On 08/02/2019 17:20, Laurent Pinchart wrote:
> Hi Tomi,
>
> On Fri, Jan 18, 2019 at 12:33:03PM +0200, Tomi Valkeinen wrote:
>> On 11/01/19 05:51, Laurent Pinchart wrote:
>>> Hook up drm_bridge support in the omapdrm driver. Despite the recent
>>> extensive preparation work, this is a rather intrus
Hi,
On Fri, Jan 11, 2019 at 05:51:16AM +0200, Laurent Pinchart wrote:
> Hook up drm_bridge support in the omapdrm driver. Despite the recent
> extensive preparation work, this is a rather intrusive change, as the
> management of outputs needs to be adapted through the driver to handle
> both omap_
Hi,
On Fri, Jan 11, 2019 at 05:51:16AM +0200, Laurent Pinchart wrote:
> Hook up drm_bridge support in the omapdrm driver. Despite the recent
> extensive preparation work, this is a rather intrusive change, as the
> management of outputs needs to be adapted through the driver to handle
> both omap_
Hi Tomi,
On Fri, Jan 18, 2019 at 12:33:03PM +0200, Tomi Valkeinen wrote:
> On 11/01/19 05:51, Laurent Pinchart wrote:
> > Hook up drm_bridge support in the omapdrm driver. Despite the recent
> > extensive preparation work, this is a rather intrusive change, as the
> > management of outputs needs t
Hi Laurent,
On 11/01/19 05:51, Laurent Pinchart wrote:
> Hook up drm_bridge support in the omapdrm driver. Despite the recent
> extensive preparation work, this is a rather intrusive change, as the
> management of outputs needs to be adapted through the driver to handle
> both omap_dss_device and
Hook up drm_bridge support in the omapdrm driver. Despite the recent
extensive preparation work, this is a rather intrusive change, as the
management of outputs needs to be adapted through the driver to handle
both omap_dss_device and drm_bridge.
Connector creation is skipped when using a drm_brid