On Thu, 21 Aug 2014 17:04:34 +0200
Andrzej Hajda [off-list ref] wrote:

On 08/21/2014 03:21 PM, Thierry Reding wrote:

quoted

On Thu, Aug 21, 2014 at 12:32:43PM +0200, Andrzej Hajda wrote:

quoted

On 08/21/2014 11:52 AM, Thierry Reding wrote:

quoted

On Thu, Aug 21, 2014 at 11:41:59AM +0200, Boris BREZILLON wrote:

quoted

On Thu, 21 Aug 2014 11:04:07 +0200
Thierry Reding [off-list ref] wrote:

quoted

On Thu, Aug 21, 2014 at 10:37:06AM +0200, Boris BREZILLON wrote:

quoted

Hi Ludovic,

On Thu, 21 Aug 2014 10:16:19 +0200
Ludovic Desroches [off-list ref] wrote:

quoted

Hi Boris,

You can add

Tested-by: Ludovic Desroches <redacted>

Thanks for testing this driver.

quoted

Only one issue but not related to your patches, you can't display
quickly the bootup logo since the panel detection takes too much
time.

Yes, actually this is related to the device probe order: the
hlcdc-display-controller device is probed before the simple-panel, thus
nothing is detected on the RGB connector (I use of_drm_find_panel to
check for panel availability) when the display controller is
instantiated. I rely on the default polling infrastructure provided by
the DRM/KMS framework which polls for a new connector every 10s, and
this is far more than you kernel boot time.

Do anyone see a solution to reduce this delay (without changing the
polling interval). I thought we could add a notifier infrastructure to
the DRM panel framework, but I'm not sure this is how you want things
done...

Other drivers return -EPROBE_DEFER when a panel hasn't been registered
yet. This will automatically take care of ordering things in a way that
DRM/KMS will only be initialized after the panel has been probed.

Actually I'd like to avoid doing this with a deferred probe, because,
AFAIU, the remote endpoint is not tightly linked with the display
controller driver (I mean the display controller can still be
initialized without having a display connected on it).
Moreover the atmel dev kit I'm using has an HDMI bridge connected on
the same RGB connector and I'd like to use it in a near future.
Returning -EPROBE_DEFER in case of several devices connected on the
same connector implies that I'll have to wait for all the remote
end-points to be available before my display controller could be
instantiated.

While this could be acceptable when all drivers are statically linked
in the kernel, it might be problematic when you're using modules,
meaning that you won't be able to display anything on your LCD panel
until your HDMI bridge module has been loaded.

No. HDMI should be using proper hotplugging anyway, hence it should be
always be loaded anyway. You're in for a world of pain if you think you
can run DRM with a driver that's composed of separate kernel modules.

Also if you don't want to use deferred probe, then you're in for the
full hotplugging panel dance and that implies that you need to fix a
bunch of things in DRM (one being the framebuffer console instantiation
that I referred to in the other thread). You also can't be using the
current device tree bindings because they all assume a dependency from
the display controller/output to the panel. For hotplugging you'd need
the dependency the other way around (the panel needs to refer to the
output by phandle).

I have tested panel as a module in exynos-dsi + panel-s6e8aa0
configuration, everything works. There is a workaround for fb console
not being reconfigurable, but it does not make thing worse than before.
And I do not see a problem with phandles, ie in DT they point both ways,
according to binding advices at the time, but in the code it is display
controller/encoder which is looking for the panel.

That works because it's DSI. And we have attach/detach callbacks for
DSI. We don't have those for regular panels, so we'd need to find a way
to add that.

Maybe I have misread your answer, but you showed it as very
difficult/painful
process: "hotplugging panel dance", "fix a bunch of things in DRM". In fact
we are missing here only good notifications about panel appearance.

quoted

The way that this currently works is that an encoder/connector driver
looks up the panel and attaches it to itself. If you allow panels to be
hotpluggable, then they have no knowledge about what they are connected
to, so there needs to be a way to inject that knowledge so that they can
attach to a connector.

I do not understand that. Currently it is the connector who looks for
the panel
and attaches it.
So the scenario, after adding panel tracking, could be:
 - encoder parses its phandle to panel, and start tracking appearance of
the panel
identified by this phandle,
 - when panel appears encoder callback is called, and encoder attaches
the panel,
 - when panel wants to disappear encoder callback is called, encoder
detaches the panel.

All this I have already presented together with generic interface
tracker [1].

Well, your attempt at doing a generic tracker framework sounds
interesting, but given the answer you've got from greg-kh and Russel,
I'd say this patch series is in a dead-end (unless there are other
versions I haven't seen yet).

How about implementing a specific notifier interface for the drm_panel
framework first, and move to your generic implementation if it gets
accepted.

These are the two proposal I sent to Thierry:

http://code.bulix.org/scq4g3-86804 (v1)

and

http://code.bulix.org/7urh8v-86806 (v2)

Feel free to propose any alternative to those implementations.

Best Regards,

Boris


-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com