Re: Bug#793185: [linux-sunxi] Re: forwarding a bug: cpufreq missing in debian stable on a cuibeboard
On Sat, 2015-08-01 at 10:51 +0100, Ian Campbell wrote: http://git.kernel.org/linus/07949bf9c63c9a80027fe8452d5fe8b9ba9b3c23 I'll see about backporting that to the 4.1 kernel in Debian until we move to 4.2. It turns out that this patch while necessary is not sufficient and I also needed the following for full cpufreq autoloading on Cubietruck with Debian's modular kernel config. Cheers, Ian. 8--- From 38880ed1b26e8778268c1da41ab2bb52c6797947 Mon Sep 17 00:00:00 2001 From: Ian Campbell i...@hellion.org.uk Date: Sat, 1 Aug 2015 13:44:06 +0100 Subject: [PATCH] regulator: axp20x: Add module alias This allows the module to be autoloaded. Together with 07949bf9c63c (cpufreq: dt: allow driver to boot automatically) this is sufficient to allow a modular kernel (such as Debian's) to enable cpufreq on a Cubietruck. Signed-off-by: Ian Campbell i...@hellion.org.uk Cc: Liam Girdwood lgirdw...@gmail.com Cc: Mark Brown broo...@kernel.org Cc: Signed-off-by: Chen-Yu Tsai w...@csie.org Cc: Maxime Ripard maxime.rip...@free-electrons.com --- drivers/regulator/axp20x-regulator.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/regulator/axp20x-regulator.c b/drivers/regulator/axp20x-regulator.c index e4331f5..2c82131 100644 --- a/drivers/regulator/axp20x-regulator.c +++ b/drivers/regulator/axp20x-regulator.c @@ -264,3 +264,4 @@ module_platform_driver(axp20x_regulator_driver); MODULE_LICENSE(GPL v2); MODULE_AUTHOR(Carlo Caione ca...@caione.org); MODULE_DESCRIPTION(Regulator Driver for AXP20X PMIC); +MODULE_ALIAS(platform:axp20x-regulator); -- 2.1.4 -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Bug#793185: [linux-sunxi] Re: forwarding a bug: cpufreq missing in debian stable on a cuibeboard
Hi, On 01-08-15 14:50, Ian Campbell wrote: On Sat, 2015-08-01 at 10:51 +0100, Ian Campbell wrote: http://git.kernel.org/linus/07949bf9c63c9a80027fe8452d5fe8b9ba9b3c23 I'll see about backporting that to the 4.1 kernel in Debian until we move to 4.2. It turns out that this patch while necessary is not sufficient and I also needed the following for full cpufreq autoloading on Cubietruck with Debian's modular kernel config. Makes sense, and the patch looks good. Can you please submit this upstream to the regulator subsys maintainers? I know that Mark is in the Cc, but this thread does not really look like an official patch submission, I believe that a separate patch submission using the standard procedure for those would be good. Thanks Regards, Hans Cheers, Ian. 8--- From 38880ed1b26e8778268c1da41ab2bb52c6797947 Mon Sep 17 00:00:00 2001 From: Ian Campbell i...@hellion.org.uk Date: Sat, 1 Aug 2015 13:44:06 +0100 Subject: [PATCH] regulator: axp20x: Add module alias This allows the module to be autoloaded. Together with 07949bf9c63c (cpufreq: dt: allow driver to boot automatically) this is sufficient to allow a modular kernel (such as Debian's) to enable cpufreq on a Cubietruck. Signed-off-by: Ian Campbell i...@hellion.org.uk Cc: Liam Girdwood lgirdw...@gmail.com Cc: Mark Brown broo...@kernel.org Cc: Signed-off-by: Chen-Yu Tsai w...@csie.org Cc: Maxime Ripard maxime.rip...@free-electrons.com --- drivers/regulator/axp20x-regulator.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/regulator/axp20x-regulator.c b/drivers/regulator/axp20x-regulator.c index e4331f5..2c82131 100644 --- a/drivers/regulator/axp20x-regulator.c +++ b/drivers/regulator/axp20x-regulator.c @@ -264,3 +264,4 @@ module_platform_driver(axp20x_regulator_driver); MODULE_LICENSE(GPL v2); MODULE_AUTHOR(Carlo Caione ca...@caione.org); MODULE_DESCRIPTION(Regulator Driver for AXP20X PMIC); +MODULE_ALIAS(platform:axp20x-regulator); -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Bug#793185: [linux-sunxi] Re: forwarding a bug: cpufreq missing in debian stable on a cuibeboard
On Thu, 2015-07-30 at 15:47 +0800, Chen-Yu Tsai wrote: On Sat, Jul 25, 2015 at 11:30 PM, Ian Campbell i...@debian.org wrote: On Sat, 2015-07-25 at 22:54 +0800, Chen-Yu Tsai wrote: On Sat, Jul 25, 2015 at 10:46 PM, Leonardo Canducci leonardo.candu...@gmail.com wrote: I got lost somewhere in that long thread but I saw cpufreq on cubie* works for someone [0]. It's just a matter of loading two modules. I tried myself on my jessie install (kernel from experimental) and can confirm that: leo@cubetto:~$ sudo modprobe axp20x-regulator leo@cubetto:~$ sudo modprobe cpufreq-dt leo@cubetto:~$ ls /sys/devices/system/cpu/cpu0/cpufreq/ affected_cpus related_cpus scaling_governor cpuinfo_cur_freqscaling_available_frequencies scaling_max_freq cpuinfo_max_freqscaling_available_governors scaling_min_freq cpuinfo_min_freqscaling_cur_freq scaling_setspeed cpuinfo_transition_latency scaling_driver statsplatform_device_register_simple How do I make this change persistent? Add both module names to /etc/modules. Is there any way to arrange for these modules to be loaded automatically without the user needing to configure it manually, likeplatform_device_register_simple(cpufreq-dt, -1, NULL, 0); any other h/w driver? I'd expect at least the axp20x-regulator driver to get autoloaded when the relevant hardware is present. Not sure about the cpufreq-dt one, * In particular, when such drivers are built as modules, they can't be * hotplugged. but should it not be loaded if the relevant nodes are present? cpufreq-dt is not a node in the DT. It is added in platform code. See arch/arm/mach-sunxi/sunxi.c. That is this: platform_device_register_simple(cpufreq-dt, -1, NULL, 0); AFAIK all other users of cpufreq-dt use this method. Not sure how you can automatically detect this... Supposedly there wouldfeatures/all/cpufreq-dt-allow-driver-to-boot-automatically.patch be an event to udev? I would expect the register to emit something, perhaps all that is missing is a suitable MODULE_ALIAS. Looking around there seems to be a fair few MODULE_ALIAS(platform:foo) which appear to serve this purpose. ...searches..., aha!: http://lists.infradead.org/pipermail/linux-arm-kernel/2015-June/350884.html which is in v4.2-rc1 as: http://git.kernel.org/linus/07949bf9c63c9a80027fe8452d5fe8b9ba9b3c23 I'll see about backporting that to the 4.1 kernel in Debian until we move to 4.2. Ian. -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: forwarding a bug: cpufreq missing in debian stable on a cuibeboard
On Fri, Jul 24, 2015 at 03:23:33PM +0200, Hans de Goede wrote: Hi, On 24-07-15 15:16, Maxime Ripard wrote: On Fri, Jul 24, 2015 at 02:58:31PM +0200, Hans de Goede wrote: There is slightly more to it then those 5 lines, but yes we should enable voltage scaling on more boards. This mostly requires someone to simply just do the work. I've a workshop on dts this weekend at our localhacker space and the plan is for the people attending to get some handson experience by them doing this work (amongst other things) :) While I agree with you on the fact that more board needs to have the regulators enabled, I really don't think that making some newbies doing it without any schematics (and boards I guess?) They will only be writing patches for boards which I have, and the patches will be tested on the actual boards before submitting them upstream. I will be collecting and double checking all patches before sending them to you. I will let you know if they blow up any boards :) But I do not really expect that to happen. is a good thing when it comes to something that can permanently damage a board. I'd expect that such changes would be carefully done and tested before being submitted. And they will be, see above. Perfect then :) My point was simply that we shouldn't have automated changes for this, just for the sake of having regulators for all the boards. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: Digital signature
Re: Bug#793185: [linux-sunxi] Re: forwarding a bug: cpufreq missing in debian stable on a cuibeboard
On Sat, Jul 25, 2015 at 11:30 PM, Ian Campbell i...@debian.org wrote: On Sat, 2015-07-25 at 22:54 +0800, Chen-Yu Tsai wrote: On Sat, Jul 25, 2015 at 10:46 PM, Leonardo Canducci leonardo.candu...@gmail.com wrote: I got lost somewhere in that long thread but I saw cpufreq on cubie* works for someone [0]. It's just a matter of loading two modules. I tried myself on my jessie install (kernel from experimental) and can confirm that: leo@cubetto:~$ sudo modprobe axp20x-regulator leo@cubetto:~$ sudo modprobe cpufreq-dt leo@cubetto:~$ ls /sys/devices/system/cpu/cpu0/cpufreq/ affected_cpus related_cpus scaling_governor cpuinfo_cur_freqscaling_available_frequencies scaling_max_freq cpuinfo_max_freqscaling_available_governors scaling_min_freq cpuinfo_min_freqscaling_cur_freq scaling_setspeed cpuinfo_transition_latency scaling_driver stats How do I make this change persistent? Add both module names to /etc/modules. Is there any way to arrange for these modules to be loaded automatically without the user needing to configure it manually, like any other h/w driver? I'd expect at least the axp20x-regulator driver to get autoloaded when the relevant hardware is present. Not sure about the cpufreq-dt one, but should it not be loaded if the relevant nodes are present? cpufreq-dt is not a node in the DT. It is added in platform code. See arch/arm/mach-sunxi/sunxi.c. AFAIK all other users of cpufreq-dt use this method. Not sure how you can automatically detect this... Supposedly there would be an event to udev? ChenYu -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: forwarding a bug: cpufreq missing in debian stable on a cuibeboard
I got lost somewhere in that long thread but I saw cpufreq on cubie* works for someone [0]. It's just a matter of loading two modules. I tried myself on my jessie install (kernel from experimental) and can confirm that: leo@cubetto:~$ sudo modprobe axp20x-regulator leo@cubetto:~$ sudo modprobe cpufreq-dt leo@cubetto:~$ ls /sys/devices/system/cpu/cpu0/cpufreq/ affected_cpus related_cpus scaling_governor cpuinfo_cur_freqscaling_available_frequencies scaling_max_freq cpuinfo_max_freqscaling_available_governorsscaling_min_freq cpuinfo_min_freqscaling_cur_freq scaling_setspeed cpuinfo_transition_latency scaling_driver stats How do I make this change persistent? Thanks, Leonardo [0] http://forum.armbian.com/index.php/topic/108-no-cpufreq-support-in-cubietruck-debian-39-wheezy-405/?p=781 2015-07-24 15:23 GMT+02:00 Hans de Goede hdego...@redhat.com: Hi, On 24-07-15 15:16, Maxime Ripard wrote: On Fri, Jul 24, 2015 at 02:58:31PM +0200, Hans de Goede wrote: There is slightly more to it then those 5 lines, but yes we should enable voltage scaling on more boards. This mostly requires someone to simply just do the work. I've a workshop on dts this weekend at our localhacker space and the plan is for the people attending to get some handson experience by them doing this work (amongst other things) :) While I agree with you on the fact that more board needs to have the regulators enabled, I really don't think that making some newbies doing it without any schematics (and boards I guess?) They will only be writing patches for boards which I have, and the patches will be tested on the actual boards before submitting them upstream. I will be collecting and double checking all patches before sending them to you. I will let you know if they blow up any boards :) But I do not really expect that to happen. is a good thing when it comes to something that can permanently damage a board. I'd expect that such changes would be carefully done and tested before being submitted. And they will be, see above. Regards, Hans -- Leonardo Canducci -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: forwarding a bug: cpufreq missing in debian stable on a cuibeboard
On Sat, Jul 25, 2015 at 10:46 PM, Leonardo Canducci leonardo.candu...@gmail.com wrote: I got lost somewhere in that long thread but I saw cpufreq on cubie* works for someone [0]. It's just a matter of loading two modules. I tried myself on my jessie install (kernel from experimental) and can confirm that: leo@cubetto:~$ sudo modprobe axp20x-regulator leo@cubetto:~$ sudo modprobe cpufreq-dt leo@cubetto:~$ ls /sys/devices/system/cpu/cpu0/cpufreq/ affected_cpus related_cpus scaling_governor cpuinfo_cur_freqscaling_available_frequencies scaling_max_freq cpuinfo_max_freqscaling_available_governorsscaling_min_freq cpuinfo_min_freqscaling_cur_freq scaling_setspeed cpuinfo_transition_latency scaling_driver stats How do I make this change persistent? Add both module names to /etc/modules. ChenYu Thanks, Leonardo [0] http://forum.armbian.com/index.php/topic/108-no-cpufreq-support-in-cubietruck-debian-39-wheezy-405/?p=781 2015-07-24 15:23 GMT+02:00 Hans de Goede hdego...@redhat.com: Hi, On 24-07-15 15:16, Maxime Ripard wrote: On Fri, Jul 24, 2015 at 02:58:31PM +0200, Hans de Goede wrote: There is slightly more to it then those 5 lines, but yes we should enable voltage scaling on more boards. This mostly requires someone to simply just do the work. I've a workshop on dts this weekend at our localhacker space and the plan is for the people attending to get some handson experience by them doing this work (amongst other things) :) While I agree with you on the fact that more board needs to have the regulators enabled, I really don't think that making some newbies doing it without any schematics (and boards I guess?) They will only be writing patches for boards which I have, and the patches will be tested on the actual boards before submitting them upstream. I will be collecting and double checking all patches before sending them to you. I will let you know if they blow up any boards :) But I do not really expect that to happen. is a good thing when it comes to something that can permanently damage a board. I'd expect that such changes would be carefully done and tested before being submitted. And they will be, see above. Regards, Hans -- Leonardo Canducci -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: forwarding a bug: cpufreq missing in debian stable on a cuibeboard
Hi, Timo wrote: I think what Maxime was trying to say is, that while all of your boards support Cpufreq, only the Cubietruck supports voltage scaling because only Cubietruck has the power regulator nodes defined in it's dts file (just have a look at the last lines of the Cubitruck dts file and compare that to the dts file, let's say, for Bananapi). On the other boards, the frequency is scaled, but the voltage always stays at 1.4V as set in U-Boot (that means the voltages in the cpufreq operating points are not used on these boards). At least that's what I understand after a recent email axchange with Chen-Yu Tsai. Ah, now I think I understand. You're talking about these lines here? https://github.com/RobertCNelson/u-boot/blob/master/arch/arm/dts/sun7i-a20-cubietruck.dts#L244-L269 So while using CONFIG_REGULATOR_AXP20X=y will bring working cpufreq support to the cubietruck, shouldn't adding these lines to the device trees of the other 5 A20 devices enable CPU voltage scaling there? -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: forwarding a bug: cpufreq missing in debian stable on a cuibeboard
Am Freitag, 24. Juli 2015 14:49:42 UTC+2 schrieb Thomas Kaiser: Ah, now I think I understand. You're talking about these lines here? https://github.com/RobertCNelson/u-boot/blob/master/arch/arm/dts/sun7i-a20-cubietruck.dts#L244-L269 Yes. So while using CONFIG_REGULATOR_AXP20X=y will bring working cpufreq support to the cubietruck, shouldn't adding these lines to the device trees of the other 5 A20 devices enable CPU voltage scaling there? Basically yes. The point that Chen-Yu made is that he and other developers don't have all boards available to verify that all of these boards use the same layout for their wiring. Therefore they just leave these bits out. I'm actually working on a small patch to add these regulator bits to the BananaPi and possibly BananaPro dts files. I will post it soon, when I gathered enough information to ensure everything works fine. But anyway, we're getting offtopic here. So let's postpone this discussion until then. Cheers, Timo -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: forwarding a bug: cpufreq missing in debian stable on a cuibeboard
Hi, On 24-07-15 14:49, Thomas Kaiser wrote: Hi, Timo wrote: I think what Maxime was trying to say is, that while all of your boards support Cpufreq, only the Cubietruck supports voltage scaling because only Cubietruck has the power regulator nodes defined in it's dts file (just have a look at the last lines of the Cubitruck dts file and compare that to the dts file, let's say, for Bananapi). On the other boards, the frequency is scaled, but the voltage always stays at 1.4V as set in U-Boot (that means the voltages in the cpufreq operating points are not used on these boards). At least that's what I understand after a recent email axchange with Chen-Yu Tsai. Ah, now I think I understand. You're talking about these lines here? https://github.com/RobertCNelson/u-boot/blob/master/arch/arm/dts/sun7i-a20-cubietruck.dts#L244-L269 So while using CONFIG_REGULATOR_AXP20X=y will bring working cpufreq support to the cubietruck, shouldn't adding these lines to the device trees of the other 5 A20 devices enable CPU voltage scaling there? There is slightly more to it then those 5 lines, but yes we should enable voltage scaling on more boards. This mostly requires someone to simply just do the work. I've a workshop on dts this weekend at our localhacker space and the plan is for the people attending to get some handson experience by them doing this work (amongst other things) :) Regards, Hans -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: forwarding a bug: cpufreq missing in debian stable on a cuibeboard
On Fri, Jul 24, 2015 at 05:49:42AM -0700, Thomas Kaiser wrote: Hi, Timo wrote: I think what Maxime was trying to say is, that while all of your boards support Cpufreq, only the Cubietruck supports voltage scaling because only Cubietruck has the power regulator nodes defined in it's dts file (just have a look at the last lines of the Cubitruck dts file and compare that to the dts file, let's say, for Bananapi). On the other boards, the frequency is scaled, but the voltage always stays at 1.4V as set in U-Boot (that means the voltages in the cpufreq operating points are not used on these boards). At least that's what I understand after a recent email axchange with Chen-Yu Tsai. Ah, now I think I understand. You're talking about these lines here? https://github.com/RobertCNelson/u-boot/blob/master/arch/arm/dts/sun7i-a20-cubietruck.dts#L244-L269 So while using CONFIG_REGULATOR_AXP20X=y will bring working cpufreq support to the cubietruck, shouldn't adding these lines to the device trees of the other 5 A20 devices enable CPU voltage scaling there? That and https://github.com/RobertCNelson/u-boot/blob/master/arch/arm/dts/sun7i-a20-cubietruck.dts#L108-L110 Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: Digital signature
Re: [linux-sunxi] Re: forwarding a bug: cpufreq missing in debian stable on a cuibeboard
On Fri, Jul 24, 2015 at 05:58:34AM -0700, m.silentcr...@gmail.com wrote: So while using CONFIG_REGULATOR_AXP20X=y will bring working cpufreq support to the cubietruck, shouldn't adding these lines to the device trees of the other 5 A20 devices enable CPU voltage scaling there? Basically yes. The point that Chen-Yu made is that he and other developers don't have all boards available to verify that all of these boards use the same layout for their wiring. The hard part is that there's not a single reference design there. There's some pattern, but it's not at all something that can be made generic, because to a few exceptions, no one uses the same regulator to power the same thing, and with the same constraints (that directly depend on the stuff that you have connected on the other end of the regulator). So any mechanical change is not something that can be done. Especially for something that might blow up your board. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: Digital signature
[linux-sunxi] Re: forwarding a bug: cpufreq missing in debian stable on a cuibeboard
Leonardo Canducci wrote: I've submitted a bug [0] in the Debian BTS and tried kernel 4.0 and 4.1 from unstable and experimental branches with no success I can confirm that it's neither working with 4.0.4 and 4.1 on cubietruck (always tried Wheezy): http://forum.armbian.com/index.php/topic/108-no-cpufreq-support-in-cubietruck-debian-39-wheezy-405/#entry764 With the very same kernel/userland (kernel exactly identical) cpufreq stuff works on the other A20 devices I tested with: A20-Lime2, Banana Pi, Banana Pro, pcDuino3 Nano, Lamobo R1 -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: forwarding a bug: cpufreq missing in debian stable on a cuibeboard
Hi, Hans de Goede wrote: Is the debian kernel building the axp209 mfd driver, and also the axp20x regulator drive, and do these get loaded properly on the cubietruck ? Unfortunately I've no idea since i fetch the kernel sources directly from git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git And this was the kernel config I used: https://github.com/igorpecovnik/lib/blob/429867a80c85011b6d31048481c0beb1c7bc76fa/config/linux-sunxi-next.config What puzzles me is that exactly the same kernel (I used Igor Pečovnik's build system) provides working cpufreq support on 5 A20 devices and one it fails. -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: forwarding a bug: cpufreq missing in debian stable on a cuibeboard
Hi, Maxime Ripard wrote: So any mechanical change is not something that can be done. Especially for something that might blow up your board. Thanks for the warning. I already started to prepare to blow away the Lamobo R1 I've here by applying the cubietruck device tree settings (for this board there's only a reverse engineered power scheme available that looks good to my. But actually I've no idea what I'm doing :-) Now with CONFIG_REGULATOR_AXP20X=y everything's fine on cubietruck. Thanks for providing both the solution and the comprehensive interrelationship between here and there (and of course for all the good work you all provide) -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: forwarding a bug: cpufreq missing in debian stable on a cuibeboard
On Fri, Jul 24, 2015 at 02:58:31PM +0200, Hans de Goede wrote: There is slightly more to it then those 5 lines, but yes we should enable voltage scaling on more boards. This mostly requires someone to simply just do the work. I've a workshop on dts this weekend at our localhacker space and the plan is for the people attending to get some handson experience by them doing this work (amongst other things) :) While I agree with you on the fact that more board needs to have the regulators enabled, I really don't think that making some newbies doing it without any schematics (and boards I guess?) is a good thing when it comes to something that can permanently damage a board. I'd expect that such changes would be carefully done and tested before being submitted. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: Digital signature
Re: [linux-sunxi] Re: forwarding a bug: cpufreq missing in debian stable on a cuibeboard
Hi, On 24-07-15 15:16, Maxime Ripard wrote: On Fri, Jul 24, 2015 at 02:58:31PM +0200, Hans de Goede wrote: There is slightly more to it then those 5 lines, but yes we should enable voltage scaling on more boards. This mostly requires someone to simply just do the work. I've a workshop on dts this weekend at our localhacker space and the plan is for the people attending to get some handson experience by them doing this work (amongst other things) :) While I agree with you on the fact that more board needs to have the regulators enabled, I really don't think that making some newbies doing it without any schematics (and boards I guess?) They will only be writing patches for boards which I have, and the patches will be tested on the actual boards before submitting them upstream. I will be collecting and double checking all patches before sending them to you. I will let you know if they blow up any boards :) But I do not really expect that to happen. is a good thing when it comes to something that can permanently damage a board. I'd expect that such changes would be carefully done and tested before being submitted. And they will be, see above. Regards, Hans -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: forwarding a bug: cpufreq missing in debian stable on a cuibeboard
On Fri, Jul 24, 2015 at 05:12:57AM -0700, Thomas Kaiser wrote: What puzzles me is that exactly the same kernel (I used Igor Pečovnik's build system) provides working cpufreq support on 5 A20 devices and one it fails. And none of those 5 use CPU voltage scaling. Maybe I don't understand the whole meaning. But on a Banana Pi a few weeks ago [1] and on a pcDuino3 Nano I used the last days for USB/UAS benchmarks the cpufreq stuff was available below /sys/devices/system/cpu/cpu0/cpufreq/ and altering parameters always had an effect. Yes, and it had an effect on the frequency, not the voltage. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: Digital signature
Re: [linux-sunxi] Re: forwarding a bug: cpufreq missing in debian stable on a cuibeboard
On Fri, Jul 24, 2015 at 04:36:57AM -0700, Thomas Kaiser wrote: Hi, Hans de Goede wrote: Is the debian kernel building the axp209 mfd driver, and also the axp20x regulator drive, and do these get loaded properly on the cubietruck ? Unfortunately I've no idea since i fetch the kernel sources directly from git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git And this was the kernel config I used: https://github.com/igorpecovnik/lib/blob/429867a80c85011b6d31048481c0beb1c7bc76fa/config/linux-sunxi-next.config # CONFIG_REGULATOR_AXP20X is not set What puzzles me is that exactly the same kernel (I used Igor Pečovnik's build system) provides working cpufreq support on 5 A20 devices and one it fails. And none of those 5 use CPU voltage scaling. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: Digital signature
Re: [linux-sunxi] Re: forwarding a bug: cpufreq missing in debian stable on a cuibeboard
Hi, Maxime Ripard wrote: On Fri, Jul 24, 2015 at 04:36:57AM -0700, Thomas Kaiser wrote: And this was the kernel config I used: https://github.com/igorpecovnik/lib/blob/429867a80c85011b6d31048481c0beb1c7bc76fa/config/linux-sunxi-next.config # CONFIG_REGULATOR_AXP20X is not set Thanks. Will give it a try with CONFIG_REGULATOR_AXP20X=y ASAP. What puzzles me is that exactly the same kernel (I used Igor Pečovnik's build system) provides working cpufreq support on 5 A20 devices and one it fails. And none of those 5 use CPU voltage scaling. Maybe I don't understand the whole meaning. But on a Banana Pi a few weeks ago [1] and on a pcDuino3 Nano I used the last days for USB/UAS benchmarks the cpufreq stuff was available below /sys/devices/system/cpu/cpu0/cpufreq/ and altering parameters always had an effect. But I will follow your advise, double check and report back. Thx, Thomas [1] http://www.lemaker.org/forum.php?mod=viewthreadtid=15543 -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: forwarding a bug: cpufreq missing in debian stable on a cuibeboard
Am Freitag, 24. Juli 2015 14:12:57 UTC+2 schrieb Thomas Kaiser: Maxime Ripard wrote: What puzzles me is that exactly the same kernel (I used Igor Pečovnik's build system) provides working cpufreq support on 5 A20 devices and one it fails. And none of those 5 use CPU voltage scaling. Maybe I don't understand the whole meaning. But on a Banana Pi a few weeks ago [1] and on a pcDuino3 Nano I used the last days for USB/UAS benchmarks the cpufreq stuff was available below /sys/devices/system/cpu/cpu0/cpufreq/ and altering parameters always had an effect. But I will follow your advise, double check and report back. I think what Maxime was trying to say is, that while all of your boards support Cpufreq, only the Cubietruck supports voltage scaling because only Cubietruck has the power regulator nodes defined in it's dts file (just have a look at the last lines of the Cubitruck dts file and compare that to the dts file, let's say, for Bananapi). On the other boards, the frequency is scaled, but the voltage always stays at 1.4V as set in U-Boot (that means the voltages in the cpufreq operating points are not used on these boards). At least that's what I understand after a recent email axchange with Chen-Yu Tsai. Cheers, Timo -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
