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. > 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. 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. Tomi
Attachment:
signature.asc
Description: OpenPGP digital signature
