Re: [linux-sunxi] Wiki page to track allwinner datasheets (user manual) errata
Hi, On 09/30/2014 06:32 PM, jonsm...@gmail.com wrote: 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. That is a good idea, feel free to report an issue there with the errata we're talking about atm: 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
Hi, On 09/30/2014 06:25 PM, Luc Verhaegen wrote: 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. Sounds good. Unfortunately I've come to the conclusion that I'm way too busy lately, and that I've to better prioritize things (and actually drop low priority items after setting priorities). I'm afraid this item has been put on the to be dropped list. I'm sorry (really I am). I hope someone else can pick this up. 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 7:32 PM, jonsm...@gmail.com jonsm...@gmail.com wrote: 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. Ideally, Allwinner should update the PDF documents once errors/omissions are found. I do not know how fast they can attend to such issues, so it is important to find out. The second option is to maintain errata files on https://github.com/allwinner-zh/documents/ for each SoC. For the current issue for the A20, we create a new file into https://github.com/allwinner-zh/documents/tree/master/A20 called errata_datasheet.txt/errata_usermanual.txt and add the text that describes what is changed. Then we sent a pull request so that Allwinner would merely need to click a button at github.com to accept the change. Then, they can take their time to update the original PDF docs. When that happens, we clear the errata files. If however Allwinner would prefer the community to do all the work with the errata files, then the github.com account for allwinner-zh could be converted into an organization account, and then they can add a few of our github user accounts as members of the documents repository. This means that we can deal with errata documents completely by ourselves, and let Allwinner add those changes into future revisions of the documents. If the above make sense, we can suggest them to Allwinner. Are we OK with that? Simos 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. -- 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 v2 2/3] ARM: dts: sun7i: Add uart3_pins_b pinctrl setting
The uart3_pins_a multiplexes the uart3 pins to port G, add a pinctrl entry
for mapping them to port H (as used on the Bananapi).
Signed-off-by: Hans de Goede hdego...@redhat.com
---
arch/arm/boot/dts/sun7i-a20.dtsi | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi
index cb5abef..302dc1f 100644
--- a/arch/arm/boot/dts/sun7i-a20.dtsi
+++ b/arch/arm/boot/dts/sun7i-a20.dtsi
@@ -677,6 +677,13 @@
allwinner,pull = 0;
};
+ uart3_pins_b: uart3@1 {
+ allwinner,pins = PH0, PH1;
+ allwinner,function = uart3;
+ allwinner,drive = 0;
+ allwinner,pull = 0;
+ };
+
uart4_pins_a: uart4@0 {
allwinner,pins = PG10, PG11;
allwinner,function = uart4;
--
2.1.0
--
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 v2 3/3] ARM: dts: sun7i: Add Banana Pi board
The Banana Pi is an A20 based development board using Raspberry Pi compatible
IO headers. It comes with 1 GB RAM, 1 Gb ethernet, 2x USB host, sata, hdmi
and stereo audio out + various expenansion headers:
http://www.lemaker.org/
Signed-off-by: Hans de Goede hdego...@redhat.com
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/sun7i-a20-bananapi.dts | 214 +++
2 files changed, 215 insertions(+)
create mode 100644 arch/arm/boot/dts/sun7i-a20-bananapi.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index b8c5cd3..c3003a4 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -414,6 +414,7 @@ dtb-$(CONFIG_MACH_SUN6I) += \
sun6i-a31-hummingbird.dtb \
sun6i-a31-m9.dtb
dtb-$(CONFIG_MACH_SUN7I) += \
+ sun7i-a20-bananapi.dtb \
sun7i-a20-cubieboard2.dtb \
sun7i-a20-cubietruck.dtb \
sun7i-a20-i12-tvbox.dtb \
diff --git a/arch/arm/boot/dts/sun7i-a20-bananapi.dts
b/arch/arm/boot/dts/sun7i-a20-bananapi.dts
new file mode 100644
index 000..0e7c9f5
--- /dev/null
+++ b/arch/arm/boot/dts/sun7i-a20-bananapi.dts
@@ -0,0 +1,214 @@
+/*
+ * Copyright 2014 Hans de Goede hdego...@redhat.com
+ *
+ * Hans de Goede hdego...@redhat.com
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public
+ * License along with this library; if not, write to the Free
+ * Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
+ * MA 02110-1301 USA
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the Software), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+/include/ sun7i-a20.dtsi
+/include/ sunxi-common-regulators.dtsi
+
+/ {
+ model = LeMaker Banana Pi;
+ compatible = lemaker,bananapi, allwinner,sun7i-a20;
+
+ soc@01c0 {
+ spi0: spi@01c05000 {
+ pinctrl-names = default;
+ pinctrl-0 = spi0_pins_a;
+ status = okay;
+ };
+
+ mmc0: mmc@01c0f000 {
+ pinctrl-names = default;
+ pinctrl-0 = mmc0_pins_a, mmc0_cd_pin_bananapi;
+ vmmc-supply = reg_vcc3v3;
+ bus-width = 4;
+ cd-gpios = pio 7 10 0; /* PH10 */
+ cd-inverted;
+ status = okay;
+ };
+
+ usbphy: phy@01c13400 {
+ usb1_vbus-supply = reg_usb1_vbus;
+ usb2_vbus-supply = reg_usb2_vbus;
+ status = okay;
+ };
+
+ ehci0: usb@01c14000 {
+ status = okay;
+ };
+
+ ohci0: usb@01c14400 {
+ status = okay;
+ };
+
+ ahci: sata@01c18000 {
+ status = okay;
+ };
+
+ ehci1: usb@01c1c000 {
+ status = okay;
+ };
+
+ ohci1: usb@01c1c400 {
+ status = okay;
+ };
+
+
[linux-sunxi] [PATCH v2 0/3] ARM: dts: sun7i: Add Banana Pi board
Hi Maxime, Here is v2 of the Bananapi board addition. Sorry for taking so long. Changes from v2: -Move uart3_pins definition from a20-sun7i-bananapi.dts to a20-sun7i.dtsi, the addition of the pinctrl node is done in a separate patch -Use the new dual license header as license header Regards, Hans -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] [PATCH v2 1/3] ARM: dts: sun7i: Add spi0_pins_a pinctrl setting
Signed-off-by: Hans de Goede hdego...@redhat.com
---
arch/arm/boot/dts/sun7i-a20.dtsi | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi
index b22daf3..cb5abef 100644
--- a/arch/arm/boot/dts/sun7i-a20.dtsi
+++ b/arch/arm/boot/dts/sun7i-a20.dtsi
@@ -784,6 +784,13 @@
allwinner,pull = 0;
};
+ spi0_pins_a: spi0@0 {
+ allwinner,pins = PI10, PI11, PI12,
PI13, PI14;
+ allwinner,function = spi0;
+ allwinner,drive = 0;
+ allwinner,pull = 0;
+ };
+
spi1_pins_a: spi1@0 {
allwinner,pins = PI16, PI17, PI18, PI19;
allwinner,function = spi1;
--
2.1.0
--
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 02:37:53PM -0700, Mike Turquette wrote: 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. I think that's better than before, but I don't think it's accurate yet. As pointed out by Maxime unused clock may still be disabled if it's part of a tree and that tree is being disabled because there are no users left. What I had argued is that it's unexpected behaviour, because the clock is still unused (or becomes unused again), therefore shouldn't be disabled at that point either. So if you want to keep the current behaviour where an unused clock can still be disabled depending on what other users do, then I think it'd be good to mention that as a potential caveat. Thierry pgpC8LuOkv3Rr.pgp Description: PGP signature
Re: [linux-sunxi] A80 mixed OS (Linux / RTOS)
You'll need to run an hypervisor to arbitre the access to shared resources for the two OSs, look at http://wiki.xen.org/wiki/Xen_ARM_with_Virtualization_Extensions/Allwinner http://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualization_Extensions I believe there was some demo of a tablet running two android using Xen. On Tue, Sep 30, 2014 at 5:18 PM, javqui wavetofind...@gmail.com wrote: 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. -- Jorge Nerín jne...@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] A80 mixed OS (Linux / RTOS)
On Mon, Sep 29, 2014 at 01:46:50PM -0700, javqui 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 What might be easier for you, and probably less intrusive from the kernel point of view, would be to use the co-processor that some Allwinner SoCs have. I know the A31 has one, and I'm pretty sure the A80 too. That would leave Linux in charge of the real CPUs, while offloading your RT tasks to a smaller processor, without having to deal with all the segmentation in the bootloader. And if you're used to using Cortex-M, you shouldn't need all that horsepower anyway. Maxime -- 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:00:36PM +0100, Mark Brown wrote: 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. I agree from a technical point of view. However given the dynamically generated nature of the node the problem is more of a logistical nature. As we've seen U-Boot is being enabled to add clocks to the simplefb node but I'm fairly certain that there's a regulator somewhere that needs to be enabled too, be it for powering the display controller, the panel or the backlight. I wouldn't even be surprised if there were one for each of those. If so simplefb on this board will break when the regulators are described in the kernel's DTS. If we don't consider this a problem then the whole DT ABI stability business is a farce. 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... It might be the sensible thing to do in most cases. I think there's a legitimate reason not to trust firmware. However in case of simplefb we already do, so I think having a sort of flag to signal that we do trust firmware would allow us to cope with these situation much better. 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. Is it? I thought the only way to keep backwards compatibility was by making any new properties optional. But if those properties add vital information for the device to work you have to come up with a sensible default to keep existing setups working that lack the new properties. Doing that is not going to scale very well. It has a chance of working for hardware-specific drivers because we may be able to derive the default from the SoC generation or even the machine compatible. But I don't see how it could work for something that's supposed to be generic like simplefb. I'm hoping that there's a better way that I don't know about, because it would certainly make a lot of things much easier. 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
Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code
On Tue, Sep 30, 2014 at 07:00:36PM +0100, Mark Brown wrote: On Tue, Sep 30, 2014 at 08:03:14AM +0200, Thierry Reding wrote: [...] 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). Perhaps an alternative would be to just keep power management going and hope for the best. This may turn out not to be as much of a problem for many SoCs or boards as people make it out to be. Thierry pgpGUTF5zy5fp.pgp Description: PGP signature
Re: [linux-sunxi] A80 mixed OS (Linux / RTOS)
On Wed, 2014-10-01 at 09:38 +0200, Jorge wrote: You'll need to run an hypervisor to arbitre the access to shared resources for the two OSs, look at http://wiki.xen.org/wiki/Xen_ARM_with_Virtualization_Extensions/Allwinner http://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualization_Extensions I believe there was some demo of a tablet running two android using Xen. Puts on Xen on ARM upstream maintainer's hat... This is exactly what I was about to suggest ;-). There is quite a bit of interest in running Xen on ARM from the embedded space, people are using it for in car infotainment systems, autopilot software for quadcopters and all sorts of interesting stuff these days. I know that people are certainly running FreeRTOS on top of Xen (the other one I've heard is QNX). Xen has a pluggable scheduler architecture and includes a couple of RT capable schedulers (arinc and a new EDF one in upcoming 4.5) and you can even divide the system's physical CPUs into pools and run a different scheduler on each pool (useful to divide processors into RT and regular sets and assign domains to pools accordingly). The Allwinner platform is well supported (it was one of the earliest supported platforms). In fact I'm in the process of deploying 4x cubietrucks into the Xen Project's automated test system. Still quite a bit of soldering and wiring to do to get it all rack friendly and power controlled etc though ;-) Ian. -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] A80 mixed OS (Linux / RTOS)
On Wed, 2014-10-01 at 09:19 +0100, Ian Campbell wrote: On Wed, 2014-10-01 at 09:38 +0200, Jorge wrote: You'll need to run an hypervisor to arbitre the access to shared resources for the two OSs, look at http://wiki.xen.org/wiki/Xen_ARM_with_Virtualization_Extensions/Allwinner http://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualization_Extensions I believe there was some demo of a tablet running two android using Xen. Puts on Xen on ARM upstream maintainer's hat... This is exactly what I was about to suggest ;-). There is quite a bit of interest in running Xen on ARM from the embedded space, people are using it for in car infotainment systems, autopilot software for quadcopters and all sorts of interesting stuff these days. I know that people are certainly running FreeRTOS on top of Xen (the other one I've heard is QNX). I should have said that if you want to know more check out the presentations from the last two Xen Developer Summits in Edinburgh and Chicago. http://xenproject.org/component/content/article/9-uncategorised/159-xen-project-developer-summit-2013-videos-and-presentations.html and I'm not sure the 2014 videos are posted yet but slides seem to be at http://events.linuxfoundation.org/events/xen-project-developer-summit/program/slides. There were quite a number of Xen on embedded ARM talks. Ian. -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Wiki page to track allwinner datasheets (user manual) errata
Hi, Wouldn’t it be easier if these PDF files are in some kind of markdown format? Then it will be so much easier to do pull request, review, diff, see commit log, etc. And it’ll be very easy to export as PDF. Clement On Oct 1, 2014, at 9:14 AM, Simos Xenitellis simos.li...@googlemail.com wrote: On Tue, Sep 30, 2014 at 7:32 PM, jonsm...@gmail.com mailto:jonsm...@gmail.com jonsm...@gmail.com mailto:jonsm...@gmail.com wrote: On Tue, Sep 30, 2014 at 12:21 PM, Hans de Goede hdego...@redhat.com mailto: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 https://github.com/allwinner-zh/documents/issues I'd like to see Allwinner get used to responding to a normal issues tracking system. Ideally, Allwinner should update the PDF documents once errors/omissions are found. I do not know how fast they can attend to such issues, so it is important to find out. The second option is to maintain errata files on https://github.com/allwinner-zh/documents/ https://github.com/allwinner-zh/documents/ for each SoC. For the current issue for the A20, we create a new file into https://github.com/allwinner-zh/documents/tree/master/A20 https://github.com/allwinner-zh/documents/tree/master/A20 called errata_datasheet.txt/errata_usermanual.txt and add the text that describes what is changed. Then we sent a pull request so that Allwinner would merely need to click a button at github.com http://github.com/ to accept the change. Then, they can take their time to update the original PDF docs. When that happens, we clear the errata files. If however Allwinner would prefer the community to do all the work with the errata files, then the github.com http://github.com/ account for allwinner-zh could be converted into an organization account, and then they can add a few of our github user accounts as members of the documents repository. This means that we can deal with errata documents completely by ourselves, and let Allwinner add those changes into future revisions of the documents. If the above make sense, we can suggest them to Allwinner. Are we OK with that? Simos 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 mailto:linux-sunxi%2bunsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout https://groups.google.com/d/optout. -- Jon Smirl jonsm...@gmail.com mailto: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 mailto:linux-sunxi%2bunsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout 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 mailto:linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout 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
Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code
On Wed, Oct 1, 2014 at 9:41 AM, Thierry Reding thierry.red...@gmail.com wrote: On Tue, Sep 30, 2014 at 06:39:28PM +0100, Mark Brown wrote: 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. Okay, that's what I meant. It seems rather odd to add a PMIC DT node but omit the description of the regulators that it exposes. Unless the regulators are truly unused, as in not connected to any peripherals. Agreed, I added similar PMIC support to other Chromebooks (Peach Pit and Pi) DTS and for me it made totally sense to add nodes for all the regulators that are connected to peripherals according to the board schematic. Specially since the framework is smart enough to disable any regulator that is not used. After all, a DT is meant to describe the hardware, so how can possibly be an issue to add more details about the hw in a DTS? If something is working relying on parts of the hw on not being described, then is essentially relying on side-effects and implementation details which are bound to be broken anyways. 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. With described as unused you mean they have a node in DT, so constraints are applied and all that, but no driver actually uses them? Adding your resources (clock, regulators, etc) incrementally and only when the driver for the device that use these resources is available, will only make adding support for a new platform slower IMHO since there will be more patches to be posted, reviewed and merged. The fundamental issue is that if we start describing simplefb nodes with an incomplete set of resources then we're bound to run into problems where it'll break once these new resources are described in the DTS. If the simplefb node was described in the DTS then this would be less of a problem because the resources could be added to the simplefb node at the same time. Agreed, the assumptions made by simplefb are quite fragile so we should either document somewhere that simplefb ignores all the resources and that is a best effort so users should not consider the display breaking a regression or make it robust enough so users can expect that it will always work. Just adding the clocks is a partial solution which I think will make the situation even worst since it will give a false illusion of robustness but as you said it will break anyways due other resources. However given that simplefb is supposed to be generated by firmware this is no longer possible. It will inevitably break unless you upgrade the DTB and the firmware at the same time. And it was already decided long ago that upgrading the firmware should never be a requirement for keeping things working. AFAICT in practice most platforms' firmware do not generate the simplefb by default. In the case of Chromebooks for example, a custom U-boot needs to be flashed in order to have simplefb support. In fact most people working on mainline support for Chromebooks do not use simplefb and that is why the issue was not spot when adding the support for clocks and regulators. Personally I didn't even know how simplefb worked before Will reported that his display used to work on Snow before 3.16. So I assume that his reasonable to expect that users using simplefb are able to update their bootloader. Which brings a more general question about DT and backward compatibility. Should we have backward compatibility only with the official firmware that is ship on a device when is bought or should we maintain backward compatibility against any firmware out there that someone re-built and added logic to mangle the FDT before is passed to the kernel? Going back to simplefb, I think the fact that the simplefb is not in the DTS is the fundamental issue here. For me, the most reasonable approach to solve this is the one suggested by Doug Anderson. That is to have the simplefb node in the DTS so all the references to the resources it uses can be added in the DTS but keep the simplefb node as status = disabled. The bootloader can find the simplefb node and fill all the information about the framebuffer
Re: [linux-sunxi] Wiki page to track allwinner datasheets (user manual) errata
On Wed, Oct 01, 2014 at 09:04:36AM +0200, Hans de Goede wrote: Hi, Sounds good. Unfortunately I've come to the conclusion that I'm way too busy lately, and that I've to better prioritize things (and actually drop low priority items after setting priorities). I'm afraid this item has been put on the to be dropped list. I'm sorry (really I am). I hope someone else can pick this up. Regards, Hans I already found it, let's call it, out of place, when you offered to work the wiki. 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] Re: [PATCH 4/4] simplefb: add clock handling code
On Wed, Oct 01, 2014 at 10:14:44AM +0200, Thierry Reding wrote: On Tue, Sep 30, 2014 at 07:00:36PM +0100, Mark Brown wrote: 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. I agree from a technical point of view. However given the dynamically generated nature of the node the problem is more of a logistical nature. As we've seen U-Boot is being enabled to add clocks to the simplefb node but I'm fairly certain that there's a regulator somewhere that needs to be enabled too, be it for powering the display controller, the panel or the backlight. I wouldn't even be surprised if there were one for each of those. If so simplefb on this board will break when the regulators are described in the kernel's DTS. If we don't consider this a problem then the whole DT ABI stability business is a farce. I think you're setting constraints on the implementation you want to see which make it unworkable but I don't think those constraints are needed. You're starting from the position that the DT needs to be updated without the bootloader and that the DT must not contain any hint of simplefb as shipped separately. That's never going to work well as far as I can see but doesn't seem like an ABI stability issue, or at least not a reasonable one. Either the bootloader needs to be updated along with the DT or the DT needs to offer the bootloader a stable interface of its own for adding the description of what it has set up (like a default disabled node with the FB description, I'm sure other ideas are possible). Obviously the goal with the stable ABI is that the DT will be distributed along with the platform. 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). So if disabling power management wholesale isn't going to be an option, what's the alternative? I originally proposed that the clock drivers could be modified to not disable clocks that are known to be problematic with simplefb. People objected to that because they thought it would be impractical to determine which clocks are involved with display across various boards. Handling this in the clock driver has worked remarkably well for us on Tegra, but perhaps that's just because Tegra is an unusually sane design to begin with. It's probably more that you've just not run into the corner cases yet - if the display is mostly driven from the standard controller on the SoC you've got a pretty good idea what's going to be happening. signature.asc Description: Digital signature
Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code
On Wed, Oct 01, 2014 at 01:10:46PM +0200, Javier Martinez Canillas wrote: On Wed, Oct 1, 2014 at 9:41 AM, Thierry Reding thierry.red...@gmail.com wrote: Okay, that's what I meant. It seems rather odd to add a PMIC DT node but omit the description of the regulators that it exposes. Unless the regulators are truly unused, as in not connected to any peripherals. Agreed, I added similar PMIC support to other Chromebooks (Peach Pit and Pi) DTS and for me it made totally sense to add nodes for all the regulators that are connected to peripherals according to the board schematic. Specially since the framework is smart enough to disable any regulator that is not used. After all, a DT is meant to describe the hardware, so how can possibly be an issue to add more details about the hw in a DTS? If something is working relying on parts of the hw on not being described, then is essentially relying on side-effects and implementation details which are bound to be broken anyways. It's not a problem to describe the hardware, it's a problem to describe the hardware inaccurately. If you add something and explicitly tell the kernel that nothing needs it then it shouldn't be a surprise that it gets turned off. With described as unused you mean they have a node in DT, so constraints are applied and all that, but no driver actually uses them? Adding your resources (clock, regulators, etc) incrementally and only when the driver for the device that use these resources is available, will only make adding support for a new platform slower IMHO since there will be more patches to be posted, reviewed and merged. So don't do that if you're worried about it then, provide the bits of DT that hook everything up from the start or otherwise describe things as being in use. signature.asc Description: Digital signature
Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code
On Wed, Oct 01, 2014 at 01:32:50PM +0100, Mark Brown wrote: On Wed, Oct 01, 2014 at 01:10:46PM +0200, Javier Martinez Canillas wrote: [...] Adding your resources (clock, regulators, etc) incrementally and only when the driver for the device that use these resources is available, will only make adding support for a new platform slower IMHO since there will be more patches to be posted, reviewed and merged. So don't do that if you're worried about it then, provide the bits of DT that hook everything up from the start or otherwise describe things as being in use. Otherwise describe things as being in use doesn't work for clocks for example. And Mike already said he wasn't willing to add something like an always-on DT property for clocks. Thierry pgpB5ykJ9w8oI.pgp Description: PGP signature
Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code
On Wed, Oct 01, 2014 at 01:20:08PM +0100, Mark Brown wrote: On Wed, Oct 01, 2014 at 10:14:44AM +0200, Thierry Reding wrote: On Tue, Sep 30, 2014 at 07:00:36PM +0100, Mark Brown wrote: 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. I agree from a technical point of view. However given the dynamically generated nature of the node the problem is more of a logistical nature. As we've seen U-Boot is being enabled to add clocks to the simplefb node but I'm fairly certain that there's a regulator somewhere that needs to be enabled too, be it for powering the display controller, the panel or the backlight. I wouldn't even be surprised if there were one for each of those. If so simplefb on this board will break when the regulators are described in the kernel's DTS. If we don't consider this a problem then the whole DT ABI stability business is a farce. I think you're setting constraints on the implementation you want to see which make it unworkable but I don't think those constraints are needed. You're starting from the position that the DT needs to be updated without the bootloader No, what I'm saying is that what the simplefb driver expects and what the bootloader sets up may diverge as resource drivers are added to the kernel. The DT /could/ be updated without the bootloader. You may only be able to replace the DTB but not the bootloader on a given platform. and that the DT must not contain any hint of simplefb as shipped separately. Well, I don't think it should because it describes the same resources that the device tree node for the real device already describes. But perhaps this is one of the cases where duplication isn't all that bad? That's never going to work well as far as I can see but doesn't seem like an ABI stability issue, or at least not a reasonable one. It would work well under the assumption that the kernel wouldn't be touching any of the resources that simplefb depends on. If that's not a reasonable assumption then I think we can't make simplefb work the way it's currently written. Either the bootloader needs to be updated along with the DT I thought we had decided that this was one of the big no-nos. But perhaps I'm misremembering. or the DT needs to offer the bootloader a stable interface of its own for adding the description of what it has set up (like a default disabled node with the FB description, I'm sure other ideas are possible). Obviously the goal with the stable ABI is that the DT will be distributed along with the platform. So instead of pretending that this is in any way generic, maybe a better idea would be to provide code in DRM/KMS drivers that is called early, grabs all the resources as defined in the binding for the device and then instantiates simplefb using the parsed information. Which is kind of the stub driver that Grant had suggested. Of course that means duplicating most of the resource handling from the real driver into this stub driver. And it means that this part of the driver would have to be built into the kernel and bloat it some more. Thierry pgpvcvXAotbWP.pgp Description: PGP signature
Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code
On Wed, Oct 1, 2014 at 8:48 AM, Thierry Reding thierry.red...@gmail.com wrote: On Wed, Oct 01, 2014 at 01:20:08PM +0100, Mark Brown wrote: On Wed, Oct 01, 2014 at 10:14:44AM +0200, Thierry Reding wrote: On Tue, Sep 30, 2014 at 07:00:36PM +0100, Mark Brown wrote: 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. I agree from a technical point of view. However given the dynamically generated nature of the node the problem is more of a logistical nature. As we've seen U-Boot is being enabled to add clocks to the simplefb node but I'm fairly certain that there's a regulator somewhere that needs to be enabled too, be it for powering the display controller, the panel or the backlight. I wouldn't even be surprised if there were one for each of those. If so simplefb on this board will break when the regulators are described in the kernel's DTS. If we don't consider this a problem then the whole DT ABI stability business is a farce. I think you're setting constraints on the implementation you want to see which make it unworkable but I don't think those constraints are needed. You're starting from the position that the DT needs to be updated without the bootloader No, what I'm saying is that what the simplefb driver expects and what the bootloader sets up may diverge as resource drivers are added to the kernel. The DT /could/ be updated without the bootloader. You may only be able to replace the DTB but not the bootloader on a given platform. simplefb should be a boot console and not survive past the boot process. Trying to get a 'generic' console driver to survive the boot process is not a generic problem. There are about 1,000 messages in these threads explaining why this is not a generic problem. All of these clock and regulator issues would go away by building a device specific framebuffer driver. A device specific framebuffer driver can be written in a day or two, it is far simpler than a KMS driver. This driver would how to parse the device specific device tree node and do the right thing with the regulators/clocks. So simplefb is built-in and used for early boot. During the boot process a device specific framebuffer driver loads. This device specific driver takes over for simplefb and can become the user space console. If the device specific framebuffer does not get loaded, then simplefb is going to stop working when the clocks and regulators get shut off. But that is what should happen. and that the DT must not contain any hint of simplefb as shipped separately. Well, I don't think it should because it describes the same resources that the device tree node for the real device already describes. But perhaps this is one of the cases where duplication isn't all that bad? That's never going to work well as far as I can see but doesn't seem like an ABI stability issue, or at least not a reasonable one. It would work well under the assumption that the kernel wouldn't be touching any of the resources that simplefb depends on. If that's not a reasonable assumption then I think we can't make simplefb work the way it's currently written. Either the bootloader needs to be updated along with the DT I thought we had decided that this was one of the big no-nos. But perhaps I'm misremembering. or the DT needs to offer the bootloader a stable interface of its own for adding the description of what it has set up (like a default disabled node with the FB description, I'm sure other ideas are possible). Obviously the goal with the stable ABI is that the DT will be distributed along with the platform. So instead of pretending that this is in any way generic, maybe a better idea would be to provide code in DRM/KMS drivers that is called early, grabs all the resources as defined in the binding for the device and then instantiates simplefb using the parsed information. Which is kind of the stub driver that Grant had suggested. Of course that means duplicating most of the resource handling from the real driver into this stub driver. And it means that this part of the driver would have to be built into the kernel and bloat it some more. Thierry -- 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 1 October 2014 15:01, jonsm...@gmail.com jonsm...@gmail.com wrote: On Wed, Oct 1, 2014 at 8:48 AM, Thierry Reding thierry.red...@gmail.com wrote: On Wed, Oct 01, 2014 at 01:20:08PM +0100, Mark Brown wrote: On Wed, Oct 01, 2014 at 10:14:44AM +0200, Thierry Reding wrote: On Tue, Sep 30, 2014 at 07:00:36PM +0100, Mark Brown wrote: 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. I agree from a technical point of view. However given the dynamically generated nature of the node the problem is more of a logistical nature. As we've seen U-Boot is being enabled to add clocks to the simplefb node but I'm fairly certain that there's a regulator somewhere that needs to be enabled too, be it for powering the display controller, the panel or the backlight. I wouldn't even be surprised if there were one for each of those. If so simplefb on this board will break when the regulators are described in the kernel's DTS. If we don't consider this a problem then the whole DT ABI stability business is a farce. I think you're setting constraints on the implementation you want to see which make it unworkable but I don't think those constraints are needed. You're starting from the position that the DT needs to be updated without the bootloader No, what I'm saying is that what the simplefb driver expects and what the bootloader sets up may diverge as resource drivers are added to the kernel. The DT /could/ be updated without the bootloader. You may only be able to replace the DTB but not the bootloader on a given platform. simplefb should be a boot console and not survive past the boot process. Trying to get a 'generic' console driver to survive the boot process is not a generic problem. There are about 1,000 messages in these threads explaining why this is not a generic problem. All of these clock and regulator issues would go away by building a device specific framebuffer driver. A device specific framebuffer driver can be written in a day or two, it is far simpler than a KMS driver. This driver would how to parse the device specific device tree node and do the right thing with the regulators/clocks. How it would know? You need different clocks for LCD and different clocks for HDMI. Unless it is a real driver that can drive either it can tell which is enabled or u-boot has to tell it or you have to write a fixed entry for the configuration you want in the DT and configure u-boot accordingly by hand as well. So simplefb is built-in and used for early boot. During the boot process a device specific framebuffer driver loads. This device specific driver takes over for simplefb and can become the user space console. If the device specific framebuffer does not get loaded, then simplefb is going to stop working when the clocks and regulators get shut off. But that is what should happen. Why it should be so? It is reasonable to want working console on device which has u-boot or other firmware graphics support but the support in kernel is still under development. Also the 'boot end' for kernel when it frees the clocks is way earlier than the 'boot end' for the distribution which ends when you reach certain init goal like multiuser environment. There is a lot between and once the kernel hands over to init it can never tell what's going on. Since a modular KMS driver would load way later than the moment when 'boot end' is reached for kernel the simple function as early console would break. Also if you prevented resource management from happening during this 'booting' stage you could not safely load drivers during that time which kind of defeats the purpose of this stage. Because either the kernel can do resource management and give resources to drivers that are loaded or it cannot do either. Thanks Michal -- 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 Wed, Oct 1, 2014 at 9:17 AM, Michal Suchanek hramr...@gmail.com wrote: On 1 October 2014 15:01, jonsm...@gmail.com jonsm...@gmail.com wrote: On Wed, Oct 1, 2014 at 8:48 AM, Thierry Reding thierry.red...@gmail.com wrote: On Wed, Oct 01, 2014 at 01:20:08PM +0100, Mark Brown wrote: On Wed, Oct 01, 2014 at 10:14:44AM +0200, Thierry Reding wrote: On Tue, Sep 30, 2014 at 07:00:36PM +0100, Mark Brown wrote: 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. I agree from a technical point of view. However given the dynamically generated nature of the node the problem is more of a logistical nature. As we've seen U-Boot is being enabled to add clocks to the simplefb node but I'm fairly certain that there's a regulator somewhere that needs to be enabled too, be it for powering the display controller, the panel or the backlight. I wouldn't even be surprised if there were one for each of those. If so simplefb on this board will break when the regulators are described in the kernel's DTS. If we don't consider this a problem then the whole DT ABI stability business is a farce. I think you're setting constraints on the implementation you want to see which make it unworkable but I don't think those constraints are needed. You're starting from the position that the DT needs to be updated without the bootloader No, what I'm saying is that what the simplefb driver expects and what the bootloader sets up may diverge as resource drivers are added to the kernel. The DT /could/ be updated without the bootloader. You may only be able to replace the DTB but not the bootloader on a given platform. simplefb should be a boot console and not survive past the boot process. Trying to get a 'generic' console driver to survive the boot process is not a generic problem. There are about 1,000 messages in these threads explaining why this is not a generic problem. All of these clock and regulator issues would go away by building a device specific framebuffer driver. A device specific framebuffer driver can be written in a day or two, it is far simpler than a KMS driver. This driver would how to parse the device specific device tree node and do the right thing with the regulators/clocks. How it would know? You need different clocks for LCD and different clocks for HDMI. Unless it is a real driver that can drive either it can tell which is enabled or u-boot has to tell it or you have to write a fixed entry for the configuration you want in the DT and configure u-boot accordingly by hand as well. Start building all of that very device specific support inside the device specific framebuffer driver. The device specific framebuffer driver will be on initrd and it will get loaded as soon as possible by the kernel. Inside the device node for the video device there should be a sub-node or phandle indicating the presence of the LCD or HDMI jack. That is a valid hardware description and it should always be there. You can also add a 'chosen' node to indicate how these have been programmed. Two solutions -- 1) Build in all of the device specific KMS/framebuffer drivers into the kernel. Now there is no need for simplefb. But that wastes a lot of memory with code that will never get executed. 2) Early boot off from simplefb. Have all of the graphics drivers on initrd. Load the right one. Device specific graphic driver now owns hardware. When KMS is missing, write a much smaller framebuffer driver. You can start by copying simplefb and then add in the device specific bits. The option of fully booting on simplefb up to user space console is not a good one. It requires that simplefb be taught about all of the crazy and very complex clock and regulator environments for all of the random graphics systems. And we're just getting started on enumerating all of those crazy configurations. You haven't wandered into the area of the video hardware living on a different bus and having a bus controller in the way yet. Now you have to figure out how to keep that bus from being turned off (there are SGI systems like this). So simplefb is built-in and used for early boot. During the boot process a device specific framebuffer driver loads. This device specific driver takes over for simplefb and can become the user space console. If the device specific framebuffer does not get loaded, then simplefb is going to stop working when the clocks and regulators get shut off. But that is what should happen. Why it should be so? It is reasonable to want working console on device which has u-boot or other firmware graphics support but the support in kernel is still
[linux-sunxi] [PATCH] sunxi: Add support for the Mele M3 board
The Mele M3 is yet another Allwinnner based Android top set box from Mele. It uses a housing similar to the A2000, but without the USM sata storage slot at the top. It features an A20 SoC, 1G RAM, 4G eMMC (unique for Allwinner devices), 100Mbit ethernet, HDMI out, 3 USB A receptacles, VGA, and A/V OUT connections. Signed-off-by: Hans de Goede hdego...@redhat.com --- board/sunxi/MAINTAINERS | 1 + board/sunxi/Makefile | 1 + configs/Mele_M3_defconfig | 5 + 3 files changed, 7 insertions(+) create mode 100644 configs/Mele_M3_defconfig diff --git a/board/sunxi/MAINTAINERS b/board/sunxi/MAINTAINERS index 4ed82cf..6c4226e 100644 --- a/board/sunxi/MAINTAINERS +++ b/board/sunxi/MAINTAINERS @@ -8,6 +8,7 @@ F: configs/ba10_tv_box_defconfig F: configs/Cubieboard_defconfig F: configs/Mele_A1000_defconfig F: configs/Mele_A1000G_defconfig +F: configs/Mele_M3_defconfig F: configs/Mini-X_defconfig F: configs/Mini-X-1Gb_defconfig F: include/configs/sun5i.h diff --git a/board/sunxi/Makefile b/board/sunxi/Makefile index d63a6d2..6a2e4c9 100644 --- a/board/sunxi/Makefile +++ b/board/sunxi/Makefile @@ -28,6 +28,7 @@ obj-$(CONFIG_CUBIETRUCK) += dram_cubietruck.o obj-$(CONFIG_I12_TVBOX)+= dram_sun7i_384_1024_iow16.o obj-$(CONFIG_MELE_A1000) += dram_sun4i_360_512.o obj-$(CONFIG_MELE_A1000G) += dram_sun4i_360_1024_iow8.o +obj-$(CONFIG_MELE_M3) += dram_sun7i_384_1024_iow16.o obj-$(CONFIG_MINI_X) += dram_sun4i_360_512.o obj-$(CONFIG_MINI_X_1GB) += dram_sun4i_360_1024_iow16.o obj-$(CONFIG_PCDUINO3) += dram_linksprite_pcduino3.o diff --git a/configs/Mele_M3_defconfig b/configs/Mele_M3_defconfig new file mode 100644 index 000..645b236 --- /dev/null +++ b/configs/Mele_M3_defconfig @@ -0,0 +1,5 @@ +CONFIG_SPL=y +CONFIG_SYS_EXTRA_OPTIONS=MELE_M3,AXP209_POWER,SUNXI_GMAC,USB_EHCI +CONFIG_FDTFILE=sun7i-a20-m3.dtb ++S:CONFIG_ARM=y ++S:CONFIG_TARGET_SUN7I=y -- 2.1.0 -- 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 2/2] ARM: dts: sun7i: Add Mele M3 board
The Mele M3 is yet another Allwinnner based Android top set box from Mele.
It uses a housing similar to the A2000, but without the USM sata storage slot
at the top.
It features an A20 SoC, 1G RAM, 4G eMMC (unique for Allwinner devices),
100Mbit ethernet, HDMI out, 3 USB A receptacles, VGA, and A/V OUT connections.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/sun7i-a20-m3.dts | 168 +
2 files changed, 169 insertions(+)
create mode 100644 arch/arm/boot/dts/sun7i-a20-m3.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index c3003a4..20db691 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -418,6 +418,7 @@ dtb-$(CONFIG_MACH_SUN7I) += \
sun7i-a20-cubieboard2.dtb \
sun7i-a20-cubietruck.dtb \
sun7i-a20-i12-tvbox.dtb \
+ sun7i-a20-m3.dtb \
sun7i-a20-olinuxino-micro.dtb \
sun7i-a20-pcduino3.dtb
dtb-$(CONFIG_MACH_SUN8I) += \
diff --git a/arch/arm/boot/dts/sun7i-a20-m3.dts
b/arch/arm/boot/dts/sun7i-a20-m3.dts
new file mode 100644
index 000..ce07141
--- /dev/null
+++ b/arch/arm/boot/dts/sun7i-a20-m3.dts
@@ -0,0 +1,168 @@
+/*
+ * Copyright 2014 Hans de Goede hdego...@redhat.com
+ *
+ * Hans de Goede hdego...@redhat.com
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public
+ * License along with this library; if not, write to the Free
+ * Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
+ * MA 02110-1301 USA
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the Software), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+/include/ sun7i-a20.dtsi
+/include/ sunxi-common-regulators.dtsi
+
+/ {
+ model = Mele M3;
+ compatible = mele,m3, allwinner,sun7i-a20;
+
+ soc@01c0 {
+ mmc0: mmc@01c0f000 {
+ pinctrl-names = default;
+ pinctrl-0 = mmc0_pins_a,
mmc0_cd_pin_reference_design;
+ vmmc-supply = reg_vcc3v3;
+ bus-width = 4;
+ cd-gpios = pio 7 1 0; /* PH1 */
+ cd-inverted;
+ status = okay;
+ };
+
+ mmc2: mmc@01c11000 {
+ pinctrl-names = default;
+ pinctrl-0 = mmc2_pins_a;
+ vmmc-supply = reg_vcc3v3;
+ bus-width = 4;
+ non-removable;
+ status = okay;
+ };
+
+ usbphy: phy@01c13400 {
+ usb1_vbus-supply = reg_usb1_vbus;
+ usb2_vbus-supply = reg_usb2_vbus;
+ status = okay;
+ };
+
+ ehci0: usb@01c14000 {
+ status = okay;
+ };
+
+ ohci0: usb@01c14400 {
+ status = okay;
+ };
+
+ ehci1: usb@01c1c000 {
+ status = okay;
+ };
+
+ ohci1:
[linux-sunxi] [PATCH 1/2] ARM: dts: sun7i: Add mmc2_pins_a pinctrl definition
Signed-off-by: Hans de Goede hdego...@redhat.com
---
arch/arm/boot/dts/sun7i-a20.dtsi | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi
index 302dc1f..a323621 100644
--- a/arch/arm/boot/dts/sun7i-a20.dtsi
+++ b/arch/arm/boot/dts/sun7i-a20.dtsi
@@ -833,6 +833,13 @@
allwinner,pull = 1;
};
+ mmc2_pins_a: mmc2@0 {
+ allwinner,pins =
PC6,PC7,PC8,PC9,PC10,PC11;
+ allwinner,function = mmc2;
+ allwinner,drive = 2;
+ allwinner,pull = 1;
+ };
+
mmc3_pins_a: mmc3@0 {
allwinner,pins =
PI4,PI5,PI6,PI7,PI8,PI9;
allwinner,function = mmc3;
--
2.1.0
--
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 Wed, Oct 01, 2014 at 02:48:02PM +0200, Thierry Reding wrote: On Wed, Oct 01, 2014 at 01:32:50PM +0100, Mark Brown wrote: So don't do that if you're worried about it then, provide the bits of DT that hook everything up from the start or otherwise describe things as being in use. Otherwise describe things as being in use doesn't work for clocks for example. And Mike already said he wasn't willing to add something like an always-on DT property for clocks. That's not the only way of doing things - another way would be to have a stub driver that just holds the resources while working on getting a full one in place for example. signature.asc Description: Digital signature
Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code
On Wed, Oct 01, 2014 at 02:48:53PM +0200, Thierry Reding wrote: On Wed, Oct 01, 2014 at 01:20:08PM +0100, Mark Brown wrote: I think you're setting constraints on the implementation you want to see which make it unworkable but I don't think those constraints are needed. You're starting from the position that the DT needs to be updated without the bootloader No, what I'm saying is that what the simplefb driver expects and what the bootloader sets up may diverge as resource drivers are added to the kernel. The DT /could/ be updated without the bootloader. You may only be able to replace the DTB but not the bootloader on a given platform. Sure, but doing that and also having the bootloader write part of the DT from scratch with no cooperation from the rest of the DT doesn't seem like the way to robustness. and that the DT must not contain any hint of simplefb as shipped separately. Well, I don't think it should because it describes the same resources that the device tree node for the real device already describes. But perhaps this is one of the cases where duplication isn't all that bad? If we were worried about this wecould also do it by referring to those nodes and saying get all the resources these things need rather than duplicating the references (this might make it easier to work out when the system is ready to hand off to the real drivers). That's never going to work well as far as I can see but doesn't seem like an ABI stability issue, or at least not a reasonable one. It would work well under the assumption that the kernel wouldn't be touching any of the resources that simplefb depends on. If that's not a reasonable assumption then I think we can't make simplefb work the way it's currently written. I can't see how that's reasonable unless the kernel has some way of figuring out what it shouldn't be touching. Either the bootloader needs to be updated along with the DT I thought we had decided that this was one of the big no-nos. But perhaps I'm misremembering. It makes things more fragile so it's not desirable, no. signature.asc Description: Digital signature
Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code
Hi, On 10/01/2014 07:05 PM, Mark Brown wrote: On Wed, Oct 01, 2014 at 02:48:02PM +0200, Thierry Reding wrote: On Wed, Oct 01, 2014 at 01:32:50PM +0100, Mark Brown wrote: So don't do that if you're worried about it then, provide the bits of DT that hook everything up from the start or otherwise describe things as being in use. Otherwise describe things as being in use doesn't work for clocks for example. And Mike already said he wasn't willing to add something like an always-on DT property for clocks. That's not the only way of doing things - another way would be to have a stub driver that just holds the resources while working on getting a full one in place for example. That won't work because the real driver which will eventually replace the stub one will likely be a module, and then we will loose video output between the kernel finalizing the initial boot, and the module actually loading. We've been over all this again and again and again. RGH! All solutions provided sofar are both tons more complicated, then the simple solution of simply having the simplefb dt node declare which clocks it needs. And to make things worse all of them sofar have unresolved issues (due to their complexity mostly). With the clocks in the simplefb node, then all a real driver has to do, is claim those same clocks before unregistering the simplefb driver, and everything will just work. Yet we've been discussing this for months, all because of some vague worries from Thierry, and *only* from Thierry that this will make simplefb less generic / not abstract enough, while a simple generic clocks property is about as generic as things come. This madness has to end! Thierry can we please have a clear and unambiguous NACK from you on having the clocks property in the simplefb dt node, and if you do so I expect a proof of concept patch from you with an alternative solution within a week, or can you please stop blocking this from getting merged? And again, if you believe this will cause some sort of dt compat issues or whatever, no one is making you use this property for your boards! 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] A80 mixed OS (Linux / RTOS)
ons 2014-10-01 klockan 09:38 +0200 skrev Jorge: You'll need to run an hypervisor to arbitre the access to shared resources for the two OSs Not really if all you want is to run a simple RTOS on one core, and not sharing any I/O resources. To do that basically all you need is to reserve the memory and CPU so the Linux kenel don't stomp on it. But yes, using a hypervisor like XEN gives you a more flexible separation and plenty of options and cleaner upgrade path to other hardware. Keep in mind that there is some vital shared resources like PLL, SDRAM, CPU cache and a bit more that will cause sideeffects on the RTOS from the concurrently running Linux part. Regarding using the OpenRISC(?) co-processor in later Allwinner CPUs then it looks like Allwinner is sitting tight on it's specifications and toolchain requirements, so using it is not really a viable option. The one seen in A31 looked like a plain OpenRISC one, but in A80 I am not so sure what it is, and the largest piece of code blob for it in the SDK seems to be encrypted for some strange reason. 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.
Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code
On Wed, Oct 1, 2014 at 1:26 PM, Hans de Goede hdego...@redhat.com wrote: Hi, On 10/01/2014 07:05 PM, Mark Brown wrote: On Wed, Oct 01, 2014 at 02:48:02PM +0200, Thierry Reding wrote: On Wed, Oct 01, 2014 at 01:32:50PM +0100, Mark Brown wrote: So don't do that if you're worried about it then, provide the bits of DT that hook everything up from the start or otherwise describe things as being in use. Otherwise describe things as being in use doesn't work for clocks for example. And Mike already said he wasn't willing to add something like an always-on DT property for clocks. That's not the only way of doing things - another way would be to have a stub driver that just holds the resources while working on getting a full one in place for example. That won't work because the real driver which will eventually replace the stub one will likely be a module, and then we will loose video output between the kernel finalizing the initial boot, and the module actually loading. Is this correct? Do the clocks really get shut off before a driver on initrd can load? I agree this is true if you wait until user space is fully up and stick this driver out on a disk drive. We've been over all this again and again and again. RGH! All solutions provided sofar are both tons more complicated, then the simple solution of simply having the simplefb dt node declare which clocks it needs. And to make things worse all of them sofar have unresolved issues (due to their complexity mostly). With the clocks in the simplefb node, then all a real driver has to do, is claim those same clocks before unregistering the simplefb driver, and everything will just work. Yet we've been discussing this for months, all because of some vague worries from Thierry, and *only* from Thierry that this will make simplefb less generic / not abstract enough, while a simple generic clocks property is about as generic as things come. This madness has to end! Thierry can we please have a clear and unambiguous NACK from you on having the clocks property in the simplefb dt node, and if you do so I expect a proof of concept patch from you with an alternative solution within a week, or can you please stop blocking this from getting merged? And again, if you believe this will cause some sort of dt compat issues or whatever, no one is making you use this property for your boards! 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 10/01/2014 11:54 AM, jonsm...@gmail.com wrote: On Wed, Oct 1, 2014 at 1:26 PM, Hans de Goede hdego...@redhat.com wrote: ... We've been over all this again and again and again. RGH! All solutions provided sofar are both tons more complicated, then the simple solution of simply having the simplefb dt node declare which clocks it needs. And to make things worse all of them sofar have unresolved issues (due to their complexity mostly). With the clocks in the simplefb node, then all a real driver has to do, is claim those same clocks before unregistering the simplefb driver, and everything will just work. Yet we've been discussing this for months, all because of some vague worries from Thierry, and *only* from Thierry that this will make simplefb less generic / not abstract enough, while a simple generic clocks property is about as generic as things come. Note: I haven't been following this thread, and really don't have the time to get involved, but I did want to point out one thing: As I think I mentioned very early on in this thread, one of the big concerns when simplefb was merged was that it would slowly grow and become a monster. As such, a condition of merging it was that it would not grow features like resource management at all. That means no clock/regulator/... support. It's intended as a simple stop-gap between early platform bringup and whenever a real driver exists for the HW. If you need resource management, write a HW-specific driver. The list archives presumably have a record of the discussion, but I don't know the links off the top of my head. If nobody other than Thierry is objecting, presumably the people who originally objected simply haven't noticed this patch/thread. I suppose it's possible they changed their mind. BTW, there's no reason that the simplefb code couldn't be refactored out into a support library that's used by both the simplefb we currently have and any new HW-specific driver. It's just that the simplefb binding and driver shouldn't grow. -- 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 Wed, Oct 01, 2014 at 12:12:20PM -0600, Stephen Warren wrote: On 10/01/2014 11:54 AM, jonsm...@gmail.com wrote: On Wed, Oct 1, 2014 at 1:26 PM, Hans de Goede hdego...@redhat.com wrote: ... We've been over all this again and again and again. RGH! All solutions provided sofar are both tons more complicated, then the simple solution of simply having the simplefb dt node declare which clocks it needs. And to make things worse all of them sofar have unresolved issues (due to their complexity mostly). With the clocks in the simplefb node, then all a real driver has to do, is claim those same clocks before unregistering the simplefb driver, and everything will just work. Yet we've been discussing this for months, all because of some vague worries from Thierry, and *only* from Thierry that this will make simplefb less generic / not abstract enough, while a simple generic clocks property is about as generic as things come. Note: I haven't been following this thread, and really don't have the time to get involved, but I did want to point out one thing: As I think I mentioned very early on in this thread, one of the big concerns when simplefb was merged was that it would slowly grow and become a monster. As such, a condition of merging it was that it would not grow features like resource management at all. That means no clock/regulator/... support. It's intended as a simple stop-gap between early platform bringup and whenever a real driver exists for the HW. If you need resource management, write a HW-specific driver. The list archives presumably have a record of the discussion, but I don't know the links off the top of my head. If nobody other than Thierry is objecting, presumably the people who originally objected simply haven't noticed this patch/thread. I suppose it's possible they changed their mind. BTW, there's no reason that the simplefb code couldn't be refactored out into a support library that's used by both the simplefb we currently have and any new HW-specific driver. It's just that the simplefb binding and driver shouldn't grow. Define resource management. Simplefb should never alter resources. It should never alter anything that $bootloader set up. It should however claim resources to prevent them from being altered. Perhaps the word managing should be split up in claiming and altering here. 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] Re: [PATCH 4/4] simplefb: add clock handling code
On Wed, Oct 1, 2014 at 12:30 AM, Thierry Reding thierry.red...@gmail.com wrote: On Tue, Sep 30, 2014 at 02:37:53PM -0700, Mike Turquette wrote: 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. I think that's better than before, but I don't think it's accurate yet. As pointed out by Maxime unused clock may still be disabled if it's part of a tree and that tree is being disabled because there are no users left. It is entirely accurate. This feature does in fact prevent the clock framework from *automatically* gating clock And it was merged by Olof so that he could use simplefb with the Chromebook! What I had argued is that it's unexpected behavior, because the clock is still unused (or becomes unused again), therefore shouldn't be disabled at that point either. Leaving clocks enabled because nobody claimed them is not an option. So if you want to keep the current behaviour where an unused clock can still be disabled depending on what other users do, then I think it'd be good to mention that as a potential caveat. Do you have a suggestion on the wording? Thanks, Mike Thierry -- 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 Wed, Oct 1, 2014 at 7:17 PM, Mark Brown broo...@kernel.org wrote:
Well, I don't think it should because it describes the same resources
that the device tree node for the real device already describes. But
perhaps this is one of the cases where duplication isn't all that bad?
If we were worried about this wecould also do it by referring to
those nodes and saying get all the resources these things need rather
than duplicating the references (this might make it easier to work out
when the system is ready to hand off to the real drivers).
You can have a single node for both simplefb and the later real driver.
DT describes the hardware, not the software ecosystem running on the
hardware. Clock, regulators, etc. don't change from a hardware point of
view.
If the firmware initialized a suitable graphics mode, it just has to add
linux,simplefb to the compatible property (and perhaps a few other
simplefb-specific properties).
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
--
You received this message because you are subscribed to the Google Groups
linux-sunxi group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: ir_rx should be ir0_rx in all A20 fex files
Patrick is this still an issue? I just compiled sugar-cubieboard2 from the version 9 SDK, updated the default sys_config.fex in the sun7i/android directories but am not getting a functional IR. 3ir_init: ir_wakeup script_get_item error. 3ir_init: power_key script_get_item error. 3ir_init: ir_addr_code script_get_item error. 7sun7i-ir script_get_item,ir_wakeup:0, power_key:57,ir_addr_code:9f00 7keyname:ir_para subname:ir_rate ,get error! 6input: sun7i-ir as /devices/virtual/input/input3 Also can't find any info for ir_rate that could be in the fex file, but I did see a rate value in the sun7i-ir.c source in the linux-3.4 tree. On Wednesday, December 11, 2013 12:40:36 AM UTC-5, Patrick Wood wrote: I just noticed that all the A20 fex files use ir_rx = port:PB042defaultdefaultdefault but the code in ./drivers/input/keyboard/sunxi-ir.c looks for ir0_rx: drivers/input/keyboard/sunxi-ir.c: ir_gpio_hdle = gpio_request_ex(ir_para, ir0_rx); Pat -- 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: gslx680 driver ported to sunxi
Hi Kristijan,
Not sure quite what your after, but here is a new, not tested yet (would
have to dig up the tablet), firmware extractor.
It uses just readelf, objcopy and dd. Quick and dirty python for shell
implementation.
Hopefully this should help.
Joe
On 01/10/14 10:00, Kristijan Vrban wrote:
Hello,
attached is a gslX680.ko module from a Q88 A23 based tablet (the cheap
USD 32 devices) I just started to extract the firmware to use gsl1680
IC with the touch panels that are used in this Q88 devices.
I think GSL1680_K70_FW should be the one. from this module.
Attached is also a small PCB design made in eagle to make test
connection between that touch panels and I2C interface. Maybe it
is useful for someone.
Kristijan
--
You received this message because you are subscribed to a topic in the
Google Groups linux-sunxi group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/linux-sunxi/SZGxiTQcFyY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
linux-sunxi+unsubscr...@googlegroups.com
mailto: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.
#! /usr/bin/python
from subprocess import *
import sys
import os
if len(sys.argv) != 2:
print Firware extractor.\n
print Requires elf file (driver) argument
sys.exit(1)
filename = sys.argv[1]
call(['objcopy','-I','elf32-little','-j','.rodata','-O','binary',filename,'temp.bin'])
p = Popen(['/bin/sh', '-c', 'readelf -s '+ filename +' | grep FW'], stdout=PIPE)
for line in p.stdout:
args = line.split()
print Found, args[7], offset, int(args[1],16), count, args[2]
call(['dd','if=temp.bin','bs=1','count='+args[2], 'skip='+str(int(args[1],16)),'of='+args[7] + .fw])
os.unlink('temp.bin')
