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.