On Wed, Aug 2, 2017 at 1:54 PM, Tomi Valkeinen tomi.valkeinen@ti.com wrote:
On 02/08/17 13:12, Daniel Vetter wrote:
On Mon, Jul 31, 2017 at 04:21:51PM +0300, Tomi Valkeinen wrote:
On 30/06/17 15:36, Daniel Vetter wrote:
I don't think registering before everything is loaded make sense. On the big desktop driver chips we have all the bridge/encoder/panel drivers built into the driver. arm-soc loves to make everything a separate module, but in the end if you decided to not compile half of the driver you need, then it's not going to work.
I don't think that's quite the same. On the desktop you just have the video card, and it's easy to enable that single component. On an embedded device you have the SoC's display controller and then possibly multiple external encoders/panels on the board. Those external components have to be separate modules, they can't be part of the SoC driver. The desktop video card matches only to the SoC's display controller.
Please take a look at the encoder drivers both nouveau and i915 have had (for older hw). In neither of these cases did we register an incomplete driver.
Imo the only thing we should support to be hotplugged in drm is stuff you can physically hotplug (like atm connectors). Everything else just complicates the code for no good reason at all.
"unplugging" components would not give much, I think, but allowing adding new displays at runtime would be a very good thing.
We do, just register another drm_device.
But a drm_device is the display controller ("graphics card") side of the whole, isn't it? Well, that's not exactly true, it also contains the output side, like panel, but it's the display controller that defines how many drm_devices we have.
This was a reply to "Adding new displays at runtime". We support that, by either hotplugging drm_device or drm_connector. Not anything else. And there's not a real-world use-case as in "you can physically hotplug it" to support more, at least for now. There's a design problem in armsoc (you're not the only one who want to make this work), but I really don't understand why it's a use-case we care about.
It's not only about mistakenly having the driver disabled in the kernel config, it could also be that some base driver failed to probe, which then makes an encoder or a panel to defer probing as it can't get the base resource. But HDMI or some other panel would work fine, but with current architecture can't be used.
And if you really want to optimize, one a phone-type device you could have the LCD driver built-in, but HDMI drivers as modules, and only load the HDMI drivers if the user actually needs the HDMI.
I don't see why we should support this as a valid use-case. E.g. if i915 fails to load a component (just because it's all in the same .ko doesn't mean it's not multiple bits, same way you can have multiple drivers in the same .ko), we also fail the overall driver bind. Really not seeing any difference with arm-soc vs. desktop here.
I admit I'm not that familiar with the desktop side, but I don't follow.
From the user's perspective, why would his board's HDMI not work, if the embedded panel fails, or the kernel doesn't have the driver for the panel? As a user, at least I would very much like the HDMI to work even if the other display doesn't.
If there's a clear error on the panel side, the DRM driver can handle that and just leave the panel away. I think the real problems are the deferred probing and loading as modules, as we don't know when, if ever, the panel is ok.
At least for me there's a clear distinction between, say, i915 and, say, boards with OMAP DSS hardware:
i915 is one whole component, and if parts of it don't load, it makes sense that i915 as a whole doesn't load. And the i915 driver knows and understand about everything that i915 contains. And i915 can be a single .ko, splitting it into smaller .kos probably doesn't give much benefit.
On an OMAP board, we have DSS in the SoC, which contains a bunch of subcomponents. Everything I said above about i915 goes also for DSS driver. Then we have external encoders and panels. Those have to be separate drivers and modules, as there can be any number of those, used in any combination, on any platform.
If I'm configuring the kernel for my OMAP board which has HDMI output and a panel, and I want to use the HDMI output, it makes sense that I enable DSS and whatever is needed on the HDMI path. It doesn't really make sense that I also need to enable panel-foobar.
It's almost as if my board has a GPIO chip, and I would need to enable and successfully load all the drivers for the devices using the GPIO chip until any of the devices would work.
Now, I don't think this is a big issue, and I don't think normal users would often encounter it, but it does feel confusing when you hit the problem when debugging or doing new kernel configs.
i915 has a hard depency on a bunch of other .ko too. We fail driver load if they're not there, for whatever reason (and they are all about as optional as your panel driver). I see this like any unsupported platform, if you really want to use the HDMI port without the panel, then edit your DT to not have that panel enabled. Or type a dummy panel driver which doesn't register a connector. Drivers don't magically support boards they've never been enabled on.
In my experience the only people who care about this use-case are driver hackers, and they know how to make it work and add the necessary board support. -Daniel