Re: DRM encoder/bridge architecture questions

[Laurent Pinchart <laurent.pinchart@ideasonboard.com>]

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