[Letux-kernel] [RFC PATCH 0/3] Enable 1GHz support on omap36xx

H. Nikolaus Schaller hns at goldelico.com
Mon Sep 2 12:55:10 CEST 2019


Hi,

> Am 17.08.2019 um 11:24 schrieb H. Nikolaus Schaller <hns at goldelico.com>:
> 
> 
>> Am 16.08.2019 um 14:25 schrieb Adam Ford <aford173 at gmail.com>:
>>> 
>>> I tried to get such code into drivers/cpufreq/ti-cpufreq.c but
>>> gave up when I found that this is not used for the omap36xx.
>>> 
>>> 
>>> To me it looks as if this opp-v2-ti table is what we need for omap36xx.dtsi
>>> as well to manage the speed-binned bit of DM3730. To me it looks sufficiently
>>> similar to an "eFuse" bit. But I didn't look into the details of the
>>> opp-v2-ti format, because all that is a second step after getting 1GHz stable
>>> on 1GHz capable chips.
>> 
>> I looked into this once, but I couldn't figure out how to interpret
>> the "opp-supported-hw" entries.
> 
> Translating the OPP values isn't difficult and I have started a sketch for it.
> "opp-supported-hw" is indeed difficult to understand. I just have a working
> hypothesis that it seems to be possible to have major chip variants and minor
> variants. Major variants get their own 32 bit value in each record. Minor variants
> are described by bit positions.
> 
> Since we only have to care about one major variant of omap36xx (unless we want
> a single OPP value list for omap34xx and omap36xx) and there are only 800MHz
> and 1GHz rated chips a single entry array with only one or two bits in each value
> should suffice to handle it.
> 
> What I am missing in the big picture is how to specify the register address to
> be inspected and how the bits in the eFuse / "speed-binned" register match
> the bits in the "opp-supported-hw" entries. Maybe it is done by driver code
> or needs a separate DT entry somewhere.
> 
> For the records, we have to read the Control Device Status Register 15:0
> (Address 0x4800 244C) BIT(9).
> 
> I'll look into that as soon as I find time for further study.

Ok, I found some time and it is not that difficult, besides several quirks :)

We have to define opp-v2 tables and add some config and code to the ti-cpufreq
driver which reads out the silicon revision and eFuse registers. And we have
to blacklist the chips in the cpufreq-dt-platdev driver.

Reading the eFuse registers in the ti-cpufreq code is tricky since they are not part
of the syscon register block like on am33xx or dra7. I have added some ioremap()
and readl(). It works, but it can be improved in future work if someone has
a better idea. For the moment I would consider it as a simple and good enough
solution.

I have also tried to add the same approach for the 600/720MHz speed grades of
the omap3430 but have not found a BeagleBoard C4 which should have the 720MHz
grade. The C2 I have tested with has 600MHz only.

Note that omap3430 and omap3630 have different OPPs so we can not share
tables.

Another complication is that the DTS have no uniform compatible= records for
the 34xx. I have found e.g.:

omap3-beagle.dts:	compatible = "ti,omap3-beagle", "ti,omap3";
omap3-cm-t3530.dts:	compatible = "compulab,omap3-cm-t3530", "ti,omap34xx", "ti,omap3";
omap3-evm.dts:		compatible = "ti,omap3-evm", "ti,omap3430", "ti,omap3";
omap3-sbc-t3517.dts:	compatible = "compulab,omap3-sbc-t3517", "compulab,omap3-cm-t3517", "ti,am3517", "ti,omap3";

But all ti,omap36xx also have ti,omap3.

So there is "omap3430", "omap34xx" or no definition (or even "ti,am3517").
This makes matching the ti-cpufreq driver for either omap34xx or omap36xx difficult...

Finally, I am not exactly sure about if omap3430 and omap3530 are really the
same for the eFuses and silicon revision registers and values...

BR,
Nikolaus



More information about the Letux-kernel mailing list