* Re: Can't boot 2.6.30 powerpc kernel under qemu.
From: Benjamin Herrenschmidt @ 2009-06-30 10:50 UTC (permalink / raw)
To: michael
Cc: Stephen Rothwell, linuxppc-dev, Jeremy Kerr, Rob Landley,
linux-kernel
In-Reply-To: <1246321478.4621.11.camel@concordia>
On Tue, 2009-06-30 at 10:24 +1000, Michael Ellerman wrote:
> On Mon, 2009-06-29 at 18:34 -0500, Rob Landley wrote:
> > Which suggested that the problem was the new CONFIG_PPC_OF_BOOT_TRAMPOLINE
> > symbol wasn't set, and once I switched that on it started working again.
>
> What defconfig are you using? It sounds like maybe something should be
> 'select'ing OF_BOOT_TRAMPOLINE.
Right, pmac, pseries and chrp probably ... though I don't like select
for a user-visible option, I'd rather fix things if I inadvertently
forgot the "default y" here, after all, one may want to do a minimum
kdump kernel without prom_init.c in it.
Cheers,
Ben.
>
> > > linuxppc-dev@lists.ozlabs.org is the one you want for this:
> > >
> > > https://lists.ozlabs.org/listinfo/linuxppc-dev
> >
> > Cool! Is there a reason it's hidden? (Or at least not listed in either
> > vger.kernel.org's list info page or in the "Maling lists" page linked from
> > ozlabs.org's top level web page.) Just curious, I couldn't find it when I
> > looked in the obvious (to me) places.
>
> It's not hidden, it's just in the process of moving from ozlabs.org to
> lists.ozlabs.org - and it's a bit hard to find in the process. I've
> updated the ozlabs.org page to point to it in the meantime.
>
> It's also in maintainers :D
>
> LINUX FOR POWERPC (32-BIT AND 64-BIT)
> P: Benjamin Herrenschmidt
> M: benh@kernel.crashing.org
> P: Paul Mackerras
> M: paulus@samba.org
> W: http://www.penguinppc.org/
> L: linuxppc-dev@ozlabs.org
> T: git git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git
> S: Supported
>
>
> cheers
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: Inline Assembly queries
From: Benjamin Herrenschmidt @ 2009-06-30 10:41 UTC (permalink / raw)
To: kernel mailz; +Cc: Scott Wood, gcc-help, linuxppc-dev
In-Reply-To: <abe8a1fd0906292227p15fbfe34r595e80db780b77ca@mail.gmail.com>
On Tue, 2009-06-30 at 10:57 +0530, kernel mailz wrote:
> Hi Scott,
> I agree with you, kind of understand that it is required.
> But buddy unless you see some construct work or by adding the
> construct a visible difference is there, the concept is just piece of
> theory.
In this case you'd rather get the theory right :-) The problem here is
that doing it wrong won't bite most of the time ... until for some
reason gcc decides to optimize things, for example by moving things
around, and kaboom ! But it may only happen in one out of 100 cases of
the same inline function depending on the surrounding code.
> I am trying all the kernel code inline assembly to find an example
> that works differently with memory.
Well, we recently had an example in the atomic64 code for 32-bit that
Paulus wrote, where we discovered we were missing the memory clobber in
local_irq_restore() iirc. On a base UP build, we did observe the load
and stores within the local_irq_save/restore section being moved to
outside of it by gcc.
> For instance take atomic_add , atomic_add_return, while the
> atomic_add_return has the "memory", atomic_add skips it.
There is a reason for the slightly different semantics here.
The base atomic ops such as atomic_add are defined as having no side
effects and to allow re-ordering. Thus atomic_add has an explicit
clobber of the actual variable that's incremented but nothing else and
no other memory barrier instruction.
The variants that -return- something, however, have been granted
stronger semantics, because they have been (ab)used to construct what
effectively is semaphores or locks by callers, and thus we added
stronger memory barriers to avoid re-ordering of loads and stores around
the atomic operation.
Cheers,
Ben.
> -TZ
>
> On Tue, Jun 30, 2009 at 12:57 AM, Scott Wood<scottwood@freescale.com> wrote:
> > On Mon, Jun 29, 2009 at 09:19:57PM +0530, kernel mailz wrote:
> >> I tried a small example
> >>
> >> int *p = 0x1000;
> >> int a = *p;
> >> asm("sync":::"memory");
> >> a = *p;
> >>
> >> and
> >>
> >> volatile int *p = 0x1000;
> >> int a = *p;
> >> asm("sync");
> >> a = *p
> >>
> >> Got the same assembly.
> >> Which is right.
> >>
> >> So does it mean, if proper use of volatile is done, there is no need
> >> of "memory" ?
> >
> > No. As I understand it, volatile concerns deletion of the asm statement
> > (if no outputs are used) and reordering with respect to other asm
> > statements (not sure whether GCC will actually do this), while the memory
> > clobber concerns optimization of non-asm loads/stores around the asm
> > statement.
> >
> >> static inline unsigned long
> >> __xchg_u32(volatile void *p, unsigned long val)
> >> {
> >> unsigned long prev;
> >>
> >> __asm__ __volatile__(
> >>
> >> "1: lwarx %0,0,%2 \n"
> >>
> >> " stwcx. %3,0,%2 \n\
> >> bne- 1b"
> >>
> >> : "=&r" (prev), "+m" (*(volatile unsigned int *)p)
> >> : "r" (p), "r" (val)
> >> // :"memory","cc");
> >>
> >> return prev;
> >> }
> >> #define ADDR 0x1000
> >> int main()
> >> {
> >> __xchg_u32((void*)ADDR, 0x2000);
> >> __xchg_u32((void*)ADDR, 0x3000);
> >>
> >> return 0;
> >>
> >> }
> >>
> >> Got the same asm, when compiled with O1 , with / without "memory" clobber
> >
> > This isn't a good test case, because there's nothing other than inline
> > asm going on in that function for GCC to optimize. Plus, it's generally
> > not a good idea, when talking about what the compiler is or isn't allowed
> > to do, to point to a single test case (or even several) and say that it
> > isn't required because you don't notice a difference. Even if there were
> > no code at all with which it made a difference with GCC version X, it
> > could make a difference with GCC version X+1.
> >
> > -Scott
> >
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: Inline Assembly queries
From: Benjamin Herrenschmidt @ 2009-06-30 10:43 UTC (permalink / raw)
To: David Howells; +Cc: gcc-help, linuxppc-dev, kernel mailz
In-Reply-To: <30098.1246291036@redhat.com>
On Mon, 2009-06-29 at 16:57 +0100, David Howells wrote:
> kernel mailz <kernelmailz@googlemail.com> wrote:
>
> > asm("sync");
>
> Isn't gcc free to discard this as it has no dependencies, no indicated side
> effects, and isn't required to be kept? I think this should probably be:
>
> asm volatile("sync");
It should also have a "memory" clobber or it's pointless since gcc would
otherwise be free to move load and stores accross that barrier.
Cheers,
Ben.
^ permalink raw reply
* Re: Can't boot 2.6.30 powerpc kernel under qemu.
From: Benjamin Herrenschmidt @ 2009-06-30 10:24 UTC (permalink / raw)
To: Rob Landley; +Cc: Stephen Rothwell, linuxppc-dev, Jeremy Kerr, linux-kernel
In-Reply-To: <200906291834.07902.rob@landley.net>
On Mon, 2009-06-29 at 18:34 -0500, Rob Landley wrote:
>
> Which suggested that the problem was the new
> CONFIG_PPC_OF_BOOT_TRAMPOLINE
> symbol wasn't set, and once I switched that on it started working
> again.
Ah, I might have forgot to set it to default y...
> > linuxppc-dev@lists.ozlabs.org is the one you want for this:
> >
> > https://lists.ozlabs.org/listinfo/linuxppc-dev
>
> Cool! Is there a reason it's hidden? (Or at least not listed in
> either
> vger.kernel.org's list info page or in the "Maling lists" page linked
> from
> ozlabs.org's top level web page.) Just curious, I couldn't find it
> when I
> looked in the obvious (to me) places.
It's a glitch of the transition from ozlabs.org to lists.ozlabs.org for
lists... they haven't all moved over yet so it's still a bit messy.
> Rob
>
> P.S. Yes I tried google: top hit for "linux powerpc list" is
> penguinppc.org,
> which links to mailing lists on the right which is the ozlabs.org page
> that
> doesn't list linuxppc-dev. In fact the entire first page of google
> hits for
> that search doesn't give a hint of the existence of that list,
> although some
> of the later ones might if I clicked through more of them...
I'll check with Stephen if we can get the ozlabs.org page a link to the
new lists.ozlabs.org or something like that...
Cheers,
Ben.
^ permalink raw reply
* Re: Inline Assembly queries
From: Paul Mackerras @ 2009-06-30 9:52 UTC (permalink / raw)
To: kernel mailz; +Cc: gcc-help, linuxppc-dev, Ian Lance Taylor
In-Reply-To: <abe8a1fd0906292253ye4595c9wb0c085b7d89aea7@mail.gmail.com>
kernel mailz writes:
> Consider atomic_add and atomic_add_return in kernel code.
> I am not able to figure out why "memory" is added in latter
The "memory" indicates that gcc should not reorder accesses to memory
from one side of the asm to the other. The reason for putting it on
the atomic ops that return a value is that they are sometimes used to
implement locks or other synchronization primitives.
Paul.
^ permalink raw reply
* Re: Inline Assembly queries
From: Andrew Haley @ 2009-06-30 9:30 UTC (permalink / raw)
To: kernel mailz; +Cc: gcc-help, linuxppc-dev, Ian Lance Taylor
In-Reply-To: <abe8a1fd0906292253ye4595c9wb0c085b7d89aea7@mail.gmail.com>
kernel mailz wrote:
> Consider atomic_add and atomic_add_return in kernel code.
>
> On Tue, Jun 30, 2009 at 2:59 AM, Ian Lance Taylor<iant@google.com> wrote:
>> kernel mailz <kernelmailz@googlemail.com> writes:
>>
>>> I tried a small example
>>>
>>> int *p = 0x1000;
>>> int a = *p;
>>> asm("sync":::"memory");
>>> a = *p;
>>>
>>> and
>>>
>>> volatile int *p = 0x1000;
>>> int a = *p;
>>> asm("sync");
>>> a = *p
>>>
>>> Got the same assembly.
>>> Which is right.
>>>
>>> So does it mean, if proper use of volatile is done, there is no need
>>> of "memory" ?
>> You have to consider the effects of inlining, which may bring in other
>> memory loads and stores through non-volatile pointers.
> Consider
>
> static __inline__ void atomic_add(int a, atomic_t *v)
> {
> int t;
>
> __asm__ __volatile__(
> "1: lwarx %0,0,%3 # atomic_add\n\
> add %0,%2,%0\n"
> PPC405_ERR77(0,%3)
> " stwcx. %0,0,%3 \n\
> bne- 1b"
> : "=&r" (t), "+m" (v->counter)
> : "r" (a), "r" (&v->counter)
> : "cc");
> }
>
> static __inline__ int atomic_add_return(int a, atomic_t *v)
> {
> int t;
>
> __asm__ __volatile__(
> LWSYNC_ON_SMP
> "1: lwarx %0,0,%2 # atomic_add_return\n\
> add %0,%1,%0\n"
> PPC405_ERR77(0,%2)
> " stwcx. %0,0,%2 \n\
> bne- 1b"
> ISYNC_ON_SMP
> : "=&r" (t)
> : "r" (a), "r" (&v->counter)
> : "cc", "memory");
>
> return t;
> }
>
> I am not able to figure out why "memory" is added in latter
The latter, as well as its stated purpose, forms a memory barrier, so the
compiler must be prevented from moving memory access across it. See
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2745.html
Andrew.
^ permalink raw reply
* Re: [PATCH] alsa/soc: add locking to mpc5200-psc-ac97 driver
From: Mark Brown @ 2009-06-30 8:59 UTC (permalink / raw)
To: Jon Smirl; +Cc: linuxppc-dev, alsa-devel
In-Reply-To: <9e4733910906291726h5cd5bdf8ve7e946aef855ac07@mail.gmail.com>
On Mon, Jun 29, 2009 at 08:26:12PM -0400, Jon Smirl wrote:
> Does your touchscreen driver use this mutex? Or was this mutex needed
> just for the AC97 driver?
It's in the register accesses so everything accessing the chip registers
will use it.
^ permalink raw reply
* AW: Direct MII connection between MPC8313 and VIRTEX FPGA
From: Frank Prepelica @ 2009-06-30 8:35 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
> What kernel version are you using?
We are using kernel version 2.6.24. I've searched for "current speed" in =
version 2.6.28.7 and I've found that string.
> Yes, you need to modify the DTB. You have a back to back MII
> connection, not a phy, so you do *not* want to have a PHY node in the
> device tree.
Hmm, but I do have a "PHY", don't I?. The "PHY" will be emulated in the =
FPGA. Of course, it's not a physical PHY but it should look like one.
So, do I really need the remove the complete PHY description in the DTB?
=09
=20
=20
Frank Prepelica
Software Design Engineer
Ubidyne GmbH
Lise-Meitner-Str.-14
89081 Ulm - Germany
> -----Urspr=FCngliche Nachricht-----
> Von: Grant Likely [mailto:grant.likely@secretlab.ca]
> Gesendet: Montag, 29. Juni 2009 17:40
> An: Frank Prepelica
> Cc: linuxppc-dev@ozlabs.org
> Betreff: Re: Direct MII connection between MPC8313 and VIRTEX FPGA
>=20
> On Mon, Jun 29, 2009 at 2:23 AM, Frank
> Prepelica<Frank.Prepelica@ubidyne.com> wrote:
> > Hi Grant
> >
> > Thanks for your response!
> >
> > I have searched for "current-speed" in drivers/net/fec_mpc52xx.c but =
I
> cannot find anything. However we are using the gianfar.c Ethernet =
driver.
> > Do you know whether this driver supports fixed MII links without =
PHY?
>=20
> What kernel version are you using?
>=20
> > I've got another question regarding MII connection between and MPC =
and a
> Virtex FPGA. Whats about the PHY address which has to be set in the =
DTB
> file? Do I have to modify the DTB at all?
>=20
> Yes, you need to modify the DTB. You have a back to back MII
> connection, not a phy, so you do *not* want to have a PHY node in the
> device tree.
>=20
> g.
>=20
> --
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: PCI device support in Open Firmware (device tree syntax)
From: Johnny Hung @ 2009-06-30 7:33 UTC (permalink / raw)
To: Marco Stornelli, linux-embedded, linuxppc-dev
In-Reply-To: <2ea1731b0906292329t30cdc9a6q1fc36dc2273a2931@mail.gmail.com>
2009/6/30 Marco Stornelli <marco.stornelli@gmail.com>:
> 2009/6/30 Johnny Hung <johnny.hacking@gmail.com>:
>> Thanks for your reply. So there are no PCI device resource info in
>> flat device tree.
>> How do PCI device resources be assign in general case or is there any example?
>> I am so confusing, would you please give me detailed describle?
>>
>> BRs, H. Johnny
>>>
>
> You should look at your bootloader about the initial configuration of
> the pci device, in general it should (more or less) do the work of
> BIOS as you said. After that the kernel can probe them.
>
> Marco
>
You are right. u-boot do PCI device BAR resources assign and flat
device tree describe PCI device interrupt-map. I use "lspci -s xxx -x"
for the PCI device, the resources was assigned properly.
Thanks.
BRs, H. Johnny
^ permalink raw reply
* USB Host support on MPC8536DS
From: Felix Radensky @ 2009-06-30 7:03 UTC (permalink / raw)
To: linuxppc-dev
Hi,
Is USB host functionality supported by mainline kernel on MPC8536DS ?
Are there any limitations (e.g not all host ports supported, etc.) ?
Thanks a lot.
Felix.
--
View this message in context: http://www.nabble.com/USB-Host-support-on-MPC8536DS-tp24267110p24267110.html
Sent from the linuxppc-dev mailing list archive at Nabble.com.
^ permalink raw reply
* Re: Inline Assembly queries
From: kernel mailz @ 2009-06-30 5:27 UTC (permalink / raw)
To: Scott Wood; +Cc: gcc-help, linuxppc-dev
In-Reply-To: <20090629192722.GA12789@b07421-ec1.am.freescale.net>
Hi Scott,
I agree with you, kind of understand that it is required.
But buddy unless you see some construct work or by adding the
construct a visible difference is there, the concept is just piece of
theory.
I am trying all the kernel code inline assembly to find an example
that works differently with memory.
For instance take atomic_add , atomic_add_return, while the
atomic_add_return has the "memory", atomic_add skips it.
-TZ
On Tue, Jun 30, 2009 at 12:57 AM, Scott Wood<scottwood@freescale.com> wrote=
:
> On Mon, Jun 29, 2009 at 09:19:57PM +0530, kernel mailz wrote:
>> I tried a small example
>>
>> int *p =3D 0x1000;
>> int a =3D *p;
>> asm("sync":::"memory");
>> a =3D *p;
>>
>> and
>>
>> volatile int *p =3D 0x1000;
>> int a =3D *p;
>> asm("sync");
>> a =3D *p
>>
>> Got the same assembly.
>> Which is right.
>>
>> So does it mean, if proper use of volatile is done, there is no need
>> of "memory" ?
>
> No. =A0As I understand it, volatile concerns deletion of the asm statemen=
t
> (if no outputs are used) and reordering with respect to other asm
> statements (not sure whether GCC will actually do this), while the memory
> clobber concerns optimization of non-asm loads/stores around the asm
> statement.
>
>> static inline unsigned long
>> __xchg_u32(volatile void *p, unsigned long val)
>> {
>> =A0 =A0 =A0 =A0unsigned long prev;
>>
>> =A0 =A0 =A0 =A0__asm__ __volatile__(
>>
>> "1: =A0 =A0 lwarx =A0 %0,0,%2 \n"
>>
>> " =A0 =A0 =A0 stwcx. =A0%3,0,%2 \n\
>> =A0 =A0 =A0 =A0bne- =A0 =A01b"
>>
>> =A0 =A0 =A0 =A0: "=3D&r" (prev), "+m" (*(volatile unsigned int *)p)
>> =A0 =A0 =A0 =A0: "r" (p), "r" (val)
>> // =A0 =A0 =A0 =A0:"memory","cc");
>>
>> =A0 =A0 =A0 =A0return prev;
>> }
>> #define ADDR 0x1000
>> int main()
>> {
>> =A0 =A0 =A0 =A0__xchg_u32((void*)ADDR, 0x2000);
>> =A0 =A0 =A0 =A0__xchg_u32((void*)ADDR, 0x3000);
>>
>> =A0 =A0 =A0 =A0return 0;
>>
>> }
>>
>> Got the same asm, when compiled with O1 , with / without "memory" clobbe=
r
>
> This isn't a good test case, because there's nothing other than inline
> asm going on in that function for GCC to optimize. =A0Plus, it's generall=
y
> not a good idea, when talking about what the compiler is or isn't allowed
> to do, to point to a single test case (or even several) and say that it
> isn't required because you don't notice a difference. =A0Even if there we=
re
> no code at all with which it made a difference with GCC version X, it
> could make a difference with GCC version X+1.
>
> -Scott
>
^ permalink raw reply
* [PATCH] Remove 'SBC8240 Wind River' Device Driver Code
From: Subrata Modak @ 2009-06-30 5:45 UTC (permalink / raw)
To: Scott Wood, David Woodhouse
Cc: carolyn.j.smith, Stephen Rothwell, Adrian Bunk, Jim Cromie,
linux-kernel, Linuxppc-dev, Sachin P Sant, linux-next,
Alexander Beregalov, Balbir Singh
In-Reply-To: <20090626142513.10380.20811.sendpatchset@gekko-lp3.ltc.austin.ibm.com>
Scott/David,
Your say on this patch below ?
Regards--
Subrata
On Fri, 2009-06-26 at 09:25 -0500, Subrata Modak wrote:
> Hi David/Scott,
>
> Today's next tree(20090626) produced the following build error:
>
> CC [M] drivers/mtd/maps/sbc8240.o
> drivers/mtd/maps/sbc8240.c:31:1: warning: "DEBUG" redefined
> In file included from drivers/mtd/maps/sbc8240.c:23:
> include/linux/mtd/mtd.h:333:1: warning: this is the location of the previous definition
> drivers/mtd/maps/sbc8240.c: In function 'init_sbc8240_mtd':
> drivers/mtd/maps/sbc8240.c:172: warning: passing argument 1 of 'simple_map_init' from incompatible pointer type
> drivers/mtd/maps/sbc8240.c:177: error: 'struct mtd_info' has no member named 'module'
> make[3]: *** [drivers/mtd/maps/sbc8240.o] Error 1
> make[2]: *** [drivers/mtd/maps] Error 2
> make[1]: *** [drivers/mtd] Error 2
> make: *** [drivers] Error 2
>
> I remember reporting this log back in April, when you suggested in removing it:
> http://lkml.org/lkml/2009/4/21/476,
>
> >On Tue, 2009-04-21 at 15:00 -0500, Scott Wood wrote:
> >Subrata Modak wrote:
> > > This is a very old one. DoesnB4t seem to go away. Reported this earlier
> > > on 14th April:
> > > http://lkml.org/lkml/2009/4/14/483,
> > >
> > > CC [M] drivers/mtd/maps/sbc8240.o
> > > drivers/mtd/maps/sbc8240.c:31:1: warning: "DEBUG" redefined
> > > In file included from drivers/mtd/maps/sbc8240.c:23:
> > > include/linux/mtd/mtd.h:339:1: warning: this is the location of the
> > > previous definition
> > > drivers/mtd/maps/sbc8240.c: In function b\x18init_sbc8240_mtdb\x19:
> > > drivers/mtd/maps/sbc8240.c:172: error: b\x18sbc8240_mtdb\x19 undeclared (first
> > > use in this function)
> > > drivers/mtd/maps/sbc8240.c:172: error: (Each undeclared identifier is
> > > reported only once
> > > drivers/mtd/maps/sbc8240.c:172: error: for each function it appears in.)
> > > drivers/mtd/maps/sbc8240.c: In function b\x18cleanup_sbc8240_mtdb\x19:
> > > drivers/mtd/maps/sbc8240.c:233: error: b\x18sbc8240_mtdb\x19 undeclared (first
> > > use in this function)
> >
> > This looks like an arch/ppc orphan. It's not enabled by any defconfig,
> > and it doesn't look like it does anything that physmap_of can't do.
> >
> > I'd just remove it.
> >
> > -Scott
>
> I tried to gather some more info about this driver from the link
> mentioned in Kconfig:
> http://www.windriver.com/products/sbc8240/,
> without much success.
>
> If there are no issues, can you please apply this patch to remove it ?
>
> To: David Woodhouse <dwmw2@infradead.org>,
> To: Scott Wood <scottwood@freescale.com>,
> Cc: Jim Cromie <jim.cromie@gmail.com>,
> Cc: carolyn.j.smith@exgate.tek.com,
> Cc: Adrian Bunk <bunk@kernel.org>,
> Cc: Sachin P Sant <sachinp@linux.vnet.ibm.com>,
> Cc: Balbir Singh <balbir@linux.vnet.ibm.com>,
> Cc: Stephen Rothwell <sfr@canb.auug.org.au>,
> Cc: linux-kernel <linux-kernel@vger.kernel.org>,
> Cc: Linuxppc-dev <Linuxppc-dev@ozlabs.org>,
> Cc: linux-next <linux-next@vger.kernel.org>,
> Cc: Alexander Beregalov <a.beregalov@gmail.com>
>
>
> Signed-off-by: Subrata Modak <subrata@linux.vnet.ibm.com>
> Tested-on-PPC64-by: Subrata Modak <subrata@linux.vnet.ibm.com>
> ---
>
> diff -uprN a/drivers/mtd/maps/Kconfig b/drivers/mtd/maps/Kconfig
> --- a/drivers/mtd/maps/Kconfig 2009-06-26 07:36:23.000000000 -0500
> +++ b/drivers/mtd/maps/Kconfig 2009-06-26 07:39:34.000000000 -0500
> @@ -284,13 +284,6 @@ config MTD_L440GX
>
> BE VERY CAREFUL.
>
> -config MTD_SBC8240
> - tristate "Flash device on SBC8240"
> - depends on MTD_JEDECPROBE && 8260
> - help
> - Flash access on the SBC8240 board from Wind River. See
> - <http://www.windriver.com/products/sbc8240/>
> -
> config MTD_TQM8XXL
> tristate "CFI Flash device mapped on TQM8XXL"
> depends on MTD_CFI && TQM8xxL
> diff -uprN a/drivers/mtd/maps/Makefile b/drivers/mtd/maps/Makefile
> --- a/drivers/mtd/maps/Makefile 2009-06-26 07:36:23.000000000 -0500
> +++ b/drivers/mtd/maps/Makefile 2009-06-26 07:40:03.000000000 -0500
> @@ -50,7 +50,6 @@ obj-$(CONFIG_MTD_UCLINUX) += uclinux.o
> obj-$(CONFIG_MTD_NETtel) += nettel.o
> obj-$(CONFIG_MTD_SCB2_FLASH) += scb2_flash.o
> obj-$(CONFIG_MTD_H720X) += h720x-flash.o
> -obj-$(CONFIG_MTD_SBC8240) += sbc8240.o
> obj-$(CONFIG_MTD_IXP4XX) += ixp4xx.o
> obj-$(CONFIG_MTD_IXP2000) += ixp2000.o
> obj-$(CONFIG_MTD_WRSBC8260) += wr_sbc82xx_flash.o
> diff -uprN a/drivers/mtd/maps/sbc8240.c b/drivers/mtd/maps/sbc8240.c
> --- a/drivers/mtd/maps/sbc8240.c 2009-06-26 07:36:23.000000000 -0500
> +++ b/drivers/mtd/maps/sbc8240.c 1969-12-31 18:00:00.000000000 -0600
> @@ -1,250 +0,0 @@
> -/*
> - * Handle mapping of the flash memory access routines on the SBC8240 board.
> - *
> - * Carolyn Smith, Tektronix, Inc.
> - *
> - * This code is GPLed
> - */
> -
> -/*
> - * The SBC8240 has 2 flash banks.
> - * Bank 0 is a 512 KiB AMD AM29F040B; 8 x 64 KiB sectors.
> - * It contains the U-Boot code (7 sectors) and the environment (1 sector).
> - * Bank 1 is 4 x 1 MiB AMD AM29LV800BT; 15 x 64 KiB sectors, 1 x 32 KiB sector,
> - * 2 x 8 KiB sectors, 1 x 16 KiB sectors.
> - * Both parts are JEDEC compatible.
> - */
> -
> -#include <linux/module.h>
> -#include <linux/types.h>
> -#include <linux/kernel.h>
> -#include <asm/io.h>
> -
> -#include <linux/mtd/mtd.h>
> -#include <linux/mtd/map.h>
> -#include <linux/mtd/cfi.h>
> -
> -#ifdef CONFIG_MTD_PARTITIONS
> -#include <linux/mtd/partitions.h>
> -#endif
> -
> -#define DEBUG
> -
> -#ifdef DEBUG
> -# define debugk(fmt,args...) printk(fmt ,##args)
> -#else
> -# define debugk(fmt,args...)
> -#endif
> -
> -
> -#define WINDOW_ADDR0 0xFFF00000 /* 512 KiB */
> -#define WINDOW_SIZE0 0x00080000
> -#define BUSWIDTH0 1
> -
> -#define WINDOW_ADDR1 0xFF000000 /* 4 MiB */
> -#define WINDOW_SIZE1 0x00400000
> -#define BUSWIDTH1 8
> -
> -#define MSG_PREFIX "sbc8240:" /* prefix for our printk()'s */
> -#define MTDID "sbc8240-%d" /* for mtdparts= partitioning */
> -
> -
> -static struct map_info sbc8240_map[2] = {
> - {
> - .name = "sbc8240 Flash Bank #0",
> - .size = WINDOW_SIZE0,
> - .bankwidth = BUSWIDTH0,
> - },
> - {
> - .name = "sbc8240 Flash Bank #1",
> - .size = WINDOW_SIZE1,
> - .bankwidth = BUSWIDTH1,
> - }
> -};
> -
> -#define NUM_FLASH_BANKS ARRAY_SIZE(sbc8240_map)
> -
> -/*
> - * The following defines the partition layout of SBC8240 boards.
> - *
> - * See include/linux/mtd/partitions.h for definition of the
> - * mtd_partition structure.
> - *
> - * The *_max_flash_size is the maximum possible mapped flash size
> - * which is not necessarily the actual flash size. It must correspond
> - * to the value specified in the mapping definition defined by the
> - * "struct map_desc *_io_desc" for the corresponding machine.
> - */
> -
> -#ifdef CONFIG_MTD_PARTITIONS
> -
> -static struct mtd_partition sbc8240_uboot_partitions [] = {
> - /* Bank 0 */
> - {
> - .name = "U-boot", /* U-Boot Firmware */
> - .offset = 0,
> - .size = 0x00070000, /* 7 x 64 KiB sectors */
> - .mask_flags = MTD_WRITEABLE, /* force read-only */
> - },
> - {
> - .name = "environment", /* U-Boot environment */
> - .offset = 0x00070000,
> - .size = 0x00010000, /* 1 x 64 KiB sector */
> - },
> -};
> -
> -static struct mtd_partition sbc8240_fs_partitions [] = {
> - {
> - .name = "jffs", /* JFFS filesystem */
> - .offset = 0,
> - .size = 0x003C0000, /* 4 * 15 * 64KiB */
> - },
> - {
> - .name = "tmp32",
> - .offset = 0x003C0000,
> - .size = 0x00020000, /* 4 * 32KiB */
> - },
> - {
> - .name = "tmp8a",
> - .offset = 0x003E0000,
> - .size = 0x00008000, /* 4 * 8KiB */
> - },
> - {
> - .name = "tmp8b",
> - .offset = 0x003E8000,
> - .size = 0x00008000, /* 4 * 8KiB */
> - },
> - {
> - .name = "tmp16",
> - .offset = 0x003F0000,
> - .size = 0x00010000, /* 4 * 16KiB */
> - }
> -};
> -
> -/* trivial struct to describe partition information */
> -struct mtd_part_def
> -{
> - int nums;
> - unsigned char *type;
> - struct mtd_partition* mtd_part;
> -};
> -
> -static struct mtd_info *sbc8240_mtd[NUM_FLASH_BANKS];
> -static struct mtd_part_def sbc8240_part_banks[NUM_FLASH_BANKS];
> -
> -
> -#endif /* CONFIG_MTD_PARTITIONS */
> -
> -
> -static int __init init_sbc8240_mtd (void)
> -{
> - static struct _cjs {
> - u_long addr;
> - u_long size;
> - } pt[NUM_FLASH_BANKS] = {
> - {
> - .addr = WINDOW_ADDR0,
> - .size = WINDOW_SIZE0
> - },
> - {
> - .addr = WINDOW_ADDR1,
> - .size = WINDOW_SIZE1
> - },
> - };
> -
> - int devicesfound = 0;
> - int i,j;
> -
> - for (i = 0; i < NUM_FLASH_BANKS; i++) {
> - printk (KERN_NOTICE MSG_PREFIX
> - "Probing 0x%08lx at 0x%08lx\n", pt[i].size, pt[i].addr);
> -
> - sbc8240_map[i].map_priv_1 =
> - (unsigned long) ioremap (pt[i].addr, pt[i].size);
> - if (!sbc8240_map[i].map_priv_1) {
> - printk (MSG_PREFIX "failed to ioremap\n");
> - for (j = 0; j < i; j++) {
> - iounmap((void *) sbc8240_map[j].map_priv_1);
> - sbc8240_map[j].map_priv_1 = 0;
> - }
> - return -EIO;
> - }
> - simple_map_init(&sbc8240_mtd[i]);
> -
> - sbc8240_mtd[i] = do_map_probe("jedec_probe", &sbc8240_map[i]);
> -
> - if (sbc8240_mtd[i]) {
> - sbc8240_mtd[i]->module = THIS_MODULE;
> - devicesfound++;
> - } else {
> - if (sbc8240_map[i].map_priv_1) {
> - iounmap((void *) sbc8240_map[i].map_priv_1);
> - sbc8240_map[i].map_priv_1 = 0;
> - }
> - }
> - }
> -
> - if (!devicesfound) {
> - printk(KERN_NOTICE MSG_PREFIX
> - "No suppported flash chips found!\n");
> - return -ENXIO;
> - }
> -
> -#ifdef CONFIG_MTD_PARTITIONS
> - sbc8240_part_banks[0].mtd_part = sbc8240_uboot_partitions;
> - sbc8240_part_banks[0].type = "static image";
> - sbc8240_part_banks[0].nums = ARRAY_SIZE(sbc8240_uboot_partitions);
> - sbc8240_part_banks[1].mtd_part = sbc8240_fs_partitions;
> - sbc8240_part_banks[1].type = "static file system";
> - sbc8240_part_banks[1].nums = ARRAY_SIZE(sbc8240_fs_partitions);
> -
> - for (i = 0; i < NUM_FLASH_BANKS; i++) {
> -
> - if (!sbc8240_mtd[i]) continue;
> - if (sbc8240_part_banks[i].nums == 0) {
> - printk (KERN_NOTICE MSG_PREFIX
> - "No partition info available, registering whole device\n");
> - add_mtd_device(sbc8240_mtd[i]);
> - } else {
> - printk (KERN_NOTICE MSG_PREFIX
> - "Using %s partition definition\n", sbc8240_part_banks[i].mtd_part->name);
> - add_mtd_partitions (sbc8240_mtd[i],
> - sbc8240_part_banks[i].mtd_part,
> - sbc8240_part_banks[i].nums);
> - }
> - }
> -#else
> - printk(KERN_NOTICE MSG_PREFIX
> - "Registering %d flash banks at once\n", devicesfound);
> -
> - for (i = 0; i < devicesfound; i++) {
> - add_mtd_device(sbc8240_mtd[i]);
> - }
> -#endif /* CONFIG_MTD_PARTITIONS */
> -
> - return devicesfound == 0 ? -ENXIO : 0;
> -}
> -
> -static void __exit cleanup_sbc8240_mtd (void)
> -{
> - int i;
> -
> - for (i = 0; i < NUM_FLASH_BANKS; i++) {
> - if (sbc8240_mtd[i]) {
> - del_mtd_device (sbc8240_mtd[i]);
> - map_destroy (sbc8240_mtd[i]);
> - }
> - if (sbc8240_map[i].map_priv_1) {
> - iounmap ((void *) sbc8240_map[i].map_priv_1);
> - sbc8240_map[i].map_priv_1 = 0;
> - }
> - }
> -}
> -
> -module_init (init_sbc8240_mtd);
> -module_exit (cleanup_sbc8240_mtd);
> -
> -MODULE_LICENSE ("GPL");
> -MODULE_AUTHOR ("Carolyn Smith <carolyn.smith@tektronix.com>");
> -MODULE_DESCRIPTION ("MTD map driver for SBC8240 boards");
> -
>
> ---
> Regards--
> Subrata
>
^ permalink raw reply
* Re: [PATCH] alsa/soc: add locking to mpc5200-psc-ac97 driver
From: Wolfram Sang @ 2009-06-30 6:18 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, alsa-devel, broonie
In-Reply-To: <20090629234214.12670.9082.stgit@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 4049 bytes --]
Hi Grant,
On Mon, Jun 29, 2009 at 05:42:21PM -0600, Grant Likely wrote:
> From: Grant Likely <grant.likely@secretlab.ca>
>
> AC97 bus register read/write hooks need to provide locking, but the
> mpc5200-psc-ac97 driver does not. This patch adds a mutex around
> the register access routines.
>
> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
> ---
>
> sound/soc/fsl/mpc5200_dma.c | 1 +
> sound/soc/fsl/mpc5200_dma.h | 1 +
> sound/soc/fsl/mpc5200_psc_ac97.c | 17 ++++++++++++++++-
> 3 files changed, 18 insertions(+), 1 deletions(-)
>
>
> diff --git a/sound/soc/fsl/mpc5200_dma.c b/sound/soc/fsl/mpc5200_dma.c
> index efec33a..f0a2d40 100644
> --- a/sound/soc/fsl/mpc5200_dma.c
> +++ b/sound/soc/fsl/mpc5200_dma.c
> @@ -456,6 +456,7 @@ int mpc5200_audio_dma_create(struct of_device *op)
> return -ENODEV;
>
> spin_lock_init(&psc_dma->lock);
> + mutex_init(&psc_dma->mutex);
> psc_dma->id = be32_to_cpu(*prop);
> psc_dma->irq = irq;
> psc_dma->psc_regs = regs;
> diff --git a/sound/soc/fsl/mpc5200_dma.h b/sound/soc/fsl/mpc5200_dma.h
> index 2000803..8d396bb 100644
> --- a/sound/soc/fsl/mpc5200_dma.h
> +++ b/sound/soc/fsl/mpc5200_dma.h
> @@ -55,6 +55,7 @@ struct psc_dma {
> unsigned int irq;
> struct device *dev;
> spinlock_t lock;
> + struct mutex mutex;
> u32 sicr;
> uint sysclk;
> int imr;
> diff --git a/sound/soc/fsl/mpc5200_psc_ac97.c b/sound/soc/fsl/mpc5200_psc_ac97.c
> index 794a247..7eb5499 100644
> --- a/sound/soc/fsl/mpc5200_psc_ac97.c
> +++ b/sound/soc/fsl/mpc5200_psc_ac97.c
> @@ -34,13 +34,20 @@ static unsigned short psc_ac97_read(struct snd_ac97 *ac97, unsigned short reg)
> int status;
> unsigned int val;
>
> + mutex_lock(&psc_dma->mutex);
> +
> /* Wait for command send status zero = ready */
> status = spin_event_timeout(!(in_be16(&psc_dma->psc_regs->sr_csr.status) &
> MPC52xx_PSC_SR_CMDSEND), 100, 0);
> if (status == 0) {
> pr_err("timeout on ac97 bus (rdy)\n");
> + mutex_unlock(&psc_dma->mutex);
> return -ENODEV;
> }
> +
> + /* Force clear the data valid bit */
> + in_be32(&psc_dma->psc_regs->ac97_data);
> +
No mutex involved here. I think this is either a seperate patch or it needs at
least to be mentioned in the patch description.
> /* Send the read */
> out_be32(&psc_dma->psc_regs->ac97_cmd, (1<<31) | ((reg & 0x7f) << 24));
>
> @@ -50,16 +57,19 @@ static unsigned short psc_ac97_read(struct snd_ac97 *ac97, unsigned short reg)
> if (status == 0) {
> pr_err("timeout on ac97 read (val) %x\n",
> in_be16(&psc_dma->psc_regs->sr_csr.status));
> + mutex_unlock(&psc_dma->mutex);
> return -ENODEV;
> }
> /* Get the data */
> val = in_be32(&psc_dma->psc_regs->ac97_data);
> if (((val >> 24) & 0x7f) != reg) {
> pr_err("reg echo error on ac97 read\n");
> + mutex_unlock(&psc_dma->mutex);
> return -ENODEV;
> }
> val = (val >> 8) & 0xffff;
>
> + mutex_unlock(&psc_dma->mutex);
> return (unsigned short) val;
> }
>
> @@ -68,16 +78,21 @@ static void psc_ac97_write(struct snd_ac97 *ac97,
> {
> int status;
>
> + mutex_lock(&psc_dma->mutex);
> +
> /* Wait for command status zero = ready */
> status = spin_event_timeout(!(in_be16(&psc_dma->psc_regs->sr_csr.status) &
> MPC52xx_PSC_SR_CMDSEND), 100, 0);
> if (status == 0) {
> pr_err("timeout on ac97 bus (write)\n");
> - return;
> + goto out;
> }
> /* Write data */
> out_be32(&psc_dma->psc_regs->ac97_cmd,
> ((reg & 0x7f) << 24) | (val << 8));
> +
> + out:
> + mutex_unlock(&psc_dma->mutex);
> }
>
> static void psc_ac97_warm_reset(struct snd_ac97 *ac97)
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Inline Assembly queries
From: kernel mailz @ 2009-06-30 5:53 UTC (permalink / raw)
To: Ian Lance Taylor; +Cc: gcc-help, linuxppc-dev
In-Reply-To: <m3ljna20fx.fsf@google.com>
Consider atomic_add and atomic_add_return in kernel code.
On Tue, Jun 30, 2009 at 2:59 AM, Ian Lance Taylor<iant@google.com> wrote:
> kernel mailz <kernelmailz@googlemail.com> writes:
>
>> I tried a small example
>>
>> int *p = 0x1000;
>> int a = *p;
>> asm("sync":::"memory");
>> a = *p;
>>
>> and
>>
>> volatile int *p = 0x1000;
>> int a = *p;
>> asm("sync");
>> a = *p
>>
>> Got the same assembly.
>> Which is right.
>>
>> So does it mean, if proper use of volatile is done, there is no need
>> of "memory" ?
>
> You have to consider the effects of inlining, which may bring in other
> memory loads and stores through non-volatile pointers.
>
> Ian
>
Consider
static __inline__ void atomic_add(int a, atomic_t *v)
{
int t;
__asm__ __volatile__(
"1: lwarx %0,0,%3 # atomic_add\n\
add %0,%2,%0\n"
PPC405_ERR77(0,%3)
" stwcx. %0,0,%3 \n\
bne- 1b"
: "=&r" (t), "+m" (v->counter)
: "r" (a), "r" (&v->counter)
: "cc");
}
static __inline__ int atomic_add_return(int a, atomic_t *v)
{
int t;
__asm__ __volatile__(
LWSYNC_ON_SMP
"1: lwarx %0,0,%2 # atomic_add_return\n\
add %0,%1,%0\n"
PPC405_ERR77(0,%2)
" stwcx. %0,0,%2 \n\
bne- 1b"
ISYNC_ON_SMP
: "=&r" (t)
: "r" (a), "r" (&v->counter)
: "cc", "memory");
return t;
}
I am not able to figure out why "memory" is added in latter
-TZ
^ permalink raw reply
* Re: PCI device support in Open Firmware (device tree syntax)
From: Johnny Hung @ 2009-06-30 1:36 UTC (permalink / raw)
To: Scott Wood; +Cc: kernelnewbies, linuxppc-dev, linux-embedded
In-Reply-To: <20090629165133.GC1323@b07421-ec1.am.freescale.net>
Thanks for your reply. So there are no PCI device resource info in
flat device tree.
How do PCI device resources be assign in general case or is there any examp=
le?
I am so confusing, would you please give me detailed describle?
BRs, H. Johnny
>
> With flat device trees, PCI devices are not typically included as they
> can be probed instead. =A0Interrupt mapping is conveyed by the
> interrupt-map property in the PCI controller node.
>
> -Scott
>
^ permalink raw reply
* Re: [PATCH] alsa/soc: add locking to mpc5200-psc-ac97 driver
From: Jon Smirl @ 2009-06-30 0:26 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, alsa-devel, broonie
In-Reply-To: <20090629234214.12670.9082.stgit@localhost.localdomain>
On Mon, Jun 29, 2009 at 7:42 PM, Grant Likely<grant.likely@secretlab.ca> wr=
ote:
> From: Grant Likely <grant.likely@secretlab.ca>
>
> AC97 bus register read/write hooks need to provide locking, but the
> mpc5200-psc-ac97 driver does not. =A0This patch adds a mutex around
> the register access routines.
Does your touchscreen driver use this mutex? Or was this mutex needed
just for the AC97 driver?
--=20
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Can't boot 2.6.30 powerpc kernel under qemu.
From: Michael Ellerman @ 2009-06-30 0:24 UTC (permalink / raw)
To: Rob Landley; +Cc: Stephen Rothwell, linuxppc-dev, Jeremy Kerr, linux-kernel
In-Reply-To: <200906291834.07902.rob@landley.net>
[-- Attachment #1: Type: text/plain, Size: 1366 bytes --]
On Mon, 2009-06-29 at 18:34 -0500, Rob Landley wrote:
> Which suggested that the problem was the new CONFIG_PPC_OF_BOOT_TRAMPOLINE
> symbol wasn't set, and once I switched that on it started working again.
What defconfig are you using? It sounds like maybe something should be
'select'ing OF_BOOT_TRAMPOLINE.
> > linuxppc-dev@lists.ozlabs.org is the one you want for this:
> >
> > https://lists.ozlabs.org/listinfo/linuxppc-dev
>
> Cool! Is there a reason it's hidden? (Or at least not listed in either
> vger.kernel.org's list info page or in the "Maling lists" page linked from
> ozlabs.org's top level web page.) Just curious, I couldn't find it when I
> looked in the obvious (to me) places.
It's not hidden, it's just in the process of moving from ozlabs.org to
lists.ozlabs.org - and it's a bit hard to find in the process. I've
updated the ozlabs.org page to point to it in the meantime.
It's also in maintainers :D
LINUX FOR POWERPC (32-BIT AND 64-BIT)
P: Benjamin Herrenschmidt
M: benh@kernel.crashing.org
P: Paul Mackerras
M: paulus@samba.org
W: http://www.penguinppc.org/
L: linuxppc-dev@ozlabs.org
T: git git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git
S: Supported
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Can't boot 2.6.30 powerpc kernel under qemu.
From: Tony Breeds @ 2009-06-30 0:23 UTC (permalink / raw)
To: Rob Landley; +Cc: linuxppc-dev, Jeremy Kerr, linux-kernel
In-Reply-To: <200906291834.07902.rob@landley.net>
On Mon, Jun 29, 2009 at 06:34:06PM -0500, Rob Landley wrote:
> Cool! Is there a reason it's hidden? (Or at least not listed in either
> vger.kernel.org's list info page
Because it's not hosted on vger :( ... I guess we're controll freaks! :D
> or in the "Maling lists" page linked from
> ozlabs.org's top level web page.)
Ahh this is becuase we're currently on the process of moving the lists to
"lists.ozlabs.org", there is an alias in place so the old address still works.
So at some level it's just bad timing :(
We'll do what we can to make this easier during the transition.
> Just curious, I couldn't find it when I
> looked in the obvious (to me) places.
Not to be flipant but it's in the MAINTAINERS file:
---
LINUX FOR POWERPC (32-BIT AND 64-BIT)
P: Benjamin Herrenschmidt
M: benh@kernel.crashing.org
P: Paul Mackerras
M: paulus@samba.org
W: http://www.penguinppc.org/
L: linuxppc-dev@ozlabs.org
T: git git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git
S: Supported
---
> P.S. Yes I tried google: top hit for "linux powerpc list" is penguinppc.org,
> which links to mailing lists on the right which is the ozlabs.org page that
> doesn't list linuxppc-dev. In fact the entire first page of google hits for
> that search doesn't give a hint of the existence of that list, although some
> of the later ones might if I clicked through more of them...
Rats, not really sure what we can do about that :(
Yours Tony
^ permalink raw reply
* [PATCH] alsa/soc: add locking to mpc5200-psc-ac97 driver
From: Grant Likely @ 2009-06-29 23:42 UTC (permalink / raw)
To: jonsmirl, linuxppc-dev, alsa-devel, broonie
From: Grant Likely <grant.likely@secretlab.ca>
AC97 bus register read/write hooks need to provide locking, but the
mpc5200-psc-ac97 driver does not. This patch adds a mutex around
the register access routines.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
sound/soc/fsl/mpc5200_dma.c | 1 +
sound/soc/fsl/mpc5200_dma.h | 1 +
sound/soc/fsl/mpc5200_psc_ac97.c | 17 ++++++++++++++++-
3 files changed, 18 insertions(+), 1 deletions(-)
diff --git a/sound/soc/fsl/mpc5200_dma.c b/sound/soc/fsl/mpc5200_dma.c
index efec33a..f0a2d40 100644
--- a/sound/soc/fsl/mpc5200_dma.c
+++ b/sound/soc/fsl/mpc5200_dma.c
@@ -456,6 +456,7 @@ int mpc5200_audio_dma_create(struct of_device *op)
return -ENODEV;
spin_lock_init(&psc_dma->lock);
+ mutex_init(&psc_dma->mutex);
psc_dma->id = be32_to_cpu(*prop);
psc_dma->irq = irq;
psc_dma->psc_regs = regs;
diff --git a/sound/soc/fsl/mpc5200_dma.h b/sound/soc/fsl/mpc5200_dma.h
index 2000803..8d396bb 100644
--- a/sound/soc/fsl/mpc5200_dma.h
+++ b/sound/soc/fsl/mpc5200_dma.h
@@ -55,6 +55,7 @@ struct psc_dma {
unsigned int irq;
struct device *dev;
spinlock_t lock;
+ struct mutex mutex;
u32 sicr;
uint sysclk;
int imr;
diff --git a/sound/soc/fsl/mpc5200_psc_ac97.c b/sound/soc/fsl/mpc5200_psc_ac97.c
index 794a247..7eb5499 100644
--- a/sound/soc/fsl/mpc5200_psc_ac97.c
+++ b/sound/soc/fsl/mpc5200_psc_ac97.c
@@ -34,13 +34,20 @@ static unsigned short psc_ac97_read(struct snd_ac97 *ac97, unsigned short reg)
int status;
unsigned int val;
+ mutex_lock(&psc_dma->mutex);
+
/* Wait for command send status zero = ready */
status = spin_event_timeout(!(in_be16(&psc_dma->psc_regs->sr_csr.status) &
MPC52xx_PSC_SR_CMDSEND), 100, 0);
if (status == 0) {
pr_err("timeout on ac97 bus (rdy)\n");
+ mutex_unlock(&psc_dma->mutex);
return -ENODEV;
}
+
+ /* Force clear the data valid bit */
+ in_be32(&psc_dma->psc_regs->ac97_data);
+
/* Send the read */
out_be32(&psc_dma->psc_regs->ac97_cmd, (1<<31) | ((reg & 0x7f) << 24));
@@ -50,16 +57,19 @@ static unsigned short psc_ac97_read(struct snd_ac97 *ac97, unsigned short reg)
if (status == 0) {
pr_err("timeout on ac97 read (val) %x\n",
in_be16(&psc_dma->psc_regs->sr_csr.status));
+ mutex_unlock(&psc_dma->mutex);
return -ENODEV;
}
/* Get the data */
val = in_be32(&psc_dma->psc_regs->ac97_data);
if (((val >> 24) & 0x7f) != reg) {
pr_err("reg echo error on ac97 read\n");
+ mutex_unlock(&psc_dma->mutex);
return -ENODEV;
}
val = (val >> 8) & 0xffff;
+ mutex_unlock(&psc_dma->mutex);
return (unsigned short) val;
}
@@ -68,16 +78,21 @@ static void psc_ac97_write(struct snd_ac97 *ac97,
{
int status;
+ mutex_lock(&psc_dma->mutex);
+
/* Wait for command status zero = ready */
status = spin_event_timeout(!(in_be16(&psc_dma->psc_regs->sr_csr.status) &
MPC52xx_PSC_SR_CMDSEND), 100, 0);
if (status == 0) {
pr_err("timeout on ac97 bus (write)\n");
- return;
+ goto out;
}
/* Write data */
out_be32(&psc_dma->psc_regs->ac97_cmd,
((reg & 0x7f) << 24) | (val << 8));
+
+ out:
+ mutex_unlock(&psc_dma->mutex);
}
static void psc_ac97_warm_reset(struct snd_ac97 *ac97)
^ permalink raw reply related
* Re: Can't boot 2.6.30 powerpc kernel under qemu.
From: Rob Landley @ 2009-06-29 23:34 UTC (permalink / raw)
To: Jeremy Kerr, linuxppc-dev; +Cc: linux-kernel
In-Reply-To: <200906281033.09842.jk@ozlabs.org>
On Saturday 27 June 2009 21:33:09 Jeremy Kerr wrote:
> Hi Rob,
>
> > I bisected the problem in the linux kernel repository, and wound up
> > here:
> >
> > 60ee031940c1b09c137b617a8829e2f081961fe0 is first bad commit
> > commit 60ee031940c1b09c137b617a8829e2f081961fe0
> > Author: Jeremy Kerr <jk@ozlabs.org>
> > Date: Tue Feb 17 11:44:14 2009 +1100
> >
> > powerpc/spufs: Use correct return value for spu_handle_mm_fault
>
> I think it's very unlikely that this commit would be causing the
> problem, as qemu doesn't have any SPEs (they're specific to the Cell
> architecture), which would be required to hit this code. Also, you're
> not compiling with CONFIG_SPU_BASE, so the file that this changed
> shouldn't even be built.
Yeah, it seemed odd. That's why I needed help. :)
> Perhaps try the bisect again?
Sorry about that. I suck at git.
Part of the reason is that git bisect assumes that "good" always comes before
"bad" in the repository, so if you're looking for the patch that _fixed_ a bug
(I.E. good == new and bad == old), you have to reverse 'em to humor git
bisect. I had to do that this time to patch an intermediate version that
build breaks, which "git bisect run" called "skip" on over a dozen times
without noticeable progress. If good and bad then mean the opposite on the
_next_ bisect, I tend to get 'em confused occasionally. (Especially when I've
hit three or more unrelated bugs in the same bisect run. In this case the
build break in kmap_atomic_prot, whatever memory glitch is corrupting the
squashfs root filesystem image and spamming the console about it, and this bug.
Oh, and the really _fun_ part is that the squashfs bug only reproduces about
half the time. If you run the same binary twice, sometimes it'll work and
sometimes it'll spam squashfs errors to the console. Wheee...)
Anyway, on something like my fifth attempt I managed to bisect it to:
28794d34ecb6815a3fa0a4256027c9b081a17c5f is first bad commit
commit 28794d34ecb6815a3fa0a4256027c9b081a17c5f
Author: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: Tue Mar 10 17:53:27 2009 +0000
powerpc/kconfig: Kill PPC_MULTIPLATFORM
CONFIG_PPC_MULTIPLATFORM is a remain of the pre-powerpc days and isn't
really meaningful anymore. It was basically equivalent to PPC64 || 6xx.
This removes it along with the following changes:
- 32-bit platforms that relied on PPC32 && PPC_MULTIPLATFORM now rely
on 6xx which is what they want anyway.
- A new symbol, PPC_BOOK3S, is defined that represent compliance with
the "Server" variant of the architecture. This is set when either 6xx
or PPC64 is set and open the door for future BOOK3E 64-bit.
- 64-bit platforms that relied on PPC64 && PPC_MULTIPLATFORM now use
PPC64 && PPC_BOOK3S
- A separate and selectable CONFIG_PPC_OF_BOOT_TRAMPOLINE option is now
used to control the use of prom_init.c
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Which suggested that the problem was the new CONFIG_PPC_OF_BOOT_TRAMPOLINE
symbol wasn't set, and once I switched that on it started working again.
> linuxppc-dev@lists.ozlabs.org is the one you want for this:
>
> https://lists.ozlabs.org/listinfo/linuxppc-dev
Cool! Is there a reason it's hidden? (Or at least not listed in either
vger.kernel.org's list info page or in the "Maling lists" page linked from
ozlabs.org's top level web page.) Just curious, I couldn't find it when I
looked in the obvious (to me) places.
Rob
P.S. Yes I tried google: top hit for "linux powerpc list" is penguinppc.org,
which links to mailing lists on the right which is the ozlabs.org page that
doesn't list linuxppc-dev. In fact the entire first page of google hits for
that search doesn't give a hint of the existence of that list, although some
of the later ones might if I clicked through more of them...
--
Latency is more important than throughput. It's that simple. - Linus Torvalds
^ permalink raw reply
* [PATCH] powerpc: Fix spin_event_timeout() to be robust over context switches
From: Grant Likely @ 2009-06-29 23:40 UTC (permalink / raw)
To: linuxppc-dev, linux-kernel, timur, jonsmirl
From: Grant Likely <grant.likely@secretlab.ca>
Current implementation of spin_event_timeout can be interrupted by an
IRQ or context switch after testing the condition, but before checking
the timeout. This can cause the loop to report a timeout when the
condition actually became true in the middle.
This patch adds one final check of the condition upon exit of the loop
if the last test of the condition was still false.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
arch/powerpc/include/asm/delay.h | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/include/asm/delay.h b/arch/powerpc/include/asm/delay.h
index 1e2eb41..52e4d54 100644
--- a/arch/powerpc/include/asm/delay.h
+++ b/arch/powerpc/include/asm/delay.h
@@ -63,6 +63,8 @@ extern void udelay(unsigned long usecs);
udelay(delay); \
else \
cpu_relax(); \
+ if (!__ret) \
+ __ret = (condition); \
__ret; \
})
^ permalink raw reply related
* Re: Inline Assembly queries
From: Ian Lance Taylor @ 2009-06-29 21:29 UTC (permalink / raw)
To: kernel mailz; +Cc: gcc-help, linuxppc-dev
In-Reply-To: <abe8a1fd0906290849w1ba6bd33of60a9c2e110c10fd@mail.gmail.com>
kernel mailz <kernelmailz@googlemail.com> writes:
> I tried a small example
>
> int *p = 0x1000;
> int a = *p;
> asm("sync":::"memory");
> a = *p;
>
> and
>
> volatile int *p = 0x1000;
> int a = *p;
> asm("sync");
> a = *p
>
> Got the same assembly.
> Which is right.
>
> So does it mean, if proper use of volatile is done, there is no need
> of "memory" ?
You have to consider the effects of inlining, which may bring in other
memory loads and stores through non-volatile pointers.
Ian
^ permalink raw reply
* Re: Inline Assembly queries
From: Ian Lance Taylor @ 2009-06-29 21:27 UTC (permalink / raw)
To: David Howells; +Cc: gcc-help, linuxppc-dev, kernel mailz
In-Reply-To: <30098.1246291036@redhat.com>
David Howells <dhowells@redhat.com> writes:
> kernel mailz <kernelmailz@googlemail.com> wrote:
>
>> asm("sync");
>
> Isn't gcc free to discard this as it has no dependencies, no indicated side
> effects, and isn't required to be kept? I think this should probably be:
>
> asm volatile("sync");
An asm with no outputs is considered to be volatile.
Ian
^ permalink raw reply
* Re: Trouble "Transferring control to Linux (at address 00000000)"
From: Scott Wood @ 2009-06-29 21:03 UTC (permalink / raw)
To: Mikhail Zaturenskiy; +Cc: Frank Svendsbøe, linuxppc-dev, Gary Thomas
In-Reply-To: <97dd5fd20906291346s3ee60edbr1863c27280ae373c@mail.gmail.com>
Mikhail Zaturenskiy wrote:
>
> Seems like at that point it begins to redirect output to ttyCPM0 but
> still nothing showing on the console...
Check the clock-frequency of the CPM BRG node. If u-boot isn't setting
the memory, it's probably not setting this either.
If you're not up to the task of fixing u-boot to fill in the device
tree, you may want to try cuImage.
-Scott
^ permalink raw reply
* Re: Trouble "Transferring control to Linux (at address 00000000)"
From: Mikhail Zaturenskiy @ 2009-06-29 20:46 UTC (permalink / raw)
To: Scott Wood; +Cc: Frank Svendsbøe, linuxppc-dev, Gary Thomas
In-Reply-To: <4A49249C.5080101@freescale.com>
> Change "root=" to "console=".
Thank you for clarifying.
I tried this but I get the following in my memory dump:
<6>Using Embedded Planet EP88xC ??achine description?
<5>Linux ver??ion 2.6.30-rc2-01402-gd4e2f68-d??rty
(devone@localhost.localdoma??n) (gcc version 4.2.2) #1 Mon J??n 29
11:35:28 CDT 2009?
<7>Top o?? RAM: 0x4000000' Total RAM: 0x4??00000?
<7>Memory hole size: 0MB???
>4>Zone PFN ranges:?
<4> DMA ?? 0x00000000 -> 0x00004000?
<4> ??ormal 0x00004000 -> 0x0000400???
<4>Movable zone start PFN for ??ach node?
<4>early_node_map[1] a??tive PFN ranges?
<4> 0: 0x000??0000 -> 0x00004000?
<7>On node 0??totalpages: 16384?
<7>free_area_??nit_node: node 0' pgdat c021bf7??' node_mem_map c023f000?
<7> DM?? zone: 128 pages used for memma???
<7> DMA zone: 0 pages reserve???
<7> DMA zone: 16256 pages' LI??O batch:3?
<6>MMU: Allocated 72 ??ytes of context maps for 16 con??exts?
<4>Built 1 zonelists in Zo??e order' mobility grouping on. ??Total pages: 16256?
<5>Kernel co??mand line: console=ttyCPM0'9600??8 loglevel=7?
<6>NR_IRQS:512?
<7>??rq: irq 5 on host /soc@f0000000??interrupt-controller@0 mapped
t?? virtual irq 16?
<7>irq: irq 0 o?? host /soc@f0000000/cpm@9c0/int??rrupt-controller@930
mapped to ??irtual irq 17?
<4>PID hash table??entries: 256 (order: 8' 1024 by??es)?
<4>Decrementer Frequency = ??x7bfa48?
<7>irq: irq 15 on host ??soc@f0000000/interrupt-controll??r@0 mapped
to virtual irq 18?
<7??time_init: decrementer frequenc?? = 8.125000 MHz?
<7>time_init: p??ocessor frequency = 130.00000?? MHz?
<6>clocksource: timebase m??lt[1ec4ec4f] shift[22] register??d?
<7>clockevent: decrementer mu??t[214] shift[16] cpu[0]?
<7>irq:??irq 4 on host /soc@f0000000/cpm??9c0/interrupt-controller@930
ma??ped to virtual irq 19?
<6>consol?? [ttyCPM0] enabled
Seems like at that point it begins to redirect output to ttyCPM0 but
still nothing showing on the console...
^ 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