Am Montag, den 26.10.2020, 16:55 +0200 schrieb Abel Vesa:
> On 20-10-25 11:05:32, Adam Ford wrote:
> > On Sun, Oct 25, 2020 at 7:19 AM Marek Vasut <marex@xxxxxxx> 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@32e28000 {
> > > > > 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.
> >
>
> Yeah, that makes sense. Basically, it was trying to disable unused clocks
> (see clk_disable_unused) but in order to disable the clocks from the
> media BLK_CTL (which I think should be renamed in display BLK_CTL) the
> PD need to be on. Since you initially didn't give it any PD, it was trying
> to blindly write/read the gate bit and therefore freeze.
>
> > 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.
>
> I'm trying to make a branch with all the patches for all i.MX8M so I
> can keep track of it all. On this branch I've also applied the
> following patchset from Lucas Stach:
> https://www.spinics.net/lists/arm-kernel/msg843007.html
> but I'm getting the folowing errors:
>
> [ 16.690885] imx-pgc imx-pgc-domain.3: failed to power up ADB400
> [ 16.716839] imx-pgc imx-pgc-domain.3: failed to power up ADB400
> [ 16.730500] imx-pgc imx-pgc-domain.3: failed to power up ADB400
>
> Lucas, any thoughts?
>
> Maybe it's something related to 8MN.
The ADB is apparently clocked by one of the BLK_CTL clocks, so the ADB
handshake ack will only work when the BLK_CTL clocks are enabled. So I
guess the GPC driver should enable those clocks and assert the resets
at the right time in the power-up sequencing. Unfortunately this means
we can't properly put the BLK_CTL driver in the power-domain without
having a cyclic dependency in the DT. I'm still thinking about how to
solve this properly.
Regards,
Lucas
