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

[Sean Paul]

On Thu, Jan 24, 2013 at 4:22 PM, Daniel Vetter <daniel at ffwll.ch> wrote:
> On Thu, Jan 24, 2013 at 7:09 PM, Sean Paul <seanpaul at chromium.org> wrote:
>> 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 <seanpaul at chromium.org>
>> ---
>>  .../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