Hi guys, Note: I was a total DRM newbie at the beginning of this exercise. Now I would say I'm just newbie. ;) I am trying to implement our lvds panel using xilinx_drm on zynqmp. We are composing our pipeline starting with the xilinx-vdma, then a few logic parts from the ALI3 on zedboard ref design. The only configurable bits in this pipeline are the vdma registers at one end, then an enable GPIO and PWM going to the panel itself. The rest (resolution, etc.) are hard-coded at synthesis time. This makes things simpler, in theory. I opted to use the lvds-encoder.c (found upstream) which is actually a drm_bridge (!??), and the panel-lvds.c(also upstream) driver which take resolution and timings from dts and create a drm_panel. All I was missing is an encoder (xilinx_drm_encoder would not do). I created a somewhat dummy encoder which binds the crtc to the bridge just by being present. It is discovered by xilinx_drm_drv by the component subsys using the endpoints in dts. >From what I now understand, there are two "worlds" in the DRM/KMS framework, legacy and atomic. From what I gather, xilinx_drm stands on the legacy side. Whereas the drm_bridge and drm_panel are more on the atomic side. I believe this is what's causing a few OOPS and exceptions here and there that I had to "patch" by adding "if" statements for null objects. For example, one is struct drm_connector_state missing on the crtc. This is used by atomic helpers invoked by the drm_bridge (if I remember correctly). In https://github.com/Xilinx/linux-xlnx/commit/d5733539adba1c509cb82bd3d4d418a3dbfbfd68 there is suggestion that xilinx_drm be converted to atomic modesetting. Is this work started? I would like to contribute by testing and submitting patches. Maybe a topic branch on github in linux-xlnx would help us out, and help you out as well to get the driver more polished sooner. Cheers! /jfd _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
