* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
From: Segher Boessenkool @ 2007-06-03 18:43 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: ppcdev, linux-mtd, Milton Miller
In-Reply-To: <4663060C.2020906@ru.mvista.com>
>>>> I think "direct-mapped" as compatible is a bit too broad or vague.
>
>>> It's actually not -- it means simple 1:1 address mapping (w/o
>>> explicit
>>> byte-swapping and such).
>
>> Which has nothing to do with "compatible"; instead,
>> it is implied by the parent node have a "ranges"
>
> No! It doesn't have anything to do with "ranges" of parent (don't
> even know why it would). :-O
So learn about it please? "ranges" means exactly that:
child nodes' address space is direct mapped.
>> property. Or you can put some other property in
>> the flash node for all I care, if that seems
>> necessary for certain cases.
>
> Erm... it's *certainly* necessary to mark this somewhere.
Not if it's redundant information.
>>>> The compatible is supposed to be useable to find and match a driver
>>>> without regard to the name of the node. Perhaps direct-mapped-rom?
>
> That really depends on whether we choose to follow the Generic
> Names spec.
No, it doesn't. OF before the generic names recommended practice
was different only in that it had "name" be the most specific
of the device descriptions.
Also, it has already been decided to follow this recommended
practice. It would have been foolish not to, it being collected
wisdom by real-life implementations and all.
> Even if we do, it does *not* preclude OS from using both props for the
> driver selection.
An OS is *required* (erm, "supposed", if you like) to use
first "name", and then "compatible". An OS is not supposed
to use "device_type" or any other properties for device
matching.
>>> Note that we're matching by both "device_type" and "compatible".
>
>> Which is wrong.
>
> Why?
Because that is a) not what you are supposed to do according
to the standard (so it might very well not work with a
"third-party" device tree that equally conforms to the standard);
b) "device_type" describes some other information (namely, the
OF programming model for the device node) that is completely
unrelated to the process of driver matching; and c) it is wholly
redundant to the information in "compatible" *ANYWAY*.
> And why then it's allowed to match by "device_type"?
Anything is allowed, this is a free world. It is wrong though.
Linux used to do this wrong, there are many remnants of that
left. You also might *need* to do this for certain imperfect
device trees. None of this is an argument to continue this
"tradition".
> And why you haven't complained at MPC5200 IDE driver
Since no one paid me to review the code? Please don't try
that argument ever again, thank you very much. I think I
do quite enough work here already, I don't need people
demanding stuff from me.
> which does the same (well, maybe you have :-) or at PowerMac IDE
> driver which matches wither by "name" or "device_type"? Well, quite a
> lot of drivers are doing this...
See before why that may be. Short answer is "history".
>>> This would serve no purpose, as the driver that would catches
>>> all these is signle one, drivers/mtd/maps/physmap_of.c...
>
>> With the current kernel version, perhaps. Did you check
>> out 2.6.28? Does it work with that?
>
> For the simply mapped flashes, physmap_of will suffice, for more
> complex cases, other driver will be needed.
Ah, so you can predict the future of the Linux kernel!
> If you're hinting at the possibility that MTD subsys will be
> substantially reworked -- I don't find that likely. If it will --
> well, bad luck. :-)
Which is not an acceptable outcome.
> Anyway, reasonable suggestions on how to make MTD nodes more viable
> are always welcome. I just haven't seen reasonable enough yet. ;-)
I suggest you read, and try to understand, some of the base
device tree specifications first.
Segher
^ permalink raw reply
* Re: [PATCH] IDE: Remove remnants related to dead BLK_DEV_MAC_MEDIABAY CONFIG variable.
From: Robert P. J. Day @ 2007-06-03 18:41 UTC (permalink / raw)
To: Brad Boyer; +Cc: Linux PPC Mailing List, bzolnier
In-Reply-To: <20070603172829.GA25404@cynthia.pants.nu>
On Sun, 3 Jun 2007, Brad Boyer wrote:
> On Sun, Jun 03, 2007 at 01:52:02PM -0400, Robert P. J. Day wrote:
> > Remove the two snippets of code conditional on the non-existent CONFIG
> > variable CONFIG_BLK_DEV_MAC_MEDIABAY.
>
> This is the wrong list. The macide driver is for m68k Macintoshes,
> so you really need to send this to the linux-m68k list. It looks
> like this was originally a copy of the IDE driver for ppc based
> Macintoshes and this particular feature was never finished.
>
> Just in case you don't know where to find the linux-m68k mailing
> list, it is hosted on vger.kernel.org.
ok, i'll do that, thanks.
rday
--
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://fsdev.net/wiki/index.php?title=Main_Page
========================================================================
^ permalink raw reply
* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
From: Segher Boessenkool @ 2007-06-03 18:44 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linuxppc-dev, linux-mtd, Milton Miller
In-Reply-To: <466308F4.8050004@ru.mvista.com>
>> You obviously completely misunderstand the semantics
>> of the "compatible" property.
>
> Oh well, on the chip level, your "compatible" prop would be correct.
This has nothing to do with a "chip level", it is plain and
simply the most basic device tree stuff.
[rest snipped]
Segher
^ permalink raw reply
* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
From: Segher Boessenkool @ 2007-06-03 18:46 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: ppcdev, linux-mtd, Milton Miller
In-Reply-To: <46630A32.7000403@ru.mvista.com>
>>> Nobody's talking about the direct match but making the task of
>>> selecting a proper driver more complex by specifying the details
>>> that don't help (if not hinder) the correct selection is certainly
>>> not a way to go.
>
>> Nonsense. If the kernel doesn't care about certain details,
>> it can just ignore them.
>
> That's OK, as long as it has the details it needs. Your suggestions
> on the "compatible" devoided it of such.
Sigh.
[snip]
>>> That's the way the cookie crumbles in Linux MTD for now. It's
>>> *always* detecting this by probing -- you only can say what [not] to
>>> probe.
>
>> So go fix that :-)
>
> Wanna pay me for that? ;-)
You're the one complaining, you go pay yourself.
[snip, plunk]
Segher
^ permalink raw reply
* Re: [PATCH] IDE: Remove remnants related to dead BLK_DEV_MAC_MEDIABAY CONFIG variable.
From: Bartlomiej Zolnierkiewicz @ 2007-06-03 19:07 UTC (permalink / raw)
To: Brad Boyer; +Cc: Linux PPC Mailing List, Robert P. J. Day
In-Reply-To: <20070603172829.GA25404@cynthia.pants.nu>
Hi,
Ehm, I'm guilty for this mistake since I've advised Robert
to cc: wrong list (thinko caused by mediabay == ppc assumption).
Sorry for this. :)
Robert: I'll apply both patches in a few days if there are no
complains from m68k/scsi people.
Thanks,
Bart
On Sunday 03 June 2007, Brad Boyer wrote:
> On Sun, Jun 03, 2007 at 01:52:02PM -0400, Robert P. J. Day wrote:
> > Remove the two snippets of code conditional on the non-existent CONFIG
> > variable CONFIG_BLK_DEV_MAC_MEDIABAY.
>
> This is the wrong list. The macide driver is for m68k Macintoshes, so
> you really need to send this to the linux-m68k list. It looks like this
> was originally a copy of the IDE driver for ppc based Macintoshes and
> this particular feature was never finished.
>
> Just in case you don't know where to find the linux-m68k mailing list,
> it is hosted on vger.kernel.org.
>
> Brad Boyer
> flar@allandria.com
^ permalink raw reply
* Re: [PATCH 2/8] Add uli1575 pci-bridge sector to MPC8641HPCN dts file.
From: Segher Boessenkool @ 2007-06-03 18:56 UTC (permalink / raw)
To: Gabriel Paubert; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <20070603182020.GA10355@iram.es>
>>> Otherwise the "feature" of this RTC is that its interrupt
>>> is not connected.
>>
>> Dunno what you mean here?
>
> On a standard PC, the RTC is connected to interrupt
> 8 of the 8259 pair.
Ah okay. This RTC is a completely different device
though. It does have an interrupt line, but it might
very well not be connected anywhere.
>>> Actually I wonder
>>> whether using PNP0B00 is correct in the residual data here.
>>
>> It's not correct at all, no.
>
> Ok. I don't know well the PNP spec.
b00 means PC-AT style RTC.
> I don't really remember
> also what the chip identification means in the residual data,
> but it is always MOT3040.
I searched for that too, but couldn't find anything else
than Linux-on-PReP related stuff ;-)
> OTOH, there is a but in more
> recent versions, that claims that the NVRAM data size is
> 32768 and not 8192...
You can fix that in the device tree :-)
>> Not sure how best to describe this thing -- one master
>> node with a kid for both nvram and rtc; one node; or
>> perhaps one node for rtc, with a child node for nvram.
>
> Hey, at least you now understand why I was asking the question :-)
Yeah, it's a bit nasty case. Since it _is_ one device,
you really want to describe it as such -- but it also
is nice to describe the nvram functionality separately.
I think I'd go for
rtc@i74 {
device_type = "rtc";
reg = <1 74 4>;
compatible = "MK42whatever";
nvram {
device_type = "nvram";
#bytes = <1ff0>;
}
}
or something like that. You'll have to do the device
matching as one device, but the driver has to know they
are one device *anyway* :-)
> This is the only device on these boards that really causes
> me trouble, for all the others I think I can get a reasonable
> description in the device tree.
Great to hear, looking forward to seeing it.
Segher
^ permalink raw reply
* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
From: Sergei Shtylyov @ 2007-06-03 18:59 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: ppcdev, linux-mtd, Milton Miller
In-Reply-To: <c077dedaa90bf4fb3af1c5c8c4b39c85@kernel.crashing.org>
Segher Boessenkool wrote:
>>>>> I think "direct-mapped" as compatible is a bit too broad or vague.
>>>> It's actually not -- it means simple 1:1 address mapping (w/o
>>>> explicit
>>>> byte-swapping and such).
>>> Which has nothing to do with "compatible"; instead,
>>> it is implied by the parent node have a "ranges"
>> No! It doesn't have anything to do with "ranges" of parent (don't
>> even know why it would). :-O
> So learn about it please? "ranges" means exactly that:
> child nodes' address space is direct mapped.
Well, now we certainly need a parent node -- which would be static bus
controller? But those have multiple chips selects, so we should know which
range to use. Ugh...
>>> property. Or you can put some other property in
>>> the flash node for all I care, if that seems
>>> necessary for certain cases.
>> Erm... it's *certainly* necessary to mark this somewhere.
> Not if it's redundant information.
>>>> Note that we're matching by both "device_type" and "compatible".
>>> Which is wrong.
>> Why?
> Because that is a) not what you are supposed to do according
> to the standard (so it might very well not work with a
> "third-party" device tree that equally conforms to the standard);
> b) "device_type" describes some other information (namely, the
> OF programming model for the device node) that is completely
> unrelated to the process of driver matching; and c) it is wholly
> redundant to the information in "compatible" *ANYWAY*.
Hm, well. Than changing "compatible" prop would make sense.
>> And why then it's allowed to match by "device_type"?
> Anything is allowed, this is a free world. It is wrong though.
> Linux used to do this wrong, there are many remnants of that
> left. You also might *need* to do this for certain imperfect
> device trees. None of this is an argument to continue this
> "tradition".
>> And why you haven't complained at MPC5200 IDE driver
> Since no one paid me to review the code? Please don't try
Sigh, nobody pays me for that too. :-)
> that argument ever again, thank you very much. I think I
> do quite enough work here already, I don't need people
> demanding stuff from me.
I wasn't demanding anything. I just wanted to clear things out.
>> which does the same (well, maybe you have :-) or at PowerMac IDE
>> driver which matches wither by "name" or "device_type"? Well, quite a
>> lot of drivers are doing this...
> See before why that may be. Short answer is "history".
Well, at least that's cleared.
>>>> This would serve no purpose, as the driver that would catches
>>>> all these is signle one, drivers/mtd/maps/physmap_of.c...
>>> With the current kernel version, perhaps. Did you check
>>> out 2.6.28? Does it work with that?
>
>> For the simply mapped flashes, physmap_of will suffice, for more
>> complex cases, other driver will be needed.
> Ah, so you can predict the future of the Linux kernel!
If I could, I'd have taken measures. :-)
>> If you're hinting at the possibility that MTD subsys will be
>> substantially reworked -- I don't find that likely. If it will --
>> well, bad luck. :-)
> Which is not an acceptable outcome.
>> Anyway, reasonable suggestions on how to make MTD nodes more viable
>> are always welcome. I just haven't seen reasonable enough yet. ;-)
> I suggest you read, and try to understand, some of the base
> device tree specifications first.
Read them some months ago -- do you think I would have plunged into that
not reading anything first? :-/
> Segher
WBR, Sergei
^ permalink raw reply
* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
From: Sergei Shtylyov @ 2007-06-03 19:13 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, linux-mtd, Milton Miller
In-Reply-To: <8ac5664208e0f59329b62ac2138bbc8c@kernel.crashing.org>
Segher Boessenkool wrote:
>>> You obviously completely misunderstand the semantics
>>> of the "compatible" property.
>> Oh well, on the chip level, your "compatible" prop would be correct.
> This has nothing to do with a "chip level", it is plain and
> simply the most basic device tree stuff.
If it was as "plain and simple" as you say, there would be nothing to
argue about. What we ended up with is 2 or 3 level hierarchy of nodes which
doesn't at all seem to be such simple (considering the fact that what's
covered by a the simple "bank-width" property could be represented by several
combinations of interleaved flash chips). So, what you wanted us to do was
either substantially redesign Linux MTD subsys to fit it into that model
(either that or over-engineer the physmap_of driver to gather that kind of
information from the multiple "chip" subnodes). Guess how well would that
have been accepted even if we had time to do that...
> Segher
WBR, Sergei
^ permalink raw reply
* Re: [PATCH] IDE: Remove remnants related to dead BLK_DEV_MAC_MEDIABAY CONFIG variable.
From: Brad Boyer @ 2007-06-03 17:28 UTC (permalink / raw)
To: Robert P. J. Day; +Cc: Linux PPC Mailing List, bzolnier
In-Reply-To: <Pine.LNX.4.64.0706031348550.24843@localhost.localdomain>
On Sun, Jun 03, 2007 at 01:52:02PM -0400, Robert P. J. Day wrote:
> Remove the two snippets of code conditional on the non-existent CONFIG
> variable CONFIG_BLK_DEV_MAC_MEDIABAY.
This is the wrong list. The macide driver is for m68k Macintoshes, so
you really need to send this to the linux-m68k list. It looks like this
was originally a copy of the IDE driver for ppc based Macintoshes and
this particular feature was never finished.
Just in case you don't know where to find the linux-m68k mailing list,
it is hosted on vger.kernel.org.
Brad Boyer
flar@allandria.com
^ permalink raw reply
* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
From: Sergei Shtylyov @ 2007-06-03 19:16 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: ppcdev, linux-mtd, Milton Miller
In-Reply-To: <e85b2d39481e426dcd4c19a3eaaf8238@kernel.crashing.org>
Segher Boessenkool wrote:
>>>> Nobody's talking about the direct match but making the task of
>>>> selecting a proper driver more complex by specifying the details
>>>> that don't help (if not hinder) the correct selection is certainly
>>>> not a way to go.
>>> Nonsense. If the kernel doesn't care about certain details,
>>> it can just ignore them.
>> That's OK, as long as it has the details it needs. Your suggestions
>> on the "compatible" devoided it of such.
> Sigh.
There had been no suggestions about other props or using "ranges" at that
point. That wouldn't have covered all issues anyway.
> [snip]
>>>> That's the way the cookie crumbles in Linux MTD for now. It's
>>>> *always* detecting this by probing -- you only can say what [not] to
>>>> probe.
>>> So go fix that :-)
>> Wanna pay me for that? ;-)
> You're the one complaining, you go pay yourself.
I'm lost here. Complaining about what?
> [snip, plunk]
> Segher
WBR, Sergei
^ permalink raw reply
* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
From: Segher Boessenkool @ 2007-06-03 19:48 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: ppcdev, linux-mtd, Milton Miller
In-Reply-To: <46630F8F.6080708@ru.mvista.com>
>>> No! It doesn't have anything to do with "ranges" of parent (don't
>>> even know why it would). :-O
>
>> So learn about it please? "ranges" means exactly that:
>> child nodes' address space is direct mapped.
>
> Well, now we certainly need a parent node -- which would be static
> bus controller?
I have no clue what a "static bus controller" is. Your
flash node obviously needs _some_ parent node though --
this is a tree after all.
> But those have multiple chips selects, so we should know which range
> to use. Ugh...
That is described in the "reg" property of the flash
node, just like for any other node.
>> Because that is a) not what you are supposed to do according
>> to the standard (so it might very well not work with a
>> "third-party" device tree that equally conforms to the standard);
>> b) "device_type" describes some other information (namely, the
>> OF programming model for the device node) that is completely
>> unrelated to the process of driver matching; and c) it is wholly
>> redundant to the information in "compatible" *ANYWAY*.
>
> Hm, well. Than changing "compatible" prop would make sense.
Yes.
>>> And why you haven't complained at MPC5200 IDE driver
>
>> Since no one paid me to review the code? Please don't try
>
> Sigh, nobody pays me for that too. :-)
Yeah it's a shame isn't it?
>>> which does the same (well, maybe you have :-) or at PowerMac IDE
>>> driver which matches wither by "name" or "device_type"? Well, quite
>>> a lot of drivers are doing this...
>
>> See before why that may be. Short answer is "history".
>
> Well, at least that's cleared.
Okido, good to hear.
>>> Anyway, reasonable suggestions on how to make MTD nodes more
>>> viable are always welcome. I just haven't seen reasonable enough
>>> yet. ;-)
>
>> I suggest you read, and try to understand, some of the base
>> device tree specifications first.
>
> Read them some months ago -- do you think I would have plunged into
> that not reading anything first? :-/
It seems we really need more howto-style docs...
Segher
^ permalink raw reply
* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
From: Segher Boessenkool @ 2007-06-03 19:56 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linuxppc-dev, linux-mtd, Milton Miller
In-Reply-To: <466312C2.4090200@ru.mvista.com>
>>>> You obviously completely misunderstand the semantics
>>>> of the "compatible" property.
>
>>> Oh well, on the chip level, your "compatible" prop would be
>>> correct.
>
>> This has nothing to do with a "chip level", it is plain and
>> simply the most basic device tree stuff.
>
> If it was as "plain and simple" as you say, there would be nothing
> to argue about.
There isn't as far as I am concerned; the purpose and
meaning of the "compatible" property, as well as of any
other standard OF properties, is clear.
> What we ended up with is 2 or 3 level hierarchy of nodes which doesn't
> at all seem to be such simple (considering the fact that what's
> covered by a the simple "bank-width" property could be represented by
> several combinations of interleaved flash chips).
Yes, the more complex (and sometimes insane) ways that
flash chips are connected to systems can be really hard
to describe properly. Which is why I don't even want
to make a "binding" for it (yet). It seems easy enough
to do this for single flash chips (possibly direct-mapped)
though.
> So, what you wanted us to do was either substantially redesign Linux
> MTD subsys to fit it into that model
Nah. The current MTD model has some issues of course,
but that is a separate problem.
> (either that or over-engineer the physmap_of driver to gather that
> kind of information from the multiple "chip" subnodes).
I would say it is overengineered already. It shouldn't
try to be a general solution for all possible cases since
it has no hope of achieving that. Get the simple cases
(that actually are used in real life) right, first.
Segher
^ permalink raw reply
* Re: [PATCH] IDE: Remove remnants related to dead BLK_DEV_MAC_MEDIABAY CONFIG variable.
From: Brad Boyer @ 2007-06-03 18:51 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz; +Cc: Linux PPC Mailing List, Robert P. J. Day
In-Reply-To: <200706032107.52152.bzolnier@gmail.com>
On Sun, Jun 03, 2007 at 09:07:52PM +0200, Bartlomiej Zolnierkiewicz wrote:
> Ehm, I'm guilty for this mistake since I've advised Robert
> to cc: wrong list (thinko caused by mediabay == ppc assumption).
>
> Sorry for this. :)
Don't worry about it. I would have missed it if I wasn't active in
the m68k Mac support. I'm pretty sure the PowerBook 190 was the only
m68k Mac with a media bay, and it's really just a PB 5300 with the
ppc chip swapped out for a 68LC040 to make a cheaper model. They're
fundamentally the same system in most ways. Hopefully we can merge
more of the m68k Mac support code with the ppc Mac support at some
point in the future, but that's still a fair amount of work.
Brad Boyer
flar@allandria.com
^ permalink raw reply
* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
From: Sergei Shtylyov @ 2007-06-03 20:10 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: ppcdev, linux-mtd, Milton Miller
In-Reply-To: <bd28eac8eb60db8aaff74f91c76d4196@kernel.crashing.org>
Segher Boessenkool wrote:
>>>> No! It doesn't have anything to do with "ranges" of parent (don't
>>>> even know why it would). :-O
>>
>>
>>> So learn about it please? "ranges" means exactly that:
>>> child nodes' address space is direct mapped.
>>
>>
>> Well, now we certainly need a parent node -- which would be static
>> bus controller?
> I have no clue what a "static bus controller" is. Your
As has been pointed out in the previous "fit" of this dispute, the NOR
flashes are usually behind a kind of bridge between the "host" and
"peripheral" (static) busses.
> flash node obviously needs _some_ parent node though --
> this is a tree after all.
Yes, of course it always has a perent. The question is which parent it
should be. :-)
>> But those have multiple chips selects, so we should know which range
>> to use. Ugh...
> That is described in the "reg" property of the flash
> node, just like for any other node.
Ah. So simple. :-)
What I failed to realize so far was that "ranges" imply 1:1 address
correspondence. But not all is so simple, I'm afraid. The flash chips
themselves could be connected to their bus in some weird fashion, I'm afraid
(not that it's likely to happen on mostly big-endian PPC though).
>>>> And why you haven't complained at MPC5200 IDE driver
>>> Since no one paid me to review the code? Please don't try
>> Sigh, nobody pays me for that too. :-)
> Yeah it's a shame isn't it?
Well, I'm doing it anyway. :-)
>>>> Anyway, reasonable suggestions on how to make MTD nodes more
>>>> viable are always welcome. I just haven't seen reasonable enough
>>>> yet. ;-)
>>> I suggest you read, and try to understand, some of the base
>>> device tree specifications first.
>> Read them some months ago -- do you think I would have plunged into
>> that not reading anything first? :-/
> It seems we really need more howto-style docs...
It may indeed be non-trivial task to find all the necessary specs besides
1285 itself -- I just happened to know where to grab them beforehand:
http://www.openbios.org/Bindings
> Segher
WBR, Sergei
^ permalink raw reply
* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
From: Sergei Shtylyov @ 2007-06-03 20:26 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, linux-mtd, Milton Miller
In-Reply-To: <548a7e11ffb577f6395b8f5a9c2fba2d@kernel.crashing.org>
Segher Boessenkool wrote:
>>>>> You obviously completely misunderstand the semantics
>>>>> of the "compatible" property.
>>>> Oh well, on the chip level, your "compatible" prop would be correct.
>>> This has nothing to do with a "chip level", it is plain and
>>> simply the most basic device tree stuff.
>> If it was as "plain and simple" as you say, there would be nothing
>> to argue about.
> There isn't as far as I am concerned; the purpose and
> meaning of the "compatible" property, as well as of any
> other standard OF properties, is clear.
Erm, concerning matching those with drivers it wasn't as clear that those
props aren't the same as driver names b/c of the follwing passage in Generic
Names:
"It is possible that the operating system will find a driver matching the
generic name, and that said driver will not be the correct one. However, this
is not a new problem, because generic names have already been used in the past
for built-in devices. Consequently, an operating system that does not already
have a mechanism for resolving or avoiding such false matches is likely to
have problems eventually, with or without the proliferation of generic names.
The following suggests some possible techniques for dealing with such false
generic matches.
a) In collections of OS drivers, avoid the use of generic names for the
drivers themselves. For example, it is generally unwise to name a driver
ethernet, since there are many different ethernet adapters with different
programming models. Using the generic name ethernet to identify only one such
driver is presumptuous.
b) Separate the OS's name spaces for drivers for real hardware devices and
pseudodrivers (collections of support routines that are used by real drivers).
Some operating systems load such pseudo-drivers using a mechanism similar to
the mechanism used for real drivers. Pseudo drivers often perform generic
functions that apply equally well to, for example, all ethernet adapters,
independent of their low-level programming models. Consequently, it is
reasonable to use generic names (e.g. ethernet) for such pseudodrivers.
Separating the name spaces of real drivers and pseudo-drivers avoids false
matches from generic device names to generic psuedo-driver names.
c) Make the OS's driver search mechanism depend upon the device's parent. In
other words, separate the OS's driver name spaces so that drivers for devices
that attach to, for example, PCI bus can be distinguished from those that
attach to, for example, ISA bus. This reduces the range over which false
matches can occur.
d) For cases where false matches are unavoidable (for example, if there is an
existing driver with a generic name that must be retained for backwards
compatibility) allow the drivers that can be incorrectly matched the
possibility of rejecting the match. One technique for doing so is to for the
driver to inspect the compatible property to ensure that it is appropriate.
Another common technique is to have the generic driver probe the hardware to
see if it behaves as expected (although this technique can cause problems)."
Well, I've already pointed that out in the past...
>> What we ended up with is 2 or 3 level hierarchy of nodes which doesn't
>> at all seem to be such simple (considering the fact that what's
>> covered by a the simple "bank-width" property could be represented by
>> several combinations of interleaved flash chips).
> Yes, the more complex (and sometimes insane) ways that
> flash chips are connected to systems can be really hard
> to describe properly. Which is why I don't even want
> to make a "binding" for it (yet). It seems easy enough
Neither do we. :-)
> to do this for single flash chips (possibly direct-mapped)
> though.
Erm, FSL boards seem to generally have dual 16-bit NOR flash chips
interleaved -- and that's seems quite a common case, not only in PPC world.
Perhaps... those interleaved chips could really be merged (abstracted)
into a single one, with the bus width being a sum of two?
>> (either that or over-engineer the physmap_of driver to gather that
>> kind of information from the multiple "chip" subnodes).
> I would say it is overengineered already. It shouldn't
> try to be a general solution for all possible cases since
> it has no hope of achieving that.
It's not trying to be such a general solution, it's just trying to handle
all the cases of simply-mapped NOR flashes, just like its non-OF counterpart does.
> Get the simple cases
> (that actually are used in real life) right, first.
We pursued this task exactly. Get it working, quick. :-)
> Segher
WBR, Sergei
^ permalink raw reply
* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
From: Benjamin Herrenschmidt @ 2007-06-03 21:04 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: ppcdev, linux-mtd, Milton Miller
In-Reply-To: <46630256.8050909@ru.mvista.com>
On Sun, 2007-06-03 at 22:03 +0400, Sergei Shtylyov wrote:
> >> the CFI/JEDEC interface then can be deduced by probing
>
> > Most of the time, sure. Not always.
>
> That's the way the cookie crumbles in Linux MTD for now. It's
> *always*
> detecting this by probing -- you only can say what [not] to probe.
So you are saying that because the current linux MTD stuff can only
probe (which doesn't always work), we should not put the proper chip
interface type in the device-tree ?
Your argument makes no sense to me.
Put the proper interface informations in the device-tree, maybe some OS
smarter than linux will make good use on it and maybe linux will be
fixed at one point too (not by you, of course, you gave us that line
often enough about not being paid to do the right thing).
Ben.
^ permalink raw reply
* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
From: Benjamin Herrenschmidt @ 2007-06-03 21:12 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linuxppc-dev, linux-mtd, Milton Miller
In-Reply-To: <4662EAA9.70104@ru.mvista.com>
On Sun, 2007-06-03 at 20:22 +0400, Sergei Shtylyov wrote:
>
> No, it doesn't -- since that info is almost *absolutely* useless
> (the only
> exception is "cfi") in the context of Linux MTD subsys.
> Please, try to understand that knowing that chip is CFI compatible
> in
> itself doesn't yet guarantee that you can access the chip -- it all
> depends on
> its mapping to the real physical address range, therefore this group
> IMO
> cannot even constitute a valid "compatible" property.
You make no sense to me. It's like saying that knowing that a 8250 chip
on ISA cannot be accessed if you don't know it's IO ports so it
shouldn't say "8250" in compatible property ?!?!?!?
Also, whatever shortcomings of the linux MTD drivers are totally
irrelevant to what is correct to have in a device-tree. While we do
tailor our device-tree specification around linux needs in most cases,
there are cases like this one where common sense should be enough to
understand that it's not because the linux MTD subsystem, as of today,
cannot be told what programming interface to use, that we shouldn't
provide that information in the tree.
Regarding physical address ranges for the flash mapping, I suppose the
best is to define a property for flash chips for it.
^ permalink raw reply
* Re: ps3 64-bit kernel: patched prpmc2800.c (fwd)
From: Mark A. Greer @ 2007-06-03 23:25 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, Maik Nijhuis
In-Reply-To: <18018.7868.811862.733793@cargo.ozlabs.ibm.com>
On Sun, Jun 03, 2007 at 11:51:56AM +1000, Paul Mackerras wrote:
> Maik Nijhuis writes:
>
> > I managed to fix this issue as follows: At the end of
> > arch/powerpc/boot/prpmc2800.c, there is an assembly instruction
> >
> > rlwinm 10,10,0,~(1<<15)
> >
> > I replaced this by
> >
> > rlwinm 10,10,0,~(1<<15) & ((1<<32)-1)
>
> It is a binutils bug, and Alan Modra has a patch for it. In the
> meantime the best thing would be to change that to
>
> rlwinm 10,10,0,17,15
>
> which is equivalent.
Oops, I totally missed this thread. I'll whip up a patch for this on Monday.
Mark
^ permalink raw reply
* RE: Kernel and rootfs in ONE image?
From: Stelios Koroneos @ 2007-06-03 23:42 UTC (permalink / raw)
To: Frank Prepelica, linuxppc-embedded
In-Reply-To: <29DC34A6B43468409F5A371CFE34E8491B5A4A@ex01.ads.ubidyne.de>
[-- Attachment #1: Type: text/plain, Size: 1320 bytes --]
Yes it is.
There are basically two ways in doing it
One is to create a binary "blob" where each part (kernel and fs) is placed
at a certain location and the space between them is padded
These location should match exactly the kernel mtd partition settings in
terms of size.
The other method i have used, uses some "magic bytes" at the end of a jffs2
filesystem to mark it
Then kernel and the fs are joint and a kernel patch is used to find where
the filesystem starts/ends
This is the method used by Openwrt (in the kamikaze version)
Stelios S. Koroneos
Digital OPSiS - Embedded Intelligence
http://www.digital-opsis.com
-----Original Message-----
From: linuxppc-embedded-bounces+stelios=stelioscellar.com@ozlabs.org
[mailto:linuxppc-embedded-bounces+stelios=stelioscellar.com@ozlabs.org]On
Behalf Of Frank Prepelica
Sent: Friday, June 01, 2007 2:15 PM
To: linuxppc-embedded@ozlabs.org
Subject: Kernel and rootfs in ONE image?
Hi all,
in normal case you have got a kernel image and a rootfs image. Place
that images into flash memory, set correct bootargs and it should work.
But, is it possible to generate one image which includes the linux kernel
and a rootfs, place that single image into flash memory and it should also
work?
Thanks in advance!
Beste regrads
Frank
[-- Attachment #2: Type: text/html, Size: 5706 bytes --]
^ permalink raw reply
* Re: [PATCH 2/8] Add uli1575 pci-bridge sector to MPC8641HPCN dts file.
From: Olof Johansson @ 2007-06-04 0:16 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev@ozlabs.org, Jon Loeliger
In-Reply-To: <1180826202.14025.12.camel@localhost.localdomain>
On Sun, Jun 03, 2007 at 09:16:42AM +1000, Benjamin Herrenschmidt wrote:
> On Sat, 2007-06-02 at 22:00 +0200, Segher Boessenkool wrote:
> > The official (and unofficial) Open Firmware docs are quite
> > good. Perhaps we need a big huge fat sign in the DTS docs
> > pointing to them.
>
> They aren't -that- good when you come out of the blue and don't know
> where to start. I think a tutorial based on building a tree for an
> example board step by step would be best.
There seems to be two things that causes problems:
1) People basing their new tree on an old example that's broken, and
getting crap for that because it's not correct
2) Trying to add new devices that aren't in any trees already, and
the near infinite discussions that then start.
(1) Could clearly be solved to a fair extent by having a "blessed
golden tree" that people can clone their own board files from, instead
of grabbing a random one and hoping that it's not too broken.
(2) I don't have a good solution for. Better documentation pointers would
definitely be a help, but it's not the whole solution. I'd expect it to
get better and better over time as there'll be less and less unmapped
terrain, and better and better examples to use.
-Olof
^ permalink raw reply
* [PATCH] pasemi: fix iommu + 64K PAGE_SIZE bug
From: Olof Johansson @ 2007-06-04 0:49 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
The powerpc iommu code was refactored by Linas back in the 2.6.20 time
frame to map 4K pages from the generic code, but I had forgotten to go
back and fix my platform driver before submitting it.
Signed-off-by: Olof Johansson <olof@lixom.net>
diff --git a/arch/powerpc/platforms/pasemi/iommu.c b/arch/powerpc/platforms/pasemi/iommu.c
index 95fa6a7..f33b21b 100644
--- a/arch/powerpc/platforms/pasemi/iommu.c
+++ b/arch/powerpc/platforms/pasemi/iommu.c
@@ -31,8 +31,6 @@
#define IOBMAP_PAGE_SIZE (1 << IOBMAP_PAGE_SHIFT)
#define IOBMAP_PAGE_MASK (IOBMAP_PAGE_SIZE - 1)
-#define IOBMAP_PAGE_FACTOR (PAGE_SHIFT - IOBMAP_PAGE_SHIFT)
-
#define IOB_BASE 0xe0000000
#define IOB_SIZE 0x3000
/* Configuration registers */
@@ -97,9 +95,6 @@ static void iobmap_build(struct iommu_table *tbl, long index,
bus_addr = (tbl->it_offset + index) << PAGE_SHIFT;
- npages <<= IOBMAP_PAGE_FACTOR;
- index <<= IOBMAP_PAGE_FACTOR;
-
ip = ((u32 *)tbl->it_base) + index;
while (npages--) {
@@ -125,9 +120,6 @@ static void iobmap_free(struct iommu_table *tbl, long index,
bus_addr = (tbl->it_offset + index) << PAGE_SHIFT;
- npages <<= IOBMAP_PAGE_FACTOR;
- index <<= IOBMAP_PAGE_FACTOR;
-
ip = ((u32 *)tbl->it_base) + index;
while (npages--) {
^ permalink raw reply related
* Re: [PATCH 3/3] consolidate do_signal
From: Benjamin Herrenschmidt @ 2007-06-04 1:10 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: linuxppc-dev
In-Reply-To: <1180828765.14025.34.camel@localhost.localdomain>
On Sun, 2007-06-03 at 09:59 +1000, Benjamin Herrenschmidt wrote:
> > + if ((ka.sa.sa_flags & SA_ONSTACK) &&
> > + current->sas_ss_size && !
> on_sig_stack(regs->gpr[1]))
> > + newsp = current->sas_ss_sp +
> current->sas_ss_size;
> > + else
> > + newsp = regs->gpr[1];
>
> Hrm... some gratuituous differences in the signal stack handling.. I
> wonder if that hides a bug in one of the implementations...
Ok, so, that bit is actually a bit nicer on 64 bits, where there's a
get_sigframe() that handles this and is called by setup_rt_frame (which
you renamed to handle_rt_signal64).
(Though the actual implementation of get_sigframe() could use some
cleanup).
I'll do a patch on top of yours making that bit common.
Cheers,
Ben.
^ permalink raw reply
* Re: 2.6.22-rc3-mm1
From: Michael Ellerman @ 2007-06-04 2:29 UTC (permalink / raw)
To: Mariusz Kozlowski; +Cc: linuxppc-dev, Andrew Morton
In-Reply-To: <200706012321.16239.m.kozlowski@tuxland.pl>
[-- Attachment #1: Type: text/plain, Size: 857 bytes --]
On Fri, 2007-06-01 at 23:21 +0200, Mariusz Kozlowski wrote:
> BTW. This is 'make allnoconfig && make' result:
>
> MODPOST vmlinux
> ln: accessing `arch/powerpc/boot/zImage': No such file or directory
> make[1]: *** [arch/powerpc/boot/zImage] Error 1
> make: *** [zImage] Error 2
If you check your .config I think you'll find you have none of the
powerpc platforms selected, which means you don't get a zImage. And your
kernel won't boot on any actual hardware either :)
Perhaps one of the platforms should be the default if nothing else is
selected, just so allnoconfig works.
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH] [2.6.22] powerpc: uninline and export virq_to_hw()
From: Olof Johansson @ 2007-06-04 4:47 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
Uninline virq_to_hw and export it so modules can use it. The alternative
would be to export the irq_map array instead, but it's an infrequently
called function, and keeping the array unexported seems considerably
cleaner.
Signed-off-by: Olof Johansson <olof@lixom.net>
diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
index 068377a..0df86cc 100644
--- a/arch/powerpc/kernel/irq.c
+++ b/arch/powerpc/kernel/irq.c
@@ -412,6 +412,12 @@ struct irq_map_entry irq_map[NR_IRQS];
static unsigned int irq_virq_count = NR_IRQS;
static struct irq_host *irq_default_host;
+irq_hw_number_t virq_to_hw(unsigned int virq)
+{
+ return irq_map[virq].hwirq;
+}
+EXPORT_SYMBOL_GPL(virq_to_hw);
+
struct irq_host *irq_alloc_host(unsigned int revmap_type,
unsigned int revmap_arg,
struct irq_host_ops *ops,
diff --git a/include/asm-powerpc/irq.h b/include/asm-powerpc/irq.h
index 4734cc1..05dd5a3 100644
--- a/include/asm-powerpc/irq.h
+++ b/include/asm-powerpc/irq.h
@@ -138,10 +138,7 @@ struct irq_map_entry {
extern struct irq_map_entry irq_map[NR_IRQS];
-static inline irq_hw_number_t virq_to_hw(unsigned int virq)
-{
- return irq_map[virq].hwirq;
-}
+extern irq_hw_number_t virq_to_hw(unsigned int virq);
/**
* irq_alloc_host - Allocate a new irq_host data structure
^ permalink raw reply related
* [PATCH 0/21] This is my pending series for 2.6.23
From: Benjamin Herrenschmidt @ 2007-06-04 5:15 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Paul Mackerras, Christoph Hellwig, cbe-oss-dev
It contains
- My PCI IO allocation rework (the first patch changes generic code
and is in -mm already)
- spufs single step & capabilities support
- my cleanup/merge of the ptrace code
- patches from Christoph Hellwig and myself that fix and merge things
in the signal handling code
I'm still working on saving the top 32 bits of registers on 64 bits
for signals, so that's not included here.
^ 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