[PATCH v4 34/51] drm/omap: venc: Register a drm_bridge

[Laurent Pinchart]

Hi Tomi,

On Thu, Dec 19, 2019 at 01:41:47PM +0200, Tomi Valkeinen wrote:
> On 19/12/2019 12:45, Laurent Pinchart wrote:
> > In order to integrate with a chain of drm_bridge, the internal VENC
> > encoder has to expose the mode valid, fixup and set, the enable and
> > disable and the get modes operations through the drm_bridge API.
> > Register a bridge at initialisation time to do so.
> > 
> > Most of those operations are removed from the omap_dss_device as they
> > are now called through the drm_bridge API by the DRM atomic helpers. The
> > only exception is the .get_modes() operation that is still invoked
> > through the omap_dss_device-based pipeline.
> > 
> > For the time being make the next bridge in the chain optional as the
> > VENC output is still based on omap_dss_device. The create_connector
> > argument to the bridge attach function is also ignored for the same
> > reason. This will be changed later when removing the related
> > omapdrm-specific display drivers.
> > 
> > Signed-off-by: Laurent Pinchart <laurent.pinchart at ideasonboard.com>
> > Reviewed-by: Tomi Valkeinen <tomi.valkeinen at ti.com>
> > ---
> 
> Something with venc is different than without your series.
> 
> I have beagleboard xm, with both DVI and s-video connected. With and without your series, kmsprint shows:
> 
> Connector 0 (45) DVI-D-1 (connected)
>   Encoder 0 (44) TMDS
>     Crtc 0 (47) 1920x1200 154.000 1920/48/32/80 1200/3/6/26 60 (59.95)
>       Plane 0 (32) fb-id: 51 (crtcs: 0 1) 0,0 1920x1200 -> 0,0 1920x1200 (RX12 AR12 RG16 XR24 RG24 AR24 RA24 RX24)
>         FB 51 1920x1200
> Connector 1 (48) S-Video-1 (unknown)
>   Encoder 1 (46) TMDS
> 
> Without your series:
> 
> # ./kmstest -c s-video
> Connector 1/@48: S-Video-1
>   Crtc 1/@49: 720x574i at 50.00 13.500 720/12/64/68/- 574/5/5/41/- 50 (50.00) 0x1a 0x48
>   Plane 0/@32: 0,0-720x574
>     Fb 53 720x574-XR24
> press enter to exit
> 
> and I have a picture on the display.
> 
> With your series:
> 
> # ./kmstest -c s-video
> terminate called after throwing an instance of 'std::invalid_argument'
>   what():  no modes available

:-S Do you plan to bisect this, or should I give it a go ?

> To be honest, I'm not quite sure how an unknown-connection output
> should work (maybe kmstest doesn't handle it right), but the behavior
> is different.

-- 
Regards,

Laurent Pinchart