[PATCH v4 10/18] soc: imx: add i.MX8M blk-ctrl driver

[Lucas Stach]

Hi Benjamin,

Am Montag, dem 04.10.2021 um 16:27 +0200 schrieb Benjamin Gaignard:
> Le 02/10/2021 à 03:07, Lucas Stach a écrit :
> > Hi Benjamin,
> > 
> > Am Dienstag, dem 14.09.2021 um 17:46 +0200 schrieb Benjamin Gaignard:
> > > Le 10/09/2021 à 22:26, Lucas Stach a écrit :
> > > > This adds a driver for the blk-ctrl blocks found in the i.MX8M* line of
> > > > SoCs. The blk-ctrl is a top-level peripheral located in the various *MIX
> > > > power domains and interacts with the GPC power controller to provide the
> > > > peripherals in the power domain access to the NoC and ensures that those
> > > > peripherals are properly reset when their respective power domain is
> > > > brought back to life.
> > > > 
> > > > Software needs to do different things to make the bus handshake happen
> > > > after the GPC *MIX domain is powered up and before it is powered down.
> > > > As the requirements are quite different between the various blk-ctrls
> > > > there is a callback function provided to hook in the proper sequence.
> > > > 
> > > > The peripheral domains are quite uniform, they handle the soft clock
> > > > enables and resets in the blk-ctrl address space and sequencing with the
> > > > upstream GPC power domains.
> > > Hi Lucas,
> > > 
> > > I have tried to use your patches for IMX8MQ but it seems that the hardware
> > > have different architecture.
> > > On IMX8MQ there is only one VPU domain for G1 and G2 and that doesn't match
> > > with your implementation where it is needed to have "bus" and devices power domain.
> > >   From what I experiment in current IMX8MQ implementation of blk-ctrl (inside VPU driver)
> > > enabling the 3 clocks (bus, G1, G2) is needed to reset the VPUs.
> > > 
> > > Do you think you can update your design to take care of these hardware variations ?
> > The clocking/reset of the blk-ctrl and ADB in the i.MX8MQ VPU power
> > domain is really a bit strange, as the ADB reset is tied to the VPU
> > resets and the clk-ctrl seem to require all 3 VPU clocks, instead of
> > only the bus clock as in newer designs. However I was able to make it
> > work with the existing blk-ctrl driver design.
> > 
> > My current WIP patches (only tested with the G1 core so far) on top of
> > the v5 of the series I just sent out can be found here:
> > https://git.pengutronix.de/cgit/lst/linux/log/?h=imx8mq-vpu-blk-ctrl
> > 
> > Hope this helps.
> 
> Hi Lucas,
> 
> I have been able to test your branch on my iMX8MQ.
> I confirm that G1 is working fine, I able to decode H264 files.
> 
> I wasn't able to make G2 works, I think it is coming from the reset sequence
> done before each frame decoding in G2 driver.
> I have change imx8mq_runtime_resume() and  imx8m_vpu_reset()
> to call pm_runtime_put() and pm_runtime_get() to perform a reset like.

I think you need to use the _sync variants of those functions to make
sure the domain is going through the reset state. However that seems
like a pretty heavy-weight thing to do if the decoder really requires a
reset before each frame. Excuse my ignorance about the G2 block, but
this sounds like a quite odd requirement. Is this to work around some
hardware erratum?

If we really need to reset the G2 before each frame, I think it would
be best to also expose a reset controller from the blk-ctrl driver, to
allow the G2 driver to do a light-weight reset, instead of doing this
runtime PM transition.

Regards,
Lucas

> Without that G2 hangs when decoding the first frame.
> 
> One G1 it seems that doing a reset before each frame decoding is not needed.
> 
> On DT I had to assignee G1 and G2 on the both nodes to avoid a warning at probe time.
> assigned-clocks = <&clk IMX8MQ_CLK_VPU_G1>,
> 					  <&clk IMX8MQ_CLK_VPU_G2>,
> 					  <&clk IMX8MQ_VPU_PLL_BYPASS>;
> 			assigned-clock-parents = <&clk IMX8MQ_VPU_PLL_OUT>,
> 						 <&clk IMX8MQ_VPU_PLL_OUT>,
> 						 <&clk IMX8MQ_VPU_PLL>;
> 			assigned-clock-rates = <600000000>, <300000000>, <0>;
> 
> I also set G2 clock at 300Mhz as specify in the TRM.
> Even with all this G2 doesn't fire interrupts.
> 
> Benjamin
> 
> > 
> > Regards,
> > Lucas
> >