* Audio Dirver for the 403/405?
From: bert_maxel @ 2007-05-30 21:44 UTC (permalink / raw)
To: linuxppc-embedded
Hi all,
Has anybody got some working audio driver (linux) for the ML403/405 ?
I know it's an ac97 codec, but I can't find anything related to the xilinx
boards?
If nobody has worked on this yet, I'm in trouble. I don't know where to
start, or from what ac97 driver should I base my initial development?
Any suggestion is much appreciated.
Thanks
--
View this message in context: http://www.nabble.com/Audio-Dirver-for-the-403-405--tf3843165.html#a10883262
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: Saving to 32 bits of GPRs in signal context
From: Steve Munroe @ 2007-05-30 21:41 UTC (permalink / raw)
To: Gabriel Paubert
Cc: Ulrich Weigand, linuxppc-dev list, Paul Mackerras,
Anton Blanchard
In-Reply-To: <20070530210212.GB4510@iram.es>
Gabriel Paubert <paubert@iram.es> wrote on 05/30/2007 04:02:12 PM:
>
> In 32 bit mode, 64 bit divides use a libcall for example. But the
> libgcc routine can and should use the 64 bit instructions. There are
> many other libcall cases that would benefit from a libgcc compiled
> to use 64 bit instructions (64 bit int to floating point conversions and
> back). This indirectly affects a lot of functions.
>
That is not an issue. The ISA 2.0 removed the useage restriction for fctid,
fctidz, and fcfid in 32-bit implementations.
^ permalink raw reply
* Re: Saving to 32 bits of GPRs in signal context
From: Steve Munroe @ 2007-05-30 21:33 UTC (permalink / raw)
To: Olof Johansson
Cc: linuxppc-dev list, Ulrich Weigand, Paul Mackerras,
Anton Blanchard
In-Reply-To: <20070530205239.GA9462@lixom.net>
olof@lixom.net (Olof Johansson) wrote on 05/30/2007 03:52:39 PM:
> On Wed, May 30, 2007 at 02:47:37PM -0500, Steve Munroe wrote:
> >
> > Kumar Gala <galak@kernel.crashing.org> wrote on 05/30/2007 12:31:32 AM:
> >
> > >
> > > On May 29, 2007, at 9:54 PM, Steve Munroe wrote:
> > >
> > > >
> > > > Kumar Gala <galak@kernel.crashing.org> wrote on 05/29/2007 07:43:05
> > > > PM:
> > > >
> > > >>
> > > >> On May 29, 2007, at 6:46 PM, Olof Johansson wrote:
> > > >>
> > > >>> On Wed, May 30, 2007 at 07:32:33AM +1000, Benjamin Herrenschmidt
> > > >>> wrote:
> > > >>>> On Tue, 2007-05-29 at 08:10 -0500, Kumar Gala wrote:
> > > >>>>> This is all problematic since some 64-bit implementations may
not
> > > >>>>> guarantee the upper bits are valid when in 32-bit mode. Look
> > > >>>>> at the
> > > >>>>> 'Computation Modes' section in the architecture specs 2.03 or
> > > >>>>> greater
> > > >>>>> for embedded processors.
> > > >>>>
> > > >>>> Yuck. Well, we might need to export a spearate CPU feature bit
to
> > > >>>> indicate that it's the case then.
> > > >>>
> > > >>> No need for a new bit, you should be able to key off of
> > > >>> PPC_FEATURE_64
> > > >>> && !PPC_FEATURE_BOOKE.
> > > >>
> > > >> Nope, the architecture allows embedded to behave like server parts
> > > >> and support the full 64-bit registers. We really should have a
new
> > > >> feature bit so that if someone has an implementation of an
embedded
> > > >> part that supports the functionality, they get the benefit.
> > > >>
> > > > When such exists we can add a bit, until then we can wait. The
current
> > > > 32-bit AT_HWCAP is almost full. so we should not allocate bits on
> > > > speculation.
> > >
> > > Understandable.. dare I ask about a few of the current AT_HWCAPs we
> > > do have:
> > >
> > > #define PPC_FEATURE_POWER4 0x00080000
> > > #define PPC_FEATURE_POWER5 0x00040000
> > > #define PPC_FEATURE_POWER5_PLUS 0x00020000
> > > #define PPC_FEATURE_ARCH_2_05 0x00001000
> > > #define PPC_FEATURE_PA6T 0x00000800
> > > #define PPC_FEATURE_POWER6_EXT 0x00000200
> > >
> > > What exactly are we using these for? Can we not use platform for
> > > some of these?
> > >
> > These are poorly named ISA versions
> >
> > PPC_FEATURE_POWER4 == PPC_FEATURE_ARCH_2_0
> > PPC_FEATURE_POWER5 == PPC_FEATURE_ARCH_2_02
> > PPC_FEATURE_POWER5+ == PPC_FEATURE_ARCH_2_03
> >
> > Ask Olof about this but I think
> > PPC_FEATURE_PA6T == PPC_FEATURE_ARCH_2_04
> > but I think it is more then 2_04 and less than 2_05.
>
> The problem is that IBM has never (before) had to care about what was
> implementation and what was architecture. The implementation WAS the
> architecture up until POWER5+, and the PPC ISA went lock-step with the
> new server processor releases.
>
> PA6T is 2.04 + a few 2.05 bits, give or take. But it's not equivalent of
> POWER6 (nor is it equivalent of POWER5+, since they implement different
> optional features of the architecture).
>
> I'm not sure just how to make this scale down the road -- if we are to
> use a PPC_FEATURE_* for every optional feature in the ISA, we'll run
> out of bits in no time. If we end up using a flag per implementation,
> it probably won't be quite as bad, but I'm guessing the actual code that
> uses it will get hairier.
>
The current thinking is that AT_PLATFORM is for implementations
(micro-architectures where a few instruction twiques are not enough.
Different micro-architectures require recompilation with different
instruction scheduling (-mtune=<cpu-type>). For example power5 and ppc-cell
are both ISA 2.02, but completely different micro-architectures (8
pipelines out of order vs 2 in order).
AT_HWCAP is for instruction features where a quick runtime test to use
specific instructions is meaningful.
Steven J. Munroe
Linux on Power Toolchain Architect
IBM Corporation, Linux Technology Center
^ permalink raw reply
* Re: Saving to 32 bits of GPRs in signal context
From: Gabriel Paubert @ 2007-05-30 21:02 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Ulrich Weigand, Steve Munroe, linuxppc-dev list, Paul Mackerras,
Anton Blanchard
In-Reply-To: <1180525484.19517.266.camel@localhost.localdomain>
On Wed, May 30, 2007 at 09:44:44PM +1000, Benjamin Herrenschmidt wrote:
> On Wed, 2007-05-30 at 00:32 -0500, Kumar Gala wrote:
> > > I think actually it would be useful to have the saving/restoring of
> > > the high 32 bits controlled by a prctl, so that programs have to ask
> > > explicitly for the new behaviour (and programs that don't want to
> > use
> > > the high 32 bits don't incur the extra overhead).
> >
> > I like this, it means we can error if HW doesn't support it and
> > requires applications to do something specific to enable the feature.
>
> Yeah well.... I liked the prctl at first.. but then, I though twice :-)
I agree, sooner or later, distribution might install two copies in two
different places and the dynamic loader will select one depending
availability of 64 bit registers. At this point virtually all applications
will effectively use 64 bit registers even when compiled in pure 32 bit
mode but the prctl will have to stay only for "hysterical raisins".
In 32 bit mode, 64 bit divides use a libcall for example. But the
libgcc routine can and should use the 64 bit instructions. There are
many other libcall cases that would benefit from a libgcc compiled
to use 64 bit instructions (64 bit int to floating point conversions and
back). This indirectly affects a lot of functions.
Gabriel (starting to having nightmares about somebody inventing
just another processor flavor, like a 64 bit BookE processor
with SPE and Altivec).
^ permalink raw reply
* Re: Saving to 32 bits of GPRs in signal context
From: Olof Johansson @ 2007-05-30 20:52 UTC (permalink / raw)
To: Steve Munroe
Cc: linuxppc-dev list, Paul Mackerras, Anton Blanchard,
Ulrich Weigand
In-Reply-To: <OF3CF62163.CD3DCA16-ON862572EB.006C0F2C-862572EB.006CBB1C@us.ibm.com>
On Wed, May 30, 2007 at 02:47:37PM -0500, Steve Munroe wrote:
>
> Kumar Gala <galak@kernel.crashing.org> wrote on 05/30/2007 12:31:32 AM:
>
> >
> > On May 29, 2007, at 9:54 PM, Steve Munroe wrote:
> >
> > >
> > > Kumar Gala <galak@kernel.crashing.org> wrote on 05/29/2007 07:43:05
> > > PM:
> > >
> > >>
> > >> On May 29, 2007, at 6:46 PM, Olof Johansson wrote:
> > >>
> > >>> On Wed, May 30, 2007 at 07:32:33AM +1000, Benjamin Herrenschmidt
> > >>> wrote:
> > >>>> On Tue, 2007-05-29 at 08:10 -0500, Kumar Gala wrote:
> > >>>>> This is all problematic since some 64-bit implementations may not
> > >>>>> guarantee the upper bits are valid when in 32-bit mode. Look
> > >>>>> at the
> > >>>>> 'Computation Modes' section in the architecture specs 2.03 or
> > >>>>> greater
> > >>>>> for embedded processors.
> > >>>>
> > >>>> Yuck. Well, we might need to export a spearate CPU feature bit to
> > >>>> indicate that it's the case then.
> > >>>
> > >>> No need for a new bit, you should be able to key off of
> > >>> PPC_FEATURE_64
> > >>> && !PPC_FEATURE_BOOKE.
> > >>
> > >> Nope, the architecture allows embedded to behave like server parts
> > >> and support the full 64-bit registers. We really should have a new
> > >> feature bit so that if someone has an implementation of an embedded
> > >> part that supports the functionality, they get the benefit.
> > >>
> > > When such exists we can add a bit, until then we can wait. The current
> > > 32-bit AT_HWCAP is almost full. so we should not allocate bits on
> > > speculation.
> >
> > Understandable.. dare I ask about a few of the current AT_HWCAPs we
> > do have:
> >
> > #define PPC_FEATURE_POWER4 0x00080000
> > #define PPC_FEATURE_POWER5 0x00040000
> > #define PPC_FEATURE_POWER5_PLUS 0x00020000
> > #define PPC_FEATURE_ARCH_2_05 0x00001000
> > #define PPC_FEATURE_PA6T 0x00000800
> > #define PPC_FEATURE_POWER6_EXT 0x00000200
> >
> > What exactly are we using these for? Can we not use platform for
> > some of these?
> >
> These are poorly named ISA versions
>
> PPC_FEATURE_POWER4 == PPC_FEATURE_ARCH_2_0
> PPC_FEATURE_POWER5 == PPC_FEATURE_ARCH_2_02
> PPC_FEATURE_POWER5+ == PPC_FEATURE_ARCH_2_03
>
> Ask Olof about this but I think
> PPC_FEATURE_PA6T == PPC_FEATURE_ARCH_2_04
> but I think it is more then 2_04 and less than 2_05.
The problem is that IBM has never (before) had to care about what was
implementation and what was architecture. The implementation WAS the
architecture up until POWER5+, and the PPC ISA went lock-step with the
new server processor releases.
PA6T is 2.04 + a few 2.05 bits, give or take. But it's not equivalent of
POWER6 (nor is it equivalent of POWER5+, since they implement different
optional features of the architecture).
I'm not sure just how to make this scale down the road -- if we are to
use a PPC_FEATURE_* for every optional feature in the ISA, we'll run
out of bits in no time. If we end up using a flag per implementation,
it probably won't be quite as bad, but I'm guessing the actual code that
uses it will get hairier.
-Olof
^ permalink raw reply
* Re: Saving to 32 bits of GPRs in signal context
From: Steve Munroe @ 2007-05-30 19:47 UTC (permalink / raw)
To: Kumar Gala
Cc: linuxppc-dev list, Ulrich Weigand, Paul Mackerras,
Anton Blanchard, Olof Johansson
In-Reply-To: <BE207C16-E909-43B1-AA2B-BBC9E026F300@kernel.crashing.org>
Kumar Gala <galak@kernel.crashing.org> wrote on 05/30/2007 12:31:32 AM:
>
> On May 29, 2007, at 9:54 PM, Steve Munroe wrote:
>
> >
> > Kumar Gala <galak@kernel.crashing.org> wrote on 05/29/2007 07:43:05
> > PM:
> >
> >>
> >> On May 29, 2007, at 6:46 PM, Olof Johansson wrote:
> >>
> >>> On Wed, May 30, 2007 at 07:32:33AM +1000, Benjamin Herrenschmidt
> >>> wrote:
> >>>> On Tue, 2007-05-29 at 08:10 -0500, Kumar Gala wrote:
> >>>>> This is all problematic since some 64-bit implementations may not
> >>>>> guarantee the upper bits are valid when in 32-bit mode. Look
> >>>>> at the
> >>>>> 'Computation Modes' section in the architecture specs 2.03 or
> >>>>> greater
> >>>>> for embedded processors.
> >>>>
> >>>> Yuck. Well, we might need to export a spearate CPU feature bit to
> >>>> indicate that it's the case then.
> >>>
> >>> No need for a new bit, you should be able to key off of
> >>> PPC_FEATURE_64
> >>> && !PPC_FEATURE_BOOKE.
> >>
> >> Nope, the architecture allows embedded to behave like server parts
> >> and support the full 64-bit registers. We really should have a new
> >> feature bit so that if someone has an implementation of an embedded
> >> part that supports the functionality, they get the benefit.
> >>
> > When such exists we can add a bit, until then we can wait. The current
> > 32-bit AT_HWCAP is almost full. so we should not allocate bits on
> > speculation.
>
> Understandable.. dare I ask about a few of the current AT_HWCAPs we
> do have:
>
> #define PPC_FEATURE_POWER4 0x00080000
> #define PPC_FEATURE_POWER5 0x00040000
> #define PPC_FEATURE_POWER5_PLUS 0x00020000
> #define PPC_FEATURE_ARCH_2_05 0x00001000
> #define PPC_FEATURE_PA6T 0x00000800
> #define PPC_FEATURE_POWER6_EXT 0x00000200
>
> What exactly are we using these for? Can we not use platform for
> some of these?
>
These are poorly named ISA versions
PPC_FEATURE_POWER4 == PPC_FEATURE_ARCH_2_0
PPC_FEATURE_POWER5 == PPC_FEATURE_ARCH_2_02
PPC_FEATURE_POWER5+ == PPC_FEATURE_ARCH_2_03
Ask Olof about this but I think
PPC_FEATURE_PA6T == PPC_FEATURE_ARCH_2_04
but I think it is more then 2_04 and less than 2_05.
This one PPC_FEATURE_POWER6_EXT is for the mftgpr/mffgpr instructions
unique to power6 native mode.
These support inline runtime tests to use instructions for newer versions
of the ISA
AT_PLATFORM is for slecting whole libraries. Not appropriate for inline
tests.
^ permalink raw reply
* Re: Saving to 32 bits of GPRs in signal context
From: Steve Munroe @ 2007-05-30 18:09 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Ulrich Weigand, linuxppc-dev list, Paul Mackerras,
Anton Blanchard
In-Reply-To: <1180529892.19517.282.camel@localhost.localdomain>
Steven J. Munroe
Linux on Power Toolchain Architect
IBM Corporation, Linux Technology Center
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote on 05/30/2007
07:58:12 AM:
> On Wed, 2007-05-30 at 21:48 +0900, Hiroyuki Machida wrote:
> >
> > I think same framework as proposed at follwoing URLs, works.
> > http://penguinppc.org/dev/glibc/glibc-powerpc-cpu-addon.html
This is about keeping the cpu-specific code separated out in the glibc
build system. The appropriat code can be selected by configuring
--with=cpu=<cpu-type>
> > http://sources.redhat.com/ml/libc-alpha/2006-01/msg00094.html
>
This is about selecting whole cpu-tuned libraries dynamically (at load
time) that separated in the directory structure.
> Yeah, it would make sense to define a new feature bit to trigger
> automatic loading of optimized libs...
>
For dynamic library selection the primary selection is based on
AT_PLATFORM. Specific bits from AT_WHCAP can qualify the search path. For
example /lib/power4 is searched on POWER4 systems based on AT_PLATFORM. The
directory /lib/ppc970/altivec is searched on 970s from AT_PLATFORM=ppc970
and AT_HWCAP=PPC_FEATURE_HAS_ALTIVEC.
Not all bits in the AT_HWCAP effect the search, controls be the
HWCAP_IMPORTANT mask. Current only optional ISA features are includes in
the mask at this time (PPC_FEATURE_HAS_ALTIVEC and PPC_FEATURE_HAS_DFP).
> Steve, how hard do you think it would be to extend AT_HWCAP ? Like
> adding an AT_HWCAP2 or something like that ?
>
If needed, I dont think we are there yet.
Steven J. Munroe
Linux on Power Toolchain Architect
IBM Corporation, Linux Technology Center
^ permalink raw reply
* Re: [patch 6/7] ps3: ROM Storage Driver
From: Geoff Levand @ 2007-05-30 17:18 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Geert Uytterhoeven, linuxppc-dev, Christoph Hellwig, linux-scsi,
linux-kernel
In-Reply-To: <1180525555.19517.268.camel@localhost.localdomain>
Benjamin Herrenschmidt wrote:
> On Wed, 2007-05-30 at 12:13 +0200, Christoph Hellwig wrote:
>>
>> For any sane hypervisor or hardware the copy should be worth
>> than that. Then again a sane hardware or hypervisor would support
>> SG requests..
>
> Agreed... Sony should fix that, it's a bit ridiculous.
Yes, if only to put an end to seeing this kind of comment over
and over again.
-Geoff
^ permalink raw reply
* Re: [PATCH 2.6.21-rt2] PowerPC: decrementer clockevent driver
From: Milton Miller @ 2007-05-30 15:56 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: ppcdev
In-Reply-To: <1179530872.32247.423.camel@localhost.localdomain>
> On Fri, 2007-05-18 at 17:41 +0400, Sergei Shtylyov wrote:
>> From the "PowerPC Operating Environment Architecture"
>> that I've already quoated it follows that POWER4-compatible
>> decremented exception *must* be edge triggered.
>>
>> says that an exception is generated when the MSB transitions
>> from 0 to 1. It's not clear wether the exception sticks while
>> that bit is 1 or is
>>
>> Freescale MPC 7450 manual says the same, for example.
>
> I find it extremely silly to implement it as edge anyway. The
> EE line is level triggered, and having a mix of edge and level
> on the same exception without a clean way to retrigger the DEC
> one other than waiting one tick is just causing trouble.
Making it edge triggered means that the operating system gets to
set the max value to 2^32-1 instead of 2^31-1, increasing the
range of the timeouts.
The architecture changed to level sensitive when support for
shared processor lpars was being added so that the hypervisor
didn't have to do dances to avoid pending decrementer
interrupts when changing partitions.
Besides, they aren't the same vector, just the same enable.
Oh, and loading the decrementer with 1 instead of 0 is the
workaround for an errata on at least one supported cpu.
milton
^ permalink raw reply
* [PATCH] fix zImage.coff generation for pmac
From: Milton Miller @ 2007-05-30 15:29 UTC (permalink / raw)
To: Paul Mackerras, Olaf Hering; +Cc: ppcdev
In-Reply-To: <20070525081459.GA30239@aepfle.de>
Commit 9da82a6dee9db4cd5ae7a74ab4f51afb52b6efb9 inadvertently
removed the platform override for zImage.coff to be generated
with pmaccoff. Rather than add a special makefile rule,
change the platform for which the wrapper platform uses
the special rules.
Signed-off-by: Milton Miller <miltonm@bga.com>
---
Untested, and hopefully not too whitespace damaged.
Against upstream after 2.6.22-rc3.
We could look for both coff and pmaccoff if someone
has an external script calling wrapper with platform
pmaccoff (change to coff|pmaccoff).
Olof Hering wrote:
> Does anyone happen to know where the arch/powerpc/boot/coff.o is
> supposed to come from? Current Linus tree fails since a while with the
> following commands.
>
> tar xfz /mounts/mirror/kernel/v2.6/testing/linux-2.6.22-rc2.tar.gz
> cd linux-2.6.22-rc2/
> mkdir ../O
> cp arch/powerpc/configs/pmac32_defconfig ../O/.config
> make -kj42 O=../O menuconfig
> make -kj42 O=../O
>
> WRAP arch/powerpc/boot/zImage.coff
> ld: arch/powerpc/boot/coff.o: No such file: No such file or directory
> nm: 'arch/powerpc/boot/zImage.coff': No such file
> objdump: 'arch/powerpc/boot/zImage.coff': No such file
diff --git a/arch/powerpc/boot/wrapper b/arch/powerpc/boot/wrapper
index 5cedd90..b28161c 100755
--- a/arch/powerpc/boot/wrapper
+++ b/arch/powerpc/boot/wrapper
@@ -129,7 +129,7 @@ case "$platform" in
pmac|pseries|chrp)
platformo=$object/of.o
;;
-pmaccoff)
+coff)
platformo=$object/of.o
lds=$object/zImage.coff.lds
;;
@@ -217,7 +217,7 @@ case "$platform" in
pseries|chrp)
$object/addnote "$ofile"
;;
-pmaccoff)
+coff)
entry=`objdump -f "$ofile" | grep '^start address ' | \
cut -d' ' -f3`
${CROSS}objcopy -O aixcoff-rs6000 --set-start "$entry" "$ofile"
^ permalink raw reply related
* Re: Fix problems with Holly's DT representation of ethernet PHYs
From: Segher Boessenkool @ 2007-05-30 15:28 UTC (permalink / raw)
To: Josh Boyer
Cc: Alexandre Bounine, David Gibson, Paul Mackerras,
linuxppc-dev list
In-Reply-To: <1180532899.3360.79.camel@zod.rchland.ibm.com>
>>> Not that there's anything wrong with your
>>> reasoning. Just seems like we're trying really hard to define
>>> something
>>> "correctly" when we control what's on both sides :).
>>
>> Right now, and in your case, you do. OTOH, the
>> goal is to have the DTS be a well-established
>> stable interface between the firmware/bootloader/
>> bootwrapper and the kernel; there is no room for
>> either side of that interface playing dirty tricks,
>> not on any board ;-)
>>
>> Also, the DTS files in the kernel source tree should
>> server as a best-of-breed example for people doing
>> custom device trees for their own boards. We better
>> whip them into good shape or we'll all look foolish...
>
> Yeah, I know. Ignore my earlier email. I blame it on lack of sleep.
>
> The only issue we might have in the future is if DT capable firmware
> for
> these boards shows up and does something completely different.
Yeah, that's exactly the same problem as we would have
if we would code our device trees without trying to at
least create an informal binding for the nodes in question:
total chaos.
> Hopefully that won't happen.
Hopefully, indeed.
If a third party constructs a board with some weird
device tree, then they probably have a big set of Linux
patches to go with that. Now either they work with the
kernel community to get that integrated into mainline
(which means they need to do a lot of changes to the DTS
as well if it indeed is weird / wrong, so they better
start doing that *before* selling the boards); or they
can happily maintain their own kernel fork, like so many
companies already do.
I don't see a problem here :-)
Segher
^ permalink raw reply
* Re: [PATCH v2]: Fix e500 v2 core reboot bug
From: Segher Boessenkool @ 2007-05-30 15:21 UTC (permalink / raw)
To: Kumar Gala; +Cc: Paul Mackerras, linuxppc-dev list
In-Reply-To: <976AFF56-7590-46B9-ADCA-4FA6673D4C9B@kernel.crashing.org>
>> I'm thinking have a guts block and putting a property in it makes the
>> most sense.
>
> After some discussion on IRC I think the following is the suggested
> node we should add in.
>
> guts@e00000 {
> compatible = "fsl,mpc8548-guts";
> reg = <e00000 1000>;
> fsl,has-rstcr;
> };
Except you shouldn't call it "guts".
Segher
^ permalink raw reply
* Re: Consolidate cuboot initialization code
From: Scott Wood @ 2007-05-30 15:21 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20070530151236.GA14432@localhost.localdomain>
David Gibson wrote:
> On Wed, May 30, 2007 at 10:09:11AM -0500, Scott Wood wrote:
>>Is there any particular reason to not just do a direct call to
>>cuboot_init, and move the memcpy and end-of-ram calculation there? I'd
>>rather avoid macros if possible.
>
> Uh.. yeah.. because cuboot_init() doesn't know the size to memcpy(),
> because it doesn't have the right bd_t definition.
Ah, yes. Don't mind me, it's still morning here... :-P
We could probably do away with the copy altogether, though, as u-boot
puts the bd_t near the stack, which is exempted from the bootwrapper's
heap with the 1MiB exclusion.
-Scott
^ permalink raw reply
* Re: Consolidate cuboot initialization code
From: David Gibson @ 2007-05-30 15:12 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <465D9397.7000008@freescale.com>
On Wed, May 30, 2007 at 10:09:11AM -0500, Scott Wood wrote:
> David Gibson wrote:
> > +void cuboot_init(unsigned long r4, unsigned long r5,
> > + unsigned long r6, unsigned long r7,
> > + unsigned long end_of_ram);
> > +
> > +#define CUBOOT_INIT() \
> > + do { \
> > + memcpy(&bd, (bd_t *)r3, sizeof(bd)); \
> > + cuboot_init(r4, r5, r6, r7, bd.bi_memstart + bd.bi_memsize); \
> > + } while (0)
>
> Is there any particular reason to not just do a direct call to
> cuboot_init, and move the memcpy and end-of-ram calculation there? I'd
> rather avoid macros if possible.
Uh.. yeah.. because cuboot_init() doesn't know the size to memcpy(),
because it doesn't have the right bd_t definition.
> Also, the "extern char _dtb_start[], _dtb_end[];" line in cuboot.c
> doesn't appear to be needed.
Oh, yeah, that's a hangover from when I had the ft initialization in
there as well. That works for 83xx and 85xx, but not ebony.
> Other than that, it looks good.
>
> -Scott
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: Consolidate cuboot initialization code
From: Scott Wood @ 2007-05-30 15:09 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20070530020110.GC21955@localhost.localdomain>
David Gibson wrote:
> +void cuboot_init(unsigned long r4, unsigned long r5,
> + unsigned long r6, unsigned long r7,
> + unsigned long end_of_ram);
> +
> +#define CUBOOT_INIT() \
> + do { \
> + memcpy(&bd, (bd_t *)r3, sizeof(bd)); \
> + cuboot_init(r4, r5, r6, r7, bd.bi_memstart + bd.bi_memsize); \
> + } while (0)
Is there any particular reason to not just do a direct call to
cuboot_init, and move the memcpy and end-of-ram calculation there? I'd
rather avoid macros if possible.
Also, the "extern char _dtb_start[], _dtb_end[];" line in cuboot.c
doesn't appear to be needed.
Other than that, it looks good.
-Scott
^ permalink raw reply
* Re: [Patch ] Kexec Kdump support for POWER6
From: Olof Johansson @ 2007-05-30 14:33 UTC (permalink / raw)
To: Sachin P. Sant; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <465D099B.3020207@in.ibm.com>
On Wed, May 30, 2007 at 10:50:27AM +0530, Sachin P. Sant wrote:
> Paul, here is the final version of the patch with all review
> comments incorporated.
>
> Thanks
> -Sachin
>
>
> * On Power machines supporting VRMA, Kexec/Kdump does not work.
> * Hypervisor stores VRMA mapping used by the OS, in the hpte hash tables.
> * Make sure these hpte entries are left untouched.
> *
> * This patch also adds plpar_pte_read_raw() on the lines of
> * plpar_pte_remove_raw().
>
> Signed-off-by : Sachin Sant <sachinp@in.ibm.com>
> Signed-off-by : Mohan Kumar M <mohan@in.ibm.com>
Acked-by: Olof Johansson <olof@lixom.net>
-Olof
^ permalink raw reply
* Re: [PATCH 2.6.22-rc3] ehea: Fixed multi queue RX bug
From: Jeff Garzik @ 2007-05-30 14:00 UTC (permalink / raw)
To: Thomas Klein
Cc: Thomas Klein, Jan-Bernd Themann, netdev, linux-kernel,
Christoph Raisch, Stefan Roscher, linux-ppc, Marcus Eder
In-Reply-To: <200705301239.23934.osstklei@de.ibm.com>
Thomas Klein wrote:
> Must access the respective queue's dummy netdev instead of the port's netdev.
>
> Signed-off-by: Thomas Klein <tklein@de.ibm.com>
applied
^ permalink raw reply
* Re: Fix problems with Holly's DT representation of ethernet PHYs
From: Josh Boyer @ 2007-05-30 13:48 UTC (permalink / raw)
To: Segher Boessenkool
Cc: Alexandre Bounine, David Gibson, Paul Mackerras,
linuxppc-dev list
In-Reply-To: <8b93622a41f822c7b8444d42deb9e5ac@kernel.crashing.org>
On Wed, 2007-05-30 at 13:36 +0200, Segher Boessenkool wrote:
> > We're adding these compatible properties to DTS files and the drivers
> > at
> > the same time. Unless (until?) there are firmwares for these boards
> > that start specifying something else in a real device tree, it really
> > doesn't matter much.
>
> Sure. So you have time to work out things now, I
> suggest you take advantage of that :-)
>
> > Not that there's anything wrong with your
> > reasoning. Just seems like we're trying really hard to define
> > something
> > "correctly" when we control what's on both sides :).
>
> Right now, and in your case, you do. OTOH, the
> goal is to have the DTS be a well-established
> stable interface between the firmware/bootloader/
> bootwrapper and the kernel; there is no room for
> either side of that interface playing dirty tricks,
> not on any board ;-)
>
> Also, the DTS files in the kernel source tree should
> server as a best-of-breed example for people doing
> custom device trees for their own boards. We better
> whip them into good shape or we'll all look foolish...
Yeah, I know. Ignore my earlier email. I blame it on lack of sleep.
The only issue we might have in the future is if DT capable firmware for
these boards shows up and does something completely different.
Hopefully that won't happen.
josh
^ permalink raw reply
* Re: [PATCH v2]: Fix e500 v2 core reboot bug
From: Kumar Gala @ 2007-05-30 13:49 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev list, Paul Mackerras
In-Reply-To: <19325B38-202C-4837-9BE8-0ACA482F2605@kernel.crashing.org>
>>>>> I'm not terrible happy with blindly writing to rstcr.
>>>>>
>>>> I can understand you.
>>>> But I jut want to make things simple and workable.
>>>> Any idea?
>>>
>>> one idea would be for us to add a property on the soc node.
>>> Something like has-rstcr or something similar in a guts node?
>> I have seen your suggestion before to add a property in device tree.
>> But I still think the current implementation is simple.
>
> While it simple you are depending on the fact that a given
> implementation may or may not have something at the particular
> offset. Who knows if 8599 or some future part could put the 'cause
> my part to smoke and self-destruct' at the same offset in the
> future :)
>
>> Anyway, I can try your suggestion.
>
> I'm thinking have a guts block and putting a property in it makes the
> most sense.
After some discussion on IRC I think the following is the suggested
node we should add in.
guts@e00000 {
compatible = "fsl,mpc8548-guts";
reg = <e00000 1000>;
fsl,has-rstcr;
};
- k
^ permalink raw reply
* Re: Fix problems with device tree representation of TSI-1xx bridges
From: Josh Boyer @ 2007-05-30 13:44 UTC (permalink / raw)
To: David Gibson; +Cc: Alexandre Bounine, Paul Mackerras, linuxppc-dev list
In-Reply-To: <20070530013718.GB21955@localhost.localdomain>
On Wed, 2007-05-30 at 11:37 +1000, David Gibson wrote:
> This patch fixes some problems with the way the some things
> represented in the device tree for the Holly and Taiga boards. This
> means changes both to the dts files, and to the code which
> instantiates the tsi108 ethernet platform devices based on the device
> tree.
Looks great. Thanks for the cleanups David. I had some of these on my
list as well.
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Acked-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
josh
^ permalink raw reply
* Re: Fix problems with device tree representation of TSI-1xx bridges
From: Segher Boessenkool @ 2007-05-30 13:28 UTC (permalink / raw)
To: David Gibson; +Cc: Alexandre Bounine, Paul Mackerras, linuxppc-dev list
In-Reply-To: <20070530013718.GB21955@localhost.localdomain>
> This patch fixes some problems with the way the some things
> represented in the device tree for the Holly and Taiga boards. This
> means changes both to the dts files, and to the code which
> instantiates the tsi108 ethernet platform devices based on the device
> tree.
Looks fine now :-)
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Acked-by: Segher Boessenkool <segher@kernel.crashing.org>
Segher
^ permalink raw reply
* Re: Saving to 32 bits of GPRs in signal context
From: Segher Boessenkool @ 2007-05-30 13:14 UTC (permalink / raw)
To: Felix Domke; +Cc: linuxppc-dev list
In-Reply-To: <1180525953.1F02B585@fk13.dngr.org>
>>> Anyway, please don't. It is *not* portable.
>> What are you talking about ? Really, I mean, I'm not sure I understand
>> what you mean :-)
> Segher stated that there is no portable way of detecting whether 64bit
> instructions are available, and said that just trying a 64bit insn (and
> catching the SIGILL if thre cpu is 32bit) is probably the most portable
> way to do so. (Or did i got *that* wrong? If so, please ignore.)
That is exactly what I said. Note I didn't say it
is the *best* method, just the most portable one :-)
> Now my objection is that the "SIGILL"-way is not only ugly, but can be
> easily *wrong*, as there are certain possibilities (Book-E 64bit,
> non-64bit-aware OS, ...) when the CPU might not throw an exception.
All those cases would throw an exception.
> (My
> "ffmpeg with vmx"-experience shows this is a real world issue, although
> the situation is a bit different there, i agree, since vmx opcodes are
> not exclusively reserved for vmx)
Yeah nasty business.
Segher
^ permalink raw reply
* Re: [RFC/PATCH 5/5] powerpc: Allow ptrace write to pt_regs trap
From: Ulrich Weigand @ 2007-05-30 13:08 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Paul Mackerras, Anton Blanchard
In-Reply-To: <1180474900.19517.203.camel@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 1136 bytes --]
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote on 05/29/2007
11:41:40 PM:
> On Tue, 2007-05-29 at 17:41 +0200, Ulrich Weigand wrote:
> > This doesn't look sufficient. If you want GDB to use the save/
> > restore style means of handling interrupted calls (like i386),
> > at the very least we also need the capability to *write* the
> > orig_gpr3 field, which is currently prohibited. (I don't know
> > why this is case, though.)
>
> It's not prohibited afaik ... we allow writing to everything <= MQ (39)
> on 32 bits and <= CCR (38) on 64 bits and ORIG_R3 qualifies (34)
Um? I see this in the PTRACE_POKEUSR case in arch_ptrace:
if (index == PT_ORIG_R3)
break;
Mit freundlichen Gruessen / Best Regards
Ulrich Weigand
--
Dr. Ulrich Weigand | Phone: +49-7031/16-3727
GNU compiler/toolchain for Linux on System z and Cell BE
IBM Deutschland Entwicklung GmbH
Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung:
Herbert Kircher
Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht
Stuttgart, HRB 243294
[-- Attachment #2: Type: text/html, Size: 1611 bytes --]
^ permalink raw reply
* Re: Saving to 32 bits of GPRs in signal context
From: Benjamin Herrenschmidt @ 2007-05-30 12:58 UTC (permalink / raw)
To: Hiroyuki.Mach
Cc: Ulrich Weigand, Steve Munroe, linuxppc-dev list, Paul Mackerras,
Anton Blanchard
In-Reply-To: <feaf5ed90705300548v57bba9c7v157e01c3af07cf9c@mail.gmail.com>
On Wed, 2007-05-30 at 21:48 +0900, Hiroyuki Machida wrote:
>
> I think same framework as proposed at follwoing URLs, works.
> http://penguinppc.org/dev/glibc/glibc-powerpc-cpu-addon.html
> http://sources.redhat.com/ml/libc-alpha/2006-01/msg00094.html
Yeah, it would make sense to define a new feature bit to trigger
automatic loading of optimized libs...
Steve, how hard do you think it would be to extend AT_HWCAP ? Like
adding an AT_HWCAP2 or something like that ?
Ben.
^ permalink raw reply
* Re: [RFC/PATCH 2/4] powerpc: ptrace can set DABR on both 32 and 64 bits
From: Benjamin Herrenschmidt @ 2007-05-30 12:56 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Paul Mackerras, Anton Blanchard, ulrich.weigand
In-Reply-To: <AB7DD12D-76D5-43D8-90BF-904C7C85205E@kernel.crashing.org>
On Wed, 2007-05-30 at 07:44 -0500, Kumar Gala wrote:
> On May 30, 2007, at 3:05 AM, Benjamin Herrenschmidt wrote:
>
> > Allow ptrace to set dabr in the thread structure for both 32 and 64
> > bits,
> > though only 64 bits actually uses that field, it's actually defined
> > in both.
> >
> > Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>
> Can you make these -EIO for CONFIG_BOOKE for now.
I suppose best is to define set_dabr to have a result code...
The std DABR format is good enough to carry a generic setting whatever
the HW implementation is I think.
Ben.
^ 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