Messages in this thread | | | From | Adam Ford <> | Date | Thu, 31 Mar 2022 06:32:13 -0500 | Subject | Re: [PATCH] soc: imx: gpcv2: keep i.MX8MM VPU-H1 bus clock active |
| |
On Thu, Mar 31, 2022 at 4:28 AM Lucas Stach <l.stach@pengutronix.de> wrote: > > Hi Adam, hi Shawn, > > Am Samstag, dem 20.11.2021 um 13:39 -0600 schrieb Adam Ford: > > Enable the vpu-h1 clock when the domain is active because reading > > or writing to the VPU-H1 IP block cause the system to hang. > > > > Fixes: 656ade7aa42a ("soc: imx: gpcv2: keep i.MX8M* bus clocks enabled") > > Signed-off-by: Adam Ford <aford173@gmail.com> > > > > diff --git a/drivers/soc/imx/gpcv2.c b/drivers/soc/imx/gpcv2.c > > index b8d52d8d29db..7b6dfa33dcb9 100644 > > --- a/drivers/soc/imx/gpcv2.c > > +++ b/drivers/soc/imx/gpcv2.c > > @@ -734,6 +734,7 @@ static const struct imx_pgc_domain imx8mm_pgc_domains[] = { > > .map = IMX8MM_VPUH1_A53_DOMAIN, > > }, > > .pgc = BIT(IMX8MM_PGC_VPUH1), > > + .keep_clocks = true, > > }, > > > I missed this patch and just stumbled across it when looking at the git > history. I don't think this patch is correct. The H1 GPC domain does > not even have clocks assigned in the DT, so there is nothing to keep > active. Also H1 is not a MIX domain, so it should not keep any bus > clocks active, that is the job of the VPUMIX domain. > > While this patch is a no-op, as far as I can see, it still seems wrong > and I think it should be reverted.
At the time I sent this, I was working with some people in the media group to split the G1 and G2 up in the imx8mq and add G1 and G2 support in the imx8mm. I had inquired about the feasibility of using the H1 encoder on the imx8mm, but I needed to read some registers from the IP block to see which features were fused out. I tried several different options to get the H1 to not hang when reading registers, and that was the only solution I found that worked. I thought it odd as well since the G1 and G2 decoders didn't appear to need this. However, during the course of my investigation, I learned that the JPEG encoder was fused out of the imx8mm, and there wasn't a plan to add VP8 or H.264 encodering any time soon. Since it is, as you put it, a no-op, I have no objections to reverting it.
adam > > Regards, > Lucas >
| |