* 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] powerpc: Create "rom" (MTD) device prpmc2800
From: Sergei Shtylyov @ 2007-06-03 18:36 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: ppcdev, linux-mtd, Milton Miller
In-Reply-To: <daa1b6f2e18f06f053d538d28d3c046a@kernel.crashing.org>
Segher Boessenkool wrote:
>>> Which Linux driver to use is not something that should
>>> be (directly) communicated in a device tree -- even if
>> Bah... what's "name" and "compatible" properties are for then.
> They communicate to the kernel what exactly a certain device
> is. Nothing more, nothing less. The kernel is supposed to
> use this information to select what device driver to use for
> it. Any extra information the kernel might need/want to drive
> the device is described in other properties (or, in some cases,
> in different device nodes, even).
Yeah, the different node sounds more like this case.
>> 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.
>>> -- the device tree on your board doesn't necessarily
>>> change when your kernel version does.
>> Well, I'm not anticipating any changes either in this case...
> That's a problem then.
At least not in the direction that you wanted us to change the MTD device
node. :-)
>>>> 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 go fix that :-)
Wanna pay me for that? ;-)
>>> Who is talking about "probe-type"? We are talking about "compatible".
>> See my other mail where I've told why I don't consider your example
>> of this prop valid...
> I haven't read that yet, but I can tell you now that I'm already
> very sceptical about the arguments.
> Segher
WBR, Sergei
^ permalink raw reply
* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
From: Sergei Shtylyov @ 2007-06-03 18:31 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, linux-mtd, Milton Miller
In-Reply-To: <e4197fd2753f2b4d548d5dde9e3fd1d3@kernel.crashing.org>
Segher Boessenkool wrote:
>>>> I think "direct-mapped" as compatible is a bit too broad or vague.
>>>> 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?
>>>> (as opossed to a direct-mapped-ram, sram, or some width flash bank).
>>> "actual-name-of-the-chip", "cfi-command-set-#", "cfi" seems
>>> like a good start.
>> 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 obviously completely misunderstand the semantics
> of the "compatible" property.
Oh well, on the chip level, your "compatible" prop would be correct. But
that only means we need another level representating the flash mapping for
which the chip node would be a child... That seems a viable representation but
it would certainly complicate things Linux-wise.
>>> People here tried to create a generic "flash" device binding.
>>> It didn't work out (part of the problem is its scope was way
>>> too big; another problem is it was too Linux-mtd specific).
>> And that's why its worked, and the abstaractly "correct" scheme
>> wouldn't have.
> Ha. Ha. Ha. Great joke :-)
/me bows
>>> Now since the probing is done in platform-specific code here,
>>> you don't *need* an "official" binding -- just get your
>>> "compatible" prop right so you can correctly probe the device
>>> node, and then maybe add some node-specific properties if you
>>> need them.
>> I wonder what are you trying to get us to do: directly call stuff
>> from drivers/mtd/ or what (that's especially starnge because we now
>> have an OF driver for simply mapped NOR flashes)?
> I am pointing out how to do a flash node in a platform-
> specific way, in platform-specific code, since there is
I don't thing that confining the "bloody" MTD details into platform code
would be an acceptable solution.
> no working "generic" way yet (and very likely there will
> never be).
There is something working, at least Linux-generic.
However, the MTD device node was certainly misplaced my me, and probably
oversimplified too -- that's the cost one usually pays when he has to think
something up and to fit it into existing scheme in a limited time. :-<
> Segher
WBR, Sergei
^ permalink raw reply
* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
From: Segher Boessenkool @ 2007-06-03 18:25 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: ppcdev, linux-mtd, Milton Miller
In-Reply-To: <46630256.8050909@ru.mvista.com>
>> Which Linux driver to use is not something that should
>> be (directly) communicated in a device tree -- even if
>
> Bah... what's "name" and "compatible" properties are for then.
They communicate to the kernel what exactly a certain device
is. Nothing more, nothing less. The kernel is supposed to
use this information to select what device driver to use for
it. Any extra information the kernel might need/want to drive
the device is described in other properties (or, in some cases,
in different device nodes, even).
> 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.
>> -- the device tree on your board doesn't necessarily
>> change when your kernel version does.
>
> Well, I'm not anticipating any changes either in this case...
That's a problem then.
>>> 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 go fix that :-)
>> Who is talking about "probe-type"? We are talking about "compatible".
>
> See my other mail where I've told why I don't consider your example
> of this prop valid...
I haven't read that yet, but I can tell you now that I'm already
very sceptical about the arguments.
Segher
^ permalink raw reply
* Re: [PATCH 2/8] Add uli1575 pci-bridge sector to MPC8641HPCN dts file.
From: Gabriel Paubert @ 2007-06-03 18:20 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <3ffee021f3b721bde0253b1310d4958a@kernel.crashing.org>
On Sun, Jun 03, 2007 at 04:42:38PM +0200, Segher Boessenkool wrote:
> >>This is an IBM NVRAM thing -- write address to ISA I/O
> >>0x74/0x75, read/write a byte from 0x76.
> >
> >Data is 0x77 actually. Port 0x76 systematically returns 0xff
> >on this board (I have one at hand right now and am doing
> >accesses with the firmware).
>
> Oh okay, I don't know exactly what chip this is so
> obviously my information isn't 100% ;-)
>
> >>>ISA Device, Slot 0, LogicalDev 0: PNP0B00, SystemPeripheral,
> >>>RealTimeClock, #-1, interface 129
> >>> Device flags 2800: Integrated, Static
> >>> Packets describing allocated resources:
> >>> Variable (16 decoded bits) I/O port
> >>> from 0x0074 to 0x0074, alignment 1, 2 ports
> >>> Variable (16 decoded bits) I/O port
> >>> from 0x0077 to 0x0077, alignment 1, 1 ports
> >>> Chip identification: MOT3040
> >>> Small vendor item type 0x00, data (hex): 01 f8 1f 00 00
> >>
> >>The I/O port numbers here are wrong.
> >
> >No they aren't. It uses exactly the same port as for the NVRAM.
>
> Then its claim to be PNP 0b00 is incorrect.
>
> >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. On these boards the interrupt output
of the RTC is not connected (there is no interrupt
in the list of properties). Interrupt 8 is connected
to a front panel button labeled "ABT".
>
> >>rtc@i70 {
> >> device_type = "rtc";
> >> reg = <1 70 2>;
> >> compatible = "pnpPNP,b00";
> >>}
> >>
> >
> >Nope, there is nothing at 0x70-0x71 (read returns 0xff). The chip
> >is a 48T59.
>
> [Not so easy to find a datasheet for that -- STM M48T59Y
> is what I found in the end]
It is the correct one.
>
> This chip doesn't sit on any I/O port range, it is 8kB
> of direct-mapped standard SRAM stuff. There must be
> some latches or such on your board, or perhaps this is
> driven via some superio chip or something like that.
Indeed, the latches are a bit hard to find (they are inside a
Lattice chip), and the data byte is directly connected to the
ISA bus of the PIB (W83C553 / W53C554).
On some variants of the board, there is not even a superIO chip
(only a discrete UART, TL16C550 or similar).
>
> >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. I don't really remember
also what the chip identification means in the residual data,
but it is always MOT3040. OTOH, there is a but in more
recent versions, that claims that the NVRAM data size is
32768 and not 8192...
>
> 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 :-)
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.
Gabriel
^ permalink raw reply
* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
From: Sergei Shtylyov @ 2007-06-03 18:18 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: ppcdev, linux-mtd, Milton Miller
In-Reply-To: <a5dde31321a50ed198cf4fc199e4af9c@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
> 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.
>>> 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.
Even if we do, it does *not* preclude OS from using both props for the driver
selection.
>>> (as opossed to a direct-mapped-ram, sram, or some width flash bank).
>> Note that we're matching by both "device_type" and "compatible".
> Which is wrong.
Why? And why then it's allowed to match by "device_type"? And why you
haven't complained at MPC5200 IDE driver 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...
>> 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. 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. :-)
Anyway, reasonable suggestions on how to make MTD nodes more viable are
always welcome. I just haven't seen reasonable enough yet. ;-)
> Segher
WBR, Sergei
^ permalink raw reply
* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
From: Sergei Shtylyov @ 2007-06-03 18:03 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: ppcdev, linux-mtd, Milton Miller
In-Reply-To: <d067769912d2ed5c9e1b4770b77303dd@kernel.crashing.org>
Hello.
Segher Boessenkool wrote:
>>> If it's a flash, compatible should be the chip type, and maybe as a
>>> second entry, what type of flash protocol (amd, intel, cfi, ...) it's
>>> compatible.
>> As I've already (and repatedly) stated before,
> And you repeatedly got answers too, yet you choose
> to rehash this whole discussion again.
Not I have started it. And I have my reasons, too. :-)
>> this gets you *nothing* WRT
>> selecting the proper driver in the current Linux MTD subsystem.
> Which Linux driver to use is not something that should
> be (directly) communicated in a device tree -- even if
Bah... what's "name" and "compatible" properties are for then. 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.
> you take the position the device tree is a nice big
> configuration file for Linux, what if a new Linux flash
> subsystem shows up (or even simply a driver got renamed,
> etc.)
There is no direct match in *this* case (for an example of such, refer to
FSL "gianfar" nodes ;-).
> -- the device tree on your board doesn't necessarily
> change when your kernel version does.
Well, I'm not anticipating any changes either in this case...
>> What it
>> actually *needs* to know is flash mapping information,
> It needs to know what kind of flash it is, and how it
> is connected -- i.e., it needs to describe the hardware.
> How Linux then decides to use it is its own game, but
> at least the device tree puts all the information it
> could possibly need out there.
>> 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, this property ("ptobe-type"), although specified in
>> Documentation/powerpc/booting-without-of.txt, is optional.
> Who is talking about "probe-type"? We are talking about "compatible".
See my other mail where I've told why I don't consider your example of
this prop valid...
> Segher
WBR, Sergei
^ permalink raw reply
* [PATCH] IDE: Remove remnants related to dead BLK_DEV_MAC_MEDIABAY CONFIG variable.
From: Robert P. J. Day @ 2007-06-03 17:52 UTC (permalink / raw)
To: bzolnier; +Cc: Linux PPC Mailing List
Remove the two snippets of code conditional on the non-existent CONFIG
variable CONFIG_BLK_DEV_MAC_MEDIABAY.
Signed-off-by: Robert P. J. Day <rpjday@mindspring.com>
---
diff --git a/drivers/ide/legacy/macide.c b/drivers/ide/legacy/macide.c
index c211fc7..b557c45 100644
--- a/drivers/ide/legacy/macide.c
+++ b/drivers/ide/legacy/macide.c
@@ -77,15 +77,6 @@ int macide_ack_intr(ide_hwif_t* hwif)
return 0;
}
-#ifdef CONFIG_BLK_DEV_MAC_MEDIABAY
-static void macide_mediabay_interrupt(int irq, void *dev_id)
-{
- int state = baboon->mb_status & 0x04;
-
- printk(KERN_INFO "macide: media bay %s detected\n", state? "removal":"insertion");
-}
-#endif
-
/*
* Probe for a Macintosh IDE interface
*/
@@ -128,11 +119,6 @@ void macide_init(void)
ide_drive_t *drive = &ide_hwifs[index].drives[0];
drive->capacity64 = drive->cyl*drive->head*drive->sect;
-#ifdef CONFIG_BLK_DEV_MAC_MEDIABAY
- request_irq(IRQ_BABOON_2, macide_mediabay_interrupt,
- IRQ_FLG_FAST, "mediabay",
- macide_mediabay_interrupt);
-#endif
}
break;
--
========================================================================
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 related
* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
From: Segher Boessenkool @ 2007-06-03 17:45 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: ppcdev, Milton Miller
In-Reply-To: <4662FA67.3020107@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"
property. Or you can put some other property in
the flash node for all I care, if that seems
necessary for certain cases.
>> 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?
>> (as opossed to a direct-mapped-ram, sram, or some width flash bank).
>
> Note that we're matching by both "device_type" and "compatible".
Which is wrong.
> 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?
Segher
^ permalink raw reply
* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
From: Segher Boessenkool @ 2007-06-03 17:40 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linuxppc-dev, linux-mtd, Milton Miller
In-Reply-To: <4662EAA9.70104@ru.mvista.com>
>>> I think "direct-mapped" as compatible is a bit too broad or vague.
>
>>> 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?
>>> (as opossed to a direct-mapped-ram, sram, or some width flash bank).
>
>> "actual-name-of-the-chip", "cfi-command-set-#", "cfi" seems
>> like a good start.
>
> 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 obviously completely misunderstand the semantics
of the "compatible" property.
>> People here tried to create a generic "flash" device binding.
>> It didn't work out (part of the problem is its scope was way
>> too big; another problem is it was too Linux-mtd specific).
>
> And that's why its worked, and the abstaractly "correct" scheme
> wouldn't have.
Ha. Ha. Ha. Great joke :-)
>> Now since the probing is done in platform-specific code here,
>> you don't *need* an "official" binding -- just get your
>> "compatible" prop right so you can correctly probe the device
>> node, and then maybe add some node-specific properties if you
>> need them.
>
> I wonder what are you trying to get us to do: directly call stuff
> from drivers/mtd/ or what (that's especially starnge because we now
> have an OF driver for simply mapped NOR flashes)?
I am pointing out how to do a flash node in a platform-
specific way, in platform-specific code, since there is
no working "generic" way yet (and very likely there will
never be).
Segher
^ permalink raw reply
* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
From: Segher Boessenkool @ 2007-06-03 17:36 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: ppcdev, Milton Miller
In-Reply-To: <4662E7EA.70506@ru.mvista.com>
>> If it's a flash, compatible should be the chip type, and maybe as a
>> second entry, what type of flash protocol (amd, intel, cfi, ...) it's
>> compatible.
>
> As I've already (and repatedly) stated before,
And you repeatedly got answers too, yet you choose
to rehash this whole discussion again.
> this gets you *nothing* WRT
> selecting the proper driver in the current Linux MTD subsystem.
Which Linux driver to use is not something that should
be (directly) communicated in a device tree -- even if
you take the position the device tree is a nice big
configuration file for Linux, what if a new Linux flash
subsystem shows up (or even simply a driver got renamed,
etc.) -- the device tree on your board doesn't necessarily
change when your kernel version does.
> What it
> actually *needs* to know is flash mapping information,
It needs to know what kind of flash it is, and how it
is connected -- i.e., it needs to describe the hardware.
How Linux then decides to use it is its own game, but
at least the device tree puts all the information it
could possibly need out there.
> the CFI/JEDEC interface
> then can be deduced by probing
Most of the time, sure. Not always.
> -- so, this property ("ptobe-type"), although
> specified in Documentation/powerpc/booting-without-of.txt, is optional.
Who is talking about "probe-type"? We are talking
about "compatible".
Segher
^ permalink raw reply
* Re: [PATCH 2/8] Add uli1575 pci-bridge sector to MPC8641HPCN dts file.
From: Segher Boessenkool @ 2007-06-03 17:27 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <E1HurPt-0002EP-It@jdl.com>
> I think this is an example of Early Days Misunderstanding Creep.
Is that the official name? :-)
> It was likely one of the very first attempts to write the file for
> any FSL embedded part, and as such, it was probably not so good.
But it also probably worked just fine, given all the
big fat workarounds in the Linux tree parsing code,
which are applied on *all* boards -- this will have
to change sooner or later, just like you don't run
all PCI quirks on all boards: it simply doesn't scale
and the side effects make everything impossible to
understand. In almost all cases, simply fixing the
device tree (Linux' runtime copy, anyway) in some
pre-processing pass is conceptually a much simpler
solution as well.
> Likely, it could use some cleanup. Patches and suggestions welcome.
I rather just wait until things break and then
deprecate (and later remove) support for those
boards. Unless the respective maintainers for
those boards fix things up, all is fine then
of course ;-)
Slightly more seriously -- since there are so
many DTS files, and their number grows real fast;
and since they are non-modular, and mostly copy-
and-paste; most fixes have to be made to lots
of separate DTS files. And that is something
no one can do, since no one can *test* those fixes,
since you need the hardware to do that.
Segher
^ permalink raw reply
* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
From: Sergei Shtylyov @ 2007-06-03 17:29 UTC (permalink / raw)
To: Milton Miller; +Cc: ppcdev
In-Reply-To: <7fc919fce0761f861be3069a853d3169@bga.com>
Hello.
Milton Miller wrote:
>>Find the "rom" device for the prpmc2800 and create a device for it.
>>The device will be picked up by the code in
>>drivers/mtd/maps/physmap_of.c
>>and will setup MTD on that FLASH device.
> ...
>> /*
>>+ * Register a platform device for MTD.
>>+ */
>>+static int __init prpmc2800_register_mtd(void)
>>+{
>>+ struct device_node *np;
>>+
>>+ np = of_find_compatible_node(NULL, "rom", "direct-mapped");
>>+ of_platform_device_create(np, np->name, NULL);
>>+}
>>+arch_initcall(prpmc2800_register_mtd);
> 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).
> 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?
> (as opossed to a direct-mapped-ram, sram, or some width flash bank).
Note that we're matching by both "device_type" and "compatible".
> Actually, looking back at your device tree {1], your list several
> properties for flash, including bank-width and partition names.
> Perhaps first compatible should be direct-mapped-partitioned-flash,
> direct-mapped-partitioned-rom, direct-mapped-rom (to me a
> direct-mapped-rom driver would expose one section of address space
> read-only).
This would serve no purpose, as the driver that would catches all these is
signle one, drivers/mtd/maps/physmap_of.c...
> I'm assuming that your driver for this "direct-mapped"
> device will look at these properties from the of device node and
> call the mtd layer somewhat directly with their contents.
Yeah, it does.
> [1] http://ozlabs.org/pipermail/linuxppc-dev/2007-May/035858.html
> milton
> PS: I know you've posted this a few times. I'm just behind in
> my reading and replying :-).
WBR, Sergei
^ permalink raw reply
* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
From: Sergei Shtylyov @ 2007-06-03 16:22 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, linux-mtd, Milton Miller
In-Reply-To: <bd6ef296692e8cfb81118f2dc85189a5@kernel.crashing.org>
Hello.
Segher Boessenkool wrote:
>>I think "direct-mapped" as compatible is a bit too broad or vague.
>>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?
>>(as opossed to a direct-mapped-ram, sram, or some width flash bank).
> "actual-name-of-the-chip", "cfi-command-set-#", "cfi" seems
> like a good start.
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.
>>Actually, looking back at your device tree {1], your list several
>>properties for flash, including bank-width and partition names.
>>Perhaps first compatible should be direct-mapped-partitioned-flash,
>>direct-mapped-partitioned-rom, direct-mapped-rom (to me a
>>direct-mapped-rom driver would expose one section of address space
>>read-only). I'm assuming that your driver for this "direct-mapped"
>>device will look at these properties from the of device node and
>>call the mtd layer somewhat directly with their contents.
> People here tried to create a generic "flash" device binding.
> It didn't work out (part of the problem is its scope was way
> too big; another problem is it was too Linux-mtd specific).
And that's why its worked, and the abstaractly "correct" scheme wouldn't have.
> Now since the probing is done in platform-specific code here,
> you don't *need* an "official" binding -- just get your
> "compatible" prop right so you can correctly probe the device
> node, and then maybe add some node-specific properties if you
> need them.
I wonder what are you trying to get us to do: directly call stuff from
drivers/mtd/ or what (that's especially starnge because we now have an OF
driver for simply mapped NOR flashes)?
> Segher
WBR, Sergei
^ permalink raw reply
* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
From: Sergei Shtylyov @ 2007-06-03 16:10 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: ppcdev, Milton Miller
In-Reply-To: <1180769992.14025.1.camel@localhost.localdomain>
Hello.
Benjamin Herrenschmidt wrote:
> On Fri, 2007-06-01 at 23:30 -0500, Milton Miller wrote:
>
>>Actually, looking back at your device tree {1], your list several
>>properties for flash, including bank-width and partition names.
>>Perhaps first compatible should be direct-mapped-partitioned-flash,
>>direct-mapped-partitioned-rom, direct-mapped-rom (to me a
>>direct-mapped-rom driver would expose one section of address space
>>read-only). I'm assuming that your driver for this "direct-mapped"
>>device will look at these properties from the of device node and
>>call the mtd layer somewhat directly with their contents.
> If it's a flash, compatible should be the chip type, and maybe as a
> second entry, what type of flash protocol (amd, intel, cfi, ...) it's
> compatible.
As I've already (and repatedly) stated before, this gets you *nothing* WRT
selecting the proper driver in the current Linux MTD subsystem. What it
actually *needs* to know is flash mapping information, the CFI/JEDEC interface
then can be deduced by probing -- so, this property ("ptobe-type"), although
specified in Documentation/powerpc/booting-without-of.txt, is optional.
> Ben.
WBR, Sergei
^ permalink raw reply
* ppc assembler problem with calling C funciton in entry.S
From: Nicholas Mc Guire @ 2007-06-03 13:53 UTC (permalink / raw)
To: linuxppc-embedded
Hi !
Im trying to intercept rfi in entry.S - the intercept function called
emulate_iret is called (get the printk) but then the box hangs - so I
guess Im messing up the stack some how - but I don't understand how
- could someone point me to the error or to documentation that could
help ?
kernel is 2.6.19.2 (ELDK)
Toolchain ELDK
HW is AMCC 440GR
The dummy intercept function basically does a printk and messes around
on the stack a bit - sould have no sideffects.
static int g_test_int;
void emulate_iret(void)
{
static int g[2];
++g_test_int;
printk("emulate_iret!\n");
g[0] = g_test_int;
g[1] = g_test_int + 10;
}
The modified transfer_to_handler_cont - just calls emulate_iret and
restors (code between #if 1 and #endif was added):
in arch/ppc/kernel/entry.S
transfer_to_handler_cont:
3:
#if 1 /* this code block was added */
bl emulate_iret
lwz r9,_LINK(r1) /* restore the link register */
mtlr r9
lwz r10,_MSR(r1) /* may be changed during call */
FIX_SRR1(r10, r0) /* this macro is empty for (440 GR) */
#endif
mflr r9
lwz r11,0(r9) /* virtual address of handler */
lwz r9,4(r9) /* where to go when done */
mtspr SPRN_SRR0,r11
mtspr SPRN_SRR1,r10
mtlr r9
SYNC
RFI /* jump to handler, enable MMU */
dissassembly of emulate_iret:
c000688c <emulate_iret>:
c000688c: 94 21 ff e0 stwu r1,-32(r1)
c0006890: bf a1 00 14 stmw r29,20(r1)
c0006894: 3f a0 c0 2c lis r29,-16340
c0006898: 81 3d 41 34 lwz r9,16692(r29)
c000689c: 7c 08 02 a6 mflr r0
c00068a0: 3c 60 c0 20 lis r3,-16352
c00068a4: 39 29 00 01 addi r9,r9,1
c00068a8: 38 63 97 f8 addi r3,r3,-26632
c00068ac: 90 01 00 24 stw r0,36(r1)
c00068b0: 91 3d 41 34 stw r9,16692(r29)
c00068b4: 48 01 9f cd bl c0020880 <printk>
c00068b8: 81 5d 41 34 lwz r10,16692(r29)
c00068bc: 3d 60 c0 2c lis r11,-16340
c00068c0: 38 0a 00 0a addi r0,r10,10
c00068c4: 39 2b 41 24 addi r9,r11,16676
c00068c8: 90 09 00 04 stw r0,4(r9)
c00068cc: 80 01 00 24 lwz r0,36(r1)
c00068d0: bb a1 00 14 lmw r29,20(r1)
c00068d4: 7c 08 03 a6 mtlr r0
c00068d8: 38 21 00 20 addi r1,r1,32
c00068dc: 91 4b 41 24 stw r10,16676(r11)
c00068e0: 4e 80 00 20 blr
thx !
hofrat
^ permalink raw reply
* Re: [PATCH] NET: add MAINTAINERS entry for ucc_geth driver
From: Jeff Garzik @ 2007-06-03 15:48 UTC (permalink / raw)
To: Li Yang; +Cc: netdev, linuxppc-embedded
In-Reply-To: <465679FA.8010702@freescale.com>
Li Yang wrote:
> Signed-off-by: Li Yang <leoli@freescale.com>
> ---
> MAINTAINERS | 7 +++++++
> 1 files changed, 7 insertions(+), 0 deletions(-)
applied, w/ Kim's ack
^ permalink raw reply
* Re: [PATCH 2/8] Add uli1575 pci-bridge sector to MPC8641HPCN dts file.
From: Jon Loeliger @ 2007-06-03 14:50 UTC (permalink / raw)
To: Gabriel Paubert; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <20070603083339.GB2157@iram.es>
So, like, the other day Gabriel Paubert mumbled:
>
> This said, I'm looking at device trees right now, and I can understand
> that interrupt-parent of the 8259 is &mpic in mpc8641_hpcn.dts, but
> I don't understand at all why it is &pci1 on the mpc85??cds.dts.
>
> But the definition of the ISA bridge in these files is very strange to
> start with: I've never seen an ISA bridge with only an interrupt controller
> on it, no interrupts are connected to it and its reg property is
> almost certainly wrong. Maybe it is an example of things that should
> not be done.
I think this is an example of Early Days Misunderstanding Creep.
It was likely one of the very first attempts to write the file for
any FSL embedded part, and as such, it was probably not so good.
Likely, it could use some cleanup. Patches and suggestions welcome.
jdl
^ permalink raw reply
* Re: [PATCH 2/8] Add uli1575 pci-bridge sector to MPC8641HPCN dts file.
From: Segher Boessenkool @ 2007-06-03 14:42 UTC (permalink / raw)
To: Gabriel Paubert; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <20070603124357.GA6419@iram.es>
>> This is an IBM NVRAM thing -- write address to ISA I/O
>> 0x74/0x75, read/write a byte from 0x76.
>
> Data is 0x77 actually. Port 0x76 systematically returns 0xff
> on this board (I have one at hand right now and am doing
> accesses with the firmware).
Oh okay, I don't know exactly what chip this is so
obviously my information isn't 100% ;-)
>>> ISA Device, Slot 0, LogicalDev 0: PNP0B00, SystemPeripheral,
>>> RealTimeClock, #-1, interface 129
>>> Device flags 2800: Integrated, Static
>>> Packets describing allocated resources:
>>> Variable (16 decoded bits) I/O port
>>> from 0x0074 to 0x0074, alignment 1, 2 ports
>>> Variable (16 decoded bits) I/O port
>>> from 0x0077 to 0x0077, alignment 1, 1 ports
>>> Chip identification: MOT3040
>>> Small vendor item type 0x00, data (hex): 01 f8 1f 00 00
>>
>> The I/O port numbers here are wrong.
>
> No they aren't. It uses exactly the same port as for the NVRAM.
Then its claim to be PNP 0b00 is incorrect.
> Otherwise the "feature" of this RTC is that its interrupt
> is not connected.
Dunno what you mean here?
>> rtc@i70 {
>> device_type = "rtc";
>> reg = <1 70 2>;
>> compatible = "pnpPNP,b00";
>> }
>>
>
> Nope, there is nothing at 0x70-0x71 (read returns 0xff). The chip
> is a 48T59.
[Not so easy to find a datasheet for that -- STM M48T59Y
is what I found in the end]
This chip doesn't sit on any I/O port range, it is 8kB
of direct-mapped standard SRAM stuff. There must be
some latches or such on your board, or perhaps this is
driven via some superio chip or something like that.
> Actually I wonder
> whether using PNP0B00 is correct in the residual data here.
It's not correct at all, no.
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.
Segher
^ permalink raw reply
* Re: [PATCH 2/8] Add uli1575 pci-bridge sector to MPC8641HPCN dts file.
From: Gabriel Paubert @ 2007-06-03 12:43 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <ee4d3e25c4b6ede84483399249929632@kernel.crashing.org>
On Sun, Jun 03, 2007 at 01:42:22PM +0200, Segher Boessenkool wrote:
> >>>This said, I'm looking at device trees right now, and I can
> >>>understand
> >>>that interrupt-parent of the 8259 is &mpic in mpc8641_hpcn.dts, but
> >>>I don't understand at all why it is &pci1 on the mpc85??cds.dts.
> >>
> >>Perhaps the 8259 IRQ output is routed to a PCI
> >>interrupt. If not, this is just plain wrong.
> >
> >Maybe, but it ultimately has to go the mpic, no?
>
> Yes, certainly. A PowerPC CPU has only one connection
> to one interrupt controller, everything else hangs below
> that one.
>
> >>I have no idea what this whole 8259-ack thing is
> >>so I cannot comment further.
> >
> >It is a way to fetch the vector from the interrupt controller.
>
> [big snip]
>
> Thanks, I did know that stuff, just not the device
> tree property :-)
>
> But a great explanation anyway.
>
> >If you need more details, ask me.
>
> That was quite detailed enough, heh :-)
>
> >Now a question: how would you describe the nvram and RTC
> >on the PreP boards that I have?
> >
> >In the residual data I have:
> >
> >ISA Device, Slot 0, LogicalDev 0: IBM0008, SystemPeripheral, NVRAM,
> >#-1, IndirectNVRAM
> > Device flags 2800: Integrated, Static
> > Packets describing allocated resources:
> > Variable (16 decoded bits) I/O port
> > from 0x0074 to 0x0074, alignment 1, 2 ports
> > Variable (16 decoded bits) I/O port
> > from 0x0077 to 0x0077, alignment 1, 1 ports
>
> This is an IBM NVRAM thing -- write address to ISA I/O
> 0x74/0x75, read/write a byte from 0x76.
Data is 0x77 actually. Port 0x76 systematically returns 0xff
on this board (I have one at hand right now and am doing
accesses with the firmware).
>
> This node should be a child of the "isa" (or isa
> compatible) bus, and look something like this:
>
> nvram@i74 {
> device_type = "nvram";
> regs = <1 74 3>;
> compatible = "whatever-chip-this-is";
> #bytes = <2000>; // 8kB, just an example
> }
>
> >ISA Device, Slot 0, LogicalDev 0: PNP0B00, SystemPeripheral,
> >RealTimeClock, #-1, interface 129
> > Device flags 2800: Integrated, Static
> > Packets describing allocated resources:
> > Variable (16 decoded bits) I/O port
> > from 0x0074 to 0x0074, alignment 1, 2 ports
> > Variable (16 decoded bits) I/O port
> > from 0x0077 to 0x0077, alignment 1, 1 ports
> > Chip identification: MOT3040
> > Small vendor item type 0x00, data (hex): 01 f8 1f 00 00
>
> The I/O port numbers here are wrong.
No they aren't. It uses exactly the same port as for the NVRAM.
Otherwise the "feature" of this RTC is that its interrupt
is not connected.
>
> rtc@i70 {
> device_type = "rtc";
> reg = <1 70 2>;
> compatible = "pnpPNP,b00";
> }
>
Nope, there is nothing at 0x70-0x71 (read returns 0xff). The chip
is a 48T59. Look in prep_setup.c in arch/ppc/platforms.
Motorola and IBM boards use different RTC.
The lines:
} else {
TODC_INIT(TODC_TYPE_MK48T59, PREP_NVRAM_AS0, PREP_NVRAM_AS1,
PREP_NVRAM_DATA, 8);
}
show that it uses the same addresses as the nvram. Actually I wonder
whether using PNP0B00 is correct in the residual data here.
Gabriel
^ permalink raw reply
* Re: [PATCH 2/8] Add uli1575 pci-bridge sector to MPC8641HPCN dts file.
From: Segher Boessenkool @ 2007-06-03 11:42 UTC (permalink / raw)
To: Gabriel Paubert; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <20070603101052.GA3313@iram.es>
>>> This said, I'm looking at device trees right now, and I can
>>> understand
>>> that interrupt-parent of the 8259 is &mpic in mpc8641_hpcn.dts, but
>>> I don't understand at all why it is &pci1 on the mpc85??cds.dts.
>>
>> Perhaps the 8259 IRQ output is routed to a PCI
>> interrupt. If not, this is just plain wrong.
>
> Maybe, but it ultimately has to go the mpic, no?
Yes, certainly. A PowerPC CPU has only one connection
to one interrupt controller, everything else hangs below
that one.
>> I have no idea what this whole 8259-ack thing is
>> so I cannot comment further.
>
> It is a way to fetch the vector from the interrupt controller.
[big snip]
Thanks, I did know that stuff, just not the device
tree property :-)
But a great explanation anyway.
> If you need more details, ask me.
That was quite detailed enough, heh :-)
> Now a question: how would you describe the nvram and RTC
> on the PreP boards that I have?
>
> In the residual data I have:
>
> ISA Device, Slot 0, LogicalDev 0: IBM0008, SystemPeripheral, NVRAM,
> #-1, IndirectNVRAM
> Device flags 2800: Integrated, Static
> Packets describing allocated resources:
> Variable (16 decoded bits) I/O port
> from 0x0074 to 0x0074, alignment 1, 2 ports
> Variable (16 decoded bits) I/O port
> from 0x0077 to 0x0077, alignment 1, 1 ports
This is an IBM NVRAM thing -- write address to ISA I/O
0x74/0x75, read/write a byte from 0x76.
This node should be a child of the "isa" (or isa
compatible) bus, and look something like this:
nvram@i74 {
device_type = "nvram";
regs = <1 74 3>;
compatible = "whatever-chip-this-is";
#bytes = <2000>; // 8kB, just an example
}
> ISA Device, Slot 0, LogicalDev 0: PNP0B00, SystemPeripheral,
> RealTimeClock, #-1, interface 129
> Device flags 2800: Integrated, Static
> Packets describing allocated resources:
> Variable (16 decoded bits) I/O port
> from 0x0074 to 0x0074, alignment 1, 2 ports
> Variable (16 decoded bits) I/O port
> from 0x0077 to 0x0077, alignment 1, 1 ports
> Chip identification: MOT3040
> Small vendor item type 0x00, data (hex): 01 f8 1f 00 00
The I/O port numbers here are wrong.
rtc@i70 {
device_type = "rtc";
reg = <1 70 2>;
compatible = "pnpPNP,b00";
}
You might want to set the register range to 4 in both
cases, esp. if the chip actually decodes those ranges;
there are no useful registers there though (AFAIK).
> It is the same chip that has the NVRAM and the RTC, only that
> the last 8 bytes of the NVRAM change with time. I've not found
> the last "Small vendor item" described in any doc, but it looks
> like a byte of 1, followed by the offset of the RTC inside the
> NVRAM in little-endian byte order.
>
> But essentially the problem is that I have two logically
> different devices in the same chip.
That isn't a problem -- logically they are both children
of the ISA bus, just describe them like that. This is
done all the time, just look at some SoC tree ;-)
> Of course the size of
> the nvram should be somewhere (8k-8, starting at 0).
It's implicit from the chip type; the Device Support
Extensions recommended practice defines the "#bytes"
property for nvram devices though.
Segher
^ permalink raw reply
* Re: Please pull powerpc.git master branch
From: Michael Neuling @ 2007-06-03 10:54 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18018.5690.655733.126061@cargo.ozlabs.ibm.com>
> Please do:
>
> git pull \
> git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git master
>
> to get some more powerpc bug fixes, compile fixes, and a comment-only
> change, for 2.6.22.
Paulus,
Could you also grab this stolen time fix for 2.6.22?
http://patchwork.ozlabs.org/linuxppc/patch?id=11341
Thanks,
Mikey
^ permalink raw reply
* Re: [PATCH 2/8] Add uli1575 pci-bridge sector to MPC8641HPCN dts file.
From: Gabriel Paubert @ 2007-06-03 10:10 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <34eddd7ce58e7983017077454d592332@kernel.crashing.org>
On Sun, Jun 03, 2007 at 10:57:59AM +0200, Segher Boessenkool wrote:
> >>>>Oh what the hell, I'm too curious... "pnpPNP,0" it is.
> >>>>
> >>>>>I believe that "8259" should appear somewhere because of the
> >>>>>"8259-interrupt-acknowledge" property (defined in CHRP bindings)
> >>>>>which you can have on the parent bridge to speed up interrupt
> >>>>>vector acquisition.
> >>>>
> >>>>You're not CHRP so you have nothing to do with the CHRP
> >>>>bindings...
> >>>
> >>>Still, you are close to CHRP
> >>
> >>Not at all, the rest of the device interrupt subsystem
> >>is very different, too.
> >
> >Given how well you agree, I understand how other people
> >might get a bit confused ;-)
>
> Heh. Let's look at it some other way: if you use
> "chrp,iic", this node needs to be handled by either
> CHRP platform code (which will not work, you aren't
> CHRP), or by platform-specific code. If you use the
> generic "pnpPNP,0" name, it can (in theory) be handled
> by architecture-neutral code, even.
>
Thanks for this explanation.
> For the foreseeable future (or perhaps forever) the
> interrupt stuff will be set up from the platform
> code, so there is no direct impact on Linux. You
> might want to support other OSes, or be more future-
> proof, or generically want a cleaner device tree.
>
> >This said, I'm looking at device trees right now, and I can understand
> >that interrupt-parent of the 8259 is &mpic in mpc8641_hpcn.dts, but
> >I don't understand at all why it is &pci1 on the mpc85??cds.dts.
>
> Perhaps the 8259 IRQ output is routed to a PCI
> interrupt. If not, this is just plain wrong.
Maybe, but it ultimately has to go the mpic, no?
I can see how the cascade of interrupt parents and
other specifications could lead there.
>
> >But the definition of the ISA bridge in these files is very strange to
> >start with: I've never seen an ISA bridge with only an interrupt
> >controller
> >on it, no interrupts are connected to it
>
> Maybe that's why it works ;-)
That maybe the best explanation.
>
> >and its reg property is
> >almost certainly wrong.
>
> <19000 0 0 0 0> could be right, that means device d#18
> on PCI bus 1. There is a missing bus #1 node in between
> though. And the unit address is @12 in that case,
> not @19000 .
>
> >Maybe it is an example of things that should
> >not be done.
>
> Maybe :-)
>
> >>>and the CHRP bindings do apply :-)
> >>
> >>Nope.
> >
> >At least the 8259-interrupt-acknowledge property of the bus
> >on which the ISA bridge is found should keep its name. It's what
> >the kernel uses.
>
> Only the CHRP Linux platform code should use that.
> It's not necessarily a bad idea to define your
> platform's binding to do the same, of course --
> other platform's bindings do not apply to yours,
> but there is no harm in creating a certain similarity.
>
> I have no idea what this whole 8259-ack thing is
> so I cannot comment further.
It is a way to fetch the vector from the interrupt controller.
Among all the types of cycles defined by PCI (configuration,
I/O and memory spaces read and write), there is one which
is generated by the host bridge when an x86 processor
acknowledges an interrupt (it has changed with the APIC
and IO-APIC where "A" stands for awkward IMO[1]).
The sequence of events is the following:
- an interrupt is raised
- when switching to the interrupt handler, the
processor generates a special bus cycle
- this is translated by the host bridge into
a PCI interrupt acknowledge cycle
- one and only one agent on the bus behind the host bridge
(this cycle is not propagated by P2P bridges) answers
by placing a byte sized interrupt vector on the bus.
- this vector is used by the processor to index into the
interrupt descriptor table and starts execution wherever
it is told to go.
Generating a pci interrupt acknowledge cycle is a faster
way to get at the vector than doing this explicitly in
the controller: a simple byte fetch instead of 2 or
4 I/O accesses guardered by a lock acquisition and
release.
If you need more details, ask me.
Now a question: how would you describe the nvram and RTC
on the PreP boards that I have?
In the residual data I have:
ISA Device, Slot 0, LogicalDev 0: IBM0008, SystemPeripheral, NVRAM, #-1, IndirectNVRAM
Device flags 2800: Integrated, Static
Packets describing allocated resources:
Variable (16 decoded bits) I/O port
from 0x0074 to 0x0074, alignment 1, 2 ports
Variable (16 decoded bits) I/O port
from 0x0077 to 0x0077, alignment 1, 1 ports
No packets describing possible resources.
No packets describing compatible resources.
ISA Device, Slot 0, LogicalDev 0: PNP0B00, SystemPeripheral, RealTimeClock, #-1, interface 129
Device flags 2800: Integrated, Static
Packets describing allocated resources:
Variable (16 decoded bits) I/O port
from 0x0074 to 0x0074, alignment 1, 2 ports
Variable (16 decoded bits) I/O port
from 0x0077 to 0x0077, alignment 1, 1 ports
Chip identification: MOT3040
Small vendor item type 0x00, data (hex): 01 f8 1f 00 00
No packets describing possible resources.
No packets describing compatible resources.
It is the same chip that has the NVRAM and the RTC, only that
the last 8 bytes of the NVRAM change with time. I've not found
the last "Small vendor item" described in any doc, but it looks
like a byte of 1, followed by the offset of the RTC inside the
NVRAM in little-endian byte order.
But essentially the problem is that I have two logically
different devices in the same chip. Of course the size of
the nvram should be somewhere (8k-8, starting at 0).
Gabriel
[1] Read the last paragraph of http://lkml.org/lkml/2006/11/1/294,
and I believe that it is an understatement. There are also Linus'
rants about handling of edge triggered interrupts in APIC: it's
fairly easy to lose them, that's what cutting-edge (pun intended)
innovation is :-)
^ permalink raw reply
* Re: [PATCH 2/8] Add uli1575 pci-bridge sector to MPC8641HPCN dts file.
From: Segher Boessenkool @ 2007-06-03 10:02 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <1180861939.31677.15.camel@localhost.localdomain>
>> I have no idea what this whole 8259-ack thing is
>> so I cannot comment further.
>
> When you get an IRQ on your main PIC (MPIC for example) which happens
> to
> be the cascade to the 8259, you have two ways of retreiving the actual
> 8259 interrupt source.
>
> One is the "poll" method which goes read IOs on the 8259. The other one
> is to generate a PCI interrupt acknowledge cycle on the bus that leads
> to the 8259. If your bridges properly forward it all the way to the ISA
> bridge, it should "mimminc" the x86 interrupt acknowledge and return
> the
> interrupt number (an INTACK cycle on PCI is pretty much a read from a
> broadcast address).
Ah, that stuff.
> So on CHRP, that property in a PHB indicates, when possible, and
> address
> you can ioremap and readb from to generate an INTACK cycle on that bus
> and retreive the pending IRQ of any legacy PIC on that segment.
Right, so it is just misnamed (and belongs in the "reg"
property for that specific PHB anyway). It has nothing
to do with 8259, it is part of the PCI spec.
> In theory, in fact, MPIC itself, at least the PCI variant of it, is
> also
> supposed to be able to respond to these rather than reading an MMIO
> register (remember, MPIC was supposed to be useable on x86 too, though
> I
> don't know if that was never actually implemented).
OpenPIC was I think. No idea if it ever actually got
used anywhere though.
Segher
^ permalink raw reply
* Re: [PATCH 2/8] Add uli1575 pci-bridge sector to MPC8641HPCN dts file.
From: Segher Boessenkool @ 2007-06-03 9:59 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <1180861620.31677.10.camel@localhost.localdomain>
> But feel free to disagree, it's not of terrible importance. The board
> code is the one to "find" the PICs, including the cascaded 8259, the
> acutal 8259 driver takes whatever node is given to it, so as long as
> your .dts matches your board, it doesn't matter that much.
Here at least we do agree -- with the one added nit that
when using "chrp,iic" you're _forcing_ it to be platform
code that handles this device. But like I said before,
not all that important.
>> This said, I'm looking at device trees right now, and I can understand
>> that interrupt-parent of the 8259 is &mpic in mpc8641_hpcn.dts, but
>> I don't understand at all why it is &pci1 on the mpc85??cds.dts.
>
> Maybe the ISA IRQ on that board is routed to a PCI IRQ# line in which
> case it will use the ISA bridge pci device to lookup in the PCI
> interrupt map... it's a bit weird but as long as it resolves using the
> standard parser, it's perfectly fine.
I don't think it resolves using the _standard_ parser,
it needs a few of the workarounds. But the tree there
is completely broken anyway, fixing it is highly
recommended ;-)
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