[linux-sunxi] Re: [PATCH 6/9] ARM: dts: sun7i: Add board support for LinkSprite pcDuino V3
On Tue, Jul 1, 2014 at 3:12 PM, Hans de Goede hdego...@redhat.com wrote: Hi, On 07/01/2014 04:22 AM, Chen-Yu Tsai wrote: On Tue, Jul 1, 2014 at 5:57 AM, Hans de Goede hdego...@redhat.com wrote: From: Zoltan HERPAI wigy...@uid0.hu The LinkSprite pcDuino V3 is an A20 based development board featuring arduino compatible io headers, 1G RAM, 4G nand, sata, rtl8188cus usb wifi and 100 Mbit ethernet using an ip101a phy: http://www.pcduino.com/pcduino-v3/ Signed-off-by: Zoltan HERPAI wigy...@uid0.hu [hdego...@redhat.com: Various cleanups, correct led pins] [hdego...@redhat.com: Add axp209, ir and gpio-keys nodes] Signed-off-by: Hans de Goede hdego...@redhat.com -- Changes since v2: - update MMC entry to comply with upstream - unify the 4 patches into one Changes since v1: - fix cosmetic issues - fix i2c entry - remove unnecessary input bindings include - add MMC support --- arch/arm/boot/dts/Makefile | 3 +- arch/arm/boot/dts/sun7i-a20-pcduino3.dts | 173 +++ 2 files changed, 175 insertions(+), 1 deletion(-) create mode 100644 arch/arm/boot/dts/sun7i-a20-pcduino3.dts diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile index ed0de8b..fdc590e 100644 --- a/arch/arm/boot/dts/Makefile +++ b/arch/arm/boot/dts/Makefile @@ -380,7 +380,8 @@ dtb-$(CONFIG_MACH_SUN7I) += \ sun7i-a20-cubieboard2.dtb \ sun7i-a20-cubietruck.dtb \ sun7i-a20-i12-tvbox.dtb \ - sun7i-a20-olinuxino-micro.dtb + sun7i-a20-olinuxino-micro.dtb \ + sun7i-a20-pcduino3.dtb You may need to rebase onto my sun8i ippo-q8h dts patch. https://patchwork.kernel.org/patch/4389951/ There's a likely conflict in the Makefile here. Has that one already been accepted by Maxime ? I'm fine rebasing patches on top of accepted stuff, but rebasing on pending stuff is not really useful IMHO. Maxime replied stating he applied it. See the lower part of the patchwork page. AFAIK he's accepted my initial sun8i patches and CIR DT patches this cycle. 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 v10 2/2] dmaengine: sun6i: Add driver for the Allwinner A31 DMA controller
On Mon, Jun 30, 2014 at 04:33:05PM +0100, Mark Rutland wrote:
On Mon, Jun 30, 2014 at 04:19:06PM +0100, Maxime Ripard wrote:
On Mon, Jun 30, 2014 at 03:20:54PM +0100, Mark Rutland wrote:
Hi Maxime,
On Mon, Jun 30, 2014 at 02:20:54PM +0100, Maxime Ripard wrote:
The Allwinner A31 has a 16 channels DMA controller that it shares with
the
newer A23. Although sharing some similarities with the DMA controller
of the
older Allwinner SoCs, it's significantly different, I don't expect it
to be
possible to share the driver for these two.
The A31 Controller is able to memory-to-memory or memory-to-device
transfers on
the 16 channels in parallel.
Signed-off-by: Maxime Ripard maxime.rip...@free-electrons.com
Acked-by: Arnd Bergmann a...@arndb.de
---
drivers/dma/Kconfig |8 +
drivers/dma/Makefile|1 +
drivers/dma/sun6i-dma.c | 1058
+++
3 files changed, 1067 insertions(+)
create mode 100644 drivers/dma/sun6i-dma.c
[...]
+ sdc-clk = devm_clk_get(pdev-dev, NULL);
+ if (IS_ERR(sdc-clk)) {
+ dev_err(pdev-dev, No clock specified\n);
+ return PTR_ERR(sdc-clk);
+ }
+
+ mux = clk_get(NULL, ahb1_mux);
+ if (IS_ERR(mux)) {
+ dev_err(pdev-dev, Couldn't get AHB1 Mux\n);
+ return PTR_ERR(mux);
+ }
+
+ pll6 = clk_get(NULL, pll6);
+ if (IS_ERR(pll6)) {
+ dev_err(pdev-dev, Couldn't get PLL6\n);
+ clk_put(mux);
+ return PTR_ERR(pll6);
+ }
I'm slightly confused. The binding listed a single unnamed clock (the
AHB clock). What is going on here?
The device itself needs only a single clock to work...
+ ret = clk_set_parent(mux, pll6);
+ clk_put(pll6);
+ clk_put(mux);
+
+ if (ret) {
+ dev_err(pdev-dev, Couldn't reparent AHB1 on PLL6\n);
+ return ret;
+ }
Why do we need to reparent the mux?
... but will function only if this clock is derived from PLL6.
Ok, but _why_ is that the case? Could we at least have a comment for
that?
I have no idea, sorry.
Where does the driver get the named clocks from if they aren't provided
on the device node? Is there a clock-ranges somewhere?
No, it just looks up the global clock name.
It feels a little fragile to rely on the organisation of the clock tree
and the naming thereof. If the IP block is ever reused on an SoC with a
different clock tree layout then we have to handle things differently.
What do you suggest then?
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/9] ARM: dts: sun7i: Add board support for LinkSprite pcDuino V3
Hi, On 07/01/2014 09:21 AM, Chen-Yu Tsai wrote: On Tue, Jul 1, 2014 at 3:12 PM, Hans de Goede hdego...@redhat.com wrote: Hi, On 07/01/2014 04:22 AM, Chen-Yu Tsai wrote: On Tue, Jul 1, 2014 at 5:57 AM, Hans de Goede hdego...@redhat.com wrote: From: Zoltan HERPAI wigy...@uid0.hu The LinkSprite pcDuino V3 is an A20 based development board featuring arduino compatible io headers, 1G RAM, 4G nand, sata, rtl8188cus usb wifi and 100 Mbit ethernet using an ip101a phy: http://www.pcduino.com/pcduino-v3/ Signed-off-by: Zoltan HERPAI wigy...@uid0.hu [hdego...@redhat.com: Various cleanups, correct led pins] [hdego...@redhat.com: Add axp209, ir and gpio-keys nodes] Signed-off-by: Hans de Goede hdego...@redhat.com -- Changes since v2: - update MMC entry to comply with upstream - unify the 4 patches into one Changes since v1: - fix cosmetic issues - fix i2c entry - remove unnecessary input bindings include - add MMC support --- arch/arm/boot/dts/Makefile | 3 +- arch/arm/boot/dts/sun7i-a20-pcduino3.dts | 173 +++ 2 files changed, 175 insertions(+), 1 deletion(-) create mode 100644 arch/arm/boot/dts/sun7i-a20-pcduino3.dts diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile index ed0de8b..fdc590e 100644 --- a/arch/arm/boot/dts/Makefile +++ b/arch/arm/boot/dts/Makefile @@ -380,7 +380,8 @@ dtb-$(CONFIG_MACH_SUN7I) += \ sun7i-a20-cubieboard2.dtb \ sun7i-a20-cubietruck.dtb \ sun7i-a20-i12-tvbox.dtb \ - sun7i-a20-olinuxino-micro.dtb + sun7i-a20-olinuxino-micro.dtb \ + sun7i-a20-pcduino3.dtb You may need to rebase onto my sun8i ippo-q8h dts patch. https://patchwork.kernel.org/patch/4389951/ There's a likely conflict in the Makefile here. Has that one already been accepted by Maxime ? I'm fine rebasing patches on top of accepted stuff, but rebasing on pending stuff is not really useful IMHO. Maxime replied stating he applied it. See the lower part of the patchwork page. AFAIK he's accepted my initial sun8i patches and CIR DT patches this cycle. Ok, I'm not seeing anything for 3.17 here though: https://github.com/mripard/linux/ Maxime, can you push a sunxi/dt-for-3.17 with what you currently have there? Then I'll rebase this series on top, fix the commit msg thingie Chen pointed out and send a v2. 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: [PATCH 6/9] ARM: dts: sun7i: Add board support for LinkSprite pcDuino V3
On Tue, Jul 01, 2014 at 09:30:18AM +0200, Hans de Goede wrote: Ok, I'm not seeing anything for 3.17 here though: https://github.com/mripard/linux/ Maxime, can you push a sunxi/dt-for-3.17 with what you currently have there? Ah, sorry, my bad. From 3.17, I started to use a kernel.org git tree there: git://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux.git And forgot to notify you. There will also be linux-next coverage for the patches I gather. Then I'll rebase this series on top, fix the commit msg thingie Chen pointed out and send a v2. Fixed the whitespace error, the conflict, and the commit message, and applied. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
[linux-sunxi] Re: [PATCH 0/9] ARM: dts: sunxi: Various sunxi dts patches
On Mon, Jun 30, 2014 at 11:57:50PM +0200, Hans de Goede wrote: Hi Maxime, Here is a set of sunxi dts patches for your dt tree. It is a mixed collection: -Some patches submitted earlier by others which I've picked up from the list and brushed up a bit were necessary. -2 new boards -sun4i ir support (and renaming of the compatible from sun7i-a20-ir to sun4i-a10-ir as they have the same ip block for this) Applied, thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
[linux-sunxi] Re: [PATCH 0/9] ARM: dts: sunxi: Various sunxi dts patches
Hi, On 07/01/2014 10:06 AM, Maxime Ripard wrote: On Mon, Jun 30, 2014 at 11:57:50PM +0200, Hans de Goede wrote: Hi Maxime, Here is a set of sunxi dts patches for your dt tree. It is a mixed collection: -Some patches submitted earlier by others which I've picked up from the list and brushed up a bit were necessary. -2 new boards -sun4i ir support (and renaming of the compatible from sun7i-a20-ir to sun4i-a10-ir as they have the same ip block for this) Applied, thanks! Thanks, and good to know about your new tree on kernel.org. I'll use that to base dts patches on from now on. 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: [PATCH resend v2 0/3] mfd-core: Don't register supplies from add_device, add register_supply_aliases()
Hi, On 07/01/2014 11:05 AM, Lee Jones wrote: I already send this series before (in time for 3.16) and AFAIK we agreed on going with this series instead of the incomplete fix for the related oops which now has been merged as commit d137be00ee017bc40e6027cb66d667a2e0b450fd I still believe that this series is the more correct fix, as platform devices must simply not be used at all before they have been added. We were waiting for Mark's comments. Which we still have to do. As they never appeared the temporary fix went in instead. Moving forward, should that fix be reverted, or it is okay just to apply this set on top? The resend has been rebased on top of the fix, so it should be applied on top. 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: [PATCH resend v2 1/3] mfd-core: Don't register supplies from add_device, add register_supply_aliases()
On Mon, 30 Jun 2014, Hans de Goede wrote:
We cannot register supply alias in mfd_add_device before calling
platform_add_device because platform-dev's name must be set before registering
the aliases which happens from platform_add_device.
So stop registering supply aliases from mfd_add_device, and add a
mfd_register_supply_aliases helper functions for the cell's plaform driver
probe method to use.
Signed-off-by: Hans de Goede hdego...@redhat.com
Didn't I already Ack this?
---
drivers/mfd/mfd-core.c | 37 +
include/linux/mfd/core.h | 6 +-
2 files changed, 26 insertions(+), 17 deletions(-)
diff --git a/drivers/mfd/mfd-core.c b/drivers/mfd/mfd-core.c
index 892d343..03f6fee 100644
--- a/drivers/mfd/mfd-core.c
+++ b/drivers/mfd/mfd-core.c
@@ -102,13 +102,6 @@ static int mfd_add_device(struct device *parent, int id,
pdev-dev.dma_mask = parent-dma_mask;
pdev-dev.dma_parms = parent-dma_parms;
- ret = regulator_bulk_register_supply_alias(
- pdev-dev, cell-parent_supplies,
- parent, cell-parent_supplies,
- cell-num_parent_supplies);
- if (ret 0)
- goto fail_res;
-
if (parent-of_node cell-of_compatible) {
for_each_child_of_node(parent-of_node, np) {
if (of_device_is_compatible(np, cell-of_compatible)) {
@@ -122,12 +115,12 @@ static int mfd_add_device(struct device *parent, int id,
ret = platform_device_add_data(pdev,
cell-platform_data, cell-pdata_size);
if (ret)
- goto fail_alias;
+ goto fail_res;
}
ret = mfd_platform_add_cell(pdev, cell, usage_count);
if (ret)
- goto fail_alias;
+ goto fail_res;
for (r = 0; r cell-num_resources; r++) {
res[r].name = cell-resources[r].name;
@@ -162,17 +155,17 @@ static int mfd_add_device(struct device *parent, int id,
if (!cell-ignore_resource_conflicts) {
ret = acpi_check_resource_conflict(res[r]);
if (ret)
- goto fail_alias;
+ goto fail_res;
}
}
ret = platform_device_add_resources(pdev, res, cell-num_resources);
if (ret)
- goto fail_alias;
+ goto fail_res;
ret = platform_device_add(pdev);
if (ret)
- goto fail_alias;
+ goto fail_res;
if (cell-pm_runtime_no_callbacks)
pm_runtime_no_callbacks(pdev-dev);
@@ -181,10 +174,6 @@ static int mfd_add_device(struct device *parent, int id,
return 0;
-fail_alias:
- regulator_bulk_unregister_supply_alias(pdev-dev,
-cell-parent_supplies,
-cell-num_parent_supplies);
fail_res:
kfree(res);
fail_device:
@@ -289,5 +278,21 @@ int mfd_clone_cell(const char *cell, const char
**clones, size_t n_clones)
}
EXPORT_SYMBOL(mfd_clone_cell);
+int mfd_register_supply_aliases(struct platform_device *pdev)
+{
+ const struct mfd_cell *cell;
+
+ if (pdev-dev.type != mfd_dev_type)
+ return -EINVAL;
+
+ cell = mfd_get_cell(pdev);
+
+ return devm_regulator_bulk_register_supply_alias(
+ pdev-dev, cell-parent_supplies,
+ pdev-dev.parent, cell-parent_supplies,
+ cell-num_parent_supplies);
+}
+EXPORT_SYMBOL(mfd_register_supply_aliases);
+
MODULE_LICENSE(GPL);
MODULE_AUTHOR(Ian Molton, Dmitry Baryshkov);
diff --git a/include/linux/mfd/core.h b/include/linux/mfd/core.h
index f543de9..f05488e 100644
--- a/include/linux/mfd/core.h
+++ b/include/linux/mfd/core.h
@@ -61,7 +61,9 @@ struct mfd_cell {
boolpm_runtime_no_callbacks;
/* A list of regulator supplies that should be mapped to the MFD
- * device rather than the child device when requested
+ * device rather than the child device when requested.
+ * Drivers using this must call mfd_register_supply_aliases()
+ * from their probe method.
*/
const char * const *parent_supplies;
int num_parent_supplies;
@@ -110,4 +112,6 @@ extern int mfd_add_devices(struct device *parent, int id,
extern void mfd_remove_devices(struct device *parent);
+extern int mfd_register_supply_aliases(struct platform_device *pdev);
+
#endif
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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
[linux-sunxi] Re: [PATCH resend v2 1/3] mfd-core: Don't register supplies from add_device, add register_supply_aliases()
Hi, On 07/01/2014 11:22 AM, Lee Jones wrote: On Mon, 30 Jun 2014, Hans de Goede wrote: We cannot register supply alias in mfd_add_device before calling platform_add_device because platform-dev's name must be set before registering the aliases which happens from platform_add_device. So stop registering supply aliases from mfd_add_device, and add a mfd_register_supply_aliases helper functions for the cell's plaform driver probe method to use. Signed-off-by: Hans de Goede hdego...@redhat.com Didn't I already Ack this? Ah yes you did, but back then I expected the series to get picked up immediately, so I did not add the ack to my local copy of it. 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: A20 + OV5640 (parallel) issues
On Thursday, June 26, 2014 10:48:35 AM UTC+4:30, alex simohin wrote: Hello everyone! I want to run on the OV5642 sensor cubieboard2 (A20). First tried to run OV7670. Works well. Ov5642 sensor used in another project, so the working registers I have. Tried to use them in the driver ov5640 and get a green screen with lower stripes, and in the background, the image movement visible. I do not know what the problem is. Maybe the wrong color conversion? Tested through gstreamer rtp on hardware encoder cedar264. Tried to jpeg-encode the same picture. hi alex how did you run ov7670 on A20 could you please share your fex and any other important settings? thanks, -- 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] A23 schematic
Has A23 schematic been released ? Is anyone designing a board with it ? I understand that A20 schematic was released sometime ago by Olimex and that Olimex and Cubieboard designs are available as open source for A20. Sorry if the posting is duplicate but I did not see the original post. -- 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] A23 schematic
Hi All, Has all winner released the schematic/library file for the A23 processor ? I understand there was .DSN file available for A20 a while ago but A23 has been released for a while including data sheet and spec, but there is no mention of .DSN file. Are people/companies already designing boards with it and/or are present in this forum. -- 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] A20/A23 hardware design guidelines/application notes
Are there application notes available by Allwinner for PCB design using A20/A23 processors. I understand that Cubie board and Olimex has designs which are open source hardware and can be used by others but what if someone needs to make some modifications and add/remove components. -- 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 v10 2/2] dmaengine: sun6i: Add driver for the Allwinner A31 DMA controller
On Tue, Jul 01, 2014 at 08:21:19AM +0100, Maxime Ripard wrote:
On Mon, Jun 30, 2014 at 04:33:05PM +0100, Mark Rutland wrote:
On Mon, Jun 30, 2014 at 04:19:06PM +0100, Maxime Ripard wrote:
On Mon, Jun 30, 2014 at 03:20:54PM +0100, Mark Rutland wrote:
Hi Maxime,
On Mon, Jun 30, 2014 at 02:20:54PM +0100, Maxime Ripard wrote:
The Allwinner A31 has a 16 channels DMA controller that it shares
with the
newer A23. Although sharing some similarities with the DMA controller
of the
older Allwinner SoCs, it's significantly different, I don't expect it
to be
possible to share the driver for these two.
The A31 Controller is able to memory-to-memory or memory-to-device
transfers on
the 16 channels in parallel.
Signed-off-by: Maxime Ripard maxime.rip...@free-electrons.com
Acked-by: Arnd Bergmann a...@arndb.de
---
drivers/dma/Kconfig |8 +
drivers/dma/Makefile|1 +
drivers/dma/sun6i-dma.c | 1058
+++
3 files changed, 1067 insertions(+)
create mode 100644 drivers/dma/sun6i-dma.c
[...]
+ sdc-clk = devm_clk_get(pdev-dev, NULL);
+ if (IS_ERR(sdc-clk)) {
+ dev_err(pdev-dev, No clock specified\n);
+ return PTR_ERR(sdc-clk);
+ }
+
+ mux = clk_get(NULL, ahb1_mux);
+ if (IS_ERR(mux)) {
+ dev_err(pdev-dev, Couldn't get AHB1 Mux\n);
+ return PTR_ERR(mux);
+ }
+
+ pll6 = clk_get(NULL, pll6);
+ if (IS_ERR(pll6)) {
+ dev_err(pdev-dev, Couldn't get PLL6\n);
+ clk_put(mux);
+ return PTR_ERR(pll6);
+ }
I'm slightly confused. The binding listed a single unnamed clock (the
AHB clock). What is going on here?
The device itself needs only a single clock to work...
+ ret = clk_set_parent(mux, pll6);
+ clk_put(pll6);
+ clk_put(mux);
+
+ if (ret) {
+ dev_err(pdev-dev, Couldn't reparent AHB1 on
PLL6\n);
+ return ret;
+ }
Why do we need to reparent the mux?
... but will function only if this clock is derived from PLL6.
Ok, but _why_ is that the case? Could we at least have a comment for
that?
I have no idea, sorry.
Oh no :(
Where did this requirement turn up? Did an issue crop up in testing and
using PLL6 just happened to work, or does some manual somewhere say that
the device must have its clock derived from PLL6 without further
explanation?
Does PLL6 drive some other clock that the DMA clock needs to stay in
sync with, possibly?
Where does the driver get the named clocks from if they aren't provided
on the device node? Is there a clock-ranges somewhere?
No, it just looks up the global clock name.
Ok.
It feels a little fragile to rely on the organisation of the clock tree
and the naming thereof. If the IP block is ever reused on an SoC with a
different clock tree layout then we have to handle things differently.
What do you suggest then?
I will admit that I don't have a better suggestion.
Without knowing which particular constraint on the mux parent clock we
care about it's difficult to suggest anything useful.
Mark.
--
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 resend v2 1/3] mfd-core: Don't register supplies from add_device, add register_supply_aliases()
On Tue, 01 Jul 2014, Hans de Goede wrote: On 07/01/2014 11:22 AM, Lee Jones wrote: On Mon, 30 Jun 2014, Hans de Goede wrote: We cannot register supply alias in mfd_add_device before calling platform_add_device because platform-dev's name must be set before registering the aliases which happens from platform_add_device. So stop registering supply aliases from mfd_add_device, and add a mfd_register_supply_aliases helper functions for the cell's plaform driver probe method to use. Signed-off-by: Hans de Goede hdego...@redhat.com Didn't I already Ack this? Ah yes you did, but back then I expected the series to get picked up immediately, so I did not add the ack to my local copy of it. When resubmitting, it's always a good idea to look at previous review in order to search for review comments to fix, or Acks to apply. Unfortunately the set couldn't go in without Mark's review - which is still the case. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- 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] pinctrl: sunxi: Remove gpio_out function from sun5i-a13 PG0/1/2 pins
The A13 user manual states pins PG0/1/2 only have GPIO input and
interrupt functions. Remove the gpio_out functions for these pins.
Signed-off-by: Chen-Yu Tsai w...@csie.org
---
Hi,
The A13 manual [1] and reference design [2] explicitly warn that pins
PG0/1/2 can not be used as gpio outputs. This patch removes the output
functions from the pin definitions.
ChenYu
[1]
http://dl.linux-sunxi.org/A13/A13%20User%20Manual%20-%20v1.2%20%282013-01-08%29.pdf
Page 384.
[2] https://github.com/OLIMEX/OLINUXINO/raw/master/HARDWARE/A13-PDFs/a13-sch.pdf
Page 1, reminder in the red box (in Chinese)
---
drivers/pinctrl/sunxi/pinctrl-sun5i-a13.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/pinctrl/sunxi/pinctrl-sun5i-a13.c
b/drivers/pinctrl/sunxi/pinctrl-sun5i-a13.c
index 29c734a..e47c33d 100644
--- a/drivers/pinctrl/sunxi/pinctrl-sun5i-a13.c
+++ b/drivers/pinctrl/sunxi/pinctrl-sun5i-a13.c
@@ -330,15 +330,12 @@ static const struct sunxi_desc_pin sun5i_a13_pins[] = {
/* Hole */
SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 0),
SUNXI_FUNCTION(0x0, gpio_in),
- SUNXI_FUNCTION(0x1, gpio_out),
SUNXI_FUNCTION_IRQ(0x6, 0)), /* EINT0 */
SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 1),
SUNXI_FUNCTION(0x0, gpio_in),
- SUNXI_FUNCTION(0x1, gpio_out),
SUNXI_FUNCTION_IRQ(0x6, 1)), /* EINT1 */
SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 2),
SUNXI_FUNCTION(0x0, gpio_in),
- SUNXI_FUNCTION(0x1, gpio_out),
SUNXI_FUNCTION_IRQ(0x6, 2)), /* EINT2 */
SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 3),
SUNXI_FUNCTION(0x0, gpio_in),
--
2.0.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] A20 Scaler/DEFE/DEBE register update
Hi all, Does anyone know when are the register settings applied to DEBE/DEFE? To be honest I did go through the code many times, but it's a bit abstract and I don't know if I'm mistaken somewhere. Somehow I concluded that it is done on a frame boundary, since most of the settings seem to be applied through Hal_Set_Frame (defined in disp_video.c). This function is called in Video_Operation_In_Vblanking (defined also in disp_video.c, called in disp_event.c during VBI, so it's during vertical blanking). Although some scaler functions (like DE_SCAL_Config_Src) I tracked to be called from disp_layer.c (BSP_disp_layer_set_framebuffer), which seems async to the frame boundary - I'm not sure of this... If anyone knows it would be very helpful! Thanks in advance! -- 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] A20: SPI Drivers
Hi I wanted to ask if anybody has tried to build spi-sun7.c for mainline kernels? I followed this excellent guide: http://will-tm.com/spi-on-the-cubieboard2/ ...but the compile fails with drivers/spi/spi-sun7i.c:30:22: fatal error: mach/dma.h: No such file or directory #include mach/dma.h ^ compilation terminated. make[3]: *** [drivers/spi/spi-sun7i.o] Error 1 make[3]: *** Waiting for unfinished jobs I also noticed the Fedora 20 images doesn't support SPI for A20: https://github.com/jwrdegoede/sunxi-fedora-scripts/blob/master/README * SPI (as module, not supported on A20) So now I'm a little worried as my entire project is built around 4 SPI devices on an A20-SOM :) Any secret plans for full DMA + SPI in the works? Bruce -- 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] A20: SPI Drivers
Hi there, El 01/07/14 18:47, bruce bushby escribió: Hi I wanted to ask if anybody has tried to build spi-sun7.c for mainline kernels? I followed this excellent guide: http://will-tm.com/spi-on-the-cubieboard2/ ...but the compile fails with drivers/spi/spi-sun7i.c:30:22: fatal error: mach/dma.h: No such file or directory #include mach/dma.h ^ compilation terminated. make[3]: *** [drivers/spi/spi-sun7i.o] Error 1 make[3]: *** Waiting for unfinished jobs SPI on mainline is already supported on A20 via the SPI_SUN4I kconfig entry. It only supports PIO transfers for the moment. I also noticed the Fedora 20 images doesn't support SPI for A20: https://github.com/jwrdegoede/sunxi-fedora-scripts/blob/master/README * SPI (as module, not supported on A20) This uses the linux-sunxi 3.4 kernel. I believe it has also recently gained SPI support on A20. So now I'm a little worried as my entire project is built around 4 SPI devices on an A20-SOM :) Any secret plans for full DMA + SPI in the works? As part of my work on DMA, I have worked on enabling DMA transfers on SPI, so it should be supported on mainline in the nearby future. I'll be sending a fresh second round of patches you can try really soon, so stay tuned. Cheers, Emilio -- 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: A20: SPI Drivers
I can compile the driver successfully, May be you can cherry-pick this commit https://github.com/mmplayer/linux-sunxi/commit/82f7a2bda8a8adbbdca1850dfaf3df0f43ee2ee1 On Wednesday, July 2, 2014 5:47:39 AM UTC+8, bruce bushby wrote: Hi I wanted to ask if anybody has tried to build spi-sun7.c for mainline kernels? I followed this excellent guide: http://will-tm.com/spi-on-the-cubieboard2/ ...but the compile fails with drivers/spi/spi-sun7i.c:30:22: fatal error: mach/dma.h: No such file or directory #include mach/dma.h ^ compilation terminated. make[3]: *** [drivers/spi/spi-sun7i.o] Error 1 make[3]: *** Waiting for unfinished jobs I also noticed the Fedora 20 images doesn't support SPI for A20: https://github.com/jwrdegoede/sunxi-fedora-scripts/blob/master/README * SPI (as module, not supported on A20) So now I'm a little worried as my entire project is built around 4 SPI devices on an A20-SOM :) Any secret plans for full DMA + SPI in the works? Bruce -- 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.
