[linux-sunxi] [PATCH] ARM: dts: sun9i: Enable ARM architected timer on A80
The A80 SoC has the architected timer, but the existing firmware from
Allwinner does not set CNTFRQ at all.
Signed-off-by: Chen-Yu Tsai w...@csie.org
---
I'm not so sure about the cpu mask, but there's no SMP
support to actually test it.
---
arch/arm/boot/dts/sun9i-a80.dtsi | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/sun9i-a80.dtsi b/arch/arm/boot/dts/sun9i-a80.dtsi
index 2f7f82cc86ba..d46c0c70101c 100644
--- a/arch/arm/boot/dts/sun9i-a80.dtsi
+++ b/arch/arm/boot/dts/sun9i-a80.dtsi
@@ -114,6 +114,16 @@
reg = 0 0x2000 0x02 0;
};
+ timer {
+ compatible = arm,armv7-timer;
+ interrupts = GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(4) |
IRQ_TYPE_LEVEL_LOW),
+GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(4) |
IRQ_TYPE_LEVEL_LOW),
+GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(4) |
IRQ_TYPE_LEVEL_LOW),
+GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(4) |
IRQ_TYPE_LEVEL_LOW);
+ clock-frequency = 2400;
+ arm,cpu-registers-not-fw-configured;
+ };
+
clocks {
#address-cells = 1;
#size-cells = 1;
--
2.1.4
--
You received this message because you are subscribed to the Google Groups
linux-sunxi group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: [RFC] Serial number on sunxi devices
ons 2015-03-18 klockan 08:55 +0100 skrev Olliver Schinagl: I'm all for common methods, but you are suggesting to use a single dedicated page purely for the MAC address? Where is it defined which page that is? And what about using the subsequent page for stuff like a crc/checksum and verify the mac against that? It would yield in an easy way to verify if there is actually a MAC stored there or not. What I am saying is that unless you are doing a very high volume then the most practical approach to get a real MAC is to buy them as preprogrammed eeproms, for example Microchip 24AA02E48. There is no checksum what so ever in these devices, only the MAC at a predefined location (write protected). There is also some small amount of unprotected space for custom data if needed (can often be protected after programming). 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] r3p2 version of the Mali driver A20
On Tue, 17 Mar 2015 18:14:59 -0700 (PDT) @lex alex.mob...@gmail.com wrote: Hi, I would like to have r3p2 version of the Mali driver for my cb2, and i have followed the sunxi-linux instructions and ended up with r3p0. The r3p0 mali driver should provide you with a functional OpenGL ES implementation. i have found the tutorial to use the recent mali r3p2 but i am not sure how to proceed. I am using sunxi-linux kernel 3.4.103 but i don`t know if it has r3p2 mali driver, can someone help how to get r3p2 compiled? And how to get mali-r3p2-support branch of the xf86-video-fbturbo xorg? Appreciate any help. The r3p0 and r3p2 mali binary blobs are a little bit buggy. Moreover, they are buggy in different ways and require different sets of workarounds. Officially supporting them both would be an extra hassle. Moving exclusively to r3p2 is not totally painless either. There needs to be a very good reason to do this work. -- Best regards, Siarhei Siamashka -- 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: [PATCH] pinctrl: sun4i: GPIOs configured as irq must be set to input before reading
On Sun, Mar 8, 2015 at 10:13 PM, Hans de Goede hdego...@redhat.com wrote: On sun4i-a10, when GPIOs are configured as external interrupt the value for them in the data register does not seem to get updated, so set their mux to input (and restore afterwards) when reading the pin. Missed edges seem to be buffered, so this does not introduce a race condition. I've also tested this on sun5i-a13 and sun7i-a20 and those do not seem to be affected, the input value representation in the data register does seem to correctly get updated to the actual pin value while in irq mode there. Signed-off-by: Hans de Goede hdego...@redhat.com Patch applied for fixes with Maxime's ACK. Yours, Linus Walleij -- 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: [PATCH 2/3] ARM: sun8i: Add SMP support for the Allwinner A23
On Wed, Mar 18, 2015 at 11:24:01AM +0800, Chen-Yu Tsai wrote:
The A23 is a dual Cortex-A7. Add the logic to use the IPs used to
control the CPU configuration and the CPU power so that we can
bring up secondary CPUs at boot.
Signed-off-by: Chen-Yu Tsai w...@csie.org
---
We can't use of_io_request_and_map() here, as it will conflict
with PRCM, and leave us without a serial console.
I think a proper way to solve this would be a syscon device or
something like the mfd-simple device posted by Arnd.
---
Documentation/devicetree/bindings/arm/cpus.txt | 1 +
arch/arm/mach-sunxi/platsmp.c | 69
++
2 files changed, 70 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/cpus.txt
b/Documentation/devicetree/bindings/arm/cpus.txt
index 8b9e0a95de31..40202d85b132 100644
--- a/Documentation/devicetree/bindings/arm/cpus.txt
+++ b/Documentation/devicetree/bindings/arm/cpus.txt
@@ -188,6 +188,7 @@ nodes to be present and contain the properties described
below.
# On ARM 32-bit systems this property is optional and
can be one of:
allwinner,sun6i-a31
+ allwinner,sun8i-a23
arm,psci
brcm,brahma-b15
marvell,armada-375-smp
diff --git a/arch/arm/mach-sunxi/platsmp.c b/arch/arm/mach-sunxi/platsmp.c
index 587b0468efcc..e8483ec79d67 100644
--- a/arch/arm/mach-sunxi/platsmp.c
+++ b/arch/arm/mach-sunxi/platsmp.c
@@ -121,3 +121,72 @@ static struct smp_operations sun6i_smp_ops __initdata = {
.smp_boot_secondary = sun6i_smp_boot_secondary,
};
CPU_METHOD_OF_DECLARE(sun6i_a31_smp, allwinner,sun6i-a31, sun6i_smp_ops);
+
+static void __init sun8i_smp_prepare_cpus(unsigned int max_cpus)
+{
+ struct device_node *node;
+
+ node = of_find_compatible_node(NULL, NULL, allwinner,sun8i-a23-prcm);
+ if (!node) {
+ pr_err(Missing A23 PRCM node in the device tree\n);
+ return;
+ }
+
+ prcm_membase = of_iomap(node, 0);
+ if (!prcm_membase) {
+ pr_err(Couldn't map A23 PRCM registers\n);
+ return;
+ }
+
+ node = of_find_compatible_node(NULL, NULL,
+allwinner,sun8i-a23-cpuconfig);
+ if (!node) {
+ pr_err(Missing A23 CPU config node in the device tree\n);
+ return;
+ }
+
+ cpucfg_membase = of_iomap(node, 0);
+ if (!cpucfg_membase)
+ pr_err(Couldn't map A23 CPU config registers\n);
+
+}
+
+static int sun8i_smp_boot_secondary(unsigned int cpu,
+ struct task_struct *idle)
+{
+ u32 reg;
+
+ if (!(prcm_membase cpucfg_membase))
+ return -EFAULT;
+
+ spin_lock(cpu_lock);
+
+ /* Set CPU boot address */
+ writel(virt_to_phys(secondary_startup),
+cpucfg_membase + CPUCFG_PRIVATE0_REG);
One question I couldn't find any answer to is that does the SMP bit is
set in secondary_startup?
I couldn't find where it was set, but it still looks like the right
thing to do, so I would expect the code to do that.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
You received this message because you are subscribed to the Google Groups
linux-sunxi group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: Digital signature
Re: [linux-sunxi] r3p2 version of the Mali driver A20
2015-03-18 11:36 GMT+03:00 Siarhei Siamashka siarhei.siamas...@gmail.com: On Tue, 17 Mar 2015 18:14:59 -0700 (PDT) @lex alex.mob...@gmail.com wrote: Hi, I would like to have r3p2 version of the Mali driver for my cb2, and i have followed the sunxi-linux instructions and ended up with r3p0. The r3p0 mali driver should provide you with a functional OpenGL ES implementation. i have found the tutorial to use the recent mali r3p2 but i am not sure how to proceed. I am using sunxi-linux kernel 3.4.103 but i don`t know if it has r3p2 mali driver, can someone help how to get r3p2 compiled? And how to get mali-r3p2-support branch of the xf86-video-fbturbo xorg? Appreciate any help. The r3p0 and r3p2 mali binary blobs are a little bit buggy. Moreover, they are buggy in different ways and require different sets of workarounds. Officially supporting them both would be an extra hassle. Moving exclusively to r3p2 is not totally painless either. There needs to be a very good reason to do this work. Any chances to test r4pX and r5p0 coming from ODROID community? -- Best regards, Siarhei Siamashka Best Regards, Dmitriy Beykun -- 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] r3p2 version of the Mali driver A20
On Wed, 18 Mar 2015 11:50:20 +0300 Dmitriy B. rzk...@gmail.com wrote: 2015-03-18 11:36 GMT+03:00 Siarhei Siamashka siarhei.siamas...@gmail.com: On Tue, 17 Mar 2015 18:14:59 -0700 (PDT) @lex alex.mob...@gmail.com wrote: Hi, I would like to have r3p2 version of the Mali driver for my cb2, and i have followed the sunxi-linux instructions and ended up with r3p0. The r3p0 mali driver should provide you with a functional OpenGL ES implementation. i have found the tutorial to use the recent mali r3p2 but i am not sure how to proceed. I am using sunxi-linux kernel 3.4.103 but i don`t know if it has r3p2 mali driver, can someone help how to get r3p2 compiled? And how to get mali-r3p2-support branch of the xf86-video-fbturbo xorg? Appreciate any help. The r3p0 and r3p2 mali binary blobs are a little bit buggy. Moreover, they are buggy in different ways and require different sets of workarounds. Officially supporting them both would be an extra hassle. Moving exclusively to r3p2 is not totally painless either. There needs to be a very good reason to do this work. Any chances to test r4pX and r5p0 coming from ODROID community? It would be best if we could get up to date Mali binaries from Allwinner. I suspect that the ODROID blobs have an EULA, which forbids us to use them. -- Best regards, Siarhei Siamashka -- 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: [PATCH] Input: sun4i-ts - allow to adjust some settings via device-tree properties.
On Thu, Mar 12, 2015 at 04:45:50PM +0100, Jens Thiele wrote: This commit introduces two new optional device-tree properties: tp-sensitive-adjust: adjust sensitivity of pen down detection filter-type: select median and averaging filter The previous fixed defaults, didn't work well for the Olimex A13-LCD10TS (I have). Signed-off-by: Jens Thiele ka...@karme.de --- .../devicetree/bindings/input/touchscreen/sun4i.txt | 19 +-- drivers/input/touchscreen/sun4i-ts.c| 17 + 2 files changed, 30 insertions(+), 6 deletions(-) diff --git a/Documentation/devicetree/bindings/input/touchscreen/sun4i.txt b/Documentation/devicetree/bindings/input/touchscreen/sun4i.txt index 42d..c93edfa 100644 --- a/Documentation/devicetree/bindings/input/touchscreen/sun4i.txt +++ b/Documentation/devicetree/bindings/input/touchscreen/sun4i.txt @@ -8,8 +8,20 @@ Required properties: - #thermal-sensor-cells: shall be 0 Optional properties: - - allwinner,ts-attached: boolean indicating that an actual touchscreen is - attached to the controller + - allwinner,ts-attached : boolean indicating that an actual touchscreen +is attached to the controller + - allwinner,tp-sensitive-adjust : integer (4 bits) +adjust sensitivity of pen down detection +between 0 (least sensitive) and 15 +(defaults to 15) + - allwinner,filter-type : integer (2 bits) +select median and averaging filter +samples used for median / averaging filter +0: 4/2 +1: 5/3 +2: 8/4 +3: 16/8 +(defaults to 1) You shouldn't rely on any bits length in your binding. And this looks really more of a configuration option, and would be better exposed through sysfs. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: Digital signature
Re: [linux-sunxi] Re: [RFC] Serial number on sunxi devices
Am 18.03.2015, 08:55 Uhr, schrieb Olliver Schinagl oli...@schinagl.nl: Hey Henrik, On 18-03-15 08:51, Henrik Nordström wrote: mån 2015-03-16 klockan 11:13 +0100 skrev Hans de Goede: I see, yes using olinuxino's embedded in factory devices is a valid reason, so I will be happy to take patches for reading the MAC from the eeprom, we will need to do some tests to make sure that we only do this on valid eeproms though, I think it would be good to add a checksum + all 00 test, or a crc check, note a checksum is fine by me, but if there is ready to use crc code somewhere in u-boot that works for me too. The MAC eeproms I have seen do not have any CRC. Just the raw MAC in a dedicated page. Better to follow common practice in how MAC is stored. There is room for additional data in other pages as well. I'm all for common methods, but you are suggesting to use a single dedicated page purely for the MAC address? Where is it defined which page that is? And what about using the subsequent page for stuff like a crc/checksum and verify the mac against that? It would yield in an easy way to verify if there is actually a MAC stored there or not. Olliver Regards Henrik Just to get the technical aspects cleared: As far as I believe to know, each manufacturer of products with Ethernet interfaces is obliged to apply for MAC addresses for the products he puts on the market. If he does not follow that rule then it is somehow a rouge product? Most often these addresses are stored in an eeprom directly connected to the interface chip, but other locations have been found in the wild. I think that for the MAC used, sunxi must make sure that on all supported hardware the MAC planned by the board manufacturer will be used as default. If a board manufacturer somewhere permanently stores a serial number, sunxi should try to display that number. If no such number is present, it seems to be a good idea to show the MAC number as a serial number. If the number displayed is somehow 'wrong' imho this does not really harm? I don't understand why checksums and other nasty problems come to play a role? I.Irgendeiner -- 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: [RFC] Serial number on sunxi devices
From: Henrik Nordström hen...@henriknordstrom.net To: linux-sunxi@googlegroups.com Sent: Wednesday, 18 March 2015, 10:17 Subject: Re: [linux-sunxi] Re: [RFC] Serial number on sunxi devices ons 2015-03-18 klockan 10:16 +0100 skrev Irgendeiner: I don't understand why checksums and other nasty problems come to play a role? Not for MAC assignment, but general configuration data or integrity validation purpose sure. The MAC should have bit 0 of the first octet unset so it is unicast, not multicast. Also if you are using a locally created MAC, not universally allocated, then bit 1 of the same octet should be set. For more details see: http://linux-sunxi.org/Ethernet#Setting_the_MAC_address http://www.denx.de/wiki/view/DULG/WhereCanIGetAValidMACAddress Al -- 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] Input: sun4i-ts - allow to adjust some settings via device-tree properties.
Hi, On 18-03-15 11:37, Maxime Ripard wrote: On Thu, Mar 12, 2015 at 04:45:50PM +0100, Jens Thiele wrote: This commit introduces two new optional device-tree properties: tp-sensitive-adjust: adjust sensitivity of pen down detection filter-type: select median and averaging filter The previous fixed defaults, didn't work well for the Olimex A13-LCD10TS (I have). Signed-off-by: Jens Thiele ka...@karme.de --- .../devicetree/bindings/input/touchscreen/sun4i.txt | 19 +-- drivers/input/touchscreen/sun4i-ts.c| 17 + 2 files changed, 30 insertions(+), 6 deletions(-) diff --git a/Documentation/devicetree/bindings/input/touchscreen/sun4i.txt b/Documentation/devicetree/bindings/input/touchscreen/sun4i.txt index 42d..c93edfa 100644 --- a/Documentation/devicetree/bindings/input/touchscreen/sun4i.txt +++ b/Documentation/devicetree/bindings/input/touchscreen/sun4i.txt @@ -8,8 +8,20 @@ Required properties: - #thermal-sensor-cells: shall be 0 Optional properties: - - allwinner,ts-attached: boolean indicating that an actual touchscreen is - attached to the controller + - allwinner,ts-attached: boolean indicating that an actual touchscreen + is attached to the controller + - allwinner,tp-sensitive-adjust : integer (4 bits) + adjust sensitivity of pen down detection + between 0 (least sensitive) and 15 + (defaults to 15) + - allwinner,filter-type: integer (2 bits) + select median and averaging filter + samples used for median / averaging filter + 0: 4/2 + 1: 5/3 + 2: 8/4 + 3: 16/8 + (defaults to 1) You shouldn't rely on any bits length in your binding. And this looks really more of a configuration option, and would be better exposed through sysfs. Erm, no, this is to adjust for properties of the touchscreen, so this is hardware configuration, and as such definitely belongs in the dts. Regards, Hans -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: [RFC] Serial number on sunxi devices
Hey Henrik, On 18-03-15 08:51, Henrik Nordström wrote: mån 2015-03-16 klockan 11:13 +0100 skrev Hans de Goede: I see, yes using olinuxino's embedded in factory devices is a valid reason, so I will be happy to take patches for reading the MAC from the eeprom, we will need to do some tests to make sure that we only do this on valid eeproms though, I think it would be good to add a checksum + all 00 test, or a crc check, note a checksum is fine by me, but if there is ready to use crc code somewhere in u-boot that works for me too. The MAC eeproms I have seen do not have any CRC. Just the raw MAC in a dedicated page. Better to follow common practice in how MAC is stored. There is room for additional data in other pages as well. I'm all for common methods, but you are suggesting to use a single dedicated page purely for the MAC address? Where is it defined which page that is? And what about using the subsequent page for stuff like a crc/checksum and verify the mac against that? It would yield in an easy way to verify if there is actually a MAC stored there or not. Olliver 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: Communication with Allwinner
Hi Henrik, Yes, I have but let's make sure I did not miss anything: I looked at the SDK that appeared a while ago where versions of both linux-3.4 and u-boot-2011.01 can be found (under lichee and lichee/brandy). In both places I found the sunxi video drivers and specifically the HDMI files (under aw directory). The file hdmi_core.c is the one where the HW initialisation appeared in the past, but now it is basically empty and calls a function sunxi_video_config(vic) whose source is unavailable (I assume that it is compiled inside libhdcp). That's the most important missing piece. The A80 user manual also does not contain any info about the HDMI module. Raanan On Wednesday, March 18, 2015 at 9:35:39 AM UTC+2, Henrik Nordström wrote: tis 2015-03-17 klockan 09:38 -0700 skrev RFat: I wonder if there is any progress on getting the basic info. behind the HDMI module in the A80 chip (registers/initialization code)? Any prospects whether such info. will become public anytime soon? Have you looked at the existing code? 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: [RFC] Serial number on sunxi devices
Hi, On Wed, 18 Mar 2015 09:12:47 +0100, Henrik Nordström hen...@familjen-nordstrom.se wrote: ons 2015-03-18 klockan 08:55 +0100 skrev Olliver Schinagl: I'm all for common methods, but you are suggesting to use a single dedicated page purely for the MAC address? Where is it defined which page that is? And what about using the subsequent page for stuff like a crc/checksum and verify the mac against that? It would yield in an easy way to verify if there is actually a MAC stored there or not. What I am saying is that unless you are doing a very high volume then the most practical approach to get a real MAC is to buy them as preprogrammed eeproms, for example Microchip 24AA02E48. There is no checksum what so ever in these devices, only the MAC at a predefined location (write protected). There is also some small amount of unprotected space for custom data if needed (can often be protected after programming). Yes, this is exactly our case. We have LIME with additional board with Microchip MCP79401. This is RTC+EEPROM with preprogrammed (and somehow protected) MAC. That particular EEPROM has only 64-bits without any checksum. I just trust that the MAC is stored in I2C EEPROM at address X in a register Y. Best regards, Tomas 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: Communication with Allwinner
ons 2015-03-18 klockan 01:58 -0700 skrev RFat: The file hdmi_core.c is the one where the HW initialisation appeared in the past, but now it is basically empty and calls a function sunxi_video_config(vic) whose source is unavailable (I assume that it is compiled inside libhdcp). That's the most important missing piece. The A80 user manual also does not contain any info about the HDMI module. Ouch. You seem to be right. 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] Directions for video engine support (CedarX)
Hello, as this does not seem to get any attention from anyone who has some idea about VE I will try to write some high level info which is hopefully not completely wrong. On 16 March 2015 at 14:44, Simos Xenitellis simos.li...@googlemail.com wrote: Hi All, I recently I had a conversation with Manuel about what can be done for better support for the video engine (CedarX) that is found in the A-series of SoCs from Allwinner. The way I understood all these was that there are short-term and long-term goals for better support with the video engine. The long-term goal would be to support CedarX in Video4Linux2 (V4L2), as it is already described in http://linux-sunxi.org/VE_Planning It makes sense to have CedarX supported in V4L2 (Linux kernel) as it is part of the mainlining process of the Allwinner SoCs. There are some open questions that need discussion (such as feasibility, what resources are needed, etc). This is most likely feasible. If the current v4l2 framework cannot work with cedar hardware it should be updated to work with it. Existing hardware is undisputable reality. In addition, it is important to describe the benefits from having CedarX support in V4L2 and especially when we should expect to have the first benefits when starting work on this. The benefit is that the v4l2 framework is a standard linux interface. Presumably adding support for v4l2 on application side and writing v4l2 driver on kernel side should be something you do once for good. From then on the application should not be bothered by new hardware codecs emerging and the codec drivers not bothered by new applications emerging. Practically different applications use different features and different codecs implement different features so there is always room for finding new and exciting bugs everywhere. Also Cedar will probably be one of the first VEs to have such driver. Also related is that the v4l2 driver should share buffers with any image postprocessing engine(s) and display engine(s) (such as the sunxi KMS driver) and camera drivers using some kernel-wide buffer management. Ideally, the buffers can be passed around by a handle without the application using the drivers ever looking at them (unless it has some actual use for the data) or the kernel copying them. Hardware restrictions and driver defects may apply. I would like to let Manuel to take over here, explain and expand on what his thoughts are. The short-term goals would be to use better what is available now, include libvdpau (anything needs fixing?) AFAIK the libvdpau is more proof of concept than a finished driver. It is usable with mplayer and probably implements exactly the features mplayer uses. Using it with other players may need implementing new features. Also the output is always on top regardless of X11 window stacking. This is because it programs the hardware directly. X11 integration would require that the X11 driver programs the hardware instead and figures out what to do when the video output is *not* on top. All this using the obsolete Allwinner video driver. HTH 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: [RFC] Serial number on sunxi devices
ons 2015-03-18 klockan 10:16 +0100 skrev Irgendeiner: I think that for the MAC used, sunxi must make sure that on all supported hardware the MAC planned by the board manufacturer will be used as default. Problem with most boards is that there is no MAC, and if there is one then it's not in a by any means standardized storage, personalized in the NAND bootloader arguments which is easily lost when dealing with other software. So far I only know of some Olimex boards having an eeprom specifically for the MAC address, but not sure it actually is an MAC in there. I don't understand why checksums and other nasty problems come to play a role? Not for MAC assignment, but general configuration data or integrity validation purpose sure. Regards Henrik -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH] ARM: dts: sun9i: Enable ARM architected timer on A80
On Wed, Mar 18, 2015 at 04:00:28PM +0800, Chen-Yu Tsai wrote: The A80 SoC has the architected timer, but the existing firmware from Allwinner does not set CNTFRQ at all. Signed-off-by: Chen-Yu Tsai w...@csie.org Merged, thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: Digital signature
Re: [linux-sunxi] [PATCH 3.4 0/4] Various fixes to make linux-sunxi work with new u-boot
On Sun, 15 Mar 2015 15:05:42 +0100 Paul Kocialkowski cont...@paulk.fr wrote: Le dimanche 15 mars 2015 à 14:10 +0200, Siarhei Siamashka a écrit : On Sun, 15 Mar 2015 12:12:00 +0100 Paul Kocialkowski cont...@paulk.fr wrote: Le mardi 24 février 2015 à 11:58 +0200, Siarhei Siamashka a écrit : On Sat, 21 Feb 2015 16:47:20 +0100 Hans de Goede hdego...@redhat.com wrote: Hi all, Newer u-boot versions may chose a different (better) PLL6 / PLL5 setting and/or different voltage settings. Unfortunately the old linux-sunxi-3.4 kernels have a number of hardcoded assumptions about PLL5 speed, and in some cases override the bootloader chosen PLL6 / voltages in a bad way. This patch series fixes this and is intended for the sunxi-3.4 branch. The first 2 patches are already in sunxi-3.4/staging, but they should really also be added to the sunxi-3.4 branch. The 2 new patches should be added to both. Note that sunxi-3.4/staging currently does not work for me (on sun5i at least) (*) so these patches have only been tested on the sunxi-3.4 branch. Regards, Hans *) It does not boot at all for some reason, not a single message is printed on the serial console after u-boot has loaded the kernel. I'm afraid I do not have the time to investigate this. Thanks. I will allocate the next few days of my time on checking what's up with sunxi-3.4 and maybe we can make the final graduation release for it. Any news on that front? Thanks for reminding. Well, the news is that I could not reproduce the alleged sun5i problem with the stage/sunxi-3.4 branch on my A13-OLinuXino-Micro board. Which obviously means that I can't debug it. Well, last time I checked, I didn't experience any particular problem with mainline U-Boot and sunxi-3.4 on sun5i/A13 but I probably lack context on this. There was just a report that the current sunxi-3.4 branch is good and the stage/sunxi-3.4 is bad on sun5i hardware. But I could not confirm this myself. Now we have a kind of The Three Musketeers scenario :-) Some users had been lost along the way just because they have settled with some old sunxi-3.4 release, which worked good enough for them. And these users don't have any motivation for upgrading further. For example, this is exactly what Olimex is doing with the 3.4 kernel: https://github.com/OLIMEX/OLINUXINO/tree/master/SOFTWARE/A20/A20-build Apparently they settled with 36080eb05e9a1e96d58e3168631d3cc9c612a0e3 revision and also carry some extra patches of their own. Then Olimex discovered the interoperability problem with the mainline u-boot (in a hard way, because the failure was non-obvious) and complained in the mailing list. This thread is exactly a response to the Olimex problem. However we have not heard from them back. And this probably means that they just made their legacy snapshot work correctly but could not care less about the fixes in the up to date sunxi-3.4 and stage/sunxi-3.4 branches. Effectively, we have no real testers for the newest fixes. To add an insult to injury, there is also a vague report about the problems on sun5i hardware in the stage/sunxi-3.4 branch. Very nice, isn't it? Anyway, the patches are now in the stage/sunxi-3.4 branch and the relevant information is available in the linux-sunxi wiki: http://linux-sunxi.org/Mainline_U-boot#Troubleshooting This should cover all the use cases. And I think that the problem is basically resolved now. Combined with Tsvetan's lack of any sign of response or any indications that anyone else could be interested, I don't feel very much motivated to do the communication part of the job, which is required to clarify the status of these 3.4 branches and move them forward. Still, I would be interested in having a sunxi-3.4 branch that can actually be used on all the supported chips and devices. Well, the idea is that it already can be used on all the supported chips and devices. And nobody needs to touch it anymore unless users report real problems. There is simply no time to do this work. There is even no time to review patches, which do not address important problems. I have been trying to boot sunxi-3.4 on sun7i/A20 using upstream U-Boot, with no success. I tried the current sunxi-3.4 branch and stage/sunxi-3.4, with and without these patches. It never prints anything on serial. Most likely you are missing the setenv bootm_boot_mode sec line in your boot.cmd (otherwise the PSCI code in u-boot drops the CPU into the non-secure mode and the sunxi-3.4 kernel can't handle it). That could be it, I'll investigate. Thanks. The documentation in the wiki about the mainline u-boot is in a pretty much bad shape, but at least this should be covered: http://linux-sunxi.org/Mainline_U-boot#Boot
[linux-sunxi] Re: [PATCH 1/3] ARM: dts: sun8i: Enable ARM architected timer on A23
On Wed, Mar 18, 2015 at 11:24:00AM +0800, Chen-Yu Tsai wrote: The A23 SoC has the architected timer, but the existing firmware from Allwinner does not set CNTFRQ at all. Signed-off-by: Chen-Yu Tsai w...@csie.org Applied, thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: Digital signature
[linux-sunxi] Re: sunxi otg usb code for mainline (wip) available now
Hi, I take a look at your patch, and would like to give it a try on my /bananapi/. vbus is tied to +5V, is there a simple dts patch I could try ? Reagrds, Eric On Friday, February 13, 2015 at 8:25:59 PM UTC+1, Hans de Goede wrote: Hi All, I'm happy to report that after a lot of poking at the Allwinner musb code I've it working reliable in both host and peripheral mode, as well as automatically switching between the 2 depending on which cable gets plugged. My wip code is available here: https://github.com/jwrdegoede/linux-sunxi/commits/sunxi-wip Functionality wise this is complete and I expect / hope there will be no functional changes before it goes upstream. There are 2 things which need to be done before it can be submitted upstream though: 1) All the ForceVbus / ForceID stuff needs to be cleaned up 2) Currently this is not suitable for multiplatform kernels as it puts a #ifdef MACH_SUNXI in musb_regs.h, this needs to be fixed. 1) is just a matter of removing a whole lot of unnecessary indirection in the code, and giving the relevant defines better names 2) I've a plan for, I just need some time for this. I've so far only tested this on a cubietruck, I started development on a cubieboard, but the cubieboard has the Vusb hardwired to the 5V of the board (or at least mine does) meaning that the Vusb enable gpio does not do anything, and Vusb-detect always reads as 1, I think my current code may work despite this, but I need to test. Note that the dts modifications for the cubietruck / cubieboard enable the musb controller in otg mode, which means that it will not start until a gadget driver is loaded. For testing I use: insmod libcomposite.ko insmod u_serial.ko insmod usb_f_acm.ko insmod g_serial.ko After this you should see 2 messages like this: [ 3528.872816] g_serial gadget: Gadget Serial v2.4 [ 3528.877377] g_serial gadget: g_serial ready And then the controller should work either as a usb serial port (ttyGS0 on cubietruck side, ttyACM0 on pc version) or as a usb host, depending on what you plug in, and you should be able to switch on the fly. I use the following on the cubietruck side to start a getty on the usb serial, this assumes you use systemd :) systemctl start serial-getty@ttyGS0.service If you put this in say rc.local, then you can use it to get a console on a tablet over the otg connector, which is very useful for debugging stuff. Regards, Hans -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: r3p2 version of the Mali driver A20
I have looked into ODROID r4p0 blobs and headers and did not find any EULA, perhaps it is kept with the sources? Would be great to catch up with them. On Wednesday, March 18, 2015 at 9:59:04 AM UTC-3, @lex wrote: Sorry if i replied the recipients. If there is an EULA, would i find it when i install the binaries on their SBC? On Tuesday, March 17, 2015 at 10:14:59 PM UTC-3, @lex wrote: Hi, I would like to have r3p2 version of the Mali driver for my cb2, and i have followed the sunxi-linux instructions and ended up with r3p0. i have found the tutorial to use the recent mali r3p2 but i am not sure how to proceed. I am using sunxi-linux kernel 3.4.103 but i don`t know if it has r3p2 mali driver, can someone help how to get r3p2 compiled? And how to get mali-r3p2-support branch of the xf86-video-fbturbo xorg? Appreciate any help. @lex -- 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: What open source community is this?
On Monday, March 16, 2015 at 3:25:01 AM UTC+1, Zhao Zhili wrote: I'm an employee of allwinner, and I joined this mailing list before joined the company. I speak for myself here. I have a Cubieboard2 (I bought it to do real-time vibration control as a graduate students.) runing Linux and want to playback video on that, and I saw some people have the same idea too. I want to find a workable solution, that's all. Thank you for you introduction. That means that a community member, you, has been employed by Allwinner. Good luck on your assignment. So, if we can get all of the source code from allwinner, and work out the complete open source solution, that is the best. If we can't, I want to find out just a workable solution. The graphic card AMD radeon 545v didn't work well with open source driver until Linux kernel 3.13. Before that, I have to use my laptop too, with AMD private driver. It seems that no one takes the cedar binaries as a solution, no matter whether it has been cleaned of not. I think the CedarX binaries will be used. The, legal situation, however does not compare to the AMD drivers. IMO binary software for hardware use is bad in any form. It creates a vendor lock in. But that's an other discussion. LGPL/GPL-ed source-code is free to use to a certain extend. Most important: Distributing products/binaries based on that source-codemust to be shipped with a copy of the Original licence and humanly readable copy of the Modified source-code. The CedarX is build upon GPL/LGPL code and has been already been released/shipped. And as has thus violated the license of that source-code. There is no cleaning possible any more. The only viable solution is to release all parts of the CedarX code which is based on (L)GPL code, Not just the original code but all changes made to it as well. If the copyright owner(s) of that code, which is not Allwinner. now has the power to file import/export prohibition on all devices containing CedarX code. Effectively condemning Allwinner to their local market. Until an Chinese competitor files a suit against Allwinner for shipping illegal code. Making Allwinner very vulnerable. Luc has done a thorough investigation on the latest CedarX, cleaned, form and has found that (L)GPL code still exists in binary form without the required License en Source-code copies. So either CedarX is to havely based on (L)GPL source-code to be separated. Or Allwinner does not understand the issue or the possible problems is arises. The current outcomes are perceived as, bad, attempts to silence the meek. Actions that will only fuel the conflict. Intended or not. If Cedrus is the only workable solution, I will try to figure out how to contribute to this project. If I've understand correctly the current direction is v4l2. http://linux-sunxi.org/VE_Planning On Mon, Mar 16, 2015 at 5:03 AM, Manuel Braga mul@gmail.com wrote: On Sun, 15 Mar 2015 23:51:03 +0800 Quink want...@gmail.com wrote: Sorry Simos, I just want to invite some students in local community to join sunxi and take part in GSOC. And everyone are welcome to join sunxi. And the GSOC idea is not bad, please do invite students. That email has nothing to do with the CedarX. It's so sad that there are so many misunderstand. If we have more I agree, let's resolve this misunderstanding. Simos for whatever reason, still didn't make public what he wrote to me in our private exchange. And this is making me suspicious. Maybe you Quink, could help here. By telling, who are you?, and your connection to allwinner?, if any. What is you want to do? And, what kind of help are expected from linux-sunxi? tolerant attitudes, technical discussing should not become a flashpoint, and we can be more Your technical question that was made in your last email is unanswered because was part of an email that started with a flashpoint. Let's keep the technical discussing, separated from flashpoints. open too. Yes, let's all be open. -- Manuel Braga -- 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.
[linux-sunxi] Re: r3p2 version of the Mali driver A20
Sorry if i replied the recipients. If there is an EULA, would i find it when i install the binaries on their SBC? On Tuesday, March 17, 2015 at 10:14:59 PM UTC-3, @lex wrote: Hi, I would like to have r3p2 version of the Mali driver for my cb2, and i have followed the sunxi-linux instructions and ended up with r3p0. i have found the tutorial to use the recent mali r3p2 but i am not sure how to proceed. I am using sunxi-linux kernel 3.4.103 but i don`t know if it has r3p2 mali driver, can someone help how to get r3p2 compiled? And how to get mali-r3p2-support branch of the xf86-video-fbturbo xorg? Appreciate any help. @lex -- 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: Communication with Allwinner
tis 2015-03-17 klockan 09:38 -0700 skrev RFat: I wonder if there is any progress on getting the basic info. behind the HDMI module in the A80 chip (registers/initialization code)? Any prospects whether such info. will become public anytime soon? Have you looked at the existing code? 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: [RFC] Serial number on sunxi devices
mån 2015-03-16 klockan 11:13 +0100 skrev Hans de Goede: I see, yes using olinuxino's embedded in factory devices is a valid reason, so I will be happy to take patches for reading the MAC from the eeprom, we will need to do some tests to make sure that we only do this on valid eeproms though, I think it would be good to add a checksum + all 00 test, or a crc check, note a checksum is fine by me, but if there is ready to use crc code somewhere in u-boot that works for me too. The MAC eeproms I have seen do not have any CRC. Just the raw MAC in a dedicated page. Better to follow common practice in how MAC is stored. There is room for additional data in other pages as well. Regards Henrik -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] [PATCH 2/2] ARM: dts: sunxi: Remove overclocked/overvoltaged OPP
Without proper regulator support for individual boards, it is dangerous
to have overclocked/overvoltaged OPPs in the list. Cpufreq will increase
the frequency without the accompanying voltage increase, resulting in
an unstable system.
Remove them for now. We can revisit them with the new version of OPP
bindings, which support boost settings and frequency ranges, among
other things.
Signed-off-by: Chen-Yu Tsai w...@csie.org
---
arch/arm/boot/dts/sun5i-a13.dtsi | 3 +--
arch/arm/boot/dts/sun7i-a20.dtsi | 3 +--
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/sun5i-a13.dtsi b/arch/arm/boot/dts/sun5i-a13.dtsi
index 5d9ce84486bb..39264f7c7ae6 100644
--- a/arch/arm/boot/dts/sun5i-a13.dtsi
+++ b/arch/arm/boot/dts/sun5i-a13.dtsi
@@ -140,7 +140,6 @@
clock-latency = 244144; /* 8 32k periods */
operating-points =
/* kHzuV */
- 1104000 150
1008000 140
912000 135
864000 130
@@ -150,7 +149,7 @@
;
#cooling-cells = 2;
cooling-min-level = 0;
- cooling-max-level = 6;
+ cooling-max-level = 5;
};
ehci0 {
diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi
index 3a8530b79f1c..fdd181792b4b 100644
--- a/arch/arm/boot/dts/sun7i-a20.dtsi
+++ b/arch/arm/boot/dts/sun7i-a20.dtsi
@@ -105,7 +105,6 @@
clock-latency = 244144; /* 8 32k periods */
operating-points =
/* kHzuV */
- 1008000 145
96 140
912000 140
864000 130
@@ -116,7 +115,7 @@
;
#cooling-cells = 2;
cooling-min-level = 0;
- cooling-max-level = 7;
+ cooling-max-level = 6;
};
cpu@1 {
--
2.1.4
--
You received this message because you are subscribed to the Google Groups
linux-sunxi group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] [PATCH 1/2] ARM: dts: sun4i: a10-lime: Override and remove 1008MHz OPP setting
The Olimex A10-Lime is known to be unstable when running at 1008MHz.
Signed-off-by: Chen-Yu Tsai w...@csie.org
---
arch/arm/boot/dts/sun4i-a10-olinuxino-lime.dts | 14 ++
1 file changed, 14 insertions(+)
diff --git a/arch/arm/boot/dts/sun4i-a10-olinuxino-lime.dts
b/arch/arm/boot/dts/sun4i-a10-olinuxino-lime.dts
index 31dc2f1c3870..16ecb8938e19 100644
--- a/arch/arm/boot/dts/sun4i-a10-olinuxino-lime.dts
+++ b/arch/arm/boot/dts/sun4i-a10-olinuxino-lime.dts
@@ -74,6 +74,20 @@
status = okay;
};
+cpu0 {
+ /* The A10-Lime is known to be unstable when running at 1008 MHz */
+ operating-points =
+ /* kHzuV */
+ 96 140
+ 912000 140
+ 864000 130
+ 72 120
+ 528000 110
+ 312000 100
+ 144000 90
+ ;
+};
+
ehci0 {
status = okay;
};
--
2.1.4
--
You received this message because you are subscribed to the Google Groups
linux-sunxi group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] [PATCH 0/2] ARM: dts: sunxi: Fix cpufreq instabilities
Hi Maxime, Here are 2 dts fixes for sunxi cpufreq support, aimed at 4.0. The first patch limits the Olimex A10-Lime to 960MHz, as a few people reported on IRC that it was unstable at 1008MHz. The second patch removes the overclocking settings from sun5i/sun7i dts, so all the boards will be stable, regardless of whether regulators were added or not. I would like to revisit this after the new OPP bindings are merged and support added to cpufreq-dt. Regards ChenYu Chen-Yu Tsai (2): ARM: dts: sun4i: a10-lime: Override and remove 1008MHz OPP setting ARM: dts: sunxi: Remove overclocked/overvoltaged OPP arch/arm/boot/dts/sun4i-a10-olinuxino-lime.dts | 14 ++ arch/arm/boot/dts/sun5i-a13.dtsi | 3 +-- arch/arm/boot/dts/sun7i-a20.dtsi | 3 +-- 3 files changed, 16 insertions(+), 4 deletions(-) -- 2.1.4 -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH 2/3] ARM: sun8i: Add SMP support for the Allwinner A23
On Wed, Mar 18, 2015 at 6:29 PM, Maxime Ripard
maxime.rip...@free-electrons.com wrote:
On Wed, Mar 18, 2015 at 11:24:01AM +0800, Chen-Yu Tsai wrote:
The A23 is a dual Cortex-A7. Add the logic to use the IPs used to
control the CPU configuration and the CPU power so that we can
bring up secondary CPUs at boot.
Signed-off-by: Chen-Yu Tsai w...@csie.org
---
We can't use of_io_request_and_map() here, as it will conflict
with PRCM, and leave us without a serial console.
I think a proper way to solve this would be a syscon device or
something like the mfd-simple device posted by Arnd.
---
Documentation/devicetree/bindings/arm/cpus.txt | 1 +
arch/arm/mach-sunxi/platsmp.c | 69
++
2 files changed, 70 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/cpus.txt
b/Documentation/devicetree/bindings/arm/cpus.txt
index 8b9e0a95de31..40202d85b132 100644
--- a/Documentation/devicetree/bindings/arm/cpus.txt
+++ b/Documentation/devicetree/bindings/arm/cpus.txt
@@ -188,6 +188,7 @@ nodes to be present and contain the properties described
below.
# On ARM 32-bit systems this property is optional and
can be one of:
allwinner,sun6i-a31
+ allwinner,sun8i-a23
arm,psci
brcm,brahma-b15
marvell,armada-375-smp
diff --git a/arch/arm/mach-sunxi/platsmp.c b/arch/arm/mach-sunxi/platsmp.c
index 587b0468efcc..e8483ec79d67 100644
--- a/arch/arm/mach-sunxi/platsmp.c
+++ b/arch/arm/mach-sunxi/platsmp.c
@@ -121,3 +121,72 @@ static struct smp_operations sun6i_smp_ops __initdata =
{
.smp_boot_secondary = sun6i_smp_boot_secondary,
};
CPU_METHOD_OF_DECLARE(sun6i_a31_smp, allwinner,sun6i-a31, sun6i_smp_ops);
+
+static void __init sun8i_smp_prepare_cpus(unsigned int max_cpus)
+{
+ struct device_node *node;
+
+ node = of_find_compatible_node(NULL, NULL, allwinner,sun8i-a23-prcm);
+ if (!node) {
+ pr_err(Missing A23 PRCM node in the device tree\n);
+ return;
+ }
+
+ prcm_membase = of_iomap(node, 0);
+ if (!prcm_membase) {
+ pr_err(Couldn't map A23 PRCM registers\n);
+ return;
+ }
+
+ node = of_find_compatible_node(NULL, NULL,
+allwinner,sun8i-a23-cpuconfig);
+ if (!node) {
+ pr_err(Missing A23 CPU config node in the device tree\n);
+ return;
+ }
+
+ cpucfg_membase = of_iomap(node, 0);
+ if (!cpucfg_membase)
+ pr_err(Couldn't map A23 CPU config registers\n);
+
+}
+
+static int sun8i_smp_boot_secondary(unsigned int cpu,
+ struct task_struct *idle)
+{
+ u32 reg;
+
+ if (!(prcm_membase cpucfg_membase))
+ return -EFAULT;
+
+ spin_lock(cpu_lock);
+
+ /* Set CPU boot address */
+ writel(virt_to_phys(secondary_startup),
+cpucfg_membase + CPUCFG_PRIVATE0_REG);
One question I couldn't find any answer to is that does the SMP bit is
set in secondary_startup?
I couldn't find where it was set, but it still looks like the right
thing to do, so I would expect the code to do that.
I don't see it either. The sun8i code is just the sun6i code with the
power clamps removed. And sun6i secondary_startup was removed some time
ago in commit 1146b600044d (ARM: sunxi: fix build for THUMB2_KERNEL).
ChenYu
--
You received this message because you are subscribed to the Google Groups
linux-sunxi group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: [RFC] Serial number on sunxi devices
Le mardi 17 mars 2015 à 23:58 +0100, Paul Kocialkowski a écrit : Le mardi 17 mars 2015 à 09:36 +0100, Hans de Goede a écrit : Hi, On 16-03-15 23:02, Paul Kocialkowski wrote: Le lundi 16 mars 2015 à 14:45 +0100, Hans de Goede a écrit : Hi, On 16-03-15 13:31, Olliver Schinagl wrote: Hey, On 16-03-15 10:52, Hans de Goede wrote: Hi, Oops, missed a bit to reply to, see below: On 16-03-15 10:04, Olliver Schinagl wrote: Also, which part of the SID do we want in /proc/cpuinfo? The one is bigger then the other, though looking at http://linux-sunxi.org/SID_Register_Guide there's a lot of non-uniqueness that can be ignored (chip ID (1623 for example). I would say all of it, serial numbers often also contain a fixed bit with model info, for /proc/cpuinfo that is fine. but isn't the serial in /proc/cpuinfo limited to a certain number of bits? Could be, whomever writes patches for this needs to look into that, and if necessary truncate the SID somehow. As far as I can see, the SID has (at least) 4 32bit words. It seems that there is more on e.g. A20 but those are not always populated, so I think it's safer to go with those 4 words and somewhat use them to come up with a serial. The Linux kernel serial ATAG (shown in cpuinfo) is only 2 32bit words, so we will have to get rid of half of the (usable) SID. AFAIK ATAG-s are pretty much dead when using a devicetree enabled platform, how does this work in the devicetree world ? You're right, ATAGs are not used anymore when devicetree is there. As far as I could see, the kernel command line is provided through the chosen dt node, but the serial number, as well as revision, are not passed to the kernel at all this way, so they always remain blank. I think it would be worth providing the serial and revision back through the dt logic, so I'll perhaps try to come up with something for both U-Boot and Linux. However, serial and revision are specific to ARM and the dt logic in the kernel is common (at least the part that handles cmdline), so I have yet to figure out how to get it right. In the meantime, it still makes sense to provide it through ATAGs for the 3.4 kernel and to have it for internal use in U-Boot (e.g. for USB Download gadgets such as fastboot). The first half seems prefixed depending on the SoC platform, which reduces the possible number of different combinations (but that's probably not really a problem) and as Hans mentioned, it isn't unusual to have a common part depending on the model. I suggest going with it. Actually if we need to truncate I think it would be good to have as much random bits in there as possible, we've a collection of SID-s here: http://linux-sunxi.org/SID_Register_Guide As you can see the last 32bit word is the most random one, for MAC addresses we use the least significant byte of the first 32bit word (which seems to be random in that table, but seems to be a fixed value on later Axx SOCs) combined with the entire last 32 bit word. So for the serial we could use the first and last 32 bit words, this will give us the model prefix, instantly showing the soc model in the serial + 32 unique bits per board. That looks like a fair bargain to me. I was starting to worry that some of the first 64 bit words from the SID look too much alike on some devices such as the Cubietruck. I'll try to come up with a patch for this soon (tomorrow if possible). Just sent a patch to the u-boot list and tested on the devices I had at disposal (A13 and A20). I would appreciate it if someone could test on devices that have the SID registers on the AXP. In U-Boot, printenv shows: serial#=1625428e04815f6a When using U-Boot with USB in gadget mode and fastboot, I get (on the host): # fastboot devices 1625428e04815f6a fastboot I only booted the sunxi-3.4 kernel on sun5i/A13 to test that the ATAG went through, resulting in: root@localhost:~# cat /proc/cpuinfo Processor : ARMv7 Processor rev 2 (v7l) BogoMIPS: 1001.88 Features: swp half thumb fastmult vfp edsp neon vfpv3 tls CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x3 CPU part: 0xc08 CPU revision: 2 Hardware: sun5i Revision: Serial : 1625428e04815f6a So everything looks good. The patch goes on top of the patches I submitted a few days ago. Thanks for your input! -- Paul Kocialkowski, Replicant developer Replicant is a fully free Android distribution running on several devices, a free software mobile operating system putting the emphasis on freedom and privacy/security. Website: http://www.replicant.us/ Blog: http://blog.replicant.us/ Wiki/tracker/forums: http://redmine.replicant.us/ -- 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,
