* Re: Oops: of_platform_serial_probe
From: Arnd Bergmann @ 2007-11-19 16:56 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <474193B8.9060007@anagramm.de>
On Monday 19 November 2007, Clemens Koller wrote:
> Unable to handle kernel paging request for data at address 0x00000000
> Faulting instruction address: 0xc018f03c
> Oops: Kernel access of bad area, sig: 11 [#1]
> MPC85xx ADS
> Modules linked in:
> NIP: c018f03c LR: c018f00c CTR: c00127b4
> REGS: c0821cf0 TRAP: 0300 =A0 Not tainted =A0(2.6.24-rc2-ge6a5c27f)
> MSR: 00029000 <EE,ME> =A0CR: 42022088 =A0XER: 20000000
> DEAR: 00000000, ESR: 00000000
> TASK =3D c081e000[1] 'swapper' THREAD: c0820000
> GPR00: b1000000 c0821da0 c081e000 c0833e10 00000004 c0821d80 c03d3064 c05=
eea80
> GPR08: 00000200 00000002 0000002a 13ab6680 82022042 00000000 c03318a4 c03=
3188c
> GPR16: c0331908 c03318f0 c03a0e30 c0331930 c033191c 007fff00 0ffeccbc c03=
a0000
> GPR24: c0821dc4 00000000 00000003 c0934cf8 cffffba8 00000000 c0833e00 c07=
fdc6c
> NIP [c018f03c] of_platform_serial_probe+0x118/0x1e4
> LR [c018f00c] of_platform_serial_probe+0xe8/0x1e4
> Call Trace:
Ok, that is a NULL pointer access, probably somewhere in the
of_platform_serial_setup that can be inlined. Please post the
device tree entries for your serial ports so we can see what
goes wrong there.
One potential problem that I can see is a missing 'current-speed'
property in your tree, which would cause this behavior. It looks
like many device trees set this, but it is not required by all
bindings. If that's the case, the patch below should fix your
problem, but you probably want to set the current-speed anyway,
according to your boot loader settings.
Arnd <><
=2D-- a/drivers/serial/of_serial.c
+++ b/drivers/serial/of_serial.c
@@ -56,7 +56,8 @@ static int __devinit of_platform_serial_setup(struct of_d=
evice *ofdev,
port->flags =3D UPF_SHARE_IRQ | UPF_BOOT_AUTOCONF | UPF_IOREMAP
| UPF_FIXED_PORT;
port->dev =3D &ofdev->dev;
=2D port->custom_divisor =3D *clk / (16 * (*spd));
+ if (spd)
+ port->custom_divisor =3D *clk / (16 * (*spd));
return 0;
}
^ permalink raw reply
* Re: Revisited, audio codec device tree entries.
From: Matt Sealey @ 2007-11-19 16:58 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: PowerPC dev list
In-Reply-To: <621f1d7bb87a49559d22162314b98398@kernel.crashing.org>
Segher Boessenkool wrote:
>> And I forgot the rant you guys usually get - for god's sake, why isn't
>> anyone using the "model" property?
>
> Probably because it isn't useful all that often.
>
>> sound@0 {
>> \\ this is our magic audio fabric
>> device_type = "digispeaker,flinger";
>
> This is wrong in so many ways; see David's mail for a start.
Why? I'm sorry but I am living in the real world where we have real
firmwares and real dynamic device trees here. You can't just say
"this is wrong because it has a device_type".
>> \\ and this defines the layout Jon picked for the DACs
>> \\ just like Apple's layout-id value
>> model = "flinger,2"
>
> "flinger" is some company that sells something they call the "2"?
> Interesting.
No, but who cares of the format of the model? It's for information -
in this case it's just there so that Jon can find out what "layout"
his codec, control interface, GPIOs, ports on the board, mixer
names, what colour the sky was on that day in June when he met his
wife-to-be, the name of his first dog, whatever information he needs
to implement on ANY driver model on ANY operating system is on that
particular version.
Maybe it should be digispeaker,2 or digispeaker,666 - who cares?
It's for the driver to know what it means.
I suggest it because I think Apple's "layout-id" is cryptic and
ridiculous duplication. Jon suggested to me a couple days back
that the layout-id is so model-specific (it increments each time
they brought out a new board, so it is synchronised with the
root "model" property!) that it's redundant. He suggested using
the root "model" property to switch his driver on the layout.
In this scenario, why not use the "model" property to keep the
audio driver more self-contained here? That was the theory
behind it.
> "model" should be the real-world exact model name/number of the device.
Well, on this example, it's quite obvious it's an MPC5200B I2S bus,
but you're not describing solely the i2s bus (although in the
example it will operate with a standard mpc5200b-psc-i2s driver)
but the entire audio solution and indirectly how to program that
audio solution (ta-da!) - i2s bus, pcm codec, it's control interface,
and anything else besides, which is...
>> Isn't the primary concern of an audio codec, to play audio?
>
> And the primary purpose of the device tree is to describe the hardware,
> and (indirectly) how to program it.
.. exactly what it does.
> For an audio codec that has I2C and I2S connections, the interface
> over which you program it is I2C.
What if you don't connect I2C to something Linux can access directly?
> There are other technicalities, too; for example, if the codec node
> would be a child node of the I2S bus, you cannot have two codecs with
> the same name on one such bus (since that bus isn't a "bus" really,
> it's more like a broadcast interface; it cannot address separate devices
> on that "bus", so in the device tree the codecs wouldn't get a "reg",
> etc.)
*shrug* as an example..
>> Therefore, shouldn't the audio codec point back to it's control
>> interface?
>
> No. The codec node _is_ the "control interface".
I think that flies in the face of the implementation of a bunch of
codecs.
>> Also, why give the name as 'i2s-handle'?
>
> Why not?
>
>> Surely it could be any interface.
>
> No it cannot; this property is only present for audio codecs that have
> an I2S bus (and not even all those, it is dependent on the device binding
> in use).
See below.
>> In reverse, it would be, perhaps, as
>> above, i2c-handle, but then what if you change the interface
>> type (for instance a bunch of Wolfson codecs can do i2c and
>> spi for control). Your property name is obselete, then and
>> drivers will need to switch on property names to find out
>> which control interface is present.
>
> That's another great argument against doing as you suggest, yes.
Why? The i2s codec sits on the i2s bus. You're right there is no
addressing on i2s it just has a stream of auduo going through it.
The i2s bus is one thing. This defines a PCM transport. This is
standardised.
The codec node defines which PCM/DAC you have on the end. This
DAC may have certain features - it may only have certain sample
rates supported, or may only support certain clock speeds. This
is what the codec node under the bus is for.
The codec node references the package handle of it's control
interface. If you want to play audio - well, go ahead, stream
some audio to the i2s bus, based on the abilities of the codec
(which are well defined in the datasheet you'd hope). You may
even use the OF standard properties for a "sound" node to define
these too - after all, it has a binding already and it would
improve driver support.
If you want to fiddle with it you need control interface, but
the primary purpose of an *audio device* is to play audio.
It is not to switch mixers on and off and change bass boost, that
is a totally secondary feature of an audio output or input
device, which may not even be present.
>> What they should really do, is be told where their control
>> interface handle is, then you can look at that handle and
>> the device it contains
>
> What you *should* do is just look at the parent node if you want to
> know how to talk to the device. This is the same for *all* nodes in
> *all* device trees.
Sorry Segher but you argued against this last time we had this
discussion. You said that all device nodes should be self-contained
and looking elsewhere in the tree is ridiculous.
What if you have a chip which has an SPI control interface, and
uses a custom FIFO setup to stream audio? What do you use then,
i2s-handle? Ha ha ha. Don't encode bus names in properties. They
should be descriptive. i2s-handle would point to a node which
has a device_type (on real firmware) and compatible property which
gives you ALL the information you need to determine
>> Remember, it doesn't matter what NAME you give it, the name
>> is for people to read,
>
> Not only. When the generic naming recommended practice is in use, "name"
> can be used to find all nodes of a certain type. Neither "name" nor
> "device_type" should be used for device driver matching though;
Then, no real Open Firmware implementation can work. What you need to
do, then is repeat the device_type information in the compatible
property on real firmwares. This is dumb. Stop sidelining real firmwares
for the sake of the Linux device tree.
> "compatible" is for that.
Why don't we propose a solution then? device_type is the type of
device you're looking at. This might be chrp,iic or it might be
fsl,i2c or it could be something else. Write this into your device
tree spec. This is important for real firmwares and other operating
systems which try and conform to IEEE 1275.
Then get your fdt blob builder and fix it so that it concatenates
the device_type value into the compatible property, and ditches
the device_type value for FDT's.
Don't start killing off part of the Open Firmware spec for the sake
of it. If you expect real Open Firmware developers to actually pay
attention to the Linux device tree specs it needs to take them into
account and not just run off on the justification that it was
"decided by the community so it's canon" - you need to design the
trees based on users of the technology.
> [As a historic note, before the "generic naming" thing, "name" was used
> for exactly what the first entry in "compatible" is used for now. But
> let's try to forget that, okay?]
>
>> device_type is what you search for,
>
> Unless you are programming in "real" Open Firmware itself, you do _not_
> search for "device_type". Ever.
Hello, we license one, so we're concerned about this.
Last time we shipped a real Open Firmware itself, you were the biggest
opponent on getting the device tree checked and standardised. Now you
want to just remove features, I don't see how we should even care if
you're going to be like that, but you're forcing us to do your bidding
against better knowledge.
When you have your own firmware to play with you can do what you like
with it, you can remove the property.. and Linux can happily support
it, but we *really* need to support other systems here and defining
things in backwards Linux ways is bad.
>> and model is to give you the enviable ability
>> to define PRECISELY what you are looking at beyond a chip
>> name.
>
> When a device driver uses "model" for anything, it is typically because
> "compatible" says the device is a member of some family of devices that
> all behave identically, but uh-oh, this isn't actually true.
>
> It's also not all that great for human readers, since the format is
> vendor-specific.
It's hard to define a value which describes something human readable
yet being simple to parse by a machine. Remember the whole justification
for XML? I don't think "model" (or by that regard, name, device_type
or compatible) *MUST* be human readable, but where and if it can be,
it should be.
name = some pretty name to differentiate it from something else in
the device tree. Not searchable, but just pretty in the output of
'.properties'
device_type = primary driver switch to look for the device, since it's
part of the OF spec, we have to implement it on our firmware. you
needn't in FDTs, but, please help us out on this.
compatible = if you don't find it in device_type, look here. I don't
think it should need to repeat device_type on real OF implementations.
model = you found the driver but you're concerned about some very
exact functionality which may not be present or software-detectable,
so you encode it here. Be that the SVR, be that the full part number
lasered into the die of the chip, be it mpc5200b,1.4 - this is up
to the guy who designed the hardware and the driver SHOULD be able
to use it AT IT'S OPTION to handle certain quirks, layout issues or
bugs in the device.
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
^ permalink raw reply
* Re: Revisited, audio codec device tree entries.
From: Jon Smirl @ 2007-11-19 16:55 UTC (permalink / raw)
To: Timur Tabi; +Cc: PowerPC dev list
In-Reply-To: <4741BD5D.2090502@freescale.com>
On 11/19/07, Timur Tabi <timur@freescale.com> wrote:
> Grant Likely wrote:
>
> > You probably mean "don't use the of_platform bus to load the fabric
> > driver".
>
> Yes, that is what I meant.
>
> > He still needs to use the data in the device tree to decide
> > what fabric drivers to use.
>
> I'm not sure about that. The fabric driver is tied to the platform itself,
> mostly because the fabric driver isn't really a device driver. It's a
> platform driver, in that its job is to initialize the other device drivers, or
> make sure the kernel initializes them. It's also responsible for telling ALSA
> which driver does what and how they're connected.
>
> With the current version of ASoC (V1), I don't think it's possible to have an
> independent platform driver. V2 is in development, but it's not ready yet and
> I haven't had a chance to study it. V2 is intended to address the problems
> that a device tree model raises.
I'm using the v2 code. The v2 code is modeled after the i2c bus code
which is the correct way to do drivers for open firmware.
v1 creates asoc core as a platform device which was completely wrong
since it is a driver core, not a device. That is fixed in v2 where it
initializes with a subsysinit() call and then creates a bus. The whole
driver organization of v2 is superior to v1. Open firmware support was
the main motivation behind v2.
>
> > In this case; it probably is appropriate to have the platform code
> > instantiate a platform_device for the fabric (instead of an
> > of_platform device) which the fabric driver can bind against.
> >
> > Another option is to explicitly call of_platform_device_create in the
> > platform code on the fabric node (which should be a child of the root
> > node) so that you can have an of_platform_bus fabric driver.
>
> I don't fully understand platform drivers. Do we really need a full-blown OF
> platform driver for this?
>
> --
> Timur Tabi
> Linux Kernel Developer @ Freescale
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Revisited, audio codec device tree entries.
From: Grant Likely @ 2007-11-19 16:53 UTC (permalink / raw)
To: Timur Tabi; +Cc: PowerPC dev list
In-Reply-To: <4741BD5D.2090502@freescale.com>
On 11/19/07, Timur Tabi <timur@freescale.com> wrote:
> Grant Likely wrote:
>
> > You probably mean "don't use the of_platform bus to load the fabric
> > driver".
>
> Yes, that is what I meant.
>
> > He still needs to use the data in the device tree to decide
> > what fabric drivers to use.
>
> I'm not sure about that. The fabric driver is tied to the platform itself,
> mostly because the fabric driver isn't really a device driver. It's a
> platform driver, in that its job is to initialize the other device drivers, or
> make sure the kernel initializes them. It's also responsible for telling ALSA
> which driver does what and how they're connected.
>
Even it it's just based on the board "model" property; that's still
deciding what the ALSA fabric is based on data in the device tree.
:-)
> > Another option is to explicitly call of_platform_device_create in the
> > platform code on the fabric node (which should be a child of the root
> > node) so that you can have an of_platform_bus fabric driver.
>
> I don't fully understand platform drivers. Do we really need a full-blown OF
> platform driver for this?
Both the platform bus and the of_platform bus do exactly the same
thing in a simple manner. They allow devices to be matched with
drivers. It is a low overhead mechanism.
In both cases, devices carry with them some metadata to describe the
devices. For platform devices, that meta data is a resource structure
and a device specific pdata structure. For of_platform devices, the
metadata is a pointer to a device tree node.
That's it. Using either mechanism allows the platform code to say
"these devices are present" without having to explicitly call routines
into the driver. In other words; it can provide late binding of
drivers to devices.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: Revisited, audio codec device tree entries.
From: Jon Smirl @ 2007-11-19 16:51 UTC (permalink / raw)
To: Grant Likely; +Cc: PowerPC dev list, Timur Tabi
In-Reply-To: <fa686aa40711190831s2e59ab05h63d10ec8a24eaad5@mail.gmail.com>
On 11/19/07, Grant Likely <grant.likely@secretlab.ca> wrote:
> On 11/19/07, Jon Smirl <jonsmirl@gmail.com> wrote:
> > On 11/19/07, Grant Likely <grant.likely@secretlab.ca> wrote:
> > > On 11/19/07, Timur Tabi <timur@freescale.com> wrote:
> > > > Jon Smirl wrote:
> > > >
> > > > > In the ALSA SOC model the i2s, codec and ac97 drivers are all generic.
> > > > > A fabric driver tells specifically how a generic codec is wired into
> > > > > the board. What I haven't been able figure out is how to load the
> > > > > right fabric driver.
> > > >
> > > > Do not use the device tree to load the fabric driver!
> > >
> > > Heh, technically you can't use the device tree to load any device
> > > drivers, it's just a data structure. :-)
> > >
> > > You probably mean "don't use the of_platform bus to load the fabric
> > > driver". He still needs to use the data in the device tree to decide
> > > what fabric drivers to use. of_platform_bus would be awkward to use
> > > for this because the node describing the fabric doesn't cleanly sit on
> > > any particular bus (ie. it describes the board; it does not describe
> > > the device).
> > >
> > > In this case; it probably is appropriate to have the platform code
> > > instantiate a platform_device for the fabric (instead of an
> > > of_platform device) which the fabric driver can bind against.
> >
> > First, I have platform bus turned off in my builds. Platform bus is a
> > place where cruft accumulates that really belongs somewhere else. For
> > example when I turned it off I discovered that there was a PC speaker
> > driver in my kernel and well as several drivers from 82xx chips.
> >
> > ALSA creates it own bus like i2c. My fabric driver sits on this bus.,
> > Kconfig attributes control if it is built-in. I've altered the i2c
> > code to look for child device tree nodes and then load the appropriate
> > drivers.
>
> Can't you then instantiate the ALSA bus device in your board platform
> code? Then when the driver is registered, the bus should call it's
> probe routine.
Yes, I can do that. I have just been resisting creating a code linkage
from arch/powerpc/platform/xx to sound/alsa/soc/powerpc. I also need
to create the fabric driver after alsa has made the bus,
subsys_initcall(asoc_bus_init);
> --
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
> grant.likely@secretlab.ca
> (403) 399-0195
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Revisited, audio codec device tree entries.
From: Timur Tabi @ 2007-11-19 16:45 UTC (permalink / raw)
To: Jon Smirl; +Cc: PowerPC dev list
In-Reply-To: <9e4733910711190800t5dc9bc40q1b58feae4ff364d0@mail.gmail.com>
Jon Smirl wrote:
> Now how do I pick which fabric driver to initialize?
I'm doing it via a Kconfig option. For ASoC V1, I think that's the only way
that works.
--
Timur Tabi
Linux Kernel Developer @ Freescale
^ permalink raw reply
* Re: Revisited, audio codec device tree entries.
From: Timur Tabi @ 2007-11-19 16:44 UTC (permalink / raw)
To: Grant Likely; +Cc: PowerPC dev list
In-Reply-To: <fa686aa40711190733vd1ffac0k62bf32186eb57aff@mail.gmail.com>
Grant Likely wrote:
> You probably mean "don't use the of_platform bus to load the fabric
> driver".
Yes, that is what I meant.
> He still needs to use the data in the device tree to decide
> what fabric drivers to use.
I'm not sure about that. The fabric driver is tied to the platform itself,
mostly because the fabric driver isn't really a device driver. It's a
platform driver, in that its job is to initialize the other device drivers, or
make sure the kernel initializes them. It's also responsible for telling ALSA
which driver does what and how they're connected.
With the current version of ASoC (V1), I don't think it's possible to have an
independent platform driver. V2 is in development, but it's not ready yet and
I haven't had a chance to study it. V2 is intended to address the problems
that a device tree model raises.
> In this case; it probably is appropriate to have the platform code
> instantiate a platform_device for the fabric (instead of an
> of_platform device) which the fabric driver can bind against.
>
> Another option is to explicitly call of_platform_device_create in the
> platform code on the fabric node (which should be a child of the root
> node) so that you can have an of_platform_bus fabric driver.
I don't fully understand platform drivers. Do we really need a full-blown OF
platform driver for this?
--
Timur Tabi
Linux Kernel Developer @ Freescale
^ permalink raw reply
* Re: Oops: of_platform_serial_probe
From: Timur Tabi @ 2007-11-19 16:34 UTC (permalink / raw)
To: Clemens Koller; +Cc: linuxppc-embedded
In-Reply-To: <4741B934.90400@anagramm.de>
Clemens Koller wrote:
> Timur Tabi schrieb:
> > Clemens Koller wrote:
> >
> >> I guess I didn't configure the OF serial right in the .dts but it still
> >> shouldn't crash. My .config is attached.
> >
> > Try disabling CONFIG_SERIAL_OF_PLATFORM. I don't think it means what
> > you think it means.
>
> Thanks, disabling CONFIG_SERIAL_OF_PLATFORM helps. but it still
> shouldn't crash...
That's a bug in the OF serial driver. It's expecting fields in the serial
node that don't exist. You are right, however. The driver should at least
check for NULL pointers. If I had any hardware that used that driver, I would
fix it myself.
--
Timur Tabi
Linux Kernel Developer @ Freescale
^ permalink raw reply
* Re: Revisited, audio codec device tree entries.
From: Matt Sealey @ 2007-11-19 16:31 UTC (permalink / raw)
To: Matt Sealey, Jon Smirl, PowerPC dev list
In-Reply-To: <20071119001209.GD20794@localhost.localdomain>
David Gibson wrote:
> On Sun, Nov 18, 2007 at 11:31:13PM +0000, Matt Sealey wrote:
>
> Gah! For the benefit of others on this list who may be misled.
>
> *Neither* of you correctly understands the device tree, what I've seen
> of *both* your suggested approaches is crap.
>
> The device tree describes the _hardware_. If you start reasoning
> about how to lay out the device tree based on your driver model,
> you're already wrong.
>
> Matt, the various properties you list do not mean what you think they
> mean.
No, David, I understand exactly what they mean, in the context of
a guy who works on Open Firmware, real Open Firmware, as was standardised
12 years ago.
Not your whacky newspeak device trees, which to be fair, are a good
idea, but it seems you all have tried to change something for the
sake of changing something.
> name - should be named according to the generic names convention.
> It's pretty much arbitrary, meant for human readability of the device
> tree. Drivers should not depend on it (some do, historically, but new
> drivers and trees should not).
I never said drivers should depend on it but why do you want to name
an i2s bus as "i2s" or the i2c bus as "i2c"? There are far, far more
descriptive names that can be used. i2s is basically audio, so why
not "audio" or "sound" or "headphone"?
Why is gpt a "gpt" and not a "timer", it defeats the whole object
of having a name for it. Since drivers never switch on it, why not
give them real names?
> device_type - indicates the open firmware method interface for the
> device. Therefore, meaningless in flattened trees. No new driver
> should use this.
.. you seem to think you must only design for the guys making Linux
flattened device trees. I'm sorry, but I am not one of those guys and
I am much more concerned with how this will affect the OF device tree
and the usage for anyone else.
Meaningless in flattened device trees, but useful information in real
OF device trees, do you implement it or not? I'd say, yes. Even if
you don't agree with "real firmware", you can't just ignore it, shrug
it away and say it doesn't matter.
Jon's fabric driver should be looking for "digispeaker,flinger"
and nothing else. The name doesn't matter but I called it "sound"
because it's far, FAR more descriptive than "i2s", and of course
both the device_type and compatible properties report exactly what
Jon will need to write a driver which handles, however that might
be, his audio codec subsystem - pcm, control, magic gpios, or
whatever.
If there is an Open Firmware standard for it, I would use that name,
then it gives everyone a rough idea of what to expect. Open Firmware
developers can then CHOOSE TO IMPLEMENT THE STANDARD METHODS, and
Linux device tree authors can just ignore it.
You are cutting out a working specification for the sake of some
arbitrary simplification.
> compatible - *this* is the one for driver selection. It describes the
> hardware level interface(s) of the device.
Compatible is meant to list alternative, compatible devices as a
*supplement* to device_type. device_type is your "primary" and
compatible is your "secondary". In this case, device_type is
exactly what Jon wants, something to mark out that the audio device
is his board design and requires special work (it is not merely an
i2s bus that you can just "use" - although throwing PCM data at it
would work, who knows what mixer it goes to, and what controls are
needed to define the bitrate or other features)
> model - usually just for debugging / diagnosis / human-readable
> purposes, describes exact model / revision of the hardware. It can be
> used to enable driver quirks / workarounds for when various devices
> are supposed to be compatible (as encoded in 'compatible') but
> aren't, due to hardware bugs. However, you should never aim to use it
> this way in design.
I don't see why "model" can't encode the particular revision of the
hardware in this way when it comes to the audio group of features on
his board. After all, if you are looking at a "digispeaker,flinger"
(I made that name up) then you need to know depending on the board
or even based on weird configurability options of the board, what
certain things may be - Apple used layout-id and a number. Why NOT
encode the "model" in the "model"?
Why choose some magical, new property, which then has to be further
standardised for no reason?
I also think that specifying an audio codec - after all the Open
Firmware standard defines an audio interface and device tree
requirements for it, even if they are methods that we don't
implement and you don't care about - as a function of it's
control interface is so backwards it doesn't bare thinking about.
If you want to output audio you do it through most audio
controllers as a simple transfer of PCM data. Be it Creative
or Freescale I2S or AC97, you push data at some port/fifo
and it plays a sound. It is NOT defined by i2c control ports,
you don't ever use those to *play* audio. It may also be very,
very true that a codec DOES NOT REQUIRE implementation of it's
control interface, or that control interface could be connected
to some other chip which handles initial configuration (like
a boot sequencer eeprom) and not to a system bus.
Therefore, pcm audio codecs as subordinate of control interfaces
is a dumb idea. Nuff said, I think.
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
^ permalink raw reply
* Re: Revisited, audio codec device tree entries.
From: Grant Likely @ 2007-11-19 16:31 UTC (permalink / raw)
To: Jon Smirl; +Cc: PowerPC dev list, Timur Tabi
In-Reply-To: <9e4733910711190800t5dc9bc40q1b58feae4ff364d0@mail.gmail.com>
On 11/19/07, Jon Smirl <jonsmirl@gmail.com> wrote:
> On 11/19/07, Grant Likely <grant.likely@secretlab.ca> wrote:
> > On 11/19/07, Timur Tabi <timur@freescale.com> wrote:
> > > Jon Smirl wrote:
> > >
> > > > In the ALSA SOC model the i2s, codec and ac97 drivers are all generic.
> > > > A fabric driver tells specifically how a generic codec is wired into
> > > > the board. What I haven't been able figure out is how to load the
> > > > right fabric driver.
> > >
> > > Do not use the device tree to load the fabric driver!
> >
> > Heh, technically you can't use the device tree to load any device
> > drivers, it's just a data structure. :-)
> >
> > You probably mean "don't use the of_platform bus to load the fabric
> > driver". He still needs to use the data in the device tree to decide
> > what fabric drivers to use. of_platform_bus would be awkward to use
> > for this because the node describing the fabric doesn't cleanly sit on
> > any particular bus (ie. it describes the board; it does not describe
> > the device).
> >
> > In this case; it probably is appropriate to have the platform code
> > instantiate a platform_device for the fabric (instead of an
> > of_platform device) which the fabric driver can bind against.
>
> First, I have platform bus turned off in my builds. Platform bus is a
> place where cruft accumulates that really belongs somewhere else. For
> example when I turned it off I discovered that there was a PC speaker
> driver in my kernel and well as several drivers from 82xx chips.
>
> ALSA creates it own bus like i2c. My fabric driver sits on this bus.,
> Kconfig attributes control if it is built-in. I've altered the i2c
> code to look for child device tree nodes and then load the appropriate
> drivers.
Can't you then instantiate the ALSA bus device in your board platform
code? Then when the driver is registered, the bus should call it's
probe routine.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: Oops: of_platform_serial_probe
From: Clemens Koller @ 2007-11-19 16:26 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-embedded
In-Reply-To: <4741A617.1060207@freescale.com>
Timur Tabi schrieb:
> Clemens Koller wrote:
>
>> I guess I didn't configure the OF serial right in the .dts but it still
>> shouldn't crash. My .config is attached.
>
> Try disabling CONFIG_SERIAL_OF_PLATFORM. I don't think it means what
> you think it means.
Thanks, disabling CONFIG_SERIAL_OF_PLATFORM helps. but it still shouldn't crash...
Regards,
Clemens Koller
__________________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Straße 45/1
Linhof Werksgelände
D-81379 München
Tel.089-741518-50
Fax 089-741518-19
http://www.anagramm-technology.com
^ permalink raw reply
* Re: how to improve linux tcp/ip(UDP) efficiency on mpc8541 833Mhz.
From: Detlev Zundel @ 2007-11-19 15:10 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <47407CCB.80503@chello.nl>
Hi,
> We use a 8250 and 8270 of which the performance is highly limited by the
> bandwidth of the memory to the very small internal cache.
> I once modified a driver into a "polling" method polling the device
> every millisecond. The amount of messages processed trippled this way!
> On full speed the console could even be used for "normal" operation (in
> contrairy to the interrupt driver driver).
> The penalties are obvious: When the bandwith used is low the delay for
> polled messages is higher and the CPU overhead is higher.
Just look at the NAPI[1] (New-NAPI in the latest incarnation) linux
layer for network drivers. The upshot of this is that where "old"
drivers pull data from the network card onto the kernel network
backlog on interrupt time, NAPI drivers only set an internal flag so
they want to get polled by the kernel when it is ready and basically
disable further interrupts. They are enabled again by the time the
driver was able to post all packets up to the network stack.
This effectively gives low latencies on low network load because it
more or less stays being interrupt driven but it turns into polling
mode on high network loads and thus prevents interrupt live lock
situations.
Adapting the network driver in question to NNAPI should improve the
performance of the whole system quite a bit.
Best wishes
Detlev
[1] http://www.linux-foundation.org/en/Net:NAPI
--
Indeed, the author firmly believes that the best serious work is also
good fun. We needn't apologize if we enjoy doing research.
-- Donald Knuth
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu@denx.de
^ permalink raw reply
* Re: Revisited, audio codec device tree entries.
From: Jon Smirl @ 2007-11-19 16:00 UTC (permalink / raw)
To: Grant Likely; +Cc: PowerPC dev list, Timur Tabi
In-Reply-To: <fa686aa40711190733vd1ffac0k62bf32186eb57aff@mail.gmail.com>
On 11/19/07, Grant Likely <grant.likely@secretlab.ca> wrote:
> On 11/19/07, Timur Tabi <timur@freescale.com> wrote:
> > Jon Smirl wrote:
> >
> > > In the ALSA SOC model the i2s, codec and ac97 drivers are all generic.
> > > A fabric driver tells specifically how a generic codec is wired into
> > > the board. What I haven't been able figure out is how to load the
> > > right fabric driver.
> >
> > Do not use the device tree to load the fabric driver!
>
> Heh, technically you can't use the device tree to load any device
> drivers, it's just a data structure. :-)
>
> You probably mean "don't use the of_platform bus to load the fabric
> driver". He still needs to use the data in the device tree to decide
> what fabric drivers to use. of_platform_bus would be awkward to use
> for this because the node describing the fabric doesn't cleanly sit on
> any particular bus (ie. it describes the board; it does not describe
> the device).
>
> In this case; it probably is appropriate to have the platform code
> instantiate a platform_device for the fabric (instead of an
> of_platform device) which the fabric driver can bind against.
First, I have platform bus turned off in my builds. Platform bus is a
place where cruft accumulates that really belongs somewhere else. For
example when I turned it off I discovered that there was a PC speaker
driver in my kernel and well as several drivers from 82xx chips.
ALSA creates it own bus like i2c. My fabric driver sits on this bus.,
Kconfig attributes control if it is built-in. I've altered the i2c
code to look for child device tree nodes and then load the appropriate
drivers.
static void of_register_i2c_devices(struct i2c_adapter *adap, struct
device_node *adap_node)
{
struct device_node *node = NULL;
while ((node = of_get_next_child(adap_node, node))) {
struct i2c_board_info info;
const u32 *addr;
const char *compatible;
int len;
addr = of_get_property(node, "reg", &len);
if (!addr || len < sizeof(int) || *addr > (1 << 10) - 1) {
printk(KERN_WARNING "i2c-mpc.c: invalid entry, missing reg attribute\n");
continue;
}
info.irq = irq_of_parse_and_map(node, 0);
if (info.irq == NO_IRQ)
info.irq = -1;
compatible = of_get_property(node, "compatible", &len);
if (!compatible) {
printk(KERN_WARNING "i2c-mpc.c: invalid entry, missing compatible
attribute\n");
continue;
}
strncpy(info.driver_name, compatible, sizeof(info.driver_name));
info.type[0] = '\0';
info.platform_data = NULL;
info.addr = *addr;
i2c_new_device(adap, &info);
}
}
I have a similar loop in the ac97 driver for loading codecs it controls.
So now I'm at this point:
i2c bus driver loaded, initialized from of
i2s bus driver loaded, initialized from of
tas5504 codec loaded onto i2c, initialized from i2c loop above
multiple fabric drivers loaded onto the alsa bus
Now how do I pick which fabric driver to initialize?
Codec and i2s are also attached to alsa bus.
>
> Another option is to explicitly call of_platform_device_create in the
> platform code on the fabric node (which should be a child of the root
> node) so that you can have an of_platform_bus fabric driver.
>
> Cheers,
> g.
>
> >
> > The layout of the hardware and the relationship between the I2S, I2C, codec,
> > and whatever device is determined by *both* the fabric driver and the device
> > tree. The information about the devices itself, and *some* information about
> > their relationship is stored in the device tree. Everything else is in the
> > fabric driver.
> >
> > The design of the device tree is already locked in stone, so to speak. The DT
> > can only store what it is allowed to store. If there's something more that
> > you need, you'll have to put it in the fabric driver.
> >
> > If I weren't on vacation this week, I'd email you my code. It's almost done
> > and it demonstrates what I'm thinking.
> >
> > --
> > Timur Tabi
> > Linux Kernel Developer @ Freescale
> > _______________________________________________
> > Linuxppc-dev mailing list
> > Linuxppc-dev@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-dev
> >
>
>
> --
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
> grant.likely@secretlab.ca
> (403) 399-0195
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Revisited, audio codec device tree entries.
From: Grant Likely @ 2007-11-19 15:42 UTC (permalink / raw)
To: Jon Smirl; +Cc: PowerPC dev list, Timur Tabi
In-Reply-To: <9e4733910711190737o59b7b692se7cc5ff569c6a479@mail.gmail.com>
On 11/19/07, Jon Smirl <jonsmirl@gmail.com> wrote:
> On 11/19/07, Timur Tabi <timur@freescale.com> wrote:
> > Jon Smirl wrote:
> >
> > > In the ALSA SOC model the i2s, codec and ac97 drivers are all generic.
> > > A fabric driver tells specifically how a generic codec is wired into
> > > the board. What I haven't been able figure out is how to load the
> > > right fabric driver.
> >
> > Do not use the device tree to load the fabric driver!
>
> If I have a multiplatform kernel with 10 fabric drivers built in, how
> do you decide which one to activate without looking at the device
> tree? Multiplatform kernels are what is causing this problem. If the
> kernel is just for a single platform I can hardwire the fabric driver
> in without looking at the tree.
Simple; instantiate the needed platform_device or of_platform_device
in the board platform code (arch/powerpc/platforms/*). Then the
driver has something to bind against.
That way the driver's probe() method gets called without having to
traverse the entire tree.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: Revisited, audio codec device tree entries.
From: Jon Smirl @ 2007-11-19 15:37 UTC (permalink / raw)
To: Timur Tabi; +Cc: PowerPC dev list
In-Reply-To: <4741A56D.9050808@freescale.com>
On 11/19/07, Timur Tabi <timur@freescale.com> wrote:
> Jon Smirl wrote:
>
> > In the ALSA SOC model the i2s, codec and ac97 drivers are all generic.
> > A fabric driver tells specifically how a generic codec is wired into
> > the board. What I haven't been able figure out is how to load the
> > right fabric driver.
>
> Do not use the device tree to load the fabric driver!
If I have a multiplatform kernel with 10 fabric drivers built in, how
do you decide which one to activate without looking at the device
tree? Multiplatform kernels are what is causing this problem. If the
kernel is just for a single platform I can hardwire the fabric driver
in without looking at the tree.
>
> The layout of the hardware and the relationship between the I2S, I2C, codec,
> and whatever device is determined by *both* the fabric driver and the device
> tree. The information about the devices itself, and *some* information about
> their relationship is stored in the device tree. Everything else is in the
> fabric driver.
>
> The design of the device tree is already locked in stone, so to speak. The DT
> can only store what it is allowed to store. If there's something more that
> you need, you'll have to put it in the fabric driver.
>
> If I weren't on vacation this week, I'd email you my code. It's almost done
> and it demonstrates what I'm thinking.
>
> --
> Timur Tabi
> Linux Kernel Developer @ Freescale
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Revisited, audio codec device tree entries.
From: Jon Smirl @ 2007-11-19 15:33 UTC (permalink / raw)
To: Timur Tabi; +Cc: PowerPC dev list
In-Reply-To: <4741A443.4080900@freescale.com>
On 11/19/07, Timur Tabi <timur@freescale.com> wrote:
> Matt Sealey wrote:
> > Jon Smirl wrote:
> >> The codec-fabric node was just being used to trigger the loading of
> >> the platform specific driver.
> >
> > Just remember one thing.
> >
> > 1) the term "fabric" when coined for audio drivers is a new, ALSA SoC
> > specific term. It isn't relevant for anything but ALSA SoC drivers.
>
> Earlier this year, when I started working on an ASoC driver, the fabric driver
> was called a "machine driver".
ALSA is using the term fabric in the aoa directory, and the term
'machine' in the soc directory. They both mean the same thing, but it
is very confusing to call this a machine driver when we are talking
about device trees. Once everything gets settled the aoa code should
be merged into the soc code, it is almost identical in architecture.
>
> > 2) this device tree stuff will end up in more than Linux device trees
>
> Sorry, I don't understand. The device trees are technically OS-independent,
> so technically there's no such thing as a "Linux device tree". In addition,
> the current master repository for device trees happens to be the Linux kernel,
> so I'm not sure where else device trees are going to be.
>
> > 3) you're going to piss off Open Firmware developers by specifying
> > very Linux-specific features in a device tree the same way Apple
> > pissed off Linux developers by encoding MacOS X-specific features in
> > the device tree.
>
> The current device trees have left their OF roots behind. Sure, we try to
> conform as much as possible, but they're not OF trees any more.
>
> > Audio driver control like this has to be very specific for a good
> > reason; you can do it a billion ways to Sunday. I'd suggest basically
> > that if you must control a device in a way that needs to be defined by
> > a device which can change address (either dynamically on boot or by
> > board design change - per revision, for example, or with a change of
> > controller) then simply use the device tree to report this address
> > so that you can have the same basic fabric driver (all in Linux) which
> > can handle minor modifications of your board design.
>
> My position is that the "fabric" driver should be loaded as a normal device
> tree and it should use the device tree to pick up some data to help it
> instantiate the other drivers. I'll be posting the code to my PowerPC ASoC
> driver in a couple weeks.
>
> > If you require the codec to be subservient to some "fabric" then I
>
> The codec is subservient to a bus (sometimes multiple buses), which is why it
> is a child to bus nodes.
>
> --
> Timur Tabi
> Linux Kernel Developer @ Freescale
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Revisited, audio codec device tree entries.
From: Grant Likely @ 2007-11-19 15:33 UTC (permalink / raw)
To: Timur Tabi; +Cc: PowerPC dev list
In-Reply-To: <4741A56D.9050808@freescale.com>
On 11/19/07, Timur Tabi <timur@freescale.com> wrote:
> Jon Smirl wrote:
>
> > In the ALSA SOC model the i2s, codec and ac97 drivers are all generic.
> > A fabric driver tells specifically how a generic codec is wired into
> > the board. What I haven't been able figure out is how to load the
> > right fabric driver.
>
> Do not use the device tree to load the fabric driver!
Heh, technically you can't use the device tree to load any device
drivers, it's just a data structure. :-)
You probably mean "don't use the of_platform bus to load the fabric
driver". He still needs to use the data in the device tree to decide
what fabric drivers to use. of_platform_bus would be awkward to use
for this because the node describing the fabric doesn't cleanly sit on
any particular bus (ie. it describes the board; it does not describe
the device).
In this case; it probably is appropriate to have the platform code
instantiate a platform_device for the fabric (instead of an
of_platform device) which the fabric driver can bind against.
Another option is to explicitly call of_platform_device_create in the
platform code on the fabric node (which should be a child of the root
node) so that you can have an of_platform_bus fabric driver.
Cheers,
g.
>
> The layout of the hardware and the relationship between the I2S, I2C, codec,
> and whatever device is determined by *both* the fabric driver and the device
> tree. The information about the devices itself, and *some* information about
> their relationship is stored in the device tree. Everything else is in the
> fabric driver.
>
> The design of the device tree is already locked in stone, so to speak. The DT
> can only store what it is allowed to store. If there's something more that
> you need, you'll have to put it in the fabric driver.
>
> If I weren't on vacation this week, I'd email you my code. It's almost done
> and it demonstrates what I'm thinking.
>
> --
> Timur Tabi
> Linux Kernel Developer @ Freescale
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH] hugetlb: follow_hugetlb_page for write access
From: Hoang-Nam Nguyen @ 2007-11-19 15:25 UTC (permalink / raw)
To: Adam Litke; +Cc: linuxppc-dev, Andrew Morton, Ken Chen, linux-kernel
In-Reply-To: <20071107195142.13505.49398.stgit@kernel>
On Wednesday 07 November 2007 20:51, Adam Litke wrote:
>
> When calling get_user_pages(), a write flag is passed in by the caller to
> indicate if write access is required on the faulted-in pages. Currently,
> follow_hugetlb_page() ignores this flag and always faults pages for
> read-only access. This can cause data corruption because a device driver
> that calls get_user_pages() with write set will not expect COW faults to
> occur on the returned pages.
>
> This patch passes the write flag down to follow_hugetlb_page() and makes
> sure hugetlb_fault() is called with the right write_access parameter.
>
> Signed-off-by: Adam Litke <agl@us.ibm.com>
Apologize for this late response.
Tested on 2.6.23 with ehca and mthca. It works like a charm for me.
Thanks!
Nam
^ permalink raw reply
* Re: Revisited, audio codec device tree entries.
From: Jon Loeliger @ 2007-11-19 15:15 UTC (permalink / raw)
To: Timur Tabi; +Cc: PowerPC dev list
In-Reply-To: <4741A56D.9050808@freescale.com>
So, like, the other day Timur Tabi mumbled:
>
> If I weren't on vacation this week, I'd email you my code. It's almost done
> and it demonstrates what I'm thinking.
Are the margins of this paper too small for your proof?
jdl
^ permalink raw reply
* Re: Oops: of_platform_serial_probe
From: Timur Tabi @ 2007-11-19 15:04 UTC (permalink / raw)
To: Clemens Koller; +Cc: linuxppc-embedded
In-Reply-To: <474193B8.9060007@anagramm.de>
Clemens Koller wrote:
> I guess I didn't configure the OF serial right in the .dts but it still
> shouldn't crash. My .config is attached.
Try disabling CONFIG_SERIAL_OF_PLATFORM. I don't think it means what you
think it means.
--
Timur Tabi
Linux Kernel Developer @ Freescale
^ permalink raw reply
* Re: Revisited, audio codec device tree entries.
From: Timur Tabi @ 2007-11-19 15:02 UTC (permalink / raw)
To: Jon Smirl; +Cc: PowerPC dev list
In-Reply-To: <9e4733910711181010q50c08d2ek8413af74d58cf0ce@mail.gmail.com>
Jon Smirl wrote:
> In the ALSA SOC model the i2s, codec and ac97 drivers are all generic.
> A fabric driver tells specifically how a generic codec is wired into
> the board. What I haven't been able figure out is how to load the
> right fabric driver.
Do not use the device tree to load the fabric driver!
The layout of the hardware and the relationship between the I2S, I2C, codec,
and whatever device is determined by *both* the fabric driver and the device
tree. The information about the devices itself, and *some* information about
their relationship is stored in the device tree. Everything else is in the
fabric driver.
The design of the device tree is already locked in stone, so to speak. The DT
can only store what it is allowed to store. If there's something more that
you need, you'll have to put it in the fabric driver.
If I weren't on vacation this week, I'd email you my code. It's almost done
and it demonstrates what I'm thinking.
--
Timur Tabi
Linux Kernel Developer @ Freescale
^ permalink raw reply
* How can I make the DDR momory storage bigger than 256M?
From: 郭劲 @ 2007-11-19 14:42 UTC (permalink / raw)
To: linuxppc-embedded
Hi,friends,
I used the U-Boot 1.2.0 on MPC8360E board. My board work nomally with 256M DDR-1
Memory. If I change the DDR-1 up to 1GB, the U-Boot can visit the DDR address
range from 0x00000000 to 0x10000000, but it can not visit the address bigger than
0x10000000,I wat wondering why? Thanks.
Using the 1GB DDR-1, I can write the u-boot to my flash by CodeWarrior.
Follow is the information that when I test the DDR on u-boot, the start address is
0x1ff00000, the end address is 0x20000000;it was dead when visit the DDR.
U-Boot 1.2.0 (Nov 19 2007 - 20:55:34) MPC83XX
CPU: e300c1, MPC8360E, Rev: 20 at 528 MHz, CSB: 264 MHz
Board: Freescale MPC8360EMDS
I2C: ready
DRAM:
DIMM type:
SPD size: 128
EEPROM size: 256
Memory type: 7
Row addr: 13
Column addr: 11
# of rows: 2
Row density: 128
# of banks: 4
Data width: 64
Chip width: 8
Refresh rate: 82
CAS latencies: 18
Write latencies: 02
tRP: 60
tRCD: 60
cs0_bnds = 0x0000001f
cs0_config = 0x80000103
cs1_bnds = 0x0020003f
cs1_config = 0x80000103
DDR:bar=0x00000000
DDR:ar=0x8000001d
DDR: caslat SPD bit is 4
DDR:Module maximum data rate is: 400Mhz
DDR:Effective data rate is: 266Mhz
DDR:The MSB 1 of CAS Latency is: 4
DDR: effective data rate is 266 MHz
DDR: caslat SPD bit is 4, controller field is 0x5
DDR:timing_cfg_1=0x26252727
DDR:timing_cfg_2=0x00004841
DDR DIMM: data bus width is 64 bit without ECC
DDR:sdram_mode=0x00000032
DDR: sdram_mode2 = 0x00000000
DDR:sdram_interval=0x04060100
DDR:sdram_clk_cntl=0x02000000
DDRC ECC mode: OFF
DDR:sdram_cfg=0xc2008000
SDRAM on Local Bus: 64 MB
DDR RAM: 1024 MB
DDR test phase 1:
(dead)
^ permalink raw reply
* Re: Revisited, audio codec device tree entries.
From: Timur Tabi @ 2007-11-19 14:57 UTC (permalink / raw)
To: Matt Sealey; +Cc: PowerPC dev list
In-Reply-To: <4740C0E3.5080704@genesi-usa.com>
Matt Sealey wrote:
> Jon Smirl wrote:
>> The codec-fabric node was just being used to trigger the loading of
>> the platform specific driver.
>
> Just remember one thing.
>
> 1) the term "fabric" when coined for audio drivers is a new, ALSA SoC
> specific term. It isn't relevant for anything but ALSA SoC drivers.
Earlier this year, when I started working on an ASoC driver, the fabric driver
was called a "machine driver".
> 2) this device tree stuff will end up in more than Linux device trees
Sorry, I don't understand. The device trees are technically OS-independent,
so technically there's no such thing as a "Linux device tree". In addition,
the current master repository for device trees happens to be the Linux kernel,
so I'm not sure where else device trees are going to be.
> 3) you're going to piss off Open Firmware developers by specifying
> very Linux-specific features in a device tree the same way Apple
> pissed off Linux developers by encoding MacOS X-specific features in
> the device tree.
The current device trees have left their OF roots behind. Sure, we try to
conform as much as possible, but they're not OF trees any more.
> Audio driver control like this has to be very specific for a good
> reason; you can do it a billion ways to Sunday. I'd suggest basically
> that if you must control a device in a way that needs to be defined by
> a device which can change address (either dynamically on boot or by
> board design change - per revision, for example, or with a change of
> controller) then simply use the device tree to report this address
> so that you can have the same basic fabric driver (all in Linux) which
> can handle minor modifications of your board design.
My position is that the "fabric" driver should be loaded as a normal device
tree and it should use the device tree to pick up some data to help it
instantiate the other drivers. I'll be posting the code to my PowerPC ASoC
driver in a couple weeks.
> If you require the codec to be subservient to some "fabric" then I
The codec is subservient to a bus (sometimes multiple buses), which is why it
is a child to bus nodes.
--
Timur Tabi
Linux Kernel Developer @ Freescale
^ permalink raw reply
* Oops: of_platform_serial_probe
From: Clemens Koller @ 2007-11-19 13:46 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 2758 bytes --]
Hi, I just ran into this in paulus.git:
=> bootm fe500000
## Booting image at fe500000 ...
Image Name: Linux-2.6.24-rc2-ge6a5c27f
Created: 2007-11-19 13:06:38 UTC
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 1951325 Bytes = 1.9 MB
Load Address: 00400000
Entry Point: 004005b0
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
x3'
Generic RTC Driver v1.07
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled
serial8250.0: ttyS0 at MMIO 0xe0004500 (irq = 42) is a 16550A
console [ttyS0] enabled
serial8250.0: ttyS1 at MMIO 0xe0004600 (irq = 42) is a 16550A
Unable to handle kernel paging request for data at address 0x00000000
Faulting instruction address: 0xc018f03c
Oops: Kernel access of bad area, sig: 11 [#1]
MPC85xx ADS
Modules linked in:
NIP: c018f03c LR: c018f00c CTR: c00127b4
REGS: c0821cf0 TRAP: 0300 Not tainted (2.6.24-rc2-ge6a5c27f)
MSR: 00029000 <EE,ME> CR: 42022088 XER: 20000000
DEAR: 00000000, ESR: 00000000
TASK = c081e000[1] 'swapper' THREAD: c0820000
GPR00: b1000000 c0821da0 c081e000 c0833e10 00000004 c0821d80 c03d3064 c05eea80
GPR08: 00000200 00000002 0000002a 13ab6680 82022042 00000000 c03318a4 c033188c
GPR16: c0331908 c03318f0 c03a0e30 c0331930 c033191c 007fff00 0ffeccbc c03a0000
GPR24: c0821dc4 00000000 00000003 c0934cf8 cffffba8 00000000 c0833e00 c07fdc6c
NIP [c018f03c] of_platform_serial_probe+0x118/0x1e4
LR [c018f00c] of_platform_serial_probe+0xe8/0x1e4
Call Trace:
[c0821da0] [c018f00c] of_platform_serial_probe+0xe8/0x1e4 (unreliable)
[c0821e70] [c0210c1c] of_platform_device_probe+0x5c/0x84
[c0821e90] [c0192f30] driver_probe_device+0xf4/0x238
[c0821eb0] [c01932a4] __driver_attach+0xcc/0xf8
[c0821ed0] [c019254c] bus_for_each_dev+0x58/0x94
[c0821f00] [c0192cec] driver_attach+0x24/0x34
[c0821f10] [c0191e18] bus_add_driver+0xac/0x21c
[c0821f30] [c0193524] driver_register+0x58/0xa0
[c0821f40] [c0008178] of_register_platform_driver+0x64/0x80
[c0821f50] [c03953d4] of_platform_serial_init+0x18/0x28
[c0821f60] [c03831f4] kernel_init+0xd0/0x2b0
[c0821ff0] [c000d980] kernel_thread+0x44/0x60
Instruction dump:
38000002 9061002c 9801003a 387e0010 93410088 3c00b100 393affff 2b89000f
817f0000 9001007c 9061009c 91610030 <80190000> 813f0000 54002036 7d290396
Kernel panic - not syncing: Attempted to kill init!
Please note the "x3'" trash characters right in the beginning.
I guess I didn't configure the OF serial right in the .dts but it still
shouldn't crash. My .config is attached.
Regards,
--
Clemens Koller
__________________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Straße 45/1
Linhof Werksgelände
D-81379 München
Tel.089-741518-50
Fax 089-741518-19
http://www.anagramm-technology.com
[-- Attachment #2: config-paul-2.6.24-rc2-git --]
[-- Type: text/plain, Size: 29927 bytes --]
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.24-rc2
# Mon Nov 19 13:33:54 2007
#
# CONFIG_PPC64 is not set
#
# Processor support
#
# CONFIG_6xx is not set
CONFIG_PPC_85xx=y
# CONFIG_PPC_8xx is not set
# CONFIG_40x is not set
# CONFIG_44x is not set
# CONFIG_E200 is not set
CONFIG_85xx=y
CONFIG_E500=y
CONFIG_BOOKE=y
CONFIG_FSL_BOOKE=y
# CONFIG_PHYS_64BIT is not set
CONFIG_SPE=y
# CONFIG_PPC_MM_SLICES 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
CONFIG_ARCH_HAS_ILOG2_U32=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_GENERIC_FIND_NEXT_BIT=y
# CONFIG_ARCH_NO_VIRT_TO_BUS is not set
CONFIG_PPC=y
CONFIG_EARLY_PRINTK=y
CONFIG_GENERIC_NVRAM=y
CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_PPC_OF=y
CONFIG_OF=y
CONFIG_PPC_UDBG_16550=y
# CONFIG_GENERIC_TBSYNC is not set
CONFIG_AUDIT_ARCH=y
CONFIG_GENERIC_BUG=y
CONFIG_DEFAULT_UIMAGE=y
# CONFIG_PPC_DCR_NATIVE is not set
# CONFIG_PPC_DCR_MMIO is not set
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
#
# General setup
#
CONFIG_EXPERIMENTAL=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
CONFIG_BSD_PROCESS_ACCT=y
# CONFIG_BSD_PROCESS_ACCT_V3 is not set
# CONFIG_TASKSTATS is not set
# CONFIG_USER_NS is not set
# CONFIG_AUDIT is not set
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=14
# CONFIG_CGROUPS is not set
CONFIG_FAIR_GROUP_SCHED=y
CONFIG_FAIR_USER_SCHED=y
# CONFIG_FAIR_CGROUP_SCHED is not set
CONFIG_SYSFS_DEPRECATED=y
CONFIG_RELAY=y
# CONFIG_BLK_DEV_INITRD is not set
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SYSCTL=y
# CONFIG_EMBEDDED is not set
CONFIG_SYSCTL_SYSCALL=y
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y
CONFIG_KALLSYMS_EXTRA_PASS=y
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_ANON_INODES=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_SLUB_DEBUG=y
# CONFIG_SLAB is not set
CONFIG_SLUB=y
# CONFIG_SLOB is not set
CONFIG_RT_MUTEXES=y
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
# CONFIG_MODULE_FORCE_UNLOAD is not set
# CONFIG_MODVERSIONS is not set
# CONFIG_MODULE_SRCVERSION_ALL is not set
# CONFIG_KMOD is not set
CONFIG_BLOCK=y
# CONFIG_LBD is not set
# CONFIG_BLK_DEV_IO_TRACE is not set
# CONFIG_LSF is not set
# CONFIG_BLK_DEV_BSG is not set
#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
CONFIG_DEFAULT_AS=y
# CONFIG_DEFAULT_DEADLINE is not set
# CONFIG_DEFAULT_CFQ is not set
# CONFIG_DEFAULT_NOOP is not set
CONFIG_DEFAULT_IOSCHED="anticipatory"
#
# Platform support
#
# CONFIG_PPC_MPC52xx is not set
# CONFIG_PPC_MPC5200 is not set
# CONFIG_PPC_CELL is not set
# CONFIG_PPC_CELL_NATIVE is not set
# CONFIG_PQ2ADS is not set
CONFIG_MPC8540_ADS=y
# CONFIG_MPC8560_ADS is not set
# CONFIG_MPC85xx_CDS is not set
# CONFIG_MPC85xx_MDS is not set
# CONFIG_MPC85xx_DS is not set
CONFIG_MPC8540=y
CONFIG_MPC85xx=y
CONFIG_MPIC=y
# CONFIG_MPIC_WEIRD is not set
# CONFIG_PPC_I8259 is not set
# CONFIG_PPC_RTAS is not set
# CONFIG_MMIO_NVRAM is not set
# CONFIG_PPC_MPC106 is not set
# CONFIG_PPC_970_NAP is not set
# CONFIG_PPC_INDIRECT_IO is not set
# CONFIG_GENERIC_IOMAP is not set
# CONFIG_CPU_FREQ is not set
# CONFIG_CPM2 is not set
# CONFIG_FSL_ULI1575 is not set
#
# Kernel options
#
# CONFIG_HIGHMEM is not set
CONFIG_TICK_ONESHOT=y
# CONFIG_NO_HZ is not set
CONFIG_HIGH_RES_TIMERS=y
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
# CONFIG_HZ_100 is not set
CONFIG_HZ_250=y
# CONFIG_HZ_300 is not set
# CONFIG_HZ_1000 is not set
CONFIG_HZ=250
CONFIG_PREEMPT_NONE=y
# CONFIG_PREEMPT_VOLUNTARY is not set
# CONFIG_PREEMPT is not set
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_MISC=y
CONFIG_MATH_EMULATION=y
CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y
CONFIG_ARCH_FLATMEM_ENABLE=y
CONFIG_ARCH_POPULATES_NODE_MAP=y
CONFIG_SELECT_MEMORY_MODEL=y
CONFIG_FLATMEM_MANUAL=y
# CONFIG_DISCONTIGMEM_MANUAL is not set
# CONFIG_SPARSEMEM_MANUAL is not set
CONFIG_FLATMEM=y
CONFIG_FLAT_NODE_MEM_MAP=y
# CONFIG_SPARSEMEM_STATIC is not set
# CONFIG_SPARSEMEM_VMEMMAP_ENABLE is not set
CONFIG_SPLIT_PTLOCK_CPUS=4
# CONFIG_RESOURCES_64BIT is not set
CONFIG_ZONE_DMA_FLAG=1
CONFIG_BOUNCE=y
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 is not set
CONFIG_WANT_DEVICE_TREE=y
CONFIG_DEVICE_TREE="mpc8540ads.dts"
CONFIG_ISA_DMA_API=y
#
# Bus options
#
CONFIG_ZONE_DMA=y
CONFIG_PPC_INDIRECT_PCI=y
CONFIG_FSL_SOC=y
CONFIG_FSL_PCI=y
CONFIG_PCI=y
CONFIG_PCI_DOMAINS=y
CONFIG_PCI_SYSCALL=y
# CONFIG_PCIEPORTBUS is not set
CONFIG_ARCH_SUPPORTS_MSI=y
# CONFIG_PCI_MSI is not set
CONFIG_PCI_LEGACY=y
CONFIG_PCI_DEBUG=y
# CONFIG_PCCARD is not set
# CONFIG_HOTPLUG_PCI is not set
#
# Advanced setup
#
# CONFIG_ADVANCED_OPTIONS is not set
#
# Default settings for advanced configuration options are used
#
CONFIG_HIGHMEM_START=0xfe000000
CONFIG_LOWMEM_SIZE=0x30000000
CONFIG_KERNEL_START=0xc0000000
CONFIG_TASK_SIZE=0xc0000000
CONFIG_BOOT_LOAD=0x00800000
#
# Networking
#
CONFIG_NET=y
#
# Networking options
#
CONFIG_PACKET=y
# CONFIG_PACKET_MMAP is not set
CONFIG_UNIX=y
CONFIG_XFRM=y
CONFIG_XFRM_USER=y
# CONFIG_XFRM_SUB_POLICY is not set
# CONFIG_XFRM_MIGRATE is not set
# CONFIG_NET_KEY is not set
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
# CONFIG_IP_ADVANCED_ROUTER is not set
CONFIG_IP_FIB_HASH=y
CONFIG_IP_PNP=y
CONFIG_IP_PNP_DHCP=y
CONFIG_IP_PNP_BOOTP=y
# CONFIG_IP_PNP_RARP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
# CONFIG_IP_MROUTE is not set
# CONFIG_ARPD is not set
CONFIG_SYN_COOKIES=y
# CONFIG_INET_AH is not set
# CONFIG_INET_ESP is not set
# CONFIG_INET_IPCOMP is not set
# CONFIG_INET_XFRM_TUNNEL is not set
CONFIG_INET_TUNNEL=y
CONFIG_INET_XFRM_MODE_TRANSPORT=y
CONFIG_INET_XFRM_MODE_TUNNEL=y
CONFIG_INET_XFRM_MODE_BEET=y
# CONFIG_INET_LRO is not set
CONFIG_INET_DIAG=y
CONFIG_INET_TCP_DIAG=y
# CONFIG_TCP_CONG_ADVANCED is not set
CONFIG_TCP_CONG_CUBIC=y
CONFIG_DEFAULT_TCP_CONG="cubic"
# CONFIG_TCP_MD5SIG is not set
CONFIG_IPV6=y
# CONFIG_IPV6_PRIVACY is not set
# CONFIG_IPV6_ROUTER_PREF is not set
# CONFIG_IPV6_OPTIMISTIC_DAD is not set
# CONFIG_INET6_AH is not set
# CONFIG_INET6_ESP is not set
# CONFIG_INET6_IPCOMP is not set
# CONFIG_IPV6_MIP6 is not set
# CONFIG_INET6_XFRM_TUNNEL is not set
# CONFIG_INET6_TUNNEL is not set
CONFIG_INET6_XFRM_MODE_TRANSPORT=y
CONFIG_INET6_XFRM_MODE_TUNNEL=y
CONFIG_INET6_XFRM_MODE_BEET=y
# CONFIG_INET6_XFRM_MODE_ROUTEOPTIMIZATION is not set
CONFIG_IPV6_SIT=y
# CONFIG_IPV6_TUNNEL is not set
# CONFIG_IPV6_MULTIPLE_TABLES is not set
# CONFIG_NETWORK_SECMARK is not set
# CONFIG_NETFILTER is not set
# CONFIG_IP_DCCP is not set
# CONFIG_IP_SCTP is not set
# CONFIG_TIPC is not set
# CONFIG_ATM is not set
# CONFIG_BRIDGE is not set
# CONFIG_VLAN_8021Q is not set
# CONFIG_DECNET is not set
# CONFIG_LLC2 is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set
# CONFIG_NET_SCHED is not set
#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_HAMRADIO is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
# CONFIG_AF_RXRPC is not set
#
# Wireless
#
# CONFIG_CFG80211 is not set
# CONFIG_WIRELESS_EXT is not set
# CONFIG_MAC80211 is not set
# CONFIG_IEEE80211 is not set
# CONFIG_RFKILL is not set
# CONFIG_NET_9P is not set
#
# Device Drivers
#
#
# Generic Driver Options
#
CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
# CONFIG_FW_LOADER is not set
CONFIG_DEBUG_DRIVER=y
# CONFIG_DEBUG_DEVRES is not set
# CONFIG_SYS_HYPERVISOR is not set
# CONFIG_CONNECTOR is not set
# CONFIG_MTD is not set
CONFIG_OF_DEVICE=y
# CONFIG_PARPORT is not set
CONFIG_BLK_DEV=y
# CONFIG_BLK_DEV_FD is not set
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_DAC960 is not set
# CONFIG_BLK_DEV_UMEM is not set
# CONFIG_BLK_DEV_COW_COMMON is not set
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 is not set
# CONFIG_CDROM_PKTCDVD is not set
# CONFIG_ATA_OVER_ETH is not set
# CONFIG_MISC_DEVICES is not set
# CONFIG_IDE is not set
#
# SCSI device support
#
# CONFIG_RAID_ATTRS is not set
CONFIG_SCSI=y
CONFIG_SCSI_DMA=y
# CONFIG_SCSI_TGT is not set
# CONFIG_SCSI_NETLINK is not set
CONFIG_SCSI_PROC_FS=y
#
# SCSI support type (disk, tape, CD-ROM)
#
CONFIG_BLK_DEV_SD=y
# CONFIG_CHR_DEV_ST is not set
# CONFIG_CHR_DEV_OSST is not set
# CONFIG_BLK_DEV_SR is not set
# CONFIG_CHR_DEV_SG is not set
# CONFIG_CHR_DEV_SCH is not set
#
# Some SCSI devices (e.g. CD jukebox) support multiple LUNs
#
# CONFIG_SCSI_MULTI_LUN is not set
# CONFIG_SCSI_CONSTANTS is not set
# CONFIG_SCSI_LOGGING is not set
# CONFIG_SCSI_SCAN_ASYNC is not set
CONFIG_SCSI_WAIT_SCAN=m
#
# SCSI Transports
#
# CONFIG_SCSI_SPI_ATTRS is not set
# CONFIG_SCSI_FC_ATTRS is not set
# CONFIG_SCSI_ISCSI_ATTRS is not set
# CONFIG_SCSI_SAS_LIBSAS is not set
# CONFIG_SCSI_SRP_ATTRS is not set
# CONFIG_SCSI_LOWLEVEL is not set
CONFIG_ATA=y
# CONFIG_ATA_NONSTANDARD is not set
# CONFIG_SATA_AHCI is not set
# CONFIG_SATA_SVW is not set
# CONFIG_ATA_PIIX is not set
# CONFIG_SATA_MV is not set
# CONFIG_SATA_NV is not set
# CONFIG_PDC_ADMA is not set
# CONFIG_SATA_QSTOR is not set
CONFIG_SATA_PROMISE=y
# CONFIG_SATA_SX4 is not set
# CONFIG_SATA_SIL is not set
# CONFIG_SATA_SIL24 is not set
# CONFIG_SATA_SIS is not set
# CONFIG_SATA_ULI is not set
# CONFIG_SATA_VIA is not set
# CONFIG_SATA_VITESSE is not set
# CONFIG_SATA_INIC162X is not set
# CONFIG_PATA_ALI is not set
# CONFIG_PATA_AMD is not set
# CONFIG_PATA_ARTOP is not set
# CONFIG_PATA_ATIIXP is not set
# CONFIG_PATA_CMD640_PCI is not set
# CONFIG_PATA_CMD64X is not set
# CONFIG_PATA_CS5520 is not set
# CONFIG_PATA_CS5530 is not set
# CONFIG_PATA_CYPRESS is not set
# CONFIG_PATA_EFAR is not set
# CONFIG_ATA_GENERIC is not set
# CONFIG_PATA_HPT366 is not set
# CONFIG_PATA_HPT37X is not set
# CONFIG_PATA_HPT3X2N is not set
# CONFIG_PATA_HPT3X3 is not set
# CONFIG_PATA_IT821X is not set
# CONFIG_PATA_IT8213 is not set
# CONFIG_PATA_JMICRON is not set
# CONFIG_PATA_TRIFLEX is not set
# CONFIG_PATA_MARVELL is not set
# CONFIG_PATA_MPIIX is not set
# CONFIG_PATA_OLDPIIX is not set
# CONFIG_PATA_NETCELL is not set
# CONFIG_PATA_NS87410 is not set
# CONFIG_PATA_NS87415 is not set
# CONFIG_PATA_OPTI is not set
# CONFIG_PATA_OPTIDMA is not set
# CONFIG_PATA_PDC_OLD is not set
# CONFIG_PATA_RADISYS is not set
# CONFIG_PATA_RZ1000 is not set
# CONFIG_PATA_SC1200 is not set
# CONFIG_PATA_SERVERWORKS is not set
CONFIG_PATA_PDC2027X=y
# CONFIG_PATA_SIL680 is not set
# CONFIG_PATA_SIS is not set
# CONFIG_PATA_VIA is not set
# CONFIG_PATA_WINBOND is not set
# CONFIG_MD is not set
# CONFIG_FUSION is not set
#
# IEEE 1394 (FireWire) support
#
# CONFIG_FIREWIRE is not set
# CONFIG_IEEE1394 is not set
# CONFIG_I2O is not set
# CONFIG_MACINTOSH_DRIVERS is not set
CONFIG_NETDEVICES=y
CONFIG_NETDEVICES_MULTIQUEUE=y
CONFIG_DUMMY=y
# CONFIG_BONDING is not set
# CONFIG_MACVLAN is not set
# CONFIG_EQUALIZER is not set
# CONFIG_TUN is not set
# CONFIG_VETH is not set
# CONFIG_IP1000 is not set
# CONFIG_ARCNET is not set
CONFIG_PHYLIB=y
#
# MII PHY device drivers
#
CONFIG_MARVELL_PHY=y
# CONFIG_DAVICOM_PHY is not set
# CONFIG_QSEMI_PHY is not set
CONFIG_LXT_PHY=y
# CONFIG_CICADA_PHY is not set
# CONFIG_VITESSE_PHY is not set
# CONFIG_SMSC_PHY is not set
# CONFIG_BROADCOM_PHY is not set
# CONFIG_ICPLUS_PHY is not set
# CONFIG_FIXED_PHY is not set
CONFIG_MDIO_BITBANG=y
CONFIG_NET_ETHERNET=y
CONFIG_MII=y
# CONFIG_HAPPYMEAL is not set
# CONFIG_SUNGEM is not set
# CONFIG_CASSINI is not set
# CONFIG_NET_VENDOR_3COM is not set
# CONFIG_NET_TULIP is not set
# CONFIG_HP100 is not set
# CONFIG_IBM_NEW_EMAC_ZMII is not set
# CONFIG_IBM_NEW_EMAC_RGMII is not set
# CONFIG_IBM_NEW_EMAC_TAH is not set
# CONFIG_IBM_NEW_EMAC_EMAC4 is not set
# CONFIG_NET_PCI is not set
# CONFIG_B44 is not set
CONFIG_NETDEV_1000=y
# CONFIG_ACENIC is not set
# CONFIG_DL2K is not set
# CONFIG_E1000 is not set
# CONFIG_E1000E is not set
# CONFIG_NS83820 is not set
# CONFIG_HAMACHI is not set
# CONFIG_YELLOWFIN is not set
# CONFIG_R8169 is not set
# 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
CONFIG_GIANFAR=y
CONFIG_GFAR_NAPI=y
# CONFIG_QLA3XXX is not set
# CONFIG_ATL1 is not set
# CONFIG_NETDEV_10000 is not set
# CONFIG_TR is not set
#
# Wireless LAN
#
# 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 is not set
# CONFIG_WAN is not set
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
# CONFIG_PPP is not set
# CONFIG_SLIP is not set
# CONFIG_NET_FC is not set
# CONFIG_SHAPER is not set
# CONFIG_NETCONSOLE is not set
# CONFIG_NETPOLL is not set
# CONFIG_NET_POLL_CONTROLLER is not set
# CONFIG_ISDN is not set
# CONFIG_PHONE is not set
#
# Input device support
#
CONFIG_INPUT=y
# CONFIG_INPUT_FF_MEMLESS is not set
# CONFIG_INPUT_POLLDEV is not set
#
# Userland interfaces
#
CONFIG_INPUT_MOUSEDEV=y
CONFIG_INPUT_MOUSEDEV_PSAUX=y
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
# CONFIG_INPUT_JOYDEV is not set
# CONFIG_INPUT_EVDEV is not set
# 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=y
# CONFIG_TOUCHSCREEN_ADS7846 is not set
# CONFIG_TOUCHSCREEN_FUJITSU is not set
# CONFIG_TOUCHSCREEN_GUNZE is not set
# CONFIG_TOUCHSCREEN_ELO is not set
# CONFIG_TOUCHSCREEN_MTOUCH is not set
# CONFIG_TOUCHSCREEN_MK712 is not set
# CONFIG_TOUCHSCREEN_PENMOUNT is not set
# CONFIG_TOUCHSCREEN_TOUCHRIGHT is not set
# CONFIG_TOUCHSCREEN_TOUCHWIN is not set
# CONFIG_TOUCHSCREEN_UCB1400 is not set
CONFIG_TOUCHSCREEN_USB_COMPOSITE=y
CONFIG_TOUCHSCREEN_USB_EGALAX=y
CONFIG_TOUCHSCREEN_USB_PANJIT=y
CONFIG_TOUCHSCREEN_USB_3M=y
CONFIG_TOUCHSCREEN_USB_ITM=y
CONFIG_TOUCHSCREEN_USB_ETURBO=y
CONFIG_TOUCHSCREEN_USB_GUNZE=y
CONFIG_TOUCHSCREEN_USB_DMC_TSC10=y
CONFIG_TOUCHSCREEN_USB_IRTOUCH=y
CONFIG_TOUCHSCREEN_USB_IDEALTEK=y
CONFIG_TOUCHSCREEN_USB_GENERAL_TOUCH=y
CONFIG_TOUCHSCREEN_USB_GOTOP=y
# CONFIG_INPUT_MISC is not set
#
# Hardware I/O ports
#
CONFIG_SERIO=y
# CONFIG_SERIO_I8042 is not set
CONFIG_SERIO_SERPORT=y
# CONFIG_SERIO_PCIPS2 is not set
# CONFIG_SERIO_RAW is not set
# CONFIG_GAMEPORT is not set
#
# Character devices
#
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
CONFIG_VT_HW_CONSOLE_BINDING=y
# CONFIG_SERIAL_NONSTANDARD is not set
#
# Serial drivers
#
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_SERIAL_8250_PCI=y
CONFIG_SERIAL_8250_NR_UARTS=4
CONFIG_SERIAL_8250_RUNTIME_UARTS=4
# CONFIG_SERIAL_8250_EXTENDED is not set
CONFIG_SERIAL_8250_SHARE_IRQ=y
#
# Non-8250 serial port support
#
# CONFIG_SERIAL_UARTLITE is not set
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
# CONFIG_SERIAL_JSM is not set
CONFIG_SERIAL_OF_PLATFORM=y
CONFIG_UNIX98_PTYS=y
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=256
# CONFIG_IPMI_HANDLER is not set
# CONFIG_HW_RANDOM is not set
# CONFIG_NVRAM is not set
CONFIG_GEN_RTC=y
# CONFIG_GEN_RTC_X is not set
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set
# CONFIG_RAW_DRIVER is not set
# CONFIG_TCG_TPM is not set
CONFIG_DEVPORT=y
CONFIG_I2C=y
CONFIG_I2C_BOARDINFO=y
CONFIG_I2C_CHARDEV=y
#
# I2C Algorithms
#
CONFIG_I2C_ALGOBIT=y
# CONFIG_I2C_ALGOPCF is not set
# CONFIG_I2C_ALGOPCA is not set
#
# I2C Hardware Bus support
#
# CONFIG_I2C_ALI1535 is not set
# CONFIG_I2C_ALI1563 is not set
# CONFIG_I2C_ALI15X3 is not set
# CONFIG_I2C_AMD756 is not set
# CONFIG_I2C_AMD8111 is not set
# CONFIG_I2C_I801 is not set
# CONFIG_I2C_I810 is not set
# CONFIG_I2C_PIIX4 is not set
CONFIG_I2C_MPC=y
# CONFIG_I2C_NFORCE2 is not set
# CONFIG_I2C_OCORES is not set
# CONFIG_I2C_PARPORT_LIGHT is not set
# CONFIG_I2C_PROSAVAGE is not set
# CONFIG_I2C_SAVAGE4 is not set
# CONFIG_I2C_SIMTEC is not set
# CONFIG_I2C_SIS5595 is not set
# CONFIG_I2C_SIS630 is not set
# 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
#
# Miscellaneous I2C Chip support
#
# CONFIG_SENSORS_DS1337 is not set
# CONFIG_SENSORS_DS1374 is not set
# CONFIG_DS1682 is not set
# CONFIG_SENSORS_EEPROM is not set
# CONFIG_SENSORS_PCF8574 is not set
# CONFIG_SENSORS_PCA9539 is not set
# CONFIG_SENSORS_PCF8591 is not set
# CONFIG_SENSORS_M41T00 is not set
# CONFIG_SENSORS_MAX6875 is not set
# CONFIG_SENSORS_TSL2550 is not set
# CONFIG_I2C_DEBUG_CORE is not set
# CONFIG_I2C_DEBUG_ALGO is not set
# CONFIG_I2C_DEBUG_BUS is not set
# CONFIG_I2C_DEBUG_CHIP is not set
#
# SPI support
#
CONFIG_SPI=y
CONFIG_SPI_DEBUG=y
CONFIG_SPI_MASTER=y
#
# SPI Master Controller Drivers
#
CONFIG_SPI_BITBANG=y
#
# SPI Protocol Masters
#
CONFIG_SPI_AT25=y
CONFIG_SPI_SPIDEV=y
# CONFIG_SPI_TLE62X0 is not set
# CONFIG_W1 is not set
# CONFIG_POWER_SUPPLY is not set
CONFIG_HWMON=y
# CONFIG_HWMON_VID is not set
# CONFIG_SENSORS_AD7418 is not set
# CONFIG_SENSORS_ADM1021 is not set
# CONFIG_SENSORS_ADM1025 is not set
# CONFIG_SENSORS_ADM1026 is not set
# CONFIG_SENSORS_ADM1029 is not set
# CONFIG_SENSORS_ADM1031 is not set
# CONFIG_SENSORS_ADM9240 is not set
# CONFIG_SENSORS_ADT7470 is not set
# CONFIG_SENSORS_ATXP1 is not set
# CONFIG_SENSORS_DS1621 is not set
# CONFIG_SENSORS_F71805F is not set
# CONFIG_SENSORS_F71882FG is not set
# CONFIG_SENSORS_F75375S is not set
# CONFIG_SENSORS_GL518SM is not set
# CONFIG_SENSORS_GL520SM is not set
# CONFIG_SENSORS_IT87 is not set
# CONFIG_SENSORS_LM63 is not set
# CONFIG_SENSORS_LM70 is not set
CONFIG_SENSORS_LM75=y
# CONFIG_SENSORS_LM77 is not set
# CONFIG_SENSORS_LM78 is not set
# CONFIG_SENSORS_LM80 is not set
# CONFIG_SENSORS_LM83 is not set
# CONFIG_SENSORS_LM85 is not set
# CONFIG_SENSORS_LM87 is not set
# CONFIG_SENSORS_LM90 is not set
# CONFIG_SENSORS_LM92 is not set
# CONFIG_SENSORS_LM93 is not set
# CONFIG_SENSORS_MAX1619 is not set
CONFIG_SENSORS_MAX6650=y
# CONFIG_SENSORS_PC87360 is not set
# CONFIG_SENSORS_PC87427 is not set
# CONFIG_SENSORS_SIS5595 is not set
# CONFIG_SENSORS_DME1737 is not set
# CONFIG_SENSORS_SMSC47M1 is not set
# CONFIG_SENSORS_SMSC47M192 is not set
# CONFIG_SENSORS_SMSC47B397 is not set
# CONFIG_SENSORS_THMC50 is not set
# CONFIG_SENSORS_VIA686A is not set
# CONFIG_SENSORS_VT1211 is not set
# CONFIG_SENSORS_VT8231 is not set
# CONFIG_SENSORS_W83781D is not set
# CONFIG_SENSORS_W83791D is not set
# CONFIG_SENSORS_W83792D is not set
# CONFIG_SENSORS_W83793 is not set
# CONFIG_SENSORS_W83L785TS is not set
# CONFIG_SENSORS_W83627HF is not set
# CONFIG_SENSORS_W83627EHF is not set
CONFIG_HWMON_DEBUG_CHIP=y
# CONFIG_WATCHDOG is not set
#
# Sonics Silicon Backplane
#
CONFIG_SSB_POSSIBLE=y
# CONFIG_SSB is not set
#
# Multifunction device drivers
#
# CONFIG_MFD_SM501 is not set
#
# Multimedia devices
#
# CONFIG_VIDEO_DEV is not set
# CONFIG_DVB_CORE is not set
# CONFIG_DAB is not set
#
# Graphics support
#
# CONFIG_AGP is not set
# CONFIG_DRM is not set
# CONFIG_VGASTATE is not set
# CONFIG_VIDEO_OUTPUT_CONTROL is not set
# CONFIG_FB is not set
# CONFIG_BACKLIGHT_LCD_SUPPORT is not set
#
# Display device support
#
# CONFIG_DISPLAY_SUPPORT is not set
#
# Console display driver support
#
CONFIG_VGA_CONSOLE=y
# CONFIG_VGACON_SOFT_SCROLLBACK is not set
CONFIG_DUMMY_CONSOLE=y
#
# Sound
#
# CONFIG_SOUND is not set
CONFIG_HID_SUPPORT=y
CONFIG_HID=y
# CONFIG_HID_DEBUG is not set
# CONFIG_HIDRAW 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 is not set
CONFIG_USB_SUPPORT=y
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB_ARCH_HAS_OHCI=y
CONFIG_USB_ARCH_HAS_EHCI=y
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=y
CONFIG_USB_EHCI_ROOT_HUB_TT=y
# CONFIG_USB_EHCI_TT_NEWSCHED is not set
# CONFIG_USB_ISP116X_HCD is not set
CONFIG_USB_OHCI_HCD=y
CONFIG_USB_OHCI_HCD_PPC_OF=y
CONFIG_USB_OHCI_HCD_PPC_OF_BE=y
# CONFIG_USB_OHCI_HCD_PPC_OF_LE is not set
CONFIG_USB_OHCI_HCD_PCI=y
CONFIG_USB_OHCI_BIG_ENDIAN_DESC=y
CONFIG_USB_OHCI_BIG_ENDIAN_MMIO=y
CONFIG_USB_OHCI_LITTLE_ENDIAN=y
# CONFIG_USB_UHCI_HCD is not set
# 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_ISD200 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_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=y
# CONFIG_USB_SERIAL_CONSOLE is not set
CONFIG_USB_SERIAL_GENERIC=y
# CONFIG_USB_SERIAL_AIRCABLE is not set
# CONFIG_USB_SERIAL_AIRPRIME is not set
# CONFIG_USB_SERIAL_ARK3116 is not set
# CONFIG_USB_SERIAL_BELKIN is not set
# CONFIG_USB_SERIAL_CH341 is not set
# CONFIG_USB_SERIAL_WHITEHEAT is not set
# CONFIG_USB_SERIAL_DIGI_ACCELEPORT is not set
# CONFIG_USB_SERIAL_CP2101 is not set
# CONFIG_USB_SERIAL_CYPRESS_M8 is not set
# CONFIG_USB_SERIAL_EMPEG is not set
CONFIG_USB_SERIAL_FTDI_SIO=y
# CONFIG_USB_SERIAL_FUNSOFT is not set
# CONFIG_USB_SERIAL_VISOR is not set
# CONFIG_USB_SERIAL_IPAQ is not set
# CONFIG_USB_SERIAL_IR is not set
# CONFIG_USB_SERIAL_EDGEPORT is not set
# CONFIG_USB_SERIAL_EDGEPORT_TI is not set
# CONFIG_USB_SERIAL_GARMIN is not set
# CONFIG_USB_SERIAL_IPW is not set
# CONFIG_USB_SERIAL_KEYSPAN_PDA is not set
# CONFIG_USB_SERIAL_KEYSPAN is not set
# CONFIG_USB_SERIAL_KLSI is not set
# CONFIG_USB_SERIAL_KOBIL_SCT is not set
# CONFIG_USB_SERIAL_MCT_U232 is not set
# CONFIG_USB_SERIAL_MOS7720 is not set
# CONFIG_USB_SERIAL_MOS7840 is not set
# CONFIG_USB_SERIAL_NAVMAN is not set
CONFIG_USB_SERIAL_PL2303=y
# CONFIG_USB_SERIAL_OTI6858 is not set
# CONFIG_USB_SERIAL_HP4X is not set
# CONFIG_USB_SERIAL_SAFE is not set
# CONFIG_USB_SERIAL_SIERRAWIRELESS is not set
# CONFIG_USB_SERIAL_TI is not set
# CONFIG_USB_SERIAL_CYBERJACK is not set
# CONFIG_USB_SERIAL_XIRCOM is not set
# CONFIG_USB_SERIAL_OPTION is not set
# CONFIG_USB_SERIAL_OMNINET is not set
# CONFIG_USB_SERIAL_DEBUG 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
# CONFIG_MMC is not set
# CONFIG_NEW_LEDS is not set
# CONFIG_INFINIBAND is not set
# CONFIG_EDAC is not set
CONFIG_RTC_LIB=y
CONFIG_RTC_CLASS=y
CONFIG_RTC_HCTOSYS=y
CONFIG_RTC_HCTOSYS_DEVICE="rtc0"
# CONFIG_RTC_DEBUG is not set
#
# RTC interfaces
#
CONFIG_RTC_INTF_SYSFS=y
CONFIG_RTC_INTF_PROC=y
CONFIG_RTC_INTF_DEV=y
# CONFIG_RTC_INTF_DEV_UIE_EMUL is not set
# CONFIG_RTC_DRV_TEST is not set
#
# I2C RTC drivers
#
CONFIG_RTC_DRV_DS1307=y
# CONFIG_RTC_DRV_DS1374 is not set
# CONFIG_RTC_DRV_DS1672 is not set
# CONFIG_RTC_DRV_MAX6900 is not set
# CONFIG_RTC_DRV_RS5C372 is not set
# CONFIG_RTC_DRV_ISL1208 is not set
# CONFIG_RTC_DRV_X1205 is not set
CONFIG_RTC_DRV_PCF8563=y
# CONFIG_RTC_DRV_PCF8583 is not set
# CONFIG_RTC_DRV_M41T80 is not set
#
# SPI RTC drivers
#
# CONFIG_RTC_DRV_RS5C348 is not set
# CONFIG_RTC_DRV_MAX6902 is not set
#
# Platform RTC drivers
#
# CONFIG_RTC_DRV_CMOS is not set
# CONFIG_RTC_DRV_DS1553 is not set
# CONFIG_RTC_DRV_STK17TA8 is not set
# CONFIG_RTC_DRV_DS1742 is not set
# CONFIG_RTC_DRV_M48T86 is not set
# CONFIG_RTC_DRV_M48T59 is not set
# CONFIG_RTC_DRV_V3020 is not set
#
# on-CPU RTC drivers
#
#
# Userspace I/O
#
# CONFIG_UIO is not set
#
# File systems
#
CONFIG_EXT2_FS=y
# CONFIG_EXT2_FS_XATTR is not set
# CONFIG_EXT2_FS_XIP is not set
CONFIG_EXT3_FS=y
CONFIG_EXT3_FS_XATTR=y
# CONFIG_EXT3_FS_POSIX_ACL is not set
# CONFIG_EXT3_FS_SECURITY is not set
# CONFIG_EXT4DEV_FS is not set
CONFIG_JBD=y
CONFIG_FS_MBCACHE=y
CONFIG_REISERFS_FS=y
# CONFIG_REISERFS_CHECK is not set
# CONFIG_REISERFS_PROC_INFO is not set
# CONFIG_REISERFS_FS_XATTR is not set
# CONFIG_JFS_FS is not set
# CONFIG_FS_POSIX_ACL is not set
# CONFIG_XFS_FS is not set
# CONFIG_GFS2_FS is not set
# CONFIG_OCFS2_FS is not set
# CONFIG_MINIX_FS is not set
# CONFIG_ROMFS_FS is not set
CONFIG_INOTIFY=y
CONFIG_INOTIFY_USER=y
# CONFIG_QUOTA is not set
CONFIG_DNOTIFY=y
# CONFIG_AUTOFS_FS is not set
# CONFIG_AUTOFS4_FS is not set
# CONFIG_FUSE_FS is not set
#
# CD-ROM/DVD Filesystems
#
# CONFIG_ISO9660_FS is not set
# CONFIG_UDF_FS is not set
#
# DOS/FAT/NT Filesystems
#
# CONFIG_MSDOS_FS is not set
# CONFIG_VFAT_FS is not set
# CONFIG_NTFS_FS is not set
#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_PROC_SYSCTL=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
# CONFIG_TMPFS_POSIX_ACL is not set
# CONFIG_HUGETLB_PAGE is not set
# CONFIG_CONFIGFS_FS is not set
#
# Miscellaneous filesystems
#
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_HFSPLUS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
# CONFIG_CRAMFS is not set
# CONFIG_VXFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set
CONFIG_NETWORK_FILESYSTEMS=y
CONFIG_NFS_FS=y
CONFIG_NFS_V3=y
# CONFIG_NFS_V3_ACL is not set
# CONFIG_NFS_V4 is not set
# CONFIG_NFS_DIRECTIO is not set
CONFIG_NFSD=y
# CONFIG_NFSD_V3 is not set
CONFIG_NFSD_TCP=y
# CONFIG_ROOT_NFS is not set
CONFIG_LOCKD=y
CONFIG_LOCKD_V4=y
CONFIG_EXPORTFS=y
CONFIG_NFS_COMMON=y
CONFIG_SUNRPC=y
# CONFIG_SUNRPC_BIND34 is not set
# CONFIG_RPCSEC_GSS_KRB5 is not set
# CONFIG_RPCSEC_GSS_SPKM3 is not set
# CONFIG_SMB_FS is not set
# CONFIG_CIFS is not set
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set
# CONFIG_AFS_FS is not set
#
# Partition Types
#
# CONFIG_PARTITION_ADVANCED is not set
CONFIG_MSDOS_PARTITION=y
# CONFIG_NLS is not set
# CONFIG_DLM is not set
# CONFIG_UCC_SLOW is not set
#
# Library routines
#
CONFIG_BITREVERSE=y
# CONFIG_CRC_CCITT is not set
# CONFIG_CRC16 is not set
# CONFIG_CRC_ITU_T is not set
CONFIG_CRC32=y
# CONFIG_CRC7 is not set
# CONFIG_LIBCRC32C is not set
CONFIG_PLIST=y
CONFIG_HAS_IOMEM=y
CONFIG_HAS_IOPORT=y
CONFIG_HAS_DMA=y
# CONFIG_INSTRUMENTATION is not set
#
# Kernel hacking
#
# CONFIG_PRINTK_TIME is not set
CONFIG_ENABLE_WARN_DEPRECATED=y
CONFIG_ENABLE_MUST_CHECK=y
CONFIG_MAGIC_SYSRQ=y
# CONFIG_UNUSED_SYMBOLS is not set
# CONFIG_DEBUG_FS is not set
# CONFIG_HEADERS_CHECK is not set
CONFIG_DEBUG_KERNEL=y
# CONFIG_DEBUG_SHIRQ is not set
CONFIG_DETECT_SOFTLOCKUP=y
# CONFIG_SCHED_DEBUG is not set
# CONFIG_SCHEDSTATS is not set
# CONFIG_TIMER_STATS is not set
# CONFIG_SLUB_DEBUG_ON is not set
# CONFIG_DEBUG_RT_MUTEXES is not set
# CONFIG_RT_MUTEX_TESTER is not set
# CONFIG_DEBUG_SPINLOCK is not set
CONFIG_DEBUG_MUTEXES=y
# CONFIG_DEBUG_SPINLOCK_SLEEP is not set
# CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set
# CONFIG_DEBUG_KOBJECT is not set
CONFIG_DEBUG_BUGVERBOSE=y
CONFIG_DEBUG_INFO=y
# CONFIG_DEBUG_VM is not set
# CONFIG_DEBUG_LIST is not set
# CONFIG_DEBUG_SG is not set
# CONFIG_FORCED_INLINING is not set
# CONFIG_BOOT_PRINTK_DELAY is not set
# CONFIG_RCU_TORTURE_TEST is not set
# CONFIG_FAULT_INJECTION is not set
# CONFIG_SAMPLES is not set
# CONFIG_DEBUG_STACKOVERFLOW is not set
# CONFIG_DEBUG_STACK_USAGE is not set
# CONFIG_DEBUG_PAGEALLOC is not set
CONFIG_DEBUGGER=y
# CONFIG_XMON is not set
# CONFIG_BDI_SWITCH is not set
# CONFIG_PPC_EARLY_DEBUG is not set
#
# Security options
#
# CONFIG_KEYS is not set
# CONFIG_SECURITY is not set
# CONFIG_SECURITY_FILE_CAPABILITIES is not set
# CONFIG_CRYPTO is not set
# CONFIG_PPC_CLOCK is not set
^ permalink raw reply
* Re: Revisited, audio codec device tree entries.
From: Segher Boessenkool @ 2007-11-19 12:48 UTC (permalink / raw)
To: David Gibson; +Cc: PowerPC dev list
In-Reply-To: <20071119001209.GD20794@localhost.localdomain>
> Matt, the various properties you list do not mean what you think they
> mean.
>
> name - should be named according to the generic names convention.
> It's pretty much arbitrary, meant for human readability of the device
> tree. Drivers should not depend on it (some do, historically, but new
> drivers and trees should not).
It is not arbitrary, there is a single well-defined name for every
common
"class" of device. It _is_ machine-readable (but shouldn't be used for
driver matching, indeed -- it says nothing about the programming model).
> device_type - indicates the open firmware method interface for the
> device.
Not "method interface", just "interface".
> Therefore, meaningless in flattened trees.
Even in flat trees, a "device_type" of for example "block" indicates the
node will have the required properties for that device type, for example
"block-size". Such properties are perfectly useful. OTOH, it isn't
very
useful to search for device with a specific device type from within the
kernel, since it currently has no firmware interaction to speak of (flat
trees don't interact, and the kernel kills "real" OF dead as soon as
possible).
> No new driver should use this.
Not without very good rationalisation, anyway.
> compatible - *this* is the one for driver selection. It describes the
> hardware level interface(s) of the device.
>
> model - usually just for debugging / diagnosis / human-readable
> purposes, describes exact model / revision of the hardware. It can be
> used to enable driver quirks / workarounds for when various devices
> are supposed to be compatible (as encoded in 'compatible') but
> aren't, due to hardware bugs. However, you should never aim to use it
> this way in design.
Yeah. Any non-workaround value a driver would derive from "model" is
usually better described using a separate property.
Segher
^ 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