* [PATCH 2/2] arm: omap: remove duplicated headers
From: Paul Walmsley @ 2011-01-16 18:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1295174783-4099-2-git-send-email-balbi@ti.com>
On Sun, 16 Jan 2011, Felipe Balbi wrote:
> A few headers are included twice, remove them.
>
> Found the following errors using make includecheck:
> arch/arm/mach-omap2/clock44xx_data.c: prm44xx.h is
> included more than once.
> arch/arm/mach-omap2/clockdomains44xx_data.c: cm1_44xx.h
> is included more than once.
> arch/arm/mach-omap2/clockdomains44xx_data.c: cm2_44xx.h
> is included more than once.
> arch/arm/mach-omap2/powerdomain2xxx_3xxx.c: prm-regbits-34xx.h
> is included more than once.
These are probably merge-related. I'll take this patch for 2.6.38-rc.
Thanks,
- Paul
^ permalink raw reply
* [PATCH] arm/tegra: Fix tegra irq_data conversion
From: Olof Johansson @ 2011-01-16 15:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110116102158.GC15575@mail.wantstofly.org>
On Sun, Jan 16, 2011 at 2:21 AM, Lennert Buytenhek
<buytenh@wantstofly.org> wrote:
> On Sat, Jan 15, 2011 at 10:41:27PM -0700, Grant Likely wrote:
>
>> Commit 37337a8d5e68d6e19075dbdb3acf4f1011dae972, "ARM: tegra: irq_data
>> conversion." missed changing one reference to 'irq' in the function
>> tegra_gpio_irq_set_type(). ?This patch fixes the build error.
>>
>> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
>
> Acked-by: Lennert Buytenhek <buytenh@secretlab.ca>
Acked-by: Olof Johansson <olof@lixom.net>
> I built this queue against all defconfigs, but there doesn't seem to
> be one for tegra at the moment, which is why I missed this.
Yep, planning on fixing this for .39.
-Olof
^ permalink raw reply
* [PATCH 2/2] arm: mx50_rdp: add i2c bus support
From: Richard Zhao @ 2011-01-16 15:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTinNe7+D9umDZjgBb+aVXnF75MjVP2JVD7ypC9TQ@mail.gmail.com>
Hi Jason,
On Sat, Jan 15, 2011 at 12:10:34AM +0800, Jason Liu wrote:
> Hi, Richard,
>
> 2011/1/14 Richard Zhao <linuxzsc@gmail.com>:
> > On Fri, Jan 14, 2011 at 10:27 PM, Jason Liu <liu.h.jason@gmail.com> wrote:
> >> Hi, Richard,
> >>
> >> 2011/1/14 Richard Zhao <richard.zhao@freescale.com>:
> >>> Signed-off-by: Richard Zhao <richard.zhao@freescale.com>
> >>> ---
> >>> ?arch/arm/mach-mx5/board-mx50_rdp.c ? ? ? ? ? | ? ?7 +++++++
> >>> ?arch/arm/mach-mx5/devices-mx50.h ? ? ? ? ? ? | ? ?3 +++
> >>
> >> We need align the naming convention with i.mx53/i.mx50 fordevices-mx50.h ,
> >> I have send out one patch for it.It seems not good when using devices-mx50.h
> >> while using devices-imx53 and devices-imx51.h in the same directory.
> >>
> >> I think we need use imx as much as possible since i.mx is FSL chip brand name.
> >>
> >> Sascha, please help merge the following patch if you don't have some
> >> comments about it.
> >> http://lists.arm.linux.org.uk/lurker/message/20110110.223149.e2d1fe51.en.html
> > I have comments on that thread too. I past here:
> > I noticed that too. Sometimes we use imx as part of file name or macro
> > name, but other times we use mx . We'd better make some rule that when
> > and where we suppose to use what.
> > I suggest we move all to mx for short. Reasons:
> > - For freescale internal, starting from mx5, we all use mx.
> > - macros in soc header files all use mx.
> > - soc header file name all use mx too.
> > - mach-types all use mx. (count in freescale board only)
>
> No, I prefer to use imx since imx is the chip brand and FSL IC doc
> stat it clearly it's i.mx.
> And the most important is to keep compatible, we had better keep the
> same naming convention.
> Otherwise, it will make the directory a little mess.
I don't care much what we use. I just think we'd better have a rule to tell
when which should be used.
Anyway, it's out of this patch.
Sascha/Uwe,
Is this patch series ok?
Thanks
Richard
>
> >
> > Thanks
> > Richard
> >>
> >> BR,
> >> Jason
> >>
> >>> _______________________________________________
> >>> linux-arm-kernel mailing list
> >>> linux-arm-kernel at lists.infradead.org
> >>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> >>>
> >>
> >
^ permalink raw reply
* State of LDP3430 platform
From: Thomas Weber @ 2011-01-16 15:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1101152028580.13225@utopia.booyaka.com>
Am 16.01.2011 05:32, schrieb Paul Walmsley:
> On Sat, 15 Jan 2011, Russell King - ARM Linux wrote:
>
>> On Sat, Jan 15, 2011 at 12:38:46PM -0700, Paul Walmsley wrote:
>>> On Fri, 14 Jan 2011, Tony Lindgren wrote:
>>>
>>>> * Paul Walmsley <paul@pwsan.com> [101207 19:30]:
>>>>> On Tue, 7 Dec 2010, Paul Walmsley wrote:
>>>>>
>>>>> Regarding the watchdog problem, unfortunately, I can't reproduce on the
>>>>> BeagleBoard with v2.6.37-rc5 with either omap2plus_defconfig or
>>>>> omap2plus_defconfig without CONFIG_WATCHDOG. If you send along your
>>>>> .config, one of us can try to reproduce the problem with it. Do the
>>>>> 2.6.38 hwmod and wdt patchsets fix the problem for .38, at least?
>>>> I've been seeing this on my omap4 panda. While debugging it, I left
>>>> u-boot console only running for a few minutes to see if that stays up.
>>>> It did.. And after doing that somehow now my panda boots all the way
>>>> and stays up. Weird.
>>> Hmmm, do you think the watchdog is what's killing it? I don't think
>>> leaving u-boot running would affect that?
>> Right, well, the LDP3430 (and probably all OMAP) is broken by my
>> init_sched_clock() changes because I gave up with testing on OMAP
>> platforms.
>>
>> Why does OMAP initialize its clock sources soo late, outside of
>> the timer initialization? This means you have no counter in place
>> (except for the jiffies counter) during early boot.
>>
>> Is there a reason why OMAP uniquely does this?
> I don't think so.
>
> Patch attached.
>
>
> - Paul
>
>
> [PATCH] OMAP: counter_32k: init clocksource as part of machine timer init
>
> Linus's master branch, currently at commit
> 1b59be2a6cdcb5a12e18d8315c07c94a624de48f ("Merge branch 'slab/urgent'
> of git://git.kernel.org/pub/scm/linux/kernel/git/penberg/slab-2.6"),
> crashes during boot on OMAP4430 ES2.0 Panda:
>
> [ 0.000000] OMAP clockevent source: GPTIMER1 at 32768 Hz
> [ 0.000000] Unable to handle kernel NULL pointer dereference at virtual address 00000000
> [ 0.000000] pgd = c0004000
> [ 0.000000] [00000000] *pgd=00000000
> [ 0.000000] Internal error: Oops: 80000005 [#1] SMP
> [ 0.000000] last sysfs file:
> [ 0.000000] Modules linked in:
> [ 0.000000] CPU: 0 Tainted: G W (2.6.37-07734-g2467802 #7)
> [ 0.000000] PC is at 0x0
> [ 0.000000] LR is at sched_clock_poll+0x2c/0x3c
> [ 0.000000] pc : [<00000000>] lr : [<c0060b74>] psr: 600001d3
> [ 0.000000] sp : c058bfd0 ip : c058a000 fp : 00000000
> [ 0.000000] r10: 00000000 r9 : 411fc092 r8 : 800330c8
> [ 0.000000] r7 : c05a08e0 r6 : c0034c48 r5 : c05ffc40 r4 : c0034c4c
> [ 0.000000] r3 : c05ffe6c r2 : c05a0bc0 r1 : c059f098 r0 : 00000000
> [ 0.000000] Flags: nZCv IRQs off FIQs off Mode SVC_32 ISA ARM Segment kernel
> [ 0.000000] Control: 10c53c7f Table: 8000404a DAC: 00000017
>
> This is due to the recent ARM init_sched_clock() changes and the late
> initialization of the counter_32k clock source:
>
> http://marc.info/?l=linux-omap&m=129513468605208&w=2
>
> Fix by initializing the counter_32k clocksource during the machine timer
> initialization.
>
> Reported-by: Russell King <rmk+kernel@arm.linux.org.uk>
> Signed-off-by: Paul Walmsley <paul@pwsan.com>
>
> ---
> arch/arm/mach-omap1/time.c | 7 +++++++
> arch/arm/mach-omap2/timer-gp.c | 10 ++++++++--
> arch/arm/plat-omap/counter_32k.c | 3 +--
> arch/arm/plat-omap/include/plat/common.h | 1 +
> 4 files changed, 17 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/mach-omap1/time.c b/arch/arm/mach-omap1/time.c
> index ed7a61f..6ec65e5 100644
> --- a/arch/arm/mach-omap1/time.c
> +++ b/arch/arm/mach-omap1/time.c
> @@ -244,6 +244,13 @@ static void __init omap_timer_init(void)
>
> omap_init_mpu_timer(rate);
> omap_init_clocksource(rate);
> + /*
> + * XXX Since this file seems to deal mostly with the MPU timer,
> + * this doesn't seem like the correct place for the sync timer
> + * clocksource init.
> + */
> + if (!cpu_is_omap7xx() && !cpu_is_omap15xx())
> + omap_init_clocksource_32k();
> }
>
> struct sys_timer omap_timer = {
> diff --git a/arch/arm/mach-omap2/timer-gp.c b/arch/arm/mach-omap2/timer-gp.c
> index 4e48e78..57d53e0 100644
> --- a/arch/arm/mach-omap2/timer-gp.c
> +++ b/arch/arm/mach-omap2/timer-gp.c
> @@ -42,6 +42,8 @@
>
> #include "timer-gp.h"
>
> +#include <plat/common.h>
> +
> /* MAX_GPTIMER_ID: number of GPTIMERs on the chip */
> #define MAX_GPTIMER_ID 12
>
> @@ -176,10 +178,14 @@ static void __init omap2_gp_clockevent_init(void)
> /*
> * When 32k-timer is enabled, don't use GPTimer for clocksource
> * instead, just leave default clocksource which uses the 32k
> - * sync counter. See clocksource setup in see plat-omap/common.c.
> + * sync counter. See clocksource setup in plat-omap/timer-32k.c
> */
>
> -static inline void __init omap2_gp_clocksource_init(void) {}
> +static void __init omap2_gp_clocksource_init(void)
> +{
> + omap_init_clocksource_32k();
> +}
> +
> #else
> /*
> * clocksource
> diff --git a/arch/arm/plat-omap/counter_32k.c b/arch/arm/plat-omap/counter_32k.c
> index ea46440..0367998 100644
> --- a/arch/arm/plat-omap/counter_32k.c
> +++ b/arch/arm/plat-omap/counter_32k.c
> @@ -160,7 +160,7 @@ void read_persistent_clock(struct timespec *ts)
> *ts = *tsp;
> }
>
> -static int __init omap_init_clocksource_32k(void)
> +int __init omap_init_clocksource_32k(void)
> {
> static char err[] __initdata = KERN_ERR
> "%s: can't register clocksource!\n";
> @@ -195,7 +195,6 @@ static int __init omap_init_clocksource_32k(void)
> }
> return 0;
> }
> -arch_initcall(omap_init_clocksource_32k);
>
> #endif /* !(defined(CONFIG_ARCH_OMAP730) || defined(CONFIG_ARCH_OMAP15XX)) */
>
> diff --git a/arch/arm/plat-omap/include/plat/common.h b/arch/arm/plat-omap/include/plat/common.h
> index 6b8088e..84c707f 100644
> --- a/arch/arm/plat-omap/include/plat/common.h
> +++ b/arch/arm/plat-omap/include/plat/common.h
> @@ -35,6 +35,7 @@ struct sys_timer;
>
> extern void omap_map_common_io(void);
> extern struct sys_timer omap_timer;
> +extern int __init omap_init_clocksource_32k(void);
>
> extern void omap_reserve(void);
>
This patch works on Devkit8000. Thanks.
Tested-by: Thomas Weber <weber@corscience.de>
^ permalink raw reply
* cannot fetch arm git tree
From: Russell King - ARM Linux @ 2011-01-16 13:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTinrZ0GnT71GCueUUpAXM5ckq+LBd0RjA51DMR-a@mail.gmail.com>
On Sun, Jan 16, 2011 at 09:10:17PM +0800, Jello huang wrote:
> yes,git doesn't handle that case and i rename the pack name,but there is
> also the similar error.Now i just delet the git tree and clone it again
> tonight .
_Always_ without fail fetch Linus' tree before pulling my tree.
My tree is a rsync clone of the objects and pack files in Linus' tree,
plus whatever git decided to build on top of that - for local commits
that's individual object files. For remote pulls, that's probably a few
small pack files.
There is *no* repacking of my tree. So the only times it gets 'repacked'
is when Linus repacks his tree.
Let's say you already have a copy of my tree from a month ago, and Linus
has pulled some work from me into his tree, and repacked his tree into one
single pack file. At the moment, the largest pack file from Linus is
400MB plus a 50MB index.
You already have most of the contents of that 400MB pack file, but if
you're missing even _one_ object which is contained within it, git will
have to download the _entire_ 400MB pack file and index file to retrieve
it.
However, if you first fetch Linus' tree via the git protocol, it can just
request the objects it doesn't have from the git server. That will mean
you'll have all the objects in the large pack files before you start trying
to pull my tree, and git won't have to download 400MB for the sake of
retrieving just maybe 10k that you didn't have.
This isn't something special with my tree - it's a side effect of the
http protocol git uses. So, before you fetch _any_ http-based git tree,
first make sure you're up to date with Linus'.
(I update my tree from Linus' in rsync mode to make http-based stuff a
lot more friendly to people using it - some of whom are stuck behind
firewalls which can only do http. Fetching a constantly repacked git
tree via http results in hundreds of megabytes needing to be fetched
every time.)
So please, whenever possible, always fetch Linus' latest tree _first_
and then mine. Same goes for any other http based tree which doesn't
auto-repack.
^ permalink raw reply
* [PATCH] ASoC: EP93xx: fixed LRCLK rate and DMA oper. in I2S code
From: Alexander @ 2011-01-16 12:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20101208124637.GD16418@rakim.wolfsonmicro.main>
From: Alexander Sverdlin <subaparts@yandex.ru>
Changelog:
1. I2S module of EP93xx should be feed by 32bit DMA transfers. This is
hardware limitation and that's the way original Cirrus's driver worked.
This will fix distorted sound playback and make capture actually work in
present ep93xx drivers.
I've found, that author of code, on which modern ep93xx-i2s.c and
ep93xx-pcm.c are based, had faced this problem also in 2007:
http://blog.gmane.org/gmane.linux.ports.arm.cirrus/month=20070101/page=3
Now SoC code uses his developments, but not overcomes the hardware
issues. Some details from EP93xx users guide:
Both I2S transmitter and receiver have similar 16x32bit FIFO, where they
store 8 samples for both left and right channels. The FIFO is always
32bit wide and should be properly aligned if you use samples of other
width. Transmitter and receiver have configuration registers for
selection of I2S word length (16, 24, 32). They are I2STXWrdLen and
I2SRXWrdLen.
Yes, EP93xx DMA can do byte, word and quad-word transfers. The width for
transfers to and from peripherals is selected by particular module
configuration. Lucky AC97 module has such configuration: AC97RXCRx
registers, bit CM (Compact mode enable) switches between 16 and 32 bit
samples. AC97TXCRx registers have the same bits for transmitters.
ep93xx-ac97.c enables this compact mode and so has all the rights to use
S16_LE format.
No one has found such a configuration in I2S module until now in any
Cirrus manuals. I2S module always feeds it's 32bit wide FIFO with 32bit
samples consecutively for left and right channels. You cannot use 32-bit
DMA transfers to transfer two 16-bit samples.
So we can use two formats for AC97, but should remove all but S32_LE for
I2S. Always using 32 bit chunks is not a problem for I2S, the codec I
use uses less bits too (24), it's permitted by I2S standard.
In proposed patch formats list shortened to just S32_LE, this makes all
the DMA transactions right, while ALSA will do all sample format
translation for us.
2. Incorrect setting of LRCLK (2 times slower) in original ep93xx-i2s.c
masks the first problem.
DMA takes two 16 bit samples instead of one, overall sound speed seems
to be normal, but you get actually 4000 sampling rate instead of
requested 8000 and therefore some noise... This is also the reason why
the capture function not worked at all in this driver...
If we take a look into I2S specification, we will figure that LRCLK MUST
be equal to sample rate, if we are talking about stereo (in mono too,
but it's not our case at all).
In proposed patch SCLK and LRCLK rates are corrected, assuming we always
send 32 bits * 2 channels to codec.
Signed-off-by: Alexander Sverdlin <subaparts@yandex.ru>
---
sound/soc/ep93xx/ep93xx-i2s.c | 18 +++++++++---------
1 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/sound/soc/ep93xx/ep93xx-i2s.c b/sound/soc/ep93xx/ep93xx-i2s.c
index 4f48733..3e4c3d9 100644
--- a/sound/soc/ep93xx/ep93xx-i2s.c
+++ b/sound/soc/ep93xx/ep93xx-i2s.c
@@ -267,14 +267,16 @@ static int ep93xx_i2s_hw_params(struct snd_pcm_substream *substream,
ep93xx_i2s_write_reg(info, EP93XX_I2S_RXWRDLEN, word_len);
/*
- * Calculate the sdiv (bit clock) and lrdiv (left/right clock) values.
- * If the lrclk is pulse length is larger than the word size, then the
- * bit clock will be gated for the unused bits.
+ * EP93xx I2S module can be setup so SCLK / LRCLK value can be
+ * 32, 64, 128. MCLK / SCLK value can be 2 and 4.
+ * We set LRCLK equal to `rate' and minimum SCLK / LRCLK
+ * value is 64, because our sample size is 32 bit * 2 channels.
+ * I2S standard permits us to transmit more bits than
+ * the codec uses.
*/
- div = (clk_get_rate(info->mclk) / params_rate(params)) *
- params_channels(params);
+ div = clk_get_rate(info->mclk) / params_rate(params);
for (sdiv = 2; sdiv <= 4; sdiv += 2)
- for (lrdiv = 32; lrdiv <= 128; lrdiv <<= 1)
+ for (lrdiv = 64; lrdiv <= 128; lrdiv <<= 1)
if (sdiv * lrdiv == div) {
found = 1;
goto out;
@@ -341,9 +343,7 @@ static struct snd_soc_dai_ops ep93xx_i2s_dai_ops = {
.set_fmt = ep93xx_i2s_set_dai_fmt,
};
-#define EP93XX_I2S_FORMATS (SNDRV_PCM_FMTBIT_S16_LE | \
- SNDRV_PCM_FMTBIT_S24_LE | \
- SNDRV_PCM_FMTBIT_S32_LE)
+#define EP93XX_I2S_FORMATS (SNDRV_PCM_FMTBIT_S32_LE)
static struct snd_soc_dai_driver ep93xx_i2s_dai = {
.symmetric_rates= 1,
^ permalink raw reply related
* [PATCH 27/48] ARM: PL08x: avoid duplicating registers in txd and phychan structures
From: Russell King - ARM Linux @ 2011-01-16 12:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTim_1yK_Q7sy4a1iMX2zXG1p3EJ0avGvcYeTP9Us@mail.gmail.com>
On Sat, Jan 15, 2011 at 11:17:04PM -0800, Dan Williams wrote:
> On Sat, Jan 15, 2011 at 1:23 AM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > On Fri, Jan 14, 2011 at 05:35:41PM -0800, Dan Williams wrote:
> >> On Mon, Jan 3, 2011 at 2:39 PM, Russell King - ARM Linux
> >> <linux@arm.linux.org.uk> wrote:
> >> > As we now have all the code accessing the phychan {csrc,cdst,clli,cctl,
> >> > ccfg} members in one function, there's no point storing the data into
> >> > the struct. ?Get rid of the struct members. ?Re-order the register dump
> >> > in the dev_dbg() to reflect the order we write the registers to the DMA
> >> > device.
> >> >
> >> > The txd {csrc,cdst,clli,cctl} values are duplicates of the lli[0]
> >> > values, so there's no point duplicating these either. ?Program the DMAC
> >> > registers directly from the lli[0] values.
> >> >
> >> > Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> >>
> >> This one caused:
> >> drivers/dma/amba-pl08x.c: In function 'pl08x_start_txd':
> >> drivers/dma/amba-pl08x.c:205: warning: dereferencing 'void *' pointer
> >
> > That probably means you've got something out of order. ?I have them
> > ordered in my git tree, I'll recheck there.
>
> I rechecked here and I think everything is in order.
Okay, something's screwed in the patch set - and I think I see what it is.
Patch 16 is missing a change. I'll respin.
^ permalink raw reply
* [PATCH 27/48] ARM: PL08x: avoid duplicating registers in txd and phychan structures
From: Shinya Kuribayashi @ 2011-01-16 12:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTim_1yK_Q7sy4a1iMX2zXG1p3EJ0avGvcYeTP9Us@mail.gmail.com>
>>> On Mon, Jan 3, 2011 at 2:39 PM, Russell King - ARM Linux
>>> <linux@arm.linux.org.uk> wrote:
>>>> As we now have all the code accessing the phychan {csrc,cdst,clli,cctl,
>>>> ccfg} members in one function, there's no point storing the data into
>>>> the struct. Get rid of the struct members. Re-order the register dump
>>>> in the dev_dbg() to reflect the order we write the registers to the DMA
>>>> device.
If it's revised, fix one nit, s/dev_dbg/dev_vdbg/ to be exact, too.
> @@ -227,19 +219,15 @@ static void pl08x_start_txd(struct pl08x_dma_chan *plchan,
>
> dev_vdbg(&pl08x->adev->dev,
> "WRITE channel %d: csrc=0x%08x, cdst=0x%08x, "
> - "cctl=0x%08x, clli=0x%08x, ccfg=0x%08x\n",
> - phychan->id,
> - phychan->csrc,
> - phychan->cdst,
> - phychan->cctl,
> - phychan->clli,
> - phychan->ccfg);
> -
> - writel(phychan->csrc, phychan->base + PL080_CH_SRC_ADDR);
> - writel(phychan->cdst, phychan->base + PL080_CH_DST_ADDR);
> - writel(phychan->clli, phychan->base + PL080_CH_LLI);
> - writel(phychan->cctl, phychan->base + PL080_CH_CONTROL);
> - writel(phychan->ccfg, phychan->base + PL080_CH_CONFIG);
> + "clli=0x%08x, cctl=0x%08x, ccfg=0x%08x\n",
> + phychan->id, lli->src, lli->dst, lli->lli, lli->cctl,
> + ccfg);
^ permalink raw reply
* [RFC+CFT] Use word operations in bitops
From: Russell King - ARM Linux @ 2011-01-16 12:19 UTC (permalink / raw)
To: linux-arm-kernel
XXX WARNING: bitops are used heavily by filesystem code: there be dragons XXX
I strongly suggest you ensure you have a copy of your filesystems before
trying this patch.
The patch below switches the bitops to use word loads/stores rather than
byte operations - so that we can avoid using the ldrexb/strexb instructions
which are only supported from ARMv6k and up.
The current bitops prevent a single kernel covering ARMv6 and ARMv7
architectures without the resulting kernel being unsafe on SMP. As
ldrex/strex is supported from ARMv6 upwards, but ldrexb/strexb is not,
switch these functions to use the word-based loads/stores.
As our bitops functions have been tolerant of misaligned pointers, they
now include a check which will do a NULL pointer store in the event that
they're passed a non-aligned pointers: ldrex/strex can't cope with such
things.
I've verified in userspace that these give the same results on LE setups
as our existing implementation - that doesn't mean these aren't buggy, it
just means they appear to behave the same for the testing I've done. BE
is completely untested (I don't have any ARM BE setups.)
Someone who uses BE setups needs to check that filesystem images (for
minix and ext2/ext3) which worked prior to this patch continue to work
after these patches.
This does need a fair amount of testing before it can be merged, so I'd
like to see a number of Tested-by's against this patch. Please also
indicate whether you tested on LE or BE or both, which filesystems, and
whether they were read-only mounted or read-write mounted.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
arch/arm/include/asm/bitops.h | 125 +++++++-------------------
arch/arm/kernel/armksyms.c | 33 ++-----
arch/arm/lib/bitops.h | 43 ++++++----
arch/arm/lib/changebit.S | 10 +--
arch/arm/lib/clearbit.S | 11 +--
arch/arm/lib/findbit.S | 197 ++++++++++++++--------------------------
arch/arm/lib/setbit.S | 11 +--
arch/arm/lib/testchangebit.S | 9 +--
arch/arm/lib/testclearbit.S | 9 +--
arch/arm/lib/testsetbit.S | 9 +--
10 files changed, 155 insertions(+), 302 deletions(-)
diff --git a/arch/arm/include/asm/bitops.h b/arch/arm/include/asm/bitops.h
index 7b1bb2b..da813b0 100644
--- a/arch/arm/include/asm/bitops.h
+++ b/arch/arm/include/asm/bitops.h
@@ -149,90 +149,47 @@ ____atomic_test_and_change_bit(unsigned int bit, volatile unsigned long *p)
*/
/*
- * Little endian assembly bitops. nr = 0 -> byte 0 bit 0.
+ * Assembly bitops. nr = 0 -> word 0 bit 0.
*/
-extern void _set_bit_le(int nr, volatile unsigned long * p);
-extern void _clear_bit_le(int nr, volatile unsigned long * p);
-extern void _change_bit_le(int nr, volatile unsigned long * p);
-extern int _test_and_set_bit_le(int nr, volatile unsigned long * p);
-extern int _test_and_clear_bit_le(int nr, volatile unsigned long * p);
-extern int _test_and_change_bit_le(int nr, volatile unsigned long * p);
-extern int _find_first_zero_bit_le(const void * p, unsigned size);
-extern int _find_next_zero_bit_le(const void * p, int size, int offset);
-extern int _find_first_bit_le(const unsigned long *p, unsigned size);
-extern int _find_next_bit_le(const unsigned long *p, int size, int offset);
-
-/*
- * Big endian assembly bitops. nr = 0 -> byte 3 bit 0.
- */
-extern void _set_bit_be(int nr, volatile unsigned long * p);
-extern void _clear_bit_be(int nr, volatile unsigned long * p);
-extern void _change_bit_be(int nr, volatile unsigned long * p);
-extern int _test_and_set_bit_be(int nr, volatile unsigned long * p);
-extern int _test_and_clear_bit_be(int nr, volatile unsigned long * p);
-extern int _test_and_change_bit_be(int nr, volatile unsigned long * p);
-extern int _find_first_zero_bit_be(const void * p, unsigned size);
-extern int _find_next_zero_bit_be(const void * p, int size, int offset);
-extern int _find_first_bit_be(const unsigned long *p, unsigned size);
-extern int _find_next_bit_be(const unsigned long *p, int size, int offset);
+extern void _set_bit(int nr, volatile unsigned long * p);
+extern void _clear_bit(int nr, volatile unsigned long * p);
+extern void _change_bit(int nr, volatile unsigned long * p);
+extern int _test_and_set_bit(int nr, volatile unsigned long * p);
+extern int _test_and_clear_bit(int nr, volatile unsigned long * p);
+extern int _test_and_change_bit(int nr, volatile unsigned long * p);
+extern int _find_first_zero_bit(const unsigned long * p, unsigned size);
+extern int _find_next_zero_bit(const unsigned long * p, int size, int offset);
+extern int _find_first_bit(const unsigned long *p, unsigned size);
+extern int _find_next_bit(const unsigned long *p, int size, int offset);
#ifndef CONFIG_SMP
/*
* The __* form of bitops are non-atomic and may be reordered.
*/
-#define ATOMIC_BITOP_LE(name,nr,p) \
+#define ATOMIC_BITOP(name,nr,p) \
(__builtin_constant_p(nr) ? \
____atomic_##name(nr, p) : \
- _##name##_le(nr,p))
-
-#define ATOMIC_BITOP_BE(name,nr,p) \
- (__builtin_constant_p(nr) ? \
- ____atomic_##name(nr, p) : \
- _##name##_be(nr,p))
+ _##name(nr,p))
#else
-#define ATOMIC_BITOP_LE(name,nr,p) _##name##_le(nr,p)
-#define ATOMIC_BITOP_BE(name,nr,p) _##name##_be(nr,p)
+#define ATOMIC_BITOP(name,nr,p) _##name(nr,p)
#endif
#define NONATOMIC_BITOP(name,nr,p) \
(____nonatomic_##name(nr, p))
-#ifndef __ARMEB__
/*
- * These are the little endian, atomic definitions.
+ * These are the endian-indifferent as they use word loads/stores.
*/
-#define set_bit(nr,p) ATOMIC_BITOP_LE(set_bit,nr,p)
-#define clear_bit(nr,p) ATOMIC_BITOP_LE(clear_bit,nr,p)
-#define change_bit(nr,p) ATOMIC_BITOP_LE(change_bit,nr,p)
-#define test_and_set_bit(nr,p) ATOMIC_BITOP_LE(test_and_set_bit,nr,p)
-#define test_and_clear_bit(nr,p) ATOMIC_BITOP_LE(test_and_clear_bit,nr,p)
-#define test_and_change_bit(nr,p) ATOMIC_BITOP_LE(test_and_change_bit,nr,p)
-#define find_first_zero_bit(p,sz) _find_first_zero_bit_le(p,sz)
-#define find_next_zero_bit(p,sz,off) _find_next_zero_bit_le(p,sz,off)
-#define find_first_bit(p,sz) _find_first_bit_le(p,sz)
-#define find_next_bit(p,sz,off) _find_next_bit_le(p,sz,off)
-
-#define WORD_BITOFF_TO_LE(x) ((x))
-
-#else
-
-/*
- * These are the big endian, atomic definitions.
- */
-#define set_bit(nr,p) ATOMIC_BITOP_BE(set_bit,nr,p)
-#define clear_bit(nr,p) ATOMIC_BITOP_BE(clear_bit,nr,p)
-#define change_bit(nr,p) ATOMIC_BITOP_BE(change_bit,nr,p)
-#define test_and_set_bit(nr,p) ATOMIC_BITOP_BE(test_and_set_bit,nr,p)
-#define test_and_clear_bit(nr,p) ATOMIC_BITOP_BE(test_and_clear_bit,nr,p)
-#define test_and_change_bit(nr,p) ATOMIC_BITOP_BE(test_and_change_bit,nr,p)
-#define find_first_zero_bit(p,sz) _find_first_zero_bit_be(p,sz)
-#define find_next_zero_bit(p,sz,off) _find_next_zero_bit_be(p,sz,off)
-#define find_first_bit(p,sz) _find_first_bit_be(p,sz)
-#define find_next_bit(p,sz,off) _find_next_bit_be(p,sz,off)
-
-#define WORD_BITOFF_TO_LE(x) ((x) ^ 0x18)
-
-#endif
+#define set_bit(nr,p) ATOMIC_BITOP(set_bit,nr,p)
+#define clear_bit(nr,p) ATOMIC_BITOP(clear_bit,nr,p)
+#define change_bit(nr,p) ATOMIC_BITOP(change_bit,nr,p)
+#define test_and_set_bit(nr,p) ATOMIC_BITOP(test_and_set_bit,nr,p)
+#define test_and_clear_bit(nr,p) ATOMIC_BITOP(test_and_clear_bit,nr,p)
+#define test_and_change_bit(nr,p) ATOMIC_BITOP(test_and_change_bit,nr,p)
+#define find_first_zero_bit(p,sz) _find_first_zero_bit(p,sz)
+#define find_next_zero_bit(p,sz,off) _find_next_zero_bit(p,sz,off)
+#define find_first_bit(p,sz) _find_first_bit(p,sz)
+#define find_next_bit(p,sz,off) _find_next_bit(p,sz,off)
#if __LINUX_ARM_ARCH__ < 5
@@ -302,42 +259,28 @@ static inline int fls(int x)
#include <asm-generic/bitops/sched.h>
#include <asm-generic/bitops/hweight.h>
#include <asm-generic/bitops/lock.h>
+#include <asm-generic/bitops/minix.h>
/*
* Ext2 is defined to use little-endian byte ordering.
* These do not need to be atomic.
*/
#define ext2_set_bit(nr,p) \
- __test_and_set_bit(WORD_BITOFF_TO_LE(nr), (unsigned long *)(p))
+ __test_and_set_bit(nr, (unsigned long *)(p))
#define ext2_set_bit_atomic(lock,nr,p) \
- test_and_set_bit(WORD_BITOFF_TO_LE(nr), (unsigned long *)(p))
+ test_and_set_bit(nr, (unsigned long *)(p))
#define ext2_clear_bit(nr,p) \
- __test_and_clear_bit(WORD_BITOFF_TO_LE(nr), (unsigned long *)(p))
+ __test_and_clear_bit(nr, (unsigned long *)(p))
#define ext2_clear_bit_atomic(lock,nr,p) \
- test_and_clear_bit(WORD_BITOFF_TO_LE(nr), (unsigned long *)(p))
+ test_and_clear_bit(nr, (unsigned long *)(p))
#define ext2_test_bit(nr,p) \
- test_bit(WORD_BITOFF_TO_LE(nr), (unsigned long *)(p))
+ test_bit(nr, (unsigned long *)(p))
#define ext2_find_first_zero_bit(p,sz) \
- _find_first_zero_bit_le(p,sz)
+ _find_first_zero_bit((unsigned long *)(p),sz)
#define ext2_find_next_zero_bit(p,sz,off) \
- _find_next_zero_bit_le(p,sz,off)
+ _find_next_zero_bit((unsigned long *)(p),sz,off)
#define ext2_find_next_bit(p, sz, off) \
- _find_next_bit_le(p, sz, off)
-
-/*
- * Minix is defined to use little-endian byte ordering.
- * These do not need to be atomic.
- */
-#define minix_set_bit(nr,p) \
- __set_bit(WORD_BITOFF_TO_LE(nr), (unsigned long *)(p))
-#define minix_test_bit(nr,p) \
- test_bit(WORD_BITOFF_TO_LE(nr), (unsigned long *)(p))
-#define minix_test_and_set_bit(nr,p) \
- __test_and_set_bit(WORD_BITOFF_TO_LE(nr), (unsigned long *)(p))
-#define minix_test_and_clear_bit(nr,p) \
- __test_and_clear_bit(WORD_BITOFF_TO_LE(nr), (unsigned long *)(p))
-#define minix_find_first_zero_bit(p,sz) \
- _find_first_zero_bit_le(p,sz)
+ _find_next_bit((unsigned long *)(p), sz, off)
#endif /* __KERNEL__ */
diff --git a/arch/arm/kernel/armksyms.c b/arch/arm/kernel/armksyms.c
index 9615423..7064ef4 100644
--- a/arch/arm/kernel/armksyms.c
+++ b/arch/arm/kernel/armksyms.c
@@ -140,29 +140,16 @@ EXPORT_SYMBOL(__aeabi_ulcmp);
#endif
/* bitops */
-EXPORT_SYMBOL(_set_bit_le);
-EXPORT_SYMBOL(_test_and_set_bit_le);
-EXPORT_SYMBOL(_clear_bit_le);
-EXPORT_SYMBOL(_test_and_clear_bit_le);
-EXPORT_SYMBOL(_change_bit_le);
-EXPORT_SYMBOL(_test_and_change_bit_le);
-EXPORT_SYMBOL(_find_first_zero_bit_le);
-EXPORT_SYMBOL(_find_next_zero_bit_le);
-EXPORT_SYMBOL(_find_first_bit_le);
-EXPORT_SYMBOL(_find_next_bit_le);
-
-#ifdef __ARMEB__
-EXPORT_SYMBOL(_set_bit_be);
-EXPORT_SYMBOL(_test_and_set_bit_be);
-EXPORT_SYMBOL(_clear_bit_be);
-EXPORT_SYMBOL(_test_and_clear_bit_be);
-EXPORT_SYMBOL(_change_bit_be);
-EXPORT_SYMBOL(_test_and_change_bit_be);
-EXPORT_SYMBOL(_find_first_zero_bit_be);
-EXPORT_SYMBOL(_find_next_zero_bit_be);
-EXPORT_SYMBOL(_find_first_bit_be);
-EXPORT_SYMBOL(_find_next_bit_be);
-#endif
+EXPORT_SYMBOL(_set_bit);
+EXPORT_SYMBOL(_test_and_set_bit);
+EXPORT_SYMBOL(_clear_bit);
+EXPORT_SYMBOL(_test_and_clear_bit);
+EXPORT_SYMBOL(_change_bit);
+EXPORT_SYMBOL(_test_and_change_bit);
+EXPORT_SYMBOL(_find_first_zero_bit);
+EXPORT_SYMBOL(_find_next_zero_bit);
+EXPORT_SYMBOL(_find_first_bit);
+EXPORT_SYMBOL(_find_next_bit);
#ifdef CONFIG_FUNCTION_TRACER
#ifdef CONFIG_OLD_MCOUNT
diff --git a/arch/arm/lib/bitops.h b/arch/arm/lib/bitops.h
index d422529..2a09e57 100644
--- a/arch/arm/lib/bitops.h
+++ b/arch/arm/lib/bitops.h
@@ -1,28 +1,34 @@
#if __LINUX_ARM_ARCH__ >= 6 && defined(CONFIG_CPU_32v6K)
.macro bitop, instr
+ tst r1, #3
+ strne r1, [r1, -r1] @ assert word-aligned
mov r2, #1
- and r3, r0, #7 @ Get bit offset
- add r1, r1, r0, lsr #3 @ Get byte offset
+ and r3, r0, #31 @ Get bit offset
+ mov r0, r0, lsr #5
+ add r1, r1, r0, lsl #2 @ Get word offset
mov r3, r2, lsl r3
-1: ldrexb r2, [r1]
+1: ldrex r2, [r1]
\instr r2, r2, r3
- strexb r0, r2, [r1]
+ strex r0, r2, [r1]
cmp r0, #0
bne 1b
mov pc, lr
.endm
.macro testop, instr, store
- and r3, r0, #7 @ Get bit offset
+ tst r1, #3
+ strne r1, [r1, -r1] @ assert word-aligned
mov r2, #1
- add r1, r1, r0, lsr #3 @ Get byte offset
+ and r3, r0, #31 @ Get bit offset
+ mov r0, r0, lsr #5
+ add r1, r1, r0, lsl #2 @ Get word offset
mov r3, r2, lsl r3 @ create mask
smp_dmb
-1: ldrexb r2, [r1]
+1: ldrex r2, [r1]
ands r0, r2, r3 @ save old value of bit
- \instr r2, r2, r3 @ toggle bit
- strexb ip, r2, [r1]
+ \instr r2, r2, r3 @ toggle bit
+ strex ip, r2, [r1]
cmp ip, #0
bne 1b
smp_dmb
@@ -32,13 +38,16 @@
.endm
#else
.macro bitop, instr
- and r2, r0, #7
+ tst r1, #3
+ strne r1, [r1, -r1] @ assert word-aligned
+ and r2, r0, #31
+ mov r0, r0, lsr #5
mov r3, #1
mov r3, r3, lsl r2
save_and_disable_irqs ip
- ldrb r2, [r1, r0, lsr #3]
+ ldr r2, [r1, r0, lsl #2]
\instr r2, r2, r3
- strb r2, [r1, r0, lsr #3]
+ str r2, [r1, r0, lsl #2]
restore_irqs ip
mov pc, lr
.endm
@@ -52,11 +61,13 @@
* to avoid dirtying the data cache.
*/
.macro testop, instr, store
- add r1, r1, r0, lsr #3
- and r3, r0, #7
- mov r0, #1
+ tst r1, #3
+ strne r1, [r1, -r1] @ assert word-aligned
+ and r3, r0, #31
+ mov r0, r0, lsr #5
save_and_disable_irqs ip
- ldrb r2, [r1]
+ ldr r2, [r1, r0, lsl #2]!
+ mov r0, #1
tst r2, r0, lsl r3
\instr r2, r2, r0, lsl r3
\store r2, [r1]
diff --git a/arch/arm/lib/changebit.S b/arch/arm/lib/changebit.S
index 80f3115..68ed5b6 100644
--- a/arch/arm/lib/changebit.S
+++ b/arch/arm/lib/changebit.S
@@ -12,12 +12,6 @@
#include "bitops.h"
.text
-/* Purpose : Function to change a bit
- * Prototype: int change_bit(int bit, void *addr)
- */
-ENTRY(_change_bit_be)
- eor r0, r0, #0x18 @ big endian byte ordering
-ENTRY(_change_bit_le)
+ENTRY(_change_bit)
bitop eor
-ENDPROC(_change_bit_be)
-ENDPROC(_change_bit_le)
+ENDPROC(_change_bit)
diff --git a/arch/arm/lib/clearbit.S b/arch/arm/lib/clearbit.S
index 1a63e43..4c04c3b 100644
--- a/arch/arm/lib/clearbit.S
+++ b/arch/arm/lib/clearbit.S
@@ -12,13 +12,6 @@
#include "bitops.h"
.text
-/*
- * Purpose : Function to clear a bit
- * Prototype: int clear_bit(int bit, void *addr)
- */
-ENTRY(_clear_bit_be)
- eor r0, r0, #0x18 @ big endian byte ordering
-ENTRY(_clear_bit_le)
+ENTRY(_clear_bit)
bitop bic
-ENDPROC(_clear_bit_be)
-ENDPROC(_clear_bit_le)
+ENDPROC(_clear_bit)
diff --git a/arch/arm/lib/findbit.S b/arch/arm/lib/findbit.S
index 64f6bc1..223e92a 100644
--- a/arch/arm/lib/findbit.S
+++ b/arch/arm/lib/findbit.S
@@ -21,173 +21,114 @@
* Purpose : Find a 'zero' bit
* Prototype: int find_first_zero_bit(void *addr, unsigned int maxbit);
*/
-ENTRY(_find_first_zero_bit_le)
+ENTRY(_find_first_zero_bit)
+ tst r0, #3
+ strne r0, [r0, -r0] @ assert word aligned
teq r1, #0
- beq 3f
+ beq ffz_none
mov r2, #0
-1:
- ARM( ldrb r3, [r0, r2, lsr #3] )
+ffz_loop:
+ ARM( ldr r3, [r0, r2, lsr #3] )
THUMB( lsr r3, r2, #3 )
- THUMB( ldrb r3, [r0, r3] )
- eors r3, r3, #0xff @ invert bits
- bne .L_found @ any now set - found zero bit
- add r2, r2, #8 @ next bit pointer
-2: cmp r2, r1 @ any more?
- blo 1b
-3: mov r0, r1 @ no free bits
+ THUMB( ldr r3, [r0, r3] )
+ mvns r3, r3 @ invert bits
+ bne .L_found0 @ any now set - found zero bit
+ffz_next: add r2, r2, #32 @ next bit pointer
+ cmp r2, r1 @ any more?
+ blo ffz_loop
+ffz_none: mov r0, r1 @ no free bits
mov pc, lr
-ENDPROC(_find_first_zero_bit_le)
+ENDPROC(_find_first_zero_bit)
/*
* Purpose : Find next 'zero' bit
* Prototype: int find_next_zero_bit(void *addr, unsigned int maxbit, int offset)
*/
-ENTRY(_find_next_zero_bit_le)
+ENTRY(_find_next_zero_bit)
+ tst r0, #3
+ strne r0, [r0, -r0] @ assert word aligned
teq r1, #0
- beq 3b
- ands ip, r2, #7
- beq 1b @ If new byte, goto old routine
- ARM( ldrb r3, [r0, r2, lsr #3] )
+ beq ffz_none
+ ands ip, r2, #31
+ beq ffz_loop
+ bic r2, r2, #31
+ ARM( ldr r3, [r0, r2, lsr #3] )
THUMB( lsr r3, r2, #3 )
- THUMB( ldrb r3, [r0, r3] )
- eor r3, r3, #0xff @ now looking for a 1 bit
+ THUMB( ldr r3, [r0, r3] )
+ mvn r3, r3 @ now looking for a 1 bit
movs r3, r3, lsr ip @ shift off unused bits
- bne .L_found
- orr r2, r2, #7 @ if zero, then no bits here
- add r2, r2, #1 @ align bit pointer
- b 2b @ loop for next bit
-ENDPROC(_find_next_zero_bit_le)
+ bne .L_foundoff
+ b ffz_next @ loop for next bit
+ENDPROC(_find_next_zero_bit)
/*
* Purpose : Find a 'one' bit
* Prototype: int find_first_bit(const unsigned long *addr, unsigned int maxbit);
*/
-ENTRY(_find_first_bit_le)
+ENTRY(_find_first_bit)
+ tst r0, #3
+ strne r0, [r0, -r0] @ assert word aligned
teq r1, #0
- beq 3f
+ beq ffb_none
mov r2, #0
-1:
- ARM( ldrb r3, [r0, r2, lsr #3] )
+ffb_loop:
+ ARM( ldr r3, [r0, r2, lsr #3] )
THUMB( lsr r3, r2, #3 )
- THUMB( ldrb r3, [r0, r3] )
+ THUMB( ldr r3, [r0, r3] )
movs r3, r3
- bne .L_found @ any now set - found zero bit
- add r2, r2, #8 @ next bit pointer
-2: cmp r2, r1 @ any more?
- blo 1b
-3: mov r0, r1 @ no free bits
+ bne .L_found0 @ any now set - found zero bit
+ffb_next: add r2, r2, #32 @ next bit pointer
+ cmp r2, r1 @ any more?
+ blo ffb_loop
+ffb_none: mov r0, r1 @ no free bits
mov pc, lr
-ENDPROC(_find_first_bit_le)
+ENDPROC(_find_first_bit)
/*
* Purpose : Find next 'one' bit
* Prototype: int find_next_zero_bit(void *addr, unsigned int maxbit, int offset)
*/
-ENTRY(_find_next_bit_le)
+ENTRY(_find_next_bit)
+ tst r0, #3
+ strne r0, [r0, -r0] @ assert word aligned
teq r1, #0
- beq 3b
- ands ip, r2, #7
- beq 1b @ If new byte, goto old routine
- ARM( ldrb r3, [r0, r2, lsr #3] )
+ beq ffb_none
+ ands ip, r2, #31
+ beq ffb_loop @ If new word, goto old routine
+ bic r2, r2, #31
+ ARM( ldr r3, [r0, r2, lsr #3] )
THUMB( lsr r3, r2, #3 )
- THUMB( ldrb r3, [r0, r3] )
+ THUMB( ldr r3, [r0, r3] )
movs r3, r3, lsr ip @ shift off unused bits
- bne .L_found
- orr r2, r2, #7 @ if zero, then no bits here
- add r2, r2, #1 @ align bit pointer
- b 2b @ loop for next bit
-ENDPROC(_find_next_bit_le)
-
-#ifdef __ARMEB__
-
-ENTRY(_find_first_zero_bit_be)
- teq r1, #0
- beq 3f
- mov r2, #0
-1: eor r3, r2, #0x18 @ big endian byte ordering
- ARM( ldrb r3, [r0, r3, lsr #3] )
- THUMB( lsr r3, #3 )
- THUMB( ldrb r3, [r0, r3] )
- eors r3, r3, #0xff @ invert bits
- bne .L_found @ any now set - found zero bit
- add r2, r2, #8 @ next bit pointer
-2: cmp r2, r1 @ any more?
- blo 1b
-3: mov r0, r1 @ no free bits
- mov pc, lr
-ENDPROC(_find_first_zero_bit_be)
-
-ENTRY(_find_next_zero_bit_be)
- teq r1, #0
- beq 3b
- ands ip, r2, #7
- beq 1b @ If new byte, goto old routine
- eor r3, r2, #0x18 @ big endian byte ordering
- ARM( ldrb r3, [r0, r3, lsr #3] )
- THUMB( lsr r3, #3 )
- THUMB( ldrb r3, [r0, r3] )
- eor r3, r3, #0xff @ now looking for a 1 bit
- movs r3, r3, lsr ip @ shift off unused bits
- bne .L_found
- orr r2, r2, #7 @ if zero, then no bits here
- add r2, r2, #1 @ align bit pointer
- b 2b @ loop for next bit
-ENDPROC(_find_next_zero_bit_be)
-
-ENTRY(_find_first_bit_be)
- teq r1, #0
- beq 3f
- mov r2, #0
-1: eor r3, r2, #0x18 @ big endian byte ordering
- ARM( ldrb r3, [r0, r3, lsr #3] )
- THUMB( lsr r3, #3 )
- THUMB( ldrb r3, [r0, r3] )
- movs r3, r3
- bne .L_found @ any now set - found zero bit
- add r2, r2, #8 @ next bit pointer
-2: cmp r2, r1 @ any more?
- blo 1b
-3: mov r0, r1 @ no free bits
- mov pc, lr
-ENDPROC(_find_first_bit_be)
-
-ENTRY(_find_next_bit_be)
- teq r1, #0
- beq 3b
- ands ip, r2, #7
- beq 1b @ If new byte, goto old routine
- eor r3, r2, #0x18 @ big endian byte ordering
- ARM( ldrb r3, [r0, r3, lsr #3] )
- THUMB( lsr r3, #3 )
- THUMB( ldrb r3, [r0, r3] )
- movs r3, r3, lsr ip @ shift off unused bits
- bne .L_found
- orr r2, r2, #7 @ if zero, then no bits here
- add r2, r2, #1 @ align bit pointer
- b 2b @ loop for next bit
-ENDPROC(_find_next_bit_be)
-
-#endif
+ bne .L_foundoff
+ b ffb_loop @ loop for next bit
+ENDPROC(_find_next_bit)
/*
* One or more bits in the LSB of r3 are assumed to be set.
*/
-.L_found:
-#if __LINUX_ARM_ARCH__ >= 5
- rsb r0, r3, #0
+.L_foundoff: add r2, r2, ip @ add bit offset back in
+.L_found0: rsb r0, r3, #0
and r3, r3, r0
+#if __LINUX_ARM_ARCH__ >= 5
clz r3, r3
rsb r3, r3, #31
add r0, r2, r3
#else
- tst r3, #0x0f
- addeq r2, r2, #4
- movne r3, r3, lsl #4
- tst r3, #0x30
- addeq r2, r2, #2
- movne r3, r3, lsl #2
- tst r3, #0x40
- addeq r2, r2, #1
+ movs r0, r3, lsr #16
+ addne r2, r2, #16
+ movne r3, r0
+ movs r0, r3, lsr #8
+ addne r2, r2, #8
+ movne r3, r0
+ movs r0, r3, lsr #4
+ addne r2, r2, #4
+ movne r3, r0
+ movs r0, r3, lsr #2
+ addne r2, r2, #2
+ movne r3, r0
+ tst r3, #2
+ addne r2, r2, #1
mov r0, r2
#endif
cmp r1, r0 @ Clamp to maxbit
diff --git a/arch/arm/lib/setbit.S b/arch/arm/lib/setbit.S
index 1dd7176..bbee5c6 100644
--- a/arch/arm/lib/setbit.S
+++ b/arch/arm/lib/setbit.S
@@ -12,13 +12,6 @@
#include "bitops.h"
.text
-/*
- * Purpose : Function to set a bit
- * Prototype: int set_bit(int bit, void *addr)
- */
-ENTRY(_set_bit_be)
- eor r0, r0, #0x18 @ big endian byte ordering
-ENTRY(_set_bit_le)
+ENTRY(_set_bit)
bitop orr
-ENDPROC(_set_bit_be)
-ENDPROC(_set_bit_le)
+ENDPROC(_set_bit)
diff --git a/arch/arm/lib/testchangebit.S b/arch/arm/lib/testchangebit.S
index 5c98dc5..15a4d43 100644
--- a/arch/arm/lib/testchangebit.S
+++ b/arch/arm/lib/testchangebit.S
@@ -12,9 +12,6 @@
#include "bitops.h"
.text
-ENTRY(_test_and_change_bit_be)
- eor r0, r0, #0x18 @ big endian byte ordering
-ENTRY(_test_and_change_bit_le)
- testop eor, strb
-ENDPROC(_test_and_change_bit_be)
-ENDPROC(_test_and_change_bit_le)
+ENTRY(_test_and_change_bit)
+ testop eor, str
+ENDPROC(_test_and_change_bit)
diff --git a/arch/arm/lib/testclearbit.S b/arch/arm/lib/testclearbit.S
index 543d709..521b66b 100644
--- a/arch/arm/lib/testclearbit.S
+++ b/arch/arm/lib/testclearbit.S
@@ -12,9 +12,6 @@
#include "bitops.h"
.text
-ENTRY(_test_and_clear_bit_be)
- eor r0, r0, #0x18 @ big endian byte ordering
-ENTRY(_test_and_clear_bit_le)
- testop bicne, strneb
-ENDPROC(_test_and_clear_bit_be)
-ENDPROC(_test_and_clear_bit_le)
+ENTRY(_test_and_clear_bit)
+ testop bicne, strne
+ENDPROC(_test_and_clear_bit)
diff --git a/arch/arm/lib/testsetbit.S b/arch/arm/lib/testsetbit.S
index 0b3f390..1c98cc2 100644
--- a/arch/arm/lib/testsetbit.S
+++ b/arch/arm/lib/testsetbit.S
@@ -12,9 +12,6 @@
#include "bitops.h"
.text
-ENTRY(_test_and_set_bit_be)
- eor r0, r0, #0x18 @ big endian byte ordering
-ENTRY(_test_and_set_bit_le)
- testop orreq, streqb
-ENDPROC(_test_and_set_bit_be)
-ENDPROC(_test_and_set_bit_le)
+ENTRY(_test_and_set_bit)
+ testop orreq, streq
+ENDPROC(_test_and_set_bit)
^ permalink raw reply related
* [PATCH] ARM: vfp: Fix up exception location in Thumb mode
From: Catalin Marinas @ 2011-01-16 11:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110115154319.GG15996@n2100.arm.linux.org.uk>
On Saturday, 15 January 2011, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Sat, Jan 15, 2011 at 03:38:16PM +0000, Catalin Marinas wrote:
>> On 14 January 2011 18:47, Russell King - ARM Linux
>> <linux@arm.linux.org.uk> wrote:
>> > diff -u b/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S
>> > --- b/arch/arm/kernel/entry-armv.S
>> > +++ b/arch/arm/kernel/entry-armv.S
>> > @@ -499,10 +499,11 @@
>> > ? ? ? ?blo ? ? __und_usr_unknown
>> > ?3: ? ? ldrht ? r0, [r4]
>> > ? ? ? ?add ? ? r2, r2, #2 ? ? ? ? ? ? ? ? ? ? ?@ r2 is PC + 2, make it PC + 4
>> > - ? ? ? orr ? ? r0, r0, r5, lsl #16
>> > + ? ? ? str ? ? r2, [sp, #S_PC] ? ? ? ? ? ? ? ? @ it's a 2x16bit instr, update
>> > + ? ? ? orr ? ? r0, r0, r5, lsl #16 ? ? ? ? ? ? @ ?regs->ARM_pc
>> > ? ? ? ?@
>> > ? ? ? ?@ r0 = the two 16-bit Thumb instructions which caused the exception
>> > - ? ? ? @ r2 = PC value for the following Thumb instruction (:= regs->ARM_pc+2)
>> > + ? ? ? @ r2 = PC value for the following Thumb instruction (:= regs->ARM_pc)
>> > ? ? ? ?@ r4 = PC value for the first 16-bit Thumb instruction
>> > ? ? ? ?@
>> > ?#else
>>
>> Do we need to modify the VFP entry code to avoit the store to ARM_pc?
>
> The one after the sub #4 instruction?
No, I misread the code, we still need the one after sub #4.
--
Catalin
^ permalink raw reply
* [PATCH] ARM: vfp: Fix up exception location in Thumb mode
From: Catalin Marinas @ 2011-01-16 11:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110115154019.GF15996@n2100.arm.linux.org.uk>
On Saturday, 15 January 2011, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Sat, Jan 15, 2011 at 03:31:04PM +0000, Catalin Marinas wrote:
>> On 14 January 2011 17:30, Russell King - ARM Linux
>> <linux@arm.linux.org.uk> wrote:
>> > diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S
>> > index 2b46fea..5876eec 100644
>> > --- a/arch/arm/kernel/entry-armv.S
>> > +++ b/arch/arm/kernel/entry-armv.S
>> > @@ -461,27 +461,35 @@ ENDPROC(__irq_usr)
>> > ? ? ? ?.align ?5
>> > ?__und_usr:
>> > ? ? ? ?usr_entry
>> > -
>> > - ? ? ? @
>> > - ? ? ? @ fall through to the emulation code, which returns using r9 if
>> > - ? ? ? @ it has emulated the instruction, or the more conventional lr
>> > - ? ? ? @ if we are to treat this as a real undefined instruction
>> > ? ? ? ?@
>> > - ? ? ? @ ?r0 - instruction
>> > + ? ? ? @ The emulation code returns using r9 if it has emulated the
>> > + ? ? ? @ instruction, or the more conventional lr if we are to treat
>> > + ? ? ? @ this as a real undefined instruction
>> > ? ? ? ?@
>> > ? ? ? ?adr ? ? r9, BSYM(ret_from_exception)
>> > ? ? ? ?adr ? ? lr, BSYM(__und_usr_unknown)
>> > + ? ? ? @
>> > + ? ? ? @ r2 = regs->ARM_pc, which is either 2 or 4 bytes ahead of the
>> > + ? ? ? @ faulting instruction depending on Thumb mode.
>> > + ? ? ? @ r3 = regs->ARM_cpsr
>> > + ? ? ? @
>> > ? ? ? ?tst ? ? r3, #PSR_T_BIT ? ? ? ? ? ? ? ? ?@ Thumb mode?
>> > - ? ? ? itet ? ?eq ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?@ explicit IT needed for the 1f label
>> > + ? ? ? itttt ? eq ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?@ explicit IT needed for the 1f label
>> > ? ? ? ?subeq ? r4, r2, #4 ? ? ? ? ? ? ? ? ? ? ?@ ARM instr at LR - 4
>> > - ? ? ? subne ? r4, r2, #2 ? ? ? ? ? ? ? ? ? ? ?@ Thumb instr at LR - 2
>> > ?1: ? ? ldreqt ?r0, [r4]
>>
>> The itttt above should just be itt. The reveq is conditionally
>> compiled and beq doesn't necessarily need one.
>
> It's a reveq, so I thought we should cover all the instructions with
> an 'eq' conditional for thumb.
If the it instruction doesn't cover all instructions, gas generates
some more its. But in this case, for little endian, the it instruction
covers more since reveq isn't included and having the beq not last in
the block I think is unpredictable. If you really want to optimise the
big endian case not to have an additional it generated by gas, you can
write ittt so that beq is included with little endian but not with big
endian. I wouldn't bother much for an extra it anyway.
>> > ?#ifdef CONFIG_CPU_ENDIAN_BE8
>> > ? ? ? ?reveq ? r0, r0 ? ? ? ? ? ? ? ? ? ? ? ? ?@ little endian instruction
>> > ?#endif
>> > + ? ? ? @
>> > + ? ? ? @ r0 = 32-bit ARM instruction which caused the exception
>> > + ? ? ? @ r2 = PC value for the following instruction (:= regs->ARM_pc)
>>
>> Is r2 here always the PC value following instruction? If the Thumb
>> instruction was 32-bit, it just points in the middle of the faulting
>> instruction.
>
> Is the T bit ever zero in this case? ?The code here is:
>
> ?? ? ? ?tst ? ? r3, #PSR_T_BIT
> ?? ? ? ?subeq ? r4, r2, #4
> 1: ? ? ?ldreqt ?r0, [r4]
> ?? ? ? ?reveq ? r0, r0
> ?? ? ? ?beq ? ? call_fpe
You can have the T bit set but the instruction a 32-bit Thumb in which
case r2 is in the middle of such instruction rather than the next.
Unless you only refer to the ARM mode, in which case the comment is
fine.
> So, if !T, then we subtract 4 and load the instruction (which was the
> faulting instruction). ?So r2 is the following instruction.
>
> Ah, maybe you're getting confused by the comment. ?Should we put
> an 'eq' suffix on the end of each line? ;)
Maybe mention that this is ARM. I think documenting this code is
difficult anyway. I found myself not reading the comments at all when
revisiting this code :) but they may be useful for others.
--
Catalin
^ permalink raw reply
* [PATCH 1/3] ASoC: EP93xx I2S and PCM fixes
From: Mark Brown @ 2011-01-16 11:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1295176862.15631.168.camel@r60e>
On Sun, Jan 16, 2011 at 02:21:02PM +0300, Alexander wrote:
Please don't top post.
> So we can use two formats for AC97, but should remove all but S32_LE for
> I2S.
> Should I resend my patches now?
Yes. Like I said the important thing is to have a changelog which makes
it clear what is going on.
^ permalink raw reply
* [PATCH 1/3] ASoC: EP93xx I2S and PCM fixes
From: Alexander @ 2011-01-16 11:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20101210150758.GE3200@rakim.wolfsonmicro.main>
Dear Mark,
Well, now I have time to deal with this again, sorry for long pause.
I've found, that author of code, on which modern ep93xx-i2s.c and
ep93xx-pcm.c are based, had faced this problem also in 2007:
http://blog.gmane.org/gmane.linux.ports.arm.cirrus/month=20070101/page=3
Now SoC code uses his developments, but not overcomes the hardware
issues. Some details from EP93xx users guide:
Both I2S transmitter and receiver have similar 16x32bit FIFO, where they
store 8 samples for both left and right channels. The FIFO is always
32bit wide and should be properly aligned if you use samples of other
width. Transmitter and receiver have configuration registers for
selection of I2S word length (16, 24, 32). They are I2STXWrdLen and
I2SRXWrdLen.
Yes, EP93xx DMA can do byte, word and quad-word transfers. The width for
transfers to and from peripherals is selected by particular module
configuration. Lucky AC97 module has such configuration: AC97RXCRx
registers, bit CM (Compact mode enable) switches between 16 and 32 bit
samples. AC97TXCRx registers have the same bits for transmitters.
ep93xx-ac97.c enables this compact mode and so has all the rights to use
S16_LE format.
No one has found such a configuration in I2S module until now in any
Cirrus manuals. I2S module always feeds it's 32bit wide FIFO with 32bit
samples consecutively for left and right channels. You cannot use 32-bit
DMA transfers to transfer two 16-bit samples.
So we can use two formats for AC97, but should remove all but S32_LE for
I2S.
Should I resend my patches now?
Best regards,
Alexander A. Sverdlin.
On Fri, 2010-12-10 at 15:07 +0000, Mark Brown wrote:
> On Fri, Dec 10, 2010 at 12:14:18AM +0300, Alexander wrote:
>
> > BTW, it's how original Cirrus's sound driver had done it's work. Cirrus
> > programmers had not found a way to overcome this. The datasheets for
> > EP93xx series cover everything only briefly... The dumbness of EP93xx's
> > DMA is also the reason why we do not have DMA in serial ports and SSP...
>
> > The function I'm talking about is snd_ep93xx_dma2usr_ratio(), as told in
> > comments "For audio playback, we convert samples of arbitrary format to
> > be 32 bit for our hardware".
>
> This doesn't really answer any of my technical questions about what's
> going on here.
>
> Please resubmit with a changelog explaining what the limitations are on
> both sides (DMA seems clear but the I2S also needs to be covered) and
> makes it clear why the functionality is being reduced like this. This
> will ensure that users understand why the change has been made - right
> now it looks like a serious functionality regression is being
> introduced so we really should make it clear why this is being done.
>
^ permalink raw reply
* cannot fetch arm git tree
From: Uwe Kleine-König @ 2011-01-16 11:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110116092315.GA27542@n2100.arm.linux.org.uk>
Hello Jello,
On Sun, Jan 16, 2011 at 09:23:15AM +0000, Russell King - ARM Linux wrote:
> On Sun, Jan 16, 2011 at 10:28:55AM +0800, Jello huang wrote:
> > Dear Russell,
> >
> > when i use git fetch,there arm some wrong with it.
> >
> > jello at jello-laptop:~/git/russell/linux-2.6-arm$git pull
> > error: Unable to find 89e4d4b145bb7e73b4c45671a84b401a5d8694c1 under
> > http://ftp.arm.linux.org.uk/pub/armlinux/kernel/git-cur/linux-2.6-arm.git
> > Cannot obtain needed blob 89e4d4b145bb7e73b4c45671a84b401a5d8694c1
> > while processing commit eda2e5dcc914b4d70f665443efc9780e89a5e5c1.
> > error: Fetch failed.
> >
> > What is the wrong?
>
> No idea. The tree has the object file in one of its pack files:
>
> | rmk at ZenIV:[linux-2.6-arm.git]:<1020> GIT_DIR=. git cat-file -p 89e4d4b145bb7e73b4c45671a84b401a5d8694c1|head
> |
> | List of maintainers and how to submit kernel changes
> |
> | Please try to follow the guidelines below. This will make things
> | easier on the maintainers. Not all of these guidelines matter for every
> | trivial patch so apply some common sense.
>
> and the pack info file lists all the pack files. Maybe you have a hash
> collision on a pack file with your repository?
Probably you have a corrupted pack file. Try renaming all packfiles
listed in
http://ftp.arm.linux.org.uk/pub/armlinux/kernel/git-cur/linux-2.6-arm.git/objects/info/packs
(i.e.
.git/objects/pack/pack-74405a23171b6debd894d4791e06956d6387022a.pack
etc.) and try refetching then. This happend to me after Ctrl-Cing an
earlier git-fetch. Git doesn't seem to handle that case.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH 2/2] arm: omap: remove duplicated headers
From: Felipe Balbi @ 2011-01-16 10:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1295174783-4099-1-git-send-email-balbi@ti.com>
A few headers are included twice, remove them.
Found the following errors using make includecheck:
arch/arm/mach-omap2/clock44xx_data.c: prm44xx.h is
included more than once.
arch/arm/mach-omap2/clockdomains44xx_data.c: cm1_44xx.h
is included more than once.
arch/arm/mach-omap2/clockdomains44xx_data.c: cm2_44xx.h
is included more than once.
arch/arm/mach-omap2/powerdomain2xxx_3xxx.c: prm-regbits-34xx.h
is included more than once.
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: linux-omap at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
Signed-off-by: Felipe Balbi <balbi@ti.com>
---
arch/arm/mach-omap2/clock44xx_data.c | 1 -
arch/arm/mach-omap2/clockdomains44xx_data.c | 2 --
arch/arm/mach-omap2/powerdomain2xxx_3xxx.c | 1 -
3 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/clock44xx_data.c b/arch/arm/mach-omap2/clock44xx_data.c
index e8cb32f..de9ec8d 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -34,7 +34,6 @@
#include "cm2_44xx.h"
#include "cm-regbits-44xx.h"
#include "prm44xx.h"
-#include "prm44xx.h"
#include "prm-regbits-44xx.h"
#include "control.h"
#include "scrm44xx.h"
diff --git a/arch/arm/mach-omap2/clockdomains44xx_data.c b/arch/arm/mach-omap2/clockdomains44xx_data.c
index 51920fc..10622c9 100644
--- a/arch/arm/mach-omap2/clockdomains44xx_data.c
+++ b/arch/arm/mach-omap2/clockdomains44xx_data.c
@@ -30,8 +30,6 @@
#include "cm1_44xx.h"
#include "cm2_44xx.h"
-#include "cm1_44xx.h"
-#include "cm2_44xx.h"
#include "cm-regbits-44xx.h"
#include "prm44xx.h"
#include "prcm44xx.h"
diff --git a/arch/arm/mach-omap2/powerdomain2xxx_3xxx.c b/arch/arm/mach-omap2/powerdomain2xxx_3xxx.c
index d523389..cf600e2 100644
--- a/arch/arm/mach-omap2/powerdomain2xxx_3xxx.c
+++ b/arch/arm/mach-omap2/powerdomain2xxx_3xxx.c
@@ -19,7 +19,6 @@
#include <plat/prcm.h>
#include "powerdomain.h"
-#include "prm-regbits-34xx.h"
#include "prm.h"
#include "prm-regbits-24xx.h"
#include "prm-regbits-34xx.h"
--
1.7.3.4.598.g85356
^ permalink raw reply related
* [PATCH] arm/tegra: Fix tegra irq_data conversion
From: Lennert Buytenhek @ 2011-01-16 10:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110116054127.1395.68849.stgit@localhost6.localdomain6>
On Sat, Jan 15, 2011 at 10:41:27PM -0700, Grant Likely wrote:
> Commit 37337a8d5e68d6e19075dbdb3acf4f1011dae972, "ARM: tegra: irq_data
> conversion." missed changing one reference to 'irq' in the function
> tegra_gpio_irq_set_type(). This patch fixes the build error.
>
> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Lennert Buytenhek <buytenh@secretlab.ca>
I built this queue against all defconfigs, but there doesn't seem to
be one for tegra at the moment, which is why I missed this.
^ permalink raw reply
* cannot fetch arm git tree
From: Russell King - ARM Linux @ 2011-01-16 9:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTikRrewCLGDTU7DjVssjpxz-EFK8AhRScAGPRumg@mail.gmail.com>
On Sun, Jan 16, 2011 at 10:28:55AM +0800, Jello huang wrote:
> Dear Russell,
>
> when i use git fetch,there arm some wrong with it.
>
> jello at jello-laptop:~/git/russell/linux-2.6-arm$git pull
> error: Unable to find 89e4d4b145bb7e73b4c45671a84b401a5d8694c1 under
> http://ftp.arm.linux.org.uk/pub/armlinux/kernel/git-cur/linux-2.6-arm.git
> Cannot obtain needed blob 89e4d4b145bb7e73b4c45671a84b401a5d8694c1
> while processing commit eda2e5dcc914b4d70f665443efc9780e89a5e5c1.
> error: Fetch failed.
>
> What is the wrong?
No idea. The tree has the object file in one of its pack files:
| rmk at ZenIV:[linux-2.6-arm.git]:<1020> GIT_DIR=. git cat-file -p 89e4d4b145bb7e73b4c45671a84b401a5d8694c1|head
|
| List of maintainers and how to submit kernel changes
|
| Please try to follow the guidelines below. This will make things
| easier on the maintainers. Not all of these guidelines matter for every
| trivial patch so apply some common sense.
and the pack info file lists all the pack files. Maybe you have a hash
collision on a pack file with your repository?
I suggest you do as I've always recommended: make sure your tree is up to
date with Linus' tree before fetching my tree. That way you avoid the
unnecessary download of large pack files.
> I have found the discussion linux-next: manual merge of
> the arm tree with the arm-current
> tree<http://forum.soft32.com/linux/linux-manual-merge-arm-tree-arm-current-tree-ftopict523173.html>
> with
> Uwe.But there is also Puzzled with me now.
How so?
^ permalink raw reply
* [PATCH 1/2] Add a common struct clk
From: Grant Likely @ 2011-01-16 7:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201101110854.15653.jeremy.kerr@canonical.com>
On Mon, Jan 10, 2011 at 5:54 PM, Jeremy Kerr <jeremy.kerr@canonical.com> wrote:
> Hi Russell,
>
>> Unless the locking problems can be resolved, the patches aren't ready.
>>
>> From what I've seen there's still quite a problem with what kind of
>> lock to use in the clock - mutex or spinlock.
>
> Yes, the clock driver may either use a spinlock or mutex.
>
> However, this exactly the same as the current clock code, my patches do not
> alter what we currently have.
>
> I do agree that we should define some specific semantics for the clock API
> with regards to sleeping, and I'll start a new thread about that. But we
> should definitely separate that issue from the problem of having multiple
> definitions for struct clk, which is what these patches address.
Given that each current struct clk implementation makes it's own
decisions about how to handle locking, would it not make sense to omit
locking entirely? At least as a first step? Let the clock ops
implement their own locking. Make enable count management their
responsibility too. That's all that the lock protects anyway. The
clk_* apis can fall directly through to the ops hooks with no
manipulation or locking. The way v3 of the patch worked.
Just having a common struct clk definition (without the locking) is
valuable on its own to get closer to supporting multiple platforms
with a single kernel on ARM. It certainly shouldn't be worse that the
current state. Locking consolidation can be implemented in follow-on
patches.
g.
^ permalink raw reply
* [PATCH 27/48] ARM: PL08x: avoid duplicating registers in txd and phychan structures
From: Dan Williams @ 2011-01-16 7:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110115092324.GX15996@n2100.arm.linux.org.uk>
On Sat, Jan 15, 2011 at 1:23 AM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Fri, Jan 14, 2011 at 05:35:41PM -0800, Dan Williams wrote:
>> On Mon, Jan 3, 2011 at 2:39 PM, Russell King - ARM Linux
>> <linux@arm.linux.org.uk> wrote:
>> > As we now have all the code accessing the phychan {csrc,cdst,clli,cctl,
>> > ccfg} members in one function, there's no point storing the data into
>> > the struct. ?Get rid of the struct members. ?Re-order the register dump
>> > in the dev_dbg() to reflect the order we write the registers to the DMA
>> > device.
>> >
>> > The txd {csrc,cdst,clli,cctl} values are duplicates of the lli[0]
>> > values, so there's no point duplicating these either. ?Program the DMAC
>> > registers directly from the lli[0] values.
>> >
>> > Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
>>
>> This one caused:
>> drivers/dma/amba-pl08x.c: In function 'pl08x_start_txd':
>> drivers/dma/amba-pl08x.c:205: warning: dereferencing 'void *' pointer
>
> That probably means you've got something out of order. ?I have them
> ordered in my git tree, I'll recheck there.
I rechecked here and I think everything is in order.
The line in question does not get touched in subsequent patches...
diff --git a/drivers/dma/amba-pl08x.c b/drivers/dma/amba-pl08x.c
index c025a4b..a1a18bd 100644
--- a/drivers/dma/amba-pl08x.c
+++ b/drivers/dma/amba-pl08x.c
@@ -193,33 +193,25 @@ static void pl08x_start_txd(struct pl08x_dma_chan *plchan,
{
struct pl08x_driver_data *pl08x = plchan->host;
struct pl08x_phy_chan *phychan = plchan->phychan;
- u32 val;
+ struct pl08x_lli *lli = &txd->llis_va[0];
+ u32 val, ccfg;
29/48 is the only other patch after this to touch pl08x_start_txd.
Double checked the sorted by subject mbox order matches the order they
are applied in git.
...nothing in the series touches the definition of llis_va in
include/linux/amba/pl08x.h.
e8689e63 (Linus Walleij 2010-09-28 15:57:37 +0200 113)
struct pl08x_txd {
e8689e63 (Linus Walleij 2010-09-28 15:57:37 +0200 114)
struct dma_async_tx_descriptor tx;
e8689e63 (Linus Walleij 2010-09-28 15:57:37 +0200 115)
struct list_head node;
e8689e63 (Linus Walleij 2010-09-28 15:57:37 +0200 116)
enum dma_data_direction direction;
d7244e9a (Russell King - ARM Linux 2011-01-03 22:43:35 +0000 117)
dma_addr_t src_addr;
d7244e9a (Russell King - ARM Linux 2011-01-03 22:43:35 +0000 118)
dma_addr_t dst_addr;
cace6585 (Russell King - ARM Linux 2011-01-03 22:37:31 +0000 119)
size_t len;
e8689e63 (Linus Walleij 2010-09-28 15:57:37 +0200 120)
dma_addr_t llis_bus;
e8689e63 (Linus Walleij 2010-09-28 15:57:37 +0200 121)
void *llis_va;
e8689e63 (Linus Walleij 2010-09-28 15:57:37 +0200 122)
bool active;
70b5ed6b (Russell King - ARM Linux 2011-01-03 22:40:13 +0000 123)
/* Default cctl value for LLIs */
70b5ed6b (Russell King - ARM Linux 2011-01-03 22:40:13 +0000 124)
u32 cctl;
4983a04f (Russell King - ARM Linux 2011-01-03 22:39:33 +0000 125) /*
4983a04f (Russell King - ARM Linux 2011-01-03 22:39:33 +0000 126)
* Settings to be put into the physical channe
4983a04f (Russell King - ARM Linux 2011-01-03 22:39:33 +0000 127)
* trigger this txd. Other registers are in l
4983a04f (Russell King - ARM Linux 2011-01-03 22:39:33 +0000 128) */
4983a04f (Russell King - ARM Linux 2011-01-03 22:39:33 +0000 129)
u32 ccfg;
e8689e63 (Linus Walleij 2010-09-28 15:57:37 +0200 130) };
--
Dan
^ permalink raw reply related
* Locking in the clk API
From: Grant Likely @ 2011-01-16 6:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110115151507.GD15996@n2100.arm.linux.org.uk>
2011/1/15 Russell King - ARM Linux <linux@arm.linux.org.uk>:
> On Sat, Jan 15, 2011 at 04:03:31PM +0100, Uwe Kleine-K?nig wrote:
>> Hi Russell,
>>
>> On Sat, Jan 15, 2011 at 02:53:58PM +0000, Russell King - ARM Linux wrote:
>> > We've been around returning EAGAIN, WARN_ONs, BUG_ONs, having clk_enable()
>> > vs clk_enable_atomic(), clk_enable_cansleep() vs clk_enable(), etc.
>> >
>> > There's been a lot of talk on this issue for ages with no real progress
>> > that I'm just going to repeat: let's unify those implementations which
>> > use a spinlock for their clks into one consolidated solution, and
>> > a separate consolidated solution for those which use a mutex.
>> >
>> > This will at least allow us to have _some_ consolidation of the existing
>> > implementations - and it doesn't add anything to the problem at hand.
>> > It might actually help identify what can be done at code level to resolve
>> > this issue.
>> Great, so how should we do it? ?Take Jeremy's patch and make the
>> differenciation between sleeping and atomic implementation a Kconfig
>> variable?
>
> No - I've been suggesting for about a week now about doing two entirely
> separate consolidations.
>
> I think it would be insane to do the consolidation of the two different
> implementations in one patch or even one patch set. ?There needs to be
> a consolidation of spinlock-based clks as one patch set, which is
> entirely separate and independent from the consolidation of mutex-based
> clks.
+1
>
> What if one of the consolidations turns out to be a problem? ?Do we want
> to throw both out, or do we want to keep as much as we possibly can?
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at ?http://www.tux.org/lkml/
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* [PATCH] arm/tegra: Fix tegra irq_data conversion
From: Grant Likely @ 2011-01-16 5:41 UTC (permalink / raw)
To: linux-arm-kernel
Commit 37337a8d5e68d6e19075dbdb3acf4f1011dae972, "ARM: tegra: irq_data
conversion." missed changing one reference to 'irq' in the function
tegra_gpio_irq_set_type(). This patch fixes the build error.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
arch/arm/mach-tegra/gpio.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-tegra/gpio.c b/arch/arm/mach-tegra/gpio.c
index bd06620..ad80488 100644
--- a/arch/arm/mach-tegra/gpio.c
+++ b/arch/arm/mach-tegra/gpio.c
@@ -207,9 +207,9 @@ static int tegra_gpio_irq_set_type(struct irq_data *d, unsigned int type)
spin_unlock_irqrestore(&bank->lvl_lock[port], flags);
if (type & (IRQ_TYPE_LEVEL_LOW | IRQ_TYPE_LEVEL_HIGH))
- __set_irq_handler_unlocked(irq, handle_level_irq);
+ __set_irq_handler_unlocked(d->irq, handle_level_irq);
else if (type & (IRQ_TYPE_EDGE_FALLING | IRQ_TYPE_EDGE_RISING))
- __set_irq_handler_unlocked(irq, handle_edge_irq);
+ __set_irq_handler_unlocked(d->irq, handle_edge_irq);
return 0;
}
^ permalink raw reply related
* State of LDP3430 platform
From: Paul Walmsley @ 2011-01-16 4:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110115233744.GA18159@n2100.arm.linux.org.uk>
On Sat, 15 Jan 2011, Russell King - ARM Linux wrote:
> On Sat, Jan 15, 2011 at 12:38:46PM -0700, Paul Walmsley wrote:
> > On Fri, 14 Jan 2011, Tony Lindgren wrote:
> >
> > > * Paul Walmsley <paul@pwsan.com> [101207 19:30]:
> > > > On Tue, 7 Dec 2010, Paul Walmsley wrote:
> > > >
> > > > Regarding the watchdog problem, unfortunately, I can't reproduce on the
> > > > BeagleBoard with v2.6.37-rc5 with either omap2plus_defconfig or
> > > > omap2plus_defconfig without CONFIG_WATCHDOG. If you send along your
> > > > .config, one of us can try to reproduce the problem with it. Do the
> > > > 2.6.38 hwmod and wdt patchsets fix the problem for .38, at least?
> > >
> > > I've been seeing this on my omap4 panda. While debugging it, I left
> > > u-boot console only running for a few minutes to see if that stays up.
> > > It did.. And after doing that somehow now my panda boots all the way
> > > and stays up. Weird.
> >
> > Hmmm, do you think the watchdog is what's killing it? I don't think
> > leaving u-boot running would affect that?
>
> Right, well, the LDP3430 (and probably all OMAP) is broken by my
> init_sched_clock() changes because I gave up with testing on OMAP
> platforms.
>
> Why does OMAP initialize its clock sources soo late, outside of
> the timer initialization? This means you have no counter in place
> (except for the jiffies counter) during early boot.
>
> Is there a reason why OMAP uniquely does this?
I don't think so.
Patch attached.
- Paul
[PATCH] OMAP: counter_32k: init clocksource as part of machine timer init
Linus's master branch, currently at commit
1b59be2a6cdcb5a12e18d8315c07c94a624de48f ("Merge branch 'slab/urgent'
of git://git.kernel.org/pub/scm/linux/kernel/git/penberg/slab-2.6"),
crashes during boot on OMAP4430 ES2.0 Panda:
[ 0.000000] OMAP clockevent source: GPTIMER1 at 32768 Hz
[ 0.000000] Unable to handle kernel NULL pointer dereference at virtual address 00000000
[ 0.000000] pgd = c0004000
[ 0.000000] [00000000] *pgd=00000000
[ 0.000000] Internal error: Oops: 80000005 [#1] SMP
[ 0.000000] last sysfs file:
[ 0.000000] Modules linked in:
[ 0.000000] CPU: 0 Tainted: G W (2.6.37-07734-g2467802 #7)
[ 0.000000] PC is at 0x0
[ 0.000000] LR is at sched_clock_poll+0x2c/0x3c
[ 0.000000] pc : [<00000000>] lr : [<c0060b74>] psr: 600001d3
[ 0.000000] sp : c058bfd0 ip : c058a000 fp : 00000000
[ 0.000000] r10: 00000000 r9 : 411fc092 r8 : 800330c8
[ 0.000000] r7 : c05a08e0 r6 : c0034c48 r5 : c05ffc40 r4 : c0034c4c
[ 0.000000] r3 : c05ffe6c r2 : c05a0bc0 r1 : c059f098 r0 : 00000000
[ 0.000000] Flags: nZCv IRQs off FIQs off Mode SVC_32 ISA ARM Segment kernel
[ 0.000000] Control: 10c53c7f Table: 8000404a DAC: 00000017
This is due to the recent ARM init_sched_clock() changes and the late
initialization of the counter_32k clock source:
http://marc.info/?l=linux-omap&m=129513468605208&w=2
Fix by initializing the counter_32k clocksource during the machine timer
initialization.
Reported-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
---
arch/arm/mach-omap1/time.c | 7 +++++++
arch/arm/mach-omap2/timer-gp.c | 10 ++++++++--
arch/arm/plat-omap/counter_32k.c | 3 +--
arch/arm/plat-omap/include/plat/common.h | 1 +
4 files changed, 17 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap1/time.c b/arch/arm/mach-omap1/time.c
index ed7a61f..6ec65e5 100644
--- a/arch/arm/mach-omap1/time.c
+++ b/arch/arm/mach-omap1/time.c
@@ -244,6 +244,13 @@ static void __init omap_timer_init(void)
omap_init_mpu_timer(rate);
omap_init_clocksource(rate);
+ /*
+ * XXX Since this file seems to deal mostly with the MPU timer,
+ * this doesn't seem like the correct place for the sync timer
+ * clocksource init.
+ */
+ if (!cpu_is_omap7xx() && !cpu_is_omap15xx())
+ omap_init_clocksource_32k();
}
struct sys_timer omap_timer = {
diff --git a/arch/arm/mach-omap2/timer-gp.c b/arch/arm/mach-omap2/timer-gp.c
index 4e48e78..57d53e0 100644
--- a/arch/arm/mach-omap2/timer-gp.c
+++ b/arch/arm/mach-omap2/timer-gp.c
@@ -42,6 +42,8 @@
#include "timer-gp.h"
+#include <plat/common.h>
+
/* MAX_GPTIMER_ID: number of GPTIMERs on the chip */
#define MAX_GPTIMER_ID 12
@@ -176,10 +178,14 @@ static void __init omap2_gp_clockevent_init(void)
/*
* When 32k-timer is enabled, don't use GPTimer for clocksource
* instead, just leave default clocksource which uses the 32k
- * sync counter. See clocksource setup in see plat-omap/common.c.
+ * sync counter. See clocksource setup in plat-omap/timer-32k.c
*/
-static inline void __init omap2_gp_clocksource_init(void) {}
+static void __init omap2_gp_clocksource_init(void)
+{
+ omap_init_clocksource_32k();
+}
+
#else
/*
* clocksource
diff --git a/arch/arm/plat-omap/counter_32k.c b/arch/arm/plat-omap/counter_32k.c
index ea46440..0367998 100644
--- a/arch/arm/plat-omap/counter_32k.c
+++ b/arch/arm/plat-omap/counter_32k.c
@@ -160,7 +160,7 @@ void read_persistent_clock(struct timespec *ts)
*ts = *tsp;
}
-static int __init omap_init_clocksource_32k(void)
+int __init omap_init_clocksource_32k(void)
{
static char err[] __initdata = KERN_ERR
"%s: can't register clocksource!\n";
@@ -195,7 +195,6 @@ static int __init omap_init_clocksource_32k(void)
}
return 0;
}
-arch_initcall(omap_init_clocksource_32k);
#endif /* !(defined(CONFIG_ARCH_OMAP730) || defined(CONFIG_ARCH_OMAP15XX)) */
diff --git a/arch/arm/plat-omap/include/plat/common.h b/arch/arm/plat-omap/include/plat/common.h
index 6b8088e..84c707f 100644
--- a/arch/arm/plat-omap/include/plat/common.h
+++ b/arch/arm/plat-omap/include/plat/common.h
@@ -35,6 +35,7 @@ struct sys_timer;
extern void omap_map_common_io(void);
extern struct sys_timer omap_timer;
+extern int __init omap_init_clocksource_32k(void);
extern void omap_reserve(void);
--
1.7.2.3
^ permalink raw reply related
* cannot fetch arm git tree
From: Jello huang @ 2011-01-16 2:28 UTC (permalink / raw)
To: linux-arm-kernel
Dear Russell,
when i use git fetch,there arm some wrong with it.
jello at jello-laptop:~/git/russell/linux-2.6-arm$git pull
error: Unable to find 89e4d4b145bb7e73b4c45671a84b401a5d8694c1 under
http://ftp.arm.linux.org.uk/pub/armlinux/kernel/git-cur/linux-2.6-arm.git
Cannot obtain needed blob 89e4d4b145bb7e73b4c45671a84b401a5d8694c1
while processing commit eda2e5dcc914b4d70f665443efc9780e89a5e5c1.
error: Fetch failed.
What is the wrong?I have found the discussion linux-next: manual merge of
the arm tree with the arm-current
tree<http://forum.soft32.com/linux/linux-manual-merge-arm-tree-arm-current-tree-ftopict523173.html>
with
Uwe.But there is also Puzzled with me now.
Best regards,
Jello Huang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20110116/2174801a/attachment.html>
^ permalink raw reply
* [PATCH] arm/ixp4xx: Rename FREQ macro to avoid collisions
From: Krzysztof Halasa @ 2011-01-15 23:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <m38vylixqw.fsf@intrepid.localdomain>
Author: Ben Hutchings <ben@decadent.org.uk>
arm/ixp4xx: Rename FREQ macro to avoid collisions
FREQ is a ridiculously short name for a platform-specific macro in a
generic header, and it now conflicts with an enumeration in the
gspca/ov519 driver.
Also delete conditional reference to ixp4xx_get_board_tick_rate()
which is not defined anywhere.
--- a/arch/arm/mach-ixp4xx/common.c
+++ b/arch/arm/mach-ixp4xx/common.c
@@ -432,7 +432,7 @@ static struct clocksource clocksource_ixp4xx = {
.flags = CLOCK_SOURCE_IS_CONTINUOUS,
};
-unsigned long ixp4xx_timer_freq = FREQ;
+unsigned long ixp4xx_timer_freq = IXP4XX_TIMER_FREQ;
EXPORT_SYMBOL(ixp4xx_timer_freq);
static void __init ixp4xx_clocksource_init(void)
{
@@ -496,7 +496,7 @@ static struct clock_event_device clockevent_ixp4xx = {
static void __init ixp4xx_clockevent_init(void)
{
- clockevent_ixp4xx.mult = div_sc(FREQ, NSEC_PER_SEC,
+ clockevent_ixp4xx.mult = div_sc(IXP4XX_TIMER_FREQ, NSEC_PER_SEC,
clockevent_ixp4xx.shift);
clockevent_ixp4xx.max_delta_ns =
clockevent_delta2ns(0xfffffffe, &clockevent_ixp4xx);
--- a/arch/arm/mach-ixp4xx/include/mach/timex.h
+++ b/arch/arm/mach-ixp4xx/include/mach/timex.h
@@ -10,6 +10,7 @@
* 66.66... MHz. We do a convulted calculation of CLOCK_TICK_RATE b/c the
* timer register ignores the bottom 2 bits of the LATCH value.
*/
-#define FREQ 66666000
-#define CLOCK_TICK_RATE (((FREQ / HZ & ~IXP4XX_OST_RELOAD_MASK) + 1) * HZ)
+#define IXP4XX_TIMER_FREQ 66666000
+#define CLOCK_TICK_RATE \
+ (((IXP4XX_TIMER_FREQ / HZ & ~IXP4XX_OST_RELOAD_MASK) + 1) * HZ)
--- a/drivers/input/misc/ixp4xx-beeper.c
+++ b/drivers/input/misc/ixp4xx-beeper.c
@@ -69,11 +69,7 @@ static int ixp4xx_spkr_event(struct input_dev *dev, unsigned int type, unsigned
}
if (value > 20 && value < 32767)
-#ifndef FREQ
- count = (ixp4xx_get_board_tick_rate() / (value * 4)) - 1;
-#else
- count = (FREQ / (value * 4)) - 1;
-#endif
+ count = (IXP4XX_TIMER_FREQ / (value * 4)) - 1;
ixp4xx_spkr_control(pin, count);
--
Krzysztof Halasa
^ permalink raw reply
* [PATCH] IXP4xx: Fix qmgr_release_queue() flushing unexpected queue entries.
From: Krzysztof Halasa @ 2011-01-15 23:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <m38vylixqw.fsf@intrepid.localdomain>
Queues should be empty when released, if not, there is a safety valve.
Make sure the queue is usable after it triggers.
--- a/arch/arm/mach-ixp4xx/ixp4xx_qmgr.c
+++ b/arch/arm/mach-ixp4xx/ixp4xx_qmgr.c
@@ -265,6 +265,11 @@ void qmgr_release_queue(unsigned int queue)
qmgr_queue_descs[queue], queue);
qmgr_queue_descs[queue][0] = '\x0';
#endif
+
+ while ((addr = qmgr_get_entry(queue)))
+ printk(KERN_ERR "qmgr: released queue %i not empty: 0x%08X\n",
+ queue, addr);
+
__raw_writel(0, &qmgr_regs->sram[queue]);
used_sram_bitmap[0] &= ~mask[0];
@@ -275,10 +280,6 @@ void qmgr_release_queue(unsigned int queue)
spin_unlock_irq(&qmgr_lock);
module_put(THIS_MODULE);
-
- while ((addr = qmgr_get_entry(queue)))
- printk(KERN_ERR "qmgr: released queue %i not empty: 0x%08X\n",
- queue, addr);
}
static int qmgr_init(void)
--
Krzysztof Halasa
^ 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