On Mon, Sep 2, 2019 at 5:55 AM H. Nikolaus Schaller <hns@xxxxxxxxxxxxx> wrote: > > Hi, > > > Am 17.08.2019 um 11:24 schrieb H. Nikolaus Schaller <hns@xxxxxxxxxxxxx>: > > > > > >> 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. > > Ok, I found some time and it is not that difficult, besides several quirks :) > Thank you for doing this. > 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 looked into this once, but I struggled with understanding how the driver worked. I am excited to test the 1GHz operation when its ready. > > 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"; Based on my screening of the device trees, it seems like 34xx is appropriate for most OMAP3's which are not am3517 and not omap36xx. The AM3517 includes omap3.dtsi, but not all 34xx devices. I think if that was the case, they would have merged them. The omap36xx have some different register addresses from 34xx which I think why both 34xx and 36xx (and am3517) all include what they can from the omap3.dtsi stuff. Even the clocks vary between 34xx, AM35 and omap36. > > But all ti,omap36xx also have ti,omap3. > > So there is "omap3430", "omap34xx" or no definition (or even "ti,am3517"). I don't believe AM3517 have different OPPs. I looked through the datasheet and didn't find any. At one time I tried to run the AM3517 at various frequencies based on the 3430 frequency points, but the operating voltage appears to be fixed. To me, it seems like it would make sense to standardize on the naming convention. (ie, make omap34xx boards and omap35xx boards, explictly state omap34xx, excluding the am35xx unless we want add extra stuff for it) > This makes matching the ti-cpufreq driver for either omap34xx or omap36xx difficult... If we add omap34xx to all non-36xx boards and non-am35xx boads, the the check for the compatible flag in the ti-cpufreq driver be based on looking for "ti,34xx" and "ti,36xx" . > > Finally, I am not exactly sure about if omap3430 and omap3530 are really the > same for the eFuses and silicon revision registers and values... >From what I can tell they are, but hopefully someone from TI can confirm. > > BR, > Nikolaus >
