On Wed, 19 Aug 2020 at 15:50, H. Nikolaus Schaller <hns@xxxxxxxxxxxxx> wrote: > > Hi Ezequiel, > > > Am 19.08.2020 um 12:21 schrieb Ezequiel Garcia <ezequiel@xxxxxxxxxxxxxxxxxxxx>: > > > > Hello, > > > > First of all, I'd like to thank everyone for the great work > > on ingenic-drm. The driver is in very good shape > > and a pleasure to work with. > > > > Yesterday, I checked out branch "paulb-jz4780-ci20-hdmi-5.8-rc5", > > from git.goldelico.com/letux-kernel.git, rebased it on v5.9-rc1, > > and then run weston over HDMI (how often > > weston runs on mips, uh? :) > > Wow! > > > The edid of my monitor is properly read > > and modetest reports all modes. > > > > I've only tested the primary plane, for some reason > > the overlay is not working as expected, but it must > > be probably some minor thing. > > > > As for the bus format, I have just added a skip > > for CONNECTOR_HDMIA types in the encoder > > atomic check. And then MEDIA_BUS_FMT_RGB888_1X24 > > is hardcoded if there are no bus formats negotiated > > Cool! > > > Paul et al, if you guys can rebase your work on v5.9-rc1 > > and Cc I will be happy to review and test the patches. > > I have tried our latest letux-5.9-rc1 tree (with Pauls fixes) > on my setup but screen remains black and the kernel was stuck > after showing "login:" and reported > > [ 490.680469] rcu: INFO: rcu_preempt self-detected stall on CPU > > Maybe, can you share your rebased tree to clearly identify the > subtle differences? Maybe I have broken something by the rebase. > Sure. Please give this a try and let me know if it works for you. I've cleaned and squashed your changes, hopefully I've kept the correct authorship for all of them. https://gitlab.collabora.com/linux/0day/-/commits/jz4780-drm-hdmi-v5.9-rc1 This should be enough to get an fbcon, launch weston, etc. However, there are few things that still don't look right. Seems planes X,Y offset is not working, and also enabling a second plane results in both planes going black for good. This needs some more investigation, but seems at least a good start. Thanks again for all the good work, Ezequiel > > Cheers & thanks again, > > Eze > > Thanks and best regards, > Nikolaus > > > > > > > > > > > > On Tue, 7 Jul 2020 at 04:27, Paul Boddie <paul@xxxxxxxxxxxxx> wrote: > >> > >> On Monday, 6 July 2020 14:12:24 CEST Neil Armstrong wrote: > >>> > >>> On 06/07/2020 01:57, Paul Boddie wrote: > >>>> > >>>> It also seems to be appropriate to set the input_bus_format on the > >>>> platform- specific HDMI driver; otherwise, I doubt that appropriate bus > >>>> encodings will be chosen in the Synopsys driver. > >>> > >>> It does but when not provided, it doesn't use it. > >>> > >>> It's handled in drm_atomic_bridge_chain_select_bus_fmts() : > >>> if (conn->display_info.num_bus_formats && > >>> conn->display_info.bus_formats) > >>> out_bus_fmts[0] = conn->display_info.bus_formats[0]; > >>> else > >>> out_bus_fmts[0] = MEDIA_BUS_FMT_FIXED; > >> > >> OK. I thought I'd seen this somewhere, but I had started to think that > >> input_bus_format would remain initialised (presumably to zero) and this would > >> then cause the Synopsys driver to not change the bus format to the actual > >> default. > >> > >> [...] > >> > >>>> Testing against 5.8-rc3 with the above changes seems to have moved the > >>>> needle slightly. Although I still get "Input not supported" from my > >>>> monitor, running modetest now gives a different error: > >>>> > >>>> modetest -D /dev/dri/card0 -M ingenic-drm -s 34@32:1280x1024-60.02 > >>>> > >>>> ...now yields this: > >>>> > >>>> setting mode 1280x1024-60.02Hz@XR24 on connectors 34, crtc 32 > >>>> failed to set gamma: Invalid argument > >>> > >>> This is because you don't provide the gamma setup ioctl, it's not a fatal > >>> error at all. It should be warning since it's optional. > >>> > >>> Did you check all modes ? > >> > >> I have checked a few more. Currently, testing them is awkward because it > >> involves switching my monitor to DVI input, getting "Input Not Supported", > >> unplugging the cable, and then the hotplug event has most likely caused a bad > >> pointer dereference in ingenic_drm_crtc_atomic_flush and thus a kernel panic. > >> > >> So, I'll try and fix this panic, which appears to be due to the DRM driver > >> accessing a null framebuffer pointer (presumably having been invalidated > >> elsewhere upon unplugging), and see if I can't get some more information about > >> the state of the peripherals. > >> > >> Paul > >> > >> > >> _______________________________________________ > >> dri-devel mailing list > >> dri-devel@xxxxxxxxxxxxxxxxxxxxx > >> https://lists.freedesktop.org/mailman/listinfo/dri-devel > _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
