[linux-sunxi] Re: [PATCH 1/9] clk: sunxi: Give sunxi_factors_register a registers parameter
Hi Hans,
On Thu, Nov 20, 2014 at 04:55:20PM +0100, Hans de Goede wrote:
Before this commit sunxi_factors_register uses of_iomap(node, 0) to get
the clk registers. The sun6i prcm has factor clocks, for which we want to
use sunxi_factors_register, but of_iomap(node, 0) does not work for the prcm
factor clocks, because the prcm uses the mfd framework, so the registers
are not part of the dt-node, instead they are added to the platform_device,
as platform_device resources.
This commit makes getting the registers the callers duty, so that
sunxi_factors_register can be used with mfd instantiated platform device too.
Signed-off-by: Hans de Goede hdego...@redhat.com
Funny, I was thinking of doing exactly the same thing for MMC clocks :)
---
drivers/clk/sunxi/clk-factors.c| 10 --
drivers/clk/sunxi/clk-factors.h| 7 ---
drivers/clk/sunxi/clk-mod0.c | 6 --
drivers/clk/sunxi/clk-sun8i-mbus.c | 2 +-
drivers/clk/sunxi/clk-sunxi.c | 3 ++-
5 files changed, 15 insertions(+), 13 deletions(-)
diff --git a/drivers/clk/sunxi/clk-factors.c b/drivers/clk/sunxi/clk-factors.c
index f83ba09..fc4f4b5 100644
--- a/drivers/clk/sunxi/clk-factors.c
+++ b/drivers/clk/sunxi/clk-factors.c
@@ -156,9 +156,10 @@ static const struct clk_ops clk_factors_ops = {
.set_rate = clk_factors_set_rate,
};
-struct clk * __init sunxi_factors_register(struct device_node *node,
-const struct factors_data *data,
-spinlock_t *lock)
+struct clk *sunxi_factors_register(struct device_node *node,
+const struct factors_data *data,
+spinlock_t *lock,
+void __iomem *reg)
{
struct clk *clk;
struct clk_factors *factors;
@@ -168,11 +169,8 @@ struct clk * __init sunxi_factors_register(struct
device_node *node,
struct clk_hw *mux_hw = NULL;
const char *clk_name = node-name;
const char *parents[FACTORS_MAX_PARENTS];
- void __iomem *reg;
int i = 0;
- reg = of_iomap(node, 0);
-
/* if we have a mux, we will have 1 parents */
while (i FACTORS_MAX_PARENTS
(parents[i] = of_clk_get_parent_name(node, i)) != NULL)
diff --git a/drivers/clk/sunxi/clk-factors.h b/drivers/clk/sunxi/clk-factors.h
index 9913840..1f5526d 100644
--- a/drivers/clk/sunxi/clk-factors.h
+++ b/drivers/clk/sunxi/clk-factors.h
@@ -37,8 +37,9 @@ struct clk_factors {
spinlock_t *lock;
};
-struct clk * __init sunxi_factors_register(struct device_node *node,
-const struct factors_data *data,
-spinlock_t *lock);
+struct clk *sunxi_factors_register(struct device_node *node,
+const struct factors_data *data,
+spinlock_t *lock,
+void __iomem *reg);
Why are you dropping the __init there?
#endif
diff --git a/drivers/clk/sunxi/clk-mod0.c b/drivers/clk/sunxi/clk-mod0.c
index 4a56385..9530833 100644
--- a/drivers/clk/sunxi/clk-mod0.c
+++ b/drivers/clk/sunxi/clk-mod0.c
@@ -78,7 +78,8 @@ static DEFINE_SPINLOCK(sun4i_a10_mod0_lock);
static void __init sun4i_a10_mod0_setup(struct device_node *node)
{
- sunxi_factors_register(node, sun4i_a10_mod0_data,
sun4i_a10_mod0_lock);
+ sunxi_factors_register(node, sun4i_a10_mod0_data,
+sun4i_a10_mod0_lock, of_iomap(node, 0));
As of_iomap can fail, I'd rather check the returned value before
calling sunxi_factors_register.
I know it wasn't done before, but it's the right thing to do, as it
would lead to an instant crash if that fails.
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: [PATCH 5/9] rc: sunxi-cir: Add support for the larger fifo found on sun5i and sun6i
Hi, On 11/21/2014 09:26 AM, Maxime Ripard wrote: Hi Mauro, On Thu, Nov 20, 2014 at 02:28:56PM -0200, Mauro Carvalho Chehab wrote: Em Thu, 20 Nov 2014 16:55:24 +0100 Hans de Goede hdego...@redhat.com escreveu: Add support for the larger fifo found on sun5i and sun6i, having a separate compatible for the ir found on sun5i sun6i also is useful if we ever want to add ir transmit support, because the sun5i sun6i version do not have transmit support. Note this commits also adds checking for the end-of-packet interrupt flag (which was already enabled), as the fifo-data-available interrupt flag only gets set when the trigger-level is exceeded. So far we've been getting away with not doing this because of the low trigger-level, but this is something which we should have done since day one. Signed-off-by: Hans de Goede hdego...@redhat.com As this is meant to be merged via some other tree: Acked-by: Mauro Carvalho Chehab mche...@osg.samsung.com I think merging it through your tree would be just fine. Acked-by: Maxime Ripard maxime.rip...@free-electrons.com Heh, I was thinking it would be best if it went through Maxime's tree because it also has some deps on new clk stuff (well the dts have deps on that), but either way works for me. Maxime if you want this go through Mauro's tree, I can send a pull-req to Mauro (I'm a linux-media sub-maintainer), so if that is the case let me know and I'll prepare a pull-req (after fixing the missing reset documentation in the bindings). 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 1/9] clk: sunxi: Give sunxi_factors_register a registers parameter
Hi,
On 11/21/2014 09:35 AM, Maxime Ripard wrote:
Hi Hans,
On Thu, Nov 20, 2014 at 04:55:20PM +0100, Hans de Goede wrote:
Before this commit sunxi_factors_register uses of_iomap(node, 0) to get
the clk registers. The sun6i prcm has factor clocks, for which we want to
use sunxi_factors_register, but of_iomap(node, 0) does not work for the prcm
factor clocks, because the prcm uses the mfd framework, so the registers
are not part of the dt-node, instead they are added to the platform_device,
as platform_device resources.
This commit makes getting the registers the callers duty, so that
sunxi_factors_register can be used with mfd instantiated platform device too.
Signed-off-by: Hans de Goede hdego...@redhat.com
Funny, I was thinking of doing exactly the same thing for MMC clocks :)
---
drivers/clk/sunxi/clk-factors.c| 10 --
drivers/clk/sunxi/clk-factors.h| 7 ---
drivers/clk/sunxi/clk-mod0.c | 6 --
drivers/clk/sunxi/clk-sun8i-mbus.c | 2 +-
drivers/clk/sunxi/clk-sunxi.c | 3 ++-
5 files changed, 15 insertions(+), 13 deletions(-)
diff --git a/drivers/clk/sunxi/clk-factors.c
b/drivers/clk/sunxi/clk-factors.c
index f83ba09..fc4f4b5 100644
--- a/drivers/clk/sunxi/clk-factors.c
+++ b/drivers/clk/sunxi/clk-factors.c
@@ -156,9 +156,10 @@ static const struct clk_ops clk_factors_ops = {
.set_rate = clk_factors_set_rate,
};
-struct clk * __init sunxi_factors_register(struct device_node *node,
- const struct factors_data *data,
- spinlock_t *lock)
+struct clk *sunxi_factors_register(struct device_node *node,
+ const struct factors_data *data,
+ spinlock_t *lock,
+ void __iomem *reg)
{
struct clk *clk;
struct clk_factors *factors;
@@ -168,11 +169,8 @@ struct clk * __init sunxi_factors_register(struct
device_node *node,
struct clk_hw *mux_hw = NULL;
const char *clk_name = node-name;
const char *parents[FACTORS_MAX_PARENTS];
-void __iomem *reg;
int i = 0;
-reg = of_iomap(node, 0);
-
/* if we have a mux, we will have 1 parents */
while (i FACTORS_MAX_PARENTS
(parents[i] = of_clk_get_parent_name(node, i)) != NULL)
diff --git a/drivers/clk/sunxi/clk-factors.h
b/drivers/clk/sunxi/clk-factors.h
index 9913840..1f5526d 100644
--- a/drivers/clk/sunxi/clk-factors.h
+++ b/drivers/clk/sunxi/clk-factors.h
@@ -37,8 +37,9 @@ struct clk_factors {
spinlock_t *lock;
};
-struct clk * __init sunxi_factors_register(struct device_node *node,
- const struct factors_data *data,
- spinlock_t *lock);
+struct clk *sunxi_factors_register(struct device_node *node,
+ const struct factors_data *data,
+ spinlock_t *lock,
+ void __iomem *reg);
Why are you dropping the __init there?
Because it is going to be used from mfd instantiation, so from a platform_dev
probe function which is not __init.
#endif
diff --git a/drivers/clk/sunxi/clk-mod0.c b/drivers/clk/sunxi/clk-mod0.c
index 4a56385..9530833 100644
--- a/drivers/clk/sunxi/clk-mod0.c
+++ b/drivers/clk/sunxi/clk-mod0.c
@@ -78,7 +78,8 @@ static DEFINE_SPINLOCK(sun4i_a10_mod0_lock);
static void __init sun4i_a10_mod0_setup(struct device_node *node)
{
-sunxi_factors_register(node, sun4i_a10_mod0_data,
sun4i_a10_mod0_lock);
+sunxi_factors_register(node, sun4i_a10_mod0_data,
+ sun4i_a10_mod0_lock, of_iomap(node, 0));
As of_iomap can fail, I'd rather check the returned value before
calling sunxi_factors_register.
I know it wasn't done before, but it's the right thing to do, as it
would lead to an instant crash if that fails.
Ok, I'll wait for you to review the rest of the series and then do a v2 of the
patch-set with this fixed (as time permits).
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 3/9] clk: sunxi: Add prcm mod0 clock driver
Hi,
On Thu, Nov 20, 2014 at 04:55:22PM +0100, Hans de Goede wrote:
Add a driver for mod0 clocks found in the prcm. Currently there is only
one mod0 clocks in the prcm, the ir clock.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
Documentation/devicetree/bindings/clock/sunxi.txt | 1 +
drivers/clk/sunxi/Makefile| 2 +-
drivers/clk/sunxi/clk-sun6i-prcm-mod0.c | 63
+++
drivers/mfd/sun6i-prcm.c | 14 +
4 files changed, 79 insertions(+), 1 deletion(-)
create mode 100644 drivers/clk/sunxi/clk-sun6i-prcm-mod0.c
diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt
b/Documentation/devicetree/bindings/clock/sunxi.txt
index ed116df..342c75a 100644
--- a/Documentation/devicetree/bindings/clock/sunxi.txt
+++ b/Documentation/devicetree/bindings/clock/sunxi.txt
@@ -56,6 +56,7 @@ Required properties:
allwinner,sun4i-a10-usb-clk - for usb gates + resets on A10 / A20
allwinner,sun5i-a13-usb-clk - for usb gates + resets on A13
allwinner,sun6i-a31-usb-clk - for usb gates + resets on A31
+ allwinner,sun6i-a31-ir-clk - for the ir clock on A31
Required properties for all clocks:
- reg : shall be the control register address for the clock.
diff --git a/drivers/clk/sunxi/Makefile b/drivers/clk/sunxi/Makefile
index 7ddc2b5..daf8b1c 100644
--- a/drivers/clk/sunxi/Makefile
+++ b/drivers/clk/sunxi/Makefile
@@ -10,4 +10,4 @@ obj-y += clk-sun8i-mbus.o
obj-$(CONFIG_MFD_SUN6I_PRCM) += \
clk-sun6i-ar100.o clk-sun6i-apb0.o clk-sun6i-apb0-gates.o \
- clk-sun8i-apb0.o
+ clk-sun8i-apb0.o clk-sun6i-prcm-mod0.o
diff --git a/drivers/clk/sunxi/clk-sun6i-prcm-mod0.c
b/drivers/clk/sunxi/clk-sun6i-prcm-mod0.c
new file mode 100644
index 000..e80f18e
--- /dev/null
+++ b/drivers/clk/sunxi/clk-sun6i-prcm-mod0.c
@@ -0,0 +1,63 @@
+/*
+ * Allwinner A31 PRCM mod0 clock driver
+ *
+ * Copyright (C) 2014 Hans de Goede hdego...@redhat.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/clk-provider.h
+#include linux/clkdev.h
+#include linux/module.h
+#include linux/of_address.h
+#include linux/platform_device.h
+
+#include clk-factors.h
+#include clk-mod0.h
+
+static const struct of_device_id sun6i_a31_prcm_mod0_clk_dt_ids[] = {
+ { .compatible = allwinner,sun6i-a31-ir-clk },
+ { /* sentinel */ }
+};
+
+static DEFINE_SPINLOCK(sun6i_prcm_mod0_lock);
+
+static int sun6i_a31_prcm_mod0_clk_probe(struct platform_device *pdev)
+{
+ struct device_node *np = pdev-dev.of_node;
+ struct resource *r;
+ void __iomem *reg;
+
+ if (!np)
+ return -ENODEV;
+
+ r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ reg = devm_ioremap_resource(pdev-dev, r);
+ if (IS_ERR(reg))
+ return PTR_ERR(reg);
+
+ sunxi_factors_register(np, sun4i_a10_mod0_data,
+sun6i_prcm_mod0_lock, reg);
+ return 0;
+}
+
+static struct platform_driver sun6i_a31_prcm_mod0_clk_driver = {
+ .driver = {
+ .name = sun6i-a31-prcm-mod0-clk,
+ .of_match_table = sun6i_a31_prcm_mod0_clk_dt_ids,
+ },
+ .probe = sun6i_a31_prcm_mod0_clk_probe,
+};
+module_platform_driver(sun6i_a31_prcm_mod0_clk_driver);
+
+MODULE_DESCRIPTION(Allwinner A31 PRCM mod0 clock driver);
+MODULE_AUTHOR(Hans de Goede hdego...@redhat.com);
+MODULE_LICENSE(GPL);
I don't think this is the right approach, mainly for two reasons: the
compatible shouldn't change, and you're basically duplicating code
there.
I understand that you need the new compatible in order to avoid a
double probing: one by CLK_OF_DECLARE, and one by the usual mechanism,
and that also implies the second reason.
However, as those are not critical clocks that need to be here early
at boot, you can also fix this by turning the mod0 driver into a
platform driver itself. The compatible will be kept, the driver will
be the same.
The only thing we need to pay attention to is how client drivers
react when they cannot grab their clock. They should return
-EPROBE_DEFER, but that remains to be checked.
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] Re: [PATCH 4/9] rc: sunxi-cir: Add support for an optional reset controller
Hi Mauro, On Thu, Nov 20, 2014 at 02:28:31PM -0200, Mauro Carvalho Chehab wrote: Em Thu, 20 Nov 2014 16:55:23 +0100 Hans de Goede hdego...@redhat.com escreveu: On sun6i the cir block is attached to the reset controller, add support for de-asserting the reset if a reset controller is specified in dt. Signed-off-by: Hans de Goede hdego...@redhat.com As this is meant to be merged via some other tree: Acked-by: Mauro Carvalho Chehab mche...@osg.samsung.com Again, I think it'll be perfectly fine in your tree :) Once the documentation is updated, Acked-by: Maxime Ripard maxime.rip...@free-electrons.com 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: [PATCH 3/9] clk: sunxi: Add prcm mod0 clock driver
Hi,
On 11/21/2014 09:49 AM, Maxime Ripard wrote:
Hi,
On Thu, Nov 20, 2014 at 04:55:22PM +0100, Hans de Goede wrote:
Add a driver for mod0 clocks found in the prcm. Currently there is only
one mod0 clocks in the prcm, the ir clock.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
Documentation/devicetree/bindings/clock/sunxi.txt | 1 +
drivers/clk/sunxi/Makefile| 2 +-
drivers/clk/sunxi/clk-sun6i-prcm-mod0.c | 63
+++
drivers/mfd/sun6i-prcm.c | 14 +
4 files changed, 79 insertions(+), 1 deletion(-)
create mode 100644 drivers/clk/sunxi/clk-sun6i-prcm-mod0.c
diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt
b/Documentation/devicetree/bindings/clock/sunxi.txt
index ed116df..342c75a 100644
--- a/Documentation/devicetree/bindings/clock/sunxi.txt
+++ b/Documentation/devicetree/bindings/clock/sunxi.txt
@@ -56,6 +56,7 @@ Required properties:
allwinner,sun4i-a10-usb-clk - for usb gates + resets on A10 / A20
allwinner,sun5i-a13-usb-clk - for usb gates + resets on A13
allwinner,sun6i-a31-usb-clk - for usb gates + resets on A31
+allwinner,sun6i-a31-ir-clk - for the ir clock on A31
Required properties for all clocks:
- reg : shall be the control register address for the clock.
diff --git a/drivers/clk/sunxi/Makefile b/drivers/clk/sunxi/Makefile
index 7ddc2b5..daf8b1c 100644
--- a/drivers/clk/sunxi/Makefile
+++ b/drivers/clk/sunxi/Makefile
@@ -10,4 +10,4 @@ obj-y += clk-sun8i-mbus.o
obj-$(CONFIG_MFD_SUN6I_PRCM) += \
clk-sun6i-ar100.o clk-sun6i-apb0.o clk-sun6i-apb0-gates.o \
-clk-sun8i-apb0.o
+clk-sun8i-apb0.o clk-sun6i-prcm-mod0.o
diff --git a/drivers/clk/sunxi/clk-sun6i-prcm-mod0.c
b/drivers/clk/sunxi/clk-sun6i-prcm-mod0.c
new file mode 100644
index 000..e80f18e
--- /dev/null
+++ b/drivers/clk/sunxi/clk-sun6i-prcm-mod0.c
@@ -0,0 +1,63 @@
+/*
+ * Allwinner A31 PRCM mod0 clock driver
+ *
+ * Copyright (C) 2014 Hans de Goede hdego...@redhat.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/clk-provider.h
+#include linux/clkdev.h
+#include linux/module.h
+#include linux/of_address.h
+#include linux/platform_device.h
+
+#include clk-factors.h
+#include clk-mod0.h
+
+static const struct of_device_id sun6i_a31_prcm_mod0_clk_dt_ids[] = {
+{ .compatible = allwinner,sun6i-a31-ir-clk },
+{ /* sentinel */ }
+};
+
+static DEFINE_SPINLOCK(sun6i_prcm_mod0_lock);
+
+static int sun6i_a31_prcm_mod0_clk_probe(struct platform_device *pdev)
+{
+struct device_node *np = pdev-dev.of_node;
+struct resource *r;
+void __iomem *reg;
+
+if (!np)
+return -ENODEV;
+
+r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+reg = devm_ioremap_resource(pdev-dev, r);
+if (IS_ERR(reg))
+return PTR_ERR(reg);
+
+sunxi_factors_register(np, sun4i_a10_mod0_data,
+ sun6i_prcm_mod0_lock, reg);
+return 0;
+}
+
+static struct platform_driver sun6i_a31_prcm_mod0_clk_driver = {
+.driver = {
+.name = sun6i-a31-prcm-mod0-clk,
+.of_match_table = sun6i_a31_prcm_mod0_clk_dt_ids,
+},
+.probe = sun6i_a31_prcm_mod0_clk_probe,
+};
+module_platform_driver(sun6i_a31_prcm_mod0_clk_driver);
+
+MODULE_DESCRIPTION(Allwinner A31 PRCM mod0 clock driver);
+MODULE_AUTHOR(Hans de Goede hdego...@redhat.com);
+MODULE_LICENSE(GPL);
I don't think this is the right approach, mainly for two reasons: the
compatible shouldn't change, and you're basically duplicating code
there.
I understand that you need the new compatible in order to avoid a
double probing: one by CLK_OF_DECLARE, and one by the usual mechanism,
and that also implies the second reason.
Not only for that, we need a new compatible also because the mfd framework
needs a separate compatible per sub-node as that is how it finds nodes
to attach to the platform devices, so we need a new compatible anyways,
with your make the mod0 clock driver a platform driver solution we could
use:
compatible = allwinner,sun6i-a31-ir-clk,
allwinner,sun4i-a10-mod0-clk;
To work around this, but there are other problems, your make mod0clk a
platform driver solution cannot work because the clocks node in the dtsi
is not simple-bus compatible, so no platform-devs will be instantiated for
the clocks there.
Besides the compatible (which as said we need a separate one
[linux-sunxi] Re: [PATCH 5/9] rc: sunxi-cir: Add support for the larger fifo found on sun5i and sun6i
On Fri, Nov 21, 2014 at 09:42:09AM +0100, Hans de Goede wrote: Hi, On 11/21/2014 09:26 AM, Maxime Ripard wrote: Hi Mauro, On Thu, Nov 20, 2014 at 02:28:56PM -0200, Mauro Carvalho Chehab wrote: Em Thu, 20 Nov 2014 16:55:24 +0100 Hans de Goede hdego...@redhat.com escreveu: Add support for the larger fifo found on sun5i and sun6i, having a separate compatible for the ir found on sun5i sun6i also is useful if we ever want to add ir transmit support, because the sun5i sun6i version do not have transmit support. Note this commits also adds checking for the end-of-packet interrupt flag (which was already enabled), as the fifo-data-available interrupt flag only gets set when the trigger-level is exceeded. So far we've been getting away with not doing this because of the low trigger-level, but this is something which we should have done since day one. Signed-off-by: Hans de Goede hdego...@redhat.com As this is meant to be merged via some other tree: Acked-by: Mauro Carvalho Chehab mche...@osg.samsung.com I think merging it through your tree would be just fine. Acked-by: Maxime Ripard maxime.rip...@free-electrons.com Heh, I was thinking it would be best if it went through Maxime's tree because it also has some deps on new clk stuff (well the dts have deps on that), but either way works for me. Maxime if you want this go through Mauro's tree, I can send a pull-req to Mauro (I'm a linux-media sub-maintainer), so if that is the case let me know and I'll prepare a pull-req (after fixing the missing reset documentation in the bindings). So much for not reading the cover letter... Sorry. We're getting quite close to the end of the ARM merge window, and I got a couple comments, Lee hasn't commented yet, so I'd say it's a bit too late for this to come in. If Mauro is happy with the current patches for him, it's completely fine to merge it through his tree. The DTS can wait. 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: [PATCH 5/9] rc: sunxi-cir: Add support for the larger fifo found on sun5i and sun6i
Hi, On 11/21/2014 10:59 AM, Maxime Ripard wrote: On Fri, Nov 21, 2014 at 09:42:09AM +0100, Hans de Goede wrote: Hi, On 11/21/2014 09:26 AM, Maxime Ripard wrote: Hi Mauro, On Thu, Nov 20, 2014 at 02:28:56PM -0200, Mauro Carvalho Chehab wrote: Em Thu, 20 Nov 2014 16:55:24 +0100 Hans de Goede hdego...@redhat.com escreveu: Add support for the larger fifo found on sun5i and sun6i, having a separate compatible for the ir found on sun5i sun6i also is useful if we ever want to add ir transmit support, because the sun5i sun6i version do not have transmit support. Note this commits also adds checking for the end-of-packet interrupt flag (which was already enabled), as the fifo-data-available interrupt flag only gets set when the trigger-level is exceeded. So far we've been getting away with not doing this because of the low trigger-level, but this is something which we should have done since day one. Signed-off-by: Hans de Goede hdego...@redhat.com As this is meant to be merged via some other tree: Acked-by: Mauro Carvalho Chehab mche...@osg.samsung.com I think merging it through your tree would be just fine. Acked-by: Maxime Ripard maxime.rip...@free-electrons.com Heh, I was thinking it would be best if it went through Maxime's tree because it also has some deps on new clk stuff (well the dts have deps on that), but either way works for me. Maxime if you want this go through Mauro's tree, I can send a pull-req to Mauro (I'm a linux-media sub-maintainer), so if that is the case let me know and I'll prepare a pull-req (after fixing the missing reset documentation in the bindings). So much for not reading the cover letter... Sorry. We're getting quite close to the end of the ARM merge window, and I got a couple comments, Lee hasn't commented yet, so I'd say it's a bit too late for this to come in. Oh, but this was not intended for 3.19, this can wait till 3.20 from my pov, sorry if that was not clear. I was assuming that the merge window was more or less closed already, so that this going into 3.20 was expected. Regrrds, 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: New board: Merrii M2 (A20)
Hello Calzada, thank for your answer. when power the board with 12 V, in android every thing is ok, there is 5 v on SATA and USBs, but in linux there's not 5v in SATA and USBs power and in kernel booting after 10 second it reboot. this is link for my image, https://www.mediafire.com/folder/ur6fie0k2h1k3/r1.4 please send your image, thanks. On Thursday, November 20, 2014 8:11:45 PM UTC+3:30, Carlos Calzada Grau wrote: Hello, we are working on Merrii M2 too and the board works perfectly with 12V, we have the last sunxi-linux and a debian on the SD, I can send you an image if you want to test it On the other hand, do yo have power on the USBs and SATA? we have power booting with android but no power with sunxi-linux 2014-11-18 17:21 GMT+01:00 mahdi Chi mahd...@gmail.com javascript:: I work on Merri M2 and manage to build Linux for it. when i power up board with USB OTG it boot good. but when i power up the board with 12 v power socket it reboot repeatedly. do you have any advice to solve this problem? -- You received this message because you are subscribed to a topic in the Google Groups linux-sunxi group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/linux-sunxi/trGVVwsFRUY/unsubscribe. To unsubscribe from this group and all its topics, send an email to linux-sunxi...@googlegroups.com javascript:. For more options, visit https://groups.google.com/d/optout. -- Movil: (+34) 633534429 e-mail: car...@zausan.com javascript: web: www.zausan.com C/ 9 de Octubre, 82 1ยช Planta despacho 6. 46520. Puerto de Sagunto, Valencia. -- 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] Is it possible to encode multi(csi0, csi1) h.264 using the CedarX(Video Engine)?
Dear members. I have questions for CedarX(Video Engine). Is it possible situation? (at same runtime) +-+ | CSI0(NV21) --++- test0.mp4 | | +-- (CedarX)VE --+ | | CSI1(NV21) --++- test1.mp4 | +-+ Is the CedarX(Video Engine) supported to encode multiple instance? If it is not support, What should I do to encode multiple input? 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] Re: [PATCH 2/2] dt-bindings: simplefb-sunxi: Add sunxi simplefb extensions
On Wed, Nov 19, 2014 at 02:05:48PM +, Grant Likely wrote:
On Mon, Nov 17, 2014 at 3:55 PM, Maxime Ripard
maxime.rip...@free-electrons.com wrote:
On Mon, Nov 17, 2014 at 01:39:18PM +, Grant Likely wrote:
On Mon, Nov 17, 2014 at 12:47 PM, Maxime Ripard
maxime.rip...@free-electrons.com wrote:
On Mon, Nov 17, 2014 at 12:34:46PM +0100, Hans de Goede wrote:
If pre-filled framebuffer nodes are used, the firmware may need extra
properties to find the right node. This documents the properties to use
for this on sunxi platforms.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
.../bindings/video/simple-framebuffer-sunxi.txt| 33
++
1 file changed, 33 insertions(+)
create mode 100644
Documentation/devicetree/bindings/video/simple-framebuffer-sunxi.txt
diff --git
a/Documentation/devicetree/bindings/video/simple-framebuffer-sunxi.txt
b/Documentation/devicetree/bindings/video/simple-framebuffer-sunxi.txt
new file mode 100644
index 000..84ca264
--- /dev/null
+++
b/Documentation/devicetree/bindings/video/simple-framebuffer-sunxi.txt
@@ -0,0 +1,33 @@
+Sunxi specific Simple Framebuffer bindings
+
+This binding documents sunxi specific extensions to the
simple-framebuffer
+bindings. The sunxi simplefb u-boot code relies on the devicetree
containing
+pre-populated simplefb nodes.
+
+These extensions are intended so that u-boot can select the right node
based
+on which pipeline and output is being used. As such they are solely
intended
+for firmware / bootloader use, and the OS should ignore them.
+
+Required properties:
+- compatible: sunxi,framebuffer
+- sunxi,pipeline:
+ 0 for the de_be0 - lcdc0 - output pipeline
+ 1 for the de_be1 - lcdc1 - output pipeline
+- sunxi,output: One of: hdmi, lcd, vga, and composite
+
+Example:
+
+chosen {
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
+
+ framebuffer@0 {
+ compatible = sunxi,framebuffer, simple-framebuffer;
+ sunxi,pipeline = 0;
+ sunxi,output = hdmi;
+ clocks = pll5 1, ahb_gates 36, ahb_gates 43,
+ ahb_gates 44;
If we're going that way, then maybe having to specify clock-names
would be better in order to know which clock is what?
I wouldn't go that way with this binding since the driver has no need
to differentiate between the clocks, and driver authors shouldn't be
encouraged to do so. The purpose of the clocks in this node is only
for itemizing dependencies, not for how to configure the clocks.
Firmware shouldn't care at all about the clocks list, it only needs to
find the correct pre-populated node to fill in and enable.
Well, if we want to play the DT as an ABI stuff, you have no
guarantee that in the future, simplefb will still be the driver bound
to sunxi,framebuffer, and that this driver doesn't need to
differentiate which clocks it needs to protect and which are not
needed. Especially with the combination of the output that you now
hardcode.
As long as the node claims compatibility with simple-framebuffer,
then it must abide by the simple framebuffer rules. It cannot depend
on the driver having special knowledge about what to do with the
clocks. It is fine for a driver that understands sunxi,framebuffer
to enable additional features over and above simple-framebuffer,
providing it doesn't break the vanilla simple-framebuffer interface.
The simple-framebuffer binding is clear that it will treat the clocks
as dependencies only.
Isn't the compatible list precisely made to be able to define more
specific behaviours if needed?
If I get a list with sunxi,framebuffer, simple-framebuffer, I've
always thought that sunxi,framebuffer was defining exactly what the
device was about, and that simple-framebuffer was only aimed at
providing roughly the same functionnality, possibly with degraded
features, and with a compatible DT bindings.
I don't see how if we require a clock-names list in sunxi,framebuffer
that would break the binding of simple-framebuffer. It's just more
information, that might prove useful in the future.
Of course, if now we don't care at all about this ABI thing, it's
completely fine for me. But I'll archive this email preciously.
I do not in any way mean to say it is okay to break ABI.
Also, my comments above are advice that I would give to U-Boot
authors, not something that should go in the binding. The
simple-framebuffer binding doesn't need to know about the clock names
at all, and if the assumption is that firmware will merely enable a
pre-populated framebuffer node in the tree, then it probably doesn't
need to parse the clocks property either. However, if it actually is
better for the U-Boot implementation to have clocks with names in the
node, then I'm not going to object.
Re: [linux-sunxi] Is it possible to encode multi(csi0, csi1) h.264 using the CedarX(Video Engine)?
CedarX doesn't do very good video. These Hi3518E camera boards are much more effective - $11 http://www.aliexpress.com/item/Pre-order-2-0MP-IP-Camera-Module-1080P-HD-Support-Intelligent-Video-Analytics-Hi3516C-1-2/1838582703.html Those boards run Linux and support ONVIF. You can use a cheap Ethernet switch and hook up a bunch of them to your Allwinner system. On Fri, Nov 21, 2014 at 6:26 AM, JongHo Kim furmu...@gmail.com wrote: Dear members. I have questions for CedarX(Video Engine). Is it possible situation? (at same runtime) +-+ | CSI0(NV21) --++- test0.mp4 | | +-- (CedarX)VE --+ | | CSI1(NV21) --++- test1.mp4 | +-+ Is the CedarX(Video Engine) supported to encode multiple instance? If it is not support, What should I do to encode multiple input? 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. -- Jon Smirl jonsm...@gmail.com -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: is it possible to chnage fb0 width and height for dual display.
Hi Punith, Try run fbset -xres 720 -yres 480 -x -a before starting Xorg, it works for me with LCD+HDMI configuretion. Why didn't you try 480p HDMI mode? Regards Dmitry On Wednesday, November 19, 2014 5:54:27 PM UTC+6, Puneet B wrote: Hi Dmitry, Thanks for your reply, Here my update in ubuntu. My HDMI is full screen with 1280x720p mode with normal layer (scaler not enabled). My TV output is full screen with 720x480 mode with scaler enable. but problem is i am not getting video output on TV because scaler enabled. so i disable the scaler for TV by fallowing command a10disp --screen 1 disablescaler. then i am getting video on both display(i did some changes in VDAPU code also). but home screen on TV going out of monitor. i need to reduce fb width and height for only TV without affecting HDMI. this i need to do without enabling scaler for TV. Could you have any idea to fix this , kindly let me know. Regards Punith -- 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] linux backports
Thanks. I think I was a little confused at how to use the tarballs. I tried using those but now when I boot up I get plastered with: compat: exports duplicate symbol clk_disable (owned by kernel) The major driver I was looking at updating was the Atheros ath9k_htc driver. Maybe I'll just try to find that independently... On Thu, Nov 20, 2014 at 5:18 PM, Julian Calaby julian.cal...@gmail.com wrote: Hi Tim, On Fri, Nov 21, 2014 at 8:18 AM, Tim Tisdall tisd...@gmail.com wrote: Has anyone tried running linux backports on the sunxi-3.4 branch? I'm trying to backport from linux-stable and here's the output: tim@ebtim:~/engage/txcz_a20/backports$ ../env/bin/python gentree.py --integrate --clean --gitdebug --git-revision master ~/engage/txcz_a20/linux-stable/ ~/engage/txcz_a20/linux-sunxi/ [snip] I've never done this stuff before, so it's possible I'm also just doing it wrong. I'm not overly familiar with it either, however it looks like it's not compatible with your kernel tree. From what I read when the latest version was released a couple of days ago, --integrate only works with linux-next newer than 2014-11-14. Unless you _need_ the drivers built in, I strongly recommend you just use their pre-patched tarballs instead of gentree as it's much easier. Thanks, -- Julian Calaby Email: julian.cal...@gmail.com Profile: http://www.google.com/profiles/julian.calaby/ -- You received this message because you are subscribed to a topic in the Google Groups linux-sunxi group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/linux-sunxi/mGRSdX5KKrc/unsubscribe. To unsubscribe from this group and all its topics, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] linux backports
Hi Tim, On Sat, Nov 22, 2014 at 6:37 AM, Tim Tisdall tisd...@gmail.com wrote: Thanks. I think I was a little confused at how to use the tarballs. I tried using those but now when I boot up I get plastered with: compat: exports duplicate symbol clk_disable (owned by kernel) Ugh. It's possible that some stuff has been already backported for our 3.4 kernel. The major driver I was looking at updating was the Atheros ath9k_htc driver. Maybe I'll just try to find that independently... I don't believe you will as everyone's supposed to get backported versions through the backports project. IIRC you can configure backports so it'll only produce a specific set of drivers - that might mean that it doesn't try to duplicate symbols already in our tree. Thanks, Julian Calaby On Thu, Nov 20, 2014 at 5:18 PM, Julian Calaby julian.cal...@gmail.com wrote: Hi Tim, On Fri, Nov 21, 2014 at 8:18 AM, Tim Tisdall tisd...@gmail.com wrote: Has anyone tried running linux backports on the sunxi-3.4 branch? I'm trying to backport from linux-stable and here's the output: tim@ebtim:~/engage/txcz_a20/backports$ ../env/bin/python gentree.py --integrate --clean --gitdebug --git-revision master ~/engage/txcz_a20/linux-stable/ ~/engage/txcz_a20/linux-sunxi/ [snip] I've never done this stuff before, so it's possible I'm also just doing it wrong. I'm not overly familiar with it either, however it looks like it's not compatible with your kernel tree. From what I read when the latest version was released a couple of days ago, --integrate only works with linux-next newer than 2014-11-14. Unless you _need_ the drivers built in, I strongly recommend you just use their pre-patched tarballs instead of gentree as it's much easier. Thanks, -- Julian Calaby Email: julian.cal...@gmail.com Profile: http://www.google.com/profiles/julian.calaby/ -- You received this message because you are subscribed to a topic in the Google Groups linux-sunxi group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/linux-sunxi/mGRSdX5KKrc/unsubscribe. To unsubscribe from this group and all its topics, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- Julian Calaby Email: julian.cal...@gmail.com Profile: http://www.google.com/profiles/julian.calaby/ -- 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.
