Date   

imx51evk and Zeus

Mauro Ziliani
 

Hi all.

I'm working on a imx51evk clone board and  Zeus.

U-boot-fslc restart with POR cause.


Where i can find good docs for Zeus and imx51evk?


Best regards,

  MZ


Imx6q: Mirror lvds and lcd on linux-fslc-imx

Wouter Vanhauwaert
 

Hello, 
I want to connect 2 identical FHD screens (timing-wise) to my imx6q board. One is LCD and the other one (dualchannel) LVDS. I only want to render content once (for perfomance) and output it on both. If I change the mxcfb0 from ldb to lcd and visa versa, it's working for the one configured, but not for both.
I thought it would be as simple as configuring the ldb bridge and setting the pinmuxes of the di0 pins correct, but that is clearly is not the case...
I'm using nxp implementation btw, not the mainline drivers.

Anyone knows?

(is there a mailinglist for kernel things only btw?)


Re: Adding LCD display (none lvds) in Linux 5.4 fslc?

Fabio Estevam
 

Hi Wouter,

On Mon, Aug 17, 2020 at 3:59 PM Wouter Vanhauwaert
<w.vanhauwaert@...> wrote:

Sorry, but I think that's not correct...
Yes, when I looked at the commit you referred to I thought initially
that it only added drivers/video/fbdev/mxsfb.c, which is the eLCDIF
controller. In fact, it adds more things other than the mxsfb driver
and it also handles the IPU driver.

Indeed, you can use fsl,imx-parallel-display, but then you're using the opensource/drm mainline way of addressing the ipu, and not the freescale proprietary way.
Correct.

fbdev/mxc/ldb.c is still providing the freescale proprietary way of configuring a mxcfb device
fbdev/mxc/mxc_lcdif.c is also using the imx6q/dl ipu for it's parallel lcd display, only it is gone since kernel 4.9-imx, which is strange as even the imx6qdl-sabresd.dtsi in the 5.4-2.0.x-imx branch is referring to it..
The way it is now, nothing is handling the compatible "fsl,lcd" in the whole 4.9-imx or 5.4-imx kernels, which is wrong according to me. I think it is just forgotten in a previous merge...
Yes, I agree.

That would mean that commit https://github.com/Freescale/linux-fslc/commit/afcde9250592b07f165e2f66217726e26ac54e7c was incomplete.
As a test, I just put back the mxc_lcdif.c, and now my display is working perfectly again with configured devicetree:

lcd@0 {
compatible = "fsl,lcd";
ipu_id = <0>;
disp_id = <0>;
default_ifmt = "RGB24";
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_ipu1>;
status = "okay";
};

mxcfb1: fb@0 {
compatible = "fsl,mxc_sdc_fb";
disp_dev = "lcd";
interface_pix_fmt = "RGB24";
mode_str ="CLAA-WVGA";
default_bpp = <16>;
int_clk = <0>;
late_init = <0>;
status = "disabled";
};

If you think I am correct, I can create a pullrequest...
It looks correct.

Sorry for the confusion, I thought your goal was to use the "mainline"
way to drive a parallel panel on mx6. Now I understand that you want
to use the "NXP way".


Re: Adding LCD display (none lvds) in Linux 5.4 fslc?

Wouter Vanhauwaert
 

Sorry, but I think that's not correct...
Indeed, you can use fsl,imx-parallel-display, but then you're using the opensource/drm mainline way of addressing the ipu, and not the freescale proprietary way.

fbdev/mxc/ldb.c is still providing the freescale proprietary way of configuring a mxcfb device
fbdev/mxc/mxc_lcdif.c is also using the imx6q/dl ipu for it's parallel lcd display, only it is gone since kernel 4.9-imx, which is strange as even the imx6qdl-sabresd.dtsi in the 5.4-2.0.x-imx branch is referring to it.. 
The way it is now, nothing is handling the compatible "fsl,lcd" in the whole 4.9-imx or 5.4-imx kernels, which is wrong according to me. I think it is just forgotten in a previous merge...
That would mean that commit https://github.com/Freescale/linux-fslc/commit/afcde9250592b07f165e2f66217726e26ac54e7c was incomplete.
As a test, I just put back the mxc_lcdif.c, and now my display is working perfectly again with configured devicetree:

   lcd@0 {
        compatible = "fsl,lcd";
        ipu_id = <0>;
        disp_id = <0>;
        default_ifmt = "RGB24";
        pinctrl-names = "default";
        pinctrl-0 = <&pinctrl_ipu1>;
        status = "okay";
    };
 
    mxcfb1: fb@0 {
        compatible = "fsl,mxc_sdc_fb";
        disp_dev = "lcd";
        interface_pix_fmt = "RGB24";
        mode_str ="CLAA-WVGA";
        default_bpp = <16>;
        int_clk = <0>;
        late_init = <0>;
        status = "disabled";
    };

If you think I am correct, I can create a pullrequest...


Re: Adding LCD display (none lvds) in Linux 5.4 fslc?

Fabio Estevam
 

Hi Wouter,

On Thu, Aug 13, 2020 at 7:28 AM Wouter Vanhauwaert
<w.vanhauwaert@...> wrote:

How do you correctly put a parallel lcd display in linux 5.4?
Uptill 4.9, there was a mxc_lcdif.c, but seems to be missing now?
In the devicetree, you used to add a node which had compatible="fsl,lcd", addressing the pinctrl etc
But none of these seem to exist now?
I see a commit https://github.com/Freescale/linux-fslc/commit/afcde9250592b07f165e2f66217726e26ac54e7c
eLCDIF is a different display controller that is found on other i.MX
SoCs like imx23/imx28/imx6sl/imx6sx.

On imx6q/dl the display controller is the IPU.

In order to drive a parallel display using the IPU on imx6dl you need
to pass compatible = "fsl,imx-parallel-display";

Please see some dts as examples, such as arch/arm/boot/dts/imx6qdl-pico.dtsi.

It is also recommended to add an entry for the panel you are using
inside drivers/gpu/drm/panel/panel-simple.c


Re: fec driver works on linux-imx, not linux-fslc+use-mainline-bsp (imx6dl)

Andrey Zhizhikin
 

Hello Christian,

On Mon, Aug 17, 2020 at 2:32 PM Christian Betz <christian.betz@...> wrote:

Hi,

I'm porting a custom MX6DL board from linux-imx to linux-fslc (along with use-mainline-bsp in FEATURES). The primary reason for this choice was for etnaviv support and a general preference for a mainline kernel. I'm pleased to say that the etnaviv is working ok!

Problem: The ethernet connection does not work correctly. It seems to accept pings and I can login via SSH. However, any scp or http transfer fails. Ifconfig shows TX errors. None of these issues happen on linux-imx. btw, i have an imx6qsabresd demo board running linux-fslc with use-mainline-bsp and the ethernet works fine on it.

There are no errors/warnings in dmesg. If I use "ping -s 1500 $DEVICE_IP", I definitely notice pings being lost, so this seems related to packet size somehow.

I'm looking for some suggestions on next steps to troubleshoot this issue, or some idea of what is different between linux-imx and linux-fslc when it comes to the fec driver. Note: i'm running kernel 5.4.46 based on revision 38d6c352 (Otavio's merge on June 15th).
Do you see the same behavior with linux-fslc-imx kernel tree? It is
basically NXP kernel + latest patch level from upstream.

Can you test that one and let here know if you have the same thing
there? If it happened that it is not exhibiting the same errors - then
there is something definitely missing in the mainline kernel, which
should be cherry-picked from NXP BSP and sent to upstream.

I cannot test that since I do not have i.MX6 HW on hands...


As far as can tell, our ethernet-related customizations are minimal, basically these changes to 'pinctrl_enet' imx6qdl-sabresd.dtsi. Again, these changes seem to work fine on linux-imx but not linux-fslc with use-mainline-bsp.

pinctrl_enet: enetgrp {
fsl,pins = <
MX6QDL_PAD_ENET_MDIO__ENET_MDIO 0x1b0b0
MX6QDL_PAD_ENET_MDC__ENET_MDC 0x1b0b0
MX6QDL_PAD_RGMII_TXC__RGMII_TXC 0x1b030
MX6QDL_PAD_RGMII_TD0__RGMII_TD0 0x1b030
MX6QDL_PAD_RGMII_TD1__RGMII_TD1 0x1b030
MX6QDL_PAD_RGMII_TD2__RGMII_TD2 0x1b030
MX6QDL_PAD_RGMII_TD3__RGMII_TD3 0x1b030
MX6QDL_PAD_RGMII_TX_CTL__RGMII_TX_CTL 0x1b030
- MX6QDL_PAD_ENET_REF_CLK__ENET_TX_CLK 0x1b0b0
+ /* MX6QDL_PAD_ENET_REF_CLK__ENET_TX_CLK 0x1b0b0
+ * Changes to CONFIG_BITS
+ * Turn off PAD_CTL_HYS, PAT_CTL_PUS_22KUP
+ * Turn on SRE_FAST
+ */
+ MX6QDL_PAD_ENET_REF_CLK__ENET_TX_CLK 0x100b1
MX6QDL_PAD_RGMII_RXC__RGMII_RXC 0x1b030
MX6QDL_PAD_RGMII_RD0__RGMII_RD0 0x1b030
MX6QDL_PAD_RGMII_RD1__RGMII_RD1 0x1b030
MX6QDL_PAD_RGMII_RD2__RGMII_RD2 0x1b030
MX6QDL_PAD_RGMII_RD3__RGMII_RD3 0x1b030
MX6QDL_PAD_RGMII_RX_CTL__RGMII_RX_CTL 0x1b030
- MX6QDL_PAD_GPIO_16__ENET_REF_CLK 0x4001b0a8
+ /* Completely disable ENET_REF_CLK (???) */
+ /*MX6QDL_PAD_GPIO_16__ENET_REF_CLK 0x4001b0a8*/
>;
};





--
Regards,
Andrey.


Re: fec driver works on linux-imx, not linux-fslc+use-mainline-bsp (imx6dl)

Fabio Estevam
 

Hi Christian,

On Mon, Aug 17, 2020 at 9:32 AM Christian Betz <christian.betz@...> wrote:

Hi,

I'm porting a custom MX6DL board from linux-imx to linux-fslc (along with use-mainline-bsp in FEATURES). The primary reason for this choice was for etnaviv support and a general preference for a mainline kernel. I'm pleased to say that the etnaviv is working ok!

Problem: The ethernet connection does not work correctly. It seems to accept pings and I can login via SSH. However, any scp or http transfer fails. Ifconfig shows TX errors. None of these issues happen on linux-imx. btw, i have an imx6qsabresd demo board running linux-fslc with use-mainline-bsp and the ethernet works fine on it.

There are no errors/warnings in dmesg. If I use "ping -s 1500 $DEVICE_IP", I definitely notice pings being lost, so this seems related to packet size somehow.

I'm looking for some suggestions on next steps to troubleshoot this issue, or some idea of what is different between linux-imx and linux-fslc when it comes to the fec driver. Note: i'm running kernel 5.4.46 based on revision 38d6c352 (Otavio's merge on June 15th).

As far as can tell, our ethernet-related customizations are minimal, basically these changes to 'pinctrl_enet' imx6qdl-sabresd.dtsi. Again, these changes seem to work fine on linux-imx but not linux-fslc with use-mainline-bsp.
What is the Ethernet PHY on your board? Is it getting detected by
looking at the dmesg log?

Could you share the schematics and device tree?


fec driver works on linux-imx, not linux-fslc+use-mainline-bsp (imx6dl)

Christian Betz
 

Hi,

I'm porting a custom MX6DL board from linux-imx to linux-fslc (along with use-mainline-bsp in FEATURES). The primary reason for this choice was for etnaviv support and a general preference for a mainline kernel. I'm pleased to say that the etnaviv is working ok!

Problem: The ethernet connection does not work correctly. It seems to accept pings and I can login via SSH. However, any scp or http transfer fails. Ifconfig shows TX errors. None of these issues happen on linux-imx. btw, i have an imx6qsabresd demo board running linux-fslc with use-mainline-bsp and the ethernet works fine on it.

There are no errors/warnings in dmesg. If I use "ping -s 1500 $DEVICE_IP", I definitely notice pings being lost, so this seems related to packet size somehow.

I'm looking for some suggestions on next steps to troubleshoot this issue, or some idea of what is different between linux-imx and linux-fslc when it comes to the fec driver. Note: i'm running kernel 5.4.46 based on revision 38d6c352 (Otavio's merge on June 15th).

As far as can tell, our ethernet-related customizations are minimal, basically these changes to 'pinctrl_enet' imx6qdl-sabresd.dtsi. Again, these changes seem to work fine on linux-imx but not linux-fslc with use-mainline-bsp.

                pinctrl_enet: enetgrp {
                        fsl,pins = <
                                MX6QDL_PAD_ENET_MDIO__ENET_MDIO         0x1b0b0
                                MX6QDL_PAD_ENET_MDC__ENET_MDC           0x1b0b0
                                MX6QDL_PAD_RGMII_TXC__RGMII_TXC         0x1b030
                                MX6QDL_PAD_RGMII_TD0__RGMII_TD0         0x1b030
                                MX6QDL_PAD_RGMII_TD1__RGMII_TD1         0x1b030
                                MX6QDL_PAD_RGMII_TD2__RGMII_TD2         0x1b030
                                MX6QDL_PAD_RGMII_TD3__RGMII_TD3         0x1b030
                                MX6QDL_PAD_RGMII_TX_CTL__RGMII_TX_CTL   0x1b030
-                               MX6QDL_PAD_ENET_REF_CLK__ENET_TX_CLK    0x1b0b0
+                               /* MX6QDL_PAD_ENET_REF_CLK__ENET_TX_CLK 0x1b0b0
+                                * Changes to CONFIG_BITS
+                                *  Turn off PAD_CTL_HYS, PAT_CTL_PUS_22KUP
+                                *  Turn on SRE_FAST
+                                */
+                               MX6QDL_PAD_ENET_REF_CLK__ENET_TX_CLK    0x100b1
                                MX6QDL_PAD_RGMII_RXC__RGMII_RXC         0x1b030
                                MX6QDL_PAD_RGMII_RD0__RGMII_RD0         0x1b030
                                MX6QDL_PAD_RGMII_RD1__RGMII_RD1         0x1b030
                                MX6QDL_PAD_RGMII_RD2__RGMII_RD2         0x1b030
                                MX6QDL_PAD_RGMII_RD3__RGMII_RD3         0x1b030
                                MX6QDL_PAD_RGMII_RX_CTL__RGMII_RX_CTL   0x1b030
-                               MX6QDL_PAD_GPIO_16__ENET_REF_CLK        0x4001b0a8
+                               /* Completely disable ENET_REF_CLK (???) */
+                               /*MX6QDL_PAD_GPIO_16__ENET_REF_CLK      0x4001b0a8*/
                        >;
                };




Re: Adding LCD display (none lvds) in Linux 5.4 fslc?

Wouter Vanhauwaert
 

Hmm, it doesn't work.
But is this endpoint-setup not meant to be used together with DRM?
Whereas before it was for mxcfb? I'm stilll a bit lost...


Re: Adding LCD display (none lvds) in Linux 5.4 fslc?

Wouter Vanhauwaert
 

Ok, I'll try it out.
Still I don't understand why they would only change half of the functionality.... (And who decides or follows up)


Re: SPI for IMX6x with cyclic DMA

Andrea Tessadri <tessadriandrea@...>
 

Great, thanks! 


Il gio 13 ago 2020, 17:17 Eric Nelson <ericnelsonaz@...> ha scritto:
Hi Andrea,

On 8/13/20 7:28 AM, Andrey Zhizhikin wrote:
> On Thu, Aug 13, 2020 at 3:31 PM Andrea Tessadri
> <tessadriandrea@...> wrote:
>>
>> I've just developed and tested cyclic DMA transfer for a SPI device on a IMX6UL with kernel 4.9.88

Cool!

>> I wanted to have a single SPI transfer repeated continuously in order to feed a DAC for generation of a particular waveform for a medical device, without interruption and minimal jitter (this is why I though to make the change at low level, instead of making the protocol driver to pump several identical messages to SPI subsystem)
>> I am wondering if this feature could be interesting for other applications and if it is worth to submit a patch for drivers/spi/spi-imx.c
>
> This is definitely a wrong list for those changes, it should go to
> LKML instead. This list is used for discussions regarding Yocto
> Project distribution, and I believe you're interested in merging your
> changes into Kernel. For that you should post this RFC to LKML.
>

Andrey is right that kernel patches aren't submitted through this list.

Depending on how you've implemented this, the proper mailing list will
be either or both linux-spi and dmaengine as noted here:

http://vger.kernel.org/vger-lists.html

That said, there are probably more potential users on this list,
and posting it here might get more feedback than those lists.

And to answer your question about whether it is worth submitting the
patch set, I'd say "yes". Even if it's not accepted, it might prove
useful to others.

Regards,


Eric


Re: SPI for IMX6x with cyclic DMA

Andrey Zhizhikin
 

On Thu, Aug 13, 2020 at 3:31 PM Andrea Tessadri
<tessadriandrea@...> wrote:

I've just developed and tested cyclic DMA transfer for a SPI device on a IMX6UL with kernel 4.9.88
I wanted to have a single SPI transfer repeated continuously in order to feed a DAC for generation of a particular waveform for a medical device, without interruption and minimal jitter (this is why I though to make the change at low level, instead of making the protocol driver to pump several identical messages to SPI subsystem)
I am wondering if this feature could be interesting for other applications and if it is worth to submit a patch for drivers/spi/spi-imx.c
This is definitely a wrong list for those changes, it should go to
LKML instead. This list is used for discussions regarding Yocto
Project distribution, and I believe you're interested in merging your
changes into Kernel. For that you should post this RFC to LKML.

Thank you in advance

Andrea



--
Regards,
Andrey.


Re: Adding LCD display (none lvds) in Linux 5.4 fslc?

Christian Betz
 

On Thu, Aug 13, 2020 at 9:49 AM Christian Betz via lists.yoctoproject.org <christian.betz=gmail.com@...> wrote:
Hi. I recently faced a similar problem on a custom imx6dl board, also with linux-fslc.

I forgot to mention: I am using "use-mainline-bsp" here and I think that matters, as you've pointed out.
 

In my case i only have a single panel but it seems I had to define two panels to make the devicetree compiler happy (one of them is disabled though; and the DRM subsystem doesn't show multiple LVDS nodes). I am new to this though, so perhaps I am doing something wrong. I'm sure i could avoid duplicating the timings at least. (note: afaict the status=disabled on the LDB nodes have no effect; but the panel disable does).

after a day or two i settled on the following DTS definitions which are basically just mods to the stock imx6qdl-sabresd.dtsi

       panel1 {
                compatible = "panel-lvds";
                backlight = <&backlight_lvds>;

                data-mapping = "vesa-24";
                width-mm = <154>;
                height-mm = <87>;

                panel-timing {
                        clock-frequency = <67200000>;
                        hactive = <1024>;
                        vactive = <600>;
                        hfront-porch = <150>;
                        hsync-len = <76>;
                        hback-porch = <150>;
                        vfront-porch = <60>;
                        vsync-len = <80>;
                        vback-porch = <60>;
                        pixelclk-active = <0>;
                        hsync-active = <0>;
                        vsync-active = <0>;
                };

                 port {
                        panel1_in: endpoint {
                                remote-endpoint = <&lvds0_out>;
                        };
                };
        };

        panel2 {
                compatible = "panel-lvds";
                backlight = <&backlight_lvds>;
                status = "disabled";

                data-mapping = "vesa-24";
                width-mm = <154>;
                height-mm = <87>;

                panel-timing {
                        clock-frequency = <67200000>;
                        hactive = <1024>;
                        vactive = <600>;
                        hfront-porch = <150>;
                        hsync-len = <76>;
                        hback-porch = <150>;
                        vfront-porch = <60>;
                        vsync-len = <80>;
                        vback-porch = <60>;
                        pixelclk-active = <0>;
                        hsync-active = <0>;
                        vsync-active = <0>;
                };

                 port {
                        panel2_in: endpoint {
                                remote-endpoint = <&lvds1_out>;
                        };
                };
        };

...

&ldb {
        status = "okay";

        lvds-channel@0 {
                status = "okay";

                port@4 {
                        reg = <4>;

                        lvds0_out: endpoint {
                                remote-endpoint = <&panel1_in>;
                        };
                };
        };

        lvds-channel@1 {
                status = "disabled";

                port@4 {
                        reg = <4>;
                        status = "disabled";

                        lvds1_out: endpoint {
                                remote-endpoint = <&panel2_in>;
                        };
                };
        };
};



On Thu, Aug 13, 2020 at 8:28 AM Wouter Vanhauwaert <w.vanhauwaert@...> wrote:
But that's the mainline way of working, no? When using etnaviv/drm/imx-ipu... ?
Why would the old ldb-style still work, but the old lcd isn't?


--
"the new garbage collector will be an arena-based, quad-color incremental, generational, non-copying, high-speed, cache-optimized garbage collector" -- LuaJIT Roadmap



--
"the new garbage collector will be an arena-based, quad-color incremental, generational, non-copying, high-speed, cache-optimized garbage collector" -- LuaJIT Roadmap


Re: Adding LCD display (none lvds) in Linux 5.4 fslc?

Christian Betz
 

Hi. I recently faced a similar problem on a custom imx6dl board, also with linux-fslc.

In my case i only have a single panel but it seems I had to define two panels to make the devicetree compiler happy (one of them is disabled though; and the DRM subsystem doesn't show multiple LVDS nodes). I am new to this though, so perhaps I am doing something wrong. I'm sure i could avoid duplicating the timings at least. (note: afaict the status=disabled on the LDB nodes have no effect; but the panel disable does).

after a day or two i settled on the following DTS definitions which are basically just mods to the stock imx6qdl-sabresd.dtsi

       panel1 {
                compatible = "panel-lvds";
                backlight = <&backlight_lvds>;

                data-mapping = "vesa-24";
                width-mm = <154>;
                height-mm = <87>;

                panel-timing {
                        clock-frequency = <67200000>;
                        hactive = <1024>;
                        vactive = <600>;
                        hfront-porch = <150>;
                        hsync-len = <76>;
                        hback-porch = <150>;
                        vfront-porch = <60>;
                        vsync-len = <80>;
                        vback-porch = <60>;
                        pixelclk-active = <0>;
                        hsync-active = <0>;
                        vsync-active = <0>;
                };

                 port {
                        panel1_in: endpoint {
                                remote-endpoint = <&lvds0_out>;
                        };
                };
        };

        panel2 {
                compatible = "panel-lvds";
                backlight = <&backlight_lvds>;
                status = "disabled";

                data-mapping = "vesa-24";
                width-mm = <154>;
                height-mm = <87>;

                panel-timing {
                        clock-frequency = <67200000>;
                        hactive = <1024>;
                        vactive = <600>;
                        hfront-porch = <150>;
                        hsync-len = <76>;
                        hback-porch = <150>;
                        vfront-porch = <60>;
                        vsync-len = <80>;
                        vback-porch = <60>;
                        pixelclk-active = <0>;
                        hsync-active = <0>;
                        vsync-active = <0>;
                };

                 port {
                        panel2_in: endpoint {
                                remote-endpoint = <&lvds1_out>;
                        };
                };
        };

...

&ldb {
        status = "okay";

        lvds-channel@0 {
                status = "okay";

                port@4 {
                        reg = <4>;

                        lvds0_out: endpoint {
                                remote-endpoint = <&panel1_in>;
                        };
                };
        };

        lvds-channel@1 {
                status = "disabled";

                port@4 {
                        reg = <4>;
                        status = "disabled";

                        lvds1_out: endpoint {
                                remote-endpoint = <&panel2_in>;
                        };
                };
        };
};



On Thu, Aug 13, 2020 at 8:28 AM Wouter Vanhauwaert <w.vanhauwaert@...> wrote:
But that's the mainline way of working, no? When using etnaviv/drm/imx-ipu... ?
Why would the old ldb-style still work, but the old lcd isn't?


--
"the new garbage collector will be an arena-based, quad-color incremental, generational, non-copying, high-speed, cache-optimized garbage collector" -- LuaJIT Roadmap


SPI for IMX6x with cyclic DMA

Andrea Tessadri <tessadriandrea@...>
 

I've just developed and tested cyclic DMA transfer for a SPI device on a IMX6UL with kernel 4.9.88
I wanted to have a single SPI transfer repeated continuously in order to feed a DAC for generation of a particular waveform for a medical device, without interruption and minimal jitter (this is why I though to make the change at low level, instead of making the protocol driver to pump several identical messages to SPI subsystem)
I am wondering if this feature could be interesting for other applications and if it is worth to submit a patch for drivers/spi/spi-imx.c
Thank you in advance

  Andrea


Re: Adding LCD display (none lvds) in Linux 5.4 fslc?

Wouter Vanhauwaert
 

But that's the mainline way of working, no? When using etnaviv/drm/imx-ipu... ?
Why would the old ldb-style still work, but the old lcd isn't?


Re: Adding LCD display (none lvds) in Linux 5.4 fslc?

Philippe Schenker
 

On Thu, 2020-08-13 at 03:28 -0700, Wouter Vanhauwaert wrote:
How do you correctly put a parallel lcd display in linux 5.4?
Uptill 4.9, there was a mxc_lcdif.c, but seems to be missing now?
In the devicetree, you used to add a node which had
compatible="fsl,lcd", addressing the pinctrl etc
But none of these seem to exist now?
I see a commit
https://github.com/Freescale/linux-fslc/commit/afcde9250592b07f165e2f66217726e26ac54e7c
This is supposed to add the lcdif, but hasn't or principle has
changed? Can someone explain?

Yes this has completely changed, look at NXP's MEK devicetrees to figure that out, at least I was once able to figure it out like that.
On Colibri-iMX8X I once had it running with something like this:

&dpu_disp1_lcdif {
remote-endpoint = <&lcd_display_in>;
status = "okay";
};


This points to:

panel {
compatible = "logictechno,lt161010-2nhc";
backlight = <&backlight>;
status = "okay";

port {
lcd_panel_in: endpoint {
remote-endpoint = <&lcd_display_out>;
};
};
};

display@disp1 {
compatible = "fsl,imx-lcdif-mux-display";
#address-cells = <1>;
#size-cells = <0>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_lcdif>;
clocks = <&clk IMX_SC_R_LCD_0 IMX_SC_PM_CLK_BYPASS>,
<&clk IMX_SC_R_LCD_0 IMX_SC_PM_CLK_MISC0>;
clock-names = "bypass_div", "pixel";
assigned-clocks = <&clk IMX_SC_R_LCD_0 IMX_SC_PM_CLK_MISC0>;
assigned-clock-parents = <&clk IMX_SC_R_LCD_0
IMX_SC_PM_CLK_BYPASS>;
fsl,lcdif-mux-regs = <&lcdif_mux_regs>;
fsl,interface-pix-fmt = "bgr666";
power-domains = <&pd IMX_SC_R_LCD_0>;
status = "okay";

port@0 {
reg = <0>;

lcd_display_in: endpoint {
remote-endpoint = <&dpu_disp1_lcdif>;
};
};

port@1 {
reg = <1>;

lcd_display_out: endpoint {
remote-endpoint = <&lcd_panel_in>;
};
};
};

Hope this helps,
Philippe


Adding LCD display (none lvds) in Linux 5.4 fslc?

Wouter Vanhauwaert
 

How do you correctly put a parallel lcd display in linux 5.4?
Uptill 4.9, there was a mxc_lcdif.c, but seems to be missing now?
In the devicetree, you used to add a node which had compatible="fsl,lcd", addressing the pinctrl etc
But none of these seem to exist now?
I see a commit https://github.com/Freescale/linux-fslc/commit/afcde9250592b07f165e2f66217726e26ac54e7c
This is supposed to add the lcdif, but hasn't or principle has changed? Can someone explain?


Re: New branch 5.4-2.1.x-imx for linux-fslc

Philippe Schenker
 

On Mon, 2020-08-10 at 17:24 -0300, Otavio Salvador wrote:
Hello all,

First, I'd like to thank you all for the great work.

Em seg., 10 de ago. de 2020 às 17:02, Andrey Zhizhikin
<andrey.z@...> escreveu:
...
Yeap, Kernel build off commit
1e10771673463a332a7e477fcba0b9488ec5362b
boots fine on i.MX8M Mini EVK. I haven't verified whether graphics
and
multimedia are OK, but in general at this state this merge is
absolutely fine!

I believe you can make a PR in
https://github.com/Freescale/linux-fslc
for Otavio to have a look at it.

With that said:
Tested-By: Andrey Zhizhikin <andrey.z@...>
I made the baseline branch based on codeaurora one. Here it goes:

https://github.com/Freescale/linux-fslc/tree/5.4-2.1.x-imx

So please, prepare a PR against it, so we can merge it there.
Haven't read all mails have created the PR now!

Also thanks from my side for the fast support Otavio!

Philippe


Re: New branch 5.4-2.1.x-imx for linux-fslc

Philippe Schenker
 

On Mon, 2020-08-10 at 22:02 +0200, Andrey Zhizhikin wrote:
On Mon, Aug 10, 2020 at 5:33 PM Philippe Schenker
<philippe.schenker@...> wrote:
On Mon, 2020-08-10 at 16:10 +0200, Andrey Zhizhikin wrote:
Hey Philippe,

On Mon, Aug 10, 2020 at 1:52 PM Philippe Schenker
<philippe.schenker@...> wrote:
On Mon, 2020-08-10 at 12:42 +0200, Andrey Zhizhikin wrote:
Hello Philippe,

On Mon, Aug 10, 2020 at 12:01 PM Philippe Schenker via
lists.yoctoproject.org
<philippe.schenker=toradex.com@...> wrote:
Hi,

Toradex is currently working on integrating the new NXP
release
'L5.4.24_2.1.0'. For this we created a new kernel branch
'5.4-
2.1.x-
imx'
based on NXP's kernel 'imx_5.4.24_2.1.0'.
We already merged patches from stable linux 5.4.47 into
'5.4-
2.1.x-
imx'.
This is great news! I was half the way of working on the same
update,
but now since you have the merge done - I can take your
version
instead.

@Otavio: I sincerely ask you if you could place the branch
'5.4-
2.1.x-
imx' that resides currently in my private github account:

https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fphilschenker%2Flinux-fslc%2Ftree%2F5.4-2.1.x-imx&;data=01%7C01%7Cphilippe.schenker%40toradex.com%7C1b2edaea486b43f0d2bf08d83d1a29be%7Cd99958660d9b42518315093f062abab4%7C0&amp;sdata=BZDTVKY%2BQJDwIgsBjAeRshdTw2i7Ksh0RjGtw92ZZHw%3D&amp;reserved=0
I'll grab this one to test on i.MX8M Mini EVK now and try it
out.
I've tried to build the branch from your repo with latest master
of
meta-freescale, and saw couple of issue with imx8mmevk machine:

1. imx-gpu-sdk recipe fails to build, as it requires the header
which
is most probably missing in the kernel:
make: *** No rule to make target
'/development/projects/master/build-output/work/cortexa53-crypto-
mx8mm-fsl-linux/imx-gpu-sdk/5.0.2-r0/recipe-
sysroot/usr/include/bits/sys_errlist.h',
needed by
'build/Yocto/obj/Release/source/FslBase/Bits/ByteArrayUtil.o'.
Stop.
I guess any user-space stuff need updating to versions that NXP
provides
with BSP 'L5.4.24_2.1.0'.

OE-core updated glibc which is the provider of 'sys_errlist.h' so
maybe
that is the reason for build failure?
Correct! My bad: I did a pull of OE-Core and then your Kernel branch,
which I should not have been doing in the first place. This issue is
not from Kernel, it is a pure glibc one. Thanks for pointing it out!

2. Kernel panics on the startup, there is something related to FEC
driver:
[ 0.994893] Unable to handle kernel paging request at virtual
address 0000000000023779
[ 1.002814] Mem abort info:
[ 1.005614] ESR = 0x96000004
[ 1.008668] EC = 0x25: DABT (current EL), IL = 32 bits
[ 1.013983] SET = 0, FnV = 0
[ 1.017040] EA = 0, S1PTW = 0
[ 1.020178] Data abort info:
[ 1.023062] ISV = 0, ISS = 0x00000004
[ 1.026901] CM = 0, WnR = 0
[ 1.029872] [0000000000023779] user address but active_mm is
swapper
[ 1.036262] Internal error: Oops: 96000004 [#1] PREEMPT SMP
[ 1.041833] Modules linked in:
[ 1.044891] CPU: 2 PID: 1 Comm: swapper/0 Not tainted
5.4.47+g1310c126dd1e #1
[ 1.052022] Hardware name: FSL i.MX8MM EVK board (DT)
[ 1.057073] pstate: 80000005 (Nzcv daif -PAN -UAO)
[ 1.061868] pc : fec_probe+0x280/0x1340
[ 1.065703] lr : fec_probe+0x80/0x1340
[ 1.069449] sp : ffff80001003baf0
[ 1.072761] x29: ffff80001003baf0 x28: 0000000000000000
[ 1.078072] x27: 0000000000000000 x26: ffff80001114d9b8
[ 1.083383] x25: 0000000000000000 x24: ffff000076090000
[ 1.088694] x23: ffff00007dc03bd8 x22: ffff000076404c10
[ 1.094005] x21: ffff000076404c00 x20: ffff0000762f8000
[ 1.099316] x19: ffff0000762f87c0 x18: 0000000000000020
[ 1.104626] x17: 0000000000000001 x16: 0000000000000019
[ 1.109937] x15: ffff000076090470 x14: 0000000000000000
[ 1.115248] x13: ffff000076090000 x12: 0000000000000000
[ 1.120559] x11: 0101010101010101 x10: 7f7f7f7f7f7f7f7f
[ 1.125870] x9 : 49fffeff06fefeff x8 : 7f7f7f7f7f7f7f7f
[ 1.131180] x7 : 01fefefefefefeff x6 : 8080808080808000
[ 1.136491] x5 : 0080808080808080 x4 : 0000000000000000
[ 1.141802] x3 : ffff80001114ea48 x2 : 0000000000000000
[ 1.147113] x1 : ffff000076090000 x0 : 0000000000023779
[ 1.152424] Call trace:
[ 1.154871] fec_probe+0x280/0x1340
[ 1.158361] platform_drv_probe+0x50/0xa0
[ 1.162371] really_probe+0xd8/0x410
[ 1.165946] driver_probe_device+0x54/0xe4
[ 1.170042] device_driver_attach+0xb4/0xc0
[ 1.174225] __driver_attach+0x80/0x114
[ 1.178060] bus_for_each_dev+0x6c/0xbc
[ 1.181895] driver_attach+0x20/0x30
[ 1.185469] bus_add_driver+0xfc/0x1e0
[ 1.189218] driver_register+0x74/0x120
[ 1.193052] __platform_driver_register+0x44/0x50
[ 1.197756] fec_driver_init+0x18/0x20
[ 1.201506] do_one_initcall+0x50/0x190
[ 1.205343] kernel_init_freeable+0x194/0x22c
[ 1.209700] kernel_init+0x10/0x100
[ 1.213188] ret_from_fork+0x10/0x18
[ 1.216765] Code: 2a1303e2 b940afe1 b900b3f3 17ffff75
(b9400000)
[ 1.222866] ---[ end trace 31a90d201ff67100 ]---
[ 1.227505] Kernel panic - not syncing: Attempted to kill init!
exitcode=0x0000000b
[ 1.235161] SMP: stopping secondary CPUs
[ 1.239085] Kernel Offset: disabled
[ 1.242572] CPU features: 0x0002,2000200c
[ 1.246579] Memory Limit: none
[ 1.249634] ---[ end Kernel panic - not syncing: Attempted to
kill
init! exitcode=0x0000000b ]---
Thanks for pointing this out, I could reproduce the issue and
checked.
There were still two commits missing. One revert that we believe is
not
applicable to downstream fec_main.c
This one also solved the issue. The other IPU commit was also
missing.
Now it works on our side. Can you confirm?
Yeap, Kernel build off commit 1e10771673463a332a7e477fcba0b9488ec5362b
boots fine on i.MX8M Mini EVK. I haven't verified whether graphics and
multimedia are OK, but in general at this state this merge is
absolutely fine!

I believe you can make a PR in https://github.com/Freescale/linux-fslc
for Otavio to have a look at it.
Thanks Andrey for testing!
I guess Otavio needs to pull it from my branch, I'm not able to create a
new branch as PR.

Philippe

With that said:
Tested-By: Andrey Zhizhikin <andrey.z@...>

Philippe

Have you ported the patch [1] from upstream? Without it - the
latest
master build would fail (it is needed for binutils-2.35).
Hi Andrey,

We were building binutils-2.34 so didn't notice this issue. I've
cherry-
picked the patch you mentioned.
That's great, I've synced up the tree to your latest commit and
the
perf build build went through.

Philippe
into the repository

https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FFreescale%2Flinux-fslc&;data=01%7C01%7Cphilippe.schenker%40toradex.com%7C1b2edaea486b43f0d2bf08d83d1a29be%7Cd99958660d9b42518315093f062abab4%7C0&amp;sdata=qkHhXyQfUuvj1C9u3FbPaqrmx6TsszVHpiRi9azUyR0%3D&amp;reserved=0

Thanks and best regards,
Philippe
[1]:
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.kernel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Ftorvalds%2Flinux.git%2Fcommit%2F%3Fid%3D39efdd94e314336f4acbac4c07e0f37bdc3bef71&;data=01%7C01%7Cphilippe.schenker%40toradex.com%7C1b2edaea486b43f0d2bf08d83d1a29be%7Cd99958660d9b42518315093f062abab4%7C0&amp;sdata=gDSV0ochz6GpX1DQ6EU%2Bn6BtpvDVBNbgPkWGWEqNegY%3D&amp;reserved=0

461 - 480 of 24848