Re: [linux-sunxi] Re: [U-Boot] Basic A33 support including dram init available in my personal repo
On Mon, Mar 09, 2015 at 05:04:15PM +0800, Chen-Yu Tsai wrote: Hi, On Mon, Mar 9, 2015 at 4:39 PM, Vishnu Patekar vishnupatekar0...@gmail.com wrote: Hello, It's sensible work by Allwinner to release the dram code under GPLv2. Now, we can have mainline u-boot support for A33 soon. Hans, Yes, I've very basic A33 dts created based on A23, still lot to do. About the dts, so far the memory maps look the same. I haven't checked the clocks or interrupts, but I bet they are the same as well. Could we use an overlay over A23 with just the different pieces overriden? Though they're not the same piece of silicon, they are damn close. Maybe even the PIO is the same. I'd prefer something like sun8i.dtsi, and then include it from both sun8i-a23.dtsi and sun8i-a33.dtsi, like we did recently for sun5i, but that's a detail. But yeah, if they're that close, we should definitely share as much as possible. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: Digital signature
Re: Re: Re: [linux-sunxi] how to build an linux image for A31S
On 9 March 2015 at 08:01, Code Kipper codekip...@gmail.com wrote: On 9 March 2015 at 07:41, Quink wantl...@gmail.com wrote: If the serial port is usable, maybe you can boot into fel mode by press '2' in serial terminal and then power on the device. I've tried connecting just a USB-A-USB-A to the board to see if it powers up but it didn't and as I'm quite keen to keep this for now as an Android box I didn't investigate any further. I do have a USB-A cable somewhere that just has the data lines connected so I can try with this and the unit's PSU. Just to update, I can get the board into fel mode by pressing '2' on powerup but I can't seem to detect the fel device on the usb. CK CK On Mon, Mar 9, 2015 at 1:28 PM, Code Kipper codekip...@gmail.com wrote: On 9 March 2015 at 03:56, li lijiamin...@163.com wrote: Hi pere canadell, the device is http://linux-sunxi.org/VidOn_Box, but i can't find the image for it. Best Regards, stone Hi Stone I don't think you'll have any chance of getting anything other than VidOn's firmware onto this device without doing some serious hardware modifications. There is no sdcard to boot from or OTG to get the device into fel mode. I have this hardware and I'm still trying to find a way to get it to boot into fel mode. For now only serial debug is possible. BR, CK -- 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. -- 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. -- 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 4/7] ARM: dts: sun5i: Add new Auxtek-t004 board
On Sun, Mar 08, 2015 at 08:15:30PM +0100, Hans de Goede wrote: Hi, On 08-03-15 18:21, Maxime Ripard wrote: On Sat, Mar 07, 2015 at 08:01:21PM +0100, Hans de Goede wrote: The auxtek-t004: http://www.fasttech.com/products/1110/10004200/1318603-auxtek-t004-allwinner-a10s-single-core-android-ics Is an Allwinner A10s based hdmi tv stick with with 512M RAM, 4G nand flash, toc9002 (bcm43362) sdio wifi, 1 USB host ports using an USB-A receptacle and a 2 micro-usb receptacles, one for power and one for USB OTG. The sdio wifi appears to not have an oob irq hooked up, so we rely on sdio-irq support for it. Signed-off-by: Hans de Goede hdego...@redhat.com foo I'm not sure what that foo was about :) Heh, that was the commit message of a fixup commit which I apparently added with a s (squash) rather then a f (fix) when doing a rebase -i leaving the foo in the combined commit msg. So now if you ever see a foo in a commit msg from me again you know where it comes from :) Noted :) 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] ARM: sun7i: dt: Add new MK808C device
On Sun, Mar 08, 2015 at 10:18:30PM +0100, Arnd Bergmann wrote: On Sunday 08 March 2015 18:47:21 Maxime Ripard wrote: Not enough information to check signature validity. Show Details Hi, On Sat, Mar 07, 2015 at 09:41:54AM +0100, Code Kipper wrote: Don't your device has any brand on the case or the PCB? There is nothing on the PCB to reference a manufacturer, the actual packaging and case are from the earlier MK808B and mention A9. There was only a small sticker on the side to show that the contents was a MK808C. I guess 'unknown' isn't a valid vendor name, Not really. I really don't know what's the policy to apply in such a case when we have a device that has no identified vendor. We need to give a vendor name, because the compatible is used to tell two devices apart, in the case where we would have to apply quirks for a particular devices. And if we have two devices (say a Marvlell and an Allwinner one), with the same name, and without any vendor, we're screwed. Maybe falling back to the SoC vendor, in our case, would make sense? Arnd? Rob? Mark? An opinion on this? I don't really have a good idea. In this case the SoC vendor might not be the worst choice, because it's likely to be very close to some reference design they actually did. Another possibility would be to use a string that refers to the organization that does the upstream kernel support, but that's harder for individuals that do not work for a company that wants its name used that way. Yeah, I don't really think that would be applicable for individuals, and would understand if people wouldn't like to follow such policy (I'm not even sure I would). At least, the SoC vendor name would be consistent, without being very touchy. 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 00/15] musb: Add support for the Allwinner sunxi musb controller
On Monday 09 March 2015 21:40:13 Hans de Goede wrote: Hi All, This patch set has been a while in the making, so I'm very happy to present the end result here, and I hope everyone likes it. Awesome work! Before talking about merging this there are 2 things which I would like to point out: a) The musb controller in the sunxi SoCs uses some SRAM which needs to be mapped to the musb controller by poking some bits in the SRAM controller, just like the EMAC patches which were send a while back I've chosen to use syscon for this, actually 2 of the patches in this set come directly from the SRAM mapping patchset for the EMAC. I know that Maxime is not 100% in favor of using syscon: http://lists.infradead.org/pipermail/linux-arm-kernel/2015-January/320221.html But I disagree with his arguments for writing a special driver for the SRAM controller: 1) syscon was specifically designed for global system control registers like this and is fine to use as long as there are no conflicts where 1 bit is of interest to multiple drivers, and there is no such conflict here 2) Maxime's other arguments seem to boil down to it would be nice / prettier to have a specific driver for this, without really proving a hard need for such a driver. But writing such a driver is going to be a lot of work, and we've a ton of other work to do, and as said there is no real need for a separate driver, syscon works fine for this. 3) I actually believe that having a specific driver for this is a bad idea, because that means inventing a whole new cross driver API for this, and getting those right is, hard, a lot of work, and even then one is still likely to get it wrong. We can avoid all this by going with the proven syscon solution. Maxime, can we please have your ack for moving forward with this using syscon? (see above for my arguments why) I'd like to understand here why we can't use the existing SRAM DT binding instead of the syscon binding. 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/d/optout.
[linux-sunxi] [PATCH 00/15] musb: Add support for the Allwinner sunxi musb controller
Hi All, This patch set has been a while in the making, so I'm very happy to present the end result here, and I hope everyone likes it. Before talking about merging this there are 2 things which I would like to point out: a) The musb controller in the sunxi SoCs uses some SRAM which needs to be mapped to the musb controller by poking some bits in the SRAM controller, just like the EMAC patches which were send a while back I've chosen to use syscon for this, actually 2 of the patches in this set come directly from the SRAM mapping patchset for the EMAC. I know that Maxime is not 100% in favor of using syscon: http://lists.infradead.org/pipermail/linux-arm-kernel/2015-January/320221.html But I disagree with his arguments for writing a special driver for the SRAM controller: 1) syscon was specifically designed for global system control registers like this and is fine to use as long as there are no conflicts where 1 bit is of interest to multiple drivers, and there is no such conflict here 2) Maxime's other arguments seem to boil down to it would be nice / prettier to have a specific driver for this, without really proving a hard need for such a driver. But writing such a driver is going to be a lot of work, and we've a ton of other work to do, and as said there is no real need for a separate driver, syscon works fine for this. 3) I actually believe that having a specific driver for this is a bad idea, because that means inventing a whole new cross driver API for this, and getting those right is, hard, a lot of work, and even then one is still likely to get it wrong. We can avoid all this by going with the proven syscon solution. Maxime, can we please have your ack for moving forward with this using syscon? (see above for my arguments why) b) If you look closely at the new drivers/usb/musb/sunxi.c file you will see that there is some register address translation happening in the sunxi_musb_readb() function and related functions. This is necessary because the registermap of the sunxi musb implementation is different from the other musb implementation and sunxi uses multi-platform kernels. I've considered adding full dynamic register map support to musb but I've chosen not to. The problem is that the way the musb code currently works is that there are 4 different address spaces used within the musb code: 1) musb-regs, the base address of the controller used for general control register access like the DEVCTL and POWER regs 2) The address space at the offset returned by musb_io.ep_offset, which contains ep control registers, this may be a different offset per endpoint, or indexed by the INDEX register 3) The address space at the offset returned by musb_io.fifo_offset, which contains the endpoint fifo data register, this is a different offset per ep. 4) The address space at the offset returned by MUSB_BUSCTL_OFFSET macro (which gets repaced by musb_io.busctl_offset in this patchset), this may be a different offset per endpoint, or indexed by the INDEX register Turning this into something using dynamic register mapping is quite hard, esp. since some parts of the address range are per endpoint and the number of endpoints varies from one implementation to the next. Besides this there also is the issue that I lack hardware to test invasive changes like this for all different musb variants. So I've chosen to do the necessary address translation (which really is only necessary for the general control registers) in a sunxi specific readb friends implementation, avoiding the need to make invasive chances elsewhere and thus hopefully avoiding any regressions. Note that some small core changes are still necessary, mostly to rationalize the busctl register handling, and make it more generic as sunxi has indexed busctl registers. So with that all said lets talk about getting this merged upstream, assuming that the code passes review :) The first patch in the set adds a header with defines for the sun4i syscon registers. Since this has already been acked by one of the MFD maintainers, I suggest we simply merge this through the musb maintainer together with all the other musb patches, as this introduces a new file without changing any other files collisions are impossible. The second patch makes some minimal changes to the phy-sun4i-usb driver, I believe it is best to merge this through the musb maintainer too, so that all buildtime deps go in through one tree. Kishon can you review this patch please and let us know if it is ok to merge this through the musb tree? Then we get 5 musb patches, 4 preparation patches and 1 adding the actual sunxi musb support, which should go through the musb tree obviously. So assuming everyone agrees this means that patches 1 - 7 should be merged through Felipe's tree. Felipe, is that ok with you and can you review these patches please? That leaves us with patches 8 - 15 which are all sunxi dts patches and as such should go upstream through Maxime's tree once patches 1 - 7
[linux-sunxi] [PATCH 01/15] ARM: sunxi: Add register bit definitions for SRAM mapping syscon
From: Chen-Yu Tsai w...@csie.org Signed-off-by: Chen-Yu Tsai w...@csie.org Signed-off-by: Jens Kuske jensku...@gmail.com Acked-by: Lee Jones lee.jo...@linaro.org Signed-off-by: Hans de Goede hdego...@redhat.com --- include/linux/mfd/syscon/sun4i-sc.h | 42 + 1 file changed, 42 insertions(+) create mode 100644 include/linux/mfd/syscon/sun4i-sc.h diff --git a/include/linux/mfd/syscon/sun4i-sc.h b/include/linux/mfd/syscon/sun4i-sc.h new file mode 100644 index 000..fb970d9 --- /dev/null +++ b/include/linux/mfd/syscon/sun4i-sc.h @@ -0,0 +1,42 @@ +/** + * sun4i-sc.h - Allwinner sun4i system control register bit definitions + * + * Copyright (C) 2014 Chen-Yu Tsai + * + * Chen-Yu Tsai w...@csie.org + * + * 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. + */ + +#ifndef __LINUX_SUN4I_SC_H +#define __LINUX_SUN4I_SC_H + +#include linux/bitops.h + +/* Registers */ +#define SUN4I_SC0 0x00 +#define SUN4I_SC1 0x04 + +/* SRAM control register 0 bits */ +#define SUN4I_SC0_SRAM_C1_MAP_VE 0x7fff + +/* SRAM control register 1 bits */ +#define SUN4I_SC1_BIST_NDMA_CTRL_SEL BIT(31) +#define SUN4I_SC1_SRAM_C3_MAP_ISP BIT(12) +#define SUN4I_SC1_SRAM_C2_MAP_MASK 0x0300 +#define SUN4I_SC1_SRAM_C2_MAP_AE 0x0100 +#define SUN4I_SC1_SRAM_C2_MAP_CE 0x0200 +#define SUN4I_SC1_SRAM_C2_MAP_ACE 0x0300 +#define SUN4I_SC1_SRAM_A3_A4_MAP_MASK 0x0030 +#define SUN4I_SC1_SRAM_A3_A4_MAP_EMAC 0x0010 +#define SUN4I_SC1_SRAM_D_MAP_USB0 BIT(0) + +#endif /* __LINUX_SUN4I_SC_H */ -- 2.3.1 -- 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 06/15] musb: Fix platform code being unable to override ep access ops
musb-core was setting the ops to the default indexed or flat handlers after
checking for platform overrides. Reverse the order of this so that platform
overrides actually work.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
drivers/usb/musb/musb_core.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 47c1a0a..374d181 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -2019,13 +2019,7 @@ musb_init_controller(struct device *dev, int nIrq, void
__iomem *ctrl)
if (musb-ops-quirks)
musb-io.quirks = musb-ops-quirks;
- /* At least tusb6010 has it's own offsets.. */
- if (musb-ops-ep_offset)
- musb-io.ep_offset = musb-ops-ep_offset;
- if (musb-ops-ep_select)
- musb-io.ep_select = musb-ops-ep_select;
-
- /* ..and some devices use indexed offset or flat offset */
+ /* Set default ep access to indexed offset or flat offset ops */
if (musb-io.quirks MUSB_INDEXED_EP) {
musb-io.ep_offset = musb_indexed_ep_offset;
musb-io.ep_select = musb_indexed_ep_select;
@@ -2033,6 +2027,11 @@ musb_init_controller(struct device *dev, int nIrq, void
__iomem *ctrl)
musb-io.ep_offset = musb_flat_ep_offset;
musb-io.ep_select = musb_flat_ep_select;
}
+ /* And override them with platform specific ops if specified. */
+ if (musb-ops-ep_offset)
+ musb-io.ep_offset = musb-ops-ep_offset;
+ if (musb-ops-ep_select)
+ musb-io.ep_select = musb-ops-ep_select;
if (musb-ops-fifo_mode)
fifo_mode = musb-ops-fifo_mode;
--
2.3.1
--
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 05/15] musb: Do not use musb_read[b|w] / _write[b|w] wrappers in generic fifo functions
The generic fifo functions already use non wrapped accesses in various
cases through the iowrite#_rep functions, and all platforms which override
the default musb_read[b|w] / _write[b|w] functions also provide their own
fifo access functions, so we can safely drop the unnecessary indirection
from the fifo access functions.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
drivers/usb/musb/musb_core.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index b71d310..47c1a0a 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -313,7 +313,7 @@ static void musb_default_write_fifo(struct musb_hw_ep
*hw_ep, u16 len,
index += len ~0x03;
}
if (len 0x02) {
- musb_writew(fifo, 0, *(u16 *)src[index]);
+ __raw_writew(*(u16 *)src[index], fifo);
index += 2;
}
} else {
@@ -323,7 +323,7 @@ static void musb_default_write_fifo(struct musb_hw_ep
*hw_ep, u16 len,
}
}
if (len 0x01)
- musb_writeb(fifo, 0, src[index]);
+ __raw_writeb(src[index], fifo);
} else {
/* byte aligned */
iowrite8_rep(fifo, src, len);
@@ -355,7 +355,7 @@ static void musb_default_read_fifo(struct musb_hw_ep
*hw_ep, u16 len, u8 *dst)
index = len ~0x03;
}
if (len 0x02) {
- *(u16 *)dst[index] = musb_readw(fifo, 0);
+ *(u16 *)dst[index] = __raw_readw(fifo);
index += 2;
}
} else {
@@ -365,7 +365,7 @@ static void musb_default_read_fifo(struct musb_hw_ep
*hw_ep, u16 len, u8 *dst)
}
}
if (len 0x01)
- dst[index] = musb_readb(fifo, 0);
+ dst[index] = __raw_readb(fifo);
} else {
/* byte aligned */
ioread8_rep(fifo, dst, len);
--
2.3.1
--
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 10/15] ARM: dts: sun5i: Add USB Dual Role Controller
Add a node for the otg/drc usb controller to sun5i-a1*.dtsi.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
arch/arm/boot/dts/sun5i.dtsi | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/sun5i.dtsi b/arch/arm/boot/dts/sun5i.dtsi
index 97b4eb1..cf730d4 100644
--- a/arch/arm/boot/dts/sun5i.dtsi
+++ b/arch/arm/boot/dts/sun5i.dtsi
@@ -384,6 +384,18 @@
status = disabled;
};
+ usb_otg: usb@01c13000 {
+ compatible = allwinner,sun4i-a10-musb;
+ reg = 0x01c13000 0x0400;
+ clocks = ahb_gates 0;
+ interrupts = 38;
+ interrupt-names = mc;
+ phys = usbphy 0;
+ phy-names = usb;
+ syscons = syscon;
+ status = disabled;
+ };
+
usbphy: phy@01c13400 {
#phy-cells = 1;
compatible = allwinner,sun5i-a13-usb-phy;
--
2.3.1
--
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 05/15] musb: Do not use musb_read[b|w] / _write[b|w] wrappers in generic fifo functions
On Monday 09 March 2015 21:40:18 Hans de Goede wrote: The generic fifo functions already use non wrapped accesses in various cases through the iowrite#_rep functions, and all platforms which override the default musb_read[b|w] / _write[b|w] functions also provide their own fifo access functions, so we can safely drop the unnecessary indirection from the fifo access functions. Signed-off-by: Hans de Goede hdego...@redhat.com The patch looks reasonably, but the description seem misleading. I believe the real reason why it's ok to use __raw_writew for the FIFO is that a FIFO by definition is using CPU endian access for copying byte streams from memory, which is unlike any other MMIO register that requires fixed-endian accessors. 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/d/optout.
[linux-sunxi] [PATCH 02/15] phy-sun4i-usb: Add a helper function to update the iscr register
Add sun4i_usb_phy_update_iscr() helper function to allow the otg driver to
update the sun4i usb phy0 Interface Status and Control Register.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
drivers/phy/phy-sun4i-usb.c | 13 +
include/linux/phy/phy-sun4i-usb.h | 26 ++
2 files changed, 39 insertions(+)
create mode 100644 include/linux/phy/phy-sun4i-usb.h
diff --git a/drivers/phy/phy-sun4i-usb.c b/drivers/phy/phy-sun4i-usb.c
index a2b08f3c..4742d5a 100644
--- a/drivers/phy/phy-sun4i-usb.c
+++ b/drivers/phy/phy-sun4i-usb.c
@@ -79,6 +79,19 @@ struct sun4i_usb_phy_data {
#define to_sun4i_usb_phy_data(phy) \
container_of((phy), struct sun4i_usb_phy_data, phys[(phy)-index])
+void sun4i_usb_phy_update_iscr(struct phy *_phy, u32 clr, u32 set)
+{
+ struct sun4i_usb_phy *phy = phy_get_drvdata(_phy);
+ struct sun4i_usb_phy_data *data = to_sun4i_usb_phy_data(phy);
+ u32 iscr;
+
+ iscr = readl(data-base + REG_ISCR);
+ iscr = ~clr;
+ iscr |= set;
+ writel(iscr, data-base + REG_ISCR);
+}
+EXPORT_SYMBOL(sun4i_usb_phy_update_iscr);
+
static void sun4i_usb_phy_write(struct sun4i_usb_phy *phy, u32 addr, u32 data,
int len)
{
diff --git a/include/linux/phy/phy-sun4i-usb.h
b/include/linux/phy/phy-sun4i-usb.h
new file mode 100644
index 000..f69e784
--- /dev/null
+++ b/include/linux/phy/phy-sun4i-usb.h
@@ -0,0 +1,26 @@
+/*
+ * Allwinner sun4i USB phy header
+ *
+ * Copyright (C) 2015 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.
+ */
+
+#ifndef __PHY_SUN4I_USB_H
+#define __PHY_SUN4I_USB_H
+
+#include linux/phy/phy.h
+
+/**
+ * sun4i_usb_phy_update_iscr() - Update sun4i usb phy0 Interface Status and
+ * Control bits
+ * @phy: Reference to sun4i usb phy0
+ * @clr: bits to clear in the ISCR register
+ * @set: bits to set in the ISCR register
+ */
+void sun4i_usb_phy_update_iscr(struct phy *phy, u32 clr, u32 set);
+
+#endif
--
2.3.1
--
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 08/15] ARM: dts: sunxi: Add syscon node for controlling SRAM mapping
From: Chen-Yu Tsai w...@csie.org
Allwinner SoCs have a system controller module that controls whether
SRAM blocks are mapped to the CPU memory or specific peripherals.
Signed-off-by: Chen-Yu Tsai w...@csie.org
[jensku...@gmail.com: duplicate syscon node to sun4i and sun5i]
Signed-off-by: Jens Kuske jensku...@gmail.com
Signed-off-by: Hans de Goede hdego...@redhat.com
---
arch/arm/boot/dts/sun4i-a10.dtsi | 5 +
arch/arm/boot/dts/sun5i.dtsi | 5 +
arch/arm/boot/dts/sun7i-a20.dtsi | 5 +
3 files changed, 15 insertions(+)
diff --git a/arch/arm/boot/dts/sun4i-a10.dtsi b/arch/arm/boot/dts/sun4i-a10.dtsi
index c66352b..2f792b6 100644
--- a/arch/arm/boot/dts/sun4i-a10.dtsi
+++ b/arch/arm/boot/dts/sun4i-a10.dtsi
@@ -457,6 +457,11 @@
#size-cells = 1;
ranges;
+ syscon: syscon@01c0 {
+ compatible = allwinner,sun4i-a10-syscon, syscon;
+ reg = 0x01c0 0x8;
+ };
+
dma: dma-controller@01c02000 {
compatible = allwinner,sun4i-a10-dma;
reg = 0x01c02000 0x1000;
diff --git a/arch/arm/boot/dts/sun5i.dtsi b/arch/arm/boot/dts/sun5i.dtsi
index 244d896..97b4eb1 100644
--- a/arch/arm/boot/dts/sun5i.dtsi
+++ b/arch/arm/boot/dts/sun5i.dtsi
@@ -298,6 +298,11 @@
#size-cells = 1;
ranges;
+ syscon: syscon@01c0 {
+ compatible = allwinner,sun4i-a10-syscon, syscon;
+ reg = 0x01c0 0x8;
+ };
+
dma: dma-controller@01c02000 {
compatible = allwinner,sun4i-a10-dma;
reg = 0x01c02000 0x1000;
diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi
index 8df77f5..fb56a1d 100644
--- a/arch/arm/boot/dts/sun7i-a20.dtsi
+++ b/arch/arm/boot/dts/sun7i-a20.dtsi
@@ -528,6 +528,11 @@
#size-cells = 1;
ranges;
+ syscon: syscon@01c0 {
+ compatible = allwinner,sun4i-a10-syscon, syscon;
+ reg = 0x01c0 0x8;
+ };
+
nmi_intc: interrupt-controller@01c00030 {
compatible = allwinner,sun7i-a20-sc-nmi;
interrupt-controller;
--
2.3.1
--
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 02/15] phy-sun4i-usb: Add a helper function to update the iscr register
On Monday 09 March 2015 21:40:15 Hans de Goede wrote:
+void sun4i_usb_phy_update_iscr(struct phy *_phy, u32 clr, u32 set)
+{
+ struct sun4i_usb_phy *phy = phy_get_drvdata(_phy);
+ struct sun4i_usb_phy_data *data = to_sun4i_usb_phy_data(phy);
+ u32 iscr;
+
+ iscr = readl(data-base + REG_ISCR);
+ iscr = ~clr;
+ iscr |= set;
+ writel(iscr, data-base + REG_ISCR);
+}
+EXPORT_SYMBOL(sun4i_usb_phy_update_iscr);
+
I would generally consider this a bad design. What is the purpose of
calling sun4i_usb_phy_update_iscr() and why can't there be a high-level
PHY API for this?
The only other phy driver with exports like this is the OMAP driver,
and that has caused problems in the past.
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/d/optout.
[linux-sunxi] [PATCH 12/15] ARM: dts: sun4i: Enable USB DRC on Chuwi V7 CW0825
Enable the otg/drc usb controller on the Chuwi V7 CW0825 tablet.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
arch/arm/boot/dts/sun4i-a10-chuwi-v7-cw0825.dts | 31 +
1 file changed, 31 insertions(+)
diff --git a/arch/arm/boot/dts/sun4i-a10-chuwi-v7-cw0825.dts
b/arch/arm/boot/dts/sun4i-a10-chuwi-v7-cw0825.dts
index 97fca89..034396c 100644
--- a/arch/arm/boot/dts/sun4i-a10-chuwi-v7-cw0825.dts
+++ b/arch/arm/boot/dts/sun4i-a10-chuwi-v7-cw0825.dts
@@ -111,6 +111,26 @@
status = okay;
};
+pio {
+ usb0_id_detect_pin: usb0_id_detect_pin@0 {
+ allwinner,pins = PH4;
+ allwinner,function = gpio_in;
+ allwinner,drive = SUN4I_PINCTRL_10_MA;
+ allwinner,pull = SUN4I_PINCTRL_PULL_UP;
+ };
+
+ usb0_vbus_detect_pin: usb0_vbus_detect_pin@0 {
+ allwinner,pins = PH5;
+ allwinner,function = gpio_in;
+ allwinner,drive = SUN4I_PINCTRL_10_MA;
+ allwinner,pull = SUN4I_PINCTRL_PULL_DOWN;
+ };
+};
+
+reg_usb0_vbus {
+ status = okay;
+};
+
reg_usb2_vbus {
status = okay;
};
@@ -121,7 +141,18 @@
status = okay;
};
+usb_otg {
+ pinctrl-names = default;
+ pinctrl-0 = usb0_id_detect_pin
+usb0_vbus_detect_pin;
+ id_det-gpio = pio 7 4 GPIO_ACTIVE_HIGH; /* PH4 */
+ vbus_det-gpio = pio 7 5 GPIO_ACTIVE_HIGH; /* PH5 */
+ dr_mode = otg;
+ status = okay;
+};
+
usbphy {
+ usb0_vbus-supply = reg_usb0_vbus;
usb2_vbus-supply = reg_usb2_vbus;
status = okay;
};
--
2.3.1
--
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 11/15] ARM: dts: sun7i: Add USB Dual Role Controller
From: Roman Byshko rbys...@gmail.com
Add a node for the otg/drc usb controller to sun7i-a20.dtsi
Signed-off-by: Hans de Goede hdego...@redhat.com
---
arch/arm/boot/dts/sun7i-a20.dtsi | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi
index fb56a1d..1d0b9ac 100644
--- a/arch/arm/boot/dts/sun7i-a20.dtsi
+++ b/arch/arm/boot/dts/sun7i-a20.dtsi
@@ -653,6 +653,18 @@
status = disabled;
};
+ usb_otg: usb@01c13000 {
+ compatible = allwinner,sun4i-a10-musb;
+ reg = 0x01c13000 0x0400;
+ clocks = ahb_gates 0;
+ interrupts = 0 38 4;
+ interrupt-names = mc;
+ phys = usbphy 0;
+ phy-names = usb;
+ syscons = syscon;
+ status = disabled;
+ };
+
usbphy: phy@01c13400 {
#phy-cells = 1;
compatible = allwinner,sun7i-a20-usb-phy;
--
2.3.1
--
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 09/15] ARM: dts: sun4i: Add USB Dual Role Controller
Add a node for the otg/drc usb controller to sun4i-a10.dtsi.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
arch/arm/boot/dts/sun4i-a10.dtsi | 12
drivers/usb/musb/Kconfig | 1 +
2 files changed, 13 insertions(+)
diff --git a/arch/arm/boot/dts/sun4i-a10.dtsi b/arch/arm/boot/dts/sun4i-a10.dtsi
index 2f792b6..e550415 100644
--- a/arch/arm/boot/dts/sun4i-a10.dtsi
+++ b/arch/arm/boot/dts/sun4i-a10.dtsi
@@ -574,6 +574,18 @@
status = disabled;
};
+ usb_otg: usb@01c13000 {
+ compatible = allwinner,sun4i-a10-musb;
+ reg = 0x01c13000 0x0400;
+ clocks = ahb_gates 0;
+ interrupts = 38;
+ interrupt-names = mc;
+ phys = usbphy 0;
+ phy-names = usb;
+ syscons = syscon;
+ status = disabled;
+ };
+
usbphy: phy@01c13400 {
#phy-cells = 1;
compatible = allwinner,sun4i-a10-usb-phy;
diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig
index 8180a3a..fab8e9a 100644
--- a/drivers/usb/musb/Kconfig
+++ b/drivers/usb/musb/Kconfig
@@ -65,6 +65,7 @@ comment Platform Glue Layer
config USB_MUSB_SUNXI
tristate Allwinner (sunxi)
depends on ARCH_SUNXI
+ depends on NOP_USB_XCEIV
select GENERIC_PHY
config USB_MUSB_DAVINCI
--
2.3.1
--
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 04/15] musb: Make busctl_offset an io-op rather then a define
The Allwinner (sunxi) implementation of the musb has its busctl registers
indexed by the MUSB_INDEX register rather then in a flat address space.
This commit turns MUSB_BUSCTL_OFFSET from a macro into an io-op which can
be overridden from the platform ops.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
drivers/usb/musb/musb_core.c | 34 +++-
drivers/usb/musb/musb_core.h | 5 +++-
drivers/usb/musb/musb_host.c | 12 -
drivers/usb/musb/musb_io.h | 2 ++
drivers/usb/musb/musb_regs.h | 63
5 files changed, 68 insertions(+), 48 deletions(-)
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 2c43b59..b71d310 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -250,6 +250,11 @@ static u32 musb_indexed_ep_offset(u8 epnum, u16 offset)
return 0x10 + offset;
}
+static u32 musb_default_busctl_offset(u8 epnum, u16 offset)
+{
+ return 0x80 + (0x08 * epnum) + offset;
+}
+
static u8 musb_default_readb(const void __iomem *addr, unsigned offset)
{
return __raw_readb(addr + offset);
@@ -2039,6 +2044,11 @@ musb_init_controller(struct device *dev, int nIrq, void
__iomem *ctrl)
else
musb-io.fifo_offset = musb_default_fifo_offset;
+ if (musb-ops-busctl_offset)
+ musb-io.busctl_offset = musb-ops-busctl_offset;
+ else
+ musb-io.busctl_offset = musb_default_busctl_offset;
+
if (musb-ops-readb)
musb_readb = musb-ops-readb;
if (musb-ops-writeb)
@@ -2312,18 +2322,18 @@ static void musb_save_context(struct musb *musb)
musb_readb(epio, MUSB_RXINTERVAL);
musb-context.index_regs[i].txfunaddr =
- musb_read_txfunaddr(musb_base, i);
+ musb_read_txfunaddr(musb, i);
musb-context.index_regs[i].txhubaddr =
- musb_read_txhubaddr(musb_base, i);
+ musb_read_txhubaddr(musb, i);
musb-context.index_regs[i].txhubport =
- musb_read_txhubport(musb_base, i);
+ musb_read_txhubport(musb, i);
musb-context.index_regs[i].rxfunaddr =
- musb_read_rxfunaddr(musb_base, i);
+ musb_read_rxfunaddr(musb, i);
musb-context.index_regs[i].rxhubaddr =
- musb_read_rxhubaddr(musb_base, i);
+ musb_read_rxhubaddr(musb, i);
musb-context.index_regs[i].rxhubport =
- musb_read_rxhubport(musb_base, i);
+ musb_read_rxhubport(musb, i);
}
}
@@ -2391,18 +2401,18 @@ static void musb_restore_context(struct musb *musb)
musb_writeb(epio, MUSB_RXINTERVAL,
musb-context.index_regs[i].rxinterval);
- musb_write_txfunaddr(musb_base, i,
+ musb_write_txfunaddr(musb, i,
musb-context.index_regs[i].txfunaddr);
- musb_write_txhubaddr(musb_base, i,
+ musb_write_txhubaddr(musb, i,
musb-context.index_regs[i].txhubaddr);
- musb_write_txhubport(musb_base, i,
+ musb_write_txhubport(musb, i,
musb-context.index_regs[i].txhubport);
- musb_write_rxfunaddr(musb_base, i,
+ musb_write_rxfunaddr(musb, i,
musb-context.index_regs[i].rxfunaddr);
- musb_write_rxhubaddr(musb_base, i,
+ musb_write_rxhubaddr(musb, i,
musb-context.index_regs[i].rxhubaddr);
- musb_write_rxhubport(musb_base, i,
+ musb_write_rxhubport(musb, i,
musb-context.index_regs[i].rxhubport);
}
musb_writeb(musb_base, MUSB_INDEX, musb-context.index);
diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
index a31d709..ba8dd78 100644
--- a/drivers/usb/musb/musb_core.h
+++ b/drivers/usb/musb/musb_core.h
@@ -67,7 +67,6 @@ struct musb_ep;
#include musb_dma.h
#include musb_io.h
-#include musb_regs.h
#include musb_gadget.h
#include linux/usb/hcd.h
@@ -186,6 +185,7 @@ struct musb_platform_ops {
void(*ep_select)(void __iomem *mbase, u8 epnum);
u16 fifo_mode;
u32 (*fifo_offset)(u8 epnum);
+ u32 (*busctl_offset)(u8 epnum, u16 offset);
u8 (*readb)(const void __iomem *addr, unsigned offset);
void(*writeb)(void __iomem *addr, unsigned offset, u8 data);
u16 (*readw)(const void __iomem *addr, unsigned offset);
@@ -435,6 +435,9 @@ struct musb {
#endif
};
+/* This must be included after struct musb is defined */
+#include musb_regs.h
+
static inline struct musb *gadget_to_musb(struct
[linux-sunxi] [PATCH 03/15] musb: Make musb_write_rxfun* and musb_write_rxhub* work like their tx versions
For some reason the musb_write_rxfun* and musb_write_rxhub* functions had
a different function prototype and some extra magic needed on the caller side
compared to their tx counterparts, this commit makes them work the same as
their tx counterparts.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
drivers/usb/musb/musb_core.c | 11 +++
drivers/usb/musb/musb_core.h | 2 --
drivers/usb/musb/musb_host.c | 12 ++--
drivers/usb/musb/musb_regs.h | 31 ---
4 files changed, 21 insertions(+), 35 deletions(-)
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index e6f4cbf..2c43b59 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -1546,7 +1546,6 @@ static int musb_core_init(u16 musb_type, struct musb
*musb)
#endif
hw_ep-regs = musb-io.ep_offset(i, 0) + mbase;
- hw_ep-target_regs = musb_read_target_reg_base(i, mbase);
hw_ep-rx_reinit = 1;
hw_ep-tx_reinit = 1;
@@ -2332,7 +2331,6 @@ static void musb_restore_context(struct musb *musb)
{
int i;
void __iomem *musb_base = musb-mregs;
- void __iomem *ep_target_regs;
void __iomem *epio;
u8 power;
@@ -2400,14 +2398,11 @@ static void musb_restore_context(struct musb *musb)
musb_write_txhubport(musb_base, i,
musb-context.index_regs[i].txhubport);
- ep_target_regs =
- musb_read_target_reg_base(i, musb_base);
-
- musb_write_rxfunaddr(ep_target_regs,
+ musb_write_rxfunaddr(musb_base, i,
musb-context.index_regs[i].rxfunaddr);
- musb_write_rxhubaddr(ep_target_regs,
+ musb_write_rxhubaddr(musb_base, i,
musb-context.index_regs[i].rxhubaddr);
- musb_write_rxhubport(ep_target_regs,
+ musb_write_rxhubport(musb_base, i,
musb-context.index_regs[i].rxhubport);
}
musb_writeb(musb_base, MUSB_INDEX, musb-context.index);
diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
index 5e65958..a31d709 100644
--- a/drivers/usb/musb/musb_core.h
+++ b/drivers/usb/musb/musb_core.h
@@ -240,8 +240,6 @@ struct musb_hw_ep {
void __iomem*fifo_sync_va;
#endif
- void __iomem*target_regs;
-
/* currently scheduled peripheral endpoint */
struct musb_qh *in_qh;
struct musb_qh *out_qh;
diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c
index 883a9ad..77006ee 100644
--- a/drivers/usb/musb/musb_host.c
+++ b/drivers/usb/musb/musb_host.c
@@ -555,8 +555,9 @@ musb_host_packet_rx(struct musb *musb, struct urb *urb, u8
epnum, u8 iso_err)
* the busy/not-empty tests are basically paranoia.
*/
static void
-musb_rx_reinit(struct musb *musb, struct musb_qh *qh, struct musb_hw_ep *ep)
+musb_rx_reinit(struct musb *musb, struct musb_qh *qh, u8 epnum)
{
+ struct musb_hw_ep *ep = musb-endpoints + epnum;
u16 csr;
/* NOTE: we know the rx fifo reinit never triggers for ep0.
@@ -594,10 +595,9 @@ musb_rx_reinit(struct musb *musb, struct musb_qh *qh,
struct musb_hw_ep *ep)
/* target addr and (for multipoint) hub addr/port */
if (musb-is_multipoint) {
- musb_write_rxfunaddr(ep-target_regs, qh-addr_reg);
- musb_write_rxhubaddr(ep-target_regs, qh-h_addr_reg);
- musb_write_rxhubport(ep-target_regs, qh-h_port_reg);
-
+ musb_write_rxfunaddr(musb-mregs, epnum, qh-addr_reg);
+ musb_write_rxhubaddr(musb-mregs, epnum, qh-h_addr_reg);
+ musb_write_rxhubport(musb-mregs, epnum, qh-h_port_reg);
} else
musb_writeb(musb-mregs, MUSB_FADDR, qh-addr_reg);
@@ -875,7 +875,7 @@ finish:
u16 csr;
if (hw_ep-rx_reinit) {
- musb_rx_reinit(musb, qh, hw_ep);
+ musb_rx_reinit(musb, qh, epnum);
/* init new state: toggle and NYET, maybe DMA later */
if (usb_gettoggle(urb-dev, qh-epnum, 0))
diff --git a/drivers/usb/musb/musb_regs.h b/drivers/usb/musb/musb_regs.h
index 11f0be0..edfc730 100644
--- a/drivers/usb/musb/musb_regs.h
+++ b/drivers/usb/musb/musb_regs.h
@@ -364,27 +364,25 @@ static inline u16 musb_read_hwvers(void __iomem *mbase)
return musb_readw(mbase, MUSB_HWVERS);
}
-static inline void __iomem *musb_read_target_reg_base(u8 i, void __iomem
*mbase)
-{
- return (MUSB_BUSCTL_OFFSET(i, 0) + mbase);
-}
-
-static inline void musb_write_rxfunaddr(void __iomem *ep_target_regs,
+static inline void musb_write_rxfunaddr(void __iomem *mbase, u8 epnum,
u8 qh_addr_reg)
{
- musb_writeb(ep_target_regs, MUSB_RXFUNCADDR, qh_addr_reg);
+
[linux-sunxi] [PATCH 14/15] ARM: dts: sun7i: Enable USB DRC on Cubietruck
From: Roman Byshko rbys...@gmail.com
Enable the otg/drc usb controller on the cubietruck.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
arch/arm/boot/dts/sun7i-a20-cubietruck.dts | 24
1 file changed, 24 insertions(+)
diff --git a/arch/arm/boot/dts/sun7i-a20-cubietruck.dts
b/arch/arm/boot/dts/sun7i-a20-cubietruck.dts
index 8111b0c..ac8ff33 100644
--- a/arch/arm/boot/dts/sun7i-a20-cubietruck.dts
+++ b/arch/arm/boot/dts/sun7i-a20-cubietruck.dts
@@ -227,6 +227,20 @@
allwinner,drive = SUN4I_PINCTRL_10_MA;
allwinner,pull = SUN4I_PINCTRL_NO_PULL;
};
+
+ usb0_id_detect_pin: usb0_id_detect_pin@0 {
+ allwinner,pins = PH19;
+ allwinner,function = gpio_in;
+ allwinner,drive = SUN4I_PINCTRL_10_MA;
+ allwinner,pull = SUN4I_PINCTRL_NO_PULL;
+ };
+
+ usb0_vbus_detect_pin: usb0_vbus_detect_pin@0 {
+ allwinner,pins = PH22;
+ allwinner,function = gpio_in;
+ allwinner,drive = SUN4I_PINCTRL_10_MA;
+ allwinner,pull = SUN4I_PINCTRL_NO_PULL;
+ };
};
pwm {
@@ -288,6 +302,16 @@
status = okay;
};
+usb_otg {
+ pinctrl-names = default;
+ pinctrl-0 = usb0_id_detect_pin
+ usb0_vbus_detect_pin;
+ dr_mode = otg;
+ id_det-gpios = pio 7 19 GPIO_ACTIVE_HIGH; /* PH19 */
+ vbus_det-gpios = pio 7 22 GPIO_ACTIVE_HIGH; /* PH22 */
+ status = okay;
+};
+
usbphy {
usb0_vbus-supply = reg_usb0_vbus;
usb1_vbus-supply = reg_usb1_vbus;
--
2.3.1
--
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 15/15] ARM: dts: sun7i: Enable USB DRC on A20-OLinuxIno-Lime
Enable the otg/drc usb controller on the A20-OLinuxIno-Lime.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
arch/arm/boot/dts/sun7i-a20-olinuxino-lime.dts | 29 ++
1 file changed, 29 insertions(+)
diff --git a/arch/arm/boot/dts/sun7i-a20-olinuxino-lime.dts
b/arch/arm/boot/dts/sun7i-a20-olinuxino-lime.dts
index 68efd2f..b3fda82 100644
--- a/arch/arm/boot/dts/sun7i-a20-olinuxino-lime.dts
+++ b/arch/arm/boot/dts/sun7i-a20-olinuxino-lime.dts
@@ -146,6 +146,20 @@
allwinner,drive = SUN4I_PINCTRL_20_MA;
allwinner,pull = SUN4I_PINCTRL_NO_PULL;
};
+
+ usb0_id_detect_pin: usb0_id_detect_pin@0 {
+ allwinner,pins = PH4;
+ allwinner,function = gpio_in;
+ allwinner,drive = SUN4I_PINCTRL_10_MA;
+ allwinner,pull = SUN4I_PINCTRL_PULL_UP;
+ };
+
+ usb0_vbus_detect_pin: usb0_vbus_detect_pin@0 {
+ allwinner,pins = PH5;
+ allwinner,function = gpio_in;
+ allwinner,drive = SUN4I_PINCTRL_10_MA;
+ allwinner,pull = SUN4I_PINCTRL_PULL_DOWN;
+ };
};
reg_ahci_5v {
@@ -154,6 +168,10 @@
status = okay;
};
+reg_usb0_vbus {
+ status = okay;
+};
+
reg_usb1_vbus {
status = okay;
};
@@ -168,7 +186,18 @@
status = okay;
};
+usb_otg {
+ pinctrl-names = default;
+ pinctrl-0 = usb0_id_detect_pin
+usb0_vbus_detect_pin;
+ id_det-gpio = pio 7 4 GPIO_ACTIVE_HIGH; /* PH4 */
+ vbus_det-gpio = pio 7 5 GPIO_ACTIVE_HIGH; /* PH5 */
+ dr_mode = otg;
+ status = okay;
+};
+
usbphy {
+ usb0_vbus-supply = reg_usb0_vbus;
usb1_vbus-supply = reg_usb1_vbus;
usb2_vbus-supply = reg_usb2_vbus;
status = okay;
--
2.3.1
--
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 07/15] musb: Add support for the Allwinner sunxi musb controller
This is based on initial code to get the Allwinner sunxi musb controller
supported by Chen-Yu Tsai and Roman Byshko.
This adds support for the Allwinner sunxi musb controller in both host only
and otg mode. Peripheral only mode is not supported, as no boards use that.
This has been tested on a cubietruck (A20 SoC) and an UTOO P66 tablet
(A13 SoC) with a variety of devices in host mode and with the g_serial gadget
driver in peripheral mode, plugging otg / host cables in/out a lot of times
in all possible imaginable plug orders.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
.../bindings/usb/allwinner,sun4i-a10-musb.txt | 27 +
drivers/usb/musb/Kconfig | 9 +-
drivers/usb/musb/Makefile | 1 +
drivers/usb/musb/musb_core.h | 1 +
drivers/usb/musb/musb_gadget.c | 6 +
drivers/usb/musb/musb_virthub.c| 6 +
drivers/usb/musb/sunxi.c | 788 +
7 files changed, 837 insertions(+), 1 deletion(-)
create mode 100644
Documentation/devicetree/bindings/usb/allwinner,sun4i-a10-musb.txt
create mode 100644 drivers/usb/musb/sunxi.c
diff --git a/Documentation/devicetree/bindings/usb/allwinner,sun4i-a10-musb.txt
b/Documentation/devicetree/bindings/usb/allwinner,sun4i-a10-musb.txt
new file mode 100644
index 000..22b6887
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/allwinner,sun4i-a10-musb.txt
@@ -0,0 +1,27 @@
+Allwinner sun4i A10 musb DRC/OTG controller
+---
+
+Required properties:
+ - compatible : allwinner,sun4i-a10-musb
+ - reg : mmio address range of the musb controller
+ - clocks : clock specifier for the musb controller ahb gate clock
+ - interrupts : interrupt to which the musb controller is connected
+ - interrupt-names : must be mc
+ - phys: phy specifier for the otg phy
+ - phy-names : must be usb
+ - syscons : syscon specifier
+ - dr_mode : Dual-Role mode must be host or otg
+
+Example:
+
+ usb_otg: usb@01c13000 {
+ compatible = allwinner,sun4i-a10-musb;
+ reg = 0x01c13000 0x0400;
+ clocks = ahb_gates 0;
+ interrupts = 38;
+ interrupt-names = mc;
+ phys = usbphy 0;
+ phy-names = usb;
+ syscons = syscon;
+ status = disabled;
+ };
diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig
index 14e1628..8180a3a 100644
--- a/drivers/usb/musb/Kconfig
+++ b/drivers/usb/musb/Kconfig
@@ -5,7 +5,7 @@
# (M)HDRC = (Multipoint) Highspeed Dual-Role Controller
config USB_MUSB_HDRC
- tristate 'Inventra Highspeed Dual Role Controller (TI, ADI, ...)'
+ tristate 'Inventra Highspeed Dual Role Controller (TI, ADI, AW, ...)'
depends on (USB || USB_GADGET)
help
Say Y here if your system has a dual role high speed USB
@@ -20,6 +20,8 @@ config USB_MUSB_HDRC
Analog Devices parts using this IP include Blackfin BF54x,
BF525 and BF527.
+ Allwinner SoCs using this IP include A10, A13, A20, ...
+
If you do not know what this is, please say N.
To compile this driver as a module, choose M here; the
@@ -60,6 +62,11 @@ endchoice
comment Platform Glue Layer
+config USB_MUSB_SUNXI
+ tristate Allwinner (sunxi)
+ depends on ARCH_SUNXI
+ select GENERIC_PHY
+
config USB_MUSB_DAVINCI
tristate DaVinci
depends on ARCH_DAVINCI_DMx
diff --git a/drivers/usb/musb/Makefile b/drivers/usb/musb/Makefile
index ba49501..f95befe 100644
--- a/drivers/usb/musb/Makefile
+++ b/drivers/usb/musb/Makefile
@@ -20,6 +20,7 @@ obj-$(CONFIG_USB_MUSB_DA8XX) += da8xx.o
obj-$(CONFIG_USB_MUSB_BLACKFIN)+= blackfin.o
obj-$(CONFIG_USB_MUSB_UX500) += ux500.o
obj-$(CONFIG_USB_MUSB_JZ4740) += jz4740.o
+obj-$(CONFIG_USB_MUSB_SUNXI) += sunxi.o
obj-$(CONFIG_USB_MUSB_AM335X_CHILD)+= musb_am335x.o
diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
index ba8dd78..444b936 100644
--- a/drivers/usb/musb/musb_core.h
+++ b/drivers/usb/musb/musb_core.h
@@ -166,6 +166,7 @@ struct musb_io;
*/
struct musb_platform_ops {
+#define MUSB_SUN4I BIT(7)
#define MUSB_DMA_UX500 BIT(6)
#define MUSB_DMA_CPPI41BIT(5)
#define MUSB_DMA_CPPI BIT(4)
diff --git a/drivers/usb/musb/musb_gadget.c b/drivers/usb/musb/musb_gadget.c
index b2d9040..7d13eb9 100644
--- a/drivers/usb/musb/musb_gadget.c
+++ b/drivers/usb/musb/musb_gadget.c
@@ -2041,6 +2041,12 @@ void musb_g_disconnect(struct musb *musb)
spin_lock(musb-lock);
}
+ /* On sunxi ep0 FADDR must be 0 when (re)entering peripheral mode */
+ if (musb-io.quirks MUSB_SUN4I) {
+
[linux-sunxi] [PATCH 13/15] ARM: dts: sun5i: Enable USB DRC on UTOO P66
Enable the OTG controller on the UTOO P66 tablet.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
arch/arm/boot/dts/sun5i-a13-utoo-p66.dts | 23 +++
1 file changed, 23 insertions(+)
diff --git a/arch/arm/boot/dts/sun5i-a13-utoo-p66.dts
b/arch/arm/boot/dts/sun5i-a13-utoo-p66.dts
index d1d4d30..8b44874 100644
--- a/arch/arm/boot/dts/sun5i-a13-utoo-p66.dts
+++ b/arch/arm/boot/dts/sun5i-a13-utoo-p66.dts
@@ -160,6 +160,20 @@
allwinner,pull = SUN4I_PINCTRL_PULL_UP;
};
+ usb0_vbus_detect_pin: usb0_vbus_detect_pin@0 {
+ allwinner,pins = PG1;
+ allwinner,function = gpio_in;
+ allwinner,drive = SUN4I_PINCTRL_10_MA;
+ allwinner,pull = SUN4I_PINCTRL_PULL_DOWN;
+ };
+
+ usb0_id_detect_pin: usb0_id_detect_pin@0 {
+ allwinner,pins = PG2;
+ allwinner,function = gpio_in;
+ allwinner,drive = SUN4I_PINCTRL_10_MA;
+ allwinner,pull = SUN4I_PINCTRL_PULL_UP;
+ };
+
i2c_lcd_pins: i2c_lcd_pin@0 {
allwinner,pins = PG10, PG12;
allwinner,function = gpio_out;
@@ -218,6 +232,15 @@
status = okay;
};
+usb_otg {
+ pinctrl-names = default;
+ pinctrl-0 = usb0_id_detect_pin, usb0_vbus_detect_pin;
+ id_det-gpio = pio 6 2 GPIO_ACTIVE_HIGH; /* PG2 */
+ vbus_det-gpio = pio 6 1 GPIO_ACTIVE_HIGH; /* PG1 */
+ dr_mode = otg;
+ status = okay;
+};
+
usbphy {
usb0_vbus-supply = reg_usb0_vbus;
usb1_vbus-supply = reg_ldo3;
--
2.3.1
--
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] [PATCH 09/15] ARM: dts: sun4i: Add USB Dual Role Controller
Hi Hans, On Tue, Mar 10, 2015 at 7:40 AM, Hans de Goede hdego...@redhat.com wrote: Add a node for the otg/drc usb controller to sun4i-a10.dtsi. Signed-off-by: Hans de Goede hdego...@redhat.com --- arch/arm/boot/dts/sun4i-a10.dtsi | 12 drivers/usb/musb/Kconfig | 1 + 2 files changed, 13 insertions(+) diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig index 8180a3a..fab8e9a 100644 --- a/drivers/usb/musb/Kconfig +++ b/drivers/usb/musb/Kconfig @@ -65,6 +65,7 @@ comment Platform Glue Layer config USB_MUSB_SUNXI tristate Allwinner (sunxi) depends on ARCH_SUNXI + depends on NOP_USB_XCEIV Shouldn't this be in a different patch? 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 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 00/15] musb: Add support for the Allwinner sunxi musb controller
Hi Arnd, On Tue, Mar 10, 2015 at 5:44 AM, Arnd Bergmann a...@arndb.de wrote: On Monday 09 March 2015 21:40:13 Hans de Goede wrote: Hi All, This patch set has been a while in the making, so I'm very happy to present the end result here, and I hope everyone likes it. Awesome work! Before talking about merging this there are 2 things which I would like to point out: a) The musb controller in the sunxi SoCs uses some SRAM which needs to be mapped to the musb controller by poking some bits in the SRAM controller, just like the EMAC patches which were send a while back I've chosen to use syscon for this, actually 2 of the patches in this set come directly from the SRAM mapping patchset for the EMAC. I know that Maxime is not 100% in favor of using syscon: http://lists.infradead.org/pipermail/linux-arm-kernel/2015-January/320221.html But I disagree with his arguments for writing a special driver for the SRAM controller: 1) syscon was specifically designed for global system control registers like this and is fine to use as long as there are no conflicts where 1 bit is of interest to multiple drivers, and there is no such conflict here 2) Maxime's other arguments seem to boil down to it would be nice / prettier to have a specific driver for this, without really proving a hard need for such a driver. But writing such a driver is going to be a lot of work, and we've a ton of other work to do, and as said there is no real need for a separate driver, syscon works fine for this. 3) I actually believe that having a specific driver for this is a bad idea, because that means inventing a whole new cross driver API for this, and getting those right is, hard, a lot of work, and even then one is still likely to get it wrong. We can avoid all this by going with the proven syscon solution. Maxime, can we please have your ack for moving forward with this using syscon? (see above for my arguments why) I'd like to understand here why we can't use the existing SRAM DT binding instead of the syscon binding. I believe you are talking about mmio-sram? The syscon here represents a switch, to toggle whether a block of SRAM is mapped into the CPU memory space, or to a specific devices private address space. It is not the actual SRAM. The SRAM DT binding is orthogonal to this, if not irrelevant when the block is mapped privately, as it is no longer visible from the DT's PoV. Coincidentally, on the A23 this is no longer needed. The SRAM for the FIFO is wholly owned by MUSB and not available to the CPU. 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 0/3] touchscreen: sun4i-ts: A10 (sun4i) has a different temperature curve
Hi, On 08-03-15 22:11, Dmitry Torokhov wrote: Hi Hans, On Sun, Mar 08, 2015 at 09:53:39PM +0100, Hans de Goede wrote: Hi Dmitry, Maxime, et al. Here is a patch-set for the sun4i-ts driver temperature sensor support, it consists of 2 fixes: 1) Use a better temperature curve for A10 SoCs to avoid reporting a way to high temperature. 2) Start with reporting an estimated temperature of 40 degrees rather then returning -EAGAIN until we get the first temperature ready interrupt to avoid the kernel tempzone core logging errors because of our -EAGAIN return. No, I think we better teach thermal core not to complain about -EAGAINs. I was wondering if that would not be a better fix myself, so ack. I'll go do a patch for that and submit it to the thermalzone maintainer. Regards, Hans -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: [U-Boot] Basic A33 support including dram init available in my personal repo
Hello, It's sensible work by Allwinner to release the dram code under GPLv2. Now, we can have mainline u-boot support for A33 soon. Hans, Yes, I've very basic A33 dts created based on A23, still lot to do. I'll send the u-boot patches soon. so that, you all can review it. On Sun, Mar 8, 2015 at 5:33 AM, Siarhei Siamashka siarhei.siamas...@gmail.com wrote: On Sat, 07 Mar 2015 20:06:27 +0100 Hans de Goede hdego...@redhat.com wrote: Hi, On 02-03-15 11:25, Hans de Goede wrote: Hi, On 01-03-15 19:42, Vishnu Patekar wrote: Allwinner A33 tablets comes with the libdram binary, fortunately I've found the libdram code at https://github.com/realthunder/a33_bootloader/tree/master/basic_loader/bsp/bsp_for_a67. Ah, that is both good and bad... I've integrated it with mainline u-boot, still lot to do to post it to upstream Integrated sounds as if you've copied pieces of code from the bsp code you've found into mainline u-boot. That is a big no no (this the bad part). AFAIK the bsp code does not come with a GPL license header, and Allwinner does not want to release these bits under the GPL for whatever reasons, a lot can be said about this, but in the end currently the bsp code is not GPL licensed, so we cannot use it / copy from it. There can be no discussion on this, when you're submitting this upstream you must not have any literal copied code in the patch you're sending upstream. You can use non copyrightable information from the bsp sources like register names and the initialization algorithm (IANAL), but you must 100% write your own code! Ok, so something (to me) quite unexpected has happened and Allwinner has just released what seems to be ALL there boot0 code under the GPL, it can found here: https://github.com/allwinner-zh/bootloader/tree/master/basic_loader/boot0 https://github.com/allwinner-zh/bootloader/tree/master/basic_loader/bsp Specifically interesting for the discussion at hand is: https://github.com/allwinner-zh/bootloader/blob/master/basic_loader/bsp/bsp_for_a33/init_dram/mctl_hal.c Which caries a GPL header now. This completely changes my story above, whatever you have (or had, sorry) was fine. It should still be cleaned up a bit, but all my worries about copy and pasting non GPL code are gone now. It is strange that this has caught you by surprise, because you had been informed about what is going on: http://lists.denx.de/pipermail/u-boot/2015-March/207174.html Basically, we need to thank David and Vishnu for negotiating this with Allwinner (and this communication has been going on for some time already), which resulted in a reasonable solution in the end. You have also played your role well. My intervention was only needed to ensure that Vishnu does not get discouraged by your response, which originally sounded like only a single less than perfect solution was possible :-) Yes, we are kinda lucky to have discovered this apparently leaked A33 dram code. I don't approve the actions of whoever is responsible for this leak. But we ended up in a situation where the bad guys (competitors?) have already got access to the code to learn all the secrets, while the good guys (us) could not use the code because of the missing license notices. And Allwinner just made a rational decision how to deal with it (in the same way as this happened with the previous code leaks). Having also the A23, A83T and A80 dram code open sourced under the GPL license is very much appreciated. It means that U-Boot can get full support for A83T and A80 too. Special thanks to Vishu for not trying to hide the origin of the A33 dram code. I particularly like full transparency and honesty in handling this case. I'm still not completely happy about the presence of magic numbers all over the place (for example, Rockchip sources for very similar dram controllers have proper named identifiers for the hardware register bitfields) and other code quality problems. In a prefect world, we would also get full documentation for the dram controllers and the errata lists. But even the current source code is enough to move from the dead point. -- Best regards, Siarhei Siamashka -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: [U-Boot] Basic A33 support including dram init available in my personal repo
Yes, except couple of additional clocks for A33, others seem to be same as A23 including PIO. I think, it's possible to overlay over A23. On Mon, Mar 9, 2015 at 2:35 PM, Hans de Goede hdego...@redhat.com wrote: Hi, On 09-03-15 10:04, Chen-Yu Tsai wrote: Hi, On Mon, Mar 9, 2015 at 4:39 PM, Vishnu Patekar vishnupatekar0...@gmail.com wrote: Hello, It's sensible work by Allwinner to release the dram code under GPLv2. Now, we can have mainline u-boot support for A33 soon. Hans, Yes, I've very basic A33 dts created based on A23, still lot to do. About the dts, so far the memory maps look the same. I haven't checked the clocks or interrupts, but I bet they are the same as well. Could we use an overlay over A23 with just the different pieces overriden? Though they're not the same piece of silicon, they are damn close. Maybe even the PIO is the same. +1, I wanted to do / suggest the same myself. 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: Mainline work status
Hi everyone, On Wed, Dec 24, 2014 at 11:29 PM, wens Tsai wens...@gmail.com wrote: Hi everyone, As some of you might have noticed, I've sent out patches for A80 MMC and AXP20x. In addition, I've picked up Boris' AXP221 patches to resend after the AXP patches are merged. The following is a list of things I'm working on or waiting to submit: Here's an update: - AXP20x (PEK and docs) series, originally by Carlo, posted v8 v10 submitted, waiting for acks (by who I'm not sure...) - AXP20x regulator driver cleanup, finished and tested Merged - AXP221 support, originally by Boris, finished and tested Can be found at: https://github.com/wens/linux/tree/axp221-v5 I will submit it later today (hopefully). This depends on the AXP20x bindings though. * Also enables WiFi on the Hummingbird A31 Apart from the MMC resets I keep getting, looks fine. - sunxi (sun[457]i) cpufreq support, finished and testing (CB/CB2 tested) * Only added support for the boards I own. It's just a matter of adding the regulator nodes with the proper constraints Merged. - sun6i cpufreq support, WiP - sun8i cpufreq support, minimal work only No progress on these two. - sun9i mmc support, posted v2 Merged. - sun9i usb support, v3 WiP Merged, except for the phy driver. Maintainer hasn't responded yet. - RSB driver, not working yet Finished and submitted, though it seems it will be rejected. See: http://www.spinics.net/lists/linux-i2c/msg18838.html Will probably make it a custom bus with regmap support, like SPMI. I've also ordered A31s and A33 devboards from Sinlinx, as well as an A33 tablet. Regards ChenYu All the above, excluding RSB, can be found in my repository: https://github.com/wens/linux Each topic is a separate branch, except for the AXP branches, which have dependencies. Testing and feedback is more than welcome. Regards 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 1/3] touchscreen: sun4i-ts: A10 (sun4i) has a different temperature curve
Hi,
On 08-03-15 22:13, Dmitry Torokhov wrote:
On Sun, Mar 08, 2015 at 09:53:40PM +0100, Hans de Goede wrote:
Testing has revealed that the temperature in the rtp controller of the A10
(sun4i) SoC has a different curve then on the A13 (sun5i) and later models.
Add a new sun5i-a13-ts compatible to differentiate the newer models and
set the curve based on the compatible string.
The new curve is still not ideal on all A10-s, that seems to have to
do with there being a large spread between different A10-s out there,
the new curve us based on callibration results on 4 completely different
models:
raw min raw max temp min temp max stepsize offset
Tong Zhang's hackberry2402268045.0 80.00.125 -255.3
Hansg's Cubieboard2207230036.0 45.00.096 -175.8
Olliver's lime 1 (*): 2258253748.3 87.10.139 -265.7
Olliver's lime 2 (*): 248646.7 91.70.170 -331.0
*) from: http://linux-sunxi.org/Temperature_Calibration
Average all 4: 0.133 -257.0
Average without outliers (middle 2): 0.132 -261.0
Since it is better to slightly overreport the temperature this patch uses
the average of all 4 as curve.
This fixes the temperature reported on the A10 being much higher then
expected.
Cc: Tong Zhang lovewill...@gmail.com
Cc: Olliver Schinagl o.schin...@ultimaker.com
Reported-by: Tong Zhang lovewill...@gmail.com
Signed-off-by: Hans de Goede hdego...@redhat.com
Applied, thank you.
Thanks.
Note I've just found out that I've made a math error, the offset as I've used
it is
in degrees, but the actual code applies the offset before multiplying by
stepsize :|
Given that this is rather backwards (every math course ever thought applies
the multiplication before the offset for linear functions. I'll do a follow up
patch fixing the code to do the logical thing, and adjusting the offset for
the other models accordingly.
Regards,
Hans
---
.../devicetree/bindings/input/touchscreen/sun4i.txt | 3 ++-
drivers/input/touchscreen/sun4i-ts.c | 16 +---
2 files changed, 15 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/input/touchscreen/sun4i.txt
b/Documentation/devicetree/bindings/input/touchscreen/sun4i.txt
index 42d..d59d252 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/sun4i.txt
+++ b/Documentation/devicetree/bindings/input/touchscreen/sun4i.txt
@@ -2,7 +2,8 @@ sun4i resistive touchscreen controller
--
Required properties:
- - compatible: allwinner,sun4i-a10-ts or allwinner,sun6i-a31-ts
+ - compatible: allwinner,sun4i-a10-ts, allwinner,sun5i-a13-ts or
+ allwinner,sun6i-a31-ts
- reg: mmio address range of the chip
- interrupts: interrupt to which the chip is connected
- #thermal-sensor-cells: shall be 0
diff --git a/drivers/input/touchscreen/sun4i-ts.c
b/drivers/input/touchscreen/sun4i-ts.c
index b93a28b..66ccd5a 100644
--- a/drivers/input/touchscreen/sun4i-ts.c
+++ b/drivers/input/touchscreen/sun4i-ts.c
@@ -258,6 +258,15 @@ static int sun4i_ts_probe(struct platform_device *pdev)
/* Allwinner SDK has temperature = -271 + (value / 6) (C) */
ts-temp_offset = 1626;
ts-temp_step = 167;
+ } else if (of_device_is_compatible(np, allwinner,sun4i-a10-ts)) {
+ /*
+* The A10 temperature sensor has quite a wide spread, these
+* parameters are based on the averaging of the calibration
+* results of 4 completely different boards, with a spread of
+* temp_step from 96 - 170 and temp_offset from 1758 - 3310.
+*/
+ ts-temp_offset = 2570;
+ ts-temp_step = 133;
} else {
/*
* The user manuals do not contain the formula for calculating
@@ -330,10 +339,10 @@ static int sun4i_ts_probe(struct platform_device *pdev)
* finally enable tp mode.
*/
reg = STYLUS_UP_DEBOUN(5) | STYLUS_UP_DEBOUN_EN(1);
- if (of_device_is_compatible(np, allwinner,sun4i-a10-ts))
- reg |= TP_MODE_EN(1);
- else
+ if (of_device_is_compatible(np, allwinner,sun6i-a31-ts))
reg |= SUN6I_TP_MODE_EN(1);
+ else
+ reg |= TP_MODE_EN(1);
writel(reg, ts-base + TP_CTRL1);
/*
@@ -383,6 +392,7 @@ static int sun4i_ts_remove(struct platform_device *pdev)
static const struct of_device_id sun4i_ts_of_match[] = {
{ .compatible = allwinner,sun4i-a10-ts, },
+ { .compatible = allwinner,sun5i-a13-ts, },
{ .compatible = allwinner,sun6i-a31-ts, },
{ /* sentinel */ }
};
--
2.3.1
--
You received this message because you are subscribed to the Google Groups
linux-sunxi group.
To unsubscribe from this group and stop
Re: [linux-sunxi] Re: [U-Boot] Basic A33 support including dram init available in my personal repo
Hi, On Mon, Mar 9, 2015 at 4:39 PM, Vishnu Patekar vishnupatekar0...@gmail.com wrote: Hello, It's sensible work by Allwinner to release the dram code under GPLv2. Now, we can have mainline u-boot support for A33 soon. Hans, Yes, I've very basic A33 dts created based on A23, still lot to do. About the dts, so far the memory maps look the same. I haven't checked the clocks or interrupts, but I bet they are the same as well. Could we use an overlay over A23 with just the different pieces overriden? Though they're not the same piece of silicon, they are damn close. Maybe even the PIO is the same. Maxime, any thoughts? Regards ChenYu I'll send the u-boot patches soon. so that, you all can review it. On Sun, Mar 8, 2015 at 5:33 AM, Siarhei Siamashka siarhei.siamas...@gmail.com wrote: On Sat, 07 Mar 2015 20:06:27 +0100 Hans de Goede hdego...@redhat.com wrote: Hi, On 02-03-15 11:25, Hans de Goede wrote: Hi, On 01-03-15 19:42, Vishnu Patekar wrote: Allwinner A33 tablets comes with the libdram binary, fortunately I've found the libdram code at https://github.com/realthunder/a33_bootloader/tree/master/basic_loader/bsp/bsp_for_a67. Ah, that is both good and bad... I've integrated it with mainline u-boot, still lot to do to post it to upstream Integrated sounds as if you've copied pieces of code from the bsp code you've found into mainline u-boot. That is a big no no (this the bad part). AFAIK the bsp code does not come with a GPL license header, and Allwinner does not want to release these bits under the GPL for whatever reasons, a lot can be said about this, but in the end currently the bsp code is not GPL licensed, so we cannot use it / copy from it. There can be no discussion on this, when you're submitting this upstream you must not have any literal copied code in the patch you're sending upstream. You can use non copyrightable information from the bsp sources like register names and the initialization algorithm (IANAL), but you must 100% write your own code! Ok, so something (to me) quite unexpected has happened and Allwinner has just released what seems to be ALL there boot0 code under the GPL, it can found here: https://github.com/allwinner-zh/bootloader/tree/master/basic_loader/boot0 https://github.com/allwinner-zh/bootloader/tree/master/basic_loader/bsp Specifically interesting for the discussion at hand is: https://github.com/allwinner-zh/bootloader/blob/master/basic_loader/bsp/bsp_for_a33/init_dram/mctl_hal.c Which caries a GPL header now. This completely changes my story above, whatever you have (or had, sorry) was fine. It should still be cleaned up a bit, but all my worries about copy and pasting non GPL code are gone now. It is strange that this has caught you by surprise, because you had been informed about what is going on: http://lists.denx.de/pipermail/u-boot/2015-March/207174.html Basically, we need to thank David and Vishnu for negotiating this with Allwinner (and this communication has been going on for some time already), which resulted in a reasonable solution in the end. You have also played your role well. My intervention was only needed to ensure that Vishnu does not get discouraged by your response, which originally sounded like only a single less than perfect solution was possible :-) Yes, we are kinda lucky to have discovered this apparently leaked A33 dram code. I don't approve the actions of whoever is responsible for this leak. But we ended up in a situation where the bad guys (competitors?) have already got access to the code to learn all the secrets, while the good guys (us) could not use the code because of the missing license notices. And Allwinner just made a rational decision how to deal with it (in the same way as this happened with the previous code leaks). Having also the A23, A83T and A80 dram code open sourced under the GPL license is very much appreciated. It means that U-Boot can get full support for A83T and A80 too. Special thanks to Vishu for not trying to hide the origin of the A33 dram code. I particularly like full transparency and honesty in handling this case. I'm still not completely happy about the presence of magic numbers all over the place (for example, Rockchip sources for very similar dram controllers have proper named identifiers for the hardware register bitfields) and other code quality problems. In a prefect world, we would also get full documentation for the dram controllers and the errata lists. But even the current source code is enough to move from the dead point. -- 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
Re: [linux-sunxi] Re: [U-Boot] Basic A33 support including dram init available in my personal repo
Hi, On 09-03-15 10:04, Chen-Yu Tsai wrote: Hi, On Mon, Mar 9, 2015 at 4:39 PM, Vishnu Patekar vishnupatekar0...@gmail.com wrote: Hello, It's sensible work by Allwinner to release the dram code under GPLv2. Now, we can have mainline u-boot support for A33 soon. Hans, Yes, I've very basic A33 dts created based on A23, still lot to do. About the dts, so far the memory maps look the same. I haven't checked the clocks or interrupts, but I bet they are the same as well. Could we use an overlay over A23 with just the different pieces overriden? Though they're not the same piece of silicon, they are damn close. Maybe even the PIO is the same. +1, I wanted to do / suggest the same myself. Regards, Hans -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Re: Re: [linux-sunxi] how to build an linux image for A31S
If the serial port is usable, maybe you can boot into fel mode by press '2' in serial terminal and then power on the device. On Mon, Mar 9, 2015 at 1:28 PM, Code Kipper codekip...@gmail.com wrote: On 9 March 2015 at 03:56, li lijiamin...@163.com wrote: Hi pere canadell, the device is http://linux-sunxi.org/VidOn_Box, but i can't find the image for it. Best Regards, stone Hi Stone I don't think you'll have any chance of getting anything other than VidOn's firmware onto this device without doing some serious hardware modifications. There is no sdcard to boot from or OTG to get the device into fel mode. I have this hardware and I'm still trying to find a way to get it to boot into fel mode. For now only serial debug is possible. BR, CK -- 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. -- 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: Re: Re: [linux-sunxi] how to build an linux image for A31S
On 9 March 2015 at 07:41, Quink wantl...@gmail.com wrote: If the serial port is usable, maybe you can boot into fel mode by press '2' in serial terminal and then power on the device. I've tried connecting just a USB-A-USB-A to the board to see if it powers up but it didn't and as I'm quite keen to keep this for now as an Android box I didn't investigate any further. I do have a USB-A cable somewhere that just has the data lines connected so I can try with this and the unit's PSU. CK On Mon, Mar 9, 2015 at 1:28 PM, Code Kipper codekip...@gmail.com wrote: On 9 March 2015 at 03:56, li lijiamin...@163.com wrote: Hi pere canadell, the device is http://linux-sunxi.org/VidOn_Box, but i can't find the image for it. Best Regards, stone Hi Stone I don't think you'll have any chance of getting anything other than VidOn's firmware onto this device without doing some serious hardware modifications. There is no sdcard to boot from or OTG to get the device into fel mode. I have this hardware and I'm still trying to find a way to get it to boot into fel mode. For now only serial debug is possible. BR, CK -- 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. -- 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. -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH v2 1/2] ARM: dts: sun7i: Add dts file for Wexler TAB7200
On Sun, Mar 08, 2015 at 02:57:33PM +0300, Aleksei Mamlin wrote: This patch add support for Wexler TAB7200 tablet. The Wexler TAB7200 is a A20 based tablet with 7 inch display(800x480), capacitive touchscreen(5 fingers), 1G RAM, 4G NAND, micro SD card slot, mini HDMI port, 3.5mm audio plug, 1 USB OTG port and 1 USB 2.0 port. Signed-off-by: Aleksei Mamlin mamli...@gmail.com --- Changes since v1: * Split to two patches: The first one adds dts file for Wexler TAB7200. The second one adds vendor-prefix for Wexler. * Remove include dt-bindings/pinctrl/sun4i-a10.h because we don't use the pinctrl header. Applied the two patches, 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] [PATCH] touchscreen: sun4i-ts: Really fix A10 temperature reporting
The commit titled:
touchscreen: sun4i-ts: A10 (sun4i) has a different temperature curve
contains a math error, the offset it uses is in degrees, but the actual code
applies the offset before multiplying by stepsize :|
Given that this is rather backwards (every math course ever thought applies
the multiplication before the offset for linear functions), this commit
fixes things by changing the code applying the offset to do the logical
thing, adjusting the offset for the other models accordingly.
This has been tested on an A10, A13, A20 and A31 to make sure everything really
is correct now.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
Note if possible this commit should be squashed into the original
touchscreen: sun4i-ts: A10 (sun4i) has a different temperature curve
commit as a fixup.
---
drivers/input/touchscreen/sun4i-ts.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/input/touchscreen/sun4i-ts.c
b/drivers/input/touchscreen/sun4i-ts.c
index 66ccd5a..178d2ef 100644
--- a/drivers/input/touchscreen/sun4i-ts.c
+++ b/drivers/input/touchscreen/sun4i-ts.c
@@ -193,7 +193,7 @@ static int sun4i_get_temp(const struct sun4i_ts_data *ts,
long *temp)
if (ts-temp_data == -1)
return -EAGAIN;
- *temp = (ts-temp_data - ts-temp_offset) * ts-temp_step;
+ *temp = ts-temp_data * ts-temp_step - ts-temp_offset;
return 0;
}
@@ -255,17 +255,17 @@ static int sun4i_ts_probe(struct platform_device *pdev)
ts-ignore_fifo_data = true;
ts-temp_data = -1;
if (of_device_is_compatible(np, allwinner,sun6i-a31-ts)) {
- /* Allwinner SDK has temperature = -271 + (value / 6) (C) */
- ts-temp_offset = 1626;
+ /* Allwinner SDK has temperature (C) = (value / 6) - 271 */
+ ts-temp_offset = 271000;
ts-temp_step = 167;
} else if (of_device_is_compatible(np, allwinner,sun4i-a10-ts)) {
/*
* The A10 temperature sensor has quite a wide spread, these
* parameters are based on the averaging of the calibration
* results of 4 completely different boards, with a spread of
-* temp_step from 96 - 170 and temp_offset from 1758 - 3310.
+* temp_step from 0.096 - 0.170 and temp_offset from 176 - 331.
*/
- ts-temp_offset = 2570;
+ ts-temp_offset = 257000;
ts-temp_step = 133;
} else {
/*
@@ -273,13 +273,13 @@ static int sun4i_ts_probe(struct platform_device *pdev)
* the temperature. The formula used here is from the AXP209,
* which is designed by X-Powers, an affiliate of Allwinner:
*
-* temperature = -144.7 + (value * 0.1)
+* temperature (C) = (value * 0.1) - 144.7
*
* Allwinner does not have any documentation whatsoever for
* this hardware. Moreover, it is claimed that the sensor
* is inaccurate and cannot work properly.
*/
- ts-temp_offset = 1447;
+ ts-temp_offset = 144700;
ts-temp_step = 100;
}
--
2.3.1
--
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.
