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

H. Nikolaus Schaller hns at goldelico.com
Sat Aug 17 11:24:59 CEST 2019


> 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.

>  If you keep me in the, loop, I'm more
> than happen to help where I can and/or test when possible.

Sure!

BR,
Nikolaus



More information about the Letux-kernel mailing list