Re: [linux-sunxi] sunxi: Endless musb_bus_suspend warnings when booting A23 tablet with OTG
On Wed, Sep 7, 2016 at 6:44 PM, Hans de Goede wrote: > Hi, > > On 06-09-16 17:31, wens Tsai wrote: >> >> On Tue, Sep 6, 2016 at 7:28 PM, Hans de Goede wrote: >>> >>> Hi, >>> >>> On 06-09-16 13:02, wens Tsai wrote: >>>> >>>> >>>> Hi Hans, >>>> >>>> I've built the latest sunxi-next branches of Linux and U-boot and >>>> tried it on my Q8 A23 tablet. My tablet has an OTG adapter with a >>>> USB ethernet adapter connected all the time. Upon booting into >>>> Linux I get an endless stream of: >>>> >>>> musb_bus_suspend 2586: trying to suspend as a_wait_bcon while active >>>> >>>> messages. To get out of this I have to physically remove the OTG >>>> adapter. Booting without the OTG adapter to begin with also gets >>>> rid of the problem. >>>> >>>> Have you run into this problem? I wonder if we should disable VBUS >>>> just before leaving U-boot? Now that we support DRIVEVBUS this >>>> shouldn't be a problem. >>> >>> >>> >>> I've not seen such a problem. I'm fine with disabling Vbus when >>> leaving u-boot, that certainly is the safe thing to do anyways. >> >> >> Seems there's no distinction between "USB reset" and leaving >> U-boot, as you mentioned in your patch removing the "power off" >> code from the USB drivers. Are you OK with power cycling during >> USB reset as well? > > > I would prefer not too, but if it is hard to get around that > I can live with it. Unfortunately musb USB reset does not work. I tested without my patch (the one I sent out today). So I think this point is irrelevant, at least until someone fixes musb. ChenYu >> >>> I guess I'll get a u-boot patch from you if that indeed fixes >>> things ? >> >> >> Yup. In progress. Though my ethernet adapter is acting up, so I'll >> need to swap in something else to test it properly. > > > Cool. > > Thanks & 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] sunxi: Endless musb_bus_suspend warnings when booting A23 tablet with OTG
On Tue, Sep 6, 2016 at 7:28 PM, Hans de Goede wrote: > Hi, > > On 06-09-16 13:02, wens Tsai wrote: >> >> Hi Hans, >> >> I've built the latest sunxi-next branches of Linux and U-boot and >> tried it on my Q8 A23 tablet. My tablet has an OTG adapter with a >> USB ethernet adapter connected all the time. Upon booting into >> Linux I get an endless stream of: >> >> musb_bus_suspend 2586: trying to suspend as a_wait_bcon while active >> >> messages. To get out of this I have to physically remove the OTG >> adapter. Booting without the OTG adapter to begin with also gets >> rid of the problem. >> >> Have you run into this problem? I wonder if we should disable VBUS >> just before leaving U-boot? Now that we support DRIVEVBUS this >> shouldn't be a problem. > > > I've not seen such a problem. I'm fine with disabling Vbus when > leaving u-boot, that certainly is the safe thing to do anyways. Seems there's no distinction between "USB reset" and leaving U-boot, as you mentioned in your patch removing the "power off" code from the USB drivers. Are you OK with power cycling during USB reset as well? > I guess I'll get a u-boot patch from you if that indeed fixes > things ? Yup. In progress. Though my ethernet adapter is acting up, so I'll need to swap in something else to test it properly. 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] sunxi: Endless musb_bus_suspend warnings when booting A23 tablet with OTG
Hi Hans, I've built the latest sunxi-next branches of Linux and U-boot and tried it on my Q8 A23 tablet. My tablet has an OTG adapter with a USB ethernet adapter connected all the time. Upon booting into Linux I get an endless stream of: musb_bus_suspend 2586: trying to suspend as a_wait_bcon while active messages. To get out of this I have to physically remove the OTG adapter. Booting without the OTG adapter to begin with also gets rid of the problem. Have you run into this problem? I wonder if we should disable VBUS just before leaving U-boot? Now that we support DRIVEVBUS this shouldn't be a problem. 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] Latest U-boot branch not booting on Hummingbird A31
Hi Hans,
I updated U-boot on my boards to your latest sunxi-wip branch:
f965340 ("sunxi: Enable support for the eMMC found on the orangepi plus")
My Hummingbird A31 fails to boot after this. See log:
HELLO! BOOT0 is starting!
boot0 version : 3.0.0
reg_addr 0x01f00100 =0x
reg_addr 0x01f00104 =0x
reg_addr 0x01f00108 =0x
reg_addr 0x01f0010c =0x
reg_addr 0x01f00110 =0x
reg_addr 0x01f00114 =0x
[DRAM]ver 1.03 clk = 312
cpu 0 pmu 0
dram size =1024
sum=0x31776fa8
src_sum=0x31776fa8
Ready to disable icache.
Jump to secend Boot.
[ 0.209]
U-Boot 2011.09-rc1 (Jun 17 2014 - 17:30:56) Allwinner Technology
[ 0.217]version: 1.1.0
[ 0.220]pmbus: ready
[ 0.222]PMU: AXP221
[ 0.225]PMU: AXP22x found
[ 0.227]PMU: bat ratio = 100
[ 0.231]PMU: dcdc3 1260
[ 0.233]PMU: pll1 1008 Mhz
dcdc1_vol = 3000
dcdc2_vol = 1200
dcdc3_vol = 1260
dcdc4_vol = 1200
dcdc5_vol = 1500
aldo1_vol = 3000
aldo2_vol = 1800
aldo3_vol = 3000
eldo3_vol = 1800
find power_sply to end
fel key old mode
run key detect
no key found
no key input
dram_para_set start
dram_para_set end
[ 0.277]DRAM: 1 GiB
relocation Offset is: 15b25000
donn't initialize ther user_gpio (main_key:boot_init_gpio)
deu_mode1 not exist.
lcdgamma4iep for lcd1 not exist.
DRV_DISP_Init: opened
[ 0.542]fetch script data boot_disp.output_type fail
[ 0.547]fetch script data boot_disp.output_mode fail
[ 0.552]fetch script data boot_disp.auto_hpd fail
[ 0.557]lcd0_para.lcd_used=1
workmode = 0
[ 0.603]NAND: NAND_UbootInit
NB1 : enter NAND_LogicInit
not burn nand partition table!
NB1 : nftl num: 2
init nftl: 0
NB1 : NAND_LogicInit ok, result = 0x0
[ 1.268]sunxi flash init ok
probe mmc0 if exist
SUNXI SD/MMC: 0
Man 1d4144 Snr d3602657
SD
0.2
boot0 capacity: 0KB,boot1 capacity: 0KB
boot0 magic = eGON.BT0蜡讕
set next system status
DRV_DISP_Exit: closed
sunxi_board_close_source
NAND_UbootExit
NB1 : NAND_LogicExit
reset cpu
HELLO! BOOT0 is starting!
boot0 version : 3.0.0
reg_addr 0x01f00100 =0x7347
reg_addr 0x01f00104 =0x703b
reg_addr 0x01f00108 =0x5aa5a55a
reg_addr 0x01f0010c =0x00ff
reg_addr 0x01f00110 =0x00ff
reg_addr 0x01f00114 =0x00ff
eraly jump fel
U-Boot SPL 2016.03-00320-geeea041 (Mar 21 2016 - 15:16:34)
DRAM: 1024 MiB
Trying to boot from MMC1
and hangs...
geeea041 is the SinA31s patch I have on top of your sunxi-wip branch.
I bisected it down to 107fb76 ("sunxi: Fix gmac not working due to
cpu_eth_init no longer being called"). Not sure why this commit fails though.
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: Stability Issues with A33 & Mainline
On Tue, Dec 8, 2015 at 4:01 PM, Maxime Ripard wrote: > Hi, > > On Tue, Dec 01, 2015 at 10:11:51PM +0800, wens Tsai wrote: >> Hi, >> >> I'm having some weird stability issues with my SinA33. >> >> After idling a while (a few hours ~ a day) it becomes non-responsive >> and just keeps outputting the same message: >> >> [53418.712180] Task dump for CPU 0: >> [53418.715403] cronR running 0 1131 1 0x0003 >> [53418.721780] [] (__schedule) from [<2013>] (0x2013) >> [53496.741465] INFO: rcu_sched detected stalls on CPUs/tasks: >> [53496.746963] 0-...: (2 GPs behind) idle=ba3/141/0 >> softirq=127599/127600 fqs=369299 >> [53496.755646] (detected by 1, t=369437 jiffies, g=78644, c=78643, q=67) >> >> Maybe something is not getting enough power. >> >> Wondering if anyone else has seen similar problems? > > Last time I used mine, I couldn't see anything like this. > > Have you tried bisecting it? Not really. It's been running nicely for 3 days now. I only rearranged my wiring. Seems I'm the only one with this problem. I guess it's a hardware issue, a combination of my power supply and very loose UART pins. 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] Stability Issues with A33 & Mainline
Hi, I'm having some weird stability issues with my SinA33. After idling a while (a few hours ~ a day) it becomes non-responsive and just keeps outputting the same message: [53418.712180] Task dump for CPU 0: [53418.715403] cronR running 0 1131 1 0x0003 [53418.721780] [] (__schedule) from [<2013>] (0x2013) [53496.741465] INFO: rcu_sched detected stalls on CPUs/tasks: [53496.746963] 0-...: (2 GPs behind) idle=ba3/141/0 softirq=127599/127600 fqs=369299 [53496.755646] (detected by 1, t=369437 jiffies, g=78644, c=78643, q=67) Maybe something is not getting enough power. Wondering if anyone else has seen similar problems? 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] PSCI for H3
Hi everyone, I got my Orange Pi PC booting U-boot now, using Hans' sunxi-wip branch that includes Jens' patches. For PSCI and SMP, it seems the H3 follows the structure of previous sun8i SoCs. The CPUCFG registers line up. The manual doesn't have the PRCM, so I'll have to dig through the SDK. One other thing is the SMTA, or Secure Memory Touch Arbiter, which we last encountered issues with on the A31s. This controls non-secure access to a whole bunch of peripherals, which we'll need to enable for Linux to run non-secure. Anyway, this is just a preliminary evaluation of the work needed for PSCI. Nothing has actually been done or tested. 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.
Re: [linux-sunxi] DCDC2 (VDD-SYS) voltage for A23/A33?
On Fri, Oct 9, 2015 at 4:56 PM, Maxime Ripard wrote: > On Wed, Oct 07, 2015 at 12:43:13AM +0800, wens Tsai wrote: >> >> On the side, I'm wondering if we can put the voltage ranges for >> >> important regulators directly in the axp dtsi. It's likely most >> >> boards follow the reference design, and will use the regulators >> >> accordingly. >> >> >> >> We could also do this for A31/A31s paired with AXP221/AXP221s. >> >> Since I already have a patch for axp221.dtsi, I can incorporate >> >> the changes. >> > >> > That doesn't really work unfortunately. We're seeing some combination >> > of the PMICs and the SoCs that have different boundaries, for example, >> > while the AXP209 is used on the A10 and A20 that have an upper >> > boundary of 1.4V for the CPU regulator, while it's also used with the >> > R8 that has a limit at 1.3V. >> >> I understand. I'm just saying it's doable for the A31/AXP221 pair, >> and the AXP223/A23/A33 pairs. I think we won't be seeing new chips >> paired with them. The A80 and A83 both have their own companion >> PMICs, and the H3 doesn't seem to use one in designs we've seen. >> The A31 and A31s have the same tolerances, as do the A23 and A33. > > Thing is, we can probably expect the same behaviour when the R* and H* > designs will be out. > > I'd really just prefer to leave the glue between the PMIC and the SoC > in the board DTS, and not make any assumption about what PMIC is > associated with what SoC in the DTSI. Got it. Hopefully I'll send out the conversion patches today. 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] DCDC2 (VDD-SYS) voltage for A23/A33?
On Tue, Oct 6, 2015 at 11:34 PM, Maxime Ripard wrote: > On Tue, Oct 06, 2015 at 12:19:43AM +0800, wens Tsai wrote: >> On Thu, Oct 1, 2015 at 6:13 PM, Maxime Ripard >> wrote: >> > On Wed, Sep 30, 2015 at 12:42:43PM +0200, Hans de Goede wrote: >> >> Hi, >> >> >> >> On 30-09-15 03:52, wens Tsai wrote: >> >> >Hi, >> >> > >> >> >I've been looking into AXP223 usage as part of the RSB patches. >> >> >I found that the recommended voltage for VDD-SYS is 1.1V, but >> >> >we default to 1.2V in U-boot. Among the fex files, some use >> >> >1.1V and some use 1.2V. >> >> >> >> Right, I happened to be looking the same thing recently. >> >> >> >> I've recently bought a bunch of 2nd hand q8 tablets, and I've >> >> pushed all the fex files I got from them to sunxi-boards yesterday. >> >> >> >> Looking at A23 devices only the ippo_q8h_v1.0.fex and >> >> ippo_q8h_v1.2.fex files set VDD-SYS to 1.2 volt, the other >> >> 7 use the recommended 1.1V value. Also note that the gt90h-v4 >> >> tablet which I have does not work with a VDD-SYS of 1.2 volt, >> >> it only works with a VDD-SYS of 1.1 volt. >> >> >> >> I've tested my ippo_q8h_v1.2 and it works fine with a VDD-SYS >> >> of 1.1 volt. >> >> >> >> Looking at A33 devices there are 2 outliers the TZX-723Qa4 and >> >> astar_mid756.fex both set VDD-SYS to 1.26 V, rather then to 1.1 V. >> >> The other 6 all use 1.1V so I believe that 1.1V indeed is a better >> >> default. >> >> >> >> >Perhaps we could update the defconfigs with the values from >> >> >the fex files. >> >> >> >> I think that we should switch the default to 1.1V and then if we see >> >> any issues set it to 1.2V in individual defconfig-s. >> > >> > Agreed. >> > >> >> >One thing that we have to be careful of is matching the settings >> >> >in U-boot and the kernel, or alternatively, not use a fixed value >> >> >but the recommended range for the VDD-SYS regulator. Accidentally >> >> >dropping the voltage on VDD-SYS results in some logic errors, >> >> >which likely lead to a crash. >> >> >> >> I think it is best to set a range in the dts file and the kernel >> >> just inherit whatever u-boot has set up, this way we don't end >> >> up changing vdd-sys half-way through boot, and we only have one >> >> place where to tweak it if necessary. >> > >> > And here too :) >> >> Sounds good. >> >> On the side, I'm wondering if we can put the voltage ranges for >> important regulators directly in the axp dtsi. It's likely most >> boards follow the reference design, and will use the regulators >> accordingly. >> >> We could also do this for A31/A31s paired with AXP221/AXP221s. >> Since I already have a patch for axp221.dtsi, I can incorporate >> the changes. > > That doesn't really work unfortunately. We're seeing some combination > of the PMICs and the SoCs that have different boundaries, for example, > while the AXP209 is used on the A10 and A20 that have an upper > boundary of 1.4V for the CPU regulator, while it's also used with the > R8 that has a limit at 1.3V. I understand. I'm just saying it's doable for the A31/AXP221 pair, and the AXP223/A23/A33 pairs. I think we won't be seeing new chips paired with them. The A80 and A83 both have their own companion PMICs, and the H3 doesn't seem to use one in designs we've seen. The A31 and A31s have the same tolerances, as do the A23 and A33. 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] DCDC2 (VDD-SYS) voltage for A23/A33?
On Thu, Oct 1, 2015 at 6:13 PM, Maxime Ripard wrote: > On Wed, Sep 30, 2015 at 12:42:43PM +0200, Hans de Goede wrote: >> Hi, >> >> On 30-09-15 03:52, wens Tsai wrote: >> >Hi, >> > >> >I've been looking into AXP223 usage as part of the RSB patches. >> >I found that the recommended voltage for VDD-SYS is 1.1V, but >> >we default to 1.2V in U-boot. Among the fex files, some use >> >1.1V and some use 1.2V. >> >> Right, I happened to be looking the same thing recently. >> >> I've recently bought a bunch of 2nd hand q8 tablets, and I've >> pushed all the fex files I got from them to sunxi-boards yesterday. >> >> Looking at A23 devices only the ippo_q8h_v1.0.fex and >> ippo_q8h_v1.2.fex files set VDD-SYS to 1.2 volt, the other >> 7 use the recommended 1.1V value. Also note that the gt90h-v4 >> tablet which I have does not work with a VDD-SYS of 1.2 volt, >> it only works with a VDD-SYS of 1.1 volt. >> >> I've tested my ippo_q8h_v1.2 and it works fine with a VDD-SYS >> of 1.1 volt. >> >> Looking at A33 devices there are 2 outliers the TZX-723Qa4 and >> astar_mid756.fex both set VDD-SYS to 1.26 V, rather then to 1.1 V. >> The other 6 all use 1.1V so I believe that 1.1V indeed is a better >> default. >> >> >Perhaps we could update the defconfigs with the values from >> >the fex files. >> >> I think that we should switch the default to 1.1V and then if we see >> any issues set it to 1.2V in individual defconfig-s. > > Agreed. > >> >One thing that we have to be careful of is matching the settings >> >in U-boot and the kernel, or alternatively, not use a fixed value >> >but the recommended range for the VDD-SYS regulator. Accidentally >> >dropping the voltage on VDD-SYS results in some logic errors, >> >which likely lead to a crash. >> >> I think it is best to set a range in the dts file and the kernel >> just inherit whatever u-boot has set up, this way we don't end >> up changing vdd-sys half-way through boot, and we only have one >> place where to tweak it if necessary. > > And here too :) Sounds good. On the side, I'm wondering if we can put the voltage ranges for important regulators directly in the axp dtsi. It's likely most boards follow the reference design, and will use the regulators accordingly. We could also do this for A31/A31s paired with AXP221/AXP221s. Since I already have a patch for axp221.dtsi, I can incorporate the changes. Let me know what you think. 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] DCDC2 (VDD-SYS) voltage for A23/A33?
Hi, I've been looking into AXP223 usage as part of the RSB patches. I found that the recommended voltage for VDD-SYS is 1.1V, but we default to 1.2V in U-boot. Among the fex files, some use 1.1V and some use 1.2V. Perhaps we could update the defconfigs with the values from the fex files. One thing that we have to be careful of is matching the settings in U-boot and the kernel, or alternatively, not use a fixed value but the recommended range for the VDD-SYS regulator. Accidentally dropping the voltage on VDD-SYS results in some logic errors, which likely lead to a crash. 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] [u-boot] PMIC init failure on A33?
Hi, I'm seeing PMIC (AXP22x) init failures on my A33 boards. On my SinA33 it fails to set the RSB runtime address for the AXP223. As a result, the CPU is running at the default frequency of 408 MHz, instead of full speed. Wonder if anyone else is seeing these failures? Also I can't get my Q8H v1.5 A33 tablet's LCD screen to display anything. It's just completely white. Any ideas? Thanks 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] Mainline U-boot wiki page updated
Hi, I've updated the wiki page with all the new U-boot releases, as well as the latest stuff planned for v2015.07. I might have missed something, so a second set of eyes would be nice. 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
Hi everyone, On Wed, Dec 24, 2014 at 11:29 PM, 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. 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 9, 2015 at 5:47 PM, Hans de Goede 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: >>>>> >>>>> >>>>> >>>>> >>>>>>> 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
On Fri, Jan 9, 2015 at 4:30 PM, Maxime Ripard 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 >> 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: ARM: dts: sunxi: A20-OlinuXino-Lime2 raise dcdc2 lower voltage limit
On Thu, Jan 8, 2015 at 6:21 AM, Iain Paton wrote:
> The Lime2 is not stable if the cpu core voltage is reduced below 1v. To
> prevent any problems when operating points are enabled, raise the pmic dcdc2
> lower voltage limit to 1v.
>
> Signed-off-by: Iain Paton
> ---
>
> Maxime, I realise the axp209 nodes will probably end up abstracted somewhat
> differently once all of the patches Chen-Yu posted are reviewed and picked
> up and I can redo the lime2 dts to fit once that's done.
> For now, the lime2 dts defines the full axp209 node itself including all of
> the regulators, so if the lowest opp with the 0.9v setting is enabled this
> will cause problems.
>
> Up to you if you want to take this patch now or we wait until the axp209.dtsi
> lands and refactor the lime2 dts appropriately then.
>
> arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts
> b/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts
> index ed364d5..910318a 100644
> --- a/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts
> +++ b/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts
> @@ -159,7 +159,7 @@
> };
>
> vdd_cpu: dcdc2 {
> - regulator-min-microvolt =
> <70>;
> + regulator-min-microvolt =
> <100>;
> regulator-max-microvolt =
> <2275000>;
You should lower the maximum voltage as well, either in this patch
or when you redo all the regulators. AFAIK the SoC certainly cannot
take up to 2.275V. The regulator nodes are supposed to say what
the board can handle.
ChenYu
> regulator-always-on;
> };
> --
> 2.1.3
>
--
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] Mainline work status
Hi, On Thu, Jan 8, 2015 at 6:21 AM, Iain Paton wrote: > On 24/12/14 15:29, wens Tsai wrote: > >> - AXP20x (PEK and docs) series, originally by Carlo, posted v8 >> - AXP20x regulator driver cleanup, finished and tested >> - AXP221 support, originally by Boris, finished and tested >> * Also enables WiFi on the Hummingbird A31 >> - 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 > > Hi, > > I've been testing your patches with a20 olinuxino lime2 & a10 lime > > I notice your cpu opp data reduces the voltage down to 0.9v for the lowest > frequency, but all of the regulator nodes you added for cubieboard cubietruck > etc, have the lower limit set to 1v. Did you test 0.9v on anything? Not before. The assumption was that we provide a generic set of OPPs. Board files then decide which ones are actually usable via regulator constraints. > The lime2 dts currently has 0.7v as the lower limit for dcdc2 and when it's > dropped to an opp with cpu core voltage set to 0.9v the board starts crashing > randomly very soon after. I just tested my cubieboard2, and it crashes as soon as the voltage is lowered to 0.9v by cpufrequtils. 0.9v is below the recommended voltage range for VDD-CPU, according to the datasheet. Running my board at 144 MHz / 1.0v seems fine though. > I'll post a patch shortly to raise the lime2 dcdc2 lower limit to 1v, but > I think it's probably worth collecting some more data on how many boards > will really be able to use that 0.9v setting. I can increase the voltage setting for 144 MHz to 1.0v in the dtsi. This brings out additional problems though. The clock driver doesn't support re-calculating the dividers ATM. So when the cpu clock is at 144 MHz, the ahb clocks run at 24 MHz, which IIRC is too slow for USB. Maybe I just remove it from the OPP set for the time being. > With the exception of altering the dcdc2 limits, I've not encountered any > other problems. Thanks for the feedback! 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 Tue, Jan 6, 2015 at 12:15 AM, Maxime Ripard 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.
[linux-sunxi] Mainline work status
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: - AXP20x (PEK and docs) series, originally by Carlo, posted v8 - AXP20x regulator driver cleanup, finished and tested - AXP221 support, originally by Boris, finished and tested * Also enables WiFi on the Hummingbird A31 - 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 - 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. 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: Raise DCDC1 Voltage on sun6i?
On Mon, Dec 1, 2014 at 4:13 PM, Hans de Goede wrote: > On 12/01/2014 03:00 AM, wens Tsai wrote: >> On Fri, Nov 28, 2014 at 7:50 PM, Hans de Goede wrote: >>> On 11/28/2014 10:20 AM, wens Tsai wrote: >>>> >>>> >>>> Hi Hans, >>>> >>>> Thanks for completing SPL support on the A31. >>>> I've managed to boot mainline U-boot on my Hummingbird A31. >>>> >>>> One issue I ran into is that with DCDC1 set at 3.0V, >>>> mmc0 is very unstable in the kernel. All operations >>>> timeout and the kernel panics because the rootfs isn't >>>> available. >>>> >>>> Raising the voltage to 3.3V gets rid of the problem, >>>> but I'm not sure that is the correct solution. >>> >>> >>> >>> The fex file for the mele boards says dcdc1 should be 3.3V not >>> 3.0V and that makes sense really, since 3.3V is a standard >>> voltage, while 3.0V is not. >>> >>> However the fex file for the Hummingbird says 3.0V and my >>> Mele M9 works fine with the current u-boot setting of 3.0V. >>> >>> I've just booted my M9 into the original firmware and that is >>> actually using 3.3V so changing things to 3.3V does seem to >>> be the right thing. >>> >>> Maxime, I seem to remember you telling me that the Colombus >>> is really using 3.0V. >>> >>> Maxime can you confirm this? Is that routed to the mmc power ? >>> >>> It could be that 3.0V is enough for the A31 itself, but that >>> on boards which do not have a separate power-supply for the >>> mmc 3.3V is used ? >>> >>> I'm fine with moving to 3.3V, I'm wondering if we should >>> make it configurable like the DLDO# and ALDO# voltages, >>> see drivers/power/Kconfig, with a 3.3V voltage and an >>> override in the Colombus defconfig ? >>> >>> ChenYu, can you check which voltage the original firmware >>> is actually using ? You should see boot1 printing the >>> voltage, and you can check it from a root shell by doing: >> >> >> This is during boot: >> >> U-Boot 2011.09-rc1 (Jun 17 2014 - 17:30:56) Allwinner Technology >> >> [ 0.213]version: 1.1.0 >> [ 0.216]pmbus: ready >> [ 0.218]PMU: AXP221 >> [ 0.220]PMU: AXP22x found >> [ 0.223]PMU: bat ratio = 100 >> [ 0.226]PMU: dcdc3 1260 >> [ 0.229]PMU: pll1 1008 Mhz >> dcdc1_vol = 3000 >> dcdc2_vol = 1200 >> dcdc3_vol = 1260 >> dcdc4_vol = 1200 >> dcdc5_vol = 1500 >> aldo1_vol = 3000 >> aldo2_vol = 1800 >> aldo3_vol = 3000 >> eldo3_vol = 1800 >> >>> cat /sys/class/regulator/regulator.13/name >>> cat /sys/class/regulator/regulator.13/microvolts >>> >>> (The first one is just to check your regulators are numbered >>> the same). >> >> >> This is just a dump of all the regulators from the firmware: >> >> axp22_DCDC1 300 enabled >> axp22_DCDC2 120 enabled >> axp22_DCDC3 126 enabled >> axp22_DCDC4 120 enabled >> axp22_DCDC5 150 enabled >> axp22_ldoio0 280 disabled >> axp22_ldoio1 180 enabled >> axp22_ldo1 300 enabled >> axp22_ldo2 330 enabled >> axp22_ldo3 180 enabled >> axp22_ldo4 300 enabled >> axp22_ldo570 disabled >> axp22_ldo670 disabled >> axp22_ldo7 280 disabled >> axp22_ldo8 280 enabled >> axp22_ldo9 150 disabled >> axp22_ldo10 70 disabled >> axp22_ldo11 180 disabled >> axp22_ldo12 110 enabled >> >> As you can see it is indeed set to 3.0V. And it does work. >> So I'm kind of confused. Plus 3.0V doesn't seem to be a valid >> I/O voltage level for SD/MMC. > > > I/O voltage yes, but what if DCDC1 is used to power the card too ? According to the schematic, the DCDC1 rail is used to power most things running on 3V ~ 3.3V, such as MMC card power, NAND, Ethernet PHY, LRADC, and some of the internal blocks like headphone amp, HDMI, MIPI PHYs and most of the I/O ports (a few aren't). The USB block which should be 3.3V has a discrete 3.0V fixed regulator. VCC-PLL for the clock generator and AVCC for the analog bits are 3.0V. These are hooked up to ALDO3. I think having DCDC1 at 3.3V is the correct setting. > And maybe the firmware is using one of the low voltage modes which > we do not support in the upstream kernel ? Low voltage setting for MMC I/O le
[linux-sunxi] Re: Raise DCDC1 Voltage on sun6i?
Hi, On Fri, Nov 28, 2014 at 7:50 PM, Hans de Goede wrote: > Hi ChenYu, > > On 11/28/2014 10:20 AM, wens Tsai wrote: >> >> Hi Hans, >> >> Thanks for completing SPL support on the A31. >> I've managed to boot mainline U-boot on my Hummingbird A31. >> >> One issue I ran into is that with DCDC1 set at 3.0V, >> mmc0 is very unstable in the kernel. All operations >> timeout and the kernel panics because the rootfs isn't >> available. >> >> Raising the voltage to 3.3V gets rid of the problem, >> but I'm not sure that is the correct solution. > > > The fex file for the mele boards says dcdc1 should be 3.3V not > 3.0V and that makes sense really, since 3.3V is a standard > voltage, while 3.0V is not. > > However the fex file for the Hummingbird says 3.0V and my > Mele M9 works fine with the current u-boot setting of 3.0V. > > I've just booted my M9 into the original firmware and that is > actually using 3.3V so changing things to 3.3V does seem to > be the right thing. > > Maxime, I seem to remember you telling me that the Colombus > is really using 3.0V. > > Maxime can you confirm this? Is that routed to the mmc power ? > > It could be that 3.0V is enough for the A31 itself, but that > on boards which do not have a separate power-supply for the > mmc 3.3V is used ? > > I'm fine with moving to 3.3V, I'm wondering if we should > make it configurable like the DLDO# and ALDO# voltages, > see drivers/power/Kconfig, with a 3.3V voltage and an > override in the Colombus defconfig ? > > ChenYu, can you check which voltage the original firmware > is actually using ? You should see boot1 printing the > voltage, and you can check it from a root shell by doing: This is during boot: U-Boot 2011.09-rc1 (Jun 17 2014 - 17:30:56) Allwinner Technology [ 0.213]version: 1.1.0 [ 0.216]pmbus: ready [ 0.218]PMU: AXP221 [ 0.220]PMU: AXP22x found [ 0.223]PMU: bat ratio = 100 [ 0.226]PMU: dcdc3 1260 [ 0.229]PMU: pll1 1008 Mhz dcdc1_vol = 3000 dcdc2_vol = 1200 dcdc3_vol = 1260 dcdc4_vol = 1200 dcdc5_vol = 1500 aldo1_vol = 3000 aldo2_vol = 1800 aldo3_vol = 3000 eldo3_vol = 1800 > cat /sys/class/regulator/regulator.13/name > cat /sys/class/regulator/regulator.13/microvolts > > (The first one is just to check your regulators are numbered > the same). This is just a dump of all the regulators from the firmware: axp22_DCDC1 300 enabled axp22_DCDC2 120 enabled axp22_DCDC3 126 enabled axp22_DCDC4 120 enabled axp22_DCDC5 150 enabled axp22_ldoio0 280 disabled axp22_ldoio1 180 enabled axp22_ldo1 300 enabled axp22_ldo2 330 enabled axp22_ldo3 180 enabled axp22_ldo4 300 enabled axp22_ldo570 disabled axp22_ldo670 disabled axp22_ldo7 280 disabled axp22_ldo8 280 enabled axp22_ldo9 150 disabled axp22_ldo10 70 disabled axp22_ldo11 180 disabled axp22_ldo12 110 enabled As you can see it is indeed set to 3.0V. And it does work. So I'm kind of confused. Plus 3.0V doesn't seem to be a valid I/O voltage level for SD/MMC. BTW, I see you're working on RSB support for U-boot. Thanks in advance. 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] Raise DCDC1 Voltage on sun6i?
Hi Hans, Thanks for completing SPL support on the A31. I've managed to boot mainline U-boot on my Hummingbird A31. One issue I ran into is that with DCDC1 set at 3.0V, mmc0 is very unstable in the kernel. All operations timeout and the kernel panics because the rootfs isn't available. Raising the voltage to 3.3V gets rid of the problem, but I'm not sure that is the correct solution. Did you encounter something like this? I remember you sending a patch for u-boot-sunxi some time ago for something like this. Regards, ChenYu Tsai -- 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.
