On Mon, Oct 21, 2013 at 09:48:54AM +0100, Russell King - ARM Linux wrote: > On Mon, Oct 21, 2013 at 10:32:42AM +0200, Sascha Hauer wrote: > > On Mon, Oct 21, 2013 at 12:11:34AM +0100, Russell King - ARM Linux wrote: > > > On Sun, Oct 20, 2013 at 10:26:54PM +0100, Stephen Warren wrote: > > > > The only thing we've really moved out of the kernel is the exact IDs of > > > > which GPIOS, interrupts, I2C/SPI ports the devices are connected to; the > > > > simple stuff not the hard stuff. The code hasn't really been simplified > > > > by DT - if anything, it's more complicated since we now have to parse > > > > those values from DT rather than putting them into simple data-structures. > > > > > > Here's my random thoughts this evening on DT, orientated mostly on a > > > problem area I've been paying attention to recently. > > > > > > In some ways, DT has made things much harder. I don't know whether > > > you've taken a look at DRM and the various drivers we have under there, > > > it's quite a mess of unreliable code which is trying to bend the DRM > > > card based model to a DT based multi-device component based description > > > with lots of sub-drivers. > > > > > > What DRM currently expects is a certain initialisation order: the main > > > drm_device structure is created by the DRM code, and then supplied to > > > the DRM driver to populate all the different parts of the "DRM card". > > > > > > Once all parts of the card have been setup (the CRTCs, encoders, > > > connectors, etc) then some helpers can be initialised. Once the > > > helpers have been initialised, the "dimensions" of the "DRM card" > > > become rather fixed until the helper is torn down. > > > > > > The problem is this: if you have a multi-driver based card, there is > > > no way to prevent any of those sub-drivers from being unbound from > > > their drivers at any time. module refcounts don't save you from this. > > > Meanwhile, (at the moment) you can't half-tear down a "DRM card" and > > > have it still in a usable state. The internals just don't allow for > > > it at present. > > > > > > Yes, work can be put in to solve this problem, but it's being solved > > > because of a desire to bend the subsystem to the DT way of doing things. > > > That may or may not be the best idea. However, what I do know is that > > > there is now great pressure to "bend stuff so that it works with DT > > > at all costs". Evidence is the Exynos driver and the imx-drm driver. > > > > In fact it was the other way round. We modeled the IPU devicetree > > binding after the hardware and bended the driver around it. The DRM > > single-card model is the limiting fator here, not the devicetree. > > There are several points which I think you failed to understand: > > 1. DRM vs device tree is an incompatibility. > 2. Trying to bend DRM to DT with independent driver solutions such as > the abomination that is imx-drm creates its own set of problems. > > If a subsystem doesn't work well with DT, then the choices are either: > > (a) don't use DT with the subsystem > (b) fix the subsystem > > The choices do not include: > > (c) creating an abomination that is fragile, and is trivially easy to > oops the kernel. > > This comes back to the root problem I'm trying to highlight: we are not > trying to strive for DT forsaking everything else. If moving to DT > means we give up with proper code design, then we've quite literally > lost the plot. I'm honestly not sure if we have much of a choice right now. I've only recently hit the stable ABI wall, which effectively keeps me from adding new functionality. Even worse, the matter isn't that some patches would need more work or anything, but the problem is that we can't merge code until everybody and their cat has acked the patches, or more precisely, the DT bindings. Typically this is a subsystem maintainer, the port maintainer and now with DT also the device tree binding maintainers. That's an awful lot of people you have to convince. In this particular case these patches were even required to be acked by yet another group of people. Now, I can't blame anyone in particular and I certainly made my own set of mistakes in the process, but the issue is systemic. If you need to run a set of patches by three or four groups of people, each with their own set of interests, it becomes very difficult to find any sort of concensus. And not only that: it also means that every group needs to find the time to at least look at the patches and to some degree understand it. So instead of requiring concensus on the binding from everyone involved, I went to investigate alternative means to get the code out and provide new features to our users with the goal to migrate to a proper device tree binding incrementally. The problem is that we can't expose all the device nodes in DT because their bindings haven't been acknowledged, but without a device node there won't be a device for the driver to bind against. So the obvious solution seemed to be to just create the device programmatically. Naively I thought: "Well, this won't be pretty, but it should be easy." Far from it. It turns out to be very difficult to do. With all the cross-referencing that DT allows to do so easily, the same is very cumbersome to do with code. Not only do you need to look up device nodes by path, but you also need to do things like fixing up phandles because the DT doesn't contain them for all nodes, yet the kernel needs them to look up the corresponding devices. Once you've actually created a device node, you still need to inject it into what the device tree core created from the DTB at boot time. Turns out that there's actually some code to do that, but it requires the OF_DYNAMIC option to be selected. Turning that on triggers a couple of warnings because code doesn't take and drop references on device nodes properly. To round things off there's the problem on how to preserve compatibility with future device trees where the nodes already exist because we've finally agreed on a binding... So unfortunately there is no easy way to mix DT with non-DT. So we can decide to just merge code that's not supported on DT platforms, but what good is that if the platform we want to run that code on supports only DT? Thierry
Attachment:
pgpatSekh1RZv.pgp
Description: PGP signature
