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

2016-11-15 21:46 GMT+01:00 Jyri Sarha [off-list ref]:

On 11/15/16 19:36, Bartosz Golaszewski wrote:

quoted

2016-11-14 17:54 GMT+01:00 Jyri Sarha [off-list ref]:

quoted

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

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.

quoted

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
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html