* [PATCH 00/16] pinctrl: samsung: Usability and extensibiltiy improvements
From: Tomasz Figa @ 2012-10-10 9:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdbUmM2=vhjhCq_qN2v=8RUDeWV4b8A8oXXPE4e8Z9C7zg@mail.gmail.com>
On Wednesday 10 of October 2012 09:46:28 Linus Walleij wrote:
> On Mon, Oct 8, 2012 at 10:39 AM, Tomasz Figa <t.figa@samsung.com> wrote:
> > This patch series is a work on improving usability and extensibiltiy of
> > the>
> > pinctrl-samsung driver. It consists of three main parts:
> > - moving SoC-specific data to device tree
> > - converting the driver to use one GPIO chip and one IRQ domain per
> > pin bank - introducing generic wake-up interrupt capability
> > description
>
> So can you prepare a patch series which does all but the first
> bullet to begin with, and a SoC-and register offset patch
> on top of that as a separate series, because it is controversial?
>
> I don't like that these two things are mingled together like this
> in an all-or-nothing manner.
>
> So I'm OK with a patch series for bulle (2) and (3) but not (1).
As I already stated in my other replies, patches for (2) and (3) depend on
(1), because current architecture of the driver makes it hard to implement
in an elegant way, so some code would have to be reworked anyway.
I should still have some preliminary work on this in one of my branches in
my working tree, but it was heavily incomplete, as it turned out that using
DT would simplify some things.
Best regards,
--
Tomasz Figa
Samsung Poland R&D Center
^ permalink raw reply
* [PATCH] [ARM] Use AT() in the linker script to create correct program headers
From: Dave Martin @ 2012-10-10 9:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121009173706.GE4124@obsidianresearch.com>
On Tue, Oct 09, 2012 at 11:37:06AM -0600, Jason Gunthorpe wrote:
> On Mon, Oct 08, 2012 at 11:24:13AM +0100, Dave Martin wrote:
>
> > Partly this came from some side speculation about whether we could do
> > things like privileged read-only permissions on newer CPUs, for preventing
> > unintended or undesired writes to the kernel's code or read-only data.
>
> Some other arches page protect the kernel, but that tends to be at
> odds with the desire to use huge pages for the kernel mapping, and
> independent of the load headers..
This wasn't so much about that headers themselves as about fragmentation
of the page permissions which makes it difficult to map everything using
huge pages / sections. But as you say, there are conflicting concerns
here, and it seems not to be a priority.
Privileged write-protect is nice to have if non-disruptive, but not
essential.
Cheers
---Dave
^ permalink raw reply
* pm: add suspend_mem and suspend_standby support
From: Daniel Mack @ 2012-10-10 9:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5075210B.3020309@ti.com>
On 10.10.2012 09:17, Vaibhav Hiremath wrote:
> On 10/10/2012 3:42 AM, Rafael J. Wysocki wrote:
>> On Tuesday 09 of October 2012 17:17:04 Jean-Christophe PLAGNIOL-VILLARD wrote:
>>> On 07:58 Tue 09 Oct , Greg Kroah-Hartman wrote:
>>>> On Tue, Oct 09, 2012 at 01:46:33PM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
>>>>> On 22:02 Sun 07 Oct , Rafael J. Wysocki wrote:
>>>>>> On Sunday 07 of October 2012 15:12:01 Jean-Christophe PLAGNIOL-VILLARD wrote:
>>>>>>> On 00:18 Sun 07 Oct , Rafael J. Wysocki wrote:
>>>>>>>> On Saturday 06 of October 2012 18:14:29 Jean-Christophe PLAGNIOL-VILLARD wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> The following changes since commit 5f3d2f2e1a63679cf1c4a4210f2f1cc2f335bef6:
>>>>>>>>>
>>>>>>>>> Merge branch 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc (2012-10-06 03:16:12 +0900)
>>>>>>>>>
>>>>>>>>> are available in the git repository at:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> git://git.jcrosoft.org/linux-2.6.git tags/pm_suspend_standby_mem
>>>>>>>>>
>>>>>>>>> for you to fetch changes up to b73c8f97aa8e720bd3b921159687d00626c99d63:
>>>>>>>>>
>>>>>>>>> arm: at91: drop at91_suspend_entering_slow_clock (2012-10-06 18:06:25 +0800)
>>>>>>>>>
>>>>>>>>> ----------------------------------------------------------------
>>>>>>>>> pm: add suspend_mem and suspend_standby support
>>>>>>>>>
>>>>>>>>> Today when we go to suspend we can not knwon at drivers level if we go in
>>>>>>>>> STANDBY or MEM. Fix this by introducing two new callback suspend_mem and
>>>>>>>>> suspend_standby.
>>>>>>>>
>>>>>>>> No way. Device drivers shouldn't be concerned about that.
>>>>>>> I do need it on at91 as we swith to slow_clock in MEM suspend and some ip
>>>>>>> need special handling when switching to slow_clock
>>>>>>
>>>>>> Well, my answer to that is: please fix your platform code instead of
>>>>>> hacking the PM core to work around its problems.
>>>>> how can I fix drivers pm issue when I no way to known at driver level the
>>>>> real suspend, the PM core is supposed to proivde the right information to the
>>>>> drivers so the driver can put it's in the right pm mode. If the pm core can not
>>>>> provide such inforation the PM core is broken as we will have to do dirty
>>>>> hack.
>>>>
>>>> Why do you need to know the difference in your driver? We used to
>>>> provide this information a long time ago, but it turned out to not be
>>>> needed at all and just caused problems.
>>> because on at91 I need to handle the mem standby at drviers level.
>>
>> This is not an answer. You're basically saying "it has to be done this way,
>> because it has to be done this way".
>>
>>> We do it today already by a hack in different drivers at91_udc (usb device),
>>> atmel_serail and at91_ohci. Those 3 IP have specifci handling when switching
>>> to mem pm. On at91 when switch to mem we shutdown everything and run form a slow
>>> clock - this is done at soc level - but those IP have issue and need specific
>>> care before doing so. Ohterwise when the SoC will wakeup but those IP will not
>>>
>>> in this patch series I send the update of those 3 drivers too
>>> and kill the hack
>>
>> Well, let's start over. What's the difference between "suspend to RAM" (mem)
>> and "standby" on your platform?
>>
>>>>> Any generic framework is supposed to evolve for real user need here I've one
>>>>> so I udpate the core to mach a need
>>
>> Yes, if there are more users needing a change. If there's only one, I think not
>> really.
>>
>
> We came across such a need while supporting various low-power modes in
> AM335x SoC. I also wanted to put similar proposal, its good that Jean
> submitted patches and we are having this discussion early.
>
> Let me try to describe the need and issue here,
>
> In case of AM33xx device, we have different low-power modes supported
> by HW, for this discussion I will just talk about DeepSleep-0 and
> StandBy mode supported by HW (few other modes also described in spec)-
>
> Below is the Spec definition of these two low-power modes,
Thanks for this summary, which raises a question for me that might be
slightly unreleated to the general discussion, but still:
I was just looking at the code that ships with the BSP kernel, and the
approach there is to load a binary firmare blob to the M3 UMEM and then
communicates with mailbox commands in order to put the system to suspend.
Is this how it should be done in mainline as well or are there any plans
to implement that behaviour natively?
Thanks,
Daniel
^ permalink raw reply
* [PATCH 2/6] ARM: EXYNOS5: DT Support for SATA and SATA PHY
From: Vasanth Ananthan @ 2012-10-10 9:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAK1UHiyjyp8u-nFwU-19dds1uF7T1kkFNHyYQ6pWLFtUwGtR1w@mail.gmail.com>
Hi,
On Tue, Oct 9, 2012 at 11:58 PM, Olof Johansson <olof@lixom.net> wrote:
>
> Hi,
>
>
> On Tue, Oct 09, 2012 at 05:18:48PM +0530, Vasanth Ananthan wrote:
> > This patch adds Device Nodes for SATA and SATA PHY device.
> >
> > Signed-off-by: Vasanth Ananthan <vasanth.a@samsung.com>
> > ---
> > arch/arm/boot/dts/exynos5250-smdk5250.dts | 11 +++++++++++
> > arch/arm/boot/dts/exynos5250.dtsi | 20 ++++++++++++++++++++
> > arch/arm/mach-exynos/include/mach/map.h | 7 +++++++
> > arch/arm/mach-exynos/mach-exynos5-dt.c | 6 ++++++
> > 4 files changed, 44 insertions(+), 0 deletions(-)
> >
> > diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts b/arch/arm/boot/dts/exynos5250-smdk5250.dts
> > index 8a5e348..bb262ce 100644
> > --- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
> > +++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
> > @@ -48,6 +48,17 @@
> > };
> > };
> >
> > + i2c at 121D0000 {
> > + samsung,i2c-sda-delay = <100>;
> > + samsung,i2c-max-bus-freq = <40000>;
> > + samsung,i2c-slave-addr = <0x38>;
>
> Whitespace is off above.
>
> > +
> > + sataphy at 70 {
>
> sata-phy would be a more conventional name.
>
> > + compatible = "samsung,i2c-phy";
>
> i2c-phy? Seems like an odd choice of name. What is this device?
The SATA physical layer controller is both a platform device and a i2c
slave device.
This compatible string is for the i2c client driver. Hence I have used
i2c-phy here.
>
>
> > + reg = <0x38>;
>
> 70 is unit address but here it's 0x38? One of them is wrong. No need for a unit
> address if it's a unique name, by the way.
>
>
> > + };
> > + };
> > +
> > i2c at 12C80000 {
> > status = "disabled";
> > };
> > diff --git a/arch/arm/boot/dts/exynos5250.dtsi b/arch/arm/boot/dts/exynos5250.dtsi
> > index 004aaa8..5a47a8f 100644
> > --- a/arch/arm/boot/dts/exynos5250.dtsi
> > +++ b/arch/arm/boot/dts/exynos5250.dtsi
> > @@ -88,6 +88,18 @@
> > interrupts = <0 54 0>;
> > };
> >
> > + sata at 122F0000 {
> > + compatible = "samsung,exynos-sata-ahci";
> > + reg = <0x122F0000 0x1ff>;
> > + interrupts = <0 115 0>;
>
> More whitespace damage. And need binding.
>
> > + };
> > +
> > + sata-phy at 12170000 {
> > + compatible = "samsung,exynos-sata-phy";
> > + reg = <0x12170000 0x1ff>;
> > + };
>
> Should have binding too. How does this relate to the i2c device above.
As mentioned earlier SATA physical layer controller is both a platform
device and also an i2c slave device.
This Node is for the SATA physical layer platform device, the previous
node is for i2c slave device.
Certain initialization settings done directly and other settings has
to be done through i2c.
>
> > +
> > i2c at 12C60000 {
> > compatible = "samsung,s3c2440-i2c";
> > reg = <0x12C60000 0x100>;
> > @@ -152,6 +164,13 @@
> > #size-cells = <0>;
> > };
> >
> > + i2c at 121D0000 {
> > + compatible = "samsung,s3c2440-sataphy-i2c";
>
> Is this a unique i2c controller, or is it just another one like the others on
> the chip? If it's the latter, it should use the regular compatible string.
Yes, its a unique i2c controller which lacks an interrupt line while
others are interrupt driven.
Hence I have used a distinct compatible string for the driver to
distinguish the controller.
>
> > + reg = <0x121D0000 0x100>;
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + };
> > +
> > spi_0: spi at 12d20000 {
> > compatible = "samsung,exynos4210-spi";
> > reg = <0x12d20000 0x100>;
> > @@ -460,4 +479,5 @@
> > #gpio-cells = <4>;
> > };
> > };
> > +
>
> Stray whitespace change.
>
> > };
> > diff --git a/arch/arm/mach-exynos/include/mach/map.h b/arch/arm/mach-exynos/include/mach/map.h
> > index c72b675..6827190 100644
> > --- a/arch/arm/mach-exynos/include/mach/map.h
> > +++ b/arch/arm/mach-exynos/include/mach/map.h
> > @@ -177,9 +177,16 @@
> > #define EXYNOS4_PA_HSOTG 0x12480000
> > #define EXYNOS4_PA_USB_HSPHY 0x125B0000
> >
> > +#ifdef CONFIG_ARCH_EXYNOS4
>
> No need to ifdef since namespace isn't overlapped.
>
> > #define EXYNOS4_PA_SATA 0x12560000
> > #define EXYNOS4_PA_SATAPHY 0x125D0000
> > #define EXYNOS4_PA_SATAPHY_CTRL 0x126B0000
> > +#endif
> > +#ifdef CONFIG_ARCH_EXYNOS5
>
> Same here.
>
> > +#define EXYNOS5_PA_SATA_PHY_CTRL 0x12170000
> > +#define EXYNOS5_PA_SATA_PHY_I2C 0x121D0000
> > +#define EXYNOS5_PA_SATA_BASE 0x122F0000
> > +#endif
>
>
> -Olof
I will incorporate the other comments and resubmit the patch. Thanks.
--
Vasanth Ananthan.
^ permalink raw reply
* pm: add suspend_mem and suspend_standby support
From: Hiremath, Vaibhav @ 2012-10-10 9:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50753DD9.1080105@gmail.com>
On Wed, Oct 10, 2012 at 14:50:25, Daniel Mack wrote:
> On 10.10.2012 09:17, Vaibhav Hiremath wrote:
> > On 10/10/2012 3:42 AM, Rafael J. Wysocki wrote:
> >> On Tuesday 09 of October 2012 17:17:04 Jean-Christophe PLAGNIOL-VILLARD wrote:
> >>> On 07:58 Tue 09 Oct , Greg Kroah-Hartman wrote:
> >>>> On Tue, Oct 09, 2012 at 01:46:33PM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> >>>>> On 22:02 Sun 07 Oct , Rafael J. Wysocki wrote:
> >>>>>> On Sunday 07 of October 2012 15:12:01 Jean-Christophe PLAGNIOL-VILLARD wrote:
> >>>>>>> On 00:18 Sun 07 Oct , Rafael J. Wysocki wrote:
> >>>>>>>> On Saturday 06 of October 2012 18:14:29 Jean-Christophe PLAGNIOL-VILLARD wrote:
> >>>>>>>>> Hi,
> >>>>>>>>>
> >>>>>>>>> The following changes since commit 5f3d2f2e1a63679cf1c4a4210f2f1cc2f335bef6:
> >>>>>>>>>
> >>>>>>>>> Merge branch 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc (2012-10-06 03:16:12 +0900)
> >>>>>>>>>
> >>>>>>>>> are available in the git repository at:
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> git://git.jcrosoft.org/linux-2.6.git tags/pm_suspend_standby_mem
> >>>>>>>>>
> >>>>>>>>> for you to fetch changes up to b73c8f97aa8e720bd3b921159687d00626c99d63:
> >>>>>>>>>
> >>>>>>>>> arm: at91: drop at91_suspend_entering_slow_clock (2012-10-06 18:06:25 +0800)
> >>>>>>>>>
> >>>>>>>>> ----------------------------------------------------------------
> >>>>>>>>> pm: add suspend_mem and suspend_standby support
> >>>>>>>>>
> >>>>>>>>> Today when we go to suspend we can not knwon at drivers level if we go in
> >>>>>>>>> STANDBY or MEM. Fix this by introducing two new callback suspend_mem and
> >>>>>>>>> suspend_standby.
> >>>>>>>>
> >>>>>>>> No way. Device drivers shouldn't be concerned about that.
> >>>>>>> I do need it on at91 as we swith to slow_clock in MEM suspend and some ip
> >>>>>>> need special handling when switching to slow_clock
> >>>>>>
> >>>>>> Well, my answer to that is: please fix your platform code instead of
> >>>>>> hacking the PM core to work around its problems.
> >>>>> how can I fix drivers pm issue when I no way to known at driver level the
> >>>>> real suspend, the PM core is supposed to proivde the right information to the
> >>>>> drivers so the driver can put it's in the right pm mode. If the pm core can not
> >>>>> provide such inforation the PM core is broken as we will have to do dirty
> >>>>> hack.
> >>>>
> >>>> Why do you need to know the difference in your driver? We used to
> >>>> provide this information a long time ago, but it turned out to not be
> >>>> needed at all and just caused problems.
> >>> because on at91 I need to handle the mem standby at drviers level.
> >>
> >> This is not an answer. You're basically saying "it has to be done this way,
> >> because it has to be done this way".
> >>
> >>> We do it today already by a hack in different drivers at91_udc (usb device),
> >>> atmel_serail and at91_ohci. Those 3 IP have specifci handling when switching
> >>> to mem pm. On at91 when switch to mem we shutdown everything and run form a slow
> >>> clock - this is done at soc level - but those IP have issue and need specific
> >>> care before doing so. Ohterwise when the SoC will wakeup but those IP will not
> >>>
> >>> in this patch series I send the update of those 3 drivers too
> >>> and kill the hack
> >>
> >> Well, let's start over. What's the difference between "suspend to RAM" (mem)
> >> and "standby" on your platform?
> >>
> >>>>> Any generic framework is supposed to evolve for real user need here I've one
> >>>>> so I udpate the core to mach a need
> >>
> >> Yes, if there are more users needing a change. If there's only one, I think not
> >> really.
> >>
> >
> > We came across such a need while supporting various low-power modes in
> > AM335x SoC. I also wanted to put similar proposal, its good that Jean
> > submitted patches and we are having this discussion early.
> >
> > Let me try to describe the need and issue here,
> >
> > In case of AM33xx device, we have different low-power modes supported
> > by HW, for this discussion I will just talk about DeepSleep-0 and
> > StandBy mode supported by HW (few other modes also described in spec)-
> >
> > Below is the Spec definition of these two low-power modes,
>
> Thanks for this summary, which raises a question for me that might be
> slightly unreleated to the general discussion, but still:
>
> I was just looking at the code that ships with the BSP kernel, and the
> approach there is to load a binary firmare blob to the M3 UMEM and then
> communicates with mailbox commands in order to put the system to suspend.
>
Ohh, Great, then you are aware of AM33xx power management support.
As you are aware, M3 here works as a soft-PRCM block, so certain things has
to be done on M3 while entering into low-power state.
> Is this how it should be done in mainline as well or are there any plans
> to implement that behaviour natively?
>
Yes, we will follow similar approach for Mainline, its under development and
soon you will see patches getting submitted to the list for review. The
first step is to get deepsleep-0 support in Mainline and then other will
follow.
Thanks,
Vaibhav
>
> Thanks,
> Daniel
>
>
^ permalink raw reply
* pm: add suspend_mem and suspend_standby support
From: Daniel Mack @ 2012-10-10 9:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <79CD15C6BA57404B839C016229A409A83EB3AF86@DBDE01.ent.ti.com>
On 10.10.2012 11:29, Hiremath, Vaibhav wrote:
> On Wed, Oct 10, 2012 at 14:50:25, Daniel Mack wrote:
>> On 10.10.2012 09:17, Vaibhav Hiremath wrote:
>>> On 10/10/2012 3:42 AM, Rafael J. Wysocki wrote:
>>>> On Tuesday 09 of October 2012 17:17:04 Jean-Christophe PLAGNIOL-VILLARD wrote:
>>>>> On 07:58 Tue 09 Oct , Greg Kroah-Hartman wrote:
>>>>>> On Tue, Oct 09, 2012 at 01:46:33PM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
>>>>>>> On 22:02 Sun 07 Oct , Rafael J. Wysocki wrote:
>>>>>>>> On Sunday 07 of October 2012 15:12:01 Jean-Christophe PLAGNIOL-VILLARD wrote:
>>>>>>>>> On 00:18 Sun 07 Oct , Rafael J. Wysocki wrote:
>>>>>>>>>> On Saturday 06 of October 2012 18:14:29 Jean-Christophe PLAGNIOL-VILLARD wrote:
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> The following changes since commit 5f3d2f2e1a63679cf1c4a4210f2f1cc2f335bef6:
>>>>>>>>>>>
>>>>>>>>>>> Merge branch 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc (2012-10-06 03:16:12 +0900)
>>>>>>>>>>>
>>>>>>>>>>> are available in the git repository at:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> git://git.jcrosoft.org/linux-2.6.git tags/pm_suspend_standby_mem
>>>>>>>>>>>
>>>>>>>>>>> for you to fetch changes up to b73c8f97aa8e720bd3b921159687d00626c99d63:
>>>>>>>>>>>
>>>>>>>>>>> arm: at91: drop at91_suspend_entering_slow_clock (2012-10-06 18:06:25 +0800)
>>>>>>>>>>>
>>>>>>>>>>> ----------------------------------------------------------------
>>>>>>>>>>> pm: add suspend_mem and suspend_standby support
>>>>>>>>>>>
>>>>>>>>>>> Today when we go to suspend we can not knwon at drivers level if we go in
>>>>>>>>>>> STANDBY or MEM. Fix this by introducing two new callback suspend_mem and
>>>>>>>>>>> suspend_standby.
>>>>>>>>>>
>>>>>>>>>> No way. Device drivers shouldn't be concerned about that.
>>>>>>>>> I do need it on at91 as we swith to slow_clock in MEM suspend and some ip
>>>>>>>>> need special handling when switching to slow_clock
>>>>>>>>
>>>>>>>> Well, my answer to that is: please fix your platform code instead of
>>>>>>>> hacking the PM core to work around its problems.
>>>>>>> how can I fix drivers pm issue when I no way to known at driver level the
>>>>>>> real suspend, the PM core is supposed to proivde the right information to the
>>>>>>> drivers so the driver can put it's in the right pm mode. If the pm core can not
>>>>>>> provide such inforation the PM core is broken as we will have to do dirty
>>>>>>> hack.
>>>>>>
>>>>>> Why do you need to know the difference in your driver? We used to
>>>>>> provide this information a long time ago, but it turned out to not be
>>>>>> needed at all and just caused problems.
>>>>> because on at91 I need to handle the mem standby at drviers level.
>>>>
>>>> This is not an answer. You're basically saying "it has to be done this way,
>>>> because it has to be done this way".
>>>>
>>>>> We do it today already by a hack in different drivers at91_udc (usb device),
>>>>> atmel_serail and at91_ohci. Those 3 IP have specifci handling when switching
>>>>> to mem pm. On at91 when switch to mem we shutdown everything and run form a slow
>>>>> clock - this is done at soc level - but those IP have issue and need specific
>>>>> care before doing so. Ohterwise when the SoC will wakeup but those IP will not
>>>>>
>>>>> in this patch series I send the update of those 3 drivers too
>>>>> and kill the hack
>>>>
>>>> Well, let's start over. What's the difference between "suspend to RAM" (mem)
>>>> and "standby" on your platform?
>>>>
>>>>>>> Any generic framework is supposed to evolve for real user need here I've one
>>>>>>> so I udpate the core to mach a need
>>>>
>>>> Yes, if there are more users needing a change. If there's only one, I think not
>>>> really.
>>>>
>>>
>>> We came across such a need while supporting various low-power modes in
>>> AM335x SoC. I also wanted to put similar proposal, its good that Jean
>>> submitted patches and we are having this discussion early.
>>>
>>> Let me try to describe the need and issue here,
>>>
>>> In case of AM33xx device, we have different low-power modes supported
>>> by HW, for this discussion I will just talk about DeepSleep-0 and
>>> StandBy mode supported by HW (few other modes also described in spec)-
>>>
>>> Below is the Spec definition of these two low-power modes,
>>
>> Thanks for this summary, which raises a question for me that might be
>> slightly unreleated to the general discussion, but still:
>>
>> I was just looking at the code that ships with the BSP kernel, and the
>> approach there is to load a binary firmare blob to the M3 UMEM and then
>> communicates with mailbox commands in order to put the system to suspend.
>>
>
> Ohh, Great, then you are aware of AM33xx power management support.
> As you are aware, M3 here works as a soft-PRCM block, so certain things has
> to be done on M3 while entering into low-power state.
>
>> Is this how it should be done in mainline as well or are there any plans
>> to implement that behaviour natively?
>>
>
> Yes, we will follow similar approach for Mainline, its under development and
> soon you will see patches getting submitted to the list for review. The
> first step is to get deepsleep-0 support in Mainline and then other will
> follow.
Ok, great. I'll test them as soon as they hit my mailbox :)
Thanks,
Daniel
^ permalink raw reply
* pm: add suspend_mem and suspend_standby support
From: Jean-Christophe PLAGNIOL-VILLARD @ 2012-10-10 9:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5075210B.3020309@ti.com>
On 12:47 Wed 10 Oct , Vaibhav Hiremath wrote:
>
>
> On 10/10/2012 3:42 AM, Rafael J. Wysocki wrote:
> > On Tuesday 09 of October 2012 17:17:04 Jean-Christophe PLAGNIOL-VILLARD wrote:
> >> On 07:58 Tue 09 Oct , Greg Kroah-Hartman wrote:
> >>> On Tue, Oct 09, 2012 at 01:46:33PM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> >>>> On 22:02 Sun 07 Oct , Rafael J. Wysocki wrote:
> >>>>> On Sunday 07 of October 2012 15:12:01 Jean-Christophe PLAGNIOL-VILLARD wrote:
> >>>>>> On 00:18 Sun 07 Oct , Rafael J. Wysocki wrote:
> >>>>>>> On Saturday 06 of October 2012 18:14:29 Jean-Christophe PLAGNIOL-VILLARD wrote:
> >>>>>>>> Hi,
> >>>>>>>>
> >>>>>>>> The following changes since commit 5f3d2f2e1a63679cf1c4a4210f2f1cc2f335bef6:
> >>>>>>>>
> >>>>>>>> Merge branch 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc (2012-10-06 03:16:12 +0900)
> >>>>>>>>
> >>>>>>>> are available in the git repository at:
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> git://git.jcrosoft.org/linux-2.6.git tags/pm_suspend_standby_mem
> >>>>>>>>
> >>>>>>>> for you to fetch changes up to b73c8f97aa8e720bd3b921159687d00626c99d63:
> >>>>>>>>
> >>>>>>>> arm: at91: drop at91_suspend_entering_slow_clock (2012-10-06 18:06:25 +0800)
> >>>>>>>>
> >>>>>>>> ----------------------------------------------------------------
> >>>>>>>> pm: add suspend_mem and suspend_standby support
> >>>>>>>>
> >>>>>>>> Today when we go to suspend we can not knwon at drivers level if we go in
> >>>>>>>> STANDBY or MEM. Fix this by introducing two new callback suspend_mem and
> >>>>>>>> suspend_standby.
> >>>>>>>
> >>>>>>> No way. Device drivers shouldn't be concerned about that.
> >>>>>> I do need it on at91 as we swith to slow_clock in MEM suspend and some ip
> >>>>>> need special handling when switching to slow_clock
> >>>>>
> >>>>> Well, my answer to that is: please fix your platform code instead of
> >>>>> hacking the PM core to work around its problems.
> >>>> how can I fix drivers pm issue when I no way to known at driver level the
> >>>> real suspend, the PM core is supposed to proivde the right information to the
> >>>> drivers so the driver can put it's in the right pm mode. If the pm core can not
> >>>> provide such inforation the PM core is broken as we will have to do dirty
> >>>> hack.
> >>>
> >>> Why do you need to know the difference in your driver? We used to
> >>> provide this information a long time ago, but it turned out to not be
> >>> needed at all and just caused problems.
> >> because on at91 I need to handle the mem standby at drviers level.
> >
> > This is not an answer. You're basically saying "it has to be done this way,
> > because it has to be done this way".
> >
> >> We do it today already by a hack in different drivers at91_udc (usb device),
> >> atmel_serail and at91_ohci. Those 3 IP have specifci handling when switching
> >> to mem pm. On at91 when switch to mem we shutdown everything and run form a slow
> >> clock - this is done at soc level - but those IP have issue and need specific
> >> care before doing so. Ohterwise when the SoC will wakeup but those IP will not
> >>
> >> in this patch series I send the update of those 3 drivers too
> >> and kill the hack
> >
> > Well, let's start over. What's the difference between "suspend to RAM" (mem)
> > and "standby" on your platform?
> >
> >>>> Any generic framework is supposed to evolve for real user need here I've one
> >>>> so I udpate the core to mach a need
> >
> > Yes, if there are more users needing a change. If there's only one, I think not
> > really.
> >
>
> We came across such a need while supporting various low-power modes in
> AM335x SoC. I also wanted to put similar proposal, its good that Jean
> submitted patches and we are having this discussion early.
>
> Let me try to describe the need and issue here,
>
> In case of AM33xx device, we have different low-power modes supported
> by HW, for this discussion I will just talk about DeepSleep-0 and
> StandBy mode supported by HW (few other modes also described in spec)-
>
> Below is the Spec definition of these two low-power modes,
>
> PowerMode Application state States
> ========================================================================
> DeepSleep0 Everything is preserved Master Oscillator = OFF
> including SDRAM. VDD_MPU = 0.95v
> VDD_CORE = 0.95v
> PD_WKUP = ON
> PD_MPU = OFF
> PD_PER = OFF
> PD_GFX = OFF
> All IOs & RTC supplies are ON
>
>
> Standby Everything is preserved Master Oscillator = ON
> including SDRAM. One PLL is ON
> Only required module clocks VDD_MPU = 0.95v
> are enabled rest are clock VDD_CORE = OPP50
> gated PD_WKUP = ON
> PD_MPU = ON
> PD_PER = ON
> PD_GFX = OFF
> All IOs & RTC supplies are ON
> If more PLLs /power domains/
> modules are required, the
> power will increase
> accordingly
>
>
>
> Now we have two major parameters here, Power Consumption and Latency
> (Sleep + Wakeup). Since DeepSleep-0 is as good as off state, it gives
> very less power consumption Vs huge Latency number, whereas, in case of
> standby the power consumption is more but the Latency is reduced.
>
> In addition to that, there are certain HW related parameters and issues
> contribute to these parameters. For example,
>
> In case of LCD driver the suspend/resume latency is in the range of
> 10msec, which can be reduced if driver knows that he is not entering or
> entered in DeepSleep-0 and choose not to do certain things.
> Another example would be, USB driver, we have seen Latency numbers in
> the range of 200msec, and of which 100 msec can simply be taken away if
> driver knows about the sleep state.
>
>
> I understand that, there is trade-off between power and latency numbers,
> but for certain use-cases latency is more important and it is not
> possible without telling driver about the low-power state.
I work on ST SoC where I have also such standby mode too and similar issue
Best Regards,
J.
^ permalink raw reply
* [Xen-devel] [PATCH 5/9] ARM: Xen: fix initial build problems:
From: Ian Campbell @ 2012-10-10 9:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201210091819.34310.arnd@arndb.de>
On Tue, 2012-10-09 at 19:19 +0100, Arnd Bergmann wrote:
> On Tuesday 09 October 2012, Ian Campbell wrote:
> > On Tue, 2012-10-09 at 16:39 +0100, Arnd Bergmann wrote:
> > > On Tuesday 09 October 2012, Ian Campbell wrote:
> > > > > * The tmem hypercall is not available on ARM
> > > > >
> > > > > * ARMv6 does not support cmpxchg on 16-bit words that are used in the
> > > >
> > > > missing the end of this sentence?
> > >
> > > Right, I meant to say
> > >
> > > * ARMv6 does not support cmpxchg on 16-bit words that are used in the
> > > Xen grant table code, so we must ensure that Xen support is only built
> > > on ARMv7-only kernels not combined ARMv6/v7 kernels.
> > >
> > > This should be fixed differently in the future.
> >
> > Is this is a build time failure because gcc/gas/etc refuses to generate
> > these instructions if it is configured for v6?
> >
> > I ask because if it is only a runtime issue then we can reason that if
> > we are running Xen specific grant table code, then we must be running on
> > Xen and therefore must necessarily be running on a v7 (because Xen only
> > support v7+virt extensions) even if the kernel happens to be capable of
> > running on v6 too.
>
> The underlying reason of course is that ARMv6 doesn't have those
> instructions. The symptom you see is a link error because gcc emits
> a reference to the (intentionally missing) __bad_cmpxchg() function
> from
OK, then your fix is the best one for now.
> [...]
> The possible solutions I can see for this are:
>
> * change the grant table format to use 32 bits for the flags on ARM
> * change the code to always cmpxchg the entire 32 bit word including the flags.
I'd need to check the grant table semantics to see if this will be
possible.
> * implement your own cmpxchg wrapper that may be implemented using a spinlock
> rather than cmpxchg if ARMv6 is enabled.
Even if ARMv6 is enabled the grant table code will never be running on
one so so it might be ok to just have our own wrapper which
unconditionally uses the v7 instruction? That might upset gas though.
>
> Arnd
^ permalink raw reply
* [PATCH] [ARM] Use AT() in the linker script to create correct program headers
From: Dave Martin @ 2012-10-10 9:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121009182514.GF4124@obsidianresearch.com>
On Tue, Oct 09, 2012 at 12:25:14PM -0600, Jason Gunthorpe wrote:
> On Mon, Oct 08, 2012 at 11:46:49AM +0100, Dave Martin wrote:
>
> > > Yes, but we still need rely on complex code like I2C/MTD to create a
> > > correct DTB, which again puts us back to patching the kernel for that
> > > functionality.
> >
> > I'm still confused as to where this complexity is coming from.
> >
> > If you need to run some complex I2C and MTD code to generate the DT, what
> > is that code doing? If it is probing to get the information, then can you
> > avoid putting the info in the DT at all? Primarily the DT is to describe
> > those aspects of the hardware which can't be probed.
>
> At manufacturing the unit is programmed with a small datastructure that
> contains all the unique ID's (MAC addresses, etc), manufacturing
> variations (ie vendor A or B was used for a socket) and other
> ancillary data.
As a side comment, some things such as MAC addresses can be probed and
set from userspace after kernel boot, assuming that you have a way
to fetch the device description blob from userspace. If it's accessible
via MTD I'm guessing you may have some chance of doing that.
Identifying the board variant is harder to defer though.
> So a fair amount of I2C and MTD stack is required just to fetch this
> structure - a full CFI probe, for instance, is needed in the NOR flash
> case just to locate the structure.
>
> Once read, things like MAC addresses are copied into the DTB, and
> certain sections of the DTB are NOP'd out - we have stanzas for chip
> vendor A and vendor B, the one that was not put on the board is
> replaced with NOP.
>
> Similar to the A/B fix, a further fixup is done based on a runtime
> probe of the programmable devices to learn their current
> configuration/memory map.
>
> It seems desirable to present a complete/correct DTB to the kernel,
> it doesn't seem there are great places to hook in custom discovery
> procedures.
>
> From a maintenance perspective we already have to test/etc the kernel
> code for all of this, we don't want to do that twice by duplicating
> this stuff outside the kernel.
OK, that gives me a good understanding of what you're trying to achieve
here.
However, I worry that if you have to run hardware-dependent code in
order to fetch or generate parts of the DT, then we have a chicken-
and-egg problem with no guaranteed solution with the frameworks that
exist today -- although I am not familiar with how DT gets used on
all other arches, so you might have counterexamples I'm not aware of.
At least in ARM-land, the DT is inherently monolithic and static: the
DT is not expected to change once you enter the kernel.
Of course, more or less anything can be done with local patches, but
merging such functionality in a clean way might be a challenge.
> > Otherwise, you that have a few static configurations: you could have one
> > pre-baked DT per hardware platform, and choose the correct one once you
> > have detected the platform.
>
> We do that too, for instance the PPC kernel we build supports 4
> different circuit boards, each served by a separate DTB, that needs a
> fixup pass.
>
> I think the biggest DTB describes about 49 devices..
>
> > > Where the 'dev tree provider' would use the stored bootloader
> > > registers and any other information to return the proper DTB.
> >
> > It would need developing a bit, but something like that might be
> > possible -- it should probably be discussed via devicetree-discuss.
> >
> > If it is doing anything less trivial than picking a pre-baked DT, the
> > rationale would need to be carefully argued.
>
> I'm not sure there is a great interest in this? What are other folks
> working on production embedded stuff doing? I suppose that will be
> more clear as device tree is rolled out.
For now, the architecturally simplest solution still seems to me to be
to write your own boot shim which customises the DT before booting the
kernel. As discussed, this can continue to look like a simple ELF image
from the bootloader's point of view -- but I appreciate that it will
involve effort and some duplication of some low-level driver components.
If we could do dynamic DT properly (either fully dynamic, or dynamic
in a more constrained way as in your suggested patch), that would
provided an architected way to solve this problem from within the kernel.
This could certainly be worth raising on devicetree-discuss.
Your problem is unlikely to affect people outside the embedded space
too much, but it doesn't sound likely to be unique.
Cheers
---Dave
^ permalink raw reply
* [RFC PATCH 1/3] amba-clcd: Add Device Tree support to amba-clcd driver
From: Jon Medhurst (Tixy) @ 2012-10-10 10:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1348070666-9153-2-git-send-email-ryan.harkin@linaro.org>
On Wed, 2012-09-19 at 17:04 +0100, Ryan Harkin wrote:
> Add support to parse the display configuration from device tree.
>
> If the board does not provide platform specific functions in the struct
> clcd_board contained with the amba device info, then defaults are provided
> by the driver.
>
> The device tree configuration can either ask for a DMA setup or provide a
> framebuffer address to be remapped into the driver.
>
> Signed-off-by: Ryan Harkin <ryan.harkin@linaro.org>
> ---
<big snip>
> static int clcdfb_probe(struct amba_device *dev, const struct amba_id *id)
> {
> struct clcd_board *board = dev->dev.platform_data;
> struct clcd_fb *fb;
> int ret;
>
> +#ifdef CONFIG_OF
> + if (dev->dev.of_node) {
> + const __be32 *prop;
> + int len, na, ns;
> + phys_addr_t reg_base;
> +
> + na = of_n_addr_cells(dev->dev.of_node);
> + ns = of_n_size_cells(dev->dev.of_node);
> +
> + prop = of_get_property(dev->dev.of_node, "reg", &len);
> + if (WARN_ON(!prop || len < (na + ns) * sizeof(*prop)))
> + return -EINVAL;
> + reg_base = of_read_number(prop, na);
> +
> + if (dev->res.start != reg_base)
> + return -EINVAL;
When the motherboard CLCD is used, the CLCD node is under the iofga node
and has a reg value equal to the offset from the start of the iofgpa,
however dev->res.start holds the calculated address of the start of the
iofga region plus the offset of the clcd, this means that the above
check fails.
The question is, what is the purpose of this check? Can't we rely on the
value of dev->res.start being consistent with dev->dev.of_node and so
just drop all the above code from "const __be32 *prop" onwards?
--
Tixy
^ permalink raw reply
* [PATCH] ARM: dts: mxs: add the "clock-names" for gpmi-nand
From: Huang Shijie @ 2012-10-10 10:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201210101237.13640.marex@denx.de>
The current DT nodes for mx23/mx28 miss the `clocks-names` item for gpmi-nand.
So the gpmi-nand driver could not find the proper clock.
This patch fixes this issue.
Signed-off-by: Huang Shijie <b32955@freescale.com>
---
arch/arm/boot/dts/imx23.dtsi | 1 +
arch/arm/boot/dts/imx28.dtsi | 1 +
2 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/imx23.dtsi b/arch/arm/boot/dts/imx23.dtsi
index 9ca4ca7..6d31aa3 100644
--- a/arch/arm/boot/dts/imx23.dtsi
+++ b/arch/arm/boot/dts/imx23.dtsi
@@ -69,6 +69,7 @@
interrupts = <13>, <56>;
interrupt-names = "gpmi-dma", "bch";
clocks = <&clks 34>;
+ clock-names = "gpmi_io";
fsl,gpmi-dma-channel = <4>;
status = "disabled";
};
diff --git a/arch/arm/boot/dts/imx28.dtsi b/arch/arm/boot/dts/imx28.dtsi
index e16d631..55c57ea 100644
--- a/arch/arm/boot/dts/imx28.dtsi
+++ b/arch/arm/boot/dts/imx28.dtsi
@@ -85,6 +85,7 @@
interrupts = <88>, <41>;
interrupt-names = "gpmi-dma", "bch";
clocks = <&clks 50>;
+ clock-names = "gpmi_io";
fsl,gpmi-dma-channel = <4>;
status = "disabled";
};
--
1.7.0.4
^ permalink raw reply related
* [PATCH 03/11] fsmc/nand: Support multiple banks connected to controller
From: Vipin Kumar @ 2012-10-10 10:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121009115523.GM12801@game.jcrosoft.org>
On 10/9/2012 5:25 PM, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 16:14 Tue 09 Oct , Vipin Kumar wrote:
>> Support up to max_banks number of banks in fsmc driver.
>>
>> Signed-off-by: Vipin Kumar<vipin.kumar@st.com>
> please rebase this over my patch that drop -off to resource
Sure, I will do that. I actually planned to do it but forgot while
sending it
>> ---
>> .../devicetree/bindings/mtd/fsmc-nand.txt | 2 ++
>> arch/arm/boot/dts/spear300.dtsi | 1 +
>> arch/arm/boot/dts/spear310.dtsi | 1 +
>> arch/arm/boot/dts/spear320.dtsi | 1 +
>> arch/arm/boot/dts/spear600.dtsi | 1 +
>> arch/arm/mach-u300/core.c | 1 +
>> drivers/mtd/nand/fsmc_nand.c | 26 +++++++++++++++-------
>> include/linux/mtd/fsmc.h | 2 +-
>> 8 files changed, 26 insertions(+), 9 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/mtd/fsmc-nand.txt b/Documentation/devicetree/bindings/mtd/fsmc-nand.txt
>> index e2c663b..29d1a2f 100644
>> --- a/Documentation/devicetree/bindings/mtd/fsmc-nand.txt
>> +++ b/Documentation/devicetree/bindings/mtd/fsmc-nand.txt
>> @@ -6,6 +6,7 @@ Required properties:
>> - reg-names: Should contain the reg names "fsmc_regs" and "nand_data"
>> - st,ale-off : Chip specific offset to ALE
>> - st,cle-off : Chip specific offset to CLE
>> +- maxbanks: Number of banks supported by SoC
> make it optionnal will simplify the binding with 1 by default and will allow
> to avoid issue
>
hmmm....OK
I think you are right. May be optional with a default of 1 is a better
option
>>
>> Optional properties:
>> - bank-width : Width (in bytes) of the device. If not present, the width
>> @@ -23,6 +24,7 @@ Example:
>> reg-names = "fsmc_regs", "nand_data";
>> st,ale-off =<0x20000>;
>> st,cle-off =<0x10000>;
>> + maxbanks =<1>;
>>
>> bank-width =<1>;
>> nand-skip-bbtscan;
>> diff --git a/arch/arm/boot/dts/spear300.dtsi b/arch/arm/boot/dts/spear300.dtsi
>> index ed3627c..19e2328 100644
>> --- a/arch/arm/boot/dts/spear300.dtsi
>> +++ b/arch/arm/boot/dts/spear300.dtsi
>> @@ -42,6 +42,7 @@
>> reg-names = "fsmc_regs", "nand_data";
>> st,ale-off =<0x20000>;
>> st,cle-off =<0x10000>;
>> + maxbanks =<1>;
>> status = "disabled";
>> };
>>
>> diff --git a/arch/arm/boot/dts/spear310.dtsi b/arch/arm/boot/dts/spear310.dtsi
>> index 62fc4fb..0272afb3 100644
>> --- a/arch/arm/boot/dts/spear310.dtsi
>> +++ b/arch/arm/boot/dts/spear310.dtsi
>> @@ -36,6 +36,7 @@
>> reg-names = "fsmc_regs", "nand_data";
>> st,ale-off =<0x10000>;
>> st,cle-off =<0x20000>;
>> + maxbanks =<1>;
>> status = "disabled";
>> };
>>
>> diff --git a/arch/arm/boot/dts/spear320.dtsi b/arch/arm/boot/dts/spear320.dtsi
>> index 1f49d69..69fe50d 100644
>> --- a/arch/arm/boot/dts/spear320.dtsi
>> +++ b/arch/arm/boot/dts/spear320.dtsi
>> @@ -42,6 +42,7 @@
>> reg-names = "fsmc_regs", "nand_data";
>> st,ale-off =<0x20000>;
>> st,cle-off =<0x10000>;
>> + maxbanks =<1>;
>> status = "disabled";
>> };
>>
>> diff --git a/arch/arm/boot/dts/spear600.dtsi b/arch/arm/boot/dts/spear600.dtsi
>> index a3c36e4..6ed57c8 100644
>> --- a/arch/arm/boot/dts/spear600.dtsi
>> +++ b/arch/arm/boot/dts/spear600.dtsi
>> @@ -71,6 +71,7 @@
>> reg-names = "fsmc_regs", "nand_data";
>> st,ale-off =<0x20000>;
>> st,cle-off =<0x10000>;
>> + maxbanks =<1>;
>> status = "disabled";
>> };
>>
>> diff --git a/arch/arm/mach-u300/core.c b/arch/arm/mach-u300/core.c
>> index 03acf18..5ea9f71 100644
>> --- a/arch/arm/mach-u300/core.c
>> +++ b/arch/arm/mach-u300/core.c
>> @@ -1546,6 +1546,7 @@ static struct fsmc_nand_platform_data nand_platform_data = {
>> .width = FSMC_NAND_BW8,
>> .ale_off = PLAT_NAND_ALE,
>> .cle_off = PLAT_NAND_CLE,
>> + .max_banks = 1,
>> };
>>
>> static struct platform_device nand_device = {
>> diff --git a/drivers/mtd/nand/fsmc_nand.c b/drivers/mtd/nand/fsmc_nand.c
>> index bd89580..fc6a044 100644
>> --- a/drivers/mtd/nand/fsmc_nand.c
>> +++ b/drivers/mtd/nand/fsmc_nand.c
>> @@ -298,6 +298,7 @@ static struct fsmc_eccplace fsmc_ecc4_sp_place = {
>> * - Word access (CPU)
>> * - None (Use driver default ie bus width specific
>> * CPU access)
>> + * @max_banks: Maximum number of banks supported
>> * @select_chip: Select a particular bank
>> *
>> * @data_pa: NAND Physical port for Data
>> @@ -325,6 +326,7 @@ struct fsmc_nand_data {
>> struct mtd_partition *partitions;
>> unsigned int nr_partitions;
>> enum access_mode mode;
>> + uint32_t max_banks;
>> void (*select_chip)(uint32_t bank, uint32_t busw);
>>
>> /* Virtual/Physical addresses for CPU/DMA access */
>> @@ -343,6 +345,7 @@ static void fsmc_select_chip(struct mtd_info *mtd, int chipnr)
>>
>> host = container_of(mtd, struct fsmc_nand_data, mtd);
>>
>> + host->bank = chipnr;
>> switch (chipnr) {
>> case -1:
>> chip->cmd_ctrl(mtd, NAND_CMD_NONE, 0 | NAND_CTRL_CHANGE);
>> @@ -889,6 +892,7 @@ static int __devinit fsmc_nand_probe_config_dt(struct platform_device *pdev,
>> of_property_read_u32(np, "st,cle-off",&pdata->cle_off);
>> if (of_get_property(np, "nand-skip-bbtscan", NULL))
>> pdata->options = NAND_SKIP_BBTSCAN;
>> + of_property_read_u32(np, "maxbanks",&pdata->max_banks);
>>
>> return 0;
>> }
>> @@ -915,7 +919,7 @@ static int __init fsmc_nand_probe(struct platform_device *pdev)
>> struct resource *res;
>> dma_cap_mask_t mask;
>> int ret = 0;
>> - u32 pid;
>> + u32 pid, bank;
>> int i;
>>
>> if (np) {
>> @@ -1023,13 +1027,13 @@ static int __init fsmc_nand_probe(struct platform_device *pdev)
>> AMBA_PART_BITS(pid), AMBA_MANF_BITS(pid),
>> AMBA_REV_BITS(pid), AMBA_CONFIG_BITS(pid));
>>
>> - host->bank = pdata->bank;
>> host->select_chip = pdata->select_bank;
>> host->partitions = pdata->partitions;
>> host->nr_partitions = pdata->nr_partitions;
>> host->dev =&pdev->dev;
>> host->dev_timings = pdata->nand_timings;
>> host->mode = pdata->mode;
>> + host->max_banks = pdata->max_banks;
>>
>> if (host->mode == USE_DMA_ACCESS)
>> init_completion(&host->dma_access_complete);
>> @@ -1083,9 +1087,10 @@ static int __init fsmc_nand_probe(struct platform_device *pdev)
>> break;
>> }
>>
>> - fsmc_nand_setup(host->regs_va, host->bank,
>> - nand->options& NAND_BUSWIDTH_16,
>> - host->dev_timings);
>> + for (bank = 0; bank< host->max_banks; bank++)
>> + fsmc_nand_setup(host->regs_va, bank,
>> + nand->options& NAND_BUSWIDTH_16,
>> + host->dev_timings);
>>
>> if (AMBA_REV_BITS(host->pid)>= 8) {
>> nand->ecc.read_page = fsmc_read_page_hwecc;
>> @@ -1230,11 +1235,16 @@ static int fsmc_nand_suspend(struct device *dev)
>> static int fsmc_nand_resume(struct device *dev)
>> {
>> struct fsmc_nand_data *host = dev_get_drvdata(dev);
>> + uint32_t bank;
>> +
>> if (host) {
>> clk_prepare_enable(host->clk);
>> - fsmc_nand_setup(host->regs_va, host->bank,
>> - host->nand.options& NAND_BUSWIDTH_16,
>> - host->dev_timings);
>> +
>> + for (bank = 0; bank< host->max_banks; bank++)
>> + fsmc_nand_setup(host->regs_va, bank,
>> + host->nand.options& NAND_BUSWIDTH_16,
>> + host->dev_timings);
>> +
>> }
>> return 0;
>> }
>> diff --git a/include/linux/mtd/fsmc.h b/include/linux/mtd/fsmc.h
>> index b200292..f0ab734 100644
>> --- a/include/linux/mtd/fsmc.h
>> +++ b/include/linux/mtd/fsmc.h
>> @@ -153,7 +153,7 @@ struct fsmc_nand_platform_data {
>> unsigned int nr_partitions;
>> unsigned int options;
>> unsigned int width;
>> - unsigned int bank;
>> + unsigned int max_banks;
>>
>> /* CLE, ALE offsets */
>> unsigned int cle_off;
>> --
>> 1.7.11.4
>>
> .
>
^ permalink raw reply
* [PATCH v2] USB: usb-skeleton.c: fix compilation error and restore kref_put on fail in skel_open
From: Constantine Shulyupin @ 2012-10-10 10:32 UTC (permalink / raw)
To: linux-arm-kernel
From: Constantine Shulyupin <const@MakeLinux.com>
Function skel_open increments usage count for the device with kref_get and the usage count should be decremented on the function failure.
Some last changes in function skel_open and finally commit
52a7499 Revert "USB: usb-skeleton.c: fix open/disconnect race"
introduced a bug in function skel_open, which this patch fixes.
--
Changelog:
-- Fixed accordinly feedback of Oliver Neukum oneukum at suse.de: also need to drop the lock.
Signed-off-by: Constantine Shulyupin <const@MakeLinux.com>
---
drivers/usb/usb-skeleton.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/usb-skeleton.c b/drivers/usb/usb-skeleton.c
index 0616f23..2025d03 100644
--- a/drivers/usb/usb-skeleton.c
+++ b/drivers/usb/usb-skeleton.c
@@ -113,8 +113,9 @@ static int skel_open(struct inode *inode, struct file *file)
mutex_lock(&dev->io_mutex);
retval = usb_autopm_get_interface(interface);
- if (retval)
- goto out_err;
+ if (retval) {
+ kref_put(&dev->kref, skel_delete);
+ }
/* save our object in the file's private structure */
file->private_data = dev;
--
1.7.9.5
^ permalink raw reply related
* [PATCH 10/11] fsmc/nand: Add sw bch support for ecc calculation/correction
From: Vipin Kumar @ 2012-10-10 10:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121009115023.GK12801@game.jcrosoft.org>
On 10/9/2012 5:20 PM, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 16:14 Tue 09 Oct , Vipin Kumar wrote:
>> Signed-off-by: Vipin Kumar<vipin.kumar@st.com>
>> ---
>> .../devicetree/bindings/mtd/fsmc-nand.txt | 2 +
>> drivers/mtd/nand/fsmc_nand.c | 156 +++++++++++++--------
>> include/linux/mtd/fsmc.h | 3 +
>> 3 files changed, 106 insertions(+), 55 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/mtd/fsmc-nand.txt b/Documentation/devicetree/bindings/mtd/fsmc-nand.txt
>> index 598bca2..dcf513b 100644
>> --- a/Documentation/devicetree/bindings/mtd/fsmc-nand.txt
>> +++ b/Documentation/devicetree/bindings/mtd/fsmc-nand.txt
>> @@ -30,6 +30,8 @@ Optional properties:
>> - st,rb-gpios: When the st,ready-busy is defined as "rb-gpio", a gpio
>> pin number is defined in this property
>>
>> +- nand-sw-ecc: boolean indicating whether s/w ecc is supported
>> +
> please use the generic binding
> - nand-ecc-mode = xx
Thanks for pointing. I will do the needful
>> Example:
>>
>> fsmc: flash at d1800000 {
>> diff --git a/drivers/mtd/nand/fsmc_nand.c b/drivers/mtd/nand/fsmc_nand.c
>> index 762cf83..ff84468 100644
>> --- a/drivers/mtd/nand/fsmc_nand.c
>> +++ b/drivers/mtd/nand/fsmc_nand.c
>> @@ -946,6 +946,9 @@ static int __devinit fsmc_nand_probe_config_dt(struct platform_device *pdev,
>> } else
>> pdata->rbpin.use_pin = FSMC_RB_WAIT;
>>
>> + if (of_property_read_bool(np, "nand-sw-ecc"))
>> + pdata->sw_ecc = true;
>> +
> of_get_nand_ecc_mode
>
Sure
-Vipin
^ permalink raw reply
* [PATCH] ARM: dts: mxs: add the `clock-names` for gpmi-nand
From: Marek Vasut @ 2012-10-10 10:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349849740-14090-1-git-send-email-b32955@freescale.com>
Dear Huang Shijie,
> The current DT nodes for mx23/mx28 miss the `clocks-names` item for
> gpmi-nand. So the gpmi-nand driver could not find the proper clock.
>
> This patch fixes this issue.
>
> Signed-off-by: Huang Shijie <b32955@freescale.com>
[...]
One more rant: Can you discard that weird backtick in the patch subject? Maybe
use '' ?
Best regards,
Marek Vasut
^ permalink raw reply
* [Xen-devel] [PATCH 5/9] ARM: Xen: fix initial build problems:
From: Arnd Bergmann @ 2012-10-10 11:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349862394.10070.23.camel@zakaz.uk.xensource.com>
On Wednesday 10 October 2012, Ian Campbell wrote:
> > * implement your own cmpxchg wrapper that may be implemented using a spinlock
> > rather than cmpxchg if ARMv6 is enabled.
>
> Even if ARMv6 is enabled the grant table code will never be running on
> one so so it might be ok to just have our own wrapper which
> unconditionally uses the v7 instruction? That might upset gas though.
Yes, that would be possible. You can tell gas to ignore the instruction
set in this case. If you do this, you can implement the update functions
more efficiently using direct ldrexh/strexh in assembler to avoid doing
two nested loops. I assume that you don't need the v1 grant table
code on ARM anyway, so the only code you need to look at is
while (!((flags = *pflags) & GTF_transfer_committed)) {
if (sync_cmpxchg(pflags, flags, 0) == flags)
return 0;
cpu_relax();
}
which should transform nicely into a few lines of inline assembly.
Arnd
^ permalink raw reply
* [Linaro-mm-sig] [PATCHv9 00/25] Integration of videobuf2 with DMABUF
From: Kyungmin Park @ 2012-10-10 11:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121010075418.6a18a867@redhat.com>
On 10/10/12, Mauro Carvalho Chehab <mchehab@redhat.com> wrote:
> Hi,
>
> Em Tue, 02 Oct 2012 16:27:11 +0200
> Tomasz Stanislawski <t.stanislaws@samsung.com> escreveu:
>
>> Hello everyone,
>> This patchset adds support for DMABUF [2] importing and exporting to V4L2
>> stack.
>>
>> v9:
>> - rebase on 3.6
>> - change type for fs to __s32
>> - add support for vb2_ioctl_expbuf
>> - remove patch 'v4l: vb2: add support for DMA_ATTR_NO_KERNEL_MAPPING',
>> it will be posted as a separate patch
>> - fix typos and style in Documentation (from Hans Verkuil)
>> - only vb2-core and vb2-dma-contig selects DMA_SHARED_BUFFER in Kconfig
>> - use data_offset and length while queueing DMABUF
>> - return the most recently used fd at VIDIOC_DQBUF
>> - use (buffer-type, index, plane) tuple instead of mem_offset
>> to identify a for exporting (from Hans Verkuil)
>> - support for DMABUF mmap in vb2-dma-contig (from Laurent Pinchart)
>> - add testing alignment of vaddr and size while verifying userptr
>> against DMA capabilities (from Laurent Pinchart)
>> - substitute VM_DONTDUMP with VM_RESERVED
>> - simplify error handling in vb2_dc_get_dmabuf (from Laurent Pinchart)
>
> For now, NACK. See below.
Sad news!
It's failed to merge by very poor samsung board support at mainline.
CC arm & samsung mailing list.
Thank you,
Kyungmin Park
>
> I spent 4 days trying to setup an environment that would allow testing
> DMABUF with video4linux without success (long story, see below). Also,
> Laurent tried the same without any luck, and it seems that it even
> corrupted his test machine.
>
> Basically Samsung generously donated me two boards that it could be
> used on this test (Origen and SMDK310). None of them actually worked
> with the upstream kernel: patches are needed to avoid OOPSes on
> Origen; both Origen/SMDK310 defconfigs are completely broken, and drivers
> don't even boot if someone tries to use the Kernel's defconfigs.
>
> Even after spending _days_ trying to figure out the needed .config options
> (as the config files are not easily available), both boards have... issues:
>
> - lack of any display output driver at SMDK310;
>
> - lack of any network driver at Origen: it seems that none of
> the available network options on Origen was upstreamed: no Bluetooth, no
> OTG,
> no Wifi.
>
> The only test I was able to do (yesterday, late night), the DMABUF caused
> an OOPS at the Origen board. So, for sure it is not ready for upstream.
>
> It is now, too late for 3.7. I might consider it to 3.8, if something
> can be done to fix the existing issues, and setup a proper setup, using
> the upstream Kernel.
>
> Regards,
> Mauro
>
> _______________________________________________
> Linaro-mm-sig mailing list
> Linaro-mm-sig at lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/linaro-mm-sig
>
^ permalink raw reply
* [PATCH] ARM: backtrace: avoid crash on large invalid fp value
From: Dave Martin @ 2012-10-10 11:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349851572-9967-1-git-send-email-toddpoynor@google.com>
On Tue, Oct 09, 2012 at 11:46:12PM -0700, Todd Poynor wrote:
> Invalid frame pointer (signed) -4 <= fp <= -1 defeats check for too high
> on overflow.
>
> Signed-off-by: Todd Poynor <toddpoynor@google.com>
> ---
> arch/arm/kernel/stacktrace.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/kernel/stacktrace.c b/arch/arm/kernel/stacktrace.c
> index 00f79e5..6315162 100644
> --- a/arch/arm/kernel/stacktrace.c
> +++ b/arch/arm/kernel/stacktrace.c
> @@ -31,7 +31,7 @@ int notrace unwind_frame(struct stackframe *frame)
> high = ALIGN(low, THREAD_SIZE);
>
> /* check current frame pointer is within bounds */
> - if (fp < (low + 12) || fp + 4 >= high)
> + if (fp < (low + 12) || fp >= high - 4)
> return -EINVAL;
>
> /* restore the registers from the stack frame */
sp and fp can still be complete garbage in the case of a corrupted frame,
so low + 12 can still overflow and cause us to read beyond the stack base.
A more robust patch might be as follows. This also checks for misaligned
fp and sp values, since those indicate corruption and there can be no
sensible way to interpret the resulting frame in that case.
Also, according to the definition of current_thread_info(),
IS_ALIGNED(sp, THREAD_SIZE) indicates a full stack extending from sp
to sp + THREAD_SIZE, and not an empty stack extending from sp -
THREAD_SIZE to sp. We cannot backtrace this situation anyway, since
that would imply that the frame record extends beyond the stack...
but this patch tidies it up in the interest of clarity.
Cheers
---Dave
(untested)
diff --git a/arch/arm/kernel/stacktrace.c b/arch/arm/kernel/stacktrace.c
index 00f79e5..fec82be 100644
--- a/arch/arm/kernel/stacktrace.c
+++ b/arch/arm/kernel/stacktrace.c
@@ -28,10 +28,20 @@ int notrace unwind_frame(struct stackframe *frame)
/* only go to a higher address on the stack */
low = frame->sp;
- high = ALIGN(low, THREAD_SIZE);
+ if (!IS_ALIGNED(fp, 4))
+ return -EINVAL;
+
+ /*
+ * low + 1 here ensures that high > sp, consistent with the
+ * definition of current_thread_info().
+ * We subtract 1 to compute the highest allowable byte address.
+ * Otherwise, we might get high == 0 which would confuse our
+ * comparisons.
+ */
+ high = ALIGN(low + 1, THREAD_SIZE) - 1;
/* check current frame pointer is within bounds */
- if (fp < (low + 12) || fp + 4 >= high)
+ if (fp < 12 || fp - 12 < low || fp > high)
return -EINVAL;
/* restore the registers from the stack frame */
@@ -39,6 +49,10 @@ int notrace unwind_frame(struct stackframe *frame)
frame->sp = *(unsigned long *)(fp - 8);
frame->pc = *(unsigned long *)(fp - 4);
+ /* Do not claim the frame is valid if if is obviously corrupt: */
+ if (!IS_ALIGNED(frame->fp, 4))
+ return -EINVAL;
+
return 0;
}
#endif
^ permalink raw reply related
* [PATCH] ARM: dts: mxs: add the "clock-names" for gpmi-nand
From: Marek Vasut @ 2012-10-10 11:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349864829-19565-1-git-send-email-b32955@freescale.com>
Dear Huang Shijie,
> The current DT nodes for mx23/mx28 miss the `clocks-names` item for
> gpmi-nand. So the gpmi-nand driver could not find the proper clock.
>
> This patch fixes this issue.
>
> Signed-off-by: Huang Shijie <b32955@freescale.com>
[...]
Reviewed-by: Marek Vasut <marex@denx.de>
I will test later today.
Best regards,
Marek Vasut
^ permalink raw reply
* [PATCH 0/8] clk: ux500: Fixup smp_twd clk for clk notifiers
From: Ulf Hansson @ 2012-10-10 11:42 UTC (permalink / raw)
To: linux-arm-kernel
From: Ulf Hansson <ulf.hansson@linaro.org>
This collection of patches fixup smp_twd clk so clk notifiers can use it
properly.
An armss clk is added which is used from cpufreq driver to update frequency
instead of using the prcmu_set|get_arm_opp API. The smp_twd clk is converted
to a fixed_factor clk with armss clk as parent and with a fixed divider of two.
Therfore it will be updated when armss clk is updated and thus corresponding
notifications will be triggered.
I would prefer if these patches could be merged through Mike Turquette's clk
tree, if he think it seems feasible of course. For the mfd and cpufreq patches
I hope Samuel Ortiz and Rafael J. Wysocki if fine by acking patches. If there
are other preferred way of dealing with this I am happy to change setup.
Do note that, the four below patches have already been sent and most of them
have already been acked/reviewed but not merged. I have included them in this
series to provide full overview for reviewers.
ARM: ux500: Remove cpufreq platform device
mfd: db8500: Provide cpufreq table as platform data
cpufreq: db8500: Register as a platform driver
cpufreq: db8500: Fetch cpufreq table from platform data
Patches are based on Linus Torvalds tree with latest commit as of okt 10.
Ulf Hansson (8):
ARM: ux500: Remove cpufreq platform device
mfd: db8500: Provide cpufreq table as platform data
cpufreq: db8500: Register as a platform driver
cpufreq: db8500: Fetch cpufreq table from platform data
mfd: db8500: Connect ARMSS clk to ARM OPP
clk: ux500: Support for prcmu_scalable_rate clock
clk: ux500: Add armss clk and fixup smp_twd clk for u8500
cpufreq: db8500: Use armss clk to update frequency
arch/arm/mach-ux500/cpu-db8500.c | 6 ---
drivers/clk/ux500/clk-prcmu.c | 17 +++++++
drivers/clk/ux500/clk.h | 6 +++
drivers/clk/ux500/u8500_clk.c | 14 +++---
drivers/cpufreq/db8500-cpufreq.c | 101 +++++++++++++++++++++-----------------
drivers/mfd/db8500-prcmu.c | 82 ++++++++++++++++++++++++++-----
6 files changed, 155 insertions(+), 71 deletions(-)
--
1.7.10
^ permalink raw reply
* [PATCH 1/8] ARM: ux500: Remove cpufreq platform device
From: Ulf Hansson @ 2012-10-10 11:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349869349-8070-1-git-send-email-ulf.hansson@stericsson.com>
From: Ulf Hansson <ulf.hansson@linaro.org>
The cpufreq device is already added from the prcmu driver as
a mfd child device.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Jonas Aaberg <jonas.aberg@stericsson.com>
---
arch/arm/mach-ux500/cpu-db8500.c | 6 ------
1 file changed, 6 deletions(-)
diff --git a/arch/arm/mach-ux500/cpu-db8500.c b/arch/arm/mach-ux500/cpu-db8500.c
index bcdfe6b..41b2779 100644
--- a/arch/arm/mach-ux500/cpu-db8500.c
+++ b/arch/arm/mach-ux500/cpu-db8500.c
@@ -214,9 +214,6 @@ struct device * __init u8500_init_devices(struct ab8500_platform_data *ab8500)
db8500_add_gpios(parent);
db8500_add_usb(parent, usb_db8500_rx_dma_cfg, usb_db8500_tx_dma_cfg);
- platform_device_register_data(parent,
- "cpufreq-u8500", -1, NULL, 0);
-
for (i = 0; i < ARRAY_SIZE(platform_devs); i++)
platform_devs[i]->dev.parent = parent;
@@ -236,9 +233,6 @@ struct device * __init u8500_of_init_devices(void)
db8500_add_usb(parent, usb_db8500_rx_dma_cfg, usb_db8500_tx_dma_cfg);
- platform_device_register_data(parent,
- "cpufreq-u8500", -1, NULL, 0);
-
u8500_dma40_device.dev.parent = parent;
/*
--
1.7.10
^ permalink raw reply related
* [PATCH 2/8] mfd: db8500: Provide cpufreq table as platform data
From: Ulf Hansson @ 2012-10-10 11:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349869349-8070-1-git-send-email-ulf.hansson@stericsson.com>
From: Ulf Hansson <ulf.hansson@linaro.org>
The cpufreq table needs dynamically update due to what the PRCMU
firmware is supporting. The table is then provided through to the
mfd child device as platform data.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Jonas Aaberg <jonas.aberg@stericsson.com>
Cc: Samuel Ortiz <sameo@linux.intel.com>
---
drivers/mfd/db8500-prcmu.c | 22 ++++++++++++++++++++++
1 file changed, 22 insertions(+)
diff --git a/drivers/mfd/db8500-prcmu.c b/drivers/mfd/db8500-prcmu.c
index 00b8b0f..53c24c4 100644
--- a/drivers/mfd/db8500-prcmu.c
+++ b/drivers/mfd/db8500-prcmu.c
@@ -31,6 +31,7 @@
#include <linux/mfd/abx500/ab8500.h>
#include <linux/regulator/db8500-prcmu.h>
#include <linux/regulator/machine.h>
+#include <linux/cpufreq.h>
#include <asm/hardware/gic.h>
#include <mach/hardware.h>
#include <mach/irqs.h>
@@ -3002,6 +3003,15 @@ static struct regulator_init_data db8500_regulators[DB8500_NUM_REGULATORS] = {
},
};
+/* CPU FREQ table, may be changed due to if MAX_OPP is supported. */
+static struct cpufreq_frequency_table db8500_cpufreq_table[] = {
+ { .frequency = 200000, .index = ARM_EXTCLK,},
+ { .frequency = 400000, .index = ARM_50_OPP,},
+ { .frequency = 800000, .index = ARM_100_OPP,},
+ { .frequency = CPUFREQ_TABLE_END,}, /* To be used for MAX_OPP. */
+ { .frequency = CPUFREQ_TABLE_END,},
+};
+
static struct resource ab8500_resources[] = {
[0] = {
.start = IRQ_DB8500_AB8500,
@@ -3020,6 +3030,8 @@ static struct mfd_cell db8500_prcmu_devs[] = {
{
.name = "cpufreq-u8500",
.of_compatible = "stericsson,cpufreq-u8500",
+ .platform_data = &db8500_cpufreq_table,
+ .pdata_size = sizeof(db8500_cpufreq_table),
},
{
.name = "ab8500-core",
@@ -3030,6 +3042,14 @@ static struct mfd_cell db8500_prcmu_devs[] = {
},
};
+static void db8500_prcmu_update_cpufreq(void)
+{
+ if (prcmu_has_arm_maxopp()) {
+ db8500_cpufreq_table[3].frequency = 1000000;
+ db8500_cpufreq_table[3].index = ARM_MAX_OPP;
+ }
+}
+
/**
* prcmu_fw_init - arch init call for the Linux PRCMU fw init logic
*
@@ -3074,6 +3094,8 @@ static int __devinit db8500_prcmu_probe(struct platform_device *pdev)
if (cpu_is_u8500v20_or_later())
prcmu_config_esram0_deep_sleep(ESRAM0_DEEP_SLEEP_STATE_RET);
+ db8500_prcmu_update_cpufreq();
+
err = mfd_add_devices(&pdev->dev, 0, db8500_prcmu_devs,
ARRAY_SIZE(db8500_prcmu_devs), NULL, 0, NULL);
if (err) {
--
1.7.10
^ permalink raw reply related
* [PATCH 3/8] cpufreq: db8500: Register as a platform driver
From: Ulf Hansson @ 2012-10-10 11:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349869349-8070-1-git-send-email-ulf.hansson@stericsson.com>
From: Ulf Hansson <ulf.hansson@linaro.org>
To fetch the mfd child device we register the cpufreq driver
as a platform driver.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Jonas Aaberg <jonas.aberg@stericsson.com>
Acked-by: Rafael J. Wysocki <rjw@sisk.pl>
---
drivers/cpufreq/db8500-cpufreq.c | 20 +++++++++++++++++++-
1 file changed, 19 insertions(+), 1 deletion(-)
diff --git a/drivers/cpufreq/db8500-cpufreq.c b/drivers/cpufreq/db8500-cpufreq.c
index 74b830b..7d61a6c 100644
--- a/drivers/cpufreq/db8500-cpufreq.c
+++ b/drivers/cpufreq/db8500-cpufreq.c
@@ -8,10 +8,12 @@
* Author: Jonas Aaberg <jonas.aberg@stericsson.com>
*
*/
+#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/cpufreq.h>
#include <linux/delay.h>
#include <linux/slab.h>
+#include <linux/platform_device.h>
#include <linux/mfd/dbx500-prcmu.h>
#include <mach/id.h>
@@ -159,12 +161,28 @@ static struct cpufreq_driver db8500_cpufreq_driver = {
.attr = db8500_cpufreq_attr,
};
+static int db8500_cpufreq_probe(struct platform_device *pdev)
+{
+ return cpufreq_register_driver(&db8500_cpufreq_driver);
+}
+
+static struct platform_driver db8500_cpufreq_plat_driver = {
+ .driver = {
+ .name = "cpufreq-u8500",
+ .owner = THIS_MODULE,
+ },
+ .probe = db8500_cpufreq_probe,
+};
+
static int __init db8500_cpufreq_register(void)
{
if (!cpu_is_u8500_family())
return -ENODEV;
pr_info("cpufreq for DB8500 started\n");
- return cpufreq_register_driver(&db8500_cpufreq_driver);
+ return platform_driver_register(&db8500_cpufreq_plat_driver);
}
device_initcall(db8500_cpufreq_register);
+
+MODULE_LICENSE("GPL v2");
+MODULE_DESCRIPTION("cpufreq driver for DB8500");
--
1.7.10
^ permalink raw reply related
* [PATCH 4/8] cpufreq: db8500: Fetch cpufreq table from platform data
From: Ulf Hansson @ 2012-10-10 11:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349869349-8070-1-git-send-email-ulf.hansson@stericsson.com>
From: Ulf Hansson <ulf.hansson@linaro.org>
By fetching the table as platform data we do not need the internally
hardcoded cpufreq table anymore.
Moreover the corresponding arm_opp idx2opp table, used for mapping
frequency to correct opp bits is also removed. This due to that the
opp bits is put directly in the index field of the cpufreq table.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Jonas Aaberg <jonas.aberg@stericsson.com>
Acked-by: Rafael J. Wysocki <rjw@sisk.pl>
---
drivers/cpufreq/db8500-cpufreq.c | 67 ++++++++++++++------------------------
1 file changed, 25 insertions(+), 42 deletions(-)
diff --git a/drivers/cpufreq/db8500-cpufreq.c b/drivers/cpufreq/db8500-cpufreq.c
index 7d61a6c..dea9a49 100644
--- a/drivers/cpufreq/db8500-cpufreq.c
+++ b/drivers/cpufreq/db8500-cpufreq.c
@@ -17,36 +17,7 @@
#include <linux/mfd/dbx500-prcmu.h>
#include <mach/id.h>
-static struct cpufreq_frequency_table freq_table[] = {
- [0] = {
- .index = 0,
- .frequency = 200000,
- },
- [1] = {
- .index = 1,
- .frequency = 400000,
- },
- [2] = {
- .index = 2,
- .frequency = 800000,
- },
- [3] = {
- /* Used for MAX_OPP, if available */
- .index = 3,
- .frequency = CPUFREQ_TABLE_END,
- },
- [4] = {
- .index = 4,
- .frequency = CPUFREQ_TABLE_END,
- },
-};
-
-static enum arm_opp idx2opp[] = {
- ARM_EXTCLK,
- ARM_50_OPP,
- ARM_100_OPP,
- ARM_MAX_OPP
-};
+static struct cpufreq_frequency_table *freq_table;
static struct freq_attr *db8500_cpufreq_attr[] = {
&cpufreq_freq_attr_scaling_available_freqs,
@@ -88,7 +59,7 @@ static int db8500_cpufreq_target(struct cpufreq_policy *policy,
cpufreq_notify_transition(&freqs, CPUFREQ_PRECHANGE);
/* request the PRCM unit for opp change */
- if (prcmu_set_arm_opp(idx2opp[idx])) {
+ if (prcmu_set_arm_opp(freq_table[idx].index)) {
pr_err("db8500-cpufreq: Failed to set OPP level\n");
return -EINVAL;
}
@@ -102,25 +73,30 @@ static int db8500_cpufreq_target(struct cpufreq_policy *policy,
static unsigned int db8500_cpufreq_getspeed(unsigned int cpu)
{
- int i;
+ int i = 0;
/* request the prcm to get the current ARM opp */
- for (i = 0; prcmu_get_arm_opp() != idx2opp[i]; i++)
- ;
- return freq_table[i].frequency;
+ int opp = prcmu_get_arm_opp();
+
+ while (freq_table[i].frequency != CPUFREQ_TABLE_END) {
+ if (opp == freq_table[i].index)
+ return freq_table[i].frequency;
+ i++;
+ }
+
+ /* We could not find a corresponding opp frequency. */
+ return 0;
}
static int __cpuinit db8500_cpufreq_init(struct cpufreq_policy *policy)
{
- int i, res;
-
- BUILD_BUG_ON(ARRAY_SIZE(idx2opp) + 1 != ARRAY_SIZE(freq_table));
-
- if (prcmu_has_arm_maxopp())
- freq_table[3].frequency = 1000000;
+ int i = 0;
+ int res;
pr_info("db8500-cpufreq : Available frequencies:\n");
- for (i = 0; freq_table[i].frequency != CPUFREQ_TABLE_END; i++)
+ while (freq_table[i].frequency != CPUFREQ_TABLE_END) {
pr_info(" %d Mhz\n", freq_table[i].frequency/1000);
+ i++;
+ }
/* get policy fields based on the table */
res = cpufreq_frequency_table_cpuinfo(policy, freq_table);
@@ -163,6 +139,13 @@ static struct cpufreq_driver db8500_cpufreq_driver = {
static int db8500_cpufreq_probe(struct platform_device *pdev)
{
+ freq_table = dev_get_platdata(&pdev->dev);
+
+ if (!freq_table) {
+ pr_err("db8500-cpufreq: Failed to fetch cpufreq table\n");
+ return -ENODEV;
+ }
+
return cpufreq_register_driver(&db8500_cpufreq_driver);
}
--
1.7.10
^ permalink raw reply related
* [PATCH 5/8] mfd: db8500: Connect ARMSS clk to ARM OPP
From: Ulf Hansson @ 2012-10-10 11:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349869349-8070-1-git-send-email-ulf.hansson@stericsson.com>
From: Ulf Hansson <ulf.hansson@linaro.org>
ARMSS clk directly maps it's frequency towards the cpufreq table.
To be able to update the ARMSS clk rate, a new set_rate function for
the ARMSS clk is added, which also will trigger a corresponding ARM
OPP request. Additionally an ARMSS clk round_rate function is added
to fetch valid cpufreq frequencies.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Cc: Samuel Ortiz <sameo@linux.intel.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
---
drivers/mfd/db8500-prcmu.c | 78 +++++++++++++++++++++++++++++++-------------
1 file changed, 56 insertions(+), 22 deletions(-)
diff --git a/drivers/mfd/db8500-prcmu.c b/drivers/mfd/db8500-prcmu.c
index 53c24c4..e91a6e6 100644
--- a/drivers/mfd/db8500-prcmu.c
+++ b/drivers/mfd/db8500-prcmu.c
@@ -421,9 +421,6 @@ static struct {
static atomic_t ac_wake_req_state = ATOMIC_INIT(0);
-/* Functions definition */
-static void compute_armss_rate(void);
-
/* Spinlocks */
static DEFINE_SPINLOCK(prcmu_lock);
static DEFINE_SPINLOCK(clkout_lock);
@@ -1020,7 +1017,6 @@ int db8500_prcmu_set_arm_opp(u8 opp)
(mb1_transfer.ack.arm_opp != opp))
r = -EIO;
- compute_armss_rate();
mutex_unlock(&mb1_transfer.lock);
return r;
@@ -1670,13 +1666,8 @@ static unsigned long clock_rate(u8 clock)
else
return 0;
}
-static unsigned long latest_armss_rate;
-static unsigned long armss_rate(void)
-{
- return latest_armss_rate;
-}
-static void compute_armss_rate(void)
+static unsigned long armss_rate(void)
{
u32 r;
unsigned long rate;
@@ -1701,7 +1692,7 @@ static void compute_armss_rate(void)
rate = pll_rate(PRCM_PLLARM_FREQ, ROOT_CLOCK_RATE, PLL_DIV);
}
- latest_armss_rate = rate;
+ return rate;
}
static unsigned long dsiclk_rate(u8 n)
@@ -1821,6 +1812,35 @@ static long round_clock_rate(u8 clock, unsigned long rate)
return rounded_rate;
}
+/* CPU FREQ table, may be changed due to if MAX_OPP is supported. */
+static struct cpufreq_frequency_table db8500_cpufreq_table[] = {
+ { .frequency = 200000, .index = ARM_EXTCLK,},
+ { .frequency = 400000, .index = ARM_50_OPP,},
+ { .frequency = 800000, .index = ARM_100_OPP,},
+ { .frequency = CPUFREQ_TABLE_END,}, /* To be used for MAX_OPP. */
+ { .frequency = CPUFREQ_TABLE_END,},
+};
+
+static long round_armss_rate(unsigned long rate)
+{
+ long freq = 0;
+ int i = 0;
+
+ /* cpufreq table frequencies is in KHz. */
+ rate = rate / 1000;
+
+ /* Find the corresponding arm opp from the cpufreq table. */
+ while (db8500_cpufreq_table[i].frequency != CPUFREQ_TABLE_END) {
+ freq = db8500_cpufreq_table[i].frequency;
+ if (freq == rate)
+ break;
+ i++;
+ }
+
+ /* Return the last valid value, even if a match was not found. */
+ return freq * 1000;
+}
+
#define MIN_PLL_VCO_RATE 600000000ULL
#define MAX_PLL_VCO_RATE 1680640000ULL
@@ -1892,6 +1912,8 @@ long prcmu_round_clock_rate(u8 clock, unsigned long rate)
{
if (clock < PRCMU_NUM_REG_CLOCKS)
return round_clock_rate(clock, rate);
+ else if (clock == PRCMU_ARMSS)
+ return round_armss_rate(rate);
else if (clock == PRCMU_PLLDSI)
return round_plldsi_rate(rate);
else if ((clock == PRCMU_DSI0CLK) || (clock == PRCMU_DSI1CLK))
@@ -1951,6 +1973,27 @@ static void set_clock_rate(u8 clock, unsigned long rate)
spin_unlock_irqrestore(&clk_mgt_lock, flags);
}
+static int set_armss_rate(unsigned long rate)
+{
+ int i = 0;
+
+ /* cpufreq table frequencies is in KHz. */
+ rate = rate / 1000;
+
+ /* Find the corresponding arm opp from the cpufreq table. */
+ while (db8500_cpufreq_table[i].frequency != CPUFREQ_TABLE_END) {
+ if (db8500_cpufreq_table[i].frequency == rate)
+ break;
+ i++;
+ }
+
+ if (db8500_cpufreq_table[i].frequency != rate)
+ return -EINVAL;
+
+ /* Set the new arm opp. */
+ return db8500_prcmu_set_arm_opp(db8500_cpufreq_table[i].index);
+}
+
static int set_plldsi_rate(unsigned long rate)
{
unsigned long src_rate;
@@ -2031,6 +2074,8 @@ int prcmu_set_clock_rate(u8 clock, unsigned long rate)
{
if (clock < PRCMU_NUM_REG_CLOCKS)
set_clock_rate(clock, rate);
+ else if (clock == PRCMU_ARMSS)
+ return set_armss_rate(rate);
else if (clock == PRCMU_PLLDSI)
return set_plldsi_rate(rate);
else if ((clock == PRCMU_DSI0CLK) || (clock == PRCMU_DSI1CLK))
@@ -2755,8 +2800,6 @@ void __init db8500_prcmu_early_init(void)
init_completion(&mb5_transfer.work);
INIT_WORK(&mb0_transfer.mask_work, prcmu_mask_work);
-
- compute_armss_rate();
}
static void __init init_prcm_registers(void)
@@ -3003,15 +3046,6 @@ static struct regulator_init_data db8500_regulators[DB8500_NUM_REGULATORS] = {
},
};
-/* CPU FREQ table, may be changed due to if MAX_OPP is supported. */
-static struct cpufreq_frequency_table db8500_cpufreq_table[] = {
- { .frequency = 200000, .index = ARM_EXTCLK,},
- { .frequency = 400000, .index = ARM_50_OPP,},
- { .frequency = 800000, .index = ARM_100_OPP,},
- { .frequency = CPUFREQ_TABLE_END,}, /* To be used for MAX_OPP. */
- { .frequency = CPUFREQ_TABLE_END,},
-};
-
static struct resource ab8500_resources[] = {
[0] = {
.start = IRQ_DB8500_AB8500,
--
1.7.10
^ 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