Re: [linux-sunxi] A31s chipset support
Hi All, On Mon, Sep 29, 2014 at 3:23 PM, Siarhei Siamashka wrote: > On Thu, 18 Sep 2014 09:36:55 +1000 > Julian Calaby wrote: > >> Hi, >> >> Earlier this year, HP released the following three tablets: >> (Australian store links due to the specifications listing the SoC's >> name) >> >> HP 7 Plus: >> http://h20386.www2.hp.com/AustraliaStore/Product.aspx?pdetail=P333853 >> HP 8: http://h20386.www2.hp.com/AustraliaStore/Product.aspx?pdetail=P327832 >> HP 10 Plus: >> http://h20386.www2.hp.com/AustraliaStore/Product.aspx?pdetail=P339093 >> >> All of which appear to be based around the A31s SoC. >> >> As they're pretty cheap for a "big name" brand's tablets, I'm planning >> to obtain one. >> >> Has anyone else laid hands on any A31s devices yet? And if so, has any >> work started on supporting them? I bought a 7 Plus over the weekend, and apart from dismal battery life it's a significant improvement on my crappy A10 tablet (iNet 3FBT in a Kogan Agora) The Android install on it feels just like my partner's Asus TF300. It appears to be a disguised version of Allwinner's 4.2.2 (Jellybean) Android version as there's a couple of little details that remind me of my A10 tablet: The most obvious is the notifications for plugging, mounting and removing USB devices or microSD cards are very basic. More subtle is that if you hold either of them diagonally by one of their top corners, angled 45 degrees away from you, they do something weird: the Agora can't figure out it's orientation, the 7 Plus emits a long string of key presses that confuse Google Play Store. Processor: QuadCore-A7 Model Number: HP 7 Plus Android Version: 4.2.2 Kernel Version: 3.3.0 zhangaiguo@SzExdroid10 #44 Tue Mar 25 14:15:51 CST 2014 Build Number: 1.1.5_WW-ILEX-13 Shockingly, it can mount thumb drives connected through an OTG cable to the micro-USB port. Frustratingly, it can't decide if the volume down button is a back button or not. It's also not pre-rooted. > I also have started considering to get an Allwinner based tablet > since a couple of weeks ago. So far all my devices are just various > development boards and one Mele TV box, which is not very different > from a development board in terms of features. > > The first attempt was a failure. I tried to buy a relatively cheap 10" > no-name tablet (but with HDMI and 1GB of RAM), which was advertised > as Allwinner A20 by the seller. But it turned out to be in fact using > an Actions ATM7029B SoC with a quad-core Cortex-A5 CPU (disguised > as "Leopard Gen.I CPU core"). Big disappointment! And a total loss > of trust in this method of obtaining hardware. Though even if the > SoC was the right one, the build quality leaves a lot to be desired > and the screen is just horrible (colors and viewing angles). Maybe > other people had better experience, but I'm not going this route > again. > > So now I'm also trying the "big name" brand buying strategy for a > change :-) The HP tablets look nice, but they don't have a HDMI > connector, which is a deal breaker for me. Another alternative are > some nice tablets from MSI. More specifically, these ones: > http://www.msi.com/product/windpad/Primo_73.html#hero-specification > http://www.msi.com/product/windpad/Primo_81.html#hero-specification > On a negative side, just like HP tablets, they have no bluetooth and > no dedicated charger connector. Primo 73 has a TN display (potentially > worse quality) and the Allwiner A20 SoC (worse performance than A31s, > but better support in linux-sunxi and no PowerVR). > > HP provides nice service manuals for their tablets, for example > one can google for "HP 7 Plus Tablet and HP 7.1 Tablet Maintenance > and Service Guide". Which provides detailed instructions about how > to take them apart and replace components. It is interesting that > this HP 7 Plus tablet is supposed to be equipped with 1.0-GB > LP-DDR2 (!) memory. If anyone has this hardware and can extract > the FEX file, it would be extremely interesting. Sadly the instructions in that document aren't sufficient (or I'm not skilled / intelligent enough) to actually open the device. I followed the instructions but couldn't complete step 2 (prying up the display assembly) as it simply wouldn't lift and I am unwilling to bend the glass any more than I already have. I'll try to obtain a proper plastic opening tool and try again. The versions of that manual (one of which you can download from HP's own website) imply that this tablet is known by the following names: - HP 7 Plus 1301 - Compaq 7 Plus 1301 - HP 7.1 1201 - Compaq 7.1 1201 The 7.1 has a different back case and a TN LCD panel instead of an IPS one. > Regarding vendor firmware. MSI offers PhoenixSuite images for download > and also kernel sources from their website. This is very nice and > reassures the availability of FEL support for unbricking. > HP only provides updates as "update.zip" files to be copied on > the device and taken into use from the "android recovery" menu. > Not
[linux-sunxi] Re: Announcing u-boot with full A31 support
On 11/02/2014 07:44 PM, Hans de Goede wrote: > Hi, > > On 11/02/2014 06:46 PM, Henrik Nordström wrote: >> sön 2014-11-02 klockan 17:06 +0100 skrev Hans de Goede: >> >>> I still need to cleanup the axp221 and p2wi patches a bit, and then I'll >>> post >>> the entire series for review. >> >> Is this the reason why PLL1 configuration is still disabled in the patch >> set? > > No that is another item which I need to fix, basically I need to check if I > can > re-use the pll1 setting code from sun4i, and if not write new code for sun6i, > so > the plan for v1 of the patch-set is to not make any pll1 changes for now. > > Fixing the pll1 stuff is high on my priority list, but there are only so > much hours in day... Ok, so I've decided to take a shot at this, and this is fixed now, and I've also done the p2wi driver cleanup I wanted to do, so all that is left now is some cleanup of the axp221 driver, and then I'll post the set for review. 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] Announcing u-boot with full A31 support
Hi, On 11/02/2014 06:46 PM, Henrik Nordström wrote: > sön 2014-11-02 klockan 17:06 +0100 skrev Hans de Goede: > >> I still need to cleanup the axp221 and p2wi patches a bit, and then I'll post >> the entire series for review. > > Is this the reason why PLL1 configuration is still disabled in the patch > set? No that is another item which I need to fix, basically I need to check if I can re-use the pll1 setting code from sun4i, and if not write new code for sun6i, so the plan for v1 of the patch-set is to not make any pll1 changes for now. Fixing the pll1 stuff is high on my priority list, but there are only so much hours in day... 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] Announcing u-boot with full A31 support
sön 2014-11-02 klockan 17:06 +0100 skrev Hans de Goede: > I still need to cleanup the axp221 and p2wi patches a bit, and then I'll post > the entire series for review. Is this the reason why PLL1 configuration is still disabled in the patch set? Regards Henrik -- 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] WLAN "SBE error": any news?
Hello. Running mainline kernel from Arch Linux ARM on a Cubietruck I have to say the so called SBE error [0] makes the on-chip WLAN interface unusable. My findings strongly suggest there's some kind of "load threshold": if only few data is transferred the link remains stable for hours. But the problem can reproducibly be triggered by larger amounts of data. If e. g. some large file gets downloaded, the error will always arise once the download has been going on for some seconds. That threshold seems to be slightly higher in 802.11n than in 802.11g mode. On a side note APs operating in 5GHz band can't even seem to be detected. But that's all I could figure out. So I was wondering whether there's any news about this problem or even a workaround. Obviously I'd be willing to perform further tests but needed some advice on how to do this. Regards, Peter Mattern [0] https://groups.google.com/d/msg/linux-sunxi/NngIhT-ELVc/Q2pt3UdrE-sJ -- 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] Announcing u-boot with full A31 support
Hi, After spending a lot of time on this, I'm happy to announce that I now have an upstream u-boot based tree with patches adding A31 dram init and SPL support, allowing one to boot Allwinner A31 boards using just u-boot for all stages of the boot :) You can find my work on this here: https://github.com/jwrdegoede/u-boot-sunxi/tree/sunxi-wip Building + install works exactly the same as for the A10 / A13 / A20. I still need to cleanup the axp221 and p2wi patches a bit, and then I'll post the entire series for review. 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: [PATCH v4 0/5] simplefb: add clock handling code
On Fri, Oct 31, 2014 at 4:47 PM, Rob Herring wrote: > > On Wed, Oct 29, 2014 at 7:08 PM, Tomi Valkeinen wrote: > > Hi Hans, Rob, > > > > On 28/10/14 13:30, Hans de Goede wrote: > >> Hi, > >> > >> On 10/28/2014 12:11 PM, Rob Herring wrote: > > > >>> Yes, I object to the binding still as it has not changed from what was > >>> previously posted. > >> > >> It would be helpful if you could explain why you object. Last time you > >> said: " You are mixing in a hardware description that is simply > >> inaccurate." > >> > >> I then explained that this is not hardware description, but runtime state > >> information, as it tells the kernel which clocks were chosen to drive the > >> display (out of typically a list of possible options, depending on which > >> output is used, etc.). Just like which memory address the bootloader has > >> chosen to scan out the video image from. > >> > >> Then you got quiet, so sorry, but this time your objection really is too > >> late. You cannot simply go quiet halfway through a discussion and then pop > >> up again when a new version is posted to say "I object" yet another time, > >> you've had your chance to make your arguments last time, and chose to stay > >> quiet after I explained in detail that this is not hardware description but > >> state information, so now it is simply too late. > >> > >> These bindings have been discussed at Plumbers with various interested > >> people > >> present, and the conclusion was that this really is the best way to handle > >> this, > >> so this patch is: > >> > >> Signed-off-by: Hans de Goede > >> Reviewed-by: Mike Turquette > >> Acked-by: Geert Uytterhoeven > >> Reviewed-by: Maxime Ripard > >> > >> And David Herrman who is working on simpledrm, which will be merged soon, > >> which > >> will also use the simplefb bindings also agrees. So we have the simplefb > >> maintainer, > >> simpledrm maintainer, and the clk subsystem maintainer + 2 other > >> maintainers all > >> agreeing on a way forward, the time for bikeshedding now really really > >> really is > >> over. > >> > >> Tomi, can you please let us know how you plan to proceed with this ? > > > > I won't merge DT bindings via fbdev tree, if a DT maintainer says no. > > > > I took Rob's silence to the earlier series as a silent ack for your > > explanation. Obviously that was not the case. > > > > Rob, please advice asap what should be done to the bindings to get your > > ack. As Hans explained above, this discussion has been going on for a > > long time, and afaik this series is the best way forward of all the > > options discussed. > > I still think for the most part this is a kernel problem. It is a > kernel policy to turn off unused clocks. The clock framework could > just as easily decide that any clocks enabled at boot and left > un-managed (i.e. w/o a driver) are kept on until they are managed. I'm > not saying this can't be in DT, only that DT is not the only solution > here. This problem is not unique to simplefb. A serial console could > stop working if no serial driver is loaded before unused clocks are > disabled. CPU core clocks have a similar issue as well (often enabled > in platform code). I want to see this solved in a generic way for any > clock. I am in agreement this point of view. This is a problem in the Linux kernel. It is not a generic problem. The Linux problem is that during boot device drivers are loaded in two phases - built-in and loadable modules. The clock-regulator clean up is happening too early. It happens after the built-in drivers load and before the loadable modules have a chance to load. That's simply the wrong place for that clean up happen. A simple alternative would be to make a tiny loadable module that triggers the clean up. Then adjust your boot scripts to load this module after the other ones have loaded. But instead of fixing this simple timing flaw in the Linux boot process a complex mechanism is being created to work around it. Simplefb is also being developed as a way of protecting the BIOS setup of the framebuffer past the boot process and out into use as a normal user space console. I in no way support this use. We have experienced decades of problems on the x86 with VGA and BIOSes that I do not wish to repeat in the ARM world. Write a correct, device specific framebuffer driver for this piece of hardware. That device specific driver will load before the clock/regulator cleanup and claim all of the correct resources. > > > As regulators were also mentioned, they already have a > "regulator-boot-on" property defined. Perhaps this is suitable to be > mirrored for clocks. If it is not, then I'm wondering why we have it. > A key difference here is that the property is part of the provider and > can be dealt with in the clock driver rather than requiring a > temporary driver. > > Rob > > -- > You received this message because you are subscribed to the Google Groups > "linux-sunxi" group. > To unsubscribe from
Re: [linux-sunxi] Re: [PATCH v4 0/5] simplefb: add clock handling code
On Fri, Oct 31, 2014 at 4:47 PM, Rob Herring wrote: > On Wed, Oct 29, 2014 at 7:08 PM, Tomi Valkeinen > wrote: > > Hi Hans, Rob, > > > > On 28/10/14 13:30, Hans de Goede wrote: > >> Hi, > >> > >> On 10/28/2014 12:11 PM, Rob Herring wrote: > > > >>> Yes, I object to the binding still as it has not changed from what was > >>> previously posted. > >> > >> It would be helpful if you could explain why you object. Last time you > >> said: " You are mixing in a hardware description that is simply > inaccurate." > >> > >> I then explained that this is not hardware description, but runtime > state > >> information, as it tells the kernel which clocks were chosen to drive > the > >> display (out of typically a list of possible options, depending on which > >> output is used, etc.). Just like which memory address the bootloader has > >> chosen to scan out the video image from. > >> > >> Then you got quiet, so sorry, but this time your objection really is too > >> late. You cannot simply go quiet halfway through a discussion and then > pop > >> up again when a new version is posted to say "I object" yet another > time, > >> you've had your chance to make your arguments last time, and chose to > stay > >> quiet after I explained in detail that this is not hardware description > but > >> state information, so now it is simply too late. > >> > >> These bindings have been discussed at Plumbers with various interested > people > >> present, and the conclusion was that this really is the best way to > handle this, > >> so this patch is: > >> > >> Signed-off-by: Hans de Goede > >> Reviewed-by: Mike Turquette > >> Acked-by: Geert Uytterhoeven > >> Reviewed-by: Maxime Ripard > >> > >> And David Herrman who is working on simpledrm, which will be merged > soon, which > >> will also use the simplefb bindings also agrees. So we have the > simplefb maintainer, > >> simpledrm maintainer, and the clk subsystem maintainer + 2 other > maintainers all > >> agreeing on a way forward, the time for bikeshedding now really really > really is > >> over. > >> > >> Tomi, can you please let us know how you plan to proceed with this ? > > > > I won't merge DT bindings via fbdev tree, if a DT maintainer says no. > > > > I took Rob's silence to the earlier series as a silent ack for your > > explanation. Obviously that was not the case. > > > > Rob, please advice asap what should be done to the bindings to get your > > ack. As Hans explained above, this discussion has been going on for a > > long time, and afaik this series is the best way forward of all the > > options discussed. > > I still think for the most part this is a kernel problem. It is a > kernel policy to turn off unused clocks. The clock framework could > just as easily decide that any clocks enabled at boot and left > un-managed (i.e. w/o a driver) are kept on until they are managed. I'm > not saying this can't be in DT, only that DT is not the only solution > here. This problem is not unique to simplefb. A serial console could > stop working if no serial driver is loaded before unused clocks are > disabled. CPU core clocks have a similar issue as well (often enabled > in platform code). I want to see this solved in a generic way for any > clock. > I am in agreement this point of view. This is a problem in the Linux kernel. It is not a generic problem. The Linux problem is that during boot device drivers are loaded in two phases - built-in and loadable modules. The clock-regulator clean up is happening too early. It happens after the built-in drivers load and before the loadable modules have a chance to load. That's simply the wrong place for that clean up happen. A simple alternative would be to make a tiny loadable module that triggers the clean up. Then adjust your boot scripts to load this module after the other ones have loaded. But instead of fixing this simple timing flaw in the Linux boot process a complex mechanism is being created to work around it. Simplefb is also being developed as a way of protecting the BIOS setup of the framebuffer past the boot process and out into use as a normal user space console. I in no way support this use. We have experienced decades of problems on the x86 with VGA and BIOSes that I do not wish to repeat in the ARM world. Write a correct, device specific framebuffer driver for this piece of hardware. That device specific driver will load before the clock/regulator cleanup and claim all of the correct resources. > > As regulators were also mentioned, they already have a > "regulator-boot-on" property defined. Perhaps this is suitable to be > mirrored for clocks. If it is not, then I'm wondering why we have it. > A key difference here is that the property is part of the provider and > can be dealt with in the clock driver rather than requiring a > temporary driver. > > Rob > > -- > You received this message because you are subscribed to the Google Groups > "linux-sunxi" group. > To unsubscribe from this group and
Re: [linux-sunxi] Re: [PATCH v4 0/5] simplefb: add clock handling code
Hi, On 10/31/2014 09:47 PM, Rob Herring wrote: > On Wed, Oct 29, 2014 at 7:08 PM, Tomi Valkeinen wrote: >> Hi Hans, Rob, >> >> On 28/10/14 13:30, Hans de Goede wrote: >>> Hi, >>> >>> On 10/28/2014 12:11 PM, Rob Herring wrote: >> Yes, I object to the binding still as it has not changed from what was previously posted. >>> >>> It would be helpful if you could explain why you object. Last time you >>> said: " You are mixing in a hardware description that is simply inaccurate." >>> >>> I then explained that this is not hardware description, but runtime state >>> information, as it tells the kernel which clocks were chosen to drive the >>> display (out of typically a list of possible options, depending on which >>> output is used, etc.). Just like which memory address the bootloader has >>> chosen to scan out the video image from. >>> >>> Then you got quiet, so sorry, but this time your objection really is too >>> late. You cannot simply go quiet halfway through a discussion and then pop >>> up again when a new version is posted to say "I object" yet another time, >>> you've had your chance to make your arguments last time, and chose to stay >>> quiet after I explained in detail that this is not hardware description but >>> state information, so now it is simply too late. >>> >>> These bindings have been discussed at Plumbers with various interested >>> people >>> present, and the conclusion was that this really is the best way to handle >>> this, >>> so this patch is: >>> >>> Signed-off-by: Hans de Goede >>> Reviewed-by: Mike Turquette >>> Acked-by: Geert Uytterhoeven >>> Reviewed-by: Maxime Ripard >>> >>> And David Herrman who is working on simpledrm, which will be merged soon, >>> which >>> will also use the simplefb bindings also agrees. So we have the simplefb >>> maintainer, >>> simpledrm maintainer, and the clk subsystem maintainer + 2 other >>> maintainers all >>> agreeing on a way forward, the time for bikeshedding now really really >>> really is >>> over. >>> >>> Tomi, can you please let us know how you plan to proceed with this ? >> >> I won't merge DT bindings via fbdev tree, if a DT maintainer says no. >> >> I took Rob's silence to the earlier series as a silent ack for your >> explanation. Obviously that was not the case. >> >> Rob, please advice asap what should be done to the bindings to get your >> ack. As Hans explained above, this discussion has been going on for a >> long time, and afaik this series is the best way forward of all the >> options discussed. > > I still think for the most part this is a kernel problem. It is a > kernel policy to turn off unused clocks. The clock framework could > just as easily decide that any clocks enabled at boot and left > un-managed (i.e. w/o a driver) are kept on until they are managed. This is not just about being unmanaged, clocks can be shared, and another driver can actively claim the clock and turn it off, we need to protect against this too. > I'm not saying this can't be in DT, only that DT is not the only solution > here. Basically the problem is that we must keep the clock enabled for the lifetime of the simplefb device. We've been over this in 2 very long threads already, and many alternatives have been evaluated and found wanting. The only 100% safe way to ensure clocks are not turned off is to tie there lifetime to that of the simplefb device, and the only reliable way to do that is through a clocks property. It really is that simple, and I don't understand why people keep insisting there must be another way, while they fail to offer a (reliable, working) other way. > This problem is not unique to simplefb. A serial console could > stop working if no serial driver is loaded before unused clocks are > disabled. CPU core clocks have a similar issue as well (often enabled > in platform code). I want to see this solved in a generic way for any > clock. > > As regulators were also mentioned, they already have a > "regulator-boot-on" property defined. Perhaps this is suitable to be > mirrored for clocks. If it is not, then I'm wondering why we have it. > A key difference here is that the property is part of the provider and > can be dealt with in the clock driver rather than requiring a > temporary driver. "regulator-boot-on" tells the regulator framework to enable a regulator at boot, but it does not protect it from getting turned of by another driver later (it does not increase use_count). So this is the same none solution as not turning off unmanaged clocks, what if another driver who shares the clock, enables it during probe, then disables it while done probing (to put things in low power state until userspace uses the device). This is not about not turning the clock off, this is about keeping the clock on for the lifetime of the simplefb device, which is a different problem, cause we must not remove a single calling point of clock_off, put we must block all attempts to turn the clock off, which i
