Arnaud Ebalard [Tue, 5 Nov 2013 20:46:02 +0000 (21:46 +0100)]
ARM: mvebu: fix second and third PCIe unit of Armada XP mv78260
mv78260 flavour of Marvell Armada XP SoC has 3 PCIe units. The
two first units are both x4 and quad x1 capable. The third unit
is only x4 capable. This patch fixes mv78260 .dtsi to reflect
those capabilities.
Signed-off-by: Arnaud Ebalard <arno@natisbad.org> Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: <stable@vger.kernel.org> # v3.10.x Signed-off-by: Jason Cooper <jason@lakedaemon.net>
Arnaud Ebalard [Tue, 5 Nov 2013 20:45:48 +0000 (21:45 +0100)]
ARM: mvebu: second PCIe unit of Armada XP mv78230 is only x1 capable
Various Marvell datasheets advertise second PCIe unit of mv78230
flavour of Armada XP as x4/quad x1 capable. This second unit is in
fact only x1 capable. This patch fixes current mv78230 .dtsi to
reflect that, i.e. makes 1.0 the second interface (instead of 2.0
at the moment). This was successfully tested on a mv78230-based
ReadyNAS 2120 platform with a x1 device (FL1009 XHCI controller)
connected to this second interface.
Signed-off-by: Arnaud Ebalard <arno@natisbad.org> Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: <stable@vger.kernel.org> # v3.10.x Signed-off-by: Jason Cooper <jason@lakedaemon.net>
PCI: mvebu: increment nports only for registered ports
The number of ports is probed by counting the number of available child nodes.
Later on, the registration of a port can fail and cause a mismatch between
the ->nports counter and registered ports. This patch modifies the counting
strategy, to make ->nports represent the number of registered ports instead
of the number of available childs.
Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Signed-off-by: Jason Cooper <jason@lakedaemon.net>
PCI: mvebu: move clock enable before register access
The clock passed to PCI controller found on MVEBU SoCs may come from a
clock gate. This requires the clock to be enabled before any registers
are accessed. Therefore, move the clock enable before register iomap to
ensure it is enabled.
Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Signed-off-by: Jason Cooper <jason@lakedaemon.net>
Tushar Behera [Mon, 17 Jun 2013 09:16:13 +0000 (14:46 +0530)]
PCI: mvebu: Convert to use devm_ioremap_resource
Commit 75096579c3ac ("lib: devres: Introduce devm_ioremap_resource()")
introduced devm_ioremap_resource() and deprecated the use of
devm_request_and_ioremap().
While at it, modify mvebu_pcie_map_registers() to propagate error code.
Xenia Ragiadakou [Mon, 23 Dec 2013 15:59:02 +0000 (16:59 +0100)]
xhci: fix dma mask setup in xhci.c
The function dma_set_mask() tests internally whether the dma_mask pointer
for the device is initialized and fails if the dma_mask pointer is NULL.
On pci platforms, the device dma_mask pointer is initialized, when pci
devices are enumerated, to point to the pci_dev->dma_mask which is 0xffffffff.
However, for non-pci platforms, the dma_mask pointer may not be initialized
and in that case dma_set_mask() will fail.
This patch initializes the dma_mask and the coherent_dma_mask to 32bits
in xhci_plat_probe(), before the call to usb_create_hcd() that sets the
"uses_dma" flag for the usb bus and the call to usb_add_hcd() that creates
coherent dma pools for the usb hcd.
Moreover, a call to dma_set_mask() does not set the device coherent_dma_mask.
Since the xhci-hcd driver calls dma_alloc_coherent() and dma_pool_alloc()
to allocate consistent DMA memory blocks, the coherent DMA address mask
has to be set explicitly.
This patch sets the coherent_dma_mask to 64bits in xhci_gen_setup() when
the xHC is capable for 64-bit DMA addressing.
If dma_set_mask() succeeds, for a given bitmask, it is guaranteed that
the given bitmask is also supported for consistent DMA mappings.
Other changes introduced in this patch are:
- The return value of dma_set_mask() is checked to ensure that the required
dma bitmask conforms with the host system's addressing capabilities.
- The dma_mask setup code for the non-primary hcd was removed since both
primary and non-primary hcd refer to the same generic device whose
dma_mask and coherent_dma_mask are already set during the setup of
the primary hcd.
- The code for reading the HCCPARAMS register to find out the addressing
capabilities of xHC was removed since its value is already cached in
xhci->hccparams.
- hcd->self.controller was replaced with the dev variable since it is
already available.
Signed-off-by: Xenia Ragiadakou <burzalodowa@gmail.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Conflicts:
drivers/usb/host/xhci-plat.c
Al Cooper [Thu, 5 Dec 2013 23:18:25 +0000 (00:18 +0100)]
usb: Add Device Tree support to XHCI Platform driver
Add Device Tree match table to xhci-plat.c. Add DT bindings document.
Signed-off-by: Al Cooper <alcooperx@gmail.com> Cc: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Cc: Felipe Balbi <balbi@ti.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Conflicts:
drivers/usb/host/xhci-plat.c
Ezequiel Garcia [Tue, 20 Aug 2013 15:45:54 +0000 (12:45 -0300)]
clocksource: armada-370-xp: Add detailed clock requirements in devicetree binding
Specifies the required clock inputs for each supported compatible.
Armada 370 requires a single clock phandle, and Armada XP requires
two clock phandles with clock-names "nbclk" and "fixed".
Cc: devicetree@vger.kernel.org Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Acked-by: Jason Cooper <jason@lakedaemon.net> Acked-by: Stephen Warren <swarren@nvidia.com> Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
This commit fixes the DT binding for the Armada 370/XP SoC timer.
The previous "marvell,armada-370-xp-timer" compatible is removed and
two new compatible strings are introduced: "marvell,armada-xp-timer"
and "marvell,armada-370-timer".
The rationale behind this change is that the Armada 370 SoC and the
Armada XP SoC timers are not really compatible:
* Armada 370 has no 25 MHz fixed timer.
* Armada XP cannot work properly without such 25 MHz fixed timer
as doing otherwise leads to using a clocksource whose frequency
varies when doing cpufreq frequency changes.
This commit also removes the "marvell,timer-25Mhz" property, given
it's now meaningless.
Cc: devicetree@vger.kernel.org Acked-by: Jason Cooper <jason@lakedaemon.net> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Grant Likely [Thu, 19 Dec 2013 12:31:02 +0000 (09:31 -0300)]
of/irq: Fix potential buffer overflow
Commit 2361613206e6, "of/irq: Refactor interrupt-map parsing" introduced
a potential buffer overflow bug because it doesn't do sufficient range
checking on the input data. This patch adds the appropriate checking and
buffer size adjustments. If the bounds are out of range then warn
loudly. MAX_PHANDLE_ARGS should be sufficient. If it is not then the
value can be increased.
Signed-off-by: Grant Likely <grant.likely@linaro.org> Cc: Rob Herring <rob.herring@calxeda.com>
Grant Likely [Thu, 19 Dec 2013 12:31:01 +0000 (09:31 -0300)]
of/irq: Fix bug in interrupt parsing refactor.
Commit 2361613206e6, "of/irq: Refactor interrupt-map parsing" introduced
a bug. The irq parsing will fail for some nodes that don't have a reg
property. It is fixed by deferring the check for reg until it is
actually needed. Also adjust the testcase data to catch the bug.
Signed-off-by: Grant Likely <grant.likely@linaro.org> Tested-by: Stephen Warren <swarren@nvidia.com> Tested-by: Ming Lei <tom.leiming@gmail.com> Tested-by: Stephen Warren <swarren@nvidia.com> Cc: Rob Herring <rob.herring@calxeda.com>
Conflicts:
arch/arm/boot/dts/testcases/tests-interrupts.dtsi
Grant Likely [Thu, 19 Dec 2013 12:31:00 +0000 (09:31 -0300)]
of/irq: create interrupts-extended property
The standard interrupts property in device tree can only handle
interrupts coming from a single interrupt parent. If a device is wired
to multiple interrupt controllers, then it needs to be attached to a
node with an interrupt-map property to demux the interrupt specifiers
which is confusing. It would be a lot easier if there was a form of the
interrupts property that allows for a separate interrupt phandle for
each interrupt specifier.
This patch does exactly that by creating a new interrupts-extended
property which reuses the phandle+arguments pattern used by GPIOs and
other core bindings.
Signed-off-by: Grant Likely <grant.likely@linaro.org> Acked-by: Tony Lindgren <tony@atomide.com> Acked-by: Kumar Gala <galak@codeaurora.org>
[grant.likely: removed versatile platform hunks into separate patch] Cc: Rob Herring <rob.herring@calxeda.com>
Conflicts:
arch/arm/boot/dts/testcases/tests-interrupts.dtsi
drivers/of/selftest.c
Thierry Reding [Thu, 19 Dec 2013 12:30:59 +0000 (09:30 -0300)]
of/irq: Rework of_irq_count()
The of_irq_to_resource() helper that is used to implement of_irq_count()
tries to resolve interrupts and in fact creates a mapping for resolved
interrupts. That's pretty heavy lifting for something that claims to
just return the number of interrupts requested by a given device node.
Instead, use the more lightweight of_irq_map_one(), which, despite the
name, doesn't create an actual mapping. Perhaps a better name would be
of_irq_translate_one().
Signed-off-by: Thierry Reding <treding@nvidia.com> Acked-by: Rob Herring <rob.herring@calxeda.com>
[grant.likely: fixup s/of_irq_map_one/of_irq_parse_one/] Signed-off-by: Grant Likely <grant.likely@linaro.org>
Grant Likely [Thu, 19 Dec 2013 12:30:57 +0000 (09:30 -0300)]
of/irq: Refactor interrupt-map parsing
All the users of of_irq_parse_raw pass in a raw interrupt specifier from
the device tree and expect it to be returned (possibly modified) in an
of_phandle_args structure. However, the primary function of
of_irq_parse_raw() is to check for translations due to the presence of
one or more interrupt-map properties. The actual placing of the data
into an of_phandle_args structure is trivial. If it is refactored to
accept an of_phandle_args structure directly, then it becomes possible
to consume of_phandle_args from other sources. This is important for an
upcoming patch that allows a device to be connected to more than one
interrupt parent. It also simplifies the code a bit.
The biggest complication with this patch is that the old version works
on the interrupt specifiers in __be32 form, but the of_phandle_args
structure is intended to carry it in the cpu-native version. A bit of
churn was required to make this work. In the end it results in tighter
code, so the churn is worth it.
Signed-off-by: Grant Likely <grant.likely@linaro.org> Acked-by: Tony Lindgren <tony@atomide.com> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Grant Likely [Thu, 19 Dec 2013 12:30:56 +0000 (09:30 -0300)]
of/irq: simplify args to irq_create_of_mapping
All the callers of irq_create_of_mapping() pass the contents of a struct
of_phandle_args structure to the function. Since all the callers already
have an of_phandle_args pointer, why not pass it directly to
irq_create_of_mapping()?
Signed-off-by: Grant Likely <grant.likely@linaro.org> Acked-by: Michal Simek <monstr@monstr.eu> Acked-by: Tony Lindgren <tony@atomide.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Russell King <linux@arm.linux.org.uk> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Conflicts:
arch/mips/pci/pci-rt3883.c
kernel/irq/irqdomain.c
Grant Likely [Thu, 19 Dec 2013 12:30:55 +0000 (09:30 -0300)]
of/irq: Replace of_irq with of_phandle_args
struct of_irq and struct of_phandle_args are exactly the same structure.
This patch makes the kernel use of_phandle_args everywhere. This in
itself isn't a big deal, but it makes some follow-on patches simpler.
Signed-off-by: Grant Likely <grant.likely@linaro.org> Acked-by: Michal Simek <monstr@monstr.eu> Acked-by: Tony Lindgren <tony@atomide.com> Cc: Russell King <linux@arm.linux.org.uk> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Conflicts:
arch/mips/pci/pci-rt3883.c
Grant Likely [Thu, 19 Dec 2013 12:30:54 +0000 (09:30 -0300)]
of/irq: Rename of_irq_map_* functions to of_irq_parse_*
The OF irq handling code has been overloading the term 'map' to refer to
both parsing the data in the device tree and mapping it to the internal
linux irq system. This is probably because the device tree does have the
concept of an 'interrupt-map' function for translating interrupt
references from one node to another, but 'map' is still confusing when
the primary purpose of some of the functions are to parse the DT data.
This patch renames all the of_irq_map_* functions to of_irq_parse_*
which makes it clear that there is a difference between the parsing
phase and the mapping phase. Kernel code can make use of just the
parsing or just the mapping support as needed by the subsystem.
The patch was generated mechanically with a handful of sed commands.
Signed-off-by: Grant Likely <grant.likely@linaro.org> Acked-by: Michal Simek <monstr@monstr.eu> Acked-by: Tony Lindgren <tony@atomide.com> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Conflicts:
arch/arm/mach-integrator/pci_v3.c
arch/mips/pci/pci-rt3883.c
Tomasz Figa [Thu, 19 Dec 2013 12:30:53 +0000 (09:30 -0300)]
of/irq: Pass trigger type in IRQ resource flags
Some drivers might rely on availability of trigger flags in IRQ
resource, for example to configure the hardware for particular interrupt
type. However current code creating IRQ resources from data in device
tree does not configure trigger flags in resulting resources.
This patch tries to solve the problem, based on the fact that
irq_of_parse_and_map() configures the trigger based on DT interrupt
specifier and IRQD_TRIGGER_* flags are consistent with IORESOURCE_IRQ_*,
and we can get correct trigger flags by calling irqd_get_trigger_type()
after mapping the interrupt.
Signed-off-by: Tomasz Figa <tomasz.figa@gmail.com>
[grant.likely: Merged the two assignments to r->flags] Signed-off-by: Grant Likely <grant.likely@linaro.org>
Grant Likely [Thu, 19 Dec 2013 12:30:52 +0000 (09:30 -0300)]
of: Fix dereferencing node name in debug output to be safe
Several locations in the of_address and of_irq code dereference the
full_name parameter from a device_node pointer without checking if the
pointer is valid. This patch switches to use of_node_full_name() which
always checks the pointer.
Signed-off-by: Grant Likely <grant.likely@linaro.org>
of/irq: init struct resource to 0 in of_irq_to_resource()
It almost does not matter because most users use only the ->start member
of the struct. However if this struct is passed to a platform device
which is then added via platform_device_add() then the ->parent member is
also used.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Grant Likely <grant.likely@linaro.org>
Rob Herring [Thu, 19 Dec 2013 12:30:49 +0000 (09:30 -0300)]
of: clean-up ifdefs in of_irq.h
Much of of_irq.h is needlessly ifdef'ed. Clean this up and minimize the
amount ifdef'ed code. This fixes some build warnings when CONFIG_OF
is not enabled (seen on i386 and x86_64):
include/linux/of_irq.h:82:7: warning: 'struct device_node' declared inside parameter list [enabled by default]
include/linux/of_irq.h:82:7: warning: its scope is only this definition or declaration, which is probably not what you want [enabled by default]
include/linux/of_irq.h:87:47: warning: 'struct device_node' declared inside parameter list [enabled by default]
Compile tested on i386, sparc and arm.
Reported-by: Randy Dunlap <rdunlap@infradead.org> Cc: Grant Likely <grant.likely@linaro.org> Signed-off-by: Rob Herring <rob.herring@calxeda.com>
Axel Lin [Thu, 19 Dec 2013 12:30:48 +0000 (09:30 -0300)]
of/irq: Avoid calling list_first_entry() for empty list
list_first_entry() expects the list is not empty, we need to check if list is
empty before calling list_first_entry(). Thus use list_first_entry_or_null()
instead of list_first_entry().
Signed-off-by: Axel Lin <axel.lin@ingics.com> Signed-off-by: Grant Likely <grant.likely@linaro.org>
Grant Likely [Thu, 19 Dec 2013 12:30:47 +0000 (09:30 -0300)]
of/irq: create interrupts-extended property
The standard interrupts property in device tree can only handle
interrupts coming from a single interrupt parent. If a device is wired
to multiple interrupt controllers, then it needs to be attached to a
node with an interrupt-map property to demux the interrupt specifiers
which is confusing. It would be a lot easier if there was a form of the
interrupts property that allows for a separate interrupt phandle for
each interrupt specifier.
This patch does exactly that by creating a new interrupts-extended
property which reuses the phandle+arguments pattern used by GPIOs and
other core bindings.
Signed-off-by: Grant Likely <grant.likely@linaro.org> Acked-by: Tony Lindgren <tony@atomide.com> Acked-by: Kumar Gala <galak@codeaurora.org>
[grant.likely: removed versatile platform hunks into separate patch] Cc: Rob Herring <rob.herring@calxeda.com>
Conflicts:
arch/arm/boot/dts/testcases/tests-interrupts.dtsi
drivers/of/selftest.c
Ezequiel Garcia [Tue, 20 Aug 2013 15:45:51 +0000 (12:45 -0300)]
ARM: mvebu: Add clock properties to Armada XP timer node
With the addition of the Armada XP reference clock, we can now model
accurately the available clock inputs for the timer: namely, nbclk
and refclk. For each of this clock inputs we assign a name, for the
driver to select as appropriate.
Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Reviewed-by: Mike Turquette <mturquette@linaro.org> Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by: Jason Cooper <jason@lakedaemon.net>
Ezequiel Garcia [Tue, 20 Aug 2013 15:45:50 +0000 (12:45 -0300)]
ARM: mvebu: Add the reference 25 MHz fixed-clock to Armada XP
The Armada XP SoC has a reference 25 MHz fixed-clock that is used in
some controllers such as the timer and the watchdog. This commit adds
a DT representation of this clock through a fixed-clock compatible node.
Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Reviewed-by: Mike Turquette <mturquette@linaro.org> Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by: Jason Cooper <jason@lakedaemon.net>
Ezequiel Garcia [Tue, 13 Aug 2013 14:43:15 +0000 (11:43 -0300)]
ARM: mvebu: Fix the Armada 370/XP timer compatible strings
The "marvell,armada-370-xp-timer" compatible string, together with
the "marvell,timer-25Mhz" property are deprecated and should be
removed from current DT.
Instead, the timer DT nodes are now required to have an appropriate
compatible string, which should be either "marvell,armada-370-timer"
or "marvell,armada-xp-timer", depending on SoC.
The clock property is now required only for Armada 370 so move it accordingly.
Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Signed-off-by: Jason Cooper <jason@lakedaemon.net>
Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Acked-by: Jason Cooper <jason@lakedaemon.net>
Ezequiel Garcia [Tue, 20 Aug 2013 15:45:52 +0000 (12:45 -0300)]
clocksource: armada-370-xp: Replace WARN_ON with BUG_ON
If the clock fails to be obtained and the timer fails to be properly
registered, the kernel will freeze real soon. Instead, let's BUG()
where the actual problem is located.
Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Acked-by: Jason Cooper <jason@lakedaemon.net> Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Ezequiel Garcia [Tue, 13 Aug 2013 14:43:13 +0000 (11:43 -0300)]
clocksource: armada-370-xp: Introduce new compatibles
The Armada XP SoC clocksource driver cannot work without the 25 MHz
fixed timer. Therefore it's appropriate to introduce a new compatible
string and use it to set the 25 MHz fixed timer.
The 'marvell,timer-25MHz' property will be marked as deprecated.
Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Reviewed-by: Andrew Lunn <andrew@lunn.ch>
This commit creates two functions to access the TIMER_CTRL register:
one for global one for the per-cpu. This makes the code much more
readable. In addition, since the TIMER_CTRL register is also used for
watchdog, this is preparation work for future thread-safe improvements.
Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
The armada_370_xp_pmsu_init() function is called as an
early_initcall(). Therefore, there is no need to export this function,
and we can make it static.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
ARM: mvebu: fix register length for Armada XP PMSU
The per-CPU PMSU registers documented in the datasheet start at
0x22100 and the last register for CPU3 is at 0x22428. However, the DT
informations use <0x22100 0x430>, which makes the region end at
0x22530 and not 0x22430.
Moreover, looking at the datasheet, we can see that the registers for
CPU0 start at 0x22100, for CPU1 at 0x22200, for CPU2 at 0x22300 and
for CPU3 at 0x22400. It seems clear that 0x100 bytes of registers have
been used per CPU.
Therefore, this commit reduces the length of the PMSU per-CPU register
area from the incorrect 0x430 bytes to a more logical 0x400 bytes.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
ARM: mvebu: move ARMADA_XP_MAX_CPUS to armada-370-xp.h
The ARMADA_XP_MAX_CPUS definition was in common.h, which as its name
says, is common to all mvebu SoCs. It is more logical to have this XP
specific definition in the already existing armada-370-xp.h header
file.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Ezequiel Garcia [Thu, 19 Dec 2013 09:08:03 +0000 (06:08 -0300)]
mtd: nand: pxa3xx: Clear need_wait flag when starting a command
Currently the driver assumes all commands will eventually trigger a RnB
transition, and thus a "device is ready" IRQ.
This assumption means that on every issued command, the dev_ready completion
handler is init'ed and the need_wait flag is set.
However this is incorrect: some commands (such as NAND_CMD_STATUS) don't
make the device 'busy' and thus a RnB transition never occurs.
Given, the NAND core never calls waitfunc() after such commands, this
is not a problem.
Therefore, it's possible to only clear the need_wait flag on every command
that is started.
This fixes a current bug that can be reproduced on PXA boards by writing
blank (all 0xff'ed) to a page:
1. The kernel issues NAND_CMD_STATUS and sets need_wait=1. The flag
won't be cleared for this command since no RnB transition is
involved.
2. NAND_CMD_PAGEPROG is issued but since the data is blank, the driver
decides not to execute the command (and no IRQ activity is
involved).
3. The NAND core calls waitfunc() and waits for the dev_ready
completion, which will never end since the device _is_ already ready.
Ezequiel Garcia [Thu, 5 Dec 2013 16:35:37 +0000 (13:35 -0300)]
net: mvneta: Fix incorrect DMA unmapping size
The current code unmaps the DMA mapping created for rx skb_buff's by
using the data_size as the the mapping size. This is wrong since the
correct size to specify should match the size used to create the mapping.
This commit removes the following DMA_API_DEBUG warning:
------------[ cut here ]------------
WARNING: at lib/dma-debug.c:887 check_unmap+0x3a8/0x860()
mvneta d0070000.ethernet: DMA-API: device driver frees DMA memory with different size [device address=0x000000002eb80000] [map size=1600 bytes] [unmap size=66 bytes]
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.10.21-01444-ga88ae13-dirty #92
[<c0013600>] (unwind_backtrace+0x0/0xf8) from [<c0010fb8>] (show_stack+0x10/0x14)
[<c0010fb8>] (show_stack+0x10/0x14) from [<c001afa0>] (warn_slowpath_common+0x48/0x68)
[<c001afa0>] (warn_slowpath_common+0x48/0x68) from [<c001b01c>] (warn_slowpath_fmt+0x30/0x40)
[<c001b01c>] (warn_slowpath_fmt+0x30/0x40) from [<c018d0fc>] (check_unmap+0x3a8/0x860)
[<c018d0fc>] (check_unmap+0x3a8/0x860) from [<c018d734>] (debug_dma_unmap_page+0x64/0x70)
[<c018d734>] (debug_dma_unmap_page+0x64/0x70) from [<c0233f78>] (mvneta_rx+0xec/0x468)
[<c0233f78>] (mvneta_rx+0xec/0x468) from [<c023436c>] (mvneta_poll+0x78/0x16c)
[<c023436c>] (mvneta_poll+0x78/0x16c) from [<c02db468>] (net_rx_action+0x94/0x160)
[<c02db468>] (net_rx_action+0x94/0x160) from [<c0021e68>] (__do_softirq+0xe8/0x1d0)
[<c0021e68>] (__do_softirq+0xe8/0x1d0) from [<c0021ff8>] (do_softirq+0x4c/0x58)
[<c0021ff8>] (do_softirq+0x4c/0x58) from [<c0022228>] (irq_exit+0x58/0x90)
[<c0022228>] (irq_exit+0x58/0x90) from [<c000e7c8>] (handle_IRQ+0x3c/0x94)
[<c000e7c8>] (handle_IRQ+0x3c/0x94) from [<c0008548>] (armada_370_xp_handle_irq+0x4c/0xb4)
[<c0008548>] (armada_370_xp_handle_irq+0x4c/0xb4) from [<c000dc20>] (__irq_svc+0x40/0x50)
Exception stack(0xc04f1f70 to 0xc04f1fb8)
1f60: c1fe46f80000000000001d9200001d92
1f80: c04f0000c04f0000c04f84a4c03e081cc05220e700000001c05220e7c04f0000
1fa0: 00000000c04f1fb8c000eaf8c004c04860000113ffffffff
[<c000dc20>] (__irq_svc+0x40/0x50) from [<c004c048>] (cpu_startup_entry+0x54/0x128)
[<c004c048>] (cpu_startup_entry+0x54/0x128) from [<c04c1a14>] (start_kernel+0x29c/0x2f0)
[<c04c1a14>] (start_kernel+0x29c/0x2f0) from [<00008074>] (0x8074)
---[ end trace d4955f6acd178110 ]---
Mapped at:
[<c018d600>] debug_dma_map_page+0x4c/0x11c
[<c0235d6c>] mvneta_setup_rxqs+0x398/0x598
[<c0236084>] mvneta_open+0x40/0x17c
[<c02dbbd4>] __dev_open+0x9c/0x100
[<c02dbe58>] __dev_change_flags+0x7c/0x134
Ezequiel Garcia [Mon, 12 Aug 2013 17:14:59 +0000 (14:14 -0300)]
mtd: nand: Allow to build pxa3xx_nand on Orion platforms
The Armada 370 and Armada XP SoC families, selected by PLAT_ORION,
have a Nand Flash Controller (NFC) IP very similar to the one present
in PXA platforms. Therefore, we want to build this driver on PLAT_ORION.
Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Tested-by: Daniel Mack <zonque@gmail.com> Signed-off-by: Brian Norris <computersforpeace@gmail.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Ezequiel Garcia [Mon, 25 Nov 2013 15:36:18 +0000 (12:36 -0300)]
mtd: nand: pxa3xx: Consolidate ECC initialization
In order to avoid code duplication, let's consolidate the ECC setting
for all SoC variants. Such decision is based on page size and ECC
strength requirements.
Also, provide a default value for the case where such ECC information
is not provided (non-ONFI devices).
Ezequiel Garcia [Mon, 25 Nov 2013 14:02:51 +0000 (11:02 -0300)]
mtd: nand: pxa3xx: Use extended cmdfunc() only if needed
Currently, we have two different cmdfunc's implementations:
one for PXA3xx SoC variant and one for Armada 370/XP SoC variant.
The former is the legacy one, typically constrained to devices
with page sizes smaller or equal to the controller's FIFO buffer.
On the other side, the latter _only_ supports the so-called extended
command semantics, which allow to handle devices with larger
page sizes (4 KiB, 8 KiB, ...).
This means we currently don't support devices with smaller pages on the
A370/XP SoC. Fix it by first renaming the cmdfuncs variants, and then
make the choice based on device page size (and SoC variant), rather than
SoC variant alone.
While at it, add a check for page size, to make sure we don't allow larger
pages sizes on the PXA3xx variant.
Ezequiel Garcia [Mon, 25 Nov 2013 15:35:28 +0000 (12:35 -0300)]
mtd: nand: pxa3xx: Use info->use_dma to release DMA resources
After the driver allocates all DMA resources, it sets "info->use_dma".
Therefore, we need to check that variable to decide which resources
needs to be freed, instead of the global use_dma variable.
Without this change, when the device probe fails, the driver will try
to release unallocated DMA resources, with nasty results.
Brian Norris [Thu, 14 Nov 2013 22:41:32 +0000 (14:41 -0800)]
mtd: nand: pxa3xx: make ECC configuration checks more explicit
The Armada BCH configuration in this driver uses one of the two
following ECC schemes:
16-bit correction per 2048 bytes
16-bit correction per 1024 bytes
These are sufficient for mapping to the 4-bit per 512-bytes and 8-bit
per 512-bytes (respectively) minimum correctability requirements of many
common NAND.
The current code only checks for the required strength (4-bit or 8-bit)
without checking the ECC step size that is associated with that strength
(and simply assumes it is 512). While that is often a safe assumption to
make, let's make it explicit, since we have that information.
Signed-off-by: Brian Norris <computersforpeace@gmail.com> Acked-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Tested-by: Daniel Mack <zonque@gmail.com>
This commit extends the ECC correctable error detection to include
ECC BCH errors. The number of BCH correctable errors can be any up to 16,
and the actual value is exposed in the NDSR register.
Therefore, we change some symbol names to refer to correctable or
uncorrectable (instead of single-bit or double-bit as it was in the
Hamming case) and while at it, cleanup the detection code slightly.
Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Tested-by: Daniel Mack <zonque@gmail.com> Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Ezequiel Garcia [Thu, 14 Nov 2013 21:25:38 +0000 (18:25 -0300)]
mtd: nand: pxa3xx: Add multiple chunk write support
This commit adds write support for large pages (4 KiB, 8 KiB).
Such support is implemented by issuing a multiple command sequence,
transfering a set of 2 KiB chunks per transaction.
The splitted command sequence requires to send the SEQIN command
independently of the PAGEPROG command and therefore it's set as
an execution command.
Since PAGEPROG enables ECC, each 2 KiB chunk of data is written
together with ECC code at a controller-fixed location within
the flash page.
Currently, only devices with a 4 KiB page size has been tested.
Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Tested-by: Daniel Mack <zonque@gmail.com> Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Ezequiel Garcia [Thu, 14 Nov 2013 21:25:37 +0000 (18:25 -0300)]
mtd: nand: pxa3xx: Introduce multiple page I/O support
As preparation work to fully support large pages, this commit adds
the initial infrastructure to support splitted (aka chunked) I/O
operation. This commit adds support for read, and follow-up patches
will add write support.
When a read (aka READ0) command is issued, the driver loops issuing
the same command until all the requested data is transfered, changing
the 'extended' command field as needed.
For instance, if the driver is required to read a 4 KiB page, using a
chunk size of 2 KiB, the transaction is splitted in:
1. Monolithic read, first 2 KiB page chunk is read
2. Last naked read, second and last 2KiB page chunk is read
If ECC is enabled it is calculated on each chunk transfered and added
at a controller-fixed location after the data chunk that must be
spare area.
Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Tested-by: Daniel Mack <zonque@gmail.com> Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Ezequiel Garcia [Thu, 14 Nov 2013 21:25:36 +0000 (18:25 -0300)]
mtd: nand: pxa3xx: Add a read/write buffers markers
In preparation to support multiple (aka chunked, aka splitted)
page I/O, this commit adds 'data_buff_pos' and 'oob_buff_pos' fields
to keep track of where the next read (or write) should be done.
This will allow multiple calls to handle_data_pio() to continue
the read (or write) operation.
Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Tested-by: Daniel Mack <zonque@gmail.com> Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Ezequiel Garcia [Thu, 14 Nov 2013 21:25:35 +0000 (18:25 -0300)]
mtd: nand: pxa3xx: Fix SEQIN column address set
This commit adds support page programming with a non-zero "column"
address setting. This is important to support OOB writing, through
command sequences such as:
Ezequiel Garcia [Thu, 14 Nov 2013 21:25:34 +0000 (18:25 -0300)]
mtd: nand: pxa3xx: Move the data buffer clean to prepare_start_command()
To allow future support of multiple page reading/writing, move the data
buffer clean out of prepare_set_command().
This is done to prevent the data buffer from being cleaned on every command
preparation, when a multiple command sequence is implemented to read/write
pages larger than the FIFO size (2 KiB).
Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Tested-by: Daniel Mack <zonque@gmail.com> Signed-off-by: Brian Norris <computersforpeace@gmail.com>
READ0 and READOOB command preparation has a falltrough to SEQIN
case, where the command address is specified.
This is certainly confusing and makes the code less readable with
no added value. Let's remove it.
Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Tested-by: Daniel Mack <zonque@gmail.com> Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Ezequiel Garcia [Thu, 14 Nov 2013 21:25:29 +0000 (18:25 -0300)]
mtd: nand: pxa3xx: Add driver-specific ECC BCH support
This commit adds the BCH ECC support available in NFCv2 controller.
Depending on the detected required strength the respective ECC layout
is selected.
This commit adds an empty ECC layout, since support to access large
pages is first required. Once that support is added, a proper ECC
layout will be added as well.
Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Tested-by: Daniel Mack <zonque@gmail.com> Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Ezequiel Garcia [Thu, 14 Nov 2013 21:25:28 +0000 (18:25 -0300)]
mtd: nand: pxa3xx: Add bad block handling
Add support for flash-based bad block table using Marvell's
custom in-flash bad block table layout. The support is enabled
a 'flash_bbt' platform data or device tree parameter.
Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Tested-by: Daniel Mack <zonque@gmail.com> Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Ezequiel Garcia [Thu, 14 Nov 2013 21:25:27 +0000 (18:25 -0300)]
mtd: nand: pxa3xx: Use waitfunc() to wait for the device to be ready
In pxa3xx_nand_sensing() instead of simply using info->is_ready
after issuing a command, the correct way of checking is to wait
for the device to be ready through the chip's waitfunc().
Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Tested-by: Daniel Mack <zonque@gmail.com> Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Ezequiel Garcia [Thu, 14 Nov 2013 21:25:26 +0000 (18:25 -0300)]
mtd: nand: pxa3xx: Use a completion to signal device ready
The expected behavior of the waitfunc() NAND chip call is to wait
for the device to be READY (this is a standard chip line).
However, the current implementation does almost nothing, which opens
the possibility of issuing a command to a non-ready device.
Fix this by adding a new completion to wait for the ready event to arrive.
Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Tested-by: Daniel Mack <zonque@gmail.com> Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Ezequiel Garcia [Thu, 7 Nov 2013 15:17:18 +0000 (12:17 -0300)]
mtd: nand: pxa3xx: Add a nice comment to pxa3xx_set_datasize()
Add a comment clarifying the use of pxa3xx_set_datasize() which is only
applicable on data read/write commands (i.e. commands with a data cycle,
such as READID, READ0, STATUS, etc.)
Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Ezequiel Garcia [Thu, 7 Nov 2013 15:17:17 +0000 (12:17 -0300)]
mtd: nand: pxa3xx: Replace host->page_size by mtd->writesize
There's no need to privately store the device page size as it's
available in mtd structure field mtd->writesize.
Also, this removes the hardcoded page size value, leaving the
auto-detected value only.
Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Tested-by: Daniel Mack <zonque@gmail.com> Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Ezequiel Garcia [Thu, 7 Nov 2013 15:17:16 +0000 (12:17 -0300)]
mtd: nand: pxa3xx: Split FIFO size from to-be-read FIFO count
Introduce a fifo_size field to represent the size of the controller's
FIFO buffer, and use it to distinguish that size from the amount
of data bytes to be read from the FIFO.
This is important to support devices with pages larger than the
controller's internal FIFO, that need to read the pages in FIFO-sized
chunks.
In particular, the current code is at least confusing, for it mixes
all the different sizes involved: FIFO size, page size and data size.
This commit starts the cleaning by removing the info->page_size field
that is not currently used. The host->page_size field should also
be removed and use always mtd->writesize instead. Follow up commits
will clean this up.
Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Tested-by: Daniel Mack <zonque@gmail.com> Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Ezequiel Garcia [Thu, 7 Nov 2013 15:17:15 +0000 (12:17 -0300)]
mtd: nand: pxa3xx: Use chip->cmdfunc instead of the internal
Whenever possible, it's always better to use the generic chip->cmdfunc
instead of the internal pxa3xx_nand_cmdfunc().
In this particular case, this will allow to have multiple cmdfunc()
implementations for different SoC variants.
Reviewed-by: Huang Shijie <shijie8@gmail.com> Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Tested-by: Daniel Mack <zonque@gmail.com> Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Ezequiel Garcia [Thu, 7 Nov 2013 15:17:14 +0000 (12:17 -0300)]
mtd: nand: pxa3xx: Early variant detection
In order to customize early settings depending on the detected SoC variant,
move the detection to be before the nand_chip struct filling.
In a follow-up patch, this change is needed to detect the variant *before*
the call to alloc_nand_resource(), which allows to set a different cmdfunc()
for each variant.
Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Tested-by: Daniel Mack <zonque@gmail.com> Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Ezequiel Garcia [Thu, 7 Nov 2013 15:17:10 +0000 (12:17 -0300)]
mtd: nand: pxa3xx: Add documentation about the controller
Given there's no public specification to this date, and in order
to capture some important details and singularities about the
controller let's document them once and for good.
Cc: linux-doc@vger.kernel.org Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Ezequiel Garcia [Fri, 4 Oct 2013 18:30:38 +0000 (15:30 -0300)]
mtd: nand: pxa3xx: Allocate data buffer on detected flash size
This commit replaces the currently hardcoded buffer size, by a
dynamic detection scheme. First a small 256 bytes buffer is allocated
so the device can be detected (using READID and friends commands).
After detection, this buffer is released and a new buffer is allocated
to acommodate the page size plus out-of-band size.
Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Tested-by: Daniel Mack <zonque@gmail.com> Signed-off-by: Brian Norris <computersforpeace@gmail.com>
There's no advantage in using a hardcoded name for the mtd device.
Instead use the provided by the platform_device.
The MTD name was changed to use the one provided by the platform_device.
However, this can be problematic as some users want to set partitions
using the kernel parameter 'mtdparts', where the name is needed.
Therefore, to avoid regressions in users relying in 'mtdparts' we revert
the change and use the previous one 'pxa3xx_nand-0'.
While at it, let's put a big comment and prevent this change from happening
ever again.
Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Signed-off-by: Brian Norris <computersforpeace@gmail.com>
projects / people / arne_f / kernel.git / log
