* [PATCH v2 2/2] USB: doc: Binding document for ehci-platform driver
From: Florian Fainelli @ 2012-10-24 16:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <Pine.LNX.4.44L0.1210241233040.1282-100000@iolanthe.rowland.org>
On Wednesday 24 October 2012 12:38:42 Alan Stern wrote:
> On Wed, 24 Oct 2012, Stephen Warren wrote:
>
> > On 10/24/2012 09:26 AM, Sebastian Andrzej Siewior wrote:
> > > On Wed, Oct 24, 2012 at 10:57:00AM -0400, Alan Stern wrote:
> > >> Under the circumstances, do we really need a new binding document for
> > >> the ehci-platform driver?
> >
> > It seems reasonable to add the new properties to usb-ehci.txt, since
> > they do describe the HW.
> >
> > >> We should be able to use the existing
> > >> usb-ehci binding, perhaps with some new properties added:
> > >>
> > >> has-synopsys-hc-bug
> > >> no-io-watchdog
> > >> has-tt
> >
> > That sounds fine to me.
> >
> > However, there is an implementation issue here. I believe the way Linux
> > searches for a driver for a particular node is:
> >
> > for every driver that's registered
> > if the driver's supported compatible list matches the device
> > use the driver
> >
> > (See drivers/base/platform.c:platform_match() which implements the if
> > statement above, and I assume the driver core implements the outer for
> > loop above)
>
> Yes, it does.
>
> > That means that if the generic driver supports compatible="usb-ehci", it
> > may "steal" device nodes that have
> > compatible="something-custom","usb-ehci", even if there's a driver
> > specifically for "something-custom". We would need to re-arrange the
> > driver matching code to:
> >
> > for each compatible value in the node:
> > for each driver that's registered:
> > if the driver supports the compatible value:
> > use the driver.
>
> Which might be difficult since the inner loop would be controlled by
> the outer code in the driver core.
>
> How do we determine which existing drivers claim to support usb-ehci?
> A quick search under arch/ and drivers/ turns up nothing but
> drivers/usb/host/ehci-ppc-of.c. Changing it to a more HW-specific
> match should be easy enough, and then "usb-ehci" would be safe to use
> in ehci-platform.c.
As long as no one enables both ehci-platform and ehci-ppc-of at the same time
there is no problem. ehci-ppc-of should be removed in favor of ehci-platform
and make sure that the specific quirk in ehci-ppc-of also gets ported, other
that I see no issue using "usb-ehci" as the least detailed compatible property
name.
--
Florian
^ permalink raw reply
* [PATCH v2 2/2] USB: doc: Binding document for ehci-platform driver
From: Alan Stern @ 2012-10-24 16:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5088145F.1040504@wwwdotorg.org>
On Wed, 24 Oct 2012, Stephen Warren wrote:
> On 10/24/2012 09:26 AM, Sebastian Andrzej Siewior wrote:
> > On Wed, Oct 24, 2012 at 10:57:00AM -0400, Alan Stern wrote:
> >> Under the circumstances, do we really need a new binding document for
> >> the ehci-platform driver?
>
> It seems reasonable to add the new properties to usb-ehci.txt, since
> they do describe the HW.
>
> >> We should be able to use the existing
> >> usb-ehci binding, perhaps with some new properties added:
> >>
> >> has-synopsys-hc-bug
> >> no-io-watchdog
> >> has-tt
>
> That sounds fine to me.
>
> However, there is an implementation issue here. I believe the way Linux
> searches for a driver for a particular node is:
>
> for every driver that's registered
> if the driver's supported compatible list matches the device
> use the driver
>
> (See drivers/base/platform.c:platform_match() which implements the if
> statement above, and I assume the driver core implements the outer for
> loop above)
Yes, it does.
> That means that if the generic driver supports compatible="usb-ehci", it
> may "steal" device nodes that have
> compatible="something-custom","usb-ehci", even if there's a driver
> specifically for "something-custom". We would need to re-arrange the
> driver matching code to:
>
> for each compatible value in the node:
> for each driver that's registered:
> if the driver supports the compatible value:
> use the driver.
Which might be difficult since the inner loop would be controlled by
the outer code in the driver core.
How do we determine which existing drivers claim to support usb-ehci?
A quick search under arch/ and drivers/ turns up nothing but
drivers/usb/host/ehci-ppc-of.c. Changing it to a more HW-specific
match should be easy enough, and then "usb-ehci" would be safe to use
in ehci-platform.c.
Alan Stern
^ permalink raw reply
* [RFC] Energy/power monitoring within the kernel
From: Pawel Moll @ 2012-10-24 16:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121023220240.GA25895@roeck-us.net>
On Tue, 2012-10-23 at 23:02 +0100, Guenter Roeck wrote:
> > Traditionally such data should be exposed to the user via hwmon sysfs
> > interface, and that's exactly what I did for "my" platform - I have
> > a /sys/class/hwmon/hwmon*/device/energy*_input and this was good
> > enough to draw pretty graphs in userspace. Everyone was happy...
> >
> Only driver supporting "energy" output so far is ibmaem, and the reported energy
> is supposed to be cumulative, as in energy = power * time. Do you mean power,
> possibly ?
So the vexpress would be the second one, than :-) as the energy
"monitor" actually on the latest tiles reports 64-bit value of
microJoules consumed (or produced) since the power-up.
Some of the older boards were able to report instant power, but this
metrics is less useful in our case.
> > Now I am getting new requests to do more with this data. In particular
> > I'm asked how to add such information to ftrace/perf output. The second
> > most frequent request is about providing it to a "energy aware"
> > cpufreq governor.
>
> Anything energy related would have to be along the line of "do something after a
> certain amount of work has been performed", which at least at the surface does
> not make much sense to me, unless you mean something along the line of a
> process scheduler which schedules a process not based on time slices but based
> on energy consumed, ie if you want to define a time slice not in milli-seconds
> but in Joule.
Actually there is some research being done in this direction, but it's
way too early to draw any conclusions...
> If so, I would argue that a similar behavior could be achieved by varying the
> duration of time slices with the current CPU speed, or simply by using cycle
> count instead of time as time slice parameter. Not that I am sure if such an
> approach would really be of interest for anyone.
>
> Or do you really mean power, not energy, such as in "reduce CPU speed if its
> power consumption is above X Watt" ?
Uh. To be completely honest I must answer: I'm not sure how the "energy
aware" cpufreq governor is supposed to work. I have been simply asked to
provide the data in some standard way, if possible.
> I am not sure how this would be expected to work. hwmon is, by its very nature,
> a passive subsystem: It doesn't do anything unless data is explicitly requested
> from it. It does not update an attribute unless that attribute is read.
> That does not seem to fit well with the idea of tracing - which assumes
> that some activity is happening, ultimately, all by itself, presumably
> periodically. The idea to have a user space application read hwmon data only
> for it to trigger trace events does not seem to be very compelling to me.
What I had in mind was similar to what adt7470 driver does. The driver
would automatically access the device every now and then to update it's
internal state and generate the trace event on the way. This
auto-refresh "feature" is particularly appealing for me, as on some of
"my" platforms can take up to 500 microseconds to actually get the data.
So doing this in background (and providing users with the last known
value in the meantime) seems attractive.
> An exception is if a monitoring device suppports interrupts, and if its driver
> actually implements those interrupts. This is, however, not the case for most of
> the current drivers (if any), mostly because interrupt support for hardware
> monitoring devices is very platform dependent and thus difficult to implement.
Interestingly enough the newest version of our platform control micro
(doing the energy monitoring as well) can generate and interrupt when a
transaction is finished, so I was planning to periodically update the
all sort of values. And again, generating a trace event on this
opportunity would be trivial.
> > Of course a particular driver could register its own perf PMU on its
> > own. It's certainly an option, just very suboptimal in my opinion.
> > Or maybe not? Maybe the task is so specialized that it makes sense?
> >
> We had a couple of attempts to provide an in-kernel API. Unfortunately,
> the result was, at least so far, more complexity on the driver side.
> So the difficulty is really to define an API which is really simple, and does
> not just complicate driver development for a (presumably) rare use case.
Yes, I appreciate this. That's why this option is actually my least
favourite. Anyway, what I was thinking about was just a thin shin that
*can* be used by a driver to register some particular value with the
core (so it can be enumerated and accessed by in-kernel clients) and the
core could (or not) create a sysfs attribute for this value on behalf of
the driver. Seems lightweight enough, unless previous experience
suggests otherwise?
Cheers!
Pawe?
^ permalink raw reply
* [PATCH v2 2/2] USB: doc: Binding document for ehci-platform driver
From: Florian Fainelli @ 2012-10-24 16:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5088145F.1040504@wwwdotorg.org>
On Wednesday 24 October 2012 10:16:31 Stephen Warren wrote:
> On 10/24/2012 09:26 AM, Sebastian Andrzej Siewior wrote:
> > On Wed, Oct 24, 2012 at 10:57:00AM -0400, Alan Stern wrote:
> >> Under the circumstances, do we really need a new binding document for
> >> the ehci-platform driver?
>
> It seems reasonable to add the new properties to usb-ehci.txt, since
> they do describe the HW.
>
> >> We should be able to use the existing
> >> usb-ehci binding, perhaps with some new properties added:
> >>
> >> has-synopsys-hc-bug
> >> no-io-watchdog
> >> has-tt
>
> That sounds fine to me.
>
> However, there is an implementation issue here. I believe the way Linux
> searches for a driver for a particular node is:
>
> for every driver that's registered
> if the driver's supported compatible list matches the device
> use the driver
>
> (See drivers/base/platform.c:platform_match() which implements the if
> statement above, and I assume the driver core implements the outer for
> loop above)
>
> That means that if the generic driver supports compatible="usb-ehci", it
> may "steal" device nodes that have
> compatible="something-custom","usb-ehci", even if there's a driver
> specifically for "something-custom". We would need to re-arrange the
> driver matching code to:
>
> for each compatible value in the node:
> for each driver that's registered:
> if the driver supports the compatible value:
> use the driver.
>
> > On the PCI side we have VID, PID which is used for quirks. Sometimes we have a
> > revision ID which can be used to figure out if "this quirk" is still required.
> > The PCI driver probes by class so the ehci driver does not have a large table
> > of VID/PID for each controller out there. And the USB controller in two
> > different Intel boards has a different PID so a quirk, if required, could be
> > applied only to the specific mainboard.
> >
> > Based on this we need atleast two compatible entries one "HW-Specific"
> > followed by a generic one (similar to PCI class).
> > Doing it the PCI way we would have to have table and figure out which
> > HW-specific compatible entry sets the TT flag and which one does the
> > no-io-watchdog. Having has-tt in compatible isn't right.
>
> Yes, the driver could easily bind to anything compatible with
> "usb-ehci", then use the HW-specific compatible value to index into a
> quirk table in the same way that specific PCI IDs index into a quirk table.
Sounds good.
>
> I agree that having separate compatible values like usb-ehci and
> usb-ehci-with-tt probably doesn't make sense here.
>
> > I'm all with Alan here, to make a shortcut and allow Linux specific properties
> > which describe a specific quirk in less code lines. Other OS can just ignore
> > those and build their table based on the compatible entry if they want to.
>
> We should absolutely avoid Linux-specific properties where possible.
>
> That said, what Linux-specific properties are you talking about? The
> properties discussed here (has-synopsys-hc-bug, no-io-watchdog, has-tt)
> are all purely a description of HW, aren't they.
has-tt and has-synopsys-hc-bug are certainly hardware properties, while
no-io-watchdog is a Linux driver software workaround for a hardware issue,
so that's kind of in a grey zone to decide whether this describes hardware or
not. Let's just assume that this is a hardware issue :)
>
> > So usb-ehci should be fine. It is a generic USB-EHCI controller after all.
> > Quirks or no quirks, the register layout is the same, the functionality is the
> > same. If you can't map memory >4GiB then you need a quirk for this but you may
> > discover it way too late.
> > If your platform driver requires extra code for the PHY then it is still an
> > EHCI controller. The PHY wasn't setup by the bootloader / bios so Linux has to
> > deal with it.
> >
> >> We probably can omit has-synopsys-hc-bug, as that is specific to one
> >> type of MIPS ATH79 controller. The driver can check for it explicitly,
> >> if necessary.
> >>
> >> In fact, it's not clear that these new properties need to be added now.
> >> They can be added over time as needed, as existing drivers are
> >> converted over to DT. Or is it preferable to document these things
> >> now, preemptively as it were?
>
> It's best to define the binding up-front so it doesn't churn, where
> possible. This will also ensure that multiple people don't try to update
> the binding document to add the same feature in different ways.
Agreed, we do support these properties in the non-DT case, so I see no reason
why we should not document them in the binding too.
>
> > I would add it only if required / has users.
^ permalink raw reply
* [PATCH v2 2/2] USB: doc: Binding document for ehci-platform driver
From: Stephen Warren @ 2012-10-24 16:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <Pine.LNX.4.44L0.1210241013310.1481-100000@iolanthe.rowland.org>
On 10/24/2012 08:57 AM, Alan Stern wrote:
> On Tue, 23 Oct 2012, Rob Herring wrote:
>
>> On 10/23/2012 02:33 PM, Alan Stern wrote:
>>> On Tue, 23 Oct 2012, Stephen Warren wrote:
>>>
>>>>> Nothing intrinsically distinguishes this class of hardware. The only
>>>>> thing these devices have in common is that they can be managed by
>>>>> Linux's ehci-platform driver.
>>>>
>>>> I don't agree. They're all EHCI USB controllers (or all EHCI USB
>>>> controllers that don't require custom drivers due to quirks), which is a
>>>> much more general statement than anything related to which driver Linux
>>>> uses for them.
>>>
>>> That's true, but it doesn't distinguish these devices. There are other
>>> EHCI controllers with no quirks that nevertheless can't be handled by
>>> ehci-platform because they have requirements (_not_ quirks) that
>>> ehci-platform is unable to deal with currently -- clocks or power
>>> supplies or special register settings or PHYs or etc.
>>
>> But what if the h/w has quirks you haven't yet discovered? You need the
>> compatible property to be specific now, so if there are any future
>> driver changes needed the DT does not have to change (as it may be in
>> firmware which you can't change).
>
> That argument applies always, doesn't it? There's always a chance that
> you might discover a new quirk in a device for which the DT board file
> has already been written and committed to firmware. The board file
> could declare that the device is compatible with something older, but
> the new quirk might ruin that compatibility.
If the board file /only/ declares that the device is compatible with the
older/most-generic thing, that would be a bug in the .dts file. As a
general rule, the device tree should be fixed, although there may be
reasons to work around some buggy device trees in the kernel we should
avoid it if possible.
Device tree files always need a completely specific value in the
compatible property, even when less-specific/more-generic values are
also present. So for example, the Linux driver might only care about the
following existing:
compatible = "usb-ehci".
However, any actual EHCI controller is always some specific model, so
the compatible value must define which specific model it is, e.g.:
compatible = "nvidia,tegra20-ehci", "usb-ehci".
Now lets say the Tegra30 EHCI controller is identical to the Tegra20
controller. That needs to be explicitly represented too:
compatible = "nvidia,tegra30-ehci", "nvidia,tegra20-ehci", "usb-ehci".
In that case, the driver might still only declare support for
"nvidia,tegra20-ehci", but "nvidia,tegra30-ehci" is added to be explicit
about the actual HW model.
This doesn't continue forever though; you typically only list the
specific HW model, the base specific model it's compatible with, and any
generic value needed. So, a hypothetical Tegra40 EHCI controller would be:
compatible = "nvidia,tegra40-ehci", "nvidia,tegra20-ehci", "usb-ehci".
Given that, there is always something to key any newly required quirk
off, so even if the need for a quirk is found later, the device tree
already contains the information needed to trigger it.
This is why quirks should always be keyed off compatible values, since
they're guaranteed to be there in a correctly written device tree.
Generic HW features (such as has-tt) don't need to be derived from the
compatible value (although they could be), since they are something
that's known up-front and hence should be present in any non-buggy
device tree from day one. That's why the binding needs to thought out
ahead of time, or if necessary (e.g. if expanded to support both EHCI
and XHCI and XYZHCI which might require extra standard properties)
evolved in a backwards-compatible fashion.
^ permalink raw reply
* [PATCHv2] Input: omap4-keypad: Add pinctrl support
From: Dmitry Torokhov @ 2012-10-24 16:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdYwA7O8AqB8YFCK-c3e6-7FcbhMOiPEUq-cKJni_PO-Ow@mail.gmail.com>
On Wed, Oct 24, 2012 at 02:54:23PM +0200, Linus Walleij wrote:
> On Tue, Oct 23, 2012 at 10:02 PM, Dmitry Torokhov
> <dmitry.torokhov@gmail.com> wrote:
>
> > I have seen just in a few days 3 or 4 drivers having exactly the same
> > change - call to devm_pinctrl_get_select_default(), and I guess I will
> > receive the same patches for the rest of input drivers shortly.
> > This suggests that the operation is done at the wrong level. Do the
> > pin configuration as you parse DT data, the same way you set up i2c
> > devices registers in of_i2c.c, and leave the individual drivers that do
> > not care about specifics alone.
>
> Exactly this can be done with pinctrl hogs.
>
> The problem with that is that it removes the cross-reference
> between the device and it's pinctrl handle (also from the device
> tree). Instead the pinctrl handle gets referenced to the pin controller
> itself. So from a modelling perpective this looks a bit ugly.
>
> So we have two kinds of ugly:
>
> - Sprinke devm_pinctrl_get_select_default() over all drivers
> which makes pinctrl handles properly reference their devices
>
> - Use hogs and loose coupling between pinctrl handles and their
> devices
>
> A third alternative as outlined is to use notifiers and some
> resource core in drivers/base/*
OK, so with drivers/base/, have you considered doing default pinctrl
selection in bus's probe() methods? Yo would select the default
configuration before starting probing the device and maybe select idle
when probe fails or device is unbound? That would still keep the link
between device object and pinctrl and there less busses than device
drivers out there.
Thanks.
--
Dmitry
^ permalink raw reply
* [PATCH v2 2/2] USB: doc: Binding document for ehci-platform driver
From: Stephen Warren @ 2012-10-24 16:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121024152652.GG4368@breakpoint.cc>
On 10/24/2012 09:26 AM, Sebastian Andrzej Siewior wrote:
> On Wed, Oct 24, 2012 at 10:57:00AM -0400, Alan Stern wrote:
>> Under the circumstances, do we really need a new binding document for
>> the ehci-platform driver?
It seems reasonable to add the new properties to usb-ehci.txt, since
they do describe the HW.
>> We should be able to use the existing
>> usb-ehci binding, perhaps with some new properties added:
>>
>> has-synopsys-hc-bug
>> no-io-watchdog
>> has-tt
That sounds fine to me.
However, there is an implementation issue here. I believe the way Linux
searches for a driver for a particular node is:
for every driver that's registered
if the driver's supported compatible list matches the device
use the driver
(See drivers/base/platform.c:platform_match() which implements the if
statement above, and I assume the driver core implements the outer for
loop above)
That means that if the generic driver supports compatible="usb-ehci", it
may "steal" device nodes that have
compatible="something-custom","usb-ehci", even if there's a driver
specifically for "something-custom". We would need to re-arrange the
driver matching code to:
for each compatible value in the node:
for each driver that's registered:
if the driver supports the compatible value:
use the driver.
> On the PCI side we have VID, PID which is used for quirks. Sometimes we have a
> revision ID which can be used to figure out if "this quirk" is still required.
> The PCI driver probes by class so the ehci driver does not have a large table
> of VID/PID for each controller out there. And the USB controller in two
> different Intel boards has a different PID so a quirk, if required, could be
> applied only to the specific mainboard.
>
> Based on this we need atleast two compatible entries one "HW-Specific"
> followed by a generic one (similar to PCI class).
> Doing it the PCI way we would have to have table and figure out which
> HW-specific compatible entry sets the TT flag and which one does the
> no-io-watchdog. Having has-tt in compatible isn't right.
Yes, the driver could easily bind to anything compatible with
"usb-ehci", then use the HW-specific compatible value to index into a
quirk table in the same way that specific PCI IDs index into a quirk table.
I agree that having separate compatible values like usb-ehci and
usb-ehci-with-tt probably doesn't make sense here.
> I'm all with Alan here, to make a shortcut and allow Linux specific properties
> which describe a specific quirk in less code lines. Other OS can just ignore
> those and build their table based on the compatible entry if they want to.
We should absolutely avoid Linux-specific properties where possible.
That said, what Linux-specific properties are you talking about? The
properties discussed here (has-synopsys-hc-bug, no-io-watchdog, has-tt)
are all purely a description of HW, aren't they.
> So usb-ehci should be fine. It is a generic USB-EHCI controller after all.
> Quirks or no quirks, the register layout is the same, the functionality is the
> same. If you can't map memory >4GiB then you need a quirk for this but you may
> discover it way too late.
> If your platform driver requires extra code for the PHY then it is still an
> EHCI controller. The PHY wasn't setup by the bootloader / bios so Linux has to
> deal with it.
>
>> We probably can omit has-synopsys-hc-bug, as that is specific to one
>> type of MIPS ATH79 controller. The driver can check for it explicitly,
>> if necessary.
>>
>> In fact, it's not clear that these new properties need to be added now.
>> They can be added over time as needed, as existing drivers are
>> converted over to DT. Or is it preferable to document these things
>> now, preemptively as it were?
It's best to define the binding up-front so it doesn't churn, where
possible. This will also ensure that multiple people don't try to update
the binding document to add the same feature in different ways.
> I would add it only if required / has users.
^ permalink raw reply
* [PATCHv2] Input: omap4-keypad: Add pinctrl support
From: Dmitry Torokhov @ 2012-10-24 16:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121024083704.GF5665@arwen.pp.htv.fi>
On Wed, Oct 24, 2012 at 11:37:04AM +0300, Felipe Balbi wrote:
> Hi,
>
> On Tue, Oct 23, 2012 at 01:02:49PM -0700, Dmitry Torokhov wrote:
> > On Tue, Oct 23, 2012 at 11:18:12AM +0200, Benoit Cousson wrote:
> > > Hi Dimitry,
> > >
> > > On 10/22/2012 05:50 PM, Dmitry Torokhov wrote:
> > > > Hi Sourav,
> > > >
> > > > On Mon, Oct 22, 2012 at 06:43:00PM +0530, Sourav Poddar wrote:
> > > >> Adapt keypad to use pinctrl framework.
> > > >>
> > > >> Tested on omap4430 sdp with 3.7-rc1 kernel.
> > > >
> > > > I do not see anything in the driver that would directly use pinctrl. Is
> > > > there a better place to select default pin configuration; maybe when
> > > > instantiating platform device?
> > >
> > > Why?
> > > The devm_pinctrl_get_select_default is using the pinctrl.
> >
> > No, I guess we ihave different understanding of what "directly use" means.
> > This particular driver does directly use interrupts: it requests it and
> > performs some actions when interrupt arrives. Same goes for IO memory -
> > it gets requested, then we access it. With pinctrl we do not do anything
> > - we just ask another layer to configure it and that is it.
>
> this is true for almost anything we do:
>
> - we ask another layer to allocate memory for us
> - we ask another layer to call our ISR once the IRQ line is asserted
> - we ask another layer to handle the input events we just received
> - we ask another layer to transfer data through DMA for us
> - we ask another layer to turn regulators on and off.
But we are _directly_ _using_ all of these. You allocate memory and you
(the driver) stuff data into that memory. You ask for DMA and you take
the DMAed data and work with it. Not so with pinctrl in omap keypad and
other drivers I have seen so far.
>
> and so on. This is just how abstractions work, we group common parts in
> a framework so that users don't need to know the details, but still need
> to tell the framework when to fiddle with those resources.
>
> > I have seen just in a few days 3 or 4 drivers having exactly the same
> > change - call to devm_pinctrl_get_select_default(), and I guess I will
> > receive the same patches for the rest of input drivers shortly.
> > This suggests that the operation is done at the wrong level. Do the
> > pin configuration as you parse DT data, the same way you set up i2c
> > devices registers in of_i2c.c, and leave the individual drivers that do
> > not care about specifics alone.
>
> Makes no sense to hide that from drivers. The idea here is that driver
> should know when it needs its pins to muxed correctly.
The driver also needs memory controller to be initialized, gpio chip be
ready and registered, DMA subsystem ready, input core reade, etc, etc,
etc. You however do not have every driver explicitly initialize any of
that; you expect certain working environment to be already operable. The
driver does manage resources it controls, it has ultimate knowledge
about, pin configuration is normally is not it. We just need to know
that we wired/muxed properly, otherwise we won't work. So please let
parent layers deal with it.
> 95% of the time
> it will be done during probe() but then again, so what ?
>
> doing that when parsing DT, or on bus notifiers is just plain wrong.
> Drivers should be required to handle all of their resources.
All of _their_ resources, exactly. They do not own nor control pins so
they should not be bothered with them either. Look, when you see that
potentially _every_ driver in the system needs to set up the same object
that it doe snot use otherwise you should realize that individual driver
is not the proper place to do that.
>
> > > That's why it is named "get_select_default" and not "get" only.
> > > This API ensure that the pin will be set to the default state, and this
> > > is all we need to do during the probe.
> >
> > Why during the probe and not by default? Realistically, the driver will
> > be loaded as long as there is a matching device and pins will need to be
> > configured.
>
> likewise memory will be allocated when matching happens, IRQs will be
> allocated, regulators will be turned on. So why don't we do all that by
> default ? Because it is wrong.
No, because we do not know how. The generic layer does not know the ISR
to install, how much memory to allocate, etc. Having regulator turned on
before getting to probe might not be a bad idea.
>
> > > There is no point to change the mux if the driver is not probed, because
> > > potentially the pin can be use be another driver.
> >
> > What other driver would use it? Who would chose what driver to load?
>
> Well, you _do_ know that on a SoC we have a limited amount of pins
> right ?
>
> Considering the amont of features which are packed inside a single die,
> it's not farfetched to assume we will have a lot less pins then we
> actually need, so we need muxers behind each pin in order to choose
> which functionality we want.
>
> If it happens that keypad's pins are shared with another IP (e.g. GPIO),
> we need to give the final user (a OEM/ODM) the choice of using those
> pins as either keypad or GPIOs, thus the need for pinctrl framework and
> the calls in the drivers.
Right, so please walk me through, step by step, how an OEM/ODM woudl
select a particular configuration. Do you expect it to happen at
runtime, or do you expect relevant data be put in DT?
Thanks.
--
Dmitry
^ permalink raw reply
* [RFC] Energy/power monitoring within the kernel
From: Pawel Moll @ 2012-10-24 16:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5086E6D6.8000208@linaro.org>
On Tue, 2012-10-23 at 19:49 +0100, Andy Green wrote:
> A thought on that... from an SoC perspective there are other interesting
> power rails than go to just the CPU core. For example DDR power and
> rails involved with other IP units on the SoC such as 3D graphics unit.
> So tying one number to specifically a CPU core does not sound like
> it's enough.
I do realize this. I just didn't want to try to cover too much ground,
and cpufreq governor would be interested in cpu-related data anyway...
> If you turn the problem upside down to solve the representation question
> first, maybe there's a way forward defining the "power tree" in terms of
> regulators, and then adding something in struct regulator that spams
> readers with timestamped results if the regulator has a power monitoring
> capability.
>
> Then you can map the regulators in the power tree to real devices by the
> names or the supply stuff. Just a thought.
Hm. Interesting idea indeed - if a regulator device was able to report
the energy being produced by it (instead of looking at cumulative energy
consumed by more than one device), defining "power domains" (by adding
selected cpus as consumers) would be straight forward and the cpufreq
could request the information that way.
I'll look into it, thanks!
Pawe?
^ permalink raw reply
* [RFC] Energy/power monitoring within the kernel
From: Pawel Moll @ 2012-10-24 16:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351014187.8467.24.camel@gandalf.local.home>
On Tue, 2012-10-23 at 18:43 +0100, Steven Rostedt wrote:
> > <...>212.673126: hwmon_attr_update: hwmon4 temp1_input 34361
> >
> > One issue with this is that some external knowledge is required to
> > relate a number to a processor core. Or maybe it's not an issue at all
> > because it should be left for the user(space)?
>
> If the external knowledge can be characterized in a userspace tool with
> the given data here, I see no issues with this.
Ok, fine.
> > TP_fast_assign(
> > memcpy(__entry->cpus, cpus, sizeof(struct cpumask));
>
> Copying the entire cpumask seems like overkill. Especially when you have
> 4096 CPU machines.
Uh, right. I didn't consider such use case...
> Perhaps making a field that can be a subset of cpus may be better. That
> way we don't waste the ring buffer with lots of zeros. I'm guessing that
> it will only be a group of cpus, and not a scattered list? Of course,
> I've seen boxes where the cpu numbers went from core to core. That is,
> cpu 0 was on core 1, cpu 1 was on core 2, and then it would repeat.
> cpu 8 was on core 1, cpu 9 was on core 2, etc.
>
> But still, this could be compressed somehow.
Sure thing. Or I could simply use cpumask_scnprintf() on the assign
stage and keep an already-formatted string. Or, as the cpumask per
sensor would be de-facto constant, I could assume keep only a pointer to
it. Will keep it in mind if this event was supposed to happen.
Thanks!
Pawe?
^ permalink raw reply
* [PATCH 7/8] ARM: at91/i2c: change id to let i2c-at91 work
From: ludovic.desroches @ 2012-10-24 15:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <55320d29feb80bb5da64dcb82518a56174da7ce4.1351092432.git.nicolas.ferre@atmel.com>
Le 10/24/2012 05:33 PM, Nicolas Ferre a ?crit :
> From: Bo Shen <voice.shen@atmel.com>
>
> The i2c core driver will turn the platform device ID to busnum
> When using platfrom device ID as -1, it means dynamically assigned
> the busnum. When writing code, we need to make sure the busnum,
> and call i2c_register_board_info(int busnum, ...) to register device
> if using -1, we do not know the value of busnum
>
> In order to solve this issue, set the platform device ID as a fix number
> Here using 0 to match the busnum used in i2c_regsiter_board_info()
>
> Signed-off-by: Bo Shen <voice.shen@atmel.com>
> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Acked-By: Ludovic Desroches <ludovic.desroches@atmel.com>
> ---
> arch/arm/mach-at91/at91rm9200.c | 2 +-
> arch/arm/mach-at91/at91rm9200_devices.c | 2 +-
> arch/arm/mach-at91/at91sam9260.c | 4 ++--
> arch/arm/mach-at91/at91sam9260_devices.c | 2 +-
> arch/arm/mach-at91/at91sam9261.c | 4 ++--
> arch/arm/mach-at91/at91sam9261_devices.c | 2 +-
> arch/arm/mach-at91/at91sam9263.c | 2 +-
> arch/arm/mach-at91/at91sam9263_devices.c | 2 +-
> arch/arm/mach-at91/at91sam9rl_devices.c | 2 +-
> 9 files changed, 11 insertions(+), 11 deletions(-)
>
> diff --git a/arch/arm/mach-at91/at91rm9200.c b/arch/arm/mach-at91/at91rm9200.c
> index b4f0565..5269825 100644
> --- a/arch/arm/mach-at91/at91rm9200.c
> +++ b/arch/arm/mach-at91/at91rm9200.c
> @@ -187,7 +187,7 @@ static struct clk_lookup periph_clocks_lookups[] = {
> CLKDEV_CON_DEV_ID("pclk", "ssc.0", &ssc0_clk),
> CLKDEV_CON_DEV_ID("pclk", "ssc.1", &ssc1_clk),
> CLKDEV_CON_DEV_ID("pclk", "ssc.2", &ssc2_clk),
> - CLKDEV_CON_DEV_ID(NULL, "i2c-at91rm9200", &twi_clk),
> + CLKDEV_CON_DEV_ID(NULL, "i2c-at91rm9200.0", &twi_clk),
> /* fake hclk clock */
> CLKDEV_CON_DEV_ID("hclk", "at91_ohci", &ohci_clk),
> CLKDEV_CON_ID("pioA", &pioA_clk),
> diff --git a/arch/arm/mach-at91/at91rm9200_devices.c b/arch/arm/mach-at91/at91rm9200_devices.c
> index 7cd8053..1e122bc 100644
> --- a/arch/arm/mach-at91/at91rm9200_devices.c
> +++ b/arch/arm/mach-at91/at91rm9200_devices.c
> @@ -512,7 +512,7 @@ static struct resource twi_resources[] = {
>
> static struct platform_device at91rm9200_twi_device = {
> .name = "i2c-at91rm9200",
> - .id = -1,
> + .id = 0,
> .resource = twi_resources,
> .num_resources = ARRAY_SIZE(twi_resources),
> };
> diff --git a/arch/arm/mach-at91/at91sam9260.c b/arch/arm/mach-at91/at91sam9260.c
> index ad29f93..f820261 100644
> --- a/arch/arm/mach-at91/at91sam9260.c
> +++ b/arch/arm/mach-at91/at91sam9260.c
> @@ -211,8 +211,8 @@ static struct clk_lookup periph_clocks_lookups[] = {
> CLKDEV_CON_DEV_ID("t1_clk", "atmel_tcb.1", &tc4_clk),
> CLKDEV_CON_DEV_ID("t2_clk", "atmel_tcb.1", &tc5_clk),
> CLKDEV_CON_DEV_ID("pclk", "ssc.0", &ssc_clk),
> - CLKDEV_CON_DEV_ID(NULL, "i2c-at91sam9260", &twi_clk),
> - CLKDEV_CON_DEV_ID(NULL, "i2c-at91sam9g20", &twi_clk),
> + CLKDEV_CON_DEV_ID(NULL, "i2c-at91sam9260.0", &twi_clk),
> + CLKDEV_CON_DEV_ID(NULL, "i2c-at91sam9g20.0", &twi_clk),
> /* more usart lookup table for DT entries */
> CLKDEV_CON_DEV_ID("usart", "fffff200.serial", &mck),
> CLKDEV_CON_DEV_ID("usart", "fffb0000.serial", &usart0_clk),
> diff --git a/arch/arm/mach-at91/at91sam9260_devices.c b/arch/arm/mach-at91/at91sam9260_devices.c
> index 44385a4..aa1e587 100644
> --- a/arch/arm/mach-at91/at91sam9260_devices.c
> +++ b/arch/arm/mach-at91/at91sam9260_devices.c
> @@ -421,7 +421,7 @@ static struct resource twi_resources[] = {
> };
>
> static struct platform_device at91sam9260_twi_device = {
> - .id = -1,
> + .id = 0,
> .resource = twi_resources,
> .num_resources = ARRAY_SIZE(twi_resources),
> };
> diff --git a/arch/arm/mach-at91/at91sam9261.c b/arch/arm/mach-at91/at91sam9261.c
> index 8d999eb..04295c0 100644
> --- a/arch/arm/mach-at91/at91sam9261.c
> +++ b/arch/arm/mach-at91/at91sam9261.c
> @@ -178,8 +178,8 @@ static struct clk_lookup periph_clocks_lookups[] = {
> CLKDEV_CON_DEV_ID("pclk", "ssc.1", &ssc1_clk),
> CLKDEV_CON_DEV_ID("pclk", "ssc.2", &ssc2_clk),
> CLKDEV_CON_DEV_ID("hclk", "at91_ohci", &hck0),
> - CLKDEV_CON_DEV_ID(NULL, "i2c-at91sam9261", &twi_clk),
> - CLKDEV_CON_DEV_ID(NULL, "i2c-at91sam9g10", &twi_clk),
> + CLKDEV_CON_DEV_ID(NULL, "i2c-at91sam9261.0", &twi_clk),
> + CLKDEV_CON_DEV_ID(NULL, "i2c-at91sam9g10.0", &twi_clk),
> CLKDEV_CON_ID("pioA", &pioA_clk),
> CLKDEV_CON_ID("pioB", &pioB_clk),
> CLKDEV_CON_ID("pioC", &pioC_clk),
> diff --git a/arch/arm/mach-at91/at91sam9261_devices.c b/arch/arm/mach-at91/at91sam9261_devices.c
> index 0256a00..b948769 100644
> --- a/arch/arm/mach-at91/at91sam9261_devices.c
> +++ b/arch/arm/mach-at91/at91sam9261_devices.c
> @@ -317,7 +317,7 @@ static struct resource twi_resources[] = {
> };
>
> static struct platform_device at91sam9261_twi_device = {
> - .id = -1,
> + .id = 0,
> .resource = twi_resources,
> .num_resources = ARRAY_SIZE(twi_resources),
> };
> diff --git a/arch/arm/mach-at91/at91sam9263.c b/arch/arm/mach-at91/at91sam9263.c
> index 6a01d03..d6f9c23 100644
> --- a/arch/arm/mach-at91/at91sam9263.c
> +++ b/arch/arm/mach-at91/at91sam9263.c
> @@ -193,7 +193,7 @@ static struct clk_lookup periph_clocks_lookups[] = {
> CLKDEV_CON_DEV_ID("spi_clk", "atmel_spi.0", &spi0_clk),
> CLKDEV_CON_DEV_ID("spi_clk", "atmel_spi.1", &spi1_clk),
> CLKDEV_CON_DEV_ID("t0_clk", "atmel_tcb.0", &tcb_clk),
> - CLKDEV_CON_DEV_ID(NULL, "i2c-at91sam9260", &twi_clk),
> + CLKDEV_CON_DEV_ID(NULL, "i2c-at91sam9260.0", &twi_clk),
> /* fake hclk clock */
> CLKDEV_CON_DEV_ID("hclk", "at91_ohci", &ohci_clk),
> CLKDEV_CON_ID("pioA", &pioA_clk),
> diff --git a/arch/arm/mach-at91/at91sam9263_devices.c b/arch/arm/mach-at91/at91sam9263_devices.c
> index 23b6384..cb85da2 100644
> --- a/arch/arm/mach-at91/at91sam9263_devices.c
> +++ b/arch/arm/mach-at91/at91sam9263_devices.c
> @@ -600,7 +600,7 @@ static struct resource twi_resources[] = {
>
> static struct platform_device at91sam9263_twi_device = {
> .name = "i2c-at91sam9260",
> - .id = -1,
> + .id = 0,
> .resource = twi_resources,
> .num_resources = ARRAY_SIZE(twi_resources),
> };
> diff --git a/arch/arm/mach-at91/at91sam9rl_devices.c b/arch/arm/mach-at91/at91sam9rl_devices.c
> index 3d2c81d..5047bdc 100644
> --- a/arch/arm/mach-at91/at91sam9rl_devices.c
> +++ b/arch/arm/mach-at91/at91sam9rl_devices.c
> @@ -347,7 +347,7 @@ static struct resource twi_resources[] = {
>
> static struct platform_device at91sam9rl_twi_device = {
> .name = "i2c-at91sam9g20",
> - .id = -1,
> + .id = 0,
> .resource = twi_resources,
> .num_resources = ARRAY_SIZE(twi_resources),
> };
>
^ permalink raw reply
* [PATCH 6/8] ARM: at91/i2c: change id to let i2c-gpio work
From: ludovic.desroches @ 2012-10-24 15:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2f8dcb42aa52bd8c7828bc1e1c7bdbff397f2853.1351092432.git.nicolas.ferre@atmel.com>
Le 10/24/2012 05:33 PM, Nicolas Ferre a ?crit :
> From: Bo Shen <voice.shen@atmel.com>
>
> The i2c core driver will turn the platform device ID to busnum
> When using platfrom device ID as -1, it means dynamically assigned
> the busnum. When writing code, we need to make sure the busnum,
> and call i2c_register_board_info(int busnum, ...) to register device
> if using -1, we do not know the value of busnum
>
> In order to solve this issue, set the platform device ID as a fix number
> Here using 0 to match the busnum used in i2c_regsiter_board_info()
>
> Signed-off-by: Bo Shen <voice.shen@atmel.com>
> Acked-by: Jean Delvare <khali@linux-fr.org>
> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Acked-By: Ludovic Desroches <ludovic.desroches@atmel.com>
> Cc: stable <stable@vger.kernel.org> [very long time]
> ---
> arch/arm/mach-at91/at91rm9200_devices.c | 2 +-
> arch/arm/mach-at91/at91sam9260_devices.c | 2 +-
> arch/arm/mach-at91/at91sam9261_devices.c | 2 +-
> arch/arm/mach-at91/at91sam9263_devices.c | 2 +-
> arch/arm/mach-at91/at91sam9rl_devices.c | 2 +-
> 5 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm/mach-at91/at91rm9200_devices.c b/arch/arm/mach-at91/at91rm9200_devices.c
> index a563189..7cd8053 100644
> --- a/arch/arm/mach-at91/at91rm9200_devices.c
> +++ b/arch/arm/mach-at91/at91rm9200_devices.c
> @@ -479,7 +479,7 @@ static struct i2c_gpio_platform_data pdata = {
>
> static struct platform_device at91rm9200_twi_device = {
> .name = "i2c-gpio",
> - .id = -1,
> + .id = 0,
> .dev.platform_data = &pdata,
> };
>
> diff --git a/arch/arm/mach-at91/at91sam9260_devices.c b/arch/arm/mach-at91/at91sam9260_devices.c
> index a76b868..44385a4 100644
> --- a/arch/arm/mach-at91/at91sam9260_devices.c
> +++ b/arch/arm/mach-at91/at91sam9260_devices.c
> @@ -389,7 +389,7 @@ static struct i2c_gpio_platform_data pdata = {
>
> static struct platform_device at91sam9260_twi_device = {
> .name = "i2c-gpio",
> - .id = -1,
> + .id = 0,
> .dev.platform_data = &pdata,
> };
>
> diff --git a/arch/arm/mach-at91/at91sam9261_devices.c b/arch/arm/mach-at91/at91sam9261_devices.c
> index 9752f17..0256a00 100644
> --- a/arch/arm/mach-at91/at91sam9261_devices.c
> +++ b/arch/arm/mach-at91/at91sam9261_devices.c
> @@ -285,7 +285,7 @@ static struct i2c_gpio_platform_data pdata = {
>
> static struct platform_device at91sam9261_twi_device = {
> .name = "i2c-gpio",
> - .id = -1,
> + .id = 0,
> .dev.platform_data = &pdata,
> };
>
> diff --git a/arch/arm/mach-at91/at91sam9263_devices.c b/arch/arm/mach-at91/at91sam9263_devices.c
> index 8dde220..23b6384 100644
> --- a/arch/arm/mach-at91/at91sam9263_devices.c
> +++ b/arch/arm/mach-at91/at91sam9263_devices.c
> @@ -567,7 +567,7 @@ static struct i2c_gpio_platform_data pdata = {
>
> static struct platform_device at91sam9263_twi_device = {
> .name = "i2c-gpio",
> - .id = -1,
> + .id = 0,
> .dev.platform_data = &pdata,
> };
>
> diff --git a/arch/arm/mach-at91/at91sam9rl_devices.c b/arch/arm/mach-at91/at91sam9rl_devices.c
> index d6ca054..3d2c81d 100644
> --- a/arch/arm/mach-at91/at91sam9rl_devices.c
> +++ b/arch/arm/mach-at91/at91sam9rl_devices.c
> @@ -314,7 +314,7 @@ static struct i2c_gpio_platform_data pdata = {
>
> static struct platform_device at91sam9rl_twi_device = {
> .name = "i2c-gpio",
> - .id = -1,
> + .id = 0,
> .dev.platform_data = &pdata,
> };
>
>
^ permalink raw reply
* [PATCH 4/8] ARM: at91: fix external interrupt specification in board code
From: ludovic.desroches @ 2012-10-24 15:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ecf01c6afd3969c9af1839ccbe64cdf5357d0433.1351092432.git.nicolas.ferre@atmel.com>
Le 10/24/2012 05:33 PM, Nicolas Ferre a ?crit :
> Since the switch to sparse irq, we have to add the NR_IRQS_LEGACY
> offset to static irq numbers. It has been forgotten on these
> SPI irq definitions in board code.
>
> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Acked-By: Ludovic Desroches <ludovic.desroches@atmel.com>
> Cc: stable <stable@vger.kernel.org> [v3.6]
> ---
> arch/arm/mach-at91/board-neocore926.c | 2 +-
> arch/arm/mach-at91/board-sam9261ek.c | 2 +-
> arch/arm/mach-at91/board-sam9263ek.c | 2 +-
> 3 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/mach-at91/board-neocore926.c b/arch/arm/mach-at91/board-neocore926.c
> index 9cda3fd..6960778 100644
> --- a/arch/arm/mach-at91/board-neocore926.c
> +++ b/arch/arm/mach-at91/board-neocore926.c
> @@ -129,7 +129,7 @@ static struct spi_board_info neocore926_spi_devices[] = {
> .max_speed_hz = 125000 * 16,
> .bus_num = 0,
> .platform_data = &ads_info,
> - .irq = AT91SAM9263_ID_IRQ1,
> + .irq = NR_IRQS_LEGACY + AT91SAM9263_ID_IRQ1,
> },
> #endif
> };
> diff --git a/arch/arm/mach-at91/board-sam9261ek.c b/arch/arm/mach-at91/board-sam9261ek.c
> index 27b3af1..a9167dd 100644
> --- a/arch/arm/mach-at91/board-sam9261ek.c
> +++ b/arch/arm/mach-at91/board-sam9261ek.c
> @@ -309,7 +309,7 @@ static struct spi_board_info ek_spi_devices[] = {
> .max_speed_hz = 125000 * 26, /* (max sample rate @ 3V) * (cmd + data + overhead) */
> .bus_num = 0,
> .platform_data = &ads_info,
> - .irq = AT91SAM9261_ID_IRQ0,
> + .irq = NR_IRQS_LEGACY + AT91SAM9261_ID_IRQ0,
> .controller_data = (void *) AT91_PIN_PA28, /* CS pin */
> },
> #endif
> diff --git a/arch/arm/mach-at91/board-sam9263ek.c b/arch/arm/mach-at91/board-sam9263ek.c
> index 073e174..b87dbe2 100644
> --- a/arch/arm/mach-at91/board-sam9263ek.c
> +++ b/arch/arm/mach-at91/board-sam9263ek.c
> @@ -132,7 +132,7 @@ static struct spi_board_info ek_spi_devices[] = {
> .max_speed_hz = 125000 * 26, /* (max sample rate @ 3V) * (cmd + data + overhead) */
> .bus_num = 0,
> .platform_data = &ads_info,
> - .irq = AT91SAM9263_ID_IRQ1,
> + .irq = NR_IRQS_LEGACY + AT91SAM9263_ID_IRQ1,
> },
> #endif
> };
>
^ permalink raw reply
* [PATCH 3/8] ARM: at91: fix external interrupts in non-DT case
From: ludovic.desroches @ 2012-10-24 15:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d431a4eca966e5faf17cc3c3af2fe1653bf2f2c5.1351092432.git.nicolas.ferre@atmel.com>
Le 10/24/2012 05:33 PM, Nicolas Ferre a ?crit :
> Management of external interrupts has changed but the
> non-DT code has not integrated these changes.
> Add a mask to pass external irq specification from SoC
> specific code to the at91_aic_init() function.
>
> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Acked-By: Ludovic Desroches <ludovic.desroches@atmel.com>
> Cc: stable <stable@vger.kernel.org> [v3.6]
> ---
> arch/arm/mach-at91/generic.h | 3 ++-
> arch/arm/mach-at91/irq.c | 9 +++++++--
> arch/arm/mach-at91/setup.c | 2 +-
> 3 files changed, 10 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/mach-at91/generic.h b/arch/arm/mach-at91/generic.h
> index f496506..b62f560e 100644
> --- a/arch/arm/mach-at91/generic.h
> +++ b/arch/arm/mach-at91/generic.h
> @@ -26,7 +26,8 @@ extern void __init at91_dt_initialize(void);
> extern void __init at91_init_irq_default(void);
> extern void __init at91_init_interrupts(unsigned int priority[]);
> extern void __init at91x40_init_interrupts(unsigned int priority[]);
> -extern void __init at91_aic_init(unsigned int priority[]);
> +extern void __init at91_aic_init(unsigned int priority[],
> + unsigned int ext_irq_mask);
> extern int __init at91_aic_of_init(struct device_node *node,
> struct device_node *parent);
> extern int __init at91_aic5_of_init(struct device_node *node,
> diff --git a/arch/arm/mach-at91/irq.c b/arch/arm/mach-at91/irq.c
> index 1e02c0e..febc2ee 100644
> --- a/arch/arm/mach-at91/irq.c
> +++ b/arch/arm/mach-at91/irq.c
> @@ -502,14 +502,19 @@ int __init at91_aic5_of_init(struct device_node *node,
> /*
> * Initialize the AIC interrupt controller.
> */
> -void __init at91_aic_init(unsigned int *priority)
> +void __init at91_aic_init(unsigned int *priority, unsigned int ext_irq_mask)
> {
> unsigned int i;
> int irq_base;
>
> - if (at91_aic_pm_init())
> + at91_extern_irq = kzalloc(BITS_TO_LONGS(n_irqs)
> + * sizeof(*at91_extern_irq), GFP_KERNEL);
> +
> + if (at91_aic_pm_init() || at91_extern_irq == NULL)
> panic("Unable to allocate bit maps\n");
>
> + *at91_extern_irq = ext_irq_mask;
> +
> at91_aic_base = ioremap(AT91_AIC, 512);
> if (!at91_aic_base)
> panic("Unable to ioremap AIC registers\n");
> diff --git a/arch/arm/mach-at91/setup.c b/arch/arm/mach-at91/setup.c
> index 6a3d4bb..0b32c81 100644
> --- a/arch/arm/mach-at91/setup.c
> +++ b/arch/arm/mach-at91/setup.c
> @@ -47,7 +47,7 @@ void __init at91_init_irq_default(void)
> void __init at91_init_interrupts(unsigned int *priority)
> {
> /* Initialize the AIC interrupt controller */
> - at91_aic_init(priority);
> + at91_aic_init(priority, at91_extern_irq);
>
> /* Enable GPIO interrupts */
> at91_gpio_irq_setup();
>
^ permalink raw reply
* [PATCH 0/8] at91: 3.7 fixes patch series
From: Jean-Christophe PLAGNIOL-VILLARD @ 2012-10-24 15:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1351092432.git.nicolas.ferre@atmel.com>
Acked-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Best Regards,
J.
On 17:33 Wed 24 Oct , Nicolas Ferre wrote:
>
> Hi all,
> I am posting this patch series just before sending a pull-request to Arnd and
> Olof.
> There are 2 new patches that I have just cooked today about external IRQ
> handling: please review.
> I would like you to double check that I have not made any mistake while
> collecting the other patches...
>
> Thanks, best regards,
>
>
> Bo Shen (2):
> ARM: at91/i2c: change id to let i2c-gpio work
> ARM: at91/i2c: change id to let i2c-at91 work
>
> Ivan Shugov (1):
> ARM: at91: at91sam9g10: fix SOC type detection
>
> Jean-Christophe PLAGNIOL-VILLARD (1):
> ARM: at91: drop duplicated config SOC_AT91SAM9 entry
>
> Josh Wu (1):
> ARM: at91/tc: fix typo in the DT document
>
> Marek Belisko (1):
> ARM: at91/dts: at91sam9g20ek_common: Fix typos in buttons labels.
>
> Nicolas Ferre (2):
> ARM: at91: fix external interrupts in non-DT case
> ARM: at91: fix external interrupt specification in board code
>
> Documentation/devicetree/bindings/arm/atmel-at91.txt | 2 +-
> arch/arm/boot/dts/at91sam9g20ek_common.dtsi | 4 ++--
> arch/arm/mach-at91/Kconfig | 10 ++--------
> arch/arm/mach-at91/at91rm9200.c | 2 +-
> arch/arm/mach-at91/at91rm9200_devices.c | 4 ++--
> arch/arm/mach-at91/at91sam9260.c | 4 ++--
> arch/arm/mach-at91/at91sam9260_devices.c | 4 ++--
> arch/arm/mach-at91/at91sam9261.c | 4 ++--
> arch/arm/mach-at91/at91sam9261_devices.c | 4 ++--
> arch/arm/mach-at91/at91sam9263.c | 2 +-
> arch/arm/mach-at91/at91sam9263_devices.c | 4 ++--
> arch/arm/mach-at91/at91sam9rl_devices.c | 4 ++--
> arch/arm/mach-at91/board-neocore926.c | 2 +-
> arch/arm/mach-at91/board-sam9261ek.c | 2 +-
> arch/arm/mach-at91/board-sam9263ek.c | 2 +-
> arch/arm/mach-at91/generic.h | 3 ++-
> arch/arm/mach-at91/irq.c | 9 +++++++--
> arch/arm/mach-at91/setup.c | 4 ++--
> 18 files changed, 35 insertions(+), 35 deletions(-)
>
> --
> 1.7.11.3
>
^ permalink raw reply
* [PATCH V4 1/5] ARM: dts: OMAP: Add timer nodes
From: Benoit Cousson @ 2012-10-24 15:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350658744-13509-2-git-send-email-jon-hunter@ti.com>
Hi Jon,
On 10/19/2012 04:59 PM, Jon Hunter wrote:
> Add the 12 GP timers nodes present in OMAP2.
> Add the 12 GP timers nodes present in OMAP3.
> Add the 11 GP timers nodes present in OMAP4.
> Add the 7 GP timers nodes present in AM33xx.
>
> Add documentation for timer properties specific to OMAP.
>
> Thanks to Vaibhav Hiremath for creating the AM33xx timer nodes. I have modified
> Vaibhav's original nodes adding information on which timers support a PWM
> output.
>
> Cc: Benoit Cousson <b-cousson@ti.com>
> Signed-off-by: Jon Hunter <jon-hunter@ti.com>
I updated the patch to remove the interrupt-parent from the DTS nodes and the documentation, as discussed on the list in the context of OMAP5 DTS for GPIO.
If you are OK with that version, I'll push it to Tony along with the others DTS patches.
Regards,
Benoit
---
>From 531cc8142ecd6da7929628772c4035dcf7996fef Mon Sep 17 00:00:00 2001
From: Jon Hunter <jon-hunter@ti.com>
Date: Fri, 19 Oct 2012 09:59:00 -0500
Subject: [PATCH] ARM: dts: OMAP: Add timer nodes
Add the 12 GP timers nodes present in OMAP2.
Add the 12 GP timers nodes present in OMAP3.
Add the 11 GP timers nodes present in OMAP4.
Add the 7 GP timers nodes present in AM33xx.
Add documentation for timer properties specific to OMAP.
Thanks to Vaibhav Hiremath for creating the AM33xx timer nodes. I have modified
Vaibhav's original nodes adding information on which timers support a PWM
output.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
[b-cousson at ti.com: Remove the interrupt-parent from nodes]
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
---
.../devicetree/bindings/arm/omap/timer.txt | 31 +++++++
arch/arm/boot/dts/am33xx.dtsi | 54 +++++++++++
arch/arm/boot/dts/omap2.dtsi | 85 +++++++++++++++++
arch/arm/boot/dts/omap2420.dtsi | 8 ++
arch/arm/boot/dts/omap2430.dtsi | 8 ++
arch/arm/boot/dts/omap3.dtsi | 95 ++++++++++++++++++++
arch/arm/boot/dts/omap4.dtsi | 86 ++++++++++++++++++
7 files changed, 367 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/arm/omap/timer.txt
diff --git a/Documentation/devicetree/bindings/arm/omap/timer.txt b/Documentation/devicetree/bindings/arm/omap/timer.txt
new file mode 100644
index 0000000..b073d89
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/omap/timer.txt
@@ -0,0 +1,31 @@
+OMAP Timer bindings
+
+Required properties:
+- compatible: Must be "ti,omap2-timer" for OMAP2+ controllers.
+- reg: Contains timer register address range (base address and
+ length).
+- interrupts: Contains the interrupt information for the timer. The
+ format is being dependent on which interrupt controller
+ the OMAP device uses.
+- ti,hwmods: Name of the hwmod associated to the timer, "timer<X>",
+ where <X> is the instance number of the timer from the
+ HW spec.
+
+Optional properties:
+- ti,timer-alwon: Indicates the timer is in an alway-on power domain.
+- ti,timer-dsp: Indicates the timer can interrupt the on-chip DSP in
+ addition to the ARM CPU.
+- ti,timer-pwm: Indicates the timer can generate a PWM output.
+- ti,timer-secure: Indicates the timer is reserved on a secure OMAP device
+ and therefore cannot be used by the kernel.
+
+Example:
+
+timer12: timer at 48304000 {
+ compatible = "ti,omap2-timer";
+ reg = <0x48304000 0xfff>;
+ interrupts = <95>;
+ ti,hwmods = "timer12"
+ ti,timer-alwon;
+ ti,timer-secure;
+};
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 4709269..7522e16 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -237,5 +237,59 @@
interrupts = <55>;
status = "disabled";
};
+
+ timer1: timer at 44e31000 {
+ compatible = "ti,omap2-timer";
+ reg = <0x44e31000 0x1000>;
+ interrupts = <67>;
+ ti,hwmods = "timer1";
+ ti,timer-alwon;
+ };
+
+ timer2: timer at 48040000 {
+ compatible = "ti,omap2-timer";
+ reg = <0x48040000 0x1000>;
+ interrupts = <68>;
+ ti,hwmods = "timer2";
+ };
+
+ timer3: timer at 48042000 {
+ compatible = "ti,omap2-timer";
+ reg = <0x48042000 0x1000>;
+ interrupts = <69>;
+ ti,hwmods = "timer3";
+ };
+
+ timer4: timer at 48044000 {
+ compatible = "ti,omap2-timer";
+ reg = <0x48044000 0x1000>;
+ interrupts = <92>;
+ ti,hwmods = "timer4";
+ ti,timer-pwm;
+ };
+
+ timer5: timer at 48046000 {
+ compatible = "ti,omap2-timer";
+ reg = <0x48046000 0x1000>;
+ interrupts = <93>;
+ ti,hwmods = "timer5";
+ ti,timer-pwm;
+ };
+
+ timer6: timer at 48048000 {
+ compatible = "ti,omap2-timer";
+ reg = <0x48048000 0x1000>;
+ interrupts = <94>;
+ ti,hwmods = "timer6";
+ ti,timer-pwm;
+ };
+
+ timer7: timer at 4804a000 {
+ compatible = "ti,omap2-timer";
+ reg = <0x4804a000 0x1000>;
+ interrupts = <95>;
+ ti,hwmods = "timer7";
+ ti,timer-pwm;
+ };
};
};
diff --git a/arch/arm/boot/dts/omap2.dtsi b/arch/arm/boot/dts/omap2.dtsi
index f366482..731de55 100644
--- a/arch/arm/boot/dts/omap2.dtsi
+++ b/arch/arm/boot/dts/omap2.dtsi
@@ -66,5 +66,90 @@
ti,hwmods = "uart3";
clock-frequency = <48000000>;
};
+
+ timer2: timer at 4802a000 {
+ compatible = "ti,omap2-timer";
+ reg = <0x4802a000 0xfff>;
+ interrupts = <38>;
+ ti,hwmods = "timer2";
+ };
+
+ timer3: timer at 48078000 {
+ compatible = "ti,omap2-timer";
+ reg = <0x48078000 0xfff>;
+ interrupts = <39>;
+ ti,hwmods = "timer3";
+ };
+
+ timer4: timer at 4807a000 {
+ compatible = "ti,omap2-timer";
+ reg = <0x4807a000 0xfff>;
+ interrupts = <40>;
+ ti,hwmods = "timer4";
+ };
+
+ timer5: timer at 4807c000 {
+ compatible = "ti,omap2-timer";
+ reg = <0x4807c000 0xfff>;
+ interrupts = <41>;
+ ti,hwmods = "timer5";
+ ti,timer-dsp;
+ };
+
+ timer6: timer at 4807e000 {
+ compatible = "ti,omap2-timer";
+ reg = <0x4807e000 0xfff>;
+ interrupts = <42>;
+ ti,hwmods = "timer6";
+ ti,timer-dsp;
+ };
+
+ timer7: timer at 48080000 {
+ compatible = "ti,omap2-timer";
+ reg = <0x48080000 0xfff>;
+ interrupts = <43>;
+ ti,hwmods = "timer7";
+ ti,timer-dsp;
+ };
+
+ timer8: timer at 48082000 {
+ compatible = "ti,omap2-timer";
+ reg = <0x48082000 0xfff>;
+ interrupts = <44>;
+ ti,hwmods = "timer8";
+ ti,timer-dsp;
+ };
+
+ timer9: timer at 48084000 {
+ compatible = "ti,omap2-timer";
+ reg = <0x48084000 0xfff>;
+ interrupts = <45>;
+ ti,hwmods = "timer9";
+ ti,timer-pwm;
+ };
+
+ timer10: timer at 48086000 {
+ compatible = "ti,omap2-timer";
+ reg = <0x48086000 0xfff>;
+ interrupts = <46>;
+ ti,hwmods = "timer10";
+ ti,timer-pwm;
+ };
+
+ timer11: timer at 48088000 {
+ compatible = "ti,omap2-timer";
+ reg = <0x48088000 0xfff>;
+ interrupts = <47>;
+ ti,hwmods = "timer11";
+ ti,timer-pwm;
+ };
+
+ timer12: timer at 4808a000 {
+ compatible = "ti,omap2-timer";
+ reg = <0x4808a000 0xfff>;
+ interrupts = <48>;
+ ti,hwmods = "timer12";
+ ti,timer-pwm;
+ };
};
};
diff --git a/arch/arm/boot/dts/omap2420.dtsi b/arch/arm/boot/dts/omap2420.dtsi
index 4d5ce91..eee3778 100644
--- a/arch/arm/boot/dts/omap2420.dtsi
+++ b/arch/arm/boot/dts/omap2420.dtsi
@@ -42,5 +42,13 @@
interrupt-names = "tx", "rx";
ti,hwmods = "mcbsp2";
};
+
+ timer1: timer at 48028000 {
+ compatible = "ti,omap2-timer";
+ reg = <0x48028000 0xfff>;
+ interrupts = <37>;
+ ti,hwmods = "timer1";
+ ti,timer-alwon;
+ };
};
};
diff --git a/arch/arm/boot/dts/omap2430.dtsi b/arch/arm/boot/dts/omap2430.dtsi
index fa84532..eea5b8e 100644
--- a/arch/arm/boot/dts/omap2430.dtsi
+++ b/arch/arm/boot/dts/omap2430.dtsi
@@ -83,5 +83,13 @@
ti,buffer-size = <128>;
ti,hwmods = "mcbsp5";
};
+
+ timer1: timer at 49018000 {
+ compatible = "ti,omap2-timer";
+ reg = <0x49018000 0xfff>;
+ interrupts = <37>;
+ ti,hwmods = "timer1";
+ ti,timer-alwon;
+ };
};
};
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 955cbdc..904c07e 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -296,5 +296,100 @@
ti,buffer-size = <128>;
ti,hwmods = "mcbsp5";
};
+
+ timer1: timer at 48318000 {
+ compatible = "ti,omap2-timer";
+ reg = <0x48318000 0xfff>;
+ interrupts = <37>;
+ ti,hwmods = "timer1";
+ ti,timer-alwon;
+ };
+
+ timer2: timer at 49032000 {
+ compatible = "ti,omap2-timer";
+ reg = <0x49032000 0xfff>;
+ interrupts = <38>;
+ ti,hwmods = "timer2";
+ };
+
+ timer3: timer at 49034000 {
+ compatible = "ti,omap2-timer";
+ reg = <0x49034000 0xfff>;
+ interrupts = <39>;
+ ti,hwmods = "timer3";
+ };
+
+ timer4: timer at 49036000 {
+ compatible = "ti,omap2-timer";
+ reg = <0x49036000 0xfff>;
+ interrupts = <40>;
+ ti,hwmods = "timer4";
+ };
+
+ timer5: timer at 49038000 {
+ compatible = "ti,omap2-timer";
+ reg = <0x49038000 0xfff>;
+ interrupts = <41>;
+ ti,hwmods = "timer5";
+ ti,timer-dsp;
+ };
+
+ timer6: timer at 4903a000 {
+ compatible = "ti,omap2-timer";
+ reg = <0x4903a000 0xfff>;
+ interrupts = <42>;
+ ti,hwmods = "timer6";
+ ti,timer-dsp;
+ };
+
+ timer7: timer at 4903c000 {
+ compatible = "ti,omap2-timer";
+ reg = <0x4903c000 0xfff>;
+ interrupts = <43>;
+ ti,hwmods = "timer7";
+ ti,timer-dsp;
+ };
+
+ timer8: timer at 4903e000 {
+ compatible = "ti,omap2-timer";
+ reg = <0x4903e000 0xfff>;
+ interrupts = <44>;
+ ti,hwmods = "timer8";
+ ti,timer-pwm;
+ ti,timer-dsp;
+ };
+
+ timer9: timer at 49040000 {
+ compatible = "ti,omap2-timer";
+ reg = <0x49040000 0xfff>;
+ interrupts = <45>;
+ ti,hwmods = "timer9";
+ ti,timer-pwm;
+ };
+
+ timer10: timer at 48086000 {
+ compatible = "ti,omap2-timer";
+ reg = <0x48086000 0xfff>;
+ interrupts = <46>;
+ ti,hwmods = "timer10";
+ ti,timer-pwm;
+ };
+
+ timer11: timer at 48088000 {
+ compatible = "ti,omap2-timer";
+ reg = <0x48088000 0xfff>;
+ interrupts = <47>;
+ ti,hwmods = "timer11";
+ ti,timer-pwm;
+ };
+
+ timer12: timer at 48304000 {
+ compatible = "ti,omap2-timer";
+ reg = <0x48304000 0xfff>;
+ interrupts = <95>;
+ ti,hwmods = "timer12";
+ ti,timer-alwon;
+ ti,timer-secure;
+ };
};
};
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 2ab6e68..77f9cc9 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -433,5 +433,91 @@
ranges;
ti,hwmods = "ocp2scp_usb_phy";
};
+
+ timer1: timer at 4a318000 {
+ compatible = "ti,omap2-timer";
+ reg = <0x4a318000 0x7f>;
+ interrupts = <0 37 0x4>;
+ ti,hwmods = "timer1";
+ ti,timer-alwon;
+ };
+
+ timer2: timer at 48032000 {
+ compatible = "ti,omap2-timer";
+ reg = <0x48032000 0x7f>;
+ interrupts = <0 38 0x4>;
+ ti,hwmods = "timer2";
+ };
+
+ timer3: timer at 48034000 {
+ compatible = "ti,omap2-timer";
+ reg = <0x48034000 0x7f>;
+ interrupts = <0 39 0x4>;
+ ti,hwmods = "timer3";
+ };
+
+ timer4: timer at 48036000 {
+ compatible = "ti,omap2-timer";
+ reg = <0x48036000 0x7f>;
+ interrupts = <0 40 0x4>;
+ ti,hwmods = "timer4";
+ };
+
+ timer5: timer at 49038000 {
+ compatible = "ti,omap2-timer";
+ reg = <0x49038000 0x7f>;
+ interrupts = <0 41 0x4>;
+ ti,hwmods = "timer5";
+ ti,timer-dsp;
+ };
+
+ timer6: timer at 4903a000 {
+ compatible = "ti,omap2-timer";
+ reg = <0x4903a000 0x7f>;
+ interrupts = <0 42 0x4>;
+ ti,hwmods = "timer6";
+ ti,timer-dsp;
+ };
+
+ timer7: timer at 4903c000 {
+ compatible = "ti,omap2-timer";
+ reg = <0x4903c000 0x7f>;
+ interrupts = <0 43 0x4>;
+ ti,hwmods = "timer7";
+ ti,timer-dsp;
+ };
+
+ timer8: timer at 4903e000 {
+ compatible = "ti,omap2-timer";
+ reg = <0x4903e000 0x7f>;
+ interrupts = <0 44 0x4>;
+ ti,hwmods = "timer8";
+ ti,timer-pwm;
+ ti,timer-dsp;
+ };
+
+ timer9: timer at 4803e000 {
+ compatible = "ti,omap2-timer";
+ reg = <0x4803e000 0x7f>;
+ interrupts = <0 45 0x4>;
+ ti,hwmods = "timer9";
+ ti,timer-pwm;
+ };
+
+ timer10: timer at 48086000 {
+ compatible = "ti,omap2-timer";
+ reg = <0x48086000 0x7f>;
+ interrupts = <0 46 0x4>;
+ ti,hwmods = "timer10";
+ ti,timer-pwm;
+ };
+
+ timer11: timer at 48088000 {
+ compatible = "ti,omap2-timer";
+ reg = <0x48088000 0x7f>;
+ interrupts = <0 47 0x4>;
+ ti,hwmods = "timer11";
+ ti,timer-pwm;
+ };
};
};
--
1.7.0.4
^ permalink raw reply related
* [PATCH] arm: mvebu: support for the PlatHome OpenBlocks AX3 board
From: Thomas Petazzoni @ 2012-10-24 15:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121024153131.GG11837@lunn.ch>
Andrew,
On Wed, 24 Oct 2012 17:31:31 +0200, Andrew Lunn wrote:
> I agree with the last point. So maybe have a openblocks-ax3-4.dts and
> set the compatibility string to plathome,openblocks-ax3-4.
>
> When somebody gets a ax3/2, they can refactor the common DT into a
> dtsi file without causing any compatibility issues.
Ok, I'll repost with this update. Thanks!
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH 0/9] ARM: Kirkwood: Convert to pinctrl
From: Andrew Lunn @ 2012-10-24 15:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMW5UfaHZE2VB5Ug-5hT_29U8zfO_qZh9T=9QBbx0xv7D+OeOA@mail.gmail.com>
On Wed, Oct 24, 2012 at 11:29:08AM -0400, Josh Coombs wrote:
> Andrew, are there any required kernel config changes to go along with
> this? I didn't see any updates to the default configs in the patches
> so I want to make sure I'm testing with the right options enabled.
Hi Josh
I've been testing with is:
make kirkwood_defconfig
make
The _defconfig file now contains all boards and should build most
common drivers to get the boards booted. If something critical is
missing for your boards, please let us known and we will add it to
_defconfig.
Andrew
^ permalink raw reply
* [PATCH 8/8] ARM: at91: drop duplicated config SOC_AT91SAM9 entry
From: Nicolas Ferre @ 2012-10-24 15:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1351092432.git.nicolas.ferre@atmel.com>
From: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
---
arch/arm/mach-at91/Kconfig | 10 ++--------
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-at91/Kconfig b/arch/arm/mach-at91/Kconfig
index b142071..0436242 100644
--- a/arch/arm/mach-at91/Kconfig
+++ b/arch/arm/mach-at91/Kconfig
@@ -21,19 +21,13 @@ config SOC_AT91SAM9
bool
select CPU_ARM926T
select GENERIC_CLOCKEVENTS
+ select MULTI_IRQ_HANDLER
+ select SPARSE_IRQ
menu "Atmel AT91 System-on-Chip"
comment "Atmel AT91 Processor"
-config SOC_AT91SAM9
- bool
- select AT91_SAM9_SMC
- select AT91_SAM9_TIME
- select CPU_ARM926T
- select MULTI_IRQ_HANDLER
- select SPARSE_IRQ
-
config SOC_AT91RM9200
bool "AT91RM9200"
select CPU_ARM920T
--
1.7.11.3
^ permalink raw reply related
* [PATCH 7/8] ARM: at91/i2c: change id to let i2c-at91 work
From: Nicolas Ferre @ 2012-10-24 15:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1351092432.git.nicolas.ferre@atmel.com>
From: Bo Shen <voice.shen@atmel.com>
The i2c core driver will turn the platform device ID to busnum
When using platfrom device ID as -1, it means dynamically assigned
the busnum. When writing code, we need to make sure the busnum,
and call i2c_register_board_info(int busnum, ...) to register device
if using -1, we do not know the value of busnum
In order to solve this issue, set the platform device ID as a fix number
Here using 0 to match the busnum used in i2c_regsiter_board_info()
Signed-off-by: Bo Shen <voice.shen@atmel.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
---
arch/arm/mach-at91/at91rm9200.c | 2 +-
arch/arm/mach-at91/at91rm9200_devices.c | 2 +-
arch/arm/mach-at91/at91sam9260.c | 4 ++--
arch/arm/mach-at91/at91sam9260_devices.c | 2 +-
arch/arm/mach-at91/at91sam9261.c | 4 ++--
arch/arm/mach-at91/at91sam9261_devices.c | 2 +-
arch/arm/mach-at91/at91sam9263.c | 2 +-
arch/arm/mach-at91/at91sam9263_devices.c | 2 +-
arch/arm/mach-at91/at91sam9rl_devices.c | 2 +-
9 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-at91/at91rm9200.c b/arch/arm/mach-at91/at91rm9200.c
index b4f0565..5269825 100644
--- a/arch/arm/mach-at91/at91rm9200.c
+++ b/arch/arm/mach-at91/at91rm9200.c
@@ -187,7 +187,7 @@ static struct clk_lookup periph_clocks_lookups[] = {
CLKDEV_CON_DEV_ID("pclk", "ssc.0", &ssc0_clk),
CLKDEV_CON_DEV_ID("pclk", "ssc.1", &ssc1_clk),
CLKDEV_CON_DEV_ID("pclk", "ssc.2", &ssc2_clk),
- CLKDEV_CON_DEV_ID(NULL, "i2c-at91rm9200", &twi_clk),
+ CLKDEV_CON_DEV_ID(NULL, "i2c-at91rm9200.0", &twi_clk),
/* fake hclk clock */
CLKDEV_CON_DEV_ID("hclk", "at91_ohci", &ohci_clk),
CLKDEV_CON_ID("pioA", &pioA_clk),
diff --git a/arch/arm/mach-at91/at91rm9200_devices.c b/arch/arm/mach-at91/at91rm9200_devices.c
index 7cd8053..1e122bc 100644
--- a/arch/arm/mach-at91/at91rm9200_devices.c
+++ b/arch/arm/mach-at91/at91rm9200_devices.c
@@ -512,7 +512,7 @@ static struct resource twi_resources[] = {
static struct platform_device at91rm9200_twi_device = {
.name = "i2c-at91rm9200",
- .id = -1,
+ .id = 0,
.resource = twi_resources,
.num_resources = ARRAY_SIZE(twi_resources),
};
diff --git a/arch/arm/mach-at91/at91sam9260.c b/arch/arm/mach-at91/at91sam9260.c
index ad29f93..f820261 100644
--- a/arch/arm/mach-at91/at91sam9260.c
+++ b/arch/arm/mach-at91/at91sam9260.c
@@ -211,8 +211,8 @@ static struct clk_lookup periph_clocks_lookups[] = {
CLKDEV_CON_DEV_ID("t1_clk", "atmel_tcb.1", &tc4_clk),
CLKDEV_CON_DEV_ID("t2_clk", "atmel_tcb.1", &tc5_clk),
CLKDEV_CON_DEV_ID("pclk", "ssc.0", &ssc_clk),
- CLKDEV_CON_DEV_ID(NULL, "i2c-at91sam9260", &twi_clk),
- CLKDEV_CON_DEV_ID(NULL, "i2c-at91sam9g20", &twi_clk),
+ CLKDEV_CON_DEV_ID(NULL, "i2c-at91sam9260.0", &twi_clk),
+ CLKDEV_CON_DEV_ID(NULL, "i2c-at91sam9g20.0", &twi_clk),
/* more usart lookup table for DT entries */
CLKDEV_CON_DEV_ID("usart", "fffff200.serial", &mck),
CLKDEV_CON_DEV_ID("usart", "fffb0000.serial", &usart0_clk),
diff --git a/arch/arm/mach-at91/at91sam9260_devices.c b/arch/arm/mach-at91/at91sam9260_devices.c
index 44385a4..aa1e587 100644
--- a/arch/arm/mach-at91/at91sam9260_devices.c
+++ b/arch/arm/mach-at91/at91sam9260_devices.c
@@ -421,7 +421,7 @@ static struct resource twi_resources[] = {
};
static struct platform_device at91sam9260_twi_device = {
- .id = -1,
+ .id = 0,
.resource = twi_resources,
.num_resources = ARRAY_SIZE(twi_resources),
};
diff --git a/arch/arm/mach-at91/at91sam9261.c b/arch/arm/mach-at91/at91sam9261.c
index 8d999eb..04295c0 100644
--- a/arch/arm/mach-at91/at91sam9261.c
+++ b/arch/arm/mach-at91/at91sam9261.c
@@ -178,8 +178,8 @@ static struct clk_lookup periph_clocks_lookups[] = {
CLKDEV_CON_DEV_ID("pclk", "ssc.1", &ssc1_clk),
CLKDEV_CON_DEV_ID("pclk", "ssc.2", &ssc2_clk),
CLKDEV_CON_DEV_ID("hclk", "at91_ohci", &hck0),
- CLKDEV_CON_DEV_ID(NULL, "i2c-at91sam9261", &twi_clk),
- CLKDEV_CON_DEV_ID(NULL, "i2c-at91sam9g10", &twi_clk),
+ CLKDEV_CON_DEV_ID(NULL, "i2c-at91sam9261.0", &twi_clk),
+ CLKDEV_CON_DEV_ID(NULL, "i2c-at91sam9g10.0", &twi_clk),
CLKDEV_CON_ID("pioA", &pioA_clk),
CLKDEV_CON_ID("pioB", &pioB_clk),
CLKDEV_CON_ID("pioC", &pioC_clk),
diff --git a/arch/arm/mach-at91/at91sam9261_devices.c b/arch/arm/mach-at91/at91sam9261_devices.c
index 0256a00..b948769 100644
--- a/arch/arm/mach-at91/at91sam9261_devices.c
+++ b/arch/arm/mach-at91/at91sam9261_devices.c
@@ -317,7 +317,7 @@ static struct resource twi_resources[] = {
};
static struct platform_device at91sam9261_twi_device = {
- .id = -1,
+ .id = 0,
.resource = twi_resources,
.num_resources = ARRAY_SIZE(twi_resources),
};
diff --git a/arch/arm/mach-at91/at91sam9263.c b/arch/arm/mach-at91/at91sam9263.c
index 6a01d03..d6f9c23 100644
--- a/arch/arm/mach-at91/at91sam9263.c
+++ b/arch/arm/mach-at91/at91sam9263.c
@@ -193,7 +193,7 @@ static struct clk_lookup periph_clocks_lookups[] = {
CLKDEV_CON_DEV_ID("spi_clk", "atmel_spi.0", &spi0_clk),
CLKDEV_CON_DEV_ID("spi_clk", "atmel_spi.1", &spi1_clk),
CLKDEV_CON_DEV_ID("t0_clk", "atmel_tcb.0", &tcb_clk),
- CLKDEV_CON_DEV_ID(NULL, "i2c-at91sam9260", &twi_clk),
+ CLKDEV_CON_DEV_ID(NULL, "i2c-at91sam9260.0", &twi_clk),
/* fake hclk clock */
CLKDEV_CON_DEV_ID("hclk", "at91_ohci", &ohci_clk),
CLKDEV_CON_ID("pioA", &pioA_clk),
diff --git a/arch/arm/mach-at91/at91sam9263_devices.c b/arch/arm/mach-at91/at91sam9263_devices.c
index 23b6384..cb85da2 100644
--- a/arch/arm/mach-at91/at91sam9263_devices.c
+++ b/arch/arm/mach-at91/at91sam9263_devices.c
@@ -600,7 +600,7 @@ static struct resource twi_resources[] = {
static struct platform_device at91sam9263_twi_device = {
.name = "i2c-at91sam9260",
- .id = -1,
+ .id = 0,
.resource = twi_resources,
.num_resources = ARRAY_SIZE(twi_resources),
};
diff --git a/arch/arm/mach-at91/at91sam9rl_devices.c b/arch/arm/mach-at91/at91sam9rl_devices.c
index 3d2c81d..5047bdc 100644
--- a/arch/arm/mach-at91/at91sam9rl_devices.c
+++ b/arch/arm/mach-at91/at91sam9rl_devices.c
@@ -347,7 +347,7 @@ static struct resource twi_resources[] = {
static struct platform_device at91sam9rl_twi_device = {
.name = "i2c-at91sam9g20",
- .id = -1,
+ .id = 0,
.resource = twi_resources,
.num_resources = ARRAY_SIZE(twi_resources),
};
--
1.7.11.3
^ permalink raw reply related
* [PATCH 6/8] ARM: at91/i2c: change id to let i2c-gpio work
From: Nicolas Ferre @ 2012-10-24 15:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1351092432.git.nicolas.ferre@atmel.com>
From: Bo Shen <voice.shen@atmel.com>
The i2c core driver will turn the platform device ID to busnum
When using platfrom device ID as -1, it means dynamically assigned
the busnum. When writing code, we need to make sure the busnum,
and call i2c_register_board_info(int busnum, ...) to register device
if using -1, we do not know the value of busnum
In order to solve this issue, set the platform device ID as a fix number
Here using 0 to match the busnum used in i2c_regsiter_board_info()
Signed-off-by: Bo Shen <voice.shen@atmel.com>
Acked-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Cc: stable <stable@vger.kernel.org> [very long time]
---
arch/arm/mach-at91/at91rm9200_devices.c | 2 +-
arch/arm/mach-at91/at91sam9260_devices.c | 2 +-
arch/arm/mach-at91/at91sam9261_devices.c | 2 +-
arch/arm/mach-at91/at91sam9263_devices.c | 2 +-
arch/arm/mach-at91/at91sam9rl_devices.c | 2 +-
5 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-at91/at91rm9200_devices.c b/arch/arm/mach-at91/at91rm9200_devices.c
index a563189..7cd8053 100644
--- a/arch/arm/mach-at91/at91rm9200_devices.c
+++ b/arch/arm/mach-at91/at91rm9200_devices.c
@@ -479,7 +479,7 @@ static struct i2c_gpio_platform_data pdata = {
static struct platform_device at91rm9200_twi_device = {
.name = "i2c-gpio",
- .id = -1,
+ .id = 0,
.dev.platform_data = &pdata,
};
diff --git a/arch/arm/mach-at91/at91sam9260_devices.c b/arch/arm/mach-at91/at91sam9260_devices.c
index a76b868..44385a4 100644
--- a/arch/arm/mach-at91/at91sam9260_devices.c
+++ b/arch/arm/mach-at91/at91sam9260_devices.c
@@ -389,7 +389,7 @@ static struct i2c_gpio_platform_data pdata = {
static struct platform_device at91sam9260_twi_device = {
.name = "i2c-gpio",
- .id = -1,
+ .id = 0,
.dev.platform_data = &pdata,
};
diff --git a/arch/arm/mach-at91/at91sam9261_devices.c b/arch/arm/mach-at91/at91sam9261_devices.c
index 9752f17..0256a00 100644
--- a/arch/arm/mach-at91/at91sam9261_devices.c
+++ b/arch/arm/mach-at91/at91sam9261_devices.c
@@ -285,7 +285,7 @@ static struct i2c_gpio_platform_data pdata = {
static struct platform_device at91sam9261_twi_device = {
.name = "i2c-gpio",
- .id = -1,
+ .id = 0,
.dev.platform_data = &pdata,
};
diff --git a/arch/arm/mach-at91/at91sam9263_devices.c b/arch/arm/mach-at91/at91sam9263_devices.c
index 8dde220..23b6384 100644
--- a/arch/arm/mach-at91/at91sam9263_devices.c
+++ b/arch/arm/mach-at91/at91sam9263_devices.c
@@ -567,7 +567,7 @@ static struct i2c_gpio_platform_data pdata = {
static struct platform_device at91sam9263_twi_device = {
.name = "i2c-gpio",
- .id = -1,
+ .id = 0,
.dev.platform_data = &pdata,
};
diff --git a/arch/arm/mach-at91/at91sam9rl_devices.c b/arch/arm/mach-at91/at91sam9rl_devices.c
index d6ca054..3d2c81d 100644
--- a/arch/arm/mach-at91/at91sam9rl_devices.c
+++ b/arch/arm/mach-at91/at91sam9rl_devices.c
@@ -314,7 +314,7 @@ static struct i2c_gpio_platform_data pdata = {
static struct platform_device at91sam9rl_twi_device = {
.name = "i2c-gpio",
- .id = -1,
+ .id = 0,
.dev.platform_data = &pdata,
};
--
1.7.11.3
^ permalink raw reply related
* [PATCH 5/8] ARM: at91/dts: at91sam9g20ek_common: Fix typos in buttons labels.
From: Nicolas Ferre @ 2012-10-24 15:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1351092432.git.nicolas.ferre@atmel.com>
From: Marek Belisko <marek.belisko@open-nandra.com>
Signed-off-by: Marek Belisko <marek.belisko@open-nandra.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
---
arch/arm/boot/dts/at91sam9g20ek_common.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/at91sam9g20ek_common.dtsi b/arch/arm/boot/dts/at91sam9g20ek_common.dtsi
index b06c0db..e6391a4 100644
--- a/arch/arm/boot/dts/at91sam9g20ek_common.dtsi
+++ b/arch/arm/boot/dts/at91sam9g20ek_common.dtsi
@@ -126,14 +126,14 @@
#size-cells = <0>;
btn3 {
- label = "Buttin 3";
+ label = "Button 3";
gpios = <&pioA 30 1>;
linux,code = <0x103>;
gpio-key,wakeup;
};
btn4 {
- label = "Buttin 4";
+ label = "Button 4";
gpios = <&pioA 31 1>;
linux,code = <0x104>;
gpio-key,wakeup;
--
1.7.11.3
^ permalink raw reply related
* [PATCH 4/8] ARM: at91: fix external interrupt specification in board code
From: Nicolas Ferre @ 2012-10-24 15:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1351092432.git.nicolas.ferre@atmel.com>
Since the switch to sparse irq, we have to add the NR_IRQS_LEGACY
offset to static irq numbers. It has been forgotten on these
SPI irq definitions in board code.
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Cc: stable <stable@vger.kernel.org> [v3.6]
---
arch/arm/mach-at91/board-neocore926.c | 2 +-
arch/arm/mach-at91/board-sam9261ek.c | 2 +-
arch/arm/mach-at91/board-sam9263ek.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-at91/board-neocore926.c b/arch/arm/mach-at91/board-neocore926.c
index 9cda3fd..6960778 100644
--- a/arch/arm/mach-at91/board-neocore926.c
+++ b/arch/arm/mach-at91/board-neocore926.c
@@ -129,7 +129,7 @@ static struct spi_board_info neocore926_spi_devices[] = {
.max_speed_hz = 125000 * 16,
.bus_num = 0,
.platform_data = &ads_info,
- .irq = AT91SAM9263_ID_IRQ1,
+ .irq = NR_IRQS_LEGACY + AT91SAM9263_ID_IRQ1,
},
#endif
};
diff --git a/arch/arm/mach-at91/board-sam9261ek.c b/arch/arm/mach-at91/board-sam9261ek.c
index 27b3af1..a9167dd 100644
--- a/arch/arm/mach-at91/board-sam9261ek.c
+++ b/arch/arm/mach-at91/board-sam9261ek.c
@@ -309,7 +309,7 @@ static struct spi_board_info ek_spi_devices[] = {
.max_speed_hz = 125000 * 26, /* (max sample rate @ 3V) * (cmd + data + overhead) */
.bus_num = 0,
.platform_data = &ads_info,
- .irq = AT91SAM9261_ID_IRQ0,
+ .irq = NR_IRQS_LEGACY + AT91SAM9261_ID_IRQ0,
.controller_data = (void *) AT91_PIN_PA28, /* CS pin */
},
#endif
diff --git a/arch/arm/mach-at91/board-sam9263ek.c b/arch/arm/mach-at91/board-sam9263ek.c
index 073e174..b87dbe2 100644
--- a/arch/arm/mach-at91/board-sam9263ek.c
+++ b/arch/arm/mach-at91/board-sam9263ek.c
@@ -132,7 +132,7 @@ static struct spi_board_info ek_spi_devices[] = {
.max_speed_hz = 125000 * 26, /* (max sample rate @ 3V) * (cmd + data + overhead) */
.bus_num = 0,
.platform_data = &ads_info,
- .irq = AT91SAM9263_ID_IRQ1,
+ .irq = NR_IRQS_LEGACY + AT91SAM9263_ID_IRQ1,
},
#endif
};
--
1.7.11.3
^ permalink raw reply related
* [PATCH 3/8] ARM: at91: fix external interrupts in non-DT case
From: Nicolas Ferre @ 2012-10-24 15:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1351092432.git.nicolas.ferre@atmel.com>
Management of external interrupts has changed but the
non-DT code has not integrated these changes.
Add a mask to pass external irq specification from SoC
specific code to the at91_aic_init() function.
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Cc: stable <stable@vger.kernel.org> [v3.6]
---
arch/arm/mach-at91/generic.h | 3 ++-
arch/arm/mach-at91/irq.c | 9 +++++++--
arch/arm/mach-at91/setup.c | 2 +-
3 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-at91/generic.h b/arch/arm/mach-at91/generic.h
index f496506..b62f560e 100644
--- a/arch/arm/mach-at91/generic.h
+++ b/arch/arm/mach-at91/generic.h
@@ -26,7 +26,8 @@ extern void __init at91_dt_initialize(void);
extern void __init at91_init_irq_default(void);
extern void __init at91_init_interrupts(unsigned int priority[]);
extern void __init at91x40_init_interrupts(unsigned int priority[]);
-extern void __init at91_aic_init(unsigned int priority[]);
+extern void __init at91_aic_init(unsigned int priority[],
+ unsigned int ext_irq_mask);
extern int __init at91_aic_of_init(struct device_node *node,
struct device_node *parent);
extern int __init at91_aic5_of_init(struct device_node *node,
diff --git a/arch/arm/mach-at91/irq.c b/arch/arm/mach-at91/irq.c
index 1e02c0e..febc2ee 100644
--- a/arch/arm/mach-at91/irq.c
+++ b/arch/arm/mach-at91/irq.c
@@ -502,14 +502,19 @@ int __init at91_aic5_of_init(struct device_node *node,
/*
* Initialize the AIC interrupt controller.
*/
-void __init at91_aic_init(unsigned int *priority)
+void __init at91_aic_init(unsigned int *priority, unsigned int ext_irq_mask)
{
unsigned int i;
int irq_base;
- if (at91_aic_pm_init())
+ at91_extern_irq = kzalloc(BITS_TO_LONGS(n_irqs)
+ * sizeof(*at91_extern_irq), GFP_KERNEL);
+
+ if (at91_aic_pm_init() || at91_extern_irq == NULL)
panic("Unable to allocate bit maps\n");
+ *at91_extern_irq = ext_irq_mask;
+
at91_aic_base = ioremap(AT91_AIC, 512);
if (!at91_aic_base)
panic("Unable to ioremap AIC registers\n");
diff --git a/arch/arm/mach-at91/setup.c b/arch/arm/mach-at91/setup.c
index 6a3d4bb..0b32c81 100644
--- a/arch/arm/mach-at91/setup.c
+++ b/arch/arm/mach-at91/setup.c
@@ -47,7 +47,7 @@ void __init at91_init_irq_default(void)
void __init at91_init_interrupts(unsigned int *priority)
{
/* Initialize the AIC interrupt controller */
- at91_aic_init(priority);
+ at91_aic_init(priority, at91_extern_irq);
/* Enable GPIO interrupts */
at91_gpio_irq_setup();
--
1.7.11.3
^ permalink raw reply related
* [PATCH 2/8] ARM: at91: at91sam9g10: fix SOC type detection
From: Nicolas Ferre @ 2012-10-24 15:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1351092432.git.nicolas.ferre@atmel.com>
From: Ivan Shugov <ivan.shugov@gmail.com>
Newer at91sam9g10 SoC revision can't be detected, so the kernel can't boot with
this kind of kernel panic:
"AT91: Impossible to detect the SOC type"
CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00053177
CPU: VIVT data cache, VIVT instruction cache
Machine: Atmel AT91SAM9G10-EK
Ignoring tag cmdline (using the default kernel command line)
bootconsole [earlycon0] enabled
Memory policy: ECC disabled, Data cache writeback
Kernel panic - not syncing: AT91: Impossible to detect the SOC type
[<c00133d4>] (unwind_backtrace+0x0/0xe0) from [<c02366dc>] (panic+0x78/0x1cc)
[<c02366dc>] (panic+0x78/0x1cc) from [<c02fa35c>] (at91_map_io+0x90/0xc8)
[<c02fa35c>] (at91_map_io+0x90/0xc8) from [<c02f9860>] (paging_init+0x564/0x6d0)
[<c02f9860>] (paging_init+0x564/0x6d0) from [<c02f7914>] (setup_arch+0x464/0x704)
[<c02f7914>] (setup_arch+0x464/0x704) from [<c02f44f8>] (start_kernel+0x6c/0x2d4)
[<c02f44f8>] (start_kernel+0x6c/0x2d4) from [<20008040>] (0x20008040)
The reason for this is that the Debug Unit Chip ID Register has changed between
Engineering Sample and definitive revision of the SoC. Changing the check of
cidr to socid will address the problem. We do not integrate this check to the
list just above because we also have to make sure that the extended id is
disregarded.
Signed-off-by: Ivan Shugov <ivan.shugov@gmail.com>
[nicolas.ferre at atmel.com: change commit message]
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Cc: stable <stable@vger.kernel.org> [v3.1] # since commit 8c3583b6
---
arch/arm/mach-at91/setup.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-at91/setup.c b/arch/arm/mach-at91/setup.c
index da9881b..6a3d4bb 100644
--- a/arch/arm/mach-at91/setup.c
+++ b/arch/arm/mach-at91/setup.c
@@ -151,7 +151,7 @@ static void __init soc_detect(u32 dbgu_base)
}
/* at91sam9g10 */
- if ((cidr & ~AT91_CIDR_EXT) == ARCH_ID_AT91SAM9G10) {
+ if ((socid & ~AT91_CIDR_EXT) == ARCH_ID_AT91SAM9G10) {
at91_soc_initdata.type = AT91_SOC_SAM9G10;
at91_boot_soc = at91sam9261_soc;
}
--
1.7.11.3
^ 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