* Re: Xilinx devicetrees
From: David H. Lynch Jr. @ 2007-11-26 20:28 UTC (permalink / raw)
To: Grant Likely
Cc: Koss, Mike (Mission Systems), Stephen Neuendorffer,
linuxppc-embedded
In-Reply-To: <fa686aa40711260830y46aeb64cy8b662cad7196af8d@mail.gmail.com>
Grant Likely wrote:
> On 11/26/07, Koss, Mike (Mission Systems) <mike.koss@ngc.com> wrote:
>
>> DL> And once again a plea to ALWAYS make version/capabilities registers
>> DL> atleast an optional part of every design.
>> DL> Embeddeding a device tree into a design might be fairly expensive. a
>> DL> pair of read only 32 bit registers is damn near free - basically the
>> DL> FPGA equivalent of atmost 64 diodes or resistors.
>>
>> SN> Actually, device trees actually seem to be cheaper (in the whole system
>> sense) than such registers. Unless there is something I don't understand?
>>
First the decoding for the register is almost certainly already
present for the other registers for the device.
After that - assuming that an FPGA can impliment a read only
register as easily as discrete logic - it should be damn near the
most trivial peice of hardware imaginable. It is simpler than 64
bits of RAM. It can be simpler than 64bits of ROM.
I do not think there is a way in the world that devicetrees can more
cheaply provide the same information.
They might me more flexible, or powerful, but 2 64bit read only
registers.
Anyway I am not arguing that you should not do devicetrees. Just
that you should do version/capabilities registers - atleast as a IP
option always.
Every OS does nto support devicetree's. Every application of an FPGA
not going to have that as an option. But every peice of software that
can access and I/O device can access its version and capabilities registers.
> *If* edk is generating our device tree(s) for us, *then* version
> registers are not needed by Linux.
>
I want both. I want version registers - because they are ALWAYS
available.
They are available to software running on the FPGA that has no clue
what bit file it is running on,how it got to be running.
Devicetrees may provide a great deal more information bit it is not
hard to come up with scenarios where that information might not
be present. It is like the security arguments about biometric
identification. I can forget my key card, my password, ... But I am
unlikely to forget my thumbprint or retina.
--
Dave Lynch DLA Systems
Software Development: Embedded Linux
717.627.3770 dhlii@dlasys.net http://www.dlasys.net
fax: 1.253.369.9244 Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too numerous to list.
"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein
^ permalink raw reply
* Re: dtc: Remove some redundant testcases
From: Jon Loeliger @ 2007-11-26 21:21 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20071121002918.GC13156@localhost.localdomain>
So, like, the other day David Gibson mumbled:
> This patch removes a number of testcases from the testsuite that are
> extremely unlikely to find any bugs that won't be found by the other
> tests. This speeds up the testsuite.
>
> - Both loops across the various tree block layouts run the
> tree1_tests on the basic mangled tree. This is completely redundant,
> so remove the second copy. This removes 456 testcases.
>
> - We currently run tree1_tests on various trees manipulated by
> move_and_save. We replace those with just a dtbs_equal_ordered test
> to check that the manipulated tree is equal to the original. What
> we're testing here is that fdt_move() operates correctly - it's very
> unlikely it would succeed well enough for the ordered_equal test to
> succeed, but the tree1_tests would fail on the result. This removes
> 162 testcases.
>
> - Currently we re-ordered with mangle-layout both the basic
> test_tree1.dtb and sw_tree1.test.dtb. Since we've already checked
> that these dtbs are equivalent with dtbs_ordered_equal, it's very
> unlikely that the tests would fail on one but not the other.
> Therefore reduce this to only using test_tree1.dtb. This removes 828
> testcases.
Applied.
Thanks,
jdl
^ permalink raw reply
* Re: Xilinx devicetrees
From: David H. Lynch Jr. @ 2007-11-26 21:16 UTC (permalink / raw)
To: Koss, Mike (Mission Systems); +Cc: Stephen Neuendorffer, linuxppc-embedded
In-Reply-To: <EDAE140DF1B2FC42B5867C22CA0B333F0A58E4@XMBIL132.northgrum.com>
Koss, Mike (Mission Systems) wrote:
> Time for my $.02, since I am heavily weighting my future designs on the
> use of the device trees. :) (and b/c I don't check my work e-mail from
> home ;P)
>
> ________________________________
>
> From: Stephen Neuendorffer [mailto:stephen.neuendorffer@xilinx.com]
> Sent: Sunday, November 25, 2007 6:59 PM
> To: David H. Lynch Jr.; Grant Likely; linuxppc-embedded
> Subject: RE: Xilinx devicetrees
>
>
> SN> the device tree is packaged (somehow, TBD) along with the bitstream.
>
If xilinx wants to optionally incorporate the device tree into the
bitstream in a fashion that can easily be worked out by software - that
would be excellent.
>
> I don't know if packaging the device tree with the bitstream is the best
> way to go. It's possible that it could lead to headaches for certain
> systems that have security restrictions.
Make it an option. Where are the systems with security restrictions
going to get their hardware information ?
Besides - though I am not aware off the top of my head of a
bitstream decompliler, still if you have access to the bitstream you
have access to the information about the device. We deal with alot of
high security applications. Security restrictions have to make sense.
blocking devicetrees for security reasons is like telling somebody
they can have the manual in computer readable form, but not on paper.
Further if you are going to boot an OS that requires devicetrees
then the devicetree must be somewhere - whether it is appended to the
bitstream, appended to the kernel, compiled into the kernel, in a
separate file, it still has to be present.
> The same could be said for
> using it w/ the SystemACE to load it into RAM after the image. (which is
> what I'm currently doing for my 2 linux images in lieu of a true on-chip
> bootloader). I am already taking the security concerns into account for
> future revisions of the hardware wrt to using a SystemACE, and am
> planning on moving the device trees into NV storage like FLASH.
>
I am not working with MLXXX boards. Pico has no System ACE. The card
has an FPGA, flash, ram and a few other things all in a
CF/Cardbus/expressbus formfactor. You program it in a host with our
tools. You run it either in the host or standalone.
>
> SN> I don't understand the 'burden on software developers'. The code to
> do this will just be standard code.
I got 16K of RAM for my boot loader and that 16K has to do alot more
than just manage device trees.
I think we have 2K left. In that I have to fit scripting, and
ethernet, so where am I supposed to fit the standard code ?
If the devicetree is say at the end of the bit file I can probably
copy it to ram and pass a pointer to linux in maybe a couple of hundred
bytes.
If I have to do much more it ain't happening.
> The worst that one can say is:
> SN> 1) I need several KB additional non volatile storage. Given the
> size of the FPGA bitstream, this can't be a huge constraint.
>
Several KB is NOT happening. The bitstream is in flash. Flash is
not a limited reasorce for us.
FPGA cells, and BRAM are precious as gold. The more we use the
less our clients have.
Different systems are going to have different resource constraints.
What is unlimited for me may be severely limited for someone
else. What is unlimted for you may be seriously limited for me.
> I do agree that using more FPGA resources is not a solution to the
> problem. I'm already hitting 80% usage on a FX60 and trying to squeeze
> more real estate for storage of the device tree seems silly. Especially
> since that would require that every image have this extra hardware built
> into it just to support booting a Linux kernel. Why should I have to
> have different hardware to boot linux, versus non-kernel, xilkernel, or
> other (GHS, LynxOS, etc..)?
>
One of the problems is that neither devicetrees, nor any of the ways
of tracking them are one size fits all solutions.
I do GHS work, it would be nice if GHS supported devicetrees and
maybe it will.
bound to the kernel, in a separate file, appended to the bitstream
and in the FPGA fabric all have pluses and minuses.
One reason I am harping on version registers is they are extremely
cost cheap, can easily be made optional, and can be fairly easily
incorporated into any OS (or no OS - we do that too). They are not a
replacement for devicetrees. But they still have very important uses in
many environments.
>
> SN> Certainly.. But in a sense, these are all intermediate files on the
> path to the image on the board.
Unless we are going to teach linux to read and interpret .bit files
while loading, then devicetrees are intermediate in an entirely
different sense.
The hardware works fine regardless of whether their is a devicetree.
But Linux may not boot.
My objective is to get alot of software - linux, GHS, and
standalone apps, to all load - from a single executables, accross
multiple different bit images on several different (though deliberately
similar) products. My Linux kernel needs to work regardless of the Pico
card and regardless of the bit image, as done my GHS kernel, and ....
And I need to do that in a severly resource constrained environment.
I would hope that should make sense of my harping about
version/capabilities registers. If I have maybe 10 possible peices of IP
that may/maynot be present in a given FPGA and I am trying to
dynamically configure - Linux/GHS/... to adapt to whatever it encounters
and work as long as it is a viable combination. At best devicetrees are
an extremly complex way of solving that - while version registers are a
trivial way.
As an example I know that if I have a UartLite, Keyhole, TEMAC, PIC,
... they will always be at specific addresses. We never move them.
But I do not know for sure it they are present. A version register
provides a fairly safe very efficient means of checking that a device is
present (and establishing its version and maybe capabilites) - device
trees might do the same thing but have alot higher overhead to do so.
I deal more with presence/absence issues and maybe what version is
the IP rather than hardware is the IP and what IRQ is it using.
--
Dave Lynch DLA Systems
Software Development: Embedded Linux
717.627.3770 dhlii@dlasys.net http://www.dlasys.net
fax: 1.253.369.9244 Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too numerous to list.
"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein
^ permalink raw reply
* Re: [RFC/PATCH] powerpc: Move CPM command handling into the cpm drivers
From: Vitaly Bordug @ 2007-11-26 21:22 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20071126162446.GA4408@loki.buserror.net>
On Mon, 26 Nov 2007 10:24:46 -0600
Scott Wood wrote:
> On Fri, Nov 23, 2007 at 12:51:21AM +0300, Vitaly Bordug wrote:
> > Even that might be not enough - we may have simultaneous call of
> > this func in non-smp case...
>
> Do you really think that every piece of code that uses spinlocks in
> the kernel is broken on non-SMP?
>
No. I think spinlock is not universal save thing in such cases. See below.
> > I was thinking of some kind of refcount, so one that is going to
> > issue CPM command, must do say pq_cpmp_get() and another driver
> > won't be able to mangle with cpcr while it's not done with previous
> > request.
>
> How on earth are you going to effect mutual exclusion using reference
> counting?
>
perhaps I was not clear enough. That was a rough idea how to handle the whole thing,
not just cpm_cr_cmd. This cpm command is a corner case, but there can be other actions
that may confuse CPM being triggered simultaneously or overlapping. This is part of much bigger
problem, and I was intended to have a look what people think about that.
--
Sincerely, Vitaly
^ permalink raw reply
* Re: Xilinx devicetrees
From: David H. Lynch Jr. @ 2007-11-26 21:36 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20071125235855.95B9999804D@mail138-cpk.bigfish.com>
Stephen Neuendorffer wrote:
> In any event, why do you do this rather than just run out of the flash (or a ram copy of the flash?)
>
This is not literally true, but the parameters are nearly the same
- pretend we are using NAND flash and storing executables as elf files.
We can not run from flash because:
The code has not been relocated
the flash is not persistent
We do load the flash/elf file into DRAM dealing with elf issues
along the way and then execute it.
We can do something similar for devicetrees, actually just passing
Linux the offset from the begining of flash to the devicetree would be
sufficient. Or if finding the devicetree inside the bitsstream can be
accomplished fairly simply, just passing the offset of the bit file.
--
Dave Lynch DLA Systems
Software Development: Embedded Linux
717.627.3770 dhlii@dlasys.net http://www.dlasys.net
fax: 1.253.369.9244 Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too numerous to list.
"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein
^ permalink raw reply
* Re: [RFC/PATCH] powerpc: Move CPM command handling into the cpm drivers
From: Scott Wood @ 2007-11-26 21:41 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-dev
In-Reply-To: <20071127002249.612f4ff6@kernel.crashing.org>
Vitaly Bordug wrote:
> perhaps I was not clear enough. That was a rough idea how to handle
> the whole thing, not just cpm_cr_cmd. This cpm command is a corner
> case, but there can be other actions that may confuse CPM being
> triggered simultaneously or overlapping.
What kind of actions did you have in mind? Microcode patching?
-Scott
^ permalink raw reply
* RE: Xilinx EDK BSP generation of device trees for microblaze and PowerPC
From: Stephen Neuendorffer @ 2007-11-26 21:44 UTC (permalink / raw)
To: Grant Likely, Segher Boessenkool, David Gibson, Jon Loeliger
Cc: microblaze-uclinux, Michal Simek, git, linuxppc-dev
In-Reply-To: <fa686aa40711251447t57f96dd4iba51d68e1c9a9c5c@mail.gmail.com>
=20
I've pushed the current state up to
git://git.xilinx.com/gen-mhs-devtree.git for your perusing. Comments
below.
> -----Original Message-----
> From: glikely@secretlab.ca [mailto:glikely@secretlab.ca] On=20
> Behalf Of Grant Likely
> Sent: Sunday, November 25, 2007 2:47 PM
> To: Stephen Neuendorffer; Segher Boessenkool; David Gibson;=20
> Jon Loeliger
> Cc: microblaze-uclinux@itee.uq.edu.au;=20
> linuxppc-dev@ozlabs.org; Michal Simek; git
> Subject: Re: Xilinx EDK BSP generation of device trees for=20
> microblaze and PowerPC
>=20
> On 11/24/07, Stephen Neuendorffer=20
> <stephen.neuendorffer@xilinx.com> wrote:
> >
>=20
> Thanks for all this work; comments below.
>=20
> >
> > Here's what I've gotten so far:
> >
> > Hard_Ethernet_MAC: xps-ll-temac@81c00000 {
> > #address-cells =3D <1>;
> > #size-cells =3D <1>;
> > network@81c00000 {
> > compatible =3D=20
> "xlnx,xps-ll-temac-1.00.a",
> > "xlnx,xps-ll-temac";
>=20
> Drop "xlnx,xps-ll-temac"; it's 100% made up. This should be simply:
> compatible =3D "xlnx,xps-ll-temac-1.00.a" for version 1.00.a and
> compatible =3D
> "xlnx,xps-ll-temac-<version>","xlnx,xps-ll-temac-1.00.a" for a future
> version if it maintains register level compatibility.
>=20
> "xlnx,xps-ll-temac" is far to ambiguous.
What if it was: compatible =3D "xlnx,xps-ll-temac-1.00.a",
"xlnx,xps-ll-temac-1"?
Basically, I don't want to be responsible for declaring what versions of
IP are backward compatible with ll-temac-1.00.a, and I think it's bad
software design to put that list into the dts generator anyway. In
theory, at least, all ip with the same major version should be
compatible.
> > interrupt-parent =3D <&xps_intc_0>;
> > interrupts =3D < 3 0 >;
> > llink-connected =3D <&PIM3>;
>=20
> What's this property for?
So that the ll_temac knows whether to use dma or fifo code and where the
dma or fifo control/interrupts are.
>=20
> > reg =3D < 81c00000 40 >;
>=20
> If these registers are addressable, then the parent needs a=20
> 'ranges' property.
I thought ranges weren't necessary in a 1:1 mapping?
> > xlnx,bus2core-clk-ratio =3D <1>;
> > xlnx,phy-type =3D <1>;
> > xlnx,phyaddr =3D <1>;
> > xlnx,rxcsum =3D <0>;
> > xlnx,rxfifo =3D <1000>;
> > xlnx,temac-type =3D <0>;
> > xlnx,txcsum =3D <0>;
> > xlnx,txfifo =3D <1000>;
>=20
> Would be nice to have a 'phy-handle' property as that is what is being
> used on other platforms; but that's not something that EDK knows
> about. It would be nice to have a way to tell EDK what PHY device is
> on the board so it could generate the appropriate mdio and phy nodes.
Yeah, this is going to be a big issue, I think...
^ permalink raw reply
* RE: Xilinx devicetrees
From: Stephen Neuendorffer @ 2007-11-26 21:55 UTC (permalink / raw)
To: David H. Lynch Jr., Koss, Mike (Mission Systems); +Cc: linuxppc-embedded
In-Reply-To: <474B37C9.8020405@dlasystems.com>
=20
> -----Original Message-----
> From: David H. Lynch Jr. [mailto:dhlii@dlasystems.com]=20
> Sent: Monday, November 26, 2007 1:17 PM
> To: Koss, Mike (Mission Systems)
> Cc: Stephen Neuendorffer; Grant Likely; linuxppc-embedded
> Subject: Re: Xilinx devicetrees
>=20
> Koss, Mike (Mission Systems) wrote:
> > Time for my $.02, since I am heavily weighting my future=20
> designs on the
> > use of the device trees. :) (and b/c I don't check my work=20
> e-mail from
> > home ;P)
> >
> > ________________________________
> >
> > From: Stephen Neuendorffer [mailto:stephen.neuendorffer@xilinx.com]=20
> > Sent: Sunday, November 25, 2007 6:59 PM
> > To: David H. Lynch Jr.; Grant Likely; linuxppc-embedded
> > Subject: RE: Xilinx devicetrees
> >
> >
>=20
> >
> > SN> I don't understand the 'burden on software developers'.=20
> The code to
> > do this will just be standard code. =20
> I got 16K of RAM for my boot loader and that 16K has to=20
> do alot more
> than just manage device trees.
> I think we have 2K left. In that I have to fit scripting, and
> ethernet, so where am I supposed to fit the standard code ?
> If the devicetree is say at the end of the bit file I can probably
> copy it to ram and pass a pointer to linux in maybe a couple=20
> of hundred
> bytes.
> If I have to do much more it ain't happening.
Personally, It sounds like you're trying to do to much... The only
thing that that code really needs to do is to find the 'real' boot code:
Maybe Uboot stored in flash? :) I'm not naive enough to suggest that I
understand all the constraints of your system, but it is another
solution.
> > The worst that one can say is:
> > SN> 1) I need several KB additional non volatile storage. Given the
> > size of the FPGA bitstream, this can't be a huge constraint.
> > =20
> Several KB is NOT happening. The bitstream is in=20
> flash. Flash is
> not a limited reasorce for us.
> FPGA cells, and BRAM are precious as gold. The more we use the
> less our clients have.
Device tree should probably be stored in flash, in your case....
> >
> > SN> Certainly.. But in a sense, these are all intermediate=20
> files on the
> > path to the image on the board.
> Unless we are going to teach linux to read and interpret=20
> .bit files
> while loading, then devicetrees are intermediate in an entirely
> different sense.
> The hardware works fine regardless of whether their is a=20
> devicetree.
> But Linux may not boot.
I think this philosphy really minimized the value of software... The
hardware doesn't work unless the software that comes with it *also*
works. :)
> My objective is to get alot of software - linux, GHS, and
> standalone apps, to all load - from a single executables, accross
> multiple different bit images on several different (though=20
> deliberately
> similar) products. My Linux kernel needs to work regardless=20
> of the Pico
> card and regardless of the bit image, as done my GHS kernel, and ....
> And I need to do that in a severly resource constrained environment.
> I would hope that should make sense of my harping about
> version/capabilities registers. If I have maybe 10 possible=20
> peices of IP
> that may/maynot be present in a given FPGA and I am trying to
> dynamically configure - Linux/GHS/... to adapt to whatever it=20
> encounters
> and work as long as it is a viable combination. At best=20
> devicetrees are
> an extremly complex way of solving that - while version=20
> registers are a
> trivial way.
It sounds like the real problem that you have is that even if you get
device trees working for Linux, you still have the same problem for GHS,
so from your perspective "device trees don't help"
Steve
^ permalink raw reply
* Re: Xilinx devicetrees
From: Grant Likely @ 2007-11-26 22:09 UTC (permalink / raw)
To: Stephen Neuendorffer
Cc: Koss, Mike (Mission Systems), David H. Lynch Jr.,
linuxppc-embedded
In-Reply-To: <20071126215615.73F4B1138066@mail175-dub.bigfish.com>
On 11/26/07, Stephen Neuendorffer <stephen.neuendorffer@xilinx.com> wrote:
>
>
> > -----Original Message-----
> > From: David H. Lynch Jr. [mailto:dhlii@dlasystems.com]
> > Sent: Monday, November 26, 2007 1:17 PM
> > To: Koss, Mike (Mission Systems)
> > Cc: Stephen Neuendorffer; Grant Likely; linuxppc-embedded
> > Subject: Re: Xilinx devicetrees
> >
> > My objective is to get alot of software - linux, GHS, and
> > standalone apps, to all load - from a single executables, accross
> > multiple different bit images on several different (though
> > deliberately
> > similar) products. My Linux kernel needs to work regardless
> > of the Pico
> > card and regardless of the bit image, as done my GHS kernel, and ....
> > And I need to do that in a severly resource constrained environment.
> > I would hope that should make sense of my harping about
> > version/capabilities registers. If I have maybe 10 possible
> > peices of IP
> > that may/maynot be present in a given FPGA and I am trying to
> > dynamically configure - Linux/GHS/... to adapt to whatever it
> > encounters
> > and work as long as it is a viable combination. At best
> > devicetrees are
> > an extremly complex way of solving that - while version
> > registers are a
> > trivial way.
I disagree. I'm not disputing that version registers are valuable.
But I *am* disputing their value for device detection. It may work in
your specific case of devices always in certain locations, but it does
not help the general case where devices can be instantiated anywhere
in the 4GB address space.
>
> It sounds like the real problem that you have is that even if you get
> device trees working for Linux, you still have the same problem for GHS,
> so from your perspective "device trees don't help"
In embedded power.org land, device trees are becoming the recommended
method for describing platform configuration for all embedded powerpc
software. Not just Linux. So from that perspective device trees
might help.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Please pull powerpc.git merge branch
From: Paul Mackerras @ 2007-11-26 22:09 UTC (permalink / raw)
To: torvalds; +Cc: linuxppc-dev
Linus,
Please do
git pull \
git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git merge
to get another batch of fixes for powerpc, as listed below. Since the
pull request I sent last week while you were away, I have added four
more commits from Kumar.
Thanks,
Paul.
Documentation/powerpc/booting-without-of.txt | 5 +
arch/powerpc/boot/dts/mpc832x_mds.dts | 16 ++-
arch/powerpc/boot/dts/mpc834x_mds.dts | 9 ++
arch/powerpc/boot/dts/mpc836x_mds.dts | 9 ++
arch/powerpc/boot/dts/mpc8544ds.dts | 20 ++--
arch/powerpc/boot/dts/mpc8572ds.dts | 108 ++++++++++++++++++---
arch/powerpc/boot/dts/mpc8641_hpcn.dts | 126 ++++++++++++++++++++----
arch/powerpc/configs/mpc832x_mds_defconfig | 48 +++++++++
arch/powerpc/configs/mpc832x_rdb_defconfig | 41 +++++++-
arch/powerpc/configs/mpc834x_itx_defconfig | 2
arch/powerpc/configs/mpc834x_itxgp_defconfig | 88 +++++++++++++++++
arch/powerpc/configs/mpc834x_mds_defconfig | 48 +++++++++
arch/powerpc/configs/mpc836x_mds_defconfig | 48 +++++++++
arch/powerpc/configs/mpc8568mds_defconfig | 48 +++++++++
arch/powerpc/kernel/asm-offsets.c | 4 +
arch/powerpc/kernel/rtas.c | 111 ++++++++++++---------
arch/powerpc/kernel/time.c | 5 +
arch/powerpc/kernel/vdso.c | 11 ++
arch/powerpc/kernel/vdso32/cacheflush.S | 41 ++++++--
arch/powerpc/kernel/vdso64/cacheflush.S | 41 ++++++--
arch/powerpc/mm/mem.c | 2
arch/powerpc/mm/mmu_decl.h | 2
arch/powerpc/mm/stab.c | 1
arch/powerpc/platforms/40x/walnut.c | 3 -
arch/powerpc/platforms/44x/bamboo.c | 3 -
arch/powerpc/platforms/44x/ebony.c | 3 -
arch/powerpc/platforms/44x/sequoia.c | 3 -
arch/powerpc/platforms/83xx/mpc832x_mds.c | 31 +-----
arch/powerpc/platforms/83xx/mpc832x_rdb.c | 14 ++-
arch/powerpc/platforms/83xx/mpc834x_mds.c | 24 -----
arch/powerpc/platforms/83xx/mpc836x_mds.c | 55 +++++-----
arch/powerpc/platforms/83xx/usb.c | 8 +-
arch/powerpc/platforms/cell/spufs/inode.c | 1
arch/powerpc/platforms/embedded6xx/prpmc2800.c | 1
arch/powerpc/platforms/pasemi/setup.c | 2
arch/powerpc/platforms/pseries/Kconfig | 2
arch/powerpc/platforms/pseries/setup.c | 3 -
arch/powerpc/sysdev/uic.c | 18 +++
arch/ppc/kernel/setup.c | 7 +
arch/ppc/mm/init.c | 2
arch/ppc/mm/mmu_decl.h | 2
arch/ppc/platforms/4xx/yucca.c | 1
arch/ppc/syslib/virtex_devices.c | 31 ++++++
include/asm-powerpc/page_32.h | 4 +
include/asm-powerpc/pci-bridge.h | 5 +
include/asm-powerpc/rtas.h | 3 -
include/asm-powerpc/vdso_datapage.h | 8 ++
47 files changed, 832 insertions(+), 236 deletions(-)
Anton Vorontsov (2):
[POWERPC] 83xx: MPC832x RDB - remove spidev stub, use mmc_spi
[POWERPC] 83xx: Update mpc832x_rdb_defconfig to enable MMC-over-SPI
Benjamin Herrenschmidt (3):
[POWERPC] Fix declaration of pcibios_free_controller
[POWERPC] Fix kmalloc alignment on non-coherent DMA platforms
[POWERPC] Fix 8xx build breakage due to _tlbie changes
Cyrill Gorcunov (1):
[POWERPC] Fix potential NULL dereference
Grant Likely (1):
[POWERPC] 83xx: Update mpc8349emitx(gp) defconfig for USB
Jeremy Kerr (1):
[POWERPC] spufs: Fix context destroy vs /spu readdir race
Joachim Foerster (1):
[POWERPC] Xilinx: Register AC97 Controller Reference with the platform bus
Jon Loeliger (1):
[POWERPC] 4xx: Replace #includes of asm/of_platform.h with linux/of_platform.h.
Josh Boyer (1):
[POWERPC] 4xx: Use virtual PVR value to init FPU on arch/ppc 440EP
Kamalesh Babulal (1):
[POWERPC] Fix build failure on legacy iSeries
Kim Phillips (5):
[POWERPC] 83xx: mpc832x mds: Fix board PHY reset code
[POWERPC] 83xx: Fix 2nd UCC entry in mpc832x_mds.dts
[POWERPC] Document rgmii-rxid and rgmii-txid phy-connection-types
[POWERPC] 83xx: Handle mpc8360 rev. 2.1 RGMII timing erratum
[POWERPC] 8xxx: MDS board RTC fixes
Kumar Gala (1):
[POWERPC] Fix device tree interrupt map for Freescale ULI1575 boards
Linas Vepstas (1):
[POWERPC] Fix RTAS os-term usage on kernel panic
Mark A. Greer (1):
[POWERPC] prpmc2800: Enable L2 cache
Michael Neuling (1):
[POWERPC] Fix possible division by zero in scaled time accounting
Nathan Lynch (1):
[POWERPC] Fix multiple bugs in rtas_ibm_suspend_me code
Olof Johansson (2):
[POWERPC] pasemi: Don't reset mpic at boot
[POWERPC] vdso: Fixes for cache block sizes
Roel Kluin (1):
[POWERPC] 4xx: balance ioremap/ioumap calls for Yucca
Stephen Rothwell (1):
[POWERPC] pSeries: make pseries_defconfig minus PCI build again
Valentine Barshak (1):
[POWERPC] 4xx: UIC add mask_ack callback
^ permalink raw reply
* Re: dtc: Add valgrind support to testsuite
From: Jon Loeliger @ 2007-11-26 22:10 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20071121005614.GD13156@localhost.localdomain>
So, like, the other day David Gibson mumbled:
> This patch adds some options to the run_tests.sh script allowing it to
> run all the testcases under valgrind to check for pointer corruption
> bugs and memory leaks. Invoking "make checkm" will run the testsuite
> with valgrind.
>
> It include a mechanism for specifying valgrind errors to be suppressed
> on a per-testcase basis, and adds a couple of such suppression files
> for the mangle-layout and open_pack testcases which dump for use by
> other testcases a buffer which may contain uninitialized sections. We
> use suppressions rather than initializing the buffer so that valgrind
> will catch any internal access s to the uninitialized data, which
> would be a bug.
>
> The patch also fixes one genuine bug caught by valgrind -
> _packblocks() in fdt_rw.c was using memcpy() where it should have been
> using memmove().
>
> At present the valgrinding won't do anything useful for testcases
> invoked via a shell script - which includes all the dtc testcases. I
> plan to fix that later.
>
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Applied.
Thanks,
jdl
PS -- Clearly, I'm going to have to break down and install valgrind now. :-)
^ permalink raw reply
* Re: dtc: Merge refs and labels into single "markers" list
From: Jon Loeliger @ 2007-11-26 22:11 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20071122003707.GF19445@localhost.localdomain>
So, like, the other day David Gibson mumbled:
> Currently, every 'data' object, used to represent property values, has
> two lists of fixup structures - one for labels and one for references.
> Sometimes we want to look at them separately, but other times we need
> to consider both types of fixup.
>
> I'm planning to implement string references, where a full path rather
> than a phandle is substituted into a property value. Adding yet
> another list of fixups for that would start to get messy. So, this
> patch merges the "refs" and "labels" lists into a single list of
> "markers", each of which has a type field indicating if it represents
> a label or a phandle reference. String references or any other new
> type of in-data marker will then just need a new type value - merging
> data blocks and other common manipulations will just work.
>
> While I was at it I made some cleanups to the handling of fixups which
> simplify things further.
>
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Applied.
Thanks,
jdl
^ permalink raw reply
* Re: dtc: Flexible tree checking infrastructure (v2)
From: Jon Loeliger @ 2007-11-26 22:13 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20071122033807.GH19445@localhost.localdomain>
So, like, the other day David Gibson mumbled:
> dtc: Flexible tree checking infrastructure
>
> Here, at last, is a substantial start on revising dtc's infrastructure
> for checking the tree; this is the rework I've been saying was
> necessary practically since dtc was first release.
>
> In the new model, we have a table of "check" structures, each with a
> name, references to checking functions, and status variables. Each
> check can (in principle) be individually switched off or on (as either
> a warning or error). Checks have a list of prerequisites, so if
> checks need to rely on results from earlier checks to make sense (or
> even to avoid crashing) they just need to list the relevant other
> checks there.
>
> For now, only the "structural" checks and the fixups for phandle
> references are converted to the new mechanism. The rather more
> involved semantic checks (which is where this new mechanism will
> really be useful) will have to be converted in future patches.
>
> At present, there's no user interface for turning on/off the checks -
> the -f option now forces output even if "error" level checks fail.
> Again, future patches will be needed to add the fine-grained control,
> but that should be quite straightforward with the infrastructure
> implemented here.
>
> Also adds a testcase for the handling of bad references, which catches
> a bug encountered while developing this patch.
>
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
While I've Applied this one, it has introduced this:
CC dtc.o
dtc.c: In function 'main':
dtc.c:199: warning: 'structure_ok' is used uninitialized in this function
Followup easy patch?
Thanks,
jdl
^ permalink raw reply
* [PATCH 0/3][RESEND] fixups for mpc8360 rev. 2.1 erratum #2 (RGMII Timing)
From: Kim Phillips @ 2007-11-26 22:17 UTC (permalink / raw)
To: jgarzik; +Cc: netdev, Li Yang, linuxppc-dev
these 3 patches are a resend of patches 2-4 (out of 5) that were
originally sent 2007-11-05* (patches 1 and 5 were picked up by Kumar
to go through powerpc).
Jeff, Leo has acked these, please consider for 2.6.24.
Thanks,
Kim
* http://marc.info/?l=linux-netdev&m=119428688804765&w=1
^ permalink raw reply
* [PATCH 1/3][RESEND] phylib: add PHY interface modes for internal delay for tx and rx only
From: Kim Phillips @ 2007-11-26 22:17 UTC (permalink / raw)
To: jgarzik; +Cc: netdev, Li Yang, linuxppc-dev
Allow phylib specification of cases where hardware needs to configure
PHYs for Internal Delay only on either RX or TX (not both).
Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
Tested-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Acked-by: Li Yang <leoli@freescale.com>
---
include/linux/phy.h | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/include/linux/phy.h b/include/linux/phy.h
index f0742b6..e10763d 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -58,6 +58,8 @@ typedef enum {
PHY_INTERFACE_MODE_RMII,
PHY_INTERFACE_MODE_RGMII,
PHY_INTERFACE_MODE_RGMII_ID,
+ PHY_INTERFACE_MODE_RGMII_RXID,
+ PHY_INTERFACE_MODE_RGMII_TXID,
PHY_INTERFACE_MODE_RTBI
} phy_interface_t;
--
1.5.2.2
^ permalink raw reply related
* [PATCH 2/3][RESEND] phylib: marvell: add support for TX-only and RX-only Internal Delay
From: Kim Phillips @ 2007-11-26 22:17 UTC (permalink / raw)
To: jgarzik; +Cc: netdev, Li Yang, linuxppc-dev
Previously, Internal Delay specification implied the delay be
applied to both TX and RX. This patch allows for separate TX/RX-only
internal delay specification.
Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
Tested-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Acked-by: Li Yang <leoli@freescale.com>
---
drivers/net/phy/marvell.c | 26 +++++++++++++++++---------
1 files changed, 17 insertions(+), 9 deletions(-)
diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
index 035fd41..f057407 100644
--- a/drivers/net/phy/marvell.c
+++ b/drivers/net/phy/marvell.c
@@ -143,21 +143,29 @@ static int m88e1111_config_init(struct phy_device *phydev)
int err;
if ((phydev->interface == PHY_INTERFACE_MODE_RGMII) ||
- (phydev->interface == PHY_INTERFACE_MODE_RGMII_ID)) {
+ (phydev->interface == PHY_INTERFACE_MODE_RGMII_ID) ||
+ (phydev->interface == PHY_INTERFACE_MODE_RGMII_RXID) ||
+ (phydev->interface == PHY_INTERFACE_MODE_RGMII_TXID)) {
int temp;
- if (phydev->interface == PHY_INTERFACE_MODE_RGMII_ID) {
- temp = phy_read(phydev, MII_M1111_PHY_EXT_CR);
- if (temp < 0)
- return temp;
+ temp = phy_read(phydev, MII_M1111_PHY_EXT_CR);
+ if (temp < 0)
+ return temp;
+ if (phydev->interface == PHY_INTERFACE_MODE_RGMII_ID) {
temp |= (MII_M1111_RX_DELAY | MII_M1111_TX_DELAY);
-
- err = phy_write(phydev, MII_M1111_PHY_EXT_CR, temp);
- if (err < 0)
- return err;
+ } else if (phydev->interface == PHY_INTERFACE_MODE_RGMII_RXID) {
+ temp &= ~MII_M1111_TX_DELAY;
+ temp |= MII_M1111_RX_DELAY;
+ } else if (phydev->interface == PHY_INTERFACE_MODE_RGMII_TXID) {
+ temp &= ~MII_M1111_RX_DELAY;
+ temp |= MII_M1111_TX_DELAY;
}
+ err = phy_write(phydev, MII_M1111_PHY_EXT_CR, temp);
+ if (err < 0)
+ return err;
+
temp = phy_read(phydev, MII_M1111_PHY_EXT_SR);
if (temp < 0)
return temp;
--
1.5.2.2
^ permalink raw reply related
* [PATCH 3/3][RESEND] ucc_geth: handle passing of RX-only and TX-only internal delay PHY connection type parameters
From: Kim Phillips @ 2007-11-26 22:17 UTC (permalink / raw)
To: jgarzik; +Cc: netdev, Li Yang, linuxppc-dev
Extend the RGMII-Internal Delay specification case to include
TX-only and RX-only variants.
Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
Tested-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Acked-by: Li Yang <leoli@freescale.com>
---
drivers/net/ucc_geth.c | 10 ++++++++++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
index a3ff270..7f68990 100644
--- a/drivers/net/ucc_geth.c
+++ b/drivers/net/ucc_geth.c
@@ -1460,6 +1460,8 @@ static int adjust_enet_interface(struct ucc_geth_private *ugeth)
if ((ugeth->phy_interface == PHY_INTERFACE_MODE_RMII) ||
(ugeth->phy_interface == PHY_INTERFACE_MODE_RGMII) ||
(ugeth->phy_interface == PHY_INTERFACE_MODE_RGMII_ID) ||
+ (ugeth->phy_interface == PHY_INTERFACE_MODE_RGMII_RXID) ||
+ (ugeth->phy_interface == PHY_INTERFACE_MODE_RGMII_TXID) ||
(ugeth->phy_interface == PHY_INTERFACE_MODE_RTBI)) {
upsmr |= UPSMR_RPM;
switch (ugeth->max_speed) {
@@ -1557,6 +1559,8 @@ static void adjust_link(struct net_device *dev)
if ((ugeth->phy_interface == PHY_INTERFACE_MODE_RMII) ||
(ugeth->phy_interface == PHY_INTERFACE_MODE_RGMII) ||
(ugeth->phy_interface == PHY_INTERFACE_MODE_RGMII_ID) ||
+ (ugeth->phy_interface == PHY_INTERFACE_MODE_RGMII_RXID) ||
+ (ugeth->phy_interface == PHY_INTERFACE_MODE_RGMII_TXID) ||
(ugeth->phy_interface == PHY_INTERFACE_MODE_RTBI)) {
if (phydev->speed == SPEED_10)
upsmr |= UPSMR_R10M;
@@ -3795,6 +3799,10 @@ static phy_interface_t to_phy_interface(const char *phy_connection_type)
return PHY_INTERFACE_MODE_RGMII;
if (strcasecmp(phy_connection_type, "rgmii-id") == 0)
return PHY_INTERFACE_MODE_RGMII_ID;
+ if (strcasecmp(phy_connection_type, "rgmii-txid") == 0)
+ return PHY_INTERFACE_MODE_RGMII_TXID;
+ if (strcasecmp(phy_connection_type, "rgmii-rxid") == 0)
+ return PHY_INTERFACE_MODE_RGMII_RXID;
if (strcasecmp(phy_connection_type, "rtbi") == 0)
return PHY_INTERFACE_MODE_RTBI;
@@ -3889,6 +3897,8 @@ static int ucc_geth_probe(struct of_device* ofdev, const struct of_device_id *ma
case PHY_INTERFACE_MODE_GMII:
case PHY_INTERFACE_MODE_RGMII:
case PHY_INTERFACE_MODE_RGMII_ID:
+ case PHY_INTERFACE_MODE_RGMII_RXID:
+ case PHY_INTERFACE_MODE_RGMII_TXID:
case PHY_INTERFACE_MODE_TBI:
case PHY_INTERFACE_MODE_RTBI:
max_speed = SPEED_1000;
--
1.5.2.2
^ permalink raw reply related
* RE: Xilinx devicetrees
From: Koss, Mike (Mission Systems) @ 2007-11-26 22:19 UTC (permalink / raw)
To: David H. Lynch Jr.; +Cc: Stephen Neuendorffer, linuxppc-embedded
In-Reply-To: <474B37C9.8020405@dlasystems.com>
=20
>> I don't know if packaging the device tree with the bitstream is the=20
>> best way to go. It's possible that it could lead to headaches for=20
>> certain systems that have security restrictions.
> Make it an option. Where are the systems with security restrictions
going to get their hardware information ?
> Besides - though I am not aware off the top of my head of a
bitstream decompliler, still if you have access to the bitstream you
have access to
> the information about the device. We deal with alot of high security
applications. Security restrictions have to make sense.
> blocking devicetrees for security reasons is like telling somebody
they can have the manual in computer readable form, but not on paper.
> Further if you are going to boot an OS that requires devicetrees
then the devicetree must be somewhere - whether it is appended to the
bitstream,
> appended to the kernel, compiled into the kernel, in a separate file,
it still has to be present.
The devicetree itself is not the security concern, but the retrieval of
it from the bitstream. If it is stored in the FPGA, it may be that
accessing that stored information may not be probable at run-time.
>> The worst that one can say is:
>> SN> 1) I need several KB additional non volatile storage. Given the
>> size of the FPGA bitstream, this can't be a huge constraint.
>> =20
> Several KB is NOT happening. The bitstream is in flash. Flash is
not a limited reasorce for us.
> FPGA cells, and BRAM are precious as gold. The more we use the
less our clients have.
Which is why I'm proposing that it be an "extra" file that can be stored
however. For one system, it could be stored in the FPGA using BRAM and
it could be automatically available to kernel. For another system, it
could be stored in FLASH and the bootloader may have to copy the data
from FLASH to RAM.
>> I do agree that using more FPGA resources is not a solution to the=20
>> problem. I'm already hitting 80% usage on a FX60 and trying to
squeeze=20
>> more real estate for storage of the device tree seems silly.=20
>> Especially since that would require that every image have this extra=20
>> hardware built into it just to support booting a Linux kernel. Why=20
>> should I have to have different hardware to boot linux, versus=20
>> non-kernel, xilkernel, or other (GHS, LynxOS, etc..)?
>> =20
> One of the problems is that neither devicetrees, nor any of the
ways of tracking them are one size fits all solutions.
> I do GHS work, it would be nice if GHS supported devicetrees and
maybe it will.
> bound to the kernel, in a separate file, appended to the bitstream
and in the FPGA fabric all have pluses and minuses.
> One reason I am harping on version registers is they are extremely
cost cheap, can easily be made optional, and can be fairly easily
incorporated > into any OS (or no OS - we do that too). They are not a
replacement for devicetrees. But they still have very important uses in
many environments.
>
>> SN> Certainly.. But in a sense, these are all intermediate files on=20
>> SN> the
>> path to the image on the board.
> Unless we are going to teach linux to read and interpret .bit files
while loading, then devicetrees are intermediate in an entirely
different
> sense.
> The hardware works fine regardless of whether their is a
devicetree.
> But Linux may not boot.
You are correct, but I think a single self-contained file that has all
of the hardware descriptions is much preferred to many header files, and
#ifdef macro's to make sense of what is actually available at run-time.
> My objective is to get alot of software - linux, GHS, and
standalone apps, to all load - from a single executables, accross
multiple different
> bit images on several different (though deliberately
> similar) products. My Linux kernel needs to work regardless of the
Pico card and regardless of the bit image, as done my GHS kernel, and
....
> And I need to do that in a severly resource constrained environment.
> I would hope that should make sense of my harping about
version/capabilities registers. If I have maybe 10 possible peices of IP
that may/maynot
> be present in a given FPGA and I am trying to dynamically configure -
Linux/GHS/... to adapt to whatever it encounters and work as long as it
is a
> viable combination. At best devicetrees are an extremly complex way of
solving that - while version registers are a trivial way.
> As an example I know that if I have a UartLite, Keyhole, TEMAC,
PIC, ... they will always be at specific addresses. We never move them.
> But I do not know for sure it they are present. A version register
provides a fairly safe very efficient means of checking that a device is
> present (and establishing its version and maybe capabilites) - device
trees might do the same thing but have alot higher overhead to do so.
For your system, yes, you never move the location of the devices. But
for others, we may add other pieces or multiple pieces and require them
in multiple/different places. That's the beauty of the device tree. You
*can* create that one monolithic kernel that has support for ANY type of
hardware, and at boot-time a device tree is provided to the kernel that
defines all of the devices that are physically available in your FPGA.
I'm not trying to argue for/against the version registers. Just that a
version register is short-sighted with regards to the larger FPGA-based
view. Version registers work wonderfully when everything is staticly
located, like in your image builds or a SoC like 440GX. For general
usage for others creating their own FPGA images with varying hardware
setups, statically defined location version register checking is not
feasible.
The device tree approach can "easily" be adapted to other systems, such
as GHS, through adaptors in your corresponding BSP.
-- Mike
^ permalink raw reply
* Re: mmap on PPC removes file refcount?
From: Dave Jiang @ 2007-11-26 22:30 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <47435338.2050107@mvista.com>
NM, it was a bad test causing weird behavior on PPC. :(
Dave Jiang wrote:
> It seems the mmap() userland call on PPC causes the kernel to lose the ref
> count for the mount point. This is what I did on a prpmc2800 board (74xx) with
> latest powerpc.git tree (but also seem to happen on 8548 as well).
>
> I mounted an IDE partition. The userland test app opens a file on the mounted
> partition and sits in a sleep loop while holding the file open. I call umount
> on the partition and I get "device is busy" which is suppose to happen.
> However, after the test app calls mmap on the file id for the opened file, I
> can successfully umount even though it should still say "device is busy". This
> does not happen on x86 so I'm assuming something is going on with just PPC.
>
> So using lsof I can list the opened files on a particular partition. When the
> file is opened, it lists 1 entry. When mmaped, on x86 it would list 2 entries,
> but on ppc it lists nothing. Not only did the mmaped entry not show up, the
> entry caused by open disappeared as well. Also, I put a printk in do_umount()
> to see what the refcount is. On x86, it would be 3 and thus causes device busy.
> On PPC it is 3 when the file is openend, however if mmap is called, the
> refcount becomes 2 and thus umount proceeds. It's almost as if the mmap call
> wiped out the opened file entry and decremented the mount count as well.
>
>
--
------------------------------------------------------
Dave Jiang
Software Engineer
MontaVista Software, Inc.
http://www.mvista.com
------------------------------------------------------
^ permalink raw reply
* Re: dtc: RFC: Fix some lexical problems with references
From: Jon Loeliger @ 2007-11-26 22:38 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20071122061007.GA22888@localhost.localdomain>
So, like, the other day David Gibson mumbled:
> The recent change to the lexer to only recognize property and node
> names in the appropriate context removed a number of lexical warts in
> our language that would have gotten ugly as we add expression support
> and so forth.
>
> But there's one nasty one remaining: references can contain a full
> path, including the various problematic node name characters (',', '+'
> and '-', for example). This would cause trouble with expressions, and
> it also causes trouble with the patch I'm working on to allow
> expanding references to paths rather than phandles. This patch
> therefore reworks the lexer to mitigate these problems.
>
> - References to labels cause no problems. These are now
> recognized separately from references to full paths. No syntax change
> here.
>
> - References to full paths, including problematic characters
> are allowed by "quoting" the path with braces
> e.g. &{/pci@10000/somedevice@3,8000}. The braces protect any internal
> problematic characters from being confused with operators or whatever.
>
> - For compatibility with existing dts files, in v0 dts files
> we allow bare references to paths as before &/foo/bar/whatever - but
> *only* if the path contains no troublesome characters. Specifically
> only [a-zA-Z0-9_@/] are allowed.
>
> This is an incompatible change to the dts-v1 format, but since AFAIK
> no-one has yet switched to dts-v1 files, I think we can get away with
> it. Better to make the transition when people to convert to v1, and
> get rid of the problematic old syntax.
>
> Strictly speaking, it's also an incompatible change to the v0 format,
> since some path references that were allowed before are no longer
> allowed. I suspect no-one has been using the no-longer-supported
> forms (certainly none of the kernel dts files will cause trouble). We
> might need to think about this harder, though.
This all sounds fine by me. We should take the incompatibility hit
once here and now; it shouldn't be a problem to eek in some more still.
Thanks,
jdl
^ permalink raw reply
* Re: mmap on PPC removes file refcount?
From: Benjamin Herrenschmidt @ 2007-11-26 22:38 UTC (permalink / raw)
To: Dave Jiang; +Cc: linuxppc-dev
In-Reply-To: <474B4923.905@mvista.com>
On Mon, 2007-11-26 at 15:30 -0700, Dave Jiang wrote:
> NM, it was a bad test causing weird behavior on PPC. :(
Ah good, because I did spend some time looking at the code and didn't
see anything wrong :-)
Cheers,
Ben.
^ permalink raw reply
* PPC upstream kernel ignored DABR bug
From: Jan Kratochvil @ 2007-11-26 22:02 UTC (permalink / raw)
To: Paul Mackerras, linuxppc-dev; +Cc: Roland McGrath
Hi,
this testcase:
http://people.redhat.com/jkratoch/dabr-lost.c
reproduces a PPC DABR kernel bug. The variable `variable' should not get
modified as the thread modifying it should be caught by its DABR:
$ ./dabr-lost
TID 30914: DABR 0x10012a77 NIP 0x80f6ebb318
TID 30915: DABR 0x10012a77 NIP 0x80f6ebb318
TID 30916: DABR 0x10012a77 NIP 0x80f6ebb318
TID 30914: hitting the variable
TID 30915: hitting the variable
TID 30916: hitting the variable
variable found = 30916, caught TID = 30914
TID 30916: DABR 0x10012a77
Variable got modified by a thread which has DABR still set!
At the `variable found =' line the parent ptracer found the TID thread 30916
wrote the value into the variable - despite it had DABR alrady set before.
As the behavior is dependent on the current weather I expect the scheduling
matters there.
It is important the target thread is in the `nanosleep' syscall. If you define
WORKAROUND_SET_DABR_IN_SYSCALL in the testcase it busyloops in the userland and
the bug gets no longer reproduced.
I got it reproduced on a utrace-patched kernel on dual-CPU Power5 and Roland
McGrath reported it reproduced on the vanilla upstream kernel on a Mac G5.
Regards,
Jan Kratochvil
^ permalink raw reply
* Re: Sequoia EMAC only works if u-boot initializes it?
From: Steven A. Falco @ 2007-11-26 22:46 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, Stefan Roese
In-Reply-To: <1196107715.7195.107.camel@pasglop>
With the following 15 patches on top of the DENX git tree, I have both emac ports working:
1) [PATCH 2/2] PowerPC: Fix Sequoia MAL0 and EMAC dts entries.
2) [PATCH] PowerPC: Add RGMII support for Sequoia 440EPx
3) [PATCH] Fix typo in new EMAC driver.
4) PowerPC: Enable NEW EMAC support for Sequoia 440EPx.
5) [PATCH 1/8] ibm_newemac: Fix possible lockup on close
6) [PATCH 2/8] ibm_newemac: Add BCM5248 and Marvell 88E1111 PHY support
7) [PATCH 3/8] ibm_newemac: Add ET1011c PHY support
8) [PATCH 4/8] ibm_newemac: Fix ZMII refcounting bug
9) [PATCH 5/8] ibm_newemac: Workaround reset timeout when no link
10) [PATCH 6/8] ibm_newemac: Cleanup/Fix RGMII MDIO support detection
11) [PATCH 7/8] ibm_newemac: Cleanup/fix support for STACR register variants
12) [PATCH 8/8] ibm_newemac: Skip EMACs that are marked unused by the firmware
13) [PATCH 1/3] PowerPC: ibm_newemac correct opb_bus_freq value
14) [PATCH 2/3] PowerPC: ibm_newemac tah_ph typo fix
15) [PATCH 3/3] PowerPC: ibm_newemac call dev_set_drvdata() before tah_reset()
Steve
Benjamin Herrenschmidt wrote:
> On Mon, 2007-11-26 at 14:10 -0500, Steven A. Falco wrote:
>> I've attached a copy of my bootlog. I added in one patch to enable
>> rgmii but that didn't fix
>> it.(http://ozlabs.org/pipermail/linuxppc-dev/2007-October/043435.html)
>>
>> I am curious why the new emac driver is enabled in the DENX tree but
>> not in the upstream trees. Has DENX successfully used this driver on
>> the Sequoia board? Am I trying something that is known not to work?
>>
>> I'm interested in helping in whatever way I can. I need ARCH=powerpc
>> to use the current Xenomai patches, and I need both EMACs so I can
>> evaluate bonding (for high-availability).
>
> Have you tried adding the various patches I posted along with the
> patches Valentine posted ?
>
> I'll re-send a full serie later this week. Let us know if those help or
> if something is still broken.
>
> Cheers,
> Ben.
>
>
>
^ permalink raw reply
* Re: Sequoia EMAC only works if u-boot initializes it?
From: Benjamin Herrenschmidt @ 2007-11-26 22:49 UTC (permalink / raw)
To: Steven A. Falco; +Cc: linuxppc-dev, Stefan Roese
In-Reply-To: <474B4CA9.3070506@harris.com>
On Mon, 2007-11-26 at 17:46 -0500, Steven A. Falco wrote:
> With the following 15 patches on top of the DENX git tree, I have both emac ports working:
.../...
Good. All of these should go in 2.6.25 (not .24 at this stage though).
I suppose DENX will pick them up asap.
Cheers,
Ben.
^ permalink raw reply
* Re: 2.6.24-rc3: High CPU load -- hardware interrupts
From: Elimar Riesebieter @ 2007-11-26 22:38 UTC (permalink / raw)
To: linuxppc-dev; +Cc: joerg
In-Reply-To: <slrnfk1d21.229.joerg@alea.gnuu.de>
[-- Attachment #1: Type: text/plain, Size: 184 bytes --]
Hi,
I can confirm this situation. But it seems, that no one takes care
of it ....
Elimar
--
Excellent day for drinking heavily.
Spike the office water cooler;-)
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ 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