| Message ID | CAHCN7xJoL40x1_tMp2es5VxpOZNPkz64SsGsBRuOm5GtbNU5Yw@mail.gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Hi, Adding Nishanth to Cc. * Adam Ford <aford173@gmail.com> [170119 13:02]: > On Thu, Dec 15, 2016 at 10:16 AM, Tony Lindgren <tony@atomide.com> wrote: > > * Adam Ford <aford173@gmail.com> [161215 07:53]: > >> On Thu, Dec 15, 2016 at 9:40 AM, Tony Lindgren <tony@atomide.com> wrote: > >> > * Adam Ford <aford173@gmail.com> [161215 07:27]: > >> >> On Thu, Dec 15, 2016 at 2:44 AM, Daniel Gomez <dgomez@iseebcn.com> wrote: > >> >> > Thanks for your answer Tony, > >> >> > > >> >> > I would like to fix it but I don't know how to start. Any idea or > >> >> > suggestion please? > >> >> > I have patched kernel 4.3 with this patch with the same result: > >> >> > http://lists.infradead.org/pipermail/linux-arm-kernel/2014-October/294018.html > >> >> > > >> >> > Furthermore, which kernel version is recommended to be use? > >> >> > > >> >> > Daniel > >> >> > > >> >> > 2016-12-14 20:52 GMT+01:00 Tony Lindgren <tony@atomide.com>: > >> >> >> > >> >> >> * Daniel Gomez <dgomez@iseebcn.com> [161214 08:14]: > >> >> >> > HI, > >> >> >> > > >> >> >> > I would like to know about the status for supporting 1GHz of DM3730 > >> >> >> > processor (omap3) in the kernel mainline. > > Daniel, > > I was able to get my DM3730 working at 1GHz with the following patch: > > diff --git a/arch/arm/boot/dts/omap36xx.dtsi b/arch/arm/boot/dts/omap36xx.dtsi > index 718fa88..2c97783 100644 > --- a/arch/arm/boot/dts/omap36xx.dtsi > +++ b/arch/arm/boot/dts/omap36xx.dtsi > @@ -25,6 +25,7 @@ > 300000 1012500 > 600000 1200000 > 800000 1325000 > + 1000000 1375000 > >; > clock-latency = <300000>; /* From legacy driver */ > }; > > > I looked at the device tree for omap36 and abb_mpu_iva: > regulator-abb-mpu shows 1375000 with ABB set to 1 > > What I am not sure is how to confirm whether or not there is more to > do. I confirmed that vdd1 (which powers the CPU on my board) is > running at 1.375 volts. I think you still need the smartreflex operational to exit the 1GiHz mode when needed. > >> >> >> Yeah unfortunately the voltdomain support is still missing. Somebody > >> >> >> just needs to fix it.. > >> >> >> > Tony - Can you elaborate on what voltdomain support is? I'm willing > to look into it. Nishanth, care to paste your notes on what's missing again? > >> >> I modified the om36xx.dtsi file to list 1000000 and 1375000 uV, but I > >> >> couldn't figure out how to autodetect whether or not the > >> >> DM3730/OMAP3630 was 800MHz or 1000. > > I also pushed a patch to the U-Boot which updates the proper reading > and display of 800/1GHz versions of the various DM37/AM37 processors, > but it hasn't been reviewed or approved yet. OK great. > I don't know what Tony's opinion is, but if we don't have a good way > (yet) to limit the 800 MHz version to 800MHz with the 1000 entry in > the device tree, we might be able to use U-Boot to determine which > speed is correct and load/modify the device tree before the kernel > boots. Yeah that's possible. Maybe the recent cpufreq patches for am335x can be used to read the hardware information? Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Jan 19, 2017 at 3:44 PM, Tony Lindgren <tony@atomide.com> wrote: > Nishanth, care to paste your notes on what's missing again? > http://marc.info/?l=linux-kernel&m=137185002523884&w=2 --- Regards, Nishanth Menon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Jan 19, 2017 at 3:44 PM, Tony Lindgren <tony@atomide.com> wrote: > Hi, > > Adding Nishanth to Cc. > > * Adam Ford <aford173@gmail.com> [170119 13:02]: >> On Thu, Dec 15, 2016 at 10:16 AM, Tony Lindgren <tony@atomide.com> wrote: >> > * Adam Ford <aford173@gmail.com> [161215 07:53]: >> >> On Thu, Dec 15, 2016 at 9:40 AM, Tony Lindgren <tony@atomide.com> wrote: >> >> > * Adam Ford <aford173@gmail.com> [161215 07:27]: >> >> >> On Thu, Dec 15, 2016 at 2:44 AM, Daniel Gomez <dgomez@iseebcn.com> wrote: >> >> >> > Thanks for your answer Tony, >> >> >> > >> >> >> > I would like to fix it but I don't know how to start. Any idea or >> >> >> > suggestion please? >> >> >> > I have patched kernel 4.3 with this patch with the same result: >> >> >> > http://lists.infradead.org/pipermail/linux-arm-kernel/2014-October/294018.html >> >> >> > >> >> >> > Furthermore, which kernel version is recommended to be use? >> >> >> > >> >> >> > Daniel >> >> >> > >> >> >> > 2016-12-14 20:52 GMT+01:00 Tony Lindgren <tony@atomide.com>: >> >> >> >> >> >> >> >> * Daniel Gomez <dgomez@iseebcn.com> [161214 08:14]: >> >> >> >> > HI, >> >> >> >> > >> >> >> >> > I would like to know about the status for supporting 1GHz of DM3730 >> >> >> >> > processor (omap3) in the kernel mainline. >> >> Daniel, >> >> I was able to get my DM3730 working at 1GHz with the following patch: >> >> diff --git a/arch/arm/boot/dts/omap36xx.dtsi b/arch/arm/boot/dts/omap36xx.dtsi >> index 718fa88..2c97783 100644 >> --- a/arch/arm/boot/dts/omap36xx.dtsi >> +++ b/arch/arm/boot/dts/omap36xx.dtsi >> @@ -25,6 +25,7 @@ >> 300000 1012500 >> 600000 1200000 >> 800000 1325000 >> + 1000000 1375000 >> >; >> clock-latency = <300000>; /* From legacy driver */ >> }; >> >> >> I looked at the device tree for omap36 and abb_mpu_iva: >> regulator-abb-mpu shows 1375000 with ABB set to 1 >> >> What I am not sure is how to confirm whether or not there is more to >> do. I confirmed that vdd1 (which powers the CPU on my board) is >> running at 1.375 volts. > > I think you still need the smartreflex operational to exit the 1GiHz mode > when needed. > >> >> >> >> Yeah unfortunately the voltdomain support is still missing. Somebody >> >> >> >> just needs to fix it.. >> >> >> >> >> Tony - Can you elaborate on what voltdomain support is? I'm willing >> to look into it. > > Nishanth, care to paste your notes on what's missing again? > >> >> >> I modified the om36xx.dtsi file to list 1000000 and 1375000 uV, but I >> >> >> couldn't figure out how to autodetect whether or not the >> >> >> DM3730/OMAP3630 was 800MHz or 1000. >> >> I also pushed a patch to the U-Boot which updates the proper reading >> and display of 800/1GHz versions of the various DM37/AM37 processors, >> but it hasn't been reviewed or approved yet. > > OK great. > >> I don't know what Tony's opinion is, but if we don't have a good way >> (yet) to limit the 800 MHz version to 800MHz with the 1000 entry in >> the device tree, we might be able to use U-Boot to determine which >> speed is correct and load/modify the device tree before the kernel >> boots. > > Yeah that's possible. Maybe the recent cpufreq patches for am335x > can be used to read the hardware information? > Tony - Can you point me to those patches? I know we're looking for feedback from Nishanth, but if you can point me to the am335x patches, I'd like to see what was being done. I managed to find the register to read the max speed in the DM3730 TRM (it's not listed in the 3630 version). On a DM3730, If we read address 0x4800244C and bit 9 is set, it is a 1 GHz processor, otherwise it's 800 MHz. I don't know if the 3630 is the same, but maybe someone from TI can confirm or someone in the community with a 3630 board. In my head I was thinking that when calculating the frequency ceiling, we'd compare it to a value based on bit 9 if the CPU family was a 36xx/37xx. If something was already done, I can copy that concept instead. adam > Regards, > > Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
* Adam Ford <aford173@gmail.com> [170119 14:36]: > On Thu, Jan 19, 2017 at 3:44 PM, Tony Lindgren <tony@atomide.com> wrote: > > > > Yeah that's possible. Maybe the recent cpufreq patches for am335x > > can be used to read the hardware information? > > > Tony - Can you point me to those patches? I know we're looking for > feedback from Nishanth, but if you can point me to the am335x patches, > I'd like to see what was being done. It's the "[PATCH v4 0/4] cpufreq: Introduce TI CPUFreq/OPP Driver" thread. > I managed to find the register to read the max speed in the DM3730 TRM > (it's not listed in the 3630 version). On a DM3730, If we read address > 0x4800244C and bit 9 is set, it is a 1 GHz processor, otherwise it's > 800 MHz. I don't know if the 3630 is the same, but maybe someone from > TI can confirm or someone in the community with a 3630 board. > > In my head I was thinking that when calculating the frequency ceiling, > we'd compare it to a value based on bit 9 if the CPU family was a > 36xx/37xx. If something was already done, I can copy that concept > instead. Well I think that cpufreq driver thread above is doing similar things. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> I managed to find the register to read the max speed in the DM3730 TRM > (it's not listed in the 3630 version). On a DM3730, If we read address > 0x4800244C and bit 9 is set, it is a 1 GHz processor, otherwise it's > 800 MHz. I don't know if the 3630 is the same, but maybe someone from > TI can confirm or someone in the community with a 3630 board. > > In my head I was thinking that when calculating the frequency ceiling, > we'd compare it to a value based on bit 9 if the CPU family was a > 36xx/37xx. If something was already done, I can copy that concept > instead. I was looking at this in some other context recently for 3630. CONTROL_FEATURE_OMAP_STATUS is at 0x4800244C. Bit9 is defined as the SPEED_BINNED bit. IIRC, its purpose was as you intuit. I would be surprised if an old patch does not exist in mail group archives. For 1GHZ, along with probing VDD, you should probe U4:cap_vdd_bb_mpu_iva on U4 to see if FBB is engaged, the cap should read 1V, if its .4 it is in bypass, or worse in RBB. FBB is needed to ensure 1GHz is stable at DM voltage across devices. Regards, Richard W.
diff --git a/arch/arm/boot/dts/omap36xx.dtsi b/arch/arm/boot/dts/omap36xx.dtsi index 718fa88..2c97783 100644 --- a/arch/arm/boot/dts/omap36xx.dtsi +++ b/arch/arm/boot/dts/omap36xx.dtsi @@ -25,6 +25,7 @@ 300000 1012500 600000 1200000 800000 1325000 + 1000000 1375000 >; clock-latency = <300000>; /* From legacy driver */ };