Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1241025 > unrolled thread

i.mx6 video out in mainline

Back to article view | Back to linux.kernel

Contents

  i.mx6 video out in mainline Pushpal Sidhu <psidhu@gateworks.com> - 2015-10-07 00:00 +0200
    Re: i.mx6 video out in mainline Fabio Estevam <festevam@gmail.com> - 2015-10-07 00:30 +0200
      Re: i.mx6 video out in mainline Pushpal Sidhu <psidhu@gateworks.com> - 2015-10-07 01:10 +0200
        Re: i.mx6 video out in mainline Fabio Estevam <festevam@gmail.com> - 2015-10-07 05:10 +0200
          Re: i.mx6 video out in mainline Pushpal Sidhu <psidhu@gateworks.com> - 2015-10-08 23:00 +0200
        Re: i.mx6 video out in mainline Lucas Stach <l.stach@pengutronix.de> - 2015-10-07 08:50 +0200
          Re: i.mx6 video out in mainline Pushpal Sidhu <psidhu@gateworks.com> - 2015-10-08 21:40 +0200

#1241025 — i.mx6 video out in mainline

Hi All,

I'm attempting to use a standard fb console (using the
imx6qdl-gw54xx.dtsi), but I find that it only draws to the 1024x768p
portion of the screen. This is also true when running the userspace
tool fb-test.

When I $(cat /sys/class/graphics/fb0/modes), I see only the 1024x768p
resolution there. I verified that the edid read from the monitor is
correct, and that all of it's modes were properly read (in the
drm_mode_std function and enumerated in
/sys/devices/soc0/display-subsystem/drm/card0/card0-HDMI-A-1/modes),
but I can't figure out how to choose a different resolution. I've also
verified that dpms is 'On'.

The monitor appears to think that a 1080p signal is coming in, which
might have to do with the virtual size being set to 1080p. I should
note that I'm not running X11. Is there something I am missing that's
required for changing framebuffer resolutions? Thanks ahead of time.

- Pushpal
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1241037

On Tue, Oct 6, 2015 at 6:52 PM, Pushpal Sidhu <psidhu@gateworks.com> wrote:
> Hi All,
>
> I'm attempting to use a standard fb console (using the
> imx6qdl-gw54xx.dtsi), but I find that it only draws to the 1024x768p
> portion of the screen. This is also true when running the userspace
> tool fb-test.

Looking at imx6qdl-gw54xx.dtsi I see you have a LVDS panel with
1024x768 resolution.

I sent a patch that allows LDB and HDMI to work simultaneously:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/arch/arm/boot/dts/imx6qdl-sabresd.dtsi?id=d28be499c45e6e16d7a042ce280eb872dc06952b

Can you try to adapt it for imx6qdl-gw54xx.dtsi?

If this still does not help your HDMI output, please try disabling the LVDS.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1241072

On Tue, Oct 6, 2015 at 3:16 PM, Fabio Estevam <festevam@gmail.com> wrote:
> On Tue, Oct 6, 2015 at 6:52 PM, Pushpal Sidhu <psidhu@gateworks.com> wrote:
>> Hi All,
>>
>> I'm attempting to use a standard fb console (using the
>> imx6qdl-gw54xx.dtsi), but I find that it only draws to the 1024x768p
>> portion of the screen. This is also true when running the userspace
>> tool fb-test.
>
> Looking at imx6qdl-gw54xx.dtsi I see you have a LVDS panel with
> 1024x768 resolution.
>
> I sent a patch that allows LDB and HDMI to work simultaneously:
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/arch/arm/boot/dts/imx6qdl-sabresd.dtsi?id=d28be499c45e6e16d7a042ce280eb872dc06952b
>
> Can you try to adapt it for imx6qdl-gw54xx.dtsi?
>
> If this still does not help your HDMI output, please try disabling the LVDS.

When I took your patch and adapted it for imx6qdl-gw54xx.dtsi, I found
that HDMI video out was slightly shifted to the left and resolution
remained at 1024x768p.

I also found that when I disabled DRM_IMX_LDB, HDMI out stopped
working altogether, though if I stripped out the ldb section in device
tree, the resolution comes back at 1080p (regardless of setting
DRM_IMX_LDB or not). There is definitely some strange interdependency
between lvds and hdmi here. Do you have an idea of where I should
start looking for this problem?

- Pushpal
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1241137

On Tue, Oct 6, 2015 at 8:02 PM, Pushpal Sidhu <psidhu@gateworks.com> wrote:

> When I took your patch and adapted it for imx6qdl-gw54xx.dtsi, I found
> that HDMI video out was slightly shifted to the left and resolution
> remained at 1024x768p.
>
> I also found that when I disabled DRM_IMX_LDB, HDMI out stopped
> working altogether, though if I stripped out the ldb section in device
> tree, the resolution comes back at 1080p (regardless of setting
> DRM_IMX_LDB or not). There is definitely some strange interdependency
> between lvds and hdmi here. Do you have an idea of where I should
> start looking for this problem?

I thought we have already fixed that. Does this issue still happen with 4.3-rc4?

I would suggest turning on debug in drivers/gpu/ipu-v3/ipu-di.c and
see the DI frequencies you are getting for the HDMI and LDB ports.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1242734

On Tue, Oct 6, 2015 at 8:07 PM, Fabio Estevam <festevam@gmail.com> wrote:
> On Tue, Oct 6, 2015 at 8:02 PM, Pushpal Sidhu <psidhu@gateworks.com> wrote:
>
>> When I took your patch and adapted it for imx6qdl-gw54xx.dtsi, I found
>> that HDMI video out was slightly shifted to the left and resolution
>> remained at 1024x768p.
>>
>> I also found that when I disabled DRM_IMX_LDB, HDMI out stopped
>> working altogether, though if I stripped out the ldb section in device
>> tree, the resolution comes back at 1080p (regardless of setting
>> DRM_IMX_LDB or not). There is definitely some strange interdependency
>> between lvds and hdmi here. Do you have an idea of where I should
>> start looking for this problem?
>
> I thought we have already fixed that. Does this issue still happen with 4.3-rc4?
>
> I would suggest turning on debug in drivers/gpu/ipu-v3/ipu-di.c and
> see the DI frequencies you are getting for the HDMI and LDB ports.

I moved to 4.3-rc4, and found that HDMI and LVDS DI freq's are
different (with your patch to move LVDS's parent clock to OTG.

HDMI: imx-ipuv3 2400000.ipu: Clocks: IPU 264000000Hz DI 65000000Hz
Needed 65000000Hz
LVDS: imx-ipuv3 2400000.ipu: Clocks: IPU 264000000Hz DI 68571429Hz
Needed 65000000Hz

However, if I have both HDMI and LVDS hooked into the system at the
same time, the HDMI's EDID block 0 is always invalid.

$ cat /proc/cmdline
console=ttymxc1,115200 root=ubi0:rootfs ubi.mtd=2 rootfstype=ubifs
debug video=HDMI-A-1,1920x1080M@60

$ dmesg | grep "ipu\|drm\|hdmi\|lvds"
[    1.983369] [drm] Initialized drm 1.1.0 20060810
[    1.990533] imx-ipuv3 2400000.ipu: IPUv3H probed
[    1.996823] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[    2.004000] [drm] No driver support for vblank timestamp query.
[    2.010539] imx-drm display-subsystem: bound imx-ipuv3-crtc.0 (ops
ipu_crtc_ops)
[    2.018549] imx-drm display-subsystem: bound imx-ipuv3-crtc.1 (ops
ipu_crtc_ops)
[    2.026575] imx-drm display-subsystem: bound imx-ipuv3-crtc.4 (ops
ipu_crtc_ops)
[    2.034608] imx-drm display-subsystem: bound imx-ipuv3-crtc.5 (ops
ipu_crtc_ops)
[    2.043253] dwhdmi-imx 120000.hdmi: Detected HDMI controller
0x13:0xa:0xa0:0xc1
[    2.057862] imx-drm display-subsystem: bound 120000.hdmi (ops
dw_hdmi_imx_ops)
[    2.072465] imx-drm display-subsystem: bound
2000000.aips-bus:ldb@020e0008 (ops imx_ldb_ops)
[    2.097335] [drm:drm_edid_block_valid] *ERROR* EDID checksum is
invalid, remainder is 81
[    2.169323] [drm:drm_edid_block_valid] *ERROR* EDID checksum is
invalid, remainder is 81
[    2.241300] [drm:drm_edid_block_valid] *ERROR* EDID checksum is
invalid, remainder is 81
[    2.313291] [drm:drm_edid_block_valid] *ERROR* EDID checksum is
invalid, remainder is 81
[    2.369763] imx-drm display-subsystem: HDMI-A-1: EDID block 0 invalid.
[    2.416797] imx-drm display-subsystem: fb0:  frame buffer device
[    2.460575] [drm] Initialized imx-drm 1.0.0 20120507 on minor 0
[    2.466766] imx-ipuv3 2800000.ipu: IPUv3H probed
[   28.270558] imx-ipuv3 2400000.ipu: Timeout waiting for DMFC FIFOs to clear

This causes the HDMI monitor to get a signal, and within a second,
think that a signal no longer exists. Also, it seems that LVDS (even
connected by itself), appears to work. The backlight comes on, but
nothing gets drawn to the display. I then tried the following:

$ cat /proc/cmdline
console=ttymxc1,115200 root=ubi0:rootfs ubi.mtd=2 rootfstype=ubifs
debug video=HDMI-A-1:d video=LVDS-1:e

That is, forcing HDMI off and LVDS on. I verified that the kernel saw
this (e.g. [drm] forcing HDMI-A-1 connector OFF) and found an
interesting result. The LVDS backlight still turns on, but the HDMI
had the image painted onto it while being colorspace converted for the
LVDS monitor (white showed up as a light blue, green was blue, red was
green etc). It looks like when only LVDS is connected, signals still
get sent to the HDMI monitor, which would explain why it appears that
LVDS doesn't work.

Comparing the imx6qdl-gw54xx.dtsi and imx6qdl-sabersd.dtsi, I couldn't
see too many differences between HDMI and LVDS, so I'm a little
surprised you don't see this exact same behavior there. Note that I've
tried this with the patch for changing the LVDS's parent clock in the
imx6qdl-gw54xx.dtsi file.

- Pushpal
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1241170

Am Dienstag, den 06.10.2015, 16:02 -0700 schrieb Pushpal Sidhu:
> On Tue, Oct 6, 2015 at 3:16 PM, Fabio Estevam <festevam@gmail.com>
> wrote:
> > On Tue, Oct 6, 2015 at 6:52 PM, Pushpal Sidhu <psidhu@gateworks.com
> > > wrote:
> > > Hi All,
> > > 
> > > I'm attempting to use a standard fb console (using the
> > > imx6qdl-gw54xx.dtsi), but I find that it only draws to the
> > > 1024x768p
> > > portion of the screen. This is also true when running the
> > > userspace
> > > tool fb-test.
> > 
> > Looking at imx6qdl-gw54xx.dtsi I see you have a LVDS panel with
> > 1024x768 resolution.
> > 
> > I sent a patch that allows LDB and HDMI to work simultaneously:
> > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/com
> > mit/arch/arm/boot/dts/imx6qdl
> > -sabresd.dtsi?id=d28be499c45e6e16d7a042ce280eb872dc06952b
> > 
> > Can you try to adapt it for imx6qdl-gw54xx.dtsi?
> > 
> > If this still does not help your HDMI output, please try disabling
> > the LVDS.
> 
> When I took your patch and adapted it for imx6qdl-gw54xx.dtsi, I
> found
> that HDMI video out was slightly shifted to the left and resolution
> remained at 1024x768p.
> 
> I also found that when I disabled DRM_IMX_LDB, HDMI out stopped
> working altogether, though if I stripped out the ldb section in
> device
> tree, the resolution comes back at 1080p (regardless of setting
> DRM_IMX_LDB or not). There is definitely some strange interdependency
> between lvds and hdmi here. Do you have an idea of where I should
> start looking for this problem?
> 
This isn't strange, but actually really simple to explain:

1. The DRM driver is a componentized driver that needs all of its
components to come up before it registers the DRM device. So if you
have the LDB enabled in your DT you also need the LDB driver, otherwise
you won't get any video out. If you don't want to have LDB, don't
disable the driver alone, but also add a status = "disabled" in the DT
LDB node.

2. The kernels framebuffer emulation layer will try to put the
framebuffer on both displays. So if you have a smaller LVDS display
connected the framebuffer will only have the size of the smaller
display. Solution is to not depend on the kernels frambuffer emulation,
but actually set a mode from userspace and work with the KMS interface
directly.

Regards,
Lucas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1242700

On Tue, Oct 6, 2015 at 11:45 PM, Lucas Stach <l.stach@pengutronix.de> wrote:
> Am Dienstag, den 06.10.2015, 16:02 -0700 schrieb Pushpal Sidhu:
>> On Tue, Oct 6, 2015 at 3:16 PM, Fabio Estevam <festevam@gmail.com>
>> wrote:
>> > On Tue, Oct 6, 2015 at 6:52 PM, Pushpal Sidhu <psidhu@gateworks.com
>> > > wrote:
>> > > Hi All,
>> > >
>> > > I'm attempting to use a standard fb console (using the
>> > > imx6qdl-gw54xx.dtsi), but I find that it only draws to the
>> > > 1024x768p
>> > > portion of the screen. This is also true when running the
>> > > userspace
>> > > tool fb-test.
>> >
>> > Looking at imx6qdl-gw54xx.dtsi I see you have a LVDS panel with
>> > 1024x768 resolution.
>> >
>> > I sent a patch that allows LDB and HDMI to work simultaneously:
>> > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/com
>> > mit/arch/arm/boot/dts/imx6qdl
>> > -sabresd.dtsi?id=d28be499c45e6e16d7a042ce280eb872dc06952b
>> >
>> > Can you try to adapt it for imx6qdl-gw54xx.dtsi?
>> >
>> > If this still does not help your HDMI output, please try disabling
>> > the LVDS.
>>
>> When I took your patch and adapted it for imx6qdl-gw54xx.dtsi, I
>> found
>> that HDMI video out was slightly shifted to the left and resolution
>> remained at 1024x768p.
>>
>> I also found that when I disabled DRM_IMX_LDB, HDMI out stopped
>> working altogether, though if I stripped out the ldb section in
>> device
>> tree, the resolution comes back at 1080p (regardless of setting
>> DRM_IMX_LDB or not). There is definitely some strange interdependency
>> between lvds and hdmi here. Do you have an idea of where I should
>> start looking for this problem?
>>
> This isn't strange, but actually really simple to explain:
>
> 1. The DRM driver is a componentized driver that needs all of its
> components to come up before it registers the DRM device. So if you
> have the LDB enabled in your DT you also need the LDB driver, otherwise
> you won't get any video out. If you don't want to have LDB, don't
> disable the driver alone, but also add a status = "disabled" in the DT
> LDB node.
>
> 2. The kernels framebuffer emulation layer will try to put the
> framebuffer on both displays. So if you have a smaller LVDS display
> connected the framebuffer will only have the size of the smaller
> display. Solution is to not depend on the kernels frambuffer emulation,
> but actually set a mode from userspace and work with the KMS interface
> directly.

Ah, that makes total sense then. Do you know of any userspace
application that works using the KMS interface, other than using
x11/wayland (in other words, something extremely simple like fbset)?
I've gotten too used to using the downstream vendor kernel way of
using sysfs to set the modes per display so I'm trying to learn the
"right" way of doing things.

About sysfs, why is it that the seemingly obsolete
/sys/class/graphics/fbX/{mode,modes} still exist in the kernel when
they seem to serve no function? Is that just some cleanup that hasn't
occurred yet?

- Pushpal
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web