Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code
On Mon, Sep 29, 2014 at 05:11:01PM +0100, Mark Brown wrote: On Mon, Sep 29, 2014 at 10:06:39AM +0200, Thierry Reding wrote: On Sat, Sep 27, 2014 at 04:56:01PM -0700, Mike Turquette wrote: With that said I think that Luc's approach is very sensible. I'm not sure what purpose in the universe DT is supposed to serve if not for _this_exact_case_. We have a nice abstracted driver, usable by many people. The hardware details of how it is hooked up at the board level can all be hidden behind stable DT bindings that everyone already uses. simplefb doesn't deal at all with hardware details. It simply uses what firmware has set up, which is the only reason why it will work for many people. What is passed in via its device tree node is the minimum amount of information needed to draw something into the framebuffer. Also note that the simplefb device tree node is not statically added to a DTS file but needs to be dynamically generated by firmware at runtime. If we start extending the binding with board-level details we end up duplicating the device tree node for the proper video device. Also note that it won't stop at clocks. Other setups will require regulators to be listed in this device tree node as well so that they don't get disabled at late_initcall. And the regulator bindings don't provide a method to list an arbitrary number of clocks in a single property in the way that the clocks property works. Not really thought this through fully yet but would having phandles to the relevant devices do the job? Kind of lines up with Grant's idea of having dummy drivers. One of the arguments that came up during the discussion of the sunxi patches is that simplefb is going to be used precisely because there is no real driver for the display part of the SoC yet and nobody knows what the binding will look like. So there's nothing to point at currently and for the same reason having a dummy driver won't work. There's simply no definition of what resources are needed. There may be also resets involved. Fortunately the reset framework is minimalistic enough not to care about asserting all unused resets at late_initcall. And other things like power domains may also need to be kept on. We might want to do that in the future, though it's not always the case that reset is the lowest power state. That proves my point. If we ever decide to assert resets by default we'll have yet another subsystem that can potentially break existing DTs. In the end it brings us back to the very fundamental principles of DT that's been causing so much pain. For things to work properly and in a stable way you have to get the bindings right and complete from the start. That is, it needs to describe every aspect of the hardware block and all links to other components. But there is no way you can do that for a virtual device like simplefb because it is a generic abstraction for hardware that varies wildly. The only way to make it work is to abstract away all the resource management and consider it to be done elsewhere. So how about instead of requiring resources to be explicitly claimed we introduce something like the below patch? The intention being to give firmware device drivers a way of signalling to the clock framework that they need rely on clocks set up by firmware and when they no longer need them. This implements essentially what Mark (CC'ing again on this subthread) suggested earlier in this thread. Basically, it will allow drivers to determine the time when unused clocks are really unused. It will of course only work when used correctly by drivers. For the case of simplefb I'd expect its .probe() implementation to call the new clk_ignore_unused() function and once it has handed over control of the display hardware to the real driver it can call clk_unignore_unused() to signal that all unused clocks that it cares about have now been claimed. This is reference counted and can therefore be used by more than a single driver if necessary. Similar functionality could be added for other resource subsystems as needed. One thing that makes me a bit nervous about this approach in the context of the regulator API is the frequency with which one finds shared supplies. I'm not sure if it's actually a big problem in practice but it makes me worry a bit. We could probably just do something like make refcounting down to zero not actually disable anything for standard regulators to deal with it which might be an idea anyway in the context of this sort of dodge. Yes, that's sort of how I expected clk_ignore_unused to work. The way I understood it, it would cause all unused clocks to be ignored (that is stay enabled if they are). Of course as Geert pointed out in another subthread, taking this all the way means that we have to disable all power management because the firmware device may be sharing resources with other devices and which therefore are
[linux-sunxi] Re: [U-Boot] [PATCH] sunxi: Fix gmac not working reliable on the Bananapi
On Sun, 2014-09-28 at 20:13 +0200, Hans de Goede wrote:
In order for the gmac nic to work reliable on the Bananapi, we need to poke
these 2 undocumented bits in the gmac clk register. Since these are
undocumented, this commit only sets these bits on the Bananapi for now.
I'll contact Allwinner to try and get these bits documented, once they
are documented we can hopefully replace this hack with a better patch.
Reported-by: Karsten Merker mer...@debian.org
Signed-off-by: Hans de Goede hdego...@redhat.com
It would be good to include some of Karsten's more detailed explanation
(see his reply downthread) of what's going on, but other than that:
Acked-by: Ian Campbell i...@hellion.org.uk
and ack to pushing it for v2014.10.
---
board/sunxi/gmac.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/board/sunxi/gmac.c b/board/sunxi/gmac.c
index e7ff952..f58c963 100644
--- a/board/sunxi/gmac.c
+++ b/board/sunxi/gmac.c
@@ -24,6 +24,15 @@ int sunxi_gmac_initialize(bd_t *bis)
CCM_GMAC_CTRL_GPIT_MII);
#endif
+ /*
+ * HdG: this is necessary to get GMAC to work reliable on the
+ * Bananapi. We don't know what these undocumented bits do, so this
+ * is a Bananapi specific hack for now.
+ */
+#ifdef CONFIG_BANANAPI
+ setbits_le32(ccm-gmac_clk_cfg, 0x3 10);
+#endif
+
/* Configure pin mux settings for GMAC */
for (pin = SUNXI_GPA(0); pin = SUNXI_GPA(16); pin++) {
#ifdef CONFIG_RGMII
--
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: [U-Boot] [linux-sunxi] Re: [PATCH v2 10/10] ARM: sun6i: Add Colombus board defconfig
On Mon, 2014-09-29 at 20:08 +0200, Hans de Goede wrote: Right, so lets just drop the board and I'll do a pull-req with only the bananapi gmac fix, can I have your Reviewed-by for that one please? Done. -- 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 4/4] simplefb: add clock handling code
On Tue, Sep 30, 2014 at 06:59:59AM +0200, Thierry Reding wrote: On Mon, Sep 29, 2014 at 05:57:18PM +0200, Maxime Ripard wrote: On Mon, Sep 29, 2014 at 03:54:00PM +0200, Thierry Reding wrote: On Mon, Sep 29, 2014 at 01:34:36PM +0200, Maxime Ripard wrote: On Mon, Sep 29, 2014 at 12:44:57PM +0200, Thierry Reding wrote: Plus, speaking more specifically about the clocks, that won't prevent your clock to be shut down as a side effect of a later clk_disable call from another driver. Furthermore isn't it a bug for a driver to call clk_disable() before a preceding clk_enable()? There are patches being worked on that will enable per-user clocks and as I understand it they will specifically disallow drivers to disable the hardware clock if other drivers are still keeping them on via their own referenc. Calling clk_disable() preceding clk_enable() is a bug. Calling clk_disable() after clk_enable() will disable the clock (and its parents) if the clock subsystem thinks there are no other users, which is what will happen here. Right. I'm not sure this is really applicable to this situation, though. It's actually very easy to do. Have a driver that probes, enables its clock, fails to probe for any reason, call clk_disable in its exit path. If there's no other user at that time of this particular clock tree, it will be shut down. Bam. You just lost your framebuffer. Really, it's just that simple, and relying on the fact that some other user of the same clock tree will always be their is beyond fragile. Perhaps the meaning clk_ignore_unused should be revised, then. What you describe isn't at all what I'd expect from such an option. And it does not match the description in Documentation/kernel-parameters.txt either. Well, it never says that it also prevent them from being disabled later on. But it's true it's not very explicit. It says: Keep all clocks already enabled by bootloader on, even if no driver has claimed them. ... There's no until or anything there, so I interpret that as indefinitely. Well, then, sorry, but that's not how it works. Either way, if there are other users of a clock then they will just as likely want to modify the rate at which point simplefb will break just as badly. And this can be handled just as well. Register a clock notifier, refuse any rate change, done. But of course, that would require having a clock handle. Now, how would *you* prevent such a change? Like I said in the other thread. If you have two drivers that use the same clock but need different frequencies you've lost anyway. Except that the driver that has the most logic (ie not simplefb) will have a way to recover and deal with that. You're making an assumption here. Why would the driver have such logic if nothing ever prevented it from setting the rate properly before. I'm not saying it has, but it something that can be done. You usually have several strategies, which depending on the device, might or might not be possible, such as reparenting, trying to use an additional divider. Worst case scenario, you're indeed doomed. But you do have a best case scenario, which isn't the case with your approach. And you didn't screw the framebuffer silently. But sure, you can still try to point new issues, get an obvious and robust solution, and then discard the issue when the solution doesn't go your way... And you've already proven that you're completely unwilling to even consider any other solution than what was originally proposed, so I really don't see how discussing this further with you is going to be productive. You haven't express *what* you wanted to achieve for quite some time, but only *how*. And your how has some deficiencies that have already been pointed out numerous times. However, I do come to the same conclusion. I really don't see how we can be productive. Just like I really don't see how we will ever be able to get any DRM/KMS driver in when the time comes. -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code
On Tue, Sep 30, 2014 at 07:21:11AM +0200, Thierry Reding wrote: On Mon, Sep 29, 2014 at 06:28:14PM +0200, Maxime Ripard wrote: On Mon, Sep 29, 2014 at 03:47:15PM +0200, Thierry Reding wrote: On Mon, Sep 29, 2014 at 01:46:43PM +0200, Maxime Ripard wrote: On Mon, Sep 29, 2014 at 12:18:08PM +0200, Thierry Reding wrote: On Mon, Sep 29, 2014 at 11:23:01AM +0200, Maxime Ripard wrote: On Mon, Sep 29, 2014 at 10:06:39AM +0200, Thierry Reding wrote: [...] simplefb doesn't deal at all with hardware details. It simply uses what firmware has set up, which is the only reason why it will work for many people. What is passed in via its device tree node is the minimum amount of information needed to draw something into the framebuffer. Also note that the simplefb device tree node is not statically added to a DTS file but needs to be dynamically generated by firmware at runtime. Which makes the whole even simpler, since the firmware already knows all about which clocks it had to enable. It makes things very complicated in the firmware because it now needs to be able to generate DTB content that we would otherwise be able to do much easier with a text editor. Didn't you just say that it was dynamically generated at runtime? So we can just ignore the text editor case. Perhaps read the sentence again. I said that we would *otherwise* be able to do much easier with a text editor.. My point remains that there shouldn't be a need to generate DTB content of this complexity at all. Why do you think what I proposed isn't going to work or be reliable? I don't see any arguments in the thread that would imply that. The fact that it broke in the first place? That's exactly the point. And it's going to break again and again as simplefb is extended with new things. Generally DT bindings should be backwards compatible. When extended they should provide a way to fall back to a reasonable default. There's simply no way you can do that with simplefb. This one *is* backward compatible. It doesn't even change the simplefb behaviour, compared to what it was doing before, if you don't have this clocks property. What can be a more reasonable default that the way it used to behave? My point is that if we decide not to consider all resources handled by firmware then we need to go all the way. At that point you start having problems as evidenced by the Snow example. Agreed. What happened in the Snow example is that regulators that were previously on would all of a sudden be automatically disabled on boot because there was now a driver that registered them with a generic framework. The same thing is going to happen with simplefb for your device. If you later realize that you need a regulator to keep the panel going, you'll have to add code to your firmware to populate the corresponding properties, otherwise the regulator will end up unused and will be automatically disabled. At the same time you're going to break upstream for all users of your old firmware because it doesn't add that property yet. And the same will continue to happen for every new type of resource you're going to add. Sure, we can add any resources we will need. Regulators, reset lines, pm domains, allocated memory, but I'm not really sure this is what you want, right? No it's not what I want. *You* want to add resource management to this driver. What I'm saying is that if we start adding clocks then we can no longer say no to resets or regulators or power domains either. Yes, because resource management can be more than just keep the thing enabled. It might also be about not modifying anything, just like we saw for the clocks, but that might also apply to regulators voltage. And the only way I can think of to deal with that properly is to have resources management in the driver. You know that you are going to call that for regulator, reset, power domains, just as you would have needed to with the proper API, unless that with this kind of solution, you would have to modify *every* framework that might interact with any resource involved in getting simplefb running? We have to add handling for every kind of resource either way. Also if this evolves into a common pattern we can easily wrap it up in a single function call. Unless that in one case, we already have everything needed to handle everything properly, and in another, you keep hacking more and more into the involved frameworks. This is a fundamental issue that we are facing and I'm trying to come up with a solution that is future-proof and will work for drivers other than simplefb. Just because we currently lack this
Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code
On Tue, Sep 30, 2014 at 07:39:02AM +0200, Thierry Reding wrote: You keep bringing up the Raspberry Pi for some reason and suggest that it is somehow inferior to sunxi. What makes you think it's less entitled to be supported on Linux than sunxi? I don't care about the Raspberry Pi and I equally don't care about sunxi. I don't own a Raspberry Pi and I don't own any Allwinner hardware. What I do care about is Linux and I want it to work well for all SoCs equally. Perhaps if you could put aside your crusade against the Raspberry Pi for just a second you'll realize that we're all on the same team. This isn't a competition and I'm not trying to put a spoke in your wheel. On the contrary, I'm actually trying to help you. We've been over this already, and I'll tell you again that you're getting this wrong. No platform is more entitled to get merged than another one. I do care about the Allwinner SoCs, and I care just as much about the broader Linux support for all the other SoCs, be it from nvidia, samsung or whatever vendor you can come up with. But you can't hide the fact that the bcm2835 still has a very limited clock support, and I really don't know about its clock tree, but I guess that if the times come when they add a more complete clock support, they will face the same issue. If the driver would have been developped initially to create a framebuffer on the Allwinner SoCs, at a time when we didn't have any clock support too, calling it only usable on sunxi wouldn't have shocked me tbh. -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [linux-sunxi] A80 mixed OS (Linux / RTOS)
On Tuesday, September 30, 2014, Quink wantl...@gmail.com wrote: Such a big plan. I just did a small project with (Real-time patch for linux kernel) + (processor affinity) + (super loop) on A20. Since A20 has two A7, a real time process can occupy a processor and leave the other for other tasks. With out a working main line kernel, it seems like you have a lot of work to do to customize the kernel. Could you share how you did it? On Tue, Sep 30, 2014 at 4:46 AM, javqui wavetofind...@gmail.com wrote: Hi, I'm working on a couple of projects requiring the classic Micro controller features (low power, deterministic real time processing) and the classic UX, flexibility and functionality of Linux /android. Most SoCs today provide many high level external hardware interfaces (like Camera, USB, HDMI, etc) but some projects require additional drivers and interfaces to handle different external hardware. Usually we solve the interconnectivity with extra MCUs, FPGAs or other specialized chip interfaces available. Sometimes, we design product boards with two solutions: a Cortex A SoC like Allwinner/rockchip/Omap series and a small MCU Cortex M like the STM32 series, but with a powerful A80, it could change forever. I will receive my first Optimus board soon, and I want to customize the kernel to create a classic Linux running on the powerful 4x A15+ GPU and Nucleus (or Free RTOS) on one or two of the A7 of the Allwinner A80 Soc. (I made similar kernel works with MTK SoCs in the past, but never try to run two operating systems in the same chip at the same time) Both projects require continuous operation and deterministic real time response on the low power processor(s) (RTOS on A7). User interaction (Linux on the A15 + GPU side ) is only eventual, so termal issues by running almost all processors at the same time occasionally, should not be a problem. If anyone anticipate a significant barrier to build a kernel of this type, please share it here, I will really appreciate. I will share the results and evaluation test here Additionally I will really appreciate if someone could help me to get the A80 user manual, (please contact me by email). Both projects require access to low level A80 features for special hardware interfaces and the user manual is a must for both projects and future product projects related with the A80. I want to switch almost all my projects to Allwinner A80. Javqui -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- Benjamin Henrion bhenrion at ffii.org FFII Brussels - +32-484-566109 - +32-2-4148403 In July 2005, after several failed attempts to legalise software patents in Europe, the patent establishment changed its strategy. Instead of explicitly seeking to sanction the patentability of software, they are now seeking to create a central European patent court, which would establish and enforce patentability rules in their favor, without any possibility of correction by competing courts or democratically elected legislators. -- 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 4/4] simplefb: add clock handling code
On Tue, Sep 30, 2014 at 09:52:58AM +0200, Maxime Ripard wrote: On Tue, Sep 30, 2014 at 07:21:11AM +0200, Thierry Reding wrote: On Mon, Sep 29, 2014 at 06:28:14PM +0200, Maxime Ripard wrote: On Mon, Sep 29, 2014 at 03:47:15PM +0200, Thierry Reding wrote: [...] What happened in the Snow example is that regulators that were previously on would all of a sudden be automatically disabled on boot because there was now a driver that registered them with a generic framework. The same thing is going to happen with simplefb for your device. If you later realize that you need a regulator to keep the panel going, you'll have to add code to your firmware to populate the corresponding properties, otherwise the regulator will end up unused and will be automatically disabled. At the same time you're going to break upstream for all users of your old firmware because it doesn't add that property yet. And the same will continue to happen for every new type of resource you're going to add. Sure, we can add any resources we will need. Regulators, reset lines, pm domains, allocated memory, but I'm not really sure this is what you want, right? No it's not what I want. *You* want to add resource management to this driver. What I'm saying is that if we start adding clocks then we can no longer say no to resets or regulators or power domains either. Yes, because resource management can be more than just keep the thing enabled. It might also be about not modifying anything, just like we saw for the clocks, but that might also apply to regulators voltage. We've already determined that simplefb can't do anything meaningful with the resources other than keep them in the status quo. It simply doesn't have enough knowledge to do so. It doesn't know the exact pixel clock or what voltage the attached panel needs. And the only way I can think of to deal with that properly is to have resources management in the driver. My point is that if we had a proper way to tell the kernel not to do anything with resources owned by firmware, then the driver wouldn't have to do anything with the resources. I really start to consider adding a sunxi-uboot-fb, that would just duplicate the source code of simplefb but also taking the clocks. Somehow, I feel like it will be easier (and definitely less of a hack than using the generic common clock API). You're not getting it are you? What makes you think sunxi-uboot-fb is going to be any different? This isn't about a name. At least, we would get to do any binding and resource management we want. And that's a big win. So instead of trying to understand the concerns that I've expressed and constructively contribute to finding a solution that works for everybody you'd rather go and write a driver from scratch. Way to go. I've already said that I'm not saying strictly no to these patches, but what I want to see happen is some constructive discussion about whether we can find better ways to do it. If we can't then I'm all for merging these patches. Fortunately other (sub)threads have been somewhat more constructive and actually come up with alternatives that should make everyone happier. If you're going to do SoC-specific bindings and resource management you are in fact implementing what Grant suggested in a subthread. You're implementing a dummy driver only for resource management, which isn't really a bad thing. It can serve as a placeholder for now until you add the real driver. And you can also use the simplefb driver to provide the framebuffer. Thierry pgpwc7ByQwhIp.pgp Description: PGP signature
[linux-sunxi] uart5 not working right on sun4i and sun7i (mainline mostly tested)
Hey list, I'm trying to get uart5 to work on a setup here, and am having some strange issues. I tried this on stage-3.4 but couldn't get any output, so I quickly switched over to mainline without going to deep into this. I've configured uart0, uart2, uart5 and uart6 to do some tests. Using luc's serial noise program I get spammed with /dev/ttyS%d (i adapted it from USB%d) and see those strings on a logic analyizer, scope and several USB to serial converters. However uart2 is giving me headaches. The output is prepended with random junk: (hope copy paste works) ���^E^B^@!@�^H^@^@!^BB�^H!/dev/ttyS2 B^@^H^P�@�^@^B^@�/dev/ttyS2 /d^C ^E^B/ttyS2 /dev/ttyS2 ^B^H/dev/ttyS2 occasionally, somehow it 'sticks' and from then on just outputs /dev/ttyS2 in a row and remains okay. Restarting serial_noise breaks it again and it may remain broken for ages or sometimes picks up again and continues to work. What strikes me is that the end always is the string I expect (with the exception where backspace and delete characters break things). On the scope i see perfect squares, so it's not a electrical noise thing. I will next test with uart3 added, and uart2 (and 3, 6) removed to see if that matters. But so far, it looks like uart5 is ... somehow broken. I tested this on two sun4i lime's and 1 sun7i lime. I'm just baffled ... Olliver -- 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 4/4] simplefb: add clock handling code
On 30 September 2014 10:54, Thierry Reding thierry.red...@gmail.com wrote: On Tue, Sep 30, 2014 at 09:52:58AM +0200, Maxime Ripard wrote: On Tue, Sep 30, 2014 at 07:21:11AM +0200, Thierry Reding wrote: On Mon, Sep 29, 2014 at 06:28:14PM +0200, Maxime Ripard wrote: On Mon, Sep 29, 2014 at 03:47:15PM +0200, Thierry Reding wrote: [...] What happened in the Snow example is that regulators that were previously on would all of a sudden be automatically disabled on boot because there was now a driver that registered them with a generic framework. The same thing is going to happen with simplefb for your device. If you later realize that you need a regulator to keep the panel going, you'll have to add code to your firmware to populate the corresponding properties, otherwise the regulator will end up unused and will be automatically disabled. At the same time you're going to break upstream for all users of your old firmware because it doesn't add that property yet. And the same will continue to happen for every new type of resource you're going to add. Sure, we can add any resources we will need. Regulators, reset lines, pm domains, allocated memory, but I'm not really sure this is what you want, right? No it's not what I want. *You* want to add resource management to this driver. What I'm saying is that if we start adding clocks then we can no longer say no to resets or regulators or power domains either. Yes, because resource management can be more than just keep the thing enabled. It might also be about not modifying anything, just like we saw for the clocks, but that might also apply to regulators voltage. We've already determined that simplefb can't do anything meaningful with the resources other than keep them in the status quo. It simply doesn't have enough knowledge to do so. It doesn't know the exact pixel clock or what voltage the attached panel needs. And the only way I can think of to deal with that properly is to have resources management in the driver. My point is that if we had a proper way to tell the kernel not to do anything with resources owned by firmware, then the driver wouldn't have to do anything with the resources. The firmware on sunxi does not own any resources whatsoever. It ceases running once it executes the kernel. This is different from ACPI and UEFI where you have pieces of the firmware lingering indefinitely and potentially getting invoked by user pressing some button or some other hardware event. It is also different from rpi where the Linux kernel effectively runs in a virtual environment created by the firmware hypervisor. So on sunxi and many other ARM machines the Linux kernel is the sole owner of any resources that might happen to be available on the machine. There is no firmware owning them when the Linux kernel is running, ever. And we do have a proper way to tell to the kernel what these resources are used for - inserting description of them into the simplefb DT node. Sure the simplefb cannot manage the resources in any way and but it does own them. When it is running they are in use, when it stops they are free to be reclaimed by the platform driver. But you refuse to marge the kernel change for this proper management to happen. The alternate proposal to stop the kernel from managing resources while simplefb is running and refernce count drivers that cannot manage resources is indeed a workable, general alternative. It does however switch the kernel into special mode when resources are not managed and will needlessly hinder eg. development and testing of powermanagement and hotplug for drivers unrelated to kms in parallel to kms. But let's look at this special mode closer. Under normal boot sequence when the built-in drivers are initialized or around that time the kernel does a pass in which it disables unused clocks and possibly reclaims other resources. The boot has finished for the kernel and now it hands over to userspace and it is up to the userspace to load any more drivers (such as kms) or not. If at that point a driver like simplefb exists it should have called that stop_managing_resources() which should replace clk_ignore_unused() so that other resources are properly handled without the driver ever having to know about them. For clocks this should be simple. At least on sunxi the clock driver can tell if the clock is gated and can potentially be in use. It can even mark clocks that are used at this point to know not to ever disable them. Also it should refuse to ever change a clock frequency on these clocks since if one of them was used for simplefb it should break. It does not matter it's a mmc bus clock completely unrelated to display. If you assume no knowledge you cannot change the mmc clock when a different card is inserted or when a card is inserted into an empty slot. If the firmware probed the slot the clock might be running anyway. Other
Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code
On Tue, Sep 30, 2014 at 10:03:54AM +0200, Maxime Ripard wrote: On Tue, Sep 30, 2014 at 07:39:02AM +0200, Thierry Reding wrote: You keep bringing up the Raspberry Pi for some reason and suggest that it is somehow inferior to sunxi. What makes you think it's less entitled to be supported on Linux than sunxi? I don't care about the Raspberry Pi and I equally don't care about sunxi. I don't own a Raspberry Pi and I don't own any Allwinner hardware. What I do care about is Linux and I want it to work well for all SoCs equally. Perhaps if you could put aside your crusade against the Raspberry Pi for just a second you'll realize that we're all on the same team. This isn't a competition and I'm not trying to put a spoke in your wheel. On the contrary, I'm actually trying to help you. We've been over this already, and I'll tell you again that you're getting this wrong. No platform is more entitled to get merged than another one. I do care about the Allwinner SoCs, and I care just as much about the broader Linux support for all the other SoCs, be it from nvidia, samsung or whatever vendor you can come up with. Okay, I'm glad our goals aren't that far apart then. It would be helpful to stop dragging the Raspberry Pi into this, though, since it isn't at all relevant. But you can't hide the fact that the bcm2835 still has a very limited clock support, and I really don't know about its clock tree, but I guess that if the times come when they add a more complete clock support, they will face the same issue. This isn't at all relevant. And that's exactly why I think it's good to hide all the resource management behind firmware. That way it becomes easy to support any SoC with any firmware. If the driver would have been developped initially to create a framebuffer on the Allwinner SoCs, at a time when we didn't have any clock support too, calling it only usable on sunxi wouldn't have shocked me tbh. The functionality that it provides is still very generic. And the firmware interface is generic too. It is this abstraction that allows it to be generic. You on the other hand seem to be arguing that by making it abstract we've made it less generic. Abstraction is about hiding details to capture commonality. Thierry pgpAFZSGpCS4j.pgp Description: PGP signature
Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code
On Tue, Sep 30, 2014 at 11:38:50AM +0200, Michal Suchanek wrote: On 30 September 2014 10:54, Thierry Reding thierry.red...@gmail.com wrote: On Tue, Sep 30, 2014 at 09:52:58AM +0200, Maxime Ripard wrote: On Tue, Sep 30, 2014 at 07:21:11AM +0200, Thierry Reding wrote: On Mon, Sep 29, 2014 at 06:28:14PM +0200, Maxime Ripard wrote: On Mon, Sep 29, 2014 at 03:47:15PM +0200, Thierry Reding wrote: [...] What happened in the Snow example is that regulators that were previously on would all of a sudden be automatically disabled on boot because there was now a driver that registered them with a generic framework. The same thing is going to happen with simplefb for your device. If you later realize that you need a regulator to keep the panel going, you'll have to add code to your firmware to populate the corresponding properties, otherwise the regulator will end up unused and will be automatically disabled. At the same time you're going to break upstream for all users of your old firmware because it doesn't add that property yet. And the same will continue to happen for every new type of resource you're going to add. Sure, we can add any resources we will need. Regulators, reset lines, pm domains, allocated memory, but I'm not really sure this is what you want, right? No it's not what I want. *You* want to add resource management to this driver. What I'm saying is that if we start adding clocks then we can no longer say no to resets or regulators or power domains either. Yes, because resource management can be more than just keep the thing enabled. It might also be about not modifying anything, just like we saw for the clocks, but that might also apply to regulators voltage. We've already determined that simplefb can't do anything meaningful with the resources other than keep them in the status quo. It simply doesn't have enough knowledge to do so. It doesn't know the exact pixel clock or what voltage the attached panel needs. And the only way I can think of to deal with that properly is to have resources management in the driver. My point is that if we had a proper way to tell the kernel not to do anything with resources owned by firmware, then the driver wouldn't have to do anything with the resources. The firmware on sunxi does not own any resources whatsoever. It ceases running once it executes the kernel. This is different from ACPI and UEFI where you have pieces of the firmware lingering indefinitely and potentially getting invoked by user pressing some button or some other hardware event. It is also different from rpi where the Linux kernel effectively runs in a virtual environment created by the firmware hypervisor. You know all that because you of course wrote every single firmware implementation that does and will ever exist for sunxi. There's nothing keeping anyone from running UEFI on a sunxi SoC. So on sunxi and many other ARM machines the Linux kernel is the sole owner of any resources that might happen to be available on the machine. There is no firmware owning them when the Linux kernel is running, ever. Of course this is part of the abstraction. The idea is that the device is a virtual one created by firmware. Therefore firmware owns the resources until the virtual device has been handed over to the kernel. If you're into splitting hairs, then the simplefb device shouldn't exist in the first place. And we do have a proper way to tell to the kernel what these resources are used for - inserting description of them into the simplefb DT node. Sure the simplefb cannot manage the resources in any way and but it does own them. When it is running they are in use, when it stops they are free to be reclaimed by the platform driver. Yes. And again I'm not saying anything different. What I'm saying is that we shouldn't need to know about the resources and instead hide that within the firmware, for the same reason that we're already hiding the register programming in hardware, namely to create an abstraction that works irrespective of the underlying hardware. But you refuse to marge the kernel change for this proper management to happen. I have no authority to merge these changes nor have I any way of vetoing them. All I'm saying is that I think it's a bad idea. If nobody else thinks it is then it will eventually get merged irrespective of what I'm saying. And when that happens I'll shut up and live happily ever after. But it doesn't magically convince me that it's a good idea. The alternate proposal to stop the kernel from managing resources while simplefb is running and refernce count drivers that cannot manage resources is indeed a workable, general alternative. It does however switch the kernel into special mode when resources are not managed and will needlessly hinder eg. development and testing of
Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code
Hi, On 09/30/2014 06:59 AM, Thierry Reding wrote: On Mon, Sep 29, 2014 at 05:57:18PM +0200, Maxime Ripard wrote: snip But sure, you can still try to point new issues, get an obvious and robust solution, and then discard the issue when the solution doesn't go your way... And you've already proven that you're completely unwilling to even consider any other solution than what was originally proposed, so I really don't see how discussing this further with you is going to be productive. That is not true, we have seriously considered various other alternatives, as you know since you've participated in the discussion about them. And we've found them all lacking, mostly because they are 10 times as complicated. You've made your point that you don't like this solution quite loudly already, and we've all heard you. However you seem to be mostly alone in this. Even the clk maintainer has said that what we want to do is exactly how clocks are supposed to be used in dt. If you don't like this no-one is forcing you to use the clocks property in your own code. If it is not there, simplefb will behave exactly as before. Now since you're the only one very vocally against this, and a lot of people are in favor of this and have a need for this, can we please just get this merged and get this over with ? 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 4/4] simplefb: add clock handling code
On Tue, Sep 30, 2014 at 01:43:45PM +0200, Hans de Goede wrote: Hi, On 09/30/2014 06:59 AM, Thierry Reding wrote: On Mon, Sep 29, 2014 at 05:57:18PM +0200, Maxime Ripard wrote: snip But sure, you can still try to point new issues, get an obvious and robust solution, and then discard the issue when the solution doesn't go your way... And you've already proven that you're completely unwilling to even consider any other solution than what was originally proposed, so I really don't see how discussing this further with you is going to be productive. That is not true, we have seriously considered various other alternatives, as you know since you've participated in the discussion about them. And we've found them all lacking, mostly because they are 10 times as complicated. You've made your point that you don't like this solution quite loudly already, and we've all heard you. However you seem to be mostly alone in this. Even the clk maintainer has said that what we want to do is exactly how clocks are supposed to be used in dt. If you don't like this no-one is forcing you to use the clocks property in your own code. If it is not there, simplefb will behave exactly as before. Now since you're the only one very vocally against this, and a lot of people are in favor of this and have a need for this, can we please just get this merged and get this over with ? Whatever. I no longer care. Thierry pgpUQ_XRIPqPR.pgp Description: PGP signature
Re: [linux-sunxi] Re: [PATCH] sunxi: Fix gmac not working reliable on the Bananapi
Hi, On 09/29/2014 08:35 PM, jonsm...@gmail.com wrote: On Mon, Sep 29, 2014 at 2:16 PM, Karsten Merker mer...@debian.org wrote: On Mon, Sep 29, 2014 at 09:13:37AM +0300, Siarhei Siamashka wrote: How did you come to the idea to poke these bits? The linux 3.4 kernel from https://github.com/LeMaker/linux-bananapi (which is a patched linux-sunxi.org 3.4 kernel) does not show this problem, so we started looking into what is different there, and the relevant change that was found was setting these particular undocumented bits. File at issue here asking for the documentation https://github.com/allwinner-zh/documents I'm already talking to Allwinner about this, it seems that bits 10-11, or more likely 10-12 of the gmac clk register are the tx equivalent of bits 5-7, Configure GMAC receive clock delay chain. I think this is there to deal with the pcb data and clk traces not having the same length, so that this is highly board specific. I'm waiting on confirmation on this from Allwinner, as well as some info on the unit of this 0-7 value. 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] sunxi: Fix gmac not working reliable on the Bananapi
On Tue, Sep 30, 2014 at 8:02 AM, Hans de Goede hdego...@redhat.com wrote: Hi, On 09/29/2014 08:35 PM, jonsm...@gmail.com wrote: On Mon, Sep 29, 2014 at 2:16 PM, Karsten Merker mer...@debian.org wrote: On Mon, Sep 29, 2014 at 09:13:37AM +0300, Siarhei Siamashka wrote: How did you come to the idea to poke these bits? The linux 3.4 kernel from https://github.com/LeMaker/linux-bananapi (which is a patched linux-sunxi.org 3.4 kernel) does not show this problem, so we started looking into what is different there, and the relevant change that was found was setting these particular undocumented bits. File at issue here asking for the documentation https://github.com/allwinner-zh/documents I'm already talking to Allwinner about this, it seems that bits 10-11, or more likely 10-12 of the gmac clk register are the tx equivalent of bits 5-7, Configure GMAC receive clock delay chain. I think this is there to deal with the pcb data and clk traces not having the same length, so that this is highly board specific. I'm waiting on confirmation on this from Allwinner, as well as some info on the unit of this 0-7 value. Encourage them to update the manual and push a new copy to git hub immediately. Too much info like this is getting buried in mail archives. Electronic publishing is free - update as often as you want. The more they fix stuff like this in the manual, the fewer questions they will need to deal with in person. When it goes into the manual it won't get lost. Regards, Hans -- Jon Smirl jonsm...@gmail.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.
Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code
On Tue, Sep 30, 2014 at 10:54:32AM +0200, Thierry Reding wrote: On Tue, Sep 30, 2014 at 09:52:58AM +0200, Maxime Ripard wrote: On Tue, Sep 30, 2014 at 07:21:11AM +0200, Thierry Reding wrote: On Mon, Sep 29, 2014 at 06:28:14PM +0200, Maxime Ripard wrote: On Mon, Sep 29, 2014 at 03:47:15PM +0200, Thierry Reding wrote: [...] What happened in the Snow example is that regulators that were previously on would all of a sudden be automatically disabled on boot because there was now a driver that registered them with a generic framework. The same thing is going to happen with simplefb for your device. If you later realize that you need a regulator to keep the panel going, you'll have to add code to your firmware to populate the corresponding properties, otherwise the regulator will end up unused and will be automatically disabled. At the same time you're going to break upstream for all users of your old firmware because it doesn't add that property yet. And the same will continue to happen for every new type of resource you're going to add. Sure, we can add any resources we will need. Regulators, reset lines, pm domains, allocated memory, but I'm not really sure this is what you want, right? No it's not what I want. *You* want to add resource management to this driver. What I'm saying is that if we start adding clocks then we can no longer say no to resets or regulators or power domains either. Yes, because resource management can be more than just keep the thing enabled. It might also be about not modifying anything, just like we saw for the clocks, but that might also apply to regulators voltage. We've already determined that simplefb can't do anything meaningful with the resources other than keep them in the status quo. It simply doesn't have enough knowledge to do so. It doesn't know the exact pixel clock or what voltage the attached panel needs. We do agree that it doesn't care, doesn't need to know it, or doesn't need to do anything about it, but what it needs is that they stay the same. That means both keeping a clock or a regulator enabled, but also preventing any other user (direct, as in a shared regulator, or indirect, as in two clocks sharing the same parent) to change that voltage or pixel clock. You were trying to address the former in your patch, but you completely ignore the second one, which is just as important. And the only way I can think of to deal with that properly is to have resources management in the driver. My point is that if we had a proper way to tell the kernel not to do anything with resources owned by firmware, then the driver wouldn't have to do anything with the resources. Yes, but at least for the clocks, and I guess it might be true in some sick way for regulators too, the fact that it's a tree doesn't make this easy at all. If they were completely independant clocks, yeah, sure, we could do that. But it's almost never the case, and all clocks share parents with other at some degree. I guess you could do it using clock flags of some sort, but that would require traversing the clock tree for almost any operation, which doesn't look very reasonable. I really start to consider adding a sunxi-uboot-fb, that would just duplicate the source code of simplefb but also taking the clocks. Somehow, I feel like it will be easier (and definitely less of a hack than using the generic common clock API). You're not getting it are you? What makes you think sunxi-uboot-fb is going to be any different? This isn't about a name. At least, we would get to do any binding and resource management we want. And that's a big win. So instead of trying to understand the concerns that I've expressed and constructively contribute to finding a solution that works for everybody you'd rather go and write a driver from scratch. Way to go. Hey, you haven't really contributed either to finding a solution to the fact that we need not only to prevent the clocks from being touched during the framework initcall, but also from other related users. I've already said that I'm not saying strictly no to these patches, but what I want to see happen is some constructive discussion about whether we can find better ways to do it. If we can't then I'm all for merging these patches. Fortunately other (sub)threads have been somewhat more constructive and actually come up with alternatives that should make everyone happier. I didn't see where you said that you were not strictly against them. But ok. I guess your concerns all boil down to 1) do not break DT backward compatibility, 2) do not break what the firmware has set up, even on older firmwares. We got 1 covered already, but in order to cover 2, I guess we would need both our solutions, that I don't really see as orthogonal. How would something like adding
Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code
On Tue, Sep 30, 2014 at 12:02:50AM +0200, Luc Verhaegen wrote: 2) Simplefb will only have a single user: the rpi. As the only other users i can think of, which does not have a full driver and which does not have clocks automatically disabled, are discrete cards. And they do not really tend to happen with dt or platform devices. I thought the goal was for other platforms to use simplefb while waiting for the real drivers to be loaded (so you can get get console output as early as possible from a built in driver for example)? signature.asc Description: Digital signature
Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code
On Tue, Sep 30, 2014 at 8:41 AM, Mark Brown broo...@kernel.org wrote: On Tue, Sep 30, 2014 at 12:02:50AM +0200, Luc Verhaegen wrote: 2) Simplefb will only have a single user: the rpi. As the only other users i can think of, which does not have a full driver and which does not have clocks automatically disabled, are discrete cards. And they do not really tend to happen with dt or platform devices. I thought the goal was for other platforms to use simplefb while waiting for the real drivers to be loaded (so you can get get console output as early as possible from a built in driver for example)? That is an option that might work. Stop trying to make simplefb work after the system is fully booted. Instead just let it run until the clocks get shut off. That allows it to go back to being nothing but a simple pointer to the video buffer. Then if you want to keep your display going and don't have a KMS driver written, whip together a device specific framebuffer driver for your hardware that does the right thing with the clocks, etc. The device specific framebuffer driver can load later in the boot process so that it doesn't have to be built into the kernel. This device specfic driver matches on a compatible string and knows what to do with all of the device tree info. -- Jon Smirl jonsm...@gmail.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.
Re: [linux-sunxi] [PATCH] sunxi: Fix gmac not working reliable on the Bananapi
Op 30 sep. 2014, om 14:02 heeft Hans de Goede hdego...@redhat.com het volgende geschreven: Hi, On 09/29/2014 08:35 PM, jonsm...@gmail.com wrote: On Mon, Sep 29, 2014 at 2:16 PM, Karsten Merker mer...@debian.org wrote: On Mon, Sep 29, 2014 at 09:13:37AM +0300, Siarhei Siamashka wrote: How did you come to the idea to poke these bits? The linux 3.4 kernel from https://github.com/LeMaker/linux-bananapi (which is a patched linux-sunxi.org 3.4 kernel) does not show this problem, so we started looking into what is different there, and the relevant change that was found was setting these particular undocumented bits. File at issue here asking for the documentation https://github.com/allwinner-zh/documents I'm already talking to Allwinner about this, it seems that bits 10-11, or more likely 10-12 of the gmac clk register are the tx equivalent of bits 5-7, Configure GMAC receive clock delay chain. I think this is there to deal with the pcb data and clk traces not having the same length, so that this is highly board specific. I'm waiting on confirmation on this from Allwinner, as well as some info on the unit of this 0-7 value. Gbit ethernet requires a delay between the lines, which you can implement by adding 10cm or so extra trace on the PCB or tell the MAC or PHY to do it in software. Very board specific, but so far I've only seen Intel reference designs use the extra trace length method most arm/ppc/mips gbit boards use a PHY that handles it in hardware on request like the GMAC is doing above. regards, Koen -- 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 4/4] simplefb: add clock handling code
On 30 September 2014 13:31, Thierry Reding thierry.red...@gmail.com wrote: On Tue, Sep 30, 2014 at 11:38:50AM +0200, Michal Suchanek wrote: On 30 September 2014 10:54, Thierry Reding thierry.red...@gmail.com wrote: On Tue, Sep 30, 2014 at 09:52:58AM +0200, Maxime Ripard wrote: On Tue, Sep 30, 2014 at 07:21:11AM +0200, Thierry Reding wrote: On Mon, Sep 29, 2014 at 06:28:14PM +0200, Maxime Ripard wrote: On Mon, Sep 29, 2014 at 03:47:15PM +0200, Thierry Reding wrote: [...] What happened in the Snow example is that regulators that were previously on would all of a sudden be automatically disabled on boot because there was now a driver that registered them with a generic framework. The same thing is going to happen with simplefb for your device. If you later realize that you need a regulator to keep the panel going, you'll have to add code to your firmware to populate the corresponding properties, otherwise the regulator will end up unused and will be automatically disabled. At the same time you're going to break upstream for all users of your old firmware because it doesn't add that property yet. And the same will continue to happen for every new type of resource you're going to add. Sure, we can add any resources we will need. Regulators, reset lines, pm domains, allocated memory, but I'm not really sure this is what you want, right? No it's not what I want. *You* want to add resource management to this driver. What I'm saying is that if we start adding clocks then we can no longer say no to resets or regulators or power domains either. Yes, because resource management can be more than just keep the thing enabled. It might also be about not modifying anything, just like we saw for the clocks, but that might also apply to regulators voltage. We've already determined that simplefb can't do anything meaningful with the resources other than keep them in the status quo. It simply doesn't have enough knowledge to do so. It doesn't know the exact pixel clock or what voltage the attached panel needs. And the only way I can think of to deal with that properly is to have resources management in the driver. My point is that if we had a proper way to tell the kernel not to do anything with resources owned by firmware, then the driver wouldn't have to do anything with the resources. The firmware on sunxi does not own any resources whatsoever. It ceases running once it executes the kernel. This is different from ACPI and UEFI where you have pieces of the firmware lingering indefinitely and potentially getting invoked by user pressing some button or some other hardware event. It is also different from rpi where the Linux kernel effectively runs in a virtual environment created by the firmware hypervisor. You know all that because you of course wrote every single firmware implementation that does and will ever exist for sunxi. There's nothing keeping anyone from running UEFI on a sunxi SoC. The existing 'firmware' or rather loader for sunxi is u-boot. I am not saying other solutions cannot exist. I am describing the current situation. So on sunxi and many other ARM machines the Linux kernel is the sole owner of any resources that might happen to be available on the machine. There is no firmware owning them when the Linux kernel is running, ever. Of course this is part of the abstraction. The idea is that the device is a virtual one created by firmware. Therefore firmware owns the resources until the virtual device has been handed over to the kernel. If you're into splitting hairs, then the simplefb device shouldn't exist in the first place. Why shoudn't it? It is properly created by u-boot and handed over to the kernel with all the required information for the kernel to keep it running or shut it down as it sees fit. And we do have a proper way to tell to the kernel what these resources are used for - inserting description of them into the simplefb DT node. Sure the simplefb cannot manage the resources in any way and but it does own them. When it is running they are in use, when it stops they are free to be reclaimed by the platform driver. Yes. And again I'm not saying anything different. What I'm saying is that we shouldn't need to know about the resources and instead hide that within the firmware, for the same reason that we're already hiding the register programming in hardware, namely to create an abstraction that works irrespective of the underlying hardware. So then hide those resources in the Linux kernel. Because if you are into hair splitting then on sunxi currently the Linux kernel is the firmware and u-boot is only one of the loader stages that ultimately executes the final firmware which is Linux. I really start to consider adding a sunxi-uboot-fb, that would just duplicate the
Re: [linux-sunxi] A80 mixed OS (Linux / RTOS)
Maybe a complete separate OS is a little easier than implement a modified Linux Kernel as you did (impressive Job) Maybe the Kernel is not the right word in my first post and a customized boot will be a better definition. The system will have 2 simultaneous OS kernels. For the Linux Kernel OS perspective, the A7 will not exist. From the Nucleus kernel perspective, the A15 will not exist. The interaction and potential sync events will happen in shared memory with adequate traffic lights or/and external interrupts (like a peripheral). Memory protection domains for each OS will avoid a lot of problems and the A80 (ARM Big.Litte) provide this secure feature according with the very basic A80 datasheet available. An implementation of this type could replace many non-traditional product designs with a single A80. A80 looks like was designed with tablet and smartphone markets in mind, but it could have access to a larger market and developers. A minimum starting point documentation (A80 user manual) is mandatory to start moving the current projects to A80 platform and to start recommending it for new projects. Anyone that could help with the user manual, please contact me directly. Javqui On Monday, September 29, 2014 8:57:17 PM UTC-4, Zhao Zhili wrote: Such a big plan. I just did a small project with (Real-time patch for linux kernel) + (processor affinity) + (super loop) on A20. Since A20 has two A7, a real time process can occupy a processor and leave the other for other tasks. With out a working main line kernel, it seems like you have a lot of work to do to customize the kernel. On Tue, Sep 30, 2014 at 4:46 AM, javqui waveto...@gmail.com javascript: wrote: Hi, I'm working on a couple of projects requiring the classic Micro controller features (low power, deterministic real time processing) and the classic UX, flexibility and functionality of Linux /android. Most SoCs today provide many high level external hardware interfaces (like Camera, USB, HDMI, etc) but some projects require additional drivers and interfaces to handle different external hardware. Usually we solve the interconnectivity with extra MCUs, FPGAs or other specialized chip interfaces available. Sometimes, we design product boards with two solutions: a Cortex A SoC like Allwinner/rockchip/Omap series and a small MCU Cortex M like the STM32 series, but with a powerful A80, it could change forever. I will receive my first Optimus board soon, and I want to customize the kernel to create a classic Linux running on the powerful 4x A15+ GPU and Nucleus (or Free RTOS) on one or two of the A7 of the Allwinner A80 Soc. (I made similar kernel works with MTK SoCs in the past, but never try to run two operating systems in the same chip at the same time) Both projects require continuous operation and deterministic real time response on the low power processor(s) (RTOS on A7). User interaction (Linux on the A15 + GPU side ) is only eventual, so termal issues by running almost all processors at the same time occasionally, should not be a problem. If anyone anticipate a significant barrier to build a kernel of this type, please share it here, I will really appreciate. I will share the results and evaluation test here Additionally I will really appreciate if someone could help me to get the A80 user manual, (please contact me by email). Both projects require access to low level A80 features for special hardware interfaces and the user manual is a must for both projects and future product projects related with the A80. I want to switch almost all my projects to Allwinner A80. Javqui -- 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...@googlegroups.com javascript:. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Wiki page to track allwinner datasheets (user manual) errata
Hi All, I think we should start an errata page on the linux-sunxi wiki somewhere, specifically targeting errata for the official user manual documents. I know we already have various pages to document specific blocks, the idea here would be to have a general errata page. The purpose is to have a single place to gather doc fixes for blocks which are adequately documented in the user-manual, except for one or two missing bits. IMHO it is not worth the trouble / useful to create an entire new page for cases where we're talking about just 1-2 bits. But it would be useful to gather these little fixes somewhere, hence the suggestion to have a generic errata page. For blocks for which we already have extensive documentation in the wiki, this generic page can contain links to the documentation for these blocks. So good or bad idea ? And if you believe this is a good idea, any suggestions for a name / hierarchy for these pages ? ### The specific case triggering this idea is the lack of documentation for bits 10-12 of the GMAC clk register (0x01c20164). I've been in contact with allwinner about these 3 bits, and they configure the GMAC Transmit Clock Delay Chain (GTXDC), they are the transmit equivalent of bits 5-7. 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] Wiki page to track allwinner datasheets (user manual) errata
On Tue, Sep 30, 2014 at 06:21:18PM +0200, Hans de Goede wrote: Hi All, I think we should start an errata page on the linux-sunxi wiki somewhere, specifically targeting errata for the official user manual documents. I know we already have various pages to document specific blocks, the idea here would be to have a general errata page. The purpose is to have a single place to gather doc fixes for blocks which are adequately documented in the user-manual, except for one or two missing bits. IMHO it is not worth the trouble / useful to create an entire new page for cases where we're talking about just 1-2 bits. But it would be useful to gather these little fixes somewhere, hence the suggestion to have a generic errata page. For blocks for which we already have extensive documentation in the wiki, this generic page can contain links to the documentation for these blocks. So good or bad idea ? And if you believe this is a good idea, any suggestions for a name / hierarchy for these pages ? ### The specific case triggering this idea is the lack of documentation for bits 10-12 of the GMAC clk register (0x01c20164). I've been in contact with allwinner about these 3 bits, and they configure the GMAC Transmit Clock Delay Chain (GTXDC), they are the transmit equivalent of bits 5-7. Regards, Hans Sounds like a plan. Let's start out with something like this: Start with a page called documentation or something. Then start listing the datasheets, one section per chipset (single =) on that page. Have the device pages link to those sections. Then have a per chipset errata page reachable from each chipset specific section. We will see where to go from there. Luc Verhaegen. -- 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] Wiki page to track allwinner datasheets (user manual) errata
On Tue, Sep 30, 2014 at 12:21 PM, Hans de Goede hdego...@redhat.com wrote: Hi All, I think we should start an errata page on the linux-sunxi wiki somewhere, specifically targeting errata for the official user manual documents. Why not issue tracking on the github account Allwinner made? https://github.com/allwinner-zh/documents/issues I'd like to see Allwinner get used to responding to a normal issues tracking system. I know we already have various pages to document specific blocks, the idea here would be to have a general errata page. The purpose is to have a single place to gather doc fixes for blocks which are adequately documented in the user-manual, except for one or two missing bits. IMHO it is not worth the trouble / useful to create an entire new page for cases where we're talking about just 1-2 bits. But it would be useful to gather these little fixes somewhere, hence the suggestion to have a generic errata page. For blocks for which we already have extensive documentation in the wiki, this generic page can contain links to the documentation for these blocks. So good or bad idea ? And if you believe this is a good idea, any suggestions for a name / hierarchy for these pages ? ### The specific case triggering this idea is the lack of documentation for bits 10-12 of the GMAC clk register (0x01c20164). I've been in contact with allwinner about these 3 bits, and they configure the GMAC Transmit Clock Delay Chain (GTXDC), they are the transmit equivalent of bits 5-7. 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. -- Jon Smirl jonsm...@gmail.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.
Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code
On Tue, Sep 30, 2014 at 07:09:24AM +0200, Thierry Reding wrote: On Mon, Sep 29, 2014 at 04:55:17PM +0100, Mark Brown wrote: So long as we're ensuring that when we don't start supporting resources without DT additions or at least require DT additions to actively manage them (which can then include simplefb hookup) we should be fine. I'm not sure I understand what you mean. If we add a driver for the PMIC that exposes these regulators and then add a DT node for the PMIC, we'd still need to fix the firmware to generate the appropriate DT properties to allow simplefb to enable the regulators. No, you don't. It's only if you start describing the regulators in the PMIC in DT that you run into problems. Unconfigured regulators won't be touched. So unless firmware is updated at the same time, regulators will get disabled because they are unused. That won't happen unless the regulators are explicitly described, if they are described as unused then this will of course happen. signature.asc Description: Digital signature
Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code
On Tue, Sep 30, 2014 at 08:03:14AM +0200, Thierry Reding wrote: On Mon, Sep 29, 2014 at 05:11:01PM +0100, Mark Brown wrote: Not really thought this through fully yet but would having phandles to the relevant devices do the job? Kind of lines up with Grant's idea of having dummy drivers. One of the arguments that came up during the discussion of the sunxi patches is that simplefb is going to be used precisely because there is no real driver for the display part of the SoC yet and nobody knows what the binding will look like. So there's nothing to point at currently and for the same reason having a dummy driver won't work. There's simply no definition of what resources are needed. You may well need to extend the binding in future for an actual driver but from the point of view of what's going into the block it really should just be a case of reading the datasheet and mechanically typing that in. If we can work out how to say where the framebuffer is we really ought to be able to work this stuff out. There may be also resets involved. Fortunately the reset framework is minimalistic enough not to care about asserting all unused resets at late_initcall. And other things like power domains may also need to be kept on. We might want to do that in the future, though it's not always the case that reset is the lowest power state. That proves my point. If we ever decide to assert resets by default we'll have yet another subsystem that can potentially break existing DTs. OTOH given the level of breakage that's like to introduce we might just decide not to do that... In the end it brings us back to the very fundamental principles of DT that's been causing so much pain. For things to work properly and in a stable way you have to get the bindings right and complete from the start. That is, it needs to describe every aspect of the hardware block and all links to other components. Or we ned to introduce things in a conservative fashion which does cope with backwards compatibility; it's definitely more work but it is doable. One thing that makes me a bit nervous about this approach in the context of the regulator API is the frequency with which one finds shared supplies. I'm not sure if it's actually a big problem in practice but it makes me worry a bit. We could probably just do something like make refcounting down to zero not actually disable anything for standard regulators to deal with it which might be an idea anyway in the context of this sort of dodge. Yes, that's sort of how I expected clk_ignore_unused to work. The way I understood it, it would cause all unused clocks to be ignored (that is stay enabled if they are). Of course as Geert pointed out in another subthread, taking this all the way means that we have to disable all power management because the firmware device may be sharing resources with other devices and which therefore are not unused. That's a pretty strong argument and I don't have a solution for that. It is only really a problem for cases where the firmware virtual device isn't taken over by a proper driver at some point, though. Indeed, and we also run into trouble for things where we actually need to really turn off the resource for some reason (MMC has some needs here for example). signature.asc Description: Digital signature
Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code
Quoting Thierry Reding (2014-09-29 06:54:00) On Mon, Sep 29, 2014 at 01:34:36PM +0200, Maxime Ripard wrote: On Mon, Sep 29, 2014 at 12:44:57PM +0200, Thierry Reding wrote: Plus, speaking more specifically about the clocks, that won't prevent your clock to be shut down as a side effect of a later clk_disable call from another driver. Furthermore isn't it a bug for a driver to call clk_disable() before a preceding clk_enable()? There are patches being worked on that will enable per-user clocks and as I understand it they will specifically disallow drivers to disable the hardware clock if other drivers are still keeping them on via their own referenc. Calling clk_disable() preceding clk_enable() is a bug. Calling clk_disable() after clk_enable() will disable the clock (and its parents) if the clock subsystem thinks there are no other users, which is what will happen here. Right. I'm not sure this is really applicable to this situation, though. It's actually very easy to do. Have a driver that probes, enables its clock, fails to probe for any reason, call clk_disable in its exit path. If there's no other user at that time of this particular clock tree, it will be shut down. Bam. You just lost your framebuffer. Really, it's just that simple, and relying on the fact that some other user of the same clock tree will always be their is beyond fragile. Perhaps the meaning clk_ignore_unused should be revised, then. What you describe isn't at all what I'd expect from such an option. And it does not match the description in Documentation/kernel-parameters.txt either. From e156ee56cbe26c9e8df6619dac1a993245afc1d5 Mon Sep 17 00:00:00 2001 From: Mike Turquette mturque...@linaro.org Date: Tue, 30 Sep 2014 14:24:38 -0700 Subject: [PATCH] doc/kernel-parameters.txt: clarify clk_ignore_unused Refine the definition around clk_ignore_unused, which caused some confusion recently on the linux-fbdev and linux-arm-kernel mailing lists[0]. [0] http://lkml.kernel.org/r/20140929135358.GC30998@ulmo Signed-off-by: Mike Turquette mturque...@linaro.org --- Thierry, Please let me know if this wording makes the feature more clear. Documentation/kernel-parameters.txt | 14 +- 1 file changed, 9 insertions(+), 5 deletions(-) diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 10d51c2..0ce01fb 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -605,11 +605,15 @@ bytes respectively. Such letter suffixes can also be entirely omitted. See Documentation/s390/CommonIO for details. clk_ignore_unused [CLK] - Keep all clocks already enabled by bootloader on, - even if no driver has claimed them. This is useful - for debug and development, but should not be - needed on a platform with proper driver support. - For more information, see Documentation/clk.txt. + Prevents the clock framework from automatically gating + clocks that have not been explicitly enabled by a Linux + device driver but are enabled in hardware at reset or + by the bootloader/firmware. Note that this does not + force such clocks to be always-on nor does it reserve + those clocks in any way. This parameter is useful for + debug and development, but should not be needed on a + platform with proper driver support. For more + information, see Documentation/clk.txt. clock= [BUGS=X86-32, HW] gettimeofday clocksource override. [Deprecated] -- 1.8.3.2 -- 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] [PATCH 1/1] sunxi: Enable network commands by default
Network commands are enabled by default in include/config_cmd_default.h Undefining them in sunxi-common.h then causes multiple build warnings when re-enabled If there is good reason to disable by default then their should be a cleaner way to enable the commands for those who want to use networking Signed-off-by: Alistair Thomas astav...@yahoo.co.uk --- include/configs/sunxi-common.h | 2 -- 1 file changed, 2 deletions(-) diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h index 019a1bb..50e8fd3 100644 --- a/include/configs/sunxi-common.h +++ b/include/configs/sunxi-common.h @@ -309,8 +309,6 @@ #endif #undef CONFIG_CMD_FPGA -#undef CONFIG_CMD_NET -#undef CONFIG_CMD_NFS /* I2C */ #if !defined CONFIG_SUN6I !defined CONFIG_SUN8I -- 1.8.1.4 -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] A80 mixed OS (Linux / RTOS)
This project is amazing. It will be very useful in industrial and control area. I have two question: 1. Since you only need one or two A7 cores to run RTOS, why not let the remaining A7 run Linux together with A15 since this will use less power? 2. Are you going to build only one image contain two kernel? Thank you and hope to see progress. 2014-09-30 23:18 GMT+08:00 javqui wavetofind...@gmail.com: Maybe a complete separate OS is a little easier than implement a modified Linux Kernel as you did (impressive Job) Maybe the Kernel is not the right word in my first post and a customized boot will be a better definition. The system will have 2 simultaneous OS kernels. For the Linux Kernel OS perspective, the A7 will not exist. From the Nucleus kernel perspective, the A15 will not exist. The interaction and potential sync events will happen in shared memory with adequate traffic lights or/and external interrupts (like a peripheral). Memory protection domains for each OS will avoid a lot of problems and the A80 (ARM Big.Litte) provide this secure feature according with the very basic A80 datasheet available. An implementation of this type could replace many non-traditional product designs with a single A80. A80 looks like was designed with tablet and smartphone markets in mind, but it could have access to a larger market and developers. A minimum starting point documentation (A80 user manual) is mandatory to start moving the current projects to A80 platform and to start recommending it for new projects. Anyone that could help with the user manual, please contact me directly. Javqui On Monday, September 29, 2014 8:57:17 PM UTC-4, Zhao Zhili wrote: Such a big plan. I just did a small project with (Real-time patch for linux kernel) + (processor affinity) + (super loop) on A20. Since A20 has two A7, a real time process can occupy a processor and leave the other for other tasks. With out a working main line kernel, it seems like you have a lot of work to do to customize the kernel. On Tue, Sep 30, 2014 at 4:46 AM, javqui waveto...@gmail.com wrote: Hi, I'm working on a couple of projects requiring the classic Micro controller features (low power, deterministic real time processing) and the classic UX, flexibility and functionality of Linux /android. Most SoCs today provide many high level external hardware interfaces (like Camera, USB, HDMI, etc) but some projects require additional drivers and interfaces to handle different external hardware. Usually we solve the interconnectivity with extra MCUs, FPGAs or other specialized chip interfaces available. Sometimes, we design product boards with two solutions: a Cortex A SoC like Allwinner/rockchip/Omap series and a small MCU Cortex M like the STM32 series, but with a powerful A80, it could change forever. I will receive my first Optimus board soon, and I want to customize the kernel to create a classic Linux running on the powerful 4x A15+ GPU and Nucleus (or Free RTOS) on one or two of the A7 of the Allwinner A80 Soc. (I made similar kernel works with MTK SoCs in the past, but never try to run two operating systems in the same chip at the same time) Both projects require continuous operation and deterministic real time response on the low power processor(s) (RTOS on A7). User interaction (Linux on the A15 + GPU side ) is only eventual, so termal issues by running almost all processors at the same time occasionally, should not be a problem. If anyone anticipate a significant barrier to build a kernel of this type, please share it here, I will really appreciate. I will share the results and evaluation test here Additionally I will really appreciate if someone could help me to get the A80 user manual, (please contact me by email). Both projects require access to low level A80 features for special hardware interfaces and the user manual is a must for both projects and future product projects related with the A80. I want to switch almost all my projects to Allwinner A80. Javqui -- 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...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- 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.
