[linux-sunxi] Re: [PATCH v2 2/4] ARM: sunxi: Add ahci-sunxi driver for the Allwinner SUNXi SoCs sata
On Sunday 05 January 2014, Hans de Goede wrote:
Also, please send the binding as a separate patch with Cc to
the devicetree-discuss mailing list.
Hmm, this contradicts what others are saying who have requested for
the binding docs to be part of the same commit as the driver (with
various other drivers). Note that I've cc-ed devicetree already.
Probably my fault then, I've been away for some time and may misremember
what we discussed. Maybe someone else can clarify.
+static int sunxi_ahci_phy_init(struct device *dev, void __iomem *reg_base)
+{
+ u32 reg_val;
+ int timeout;
+
+ /* This magic is from the original code */
+ writel(0, reg_base + AHCI_RWCR);
+ mdelay(5);
This function should probably be in a separate phy driver. I would
very much hope that we can minimize the required code in an AHCI
driver and move code from this new file into the ahci-platform
driver. The clock, regulator and phy setup can all be optional
properties of the generic driver, and then there shouldn't
be much left that is sunxi specific.
Writing a phy driver, and extending ahci-platform to use that
was my original plan. But the phy really is part of the
ahci ip-block here, and not a separate ip-block. Its registers
are smack in the middle of the io-range for the ahci function.
I see. I wonder if the register layout is common with some other
implementation then. If it's part of the AHCI block, it's probably
not an Allwinner invention but comes from whoever implemented the
AHCI.
Also note that sunxi_ahci_pre_start_engine is rather sunxi
specific. Needing to put that in a generic ahci_platform driver
and only activating it for sunxi socs would only serve to
prove my point that at some point it is simply easier and
better to write a non generic platform glue driver when dealing
with exotic ahci ip blocks.
If we end up putting all sort of if soca do foo else if socb
do bar, else do nothing magic in ahci_platform.c I think we're
over generalizing. If something nicely fits as a generic
platform dev, by all means we should use a generic platform
driver, but that just won't work cleanly here.
Yes, but there may be some middle ground. I still think it would
be worthwhile to make the clock handling part of the common
ahci (or ahci-platform) driver and reuse that, since it seems
to be needed on a number of implementations. IIRC there is already
some inheritence model in libata that can be used to define
variations of drivers and have common parts done only once.
Actually I've just completed writing a phy driver for
the usbphy in the same soc, and a patch to extend ehci-platform
to take an optional clk and phy. So I completely agree with the
basic idea, it just does not seem doable cleanly in this case,
hence my choice to write a separate platform driver. For the
usb stuff (wip) see:
https://github.com/jwrdegoede/linux-sunxi/commit/4655dd01936f42d8a75da08a00af439e0a34eaf7
https://github.com/jwrdegoede/linux-sunxi/commit/bcb674859d015ff9e082829dbd5cf239b8b53d4a
Ah, very nice!
+static int sunxi_ahci_susp(struct device *dev)
+{
+ struct ata_host *host = dev_get_drvdata(dev);
+ struct ahci_host_priv *hpriv = host-private_data;
+ struct sunxi_ahci *ahci = hpriv-plat_data;
+ int ret;
+
+ /*
+ * AHCI spec rev1.1 section 8.3.3:
+ * Software must disable interrupts prior to requesting a
+ * transition of the HBA to D3 state.
+ */
+ sunxi_clrbits(hpriv-mmio + HOST_CTL, HOST_IRQ_EN);
+
+ ret = ata_host_suspend(host, PMSG_SUSPEND);
+ if (ret)
+ return ret;
+
+ sunxi_ahci_disable_clks(ahci);
+
+ return 0;
+}
The only thing in here that seems sunxi-specific is the irq disabling
part. Can't you do this instead by calling disable_irq() and make
the function completely generic?
The irq disabling part actually is not sunxi specific, ahci_platform.c
has it too.
Ok. Can this function be shared in some way then, e.g. by exporting the
ahci-platform implementation?
Arnd
--
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/groups/opt_out.
[linux-sunxi] Re: Experimental sunxi-devel branch with updated ehci driver using a separate phy driver.
Hi, On 01/05/2014 11:56 AM, Arokux X wrote: Hello Hans, On Sun, Jan 5, 2014 at 12:48 AM, Hans de Goede hdego...@redhat.com wrote: Hi Arokux et al, So I've been working on cleaning up the sunxi-ehci support by writing a separate phy driver for the usbphy part of the SoC. This is turning out quite nicely, for those interested you can find my wip here: Note only tested on sun7i sofar, and the sun4i / sun5i dt bits aren't updated yet. The bulk of the work is in these 2 commits: https://github.com/jwrdegoede/linux-sunxi/commit/4655dd01936f42d8a75da08a00af439e0a34eaf7 https://github.com/jwrdegoede/linux-sunxi/commit/bcb674859d015ff9e082829dbd5cf239b8b53d4a Nice work! Thanks. Have you maybe forgotten to commit changes to the corresponding dtsi files? Yes and no, as mentioned I've only updated and tested sun7i dts(i) atm. I'm particularly interested in how do you bind reset bits. I'm still using your hack which uses Maxime's reset driver, I know this is wrong. I thought you already had a fix for this, which is why I've been asking you to push your latest work. If you don't have a fix yet, I can look into one. I've not touched this part yet because I thought you already have a fix. In addition I've seen you did this https://github.com/jwrdegoede/linux-sunxi/commit/e2d95f5509f799c4264153ae8dd9d51eb2baba42 Are you maybe trying to use reset driver written by Maxime to handle sunxi reset bits? Yes, and as said I know this is wrong, but it works for now, for upstream this need to be properly fixed. There was a try to do it like so and the above rename was done by Maxime (and I had the code that has used it). Later howerever he has reverted this rename since it was decided to use the feature of the clk framework which can handle reset bits. Here is an example drivers/usb/phy/phy-msm-usb.c +309 Ah, examples are always good. So if you don't have a fix for this yet let me know and I'll go and write one based on this. I was not following Maxime's work closely lately, so can you please clarify this? See above. 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/groups/opt_out.
[linux-sunxi] Re: [PATCH v2 2/4] ARM: sunxi: Add ahci-sunxi driver for the Allwinner SUNXi SoCs sata
On 01/04/14 22:47, Arnd Bergmann wrote: On Saturday 04 January 2014 22:39:50 Arnd Bergmann wrote: +Required properties: +- compatible : compatible list, contains allwinner,sun4i-a10-ahci +- reg: registers mapping +- interrupts : interrupt mapping for AHCI IRQ +- clocks : clocks for ACHI +- clock-names: clock names for AHCI The binding needs to specify the required names for the clocks. fwiw, the imx driver uses ahb and sata_ref as the clock names. I would strongly suggest using the same names here, and documenting them in the ahci binding as optional. This is my fault, and you just reminded me I should have fixed that from the previous comments. It just slipped my mind and I'm sorry for that! Hans, I'll go over the original commit thread and pick up all changes and send them as a patch to you Monday. Oliver Arnd -- 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/groups/opt_out.
[linux-sunxi] Re: [PATCH v2 2/4] ARM: sunxi: Add ahci-sunxi driver for the Allwinner SUNXi SoCs sata
Hi, On 01/05/2014 01:42 PM, Olliver Schinagl wrote: On 01/04/14 22:47, Arnd Bergmann wrote: On Saturday 04 January 2014 22:39:50 Arnd Bergmann wrote: +Required properties: +- compatible : compatible list, contains allwinner,sun4i-a10-ahci +- reg: registers mapping +- interrupts : interrupt mapping for AHCI IRQ +- clocks : clocks for ACHI +- clock-names: clock names for AHCI The binding needs to specify the required names for the clocks. fwiw, the imx driver uses ahb and sata_ref as the clock names. I would strongly suggest using the same names here, and documenting them in the ahci binding as optional. This is my fault, and you just reminded me I should have fixed that from the previous comments. It just slipped my mind and I'm sorry for that! Hans, I'll go over the original commit thread and pick up all changes and send them as a patch to you Monday. As I just mentioned to Arnd I've a better idea to be able to re-use most of the ahci_platform.c code without copy-pasting it. So I'm going to do a v3 soonish. Can you please just make a mail with summary of the requested changes and send that to me, or do this after I've send v3 ? Thanks, 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/groups/opt_out.
[linux-sunxi] Re: [PATCH v2 2/4] ARM: sunxi: Add ahci-sunxi driver for the Allwinner SUNXi SoCs sata
On 01/05/14 14:32, Hans de Goede wrote: Hi, On 01/05/2014 01:42 PM, Olliver Schinagl wrote: On 01/04/14 22:47, Arnd Bergmann wrote: On Saturday 04 January 2014 22:39:50 Arnd Bergmann wrote: +Required properties: +- compatible : compatible list, contains allwinner,sun4i-a10-ahci +- reg: registers mapping +- interrupts : interrupt mapping for AHCI IRQ +- clocks : clocks for ACHI +- clock-names: clock names for AHCI The binding needs to specify the required names for the clocks. fwiw, the imx driver uses ahb and sata_ref as the clock names. I would strongly suggest using the same names here, and documenting them in the ahci binding as optional. This is my fault, and you just reminded me I should have fixed that from the previous comments. It just slipped my mind and I'm sorry for that! Hans, I'll go over the original commit thread and pick up all changes and send them as a patch to you Monday. As I just mentioned to Arnd I've a better idea to be able to re-use most of the ahci_platform.c code without copy-pasting it. So I'm going to do a v3 soonish. Can you please just make a mail with summary of the requested changes and send that to me, or do this after I've send v3 ? if memory serves, it was mostly about the dt documentation and binding names, i'll work on it first thing tomorrow morning ;) Thanks, 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/groups/opt_out.
[linux-sunxi] Device list contribution procedure
Hello everybody, I bought an A20 tablet which doesn't seems to be listed in the wiki device list, I would be happy to contribute in any way to provide all the information about it, I took some PCB pictures, I started to list all the chip inside. At this point I can boot linux on it thank to Olimex OlinuXino-A20 image, I've started to extract android initialization info from the nanda. The PCB is tagged as A70X1_V2. What is the procedure to update the Wiki, who should I contact to give all the pictures, and others information? If you are interested. Best regards, Alexis. -- 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/groups/opt_out.
[linux-sunxi] [PATCH 2/2] ARM: sun7i: dts: Add NMI irqchip support
This patch adds DTS entry for NMI controller as child of GIC.
Signed-off-by: Carlo Caione carlo.cai...@gmail.com
---
arch/arm/boot/dts/sun7i-a20.dtsi | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi
index 4c25f81..89e93da 100644
--- a/arch/arm/boot/dts/sun7i-a20.dtsi
+++ b/arch/arm/boot/dts/sun7i-a20.dtsi
@@ -310,6 +310,15 @@
#size-cells = 1;
ranges;
+ nmi_intc: sc-nmi-intc@01c00030 {
+ compatible = allwinner,sun7i-sc-nmi;
+ interrupt-controller;
+ #interrupt-cells = 2;
+ reg = 0x01c00030 0x0c;
+ interrupt-parent = gic;
+ interrupts = 0 0 1;
+ };
+
emac: ethernet@01c0b000 {
compatible = allwinner,sun4i-emac;
reg = 0x01c0b000 0x1000;
--
1.8.5.2
--
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/groups/opt_out.
[linux-sunxi] [PATCH 0/2] ARM: sun7i: irqchip driver for NMI
Allwinner A20 SoCs have a special interrupt controller for managing NMI. Three register are present to (un)mask, control and acknowledge NMI. These two patches add a new irqchip driver in cascade with GIC. Carlo Caione (2): ARM: sun7i: Add irqchip driver for NMI controller ARM: sun7i: dts: Add NMI irqchip support arch/arm/boot/dts/sun7i-a20.dtsi | 9 ++ drivers/irqchip/Makefile | 1 + drivers/irqchip/irq-sun7i-nmi.c | 192 +++ 3 files changed, 202 insertions(+) create mode 100644 drivers/irqchip/irq-sun7i-nmi.c -- 1.8.5.2 -- 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/groups/opt_out.
[linux-sunxi] [PATCH 1/2] ARM: sun7i: Add irqchip driver for NMI controller
Allwinner A20 SoCs have special registers to control / (un)mask /
acknowledge NMI. This NMI controller is separated and independent from GIC.
This patch adds a new irqchip to manage NMI.
Signed-off-by: Carlo Caione carlo.cai...@gmail.com
---
drivers/irqchip/Makefile| 1 +
drivers/irqchip/irq-sun7i-nmi.c | 191
2 files changed, 192 insertions(+)
create mode 100644 drivers/irqchip/irq-sun7i-nmi.c
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index c60b901..d6ad783 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -11,6 +11,7 @@ obj-$(CONFIG_METAG_PERFCOUNTER_IRQS) += irq-metag.o
obj-$(CONFIG_ARCH_MOXART) += irq-moxart.o
obj-$(CONFIG_ORION_IRQCHIP)+= irq-orion.o
obj-$(CONFIG_ARCH_SUNXI) += irq-sun4i.o
+obj-$(CONFIG_ARCH_SUNXI) += irq-sun7i-nmi.o
obj-$(CONFIG_ARCH_SPEAR3XX)+= spear-shirq.o
obj-$(CONFIG_ARM_GIC) += irq-gic.o
obj-$(CONFIG_ARM_NVIC) += irq-nvic.o
diff --git a/drivers/irqchip/irq-sun7i-nmi.c b/drivers/irqchip/irq-sun7i-nmi.c
new file mode 100644
index 000..c36a236
--- /dev/null
+++ b/drivers/irqchip/irq-sun7i-nmi.c
@@ -0,0 +1,191 @@
+/*
+ * Allwinner A20 SoCs NMI IRQ chip driver.
+ *
+ * Carlo Caione carlo.cai...@gmail.com
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed as is without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include linux/bitops.h
+#include linux/device.h
+#include linux/io.h
+#include linux/irq.h
+#include linux/interrupt.h
+#include linux/irqdomain.h
+#include linux/of_irq.h
+#include linux/of_address.h
+#include linux/of_platform.h
+#include linux/irqchip/chained_irq.h
+#include irqchip.h
+
+#define SUN7I_NMI_IRQ_CTRL_REG 0x00
+#define SUN7I_NMI_IRQ_PEND_REG 0x04
+#define SUN7I_NMI_IRQ_EN_REG 0x08
+
+#define SUN7I_NMI_SRC_TYPE_MASK0x0003
+
+enum {
+ SUN7I_SRC_TYPE_LEVEL_LOW = 0,
+ SUN7I_SRC_TYPE_EDGE_FALLING,
+ SUN7I_SRC_TYPE_LEVEL_HIGH,
+ SUN7I_SRC_TYPE_EDGE_RISING,
+};
+
+/*
+ * Ack level interrupts right before unmask
+ *
+ * In case of level-triggered interrupt, IRQ line must be acked before it
+ * is unmasked or else a double-interrupt is triggered
+ */
+
+static void sun7i_sc_nmi_ack_and_unmask(struct irq_data *d)
+{
+ struct irq_chip_generic *gc = irq_data_get_irq_chip_data(d);
+ struct irq_chip_type *ct = irq_data_get_chip_type(d);
+ u32 mask = d-mask;
+
+ if (irqd_get_trigger_type(d) IRQ_TYPE_LEVEL_MASK)
+ ct-chip.irq_ack(d);
+
+ irq_gc_lock(gc);
+ irq_reg_writel(mask, gc-reg_base + ct-regs.mask);
+ irq_gc_unlock(gc);
+}
+
+static inline void sun7i_sc_nmi_write(struct irq_chip_generic *gc, u32 off,
+ u32 val)
+{
+ irq_reg_writel(val, gc-reg_base + off);
+}
+
+static inline u32 sun7i_sc_nmi_read(struct irq_chip_generic *gc, u32 off)
+{
+ return irq_reg_readl(gc-reg_base + off);
+}
+
+static void sun7i_sc_nmi_handle_irq(unsigned int irq, struct irq_desc *desc)
+{
+ struct irq_domain *domain = irq_desc_get_handler_data(desc);
+ struct irq_chip *chip = irq_get_chip(irq);
+ unsigned int virq = irq_find_mapping(domain, 0);
+
+ chained_irq_enter(chip, desc);
+ generic_handle_irq(virq);
+ chained_irq_exit(chip, desc);
+}
+
+static int sun7i_sc_nmi_set_type(struct irq_data *data, unsigned int flow_type)
+{
+ struct irq_chip_generic *gc = irq_data_get_irq_chip_data(data);
+ u32 src_type_reg;
+ unsigned int src_type;
+
+ irq_gc_lock(gc);
+
+ switch (flow_type IRQF_TRIGGER_MASK) {
+ case IRQ_TYPE_EDGE_FALLING:
+ src_type = SUN7I_SRC_TYPE_EDGE_FALLING;
+ break;
+ case IRQ_TYPE_EDGE_RISING:
+ src_type = SUN7I_SRC_TYPE_EDGE_RISING;
+ break;
+ case IRQ_TYPE_LEVEL_HIGH:
+ src_type = SUN7I_SRC_TYPE_LEVEL_HIGH;
+ break;
+ case IRQ_TYPE_NONE:
+ case IRQ_TYPE_LEVEL_LOW:
+ src_type = SUN7I_SRC_TYPE_LEVEL_LOW;
+ break;
+ default:
+ irq_gc_unlock(gc);
+ pr_err(%s: Cannot assign multiple trigger modes to IRQ %d.\n,
+ __func__, data-irq);
+ return -EBADR;
+ }
+
+ irqd_set_trigger_type(data, flow_type);
+ irq_setup_alt_chip(data, flow_type);
+
+ src_type_reg = sun7i_sc_nmi_read(gc, SUN7I_NMI_IRQ_CTRL_REG);
+ src_type_reg = ~SUN7I_NMI_SRC_TYPE_MASK;
+ src_type_reg |= src_type;
+ sun7i_sc_nmi_write(gc, SUN7I_NMI_IRQ_CTRL_REG, src_type_reg);
+
+ irq_gc_unlock(gc);
+
+ return IRQ_SET_MASK_OK;
+}
+
+static int __init sun7i_sc_nmi_irq_init(struct device_node *node,
+ struct device_node *parent)
+{
+
Re: [linux-sunxi] OV2643 Camera on A20
On Sun, Jan 5, 2014 at 5:38 AM, Michal Suchanek hramr...@gmail.com wrote: AFAIK the camera board is connected digitally so the noise is something that is internal to the camera board. It is normal that under low light condition the image is noisy. Did you try taking pictures in full daylight or using some photography lighting? I have four other USB webcams and none of them have this noise under same lighting conditions. I have two other Allwinner systems with cameras and they all have noise. I checked it out this morning under sunlight. It is better but the noise is still there. Maybe the camera images need some image processing that is not getting turned on under the Allwinner platform? All of the Allwinner devices appear to be running Allwinner SDK with only minor changes. They probably all copied each other. The datasheet for the image sensor is here: http://files.virt2real.ru/docs/ It is also possible that image processing features of the sensor chip are not properly enabled. The noise can be removed in software and the AW chips should have some image filter which is probably unused as of now. Thanks Michal On 5 January 2014 06:32, jonsm...@gmail.com jonsm...@gmail.com wrote: I have an A20 system here that has a lot of noise in the camera. Does anyone have experience with noise like this? Is this something that software can impact or is it a problem in PCB? It is OV2643 image sensor. Looks like it is using this driver. http://files.virt2real.ru/docs/ P1050011_1.JPGhttps://docs.google.com/file/d/0B-2Z6FDzyIwrSkNucEdLRjVXQVU/edit?usp=drive_web P1050013_1.JPGhttps://docs.google.com/file/d/0B-2Z6FDzyIwrVkhyREhRQXBLaW8/edit?usp=drive_web -- 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/groups/opt_out. -- 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/groups/opt_out. -- 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/groups/opt_out.
Re: [linux-sunxi] How to use socketcan in android application layer
On 12/21/2013 12:55 PM, Peter Chen wrote: Thanks for you reply.The link should helps me a lot.Here is the CAN controller document, hope it help those CAN driver deps. Thanks for your documentation! AFAIK, there is Flexcan implement in android framework, https://github.com/zhangjie201412/Flexcan.git hope this helps. Regards, Kaspter -- 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/groups/opt_out.
Re: [linux-sunxi] OV2643 Camera on A20
The unit has a Chinese Android build on it which is slowing me down. I haven't figure out how to start adb Ethernet daemon on target device. On Sun, Jan 5, 2014 at 12:01 PM, jonsm...@gmail.com jonsm...@gmail.comwrote: On Sun, Jan 5, 2014 at 11:55 AM, Michal Suchanek hramr...@gmail.comwrote: On 5 January 2014 17:48, jonsm...@gmail.com jonsm...@gmail.com wrote: On Sun, Jan 5, 2014 at 11:43 AM, Michal Suchanek hramr...@gmail.com wrote: On 5 January 2014 16:50, jonsm...@gmail.com jonsm...@gmail.com wrote: On Sun, Jan 5, 2014 at 5:38 AM, Michal Suchanek hramr...@gmail.com wrote: AFAIK the camera board is connected digitally so the noise is something that is internal to the camera board. It is normal that under low light condition the image is noisy. Did you try taking pictures in full daylight or using some photography lighting? I have four other USB webcams and none of them have this noise under same lighting conditions. I have two other Allwinner systems with cameras and they all have noise. I checked it out this morning under sunlight. It is better but the noise is still there. Maybe the camera images need some image processing that is not getting turned on under the Allwinner platform? All of the Allwinner devices appear to be running Allwinner SDK with only minor changes. They probably all copied each other. The datasheet for the image sensor is here: http://files.virt2real.ru/docs/ It is also possible that image processing features of the sensor chip are not properly enabled. According to the datasheet the camera chip has various image processing filters including noise reduction. Does the driver support tuning these filters? I can modify driver. But that triggers the whole problem of being able to rebuild the software for these devices. I'm trying to figure out how to extract the fex files. They are STBs and don't have normal Android buttons. Meaning not even a FEL button? No OTG USB port. They put a hub chip on the board and only exposed host port. Do you get access to the boot partition with adb? The other way would be to run a non-broken Linux system from SD card. Getting at least serial or ethernet should be easy if the box has those. Or an USB Ethernet. It has Ethernet. I'm trying to figure it out, I haven't used Android SDK with Ethernet before. Thanks Michal -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- Jon Smirl jonsm...@gmail.com -- 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/groups/opt_out.
Re: [linux-sunxi] Re: Internal photos of EU3000 A20 web cam
On Sun, Jan 5, 2014 at 1:12 PM, selim.bay...@gmail.com wrote: 3 Ekim 2013 Perşembe 17:56:24 UTC+3 tarihinde Jon Smirl yazdı: I have one of these A20 based EU3000 web cams. http://www.aliexpress.com/store/product/EU3000-HD2-Android4-2-TV-Box-Allwinner-A20-Cortex-Dual-Core-A7-5-0MP-Camera-MIC/507965_1213723041.html Nice case and tiny package. OV5640 sensor. Photos of inside plus fex file. https://drive.google.com/folderview?id=0B-2Z6FDzyIwraE9aWFhfN3lKcHcusp=sharing Can anyone id the chip between the SDCard socket and the A20? They've sanded the markings off. Crystal next to it is 24.576Mhz which is multiple of 48Khz. Maybe a USB hub? But why would they need a hub chip? There is dmesg from boot in folder. Note that I had an external hub plugged in during boot. External hub has keyboard, mouse and a webcam. I wanted to get the Android ADK debugger going on it, but something is corrupted with the debug usb devices. ADK shows a device but won't let me access it. I wanted to install a fresh Android build to see if I can get debugging to work. -- Jon Smirl Hi Jon, Thanks for your photos inside of EU3000. I just wanted to make a prototype of a device and want to learn if this device is appropriate for my prototype. I need some place to change the position of camera. As I see from the photos there are insulation tapes over camera wires and camera itself. Can I easily change the position of camera. And can you tell the approximate distance between camera sensor and connection on the board.? It is on a flex cable about 1in long. Selim -- 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/groups/opt_out. -- 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/groups/opt_out.
Re: [linux-sunxi] Re: A good SD card image for A10-OLinuXino-Lime?
On Sunday, January 5, 2014 5:00:00 PM UTC-5, Siarhei Siamashka wrote: On Wed, 1 Jan 2014 20:03:35 -0800 (PST) Patrick Wood patric...@gmail.com javascript: wrote: On Wednesday, January 1, 2014 5:54:20 PM UTC-5, Siarhei Siamashka wrote: I myself still see no good reason for using any governor other than performance when running with a wall connected power plug. Poor default cpufreq behaviour is a major performance pitfall for inexperienced users and it totally kills desktop responsiveness. We may introduce a new customized cpufreq governor and set it by default. The users can always change the cpufreq settings to whatever they want. Moreover, as a temporary solution, I would probably even advocate setting the performance cpufreq governor for linux-sunxi kernels by default (for the linux defconfigs). Do we have many tablet users, who are running linux instead of android and also need good battery life (have no usb ports or chargers nearby for providing power)? I believe that a minimum setting of 408MHZ with the interactive governor works quite well. This governor raises the CPU clock much faster than ondemand, and 408MHz seems to be a spot where the SoC will power down a lot of blocks when idle. Is this just a speculation? Or some kind of research has been done? It was based on the comments in this commit: 47d3b18876571835f0fce7b7b8125110713e30fc Also, my experience with performance on the A10 devices over the last two years has shown me that ondemand is a really terrible governor, as it doesn't boost the CPU frequency unless utilization has been high over an extended period, so even programs that are CPU bound don't cause it to switch if they spend just a little time reading or writing data. interactive is much better at increasing the CPU clock even on relatively small changes in demand. What we know for sure is that the current cpufreq defaults (ondemand for sun4i and fantasy for sun7i) are responsible for really poor performance. Note that sun4i and sun7i are defaulting to different governors for some unknown reason. And there is one more source of inconsistency. The range of allowed CPU frequencies and their voltages can be configured in fex files for each device/board individually. For example, compare cubieboard2 and cubietruck fex files: https://github.com/linux-sunxi/sunxi-boards/blob/36a6f268b69afde7/sys_config/a20/cubieboard2.fex#L957 https://github.com/linux-sunxi/sunxi-boards/blob/36a6f268b69afde7/sys_config/a20/cubietruck.fex#L944 The minimum CPU clock frequency for the cubieboard2 is set to 400MHz. And for cubietruck the lowest limit is 60MHz. This means that the fantasy governor on cubieboard2 will run the idle system at 384MHz, but on cubietruck that would be supposedly 60MHz. Funny, isn't it? This is a big freaking mess. No argument there. Also, perhaps the minimum setting should be 1GHz at boot time and not dropped until the UI is up and running, since this affects the overall boot speed by quite a bit, and that's the first impression any user gets of a distro -- how long it takes to get my login prompt or splash screen. Does it mean that currently the ondemand / fantasy / interactive governors are also responsible poor boot time? That's one more reason to do something about this. I don't know about fantasy, but I do know that boot times are faster with interactive than ondemand given the same 60 MHz minimum clock frequency setting (based on the boot log time stamps); boot times don't change much switching from interactive to performance. I tried to look into this stuff and run some tests on cubieboard2 and cubietruck using the current stage/linux-sunxi-3.4 branch. As Michal Suchanek mentioned earlier in this thread, we have AXP209 power management chip. And it has some interesting registers (REG 00H and REG 01H): http://linux-sunxi.org/AXP209#REG_00H:_Power_input_status The values of these registers are exposed to the userspace via /sys/devices/platform/sunxi-i2c.0/i2c-0/0-0034/axp20_regs AXP209 also has IRQs for the notifications about plugging/removing different power sources: ACIN (power plug), VBUS (miniusb) and LiPo battery. So looks like the hardware mostly provides all that we need. Now the results of some tests are below. They were done with screen blanked because this saves ~20 mA of current. I also have a LiPo battery, earlier bought from OLIMEX: https://www.olimex.com/Products/Power/BATTERY-LIPO6600mAh/ The connector of this LiPo battery is mechanically incompatible with cubietruck, but I still got it temporarily connected just for the sake of this experiment using jumper wires. Now the results: === cubietruck === # echo 1 /sys/devices/platform/disp/graphics/fb0/blank # cat /sys/devices/platform/sunxi-i2c.0/i2c-0/0-0034/axp20_regs only
Re: [linux-sunxi] Re: A good SD card image for A10-OLinuXino-Lime?
On Sun, 5 Jan 2014 16:01:20 -0800 (PST) Patrick Wood patrickhw...@gmail.com wrote: Also, my experience with performance on the A10 devices over the last two years has shown me that ondemand is a really terrible governor, as it doesn't boost the CPU frequency unless utilization has been high over an extended period This is easily tunable via knobs mentioned at http://linux-sunxi.org/Cpufreq Specifically you want to reduce the up_threshold, in the example on that page the frequency will be boosted as soon as the CPU utilization even touches 25%. Not high over extended period, is it? And then if an issue arises that it drops back too quickly, that can be tuned by changing sampling_down_factor. so even programs that are CPU bound don't cause it to switch if they spend just a little time reading or writing data. Set io_is_busy to 1, and even time spent reading or writing data (in iowait) will count as CPU load for the purposes of frequency switching. interactive is much better at increasing the CPU clock even on relatively small changes in demand. My guess is that people tend to invent crazy new obscure governors mostly because they didn't spend any time reading documentation for the existing ones (and how to properly configure them for the usage scenario at hand). -- With respect, Roman signature.asc Description: PGP signature
Re: [linux-sunxi] Re: A good SD card image for A10-OLinuXino-Lime?
On Sunday, January 5, 2014 7:13:06 PM UTC-5, Roman Mamedov wrote: On Sun, 5 Jan 2014 16:01:20 -0800 (PST) Patrick Wood patric...@gmail.com javascript: wrote: Also, my experience with performance on the A10 devices over the last two years has shown me that ondemand is a really terrible governor, as it doesn't boost the CPU frequency unless utilization has been high over an extended period This is easily tunable via knobs mentioned at http://linux-sunxi.org/Cpufreq Specifically you want to reduce the up_threshold, in the example on that page the frequency will be boosted as soon as the CPU utilization even touches 25%. Not high over extended period, is it? And then if an issue arises that it drops back too quickly, that can be tuned by changing sampling_down_factor. Yes, but most people don't bother to read that. In fact, most people don't know about the cpu governors; they just complain about performance. The default settings for ondemand are obviously poor for non-battery use. Also, none of these knobs helps boot times. so even programs that are CPU bound don't cause it to switch if they spend just a little time reading or writing data. Set io_is_busy to 1, and even time spent reading or writing data (in iowait) will count as CPU load for the purposes of frequency switching. See comment above. interactive is much better at increasing the CPU clock even on relatively small changes in demand. My guess is that people tend to invent crazy new obscure governors mostly because they didn't spend any time reading documentation for the existing ones (and how to properly configure them for the usage scenario at hand). See comment above. The current default governor (ondemand) and/or its default settings need to be changed. Pat -- With respect, Roman -- 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/groups/opt_out.
Re: [linux-sunxi] Re: A good SD card image for A10-OLinuXino-Lime?
On Sun, 5 Jan 2014 23:25:29 +0100 Michal Suchanek hramr...@gmail.com wrote: On 5 January 2014 23:00, Siarhei Siamashka siarhei.siamas...@gmail.com wrote: === cubietruck === # echo 1 /sys/devices/platform/disp/graphics/fb0/blank # cat /sys/devices/platform/sunxi-i2c.0/i2c-0/0-0034/axp20_regs only power adapter : REG[0x0]=0xc1,REG[0x1]=0x10 power adapter + miniusb : REG[0x0]=0xf9,REG[0x1]=0x10 only miniusb : REG[0x0]=0x3d,REG[0x1]=0x70 miniusb + lipo battery : REG[0x0]=0x3d,REG[0x1]=0x70 power adapter + lipo battery : REG[0x0]=0xc5,REG[0x1]=0x70 only lipo battery: REG[0x0]=0x1,REG[0x1]=0x30 Note: only miniusb and miniusb + lipo battery really have the same AXP20 register values, that's not a typo. Power consumption measurements with a multimeter on the 5V barrel power plug: idle at 60MHz : ~271 mA idle at 912MHz : ~287 mA Note: while cpufreq reports 60MHz clock frequency, the CPU really runs faster than this and the benchmarks indicate that it is more likely to be something around ~240MHz. === cubieboard2 === # echo 1 /sys/devices/platform/disp/graphics/fb0/blank # echo 6 /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq # echo 6 /sys/devices/system/cpu/cpu1/cpufreq/scaling_min_freq # cat /sys/devices/platform/sunxi-i2c.0/i2c-0/0-0034/axp20_regs REG[0x0]=0xc1,REG[0x1]=0x10 Note: The values of AXP20 registers are always the same (no matter whether only a miniusb cable is plugged, or a barrel power plug, or both of them). Power consumption measurements with a multimeter on the 5V barrel power plug: idle at 60MHz : ~219 mA idle at 912MHz : ~238 mA Note: the 60MHz CPU clock speed is fake here too (just like for the cubietruck). Given these stunning power savings I guess playing with cpufreq is really quite pointless on A20. I'm more worried that there seems to be a bug in sun7i cpufreq. It thinks that the CPU clock frequency is 60MHz, but in fact the multipliers are likely wrong because the actual performance of the CPU is higher (~240MHz). Still the voltages are taken from the table and applied. One experiment was to force the use of the cpufreq table hardcoded in the kernel sources instead of taking it from fex by changing 'use_default_table' variable: https://github.com/linux-sunxi/linux-sunxi/blob/77a43694fca9db61/arch/arm/mach-sun7i/cpu-freq/cpu-freq.c#L84 If I do this, the voltage for 60MHz clock speed would be 0.9V instead of 1.05V as hardcoded in the cubietruck fex: https://github.com/linux-sunxi/sunxi-boards/blob/36a6f268b69afde7/sys_config/a20/cubietruck.fex#L961 And after this change, any attempt to use 0.9V with the clock frequency which happens to be actually used instead of 60MHz results in a deadlock. The 0.9V is apparently not enough. I'm also wonder whether 1.05V used by cubietruck when it attempts to reduce the clock frequency to 60MHz (and uses something else instead) is still safe. It might be a potential reliability issue. It would be interesting to test some other kernels (from android?), because this might be a bug only affecting sunxi-3.4. The way to go is probably to use performance governor and STR when battery powered. STR as Suspend-to-RAM? That would be very interesting indeed. It should work on sun7i iirc. With AR100 chip? Or also without it? I wonder if there is some way to power down one of the cores and what savings that could give. Yes, an interesting idea indeed. -- 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/groups/opt_out.
[linux-sunxi] [PATCH v2 1/8] clk: sunxi: add clock-output-names dt property support
sunxi clock drivers use dt node name as clock name, but clock nodes should be named clk@X, so the names would be the same. Let the drivers read clock names from dt clock-output-names property. Signed-off-by: Chen-Yu Tsai w...@csie.org --- drivers/clk/sunxi/clk-sunxi.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c index 19d9e9e..14a3774 100644 --- a/drivers/clk/sunxi/clk-sunxi.c +++ b/drivers/clk/sunxi/clk-sunxi.c @@ -53,6 +53,8 @@ static void __init sun4i_osc_clk_setup(struct device_node *node) if (of_property_read_u32(node, clock-frequency, rate)) return; + of_property_read_string(node, clock-output-names, clk_name); + /* set up gate and fixed rate properties */ gate-reg = of_iomap(node, 0); gate-bit_idx = SUNXI_OSC24M_GATE; @@ -595,6 +597,8 @@ static void __init sunxi_mux_clk_setup(struct device_node *node, (parents[i] = of_clk_get_parent_name(node, i)) != NULL) i++; + of_property_read_string(node, clock-output-names, clk_name); + clk = clk_register_mux(NULL, clk_name, parents, i, CLK_SET_RATE_NO_REPARENT, reg, data-shift, SUNXI_MUX_GATE_WIDTH, @@ -654,6 +658,8 @@ static void __init sunxi_divider_clk_setup(struct device_node *node, clk_parent = of_clk_get_parent_name(node, 0); + of_property_read_string(node, clock-output-names, clk_name); + clk = clk_register_divider(NULL, clk_name, clk_parent, 0, reg, data-shift, data-width, data-pow ? CLK_DIVIDER_POWER_OF_TWO : 0, -- 1.8.5.2 -- 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/groups/opt_out.
[linux-sunxi] Re: [PATCH 1/2] ohci-platform: Add support for devicetree instantiation
Hi,
On 01/06/2014 08:16 AM, Arnd Bergmann wrote:
On Monday 06 January 2014, Hans de Goede wrote:
+Required properties:
+ - compatible: Should be platform-ohci
+ - reg: Address range of the ohci registers.
+ - interrupts: Should contain the ohci interrupt.
+
+Optional properties:
+ - clocks: array of clocks
+ - clock-names: clock names ahb and/or ohci
+ - phys: phy
+ - phy-names: usb_phy
Maybe just usb? It obviously is a phy, so that part of the name
is a bit redundant. Actually, the usb part of the name also seems
redundant. Is it possible to make it an anonymous phy reference
without a phy-names property as we often do for clocks?
I'm not a big fan of anonymous references, IE currently the ahci-platform
driver is using an anonymous clk reference, but for sunxi (and ie imx too)
it needs to be extended to 2 clks, which means using names, while
keeping compatibility with the older anonymous using dts (and board)
files.
So I can agree to dropping the _phy, but I would like to keep the usb
name I realize the chances are slim of ever needing 2 phys but never
say never ...
+static int ohci_platform_power_on(struct platform_device *dev)
+{
+ struct usb_hcd *hcd = platform_get_drvdata(dev);
+ struct ohci_platform_priv *priv =
+ (struct ohci_platform_priv *)hcd_to_ohci(hcd)-priv;
+ int ret;
+
+ if (!IS_ERR(priv-ohci_clk)) {
+ ret = clk_prepare_enable(priv-ohci_clk);
+ if (ret)
+ return ret;
+ }
+
+ if (!IS_ERR(priv-ahb_clk)) {
+ ret = clk_prepare_enable(priv-ahb_clk);
+ if (ret)
+ goto err_disable_ohci_clk;
+ }
+
+ if (!IS_ERR(priv-phy)) {
+ ret = phy_init(priv-phy);
+ if (ret)
+ goto err_disable_ahb_clk;
+
+ ret = phy_power_on(priv-phy);
+ if (ret)
+ goto err_exit_phy;
+ }
Style-wise, I think I'd prefer not storing error values in the
ohci_platform_priv struct, but rather using NULL pointers for
when the clocks or phy references are unused.
This is a style I picked up from the mmc code, ie do a grep for
!IS_ERR in drivers/mmc/host/*.c, but I agree it is not the prettiest,
and on looking in other subsystems it is not common, so I'll convert
this to storing NULL on error to get the phy or clk.
@@ -83,17 +171,30 @@ static int ohci_platform_probe(struct platform_device *dev)
return -ENXIO;
}
+ hcd = usb_create_hcd(ohci_platform_hc_driver, dev-dev,
+ dev_name(dev-dev));
+ if (!hcd)
+ return -ENOMEM;
+
+ if (pdata == ohci_platform_defaults) {
+ struct ohci_platform_priv *priv = (struct ohci_platform_priv *)
+ hcd_to_ohci(hcd)-priv;
+
+ priv-phy = devm_phy_get(dev-dev, usb_phy);
+ if (IS_ERR(priv-phy) PTR_ERR(priv-phy) == -EPROBE_DEFER) {
+ err = -EPROBE_DEFER;
+ goto err_put_hcd;
+ }
+
+ priv-ohci_clk = devm_clk_get(dev-dev, ohci);
+ priv-ahb_clk = devm_clk_get(dev-dev, ahb);
+ }
I think you have to check the clocks for -EPROBE_DEFER as well here, not
just the PHY.
So far I've never seen clk_get return -EPROBE_DEFER, but I guess on some
platforms it can.
Otherwise you don't know the difference between no clock
provided, error getting the clock reference and clock controller not
initialized yet, try again.
I guess of these 3 we really only want to continue on no clock provided,
so I think something like this (for both clks and the phy) would be best:
priv-ahb_clk = devm_clk_get(dev-dev, ahb);
if (IS_ERR(priv-ahb_clk)) {
err = PTR_ERR(priv-ahb_clk);
if (err != -EINVAL err != -ENODATA)
goto err_put_hcd;
priv-ahb_clk = NULL; /* No clock provided */
}
To clarify -EINVAL will be returned when there is no clock-names, and
-ENODATA when the specified name is not found in clock-names.
@@ -178,6 +277,12 @@ static int ohci_platform_resume(struct device *dev)
#define ohci_platform_resume NULL
#endif /* CONFIG_PM */
+static const struct of_device_id ohci_platform_ids[] = {
+ { .compatible = platform-ohci, },
+ { }
+};
+MODULE_DEVICE_TABLE(of, ohci_platform_ids);
I never liked the platform-* naming for compatible properties, the
name of the driver is just based on a linux implementation detail
(the platform bus), which could change. How about just calling the
generic one ohci or usb-ohci?
usb-ohci seems free but usb-ehci are already taken by
drivers/usb/host/ehci-ppc-of.c which is as the name implies pretty ppc
specific. And since ehci-platform.c can be build on ppc too, we could
end up with 2 drivers
