* [PATCH 1/5] drivercore: add new error value for deferred probe
From: Greg KH @ 2011-10-08 0:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <32004.1318030113@turing-police.cc.vt.edu>
On Fri, Oct 07, 2011 at 07:28:33PM -0400, Valdis.Kletnieks at vt.edu wrote:
> On Fri, 07 Oct 2011 16:12:45 MDT, Grant Likely said:
> > On Fri, Oct 7, 2011 at 12:43 AM, Greg KH <greg@kroah.com> wrote:
> > > On Fri, Oct 07, 2011 at 10:33:06AM +0500, G, Manjunath Kondaiah wrote:
>
> > >> +#define EPROBE_DEFER 517 ? ? /* restart probe again after some time */
> > >
> > > Can we really do this?
>
> > According to Arnd, yes this is okay.
>
> > > ?Isn't this some user/kernel api here?
>
> > > What's wrong with just "overloading" on top of an existing error code?
> > > Surely one of the other 516 types could be used here, right?
>
> > overloading makes it really hard to find the users at a later date.
>
> Would proposing '#define EPROBE_DEFER EAGAIN' be acceptable to everybody? That
> would allow overloading EAGAIN, but still make it easy to tell the usages apart
> if we need to separate them later...
Yes, please do that, it is what USB does for it's internal error code
handling.
greg k-h
^ permalink raw reply
* [GIT PULL] ARM: CSR: l2x0 init cleanup for 3.2
From: Barry Song @ 2011-10-08 1:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201110072304.48412.arnd@arndb.de>
2011/10/8 Arnd Bergmann <arnd@arndb.de>:
> On Saturday 01 October 2011, Barry Song wrote:
>> Since the l2x0 cleanup of prima2 depends on the following two patches
>> in rmk's tree:
>>
>> [1]Rob Herring
>> ARM: 7009/1: l2x0: Add OF based initialization
>> http://www.spinics.net/lists/arm-kernel/msg131123.html
>> it has been in rmk/for-next
>>
>> [2]Barry Song
>> ARM: 7009/1: CACHE-L2X0: filter start address can be 0 and is often 0
>> http://www.spinics.net/lists/arm-kernel/msg140126.html
>> it has been in rmk/for-next
>>
>> I have rebased the l2x0-cleanup branch to "ARM: 7009/1: CACHE-L2X0:
>> filter start address can be 0 and is often 0". this might cause some
>> issues to you. if that is difficult to you, i guess you can pich the
>> commmit and apply it when your tree has been ready.
>>
>> The following changes since commit 513d47a3d953e44d79c29077f6c428a017f8af62:
>> ? Barry Song (1):
>> ? ? ? ? ARM: 7090/1: CACHE-L2X0: filter start address can be 0 and is often 0
>>
>> are available in the git repository at:
>>
>> ? git://gitorious.org/sirfprima2-kernel/sirfprima2-kernel.git l2x0-cleanup
>
> I think I can keep track of this, but is the commit that you used actually
> from a stable branch in Russell's tree? If that gets rebased, I should
> not pull your patch in.
not actually. the commit is in rmk/for-next. rmk might rebase
for-next. you might apply this one after your local tree merge rmk's
stable tree with this commit.
>
> ? ? ? ?Arnd
>
-barry
^ permalink raw reply
* [PATCH v2 0/5] ARM: pxa: move gpio driver into drivers directory
From: Haojian Zhuang @ 2011-10-08 1:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111001164241.GK11710@n2100.arm.linux.org.uk>
On Sun, Oct 2, 2011 at 12:42 AM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Fri, Sep 30, 2011 at 06:19:15PM +0800, Haojian Zhuang wrote:
>> Changelog:
>> v2:
>> ? ? ? 1. Remove gpio.c from mach-pxa & mach-mmp that is introduced from v1.
>> ? ? ? 2. Remove init function in gpio.c. Move the platfrom_device_register()
>> ? ? ? ? ?into platform driver.
>> ? ? ? 3. Initialize pxa_gpio_regs in gpio-pxa.c
>> ? ? ? 4. Simplify code of identifing pxa gpio series or mmp gpio series.
>> ? ? ? 5. Use linux/io.h instead of asm/io.h.
>
> This series looks fine to me. ?You don't mention what it's based upon -
> should I assume my gpio patch series? ?If so, it looks fine to be
> submitted to the patch system.
>
> It would be nice to have a few acks from people against it first though.
>
> Thanks.
>
I'm sorry that I was in holiday in the last week, and I missed these
mails. It seems that linus's patch is already merged into your git
tree. And my codebase is linux-next.git.
So I'll re-format these patches based on your git tree, and I'll paste it again.
Thanks
Haojian
^ permalink raw reply
* [PATCH] mx5: modify pm and idle
From: Hui Wang @ 2011-10-08 1:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111003052458.GA21563@S2100-06.ap.freescale.net>
Shawn Guo wrote:
> On Fri, Sep 30, 2011 at 02:37:22PM +0800, Hui Wang wrote:
>
>> Two problems exist in the current i.MX5 pm suspend/resume and idle
>> functions. The first is the current i.MX5 suspend routine will call
>>
<snip>
>> MPGC1_SRPGCR);
>> }
>> }
>> +
>> +void mx5_arch_idle(void)
>> +{
>> + if (gpc_dvfs_clk == NULL)
>> + gpc_dvfs_clk = clk_get(NULL, "gpc_dvfs");
>> +
>> + /* gpc clock is needed for SRPG */
>> + clk_enable(gpc_dvfs_clk);
>> + mx5_cpu_lp_set(WAIT_UNCLOCKED_POWER_OFF);
>> + if (tzic_enable_wake() != 0)
>> + goto exit;
>> + cpu_do_idle();
>> +exit:
>> + clk_disable(gpc_dvfs_clk);
>>
>
> Bad indentation on entire function block (should be 1 tab rather than 2)
>
> Regards,
> Shawn
>
>
Got it. I will fix it in the V2.
>> +}
>> diff --git a/arch/arm/plat-mxc/include/mach/mxc.h b/arch/arm/plat-mxc/include/mach/mxc.h
>> index 0987923..c4d324a 100644
>> --- a/arch/arm/plat-mxc/include/mach/mxc.h
>> +++ b/arch/arm/plat-mxc/include/mach/mxc.h
>> @@ -182,7 +182,7 @@ struct cpu_op {
>> u32 cpu_rate;
>> };
>>
>>
^ permalink raw reply
* [PATCH] mx5: modify pm and idle
From: Hui Wang @ 2011-10-08 1:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111004074316.GK31404@pengutronix.de>
Sascha Hauer wrote:
> On Fri, Sep 30, 2011 at 02:37:22PM +0800, Hui Wang wrote:
>
>> Two problems exist in the current i.MX5 pm suspend/resume and idle
>> functions. The first is the current i.MX5 suspend routine will call
>> tzic_enable_wake(1) to set wake source, this will set all enabled
>> irq as wake source rather than those wake capable. The second
>> is i.MX5 idle will call mx5_cpu_lp_set() to prepare enter low power
>> mode, but it forgets to call wfi instruction to enter this mode.
>>
>> To fix these two problems, using generic irq chip pm interface and
>> adding a new function mx5_arch_idle().
>>
>> Signed-off-by: Hui Wang <jason77.wang@gmail.com>
>>
>
> As shawn already pointed out this conflicts with the imx-cleanup
> branch. Can you rework this onto it? Shawn has reworked the SoC
> specific idle stuff, so this is different now.
>
> Also, please find a better subject for this patch. 'modify pm and idle'
> is not enough.
>
> Sascha
>
>
Got it, OK.
>> ---
>>
>> This patch is basing on the latest imx-features branch.
>>
>> This patch is validated on the i.MX51 PDK board (CPU revision 2.0).
>>
>> Since both pm suspend/resume and idle has close relation with
>> mx5_cpu_lp_set() and tzic_enable_wake(), i choose to use one patch
>> instead of independent two to address existing problems.
>>
>> arch/arm/mach-mx5/system.c | 24 +++++++++++++++--
>> arch/arm/plat-mxc/include/mach/mxc.h | 2 +-
>> arch/arm/plat-mxc/include/mach/system.h | 3 +-
>> arch/arm/plat-mxc/tzic.c | 42 ++++++++++++++++++++++---------
>> 4 files changed, 54 insertions(+), 17 deletions(-)
>>
^ permalink raw reply
* [PATCH] mx5: modify pm and idle
From: Shawn Guo @ 2011-10-08 2:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4E8FA8B3.80206@gmail.com>
On Sat, Oct 08, 2011 at 09:34:43AM +0800, Hui Wang wrote:
> Sascha Hauer wrote:
> >On Fri, Sep 30, 2011 at 02:37:22PM +0800, Hui Wang wrote:
> >>Two problems exist in the current i.MX5 pm suspend/resume and idle
> >>functions. The first is the current i.MX5 suspend routine will call
> >>tzic_enable_wake(1) to set wake source, this will set all enabled
> >>irq as wake source rather than those wake capable. The second
> >>is i.MX5 idle will call mx5_cpu_lp_set() to prepare enter low power
> >>mode, but it forgets to call wfi instruction to enter this mode.
> >>
> >>To fix these two problems, using generic irq chip pm interface and
> >>adding a new function mx5_arch_idle().
> >>
> >>Signed-off-by: Hui Wang <jason77.wang@gmail.com>
> >
> >As shawn already pointed out this conflicts with the imx-cleanup
> >branch. Can you rework this onto it? Shawn has reworked the SoC
> >specific idle stuff, so this is different now.
> >
> >Also, please find a better subject for this patch. 'modify pm and idle'
> >is not enough.
> >
> >Sascha
> >
> Got it, OK.
Please also add 'ARM: ' prefix to the subject for consistency.
--
Regards,
Shawn
^ permalink raw reply
* [PATCH 17/26] ARM: pxa: pxa95x is incompatible with earlier pxa
From: Haojian Zhuang @ 2011-10-08 2:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317499438-14058-18-git-send-email-arnd@arndb.de>
On Sun, Oct 2, 2011 at 4:03 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> We cannot support ARMv5 and ARMv7 based boards in a single kernel,
> so introduce a new option in mach-pxa to select between the two.
>
> The PJ4 (ARMv7) based boards are now only visible when
> CONFIG_ARCH_PXA_V7 is set, the other boards are only visible
> when it's not set.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> ?arch/arm/mach-pxa/Kconfig | ? 31 ++++++++++++++++++++++---------
> ?1 files changed, 22 insertions(+), 9 deletions(-)
>
> diff --git a/arch/arm/mach-pxa/Kconfig b/arch/arm/mach-pxa/Kconfig
> index cd19309..bb310d0 100644
> --- a/arch/arm/mach-pxa/Kconfig
> +++ b/arch/arm/mach-pxa/Kconfig
> @@ -2,6 +2,27 @@ if ARCH_PXA
>
> ?menu "Intel PXA2xx/PXA3xx Implementations"
>
> +config ARCH_PXA_V7
> + ? ? ? bool "ARMv7 (PXA95x) based systems"
> +
> +if ARCH_PXA_V7
> +comment "Marvell Dev Platforms (sorted by hardware release time)"
> +config MACH_TAVOREVB3
> + ? ? ? bool "PXA95x Development Platform (aka TavorEVB III)"
> + ? ? ? select CPU_PXA955
> +
> +config MACH_SAARB
> + ? ? ? bool "PXA955 Handheld Platform (aka SAARB)"
> + ? ? ? select CPU_PXA955
> +endif
> +
> +config PXA_V7_MACH_AUTO
> + ? ? ? def_bool y
> + ? ? ? depends on ARCH_PXA_V7
> + ? ? ? depends on !MACH_SAARB
> + ? ? ? select MACH_TAVOREVB3
> +
Could we avoid to use PXA_V7_MACH_AUTO? I think the better way is
defining a new ARCH (ARCH_PXA95X or something else), and sharing the
code in arch/arm/mach-pxa. I think that it's easy to implement.
How about you, Russell & Eric?
> +if !ARCH_PXA_V7
> ?comment "Intel/Marvell Dev Platforms (sorted by hardware release time)"
>
> ?config ARCH_LUBBOCK
> @@ -41,19 +62,11 @@ config MACH_TAVOREVB
> ? ? ? ?select PXA3xx
> ? ? ? ?select CPU_PXA930
>
> -config MACH_TAVOREVB3
> - ? ? ? bool "PXA95x Development Platform (aka TavorEVB III)"
> - ? ? ? select CPU_PXA950
> -
> ?config MACH_SAAR
> ? ? ? ?bool "PXA930 Handheld Platform (aka SAAR)"
> ? ? ? ?select PXA3xx
> ? ? ? ?select CPU_PXA930
>
> -config MACH_SAARB
> - ? ? ? bool "PXA955 Handheld Platform (aka SAARB)"
> - ? ? ? select CPU_PXA955
> -
> ?comment "Third Party Dev Platforms (sorted by vendor name)"
>
> ?config ARCH_PXA_IDP
> @@ -598,7 +611,7 @@ config MACH_ZIPIT2
> ? ? ? ?bool "Zipit Z2 Handheld"
> ? ? ? ?select PXA27x
> ? ? ? ?select HAVE_PWM
> -
> +endif
> ?endmenu
>
> ?config PXA25x
> --
> 1.7.5.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at ?http://www.tux.org/lkml/
>
^ permalink raw reply
* [PATCH 17/26] ARM: pxa: pxa95x is incompatible with earlier pxa
From: Eric Miao @ 2011-10-08 3:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAN1soZw-eB5WxY5YWjfd=_q5w8wSu09mRTcmOEN_SDq9Zuz7eg@mail.gmail.com>
On Sat, Oct 8, 2011 at 10:57 AM, Haojian Zhuang
<haojian.zhuang@gmail.com> wrote:
> On Sun, Oct 2, 2011 at 4:03 AM, Arnd Bergmann <arnd@arndb.de> wrote:
>> We cannot support ARMv5 and ARMv7 based boards in a single kernel,
>> so introduce a new option in mach-pxa to select between the two.
>>
>> The PJ4 (ARMv7) based boards are now only visible when
>> CONFIG_ARCH_PXA_V7 is set, the other boards are only visible
>> when it's not set.
>>
>> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>> ---
>> ?arch/arm/mach-pxa/Kconfig | ? 31 ++++++++++++++++++++++---------
>> ?1 files changed, 22 insertions(+), 9 deletions(-)
>>
>> diff --git a/arch/arm/mach-pxa/Kconfig b/arch/arm/mach-pxa/Kconfig
>> index cd19309..bb310d0 100644
>> --- a/arch/arm/mach-pxa/Kconfig
>> +++ b/arch/arm/mach-pxa/Kconfig
>> @@ -2,6 +2,27 @@ if ARCH_PXA
>>
>> ?menu "Intel PXA2xx/PXA3xx Implementations"
>>
>> +config ARCH_PXA_V7
>> + ? ? ? bool "ARMv7 (PXA95x) based systems"
>> +
>> +if ARCH_PXA_V7
>> +comment "Marvell Dev Platforms (sorted by hardware release time)"
>> +config MACH_TAVOREVB3
>> + ? ? ? bool "PXA95x Development Platform (aka TavorEVB III)"
>> + ? ? ? select CPU_PXA955
>> +
>> +config MACH_SAARB
>> + ? ? ? bool "PXA955 Handheld Platform (aka SAARB)"
>> + ? ? ? select CPU_PXA955
>> +endif
>> +
>> +config PXA_V7_MACH_AUTO
>> + ? ? ? def_bool y
>> + ? ? ? depends on ARCH_PXA_V7
>> + ? ? ? depends on !MACH_SAARB
>> + ? ? ? select MACH_TAVOREVB3
>> +
> Could we avoid to use PXA_V7_MACH_AUTO? I think the better way is
> defining a new ARCH (ARCH_PXA95X or something else), and sharing the
> code in arch/arm/mach-pxa. I think that it's easy to implement.
>
> How about you, Russell & Eric?
Haojian,
The patch here is to fix the issue of V5 boards and V7 boards being
built together yet it's not supported (there will be building errors).
And this could be easily spotted with auto/random configurations.
I generally think the patch is fine before we'll allow building of both
v5 and v7 code together (which Nico will be definitely interested in)
>
>> +if !ARCH_PXA_V7
>> ?comment "Intel/Marvell Dev Platforms (sorted by hardware release time)"
>>
>> ?config ARCH_LUBBOCK
>> @@ -41,19 +62,11 @@ config MACH_TAVOREVB
>> ? ? ? ?select PXA3xx
>> ? ? ? ?select CPU_PXA930
>>
>> -config MACH_TAVOREVB3
>> - ? ? ? bool "PXA95x Development Platform (aka TavorEVB III)"
>> - ? ? ? select CPU_PXA950
>> -
>> ?config MACH_SAAR
>> ? ? ? ?bool "PXA930 Handheld Platform (aka SAAR)"
>> ? ? ? ?select PXA3xx
>> ? ? ? ?select CPU_PXA930
>>
>> -config MACH_SAARB
>> - ? ? ? bool "PXA955 Handheld Platform (aka SAARB)"
>> - ? ? ? select CPU_PXA955
>> -
>> ?comment "Third Party Dev Platforms (sorted by vendor name)"
>>
>> ?config ARCH_PXA_IDP
>> @@ -598,7 +611,7 @@ config MACH_ZIPIT2
>> ? ? ? ?bool "Zipit Z2 Handheld"
>> ? ? ? ?select PXA27x
>> ? ? ? ?select HAVE_PWM
>> -
>> +endif
>> ?endmenu
>>
>> ?config PXA25x
>> --
>> 1.7.5.4
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majordomo at vger.kernel.org
>> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at ?http://www.tux.org/lkml/
>>
>
^ permalink raw reply
* [PATCH 17/26] ARM: pxa: pxa95x is incompatible with earlier pxa
From: Haojian Zhuang @ 2011-10-08 3:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMPhdO_L-g4vSj3fC-1ckqnHGAPhWOy6Hm4VL5iUbZbbdjRkNQ@mail.gmail.com>
On Sat, Oct 8, 2011 at 11:21 AM, Eric Miao <eric.y.miao@gmail.com> wrote:
> On Sat, Oct 8, 2011 at 10:57 AM, Haojian Zhuang
> <haojian.zhuang@gmail.com> wrote:
>> On Sun, Oct 2, 2011 at 4:03 AM, Arnd Bergmann <arnd@arndb.de> wrote:
>>> We cannot support ARMv5 and ARMv7 based boards in a single kernel,
>>> so introduce a new option in mach-pxa to select between the two.
>>>
>>> The PJ4 (ARMv7) based boards are now only visible when
>>> CONFIG_ARCH_PXA_V7 is set, the other boards are only visible
>>> when it's not set.
>>>
>>> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>>> ---
>>> ?arch/arm/mach-pxa/Kconfig | ? 31 ++++++++++++++++++++++---------
>>> ?1 files changed, 22 insertions(+), 9 deletions(-)
>>>
>>> diff --git a/arch/arm/mach-pxa/Kconfig b/arch/arm/mach-pxa/Kconfig
>>> index cd19309..bb310d0 100644
>>> --- a/arch/arm/mach-pxa/Kconfig
>>> +++ b/arch/arm/mach-pxa/Kconfig
>>> @@ -2,6 +2,27 @@ if ARCH_PXA
>>>
>>> ?menu "Intel PXA2xx/PXA3xx Implementations"
>>>
>>> +config ARCH_PXA_V7
>>> + ? ? ? bool "ARMv7 (PXA95x) based systems"
>>> +
>>> +if ARCH_PXA_V7
>>> +comment "Marvell Dev Platforms (sorted by hardware release time)"
>>> +config MACH_TAVOREVB3
>>> + ? ? ? bool "PXA95x Development Platform (aka TavorEVB III)"
>>> + ? ? ? select CPU_PXA955rds and V7 boards being
built together yet it's not supported (there will be building errors).
And this could be easily spotted with auto/rds and V7 boards being
built together yet it's not supported (there will be building errors).
And this could be easily spotted with auto/
>>> +
>>> +config MACH_SAARB
>>> + ? ? ? bool "PXA955 Handheld Platform (aka SAARB)"
>>> + ? ? ? select CPU_PXA955
>>> +endif
>>> +
>>> +config PXA_V7_MACH_AUTO
>>> + ? ? ? def_bool y
>>> + ? ? ? depends on ARCH_PXA_V7
>>> + ? ? ? depends on !MACH_SAARB
>>> + ? ? ? select MACH_TAVOREVB3
>>> +
>> Could we avoid to use PXA_V7_MACH_AUTO? I think the better way is
>> defining a new ARCH (ARCH_PXA95X or something else), and sharing the
>> code in arch/arm/mach-pxa. I think that it's easy to implement.
>>
>> How about you, Russell & Eric?
>
> Haojian,
>
> The patch here is to fix the issue of V5 boards and V7 boards being
> built together yet it's not supported (there will be building errors).
> And this could be easily spotted with auto/random configurations.
>
> I generally think the patch is fine before we'll allow building of both
> v5 and v7 code together (which Nico will be definitely interested in)
>
>
Eric,
At first, a new macro (ARCH_PXA_V7) is defined in
arch/arm/mach-pxa/Kconfig in this patch.
I prefer to move this macro to arch/arm/Kconfig.
Secondly, pxa95x is both used in saarb and tavorevb3.
Thirdly, PXA_V7_MACH_AUTO is unnecessary. We just need to select those
machines in defconfig or define a new DT machine type to select all
machines.
Thanks
Haojian
^ permalink raw reply
* [PATCH 2/5] drivercore: Add driver probe deferral mechanism
From: Josh Triplett @ 2011-10-08 4:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111007212326.GA29003@kroah.com>
On Fri, Oct 07, 2011 at 02:23:26PM -0700, Greg KH wrote:
> On Fri, Oct 07, 2011 at 01:57:15PM -0700, Josh Triplett wrote:
> > On Thu, Oct 06, 2011 at 11:49:28PM -0700, Greg KH wrote:
> > > On Fri, Oct 07, 2011 at 10:33:07AM +0500, G, Manjunath Kondaiah wrote:
> > > > +config PROBE_DEFER
> > > > + bool "Deferred Driver Probe"
> > > > + default y
> > > > + help
> > > > + This option provides deferring driver probe if it has dependency on
> > > > + other driver. Without this feature, initcall ordering should be done
> > > > + manually to resolve driver dependencies. This feature completely side
> > > > + steps the issues by allowing driver registration to occur in any
> > > > + order, and any driver can request to be retried after a few more other
> > > > + drivers get probed.
> > >
> > > Why is this even an option? Why would you ever want it disabled? Why
> > > does it need to be selected?
> > >
> > > If you are going to default something to 'y' then just make it so it
> > > can't be turned off any other way by just not making it an option at
> > > all.
> >
> > Given that the drivers which use this mechanism will not necessarily get
> > built into the kernel, I'd suggest that it should remain optional and
> > default to n. Those drivers can then add a dependency on PROBE_DEFER.
> > Let's try to avoid adding more infrastructure to the kernel that takes
> > up space even when unused; certainly embedded will appreciate not having
> > this feature unless a driver needs it.
>
> How much extra space is this "feature" really?
Just checked: 776 bytes, 640 of text and 136 of data. We have kconfig
options for comparable amounts.
> I don't see it being
> anything larger than the amount of memory increase that just happened as
> I typed this email as part of the ongoing memory density changes.
I don't know about the changes you mean, but in any case I'd like to
prevent mandatory size increases wherever possible. I'd love to see the
size of "allnoconfig" getting *smaller* over time, not larger.
- Josh Triplett
^ permalink raw reply
* [PATCH] arm: mm: Fix infinite looping issue
From: Girish KS @ 2011-10-08 5:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317724684-29115-1-git-send-email-girish.shivananjappa@linaro.org>
Hello Mr choi,
If there is no issue with this patch can you apply to your for-next tree
regards
Girish K S
On Tue, Oct 4, 2011 at 4:08 PM, Girish K S
<girish.shivananjappa@linaro.org> wrote:
>
> This patch fixes the problem of infinite looping while booting.
>
> The bne instruction expects the z flag to be set to break the loop.
> The (mov r1, r1, lsr #1) doesn't behave in the expected way. If
> replaced with the movs instruction then the execution will exit
> the loop.
>
> Signed-off-by: Girish K S <girish.shivananjappa@linaro.org>
> ---
> ?arch/arm/mm/proc-arm740.S | ? ?4 ++--
> ?arch/arm/mm/proc-arm940.S | ? ?4 ++--
> ?arch/arm/mm/proc-arm946.S | ? ?4 ++--
> ?3 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm/mm/proc-arm740.S b/arch/arm/mm/proc-arm740.S
> index 4506be3..9284f10 100644
> --- a/arch/arm/mm/proc-arm740.S
> +++ b/arch/arm/mm/proc-arm740.S
> @@ -77,7 +77,7 @@ __arm740_setup:
> ? ? ? ?ldr ? ? r1, =(CONFIG_DRAM_SIZE >> 12) ? @ size of RAM (must be >= 4KB)
> ? ? ? ?mov ? ? r2, #10 ? ? ? ? ? ? ? ? ? ? ? ? @ 11 is the minimum (4KB)
> ?1: ? ? add ? ? r2, r2, #1 ? ? ? ? ? ? ? ? ? ? ?@ area size *= 2
> - ? ? ? mov ? ? r1, r1, lsr #1
> + ? ? ? movs ? ?r1, r1, lsr #1 ? ? ? ? ? ? ? ? ?@ set zero bit if r1=0
> ? ? ? ?bne ? ? 1b ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?@ count not zero r-shift
> ? ? ? ?orr ? ? r0, r0, r2, lsl #1 ? ? ? ? ? ? ?@ the area register value
> ? ? ? ?orr ? ? r0, r0, #1 ? ? ? ? ? ? ? ? ? ? ?@ set enable bit
> @@ -87,7 +87,7 @@ __arm740_setup:
> ? ? ? ?ldr ? ? r1, =(CONFIG_FLASH_SIZE >> 12) ?@ size of FLASH (must be >= 4KB)
> ? ? ? ?mov ? ? r2, #10 ? ? ? ? ? ? ? ? ? ? ? ? @ 11 is the minimum (4KB)
> ?1: ? ? add ? ? r2, r2, #1 ? ? ? ? ? ? ? ? ? ? ?@ area size *= 2
> - ? ? ? mov ? ? r1, r1, lsr #1
> + ? ? ? movs ? ?r1, r1, lsr #1 ? ? ? ? ? ? ? ? ?@ set zero bit if r1=0
> ? ? ? ?bne ? ? 1b ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?@ count not zero r-shift
> ? ? ? ?orr ? ? r0, r0, r2, lsl #1 ? ? ? ? ? ? ?@ the area register value
> ? ? ? ?orr ? ? r0, r0, #1 ? ? ? ? ? ? ? ? ? ? ?@ set enable bit
> diff --git a/arch/arm/mm/proc-arm940.S b/arch/arm/mm/proc-arm940.S
> index ac750d5..e639034 100644
> --- a/arch/arm/mm/proc-arm940.S
> +++ b/arch/arm/mm/proc-arm940.S
> @@ -296,7 +296,7 @@ __arm940_setup:
> ? ? ? ?ldr ? ? r1, =(CONFIG_DRAM_SIZE >> 12) ? @ size of RAM (must be >= 4KB)
> ? ? ? ?mov ? ? r2, #10 ? ? ? ? ? ? ? ? ? ? ? ? @ 11 is the minimum (4KB)
> ?1: ? ? add ? ? r2, r2, #1 ? ? ? ? ? ? ? ? ? ? ?@ area size *= 2
> - ? ? ? mov ? ? r1, r1, lsr #1
> + ? ? ? movs ? ?r1, r1, lsr #1 ? ? ? ? ? ? ? ? ?@ set zero bit if r1=0
> ? ? ? ?bne ? ? 1b ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?@ count not zero r-shift
> ? ? ? ?orr ? ? r0, r0, r2, lsl #1 ? ? ? ? ? ? ?@ the area register value
> ? ? ? ?orr ? ? r0, r0, #1 ? ? ? ? ? ? ? ? ? ? ?@ set enable bit
> @@ -307,7 +307,7 @@ __arm940_setup:
> ? ? ? ?ldr ? ? r1, =(CONFIG_FLASH_SIZE >> 12) ?@ size of FLASH (must be >= 4KB)
> ? ? ? ?mov ? ? r2, #10 ? ? ? ? ? ? ? ? ? ? ? ? @ 11 is the minimum (4KB)
> ?1: ? ? add ? ? r2, r2, #1 ? ? ? ? ? ? ? ? ? ? ?@ area size *= 2
> - ? ? ? mov ? ? r1, r1, lsr #1
> + ? ? ? movs ? ?r1, r1, lsr #1 ? ? ? ? ? ? ? ? ?@ set zero bit if r1=0
> ? ? ? ?bne ? ? 1b ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?@ count not zero r-shift
> ? ? ? ?orr ? ? r0, r0, r2, lsl #1 ? ? ? ? ? ? ?@ the area register value
> ? ? ? ?orr ? ? r0, r0, #1 ? ? ? ? ? ? ? ? ? ? ?@ set enable bit
> diff --git a/arch/arm/mm/proc-arm946.S b/arch/arm/mm/proc-arm946.S
> index 683af3a..731388a 100644
> --- a/arch/arm/mm/proc-arm946.S
> +++ b/arch/arm/mm/proc-arm946.S
> @@ -341,7 +341,7 @@ __arm946_setup:
> ? ? ? ?ldr ? ? r1, =(CONFIG_DRAM_SIZE >> 12) ? @ size of RAM (must be >= 4KB)
> ? ? ? ?mov ? ? r2, #10 ? ? ? ? ? ? ? ? ? ? ? ? @ 11 is the minimum (4KB)
> ?1: ? ? add ? ? r2, r2, #1 ? ? ? ? ? ? ? ? ? ? ?@ area size *= 2
> - ? ? ? mov ? ? r1, r1, lsr #1
> + ? ? ? movs ? ?r1, r1, lsr #1 ? ? ? ? ? ? ? ? ?@ set zero bit if r1=0
> ? ? ? ?bne ? ? 1b ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?@ count not zero r-shift
> ? ? ? ?orr ? ? r0, r0, r2, lsl #1 ? ? ? ? ? ? ?@ the region register value
> ? ? ? ?orr ? ? r0, r0, #1 ? ? ? ? ? ? ? ? ? ? ?@ set enable bit
> @@ -351,7 +351,7 @@ __arm946_setup:
> ? ? ? ?ldr ? ? r1, =(CONFIG_FLASH_SIZE >> 12) ?@ size of FLASH (must be >= 4KB)
> ? ? ? ?mov ? ? r2, #10 ? ? ? ? ? ? ? ? ? ? ? ? @ 11 is the minimum (4KB)
> ?1: ? ? add ? ? r2, r2, #1 ? ? ? ? ? ? ? ? ? ? ?@ area size *= 2
> - ? ? ? mov ? ? r1, r1, lsr #1
> + ? ? ? movs ? ?r1, r1, lsr #1 ? ? ? ? ? ? ? ? ?@ set zero bit if r1=0
> ? ? ? ?bne ? ? 1b ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?@ count not zero r-shift
> ? ? ? ?orr ? ? r0, r0, r2, lsl #1 ? ? ? ? ? ? ?@ the region register value
> ? ? ? ?orr ? ? r0, r0, #1 ? ? ? ? ? ? ? ? ? ? ?@ set enable bit
> --
> 1.7.1
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] arm: mm: Fix infinite looping issue
From: Girish KS @ 2011-10-08 5:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317724684-29115-1-git-send-email-girish.shivananjappa@linaro.org>
On Tue, Oct 4, 2011 at 4:08 PM, Girish K S
<girish.shivananjappa@linaro.org> wrote:
> This patch fixes the problem of infinite looping while booting.
>
> The bne instruction expects the z flag to be set to break the loop.
> The (mov r1, r1, lsr #1) doesn't behave in the expected way. If
> replaced with the movs instruction then the execution will exit
> the loop.
>
> Signed-off-by: Girish K S <girish.shivananjappa@linaro.org>
> ---
> ?arch/arm/mm/proc-arm740.S | ? ?4 ++--
> ?arch/arm/mm/proc-arm940.S | ? ?4 ++--
> ?arch/arm/mm/proc-arm946.S | ? ?4 ++--
> ?3 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm/mm/proc-arm740.S b/arch/arm/mm/proc-arm740.S
> index 4506be3..9284f10 100644
> --- a/arch/arm/mm/proc-arm740.S
> +++ b/arch/arm/mm/proc-arm740.S
> @@ -77,7 +77,7 @@ __arm740_setup:
> ? ? ? ?ldr ? ? r1, =(CONFIG_DRAM_SIZE >> 12) ? @ size of RAM (must be >= 4KB)
> ? ? ? ?mov ? ? r2, #10 ? ? ? ? ? ? ? ? ? ? ? ? @ 11 is the minimum (4KB)
> ?1: ? ? add ? ? r2, r2, #1 ? ? ? ? ? ? ? ? ? ? ?@ area size *= 2
> - ? ? ? mov ? ? r1, r1, lsr #1
> + ? ? ? movs ? ?r1, r1, lsr #1 ? ? ? ? ? ? ? ? ?@ set zero bit if r1=0
> ? ? ? ?bne ? ? 1b ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?@ count not zero r-shift
> ? ? ? ?orr ? ? r0, r0, r2, lsl #1 ? ? ? ? ? ? ?@ the area register value
> ? ? ? ?orr ? ? r0, r0, #1 ? ? ? ? ? ? ? ? ? ? ?@ set enable bit
> @@ -87,7 +87,7 @@ __arm740_setup:
> ? ? ? ?ldr ? ? r1, =(CONFIG_FLASH_SIZE >> 12) ?@ size of FLASH (must be >= 4KB)
> ? ? ? ?mov ? ? r2, #10 ? ? ? ? ? ? ? ? ? ? ? ? @ 11 is the minimum (4KB)
> ?1: ? ? add ? ? r2, r2, #1 ? ? ? ? ? ? ? ? ? ? ?@ area size *= 2
> - ? ? ? mov ? ? r1, r1, lsr #1
> + ? ? ? movs ? ?r1, r1, lsr #1 ? ? ? ? ? ? ? ? ?@ set zero bit if r1=0
> ? ? ? ?bne ? ? 1b ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?@ count not zero r-shift
> ? ? ? ?orr ? ? r0, r0, r2, lsl #1 ? ? ? ? ? ? ?@ the area register value
> ? ? ? ?orr ? ? r0, r0, #1 ? ? ? ? ? ? ? ? ? ? ?@ set enable bit
> diff --git a/arch/arm/mm/proc-arm940.S b/arch/arm/mm/proc-arm940.S
> index ac750d5..e639034 100644
> --- a/arch/arm/mm/proc-arm940.S
> +++ b/arch/arm/mm/proc-arm940.S
> @@ -296,7 +296,7 @@ __arm940_setup:
> ? ? ? ?ldr ? ? r1, =(CONFIG_DRAM_SIZE >> 12) ? @ size of RAM (must be >= 4KB)
> ? ? ? ?mov ? ? r2, #10 ? ? ? ? ? ? ? ? ? ? ? ? @ 11 is the minimum (4KB)
> ?1: ? ? add ? ? r2, r2, #1 ? ? ? ? ? ? ? ? ? ? ?@ area size *= 2
> - ? ? ? mov ? ? r1, r1, lsr #1
> + ? ? ? movs ? ?r1, r1, lsr #1 ? ? ? ? ? ? ? ? ?@ set zero bit if r1=0
> ? ? ? ?bne ? ? 1b ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?@ count not zero r-shift
> ? ? ? ?orr ? ? r0, r0, r2, lsl #1 ? ? ? ? ? ? ?@ the area register value
> ? ? ? ?orr ? ? r0, r0, #1 ? ? ? ? ? ? ? ? ? ? ?@ set enable bit
> @@ -307,7 +307,7 @@ __arm940_setup:
> ? ? ? ?ldr ? ? r1, =(CONFIG_FLASH_SIZE >> 12) ?@ size of FLASH (must be >= 4KB)
> ? ? ? ?mov ? ? r2, #10 ? ? ? ? ? ? ? ? ? ? ? ? @ 11 is the minimum (4KB)
> ?1: ? ? add ? ? r2, r2, #1 ? ? ? ? ? ? ? ? ? ? ?@ area size *= 2
> - ? ? ? mov ? ? r1, r1, lsr #1
> + ? ? ? movs ? ?r1, r1, lsr #1 ? ? ? ? ? ? ? ? ?@ set zero bit if r1=0
> ? ? ? ?bne ? ? 1b ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?@ count not zero r-shift
> ? ? ? ?orr ? ? r0, r0, r2, lsl #1 ? ? ? ? ? ? ?@ the area register value
> ? ? ? ?orr ? ? r0, r0, #1 ? ? ? ? ? ? ? ? ? ? ?@ set enable bit
> diff --git a/arch/arm/mm/proc-arm946.S b/arch/arm/mm/proc-arm946.S
> index 683af3a..731388a 100644
> --- a/arch/arm/mm/proc-arm946.S
> +++ b/arch/arm/mm/proc-arm946.S
> @@ -341,7 +341,7 @@ __arm946_setup:
> ? ? ? ?ldr ? ? r1, =(CONFIG_DRAM_SIZE >> 12) ? @ size of RAM (must be >= 4KB)
> ? ? ? ?mov ? ? r2, #10 ? ? ? ? ? ? ? ? ? ? ? ? @ 11 is the minimum (4KB)
> ?1: ? ? add ? ? r2, r2, #1 ? ? ? ? ? ? ? ? ? ? ?@ area size *= 2
> - ? ? ? mov ? ? r1, r1, lsr #1
> + ? ? ? movs ? ?r1, r1, lsr #1 ? ? ? ? ? ? ? ? ?@ set zero bit if r1=0
> ? ? ? ?bne ? ? 1b ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?@ count not zero r-shift
> ? ? ? ?orr ? ? r0, r0, r2, lsl #1 ? ? ? ? ? ? ?@ the region register value
> ? ? ? ?orr ? ? r0, r0, #1 ? ? ? ? ? ? ? ? ? ? ?@ set enable bit
> @@ -351,7 +351,7 @@ __arm946_setup:
> ? ? ? ?ldr ? ? r1, =(CONFIG_FLASH_SIZE >> 12) ?@ size of FLASH (must be >= 4KB)
> ? ? ? ?mov ? ? r2, #10 ? ? ? ? ? ? ? ? ? ? ? ? @ 11 is the minimum (4KB)
> ?1: ? ? add ? ? r2, r2, #1 ? ? ? ? ? ? ? ? ? ? ?@ area size *= 2
> - ? ? ? mov ? ? r1, r1, lsr #1
> + ? ? ? movs ? ?r1, r1, lsr #1 ? ? ? ? ? ? ? ? ?@ set zero bit if r1=0
> ? ? ? ?bne ? ? 1b ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?@ count not zero r-shift
> ? ? ? ?orr ? ? r0, r0, r2, lsl #1 ? ? ? ? ? ? ?@ the region register value
> ? ? ? ?orr ? ? r0, r0, #1 ? ? ? ? ? ? ? ? ? ? ?@ set enable bit
> --
> 1.7.1
>
>Hello Mr choi,
Sorry for my previous top posting.
If there is no issue with this patch can you apply to your for-next tree
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
^ permalink raw reply
* [PATCH 18/26] ARM: pxa: MTD_XIP is not actually working any more
From: Eric Miao @ 2011-10-08 7:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317499438-14058-19-git-send-email-arnd@arndb.de>
On Sun, Oct 2, 2011 at 4:03 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> The headers files required for XIP support have moved around
> over the last few years, and the code no longer builds.
> Until someone fixes this, let's just disable support, leaving
> sa1100 as the only platform still supporting xip.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
It is actually fixable, the problem is really mtd-xip.h is referencing
the interrupt registers directly which I moved them to mach-pxa/irq.c
for better modularization.
I'm fine to drop XIP. I'm afraid Nico's gonna be a bit disappointed
as I broke his favorite XIP code :-)
> ---
> ?arch/arm/Kconfig | ? ?1 -
> ?1 files changed, 0 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 570c9fd..71b0ccb 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -619,7 +619,6 @@ config ARCH_PNX4008
> ?config ARCH_PXA
> ? ? ? ?bool "PXA2xx/PXA3xx-based"
> ? ? ? ?depends on MMU
> - ? ? ? select ARCH_MTD_XIP
> ? ? ? ?select ARCH_HAS_CPUFREQ
> ? ? ? ?select CLKDEV_LOOKUP
> ? ? ? ?select CLKSRC_MMIO
> --
> 1.7.5.4
>
>
^ permalink raw reply
* [PATCH 06/26] ARM: pxa: add missing header inclusions
From: Russell King - ARM Linux @ 2011-10-08 8:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMPhdO8FGTw7NzNNjK819zF3GjrRX0ybPyaSFR4U7oG8cGmDtQ@mail.gmail.com>
On Fri, Oct 07, 2011 at 01:08:23PM +0800, Eric Miao wrote:
> On Sun, Oct 2, 2011 at 4:03 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> > These resulted in build breakage in some configurations:
> >
> > arch/arm/mach-pxa/irq.c:132:39: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'icip_handle_irq'
> >
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > ---
> > ?arch/arm/mach-pxa/irq.c | ? ?1 +
> > ?1 files changed, 1 insertions(+), 0 deletions(-)
> >
> > diff --git a/arch/arm/mach-pxa/irq.c b/arch/arm/mach-pxa/irq.c
> > index b09e848..848e96d 100644
> > --- a/arch/arm/mach-pxa/irq.c
> > +++ b/arch/arm/mach-pxa/irq.c
> > @@ -16,6 +16,7 @@
> > ?#include <linux/module.h>
> > ?#include <linux/interrupt.h>
> > ?#include <linux/syscore_ops.h>
> > +#include <linux/ftrace.h>
>
> It's actually __irq_entry being defined in <linux/ftrace.h> and in turn
> __exception_irq_entry being conditionally defined to that.
>
> I think it's better to fix this in <asm/system.h> instead of in the
> cases where this macro is referenced?
>
> Russell?
There's a patch in the patch system which fixes this (7115/3) but I
can't apply it because it doesn't apply to anything in my for-next
tree (it applies to the obsolete 'devel' branch which is rather old
now.)
^ permalink raw reply
* [PATCH 19/26] ARM: pxa: CPU_FREQ_TABLE is needed for CPU_FREQ
From: Eric Miao @ 2011-10-08 8:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317499438-14058-20-git-send-email-arnd@arndb.de>
On Sun, Oct 2, 2011 at 4:03 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> The pxa specific cpufreq code is based on the cpu_freq_table
> module, so we have to select that.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Applied.
> ---
> ?arch/arm/Kconfig | ? ?1 +
> ?1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 71b0ccb..3b84eda 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -1926,6 +1926,7 @@ config CPU_FREQ_PXA
> ? ? ? ?bool
> ? ? ? ?depends on CPU_FREQ && ARCH_PXA && PXA25x
> ? ? ? ?default y
> + ? ? ? select CPU_FREQ_TABLE
> ? ? ? ?select CPU_FREQ_DEFAULT_GOV_USERSPACE
>
> ?config CPU_FREQ_S3C
> --
> 1.7.5.4
>
>
^ permalink raw reply
* [PATCH 00/24 V2] OMAP4: PM: suspend, CPU-hotplug and CPUilde support
From: Santosh Shilimkar @ 2011-10-08 8:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87vcs0ifgn.fsf@ti.com>
On Saturday 08 October 2011 04:20 AM, Kevin Hilman wrote:
> Kevin Hilman <khilman@ti.com> writes:
>
>> Hi Santosh,
>>
>> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
>>
>>> The series adds OMAP4 MPUSS (MPU SubSystem) power management support for
>>> suspend (S2R), CPU hotplug and CPUidle.
>>
>> Just noticed when doing some final build/sanity testing that there are a
>> few of compile/link warnings/problems when the kernel is built without
>> CONFIG_PM
>>
>> Some warnings:
>>
>> /work/kernel/omap/pm/arch/arm/mach-omap2/omap-wakeupgen.c:203:13: warning: 'irq_save_context' defined but not used
>> /work/kernel/omap/pm/arch/arm/mach-omap2/omap-wakeupgen.c:270:13: warning: 'irq_save_secure_context' defined but not used
>>
Sory I missed it in my builds.
[...]
> Please just cleanup the wakeupgen compile warnings and update your
> branch.
>
Done !!
Updated branch : for_3_2/omap4-mpuss-pm_2
Regards
Santosh
^ permalink raw reply
* [PATCH 1/4] mmc: mmci: Bugfix in pio read for small packets
From: Russell King - ARM Linux @ 2011-10-08 9:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4E8F028C.10102@stericsson.com>
On Fri, Oct 07, 2011 at 03:45:48PM +0200, Ulf Hansson wrote:
> My feeling is that since discussing this patch, the rest of the patches
> in this serie and are kind of "put on hold". The reason for keeping them
> together is more of functional purpose. I hope you can have a look at
> them anyway, they shall be possible to apply without this one.
Well, the patch system says that each one depends on the previous one,
and the first one in the series contains the PIO read thing.
Do 7108/1 onwards depend on 7106/1 and 7107/1 ?
^ permalink raw reply
* [PATCH 2/2] pinmux: add a driver for the U300 pinmux
From: Barry Song @ 2011-10-08 9:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317629883-13582-1-git-send-email-linus.walleij@stericsson.com>
> +static int __init u300_pmx_probe(struct platform_device *pdev)
> +{
> + ? ? ? int ret;
> + ? ? ? struct u300_pmx *upmx;
> + ? ? ? struct resource *res;
> +
> + ? ? ? /* Create state holders etc for this driver */
> + ? ? ? upmx = devm_kzalloc(&pdev->dev, sizeof(struct u300_pmx), GFP_KERNEL);
and this would be "devm_kzalloc(&pdev->dev, sizeof(*upmx), GFP_KERNEL); " ?
> + ? ? ? if (!upmx)
> + ? ? ? ? ? ? ? return -ENOMEM;
> +
> + ? ? ? upmx->dev = &pdev->dev;
> +
> + ? ? ? res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + ? ? ? if (!res) {
> + ? ? ? ? ? ? ? ret = -ENOENT;
> + ? ? ? ? ? ? ? goto out_no_resource;
> + ? ? ? }
> + ? ? ? upmx->phybase = res->start;
> + ? ? ? upmx->physize = resource_size(res);
> +
> + ? ? ? if (request_mem_region(upmx->phybase, upmx->physize,
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?DRIVER_NAME) == NULL) {
> + ? ? ? ? ? ? ? ret = -EBUSY;
> + ? ? ? ? ? ? ? goto out_no_memregion;
> + ? ? ? }
> +
> + ? ? ? upmx->virtbase = ioremap(upmx->phybase, upmx->physize);
> + ? ? ? if (!upmx->virtbase) {
> + ? ? ? ? ? ? ? ret = -ENOMEM;
> + ? ? ? ? ? ? ? goto out_no_remap;
> + ? ? ? }
> +
> + ? ? ? upmx->pctl = pinctrl_register(&u300_pmx_desc, &pdev->dev, upmx);
> + ? ? ? if (IS_ERR(upmx->pctl)) {
> + ? ? ? ? ? ? ? dev_err(&pdev->dev, "could not register U300 pinmux driver\n");
> + ? ? ? ? ? ? ? ret = PTR_ERR(upmx->pctl);
> + ? ? ? ? ? ? ? goto out_no_pmx;
> + ? ? ? }
> +
> + ? ? ? /* We will handle a range of GPIO pins */
> + ? ? ? pinctrl_add_gpio_range(upmx->pctl, &u300_gpio_range);
> +
> + ? ? ? platform_set_drvdata(pdev, upmx);
> +
> + ? ? ? u300_pmx_dumpregs(upmx);
> +
> + ? ? ? dev_info(&pdev->dev, "initialized U300 pinmux driver\n");
> +
> + ? ? ? return 0;
> +
> +out_no_pmx:
> + ? ? ? iounmap(upmx->virtbase);
> +out_no_remap:
> + ? ? ? platform_set_drvdata(pdev, NULL);
> +out_no_memregion:
> + ? ? ? release_mem_region(upmx->phybase, upmx->physize);
> +out_no_resource:
> + ? ? ? devm_kfree(&pdev->dev, upmx);
> + ? ? ? return ret;
> +}
> +
-barry
^ permalink raw reply
* [PATCH 2/2] pinmux: add a driver for the U300 pinmux
From: Barry Song @ 2011-10-08 9:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317629883-13582-1-git-send-email-linus.walleij@stericsson.com>
> +static void __init u300_pmx_dumpregs(struct u300_pmx *upmx)
> +{
> + ? ? ? u16 regval;
> + ? ? ? int i;
> +
> + ? ? ? for (i = 0; i < ARRAY_SIZE(u300_pmx_registers); i++) {
> + ? ? ? ? ? ? ? regval = readw(upmx->virtbase + u300_pmx_registers[i]);
> + ? ? ? ? ? ? ? dev_info(upmx->dev, "PMX%u: 0x%04x\n", i, regval);
> + ? ? ? }
> +}
> +
is this a debug information or do you want it to be in mainline?
-barry
^ permalink raw reply
* [PATCH 20/26] ARM: pxa: select FB_PXA on saar and tevorevb
From: Eric Miao @ 2011-10-08 9:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317499438-14058-21-git-send-email-arnd@arndb.de>
On Sun, Oct 2, 2011 at 4:03 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> The saar and tevorevb platforms call pxafb_smart_flush from board
> code, and that function is defined in the framebuffer code, so it
> cannot be disabled.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> ?arch/arm/mach-pxa/Kconfig | ? ?4 ++++
> ?1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-pxa/Kconfig b/arch/arm/mach-pxa/Kconfig
> index bb310d0..cd94f2f 100644
> --- a/arch/arm/mach-pxa/Kconfig
> +++ b/arch/arm/mach-pxa/Kconfig
> @@ -61,11 +61,15 @@ config MACH_TAVOREVB
> ? ? ? ?bool "PXA930 Evaluation Board (aka TavorEVB)"
> ? ? ? ?select PXA3xx
> ? ? ? ?select CPU_PXA930
> + ? ? ? select FB_PXA
> + ? ? ? select FB
>
> ?config MACH_SAAR
> ? ? ? ?bool "PXA930 Handheld Platform (aka SAAR)"
> ? ? ? ?select PXA3xx
> ? ? ? ?select CPU_PXA930
> + ? ? ? select FB_PXA
> + ? ? ? select FB
Hi Arnd,
The option really matters is FB_PXA_SMARTPANEL, which adds support
for the display driver to control an external "smart" LCD panel. And how
about the patch below to fix this - as normal, make empty functions
when not enabled?
diff --git a/arch/arm/mach-pxa/include/mach/pxafb.h
b/arch/arm/mach-pxa/include/mach/pxafb.h
index 01a45ac..486b4c5 100644
--- a/arch/arm/mach-pxa/include/mach/pxafb.h
+++ b/arch/arm/mach-pxa/include/mach/pxafb.h
@@ -158,5 +158,18 @@ struct pxafb_mach_info {
void pxa_set_fb_info(struct device *, struct pxafb_mach_info *);
unsigned long pxafb_get_hsync_time(struct device *dev);
+#ifdef CONFIG_FB_PXA_SMARTPANEL
extern int pxafb_smart_queue(struct fb_info *info, uint16_t *cmds, int);
extern int pxafb_smart_flush(struct fb_info *info);
+#else
+static inline int pxafb_smart_queue(struct fb_info *info,
+ uint16_t *cmds, int n)
+{
+ return 0;
+}
+
+static inline int pxafb_smart_flush(struct fb_info *info)
+{
+ return 0;
+}
+#endif
diff --git a/drivers/video/pxafb.c b/drivers/video/pxafb.c
index 0f4e8c9..389530b 100644
--- a/drivers/video/pxafb.c
+++ b/drivers/video/pxafb.c
@@ -1309,16 +1309,6 @@ static int pxafb_smart_init(struct pxafb_info *fbi)
return 0;
}
#else
-int pxafb_smart_queue(struct fb_info *info, uint16_t *cmds, int n_cmds)
-{
- return 0;
-}
-
-int pxafb_smart_flush(struct fb_info *info)
-{
- return 0;
-}
-
static inline int pxafb_smart_init(struct pxafb_info *fbi) { return 0; }
#endif /* CONFIG_FB_PXA_SMARTPANEL */
^ permalink raw reply related
* [PATCH 21/26] ARM: pxa: select POWER_SUPPLY on raumfeld
From: Eric Miao @ 2011-10-08 9:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317499438-14058-22-git-send-email-arnd@arndb.de>
On Sun, Oct 2, 2011 at 4:03 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> The raumfeld platform code calls power_supply_set_battery_charged
> which is part of the power supply layer, so that always has
> to be enabled.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
A better way might be for the raumfeld board file to compile the code
based on whether POWER_SUPPLY is selected. However, the power supply
code for raumfeld is a bit difficult to separate indeed, let's merge this
before that happens.
Daniel?
> ---
> ?arch/arm/mach-pxa/Kconfig | ? ?3 +++
> ?1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-pxa/Kconfig b/arch/arm/mach-pxa/Kconfig
> index cd94f2f..491c522 100644
> --- a/arch/arm/mach-pxa/Kconfig
> +++ b/arch/arm/mach-pxa/Kconfig
> @@ -453,15 +453,18 @@ config MACH_RAUMFELD_RC
> ? ? ? ?bool "Raumfeld Controller"
> ? ? ? ?select PXA3xx
> ? ? ? ?select CPU_PXA300
> + ? ? ? select POWER_SUPPLY
> ? ? ? ?select HAVE_PWM
>
> ?config MACH_RAUMFELD_CONNECTOR
> ? ? ? ?bool "Raumfeld Connector"
> + ? ? ? select POWER_SUPPLY
> ? ? ? ?select PXA3xx
> ? ? ? ?select CPU_PXA300
>
> ?config MACH_RAUMFELD_SPEAKER
> ? ? ? ?bool "Raumfeld Speaker"
> + ? ? ? select POWER_SUPPLY
> ? ? ? ?select PXA3xx
> ? ? ? ?select CPU_PXA300
>
> --
> 1.7.5.4
>
>
^ permalink raw reply
* [PATCH 20/26] ARM: pxa: select FB_PXA on saar and tevorevb
From: Arnd Bergmann @ 2011-10-08 10:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMPhdO8ke1M2aFAqzfmFB-MWj6m5JsCYC_zYBC=iSX1L6kWwTw@mail.gmail.com>
On Saturday 08 October 2011 17:50:31 Eric Miao wrote:
>
> The option really matters is FB_PXA_SMARTPANEL, which adds support
> for the display driver to control an external "smart" LCD panel. And how
> about the patch below to fix this - as normal, make empty functions
> when not enabled?
>
Yes, your patch looks better than mine.
Thanks,
Arnd
^ permalink raw reply
* [PATCH 22/26] ARM: pxa: only select SMC91x on xcep when networking is enabled
From: Eric Miao @ 2011-10-08 10:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317499438-14058-23-git-send-email-arnd@arndb.de>
On Sun, Oct 2, 2011 at 4:03 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> The smc91x driver is not strictly required for xcep, but it
> can only be enabled if ethernet support is built into the
> kernel, so make the dependency more specific.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> ?arch/arm/mach-pxa/Kconfig | ? ?2 +-
> ?1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-pxa/Kconfig b/arch/arm/mach-pxa/Kconfig
> index 491c522..ef35ce9 100644
> --- a/arch/arm/mach-pxa/Kconfig
> +++ b/arch/arm/mach-pxa/Kconfig
> @@ -174,7 +174,7 @@ config MACH_XCEP
> ? ? ? ?select MTD_CFI_INTELEXT
> ? ? ? ?select MTD_CFI
> ? ? ? ?select MTD_CHAR
> - ? ? ? select SMC91X
> + ? ? ? select SMC91X if NET_ETHERNET
Or let's just remove this 'select SMC91X' completely as it's not
strictly required?
BTW - how's the Kconfig cleanup works going? I guess going forward,
the best way for such cases might be to introduce HAVE_SMC91X, and
let SMC91X to depend on this? However, that could in turn introduce
a massive number of HAVE_* for various drivers.
> ? ? ? ?help
> ? ? ? ? ?PXA255 based Single Board Computer with SMC 91C111 ethernet chip and 64 MB of flash.
> ? ? ? ? ?Tuned for usage in Libera instruments for particle accelerators.
> --
> 1.7.5.4
>
>
^ permalink raw reply
* [PULL] i.MX
From: Sascha Hauer @ 2011-10-08 10:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201110072230.18233.arnd@arndb.de>
On Fri, Oct 07, 2011 at 10:30:18PM +0200, Arnd Bergmann wrote:
> On Tuesday 04 October 2011, Sascha Hauer wrote:
> > Please pull the following for next. There are merge conflicts between
> > the cleanup and the features branch, so I decided to merge them together
> > so you don't have to handle the conflicts yourself. Please let me know
> > if this is ok for you or if we have to find another solution.
>
> Hi Sascha,
>
> it took me a while to figure out what you are doing here, but I think I've
> made it in the end. I recreated the imx/cleanup and imx/devel branches
> from the commit you sent me and made sure everything was still there, then
> did the merge again and took the conflict resolution that you had
> provided.
Well it also took me a while to figure out what I should do ;) The
problem I had started with the second pull request which partly depended
on the first one, so I decided to use the commits of the first pull
request as a base.
>
> I also recreated the next/devel branch to have a cleaner history with
> the same contents after that.
>
> I also took out the ata stuff into a separate branch, and will decide
> later if I submit that before the rest or as part of the devel branch.
>
> Please check if the branch contents are ok for you now and if the for-next
> branch work for you.
Compiles and works smoothly and everything seems to be there. Thanks.
>
> I've been thinking about these dependencies a bit more in general. I
> think a good solution is how Tony does it for the omap branches:
> There are lots of feature branches and he sends the bigger ones
> individually to me instead of one big 'devel' branch, so I can decide
> how to group them with other stuff (e.g. your ata changes can go
> into a driver branch). Any significant cleanups go *first* in each
> branch in order to avoid having to do a merge between feature and
> cleanup branches for the conflict resolution. There are (at least)
> two ways to get there, I don't mind which one you prefer:
>
> 1. Apply all cleanups into one branch, then start each feature branch
> from the latest (at that time) version of the cleanup branch.
> 2. Keep the cleanups local to the feature branches, but have them
> first in each branch. Then create the global cleanup branch by
> merging the cleanup parts of each branch together.
>
> In the end, the thing I'm interested in is being able to reasonably
> argue stuff like:
> a) This branch contains only cleanups. The number of lines changed
> may be huge, but you can easily tell from each commit that the
> code quality is improving throughout the branch.
> b) This is a feature branch. We've tried our best to keep each
> feature as clean and small as possible and from the commits
> it is clear to see why these changes are necessary in order to
> make progress.
>
> When you get to a point where you have to do a manual merge between
> branches because there was no easier solution, I generally want
> to be the person to do the merge. If the merge is nontrivial,
> I certainly like to see a branch that contains the resolution
> that you ended up with, so I can do the same, but I also want to
> understand what you do, and that is easier if I get individual
> branches.
Ok, the last paragraph explains it for me. As you might have noticed
I keep all branches seperated by topics anyway, so I have no problem
letting you pull what you prefer, only I wanted to resolve the merge
conflicts myself. What I'll do next time is that I leave resolving
conflicts up to you but provide a second branch with all necessary
merges as a hint for you.
I think I still have to learn that merge conflicts are no bad thing at
all.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* Question about "Inconsistent kallsyms data"
From: Eric Miao @ 2011-10-08 10:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4E382602.6050308@grupopie.com>
On Wed, Aug 3, 2011 at 12:29 AM, Paulo Marques <pmarques@grupopie.com> wrote:
> Tomasz Figa wrote:
>> On Friday 29 of July 2011 at 12:58:32, Tomasz Figa wrote:
>>>[...]
>>> I will try to bisect the case with s3c6400 defconfig.
>>
>> I have no idea why, but I cannot reproduce the issue anymore, even after make
>> distclean or starting with a clean tree. A build system bug?
>>
>> I do not know much technical details about the kernel build system, but might
>> it be a concurrency issue (I use make -j5 for building with 5 jobs)?
>
> Usually this is caused by symbols moving slightly between kernel compiles.
>
> This is an explanation of the process I wrote a while ago in a different
> thread at LKML:
>
>> Now as for CONFIG_KALLSYMS_EXTRA_PASS: to build the kallsyms table, the
>> build process first links a kernel image with an empty kallsyms table
>> and use that to fetch information for all the symbols.
>>
>> It then uses that information to build the table with the right size,
>> and links it again. If everything goes ok, this new version as all the
>> symbols in the correct places and the final table can be built with the
>> correct addresses.
>>
>> The final linking should produce the same result as only the data on the
>> kallsyms table changed, but not its size.
>>
>> However, there have been bugs in the past with section alignments and
>> symbol reordering for symbols with the same address, etc., etc. that
>> make this final table not have the exact same size, and the build fails
>> with an inconsistent kallsyms data message. At this point, the user can
>> turn on the CONFIG_KALLSYMS_EXTRA_PASS and temporarily solve the problem
>> while the developers find the correct fix. Without this option, in this
>> situation the kernel would simply fail the compilation.
>>
>> All this has been stable for a while and this option hasn't been needed
>> recently (AFAIK), but if there is some bug in some new binutils or
>> something, the option might be needed again.
>
> To check inconsistencies, the Makefile compares ".tmp_System.map" and
> "System.map" for differences.
>
> On a normal build they should be identical, but if this fails with
> "Inconsistent kallsyms data" you could try comparing the two files to
> check which symbols are causing trouble.
I met this issue today as well. Didn't have a chance to compare the
files, as I did a 'rm -fr ../build' and reconfigured/re-built everything,
and 'make O=../build clean' didn't work for me.
I'm using a toolchain with version info as below:
$ arm-linux-gnueabi-gcc -v
Using built-in specs.
COLLECT_GCC=arm-linux-gnueabi-gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabi/4.5.2/lto-wrapper
Target: arm-linux-gnueabi
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.5.2-8ubuntu3'
--with-bugurl=file:///usr/share/doc/gcc-4.5/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.5 --enable-shared --enable-multiarch
--with-multiarch-defaults=i386-linux-gnu --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix
--with-gxx-include-dir=/usr/arm-linux-gnueabi/include/c++/4.5.2
--libdir=/usr/lib --enable-nls --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-plugin
--enable-gold --enable-ld=default --with-plugin-ld=ld.gold
--enable-objc-gc --disable-sjlj-exceptions --with-arch=armv7-a
--with-float=softfp --with-fpu=vfpv3-d16 --with-mode=thumb
--disable-werror --enable-checking=release
--program-prefix=arm-linux-gnueabi-
--includedir=/usr/arm-linux-gnueabi/include --build=i686-linux-gnu
--host=i686-linux-gnu --target=arm-linux-gnueabi
--with-headers=/usr/arm-linux-gnueabi/include
--with-libs=/usr/arm-linux-gnueabi/lib
Thread model: posix
gcc version 4.5.2 (Ubuntu/Linaro 4.5.2-8ubuntu3)
>
> --
> Paulo Marques - www.grupopie.com
>
> "All generalizations are false."
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
^ permalink raw reply
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