* [PATCH 2/5] OMAP2xxx: clock: fix low-frequency oscillator clock rate
From: Paul Walmsley @ 2011-02-17 4:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110217041437.16009.52336.stgit@twilight.localdomain>
The OMAP2420/2430 external 32-kHz low-frequency oscillator is a 32768
Hz oscillator, not a 32,000 Hz oscillator[1][2]. Fix this in the clock
tree.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
1. OMAP2420/22 Multimedia Processor Data Manual, Version P [SWPS019P],
section 5.1.4 "External 32-kHz CMOS Clock" (note that it refers to
a "32.768-kHz" clock; this presumably should be "32.768-KHz")
2. OMAP2430 Multimedia Processor ES2.1 Data Manual, Version V [SWPS023V],
section 5.1.4 "External 32-kHz CMOS Clock" (note that it refers to
a "32.768-kHz" clock; this presumably should be "32.768-KHz")
---
arch/arm/mach-omap2/clock2420_data.c | 2 +-
arch/arm/mach-omap2/clock2430_data.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/clock2420_data.c b/arch/arm/mach-omap2/clock2420_data.c
index 693a0a8..fd5ba90 100644
--- a/arch/arm/mach-omap2/clock2420_data.c
+++ b/arch/arm/mach-omap2/clock2420_data.c
@@ -55,7 +55,7 @@
static struct clk func_32k_ck = {
.name = "func_32k_ck",
.ops = &clkops_null,
- .rate = 32000,
+ .rate = 32768,
.clkdm_name = "wkup_clkdm",
};
diff --git a/arch/arm/mach-omap2/clock2430_data.c b/arch/arm/mach-omap2/clock2430_data.c
index f00f52e..0d069ef 100644
--- a/arch/arm/mach-omap2/clock2430_data.c
+++ b/arch/arm/mach-omap2/clock2430_data.c
@@ -55,7 +55,7 @@
static struct clk func_32k_ck = {
.name = "func_32k_ck",
.ops = &clkops_null,
- .rate = 32000,
+ .rate = 32768,
.clkdm_name = "wkup_clkdm",
};
^ permalink raw reply related
* [PATCH 1/5] OMAP2xxx: clock: fix parents for L3-derived clocks
From: Paul Walmsley @ 2011-02-17 4:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110217041437.16009.52336.stgit@twilight.localdomain>
Several clocks are listed as having the core L4 clock as their parent,
when they are actually derived from the L3 clock. Fix these.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
---
arch/arm/mach-omap2/clock2420_data.c | 2 +-
arch/arm/mach-omap2/clock2430_data.c | 6 +++---
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/clock2420_data.c b/arch/arm/mach-omap2/clock2420_data.c
index 68c0369..693a0a8 100644
--- a/arch/arm/mach-omap2/clock2420_data.c
+++ b/arch/arm/mach-omap2/clock2420_data.c
@@ -1614,7 +1614,7 @@ static struct clk sdma_fck = {
static struct clk sdma_ick = {
.name = "sdma_ick",
.ops = &clkops_omap2_iclk_idle_only,
- .parent = &l4_ck,
+ .parent = &core_l3_ck,
.clkdm_name = "core_l3_clkdm",
.enable_reg = OMAP_CM_REGADDR(CORE_MOD, CM_ICLKEN3),
.enable_bit = OMAP24XX_AUTO_SDMA_SHIFT,
diff --git a/arch/arm/mach-omap2/clock2430_data.c b/arch/arm/mach-omap2/clock2430_data.c
index 34daed9..f00f52e 100644
--- a/arch/arm/mach-omap2/clock2430_data.c
+++ b/arch/arm/mach-omap2/clock2430_data.c
@@ -1652,7 +1652,7 @@ static struct clk sdma_fck = {
static struct clk sdma_ick = {
.name = "sdma_ick",
.ops = &clkops_omap2_iclk_idle_only,
- .parent = &l4_ck,
+ .parent = &core_l3_ck,
.clkdm_name = "core_l3_clkdm",
.enable_reg = OMAP_CM_REGADDR(CORE_MOD, CM_ICLKEN3),
.enable_bit = OMAP24XX_AUTO_SDMA_SHIFT,
@@ -1662,9 +1662,9 @@ static struct clk sdma_ick = {
static struct clk sdrc_ick = {
.name = "sdrc_ick",
.ops = &clkops_omap2_iclk_idle_only,
- .parent = &l4_ck,
+ .parent = &core_l3_ck,
.flags = ENABLE_ON_INIT,
- .clkdm_name = "core_l4_clkdm",
+ .clkdm_name = "core_l3_clkdm",
.enable_reg = OMAP_CM_REGADDR(CORE_MOD, CM_ICLKEN3),
.enable_bit = OMAP2430_EN_SDRC_SHIFT,
.recalc = &followparent_recalc,
^ permalink raw reply related
* [PATCH 0/5] OMAP: clock: miscellaneous fixes and dead code removal for 2.6.39
From: Paul Walmsley @ 2011-02-17 4:17 UTC (permalink / raw)
To: linux-arm-kernel
Hello,
This series contains some OMAP clock patches for 2.6.39. The patches
in this series fix some long-standing inaccuracies in the OMAP2xxx clock trees,
prepare for some clock framework locking changes, and remove some
DPLL rate rounding code that I don't think anyone is using.
Dynamic idle entry and exit has been tested on an OMAP3530 Beagleboard, and
the "before" and "after" clock trees have been verified on an N800.
- Paul
---
clk_b_2.6.39
text data bss dec hex filename
3697449 229488 5390028 9316965 8e2a65 vmlinux.n800.orig
3697325 229584 5390028 9316937 8e2a49 vmlinux.n800.patched
Paul Walmsley (5):
OMAP2xxx: clock: fix parents for L3-derived clocks
OMAP2xxx: clock: fix low-frequency oscillator clock rate
OMAP2xxx: clock: fix interface clocks and clockdomains for modules in the WKUP domain
OMAP: clock: bail out early if arch_clock functions not implemented
OMAP2+: clock: remove the DPLL rate tolerance code
arch/arm/mach-omap2/clkt_dpll.c | 91 ++++++++-----------------------
arch/arm/mach-omap2/clock.h | 4 -
arch/arm/mach-omap2/clock2420_data.c | 38 ++++++++-----
arch/arm/mach-omap2/clock2430_data.c | 46 +++++++++-------
arch/arm/mach-omap2/clock3xxx_data.c | 6 --
arch/arm/plat-omap/clock.c | 66 +++++++++++++---------
arch/arm/plat-omap/include/plat/clock.h | 7 --
7 files changed, 112 insertions(+), 146 deletions(-)
^ permalink raw reply
* [PATCH v2 1/7] mmc: mxs-mmc: add mmc host driver for i.MX23/28
From: Shawn Guo @ 2011-02-17 4:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110216153332.GC6365@pengutronix.de>
Hi Wolfram,
On Wed, Feb 16, 2011 at 04:33:32PM +0100, Wolfram Sang wrote:
> Hi Shawn,
>
> [CRC failures on MMC]
> > I guess you will also get the unknown partition table message if you
> > test this card on mx35 right now.
>
> No, I didn't see that message on MX35. (Doesn't matter much now).
>
> > I just tested 7 mmc cards in total. 6 cards work fine, and 1 card
> > (Transcend MMC plus 1GB) has the exactly same problem as yours. And
> > if I remove the 8 bit cap, this card also works fine. So I would
> > agree with Russell that it's unrelated to the driver.
>
> Ah, the 8_BIT_CAP was the right pointer. It works now and I can see the
> partitions \o/ But IMHO it is related to the driver because it cannot set that
> 8_BIT_DATA_CAP unconditionally? Probably something like 'flags' should be added
> to platform_data? One flag could then be 8_BIT_CAPABLE_SLOT or something.
>
If a platform is designed to support 8-bit mode (e.g. all 8 data
lines are routed), I do not think the 8-bit cap will be removed from
this platform just because one particular card has problem to work
in 8-bit mode.
But I would anyway let platform_data tell the 4 BIT_CAP and 8_BIT_CAP
just like what Freescale BSP is doing, as some platforms may design
this cap differently.
> > I tested the SDIO, but probably in different way from yours. I had
> > two card slots on my board, rootfs on mmc0 and SDIO card on mmc1.
> > It seems working fine in this way. However, when I use nfs and test
> > SDIO on mmc0, my systems hangs too. I will look into it.
>
> The latter scenario is the only one I can test, because I don't have an
> (active) second slot.
>
It's a board thing. I just rechecked the schematics of mx28evk
board, and found that the power supply of the two slots are
different. The mmc1 uses the external regulator REG_3V3 which can
supply up to 1.5 A current, while mmc0 uses mx28 internal regulator
VDDIO_3V3 which has very limited current capability. That's why my
SDIO WiFi card works on mmc1 slot while hangs system on mmc0. When
I reworked the board to supply mmc0 with REG_3V3, the card works on
mmc0 too.
So your board supplies mmc0 slot with VDDIO_3V3 as well?
--
Regards,
Shawn
^ permalink raw reply
* [klibc] fwd: fix up ARM assembly to use 'bx lr' in place of 'mov pc, lr'.
From: Khem Raj @ 2011-02-17 3:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTimF6ppk1RHXJnZ+pT1Xwb02idKr5dsFFXsW0Nqr@mail.gmail.com>
On Wed, Feb 16, 2011 at 4:03 PM, Khem Raj <raj.khem@gmail.com> wrote:
> On Wed, Feb 16, 2011 at 3:50 PM, Kirill A. Shutemov
> <kirill@shutemov.name> wrote:
>> On Thu, Feb 17, 2011 at 12:06:48AM +0100, maximilian attems wrote:
>>> hello vorlon,
>>>
>>> got notified of your patch,
>>> will apply next days upstream unless some critiques are voiced on ml.
>>> thanks.
>>>
>>> --
>>> maks
>>>
>>>
>>> ----- Forwarded message from Steve Langasek <steve.langasek@canonical.com> -----
>>>
>>> Date: Wed, 16 Feb 2011 22:05:42 -0000
>>> From: Steve Langasek <steve.langasek@canonical.com>
>>> Subject: [Bug 527720] Re: thumb2 porting issues identified: klibc uses mov.*pc
>>>
>>>
>>> I've also touched it up to be mergeable with Debian (support v4t builds
>>> with #ifdef).
>>>
>>> Confirmed that installing the resulting klibc packages on my beagleboard
>>> gives me a successfully-booting initramfs with klibc; and the
>>> vfork/setjmptest test cases all pass in the klibc package tree.
>>>
>>> Fixes: https://bugs.launchpad.net/ubuntu/+source/klibc/+bug/527720
>>>
>>> --- klibc-1.5.20.orig/usr/klibc/arch/arm/vfork.S
>>> +++ klibc-1.5.20/usr/klibc/arch/arm/vfork.S
>>> @@ -25,7 +25,11 @@ vfork:
>>> ? ? ? ? ?ldrcs ? ? ? ?r3, 1f
>>> ? ? ? ? ?mvncs ? ? ? ?r0, #0
>>> ? ? ? ? ?strcs ? ? ? ?r2, [r3]
>>> +#if defined (___ARM_ARCH_4T__) || defined (__ARM_ARCH_4__)
>>
>> NAK. ARMv4T supports bx intruction. ARMv4 doesn't.
>
> Does ARMv4t support BX lr ?
hmm yes it does. I confused it with blx <Rm> which is unpredictable in
thumb mode on architectures < armv5t
>
>
>>
>>> ? ? ? mov ? ? pc, lr
>>> +#else
>>> + ? ? bx ? ? ?lr
>>> +#endif
>>>
>>> ? ? ? .balign 4
>>> ?1:
>>> @@ -49,7 +53,11 @@ vfork:
>>> ? ? ? str ? ? r2, [r1]
>>> ? ? ? neg ? ? r0, r0
>>> ?1:
>>> +#if defined (___ARM_ARCH_4T__) || defined (__ARM_ARCH_4__)
>>> ? ? ? mov ? ? pc, lr
>>> +#else
>>> + ? ? bx ? ? ?lr
>>> +#endif
>>>
>>> ? ? ? .balign 4
>>> ?2:
>>> --- klibc-1.5.20.orig/usr/klibc/arch/arm/setjmp.S
>>> +++ klibc-1.5.20/usr/klibc/arch/arm/setjmp.S
>>> @@ -29,7 +29,11 @@
>>> ?setjmp:
>>> ? ? ? stmia ? r0, {r4, r5, r6, r7, r8, r9, r10, fp, sp, lr}
>>> ? ? ? mov ? ? r0, #0
>>> +#if defined (___ARM_ARCH_4T__) || defined (__ARM_ARCH_4__)
>>> ? ? ? mov ? ? pc, lr
>>> +#else
>>> + ? ? bx ? ? ?lr
>>> +#endif
>>> ? ? ? .size setjmp,.-setjmp
>>>
>>> ? ? ? .text
>>> @@ -39,7 +43,11 @@ setjmp:
>>> ?longjmp:
>>> ? ? ? ldmia ? r0, {r4, r5, r6, r7, r8, r9, r10, fp, sp, lr}
>>> ? ? ? mov ? ? r0, r1
>>> +#if defined (___ARM_ARCH_4T__) || defined (__ARM_ARCH_4__)
>>> ? ? ? mov ? ? pc, lr
>>> +#else
>>> + ? ? bx ? ? ?lr
>>> +#endif
>>> ? ? ? .size longjmp,.-longjmp
>>>
>>> ?#else /* __thumb__ */
>>> @@ -75,7 +83,11 @@ setjmp:
>>> ? ? ? mov ? ? r7, sp
>>> ? ? ? stmia ? r0!, {r3, r4, r5, r6, r7}
>>> ? ? ? mov ? ? r0, #0
>>> +#if defined (___ARM_ARCH_4T__) || defined (__ARM_ARCH_4__)
>>> ? ? ? mov ? ? pc, lr
>>> +#else
>>> + ? ? bx ? ? ?lr
>>> +#endif
>>> ? ? ? .size setjmp,.-setjmp
>>>
>>> ? ? ? .text
>>> @@ -96,7 +108,11 @@ longjmp:
>>> ? ? ? mov ? ? r0, r1
>>> ? ? ? bne ? ? 1f
>>> ? ? ? mov ? ? r0, #1
>>> +#if defined (___ARM_ARCH_4T__) || defined (__ARM_ARCH_4__)
>>> ?1: ? mov ? ? pc, r3
>>> +#else
>>> +1: ? bx ? ? ?r3
>>> +#endif
>>> ? ? ? .size longjmp,.-longjmp
>>>
>>> ?#endif /* __thumb__ */
>>>
>>> _______________________________________________
>>> klibc mailing list
>>> klibc at zytor.com
>>> http://www.zytor.com/mailman/listinfo/klibc
>>
>> --
>> ?Kirill A. Shutemov
>>
>> _______________________________________________
>> 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 v2 1/7] mmc: mxs-mmc: add mmc host driver for i.MX23/28
From: Shawn Guo @ 2011-02-17 2:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201102161659.18475.arnd@arndb.de>
Hi Arnd,
On Wed, Feb 16, 2011 at 04:59:18PM +0100, Arnd Bergmann wrote:
> On Wednesday 16 February 2011, Shawn Guo wrote:
> > It's caused by spinlock recursion introduced by mxs-dma functions
> > mxs_dma_tx_submit and mxs_dma_tasklet. We have mmc_request_done
> > invoked in the dma callback tasklet. At the meantime,
> > mmc_request_done will issue retries in some case, which will call in
> > mxs_dma_tx_submit.
> >
> > I added the lock by referring to other dma driver implementation, but
> > now I'm considering to remove the lock completely, as I do not see
> > any global data needs to be protected there. Comments?
>
> You need to be sure that the data accessed in the tasklet does not
> need to be locked against mxs_dma_tx_submit.
>
The only thing we actually put in tasklet is just the callback
registered by client device driver, which should not have anything
that mxs_dma_tx_submit would concern.
> I haven't looked at the dmaengine code for this, but it's quite likely
> that you actually need it, because you need to serialize adding an
> element to the DMA device with removing it again.
>
I'm not sure that I understand your comment. If the adding/removing
an element means what mxs_dma_alloc_chan_resources and
mxs_dma_free_chan_resources do, I do not think it's a problem, as
client driver is calling them in probe/remove for once.
--
Regards,
Shawn
^ permalink raw reply
* MMC quirks relating to performance/lifetime.
From: Andrei Warkentin @ 2011-02-17 2:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201102151816.57104.arnd@arndb.de>
On Tue, Feb 15, 2011 at 11:16 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Monday 14 February 2011, Andrei Warkentin wrote:
>> > There are multiple ways how this could be implemented:
>> >
>> > 1. Have one exception cache for all "special" blocks. This would normally
>> > ? be for FAT32 subdirectory updates, which always write to the same
>> > ? few blocks. This means you can do small writes efficiently anywhere
>> > ? on the card, but only up to a (small) fixed number of block addresses.
>> > ? If you overflow the table, the card still needs to go through an
>> > ? extra PE for each new entry you write, in order to free up an entry.
>> >
>> > 2. Have a small number of AUs that can be in a special mode with efficient
>> > ? small writes but inefficient large writes. This means that when you
>> > ? alternate between small and large writes in the same AU, it has to go
>> > ? through a PE on every switch. Similarly, if you do small writes to
>> > ? more than the maximum number of AUs that can be held in this mode, you
>> > ? get the same effect. This number can be as small as one, because that
>> > ? is what FAT32 requires.
>> >
>> > In both cases, you don't actually have a solution for the problem, you just
>> > make it less likely for specific workloads.
>>
>> Aha, ok. By the way, I did find out that either suggestion works. So
>> I'll pull out the reversing portion of the patch. No need to
>> overcomplicate :).
>
> BTW, what file system are you using? I could imagine that each of ext4, btrfs
> and nilfs2 give you very different results here. It could be that if your
> patch is optimizing for one file system, it is actually pessimising for
> another one.
>
Ext4. I've actually been rewriting the patch a lot and it's taking
time because there are a lot of things that are wrong in it (so I feel
kinda bad for forwarding it to this list in the first place...). I've
already mentioned that there is no need to reorder, so that's going
away and it simplifies everything greatly.
I agree, which is why all of this is controlled now through sysfs, and
there are no more hard-coded checks for manfid, mmc versus sd or any
other magic. There is a page_size_secs attribute, through which you
can notify of the page size for the device. The workaround for small
writes crossing the page boundary (and winding up in Buffer B, instead
of A) is turned on by setting split_tlow and split_thigh, which
provided a threshold range in sectors over which the the writes will
be split/aligned. The second workaround for splitting larger requests
and writing them with reliable write (to avoid getting coalesced and
winding up in Buffer B again) is controlled through split_relw_tlow
and split_relw_thigh. Do you think there is a better way? Or is this
good enough?
So, as I mentioned before, T had done some tests given data provided
by M, and then T verified that this fix was good. I need to do my own
tests on the patch after I rewrite it. Is iozone the best tool I can
use? So far I have a MMC logging facility through connector that I use
to collect stats (useful for seeing how fs traffic translates to
actual mmc commands...once I clean it up I'll push here for RFC). What
about the tool you're writing? Any way I can use it?
^ permalink raw reply
* compiling 2.6.37 kernel in THUMB2 mode
From: vb at vsbe.com @ 2011-02-17 2:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTi=PLJBZ=Q-4k8ZUbX4S3w7f3WfUd9acb7iVYGBP@mail.gmail.com>
On Wed, Feb 16, 2011 at 1:19 AM, Dave Martin <dave.martin@linaro.org> wrote:
>>
>> Note that while the bulk of the kernel is Thumb-2 safe, there are
>> occasional regressions, and individual platforms and drivers could
>> still have problems. ?For now, I've been focusing on omap--- see
>>
>> git://git.linaro.org/people/dmart/linux-2.6-arm.git dirty/arm/omap-thumb2+merged
>>
>> ARM: Add local symbols in relocate_kernel.S to work around gas bugs
>
> ^ Oops, forgot to explain that line: this is the patch required to
> work around a specific bug in the assembler. ?I'm not currently
> proposing to merge this upstream, since I prefer the assembler to get
> fixed...
> You can grab this patch from the branch.
>
Dave, thank you for this information. I checked out this branch and
would like to build a kernel. I don't know what omap is though, can
you please share a config file one could use to build the thumb
enabled kernel for it?
TIA,
cheers,
Vadim
>>
>> If you're trying to support a specific board I'm unlikely to be able
>> to debug it for you, but feel free to ping me with questions.
>>
>> Cheers
>> ---Dave
>>
>
^ permalink raw reply
* [PATCH 2/2] ARM: remove the 4x expansion presumption while decompressing the kernel
From: Nicolas Pitre @ 2011-02-17 1:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110217000923.GF2364@angua.secretlab.ca>
On Wed, 16 Feb 2011, Grant Likely wrote:
> Patch looks good to me, but on a related note, I'm looking for a way
> to also find the end of .bss.
>
> When John looks at adding support for appending an initrd and/or dtb
> to the zimage, it will be important to make sure the start of the
> initrd/dtb does not overlap the ram the kernel is expecting to be
> empty and available. I was thinking about simply grepping System.map
> for __end and doing some sed magic to extract the offset from the
> beginning of the kernel.
I'd use the 'size' command instead:
$ arm-linux-size vmlinux
text data bss dec hex filename
3707759 135316 137808 3980883 3cbe53 vmlinux
> Do you think that is sufficient to protect appended data images?
Starting with my compressed/head.S rework, you'd have to:
1) Detect if there is some valuable data past _edata, and if so then
increase the cached _edata value in r6 accordingly. This way, if
zImage needs to relocate itself then that will include that data.
2) Modify the conditions and parameters for a zImage relocation to
ensure the end of the kernel .bss is below the start of your data.
3) Modify the relocation of .bss entries in the GOT table so .bss is
effectively moved after that appended data.
4) Tell the kernel about the data via extra ATAG/DTB entries.
Except for (4), this can be done with only a few assembly instructions.
And even in the ATAG case there is a good example in
arch/arm/boot/bootp/init.S for (4), but that could as well be done in C
instead, like the initial patch that John Bonesio did.
Nicolas
^ permalink raw reply
* [PATCH 1/2] omap4: 4430sdp: drop ehci support
From: Tony Lindgren @ 2011-02-17 1:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110216112631.GA2497@legolas.emea.dhcp.ti.com>
* Felipe Balbi <balbi@ti.com> [110216 03:25]:
> On Wed, Feb 16, 2011 at 04:47:19PM +0530, Anand Gadiyar wrote:
> > Most revisions of the OMAP4 Blaze/SDP platform do not have
> > the EHCI signals routed by default. The pads are routed
> > for the alternate HSI functionality instead, and explicit
> > board modifications are needed to route the signals to
> > the USB PHY on the board.
> >
> > Also, turning on the PHY connected to the EHCI port causes
> > a board reboot during bootup due to an unintended short
> > on the rails - this affects many initial revisions of the
> > board, and needs a minor board mod to fix (or as a
> > workaround, one should not attempt to power on the
> > USB PHY).
> >
> > Given that these boards need explicit board mods to even
> > get EHCI working (separate from the accidental short above),
> > we should not attempt to enable EHCI by default.
> >
> > So drop the EHCI support from the board files for the
> > Blaze/SDP platforms.
> >
> > Signed-off-by: Anand Gadiyar <gadiyar@ti.com>
> > Cc: Keshava Munegowda <keshava_mgowda@ti.com>
> > Cc: Tony Lindgren <tony@atomide.com>
>
> Tony, if you want to queue this one directly, here's my:
>
> Acked-by: Felipe Balbi <balbi@ti.com>
>
> if you wish, I can send you a pull request as well. I already have
> another patch for you anyway.
OK if you have more I'd rather pull.
Tony
^ permalink raw reply
* [PATCH] i.MX23/28 framebuffer driver
From: Jammy Zhou @ 2011-02-17 1:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTimMBLhopNq0L-NuJLdX08SrA078VF3tWf9TcEom@mail.gmail.com>
There is already one KMS abstraction layer (libkms.so) in libdrm, maybe it
can serve as what we needed.
Regards,
Jammy
On Thu, Feb 17, 2011 at 9:08 AM, Clark, Rob <rob@ti.com> wrote:
> I'm still in the learning-as-I-go phase here, so definitely not ready
> to propose a solution, but it does seem to me like there is room for
> some sort of kms-helper library here to handle more of the boilerplate
> xf86-video-* stuff.. I guess I'll have a better picture once I have a
> chance to add support for the various multi-monitor configurations.
> But certainly would be interested if anyone already has some ideas.
>
> BR,
> -R
>
> On Wed, Feb 16, 2011 at 8:42 AM, Jesse Barker <jesse.barker@linaro.org>
> wrote:
> > Speaking for the Linaro graphics working group, I think it's great. And,
> I
> > think you're right, that if enough of the KMS support in xf86-video-* is
> > similar enough (I was only aware of intel and nouveau supporting it
> properly
> > at current), pulling it out into a common layer would make it easier to
> > support in new drivers (including fbdev).
> >
> > cheers,
> > Jesse
> >
> > On Wed, Feb 16, 2011 at 4:22 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> >>
> >> On Tuesday 15 February 2011, Clark, Rob wrote:
> >> > I'd been experimenting a bit on the side w/ the DRM driver framework (
> >> >
> >> >
> http://gitorious.com/~robclark/pandaboard/robclarks-kernel-omap4/commits/omap_gpu
> >> > ), but had to add a good chunk of mostly boilerplate code to our xorg
> >> > driver in order just to test it. Maybe some generic support for KMS
> >> > in xf86-video-fbdev would have made this easier to develop the kernel
> >> > part without in parallel having to implement the userspace part. I'm
> >> > not sure if this is the sort of thing the linaro-wg has in mind?
> >>
> >> I'm not sure what the the linaro multimedia wg thinks of this, but the
> >> kernel code you linked looks like it's doing exactly the right thing.
> >>
> >> Arnd
> >>
> >> _______________________________________________
> >> linaro-dev mailing list
> >> linaro-dev at lists.linaro.org
> >> http://lists.linaro.org/mailman/listinfo/linaro-dev
> >
> >
>
> _______________________________________________
> linaro-dev mailing list
> linaro-dev at lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/linaro-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20110217/47c57980/attachment-0001.html>
^ permalink raw reply
* [PATCH] i.MX23/28 framebuffer driver
From: Clark, Rob @ 2011-02-17 1:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTik+ounqcTJ6rhiUqKPGkwcCOKGXdsVADs6zHfPU@mail.gmail.com>
I'm still in the learning-as-I-go phase here, so definitely not ready
to propose a solution, but it does seem to me like there is room for
some sort of kms-helper library here to handle more of the boilerplate
xf86-video-* stuff.. I guess I'll have a better picture once I have a
chance to add support for the various multi-monitor configurations.
But certainly would be interested if anyone already has some ideas.
BR,
-R
On Wed, Feb 16, 2011 at 8:42 AM, Jesse Barker <jesse.barker@linaro.org> wrote:
> Speaking for the Linaro graphics working group, I think it's great.? And, I
> think you're right, that if enough of the KMS support in xf86-video-* is
> similar enough (I was only aware of intel and nouveau supporting it properly
> at current), pulling it out into a common layer would make it easier to
> support in new drivers (including fbdev).
>
> cheers,
> Jesse
>
> On Wed, Feb 16, 2011 at 4:22 AM, Arnd Bergmann <arnd@arndb.de> wrote:
>>
>> On Tuesday 15 February 2011, Clark, Rob wrote:
>> > I'd been experimenting a bit on the side w/ the DRM driver framework (
>> >
>> > http://gitorious.com/~robclark/pandaboard/robclarks-kernel-omap4/commits/omap_gpu
>> > ), but had to add a good chunk of mostly boilerplate code to our xorg
>> > driver in order just to test it. ?Maybe some generic support for KMS
>> > in xf86-video-fbdev would have made this easier to develop the kernel
>> > part without in parallel having to implement the userspace part. ?I'm
>> > not sure if this is the sort of thing the linaro-wg has in mind?
>>
>> I'm not sure what the the linaro multimedia wg thinks of this, but the
>> kernel code you linked looks like it's doing exactly the right thing.
>>
>> ? ? ? ?Arnd
>>
>> _______________________________________________
>> linaro-dev mailing list
>> linaro-dev at lists.linaro.org
>> http://lists.linaro.org/mailman/listinfo/linaro-dev
>
>
^ permalink raw reply
* [klibc] fwd: fix up ARM assembly to use 'bx lr' in place of 'mov pc, lr'.
From: Kirill A. Shutemov @ 2011-02-17 0:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTimF6ppk1RHXJnZ+pT1Xwb02idKr5dsFFXsW0Nqr@mail.gmail.com>
On Wed, Feb 16, 2011 at 04:03:07PM -0800, Khem Raj wrote:
> On Wed, Feb 16, 2011 at 3:50 PM, Kirill A. Shutemov
> <kirill@shutemov.name> wrote:
> > On Thu, Feb 17, 2011 at 12:06:48AM +0100, maximilian attems wrote:
> >> hello vorlon,
> >>
> >> got notified of your patch,
> >> will apply next days upstream unless some critiques are voiced on ml.
> >> thanks.
> >>
> >> --
> >> maks
> >>
> >>
> >> ----- Forwarded message from Steve Langasek <steve.langasek@canonical.com> -----
> >>
> >> Date: Wed, 16 Feb 2011 22:05:42 -0000
> >> From: Steve Langasek <steve.langasek@canonical.com>
> >> Subject: [Bug 527720] Re: thumb2 porting issues identified: klibc uses mov.*pc
> >>
> >>
> >> I've also touched it up to be mergeable with Debian (support v4t builds
> >> with #ifdef).
> >>
> >> Confirmed that installing the resulting klibc packages on my beagleboard
> >> gives me a successfully-booting initramfs with klibc; and the
> >> vfork/setjmptest test cases all pass in the klibc package tree.
> >>
> >> Fixes: https://bugs.launchpad.net/ubuntu/+source/klibc/+bug/527720
> >>
> >> --- klibc-1.5.20.orig/usr/klibc/arch/arm/vfork.S
> >> +++ klibc-1.5.20/usr/klibc/arch/arm/vfork.S
> >> @@ -25,7 +25,11 @@ vfork:
> >> ? ? ? ? ?ldrcs ? ? ? ?r3, 1f
> >> ? ? ? ? ?mvncs ? ? ? ?r0, #0
> >> ? ? ? ? ?strcs ? ? ? ?r2, [r3]
> >> +#if defined (___ARM_ARCH_4T__) || defined (__ARM_ARCH_4__)
> >
> > NAK. ARMv4T supports bx intruction. ARMv4 doesn't.
>
> Does ARMv4t support BX lr ?
Sure.
See http://wiki.debian.org/ArmEabiPort
--
Kirill A. Shutemov
^ permalink raw reply
* [klibc] fwd: fix up ARM assembly to use 'bx lr' in place of 'mov pc, lr'.
From: Kirill A. Shutemov @ 2011-02-17 0:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110217000144.GA6995@virgil.dodds.net>
On Wed, Feb 16, 2011 at 04:01:44PM -0800, Steve Langasek wrote:
> Thanks for forwarding this on, maks.
>
> On Thu, Feb 17, 2011 at 01:50:19AM +0200, Kirill A. Shutemov wrote:
> > > Date: Wed, 16 Feb 2011 22:05:42 -0000
> > > From: Steve Langasek <steve.langasek@canonical.com>
> > > Subject: [Bug 527720] Re: thumb2 porting issues identified: klibc uses mov.*pc
>
> > > I've also touched it up to be mergeable with Debian (support v4t builds
> > > with #ifdef).
>
> > > Confirmed that installing the resulting klibc packages on my beagleboard
> > > gives me a successfully-booting initramfs with klibc; and the
> > > vfork/setjmptest test cases all pass in the klibc package tree.
>
> > > Fixes: https://bugs.launchpad.net/ubuntu/+source/klibc/+bug/527720
>
> > > --- klibc-1.5.20.orig/usr/klibc/arch/arm/vfork.S
> > > +++ klibc-1.5.20/usr/klibc/arch/arm/vfork.S
> > > @@ -25,7 +25,11 @@ vfork:
> > > ldrcs r3, 1f
> > > mvncs r0, #0
> > > strcs r2, [r3]
> > > +#if defined (___ARM_ARCH_4T__) || defined (__ARM_ARCH_4__)
>
> > NAK. ARMv4T supports bx intruction. ARMv4 doesn't.
>
> I see from
> https://wiki.ubuntu.com/ARM/Thumb2PortingHowto#Identifying%20the%20Target%20Architecture
> that you are correct - but then in
> https://wiki.ubuntu.com/ARM/Thumb2PortingHowto#Detailed%20Instruction%20Behaviour
> the recommendation given is to use exactly this guard for backwards
> compatibility.
glibc-ports:
sysdeps/arm/sysdep.h:
#if (!defined (__ARM_ARCH_2__) && !defined (__ARM_ARCH_3__) \
&& !defined (__ARM_ARCH_3M__) && !defined (__ARM_ARCH_4__))
# define __USE_BX__
#endif
sysdeps/arm/dl-machine.h:
#if defined(__USE_BX__)
#define BX(x) "bx\t" #x
#else
#define BX(x) "mov\tpc, " #x
#endif
>
> I'm cc:ing Dave Martin from ARM who drafted this porting guide. Dave, was
> there some other reason besides instruction compatibility to prefer the
> original "mov pc,lr" on armv4t, or is this simply a miscopy?
>
> > > mov pc, lr
> > > +#else
> > > + bx lr
> > > +#endif
>
> Thanks,
> --
> Steve Langasek Give me a lever long enough and a Free OS
> Debian Developer to set it on, and I can move the world.
> Ubuntu Developer http://www.debian.org/
> slangasek at ubuntu.com vorlon at debian.org
--
Kirill A. Shutemov
^ permalink raw reply
* [PATCH 2/2] ARM: remove the 4x expansion presumption while decompressing the kernel
From: Grant Likely @ 2011-02-17 0:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1297892343-29064-2-git-send-email-nico@fluxnic.net>
On Wed, Feb 16, 2011 at 04:39:03PM -0500, Nicolas Pitre wrote:
> We currently presume a 4x expansion to guess the decompressed kernel size
> in order to determine if the decompressed kernel is in conflict with
> the location where zImage is loaded. This guess may cause many issues
> by overestimating the final kernel image size:
>
> - This may force a needless relocation if the location of zImage was
> fine, wasting some precious microseconds of boot time.
>
> - The relocation may be located way too far, possibly overwriting the
> initrd image in RAM.
>
> - If the kernel image includes a large already-compressed initramfs image
> then the problem is even more exacerbated.
>
> And if by some strange means the 4x guess is too low then we may overwrite
> ourselves with the decompressed image.
>
> So let's use the exact decompressed kernel image size instead. For that
> we need to rely on the stat command, but this is hardly a new build
> dependency as the kernel already depends on many commands provided by
> the same coreutils package where stat is found to be built.
>
> Signed-off-by: Nicolas Pitre <nicolas.pitre@linaro.org>
> ---
> arch/arm/boot/compressed/Makefile | 4 +++-
> arch/arm/boot/compressed/vmlinux.lds.in | 3 ---
> 2 files changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/boot/compressed/Makefile b/arch/arm/boot/compressed/Makefile
> index 0a8f748..9d328be 100644
> --- a/arch/arm/boot/compressed/Makefile
> +++ b/arch/arm/boot/compressed/Makefile
> @@ -83,9 +83,11 @@ endif
> EXTRA_CFLAGS := -fpic -fno-builtin
> EXTRA_AFLAGS := -Wa,-march=all
>
> +# Provide size of uncompressed kernel to the decompressor via a linker symbol.
> +LDFLAGS_vmlinux := --defsym _image_size=$(shell stat -c "%s" $(obj)/../Image)
Patch looks good to me, but on a related note, I'm looking for a way
to also find the end of .bss.
When John looks at adding support for appending an initrd and/or dtb
to the zimage, it will be important to make sure the start of the
initrd/dtb does not overlap the ram the kernel is expecting to be
empty and available. I was thinking about simply grepping System.map
for __end and doing some sed magic to extract the offset from the
beginning of the kernel.
Do you think that is sufficient to protect appended data images?
^ permalink raw reply
* [klibc] fwd: fix up ARM assembly to use 'bx lr' in place of 'mov pc, lr'.
From: Khem Raj @ 2011-02-17 0:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110216235019.GA17674@shutemov.name>
On Wed, Feb 16, 2011 at 3:50 PM, Kirill A. Shutemov
<kirill@shutemov.name> wrote:
> On Thu, Feb 17, 2011 at 12:06:48AM +0100, maximilian attems wrote:
>> hello vorlon,
>>
>> got notified of your patch,
>> will apply next days upstream unless some critiques are voiced on ml.
>> thanks.
>>
>> --
>> maks
>>
>>
>> ----- Forwarded message from Steve Langasek <steve.langasek@canonical.com> -----
>>
>> Date: Wed, 16 Feb 2011 22:05:42 -0000
>> From: Steve Langasek <steve.langasek@canonical.com>
>> Subject: [Bug 527720] Re: thumb2 porting issues identified: klibc uses mov.*pc
>>
>>
>> I've also touched it up to be mergeable with Debian (support v4t builds
>> with #ifdef).
>>
>> Confirmed that installing the resulting klibc packages on my beagleboard
>> gives me a successfully-booting initramfs with klibc; and the
>> vfork/setjmptest test cases all pass in the klibc package tree.
>>
>> Fixes: https://bugs.launchpad.net/ubuntu/+source/klibc/+bug/527720
>>
>> --- klibc-1.5.20.orig/usr/klibc/arch/arm/vfork.S
>> +++ klibc-1.5.20/usr/klibc/arch/arm/vfork.S
>> @@ -25,7 +25,11 @@ vfork:
>> ? ? ? ? ?ldrcs ? ? ? ?r3, 1f
>> ? ? ? ? ?mvncs ? ? ? ?r0, #0
>> ? ? ? ? ?strcs ? ? ? ?r2, [r3]
>> +#if defined (___ARM_ARCH_4T__) || defined (__ARM_ARCH_4__)
>
> NAK. ARMv4T supports bx intruction. ARMv4 doesn't.
Does ARMv4t support BX lr ?
>
>> ? ? ? mov ? ? pc, lr
>> +#else
>> + ? ? bx ? ? ?lr
>> +#endif
>>
>> ? ? ? .balign 4
>> ?1:
>> @@ -49,7 +53,11 @@ vfork:
>> ? ? ? str ? ? r2, [r1]
>> ? ? ? neg ? ? r0, r0
>> ?1:
>> +#if defined (___ARM_ARCH_4T__) || defined (__ARM_ARCH_4__)
>> ? ? ? mov ? ? pc, lr
>> +#else
>> + ? ? bx ? ? ?lr
>> +#endif
>>
>> ? ? ? .balign 4
>> ?2:
>> --- klibc-1.5.20.orig/usr/klibc/arch/arm/setjmp.S
>> +++ klibc-1.5.20/usr/klibc/arch/arm/setjmp.S
>> @@ -29,7 +29,11 @@
>> ?setjmp:
>> ? ? ? stmia ? r0, {r4, r5, r6, r7, r8, r9, r10, fp, sp, lr}
>> ? ? ? mov ? ? r0, #0
>> +#if defined (___ARM_ARCH_4T__) || defined (__ARM_ARCH_4__)
>> ? ? ? mov ? ? pc, lr
>> +#else
>> + ? ? bx ? ? ?lr
>> +#endif
>> ? ? ? .size setjmp,.-setjmp
>>
>> ? ? ? .text
>> @@ -39,7 +43,11 @@ setjmp:
>> ?longjmp:
>> ? ? ? ldmia ? r0, {r4, r5, r6, r7, r8, r9, r10, fp, sp, lr}
>> ? ? ? mov ? ? r0, r1
>> +#if defined (___ARM_ARCH_4T__) || defined (__ARM_ARCH_4__)
>> ? ? ? mov ? ? pc, lr
>> +#else
>> + ? ? bx ? ? ?lr
>> +#endif
>> ? ? ? .size longjmp,.-longjmp
>>
>> ?#else /* __thumb__ */
>> @@ -75,7 +83,11 @@ setjmp:
>> ? ? ? mov ? ? r7, sp
>> ? ? ? stmia ? r0!, {r3, r4, r5, r6, r7}
>> ? ? ? mov ? ? r0, #0
>> +#if defined (___ARM_ARCH_4T__) || defined (__ARM_ARCH_4__)
>> ? ? ? mov ? ? pc, lr
>> +#else
>> + ? ? bx ? ? ?lr
>> +#endif
>> ? ? ? .size setjmp,.-setjmp
>>
>> ? ? ? .text
>> @@ -96,7 +108,11 @@ longjmp:
>> ? ? ? mov ? ? r0, r1
>> ? ? ? bne ? ? 1f
>> ? ? ? mov ? ? r0, #1
>> +#if defined (___ARM_ARCH_4T__) || defined (__ARM_ARCH_4__)
>> ?1: ? mov ? ? pc, r3
>> +#else
>> +1: ? bx ? ? ?r3
>> +#endif
>> ? ? ? .size longjmp,.-longjmp
>>
>> ?#endif /* __thumb__ */
>>
>> _______________________________________________
>> klibc mailing list
>> klibc at zytor.com
>> http://www.zytor.com/mailman/listinfo/klibc
>
> --
> ?Kirill A. Shutemov
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
^ permalink raw reply
* [klibc] fwd: fix up ARM assembly to use 'bx lr' in place of 'mov pc, lr'.
From: Steve Langasek @ 2011-02-17 0:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110216235019.GA17674@shutemov.name>
Thanks for forwarding this on, maks.
On Thu, Feb 17, 2011 at 01:50:19AM +0200, Kirill A. Shutemov wrote:
> > Date: Wed, 16 Feb 2011 22:05:42 -0000
> > From: Steve Langasek <steve.langasek@canonical.com>
> > Subject: [Bug 527720] Re: thumb2 porting issues identified: klibc uses mov.*pc
> > I've also touched it up to be mergeable with Debian (support v4t builds
> > with #ifdef).
> > Confirmed that installing the resulting klibc packages on my beagleboard
> > gives me a successfully-booting initramfs with klibc; and the
> > vfork/setjmptest test cases all pass in the klibc package tree.
> > Fixes: https://bugs.launchpad.net/ubuntu/+source/klibc/+bug/527720
> > --- klibc-1.5.20.orig/usr/klibc/arch/arm/vfork.S
> > +++ klibc-1.5.20/usr/klibc/arch/arm/vfork.S
> > @@ -25,7 +25,11 @@ vfork:
> > ldrcs r3, 1f
> > mvncs r0, #0
> > strcs r2, [r3]
> > +#if defined (___ARM_ARCH_4T__) || defined (__ARM_ARCH_4__)
> NAK. ARMv4T supports bx intruction. ARMv4 doesn't.
I see from
https://wiki.ubuntu.com/ARM/Thumb2PortingHowto#Identifying%20the%20Target%20Architecture
that you are correct - but then in
https://wiki.ubuntu.com/ARM/Thumb2PortingHowto#Detailed%20Instruction%20Behaviour
the recommendation given is to use exactly this guard for backwards
compatibility.
I'm cc:ing Dave Martin from ARM who drafted this porting guide. Dave, was
there some other reason besides instruction compatibility to prefer the
original "mov pc,lr" on armv4t, or is this simply a miscopy?
> > mov pc, lr
> > +#else
> > + bx lr
> > +#endif
Thanks,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slangasek at ubuntu.com vorlon at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 828 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20110216/ff3d096d/attachment.sig>
^ permalink raw reply
* [klibc] fwd: fix up ARM assembly to use 'bx lr' in place of 'mov pc, lr'.
From: Kirill A. Shutemov @ 2011-02-16 23:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110216230648.GA7649@stro.at>
On Thu, Feb 17, 2011 at 12:06:48AM +0100, maximilian attems wrote:
> hello vorlon,
>
> got notified of your patch,
> will apply next days upstream unless some critiques are voiced on ml.
> thanks.
>
> --
> maks
>
>
> ----- Forwarded message from Steve Langasek <steve.langasek@canonical.com> -----
>
> Date: Wed, 16 Feb 2011 22:05:42 -0000
> From: Steve Langasek <steve.langasek@canonical.com>
> Subject: [Bug 527720] Re: thumb2 porting issues identified: klibc uses mov.*pc
>
>
> I've also touched it up to be mergeable with Debian (support v4t builds
> with #ifdef).
>
> Confirmed that installing the resulting klibc packages on my beagleboard
> gives me a successfully-booting initramfs with klibc; and the
> vfork/setjmptest test cases all pass in the klibc package tree.
>
> Fixes: https://bugs.launchpad.net/ubuntu/+source/klibc/+bug/527720
>
> --- klibc-1.5.20.orig/usr/klibc/arch/arm/vfork.S
> +++ klibc-1.5.20/usr/klibc/arch/arm/vfork.S
> @@ -25,7 +25,11 @@ vfork:
> ldrcs r3, 1f
> mvncs r0, #0
> strcs r2, [r3]
> +#if defined (___ARM_ARCH_4T__) || defined (__ARM_ARCH_4__)
NAK. ARMv4T supports bx intruction. ARMv4 doesn't.
> mov pc, lr
> +#else
> + bx lr
> +#endif
>
> .balign 4
> 1:
> @@ -49,7 +53,11 @@ vfork:
> str r2, [r1]
> neg r0, r0
> 1:
> +#if defined (___ARM_ARCH_4T__) || defined (__ARM_ARCH_4__)
> mov pc, lr
> +#else
> + bx lr
> +#endif
>
> .balign 4
> 2:
> --- klibc-1.5.20.orig/usr/klibc/arch/arm/setjmp.S
> +++ klibc-1.5.20/usr/klibc/arch/arm/setjmp.S
> @@ -29,7 +29,11 @@
> setjmp:
> stmia r0, {r4, r5, r6, r7, r8, r9, r10, fp, sp, lr}
> mov r0, #0
> +#if defined (___ARM_ARCH_4T__) || defined (__ARM_ARCH_4__)
> mov pc, lr
> +#else
> + bx lr
> +#endif
> .size setjmp,.-setjmp
>
> .text
> @@ -39,7 +43,11 @@ setjmp:
> longjmp:
> ldmia r0, {r4, r5, r6, r7, r8, r9, r10, fp, sp, lr}
> mov r0, r1
> +#if defined (___ARM_ARCH_4T__) || defined (__ARM_ARCH_4__)
> mov pc, lr
> +#else
> + bx lr
> +#endif
> .size longjmp,.-longjmp
>
> #else /* __thumb__ */
> @@ -75,7 +83,11 @@ setjmp:
> mov r7, sp
> stmia r0!, {r3, r4, r5, r6, r7}
> mov r0, #0
> +#if defined (___ARM_ARCH_4T__) || defined (__ARM_ARCH_4__)
> mov pc, lr
> +#else
> + bx lr
> +#endif
> .size setjmp,.-setjmp
>
> .text
> @@ -96,7 +108,11 @@ longjmp:
> mov r0, r1
> bne 1f
> mov r0, #1
> +#if defined (___ARM_ARCH_4T__) || defined (__ARM_ARCH_4__)
> 1: mov pc, r3
> +#else
> +1: bx r3
> +#endif
> .size longjmp,.-longjmp
>
> #endif /* __thumb__ */
>
> _______________________________________________
> klibc mailing list
> klibc at zytor.com
> http://www.zytor.com/mailman/listinfo/klibc
--
Kirill A. Shutemov
^ permalink raw reply
* fwd: [klibc] fix up ARM assembly to use 'bx lr' in place of 'mov pc, lr'.
From: maximilian attems @ 2011-02-16 23:06 UTC (permalink / raw)
To: linux-arm-kernel
hello vorlon,
got notified of your patch,
will apply next days upstream unless some critiques are voiced on ml.
thanks.
--
maks
----- Forwarded message from Steve Langasek <steve.langasek@canonical.com> -----
Date: Wed, 16 Feb 2011 22:05:42 -0000
From: Steve Langasek <steve.langasek@canonical.com>
Subject: [Bug 527720] Re: thumb2 porting issues identified: klibc uses mov.*pc
I've also touched it up to be mergeable with Debian (support v4t builds
with #ifdef).
Confirmed that installing the resulting klibc packages on my beagleboard
gives me a successfully-booting initramfs with klibc; and the
vfork/setjmptest test cases all pass in the klibc package tree.
Fixes: https://bugs.launchpad.net/ubuntu/+source/klibc/+bug/527720
--- klibc-1.5.20.orig/usr/klibc/arch/arm/vfork.S
+++ klibc-1.5.20/usr/klibc/arch/arm/vfork.S
@@ -25,7 +25,11 @@ vfork:
ldrcs r3, 1f
mvncs r0, #0
strcs r2, [r3]
+#if defined (___ARM_ARCH_4T__) || defined (__ARM_ARCH_4__)
mov pc, lr
+#else
+ bx lr
+#endif
.balign 4
1:
@@ -49,7 +53,11 @@ vfork:
str r2, [r1]
neg r0, r0
1:
+#if defined (___ARM_ARCH_4T__) || defined (__ARM_ARCH_4__)
mov pc, lr
+#else
+ bx lr
+#endif
.balign 4
2:
--- klibc-1.5.20.orig/usr/klibc/arch/arm/setjmp.S
+++ klibc-1.5.20/usr/klibc/arch/arm/setjmp.S
@@ -29,7 +29,11 @@
setjmp:
stmia r0, {r4, r5, r6, r7, r8, r9, r10, fp, sp, lr}
mov r0, #0
+#if defined (___ARM_ARCH_4T__) || defined (__ARM_ARCH_4__)
mov pc, lr
+#else
+ bx lr
+#endif
.size setjmp,.-setjmp
.text
@@ -39,7 +43,11 @@ setjmp:
longjmp:
ldmia r0, {r4, r5, r6, r7, r8, r9, r10, fp, sp, lr}
mov r0, r1
+#if defined (___ARM_ARCH_4T__) || defined (__ARM_ARCH_4__)
mov pc, lr
+#else
+ bx lr
+#endif
.size longjmp,.-longjmp
#else /* __thumb__ */
@@ -75,7 +83,11 @@ setjmp:
mov r7, sp
stmia r0!, {r3, r4, r5, r6, r7}
mov r0, #0
+#if defined (___ARM_ARCH_4T__) || defined (__ARM_ARCH_4__)
mov pc, lr
+#else
+ bx lr
+#endif
.size setjmp,.-setjmp
.text
@@ -96,7 +108,11 @@ longjmp:
mov r0, r1
bne 1f
mov r0, #1
+#if defined (___ARM_ARCH_4T__) || defined (__ARM_ARCH_4__)
1: mov pc, r3
+#else
+1: bx r3
+#endif
.size longjmp,.-longjmp
#endif /* __thumb__ */
^ permalink raw reply
* [RFC] MMC: error handling improvements
From: Brian Swetland @ 2011-02-16 23:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTimQqGVTwUv4ywQnmd4Z1Ur4vWk2sK5+ZLa4mmTs@mail.gmail.com>
On Wed, Feb 16, 2011 at 1:01 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
> 2011/2/16 David Brown <davidb@codeaurora.org>:
>>?The driver doesn't directly
>> access the registers of the controller, but all accesses go through a
>> custom DMA engine.
>> (...)
>> The SDCC block is shared between
>> the modem processor and the processor running Linux. ?If the driver
>> doesn't go through the DMA engine, which coordinates this, the registers
>> will be stomped on by the other CPU whenever it decides to access it's
>> parts of the flash device.
>
> That's significant, I agree. That the DMA engine is custom
> instead of using the <linux/dmaengine.h> interface is not
> making things easier, but it's another issue. If it did, I think it
> could quite easily use mmci.c.
>
> At the same time what you're saying sounds very weird:
> the ios handler in mmc_sdcc does not request any DMA
> channel before messing with the hardware, it simply just write
> into registers very much in the style of mmci.c. Wouldn't that
> disturb any simultaneous access to the MMC from another
> CPU?
On MSM7x01,7x2x,8x50,8x55,7x30 the overall design involves both the
baseband cpu (running AMSS) and the apps cpu (running Linux) sharing a
single SDCC to read/write different partitions on NAND.
The way register access for the SDCC is synchronized between these two
cores is by using a locking primitive built into the MSM DMA
controller. If you don't use this indirect access model (via DMA
transactions to the registers), you end up tripping over the baseband
or the other way 'round. It's not fun.
Later Qualcomm chipsets move away from this model (yay) and that
should simplify things quite a bit.
Brian
>
> The DMA code path doesn't look one bit different from
> what we currently do for the generic DMA engine in
> mmci.c, it sets up a DMA job from the sglist in the datapath,
> but maybe I'm not looking close enough?
>
>> I suspect the changes to mmci would be fairly drastic.
>
> I don't think so, but the changes to the DMA engine
> (I guess mach-msm/dma.c) would potentially be pretty drastic,
> apart from just moving the thing to drivers/dma.
>
> Actually when I look at the code in msm_sdcc.c it looks
> like some of the code we usually centralize into the
> DMA engine (like the thing iterating over a sglist and
> packing it into some custom struct called "box") is instead
> spread out in the client drivers.
>
> I just wanted to raise the issue because I see that the
> msm_sdcc driver is trying to e.g. synchronize against
> dataend signals and such stuff that we've worked with
> recently in mmci.c, and I really think it would be in the
> MSM platforms best interest to use this driver rather than
> its own.
>
> Yours,
> Linus Walleij
>
> _______________________________________________
> 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 00/11] OMAP2+: clock: add clockfw autoidle for iclks, OMAP2xxx
From: Paul Walmsley @ 2011-02-16 23:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <43af56d25809fa616f0e17d7e641ebc0@mail.gmail.com>
On Wed, 16 Feb 2011, Rajendra Nayak wrote:
> Boot-tested on 3430sdp/4430sdp, with CONFIG_PM and with !CONFIG_PM.
> suspend-offmode tested on 3430sdp and suspend-retmode on 4430sdp (with
> some out-of-tree patches)
Thanks, will add Tested-by:s.
> Dynamic idle testing on 3430sdp showed me some very jerky debug console
> the moment a 'echo 1 > /debug/pm_debug/sleep_while_idle' is done. This
> however seems to be the case even on 2.6.38-rc4 and not related to the
> current patch series.
Does enabling CONFIG_OMAP2_DSS resolve the problem you're seeing?
> Will debug further, but seems to some 3430sdp specific issue, since you
> did not see it on Beagleboard and seems it is not seen on OMAP3 zoom's
> either. Just out of curiosity, what dynamic-idle state where you able to
> achieve on Beagle?
Full chip off. I use omap2plus_defconfig, sometimes with CONFIG_OMAP2_DSS
depending on personal mood and what's being tested. I boot to a shell and
run the commands at the end of this message (some of which are probably
superfluous).
- Paul
echo 1 > /debug/pm_debug/sleep_while_idle
echo 1 > /debug/pm_debug/enable_off_mode
echo 5 > /sys/devices/platform/omap/omap_uart.0/sleep_timeout
echo 5 > /sys/devices/platform/omap/omap_uart.1/sleep_timeout
echo 5 > /sys/devices/platform/omap/omap_uart.2/sleep_timeout
echo enabled > /sys/devices/platform/omap/omap_uart.0/tty/ttyO0/power/wakeup
echo enabled > /sys/devices/platform/omap/omap_uart.1/tty/ttyO1/power/wakeup
echo enabled > /sys/devices/platform/omap/omap_uart.2/tty/ttyO2/power/wakeup
^ permalink raw reply
* [RFC] orion5x: TS-78XX support for FPGA generated doorbell IRQ's
From: Alexander Clouter @ 2011-02-16 22:45 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
The TS-7800 board[1] FPGA can generate interrupts for devices connected
to the PC/104 header. This works by triggering the doorbell IRQ, which
seems typically to not be used on other orion5x boards seen in the wild.
The following patch bumps NR_IRQS from 64 to 96 for the TS-7800 and
calls upon the rather nifty set_irq_chained_handler() framework (the
vendor of the board in their tree do hairy things in assembler).
The code has been tested with an Ethernet card driven off ax88796.c, but
I am looking for feedback if this is the Right Way(tm) to do this, and
if there is a better way.
Bear in mind that fpga_addr could vary if people wish to put their own
bitstream on the FPGA and generate IRQ's in a similar fashion; which is
why there is a switch statement present[2] as the VHDL coder might want
to use different addresses.
Cheers
[1] http://www.embeddedarm.com/products/board-detail.php?product=TS-7800
[2] I am planning at some stage to rework all the FPGA related bits to
use either MFD or even the new ARM Device Tree framework
---
arch/arm/mach-orion5x/addr-map.c | 2 -
arch/arm/mach-orion5x/include/mach/irqs.h | 10 ++-
arch/arm/mach-orion5x/include/mach/orion5x.h | 10 ++
arch/arm/mach-orion5x/irq.c | 3 +-
arch/arm/mach-orion5x/ts78xx-fpga.h | 2 +
arch/arm/mach-orion5x/ts78xx-setup.c | 121 ++++++++++++++++++++++++++
6 files changed, 143 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-orion5x/addr-map.c b/arch/arm/mach-orion5x/addr-map.c
index 1a5d6a0..1fa730c 100644
--- a/arch/arm/mach-orion5x/addr-map.c
+++ b/arch/arm/mach-orion5x/addr-map.c
@@ -60,14 +60,12 @@
/*
* Helpers to get DDR bank info
*/
-#define ORION5X_DDR_REG(x) (ORION5X_DDR_VIRT_BASE | (x))
#define DDR_BASE_CS(n) ORION5X_DDR_REG(0x1500 + ((n) << 3))
#define DDR_SIZE_CS(n) ORION5X_DDR_REG(0x1504 + ((n) << 3))
/*
* CPU Address Decode Windows registers
*/
-#define ORION5X_BRIDGE_REG(x) (ORION5X_BRIDGE_VIRT_BASE | (x))
#define CPU_WIN_CTRL(n) ORION5X_BRIDGE_REG(0x000 | ((n) << 4))
#define CPU_WIN_BASE(n) ORION5X_BRIDGE_REG(0x004 | ((n) << 4))
#define CPU_WIN_REMAP_LO(n) ORION5X_BRIDGE_REG(0x008 | ((n) << 4))
diff --git a/arch/arm/mach-orion5x/include/mach/irqs.h b/arch/arm/mach-orion5x/include/mach/irqs.h
index a6fa9d8..677b594 100644
--- a/arch/arm/mach-orion5x/include/mach/irqs.h
+++ b/arch/arm/mach-orion5x/include/mach/irqs.h
@@ -54,7 +54,13 @@
#define IRQ_ORION5X_GPIO_START 32
#define NR_GPIO_IRQS 32
-#define NR_IRQS (IRQ_ORION5X_GPIO_START + NR_GPIO_IRQS)
-
+#ifdef CONFIG_MACH_TS78XX
+# define NR_TS78XX_FPGA_IRQS 32
+# define FPGA_IRQ(irq) (IRQ_ORION5X_GPIO_START + NR_GPIO_IRQS + irq)
+#
+# define NR_IRQS (IRQ_ORION5X_GPIO_START + NR_GPIO_IRQS + NR_TS78XX_FPGA_IRQS)
+#else
+# define NR_IRQS (IRQ_ORION5X_GPIO_START + NR_GPIO_IRQS)
+#endif
#endif
diff --git a/arch/arm/mach-orion5x/include/mach/orion5x.h b/arch/arm/mach-orion5x/include/mach/orion5x.h
index 2d87665..5a1711b 100644
--- a/arch/arm/mach-orion5x/include/mach/orion5x.h
+++ b/arch/arm/mach-orion5x/include/mach/orion5x.h
@@ -69,6 +69,7 @@
******************************************************************************/
#define ORION5X_DDR_VIRT_BASE (ORION5X_REGS_VIRT_BASE | 0x00000)
+#define ORION5X_DDR_REG(x) (ORION5X_DDR_VIRT_BASE | (x))
#define ORION5X_DEV_BUS_PHYS_BASE (ORION5X_REGS_PHYS_BASE | 0x10000)
#define ORION5X_DEV_BUS_VIRT_BASE (ORION5X_REGS_VIRT_BASE | 0x10000)
@@ -81,6 +82,7 @@
#define UART1_VIRT_BASE (ORION5X_DEV_BUS_VIRT_BASE | 0x2100)
#define ORION5X_BRIDGE_VIRT_BASE (ORION5X_REGS_VIRT_BASE | 0x20000)
+#define ORION5X_BRIDGE_REG(x) (ORION5X_BRIDGE_VIRT_BASE | (x))
#define ORION5X_PCI_VIRT_BASE (ORION5X_REGS_VIRT_BASE | 0x30000)
@@ -120,6 +122,14 @@
#define DEV_BUS_INT_MASK ORION5X_DEV_BUS_REG(0x4d4)
/*******************************************************************************
+ * CPU Doorbell Registers
+ ******************************************************************************/
+#define H2C_DOORBELL_REG ORION5X_BRIDGE_REG(0x400)
+#define H2C_DOORBELL_MASK_REG ORION5X_BRIDGE_REG(0x404)
+#define C2H_DOORBELL_REG ORION5X_BRIDGE_REG(0x408)
+#define C2H_DOORBELL_MASK_REG ORION5X_BRIDGE_REG(0x40c)
+
+/*******************************************************************************
* Supported Devices & Revisions
******************************************************************************/
/* Orion-1 (88F5181) and Orion-VoIP (88F5181L) */
diff --git a/arch/arm/mach-orion5x/irq.c b/arch/arm/mach-orion5x/irq.c
index d7512b9..d5ba5b4 100644
--- a/arch/arm/mach-orion5x/irq.c
+++ b/arch/arm/mach-orion5x/irq.c
@@ -43,7 +43,8 @@ void __init orion5x_init_irq(void)
* Register chained level handlers for GPIO IRQs by default.
* User can use set_type() if he wants to use edge types handlers.
*/
- for (i = IRQ_ORION5X_GPIO_START; i < NR_IRQS; i++) {
+ for (i = IRQ_ORION5X_GPIO_START;
+ i < IRQ_ORION5X_GPIO_START + NR_GPIO_IRQS; i++) {
set_irq_chip(i, &orion_gpio_irq_chip);
set_irq_handler(i, handle_level_irq);
irq_desc[i].status |= IRQ_LEVEL;
diff --git a/arch/arm/mach-orion5x/ts78xx-fpga.h b/arch/arm/mach-orion5x/ts78xx-fpga.h
index 791f754..8bb0331 100644
--- a/arch/arm/mach-orion5x/ts78xx-fpga.h
+++ b/arch/arm/mach-orion5x/ts78xx-fpga.h
@@ -26,6 +26,8 @@ struct fpga_device {
};
struct fpga_devices {
+ struct fpga_device doorbell_irq;
+
/* Technologic Systems */
struct fpga_device ts_rtc;
struct fpga_device ts_nand;
diff --git a/arch/arm/mach-orion5x/ts78xx-setup.c b/arch/arm/mach-orion5x/ts78xx-setup.c
index d3e29f8..592773a 100644
--- a/arch/arm/mach-orion5x/ts78xx-setup.c
+++ b/arch/arm/mach-orion5x/ts78xx-setup.c
@@ -22,6 +22,8 @@
#include <asm/mach/arch.h>
#include <asm/mach/map.h>
#include <mach/orion5x.h>
+#include <linux/irq.h>
+#include <mach/bridge-regs.h>
#include "common.h"
#include "mpp.h"
#include "ts78xx-fpga.h"
@@ -62,6 +64,112 @@ void __init ts78xx_map_io(void)
}
/*****************************************************************************
+ * IRQ
+ ****************************************************************************/
+static void ts78xx_irq_ack(u32 irq)
+{
+ u32 addr;
+
+ addr = readl(H2C_DOORBELL_REG);
+ addr &= ~(1 << (irq - FPGA_IRQ(0)));
+ writel(addr, H2C_DOORBELL_REG);
+}
+
+static void ts78xx_irq_mask(u32 irq)
+{
+ void __iomem *fpgaaddr = get_irq_chip_data(irq);
+ unsigned long reg;
+
+ reg = readl(H2C_DOORBELL_MASK_REG);
+ reg &= ~(1 << (irq - FPGA_IRQ(0)));
+ writel(reg, H2C_DOORBELL_MASK_REG);
+
+ reg = readl(fpgaaddr);
+ reg &= ~(1 << (irq - FPGA_IRQ(0)));
+ writel(reg, fpgaaddr);
+}
+
+static void ts78xx_irq_unmask(u32 irq)
+{
+ void __iomem *fpgaaddr = get_irq_chip_data(irq);
+ unsigned long reg;
+
+ reg = readl(H2C_DOORBELL_MASK_REG);
+ reg |= 1 << (irq - FPGA_IRQ(0));
+ writel(reg, H2C_DOORBELL_MASK_REG);
+
+ reg = readl(H2C_DOORBELL_REG);
+ reg &= ~(1 << (irq - FPGA_IRQ(0)));
+ writel(reg, H2C_DOORBELL_REG);
+
+ reg = readl(fpgaaddr);
+ reg |= 1 << (irq - FPGA_IRQ(0));
+ writel(reg, fpgaaddr);
+}
+
+static struct irq_chip ts78xx_irq_chip = {
+ .name = "ts78xx_irq",
+ .ack = ts78xx_irq_ack,
+ .mask = ts78xx_irq_mask,
+ .unmask = ts78xx_irq_unmask,
+};
+
+static void ts78xx_irq(unsigned int irq, struct irq_desc *desc)
+{
+ unsigned long reg = readl(H2C_DOORBELL_REG);
+
+ for_each_set_bit(irq, ®, 32)
+ generic_handle_irq(FPGA_IRQ(irq));
+}
+
+static int ts78xx_doorbell_irq_load(void)
+{
+ void __iomem *fpgaaddr;
+ unsigned int irq;
+
+ switch (ts78xx_fpga.id) {
+ case TS7800_REV_1:
+ case TS7800_REV_2:
+ case TS7800_REV_3:
+ case TS7800_REV_4:
+ case TS7800_REV_5:
+ case TS7800_REV_6:
+ case TS7800_REV_7:
+ case TS7800_REV_8:
+ case TS7800_REV_9:
+ fpgaaddr = (void __iomem *)(TS78XX_FPGA_REGS_VIRT_BASE | 0x204);
+ break;
+ default:
+ return -ENODEV;
+ }
+
+ for (irq = FPGA_IRQ(0); irq < FPGA_IRQ(NR_TS78XX_FPGA_IRQS); irq++) {
+ set_irq_chip(irq, &ts78xx_irq_chip);
+ set_irq_chip_data(irq, fpgaaddr);
+ set_irq_handler(irq, handle_level_irq);
+ irq_desc[irq].status |= IRQ_LEVEL;
+ set_irq_flags(irq, IRQF_VALID);
+ }
+
+ set_irq_chained_handler(IRQ_ORION5X_DOORBELL_H2C, ts78xx_irq);
+
+ return 0;
+}
+
+static void ts78xx_doorbell_irq_unload(void)
+{
+ unsigned int irq;
+
+ set_irq_chained_handler(IRQ_ORION5X_DOORBELL_H2C, NULL);
+
+ for (irq = FPGA_IRQ(0); irq < FPGA_IRQ(NR_TS78XX_FPGA_IRQS); irq++) {
+ set_irq_flags(irq, 0);
+ set_irq_chip(irq, NULL);
+ set_irq_chip_data(irq, NULL);
+ }
+}
+
+/*****************************************************************************
* Ethernet
****************************************************************************/
static struct mv643xx_eth_platform_data ts78xx_eth_data = {
@@ -376,6 +484,7 @@ static void ts78xx_ts_rng_unload(void)
****************************************************************************/
static void ts78xx_fpga_devices_zero_init(void)
{
+ ts78xx_fpga.supports.doorbell_irq.init = 0;
ts78xx_fpga.supports.ts_rtc.init = 0;
ts78xx_fpga.supports.ts_nand.init = 0;
ts78xx_fpga.supports.ts_rng.init = 0;
@@ -394,11 +503,13 @@ static void ts78xx_fpga_supports(void)
case TS7800_REV_7:
case TS7800_REV_8:
case TS7800_REV_9:
+ ts78xx_fpga.supports.doorbell_irq.present = 1;
ts78xx_fpga.supports.ts_rtc.present = 1;
ts78xx_fpga.supports.ts_nand.present = 1;
ts78xx_fpga.supports.ts_rng.present = 1;
break;
default:
+ ts78xx_fpga.supports.doorbell_irq.present = 0;
ts78xx_fpga.supports.ts_rtc.present = 0;
ts78xx_fpga.supports.ts_nand.present = 0;
ts78xx_fpga.supports.ts_rng.present = 0;
@@ -409,6 +520,14 @@ static int ts78xx_fpga_load_devices(void)
{
int tmp, ret = 0;
+ if (ts78xx_fpga.supports.doorbell_irq.present == 1) {
+ tmp = ts78xx_doorbell_irq_load();
+ if (tmp) {
+ printk(KERN_INFO "TS-78xx: Doorbell IRQs not registered\n");
+ ts78xx_fpga.supports.doorbell_irq.present = 0;
+ }
+ ret |= tmp;
+ }
if (ts78xx_fpga.supports.ts_rtc.present == 1) {
tmp = ts78xx_ts_rtc_load();
if (tmp) {
@@ -441,6 +560,8 @@ static int ts78xx_fpga_unload_devices(void)
{
int ret = 0;
+ if (ts78xx_fpga.supports.doorbell_irq.present == 1)
+ ts78xx_doorbell_irq_unload();
if (ts78xx_fpga.supports.ts_rtc.present == 1)
ts78xx_ts_rtc_unload();
if (ts78xx_fpga.supports.ts_nand.present == 1)
--
1.7.2.3
^ permalink raw reply related
* [PATCH v2 5/7] omap: dpll: Enable all OMAP3/4 dpll autoidle late at boot
From: Paul Walmsley @ 2011-02-16 22:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ee3e93f406daf1a283b8d551f57933e3@mail.gmail.com>
Hi
After Rajendra's E-mail here:
http://marc.info/?l=linux-arm-kernel&m=129785498406128&w=2
upon looking further, mach-omap2/pm.c is compiled in for !CONFIG_PM.
This will be dealt with in a separate patch, but in the meantime, I
propose we enable clock autoidle if CONFIG_OMAP_RESET_CLOCKS is set.
(Really this config option should be called CONFIG_OMAP_DONT_BREAK_CLOCKFW
or CONFIG_OMAP_MAKE_POWER_MANAGEMENT_WORK, but all that, too, is a matter
for another patch.)
Here's what I'm proposing to use as a replacement; comments welcome. The
clk_autoidle_a_2.6.39 branch has been updated accordingly.
- Paul
From: Paul Walmsley <paul@pwsan.com>
Date: Mon, 14 Feb 2011 09:39:11 -0700
Subject: [PATCH] OMAP2+: clock: autoidle as many clocks as possible if CONFIG_OMAP_RESET_CLOCKS
Attempt to enable autoidle for as many clocks as possible in the
OMAP2+-common CONFIG_OMAP_RESET_CLOCKS code. Currently, this only
enables DPLL autoidle for OMAP3/4 DPLLs; but future patches will
enable autoidle for other clocks and the OMAP2 DPLL/APLLs.
In the long run, we should probably get rid of
CONFIG_OMAP_RESET_CLOCKS, and unconditionally run the code that it
selects. Otherwise, the state of the clock tree won't match the
hardware state - this could result in clocks being enabled or disabled
unpredictably.
Based on a patch by Rajendra Nayak <rnayak@ti.com> that did this in
the pm34xx.c/pm44xx.c code.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Rajendra Nayak <rnayak@ti.com>
---
arch/arm/mach-omap2/pm34xx.c | 17 -----------------
arch/arm/plat-omap/clock.c | 1 +
2 files changed, 1 insertions(+), 17 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 2f864e4..1fe2e73 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -814,23 +814,6 @@ static void __init prcm_setup_regs(void)
omap_ctrl_writel(OMAP3430_AUTOIDLE_MASK, OMAP2_CONTROL_SYSCONFIG);
/*
- * Set all plls to autoidle. This is needed until autoidle is
- * enabled by clockfw
- */
- omap2_cm_write_mod_reg(1 << OMAP3430_AUTO_IVA2_DPLL_SHIFT,
- OMAP3430_IVA2_MOD, CM_AUTOIDLE2);
- omap2_cm_write_mod_reg(1 << OMAP3430_AUTO_MPU_DPLL_SHIFT,
- MPU_MOD,
- CM_AUTOIDLE2);
- omap2_cm_write_mod_reg((1 << OMAP3430_AUTO_PERIPH_DPLL_SHIFT) |
- (1 << OMAP3430_AUTO_CORE_DPLL_SHIFT),
- PLL_MOD,
- CM_AUTOIDLE);
- omap2_cm_write_mod_reg(1 << OMAP3430ES2_AUTO_PERIPH2_DPLL_SHIFT,
- PLL_MOD,
- CM_AUTOIDLE2);
-
- /*
* Enable control of expternal oscillator through
* sys_clkreq. In the long run clock framework should
* take care of this.
diff --git a/arch/arm/plat-omap/clock.c b/arch/arm/plat-omap/clock.c
index 0ae0eae..2770ddd 100644
--- a/arch/arm/plat-omap/clock.c
+++ b/arch/arm/plat-omap/clock.c
@@ -446,6 +446,7 @@ static int __init clk_disable_unused(void)
return 0;
}
late_initcall(clk_disable_unused);
+late_initcall(omap_clk_enable_autoidle_all);
#endif
int __init clk_init(struct clk_functions * custom_clocks)
--
1.7.2.3
^ permalink raw reply related
* [PATCH] [ARM] update FPGA revisions for TS-7800
From: Alexander Clouter @ 2011-02-16 22:29 UTC (permalink / raw)
To: linux-arm-kernel
New FPGA revisions have been released and seen in the wild on the
platform, so it's time to update the list.
Signed-off-by: Alexander Clouter <alex@digriz.org.uk>
---
arch/arm/mach-orion5x/ts78xx-fpga.h | 4 ++++
arch/arm/mach-orion5x/ts78xx-setup.c | 4 ++++
2 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-orion5x/ts78xx-fpga.h b/arch/arm/mach-orion5x/ts78xx-fpga.h
index 37b3d48..791f754 100644
--- a/arch/arm/mach-orion5x/ts78xx-fpga.h
+++ b/arch/arm/mach-orion5x/ts78xx-fpga.h
@@ -11,6 +11,10 @@ enum fpga_ids {
TS7800_REV_3 = FPGAID(0x00b480, 0x03),
TS7800_REV_4 = FPGAID(0x00b480, 0x04),
TS7800_REV_5 = FPGAID(0x00b480, 0x05),
+ TS7800_REV_6 = FPGAID(0x00b480, 0x06),
+ TS7800_REV_7 = FPGAID(0x00b480, 0x07),
+ TS7800_REV_8 = FPGAID(0x00b480, 0x08),
+ TS7800_REV_9 = FPGAID(0x00b480, 0x09),
/* Unaffordable & Expensive */
UAE_DUMMY = FPGAID(0xffffff, 0x01),
diff --git a/arch/arm/mach-orion5x/ts78xx-setup.c b/arch/arm/mach-orion5x/ts78xx-setup.c
index c1c1cd0..7bed418 100644
--- a/arch/arm/mach-orion5x/ts78xx-setup.c
+++ b/arch/arm/mach-orion5x/ts78xx-setup.c
@@ -334,6 +334,10 @@ static void ts78xx_fpga_supports(void)
case TS7800_REV_3:
case TS7800_REV_4:
case TS7800_REV_5:
+ case TS7800_REV_6:
+ case TS7800_REV_7:
+ case TS7800_REV_8:
+ case TS7800_REV_9:
ts78xx_fpga.supports.ts_rtc.present = 1;
ts78xx_fpga.supports.ts_nand.present = 1;
ts78xx_fpga.supports.ts_rng.present = 1;
--
1.7.2.3
^ permalink raw reply related
* [PATCHv3] [ARM] orion5x: accelerate NAND on the TS-78xx
From: Alexander Clouter @ 2011-02-16 22:26 UTC (permalink / raw)
To: linux-arm-kernel
The NAND supports 32bit reads and writes so lets stop shunting 8bit
chunks across the bus.
Doing a dumb 'dd' benchmark, this increases performance roughly like so:
* read: 1.3MB/s to 3.4MB/s
* write: 614kB/s to 882kB/s
Changelog:
v3: added cast to first parameter of min() to remove gcc warnings
v2: used approach suggested by Russell King instead
<20110105003316.GJ24935@n2100.arm.linux.org.uk>
v1: initial release <20110104235158.GQ12386@chipmunk>
Signed-off-by: Alexander Clouter <alex@digriz.org.uk>
---
arch/arm/mach-orion5x/ts78xx-setup.c | 56 ++++++++++++++++++++++++++++++++++
1 files changed, 56 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-orion5x/ts78xx-setup.c b/arch/arm/mach-orion5x/ts78xx-setup.c
index c1c1cd0..4431309 100644
--- a/arch/arm/mach-orion5x/ts78xx-setup.c
+++ b/arch/arm/mach-orion5x/ts78xx-setup.c
@@ -191,6 +191,60 @@ static int ts78xx_ts_nand_dev_ready(struct mtd_info *mtd)
return readb(TS_NAND_CTRL) & 0x20;
}
+static void ts78xx_ts_nand_write_buf(struct mtd_info *mtd,
+ const uint8_t *buf, int len)
+{
+ struct nand_chip *chip = mtd->priv;
+ void __iomem *io_base = chip->IO_ADDR_W;
+ unsigned long off = ((unsigned long)buf & 3);
+ int sz;
+
+ if (off) {
+ sz = min((int) (4 - off), len);
+ writesb(io_base, buf, sz);
+ buf += sz;
+ len -= sz;
+ }
+
+ sz = len >> 2;
+ if (sz) {
+ u32 *buf32 = (u32 *)buf;
+ writesl(io_base, buf32, sz);
+ buf += sz << 2;
+ len -= sz << 2;
+ }
+
+ if (len)
+ writesb(io_base, buf, len);
+}
+
+static void ts78xx_ts_nand_read_buf(struct mtd_info *mtd,
+ uint8_t *buf, int len)
+{
+ struct nand_chip *chip = mtd->priv;
+ void __iomem *io_base = chip->IO_ADDR_R;
+ unsigned long off = ((unsigned long)buf & 3);
+ int sz;
+
+ if (off) {
+ sz = min((int) (4 - off), len);
+ readsb(io_base, buf, sz);
+ buf += sz;
+ len -= sz;
+ }
+
+ sz = len >> 2;
+ if (sz) {
+ u32 *buf32 = (u32 *)buf;
+ readsl(io_base, buf32, sz);
+ buf += sz << 2;
+ len -= sz << 2;
+ }
+
+ if (len)
+ readsb(io_base, buf, len);
+}
+
const char *ts_nand_part_probes[] = { "cmdlinepart", NULL };
static struct mtd_partition ts78xx_ts_nand_parts[] = {
@@ -233,6 +287,8 @@ static struct platform_nand_data ts78xx_ts_nand_data = {
*/
.cmd_ctrl = ts78xx_ts_nand_cmd_ctrl,
.dev_ready = ts78xx_ts_nand_dev_ready,
+ .write_buf = ts78xx_ts_nand_write_buf,
+ .read_buf = ts78xx_ts_nand_read_buf,
},
};
--
1.7.2.3
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox