DRM encoder/bridge architecture questions

DRM encoder/bridge architecture questions

[Sean Cross]

Hi,

We've got an IT6251 LVDS -> eDP bridge chip we're hanging off of a
dual-lane LVDS port on an i.MX6.  We have a driver we're using
internally that's little more than a series of register pokes to boot
the chip, but I'd like to clean it up for submission.

What kind of device is this?  It's externally connected to the main SoC
via LVDS and I2C.  It's conceptually hanging off of the ldb "LVDS
Display Bridge" encoder, which means it's an encoder attached to an
encoder.  Is that allowed in the DRM model?

With the current driver, I have it just sitting in drivers/gpu/drm/i2c/,
and it's not "attached" to anything.  The encoder chip automatically
figures out display timings and the like.  Where should the file
actually go?

Finally, how would the driver get attached to the system?  I see there's
an Exynos bridge device that appears to go the other way, but it's
explicitly loaded by the Exynos display adapter.  Since most devices
will have an LVDS panel attached directly to the LDB port, it seems
silly to have it explicitly look for an additional bridge device to plug
in as this is a special case.  Is there any way I could pass the it6251
a handle to the ldb in device tree and have it hang itselff of the end
that way?


Sean

Re: DRM encoder/bridge architecture questions

[Laurent Pinchart]

Hi Sean,

On Monday 18 August 2014 16:29:24 Sean Cross wrote:
> Hi,
> 
> We've got an IT6251 LVDS -> eDP bridge chip we're hanging off of a
> dual-lane LVDS port on an i.MX6.  We have a driver we're using
> internally that's little more than a series of register pokes to boot
> the chip, but I'd like to clean it up for submission.
> 
> What kind of device is this?  It's externally connected to the main SoC
> via LVDS and I2C.

The kernel organizes its device hierarchy based on control buses, so this 
should be an I2C device.

> It's conceptually hanging off of the ldb "LVDS Display Bridge" encoder,
> which means it's an encoder attached to an encoder.  Is that allowed in the
> DRM model?

That's not allowed by the device model DRM exposes to userspace, but it's 
allowed internally in the kernel using the drm_bridge framework that has been 
designed to support chained encoders.

I'm not happy with the current implementation though. 	Ajay Kumar has posted a 
patch series named "[PATCH V6 0/8] drm/exynos: few patches to enhance bridge 
chip support" that pushes the DRM bridge framework in the right direction, but 
we're not there yet. I'll reply to the patches now and will CC you.

> With the current driver, I have it just sitting in drivers/gpu/drm/i2c/,
> and it's not "attached" to anything.  The encoder chip automatically
> figures out display timings and the like.  Where should the file
> actually go?

If you implement it as a bridge, probably in drivers/gpu/drm/bridge, but if 
you implement it as a slave encoder (which is another DRM framework to support 
I2C encoders) then it's in the right place. The two frameworks should 
eventually be merged.

> Finally, how would the driver get attached to the system?  I see there's an
> Exynos bridge device that appears to go the other way, but it's explicitly
> loaded by the Exynos display adapter. Since most devices will have an LVDS
> panel attached directly to the LDB port, it seems silly to have it
> explicitly look for an additional bridge device to plug in as this is a
> special case. Is there any way I could pass the it6251 a handle to the ldb
> in device tree and have it hang itselff of the end that way?

That's how it should work, connections between components should be modeled in 
DT using phandles (see Documentation/devicetree/bindings/graph.txt and 
Documentation/devicetree/bindings/video/ti,omap-dss.txt for instance). Your 
DRM driver should use the component framework (include/linux/component.h) to 
get references to all external components it needs. There are several 
implementations in progress, but none yet that (in my opinion) is clean and 
standard enough to serve as a good example.

-- 
Regards,

Laurent Pinchart