Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1700041 > unrolled thread

Re: [BISECTED, REGRESSION] v4.12-rc: omapdrm fails to probe on Nokia N900

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [BISECTED, REGRESSION] v4.12-rc: omapdrm fails to probe on Nokia  N900 Tomi Valkeinen <tomi.valkeinen@ti.com> - 2017-07-31 15:30 +0200
    Re: [BISECTED, REGRESSION] v4.12-rc: omapdrm fails to probe on Nokia  N900 Daniel Vetter <daniel@ffwll.ch> - 2017-08-02 12:20 +0200
      Re: [BISECTED, REGRESSION] v4.12-rc: omapdrm fails to probe on Nokia N900 Daniel Vetter <daniel@ffwll.ch> - 2017-08-02 14:10 +0200
      Re: [BISECTED, REGRESSION] v4.12-rc: omapdrm fails to probe on Nokia  N900 Tomi Valkeinen <tomi.valkeinen@ti.com> - 2017-08-02 14:10 +0200

#1700041 — Re: [BISECTED, REGRESSION] v4.12-rc: omapdrm fails to probe on Nokia N900

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [next] | [standalone]

#1701982

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.

> 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.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[toc] | [prev] | [next] | [standalone]

#1702056 — Re: [BISECTED, REGRESSION] v4.12-rc: omapdrm fails to probe on Nokia N900

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
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[toc] | [prev] | [next] | [standalone]

#1702058

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web