[PATCH v2 3/3] drm/tilcdc: Add drm bridge support for attaching drm bridge drivers

[Bartosz Golaszewski]

2016-11-15 21:46 GMT+01:00 Jyri Sarha <jsarha at ti.com>:
> On 11/15/16 19:36, Bartosz Golaszewski wrote:
>> 2016-11-14 17:54 GMT+01:00 Jyri Sarha <jsarha at ti.com>:
>>> Adds drm bride support for attaching drm bridge drivers to tilcdc. The
>>> decision whether a video port leads to an external encoder or bridge
>>> is made simply based on remote device's compatible string. The code
>>> has been tested with BeagleBone-Black with and without BeagleBone
>>> DVI-D Cape Rev A3 using ti-tfp410 driver.
>>>
>>> Signed-off-by: Jyri Sarha <jsarha at ti.com>
>>> ---
>>
>> Hi Jyri,
>>
>> thanks a lot for doing this.
>>
>> One issue I see with this patch is that tilcdc doesn't seem to support
>> deferred probe correctly (if modules are built-in). The following
>> happens on my setup:
>>
>> The dump-vga-dac module is loaded first, but the i2c0 is not ready yet
>> - probe returns EPROBE_DEFER and it's propagated to tilcdc probe.
>>
>>     [drm] Initialized
>>     dumb-vga-dac vga_bridge: Couldn't retrieve i2c bus
>>
>> Then the i2c bus is initialized and dump-vga-dac probe succeeds, but
>> the second probe of tilcdc gives me:
>>
>>     [drm:drm_debugfs_init] *ERROR* Cannot create /sys/kernel/debug/dri/64
>>     [drm:drm_minor_register] *ERROR* DRM: Failed to initialize
>> /sys/kernel/debug/dri.
>>     tilcdc: probe of da8xx_lcdc.0 failed with error -1
>>
>> I was able to work around this issue by loading modules in correct order.
>>
>
> Did you have any conflicts when applying my patch? I have done quite a
> few changes lately and especially the initialization sequence and back
> off from deferred probe may get broken easily broken if the source base
> is not correct. I try to come up with a pull-request candidate branch
> soon (hopefully tomorrow) for you to test.
>

I only had some trivial conflicts, but you're right, maybe I'm missing
some parts. It would be great to have a branch for testing - I could
then rebase my follow-up work on tilcdc against it.

>> I then tried testing the patch with a da850-lcdk, but I don't get
>> anything on the display (no signal), even though the LCDC seems to
>> work fine (modetest and dmesg messages work just like when using the
>> tilcdc panel). Also: I see the EDID info is correctly retrieved from
>> the display.
>>
>> Could you take a look at my DT[1] and see if you find it correct?
>>
>
> It is hard to follow the dts diff, but if it probes and tilcdc is able
> to read EDID modes, there should not be anything more to it.
>

Yes, this is what I thought too.

Let me know when you'll have the testing branch ready.

Best regards,
Bartosz Golaszewski