On Wed, Aug 2, 2017 at 1:54 PM, Tomi Valkeinen <tomi.valkeinen@xxxxxx> 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
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
