* [PATCH 2/6] ARM: pxa2xx: reorganize I2C files
From: Eric Miao @ 2011-03-02 3:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4D6D9426.8030905@fluff.org>
On Wed, Mar 2, 2011 at 8:49 AM, Ben Dooks <ben-linux@fluff.org> wrote:
> On 23/02/11 11:38, Sebastian Andrzej Siewior wrote:
>>
>> This patch moves the platform data definition from
>> arch/arm/plat-pxa/include/plat/i2c.h to include/linux/i2c/pxa-i2c.h so
>> it can be accessed from x86 the same way as on ARM.
>>
>> This change should make no functional change to the PXA code. The move
>> is verified by building the following defconfigs:
>> ? cm_x2xx_defconfig corgi_defconfig em_x270_defconfig ezx_defconfig
>> ? imote2_defconfig pxa3xx_defconfig spitz_defconfig zeus_defconfig
>> ? raumfeld_defconfig magician_defconfig mmp2_defconfig pxa168_defconfig
>> ? pxa910_defconfig
>>
>
> Russell/others, you OK with this going through my tree?
>
Ben, I'm fine that you take this change. Trivial changes to me, so
I expect no significant merge conflicts.
^ permalink raw reply
* [PATCH] msm: gpiomux: Remove GPIOMUX_VALID and merge config enums
From: Saravana Kannan @ 2011-03-02 2:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTi=ePu9hTeecOfKoxKEXd6VZ6tJBN2XphDO5suOA@mail.gmail.com>
On 03/01/2011 06:25 PM, Dima Zavin wrote:
> Good point, ptr to anon struct would work.
Glad to know the suggestion helped.
> I would still very much like to see the helper macros be added though
> as it really would be very helpful in keeping the pinmuxing tidy in
> the board files. Doing it as a separate patch is fine.
>
> Other than the addition of helper macros, ack.
Rohit, would you mind adding the helper macros that use pointer to anon
struct to simplify the GPIO config population in the board files? You
can contact me offline if you need any help with it.
Thanks,
Saravana
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply
* [PATCH 1/4] ARM:boot:device tree: Allow the device tree binary to be appended to zImage
From: Nicolas Pitre @ 2011-03-02 2:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4D6DA7C3.4040609@secretlab.ca>
On Tue, 1 Mar 2011, John Bonesio wrote:
> Comment/question below.
>
> On 02/28/2011 10:39 PM, Nicolas Pitre wrote:
> > On Mon, 28 Feb 2011, John Bonesio wrote:
> >
> >> @@ -288,12 +330,34 @@ wont_overwrite:
> >>
> >> /*
> >> * Relocate all entries in the GOT table.
> >> + * Bump bss entries to past image end (r10)
> >> */
> >> + sub r5, r10, r6 @ delta of image end and _edata
> >> + add r5, r5, #7 @ ... rounded up to a multiple
> >> + bic r5, r5, #7 @ ... of 8 bytes, so misaligned
> >> + @ ... GOT entry doesn't
> >> + @ ... overwrite end of image
> >
> > This is wrong. You are going to displace the .bss pointers even if they
> > don't need that in the case where no dtb was found. And if a dtb was
> > found the displacement is going to be the size of the dtb _plus_ the
> > size of the .bss_stack instead of only the dtb size.
> >
> > At this point you should only keep track of the .bss displacement in
> > addition to the delta offset in r0. And if both are equal to zero then
> > skip over the fixup loop as before.
>
> Maybe I'm not understanding correctly. I think that if there is an
> appended dtb, then there are sections like the code and data that needs
> to be adjusted by the old r0 value, while the bss and the stack need to
> be adjusted by the old r0 + dtb size.
Exact.
> If my understanding is right, then we can't just add the dtb size to r0
> and adjust everything.
indeed.
> Am I missing something?
Suppose that no dtb was found. In that case, r10 is still pointing to
the top of the stack. So r5 will contain the size of .bss and the
stack. Then you bump .bss pointers in the GOT by that size. If a dtb
was found then r5 ends up with the size of the dtb plus .bss plus stack.
What I'm suggesting is that the size of the dtb be kept in a register of
its own up to this point. That size can be 0 if none was found. If
r0 == 0 and dtb_size == 0 then the whole GOT fixup can be skipped as it
is done at the moment by branching to not_relocated.
Nicolas
^ permalink raw reply
* [PATCHv5 0/3] Introduce the /proc/socinfo and use it to export OMAP data
From: Saravana Kannan @ 2011-03-02 2:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4D6DAE6E.4030701@bluewatersys.com>
On 03/01/2011 06:41 PM, Ryan Mallon wrote:
> On 03/02/2011 03:23 PM, Saravana Kannan wrote:
>> I don't have any attachment to the "arch" file suggestion. If there is a
>> better solution to identify the different implementations of socinfo
>> without having to maintain some "unique id" list in the kernel, then I'm
>> all for it. But cpuinfo is not it.
>
> Sorry I am confusing the 'arch' and 'mach' bits here. I definitely have
> an objection to having an 'arch' file (i.e. ARM). A 'mach' (i.e. omap)
> file makes a bit more sense, but should probably be called 'mach' rather
> than 'arch' to avoid this confusion :-).
Sorry for the confusion. Sure, I don't care much for the filename as
long as we can all agree on it. I care more about the content of the
file (using names very close to xxxx in mach-xxxx). I like "soc-family"
better since it's generic enough to not force, say omap3 and omap4, to
report different values.
Linus Walleij, Eduardo, Maxime, Andrei,
Would like to hear your opinion on the file name (soc-family vs. mach vs
<somethingelse>) and the path /sys/devices/system/soc/.
If we settle on this, may be it would be easier to get this through.
> I still think it is a solution in search of a problem though. What
> userspace programs need to know what specific SoC they are on? My
> feeling is that if userspace needs to know this information, then it is
> probably dicking around with things that should be managed by the
> kernel. Differences in available peripherals, etc can be determined by
> looking at existing sysfs files.
I certainly have seen several use cases. Couple of easy examples:
* A lot of test scripts would find this very useful. For example, some
clock (present is all/most MSMs) shouldn't be tested on some SOCs as it
would lock up the system if you try to turn it off while the CPU is running.
* Some of the user space tools might want to report different "product
id/type" (nothing to do with USB, etc) depending on what SOC it is
running on.
Thank,
Saravana
P.S: Removed felipe.balbi at nokia.com <felipe.balbi@nokia.com> since I
keep getting delivery failure emails.
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply
* [PATCHv5 0/3] Introduce the /proc/socinfo and use it to export OMAP data
From: Ryan Mallon @ 2011-03-02 2:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4D6DAA24.3000204@codeaurora.org>
On 03/02/2011 03:23 PM, Saravana Kannan wrote:
> On 03/01/2011 05:51 PM, Ryan Mallon wrote:
>> On 03/02/2011 02:39 PM, Saravana Kannan wrote:
>>> On 03/01/2011 05:27 PM, Ryan Mallon wrote:
>>>> On 03/02/2011 02:19 PM, Saravana Kannan wrote:
>>>>> On 03/01/2011 05:13 PM, Andrei Warkentin wrote:
>>>>>> On Mon, Feb 28, 2011 at 10:51 PM, Saravana Kannan
>>>>>> <skannan@codeaurora.org> wrote:
>>>>
>>>> <snip>
>>>>
>>>>>> What would an "arch" file mean? The name of the soc platform?
>>>>>
>>>>> The arch file would pretty much be the "xxxx" from
>>>>> arch/arm/mach-xxxx or
>>>>> similar paths. If that info is already available elsewhere, then that
>>>>> file is not needed. I proposed using the arch since that will
>>>>> remove the
>>>>> need to maintain some database of unique/reserved names/numbers for
>>>>> each
>>>>> implementation of socinfo (like the machinetypes list we have).
>>>>
>>>> /proc/cpuinfo already tells you what the CPU is, which gives more
>>>> information than just the architecture name.
>>>>
>>>> Why is the arch information even required by userspace?
>>>
>>> The socinfo exported by each soc is different. If userspace is trying to
>>> make decisions based on socinfo, it will need to know what type of soc
>>> (really what type of socinfo implementation) it is before trying to
>>> interpret the rest of the socinfo files. Keep in mind that cpuinfo is
>>> different from socinfo -- the cpu is just a small part of a soc.
>>
>> I understand that having a socinfo file for obtaining information about
>> a particular SoC would be useful. A similar discussion came up a few
>> years ago when we talked about having a socinfo file for exposing the
>> ep93xx Maverick crunch id, but nothing ever came out of it.
>>
>> What I don't understand is why you want the 'arch' file (ie the
>> mach-xxxx) name. /proc/cpuinfo already gives you more information than
>> an 'arch' file would. I also can't think of a particularly good
>> situation why userspace would need to know at runtime what the
>> architecture is.
>>
>> Have a socinfo file to expose implementation details of the particular
>> SoC I am fine with (assuming those details are useful to userspace),
>> having an 'arch' file to expose the architecture I am against.
>
> You probably already understood this, but just to be sure, when I say
> "socinfo implementation" I mean the various ways the socinfo data should
> be interpreted by userspace. "socid" of 1 would mean a different thing
> depending on whether it's for omap, msm, kirkwood, etc.
>
> I don't have any attachment to the "arch" file suggestion. If there is a
> better solution to identify the different implementations of socinfo
> without having to maintain some "unique id" list in the kernel, then I'm
> all for it. But cpuinfo is not it.
Sorry I am confusing the 'arch' and 'mach' bits here. I definitely have
an objection to having an 'arch' file (i.e. ARM). A 'mach' (i.e. omap)
file makes a bit more sense, but should probably be called 'mach' rather
than 'arch' to avoid this confusion :-).
I still think it is a solution in search of a problem though. What
userspace programs need to know what specific SoC they are on? My
feeling is that if userspace needs to know this information, then it is
probably dicking around with things that should be managed by the
kernel. Differences in available peripherals, etc can be determined by
looking at existing sysfs files.
~Ryan
--
Bluewater Systems Ltd - ARM Technology Solution Centre
Ryan Mallon 5 Amuri Park, 404 Barbadoes St
ryan at bluewatersys.com PO Box 13 889, Christchurch 8013
http://www.bluewatersys.com New Zealand
Phone: +64 3 3779127 Freecall: Australia 1800 148 751
Fax: +64 3 3779135 USA 1800 261 2934
^ permalink raw reply
* [PATCH 1/4] ARM:boot:device tree: Allow the device tree binary to be appended to zImage
From: Nicolas Pitre @ 2011-03-02 2:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4D6DA062.8010904@secretlab.ca>
On Tue, 1 Mar 2011, John Bonesio wrote:
> I have looked through, and I'm reworking the patch set. I have just one
> comment below.
>
> - John
>
> On 02/28/2011 10:39 PM, Nicolas Pitre wrote:
> > On Mon, 28 Feb 2011, John Bonesio wrote:
> >
[...]
> >> +
> >> + /* bump our bss registers too */
> >> + add r2, r2, r5
> >> + add r3, r3, r5
> >> +
> >> + /* bump the stack pinter, if at or above _edata */
> >> + cmp sp, r6
> >> + addcs sp, sp, r5
> >
> > This will always be true as this is within #ifndef CONFIG_ZBOOT_ROM.
>
> Right now sp will always be above r6. I thought it might be prudent to
> add the test in case the linker script changed and the stack was placed
> elsewhere. It might save someone a headache later.
That's what comments are for. And if someone modifies the linker script
without understanding the affected code then that someone deserves the
pain.
Nicolas
^ permalink raw reply
* [PATCH] msm: gpiomux: Remove GPIOMUX_VALID and merge config enums
From: Dima Zavin @ 2011-03-02 2:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4D689230.7020704@codeaurora.org>
Good point, ptr to anon struct would work.
I would still very much like to see the helper macros be added though
as it really would be very helpful in keeping the pinmuxing tidy in
the board files. Doing it as a separate patch is fine.
Other than the addition of helper macros, ack.
--Dima
On Fri, Feb 25, 2011 at 9:40 PM, Saravana Kannan <skannan@codeaurora.org> wrote:
> On 02/25/2011 05:20 PM, Dima Zavin wrote:
>>
>> On Fri, Feb 25, 2011 at 12:19 PM, Rohit Vaswani<rvaswani@codeaurora.org>
>> ?wrote:
>>>
>>> diff --git a/arch/arm/mach-msm/board-qsd8x50.c
>>> b/arch/arm/mach-msm/board-qsd8x50.c
>>> index 33ab1fe..d665b0e 100644
>>> --- a/arch/arm/mach-msm/board-qsd8x50.c
>>> +++ b/arch/arm/mach-msm/board-qsd8x50.c
>>> @@ -38,19 +38,26 @@
>>> ?#include "devices.h"
>>> ?#include "gpiomux.h"
>>>
>>> -#define UART3_SUSPENDED (GPIOMUX_DRV_2MA | GPIOMUX_PULL_DOWN |\
>>> - ? ? ? ? ? ?GPIOMUX_FUNC_1 | GPIOMUX_VALID)
>>> +static struct gpiomux_setting uart3_suspended = {
>>> + ? ?.drv = GPIOMUX_DRV_2MA,
>>> + ? ?.pull = GPIOMUX_PULL_DOWN,
>>> + ? ?.func = GPIOMUX_FUNC_1,
>>> +};
>>>
>>> ?extern struct sys_timer msm_timer;
>>>
>>> -struct msm_gpiomux_config qsd8x50_uart3_configs[] __initdata = {
>>> +struct msm_gpiomux_config qsd8x50_uart3_configs[] = {
>>> ? ? {
>>> ? ? ? ? .gpio = 86, /* UART3 RX */
>>> - ? ? ? ?.suspended = UART3_SUSPENDED,
>>> + ? ? ? ?.settings = {
>>> + ? ? ? ? ? ?[GPIOMUX_SUSPENDED] =&uart3_suspended,
>>> + ? ? ? ?},
>>> ? ? },
>>> ? ? {
>>> ? ? ? ? .gpio = 87, /* UART3 TX */
>>> - ? ? ? ?.suspended = UART3_SUSPENDED,
>>> + ? ? ? ?.settings = {
>>> + ? ? ? ? ? ?[GPIOMUX_SUSPENDED] =&uart3_suspended,
>>> + ? ? ? ?},
>>> ? ? },
>>> ?};
>>
>> I think this new interface is way too verbose and will quickly get
>> unwieldy for configurations that have more than a few pins. For
>> instance, imagine what the above would look like when muxing a 24bit
>> LCD pin list...
>>
>> How about adding a "bool valid" to gpiomux_setting, and convert the
>> "sets" array to an array of settings and not pointers to settings.
>> This will allow us to do (in gpiomux.h):
>>
>> struct msm_gpiomux_rec {
>> ? ? struct gpiomux_setting sets[GPIOMUX_NSETTINGS];
>> ? ? int ref;
>> };
>>
>> struct gpiomux_setting {
>> ? ? enum gpiomux_func func;
>> ? ? enum gpiomux_drv ?drv;
>> ? ? enum gpiomux_pull pull;
>> ? ? bool valid;
>> };
>>
>> This way, I can do something like (very rough):
>>
>> #define GPIOMUX_SET(func,drv,pull) { \
>> ? ? .func = GPIOMUX_##func, \
>> ? ? .drv = GPIOMUX_##drv, \
>> ? ? .pull = GPIOMUX_##pull, \
>> ? ? .valid = true, \
>> ? }
>>
>> #define GPIOMUX_SET_NONE { .valid = false, }
>>
>> #define GPIOMUX_CFG(g, active, suspended) { \
>> ? ? ?.gpio = g, \
>> ? ? ?.sets = { \
>> ? ? ? ? ?[GPIOMUX_ACTIVE] = active, \
>> ? ? ? ? ?[GPIOMUX_SUSPENDED] = suspended, \
>> ? ? ? }, \
>> ?}
>>
>> This will then allow me to define the uart3 pinmuxing in my board file
>> as follows:
>>
>> struct msm_gpiomux_rec uart3_mux_cfg[] = {
>> ? ? GPIOMUX_CFG(86, GPIOMUX_SET_NONE,
>> ? ? ? ? ? ? ? ? ? ? ? ? ? ?GPIOMUX_SET(FUNC_1, DRV_2MA, PULL_DOWN)),
>> ? ? GPIOMUX_CFG(87, GPIOMUX_SET_NONE,
>> ? ? ? ? ? ? ? ? ? ? ? ? ? ?GPIOMUX_SET(FUNC_1, DRV_2MA, PULL_DOWN)),
>> };
>>
>> Thoughts?
>>
>
> I haven't read this GPIO code thoroughly, but by looking just at the diff, I
> think you can still have these type of macros with the structure definition
> Rohit chose. I have no opinion one which struct definition is better (not
> enough context). Just trying to help with writing helper macros.
>
> The trick is to use pointers to anonymous struct. A very rough macro:
>
> #define GPIOMUX_SET(f, d, p) \
> &(struct gpiomux_setting) {
> ? ? ? ?.func = f,
> ? ? ? ?.drv = d,
> ? ? ? ?.pull = p,
> }
>
> #define GPIOMUX_CFG(g, active, suspended) { \
> ? ? ? ?.gpio = g,
> ? ? ? ?.settings = {
> ? ? ? ? ? ? ? ?[ACTIVE] = active,
> ? ? ? ? ? ? ? ?[SUSPENDED] = suspended,
> ? ? ? ?}
> }
>
> struct msm_gpiomux_config foo_bar[] = {
> ? ? ? ?GPIOMUX_CFG(10, GPIOMUX_SET(FUNC, 2MA, PULL_UP), NULL),
> ? ? ? ?GPIOMUX_CFG(11, GPIOMUX_SET(FUNC, 2MA, PULL_UP), NULL),
> };
>
> I'm certain the pointer to anonymous struct stuff works. You might have to
> tweak the macros a bit though. Hope this help.
>
> -Saravana
>
> --
> Sent by an employee of the Qualcomm Innovation Center, Inc.
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
>
^ permalink raw reply
* [PATCHv5 0/3] Introduce the /proc/socinfo and use it to export OMAP data
From: Saravana Kannan @ 2011-03-02 2:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4D6DA290.2010607@bluewatersys.com>
On 03/01/2011 05:51 PM, Ryan Mallon wrote:
> On 03/02/2011 02:39 PM, Saravana Kannan wrote:
>> On 03/01/2011 05:27 PM, Ryan Mallon wrote:
>>> On 03/02/2011 02:19 PM, Saravana Kannan wrote:
>>>> On 03/01/2011 05:13 PM, Andrei Warkentin wrote:
>>>>> On Mon, Feb 28, 2011 at 10:51 PM, Saravana Kannan
>>>>> <skannan@codeaurora.org> wrote:
>>>
>>> <snip>
>>>
>>>>> What would an "arch" file mean? The name of the soc platform?
>>>>
>>>> The arch file would pretty much be the "xxxx" from arch/arm/mach-xxxx or
>>>> similar paths. If that info is already available elsewhere, then that
>>>> file is not needed. I proposed using the arch since that will remove the
>>>> need to maintain some database of unique/reserved names/numbers for each
>>>> implementation of socinfo (like the machinetypes list we have).
>>>
>>> /proc/cpuinfo already tells you what the CPU is, which gives more
>>> information than just the architecture name.
>>>
>>> Why is the arch information even required by userspace?
>>
>> The socinfo exported by each soc is different. If userspace is trying to
>> make decisions based on socinfo, it will need to know what type of soc
>> (really what type of socinfo implementation) it is before trying to
>> interpret the rest of the socinfo files. Keep in mind that cpuinfo is
>> different from socinfo -- the cpu is just a small part of a soc.
>
> I understand that having a socinfo file for obtaining information about
> a particular SoC would be useful. A similar discussion came up a few
> years ago when we talked about having a socinfo file for exposing the
> ep93xx Maverick crunch id, but nothing ever came out of it.
>
> What I don't understand is why you want the 'arch' file (ie the
> mach-xxxx) name. /proc/cpuinfo already gives you more information than
> an 'arch' file would. I also can't think of a particularly good
> situation why userspace would need to know at runtime what the
> architecture is.
>
> Have a socinfo file to expose implementation details of the particular
> SoC I am fine with (assuming those details are useful to userspace),
> having an 'arch' file to expose the architecture I am against.
You probably already understood this, but just to be sure, when I say
"socinfo implementation" I mean the various ways the socinfo data should
be interpreted by userspace. "socid" of 1 would mean a different thing
depending on whether it's for omap, msm, kirkwood, etc.
I don't have any attachment to the "arch" file suggestion. If there is a
better solution to identify the different implementations of socinfo
without having to maintain some "unique id" list in the kernel, then I'm
all for it. But cpuinfo is not it.
Which data listed in cpuinfo do you think will let you identify the
socinfo implementation in a unique manner? The only thing that's even
remotely possible is vendor_id, but I'm not sure what it's supposed to
be if the CPU core is licensed from some vendor and used in a SOC by
another vendor. What is a Samsung with an ARM11 core supposed to list
for vendor_id? What if the another Samsung SOC has a Samsung's own CPU
core? What about non-ARM architectures? I would rather not add implicit
dependency on cpuinfo that's hard to maintain or guarantee and instead
have the socinfo implementation explicitly exported.
The "arch" filename and what it's supposed to contain was just a
suggestion. Another alternative might be to call it soc-family and the a
general guideline to keep it as close as possible to the mach-xxxx name.
For example, omap3 and omap4 might not care for having different socinfo
implementations and can decide to use the socfamily name of "omap".
Thanks,
Saravana
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply
* Common suspend and resume with L2 cache on
From: Colin Cross @ 2011-03-02 2:23 UTC (permalink / raw)
To: linux-arm-kernel
Now that common suspend helpers are in linux-next, I'm going back to
trying to use them with the L2 cache on, which is required when
implementing cpuidle states that put a cpu in reset in an SMP system.
There are a few obvious requirements - the stack pointer, stack
contents, and page tables must be flushed in the L2 during suspend.
There is one trickier problem. The current resume sequence starts from
reset, with cache and MMU off:
Restore cpu registers, including TTBR0, but not SCTLR
Rewrite the page table to map the MMU trampoline VA=PA
Restore SCTLR with dcache bit off (enables MMU)
Jump to virtual address
Restore SCTLR with original dcache bit
The page table is rewritten with the temporary mapping with the cache
off, so the write goes directly to memory. When the MMU is enabled,
the TTBR0 RGN and IRGN bits determine the cachability attributes of
the page table walk memory accesses. These bits are normally set to
cachable, so when the MMU is turned on, the page table walks can hit
the L2 instead of memory. If a stale entry for the temporary mapping
is in the L2, which can happen if it is prefetched by the other cpu
during suspend, the page table walk will not see the new mapping.
This could be fixed by restoring the TTBR0 register with caching
disabled, and re-enabling caching after the page table entry is
restored, or by switching to a custom page table prepared during init
to avoid any writes while the cache is off.
^ permalink raw reply
* [PATCH 1/4] ARM:boot:device tree: Allow the device tree binary to be appended to zImage
From: John Bonesio @ 2011-03-02 2:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.00.1103010019160.10356@xanadu.home>
Comment/question below.
On 02/28/2011 10:39 PM, Nicolas Pitre wrote:
> On Mon, 28 Feb 2011, John Bonesio wrote:
>
>> This patch provides the ability to boot using a device tree that is appended
>> to the raw binary zImage (e.g. cat zImage <filename>.dtb > zImage_w_dtb).
>>
>> Signed-off-by: John Bonesio <bones@secretlab.ca>
>
> Comments below.
>
>> ---
>>
>> arch/arm/Kconfig | 7 +++
>> arch/arm/boot/compressed/head.S | 93 ++++++++++++++++++++++++++++++++++++---
>> 2 files changed, 94 insertions(+), 6 deletions(-)
>>
>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
>> index d8a330f..68fc640 100644
>> --- a/arch/arm/Kconfig
>> +++ b/arch/arm/Kconfig
>> @@ -1593,6 +1593,13 @@ config USE_OF
>> help
>> Include support for flattened device tree machine descriptions.
>>
>> +config ARM_APPENDED_DTB
>> + bool "Use appended device tree blob" if OF
>> + default n
>
> The default is n by default, so you don't need to mention it.
>
> Also this should depend on OF (CONFIG_OF).
>
>> + help
>> + With this option, the boot code will look for a dtb bianry
>
> s/bianry/binary/
>
> Since this is an help text for people who might not have a clue about
> "dtb", it would be better to spell it out.
>
>> + appended to zImage.
>> +
>> # Compressed boot loader in ROM. Yes, we really want to ask about
>> # TEXT and BSS so we preserve their values in the config files.
>> config ZBOOT_ROM_TEXT
>> diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
>> index 200625c..ae9f8c6 100644
>> --- a/arch/arm/boot/compressed/head.S
>> +++ b/arch/arm/boot/compressed/head.S
>> @@ -210,6 +210,46 @@ restart: adr r0, LC0
>> */
>> mov r10, r6
>> #endif
>> +#ifdef CONFIG_ARM_APPENDED_DTB
>> +/*
>> + * r0 = delta
>> + * r2 = BSS start
>> + * r3 = BSS end
>> + * r4 = final kernel address
>> + * r5 = start of this image
>> + * r6 = _edata
>> + * r7 = architecture ID
>> + * r8 = atags/device tree pointer
>> + * r9 = size of decompressed image
>> + * r10 = end of this image, including bss/stack/malloc space if non XIP
>> + * r11 = GOT start
>> + * r12 = GOT end
>> + *
>> + * if there are device trees (dtb) appended to zImage, advance r10 so that the
>> + * dtb data will get relocated along with the kernel if necessary.
>> + */
>> +
>> + ldr r12, [r6, #0]
>> + ldr r1, =0xedfe0dd0 @ sig is 0xdoodfeed big endian
>> + cmp r12, r1
>> + bne dtb_check_done
>> +
>> + /* Get the dtb's size */
>> + ldr r12, [r6, #4] @ device tree size
>> +
>> + /* convert r12 (dtb size) to little endian */
>> + eor r1, r12, r12, ror #16
>> + bic r1, r1, #0x00ff0000
>> + mov r12, r12, ror #8
>> + eor r12, r12, r1, lsr #8
>> +
>> + add r10, r10, r12
>> + add r6, r6, r12
>> +
>> +dtb_check_done:
>> + adr r1, LC0
>> + ldr r12, [r1, #28] @ restore r12 (GOT end)
>> +#endif
>
> Instead of clobbering r12, you could use lr instead.
>
> The byte swap on the size should be done only if __ARMEB__ is not
> defined i.e. #ifndef __ARMEB__ ...
>
> Also the DT signature should be endian aware.
>
>> /*
>> * Check to see if we will overwrite ourselves.
>> @@ -223,8 +263,8 @@ restart: adr r0, LC0
>> */
>> cmp r4, r10
>> bhs wont_overwrite
>> - add r10, r4, r9
>> - cmp r10, r5
>> + add r1, r4, r9
>> + cmp r1, r5
>> bls wont_overwrite
>>
>> /*
>> @@ -272,8 +312,10 @@ wont_overwrite:
>> * r12 = GOT end
>> * sp = stack pointer
>> */
>> - teq r0, #0
>> - beq not_relocated
>> + adr r1, LC0
>> + ldr r6, [r1, #16] @ reload _edata value
>
> Why?
>
>> +
>> + add r6, r6, r0
>> add r11, r11, r0
>> add r12, r12, r0
>>
>> @@ -288,12 +330,34 @@ wont_overwrite:
>>
>> /*
>> * Relocate all entries in the GOT table.
>> + * Bump bss entries to past image end (r10)
>> */
>> + sub r5, r10, r6 @ delta of image end and _edata
>> + add r5, r5, #7 @ ... rounded up to a multiple
>> + bic r5, r5, #7 @ ... of 8 bytes, so misaligned
>> + @ ... GOT entry doesn't
>> + @ ... overwrite end of image
>
> This is wrong. You are going to displace the .bss pointers even if they
> don't need that in the case where no dtb was found. And if a dtb was
> found the displacement is going to be the size of the dtb _plus_ the
> size of the .bss_stack instead of only the dtb size.
>
> At this point you should only keep track of the .bss displacement in
> addition to the delta offset in r0. And if both are equal to zero then
> skip over the fixup loop as before.
Maybe I'm not understanding correctly. I think that if there is an
appended dtb, then there are sections like the code and data that needs
to be adjusted by the old r0 value, while the bss and the stack need to
be adjusted by the old r0 + dtb size.
If my understanding is right, then we can't just add the dtb size to r0
and adjust everything.
Am I missing something?
>
>> 1: ldr r1, [r11, #0] @ relocate entries in the GOT
>> add r1, r1, r0 @ table. This fixes up the
>> + cmp r1, r2
>> + movcc r9, #0 @ r9 = entry < bss_start ? 0 :
>> + movcs r9, #1 @ 1;
>> + cmp r1, r3
>> + movcs r9, #0 @ r9 = entry >= end ? 0 : t1;
>> + cmp r9, #0
>> + addne r1, r5 @ entry += r9 ? bss delta : 0;
>
> The above would be much more elegant if written like this:
>
> cmp r1, r2
> cmphs r3, r1
> addhi r1, r5
>
>> str r1, [r11], #4 @ C references.
>> cmp r11, r12
>> blo 1b
>> +
>> + /* bump our bss registers too */
>> + add r2, r2, r5
>> + add r3, r3, r5
>> +
>> + /* bump the stack pinter, if at or above _edata */
>> + cmp sp, r6
>> + addcs sp, sp, r5
>
> This will always be true as this is within #ifndef CONFIG_ZBOOT_ROM.
>
>> #else
>>
>> /*
>> @@ -309,7 +373,7 @@ wont_overwrite:
>> blo 1b
>> #endif
>>
>> -not_relocated: mov r0, #0
>> + mov r0, #0
>> 1: str r0, [r2], #4 @ clear bss
>> str r0, [r2], #4
>> str r0, [r2], #4
>> @@ -317,8 +381,25 @@ not_relocated: mov r0, #0
>> cmp r2, r3
>> blo 1b
>>
>> +#ifdef CONFIG_ARM_APPENDED_DTB
>> +/*
>> + * The C runtime environment should now be set up sufficiently.
>> + * r4 = kernel execution address
>> + * r6 = _edata
>> + * r7 = architecture ID
>> + * r8 = atags pointer
>> + *
>> + * if there is a device tree (dtb) appended to zImage, set up to use this dtb.
>> + */
>> + ldr r0, [r6, #0]
>> + ldr r1, =0xedfe0dd0 @ sig is 0xdoodfeed big endian
>> + cmp r0, r1
>> + bne keep_atags
>> +
>> + mov r8, r6 @ use the appended device tree
>
> You should have updated r8 the moment you knew you have a valid dtb
> earlier instead of duplicating this test here.
>
>> +keep_atags:
>> +#endif
>> /*
>> - * The C runtime environment should now be setup sufficiently.
>> * Set up some pointers, and start decompressing.
>> * r4 = kernel execution address
>> * r7 = architecture ID
>>
^ permalink raw reply
* [PATCHv5 0/3] Introduce the /proc/socinfo and use it to export OMAP data
From: Ryan Mallon @ 2011-03-02 1:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4D6D9FC7.1090206@codeaurora.org>
On 03/02/2011 02:39 PM, Saravana Kannan wrote:
> On 03/01/2011 05:27 PM, Ryan Mallon wrote:
>> On 03/02/2011 02:19 PM, Saravana Kannan wrote:
>>> On 03/01/2011 05:13 PM, Andrei Warkentin wrote:
>>>> On Mon, Feb 28, 2011 at 10:51 PM, Saravana Kannan
>>>> <skannan@codeaurora.org> wrote:
>>
>> <snip>
>>
>>>> What would an "arch" file mean? The name of the soc platform?
>>>
>>> The arch file would pretty much be the "xxxx" from arch/arm/mach-xxxx or
>>> similar paths. If that info is already available elsewhere, then that
>>> file is not needed. I proposed using the arch since that will remove the
>>> need to maintain some database of unique/reserved names/numbers for each
>>> implementation of socinfo (like the machinetypes list we have).
>>
>> /proc/cpuinfo already tells you what the CPU is, which gives more
>> information than just the architecture name.
>>
>> Why is the arch information even required by userspace?
>
> The socinfo exported by each soc is different. If userspace is trying to
> make decisions based on socinfo, it will need to know what type of soc
> (really what type of socinfo implementation) it is before trying to
> interpret the rest of the socinfo files. Keep in mind that cpuinfo is
> different from socinfo -- the cpu is just a small part of a soc.
I understand that having a socinfo file for obtaining information about
a particular SoC would be useful. A similar discussion came up a few
years ago when we talked about having a socinfo file for exposing the
ep93xx Maverick crunch id, but nothing ever came out of it.
What I don't understand is why you want the 'arch' file (ie the
mach-xxxx) name. /proc/cpuinfo already gives you more information than
an 'arch' file would. I also can't think of a particularly good
situation why userspace would need to know at runtime what the
architecture is.
Have a socinfo file to expose implementation details of the particular
SoC I am fine with (assuming those details are useful to userspace),
having an 'arch' file to expose the architecture I am against.
~Ryan
--
Bluewater Systems Ltd - ARM Technology Solution Centre
Ryan Mallon 5 Amuri Park, 404 Barbadoes St
ryan at bluewatersys.com PO Box 13 889, Christchurch 8013
http://www.bluewatersys.com New Zealand
Phone: +64 3 3779127 Freecall: Australia 1800 148 751
Fax: +64 3 3779135 USA 1800 261 2934
^ permalink raw reply
* [PATCH 1/4] ARM:boot:device tree: Allow the device tree binary to be appended to zImage
From: John Bonesio @ 2011-03-02 1:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.00.1103010019160.10356@xanadu.home>
I have looked through, and I'm reworking the patch set. I have just one
comment below.
- John
On 02/28/2011 10:39 PM, Nicolas Pitre wrote:
> On Mon, 28 Feb 2011, John Bonesio wrote:
>
>> This patch provides the ability to boot using a device tree that is appended
>> to the raw binary zImage (e.g. cat zImage <filename>.dtb > zImage_w_dtb).
>>
>> Signed-off-by: John Bonesio <bones@secretlab.ca>
>
> Comments below.
>
>> ---
>>
>> arch/arm/Kconfig | 7 +++
>> arch/arm/boot/compressed/head.S | 93 ++++++++++++++++++++++++++++++++++++---
>> 2 files changed, 94 insertions(+), 6 deletions(-)
>>
>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
>> index d8a330f..68fc640 100644
>> --- a/arch/arm/Kconfig
>> +++ b/arch/arm/Kconfig
>> @@ -1593,6 +1593,13 @@ config USE_OF
>> help
>> Include support for flattened device tree machine descriptions.
>>
>> +config ARM_APPENDED_DTB
>> + bool "Use appended device tree blob" if OF
>> + default n
>
> The default is n by default, so you don't need to mention it.
>
> Also this should depend on OF (CONFIG_OF).
>
>> + help
>> + With this option, the boot code will look for a dtb bianry
>
> s/bianry/binary/
>
> Since this is an help text for people who might not have a clue about
> "dtb", it would be better to spell it out.
>
>> + appended to zImage.
>> +
>> # Compressed boot loader in ROM. Yes, we really want to ask about
>> # TEXT and BSS so we preserve their values in the config files.
>> config ZBOOT_ROM_TEXT
>> diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
>> index 200625c..ae9f8c6 100644
>> --- a/arch/arm/boot/compressed/head.S
>> +++ b/arch/arm/boot/compressed/head.S
>> @@ -210,6 +210,46 @@ restart: adr r0, LC0
>> */
>> mov r10, r6
>> #endif
>> +#ifdef CONFIG_ARM_APPENDED_DTB
>> +/*
>> + * r0 = delta
>> + * r2 = BSS start
>> + * r3 = BSS end
>> + * r4 = final kernel address
>> + * r5 = start of this image
>> + * r6 = _edata
>> + * r7 = architecture ID
>> + * r8 = atags/device tree pointer
>> + * r9 = size of decompressed image
>> + * r10 = end of this image, including bss/stack/malloc space if non XIP
>> + * r11 = GOT start
>> + * r12 = GOT end
>> + *
>> + * if there are device trees (dtb) appended to zImage, advance r10 so that the
>> + * dtb data will get relocated along with the kernel if necessary.
>> + */
>> +
>> + ldr r12, [r6, #0]
>> + ldr r1, =0xedfe0dd0 @ sig is 0xdoodfeed big endian
>> + cmp r12, r1
>> + bne dtb_check_done
>> +
>> + /* Get the dtb's size */
>> + ldr r12, [r6, #4] @ device tree size
>> +
>> + /* convert r12 (dtb size) to little endian */
>> + eor r1, r12, r12, ror #16
>> + bic r1, r1, #0x00ff0000
>> + mov r12, r12, ror #8
>> + eor r12, r12, r1, lsr #8
>> +
>> + add r10, r10, r12
>> + add r6, r6, r12
>> +
>> +dtb_check_done:
>> + adr r1, LC0
>> + ldr r12, [r1, #28] @ restore r12 (GOT end)
>> +#endif
>
> Instead of clobbering r12, you could use lr instead.
>
> The byte swap on the size should be done only if __ARMEB__ is not
> defined i.e. #ifndef __ARMEB__ ...
>
> Also the DT signature should be endian aware.
>
>> /*
>> * Check to see if we will overwrite ourselves.
>> @@ -223,8 +263,8 @@ restart: adr r0, LC0
>> */
>> cmp r4, r10
>> bhs wont_overwrite
>> - add r10, r4, r9
>> - cmp r10, r5
>> + add r1, r4, r9
>> + cmp r1, r5
>> bls wont_overwrite
>>
>> /*
>> @@ -272,8 +312,10 @@ wont_overwrite:
>> * r12 = GOT end
>> * sp = stack pointer
>> */
>> - teq r0, #0
>> - beq not_relocated
>> + adr r1, LC0
>> + ldr r6, [r1, #16] @ reload _edata value
>
> Why?
>
>> +
>> + add r6, r6, r0
>> add r11, r11, r0
>> add r12, r12, r0
>>
>> @@ -288,12 +330,34 @@ wont_overwrite:
>>
>> /*
>> * Relocate all entries in the GOT table.
>> + * Bump bss entries to past image end (r10)
>> */
>> + sub r5, r10, r6 @ delta of image end and _edata
>> + add r5, r5, #7 @ ... rounded up to a multiple
>> + bic r5, r5, #7 @ ... of 8 bytes, so misaligned
>> + @ ... GOT entry doesn't
>> + @ ... overwrite end of image
>
> This is wrong. You are going to displace the .bss pointers even if they
> don't need that in the case where no dtb was found. And if a dtb was
> found the displacement is going to be the size of the dtb _plus_ the
> size of the .bss_stack instead of only the dtb size.
>
> At this point you should only keep track of the .bss displacement in
> addition to the delta offset in r0. And if both are equal to zero then
> skip over the fixup loop as before.
>
>> 1: ldr r1, [r11, #0] @ relocate entries in the GOT
>> add r1, r1, r0 @ table. This fixes up the
>> + cmp r1, r2
>> + movcc r9, #0 @ r9 = entry < bss_start ? 0 :
>> + movcs r9, #1 @ 1;
>> + cmp r1, r3
>> + movcs r9, #0 @ r9 = entry >= end ? 0 : t1;
>> + cmp r9, #0
>> + addne r1, r5 @ entry += r9 ? bss delta : 0;
>
> The above would be much more elegant if written like this:
>
> cmp r1, r2
> cmphs r3, r1
> addhi r1, r5
>
>> str r1, [r11], #4 @ C references.
>> cmp r11, r12
>> blo 1b
>> +
>> + /* bump our bss registers too */
>> + add r2, r2, r5
>> + add r3, r3, r5
>> +
>> + /* bump the stack pinter, if at or above _edata */
>> + cmp sp, r6
>> + addcs sp, sp, r5
>
> This will always be true as this is within #ifndef CONFIG_ZBOOT_ROM.
Right now sp will always be above r6. I thought it might be prudent to
add the test in case the linker script changed and the stack was placed
elsewhere. It might save someone a headache later.
>
>> #else
>>
>> /*
>> @@ -309,7 +373,7 @@ wont_overwrite:
>> blo 1b
>> #endif
>>
>> -not_relocated: mov r0, #0
>> + mov r0, #0
>> 1: str r0, [r2], #4 @ clear bss
>> str r0, [r2], #4
>> str r0, [r2], #4
>> @@ -317,8 +381,25 @@ not_relocated: mov r0, #0
>> cmp r2, r3
>> blo 1b
>>
>> +#ifdef CONFIG_ARM_APPENDED_DTB
>> +/*
>> + * The C runtime environment should now be set up sufficiently.
>> + * r4 = kernel execution address
>> + * r6 = _edata
>> + * r7 = architecture ID
>> + * r8 = atags pointer
>> + *
>> + * if there is a device tree (dtb) appended to zImage, set up to use this dtb.
>> + */
>> + ldr r0, [r6, #0]
>> + ldr r1, =0xedfe0dd0 @ sig is 0xdoodfeed big endian
>> + cmp r0, r1
>> + bne keep_atags
>> +
>> + mov r8, r6 @ use the appended device tree
>
> You should have updated r8 the moment you knew you have a valid dtb
> earlier instead of duplicating this test here.
>
>> +keep_atags:
>> +#endif
>> /*
>> - * The C runtime environment should now be setup sufficiently.
>> * Set up some pointers, and start decompressing.
>> * r4 = kernel execution address
>> * r7 = architecture ID
>>
^ permalink raw reply
* [PATCHv5 0/3] Introduce the /proc/socinfo and use it to export OMAP data
From: Saravana Kannan @ 2011-03-02 1:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4D6D9D06.2020204@bluewatersys.com>
On 03/01/2011 05:27 PM, Ryan Mallon wrote:
> On 03/02/2011 02:19 PM, Saravana Kannan wrote:
>> On 03/01/2011 05:13 PM, Andrei Warkentin wrote:
>>> On Mon, Feb 28, 2011 at 10:51 PM, Saravana Kannan
>>> <skannan@codeaurora.org> wrote:
>
> <snip>
>
>>> What would an "arch" file mean? The name of the soc platform?
>>
>> The arch file would pretty much be the "xxxx" from arch/arm/mach-xxxx or
>> similar paths. If that info is already available elsewhere, then that
>> file is not needed. I proposed using the arch since that will remove the
>> need to maintain some database of unique/reserved names/numbers for each
>> implementation of socinfo (like the machinetypes list we have).
>
> /proc/cpuinfo already tells you what the CPU is, which gives more
> information than just the architecture name.
>
> Why is the arch information even required by userspace?
The socinfo exported by each soc is different. If userspace is trying to
make decisions based on socinfo, it will need to know what type of soc
(really what type of socinfo implementation) it is before trying to
interpret the rest of the socinfo files. Keep in mind that cpuinfo is
different from socinfo -- the cpu is just a small part of a soc.
Thanks,
Saravana
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply
* [PATCHv5 0/3] Introduce the /proc/socinfo and use it to export OMAP data
From: Ryan Mallon @ 2011-03-02 1:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4D6D9B10.9000606@codeaurora.org>
On 03/02/2011 02:19 PM, Saravana Kannan wrote:
> On 03/01/2011 05:13 PM, Andrei Warkentin wrote:
>> On Mon, Feb 28, 2011 at 10:51 PM, Saravana Kannan
>> <skannan@codeaurora.org> wrote:
<snip>
>> What would an "arch" file mean? The name of the soc platform?
>
> The arch file would pretty much be the "xxxx" from arch/arm/mach-xxxx or
> similar paths. If that info is already available elsewhere, then that
> file is not needed. I proposed using the arch since that will remove the
> need to maintain some database of unique/reserved names/numbers for each
> implementation of socinfo (like the machinetypes list we have).
/proc/cpuinfo already tells you what the CPU is, which gives more
information than just the architecture name.
Why is the arch information even required by userspace?
~Ryan
--
Bluewater Systems Ltd - ARM Technology Solution Centre
Ryan Mallon 5 Amuri Park, 404 Barbadoes St
ryan at bluewatersys.com PO Box 13 889, Christchurch 8013
http://www.bluewatersys.com New Zealand
Phone: +64 3 3779127 Freecall: Australia 1800 148 751
Fax: +64 3 3779135 USA 1800 261 2934
^ permalink raw reply
* Store buffer and l2x0_cache_sync
From: Colin Cross @ 2011-03-02 1:25 UTC (permalink / raw)
To: linux-arm-kernel
l2x0_cache_sync on a PL310 has no wait after the writel_relaxed to the
L2X0_CACHE_SYNC register, because PL310 cache operations are atomic.
Doesn't the cpu store buffer still need to be flushed after the
register write, either with a dsb or a dummy read?
^ permalink raw reply
* CONFIG_ARM_DMA_MEM_BUFFERABLE and readl/writel weirdness
From: Saravana Kannan @ 2011-03-02 1:23 UTC (permalink / raw)
To: linux-arm-kernel
Russell, Catalin,
In arch/arm/include/asm/io.h, we have the following piece of code:
#ifdef CONFIG_ARM_DMA_MEM_BUFFERABLE
#define __iormb() rmb()
#define __iowmb() wmb()
#else
#define __iormb() do { } while (0)
#define __iowmb() do { } while (0)
#endif
#define readb(c) ({ u8 __v = readb_relaxed(c);
__iormb(); __v; })
#define readw(c) ({ u16 __v = readw_relaxed(c);
__iormb(); __v; })
#define readl(c) ({ u32 __v = readl_relaxed(c);
__iormb(); __v; })
#define writeb(v,c) ({ __iowmb(); writeb_relaxed(v,c); })
#define writew(v,c) ({ __iowmb(); writew_relaxed(v,c); })
#define writel(v,c) ({ __iowmb(); writel_relaxed(v,c); })
If I'm not missing some magic, this would mean that
"CONFIG_ARM_DMA_MEM_BUFFERABLE" determines if readl(s)/writel(s) get to
have a built in mb() or not.
The rest of the emails is under the assumption that my statement above
is true.
This seems like a real bad thing to do.
There are so many other drivers that don't use or care about DMA and
might still want to ensure some ordering constraints between their
readl(s)/writel(s). They can't depend on readl/writel taking care of it
for them since their code could be used in a kernel configuration that
doesn't enable this config.
Firstly, I don't know how many people noticed this and realize they
can't depend on readl/writel to take care of the mb()s for them. Seems
like an unnecessary encouragement to make mistakes when it didn't need
to be so.
Secondly, even if they realize they have to take care of it, they will
have to continue using mb()s in to force ordering between their
reads/writes. So, are we depending on the compiler to optimize these
extra mb() out in the case where the config is enabled? I'm not sure it
will be able to optimize out the extra mb()s in all cases.
Please let me know if I'm missing something and there is a good reason
for writing the code as it is today. If there is not much of a reason
for this, do you have any objections if I send a patch to split out the
"readl/writel with built in mb()" as a separate config and 'select'ing
it in ARM_DMA_MEM_BUFFERABLE?
Thanks,
Saravana
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply
* [PATCH V4 1/4] ARM: imx53_loco: add esdhc device support
From: Fabio Estevam @ 2011-03-02 1:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1298973500-2858-1-git-send-email-Hong-Xing.Zhu@freescale.com>
On Tue, Mar 1, 2011 at 6:58 AM, Richard Zhu <Hong-Xing.Zhu@freescale.com> wrote:
> Signed-off-by: Richard Zhao <richard.zhao@freescale.com>
> Acked-by: Wolfram Sang <w.sang@pengutronix.de>
> ---
> ?arch/arm/mach-mx5/Kconfig ? ? ? ? ? | ? ?1 +
> ?arch/arm/mach-mx5/board-mx53_loco.c | ? ?2 ++
> ?2 files changed, 3 insertions(+), 0 deletions(-)
I thought you were going to put this patch as the last of the series.
It is strange to add support for the board first and add the support
for the MX53 later.
Regards,
Fabio Estevam
^ permalink raw reply
* [PATCHv5 0/3] Introduce the /proc/socinfo and use it to export OMAP data
From: Saravana Kannan @ 2011-03-02 1:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTikvhj49DftS9c_NouASY9_MbYPCfmSUdJg6pf-5@mail.gmail.com>
On 03/01/2011 05:13 PM, Andrei Warkentin wrote:
> On Mon, Feb 28, 2011 at 10:51 PM, Saravana Kannan
> <skannan@codeaurora.org> wrote:
>> On 02/28/2011 02:28 AM, Maxime Coquelin wrote:
>>>
>>> Hello Eduardo,
>>>
>>> On 02/16/2011 12:57 PM, Eduardo Valentin wrote:
>>>>>
>>>>> Eduardo, what has happened to this patchset?
>>>>
>>>> Got forgotten :-(. Unfortunately I didn't pushed it hard enough.
>>>
>>> I propose to refactor your patchset, moving from procfs to sysfs.
>>
>>>>> Do you want help in picking it up and try to polish it up?
>>>>
>>>> Yeah, but it would need a refactoring. IIRC, result of last discussion
>>>> was that we should not mess with /proc. So, maybe moving back
>>
>>>> to something under sysfs. Perhaps /sys/devices/soc or so?
>>>
>>> About the location of this new sysfs entry, where do you think it should
>>> be?
>>> I propose to create a new directory named "soc" in /sys/devices/system/.
>>>
>>> As platform vendors have several/different kind of IDs to export to
>>> sysfs, I propose each vendor to create file entries related to their IDs
>>> (eg. /sys/devices/system/soc/idcode for OMAP platforms).
>>
>> I think the path /sys/devices/system/soc/ will work for the MSM too. I would
>> have ideally liked it to be /sys/devices/system/soc/msm,
>> /sys/devices/system/soc/omap, etc, but we can't get to pick names for
>> devices under a class. So, we can make do with /sys/devices/system/soc/.
>>
>>> However, I think we should have a common file entry to export the unique
>>> ID of the platforms. Indeed, user-space applications should have a
>>> unified way to get this kind of ID, regardless of the platform (eg.
>>> /sys/devices/system/soc/unique_id).
>>
>> I like the idea of have a common file across all implementations that will
>> let user space identify what implementation is exporting the other files and
>> how to interpret them.
>>
>> I would like to propose an "arch" file to identify the arch the soc info
>> file are for. I'm guessing within an arch, the soc files would mostly be the
>> same? If there are other minor differences, we can let the arch specific
>> code deal with how the files are interpreted.
>>
>> Does "arch" work for everyone?
>>
>
> Sorry to butt in, but what kind of info are you guys talking about?
Please do butt in :-), that's what a community discussion is for.
> Like SOC revision, serial numbers, etc...?
Like SOC type (to identify different chipsets), revision, etc.
> What would an "arch" file mean? The name of the soc platform?
The arch file would pretty much be the "xxxx" from arch/arm/mach-xxxx or
similar paths. If that info is already available elsewhere, then that
file is not needed. I proposed using the arch since that will remove the
need to maintain some database of unique/reserved names/numbers for each
implementation of socinfo (like the machinetypes list we have).
-Saravana
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply
* [PATCH] ARM: EXYNOS4: enabled lcd and backlight in NURI board
From: Donghwa Lee @ 2011-03-02 1:17 UTC (permalink / raw)
To: linux-arm-kernel
This patch enables lcd and backlight drivers in NURI board.
Signed-off-by: Donghwa Lee <dh09.lee@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
------
arch/arm/configs/exynos4_nuri_defconfig | 9 +++-
arch/arm/mach-exynos4/Kconfig | 1 +
arch/arm/mach-exynos4/mach-nuri.c | 62 +++++++++++++++++++++++++++++++
3 files changed, 70 insertions(+), 2 deletions(-)
diff --git a/arch/arm/configs/exynos4_nuri_defconfig b/arch/arm/configs/exynos4_nuri_defconfig
index 5f03027..e2f0bfb 100644
--- a/arch/arm/configs/exynos4_nuri_defconfig
+++ b/arch/arm/configs/exynos4_nuri_defconfig
@@ -786,8 +786,13 @@ CONFIG_REGULATOR=y
# CONFIG_DRM is not set
# CONFIG_VGASTATE is not set
# CONFIG_VIDEO_OUTPUT_CONTROL is not set
-# CONFIG_FB is not set
-# CONFIG_BACKLIGHT_LCD_SUPPORT is not set
+CONFIG_FB=y
+CONFIG_FB_S3C=y
+CONFIG_LCD_CLASS_DEVICE=y
+CONFIG_LCD_PLATFORM=y
+CONFIG_BACKLIGHT_CLASS_DEVICE=y
+CONFIG_BACKLIGHT_LCD_SUPPORT=y
+CONFIG_BACKLIGHT_PWM=y
#
# Display device support
diff --git a/arch/arm/mach-exynos4/Kconfig b/arch/arm/mach-exynos4/Kconfig
index 5bf00b9..1d0d222 100644
--- a/arch/arm/mach-exynos4/Kconfig
+++ b/arch/arm/mach-exynos4/Kconfig
@@ -135,6 +135,7 @@ config MACH_NURI
select EXYNOS4_SETUP_I2C1
select EXYNOS4_SETUP_I2C5
select EXYNOS4_SETUP_SDHCI
+ select HAVE_PWM
help
Machine support for Samsung Mobile NURI Board.
diff --git a/arch/arm/mach-exynos4/mach-nuri.c b/arch/arm/mach-exynos4/mach-nuri.c
index 28010bd..d06cc91 100644
--- a/arch/arm/mach-exynos4/mach-nuri.c
+++ b/arch/arm/mach-exynos4/mach-nuri.c
@@ -17,6 +17,10 @@
#include <linux/regulator/machine.h>
#include <linux/regulator/fixed.h>
#include <linux/mmc/host.h>
+#include <linux/fb.h>
+#include <linux/pwm_backlight.h>
+
+#include <video/platform_lcd.h>
#include <asm/mach/arch.h>
#include <asm/mach-types.h>
@@ -26,6 +30,8 @@
#include <plat/cpu.h>
#include <plat/devs.h>
#include <plat/sdhci.h>
+#include <plat/fb.h>
+#include <plat/regs-fb.h>
#include <mach/map.h>
@@ -181,6 +187,60 @@ static struct platform_device nuri_gpio_keys = {
},
};
+static int lcd_power_on(struct lcd_device *ld, int enable)
+{
+ int gpio = EXYNOS4_GPE1(5);
+
+ gpio_request(gpio, "LVDS_nSHDN");
+
+ if (enable)
+ gpio_direction_output(gpio, 1);
+ else
+ gpio_direction_output(gpio, 0);
+
+ return 0;
+}
+
+static int backlight_init(struct device *dev)
+{
+ return 0;
+}
+
+/* nuri pwm backlight */
+static struct platform_pwm_backlight_data nuri_backlight_data = {
+ .pwm_id = 0,
+ .pwm_period_ns = 30000,
+ .max_brightness = 100,
+ .dft_brightness = 50,
+ .init = backlight_init,
+};
+
+static struct platform_device nuri_backlight_device = {
+ .name = "pwm-backlight",
+ .id = -1,
+ .dev = {
+ .platform_data = &nuri_backlight_data,
+ },
+};
+
+static struct plat_lcd_data nuri_lcd_platform_data = {
+ .set_power = lcd_power_on,
+};
+
+static struct platform_device nuri_lcd_device = {
+ .name = "platform-lcd",
+ .id = -1,
+ .dev = {
+ .platform_data = (void *) &nuri_lcd_platform_data,
+ },
+};
+
+static void __init nuri_fb_init(void)
+{
+ platform_device_register(&nuri_lcd_device);
+ platform_device_register(&nuri_backlight_device);
+}
+
/* I2C1 */
static struct i2c_board_info i2c1_devs[] __initdata = {
/* Gyro, To be updated */
@@ -201,6 +261,7 @@ static struct platform_device *nuri_devices[] __initdata = {
&s3c_device_wdt,
#endif
+ &s3c_device_timer[0],
/* NURI Devices */
&nuri_gpio_keys,
};
@@ -219,6 +280,7 @@ static void __init nuri_machine_init(void)
i2c_register_board_info(1, i2c1_devs, ARRAY_SIZE(i2c1_devs));
i2c_register_board_info(5, i2c5_devs, ARRAY_SIZE(i2c5_devs));
+ nuri_fb_init();
/* Last */
platform_add_devices(nuri_devices, ARRAY_SIZE(nuri_devices));
}
--
1.6.0.4
^ permalink raw reply related
* [PATCH] ARM: imx/mx25_3ds: Fix build failure
From: Fabio Estevam @ 2011-03-02 1:15 UTC (permalink / raw)
To: linux-arm-kernel
Commit
ca8d906 (ARM: mach-imx: mx25_3ds: add write-protect and card-detect for SD)
assigned a non-existing member .cd_gpio in a struct esdhc_platform_data.
This field can be added later after the esdhc patches are merged.
Fix the build for now.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
---
arch/arm/mach-imx/mach-mx25_3ds.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-imx/mach-mx25_3ds.c b/arch/arm/mach-imx/mach-mx25_3ds.c
index 561f07f..11c25f9 100644
--- a/arch/arm/mach-imx/mach-mx25_3ds.c
+++ b/arch/arm/mach-imx/mach-mx25_3ds.c
@@ -208,7 +208,6 @@ static const struct fsl_usb2_platform_data otg_device_pdata __initconst = {
static const struct esdhc_platform_data mx25pdk_esdhc_pdata __initconst = {
.wp_gpio = SD1_GPIO_WP,
- .cd_gpio = SD1_GPIO_CD,
};
static void __init mx25pdk_init(void)
--
1.6.0.4
^ permalink raw reply related
* [PATCHv5 0/3] Introduce the /proc/socinfo and use it to export OMAP data
From: Andrei Warkentin @ 2011-03-02 1:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4D6C7B56.9060109@codeaurora.org>
On Mon, Feb 28, 2011 at 10:51 PM, Saravana Kannan
<skannan@codeaurora.org> wrote:
> On 02/28/2011 02:28 AM, Maxime Coquelin wrote:
>>
>> Hello Eduardo,
>>
>> On 02/16/2011 12:57 PM, Eduardo Valentin wrote:
>>>>
>>>> Eduardo, what has happened to this patchset?
>>>
>>> Got forgotten :-(. Unfortunately I didn't pushed it hard enough.
>>
>> I propose to refactor your patchset, moving from procfs to sysfs.
>
>>>> Do you want help in picking it up and try to polish it up?
>>>
>>> Yeah, but it would need a refactoring. IIRC, result of last discussion
>>> was that we should not mess with /proc. So, maybe moving back
>
>>> to something under sysfs. Perhaps /sys/devices/soc or so?
>>
>> About the location of this new sysfs entry, where do you think it should
>> be?
>> I propose to create a new directory named "soc" in /sys/devices/system/.
>>
>> As platform vendors have several/different kind of IDs to export to
>> sysfs, I propose each vendor to create file entries related to their IDs
>> (eg. /sys/devices/system/soc/idcode for OMAP platforms).
>
> I think the path /sys/devices/system/soc/ will work for the MSM too. I would
> have ideally liked it to be /sys/devices/system/soc/msm,
> /sys/devices/system/soc/omap, etc, but we can't get to pick names for
> devices under a class. So, we can make do with /sys/devices/system/soc/.
>
>> However, I think we should have a common file entry to export the unique
>> ID of the platforms. Indeed, user-space applications should have a
>> unified way to get this kind of ID, regardless of the platform (eg.
>> /sys/devices/system/soc/unique_id).
>
> I like the idea of have a common file across all implementations that will
> let user space identify what implementation is exporting the other files and
> how to interpret them.
>
> I would like to propose an "arch" file to identify the arch the soc info
> file are for. I'm guessing within an arch, the soc files would mostly be the
> same? If there are other minor differences, we can let the arch specific
> code deal with how the files are interpreted.
>
> Does "arch" work for everyone?
>
Sorry to butt in, but what kind of info are you guys talking about?
Like SOC revision, serial numbers, etc...?
What would an "arch" file mean? The name of the soc platform?
^ permalink raw reply
* [PATCH 3/6] i2c-pxa2xx: Add PCI support for PXA I2C controller
From: Ben Dooks @ 2011-03-02 0:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1298461100-14869-4-git-send-email-bigeasy@linutronix.de>
On 23/02/11 11:38, Sebastian Andrzej Siewior wrote:
> The Sodaville I2C controller is almost the same as found on PXA2xx. The
> difference:
> - the register are at a different offset
> - no slave support
>
> The PCI probe code adds three platform devices which are probed then by
> the platform code.
> The X86 part also adds dummy clock defines because we don't have HW
> clock support.
>
> Signed-off-by: Sebastian Andrzej Siewior<bigeasy@linutronix.de>
> Signed-off-by: Dirk Brandewie<dirk.brandewie@gmail.com>
> ---
> drivers/i2c/busses/Kconfig | 7 +-
> drivers/i2c/busses/Makefile | 1 +
> drivers/i2c/busses/i2c-pxa-pci.c | 176 ++++++++++++++++++++++++++++++++++++++
> drivers/i2c/busses/i2c-pxa.c | 27 +++++-
> 4 files changed, 206 insertions(+), 5 deletions(-)
> create mode 100644 drivers/i2c/busses/i2c-pxa-pci.c
>
> diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
> index 113505a..deefa13 100644
> --- a/drivers/i2c/busses/Kconfig
> +++ b/drivers/i2c/busses/Kconfig
> @@ -525,15 +525,18 @@ config I2C_PNX
>
> config I2C_PXA
> tristate "Intel PXA2XX I2C adapter"
> - depends on ARCH_PXA || ARCH_MMP
> + depends on ARCH_PXA || ARCH_MMP || (X86_32&& PCI&& OF)
> help
> If you have devices in the PXA I2C bus, say yes to this option.
> This driver can also be built as a module. If so, the module
> will be called i2c-pxa.
>
> +config I2C_PXA_PCI
> + def_bool I2C_PXA&& X86_32&& PCI&& OF
> +
> config I2C_PXA_SLAVE
> bool "Intel PXA2XX I2C Slave comms support"
> - depends on I2C_PXA
> + depends on I2C_PXA&& !X86_32
> help
> Support I2C slave mode communications on the PXA I2C bus. This
> is necessary for systems where the PXA may be a target on the
> diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
> index 9d2d0ec..e95d0bf 100644
> --- a/drivers/i2c/busses/Makefile
> +++ b/drivers/i2c/busses/Makefile
> @@ -52,6 +52,7 @@ obj-$(CONFIG_I2C_PCA_PLATFORM) += i2c-pca-platform.o
> obj-$(CONFIG_I2C_PMCMSP) += i2c-pmcmsp.o
> obj-$(CONFIG_I2C_PNX) += i2c-pnx.o
> obj-$(CONFIG_I2C_PXA) += i2c-pxa.o
> +obj-$(CONFIG_I2C_PXA_PCI) += i2c-pxa-pci.o
> obj-$(CONFIG_I2C_S3C2410) += i2c-s3c2410.o
> obj-$(CONFIG_I2C_S6000) += i2c-s6000.o
> obj-$(CONFIG_I2C_SH7760) += i2c-sh7760.o
> diff --git a/drivers/i2c/busses/i2c-pxa-pci.c b/drivers/i2c/busses/i2c-pxa-pci.c
> new file mode 100644
> index 0000000..6659d26
> --- /dev/null
> +++ b/drivers/i2c/busses/i2c-pxa-pci.c
> @@ -0,0 +1,176 @@
> +/*
> + * The CE4100's I2C device is more or less the same one as found on PXA.
> + * It does not support slave mode, the register slightly moved. This PCI
> + * device provides three bars, every contains a single I2C controller.
> + */
> +#include<linux/pci.h>
> +#include<linux/platform_device.h>
> +#include<linux/i2c/pxa-i2c.h>
> +#include<linux/of.h>
> +#include<linux/of_device.h>
> +#include<linux/of_address.h>
> +
> +#define CE4100_PCI_I2C_DEVS 3
> +
> +struct ce4100_devices {
> + struct platform_device *pdev[CE4100_PCI_I2C_DEVS];
> +};
> +
> +static struct platform_device *add_i2c_device(struct pci_dev *dev, int bar)
> +{
> + struct platform_device *pdev;
> + struct i2c_pxa_platform_data pdata;
> + struct resource res[2];
> + struct device_node *child;
> + static int devnum;
> + int ret;
> +
> + memset(&pdata, 0, sizeof(struct i2c_pxa_platform_data));
> + memset(&res, 0, sizeof(res));
> +
> + res[0].flags = IORESOURCE_MEM;
> + res[0].start = pci_resource_start(dev, bar);
> + res[0].end = pci_resource_end(dev, bar);
> +
> + res[1].flags = IORESOURCE_IRQ;
> + res[1].start = dev->irq;
> + res[1].end = dev->irq;
> +
> + for_each_child_of_node(dev->dev.of_node, child) {
> + const void *prop;
> + struct resource r;
> + int ret;
> +
> + ret = of_address_to_resource(child, 0,&r);
> + if (ret< 0)
> + continue;
> + if (r.start != res[0].start)
> + continue;
> + if (r.end != res[0].end)
> + continue;
> + if (r.flags != res[0].flags)
> + continue;
> +
> + prop = of_get_property(child, "fast-mode", NULL);
> + if (prop)
> + pdata.fast_mode = 1;
> +
> + break;
> + }
> +
> + if (!child) {
> + dev_err(&dev->dev, "failed to match a DT node for bar %d.\n",
> + bar);
> + ret = -EINVAL;
> + goto out;
> + }
> +
> + pdev = platform_device_alloc("ce4100-i2c", devnum);
> + if (!pdev) {
> + of_node_put(child);
> + ret = -ENOMEM;
> + goto out;
> + }
> + pdev->dev.parent =&dev->dev;
> + pdev->dev.of_node = child;
> +
> + ret = platform_device_add_resources(pdev, res, ARRAY_SIZE(res));
> + if (ret)
> + goto err;
> +
> + ret = platform_device_add_data(pdev,&pdata, sizeof(pdata));
> + if (ret)
> + goto err;
> +
> + ret = platform_device_add(pdev);
> + if (ret)
> + goto err;
> + devnum++;
> + return pdev;
> +err:
> + platform_device_put(pdev);
> +out:
> + return ERR_PTR(ret);
> +}
> +
> +static int __devinit ce4100_i2c_probe(struct pci_dev *dev,
> + const struct pci_device_id *ent)
> +{
> + int ret;
> + int i;
> + struct ce4100_devices *sds;
> +
> + ret = pci_enable_device_mem(dev);
> + if (ret)
> + return ret;
> +
> + if (!dev->dev.of_node) {
> + dev_err(&dev->dev, "Missing device tree node.\n");
> + return -EINVAL;
> + }
> + sds = kzalloc(sizeof(*sds), GFP_KERNEL);
> + if (!sds)
> + goto err_mem;
> +
> + for (i = 0; i< ARRAY_SIZE(sds->pdev); i++) {
> + sds->pdev[i] = add_i2c_device(dev, i);
> + if (IS_ERR(sds->pdev[i])) {
> + while (--i>= 0)
> + platform_device_unregister(sds->pdev[i]);
> + goto err_dev_add;
> + }
> + }
> + pci_set_drvdata(dev, sds);
> + return 0;
> +
> +err_dev_add:
> + pci_set_drvdata(dev, NULL);
> + kfree(sds);
> +err_mem:
> + pci_disable_device(dev);
> + return ret;
> +}
> +
> +static void __devexit ce4100_i2c_remove(struct pci_dev *dev)
> +{
> + struct ce4100_devices *sds;
> + unsigned int i;
> +
> + sds = pci_get_drvdata(dev);
> + pci_set_drvdata(dev, NULL);
> +
> + for (i = 0; i< ARRAY_SIZE(sds->pdev); i++)
> + platform_device_unregister(sds->pdev[i]);
> +
> + pci_disable_device(dev);
> + kfree(sds);
> +}
> +
> +static struct pci_device_id ce4100_i2c_devices[] __devinitdata = {
> + { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x2e68)},
> + { },
> +};
> +MODULE_DEVICE_TABLE(pci, ce4100_i2c_devices);
> +
> +static struct pci_driver ce4100_i2c_driver = {
> + .name = "ce4100_i2c",
> + .id_table = ce4100_i2c_devices,
> + .probe = ce4100_i2c_probe,
> + .remove = __devexit_p(ce4100_i2c_remove),
> +};
> +
> +static int __init ce4100_i2c_init(void)
> +{
> + return pci_register_driver(&ce4100_i2c_driver);
> +}
> +module_init(ce4100_i2c_init);
> +
> +static void __exit ce4100_i2c_exit(void)
> +{
> + pci_unregister_driver(&ce4100_i2c_driver);
> +}
> +module_exit(ce4100_i2c_exit);
> +
> +MODULE_DESCRIPTION("CE4100 PCI-I2C glue code for PXA's driver");
> +MODULE_LICENSE("GPL v2");
> +MODULE_AUTHOR("Sebastian Andrzej Siewior<bigeasy@linutronix.de>");
> diff --git a/drivers/i2c/busses/i2c-pxa.c b/drivers/i2c/busses/i2c-pxa.c
> index fc2a90e..225e9a5 100644
> --- a/drivers/i2c/busses/i2c-pxa.c
> +++ b/drivers/i2c/busses/i2c-pxa.c
> @@ -38,6 +38,13 @@
>
> #include<asm/irq.h>
>
> +#ifdef CONFIG_X86
> +#define clk_get(dev, id) NULL
> +#define clk_put(clk) do { } while (0)
> +#define clk_disable(clk) do { } while (0)
> +#define clk_enable(clk) do { } while (0)
> +#endif
> +
Maybe be better on !CONFIG_HAVE_CLOCK (or whatever it is called)
> struct pxa_reg_layout {
> u32 ibmr;
> u32 idbr;
> @@ -49,6 +56,7 @@ struct pxa_reg_layout {
> enum pxa_i2c_types {
> REGS_PXA2XX,
> REGS_PXA3XX,
> + REGS_CE4100,
> };
>
> /*
> @@ -69,11 +77,19 @@ static struct pxa_reg_layout pxa_reg_layout[] = {
> .isr = 0x18,
> .isar = 0x20,
> },
> + [REGS_CE4100] = {
> + .ibmr = 0x14,
> + .idbr = 0x0c,
> + .icr = 0x00,
> + .isr = 0x04,
> + /* no isar register */
> + },
> };
>
> static const struct platform_device_id i2c_pxa_id_table[] = {
> { "pxa2xx-i2c", REGS_PXA2XX },
> { "pxa3xx-pwri2c", REGS_PXA3XX },
> + { "ce4100-i2c", REGS_CE4100 },
> { },
> };
> MODULE_DEVICE_TABLE(platform, i2c_pxa_id_table);
> @@ -442,7 +458,8 @@ static void i2c_pxa_reset(struct pxa_i2c *i2c)
> writel(I2C_ISR_INIT, _ISR(i2c));
> writel(readl(_ICR(i2c))& ~ICR_UR, _ICR(i2c));
>
> - writel(i2c->slave_addr, _ISAR(i2c));
> + if (i2c->reg_isar)
> + writel(i2c->slave_addr, _ISAR(i2c));
>
> /* set control register values */
> writel(I2C_ICR_INIT | (i2c->fast_mode ? ICR_FM : 0), _ICR(i2c));
> @@ -1074,7 +1091,8 @@ static int i2c_pxa_probe(struct platform_device *dev)
> i2c->reg_idbr = i2c->reg_base + pxa_reg_layout[i2c_type].idbr;
> i2c->reg_icr = i2c->reg_base + pxa_reg_layout[i2c_type].icr;
> i2c->reg_isr = i2c->reg_base + pxa_reg_layout[i2c_type].isr;
> - i2c->reg_isar = i2c->reg_base + pxa_reg_layout[i2c_type].isar;
> + if (i2c_type != REGS_CE4100)
> + i2c->reg_isar = i2c->reg_base + pxa_reg_layout[i2c_type].isar;
>
> i2c->iobase = res->start;
> i2c->iosize = resource_size(res);
> @@ -1113,7 +1131,10 @@ static int i2c_pxa_probe(struct platform_device *dev)
> i2c->adap.algo_data = i2c;
> i2c->adap.dev.parent =&dev->dev;
>
> - ret = i2c_add_numbered_adapter(&i2c->adap);
> + if (i2c_type == REGS_CE4100)
> + ret = i2c_add_adapter(&i2c->adap);
> + else
> + ret = i2c_add_numbered_adapter(&i2c->adap);
> if (ret< 0) {
> printk(KERN_INFO "I2C: Failed to add bus\n");
> goto eadapt;
^ permalink raw reply
* [PATCH 2/6] ARM: pxa2xx: reorganize I2C files
From: Ben Dooks @ 2011-03-02 0:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1298461100-14869-3-git-send-email-bigeasy@linutronix.de>
On 23/02/11 11:38, Sebastian Andrzej Siewior wrote:
> This patch moves the platform data definition from
> arch/arm/plat-pxa/include/plat/i2c.h to include/linux/i2c/pxa-i2c.h so
> it can be accessed from x86 the same way as on ARM.
>
> This change should make no functional change to the PXA code. The move
> is verified by building the following defconfigs:
> cm_x2xx_defconfig corgi_defconfig em_x270_defconfig ezx_defconfig
> imote2_defconfig pxa3xx_defconfig spitz_defconfig zeus_defconfig
> raumfeld_defconfig magician_defconfig mmp2_defconfig pxa168_defconfig
> pxa910_defconfig
>
Russell/others, you OK with this going through my tree?
^ permalink raw reply
* [PATCH] OMAP2+: hwmod: use status bit info for reset line
From: Omar Ramirez Luna @ 2011-03-02 0:46 UTC (permalink / raw)
To: linux-arm-kernel
On OMAP2 and OMAP3 the reset ctrl shift doesn't match the
status bit, as it does on OMAP4, when handling the reset lines.
This patch adds a new member in the reset info structure, so now it
can be added as part of hwmod data, and checked accordingly for
OMAP2 or 3; otherwise, there could be cases when the shift masks
doesn't match both of the registers, and a successful reset might
throw an error message or vice versa.
Signed-off-by: Omar Ramirez Luna <omar.ramirez@ti.com>
---
In OMAP3 (with an IVA), this affects IVA domain (in parenthesis the
shift needed).
RSTCTRL has:
RST3(2)
RST2(1)
RST1(0)
RSTST has:
...
IVA2_SW_RST3 (10)
IVA2_SW_RST2 (9)
IVA2_SW_RST1 (8)
COREDOMAINWKUP_RST (3)
GLOBALWARM_RST (2)
DOMAINWKUP_RST (1)
GLOBALCOLD_RST (0)
In OMAP2, it could potentially affect GFX, DSP and MDM domains; if the
resets are also used.
arch/arm/mach-omap2/omap_hwmod.c | 64 ++++++++++++++------------
arch/arm/mach-omap2/prm2xxx_3xxx.c | 18 ++++---
arch/arm/mach-omap2/prm2xxx_3xxx.h | 5 +-
arch/arm/plat-omap/include/plat/omap_hwmod.h | 2 +
4 files changed, 50 insertions(+), 39 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index e282e35..019fb29 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -972,25 +972,29 @@ static int _wait_target_ready(struct omap_hwmod *oh)
}
/**
- * _lookup_hardreset - return the register bit shift for this hwmod/reset line
+ * _lookup_hardreset - fill register bit info for this hwmod/reset line
* @oh: struct omap_hwmod *
* @name: name of the reset line in the context of this hwmod
+ * @r: pointer to be filled with the register bit shifts
*
* Return the bit position of the reset line that match the
* input name. Return -ENOENT if not found.
*/
-static u8 _lookup_hardreset(struct omap_hwmod *oh, const char *name)
+static u8 _lookup_hardreset(struct omap_hwmod *oh, const char *name,
+ struct omap_hwmod_rst_info *r)
{
int i;
for (i = 0; i < oh->rst_lines_cnt; i++) {
const char *rst_line = oh->rst_lines[i].name;
if (!strcmp(rst_line, name)) {
- u8 shift = oh->rst_lines[i].rst_shift;
- pr_debug("omap_hwmod: %s: _lookup_hardreset: %s: %d\n",
- oh->name, rst_line, shift);
+ r->rst_shift = oh->rst_lines[i].rst_shift;
+ r->st_shift = oh->rst_lines[i].st_shift;
+ pr_debug("omap_hwmod: %s: %s: %s: rst %d st %d\n",
+ oh->name, __func__, rst_line, r->rst_shift,
+ r->st_shift);
- return shift;
+ return 0;
}
}
@@ -1009,21 +1013,22 @@ static u8 _lookup_hardreset(struct omap_hwmod *oh, const char *name)
*/
static int _assert_hardreset(struct omap_hwmod *oh, const char *name)
{
- u8 shift;
+ struct omap_hwmod_rst_info r;
+ u8 ret;
if (!oh)
return -EINVAL;
- shift = _lookup_hardreset(oh, name);
- if (IS_ERR_VALUE(shift))
- return shift;
+ ret = _lookup_hardreset(oh, name, &r);
+ if (IS_ERR_VALUE(ret))
+ return ret;
if (cpu_is_omap24xx() || cpu_is_omap34xx())
return omap2_prm_assert_hardreset(oh->prcm.omap2.module_offs,
- shift);
+ r.rst_shift);
else if (cpu_is_omap44xx())
return omap4_prm_assert_hardreset(oh->prcm.omap4.rstctrl_reg,
- shift);
+ r.rst_shift);
else
return -EINVAL;
}
@@ -1040,29 +1045,29 @@ static int _assert_hardreset(struct omap_hwmod *oh, const char *name)
*/
static int _deassert_hardreset(struct omap_hwmod *oh, const char *name)
{
- u8 shift;
- int r;
+ struct omap_hwmod_rst_info r;
+ int ret;
if (!oh)
return -EINVAL;
- shift = _lookup_hardreset(oh, name);
- if (IS_ERR_VALUE(shift))
- return shift;
+ ret = _lookup_hardreset(oh, name, &r);
+ if (IS_ERR_VALUE(ret))
+ return ret;
if (cpu_is_omap24xx() || cpu_is_omap34xx())
- r = omap2_prm_deassert_hardreset(oh->prcm.omap2.module_offs,
- shift);
+ ret = omap2_prm_deassert_hardreset(oh->prcm.omap2.module_offs,
+ r.rst_shift, r.st_shift);
else if (cpu_is_omap44xx())
- r = omap4_prm_deassert_hardreset(oh->prcm.omap4.rstctrl_reg,
- shift);
+ ret = omap4_prm_deassert_hardreset(oh->prcm.omap4.rstctrl_reg,
+ r.rst_shift);
else
return -EINVAL;
- if (r == -EBUSY)
+ if (ret == -EBUSY)
pr_warning("omap_hwmod: %s: failed to hardreset\n", oh->name);
- return r;
+ return ret;
}
/**
@@ -1075,21 +1080,22 @@ static int _deassert_hardreset(struct omap_hwmod *oh, const char *name)
*/
static int _read_hardreset(struct omap_hwmod *oh, const char *name)
{
- u8 shift;
+ struct omap_hwmod_rst_info r;
+ u8 ret;
if (!oh)
return -EINVAL;
- shift = _lookup_hardreset(oh, name);
- if (IS_ERR_VALUE(shift))
- return shift;
+ ret = _lookup_hardreset(oh, name, &r);
+ if (IS_ERR_VALUE(ret))
+ return ret;
if (cpu_is_omap24xx() || cpu_is_omap34xx()) {
return omap2_prm_is_hardreset_asserted(oh->prcm.omap2.module_offs,
- shift);
+ r.st_shift);
} else if (cpu_is_omap44xx()) {
return omap4_prm_is_hardreset_asserted(oh->prcm.omap4.rstctrl_reg,
- shift);
+ r.rst_shift);
} else {
return -EINVAL;
}
diff --git a/arch/arm/mach-omap2/prm2xxx_3xxx.c b/arch/arm/mach-omap2/prm2xxx_3xxx.c
index ec03625..051213f 100644
--- a/arch/arm/mach-omap2/prm2xxx_3xxx.c
+++ b/arch/arm/mach-omap2/prm2xxx_3xxx.c
@@ -118,7 +118,8 @@ int omap2_prm_assert_hardreset(s16 prm_mod, u8 shift)
/**
* omap2_prm_deassert_hardreset - deassert a submodule hardreset line and wait
* @prm_mod: PRM submodule base (e.g. CORE_MOD)
- * @shift: register bit shift corresponding to the reset line to deassert
+ * @rst_shift: register bit shift corresponding to the reset line to deassert
+ * @st_shift: register bit shift for the status of the deasserted submodule
*
* Some IPs like dsp or iva contain processors that require an HW
* reset line to be asserted / deasserted in order to fully enable the
@@ -129,27 +130,28 @@ int omap2_prm_assert_hardreset(s16 prm_mod, u8 shift)
* -EINVAL upon an argument error, -EEXIST if the submodule was already out
* of reset, or -EBUSY if the submodule did not exit reset promptly.
*/
-int omap2_prm_deassert_hardreset(s16 prm_mod, u8 shift)
+int omap2_prm_deassert_hardreset(s16 prm_mod, u8 rst_shift, u8 st_shift)
{
- u32 mask;
+ u32 rst, st;
int c;
if (!(cpu_is_omap24xx() || cpu_is_omap34xx()))
return -EINVAL;
- mask = 1 << shift;
+ rst = 1 << rst_shift;
+ st = 1 << st_shift;
/* Check the current status to avoid de-asserting the line twice */
- if (omap2_prm_read_mod_bits_shift(prm_mod, OMAP2_RM_RSTCTRL, mask) == 0)
+ if (omap2_prm_read_mod_bits_shift(prm_mod, OMAP2_RM_RSTCTRL, rst) == 0)
return -EEXIST;
/* Clear the reset status by writing 1 to the status bit */
- omap2_prm_rmw_mod_reg_bits(0xffffffff, mask, prm_mod, OMAP2_RM_RSTST);
+ omap2_prm_rmw_mod_reg_bits(0xffffffff, st, prm_mod, OMAP2_RM_RSTST);
/* de-assert the reset control line */
- omap2_prm_rmw_mod_reg_bits(mask, 0, prm_mod, OMAP2_RM_RSTCTRL);
+ omap2_prm_rmw_mod_reg_bits(rst, 0, prm_mod, OMAP2_RM_RSTCTRL);
/* wait the status to be set */
omap_test_timeout(omap2_prm_read_mod_bits_shift(prm_mod, OMAP2_RM_RSTST,
- mask),
+ st),
MAX_MODULE_HARDRESET_WAIT, c);
return (c == MAX_MODULE_HARDRESET_WAIT) ? -EBUSY : 0;
diff --git a/arch/arm/mach-omap2/prm2xxx_3xxx.h b/arch/arm/mach-omap2/prm2xxx_3xxx.h
index 49654c8..a1fc62a 100644
--- a/arch/arm/mach-omap2/prm2xxx_3xxx.h
+++ b/arch/arm/mach-omap2/prm2xxx_3xxx.h
@@ -282,7 +282,8 @@ static inline int omap2_prm_assert_hardreset(s16 prm_mod, u8 shift)
"not suppose to be used on omap4\n");
return 0;
}
-static inline int omap2_prm_deassert_hardreset(s16 prm_mod, u8 shift)
+static inline int omap2_prm_deassert_hardreset(s16 prm_mod, u8 rst_shift,
+ u8 st_shift)
{
WARN(1, "prm: omap2xxx/omap3xxx specific function and "
"not suppose to be used on omap4\n");
@@ -300,7 +301,7 @@ extern u32 omap2_prm_read_mod_bits_shift(s16 domain, s16 idx, u32 mask);
/* These omap2_ PRM functions apply to both OMAP2 and 3 */
extern int omap2_prm_is_hardreset_asserted(s16 prm_mod, u8 shift);
extern int omap2_prm_assert_hardreset(s16 prm_mod, u8 shift);
-extern int omap2_prm_deassert_hardreset(s16 prm_mod, u8 shift);
+extern int omap2_prm_deassert_hardreset(s16 prm_mod, u8 rst_shift, u8 st_shift);
#endif /* CONFIG_ARCH_OMAP4 */
#endif
diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h b/arch/arm/plat-omap/include/plat/omap_hwmod.h
index 1eee85a..28596b7 100644
--- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
+++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
@@ -124,6 +124,7 @@ struct omap_hwmod_dma_info {
* struct omap_hwmod_rst_info - IPs reset lines use by hwmod
* @name: name of the reset line (module local name)
* @rst_shift: Offset of the reset bit
+ * @st_shift: Offset of the reset status bit
*
* @name should be something short, e.g., "cpu0" or "rst". It is defined
* locally to the hwmod.
@@ -131,6 +132,7 @@ struct omap_hwmod_dma_info {
struct omap_hwmod_rst_info {
const char *name;
u8 rst_shift;
+ u8 st_shift;
};
/**
--
1.7.1
^ permalink raw reply related
* [PATCH 2/4] msm: scm: Fix improper register assignment
From: Nicolas Pitre @ 2011-03-02 0:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4D6D652A.5050502@codeaurora.org>
On Tue, 1 Mar 2011, Saravana Kannan wrote:
> On 03/01/2011 02:37 AM, Will Deacon wrote:
> > Perhaps a more robust fix would be to remove the register int
> > declarations and handle the parameter marshalling in the same asm block
> > that contains the smc?
>
> I was thinking the same, but the opposing idea I heard was that not doing it
> inside the asm block would allow GCC to be make better use of the registers.
Indeed. And a significant body of code out there does rely on this gcc
feature, so it has to minimally work.
> Didn't have a strong opinion either way, so we went with the implementation
> that was sent out.
ACK.
Nicolas
^ 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