[linux-sunxi] [PATCH v5 0/3] musb: sunxi: Add support for the Allwinner sunxi musb
Hi Felipe, Here is a patch series with all my oustanding musb-sunxi changes pending for merging into 4.3. This includes the 5th iteration of the patch for adding the basic sunxi-glue, the major change in v5 is that it has been ported to the extcon API changes which are queued up for 4.2 from : http://git.kernel.org/cgit/linux/kernel/git/chanwoo/extcon.git/log/?h=extcon-ne which already merged in GKH's char-misc branch for 4.2, this means that this series now depends on those changes. Besides that I've also squashed in a fix I send out recently which removes the need for the special MUSB_SUN4I flag + core changes checking for that flag which my original version has. Meaning that the changes are nowly soley confined to the addition of drivers/usb/musb/sunxi.c + matching Kconfig / Makefile changes. Other than that this is a resend of some of the other feature addition patches I recently send rebased on top of v5 of the musb sunxi glue. Please merge this series for 4.3. 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] [PATCH v5 3/3] musb: sunxi: Add support for musb controller in A33 SoC
The A33 SoC uses the same musb controller as found on the A31 and later,
but allwinner has removed the configdata register, this commit adds special
handling for this.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
.../devicetree/bindings/usb/allwinner,sun4i-a10-musb.txt | 3 ++-
drivers/usb/musb/sunxi.c | 15 +++
2 files changed, 17 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/usb/allwinner,sun4i-a10-musb.txt
b/Documentation/devicetree/bindings/usb/allwinner,sun4i-a10-musb.txt
index fde180b..862cd7c 100644
--- a/Documentation/devicetree/bindings/usb/allwinner,sun4i-a10-musb.txt
+++ b/Documentation/devicetree/bindings/usb/allwinner,sun4i-a10-musb.txt
@@ -2,7 +2,8 @@ Allwinner sun4i A10 musb DRC/OTG controller
---
Required properties:
- - compatible : allwinner,sun4i-a10-musb or allwinner,sun6i-a31-musb
+ - compatible : allwinner,sun4i-a10-musb, allwinner,sun6i-a31-musb
+ or allwinner,sun8i-a33-musb
- reg : mmio address range of the musb controller
- clocks : clock specifier for the musb controller ahb gate clock
- reset : reset specifier for the ahb reset (A31 and newer only)
diff --git a/drivers/usb/musb/sunxi.c b/drivers/usb/musb/sunxi.c
index 825bc41..0e24292 100644
--- a/drivers/usb/musb/sunxi.c
+++ b/drivers/usb/musb/sunxi.c
@@ -73,6 +73,7 @@
#define SUNXI_MUSB_FL_PHY_ON 4
#define SUNXI_MUSB_FL_HAS_SRAM 5
#define SUNXI_MUSB_FL_HAS_RESET6
+#define SUNXI_MUSB_FL_NO_CONFIGDATA7
/* Our read/write methods need access and do not get passed in a musb ref :| */
struct musb *sunxi_musb;
@@ -370,6 +371,8 @@ static u32 sunxi_musb_busctl_offset(u8 epnum, u16 offset)
static u8 sunxi_musb_readb(const void __iomem *addr, unsigned offset)
{
+ struct sunxi_glue *glue;
+
if (addr == sunxi_musb-mregs) {
/* generic control or fifo control reg access */
switch (offset) {
@@ -392,6 +395,12 @@ static u8 sunxi_musb_readb(const void __iomem *addr,
unsigned offset)
case MUSB_RXFIFOSZ:
return readb(addr + SUNXI_MUSB_RXFIFOSZ);
case MUSB_CONFIGDATA + 0x10: /* See musb_read_configdata() */
+ glue = dev_get_drvdata(sunxi_musb-controller-parent);
+ /* A33 saves a reg, and we get to hardcode this */
+ if (test_bit(SUNXI_MUSB_FL_NO_CONFIGDATA,
+glue-flags))
+ return 0xde;
+
return readb(addr + SUNXI_MUSB_CONFIGDATA);
/* Offset for these is fixed by sunxi_musb_busctl_offset() */
case SUNXI_MUSB_TXFUNCADDR:
@@ -643,6 +652,11 @@ static int sunxi_musb_probe(struct platform_device *pdev)
if (of_device_is_compatible(np, allwinner,sun6i-a31-musb))
set_bit(SUNXI_MUSB_FL_HAS_RESET, glue-flags);
+ if (of_device_is_compatible(np, allwinner,sun8i-a33-musb)) {
+ set_bit(SUNXI_MUSB_FL_HAS_RESET, glue-flags);
+ set_bit(SUNXI_MUSB_FL_NO_CONFIGDATA, glue-flags);
+ }
+
glue-clk = devm_clk_get(pdev-dev, NULL);
if (IS_ERR(glue-clk)) {
dev_err(pdev-dev, Error getting clock: %ld\n,
@@ -723,6 +737,7 @@ static int sunxi_musb_remove(struct platform_device *pdev)
static const struct of_device_id sunxi_musb_match[] = {
{ .compatible = allwinner,sun4i-a10-musb, },
{ .compatible = allwinner,sun6i-a31-musb, },
+ { .compatible = allwinner,sun8i-a33-musb, },
{}
};
--
2.4.3
--
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 v5 1/3] musb: sunxi: 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
---
Changes in v2:
-Move polling of id and vbus-det gpio-s to the phy driver
-Use extcon to get id (USB_HOST mode) status changes from the phy driver
-Stop using syscon, instead use Maxime Ripard's sunxi SRAM controller driver
Changes in v3:
-Check that USB_MUSB_FOO config is compatible with the dr_mode setting from dt
Changes in v4:
-Squash in musb: sunxi: Add pre/post root reset end platform functions patch
-Adjust for sunxi_sram controller driver changes
-Stop musb work from turning vbus off again when in host mode
Changes in v5:
-Squash in musb: sunxi: Remove special MUSB_SUN4I flag patch, as it was
mostly revering changes done by this patch
-Adjust for extcon api changes landing in 4.2
---
.../bindings/usb/allwinner,sun4i-a10-musb.txt | 27 +
drivers/usb/musb/Kconfig | 13 +-
drivers/usb/musb/Makefile | 1 +
drivers/usb/musb/sunxi.c | 703 +
4 files changed, 743 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..9254a6c
--- /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
+ - dr_mode : Dual-Role mode must be host or otg
+ - extcon : extcon specifier for the otg phy
+
+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;
+ extcon = usbphy 0;
+ status = disabled;
+ };
diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig
index 39db8b6..37081ed 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,15 @@ endchoice
comment Platform Glue Layer
+config USB_MUSB_SUNXI
+ tristate Allwinner (sunxi)
+ depends on ARCH_SUNXI
+ depends on NOP_USB_XCEIV
+ depends on PHY_SUN4I_USB
+ depends on EXTCON
+ depends on GENERIC_PHY
+ select SUNXI_SRAM
+
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/sunxi.c b/drivers/usb/musb/sunxi.c
new file mode 100644
index 000..71c1cea
--- /dev/null
+++ b/drivers/usb/musb/sunxi.c
@@ -0,0
[linux-sunxi] [PATCH v5 2/3] musb: sunxi: Add support for musb controller in A31 SoC
The A31 SoC uses the same musb controller as found in earlier SoCs, but it
is hooked up slightly different. Its SRAM is private and no longer controlled
through the SRAM controller, and its reset is controlled via a separate
reset controller. This commit adds support for this setup.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
.../bindings/usb/allwinner,sun4i-a10-musb.txt | 3 +-
drivers/usb/musb/sunxi.c | 50 +++---
2 files changed, 46 insertions(+), 7 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/allwinner,sun4i-a10-musb.txt
b/Documentation/devicetree/bindings/usb/allwinner,sun4i-a10-musb.txt
index 9254a6c..fde180b 100644
--- a/Documentation/devicetree/bindings/usb/allwinner,sun4i-a10-musb.txt
+++ b/Documentation/devicetree/bindings/usb/allwinner,sun4i-a10-musb.txt
@@ -2,9 +2,10 @@ Allwinner sun4i A10 musb DRC/OTG controller
---
Required properties:
- - compatible : allwinner,sun4i-a10-musb
+ - compatible : allwinner,sun4i-a10-musb or allwinner,sun6i-a31-musb
- reg : mmio address range of the musb controller
- clocks : clock specifier for the musb controller ahb gate clock
+ - reset : reset specifier for the ahb reset (A31 and newer only)
- interrupts : interrupt to which the musb controller is connected
- interrupt-names : must be mc
- phys: phy specifier for the otg phy
diff --git a/drivers/usb/musb/sunxi.c b/drivers/usb/musb/sunxi.c
index 71c1cea..825bc41 100644
--- a/drivers/usb/musb/sunxi.c
+++ b/drivers/usb/musb/sunxi.c
@@ -26,6 +26,7 @@
#include linux/of.h
#include linux/phy/phy-sun4i-usb.h
#include linux/platform_device.h
+#include linux/reset.h
#include linux/soc/sunxi/sunxi_sram.h
#include linux/usb/musb.h
#include linux/usb/of.h
@@ -70,6 +71,8 @@
#define SUNXI_MUSB_FL_HOSTMODE_PEND2
#define SUNXI_MUSB_FL_VBUS_ON 3
#define SUNXI_MUSB_FL_PHY_ON 4
+#define SUNXI_MUSB_FL_HAS_SRAM 5
+#define SUNXI_MUSB_FL_HAS_RESET6
/* Our read/write methods need access and do not get passed in a musb ref :| */
struct musb *sunxi_musb;
@@ -78,6 +81,7 @@ struct sunxi_glue {
struct device *dev;
struct platform_device *musb;
struct clk *clk;
+ struct reset_control*rst;
struct phy *phy;
struct platform_device *usb_phy;
struct usb_phy *xceiv;
@@ -229,14 +233,22 @@ static int sunxi_musb_init(struct musb *musb)
musb-phy = glue-phy;
musb-xceiv = glue-xceiv;
- ret = sunxi_sram_claim(musb-controller-parent);
- if (ret)
- return ret;
+ if (test_bit(SUNXI_MUSB_FL_HAS_SRAM, glue-flags)) {
+ ret = sunxi_sram_claim(musb-controller-parent);
+ if (ret)
+ return ret;
+ }
ret = clk_prepare_enable(glue-clk);
if (ret)
goto error_sram_release;
+ if (test_bit(SUNXI_MUSB_FL_HAS_RESET, glue-flags)) {
+ ret = reset_control_deassert(glue-rst);
+ if (ret)
+ goto error_clk_disable;
+ }
+
writeb(SUNXI_MUSB_VEND0_PIO_MODE, musb-mregs + SUNXI_MUSB_VEND0);
/* Register notifier before calling phy_init() */
@@ -244,7 +256,7 @@ static int sunxi_musb_init(struct musb *musb)
ret = extcon_register_notifier(glue-extcon, EXTCON_USB_HOST,
glue-host_nb);
if (ret)
- goto error_clk_disable;
+ goto error_reset_assert;
}
ret = phy_init(glue-phy);
@@ -273,10 +285,14 @@ error_unregister_notifier:
if (musb-port_mode == MUSB_PORT_MODE_DUAL_ROLE)
extcon_unregister_notifier(glue-extcon, EXTCON_USB_HOST,
glue-host_nb);
+error_reset_assert:
+ if (test_bit(SUNXI_MUSB_FL_HAS_RESET, glue-flags))
+ reset_control_assert(glue-rst);
error_clk_disable:
clk_disable_unprepare(glue-clk);
error_sram_release:
- sunxi_sram_release(musb-controller-parent);
+ if (test_bit(SUNXI_MUSB_FL_HAS_SRAM, glue-flags))
+ sunxi_sram_release(musb-controller-parent);
return ret;
}
@@ -296,8 +312,12 @@ static int sunxi_musb_exit(struct musb *musb)
extcon_unregister_notifier(glue-extcon, EXTCON_USB_HOST,
glue-host_nb);
+ if (test_bit(SUNXI_MUSB_FL_HAS_RESET, glue-flags))
+ reset_control_assert(glue-rst);
+
clk_disable_unprepare(glue-clk);
- sunxi_sram_release(musb-controller-parent);
+ if (test_bit(SUNXI_MUSB_FL_HAS_SRAM, glue-flags))
+ sunxi_sram_release(musb-controller-parent);
return 0;
}
@@ -617,6
Re: [linux-sunxi] [PATCH 2/8] mfd: axp20x: Add a cell for the usb power_supply part of the axp20x PMICs
On Wed, Jun 10, 2015 at 09:57:13AM +0200, Hans de Goede wrote:
@@ -368,6 +392,12 @@ static struct mfd_cell axp20x_cells[] = {
.resources = axp20x_pek_resources,
}, {
.name = axp20x-regulator,
+ }, {
+ .name = axp20x-usb-power-supply,
Could we use either vbus-power-supply to match the AXP datasheets,
or otg-power-supply which is slightly more obvious to board owners?
I do not like the vbus name, since it does not indicate which bus
it is, OTOH you are right that is what it is called in the datasheet.
As for using otg, I think that usb is better then.
All in all I believe that the current usb name is best, but if others
disagree I'm open to renaming this.
So anyone else have an opinion on what would be a good name for the
cell and the compatible ?
I usually prefer to use the name mentionned in the datasheet, but if
that doesn't make sense, feel free to use an alternative like this
one.
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 v2 6/6] ARM: sun8i: dts: Add Ippo-q8h v1.2 with A33 and 1024x600 lcd support
Hi, Sorry for the late reply. On Wed, Jun 03, 2015 at 01:12:04PM +0200, Hans de Goede wrote: Hi, On 03-06-15 11:45, Maxime Ripard wrote: On Tue, Jun 02, 2015 at 10:29:09AM +0200, Hans de Goede wrote: Hi, On 02-06-15 10:14, Maxime Ripard wrote: On Sat, May 30, 2015 at 04:55:06PM +0200, Hans de Goede wrote: The Ippo-q8h is a tablet circuit board commonly found in cheap Android tablets. The v1.2 version can be used with either an A23 or A33 SoC. This adds a dts file for the v1.2 board with an A33 SoC and a 1024x600 LCD screen (most of these tablets have a 800x480 screen). I think the difference between the resolution here is more of a case for the DT quirks interface: https://lkml.org/lkml/2015/2/18/258 I would expect the only difference between the 2 dts files to be the node describing the lcd panel, so yes that makes somewhat sense. Do you know if there's some way to autodetect the two board versions (like a board id somewhere in an EEPROM)? No, AFAIK there is no way to tell the difference. There is no eeprom no the board, and we really cannot rely on the nand contents. Ok. If not, then maybe u-boot can simply add that board compatible to the list, and we'll base our logic on that when we'll need it. That means extra logic in u-boot, and on the kernel side, for what benefit exactly? Such logic would make sense if there was one u-boot image which runtime adjusted itself, but that is not an option. For what benefit? One kernel image which runtime adjusts itself. You mean one dtb right, because the kernel itself already runtime adjusts itself. Well, the kernel will runtime adjust the DT, so, both, I'd say? It's especially possible if u-boot's image is not, which seems to be what you're saying. But we will still need different configs in u-boot, and we need to add code + config to u-boot to plug in the extra compatibles to automatically select the right built-in overlays. You're going to have a different config anyway, but yeah, that's true. And we can avoid copy and paste on the dts side by putting all the common stuff in a common file and including that, I believe that that is better (KISS = better) since we've no way to runtime do the right thing AFAICT. My concern is about the ever-growing number of DTS that just are small variations of one or the other. What about the time when we'll discover that this board has a variant that has an emmc, and some that don't have any button, or the i2c bus 2 not wired, and one other that doesn't have any HDMI? Do we really want to have a dts called sun8i-a33-q8h-emmc-lcd800x600-nohdmi-noi2c2-nobuttons.dts? Especially when we will have the one that we include here that will not have followed this convention because it was introduced before that, and that we have a way to deal with this nicely? You chose to consider the DTS names an ABI, the best way to handle this is to have a DTS as generic as possible, and leave all these small variations outside of the name. Ok, so for now this is not really an issue at all since the dts does not yet decribe the lcd at all. So can you merge this one renamed to a more generic name for 4.2? That will work fine for now. Then we can use the DT quirks interface to add different lcd nodes for different variants once we get lcd support in the kernel, and teach u-boot to add the extra board compatible to select the right lcd node at that time. I think we need to discuss this with Pantelis and what is his feeling about this. Pantelis, to sum things up, we have a case of a tablet that comes with the exact same board, but coming in two flavours with two differents screen resolutions. It looks like a great case for your DT quirks work, but we have no way of runtime detecting the difference between the two variants. What do you think about this? Should we go with using the DT quirks or is this simply out of scope? There's not so much example of similar cases in the kernel, and none of them use quirks so far (obviously) but they all boil down to either the solution you were suggesting in that patch or adding the alternate configuration as a comment. I don't think the latter would work for you, and I agree with that, so I guess that depending on what Pantelis says, either we go with a better solution using the quirks, or we end up using what you suggested (with a nitpick though, I'd prefer if you used the display standard instead of the resolution, which would make it xga I guess?) 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 v2 6/6] ARM: sun8i: dts: Add Ippo-q8h v1.2 with A33 and 1024x600 lcd support
Hi, On 13-06-15 15:50, Maxime Ripard wrote: Hi, Sorry for the late reply. On Wed, Jun 03, 2015 at 01:12:04PM +0200, Hans de Goede wrote: Hi, On 03-06-15 11:45, Maxime Ripard wrote: On Tue, Jun 02, 2015 at 10:29:09AM +0200, Hans de Goede wrote: Hi, On 02-06-15 10:14, Maxime Ripard wrote: On Sat, May 30, 2015 at 04:55:06PM +0200, Hans de Goede wrote: The Ippo-q8h is a tablet circuit board commonly found in cheap Android tablets. The v1.2 version can be used with either an A23 or A33 SoC. This adds a dts file for the v1.2 board with an A33 SoC and a 1024x600 LCD screen (most of these tablets have a 800x480 screen). I think the difference between the resolution here is more of a case for the DT quirks interface: https://lkml.org/lkml/2015/2/18/258 I would expect the only difference between the 2 dts files to be the node describing the lcd panel, so yes that makes somewhat sense. Do you know if there's some way to autodetect the two board versions (like a board id somewhere in an EEPROM)? No, AFAIK there is no way to tell the difference. There is no eeprom no the board, and we really cannot rely on the nand contents. Ok. If not, then maybe u-boot can simply add that board compatible to the list, and we'll base our logic on that when we'll need it. That means extra logic in u-boot, and on the kernel side, for what benefit exactly? Such logic would make sense if there was one u-boot image which runtime adjusted itself, but that is not an option. For what benefit? One kernel image which runtime adjusts itself. You mean one dtb right, because the kernel itself already runtime adjusts itself. Well, the kernel will runtime adjust the DT, so, both, I'd say? It's especially possible if u-boot's image is not, which seems to be what you're saying. But we will still need different configs in u-boot, and we need to add code + config to u-boot to plug in the extra compatibles to automatically select the right built-in overlays. You're going to have a different config anyway, but yeah, that's true. And we can avoid copy and paste on the dts side by putting all the common stuff in a common file and including that, I believe that that is better (KISS = better) since we've no way to runtime do the right thing AFAICT. My concern is about the ever-growing number of DTS that just are small variations of one or the other. What about the time when we'll discover that this board has a variant that has an emmc, and some that don't have any button, or the i2c bus 2 not wired, and one other that doesn't have any HDMI? Do we really want to have a dts called sun8i-a33-q8h-emmc-lcd800x600-nohdmi-noi2c2-nobuttons.dts? Especially when we will have the one that we include here that will not have followed this convention because it was introduced before that, and that we have a way to deal with this nicely? You chose to consider the DTS names an ABI, the best way to handle this is to have a DTS as generic as possible, and leave all these small variations outside of the name. Ok, so for now this is not really an issue at all since the dts does not yet decribe the lcd at all. So can you merge this one renamed to a more generic name for 4.2? That will work fine for now. Then we can use the DT quirks interface to add different lcd nodes for different variants once we get lcd support in the kernel, and teach u-boot to add the extra board compatible to select the right lcd node at that time. I think we need to discuss this with Pantelis and what is his feeling about this. Ok. Pantelis, to sum things up, we have a case of a tablet that comes with the exact same board, but coming in two flavours with two differents screen resolutions. It looks like a great case for your DT quirks work, but we have no way of runtime detecting the difference between the two variants. What do you think about this? Should we go with using the DT quirks or is this simply out of scope? There's not so much example of similar cases in the kernel, and none of them use quirks so far (obviously) but they all boil down to either the solution you were suggesting in that patch or adding the alternate configuration as a comment. I don't think the latter would work for you, and I agree with that, so I guess that depending on what Pantelis says, either we go with a better solution using the quirks, or we end up using what you suggested (with a nitpick though, I'd prefer if you used the display standard instead of the resolution, which would make it xga I guess?) If we go with a separate dts file for each of the 800x480 and 1024x600 screens, I would greatly prefer to stick with the lcd1024x600 in the dts filename instead of using something like xga, the fact that you say: I guess that my answer to that is: I dunno I would need to look this up in wikipedia or some such makes me think that using a qualifier like xga is not going the help end users decide which dts file to pick, it will just lead to them needing to go to
[linux-sunxi] Re: [PATCH 00/20] ARM: dts: Add USB and OTG related nodes and enable on various boards
Hi, On 12-06-15 15:27, Hans de Goede wrote: Hi, On 10-06-15 15:27, Hans de Goede wrote: Hi, On 08-06-15 12:03, Maxime Ripard wrote: Hi Hans, On Fri, Jun 05, 2015 at 09:02:03PM +0200, Hans de Goede wrote: Hi Maxime, Here is a patch-set with all the otg / sun8i-usb-host related dts patches I've accumulated. These are intended for 4.3, and go hand in hand with the outstanding musb-sunxi / phy-sun4i-usb patches, which I expect to be merged as is for 4.3 . I'm fine with these patches. Do you have a branch somewhere that I can pull (without the one that you wanted me to drop, obviously)? I've just created a branch with just these patches directly on top of sunxi/for-next for you: https://github.com/jwrdegoede/linux-sunxi/commits/otg-dts-for-maxime Please ignore this for now. There have been some changes to the extcon framework, making it more integrated with devicetree, this means I need to add an extcon property to the musb nodes in devicetree: --- a/Documentation/devicetree/bindings/usb/allwinner,sun4i-a10-musb.txt +++ b/Documentation/devicetree/bindings/usb/allwinner,sun4i-a10-musb.txt @@ -12,6 +12,7 @@ Required properties: - phys: phy specifier for the otg phy - phy-names : must be usb - dr_mode : Dual-Role mode must be host or otg + - extcon : extcon specifier for the otg phy Example: @@ -23,5 +24,6 @@ Example: interrupt-names = mc; phys = usbphy 0; phy-names = usb; + extcon = usbphy 0; status = disabled; }; --- a/arch/arm/boot/dts/sun7i-a20.dtsi +++ b/arch/arm/boot/dts/sun7i-a20.dtsi @@ -773,6 +773,7 @@ interrupt-names = mc; phys = usbphy 0; phy-names = usb; + extcon = usbphy 0; allwinner,sram = otg_sram 1; status = disabled; }; I'll push a new version of the patches to otg-dts-for-maxime with the extcon property added for you and ping you when it is ready. Done, https://github.com/jwrdegoede/linux-sunxi/commits/otg-dts-for-maxime now contains the necessary changes and is ready for merging for 4.3. 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] testing sunxi-codec on Cubieboard A10
hello, first of all, thanx for the feedback and sorry for the late reply on thread; it's that i'm a bit busy so can't followup properly. moreover let me tell you that my first report about audio on sunxi-codec coming only from one (wrong) earphone, was a completely mistake by my side. i wasn't plugging the HP jack enough. :-) that's why also i was getting the wrong channel on the only ear. after i started plugging the jack completely,the sound has been flowing correctly in both the ears. so it was just a typical PEBKAC issue! :-) before doing other tests, i'll try your next iteration of the linux-wip and report the eventual patch to make the cubieboard .dts support the codec. On 03-06-15 22:03, Andrea Venturi wrote: hello, moreover when moving control to the position where it was muted, again on mplayer console i could spot messages of audio device is stuck , and again toggling back the DAC output control, the music starting again.. i suppose anyway that toggling alsa mixer controls should never stop the DAC from sinking samples coming from the application level, right? Right. then there's pending this glitch on playback issues when/if toggling alsa audio controls; i'll check again/better in next testing iteration, too. -- 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] GMAC speed problem on my A31s tv box
Hello,
I am trying to run mainline linux with mainline u-boot on tmb2200ra (A TV BOX
made by TIAOBAO, A31s,1GB Ram, 8GB eMMC and 100Mb Ethenet (ICPLUS IP101GR
PHY)), the GMAC speed is very stange, scp from other computer speed at 8.0MB/s,
pretty good, while scp to other machine start at 2.0MB/s and gradually drop to
around 70KB/s and stable at there. The stock android kernel can go beyond 8.0MB
for both Rx and Tx, so it's not hardware problem.
My dts file is minimum, with gmac set as:
gmac: ethernet@01c3 {
pinctrl-names = default;
pinctrl-0 = gmac_pins_mii_a;
phy = phy1;
phy-mode = mii;
status = okay;
phy1: ethernet-phy@1 {
reg = 1;
};
};
I noticed there are some discussion about CONFIG_GMAC_TX_DELAY in uboot, I
tried 0 and 3, it seems has no effect on this problem.
Please anyone shed some light on this problem?
--
You received this message because you are subscribed to the Google Groups
linux-sunxi group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [RFC] Add DMA RX support for sunxi nand
Hi Roy, On Fri, 12 Jun 2015 13:38:47 +0200 Roy Spliet r.spl...@ultimaker.com wrote: Following are two patches for sunxi nand DMA support. There's a whole phletora of reasons why these are marked RFC, including: - Sunxi DMA support still needs to be merged upstream - Sun7i NAND definitions are not merged upstream - No TX support - Bounce buffer size is fixed to 8KB, and I have no idea whether this is sane - No clustering of DMA requests - More hw features that we might want to use Some of this can be addressed in follow-up patches, some can't. I'm just curious what you think. Motivation for sending this out anyway: on my set-up this already improves boot time by approx. 4s, or ~10%. This cheers me up on a sunny Friday afternoon in the office. I'm really interested in having DMA support for this driver, but I'm still wondering why we have such a difference between the non-DMA and DMA verion, especially since you're now using a bounce buffer allocated with dma_alloc_coherent (uncached memory region). I guess all the perf penalty comes from the memcpy_fromio/toio (which are useless in our case: we don't need a memory barrier after writing each byte in the SRAM). Can you try replacing them by simple memcpys and relaunch you tests ? This being said, I really think the DMA approach can be interesting if we support the 'page mode', which is able to read one full page with a single command (and a single DMA transfer) instead of having iterate over each ECC chunk. Best Regards, Boris -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] [PATCH v2 4/4] power: Add an axp20x-usb-power driver
This adds a driver for the usb power_supply bits of the axp20x PMICs.
I initially started writing my own driver, before coming aware of
Bruno Prémont's excellent earlier RFC with a driver for this.
My driver was lacking CURRENT_MAX and VOLTAGE_MIN support Bruno's
drvier has, so I've copied the code for those from his driver.
Note that the AC-power-supply and battery charger bits will need separate
drivers. Each one needs its own devictree child-node so that other
devicetree nodes can reference the right power-supply, and thus each one
will get its own mfd-cell / platform_device and platform-driver.
Cc: Bruno Prémont bonb...@linux-vserver.org
Signed-off-by: Hans de Goede hdego...@redhat.com
---
Changes in v2:
-Split out the dt-bindings documentation into a separate patch
-Renamed axp20x_read_16bit to axp20x_read_variable_width
-Use better local variable names inside axp20x_read_variable_width
---
drivers/power/Kconfig| 7 ++
drivers/power/Makefile | 1 +
drivers/power/axp20x_usb_power.c | 243 +++
include/linux/mfd/axp20x.h | 24
4 files changed, 275 insertions(+)
create mode 100644 drivers/power/axp20x_usb_power.c
diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
index 4091fb0..1fee60c 100644
--- a/drivers/power/Kconfig
+++ b/drivers/power/Kconfig
@@ -439,6 +439,13 @@ config BATTERY_RT5033
The fuelgauge calculates and determines the battery state of charge
according to battery open circuit voltage.
+config AXP20X_POWER
+ tristate AXP20x power supply driver
+ depends on MFD_AXP20X
+ help
+ This driver provides support for the power supply features of
+ AXP20x PMIC.
+
source drivers/power/reset/Kconfig
endif # POWER_SUPPLY
diff --git a/drivers/power/Makefile b/drivers/power/Makefile
index b7b0181..ae0f27d 100644
--- a/drivers/power/Makefile
+++ b/drivers/power/Makefile
@@ -9,6 +9,7 @@ obj-$(CONFIG_GENERIC_ADC_BATTERY) += generic-adc-battery.o
obj-$(CONFIG_PDA_POWER)+= pda_power.o
obj-$(CONFIG_APM_POWER)+= apm_power.o
+obj-$(CONFIG_AXP20X_POWER) += axp20x_usb_power.o
obj-$(CONFIG_MAX8925_POWER)+= max8925_power.o
obj-$(CONFIG_WM831X_BACKUP)+= wm831x_backup.o
obj-$(CONFIG_WM831X_POWER) += wm831x_power.o
diff --git a/drivers/power/axp20x_usb_power.c b/drivers/power/axp20x_usb_power.c
new file mode 100644
index 000..09f388e
--- /dev/null
+++ b/drivers/power/axp20x_usb_power.c
@@ -0,0 +1,243 @@
+/*
+ * AXP20x PMIC USB power supply status driver
+ *
+ * Copyright (C) 2015 Hans de Goede hdego...@redhat.com
+ * Copyright (C) 2014 Bruno Prémont bonb...@linux-vserver.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.
+ */
+
+#include linux/device.h
+#include linux/init.h
+#include linux/interrupt.h
+#include linux/kernel.h
+#include linux/mfd/axp20x.h
+#include linux/module.h
+#include linux/of.h
+#include linux/platform_device.h
+#include linux/power_supply.h
+#include linux/regmap.h
+#include linux/slab.h
+
+#define DRVNAME axp20x-usb-power-supply
+
+#define AXP20X_PWR_STATUS_VBUS_PRESENT BIT(5)
+#define AXP20X_PWR_STATUS_VBUS_USEDBIT(4)
+
+#define AXP20X_USB_STATUS_VBUS_VALID BIT(2)
+
+#define AXP20X_VBUS_VHOLD_uV(b)(400 + (((b) 3) 7) *
10)
+#define AXP20X_VBUS_CLIMIT_MASK3
+#define AXP20X_VBUC_CLIMIT_900mA 0
+#define AXP20X_VBUC_CLIMIT_500mA 1
+#define AXP20X_VBUC_CLIMIT_100mA 2
+#define AXP20X_VBUC_CLIMIT_NONE3
+
+#define AXP20X_ADC_EN1_VBUS_CURR BIT(2)
+#define AXP20X_ADC_EN1_VBUS_VOLT BIT(3)
+
+#define AXP20X_VBUS_MON_VBUS_VALID BIT(3)
+
+struct axp20x_usb_power {
+ struct regmap *regmap;
+ struct power_supply *supply;
+};
+
+static irqreturn_t axp20x_usb_power_irq(int irq, void *devid)
+{
+ struct axp20x_usb_power *power = devid;
+
+ power_supply_changed(power-supply);
+
+ return IRQ_HANDLED;
+}
+
+static int axp20x_usb_power_get_property(struct power_supply *psy,
+ enum power_supply_property psp, union power_supply_propval *val)
+{
+ struct axp20x_usb_power *power = power_supply_get_drvdata(psy);
+ unsigned int input, v;
+ int r;
+
+ switch (psp) {
+ case POWER_SUPPLY_PROP_VOLTAGE_MIN:
+ r = regmap_read(power-regmap, AXP20X_VBUS_IPSOUT_MGMT, v);
+ if (r)
+ return r;
+
+ val-intval = AXP20X_VBUS_VHOLD_uV(v);
+ return 0;
+ case POWER_SUPPLY_PROP_VOLTAGE_NOW:
+ r = axp20x_read_variable_width(power-regmap,
+ AXP20X_VBUS_V_ADC_H, 12);
+ if (r 0)
+
[linux-sunxi] [PATCH v2 3/4] mfd: axp20x: Add a cell for the usb power_supply part of the axp20x PMICs
Add a cell for the usb power_supply part of the axp20x PMICs.
Note that this cell is only for the usb power_supply part and not the
ac-power / battery-charger / rtc-backup-bat-charger bits.
Depending on the board each of those must be enabled / disabled separately
in devicetree as most boards do not use all 4. So in dt each one needs its
own child-node of the axp20x node. Another reason for using separate child
nodes for each is so that other devicetree nodes can have a power-supply
property with a phandle referencing a node representing a single
power-supply.
The decision to use a separate devicetree node for each is reflected on
the kernel side by each getting its own mfd-cell / platform_device and
platform-driver.
Cc: Bruno Prémont bonb...@linux-vserver.org
Signed-off-by: Hans de Goede hdego...@redhat.com
---
Changes in v2:
-Use DEFINE_RES_IRQ_NAMED
-Change indentation of axp20x_cells initializers to avoid line wrapping
---
drivers/mfd/axp20x.c | 20
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
index f9a3c2d..ca4a604 100644
--- a/drivers/mfd/axp20x.c
+++ b/drivers/mfd/axp20x.c
@@ -113,6 +113,13 @@ static struct resource axp20x_pek_resources[] = {
},
};
+static struct resource axp20x_usb_power_supply_resources[] = {
+ DEFINE_RES_IRQ_NAMED(AXP20X_IRQ_VBUS_PLUGIN, VBUS_PLUGIN),
+ DEFINE_RES_IRQ_NAMED(AXP20X_IRQ_VBUS_REMOVAL, VBUS_REMOVAL),
+ DEFINE_RES_IRQ_NAMED(AXP20X_IRQ_VBUS_VALID, VBUS_VALID),
+ DEFINE_RES_IRQ_NAMED(AXP20X_IRQ_VBUS_NOT_VALID, VBUS_NOT_VALID),
+};
+
static struct resource axp22x_pek_resources[] = {
{
.name = PEK_DBR,
@@ -363,11 +370,16 @@ static const struct regmap_irq_chip
axp288_regmap_irq_chip = {
static struct mfd_cell axp20x_cells[] = {
{
- .name = axp20x-pek,
- .num_resources = ARRAY_SIZE(axp20x_pek_resources),
- .resources = axp20x_pek_resources,
+ .name = axp20x-pek,
+ .num_resources = ARRAY_SIZE(axp20x_pek_resources),
+ .resources = axp20x_pek_resources,
}, {
- .name = axp20x-regulator,
+ .name = axp20x-regulator,
+ }, {
+ .name = axp20x-usb-power-supply,
+ .of_compatible = x-powers,axp202-usb-power-supply,
+ .num_resources = ARRAY_SIZE(axp20x_usb_power_supply_resources),
+ .resources = axp20x_usb_power_supply_resources,
},
};
--
2.4.3
--
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 v2 0/4] mfd/power: axp20x-usb-power driver
Hi All, Here is v2 of my axp20x-usb-power driver, addressing all review remarks from Lee Jones review of v1 (see individual commit messages for details). I'm not resending the dts bits as those are unchanged. I'll resend them to Maxime for merging once the axp20x-usb-power mfd bits and power_supply-driver have landed. 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] [PATCH v2 2/4] mfd: axp20x: Add missing registers, and mark more registers volatile
From: Bruno Prémont bonb...@linux-vserver.org
Add an extra set of registers which is necessary tu support the PMICs
battery charger function, and mark registers which contain status bits,
gpio status, and adc readings as volatile.
Cc: Bruno Prémont bonb...@linux-vserver.org
Signed-off-by: Hans de Goede hdego...@redhat.com
---
Changes in v2:
-Add a AXP20X_OCV_MAX define
---
drivers/mfd/axp20x.c | 8 +++-
include/linux/mfd/axp20x.h | 6 ++
2 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
index 6df9155..f9a3c2d 100644
--- a/drivers/mfd/axp20x.c
+++ b/drivers/mfd/axp20x.c
@@ -39,10 +39,16 @@ static const char * const axp20x_model_names[] = {
static const struct regmap_range axp20x_writeable_ranges[] = {
regmap_reg_range(AXP20X_DATACACHE(0), AXP20X_IRQ5_STATE),
regmap_reg_range(AXP20X_DCDC_MODE, AXP20X_FG_RES),
+ regmap_reg_range(AXP20X_RDC_H, AXP20X_OCV(15)),
};
static const struct regmap_range axp20x_volatile_ranges[] = {
+ regmap_reg_range(AXP20X_PWR_INPUT_STATUS, AXP20X_USB_OTG_STATUS),
+ regmap_reg_range(AXP20X_CHRG_CTRL1, AXP20X_CHRG_CTRL2),
regmap_reg_range(AXP20X_IRQ1_EN, AXP20X_IRQ5_STATE),
+ regmap_reg_range(AXP20X_ACIN_V_ADC_H, AXP20X_IPSOUT_V_HIGH_L),
+ regmap_reg_range(AXP20X_GPIO20_SS, AXP20X_GPIO3_CTRL),
+ regmap_reg_range(AXP20X_FG_RES, AXP20X_RDC_L),
};
static const struct regmap_access_table axp20x_writeable_table = {
@@ -159,7 +165,7 @@ static const struct regmap_config axp20x_regmap_config = {
.val_bits = 8,
.wr_table = axp20x_writeable_table,
.volatile_table = axp20x_volatile_table,
- .max_register = AXP20X_FG_RES,
+ .max_register = AXP20X_OCV(AXP20X_OCV_MAX),
.cache_type = REGCACHE_RBTREE,
};
diff --git a/include/linux/mfd/axp20x.h b/include/linux/mfd/axp20x.h
index 5275423..6d8b39a 100644
--- a/include/linux/mfd/axp20x.h
+++ b/include/linux/mfd/axp20x.h
@@ -151,6 +151,12 @@ enum {
#define AXP20X_CC_CTRL 0xb8
#define AXP20X_FG_RES 0xb9
+/* OCV */
+#define AXP20X_RDC_H 0xba
+#define AXP20X_RDC_L 0xbb
+#define AXP20X_OCV(m) (0xc0 + (m))
+#define AXP20X_OCV_MAX 0xf
+
/* AXP22X specific registers */
#define AXP22X_BATLOW_THRES1 0xe6
--
2.4.3
--
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 v2 1/4] ARM: dts: Add binding documentation for AXP20x pmic usb power supply
Add binding documentation for the usb power supply part of the AXP20x pmic.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
Changes in v2:
-Split out into a separate patch from the actual driver commit
---
.../bindings/power_supply/axp20x_usb_power.txt | 34 ++
1 file changed, 34 insertions(+)
create mode 100644
Documentation/devicetree/bindings/power_supply/axp20x_usb_power.txt
diff --git
a/Documentation/devicetree/bindings/power_supply/axp20x_usb_power.txt
b/Documentation/devicetree/bindings/power_supply/axp20x_usb_power.txt
new file mode 100644
index 000..a84d801
--- /dev/null
+++ b/Documentation/devicetree/bindings/power_supply/axp20x_usb_power.txt
@@ -0,0 +1,34 @@
+AXP20x USB power supply
+
+Required Properties:
+-compatible: x-powers,axp202-usb-power-supply
+
+This node is a subnode of the axp20x PMIC.
+
+Example:
+
+axp209: pmic@34 {
+ compatible = x-powers,axp209;
+ reg = 0x34;
+ interrupt-parent = nmi_intc;
+ interrupts = 0 IRQ_TYPE_LEVEL_LOW;
+ interrupt-controller;
+ #interrupt-cells = 1;
+
+ regulators {
+ x-powers,dcdc-freq = 1500;
+
+ vdd_cpu: dcdc2 {
+ regulator-always-on;
+ regulator-min-microvolt = 100;
+ regulator-max-microvolt = 145;
+ regulator-name = vdd-cpu;
+ };
+
+ ...
+ };
+
+ usb_power_supply: usb_power_supply {
+ compatible = x-powers,axp202-usb-power-supply;
+ };
+};
--
2.4.3
--
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] Discussion about mainlining the A83T
On Sat, Jun 13, 2015 at 12:05:28PM +0300, 'Simos Xenitellis' via linux-sunxi wrote: Hi All! Recently, several people received developer boards with the A83T SoC. I have collected information from a few sources and put them on https://linux-sunxi.org/User:Simos/H8HomletProtoV20_A83T The page includes a comparison of modules of the A83T with other A-line SoCs. There are high-resolution images of the board. In addition, the page has boot messages and also output of commands from the pre-installed BR Linux (kernel version: 3.4). I'ld like to start a thread about the planning of the mainlining of the A83T. If there are any other topics not directly related to this thread, please start a new thread. Simos Try the New_Device_Howto. Luc Verhaegen. -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] [PATCH v5 5/7] phy-sun4i-usb: Add support for the usb-phys on the sun8i-a33 SoC
The usb-phys on the sun8i-a33 SoC are mostly the same as sun8i-a23 but for
some reason (hw bug?) the phyctl register was moved to a different address
and is not initialized to 0 on reset.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
.../devicetree/bindings/phy/sun4i-usb-phy.txt | 1 +
drivers/phy/phy-sun4i-usb.c| 39 --
2 files changed, 29 insertions(+), 11 deletions(-)
diff --git a/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
b/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
index f0c640a..5f48979 100644
--- a/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
+++ b/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
@@ -8,6 +8,7 @@ Required properties:
* allwinner,sun6i-a31-usb-phy
* allwinner,sun7i-a20-usb-phy
* allwinner,sun8i-a23-usb-phy
+ * allwinner,sun8i-a33-usb-phy
- reg : a list of offset + length pairs
- reg-names :
* phy_ctrl
diff --git a/drivers/phy/phy-sun4i-usb.c b/drivers/phy/phy-sun4i-usb.c
index 6850fcd..5060257 100644
--- a/drivers/phy/phy-sun4i-usb.c
+++ b/drivers/phy/phy-sun4i-usb.c
@@ -40,9 +40,10 @@
#include linux/workqueue.h
#define REG_ISCR 0x00
-#define REG_PHYCTL 0x04
+#define REG_PHYCTL_A10 0x04
#define REG_PHYBIST0x08
#define REG_PHYTUNE0x0c
+#define REG_PHYCTL_A33 0x10
#define PHYCTL_DATABIT(7)
@@ -90,6 +91,7 @@ struct sun4i_usb_phy_data {
struct mutex mutex;
int num_phys;
u32 disc_thresh;
+ bool has_a33_phyctl;
struct sun4i_usb_phy {
struct phy *phy;
void __iomem *pmu;
@@ -152,37 +154,46 @@ static void sun4i_usb_phy_write(struct sun4i_usb_phy
*phy, u32 addr, u32 data,
{
struct sun4i_usb_phy_data *phy_data = to_sun4i_usb_phy_data(phy);
u32 temp, usbc_bit = BIT(phy-index * 2);
+ void *phyctl;
int i;
mutex_lock(phy_data-mutex);
+ if (phy_data-has_a33_phyctl) {
+ phyctl = phy_data-base + REG_PHYCTL_A33;
+ /* A33 needs us to set phyctl to 0 explictly */
+ writel(0, phyctl);
+ } else {
+ phyctl = phy_data-base + REG_PHYCTL_A10;
+ }
+
for (i = 0; i len; i++) {
- temp = readl(phy_data-base + REG_PHYCTL);
+ temp = readl(phyctl);
/* clear the address portion */
temp = ~(0xff 8);
/* set the address */
temp |= ((addr + i) 8);
- writel(temp, phy_data-base + REG_PHYCTL);
+ writel(temp, phyctl);
/* set the data bit and clear usbc bit*/
- temp = readb(phy_data-base + REG_PHYCTL);
+ temp = readb(phyctl);
if (data 0x1)
temp |= PHYCTL_DATA;
else
temp = ~PHYCTL_DATA;
temp = ~usbc_bit;
- writeb(temp, phy_data-base + REG_PHYCTL);
+ writeb(temp, phyctl);
/* pulse usbc_bit */
- temp = readb(phy_data-base + REG_PHYCTL);
+ temp = readb(phyctl);
temp |= usbc_bit;
- writeb(temp, phy_data-base + REG_PHYCTL);
+ writeb(temp, phyctl);
- temp = readb(phy_data-base + REG_PHYCTL);
+ temp = readb(phyctl);
temp = ~usbc_bit;
- writeb(temp, phy_data-base + REG_PHYCTL);
+ writeb(temp, phyctl);
data = 1;
}
@@ -443,7 +454,8 @@ static int sun4i_usb_phy_probe(struct platform_device *pdev)
dev_set_drvdata(dev, data);
if (of_device_is_compatible(np, allwinner,sun5i-a13-usb-phy) ||
- of_device_is_compatible(np, allwinner,sun8i-a23-usb-phy))
+ of_device_is_compatible(np, allwinner,sun8i-a23-usb-phy) ||
+ of_device_is_compatible(np, allwinner,sun8i-a33-usb-phy))
data-num_phys = 2;
else
data-num_phys = 3;
@@ -455,11 +467,15 @@ static int sun4i_usb_phy_probe(struct platform_device
*pdev)
data-disc_thresh = 3;
if (of_device_is_compatible(np, allwinner,sun6i-a31-usb-phy) ||
- of_device_is_compatible(np, allwinner,sun8i-a23-usb-phy))
+ of_device_is_compatible(np, allwinner,sun8i-a23-usb-phy) ||
+ of_device_is_compatible(np, allwinner,sun8i-a33-usb-phy))
dedicated_clocks = true;
else
dedicated_clocks = false;
+ if (of_device_is_compatible(np, allwinner,sun8i-a33-usb-phy))
+ data-has_a33_phyctl = true;
+
res = platform_get_resource_byname(pdev, IORESOURCE_MEM, phy_ctrl);
data-base = devm_ioremap_resource(dev, res);
if (IS_ERR(data-base))
@@ -591,6 +607,7 @@ static const struct
[linux-sunxi] [PATCH v5 6/7] phy-sun4i-usb: Add support for boards with broken Vusb-detection
On some boards we cannot detect the presence of an external Vusb, because
e.g. the 5V of the otg connector is directly connected to the 5V of the board,
and thus is always high.
This commit adds support for using such boards by only looking at the
id-detection pin.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
drivers/phy/phy-sun4i-usb.c | 44
1 file changed, 36 insertions(+), 8 deletions(-)
diff --git a/drivers/phy/phy-sun4i-usb.c b/drivers/phy/phy-sun4i-usb.c
index 5060257..0681641 100644
--- a/drivers/phy/phy-sun4i-usb.c
+++ b/drivers/phy/phy-sun4i-usb.c
@@ -22,6 +22,7 @@
*/
#include linux/clk.h
+#include linux/delay.h
#include linux/err.h
#include linux/extcon.h
#include linux/io.h
@@ -309,7 +310,7 @@ static int sun4i_usb_phy_power_on(struct phy *_phy)
phy-regulator_on = true;
/* We must report Vbus high within OTG_TIME_A_WAIT_VRISE msec. */
- if (phy-index == 0 data-phy0_poll)
+ if (phy-index == 0 data-vbus_det_gpio data-phy0_poll)
mod_delayed_work(system_wq, data-detect, DEBOUNCE_TIME);
return 0;
@@ -330,7 +331,7 @@ static int sun4i_usb_phy_power_off(struct phy *_phy)
* phy0 vbus typically slowly discharges, sometimes this causes the
* Vbus gpio to not trigger an edge irq on Vbus off, so force a rescan.
*/
- if (phy-index == 0 !data-phy0_poll)
+ if (phy-index == 0 data-vbus_det_gpio !data-phy0_poll)
mod_delayed_work(system_wq, data-detect, POLL_TIME);
return 0;
@@ -359,7 +360,10 @@ static void sun4i_usb_phy0_id_vbus_det_scan(struct
work_struct *work)
int id_det, vbus_det, id_notify = 0, vbus_notify = 0;
id_det = gpiod_get_value_cansleep(data-id_det_gpio);
- vbus_det = gpiod_get_value_cansleep(data-vbus_det_gpio);
+ if (data-vbus_det_gpio)
+ vbus_det = gpiod_get_value_cansleep(data-vbus_det_gpio);
+ else
+ vbus_det = 1; /* Report vbus as high */
mutex_lock(phy0-mutex);
@@ -369,6 +373,16 @@ static void sun4i_usb_phy0_id_vbus_det_scan(struct
work_struct *work)
}
if (id_det != data-id_det) {
+ /*
+* When a host cable (id == 0) gets plugged in on systems
+* without vbus detection report vbus low for long enough for
+* the musb-ip to end the current device session.
+*/
+ if (!data-vbus_det_gpio id_det == 0) {
+ sun4i_usb_phy0_set_vbus_detect(phy0, 0);
+ msleep(200);
+ sun4i_usb_phy0_set_vbus_detect(phy0, 1);
+ }
sun4i_usb_phy0_set_id_detect(phy0, id_det);
data-id_det = id_det;
id_notify = 1;
@@ -382,9 +396,22 @@ static void sun4i_usb_phy0_id_vbus_det_scan(struct
work_struct *work)
mutex_unlock(phy0-mutex);
- if (id_notify)
+ if (id_notify) {
extcon_set_cable_state_(data-extcon, EXTCON_USB_HOST,
!id_det);
+ /*
+* When a host cable gets unplugged (id == 1) on systems
+* without vbus detection report vbus low for long enough to
+* the musb-ip to end the current host session.
+*/
+ if (!data-vbus_det_gpio id_det == 1) {
+ mutex_lock(phy0-mutex);
+ sun4i_usb_phy0_set_vbus_detect(phy0, 0);
+ msleep(1000);
+ sun4i_usb_phy0_set_vbus_detect(phy0, 1);
+ mutex_unlock(phy0-mutex);
+ }
+ }
if (vbus_notify)
extcon_set_cable_state_(data-extcon, EXTCON_USB, vbus_det);
@@ -495,9 +522,9 @@ static int sun4i_usb_phy_probe(struct platform_device *pdev)
data-vbus_det_gpio = NULL;
}
- /* We either want both gpio pins or neither (when in host mode) */
- if (!data-id_det_gpio != !data-vbus_det_gpio) {
- dev_err(dev, failed to get id or vbus detect pin\n);
+ /* vbus_det without id_det makes no sense, and is not supported */
+ if (data-vbus_det_gpio !data-id_det_gpio) {
+ dev_err(dev, usb0_id_det missing or invalid\n);
return -ENODEV;
}
@@ -565,7 +592,8 @@ static int sun4i_usb_phy_probe(struct platform_device *pdev)
data-id_det_irq = gpiod_to_irq(data-id_det_gpio);
data-vbus_det_irq = gpiod_to_irq(data-vbus_det_gpio);
- if (data-id_det_irq 0 || data-vbus_det_irq 0)
+ if ((data-id_det_gpio data-id_det_irq 0) ||
+ (data-vbus_det_gpio data-vbus_det_irq 0))
data-phy0_poll = true;
if (data-id_det_irq = 0) {
--
2.4.3
--
You received this message because you are subscribed to the Google Groups
linux-sunxi group.
To unsubscribe from this
[linux-sunxi] [PATCH v5 0/7] phy-sun4i-usb: Add OTG and newer SoC support
Hi Kishon, Here is a patch series with all my oustanding phy-sun4i-usb changes pending for merging into 4.3. This includes the 5th iteration of the OTG support addition, now with the extcon provider support addition split-out into a new patch and ported to the extcon API changes which are queued up for 4.2 from : http://git.kernel.org/cgit/linux/kernel/git/chanwoo/extcon.git/log/?h=extcon-next-v4.2 which already merged in GKH's char-misc branch for 4.2, this means that this series now depends on those changes. Other than that this is a resend of some of the other feature addition patches I recently send rebased on top of v5 of the OTG support. Please merge this series for 4.3. 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] Discussion about mainlining the A83T
Hi All! Recently, several people received developer boards with the A83T SoC. I have collected information from a few sources and put them on https://linux-sunxi.org/User:Simos/H8HomletProtoV20_A83T The page includes a comparison of modules of the A83T with other A-line SoCs. There are high-resolution images of the board. In addition, the page has boot messages and also output of commands from the pre-installed BR Linux (kernel version: 3.4). I'ld like to start a thread about the planning of the mainlining of the A83T. If there are any other topics not directly related to this thread, please start a new thread. Simos -- 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 v5 4/7] phy-sun4i-usb: Add support for the usb-phys on the sun8i-a23 SoC
The usb-phys on the sun8i-a23 SoC have the same setup wrt clocks as on the
sun6i-a31 SoC, but there are only 2 instead of 3 like on the sun5i-a13 SoC.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt | 2 ++
drivers/phy/phy-sun4i-usb.c | 7 +--
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
b/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
index 557fa99..f0c640a 100644
--- a/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
+++ b/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
@@ -7,6 +7,7 @@ Required properties:
* allwinner,sun5i-a13-usb-phy
* allwinner,sun6i-a31-usb-phy
* allwinner,sun7i-a20-usb-phy
+ * allwinner,sun8i-a23-usb-phy
- reg : a list of offset + length pairs
- reg-names :
* phy_ctrl
@@ -17,6 +18,7 @@ Required properties:
- clock-names :
* usb_phy for sun4i, sun5i or sun7i
* usb0_phy, usb1_phy and usb2_phy for sun6i
+ * usb0_phy, usb1_phy for sun8i
- resets : a list of phandle + reset specifier pairs
- reset-names :
* usb0_reset
diff --git a/drivers/phy/phy-sun4i-usb.c b/drivers/phy/phy-sun4i-usb.c
index d78a071..6850fcd 100644
--- a/drivers/phy/phy-sun4i-usb.c
+++ b/drivers/phy/phy-sun4i-usb.c
@@ -442,7 +442,8 @@ static int sun4i_usb_phy_probe(struct platform_device *pdev)
INIT_DELAYED_WORK(data-detect, sun4i_usb_phy0_id_vbus_det_scan);
dev_set_drvdata(dev, data);
- if (of_device_is_compatible(np, allwinner,sun5i-a13-usb-phy))
+ if (of_device_is_compatible(np, allwinner,sun5i-a13-usb-phy) ||
+ of_device_is_compatible(np, allwinner,sun8i-a23-usb-phy))
data-num_phys = 2;
else
data-num_phys = 3;
@@ -453,7 +454,8 @@ static int sun4i_usb_phy_probe(struct platform_device *pdev)
else
data-disc_thresh = 3;
- if (of_device_is_compatible(np, allwinner,sun6i-a31-usb-phy))
+ if (of_device_is_compatible(np, allwinner,sun6i-a31-usb-phy) ||
+ of_device_is_compatible(np, allwinner,sun8i-a23-usb-phy))
dedicated_clocks = true;
else
dedicated_clocks = false;
@@ -588,6 +590,7 @@ static const struct of_device_id sun4i_usb_phy_of_match[] =
{
{ .compatible = allwinner,sun5i-a13-usb-phy },
{ .compatible = allwinner,sun6i-a31-usb-phy },
{ .compatible = allwinner,sun7i-a20-usb-phy },
+ { .compatible = allwinner,sun8i-a23-usb-phy },
{ },
};
MODULE_DEVICE_TABLE(of, sun4i_usb_phy_of_match);
--
2.4.3
--
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 v5 7/7] phy-sun4i-usb: Add support for monitoring vbus via a power-supply
On some boards there is no vbus_det gpio pin, instead vbus-detection for
otg can be done via the pmic.
This commit adds support for monitoring vbus_det via the power_supply
exported by the pmic, enabling support for otg on these boards.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
.../devicetree/bindings/phy/sun4i-usb-phy.txt | 1 +
drivers/phy/Kconfig| 1 +
drivers/phy/phy-sun4i-usb.c| 76 --
3 files changed, 71 insertions(+), 7 deletions(-)
diff --git a/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
b/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
index 5f48979..0cebf74 100644
--- a/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
+++ b/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
@@ -29,6 +29,7 @@ Required properties:
Optional properties:
- usb0_id_det-gpios : gpio phandle for reading the otg id pin value
- usb0_vbus_det-gpios : gpio phandle for detecting the presence of usb0 vbus
+- usb0_vbus_power-supply: power-supply phandle for usb0 vbus presence detect
- usb0_vbus-supply : regulator phandle for controller usb0 vbus
- usb1_vbus-supply : regulator phandle for controller usb1 vbus
- usb2_vbus-supply : regulator phandle for controller usb2 vbus
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 9841780..4e71765 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -174,6 +174,7 @@ config PHY_SUN4I_USB
depends on ARCH_SUNXI HAS_IOMEM OF
depends on RESET_CONTROLLER
depends on EXTCON
+ depends on POWER_SUPPLY
select GENERIC_PHY
help
Enable this to support the transceiver that is part of Allwinner
diff --git a/drivers/phy/phy-sun4i-usb.c b/drivers/phy/phy-sun4i-usb.c
index 0681641..1010519 100644
--- a/drivers/phy/phy-sun4i-usb.c
+++ b/drivers/phy/phy-sun4i-usb.c
@@ -36,6 +36,7 @@
#include linux/phy/phy.h
#include linux/phy/phy-sun4i-usb.h
#include linux/platform_device.h
+#include linux/power_supply.h
#include linux/regulator/consumer.h
#include linux/reset.h
#include linux/workqueue.h
@@ -108,6 +109,9 @@ struct sun4i_usb_phy_data {
bool phy0_poll;
struct gpio_desc *id_det_gpio;
struct gpio_desc *vbus_det_gpio;
+ struct power_supply *vbus_power_supply;
+ struct notifier_block vbus_power_nb;
+ bool vbus_power_nb_registered;
int id_det_irq;
int vbus_det_irq;
int id_det;
@@ -352,6 +356,30 @@ static struct phy_ops sun4i_usb_phy_ops = {
.owner = THIS_MODULE,
};
+static int sun4i_usb_phy0_get_vbus_det(struct sun4i_usb_phy_data *data)
+{
+ if (data-vbus_det_gpio)
+ return gpiod_get_value_cansleep(data-vbus_det_gpio);
+
+ if (data-vbus_power_supply) {
+ union power_supply_propval val;
+ int r;
+
+ r = power_supply_get_property(data-vbus_power_supply,
+ POWER_SUPPLY_PROP_PRESENT, val);
+ if (r == 0)
+ return val.intval;
+ }
+
+ /* Fallback: report vbus as high */
+ return 1;
+}
+
+static bool sun4i_usb_phy0_have_vbus_det(struct sun4i_usb_phy_data *data)
+{
+ return data-vbus_det_gpio || data-vbus_power_supply;
+}
+
static void sun4i_usb_phy0_id_vbus_det_scan(struct work_struct *work)
{
struct sun4i_usb_phy_data *data =
@@ -360,10 +388,7 @@ static void sun4i_usb_phy0_id_vbus_det_scan(struct
work_struct *work)
int id_det, vbus_det, id_notify = 0, vbus_notify = 0;
id_det = gpiod_get_value_cansleep(data-id_det_gpio);
- if (data-vbus_det_gpio)
- vbus_det = gpiod_get_value_cansleep(data-vbus_det_gpio);
- else
- vbus_det = 1; /* Report vbus as high */
+ vbus_det = sun4i_usb_phy0_get_vbus_det(data);
mutex_lock(phy0-mutex);
@@ -378,7 +403,7 @@ static void sun4i_usb_phy0_id_vbus_det_scan(struct
work_struct *work)
* without vbus detection report vbus low for long enough for
* the musb-ip to end the current device session.
*/
- if (!data-vbus_det_gpio id_det == 0) {
+ if (!sun4i_usb_phy0_have_vbus_det(data) id_det == 0) {
sun4i_usb_phy0_set_vbus_detect(phy0, 0);
msleep(200);
sun4i_usb_phy0_set_vbus_detect(phy0, 1);
@@ -404,7 +429,7 @@ static void sun4i_usb_phy0_id_vbus_det_scan(struct
work_struct *work)
* without vbus detection report vbus low for long enough to
* the musb-ip to end the current host session.
*/
- if (!data-vbus_det_gpio id_det == 1) {
+ if (!sun4i_usb_phy0_have_vbus_det(data) id_det == 1) {
mutex_lock(phy0-mutex);
sun4i_usb_phy0_set_vbus_detect(phy0, 0);
[linux-sunxi] [PATCH v5 2/7] phy-sun4i-usb: Add extcon support for the otg phy (phy0)
The sunxi musb glue needs to know if a host or normal usb cable is plugged
in, add extcon support so that the musb glue can monitor the host status.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
Changes in v5:
-Split out of the Add id and vbus detection support commit
-Ported to the new extcon API queued for 4.2
---
drivers/phy/Kconfig | 1 +
drivers/phy/phy-sun4i-usb.c | 32 +++-
2 files changed, 32 insertions(+), 1 deletion(-)
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index a53bd5b..9841780 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -173,6 +173,7 @@ config PHY_SUN4I_USB
tristate Allwinner sunxi SoC USB PHY driver
depends on ARCH_SUNXI HAS_IOMEM OF
depends on RESET_CONTROLLER
+ depends on EXTCON
select GENERIC_PHY
help
Enable this to support the transceiver that is part of Allwinner
diff --git a/drivers/phy/phy-sun4i-usb.c b/drivers/phy/phy-sun4i-usb.c
index bdf63ad..86d9ce1 100644
--- a/drivers/phy/phy-sun4i-usb.c
+++ b/drivers/phy/phy-sun4i-usb.c
@@ -23,6 +23,7 @@
#include linux/clk.h
#include linux/err.h
+#include linux/extcon.h
#include linux/io.h
#include linux/interrupt.h
#include linux/kernel.h
@@ -99,6 +100,7 @@ struct sun4i_usb_phy_data {
int index;
} phys[MAX_PHYS];
/* phy0 / otg related variables */
+ struct extcon_dev *extcon;
bool phy0_init;
bool phy0_poll;
struct gpio_desc *id_det_gpio;
@@ -343,7 +345,7 @@ static void sun4i_usb_phy0_id_vbus_det_scan(struct
work_struct *work)
struct sun4i_usb_phy_data *data =
container_of(work, struct sun4i_usb_phy_data, detect.work);
struct phy *phy0 = data-phys[0].phy;
- int id_det, vbus_det;
+ int id_det, vbus_det, id_notify = 0, vbus_notify = 0;
id_det = gpiod_get_value_cansleep(data-id_det_gpio);
vbus_det = gpiod_get_value_cansleep(data-vbus_det_gpio);
@@ -358,15 +360,24 @@ static void sun4i_usb_phy0_id_vbus_det_scan(struct
work_struct *work)
if (id_det != data-id_det) {
sun4i_usb_phy0_set_id_detect(phy0, id_det);
data-id_det = id_det;
+ id_notify = 1;
}
if (vbus_det != data-vbus_det) {
sun4i_usb_phy0_set_vbus_detect(phy0, vbus_det);
data-vbus_det = vbus_det;
+ vbus_notify = 1;
}
mutex_unlock(phy0-mutex);
+ if (id_notify)
+ extcon_set_cable_state_(data-extcon, EXTCON_USB_HOST,
+ !id_det);
+
+ if (vbus_notify)
+ extcon_set_cable_state_(data-extcon, EXTCON_USB, vbus_det);
+
if (data-phy0_poll)
queue_delayed_work(system_wq, data-detect, POLL_TIME);
}
@@ -407,6 +418,12 @@ static int sun4i_usb_phy_remove(struct platform_device
*pdev)
return 0;
}
+static const unsigned int sun4i_usb_phy0_cable[] = {
+ EXTCON_USB,
+ EXTCON_USB_HOST,
+ EXTCON_NONE,
+};
+
static int sun4i_usb_phy_probe(struct platform_device *pdev)
{
struct sun4i_usb_phy_data *data;
@@ -466,6 +483,19 @@ static int sun4i_usb_phy_probe(struct platform_device
*pdev)
return -ENODEV;
}
+ if (data-id_det_gpio) {
+ data-extcon = devm_extcon_dev_allocate(dev,
+ sun4i_usb_phy0_cable);
+ if (IS_ERR(data-extcon))
+ return PTR_ERR(data-extcon);
+
+ ret = devm_extcon_dev_register(dev, data-extcon);
+ if (ret) {
+ dev_err(dev, failed to register extcon: %d\n, ret);
+ return ret;
+ }
+ }
+
for (i = 0; i data-num_phys; i++) {
struct sun4i_usb_phy *phy = data-phys + i;
char name[16];
--
2.4.3
--
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 v5 1/7] phy-sun4i-usb: Add id and vbus detection support for the otg phy (phy0)
The usb0 phy is connected to an OTG controller, and as such needs some special
handling:
1) It allows explicit control over the pullups, enable these on phy_init and
disable them on phy_exit.
2) It has bits to signal id and vbus detect to the musb-core, add support for
for monitoring id and vbus detect gpio-s for use in dual role mode, and set
these bits to the correct values for operating in host only mode when no
gpios are specified in the devicetree.
While updating the devicetree binding documentation also add documentation
for the sofar undocumented usage of regulators for vbus for all 3 phys.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
Changes in v2:
-Removed the sunxi specific phy functions, instead the id / vbus gpio polling
has been moved to the phy-sun4i-usb driver and their status is exported
through extcon for the sunxi-musb glue
Changes in v3:
-No changes
Changes in v4:
-Do not call regulator_disable in an unbalanced manner when an external vbus
is present
Changes in v5:
-Split the addition of the extcon handler out into a separate patch
-Use sun4i_usb_phy_remove() to ensure the vbus/id detect workqueue is stopped
if sun4i_usb_phy_probe() fails after registering an irq handler
---
.../devicetree/bindings/phy/sun4i-usb-phy.txt | 18 +-
drivers/phy/phy-sun4i-usb.c| 250 -
2 files changed, 256 insertions(+), 12 deletions(-)
diff --git a/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
b/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
index 16528b9..557fa99 100644
--- a/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
+++ b/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
@@ -23,6 +23,13 @@ Required properties:
* usb1_reset
* usb2_reset for sun4i, sun6i or sun7i
+Optional properties:
+- usb0_id_det-gpios : gpio phandle for reading the otg id pin value
+- usb0_vbus_det-gpios : gpio phandle for detecting the presence of usb0 vbus
+- usb0_vbus-supply : regulator phandle for controller usb0 vbus
+- usb1_vbus-supply : regulator phandle for controller usb1 vbus
+- usb2_vbus-supply : regulator phandle for controller usb2 vbus
+
Example:
usbphy: phy@0x01c13400 {
#phy-cells = 1;
@@ -32,6 +39,13 @@ Example:
reg-names = phy_ctrl, pmu1, pmu2;
clocks = usb_clk 8;
clock-names = usb_phy;
- resets = usb_clk 1, usb_clk 2;
- reset-names = usb1_reset, usb2_reset;
+ resets = usb_clk 0, usb_clk 1, usb_clk 2;
+ reset-names = usb0_reset, usb1_reset, usb2_reset;
+ pinctrl-names = default;
+ pinctrl-0 = usb0_id_detect_pin, usb0_vbus_detect_pin;
+ usb0_id_det-gpios = pio 7 19 GPIO_ACTIVE_HIGH; /* PH19 */
+ usb0_vbus_det-gpios = pio 7 22 GPIO_ACTIVE_HIGH; /* PH22 */
+ usb0_vbus-supply = reg_usb0_vbus;
+ usb1_vbus-supply = reg_usb1_vbus;
+ usb2_vbus-supply = reg_usb2_vbus;
};
diff --git a/drivers/phy/phy-sun4i-usb.c b/drivers/phy/phy-sun4i-usb.c
index 91c5be4..bdf63ad 100644
--- a/drivers/phy/phy-sun4i-usb.c
+++ b/drivers/phy/phy-sun4i-usb.c
@@ -1,7 +1,7 @@
/*
* Allwinner sun4i USB phy driver
*
- * Copyright (C) 2014 Hans de Goede hdego...@redhat.com
+ * Copyright (C) 2014-2015 Hans de Goede hdego...@redhat.com
*
* Based on code from
* Allwinner Technology Co., Ltd. www.allwinnertech.com
@@ -24,16 +24,19 @@
#include linux/clk.h
#include linux/err.h
#include linux/io.h
+#include linux/interrupt.h
#include linux/kernel.h
#include linux/module.h
#include linux/mutex.h
#include linux/of.h
#include linux/of_address.h
+#include linux/of_gpio.h
#include linux/phy/phy.h
#include linux/phy/phy-sun4i-usb.h
#include linux/platform_device.h
#include linux/regulator/consumer.h
#include linux/reset.h
+#include linux/workqueue.h
#define REG_ISCR 0x00
#define REG_PHYCTL 0x04
@@ -47,6 +50,17 @@
#define SUNXI_AHB_INCRX_ALIGN_EN BIT(8)
#define SUNXI_ULPI_BYPASS_EN BIT(0)
+/* ISCR, Interface Status and Control bits */
+#define ISCR_ID_PULLUP_EN (1 17)
+#define ISCR_DPDM_PULLUP_EN(1 16)
+/* sunxi has the phy id/vbus pins not connected, so we use the force bits */
+#define ISCR_FORCE_ID_MASK (3 14)
+#define ISCR_FORCE_ID_LOW (2 14)
+#define ISCR_FORCE_ID_HIGH (3 14)
+#define ISCR_FORCE_VBUS_MASK (3 12)
+#define ISCR_FORCE_VBUS_LOW(2 12)
+#define ISCR_FORCE_VBUS_HIGH (3 12)
+
/* Common Control Bits for Both PHYs */
#define PHY_PLL_BW 0x03
#define PHY_RES45_CAL_EN 0x0c
@@ -63,6 +77,13 @@
#define MAX_PHYS 3
+/*
+ * Note do not raise the debounce time, we must report Vusb high within 100ms
+ * otherwise we get Vbus errors
+ */
+#define DEBOUNCE_TIME msecs_to_jiffies(50)
+#define POLL_TIME
[linux-sunxi] [PATCH v5 3/7] phy-sun4i-usb: Swap check for disconnect threshold
Before this commit the code for determining the disconnect threshold was checking for allwinner,sun4i-a10-usb-phy or allwinner,sun6i-a31-usb-phy assuming that those where the exception and then newer SoCs would use a disconnect threshold of 2 like sun7i does. But it turns out that newer SoCs use a disconnect threshold of 3 and sun5i and sun7i are the exceptions, so check for those instead. Here are the settings from the various Allwinner SDK sources: sun4i-a10: USBC_Phy_Write(usbc_no, 0x2a, 3, 2); sun5i-a13: USBC_Phy_Write(usbc_no, 0x2a, 2, 2); sun6i-a31: USBC_Phy_Write(usbc_no, 0x2a, 3, 2); sun7i-a20: USBC_Phy_Write(usbc_no, 0x2a, 2, 2); sun8i-a23: USBC_Phy_Write(usbc_no, 0x2a, 3, 2); sun8i-h3: USBC_Phy_Write(usbc_no, 0x2a, 3, 2); sun9i-a80: USBC_Phy_Write(usbc_no, 0x2a, 3, 2); Note this commit makes no functional changes as currently we only support sun4i - sun7i. Signed-off-by: Hans de Goede hdego...@redhat.com --- drivers/phy/phy-sun4i-usb.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/phy/phy-sun4i-usb.c b/drivers/phy/phy-sun4i-usb.c index 86d9ce1..d78a071 100644 --- a/drivers/phy/phy-sun4i-usb.c +++ b/drivers/phy/phy-sun4i-usb.c @@ -447,11 +447,11 @@ static int sun4i_usb_phy_probe(struct platform_device *pdev) else data-num_phys = 3; - if (of_device_is_compatible(np, allwinner,sun4i-a10-usb-phy) || - of_device_is_compatible(np, allwinner,sun6i-a31-usb-phy)) - data-disc_thresh = 3; - else + if (of_device_is_compatible(np, allwinner,sun5i-a13-usb-phy) || + of_device_is_compatible(np, allwinner,sun7i-a20-usb-phy)) data-disc_thresh = 2; + else + data-disc_thresh = 3; if (of_device_is_compatible(np, allwinner,sun6i-a31-usb-phy)) dedicated_clocks = true; -- 2.4.3 -- 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.
