* Re: [PATCH v7 3/3] [POWERPC] MPC832x_RDB: update dts to use SPI1in QE, register mmc_spi stub
From: Segher Boessenkool @ 2007-09-06 14:29 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, Timur Tabi
In-Reply-To: <20070906141901.GC16353@ld0162-tx32.am.freescale.net>
>>> AFAIK, there is no other standard data structure that could take
>>> place
>>> of the par_io nodes in the DTS.
>>
>> The device tree is not a dumping ground for all your "I need some
>> standard data structure" stuff. Use an XML file if you have to ;-)
>
> Bah. How about we just remove the nodes you don't want to see before
> passing it on to the kernel? :-)
That is fine. In fact, LinuxBIOS will probably do similar things.
Since this node will have one user only, feel free to create a
format for it that is as simple as possible for what you need
it for, there's no need to follow any conventions (as long as
you can create a _real_ tree from it later ;-) )
Segher
^ permalink raw reply
* Re: [PATCH v7 3/3] [POWERPC] MPC832x_RDB: update dts to use SPI1in QE, register mmc_spi stub
From: Segher Boessenkool @ 2007-09-06 14:25 UTC (permalink / raw)
To: avorontsov; +Cc: linuxppc-dev, Timur Tabi
In-Reply-To: <20070905114023.GA4072@localhost.localdomain>
>> The kernel is of course welcome to do so -- and this may be a valid
>> reason to attach pin information to specific device nodes, if it
>> actually
>> saves a non-negligible amount of power -- but it's not a reason to
>> force
>> the kernel to have to care by not setting things up in the firmware.
>
> Well, I might agree here. But to me it seems unnatural that I have to
> upgrade bootloader to use SPI -- I can already boot the kernel.
>
> Bootloader's duties are finished when kernel booted. And if already
> running kernel is unable to do something, it's not bootloader's fault
> anymore, but kernel's itself.
If the firmware failed to properly initialise the system into some
stable state, then yeah, it _is_ the firmware's fault.
> And from the practical point of view, upgrading bootloader is much
> more error-prone and risky for the users without proper rescue tools
> and knowledge.
Yeah well -- it's hardly rocket science to make this a very
reliable and safe procedure.
> Kernel is easier to deploy after bug-fixing (and
> wrongly set up GPIO pin is a bug). That's why I tend to like "dumb
> and simple" bootloaders and do not hang up too much duties on it.
That's one of the ways it is done -- have a "dumb and simple"
recovery firmware that can install new versions of the "main"
firmware.
Anyway, we're getting very far off-topic now :-)
Segher
^ permalink raw reply
* Re: [PATCH v7 3/3] [POWERPC] MPC832x_RDB: update dts to use SPI1in QE, register mmc_spi stub
From: Segher Boessenkool @ 2007-09-06 14:19 UTC (permalink / raw)
To: avorontsov; +Cc: linuxppc-dev, Timur Tabi
In-Reply-To: <20070904104750.GA32451@localhost.localdomain>
>> _and system GPIOs_ :-)
>
> Yup, firmware should set up gpios, to make initial kernel boot.
> After that, kernel can and should manage GPIOs.
Sure. But only the GPIOs it _does_ need to toggle, not the ones
that have to be fixed to a certain value (like everything that is
described in the par_io nodes now).
Devices that really _use_ some GPIO, should use some generic GPIO
binding in the device tree, and the generic GPIO subsystem in the
kernel.
> Few examples.
[some good examples of why GPIOs can be useful at runtime snipped]
> At the same time I agree: doing gpio setup in the board file isn't a
> great solution, just like doing it in the device tree. But hard-code
> gpio setup in the firmware is much worse and short-sighted approach.
It is the correct solution for 99.99% of GPIOs: every GPIO needs to
either be set to some fixed configuration (and value), dictated by
the board design; or at least it needs to be initialised to something
that results in a stable system ;-)
Segher
^ permalink raw reply
* Re: [PATCH v7 3/3] [POWERPC] MPC832x_RDB: update dts to use SPI1in QE, register mmc_spi stub
From: Scott Wood @ 2007-09-06 14:19 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, Timur Tabi
In-Reply-To: <3299c27fe2551315c6f5ecff3569f2e0@kernel.crashing.org>
On Thu, Sep 06, 2007 at 04:13:56PM +0200, Segher Boessenkool wrote:
> > AFAIK, there is no other standard data structure that could take place
> > of the par_io nodes in the DTS.
>
> The device tree is not a dumping ground for all your "I need some
> standard data structure" stuff. Use an XML file if you have to ;-)
Bah. How about we just remove the nodes you don't want to see before
passing it on to the kernel? :-)
-Scott
^ permalink raw reply
* Re: [PATCH 8/9] 8xx: Adder 875 support
From: Scott Wood @ 2007-09-06 14:16 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <85281ec227e35a9e466e68e3fdc7e6ef@kernel.crashing.org>
On Thu, Sep 06, 2007 at 04:08:43PM +0200, Segher Boessenkool wrote:
> >+/ {
> >+ model = "Analogue & Micro Adder MPC875";
>
> This should probably be just "MPC875".
There's more than one board with an MPC875 on it.
-Scott
^ permalink raw reply
* PCI I/O space -- reg or ranges?
From: Scott Wood @ 2007-09-06 14:15 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, David Gibson
In-Reply-To: <22dc6fa3382b591fe721c1b9dee88097@kernel.crashing.org>
On Thu, Sep 06, 2007 at 03:56:38PM +0200, Segher Boessenkool wrote:
> > Err... huh? The legacy IO space is assigned a block of addresses in
> > 3-word "OF-PCI-space by the PCI binding. When that is translated into
> > an MMIO range by the bridge, there's no reason that can't be encoded
> > into the ranges property.
>
> Sure, it can be encoded like that. But does it make sense?
> You cannot use legacy I/O space as normal memory space.
Why does it not make sense? I'm not sure what you mean by using it as
"normal memory space", but if the PCI bridge does a straightforward
linear mapping of I/O into memory space (like most non-x86 bridges do),
it seems to make sense to me to reuse the existing ranges mechanism
rather than require each driver to have extra glue code.
And given the substantial impact of such a change on many existing device
trees and the kernel, it should probably be brought up in a thread with a
subject that will clue people in to what is being discussed, rather than
buried in "AmigaOne device tree source v2".
BTW, memory space could be non-linear as well, so should we stop using
ranges for that? For an example, see the old Alphas which lacked
byte/word I/O, and thus used a weird sparse mapping to control the size
of the access that went out over the bus.
> Also, from a driver standpoint, a PHB driver needs to find out
> two main things about the bridge: a) how and where to generate
> config cycles; b) how and where to generate legacy I/O cycles.
> It is told "how" by the "compatible" property, and "where" by
> the "reg" property, normally.
All it currently needs to do is a), provided it's a normal linear mapping
and the I/O space is in ranges.
-Scott
^ permalink raw reply
* Re: [PATCH v7 3/3] [POWERPC] MPC832x_RDB: update dts to use SPI1in QE, register mmc_spi stub
From: Segher Boessenkool @ 2007-09-06 14:13 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev
In-Reply-To: <46DCCE19.6050401@freescale.com>
>> This kind of thing is typically hardcoded into the firmware (just like
>> the device tree is) -- just put it somewhere _next to_ the device
>> tree,
>> not _in_ it.
>
> What is next to the device tree?
"Anywhere else in the firmware".
> AFAIK, there is no other standard data structure that could take place
> of the par_io nodes in the DTS.
The device tree is not a dumping ground for all your "I need some
standard data structure" stuff. Use an XML file if you have to ;-)
> I agree with your points, Segher, but replacing the par_io node with a
> bunch of par_io_config_pin() calls in the kernel is not really an
> improvement, I think. Until we migrate the QE pin configuration code
> to U-boot, I suggest that we keep the device tree structure as-is and
> continue to use it for new code. That way, it will all stay in one
> place.
Sure, some migration plan is in order, things won't change overnight.
That doesn't mean you don't need to start planning _now_ ;-)
Segher
^ permalink raw reply
* Re: OF NDFC
From: Segher Boessenkool @ 2007-09-06 14:06 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <20070906084109.315544ea@zod.rchland.ibm.com>
>> AFAIK, NAND flash is autodetected by reading it's ID at runtime, so
>> there should be no need for flash bindings.
>
> Well, I'm not really sure. CFI and JEDEC can both be probed as well,
> and we're working on a binding there.
JEDEC cannot be reliably probed. CFI can be _almost_ probed,
you need to know the interleaving though, to handle some edge
cases. Oh, and you need to know it _is_ CFI, of course.
> But if you think you can come up
> with a driver for NDFC that doesn't require some kind of device tree
> description of the devices it controls, then by all means go for it.
I don't know whether NAND can be reliably probed; most "standard"
NAND devices can be, but I don't know what standards are involved
here, if any. We'll need some MTD people help here.
OTOH, it definitely is better to describe only the NAND controller
and not the devices, than to put nothing at all in the device tree.
We had this same situation with NOR flash before, already...
Segher
^ permalink raw reply
* Re: "atomic" 64-bit math on 32-bit ppc's?
From: Segher Boessenkool @ 2007-09-06 14:09 UTC (permalink / raw)
To: Scott Wood; +Cc: ppc-dev
In-Reply-To: <20070906134354.GA16153@ld0162-tx32.am.freescale.net>
>> Either way, it's a bit late to change this, no?
>
> Sure, I was just whining due to having been bitten by this sort of bug
> in
> the past. :-)
Write a song about it, it's therapeutical it seems!
Segher
^ permalink raw reply
* Re: [PATCH 8/9] 8xx: Adder 875 support
From: Segher Boessenkool @ 2007-09-06 14:08 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20070905192820.GG32398@ld0162-tx32.am.freescale.net>
> +/ {
> + model = "Analogue & Micro Adder MPC875";
This should probably be just "MPC875".
Segher
^ permalink raw reply
* Re: [RFC] AmigaOne device tree source v2
From: Segher Boessenkool @ 2007-09-06 14:00 UTC (permalink / raw)
To: Gerhard Pircher; +Cc: linuxppc-dev, David Gibson
In-Reply-To: <20070905115419.321990@gmx.net>
>> The node should have a compatible
>> property which is sufficient to select the right bridge driver.
> Yeah, I defined a compatible = "mai,articias"; property in the pci
> node.
> Are there any naming conventions (maybe lower case only)?
It's conventional for the part behind the comma to be lower-case
only, yes. There are more stringent rules for the part before
the comma (the manufacturer part). What is "mai"?
Segher
^ permalink raw reply
* Re: [RFC] AmigaOne device tree source v2
From: Segher Boessenkool @ 2007-09-06 13:56 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20070905024805.GE17189@localhost.localdomain>
> That looks totally bogus. Unlike Segher, I think there are a few
> cases where overlapping reg and ranges can make sense
That's not unlike me -- I may have lower tolerance for it though :-)
> (PCI bridges
> where config space is accessed indirectly via MMIO registers which lie
> in the legacy ISA IO space is an example).
That's a good example yes.
> But this doesn't look like
> such a case - it just looks like whoever did the device tree
> misunderstood the distinction between reg and ranges.
Indeed.
>>> PCI legacy I/O is not direct mapped: there is no legacy I/O on a
>>> PowerPC system bus. So, it can not be mentioned in the "ranges"
>>> property, but the PHB registers used to access it should be shown
>>> in the "reg" property. It could be a simple linear window (it
>>> sounds like it is here?), but it could for example also be
>>> implemented
>>> via an address/data register pair.
>
> Err... huh? The legacy IO space is assigned a block of addresses in
> 3-word "OF-PCI-space by the PCI binding. When that is translated into
> an MMIO range by the bridge, there's no reason that can't be encoded
> into the ranges property.
Sure, it can be encoded like that. But does it make sense?
You cannot use legacy I/O space as normal memory space.
On an arch like x86, where "I/O addresses" exist on the system
bus as well, it would make sense, since you can translate I/O
addresses to I/O addresses that way (except on x86 even it cannot
be done either, since I/O addresses cannot be encoded on the root
bus -- at least not in existing device trees. There is no official
x86 binding yet though).
Also, from a driver standpoint, a PHB driver needs to find out
two main things about the bridge: a) how and where to generate
config cycles; b) how and where to generate legacy I/O cycles.
It is told "how" by the "compatible" property, and "where" by
the "reg" property, normally.
But yes, you _can_ use "ranges" for this purpose on PHBs where
legacy I/O is linearly mapped. It just doesn't make much sense.
The binding for your specific PHB should tell you what to do.
>> Only the Pegasos I and the AmigaOne use this PCI bridge. I guess it
>> should
>> be enough to check for the board type, but a compatible property
>> doesn't
>> hurt.
>
> The whole damn point of the device tree is to avoid using this kind of
> non-local information "I know what the board type is over there, so it
> must be this PCI bridge over here". The node should have a compatible
> property which is sufficient to select the right bridge driver.
Yeah. _Even if_ the kernel decides to cheat by hardcoding certain
board information, that doesn't mean the device tree shouldn't
encode that info, too.
> I think this is typically badly done at the moment, simply because PCI
> has historically been set up by the platform code, rather than by a
> "host bridge driver" in the mould of other drivers. I don't see that
> changing real soon, but that doesn't mean we shouldn't at least put
> enough information in the device tree to make it possible.
Exactly.
Segher
^ permalink raw reply
* Re: "atomic" 64-bit math on 32-bit ppc's?
From: Scott Wood @ 2007-09-06 13:43 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: ppc-dev
In-Reply-To: <e1d766f8390851a75a6fe83800484ab7@kernel.crashing.org>
On Thu, Sep 06, 2007 at 03:21:36PM +0200, Segher Boessenkool wrote:
> >>That's wrong if lock is assigned to r0, you should use
> >>a "b" constraint to avoid this. Same for atomic_dec below.
> >
> >GCC should really have removed r0 from the "r" class (it isn't truly a
> >general-purpose register), and had a different class meaning
> >"r"-plus-r0.
>
> Nah, GPR0 _is_ a general purpose register, you just cannot use all
> general purpose registers as base registers ;-)
Bah.
> Either way, it's a bit late to change this, no?
Sure, I was just whining due to having been bitten by this sort of bug in
the past. :-)
-Scott
^ permalink raw reply
* Re: [RFC] AmigaOne device tree source v2
From: Segher Boessenkool @ 2007-09-06 13:41 UTC (permalink / raw)
To: Gerhard Pircher; +Cc: linuxppc-dev, david
In-Reply-To: <20070904122040.276440@gmx.net>
> BTW: It looks like the Pegasos II device tree defines device_type =
> "spi"
> for the IDE controller. Is that correct?
There is no standard binding for an "spi" device type. I have no
idea which of various "SPI" kind of devices is meant here; and none
of the ones I know of have anything to do with ATA anyway.
In short, it probably is incorrect.
Also, in general, you shouldn't use "device_type" in flat device
trees (the main exceptions are: some/most bus nodes, cpu nodes,
some other "standard" nodes).
>> There is no such thing as "interrupt 14 and 15" on PCI. You can use
>> the interrupt mapping recommended practice to show two interrupts
>> (and their polarity, and how they are routed to the relevant interrupt
>> controller) in the IDE node.
> But I'll still need a quirk in the IDE driver, because it doesn't make
> use of any interrupt routing information in the device tree. If so, I
> can omit the whole IDE controller device node and simply rely on the
> IDE driver's probe functions and the Pegasos IDE IRQ quirk.
> I wonder how this issue will be handled for libata and the via-pata
> driver, since IIRC this one doesn't contain the Pegasos IDE IRQ quirk.
I imagine the ata quirk would ask the arch or platform code about
the interrupts used; it in turn can query the device tree.
Segher
^ permalink raw reply
* Re: OF NDFC
From: Josh Boyer @ 2007-09-06 13:41 UTC (permalink / raw)
To: Valentine Barshak; +Cc: linuxppc-dev
In-Reply-To: <46E000E0.4080203@ru.mvista.com>
On Thu, 06 Sep 2007 17:30:08 +0400
Valentine Barshak <vbarshak@ru.mvista.com> wrote:
> AFAIK, NAND flash is autodetected by reading it's ID at runtime, so
> there should be no need for flash bindings.
Well, I'm not really sure. CFI and JEDEC can both be probed as well,
and we're working on a binding there. But if you think you can come up
with a driver for NDFC that doesn't require some kind of device tree
description of the devices it controls, then by all means go for it.
josh
^ permalink raw reply
* Re: [RFC] AmigaOne device tree source v2
From: Segher Boessenkool @ 2007-09-06 13:36 UTC (permalink / raw)
To: Gerhard Pircher; +Cc: linuxppc-dev, david
In-Reply-To: <20070904114945.303440@gmx.net>
>> PCI memory space sits on the PCI bus, not on the PCI host bridge,
>> so is not part of "reg" but is part of "ranges" here, since it is
>> direct mapped into the host's address space.
> That's right, but what about this example here (from a Pegasos II):
>
> /proc/device-tree/pci@80000000:
> reg 80000000 40000000
> ranges 01000000 00000000 00000000 fe000000 00000000 00010000
> 02000000 00000000 80000000 80000000 00000000 40000000
That's just broken.
> AFAIU the reg property overlaps the ranges property for the PCI memory
> space from 0x80000000 to 0xC0000000 or the CPU address space at the
> same location!?
reg = < something for pci config space >,
< fe000000 10000 >
ranges = < 02000000 0 80000000 80000000 0 40000000 >
>> PCI legacy I/O is not direct mapped: there is no legacy I/O on a
>> PowerPC system bus. So, it can not be mentioned in the "ranges"
>> property, but the PHB registers used to access it should be shown
>> in the "reg" property. It could be a simple linear window (it
>> sounds like it is here?), but it could for example also be implemented
>> via an address/data register pair.
> Yes, it is a simple linear address window. I'll remove its address
> range
> from the reg property.
No, please remove it from the "ranges" property, instead.
>> The order of the "reg" entries depends on the exact model of PCI
>> bridge, so a device binding for it has to be written.
> Only the Pegasos I and the AmigaOne use this PCI bridge. I guess it
> should
> be enough to check for the board type, but a compatible property
> doesn't
> hurt.
Please always use "compatible" to probe any devices.
Segher
^ permalink raw reply
* Re: [RFC] AmigaOne device tree source v2
From: Segher Boessenkool @ 2007-09-06 13:31 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20070904002745.GB20549@localhost.localdomain>
> Hrm.. IIRC, it is permissible under Linux to only include device nodes
> for those PCI devices where something must be specified which can't be
> proved via PCI.
It is. It isn't clear (to me, at least) which properties are
required in a PCI node that exists for e.g. interrupt reasons
only; or how the kernel decides if a PCI node is a "real" PCI
node (i.e., using the PCI binding), or an "empty" PCI node.
Segher
^ permalink raw reply
* Re: OF NDFC
From: Valentine Barshak @ 2007-09-06 13:30 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <20070906081732.079bc45d@zod.rchland.ibm.com>
Josh Boyer wrote:
> On Thu, 6 Sep 2007 15:06:03 +0200
> Segher Boessenkool <segher@kernel.crashing.org> wrote:
>
>>>> Is anybody working on the device-tree-aware ppc 44x NAND flash
>>>> controller (ndfc) driver?
>>> Not to my knowledge. We sort of need a decent binding for NAND flash
>>> in general first.
>> Not really. You can put the NAND controller in the device
>> tree without describing the NAND flash itself -- and for that,
>> you only need a "name", "compatible", "reg", and maybe some
>> interrupt stuff.
>
> He said driver. To test a driver, you'd need the binding for both the
> controller, and the NAND flash it controls. Otherwise, the driver
> isn't going to do much :).
>
> josh
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
AFAIK, NAND flash is autodetected by reading it's ID at runtime, so
there should be no need for flash bindings.
Thanks,
Valentine.
^ permalink raw reply
* [NEWBIE] Interrupt-problem mpc5200
From: S. Fricke @ 2007-09-06 13:30 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 1262 bytes --]
Hello all.
What are the steps to configure an MPC500B-Board to react on an IRQ (2)?
I have written a test-driver with this code-snippets, but the prozessor
hangs when loading the driver.
my __init-function looks like:
static int __init mod_init( void )
{
volatile static struct mpc52xx_intr __iomem *intr;
u32 intr_ctrl;
// ...
printk( "intmod.ko: interrupt init ");
if (request_irq(MPC52xx_IRQ2, intmod_isr, IRQF_SHARED , "intmod",
INTMOD_IRQ_BOARD) == -EBUSY)
printk("KO\n");
else
printk("OK\n");
intr = ioremap(MPC52xx_MBAR+MPC52xx_INTR_OFFSET, MPC52xx_INTR_SIZE);
// read - modify - write
intr_ctrl = in_be32(&intr->ctrl);
intr_ctrl &= 0xfff3ffff;
intr_ctrl |= 0x00080200;
out_be32(&intr->ctrl, intr_ctrl); // ERROR!
if(intr) iounmap(intr);
// ...
}
On the Line, marked with "ERROR!" the prozessor hangs and the kernel drops
out.
TIA: Silvio
--
-- S. Fricke ----------------------------- MAILTO:silvio.fricke@gmail.com --
Diplom-Informatiker (FH)
Linux-Entwicklung JABBER: fricke@jabber.org
----------------------------------------------------------------------------
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Document and implement an improved flash device binding
From: Segher Boessenkool @ 2007-09-06 13:28 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20070905025907.GG17189@localhost.localdomain>
>>> + - bank-width : Width (in bytes) of the flash bank. Equal to
>>> the
>>> + device width times the number of interleaved chips.
>>> + - device-width : (optional) Width of a single flash chip. If
>>> + omitted, assumed to be equal to 'bank-width'.
>>
>> Let's have bank-width optional instead, it's more natural
>> that way for the common case of just one chip. Or, you can
>> say that either is optional.
>
> No, I'm disinclined to do that since bank-width is the primary bit of
> information that the driver needs.
Bzzzzt. That's not what the device tree is about; it should
describe the hardware, it shouldn't be just a config file for
the current Linux drivers.
Besides, like I said, for the common case where your flash
chips aren't interleaved, it makes way more sense to talk
about device-width than it does to call it bank-width.
>>> + OpenBIOS@0 {
>>
>> This show immediately why node name = partition name won't
>> work out. You're not supposed to start a node name with a
>> capital like this.
>
> According to which?
It's just convention, really.
OTOH, spaces and commas and colons and a whole bunch of special
chars are completely disallowed here, so you need...
> Nonetheless, I've added a label property,
...something like that :-)
Segher
^ permalink raw reply
* Re: "atomic" 64-bit math on 32-bit ppc's?
From: Segher Boessenkool @ 2007-09-06 13:21 UTC (permalink / raw)
To: Scott Wood; +Cc: ppc-dev
In-Reply-To: <20070904184810.GG18280@ld0162-tx32.am.freescale.net>
>> That's wrong if lock is assigned to r0, you should use
>> a "b" constraint to avoid this. Same for atomic_dec below.
>
> GCC should really have removed r0 from the "r" class (it isn't truly a
> general-purpose register), and had a different class meaning
> "r"-plus-r0.
Nah, GPR0 _is_ a general purpose register, you just cannot use all
general purpose registers as base registers ;-)
Either way, it's a bit late to change this, no?
Segher
^ permalink raw reply
* Re: OF NDFC
From: Josh Boyer @ 2007-09-06 13:17 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <b9fb2fad5d6b04a07996416842df7f72@kernel.crashing.org>
On Thu, 6 Sep 2007 15:06:03 +0200
Segher Boessenkool <segher@kernel.crashing.org> wrote:
> >> Is anybody working on the device-tree-aware ppc 44x NAND flash
> >> controller (ndfc) driver?
> >
> > Not to my knowledge. We sort of need a decent binding for NAND flash
> > in general first.
>
> Not really. You can put the NAND controller in the device
> tree without describing the NAND flash itself -- and for that,
> you only need a "name", "compatible", "reg", and maybe some
> interrupt stuff.
He said driver. To test a driver, you'd need the binding for both the
controller, and the NAND flash it controls. Otherwise, the driver
isn't going to do much :).
josh
^ permalink raw reply
* Re: OF NDFC
From: Segher Boessenkool @ 2007-09-06 13:06 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <20070905160008.201a243a@vader.jdub.homelinux.org>
>> Is anybody working on the device-tree-aware ppc 44x NAND flash
>> controller (ndfc) driver?
>
> Not to my knowledge. We sort of need a decent binding for NAND flash
> in general first.
Not really. You can put the NAND controller in the device
tree without describing the NAND flash itself -- and for that,
you only need a "name", "compatible", "reg", and maybe some
interrupt stuff.
Segher
^ permalink raw reply
* RE: Gianfar - MPC8541 - tx buffer overrun errors
From: Joyeau Sylvain @ 2007-09-06 8:43 UTC (permalink / raw)
To: Shriram Janardhan, linuxppc-embedded
Hi Shriram,
Try to increase the DEFAULT_TX_RING_SIZE parameter in gianfar.h.
Enabling NAPI mechanism should have no effect on transmission side.
Cheers
--
sj
________________________________
From:
linuxppc-embedded-bounces+sylvain.joyeau=3Dthomson.net@ozlabs.org
[mailto:linuxppc-embedded-bounces+sylvain.joyeau=3Dthomson.net@ozlabs.org=
]
On Behalf Of Shriram Janardhan
Sent: jeudi 6 septembre 2007 03:49
To: linuxppc-embedded@ozlabs.org
Subject: Gianfar - MPC8541 - tx buffer overrun errors
=09
=09
All,
=20
I am running 2.6.11 version of the kernel on MPC8541. Have one
of the TSECs configured at 100Mbps/Full Duplex. The TSEC MAC is
connected to a Marvell Ethernet switch MAC without any PHY in between.
MAC level flow control is enabled but no pause frames sent or received.
=20
I see a high number of transmit buffer overrun errors
(tx_fifo_empty errors in the gianfar driver). I don't have NAPI
enabled. In addition to other things, I was thinking of enabling NAPI
and see if it helps - is there any downside to it?? Are there any other
parameters that I could tweak to reduce/eliminate the overrun errors??
=20
Thanks,
Shriram.
=20
________________________________
Got a little couch potato?=20
Check out fun summer activities for kids.
<http://us.rd.yahoo.com/evt=3D48248/*http://search.yahoo.com/search?fr=3D=
oni
_on_mail&p=3Dsummer+activities+for+kids&cs=3Dbz>=20
^ permalink raw reply
* [PATCH update] Re: Sleep problems with kernels >= 2.6.21 on powerpc
From: Stefan Richter @ 2007-09-06 7:50 UTC (permalink / raw)
To: Andrew Morton
Cc: michal.k.k.piotrowski, rbrito, krh, linux-kernel, rjw,
linuxppc-dev, debian-powerpc, linux-pm, rael
In-Reply-To: <tkrat.29a16d2ec8698ff2@s5r6.in-berlin.de>
On 5 Sep, Stefan Richter wrote:
> On 5 Sep, Andrew Morton wrote:
>>> >>> Trying to free already-free IRQ 40
>>> >>> pci_set_power_state(): 0002:20:0e.0: state=3, current state=5
>>> >>> firewire_ohci: pci_set_power_state failed with -22<3>pci_device_suspend(): pci_suspend+0x0/0x9c [firewire_ohci]() returns -22
...
>> It's not clear _why_ pci_set_power_state() is failing.
>
> The only -22 error path in pci_set_power_state is this:
>
> /* Validate current state:
> * Can enter D0 from any state, but if we can only go deeper
> * to sleep if we're already in a low power state
> */
> if (state != PCI_D0 && dev->current_state > state) {
> printk(KERN_ERR "%s(): %s: state=%d, current state=%d\n",
> __FUNCTION__, pci_name(dev), state, dev->current_state);
> return -EINVAL;
> } [...else...]
From: Stefan Richter <stefanr@s5r6.in-berlin.de>
Subject: firewire: fw-ohci: ignore failure of pci_set_power_state (fix suspend regression)
Fixes (papers over) "Sleep problems with kernels >= 2.6.21 on powerpc",
http://lkml.org/lkml/2007/8/25/155. The issue is that the FireWire
controller's pci_dev.current_state of iBook G3 and presumably older
PowerBooks is still in PCI_UNKNOWN instead of PCI_D0 when the firewire
driver's .suspend method is called.
Like it was suggested earlier in http://lkml.org/lkml/2006/10/24/13, we
do not fail .suspend anymore if pci_set_power_state failed.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
---
Update:
- omit comment which will become outdated if the underlying problem is fixed
- log the error return value
- document the actual bug in the patch description
IMO the actual bug here (operating the controller while it is in
PCI_UNKNOWN state, which is surely a fault in the PPC platform code) is
something to be fixed post 2.6.23 release.
drivers/firewire/fw-ohci.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
Index: linux/drivers/firewire/fw-ohci.c
===================================================================
--- linux.orig/drivers/firewire/fw-ohci.c
+++ linux/drivers/firewire/fw-ohci.c
@@ -1973,10 +1973,8 @@ static int pci_suspend(struct pci_dev *p
return err;
}
err = pci_set_power_state(pdev, pci_choose_state(pdev, state));
- if (err) {
- fw_error("pci_set_power_state failed\n");
- return err;
- }
+ if (err)
+ fw_error("pci_set_power_state failed with %d\n", err);
return 0;
}
--
Stefan Richter
-=====-=-=== =--= --==-
http://arcgraph.de/sr/
^ 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