[PATCH RFC 00/11] drm/tilcdc: Atomic modeset support

Daniel Vetter daniel at ffwll.ch
Tue May 10 16:08:07 UTC 2016


On Tue, May 10, 2016 at 5:11 PM, Laurent Pinchart
<laurent.pinchart at ideasonboard.com> wrote:
>> >> Hmmm, too bad it wants to own its encoder. LCDC on Beaglebone-Black
>> >> needs the componentized external tda998x driver. So at least in its
>> >> current form the drm_simple_display_pipe wont work for tilcdc.
>> >>
>> >> It may not be too big a job to add an external encoder support, but
>> >> would it complicate currently so nice and simple driver structure too
>> >> much?
>> >
>> > How about we add an argument for encoder and if it is NULL, then the no-op
>> > encoder is used:
>>
>> Hm, my idea with external transcoders was to pull them in as a
>> drm_bridge. That's of course more work, and we already have a
>> proliferation of different transcoder driver standards in drm
>> unfortunately (there's drm_bridge, but als to drm_encoder_slave).
>
> drm_encoder_slave has to go. As a first step the adv7511 driver is being
> converted to a drm_bridge by Archit. Any volunteer for the three other drivers
> ? We also need to clearly state that new drivers must use drm_bridge.

Hm, just realized that tda998x _is_ an encoder slave driver. But since
it's not automatically wire up like drm_bridge we can't keep the dummy
encoder of drm_simple_display_pipe. Would be good indeed to have a
minimal drm_bridge conversion of tda998x so that we don't need to add
hacks to the simple pipe helpers.

A small function to set the first drm_bridge for a
drm_simple_display_pipe should be all that's really needed here. A bit
more work, but hopefully not much. And really should be worth it to
use the simple helpers for tilcdc, it matches the use-case perfectly I
think.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch


More information about the dri-devel mailing list