* Re: [PATCH 1/2] [RFC][POWERPC] MPC8568E-MDS: create localbus node
From: Kumar Gala @ 2007-10-15 19:08 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20071015184743.GA4474@loki.buserror.net>
On Oct 15, 2007, at 1:47 PM, Scott Wood wrote:
> On Mon, Oct 15, 2007 at 07:57:30PM +0400, Anton Vorontsov wrote:
>> On Mon, Oct 15, 2007 at 07:42:12PM +0400, Sergei Shtylyov wrote:
>>> Is the entity described as "localbus" indeed so *board* specific?
>>
>> That's what booting-without-of.txt gives as an example.
>
> The board should have been left out of that. Your compatible
> should be
> something like "fsl,mpc8568-localbus", possibly with some canonical
> mpc85xx
> chip as well, chosen to represent 85xx localbus in general.
Lets be careful, there are at least two forms of localbus on 85xx.
- k
^ permalink raw reply
* Re: [PATCH 1/2] [RFC][POWERPC] MPC8568E-MDS: create localbus node
From: Scott Wood @ 2007-10-15 19:10 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <3387D0D7-EBB8-4346-853D-75850159BCE4@kernel.crashing.org>
Kumar Gala wrote:
>
> On Oct 15, 2007, at 1:47 PM, Scott Wood wrote:
>
>> On Mon, Oct 15, 2007 at 07:57:30PM +0400, Anton Vorontsov wrote:
>>> On Mon, Oct 15, 2007 at 07:42:12PM +0400, Sergei Shtylyov wrote:
>>>> Is the entity described as "localbus" indeed so *board* specific?
>>>
>>> That's what booting-without-of.txt gives as an example.
>>
>> The board should have been left out of that. Your compatible should be
>> something like "fsl,mpc8568-localbus", possibly with some canonical
>> mpc85xx
>> chip as well, chosen to represent 85xx localbus in general.
>
> Lets be careful, there are at least two forms of localbus on 85xx.
Do you mean LAWBAR v. BRn/ORn (the manuals refer to the latter as
"localbus", so I'd be inclined to stick with that name, and call the
former mpc8568-lawbar or something), or some 85xx being different than
others?
-Scott
^ permalink raw reply
* Re: [PATCH 2/2] i2c: Add devtree-aware iic support for PPC4xx
From: Eugene Surovegin @ 2007-10-15 19:11 UTC (permalink / raw)
To: Scott Wood; +Cc: Jean Delvare, Stefan Roese, i2c, linuxppc-dev
In-Reply-To: <20071015185340.GB4474@loki.buserror.net>
On Mon, Oct 15, 2007 at 01:53:40PM -0500, Scott Wood wrote:
> Though, I don't see what the problem with the original approach is, as long
> as the numbers are chosen in the same way when registering i2c clients based
> on the children of the adapter node. There's no concept in the hardware
> itself of a bus number.
Huh? As far as I can tell, there is. Also, I want messages from the
kernel mention something I can map to the real hw, e.g. fixed IIC
device index, not some random number.
This already works with the current OCP code, so if you want change
it to a "superior" technology, please, make sure it provides the same
functionality as trivial OCP one.
I find it rather puzzling that instead people are trying to make
this a non-issue as soon as it cannot be implemented easily with
their new and shiny infrastructure.
--
Eugene
^ permalink raw reply
* Re: [PATCH 2/2] i2c: Add devtree-aware iic support for PPC4xx
From: Grant Likely @ 2007-10-15 19:13 UTC (permalink / raw)
To: Scott Wood; +Cc: Jean Delvare, linuxppc-dev, Stefan Roese, i2c
In-Reply-To: <20071015185340.GB4474@loki.buserror.net>
On 10/15/07, Scott Wood <scottwood@freescale.com> wrote:
> On Mon, Oct 15, 2007 at 10:57:48AM -0600, Grant Likely wrote:
> > Segher is recommending that we use an aliases node as per the open
> > firmware example for this. I think in this case it would look
> > something like this (but I'm not the expert):
> >
> > aliases {
> > IIC0 = "/path/to/bus/iic@0x2000";
> > IIC1 = "/path/to/bus/iic@0x2000";
> > };
>
> I think this is overly complicated; something like linux,i2c-index in the
> i2c adapter node would be simpler.
But not perhaps better. Enumeration is a system-wide thing. It does
make sense to group all the device enumerations in one place. It
eliminates two nodes trying to enumerate to the same device number and
since device numbers are something that the user will potentially want
to modify, it separates enumeration from hardware description.
As per your point below; if all the i2c devices are children of the
adapter, then yes you are right that the bus number doesn't matter to
the user. But it *does* matter for things like serial and ethernet
ports.
>
> Though, I don't see what the problem with the original approach is, as long
> as the numbers are chosen in the same way when registering i2c clients based
> on the children of the adapter node. There's no concept in the hardware
> itself of a bus number.
Even if you take this approach, the driver still need to know what bus
number to use (as per the i2c infrastructure). It is not sane for an
i2c bus driver to attempt to assign the bus number itself because it
could conflict with another arbitrarily chosen bus number from another
driver.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH 2/2] i2c: Add devtree-aware iic support for PPC4xx
From: Grant Likely @ 2007-10-15 19:16 UTC (permalink / raw)
To: Eugene Surovegin; +Cc: Jean Delvare, Stefan Roese, i2c, linuxppc-dev
In-Reply-To: <20071015191118.GA9733@gate.ebshome.net>
On 10/15/07, Eugene Surovegin <ebs@ebshome.net> wrote:
> On Mon, Oct 15, 2007 at 01:53:40PM -0500, Scott Wood wrote:
> > Though, I don't see what the problem with the original approach is, as long
> > as the numbers are chosen in the same way when registering i2c clients based
> > on the children of the adapter node. There's no concept in the hardware
> > itself of a bus number.
>
> Huh? As far as I can tell, there is. Also, I want messages from the
> kernel mention something I can map to the real hw, e.g. fixed IIC
> device index, not some random number.
Yes, in the same way that there may be more than one on-chip serial or
ethernet controllers. However, it does not necessarily follow that
the *logical* bus number will match the way on chip devices are
numbered.
Example: Suppose you have a board with 2 chips which each include 2
i2c controllers. Each chip numbers them 1 & 2. So, which chip gets
1-2 and which one gets 3-4?
>
> This already works with the current OCP code, so if you want change
> it to a "superior" technology, please, make sure it provides the same
> functionality as trivial OCP one.
agreed
> I find it rather puzzling that instead people are trying to make
> this a non-issue as soon as it cannot be implemented easily with
> their new and shiny infrastructure.
No, it is a real problem; and not just for i2c. We need a solution for it.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* RE: Linux booting problem on Xilinx ppc
From: Koss, Mike (Mission Systems) @ 2007-10-15 19:17 UTC (permalink / raw)
To: aauer1, linuxppc-embedded
In-Reply-To: <13219154.post@talk.nabble.com>
In house we use the gcc 4.1.2, glibc 2.3.6 combo with success.
-- Mike
-----Original Message-----
From: aauer1 [mailto:aauer1@gmx.at]=20
Sent: Monday, October 15, 2007 2:47 PM
To: linuxppc-embedded@ozlabs.org
Subject: Re: Linux booting problem on Xilinx ppc
Hello
I'm also working with ML403 board from Xilinx and have the same problem
as you. The boot process stops after decompressing with the message "Now
booting the kernel". We also used gcc-4.1.0 for the cross compilation.
So, I would be glad to know, which gcc version have you used to get a
working kernel!
Thanks,
Andreas
Junqiang Hu wrote:
>=20
>=20
> Hi Grant,
>=20
> Thank you so much for the reply! Fortunately I got it work now --=20
> it's the crosstool compiler problem. Originally I was using=20
> gcc-4.1.0, yet when compiling kernel 2.6.22, I noticed that it says=20
> gcc-4.1.0 will miscompile the kernel, so I changed to another version,
> and now I can let it go!
>=20
> Right now still not fully booted because of the SystemACE problem,=20
> or maybe the partition is not correct. I'm still working on it,=20
> hopefully to get it solved soon :-)
>=20
> Thanks,
> -J.
>=20
>=20
> Grant Likely-2 wrote:
>>=20
>> On 9/15/07, Junqiang Hu <jqhu936@yahoo.com> wrote:
>>>
>>>
>>> Dear friends,
>>>
>>> I'm trying to run Linux in AvNet (Memec)=20
>>> Xilinx-XC2VP50-EVKT-FF1152 board. The Linux version I'm using is=20
>>> 2.4; the cross-compiler is gcc-4.1.0, glibc 2.3.6. When booting the
kernel, it shows:
>>> loaded at: 00400000 004B51E4
>>> board data at: 00000000 00000018
>>> relocated to: 0040526C 00405284
>>> zimage at: 00405B2B 004B177C
>>> avail ram: 004B6000 60000000
>>=20
>> I strongly recommend moving to a 2.6 kernel. Recent mainline has=20
>> support for the Xilinx ppc built in.
>>>
>>> Linux/PPC load: console=3DttyS0,9600=20
>>> root=3D/dev/xsysace/disc0/part3 rw
>>> Uncompressing Linux...done.
>>> Now booting the kernel
>>>
>>> Then it hangs. First it seems to me that the "avail ram" is not=20
>>> correct, since I configured only 32MB SDRAM. Moreover, if it's=20
>>> first powered on, the end address of "avail ram" would be FFD9FBED.=20
>>> Then I tried to investigate the problem using xmd. When launched,=20
>>> it says:
>>=20
>> (If you're using u-boot) You might have a mismatch between the board=20
>> info structure used by u-boot and the one used by Linux.
>>=20
>> Also, you should use your debugger to inspect the __log_buf memory of
>> the kernel. A common problem is the kernel starts booting, but the=20
>> console is setup incorrectly and so you see nothing. But, you can=20
>> read the console output directly from memory if you look at the=20
>> __log_buf region (find the address in the System.map file; you might=20
>> need to subtract 0xC0000000 from the address to view the memory)
>>=20
>> Cheers,
>> g.
>>=20
>> --
>> Grant Likely, B.Sc., P.Eng.
>> Secret Lab Technologies Ltd.
>> grant.likely@secretlab.ca
>> (403) 399-0195
>> _______________________________________________
>> 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/Linux-booting-problem-on-Xilinx-ppc-tf4449060.html
#a13219154
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH v3 0/4] FEC - fast ethernet controller for mpc52xx
From: Grant Likely @ 2007-10-15 19:19 UTC (permalink / raw)
To: Jeff Garzik; +Cc: linuxppc-dev, netdev, Domen Puncer
In-Reply-To: <4713BA1C.2050604@pobox.com>
On 10/15/07, Jeff Garzik <jgarzik@pobox.com> wrote:
> Domen Puncer wrote:
> > Hello!
> >
> > If there are no objections, I would like to get this merged
> > when bestcomm goes in (any time now?).
> >
> > It's split into four parts:
> > 1 - device tree
> > 2 - small bestcomm change
> > 3 - the actual driver
> > 4 - phy part of the driver
>
> patches #3 and #4 need to be combined together.
>
> Are the arch people OK with patches #1 and #2?
Yes, I'll be pushing both to Paulus shortly.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: Linux booting problem on Xilinx ppc
From: Grant Likely @ 2007-10-15 19:20 UTC (permalink / raw)
To: aauer1; +Cc: linuxppc-embedded
In-Reply-To: <13219154.post@talk.nabble.com>
On 10/15/07, aauer1 <aauer1@gmx.at> wrote:
>
> Hello
>
> I'm also working with ML403 board from Xilinx and have the same problem as
> you. The boot process stops after decompressing with the message "Now
> booting the kernel". We also used gcc-4.1.0 for the cross compilation. So, I
> would be glad to know, which gcc version have you used to get a working
> kernel!
First step:
Get a JTAG debugger and look at the __log_buf address.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH v2] Device tree bindings for Xilinx devices
From: Arnd Bergmann @ 2007-10-15 19:21 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20071015155223.7403.39615.stgit@trillian.cg.shawcable.net>
On Monday 15 October 2007, Grant Likely wrote:
> From: Grant Likely <grant.likely@secretlab.ca>
>
> Here's my second version of xilinx device tree bindings. Please review
> and comment. I'd like to push these out to Paulus in the next couple
> of days.
There are a few more properties that I can imagine you might need.
Not sure if it makes sense specifying them now, but here are my thoughts:
> More devices will be defined as this spec matures.
>
> + l) Xilinx ML300 Framebuffer
> +
> + Simple framebuffer device from the ML300 reference design (also on the
> + ML403 reference design as well as others).
> +
> + Required properties:
> + - compatible : Must include "xilinx,ml300-fb"
> + - reg : offset and length of the framebuffer register set
> +
> + Optional properties:
> + - resolution : <xres yres> pixel resolution of framebuffer. Some
> + implementations use a different resolution. Default
> + is <d#640 d#480>
> + - virt-resolution : <xvirt yvirt> Size of framebuffer in memory.
> + Default is <d#1024 d#480>.
> + - rotate-display (empty) : rotate display 180 degrees.
rotate-display could be defined as something that allows 0/90/180/270
degrees, as well as mirroring, not just 180 degree rotation.
> + o) Xilinx Uartlite
> +
> + Xilinx uartlite devices are simple fixed speed serial ports. Uartlite
> + ports should be described in a node with the following properties.
> +
> + Requred properties:
> + - compatible : Must include "xilinx,uartlite"
> + - reg : offset and length of uartlite register set
> +
> + Recommended properties:
> + - interrupt-parent, interrupts : Connection of device irq signal.
> +
typically, serial ports include properties for current-speed and
clock-frequency. I guess it would be good to include at least one
of the two here.
Arnd <><
^ permalink raw reply
* Re: [PATCH 2/2] i2c: Add devtree-aware iic support for PPC4xx
From: Scott Wood @ 2007-10-15 19:18 UTC (permalink / raw)
To: Eugene Surovegin; +Cc: Jean Delvare, Stefan Roese, i2c, linuxppc-dev
In-Reply-To: <20071015191118.GA9733@gate.ebshome.net>
Eugene Surovegin wrote:
> On Mon, Oct 15, 2007 at 01:53:40PM -0500, Scott Wood wrote:
>> Though, I don't see what the problem with the original approach is,
>> as long as the numbers are chosen in the same way when registering
>> i2c clients based on the children of the adapter node. There's no
>> concept in the hardware itself of a bus number.
>
> Huh? As far as I can tell, there is.
Where? Hardware != Documentation.
> Also, I want messages from the kernel mention something I can map to
> the real hw, e.g. fixed IIC device index, not some random number.
The OF node path should have a unit address that accomplishes that.
> I find it rather puzzling that instead people are trying to make this
> a non-issue as soon as it cannot be implemented easily with their new
> and shiny infrastructure.
"People" are not a monolithic entity. I never advocated using bus numbers.
-Scott
^ permalink raw reply
* Re: [PATCH 2/2] i2c: Add devtree-aware iic support for PPC4xx
From: Scott Wood @ 2007-10-15 19:24 UTC (permalink / raw)
To: Grant Likely; +Cc: Jean Delvare, linuxppc-dev, Stefan Roese, i2c
In-Reply-To: <fa686aa40710151213r670bea49i63fa5f5402aa150d@mail.gmail.com>
Grant Likely wrote:
> On 10/15/07, Scott Wood <scottwood@freescale.com> wrote:
>> On Mon, Oct 15, 2007 at 10:57:48AM -0600, Grant Likely wrote:
>>> Segher is recommending that we use an aliases node as per the open
>>> firmware example for this. I think in this case it would look
>>> something like this (but I'm not the expert):
>>>
>>> aliases {
>>> IIC0 = "/path/to/bus/iic@0x2000";
>>> IIC1 = "/path/to/bus/iic@0x2000";
>>> };
>> I think this is overly complicated; something like linux,i2c-index in the
>> i2c adapter node would be simpler.
>
> But not perhaps better. Enumeration is a system-wide thing. It does
> make sense to group all the device enumerations in one place.
For purposes of generating a Linux bus number, having to scan all
aliases for a matching path and turn IIC0/IIC1 into a number is a bit silly.
For associating a device node with a human readable label, I'd prefer a
"label" property in the device node, rather than doing it backwards with
aliases.
> As per your point below; if all the i2c devices are children of the
> adapter, then yes you are right that the bus number doesn't matter to
> the user. But it *does* matter for things like serial and ethernet
> ports.
And a label property would be great for that. :-)
>> Though, I don't see what the problem with the original approach is, as long
>> as the numbers are chosen in the same way when registering i2c clients based
>> on the children of the adapter node. There's no concept in the hardware
>> itself of a bus number.
>
> Even if you take this approach, the driver still need to know what bus
> number to use (as per the i2c infrastructure). It is not sane for an
> i2c bus driver to attempt to assign the bus number itself because it
> could conflict with another arbitrarily chosen bus number from another
> driver.
Hence why global bus numbers suck. :-)
However, statically chosen numbers should only be done for platform
devices, not dynamic things such as PCI, so in practice I don't think
it'd be a problem.
-Scott
^ permalink raw reply
* Re: [PATCH 2/2] i2c: Add devtree-aware iic support for PPC4xx
From: Grant Likely @ 2007-10-15 19:48 UTC (permalink / raw)
To: Scott Wood; +Cc: Jean Delvare, linuxppc-dev, Stefan Roese, i2c
In-Reply-To: <4713BE5E.3030406@freescale.com>
On 10/15/07, Scott Wood <scottwood@freescale.com> wrote:
> Grant Likely wrote:
> > On 10/15/07, Scott Wood <scottwood@freescale.com> wrote:
> >> On Mon, Oct 15, 2007 at 10:57:48AM -0600, Grant Likely wrote:
> >>> Segher is recommending that we use an aliases node as per the open
> >>> firmware example for this. I think in this case it would look
> >>> something like this (but I'm not the expert):
> >>>
> >>> aliases {
> >>> IIC0 = "/path/to/bus/iic@0x2000";
> >>> IIC1 = "/path/to/bus/iic@0x2000";
> >>> };
> >> I think this is overly complicated; something like linux,i2c-index in the
> >> i2c adapter node would be simpler.
> >
> > But not perhaps better. Enumeration is a system-wide thing. It does
> > make sense to group all the device enumerations in one place.
>
> For purposes of generating a Linux bus number, having to scan all
> aliases for a matching path and turn IIC0/IIC1 into a number is a bit silly.
>
> For associating a device node with a human readable label, I'd prefer a
> "label" property in the device node, rather than doing it backwards with
> aliases.
Here the corresponding problem; having to scan every device node to
make sure you don't assign a number already selected by another node
(in the case where one node is assigned a number and another is not).
At some point you're going to need to reverse map from number to
device. I'd rather scan a list of properties in aliases instead of
scanning the whole tree looking for all devices of the same type.
>
> > As per your point below; if all the i2c devices are children of the
> > adapter, then yes you are right that the bus number doesn't matter to
> > the user. But it *does* matter for things like serial and ethernet
> > ports.
>
> And a label property would be great for that. :-)
Not really; if the user needs to renumber devices; you don't want him
fiddling around in the hardware description. Just like the chosen
node; an aliases describes logical constructs, not physical ones. I
don't think this is any different from the linux,stdout-path property
in chosen.
>
> >> Though, I don't see what the problem with the original approach is, as long
> >> as the numbers are chosen in the same way when registering i2c clients based
> >> on the children of the adapter node. There's no concept in the hardware
> >> itself of a bus number.
> >
> > Even if you take this approach, the driver still need to know what bus
> > number to use (as per the i2c infrastructure). It is not sane for an
> > i2c bus driver to attempt to assign the bus number itself because it
> > could conflict with another arbitrarily chosen bus number from another
> > driver.
>
> Hence why global bus numbers suck. :-)
I'm not going to disagree with you there; but it's unavoidable.
> However, statically chosen numbers should only be done for platform
> devices, not dynamic things such as PCI, so in practice I don't think
> it'd be a problem.
So... in the I2C case, as long as all the i2c devices are in the
device tree and the i2c layer is responsible for actually handing out
the bus numbers; then yes I agree.
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] Device tree bindings for Xilinx devices
From: Grant Likely @ 2007-10-15 19:54 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev
In-Reply-To: <200710152121.54977.arnd@arndb.de>
On 10/15/07, Arnd Bergmann <arnd@arndb.de> wrote:
> On Monday 15 October 2007, Grant Likely wrote:
> > From: Grant Likely <grant.likely@secretlab.ca>
> >
> > Here's my second version of xilinx device tree bindings. Please review
> > and comment. I'd like to push these out to Paulus in the next couple
> > of days.
>
> There are a few more properties that I can imagine you might need.
> Not sure if it makes sense specifying them now, but here are my thoughts:
>
> > More devices will be defined as this spec matures.
> >
> > + l) Xilinx ML300 Framebuffer
> > +
> > + Simple framebuffer device from the ML300 reference design (also on the
> > + ML403 reference design as well as others).
> > +
> > + Required properties:
> > + - compatible : Must include "xilinx,ml300-fb"
> > + - reg : offset and length of the framebuffer register set
> > +
> > + Optional properties:
> > + - resolution : <xres yres> pixel resolution of framebuffer. Some
> > + implementations use a different resolution. Default
> > + is <d#640 d#480>
> > + - virt-resolution : <xvirt yvirt> Size of framebuffer in memory.
> > + Default is <d#1024 d#480>.
> > + - rotate-display (empty) : rotate display 180 degrees.
>
> rotate-display could be defined as something that allows 0/90/180/270
> degrees, as well as mirroring, not just 180 degree rotation.
Yeah, I'm not sure what to do here. The current xilinxfb device is
quite simple; but being that it's implemented in an FPGA, it's
conceivable that HW designers could build in any number of added
features in variant designs. rotate-display reflects the currently
implemented behavior. I'd like to future-proof it, but I'm not sure
how far down that path to go. (suggestions welcome!)
>
> > + o) Xilinx Uartlite
> > +
> > + Xilinx uartlite devices are simple fixed speed serial ports. Uartlite
> > + ports should be described in a node with the following properties.
> > +
> > + Requred properties:
> > + - compatible : Must include "xilinx,uartlite"
> > + - reg : offset and length of uartlite register set
> > +
> > + Recommended properties:
> > + - interrupt-parent, interrupts : Connection of device irq signal.
> > +
>
> typically, serial ports include properties for current-speed and
> clock-frequency. I guess it would be good to include at least one
> of the two here.
Is 'current-speed' the current baud rate? clock-frequency is unneeded
here because the uartlite is a fixed speed serial device. :-)
Thanks for the feedback,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH 2/2] i2c: Add devtree-aware iic support for PPC4xx
From: Scott Wood @ 2007-10-15 19:54 UTC (permalink / raw)
To: Grant Likely; +Cc: Jean Delvare, linuxppc-dev, Stefan Roese, i2c
In-Reply-To: <fa686aa40710151248y5e921a4fmbb0a3e0b7c9a2ca5@mail.gmail.com>
Grant Likely wrote:
> On 10/15/07, Scott Wood <scottwood@freescale.com> wrote:
>> For associating a device node with a human readable label, I'd
>> prefer a "label" property in the device node, rather than doing it
>> backwards with aliases.
>
> Here the corresponding problem; having to scan every device node to
> make sure you don't assign a number already selected by another node
> (in the case where one node is assigned a number and another is not).
>
Don't Do That(tm). If you use this mechanism, and an adapter node
doesn't have a bus number, then it doesn't get to pre-register devices,
but instead must use i2c_new_device.
>>> As per your point below; if all the i2c devices are children of
>>> the adapter, then yes you are right that the bus number doesn't
>>> matter to the user. But it *does* matter for things like serial
>>> and ethernet ports.
>> And a label property would be great for that. :-)
>
> Not really; if the user needs to renumber devices; you don't want him
> fiddling around in the hardware description.
Why would the user renumber devices?
> Just like the chosen node; an aliases describes logical constructs,
> not physical ones. I don't think this is any different from the
> linux,stdout-path property in chosen.
Well, it's somewhat different in that stdout describes a usage of the
device, not the identity.
Still, I don't like linux,stdout-path. :-)
At the very least it should be a phandle.
-Scott
^ permalink raw reply
* [PATCH] mpc8349emitx(gp): add UHCI support and other misc defconfig changes
From: Grant Likely @ 2007-10-15 16:33 UTC (permalink / raw)
To: Timur Tabi, galak, linuxppc-dev
From: Grant Likely <grant.likely@secretlab.ca>
USB support for the 8349itx got added a while back; but the defconfig
never got updated. This patch updates defconfig and adds the appropriate
USB config options.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
CC: Scott Wood <scottwood@freescale.com>
CC: Kumar Gala <galak@kernel.crashing.org>
CC: Timur Tabi <timur@freescale.com>
---
arch/powerpc/configs/mpc834x_itx_defconfig | 87 ++++++++----
arch/powerpc/configs/mpc834x_itxgp_defconfig | 190 ++++++++++++++++++++++----
2 files changed, 224 insertions(+), 53 deletions(-)
diff --git a/arch/powerpc/configs/mpc834x_itx_defconfig b/arch/powerpc/configs/mpc834x_itx_defconfig
index ddafa6b..8f3d1f2 100644
--- a/arch/powerpc/configs/mpc834x_itx_defconfig
+++ b/arch/powerpc/configs/mpc834x_itx_defconfig
@@ -1,7 +1,7 @@
#
# Automatically generated make config: don't edit
-# Linux kernel version: 2.6.23-rc4
-# Tue Aug 28 21:24:41 2007
+# Linux kernel version: 2.6.23-rc9
+# Mon Oct 15 10:28:18 2007
#
# CONFIG_PPC64 is not set
@@ -21,8 +21,13 @@ CONFIG_PPC_STD_MMU_32=y
# CONFIG_PPC_MM_SLICES is not set
# CONFIG_SMP is not set
CONFIG_PPC32=y
+CONFIG_WORD_SIZE=32
CONFIG_PPC_MERGE=y
CONFIG_MMU=y
+CONFIG_GENERIC_CMOS_UPDATE=y
+CONFIG_GENERIC_TIME=y
+CONFIG_GENERIC_TIME_VSYSCALL=y
+CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_IRQ_PER_CPU=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
@@ -83,12 +88,12 @@ CONFIG_FUTEX=y
CONFIG_ANON_INODES=y
# CONFIG_EPOLL is not set
CONFIG_SIGNALFD=y
-CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_VM_EVENT_COUNTERS=y
-CONFIG_SLAB=y
-# CONFIG_SLUB is not set
+# CONFIG_SLUB_DEBUG is not set
+# CONFIG_SLAB is not set
+CONFIG_SLUB=y
# CONFIG_SLOB is not set
CONFIG_RT_MUTEXES=y
# CONFIG_TINY_SHMEM is not set
@@ -122,7 +127,6 @@ CONFIG_DEFAULT_IOSCHED="anticipatory"
# Platform support
#
# CONFIG_PPC_MULTIPLATFORM is not set
-# CONFIG_EMBEDDED6xx is not set
# CONFIG_PPC_82xx is not set
CONFIG_PPC_83xx=y
# CONFIG_PPC_86xx is not set
@@ -155,6 +159,9 @@ CONFIG_MPC834x=y
# Kernel options
#
# CONFIG_HIGHMEM is not set
+# CONFIG_TICK_ONESHOT is not set
+# CONFIG_NO_HZ is not set
+# CONFIG_HIGH_RES_TIMERS is not set
# CONFIG_HZ_100 is not set
CONFIG_HZ_250=y
# CONFIG_HZ_300 is not set
@@ -183,9 +190,11 @@ CONFIG_VIRT_TO_BUS=y
CONFIG_PROC_DEVICETREE=y
# CONFIG_CMDLINE_BOOL is not set
# CONFIG_PM is not set
+CONFIG_SUSPEND_UP_POSSIBLE=y
+CONFIG_HIBERNATION_UP_POSSIBLE=y
CONFIG_SECCOMP=y
CONFIG_WANT_DEVICE_TREE=y
-CONFIG_DEVICE_TREE=""
+CONFIG_DEVICE_TREE="mpc8349emitx.dts"
CONFIG_ISA_DMA_API=y
#
@@ -219,7 +228,7 @@ CONFIG_ARCH_SUPPORTS_MSI=y
CONFIG_HIGHMEM_START=0xfe000000
CONFIG_LOWMEM_SIZE=0x30000000
CONFIG_KERNEL_START=0xc0000000
-CONFIG_TASK_SIZE=0x80000000
+CONFIG_TASK_SIZE=0xc0000000
CONFIG_BOOT_LOAD=0x00800000
#
@@ -419,11 +428,7 @@ CONFIG_BLK_DEV_RAM_SIZE=32768
CONFIG_BLK_DEV_RAM_BLOCKSIZE=1024
# CONFIG_CDROM_PKTCDVD is not set
# CONFIG_ATA_OVER_ETH is not set
-CONFIG_MISC_DEVICES=y
-# CONFIG_PHANTOM is not set
-# CONFIG_EEPROM_93CX6 is not set
-# CONFIG_SGI_IOC4 is not set
-# CONFIG_TIFM_CORE is not set
+# CONFIG_MISC_DEVICES is not set
CONFIG_IDE=y
CONFIG_IDE_MAX_HWIFS=4
# CONFIG_BLK_DEV_IDE is not set
@@ -618,6 +623,7 @@ CONFIG_NETDEV_1000=y
# CONFIG_SIS190 is not set
# CONFIG_SKGE is not set
# CONFIG_SKY2 is not set
+# CONFIG_SK98LIN is not set
# CONFIG_VIA_VELOCITY is not set
# CONFIG_TIGON3 is not set
# CONFIG_BNX2 is not set
@@ -625,14 +631,7 @@ CONFIG_GIANFAR=y
CONFIG_GFAR_NAPI=y
# CONFIG_QLA3XXX is not set
# CONFIG_ATL1 is not set
-CONFIG_NETDEV_10000=y
-# CONFIG_CHELSIO_T1 is not set
-# CONFIG_CHELSIO_T3 is not set
-# CONFIG_IXGB is not set
-# CONFIG_S2IO is not set
-# CONFIG_MYRI10GE is not set
-# CONFIG_NETXEN_NIC is not set
-# CONFIG_MLX4_CORE is not set
+# CONFIG_NETDEV_10000 is not set
# CONFIG_TR is not set
#
@@ -666,7 +665,28 @@ CONFIG_NETDEV_10000=y
#
# Input device support
#
-# CONFIG_INPUT is not set
+CONFIG_INPUT=y
+# CONFIG_INPUT_FF_MEMLESS is not set
+# CONFIG_INPUT_POLLDEV is not set
+
+#
+# Userland interfaces
+#
+# CONFIG_INPUT_MOUSEDEV is not set
+# CONFIG_INPUT_JOYDEV is not set
+# CONFIG_INPUT_TSDEV is not set
+CONFIG_INPUT_EVDEV=y
+# CONFIG_INPUT_EVBUG is not set
+
+#
+# Input Device Drivers
+#
+# CONFIG_INPUT_KEYBOARD is not set
+# CONFIG_INPUT_MOUSE is not set
+# CONFIG_INPUT_JOYSTICK is not set
+# CONFIG_INPUT_TABLET is not set
+# CONFIG_INPUT_TOUCHSCREEN is not set
+# CONFIG_INPUT_MISC is not set
#
# Hardware I/O ports
@@ -841,6 +861,17 @@ CONFIG_VIDEO_OUTPUT_CONTROL=m
# Sound
#
# CONFIG_SOUND is not set
+CONFIG_HID_SUPPORT=y
+CONFIG_HID=y
+# CONFIG_HID_DEBUG is not set
+
+#
+# USB Input Devices
+#
+CONFIG_USB_HID=y
+# CONFIG_USB_HIDINPUT_POWERBOOK is not set
+# CONFIG_HID_FF is not set
+CONFIG_USB_HIDDEV=y
CONFIG_USB_SUPPORT=y
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB_ARCH_HAS_OHCI=y
@@ -862,11 +893,11 @@ CONFIG_USB_DEVICE_CLASS=y
CONFIG_USB_EHCI_HCD=y
# CONFIG_USB_EHCI_SPLIT_ISO is not set
CONFIG_USB_EHCI_ROOT_HUB_TT=y
-# CONFIG_USB_EHCI_TT_NEWSCHED is not set
+CONFIG_USB_EHCI_TT_NEWSCHED=y
CONFIG_USB_EHCI_FSL=y
# CONFIG_USB_ISP116X_HCD is not set
# CONFIG_USB_OHCI_HCD is not set
-# CONFIG_USB_UHCI_HCD is not set
+CONFIG_USB_UHCI_HCD=y
# CONFIG_USB_SL811_HCD is not set
# CONFIG_USB_R8A66597_HCD is not set
@@ -893,6 +924,7 @@ CONFIG_USB_STORAGE=y
# CONFIG_USB_STORAGE_SDDR55 is not set
# CONFIG_USB_STORAGE_JUMPSHOT is not set
# CONFIG_USB_STORAGE_ALAUDA is not set
+# CONFIG_USB_STORAGE_ONETOUCH is not set
# CONFIG_USB_STORAGE_KARMA is not set
# CONFIG_USB_LIBUSUAL is not set
@@ -1010,7 +1042,7 @@ CONFIG_NET_DMA=y
#
# DMA Devices
#
-CONFIG_INTEL_IOATDMA=y
+# CONFIG_INTEL_IOATDMA is not set
#
# Userspace I/O
@@ -1169,7 +1201,7 @@ CONFIG_NLS_DEFAULT="iso8859-1"
# CONFIG_NLS_CODEPAGE_1250 is not set
# CONFIG_NLS_CODEPAGE_1251 is not set
# CONFIG_NLS_ASCII is not set
-# CONFIG_NLS_ISO8859_1 is not set
+CONFIG_NLS_ISO8859_1=y
# CONFIG_NLS_ISO8859_2 is not set
# CONFIG_NLS_ISO8859_3 is not set
# CONFIG_NLS_ISO8859_4 is not set
@@ -1213,7 +1245,7 @@ CONFIG_HAS_DMA=y
#
# Kernel hacking
#
-# CONFIG_PRINTK_TIME is not set
+CONFIG_PRINTK_TIME=y
CONFIG_ENABLE_MUST_CHECK=y
# CONFIG_MAGIC_SYSRQ is not set
# CONFIG_UNUSED_SYMBOLS is not set
@@ -1266,3 +1298,4 @@ CONFIG_CRYPTO_DES=y
# CONFIG_CRYPTO_CAMELLIA is not set
# CONFIG_CRYPTO_TEST is not set
CONFIG_CRYPTO_HW=y
+# CONFIG_PPC_CLOCK is not set
diff --git a/arch/powerpc/configs/mpc834x_itxgp_defconfig b/arch/powerpc/configs/mpc834x_itxgp_defconfig
index 8241c69..303e4e5 100644
--- a/arch/powerpc/configs/mpc834x_itxgp_defconfig
+++ b/arch/powerpc/configs/mpc834x_itxgp_defconfig
@@ -1,7 +1,7 @@
#
# Automatically generated make config: don't edit
-# Linux kernel version: 2.6.23-rc4
-# Tue Aug 28 21:24:41 2007
+# Linux kernel version: 2.6.23-rc9
+# Mon Oct 15 10:28:05 2007
#
# CONFIG_PPC64 is not set
@@ -21,8 +21,13 @@ CONFIG_PPC_STD_MMU_32=y
# CONFIG_PPC_MM_SLICES is not set
# CONFIG_SMP is not set
CONFIG_PPC32=y
+CONFIG_WORD_SIZE=32
CONFIG_PPC_MERGE=y
CONFIG_MMU=y
+CONFIG_GENERIC_CMOS_UPDATE=y
+CONFIG_GENERIC_TIME=y
+CONFIG_GENERIC_TIME_VSYSCALL=y
+CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_IRQ_PER_CPU=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
@@ -83,12 +88,12 @@ CONFIG_FUTEX=y
CONFIG_ANON_INODES=y
# CONFIG_EPOLL is not set
CONFIG_SIGNALFD=y
-CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_VM_EVENT_COUNTERS=y
-CONFIG_SLAB=y
-# CONFIG_SLUB is not set
+# CONFIG_SLUB_DEBUG is not set
+# CONFIG_SLAB is not set
+CONFIG_SLUB=y
# CONFIG_SLOB is not set
CONFIG_RT_MUTEXES=y
# CONFIG_TINY_SHMEM is not set
@@ -122,7 +127,6 @@ CONFIG_DEFAULT_IOSCHED="anticipatory"
# Platform support
#
# CONFIG_PPC_MULTIPLATFORM is not set
-# CONFIG_EMBEDDED6xx is not set
# CONFIG_PPC_82xx is not set
CONFIG_PPC_83xx=y
# CONFIG_PPC_86xx is not set
@@ -155,6 +159,9 @@ CONFIG_MPC834x=y
# Kernel options
#
# CONFIG_HIGHMEM is not set
+# CONFIG_TICK_ONESHOT is not set
+# CONFIG_NO_HZ is not set
+# CONFIG_HIGH_RES_TIMERS is not set
# CONFIG_HZ_100 is not set
CONFIG_HZ_250=y
# CONFIG_HZ_300 is not set
@@ -183,9 +190,11 @@ CONFIG_VIRT_TO_BUS=y
CONFIG_PROC_DEVICETREE=y
# CONFIG_CMDLINE_BOOL is not set
# CONFIG_PM is not set
+CONFIG_SUSPEND_UP_POSSIBLE=y
+CONFIG_HIBERNATION_UP_POSSIBLE=y
CONFIG_SECCOMP=y
CONFIG_WANT_DEVICE_TREE=y
-CONFIG_DEVICE_TREE=""
+CONFIG_DEVICE_TREE="mpc8349emitxgp.dts"
CONFIG_ISA_DMA_API=y
#
@@ -219,7 +228,7 @@ CONFIG_ARCH_SUPPORTS_MSI=y
CONFIG_HIGHMEM_START=0xfe000000
CONFIG_LOWMEM_SIZE=0x30000000
CONFIG_KERNEL_START=0xc0000000
-CONFIG_TASK_SIZE=0x80000000
+CONFIG_TASK_SIZE=0xc0000000
CONFIG_BOOT_LOAD=0x00800000
#
@@ -412,17 +421,14 @@ CONFIG_BLK_DEV_LOOP=y
# CONFIG_BLK_DEV_CRYPTOLOOP is not set
# CONFIG_BLK_DEV_NBD is not set
# CONFIG_BLK_DEV_SX8 is not set
+# CONFIG_BLK_DEV_UB is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=32768
CONFIG_BLK_DEV_RAM_BLOCKSIZE=1024
# CONFIG_CDROM_PKTCDVD is not set
# CONFIG_ATA_OVER_ETH is not set
-CONFIG_MISC_DEVICES=y
-# CONFIG_PHANTOM is not set
-# CONFIG_EEPROM_93CX6 is not set
-# CONFIG_SGI_IOC4 is not set
-# CONFIG_TIFM_CORE is not set
+# CONFIG_MISC_DEVICES is not set
# CONFIG_IDE is not set
#
@@ -549,6 +555,7 @@ CONFIG_NETDEV_1000=y
# CONFIG_SIS190 is not set
# CONFIG_SKGE is not set
# CONFIG_SKY2 is not set
+# CONFIG_SK98LIN is not set
# CONFIG_VIA_VELOCITY is not set
# CONFIG_TIGON3 is not set
# CONFIG_BNX2 is not set
@@ -556,14 +563,7 @@ CONFIG_GIANFAR=y
CONFIG_GFAR_NAPI=y
# CONFIG_QLA3XXX is not set
# CONFIG_ATL1 is not set
-CONFIG_NETDEV_10000=y
-# CONFIG_CHELSIO_T1 is not set
-# CONFIG_CHELSIO_T3 is not set
-# CONFIG_IXGB is not set
-# CONFIG_S2IO is not set
-# CONFIG_MYRI10GE is not set
-# CONFIG_NETXEN_NIC is not set
-# CONFIG_MLX4_CORE is not set
+# CONFIG_NETDEV_10000 is not set
# CONFIG_TR is not set
#
@@ -571,6 +571,16 @@ CONFIG_NETDEV_10000=y
#
# CONFIG_WLAN_PRE80211 is not set
# CONFIG_WLAN_80211 is not set
+
+#
+# USB Network Adapters
+#
+# CONFIG_USB_CATC is not set
+# CONFIG_USB_KAWETH is not set
+# CONFIG_USB_PEGASUS is not set
+# CONFIG_USB_RTL8150 is not set
+# CONFIG_USB_USBNET_MII is not set
+# CONFIG_USB_USBNET is not set
# CONFIG_WAN is not set
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
@@ -587,7 +597,28 @@ CONFIG_NETDEV_10000=y
#
# Input device support
#
-# CONFIG_INPUT is not set
+CONFIG_INPUT=y
+# CONFIG_INPUT_FF_MEMLESS is not set
+# CONFIG_INPUT_POLLDEV is not set
+
+#
+# Userland interfaces
+#
+# CONFIG_INPUT_MOUSEDEV is not set
+# CONFIG_INPUT_JOYDEV is not set
+# CONFIG_INPUT_TSDEV is not set
+CONFIG_INPUT_EVDEV=y
+# CONFIG_INPUT_EVBUG is not set
+
+#
+# Input Device Drivers
+#
+# CONFIG_INPUT_KEYBOARD is not set
+# CONFIG_INPUT_MOUSE is not set
+# CONFIG_INPUT_JOYSTICK is not set
+# CONFIG_INPUT_TABLET is not set
+# CONFIG_INPUT_TOUCHSCREEN is not set
+# CONFIG_INPUT_MISC is not set
#
# Hardware I/O ports
@@ -637,6 +668,11 @@ CONFIG_83xx_WDT=y
#
# CONFIG_PCIPCWATCHDOG is not set
# CONFIG_WDTPCI is not set
+
+#
+# USB-based Watchdog Cards
+#
+# CONFIG_USBPCWATCHDOG is not set
CONFIG_HW_RANDOM=y
# CONFIG_NVRAM is not set
# CONFIG_GEN_RTC is not set
@@ -681,6 +717,7 @@ CONFIG_I2C_MPC=y
# CONFIG_I2C_SIS96X is not set
# CONFIG_I2C_TAOS_EVM is not set
# CONFIG_I2C_STUB is not set
+# CONFIG_I2C_TINY_USB is not set
# CONFIG_I2C_VIA is not set
# CONFIG_I2C_VIAPRO is not set
# CONFIG_I2C_VOODOO3 is not set
@@ -736,6 +773,7 @@ CONFIG_SPI_MPC83xx=y
# CONFIG_VIDEO_DEV is not set
# CONFIG_DVB_CORE is not set
CONFIG_DAB=y
+# CONFIG_USB_DABUSB is not set
#
# Graphics support
@@ -755,19 +793,118 @@ CONFIG_VIDEO_OUTPUT_CONTROL=m
# Sound
#
# CONFIG_SOUND is not set
+CONFIG_HID_SUPPORT=y
+CONFIG_HID=y
+# CONFIG_HID_DEBUG is not set
+
+#
+# USB Input Devices
+#
+CONFIG_USB_HID=y
+# CONFIG_USB_HIDINPUT_POWERBOOK is not set
+# CONFIG_HID_FF is not set
+CONFIG_USB_HIDDEV=y
CONFIG_USB_SUPPORT=y
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB_ARCH_HAS_OHCI=y
CONFIG_USB_ARCH_HAS_EHCI=y
-# CONFIG_USB is not set
+CONFIG_USB=y
+# CONFIG_USB_DEBUG is not set
+
+#
+# Miscellaneous USB options
+#
+CONFIG_USB_DEVICEFS=y
+CONFIG_USB_DEVICE_CLASS=y
+# CONFIG_USB_DYNAMIC_MINORS is not set
+# CONFIG_USB_OTG is not set
+
+#
+# USB Host Controller Drivers
+#
+CONFIG_USB_EHCI_HCD=y
+# CONFIG_USB_EHCI_SPLIT_ISO is not set
CONFIG_USB_EHCI_ROOT_HUB_TT=y
+CONFIG_USB_EHCI_TT_NEWSCHED=y
CONFIG_USB_EHCI_FSL=y
+# CONFIG_USB_ISP116X_HCD is not set
+# CONFIG_USB_OHCI_HCD is not set
+CONFIG_USB_UHCI_HCD=y
+# CONFIG_USB_SL811_HCD is not set
+# CONFIG_USB_R8A66597_HCD is not set
+
+#
+# USB Device Class drivers
+#
+# CONFIG_USB_ACM is not set
+# CONFIG_USB_PRINTER is not set
#
# NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support'
#
#
+# may also be needed; see USB_STORAGE Help for more information
+#
+CONFIG_USB_STORAGE=y
+# CONFIG_USB_STORAGE_DEBUG is not set
+# CONFIG_USB_STORAGE_DATAFAB is not set
+# CONFIG_USB_STORAGE_FREECOM is not set
+# CONFIG_USB_STORAGE_DPCM is not set
+# CONFIG_USB_STORAGE_USBAT is not set
+# CONFIG_USB_STORAGE_SDDR09 is not set
+# CONFIG_USB_STORAGE_SDDR55 is not set
+# CONFIG_USB_STORAGE_JUMPSHOT is not set
+# CONFIG_USB_STORAGE_ALAUDA is not set
+# CONFIG_USB_STORAGE_ONETOUCH is not set
+# CONFIG_USB_STORAGE_KARMA is not set
+# CONFIG_USB_LIBUSUAL is not set
+
+#
+# USB Imaging devices
+#
+# CONFIG_USB_MDC800 is not set
+# CONFIG_USB_MICROTEK is not set
+CONFIG_USB_MON=y
+
+#
+# USB port drivers
+#
+
+#
+# USB Serial Converter support
+#
+# CONFIG_USB_SERIAL is not set
+
+#
+# USB Miscellaneous drivers
+#
+# CONFIG_USB_EMI62 is not set
+# CONFIG_USB_EMI26 is not set
+# CONFIG_USB_ADUTUX is not set
+# CONFIG_USB_AUERSWALD is not set
+# CONFIG_USB_RIO500 is not set
+# CONFIG_USB_LEGOTOWER is not set
+# CONFIG_USB_LCD is not set
+# CONFIG_USB_BERRY_CHARGE is not set
+# CONFIG_USB_LED is not set
+# CONFIG_USB_CYPRESS_CY7C63 is not set
+# CONFIG_USB_CYTHERM is not set
+# CONFIG_USB_PHIDGET is not set
+# CONFIG_USB_IDMOUSE is not set
+# CONFIG_USB_FTDI_ELAN is not set
+# CONFIG_USB_APPLEDISPLAY is not set
+# CONFIG_USB_SISUSBVGA is not set
+# CONFIG_USB_LD is not set
+# CONFIG_USB_TRANCEVIBRATOR is not set
+# CONFIG_USB_IOWARRIOR is not set
+# CONFIG_USB_TEST is not set
+
+#
+# USB DSL modem support
+#
+
+#
# USB Gadget Support
#
# CONFIG_USB_GADGET is not set
@@ -837,7 +974,7 @@ CONFIG_NET_DMA=y
#
# DMA Devices
#
-CONFIG_INTEL_IOATDMA=y
+# CONFIG_INTEL_IOATDMA is not set
#
# Userspace I/O
@@ -996,7 +1133,7 @@ CONFIG_NLS_DEFAULT="iso8859-1"
# CONFIG_NLS_CODEPAGE_1250 is not set
# CONFIG_NLS_CODEPAGE_1251 is not set
# CONFIG_NLS_ASCII is not set
-# CONFIG_NLS_ISO8859_1 is not set
+CONFIG_NLS_ISO8859_1=y
# CONFIG_NLS_ISO8859_2 is not set
# CONFIG_NLS_ISO8859_3 is not set
# CONFIG_NLS_ISO8859_4 is not set
@@ -1040,7 +1177,7 @@ CONFIG_HAS_DMA=y
#
# Kernel hacking
#
-# CONFIG_PRINTK_TIME is not set
+CONFIG_PRINTK_TIME=y
CONFIG_ENABLE_MUST_CHECK=y
# CONFIG_MAGIC_SYSRQ is not set
# CONFIG_UNUSED_SYMBOLS is not set
@@ -1093,3 +1230,4 @@ CONFIG_CRYPTO_DES=y
# CONFIG_CRYPTO_CAMELLIA is not set
# CONFIG_CRYPTO_TEST is not set
CONFIG_CRYPTO_HW=y
+# CONFIG_PPC_CLOCK is not set
^ permalink raw reply related
* Re: [PATCH 1/2] i2c: ibm_iic: Whitespace cleanup
From: Jean Delvare @ 2007-10-15 20:19 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev, i2c
In-Reply-To: <200710151528.55261.sr@denx.de>
Hi Stefan,
On Mon, 15 Oct 2007 15:28:54 +0200, Stefan Roese wrote:
> Signed-off-by: Stefan Roese <sr@denx.de>
> ---
> drivers/i2c/busses/i2c-ibm_iic.c | 192 +++++++++++++++++++-------------=
------
> drivers/i2c/busses/i2c-ibm_iic.h | 8 +-
> 2 files changed, 100 insertions(+), 100 deletions(-)
>=20
> diff --git a/drivers/i2c/busses/i2c-ibm_iic.c b/drivers/i2c/busses/i2c-ib=
m_iic.c
> index e08baca..956b947 100644
> --- a/drivers/i2c/busses/i2c-ibm_iic.c
> +++ b/drivers/i2c/busses/i2c-ibm_iic.c
> @@ -6,7 +6,7 @@
> * Copyright (c) 2003, 2004 Zultys Technologies.
> * Eugene Surovegin <eugene.surovegin@zultys.com> or <ebs@ebshome.net>
> *
> - * Based on original work by=20
> + * Based on original work by
> * Ian DaSilva <idasilva@mvista.com>
> * Armin Kuster <akuster@mvista.com>
> * Matt Porter <mporter@mvista.com>
> @@ -18,7 +18,7 @@
> * Copyright 1995-97 Simon G. Vogl
> * 1998-99 Hans Berglund
> *
> - * With some changes from Ky=F6sti M=E4lkki <kmalkki@cc.hut.fi>=20
> + * With some changes from Ky=F6sti M=E4lkki <kmalkki@cc.hut.fi>
> * and even Frodo Looijaard <frodol@dds.nl>
> *
> * This program is free software; you can redistribute it and/or modify=
it
(etc.)
Applied, thank you.
--=20
Jean Delvare
^ permalink raw reply
* Re: [PATCH 2/2] i2c: Add devtree-aware iic support for PPC4xx
From: Grant Likely @ 2007-10-15 20:26 UTC (permalink / raw)
To: Scott Wood; +Cc: Jean Delvare, linuxppc-dev, Stefan Roese, i2c
In-Reply-To: <4713C57F.7060509@freescale.com>
On 10/15/07, Scott Wood <scottwood@freescale.com> wrote:
> Grant Likely wrote:
> > On 10/15/07, Scott Wood <scottwood@freescale.com> wrote:
> >> For associating a device node with a human readable label, I'd
> >> prefer a "label" property in the device node, rather than doing it
> >> backwards with aliases.
> >
> > Here the corresponding problem; having to scan every device node to
> > make sure you don't assign a number already selected by another node
> > (in the case where one node is assigned a number and another is not).
> >
> Don't Do That(tm). If you use this mechanism, and an adapter node
> doesn't have a bus number, then it doesn't get to pre-register devices,
> but instead must use i2c_new_device.
Even that doesn't work. For example if a PCI device is probed which
registers an i2c bus; there needs to be a mechanism for the i2c layer
to know that an id is already spoken for, so once again there needs to
be a mechanism to map easily from id to device (or lack thereof).
> >>> As per your point below; if all the i2c devices are children of
> >>> the adapter, then yes you are right that the bus number doesn't
> >>> matter to the user. But it *does* matter for things like serial
> >>> and ethernet ports.
> >> And a label property would be great for that. :-)
> >
> > Not really; if the user needs to renumber devices; you don't want him
> > fiddling around in the hardware description.
>
> Why would the user renumber devices?
Where user == system integrator or firmware engineer. ie. boards with
no-populate options which affect the numbering; changes to match the
silkscreening on the chassis when a common board is used by multiple
systems. It's a conceivable scenario. (Again; this is more relevant
to eth and serial devices than i2c).
>
> > Just like the chosen node; an aliases describes logical constructs,
> > not physical ones. I don't think this is any different from the
> > linux,stdout-path property in chosen.
>
> Well, it's somewhat different in that stdout describes a usage of the
> device, not the identity.
>
> Still, I don't like linux,stdout-path. :-)
> At the very least it should be a phandle.
I'm cool with it being a phandle. (insert obvious objection someone
will make about that not being OF compatible) :-)
Perhaps aliases should look like (which can be generated from the OF
path form when the device tree if flattened):
aliases {
linux,eth0 = <phandle1>;
linux,eth1 = <phandle2>;
}
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 4/7] bestcomm: core bestcomm support for Freescale MPC5200
From: Matt Sealey @ 2007-10-15 20:53 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, paulus, domen.puncer
In-Reply-To: <fa686aa40710150704j15f3a511rf5924573282c966b@mail.gmail.com>
Grant Likely wrote:
> On 10/15/07, Matt Sealey <matt@genesi-usa.com> wrote:
>> My nits:
>>
>> Grant Likely wrote:
>>> From: Sylvain Munaut <tnt@246tNt.com>
>>> +static int __devinit
>>> +bcom_engine_init(void)
>> Why "bcom" and not "bestcomm"?
>
> I can type 'bcom' twice as fast. :-) bcom is a suitable shortening;
> I'm not concerned about it.
I hate acronyms and shortening for the sake of it.
My IDE highlights known symbols from includes and lets me tab complete them :D
After all once all these APIs are fixed and most of the drivers are implemented
(most of them are, already, anyway, and have been from TaskSomething to sdma_
to bcom_ changes and major API reworks), I wonder why we have to constantly
cut every function definition down to 4 characters rhp_bjz_ywh_moo_purr()
I'd level the same thing at bcom_eng (what's an Eng when it's at home? English?
Engraved? Surely Engine but.. come on :)
There's no real good need to shorten the names of things except when those
shortenings are also used in the documentation - after all, PSC is what Freescale
call a PSC, we wouldn't be making structures called mpc52xx_programmable_serial_controller,
that's redundant, I don't think calling it "bestcomm" (which is it's name) over
"bcom" (which isn't) works to anyone's advantage here.
>>> + /* Disable COMM Bus Prefetch, apparently it's not reliable yet */
>>> + /* FIXME: This should be done on 5200 and not 5200B ... */
>>> + out_be16(&bcom_eng->regs->PtdCntrl, in_be16(&bcom_eng->regs->PtdCntrl) | 1);
>> This really, really shouldn't even be here, could it be moved to a platform
>> init, or switched on a PVR/SVR here?
>
> I think I'd like to leave it here for getting this series merged; it
> may not be good to have it here; but it's not dangerous either. I'm
> trying to keep churn on this series down to a minimum.
Why not just accept the churn, and remove those two lines, and someone will
submit a patch to make it work on the 5200 in the appropriate place later?
I don't think "mainlining it" is a good excuse to leave FIXME comments
and little device-specific hacks in drivers.
> Please submit a patch to make this change once it's merged.
I'd rather submit a patch containing this fix somewhere else, without having
to touch this driver ever again.
My opinion is that this is a firmware thing, u-boot or openfirmware should
be configuring the system on boot so that they do not do crazy things like
enable the BTIC on a 7447, or leave comm bus prefetch turned on with a 5200 -
in the absense of good firmware, platform support should be used.
This is what Segher tells me we should be doing, but I see you guys "breaking
the rules" all the time.. it makes it hard to justify doing any Linux platform
support if we are beaten with the stick while you guys munch on the carrots..
So, I don't think "reducing churn" justifies leaving it in. Users of 5200
devices who need that fix, can patch their kernels.. users of 5200B and
5121E who do not need that fix, shouldn't be forced to.
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
^ permalink raw reply
* Re: [PATCH 2/2] i2c: Add devtree-aware iic support for PPC4xx
From: Scott Wood @ 2007-10-15 20:45 UTC (permalink / raw)
To: Grant Likely; +Cc: Jean Delvare, linuxppc-dev, Stefan Roese, i2c
In-Reply-To: <fa686aa40710151326m789046aaq60ba002e180d4e14@mail.gmail.com>
Grant Likely wrote:
> On 10/15/07, Scott Wood <scottwood@freescale.com> wrote:
>> Don't Do That(tm). If you use this mechanism, and an adapter node
>> doesn't have a bus number, then it doesn't get to pre-register devices,
>> but instead must use i2c_new_device.
>
> Even that doesn't work. For example if a PCI device is probed which
> registers an i2c bus; there needs to be a mechanism for the i2c layer
> to know that an id is already spoken for, so once again there needs to
> be a mechanism to map easily from id to device (or lack thereof).
As long as all statically-assigned buses have their devices passed to
i2c_register_board_info by platform code before the PCI device is
probed, the i2c layer will hand out bus numbers that don't conflict.
> Where user == system integrator or firmware engineer. ie. boards with
> no-populate options which affect the numbering; changes to match the
> silkscreening on the chassis when a common board is used by multiple
> systems. It's a conceivable scenario. (Again; this is more relevant
> to eth and serial devices than i2c).
Sure, but I guess I don't see the problem with such a person editing the
label property. The label property also gives more freedom in terms of
which characters can be used in the description.
Aliases could still be used when there's a higher level abstraction
related to purpose, not identification.
-Scott
^ permalink raw reply
* Re: [PATCH v2 4/7] bestcomm: core bestcomm support for Freescale MPC5200
From: Matt Sealey @ 2007-10-15 20:55 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, paulus, domen.puncer
In-Reply-To: <4713D35A.9080200@genesi-usa.com>
Matt Sealey wrote:
> call a PSC, we wouldn't be making structures called mpc52xx_programmable_serial_controller,
> that's redundant, I don't think calling it "bestcomm" (which is it's name) over
> "bcom" (which isn't) works to anyone's advantage here.
Disadvantage, even. Damn autocorrecting :(
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
^ permalink raw reply
* Re: [PATCH 1/5] Update ibm_newemac to use dcr_host_t.base
From: Benjamin Herrenschmidt @ 2007-10-15 20:54 UTC (permalink / raw)
To: Jeff Garzik; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <4713B2A1.4000503@pobox.com>
On Mon, 2007-10-15 at 14:34 -0400, Jeff Garzik wrote:
> Michael Ellerman wrote:
> > Now that dcr_host_t contains the base address, we can use that in the
> > ibm_newemac code, rather than storing it separately.
> >
> > Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
> > ---
> > drivers/net/ibm_newemac/mal.c | 9 +++++----
> > drivers/net/ibm_newemac/mal.h | 5 ++---
> > 2 files changed, 7 insertions(+), 7 deletions(-)
>
> applied 1-5
Those patches have been around for some time now, they didn't make
paulus initial merge for reasons I'm not sure about but I think they
should go into 2.6.24. Now the question is via Jeff or via Paulus ? :-)
Ben.
^ permalink raw reply
* RE: Override timer interrupt
From: Benjamin Herrenschmidt @ 2007-10-15 20:55 UTC (permalink / raw)
To: Rune Torgersen; +Cc: linuxppc-dev, linuxppc-embedded
In-Reply-To: <DCEAAC0833DD314AB0B58112AD99B93B037D4F05@ismail.innsys.innovsys.com>
On Mon, 2007-10-15 at 11:49 -0500, Rune Torgersen wrote:
>
> The main couse is that our main bus frequency cannort be divided into
> 1kHz evently by the decrementer.
> Main bus freq = 99532800 Hz.
> Decrementer then becomes 24883, which gives us 999991.9624485600nsec
> per
> jiffy.
> That is not a number easilly converted into time without drift.
>
> Changing HZ to 100 fixes it, but is for varous reasons not an option
> right now.
>
> What I did do is change the timer interrupt to be called by an
> ecxternal
> 1kHz interrupt source instead of the decrementer.
>
> The TB register is only ued for offsets from the last jiffie, not as a
> continous offset, so then it works out pretty good.
> There is a discontinuity in the sub ms resolution of the clock that I
> can live with. msec and up are dead accurate.
The date is derived from the absolute TB value though...
Ben.
^ permalink raw reply
* Re: [PATCH] PowerPC: Add NEW EMAC driver support to 440EPx Sequoia board.
From: Benjamin Herrenschmidt @ 2007-10-15 21:01 UTC (permalink / raw)
To: Valentine Barshak; +Cc: linuxppc-dev
In-Reply-To: <20071012130305.GA14682@ru.mvista.com>
On Fri, 2007-10-12 at 17:03 +0400, Valentine Barshak wrote:
> This patch enables NEW EMAC support for PowerPC 440EPx Sequoia board
> and adds BCM5248 and Marvell 88E1111 PHY support to NEW EMAC driver.
> These PHY chips are used on PowerPC440EPx boards.
> The PHY code is based on the previous work by Stefan Roese <sr@denx.de>
>
> Signed-off-by: Stefan Roese <sr@denx.de>
> Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>
> ---
> arch/powerpc/platforms/44x/Kconfig | 7 ++----
> drivers/net/ibm_newemac/phy.c | 39 +++++++++++++++++++++++++++++++++++++
> 2 files changed, 42 insertions(+), 4 deletions(-)
>
> --- linux.orig/arch/powerpc/platforms/44x/Kconfig 2007-07-30 15:05:50.000000000 +0400
> +++ linux/arch/powerpc/platforms/44x/Kconfig 2007-07-30 17:59:05.000000000 +0400
> @@ -48,10 +48,9 @@
> config 440EPX
> bool
> select PPC_FPU
> -# Disabled until the new EMAC Driver is merged.
> -# select IBM_NEW_EMAC_EMAC4
> -# select IBM_NEW_EMAC_RGMII
> -# select IBM_NEW_EMAC_ZMII
> + select IBM_NEW_EMAC_EMAC4
> + select IBM_NEW_EMAC_RGMII
> + select IBM_NEW_EMAC_ZMII
>
> config 440GP
> bool
> --- linux.orig/drivers/net/ibm_newemac/phy.c 2007-06-15 21:45:18.000000000 +0400
> +++ linux/drivers/net/ibm_newemac/phy.c 2007-06-15 20:45:15.000000000 +0400
> @@ -306,8 +306,47 @@
> .ops = &cis8201_phy_ops
> };
>
> +static struct mii_phy_def bcm5248_phy_def = {
> +
> + .phy_id = 0x0143bc00,
> + .phy_id_mask = 0x0ffffff0,
> + .name = "BCM5248 10/100 SMII Ethernet",
> + .ops = &generic_phy_ops
> +};
> +
> +static int m88e1111_init(struct mii_phy *phy)
> +{
> + printk("%s: Marvell 88E1111 Ethernet\n", __FUNCTION__);
> + phy_write(phy, 0x14, 0x0ce3);
> + phy_write(phy, 0x18, 0x4101);
> + phy_write(phy, 0x09, 0x0e00);
> + phy_write(phy, 0x04, 0x01e1);
> + phy_write(phy, 0x00, 0x9140);
> + phy_write(phy, 0x00, 0x1140);
> +
> + return 0;
> +}
> +
> +static struct mii_phy_ops m88e1111_phy_ops = {
> + .init = m88e1111_init,
> + .setup_aneg = genmii_setup_aneg,
> + .setup_forced = genmii_setup_forced,
> + .poll_link = genmii_poll_link,
> + .read_link = genmii_read_link
> +};
> +
> +static struct mii_phy_def m88e1111_phy_def = {
> +
> + .phy_id = 0x01410CC0,
> + .phy_id_mask = 0x0ffffff0,
> + .name = "Marvell 88E1111 Ethernet",
> + .ops = &m88e1111_phy_ops,
> +};
> +
> static struct mii_phy_def *mii_phy_table[] = {
> &cis8201_phy_def,
> + &bcm5248_phy_def,
> + &m88e1111_phy_def,
> &genmii_phy_def,
> NULL
> };
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH] PowerPC: Add NEW EMAC driver support to 440EPx Sequoia board.
From: Benjamin Herrenschmidt @ 2007-10-15 20:59 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <20071015122616.08250b54@weaponx.rchland.ibm.com>
On Mon, 2007-10-15 at 12:26 -0500, Josh Boyer wrote:
> On Fri, 12 Oct 2007 17:03:05 +0400
> Valentine Barshak <vbarshak@ru.mvista.com> wrote:
>
> > This patch enables NEW EMAC support for PowerPC 440EPx Sequoia board
> > and adds BCM5248 and Marvell 88E1111 PHY support to NEW EMAC driver.
> > These PHY chips are used on PowerPC440EPx boards.
> > The PHY code is based on the previous work by Stefan Roese <sr@denx.de>
>
> Could you send the phy part to Jeff Garzik and the netdev list by
> itself? That way it will get picked up and we'll update the Kconfig
> with a later patch.
Oh and please CC me :-)
Ben.
^ permalink raw reply
* Re: [PATCH] NEW EMAC Fix RGMII build error: use of_device_is_compatible
From: Benjamin Herrenschmidt @ 2007-10-15 21:01 UTC (permalink / raw)
To: Valentine Barshak; +Cc: linuxppc-dev, netdev
In-Reply-To: <20071012130445.GA14704@ru.mvista.com>
On Fri, 2007-10-12 at 17:04 +0400, Valentine Barshak wrote:
> Fix build RGMII error: use of_device_is_compatible()
> insteadof now deprecated device_is_compatible() function.
>
> Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
> drivers/net/ibm_newemac/rgmii.c | 2 +-
> 1 files changed, 1 insertion(+), 1 deletion(-)
>
> diff -pruN linux-2.6.orig/drivers/net/ibm_newemac/rgmii.c linux-2.6/drivers/net/ibm_newemac/rgmii.c
> --- linux-2.6.orig/drivers/net/ibm_newemac/rgmii.c 2007-10-12 16:02:41.000000000 +0400
> +++ linux-2.6/drivers/net/ibm_newemac/rgmii.c 2007-10-12 16:49:07.000000000 +0400
> @@ -251,7 +251,7 @@ static int __devinit rgmii_probe(struct
> }
>
> /* Check for RGMII type */
> - if (device_is_compatible(ofdev->node, "ibm,rgmii-axon"))
> + if (of_device_is_compatible(ofdev->node, "ibm,rgmii-axon"))
> dev->type = RGMII_AXON;
> else
> dev->type = RGMII_STANDARD;
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ 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