Re: pci and pcie device-tree binding - range No cells
On 12/10/2012 12:38 PM, Benjamin Herrenschmidt wrote: On Mon, 2012-12-10 at 21:43 +, Grant Likely wrote: Sorry for my pci ignorance (have never got hw for mb/zynq) I just want to get better overview how we should we our drivers to be compatible. Does it mean that pci is supposed be always 64 bit wide? And there is no option to have just 32bit values. Yes, PCIe addressing is always 64 bits wide. Even on 32bit PCI systems we use 64 bit PCI addressing in the device tree. Right. The size format of an address cell for PCI is specified in the OF PCI bindings and we follow that binding. It's always 3 cells. .. and the reason why it must be 3 cells, even if the host PCI bus only supports 32-bit addressing, is because a plug-in PCI card has no way of knowing what the host supports. Cheers, Ben. ___ devicetree-discuss mailing list devicetree-disc...@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: fpga driver on custom PPC target platform (P4080) ...
On 11/7/2011 10:09 AM, Robert Sciuk wrote:
In my continuing saga of dev/tree driver development, I have a problem which
might be obvious to those who have more experience in such matters.
I'm a bit perplexed on the tree nodes for the localbus/simplebus nodes for my
FPGA. CS0 is reserved for booting (from NOR flash as required by our design),
CS1 is tied to an FPGA which will always be present. CS2 actually is tied to
both of two (optional) fpga's, which have been previously mapped by U-Boot
(BRn/ORn configuration). Should I specify a ranges command as follows? This
seems somehow wrong, to me, and I'm wondering if there is an alternative
representation which would work better in this case. If you recall, the
programming control lines are handled on the I2C bus, via a gpio controller.
In an ideal world, the optional FPE1 and FPE2 fpgas will have the identical
.bts stream, and should support the option to program both simultaneously, or
each individually, but I'm at a loss as how to best represent this in the tree.
I would be tempted to add another level of hierarchy as a container for
the two FPEs on CS2.
localbus@ffe124000 {
compatible = fsl,p4080-elbc, fsl,elbc, simple-bus;
reg =0xf 0xfe124000 0 0x1000;
interrupts =25 2 0 0;
interrupt-parent =mpic;
#address-cells =2;
#size-cells =1;
/* Local bus region mappings */
ranges =0 0 0xf 0xe800 0x0800 /* CS0: Boot
flash */
1 0 0xf 0xd000 0x7fff /* CS1: FPGA0
- LIM */
2 0 0xf 0xd100 0x7fff /* CS2: FPGA1
- FPE1 */
2 0 0xf 0xd200 0x7fff; /* CS2: FPGA2 -
FPE2 */
flash@0,0 {
compatible = cfi-flash;
reg =0 0 0x0800;
bank-width =2;
device-width =2;
#size-cells =1;
#address-cells =1;
partition@0 {
label = rcw;
reg =0x0 0x2;
read-only;
};
partition@4 {
label = saveenv;
reg =0x4 0x2;
};
partition@700 {
label = fman-firmware;
reg =0x700 0x2;
read-only;
};
partition@7f8 {
label = u-boot;
reg =0x7f8 0x8;
read-only;
};
};
lim: fpga@1, {
}
fpe1: fpga@2, {
}
fpe2: fpga@2, {
}
Again, any pointers here would be greatly appreciated ...
Cheers,
Rob Sciuk
___
devicetree-discuss mailing list
devicetree-disc...@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: RFC: Mega rename of device tree routines from of_*() to dt_*()
On 11/25/2010 5:15 PM, Michael Ellerman wrote: On Thu, 2010-11-25 at 09:17 -0700, Grant Likely wrote: On Thu, Nov 25, 2010 at 6:34 AM, Michael Ellerman mich...@ellerman.id.au wrote: On Thu, 2010-11-25 at 01:03 +1100, Michael Ellerman wrote: Hi all, There were some murmurings on IRC last week about renaming the of_*() routines. ... The thinking is that on many platforms that use the of_() routines OpenFirmware is not involved at all, this is true even on many powerpc platforms. Also for folks who don't know the OpenFirmware connection it reads as of, as in a can of worms. ... So I'm hoping people with either say YES this is a great idea, or NO this is stupid. I'm still hoping, but so far it seems most people have got better things to do, and of those that do have an opinion the balance is slightly positive. I assume you'll be also publishing the script that you use for generating the massive patch. I expect that there will be a few iterations of running the rename script to convert over all the stragglers. Yep sure, I'll just make it less crap first. It should also be negotiated with Linus about when this patch should get applied. I do NOT want to cause massive merge pain during the merge window. Obviously. Andrew/Linus: Before Michael proceeds too far with this rename, are you okay with a mass rename of the device tree functions from of_* to dt_*? Nobody likes the ambiguous 'of_' prefix (of? of what?), but to fix it means large cross-tree patches and potential merge conflicts. It'd also be good to hear from DaveM, sparc is the platform with the strongest link to real OF AFAIK, so the of_() names make more sense there. One Laptop Per Child ships real Open Firmware on its x86 Linux systems, of which approximately 2 million have been shipped or ordered. An ARM version, also with OFW, is in the works. From the standpoint of number of units in the field actually running Linux, I expect that compares favorably with SPARC. That said, I don't particularly like the abbreviation of either; I abbreviate Open Firmware as OFW. I don't mind using dt_ to apply to device tree things; I think it's clearer than of_. Ideally, it would be nice to acknowledge the historical connection in some way, but confusing nomenclature probably is not the way to go about it. So here's a first cut of a patch to add the new names. I've not touched of_platform because that is supposed to go away. That will lead to some odd looking code in the interim, but I think is the right approach. I would split it up into separate dt*.h files, one for each of*.h file so that the #include lines can be changed in the C code at the same time. Each dt*.h file would include it's of*.h counterpart. Then after the code is renamed, and a release or two has passed to catch the majority of users, the old definitions can be moved into the dt*.h files. Yep that sounds like a plan. I did it as a single header for starters so I could autogenerate the rename script easily. However, it may be better to move and rename the definitions immediately, and leave #define of_* dt_* macros in the old of*.h files which can be removed with a simple patch after all the users are converted. That would have a smaller impact in the cleanup stage. True, though a bigger impact to start with. I did that originally but decided it might be better to start with the minimal patch to add the new names. That way Linus might accept it this release, meaning we'd have the new names in place for code in -next. Most of these are straight renames, but some have changed more substantially. The routines for the flat tree have all become fdt_foo(). I'd be inclined to drop early_init from them too, because they're basically all about early init, but Grant said he'd prefer not to I think. I've also renamed the flat tree tag constants to match libfdt. It is all about early init now in Linus' tree, but Stephen Neuendorffer has patches that use the fdt code at driver probe time for parsing device tree fragments that describe an FPGA add-in board. OK fair enough. I've left for_each_child_of_node(), because I read it as of, but maybe it's OF? hahaha! I never considered that it might be OF, but now I probably won't be able to help but read it that way! I like Geert's suggestion of dt_for_each_child_node OK, I like it the way it is, but if the consensus is to change it then we can. There's a bunch actually: for_each_node_by_name(dn, name) \ for_each_node_by_type(dn, type) \ for_each_compatible_node(dn, type, compatible) \ for_each_matching_node(dn, matches) \ for_each_child_of_node(parent, child) \ for_each_node_with_property(dn, prop_name) \ So either dt_for_each_blah(), or for_each_dt_node_blah() ? /* include/linux/device.h */ #define dt_match_table of_match_table #define dt_node of_node This could be very messy. I've nervous about using #define to rename structure members.
Re: RFC: Mega rename of device tree routines from of_*() to dt_*()
One Laptop Per Child ships real Open Firmware on its x86 Linux systems, of which approximately 2 million have been shipped or ordered. An ARM version, also with OFW, is in the works. OK. I don't see any code under arch/x86 or arch/arm that uses of_() routines though? Or is it under drivers or something? Andres Salomon has been working for some time to get some Open Firmware support for x86 upstream. As you can probably imagine, it has been slow going, but seems to be getting close. The OLPC ARM work is just beginning, so nothing has been submitted yet. The first hardware prototypes are still being debugged. Lennert Buytenhek is the key OS person who will be involved. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2] powerpc: pcm030/032: add pagesize to dts
In general I think it's better to report parameter values directly, instead of inferring them from manufacturer and part numbers. That way you at least have a fighting chance of avoiding a kernel upgrade when a part changes. Of course, that only works when the device tree is exported from the boot firmware instead of having to carry the device tree inside the kernel. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V4] powerpc/prom: Export device tree physical address via proc
Grant Likely wrote: On Thu, Jul 15, 2010 at 12:58 PM, Matthew McClintock m...@freescale.com wrote: On Thu, 2010-07-15 at 12:37 -0600, Grant Likely wrote: On Thu, Jul 15, 2010 at 12:03 PM, Matthew McClintock m...@freescale.com wrote: Yes. Where would we get a list of memreserve sections? I would say the list of reserves that are not under the control of Linux should be explicitly described in the device tree proper. For instance, if you have a region that firmware depends on, then have a node for describing the firmware and a property stating the memory regions that it depends on. The memreserve regions can be generated from that. Ok, so we could traverse the tree node-by-bode for a persistent-memreserve property and add them to the /memreserve/ list in the kexec user space tools? I *think* that is okay, but I'd like to hear from Segher, Ben, Mitch, David Gibson, and other device tree experts on whether or not that exact property naming is a good one. In the /memory node, the reg property specifies all of memory and the available property specifies those portions that the OS is permitted to use. Subtracting available from reg gives you the regions that are used for other purposes, such as frame buffers or firmware needs. Often the OS can just look at available, as it typically wants to know what it can use, not what it can't. The full size as given by reg is useful for system configuration reporting purposes - the user thinks he bought 2G of memory, so it's good to report that 2G is indeed installed in the system. (As an aside, when I first invented Open Boot, 16M was a typical memory size. I'm rather gratified that the overall device tree design has held up reasonably well over the scale factors that have happened since then.) It would be possible to mark the used regions with a finer-grained distinction than they are unavailable to the OS, but that quickly gets into the diminishing returns realm - a lot of trouble for fairly small incremental value. The PC BIOS E820 memory description scheme has a few extra categories of memory. The one category that seems like it might (just barely) be worth the effort is temporarily used by firmware but reclaimable after a certain point - but then you have to define rather carefully the reclamation time and conditions. Write up a proposed binding (you can use devicetree.org). Post it for review (make sure you cc: both devicetree-discuss and linuxppc-dev, as well as cc'ing the people listed above.) Should we export the reserve sections instead of the device tree location? It shouldn't really be something that the kernel is explicitly exporting because it is a characteristic of the board design. It is something that belongs in the tree-proper. ie. when you extract the tree you have data telling what the region is, and why it is reserved. Agreed. We just need a way to preserve what was there at boot to pass to the new kernel. Yet there is no differentiation between the board-dictated memory reserves and the things that U-Boot/Linux made an arbitrary decision on. The solution should focus not on can I throw this one away? but rather Is this one I should keep? :-) A subtle difference, I know, but it changes the way you approach the solution. Fair enough. I think the above solution will work nicely, and I can start implementing something if you agree - if I interpreted your idea correctly. Although it should not require any changes to the kernel proper. Correct. g. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Request review of device tree documentation
Mike Rapoport wrote: Mitch Bradley wrote: The second topic is the hypothetical use of OFW as a HAL. That will not happen for several reasons. The opposition to the idea is widespread and deeply held, and there are good arguments to support that opposition. Furthermore, the economic conditions necessary for the creation of such a HAL do not exist in the ARM world, nor indeed in the Linux world in general. (The necessary condition is the ability for one company to impose a substantial change by fiat - essentially a monopoly position.) Shall we agree, then, that any further discussion of the HAL issue is just for fun, and that nobody needs to feel threatened that it would actually happen? I've recently worked with vendor versions of U-Boot for advanced ARM SoCs. There is already *huge* chunk of HAL code in those versions. And if there would be possibility to have callbacks into the firmware these chunks would only grow, IMHO. How can there be HAL code in U-Boot unless there is already the possibility to have callbacks into the firmware? It is not HAL if it can't be called. The potential for vendors breaking out of the debugging use case and turning it into a HAL is miniscule, because a) The callback is disabled by default b) The technical challenges of the callback interface limit its applicability to specific wizard user scenarios c) OFW is unlikely to achieve sufficient market penetration for the HAL thing to be worth doing ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Request review of device tree documentation
Mike Rapoport wrote: Mitch Bradley wrote: Mike Rapoport wrote: Mitch Bradley wrote: The second topic is the hypothetical use of OFW as a HAL. That will not happen for several reasons. The opposition to the idea is widespread and deeply held, and there are good arguments to support that opposition. Furthermore, the economic conditions necessary for the creation of such a HAL do not exist in the ARM world, nor indeed in the Linux world in general. (The necessary condition is the ability for one company to impose a substantial change by fiat - essentially a monopoly position.) Shall we agree, then, that any further discussion of the HAL issue is just for fun, and that nobody needs to feel threatened that it would actually happen? I've recently worked with vendor versions of U-Boot for advanced ARM SoCs. There is already *huge* chunk of HAL code in those versions. And if there would be possibility to have callbacks into the firmware these chunks would only grow, IMHO. How can there be HAL code in U-Boot unless there is already the possibility to have callbacks into the firmware? Currently it aims to abstract hardware from U-Boot and reuse the same HW access code across operating systems and bootloaders. If this code would have callbacks I afraid the things would became worse. The only way I can understand what you said is if I assume that by callback, you mean the following sequence: a) U-boot loads and executes the OS, providing to the OS the address of some HW access routines that it can use b) The OS calls one of those HW access routines c) During the execution of that HW access routine, that routine calls back into the OS, before returning. So a call into the OS is nested inside a call into U-boot resident code. If that is what you are worried about, it is not what we were discussing. We were discussing - and many people were against - step (b). Are you saying that step (b) - the OS calling into routines provided by U-Boot - is already the status quo? It is not HAL if it can't be called. The potential for vendors breaking out of the debugging use case and turning it into a HAL is miniscule, because a) The callback is disabled by default b) The technical challenges of the callback interface limit its applicability to specific wizard user scenarios c) OFW is unlikely to achieve sufficient market penetration for the HAL thing to be worth doing ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Request review of device tree documentation
Mike Rapoport wrote: Mitch Bradley wrote: Mike Rapoport wrote: Mitch Bradley wrote: Mike Rapoport wrote: Mitch Bradley wrote: The second topic is the hypothetical use of OFW as a HAL. That will not happen for several reasons. The opposition to the idea is widespread and deeply held, and there are good arguments to support that opposition. Furthermore, the economic conditions necessary for the creation of such a HAL do not exist in the ARM world, nor indeed in the Linux world in general. (The necessary condition is the ability for one company to impose a substantial change by fiat - essentially a monopoly position.) Shall we agree, then, that any further discussion of the HAL issue is just for fun, and that nobody needs to feel threatened that it would actually happen? I've recently worked with vendor versions of U-Boot for advanced ARM SoCs. There is already *huge* chunk of HAL code in those versions. And if there would be possibility to have callbacks into the firmware these chunks would only grow, IMHO. How can there be HAL code in U-Boot unless there is already the possibility to have callbacks into the firmware? Currently it aims to abstract hardware from U-Boot and reuse the same HW access code across operating systems and bootloaders. If this code would have callbacks I afraid the things would became worse. The only way I can understand what you said is if I assume that by callback, you mean the following sequence: a) U-boot loads and executes the OS, providing to the OS the address of some HW access routines that it can use b) The OS calls one of those HW access routines c) During the execution of that HW access routine, that routine calls back into the OS, before returning. So a call into the OS is nested inside a call into U-boot resident code. If that is what you are worried about, it is not what we were discussing. We were discussing - and many people were against - step (b). Are you saying that step (b) - the OS calling into routines provided by U-Boot - is already the status quo? I'm also objecting the step (b) and, fortunately, it's not yet the status quo. Current U-Boot/kernel implementations I've encountered still do not have OS calls to resident HW access routines. But if such calls would be allowed, my impression is that SoC vendors would make extensive use of them. One could argue that a feature that vendors would use extensively is one that is sorely needed from their point of view. One counterargument, of course, is that there is a better way. But it is only better under a cost function that values things differently than the vendors value them. Were that not so, the vendors would gladly use the better way and not be tempted to use the objectionable feature. (Unless, of course, the vendors are just ignorant or unskilled - but I generally find that different cost functions cause more disconnects than lack of ability.) Which of course raises the question: How does the Linux community view such SoC vendors? Are they embraced and eagerly supported, or (either openly or secretly) viewed as a nuisance? How does the widespread objection to something that such vendors would make extensive use of mesh with that view? It is not HAL if it can't be called. The potential for vendors breaking out of the debugging use case and turning it into a HAL is miniscule, because a) The callback is disabled by default b) The technical challenges of the callback interface limit its applicability to specific wizard user scenarios c) OFW is unlikely to achieve sufficient market penetration for the HAL thing to be worth doing ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Request review of device tree documentation
Benjamin Herrenschmidt wrote: On Sun, 2010-06-13 at 23:13 -0600, Grant Likely wrote: We use that to suck the device-tree, which we flatten, and then re-enter the kernel with the common entry interface. I don't think I want to do the same on ARM. I'd rather have the prom_init stuff in a boot wrapper, or have OFW itself generate the flat representation before booting the kernel. But then it's no longer OF. IE. A compliant OF implementation provides a client interface API :-) This is going to be especially important if Mitch wants to keep OF alive. I suppose it could be done via a wrapper like prom_init, which flattens the tree, and sticks somewhere in a property the address of the OF client interface callback though it's a tad awkward. If well defined, I suppose Mitch might even be able to make his OF natively boot kernels that way but that's of course up to him. I'm willing to create a flattened tree. I can provide both a client interface and a flattened tree. The kernel probably won't use the client interface to any significant extent. Way back in the misty annals of history, I dreamed of having a common interface between firmware and OSs. That didn't happen. Every OS insisted on defining its own interface and creating a custom bootloader, or in some cases a half dozen of them. I'm trying to constrain the number of things that could go wrong by defining only one way for getting the device tree data into the kernel. I understand, and the flattened method is the most versatile, I'm just pointing out the situation here :-) Right. We don't need to use OFW/RTAS to handle this use case. Definitely not. It will depend on whatever hypervisor interface is implemented in a given environment. Though I do like the idea of passing precompiled bits of .dtb around for hotplug :-) We could make that a standard way of KVM to do things in embedded space. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Request review of device tree documentation
Russell King - ARM Linux wrote: On Sun, Jun 13, 2010 at 11:23:45PM -0600, Grant Likely wrote: Or perhaps the MMU and caches can be turned off for the duration of the callback. I don't have the details of ARM MMUs and caches reloaded into my head yet. Maybe next week... We've had these kinds of questions in the past. Doing what you're asking above is not really an option - it requires: 1. disable all IRQs 2. setup 1:1 MMU mappings for code to turn off MMU (requires new page table) 3. disable imprecise exceptions 4. flush caches and TLBS 5. jump to 1:1 mapping area for code to disable MMU 6. disable caches and mmu 7. call function 8. flush caches and TLBs 9. re-enable caches and mmu 10. re-enable imprecise exceptions 11. switch back to original MMU mappings 12. re-enable all IRQs This is fine if you don't care at all about interrupt latency. Unfortunately, most people do care about interrupt latency because that directly affects interactivity and system performance. The called function could not enable interrupts or exceptions - as the CPU vectors are in virtual space, disabling the MMU effectively makes them disappear. Moreover, with the MMU and caches disabled, the CPU performance is extremely poor, so the called function will run slowly. So, disabling the MMU isn't really viable. None of this is a deal-breaker for the kind of debugging tasks that are the primary use case for the callback. Now, if the external code was fully PIC, we could then run it with the MMU enabled. However, this wouldn't really help - the external code could not access any devices without knowledge of how the kernel setup the V:P translations. So you'd need to pass some kind of data structure giving locations of devices to the called code - but then what if the kernel doesn't have the device mapped? ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Request review of device tree documentation
I shall try to clarify this discussion. There are actually two different things being discussed. The first is, I hope, not too controversial. The second is so controversial as to be a hopeless cause. First, the primary use case for keeping OFW alive is for debugging purposes. OFW remains resident in memory so that, if the OS is set to allow it (not the default), a hot-key freezes the OS and enters OFW, where a human can inspect the state of devices and OS data structures. A high skill level is required, so it's okay if some fiddling is necessary to find or establish virtual addresses or do similar magic . In my career of working closely with hardware manufacturers, I and others have found this feature to be extremely helpful. Often it has resulted in the resolution of difficult problems that were blocking the ability to ship the product - problems that resisted other kernel debugging techniques. The second topic is the hypothetical use of OFW as a HAL. That will not happen for several reasons. The opposition to the idea is widespread and deeply held, and there are good arguments to support that opposition. Furthermore, the economic conditions necessary for the creation of such a HAL do not exist in the ARM world, nor indeed in the Linux world in general. (The necessary condition is the ability for one company to impose a substantial change by fiat - essentially a monopoly position.) Shall we agree, then, that any further discussion of the HAL issue is just for fun, and that nobody needs to feel threatened that it would actually happen? The potential for vendors breaking out of the debugging use case and turning it into a HAL is miniscule, because a) The callback is disabled by default b) The technical challenges of the callback interface limit its applicability to specific wizard user scenarios c) OFW is unlikely to achieve sufficient market penetration for the HAL thing to be worth doing ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Request review of device tree documentation
Nicolas Pitre wrote: On Mon, 14 Jun 2010, Mitch Bradley wrote: First, the primary use case for keeping OFW alive is for debugging purposes. OFW remains resident in memory so that, if the OS is set to allow it (not the default), a hot-key freezes the OS and enters OFW, where a human can inspect the state of devices and OS data structures. A high skill level is required, so it's okay if some fiddling is necessary to find or establish virtual addresses or do similar magic . Why would you impose such pain on yourself in order to try to make OFW a viable debugging tool on ARM for live kernels, while you can achieve the same and more much less intrusively and so much more safely with a JTAG based debugger? If the cost of a JTAG solution is a concern, you can order USB based JTAG dongles on the net for less than $30 and use them with OpenOCD[1]. If OFW is present on the machine, when a customer reports a problem I can tell them to do x and y and z and tell me what they see. In this manner, I have often solved difficult problems in minutes or hours. Arranging for a JTAG dongle to appear at the customer site, then getting it set up and the necessary software installed and configured on a suitable host system, typically requires several days at best, plus potentially a lot of fiddling depending on what sort of host system the customer happens to have. The phrase impose such pain on yourself presupposes that the technical challenges are much harder than they actually are. In fact, most of the pain comes from dealing with the yuck, why would you ever want to do that argument. I first experienced that argument in 1982, when Tom Lyon - Sun's Unix driver expert at the time - threatened to scratch my disk if I ported Forth to the Sun 1 machine. Tom later recanted and said that he was very glad that I had done so, after I used it to solve several stop-ship problems that came close to killing the company. Otherwise, what's wrong with already supported kgdb, or even kdb? [1] http://openocd.berlios.de/web/ Requires setup. The power of it's just there, flip a switch to turn it on has to be experienced in the heat of battle to be appreciated. The other difference is that conventional debuggers focus on the problem of inspecting and controlling the execution of preexisting programs, instead of on the problem of constructing quick tests to test hypotheses. While it is possible to use them to poke around, it quickly becomes cumbersome if you need to do anything more complicated than just looking. OFW's built-in programming language is particularly well suited for making little test loops on-the-fly. Also, OFW has drivers for most of all of the system's hardware, and those drivers are independently developed from the Linux drivers. That often serves as a valuable second opinion to help discover the root cause of hardware misbehavior. Nicolas ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Request review of device tree documentation
Benjamin Herrenschmidt wrote: On Sat, 2010-06-12 at 19:39 -1000, Mitch Bradley wrote: Minimally, OFW needs to own some memory that the kernel won't steal. OFW on ARM is position-independent, so it can be tucked up at the top of memory fairly easily. Amen :-) To call back into OFW, the virtual mapping for that memory needs to be reestablished. That's a nasty part unless ARM provides a usable real mode which allows MMIO accesses, which I -think- it does. I don't remember the details that much. IIRC - and I could be wrong - ARM does have a real mode, but the catch is that you must have the MMU on in order to use the caches, to distinguish between memory and MMIO. So you take a fairly hefty performance hit. I'm running my test build right now with caches off, and the performance is okay for interactive work, but I'll want to have them on for startup and bootloading, so as not to negatively impact the boot time. Maybe we could define a binding tho where we could somewhat standardize the portion of the virtual address space used by OF. IE. from the top of the address space down to the max size it requires. It might require some games to play with the fixmap on ARM side tho... That would be okay as far as I'm concerned. Another option would be something more RTAS-like where a specific call can be done by the OS itself to 'relocate' (not physically but virtually in this case) OF into the OS preferred location. Be prepared to have multiple of these called though as kernels kexec into one another. That might be a bit harder, but still do-able. Or perhaps the MMU and caches can be turned off for the duration of the callback. I don't have the details of ARM MMUs and caches reloaded into my head yet. Maybe next week... Forgot most of it too. Looks like it's about time I read the ARM architecture again, this sounds like fun :-) BTW. I notice no ARM list is CCed on this discussion ... maybe we should fix that ? Sounds like a good idea. Do you know which list(s) would be good candidates? Also, for debugging, OFW typically needs access to a UART. If the OS is using the UART, it's often possible for OFW to use it just by turning off interrupts and polling the UART. That might not be a big deal unless the OS plays with the clocks which it -does- tend to do. It might be worth defining some kind of property OF puts in the UART node to inform the OS not to play games and keep that one enabled, though that could affect power management, so might need to be conditional on some nvram option (debug-enabled?) The use case for a dynamic device tree is not compelling. Right, generally not, except in virtualized environments (see my other response). Now, the -one- thing that WILL happen if we have something like OF that remains alive is of course vendors will try to use it as a HAL. You know as well as I do that it -will- happen :-) I tried to be very clear when I was developing OFW that is is not a HAL. I knew that it would be impractical to pin down a coherent set of assumptions in the face of the many different OSs - and versions of the same OS - that were extant at the time. Digital was fairly committed to the HAL approach on Alpha, but they had two different HAL ABIs, one for VMS and a different one for Ultrix! So they were unable to solve the problem for N=2, where both OSs were under their control. There's two reasons that typically happen. The misguided good one which is to think it helps keeping a single/more maintainable kernel image by stuffing the horrible details of nvram, rtc, etc.. access, poweron/off GPIOs, clock control, etc... in there. Whether or not it is misguided depends on your cost structure. For hardware companies that don't control (and don't want to control) the OS, it is one of only two possible ways to ship product. Either you make hardware that is 100% compatible with something that the OS already supports, or you have a HAL at some level. The PC industry, of course, has played both games, and by and large has been economically successful. The bad one which is to stash code you don't want to show the source code for (codec control, etc...). This is bad for so many reasons that I don't think I need to even start listing them :-) So that's something that will have to be strongly kept in check and fought I suspect. Either fought or embraced. To the extent that it is possible to focus solely on Linux and ARM, one could image doing a good HAL. (The reason I say ARM-only is because the only other non-x86 architecture that has any legs left is PowerPC, and PPC already has a coherent story.) To some extent, in fact, doing that sort of stuff in OF or even in RTAS like we do on power is even worse than ACPI-like tables. At least with those tables, the interpreter is in the operating system, thus can run with interrupts on, scheduling on, etc... I have an FCode interpreter
Re: Request review of device tree documentation
Grant Likely wrote: I also changed the property in the cpu nodes from model to compatible so that the exact CPU version can be specified. This isn't actually in any spec anywhere, but I need something to properly identify the different ARM cores. Mitch, I know you were working on a draft ARM binding a while ago, have you resurrected it at all? As it turns out, today I re-began ARM OFW work in earnest, after a hiatus of something like 10 years. I haven't thought much about a binding yet. I'm still getting my head around the current state of the ARM art. How do you think the core should be identified? When I was last working on ARM, few ARM devices had enough resources to run a general purpose OS. To first approximation, StrongARM was the only game in town - so there wasn't much need to address the identification question. It seems that many of the differences at the CPU level can be determined by looking at coprocessor registers. For what purpose(s) do we need to identify the core? That will inform our choice of a core ID schema. Cheers, g. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Request review of device tree documentation
Benjamin Herrenschmidt wrote: On Sat, 2010-06-12 at 20:45 +1000, Benjamin Herrenschmidt wrote: On Fri, 2010-06-11 at 22:19 -1000, Mitch Bradley wrote: It seems that many of the differences at the CPU level can be determined by looking at coprocessor registers. For what purpose(s) do we need to identify the core? That will inform our choice of a core ID schema. The primary thing I see would be architecture version compliance, though this is better carried additionally via a binary field in the header or a GPR at the entry point, to help the initial asm code to setup the MMU etc... before getting into C code. Also, if you're going to revive a real OF port to ARM (with client interface etc...), should we start considering moving some of powerpc's prom_init.c to a generic place ? IE. prom_init is a trampoline that uses the client interface to essentially create a flatten device-tree and enter the kernel via the common epapr style entry point. The main drawback is that it doesn't allow to keep OF alive along with the OS, but then, only sparc does that successfully and I'm not sure it's something that would be practical to do on ARM either. I'm certainly going to try keeping OFW alive. On the x86 OLPC machines, the ability to dive into OFW via a SysRq key combo was very helpful for debugging some difficult problems. The team has asked me to support the feature on ARM. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Request review of device tree documentation
Grant Likely wrote: On Sat, Jun 12, 2010 at 4:52 PM, Benjamin Herrenschmidt b...@kernel.crashing.org wrote: On Sat, 2010-06-12 at 06:30 -1000, Mitch Bradley wrote: I'm certainly going to try keeping OFW alive. On the x86 OLPC machines, the ability to dive into OFW via a SysRq key combo was very helpful for debugging some difficult problems. The team has asked me to support the feature on ARM. Oh well, if you can and can convince the ARM kernel folks to do the necessary changes ... :-) What is needed to keep OFW alive? I've got no problem with doing so if it isn't invasive, and as long as the same boot entry interface can be used. Minimally, OFW needs to own some memory that the kernel won't steal. OFW on ARM is position-independent, so it can be tucked up at the top of memory fairly easily. To call back into OFW, the virtual mapping for that memory needs to be reestablished. Or perhaps the MMU and caches can be turned off for the duration of the callback. I don't have the details of ARM MMUs and caches reloaded into my head yet. Maybe next week... Also, for debugging, OFW typically needs access to a UART. If the OS is using the UART, it's often possible for OFW to use it just by turning off interrupts and polling the UART. One thing tho, you will only benefit from the whole infrastructure we have created accross platforms in linux if the device-tree is sucked into linux at boot. IE. Linux will not do constant accesses to OF for the DT. Even sparc converted to that now. That means that if your device-tree has a dynamic nature, we'll need to come up with a way to inform the kernel of changes in it so it can update it's copy accordingly. What is the use-case for having a dynamic device tree? The use case for a dynamic device tree is not compelling. In SPARC / Solaris land, Open Boot managed the non-volatile configuration variables, which the OS could access and modify dynamically as properties in /options. The OS didn't have to know the storage layout nor the hardware details of the storage device. Convenient, but not hugely important. I can see keeping OFW alive being useful for some debug facilities, but once the kernel has started, I'm really not interested in relying on firmware to manage the hardware. That's sort of a self-fulfilling prophecy. If the OS doesn't trust the firmware, there is no pressure for the firmware to get it right. In PC land, the current status quo is that Windows depends on ACPI so heavily that BIOS vendors pretty much have to get that part of the puzzle right. Microsoft did a thorough job of creating certification tests and enforcing their use. I'm not praising ACPI, just pointing out the dynamics that result from assignment of responsibility. That said, I'm not interested in pushing the issue. It's okay with me if the device tree is static as far as the kernel is concerned, and callbacks to OFW are only used for debugging purposes. (but then again it's no secret that I'm suspicious of anything that depends on runtime interaction with firmware). g. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Request review of device tree documentation
Benjamin Herrenschmidt wrote: On Fri, 2010-06-11 at 16:47 -0700, Dan Malek wrote: Hi Grant. On Jun 11, 2010, at 3:59 PM, Grant Likely wrote: I've been doing a bit of work on some introductory level documentation of the flattened device tree. Wow, I feel empowered to create device trees now :-) Seriously, I never understood this well and this is a great document. I have one source of confusion. Your first Initial structure example uses 'compatible' to describe the machine, the paragraph below then mentions the 'model' property, and all subsequent examples use model. Does this mean if I use just the single line in the dts, using 'compatible' implies the ARM machine ID? If I have more description I use 'model'? Normally, compatible is what is used for code to match, and model is more like a user-visible thingy. Indeed, one common use of model - at least in the systems I work on - is to display the name of the machine in a system identification banner that the user sees. It's possible to peek at 'model' tho, in some cases, I've seen the case for example where things are -supposed- to be identical from an arch point of view, have the same compatible, but later on, a quirk is found and a test against model is used to differentiate. But that's something to avoid in general. Better off having multiple strings in compatible then, one more generic to have the BSP match against, and one more specific that can be used if a quirk is needed. Of course, it doesn't help that all pseries have chrp and nothing else as compatible :-) But then, both IBM and Apple have been quite lax with their (ab)use of the DT. Cheers, Ben. ___ devicetree-discuss mailing list devicetree-disc...@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 6/6] of/device: populate platform_device (of_device) resource table on allocation
Wow, there is some serious bikeshedding going on with this argument about structures and arrays . ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3] powerpc: Add i8042 keyboard and mouse irq parsing
Grant Likely wrote:
On Tue, May 25, 2010 at 2:09 AM, Martyn Welch martyn.we...@ge.com wrote:
Currently the irqs for the i8042, which historically provides keyboard and
mouse (aux) support, is hardwired in the driver rather than parsing the
dts. This patch modifies the powerpc legacy IO code to attempt to parse
the device tree for this information, failing back to the hardcoded values
if it fails.
Signed-off-by: Martyn Welch martyn.we...@ge.com
---
v2: This patch no longer requires the DTS files to be modified, reading the
interrupts from the current location as suggested by Grant.
v3: Code compacted as suggested by Grant.
arch/powerpc/kernel/setup-common.c | 13 +
drivers/input/serio/i8042-io.h |5 +
2 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/kernel/setup-common.c
b/arch/powerpc/kernel/setup-common.c
index 48f0a00..3d169bb 100644
--- a/arch/powerpc/kernel/setup-common.c
+++ b/arch/powerpc/kernel/setup-common.c
@@ -94,6 +94,10 @@ struct screen_info screen_info = {
.orig_video_points = 16
};
+/* Variables required to store legacy IO irq routing */
+int of_i8042_kbd_irq;
+int of_i8042_aux_irq;
+
#ifdef __DO_IRQ_CANON
/* XXX should go elsewhere eventually */
int ppc_do_canonicalize_irqs;
@@ -567,6 +571,15 @@ int check_legacy_ioport(unsigned long base_port)
np = of_find_compatible_node(NULL, NULL, pnpPNP,f03);
if (np) {
parent = of_get_parent(np);
+
+ of_i8042_kbd_irq = irq_of_parse_and_map(parent, 0);
+ if (!of_i8042_kbd_irq)
+ of_i8042_kbd_irq = 1;
+
+ of_i8042_aux_irq = irq_of_parse_and_map(parent, 1);
+ if (!of_i8042_aux_irq)
+ of_i8042_aux_irq = 12;
+
The patch looks okay to me.
BTW, where is the i8042 binding documented? Ben, is this location of
the kbd/mouse irq historical,
i8042 is, of course, the legacy PC keyboard interrupt controller, and
the IRQs that it generates on behalf of its attached keyboard and mouse
have always been 1 and 12 on the PC platforms that drive the hardware
designs of junk I/O chips. By the time that PowerPC came on the market,
the i8042 functionality was always implemented as a subsystem within a
much larger SuperIO chip, which often included the (legacy PC)
interrupt controller functionality. Those SuperIO chips let you move
the IRQ numbers around for some of the included devices, but I don't
remember whether or not you could move the IRQs for the keyboard and
mouse. Even if you could, nobody ever did it, because people were so
accustomed to 1 and 12 being keyboard and mouse that changing them would
just cause too much confusion. There was also the issue of setting the
edge/level and polarity correctly for the various IRQs. Moving the
kbd/mouse IRQs would have a ripple effect on other old-and-dusty code
that nobody wanted to touch.
The design of PReP (PowerPC Reference Platform) was amusing to watch.
Apple was wanting to make it into a 68K Macintosh I/O system with a
PowerPC grafted in, while IBM wanted a conventional PC with a PowerPC
grafted in. IBM stacked the committee and basically got what they
wanted - a PC with a different CPU chip. At the Comdex show where they
rolled out the PReP spec, Apple had their own announcement to make -
Apple wasn't going to use PReP. So IBM's power play backfired.
The PReP committee (consisting of representatives from IBM, Apple,
Motorola, and a few other bit players like myself) then went into panic
mode, and came out with CHRP. CHRP was PReP with a legacy Macintosh I/O
system bolted onto the side. So you had the worst of both worlds. In
the PReP mode, you had PC-style I/O like IDE, i8042, 8259 interrupt
controller, etc. In the Mac mode, you had SCSI (using a horrible
ancient programming model that nobody else was using anymore), ADB, and
an OpenPIC interrupt controller. The chipsets had to support both sets.
The final shoe dropped 18 months later, when Steve Jobs re-took Apple
and announced that Apple was not in fact going to license MacOS for use
on third-party CHRP machines.
The original binding documents for the PC-style I/O system were driven
from the IBM side. I may have written some of the text (or maybe not; I
forget), but it was IBM who stipulated how it was going to work.
or is it just something that we happened
to get when the .dts files were first created? Having the irq
specified directly in the kbd or aux nodes would make a lot more
sense, and if this isn't something already nailed down, then it
probably does make sense to move the irq specification, fall back to
the parent node to still support older trees, and with the hard coded
irq numbers as the last resort.
Cheers,
g.
___
devicetree-discuss mailing list
Re: [PATCH] powerpc/fsl: add device tree binding for QE firmware
Timur Tabi wrote:
Grant Likely wrote:
Without the compatible property, the only way I'd know that the child node
contains a firmware is to look at the actual name of the child node, which (as
Scott and I believe) is not better than a compatible property.
If it is always a child of a qe node, then I've got no objections.
I have no problem with putting the firmware node as a child of the QE node and
skipping the phandle property, but only as long as there's only one QE node.
Would you agree that this is bad:
qe1: q...@e008 {
compatible = fsl,qe;
qefw: fsl,qe_firmware {
compatible=fsl,qe-firmware;
fsl,firmware = /bininc/(firmware-blob.bin);
fsl,qe-firmware-eccr = 0x 0x1230;
}
...
}
qe2: q...@e009 {
compatible = fsl,qe;
fsl,firmware-phandle = qefw;
...
}
It not any worse than having the firmware blob anywhere else that is not
hierarchically related.
If one insists on purity of hierarchy, one could introduce a node above
qe1 and qe2 and put the firmware blob in that parent node. That
captures the assertion that the two qe devices are in fact identical so
the same firmware is suitable for both.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/fsl: add device tree binding for QE firmware
Timur Tabi wrote: Grant Likely wrote: Nah. That looks totally fine. Not having the firmware under a qe node would look bad to me. You don't think it weird to have one QE node reference data from another QE node, or that the DTS implies that the firmware belongs to one QE more than it belongs to the other? It is certainly not symmetric. Putting the firmware blob somewhere completely unrelated to either node maintains the symmetry between the two qe nodes, but only weakly captures the relationship between the firmware blob and the qe nodes. It is then necessary to invoke a strong naming convention for the firmware blob, because you don't have the hierarchy to do the name space disambiguation for you. As I see it, the three possibilities, and their disadvantages, are: a) Firmware blob in some random place - requires strong naming of either firmware blob property or node containing it. b) Firmware blob within first qe node - asymmetric. c) Firmware blob in new parent of both qe nodes - requires introduction of otherwise-unneeded hierarchy level. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/fsl: add device tree binding for QE firmware
It seems to me that there are plausible use cases for both direct-inclusion and indirection. I don't see any real problems with either, so I would vote for specifying both alternatives. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/fsl: add device tree binding for QE firmware
Most firmware is 8-12KB, so this will make for one ugly DTS. Plus, there's the issue of distributing non-GPL firmware data inside a DTS, which is GPL. You've got the distribution problem that needs to be solved regardless because it cannot be part of U-Boot either. How do you plan to handle QE firmware distribution and loading? Or you could use real Open Firmware, which is free as in free, instead of free as in whatever RMS says. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/3] video: add support for getting video mode from device tree
Hi Anatolij,
[added cc: to devicetree-disc...@lists.ozlabs.org]
On Sat, Feb 27, 2010 at 2:58 PM, Anatolij Gustschin ag...@denx.de wrote:
Framebuffer drivers may want to get panel timing info
from the device tree. This patch adds appropriate support.
Subsequent patch for FSL DIU frame buffer driver makes use
of this functionality.
I think this is moving in the right direction, but there needs to
debate review over the binding before committing to anything.
Please write a patch that documents the new binding in
Documentation/powerpc/dts-bindings. All new bindings should be
documented and reviewed on devicetree-discuss before merging any
drivers that use them into mainline.
From what I can tell by reading your code, I suspect that the binding
you've designed will solve your immediate problem, but won't be able
to handle anything slightly more complex, but it also looks like the
binding has been designed to be generic, usable by any display device.
First off, I did a tiny amount of research, and I didn't find any
existing OpenFirmware bindings for describing video displays.
Otherwise, I'd suggest considering that.
From the little bit that I know, it seems that for most video devices
(ie. PCs) the video card discovers the capabilities of the screen by
reading the monitor's EDID data. However, in your particular case
embedded case, a fixed flat panel is attached, and there isn't any
EDID data provided. Therefore, you need an alternate method of
describing the display capabilities. Rather than designing something
entirely new, you may want to consider using the EDID data format
directly; or at least cover the same things that EDID describes. The
downside to using EDID directly is that it is a packed binary format
that isn't parseable by mere mortals; but the data contained in it
seems about right. The upside is the kernel already knows what to do
with EDID data.
Otherwise you risk designing something that won't be useful for
anything much outside of your own use case. For example, the binding
I see from the code cannot handle a display with multiple output
modes.
Also, since you're now in the realm of describing a video display,
which is separate from the display controller, you should consider
describing the display in a separate device tree node. Maybe
something like this...
video {
compatible = fsl,mpc5121-diu;
display {
compatible = vendor,model;
edid = [edid-data];
};
};
As it turns out, I'm doing exactly that - exporting verbatim EDID data
as the value of the edid property - for the display node on the Via
version of the OLPC machine. The kernel driver uses it instead of
trying to obtain the EDID data from the monitor, because the builtin
OLPC display cannot supply EDID data through the usual hardware interfaces.
Mitch
Cheers,
g.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 04/11] of/flattree: eliminate cell_t typedef
Right, that's the only sane way to do it, I just didn't remember off hand what was said in the OF spec :-) 3.2.2.1.2 Property values The property-encoding format is independent of hardware byte order and alignment characteristics. The encoded byte order is well-defined (in particular, it is big endian). ... ... -- 32-bit integer. A 32-bit integer is encoded into a property value byte array by storing the most significant byte at the next available address, followed (at address+1) by the high middle byte, the low middle byte, and (at address+3) the least significant byte. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH 00/12] Merge common OpenFirmware device tree code
Sun3 doesn't have OF When I was first developing Open Boot for the SPARCstation-1, I was also simultaneously trying to do it for a Sun-3 system that was being built at the same time. It proved to be too much to do both jobs at the same time, especially in light of all the hardware debugging that is part of a new system bringup. So I gave up on Sun 3 and just focused on SS-1. That particular Sun-3 machine never sold very well, while the SS-1 was very popular. That was Sun's last 680x0 machine. Personally, I think that continuing to support Sun-3 in Linux is not useful in a practical sense. To the extent that supporting long-obsolete platforms and devices makes the job harder for current systems, it is actually harmful. Portability and generality is good in some theoretical rightness sense, but there are practical limits. Code can become so heavily layered that approaching it requires a huge commitment of effort to learn all the artificial layers. Sometimes you have to prune the dead branches so the living ones can get light and air. Taking this one step further, I don't see any real good reason to continue supporting Sun4 going forward. I got rid of my Sun4 systems long ago because it was just too hard to keep them working - after having used them long after most people had moved on. Dropping Sun3 and Sun4 eliminates all vestiges of the sunmon interface and also allows dropping support for OBP version 1, which only shipped on SS1-class machines - the first machines in the Sun4c subclass. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC] Clock binding
On Tue, 2009-08-18 at 14:21 +1000, Benjamin Herrenschmidt wrote: So here's a followup to my discussion about the clock API. Really nobody has a comment here ? :-) Not even Mitch ? I refrained from commenting as I didn't want to get involved in an endless argument about goodness. Indexed arrays are appropriate for some cases and names are better for others. Names are especially good for large spaces that are sparse or weakly-structured. The same is true for subroutine arguments. It's nice to be able to write setup_uart(baud=115200, flow_control=rts_cts), but you would go crazy (or become a COBOL programmer) if you had to name every argument to every subroutine. Open Firmware often avoids indexed structures. Cases in point include the use of named properties instead of fixed structures and named methods instead of function pointer arrays. Open Firmware's use of arrays for reg properties seems like the right choice for that particular case, but shouldn't be construed to suggest that arrays are good for everything. One problem you run into with names is the registration authority problem. Who maintains the list of valid names to avoid collisions and to ensure consistent spelling? It's a solvable problem, but one that must be considered. Of course, a related problem exists with indices - what is the meaning of index value N, and how do you manage the addition of new fields and deletion of others? Names are easier to manage in some cases and indices easier in others. In the particular case of a clock binding, I don't have enough experience with the problem details to have formed a strong opinion. Are there well-known clock names that will be used in common code that is shared among different vendors (e.g. primary-clock)? If so, the binding should preregister a list of common names. Will implementors of new hardware have to scratch their heads to decide what to name their clock inputs? The binding should offer some guidance about good name choices and spelling rules, to avoid an eventuall mess as new people come on board and pull names out of the air, with different conventions for capitalization and punctuation and abbreviation. One advantage of indices is that they avoid endless arguments about the exact name (and spelling) of things. In my current project, there are several different hardware manuals for the same that must all be consulted to get the full picture, and they often use different names or inconsistent spellings for the same thing. It makes finding things very challenging. With a name-based interface, it pays to keep in mind that lots of people will ultimately be involved. Many of them will be new so they won't know the conventions well, and few will be careful and precise in their use of language (i.e. names). Provide a lot of guidance about how to choose a set of names. Suppose there were a conventional set of names like clock0, clock1, ..., essentially boiling down to verbosely-spelled indices. I expect that a lot of people would choose to use it just to avoid having to thing of better names and having bike shed arguments with coworkers. So there you have it - my incoherent rambling commentary with no particular conclusion. Cheers, Ben. I'm cooking up a patch that replace our current primitive implementation in arch/powerpc/kernel/clock.c with something along the lines of what I described. However, I want a bit more churn here on the device-tree related bits. So, basically, the goal here is to define a binding so that we can link a device clock inputs to a clock provider clock outputs. In general, in a system, there's actually 3 names involved. The clock provider output name, the clock signal name, and the clock input name on the device. However, I want to avoid involving the clock signal name as it's a global name and it will just end up being a mess if we start exposing that. So basically, it boils down to a device having some clock inputs, referenced by names, that need to be linked to another node which is a clock provider, which has outputs, references either by number or names, see discussion below. First, why names, and not numbers ? IE. It's the OF tradition for resources to just be an array, like interrupts, or address ranges in reg properties, and one has to know what the Nth interrupt correspond too. My answer here is that maybe the tradition but it's crap :-) Names are much better in the long run, besides it makes it easier to represent if not all inputs have been wired. Also, to some extent, things like PCI do encode a name with reg or assigned-addresses properties as part of the config space offset in the top part of the address, and that has proved very useful. Thus I think using names is the way to go, and we should even generalize that and add a new interrupt-names property to name the members of an interrupts :-) So back to
Re: [RFC] Clock binding
Open Firmware often avoids indexed structures. Cases in point include the use of named properties instead of fixed structures and named methods instead of function pointer arrays. Open Firmware's use of arrays for reg properties seems like the right choice for that particular case, but shouldn't be construed to suggest that arrays are good for everything. Well, the reg property is fine for the common cases of devices with one IO (or MMIO) range, no confusion possible, or PCI since it encodes the BAR number. For other cases, especially random embedded stuff that maps several regions of memory, it's a bit harder since we go back to the need of having somebody define which region is which. Indeed. You choose based on the common case and eventually there will be some case that stretches the boundaries. I suppose that, if the problem became severe enough, one could invent a new reg-names property, a list of strings naming the reg entries. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC] Clock binding
One advantage of indices is that they avoid endless arguments about the exact name (and spelling) of things. Right, though in that case, nobody gets to have to decide on the name, it comes from the chip manufacturer pin naming or data sheet. I agree in general. It has long been a convention of mine to follow the vendor's names as exactly as possible. But that often presents difficulties. Many of them have been touched on in our previous discussion but I'll list some here just to emphasize the problem we face: a) Inconsistent naming within a vendor's documentation set - datasheet spells it one way, programmer's manual another, appnotes/porting guide still another, reference schematic spells it two different ways (pin name on part versus net name of signal wire). b) Sometimes the name is abbreviated and sometimes spelled out. SMBALRT vs. SMbus Alert. c) Different tools (CAD programs, word processors) have different conventions leading to existence of ambiguously-representable name components - particular cases in point are overbars for active low signals and embedded spaces/underscores/hyphens in names. d) Compatible part from different vendors leads to confusion about which vendor's names are canonical. Or leading vendor goes out of business or gets bought. These problems are getting worse rapidly as more devices are being sourced from Asia, where the linguistic connection to the Roman alphabet is tenuous. You need a Pope to decide what is canonical. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC] Clock binding
The idea of a wiki as a registration authority is a good one, but I'm not volunteering to maintain it :-) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: ARM clock API to PowerPC
On Wed, 2009-08-12 at 17:57 +1000, Benjamin Herrenschmidt wrote: - Device-tree: The idea on top of my mind would be to define a clock-map property that has the following format: A list of: - zero terminated string clock ID, padded with zeros to a cell boundary Padding a string violates a core principle of property representation, namely the no alignment assumptions one. The reason for that principle was the fact that alignment needs are not stable across processor families, or even within a processor family . - a phandle to the clock provider - a numerical (string ?) ID for that clock within that provider The core would thus be able to do a search in that list based on the clock-id passed in, or if clk_get(dev, NULL), then, use the first one. Thinking a bit more about that one, mixing strings and numbers in a property sucks. What about instead: clock-map is a list of phandle, id clock-names is an optional list of 0 terminated strings This approach finesses the problem nicely. If there's only one clock, and the ID can be ommited, then the clock-names property can be ommited completely too. Else, the entries in clock-names match the entries in clock-map. It's a bit strange to separate the list into two properties but I think it will generally suck less than having them mixed, especially with ASCII representations such as lsprop output. Cheers, Ben ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC] More compatibles or more quirk properties
I'm running into a dilemma choosing between two approaches of defining device tree binding. Let's say if we have several chips with a similar SoC block, but each of them have different quirks. If I define different compatibles for each of the chips, the driver will have a longer match table and thus bloat the device matching process. Or we can use a same compatible for all of them and define properties for each of the quirks. But it somewha Properties to describe quirks precisely are definitely better. In fact, that's fundamental principle - describe the situation, don't infer a bunch of details from a name. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] ndfc driver
n Mon, 08 Dec 2008 21:57:12 -1000
Mitch Bradley [EMAIL PROTECTED] wrote:
One address/size cell isn't enough for the next generation of NAND
FLASH chips.
I am no dts expert, but I thought I could put:
nand {
#address-cells = 1;
#size-cells = 1;
in my dts and you could put:
nand {
#address-cells = 2;
#size-cells = 2;
and, assuming we specified the reg entry right, everything would just
work. Is that assumption wrong?
And if the assumption is true, should I make a note in the doc that you
can make the address and size bigger?
Cheers,
Sean
In principle that is correct, but the device tree partition parser in
the Linux kernel assumes one address cell and one size cell, or at least
it did the last time I looked.
I wrote a patch to fix that and circulated it on the linuxppc list, but
since lost interest. OLPC (my main focus) is probably going to switch to
managed NAND (SSD, LBA-NAND, eMMC, or some such thing with a built-in
Flash Translation Layer) at some point. Raw NAND is starting to go by
the wayside.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] ndfc driver
One address/size cell isn't enough for the next generation of NAND FLASH chips. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: GPIO - marking individual pins (not) available in device tree
Right. I had a similar discussion about this the other day with Anton (I think he forwarded it here but I wasn't subscribed at that point..). The current ideology for device trees is to get rid of device_type for new trees that aren't OF-based. I think it's relevant to give nodes fancy names (i.e. not timer or even ethernet) since the name property is entirely descriptive in nature. I also think it's relevant that device_type still exists because since the name is totally irrelevant except from a user-friendliness point of view, marking a device as a generic type is quite important (device_type = serial, ethernet, rtc, keyboard) where compatible properties are usually wildly over-specific. I don't use device_type much, if at all, anymore. Generic name + compatible just works better than device_type + specific name. When I write code that has to find a node that is suitable for a given purpose, I look for the existence of suitable methods and perhaps other properties. I was just too hard to keep the list of device_type values properly synchronized with all the possible things that you might want to infer from that set of names. device_type is one of those things that seemed like a good idea at the time, but didn't work out as well as I had hoped. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: GPIO - marking individual pins (not) available in device tree
You could have the gpio node define an address space where each
address is a GPIO pin number.
The node would have one address cell and one size cell, and the
decode-unit and encode-unit methods would be the garden-variety
flavors that just convert integers between binary and ASCII. Since this
is not a memory mapped address space, a ranges property wouldn't be
necessary or appropriate.
The node could have an available property with address/size pairs
defining pins that can be freely used. For example, if pins 4 and 7-9
were free, the available property would contain
4 0001 \ 1 pin starting at #4
7 0003 \ 3 pins starting at 7
This is modeled on the /memory node's available property.
Subordinate nodes could represent specific preassigned GPIO functions,
for example
/whatever/gpio/[EMAIL PROTECTED]
As an alternative to the available property, you could instead have
subordinate nodes for the user-assignable GPIOs, e.g.:
/whatever/gpio/[EMAIL PROTECTED]
/whatever/gpio/[EMAIL PROTECTED]
...
That last idea is probably a bit over-the-top, though, especially if
there are a lot of unassigned GPIOs.
You could adopt the convention that preassigned GPIOs must be
represented by subordinate nodes, and any GPIO that is not covered by a
subordinate node's reg property is implicitly available. That's the
way it works for other address spaces.
Mitch Bradley
Hi guys,
I'm a little perplexed as to how I would define a GPIO controller in a
device tree but mark off pins as available or not, so users can geek
around in their own drivers without defining in a device tree exactly
what they intend to use it for (especially if it's something really
weird).
Easiest example - the Efika runs an MPC5200B has 3 GPIO pins on the
board. It's not much, but they're there for use. All the other GPIOs
are absolutely out of bounds, off limits and probably dangerous to
touch, but since each GPIO block has a 32-bit register to handle them,
you can twiddle any bit you like with impunity and cause all the
damage you want. A simple thought comes to mind in that the gpiolib
should not allow a request for one of these bad GPIO pins to succeed.
So, how do we define in a bank of GPIOs, which ones are free for use,
without them being attached to a device and given as a gpios property?
Would we suggest a node;
gpio-header {
compatible = bplan,efika-gpio;
gpios = gpio-standard 16 0 17 0;
};
gpio-header2 {
compatible = bplan,efika-gpio-wkup;
gpios = gpio-wkup 18 0;
};
Which a driver can then look for? I would much rather I did not have
to come up with a special compatible property though, after all,
MPC5200B GPIO are not special and the Efika does not do fancy magic
with them :)
My goal is basically to give an entry in the device tree whereby
(using a forth script) you can pick between IrDA, GPIO, a Sleep Switch
(for Sylvain's patch for Lite5200 and Efika from a year or two ago..),
or whatever else you like. But a generic GPIO geek port is basically
then undefined and left hanging.
By the way I did notice that none of the GPT timer entries in the
lite5200b.dts have GPIO references and the GPT GPIO block is not
defined. Is this because the timers are not exposed on the board for
GPIO or just no need for it? Each timer has a pin it can sample, drive
and do PWM on.. this leads me to wonder how the PWM driver framework
as announced/proposed last week would work here, and if the device
tree should specifically pick which operation works on which timer
(after all if you have a PWM fan controller on a timer pin, you would
want to advertise the fact, but having the full 8 timers as a
gpio-controller and pwm-controller both at the same time, sharing
the same reg property but supporting only a subset of that controller,
needs addressing.
--
Matt Sealey [EMAIL PROTECTED]
Genesi, Manager, Developer Relations
___
devicetree-discuss mailing list
[EMAIL PROTECTED]
https://ozlabs.org/mailman/listinfo/devicetree-discuss
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: GPIO - marking individual pins (not) available in device tree
Mitch Bradley wrote: [snip] You could adopt the convention that preassigned GPIOs must be represented by subordinate nodes, and any GPIO that is not covered by a subordinate node's reg property is implicitly available. That's the way it works for other address spaces. I like that idea except for the implicitly available bit. Just summarizing this in my head (also on the list), if we had an available property in the node marked as a gpio-controller, that would easily give gpiolib something to parse so that it only gives out allocations for pins that are really, really not being multiplexed for something else or just not being connected. There's a GPIO spec in booting-without-of.txt which basically defines a controller and a bank, and you can assign a bank of GPIO to some other device. Assigning specific GPIO pins should be possible.. umm.. http://patchwork.ozlabs.org/patch/5478/ With regards to this patch, how about device usage of pins being defined as a range of pins (reusing the standard-ish ranges property from PCI binding)? Okay, so it looks to me like your bank concept is sort of akin to a gpio-to-gpio bridge, with analogy to a pci-to-pci bridge. Following that model, the name of your gpio-bank would instead be gpio-controller, because its children are GPIO pin nodes that could just as well be attached directly to the top-level gpio-controller node. The compatible property would be different, reflecting the fact that it is a gpio-to-gpio bridge instead of an io-to-gpio bridge (for example). ranges is fully standard. Its specification is tight enough to permit generic address-translation code to walk up a tree and work out how to translate addresses through multiple levels, even in the face of different address representations at the various levels. (But the chained address spaces must be of the same general flavor, such as memory mapped spaces translated through PCI nodes.) Each ranges entry defines a subrange of the child address space and the corresponding subrange of the parent address space. So to use ranges in the context of gpio-to-gpio bridge node, the value would be a list of each entries each containing child-start-pin# parent-start-pin# size. You could choose whether or not to offset the child and parent pin numbers. If you wrote 0 5 2, that would mean that child pins 0 and 1 would actually be parent pins 5 and 6 - the child reg property would have to say, e.g. 0 2. If you wrote 5 5 2, that would mean no offsetting from child to parent; the child reg would be 5 2. Generic ranges handling code wouldn't care. That said, I'm not sure that the intermediate level (banks or g2g bridge, whatever you want to call it) is worth the effort. There is a very good reason for pci-to-pci bridge nodes - they exist in hardware and impose a translation on the configuration addresses. The g2g intermediate nodes might make it slightly easier to move around chunks of GPIO pins, but I'm not sure that it's really that much easier, compared to just changing the values in the reg property of the child. If a child function requires a group of related GPIO pins, you can list all the pins in its reg property, ordered according to their purposes. For example, the first reg entry might be for the SCL pin and the second for the SDA pin. That way you have all the information you could ever need for each device. 1) where the controller sits (gpio-controller property) 2) which pins are available for use (everything not in available is therefore out of bounds) 3) define banks of gpio for a specific function with ranges (for instance pins 10, 11 and 15 would be encoded as 10 2 and 15 1 and these encapsulate some kind of function be it user definable gpio or some control function for a chip) As argued above, I think the grouping should be done directly in the child node, listing the pins in the reg property. 4) assign gpio properties to other nodes which refer to banks (see booting-without-of.txt section IX, at the end) rather than individual pins. I think that's an improvement over the gpios formulation in section IX. I'm concerned that the stipulated gpios format pushes a lot of address-format complexity out into unrelated nodes. 5) optionally a bank may contain gpio pin node which describes EXACTLY what that pin function is (and any lovely properties it may well have). At the moment it's encoded as: gpios = controller-phandle pin-number pin-flags Ad infinitum. Instead of a controller phandle you'd pass in a bank (which is a subset of the controller's available pins) and then you can give each pin it's little options. How about gpios = controller-child-phandle0 controller-child-phandle1 ... The flags, if any, should be properties of the child node. One might argue that the code to process the new gpios will need additional complexity to deal with addressing issues at the target child nodes. I
Re: GPIO - marking individual pins (not) available in device tree
No, no, no, no, no. Making complex multi-level representations of nested things for gpios is just insanity. You know, I don't find this argument particularly compelling. But it certainly is strongly worded. Just use the same encoded format as we already use for gpio descriptors in 'gpios' properties (which is gpio controller specific, with length defined by #gpio-cells). http://en.wikipedia.org/wiki/Proof_by_assertion ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/3]: Sparc OF I2C support.
Hi, I wrote most of 1275. Mitch Bradley ([EMAIL PROTECTED]) David Miller wrote: From: Grant Likely [EMAIL PROTECTED] Date: Thu, 21 Aug 2008 22:18:56 -0600 On Thu, Aug 21, 2008 at 9:53 PM, David Miller [EMAIL PROTECTED] wrote: Have patience with the embedded people that are both new to OpenFirmware and trying to make stuff work at the same time. I think the devicetree-discuss list will help here as new bindings are proposed. I hope you're subscribed. Why not ask the people who actually work on the standards? That's who I go to when I want to know something about openfirmware issues. You mean email them privately? Outside of a public forum? That doesn't help much when it comes to discussing/debating issues and learning from other peoples conversations. You can CC: them on the discussion to get their input, whatever is appropriate. ___ devicetree-discuss mailing list [EMAIL PROTECTED] https://ozlabs.org/mailman/listinfo/devicetree-discuss ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/3]: Sparc OF I2C support.
David Miller wrote: From: Grant Likely [EMAIL PROTECTED] Date: Thu, 21 Aug 2008 22:34:31 -0600 On Thu, Aug 21, 2008 at 10:30 PM, Grant Likely [EMAIL PROTECTED] wrote: On Thu, Aug 21, 2008 at 10:29 PM, Mitch Bradley [EMAIL PROTECTED] wrote: Hi, I wrote most of 1275. Mitch Bradley ([EMAIL PROTECTED]) Hi Mitch, What is your suggestion. Where should we be discussing new device tree bindings? Whether it be real Open Firmware, or flattened device tree, or something in between ...and along those lines: is there a place for documenting new bindings? Lacking anything better, those of us in PowerPC-Linux-land have been adding documentation to Documentation/powerpc/dts-bindings/* in the Linux kernel tree. In a discussion I am having with Greg Onufer, David K. and Tayfun at Sun, Greg said the some of the newer binding documents are being published on the opensolaris site, and he is trying to get some of the older cases (like this I2C one) published there too. This collection of mailing lists is as good a place as any to discuss new bindings. I don't know how many Sun people are on the lists, but we might be able to persuade various Sun people to lurk on one or more of them; I lurk on devicetree-discuss. The opensolaris site seems as good as anywhere for publishing the bindings, especially if they can pull over the old ones from e.g. playground.sun.com . Another possible site might be openbios.org . ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v3] libfdt: Add support for using aliases in fdt_path_offset()
David Gibson wrote:
On Thu, Aug 14, 2008 at 12:43:48PM -0500, Scott Wood wrote:
On Thu, Aug 14, 2008 at 08:28:19AM -0500, Kumar Gala wrote:
- if (*path != '/')
- return -FDT_ERR_BADPATH;
+ /* see if we have an alias */
+ if (*path != '/') {
+ const char *q;
+ int aliasoffset = fdt_path_offset(fdt, /aliases);
+
+ if (aliasoffset 0)
+ return -FDT_ERR_BADPATH;
+
+ q = strchr(path, '/');
+ if (!q)
+ q = end;
+
+ p = fdt_getprop_namelen(fdt, aliasoffset, path, q - p, NULL);
+ if (!p)
+ return -FDT_ERR_BADPATH;
+ offset = fdt_path_offset(fdt, p);
+
+ p = q;
+ }
Can we limit the recursion depth to avoid falling off the stack if an
alias points to itself? Or if aliases pointing to aliases are
disallowed, check for a leading '/' before recursively calling
fdt_path_offset.
Hmm.. my reading of 1275 says that an alias pointing to another alias
is not permitted, but I'm not terribly confident I'm not misreading
it. Segher, do you know whether this is allowed?
The 1275 spec doesn't require multiple levels of aliasing, but my
current implementation allows it and uses it for things like components
of the network stack.
If that's the case then, yes, we should not recurse if the alias value
doesn't start with a /. In fact, if I factor out a fdt_get_alias()
function, it should probably check the alias and return an error if
it's not an absolute path.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/PATCH 2/3] of: add of_lookup_stdout() utility function
Segher Boessenkool wrote: It's not what we do with flattened device trees blobs though. In the flattened tree we're not using a /chosen/stdout property, just the linux,stdout-path one. The question that remains is; should there be? Should the dt blobs use /chosen/stdout also? (I'm not familiar enough with real OF to know the answer. I'm assuming that an instance value is not the same as a phandle). The difference between a phandle and an ihandle is similar to the difference between (the inode of) an executable files on disk and (the process id of) a running process. A phandle refers to the static information that describes a device, while an ihandle refers to a particular (out of potentially several) active instantiation of the OFW driver for that devices. An instance value is a data item that can have a different value for each of the running instances of a given driver. In the analogy, an instance value is like a data segment variable. Given an ihandle, you can get the corresponding phandle with ihandlephandle. You can't go from phandle to ihandle, because that direction is one-to-many. Why you you ever need more than one running instance of a given driver? For leaf devices, it is pretty rare to have multiple instances. Multiple instances are more often used for intermediate nodes. The same intermediate node - for example a usb node - is often the parent of several leaf nodes that are active simultaneously. When you open a device, its device tree parents up to the root are implicitly opened. Each such instance can hold dynamic state on behalf of its children. ihandles and phandles are not the same thing in OF. Since in the flat world we cannot have instances, we should use phandles instead of ihandles for the things in /chosen. I thought we agreed on that already, perhaps I am wrong? Segher ___ devicetree-discuss mailing list [EMAIL PROTECTED] https://ozlabs.org/mailman/listinfo/devicetree-discuss ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] Support NAND partitions 4GiB with Open Firmware
This patch modifes ofpart.c so the total size of NAND FLASH
and the size of an individual partition can exceed 4GiB. It does so
by decoding the reg property based on the values of #address-cells
and #size-cells in the parent node, thus allowing the base address
and size to be 64-bit numbers if necessary. It handles any combination
of #address-cells = 1 or 2 and #size-cells = 1 or 2, handles the case
where the parent node doesn't have #address-cells / #size-cells properties,
and handles the case where the value of #address-cells is incorrectly
inherited from farther up the tree than the direct parent.
This patch does not solve the problem that the MTD subsystem
itself is limited to 2 GiB NAND sizes, but it is a step in that direction.
The final assignment of the 64-bit partition offset and size values is
truncated (by the C type conversion rules) to the actual size of the
struct mtd_partition offset and size fields (which are currently u_int32's).
At some point in the future, when those fields become larger, the code
should just work.
The patch should apply to either 2.6.25 or 2.6.26rc. It has been tested
on the OLPC variant of 2.6.25 , with additional patches to other
OLPC-specific files that aren't necessary for other architectures
that have more mature support for Open Firmware. The OLPC
patch set, plus a set of test cases that verify correct operation for
various #address-cells / #size-cells combinations, can be found at
http://dev.laptop.org/~wmb/ofpart-olpc.tgz
Signed-off-by: Mitch Bradley [EMAIL PROTECTED]
diff --git a/drivers/mtd/ofpart.c b/drivers/mtd/ofpart.c
index f86e069..b83b26c 100644
--- a/drivers/mtd/ofpart.c
+++ b/drivers/mtd/ofpart.c
@@ -7,6 +7,10 @@
* Revised to handle newer style flash binding by:
* Copyright (C) 2007 David Gibson, IBM Corporation.
*
+ * Revised to handle multi-cell addresses and size in reg properties,
+ * paving the way for NAND FLASH devices 4GiB by:
+ * Mitch Bradley [EMAIL PROTECTED]
+ *
* This program is free software; you can redistribute it and/or modify it
* under the terms of the GNU General Public License as published by the
* Free Software Foundation; either version 2 of the License, or (at your
@@ -15,0 +19,0 @@
#include linux/module.h
#include linux/init.h
+#include linux/device.h
#include linux/of.h
#include linux/mtd/mtd.h
#include linux/mtd/partitions.h
+u_int32_t decode_cell(const u_int8_t *prop)
+{
+ return ((prop[0] 24) + (prop[1] 16) + (prop[2] 8) +
prop[3]);
+}
+
int __devinit of_mtd_parse_partitions(struct device *dev,
struct mtd_info *mtd,
struct device_node *node,
@@ -44,5 +54,7 @@ int __devinit of_mtd_parse_partitions(struct device *dev,
pp = NULL;
i = 0;
while ((pp = of_get_next_child(node, pp))) {
- const u32 *reg;
+ u_int64_t xoffset, xsize;
+ const u_int32_t *propval;
+ u_int32_t addrcells = 0, sizecells = 0;
int len;
- reg = of_get_property(pp, reg, len);
- if (!reg || (len != 2 * sizeof(u32))) {
+ /*
+* Determine the layout of a reg entry based on the parent
+* node's properties, if it hasn't been done already.
+*/
+
+ if (addrcells == 0)
+ addrcells = of_n_addr_cells(pp);
+ if (sizecells == 0)
+ sizecells = of_n_size_cells(pp);
+
+ propval = of_get_property(pp, reg, len);
+
+ /*
+* Handle the possibility of a broken device tree that
+* doesn't define #address-cells and #size-cells properly.
+ * In a standard device tree, if the address portion of
+ * reg is one cell, the direct parent should have a
+ * #address-cells property with value 1.
+*/
+ if (propval (len == 2 * sizeof(u32)))
+ addrcells = sizecells = 1;
+
+ /* Error checks */
+
+ if (addrcells 1 || addrcells 2) {
+ of_node_put(pp);
+ dev_err(dev, Invalid #address_cells %d on %s\n,
+ addrcells, node-full_name);
+ kfree(*pparts);
+ *pparts = NULL;
+ return -EINVAL;
+ }
+
+ if (sizecells 1 || sizecells 2) {
+ of_node_put(pp);
+ dev_err(dev, Invalid #size-cells %d on %s\n,
+ sizecells, node-full_name);
+ kfree(*pparts);
+ *pparts = NULL;
+ return -EINVAL;
+ }
+
+ if (!propval || (len != (addrcells+sizecells) *
sizeof(u32))) {
of_node_put(pp);
dev_err(dev
Re: [PATCH] Support NAND partitions 4GiB with Open Firmware
A revised version of the patch, addressing some points that Segher identified, will be issued soon. So if you want to review the patch as submitted, please be aware that some stylistic things have already been fixed (u64 instead of u_int64_t etc, use of of_read_number(), removal of fallback code for broken device trees). The info in Documentation/powerpc/booting-without-of.txt will also be amended. The overall scheme - using #address-cells and #size-cells to permit 64-bit offset and sizes - remains unchanged. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Support NAND partitions 4GiB with Open Firmware
David Gibson wrote:
On Thu, Jun 26, 2008 at 01:50:40PM -1000, Mitch Bradley wrote:
This patch modifes ofpart.c so the total size of NAND FLASH
and the size of an individual partition can exceed 4GiB. It does so
by decoding the reg property based on the values of #address-cells
and #size-cells in the parent node, thus allowing the base address
and size to be 64-bit numbers if necessary. It handles any combination
of #address-cells = 1 or 2 and #size-cells = 1 or 2, handles the case
where the parent node doesn't have #address-cells / #size-cells properties,
and handles the case where the value of #address-cells is incorrectly
inherited from farther up the tree than the direct parent.
This patch does not solve the problem that the MTD subsystem
itself is limited to 2 GiB NAND sizes, but it is a step in that direction.
The final assignment of the 64-bit partition offset and size values is
truncated (by the C type conversion rules) to the actual size of the
struct mtd_partition offset and size fields (which are currently u_int32's).
At some point in the future, when those fields become larger, the code
should just work.
The patch should apply to either 2.6.25 or 2.6.26rc. It has been tested
on the OLPC variant of 2.6.25 , with additional patches to other
OLPC-specific files that aren't necessary for other architectures
that have more mature support for Open Firmware. The OLPC
patch set, plus a set of test cases that verify correct operation for
various #address-cells / #size-cells combinations, can be found at
http://dev.laptop.org/~wmb/ofpart-olpc.tgz
I like the idea - but there are some uglies in the implementation.
Signed-off-by: Mitch Bradley [EMAIL PROTECTED]
diff --git a/drivers/mtd/ofpart.c b/drivers/mtd/ofpart.c
index f86e069..b83b26c 100644
--- a/drivers/mtd/ofpart.c
+++ b/drivers/mtd/ofpart.c
@@ -7,6 +7,10 @@
* Revised to handle newer style flash binding by:
* Copyright (C) 2007 David Gibson, IBM Corporation.
*
+ * Revised to handle multi-cell addresses and size in reg properties,
+ * paving the way for NAND FLASH devices 4GiB by:
+ * Mitch Bradley [EMAIL PROTECTED]
+ *
* This program is free software; you can redistribute it and/or modify it
* under the terms of the GNU General Public License as published by the
* Free Software Foundation; either version 2 of the License, or (at your
@@ -15,0 +19,0 @@
#include linux/module.h
#include linux/init.h
+#include linux/device.h
#include linux/of.h
#include linux/mtd/mtd.h
#include linux/mtd/partitions.h
+u_int32_t decode_cell(const u_int8_t *prop)
+{
+ return ((prop[0] 24) + (prop[1] 16) + (prop[2] 8) +
prop[3]);
+}
You don't appear to actually use this new function.
It's already gone in the new version (the announcement of which may have
been delayed by the mailing list of which I'm not a subscriber).
int __devinit of_mtd_parse_partitions(struct device *dev,
struct mtd_info *mtd,
struct device_node *node,
@@ -44,5 +54,7 @@ int __devinit of_mtd_parse_partitions(struct device *dev,
pp = NULL;
i = 0;
while ((pp = of_get_next_child(node, pp))) {
- const u32 *reg;
+ u_int64_t xoffset, xsize;
The names u64 and u32 are preferred for kernel internal things.
Certainly not u_int64_t which isn't even the C99 standard name.
Already fixed.
+ const u_int32_t *propval;
+ u_int32_t addrcells = 0, sizecells = 0;
int len;
- reg = of_get_property(pp, reg, len);
- if (!reg || (len != 2 * sizeof(u32))) {
+ /*
+* Determine the layout of a reg entry based on the parent
+* node's properties, if it hasn't been done already.
+*/
+
+ if (addrcells == 0)
Redundant 'if'; you've just initialized this variable to zero.
The intention is that the body of the if should only be executed
once during the loop, since the parent node is the same for all children.
+ addrcells = of_n_addr_cells(pp);
+ if (sizecells == 0)
+ sizecells = of_n_size_cells(pp);
+
+ propval = of_get_property(pp, reg, len);
+
+ /*
+* Handle the possibility of a broken device tree that
+* doesn't define #address-cells and #size-cells properly.
+ * In a standard device tree, if the address portion of
+ * reg is one cell, the direct parent should have a
+ * #address-cells property with value 1.
+*/
+ if (propval (len == 2 * sizeof(u32)))
+ addrcells = sizecells = 1;
+
+ /* Error checks */
+
+ if (addrcells 1 || addrcells 2) {
+ of_node_put(pp);
+ dev_err(dev
Re: [PATCH] Support NAND partitions 4GiB with Open Firmware
David Gibson wrote:
On Thu, Jun 26, 2008 at 05:28:42PM -1000, Mitch Bradley wrote:
David Gibson wrote:
On Thu, Jun 26, 2008 at 01:50:40PM -1000, Mitch Bradley wrote:
[snip]
+ const u_int32_t *propval;
+ u_int32_t addrcells = 0, sizecells = 0;
int len;
- reg = of_get_property(pp, reg, len);
- if (!reg || (len != 2 * sizeof(u32))) {
+ /*
+* Determine the layout of a reg entry based on the parent
+* node's properties, if it hasn't been done already.
+*/
+
+ if (addrcells == 0)
Redundant 'if'; you've just initialized this variable to zero.
The intention is that the body of the if should only be executed
once during the loop, since the parent node is the same for all
children.
But the initialization is within the loop body as well, so this won't
do it. Just factor the code getting addr and size cells right out of
the loop, instead.
Hmmm. Perhaps it's better to move the declaration of the variables out of
the loop instead.
Moving the of_n_*_cells() calls outside the loop requires redundant calls
to of_get_child() and of_node_put(), because of_n_*_cells() implicitly
reach up to the parent node. That is almost certainly more expensive
than the if.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
