linux-kernel - Re: [RFC 0/3] clk: imx: Implement blk-ctl driver for i.MX8MN

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Sun, 25 Oct 2020 11:05:32 -0500
From:   Adam Ford <aford173@...il.com>
To:     Marek Vasut <marex@...x.de>
Cc:     Abel Vesa <abel.vesa@....com>,
        linux-clk <linux-clk@...r.kernel.org>,
        Michael Turquette <mturquette@...libre.com>,
        Stephen Boyd <sboyd@...nel.org>,
        Shawn Guo <shawnguo@...nel.org>,
        Sascha Hauer <s.hauer@...gutronix.de>,
        Pengutronix Kernel Team <kernel@...gutronix.de>,
        Fabio Estevam <festevam@...il.com>,
        NXP Linux Team <linux-imx@....com>,
        Rob Herring <robh+dt@...nel.org>,
        Philipp Zabel <p.zabel@...gutronix.de>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        arm-soc <linux-arm-kernel@...ts.infradead.org>,
        devicetree <devicetree@...r.kernel.org>
Subject: Re: [RFC 0/3] clk: imx: Implement blk-ctl driver for i.MX8MN

On Sun, Oct 25, 2020 at 7:19 AM Marek Vasut <marex@...x.de> wrote:
>
> On 10/25/20 1:05 PM, Abel Vesa wrote:
>
> [...]
>
> >> Together, both the GPC and the clk-blk driver should be able to pull
> >> the multimedia block out of reset.  Currently, the GPC can handle the
> >> USB OTG and the GPU, but the LCDIF and MIPI DSI appear to be gated by
> >> the clock block
> >>
> >> My original patch RFC didn't include the imx8mn node, because it
> >> hangs, but the node I added looks like:
> >>
> >> media_blk_ctl: clock-controller@...28000 {
> >>      compatible = "fsl,imx8mn-media-blk-ctl", "syscon";
> >>      reg = <0x32e28000 0x1000>;
> >>      #clock-cells = <1>;
> >>      #reset-cells = <1>;
> >> };
> >>
> >> I was hoping you might have some feedback on the 8mn clk-blk driver
> >> since you did the 8mp clk-blk drive and they appear to be very
> >> similar.
> >>
> >
> > I'll do you one better still. I'll apply the patch in my tree and give it
> > a test tomorrow morning.

I do have some more updates on how to get the system to not hang, and
to enumerate more clocks.
Looking at Marek's work on enabling clocks in the 8MM, he added a
power-domain in dispmix_blk_ctl pointing to the dispmix in the GPC.
By forcing the GPC driver to write 0x1fff  to 32e28004, 0x7f to
32e28000 and 0x30000 to 32e28008, the i.MX8MM can bring the display
clocks out of reset.

Unfortunately, the i.MX8MN needs to have 0x100 written to both
32e28000 and 32e28004, and the values written for the 8MM are not
compatible.
By forcing the GPC to write those values, I can get  lcdif_pixel_clk
and the mipi_dsi_clkref  appearing on the Nano.

 video_pll1_ref_sel                0        0        0    24000000
     0     0  50000
       video_pll1                     0        0        0   594000000
        0     0  50000
          video_pll1_bypass           0        0        0   594000000
        0     0  50000
             video_pll1_out           0        0        0   594000000
        0     0  50000
                disp_pixel            0        0        0   594000000
        0     0  50000
                   lcdif_pixel_clk       0        0        0
594000000          0     0  50000
                   disp_pixel_clk       0        0        0
594000000          0     0  50000
                dsi_phy_ref           0        0        0    27000000
        0     0  50000
                   mipi_dsi_clkref       0        0        0
27000000          0     0  50000

I am not 100% certain the clock parents  in the clk block driver for
the 8MN are correct, and I am not seeing the mipi_dsi_pclk

Once the dust settles on the GPC decision for Mini and Nano, I think
we'll need a more generic way to pass the bits we need to set in clock
block to the GPC.

adam
>
> You can also apply the one for 8MM:
> https://lore.kernel.org/linux-arm-kernel/20201003224555.163780-5-marex@denx.de/