Re: [PATCH] drm/i2c: Add driver for PTN3460 LVDS/DP bridge

On Thu, Jan 24, 2013 at 4:22 PM, Daniel Vetter [off-list ref] wrote:

On Thu, Jan 24, 2013 at 7:09 PM, Sean Paul [off-list ref] wrote:

quoted

This patch adds the driver for the PTN3460 LVDS/DP bridge chip.

The driver allows the EDID emulation to be selected from device tree,
along with specifying the GPIOs driving powerdown and reset pins.

The chip has a bug in it such that when the powerdown and reset pins
are toggled, the hotplug line blips before the bridge is completely
ready. This forces us to wait for the maximum specified setup time
(90ms) before interacting with the chip via i2c or doing DP training, as
opposed to watching the hotplug line. This limitation means that we need
to synchronize the bridge driver with the DP driver via the
ptn3460_wait_until_ready function.

Signed-off-by: Sean Paul <redacted>
---
 .../devicetree/bindings/drm/i2c/ptn3460.txt        |   27 ++
 drivers/gpu/drm/Kconfig                            |    2 +
 drivers/gpu/drm/i2c/Kconfig                        |    6 +
 drivers/gpu/drm/i2c/Makefile                       |    2 +
 drivers/gpu/drm/i2c/ptn3460.c                      |  283 ++++++++++++++++++++

Afaict from reading through the code, this is just a bit of
special-purpose i2c code to control some hw. Imo you can just put that
into your driver directory, since currently all the drivers in drm/i2c
are drm_encoder_slaves (potentially shared between drivers), and I
think we should keep it at that.

Of course, if you plane to extend that to such an encoder slave
driver, then we could move it back.

Yep, right on, it's not using any drm specific bits at the moment. I
have it in drm since I was using from the exynos DP driver in the
chromium tree (which has been moved into drm to alleviate the power
on/suspend/resume ordering issues that exist). I'm happy to move it
out, but want to avoid needlessly having to move it back in at some
point (depending on where the DP driver ends up).

Apart from that, I think there's a chance that it can be expanded to a
drm_encoder_slave if things get more complex, or potentially
daisy-chained as a CDF display, but that remains to be seen.

Suggestions welcome!

Sean

-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch