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.
>> 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.
Tomi
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
