Re: [linux-sunxi] Re: Help adding I2C child node
On Wed, Sep 24, 2014 at 04:27:02PM +0100, bruce bushby wrote: Quick update in case it help somebody else. Big thank you to selsinork for some valuable tips and pointers. As it turns out, you don't need a DTS entry to add an I2C child node/device. I removed my DTS child node entries in case they were breaking things, booted the board and then manually added the device and kernel driver. Although my driver still doesn't work, I am able to see the debug messages which is great. Shell session: First I confirm I can see and query the I2C device using i2ctools, then instantiate the device and then load the module...which fails, but at least explains where it's failing. # lsmod Module Size Used byNot tainted # # # # i2cdetect -y 0 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- 34 -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- 69 -- -- -- -- -- -- 70: -- -- -- -- -- -- -- 77 # # # # i2cget -y 0 0x69 0x75 0x71 # # # # echo mpu9250 0x69 /sys/bus/i2c/devices/i2c-0/new_device [ 55.362493] i2c i2c-0: new_device: Instantiated device mpu9250 at 0x69 # # modprobe inv-mpu-iio [ 77.347200] inv-mpu-iio 0-0069: Unable to read axis_map_x [ 77.352699] i2c i2c-0: inv_mpu_probe failed -22 [ 77.357254] inv-mpu-iio: probe of 0-0069 failed with error -5 # Without having the code, it's hard to say, but it definitely looks like you're missing some DT properties (and hence, have to create a node for your device). Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
[linux-sunxi] Re: [PATCH 6/7] ARM: dts: sun6i: Add required ahb1 clock parent and rates for dma controller
On Sun, Sep 21, 2014 at 04:31:06PM +0800, Chen-Yu Tsai wrote: On Sat, Sep 20, 2014 at 5:59 PM, Maxime Ripard maxime.rip...@free-electrons.com wrote: On Wed, Sep 17, 2014 at 12:01:46AM +0800, Chen-Yu Tsai wrote: On Tue, Sep 16, 2014 at 11:48 PM, Maxime Ripard maxime.rip...@free-electrons.com wrote: On Fri, Sep 12, 2014 at 10:10:25AM +0800, Chen-Yu Tsai wrote: On Fri, Sep 12, 2014 at 5:15 AM, Maxime Ripard maxime.rip...@free-electrons.com wrote: On Sat, Sep 06, 2014 at 06:47:27PM +0800, Chen-Yu Tsai wrote: The DMA controller requires AHB1 bus clock to be clocked from PLL6. Signed-off-by: Chen-Yu Tsai w...@csie.org --- arch/arm/boot/dts/sun6i-a31.dtsi | 5 + 1 file changed, 5 insertions(+) diff --git a/arch/arm/boot/dts/sun6i-a31.dtsi b/arch/arm/boot/dts/sun6i-a31.dtsi index 8eb2c6d..1117989 100644 --- a/arch/arm/boot/dts/sun6i-a31.dtsi +++ b/arch/arm/boot/dts/sun6i-a31.dtsi @@ -317,6 +317,11 @@ clocks = ahb1_gates 6; resets = ahb1_rst 6; #dma-cells = 1; + + /* DMA controller requires AHB1 clocked from PLL6 */ + assigned-clocks = ahb1; + assigned-clock-parents = pll6; + assigned-clock-rates = 2; Where did you get that from? The user manual says that it should be clocked at 600MHz, and I'm not sure it should be enforced there either. The bindings mean that ahb1 should be clocked from pll6 and at 200 MHz, not pll6 should be 200 MHz. I assume you were misled by them. Clocking ahb1 from pll6 and at 200 MHz with the /3 pre-divider is the vendor BSP default: On sun6i, the clock init code calls aw_ccu_switch_ahb_2_pll6(), which muxes ahb1 from pll6 with the highest dividers, then sets the rate for ahb1 to pll6, which sets pre-divider to /3 and divider to /1. Hope this clears it up. :) It does, thanks :) But still, I find it the wrong place to enforce such a limit. This should go into the clock driver itself. The DMA controller requires such a parenting, but it doesn't require any specific rate, this is more something of the global system policy. But I am guessing the AHB bus clock cannot be clock at any arbitrary rate. Just muxing without setting a specific clock rate might result in a hang. We could address this with per clock limitations, like the patch you posted earlier. Not sure if there's anything in the kernel like that at the moment, or how the clock framework handles clock rates after re-parenting. There's the Tomeu patch series that allows to set clock rate requirements from the user side, I guess that could be easily extended to integrate some clock side boundaries. That's why I stopped working on the sun5i MMC clock issue until that patch is merged. I could take a look, but AFAIK none of our drivers need to propagate clock rate changes. Don't worry about this. Or we could just specify in the clock driver, or in the DT via clock supplier defaults, that the AHB bus should be clocked from PLL6 @ 200 MHz. The latter seems easier to do. IIRC, there was some opposition to having the muxing assignment in the clock driver. Also, I tested the DMA controller using dmatest on my A31 Hummingbird without this re-parenting patch. It worked fine. How did your tests fail? It was just timeouting, and actually, it was only working to the SRAM, and not the DRAM. Maybe the bootloader sets up the clock muxing already? I just reran my tests on the A31, and dmatest indeed passes. I'm using your A31 sdcard.img, replaced u-boot with one built from u-boot-sunxi, so it supports DT. I also checked both the clock framework and the raw registers. AHB1 is indeed clocked from AXI on my system. Full log: https://gist.github.com/wens/ae17aed6728b83c0a9c3 If you (or someone else with A31) can verify the results, maybe we can just drop this patch. I'm away from the colombus board this week, but if it works on the hummingbird, we can just move this patch to the colombus DT, and not put it in the DTSI. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
[linux-sunxi] Re: [PATCH v2 01/10] ARM: sunxi: Use macro values for setting UART GPIO pull-ups
On Wed, 2014-09-24 at 16:01 +0800, Chen-Yu Tsai wrote: We have already defined macros for pull-up/down values in the GPIO header. Use them instead of magic numbers when configuring the UART pins. Signed-off-by: Chen-Yu Tsai w...@csie.org Acked-by: Ian Campbell i...@hellion.org.uk -- 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 v2 05/10] ARM: sun6i: Add clock support
On Wed, 2014-09-24 at 16:01 +0800, Chen-Yu Tsai wrote:
This patch adds the basic clocks support for the Allwinner A31 (sun6i)
processor. This code will not been compiled until the build is hooked
up in a later patch. It has been split out to keep the patches manageable.
This includes changes from the following commits from u-boot-sunxi:
a92051b ARM: sunxi: Add sun6i clock controller structure
1f72c6f ARM: sun6i: Setup the UART0 clocks
5f2e712 ARM: sunxi: Enable pll6 by default on all models
2be2f2a ARM: sunxi-mmc: Add mmc support for sun6i / A31
12e1633 ARM: sun6i: Add initial clock setup for SPL
1a9c9c6 ARM: sunxi: Split clock code into common, sun4i and sun6i code
0b194ee ARM: sun6i: Properly setup the PLL LDO in clock_init_safe
b54c626 sunxi: avoid sr32 for APB1 clock setup.
68fe29c sunxi: remove magic numbers from clock_get_pll{5,6}
c89867d sunxi: clocks: clock_get_pll5 prototype and coding style
501ab1e ARM: sunxi: Fix sun6i PLL6 settings
37f669b ARM: sunxi: Fix macro names for mmc and uart reset offsets
61de1e6 ARM: sunxi: Correct comment for MBUS1 register in sun6i clock
definitions
Signed-off-by: Maxime Ripard maxime.rip...@free-electrons.com
Signed-off-by: Ian Campbell i...@hellion.org.uk
Signed-off-by: Hans de Goede hdego...@redhat.com
[w...@csie.org: styling fixes reported by checkpatch.pl]
[w...@csie.org: drop unsupported SPL code block and unused gpio.h header]
Signed-off-by: Chen-Yu Tsai w...@csie.org
Cc: Tom Cubie mr.hip...@gmail.com
Acked-by: Ian Campbell i...@hellion.org.uk
(my contributions to what became this patch were minor enough that I
think this doesn't constitute a double dealing self-ack, if that might
have been a problem)
--
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 v2 06/10] ARM: sunxi-mmc: Add mmc support for sun6i / A31
On Wed, 2014-09-24 at 16:01 +0800, Chen-Yu Tsai wrote:
From: Hans de Goede hdego...@redhat.com
The mmc hardware on sun6i has an extra reset control that needs to
be de-asserted prior to usage. Also the FIFO address is different.
Signed-off-by: Hans de Goede hdego...@redhat.com
[w...@csie.org: use setbits_le32 for reset control, drop obsolete changes,
rewrite different FIFO address handling, add commit message]
Signed-off-by: Chen-Yu Tsai w...@csie.org
Acked-by: Ian Campbell i...@hellion.org.uk
Pantelis, unless you object I'd like to eventually take this into
u-boot-sunxi.git#next and merge for v2015.04.
---
arch/arm/include/asm/arch-sunxi/mmc.h | 5 -
drivers/mmc/sunxi_mmc.c | 11 +++
2 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/arch/arm/include/asm/arch-sunxi/mmc.h
b/arch/arm/include/asm/arch-sunxi/mmc.h
index 53196e3..6a31184 100644
--- a/arch/arm/include/asm/arch-sunxi/mmc.h
+++ b/arch/arm/include/asm/arch-sunxi/mmc.h
@@ -43,7 +43,10 @@ struct sunxi_mmc {
u32 chda; /* 0x90 */
u32 cbda; /* 0x94 */
u32 res1[26];
- u32 fifo; /* 0x100 FIFO access address */
+#if defined(CONFIG_SUN6I)
+ u32 res2[64];
+#endif
+ u32 fifo; /* 0x100 (0x200 on sun6i) FIFO access address */
};
#define SUNXI_MMC_CLK_POWERSAVE (0x1 17)
diff --git a/drivers/mmc/sunxi_mmc.c b/drivers/mmc/sunxi_mmc.c
index d4e574f..1982988 100644
--- a/drivers/mmc/sunxi_mmc.c
+++ b/drivers/mmc/sunxi_mmc.c
@@ -19,7 +19,6 @@
struct sunxi_mmc_host {
unsigned mmc_no;
uint32_t *mclkreg;
- unsigned database;
unsigned fatal_err;
unsigned mod_clk;
struct sunxi_mmc *reg;
@@ -57,7 +56,6 @@ static int mmc_resource_init(int sdc_no)
printf(Wrong mmc number %d\n, sdc_no);
return -1;
}
- mmchost-database = (unsigned int)mmchost-reg + 0x100;
mmchost-mmc_no = sdc_no;
return 0;
@@ -75,6 +73,11 @@ static int mmc_clk_io_on(int sdc_no)
/* config ahb clock */
setbits_le32(ccm-ahb_gate0, 1 AHB_GATE_OFFSET_MMC(sdc_no));
+#if defined(CONFIG_SUN6I)
+ /* unassert reset */
+ setbits_le32(ccm-ahb_reset0_cfg, 1 AHB_RESET_OFFSET_MMC(sdc_no));
+#endif
+
/* config mod clock */
pll_clk = clock_get_pll6();
/* should be close to 100 MHz but no more, so round up */
@@ -194,9 +197,9 @@ static int mmc_trans_data_by_cpu(struct mmc *mmc, struct
mmc_data *data)
}
if (reading)
- buff[i] = readl(mmchost-database);
+ buff[i] = readl(mmchost-reg-fifo);
else
- writel(buff[i], mmchost-database);
+ writel(buff[i], mmchost-reg-fifo);
}
return 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] Re: [PATCH v2 07/10] ARM: sun6i: Define UART0 pins for A31
On Wed, 2014-09-24 at 16:01 +0800, Chen-Yu Tsai wrote: UART0 is the default debug/console UART on the A31. Signed-off-by: Chen-Yu Tsai w...@csie.org Acked-by: Ian Campbell i...@hellion.org.uk -- 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 v2 08/10] ARM: sun6i: Setup the A31 UART0 muxing
On Wed, 2014-09-24 at 16:01 +0800, Chen-Yu Tsai wrote: From: Maxime Ripard maxime.rip...@free-electrons.com Signed-off-by: Maxime Ripard maxime.rip...@free-electrons.com Signed-off-by: Hans de Goede hdego...@redhat.com [w...@csie.org: commit message was ARM: sunxi: Setup the A31 UART0 muxing] [w...@csie.org: reorder #ifs by SUN?I] [w...@csie.org: replace magic numbers with GPIO definitions] Signed-off-by: Chen-Yu Tsai w...@csie.org Acked-by: Ian Campbell i...@hellion.org.uk -- 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 v2 09/10] ARM: sunxi: Add basic A31 support
On Wed, 2014-09-24 at 16:01 +0800, Chen-Yu Tsai wrote: From: Maxime Ripard maxime.rip...@free-electrons.com Add a new sun6i machine that supports UART and MMC. Signed-off-by: Maxime Ripard maxime.rip...@free-electrons.com Signed-off-by: Hans de Goede hdego...@redhat.com [w...@csie.org: use SPDX labels, adapt to Kconfig system, drop ifdef around mmc and smp code, drop MACH_TYPE] Signed-off-by: Chen-Yu Tsai w...@csie.org Acked-by: Ian Campbell i...@hellion.org.uk -- 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 v2 10/10] ARM: sun6i: Add Colombus board defconfig
On Wed, 2014-09-24 at 16:01 +0800, Chen-Yu Tsai wrote: The Colombus board is an A31 evaluation board from WITS Technology. Signed-off-by: Chen-Yu Tsai w...@csie.org --- configs/Colombus_defconfig | 4 1 file changed, 4 insertions(+) create mode 100644 configs/Colombus_defconfig diff --git a/configs/Colombus_defconfig b/configs/Colombus_defconfig new file mode 100644 index 000..16800de --- /dev/null +++ b/configs/Colombus_defconfig @@ -0,0 +1,4 @@ +CONFIG_SYS_EXTRA_OPTIONS=COLOMBUS Does this do anything other than define an unused #define? Ah, I suppose eventually it will cause the inclusion of a suitable dram file. Really ought to start moving things out of SYS_EXTRA though, but I don't think you need to shave that yakk just to get this patch in, so: Acked-by: Ian Campbell i...@hellion.org.uk -- 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: * failed to open vchiq device
Hi, I also have a banana pi and installed precompiled mali gpu packages from here: http://forum.lemaker.org/2872-1-1-precompiled_mali_gpu_drivers_for_debian.html (I use the Lubuntu image). Had to compile my own version of fbturbo though. Just tried the test/test from sunxi-mali and I get to see the colored triangle. One thing was that I had to add -lX11 to the build command for 'test'. -- 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: * failed to open vchiq device
On Thu, Sep 25, 2014 at 12:16:18PM -0700, willemjan.deh...@gmail.com wrote: Hi, I also have a banana pi and installed precompiled mali gpu packages from here: http://forum.lemaker.org/2872-1-1-precompiled_mali_gpu_drivers_for_debian.html (I use the Lubuntu image). Had to compile my own version of fbturbo though. Just tried the test/test from sunxi-mali and I get to see the colored triangle. One thing was that I had to add -lX11 to the build command for 'test'. Oh wow. I just looked at that guys libump... He just cleared out the changelog and removed my name from the debian control file. Unbelievable. Why do i even bother with doing the right thing? 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] * failed to open vchiq device
On Thu, 25 Sep 2014 02:15:02 -0700 (PDT) Simo Xefil xe...@xefil.com wrote: Hello, Following your guide here: *http://linux-sunxi.org/Mali_binary_driver* *http://linux-sunxi.org/Xorg#fbturbo_driver* I'm trying to 'Verifying the EGL/GLES driver stack' but I get: root@lemaker ~/software/sunxi-mali # ./test/test * failed to open vchiq device What could be the issue? My board is a bananapi (www.lemaker.org) and the system a Raspbian. Thanks for the help! Google tells us that the abbreviation vchiq is associated with the Broadcomm VideoCore GPU. What happens is that you are trying to use the Raspberry Pi VideoCore drivers. And they naturally do not work on the Mali 400 GPU, which is a part of the Allwinner A20 SoC used by Banana Pi. The drivers installation is apparently incomplete and probably some steps have been skipped. -- 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 3/7] clk: sunxi: unify sun6i AHB1 clock with proper PLL6 pre-divider
Quoting Maxime Ripard (2014-09-13 03:26:03) On Fri, Sep 12, 2014 at 11:16:26AM +0800, Chen-Yu Tsai wrote: Hi, On Fri, Sep 12, 2014 at 5:02 AM, Maxime Ripard maxime.rip...@free-electrons.com wrote: Hi, On Sat, Sep 06, 2014 at 06:47:24PM +0800, Chen-Yu Tsai wrote: This patch unifies the sun6i AHB1 clock, originally supported with separate mux and divider clks. It also adds support for the pre-divider on the PLL6 input, thus allowing the clock to be muxed to PLL6 with proper clock rate calculation. Signed-off-by: Chen-Yu Tsai w...@csie.org It looks fine, but I'd rather see this in a separate file, especially since we don't seem to have any order dependency. Sorry, just to be clear, separate file under clk/sunxi? Yes This cannot be in a separate file, as it shares a spinlock with apb1 divider. They share the same register. We could move apb1 out though. But i would prefer to do that when we split out all the clocks into individual OF_CLK_DECLAREs. Ah right, my bad :) My plan on the long term is to kill clk-sunxi as a place where all the clocks are defined, and only leave the policy there, for example the clock protection code (even if that should probably be removed too, together with clkdev), the various rates / parenting enforcements, etc. Interesting! Where are you planning to store the clock data? Regards, Mike 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.
[linux-sunxi] Re: [PATCH 0/7] clk: sun6i: Unify AHB1 clock and fix rate calculation
On Fri, Sep 26, 2014 at 8:25 AM, Mike Turquette mturque...@linaro.org wrote: Quoting Maxime Ripard (2014-09-11 13:36:23) Hi Chen-Yu, On Sat, Sep 06, 2014 at 06:47:21PM +0800, Chen-Yu Tsai wrote: Hi everyone, This series unifies the mux and divider parts of the AHB1 clock found on sun6i and sun8i, while also adding support for the pre-divider on the PLL6 input. The rate calculation logic must factor in which parent it is using to calculate the rate, to decide whether to use the pre-divider or not. This is beyond the original factors clk design in sunxi. To avoid feature bloat, this is implemented as a seperate composite clk. The new clock driver is registered with a separate OF_CLK_DECLARE. This is done so that assigned-clocks* properties on the clk provider node can actually work. The clock framework arranges the clock setup order by checking whether all clock parents are available, by checking the node matching OF_CLK_DECLARE. However, the sunxi clk driver is based on the root node compatible, has no defined dependencies (parents), and is setup before the fixed-rate clocks. Thus when the ahb1 clock is added, all parents have rate = 0. There is no way to calculate the required clock factors to set a default clock rate under these circumstances. This happens when we set the defaults in the clock node (provider), rather than a clock consumer. I can think of 2 ways to solve the dependency issue, but neither is pretty. One would be to move the root fixed-rate clocks into the sunxi clk driver. The other would be separating all the clocks into individual OF_CLK_DECLARE statements, which adds a lot of boilerplate code. I don't know what Mike thinks of this, but I'd prefer the second. I do not fully understand the problem. Ideally the clock driver should have some way to fail with EPROBE_DEFER until the fixed-rate clocks are registered. Those fixed-rate parents are enumerated in your dts, right? Why isn't this enough? This is due to the way the sunxi clock driver is setup. The clock driver's OF_CLK_DECLARE matches against the soc node, not the individual clock nodes. When the setup function is called, it just registers all the supported clocks. There are no dependencies listed. Unfortunately, the fixed-factor clock is in the middle of the whole clock tree. The sunxi clock driver provides its parents _and_ its children. Naturally the clock framework then probes the fixed-factor clock after the sunxi ones. Any attempts to change the state of clocks under the unavailable fixed-factor clock, such as done by of_clk_set_defaults(), would get an incomplete clock, likely with no parents and parent_rate = 0. That is until of_clk_init() finishes and all clocks are properly hooked up. Anyway, this problem only occurred when I added clk-assigned-* defaults to the clock provider node, which is not the case anymore. The second method i proposed is to have OF_CLK_DECLAREs for each individual clock. An example can be found here: https://github.com/wens/linux/commit/1276898da02a93da4af163ed5bdc88cdead565dc This does add a lot of boilerplate code. Not really happy about it. But it seems the proper way to split up the driver. Cheers ChenYu -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH v2 0/3] ARM: sun8i: Add DMA controller support
On Thu, Sep 18, 2014 at 11:24 AM, Chen-Yu Tsai w...@csie.org wrote: Hi everyone, This is v2 of my sun8i DMA controller support series. This series adds support for the DMA controller found in the Allwinner A23 SoC. It is the same hardware as found in the A31 (sun6i) SoC. In addition to reduced physical channels and endpoints, the controller in the A23 requires an undocumented register to be toggled. That seems to allow memory bus access. This series is based on my earlier clk: sun6i: Unify AHB1 clock and fix rate calculation series, which removes the clock muxing calls from the sun6i-dma driver. The default PLL6 pre-divider for AHB1 on the A23 results in an exceedingly high clock rate for AHB1, and the system hangs. Also, on the A23, the dma controller happily works even when AHB1 is clocked from AXI. Patch 1 changes the channel count macros into runtime data binded to the DT compatible strings. It also gets rid of some hardcoded values in the interrupt handler. Patch 2 adds the channel number data for the A23 (sun8i), as well as the undocumented register quirk. Hi, Vinod, Any chance we can get patches 1 2 merged? You've already merged the prerequisite patch dmaengine: sun6i: Remove obsolete clk muxing code a few days ago, and patch 3 is already in arm-soc. Thanks! ChenYu Patch 3 adds the dma controller node, and related dma resources, to the DT. Changes since v1: - Added Maxime's Acked-by for patch 1 - Added macros for sun8i specific dma gating registers, and updated comment to reflect its usage. Cheers ChenYu Chen-Yu Tsai (3): dmaengine: sun6i: support parameterized compatible strings dmaengine: sun6i: Add support for Allwinner A23 (sun8i) variant ARM: dts: sun8i: Add DMA controller node .../devicetree/bindings/dma/sun6i-dma.txt | 2 +- arch/arm/boot/dts/sun8i-a23.dtsi | 19 drivers/dma/Kconfig| 4 +- drivers/dma/sun6i-dma.c| 123 +++-- 4 files changed, 110 insertions(+), 38 deletions(-) -- 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.
