[PATCH v2] usb: host: add DT bindings for faraday fotg2
From: Hans Ulli Kroll
This adds device tree bindings for the Faraday FOTG2
dual-mode host controller.
Cc: devicet...@vger.kernel.org
Signed-off-by: Hans Ulli Kroll
Acked-by: Rob Herring
Signed-off-by: Linus Walleij
---
ChangeLog v1->v2:
- Changed "OTH" to "OTG"
- Collected Rob's ACK.
- I don't see any problem with these bindings, but IIRC Hans
had some reservations for the OTG mode, maybe we can strip
some properties like the mini-usb thing and use as a starter
so we can add host mode at least?
---
.../bindings/usb/faraday,fotg210.txt | 35 +++
1 file changed, 35 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/faraday,fotg210.txt
diff --git a/Documentation/devicetree/bindings/usb/faraday,fotg210.txt
b/Documentation/devicetree/bindings/usb/faraday,fotg210.txt
new file mode 100644
index ..06a2286e2054
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/faraday,fotg210.txt
@@ -0,0 +1,35 @@
+Faraday FOTG Host controller
+
+This OTG-capable USB host controller is found in Cortina Systems
+Gemini and other SoC products.
+
+Required properties:
+- compatible: should be one of:
+ "faraday,fotg210"
+ "cortina,gemini-usb", "faraday,fotg210"
+- reg: should contain one register range i.e. start and length
+- interrupts: description of the interrupt line
+
+Optional properties:
+- clocks: should contain the IP block clock
+- clock-names: should be "PCLK" for the IP block clock
+
+Required properties for "cortina,gemini-usb" compatible:
+- syscon: a phandle to the system controller to access PHY registers
+
+Optional properties for "cortina,gemini-usb" compatible:
+- cortina,gemini-mini-b: boolean property that indicates that a Mini-B
+ OTG connector is in use
+- wakeup-source: see power/wakeup-source.txt
+
+Example for Gemini:
+
+usb@6800 {
+ compatible = "cortina,gemini-usb", "faraday,fotg210";
+ reg = <0x6800 0x1000>;
+ interrupts = <10 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = < 12>;
+ clock-names = "PCLK";
+ syscon = <>;
+ wakeup-source;
+};
--
2.17.1
[PATCH] usb: host: fotg2: Fix potential NULL dereference
There is code in the .remove() hook to handle the drvdata
being NULL, for good reasons: it is never set, so it will
always be NULL. As I moved code around, static checkers
start complaining.
Instead of this, make sure to always set it on successful
probe so we can always dereference it on the remove path.
Use the platform_device_[set|get]_drvdata() since this is
a platform device.
Fixes: ffa8a31b5b3b ("usb: host: fotg2: add silicon clock handling")
Reported-by: Dan Carpenter
Cc: Dan Carpenter
Signed-off-by: Linus Walleij
---
drivers/usb/host/fotg210-hcd.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/host/fotg210-hcd.c b/drivers/usb/host/fotg210-hcd.c
index 058ff82ea789..bbcc68179bfc 100644
--- a/drivers/usb/host/fotg210-hcd.c
+++ b/drivers/usb/host/fotg210-hcd.c
@@ -5636,6 +5636,7 @@ static int fotg210_hcd_probe(struct platform_device *pdev)
goto failed_dis_clk;
}
device_wakeup_enable(hcd->self.controller);
+ platform_set_drvdata(pdev, hcd);
return retval;
@@ -5656,16 +5657,12 @@ static int fotg210_hcd_probe(struct platform_device
*pdev)
*/
static int fotg210_hcd_remove(struct platform_device *pdev)
{
- struct device *dev = >dev;
- struct usb_hcd *hcd = dev_get_drvdata(dev);
+ struct usb_hcd *hcd = platform_get_drvdata(pdev);
struct fotg210_hcd *fotg210 = hcd_to_fotg210(hcd);
if (!IS_ERR(fotg210->pclk))
clk_disable_unprepare(fotg210->pclk);
- if (!hcd)
- return 0;
-
usb_remove_hcd(hcd);
usb_put_hcd(hcd);
--
2.17.1
[PATCH v2] usb: host: fotg2: add silicon clock handling
When used in a system with software-controlled silicon clocks,
the FOTG210 needs to grab, prepare and enable the clock.
This is needed on for example the Cortina Gemini, where the
platform will by default gate off the clock unless the
peripheral (in this case the USB driver) grabs and enables
the clock.
If there is no clock available on the platform, we live
without it. Make sure to percolate probe deferrals.
Signed-off-by: Linus Walleij
---
ChangeLog v1->v2:
- Handle probe deferrals on the clock controller, no matter
how unlikely they are.
- Send the patch to get Gemini USB rolling and try to get some
stuff upstream, this patch should be fine on its own.
---
drivers/usb/host/fotg210-hcd.c | 33 +
drivers/usb/host/fotg210.h | 3 +++
2 files changed, 32 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/host/fotg210-hcd.c b/drivers/usb/host/fotg210-hcd.c
index e64eb47770c8..058ff82ea789 100644
--- a/drivers/usb/host/fotg210-hcd.c
+++ b/drivers/usb/host/fotg210-hcd.c
@@ -31,6 +31,7 @@
#include
#include
#include
+#include
#include
#include
@@ -5596,7 +5597,7 @@ static int fotg210_hcd_probe(struct platform_device *pdev)
hcd->regs = devm_ioremap_resource(>dev, res);
if (IS_ERR(hcd->regs)) {
retval = PTR_ERR(hcd->regs);
- goto failed;
+ goto failed_put_hcd;
}
hcd->rsrc_start = res->start;
@@ -5606,22 +5607,42 @@ static int fotg210_hcd_probe(struct platform_device
*pdev)
fotg210->caps = hcd->regs;
+ /* It's OK not to supply this clock */
+ fotg210->pclk = clk_get(dev, "PCLK");
+ if (!IS_ERR(fotg210->pclk)) {
+ retval = clk_prepare_enable(fotg210->pclk);
+ if (retval) {
+ dev_err(dev, "failed to enable PCLK\n");
+ goto failed_put_hcd;
+ }
+ } else if (PTR_ERR(fotg210->pclk) == -EPROBE_DEFER) {
+ /*
+* Percolate deferrals, for anything else,
+* just live without the clocking.
+*/
+ retval = PTR_ERR(fotg210->pclk);
+ goto failed_dis_clk;
+ }
+
retval = fotg210_setup(hcd);
if (retval)
- goto failed;
+ goto failed_dis_clk;
fotg210_init(fotg210);
retval = usb_add_hcd(hcd, irq, IRQF_SHARED);
if (retval) {
dev_err(dev, "failed to add hcd with err %d\n", retval);
- goto failed;
+ goto failed_dis_clk;
}
device_wakeup_enable(hcd->self.controller);
return retval;
-failed:
+failed_dis_clk:
+ if (!IS_ERR(fotg210->pclk))
+ clk_disable_unprepare(fotg210->pclk);
+failed_put_hcd:
usb_put_hcd(hcd);
fail_create_hcd:
dev_err(dev, "init %s fail, %d\n", dev_name(dev), retval);
@@ -5637,6 +5658,10 @@ static int fotg210_hcd_remove(struct platform_device
*pdev)
{
struct device *dev = >dev;
struct usb_hcd *hcd = dev_get_drvdata(dev);
+ struct fotg210_hcd *fotg210 = hcd_to_fotg210(hcd);
+
+ if (!IS_ERR(fotg210->pclk))
+ clk_disable_unprepare(fotg210->pclk);
if (!hcd)
return 0;
diff --git a/drivers/usb/host/fotg210.h b/drivers/usb/host/fotg210.h
index 7fcd785c7bc8..28f6467c0cbf 100644
--- a/drivers/usb/host/fotg210.h
+++ b/drivers/usb/host/fotg210.h
@@ -182,6 +182,9 @@ struct fotg210_hcd {/* one per
controller */
# define COUNT(x)
#endif
+ /* silicon clock */
+ struct clk *pclk;
+
/* debug files */
struct dentry *debug_dir;
};
--
2.17.1
[PATCH] usb: phy: ab8500: Drop AB8540/9540 support
The AB8540 was an evolved version of the AB8500, but it was never
mass produced or put into products, only reference designs exist.
The upstream support was never completed and it is unlikely that
this will happen so drop the support for now to simplify
maintenance of the AB8500.
Cc: Loic Pallardy <loic.palla...@st.com>
Signed-off-by: Linus Walleij <linus.wall...@linaro.org>
---
drivers/usb/phy/phy-ab8500-usb.c | 506 ---
1 file changed, 506 deletions(-)
diff --git a/drivers/usb/phy/phy-ab8500-usb.c b/drivers/usb/phy/phy-ab8500-usb.c
index 87295313a10c..7eb2b2b911e5 100644
--- a/drivers/usb/phy/phy-ab8500-usb.c
+++ b/drivers/usb/phy/phy-ab8500-usb.c
@@ -29,17 +29,12 @@
/* Bank AB8500_USB */
#define AB8500_USB_LINE_STAT_REG 0x80
#define AB8505_USB_LINE_STAT_REG 0x94
-#define AB8540_USB_LINK_STAT_REG 0x94
-#define AB9540_USB_LINK_STAT_REG 0x94
-#define AB8540_USB_OTG_CTL_REG 0x87
#define AB8500_USB_PHY_CTRL_REG 0x8A
-#define AB8540_VBUS_CTRL_REG 0x82
/* Bank AB8500_DEVELOPMENT */
#define AB8500_BANK12_ACCESS 0x00
/* Bank AB8500_DEBUG */
-#define AB8540_DEBUG 0x32
#define AB8500_USB_PHY_TUNE1 0x05
#define AB8500_USB_PHY_TUNE2 0x06
#define AB8500_USB_PHY_TUNE3 0x07
@@ -53,10 +48,6 @@
#define AB8500_BIT_WD_CTRL_ENABLE (1 << 0)
#define AB8500_BIT_WD_CTRL_KICK (1 << 1)
#define AB8500_BIT_SOURCE2_VBUSDET (1 << 7)
-#define AB8540_BIT_OTG_CTL_VBUS_VALID_ENA (1 << 0)
-#define AB8540_BIT_OTG_CTL_ID_HOST_ENA (1 << 1)
-#define AB8540_BIT_OTG_CTL_ID_DEV_ENA (1 << 5)
-#define AB8540_BIT_VBUS_CTRL_CHARG_DET_ENA (1 << 0)
#define AB8500_WD_KICK_DELAY_US 100 /* usec */
#define AB8500_WD_V11_DISABLE_DELAY_US 100 /* usec */
@@ -113,68 +104,6 @@ enum ab8505_usb_link_status {
USB_LINK_MOTOROLA_FACTORY_CBL_PHY_EN_8505,
};
-enum ab8540_usb_link_status {
- USB_LINK_NOT_CONFIGURED_8540 = 0,
- USB_LINK_STD_HOST_NC_8540,
- USB_LINK_STD_HOST_C_NS_8540,
- USB_LINK_STD_HOST_C_S_8540,
- USB_LINK_CDP_8540,
- USB_LINK_RESERVED0_8540,
- USB_LINK_RESERVED1_8540,
- USB_LINK_DEDICATED_CHG_8540,
- USB_LINK_ACA_RID_A_8540,
- USB_LINK_ACA_RID_B_8540,
- USB_LINK_ACA_RID_C_NM_8540,
- USB_LINK_RESERVED2_8540,
- USB_LINK_RESERVED3_8540,
- USB_LINK_HM_IDGND_8540,
- USB_LINK_CHARGERPORT_NOT_OK_8540,
- USB_LINK_CHARGER_DM_HIGH_8540,
- USB_LINK_PHYEN_NO_VBUS_NO_IDGND_8540,
- USB_LINK_STD_UPSTREAM_NO_IDGNG_VBUS_8540,
- USB_LINK_STD_UPSTREAM_8540,
- USB_LINK_CHARGER_SE1_8540,
- USB_LINK_CARKIT_CHGR_1_8540,
- USB_LINK_CARKIT_CHGR_2_8540,
- USB_LINK_ACA_DOCK_CHGR_8540,
- USB_LINK_SAMSUNG_BOOT_CBL_PHY_EN_8540,
- USB_LINK_SAMSUNG_BOOT_CBL_PHY_DISB_8540,
- USB_LINK_SAMSUNG_UART_CBL_PHY_EN_8540,
- USB_LINK_SAMSUNG_UART_CBL_PHY_DISB_8540,
- USB_LINK_MOTOROLA_FACTORY_CBL_PHY_EN_8540
-};
-
-enum ab9540_usb_link_status {
- USB_LINK_NOT_CONFIGURED_9540 = 0,
- USB_LINK_STD_HOST_NC_9540,
- USB_LINK_STD_HOST_C_NS_9540,
- USB_LINK_STD_HOST_C_S_9540,
- USB_LINK_CDP_9540,
- USB_LINK_RESERVED0_9540,
- USB_LINK_RESERVED1_9540,
- USB_LINK_DEDICATED_CHG_9540,
- USB_LINK_ACA_RID_A_9540,
- USB_LINK_ACA_RID_B_9540,
- USB_LINK_ACA_RID_C_NM_9540,
- USB_LINK_RESERVED2_9540,
- USB_LINK_RESERVED3_9540,
- USB_LINK_HM_IDGND_9540,
- USB_LINK_CHARGERPORT_NOT_OK_9540,
- USB_LINK_CHARGER_DM_HIGH_9540,
- USB_LINK_PHYEN_NO_VBUS_NO_IDGND_9540,
- USB_LINK_STD_UPSTREAM_NO_IDGNG_VBUS_9540,
- USB_LINK_STD_UPSTREAM_9540,
- USB_LINK_CHARGER_SE1_9540,
- USB_LINK_CARKIT_CHGR_1_9540,
- USB_LINK_CARKIT_CHGR_2_9540,
- USB_LINK_ACA_DOCK_CHGR_9540,
- USB_LINK_SAMSUNG_BOOT_CBL_PHY_EN_9540,
- USB_LINK_SAMSUNG_BOOT_CBL_PHY_DISB_9540,
- USB_LINK_SAMSUNG_UART_CBL_PHY_EN_9540,
- USB_LINK_SAMSUNG_UART_CBL_PHY_DISB_9540,
- USB_LINK_MOTOROLA_FACTORY_CBL_PHY_EN_9540
-};
-
enum ab8500_usb_mode {
USB_IDLE = 0,
USB_PERIPHERAL,
@@ -192,10 +121,6 @@ enum ab8500_usb_mode {
#define AB8500_USB_FLAG_USE_AB_IDDET (1 << 3)
/* Enable setting regulators voltage */
#define AB8500_USB_FLAG_REGULATOR_SET_VOLTAGE (1 << 4)
-/* Enable the check_vbus_status workaround */
-#define AB8500_USB_FLAG_USE_CHECK_VBUS_STATUS (1 << 5)
-/* Enable the vbus host workaround */
-#define AB8500_USB_FLAG_USE_VBUS_HOST_QUIRK(1 << 6)
struct ab8500_usb {
struct usb_phy phy;
@@ -203,7 +128,6 @@ struct ab8500_usb {
struct ab8500 *ab8500;
unsigned vbus_draw;
struct work_struct phy_dis_work;
- struct work_struct vbus_event_work;
enum ab8500_usb_mode mode;
struct clk *sysclk;
struct regulator *v_ape;
@@ -342,15 +266,6 @@ static void ab8500_usb_phy_enable(struct ab8500_usb *
Re: [PATCH 2/2] usb: gadget: udc: atmel: convert to use GPIO descriptors
On Thu, Feb 1, 2018 at 10:34 AM, Ludovic Desroches <ludovic.desroc...@microchip.com> wrote: > Use GPIO descriptors instead of relying on the old method. > Include irq.h header since it is needed and was indirectly > included through of_gpio.h. > > Signed-off-by: Ludovic Desroches <ludovic.desroc...@microchip.com> Reviewed-by: Linus Walleij <linus.wall...@linaro.org> Thank you for doing gpiod conversions. Making the world a better place! Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] gpio: Add FT232H CBUS GPIO driver
On Tue, Aug 1, 2017 at 11:24 AM, Johan Hovold <jo...@kernel.org> wrote: > On Tue, Aug 01, 2017 at 08:49:02AM +0200, Linus Walleij wrote: >> On Thu, Jul 6, 2017 at 10:49 PM, Anatolij Gustschin <ag...@denx.de> wrote: >> >> > Add driver for CBUS pins on FT232H. The driver supports setting >> > GPIO direction and getting/setting CBUS 0-3 pin value. The CBUS >> > pins have to be enabled by configuring I/O mode in the FTDI EEPROM. >> > >> > Signed-off-by: Anatolij Gustschin <ag...@denx.de> > >> Apart from these small things it looks like a solid and nice driver, >> do you plan to merge this into MFD or should I merge it? Since it depends >> on the Kconfig symbol I guess I can merge it orthogonally if I am sure >> Lee will pick the MFD part. > > There are some fundamental problems with this series which prevents it > from being merged. Please take a look at the discussion following patch > 1/3. Allright it is on hold pending the MFD discussion. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] gpio: Add FT232H CBUS GPIO driver
On Thu, Jul 6, 2017 at 10:49 PM, Anatolij Gustschin <ag...@denx.de> wrote: > Add driver for CBUS pins on FT232H. The driver supports setting > GPIO direction and getting/setting CBUS 0-3 pin value. The CBUS > pins have to be enabled by configuring I/O mode in the FTDI EEPROM. > > Signed-off-by: Anatolij Gustschin <ag...@denx.de> (...) > + select GPIO_GENERIC You do not seem to be using this. > +#include This include should not be needed. If it is, something is wrong. > +#include Drivers should only include this. > +#include > +#include > +#include > +#include Why is this needed if the device is abstracted behind an MFD interface? > +#include I.e. this? Apart from these small things it looks like a solid and nice driver, do you plan to merge this into MFD or should I merge it? Since it depends on the Kconfig symbol I guess I can merge it orthogonally if I am sure Lee will pick the MFD part. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/7] driver core: fix automatic pinctrl management
On Tue, May 30, 2017 at 6:25 PM, Johan Hovold <jo...@kernel.org> wrote:
> Commit ab78029ecc34 ("drivers/pinctrl: grab default handles from device
> core") added automatic pin-control management to driver core by looking
> up and setting any default pinctrl state found in device tree while a
> device is being probed.
Actually we do not just support device tree, but also passing pin control
states from board files. It is handled by the core all the same.
So it's not a device tree thing.
One of those days we will have ACPI passing state tables too...
But I understand what you mean.
> Fix this by checking the new of_node_reused flag and skipping automatic
> pinctrl configuration during probe if set.
Seems like a solid idea. I hope we don't need another quirk for ACPI.
Acked-by: Linus Walleij <linus.wall...@linaro.org>
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/5 v3] usb: host: fotg2: add Gemini-specific handling
On Mon, Apr 24, 2017 at 7:06 PM, Hans Ulli Kroll <ulli.kr...@googlemail.com> wrote: > please wait for a while, I'm working on some glue code to support both > host and device mode on FOTG. Sure no problem, sorry for being so impatient, it's a character trait. I sent out bindings and drivers for the Gemini clock controller and reset controller, so we might want to queue the clock handling at least. I'm happy if you pick some of these patches and keep them in your queue BTW. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5 v3] usb: host: add DT bindings for faraday fotg2
On Mon, Apr 24, 2017 at 6:53 PM, Hans Ulli Kroll
<ulli.kr...@googlemail.com> wrote:
> Got NAK'ed from Rob on some ealier round due missing "device mode" on this
> IP. I've blatantly overrided this to a host only driver.
>
> These are the needed changes in DT to support both modes
> Note the -dr at the end of fotg210, to reflect this in an dual role device
OK I understood the discussion such that the compatible should
simply be ""faraday,fotg210" as that is the name of the hardware
IP block. This is the name of the hardware name in the Faraday
page:
http://www.faraday-tech.com/html/Product/IPProduct/InterfaceIP/USB2_0.htm
Any other string implies how it is used, so that was what I understood
as the reason to reject it with the "-hcd" (host controller device) suffix.
> +- dr_mode : indicates the working mode for "fotg210-dr" compatible
> + controllers. Can be "host", "peripheral". Default to
> + "host" if not defined for backward compatibility.
This seems right, so it is part of the generic bindings, correct?
> usb@6800 {
> - compatible = "cortina,gemini-usb", "faraday,fotg210";
> + compatible = "cortina,gemini-usb", "faraday,fotg210-dr";
But this would be wrong, because the compatible should only
indicate what kind of hardware it is, not how it is going to be used
(whether as host only, slave only or dual-role (OTG).
I hope I didn't get anything wrong here :/
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] usb: add DT bindings for farady fotg2 host controller
On Thu, Mar 30, 2017 at 8:31 PM, Hans Ulli Kroll <ulli.kr...@googlemail.com> wrote: >> On Tue, Feb 21, 2017 at 3:43 PM, Rob Herring <r...@kernel.org> wrote: >> > On Fri, Feb 17, 2017 at 4:07 AM, Hans Ulli Kroll >> > <ulli.kr...@googlemail.com> wrote: >> >> Hi Rob, >> >> >> >> On Wed, 15 Feb 2017, Rob Herring wrote: >> >> >> >>> On Wed, Feb 08, 2017 at 09:00:09PM +0100, Hans Ulli Kroll wrote: >> >>> > This adds DT bindings for the Faraday FOTG2 host controller. >> >>> > >> >>> > Signed-off-by: Hans Ulli Kroll <ulli.kr...@googlemail.com> >> >>> > --- >> >>> > Documentation/devicetree/bindings/usb/fotg2-host.txt | 15 >> >>> > +++ >> >>> > 1 file changed, 15 insertions(+) >> >>> > create mode 100644 >> >>> > Documentation/devicetree/bindings/usb/fotg2-host.txt >> >>> > >> >>> > diff --git a/Documentation/devicetree/bindings/usb/fotg2-host.txt >> >>> > b/Documentation/devicetree/bindings/usb/fotg2-host.txt >> >>> > new file mode 100644 >> >>> > index ..4c07566a4bf5 >> >>> > --- /dev/null >> >>> > +++ b/Documentation/devicetree/bindings/usb/fotg2-host.txt >> >>> > @@ -0,0 +1,15 @@ >> >>> > +Faraday FOTG Host controller >> >>> > + >> >>> > +Required properties: >> >>> > + >> >>> > +- compatible: should be "faraday,fotg210-hcd" >> >>> >> >>> hcd as in "host controller driver"? Bindings describe h/w not drivers. >> >>> >> >>> It's an OTG controller or host controller? >> >>> >> >> >> >> here only the host controller part used. >> >> >> >> faraday fotg2 is a dual role hcd/otg device and here is only the >> >> host part used. >> > >> > Because you don't care about device mode or restricted by the IP >> > configuration or SoC integration? The former is a user choice and >> > shouldn't be part of DT. The latter should be implied by an SoC >> > specific compatible string. Using only a compatible string for a >> > licensed IP is not specific enough as vendors use differing versions >> > and integrate them in different ways. >> >> Hans can you add: >> >> compatible = "cortina,gemini-fotg", "faraday,fotg210-hcd" or something >> as composite compatible for our controller? I hacked on it a bit and sent out. Hope you don't hate it too much. > I prefer > "faraday,fotg210-usb2" I simply named it after the IP core name, which is just "faraday,fotg210". > I've got rejected by Rob due the fact this is an dual role controller, > which supports both host and device mode. And DT must reflect this desgn > pattern. > > Currently I'm wrappingt my head around the design of the fsl-mph-dr-of.c > driver to use this as a blueprint for the Faraday driver. I don't know how much more of the dual-mode we need to reflect, I guess it comes up in OTG mode since we don't parse the host-only or device-only attributes (yet). Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/5 v3] usb: host: fotg2: add device tree probing
From: Hans Ulli Kroll <ulli.kr...@googlemail.com>
Add device tree probing to the fotg2 driver.
Signed-off-by: Hans Ulli Kroll <ulli.kr...@googlemail.com>
Signed-off-by: Linus Walleij <linus.wall...@linaro.org>
---
ChangeLog v2->v3:
- Change compatible to "faraday,fotg210" simply.
---
drivers/usb/host/fotg210-hcd.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/usb/host/fotg210-hcd.c b/drivers/usb/host/fotg210-hcd.c
index 1c5b34b74860..c226041101d1 100644
--- a/drivers/usb/host/fotg210-hcd.c
+++ b/drivers/usb/host/fotg210-hcd.c
@@ -23,6 +23,7 @@
* Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
*/
#include
+#include
#include
#include
#include
@@ -5600,6 +5601,15 @@ static int fotg210_hcd_probe(struct platform_device
*pdev)
if (usb_disabled())
return -ENODEV;
+ /* Right now device-tree probed devices don't get dma_mask set.
+* Since shared usb code relies on it, set it here for now.
+* Once we have dma capability bindings this can go away.
+*/
+
+ retval = dma_coerce_mask_and_coherent(>dev, DMA_BIT_MASK(32));
+ if (retval)
+ goto fail_create_hcd;
+
pdev->dev.power.power_state = PMSG_ON;
res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
@@ -5676,9 +5686,18 @@ static int fotg210_hcd_remove(struct platform_device
*pdev)
return 0;
}
+#ifdef CONFIG_OF
+static const struct of_device_id fotg210_of_match[] = {
+ { .compatible = "faraday,fotg210" },
+ {},
+};
+MODULE_DEVICE_TABLE(of, fotg210_of_match);
+#endif
+
static struct platform_driver fotg210_hcd_driver = {
.driver = {
.name = "fotg210-hcd",
+ .of_match_table = of_match_ptr(fotg210_of_match),
},
.probe = fotg210_hcd_probe,
.remove = fotg210_hcd_remove,
--
2.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/5 v3] ARM: dts: Add the FOTG210 USB host to Gemini
This adds the FOTG210 USB host controller to the Gemini
device trees. In the main SoC DTSI it is flagged as disabled
and then it is selectively enabled on the devices that utilize
it (these per-platform enablements are done on the out-of-tree
OpenWrt patch set). It is not enabled on the Itian SquareOne
NAS/router since this instead has a VIA host controller
soldered on the PCI port, and can gate off these USB host
controllers.
Signed-off-by: Linus Walleij <linus.wall...@linaro.org>
---
USB maintainers: I will merge this through the ARM SoC tree,
the patch is only included in the series for context.
---
arch/arm/boot/dts/gemini-nas4220b.dts | 8
arch/arm/boot/dts/gemini-rut1xx.dts | 8
arch/arm/boot/dts/gemini-wbd111.dts | 8
arch/arm/boot/dts/gemini-wbd222.dts | 8
arch/arm/boot/dts/gemini.dtsi | 22 ++
5 files changed, 54 insertions(+)
diff --git a/arch/arm/boot/dts/gemini-nas4220b.dts
b/arch/arm/boot/dts/gemini-nas4220b.dts
index 7668ba52158e..55059a72aef2 100644
--- a/arch/arm/boot/dts/gemini-nas4220b.dts
+++ b/arch/arm/boot/dts/gemini-nas4220b.dts
@@ -98,5 +98,13 @@
read-only;
};
};
+
+ usb@6800 {
+ status = "okay";
+ };
+
+ usb@6900 {
+ status = "okay";
+ };
};
};
diff --git a/arch/arm/boot/dts/gemini-rut1xx.dts
b/arch/arm/boot/dts/gemini-rut1xx.dts
index 7b920bfbda32..1c253da9f28c 100644
--- a/arch/arm/boot/dts/gemini-rut1xx.dts
+++ b/arch/arm/boot/dts/gemini-rut1xx.dts
@@ -61,5 +61,13 @@
reg = <0x3000 0x0080>;
/* TODO: add flash partitions here */
};
+
+ usb@6800 {
+ status = "okay";
+ };
+
+ usb@6900 {
+ status = "okay";
+ };
};
};
diff --git a/arch/arm/boot/dts/gemini-wbd111.dts
b/arch/arm/boot/dts/gemini-wbd111.dts
index 63b756e3bf5a..c6a5abca0935 100644
--- a/arch/arm/boot/dts/gemini-wbd111.dts
+++ b/arch/arm/boot/dts/gemini-wbd111.dts
@@ -98,5 +98,13 @@
read-only;
};
};
+
+ usb@6800 {
+ status = "okay";
+ };
+
+ usb@6900 {
+ status = "okay";
+ };
};
};
diff --git a/arch/arm/boot/dts/gemini-wbd222.dts
b/arch/arm/boot/dts/gemini-wbd222.dts
index 9747f5a47807..415380262140 100644
--- a/arch/arm/boot/dts/gemini-wbd222.dts
+++ b/arch/arm/boot/dts/gemini-wbd222.dts
@@ -98,5 +98,13 @@
read-only;
};
};
+
+ usb@6800 {
+ status = "okay";
+ };
+
+ usb@6900 {
+ status = "okay";
+ };
};
};
diff --git a/arch/arm/boot/dts/gemini.dtsi b/arch/arm/boot/dts/gemini.dtsi
index 6fe678a68e31..2f8d0381d5eb 100644
--- a/arch/arm/boot/dts/gemini.dtsi
+++ b/arch/arm/boot/dts/gemini.dtsi
@@ -183,5 +183,27 @@
#interrupt-cells = <1>;
};
};
+
+ usb@6800 {
+ compatible = "cortina,gemini-usb", "faraday,fotg210";
+ reg = <0x6800 0x1000>;
+ interrupts = <10 IRQ_TYPE_LEVEL_HIGH>;
+ resets = < 8>;
+ clocks = < GEMINI_CLK_GATE_USB0>;
+ clock-names = "PCLK";
+ syscon = <>;
+ status = "disabled";
+ };
+
+ usb@6900 {
+ compatible = "cortina,gemini-usb", "faraday,fotg210";
+ reg = <0x6900 0x1000>;
+ interrupts = <11 IRQ_TYPE_LEVEL_HIGH>;
+ resets = < 9>;
+ clocks = < GEMINI_CLK_GATE_USB1>;
+ clock-names = "PCLK";
+ syscon = <>;
+ status = "disabled";
+ };
};
};
--
2.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/5 v3] usb: host: fotg2: add silicon clock handling
When used in a system with software-controller silicon clocks,
the FOTG210 needs to grab, prepare and enable the clock.
This is needed on for example the Cortina Gemini, where the
platform will by default gate off the clock unless the
peripheral (in this case the USB driver) grabs and enables
the clock.
Signed-off-by: Linus Walleij <linus.wall...@linaro.org>
---
drivers/usb/host/fotg210-hcd.c | 26 ++
drivers/usb/host/fotg210.h | 3 +++
2 files changed, 25 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/host/fotg210-hcd.c b/drivers/usb/host/fotg210-hcd.c
index c226041101d1..906e42458791 100644
--- a/drivers/usb/host/fotg210-hcd.c
+++ b/drivers/usb/host/fotg210-hcd.c
@@ -45,6 +45,7 @@
#include
#include
#include
+#include
#include
#include
@@ -5635,7 +5636,7 @@ static int fotg210_hcd_probe(struct platform_device *pdev)
hcd->regs = devm_ioremap_resource(>dev, res);
if (IS_ERR(hcd->regs)) {
retval = PTR_ERR(hcd->regs);
- goto failed;
+ goto failed_put_hcd;
}
hcd->rsrc_start = res->start;
@@ -5645,22 +5646,35 @@ static int fotg210_hcd_probe(struct platform_device
*pdev)
fotg210->caps = hcd->regs;
+ /* It's OK not to supply this clock */
+ fotg210->pclk = clk_get(dev, "PCLK");
+ if (!IS_ERR(fotg210->pclk)) {
+ retval = clk_prepare_enable(fotg210->pclk);
+ if (retval) {
+ dev_err(dev, "failed to enable PCLK\n");
+ goto failed_dis_clk;
+ }
+ }
+
retval = fotg210_setup(hcd);
if (retval)
- goto failed;
+ goto failed_dis_clk;
fotg210_init(fotg210);
retval = usb_add_hcd(hcd, irq, IRQF_SHARED);
if (retval) {
dev_err(dev, "failed to add hcd with err %d\n", retval);
- goto failed;
+ goto failed_dis_clk;
}
device_wakeup_enable(hcd->self.controller);
return retval;
-failed:
+failed_dis_clk:
+ if (!IS_ERR(fotg210->pclk))
+ clk_disable_unprepare(fotg210->pclk);
+failed_put_hcd:
usb_put_hcd(hcd);
fail_create_hcd:
dev_err(dev, "init %s fail, %d\n", dev_name(dev), retval);
@@ -5676,6 +5690,10 @@ static int fotg210_hcd_remove(struct platform_device
*pdev)
{
struct device *dev = >dev;
struct usb_hcd *hcd = dev_get_drvdata(dev);
+ struct fotg210_hcd *fotg210 = hcd_to_fotg210(hcd);
+
+ if (!IS_ERR(fotg210->pclk))
+ clk_disable_unprepare(fotg210->pclk);
if (!hcd)
return 0;
diff --git a/drivers/usb/host/fotg210.h b/drivers/usb/host/fotg210.h
index b5cfa7aeb277..c429efeb2b7e 100644
--- a/drivers/usb/host/fotg210.h
+++ b/drivers/usb/host/fotg210.h
@@ -181,6 +181,9 @@ struct fotg210_hcd {/* one per
controller */
# define COUNT(x)
#endif
+ /* silicon clock */
+ struct clk *pclk;
+
/* debug files */
struct dentry *debug_dir;
};
--
2.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/5 v3] usb: host: add DT bindings for faraday fotg2
From: Hans Ulli Kroll <ulli.kr...@googlemail.com>
This adds device tree bindings for the Faraday FOTG2
dual-mode host controller.
Cc: devicet...@vger.kernel.org
Signed-off-by: Hans Ulli Kroll <ulli.kr...@googlemail.com>
Signed-off-by: Linus Walleij <linus.wall...@linaro.org>
---
ChangeLog v1->v3:
- Change compatible to "faraday,fotg210" as the name of the
hardware block.
- Add an elaborate SoC-specific compatible string for the
Cortina Systems Gemini so that SoC-specific features can
be enabled.
- Add cortina,gemini-mini-b to indicate a Gemini PHY with
a Mini-B adapter connected.
- Indicated that the Gemini version can handle "wakeup-source".
- Add optional IP block clock.
---
.../devicetree/bindings/usb/faraday,fotg210.txt| 35 ++
1 file changed, 35 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/faraday,fotg210.txt
diff --git a/Documentation/devicetree/bindings/usb/faraday,fotg210.txt
b/Documentation/devicetree/bindings/usb/faraday,fotg210.txt
new file mode 100644
index ..cf06808303e2
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/faraday,fotg210.txt
@@ -0,0 +1,35 @@
+Faraday FOTG Host controller
+
+This OTG-capable USB host controller is found in Cortina Systems
+Gemini and other SoC products.
+
+Required properties:
+- compatible: should be one of:
+ "faraday,fotg210"
+ "cortina,gemini-usb", "faraday,fotg210"
+- reg: should contain one register range i.e. start and length
+- interrupts: description of the interrupt line
+
+Optional properties:
+- clocks: should contain the IP block clock
+- clock-names: should be "PCLK" for the IP block clock
+
+Required properties for "cortina,gemini-usb" compatible:
+- syscon: a phandle to the system controller to access PHY registers
+
+Optional properties for "cortina,gemini-usb" compatible:
+- cortina,gemini-mini-b: boolean property that indicates that a Mini-B
+ OTH connector is in use
+- wakeup-source: see power/wakeup-source.txt
+
+Example for Gemini:
+
+usb@6800 {
+ compatible = "cortina,gemini-usb", "faraday,fotg210";
+ reg = <0x6800 0x1000>;
+ interrupts = <10 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = < 12>;
+ clock-names = "PCLK";
+ syscon = <>;
+ wakeup-source;
+};
--
2.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/5 v3] usb: host: fotg2: add Gemini-specific handling
The Cortina Systems Gemini has bolted on a PHY inside the
silicon that can be handled by six bits in a MISC register in
the system controller.
If we are running on Gemini, look up a syscon regmap through
a phandle and enable VBUS and optionally the Mini-B connector.
If the device is flagged as "wakeup-source" using the standard
DT bindings, we also enable this in the global controller for
respective port.
Signed-off-by: Linus Walleij <linus.wall...@linaro.org>
---
drivers/usb/host/Kconfig | 1 +
drivers/usb/host/fotg210-hcd.c | 76 ++
2 files changed, 77 insertions(+)
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 407d947b34ea..9750783e5481 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -375,6 +375,7 @@ config USB_ISP1362_HCD
config USB_FOTG210_HCD
tristate "FOTG210 HCD support"
depends on USB && HAS_DMA && HAS_IOMEM
+ select MFD_SYSCON
---help---
Faraday FOTG210 is an OTG controller which can be configured as
an USB2.0 host. It is designed to meet USB2.0 EHCI specification
diff --git a/drivers/usb/host/fotg210-hcd.c b/drivers/usb/host/fotg210-hcd.c
index 906e42458791..146f1eb96b60 100644
--- a/drivers/usb/host/fotg210-hcd.c
+++ b/drivers/usb/host/fotg210-hcd.c
@@ -46,6 +46,10 @@
#include
#include
#include
+#include
+/* For Cortina Gemini */
+#include
+#include
#include
#include
@@ -5583,6 +5587,72 @@ static void fotg210_init(struct fotg210_hcd *fotg210)
iowrite32(value, >regs->otgcsr);
}
+/*
+ * Gemini-specific initialization function, only executed on the
+ * Gemini SoC using the global misc control register.
+ */
+#define GEMINI_GLOBAL_MISC_CTRL0x30
+#define GEMINI_MISC_USB0_WAKEUPBIT(14)
+#define GEMINI_MISC_USB1_WAKEUPBIT(15)
+#define GEMINI_MISC_USB0_VBUS_ON BIT(22)
+#define GEMINI_MISC_USB1_VBUS_ON BIT(23)
+#define GEMINI_MISC_USB0_MINI_BBIT(29)
+#define GEMINI_MISC_USB1_MINI_BBIT(30)
+
+static int fotg210_gemini_init(struct device *dev, struct usb_hcd *hcd)
+{
+ struct device_node *np = dev->of_node;
+ struct regmap *map;
+ bool mini_b;
+ bool wakeup;
+ u32 mask, val;
+ int ret;
+
+ map = syscon_regmap_lookup_by_phandle(np, "syscon");
+ if (IS_ERR(map)) {
+ dev_err(dev, "no syscon\n");
+ return PTR_ERR(map);
+ }
+ mini_b = of_property_read_bool(np, "cortina,gemini-mini-b");
+ wakeup = of_property_read_bool(np, "wakeup-source");
+
+ /*
+* Figure out if this is USB0 or USB1 by simply checking the
+* physical base address.
+*/
+ mask = 0;
+ if (hcd->rsrc_start == 0x6900) {
+ val = GEMINI_MISC_USB1_VBUS_ON;
+ if (mini_b)
+ val |= GEMINI_MISC_USB1_MINI_B;
+ else
+ mask |= GEMINI_MISC_USB1_MINI_B;
+ if (wakeup)
+ val |= GEMINI_MISC_USB1_WAKEUP;
+ else
+ mask |= GEMINI_MISC_USB1_WAKEUP;
+ } else {
+ val = GEMINI_MISC_USB0_VBUS_ON;
+ if (mini_b)
+ val |= GEMINI_MISC_USB0_MINI_B;
+ else
+ mask |= GEMINI_MISC_USB0_MINI_B;
+ if (wakeup)
+ val |= GEMINI_MISC_USB0_WAKEUP;
+ else
+ mask |= GEMINI_MISC_USB0_WAKEUP;
+ }
+
+ ret = regmap_update_bits(map, GEMINI_GLOBAL_MISC_CTRL, mask, val);
+ if (ret) {
+ dev_err(dev, "failed to initialize Gemini PHY\n");
+ return ret;
+ }
+
+ dev_info(dev, "initialized Gemini PHY\n");
+ return 0;
+}
+
/**
* fotg210_hcd_probe - initialize faraday FOTG210 HCDs
*
@@ -5662,6 +5732,12 @@ static int fotg210_hcd_probe(struct platform_device
*pdev)
fotg210_init(fotg210);
+ if (of_device_is_compatible(dev->of_node, "cortina,gemini-usb")) {
+ retval = fotg210_gemini_init(dev, hcd);
+ if (retval)
+ goto failed_dis_clk;
+ }
+
retval = usb_add_hcd(hcd, irq, IRQF_SHARED);
if (retval) {
dev_err(dev, "failed to add hcd with err %d\n", retval);
--
2.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] usb: add DT bindings for farady fotg2 host controller
On Tue, Feb 21, 2017 at 3:43 PM, Rob Herring <r...@kernel.org> wrote: > On Fri, Feb 17, 2017 at 4:07 AM, Hans Ulli Kroll > <ulli.kr...@googlemail.com> wrote: >> Hi Rob, >> >> On Wed, 15 Feb 2017, Rob Herring wrote: >> >>> On Wed, Feb 08, 2017 at 09:00:09PM +0100, Hans Ulli Kroll wrote: >>> > This adds DT bindings for the Faraday FOTG2 host controller. >>> > >>> > Signed-off-by: Hans Ulli Kroll <ulli.kr...@googlemail.com> >>> > --- >>> > Documentation/devicetree/bindings/usb/fotg2-host.txt | 15 +++ >>> > 1 file changed, 15 insertions(+) >>> > create mode 100644 Documentation/devicetree/bindings/usb/fotg2-host.txt >>> > >>> > diff --git a/Documentation/devicetree/bindings/usb/fotg2-host.txt >>> > b/Documentation/devicetree/bindings/usb/fotg2-host.txt >>> > new file mode 100644 >>> > index ..4c07566a4bf5 >>> > --- /dev/null >>> > +++ b/Documentation/devicetree/bindings/usb/fotg2-host.txt >>> > @@ -0,0 +1,15 @@ >>> > +Faraday FOTG Host controller >>> > + >>> > +Required properties: >>> > + >>> > +- compatible: should be "faraday,fotg210-hcd" >>> >>> hcd as in "host controller driver"? Bindings describe h/w not drivers. >>> >>> It's an OTG controller or host controller? >>> >> >> here only the host controller part used. >> >> faraday fotg2 is a dual role hcd/otg device and here is only the >> host part used. > > Because you don't care about device mode or restricted by the IP > configuration or SoC integration? The former is a user choice and > shouldn't be part of DT. The latter should be implied by an SoC > specific compatible string. Using only a compatible string for a > licensed IP is not specific enough as vendors use differing versions > and integrate them in different ways. Hans can you add: compatible = "cortina,gemini-fotg", "faraday,fotg210-hcd" or something as composite compatible for our controller? It's OK for the driver to only match on the latter for now, but for the future it's nice for the driver to know what silicon it is on. This is what I've done for most other Cortina/Gemini stuff. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1] usb: dwc3: pci: Switch to devm_acpi_dev_add_driver_gpios()
On Wed, Mar 22, 2017 at 3:08 PM, Andy Shevchenko <andriy.shevche...@linux.intel.com> wrote: > Switch to use managed variant of acpi_dev_add_driver_gpios() to simplify > error path and fix potentially wrong assignment if ->probe() fails. > > While here, add a debug message in case assignment fails to allow user > see the cause of a potential issue. > > Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com> > --- > > Linus, according to preliminary agreement with Felipe it may go through > GPIO subsystem instead of pulling from it. Patch applied with Felipe's ACK. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] DT: add Faraday Tec. as vendor
On Wed, Feb 8, 2017 at 9:00 PM, Hans Ulli Kroll <ulli.kr...@googlemail.com> wrote: > add Faraday Technology Corporation as vendor faraday for DT > > Signed-off-by: Hans Ulli Kroll <ulli.kr...@googlemail.com> I realized a lot of Gemini IP blocks are actually from Faraday, so now I'm editing the drivers a bit... Rob could you pick this patch directly to the DT tree so we need not worry about the vendor thing? Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] usb: add device tree support for fotg2-hcd driver
On Wed, Feb 8, 2017 at 9:00 PM, Hans Ulli Kroll <ulli.kr...@googlemail.com> wrote: > Add device tree binding and DT driver support for fotg2-hcd controller > The device is used on Gemini SoC. All looks good to me. If you send a patch on top of my git branch adding it to the gemini.dtsi set as status = "disabled"; and gemini-nas4220b.dts mainly just setting status = "okay"; I can merge this on top of the rest of the stuff in my tree that should go upstream to ARM SoC. Yours. Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] usb: add DT bindings for farady fotg2 host controller
On Wed, Feb 8, 2017 at 9:00 PM, Hans Ulli Kroll <ulli.kr...@googlemail.com> wrote: > This adds DT bindings for the Faraday FOTG2 host controller. > > Signed-off-by: Hans Ulli Kroll <ulli.kr...@googlemail.com> Reviewed-by: Linus Walleij <linus.wall...@linaro.org> Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] DT: add Faraday Tec. as vendor
On Wed, Feb 8, 2017 at 9:00 PM, Hans Ulli Kroll <ulli.kr...@googlemail.com> wrote: > add Faraday Technology Corporation as vendor faraday for DT > > Signed-off-by: Hans Ulli Kroll <ulli.kr...@googlemail.com> Reviewed-by: Linus Walleij <linus.wall...@linaro.org> I think I should use this for the PCI block as well, looking over some code and the root hub is using Faraday's PCI ID. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3 v2] usb: host: fotg2: add device tree probing
On Thu, Feb 9, 2017 at 3:20 PM, Hans Ulli Kroll <ulli.kr...@googlemail.com> wrote: > Add device tree probe for fotg2 driver > > v2: > fix in wrong MODULE_DEVICE_TABLE > > Signed-off-by: Hans Ulli Kroll <ulli.kr...@googlemail.com> Acked-by: Linus Walleij <linus.wall...@linaro.org> > + /* Right now device-tree probed devices don't get dma_mask set. > +* Since shared usb code relies on it, set it here for now. > +* Once we have dma capability bindings this can go away. > +*/ > + > + retval = dma_coerce_mask_and_coherent(>dev, DMA_BIT_MASK(32)); > + if (retval) > + goto fail_create_hcd; Were you able to test this part? I saw the gemini has some DMA engine but I never saw a driver for it. It looks like a reasonable thing to do to my untrained DMA eye. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v10 1/1] USB: serial: cp210x: Adding GPIO support for CP2105
On Wed, Oct 26, 2016 at 11:09 AM, Johan Hovold <jo...@kernel.org> wrote: > On Tue, Oct 25, 2016 at 11:34:40AM +0200, Linus Walleij wrote: >> I was thinking on either reusing the .names field of the >> struct gpiochip to name the lines for the userspace >> chardev. With the sideeffect of the names getting reflected >> also to sysfs if using that. > > Simply reusing .names would cause problems since the old sysfs name > space is flat, so you would be unable to use more than one pluggable > expander (unless also encoding the topology in the name). Hm it seems we should actually #ifdef that field for sysfs then, it has no applicability outside the legacy sysfs. > Providing default names from the driver could perhaps be useful at > times. For this particular chip the names would still be GPIO_0, GPIO_1 > and GPIO_2 (possibly with a suffix depending on which of the two > controllers they hang off of) however, which may not be much better than > using chip->base + offset. I'd assume this to be the common case. The chardev names are pertaining to a certain device like "gpiochip1" already so the names only need to be unique per-instance. If we made them globally unique we could just use the .names in gpiochip anyways, but that seems ugly. What about suppling gpiochip_set_names(struct gpio_chip *gc, char **names); As the size of the array is implicit from ngpios and the function would be kernel-internal anyways. > Device-tree overlays is what I see a real use for where different > overlays can be applied based on topology data to describe what is > actually connected to a pin in a specific setup. And that seems like > something that could be useful for normal (static) DT systems as well > (e.g. describe what's actually connected to those Beaglebone pins). Yeah these overlays ... discussed that a lot recently. It fits the Beaglebone indeed. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v10 1/1] USB: serial: cp210x: Adding GPIO support for CP2105
Good work on this patch, nice that it got merged. I was just thinking that as an add-on, you may want to name the gpio lines so they have meaningful names in userspace when you use this with the chardev (I have reasons to believe these GPIOs will be used from userspace, tell me if that is wrong). We currently support naming lines for devicetree and ACPI (in -next). I was thinking on either reusing the .names field of the struct gpiochip to name the lines for the userspace chardev. With the sideeffect of the names getting reflected also to sysfs if using that. We could otherwise add a special function to name the lines from drivers like this that hang off a pluggable bus. Johan/Martyn what is your idea? Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [balbi-usb:testing/next 57/84] drivers/usb/dwc3/dwc3-st.c:328:2: error: implicit declaration of function 'pinctrl_pm_select_sleep_state'
On Mon, Oct 17, 2016 at 1:50 PM, Felipe Balbi <felipe.ba...@linux.intel.com> wrote: > kbuild test robot <fengguang...@intel.com> writes: >> tree: https://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git >> testing/next >> head: 4281ef86fae986e0a9bb553fb311fe6d8e039118 >> commit: 040f47e7330045feaa8c06bf2900db2eb2038e80 [57/84] usb: dwc3: Kconfig: >> allow all glues to build if COMPILE_TEST >> config: blackfin-allmodconfig (attached as .config) >> compiler: bfin-uclinux-gcc (GCC) 6.2.0 >> reproduce: >> wget >> https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross >> -O ~/bin/make.cross >> chmod +x ~/bin/make.cross >> git checkout 040f47e7330045feaa8c06bf2900db2eb2038e80 >> # save the attached .config to linux build tree >> make.cross ARCH=blackfin >> >> All errors (new ones prefixed by >>): >> >>drivers/usb/dwc3/dwc3-st.c: In function 'st_dwc3_suspend': >>>> drivers/usb/dwc3/dwc3-st.c:328:2: error: implicit declaration of function >>>> 'pinctrl_pm_select_sleep_state' [-Werror=implicit-function-declaration] >> pinctrl_pm_select_sleep_state(dev); >> ^ >>drivers/usb/dwc3/dwc3-st.c: In function 'st_dwc3_resume': >>>> drivers/usb/dwc3/dwc3-st.c:338:2: error: implicit declaration of function >>>> 'pinctrl_pm_select_default_state' [-Werror=implicit-function-declaration] >> pinctrl_pm_select_default_state(dev); >> ^~~ >>cc1: some warnings being treated as errors > > looks like a bug in . Something along the > lines of below should be enough: I don't think so, that include file looks pretty solid. I think the actual problem is that dwc3-st.c doesn't #include even if it is using the functions from it. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 1/1] USB: serial: cp210x: Adding GPIO support for CP2105
On Mon, Oct 10, 2016 at 3:39 PM, Martyn Welch <martyn.we...@collabora.co.uk> wrote: > This patch adds support for the GPIO found on the CP2105. Unlike the GPIO > provided by some of the other devices supported by the cp210x driver, the > GPIO on the CP2015 is muxed on pins otherwise used for serial control > lines. The GPIO have been configured in 2 separate banks as the choice to > configure the pins for GPIO is made separately for pins shared with each > of the 2 serial ports this device provides, though the choice is made for > all pins associated with that port in one go. The choice of whether to use > the pins for GPIO or serial is made by adding configuration to a one-time > programable PROM in the chip and can not be changed at runtime. The device > defaults to GPIO. > > This device supports either push-pull or open-drain modes, it doesn't > provide an explicit input mode, though the state of the GPIO can be read > when used in open-drain mode. Like with pin use, the mode is configured in > the one-time programable PROM and can't be changed at runtime. > > Signed-off-by: Martyn Welch <martyn.we...@collabora.co.uk> (...) > V7: - Using GPIO private data for GPIO bits. > - Adding limited .set_single_ended() and direction support. > - Simplifying attach() and removing release() as it's no longer required. >From a GPIO point of view: Reviewed-by: Linus Walleij <linus.wall...@linaro.org> Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 1/1] USB: serial: cp210x: Adding GPIO support for CP2105
On Fri, Oct 7, 2016 at 5:31 PM, Martyn Welch <martyn.we...@collabora.co.uk> wrote: > WRT this driver, I think I need to keep set_single_ended, but change > .direction_input > to always return a failure and have .direction_output always return success to > avoid pins being driven in unexpected ways. Does that sould acceptable? I'm pretty sure it's OK, I just want you to consider and think these things over. Your conclusion is as good as mine. I suspect I will just ACK your patch when you have it working. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 1/1] USB: serial: cp210x: Adding GPIO support for CP2105
On Sat, Sep 24, 2016 at 12:50 AM, Martyn Welch
<martyn.we...@collabora.co.uk> wrote:
> This patch adds support for the GPIO found on the CP2105.
> This device supports either push-pull or open-drain modes, it doesn't
> provide an explicit input mode, though the state of the GPIO can be read
> when used in open-drain mode. Like with pin use, the mode is configured in
> the one-time programable PROM and can't be changed at runtime.
I see.
So implement .direction_input() and .direction_output()
anyways.
Return failure on .direction_input() if it is in push-pull mode.
Return success on all .direction_output() calls.
Then implement .set_single_ended() and return success for open drain
if the is in open drain, success for push-pull if the line is in push-pull
mode, and failure in all other cases. Simple, but correct.
Add some comments to these functions so it is clear what is going on.
(...)
> +#ifdef CONFIG_GPIOLIB
> +static int cp210x_gpio_request(struct gpio_chip *gc, unsigned int offset)
> +{
> + struct cp210x_serial_private *priv =
> + container_of(gc, struct cp210x_serial_private, gc);
Just:
struct cp210x_serial_private *priv = gpiochip_get_data(gc);
> +static int cp210x_gpio_direction_get(struct gpio_chip *gc, unsigned int gpio)
> +{
> + return 0;
> +}
Aha no explicit input mode...
> +static int cp210x_gpio_get(struct gpio_chip *gc, unsigned int gpio)
> +{
> + struct cp210x_serial_private *priv =
> + container_of(gc, struct cp210x_serial_private, gc);
gpiochip_get_data
> + struct usb_serial *serial = priv->serial;
> + int result;
> + u8 buf;
> +
> + result = cp210x_read_vendor_block(serial, REQTYPE_INTERFACE_TO_HOST,
> + CP210X_READ_LATCH, ,
> sizeof(buf));
> + if (result < 0)
> + return 0;
No just return the error code. We handle this nowadays.
> +
> + return (buf >> gpio) & 0x1;
Do it like this:
return !!(buf & BIT(gpio));
> +static void cp210x_gpio_set(struct gpio_chip *gc, unsigned int gpio, int
> value)
> +{
> + struct cp210x_serial_private *priv =
> + container_of(gc, struct cp210x_serial_private, gc);
gpiochip_get_data()
(...)
+ result = gpiochip_add(>gc);
Use devm_gpiochip_add_data(>interface->dev, >gc, gc);
And you get the pointer you need.
+void cp210x_shared_gpio_remove(struct usb_serial *serial)
+{
+ struct cp210x_serial_private *priv = usb_get_serial_data(serial);
+
+ if (priv->gc.label)
+ gpiochip_remove(>gc);
+}
Should not be needed with the devm_* call above doing garbage collection.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND PATCH v5 1/1] USB: serial: cp210x: Adding GPIO support for CP2105
On Fri, Jul 22, 2016 at 12:33 PM, Martyn Welch <martyn.we...@collabora.co.uk> wrote: > This patch adds support for the GPIO found on the CP2105. Unlike the GPIO > provided by some of the other devices supported by the cp210x driver, the > GPIO on the CP2015 is muxed on pins otherwise used for serial control > lines. The GPIO have been configured in 2 separate banks as the choice to > configure the pins for GPIO is made separately for pins shared with each > of the 2 serial ports this device provides, though the choice is made for > all pins associated with that port in one go. The choice of whether to use > the pins for GPIO or serial is made by adding configuration to a one-time > programable PROM in the chip and can not be changed at runtime. The device > defaults to GPIO. > > This device supports either push-pull or open-drain modes, it doesn't > provide an explicit input mode, though the state of the GPIO can be read > when used in open-drain mode. Like with pin use, the mode is configured in > the one-time programable PROM and can't be changed at runtime. > > Signed-off-by: Martyn Welch <martyn.we...@collabora.co.uk> > Acked-by: Linus Walleij <linus.wall...@linaro.org> Still stands. > V2: - Doesn't break build when gpiolib isn't selected. Nowadays I have changed the kernel so the driver can actually select GPIOLIB, any arch supports it now. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/6] pinctrl: mt8173: set GPIO16 to usb iddig mode
On Tue, May 10, 2016 at 10:23 AM, Chunfeng Yun <chunfeng@mediatek.com> wrote: > the default mode of GPIO16 pin is gpio, when set EINT16 to > IRQ_TYPE_LEVEL_HIGH, no interrupt is triggered, it can be > fixed when set its default mode as usb iddig. > > Signed-off-by: Chunfeng Yun <chunfeng@mediatek.com> This looks like it can be merged orthogonally to all the other patches, but I don't understand the patch or if it is correct. Hongzhou/Yingjoe, can either of you review this patch? Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v10 4/9] phy: Add Tegra XUSB pad controller support
On Mon, Apr 18, 2016 at 1:43 PM, Thierry Reding
<thierry.red...@gmail.com> wrote:
> On Fri, Mar 04, 2016 at 05:19:34PM +0100, Thierry Reding wrote:
>> -MODULE_LICENSE("GPL v2");
>> +EXPORT_SYMBOL_GPL(tegra_xusb_padctl_legacy_remove);
>
> Since this merely implements the binding change, does your Acked-by on
> the binding apply to this part as well?
Sure
Acked-by: Linus Walleij <linus.wall...@linaro.org>
Sorry for missing to reply to this, have been swamped.
Basically I trust anything that you and Stephen agree on.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v10 2/9] dt-bindings: pinctrl: Deprecate Tegra XUSB pad controller binding
On Mon, Apr 18, 2016 at 1:12 PM, Thierry Reding <thierry.red...@gmail.com> wrote: > On Tue, Mar 15, 2016 at 10:01:25AM +0100, Linus Walleij wrote: >> On Fri, Mar 4, 2016 at 5:19 PM, Thierry Reding <thierry.red...@gmail.com> >> wrote: >> >> > From: Thierry Reding <tred...@nvidia.com> >> > >> > This is an old version of the binding that isn't flexible enough to >> > describe all aspects of the XUSB pad controller. Specifically with the >> > addition of XUSB support (for SuperSpeed USB) the existing binding is >> > no longer suitable. >> > >> > Signed-off-by: Thierry Reding <tred...@nvidia.com> >> >> That's unfortunate, not to say unelegant. I want to know Stephen's >> opinion on these patches (probably they are in another mail) >> before merging. >> >> Will the new binding also work with SuperDuperSpeed USB and >> SuperSuperMegaUltraOrtonSpeed USB I wonder... or will we >> change the bindings again? > > Linus, Stephen's gave his Acked-by on this patch (provided it gets > merged into patch 1/9, which I've done locally), would you be willing to > give your Acked-by so that this change can go in via the PHY tree where > the new bindings are introduced? Yes I trust Stephen to know what's right for Tegra. Acked-by: Linus Walleij <linus.wall...@linaro.org> Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 1/2] USB: serial: cp210x: Adding GPIO support for CP2105
On Tue, Mar 29, 2016 at 6:47 PM, Martyn Welch <martyn.we...@collabora.co.uk> wrote: > This patch adds support for the GPIO found on the CP2105. Unlike the GPIO > provided by some of the other devices supported by the cp210x driver, the > GPIO on the CP2015 is muxed on pins otherwise used for serial control > lines. The GPIO have been configured in 2 separate banks as the choice to > configure the pins for GPIO is made separately for pins shared with each > of the 2 serial ports this device provides, though the choice is made for > all pins associated with that port in one go. The choice of whether to use > the pins for GPIO or serial is made by adding configuration to a one-time > programable PROM in the chip and can not be changed at runtime. The device > defaults to GPIO. > > This device supports either push-pull or open-drain modes, it doesn't > provide an explicit input mode, though the state of the GPIO can be read > when used in open-drain mode. Like with pin use, the mode is configured in > the one-time programable PROM and can't be changed at runtime. > > Signed-off-by: Martyn Welch <martyn.we...@collabora.co.uk> Looking good from a GPIO point of view. Acked-by: Linus Walleij <linus.wall...@linaro.org> Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v10 1/9] dt-bindings: phy: Add NVIDIA Tegra XUSB pad controller binding
On Fri, Mar 4, 2016 at 5:19 PM, Thierry Reding <thierry.red...@gmail.com> wrote: > From: Thierry Reding <tred...@nvidia.com> > > The NVIDIA Tegra XUSB pad controller provides a set of pads, each with a > set of lanes that are used for PCIe, SATA and USB. > > Signed-off-by: Thierry Reding <tred...@nvidia.com> > --- > Changes in v10: > - clarify that the hardware documentation means something different when > referring to a "port" (intra-SoC connectivity) Thierry I'm a bit out of sync, so can you resend these patches with collected ACKs after -rc1? Please send me the patches I can just merge into the pinctrl tree separately if possible, I encourage any DTS changes to go in orthogonally through ARM SoC. The DTS business I regard as kind of its own tree. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] pinctrl: Intel: add RX invertion config
On Wed, Mar 16, 2016 at 2:34 PM, Daniel Vetter <dan...@ffwll.ch> wrote: > On Wed, Mar 16, 2016 at 01:27:49PM +0100, Linus Walleij wrote: >> - What is a HPD interrupt? > > hotplug interrupt, fires when you plug in a cable. > >> - What is a Type-C DP HPD? > > usb type C connector can multiplex both DisplayPort and USB, you need to > renegotiate the lane splitting every time the sink changes, i.e. on each > hotplug. OK I understand, thanks a lot! >> - Again why can't you just use a notifier or function call? > > Because windows sucks, hence all that coordination happens through hw > forwarded interrupts and magic registers. Same horror story on the sound > side, where the sound driver needs to know what kind of PCM stream the > monitor can take. It's hilarious. Except when they screw up the design and > then need to fake parts of it in software. So the story is something like that these IRQs have been put into hardware in order to compensate for flaws in Windows device driver model, I see. If there are such special registers in some hardware I guess I'm all for implementing some generic quirk in gpiolib for people who need to software-trigger GPIO IRQs. Could be good for testing too, as there are such registers in ARMs PL061 GPIO controller for test, just so as to simulate a GPIO IRQ. gpiod_trig_irq() would work with me, I'm happy to support whatever the GPIO hardware can do usually. > In sound we've switched over to a proper sw interface, and we tie the > different parts (drm graphics driver and alsa snd driver) using the > component.c framework. Hm is that solution or something similar proper for USB connector as well I wonder... I was thinking about just adding $random_notifier but maybe that is a bit ugly :/ >> What is VPG? Now it seems Intel's internal organization is being used as >> part of the argument to get this change in and that makes me a bit >> annoyed. (...) > There was chat of usb type C support for forever, but I was always > promised that we don't need any interactions on the sw side and it's all > magic in hw. There hasn't been any real design discussions in the open > source group. VPG is the hw/windows group and generally comes up with > "interesting" designs not suitable for upstream. > > Feel free to just nack this stuff, and please cc intel-gfx/dri-devel in > the future (since I tend to ignore everything that's not cc'ed to mailing > lists I don't care about, even when I'm on cc personally). I've added them > all to cc. Thanks a lot Daniel, I understand better now. I'm not really against adding this "interesting" workaround if that is how Windows works, we usually have to go by their standards. From the GPIO point of view it is OK, just something the GPIO can do. I would be more worried about what the USB PHY maintainer (Felipe) is going to say about this. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v10 3/9] dt-bindings: phy: tegra-xusb-padctl: Add Tegra210 support
On Fri, Mar 4, 2016 at 5:19 PM, Thierry Reding <thierry.red...@gmail.com> wrote: > From: Thierry Reding <tred...@nvidia.com> > > Extend the binding to cover the set of feature found in Tegra210. > > Signed-off-by: Thierry Reding <tred...@nvidia.com> Again I'd like Stephen's ACK on this to keep things together, thanks. Please resend the pinctrl patches to me after v4.6-rc1 with the apropriate ACKs (hoping they will appear). Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v10 2/9] dt-bindings: pinctrl: Deprecate Tegra XUSB pad controller binding
On Fri, Mar 4, 2016 at 5:19 PM, Thierry Reding <thierry.red...@gmail.com> wrote: > From: Thierry Reding <tred...@nvidia.com> > > This is an old version of the binding that isn't flexible enough to > describe all aspects of the XUSB pad controller. Specifically with the > addition of XUSB support (for SuperSpeed USB) the existing binding is > no longer suitable. > > Signed-off-by: Thierry Reding <tred...@nvidia.com> That's unfortunate, not to say unelegant. I want to know Stephen's opinion on these patches (probably they are in another mail) before merging. Will the new binding also work with SuperDuperSpeed USB and SuperSuperMegaUltraOrtonSpeed USB I wonder... or will we change the bindings again? Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: musb: ux500: Fix NULL pointer dereference at system PM
On Mon, Jan 25, 2016 at 1:01 PM, Ulf Hansson <ulf.hans...@linaro.org> wrote:
> The commit 7d32cdef5356 ("usb: musb: fail with error when no DMA
> controller set"), caused the core platform driver to correctly return an
> error code when fail probing.
>
> Unfurtante it also caused bug for a NULL pointer dereference, during
> system suspend for the ux500 driver. The reason is a lacking validation
> of the corresponding ->driver_data pointer, which won't be set when the
> musb core driver fails to probe (or haven't yet been probed).
>
> Fixes: 7d32cdef5356 ("usb: musb: fail with error when no DMA...")
> Signed-off-by: Ulf Hansson <ulf.hans...@linaro.org>
Acked-by: Linus Walleij <linus.wall...@linaro.org>
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] gpio: rcar: Remove obsolete platform data support
On Wed, Oct 7, 2015 at 10:23 AM, Geert Uytterhoeven
<geert+rene...@glider.be> wrote:
> Hi Greg, Linus, Alexandre,
>
> Since commit 4baadb9e05c68962 ("ARM: shmobile: r8a7778: remove obsolete
> setup code"), which is now in arm-soc/for-next, Renesas R-Car SoCs are
> only supported in generic DT-only ARM multi-platform builds. The driver
> doesn't need to use platform data anymore, hence this driver removes
> platform data configuration.
>
> Unfortunately the platform data header file is used in a few other
> places, so we have to fix these first to avoid breaking the build.
Acked-by: Linus Walleij <linus.wall...@linaro.org>
Include this in your pull request.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] pinctrl: sh-pfc: Stop including
On Wed, Oct 7, 2015 at 10:23 AM, Geert Uytterhoeven <geert+rene...@glider.be> wrote: > This header file will be removed soon. > > Copy the helper macro RCAR_GP_PIN(), which is used by the pinctrl > drivers only, to sh_pfc.h, and drop the #include. > > Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be> Acked-by: Linus Walleij <linus.wall...@linaro.org> Include this in your pull request to me. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] USB: ftdi_sio: add GPIO support
On Sat, Jul 4, 2015 at 12:13 AM, Grant Likely grant.lik...@secretlab.ca wrote: On Tue, Jun 2, 2015 at 2:18 PM, Linus Walleij linus.wall...@linaro.org wrote: On Sat, May 30, 2015 at 10:29 PM, Grant Likely grant.lik...@secretlab.ca wrote: On Mon, Jul 7, 2014 at 6:31 PM, Greg Kroah-Hartman gre...@linuxfoundation.org wrote: However is the MFD cell approach acceptable? Yes it is. Going back to this old conversation... Actually, I disagree. There is absolutely no need to go the MFD approach for this driver. That just adds layers of abstraction for no purpose. GPIOLIB is an interface, and it is completely fine for a driver to hook up to the GPIOLIB interface at the same time as exposing a serial port. MFD doesn't buy the driver anything useful here. What is buys is centralizing code into the proper drivers/gpio folder of the kernel. So more of a maintenance point than a mechanics/performance point. We do have GPIO drivers scattered all over the kernel so one more or less wouldn't matter so much... Yeah, I would say that's a non-reason. When it comes to a single device, it is far better in my opinion to have the entire driver located together rather than splitting it up into parts so that each part lives with it's subsystem. We've got tools for find users of interfaces, whereas spliting a driver up can make maintenance a lot more complicated. Yeah I already gave up on this in some other thread :D Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] gpio: gpio-ftdi-cbus: add driver for FTDI CBUS GPIOs
On Sun, Jun 21, 2015 at 12:12 AM, Stefan Agner ste...@agner.ch wrote:
This driver allows to use the CBUS pins, e.g. CBUS 0-3 on FT232R
type of devices. Note that the pins need to be configured first
by using I/O mode signal option in the EEPROM. This is _not_ the
factory default configuration of any of the four pins.
See also FTDI's Application Note AN_232R-01.
Signed-off-by: Stefan Agner ste...@agner.ch
I see no big problems with this driver but I guess the serial portions
are the controversial parts.
+++ b/drivers/gpio/gpio-ftdi-cbus.c
@@ -0,0 +1,167 @@
+/*
+ * gpiolib support for FTDI SIO chips supporting CBUS GPIO's (FT232R class)
+ *
+ * Copyright 2015 Stefan Agner
+ *
+ * Author: Stefan Agner ste...@agner.ch
+ *
+ * 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.
+ *
+ * Note: To use the GPIOs on CBUS the signal option need to be set to
+ * I/O mode in EEPROM!
+ */
+
+#include linux/kernel.h
+#include linux/slab.h
+#include linux/module.h
+#include linux/gpio.h
#include linux/gpio/driver.h
should be enough.
+static int ftdi_cbus_gpio_direction_input(struct gpio_chip *chip,
+ unsigned offset)
+{
+ struct ftdi_cbus_gpio *fcg = to_ftdi_cbus_gpio(chip);
+
+ fcg-cbus_mask = ~((1 offset) 4);
I usually replace:
(1 offset)
with
#include linux/bitops.h
BIT(offset)
so it's clear what is happening.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] USB: ftdi_sio: add CBUS mode for FT232R devices
On Sun, Jun 21, 2015 at 12:12 AM, Stefan Agner ste...@agner.ch wrote: Add interface to allow CBUS access. The functions set_bitmode and read_pins use control transfers only hence should not interfere with the serial operation mode. Signed-off-by: Stefan Agner ste...@agner.ch Interesting. Waiting for Johan's review on both patches. Need his or Greg's ACK on patch 1 if I should merge through the GPIO tree. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: dwc3: pci: make better use of gpiod API
On Fri, Jun 12, 2015 at 9:10 AM, Uwe Kleine-König u.kleine-koe...@pengutronix.de wrote: Since 39b2bbe3d715 (gpio: add flags argument to gpiod_get*() functions) which appeared in v3.17-rc1, the gpiod_get* functions take an additional parameter that allows to specify direction and initial value for output. Furthermore there is devm_gpiod_get_optional which is designed to get optional gpios. Also use devm_gpiod_get* because otherwise the gpio might be grabbed by a different driver. Simplify driver accordingly. Signed-off-by: Uwe Kleine-König u.kleine-koe...@pengutronix.de Acked-by: Linus Walleij linus.wall...@linaro.org Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/21] On-demand device registration
On Sat, Jun 13, 2015 at 8:27 PM, Alexander Holler hol...@ahsoftware.de wrote: And because you've said that problem space is a bit convoluted and I disagree, here's a summary from my point of view: 1. All the necessary information (dependencies between drivers) already exists at compile time. The set of dependencies between drivers might become smaller by configuration, but will not become larger. So there should be NO need to collect them at runtime, e.g. by instrumenting function calls. I think you arrived at the core of the crux here. When we look up a resource provided from another driver, e.g. from regulator_get(), clk_get(), pinctrl_get(), gpiod_get() etc - the dependency is resolved by looking in a cross-reference table for either a struct device* pointer or a string, an index, or both or all three. Examples: struct regulator *regulator_get(struct device *dev, const char *id); struct clk *clk_get(struct device *dev, const char *id); struct gpio_desc *__must_check __gpiod_get(struct device *dev, const char *con_id, enum gpiod_flags flags); (...) (*_index() variants exist on some of the resource retrieveal functions.) struct device * is the device requesting the resource, con_id is the string name of the resource on the provider side. This is all solved by looking in cross reference tables. ONE way of resolving that cross reference is to look into the device tree or the ACPI table. But for the board file case, this is resolved at runtime by the cross reference table, registered with calls such as gpiod_add_lookup_table(). It is true that in the theoretical sense, all of this exist at compile time especially if you can parse something like a device tree and figure out what struct device * nodes will correspond to the struct device_node:s in it. For ACPI I guess a similar procedure is viable. Problem: this requires the kernel compile to know exactly *which* device tree or ACPI table it is going to boot on. The expressed goal of device tree and ACPI is to have *ONE* kernel booting several device trees. Here your approach stops short: you are suggesting instrumenting the kernel at compile time to one single device tree or ACPI table. But we never know really what device tree or ACPI table will be used. This just cannot be done at compile time for that reason alone. Example: in boot case (A) the regulator may be provided by regulator foo driver on an i2c bus. But in boot case (B) the very same regulator may be provided by regulator bar on an SPI bus. These are very real usecases, for example for drivers/net/ethernet/smsc/smsc911x.c, will get regulators from the most diverse places depending on what device tree is used. For board files, it is neither possible in theory: you need to compile the code to figure out the struct device * provider, and/or the string name of the providing device (.name field in struct device for the provider) to resolve dependencies at compile time. For the board file case, resolving dependencies at compile time will require a quite complex two-stage rocket: compile the code to get resources out, then recompile with known resources. I guess your suggested approach then need to introduce a special build tool to order the initcalls accordingly. Again this will fall short if you don't know at compile time exactly *which* board file will be executed. So the only practical way to solve this at compile time is to predict an initcall ordering sequence for all possible boot paths, compile in all of them, and choose the right one at boot. But the number of boot paths is equal to the number of device trees / ACPI tables or board files supported, and that space is uncontrolled and ordered infinite. Basically I think the root problem with your approach is that you assume we know what hardware we will boot on at compile time. We discarded that development path years ago. We have no clue, this is resolved at runtime. Alas, people still create super-optimized systems using exactly this knowledge, but it is not our main target here, it is a special optimization case. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/21] On-demand device registration
On Wed, Jun 10, 2015 at 12:19 PM, Tomeu Vizoso tomeu.viz...@collabora.com wrote: On 10 June 2015 at 09:30, Linus Walleij linus.wall...@linaro.org wrote: regulator_get(...) - not available, so: - identify target regulator provider - this will need instrumentation - probe it It then turns out the regulator driver is on the i2c bus, so we need to probe the i2c driver: - identify target i2c host for the regulator driver - this will need instrumentation - probe the i2c host driver i2c host comes out, probes the regulator driver, regulator driver probes and then the regulator_get() call returns. Hmm, if I understand correctly what you say, this is exactly what this particular series does: regulator_get - of_platform_device_ensure - probe() on the platform device that encloses the requested device node (i2c host) - i2c slave gets probed and the regulator registered - regulator_get returns the requested resource Yes. But only for device tree. The downside I'm currently looking at is that an explicit dependency graph would be useful to have for other purposes. For example to print a neat warning when a dependency cannot be fulfilled. Or to refuse to unbind a device which other devices depend on, or to automatically unbind the devices that depend on it, or to print a warning if a device is hotplugged off and other devices depend on it. Unbind/remove() calls are the inverse usually yes. But also the [runtime] power up/down sequences for the devices tend to depend on a similar ordering or mostly the same. (Mentioned this before I think.) This requires instrumentation on anything providing a resource to another driver like those I mentioned and a lot of overhead infrastructure, but I think it's the right approach. However I don't know if I would ever be able to pull that off myself, I know talk is cheap and I should show the code instead. Yeah, if you can give it a second look and say if it matches what you wrote above, it would be very much appreciated. Yes you are right. But what about ACPI, board files, Simple Firmware and future hardware description languages... Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/21] On-demand device registration
On Tue, Jun 2, 2015 at 12:14 PM, Tomeu Vizoso tomeu.viz...@collabora.com wrote: On 2 June 2015 at 10:48, Linus Walleij linus.wall...@linaro.org wrote: This is what systemd is doing in userspace for starting services: ask for your dependencies and wait for them if they are not there. So drivers ask for resources and wait for them. It also needs to be abstract, so for example we need to be able to hang on regulator_get() until the driver is up and providing that regulator, and as long as everything is in slowpath it should be OK. (And vice versa mutatis mutandis for clk, gpio, pin control, interrupts (!) and DMA channels for example.) I understood above that you propose probing devices in order, but now you mention that resource getters would block until the dependency is fulfilled which confuses me because if we are probing in order then all dependencies would be fulfilled before the device in question gets probed. Sorry, the problem space is a bit convoluted so the answers get a bit convoluted. Maybe I'm thinking aloud and altering the course of my thoughts as I type... I guess there can be explicit dependencies for resources like this patch does, but another way would be for all resource fetch functions to be instrumented, so that you do not block until you try to take a resource that is not yet there, e.g.: regulator_get(...) - not available, so: - identify target regulator provider - this will need instrumentation - probe it It then turns out the regulator driver is on the i2c bus, so we need to probe the i2c driver: - identify target i2c host for the regulator driver - this will need instrumentation - probe the i2c host driver i2c host comes out, probes the regulator driver, regulator driver probes and then the regulator_get() call returns. This requires instrumentation on anything providing a resource to another driver like those I mentioned and a lot of overhead infrastructure, but I think it's the right approach. However I don't know if I would ever be able to pull that off myself, I know talk is cheap and I should show the code instead. Deepest respect for your efforts! Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/21] On-demand device registration
On Mon, May 25, 2015 at 4:53 PM, Tomeu Vizoso tomeu.viz...@collabora.com wrote: have looked into ordered probing as a better way of solving this than moving nodes around in the DT or playing with initcall levels. While reading the thread [1] that Alexander Holler started with his series to make probing order deterministic, it occurred to me that it should be possible to achieve the same by registering devices as they are referenced by other devices. This is pretty cool, but a too local solution to a global problem. Deferred probe and initcall reordering, silly as they may seem, does not require you to use device tree. The real solution, which I think I pointed out already when we added deferred probe, is to put dependency graphs in the drivers and have the kernel device driver core percolate dependecies by walking the graph on probing driver, removing driver (usually the inverse use case), [runtime] suspend and [runtime] resumeing a driver. Possibly the dependencies will even be different depending on use case. This is what systemd is doing in userspace for starting services: ask for your dependencies and wait for them if they are not there. So drivers ask for resources and wait for them. It also needs to be abstract, so for example we need to be able to hang on regulator_get() until the driver is up and providing that regulator, and as long as everything is in slowpath it should be OK. (And vice versa mutatis mutandis for clk, gpio, pin control, interrupts (!) and DMA channels for example.) So if this should be solved it should be solved in an abstract way in the device driver core available for all, then have calls calling out to DT, ACPI, possibly even PCI or USB (as these enumerate devices themselves) to obtain a certain dependency. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] USB: ftdi_sio: add GPIO support
On Sat, May 30, 2015 at 10:29 PM, Grant Likely grant.lik...@secretlab.ca wrote: On Mon, Jul 7, 2014 at 6:31 PM, Greg Kroah-Hartman gre...@linuxfoundation.org wrote: However is the MFD cell approach acceptable? Yes it is. Going back to this old conversation... Actually, I disagree. There is absolutely no need to go the MFD approach for this driver. That just adds layers of abstraction for no purpose. GPIOLIB is an interface, and it is completely fine for a driver to hook up to the GPIOLIB interface at the same time as exposing a serial port. MFD doesn't buy the driver anything useful here. What is buys is centralizing code into the proper drivers/gpio folder of the kernel. So more of a maintenance point than a mechanics/performance point. We do have GPIO drivers scattered all over the kernel so one more or less wouldn't matter so much... Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8 4/9] mfd: Add binding document for NVIDIA Tegra XUSB
On Wed, May 20, 2015 at 4:52 PM, Thierry Reding
thierry.red...@gmail.com wrote:
I'm a little confused by the simple-mfd approach. The only code I see in
linux-next for this is a single line that adds the simple-mfd string
to the OF device ID table in drivers/of/platform.c. As far as I can tell
this will merely cause child devices to be created. There won't be a
shared regmap and resources won't be set up properly either.
That is correct. The simple-mfd is a two-component approach.
Ideally, in the simplest case, you combine simple-mfd with syscon.
foo@0 {
compatible = foo, syscon, simple-mfd;
reg = 0x1000 0x1000;
bar@1 {
compatible = bar;
};
baz@2 {
compatible = baz;
};
};
This will instantiate bar and baz.
These subdrivers then probe and:
probe() {
struct regmap *map;
map = syscon_node_to_regmap(parent-of_node);
(...)
}
Simple, syscon is the MFD hub.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] extcon: otg_gpio: add driver for USB OTG port controlled by GPIO(s)
On Fri, Feb 20, 2015 at 8:17 PM, David Cohen david.a.co...@linux.intel.com wrote: On Fri, Feb 20, 2015 at 10:53:44AM +0100, Linus Walleij wrote: I would put this adjacent to the phy driver somewhere in drivers/usb/* and make the actual USB-driver thing handle its GPIOs directly. But I guess David and Felipe have already discussed that as we're seeing this patch? - The mux functions would be controlled by a possible new pinctrl-gpio driver (Linus, your input here would be nice :) I don't understand what this means, does it mean a pin control function somewhere else controlled by a GPIO pin? Or do you mean a new combined pin control and GPIO driver (we have plenty of these). If you elaborate on what you need to do in that driver I might understand it better. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] extcon: otg_gpio: add driver for USB OTG port controlled by GPIO(s)
On Fri, Feb 20, 2015 at 9:40 PM, David Cohen david.a.co...@linux.intel.com wrote: On Fri, Feb 20, 2015 at 02:00:26PM -0600, Felipe Balbi wrote: On Fri, Feb 20, 2015 at 11:59:27AM -0800, David Cohen wrote: I'd need to lookup GPIOs via ACPI without requesting them on mfd driver and then give them to children devices. Heikki proposed a way to do that on [1], but it got nack'ed by community. you missed [1] :-) Oops. Looks like it went away during your past reply :) [1] https://lkml.org/lkml/2014/12/18/82 We don't want to do that in generic code since it's an ACPI problem, not a generic GPIO problem. So the solution must be confined to the GPIO ACPI portions of the GPIO code, not altering central mechanisms. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] extcon: otg_gpio: add driver for USB OTG port controlled by GPIO(s)
On Fri, Feb 20, 2015 at 7:41 AM, Robert Baldyga r.bald...@samsung.com wrote: Hi David, On 02/19/2015 08:59 PM, David Cohen wrote: Some Intel platforms have an USB OTG port fully (or partially) controlled by GPIOs: (1) USB ID is connected directly to a pulled up GPIO. Optionally: (2) VBUS is enabled/disabled by a GPIO (3) Platform has 2 USB controllers connected to same port: one for device and one for host role. D+/- are switched between phys. according to this GPIO level. This driver configures USB OTG port for device or host role according to USB ID value. - If USB ID's GPIO level is low, OTG port is configured for host role by sourcing VBUS and switching D+/- to host phy. - If USB ID's GPIO level is high, by standard, the OTG port is configured for device role by not sourcing VBUS and switching D+/- to device controller. IMO it's not very elegant to handle VBUS power on/off in extcon driver. Creating fixed regulator would allow to make VBUS handling more generic. IMHO it's just layers of abstraction piled on top of each other here. I would put this adjacent to the phy driver somewhere in drivers/usb/* and make the actual USB-driver thing handle its GPIOs directly. But I guess David and Felipe have already discussed that as we're seeing this patch? Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/3] usb: phy: generic: migrate to gpio_desc
On Wed, Jan 28, 2015 at 4:44 PM, Felipe Balbi ba...@ti.com wrote: On Wed, Jan 28, 2015 at 01:40:59PM -0200, Fabio Estevam wrote: On Wed, Jan 28, 2015 at 12:04 PM, Felipe Balbi ba...@ti.com wrote: I don't want to change direction all the time, some controllers might not be glitch free, but I agree that direction has to be set. It looks like we're missing a gpiod_direction_output() call from probe() so that this gpiod_set_value() works fine. We could do like that: nop-gpiod_reset = devm_gpiod_get_optional(dev, reset, GPIOD_OUT_LOW); and it works. However, the initial value can't be set to 0 always as it depends if the pin is active low or high. I tried to do like this: nop-gpiod_reset = devm_gpiod_get_optional(dev, reset); if (gpiod_is_active_low(nop-gpiod_reset)) gpiod_direction_output(nop-gpiod_reset, GPIOD_OUT_LOW); else gpiod_direction_output(nop-gpiod_reset, GPIOD_OUT_HIGH); won't the descriptor itself handle that for us ? Linus ? The descriptor table contains polarity information like this: Documentation/gpio/board.txt (same GPIO_ACTIVE_LOW/HIGH can be passed for device tree and I guess also ACPI) So you should only need to drive the output high, and the core will invert it if needed. So in this case I'd go back and check where the GPIOs are described and make sure it is properly indicated which polarity it has. If you're anyway doing manual control like this, you have to use gpiod_direction_output_raw() to avoid the inversion in the core. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/3] usb: phy: generic: migrate to gpio_desc
On Wed, Jan 28, 2015 at 7:54 PM, Robert Jarzmik robert.jarz...@free.fr wrote: Felipe Balbi ba...@ti.com writes: nop-gpiod_reset = devm_gpiod_get_optional(dev, reset); if (gpiod_is_active_low(nop-gpiod_reset)) gpiod_direction_output(nop-gpiod_reset, GPIOD_OUT_LOW); else gpiod_direction_output(nop-gpiod_reset, GPIOD_OUT_HIGH); won't the descriptor itself handle that for us ? Linus ? I want to hear from Linus W first. Yes, so do I. Let's add a bit of context for Linus : 1) In the past, the driver was doing a ; gpio_request_one() - gpiod_direction_output_raw() 2) After the conversion to gpio descriptors, it is doing : gpiod_get_optional(dev, reset); - ... - __gpiod_get_index(dev, reset, 0, 0) - this of course doesn't call gpiod_direction() But wait. __gpiod_get_index() does call gpiod_direction_output() if any dir bits are set. The problem is that we cannot call: gpiod_get_optional(dev, reset, GPIOD_OUT_LOW); because we don't know before the call if the GPIO is active high or low. The call __gpiod_get_index() first sets the inversion flag if applicable and if you pass GPIOD_OUT_HIGH it should set the raw value to 0 if it was inverted. Else find the bug... is the GPIO line clearly marked as inverted wherever it is described? Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] Documentation: dt-bindings: Add aliases information for Exynos7 pin controllers
On Wed, Dec 10, 2014 at 9:39 AM, Vivek Gautam gautam.vi...@samsung.com wrote: Adding list of aliases for supported Exynos7 pin controller blocks. Signed-off-by: Vivek Gautam gautam.vi...@samsung.com Cc: Tomasz Figa tomasz.f...@gmail.com Cc: Linus Walleij linus.wall...@linaro.org Patch applied. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 2/2] pinctrl: exynos: Add BUS1 pin controller for exynos7
On Wed, Dec 10, 2014 at 9:39 AM, Vivek Gautam gautam.vi...@samsung.com wrote: USB and Power regulator on Exynos7 require gpios available in BUS1 pin controller block. So adding the BUS1 pinctrl support. Signed-off-by: Naveen Krishna Ch naveenkrishna...@gmail.com Signed-off-by: Vivek Gautam gautam.vi...@samsung.com Cc: Tomasz Figa tomasz.f...@gmail.com Cc: Linus Walleij linus.wall...@linaro.org --- Changes since V2: - Added documentation on alias for BUS1 pin controller block. Patch applied with Tomasz ACK. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] gpio: dln2: use bus_sync_unlock instead of scheduling work
On Fri, Jan 9, 2015 at 12:40 AM, Octavian Purdila octavian.purd...@intel.com wrote: On Thu, Jan 1, 2015 at 9:56 AM, Linus Walleij linus.wall...@linaro.org wrote: On Thu, Dec 11, 2014 at 2:02 PM, Octavian Purdila octavian.purd...@intel.com wrote: Use the irq_chip bus_sync_unlock method to update hardware registers instead of scheduling work from the mask/unmask methods. This simplifies a bit the driver and make it more uniform with the other GPIO IRQ drivers. Signed-off-by: Octavian Purdila octavian.purd...@intel.com Patch applied for fixes. Hi Linus, I don't see the patch applied, could you please consider it for the -for-next branch? Ah sorry I thought only the first patch was a critical fix. Applied this to fixes too now. Working on queueing the GPIO fixes. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] extcon: otg_gpio: add driver for USB OTG port controlled by GPIO(s)
On Mon, Dec 22, 2014 at 11:43 PM, David Cohen
david.a.co...@linux.intel.com wrote:
Some platforms have an USB OTG port fully (or partially) controlled by
GPIOs:
(1) USB ID is connected directly to GPIO
Optionally:
(2) VBUS is enabled by a GPIO (when ID is grounded)
(3) Platform has 2 USB controllers connected to same port: one for
device and one for host role. D+/- are switched between phys
by GPIO.
As per initial version, this driver has the duty to control whether
USB-Host cable is plugged in or not:
- If yes, OTG port is configured for host role
- If no, by standard, the OTG port is configured for device role
Signed-off-by: David Cohen david.a.co...@linux.intel.com
Pretty interesting! I don't understand the USB stuff so commenting
from a GPIO side of things only.
+config EXTCON_OTG_GPIO
+ tristate VIRTUAL USB OTG PORT support
+ depends on GPIOLIB
Isn't it dependent on ACPI? This was mentioned in the commit message.
+/*
+ * Virtual USB OTG Port driver controlled by gpios
+ *
+ * Copyright (c) 2014, Intel Corporation.
+ * Author: David Cohen david.a.co...@linux.intel.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/acpi.h
+#include linux/extcon.h
+#include linux/gpio.h
You should include linux/gpio/consumer.h
And nothing else. (I think it'll just work.)
+static int __init vuport_init(void)
+{
+ return platform_driver_register(vuport_driver);
+}
+subsys_initcall(vuport_init);
Usually we try to avoid this kind of early initcalls.
Doesn't deferred probe work as intended?
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/4] gpio: dln2: fix issue when an IRQ is unmasked then enabled
On Tue, Dec 16, 2014 at 4:57 PM, Octavian Purdila octavian.purd...@intel.com wrote: As noticed during suspend/resume operations, the IRQ can be unmasked then disabled in suspend and eventually enabled in resume, but without being unmasked. The current implementation does not take into account interactions between mask/unmask and enable/disable interrupts, and thus in the above scenarios the IRQs remain unactive. To fix this we removed the enable/disable operations as they fallback to mask/unmask anyway. We also remove the pending bitmaks as it is already done in irq_data (i.e. IRQS_PENDING). Signed-off-by: Octavian Purdila octavian.purd...@intel.com This patch applied for fixes. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] gpio: dln2: fix issue when an IRQ is unmasked then enabled
On Wed, Dec 31, 2014 at 9:55 PM, Linus Walleij linus.wall...@linaro.org wrote: On Thu, Dec 11, 2014 at 2:02 PM, Octavian Purdila octavian.purd...@intel.com wrote: As noticed during suspend/resume operations, the IRQ can be unmasked then disabled in suspend and eventually enabled in resume, but without being unmasked. The current implementation does not take into account interactions between mask/unmask and enable/disable interrupts, and thus in the above scenarios the IRQs remain unactive. To fix this we removed the enable/disable operations as they fallback to mask/unmask anyway. We also remove the pending bitmaks as it is already done in irq_data (i.e. IRQS_PENDING). Signed-off-by: Octavian Purdila octavian.purd...@intel.com Patch applied for fixes. Bah now that I see there are several versions of the patch set floating around and also MFD patches I don't quite understand how acute this is or how it's to be applied. - Are these regression fixes or nice to have for next kernel release? - Are the GPIO patches independent of the MFD patch? Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] gpio: dln2: fix issue when an IRQ is unmasked then enabled
On Thu, Dec 11, 2014 at 2:02 PM, Octavian Purdila octavian.purd...@intel.com wrote: As noticed during suspend/resume operations, the IRQ can be unmasked then disabled in suspend and eventually enabled in resume, but without being unmasked. The current implementation does not take into account interactions between mask/unmask and enable/disable interrupts, and thus in the above scenarios the IRQs remain unactive. To fix this we removed the enable/disable operations as they fallback to mask/unmask anyway. We also remove the pending bitmaks as it is already done in irq_data (i.e. IRQS_PENDING). Signed-off-by: Octavian Purdila octavian.purd...@intel.com Patch applied for fixes. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] gpio: dln2: use bus_sync_unlock instead of scheduling work
On Thu, Dec 11, 2014 at 2:02 PM, Octavian Purdila octavian.purd...@intel.com wrote: Use the irq_chip bus_sync_unlock method to update hardware registers instead of scheduling work from the mask/unmask methods. This simplifies a bit the driver and make it more uniform with the other GPIO IRQ drivers. Signed-off-by: Octavian Purdila octavian.purd...@intel.com Patch applied for fixes. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 1/2] pinctrl: exynos: Add BUS1 pin controller for exynos7
On Mon, Dec 1, 2014 at 3:21 PM, Vivek Gautam gautamvivek1...@gmail.com wrote: On Fri, Nov 28, 2014 at 9:15 PM, Linus Walleij linus.wall...@linaro.org wrote: Apart from that, there are *again* a lot of Exynos patches flying around and I start to loose track of them. If they do not apply together and start to conflict I will just ask Tomasz to stack them and provide a pull request again. True, this merge cycle has surely got number of exynos7 related patches in flight, which are difficult to keep track of. Thanks for asking Tomasz. I will probably not take any more Exynos patches for this merge cycle and ask Tomasz to queue the Exynos pinctrl patches for v3.20 after v3.19 merge cycle is complete, so make sure to include Tomasz on reviews. Tomasz: OK? Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1] usb: phy: generic: migrate to gpio_desc
On Fri, Nov 21, 2014 at 4:43 PM, Felipe Balbi ba...@ti.com wrote:
On Sun, Nov 09, 2014 at 01:23:07PM +0100, Robert Jarzmik wrote:
Change internal gpio handling from integer gpios into gpio
descriptors. This change only addresses the internal API and
device-tree/ACPI, while the legacy platform data remains integer space
based.
This change is only build compile tested, and very prone to error. I
leave this comment for now in the commit message so that this patch gets
some testing as I'm pretty sure it's buggy.
Signed-off-by: Robert Jarzmik robert.jarz...@free.fr
To my eyes, patch looks fine, but let's get a review from Linus W.
Linus, can you have a look below ? Is this being used the way you
intended ? BTW, we need support DT and pdata platforms here.
This definately make things better so:
Acked-by: Linus Walleij linus.wall...@linaro.org
One comment though:
if (dev-of_node) {
(...)
+ nop-gpiod_reset = devm_gpiod_get(dev, reset-gpios);
+ err = PTR_ERR(nop-gpiod_reset);
} else if (pdata) {
(...)
+ err = devm_gpio_request_one(dev, pdata-gpio_reset, 0,
+ dev_name(dev));
+ if (!err)
+ nop-gpiod_reset = gpio_to_desc(pdata-gpio_reset);
+ }
This construction implies that if we don't have a DT node, the
GPIO is passed as a fixed number in pdata-gpio_reset,
but it is actually possible to use descriptors in board files
by adding a fixed table.
So a next step would be to add support for getting the
devm_gpiod_get(dev, reset-gpios); outside of the if (dev-of_node)
clause, and possibly convert the board files for affected
platforms to use descriptors, if they will not be replaced by
device tree only.
I know this is a major work, so this patch is still a good start!
Using descriptors internally is always preferred.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/8] usb: musb: Pass fifo_mode in platform data
On Mon, Nov 24, 2014 at 8:05 PM, Tony Lindgren t...@atomide.com wrote: This allows setting the correct fifo_mode when multiple MUSB glue layers are built-in. Cc: Fabio Baltieri fabio.balti...@linaro.org Cc: Lee Jones lee.jo...@linaro.org Cc: Linus Walleij linus.wall...@linaro.org Cc: Apelete Seketeli apel...@seketeli.net Cc: Lars-Peter Clausen l...@metafoo.de Signed-off-by: Tony Lindgren t...@atomide.com Reviewed-by: Linus Walleij linus.wall...@linaro.org Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/8] usb: musb: Change end point selection to use new IO access
On Mon, Nov 24, 2014 at 8:05 PM, Tony Lindgren t...@atomide.com wrote: This allows the endpoints to work when multiple MUSB glue layers are built in. Cc: Fabio Baltieri fabio.balti...@linaro.org Cc: Lee Jones lee.jo...@linaro.org Cc: Linus Walleij linus.wall...@linaro.org Cc: Apelete Seketeli apel...@seketeli.net Cc: Lars-Peter Clausen l...@metafoo.de Signed-off-by: Tony Lindgren t...@atomide.com Acked-by: Linus Walleij linus.wall...@linaro.org Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 1/2] pinctrl: exynos: Add BUS1 pin controller for exynos7
On Fri, Nov 28, 2014 at 4:39 AM, Vivek Gautam gautamvivek1...@gmail.com wrote: On Fri, Nov 28, 2014 at 9:05 AM, Vivek Gautam gautamvivek1...@gmail.com wrote: On Mon, Nov 24, 2014 at 6:32 PM, Vivek Gautam gautam.vi...@samsung.com wrote: USB and Power regulator on Exynos7 require gpios available in BUS1 pin controller block. So adding the BUS1 pinctrl support. Signed-off-by: Naveen Krishna Ch naveenkrishna...@gmail.com Signed-off-by: Vivek Gautam gautam.vi...@samsung.com Cc: Linus Walleij linus.wall...@linaro.org If the change looks good, will it be possible to pick it fo 3.19-rc1 ? That will really help enabling USB IP on exynos7. As you know the Exynos driver has a maintainer, Tomasz Figa, I will not merge patches without his ACK. Apart from that, there are *again* a lot of Exynos patches flying around and I start to loose track of them. If they do not apply together and start to conflict I will just ask Tomasz to stack them and provide a pull request again. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/8] usb: musb: Change to use new IO access
On Mon, Nov 24, 2014 at 8:05 PM, Tony Lindgren t...@atomide.com wrote: Change to use new IO access. This allows us to build in multiple MUSB glue layers. Cc: Fabio Baltieri fabio.balti...@linaro.org Cc: Lee Jones lee.jo...@linaro.org Cc: Linus Walleij linus.wall...@linaro.org Signed-off-by: Tony Lindgren t...@atomide.com Acked-by: Linus Walleij linus.wall...@linaro.org Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] Immutable branch between MFD, GPIO and I2C
On Mon, Nov 10, 2014 at 6:43 PM, Lee Jones lee.jo...@linaro.org wrote: Please don't pull this -- it is missing a patch. Will fix. Okay, dependency fixed. Sorry for the fuss. Pull when ready. Letting it just sit around unless there are conflicts coming up... Seems like this can go through MFD alone from the GPIO side of things. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RESEND V4 3/9] of: Update Tegra XUSB pad controller binding for USB
On Tue, Oct 28, 2014 at 11:27 PM, Andrew Bresticker abres...@chromium.org wrote: Add new bindings used for USB support by the Tegra XUSB pad controller. This includes additional PHY types, USB-specific pinconfig properties, etc. Signed-off-by: Andrew Bresticker abres...@chromium.org Reviewed-by: Stephen Warren swar...@nvidia.com --- Changes from v2: - Added nvidia,otg-hs-curr-level-offset property. - Dropped -otg from VBUS supplies. - Added mbox-names property. - Removed extra whitespace. Changes from v1: - Updated to use common mailbox bindings. - Made USB3 port-to-lane mappins a top-level binding rather than a pinconfig binding. - Add #defines for the padctl lanes. Acked-by: Linus Walleij linus.wall...@linaro.org I guess you will take this patch along with the rest through ARM SoC or so? Yours. Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 3/3] gpio: add support for Cypress CYUSBS234 USB-GPIO adapter
On Thu, Oct 9, 2014 at 1:46 AM, RR rajaram.officema...@gmail.com wrote:
On Wed, Oct 8, 2014 at 12:18 AM, Alexandre Courbot gnu...@gmail.com wrote:
On Wed, Oct 8, 2014 at 4:09 PM, Muthu Mani m...@cypress.com wrote:
+static int cy_gpio_direction_output(struct gpio_chip *chip,
+ unsigned offset, int value) {
+ return 0;
+}
If that chip is capable of both output and input, shouldn't these
functions be
implemented? I think this has already been pointed out in a previous
version
but you did not reply.
Thanks for your inputs.
Only the GPIOs which are configured to be output GPIO can be set.
In that case cy_gpio_set() should return an error for GPIOs which are
not configured as outputs. Is that guaranteed by the current
implementation?
The set operation would fail trying to set the input or unconfigured GPIOs.
In this version of driver, this support is not added, it can be introduced
in future versions.
I will add a TODO note in the code.
Argh, no TODO please. Actual code that will turn this code into a
solid driver that can be merged.
Does a driver targeted for a custom device has to implement every
functionality in the 1st version ?
When you post a driver to the GPIO maintainers it is *NOT* tageted
at a consumer device, it is targeted at the kernel community and
upstream maintainers.
Of course you can deliver add-on patches out-of-tree to your
customers, it's generally a bad idea for the long term and maintenance
of your driver, but it's your pick.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 3/4] gpiolib: add irq_not_threaded flag to gpio_chip
On Thu, Oct 9, 2014 at 9:22 PM, Octavian Purdila octavian.purd...@intel.com wrote: Some GPIO chips (e.g. the DLN2 USB adapter) have blocking get/set operation but do not need a threaded irq handler. Signed-off-by: Octavian Purdila octavian.purd...@intel.com This is already upstream now. Rebase and you can drop this patch. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 4/4] gpio: add support for the Diolan DLN-2 USB GPIO driver
On Thu, Oct 9, 2014 at 9:22 PM, Octavian Purdila octavian.purd...@intel.com wrote: From: Daniel Baluta daniel.bal...@intel.com This patch adds GPIO and IRQ support for the Diolan DLN-2 GPIO module. Information about the USB protocol interface can be found in the Programmer's Reference Manual [1], see section 2.9 for the GPIO module commands and responses. [1] https://www.diolan.com/downloads/dln-api-manual.pdf Signed-off-by: Daniel Baluta daniel.bal...@intel.com Signed-off-by: Octavian Purdila octavian.purd...@intel.com Looks good to me. Acked-by: Linus Walleij linus.wall...@linaro.org Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 partial 0/2] pxa27x_udc port to device-tree and gpio_desc
On Wed, Sep 24, 2014 at 9:41 PM, Robert Jarzmik robert.jarz...@free.fr wrote: I have not found in the gpiolib anything for a driver to set that active_low value, only for machine code. The legacy behaviour was that that information was handed over to the driver. That's correct, active low is a property of the electronics, and not something the driver should mess with going forward. Active low is now defined in either the descriptor table in the machine, in the device tree or in ACPI nodes. The old way was convoluted and something like: board file defines custom platform data - driver gets this - tells GPIOlib to use active low Or in worst case the polarity is hard-coded in the driver (!) That was not a clean separation, the driver should not need to care about polarity, the core should handle this. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 partial 0/2] pxa27x_udc port to device-tree and gpio_desc
On Thu, Sep 25, 2014 at 10:26 AM, Linus Walleij linus.wall...@linaro.org wrote: On Wed, Sep 24, 2014 at 9:41 PM, Robert Jarzmik robert.jarz...@free.fr wrote: I have not found in the gpiolib anything for a driver to set that active_low value, only for machine code. The legacy behaviour was that that information was handed over to the driver. That's correct, active low is a property of the electronics, and not something the driver should mess with going forward. However you can still do it if you have to. In the final v3.17 we have added a flags argument to devm_gpiod_get() and friends so you can set GPIOD_OUT_LOW / GPIOD_OUT_HIGH The old style without specifying flags also works, but we have moved to always adding the flags. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 partial v2 1/3] usb: gadget: pxa27x_udc: prepare device-tree support
On Wed, Sep 24, 2014 at 11:05 PM, Robert Jarzmik robert.jarz...@free.fr wrote:
For this preparation, a preliminary cleanup is done :
- convert the probing of pxa27x_udc to gpio_desc.
The conversion is partial because :
- the platform data still provides a gpio number, not a gpio desc
- the invert attribute is lost, hence a loss in the translation
The drawback with the gpio_desc conversion is that the inverted gpio
attribute is lost, as no gpiod_*() function exists to set the
active_low state of a gpio, and that attribute was at driver's
creation forecast to be set up by the driver and not the machine
specific code.
This can be fixed as of kernel v3.17.
#include linux/gpio.h
+#include linux/gpio/consumer.h
You should only need the lower include, remove
linux/gpio.h.
@@ -2415,7 +2411,13 @@ static int pxa_udc_probe(struct platform_device *pdev)
{
struct resource *regs;
struct pxa_udc *udc = memory;
- int retval = 0, gpio;
+ struct pxa2xx_udc_mach_info *mach = dev_get_platdata(pdev-dev);
+ int retval = 0;
+
+ if (mach) {
+ udc-gpiod = gpio_to_desc(mach-gpio_pullup);
+ udc-mach = mach;
+ }
} else {
udv-gpiod = devm_gpiod_get(pdev-dev, ...);
}
Here you can also use the flags.
So the idea is to use device-bound GPIOs for the future.
Please consult Documentation/gpio/consumer.txt
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 2/2] usb: gadget: pxa27x_udc: add devicetree support
On Wed, Sep 24, 2014 at 9:41 PM, Robert Jarzmik robert.jarz...@free.fr wrote:
Add support for device-tree device discovery. If devicetree is not
provided, fallback to legacy platform data discovery.
Signed-off-by: Robert Jarzmik robert.jarz...@free.fr
Cc: devicet...@vger.kernel.org
(...)
@@ -2417,6 +2425,8 @@ static int pxa_udc_probe(struct platform_device *pdev)
if (mach) {
udc-gpiod = gpio_to_desc(mach-gpio_pullup);
udc-udc_command = mach-udc_command;
+ } else {
+ udc-gpiod = devm_gpiod_get(pdev-dev, NULL);
}
Aha OK there it is.
devm_gpiod_get() actually uses three arguments now, you're using
a deprecated version of the interface:
struct gpio_desc *__must_check devm_gpiod_get(struct device *dev,
const char *con_id,
enum gpiod_flags flags);
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 partial v2 1/3] usb: gadget: pxa27x_udc: prepare device-tree support
On Thu, Sep 25, 2014 at 11:47 AM, robert.jarz...@free.fr wrote:
De: Linus Walleij linus.wall...@linaro.org
@@ -2415,7 +2411,13 @@ static int pxa_udc_probe(struct platform_device *pdev)
{
struct resource *regs;
struct pxa_udc *udc = memory;
- int retval = 0, gpio;
+ struct pxa2xx_udc_mach_info *mach = dev_get_platdata(pdev-dev);
+ int retval = 0;
+
+ if (mach) {
+ udc-gpiod = gpio_to_desc(mach-gpio_pullup);
+ udc-mach = mach;
+ }
} else {
udv-gpiod = devm_gpiod_get(pdev-dev, ...);
}
Here you can also use the flags.
Yeah, but my problem is in the if statement, not in the else. The else is for
the DT/ACPI cases, in which there is no problem.
In that case, that whole clause is actually using the old API without
explicit request, so you can just do this:
if (mach) {
/* This clause will go away when we have transitioned to
just using descriptors */
if (devm_gpio_request_one(pdev-dev, mach-gpio_pullup,
mach-gpio_pullup_inverted ?
GPIOF_ACTIVE_LOW : 0,
my pin))
goto err;
udc-gpiod = gpio_to_desc(mach-gpio_pullup);
udc-mach = mach;
} else {
...
}
On the other hand, the if is for the legacy platform_data cases which
bother me.
The mach info contains :
- gpio_pullup : number of the gpio
- gpio_pullup_inverted : the active low state
What I would have needed would be something like :
if (mach) {
udc-gpiod = gpio_to_desc(mach-gpio_pullup);
gpiod_MAGIC_FUNC_set_flags(udc-gpiod, mach-gpio_pullup_inverted ?
ACTIVE_LOW : 0);
udc-mach = mach;
} else {
udv-gpiod = devm_gpiod_get(pdev-dev, ...);
}
The MAGIC_FUNC is what I'm missing here. And I agree this is something that
is bound in
electronics, and eventually will have to be shifted to platform code. The
porting issue I
have is that I don't want the dependency of changing *all* pxa27x machines as
a dependency
for a patch to pxa27x_udc to support device-tree.
Or alternatively have something like :
udc-gpiod = gpio_to_desc_with_flags(mach-gpio_pullup, flags).
Or another way, to enable a smooth transition without the dependency.
Even I have not found any machine code using this inverted flag, I might have
overlooked
something, and I'm not feeling confortable killing a platform because I made
a wrong
decision.
Cheers.
--
Robert
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 partial v2 1/3] usb: gadget: pxa27x_udc: prepare device-tree support
On Thu, Sep 25, 2014 at 11:47 AM, robert.jarz...@free.fr wrote:
} else {
udv-gpiod = devm_gpiod_get(pdev-dev, ...);
}
Here you can also use the flags.
Yeah, but my problem is in the if statement, not in the else. The else is for
the DT/ACPI cases, in which there is no problem.
Damned mailer sent of the mail before I was finished.
Well you got the solution anyway, check it out.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 partial v2 1/3] usb: gadget: pxa27x_udc: prepare device-tree support
On Thu, Sep 25, 2014 at 3:44 PM, robert.jarz...@free.fr wrote: Could you also review patch 1/3 while at it ;) ? This is patch 1/3... I guess you mean the others. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 3/4] gpiolib: add irq_not_threaded flag to gpio_chip
On Fri, Sep 19, 2014 at 10:22 PM, Octavian Purdila octavian.purd...@intel.com wrote: Some GPIO chips (e.g. the DLN2 USB adapter) have blocking get/set operation but do not need a threaded irq handler. Signed-off-by: Octavian Purdila octavian.purd...@intel.com Usually I don't apply patches adding interfaces with no users, but this seems very useful, so patch applied. I guess your driver will appear on v3.19+ so then you can rely on this having been merged for v3.18. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8] usb:serial:pl2303: add GPIOs interface on PL2303
On Thu, Sep 4, 2014 at 11:57 PM, Benjamin Henrion zoo...@gmail.com wrote: On Thu, Sep 4, 2014 at 7:35 PM, Wang YanQing udkni...@gmail.com wrote: On Sun, Aug 31, 2014 at 11:24:56PM +0800, Wang YanQing wrote: PL2303 USB Serial devices may has GPIOs, this patch add basic PL2303 gpio support. Known issue: If gpios are in use(export to userspace through sysfs interface, etc), then call pl2303_release(unplug usb-serial convertor, modprobe -r, etc), will cause trouble, so we need to make sure there is no gpio user before call pl2303_release. Signed-off-by: Wang YanQing udkni...@gmail.com --- Note: I sniffed office HXD gpio test program to get gpios control protocol with PL2303 RA, so I only test it with PL2303 RA and HXA, I don't have HXD, but because it is *office* HXD gpio test program, so if it doesn't work with HXD, I will feel surprise. I can confirm your patch is working fine on the HXD: http://www.zoobab.com/pl2303hxd-gpio I am still hunting for a simple C program to test the speed of the GPIOs and sysfs, if you have a good reference. The exercise of the GPIO sysfs interface should be discouraged. I would put emphasis on in-kernel tests and working on a better userspace GPIO interface than the sysfs thing. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/3] gpio: add support for the Diolan DLN-2 USB GPIO driver
On Sat, Aug 30, 2014 at 12:00 AM, Octavian Purdila octavian.purd...@intel.com wrote: From: Daniel Baluta daniel.bal...@intel.com This patch adds GPIO and IRQ support for the Diolan DLN-2 GPIO module. Information about the USB protocol interface can be found in the Programmer's Reference Manual [1], see section 2.9 for the GPIO module commands and responses. [1] https://www.diolan.com/downloads/dln-api-manual.pdf Signed-off-by: Daniel Baluta daniel.bal...@intel.com Signed-off-by: Octavian Purdila octavian.purd...@intel.com I like this version. I assume you need to funnel it with the rest of the patches through the MFD tree so: Acked-by: Linus Walleij linus.wall...@linaro.org Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8] usb:serial:pl2303: add GPIOs interface on PL2303
On Sun, Aug 31, 2014 at 5:24 PM, Wang YanQing udkni...@gmail.com wrote: PL2303 USB Serial devices may has GPIOs, this patch add basic PL2303 gpio support. Known issue: If gpios are in use(export to userspace through sysfs interface, etc), then call pl2303_release(unplug usb-serial convertor, modprobe -r, etc), will cause trouble, so we need to make sure there is no gpio user before call pl2303_release. Signed-off-by: Wang YanQing udkni...@gmail.com --- Note: I sniffed office HXD gpio test program to get gpios control protocol with PL2303 RA, so I only test it with PL2303 RA and HXA, I don't have HXD, but because it is *office* HXD gpio test program, so if it doesn't work with HXD, I will feel surprise. Changes v7-v8: 1: add support for four dedicated gpios on HXD and RA 2: fix problem reported by Johan Hovold in v7 3: fix checkpatch.pl's warning This has been looking nice from the GPIO side of things for a while so: Acked-by: Linus Walleij linus.wall...@linaro.org Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] gpio: add support for the Diolan DLN-2 USB-GPIO driver
On Wed, Aug 20, 2014 at 1:24 PM, Daniel Baluta daniel.bal...@intel.com wrote: This patch adds GPIO and IRQ support for the Diolan DLN-2 GPIO module. Information about the USB protocol interface can be found in the Programmer's Reference Manual [1], see section 2.9 for the GPIO module commands and responses. [1] https://www.diolan.com/downloads/dln-api-manual.pdf Signed-off-by: Daniel Baluta daniel.bal...@intel.com Major change required: rewrite this driver to not select IRQ_DOMAIN, instead select GPIOLIB_IRQCHIP and use the shared infrastructure. See other drivers that select GPIOLIB_IRQCHIP or grep the git log to see how this works in practice. You need to use some container_of() operations. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 4/9] pinctrl: tegra-xusb: Add USB PHY support
On Mon, Aug 25, 2014 at 9:22 PM, Stephen Warren swar...@wwwdotorg.org wrote: On 08/18/2014 11:08 AM, Andrew Bresticker wrote: In addition to the PCIe and SATA PHYs, the XUSB pad controller also supports 3 UTMI, 2 HSIC, and 2 USB3 PHYs. Each USB3 PHY uses a single PCIe or SATA lane and is mapped to one of the three UTMI ports. The xHCI controller will also send messages intended for the PHY driver, so request and listen for messages on the mailbox's PHY channel. I'd like a review from Thierry here as the HW expert. I need an ack from LinusW in order to take this pinctrl patch through the Tegra tree. Acked-by: Linus Walleij linus.wall...@linaro.org Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4] usb:serial:pl2303: add GPIOs interface on PL2303
On Thu, Jul 24, 2014 at 7:03 PM, Wang YanQing udkni...@gmail.com wrote: PL2303HX has two GPIOs, this patch add interface for it. Signed-off-by: Wang YanQing udkni...@gmail.com --- Changes v3-v4: 1: fix missing static for gpio_dir_mask and gpio_value_mask 2: reduce unneeded compile macro defined suggested by gno...@lxorguk.ukuu.org.uk 3: use true instead of 1 corrected by Linus Walleij 4: ignore return value of gpiochip_remove suggested by Linus Walleij 5: fix multi gpio_chips registered by pl2303 can't be distinguished in kernel space. This is OK with me now, Reviewed-by: Linus Walleij linus.wall...@linaro.org Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] usb:serial:pl2303: add GPIOs interface on PL2303
On Mon, Jul 21, 2014 at 4:46 AM, Wang YanQing udkni...@gmail.com wrote:
PL2303HX has two GPIOs, this patch add interface for it.
Signed-off-by: Wang YanQing udkni...@gmail.com
---
Changes v2-v3:
1: fix errors and warnings reported by Daniele Forsi checked with
checkpatch.pl
2: fix missing GPIOLIB dependence in Kconfig
3: fix pl2303_gpio_get can't work
Known issue:
If gpios are in use(export to userspace through sysfs interface, etc),
then call pl2303_release(unplug usb-serial convertor, modprobe -r, etc),
will cause trouble, so we need to make sure there is no gpio user before
call pl2303_release.
The sysfs ABI is not sound, using it is a recipe for trouble.
IIRC it was merged at a time when drivers/gpio was unmaintained :-(
(...)
+static struct gpio_chip template_chip = {
+ .label = pl2303-gpio,
+ .owner = THIS_MODULE,
+ .direction_input= pl2303_gpio_direction_in,
+ .get= pl2303_gpio_get,
+ .direction_output = pl2303_gpio_direction_out,
+ .set= pl2303_gpio_set,
+ .can_sleep = 1,
This is a bool so use = true,
+#ifdef CONFIG_USB_SERIAL_PL2303_GPIO
+ if (spriv spriv-gpio) {
+ if (gpiochip_remove(spriv-gpio-gpio_chip))
+ dev_err(serial-interface-dev,
+ unable to remove gpio_chip?\n);
I'm getting rid of the return code from gpiochip_remove() and have removed
the __must_check tag in the gpio tree, so just call gpiochip_remove()
unconditionally and ignore any compile error messages for now.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] USB: ftdi_sio: add GPIO support
On Fri, Jun 13, 2014 at 8:31 PM, Greg Kroah-Hartman gre...@linuxfoundation.org wrote: On Fri, Jun 13, 2014 at 09:25:07AM +0200, Linus Walleij wrote: But I also want to bring the device model into question: normally when a mother device spawns children across different subsystems we model them as MFD devices (drivers/mfd) that instantiate children for the different subsystems. So you could spawn a serial and a GPIO device from a USB-based hub device there. I do not know if that is really apropriate in this case. It seems the device is first and foremost FTDI. But it could still spawn a child platform device for the GPIO stuff so that this can live as a separate driver under drivers/gpio/gpio-ftdi.c or similar. You could then use something like: struct platform_device *gdev; Ick, no, it's a USB device, do not abuse the platform_device code any more than it currently is (note, I HATE the platform device code, someday I'll delete it entirely... Well, I can dream...) Haha yeah :-) However is the MFD cell approach acceptable? Now MFD cells are platform_devices mind you, but it's in principle just how that got implemented, MFD cells could be device-something else. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] USB: ftdi_sio: add GPIO support
On Mon, Jun 9, 2014 at 3:21 PM, Sascha Silbe x-li...@infra-silbe.de wrote: The chips can operate either in regular or in bitbang mode. Care was taken to prevent using GPIOs if the serial device is in use and vice versa. Very interesting patch! I've seen USB-based GPIO things before but never a dual-mode thing. There was already a comment to move the implementation to a separate file, which I won't repeat. But I also want to bring the device model into question: normally when a mother device spawns children across different subsystems we model them as MFD devices (drivers/mfd) that instantiate children for the different subsystems. So you could spawn a serial and a GPIO device from a USB-based hub device there. I do not know if that is really apropriate in this case. It seems the device is first and foremost FTDI. But it could still spawn a child platform device for the GPIO stuff so that this can live as a separate driver under drivers/gpio/gpio-ftdi.c or similar. You could then use something like: struct platform_device *gdev; gdev = platform_device_alloc(gpio-ftdi, PLATFORM_DEVID_AUTO); /* pdata contains communication cookie for callbacks etc */ ret = platform_device_add_data(gdev, pdata, sizeof(*pdata)); ret = platform_device_add(gdev); Then we can probe that device normally in the GPIO subsystem like any other driver, just that it needs some linux/usb/ftdi.h header or similar to define the function calls to communicate with the FTDI driver. However Greg is device core maintainer and may have better ideas about this! Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] usb: musb: ux500: don't propagate the OF node
There is a regression in the upcoming v3.16-rc1, that is caused by a problem that has been around for a while but now finally hangs the system. The bootcrawl looks like this: pinctrl-nomadik soc:pinctrl: pin GPIO256_AF28 already requested by a03e.usb_per5; cannot claim for musb-hdrc.0.auto pinctrl-nomadik soc:pinctrl: pin-256 (musb-hdrc.0.auto) status -22 pinctrl-nomadik soc:pinctrl: could not request pin 256 (GPIO256_AF28) from group usb_a_1 on device pinctrl-nomadik musb-hdrc musb-hdrc.0.auto: Error applying setting, reverse things back HS USB OTG: no transceiver configured musb-hdrc musb-hdrc.0.auto: musb_init_controller failed with status -517 platform musb-hdrc.0.auto: Driver musb-hdrc requests probe deferral (...) The ux500 MUSB driver propagates the OF node to the dynamically created musb-hdrc device, which is incorrect as it makes the OF core believe there are two devices spun from the very same DT node, which confuses other parts of the device core, notably the pin control subsystem, which will try to apply all the pin control settings also to the HDRC device as it gets instantiated. (The OMAP2430 for example, does not set the of_node member.) Cc: sta...@vger.kernel.org Cc: Lee Jones lee.jo...@linaro.org Cc: Arnd Bergmann a...@arndb.de Cc: Felipe Balbi ba...@ti.com Signed-off-by: Linus Walleij linus.wall...@linaro.org --- drivers/usb/musb/ux500.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/usb/musb/ux500.c b/drivers/usb/musb/ux500.c index c2e45e632723..f202e5088461 100644 --- a/drivers/usb/musb/ux500.c +++ b/drivers/usb/musb/ux500.c @@ -274,7 +274,6 @@ static int ux500_probe(struct platform_device *pdev) musb-dev.parent= pdev-dev; musb-dev.dma_mask = pdev-dev.coherent_dma_mask; musb-dev.coherent_dma_mask = pdev-dev.coherent_dma_mask; - musb-dev.of_node = pdev-dev.of_node; glue-dev = pdev-dev; glue-musb = musb; -- 1.9.3 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] usb: gadget: fix pxa25x compilation problems
In commit 88f718e3fa4d67f3a8dbe79a2f97d722323e4051 ARM: pxa: delete the custom GPIO header we removed the implicit inclusion of mach/gpio.h from linux/gpio.h. The pxa25x_udc was not using that, but it was relying on linux/gpio.h to implictly include mach/gpio.h which in turn implicitly included mach/hardware.h, which was needed for the driver to compile. Fix this up by explicitly including the necessary mach/hardware.h header. Reported-by: Russell King li...@arm.linux.org.uk Signed-off-by: Linus Walleij linus.wall...@linaro.org --- drivers/usb/gadget/pxa25x_udc.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/usb/gadget/pxa25x_udc.c b/drivers/usb/gadget/pxa25x_udc.c index 0ac6064aa3b8..409a3c45a36a 100644 --- a/drivers/usb/gadget/pxa25x_udc.c +++ b/drivers/usb/gadget/pxa25x_udc.c @@ -54,6 +54,7 @@ */ #ifdef CONFIG_ARCH_PXA #include mach/pxa25x-udc.h +#include mach/hardware.h #endif #ifdef CONFIG_ARCH_LUBBOCK -- 1.8.3.1 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] usb: musb: name ux500 platforms more broadly
The Kconfig help text is talking about the U5500 which is no longer supported by the kernel. Name the help text after the config symbol which is more correct. Signed-off-by: Linus Walleij linus.wall...@linaro.org --- drivers/usb/musb/Kconfig | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig index c64ee09a7..a77ac0c 100644 --- a/drivers/usb/musb/Kconfig +++ b/drivers/usb/musb/Kconfig @@ -91,7 +91,7 @@ config USB_MUSB_BLACKFIN depends on (BF54x !BF544) || (BF52x ! BF522 !BF523) config USB_MUSB_UX500 - tristate U8500 and U5500 + tristate Ux500 platforms endchoice @@ -113,7 +113,7 @@ choice allow using DMA on multiplatform kernels. config USB_UX500_DMA - bool 'ST Ericsson U8500 and U5500' + bool 'ST Ericsson Ux500' depends on USB_MUSB_UX500 help Enable DMA transfers on UX500 platforms. -- 1.8.3.1 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Ksummit-2013-discuss] Topic: where should the border between userspace and kernel be?
On Tue, Jul 16, 2013 at 12:39 PM, Miklos Szeredi mik...@szeredi.hu wrote: Is the border always where it should be? Are there any candidates for moving things into, or out of the kernel? Are there some guidelines for deciding which functionality belongs to the kernel? Now I need to flag ATTEND. On this subject I would add not just broadband modems but the media players and all type of Android devices that nowadays use the MTP protocol (and thus the PTP protocol). I am also the maintainer of libmtp. It has turned out that people think about this transactional object thing (which is more like FTP over USB than USB mass storage) as a file system and it is now being implemented with e.g. GVFS and KDE's counter-part in userspace as virtual filesystems. This would be all OK if it wasn't that I always have this worry that with all the device-specific quirks etc we had been better off in kernelspace for what is today libmtp. Certainly we had gotten to a point where it was usable for people quicker than has happened so far. The strangeness of how libusb abstracts things to userspace would not be there, and it would be more possible to share code between client and server (responder and initiator as they are called) than is currently possible. So I guess I could add some €0.01 here... Background: http://libmtp.git.sourceforge.net/git/gitweb.cgi?p=libmtp/libmtp;a=blob;f=README;hb=HEAD (The end of the file is especially interesting, may propose this as a talk for a conference this year.) Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 05/39] ARM: ux500: Stop passing MMC's platform data for Device Tree boots
On Mon, Jun 10, 2013 at 11:15 AM, Lee Jones lee.jo...@linaro.org wrote: On Wed, 15 May 2013, Linus Walleij wrote: On Wed, May 15, 2013 at 11:51 AM, Lee Jones lee.jo...@linaro.org wrote: It was required to pass DMA channel configuration information to the MMC driver before the new DMA API was in place. Now that it is, and is fully compatible with Device Tree we can stop doing that. Reviewed-by: Linus Walleij linus.wall...@linaro.org Signed-off-by: Lee Jones lee.jo...@linaro.org So since the use of dma_request_slave_channel() is not upstream, I guess this will break DMA use (i.e slow down transfers!) on all device tree boots? I'd be happy to apply it once the MMCI patch is in linux-next indicating there may just be a window in the merge period where it falls back to IRQ mode, but I don't want to disable DMA on DT boots for an entire kernel cycle just like that. Not applied as of yet. I believe it's now okay to apply this. Yep, I've rebased and applied it to the ux500-devicetree branch. I have some stuff on this branch which is queued up but may miss v3.11, because I need the 5 outstanding pull requests to land in ARM SoC so I get a merge base there before I can send any more stuff. It's mainly because this stuff isn't any orthogonal, everything just conflicts in the AUXDATA all the time. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 06/39] ARM: ux500: Move SDI (MMC) and UART devices under more descriptive heading
On Mon, Jun 10, 2013 at 11:17 AM, Lee Jones lee.jo...@linaro.org wrote: On Wed, 15 May 2013, Linus Walleij wrote: On Wed, May 15, 2013 at 11:51 AM, Lee Jones lee.jo...@linaro.org wrote: Now DMA DT bindings exist and are in use by he MMC and UART drivers, it should be possible to remove them from the auxdata structure. However, after doing so the drivers fail. Common clk is still reliant on the dev_name() call to do device name matching, which will fail due to the fact that Device Tree naming differs somewhat do the more traditional conventions. Reviewed-by: Linus Walleij linus.wall...@linaro.org Signed-off-by: Lee Jones lee.jo...@linaro.org Cannot be applied due to dependency on 5/39. I think this can be applied now (if it hasn't already). I really need a clean mergebase for this to merge ... This patch requires both the dma40 and devicetree branches to land in a common place before it can be applied. I want the DMA40 branch to be closed down now as I have sent all pull requests on it, so pls ping me again on this when we have something in the ARM SoC tree we can work on. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 20/39] usb: musb: ux500: move channel number knowledge into the driver
On Wed, May 15, 2013 at 11:51 AM, Lee Jones lee.jo...@linaro.org wrote: For all ux500 based platforms the maximum number of end-points are used. Move this knowledge into the driver so we can relinquish the burden from platform data. This also removes quite a bit of complexity from the driver and will aid us when we come to enable the driver for Device Tree. Cc: Felipe Balbi ba...@ti.com Cc: linux-usb@vger.kernel.org Acked-by: Linus Walleij linus.wall...@linaro.org Acked-by: Fabio Baltieri fabio.balti...@linaro.org Signed-off-by: Lee Jones lee.jo...@linaro.org Patch applied to my dma40 branch with Felipe's ACK. Thanks! Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 20/39] usb: musb: ux500: move channel number knowledge into the driver
On Wed, May 29, 2013 at 7:57 PM, Felipe Balbi ba...@ti.com wrote: On Wed, May 15, 2013 at 10:51:43AM +0100, Lee Jones wrote: For all ux500 based platforms the maximum number of end-points are used. Move this knowledge into the driver so we can relinquish the burden from platform data. This also removes quite a bit of complexity from the driver and will aid us when we come to enable the driver for Device Tree. Cc: Felipe Balbi ba...@ti.com Cc: linux-usb@vger.kernel.org Acked-by: Linus Walleij linus.wall...@linaro.org Acked-by: Fabio Baltieri fabio.balti...@linaro.org Signed-off-by: Lee Jones lee.jo...@linaro.org for drivers/usb/musb Acked-by: Felipe Balbi ba...@ti.com Is that only for this patch 20/39 or also 21, 22 23? Poke us if we should re-send them... Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
