[linux-sunxi] Re: Mainline work status
Hi everyone, On Wed, Dec 24, 2014 at 11:29 PM, wens Tsai wens...@gmail.com wrote: Hi everyone, As some of you might have noticed, I've sent out patches for A80 MMC and AXP20x. In addition, I've picked up Boris' AXP221 patches to resend after the AXP patches are merged. The following is a list of things I'm working on or waiting to submit: Here's an update: - AXP20x (PEK and docs) series, originally by Carlo, posted v8 v10 submitted, waiting for acks (by who I'm not sure...) - AXP20x regulator driver cleanup, finished and tested Merged - AXP221 support, originally by Boris, finished and tested Can be found at: https://github.com/wens/linux/tree/axp221-v5 I will submit it later today (hopefully). This depends on the AXP20x bindings though. * Also enables WiFi on the Hummingbird A31 Apart from the MMC resets I keep getting, looks fine. - sunxi (sun[457]i) cpufreq support, finished and testing (CB/CB2 tested) * Only added support for the boards I own. It's just a matter of adding the regulator nodes with the proper constraints Merged. - sun6i cpufreq support, WiP - sun8i cpufreq support, minimal work only No progress on these two. - sun9i mmc support, posted v2 Merged. - sun9i usb support, v3 WiP Merged, except for the phy driver. Maintainer hasn't responded yet. - RSB driver, not working yet Finished and submitted, though it seems it will be rejected. See: http://www.spinics.net/lists/linux-i2c/msg18838.html Will probably make it a custom bus with regmap support, like SPMI. I've also ordered A31s and A33 devboards from Sinlinx, as well as an A33 tablet. Regards ChenYu All the above, excluding RSB, can be found in my repository: https://github.com/wens/linux Each topic is a separate branch, except for the AXP branches, which have dependencies. Testing and feedback is more than welcome. Regards 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.
[linux-sunxi] Re: Mainline work status
On Fri, Jan 09, 2015 at 04:52:03PM +0800, wens Tsai wrote: For now I've dropped that bit. The dependency is ELDOs are powered from DCDC1, which is a fairly simple dependency. I think we can get around it by registering the DCDC ones first. The thing is that this dependency is pretty much dependant on the board. We could really well have other combinations on different boards, that we wouldn't be able to solve. I doubt anyone sane would chain DCDC regulators or LDO regulators, like DCDC1 - DCDC2-in, or ALDO1 - ELDO-in. It doesn't make sense from an efficiency standpoint. And you'll likely be further limited by how much current the parent regulator can drive. A more likely scenario would be DCDC - some external regulator - xLDO. I don't think the regulator_set stuff solves this either. Originally, I was thinking about something similar to what ASoC does, that would register sub-devices, one per regulator, that would really be treated as sub-devices and could solve cases like that with the regular deferred probe mechanism. But maybe you're right and we don't need it right now. - sunxi (sun[457]i) cpufreq support, finished and testing (CB/CB2 tested) * Only added support for the boards I own. It's just a matter of adding the regulator nodes with the proper constraints Did you test individual OPPs or global ones (ie per-board or per-SoC)? Eventually, I'd like to have per-SoC OPPs. It doesn't seem that undoable from the spreadsheet I shared with you. I've tested per-SoC OPPs with the boards I have using the hardware reliability test on the wiki [1]. Doing per-board OPPs should be as simple as overriding the OPP table in the board dts. As I will state in the series cover letter, for sun[457]i the OPPs are the same or very similar. Nice. For sun6i it is somewhat harder. Yep, that version D thing is going to cause us a bit of trouble, but since we don't have any hardware available, I'd say we should ignore it for now. Sounds good. This becomes rather simple then. Just need to get the AXP221 patches merged first. I hope that the voltage tolerance levels on the hypothetical version D is high enough so that we don't ruin anyone's board though. From what I saw, the rev D is always slightly under-volted (something around 50mV). It shouldn't really damage the CPU if we provide more power to it, and we're staying within the CPU operating range anyway, so we should be fine here. 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: Mainline work status
On Tue, Jan 06, 2015 at 12:56:37AM +0800, wens Tsai wrote: Hi, On Tue, Jan 6, 2015 at 12:15 AM, Maxime Ripard maxime.rip...@free-electrons.com wrote: Hi Chen-Yu, On Wed, Dec 24, 2014 at 11:29:26PM +0800, wens Tsai wrote: Hi everyone, As some of you might have noticed, I've sent out patches for A80 MMC and AXP20x. In addition, I've picked up Boris' AXP221 patches to resend after the AXP patches are merged. Thanks for your amazing work. The following is a list of things I'm working on or waiting to submit: - AXP20x (PEK and docs) series, originally by Carlo, posted v8 - AXP20x regulator driver cleanup, finished and tested What is left to be posted, besides the DT bits? This is actually getting rid of the DT parsing code in the regulator driver, and using common code in the regulator core added in 3.19-rc1. So this is new. Oh, cool. - AXP221 support, originally by Boris, finished and tested * Also enables WiFi on the Hummingbird A31 There was some discussion since for some board (maybe the APP4) we had some circular dependency between the regulators exposed by the PMIC. Has that been taken care of? The work Boris has done on that doesn't mesh well with the previous item. What previous items? The DT parsing code removal? For now I've dropped that bit. The dependency is ELDOs are powered from DCDC1, which is a fairly simple dependency. I think we can get around it by registering the DCDC ones first. The thing is that this dependency is pretty much dependant on the board. We could really well have other combinations on different boards, that we wouldn't be able to solve. - sunxi (sun[457]i) cpufreq support, finished and testing (CB/CB2 tested) * Only added support for the boards I own. It's just a matter of adding the regulator nodes with the proper constraints Did you test individual OPPs or global ones (ie per-board or per-SoC)? Eventually, I'd like to have per-SoC OPPs. It doesn't seem that undoable from the spreadsheet I shared with you. I've tested per-SoC OPPs with the boards I have using the hardware reliability test on the wiki [1]. Doing per-board OPPs should be as simple as overriding the OPP table in the board dts. As I will state in the series cover letter, for sun[457]i the OPPs are the same or very similar. Nice. For sun6i it is somewhat harder. Yep, that version D thing is going to cause us a bit of trouble, but since we don't have any hardware available, I'd say we should ignore it for now. 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: Mainline work status
Hi, On 09-01-15 09:30, Maxime Ripard wrote: On Tue, Jan 06, 2015 at 12:56:37AM +0800, wens Tsai wrote: snip For sun6i it is somewhat harder. Yep, that version D thing is going to cause us a bit of trouble, but since we don't have any hardware available, I'd say we should ignore it for now. Version D ? I more or less completely missed that, care to explain ? I guess this is going to impact u-boot too ? 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.
[linux-sunxi] Re: Mainline work status
On Fri, Jan 09, 2015 at 10:11:10AM +0100, Hans de Goede wrote: Hi, On 09-01-15 09:51, Maxime Ripard wrote: On Fri, Jan 09, 2015 at 09:36:28AM +0100, Hans de Goede wrote: Hi, On 09-01-15 09:30, Maxime Ripard wrote: On Tue, Jan 06, 2015 at 12:56:37AM +0800, wens Tsai wrote: snip For sun6i it is somewhat harder. Yep, that version D thing is going to cause us a bit of trouble, but since we don't have any hardware available, I'd say we should ignore it for now. Version D ? I more or less completely missed that, care to explain ? I guess this is going to impact u-boot too ? I don't think it will, or at least, not for this issue. From what we saw in the Allwinner BSPs, the A31 rev D might need different operating points for cpufreq. Ah, what about the max-speed operating point ? That is being set by u-boot early on, specifically for sun6i / sun8i it sets VDD-CPU to 1.2V and the CPU-clock to 1008MHz. Based on the two samples here: https://github.com/linux-sunxi/sunxi-boards/blob/master/sys_config/a31/hummingbird_a31.fex#L919 and here: https://github.com/linux-sunxi/sunxi-boards/blob/master/sys_config/a31/mele_i7.fex#L1436 The voltage always seem lower for each OPP. So I guess if you use the voltages from the pre-rev-D OPPs, you'd be fine. It's not really an issue per-se, but supporting both pre-rev-D and post-rev-D will need to have a bit of thoughts. Hmm, tricky. What if we add a second, soc-specific, compatible to the cpu nodes which contains the cpu-revision, and then have 2 nodes for each cpu, with either one (or both) with status = disabled; and then on early board init detect the revision and enable the right cpu nodes ? I was more thinking to feed the OPPs directly from the code in mach-sunxi if we detect a rev-D. I don't really know what would be the side effects of playing with the CPU nodes like that. 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: Mainline work status
Hi, On 09-01-15 10:37, Maxime Ripard wrote: On Fri, Jan 09, 2015 at 10:11:10AM +0100, Hans de Goede wrote: Hi, On 09-01-15 09:51, Maxime Ripard wrote: On Fri, Jan 09, 2015 at 09:36:28AM +0100, Hans de Goede wrote: Hi, On 09-01-15 09:30, Maxime Ripard wrote: On Tue, Jan 06, 2015 at 12:56:37AM +0800, wens Tsai wrote: snip For sun6i it is somewhat harder. Yep, that version D thing is going to cause us a bit of trouble, but since we don't have any hardware available, I'd say we should ignore it for now. Version D ? I more or less completely missed that, care to explain ? I guess this is going to impact u-boot too ? I don't think it will, or at least, not for this issue. From what we saw in the Allwinner BSPs, the A31 rev D might need different operating points for cpufreq. Ah, what about the max-speed operating point ? That is being set by u-boot early on, specifically for sun6i / sun8i it sets VDD-CPU to 1.2V and the CPU-clock to 1008MHz. Based on the two samples here: https://github.com/linux-sunxi/sunxi-boards/blob/master/sys_config/a31/hummingbird_a31.fex#L919 and here: https://github.com/linux-sunxi/sunxi-boards/blob/master/sys_config/a31/mele_i7.fex#L1436 The voltage always seem lower for each OPP. So I guess if you use the voltages from the pre-rev-D OPPs, you'd be fine. It's not really an issue per-se, but supporting both pre-rev-D and post-rev-D will need to have a bit of thoughts. Hmm, tricky. What if we add a second, soc-specific, compatible to the cpu nodes which contains the cpu-revision, and then have 2 nodes for each cpu, with either one (or both) with status = disabled; and then on early board init detect the revision and enable the right cpu nodes ? I was more thinking to feed the OPPs directly from the code in mach-sunxi if we detect a rev-D. I don't really know what would be the side effects of playing with the CPU nodes like that. True (wrt side-effects), but having the OPPs defined in code, rather then in the dts seems wrong to me. Maybe for sun6i we need to define the OPPs in a separate dt-node (one per revision) and have mach-sunxi populate the cpu node with the OPPs for the right revision ? 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.
[linux-sunxi] Re: Mainline work status
On Fri, Jan 09, 2015 at 09:36:28AM +0100, Hans de Goede wrote: Hi, On 09-01-15 09:30, Maxime Ripard wrote: On Tue, Jan 06, 2015 at 12:56:37AM +0800, wens Tsai wrote: snip For sun6i it is somewhat harder. Yep, that version D thing is going to cause us a bit of trouble, but since we don't have any hardware available, I'd say we should ignore it for now. Version D ? I more or less completely missed that, care to explain ? I guess this is going to impact u-boot too ? I don't think it will, or at least, not for this issue. From what we saw in the Allwinner BSPs, the A31 rev D might need different operating points for cpufreq. It's not really an issue per-se, but supporting both pre-rev-D and post-rev-D will need to have a bit of thoughts. 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: Mainline work status
On Fri, Jan 9, 2015 at 4:30 PM, Maxime Ripard maxime.rip...@free-electrons.com wrote: On Tue, Jan 06, 2015 at 12:56:37AM +0800, wens Tsai wrote: Hi, On Tue, Jan 6, 2015 at 12:15 AM, Maxime Ripard maxime.rip...@free-electrons.com wrote: Hi Chen-Yu, On Wed, Dec 24, 2014 at 11:29:26PM +0800, wens Tsai wrote: Hi everyone, As some of you might have noticed, I've sent out patches for A80 MMC and AXP20x. In addition, I've picked up Boris' AXP221 patches to resend after the AXP patches are merged. Thanks for your amazing work. The following is a list of things I'm working on or waiting to submit: - AXP20x (PEK and docs) series, originally by Carlo, posted v8 - AXP20x regulator driver cleanup, finished and tested What is left to be posted, besides the DT bits? This is actually getting rid of the DT parsing code in the regulator driver, and using common code in the regulator core added in 3.19-rc1. So this is new. Oh, cool. - AXP221 support, originally by Boris, finished and tested * Also enables WiFi on the Hummingbird A31 There was some discussion since for some board (maybe the APP4) we had some circular dependency between the regulators exposed by the PMIC. Has that been taken care of? The work Boris has done on that doesn't mesh well with the previous item. What previous items? The DT parsing code removal? Yes. For now I've dropped that bit. The dependency is ELDOs are powered from DCDC1, which is a fairly simple dependency. I think we can get around it by registering the DCDC ones first. The thing is that this dependency is pretty much dependant on the board. We could really well have other combinations on different boards, that we wouldn't be able to solve. I doubt anyone sane would chain DCDC regulators or LDO regulators, like DCDC1 - DCDC2-in, or ALDO1 - ELDO-in. It doesn't make sense from an efficiency standpoint. And you'll likely be further limited by how much current the parent regulator can drive. A more likely scenario would be DCDC - some external regulator - xLDO. I don't think the regulator_set stuff solves this either. - sunxi (sun[457]i) cpufreq support, finished and testing (CB/CB2 tested) * Only added support for the boards I own. It's just a matter of adding the regulator nodes with the proper constraints Did you test individual OPPs or global ones (ie per-board or per-SoC)? Eventually, I'd like to have per-SoC OPPs. It doesn't seem that undoable from the spreadsheet I shared with you. I've tested per-SoC OPPs with the boards I have using the hardware reliability test on the wiki [1]. Doing per-board OPPs should be as simple as overriding the OPP table in the board dts. As I will state in the series cover letter, for sun[457]i the OPPs are the same or very similar. Nice. For sun6i it is somewhat harder. Yep, that version D thing is going to cause us a bit of trouble, but since we don't have any hardware available, I'd say we should ignore it for now. Sounds good. This becomes rather simple then. Just need to get the AXP221 patches merged first. I hope that the voltage tolerance levels on the hypothetical version D is high enough so that we don't ruin anyone's board though. 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.
[linux-sunxi] Re: Mainline work status
Hi, On 09-01-15 09:51, Maxime Ripard wrote: On Fri, Jan 09, 2015 at 09:36:28AM +0100, Hans de Goede wrote: Hi, On 09-01-15 09:30, Maxime Ripard wrote: On Tue, Jan 06, 2015 at 12:56:37AM +0800, wens Tsai wrote: snip For sun6i it is somewhat harder. Yep, that version D thing is going to cause us a bit of trouble, but since we don't have any hardware available, I'd say we should ignore it for now. Version D ? I more or less completely missed that, care to explain ? I guess this is going to impact u-boot too ? I don't think it will, or at least, not for this issue. From what we saw in the Allwinner BSPs, the A31 rev D might need different operating points for cpufreq. Ah, what about the max-speed operating point ? That is being set by u-boot early on, specifically for sun6i / sun8i it sets VDD-CPU to 1.2V and the CPU-clock to 1008MHz. It's not really an issue per-se, but supporting both pre-rev-D and post-rev-D will need to have a bit of thoughts. Hmm, tricky. What if we add a second, soc-specific, compatible to the cpu nodes which contains the cpu-revision, and then have 2 nodes for each cpu, with either one (or both) with status = disabled; and then on early board init detect the revision and enable the right cpu nodes ? 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.
[linux-sunxi] Re: Mainline work status
On Fri, Jan 9, 2015 at 5:47 PM, Hans de Goede hdego...@redhat.com wrote: Hi, On 09-01-15 10:37, Maxime Ripard wrote: On Fri, Jan 09, 2015 at 10:11:10AM +0100, Hans de Goede wrote: Hi, On 09-01-15 09:51, Maxime Ripard wrote: On Fri, Jan 09, 2015 at 09:36:28AM +0100, Hans de Goede wrote: Hi, On 09-01-15 09:30, Maxime Ripard wrote: On Tue, Jan 06, 2015 at 12:56:37AM +0800, wens Tsai wrote: snip For sun6i it is somewhat harder. Yep, that version D thing is going to cause us a bit of trouble, but since we don't have any hardware available, I'd say we should ignore it for now. Version D ? I more or less completely missed that, care to explain ? I guess this is going to impact u-boot too ? I don't think it will, or at least, not for this issue. From what we saw in the Allwinner BSPs, the A31 rev D might need different operating points for cpufreq. Ah, what about the max-speed operating point ? That is being set by u-boot early on, specifically for sun6i / sun8i it sets VDD-CPU to 1.2V and the CPU-clock to 1008MHz. Based on the two samples here: https://github.com/linux-sunxi/sunxi-boards/blob/master/sys_config/a31/hummingbird_a31.fex#L919 and here: https://github.com/linux-sunxi/sunxi-boards/blob/master/sys_config/a31/mele_i7.fex#L1436 The voltage always seem lower for each OPP. So I guess if you use the voltages from the pre-rev-D OPPs, you'd be fine. It's not really an issue per-se, but supporting both pre-rev-D and post-rev-D will need to have a bit of thoughts. Hmm, tricky. What if we add a second, soc-specific, compatible to the cpu nodes which contains the cpu-revision, and then have 2 nodes for each cpu, with either one (or both) with status = disabled; and then on early board init detect the revision and enable the right cpu nodes ? I was more thinking to feed the OPPs directly from the code in mach-sunxi if we detect a rev-D. I don't really know what would be the side effects of playing with the CPU nodes like that. True (wrt side-effects), but having the OPPs defined in code, rather then in the dts seems wrong to me. Maybe for sun6i we need to define the OPPs in a separate dt-node (one per revision) and have mach-sunxi populate the cpu node with the OPPs for the right revision ? That was kind of what I had in mind when I started. May need some changes to cpufreq-dt driver. It currently loads OPPs from the default bindings unconditionally. Not sure if changing this would break anyone else. 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.
[linux-sunxi] Re: Mainline work status
Hi, On 09-01-15 10:53, wens Tsai wrote: On Fri, Jan 9, 2015 at 5:47 PM, Hans de Goede hdego...@redhat.com wrote: Hi, On 09-01-15 10:37, Maxime Ripard wrote: On Fri, Jan 09, 2015 at 10:11:10AM +0100, Hans de Goede wrote: Hi, On 09-01-15 09:51, Maxime Ripard wrote: On Fri, Jan 09, 2015 at 09:36:28AM +0100, Hans de Goede wrote: Hi, On 09-01-15 09:30, Maxime Ripard wrote: On Tue, Jan 06, 2015 at 12:56:37AM +0800, wens Tsai wrote: snip For sun6i it is somewhat harder. Yep, that version D thing is going to cause us a bit of trouble, but since we don't have any hardware available, I'd say we should ignore it for now. Version D ? I more or less completely missed that, care to explain ? I guess this is going to impact u-boot too ? I don't think it will, or at least, not for this issue. From what we saw in the Allwinner BSPs, the A31 rev D might need different operating points for cpufreq. Ah, what about the max-speed operating point ? That is being set by u-boot early on, specifically for sun6i / sun8i it sets VDD-CPU to 1.2V and the CPU-clock to 1008MHz. Based on the two samples here: https://github.com/linux-sunxi/sunxi-boards/blob/master/sys_config/a31/hummingbird_a31.fex#L919 and here: https://github.com/linux-sunxi/sunxi-boards/blob/master/sys_config/a31/mele_i7.fex#L1436 The voltage always seem lower for each OPP. So I guess if you use the voltages from the pre-rev-D OPPs, you'd be fine. It's not really an issue per-se, but supporting both pre-rev-D and post-rev-D will need to have a bit of thoughts. Hmm, tricky. What if we add a second, soc-specific, compatible to the cpu nodes which contains the cpu-revision, and then have 2 nodes for each cpu, with either one (or both) with status = disabled; and then on early board init detect the revision and enable the right cpu nodes ? I was more thinking to feed the OPPs directly from the code in mach-sunxi if we detect a rev-D. I don't really know what would be the side effects of playing with the CPU nodes like that. True (wrt side-effects), but having the OPPs defined in code, rather then in the dts seems wrong to me. Maybe for sun6i we need to define the OPPs in a separate dt-node (one per revision) and have mach-sunxi populate the cpu node with the OPPs for the right revision ? That was kind of what I had in mind when I started. May need some changes to cpufreq-dt driver. It currently loads OPPs from the default bindings unconditionally. Not sure if changing this would break anyone else. If we move/copy the right OPPs over to the cpu dt node (so we do runtime devicetree mangling) before the cpufreq driver loads there should be no need for changes to the cpufreq-dt driver. 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.
[linux-sunxi] Re: Mainline work status
Hi Chen-Yu, On Wed, Dec 24, 2014 at 11:29:26PM +0800, wens Tsai wrote: Hi everyone, As some of you might have noticed, I've sent out patches for A80 MMC and AXP20x. In addition, I've picked up Boris' AXP221 patches to resend after the AXP patches are merged. Thanks for your amazing work. The following is a list of things I'm working on or waiting to submit: - AXP20x (PEK and docs) series, originally by Carlo, posted v8 - AXP20x regulator driver cleanup, finished and tested What is left to be posted, besides the DT bits? - AXP221 support, originally by Boris, finished and tested * Also enables WiFi on the Hummingbird A31 There was some discussion since for some board (maybe the APP4) we had some circular dependency between the regulators exposed by the PMIC. Has that been taken care of? - sunxi (sun[457]i) cpufreq support, finished and testing (CB/CB2 tested) * Only added support for the boards I own. It's just a matter of adding the regulator nodes with the proper constraints Did you test individual OPPs or global ones (ie per-board or per-SoC)? Eventually, I'd like to have per-SoC OPPs. It doesn't seem that undoable from the spreadsheet I shared with you. - sun6i cpufreq support, WiP - sun8i cpufreq support, minimal work only - sun9i mmc support, posted v2 - sun9i usb support, v3 WiP - RSB driver, not working yet All the above, excluding RSB, can be found in my repository: https://github.com/wens/linux Each topic is a separate branch, except for the AXP branches, which have dependencies. Testing and feedback is more than welcome. Again, thanks a lot for your efforts. 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: Mainline work status
Hi, On Tue, Jan 6, 2015 at 12:15 AM, Maxime Ripard maxime.rip...@free-electrons.com wrote: Hi Chen-Yu, On Wed, Dec 24, 2014 at 11:29:26PM +0800, wens Tsai wrote: Hi everyone, As some of you might have noticed, I've sent out patches for A80 MMC and AXP20x. In addition, I've picked up Boris' AXP221 patches to resend after the AXP patches are merged. Thanks for your amazing work. The following is a list of things I'm working on or waiting to submit: - AXP20x (PEK and docs) series, originally by Carlo, posted v8 - AXP20x regulator driver cleanup, finished and tested What is left to be posted, besides the DT bits? This is actually getting rid of the DT parsing code in the regulator driver, and using common code in the regulator core added in 3.19-rc1. So this is new. - AXP221 support, originally by Boris, finished and tested * Also enables WiFi on the Hummingbird A31 There was some discussion since for some board (maybe the APP4) we had some circular dependency between the regulators exposed by the PMIC. Has that been taken care of? The work Boris has done on that doesn't mesh well with the previous item. For now I've dropped that bit. The dependency is ELDOs are powered from DCDC1, which is a fairly simple dependency. I think we can get around it by registering the DCDC ones first. - sunxi (sun[457]i) cpufreq support, finished and testing (CB/CB2 tested) * Only added support for the boards I own. It's just a matter of adding the regulator nodes with the proper constraints Did you test individual OPPs or global ones (ie per-board or per-SoC)? Eventually, I'd like to have per-SoC OPPs. It doesn't seem that undoable from the spreadsheet I shared with you. I've tested per-SoC OPPs with the boards I have using the hardware reliability test on the wiki [1]. Doing per-board OPPs should be as simple as overriding the OPP table in the board dts. As I will state in the series cover letter, for sun[457]i the OPPs are the same or very similar. For sun6i it is somewhat harder. [1] http://linux-sunxi.org/Hardware_Reliability_Tests#Reliability_of_cpufreq_voltage.2Ffrequency_settings - sun6i cpufreq support, WiP - sun8i cpufreq support, minimal work only - sun9i mmc support, posted v2 - sun9i usb support, v3 WiP - RSB driver, not working yet All the above, excluding RSB, can be found in my repository: https://github.com/wens/linux Each topic is a separate branch, except for the AXP branches, which have dependencies. Testing and feedback is more than welcome. Again, thanks a lot for your efforts. You're more than welcome. The work put in earlier by others shouldn't be left to waste. I'd like to see them through. :) Cheers 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.
