On Thu, Oct 24, 2013 at 8:14 AM, David Woodhouse <dwmw2@xxxxxxxxxxxxx> wrote: > >> >> On Thu, 2013-10-24 at 12:22 +0000, David Woodhouse wrote: >> >>> If you are correct to insist that DMA needs yo be supported in the new >>> driver *even* with old firmware, then yes, maybe. >> >> if DMA gives a performance boost for all workloads, what is the argument >> for not always enabling it ? > > If DMA gives a performance boost for all workloads, what bloody idiot > defined or reviewed a DT binding that didn't include the information which > is required to uae DMA? :) Two cases; 1) Where nobody documented that DMA was possible - if it is via an external DMA controller with a configurable event number, then it is not part of the binding for that IP block anyway except to optionally specify what the dma controller in use is (phandle) and the event number (irq, dma-channels, whatever) 2 a) Where there was not any driver for DMA so nobody even knew it worked, but could only trust the documentation. 2 b) Where there are errata in older hardware which stopped it working and consensus was that it shouldn't be defined until it works, and then new hardware made it work Either way, your fix is the correct one. If an interrupt or dma channel for a device is totally fixed per SoC and that device is ONLY used on that SoC, you can add a fixup in the driver to deal with older bindings. This may be seen as a "huge leap backwards" but it is the only way to do it and that is a fact of life. This is the way the original Efika PPC was designed; Genesi/bplan did not put a lot of properties (including interrupt numbers and DMA functionality) in the tree because they were already used in pre-OF drivers and the mappings were ostensibly fixed and in the manual. As long as those drivers knew the values already, why describe them again and have to write hundreds of lines of code to override a static value with a dynamic DT-derived one? Once it hits another SoC (i.e. number of users of the driver is >1) then the property has to be required for the SECOND SoC unless it's exactly the same mapping. Then you can mandate the property defining the new values on newer hardware (with a particular compatible property that differentiates it) for the purposes of future proofing the driver, but on older hardware it can know what the real value is. In the case where it's EXACTLY the same, the property stays optional because drivers would always, as per older binding, know how to deal with it. Then came this edict that *absolutely everything* needed to be defined in DT, even though there were no other platforms (and still aren't) using those peripherals, and stuff like this got written: http://www.powerdeveloper.org/platforms/efika/devicetree Which I am quite proud of writing. And executing this script before loading the OS meant Linux kept working - at least during 2008 - and it is up to the user or distro to put that script in place when the OS requires it. What is infuriating is the reluctance for the distributions to mandate being able to script device tree changes when they also want to mandate scriptable boot.. it seems like a lot of "we don't want to, shove it on the vendors' back instead." All that is going to do is piss off board designers and their software engineering teams.. >> I don't understand why having the soc-foo.h with the internal interrupt >> mapping in the kernel tree is a no-no, whereas it's ok to add the >> missing part of it in the form of fixups or directly in driver code. > > It's the difference between doing it as a matter of course, and doing it > only in the very rare "OMG we fucked up but we really *need* to fix it up > this time" case. Right. It doesn't need to be in a header or source just because it exists - it needs to be there as, and ONLY as, it is used. Most values are taken from the manuals anyway, so if they exist, they exist in the manual even if they are unused in the OS. If it really was as strict a process as some people would like it, the i.MX NFC NAND driver and a couple others, none of the i.MX pinctrl bindings currently existing or the very concept of defining clock providers (&clocknode XY where XY is an arbitrary enum inside the OS) would NEVER have hit. I absolutely loathe all 3 of these since they make it very very difficult for everyone involved in bringing up OS support on a new board, hardcoded values here and there but DT properties elsewhere..constant cross-referencing of bindings and headers and source code and Linux abstractions vs. manuals and host controller specs. Some of that is a fact of life.. a lot of it is definitely imposed by stupid design. -- Matt Sealey <neko@xxxxxxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
