2016-11-15 21:46 GMT+01:00 Jyri Sarha <jsarha@xxxxxx>: > On 11/15/16 19:36, Bartosz Golaszewski wrote: >> 2016-11-14 17:54 GMT+01:00 Jyri Sarha <jsarha@xxxxxx>: >>> 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@xxxxxx> >>> --- >> >> 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 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
