[BUG] DM_VIDEO broken on imx6q
Hi,
unfortunately the patch [1] is only the first part to get DM_VIDEO running properly on tbs2910 for u-boot-2020.10. With this, I get a valid video output signal, but no actual video console output, only a blank screen.
After some debugging, no with access to a HDMI monitor, the problem seems to be: imx6q has two ipu units, so DM_VIDEO creates 2 video devices. For these two devices also memory for two framebuffers is reserved in video-uclass, starting from gd->video_top downwards. Then vidconsole correctly uses the first video device (ipu1), but apparently the framebuffer from ipu2 at gd->video_bottom. So I see the empty framebuffer from ipu1 while the console output goes to the framebuffer memory of ipu2.
I guess there is the same problem on all imx6q devices with 2 ipu units, while on imx6s/6dl devices with a single ipu everything works fine. Disabling the second ipu in the tbs2910 devicetree also helps, but I think this is not a proper solution.
What should be done about this? Only probing the first ipu/video device? Assigning the framebuffer memory bottom-up? Using the assigned framebuffer memory of the active video device for console output (seems to be the correct solution, but maybe not so easy to implement)? Something else?
Thanks, Soeren
[1] https://patchwork.ozlabs.org/project/uboot/patch/20200730121157.5305-1-smoch...
Hi,
On Sat, 1 Aug 2020 21:14:10 +0200 Soeren Moch smoch@web.de wrote:
Hi,
unfortunately the patch [1] is only the first part to get DM_VIDEO running properly on tbs2910 for u-boot-2020.10. With this, I get a valid video output signal, but no actual video console output, only a blank screen.
After some debugging, no with access to a HDMI monitor, the problem seems to be: imx6q has two ipu units, so DM_VIDEO creates 2 video devices. For these two devices also memory for two framebuffers is reserved in video-uclass, starting from gd->video_top downwards. Then vidconsole correctly uses the first video device (ipu1), but apparently the framebuffer from ipu2 at gd->video_bottom. So I see the empty framebuffer from ipu1 while the console output goes to the framebuffer memory of ipu2.
Thanks for debugging and reporting!
I guess there is the same problem on all imx6q devices with 2 ipu units, while on imx6s/6dl devices with a single ipu everything works fine. Disabling the second ipu in the tbs2910 devicetree also helps, but I think this is not a proper solution.
What should be done about this? Only probing the first ipu/video device?
Since the second framebuffer is not in use currently, the probing for second ipu device is not done.
Assigning the framebuffer memory bottom-up? Using the assigned framebuffer memory of the active video device for console output (seems to be the correct solution, but maybe not so easy to implement)?
Yes, the later is the correct solution. I've sent a patch.
-- Anatolij
HiAnatolij,
On 03.08.20 15:54, Anatolij Gustschin wrote:
Hi,
On Sat, 1 Aug 2020 21:14:10 +0200 Soeren Moch smoch@web.de wrote:
Hi,
unfortunately the patch [1] is only the first part to get DM_VIDEO running properly on tbs2910 for u-boot-2020.10. With this, I get a valid video output signal, but no actual video console output, only a blank screen.
After some debugging, no with access to a HDMI monitor, the problem seems to be: imx6q has two ipu units, so DM_VIDEO creates 2 video devices. For these two devices also memory for two framebuffers is reserved in video-uclass, starting from gd->video_top downwards. Then vidconsole correctly uses the first video device (ipu1), but apparently the framebuffer from ipu2 at gd->video_bottom. So I see the empty framebuffer from ipu1 while the console output goes to the framebuffer memory of ipu2.
Thanks for debugging and reporting!
I guess there is the same problem on all imx6q devices with 2 ipu units, while on imx6s/6dl devices with a single ipu everything works fine. Disabling the second ipu in the tbs2910 devicetree also helps, but I think this is not a proper solution.
What should be done about this? Only probing the first ipu/video device?
Since the second framebuffer is not in use currently, the probing for second ipu device is not done.
Assigning the framebuffer memory bottom-up? Using the assigned framebuffer memory of the active video device for console output (seems to be the correct solution, but maybe not so easy to implement)?
Yes, the later is the correct solution. I've sent a patch.
Thank you very much. Patch looks good, and really not too complicated. I will try to test this later today.
Thanks again, Soeren
-- Anatolij
participants (2)
-
Anatolij Gustschin -
Soeren Moch