* [PATCH RFC v2 2/2] Documentation: arm: define DT C-states bindings
From: Lorenzo Pieralisi @ 2014-01-29 12:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140127155924.GA2178@e103592.cambridge.arm.com>
On Mon, Jan 27, 2014 at 03:59:37PM +0000, Dave Martin wrote:
> On Fri, Jan 24, 2014 at 05:58:07PM +0000, Lorenzo Pieralisi wrote:
[...]
> > > > state0 {
> > > > index = <2>;
> > > > compatible = "arm,cpu-power-state";
> > > > latency = <...>;
> > > > /*
> > > > * This means that when the state is entered, the power
> > > > * controller should use register index 0 and state 0,
> > > > * whose meaning is power controller specific. Since we
> > > > * know all components affected (for every component
> > > > * we declare its power domain(s) and states so we
> > > > * know what components are affected by the state entry.
> > > > * Given the cache node above and this phandle, the state
> > > > * implies that the cache is retained, register index == 0 state == 0
> > > > /*
> > > > power-domain =<&foo_power_controller 0 0>;
> > >
> > > for retention state we need to set the power domain in state 1
> > > power-domain =<&foo_power_controller 0 1>;
>
> The name "power-domain" probably needs changing if the specifier contains
> state information too.
>
> Instead, we could call it "power-state" or similar.
>
>
> Key issues I see:
>
> 1) How to describe platforms where there is no "power controller" as such,
> just a bunch of clocks and regulators that Linux has to poke directly.
>
> 2) Two devices might have the same power controller (in terms of IP and
> revision), but integrated in different ways. So, maybe thinking of
> the referenced thing as a power controller is not correct. We can
> thing in terms of referring to individual power domains, or maybe
> to a "power model" for the SoC.
The example was misleading. There is no link to a power controller as
such, the phandle is to a power domain, which fits with what you are
saying, basically the C-state does not care about how the power domain
is implemented, it just defines that that specific power domain is
affected. I am not sure we should change the naming either, a C-state
defines a power-domain specifier, which implies a certain behaviour
for a power domain. It is platform specific, so for certain platforms
the cells represent a state for others they do not.
> The power domain or model becomes a container for power (domains and)
> states, and refers to the IP blocks (power controllers, regulators,
> clocks, clamps, whatever) required to implement it.
>
> This change of abstraction might map more naturally onto "bunch
> of clocks and regulators" situations: the power model or domain
> binding can make symbolic references to clocks and regulators etc.,
> so that the binding becomes less dependent on the exact content of
> the rest of the DT.
Exactly, I agree, the complexity is in the power-domain (how states are
handled, what components should be programmed, etc) the C-state just
defines what power-domain it affects, with power domain specifier cells
providing additional, power domain specific, semantics (ie retention vs.
shutdown).
> 3) We need to be very clear that the power state specifier needs to be
> defined in terms of the actual hardware effects in the relevant SoC-
> specific binding -- at the "what" level, rather than "how".
>
> There's a fair chance of people getting lazy: they'll just stuff
> indices in the DT which map to random LUTs in the Linux driver. In
> that case, the DT would be describing the Linux driver, not the
> hardware -- that's not what we want.
>
> Delegating the job of defining power states to the SoC documentation
> seems acceptable, though.
I agree, and I think we are pretty close to a general agreement on this
specific subject.
Thank you,
Lorenzo
^ permalink raw reply
* Building with gcc 4.6.4
From: Mikael Pettersson @ 2014-01-29 12:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140128150611.GL15937@n2100.arm.linux.org.uk>
Russell King - ARM Linux writes:
> On Tue, Jan 28, 2014 at 03:38:14PM +0100, Mikael Pettersson wrote:
> > Russell King - ARM Linux writes:
> > > So, yesterday I built gcc 4.6.4 (mainline) for the autobuilder, and the
> > > result is that every build failed with the same error:
> > >
> > > scripts/mod/empty.c:1:0: error: FPA is unsupported in the AAPCS
> > >
> > > This seems to be because linux-elf targets default to fpe3 in mainline
> > > gcc, but specifying -mabi=aapcs-linux switches us into EABI mode where
> > > the compiler errors out with the default FPU.
> > >
> > > Hence, I believe we need this to ensure that a compatible VFP is
> > > selected. One can argue that building EABI ARMv4 with VFP is silly,
> > > but it seems that's what the gcc folk have decided (rightly or
> > > wrongly.)
> > >
> > > Maybe this is a bug in mainline GCC - which begs the question why
> > > (presumably, since no one has picked this up) Linaro's toolchain
> > > has fixes but mainline GCC doesn't.
> > >
> > > Comments?
> >
> > Perhaps because most ARM EABI toolchains default to soft-float,
> > and the hardfloat ones usually select v6 or v7 + vfp-d16 or neon
> > as their defaults, so the archaic FPA is never the default.
>
> soft-float has nothing to do with it, because the kernel always passes
> -msoft-float.
>
> > Or are you using an OABI toolchain to compile an EABI kernel?
>
> ... which should make no difference what so ever since the kernel should
> be passing the appropriate options. That's why we pass -mabi=aapcs-linux
> to the kernel.
I can reproduce your error with an OABI toolchain (gcc-4.6.4 or 4.7.3,
default configuration options wrt ISA and floating-point model), but
there's no such error with an EABI toolchain. So it looks like you've
found a GCC bug.
However, the toolchain people considers OABI to be obsolete, it's
unsupported since gcc-4.7.0, gcc-4.6 is EOL, and even gcc-4.7 is
nearing EOL (will probably happen this spring or early summer after
the release of gcc-4.9.0), so I doubt anyone is going to work on
this issue.
/Mikael
^ permalink raw reply
* iop32x: gpio breakage after "instantiate GPIO from platform device"
From: Linus Walleij @ 2014-01-29 12:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4202760.m9CxkiIWk3@wuerfel>
On Tue, Jan 28, 2014 at 10:05 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> Commit 7b85b867b9904 "ARM: plat-iop: instantiate GPIO from platform
> device" nicely cleaned up the gpio register access for iop, but
> forgot one board that directly pokes into the gpio registers
> to do a system reset.
>
> That board no longer compiles, and this patch just disables
> the code in question to work around it so I can locally build
> randconfig again, but it needs to be fixed properly.
OK I'm sending a proper fix instead.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH RFC v2 2/2] Documentation: arm: define DT C-states bindings
From: Lorenzo Pieralisi @ 2014-01-29 12:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKfTPtAEekg_KHhLikJK=njC-b5F=MOmAmSP8P96+j_23-iu3Q@mail.gmail.com>
On Tue, Jan 28, 2014 at 08:24:54AM +0000, Vincent Guittot wrote:
> On 24 January 2014 18:58, Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> wrote:
[...]
> >> Please look below, i have modified the rest of your example accordingly
> >>
> >> >
> >> > }:
> >> >
> >> > and then
> >> >
> >> > state0 {
> >> > index = <2>;
> >> > compatible = "arm,cpu-power-state";
> >> > latency = <...>;
> >> > /*
> >> > * This means that when the state is entered, the power
> >> > * controller should use register index 0 and state 0,
> >> > * whose meaning is power controller specific. Since we
> >> > * know all components affected (for every component
> >> > * we declare its power domain(s) and states so we
> >> > * know what components are affected by the state entry.
> >> > * Given the cache node above and this phandle, the state
> >> > * implies that the cache is retained, register index == 0 state == 0
> >> > /*
> >> > power-domain =<&foo_power_controller 0 0>;
> >>
> >> for retention state we need to set the power domain in state 1
> >> power-domain =<&foo_power_controller 0 1>;
> >>
> >> > };
> >> >
> >> > state1 {
> >> > index = <3>;
> >> > compatible = "arm,cpu-power-state";
> >> > latency = <...>;
> >> > /*
> >> > * This means that when the state is entered, the power
> >> > * controller should use register index 0 and state 1,
> >> > * whose meaning is power controller specific. Since we
> >> > * know all components affected (for every component
> >> > * we declare its power domain(s) and states so we
> >> > * know what components are affected by the state entry.
> >> > * Given the cache node above and this phandle, the state
> >> > * implies that the cache is lost, register index == 0 state == 1
> >> > /*
> >> > power-domain =<&foo_power_controller 0 1>;
> >>
> >> for power down mode, we need to set thge power domain in state 2
> >> power-domain =<&foo_power_controller 0 2>;
> >
> > Ok, what I meant was not what you got, but your approach looks sensible
> > too. What I do not like is that the power-domain specifier is power
>
> sorry for the misconception of your example
>
> > controller specific (that was true even for my example). In theory
> > we can achieve something identical by forcing every component in a power
> > domain to specify the max C-state index that allows it to retain its
>
> I'm not sure that we should force a component to set an opaque (for
> the component) max c-state. The device should describe its power
> domain requirements and the correlation of the latter with the
> description of the c-state binding should be enough to deduct the max
> c-state.
I agree, that was an option, I just loathe the idea of implementing it.
Using power domain specifiers is ways cleaner IMHO, the only drawback is
that, it is up to the power domain documentation to define what a state
means in terms of save/restore and cache behavior. I think that makes
perfect sense, at least for me.
> > state (through a specific property). Same logic to your example applies.
> > Nice thing is that we do not change the power domain specifiers, bad thing
> > is that it adds two properties to each device (c-state index and
> > power-domain-specifier - but we can make it hierarchical so that device
> > nodes can inherit the maximum operating C-state by inheriting the value
> > from a parent node providing a common value).
> >
> > In my example the third parameter was just a number that the power
> > controller would decode (eg 0 = cache retained, 1 = cache lost)
> > according to its implementation, it was not a "state index". The
> > power controller would know what to do with eg a cache component (that
> > declares to be in that power domain) when a C-state with that power
> > domain specifier was entered.
> >
> > Not very different from what you are saying, let's get to the nub:
> >
> > - Either we define it in a platform specific way through the power
> > domain specifier
> > - Or we force a max-c-state-supported property for every device,
> > possibly hierarchical
>
> As explained above, adding a max-cstate property for a device that
> only know the power-domain is not a good thing IMHO.
I agree, if nobody complains that's the way I will define the bindings.
Thank you,
Lorenzo
^ permalink raw reply
* iop32x: gpio breakage after "instantiate GPIO from platform device"
From: Arnd Bergmann @ 2014-01-29 12:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdbd1FOOZOrF5crh3dYfYOy1CaYFH-SOqw_SJmd39JBjhg@mail.gmail.com>
On Wednesday 29 January 2014 13:41:59 Linus Walleij wrote:
> On Tue, Jan 28, 2014 at 10:05 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>
> > Commit 7b85b867b9904 "ARM: plat-iop: instantiate GPIO from platform
> > device" nicely cleaned up the gpio register access for iop, but
> > forgot one board that directly pokes into the gpio registers
> > to do a system reset.
> >
> > That board no longer compiles, and this patch just disables
> > the code in question to work around it so I can locally build
> > randconfig again, but it needs to be fixed properly.
>
> OK I'm sending a proper fix instead.
Ok, thanks!
Arnd
^ permalink raw reply
* [PATCH] ARM: iop32x: fix reset handling for the EM7210 board
From: Linus Walleij @ 2014-01-29 12:45 UTC (permalink / raw)
To: linux-arm-kernel
This board was missed when converting all the others to proper
abstracted GPIO handling. Fix it up the right way by requesting
and driving GPIO line 0 high through gpiolib to reset the machine.
Reported-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
ARM SoC folks, if you're happy with this fix, please apply it
directly to fixes in the ARM SoC tree.
---
arch/arm/mach-iop32x/em7210.c | 16 +++++++++++++---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-iop32x/em7210.c b/arch/arm/mach-iop32x/em7210.c
index 177cd073a83b..e0c4187f3799 100644
--- a/arch/arm/mach-iop32x/em7210.c
+++ b/arch/arm/mach-iop32x/em7210.c
@@ -23,6 +23,7 @@
#include <linux/mtd/physmap.h>
#include <linux/platform_device.h>
#include <linux/i2c.h>
+#include <linux/gpio.h>
#include <mach/hardware.h>
#include <linux/io.h>
#include <linux/irq.h>
@@ -176,14 +177,21 @@ static struct platform_device em7210_serial_device = {
.resource = &em7210_uart_resource,
};
+#define EM7210_HARDWARE_RESET 0
+
void em7210_power_off(void)
{
- *IOP3XX_GPOE &= 0xfe;
- *IOP3XX_GPOD |= 0x01;
+ int ret;
+
+ ret = gpio_direction_output(EM7210_HARDWARE_RESET, 1);
+ if (ret)
+ pr_crit("could not drive reset GPIO high\n");
}
static void __init em7210_init_machine(void)
{
+ int ret;
+
register_iop32x_gpio();
platform_device_register(&em7210_serial_device);
platform_device_register(&iop3xx_i2c0_device);
@@ -194,7 +202,9 @@ static void __init em7210_init_machine(void)
i2c_register_board_info(0, em7210_i2c_devices,
ARRAY_SIZE(em7210_i2c_devices));
-
+ ret = gpio_request(EM7210_HARDWARE_RESET, "reset");
+ if (ret)
+ pr_err("could not request reset GPIO\n");
pm_power_off = em7210_power_off;
}
--
1.8.5.3
^ permalink raw reply related
* [PATCH] ARM: iop32x: fix reset handling for the EM7210 board
From: Arnaud Patard (Rtp) @ 2014-01-29 12:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390999545-31428-1-git-send-email-linus.walleij@linaro.org>
Linus Walleij <linus.walleij@linaro.org> writes:
Hi,
don't know how to comment about the subjet but it's _not_ about
resetting the board but about powering it off.
> This board was missed when converting all the others to proper
> abstracted GPIO handling. Fix it up the right way by requesting
> and driving GPIO line 0 high through gpiolib to reset the machine.
>
> Reported-by: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> ARM SoC folks, if you're happy with this fix, please apply it
> directly to fixes in the ARM SoC tree.
> ---
> arch/arm/mach-iop32x/em7210.c | 16 +++++++++++++---
> 1 file changed, 13 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/mach-iop32x/em7210.c b/arch/arm/mach-iop32x/em7210.c
> index 177cd073a83b..e0c4187f3799 100644
> --- a/arch/arm/mach-iop32x/em7210.c
> +++ b/arch/arm/mach-iop32x/em7210.c
> @@ -23,6 +23,7 @@
> #include <linux/mtd/physmap.h>
> #include <linux/platform_device.h>
> #include <linux/i2c.h>
> +#include <linux/gpio.h>
> #include <mach/hardware.h>
> #include <linux/io.h>
> #include <linux/irq.h>
> @@ -176,14 +177,21 @@ static struct platform_device em7210_serial_device = {
> .resource = &em7210_uart_resource,
> };
>
> +#define EM7210_HARDWARE_RESET 0
> +
please fix accoring to my previous comment.
> void em7210_power_off(void)
> {
> - *IOP3XX_GPOE &= 0xfe;
> - *IOP3XX_GPOD |= 0x01;
> + int ret;
> +
> + ret = gpio_direction_output(EM7210_HARDWARE_RESET, 1);
> + if (ret)
> + pr_crit("could not drive reset GPIO high\n");
> }
>
> static void __init em7210_init_machine(void)
> {
> + int ret;
> +
> register_iop32x_gpio();
> platform_device_register(&em7210_serial_device);
> platform_device_register(&iop3xx_i2c0_device);
> @@ -194,7 +202,9 @@ static void __init em7210_init_machine(void)
>
> i2c_register_board_info(0, em7210_i2c_devices,
> ARRAY_SIZE(em7210_i2c_devices));
> -
> + ret = gpio_request(EM7210_HARDWARE_RESET, "reset");
> + if (ret)
> + pr_err("could not request reset GPIO\n");
no chance to work. too early. you'll get a -EPROBE_DEFER.
Arnaud
^ permalink raw reply
* [PATCH v3 1/3] ARM: sun7i/sun6i: irqchip: Add irqchip driver for NMI controller
From: Maxime Ripard @ 2014-01-29 12:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOQ7t2YLv8dNF6i-X6Y1BgvvcBCNt6JhmpGuo23E057xez6+Tg@mail.gmail.com>
On Tue, Jan 28, 2014 at 10:02:46PM +0100, Carlo Caione wrote:
> Hi,
>
> On Tue, Jan 28, 2014 at 5:41 PM, Maxime Ripard
> <maxime.ripard@free-electrons.com> wrote:
> > Hi,
> >
> > On Tue, Jan 28, 2014 at 12:02:23PM +0100, Hans de Goede wrote:
> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> Hash: SHA1
> >>
> >> Hi,
> >>
> >> On 01/28/2014 11:40 AM, Maxime Ripard wrote:
> >>
> >> Jumping in here to try and clarify things, or so I hope at least :)
> >
> > Sure :)
> >
> >> No, the IRQ from the PMIC is a level sensitive IRQ, so it would look
> >> like this:
> >
> > Hmm, your mailer seems to have mangled your drawing :(
> >
> >> The PMIC irq line won't go low until an i2c write to its irq status
> >> registers write-clears all status bits for which the corresponding
> >> bit in the irq-mask register is set.
> >
> > Which makes sense too
> >
> >> And the only reason the NMI -> GIC also goes low is because the unmask
> >> operation writes a second ack to the NMI controller in the unmask
> >> callback of the NMI controller driver.
> >
> > Yes, and this is exactly what I don't understand. You shouldn't need
> > that ack in first place, since it's been done already right after the
> > unmask.
>
> But the first ack is ignored since the IRQ line is still maintained
> asserted by PMIC.
>
> >> Note that we cannot use edge triggered interrupts here because the PMIC
> >> has the typical setup with multiple irq status bits driving a single
> >> irq line, so the irq handler does read irq-status, handle stuff,
> >> write-clear irq-status. And if any other irq-status bits get set
> >> between the read and write-clear the PMIC -> NMI line will stay
> >> high, as it should since there are more interrupts to handle.
> >
> > Yep, the edge-thing was just the only case I could think of where it
> > could lead to troubles.
> >
> > In what you're saying, which makes total sense, if we don't do the
> > ack, as soon as the irq will be unmasked, since the level is high, the
> > handler will be called again, treat the new interrupts, and so on. I
> > don't see how this is an issue actually.
>
> This is exactly why in unmask callback we first ACK and then unmask.
> So, if the line is still maintained up by PMIC then a new interrupt is
> raised otherwise nothing happens.
>
> >> > But in this case, you would have two events coming from your
> >> > device (the two rising edges), so you'd expect two interrupts. And
> >> > in the case of a level triggered interrupt, the device would keep
> >> > the interrupt line active until it's unmasked, so we wouldn't end
> >> > up with this either.
> >> >
> >> >> sunxi_sc_nmi_ack_and_unmask is therefore called (by
> >> >> irq_finalize_oneshot) after the IRQ thread has been
> >> >> executed. After the IRQ thread has ACKed the IRQs on the
> >> >> originating device we can finally ACK and unmask again the NMI.
> >> >
> >> > And what happens if you get a new interrupt right between the end
> >> > of the handler and the unmask?
> >>
> >> The implicit ack done by the unmask will be ignored if the NMI line
> >> is still high, just like the initial ack is ignored (which is why we
> >> need the mask), and when the unmask completes the irq will
> >> immediately retrigger, as it should.
> >
> > Yeah, but why do we need the ack in the first place? I can't think of
> > a case where the ACK would be doing something useful. Either:
> > - there is no new interrupts between the mask/ack and the unmask, so
> > there's no interrupt to ack.
> > - There's a new interrupt between the mask/ack and the
> > unmask. There's two more cases here:
> > * The interrupt came before the device handler kicked in, and the
> > handler will treat it/ack it: No issue
> > * The interrupt comes right after the handler has been acking its
> > interrupt, the level stays high, your handler is called once
> > again, you can treat it: No issue
>
> AFAIU the problem here is that the only ACK that is able to assert the
> line NMI -> GIC is the ACK by the unmask callback. All the others ACKs
> before that one are ignored by the NMI controller since the line PMIC
> -> NMI is still asserted.
So, to sum things up, what you see is something like:
handle_level_irq
| device device
| mask ack handler irq acked unmask
| | | | | |
v v v v v v
NMI -> GIC:
+--------+ +---------------------
---------------+ +-----+
PMIC -> NMI:
+-------------------------+
------------+ +-------------
And you get a "rogue" retrigger because the NMI -> GIC level went up
again.
I'm not exactly sure on how to fix this. Maybe by adding a call to the
irqchip's ack just before the unmask in irq_finalize_oneshot?
Thomas, what are your thoughts on this?
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140129/f5612997/attachment.sig>
^ permalink raw reply
* PCIe trouble on imx6q
From: Bjorn Helgaas @ 2014-01-29 12:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAM9uW_56VQTui7ggin2kCHH=5JfS2SCm--T51azUZA3da8st9g@mail.gmail.com>
[+cc linux-arm, Richard, Shawn (please keep the cc list)]
On Wed, Jan 29, 2014 at 2:28 AM, Kamel BOUHARA <k.bouhara@gmail.com> wrote:
> ---------- Forwarded message ----------
> From: Kamel BOUHARA <k.bouhara@gmail.com>
> Date: 2014-01-29
> Subject: Re: PCIe trouble on imx6q
> To: Bjorn Helgaas <bhelgaas@google.com>
>
>
> 2014-01-28 Bjorn Helgaas <bhelgaas@google.com>:
>> [+cc Richard, Shawn, linux-arm-kernel (all from MAINTAINERS)]
>>
>> On Tue, Jan 28, 2014 at 1:02 AM, Kamel BOUHARA <k.bouhara@gmail.com> wrote:
>>> Hello,
>>>
>>> Im getting trouble with kernel 3.13 at boot time, the pcie link failed
>>> to get up with the following log:
>>> ------------[ cut here ]------------
>>> WARNING: CPU: 0 PID: 1 at drivers/gpio/gpiolib.c:159 gpio_to_desc+0x34/0x48()
>>> invalid GPIO -2
>>> Modules linked in:
>>> CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.13.0+ #4
>>> Backtrace:
>>> [<8001217c>] (dump_backtrace) from [<80012460>] (show_stack+0x18/0x1c)
>>> r6:802b9548 r5:00000000 r4:808d3060 r3:00000000
>>> [<80012448>] (show_stack) from [<806414fc>] (dump_stack+0x84/0x9c)
>>> [<80641478>] (dump_stack) from [<800289f8>] (warn_slowpath_common+0x70/0x94)
>>> r5:00000009 r4:bf05bcb0
>>> [<80028988>] (warn_slowpath_common) from [<80028a54>]
>>> (warn_slowpath_fmt+0x38/0x40)
>>> r8:01f00000 r7:00000000 r6:0011cc11 r5:808b68c0 r4:bf24fa30
>>> [<80028a20>] (warn_slowpath_fmt) from [<802b9548>] (gpio_to_desc+0x34/0x48)
>>> r3:fffffffe r2:807d23fc
>>> [<802b9514>] (gpio_to_desc) from [<802d9de0>] (imx6_pcie_host_init+0x174/0x434)
>>> [<802d9c6c>] (imx6_pcie_host_init) from [<80886dbc>]
>>> (dw_pcie_host_init+0x348/0x41c)
>>> r6:00000000 r5:808d52cc r4:00000020 r3:802d9c6c
>>> [<80886a74>] (dw_pcie_host_init) from [<808871d4>] (imx6_pcie_probe+0x320/0x3dc)
>>> r10:00000000 r9:000000c4 r8:808d539c r7:bf7e3384 r6:bf24fa30 r5:bf135810
>>> r4:bf24fa10
>>> [<80886eb4>] (imx6_pcie_probe) from [<8034b670>] (platform_drv_probe+0x20/0x50)
>>> r8:808d539c r7:00000000 r6:00000000 r5:808d539c r4:bf135810
>>> [<8034b650>] (platform_drv_probe) from [<80349c74>]
>>> (driver_probe_device+0x118/0x234)
>>> r5:bf135810 r4:80e526b8
>>> [<80349b5c>] (driver_probe_device) from [<80349e78>] (__driver_attach+0x9c/0xa0)
>>> r8:80886e90 r7:00000000 r6:bf135844 r5:808d539c r4:bf135810 r3:00000000
>>> [<80349ddc>] (__driver_attach) from [<8034806c>] (bus_for_each_dev+0x68/0x9c)
>>> r6:80349ddc r5:808d539c r4:00000000 r3:00000000
>>> [<80348004>] (bus_for_each_dev) from [<8034972c>] (driver_attach+0x20/0x28)
>>> r6:808df6a8 r5:bf1f5e00 r4:808d539c
>>> [<8034970c>] (driver_attach) from [<803493b0>] (bus_add_driver+0x148/0x1f4)
>>> [<80349268>] (bus_add_driver) from [<8034a4c8>] (driver_register+0x80/0x100)
>>> r7:8090e640 r6:8090e640 r5:00000005 r4:808d539c
>>> [<8034a448>] (driver_register) from [<8034b63c>]
>>> (__platform_driver_register+0x50/0x64)
>>> r5:00000005 r4:808d5388
>>> [<8034b5ec>] (__platform_driver_register) from [<8034b6e0>]
>>> (platform_driver_probe+0x28/0xac)
>>> [<8034b6b8>] (platform_driver_probe) from [<80886ea8>]
>>> (imx6_pcie_init+0x18/0x24)
>>> r5:00000005 r4:808aa104
>>> [<80886e90>] (imx6_pcie_init) from [<80008978>] (do_one_initcall+0x100/0x164)
>>> [<80008878>] (do_one_initcall) from [<8085ecc0>]
>>> (kernel_init_freeable+0x10c/0x1d0)
>>> r10:8089e060 r9:000000c4 r8:8089e050 r7:8090e640 r6:8090e640 r5:00000005
>>> r4:808aa104
>>> [<8085ebb4>] (kernel_init_freeable) from [<8063b67c>] (kernel_init+0x10/0x120)
>>> r10:00000000 r9:00000000 r8:00000000 r7:00000000 r6:00000000 r5:8063b66c
>>> r4:00000000
>>> [<8063b66c>] (kernel_init) from [<8000e9c8>] (ret_from_fork+0x14/0x2c)
>>> r4:00000000 r3:ffffffff
>>> ---[ end trace b5e746dfc2398cd6 ]---
>>> ------------[ cut here ]------------
>>> WARNING: CPU: 0 PID: 1 at drivers/gpio/gpiolib.c:159 gpio_to_desc+0x34/0x48()
>>> invalid GPIO -2
>>> Modules linked in:
>>> CPU: 0 PID: 1 Comm: swapper/0 Tainted: G W 3.13.0+ #4
>>> Backtrace:
>>> [<8001217c>] (dump_backtrace) from [<80012460>] (show_stack+0x18/0x1c)
>>> r6:802b9548 r5:00000000 r4:808d3060 r3:00000000
>>> [<80012448>] (show_stack) from [<806414fc>] (dump_stack+0x84/0x9c)
>>> [<80641478>] (dump_stack) from [<800289f8>] (warn_slowpath_common+0x70/0x94)
>>> r5:00000009 r4:bf05bcb0
>>> [<80028988>] (warn_slowpath_common) from [<80028a54>]
>>> (warn_slowpath_fmt+0x38/0x40)
>>> r8:01f00000 r7:00000000 r6:0011cc11 r5:808b68c0 r4:bf24fa30
>>> [<80028a20>] (warn_slowpath_fmt) from [<802b9548>] (gpio_to_desc+0x34/0x48)
>>> r3:fffffffe r2:807d23fc
>>> [<802b9514>] (gpio_to_desc) from [<802d9df8>] (imx6_pcie_host_init+0x18c/0x434)
>>> [<802d9c6c>] (imx6_pcie_host_init) from [<80886dbc>]
>>> (dw_pcie_host_init+0x348/0x41c)
>>> r6:00000000 r5:808d52cc r4:00000020 r3:802d9c6c
>>> [<80886a74>] (dw_pcie_host_init) from [<808871d4>] (imx6_pcie_probe+0x320/0x3dc)
>>> r10:00000000 r9:000000c4 r8:808d539c r7:bf7e3384 r6:bf24fa30 r5:bf135810
>>> r4:bf24fa10
>>> [<80886eb4>] (imx6_pcie_probe) from [<8034b670>] (platform_drv_probe+0x20/0x50)
>>> r8:808d539c r7:00000000 r6:00000000 r5:808d539c r4:bf135810
>>> [<8034b650>] (platform_drv_probe) from [<80349c74>]
>>> (driver_probe_device+0x118/0x234)
>>> r5:bf135810 r4:80e526b8
>>> [<80349b5c>] (driver_probe_device) from [<80349e78>] (__driver_attach+0x9c/0xa0)
>>> r8:80886e90 r7:00000000 r6:bf135844 r5:808d539c r4:bf135810 r3:00000000
>>> [<80349ddc>] (__driver_attach) from [<8034806c>] (bus_for_each_dev+0x68/0x9c)
>>> r6:80349ddc r5:808d539c r4:00000000 r3:00000000
>>> [<80348004>] (bus_for_each_dev) from [<8034972c>] (driver_attach+0x20/0x28)
>>> r6:808df6a8 r5:bf1f5e00 r4:808d539c
>>> [<8034970c>] (driver_attach) from [<803493b0>] (bus_add_driver+0x148/0x1f4)
>>> [<80349268>] (bus_add_driver) from [<8034a4c8>] (driver_register+0x80/0x100)
>>> r7:8090e640 r6:8090e640 r5:00000005 r4:808d539c
>>> [<8034a448>] (driver_register) from [<8034b63c>]
>>> (__platform_driver_register+0x50/0x64)
>>> r5:00000005 r4:808d5388
>>> [<8034b5ec>] (__platform_driver_register) from [<8034b6e0>]
>>> (platform_driver_probe+0x28/0xac)
>>> [<8034b6b8>] (platform_driver_probe) from [<80886ea8>]
>>> (imx6_pcie_init+0x18/0x24)
>>> r5:00000005 r4:808aa104
>>> [<80886e90>] (imx6_pcie_init) from [<80008978>] (do_one_initcall+0x100/0x164)
>>> [<80008878>] (do_one_initcall) from [<8085ecc0>]
>>> (kernel_init_freeable+0x10c/0x1d0)
>>> r10:8089e060 r9:000000c4 r8:8089e050 r7:8090e640 r6:8090e640 r5:00000005
>>> r4:808aa104
>>> [<8085ebb4>] (kernel_init_freeable) from [<8063b67c>] (kernel_init+0x10/0x120)
>>> r10:00000000 r9:00000000 r8:00000000 r7:00000000 r6:00000000 r5:8063b66c
>>> r4:00000000
>>> [<8063b66c>] (kernel_init) from [<8000e9c8>] (ret_from_fork+0x14/0x2c)
>>> r4:00000000 r3:ffffffff
>>> ---[ end trace b5e746dfc2398cd7 ]---
>>> imx6q-pcie 1ffc000.pcie: phy link never came up
>>> PCI host bridge to bus 0000:00
>>> pci_bus 0000:00: root bus resource [io 0x1000-0x10000]
>>> pci_bus 0000:00: root bus resource [mem 0x01000000-0x01efffff]
>>> pci_bus 0000:00: No busn resource found for root bus, will use [bus 00-ff]
>>
>> Not related to the GPIO/link problem, but something's wrong here --
>> the host bridge driver should be telling us what bus numbers are
>> behind the host bridge. Since it didn't, the PCI core had to guess.
>>
>>> PCI: bus0: Fast back to back transfers disabled
>>> PCI: bus1: Fast back to back transfers enabled
>>> pci 0000:00:00.0: BAR 0: assigned [mem 0x01000000-0x010fffff]
>>> pci 0000:00:00.0: BAR 6: assigned [mem 0x01100000-0x0110ffff pref]
>>> pci 0000:00:00.0: PCI bridge to [bus 01]
>>> pci 0000:00:00.0: PCI bridge to [bus 01]
>>>
>>> Please, any help is welcome.
>>> Regards,
>>> Kamel.B
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
>>> the body of a message to majordomo at vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
> So I suppose, this is not a hardware issue rather a bad configuration ?
> Maybe the following log from lspci will be helpful ?
It looks like a configuration issue or an imx6q host bridge issue. In
either case, it looks like something *before* we get to PCIe, so
something like your DT description of the host bridge is more likely
to be useful.
> root at phyFLEX-i:~ lspci -vvv
> 00:00.0 PCI bridge: Device 16c3:abcd (rev 01) (prog-if 00 [Normal decode])
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
> ParErr+ Stepping- SERR+ FastB2B- DisINTx+
> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
> <TAbort- <MAbort- >SERR- <PERR- INTx-
> Latency: 0, Cache Line Size: 64 bytes
> Region 0: Memory at 01000000 (32-bit, non-prefetchable) [size=1M]
> Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
> I/O behind bridge: 0000f000-00000fff
> Memory behind bridge: fff00000-000fffff
> Prefetchable memory behind bridge: fff00000-000fffff
> Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort-
> <TAbort- <MAbort- <SERR- <PERR-
> [virtual] Expansion ROM at 01100000 [disabled] [size=64K]
> BridgeCtl: Parity+ SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
> PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
> Capabilities: [40] Power Management version 3
> Flags: PMEClk- DSI- D1+ D2- AuxCurrent=375mA
> PME(D0+,D1+,D2-,D3hot+,D3cold+)
> Status: D0 PME-Enable- DSel=0 DScale=0 PME-
> Capabilities: [50] MSI: Mask+ 64bit+ Count=1/1 Enable+
> Address: 0000000090000000 Data: 0000
> Masking: 00000000 Pending: 00000000
> Capabilities: [70] Express (v2) Root Port (Slot-), MSI 00
> DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s
> <64ns, L1 <1us
> ExtTag- RBE+ FLReset-
> DevCtl: Report errors: Correctable+ Non-Fatal+ Fatal+
> Unsupported+
> RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop-
> MaxPayload 128 bytes, MaxReadReq 512 bytes
> DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq-
> AuxPwr+ TransPend-
> LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1,
> Latency L0 <1us, L1 <8us
> ClockPM- Surprise- LLActRep+ BwNot-
> LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk-
> ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
> LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train-
> SlotClk+ DLActive- BWMgmt- ABWMgmt-
> RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal-
> PMEIntEna+ CRSVisible-
> RootCap: CRSVisible-
> RootSta: PME ReqID 0000, PMEStatus- PMEPending-
> DevCap2: Completion Timeout: Range ABCD, TimeoutDis+ ARIFwd-
> DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis- ARIFwd-
> LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance-
> SpeedDis-, Selectable De-emphasis: -6dB
> Transmit Margin: Normal Operating Range,
> EnterModifiedCompliance- ComplianceSOS-
> Compliance De-emphasis: -6dB
> LnkSta2: Current De-emphasis Level: -3.5dB
> Capabilities: [100] Advanced Error Reporting
> UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt-
> UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
> UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt-
> UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
> UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt-
> UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
> CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
> CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
> AERCap: First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn-
> Capabilities: [140] Virtual Channel <?>
> Kernel driver in use: pcieport
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v3 1/3] ARM: sun7i/sun6i: irqchip: Add irqchip driver for NMI controller
From: Carlo Caione @ 2014-01-29 13:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140129125818.GO3867@lukather>
On Wed, Jan 29, 2014 at 1:58 PM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
>
> So, to sum things up, what you see is something like:
>
> handle_level_irq
> | device device
> | mask ack handler irq acked unmask
> | | | | | |
> v v v v v v
>
> NMI -> GIC:
> +--------+ +---------------------
> ---------------+ +-----+
>
> PMIC -> NMI:
> +-------------------------+
> ------------+ +-------------
>
> And you get a "rogue" retrigger because the NMI -> GIC level went up
> again.
I'd say something like:
handle_level_irq
| device device
| mask ack handler irq acked unmask
| | | | | |
v v v v v v
NMI -> GIC:
+-----------------------------+
---------------+ +------
PMIC -> NMI:
+-------------------------+
------------+ +-------------
> I'm not exactly sure on how to fix this. Maybe by adding a call to the
> irqchip's ack just before the unmask in irq_finalize_oneshot?
That is exactly what the unmask callback in the NMI controller driver does.
The unmask_irq() in irq_finalize_oneshot() calls the unmask callback
in the driver (sunxi_sc_nmi_ack_and_unmask()) that ACKs the line
before unmasking it again.
Best,
--
Carlo Caione
^ permalink raw reply
* [PATCH] ARM: OMAP2+: add missing ARCH_HAS_OPP
From: Nishanth Menon @ 2014-01-29 13:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389816038-17363-1-git-send-email-nm@ti.com>
Hi Tony,
On 01/15/2014 02:00 PM, Nishanth Menon wrote:
> OMAP5, DRA7, AM43xx all have OPPs. So select the same to allow SoC
> only configuration boot to work with OPP.
>
> Reported-by: Nikhil Devshatwar <nikhil.nd@ti.com>
> Signed-off-by: Nishanth Menon <nm@ti.com>
> ---
>
> For DRA7, depends on: https://patchwork.kernel.org/patch/3465411/
Considering that dependent patch is now on linus master,
a gentle ping -> The patch does apply on latest linus master commit
0e47c969c65e213421450c31043353ebe3c67e0c
patchworks reference: https://patchwork.kernel.org/patch/3493581/
>
> arch/arm/mach-omap2/Kconfig | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
> index 35c23e5..66a9c4a 100644
> --- a/arch/arm/mach-omap2/Kconfig
> +++ b/arch/arm/mach-omap2/Kconfig
> @@ -50,6 +50,7 @@ config SOC_OMAP5
> bool "TI OMAP5"
> depends on ARCH_MULTI_V7
> select ARCH_OMAP2PLUS
> + select ARCH_HAS_OPP
> select ARM_CPU_SUSPEND if PM
> select ARM_GIC
> select CPU_V7
> @@ -63,6 +64,7 @@ config SOC_AM33XX
> bool "TI AM33XX"
> depends on ARCH_MULTI_V7
> select ARCH_OMAP2PLUS
> + select ARCH_HAS_OPP
> select ARM_CPU_SUSPEND if PM
> select CPU_V7
> select MULTI_IRQ_HANDLER
> @@ -72,6 +74,7 @@ config SOC_AM43XX
> depends on ARCH_MULTI_V7
> select CPU_V7
> select ARCH_OMAP2PLUS
> + select ARCH_HAS_OPP
> select MULTI_IRQ_HANDLER
> select ARM_GIC
> select MACH_OMAP_GENERIC
> @@ -80,6 +83,7 @@ config SOC_DRA7XX
> bool "TI DRA7XX"
> depends on ARCH_MULTI_V7
> select ARCH_OMAP2PLUS
> + select ARCH_HAS_OPP
> select ARM_CPU_SUSPEND if PM
> select ARM_GIC
> select CPU_V7
>
--
Regards,
Nishanth Menon
^ permalink raw reply
* [PATCH] ARM: dts: Add basic devices for AM3517-craneboard
From: Nishanth Menon @ 2014-01-29 13:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52DD522E.1070607@ti.com>
On 01/20/2014 10:43 AM, Nishanth Menon wrote:
> Benoit,
>
> On 12/18/2013 11:16 AM, Benoit Cousson wrote:
>> On 18/12/2013 18:02, Nishanth Menon wrote:
>>> On 12/18/2013 10:57 AM, Benoit Cousson wrote:
>>>> On 17/12/2013 20:45, Nishanth Menon wrote:
>>>>> On 12/09/2013 03:55 PM, Nishanth Menon wrote:
>>>>>> Craneboard is a hardware development platform based on the Sitara
>>>>>> AM3517 ARM Cortex - A8 microprocessor device - see [1] for more
>>>>>> details. Add basic devices for craneboard as replacement for the board
>>>>>> file scheduled for removal as part of device tree conversion
>>>>>>
>>>>>> [1] http://craneboard.org
>>>>>>
>>>>>> Signed-off-by: Nishanth Menon <nm@ti.com>
>>>>>> ---
>>>>>
>>>>> gentle ping.. had'nt seen a response on this patch. Could we queue
>>>>> this up for v3.14-rc1?
>>>>
>>>> Yep, it looks good to me.
>>> Thanks benoit.
>>>
>>>> But if you don't mind I'll start pushing my branch after Xmas :-).
>>>
>>> As long as Tony is ok with it, I have no issues either - will be great
>>> to have dt only boot in .14-rc1 though.
>>
>> Good point, it is already -rc4.
>>
>> OK, I'll just queued it and pushed it to for_3.14/dts.
>
> I dont see this in next-20140120 yet - wondering if Tony or you have
> plans for one of .14 rcs OR if this is queued for .15.
gentle ping yet again :(
--
Regards,
Nishanth Menon
^ permalink raw reply
* [PATCH v2 3/5] spi: sunxi: Add Allwinner A31 SPI controller driver
From: Maxime Ripard @ 2014-01-29 13:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140129122520.GY11841@sirena.org.uk>
On Wed, Jan 29, 2014 at 12:25:20PM +0000, Mark Brown wrote:
> On Wed, Jan 29, 2014 at 12:10:48PM +0100, Maxime Ripard wrote:
>
> > +config SPI_SUN6I
> > + tristate "Allwinner A31 SPI controller"
> > + depends on ARCH_SUNXI || COMPILE_TEST
> > + select PM_RUNTIME
> > + help
> > + This enables using the SPI controller on the Allwinner A31 SoCs.
> > +
>
> A select of PM_RUNTIME is both surprising and odd - why is that there?
> The usual idiom is that the device starts out powered up (flagged using
> pm_runtime_set_active()) and then runtime PM then suspends it when it's
> compiled in. That way if for some reason people want to avoid runtime
> PM they can still use the device.
Since pm_runtime_set_active and all the pm_runtime* callbacks in
general are defined to pretty much empty functions, how the
suspend/resume callbacks are called then? Obviously, we need them to
be run, hence why I added the select here, but now I'm seeing a
construct like what's following acceptable then?
pm_runtime_enable(&pdev->dev);
if (!pm_runtime_enabled(&pdev->dev))
sun6i_spi_runtime_resume(&pdev->dev);
> > +static void sun6i_spi_set_cs(struct spi_device *spi, bool enable)
> > +{
> > + struct sun6i_spi *sspi = spi_master_get_devdata(spi->master);
> > + u32 reg;
> > +
> > + if (!enable)
> > + return;
> > +
> > + reg = sun6i_spi_read(sspi, SUN6I_TFR_CTL_REG);
> > + reg &= ~SUN6I_TFR_CTL_CS_MASK;
> > + reg |= SUN6I_TFR_CTL_CS(spi->chip_select);
> > + sun6i_spi_write(sspi, SUN6I_TFR_CTL_REG, reg);
> > +}
>
> The !enable means that it'll only ever be able to go one way. Also note
> that the documentation was clarified here to make the enable flag be the
> absolute logic level, not if chip select was asserted.
Actually the IP asserts the CS automatically, the only thing you need
to do is to set which CS to use for your next transfer in some
register (which is what I'm doing after the !enable), and the CS will
be managed directly by the controller. Hence, there's no way to say
wether you want to enable it or not.
The controller allows to control the CS manually also, if that's the
preferred way of doing things.
> > + timeout = wait_for_completion_timeout(&sspi->done,
> > + msecs_to_jiffies(1000));
> > + if (!timeout) {
> > + ret = -ETIMEDOUT;
> > + goto out;
> > + }
> > +
> > + sun6i_spi_drain_fifo(sspi, SUN6I_FIFO_DEPTH);
>
> This means we can only transfer a single FIFO of data? I didn't see a
> check on the transfer length.
At the moment, indeed. And that's the first thing I check in the
transfer_one function.
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140129/f8b2b915/attachment-0001.sig>
^ permalink raw reply
* [PATCH v3] ARM: hw_breakpoint: Add ARMv8 support
From: Christopher Covington @ 2014-01-29 14:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140129105722.GD26622@mudshark.cambridge.arm.com>
Hi Will,
On 01/29/2014 05:57 AM, Will Deacon wrote:
> Hi Christopher,
>
> On Tue, Jan 28, 2014 at 06:51:51PM +0000, Christopher Covington wrote:
>> Add the trivial support necessary to get hardware breakpoints
>> working for GDB on ARMv8 simulators running in AArch32 mode.
>>
>> Acked-by: Will Deacon <will.deacon@arm.com>
>> Signed-off-by: Christopher Covington <cov@codeaurora.org>
>> ---
>>
>> v3: assume for now that ARMv9 and later will update FSR
>
> Please can you stick this into the patch system? I don't have any other
> hw_breakpoint changes queued, so I doubt I'll send a pull for 3.15.
Thanks for your review. Sounds good; will do.
Regards,
Christopher
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by the Linux Foundation.
^ permalink raw reply
* [PATCH] ARM: iop32x: fix reset handling for the EM7210 board
From: Linus Walleij @ 2014-01-29 14:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87txcneyi6.fsf@lebrac.rtp-net.org>
On Wed, Jan 29, 2014 at 1:57 PM, Arnaud Patard
<arnaud.patard@rtp-net.org> wrote:
> Linus Walleij <linus.walleij@linaro.org> writes:
>
> don't know how to comment about the subjet but it's _not_ about
> resetting the board but about powering it off.
Aha sorry I'll respin with updated text.
>> register_iop32x_gpio();
>> platform_device_register(&em7210_serial_device);
>> platform_device_register(&iop3xx_i2c0_device);
>> @@ -194,7 +202,9 @@ static void __init em7210_init_machine(void)
>>
>> i2c_register_board_info(0, em7210_i2c_devices,
>> ARRAY_SIZE(em7210_i2c_devices));
>> -
>> + ret = gpio_request(EM7210_HARDWARE_RESET, "reset");
>> + if (ret)
>> + pr_err("could not request reset GPIO\n");
>
> no chance to work. too early. you'll get a -EPROBE_DEFER.
Yeah that's right, I remember now that I added a separate
device_initcall() on the N2100 for this. Thanks, I'll respin that.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v3 02/11] iommu/arm-smmu: Introduce iommu_group notifier block
From: Andreas Herrmann @ 2014-01-29 14:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <991cc0024ea54cdb964f31de89c0b0ea@BL2PR03MB468.namprd03.prod.outlook.com>
On Tue, Jan 28, 2014 at 11:00:35AM +0000, Varun Sethi wrote:
>
>
> > -----Original Message-----
> > From: iommu-bounces at lists.linux-foundation.org [mailto:iommu-
> > bounces at lists.linux-foundation.org] On Behalf Of Andreas Herrmann
> > Sent: Friday, January 24, 2014 1:27 AM
> > To: Sethi Varun-B16395
> > Cc: Andreas Herrmann; iommu at lists.linux-foundation.org; Will Deacon;
> > linux-arm-kernel at lists.infradead.org
> > Subject: Re: [PATCH v3 02/11] iommu/arm-smmu: Introduce iommu_group
> > notifier block
> >
> > On Wed, Jan 22, 2014 at 07:07:40PM +0000, Varun Sethi wrote:
> > > > -----Original Message-----
> > > > From: Will Deacon [mailto:will.deacon at arm.com]
> > > > Sent: Wednesday, January 22, 2014 9:04 PM
> > > > To: Sethi Varun-B16395
> > > > Cc: Andreas Herrmann; iommu at lists.linux-foundation.org; linux-arm-
> > > > kernel at lists.infradead.org; Andreas Herrmann
> > > > Subject: Re: [PATCH v3 02/11] iommu/arm-smmu: Introduce iommu_group
> > > > notifier block
> > > >
> > > > On Wed, Jan 22, 2014 at 01:54:11PM +0000, Varun Sethi wrote:
> > > > > > > > Ok, so are you suggesting that we perform the isolation
> > > > > > > > mapping in arm_smmu_add_device and drop the notifier
> > altogether?
> > > > > > > I think that should be fine, until we want to delay mapping
> > > > > > > creation till driver bind time.
> > > > > >
> > > > > > Is there a hard dependency on that?
> > > > > >
> > > > > Not sure, may be Andreas can answer that.
> > > >
> > > > Ok. Andreas? I would have thought doing this *earlier* shouldn't be
> > > > a problem (the DMA ops must be swizzled before the driver is probed).
> > > >
> > > > > > > But the "isolate device" property should dictate iommu group
> > > > creation.
> > > > > >
> > > > > > The reason we added automatic group creation (per-device) is for
> > > > > > VFIO, which expects all devices to be in a group regardless of
> > > > > > the device isolation configuration.
> > > > > >
> > > > > IIUC, with the "isolate devices" property we ensure that there
> > > > > would be independent SMR and S2CR per device. Is that correct?
> > > >
> > > > Yes, as part of giving them independent sets of page tables.
> > > > Initially these tables don't have any valid mappings, but the
> > > > dma-mapping API will populate them in response to
> > dma_map_*/dma_alloc/etc.
> > > >
> > > > Not sure what this has to do with us putting devices into their own
> > > > groups...
> >
> > > [Sethi Varun-B16395] Devices in an iommu group would share the dma
> > > mapping, so shouldn't they be sharing the SMR and context registers?
> >
> > I aggree with the context but SMRs won't be shared. I think you just can
> > say that a certain subset of the available SMRs will be used to map all
> > devices in an iommu group to the same context. Depending on what
> > streamIDs each device has you might have to use separate SMRs for each
> > device to map it to the same context.
> [Sethi Varun-B16395] IIUC the SMRs would unique per device, but
> there is a possibility where the number of context registers are
> restricted? In that case IOMMU groups should correspond to unique
> stream IDs (and corresponding SMRs).
> > > In case of the "isolate devices" property, each device would have its
> > > own SMR and context registers, thus allowing the devices to have
> > > independent mappings and allowing them to fall in separate iommu
> > > groups.
> >
> > I aggree with Varun's view here. (Now that I take iommu groups into
> > consideration.)
> >
> > But my goal with the "isolate devices" thing was twofold:
> >
> > 1. actual make use of SMMU for address translation for all master
> > devices (instead of just bypassing the SMMU)
> [Sethi Varun-B16395] even if masters have to share translation? But
> from the patch it seemed that we are creating mapping only if we
> find the isolate devices property.
Yes, the patch creates mappings only if isolate-devices property is
given. Currently there is no trigger to create a common mapping for
all devices attached to the same SMMU.
> > plus
> >
> > 2. put each master into it's own domain to isolate it
> >
> > The latter matches usage of separate iommu groups for devices. If we now
> > use the isolate devices property to just control whether master devices
> > fall into the same or separate iommu groups it seems to me we would need
> > to have another mechanism that triggers the creation of a mapping for a
> > group.
> >
> > What do you think?
> >
> [Sethi Varun-B16395] As mentioned before, we should be having iommu
> group per device (having a unique stream id). Isolate devices
> property just ensures that each device has a unique context. Now,
> for the devices for which we don't have the isolate device property,
> can't we have the multiple devices point to a common mapping.
Hmm, the isolate-devices option is per SMMU. So if this is set for an
SMMU the driver tries to create a mapping per device. (And this is
done for all master devices of this SMMU.)
Are you requesting to change the default behaviour of the driver to
create a shared mapping in case the isolate-devices property is not
specified in DT for an SMMU node?
Or maybe your concern is that you have x master devices for an SMMU
which support y number of contexts and x > y? Which would imply that
not all devices can be isolated and some need to share a context?
Andreas
^ permalink raw reply
* [PATCH v2] ARM: iop32x: fix power off handling for the EM7210 board
From: Linus Walleij @ 2014-01-29 14:20 UTC (permalink / raw)
To: linux-arm-kernel
This board was missed when converting all the others to proper
abstracted GPIO handling. Fix it up the right way by requesting
and driving GPIO line 0 high through gpiolib to power off the
machine.
Cc: Arnaud Patard <arnaud.patard@rtp-net.org>
Reported-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
ChangeLog v1->v2:
- Request the power off and set the power off hook with a
device_initcall() so we know the GPIO driver is available
when requesting the line.
- Refer to POWER OFF rather than RESET everywhere.
ARM SoC folks, if you're happy with this fix, please apply it
directly to fixes in the ARM SoC tree.
---
arch/arm/mach-iop32x/em7210.c | 32 +++++++++++++++++++++++++++-----
1 file changed, 27 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-iop32x/em7210.c b/arch/arm/mach-iop32x/em7210.c
index 177cd073a83b..77e1ff057303 100644
--- a/arch/arm/mach-iop32x/em7210.c
+++ b/arch/arm/mach-iop32x/em7210.c
@@ -23,6 +23,7 @@
#include <linux/mtd/physmap.h>
#include <linux/platform_device.h>
#include <linux/i2c.h>
+#include <linux/gpio.h>
#include <mach/hardware.h>
#include <linux/io.h>
#include <linux/irq.h>
@@ -176,11 +177,35 @@ static struct platform_device em7210_serial_device = {
.resource = &em7210_uart_resource,
};
+#define EM7210_HARDWARE_POWER 0
+
void em7210_power_off(void)
{
- *IOP3XX_GPOE &= 0xfe;
- *IOP3XX_GPOD |= 0x01;
+ int ret;
+
+ ret = gpio_direction_output(EM7210_HARDWARE_POWER, 1);
+ if (ret)
+ pr_crit("could not drive power off GPIO high\n");
+}
+
+static int __init em7210_request_gpios(void)
+{
+ int ret;
+
+ if (!machine_is_em7210())
+ return 0;
+
+ ret = gpio_request(EM7210_HARDWARE_POWER, "power");
+ if (ret) {
+ pr_err("could not request power off GPIO\n");
+ return 0;
+ }
+
+ pm_power_off = em7210_power_off;
+
+ return 0;
}
+device_initcall(em7210_request_gpios);
static void __init em7210_init_machine(void)
{
@@ -194,9 +219,6 @@ static void __init em7210_init_machine(void)
i2c_register_board_info(0, em7210_i2c_devices,
ARRAY_SIZE(em7210_i2c_devices));
-
-
- pm_power_off = em7210_power_off;
}
MACHINE_START(EM7210, "Lanner EM7210")
--
1.8.5.3
^ permalink raw reply related
* [RFC] arm: vdso: Convert sigpage to vdso implementation
From: Steve Capper @ 2014-01-29 14:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140128171015.GM15937@n2100.arm.linux.org.uk>
On Tue, Jan 26, 2014 at 05:10:15PM +0000, Russell King - ARM Linux wrote:
> On Tue, Jan 28, 2014 at 04:25:08PM +0000, Steve Capper wrote:
> > ARM has a special sigpage that is used for signal return trampolines.
> > Its implementation is very similar to a VDSO conceptually in that it
> > occupies a special mapping in user address space.
> >
> > One could actually host the trampoline code in a VDSO instead with the
> > added advantage that one could also host specialised routines there.
> > One such routine could be gettimeofday where on ARM we have architected
> > (and some vendor supplied) timers that can be queried entirely in
> > userspace, obviating the need for an expensive syscall.
> >
> > This patch converts the sigpage implementation to a VDSO. It is mostly
> > a direct port from Will Deacon's arm64 implementation with the ARM
> > signal trampoline plumbed in.
> >
> > Signed-off-by: Steve Capper <steve.capper@linaro.org>
> > ---
> > As can be inferred from this RFC, I am interested ultimately in
> > implementing a syscall-less gettimeofday for ARM. Whilst researching
> > possible vectors page or VDSO implementations, I came across the
> > sigpage mechanism which is very similar to a VDSO.
> >
> > The very simple function, __kernel_vdso_doubler, resolved in a test
> > program automatically on my Arndale board (running Fedora 20) without
> > any additional prodding.
> >
> > IPC stress tests from LTP were executed to test the signal trampoline.
> >
> > I would appreciate any comments on this approach of converting the
> > sigpage to a VDSO. If this looks sane to people, I will work on the
> > gettimeofday logic in a later patch.
>
> I'm not happy with this removing much of the work I pushed into the
> kernel to work around the security issues which were identified with
> the fixed-address placement of stuff in the vectors page. Particularly
> the random placement of the signal return stubs within the new signal
> page is gone with the VDSO approach, which means if someone can discover
> the VDSO page, they can issue any system call they please by knowing
> the appropriate offset into the page to call.
Hi Russell,
I didn't mean to undo you work.
Essentially I saw the sigpage was so close to being a vdso, it just
needed a little nudge to contain other code too.
>
> While the VDSO page will be placed randomly, I'd also like to have the
> signal handlers placed randomly within that page as well - there's no
> need for them to be at a fixed offset. The only thing which needs to
> know where they are after all is the kernel.
I was considering a larger segment containing the trampoline at random
offset, but came to the conclusion that the VA randomisation of the
vdso page location was in itself sufficient?
>
> I'm not sure about putting gettimeofday() into this - gettimeofday()
> would need to have various kernel variables exported into userspace
> for the VDSO page to then compute the current time of day from the
> timer value(s), and that's certainly not going to be at a fixed
> address.
I believe a vdso data page could house the variables, the offsets
within the page could be fixed at compile time.
>
> I believe x86 eventually ended up going down the path of trapping and
> emulating calls to the VDSO page because VDSO became too much of a
> problem (though I think it does provide the option for having it back
> but not by default.)
Cheers,
--
Steve
^ permalink raw reply
* [PATCH] ARM: iop32x: fix reset handling for the EM7210 board
From: Arnd Bergmann @ 2014-01-29 14:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390999545-31428-1-git-send-email-linus.walleij@linaro.org>
On Wednesday 29 January 2014, Linus Walleij wrote:
> This board was missed when converting all the others to proper
> abstracted GPIO handling. Fix it up the right way by requesting
> and driving GPIO line 0 high through gpiolib to reset the machine.
>
> Reported-by: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Thanks for the prompt resolution. Aside from what Arnaud mentioned,
Acked-by: Arnd Bergmann <arnd@arndb.de>
^ permalink raw reply
* [RFC PATCH v2 00/14] mtd: nand: add sunxi NAND Flash Controller support
From: Boris BREZILLON @ 2014-01-29 14:34 UTC (permalink / raw)
To: linux-arm-kernel
Hello,
This series adds support for the sunxi NAND Flash Controller (NFC).
This controller supports up to 8 NAND chip connected.
I'm still in the early stages drivers development and some key features are
missing, but it's usable (I tested it on the cubietruck board).
Here's what's missing:
- DMA support
- HW randomization support
- other improvements ?
This series depends on Emilio's patch series implementing mod0 clks
(http://lists.infradead.org/pipermail/linux-arm-kernel/2013-July/185478.html)
+ an other patch not yet posted
(http://git.elopez.com.ar/linux/commits/5b4eb3ac406b9c98965714d40e8dd6da943d1ab0)
Best Regards,
Boris
Changes since v1:
- add HW ECC support
- rework NAND timings retrieval (use ONFI timing mode instead of raw timings)
- add nand-ecc-level property to specify NAND ECC requirements from DT
Boris BREZILLON (14):
mtd: nand: retrieve ECC requirements from Hynix READ ID byte 4
of: mtd: add NAND ECC level requirements retrieval
of: mtd: add documentation for nand-ecc-level property
mtd: nand: define struct nand_timings
mtd: nand: add ONFI timing mode to nand_timings converter
of: mtd: add NAND timing mode retrieval support
of: mtd: add documentation for the ONFI NAND timing mode property
mtd: nand: add sunxi NAND flash controller support
mtd: nand: add sunxi NFC dt bindings doc
ARM: dt/sunxi: add NFC node to Allwinner A20 SoC
ARM: dt/sunxi: add NFC pinctrl pin definitions
ARM: sunxi/dt: enable NAND on cubietruck board
mtd: nand: add sunxi HW ECC support
ARM: sunxi/dt: enable HW ECC on cubietruck board
Documentation/devicetree/bindings/mtd/nand.txt | 8 +
.../devicetree/bindings/mtd/sunxi-nand.txt | 46 +
arch/arm/boot/dts/sun7i-a20-cubietruck.dts | 31 +
arch/arm/boot/dts/sun7i-a20.dtsi | 35 +
drivers/mtd/nand/Kconfig | 6 +
drivers/mtd/nand/Makefile | 3 +-
drivers/mtd/nand/nand_base.c | 37 +
drivers/mtd/nand/nand_timings.c | 248 +++++
drivers/mtd/nand/sunxi_nand.c | 997 ++++++++++++++++++++
drivers/of/of_mtd.c | 44 +
include/linux/mtd/nand.h | 53 ++
include/linux/of_mtd.h | 15 +
12 files changed, 1522 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/mtd/sunxi-nand.txt
create mode 100644 drivers/mtd/nand/nand_timings.c
create mode 100644 drivers/mtd/nand/sunxi_nand.c
--
1.7.9.5
^ permalink raw reply
* [RFC PATCH v2 01/14] mtd: nand: retrieve ECC requirements from Hynix READ ID byte 4
From: Boris BREZILLON @ 2014-01-29 14:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391006064-28890-1-git-send-email-b.brezillon.dev@gmail.com>
The Hynix nand flashes store their ECC requirements in byte 4 of its id
(returned on READ ID command).
Signed-off-by: Boris BREZILLON <b.brezillon.dev@gmail.com>
---
drivers/mtd/nand/nand_base.c | 37 +++++++++++++++++++++++++++++++++++++
1 file changed, 37 insertions(+)
diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index bd39f7b..15069ec 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -3202,6 +3202,43 @@ static void nand_decode_ext_id(struct mtd_info *mtd, struct nand_chip *chip,
else
mtd->erasesize = (64 * 1024) << tmp;
*busw = 0;
+
+ /* Retrieve ECC infos */
+ switch ((id_data[4] >> 4) & 0x7) {
+ case 1:
+ chip->ecc_step_ds = 512;
+ chip->ecc_strength_ds = 1;
+ break;
+ case 2:
+ chip->ecc_step_ds = 512;
+ chip->ecc_strength_ds = 2;
+ break;
+ case 3:
+ chip->ecc_step_ds = 512;
+ chip->ecc_strength_ds = 4;
+ break;
+ case 4:
+ chip->ecc_step_ds = 512;
+ chip->ecc_strength_ds = 8;
+ break;
+ case 5:
+ chip->ecc_step_ds = 1024;
+ chip->ecc_strength_ds = 24;
+ break;
+ case 6:
+ chip->ecc_step_ds = 1024;
+ chip->ecc_strength_ds = 32;
+ break;
+ case 7:
+ chip->ecc_step_ds = 1024;
+ chip->ecc_strength_ds = 40;
+ break;
+ case 0:
+ default:
+ chip->ecc_step_ds = 0;
+ chip->ecc_strength_ds = 0;
+ break;
+ }
} else {
/* Calc pagesize */
mtd->writesize = 1024 << (extid & 0x03);
--
1.7.9.5
^ permalink raw reply related
* [RFC PATCH v2 02/14] of: mtd: add NAND ECC level requirements retrieval
From: Boris BREZILLON @ 2014-01-29 14:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391006064-28890-1-git-send-email-b.brezillon.dev@gmail.com>
Some chip do not support automatic retrieval of ECC level requirements.
Provide an helper function to retrieve these requirements from DT.
Signed-off-by: Boris BREZILLON <b.brezillon.dev@gmail.com>
---
drivers/of/of_mtd.c | 25 +++++++++++++++++++++++++
include/linux/of_mtd.h | 7 +++++++
2 files changed, 32 insertions(+)
diff --git a/drivers/of/of_mtd.c b/drivers/of/of_mtd.c
index a27ec94..e8ced61 100644
--- a/drivers/of/of_mtd.c
+++ b/drivers/of/of_mtd.c
@@ -50,6 +50,31 @@ int of_get_nand_ecc_mode(struct device_node *np)
EXPORT_SYMBOL_GPL(of_get_nand_ecc_mode);
/**
+ * of_get_nand_ecc_level - Get nand ecc level for the given device_node
+ * @np: Pointer to the given device_node
+ * @strengh: ECC strength
+ * @blk_size: ECC block size
+ *
+ * The function gets ecc level requirements from property 'nand-ecc-level'.
+ * Return 0 on success, -errno otherwise.
+ */
+int of_get_nand_ecc_level(struct device_node *np, u32 *strengh, u32 *blk_size)
+{
+ int err;
+
+ err = of_property_read_u32_index(np, "nand-ecc-level", 0, strengh);
+ if (err < 0)
+ return err;
+
+ err = of_property_read_u32_index(np, "nand-ecc-level", 1, blk_size);
+ if (err < 0)
+ return err;
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(of_get_nand_ecc_level);
+
+/**
* of_get_nand_bus_width - Get nand bus witdh for given device_node
* @np: Pointer to the given device_node
*
diff --git a/include/linux/of_mtd.h b/include/linux/of_mtd.h
index 6f10e93..3bd8c3b 100644
--- a/include/linux/of_mtd.h
+++ b/include/linux/of_mtd.h
@@ -13,6 +13,7 @@
#include <linux/of.h>
int of_get_nand_ecc_mode(struct device_node *np);
+int of_get_nand_ecc_level(struct device_node *np, u32 *strengh, u32 *blk_size);
int of_get_nand_bus_width(struct device_node *np);
bool of_get_nand_on_flash_bbt(struct device_node *np);
@@ -23,6 +24,12 @@ static inline int of_get_nand_ecc_mode(struct device_node *np)
return -ENOSYS;
}
+static inline int of_get_nand_ecc_level(struct device_node *np, u32 *strengh,
+ u32 *blk_size)
+{
+ return -ENOSYS;
+}
+
static inline int of_get_nand_bus_width(struct device_node *np)
{
return -ENOSYS;
--
1.7.9.5
^ permalink raw reply related
* [RFC PATCH v2 03/14] of: mtd: add documentation for nand-ecc-level property
From: Boris BREZILLON @ 2014-01-29 14:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391006064-28890-1-git-send-email-b.brezillon.dev@gmail.com>
nand-ecc-level property statically defines NAND chip's ECC requirements.
Signed-off-by: Boris BREZILLON <b.brezillon.dev@gmail.com>
---
Documentation/devicetree/bindings/mtd/nand.txt | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/mtd/nand.txt b/Documentation/devicetree/bindings/mtd/nand.txt
index 03855c8..0c962296 100644
--- a/Documentation/devicetree/bindings/mtd/nand.txt
+++ b/Documentation/devicetree/bindings/mtd/nand.txt
@@ -3,5 +3,8 @@
- nand-ecc-mode : String, operation mode of the NAND ecc mode.
Supported values are: "none", "soft", "hw", "hw_syndrome", "hw_oob_first",
"soft_bch".
+- nand-ecc-level : Two cells property defining the ECC level requirements.
+ The first cell represent the strength and the second cell the ECC block size.
+ E.g. : nand-ecc-level = <4 512>; /* 4 bits / 512 bytes */
- nand-bus-width : 8 or 16 bus width if not present 8
- nand-on-flash-bbt: boolean to enable on flash bbt option if not present false
--
1.7.9.5
^ permalink raw reply related
* [RFC PATCH v2 04/14] mtd: nand: define struct nand_timings
From: Boris BREZILLON @ 2014-01-29 14:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391006064-28890-1-git-send-email-b.brezillon.dev@gmail.com>
Define a struct containing the standard NAND timings as described in NAND
datasheets.
Signed-off-by: Boris BREZILLON <b.brezillon.dev@gmail.com>
---
include/linux/mtd/nand.h | 49 ++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 49 insertions(+)
diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h
index 9e6c8f9..67f0829 100644
--- a/include/linux/mtd/nand.h
+++ b/include/linux/mtd/nand.h
@@ -805,4 +805,53 @@ static inline bool nand_is_slc(struct nand_chip *chip)
{
return chip->bits_per_cell == 1;
}
+
+/**
+ * struct nand_sdr_timings - SDR NAND chip timings
+ *
+ * This struct defines the timing requirements of a SDR NAND chip.
+ * These informations can be found in every NAND datasheets and the timings
+ * meaning are described in the ONFI specifications:
+ * www.onfi.org/~/media/ONFI/specs/onfi_3_1_spec.pdf? (chapter 4.15 Timing
+ * Parameters)
+ *
+ */
+
+struct nand_sdr_timings {
+ u32 tALH_min;
+ u32 tADL_min;
+ u32 tALS_min;
+ u32 tAR_min;
+ u32 tCEA_max;
+ u32 tCEH_min;
+ u32 tCH_min;
+ u32 tCHZ_max;
+ u32 tCLH_min;
+ u32 tCLR_min;
+ u32 tCLS_min;
+ u32 tCOH_min;
+ u32 tCS_min;
+ u32 tDH_min;
+ u32 tDS_min;
+ u32 tFEAT_max;
+ u32 tIR_min;
+ u32 tITC_max;
+ u32 tRC_min;
+ u32 tREA_max;
+ u32 tREH_min;
+ u32 tRHOH_min;
+ u32 tRHW_min;
+ u32 tRHZ_max;
+ u32 tRLOH_min;
+ u32 tRP_min;
+ u32 tRR_min;
+ u64 tRST_max;
+ u32 tWB_max;
+ u32 tWC_min;
+ u32 tWH_min;
+ u32 tWHR_min;
+ u32 tWP_min;
+ u32 tWW_min;
+};
+
#endif /* __LINUX_MTD_NAND_H */
--
1.7.9.5
^ permalink raw reply related
* [RFC PATCH v2 05/14] mtd: nand: add ONFI timing mode to nand_timings converter
From: Boris BREZILLON @ 2014-01-29 14:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391006064-28890-1-git-send-email-b.brezillon.dev@gmail.com>
Add a converter to retrieve NAND timings from an ONFI NAND timing mode.
This only support SDR NAND timings for now.
Signed-off-by: Boris BREZILLON <b.brezillon.dev@gmail.com>
---
drivers/mtd/nand/Makefile | 2 +-
drivers/mtd/nand/nand_timings.c | 248 +++++++++++++++++++++++++++++++++++++++
include/linux/mtd/nand.h | 4 +
3 files changed, 253 insertions(+), 1 deletion(-)
create mode 100644 drivers/mtd/nand/nand_timings.c
diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile
index 542b568..bbea7a6 100644
--- a/drivers/mtd/nand/Makefile
+++ b/drivers/mtd/nand/Makefile
@@ -2,7 +2,7 @@
# linux/drivers/nand/Makefile
#
-obj-$(CONFIG_MTD_NAND) += nand.o
+obj-$(CONFIG_MTD_NAND) += nand.o nand_timings.o
obj-$(CONFIG_MTD_NAND_ECC) += nand_ecc.o
obj-$(CONFIG_MTD_NAND_BCH) += nand_bch.o
obj-$(CONFIG_MTD_NAND_IDS) += nand_ids.o
diff --git a/drivers/mtd/nand/nand_timings.c b/drivers/mtd/nand/nand_timings.c
new file mode 100644
index 0000000..f66fe95
--- /dev/null
+++ b/drivers/mtd/nand/nand_timings.c
@@ -0,0 +1,248 @@
+/*
+ * Copyright (C) 2014 Boris BREZILLON <b.brezillon.dev@gmail.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+#include <linux/mtd/nand.h>
+
+static const struct nand_sdr_timings onfi_sdr_timings[] = {
+ /* Mode 0 */
+ {
+ .tADL_min = 200000,
+ .tALH_min = 20000,
+ .tALS_min = 50000,
+ .tAR_min = 25000,
+ .tCEA_max = 100000,
+ .tCEH_min = 20000,
+ .tCH_min = 20000,
+ .tCHZ_max = 100000,
+ .tCLH_min = 20000,
+ .tCLR_min = 20000,
+ .tCLS_min = 50000,
+ .tCOH_min = 0,
+ .tCS_min = 70000,
+ .tDH_min = 20000,
+ .tDS_min = 40000,
+ .tFEAT_max = 1000000,
+ .tIR_min = 10000,
+ .tITC_max = 1000000,
+ .tRC_min = 100000,
+ .tREA_max = 40000,
+ .tREH_min = 30000,
+ .tRHOH_min = 0,
+ .tRHW_min = 200000,
+ .tRHZ_max = 200000,
+ .tRLOH_min = 0,
+ .tRP_min = 50000,
+ .tRST_max = 250000000000,
+ .tWB_max = 200000,
+ .tRR_min = 40000,
+ .tWC_min = 100000,
+ .tWH_min = 30000,
+ .tWHR_min = 120000,
+ .tWP_min = 50000,
+ .tWW_min = 100000,
+ },
+ /* Mode 1 */
+ {
+ .tADL_min = 100000,
+ .tALH_min = 10000,
+ .tALS_min = 25000,
+ .tAR_min = 10000,
+ .tCEA_max = 45000,
+ .tCEH_min = 20000,
+ .tCH_min = 10000,
+ .tCHZ_max = 50000,
+ .tCLH_min = 10000,
+ .tCLR_min = 10000,
+ .tCLS_min = 25000,
+ .tCOH_min = 15000,
+ .tCS_min = 35000,
+ .tDH_min = 10000,
+ .tDS_min = 20000,
+ .tFEAT_max = 1000000,
+ .tIR_min = 0,
+ .tITC_max = 1000000,
+ .tRC_min = 50000,
+ .tREA_max = 30000,
+ .tREH_min = 15000,
+ .tRHOH_min = 15000,
+ .tRHW_min = 100000,
+ .tRHZ_max = 100000,
+ .tRLOH_min = 0,
+ .tRP_min = 25000,
+ .tRR_min = 20000,
+ .tRST_max = 500000000,
+ .tWB_max = 100000,
+ .tWC_min = 45000,
+ .tWH_min = 15000,
+ .tWHR_min = 80000,
+ .tWP_min = 25000,
+ .tWW_min = 100000,
+ },
+ /* Mode 2 */
+ {
+ .tADL_min = 100000,
+ .tALH_min = 10000,
+ .tALS_min = 15000,
+ .tAR_min = 10000,
+ .tCEA_max = 30000,
+ .tCEH_min = 20000,
+ .tCH_min = 10000,
+ .tCHZ_max = 50000,
+ .tCLH_min = 10000,
+ .tCLR_min = 10000,
+ .tCLS_min = 15000,
+ .tCOH_min = 15000,
+ .tCS_min = 25000,
+ .tDH_min = 5000,
+ .tDS_min = 15000,
+ .tFEAT_max = 1000000,
+ .tIR_min = 0,
+ .tITC_max = 1000000,
+ .tRC_min = 35000,
+ .tREA_max = 25000,
+ .tREH_min = 15000,
+ .tRHOH_min = 15000,
+ .tRHW_min = 100000,
+ .tRHZ_max = 100000,
+ .tRLOH_min = 0,
+ .tRR_min = 20000,
+ .tRST_max = 500000000,
+ .tWB_max = 100000,
+ .tRP_min = 17000,
+ .tWC_min = 35000,
+ .tWH_min = 15000,
+ .tWHR_min = 80000,
+ .tWP_min = 17000,
+ .tWW_min = 100000,
+ },
+ /* Mode 3 */
+ {
+ .tADL_min = 100000,
+ .tALH_min = 5000,
+ .tALS_min = 10000,
+ .tAR_min = 10000,
+ .tCEA_max = 25000,
+ .tCEH_min = 20000,
+ .tCH_min = 5000,
+ .tCHZ_max = 50000,
+ .tCLH_min = 5000,
+ .tCLR_min = 10000,
+ .tCLS_min = 10000,
+ .tCOH_min = 15000,
+ .tCS_min = 25000,
+ .tDH_min = 5000,
+ .tDS_min = 10000,
+ .tFEAT_max = 1000000,
+ .tIR_min = 0,
+ .tITC_max = 1000000,
+ .tRC_min = 30000,
+ .tREA_max = 20000,
+ .tREH_min = 10000,
+ .tRHOH_min = 15000,
+ .tRHW_min = 100000,
+ .tRHZ_max = 100000,
+ .tRLOH_min = 0,
+ .tRP_min = 15000,
+ .tRR_min = 20000,
+ .tRST_max = 500000000,
+ .tWB_max = 100000,
+ .tWC_min = 30000,
+ .tWH_min = 10000,
+ .tWHR_min = 80000,
+ .tWP_min = 15000,
+ .tWW_min = 100000,
+ },
+ /* Mode 4 */
+ {
+ .tADL_min = 70000,
+ .tALH_min = 5000,
+ .tALS_min = 10000,
+ .tAR_min = 10000,
+ .tCEA_max = 25000,
+ .tCEH_min = 20000,
+ .tCH_min = 5000,
+ .tCHZ_max = 30000,
+ .tCLH_min = 5000,
+ .tCLR_min = 10000,
+ .tCLS_min = 10000,
+ .tCOH_min = 15000,
+ .tCS_min = 20000,
+ .tDH_min = 5000,
+ .tDS_min = 10000,
+ .tFEAT_max = 1000000,
+ .tIR_min = 0,
+ .tITC_max = 1000000,
+ .tRC_min = 25000,
+ .tREA_max = 20000,
+ .tREH_min = 10000,
+ .tRHOH_min = 15000,
+ .tRHW_min = 100000,
+ .tRHZ_max = 100000,
+ .tRLOH_min = 5000,
+ .tRP_min = 12000,
+ .tRR_min = 20000,
+ .tRST_max = 500000000,
+ .tWB_max = 100000,
+ .tWC_min = 25000,
+ .tWH_min = 10000,
+ .tWHR_min = 80000,
+ .tWP_min = 12000,
+ .tWW_min = 100000,
+ },
+ /* Mode 5 */
+ {
+ .tADL_min = 70000,
+ .tALH_min = 5000,
+ .tALS_min = 10000,
+ .tAR_min = 10000,
+ .tCEA_max = 25000,
+ .tCEH_min = 20000,
+ .tCH_min = 5000,
+ .tCHZ_max = 30000,
+ .tCLH_min = 5000,
+ .tCLR_min = 10000,
+ .tCLS_min = 10000,
+ .tCOH_min = 15000,
+ .tCS_min = 15000,
+ .tDH_min = 5000,
+ .tDS_min = 7000,
+ .tFEAT_max = 1000000,
+ .tIR_min = 0,
+ .tITC_max = 1000000,
+ .tRC_min = 20000,
+ .tREA_max = 16000,
+ .tREH_min = 7000,
+ .tRHOH_min = 15000,
+ .tRHW_min = 100000,
+ .tRHZ_max = 100000,
+ .tRLOH_min = 5000,
+ .tRP_min = 10000,
+ .tRR_min = 20000,
+ .tRST_max = 500000000,
+ .tWB_max = 100000,
+ .tWC_min = 20000,
+ .tWH_min = 7000,
+ .tWHR_min = 80000,
+ .tWP_min = 10000,
+ .tWW_min = 100000,
+ },
+};
+
+/**
+ * onfi_async_timing_mode_to_sdr_timings - [NAND Interface] Retrieve NAND
+ * timings according to the given ONFI timing mode
+ * @mode: ONFI timing mode
+ */
+const struct nand_sdr_timings *onfi_async_timing_mode_to_sdr_timings(int mode)
+{
+ if (mode < 0 || mode > ARRAY_SIZE(onfi_sdr_timings))
+ return ERR_PTR(-EINVAL);
+
+ return &onfi_sdr_timings[mode];
+}
+EXPORT_SYMBOL(onfi_async_timing_mode_to_sdr_timings);
diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h
index 67f0829..c70e0a3 100644
--- a/include/linux/mtd/nand.h
+++ b/include/linux/mtd/nand.h
@@ -806,6 +806,7 @@ static inline bool nand_is_slc(struct nand_chip *chip)
return chip->bits_per_cell == 1;
}
+
/**
* struct nand_sdr_timings - SDR NAND chip timings
*
@@ -854,4 +855,7 @@ struct nand_sdr_timings {
u32 tWW_min;
};
+/* convert an ONFI timing mode to its timing characteristics. */
+const struct nand_sdr_timings *onfi_async_timing_mode_to_sdr_timings(int mode);
+
#endif /* __LINUX_MTD_NAND_H */
--
1.7.9.5
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox