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

Jyri Sarha jsarha at ti.com
Tue Nov 15 20:46:08 UTC 2016


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 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.

Cheers,
Jyri

> Best regards,
> Bartosz Golaszewski
> 
> [1] http://pastebin.com/dfUX7PyL
> 



More information about the dri-devel mailing list