[lkml]   [2021]   [Feb]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC 00/19] Rework support for i.MX8MQ interconnect with devfreq
On 19.02.21 16:59, Abel Vesa wrote:
> This has been on my queue for quite some time now. It is more of a
> proof-of-concept.
> This rework is done with the compatibility of future i.MX platforms in
> mind. For example, the i.MX8MP platform has multiple NoCs. This
> patchsets prepares the imx interconnect and imx devfreq for that too.
> As of now, none of the drivers involved are being used and there is no
> icc consumer on any off the i.MX platforms.
> Basically, the steps taken here are the following:
> 1. Make the dram_apb clock "reparantable" from kernel.
> This is needed in order to keep track of the actual parent of the
> dram_apb clock in the kernel clock hierarchy. Note that the actual
> switch is done EL3 (TF-A).
> 2. Rework the imx-bus so the actual link between the icc and the
> NoCs or the pl301s is not tightly coupled. This allows us to have
> as many NoCs as necessary but also allows as to use the same driver
> for the pl301s. The pl301s have their own clocks too, so we need to
> reduce their rates too.
> 3. Rework the imx8m-ddrc driver. Remove the support for dts defined
> OPPs. The EL3 provides those. So instead of havingi to keep the OPP table in
> both EL3 and kernel in sync, we rely on what the EL3 gives us.
> Also, when the platform suspends, the bus needs to be running at highest
> rate, otherwise there is a chance it might not resume anymore.
> By adding the late system sleep PM ops we can handle that easily.
> 4. Rework the imx interconnect driver to use the fsl,icc-id instead
> of the robust imx_icc_node_adj_desc for linking with the target node.
> By adding the fsl,icc-id property to all the NoC and pl301 dts nodes,
> we can link each icc node to their corresponding NoC, pl301 or dram.
> Basically, when the imx interconnect platform specific driver probes,
> it will take each node defined for that platform and look-up the
> corresponding dts node based on the id and add that as the qos device.
> 5. Added the fec and usdhc as icc consumers. This is just as an example.
> All the other consumers can be added later. Basically, each consumer
> will add a path to their device node and in the driver will have to
> handle that icc path accordingly.

thanks for working on this Abel,

It looks like the icc path requests don't work for me:

when applying this onto v5.11 (without any other workaround in that
area, but some out-of-tree icc-requests like in mxsfb) my rootfs isn't
being mounted anymore. Since you add icc requests to the usdhc driver,
there could be something wrong.

So I revert 19/19 ("mmc: sdhci-esdhc-imx: Add interconnect support") and
then my imx8mq (Librem 5) rootfs system boots, but all frequencies stay
at the minimum (despite the icc request like this:
so I can't use the display).

What could be missing? As I said I'm trying on top of v5.11, (at least I
have the NOC node described:
and (with the revert from
devfreq works without your patchset ) Is there anything I'm missing that
is not yet merged in v5.11?

Can I test anything else that would help?

/sys/class/devfreq# cat */cur_freq

the available freqs look ok (opp table removed from device dts, but you
don't read that anymore anyway):

cat */available_frequencies
133333333 400000000 800000000
25000000 100000000 800000000
25000000 133333333 333333333
25000000 266666666
25000000 800000000
25000000 800000000
25000000 333333333
25000000 500000000
25000000 500000000
25000000 128000000 500000000
25000000 133333333

where ls is:













 \ /
  Last update: 2021-02-22 17:09    [W:0.127 / U:3.100 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site