> Am 16.08.2019 um 14:25 schrieb Adam Ford <aford173@xxxxxxxxx>: >> >> 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
