* Re: [PATCH 7/7] [POWERPC] Xilinx: Update booting-without-of.
From: David Gibson @ 2007-12-17 4:14 UTC (permalink / raw)
To: Stephen Neuendorffer; +Cc: linuxppc-dev, simekm2
In-Reply-To: <20071213234151.D0B3DE80061@mail20-sin.bigfish.com>
On Thu, Dec 13, 2007 at 03:43:33PM -0800, Stephen Neuendorffer wrote:
> This now better describes what the UBoot device tree generator actually does. In particular:
>
> 1) Nodes have a label derived from the device name, and a node name
> derived from the device type.
> 2) Usage of compound nodes (representing more than one device in the same IP) which actually works. This requires having a valid compatible node, and all the other things that a bus normally has. I've chosen 'xlnx,compound' as the bus name to describe these compound nodes.
I'm not sure I like this xlnx,compound business, although maybe it's
the best you can do.
> 3) Uartlite requires a port-number property for the console to work.
Why? In general we try to avoid magical sequence numbers - cell-index
should *only* be used when it's needed to index or program some shared
register.
--
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: [PATCH 7/7] [POWERPC] Xilinx: Update booting-without-of.
From: Grant Likely @ 2007-12-17 4:30 UTC (permalink / raw)
To: Stephen Neuendorffer, grant.likely, simekm2, jwilliams,
linuxppc-dev
In-Reply-To: <20071217041455.GA3477@localhost.localdomain>
On 12/16/07, David Gibson <david@gibson.dropbear.id.au> wrote:
> On Thu, Dec 13, 2007 at 03:43:33PM -0800, Stephen Neuendorffer wrote:
> > This now better describes what the UBoot device tree generator actually does. In particular:
> >
> > 1) Nodes have a label derived from the device name, and a node name
> > derived from the device type.
> > 2) Usage of compound nodes (representing more than one device in the same IP) which actually works. This requires having a valid compatible node, and all the other things that a bus normally has. I've chosen 'xlnx,compound' as the bus name to describe these compound nodes.
>
> I'm not sure I like this xlnx,compound business, although maybe it's
> the best you can do.
I'd prefer something like "xlnx,<ip-name>-group". "xlnx,compound" is
a very bad idea because it will be reused for very different types of
devices. What happens when a device appears that has both
per-instance properties and 'top level' registers accessed by both
devices?
>
> > 3) Uartlite requires a port-number property for the console to work.
>
> Why? In general we try to avoid magical sequence numbers - cell-index
> should *only* be used when it's needed to index or program some shared
> register.
Aliases is probably the correct construct for this. port-number was a
bad idea and I never should have gone that direction.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* RE: [PATCH 7/7] [POWERPC] Xilinx: Update booting-without-of.
From: Stephen Neuendorffer @ 2007-12-17 4:48 UTC (permalink / raw)
To: Grant Likely, simekm2, jwilliams, linuxppc-dev
In-Reply-To: <fa686aa40712162030q6f0e6d87j5e6e5379cbd0d54e@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1659 bytes --]
Compound devices that actually have their own shared registers should do something different. Likely they'll need some sort of data synchronization anyway. It seems that by far the common case here is to going to be to just have aggregation, and I don't see any reason that can't be handled by a common 'pseudo-bus'.
Steve
-----Original Message-----
From: glikely@secretlab.ca on behalf of Grant Likely
Sent: Sun 12/16/2007 8:30 PM
To: Stephen Neuendorffer; grant.likely@secretlab.ca; simekm2@fel.cvut.cz; jwilliams@itee.uq.edu.au; linuxppc-dev@ozlabs.org
Subject: Re: [PATCH 7/7] [POWERPC] Xilinx: Update booting-without-of.
On 12/16/07, David Gibson <david@gibson.dropbear.id.au> wrote:
> On Thu, Dec 13, 2007 at 03:43:33PM -0800, Stephen Neuendorffer wrote:
> > This now better describes what the UBoot device tree generator actually does. In particular:
> >
> > 1) Nodes have a label derived from the device name, and a node name
> > derived from the device type.
> > 2) Usage of compound nodes (representing more than one device in the same IP) which actually works. This requires having a valid compatible node, and all the other things that a bus normally has. I've chosen 'xlnx,compound' as the bus name to describe these compound nodes.
>
> I'm not sure I like this xlnx,compound business, although maybe it's
> the best you can do.
I'd prefer something like "xlnx,<ip-name>-group". "xlnx,compound" is
a very bad idea because it will be reused for very different types of
devices. What happens when a device appears that has both
per-instance properties and 'top level' registers accessed by both
devices?
[-- Attachment #2: Type: text/html, Size: 2286 bytes --]
^ permalink raw reply
* RE: Device Tree updates for xilinx.
From: Stephen Neuendorffer @ 2007-12-17 4:58 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev, Michal Simek, git
In-Reply-To: <20071216070404.GK21311@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 1814 bytes --]
Since there don't seem to be any examples of this in the tree: do you have a format preference? For the rest of the compatible lists, I'm using something like: xlnx,ipname-version. So for the microblaze, I'd prefer something like:
xlnx,microblaze-6.00.b
For the powerpc, either ibm,ppc405 or ibm.ppc-405 would seem to be more in character than PowerPC,405.
Steve
-----Original Message-----
From: David Gibson [mailto:david@gibson.dropbear.id.au]
Sent: Sat 12/15/2007 11:04 PM
To: Stephen Neuendorffer
Cc: Grant Likely; Michal Simek; John Williams; linuxppc-dev@ozlabs.org; git
Subject: Re: Device Tree updates for xilinx.
On Thu, Dec 13, 2007 at 03:41:16PM -0800, Stephen Neuendorffer wrote:
>
> For reference, below is the device tree for a Virtex2Pro design. Except
> for the changes noted above, this is entirely automatically generated.
>
> Steve
>
> / {
> mem_size_cells: #address-cells = <1>;
> #size-cells = <1>;
> compatible = "xlnx,virtex";
> model = "testing";
> DDR_256MB_32MX64_rank1_row13_col10_cl2_5: memory@0 {
> device_type = "memory";
> reg = < 0 memsize:10000000 >;
> } ;
> chosen {
> bootargs = "root=/dev/nfs
> nfsroot=172.19.221.221:/exports/xup/ydl41 ip=dhcp console=ttyUL0";
> } ;
> cpus {
> #address-cells = <1>;
> #cpus = <1>;
> #size-cells = <0>;
> PowerPC,405@0 {
I'm trying to encourage people to move to naming cpu nodes simply
"cpu@XX", with the type of core in "compatible" instead - in keeping
with the generic names convention used elsewhere. I think this will
make your generator simpler, too.
--
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
[-- Attachment #2: Type: text/html, Size: 3744 bytes --]
^ permalink raw reply
* Re: [PATCH] [POWERPC][RFC] MPC8360E-RDK: Device tree and board file
From: David Gibson @ 2007-12-17 5:14 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: Stephen Rothwell, linuxppc-dev
In-Reply-To: <20071215162331.GA24999@localhost.localdomain>
On Sat, Dec 15, 2007 at 07:23:31PM +0300, Anton Vorontsov wrote:
> On Tue, Dec 11, 2007 at 12:42:18PM -0600, Kumar Gala wrote:
[snip]
> + soc8360@e0000000 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + device_type = "soc";
> + ranges = <0 0xe0000000 0x00100000>;
> + reg = <0xe0000000 0x00000200>;
> + /* filled by u-boot */
> + bus-frequency = <0>;
> +
> + wdt@200 {
> + device_type = "watchdog";
Drop this device_type.
> + compatible = "mpc83xx_wdt";
> + reg = <0x200 0x100>;
> + };
> +
> + i2c@3000 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + device_type = "i2c";
And this one.
[snip]
> + crypto@30000 {
> + device_type = "crypto";
> + model = "SEC2";
> + compatible = "talitos";
This device_type/compatible/model stuff is also crap, although I
suspect it needs to be fixed in the driver, as gianfar (finally) was.
[snip]
> + ipic: pic@700 {
> + #address-cells = <0>;
> + #interrupt-cells = <2>;
> + interrupt-controller;
> + reg = <0x700 0x100>;
> + device_type = "ipic";
And drop this device_type.
[snip]
> + qe@e0100000 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + device_type = "qe";
And this one.
This node needs a "compatible" too.
> + model = "QE";
> + ranges = <0 0xe0100000 0x00100000>;
> + reg = <0xe0100000 0x480>;
> + /* filled by u-boot */
> + brg-frequency = <0>;
> + bus-frequency = <0>;
This should probably be clock-frequency, not bus-frequency. After
all, it's a bus node, what other sort of frequency would it be.
> + muram@10000 {
> + device_type = "muram";
And this device_type needs to go, too.
> + ranges = <0 0x00010000 0x0000c000>;
> +
> + data-only@0 {
> + reg = <0 0xc000>;
> + };
> + };
> +
> + spi@4c0 {
> + device_type = "spi";
And this one.
[snip]
> + usb@6c0 {
> + device_type = "usb";
And this one.
> + compatible = "qe_udc";
> + reg = <0x6c0 0x40 0x8b00 0x100>;
> + interrupts = <11>;
> + interrupt-parent = <&qeic>;
> + mode = "slave";
> + };
[snip]
> + mdio@2120 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0x2120 0x18>;
> + device_type = "mdio";
And this one.
> + compatible = "ucc_geth_phy";
> +
> + phy1: ethernet-phy@1 {
> + reg = <1>;
> + device_type = "ethernet-phy";
> + };
These phy nodes have basically no information in them. PHY nodes are
optional - only include them if they actually have something useful to
say (which would mean at least a compatible property).
[snip]
> + qeic: qeic@80 {
> + #address-cells = <0>;
> + #interrupt-cells = <1>;
> + interrupt-controller;
> + device_type = "qeic";
Drop this device_type, too.
And this node, too, needs a "compatible" property. Oh, and the node
name should be "interrupt-controller@80" by the generic names
convention.
> + reg = <0x80 0x80>;
> + big-endian;
> + interrupts = <32 8 33 8>;
> + interrupt-parent = <&ipic>;
> + };
> + };
> +};
--
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: Device Tree updates for xilinx.
From: David Gibson @ 2007-12-17 5:21 UTC (permalink / raw)
To: Stephen Neuendorffer; +Cc: linuxppc-dev, Michal Simek, git
In-Reply-To: <20071217045726.DD1881298046@mail127-sin.bigfish.com>
On Sun, Dec 16, 2007 at 08:58:18PM -0800, Stephen Neuendorffer wrote:
>
> Since there don't seem to be any examples of this in the tree: do
> you have a format preference? For the rest of the compatible lists,
> I'm using something like: xlnx,ipname-version. So for the
> microblaze, I'd prefer something like:
>
> xlnx,microblaze-6.00.b
Sounds reasonable.
> For the powerpc, either ibm,ppc405 or ibm.ppc-405 would seem to be
> more in character than PowerPC,405.
Well, we could list both forms, but PowerPC,405 should be included
since it's an established name. There's some history behind this:
before the generic names convention, the node name was used to encode
the most specific register interface for the device, and "compatible"
was used to describe any other interfaces it was also compatible with.
With the generic names convention, the name came to represent the
general type of device, and "compatible" alone was used to describe
the programming interface(s). In Apple and IBM device trees, while
most things reflect the generic names convention, it seems the cpu
nodes were left using the old convention - which is why that approach
was copied and is currently used in all the dts files. So when
converting nodes to the generic names convention, the old content of
the node name should go into "compatible" verbatim as the first entry.
In practice of course, I don't think anything looks at either the name
or the compatible property for cpu nodes (nor do I think they should)
- they'll just use the PVR.
--
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: USB configuration
From: Misbah khan @ 2007-12-17 5:34 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <BLU106-W35DC430E02A0A1798D8B95CA650@phx.gbl>
I have configured for mass storage device still i am not getting the debug
msg that the kernel has detected the pen drive (after i connect the pen
drive ).
" Initializing USB Mass Storage driver...
usbcore: registered new driver usb-storage
USB Mass Storage support registered.=20
"
----misbah=20
Pedro Luis D. L. wrote:
>=20
>=20
>> From: misbah_khan@engineer.com
>> To: linuxppc-embedded@ozlabs.org
>> Subject: RE: USB configuration
>>=20
>>=20
>> I have inserted a USB card reader, and the following dmesg it shows ....=
.
>>=20
>> ------------------------------------------------------------------------=
-------
>> mpc8272ads: Init
>> PCI: Probing PCI hardware
>> PCI: Cannot allocate resource region 0 of device 0000:00:00.0
>> PCI: Cannot allocate resource region 1 of device 0000:00:00.0
>> SCSI subsystem initialized
>> Linux Kernel Card Services
>> options: [pci] [cardbus]
>> usbcore: registered new driver usbfs
>> usbcore: registered new driver hub
>> Serial: CPM driver $Revision: 0.01 $
>> ttyCPM0 at MMIO 0xf0011a00 (irq =3D 40) is a CPM UART
>> ttyCPM1 at MMIO 0xf0011a60 (irq =3D 43) is a CPM UART
>> io scheduler noop registered
>> io scheduler anticipatory registered
>> io scheduler deadline registered
>> io scheduler cfq registered
>> loop: loaded (max 8 devices)
>> fs_enet.c:v1.0 (Aug 8, 2005)
>> fs_enet: eth0 Phy @ 0x0, type DM9161 (0x0181b881)
>> fs_enet: eth1 Phy @ 0x3, type DM9161 (0x0181b881)
>> Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
>> ide: Assuming 33MHz system bus speed for PIO modes; override with
>> idebus=3Dxx
>> st: Version 20041025, fixed bufsize 32768, s/g segs 256
>> osst :I: Tape driver with OnStream support version 0.99.1
>> osst :I: $Id: osst.c,v 1.70 2003/12/23 14:22:12 wriede Exp $
>> ohci_hcd: 2004 Nov 08 USB 1.1 'Open' Host Controller (OHCI) Driver (PCI)
>> ohci_hcd: block sizes: ed 64 td 64
>> drivers/usb/serial/usb-serial.c: USB Serial support registered for
>> Generic
>> usbcore: registered new driver usbserial_generic
>> usbcore: registered new driver usbserial
>> drivers/usb/serial/usb-serial.c: USB Serial Driver core v2.0
>> NET: Registered protocol family 2
>> IP: routing cache hash table of 512 buckets, 4Kbytes
>> TCP: Hash tables configured (established 4096 bind 8192)
>> NET: Registered protocol family 1
>> NET: Registered protocol family 17
>> IP-Config: Complete:
>> device=3Deth1, addr=3D192.168.33.136, mask=3D255.255.248.0,
>> gw=3D192.168.32.47,
>> host=3Dcashel, domain=3D, nis-domain=3D(none),
>> bootserver=3D192.168.33.96, rootserver=3D192.168.33.96, rootpath=3D
>> Looking up port of RPC 100003/2 on 192.168.33.96
>> Looking up port of RPC 100005/1 on 192.168.33.96
>> VFS: Mounted root (nfs filesystem).
>> Freeing unused kernel memory: 104k init
>> ------------------------------------------------------------------------=
--------------
>>=20
>=20
> It looks like it is well configured, because the usbfs and hub are loaded=
.
> You could check in your kernel configuration that you enabled USB Mass
> storage driver and attached a pen drive as I suggested before.
> Another possibility is to insert a card in the USB card reader. Then you
> should be able to see with dmesg if it is recognized.
>=20
> Pedro.
>=20
>> This doesent gives me the clear explaination of whether USB is working
>> properly....
>>=20
>> I would appreciate if you could share with me the basic steps to be
>> followed
>> to confirm that the USB support that i had configured is being tested in
>> all
>> aspects.
>>=20
>> Misbah
>>=20
>> Pedro Luis D. L. wrote:
>>>=20
>>>=20
>>>=20
>>>> Date: Thu, 6 Dec 2007 05:27:14 -0800
>>>> From: misbah_khan@engineer.com
>>>> To: linuxppc-embedded@ozlabs.org
>>>> Subject: USB configuration
>>>>=20
>>>>=20
>>>> HI all ...
>>>=20
>>> Hi,
>>>=20
>>>> I have configured the Montavista Kernel for USB support and for
>>>> PPC8272-ADS
>>>> board I need to know that how could i test that my USB is working ????
>>>>=20
>>>=20
>>> Try to attach an USB device, like a pendrive, to an USB port. Then
>>> type:=20
>>> dmesg | tail
>>>=20
>>> If the USB support is working properly, you should see some output
>>> saying
>>> which device have you attached and where is it mapped.
>>> If you plug a memory stick, you can try to mount it and check that the
>>> filesystem is correct.
>>>=20
>>> Pedro.
>>>=20
>>>> Its creating the directory :- /proc/bus/usb/ but doesent contain any
>>>> file
>>>> under it ????
>>>>=20
>>>>=20
>>>> its also creating the directory :- /sys/bus/usb/ but doesent contain
>>>> any
>>>> file under it ????
>>>>=20
>>>>=20
>>>> Please let me know the procedure to test whether my USB configuration
>>>> is
>>>> all
>>>> right ????
>>>>=20
>>>> Thank u=20
>>>> Misbah <><
>>>> --=20
>>>> View this message in context:
>>>> http://www.nabble.com/USB-configuration-tf4956061.html#a14192347
>>>> Sent from the linuxppc-embedded mailing list archive at Nabble.com.
>>>>=20
>>>> _______________________________________________
>>>> Linuxppc-embedded mailing list
>>>> Linuxppc-embedded@ozlabs.org
>>>> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>>>=20
>>> _________________________________________________________________
>>> Tecnolog=C3=ADa, moda, motor, viajes,=E2=80=A6suscr=C3=ADbete a nuestro=
s boletines para
>>> estar a la =C3=BAltima
>>> http://newsletters.msn.com/hm/maintenanceeses.asp?L=3DES&C=3DES&P=3DWCM=
aintenance&Brand=3DWL&RU=3Dhttp%3a%2f%2fmail.live.com
>>> _______________________________________________
>>> Linuxppc-embedded mailing list
>>> Linuxppc-embedded@ozlabs.org
>>> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>>>=20
>>>=20
>>=20
>> --=20
>> View this message in context:
>> http://www.nabble.com/USB-configuration-tf4956061.html#a14206951
>> Sent from the linuxppc-embedded mailing list archive at Nabble.com.
>>=20
>> _______________________________________________
>> Linuxppc-embedded mailing list
>> Linuxppc-embedded@ozlabs.org
>> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>=20
> _________________________________________________________________
> MSN Video.=20
> http://video.msn.com/?mkt=3Des-es
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>=20
>=20
--=20
View this message in context: http://www.nabble.com/USB-configuration-tp141=
92347p14370084.html
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [DTC][PATCH] Fix cross-compile building
From: David Gibson @ 2007-12-17 5:39 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Jon Loeliger, stuarth
In-Reply-To: <A388C2C2-2452-4E70-A5DA-F61B0E3A2B22@kernel.crashing.org>
On Thu, Dec 13, 2007 at 11:57:48PM -0600, Kumar Gala wrote:
>
> On Dec 7, 2007, at 6:36 PM, David Gibson wrote:
>
> > On Fri, Dec 07, 2007 at 12:28:20PM -0600, Kumar Gala wrote:
> >> From: Stuart Hughes <stuarth@freescale.com>
> >>
> >> This patch allows you to build the DTC source without making the
> >> tests directory. This is necessary when cross compiling as the
> >> dumptest (and other) files cannot be run/used on the host system.
> >> To use this use: 'make TESTS='
> >
> > I think this is a silly way of doing this. Instead create a new
> > target which builds everything but the tests.
> >
> > Say,
> >
> > all: cross tests
> >
> > cross: dtc ftdump libfdt
>
> shouldn't we do this the other way around, it seems odd to build the
> tests always or at least as part of the all target.
Hrm. Yeah, I guess so.
The idea was to encourage the tests to be used as much as possible,
but I guess there's not all that much value to building them without
running them.
Patch forthcoming.
--
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
* dtc: Don't build tests as part of "all"
From: David Gibson @ 2007-12-17 5:39 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
Currently "make all" for dtc will build (but not run) the testcase
binaries. This is a problem for cross compiles, because building the
tests will attempt to run the dumptrees utility on the host system,
which won't work if it's cross-compiled of course.
Although it would be possible to separately build host binaries,
there's not a lot of value in doing so since we don't have a facility
for cross-executing the testsuite anyway.
Therefore, remove the tests from the "all" target. It will still, of
course, be build as a prerequisite to "make check" which will run the
testsuite.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Index: dtc/Makefile
===================================================================
--- dtc.orig/Makefile 2007-12-17 16:34:48.000000000 +1100
+++ dtc/Makefile 2007-12-17 16:34:57.000000000 +1100
@@ -46,7 +46,7 @@ else
DEPTARGETS = $(filter-out $(NODEPTARGETS),$(MAKECMDGOALS))
endif
-all: dtc ftdump libfdt tests
+all: dtc ftdump libfdt
install: all
@$(VECHO) INSTALL
--
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: [PATCH 2/3] arch/ : Platform changes for UCC TDM driver for MPC8323ERDB.Also includes related QE changes.
From: Poonam Aggrwal @ 2007-12-17 5:40 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, Poonam_Aggrwal-b10812
In-Reply-To: <475D89E1.4040107@freescale.com>
[-- Attachment #1: Type: text/plain, Size: 1296 bytes --]
Thanx Tabi for your comments.
Sorry I was on leave for the last week, so could not reply in time.
Shall make the changes you suggested and repost the patch.
Regards
Poonam
On 12/11/07, Timur Tabi <timur@freescale.com> wrote:
>
> Poonam_Aggrwal-b10812 wrote:
>
> > + qe = of_find_node_by_type(NULL, "qe");
> > + if (qe) {
> > + unsigned int size;
> > + prop = of_get_property
> > + (qe, "brg-frequency",
> &size);
> > + of_node_put(qe);
> > + of_node_put(brg);
> > + return *prop;
> > + }
>
> Only very recent versions of U-Boot set the brg-frequency property, so you
> need
> to check for situations where "*prop" is 0. If it is, then you need to
> take the
> QE's bus-frequency property and divide it by two. See my ucc_uart driver
> for an
> example.
>
> And PowerPC-specific patches should not be cross-posted to linux-kernel.
>
> --
> Timur Tabi
> Linux kernel developer at Freescale
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
[-- Attachment #2: Type: text/html, Size: 3099 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] wrapper: Treat NULL as root node in devp_offset; add devp_offset_find().
From: David Gibson @ 2007-12-17 5:43 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, paulus
In-Reply-To: <20071211212305.GB3661@loki.buserror.net>
On Tue, Dec 11, 2007 at 03:23:05PM -0600, Scott Wood wrote:
> Many operations, as currently used in the wrapper, assume they can
> pass NULL and have it be treated as the root node. However, libfdt-wrapper
> converts NULL to -1, which is only appropriate when searching for nodes,
> and will cause an error otherwise.
Hrm. AFAICT "many" in this case, means three (being calls to
create_node() in devtree.c, main.c and planetcore.c).
Still I guess this patch is ok for now. I futgure I'd like to shrink
the wrapper down and make the general interface be as close as
possible to the native libfdt interface.
> Signed-off-by: Scott Wood <scottwood@freescale.com>
Acked-by: David Gibson <david@gibson.dropbear.id.au>
--
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: [PATCH 2/3] arch/ : Platform changes for UCC TDM driver for MPC8323ERDB.Also includes related QE changes.
From: Aggrwal Poonam @ 2007-12-17 5:54 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Barkowski Michael, netdev, Gala Kumar, linux-kernel, rubini,
linuxppc-dev, Kalra Ashish, Cutler Richard
In-Reply-To: <20071211111855.dc5276a2.sfr@canb.auug.org.au>
Thanks Stephen for your comments.
I have gone through them.
Shall incorporate them and repost the patch.
Sorry for late reply as I was on leave for the last week.=20
With Regards
Poonam=20
=20
=20
-----Original Message-----
From: Stephen Rothwell [mailto:sfr@canb.auug.org.au]=20
Sent: Tuesday, December 11, 2007 5:49 AM
To: Aggrwal Poonam
Cc: rubini@vision.unipv.it; linux-kernel@vger.kernel.org;
netdev@vger.kernel.org; Gala Kumar; linuxppc-dev@ozlabs.org; Barkowski
Michael; Cutler Richard; Kalra Ashish
Subject: Re: [PATCH 2/3] arch/ : Platform changes for UCC TDM driver for
MPC8323ERDB.Also includes related QE changes.
On Mon, 10 Dec 2007 17:39:22 +0530 (IST) Poonam_Aggrwal-b10812
<b10812@freescale.com> wrote:
>
> +++ b/arch/powerpc/sysdev/qe_lib/qe.c
> @@ -149,22 +149,116 @@ EXPORT_SYMBOL(qe_issue_cmd);
> */
> static unsigned int brg_clk =3D 0;
> =20
> -unsigned int get_brg_clk(void)
> +u32 get_brg_clk(enum qe_clock brgclk, enum qe_clock *brg_source)
> {
> - struct device_node *qe;
> - if (brg_clk)
> - return brg_clk;
> + struct device_node *qe, *brg, *clocks;
> + enum qe_clock brg_src;
> + u32 brg_input_freq =3D 0;
> + u32 brg_num;
> + const unsigned int *prop;
> =20
> - qe =3D of_find_node_by_type(NULL, "qe");
> - if (qe) {
> + *brg_source =3D 0;
> +
> + brg_num =3D brgclk - QE_BRG1;
> + brg =3D of_find_compatible_node(NULL, NULL, "fsl,cpm-brg");
> + if (brg) {
> unsigned int size;
> - const u32 *prop =3D of_get_property(qe, "brg-frequency",
&size);
> - brg_clk =3D *prop;
> - of_node_put(qe);
> - };
> + prop =3D of_get_property(brg,
> + "fsl,brg-sources", &size);
> +
> + brg_src =3D *(prop + brg_num);
You should probably sanity check that prop is not NULL and points to
something large enough.
You don't use brg after here, so the "of_node_put(brg)" could go here to
save putting it in multiple places later. Also, currently there are
paths through the following code that do not do the of_node_put(brg).
> + if (brg_src =3D=3D 0) {
> + *brg_source =3D 0;
> + if (brg_clk > 0) {
> + of_node_put(brg);
> + return brg_clk;
> + }
> + qe =3D of_find_node_by_type(NULL, "qe");
> + if (qe) {
> + unsigned int size;
> + prop =3D of_get_property
> + (qe, "brg-frequency",
&size);
> + of_node_put(qe);
> + of_node_put(brg);
> + return *prop;
NULL check here (yes, I know that the old code didn't check).
> + }
> + } else {
> + *brg_source =3D brg_src + QE_CLK1 - 1;
> + clocks =3D of_find_compatible_node(NULL, NULL,
> +
"fsl,cpm-clocks");
> + prop =3D of_get_property(clocks,
> + "#clock-cells", &size);
> + /*
> + * clock-cells =3D 1 only supported right now.
> + */
> + if (*prop !=3D 1)
Again check for NULL (and possibly size).
> + return 0;
> + prop =3D of_get_property(clocks,
> + "clock-frequency",
&size);
> +
> + brg_input_freq =3D *(prop+(brg_src - 1));
And again.
> + of_node_put(clocks);
> + of_node_put(brg);
> + return brg_input_freq;
> + }
> + }
> return brg_clk;
> }
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
^ permalink raw reply
* Please pull powerpc.git merge branch
From: Paul Mackerras @ 2007-12-17 6:00 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 some bugfixes and defconfig updates for powerpc.
Thanks,
Paul.
arch/powerpc/configs/mpc8272_ads_defconfig | 6 +++---
arch/powerpc/configs/pq2fads_defconfig | 6 +++---
arch/powerpc/configs/ps3_defconfig | 2 +-
arch/powerpc/kernel/ppc_ksyms.c | 12 ------------
arch/powerpc/math-emu/op-2.h | 3 ++-
arch/powerpc/platforms/iseries/lpevents.c | 17 +++++++++++++++--
arch/powerpc/platforms/ps3/Kconfig | 2 +-
arch/powerpc/sysdev/cpm2_common.c | 3 +--
drivers/net/fs_enet/mac-scc.c | 2 +-
include/asm-powerpc/commproc.h | 3 ---
10 files changed, 27 insertions(+), 29 deletions(-)
Jochen Friedrich (2):
[POWERPC] Fix typo #ifdef -> #ifndef
[POWERPC] Kill non-existent symbols from ksyms and commproc.h
Liu Yu (1):
[POWERPC] Fix rounding bug in emulation for double float operating
Michael Ellerman (1):
[POWERPC] Make PS3_SYS_MANAGER default y, not m
Scott Wood (2):
[POWRPC] CPM2: Eliminate section mismatch warning in cpm2_reset().
[POWERPC] 82xx: mpc8272ads, pq2fads: Update defconfig with CONFIG_FS_ENET_MDIO_FCC
Stephen Rothwell (1):
[POWERPC] iSeries: don't printk with HV spinlock held
^ permalink raw reply
* RE: Device Tree updates for xilinx.
From: Stephen Neuendorffer @ 2007-12-17 6:04 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev, Michal Simek, git
In-Reply-To: <20071217052101.GC3477@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 2066 bytes --]
Thanks, I've updated the generator to reflect this.
Steve
-----Original Message-----
From: David Gibson [mailto:david@gibson.dropbear.id.au]
Sent: Sun 12/16/2007 9:21 PM
To: Stephen Neuendorffer
Cc: linuxppc-dev@ozlabs.org; Michal Simek; git
Subject: Re: Device Tree updates for xilinx.
On Sun, Dec 16, 2007 at 08:58:18PM -0800, Stephen Neuendorffer wrote:
>
> Since there don't seem to be any examples of this in the tree: do
> you have a format preference? For the rest of the compatible lists,
> I'm using something like: xlnx,ipname-version. So for the
> microblaze, I'd prefer something like:
>
> xlnx,microblaze-6.00.b
Sounds reasonable.
> For the powerpc, either ibm,ppc405 or ibm.ppc-405 would seem to be
> more in character than PowerPC,405.
Well, we could list both forms, but PowerPC,405 should be included
since it's an established name. There's some history behind this:
before the generic names convention, the node name was used to encode
the most specific register interface for the device, and "compatible"
was used to describe any other interfaces it was also compatible with.
With the generic names convention, the name came to represent the
general type of device, and "compatible" alone was used to describe
the programming interface(s). In Apple and IBM device trees, while
most things reflect the generic names convention, it seems the cpu
nodes were left using the old convention - which is why that approach
was copied and is currently used in all the dts files. So when
converting nodes to the generic names convention, the old content of
the node name should go into "compatible" verbatim as the first entry.
In practice of course, I don't think anything looks at either the name
or the compatible property for cpu nodes (nor do I think they should)
- they'll just use the PVR.
--
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
[-- Attachment #2: Type: text/html, Size: 3105 bytes --]
^ permalink raw reply
* [PATCH] Implement pci_set_dma_mask() in terms of the dma_ops
From: Michael Ellerman @ 2007-12-17 6:35 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
Powerpc currently doesn't implement pci_set_dma_mask(), which means drivers
calling it will get the generic version in drivers/pci/pci.c.
The Powerpc dma mapping ops include a dma_set_mask() hook, which luckily is
not implemented by anyone - so there is no bug in the fact that the hook
is currently never called.
However in future we'll add implementation(s) of dma_set_mask(), and so we
need pci_set_dma_mask() to call the hook.
To save adding a hook to the dma mapping ops, pci-set_consistent_dma_mask()
simply calls the dma_set_mask() hook and then copies the new mask into
dev.coherenet_dma_mask.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/kernel/pci_64.c | 16 ++++++++++++++++
include/asm-powerpc/dma-mapping.h | 3 +++
2 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/kernel/pci_64.c b/arch/powerpc/kernel/pci_64.c
index bf06926..f5c4628 100644
--- a/arch/powerpc/kernel/pci_64.c
+++ b/arch/powerpc/kernel/pci_64.c
@@ -69,6 +69,22 @@ struct dma_mapping_ops *get_pci_dma_ops(void)
}
EXPORT_SYMBOL(get_pci_dma_ops);
+
+int pci_set_dma_mask(struct pci_dev *dev, u64 mask)
+{
+ return dma_set_mask(&dev->dev, mask);
+}
+
+int pci_set_consistent_dma_mask(struct pci_dev *dev, u64 mask)
+{
+ int rc;
+
+ rc = dma_set_mask(&dev->dev, mask);
+ dev->dev.coherent_dma_mask = dev->dma_mask;
+
+ return rc;
+}
+
static void fixup_broken_pcnet32(struct pci_dev* dev)
{
if ((dev->class>>8 == PCI_CLASS_NETWORK_ETHERNET)) {
diff --git a/include/asm-powerpc/dma-mapping.h b/include/asm-powerpc/dma-mapping.h
index ff52013..e974876 100644
--- a/include/asm-powerpc/dma-mapping.h
+++ b/include/asm-powerpc/dma-mapping.h
@@ -87,6 +87,9 @@ static inline int dma_supported(struct device *dev, u64 mask)
return dma_ops->dma_supported(dev, mask);
}
+/* We have our own implementation of pci_set_dma_mask() */
+#define HAVE_ARCH_PCI_SET_DMA_MASK
+
static inline int dma_set_mask(struct device *dev, u64 dma_mask)
{
struct dma_mapping_ops *dma_ops = get_dma_ops(dev);
--
1.5.2.rc1.1884.g59b20
^ permalink raw reply related
* RE: USB configuration
From: Pedro Luis D. L. @ 2007-12-17 8:29 UTC (permalink / raw)
To: Misbah khan, linuxppc-embedded
In-Reply-To: <14370084.post@talk.nabble.com>
MIsbah wrote:
> I have configured for mass storage device still i am not getting the debu=
g
> msg that the kernel has detected the pen drive (after i connect the pen
> drive ).
>=20
> " Initializing USB Mass Storage driver...
> usbcore: registered new driver usb-storage
> USB Mass Storage support registered.=20
> "
As long as you enabled the USB Mass storage and all usb-related modules, if=
you don't get any output, maybe the usb hardware is not working properly. =
I don't work with that board, so I feel like I can not help further more, s=
orry.
Hope you find a solution!
Regards,
Pedro L.
> ----misbah=20
>=20
>=20
> Pedro Luis D. L. wrote:
>>=20
>>=20
>>> From: misbah_khan@engineer.com
>>> To: linuxppc-embedded@ozlabs.org
>>> Subject: RE: USB configuration
>>>=20
>>>=20
>>> I have inserted a USB card reader, and the following dmesg it shows ...=
..
>>>=20
>>> -----------------------------------------------------------------------=
--------
>>> mpc8272ads: Init
>>> PCI: Probing PCI hardware
>>> PCI: Cannot allocate resource region 0 of device 0000:00:00.0
>>> PCI: Cannot allocate resource region 1 of device 0000:00:00.0
>>> SCSI subsystem initialized
>>> Linux Kernel Card Services
>>> options: [pci] [cardbus]
>>> usbcore: registered new driver usbfs
>>> usbcore: registered new driver hub
>>> Serial: CPM driver $Revision: 0.01 $
>>> ttyCPM0 at MMIO 0xf0011a00 (irq =3D 40) is a CPM UART
>>> ttyCPM1 at MMIO 0xf0011a60 (irq =3D 43) is a CPM UART
>>> io scheduler noop registered
>>> io scheduler anticipatory registered
>>> io scheduler deadline registered
>>> io scheduler cfq registered
>>> loop: loaded (max 8 devices)
>>> fs_enet.c:v1.0 (Aug 8, 2005)
>>> fs_enet: eth0 Phy @ 0x0, type DM9161 (0x0181b881)
>>> fs_enet: eth1 Phy @ 0x3, type DM9161 (0x0181b881)
>>> Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
>>> ide: Assuming 33MHz system bus speed for PIO modes; override with
>>> idebus=3Dxx
>>> st: Version 20041025, fixed bufsize 32768, s/g segs 256
>>> osst :I: Tape driver with OnStream support version 0.99.1
>>> osst :I: $Id: osst.c,v 1.70 2003/12/23 14:22:12 wriede Exp $
>>> ohci_hcd: 2004 Nov 08 USB 1.1 'Open' Host Controller (OHCI) Driver (PCI=
)
>>> ohci_hcd: block sizes: ed 64 td 64
>>> drivers/usb/serial/usb-serial.c: USB Serial support registered for
>>> Generic
>>> usbcore: registered new driver usbserial_generic
>>> usbcore: registered new driver usbserial
>>> drivers/usb/serial/usb-serial.c: USB Serial Driver core v2.0
>>> NET: Registered protocol family 2
>>> IP: routing cache hash table of 512 buckets, 4Kbytes
>>> TCP: Hash tables configured (established 4096 bind 8192)
>>> NET: Registered protocol family 1
>>> NET: Registered protocol family 17
>>> IP-Config: Complete:
>>> device=3Deth1, addr=3D192.168.33.136, mask=3D255.255.248.0,
>>> gw=3D192.168.32.47,
>>> host=3Dcashel, domain=3D, nis-domain=3D(none),
>>> bootserver=3D192.168.33.96, rootserver=3D192.168.33.96, rootpath=
=3D
>>> Looking up port of RPC 100003/2 on 192.168.33.96
>>> Looking up port of RPC 100005/1 on 192.168.33.96
>>> VFS: Mounted root (nfs filesystem).
>>> Freeing unused kernel memory: 104k init
>>> -----------------------------------------------------------------------=
---------------
>>>=20
>>=20
>> It looks like it is well configured, because the usbfs and hub are loade=
d.
>> You could check in your kernel configuration that you enabled USB Mass
>> storage driver and attached a pen drive as I suggested before.
>> Another possibility is to insert a card in the USB card reader. Then you
>> should be able to see with dmesg if it is recognized.
>>=20
>> Pedro.
>>=20
>>> This doesent gives me the clear explaination of whether USB is working
>>> properly....
>>>=20
>>> I would appreciate if you could share with me the basic steps to be
>>> followed
>>> to confirm that the USB support that i had configured is being tested i=
n
>>> all
>>> aspects.
>>>=20
>>> Misbah
>>>=20
>>> Pedro Luis D. L. wrote:
>>>>=20
>>>>=20
>>>>=20
>>>>> Date: Thu, 6 Dec 2007 05:27:14 -0800
>>>>> From: misbah_khan@engineer.com
>>>>> To: linuxppc-embedded@ozlabs.org
>>>>> Subject: USB configuration
>>>>>=20
>>>>>=20
>>>>> HI all ...
>>>>=20
>>>> Hi,
>>>>=20
>>>>> I have configured the Montavista Kernel for USB support and for
>>>>> PPC8272-ADS
>>>>> board I need to know that how could i test that my USB is working ???=
?
>>>>>=20
>>>>=20
>>>> Try to attach an USB device, like a pendrive, to an USB port. Then
>>>> type:=20
>>>> dmesg | tail
>>>>=20
>>>> If the USB support is working properly, you should see some output
>>>> saying
>>>> which device have you attached and where is it mapped.
>>>> If you plug a memory stick, you can try to mount it and check that the
>>>> filesystem is correct.
>>>>=20
>>>> Pedro.
>>>>=20
>>>>> Its creating the directory :- /proc/bus/usb/ but doesent contain any
>>>>> file
>>>>> under it ????
>>>>>=20
>>>>>=20
>>>>> its also creating the directory :- /sys/bus/usb/ but doesent contai=
n
>>>>> any
>>>>> file under it ????
>>>>>=20
>>>>>=20
>>>>> Please let me know the procedure to test whether my USB configuration
>>>>> is
>>>>> all
>>>>> right ????
>>>>>=20
>>>>> Thank u=20
>>>>> Misbah <><
>>>>> --=20
>>>>> View this message in context:
>>>>> http://www.nabble.com/USB-configuration-tf4956061.html#a14192347
>>>>> Sent from the linuxppc-embedded mailing list archive at Nabble.com.
>>>>>=20
>>>>> _______________________________________________
>>>>> Linuxppc-embedded mailing list
>>>>> Linuxppc-embedded@ozlabs.org
>>>>> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>>>>=20
>>>> _________________________________________________________________
>>>> Tecnolog=EDa, moda, motor, viajes,=85suscr=EDbete a nuestros boletines=
para
>>>> estar a la =FAltima
>>>> http://newsletters.msn.com/hm/maintenanceeses.asp?L=3DES&C=3DES&P=3DWC=
Maintenance&Brand=3DWL&RU=3Dhttp%3a%2f%2fmail.live.com
>>>> _______________________________________________
>>>> Linuxppc-embedded mailing list
>>>> Linuxppc-embedded@ozlabs.org
>>>> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>>>>=20
>>>>=20
>>>=20
>>> --=20
>>> View this message in context:
>>> http://www.nabble.com/USB-configuration-tf4956061.html#a14206951
>>> Sent from the linuxppc-embedded mailing list archive at Nabble.com.
>>>=20
>>> _______________________________________________
>>> Linuxppc-embedded mailing list
>>> Linuxppc-embedded@ozlabs.org
>>> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>>=20
>> _________________________________________________________________
>> MSN Video.=20
>> http://video.msn.com/?mkt=3Des-es
>> _______________________________________________
>> Linuxppc-embedded mailing list
>> Linuxppc-embedded@ozlabs.org
>> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>>=20
>>=20
>=20
> --=20
> View this message in context: http://www.nabble.com/USB-configuration-tp1=
4192347p14370084.html
> Sent from the linuxppc-embedded mailing list archive at Nabble.com.
>=20
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
_________________________________________________________________
MSN Video.=20
http://video.msn.com/?mkt=3Des-es=
^ permalink raw reply
* Re: [PATCH] OProfile: remove dependency on spufs module
From: Jeremy Kerr @ 2007-12-17 9:23 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, Paul Mackerras, David Woodhouse, Bob Nelson
In-Reply-To: <200712141527.31893.arnd@arndb.de>
> Jeremy, please ack the spufs changes if you are ok with the patch.
Yep, fine by me.
Acked-by: Jeremy Kerr <jk@ozlabs.org>
Cheers,
Jeremy
^ permalink raw reply
* Re: [PATCH] Implement pci_set_dma_mask() in terms of the dma_ops
From: Christoph Hellwig @ 2007-12-17 10:02 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <a3b033f72681dd15badb0218b505512ce1c3a9c8.1197873226.git.michael@ellerman.id.au>
On Mon, Dec 17, 2007 at 05:35:53PM +1100, Michael Ellerman wrote:
> To save adding a hook to the dma mapping ops, pci-set_consistent_dma_mask()
> simply calls the dma_set_mask() hook and then copies the new mask into
> dev.coherenet_dma_mask.
How is this supposed to work? There are various devices around that
want different mask for coherent vs streaming dma mappings, and we need
to tell the iommu that we're setting it for either the former or the
latter.
^ permalink raw reply
* [PATCH] [NET][POWERPC] ucc_geth: really fix section mismatch
From: Anton Vorontsov @ 2007-12-17 11:54 UTC (permalink / raw)
To: Jeff Garzik; +Cc: netdev, Li Yang, linuxppc-dev
Commit ed7e63a51d46e835422d89c687b8a3e419a4212a has tried to fix
section mismatch:
WARNING: vmlinux.o(.init.text+0x17278): Section mismatch: reference to
.exit.text:uec_mdio_exit (between 'ucc_geth_init' and 'uec_mdio_init')
But that mismatch still happens.
This patch actually fixing section mismatch by removing __exit from
the header file.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
drivers/net/ucc_geth_mii.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ucc_geth_mii.h b/drivers/net/ucc_geth_mii.h
index d834370..1e45b20 100644
--- a/drivers/net/ucc_geth_mii.h
+++ b/drivers/net/ucc_geth_mii.h
@@ -96,5 +96,5 @@ enum enet_tbi_mii_reg {
int uec_mdio_read(struct mii_bus *bus, int mii_id, int regnum);
int uec_mdio_write(struct mii_bus *bus, int mii_id, int regnum, u16 value);
int __init uec_mdio_init(void);
-void __exit uec_mdio_exit(void);
+void uec_mdio_exit(void);
#endif /* __UEC_MII_H */
--
1.5.2.2
^ permalink raw reply related
* Re: [PATCH 7/7] [POWERPC] Xilinx: Update booting-without-of.
From: Peter Korsgaard @ 2007-12-17 11:57 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, simekm2
In-Reply-To: <fa686aa40712162030q6f0e6d87j5e6e5379cbd0d54e@mail.gmail.com>
>>>>> "Grant" == Grant Likely <grant.likely@secretlab.ca> writes:
Hi,
>> > 3) Uartlite requires a port-number property for the console to work.
>>
>> Why? In general we try to avoid magical sequence numbers - cell-index
>> should *only* be used when it's needed to index or program some shared
>> register.
Grant> Aliases is probably the correct construct for this.
Grant> port-number was a bad idea and I never should have gone that
Grant> direction.
Perhaps it would make more sense to add a _find_match_or_unused(port)
like 8250.c and make the initialization order define the index instead
of explicitly setting it?
Now we're at it - Why isn't the uartlite of glue handled by of_serial.c?
--
Bye, Peter Korsgaard
^ permalink raw reply
* Re: [PATCH] [POWERPC] 4xx: Add aliases node to 4xx dts files
From: Jon Loeliger @ 2007-12-17 13:46 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev, Stefan Roese
In-Reply-To: <20071216223342.GD26307@localhost.localdomain>
So, like, the other day David Gibson mumbled:
> On Sun, Dec 16, 2007 at 07:10:02PM +0100, Segher Boessenkool wrote:
> >
> > Hopefully some version that stores path strings in the properties
> > in /aliases, and not phandles.
Yes.
> > Or does that current version of DTC
> > do that correctly already, and just has an inconvenient source
> > syntax?
Feh. If there is an "inconvenient source syntax", or any other
annoying irregularity, please, by all means, suggest improvements
and offer patches!
> I don't think anyone's actually gone and generated phandles in
> /aliases, although it was suggested early on. The syntax is
> foo = < &bar >;
> to generate a phandle and
> foo = &bar;
> to generate a path.
>
> I was a bit worried about confusion between these forms, but at least
> Kumar and myself came up with this syntax independently, which
> suggests it's not too surprising to most people, and no-one had any
> other suggestions.
To be a bit more complete, Kumar and I discussed this as well.
jdl
^ permalink raw reply
* Various DTC Patches Applied
From: Jon Loeliger @ 2007-12-17 13:53 UTC (permalink / raw)
To: linuxppc-dev
Folks,
Tese patches have all been applied to the DTC repo and pushed out:
* [master] dtc: Don't build tests as part of "all"
* [master^] libfdt: Add more documentation (patch the seventh)
* [master~2] libfdt: Add more documentation (patch the sixth)
* [master~3] dtc: Fix silly typo in dtc-checkfails.sh
* [master~4] dtc: Allow gcc format warnings for check_msg()
* [master~5] dtc: Make dtc-checfails.sh script catch deaths-by-signal
* [master~6] dtc: Reinstate full old-style reference-to-path for v0 dts files
* [master~7] dtc: Convert check for obsolete /chosen property
* [master~8] dtc: Convert #address-cells and #size-cells related checks
Thanks,
jdl
^ permalink raw reply
* Re: [PATCH 7/7] [POWERPC] Xilinx: Update booting-without-of.
From: Grant Likely @ 2007-12-17 15:19 UTC (permalink / raw)
To: Stephen Neuendorffer; +Cc: linuxppc-dev, David Gibson, simekm2
In-Reply-To: <20071213234151.D0B3DE80061@mail20-sin.bigfish.com>
On 12/13/07, Stephen Neuendorffer <stephen.neuendorffer@xilinx.com> wrote:
> This now better describes what the UBoot device tree generator actually does. In particular:
>
> 1) Nodes have a label derived from the device name, and a node name
> derived from the device type.
> 2) Usage of compound nodes (representing more than one device in the same IP) which actually works. This requires having a valid compatible node, and all the other things that a bus normally has. I've chosen 'xlnx,compound' as the bus name to describe these compound nodes.
> 3) Uartlite requires a port-number property for the console to work.
>
> In addition, I've clarified some of the language relating to how mhs
> nodes should be represent in the device tree.
Thanks for the updates. Comments below.
> ---
> Documentation/powerpc/booting-without-of.txt | 61 +++++++++++++++-----------
> 1 files changed, 36 insertions(+), 25 deletions(-)
>
> diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt
> index e9a3cb1..5e2b85a 100644
> --- a/Documentation/powerpc/booting-without-of.txt
> +++ b/Documentation/powerpc/booting-without-of.txt
> @@ -2276,7 +2276,7 @@ platforms are moved over to use the flattened-device-tree model.
> properties of the device node. In general, device nodes for IP-cores
> will take the following form:
>
> - (name)@(base-address) {
> + (name): (ip-core-name)@(base-address) {
(name): (generic-name)@(base-address) {
> compatible = "xlnx,(ip-core-name)-(HW_VER)"
> [, (list of compatible devices), ...];
> reg = <(baseaddr) (size)>;
> @@ -2294,9 +2294,9 @@ platforms are moved over to use the flattened-device-tree model.
> dropped from the parameter name, the name is converted
> to lowercase and all underscore '_' characters are
> converted to dashes '-'.
> - (baseaddr): the C_BASEADDR parameter.
> + (baseaddr): the baseaddr parameter value (often named C_BASEADDR).
> (HW_VER): from the HW_VER parameter.
> - (size): equals C_HIGHADDR - C_BASEADDR + 1
> + (size): the address range size (often C_HIGHADDR - C_BASEADDR + 1).
Ah, yes. Good clarification.
>
> Typically, the compatible list will include the exact IP core version
> followed by an older IP core version which implements the same
> @@ -2326,12 +2326,13 @@ platforms are moved over to use the flattened-device-tree model.
>
> becomes the following device tree node:
>
> - opb-uartlite-0@ec100000 {
> + opb_uartlite_0: serial@ec100000 {
> device_type = "serial";
> compatible = "xlnx,opb-uartlite-1.00.b";
> reg = <ec100000 10000>;
> - interrupt-parent = <&opb-intc>;
> + interrupt-parent = <&opb_intc_0>;
> interrupts = <1 0>; // got this from the opb_intc parameters
> + port-number = <0>;
> current-speed = <d#115200>; // standard serial device prop
> clock-frequency = <d#50000000>; // standard serial device prop
> xlnx,data-bits = <8>;
> @@ -2339,16 +2340,19 @@ platforms are moved over to use the flattened-device-tree model.
> xlnx,use-parity = <0>;
> };
>
> - Some IP cores actually implement 2 or more logical devices. In this case,
> - the device should still describe the whole IP core with a single node
> - and add a child node for each logical device. The ranges property can
> - be used to translate from parent IP-core to the registers of each device.
> - (Note: this makes the assumption that both logical devices have the same
> - bus binding. If this is not true, then separate nodes should be used for
> - each logical device). The 'cell-index' property can be used to enumerate
> - logical devices within an IP core. For example, the following is the
> - system.mhs entry for the dual ps2 controller found on the ml403 reference
> - design.
> + Some IP cores actually implement 2 or more logical devices. In
> + this case, the device should still describe the whole IP core with
> + a single node and add a child node for each logical device. The
> + ranges property can be used to translate from parent IP-core to the
> + registers of each device. In addition, the parent node should be
> + compatible with the bus type 'xlnx,compound', and should contain
> + #address-cells and #size-cells, as with any other bus. (Note: this
> + makes the assumption that both logical devices have the same bus
> + binding. If this is not true, then separate nodes should be used
> + for each logical device). The 'cell-index' property can be used to
> + enumerate logical devices within an IP core. For example, the
> + following is the system.mhs entry for the dual ps2 controller found
> + on the ml403 reference design.
>
> BEGIN opb_ps2_dual_ref
> PARAMETER INSTANCE = opb_ps2_dual_ref_0
> @@ -2370,21 +2374,24 @@ platforms are moved over to use the flattened-device-tree model.
>
> It would result in the following device tree nodes:
>
> - opb_ps2_dual_ref_0@a9000000 {
> + opb_ps2_dual_ref_0: opb-ps2-dual-ref@a9000000 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "xlnx,compound";
> ranges = <0 a9000000 2000>;
> // If this device had extra parameters, then they would
> // go here.
> - ps2@0 {
> + opb-ps2-dual-ref@0 {
According to the generic names recommendation, this should be either
"keyboard@0" or "mouse@0", but of course the two interfaces are
identical and EDK doesn't have any information about how they are
used. Perhaps the node name should be: "ps2@0". David, thoughts?
> compatible = "xlnx,opb-ps2-dual-ref-1.00.a";
> reg = <0 40>;
> - interrupt-parent = <&opb-intc>;
> + interrupt-parent = <&opb_intc_0>;
> interrupts = <3 0>;
> cell-index = <0>;
> };
> - ps2@1000 {
> + opb-ps2-dual-ref@1000 {
> compatible = "xlnx,opb-ps2-dual-ref-1.00.a";
> reg = <1000 40>;
> - interrupt-parent = <&opb-intc>;
> + interrupt-parent = <&opb_intc_0>;
> interrupts = <3 0>;
> cell-index = <0>;
> };
> @@ -2447,17 +2454,18 @@ platforms are moved over to use the flattened-device-tree model.
>
> Gives this device tree (some properties removed for clarity):
>
> - plb-v34-0 {
> + plb_v34 {
Steve, when I wrote this I was lazy and I didn't add the bus address.
However, if we don't have the base address I think we'll end up with
name collisions (especially in the MPMC case). So, based on generic
names convention, this should probably simply be "plb@<baseaddr>".
> #address-cells = <1>;
> #size-cells = <1>;
> + compatible = "xlnx,plb-v34-1.02.a";
> device_type = "ibm,plb";
> ranges; // 1:1 translation
>
> - plb-bram-if-cntrl-0@ffff0000 {
> + plb_bram_if_cntrl_0: plb-bram-if-cntrl@ffff0000 {
Node name should probably just be "bram@ffff0000" here.
> reg = <ffff0000 10000>;
> }
>
> - opb-v20-0 {
> + opb_v20 {
opb@<baseaddr>
> #address-cells = <1>;
> #size-cells = <1>;
> ranges = <20000000 20000000 20000000
> @@ -2465,11 +2473,11 @@ platforms are moved over to use the flattened-device-tree model.
> 80000000 80000000 40000000
> c0000000 c0000000 20000000>;
>
> - opb-uart16550-0@a0000000 {
> + opb_uart16550_0: opb-uart16550@a0000000 {
serial@a0000000
> reg = <a00000000 2000>;
> };
>
> - opb-intc-0@d1000fc0 {
> + opb_intc_0: opb-intc@d1000fc0 {
interrupt-controller@d1000fc0
> reg = <d1000fc0 20>;
> };
> };
> @@ -2513,6 +2521,9 @@ platforms are moved over to use the flattened-device-tree model.
>
> Requred properties:
> - current-speed : Baud rate of uartlite
> + Optional properties:
> + - port-number : unique ordinal index of the device. This
> + property is required for a console on uartlite.
And has already been discussed, drop the port-number property. I'll
rework the uartlite driver to use aliases instead.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH v2 2/3] mpc82xx: Embedded Planet EP8248E support
From: Scott Wood @ 2007-12-17 15:18 UTC (permalink / raw)
To: Scott Wood, galak, linuxppc-dev
In-Reply-To: <20071217035912.GB3262@localhost.localdomain>
David Gibson wrote:
> As I think I said about another tree, this mdio-under-bcsr arrangement
> is pretty strange. What's going on here.
As I answered then, it's just the way the hardware is. I didn't design
it. :-P
>> + soc@f0000000 {
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + device_type = "soc";
>
> Ditch the device_type.
No, it's used by the bootwrapper. I'll get rid of it if you want to
write a find_node_by_compatible() function. :-)
-Scott
^ permalink raw reply
* Re: USB configuration
From: Scott Wood @ 2007-12-17 15:21 UTC (permalink / raw)
To: Misbah khan; +Cc: linuxppc-embedded
In-Reply-To: <14370084.post@talk.nabble.com>
Misbah khan wrote:
> I have configured for mass storage device still i am not getting the debug
> msg that the kernel has detected the pen drive (after i connect the pen
> drive ).
>
> " Initializing USB Mass Storage driver...
> usbcore: registered new driver usb-storage
> USB Mass Storage support registered.
> "
Did you get any output indicating that the USB controller was found and
initialized? This *is* a PCI-based OHCI controller you're trying to
use, and not the CPM USB, right? Do other PCI devices work?
-Scott
^ 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