Re: [PATCH usb-next v10 3/8] usb: core: add a wrapper for the USB PHYs on the HCD

[Kishon Vijay Abraham I]

Hi,

On Monday 19 March 2018 09:42 PM, Martin Blumenstingl wrote:
> Hi Roger,
> 
> On Mon, Mar 19, 2018 at 9:49 AM, Roger Quadros  wrote:
>> Hi,
>>
>> On 19/03/18 00:29, Martin Blumenstingl wrote:
>>> Hi Roger,
>>>
>>> On Fri, Mar 16, 2018 at 3:32 PM, Roger Quadros  wrote:
 +some TI folks

 Hi Martin,

 On 18/02/18 20:44, Martin Blumenstingl wrote:
> Many SoC platforms have separate devices for the USB PHY which are
> registered through the generic PHY framework. These PHYs have to be
> enabled to make the USB controller actually work. They also have to be
> disabled again on shutdown/suspend.
>
> Currently (at least) the following HCI platform drivers are using custom
> code to obtain all PHYs via devicetree for the roothub/controller and
> disable/enable them when required:
> - ehci-platform.c has ehci_platform_power_{on,off}
> - xhci-mtk.c has xhci_mtk_phy_{init,exit,power_on,power_off}
> - ohci-platform.c has ohci_platform_power_{on,off}
>
> With this new wrapper the USB PHYs can be specified directly in the
> USB controller's devicetree node (just like on the drivers listed
> above). This allows SoCs like the Amlogic Meson GXL family to operate
> correctly once this is wired up correctly. These SoCs use a dwc3
> controller and require all USB PHYs to be initialized (if one of the USB
> PHYs it not initialized then none of USB port works at all).
>
> Signed-off-by: Martin Blumenstingl 
> Tested-by: Yixun Lan 
> Cc: Neil Armstrong 
> Cc: Chunfeng Yun 

 This patch is breaking low power cases on TI SoCs when USB is in host mode.
 I'll explain why below.
>>> based on your explanation and reading the TI PHY drivers I am assuming
>>> that the affected SoCs are using the "phy-omap-usb2" driver
>>>
>> yes and phy-ti-pipe3 as well i.e. "ti,phy-usb3" and "ti,omap-usb3"
> I missed that, thanks
> 
> ---
>  drivers/usb/core/Makefile |   2 +-
>  drivers/usb/core/phy.c| 158 
> ++
>  drivers/usb/core/phy.h|   7 ++
>  3 files changed, 166 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/usb/core/phy.c
>  create mode 100644 drivers/usb/core/phy.h
>
> diff --git a/drivers/usb/core/Makefile b/drivers/usb/core/Makefile
> index 92c9cefb4317..18e874b0441e 100644
> --- a/drivers/usb/core/Makefile
> +++ b/drivers/usb/core/Makefile
> @@ -6,7 +6,7 @@
>  usbcore-y := usb.o hub.o hcd.o urb.o message.o driver.o
>  usbcore-y += config.o file.o buffer.o sysfs.o endpoint.o
>  usbcore-y += devio.o notify.o generic.o quirks.o devices.o
> -usbcore-y += port.o
> +usbcore-y += phy.o port.o
>
>  usbcore-$(CONFIG_OF) += of.o
>  usbcore-$(CONFIG_USB_PCI)+= hcd-pci.o
> diff --git a/drivers/usb/core/phy.c b/drivers/usb/core/phy.c
> new file mode 100644
> index ..09b7c43c0ea4
> --- /dev/null
> +++ b/drivers/usb/core/phy.c
> @@ -0,0 +1,158 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * A wrapper for multiple PHYs which passes all phy_* function calls to
> + * multiple (actual) PHY devices. This is comes handy when initializing
> + * all PHYs on a HCD and to keep them all in the same state.
> + *
> + * Copyright (C) 2018 Martin Blumenstingl 
> 
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "phy.h"
> +
> +struct usb_phy_roothub {
> + struct phy  *phy;
> + struct list_headlist;
> +};
> +
> +static struct usb_phy_roothub *usb_phy_roothub_alloc(struct device *dev)
> +{
> + struct usb_phy_roothub *roothub_entry;
> +
> + roothub_entry = devm_kzalloc(dev, sizeof(*roothub_entry), 
> GFP_KERNEL);
> + if (!roothub_entry)
> + return ERR_PTR(-ENOMEM);
> +
> + INIT_LIST_HEAD(_entry->list);
> +
> + return roothub_entry;
> +}
> +
> +static int usb_phy_roothub_add_phy(struct device *dev, int index,
> +struct list_head *list)
> +{
> + struct usb_phy_roothub *roothub_entry;
> + struct phy *phy = devm_of_phy_get_by_index(dev, dev->of_node, 
> index);
> +
> + if (IS_ERR_OR_NULL(phy)) {
> + if (!phy || PTR_ERR(phy) == -ENODEV)
> + return 0;
> + else
> + return PTR_ERR(phy);
> + }
> +
> + roothub_entry = usb_phy_roothub_alloc(dev);
> + if (IS_ERR(roothub_entry))
> + return PTR_ERR(roothub_entry);
> +
> + 

Re: [PATCHv3] phy: mapphone-mdm6600: Add USB PHY driver for MDM6600 on Droid 4

[Kishon Vijay Abraham I]

Hi Tony,

On Wednesday 07 March 2018 08:26 PM, Tony Lindgren wrote:
> Let's add support for the GPIO controlled USB PHY on the MDM6600 modem.
> It is used on some Motorola Mapphone series of phones and tablets such
> as Droid 4.
> 
> The MDM6600 is hardwired to the first OHCI port in the Droid 4 case, and
> is controlled by several GPIOs. The USB PHY is integrated into the MDM6600
> device it seems. We know this as we get L3 errors from omap-usb-host if
> trying to use the PHY before MDM6600 is configured.
> 
> The GPIOs controlling MDM6600 are used to power device on and off, to
> configure the USB start-up mode (normal mode versus USB flashing), and
> they also tell the state of the MDM6600 device.
> 
> The two start-up mode GPIOs are dual-purposed and used for out of band
> (OOB) wake-up for USB and TS 27.010 serial mux. But we need to configure
> the USB start-up mode first to get MDM6600 booted in the right mode to
> be usable in the first place.
> 
> Note that the Motorola Mapphone Linux kernel tree has a "radio-ctrl"
> driver for modems. But it really does not control the radio at all, it
> just controls the modem power and start-up mode for USB. So I came to
> the conclusion that we're better off having this done in the USB PHY
> driver. For adding support for USB flashing mode, we can later on add
> a kernel module option for flash_mode=1 or something similar.
> 
> Also note that currently there is no PM runtime support for the OHCI
> on omap variant SoCs. So for low(er) power idle states, currenty both
> ohci-platform and phy-mapphone-mdm6600 must be unloaded or unbound.
> 
> For reference here is what I measured for total power consumption on
> an idle Droid 4 with and without USB related MDM6600 modules:
> 
> idle lcd off  phy-mapphone-mdm6600ohci-platform
> 153mW 284mW   344mW
> 
> So it seems that MDM6600 is currently not yet idling even with it's
> radio turned off, but that's something that is beyond the control of
> this USB PHY driver. This patch does get us to the point where modem
> data and GPS are usable with libqmi and ModemManager for example.
> Voice calls need more audio driver work.
> 
> Cc: devicet...@vger.kernel.org
> Cc: Mark Rutland 
> Cc: Marcel Partap 
> Cc: Michael Scott 
> Cc: Rob Herring 
> Reviewed-by: Rob Herring 
> Signed-off-by: Tony Lindgren 
> ---
> 
> Changes since v2:
> - Dropped OTG as suggested by Kishon
> - Added Rob's Reviewed-by
> 
> Changes since v1:
> - Fixed up issues noticed by Rob and Sebastian
> - Implemented wake irq handler (for debug use only for now)
> - Improved error handling based on more testing
> 
> ---
>  .../bindings/phy/phy-mapphone-mdm6600.txt  |  30 ++
>  drivers/phy/motorola/Kconfig   |   9 +
>  drivers/phy/motorola/Makefile  |   1 +
>  drivers/phy/motorola/phy-mapphone-mdm6600.c| 549 
> +
>  4 files changed, 589 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/phy/phy-mapphone-mdm6600.txt
>  create mode 100644 drivers/phy/motorola/phy-mapphone-mdm6600.c
> 
> diff --git a/Documentation/devicetree/bindings/phy/phy-mapphone-mdm6600.txt 
> b/Documentation/devicetree/bindings/phy/phy-mapphone-mdm6600.txt
> new file mode 100644
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/phy-mapphone-mdm6600.txt
> @@ -0,0 +1,30 @@
> +Device tree binding documentation for Motorola Mapphone MDM6600 USB PHY
> +
> +Required properties:
> +- compatible Must be "motorola,mapphone-mdm6600"
> +- enable-gpios   GPIO to enable the USB PHY
> +- power-gpiosGPIO to power on the device
> +- reset-gpiosGPIO to reset the device
> +- motorola,mode-gpiosTwo GPIOs to configure MDM6600 USB start-up 
> mode for
> + normal mode versus USB flashing mode
> +- motorola,cmd-gpios Three GPIOs to control the power state of the MDM6600
> +- motorola,status-gpios  Three GPIOs to read the power state of the 
> MDM6600
> +
> +Example:
> +
> +usb-phy {
> + compatible = "motorola,mapphone-mdm6600";
> + enable-gpios = < 31 GPIO_ACTIVE_LOW>;
> + power-gpios = < 22 GPIO_ACTIVE_HIGH>;
> + reset-gpios = < 17 GPIO_ACTIVE_HIGH>;
> + motorola,mode-gpios = < 20 GPIO_ACTIVE_HIGH>,
> +   < 21 GPIO_ACTIVE_HIGH>;
> + motorola,cmd-gpios = < 7 GPIO_ACTIVE_HIGH>,
> +  < 8 GPIO_ACTIVE_HIGH>,
> +  < 14 GPIO_ACTIVE_HIGH>;
> + motorola,status-gpios = < 20 GPIO_ACTIVE_HIGH>,
> + < 21 GPIO_ACTIVE_HIGH>,
> + < 23 GPIO_ACTIVE_HIGH>;
> + #phy-cells = <0>;
> +};
> +
> diff --git a/drivers/phy/motorola/Kconfig b/drivers/phy/motorola/Kconfig
> --- a/drivers/phy/motorola/Kconfig
> +++ b/drivers/phy/motorola/Kconfig
> @@ 

Re: [PATCHv2] phy: mapphone-mdm6600: Add USB PHY driver for MDM6600 on Droid 4

[Kishon Vijay Abraham I]

Hi Tony,

On Thursday 01 March 2018 09:20 AM, Tony Lindgren wrote:
> Let's add support for the GPIO controlled USB PHY on the MDM6600 modem.
> It is used on some Motorola Mapphone series of phones and tablets such
> as Droid 4.

Generally PHY configuration is done for the PHYs that is connected to the USB
controllers in the SoC. In that sense it differs from the usual case by
programming the PHY in the device.
> 
> The MDM6600 is hardwired to the first OHCI port in the Droid 4 case, and
> is controlled by several GPIOs. The USB PHY is integrated into the MDM6600
> device it seems. We know this as we get L3 errors from omap-usb-host if
> trying to use the PHY before MDM6600 is configured.

Do you know what phy is connected to the OHCI port. Previously we've seen for
having USB devices on the board itself, phy less configurations was used.
> 
> The GPIOs controlling MDM6600 are used to power device on and off, to
> configure the USB start-up mode (normal mode versus USB flashing), and
> they also tell the state of the MDM6600 device.
> 
> The two start-up mode GPIOs are dual-purposed and used for out of band
> (OOB) wake-up for USB and TS 27.010 serial mux. But we need to configure
> the USB start-up mode first to get MDM6600 booted in the right mode to
> be usable in the first place.
> 
> Note that the Motorola Mapphone Linux kernel tree has a "radio-ctrl"
> driver for modems. But it really does not control the radio at all, it
> just controls the modem power and start-up mode for USB. So I came to
> the conclusion that we're better off having this done in the USB PHY
> driver. For adding support for USB flashing mode, we can later on add
> a kernel module option for flash_mode=1 or something similar.
> 
> Also note that currently there is no PM runtime support for the OHCI
> on omap variant SoCs. So for low(er) power idle states, currenty both
> ohci-platform and phy-mapphone-mdm6600 must be unloaded or unbound.
> 
> For reference here is what I measured for total power consumption on
> an idle Droid 4 with and without USB related MDM6600 modules:
> 
> idle lcd off  phy-mapphone-mdm6600ohci-platform
> 153mW 284mW   344mW
> 
> So it seems that MDM6600 is currently not yet idling even with it's
> radio turned off, but that's something that is beyond the control of
> this USB PHY driver. This patch does get us to the point where modem
> data and GPS are usable with libqmi and ModemManager for example.
> Voice calls need more audio driver work.
> 
> Cc: devicet...@vger.kernel.org
> Cc: Mark Rutland 
> Cc: Marcel Partap 
> Cc: Michael Scott 
> Cc: Rob Herring 
> Cc: Sebastian Reichel 
> Signed-off-by: Tony Lindgren 
> ---
> 
> Changes since v1:
> - Fixed up issues noticed by Rob and Sebastian
> - Implemented wake irq handler (for debug use only for now)
> - Improved error handling based on more testing
> 
> ---
>  .../bindings/phy/phy-mapphone-mdm6600.txt  |  30 ++
>  drivers/phy/motorola/Kconfig   |   9 +
>  drivers/phy/motorola/Makefile  |   1 +
>  drivers/phy/motorola/phy-mapphone-mdm6600.c| 556 
> +
>  4 files changed, 596 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/phy/phy-mapphone-mdm6600.txt
>  create mode 100644 drivers/phy/motorola/phy-mapphone-mdm6600.c
> 
> diff --git a/Documentation/devicetree/bindings/phy/phy-mapphone-mdm6600.txt 
> b/Documentation/devicetree/bindings/phy/phy-mapphone-mdm6600.txt
> new file mode 100644
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/phy-mapphone-mdm6600.txt
> @@ -0,0 +1,30 @@
> +Device tree binding documentation for Motorola Mapphone MDM6600 USB PHY
> +
> +Required properties:
> +- compatible Must be "motorola,mapphone-mdm6600"
> +- enable-gpios   GPIO to enable the USB PHY
> +- power-gpiosGPIO to power on the device
> +- reset-gpiosGPIO to reset the device
> +- motorola,mode-gpiosTwo GPIOs to configure MDM6600 USB start-up 
> mode for
> + normal mode versus USB flashing mode
> +- motorola,cmd-gpios Three GPIOs to control the power state of the MDM6600
> +- motorola,status-gpios  Three GPIOs to read the power state of the 
> MDM6600
> +
> +Example:
> +
> +usb-phy {
> + compatible = "motorola,mapphone-mdm6600";
> + enable-gpios = < 31 GPIO_ACTIVE_LOW>;
> + power-gpios = < 22 GPIO_ACTIVE_HIGH>;
> + reset-gpios = < 17 GPIO_ACTIVE_HIGH>;
> + motorola,mode-gpios = < 20 GPIO_ACTIVE_HIGH>,
> +   < 21 GPIO_ACTIVE_HIGH>;
> + motorola,cmd-gpios = < 7 GPIO_ACTIVE_HIGH>,
> +  < 8 GPIO_ACTIVE_HIGH>,
> +  < 14 GPIO_ACTIVE_HIGH>;
> + motorola,status-gpios = < 20 GPIO_ACTIVE_HIGH>,
> + < 21 GPIO_ACTIVE_HIGH>,

Re: [PATCH v5 00/17] Support for Qualcomm QUSBv2 and QMPv3 USB PHYs

[Kishon Vijay Abraham I]

On Thursday 01 February 2018 06:08 PM, Kishon Vijay Abraham I wrote:
> Hi,
> 
> On Wednesday 31 January 2018 10:51 AM, Manu Gautam wrote:
>> Hi Kishon,
>>
>>
>> On 1/16/2018 4:26 PM, Manu Gautam wrote:
>>> QUSB-v2 and QMP-v3 USB PHYs are present on Qualcomm's 14nm
>>> and 10nm SOCs.
>>> This patch series adds support for runtime PM for these
>>> USB PHYs and adds fixes in drivers to follow PHY reset and
>>> initialization sequence as per hardware programming manual.
>>
>> Can you please check this latest patch-set and let me know if it
>> is good to go?
> 
> The series looks good. I'll start merging once -rc1 is tagged.

merged, thanks!

-Kishon
--
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 00/17] Support for Qualcomm QUSBv2 and QMPv3 USB PHYs

[Kishon Vijay Abraham I]

Hi,

On Wednesday 31 January 2018 10:51 AM, Manu Gautam wrote:
> Hi Kishon,
> 
> 
> On 1/16/2018 4:26 PM, Manu Gautam wrote:
>> QUSB-v2 and QMP-v3 USB PHYs are present on Qualcomm's 14nm
>> and 10nm SOCs.
>> This patch series adds support for runtime PM for these
>> USB PHYs and adds fixes in drivers to follow PHY reset and
>> initialization sequence as per hardware programming manual.
> 
> Can you please check this latest patch-set and let me know if it
> is good to go?

The series looks good. I'll start merging once -rc1 is tagged.

Thanks
Kishon
--
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] phy: work around 'phys' references to usb-phy devices

[Kishon Vijay Abraham I]

Hi Arnd,

On Thursday 11 January 2018 11:46 PM, Eric Anholt wrote:
> Arnd Bergmann <a...@arndb.de> writes:
> 
>> On Thu, Jan 11, 2018 at 2:30 PM, Kishon Vijay Abraham I <kis...@ti.com> 
>> wrote:
>>> On Thursday 11 January 2018 02:27 AM, Arnd Bergmann wrote:
>>>> On Mon, Jan 8, 2018 at 7:32 PM, Kishon Vijay Abraham I <kis...@ti.com> 
>>>> wrote:
>>>>> On Monday 08 January 2018 06:31 PM, Arnd Bergmann wrote:
>>>>>> Stefan Wahren reports a problem with a warning fix that was merged
>>>>>> ---
>>>>>> This obviously needs to be tested, I wrote this up as a reply to
>>>>>> Stefan's bug report. I'm fairly sure that I covered all usb-phy
>>>>>> driver strings here. My goal is to have a fix merged into 4.15
>>>>>> rather than reverting all the DT fixes.
>>>>>
>>>>> Shouldn't the fix be in phy consumer drivers to not return error if it's 
>>>>> able
>>>>> to find the phy either using usb-phy or generic phy?
>>>>
>>>> Stefan has posted a patch to that effect now, but I fear that might be
>>>> a little fragile, in particular this short before the release with the
>>>> regression
>>>> in place.
>>>>
>>>> The main problem is that we'd have to change the generic
>>>> usb_add_hcd() function in addition to dwc2 and dwc3 to ignore
>>>> -EPROBE_DEFER from phy_get() whenever usb_get_phy_dev()
>>>> has already succeeded.
>>>>
>>>> If there is any HCD that relies on usb_add_hcd() to get both the
>>>> usb_phy and the phy structures, and it may need to defer probing
>>>> when the latter one isn't ready yet, that fix would break another
>>>> driver.
>>>
>>> hmm.. IMO the better thing right now would be to revert the dt patch which 
>>> adds
>>> #phy-cells.
>>> We have to see if there are better fixes in order to add #phy-cells warning 
>>> fix
>>> in stable tree.
>>
>> Let's see which patches that would be, I think this is the full list of
>> nodes that got an extra #phy-cells:
>>
>> c22fe696157d ARM: dts: Fix dm814x missing phy-cells property
>> f0e11ff8ff65 ARM: dts: am33xx: Add missing #phy-cells to ti,am335x-usb-phy
>> c5bbf358b790 arm: dts: nspire: Add missing #phy-cells to usb-nop-xceiv
>> 44e5dced2ef6 arm: dts: marvell: Add missing #phy-cells to usb-nop-xceiv
>> 014d6da6cb25 ARM: dts: bcm283x: Fix DTC warnings about missing phy-cells
>> f568f6f554b8 ARM: dts: omap: Add missing #phy-cells to usb-nop-xceiv
>>
>> plus a couple in linux-next:
>>
>> d745d5f277bf ARM: dts: imx51-zii-rdu1: Add missing #phy-cells to 
>> usb-nop-xceiv
>> 915fbe59cbf2 ARM: dts: imx: Add missing #phy-cells to usb-nop-xceiv
>>
>> It's a lot of patches to revert, and I guess it would get us back to hundreds
>> of warnings in an allmodconfig build, so I'd first try to come up with
>> ways to prove that at least some of them can stay.
>>
>> Almost all the warnings are about "usb-nop-xceiv" phys, the only exceptions
>> I could find are the OMAP ones (the first two patches), which use
>> "ti,am335x-usb-phy" and are referenced from a "ti,musb-am33xx". That
>> particular driver is not affected by the bug, so we can leave that in.
>>
>> To deal with all the "usb-nop-xceiv"  references including the one that
>> Stefan reported, we could use a much simpler version of my earlier
>> patch, do you think this is any better?

yeah, this looks simpler.
>>
>> Signed-off-by: Arnd Bergmann <a...@arndb.de>

In case you want to take this patch yourself
Acked-by: Kishon Vijay Abraham I <kis...@ti.com>

(or let me know if I have to create a separate pull request for Greg)

Thanks
Kishon

>>
>> diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
>> index b4964b067aec..f056d8fb3921 100644
>> --- a/drivers/phy/phy-core.c
>> +++ b/drivers/phy/phy-core.c
>> @@ -410,6 +410,10 @@ static struct phy *_of_phy_get(struct device_node
>> *np, int index)
>> if (ret)
>> return ERR_PTR(-ENODEV);
>>
>> +   /* This phy type handled by the usb-phy subsystem for now */
>> +   if (of_device_is_compatible("usb-nop-xceiv"))
>> +   return ERR_PTR(-ENODEV);
>> +
>> mutex_lock(_provider_mutex);
>> phy_provider = of_phy_provider_lookup(args.np);
>> if (IS_ERR(phy_provider) || !try_module_get(phy_provider->owner)) {
> 
> This seems like a nice workaround!
> 
--
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] phy: work around 'phys' references to usb-phy devices

[Kishon Vijay Abraham I]

Hi Arnd,

On Thursday 11 January 2018 02:27 AM, Arnd Bergmann wrote:
> On Mon, Jan 8, 2018 at 7:32 PM, Kishon Vijay Abraham I <kis...@ti.com> wrote:
>> Hi Arnd,
>>
>> On Monday 08 January 2018 06:31 PM, Arnd Bergmann wrote:
>>> Stefan Wahren reports a problem with a warning fix that was merged
>>> for v4.15: we had lots of device nodes with a 'phys' property pointing
>>> to a device node that is not compliant with the binding documented in
>>> Documentation/devicetree/bindings/phy/phy-bindings.txt
>>>
>>> This generally works because USB HCD drivers that support both the generic
>>> phy subsystem and the older usb-phy subsystem ignore most errors from
>>> phy_get() and related calls and then use the usb-phy driver instead.
>>>
>>> However, usb_add_hcd() (along with the respective functions in dwc2 and
>>> dwc3) propagate the EPROBE_DEFER return code so we can try again whenever
>>> the driver gets loaded. In case the driver is written for the usb-phy
>>> subsystem (like usb-generic-phy aka usb-nop-xceiv), we will never load
>>> a generic-phy driver for it, and keep failing here.
>>>
>>> There is only a small number of remaining usb-phy drivers that support
>>> device tree, so this adds a workaround by providing a full list of the
>>> potentially affected drivers, and always failing the probe with -ENODEV
>>> here, which is the same behavior that we used to get with incorrect
>>> device tree files. Since we generally want older kernels to also want
>>> to work with the fixed devicetree files, it would be good to backport
>>> the patch into stable kernels as well (3.13+ are possibly affected).
>>> Reverting back to the DTS sources that work would in theory fix USB
>>> support for now, but in the long run we'd run into the same problem
>>> again when the drivers get ported from usb-phy to generic-phy.
>>>
>>> Fixes: 014d6da6cb25 ("ARM: dts: bcm283x: Fix DTC warnings about missing 
>>> phy-cells")
>>> Link: https://marc.info/?l=linux-usb=151518314314753=2
>>> Cc: sta...@vger.kernel.org
>>> Cc: Stefan Wahren <stefan.wah...@i2se.com>
>>> Cc: Felipe Balbi <ba...@kernel.org>
>>> Signed-off-by: Arnd Bergmann <a...@arndb.de>
>>> ---
>>> This obviously needs to be tested, I wrote this up as a reply to
>>> Stefan's bug report. I'm fairly sure that I covered all usb-phy
>>> driver strings here. My goal is to have a fix merged into 4.15
>>> rather than reverting all the DT fixes.
>>
>> Shouldn't the fix be in phy consumer drivers to not return error if it's able
>> to find the phy either using usb-phy or generic phy?
> 
> Stefan has posted a patch to that effect now, but I fear that might be
> a little fragile, in particular this short before the release with the
> regression
> in place.
> 
> The main problem is that we'd have to change the generic
> usb_add_hcd() function in addition to dwc2 and dwc3 to ignore
> -EPROBE_DEFER from phy_get() whenever usb_get_phy_dev()
> has already succeeded.
> 
> If there is any HCD that relies on usb_add_hcd() to get both the
> usb_phy and the phy structures, and it may need to defer probing
> when the latter one isn't ready yet, that fix would break another
> driver.

hmm.. IMO the better thing right now would be to revert the dt patch which adds
#phy-cells.
We have to see if there are better fixes in order to add #phy-cells warning fix
in stable tree.

Thanks
Kishon
--
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] phy: work around 'phys' references to usb-phy devices

[Kishon Vijay Abraham I]

Hi Arnd,

On Monday 08 January 2018 06:31 PM, Arnd Bergmann wrote:
> Stefan Wahren reports a problem with a warning fix that was merged
> for v4.15: we had lots of device nodes with a 'phys' property pointing
> to a device node that is not compliant with the binding documented in
> Documentation/devicetree/bindings/phy/phy-bindings.txt
> 
> This generally works because USB HCD drivers that support both the generic
> phy subsystem and the older usb-phy subsystem ignore most errors from
> phy_get() and related calls and then use the usb-phy driver instead.
> 
> However, usb_add_hcd() (along with the respective functions in dwc2 and
> dwc3) propagate the EPROBE_DEFER return code so we can try again whenever
> the driver gets loaded. In case the driver is written for the usb-phy
> subsystem (like usb-generic-phy aka usb-nop-xceiv), we will never load
> a generic-phy driver for it, and keep failing here.
> 
> There is only a small number of remaining usb-phy drivers that support
> device tree, so this adds a workaround by providing a full list of the
> potentially affected drivers, and always failing the probe with -ENODEV
> here, which is the same behavior that we used to get with incorrect
> device tree files. Since we generally want older kernels to also want
> to work with the fixed devicetree files, it would be good to backport
> the patch into stable kernels as well (3.13+ are possibly affected).
> Reverting back to the DTS sources that work would in theory fix USB
> support for now, but in the long run we'd run into the same problem
> again when the drivers get ported from usb-phy to generic-phy.
> 
> Fixes: 014d6da6cb25 ("ARM: dts: bcm283x: Fix DTC warnings about missing 
> phy-cells")
> Link: https://marc.info/?l=linux-usb=151518314314753=2
> Cc: sta...@vger.kernel.org
> Cc: Stefan Wahren 
> Cc: Felipe Balbi 
> Signed-off-by: Arnd Bergmann 
> ---
> This obviously needs to be tested, I wrote this up as a reply to
> Stefan's bug report. I'm fairly sure that I covered all usb-phy
> driver strings here. My goal is to have a fix merged into 4.15
> rather than reverting all the DT fixes.

Shouldn't the fix be in phy consumer drivers to not return error if it's able
to find the phy either using usb-phy or generic phy?
> ---
>  drivers/phy/phy-core.c | 27 +++
>  1 file changed, 27 insertions(+)
> 
> diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
> index b4964b067aec..bb4dd2a2de2d 100644
> --- a/drivers/phy/phy-core.c
> +++ b/drivers/phy/phy-core.c
> @@ -387,6 +387,24 @@ int phy_calibrate(struct phy *phy)
>  }
>  EXPORT_SYMBOL_GPL(phy_calibrate);
>  
> +static struct of_device_id __maybe_unused legacy_usbphy[] = {
> + { .compatible = "fsl,imx23-usbphy" },
> + { .compatible = "fsl,imx6q-usbphy" },
> + { .compatible = "fsl,imx6sl-usbphy" },
> + { .compatible = "fsl,imx6sx-usbphy" },
> + { .compatible = "fsl,imx6ul-usbphy" },
> + { .compatible = "fsl,vf610-usbphy" },
> + { .compatible = "nvidia,tegra20-usb-phy" },
> + { .compatible = "nvidia,tegra30-usb-phy" },
> + { .compatible = "nxp,isp1301" },
> + { .compatible = "ti,am335x-usb-ctrl-module" },
> + { .compatible = "ti,am335x-usb-phy" },
> + { .compatible = "ti,keystone-usbphy" },
> + { .compatible = "ti,twl6030-usb" },
> + { .compatible = "usb-nop-xceiv" },
> + {},

"ti,am335x-usb-ctrl-module" and "ti,twl6030-usb" are not phys.

Thanks
Kishon
--
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 14/16] phy: Add USB speed related PHY modes

[Kishon Vijay Abraham I]

Hi,

On Wednesday 03 January 2018 04:58 PM, Manu Gautam wrote:
> Add following USB speed related PHY modes:
> LS (Low Speed), FS (Full Speed), HS (High Speed), SS (Super Speed)
> 
> Speed related information is required by some QCOM PHY drivers
> to program PHY monitor resume/remote-wakeup events in suspended
> state. Speed is needed in order to set correct polarity of wakeup
> events for detection. E.g. QUSB2 PHY monitors DP/DM line state
> depending on whether speed is LS or FS/HS to detect resume.
> Similarly QMP USB3 PHY in SS mode should monitor RX terminations
> attach/detach and LFPS events depending on SSPHY is active or not.
> 
> Signed-off-by: Manu Gautam 
> ---
>  drivers/phy/phy-core.c  | 15 +++
>  include/linux/phy/phy.h | 32 
>  2 files changed, 39 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
> index b4964b0..e4f0525 100644
> --- a/drivers/phy/phy-core.c
> +++ b/drivers/phy/phy-core.c
> @@ -357,6 +357,21 @@ int phy_set_mode(struct phy *phy, enum phy_mode mode)
>  }
>  EXPORT_SYMBOL_GPL(phy_set_mode);
>  
> +enum phy_mode phy_get_mode(struct phy *phy)
> +{
> + enum phy_mode ret;
> +
> + if (!phy || !phy->ops->get_mode)
> + return PHY_MODE_INVALID;
> +
> + mutex_lock(>mutex);
> + ret = phy->ops->get_mode(phy);

Since get_mode only has to return the phy mode, there is no need for an ops
here. Just add phy_mode in phy_attrs in set_mode and return it here.

Thanks
Kishon
--
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 14/16] phy: Add notify_speed callback

[Kishon Vijay Abraham I]

Hi,

On Friday 29 December 2017 09:54 AM, Manu Gautam wrote:
> Hi,
> 
> 
> On 12/28/2017 4:34 PM, Kishon Vijay Abraham I wrote:
>> Hi,
>>
> [snip]
>>
>>>> I'd prefer adding modes in enum phy_mode according to speed and using 
>>>> phy_set_mode.
>>> yeah, that also seems good idea. How about something like this:
>>>
>>> --- a/include/linux/phy/phy.h
>>> +++ b/include/linux/phy/phy.h
>>> @@ -23,12 +23,16 @@
>>>  struct phy;
>>>  
>>>  enum phy_mode {
>>> -   PHY_MODE_INVALID,
>>> -   PHY_MODE_USB_HOST,
>>> -   PHY_MODE_USB_DEVICE,
>>> -   PHY_MODE_USB_OTG,
>>> -   PHY_MODE_SGMII,
>>> -   PHY_MODE_10GKR,
>>> +   PHY_MODE_INVALID= 0,
>>> +   PHY_MODE_USB_HOST   = BIT(0),
>>> +   PHY_MODE_USB_DEVICE = BIT(1),
>>> +   PHY_MODE_USB_OTG,   = BIT(2),
>>> +   PHY_MODE_SGMII  = BIT(3),
>>> +   PHY_MODE_10GKR  = BIT(4),
>>> +   PHY_MODE_USB_LS = BIT(5),
>>> +   PHY_MODE_USB_FS = BIT(6),
>>> +   PHY_MODE_USB_HS = BIT(7),
>>> +   PHY_MODE_USB_SS = BIT(8),
>>>  };
>>>
>>>
>>> This way I don't need to duplicate USB speed enums for host/device or otg 
>>> modes.
>> no.. let's keep enum. It's lot more cleaner IMO.
> 
> In that case all PHY drivers would need to consider these speed enums. E.g.
> 
> if (mode == HOST) check in PHY driver would need to be changed to:
> if (mode == HOST || mode == HOST_LS || mode == HOST_FS || mode == HOST_HS ||
> mode == HOST_SS

suggest using switch in such case.. and not all PHY drivers do specific
configurations for specific speeds.
> 
> This looks clumsy.
> Where as if bits to used then there is no need for such changes.

really? using bits should only make it more clumsy.

-Kishon
--
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] phy: phy-mtk-tphy: use auto instead of force to bypass utmi signals

[Kishon Vijay Abraham I]

On Thursday 07 December 2017 05:23 PM, Chunfeng Yun wrote:
> When system is running, if usb2 phy is forced to bypass utmi signals,
> all PLL will be turned off, and it can't detect device connection
> anymore, so replace force mode with auto mode which can bypass utmi
> signals automatically if no device attached for normal flow.
> But keep the force mode to fix RX sensitivity degradation issue.
> 
> Signed-off-by: Chunfeng Yun 

merged this series.

Thanks
Kishon
> ---
>  drivers/phy/mediatek/phy-mtk-tphy.c | 19 +++
>  1 file changed, 7 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/phy/mediatek/phy-mtk-tphy.c 
> b/drivers/phy/mediatek/phy-mtk-tphy.c
> index fb8aba4..5d9d7f3 100644
> --- a/drivers/phy/mediatek/phy-mtk-tphy.c
> +++ b/drivers/phy/mediatek/phy-mtk-tphy.c
> @@ -440,9 +440,9 @@ static void u2_phy_instance_init(struct mtk_tphy *tphy,
>   u32 index = instance->index;
>   u32 tmp;
>  
> - /* switch to USB function. (system register, force ip into usb mode) */
> + /* switch to USB function, and enable usb pll */
>   tmp = readl(com + U3P_U2PHYDTM0);
> - tmp &= ~P2C_FORCE_UART_EN;
> + tmp &= ~(P2C_FORCE_UART_EN | P2C_FORCE_SUSPENDM);
>   tmp |= P2C_RG_XCVRSEL_VAL(1) | P2C_RG_DATAIN_VAL(0);
>   writel(tmp, com + U3P_U2PHYDTM0);
>  
> @@ -502,10 +502,8 @@ static void u2_phy_instance_power_on(struct mtk_tphy 
> *tphy,
>   u32 index = instance->index;
>   u32 tmp;
>  
> - /* (force_suspendm=0) (let suspendm=1, enable usb 480MHz pll) */
>   tmp = readl(com + U3P_U2PHYDTM0);
> - tmp &= ~(P2C_FORCE_SUSPENDM | P2C_RG_XCVRSEL);
> - tmp &= ~(P2C_RG_DATAIN | P2C_DTM0_PART_MASK);
> + tmp &= ~(P2C_RG_XCVRSEL | P2C_RG_DATAIN | P2C_DTM0_PART_MASK);
>   writel(tmp, com + U3P_U2PHYDTM0);
>  
>   /* OTG Enable */
> @@ -540,7 +538,6 @@ static void u2_phy_instance_power_off(struct mtk_tphy 
> *tphy,
>  
>   tmp = readl(com + U3P_U2PHYDTM0);
>   tmp &= ~(P2C_RG_XCVRSEL | P2C_RG_DATAIN);
> - tmp |= P2C_FORCE_SUSPENDM;
>   writel(tmp, com + U3P_U2PHYDTM0);
>  
>   /* OTG Disable */
> @@ -548,18 +545,16 @@ static void u2_phy_instance_power_off(struct mtk_tphy 
> *tphy,
>   tmp &= ~PA6_RG_U2_OTG_VBUSCMP_EN;
>   writel(tmp, com + U3P_USBPHYACR6);
>  
> - /* let suspendm=0, set utmi into analog power down */
> - tmp = readl(com + U3P_U2PHYDTM0);
> - tmp &= ~P2C_RG_SUSPENDM;
> - writel(tmp, com + U3P_U2PHYDTM0);
> - udelay(1);
> -
>   tmp = readl(com + U3P_U2PHYDTM1);
>   tmp &= ~(P2C_RG_VBUSVALID | P2C_RG_AVALID);
>   tmp |= P2C_RG_SESSEND;
>   writel(tmp, com + U3P_U2PHYDTM1);
>  
>   if (tphy->pdata->avoid_rx_sen_degradation && index) {
> + tmp = readl(com + U3P_U2PHYDTM0);
> + tmp &= ~(P2C_RG_SUSPENDM | P2C_FORCE_SUSPENDM);
> + writel(tmp, com + U3P_U2PHYDTM0);
> +
>   tmp = readl(com + U3D_U2PHYDCR0);
>   tmp &= ~P2C_RG_SIF_U2PLL_FORCE_ON;
>   writel(tmp, com + U3D_U2PHYDCR0);
> 
--
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 14/16] phy: Add notify_speed callback

[Kishon Vijay Abraham I]

Hi,

On Wednesday 20 December 2017 02:11 PM, Manu Gautam wrote:
> Hi
> 
> 
> On 12/20/2017 12:47 PM, Kishon Vijay Abraham I wrote:
>> Hi,
>>
> [snip]
>>>> Why not use a notification mechanism instead of adding new APIs in 
>>>> phy-core.
>>>> This will only bloat phy-core with APIs for a particular platform.
>>> Do you mean notifier_chains ?
>>> When we have multiple instances of USB PHYs then notifier chains are not
>>> of much help. For any platform glue or PHY driver it will be very difficult 
>>> to
>>> figure out if notification received for speed was for same phy/bus or a
>>> different one.
>>> Using PHY callbacks looked more elegant to me. Additionally PHY drivers
>>> can also use this info decide power management policy e.g. if speed is
>>> INVALID then it means PHY is not in a session and it can enter deepest
>>> low power state.
>>> Additionally if you prefer set_speed name over notify_speed then I am
>>> ok with that as well so that it sounds more generic.
>> I'd prefer adding modes in enum phy_mode according to speed and using 
>> phy_set_mode.
> 
> yeah, that also seems good idea. How about something like this:
> 
> --- a/include/linux/phy/phy.h
> +++ b/include/linux/phy/phy.h
> @@ -23,12 +23,16 @@
>  struct phy;
>  
>  enum phy_mode {
> - PHY_MODE_INVALID,
> - PHY_MODE_USB_HOST,
> - PHY_MODE_USB_DEVICE,
> - PHY_MODE_USB_OTG,
> - PHY_MODE_SGMII,
> - PHY_MODE_10GKR,
> + PHY_MODE_INVALID= 0,
> + PHY_MODE_USB_HOST   = BIT(0),
> + PHY_MODE_USB_DEVICE = BIT(1),
> + PHY_MODE_USB_OTG,   = BIT(2),
> + PHY_MODE_SGMII  = BIT(3),
> + PHY_MODE_10GKR  = BIT(4),
> + PHY_MODE_USB_LS = BIT(5),
> + PHY_MODE_USB_FS = BIT(6),
> + PHY_MODE_USB_HS = BIT(7),
> + PHY_MODE_USB_SS = BIT(8),
>  };
> 
> 
> This way I don't need to duplicate USB speed enums for host/device or otg 
> modes.

no.. let's keep enum. It's lot more cleaner IMO.

Thanks
Kishon
--
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 14/16] phy: Add notify_speed callback

[Kishon Vijay Abraham I]

Hi,

On Wednesday 20 December 2017 11:59 AM, Manu Gautam wrote:
> Hi,
> 
> 
> On 12/20/2017 11:19 AM, Kishon Vijay Abraham I wrote:
>> Hi,
>>
>> On Tuesday 12 December 2017 08:54 PM, Manu Gautam wrote:
>>> Hi,
>>>
>>>
>>> On 12/12/2017 5:13 PM, Kishon Vijay Abraham I wrote:
>>>> Hi,
>>>>
>>>> On Tuesday 21 November 2017 02:53 PM, Manu Gautam wrote:
>>>>> QCOM USB PHYs can monitor resume/remote-wakeup event in
>>>>> suspended state. However PHY driver must know current
>>>>> operational speed of PHY in order to set correct polarity of
>>>>> wakeup events for detection. E.g. QUSB2 PHY monitors DP/DM
>>>>> signals depending on speed is LS or FS/HS to detect resume.
>>>>> Similarly QMP USB3 PHY in SS mode should monitor RX
>>>>> terminations attach/detach and LFPS events depending on
>>>>> SSPHY is active or not.
>> Why not use a notification mechanism instead of adding new APIs in phy-core.
>> This will only bloat phy-core with APIs for a particular platform.
> 
> Do you mean notifier_chains ?
> When we have multiple instances of USB PHYs then notifier chains are not
> of much help. For any platform glue or PHY driver it will be very difficult to
> figure out if notification received for speed was for same phy/bus or a
> different one.
> Using PHY callbacks looked more elegant to me. Additionally PHY drivers
> can also use this info decide power management policy e.g. if speed is
> INVALID then it means PHY is not in a session and it can enter deepest
> low power state.
> Additionally if you prefer set_speed name over notify_speed then I am
> ok with that as well so that it sounds more generic.

I'd prefer adding modes in enum phy_mode according to speed and using 
phy_set_mode.

Thanks
Kishon
--
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 14/16] phy: Add notify_speed callback

[Kishon Vijay Abraham I]

Hi,

On Tuesday 12 December 2017 08:54 PM, Manu Gautam wrote:
> Hi,
> 
> 
> On 12/12/2017 5:13 PM, Kishon Vijay Abraham I wrote:
>> Hi,
>>
>> On Tuesday 21 November 2017 02:53 PM, Manu Gautam wrote:
>>> QCOM USB PHYs can monitor resume/remote-wakeup event in
>>> suspended state. However PHY driver must know current
>>> operational speed of PHY in order to set correct polarity of
>>> wakeup events for detection. E.g. QUSB2 PHY monitors DP/DM
>>> signals depending on speed is LS or FS/HS to detect resume.
>>> Similarly QMP USB3 PHY in SS mode should monitor RX
>>> terminations attach/detach and LFPS events depending on
>>> SSPHY is active or not.

Why not use a notification mechanism instead of adding new APIs in phy-core.
This will only bloat phy-core with APIs for a particular platform.

Thanks
Kishon
>>>
>>> Signed-off-by: Manu Gautam <mgau...@codeaurora.org>
>>> ---
>>>  drivers/phy/phy-core.c  | 30 ++
>>>  include/linux/phy/phy.h | 26 ++
>>>  2 files changed, 56 insertions(+)
>>>
>>> diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
>>> index b4964b0..03df2be 100644
>>> --- a/drivers/phy/phy-core.c
>>> +++ b/drivers/phy/phy-core.c
>>> @@ -387,6 +387,36 @@ int phy_calibrate(struct phy *phy)
>>>  }
>>>  EXPORT_SYMBOL_GPL(phy_calibrate);
>>>  
>>> +int phy_notify_speed(struct phy *phy, enum phy_speed speed)
>>> +{
>>> +   int ret;
>>> +
>>> +   if (!phy || !phy->ops->notify_speed)
>>> +   return 0;
>>> +
>>> +   mutex_lock(>mutex);
>>> +   ret = phy->ops->notify_speed(phy, speed);
>>> +   mutex_unlock(>mutex);
>>> +
>>> +   return ret;
>>> +}
>>> +EXPORT_SYMBOL_GPL(phy_notify_speed);
>>> +
>>> +enum phy_speed phy_get_speed(struct phy *phy)
>>> +{
>>> +   enum phy_speed ret;
>>> +
>>> +   if (!phy || !phy->ops->get_speed)
>>> +   return PHY_SPEED_UNKNOWN;
>>> +
>>> +   mutex_lock(>mutex);
>>> +   ret = phy->ops->get_speed(phy);
>>> +   mutex_unlock(>mutex);
>>> +
>>> +   return ret;
>>> +}
>>> +EXPORT_SYMBOL_GPL(phy_get_speed);
>> So this is equivalent to set_speed (why notify?) and get_speed. set_speed 
>> will
>> most likely be invoked by USB driver? who will invoke get_speed?
> 
> I picked notify_speed as set_speed sounds like driver is going to set/program
> speed related configuration in PHY. Where as the purpose of this function
> is to notify phy_driver of the connection speed of established link.
> USB glue drivers for Qualcomm platforms need to know USB PHYs' speed to
> set correct polarity of wakeup interrupt from hardware in low power state.
>  
> 
>> Thanks
>> Kishon
> 
--
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 14/16] phy: Add notify_speed callback

[Kishon Vijay Abraham I]

Hi,

On Tuesday 21 November 2017 02:53 PM, Manu Gautam wrote:
> QCOM USB PHYs can monitor resume/remote-wakeup event in
> suspended state. However PHY driver must know current
> operational speed of PHY in order to set correct polarity of
> wakeup events for detection. E.g. QUSB2 PHY monitors DP/DM
> signals depending on speed is LS or FS/HS to detect resume.
> Similarly QMP USB3 PHY in SS mode should monitor RX
> terminations attach/detach and LFPS events depending on
> SSPHY is active or not.
> 
> Signed-off-by: Manu Gautam 
> ---
>  drivers/phy/phy-core.c  | 30 ++
>  include/linux/phy/phy.h | 26 ++
>  2 files changed, 56 insertions(+)
> 
> diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
> index b4964b0..03df2be 100644
> --- a/drivers/phy/phy-core.c
> +++ b/drivers/phy/phy-core.c
> @@ -387,6 +387,36 @@ int phy_calibrate(struct phy *phy)
>  }
>  EXPORT_SYMBOL_GPL(phy_calibrate);
>  
> +int phy_notify_speed(struct phy *phy, enum phy_speed speed)
> +{
> + int ret;
> +
> + if (!phy || !phy->ops->notify_speed)
> + return 0;
> +
> + mutex_lock(>mutex);
> + ret = phy->ops->notify_speed(phy, speed);
> + mutex_unlock(>mutex);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(phy_notify_speed);
> +
> +enum phy_speed phy_get_speed(struct phy *phy)
> +{
> + enum phy_speed ret;
> +
> + if (!phy || !phy->ops->get_speed)
> + return PHY_SPEED_UNKNOWN;
> +
> + mutex_lock(>mutex);
> + ret = phy->ops->get_speed(phy);
> + mutex_unlock(>mutex);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(phy_get_speed);

So this is equivalent to set_speed (why notify?) and get_speed. set_speed will
most likely be invoked by USB driver? who will invoke get_speed?

Thanks
Kishon
--
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: [PATCHv4 2/2] phy: exynos5-usbdrd: Calibrate LOS levels for exynos5420/5800

[Kishon Vijay Abraham I]

Felipe,

On Monday 09 October 2017 05:30 PM, Andrzej Pietrasiewicz wrote:
> From: Vivek Gautam 
> 
> Adding phy calibration sequence for USB 3.0 DRD PHY present on
> Exynos5420/5800 systems.
> This calibration facilitates setting certain PHY parameters viz.
> the Loss-of-Signal (LOS) Detector Threshold Level, as well as
> Tx-Vboost-Level for Super-Speed operations.
> Additionally we also set proper time to wait for RxDetect measurement,
> for desired PHY reference clock, so as to solve issue with enumeration
> of few USB 3.0 devices, like Samsung SUM-TSB16S 3.0 USB drive
> on the controller.
> 
> We are using CR_port for this purpose to send required data
> to override the LOS values.
> 
> On testing with USB 3.0 devices on USB 3.0 port present on
> SMDK5420, and peach-pit boards should see following message:
> usb 2-1: new SuperSpeed USB device number 2 using xhci-hcd
> 
> and without this patch, should see below shown message:
> usb 1-1: new high-speed USB device number 2 using xhci-hcd
> 
> [Also removed unnecessary extra lines in the register macro definitions]
> 
> Signed-off-by: Vivek Gautam 
> [adapted to use phy_calibrate as entry point]
> Signed-off-by: Andrzej Pietrasiewicz 
> ---
>  drivers/phy/samsung/phy-exynos5-usbdrd.c | 183 
> +++
>  drivers/usb/dwc3/core.c  |   7 +-

are you okay with this patch?

Thanks
Kishon
--
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: Split out extcon header file for consumer and provider device

[Kishon Vijay Abraham I]

On Wednesday 18 October 2017 07:44 AM, Chanwoo Choi wrote:
> Gently Ping.
> 
> Dear Kishon,
> 
> Could you please review this patch for 'drivers/phy/*'?

sorry for the delay.. here it is

Acked-by: Kishon Vijay Abraham I <kis...@ti.com>
> 
> Regards,
> Chanwoo Choi
> 
> On 2017년 10월 12일 12:40, Chanwoo Choi wrote:
>> Dear Kishon,
>>
>> Could you please review this patch?
>> After that, I'll make the immutable brand and then send the pull request
>> for power_supply, mfd, phy, usb and extcon framework.
>>
>> On 2017년 10월 10일 19:17, Chanwoo Choi wrote:
>>> The extcon has two type of extcon devices as following.
>>> - 'extcon provider deivce' adds new extcon device and detect the
>>>state/properties of external connector. Also, it notifies the
>>>state/properties to the extcon consumer device.
>>> - 'extcon consumer device' gets the change state/properties
>>>from extcon provider device.
>>> Prior to that, include/linux/extcon.h contains all exported API for
>>> both provider and consumer device driver. To clarify the meaning of
>>> header file and to remove the wrong use-case on consumer device,
>>> this patch separates into extcon.h and extcon-provider.h.
>>>
>>> [Description for include/linux/{extcon.h|extcon-provider.h}]
>>> - extcon.h includes the extcon API and data structure for extcon consumer
>>>   device driver. This header file contains the following APIs:
>>>   : Register/unregister the notifier to catch the change of extcon device
>>>   : Get the extcon device instance
>>>   : Get the extcon device name
>>>   : Get the state of each external connector
>>>   : Get the property value of each external connector
>>>   : Get the property capability of each external connector
>>>
>>> - extcon-provider.h includes the extcon API and data structure for extcon
>>>   provider device driver. This header file contains the following APIs:
>>>   : Include 'include/linux/extcon.h'
>>>   : Allocate the memory for extcon device instance
>>>   : Register/unregister extcon device
>>>   : Set the state of each external connector
>>>   : Set the property value of each external connector
>>>   : Set the property capability of each external connector
>>>
>>> Cc: Felipe Balbi <ba...@kernel.org>
>>> Cc: Kishon Vijay Abraham I <kis...@ti.com>
>>> Cc: Greg Kroah-Hartman <gre...@linuxfoundation.org>
>>> Acked-by: Sebastian Reichel <sebastian.reic...@collabora.co.uk>
>>> Acked-by: Chen-Yu Tsai <w...@csie.org>
>>> Acked-by: Charles Keepax <ckee...@opensource.cirrus.com>
>>> Acked-by: Lee Jones <lee.jo...@linaro.org>
>>> Signed-off-by: Chanwoo Choi <cw00.c...@samsung.com>
>>> ---
>>> Changes from v1:
>>> - Don't touch drivers/usb/renesas_usbhs/common.h.
>>> - Add acked-by from Sebastian Reichel (for drivers/power/supply/)
>>> - Add acked-by from Chen-Yu Tsai (for phy-sun4i-usb.c & extcon-axp288.c)
>>> - Add acked-by from Charles Keepax (for drivers/extcon/extcon-arizona.c)
>>> - Add acked-by from Lee Jones (fo include/linux/mfd/palmas.h)
>>>
>>>  drivers/extcon/extcon-adc-jack.c  |   2 +-
>>>  drivers/extcon/extcon-arizona.c   |   2 +-
>>>  drivers/extcon/extcon-axp288.c|   2 +-
>>>  drivers/extcon/extcon-gpio.c  |   2 +-
>>>  drivers/extcon/extcon-intel-cht-wc.c  |   2 +-
>>>  drivers/extcon/extcon-intel-int3496.c |   2 +-
>>>  drivers/extcon/extcon-max14577.c  |   2 +-
>>>  drivers/extcon/extcon-max3355.c   |   2 +-
>>>  drivers/extcon/extcon-max77693.c  |   2 +-
>>>  drivers/extcon/extcon-max77843.c  |   2 +-
>>>  drivers/extcon/extcon-max8997.c   |   2 +-
>>>  drivers/extcon/extcon-qcom-spmi-misc.c|   2 +-
>>>  drivers/extcon/extcon-rt8973a.c   |   2 +-
>>>  drivers/extcon/extcon-sm5502.c|   2 +-
>>>  drivers/extcon/extcon-usb-gpio.c  |   2 +-
>>>  drivers/extcon/extcon-usbc-cros-ec.c  |   2 +-
>>>  drivers/extcon/extcon.h   |   2 +-
>>>  drivers/phy/allwinner/phy-sun4i-usb.c |   2 +-
>>>  drivers/phy/broadcom/phy-bcm-ns2-usbdrd.c |   2 +-
>>>  drivers/phy/renesas/phy-rcar-gen3-usb2.c  |   2 +-
>>>  drivers/phy/rockchip/phy-rockchip-inno-usb2.c |   2 +-
>>>

Re: [PATCHv4 0/2] dwc3 on XU3

[Kishon Vijay Abraham I]

On Monday 09 October 2017 05:30 PM, Andrzej Pietrasiewicz wrote:
> Hi all,
> 
> This is the fourth version of patches in this thread.
> 
> The series fixes problems with enumerating of SuperSpeed devices
> on an Odroid XU3. There was a patch series from Vivek Gautam in
> circulation, but it got lost somehow. Please see:
> 
> https://lkml.org/lkml/2014/9/2/166
> https://lkml.org/lkml/2015/2/2/257
> 
> I adapted his patch so that it does not use a hacky solution to force
> additional initialization in order for calibration to happen.
> With this patch enumeration happens correctly and a super speed device
> is recognized as such.
> 
> Changes since v3:
> 
> - improved the commit message in phy_calibrate() commit
>   (as suggested by Kishon)
> - rebased onto v4.14-rc4

merged, thanks!

-Kishon
> 
> Changes since v2:
> 
> - exported the "calibrate_phy" symbol
> 
> Changes since v1:
> 
> - added calibrate() callback to phy
> - used calibrate() instead of reset() to trigger the calibration
> 
> Andrzej Pietrasiewicz (1):
>   drivers: phy: add calibrate method
> 
> Vivek Gautam (1):
>   phy: exynos5-usbdrd: Calibrate LOS levels for exynos5420/5800
> 
>  drivers/phy/phy-core.c   |  15 +++
>  drivers/phy/samsung/phy-exynos5-usbdrd.c | 183 
> +++
>  drivers/usb/dwc3/core.c  |   7 +-
>  include/linux/phy/phy.h  |  10 ++
>  4 files changed, 213 insertions(+), 2 deletions(-)
> 
--
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: [PATCHv3 1/2] drivers: phy: add calibrate method

[Kishon Vijay Abraham I]

Hi,

On Thursday 05 October 2017 05:41 PM, Andrzej Pietrasiewicz wrote:
> Some quirky UDCs (like dwc3 on exynos) need to have heir phys calibrated

%s/heir/their
> e.g. for using super speed.

The commit log should also include when phy calibrate should be used and why
existing API's is not sufficient for initializing/calibrating the phy.

Thanks
Kishon
> 
> Signed-off-by: Andrzej Pietrasiewicz 
> ---
>  drivers/phy/phy-core.c  | 15 +++
>  include/linux/phy/phy.h | 10 ++
>  2 files changed, 25 insertions(+)
> 
> diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
> index a268f4d..b4964b0 100644
> --- a/drivers/phy/phy-core.c
> +++ b/drivers/phy/phy-core.c
> @@ -372,6 +372,21 @@ int phy_reset(struct phy *phy)
>  }
>  EXPORT_SYMBOL_GPL(phy_reset);
>  
> +int phy_calibrate(struct phy *phy)
> +{
> + int ret;
> +
> + if (!phy || !phy->ops->calibrate)
> + return 0;
> +
> + mutex_lock(>mutex);
> + ret = phy->ops->calibrate(phy);
> + mutex_unlock(>mutex);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(phy_calibrate);
> +
>  /**
>   * _of_phy_get() - lookup and obtain a reference to a phy by phandle
>   * @np: device_node for which to get the phy
> diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
> index e694d40..87580c8 100644
> --- a/include/linux/phy/phy.h
> +++ b/include/linux/phy/phy.h
> @@ -39,6 +39,7 @@ enum phy_mode {
>   * @power_off: powering off the phy
>   * @set_mode: set the mode of the phy
>   * @reset: resetting the phy
> + * @calibrate: calibrate the phy
>   * @owner: the module owner containing the ops
>   */
>  struct phy_ops {
> @@ -48,6 +49,7 @@ struct phy_ops {
>   int (*power_off)(struct phy *phy);
>   int (*set_mode)(struct phy *phy, enum phy_mode mode);
>   int (*reset)(struct phy *phy);
> + int (*calibrate)(struct phy *phy);
>   struct module *owner;
>  };
>  
> @@ -141,6 +143,7 @@ static inline void *phy_get_drvdata(struct phy *phy)
>  int phy_power_off(struct phy *phy);
>  int phy_set_mode(struct phy *phy, enum phy_mode mode);
>  int phy_reset(struct phy *phy);
> +int phy_calibrate(struct phy *phy);
>  static inline int phy_get_bus_width(struct phy *phy)
>  {
>   return phy->attrs.bus_width;
> @@ -262,6 +265,13 @@ static inline int phy_reset(struct phy *phy)
>   return -ENOSYS;
>  }
>  
> +static inline int phy_calibrate(struct phy *phy)
> +{
> + if (!phy)
> + return 0;
> + return -ENOSYS;
> +}
> +
>  static inline int phy_get_bus_width(struct phy *phy)
>  {
>   return -ENOSYS;
> 
--
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: [PATCHv2 0/2]

[Kishon Vijay Abraham I]

Hi,

On Tuesday 03 October 2017 06:29 PM, Andrzej Pietrasiewicz wrote:
> Hi all,
> 
> This is the second version of patches in this thread.
> 
> The series fixes problems with enumerating of SuperSpeed devices
> on an Odroid XU3. There was a patch series from Vivek Gautam in
> circulation, but it got lost somehow. Please see:
> 
> https://lkml.org/lkml/2014/9/2/166
> https://lkml.org/lkml/2015/2/2/257
> 
> I adapted his patch so that it does not use a hacky solution to force
> additional initialization in order for calibration to happen.
> With this patch enumeration happens correctly and a super speed device
> is recognized as such.
> 
> @Kishon:
> 
> As far as I understand what you suggest is to move phy_init() and
> phy_power_on() invocations from dwc3/core.c to xhci-plat, but,
> to the best of my knowledge, they are needed in device mode, too.

What I meant is perform phy initializations for host mode in xhci and keep only
device mode phy initialization in dwc3.

Thanks
Kishon
--
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] phy: exynos5-usbdrd: Calibrate LOS levels for exynos5420/5800

[Kishon Vijay Abraham I]

Hi,

On Monday 18 September 2017 07:50 PM, Andrzej Pietrasiewicz wrote:
> Hi,
> 
> W dniu 18.09.2017 o 14:43, Felipe Balbi pisze:
>>
>> Hi,
>>
>> Andrzej Pietrasiewicz  writes:
>>> +static int exynos5_usbdrd_phy_reset(struct phy *phy)
>>> +{
>>> +struct phy_usb_instance *inst = phy_get_drvdata(phy);
>>> +struct exynos5_usbdrd_phy *phy_drd = to_usbdrd_phy(inst);
>>> +
>>> +return exynos5420_usbdrd_phy_calibrate(phy_drd);
>>> +}
>>> +
>>> static const struct phy_ops exynos5_usbdrd_phy_ops = {
>>> .init= exynos5_usbdrd_phy_init,
>>> .exit= exynos5_usbdrd_phy_exit,
>>> .power_on= exynos5_usbdrd_phy_power_on,
>>> .power_off= exynos5_usbdrd_phy_power_off,
>>> +.reset= exynos5_usbdrd_phy_reset,
>>> .owner= THIS_MODULE,
>>> };
>>> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
>>> index 03474d3..1d5836e 100644
>>> --- a/drivers/usb/dwc3/core.c
>>> +++ b/drivers/usb/dwc3/core.c
>>> @@ -156,9 +156,10 @@ static void __dwc3_set_mode(struct work_struct 
>>> *work)
>>> } else {
>>> if (dwc->usb2_phy)
>>> otg_set_vbus(dwc->usb2_phy->otg, true);
>>> -if (dwc->usb2_generic_phy)
>>> +if (dwc->usb2_generic_phy) {
>>> phy_set_mode(dwc->usb2_generic_phy, 
>>> PHY_MODE_USB_HOST);
>>> -
>>> +phy_reset(dwc->usb2_generic_phy);
>>
>> it doesn't look like this is the best place to reset the phy. Also,
>
> right, phy_reset is done during initialization before
> phy_power_on/phy_init or
> in error cases.
>
>> ->reset() doesn't seem to match correctly with a calibration. That seems
>> to be more fitting to a ->power_on() or ->init() implementation.
>
> yeah, the initial patch seems to calibrate in phy_init(). Not sure why 
> it's
> modified.

 The original patch used a hack like below, in xhci_plat_probe():

 +   /* Initialize and power-on USB 3.0 PHY */
 +   xhci->shared_hcd->phy->init_count = 0;
 +   ret = phy_init(xhci->shared_hcd->phy);
 +   if (ret)
 +   goto dealloc_usb3_hcd;
 +
 +   xhci->shared_hcd->phy->power_count = 0;
 +   ret = phy_power_on(xhci->shared_hcd->phy);
 +   if (ret) {
 +   phy_exit(xhci->shared_hcd->phy);
 +   goto dealloc_usb3_hcd;
 +   }
 +

 Manually setting init_count to 0 in order for the subsequent phy_init() to
 happen probably does not look good.

 The calibration is clearly needed. However, I don't have any strong 
 opinions
 on from which place exactly to trigger the calibration process.
 The original patch did not make it upstream, but if that patch is ok,
 it is perfectly fine with me to drop my version and take that one instead.
>>>
>>> Me bad, I did not write about an important issue.
>>> The calibration must happen after usb_add_hcd(), otherwise
>>> usb_add_hcd() indirectly triggers overwriting the effects of calibration.
>>
>> in that case, you should do that from xhci-plat indeed. I think the
>> whole idea with init_count is just to make sure you don't initialize it
>> twice.
> 
> As far as I understand the code in question the desired result is exactly the
> opposite:
> to make sure it _does_ initialize twice, otherwise after the first
> initialization the
> calibration results were lost. In other words, in the code snippet above,
> in xhci_plat_probe() the phy_init() was creatively (ab)used in order to force
> the calibration at a desired moment, while in the original invocation of
> phy_init()
> the calibration result was merely a short-term side effect discarded soon
> afterwards.
> 
>>
>> One thing's for sure, ->reset() doesn't seem to be the matching callback
>> for you to use and, given your explanation above, dwc3 doesn't seem to
>> be the right place to fiddle with that.
>>
>> Seems like we need an extension of the generic PHY framework to cope
>> with your requirement.
>>
> 
> Here are old patches from Vivek:
> 
> https://lkml.org/lkml/2014/9/2/166
> 
> In particular:
> 
> https://lkml.org/lkml/2014/9/2/170
> 
> Please see the discussion that follows the latter.
> 
> All in all, is adding the calibrate() method to phy_ops the way to go or not?

Adding calibrate is fine but doing init() and power_on() in one driver and
calibrate() in another doesn't look correct. Why not let xhci do init() and
power_on() of phy instead of dwc3?

Thanks
Kishon
--
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 1/2] phy: phy-mtk-tphy: fix NULL point of chip bank

[Kishon Vijay Abraham I]

On Thursday 21 September 2017 04:01 PM, Chunfeng Yun wrote:
> Chip bank of version-1 is initialized as NULL, but it's used
> by pcie_phy_instance_power_on/off(), so assign it a right
> address.

merged. How was this not noticed before?

Thanks
Kishon
> 
> Signed-off-by: Chunfeng Yun 
> ---
>  drivers/phy/mediatek/phy-mtk-tphy.c |3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/phy/mediatek/phy-mtk-tphy.c 
> b/drivers/phy/mediatek/phy-mtk-tphy.c
> index e3baad7..721a2a1 100644
> --- a/drivers/phy/mediatek/phy-mtk-tphy.c
> +++ b/drivers/phy/mediatek/phy-mtk-tphy.c
> @@ -27,6 +27,7 @@
>  /* banks shared by multiple phys */
>  #define SSUSB_SIFSLV_V1_SPLLC0x000   /* shared by u3 phys */
>  #define SSUSB_SIFSLV_V1_U2FREQ   0x100   /* shared by u2 phys */
> +#define SSUSB_SIFSLV_V1_CHIP 0x300   /* shared by u3 phys */
>  /* u2 phy bank */
>  #define SSUSB_SIFSLV_V1_U2PHY_COM0x000
>  /* u3/pcie/sata phy banks */
> @@ -762,7 +763,7 @@ static void phy_v1_banks_init(struct mtk_tphy *tphy,
>   case PHY_TYPE_USB3:
>   case PHY_TYPE_PCIE:
>   u3_banks->spllc = tphy->sif_base + SSUSB_SIFSLV_V1_SPLLC;
> - u3_banks->chip = NULL;
> + u3_banks->chip = tphy->sif_base + SSUSB_SIFSLV_V1_CHIP;
>   u3_banks->phyd = instance->port_base + SSUSB_SIFSLV_V1_U3PHYD;
>   u3_banks->phya = instance->port_base + SSUSB_SIFSLV_V1_U3PHYA;
>   break;
> 
--
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] phy: exynos5-usbdrd: Calibrate LOS levels for exynos5420/5800

[Kishon Vijay Abraham I]

Hi,

On Monday 18 September 2017 04:08 PM, Felipe Balbi wrote:
> 
> Hi,
> 
> Andrzej Pietrasiewicz  writes:
>> From: Vivek Gautam 
>>
>> Adding phy calibration sequence for USB 3.0 DRD PHY present on
>> Exynos5420/5800 systems.
>> This calibration facilitates setting certain PHY parameters viz.
>> the Loss-of-Signal (LOS) Detector Threshold Level, as well as
>> Tx-Vboost-Level for Super-Speed operations.
>> Additionally we also set proper time to wait for RxDetect measurement,
>> for desired PHY reference clock, so as to solve issue with enumeration
>> of few USB 3.0 devices, like Samsung SUM-TSB16S 3.0 USB drive
>> on the controller.
>>
>> We are using CR_port for this purpose to send required data
>> to override the LOS values.
>>
>> On testing with USB 3.0 devices on USB 3.0 port present on
>> SMDK5420, and peach-pit boards should see following message:
>> usb 2-1: new SuperSpeed USB device number 2 using xhci-hcd
>>
>> and without this patch, should see below shown message:
>> usb 1-1: new high-speed USB device number 2 using xhci-hcd
>>
>> [Also removed unnecessary extra lines in the register macro definitions]
>>
>> Signed-off-by: Vivek Gautam 
>> [adapted to use phy_reset as entry point]
>> Signed-off-by: Andrzej Pietrasiewicz 
>> ---
>>  drivers/phy/samsung/phy-exynos5-usbdrd.c | 183 
>> +++
>>  drivers/usb/dwc3/core.c  |   8 +-
>>  2 files changed, 189 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/phy/samsung/phy-exynos5-usbdrd.c 
>> b/drivers/phy/samsung/phy-exynos5-usbdrd.c
>> index 7c41daa..f7de067 100644
>> --- a/drivers/phy/samsung/phy-exynos5-usbdrd.c
>> +++ b/drivers/phy/samsung/phy-exynos5-usbdrd.c
>> @@ -89,7 +89,17 @@
>>  #define PHYCLKRST_COMMONONN BIT(0)
>>  
>>  #define EXYNOS5_DRD_PHYREG0 0x14
>> +#define PHYREG0_SSC_REF_CLK_SEL BIT(21)
>> +#define PHYREG0_SSC_RANGE   BIT(20)
>> +#define PHYREG0_CR_WRITEBIT(19)
>> +#define PHYREG0_CR_READ BIT(18)
>> +#define PHYREG0_CR_DATA_IN(_x)  ((_x) << 2)
>> +#define PHYREG0_CR_CAP_DATA BIT(1)
>> +#define PHYREG0_CR_CAP_ADDR BIT(0)
>> +
>>  #define EXYNOS5_DRD_PHYREG1 0x18
>> +#define PHYREG1_CR_DATA_OUT(_x) ((_x) << 1)
>> +#define PHYREG1_CR_ACK  BIT(0)
>>  
>>  #define EXYNOS5_DRD_PHYPARAM0   0x1c
>>  
>> @@ -118,6 +128,25 @@
>>  #define EXYNOS5_DRD_PHYRESUME   0x34
>>  #define EXYNOS5_DRD_LINKPORT0x44
>>  
>> +/* USB 3.0 DRD PHY SS Function Control Reg; accessed by CR_PORT */
>> +#define EXYNOS5_DRD_PHYSS_LOSLEVEL_OVRD_IN  (0x15)
>> +#define LOSLEVEL_OVRD_IN_LOS_BIAS_5420  (0x5 << 13)
>> +#define LOSLEVEL_OVRD_IN_LOS_BIAS_DEFAULT   (0x0 << 13)
>> +#define LOSLEVEL_OVRD_IN_EN (0x1 << 10)
>> +#define LOSLEVEL_OVRD_IN_LOS_LEVEL_DEFAULT  (0x9 << 0)
>> +
>> +#define EXYNOS5_DRD_PHYSS_TX_VBOOSTLEVEL_OVRD_IN(0x12)
>> +#define TX_VBOOSTLEVEL_OVRD_IN_VBOOST_5420  (0x5 << 13)
>> +#define TX_VBOOSTLEVEL_OVRD_IN_VBOOST_DEFAULT   (0x4 << 13)
>> +
>> +#define EXYNOS5_DRD_PHYSS_LANE0_TX_DEBUG(0x1010)
>> +#define LANE0_TX_DEBUG_RXDET_MEAS_TIME_19M2_20M (0x4 << 4)
>> +#define LANE0_TX_DEBUG_RXDET_MEAS_TIME_24M  (0x8 << 4)
>> +#define LANE0_TX_DEBUG_RXDET_MEAS_TIME_25M_26M  (0x8 << 4)
>> +#define LANE0_TX_DEBUG_RXDET_MEAS_TIME_48M_50M_52M  (0x20 << 4)
>> +#define LANE0_TX_DEBUG_RXDET_MEAS_TIME_62M5 (0x20 << 4)
>> +#define LANE0_TX_DEBUG_RXDET_MEAS_TIME_96M_100M (0x40 << 4)
>> +
>>  #define KHZ 1000
>>  #define MHZ (KHZ * KHZ)
>>  
>> @@ -526,6 +555,151 @@ static int exynos5_usbdrd_phy_power_off(struct phy 
>> *phy)
>>  return 0;
>>  }
>>  
>> +static int crport_handshake(struct exynos5_usbdrd_phy *phy_drd,
>> +u32 val, u32 cmd)
>> +{
>> +u32 usec = 100;
>> +unsigned int result;
>> +
>> +writel(val | cmd, phy_drd->reg_phy + EXYNOS5_DRD_PHYREG0);
>> +
>> +do {
>> +result = readl(phy_drd->reg_phy + EXYNOS5_DRD_PHYREG1);
>> +if (result & PHYREG1_CR_ACK)
>> +break;
>> +
>> +udelay(1);
>> +} while (usec-- > 0);
>> +
>> +if (!usec) {
>> +dev_err(phy_drd->dev,
>> +"CRPORT handshake timeout1 (0x%08x)\n", val);
>> +return -ETIME;
>> +}
>> +
>> +usec = 100;
>> +
>> +writel(val, phy_drd->reg_phy + EXYNOS5_DRD_PHYREG0);
>> +
>> +do {
>> +result = readl(phy_drd->reg_phy + EXYNOS5_DRD_PHYREG1);
>> +if (!(result & PHYREG1_CR_ACK))
>> +break;
>> +
>> +

Re: [PATCH 4/4] dt-bindings: phy-mt65xx-usb: supports PCIe, SATA and rename file

[Kishon Vijay Abraham I]

Chunfeng

On Thursday 03 August 2017 03:50 PM, Chunfeng Yun wrote:
> hi,
> 
> I made a mistake, please ignore the patches with Change-Id, very sorry

No problem. However can you resend the series after fixing all checkpatch 
warnings?

Thanks
Kishon
--
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/5] phy: phy-bcm-ns2-usbdrd: Replace the deprecated extcon API

[Kishon Vijay Abraham I]

On Monday 17 July 2017 06:50 AM, Chanwoo Choi wrote:
> This patch replaces the deprecated extcon API as following:
> - extcon_set_cable_state_() -> extcon_get_state()
> 
> Cc: Kishon Vijay Abraham I <kis...@ti.com>
> Cc: Raviteja Garimella <raviteja.garime...@broadcom.com>
> Signed-off-by: Chanwoo Choi <cw00.c...@samsung.com>

Acked-by: Kishon Vijay Abraham I <kis...@ti.com>
> ---
>  drivers/phy/broadcom/phy-bcm-ns2-usbdrd.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/phy/broadcom/phy-bcm-ns2-usbdrd.c 
> b/drivers/phy/broadcom/phy-bcm-ns2-usbdrd.c
> index 9ae59e223131..d099a0c8cee5 100644
> --- a/drivers/phy/broadcom/phy-bcm-ns2-usbdrd.c
> +++ b/drivers/phy/broadcom/phy-bcm-ns2-usbdrd.c
> @@ -253,16 +253,16 @@ static void extcon_work(struct work_struct *work)
>   vbus = gpiod_get_value_cansleep(driver->vbus_gpiod);
>  
>   if (!id && vbus) { /* Host connected */
> - extcon_set_cable_state_(driver->edev, EXTCON_USB_HOST, true);
> + extcon_set_state_sync(driver->edev, EXTCON_USB_HOST, true);
>   pr_debug("Host cable connected\n");
>   driver->data->new_state = EVT_HOST;
>   connect_change(driver);
>   } else if (id && !vbus) { /* Disconnected */
> - extcon_set_cable_state_(driver->edev, EXTCON_USB_HOST, false);
> - extcon_set_cable_state_(driver->edev, EXTCON_USB, false);
> + extcon_set_state_sync(driver->edev, EXTCON_USB_HOST, false);
> + extcon_set_state_sync(driver->edev, EXTCON_USB, false);
>   pr_debug("Cable disconnected\n");
>   } else if (id && vbus) { /* Device connected */
> - extcon_set_cable_state_(driver->edev, EXTCON_USB, true);
> + extcon_set_state_sync(driver->edev, EXTCON_USB, true);
>   pr_debug("Device cable connected\n");
>   driver->data->new_state = EVT_DEVICE;
>   connect_change(driver);
> 
--
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/5] phy: rockchip-inno-usb2: Replace the extcon API

[Kishon Vijay Abraham I]

On Monday 17 July 2017 06:50 AM, Chanwoo Choi wrote:
> This patch uses the resource-managed extcon API for extcon_register_notifier()
> and replaces the deprecated extcon API as following:
> - extcon_get_cable_state_() -> extcon_get_state()
> - extcon_set_cable_state_() -> extcon_set_state_sync()
> 
> Cc: linux-rockc...@lists.infradead.org
> acked-by: Kishon Vijay Abraham I <kis...@ti.com>
  ^
should be 'A' here.

-Kishon

> Signed-off-by: Chanwoo Choi <cw00.c...@samsung.com>
> ---
>  drivers/phy/rockchip/phy-rockchip-inno-usb2.c | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/phy/rockchip/phy-rockchip-inno-usb2.c 
> b/drivers/phy/rockchip/phy-rockchip-inno-usb2.c
> index 626883d9d176..ef033089b7a0 100644
> --- a/drivers/phy/rockchip/phy-rockchip-inno-usb2.c
> +++ b/drivers/phy/rockchip/phy-rockchip-inno-usb2.c
> @@ -545,7 +545,7 @@ static void rockchip_usb2phy_otg_sm_work(struct 
> work_struct *work)
>   rockchip_usb2phy_power_off(rport->phy);
>   /* fall through */
>   case OTG_STATE_B_IDLE:
> - if (extcon_get_cable_state_(rphy->edev, EXTCON_USB_HOST) > 0) {
> + if (extcon_get_state(rphy->edev, EXTCON_USB_HOST) > 0) {
>   dev_dbg(>phy->dev, "usb otg host connect\n");
>   rport->state = OTG_STATE_A_HOST;
>   rockchip_usb2phy_power_on(rport->phy);
> @@ -598,7 +598,7 @@ static void rockchip_usb2phy_otg_sm_work(struct 
> work_struct *work)
>   rport->vbus_attached = vbus_attach;
>  
>   if (notify_charger && rphy->edev) {
> - extcon_set_cable_state_(rphy->edev,
> + extcon_set_state_sync(rphy->edev,
>   cable, vbus_attach);
>   if (cable == EXTCON_CHG_USB_SDP)
>   extcon_set_state_sync(rphy->edev,
> @@ -619,7 +619,7 @@ static void rockchip_usb2phy_otg_sm_work(struct 
> work_struct *work)
>   sch_work = true;
>   break;
>   case OTG_STATE_A_HOST:
> - if (extcon_get_cable_state_(rphy->edev, EXTCON_USB_HOST) == 0) {
> + if (extcon_get_state(rphy->edev, EXTCON_USB_HOST) == 0) {
>   dev_dbg(>phy->dev, "usb otg host disconnect\n");
>   rport->state = OTG_STATE_B_IDLE;
>   rockchip_usb2phy_power_off(rport->phy);
> @@ -1006,8 +1006,8 @@ static int rockchip_usb2phy_otg_port_init(struct 
> rockchip_usb2phy *rphy,
>   if (!IS_ERR(rphy->edev)) {
>   rport->event_nb.notifier_call = rockchip_otg_event;
>  
> - ret = extcon_register_notifier(rphy->edev, EXTCON_USB_HOST,
> ->event_nb);
> + ret = devm_extcon_register_notifier(rphy->dev, rphy->edev,
> + EXTCON_USB_HOST, >event_nb);
>   if (ret)
>   dev_err(rphy->dev, "register USB HOST notifier 
> failed\n");
>   }
> 
--
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] phy: qcom-qmp: Fix failure path in phy_init functions

[Kishon Vijay Abraham I]

Vivek,

On Monday 31 July 2017 10:58 AM, Vivek Gautam wrote:
> Hi Kishon,
> 
> 
> On Tue, Jun 20, 2017 at 11:27 AM, Vivek Gautam
> <vivek.gau...@codeaurora.org> wrote:
>> Fixing the clk enable failure path in qcom_qmp_phy_init()
>> and cleanup the reset control deassertion failure path in
>> qcom_qmp_phy_com_init().
>>
>> Fixes: e78f3d15e115 ("phy: qcom-qmp: new qmp phy driver for qcom-chipsets")
>>
>> Cc: Kishon Vijay Abraham I <kis...@ti.com>
>> Signed-off-by: Vivek Gautam <vivek.gau...@codeaurora.org>
> 
> This patch got missed. Can you please pull this in?

merged now, thanks!

-Kishon
> 
> regards
> Vivek
> 
>> ---
>>  drivers/phy/qualcomm/phy-qcom-qmp.c | 15 ++-
>>  1 file changed, 6 insertions(+), 9 deletions(-)
>>
>> diff --git a/drivers/phy/qualcomm/phy-qcom-qmp.c 
>> b/drivers/phy/qualcomm/phy-qcom-qmp.c
>> index 78ca62897784..7b739571b301 100644
>> --- a/drivers/phy/qualcomm/phy-qcom-qmp.c
>> +++ b/drivers/phy/qualcomm/phy-qcom-qmp.c
>> @@ -654,8 +654,6 @@ static int qcom_qmp_phy_com_init(struct qcom_qmp *qmp)
>> if (ret) {
>> dev_err(qmp->dev, "%s reset deassert failed\n",
>> qmp->cfg->reset_list[i]);
>> -   while (--i >= 0)
>> -   reset_control_assert(qmp->resets[i]);
>> goto err_rst;
>> }
>> }
>> @@ -684,7 +682,7 @@ static int qcom_qmp_phy_com_init(struct qcom_qmp *qmp)
>> if (ret) {
>> dev_err(qmp->dev,
>> "phy common block init timed-out\n");
>> -   goto err_com_init;
>> +   goto err_rst;
>> }
>> }
>>
>> @@ -692,11 +690,11 @@ static int qcom_qmp_phy_com_init(struct qcom_qmp *qmp)
>>
>> return 0;
>>
>> -err_com_init:
>> +err_rst:
>> while (--i >= 0)
>> reset_control_assert(qmp->resets[i]);
>> -err_rst:
>> mutex_unlock(>phy_mutex);
>> +
>> return ret;
>>  }
>>
>> @@ -749,14 +747,13 @@ static int qcom_qmp_phy_init(struct phy *phy)
>> if (ret) {
>> dev_err(qmp->dev, "failed to enable %s clk, 
>> err=%d\n",
>> qmp->cfg->clk_list[i], ret);
>> -   while (--i >= 0)
>> -   clk_disable_unprepare(qmp->clks[i]);
>> +   goto err_clk;
>> }
>> }
>>
>> ret = qcom_qmp_phy_com_init(qmp);
>> if (ret)
>> -   goto err_com_init;
>> +   goto err_clk;
>>
>> if (cfg->has_lane_rst) {
>> ret = reset_control_deassert(qphy->lane_rst);
>> @@ -804,7 +801,7 @@ static int qcom_qmp_phy_init(struct phy *phy)
>> reset_control_assert(qphy->lane_rst);
>>  err_lane_rst:
>> qcom_qmp_phy_com_exit(qmp);
>> -err_com_init:
>> +err_clk:
>> while (--i >= 0)
>> clk_disable_unprepare(qmp->clks[i]);
>>
>> --
>> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
>> a Linux Foundation Collaborative Project
>>
> 
> 
> 
--
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] phy: cpcap-usb: Fix missing return statement

[Kishon Vijay Abraham I]

On Monday 12 June 2017 01:42 PM, Tony Lindgren wrote:
> Commit 8ae904e3c236 ("phy: cpcap-usb: Add CPCAP PMIC USB support")
> is missing return statement as noted by Colin Ian King
> . If the optional pins are not configured,
> we just want to return early and not attempt to configure the pins.
> 
> Fixes: 8ae904e3c236 ("phy: cpcap-usb: Add CPCAP PMIC USB support")
> Reported-by: Colin Ian King 
> Signed-off-by: Tony Lindgren 

merged, thanks!

-Kishon
> ---
>  drivers/phy/motorola/phy-cpcap-usb.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/phy/motorola/phy-cpcap-usb.c 
> b/drivers/phy/motorola/phy-cpcap-usb.c
> --- a/drivers/phy/motorola/phy-cpcap-usb.c
> +++ b/drivers/phy/motorola/phy-cpcap-usb.c
> @@ -468,6 +468,8 @@ static int cpcap_usb_init_optional_pins(struct 
> cpcap_phy_ddata *ddata)
>   dev_info(ddata->dev, "default pins not configured: %ld\n",
>PTR_ERR(ddata->pins));
>   ddata->pins = NULL;
> +
> + return 0;
>   }
>  
>   ddata->pins_ulpi = pinctrl_lookup_state(ddata->pins, "ulpi");
> 
--
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 2/2] phy: tusb1210: implement ->set_mode()

[Kishon Vijay Abraham I]

On Friday 09 June 2017 03:50 PM, Felipe Balbi wrote:
> ->set_mode() can be used to tell PHY to prepare itself to enter USB
> Host/Peripheral mode and that's very important for DRD
> configurations.
> 
> Signed-off-by: Felipe Balbi 
> 
> changes since v1:
>   - rebase on PHY -next

removed this changelog and merged,

Thanks
Kishon
> 
> 
> ---
>  drivers/phy/ti/phy-tusb1210.c | 35 +++
>  1 file changed, 35 insertions(+)
> 
> diff --git a/drivers/phy/ti/phy-tusb1210.c b/drivers/phy/ti/phy-tusb1210.c
> index 5dbb9a7b4945..b8ec39ac4dfc 100644
> --- a/drivers/phy/ti/phy-tusb1210.c
> +++ b/drivers/phy/ti/phy-tusb1210.c
> @@ -11,6 +11,7 @@
>   */
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  
> @@ -52,9 +53,43 @@ static int tusb1210_power_off(struct phy *phy)
>   return 0;
>  }
>  
> +static int tusb1210_set_mode(struct phy *phy, enum phy_mode mode)
> +{
> + struct tusb1210 *tusb = phy_get_drvdata(phy);
> + int ret;
> +
> + ret = ulpi_read(tusb->ulpi, ULPI_OTG_CTRL);
> + if (ret < 0)
> + return ret;
> +
> + switch (mode) {
> + case PHY_MODE_USB_HOST:
> + ret |= (ULPI_OTG_CTRL_DRVVBUS_EXT
> + | ULPI_OTG_CTRL_ID_PULLUP
> + | ULPI_OTG_CTRL_DP_PULLDOWN
> + | ULPI_OTG_CTRL_DM_PULLDOWN);
> + ulpi_write(tusb->ulpi, ULPI_OTG_CTRL, ret);
> + ret |= ULPI_OTG_CTRL_DRVVBUS;
> + break;
> + case PHY_MODE_USB_DEVICE:
> + ret &= ~(ULPI_OTG_CTRL_DRVVBUS
> +  | ULPI_OTG_CTRL_DP_PULLDOWN
> +  | ULPI_OTG_CTRL_DM_PULLDOWN);
> + ulpi_write(tusb->ulpi, ULPI_OTG_CTRL, ret);
> + ret &= ~ULPI_OTG_CTRL_DRVVBUS_EXT;
> + break;
> + default:
> + /* nothing */
> + return 0;
> + }
> +
> + return ulpi_write(tusb->ulpi, ULPI_OTG_CTRL, ret);
> +}
> +
>  static const struct phy_ops phy_ops = {
>   .power_on = tusb1210_power_on,
>   .power_off = tusb1210_power_off,
> + .set_mode = tusb1210_set_mode,
>   .owner = THIS_MODULE,
>  };
>  
> 
--
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] phy: tusb1210: add support for TUSB1211

[Kishon Vijay Abraham I]

On Friday 09 June 2017 03:50 PM, Felipe Balbi wrote:
> TUSB1211 is software compatible with TUSB1210 and as such we don't
> need an entire new driver to control it. Let's add its product ID to
> the existing TUSB1210 driver instead.
> 
> Signed-off-by: Felipe Balbi 

merged this series, thanks!

-Kishon
> ---
> 
> changes since v1:
>   - rebase on PHY -next
> 
>  drivers/phy/ti/phy-tusb1210.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/phy/ti/phy-tusb1210.c b/drivers/phy/ti/phy-tusb1210.c
> index bb3fb031c478..5dbb9a7b4945 100644
> --- a/drivers/phy/ti/phy-tusb1210.c
> +++ b/drivers/phy/ti/phy-tusb1210.c
> @@ -124,7 +124,8 @@ static void tusb1210_remove(struct ulpi *ulpi)
>  #define TI_VENDOR_ID 0x0451
>  
>  static const struct ulpi_device_id tusb1210_ulpi_id[] = {
> - { TI_VENDOR_ID, 0x1507, },
> + { TI_VENDOR_ID, 0x1507, },  /* TUSB1210 */
> + { TI_VENDOR_ID, 0x1508, },  /* TUSB1211 */
>   { },
>  };
>  MODULE_DEVICE_TABLE(ulpi, tusb1210_ulpi_id);
> 
--
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] phy: tusb1210: add support for TUSB1211

[Kishon Vijay Abraham I]

Hi,

On Friday 09 June 2017 03:27 PM, Felipe Balbi wrote:
> 
> Hi,
> 
> Kishon Vijay Abraham I <kis...@ti.com> writes:
>> On Thursday 08 June 2017 05:19 PM, Felipe Balbi wrote:
>>> TUSB1211 is software compatible with TUSB1210 and as such we don't
>>> need an entire new driver to control it. Let's add its product ID to
>>> the existing TUSB1210 driver instead.
>>>
>>> Signed-off-by: Felipe Balbi <felipe.ba...@linux.intel.com>
>>> ---
>>>  drivers/phy/phy-tusb1210.c | 3 ++-
>>
>> The directory structure in phy has changed a bit. phy-tusb1210.c is now in
>> drivers/phy/ti/.
> 
> Not in mainline yet? I can either resend after v4.13-rc1 or rebase on
> whatever branch you may have. What do you prefer?

If you can rebase it on linux-phy -next, I can pick it up.

Thanks
Kishon
--
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] phy: tusb1210: add support for TUSB1211

[Kishon Vijay Abraham I]

Hi Felipe,

On Thursday 08 June 2017 05:19 PM, Felipe Balbi wrote:
> TUSB1211 is software compatible with TUSB1210 and as such we don't
> need an entire new driver to control it. Let's add its product ID to
> the existing TUSB1210 driver instead.
> 
> Signed-off-by: Felipe Balbi 
> ---
>  drivers/phy/phy-tusb1210.c | 3 ++-

The directory structure in phy has changed a bit. phy-tusb1210.c is now in
drivers/phy/ti/.

Thanks
Kishon
--
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: [PATCHv4] phy: cpcap-usb: Add CPCAP PMIC USB support

[Kishon Vijay Abraham I]

On Tuesday 23 May 2017 06:07 AM, Tony Lindgren wrote:
> Some Motorola phones like droid 4 use a custom CPCAP PMIC that has a
> multiplexing USB PHY.
> 
> This USB PHY can operate at least in four modes using pin multiplexing
> and two control GPIOS:
> 
> - Pass through companion PHY for the SoC USB PHY
> - ULPI PHY for the SoC
> - Pass through USB for the modem
> - UART debug console for the SoC
> 
> This patch adds support for droid 4 USB PHY and debug UART modes,
> support for other modes can be added later on as needed.
> 
> Both peripheral and host mode are working for the USB. The
> host mode depends on the cpcap-charger driver for VBUS.
> 
> VBUS and ID pin detection are done using cpcap-adc IIO ADC
> driver.
> 
> Cc: devicet...@vger.kernel.org
> Cc: Marcel Partap 
> Cc: Michael Scott 
> Acked-by: Rob Herring 
> Tested-by: Sebastian Reichel 
> Signed-off-by: Tony Lindgren 

merged, thanks.

-Kishon
> ---
> 
> Changes since v3:
> - Dropped extcon based on what was discussed with Kishon as
>   we're better off with using IIO directly as we need the values
>   for VBUS and ID from IIO
> 
> - Updated against linux next and moved to drivers/phy/motorola
>   directory like other phy drivers now do
> 
> - Removed list for interrupts as it was not used
> 
> Changes since v2: 
>- Added extcon support as requested by Kishon
> 
> - Added Rob's ack
> 
> - Folded in Kconfig randconfig build fix to add depends on IIO
> 
> Changes since v1:
> - Use iio_read_channel_processed() instead of iio_read_channel_scaled()
>   as changed in the v2 of the ADC driver
> 
> - Kept Tested-by from Sebastian Reichel  as the change
>   from v1 is trivial
> 
> ---
>  .../devicetree/bindings/phy/phy-cpcap-usb.txt  |  40 ++
>  drivers/phy/Kconfig|   1 +
>  drivers/phy/Makefile   |   1 +
>  drivers/phy/motorola/Kconfig   |  11 +
>  drivers/phy/motorola/Makefile  |   5 +
>  drivers/phy/motorola/phy-cpcap-usb.c   | 674 
> +
>  6 files changed, 732 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/phy/phy-cpcap-usb.txt
>  create mode 100644 drivers/phy/motorola/Kconfig
>  create mode 100644 drivers/phy/motorola/Makefile
>  create mode 100644 drivers/phy/motorola/phy-cpcap-usb.c
> 
> diff --git a/Documentation/devicetree/bindings/phy/phy-cpcap-usb.txt 
> b/Documentation/devicetree/bindings/phy/phy-cpcap-usb.txt
> new file mode 100644
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/phy-cpcap-usb.txt
> @@ -0,0 +1,40 @@
> +Motorola CPCAP PMIC USB PHY binding
> +
> +Required properties:
> +compatible: Shall be either "motorola,cpcap-usb-phy" or
> + "motorola,mapphone-cpcap-usb-phy"
> +#phy-cells: Shall be 0
> +interrupts: CPCAP PMIC interrupts used by the USB PHY
> +interrupt-names: Interrupt names
> +io-channels: IIO ADC channels used by the USB PHY
> +io-channel-names: IIO ADC channel names
> +vusb-supply: Regulator for the PHY
> +
> +Optional properties:
> +pinctrl: Optional alternate pin modes for the PHY
> +pinctrl-names: Names for optional pin modes
> +mode-gpios: Optional GPIOs for configuring alternate modes
> +
> +Example:
> +cpcap_usb2_phy: phy {
> + compatible = "motorola,mapphone-cpcap-usb-phy";
> + pinctrl-0 = <_gpio_mux_sel1 _gpio_mux_sel2>;
> + pinctrl-1 = <_ulpi_pins>;
> + pinctrl-2 = <_utmi_pins>;
> + pinctrl-3 = <_pins>;
> + pinctrl-names = "default", "ulpi", "utmi", "uart";
> + #phy-cells = <0>;
> + interrupts-extended = <
> +  15 0  14 0  28 0  19 0
> +  18 0  17 0  16 0  49 0
> +  48 1
> + >;
> + interrupt-names =
> + "id_ground", "id_float", "se0conn", "vbusvld",
> + "sessvld", "sessend", "se1", "dm", "dp";
> + mode-gpios = < 28 GPIO_ACTIVE_HIGH
> +0 GPIO_ACTIVE_HIGH>;
> + io-channels = <_adc 2>, <_adc 7>;
> + io-channel-names = "vbus", "id";
> + vusb-supply = <>;
> +};
> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> --- a/drivers/phy/Kconfig
> +++ b/drivers/phy/Kconfig
> @@ -53,6 +53,7 @@ source "drivers/phy/amlogic/Kconfig"
>  source "drivers/phy/broadcom/Kconfig"
>  source "drivers/phy/hisilicon/Kconfig"
>  source "drivers/phy/marvell/Kconfig"
> +source "drivers/phy/motorola/Kconfig"
>  source "drivers/phy/qualcomm/Kconfig"
>  source "drivers/phy/renesas/Kconfig"
>  source "drivers/phy/rockchip/Kconfig"
> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
> --- a/drivers/phy/Makefile
> +++ b/drivers/phy/Makefile
> @@ -16,6 +16,7 @@ obj-$(CONFIG_ARCH_TEGRA)+= tegra/
>  obj-y+= broadcom/\
>  hisilicon/   \
> 

Re: [PATCH 3/3] mfd: twl: move header file out of I2C realm

[Kishon Vijay Abraham I]

On Monday 22 May 2017 03:32 AM, Wolfram Sang wrote:
> include/linux/i2c is not for client devices. Move the header file to a
> more appropriate location.
> 
> Signed-off-by: Wolfram Sang <w...@the-dreams.de>

Acked-by: Kishon Vijay Abraham I <kis...@ti.com>
> ---
>  arch/arm/mach-omap2/common.h| 2 +-
>  arch/arm/mach-omap2/omap_twl.c  | 2 +-
>  drivers/gpio/gpio-twl4030.c | 2 +-
>  drivers/iio/adc/twl4030-madc.c  | 2 +-
>  drivers/iio/adc/twl6030-gpadc.c | 2 +-
>  drivers/input/keyboard/twl4030_keypad.c | 2 +-
>  drivers/input/misc/twl4030-pwrbutton.c  | 2 +-
>  drivers/input/misc/twl4030-vibra.c  | 2 +-
>  drivers/mfd/twl-core.c  | 6 +++---
>  drivers/mfd/twl4030-audio.c | 2 +-
>  drivers/mfd/twl4030-irq.c   | 2 +-
>  drivers/mfd/twl4030-power.c | 2 +-
>  drivers/mfd/twl6030-irq.c   | 2 +-
>  drivers/phy/phy-twl4030-usb.c   | 2 +-
>  drivers/power/supply/twl4030_charger.c  | 2 +-
>  drivers/pwm/pwm-twl-led.c   | 2 +-
>  drivers/pwm/pwm-twl.c   | 2 +-
>  drivers/regulator/twl-regulator.c   | 2 +-
>  drivers/regulator/twl6030-regulator.c   | 2 +-
>  drivers/rtc/rtc-twl.c   | 2 +-
>  drivers/usb/phy/phy-twl6030-usb.c   | 2 +-
>  drivers/video/backlight/pandora_bl.c| 2 +-
>  drivers/watchdog/twl4030_wdt.c  | 2 +-
>  include/linux/{i2c => mfd}/twl.h| 0
>  sound/soc/codecs/twl4030.c  | 2 +-
>  25 files changed, 26 insertions(+), 26 deletions(-)
>  rename include/linux/{i2c => mfd}/twl.h (100%)
> 
> diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
> index 8cc6338fcb1288..b5ad7fcb80ed24 100644
> --- a/arch/arm/mach-omap2/common.h
> +++ b/arch/arm/mach-omap2/common.h
> @@ -29,7 +29,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>  #include 
>  #include 
>  #include 
> diff --git a/arch/arm/mach-omap2/omap_twl.c b/arch/arm/mach-omap2/omap_twl.c
> index 1346b3ab34a5e3..295124b248ae3f 100644
> --- a/arch/arm/mach-omap2/omap_twl.c
> +++ b/arch/arm/mach-omap2/omap_twl.c
> @@ -16,7 +16,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>  
>  #include "soc.h"
>  #include "voltage.h"
> diff --git a/drivers/gpio/gpio-twl4030.c b/drivers/gpio/gpio-twl4030.c
> index 24f388ed46d4c4..9b511df5450eb6 100644
> --- a/drivers/gpio/gpio-twl4030.c
> +++ b/drivers/gpio/gpio-twl4030.c
> @@ -35,7 +35,7 @@
>  #include 
>  #include 
>  
> -#include 
> +#include 
>  
>  /*
>   * The GPIO "subchip" supports 18 GPIOs which can be configured as
> diff --git a/drivers/iio/adc/twl4030-madc.c b/drivers/iio/adc/twl4030-madc.c
> index 0c74869a540ad3..5a64eda1652061 100644
> --- a/drivers/iio/adc/twl4030-madc.c
> +++ b/drivers/iio/adc/twl4030-madc.c
> @@ -35,7 +35,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>  #include 
>  #include 
>  #include 
> diff --git a/drivers/iio/adc/twl6030-gpadc.c b/drivers/iio/adc/twl6030-gpadc.c
> index becbb0aef232b9..bc0e60b9da452e 100644
> --- a/drivers/iio/adc/twl6030-gpadc.c
> +++ b/drivers/iio/adc/twl6030-gpadc.c
> @@ -33,7 +33,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>  #include 
>  #include 
>  
> diff --git a/drivers/input/keyboard/twl4030_keypad.c 
> b/drivers/input/keyboard/twl4030_keypad.c
> index 39e72b3219d8a4..f9f98ef1d98e3f 100644
> --- a/drivers/input/keyboard/twl4030_keypad.c
> +++ b/drivers/input/keyboard/twl4030_keypad.c
> @@ -30,7 +30,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>  #include 
>  #include 
>  
> diff --git a/drivers/input/misc/twl4030-pwrbutton.c 
> b/drivers/input/misc/twl4030-pwrbutton.c
> index 1c13005b228fa7..b307cca1702226 100644
> --- a/drivers/input/misc/twl4030-pwrbutton.c
> +++ b/drivers/input/misc/twl4030-pwrbutton.c
> @@ -27,7 +27,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>  
>  #define PWR_PWRON_IRQ (1 << 0)
>  
> diff --git a/drivers/input/misc/twl4030-vibra.c 
> b/drivers/input/misc/twl4030-vibra.c
> index caa5a62c42fbe0..6c51d404874bbd 100644
> --- a/drivers/input/misc/twl4030-vibra.c
> +++ b/drivers/input/misc/twl4030-vibra.c
> @@ -28,7 +28,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>  #include 
>  #include 
>  #include 
> diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c
> index c64615dca2bd33..2a09dde4ca6efc 100644
> --- a/drivers/mfd/twl-core.c
>

Re: [PATCH v5 3/3] phy: Group vendor specific phy drivers

[Kishon Vijay Abraham I]

Hi Vivek,

On Thursday 11 May 2017 12:17 PM, Vivek Gautam wrote:
> Adding vendor specific directories in phy to group
> phy drivers under their respective vendor umbrella.
> 
> Also updated the MAINTAINERS file to reflect the correct
> directory structure for phy drivers.
> 
> Signed-off-by: Vivek Gautam <vivek.gau...@codeaurora.org>
> Acked-by: Heiko Stuebner <he...@sntech.de>
> Acked-by: Viresh Kumar <viresh.ku...@linaro.org>
> Acked-by: Krzysztof Kozlowski <k...@kernel.org>
> Acked-by: Yoshihiro Shimoda <yoshihiro.shimoda...@renesas.com>
> Reviewed-by: Jaehoon Chung <jh80.ch...@samsung.com>
> Cc: Kishon Vijay Abraham I <kis...@ti.com>
> Cc: David S. Miller <da...@davemloft.net>
> Cc: Geert Uytterhoeven <geert+rene...@glider.be>
> Cc: Yoshihiro Shimoda <yoshihiro.shimoda...@renesas.com>
> Cc: Guenter Roeck <li...@roeck-us.net>
> Cc: Heiko Stuebner <he...@sntech.de>
> Cc: Viresh Kumar <viresh.ku...@linaro.org>
> Cc: Maxime Ripard <maxime.rip...@free-electrons.com>
> Cc: Chen-Yu Tsai <w...@csie.org>
> Cc: Sylwester Nawrocki <s.nawro...@samsung.com>
> Cc: Krzysztof Kozlowski <k...@kernel.org>
> Cc: Jaehoon Chung <jh80.ch...@samsung.com>
> Cc: Stephen Boyd <stephen.b...@linaro.org>
> Cc: Martin Blumenstingl <martin.blumensti...@googlemail.com>
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-arm-...@vger.kernel.org
> Cc: linux-ker...@vger.kernel.org
> Cc: linux-o...@vger.kernel.org
> Cc: linux-renesas-...@vger.kernel.org
> Cc: linux-rockc...@lists.infradead.org
> Cc: linux-samsung-...@vger.kernel.org
> Cc: linux-usb@vger.kernel.org
> ---
> 
> Changes since v4:
>  - Reprepared the patch based on latest torvalds/master.
>  - Added new directory for amlogic, since there's a new patch [1]
>coming in for amlogic platforms.
> 
> Changes since v3:
>  - Added 'Acked-by' and 'Reviewed by' tags received for this patch.
>  - No functional change.
> 
> Changes since v2:
>  - Rebased on linux-phy/next.
>  - Took care of drivers added/removed for each vendors since v2.
>  - Updated the 'Signed-off-by' tag with my current email id.
> 
> Changes from v1:
>  - Updated the MAINTAINERS file to reflect the same change
>in directory structure.
>  - Removed PHY_PLAT config as pointed out by Kishon.
>So we don't require the second patch in the v1 of this series:
>[PATCH 2/2] arm: mach-spear: Enable PHY_PLAT to meet dependency
>  - Renamed sunxi --> allwinner; rcar --> renesas.
>  - Fixed error coming with qcom Makefile.
> 
> * Build tested multi_v7_defconfig.
> * Build tested arm64 defconfig with all the involved configs enabled.
> 
> [1] https://patchwork.kernel.org/patch/9684303/
>
.
.

.
.
> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> index afaf7b643eeb..b353ac603ea0 100644
> --- a/drivers/phy/Kconfig
> +++ b/drivers/phy/Kconfig
> @@ -15,73 +15,6 @@ config GENERIC_PHY
> phy users can obtain reference to the PHY. All the users of this

.
.

.
.
> -
> +menu "Platform Phy drivers"

I don't think creating a new menu is required. I removed it and merged into
linux-phy.

Thanks
Kishon
--
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/3] phy: qcom-usb: Remove unused ulpi phy header

[Kishon Vijay Abraham I]

Hi Vivek,

On Thursday 11 May 2017 12:17 PM, Vivek Gautam wrote:
> Ulpi phy header is not used for anything. Remove the same
> from qcom-hs and qcom-hsic phy drivers.
> 
> Signed-off-by: Vivek Gautam <vivek.gau...@codeaurora.org>
> Suggested-by: Stephen Boyd <stephen.b...@linaro.org>
> Cc: Kishon Vijay Abraham I <kis...@ti.com>
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-arm-...@vger.kernel.org
> Cc: linux-ker...@vger.kernel.org
> Cc: linux-usb@vger.kernel.org

this patch introduced a bunch of compiler errors because of missing "#include
". I fixed it and merged to linux-phy fixes.

Thanks
Kishon
--
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/3] phy: Group vendor specific phy drivers

[Kishon Vijay Abraham I]

Hi Vivek,

On Thursday 11 May 2017 12:17 PM, Vivek Gautam wrote:
> Adding vendor specific directories in phy to group
> phy drivers under their respective vendor umbrella.
> 
> Also updated the MAINTAINERS file to reflect the correct
> directory structure for phy drivers.
> 
> Signed-off-by: Vivek Gautam <vivek.gau...@codeaurora.org>
> Acked-by: Heiko Stuebner <he...@sntech.de>
> Acked-by: Viresh Kumar <viresh.ku...@linaro.org>
> Acked-by: Krzysztof Kozlowski <k...@kernel.org>
> Acked-by: Yoshihiro Shimoda <yoshihiro.shimoda...@renesas.com>
> Reviewed-by: Jaehoon Chung <jh80.ch...@samsung.com>
> Cc: Kishon Vijay Abraham I <kis...@ti.com>
> Cc: David S. Miller <da...@davemloft.net>
> Cc: Geert Uytterhoeven <geert+rene...@glider.be>
> Cc: Yoshihiro Shimoda <yoshihiro.shimoda...@renesas.com>
> Cc: Guenter Roeck <li...@roeck-us.net>
> Cc: Heiko Stuebner <he...@sntech.de>
> Cc: Viresh Kumar <viresh.ku...@linaro.org>
> Cc: Maxime Ripard <maxime.rip...@free-electrons.com>
> Cc: Chen-Yu Tsai <w...@csie.org>
> Cc: Sylwester Nawrocki <s.nawro...@samsung.com>
> Cc: Krzysztof Kozlowski <k...@kernel.org>
> Cc: Jaehoon Chung <jh80.ch...@samsung.com>
> Cc: Stephen Boyd <stephen.b...@linaro.org>
> Cc: Martin Blumenstingl <martin.blumensti...@googlemail.com>
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-arm-...@vger.kernel.org
> Cc: linux-ker...@vger.kernel.org
> Cc: linux-o...@vger.kernel.org
> Cc: linux-renesas-...@vger.kernel.org
> Cc: linux-rockc...@lists.infradead.org
> Cc: linux-samsung-...@vger.kernel.org
> Cc: linux-usb@vger.kernel.org
> ---
> 
> Changes since v4:
>  - Reprepared the patch based on latest torvalds/master.
>  - Added new directory for amlogic, since there's a new patch [1]
>coming in for amlogic platforms.

I don't prefer placeholder directories but this is not a placeholder directory
since phy-meson8b-usb2.c is already added in amlogic.

Btw, thank you for sending this patch. Will queue this once -rc1 is tagged.

Cheers
Kishon
--
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: [PATCHv3] phy: cpcap-usb: Add CPCAP PMIC USB support

[Kishon Vijay Abraham I]

Hi Tony,

On Monday 10 April 2017 09:49 AM, Tony Lindgren wrote:
> Some Motorola phones like droid 4 use a custom CPCAP PMIC that has a
> multiplexing USB PHY.
> 
> This USB PHY can operate at least in four modes using pin multiplexing
> and two control GPIOS:
> 
> - Pass through companion PHY for the SoC USB PHY
> - ULPI PHY for the SoC
> - Pass through USB for the modem
> - UART debug console for the SoC
> 
> This patch adds support for droid 4 USB PHY and debug UART modes,
> support for other modes can be added later on as needed.
> 
> Both peripheral and host mode are working for the USB. The
> host mode depends on the cpcap-charger driver for VBUS.
> 
> VBUS and ID pin detection are done using cpcap-adc IIO ADC
> driver.

I thought of using EXTCON differently from what was used below. Actually I
thought EXTCON shuld be used in cpcap-adc driver for notifying VBUS or ID
events to phy-cpcap driver which performs the various setting based on VBUS or
ID. (See drivers/usb/dwc3/dwc3-omap.c which receives VBUS/ID notifications fo
sample). That would have simply replaced the iio* calls with EXTCON calls in
phy-cpcap-usb driver (in addition to adding extcon API's in cpcap-adc driver).

Usage of EXTCON like below is not of much use here since MUSB doesn't really
wait for notification of ID or VBUS events (This is unlike dwc3-omap. since we
invoke musb_mailbox functin directly).

If adding EXTCON in cpcap-adc isn't simple then we should stick to your patch
version 2 since extcon support in this version is not useful IMO.
> 
> Cc: devicet...@vger.kernel.org
> Cc: Marcel Partap 
> Cc: Michael Scott 
> Acked-by: Rob Herring 
> Tested-by: Sebastian Reichel 
> Signed-off-by: Tony Lindgren 
> ---
> 
> Changes since v2:
> - Added extcon support as requested by Kishon
> 
> - Added Rob's ack
> 
> - Folded in Kconfig randconfig build fix to add depends on IIO
> 
> Changes since v1:
> - Use iio_read_channel_processed() instead of iio_read_channel_scaled()
>   as changed in the v2 of the ADC driver
> 
> - Kept Tested-by from Sebastian Reichel  as the change
>   from v1 is trivial
> 
> ---
>  .../devicetree/bindings/phy/phy-cpcap-usb.txt  |  40 ++
>  drivers/phy/Kconfig|   8 +
>  drivers/phy/Makefile   |   1 +
>  drivers/phy/phy-cpcap-usb.c| 734 
> +
>  4 files changed, 783 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/phy/phy-cpcap-usb.txt
>  create mode 100644 drivers/phy/phy-cpcap-usb.c
> 
> diff --git a/Documentation/devicetree/bindings/phy/phy-cpcap-usb.txt 
> b/Documentation/devicetree/bindings/phy/phy-cpcap-usb.txt
> new file mode 100644
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/phy-cpcap-usb.txt
> @@ -0,0 +1,40 @@
> +Motorola CPCAP PMIC USB PHY binding
> +
> +Required properties:
> +compatible: Shall be either "motorola,cpcap-usb-phy" or
> + "motorola,mapphone-cpcap-usb-phy"
> +#phy-cells: Shall be 0
> +interrupts: CPCAP PMIC interrupts used by the USB PHY
> +interrupt-names: Interrupt names
> +io-channels: IIO ADC channels used by the USB PHY
> +io-channel-names: IIO ADC channel names
> +vusb-supply: Regulator for the PHY
> +
> +Optional properties:
> +pinctrl: Optional alternate pin modes for the PHY
> +pinctrl-names: Names for optional pin modes
> +mode-gpios: Optional GPIOs for configuring alternate modes
> +
> +Example:
> +cpcap_usb2_phy: phy {
> + compatible = "motorola,mapphone-cpcap-usb-phy";
> + pinctrl-0 = <_gpio_mux_sel1 _gpio_mux_sel2>;
> + pinctrl-1 = <_ulpi_pins>;
> + pinctrl-2 = <_utmi_pins>;
> + pinctrl-3 = <_pins>;
> + pinctrl-names = "default", "ulpi", "utmi", "uart";
> + #phy-cells = <0>;
> + interrupts-extended = <
> +  15 0  14 0  28 0  19 0
> +  18 0  17 0  16 0  49 0
> +  48 1
> + >;
> + interrupt-names =
> + "id_ground", "id_float", "se0conn", "vbusvld",
> + "sessvld", "sessend", "se1", "dm", "dp";
> + mode-gpios = < 28 GPIO_ACTIVE_HIGH
> +0 GPIO_ACTIVE_HIGH>;
> + io-channels = <_adc 2>, <_adc 7>;
> + io-channel-names = "vbus", "id";
> + vusb-supply = <>;
> +};

I would have preferred this to be a separate patch but since Rob has Acked it,
it is fine.

Thanks
Kishon
--
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] phy: qcom-qmp: Add dependency on COMMON_CLK

[Kishon Vijay Abraham I]

On Friday 07 April 2017 01:37 AM, Vivek Gautam wrote:
> The driver uses clock provider interface, and therefore
> it fails to build when enabled for COMPILE_TEST, since
> COMMON_CLK is not enabled at that time.
> So, make PHY_QCOM_QMP depend on COMMON_CLK as well.
> 
> Cc: Fengguang Wu <fengguang...@intel.com>
> Cc: Kishon Vijay Abraham I <kis...@ti.com>
> Signed-off-by: Vivek Gautam <vivek.gau...@codeaurora.org>
> ---
> 
> Hi Kishon,
> 
> This patch is fixing the build failures for architectures
> such as, tile, and ia64, that don't enable COMMON_CLK by default.
> You can either squash this into the qmp phy driver patch,
> or put it as a separate patch with 'Fix' tag.
> Let me know if you want me to add a 'fix' tag with a reference
> to the commit ID.

I squashed it with your earlier patch and pushed.

Thanks
Kishon

> 
> Regards
> Vivek
> 
>  drivers/phy/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> index bb8140355608..8550d3dc0b71 100644
> --- a/drivers/phy/Kconfig
> +++ b/drivers/phy/Kconfig
> @@ -441,7 +441,7 @@ config PHY_STIH407_USB
>  
>  config PHY_QCOM_QMP
>   tristate "Qualcomm QMP PHY Driver"
> - depends on OF && (ARCH_QCOM || COMPILE_TEST)
> + depends on OF && COMMON_CLK && (ARCH_QCOM || COMPILE_TEST)
>   select GENERIC_PHY
>   help
> Enable this to support the QMP PHY transceiver that is used
> 
--
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/9] phy: phy-mt65xx-usb3: improve RX detection stable time

[Kishon Vijay Abraham I]

On Friday 31 March 2017 01:05 PM, Chunfeng Yun wrote:
> The default value of RX detection stable time is 10us, and this
> margin is too big for some critical cases which cause U3 link fail
> and link to U2(probability is about 1%). So change it to 5us.
> 
merged all the phy patches in this series to linux-phy -next.

Thanks
Kishon

> Signed-off-by: Chunfeng Yun 
> ---
>  drivers/phy/phy-mt65xx-usb3.c |   18 ++
>  1 file changed, 18 insertions(+)
> 
> diff --git a/drivers/phy/phy-mt65xx-usb3.c b/drivers/phy/phy-mt65xx-usb3.c
> index d972067..fe2392a 100644
> --- a/drivers/phy/phy-mt65xx-usb3.c
> +++ b/drivers/phy/phy-mt65xx-usb3.c
> @@ -112,6 +112,14 @@
>  #define P3D_RG_CDR_BIR_LTD0  GENMASK(12, 8)
>  #define P3D_RG_CDR_BIR_LTD0_VAL(x)   ((0x1f & (x)) << 8)
>  
> +#define U3P_U3_PHYD_RXDET1   (SSUSB_SIFSLV_U3PHYD_BASE + 0x128)
> +#define P3D_RG_RXDET_STB2_SETGENMASK(17, 9)
> +#define P3D_RG_RXDET_STB2_SET_VAL(x) ((0x1ff & (x)) << 9)
> +
> +#define U3P_U3_PHYD_RXDET2   (SSUSB_SIFSLV_U3PHYD_BASE + 0x12c)
> +#define P3D_RG_RXDET_STB2_SET_P3 GENMASK(8, 0)
> +#define P3D_RG_RXDET_STB2_SET_P3_VAL(x)  (0x1ff & (x))
> +
>  #define U3P_XTALCTL3 (SSUSB_SIFSLV_SPLLC + 0x0018)
>  #define XC3_RG_U3_XTAL_RX_PWDBIT(9)
>  #define XC3_RG_U3_FRC_XTAL_RX_PWDBIT(8)
> @@ -295,6 +303,16 @@ static void phy_instance_init(struct mt65xx_u3phy *u3phy,
>   tmp |= P3D_RG_CDR_BIR_LTD0_VAL(0xc) | P3D_RG_CDR_BIR_LTD1_VAL(0x3);
>   writel(tmp, port_base + U3P_PHYD_CDR1);
>  
> + tmp = readl(port_base + U3P_U3_PHYD_RXDET1);
> + tmp &= ~P3D_RG_RXDET_STB2_SET;
> + tmp |= P3D_RG_RXDET_STB2_SET_VAL(0x10);
> + writel(tmp, port_base + U3P_U3_PHYD_RXDET1);
> +
> + tmp = readl(port_base + U3P_U3_PHYD_RXDET2);
> + tmp &= ~P3D_RG_RXDET_STB2_SET_P3;
> + tmp |= P3D_RG_RXDET_STB2_SET_P3_VAL(0x10);
> + writel(tmp, port_base + U3P_U3_PHYD_RXDET2);
> +
>   dev_dbg(u3phy->dev, "%s(%d)\n", __func__, index);
>  }
>  
> 
--
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 0/4] phy: USB and PCIe phy drivers for Qcom chipsets

[Kishon Vijay Abraham I]

On Thursday 06 April 2017 11:21 AM, Vivek Gautam wrote:
> Hi Kishon,
> Here's the series with fixed checkpatch warnings/checks.
> Please pick it for phy/next.
> 
> This patch series adds couple of PHY drivers for Qualcomm chipsets.
> a) qcom-qusb2 phy driver: that provides High Speed USB functionality.
> b) qcom-qmp phy driver: that is a combo phy providing support for
>USB3, PCIe, UFS and few other controllers.
> 
> The patches are based on next branch of linux-phy tree.
> 
> These patches have been tested on Dragon board db820c hardware with
> required set of dt patches.
> The tested branch[3] is based on torvald's master with greg's usb/usb-next
> merged. Additionally the patches to get rpm up on msm8996 are also pulled
> in.

merged, thanks!

-Kishon
> 
> Changes since v7:
>  - Fixed 'checkpatch --strict' alignment warnings/checks, and
>added Stephen's Reviewed-by tag.
> 
> Changes since v6:
>  - Rebased on phy/next and *not* including phy grouping series[4].
>  - qusb2-phy: addressed Stephen's comment.
>- Dropped pm8994_s2 corner regulator from QUSB2 phy bindings.
>  - qmp-phy: none on functionality side.
>  
> Changes since v5:
>  - Addressed review comments from Bjorn:
>- Removed instances of readl/wirtel_relaxed calls from the drivers.
>  Instead, using simple readl/writel. Inserting a readl after a writel
>  to ensure the write is through to the device.
>- Replaced regulator handling with regulator_bulk_** apis. This helps
>  in cutting down a lot of regulator handling code.
>- Fixed minor return statements.
> 
> Changes since v4:
>  - Addressed comment to add child nodes for qmp phy driver. Each phy lane
>now has a separate child node under the main qmp node.
>  - Modified the clock and reset initialization and enable methods.
>Different phys - pcie, usb and later ufs, have varying number of clocks
>and resets that are mandatory. So adding provision for clocks and reset
>lists helps in requesting all mandatory resources for individual phys
>and handle their failure cases accordingly.
> 
> Changes since v3:
>  - Addressed review comments given by Rob and Stephen for qusb2 phy
>and qmp phy bindings respectively.
>  - Addressed review comments given by Stephen and Bjorn for qmp phy driver.
> 
> Changes since v2:
>  - Addressed review comments given by Rob and Stephen for bindings.
>  - Addressed the review comments given by Stephen for the qusb2 and qmp
>phy drivers.
> 
> Changes since v1:
>  - Moved device tree binding documentation to separate patches, as suggested
>by Rob.
>  - Addressed review comment regarding qfprom accesses by qusb2 phy driver,
>given by Rob.
>  - Addressed review comments from Kishon.
>  - Addressed review comments from Srinivas for QMP phy driver.
>  - Addressed kbuild warning.
> 
> Please see individual patches for detailed changelogs.
> 
> [1] https://patchwork.kernel.org/patch/9567767/
> [2] https://patchwork.kernel.org/patch/9567779/
> [3] https://github.com/vivekgautam1/linux/tree/linux-v4.11-rc5-qmp-phy-db820c
> [4] https://lkml.org/lkml/2017/3/20/407
> 
> Vivek Gautam (4):
>   dt-bindings: phy: Add support for QUSB2 phy
>   phy: qcom-qusb2: New driver for QUSB2 PHY on Qcom chips
>   dt-bindings: phy: Add support for QMP phy
>   phy: qcom-qmp: new qmp phy driver for qcom-chipsets
> 
>  .../devicetree/bindings/phy/qcom-qmp-phy.txt   |  106 ++
>  .../devicetree/bindings/phy/qcom-qusb2-phy.txt |   43 +
>  drivers/phy/Kconfig|   18 +
>  drivers/phy/Makefile   |2 +
>  drivers/phy/phy-qcom-qmp.c | 1153 
> 
>  drivers/phy/phy-qcom-qusb2.c   |  493 +
>  6 files changed, 1815 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt
>  create mode 100644 Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt
>  create mode 100644 drivers/phy/phy-qcom-qmp.c
>  create mode 100644 drivers/phy/phy-qcom-qusb2.c
> 
--
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 0/4] phy: USB and PCIe phy drivers for Qcom chipsets

[Kishon Vijay Abraham I]

Hi Vivek,

On Wednesday 05 April 2017 06:02 PM, Vivek Gautam wrote:
> This patch series adds couple of PHY drivers for Qualcomm chipsets.
> a) qcom-qusb2 phy driver: that provides High Speed USB functionality.
> b) qcom-qmp phy driver: that is a combo phy providing support for
>USB3, PCIe, UFS and few other controllers.
> 
> The patches are based on next branch of linux-phy tree.
> 
> These patches have been tested on Dragon board db820c hardware with
> required set of dt patches and the patches to get rpm up on msm8996.
> Couple of other patches [1, 2] fixing DMA config for XHCI are also
> pulled in for testing.
> A branch based on torvald's master is available in github [3].

I get a bunch of checkpatch errors/warnings when I run checkpatch with --strict
option. Those look simple enough to be fixed. Can you respin your series fixing
those?

Thanks
Kishon

> 
> Changes since v6:
>  - Rebased on phy/next and *not* including phy grouping series[4].
>  - qusb2-phy: addressed Stephen's comment.
>- Dropped pm8994_s2 corner regulator from QUSB2 phy bindings.
>  - qmp-phy: none on functionality side.
>  
> Changes since v5:
>  - Addressed review comments from Bjorn:
>- Removed instances of readl/wirtel_relaxed calls from the drivers.
>  Instead, using simple readl/writel. Inserting a readl after a writel
>  to ensure the write is through to the device.
>- Replaced regulator handling with regulator_bulk_** apis. This helps
>  in cutting down a lot of regulator handling code.
>- Fixed minor return statements.
> 
> Changes since v4:
>  - Addressed comment to add child nodes for qmp phy driver. Each phy lane
>now has a separate child node under the main qmp node.
>  - Modified the clock and reset initialization and enable methods.
>Different phys - pcie, usb and later ufs, have varying number of clocks
>and resets that are mandatory. So adding provision for clocks and reset
>lists helps in requesting all mandatory resources for individual phys
>and handle their failure cases accordingly.
> 
> Changes since v3:
>  - Addressed review comments given by Rob and Stephen for qusb2 phy
>and qmp phy bindings respectively.
>  - Addressed review comments given by Stephen and Bjorn for qmp phy driver.
> 
> Changes since v2:
>  - Addressed review comments given by Rob and Stephen for bindings.
>  - Addressed the review comments given by Stephen for the qusb2 and qmp
>phy drivers.
> 
> Changes since v1:
>  - Moved device tree binding documentation to separate patches, as suggested
>by Rob.
>  - Addressed review comment regarding qfprom accesses by qusb2 phy driver,
>given by Rob.
>  - Addressed review comments from Kishon.
>  - Addressed review comments from Srinivas for QMP phy driver.
>  - Addressed kbuild warning.
> 
> Please see individual patches for detailed changelogs.
> 
> [1] https://patchwork.kernel.org/patch/9567767/
> [2] https://patchwork.kernel.org/patch/9567779/
> [3] https://github.com/vivekgautam1/linux/tree/linux-v4.11-rc5-qmp-phy-db820c
> [4] https://lkml.org/lkml/2017/3/20/407
> 
> Vivek Gautam (4):
>   dt-bindings: phy: Add support for QUSB2 phy
>   phy: qcom-qusb2: New driver for QUSB2 PHY on Qcom chips
>   dt-bindings: phy: Add support for QMP phy
>   phy: qcom-qmp: new qmp phy driver for qcom-chipsets
> 
>  .../devicetree/bindings/phy/qcom-qmp-phy.txt   |  106 ++
>  .../devicetree/bindings/phy/qcom-qusb2-phy.txt |   43 +
>  drivers/phy/Kconfig|   18 +
>  drivers/phy/Makefile   |2 +
>  drivers/phy/phy-qcom-qmp.c | 1153 
> 
>  drivers/phy/phy-qcom-qusb2.c   |  491 +
>  6 files changed, 1813 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt
>  create mode 100644 Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt
>  create mode 100644 drivers/phy/phy-qcom-qmp.c
>  create mode 100644 drivers/phy/phy-qcom-qusb2.c
> 
--
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 0/3] phy: Group phy drivers based on vendor listing

[Kishon Vijay Abraham I]

Hi Vivek,

On Wednesday 05 April 2017 05:07 PM, Vivek Gautam wrote:
> Hi Kishon,
> 
> 
> On 04/05/2017 04:34 PM, Kishon Vijay Abraham I wrote:
>> Hi Vivek,
>>
>> On Monday 20 March 2017 06:49 PM, Vivek Gautam wrote:
>>> This is the next version to an earlier posted series [1].
>>> Missed Cc'ing the first patch of the previous series [1] to lkml.
>>> Posting out this series now after addressing comments
>>> and after adding the received 'Acked-by' and 'Reviewed-by'
>>> tags.
>>>
>>> This series is based on linux-phy/next branch.
>>>
>>> [1] https://www.spinics.net/lists/arm-kernel/msg568370.html
>>>
>>> Signed-off-by: Vivek Gautam <vivek.gau...@codeaurora.org>
>>> Cc: Kishon Vijay Abraham I <kis...@ti.com>
>>> Cc: linux-arm-ker...@lists.infradead.org
>>> Cc: linux-arm-...@vger.kernel.org
>>> Cc: linux-ker...@vger.kernel.org
>>> Cc: linux-usb@vger.kernel.org
>> The best time to merge this would be immediately after -rc1 is tagged. Can 
>> you
>> resend when 4.12-rc1 is tagged?
> 
> Sure, I will send the series when 4.12-rc1 is out.
> I am also planning to send qcom phy's next version and i had rebased the
> earlier version on this patch series. Should i just rebase those patches on
> top of phy/next, or on this series?

phy/next please..

-Kishon

> 
> 
> Best Regards
> Vivek
> 
>>
>> Thanks
>> Kishon
>>
>>> -- 
>>> Vivek Gautam (3):
>>>phy: qcom-usb: Remove unused ulpi phy header
>>>phy: Move ULPI phy header out of drivers to include path
>>>phy: Group vendor specific phy drivers
>>>
>>>   MAINTAINERS|  18 +-
>>>   drivers/phy/Kconfig| 471
>>> +
>>>   drivers/phy/Makefile   |  67 +--
>>>   drivers/phy/allwinner/Kconfig  |  31 ++
>>>   drivers/phy/allwinner/Makefile |   2 +
>>>   drivers/phy/{ => allwinner}/phy-sun4i-usb.c|   0
>>>   drivers/phy/{ => allwinner}/phy-sun9i-usb.c|   0
>>>   drivers/phy/broadcom/Kconfig   |  64 +++
>>>   drivers/phy/broadcom/Makefile  |   7 +
>>>   drivers/phy/{ => broadcom}/phy-bcm-cygnus-pcie.c   |   0
>>>   drivers/phy/{ => broadcom}/phy-bcm-kona-usb2.c |   0
>>>   drivers/phy/{ => broadcom}/phy-bcm-ns-usb2.c   |   0
>>>   drivers/phy/{ => broadcom}/phy-bcm-ns-usb3.c   |   0
>>>   drivers/phy/{ => broadcom}/phy-bcm-ns2-pcie.c  |   0
>>>   drivers/phy/{ => broadcom}/phy-bcm-nsp-usb3.c  |   0
>>>   drivers/phy/{ => broadcom}/phy-brcm-sata.c |   0
>>>   drivers/phy/hisilicon/Kconfig  |  20 +
>>>   drivers/phy/hisilicon/Makefile |   2 +
>>>   drivers/phy/{ => hisilicon}/phy-hi6220-usb.c   |   0
>>>   drivers/phy/{ => hisilicon}/phy-hix5hd2-sata.c |   0
>>>   drivers/phy/marvell/Kconfig|  50 +++
>>>   drivers/phy/marvell/Makefile   |   6 +
>>>   drivers/phy/{ => marvell}/phy-armada375-usb2.c |   0
>>>   drivers/phy/{ => marvell}/phy-berlin-sata.c|   0
>>>   drivers/phy/{ => marvell}/phy-berlin-usb.c |   0
>>>   drivers/phy/{ => marvell}/phy-mvebu-sata.c |   0
>>>   drivers/phy/{ => marvell}/phy-pxa-28nm-hsic.c  |   0
>>>   drivers/phy/{ => marvell}/phy-pxa-28nm-usb2.c  |   0
>>>   drivers/phy/qualcomm/Kconfig   |  38 ++
>>>   drivers/phy/qualcomm/Makefile  |   7 +
>>>   drivers/phy/{ => qualcomm}/phy-qcom-apq8064-sata.c |   0
>>>   drivers/phy/{ => qualcomm}/phy-qcom-ipq806x-sata.c |   0
>>>   drivers/phy/{ => qualcomm}/phy-qcom-ufs-i.h|   0
>>>   drivers/phy/{ => qualcomm}/phy-qcom-ufs-qmp-14nm.c |   0
>>>   drivers/phy/{ => qualcomm}/phy-qcom-ufs-qmp-14nm.h |   0
>>>   drivers/phy/{ => qualcomm}/phy-qcom-ufs-qmp-20nm.c |   0
>>>   drivers/phy/{ => qualcomm}/phy-qcom-ufs-qmp-20nm.h |   0
>>>   drivers/phy/{ => qualcomm}/phy-qcom-ufs.c  |   0
>>>   drivers/phy/{ => qualcomm}/phy-qcom-usb-hs.c   |   2 -
>>>   drivers/phy/{ => qualcomm}/phy-qcom-usb-hsic.c |   2 -
>>>   drivers/phy/renesas/Kconfig|  17 +
>>>   drivers/phy/renesa

Re: [PATCH v3 0/3] add support of usb2-phy for rk3328

[Kishon Vijay Abraham I]

On Monday 06 March 2017 06:59 AM, Meng Dongyang wrote:
> The config information of RK3328 about address and port property
> is different from other platform. So adds config information in the
> data of match table and the device tree bindings description for
> usb2-phy.
> 
> Changes in v2:
>  - move usb2-phy grf specification to 
> .../devicetree/bindings/soc/rockchip/grf.txt
>  - add otg port config information of rk3328
> Changes in v3:
>  - remove tuning function and id pin configs
>  - delete example of usb2-phy grf in grf.txt

removed the version history in commit log and merged the series.

Thanks
Kishon
> 
> Meng Dongyang (3):
>   dt-bindings: phy: add assign clock property in usb2-phy node
>   dt-bindings: phy: add DT bindings for usb2-phy grf
>   phy: rockchip-inno-usb2: add support of usb2-phy for rk3328
> 
>  .../bindings/phy/phy-rockchip-inno-usb2.txt|  6 +++
>  .../devicetree/bindings/soc/rockchip/grf.txt   |  4 ++
>  drivers/phy/phy-rockchip-inno-usb2.c   | 44 
> ++
>  3 files changed, 54 insertions(+)
> 
--
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 0/3] phy: Group phy drivers based on vendor listing

[Kishon Vijay Abraham I]

Hi Vivek,

On Monday 20 March 2017 06:49 PM, Vivek Gautam wrote:
> This is the next version to an earlier posted series [1].
> Missed Cc'ing the first patch of the previous series [1] to lkml.
> Posting out this series now after addressing comments
> and after adding the received 'Acked-by' and 'Reviewed-by'
> tags.
> 
> This series is based on linux-phy/next branch.
> 
> [1] https://www.spinics.net/lists/arm-kernel/msg568370.html
> 
> Signed-off-by: Vivek Gautam <vivek.gau...@codeaurora.org>
> Cc: Kishon Vijay Abraham I <kis...@ti.com>
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-arm-...@vger.kernel.org
> Cc: linux-ker...@vger.kernel.org
> Cc: linux-usb@vger.kernel.org

The best time to merge this would be immediately after -rc1 is tagged. Can you
resend when 4.12-rc1 is tagged?

Thanks
Kishon

> 
> --
> Vivek Gautam (3):
>   phy: qcom-usb: Remove unused ulpi phy header
>   phy: Move ULPI phy header out of drivers to include path
>   phy: Group vendor specific phy drivers
> 
>  MAINTAINERS|  18 +-
>  drivers/phy/Kconfig| 471 
> +
>  drivers/phy/Makefile   |  67 +--
>  drivers/phy/allwinner/Kconfig  |  31 ++
>  drivers/phy/allwinner/Makefile |   2 +
>  drivers/phy/{ => allwinner}/phy-sun4i-usb.c|   0
>  drivers/phy/{ => allwinner}/phy-sun9i-usb.c|   0
>  drivers/phy/broadcom/Kconfig   |  64 +++
>  drivers/phy/broadcom/Makefile  |   7 +
>  drivers/phy/{ => broadcom}/phy-bcm-cygnus-pcie.c   |   0
>  drivers/phy/{ => broadcom}/phy-bcm-kona-usb2.c |   0
>  drivers/phy/{ => broadcom}/phy-bcm-ns-usb2.c   |   0
>  drivers/phy/{ => broadcom}/phy-bcm-ns-usb3.c   |   0
>  drivers/phy/{ => broadcom}/phy-bcm-ns2-pcie.c  |   0
>  drivers/phy/{ => broadcom}/phy-bcm-nsp-usb3.c  |   0
>  drivers/phy/{ => broadcom}/phy-brcm-sata.c |   0
>  drivers/phy/hisilicon/Kconfig  |  20 +
>  drivers/phy/hisilicon/Makefile |   2 +
>  drivers/phy/{ => hisilicon}/phy-hi6220-usb.c   |   0
>  drivers/phy/{ => hisilicon}/phy-hix5hd2-sata.c |   0
>  drivers/phy/marvell/Kconfig|  50 +++
>  drivers/phy/marvell/Makefile   |   6 +
>  drivers/phy/{ => marvell}/phy-armada375-usb2.c |   0
>  drivers/phy/{ => marvell}/phy-berlin-sata.c|   0
>  drivers/phy/{ => marvell}/phy-berlin-usb.c |   0
>  drivers/phy/{ => marvell}/phy-mvebu-sata.c |   0
>  drivers/phy/{ => marvell}/phy-pxa-28nm-hsic.c  |   0
>  drivers/phy/{ => marvell}/phy-pxa-28nm-usb2.c  |   0
>  drivers/phy/qualcomm/Kconfig   |  38 ++
>  drivers/phy/qualcomm/Makefile  |   7 +
>  drivers/phy/{ => qualcomm}/phy-qcom-apq8064-sata.c |   0
>  drivers/phy/{ => qualcomm}/phy-qcom-ipq806x-sata.c |   0
>  drivers/phy/{ => qualcomm}/phy-qcom-ufs-i.h|   0
>  drivers/phy/{ => qualcomm}/phy-qcom-ufs-qmp-14nm.c |   0
>  drivers/phy/{ => qualcomm}/phy-qcom-ufs-qmp-14nm.h |   0
>  drivers/phy/{ => qualcomm}/phy-qcom-ufs-qmp-20nm.c |   0
>  drivers/phy/{ => qualcomm}/phy-qcom-ufs-qmp-20nm.h |   0
>  drivers/phy/{ => qualcomm}/phy-qcom-ufs.c  |   0
>  drivers/phy/{ => qualcomm}/phy-qcom-usb-hs.c   |   2 -
>  drivers/phy/{ => qualcomm}/phy-qcom-usb-hsic.c |   2 -
>  drivers/phy/renesas/Kconfig|  17 +
>  drivers/phy/renesas/Makefile   |   2 +
>  drivers/phy/{ => renesas}/phy-rcar-gen2.c  |   0
>  drivers/phy/{ => renesas}/phy-rcar-gen3-usb2.c |   0
>  drivers/phy/rockchip/Kconfig   |  51 +++
>  drivers/phy/rockchip/Makefile  |   6 +
>  drivers/phy/{ => rockchip}/phy-rockchip-dp.c   |   0
>  drivers/phy/{ => rockchip}/phy-rockchip-emmc.c |   0
>  .../phy/{ => rockchip}/phy-rockchip-inno-usb2.c|   0
>  drivers/phy/{ => rockchip}/phy-rockchip-pcie.c |   0
>  drivers/phy/{ => rockchip}/phy-rockchip-typec.c|   0
>  drivers/phy/{ => rockchip}/phy-rockchip-usb.c  |   0
>  drivers/phy/samsung/Kconfig|  96 +
>  drivers/phy/samsung/Makefile   |  11 +
>  drivers/phy/{ => samsung}/phy-exynos-dp-video.c|   0
>  drivers/phy/{ => samsung}/phy-exynos-mipi-video.c  |   0
>  drivers/phy/{ => samsung}/phy-exynos-pcie.c|   0
>  drivers/phy/{ => samsung}/phy-exynos4210-usb2.c|   0
>  drivers/phy/{ => samsung}/phy-exynos4x12-usb2.c| 

Re: [PATCHv2] phy: cpcap-usb: Add CPCAP PMIC USB support

[Kishon Vijay Abraham I]

Hi Tony,

On Monday 27 March 2017 08:35 PM, Tony Lindgren wrote:
> * Kishon Vijay Abraham I <kis...@ti.com> [170326 23:27]:
>> On Thursday 23 March 2017 05:16 AM, Tony Lindgren wrote:
>>> +static const struct phy_ops ops = {
>>> +   .owner  = THIS_MODULE,
>>> +};
>>
>> Given that this phy doesn't have any phy_ops, Is there a reason for 
>> registering
>> this phy with the phy framework? Is it because this driver uses the 
>> phy_core's
>> pm_runtime feature?
> 
> Well there's also an ULPI PHY on CPCAP, but it's not used in the
> motorola-mapphone configuration. I think some other configurations
> use it though, so probably best to keep it.
> 
> And yeah, for PM runtime, I was thinking that we can have the
> UART mode be the idle state.
> 
>>> +static void cpcap_usb_detect(struct work_struct *work)
>>> +{
>>> +   struct cpcap_phy_ddata *ddata;
>>> +   struct cpcap_usb_ints_state s;
>>> +   bool vbus = false;
>>> +   int error;
>>> +
>>> +   ddata = container_of(work, struct cpcap_phy_ddata, detect_work.work);
>>> +
>>> +   error = cpcap_phy_get_ints_state(ddata, );
>>> +   if (error)
>>> +   return;
>>> +
>>> +   /* See also cpcap-charger.c phy_companion for VBUS handling */
>>
>> I think this companion should have ideally used extcon framework. Then we 
>> could
>> have used extcon_get_state() here.
> 
> OK I'll take a look at that. I'd like to do that as a follow-up
> patches if that's OK with you.
> 
> FYI in case you're wondering, there are ADCs on the PMIC available
> via IIO, and the charger is also using IIO framework for VBUS and
> battery voltage. And the VBUS is set up as reverse mode in the
> charger registers and the charging needs to be disabled for VBUS.
> 
> I guess Ideally the VBUS would be just a regulator from Linux point
> of view that also allows negative current :)
> 
>>> +   ddata->vusb = devm_regulator_get(>dev, "vusb");
>>> +   if (IS_ERR(ddata->vusb))
>>> +   return PTR_ERR(ddata->vusb);
>>> +
>>> +   error = regulator_enable(ddata->vusb);
>>> +   if (error)
>>> +   return error;
>>
>> Maybe we should create power_on ops and do regulator enable there?
> 
> This regulator is also needed for the UART mode, so it would have
> to be disabled conditionally based on maybe a module parameter.
> But yeah thanks for the pointer I did not even realize you have
> power_on ops :)
> 
> Seems this can be also done when implementing PM runtime handling.
> If you want some of these changes done for the initial patch,
> please let me know.

I think it's better we get extcon stuff in the initial patch so that we don't
have to maintain some piece of code for legacy dt. Others can be added later.

Thanks
Kishon
--
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/2] add support of u2phy for rk3328

[Kishon Vijay Abraham I]

On Wednesday 01 March 2017 03:43 PM, Meng Dongyang wrote:
> The config information of RK3328 about address and port property
> is different from before platform. So add config information in the
> data of match table and documentation of the device tree bindings
> of u2phy.

merged, thanks.

-Kishon
> 
> Meng Dongyang (2):
>   Documentation: bindings: add DT documentation for u2phy and u2phy grf
>   phy: rockchip-inno-usb2: add support of u2phy for rk3328
> 
>  .../bindings/phy/phy-rockchip-inno-usb2.txt| 47 
> ++
>  drivers/phy/phy-rockchip-inno-usb2.c   | 21 ++
>  2 files changed, 68 insertions(+)
> 
--
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: [PATCHv2] phy: cpcap-usb: Add CPCAP PMIC USB support

[Kishon Vijay Abraham I]

Hi Tony,

On Thursday 23 March 2017 05:16 AM, Tony Lindgren wrote:
> Some Motorola phones like droid 4 use a custom CPCAP PMIC that has a
> multiplexing USB PHY.
> 
> This USB PHY can operate at least in four modes using pin multiplexing
> and two control GPIOS:
> 
> - Pass through companion PHY for the SoC USB PHY
> - ULPI PHY for the SoC
> - Pass through USB for the modem
> - UART debug console for the SoC
> 
> This patch adds support for droid 4 USB PHY and debug UART modes,
> support for other modes can be added later on as needed.
> 
> Both peripheral and host mode are working for the USB. The
> host mode depends on the cpcap-charger driver for VBUS.
> 
> VBUS and ID pin detection are done using cpcap-adc IIO ADC
> driver.
> 
> Cc: devicet...@vger.kernel.org
> Cc: Marcel Partap 
> Cc: Michael Scott 
> Tested-by: Sebastian Reichel 
> Signed-off-by: Tony Lindgren 
> ---
> 
> Changes since v1:
> 
> - Use iio_read_channel_processed() instead of iio_read_channel_scaled()
>   as changed in the v2 of the ADC driver 
> 
> - Keep Tested-by from Sebastian Reichel  as the change
>   from v1 is trivial
> 
> ---
>  .../devicetree/bindings/phy/phy-cpcap-usb.txt  |  40 ++
>  drivers/phy/Kconfig|   8 +
>  drivers/phy/Makefile   |   1 +
>  drivers/phy/phy-cpcap-usb.c| 695 
> +
>  4 files changed, 744 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/phy/phy-cpcap-usb.txt
>  create mode 100644 drivers/phy/phy-cpcap-usb.c
> 
> diff --git a/Documentation/devicetree/bindings/phy/phy-cpcap-usb.txt 
> b/Documentation/devicetree/bindings/phy/phy-cpcap-usb.txt
> new file mode 100644
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/phy-cpcap-usb.txt
> @@ -0,0 +1,40 @@
> +Motorola CPCAP PMIC USB PHY binding
> +
> +Required properties:
> +compatible: Shall be either "motorola,cpcap-usb-phy" or
> + "motorola,mapphone-cpcap-usb-phy"
> +#phy-cells: Shall be 0
> +interrupts: CPCAP PMIC interrupts used by the USB PHY
> +interrupt-names: Interrupt names
> +io-channels: IIO ADC channels used by the USB PHY
> +io-channel-names: IIO ADC channel names
> +vusb-supply: Regulator for the PHY
> +
> +Optional properties:
> +pinctrl: Optional alternate pin modes for the PHY
> +pinctrl-names: Names for optional pin modes
> +mode-gpios: Optional GPIOs for configuring alternate modes
> +
> +Example:
> +cpcap_usb2_phy: phy {
> + compatible = "motorola,mapphone-cpcap-usb-phy";
> + pinctrl-0 = <_gpio_mux_sel1 _gpio_mux_sel2>;
> + pinctrl-1 = <_ulpi_pins>;
> + pinctrl-2 = <_utmi_pins>;
> + pinctrl-3 = <_pins>;
> + pinctrl-names = "default", "ulpi", "utmi", "uart";
> + #phy-cells = <0>;
> + interrupts-extended = <
> +  15 0  14 0  28 0  19 0
> +  18 0  17 0  16 0  49 0
> +  48 1
> + >;
> + interrupt-names =
> + "id_ground", "id_float", "se0conn", "vbusvld",
> + "sessvld", "sessend", "se1", "dm", "dp";
> + mode-gpios = < 28 GPIO_ACTIVE_HIGH
> +0 GPIO_ACTIVE_HIGH>;
> + io-channels = <_adc 2>, <_adc 7>;
> + io-channel-names = "vbus", "id";
> + vusb-supply = <>;
> +};
> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> --- a/drivers/phy/Kconfig
> +++ b/drivers/phy/Kconfig
> @@ -47,6 +47,14 @@ config PHY_BERLIN_SATA
>   help
> Enable this to support the SATA PHY on Marvell Berlin SoCs.
>  
> +config PHY_CPCAP_USB
> + tristate "CPCAP USB PHY driver"
> + depends on USB_SUPPORT
> + select GENERIC_PHY
> + select USB_PHY
> + help
> +   Enable this for CPCAP USB to work.
> +
>  config ARMADA375_USBCLUSTER_PHY
>   def_bool y
>   depends on MACH_ARMADA_375 || COMPILE_TEST
> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
> --- a/drivers/phy/Makefile
> +++ b/drivers/phy/Makefile
> @@ -7,6 +7,7 @@ obj-$(CONFIG_PHY_BCM_NS_USB2) += phy-bcm-ns-usb2.o
>  obj-$(CONFIG_PHY_BCM_NS_USB3)+= phy-bcm-ns-usb3.o
>  obj-$(CONFIG_PHY_BERLIN_USB) += phy-berlin-usb.o
>  obj-$(CONFIG_PHY_BERLIN_SATA)+= phy-berlin-sata.o
> +obj-$(CONFIG_PHY_CPCAP_USB)  += phy-cpcap-usb.o
>  obj-$(CONFIG_PHY_DA8XX_USB)  += phy-da8xx-usb.o
>  obj-$(CONFIG_PHY_DM816X_USB) += phy-dm816x-usb.o
>  obj-$(CONFIG_ARMADA375_USBCLUSTER_PHY)   += phy-armada375-usb2.o
> diff --git a/drivers/phy/phy-cpcap-usb.c b/drivers/phy/phy-cpcap-usb.c
> new file mode 100644
> --- /dev/null
> +++ b/drivers/phy/phy-cpcap-usb.c
> @@ -0,0 +1,695 @@
> +/*
> + * Motorola CPCAP PMIC USB PHY driver
> + * Copyright (C) 2017 Tony Lindgren 
> + *
> + * Some parts based on earlier Motorola Linux kernel tree code in
> + * board-mapphone-usb.c and cpcap-usb-det.c:
> + * Copyright (C) 2007 - 2011 Motorola, Inc.
> + *

Re: [RESEND PATCH v3 4/8] phy: phy-mt65xx-usb3: move clock from phy node into port nodes

[Kishon Vijay Abraham I]

Hi,

On Monday 06 March 2017 07:19 PM, Chunfeng Yun wrote:
> the reference clock of HighSpeed port is 48M which comes from PLL;
> the reference clock of SuperSpeed port is 26M which usually comes
> from 26M oscillator directly, but some SoCs are not, add it for
> compatibility, and put them into port node for flexibility.

Won't this break the old dt compatiblity? Making change in dt is fine as long
as older dtb's are still supported.

Thanks
Kishon
> 
> Signed-off-by: Chunfeng Yun 
> ---
>  drivers/phy/phy-mt65xx-usb3.c |   21 +++--
>  1 file changed, 11 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/phy/phy-mt65xx-usb3.c b/drivers/phy/phy-mt65xx-usb3.c
> index 7fff482..f4a3505 100644
> --- a/drivers/phy/phy-mt65xx-usb3.c
> +++ b/drivers/phy/phy-mt65xx-usb3.c
> @@ -153,6 +153,7 @@ struct mt65xx_phy_pdata {
>  struct mt65xx_phy_instance {
>   struct phy *phy;
>   void __iomem *port_base;
> + struct clk *ref_clk;/* reference clock of anolog phy */
>   u32 index;
>   u8 type;
>  };
> @@ -160,7 +161,6 @@ struct mt65xx_phy_instance {
>  struct mt65xx_u3phy {
>   struct device *dev;
>   void __iomem *sif_base; /* only shared sif */
> - struct clk *u3phya_ref; /* reference clock of usb3 anolog phy */
>   const struct mt65xx_phy_pdata *pdata;
>   struct mt65xx_phy_instance **phys;
>   int nphys;
> @@ -449,9 +449,9 @@ static int mt65xx_phy_init(struct phy *phy)
>   struct mt65xx_u3phy *u3phy = dev_get_drvdata(phy->dev.parent);
>   int ret;
>  
> - ret = clk_prepare_enable(u3phy->u3phya_ref);
> + ret = clk_prepare_enable(instance->ref_clk);
>   if (ret) {
> - dev_err(u3phy->dev, "failed to enable u3phya_ref\n");
> + dev_err(u3phy->dev, "failed to enable ref_clk\n");
>   return ret;
>   }
>  
> @@ -494,7 +494,7 @@ static int mt65xx_phy_exit(struct phy *phy)
>   if (instance->type == PHY_TYPE_USB2)
>   phy_instance_exit(u3phy, instance);
>  
> - clk_disable_unprepare(u3phy->u3phya_ref);
> + clk_disable_unprepare(instance->ref_clk);
>   return 0;
>  }
>  
> @@ -594,12 +594,6 @@ static int mt65xx_u3phy_probe(struct platform_device 
> *pdev)
>   return PTR_ERR(u3phy->sif_base);
>   }
>  
> - u3phy->u3phya_ref = devm_clk_get(dev, "u3phya_ref");
> - if (IS_ERR(u3phy->u3phya_ref)) {
> - dev_err(dev, "error to get u3phya_ref\n");
> - return PTR_ERR(u3phy->u3phya_ref);
> - }
> -
>   port = 0;
>   for_each_child_of_node(np, child_np) {
>   struct mt65xx_phy_instance *instance;
> @@ -634,6 +628,13 @@ static int mt65xx_u3phy_probe(struct platform_device 
> *pdev)
>   goto put_child;
>   }
>  
> + instance->ref_clk = devm_clk_get(>dev, "ref");
> + if (IS_ERR(instance->ref_clk)) {
> + dev_err(dev, "failed to get ref_clk(id-%d)\n", port);
> + retval = PTR_ERR(instance->ref_clk);
> + goto put_child;
> + }
> +
>   instance->phy = phy;
>   instance->index = port;
>   phy_set_drvdata(phy, instance);
> 
--
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 0/3] Support qcom's HSIC USB and rewrite USB2 HS support

[Kishon Vijay Abraham I]

On Thursday 26 January 2017 04:02 AM, Stephen Boyd wrote:
> This patch series continues the usb chipidea rewrite for 
> Qualcommm platforms. I've dropped the patches that were applied
> to Peter's tree for chipidea. Now the phy drivers are left,
> along with the patch to call phy_set_mode() at the right place.
> 
> I've left the HSIC phy driver here, because it wasn't merged in
> the last round. Nothing has changed in that driver, so I believe
> it is ready to be merged now. The chipidea patch is independent and
> can be merged without causing any dependency with the phy tree.

merged the phy patches. Please send a patch updating the MAINTAINERS for the
phy driver.

Thanks
Kishon
> 
> Patches based on v4.10-rc1 + first 22 patches from v5. Full
> branch is here[1].
> 
> Changes from v7:
>  * Dropped set_vbus() callback (Kishon)
>  * Made phy_set_mode() generic and moved into ci_platform_configure() (Peter)
> 
> Changes from v6:
>  * Dropped first 22 applied patches
>  * Rewrote phy_set_mode() patch to be msm specific
>  * New set_vbus() callback in phy framework
>  * Updated HS phy driver for set_vbus() callback
> 
> Changes from v5:
>  * Replaced "Emulate OTGSC interrupt enable path" patch with a patch
>from Peter
>  * Updated HS phy driver to support set_mode callback to handle pullup
>  * New patch to set the mode to device or host in chipidea udc pullup
>function to toggle the pullup for HS mode
>  * New patch to drop lock around event_notify callback to avoid lockdep
>issues
>  * Removal of extcon usage from HS phy driver
>  * Picked up acks from Heikki and Peter on ULPI core patch
> 
> Changes from v4:
>  * Picked up Acks from Rob
>  * Updated HS phy init sequence DT property to restrict it to offsets
> 
> Changes from v3:
>  * Picked up Acks from Peter
>  * Updated extcon consolidation patch per Peter's comments
>  * Folded in simplification from Heikki for ULPI DT matching
> 
> Changes from v2:
>  * Added SoC specific compatibles in phy bindings
>  * Dropped AVVIS patch for OTG statemachine
>  * New patch to consolidate extcon handlers
>  * Picked up Acks from Peter
>  * Rebased onto v4.8-rc1
>  * Reworked ULPI OF code to look at vid == 0 instead of pid == 0
>  * Dropped ULPI bindings for vid and pid overrides
> 
> Changes from v1:
>  * Reworked ULPI device probing to keep using vendor/product ids that
>come from DT if needed and falls back to OF style match when product id
>is 0
>  * PHY init later patch was rejected so that moved to a quirk flag and
>the msm wrapper started managing the phy on/off
>  * Updated clk requirements for HSIC phy in binding doc
>  * Added optional clk in wrapper for "housekeeping" found on older qcom
>platforms
>  * Bug fix to OTGSC polling function
>  * Changed runtime PM patch to set as active instead of get/put
> 
> TODO:
>  * DMA fails on arm64 so we need something like [2] to make it work.
>  * The db410c needs a driver to toggle the onboard switch to connect
>the usb hub instead of micro port when the usb cable is disconnected.
>I've sent a patch set for this[3], which needs some further
>discussion/development. The current plan is to reintroduce the usb
>mux framework.
>  * apq8064 platforms need a vbus regulator to really use otg and I haven't
>tried out the RPM based regulators yet
>  * The HSIC phy on the apq8074 dragonboard is connected to a usb4604
>device which requires the i2c driver to probe and send an i2c
>sequence before the HSIC controller enumerates or HSIC doesn't work.
>Right now I have a hack to force the controller to probe defer
>once so that usb4604 probes first. This needs a more proper solution
>like having the DT describe a linkage between the controller and
>the usb device so we can enforce probe ordering. My current plan
>is to use DT graphs/endpoints for this.
> 
> [1] https://git.linaro.org/people/stephen.boyd/linux.git/log/?h=usb-hsic-8074
> [2] https://patchwork.kernel.org/patch/9319527/
> [3] https://lkml.kernel.org/r/20160914014246.31847-1-stephen.b...@linaro.org
> 
> Stephen Boyd (3):
>   usb: chipidea: Configure phy for appropriate mode
>   phy: Add support for Qualcomm's USB HSIC phy
>   phy: Add support for Qualcomm's USB HS phy
> 
>  .../devicetree/bindings/phy/qcom,usb-hs-phy.txt|  84 ++
>  .../devicetree/bindings/phy/qcom,usb-hsic-phy.txt  |  65 +
>  drivers/phy/Kconfig|  15 ++
>  drivers/phy/Makefile   |   2 +
>  drivers/phy/phy-qcom-usb-hs.c  | 296 
> +
>  drivers/phy/phy-qcom-usb-hsic.c| 160 +++
>  drivers/usb/chipidea/core.c|  20 +-
>  7 files changed, 636 insertions(+), 6 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/phy/qcom,usb-hs-phy.txt
>  create mode 100644 
> Documentation/devicetree/bindings/phy/qcom,usb-hsic-phy.txt
>  create mode 100644 

Re: [PATCH v7 3/5] phy: Add set_vbus callback

[Kishon Vijay Abraham I]

Hi,

On Tuesday 24 January 2017 01:28 AM, Stephen Boyd wrote:
> Quoting Kishon Vijay Abraham I (2017-01-22 00:46:21)
>> Hi,
>>
>> On Saturday 21 January 2017 12:20 AM, Stephen Boyd wrote:
>>> Some USB PHYs need to be told about vbus changing state
>>> explicitly. For example the qcom USB HS PHY needs to toggle a bit
>>> when vbus goes from low to high (VBUSVLDEXT) to cause the
>>> "session valid" signal to toggle. This signal will pull up D+
>>> when the phy starts running. If the vbus signal isn't routed to
>>> the PHY this "session valid" signal won't ever toggle, so we have
>>> to toggle it explicitly. This callback is used to do that.
>>>
>>> Cc: Peter Chen <peter.c...@nxp.com>
>>> Signed-off-by: Stephen Boyd <stephen.b...@linaro.org>
>>> ---
>>>
>>> New patch
>>>
>>>  drivers/phy/phy-core.c  | 15 +++
>>>  include/linux/phy/phy.h | 10 ++
>>>  2 files changed, 25 insertions(+)
>>>
>>> diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
>>> index a268f4d6f3e9..8b1a6bfa5133 100644
>>> --- a/drivers/phy/phy-core.c
>>> +++ b/drivers/phy/phy-core.c
>>> @@ -357,6 +357,21 @@ int phy_set_mode(struct phy *phy, enum phy_mode mode)
>>>  }
>>>  EXPORT_SYMBOL_GPL(phy_set_mode);
>>>  
>>> +int phy_set_vbus(struct phy *phy, int on)
>>> +{
>>> + int ret;
>>> +
>>> + if (!phy || !phy->ops->set_vbus)
>>> + return 0;
>>> +
>>> + mutex_lock(>mutex);
>>> + ret = phy->ops->set_vbus(phy, on);
>>> + mutex_unlock(>mutex);
>>> +
>>> + return ret;
>>> +}
>>> +EXPORT_SYMBOL_GPL(phy_set_vbus);
>>> +
>>>  int phy_reset(struct phy *phy)
>>>  {
>>>   int ret;
>>> diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
>>> index 78bb0d7f6b11..4d1ebde7fb14 100644
>>> --- a/include/linux/phy/phy.h
>>> +++ b/include/linux/phy/phy.h
>>> @@ -36,6 +36,7 @@ enum phy_mode {
>>>   * @power_on: powering on the phy
>>>   * @power_off: powering off the phy
>>>   * @set_mode: set the mode of the phy
>>> + * @set_vbus: enable/disable vbus in the phy (USB)
>>>   * @reset: resetting the phy
>>>   * @owner: the module owner containing the ops
>>>   */
>>> @@ -45,6 +46,7 @@ struct phy_ops {
>>>   int (*power_on)(struct phy *phy);
>>>   int (*power_off)(struct phy *phy);
>>>   int (*set_mode)(struct phy *phy, enum phy_mode mode);
>>> + int (*set_vbus)(struct phy *phy, int on);
>>
>> please avoid adding usb specific ops in generic phy ops.
>>
> 
> Is there any alternative? Something has to happen here.
> 
> The only other thing I can think of is putting back the vbus extcon in
> the phy driver so it can be notified when vbus is present or not. I can

I think extcon should be used here to get vbus notification.

Thanks
Kishon
--
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/5] phy: Add set_vbus callback

[Kishon Vijay Abraham I]

Hi,

On Saturday 21 January 2017 12:20 AM, Stephen Boyd wrote:
> Some USB PHYs need to be told about vbus changing state
> explicitly. For example the qcom USB HS PHY needs to toggle a bit
> when vbus goes from low to high (VBUSVLDEXT) to cause the
> "session valid" signal to toggle. This signal will pull up D+
> when the phy starts running. If the vbus signal isn't routed to
> the PHY this "session valid" signal won't ever toggle, so we have
> to toggle it explicitly. This callback is used to do that.
> 
> Cc: Peter Chen 
> Signed-off-by: Stephen Boyd 
> ---
> 
> New patch
> 
>  drivers/phy/phy-core.c  | 15 +++
>  include/linux/phy/phy.h | 10 ++
>  2 files changed, 25 insertions(+)
> 
> diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
> index a268f4d6f3e9..8b1a6bfa5133 100644
> --- a/drivers/phy/phy-core.c
> +++ b/drivers/phy/phy-core.c
> @@ -357,6 +357,21 @@ int phy_set_mode(struct phy *phy, enum phy_mode mode)
>  }
>  EXPORT_SYMBOL_GPL(phy_set_mode);
>  
> +int phy_set_vbus(struct phy *phy, int on)
> +{
> + int ret;
> +
> + if (!phy || !phy->ops->set_vbus)
> + return 0;
> +
> + mutex_lock(>mutex);
> + ret = phy->ops->set_vbus(phy, on);
> + mutex_unlock(>mutex);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(phy_set_vbus);
> +
>  int phy_reset(struct phy *phy)
>  {
>   int ret;
> diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
> index 78bb0d7f6b11..4d1ebde7fb14 100644
> --- a/include/linux/phy/phy.h
> +++ b/include/linux/phy/phy.h
> @@ -36,6 +36,7 @@ enum phy_mode {
>   * @power_on: powering on the phy
>   * @power_off: powering off the phy
>   * @set_mode: set the mode of the phy
> + * @set_vbus: enable/disable vbus in the phy (USB)
>   * @reset: resetting the phy
>   * @owner: the module owner containing the ops
>   */
> @@ -45,6 +46,7 @@ struct phy_ops {
>   int (*power_on)(struct phy *phy);
>   int (*power_off)(struct phy *phy);
>   int (*set_mode)(struct phy *phy, enum phy_mode mode);
> + int (*set_vbus)(struct phy *phy, int on);

please avoid adding usb specific ops in generic phy ops.

Thanks
Kishon
--
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/4] phy: sun4i-usb: add support for V3s USB PHY

[Kishon Vijay Abraham I]

On Friday 06 January 2017 07:26 PM, Maxime Ripard wrote:
> On Tue, Jan 03, 2017 at 11:25:31PM +0800, Icenowy Zheng wrote:
>> Allwinner V3s come with a USB PHY controller slightly different to other
>> SoCs, with only one PHY.
>>
>> Add support for it.
>>
>> Signed-off-by: Icenowy Zheng 
> 
> Acked-by: Maxime Ripard 

merged, thanks!

-Kishon
> 
> Thanks,
> Maxime
> 
--
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 1/3] phy: phy-hi6220-usb: Wire up extconn support to hikey's phy driver

[Kishon Vijay Abraham I]

Hi,

On Wednesday 23 November 2016 09:16 AM, John Stultz wrote:
> This wires extconn support to hikey's phy driver, and
> connects it to the usb UDC layer via a usb_phy structure.
> 
> Not sure if this is the right way to connect phy -> UDC,
> but I'm lacking a clear example.
> 
> Cc: Wei Xu <xuw...@hisilicon.com>
> Cc: Guodong Xu <guodong...@linaro.org>
> Cc: Amit Pundir <amit.pun...@linaro.org>
> Cc: Rob Herring <robh...@kernel.org>
> Cc: John Youn <johny...@synopsys.com>
> Cc: Douglas Anderson <diand...@chromium.org>
> Cc: Chen Yu <cheny...@huawei.com>
> Cc: Kishon Vijay Abraham I <kis...@ti.com>
> Cc: Felipe Balbi <felipe.ba...@linux.intel.com>
> Cc: Greg Kroah-Hartman <gre...@linuxfoundation.org>
> Cc: linux-usb@vger.kernel.org
> Signed-off-by: John Stultz <john.stu...@linaro.org>
> ---
>  arch/arm64/boot/dts/hisilicon/hi6220.dtsi |  11 +++
>  drivers/phy/Kconfig   |   2 +
>  drivers/phy/phy-hi6220-usb.c  | 139 
> ++
>  3 files changed, 152 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi 
> b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
> index 17839db..171fbb2 100644
> --- a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
> +++ b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
> @@ -732,10 +732,21 @@
>   regulator-always-on;
>   };
>  
> + usb_vbus: usb-vbus {
> + compatible = "linux,extcon-usb-gpio";
> + id-gpio = < 6 1>;
> + };
> +
> + usb_id: usb-id {
> + compatible = "linux,extcon-usb-gpio";
> + id-gpio = < 5 1>;
> + };
> +
>   usb_phy: usbphy {
>   compatible = "hisilicon,hi6220-usb-phy";
>   #phy-cells = <0>;
>   phy-supply = <_5v_hub>;
> + extcon = <_vbus>, <_id>;
>   hisilicon,peripheral-syscon = <_ctrl>;
>   };
>  
> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> index fe00f91..76f4f17 100644
> --- a/drivers/phy/Kconfig
> +++ b/drivers/phy/Kconfig
> @@ -254,8 +254,10 @@ config PHY_MT65XX_USB3
>  config PHY_HI6220_USB
>   tristate "hi6220 USB PHY support"
>   depends on (ARCH_HISI && ARM64) || COMPILE_TEST
> + depends on EXTCON
>   select GENERIC_PHY
>   select MFD_SYSCON
> + select USB_PHY
>   help
> Enable this to support the HISILICON HI6220 USB PHY.
>  
> diff --git a/drivers/phy/phy-hi6220-usb.c b/drivers/phy/phy-hi6220-usb.c
> index b2141cb..89d8475 100644
> --- a/drivers/phy/phy-hi6220-usb.c
> +++ b/drivers/phy/phy-hi6220-usb.c
> @@ -12,7 +12,12 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
> +#include 
> +#include 
>  #include 
> +#include 
>  
>  #define SC_PERIPH_CTRL4  0x00c
>  
> @@ -44,9 +49,21 @@
>  
>  #define EYE_PATTERN_PARA 0x7053348c
>  
> +
> +struct hi6220_usb_cable {
> + struct notifier_block   nb;
> + struct extcon_dev   *extcon;
> + int state;
> +};
> +
>  struct hi6220_priv {
>   struct regmap *reg;
>   struct device *dev;
> + struct usb_phy phy;
> +
> + struct delayed_work work;
> + struct hi6220_usb_cable vbus;
> + struct hi6220_usb_cable id;
>  };
>  
>  static void hi6220_phy_init(struct hi6220_priv *priv)
> @@ -112,23 +129,85 @@ static int hi6220_phy_exit(struct phy *phy)
>   return hi6220_phy_setup(priv, false);
>  }
>  
> +
>  static struct phy_ops hi6220_phy_ops = {
>   .init   = hi6220_phy_start,
>   .exit   = hi6220_phy_exit,
>   .owner  = THIS_MODULE,
>  };
>  
> +static void hi6220_detect_work(struct work_struct *work)
> +{
> + struct hi6220_priv *priv =
> + container_of(to_delayed_work(work), struct hi6220_priv, work);
> + struct usb_otg *otg = priv->phy.otg;
> +
> + if (!IS_ERR(priv->vbus.extcon))
> + priv->vbus.state = extcon_get_cable_state_(priv->vbus.extcon,
> +  EXTCON_USB);
> + if (!IS_ERR(priv->id.extcon))
> + priv->id.state = extcon_get_cable_state_(priv->id.extcon,
> +  EXTCON_USB_HOST);
> + if (otg->gadget) {
> + if (priv->id.state)
> +  

Re: [PATCH v3 1/3] phy_sun4i_usb: set_mode: Allow using set_mode to force end the current session

[Kishon Vijay Abraham I]

On Friday 23 September 2016 07:10 PM, Hans de Goede wrote:
> The sunxi musb has a bug where sometimes it will generate a babble
> error on device disconnect instead of a disconnect irq. When this
> happens the musb-controller switches from host mode to device mode
> (it clears MUSB_DEVCTL_SESSION and sets MUSB_DEVCTL_BDEVICE) and
> gets stuck in this state.
> 
> Clearing this requires reporting Vbus low for 200 or more ms, but
> on some devices Vbus is simply always high (host-only mode, no Vbus
> control).
> 
> This commit modifies sun4i_usb_phy_set_mode so that it will force
> end the current session when called with the current mode, before this
> commit calling set_mode with the current mode was a nop since id_det
> would stay the same resulting in the detect_work not doing anything.
> 
> This allows the sunxi-musb glue to use sun4i_usb_phy_set_mode to force
> end the current session without changing the mode, to fixup the stuck
> state after a babble error.
> 
> Signed-off-by: Hans de Goede 

merged, thanks.

-Kishon
> ---
> Changes in v2:
> -New patch in v2 of this series replacing the
>  "phy-sun4i-usb: Add sun4i_usb_phy_force_session_end() function"
>  from v1
> Changes in v3:
> -Fix dev_info so that it prints the new-mode instead of the old one
> ---
>  drivers/phy/phy-sun4i-usb.c | 14 ++
>  1 file changed, 10 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/phy/phy-sun4i-usb.c b/drivers/phy/phy-sun4i-usb.c
> index 43c0d98..cbd338d 100644
> --- a/drivers/phy/phy-sun4i-usb.c
> +++ b/drivers/phy/phy-sun4i-usb.c
> @@ -437,25 +437,31 @@ static int sun4i_usb_phy_set_mode(struct phy *_phy, 
> enum phy_mode mode)
>  {
>   struct sun4i_usb_phy *phy = phy_get_drvdata(_phy);
>   struct sun4i_usb_phy_data *data = to_sun4i_usb_phy_data(phy);
> + int new_mode;
>  
>   if (phy->index != 0)
>   return -EINVAL;
>  
>   switch (mode) {
>   case PHY_MODE_USB_HOST:
> - data->dr_mode = USB_DR_MODE_HOST;
> + new_mode = USB_DR_MODE_HOST;
>   break;
>   case PHY_MODE_USB_DEVICE:
> - data->dr_mode = USB_DR_MODE_PERIPHERAL;
> + new_mode = USB_DR_MODE_PERIPHERAL;
>   break;
>   case PHY_MODE_USB_OTG:
> - data->dr_mode = USB_DR_MODE_OTG;
> + new_mode = USB_DR_MODE_OTG;
>   break;
>   default:
>   return -EINVAL;
>   }
>  
> - dev_info(&_phy->dev, "Changing dr_mode to %d\n", (int)data->dr_mode);
> + if (new_mode != data->dr_mode) {
> + dev_info(&_phy->dev, "Changing dr_mode to %d\n", new_mode);
> + data->dr_mode = new_mode;
> + }
> +
> + data->id_det = -1; /* Force reprocessing of id */
>   data->force_session_end = true;
>   queue_delayed_work(system_wq, >detect, 0);
>  
> 
--
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] phy: twl4030-usb: Fix for musb session bit based PM

[Kishon Vijay Abraham I]

On Wednesday 16 November 2016 03:29 AM, Bin Liu wrote:
> On Tue, Nov 15, 2016 at 01:37:55PM -0800, Tony Lindgren wrote:
>> Now with musb driver implementing generic session bit based
>> PM, we need to have the USB PHYs behaving in a sane way for
>> platforms implementing PM.
>>
>> Currently twl4030-usb enables PM in twl4030_phy_power_on()
>> and then disables it in twl4030_phy_power_off(). This will
>> block PM runtime for the SoC when no cable is connected.
>>
>> Fix the issue by moving PM runtime autosuspend call to
>> happen where it gets called in twl4030_phy_power_on().
>>
>> Note that this patch should not be backported to anything
>> before commit 467d5c980709 ("usb: musb: Implement session bit
>> based runtime PM for musb-core") as before that all the
>> glue layers implemented their own PM.
>>
>> Fixes: 467d5c980709 ("usb: musb: Implement session bit based
>> runtime PM for musb-core")
>> Tested-by: Ladislav Michl <la...@linux-mips.org>
>> Tested-by: Laurent Pinchart <laurent.pinch...@ideasonboard.com>
>> Signed-off-by: Tony Lindgren <t...@atomide.com>
> 
> I would need Kishon's Acked-by, or he picks it to his tree.

Acked-by: Kishon Vijay Abraham I <kis...@ti.com>
> 
> Thanks,
> -Bin.
> 
>> ---
>>  drivers/phy/phy-twl4030-usb.c | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/phy/phy-twl4030-usb.c b/drivers/phy/phy-twl4030-usb.c
>> --- a/drivers/phy/phy-twl4030-usb.c
>> +++ b/drivers/phy/phy-twl4030-usb.c
>> @@ -459,8 +459,6 @@ static int twl4030_phy_power_off(struct phy *phy)
>>  struct twl4030_usb *twl = phy_get_drvdata(phy);
>>  
>>  dev_dbg(twl->dev, "%s\n", __func__);
>> -pm_runtime_mark_last_busy(twl->dev);
>> -pm_runtime_put_autosuspend(twl->dev);
>>  
>>  return 0;
>>  }
>> @@ -472,6 +470,8 @@ static int twl4030_phy_power_on(struct phy *phy)
>>  dev_dbg(twl->dev, "%s\n", __func__);
>>  pm_runtime_get_sync(twl->dev);
>>  schedule_delayed_work(>id_workaround_work, HZ);
>> +pm_runtime_mark_last_busy(twl->dev);
>> +pm_runtime_put_autosuspend(twl->dev);
>>  
>>  return 0;
>>  }
>> -- 
>> 2.10.2
--
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] phy: rcar-gen3-usb2: add sysfs for usb role swap

[Kishon Vijay Abraham I]

On Wednesday 09 November 2016 08:00 AM, Yoshihiro Shimoda wrote:
> This patch adds sysfs "role" for usb role swap. This parameter can be
> read and write. If you use this file as the following, you can swap
> the usb role.
> 
> For example:
>  1) Connect a usb cable using 2 Salvator-x boards
>  2) On A-Device (ID pin is low), you input the following command:
># echo peripheral > /sys/devices/platform/soc/ee080200.usb-phy/role
>  3) On B-Device (ID pin is high), you input the following command:
># echo host > /sys/devices/platform/soc/ee080200.usb-phy/role
> 
> Then, the A-device acts as a peripheral and the B-device acts as a host.
> Please note that A-Device must input the following command if you
> want the board to act as a host again. (even if you disconnect the usb
> cable, since id state may be the same, the A-Device keeps to act as
> peripheral.)
>  # echo host > /sys/devices/platform/soc/ee080200.usb-phy/role
> 
> Signed-off-by: Yoshihiro Shimoda 
> Reviewed-by: Peter Chen 

merged to phy -next.

Thanks
Kishon
> ---
>  This patch is based on the latest linux-phy.git / next branch.
>  (commit id = 7809cd2ce6abd4f431e4b14e6b1276a7cc842ac4)
> 
>  Since this patch is related to usb, I added email addresses of Greg, Felipe,
>  Peter and USB ML as CC. (This patch doesn't use USB OTG FSM though.)
> 
>  Changes from v4:
>   - Use if-else about the is_b_device check in role_store().
>   - Add "Reviewed-by: Peter Chen "
> 
>  Changes from v3:
>   - Clean up redundant conditions in role_store().
> 
>  Changes from v2:
>   - Modify the sysfs file name to "role", and the argument is "host" or
> "peripheral". Peter suggested this. Thank you!
> 
>  Changes from v1:
>   - rebase the latest next branch.
> 
>  .../ABI/testing/sysfs-platform-phy-rcar-gen3-usb2  |  15 +++
>  drivers/phy/phy-rcar-gen3-usb2.c   | 118 
> -
>  2 files changed, 132 insertions(+), 1 deletion(-)
>  create mode 100644 
> Documentation/ABI/testing/sysfs-platform-phy-rcar-gen3-usb2
> 
> diff --git a/Documentation/ABI/testing/sysfs-platform-phy-rcar-gen3-usb2 
> b/Documentation/ABI/testing/sysfs-platform-phy-rcar-gen3-usb2
> new file mode 100644
> index 000..6212697
> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-platform-phy-rcar-gen3-usb2
> @@ -0,0 +1,15 @@
> +What:/sys/devices/platform//role
> +Date:October 2016
> +KernelVersion:   4.10
> +Contact: Yoshihiro Shimoda 
> +Description:
> + This file can be read and write.
> + The file can show/change the phy mode for role swap of usb.
> +
> + Write the following strings to change the mode:
> +  "host" - switching mode from peripheral to host.
> +  "peripheral" - switching mode from host to peripheral.
> +
> + Read the file, then it shows the following strings:
> +  "host" - The mode is host now.
> +  "peripheral" - The mode is peripheral now.
> diff --git a/drivers/phy/phy-rcar-gen3-usb2.c 
> b/drivers/phy/phy-rcar-gen3-usb2.c
> index 3d97ead..c63da1b 100644
> --- a/drivers/phy/phy-rcar-gen3-usb2.c
> +++ b/drivers/phy/phy-rcar-gen3-usb2.c
> @@ -70,6 +70,7 @@
>  #define USB2_LINECTRL1_DP_RPDBIT(18)
>  #define USB2_LINECTRL1_DMRPD_EN  BIT(17)
>  #define USB2_LINECTRL1_DM_RPDBIT(16)
> +#define USB2_LINECTRL1_OPMODE_NODRV  BIT(6)
>  
>  /* ADPCTRL */
>  #define USB2_ADPCTRL_OTGSESSVLD  BIT(20)
> @@ -161,6 +162,43 @@ static void rcar_gen3_init_for_peri(struct 
> rcar_gen3_chan *ch)
>   schedule_work(>work);
>  }
>  
> +static void rcar_gen3_init_for_b_host(struct rcar_gen3_chan *ch)
> +{
> + void __iomem *usb2_base = ch->base;
> + u32 val;
> +
> + val = readl(usb2_base + USB2_LINECTRL1);
> + writel(val | USB2_LINECTRL1_OPMODE_NODRV, usb2_base + USB2_LINECTRL1);
> +
> + rcar_gen3_set_linectrl(ch, 1, 1);
> + rcar_gen3_set_host_mode(ch, 1);
> + rcar_gen3_enable_vbus_ctrl(ch, 0);
> +
> + val = readl(usb2_base + USB2_LINECTRL1);
> + writel(val & ~USB2_LINECTRL1_OPMODE_NODRV, usb2_base + USB2_LINECTRL1);
> +}
> +
> +static void rcar_gen3_init_for_a_peri(struct rcar_gen3_chan *ch)
> +{
> + rcar_gen3_set_linectrl(ch, 0, 1);
> + rcar_gen3_set_host_mode(ch, 0);
> + rcar_gen3_enable_vbus_ctrl(ch, 1);
> +}
> +
> +static void rcar_gen3_init_from_a_peri_to_a_host(struct rcar_gen3_chan *ch)
> +{
> + void __iomem *usb2_base = ch->base;
> + u32 val;
> +
> + val = readl(usb2_base + USB2_OBINTEN);
> + writel(val & ~USB2_OBINT_BITS, usb2_base + USB2_OBINTEN);
> +
> + rcar_gen3_enable_vbus_ctrl(ch, 0);
> + rcar_gen3_init_for_host(ch);
> +
> + writel(val | USB2_OBINT_BITS, usb2_base + USB2_OBINTEN);
> +}
> +
>  static bool rcar_gen3_check_id(struct rcar_gen3_chan *ch)
>  {
>   return 

Re: [PATCH] phy: twl4030-usb: make driver DT only

[Kishon Vijay Abraham I]

Hi,

On Saturday 12 November 2016 04:09 PM, Nicolae Rosia wrote:
> All users are DT-only and it makes no sense to keep
> unused code

Are you sure about this? I still see a bunch of board files in mach-omap2 using
twl4030.

Thanks
Kishon
> 
> Signed-off-by: Nicolae Rosia 
> ---
>  drivers/phy/Kconfig   |  1 +
>  drivers/phy/phy-twl4030-usb.c | 22 +++---
>  2 files changed, 8 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> index fe00f91..265391e 100644
> --- a/drivers/phy/Kconfig
> +++ b/drivers/phy/Kconfig
> @@ -196,6 +196,7 @@ config TWL4030_USB
>   depends on TWL4030_CORE && REGULATOR_TWL4030 && USB_MUSB_OMAP2PLUS
>   depends on USB_SUPPORT
>   depends on USB_GADGET || !USB_GADGET # if USB_GADGET=m, this can't 'y'
> + depends on OF
>   select GENERIC_PHY
>   select USB_PHY
>   help
> diff --git a/drivers/phy/phy-twl4030-usb.c b/drivers/phy/phy-twl4030-usb.c
> index 87e6334..a5e4927 100644
> --- a/drivers/phy/phy-twl4030-usb.c
> +++ b/drivers/phy/phy-twl4030-usb.c
> @@ -656,7 +656,6 @@ static const struct dev_pm_ops twl4030_usb_pm_ops = {
>  
>  static int twl4030_usb_probe(struct platform_device *pdev)
>  {
> - struct twl4030_usb_data *pdata = dev_get_platdata(>dev);
>   struct twl4030_usb  *twl;
>   struct phy  *phy;
>   int status, err;
> @@ -664,19 +663,17 @@ static int twl4030_usb_probe(struct platform_device 
> *pdev)
>   struct device_node  *np = pdev->dev.of_node;
>   struct phy_provider *phy_provider;
>  
> + if (!np) {
> + dev_err(>dev, "no DT info\n");
> + return -EINVAL;
> + }
> +
>   twl = devm_kzalloc(>dev, sizeof(*twl), GFP_KERNEL);
>   if (!twl)
>   return -ENOMEM;
>  
> - if (np)
> - of_property_read_u32(np, "usb_mode",
> - (enum twl4030_usb_mode *)>usb_mode);
> - else if (pdata) {
> - twl->usb_mode = pdata->usb_mode;
> - } else {
> - dev_err(>dev, "twl4030 initialized without pdata\n");
> - return -EINVAL;
> - }
> + of_property_read_u32(np, "usb_mode",
> + (enum twl4030_usb_mode *)>usb_mode);
>  
>   otg = devm_kzalloc(>dev, sizeof(*otg), GFP_KERNEL);
>   if (!otg)
> @@ -750,11 +747,6 @@ static int twl4030_usb_probe(struct platform_device 
> *pdev)
>   return status;
>   }
>  
> - if (pdata)
> - err = phy_create_lookup(phy, "usb", "musb-hdrc.0");
> - if (err)
> - return err;
> -
>   pm_runtime_mark_last_busy(>dev);
>   pm_runtime_put_autosuspend(twl->dev);
>  
> 
--
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 2/4] phy: da8xx-usb: Configure CFGCHIP2 to support OTG workaround

[Kishon Vijay Abraham I]

On Monday 07 November 2016 06:35 PM, Alexandre Bailon wrote:
> If we configure the da8xx OTG phy in OTG mode, neither device or host
> mode will work. That is because the PHY is not able to detect and notify
> the driver that value of ID pin changed.
> To work despite this hardware limitation, the da8xx glue implement a
> workaround.
> But to work, the workaround require the VBUS sense and the session end
> comparator to enabled.
> Enable them if the phy is configured in OTG mode.
> 
> Signed-off-by: Alexandre Bailon 

merged this to phy -next.

Thanks
Kishon
> ---
>  drivers/phy/phy-da8xx-usb.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/drivers/phy/phy-da8xx-usb.c b/drivers/phy/phy-da8xx-usb.c
> index 32ae78c..089c13b 100644
> --- a/drivers/phy/phy-da8xx-usb.c
> +++ b/drivers/phy/phy-da8xx-usb.c
> @@ -23,6 +23,8 @@
>  #include 
>  #include 
>  
> +#define PHY_INIT_BITS(CFGCHIP2_SESENDEN | CFGCHIP2_VBDTCTEN)
> +
>  struct da8xx_usb_phy {
>   struct phy_provider *phy_provider;
>   struct phy  *usb11_phy;
> @@ -207,6 +209,9 @@ static int da8xx_usb_phy_probe(struct platform_device 
> *pdev)
>   dev_warn(dev, "Failed to create usb20 phy lookup\n");
>   }
>  
> + regmap_write_bits(d_phy->regmap, CFGCHIP(2),
> +   PHY_INIT_BITS, PHY_INIT_BITS);
> +
>   return 0;
>  }
>  
> 
--
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 2/3] phy: da8xx-usb: rename the ohci device to ohci-da8xx

[Kishon Vijay Abraham I]

On Thursday 03 November 2016 09:33 PM, Axel Haslam wrote:
> The ohci device name has changed in the board configuraion files,
> hence, change the phy lookup table to match the new name.
> 
> Signed-off-by: Axel Haslam 

merged, thanks.

-Kishon
> ---
>  drivers/phy/phy-da8xx-usb.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/phy/phy-da8xx-usb.c b/drivers/phy/phy-da8xx-usb.c
> index 32ae78c..c85fb0b 100644
> --- a/drivers/phy/phy-da8xx-usb.c
> +++ b/drivers/phy/phy-da8xx-usb.c
> @@ -198,7 +198,8 @@ static int da8xx_usb_phy_probe(struct platform_device 
> *pdev)
>   } else {
>   int ret;
>  
> - ret = phy_create_lookup(d_phy->usb11_phy, "usb-phy", "ohci.0");
> + ret = phy_create_lookup(d_phy->usb11_phy, "usb-phy",
> + "ohci-da8xx");
>   if (ret)
>   dev_warn(dev, "Failed to create usb11 phy lookup\n");
>   ret = phy_create_lookup(d_phy->usb20_phy, "usb-phy",
> @@ -216,7 +217,7 @@ static int da8xx_usb_phy_remove(struct platform_device 
> *pdev)
>  
>   if (!pdev->dev.of_node) {
>   phy_remove_lookup(d_phy->usb20_phy, "usb-phy", "musb-da8xx");
> - phy_remove_lookup(d_phy->usb11_phy, "usb-phy", "ohci.0");
> + phy_remove_lookup(d_phy->usb11_phy, "usb-phy", "ohci-da8xx");
>   }
>  
>   return 0;
> 
--
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] phy: da8xx-usb: rename the ohci device to ohci-da8xx

[Kishon Vijay Abraham I]

On Friday 04 November 2016 11:04 AM, Sekhar Nori wrote:
> Hi Kishon,
> 
> On Thursday 03 November 2016 10:20 PM, Kishon Vijay Abraham I wrote:
>>
>>
>> On Wednesday 02 November 2016 06:14 PM, Axel Haslam wrote:
>>> There is only one ohci on the da8xx series of chips,
>>> so remove the ".0" when creating the phy. Also add
>>> the "-da8xx" postfix to be consistent across davinci
>>> usb drivers.
>>>
>>> Signed-off-by: Axel Haslam <ahas...@baylibre.com>
>>
>> Acked-by: Kishon Vijay Abraham I <kis...@ti.com>
> 
> You will have to carry this patch from your tree. I thought I can carry
> the entire series, but the USB patch depends on other patches that Greg
> has already queued. So I think its best if the individual patches go
> through their respective trees.
> 
> Note that there is a v2 already submitted.

Okay. I can pick them in my tree.

Thanks
Kishon
--
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/5] dt/bindings: Add a new property to DA8xx USB PHY

[Kishon Vijay Abraham I]

Hi,

On Thursday 03 November 2016 10:56 PM, Alexandre Bailon wrote:
> On 11/03/2016 05:34 PM, Kishon Vijay Abraham I wrote:
>> Hi,
>>
>> On Thursday 03 November 2016 08:56 PM, Alexandre Bailon wrote:
>>> The USB PHY is able to operate in OTG, host or peripheral.
>>> Some board may be wired to work act only as host or peripheral.
>>> In such case, the dr_mode property of controller must be set to
>>> host or peripheral. But doing that will also configure the PHY
>>> in host or peripheral mode whereas OTG is able to detect which
>>> role the USB controller should take.
>>> The PHY's host or peripheral mode are actually only useful when
>>> hardware doesn't allow OTG to detect it's role.
>>>
>>> Add the usb20_force_mode property to force the PHY to operate
>>> in host or peripheral mode.
>>
>> I think we do just that if we populate dr_mode with host or peripheral. Why 
>> do
>> we need another property to control dr_mode property?
> Because the phy doesn't work correctly when it is in host or
> device mode.

That would be the same even with usb20_force_mode property. How does
usb20_force_mode property help?

Thanks
Kishon

>>> When usb20_force_mode is used, dr_mode should also be configured
>>> to host or peripheral.
>>> The controller uses dr_mode to configure itself, but the phy use
>>> it to get the mode to use to configure the PHY mode.
>>>
>>> Signed-off-by: Alexandre Bailon <abai...@baylibre.com>
>>> ---
>>>  Documentation/devicetree/bindings/phy/phy-da8xx-usb.txt | 5 +
>>>  1 file changed, 5 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/phy/phy-da8xx-usb.txt 
>>> b/Documentation/devicetree/bindings/phy/phy-da8xx-usb.txt
>>> index c26478b..9fc87fb 100644
>>> --- a/Documentation/devicetree/bindings/phy/phy-da8xx-usb.txt
>>> +++ b/Documentation/devicetree/bindings/phy/phy-da8xx-usb.txt
>>> @@ -4,6 +4,11 @@ Required properties:
>>>   - compatible: must be "ti,da830-usb-phy".
>>>   - #phy-cells: must be 1.
>>>  
>>> +Optional properties:
>>> +- usb20-force-mode: Force the phy to operate in same mode than the USB OTG 
>>> controller.
>>> +   It should only be defined if the hardware is not capable 
>>> correctly
>>> +   detect the role of USB by using VBUS and ID pin.
>>
>> From what I understand from the previous patch, if VBUS sense and the session
>> end comparator is enabled, the controller can work in host mode or device 
>> mode.
> I but VBUS sense and and session end comparator only seems to work when
> the phy is in otg mode.
> In host mode, the phy stop to work after the first disconnect.
> In device mode, the phy never detect a disconnect.
> In otg mode, these issues go away.
> I'm working on workaround for both of them but I think it is
> better to keep the phy in otg when it is possible.
>>
>> Thanks
>> Kishon
>>
> Thanks,
> Alexandre
> 
--
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] phy: da8xx-usb: rename the ohci device to ohci-da8xx

[Kishon Vijay Abraham I]

On Wednesday 02 November 2016 06:14 PM, Axel Haslam wrote:
> There is only one ohci on the da8xx series of chips,
> so remove the ".0" when creating the phy. Also add
> the "-da8xx" postfix to be consistent across davinci
> usb drivers.
> 
> Signed-off-by: Axel Haslam <ahas...@baylibre.com>

Acked-by: Kishon Vijay Abraham I <kis...@ti.com>
> ---
>  drivers/phy/phy-da8xx-usb.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/phy/phy-da8xx-usb.c b/drivers/phy/phy-da8xx-usb.c
> index 32ae78c..c85fb0b 100644
> --- a/drivers/phy/phy-da8xx-usb.c
> +++ b/drivers/phy/phy-da8xx-usb.c
> @@ -198,7 +198,8 @@ static int da8xx_usb_phy_probe(struct platform_device 
> *pdev)
>   } else {
>   int ret;
>  
> - ret = phy_create_lookup(d_phy->usb11_phy, "usb-phy", "ohci.0");
> + ret = phy_create_lookup(d_phy->usb11_phy, "usb-phy",
> + "ohci-da8xx");
>   if (ret)
>   dev_warn(dev, "Failed to create usb11 phy lookup\n");
>   ret = phy_create_lookup(d_phy->usb20_phy, "usb-phy",
> @@ -216,7 +217,7 @@ static int da8xx_usb_phy_remove(struct platform_device 
> *pdev)
>  
>   if (!pdev->dev.of_node) {
>   phy_remove_lookup(d_phy->usb20_phy, "usb-phy", "musb-da8xx");
> - phy_remove_lookup(d_phy->usb11_phy, "usb-phy", "ohci.0");
> + phy_remove_lookup(d_phy->usb11_phy, "usb-phy", "ohci-da8xx");
>   }
>  
>   return 0;
> 
--
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/5] dt/bindings: Add a new property to DA8xx USB PHY

[Kishon Vijay Abraham I]

Hi,

On Thursday 03 November 2016 08:56 PM, Alexandre Bailon wrote:
> The USB PHY is able to operate in OTG, host or peripheral.
> Some board may be wired to work act only as host or peripheral.
> In such case, the dr_mode property of controller must be set to
> host or peripheral. But doing that will also configure the PHY
> in host or peripheral mode whereas OTG is able to detect which
> role the USB controller should take.
> The PHY's host or peripheral mode are actually only useful when
> hardware doesn't allow OTG to detect it's role.
> 
> Add the usb20_force_mode property to force the PHY to operate
> in host or peripheral mode.

I think we do just that if we populate dr_mode with host or peripheral. Why do
we need another property to control dr_mode property?
> When usb20_force_mode is used, dr_mode should also be configured
> to host or peripheral.
> The controller uses dr_mode to configure itself, but the phy use
> it to get the mode to use to configure the PHY mode.
> 
> Signed-off-by: Alexandre Bailon 
> ---
>  Documentation/devicetree/bindings/phy/phy-da8xx-usb.txt | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/phy/phy-da8xx-usb.txt 
> b/Documentation/devicetree/bindings/phy/phy-da8xx-usb.txt
> index c26478b..9fc87fb 100644
> --- a/Documentation/devicetree/bindings/phy/phy-da8xx-usb.txt
> +++ b/Documentation/devicetree/bindings/phy/phy-da8xx-usb.txt
> @@ -4,6 +4,11 @@ Required properties:
>   - compatible: must be "ti,da830-usb-phy".
>   - #phy-cells: must be 1.
>  
> +Optional properties:
> +- usb20-force-mode: Force the phy to operate in same mode than the USB OTG 
> controller.
> + It should only be defined if the hardware is not capable 
> correctly
> + detect the role of USB by using VBUS and ID pin.

>From what I understand from the previous patch, if VBUS sense and the session
end comparator is enabled, the controller can work in host mode or device mode.

Thanks
Kishon
--
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] phy: Add reset callback for not generic phy

[Kishon Vijay Abraham I]

On Wednesday 26 October 2016 02:17 AM, John Youn wrote:
> On 10/25/2016 7:15 AM, Randy Li wrote:
>> I forget to add a dummy function in case the CONFIG_GENERIC_PHY
>> is disabled.
>>
>> Signed-off-by: Randy Li 
> 
> Fixes: cac18ecb6f44 ("phy: Add reset callback")
> Tested-by: John Youn 
> 
> Hi Kishon,
> 
> Can you take this for 4.9-rc?

sure, merged now.

Thanks
Kishon

> 
> Thanks,
> John
> 
> 
> 
>> ---
>>  include/linux/phy/phy.h | 7 +++
>>  1 file changed, 7 insertions(+)
>>
>> diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
>> index ee1bed7..78bb0d7 100644
>> --- a/include/linux/phy/phy.h
>> +++ b/include/linux/phy/phy.h
>> @@ -253,6 +253,13 @@ static inline int phy_set_mode(struct phy *phy, enum 
>> phy_mode mode)
>>  return -ENOSYS;
>>  }
>>  
>> +static inline int phy_reset(struct phy *phy)
>> +{
>> +if (!phy)
>> +return 0;
>> +return -ENOSYS;
>> +}
>> +
>>  static inline int phy_get_bus_width(struct phy *phy)
>>  {
>>  return -ENOSYS;
>>
>>
> 
> 
> 
--
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] phy: nop: Add a new phy driver for No-Op transceiver

[Kishon Vijay Abraham I]

Hi,

On Tuesday 04 October 2016 04:13 PM, Vivek Gautam wrote:
> No-Op phy transceiver can be used on platforms that have
> controllers which themselves provide PHY functionality and
> there's no separate PHY controller available.
> 
> This driver provides a basic skeleton for a nop-phy driver.
> This can be further extended to add required features.
> 
> Inspired by phy-generic driver in drivers/usb/phy.
> 
> Signed-off-by: Vivek Gautam <vivek.gau...@codeaurora.org>
> Cc: Kishon Vijay Abraham I <kis...@ti.com>
> Cc: Felipe Balbi <ba...@kernel.org>
> ---
> 
> Hi Kishon, Felipe,
> 
> This patch has been lying in my tree for sometime.
> This introduces a skeletal nop-phy driver based on generic
> phy framework.
> I mainly use this driver when I have only one phy driver available
> for testing for a controller that uses more than one phy.
> 
> But this can be further extended to add any feature support for
> controllers that don't have a separate PHY controller and that
> themselves provide the PHY functionality, a purpose similar
> to what drivers/usb/phy/phy-generic.c driver serves.
> 
> Do you think we have a requirement for such a driver in the generic
> phy layer? I hope this driver can do some good.
> Let me know your comments on this.
> 
> Thanks
> Vivek
> 
>  Documentation/devicetree/bindings/phy/phy-nop.txt |  22 +++
>  drivers/phy/Kconfig   |  10 ++
>  drivers/phy/Makefile  |   1 +
>  drivers/phy/phy-nop.c | 193 
> ++
>  4 files changed, 226 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/phy/phy-nop.txt
>  create mode 100644 drivers/phy/phy-nop.c
> 
> diff --git a/Documentation/devicetree/bindings/phy/phy-nop.txt 
> b/Documentation/devicetree/bindings/phy/phy-nop.txt
> new file mode 100644
> index 000..6cb6779
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/phy-nop.txt
> @@ -0,0 +1,22 @@
> +Generic No-Op PHY
> +-
> +
> +Required properties:
> + - compatible: compatible list, contains "phy-nop".
> + - #phy-cells: must be 0.
> +
> +Optional properties:
> + - clocks: a list of phandles and clock-specifier pairs,
> +one for each entry in clock-names.
> + - clock-names: must be "main_clk" for phy core clock,
> + "ref_clk" for phy reference clk.
> + - resets: a list of phandles and reset controller specifier pairs,
> +one for each entry in reset-names.
> + - reset-names: must be  "phy" for reset of phy block.
> + - vdd-supply: Phandle to a regulator supply to PHY core block.
> +
> +Example:
> + phy_nop: phy_nop {
> + compatible = "phy-nop";
> + #phy-cells = <0>;
> + };

I don't think this qualifies to be modeled as dt. device tree should try to
represent HW and not workaround SW issues by creating dummy nodes. For such
cases phy_optional_get should suffice?

I'm more towards having a simple-phy, along the lines of [1]

[1] -> https://patchwork.kernel.org/patch/8153691/

Thanks
Kishon
> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> index fe00f91..1923c4f 100644
> --- a/drivers/phy/Kconfig
> +++ b/drivers/phy/Kconfig
> @@ -489,4 +489,14 @@ config PHY_NS2_PCIE
>   help
> Enable this to support the Broadcom Northstar2 PCIe PHY.
> If unsure, say N.
> +
> +config PHY_NOP
> + tristate "No-Operation PHY transceiver driver"
> + depends on OF || COMPILE_TEST
> + select GENERIC_PHY
> + help
> +   Enable this to support the generic no-operation PHY
> +   transeiver. This driver can be used with consumers
> +   requiring a no-op phy for few of the handlers.
> +
>  endmenu
> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
> index a534cf5..d6e0e60 100644
> --- a/drivers/phy/Makefile
> +++ b/drivers/phy/Makefile
> @@ -60,3 +60,4 @@ obj-$(CONFIG_PHY_PISTACHIO_USB) += 
> phy-pistachio-usb.o
>  obj-$(CONFIG_PHY_CYGNUS_PCIE)+= phy-bcm-cygnus-pcie.o
>  obj-$(CONFIG_ARCH_TEGRA) += tegra/
>  obj-$(CONFIG_PHY_NS2_PCIE)   += phy-bcm-ns2-pcie.o
> +obj-$(CONFIG_PHY_NOP)+= phy-nop.o
> diff --git a/drivers/phy/phy-nop.c b/drivers/phy/phy-nop.c
> new file mode 100644
> index 000..cab01a1
> --- /dev/null
> +++ b/drivers/phy/phy-nop.c
> @@ -0,0 +1,193 @@
> +/*
> + * Copyright (c) 2016, The Linux Foundation. All rights reserved.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Publ

Re: [PATCH v2 3/6] phy: meson: add USB2 PHY support for Meson8b and GXBB

[Kishon Vijay Abraham I]

On Monday 19 September 2016 10:12 PM, Kevin Hilman wrote:
> Kishon Vijay Abraham I <kis...@ti.com> writes:
> 
>> Hi Kevin,
>>
>> On Wednesday 14 September 2016 09:36 PM, Kevin Hilman wrote:
>>> Kishon,
>>>
>>> Martin Blumenstingl <martin.blumensti...@googlemail.com> writes:
>>>
>>>> This is a new driver for the USB PHY found in Meson8b and GXBB SoCs.
>>>>
>>>> Signed-off-by: Martin Blumenstingl <martin.blumensti...@googlemail.com>
>>>> Signed-off-by: Jerome Brunet <jbru...@baylibre.com>
>>>> Tested-by: Kevin Hilman <khil...@baylibre.com>
>>>
>>> Will you be picking this up for v4.9?
>>
>> It's already late for 4.9. Generally send pull request to Greg around -rc6.
>> This can go only in 4.10.
> 
> That's fine.
> 
> Does that mean you have it queued someplace?  I don't see it in any of
> your branches.

I haven't queued so far. I'll create a testing branch to queue pending patches.

Thanks
Kishon
--
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] phy-sun4i-usb: Add sun4i_usb_phy_force_session_end() function

[Kishon Vijay Abraham I]

Hi,

On Sunday 18 September 2016 10:20 PM, Hans de Goede wrote:
> The sunxi musb has a bug where sometimes it will generate a babble
> error on device disconnect instead of a disconnect irq. When this
> happens the musb-controller switches from host mode to device mode
> (it clears MUSB_DEVCTL_SESSION and sets MUSB_DEVCTL_BDEVICE) and
> gets stuck in this state.
> 
> Clearing this requires reporting Vbus low for 200 or more ms, but
> on some devices Vbus is simply always high (host-only mode, no Vbus
> control). The phy-sun4i-usb code already has code to force a session
> end for devices without Vbus control.
> 
> This commit adds a sun4i_usb_phy_force_session_end() function exporting
> this functionality to the sunxi-musb glue, so that it can force a session
> end to fixup the stuck state after a babble error.
> 
> Signed-off-by: Hans de Goede 
> ---
>  drivers/phy/phy-sun4i-usb.c   | 11 +++
>  include/linux/phy/phy-sun4i-usb.h |  7 +++
>  2 files changed, 18 insertions(+)
> 
> diff --git a/drivers/phy/phy-sun4i-usb.c b/drivers/phy/phy-sun4i-usb.c
> index 43c0d98..06f4e11a 100644
> --- a/drivers/phy/phy-sun4i-usb.c
> +++ b/drivers/phy/phy-sun4i-usb.c
> @@ -470,6 +470,17 @@ void sun4i_usb_phy_set_squelch_detect(struct phy *_phy, 
> bool enabled)
>  }
>  EXPORT_SYMBOL_GPL(sun4i_usb_phy_set_squelch_detect);
>  
> +void sun4i_usb_phy_force_session_end(struct phy *_phy)
> +{
> + struct sun4i_usb_phy *phy = phy_get_drvdata(_phy);
> + struct sun4i_usb_phy_data *data = to_sun4i_usb_phy_data(phy);
> +
> + data->id_det = -1;
> + data->force_session_end = true;
> + queue_delayed_work(system_wq, >detect, 0);
> +}
> +EXPORT_SYMBOL_GPL(sun4i_usb_phy_force_session_end);

Er.. one more export symbol :-(
> +
>  static const struct phy_ops sun4i_usb_phy_ops = {
>   .init   = sun4i_usb_phy_init,
>   .exit   = sun4i_usb_phy_exit,
> diff --git a/include/linux/phy/phy-sun4i-usb.h 
> b/include/linux/phy/phy-sun4i-usb.h
> index 50aed92..3bb773f 100644
> --- a/include/linux/phy/phy-sun4i-usb.h
> +++ b/include/linux/phy/phy-sun4i-usb.h
> @@ -23,4 +23,11 @@
>   */
>  void sun4i_usb_phy_set_squelch_detect(struct phy *phy, bool enabled);
>  
> +/**
> + * sun4i_usb_force_session_end() - Force the current session to end
> + *  by reporting VBus low for 200+ ms
> + * @phy: reference to a sun4i usb phy
> + */
> +void sun4i_usb_phy_force_session_end(struct phy *phy);

Should we include a static inline function if sun4i phy is not defined?

Thanks
Kishon
--
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] phy: meson: add USB2 PHY support for Meson8b and GXBB

[Kishon Vijay Abraham I]

Hi,

On Monday 19 September 2016 01:26 AM, Martin Blumenstingl wrote:
> Hi Kishon,
> 
> On Fri, Sep 16, 2016 at 10:19 AM, Kishon Vijay Abraham I <kis...@ti.com> 
> wrote:
>> Hi,
>>
>> On Friday 09 September 2016 09:44 PM, Martin Blumenstingl wrote:
>>> On Fri, Sep 9, 2016 at 5:33 PM, Kevin Hilman <khil...@baylibre.com> wrote:
>>>> However, the problem with all of the solutions proposed (runtime PM ones
>>>> included) is that we're forcing a board-specific design issue (2 devices
>>>> sharing a reset line) into a driver that should not have any
>>>> board-specific assumptions in it.
>>>>
>>>> For example, if this driver is used on another platform where different
>>>> PHYs have different reset lines, then one of them (the unlucky one who
>>>> is not probed first) will never get reset.  So any form of per-device
>>>> ref-counting is not a portable solution.
>>> maybe we should also consider Ben's solution: he played with the USB
>>> PHY on his Meson8b board. His approach was to have only one USB PHY
>>> driver instance which exposes two PHYs.
>>> The downside of this: the driver would have to know the offset of the
>>> PHYs (0x0 for the first PHY, 0x20 for the second), but we could handle
>>> the reset using runtime PM without any hacks.
>>
>> I think the offset information can come from the devicetree too. The phy can 
>> be
>> modeled something like below.
>>
>> usb-phys@c000 {
>> compatible = "amlogic,meson-gxbb-usb2-phy";
>> reg = <0x0 0xc000 0x0 0x40>;
>> #address-cells = <2>;
>> #size-cells = <2>;
>> ranges = <0x0 0x0 0x0 0xc000 0x0 0x40>;
>> resets = < 34>;
>>
>> usb0_phy: usb_phy@0 {
>> #phy-cells = <0>;
>> reg = <0x0 0x0 0x0 0x20>;
>> clocks = < CLKID_USB  CLKID_USB0>;
>> clock-names = "usb_general", "usb";
>> status = "disabled";
>> };
>>
>> usb1_phy: usb_phy@20 {
>> #phy-cells = <0>;
>> reg = <0x0 0x20 0x0 0x20>;
>> clocks = < CLKID_USB  CLKID_USB1>;
>> clock-names = "usb_general", "usb";
>> status = "disabled";
>> };
>> };
>>
>> This way the driver will be probed only once (the reset can be done during
>> probe). The phy driver should scan the dt node and for every sub-node it
>> invokes phy_create?
> I'll recap what we have discussed so far (so you don't have to re-read
> the whole thread):
> The reference driver treats both USB PHYs as separate devices (the
> datasheet has no information about the PHYs though). The only
> "special" thing is the shared reset line -> together with Philipp
> Zabel (the reset framework maintainer) we decided to make
> reset_control_reset work for shared reset lines.
> 
> That means we can keep the two PHYs as separate devices inside the
> .dts, while keeping everything else separate (just like the reference
> driver)
> Is this fine for you and Arnd?

yeah.. I'm fine with that.

Thanks
Kishon
> 
> 
> Regards,
> Martin
> 
--
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/6] phy: meson: add USB2 PHY support for Meson8b and GXBB

[Kishon Vijay Abraham I]

Hi Kevin,

On Wednesday 14 September 2016 09:36 PM, Kevin Hilman wrote:
> Kishon,
> 
> Martin Blumenstingl  writes:
> 
>> This is a new driver for the USB PHY found in Meson8b and GXBB SoCs.
>>
>> Signed-off-by: Martin Blumenstingl 
>> Signed-off-by: Jerome Brunet 
>> Tested-by: Kevin Hilman 
> 
> Will you be picking this up for v4.9?

It's already late for 4.9. Generally send pull request to Greg around -rc6.
This can go only in 4.10.

Thanks
Kishon

> 
> Kevin
> 
>> ---
>>  drivers/phy/Kconfig  |  11 ++
>>  drivers/phy/Makefile |   1 +
>>  drivers/phy/phy-meson-usb2.c | 280 
>> +++
>>  3 files changed, 292 insertions(+)
>>  create mode 100644 drivers/phy/phy-meson-usb2.c
>>
>> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
>> index 19bff3a..6ad87ec 100644
>> --- a/drivers/phy/Kconfig
>> +++ b/drivers/phy/Kconfig
>> @@ -453,4 +453,15 @@ config PHY_NS2_PCIE
>>  help
>>Enable this to support the Broadcom Northstar2 PCIe PHY.
>>If unsure, say N.
>> +
>> +config PHY_MESON_USB2
>> +tristate "Meson USB2 PHY driver"
>> +default ARCH_MESON
>> +depends on OF && (ARCH_MESON || COMPILE_TEST)
>> +select GENERIC_PHY
>> +help
>> +  Enable this to support the Meson USB2 PHYs found in Meson8b
>> +  and GXBB SoCs.
>> +  If unsure, say N.
>> +
>>  endmenu
>> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
>> index 90ae198..dd507ac 100644
>> --- a/drivers/phy/Makefile
>> +++ b/drivers/phy/Makefile
>> @@ -56,3 +56,4 @@ obj-$(CONFIG_PHY_PISTACHIO_USB)+= 
>> phy-pistachio-usb.o
>>  obj-$(CONFIG_PHY_CYGNUS_PCIE)   += phy-bcm-cygnus-pcie.o
>>  obj-$(CONFIG_ARCH_TEGRA) += tegra/
>>  obj-$(CONFIG_PHY_NS2_PCIE)  += phy-bcm-ns2-pcie.o
>> +obj-$(CONFIG_PHY_MESON_USB2)+= phy-meson-usb2.o
>> diff --git a/drivers/phy/phy-meson-usb2.c b/drivers/phy/phy-meson-usb2.c
>> new file mode 100644
>> index 000..eece521
>> --- /dev/null
>> +++ b/drivers/phy/phy-meson-usb2.c
>> @@ -0,0 +1,280 @@
>> +/*
>> + * Meson USB2 PHY driver
>> + *
>> + * Copyright (C) 2016 Martin Blumenstingl 
>> 
>> + *
>> + * 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.
>> + *
>> + * You should have received a copy of the GNU General Public License
>> + * along with this program. If not, see .
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#define REG_CONFIG  0x00
>> +#define REG_CONFIG_CLK_EN   BIT(0)
>> +#define REG_CONFIG_CLK_SEL_MASK GENMASK(3, 1)
>> +#define REG_CONFIG_CLK_DIV_MASK GENMASK(10, 4)
>> +#define REG_CONFIG_CLK_32k_ALTSEL   BIT(15)
>> +#define REG_CONFIG_TEST_TRIGBIT(31)
>> +
>> +#define REG_CTRL0x04
>> +#define REG_CTRL_SOFT_PRST  BIT(0)
>> +#define REG_CTRL_SOFT_HRESETBIT(1)
>> +#define REG_CTRL_SS_SCALEDOWN_MODE_MASK GENMASK(3, 2)
>> +#define REG_CTRL_CLK_DET_RSTBIT(4)
>> +#define REG_CTRL_INTR_SEL   BIT(5)
>> +#define REG_CTRL_CLK_DETECTED   BIT(8)
>> +#define REG_CTRL_SOF_SENT_RCVD_TGL  BIT(9)
>> +#define REG_CTRL_SOF_TOGGLE_OUT BIT(10)
>> +#define REG_CTRL_POWER_ON_RESET BIT(15)
>> +#define REG_CTRL_SLEEPM BIT(16)
>> +#define REG_CTRL_TX_BITSTUFF_ENN_H  BIT(17)
>> +#define REG_CTRL_TX_BITSTUFF_ENNBIT(18)
>> +#define REG_CTRL_COMMON_ON  BIT(19)
>> +#define REG_CTRL_REF_CLK_SEL_MASK   GENMASK(21, 20)
>> +#define REG_CTRL_REF_CLK_SEL_SHIFT  20
>> +#define REG_CTRL_FSEL_MASK  GENMASK(24, 22)
>> +#define REG_CTRL_FSEL_SHIFT 22
>> +#define REG_CTRL_PORT_RESET BIT(25)
>> +#define REG_CTRL_THREAD_ID_MASK GENMASK(31, 26)
>> +
>> +#define REG_ENDP_INTR   0x08
>> +
>> +/* bits [31:26], [24:21] and [15:3] seem to be read-only */
>> +#define REG_ADP_BC  0x0c
>> +#define REG_ADP_BC_VBUS_VLD_EXT_SEL BIT(0)
>> +#define REG_ADP_BC_VBUS_VLD_EXT BIT(1)
>> +#define REG_ADP_BC_OTG_DISABLE  BIT(2)
>> +#define REG_ADP_BC_ID_PULLUPBIT(3)
>> +#define REG_ADP_BC_DRV_VBUS

Re: [PATCH 4/7] phy: meson: add USB2 PHY support for Meson8b and GXBB

[Kishon Vijay Abraham I]

Hi,

On Friday 09 September 2016 09:44 PM, Martin Blumenstingl wrote:
> On Fri, Sep 9, 2016 at 5:33 PM, Kevin Hilman  wrote:
>> However, the problem with all of the solutions proposed (runtime PM ones
>> included) is that we're forcing a board-specific design issue (2 devices
>> sharing a reset line) into a driver that should not have any
>> board-specific assumptions in it.
>>
>> For example, if this driver is used on another platform where different
>> PHYs have different reset lines, then one of them (the unlucky one who
>> is not probed first) will never get reset.  So any form of per-device
>> ref-counting is not a portable solution.
> maybe we should also consider Ben's solution: he played with the USB
> PHY on his Meson8b board. His approach was to have only one USB PHY
> driver instance which exposes two PHYs.
> The downside of this: the driver would have to know the offset of the
> PHYs (0x0 for the first PHY, 0x20 for the second), but we could handle
> the reset using runtime PM without any hacks.

I think the offset information can come from the devicetree too. The phy can be
modeled something like below.

usb-phys@c000 {
compatible = "amlogic,meson-gxbb-usb2-phy";
reg = <0x0 0xc000 0x0 0x40>;
#address-cells = <2>;
#size-cells = <2>;
ranges = <0x0 0x0 0x0 0xc000 0x0 0x40>;
resets = < 34>;

usb0_phy: usb_phy@0 {
#phy-cells = <0>;
reg = <0x0 0x0 0x0 0x20>;
clocks = < CLKID_USB  CLKID_USB0>;
clock-names = "usb_general", "usb";
status = "disabled";
};

usb1_phy: usb_phy@20 {
#phy-cells = <0>;
reg = <0x0 0x20 0x0 0x20>;
clocks = < CLKID_USB  CLKID_USB1>;
clock-names = "usb_general", "usb";
status = "disabled";
};
};

This way the driver will be probed only once (the reset can be done during
probe). The phy driver should scan the dt node and for every sub-node it
invokes phy_create?

Thanks
Kishon
--
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 22/22] phy: Add support for Qualcomm's USB HS phy

[Kishon Vijay Abraham I]

On Saturday 10 September 2016 05:48 PM, Kishon Vijay Abraham I wrote:
> 
> On Wed, Sep 07, 2016 at 02:35:19PM -0700, Stephen Boyd wrote:
>> The high-speed phy on qcom SoCs is controlled via the ULPI
>> viewport.
>>
>> Cc: Kishon Vijay Abraham I <kis...@ti.com>
>> Cc: <devicet...@vger.kernel.org>
>> Signed-off-by: Stephen Boyd <stephen.b...@linaro.org>
> 
> merged this and the previous patch to linux-phy.

since there are pending discussions, I'll drop this patch for now.

Thanks
Kishon
> 
> Thanks
> Kishon
> 
>> ---
>>  .../devicetree/bindings/phy/qcom,usb-hs-phy.txt|  83 ++
>>  drivers/phy/Kconfig|   8 +
>>  drivers/phy/Makefile   |   1 +
>>  drivers/phy/phy-qcom-usb-hs.c  | 289 
>> +
>>  4 files changed, 381 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/phy/qcom,usb-hs-phy.txt
>>  create mode 100644 drivers/phy/phy-qcom-usb-hs.c
>>
>> diff --git a/Documentation/devicetree/bindings/phy/qcom,usb-hs-phy.txt 
>> b/Documentation/devicetree/bindings/phy/qcom,usb-hs-phy.txt
>> new file mode 100644
>> index ..d7eacd63d06b
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/phy/qcom,usb-hs-phy.txt
>> @@ -0,0 +1,83 @@
>> +Qualcomm's USB HS PHY
>> +
>> +PROPERTIES
>> +
>> +- compatible:
>> +Usage: required
>> +Value type: 
>> +Definition: Should contain "qcom,usb-hs-phy" and more specifically one 
>> of the
>> +following:
>> +
>> +"qcom,usb-hs-phy-apq8064"
>> +"qcom,usb-hs-phy-msm8916"
>> +"qcom,usb-hs-phy-msm8974"
>> +
>> +- #phy-cells:
>> +Usage: required
>> +Value type: 
>> +Definition: Should contain 0
>> +
>> +- clocks:
>> +Usage: required
>> +Value type: 
>> +Definition: Should contain clock specifier for the reference and sleep
>> +clocks
>> +
>> +- clock-names:
>> +Usage: required
>> +Value type: 
>> +Definition: Should contain "ref" and "sleep" for the reference and sleep
>> +clocks respectively
>> +
>> +- resets:
>> +Usage: required
>> +Value type: 
>> +Definition: Should contain the phy and POR resets
>> +
>> +- reset-names:
>> +Usage: required
>> +Value type: 
>> +Definition: Should contain "phy" and "por" for the phy and POR resets
>> +respectively
>> +
>> +- v3p3-supply:
>> +Usage: required
>> +Value type: 
>> +Definition: Should contain a reference to the 3.3V supply
>> +
>> +- v1p8-supply:
>> +Usage: required
>> +Value type: 
>> +Definition: Should contain a reference to the 1.8V supply
>> +
>> +- extcon:
>> +Usage: optional
>> +Value type: 
>> +Definition: Should contain the vbus and ID extcons in the first and 
>> second
>> +cells respectively
>> +
>> +- qcom,init-seq:
>> +Usage: optional
>> +Value type: 
>> +Definition: Should contain a sequence of ULPI register and address 
>> pairs to
>> +program into the ULPI_EXT_VENDOR_SPECIFIC area. This is 
>> related
>> +to Device Mode Eye Diagram test.
>> +
>> +EXAMPLE
>> +
>> +otg: usb-controller {
>> +ulpi {
>> +phy {
>> +compatible = "qcom,usb-hs-phy-msm8974", 
>> "qcom,usb-hs-phy";
>> +#phy-cells = <0>;
>> +clocks = <_board>, < GCC_USB2A_PHY_SLEEP_CLK>;
>> +clock-names = "ref", "sleep";
>> +resets = < GCC_USB2A_PHY_BCR>, < 0>;
>> +reset-names = "phy", "por";
>> +v3p3-supply = <_l24>;
>> +v1p8-supply = <_l6>;
>> +extcon = <>, <_id>;
>> +qcom,init-seq = /bits/ 8 <0x81 0x63>;
>> +};
>> +};
>> +};
>> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
>> index 830c443eeabf..ee0ec021a98c 100644
>> --- a/drivers/phy/Kconfig
>> +++ b/drivers/phy/Kconfig
>>

Re: [PATCH v7 3/4] usb: dwc2: assert phy reset when waking up in rk3288 platform

[Kishon Vijay Abraham I]

Hi,

On Sunday 04 September 2016 03:25 AM, Randy Li wrote:
> On the rk3288 USB host-only port (the one that's not the OTG-enabled
> port) the PHY can get into a bad state when a wakeup is asserted (not
> just a wakeup from full system suspend but also a wakeup from
> autosuspend).
> 
> We can get the PHY out of its bad state by asserting its "port reset",
> but unfortunately that seems to assert a reset onto the USB bus so it
> could confuse things if we don't actually deenumerate / reenumerate the
> device.
> 
> We can also get the PHY out of its bad state by fully resetting it using
> the reset from the CRU (clock reset unit) in chip, which does a more full
> reset.  The CRU-based reset appears to actually cause devices on the bus
> to be removed and reinserted, which fixes the problem (albeit in a hacky
> way).
> 
> It's unfortunate that we need to do a full re-enumeration of devices at
> wakeup time, but this is better than alternative of letting the bus get
> wedged.
> 
> Signed-off-by: Randy Li 
> ---
>  drivers/usb/dwc2/core_intr.c | 12 
>  1 file changed, 12 insertions(+)
> 
> diff --git a/drivers/usb/dwc2/core_intr.c b/drivers/usb/dwc2/core_intr.c
> index d85c5c9..08485b7 100644
> --- a/drivers/usb/dwc2/core_intr.c
> +++ b/drivers/usb/dwc2/core_intr.c
> @@ -345,6 +345,7 @@ static void dwc2_handle_session_req_intr(struct 
> dwc2_hsotg *hsotg)
>  static void dwc2_handle_wakeup_detected_intr(struct dwc2_hsotg *hsotg)
>  {
>   int ret;
> + struct device_node *np = hsotg->dev->of_node;
>  
>   /* Clear interrupt */
>   dwc2_writel(GINTSTS_WKUPINT, hsotg->regs + GINTSTS);
> @@ -379,6 +380,17 @@ static void dwc2_handle_wakeup_detected_intr(struct 
> dwc2_hsotg *hsotg)
>   /* Restart the Phy Clock */
>   pcgcctl &= ~PCGCTL_STOPPCLK;
>   dwc2_writel(pcgcctl, hsotg->regs + PCGCTL);
> +
> + /*
> +  * It is a quirk in Rockchip RK3288, causing by
> +  * a hardware bug. This will propagate out and
> +  * eventually we'll re-enumerate the device. 
> +  * Not great but the best we can do 
> +  */
> + if (of_device_is_compatible(np, "rockchip,rk3288-usb")
> + && (NULL != hsotg->phy->ops->reset))
> + hsotg->phy->ops->reset(hsotg->phy);

never call the phy ops directly from the controller driver. It has to be
protected as well.

Thanks
Kishon
--
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] usb: phy: phy-brcm-usb: Add Broadcom STB USB Phy driver

[Kishon Vijay Abraham I]

Hi,

On Tuesday 30 August 2016 08:00 PM, Al Cooper wrote:
> Add a new USB Phy driver for Broadcom STB SoCs. This driver
> supports all Broadcom STB ARM SoCs. This driver in combination
> with the generic ohci, ehci and xhci platform drivers will enable
> USB1.1, USB2.0 and USB3.0 support. This Phy driver also supports
> the Broadcom UDC gadget driver.

Remove usb: from $subject
> 
> Signed-off-by: Al Cooper 
> ---
>  .../bindings/phy/brcm,brcmstb-usb-phy.txt  |  39 +
>  MAINTAINERS|   7 +
>  drivers/phy/Kconfig|  10 +
>  drivers/phy/Makefile   |   2 +
>  drivers/phy/phy-brcm-usb-init.c| 792 
> +

other broadcom phy drivers use only "bcm" in the file name.
>  drivers/phy/phy-brcm-usb-init.h|  49 ++
>  drivers/phy/phy-brcm-usb.c | 206 ++
>  7 files changed, 1105 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/phy/brcm,brcmstb-usb-phy.txt
>  create mode 100644 drivers/phy/phy-brcm-usb-init.c
>  create mode 100644 drivers/phy/phy-brcm-usb-init.h
>  create mode 100644 drivers/phy/phy-brcm-usb.c
> 
> diff --git a/Documentation/devicetree/bindings/phy/brcm,brcmstb-usb-phy.txt 
> b/Documentation/devicetree/bindings/phy/brcm,brcmstb-usb-phy.txt
> new file mode 100644
> index 000..34fa9dd
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/brcm,brcmstb-usb-phy.txt
> @@ -0,0 +1,39 @@
> +Broadcom STB USB PHY
> +
> +Required properties:
> + - compatible: brcm,brcmstb-usb-phy
> + - reg: two offset and length pairs. The second pair specifies the
> +USB 3.0 related registers and is only required for PHYs
> +that support USB 3.0

I think the right way to model this should be to have separate subnodes for
usb2 and usb3.
> + - #phy-cells: Shall be 1 as it expects one argument for setting
> +the type of the PHY. Possible values are 0 (1.1 and 2.0),
> +1 (3.0)
> +
> +
spurious blank space.
> +Optional Properties:
> +- clocks : phandle + clock specifier for the phy clocks
> +- clock-names: string, clock name
> +- ipp: Invert Port Power
> +- ioc: Invert Over Current detection
> +- has_xhci: Contains an optional 3.0 PHY

prefix all the broadcom specific properties with "bcm," or whatever is used for
broadcom specific properties.
> +- device: PHY Device mode. Possible values are: 0 (Host), 1 (Device)
> +  or 2 (DRD)
> +
> +
> +

spurious blank spaces..
> +Example:
> +
> +usbphy_0: usb-phy@f0470200 {
> + reg = <0xf0470200 0xb8>,
> + <0xf0471940 0x6c0>;
> + #address-cells = <1>;
> + #size-cells = <1>;

Why do you need address cells, size cells? Include it in the documentation.
> + compatible = "brcm,brcmstb-usb-phy";
> + ioc = <1>;
> + ipp = <1>;
> + #phy-cells = <1>;
> + ranges;
> + has_xhci;
> + clocks = <_usb20>;
> + clock-names = "sw_usb";
> +};
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 0bbe4b1..d58b124 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -2697,6 +2697,13 @@ S: Maintained
>  F:   drivers/bcma/
>  F:   include/linux/bcma/
>  
> +BROADCOM STB USB PHY DRIVER
> +M:   Al Cooper 
> +L:   linux-usb@vger.kernel.org
> +L:   bcm-kernel-feedback-l...@broadcom.com
> +S:   Supported
> +F:   drivers/phy/phy-brcm-usb*
> +
>  BROADCOM SYSTEMPORT ETHERNET DRIVER
>  M:   Florian Fainelli 
>  L:   net...@vger.kernel.org
> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> index 19bff3a..5ff5e47 100644
> --- a/drivers/phy/Kconfig
> +++ b/drivers/phy/Kconfig
> @@ -443,6 +443,16 @@ config PHY_CYGNUS_PCIE
> Enable this to support the Broadcom Cygnus PCIe PHY.
> If unsure, say N.
>  
> +config BRCM_USB_PHY
> + tristate "Broadcom USB PHY driver"
> + depends on OF && USB && ARCH_BRCMSTB

Please also include COMPILE_TEST
> + select GENERIC_PHY
> + default y
> + help
> +   Enable this to support the Broadcom USB PHY on
> +   Broadcom STB SoCs.
> +   If unsure, say Y.

Generally it is N.
> +
>  source "drivers/phy/tegra/Kconfig"
>  
>  config PHY_NS2_PCIE
> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
> index 90ae198..f4ff6c7 100644
> --- a/drivers/phy/Makefile
> +++ b/drivers/phy/Makefile
> @@ -10,6 +10,8 @@ obj-$(CONFIG_PHY_DA8XX_USB) += phy-da8xx-usb.o
>  obj-$(CONFIG_PHY_DM816X_USB) += phy-dm816x-usb.o
>  obj-$(CONFIG_ARMADA375_USBCLUSTER_PHY)   += phy-armada375-usb2.o
>  obj-$(CONFIG_BCM_KONA_USB2_PHY)  += phy-bcm-kona-usb2.o
> +obj-$(CONFIG_BRCM_USB_PHY)   += phy-brcm-usb.o
> +obj-$(CONFIG_BRCM_USB_PHY)   += phy-brcm-usb-init.o
>  obj-$(CONFIG_PHY_EXYNOS_DP_VIDEO)+= phy-exynos-dp-video.o
>  obj-$(CONFIG_PHY_EXYNOS_MIPI_VIDEO)  += phy-exynos-mipi-video.o
>  obj-$(CONFIG_PHY_LPC18XX_USB_OTG)+= 

Re: [PATCH 2/4] phy: rockchip-usb: use rockchip_usb_phy_reset to reset phy during wakeup

[Kishon Vijay Abraham I]

Hi,

On Monday 22 August 2016 06:30 PM, Heiko Stübner wrote:
> Am Montag, 22. August 2016, 17:17:41 schrieb Kishon Vijay Abraham I:
>> Hi,
>>
>> On Sunday 21 August 2016 02:02 AM, Randy Li wrote:
>>> It is a hardware bug in RK3288, the only way to solve it is to
>>> reset the phy.
>>>
>>> Signed-off-by: Randy Li <ay...@soulik.info>
>>> ---
>>>
>>>  drivers/phy/phy-rockchip-usb.c | 20 
>>>  1 file changed, 20 insertions(+)
>>>
>>> diff --git a/drivers/phy/phy-rockchip-usb.c
>>> b/drivers/phy/phy-rockchip-usb.c index 2a7381f..734987f 100644
>>> --- a/drivers/phy/phy-rockchip-usb.c
>>> +++ b/drivers/phy/phy-rockchip-usb.c
>>> @@ -29,6 +29,7 @@
>>>
>>>  #include 
>>>  #include 
>>>  #include 
>>>
>>> +#include 
>>>
>>>  static int enable_usb_uart;
>>>
>>> @@ -64,6 +65,7 @@ struct rockchip_usb_phy {
>>>
>>> struct clk_hw   clk480m_hw;
>>> struct phy  *phy;
>>> booluart_enabled;
>>>
>>> +   struct reset_control *reset;
>>>
>>>  };
>>>  
>>>  static int rockchip_usb_phy_power(struct rockchip_usb_phy *phy,
>>>
>>> @@ -144,9 +146,23 @@ static int rockchip_usb_phy_power_on(struct phy
>>> *_phy)
>>>
>>> return clk_prepare_enable(phy->clk480m);
>>>  
>>>  }
>>>
>>> +static int rockchip_usb_phy_reset(struct phy *_phy)
>>> +{
>>> +   struct rockchip_usb_phy *phy = phy_get_drvdata(_phy);
>>> +
>>> +   if (phy->reset) {
>>> +   reset_control_assert(phy->reset);
>>> +   udelay(10);
>>> +   reset_control_deassert(phy->reset);
>>> +   }
>>> +
>>> +   return 0;
>>> +}
>>> +
>>>
>>>  static const struct phy_ops ops = {
>>>  
>>> .power_on   = rockchip_usb_phy_power_on,
>>> .power_off  = rockchip_usb_phy_power_off,
>>>
>>> +   .reset  = rockchip_usb_phy_reset,
>>
>> why not just reuse the .init ops? reset can be done during initialization
>> right?
> 
> The naming of power_on + power_off and init + exit probably suggests that 
> they 
> are supposed to be used in pairs. (aka module_init + module_exit and probably 
> more)
> 
> But in fact I've seen different combinations so far (phy_init + phy_power_on 
> ... phy_power_off + phy_exit but also phy_power_on + phy_init ... phy_exit + 
> phy_power_off), so I guess the semantics are not that strictly defined.

yeah, it got difficult to maintain the semantics once the number of phy users
increased. Thought it was better than bloating the framework with platform
specific callbacks.

Thanks
Kishon
--
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/4] phy: rockchip-usb: use rockchip_usb_phy_reset to reset phy during wakeup

[Kishon Vijay Abraham I]

Hi,

On Sunday 21 August 2016 02:02 AM, Randy Li wrote:
> It is a hardware bug in RK3288, the only way to solve it is to
> reset the phy.
> 
> Signed-off-by: Randy Li 
> ---
>  drivers/phy/phy-rockchip-usb.c | 20 
>  1 file changed, 20 insertions(+)
> 
> diff --git a/drivers/phy/phy-rockchip-usb.c b/drivers/phy/phy-rockchip-usb.c
> index 2a7381f..734987f 100644
> --- a/drivers/phy/phy-rockchip-usb.c
> +++ b/drivers/phy/phy-rockchip-usb.c
> @@ -29,6 +29,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  static int enable_usb_uart;
>  
> @@ -64,6 +65,7 @@ struct rockchip_usb_phy {
>   struct clk_hw   clk480m_hw;
>   struct phy  *phy;
>   booluart_enabled;
> + struct reset_control *reset;
>  };
>  
>  static int rockchip_usb_phy_power(struct rockchip_usb_phy *phy,
> @@ -144,9 +146,23 @@ static int rockchip_usb_phy_power_on(struct phy *_phy)
>   return clk_prepare_enable(phy->clk480m);
>  }
>  
> +static int rockchip_usb_phy_reset(struct phy *_phy)
> +{
> + struct rockchip_usb_phy *phy = phy_get_drvdata(_phy);
> +
> + if (phy->reset) {
> + reset_control_assert(phy->reset);
> + udelay(10);
> + reset_control_deassert(phy->reset);
> + }
> +
> + return 0;
> +}
> +
>  static const struct phy_ops ops = {
>   .power_on   = rockchip_usb_phy_power_on,
>   .power_off  = rockchip_usb_phy_power_off,
> + .reset  = rockchip_usb_phy_reset,

why not just reuse the .init ops? reset can be done during initialization right?

Thanks
Kishon
--
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: chipidea: support generic phy in PM code path

[Kishon Vijay Abraham I]

Hi,

On Monday 22 August 2016 01:44 PM, Jisheng Zhang wrote:
> + Kishon
> 
> Hi Peter, Kishon,
> 
> On Mon, 22 Aug 2016 15:29:07 +0800 Peter Chen wrote:
> 
>> On Mon, Aug 22, 2016 at 02:39:21PM +0800, Jisheng Zhang wrote:
>>> Hi Peter,
>>>
>>> On Mon, 22 Aug 2016 13:33:08 +0800 Peter Chen wrote:
>>>   
 On Fri, Aug 19, 2016 at 08:10:13PM +0800, Jisheng Zhang wrote:  
> Support generic phy in PM code path: call phy_power_off/phy_power_on
> in ci_controller_suspend/ci_controller_resume.
>
> Signed-off-by: Jisheng Zhang 
> ---
>  drivers/usb/chipidea/core.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
> index ae12595..ef9fb0b 100644
> --- a/drivers/usb/chipidea/core.c
> +++ b/drivers/usb/chipidea/core.c
> @@ -1116,6 +1116,7 @@ static void ci_controller_suspend(struct ci_hdrc 
> *ci)
>   usleep_range(ci->platdata->phy_clkgate_delay_us,
>ci->platdata->phy_clkgate_delay_us + 50);
>   usb_phy_set_suspend(ci->usb_phy, 1);
> + phy_power_off(ci->phy);

 How could you support USB wakeup after PHY is powered off?  
>>>
>>> Per my understanding, the PHY's power off just power off data communication 
>>> part
>>> but leaves the circuits involved in wakeup detection active.
>>>   
>>
>> Ok, I hope so.
> 
> If most parts of the phy can be powered off during runtime suspend to save
> power, or phy HW support suspend mode, with usb phy, usb_phy_set_suspend() 
> could
> be used, but with the generic phy, it seems there's no corresponding API for
> this purpose. I'm not sure whether using phy_power_off() is correct here. Is 
> it
> acceptable to extend the generic phy? such as, phy_suspend()/phy_resume()?

phy_pm_runtime_put() could be used right?

Thanks
Kishon
--
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/7] phy-sun4i-usb: Add support for phy_set_mode

[Kishon Vijay Abraham I]

Hi,

On Thursday 18 August 2016 03:47 PM, Felipe Balbi wrote:
> 
> Hi,
> 
> Hans de Goede  writes:
> 
> [...]
> 
>>  void sun4i_usb_phy_set_squelch_detect(struct phy *_phy, bool enabled)
>>  {
>>  struct sun4i_usb_phy *phy = phy_get_drvdata(_phy);
> [...]
>
> $ scripts/checkpatch.pl 
> ~/patches/phy-sun4i-usb-Add-support-for-phy_set_mode.patch
> ERROR: trailing statements should be on next line
> #29: FILE: drivers/phy/phy-sun4i-usb.c:439:
> +case PHY_MODE_USB_HOST:   data->dr_mode = USB_DR_MODE_HOST; break;
>
> ERROR: trailing statements should be on next line
> #30: FILE: drivers/phy/phy-sun4i-usb.c:440:
> +case PHY_MODE_USB_DEVICE: data->dr_mode = USB_DR_MODE_PERIPHERAL; 
> break;
>
> ERROR: trailing statements should be on next line
> #31: FILE: drivers/phy/phy-sun4i-usb.c:441:
> +case PHY_MODE_USB_OTG:data->dr_mode = USB_DR_MODE_OTG; break;

 This is normal codeing style for a switch-case assigning a single value 
 per case,
 but checkpatch does not know this.
>>>
>>> I don't see that in CodingStyle
>>
>> It is an exception to the rule as such it is not listed, but this
>> really is quite a normal thing to do in C code.
>>
>>> and it's quite ugly.
>>
>> So this is ugly:
>>
>>  switch (mode) {
>>  case PHY_MODE_USB_HOST:   data->dr_mode = USB_DR_MODE_HOST; break;
>>  case PHY_MODE_USB_DEVICE: data->dr_mode = USB_DR_MODE_PERIPHERAL; break;
>>  case PHY_MODE_USB_OTG:data->dr_mode = USB_DR_MODE_OTG; break;
>>  default:
>>  return -EINVAL;
>>  }
>>
>> Where as this is not:
>>
>>  switch (mode) {
>>  case PHY_MODE_USB_HOST:
>>  data->dr_mode = USB_DR_MODE_HOST;
>>  break;
>>  case PHY_MODE_USB_DEVICE:
>>  data->dr_mode = USB_DR_MODE_PERIPHERAL;
>>  break;
>>  case PHY_MODE_USB_OTG:
>>  data->dr_mode = USB_DR_MODE_OTG;
>>  break;
>>  default:
>>  return -EINVAL;
>>  }
>>
>> ???
>>
>> IMHO the original version is much easier to read / makes it much
>> clearer what the code is doing.
>>
>> But if you insist I can do a v3 changing the coding style to
>> the (IMHO) uglier version.
>>
>> Also note that the real ugliness is that we've 3 different enums
>> for host / device / dual-role. For some reason the musb code has
>> 2 all of its own and then there is "enum phy_mode".
>>
>> Anyways let me know if you want a v3 with check-patch warnings
>> fixed.
> 
> I see it's somewhat common even in drivers/usb:
> 
> $ git grep -ce "case \w+:.*break;" -- drivers/usb/ 
> drivers/usb/gadget/udc/net2272.c:4
> drivers/usb/host/ehci-hcd.c:3
> drivers/usb/host/isp116x.h:2
> drivers/usb/host/ohci-dbg.c:14
> drivers/usb/host/sl811-hcd.c:7
> drivers/usb/host/uhci-debug.c:8
> drivers/usb/image/microtek.c:64
> drivers/usb/mon/mon_text.c:6
> drivers/usb/musb/musb_gadget.c:2
> drivers/usb/serial/digi_acceleport.c:23
> drivers/usb/serial/ftdi_sio.c:10
> drivers/usb/serial/mct_u232.c:10
> drivers/usb/serial/spcp8x5.c:17
> drivers/usb/serial/whiteheat.c:4
> drivers/usb/storage/debug.c:86
> 
> so I'm okay either way. Kishon has the final say here since he's
> drivers/phy/ maintainer.

hmm.. I'd prefer without checkpatch errors or warnings.

Thanks
Kishon
--
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 0/5] da8xx USB PHY platform devices and clocks (was "da8xx UBS clocks")

[Kishon Vijay Abraham I]

Hi Kevin,

On Saturday 13 August 2016 02:54 AM, Kevin Hilman wrote:
> On Wed, May 25, 2016 at 6:18 AM, Sekhar Nori  wrote:
>> On Monday 23 May 2016 08:44 PM, David Lechner wrote:
>>> On 05/09/2016 06:46 PM, David Lechner wrote:
 v5 changes: renamed "usbphy" to "usb_phy" or "usb-phy" as appropriate

> 
> [...]
> 
>>>
>>> What should I be doing to keep this moving along?
>>
>> We need the related driver changes to be applied first. I could then use
>> an immutable branch to push the platform changes against.
>>
>> I did take a look at the patches and they look good to me. Except the
>> one comment from Sergei which I just now indicated that I agree with.
> 
> Just checking on the status of this.  I'm not seeing the driver
> changes in mainline yet.
> 
> Any update?

phy driver is already merged which actually introduced a compilation error. The
fix for it is currently queued in linux-phy -fixes and it should be merged in
this -rc cycle.
I think it would be better if David Lechner re-spins the series re-based on top
of latest mainline kernel and then merged by Bin/Alan.

Thanks
Kishon
--
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 v9 2/4] phy: rockchip-inno-usb2: add a new driver for Rockchip usb2phy

[Kishon Vijay Abraham I]

Hi,

On Friday 22 July 2016 12:30 PM, Frank Wang wrote:
> The newer SoCs (rk3366, rk3399) take a different usb-phy IP block
> than rk3288 and before, and most of phy-related registers are also
> different from the past, so a new phy driver is required necessarily.
> 
> Signed-off-by: Frank Wang 
> Suggested-by: Heiko Stuebner 
> Suggested-by: Guenter Roeck 
> Suggested-by: Doug Anderson 
> Reviewed-by: Heiko Stuebner 
> Reviewed-by: Guenter Roeck 
> ---
> 
> Changes in v9:
>  - Add "Reviewed-by" info.
> 
> Changes in v8:
>  - Added support for rk3399 SoC.
>  - Prepare input clock of phy at probe time.
>  - Improved sm_work function to handle phy-port state more clearly.
> 
> Changes in v7:
>  - renamed functions *usb2phy_resume/*usb2phy_suspend to 
> *usb2phy_power_on/usb2phy_power_off.
> 
> Changes in v6:
>  - Fixed the output clock would be disabled more than once while phy-port was 
> going to suspend.
>  - Improved the driver to avoid the currently empty otg-port would cause 
> null-pointer dereferences.
> 
> Changes in v5:
>  - Added 'reg' in the data block to match the different phy-blocks in dt.
> 
> Changes in v4:
>  - Removed some processes related to 'vbus_host-supply'.
> 
> Changes in v3:
>  - Resolved the mapping defect between fixed value in driver and the property
>in devicetree.
>  - Optimized 480m output clock register function.
>  - Code cleanup.
> 
> Changes in v2:
>  - Changed vbus_host operation from gpio to regulator in *_probe.
>  - Improved the fault treatment relate to 480m clock register.
>  - Cleaned up some meaningless codes in *_clk480m_disable.
>  - made more clear the comment of *_sm_work.
> 
>  drivers/phy/Kconfig  |7 +
>  drivers/phy/Makefile |1 +
>  drivers/phy/phy-rockchip-inno-usb2.c |  707 
> ++
>  3 files changed, 715 insertions(+)
>  create mode 100644 drivers/phy/phy-rockchip-inno-usb2.c
> 
> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> index b869b98..29ef15c 100644
> --- a/drivers/phy/Kconfig
> +++ b/drivers/phy/Kconfig
> @@ -347,6 +347,13 @@ config PHY_ROCKCHIP_USB
>   help
> Enable this to support the Rockchip USB 2.0 PHY.
>  
> +config PHY_ROCKCHIP_INNO_USB2
> + tristate "Rockchip INNO USB2PHY Driver"
> + depends on ARCH_ROCKCHIP && OF

changed this to
depends on (ARCH_ROCKCHIP || COMPILE_TEST) && OF
and merged it.

Thanks
Kishon

> + select GENERIC_PHY
> + help
> +   Support for Rockchip USB2.0 PHY with Innosilicon IP block.
> +
>  config PHY_ROCKCHIP_EMMC
>   tristate "Rockchip EMMC PHY Driver"
>   depends on ARCH_ROCKCHIP && OF
> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
> index 9c3e73c..4963fbc 100644
> --- a/drivers/phy/Makefile
> +++ b/drivers/phy/Makefile
> @@ -38,6 +38,7 @@ phy-exynos-usb2-$(CONFIG_PHY_S5PV210_USB2)  += 
> phy-s5pv210-usb2.o
>  obj-$(CONFIG_PHY_EXYNOS5_USBDRD) += phy-exynos5-usbdrd.o
>  obj-$(CONFIG_PHY_QCOM_APQ8064_SATA)  += phy-qcom-apq8064-sata.o
>  obj-$(CONFIG_PHY_ROCKCHIP_USB) += phy-rockchip-usb.o
> +obj-$(CONFIG_PHY_ROCKCHIP_INNO_USB2) += phy-rockchip-inno-usb2.o
>  obj-$(CONFIG_PHY_ROCKCHIP_EMMC) += phy-rockchip-emmc.o
>  obj-$(CONFIG_PHY_ROCKCHIP_DP)+= phy-rockchip-dp.o
>  obj-$(CONFIG_PHY_QCOM_IPQ806X_SATA)  += phy-qcom-ipq806x-sata.o
> diff --git a/drivers/phy/phy-rockchip-inno-usb2.c 
> b/drivers/phy/phy-rockchip-inno-usb2.c
> new file mode 100644
> index 000..ac20310
> --- /dev/null
> +++ b/drivers/phy/phy-rockchip-inno-usb2.c
> @@ -0,0 +1,707 @@
> +/*
> + * Rockchip USB2.0 PHY with Innosilicon IP block driver
> + *
> + * Copyright (C) 2016 Fuzhou Rockchip Electronics Co., Ltd
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define BIT_WRITEABLE_SHIFT  16
> +#define SCHEDULE_DELAY   (60 * HZ)
> +
> +enum rockchip_usb2phy_port_id {
> + USB2PHY_PORT_OTG,
> + USB2PHY_PORT_HOST,
> + USB2PHY_NUM_PORTS,
> +};
> +
> +enum rockchip_usb2phy_host_state {
> + PHY_STATE_HS_ONLINE = 0,
> + PHY_STATE_DISCONNECT= 1,
> + PHY_STATE_CONNECT   = 2,
> + PHY_STATE_FS_LS_ONLINE  = 4,
> +};
> +

Re: [PATCH RESEND v2 1/3] dt: bindings: add bindings for Allwinner A64 usb phy

[Kishon Vijay Abraham I]

On Friday 12 August 2016 08:36 AM, Icenowy Zheng wrote:
> Signed-off-by: Icenowy Zheng 

Added "Update sun4i usb phy dt binding documentation to include support for
Allwinner A64 usb phy." and then merged this.

Thanks
Kishon

> ---
>  Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt 
> b/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
> index 95736d7..287150d 100644
> --- a/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
> +++ b/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
> @@ -10,6 +10,7 @@ Required properties:
>* allwinner,sun8i-a23-usb-phy
>* allwinner,sun8i-a33-usb-phy
>* allwinner,sun8i-h3-usb-phy
> +  * allwinner,sun50i-a64-usb-phy
>  - reg : a list of offset + length pairs
>  - reg-names :
>* "phy_ctrl"
> 
--
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 v2 2/3] phy: sun4i: add support for A64 usb phy

[Kishon Vijay Abraham I]

On Friday 12 August 2016 08:36 AM, Icenowy Zheng wrote:
> There's something unknown in the pmu part that shared with H3.
> It's renamed as PMU_UNK1 from PMU_UNK_H3.
> 
> Signed-off-by: Icenowy Zheng 

Fixed the following checkpatch warning and merged this to linux-phy tree.

WARNING: line over 80 characters
#311: FILE: drivers/phy/phy-sun4i-usb.c:794:
+   { .compatible = "allwinner,sun50i-a64-usb-phy", .data = 
_a64_cfg},

Thanks
Kishon

> ---
>  drivers/phy/phy-sun4i-usb.c | 34 --
>  1 file changed, 28 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/phy/phy-sun4i-usb.c b/drivers/phy/phy-sun4i-usb.c
> index 0a45bc6..a4db658 100644
> --- a/drivers/phy/phy-sun4i-usb.c
> +++ b/drivers/phy/phy-sun4i-usb.c
> @@ -49,7 +49,7 @@
>  #define REG_PHYCTL_A33   0x10
>  #define REG_PHY_UNK_H3   0x20
>  
> -#define REG_PMU_UNK_H3   0x10
> +#define REG_PMU_UNK1 0x10
>  
>  #define PHYCTL_DATA  BIT(7)
>  
> @@ -97,6 +97,7 @@ enum sun4i_usb_phy_type {
>   sun6i_a31_phy,
>   sun8i_a33_phy,
>   sun8i_h3_phy,
> + sun50i_a64_phy,
>  };
>  
>  struct sun4i_usb_phy_cfg {
> @@ -105,6 +106,7 @@ struct sun4i_usb_phy_cfg {
>   u32 disc_thresh;
>   u8 phyctl_offset;
>   bool dedicated_clocks;
> + bool enable_pmu_unk1;
>  };
>  
>  struct sun4i_usb_phy_data {
> @@ -180,8 +182,9 @@ static void sun4i_usb_phy_write(struct sun4i_usb_phy 
> *phy, u32 addr, u32 data,
>  
>   mutex_lock(_data->mutex);
>  
> - if (phy_data->cfg->type == sun8i_a33_phy) {
> - /* A33 needs us to set phyctl to 0 explicitly */
> + if (phy_data->cfg->type == sun8i_a33_phy ||
> + phy_data->cfg->type == sun50i_a64_phy) {
> + /* A33 or A64 needs us to set phyctl to 0 explicitly */
>   writel(0, phyctl);
>   }
>  
> @@ -255,14 +258,16 @@ static int sun4i_usb_phy_init(struct phy *_phy)
>   return ret;
>   }
>  
> + if (data->cfg->enable_pmu_unk1) {
> + val = readl(phy->pmu + REG_PMU_UNK1);
> + writel(val & ~2, phy->pmu + REG_PMU_UNK1);
> + }
> +
>   if (data->cfg->type == sun8i_h3_phy) {
>   if (phy->index == 0) {
>   val = readl(data->base + REG_PHY_UNK_H3);
>   writel(val & ~1, data->base + REG_PHY_UNK_H3);
>   }
> -
> - val = readl(phy->pmu + REG_PMU_UNK_H3);
> - writel(val & ~2, phy->pmu + REG_PMU_UNK_H3);
>   } else {
>   /* Enable USB 45 Ohm resistor calibration */
>   if (phy->index == 0)
> @@ -713,6 +718,7 @@ static const struct sun4i_usb_phy_cfg sun4i_a10_cfg = {
>   .disc_thresh = 3,
>   .phyctl_offset = REG_PHYCTL_A10,
>   .dedicated_clocks = false,
> + .enable_pmu_unk1 = false,
>  };
>  
>  static const struct sun4i_usb_phy_cfg sun5i_a13_cfg = {
> @@ -721,6 +727,7 @@ static const struct sun4i_usb_phy_cfg sun5i_a13_cfg = {
>   .disc_thresh = 2,
>   .phyctl_offset = REG_PHYCTL_A10,
>   .dedicated_clocks = false,
> + .enable_pmu_unk1 = false,
>  };
>  
>  static const struct sun4i_usb_phy_cfg sun6i_a31_cfg = {
> @@ -729,6 +736,7 @@ static const struct sun4i_usb_phy_cfg sun6i_a31_cfg = {
>   .disc_thresh = 3,
>   .phyctl_offset = REG_PHYCTL_A10,
>   .dedicated_clocks = true,
> + .enable_pmu_unk1 = false,
>  };
>  
>  static const struct sun4i_usb_phy_cfg sun7i_a20_cfg = {
> @@ -737,6 +745,7 @@ static const struct sun4i_usb_phy_cfg sun7i_a20_cfg = {
>   .disc_thresh = 2,
>   .phyctl_offset = REG_PHYCTL_A10,
>   .dedicated_clocks = false,
> + .enable_pmu_unk1 = false,
>  };
>  
>  static const struct sun4i_usb_phy_cfg sun8i_a23_cfg = {
> @@ -745,6 +754,7 @@ static const struct sun4i_usb_phy_cfg sun8i_a23_cfg = {
>   .disc_thresh = 3,
>   .phyctl_offset = REG_PHYCTL_A10,
>   .dedicated_clocks = true,
> + .enable_pmu_unk1 = false,
>  };
>  
>  static const struct sun4i_usb_phy_cfg sun8i_a33_cfg = {
> @@ -753,6 +763,7 @@ static const struct sun4i_usb_phy_cfg sun8i_a33_cfg = {
>   .disc_thresh = 3,
>   .phyctl_offset = REG_PHYCTL_A33,
>   .dedicated_clocks = true,
> + .enable_pmu_unk1 = false,
>  };
>  
>  static const struct sun4i_usb_phy_cfg sun8i_h3_cfg = {
> @@ -760,6 +771,16 @@ static const struct sun4i_usb_phy_cfg sun8i_h3_cfg = {
>   .type = sun8i_h3_phy,
>   .disc_thresh = 3,
>   .dedicated_clocks = true,
> + .enable_pmu_unk1 = true,
> +};
> +
> +static const struct sun4i_usb_phy_cfg sun50i_a64_cfg = {
> + .num_phys = 2,
> + .type = sun50i_a64_phy,
> + .disc_thresh = 3,
> + .phyctl_offset = REG_PHYCTL_A33,
> + .dedicated_clocks = true,
> + .enable_pmu_unk1 = true,
>  };
>  
>  static const struct of_device_id sun4i_usb_phy_of_match[] = {
> @@ -770,6 +791,7 @@ static const struct of_device_id sun4i_usb_phy_of_match[] 
> 

Re: [PATCH V4] phy: bcm-ns-usb3: new driver for USB 3.0 PHY on Northstar

[Kishon Vijay Abraham I]

Hi,

On Friday 12 August 2016 03:58 AM, Rafał Miłecki wrote:
> From: Rafał Miłecki 
> 
> Northstar is a family of SoCs used in home routers. They have USB 2.0
> and 3.0 controllers with PHYs that need to be properly initialized.
> This driver provides PHY init support in a generic way and can be bound
> with XHCI controller driver.
> 
> There aren't any public datasheets from Broadcom so we can't have nice
> defines for all used bits. It means we just follow Broadcom's
> initialization procedure using their magic values. We were quite lucky
> actually that Broadcom put some comments in their SDK reference code
> explaining what given writes are responsible for.
> 
> Signed-off-by: Rafał Miłecki 
> ---
> V2: Redesign the driver to don't depend on bcma. This will allow reusing it on
> Northstar+ which doesn't use bcma. This requires providing two different
> registers ranges in DT which was documented in bindings info.
> V3: Use readl and writel
> Fix MODULE_LICENSE to match header (v2)
> Mention C0 series in Documentation
> RESEND: I can see that my PHY driver for USB 2.0:
>   [PATCH V4] phy: bcm-ns-usb2: new driver for USB 2.0 PHY on Northstar
>   sent on 14 Apr 2016 was accepted, however:
>   [PATCH V3] phy: bcm-ns-usb3: new driver for USB 3.0 PHY on Northstar
>   sent the very same day wasn't.
>   I'm sending a simply rebased version hoping it can be accepted or
>   commented somehow (e.g. what needs to be changed).
> V4: Comment on magic values in commit message
> Add Copyright for Broadcom and their magic values
> Some in-code trivial comments on enabling MDIO
> Use some existing defines
> Drop setting .owner
> Rebased on top of updated "next" branch
> ---
>  .../devicetree/bindings/phy/bcm-ns-usb3-phy.txt|  23 ++
>  drivers/phy/Kconfig|   9 +
>  drivers/phy/Makefile   |   1 +
>  drivers/phy/phy-bcm-ns-usb3.c  | 273 
> +
>  4 files changed, 306 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/phy/bcm-ns-usb3-phy.txt
>  create mode 100644 drivers/phy/phy-bcm-ns-usb3.c
> 
> diff --git a/Documentation/devicetree/bindings/phy/bcm-ns-usb3-phy.txt 
> b/Documentation/devicetree/bindings/phy/bcm-ns-usb3-phy.txt
> new file mode 100644
> index 000..09aeba9
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/bcm-ns-usb3-phy.txt
> @@ -0,0 +1,23 @@
> +Driver for Broadcom Northstar USB 3.0 PHY
> +
> +Required properties:
> +
> +- compatible: one of: "brcm,ns-ax-usb3-phy", "brcm,ns-bx-usb3-phy".
> +- reg: register mappings for DMP (Device Management Plugin) and ChipCommon B
> +   MMI.
> +- reg-names: "dmp" and "ccb-mii"
> +
> +Initialization of USB 3.0 PHY depends on Northstar version. There are 
> currently
> +three known series: Ax, Bx and Cx.
> +Known A0: BCM4707 rev 0
> +Known B0: BCM4707 rev 4, BCM53573 rev 2
> +Known B1: BCM4707 rev 6
> +Known C0: BCM47094 rev 0
> +
> +Example:
> + usb3-phy {
> + compatible = "brcm,ns-ax-usb3-phy";
> + reg = <0x18105000 0x1000>, <0x18003000 0x1000>;
> + reg-names = "dmp", "ccb-mii";
> + #phy-cells = <0>;
> + };
> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> index 19bff3a..afbdd6a 100644
> --- a/drivers/phy/Kconfig
> +++ b/drivers/phy/Kconfig
> @@ -24,6 +24,15 @@ config PHY_BCM_NS_USB2
> Enable this to support Broadcom USB 2.0 PHY connected to the USB
> controller on Northstar family.
>  
> +config PHY_BCM_NS_USB3
> + tristate "Broadcom Northstar USB 3.0 PHY Driver"
> + depends on ARCH_BCM_IPROC || COMPILE_TEST
> + depends on HAS_IOMEM && OF
> + select GENERIC_PHY
> + help
> +   Enable this to support Broadcom USB 3.0 PHY connected to the USB
> +   controller on Northstar family.
> +
>  config PHY_BERLIN_USB
>   tristate "Marvell Berlin USB PHY Driver"
>   depends on ARCH_BERLIN && RESET_CONTROLLER && HAS_IOMEM && OF
> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
> index 90ae198..b99370a 100644
> --- a/drivers/phy/Makefile
> +++ b/drivers/phy/Makefile
> @@ -4,6 +4,7 @@
>  
>  obj-$(CONFIG_GENERIC_PHY)+= phy-core.o
>  obj-$(CONFIG_PHY_BCM_NS_USB2)+= phy-bcm-ns-usb2.o
> +obj-$(CONFIG_PHY_BCM_NS_USB3)+= phy-bcm-ns-usb3.o
>  obj-$(CONFIG_PHY_BERLIN_USB) += phy-berlin-usb.o
>  obj-$(CONFIG_PHY_BERLIN_SATA)+= phy-berlin-sata.o
>  obj-$(CONFIG_PHY_DA8XX_USB)  += phy-da8xx-usb.o
> diff --git a/drivers/phy/phy-bcm-ns-usb3.c b/drivers/phy/phy-bcm-ns-usb3.c
> new file mode 100644
> index 000..c9326c5
> --- /dev/null
> +++ b/drivers/phy/phy-bcm-ns-usb3.c
> @@ -0,0 +1,273 @@
> +/*
> + * Broadcom Northstar USB 3.0 PHY Driver
> + *
> + * Copyright (C) 2016 Rafał Miłecki 
> + *
> + * All magic values used for initialization (and 

Re: [PATCH resend 0/1] phy-sun4i-usb: Add support for peripheral-only mode

[Kishon Vijay Abraham I]

On Tuesday 09 August 2016 01:25 AM, Hans de Goede wrote:
> Hi Kishon,
> 
> As discussed before, here is a resend now that rc1 is out (and includes
> the new of_usb_get_dr_mode_by_phy helper this patch needs).
> 
> Please merge this for 4.9-rcX some of the musb-sunxi glue changes
> already merged have a runtime dependency on this patch, without
> this patch boards using the musb controller in host-only mode
> will break.

merged, thanks.

-Kishon
> 
> Thanks & Regards,
> 
> Hans
> 
> 
--
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/7] mfd: da8xx-cfgchip: New header file for CFGCHIP registers.

[Kishon Vijay Abraham I]

Hi,

On Tuesday 10 May 2016 05:09 AM, David Lechner wrote:
> We will be using a generic syscon device for the TI DA8XX SoC CFGCHIPx
> retisters. This will be used by a number of planned drivers including a
> new USB PHY driver and common clock framework drivers.
> 
> The same defines are removed from the platform_data header file since they
> are now redundant and they didn't really belong there anyway.
> 
> Signed-off-by: David Lechner 
> Acked-by: Lee Jones 
> ---
>  include/linux/mfd/da8xx-cfgchip.h | 153 
> ++
>  include/linux/platform_data/usb-davinci.h |  22 -

This patch as well is required for da8xx-usb phy since it uses da8xx-cfgchip.h.
But I can't merge this as is since this removes macros in da8xx-cfgchip
referenced in ohci-da8xx.c. So for now I'll split this patch and take only the
part that adds da8xx-cfgchip.h. The part that removes macros from usb-davinci.h
can go along with the USB patch series.

Thanks
Kishon

>  2 files changed, 153 insertions(+), 22 deletions(-)
>  create mode 100644 include/linux/mfd/da8xx-cfgchip.h
> 
> diff --git a/include/linux/mfd/da8xx-cfgchip.h 
> b/include/linux/mfd/da8xx-cfgchip.h
> new file mode 100644
> index 000..304985e
> --- /dev/null
> +++ b/include/linux/mfd/da8xx-cfgchip.h
> @@ -0,0 +1,153 @@
> +/*
> + * TI DaVinci DA8xx CHIPCFGx registers for syscon consumers.
> + *
> + * Copyright (C) 2016 David Lechner 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +#ifndef __LINUX_MFD_DA8XX_CFGCHIP_H
> +#define __LINUX_MFD_DA8XX_CFGCHIP_H
> +
> +#include 
> +
> +/* register offset (32-bit registers) */
> +#define CFGCHIP(n)   ((n) * 4)
> +
> +/* CFGCHIP0 (PLL0/EDMA3_0) register bits */
> +#define CFGCHIP0_PLL_MASTER_LOCK BIT(4)
> +#define CFGCHIP0_EDMA30TC1DBS(n) ((n) << 2)
> +#define CFGCHIP0_EDMA30TC1DBS_MASK   CFGCHIP0_EDMA30TC1DBS(0x3)
> +#define CFGCHIP0_EDMA30TC1DBS_16 CFGCHIP0_EDMA30TC1DBS(0x0)
> +#define CFGCHIP0_EDMA30TC1DBS_32 CFGCHIP0_EDMA30TC1DBS(0x1)
> +#define CFGCHIP0_EDMA30TC1DBS_64 CFGCHIP0_EDMA30TC1DBS(0x2)
> +#define CFGCHIP0_EDMA30TC0DBS(n) ((n) << 0)
> +#define CFGCHIP0_EDMA30TC0DBS_MASK   CFGCHIP0_EDMA30TC0DBS(0x3)
> +#define CFGCHIP0_EDMA30TC0DBS_16 CFGCHIP0_EDMA30TC0DBS(0x0)
> +#define CFGCHIP0_EDMA30TC0DBS_32 CFGCHIP0_EDMA30TC0DBS(0x1)
> +#define CFGCHIP0_EDMA30TC0DBS_64 CFGCHIP0_EDMA30TC0DBS(0x2)
> +
> +/* CFGCHIP1 (eCAP/HPI/EDMA3_1/eHRPWM TBCLK/McASP0 AMUTEIN) register bits */
> +#define CFGCHIP1_CAP2SRC(n)  ((n) << 27)
> +#define CFGCHIP1_CAP2SRC_MASKCFGCHIP1_CAP2SRC(0x1f)
> +#define CFGCHIP1_CAP2SRC_ECAP_PINCFGCHIP1_CAP2SRC(0x0)
> +#define CFGCHIP1_CAP2SRC_MCASP0_TX   CFGCHIP1_CAP2SRC(0x1)
> +#define CFGCHIP1_CAP2SRC_MCASP0_RX   CFGCHIP1_CAP2SRC(0x2)
> +#define CFGCHIP1_CAP2SRC_EMAC_C0_RX_THRESHOLDCFGCHIP1_CAP2SRC(0x7)
> +#define CFGCHIP1_CAP2SRC_EMAC_C0_RX  CFGCHIP1_CAP2SRC(0x8)
> +#define CFGCHIP1_CAP2SRC_EMAC_C0_TX  CFGCHIP1_CAP2SRC(0x9)
> +#define CFGCHIP1_CAP2SRC_EMAC_C0_MISCCFGCHIP1_CAP2SRC(0xa)
> +#define CFGCHIP1_CAP2SRC_EMAC_C1_RX_THRESHOLDCFGCHIP1_CAP2SRC(0xb)
> +#define CFGCHIP1_CAP2SRC_EMAC_C1_RX  CFGCHIP1_CAP2SRC(0xc)
> +#define CFGCHIP1_CAP2SRC_EMAC_C1_TX  CFGCHIP1_CAP2SRC(0xd)
> +#define CFGCHIP1_CAP2SRC_EMAC_C1_MISCCFGCHIP1_CAP2SRC(0xe)
> +#define CFGCHIP1_CAP2SRC_EMAC_C2_RX_THRESHOLDCFGCHIP1_CAP2SRC(0xf)
> +#define CFGCHIP1_CAP2SRC_EMAC_C2_RX  CFGCHIP1_CAP2SRC(0x10)
> +#define CFGCHIP1_CAP2SRC_EMAC_C2_TX  CFGCHIP1_CAP2SRC(0x11)
> +#define CFGCHIP1_CAP2SRC_EMAC_C2_MISCCFGCHIP1_CAP2SRC(0x12)
> +#define CFGCHIP1_CAP1SRC(n)  ((n) << 22)
> +#define CFGCHIP1_CAP1SRC_MASKCFGCHIP1_CAP1SRC(0x1f)
> +#define CFGCHIP1_CAP1SRC_ECAP_PINCFGCHIP1_CAP1SRC(0x0)
> +#define CFGCHIP1_CAP1SRC_MCASP0_TX   CFGCHIP1_CAP1SRC(0x1)
> +#define CFGCHIP1_CAP1SRC_MCASP0_RX   CFGCHIP1_CAP1SRC(0x2)
> +#define CFGCHIP1_CAP1SRC_EMAC_C0_RX_THRESHOLDCFGCHIP1_CAP1SRC(0x7)
> +#define CFGCHIP1_CAP1SRC_EMAC_C0_RX  CFGCHIP1_CAP1SRC(0x8)
> +#define CFGCHIP1_CAP1SRC_EMAC_C0_TX  CFGCHIP1_CAP1SRC(0x9)
> +#define CFGCHIP1_CAP1SRC_EMAC_C0_MISC 

Re: [PATCH v6 0/1] phy-sun4i-usb: Add support for peripheral-only mode

[Kishon Vijay Abraham I]

Hi,

On Tuesday 05 July 2016 02:47 AM, Hans de Goede wrote:
> Hi Kishon,
> 
> Thanks for merging one of the 2 pending phy-sun4i-usb patches, I see
> that the other one actually has a conflict after merging in
> linux-phy/fixes. So here is a rebased version of it.
> 
> Note can you please make sure this gets into 4.8? I've a musb patch
> ("usb: musb: sunxi: Simplify dr_mode handling") heading into 4.8,
> which depends on the changes in this patch to keep host-only mode
> working (runtime dependency) and we do use host-only mode on a few
> boards.

sure.. but I think this patch can go only in the -rc cycle because of
of_usb_get_dr_mode_by_phy() API taking 2 arguments.

Thanks
Kishon
--
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] phy-sun4i-usb: Add support for peripheral-only mode

[Kishon Vijay Abraham I]

Hi Hans,

On Tuesday 05 July 2016 02:47 AM, Hans de Goede wrote:
> Use the new of_usb_get_dr_mode_by_phy() function to get the dr_mode

This API in linux-phy -next still takes a single argument. This patch can go
probably in the next -rc cycle.

Thanks
Kishon

> from the musb controller node instead of assuming that having an id_det
> gpio means otg mode, and not having one means host mode.
> 
> Implement peripheral-only mode by adding a sun4i_usb_phy0_get_id_det
> helper which looks at the dr_mode, always registering our extcon and
> always monitoring vbus.
> 
> If dr_mode is not specified in the dts, do not register phy0 as we then
> do not know how to treat it. This is actually a good thing as this means
> we will not be registering phy0 on devices where the otg controller is
> not enabled in the devicetree.
> 
> Signed-off-by: Hans de Goede <hdego...@redhat.com>
> Acked-by: Kishon Vijay Abraham I <kis...@ti.com>
> ---
> Changes in v2:
> -Adjust for of_usb_get_dr_mode_by_phy now taking an args0 parameter
> Changes in v3:
> -Only toggle the phy vbus-det bit on id-change on systems without vbus-det
>  when in otg mode
> Changes in v4:
> -No changes
> Changes in v5:
> -Added Kishon's Acked-by
> Changes in v6:
> -Rebase on top of latest linux-phy/next
> ---
>  drivers/phy/phy-sun4i-usb.c | 68 
> ++---
>  1 file changed, 46 insertions(+), 22 deletions(-)
> 
> diff --git a/drivers/phy/phy-sun4i-usb.c b/drivers/phy/phy-sun4i-usb.c
> index 0a45bc6..8c7eb33 100644
> --- a/drivers/phy/phy-sun4i-usb.c
> +++ b/drivers/phy/phy-sun4i-usb.c
> @@ -40,6 +40,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  
>  #define REG_ISCR 0x00
> @@ -110,6 +111,7 @@ struct sun4i_usb_phy_cfg {
>  struct sun4i_usb_phy_data {
>   void __iomem *base;
>   const struct sun4i_usb_phy_cfg *cfg;
> + enum usb_dr_mode dr_mode;
>   struct mutex mutex;
>   struct sun4i_usb_phy {
>   struct phy *phy;
> @@ -120,6 +122,7 @@ struct sun4i_usb_phy_data {
>   bool regulator_on;
>   int index;
>   } phys[MAX_PHYS];
> + int first_phy;
>   /* phy0 / otg related variables */
>   struct extcon_dev *extcon;
>   bool phy0_init;
> @@ -285,16 +288,10 @@ static int sun4i_usb_phy_init(struct phy *_phy)
>   sun4i_usb_phy0_update_iscr(_phy, 0, ISCR_DPDM_PULLUP_EN);
>   sun4i_usb_phy0_update_iscr(_phy, 0, ISCR_ID_PULLUP_EN);
>  
> - if (data->id_det_gpio) {
> - /* OTG mode, force ISCR and cable state updates */
> - data->id_det = -1;
> - data->vbus_det = -1;
> - queue_delayed_work(system_wq, >detect, 0);
> - } else {
> - /* Host only mode */
> - sun4i_usb_phy0_set_id_detect(_phy, 0);
> - sun4i_usb_phy0_set_vbus_detect(_phy, 1);
> - }
> + /* Force ISCR and cable state updates */
> + data->id_det = -1;
> + data->vbus_det = -1;
> + queue_delayed_work(system_wq, >detect, 0);
>   }
>  
>   return 0;
> @@ -319,6 +316,19 @@ static int sun4i_usb_phy_exit(struct phy *_phy)
>   return 0;
>  }
>  
> +static int sun4i_usb_phy0_get_id_det(struct sun4i_usb_phy_data *data)
> +{
> + switch (data->dr_mode) {
> + case USB_DR_MODE_OTG:
> + return gpiod_get_value_cansleep(data->id_det_gpio);
> + case USB_DR_MODE_HOST:
> + return 0;
> + case USB_DR_MODE_PERIPHERAL:
> + default:
> + return 1;
> + }
> +}
> +
>  static int sun4i_usb_phy0_get_vbus_det(struct sun4i_usb_phy_data *data)
>  {
>   if (data->vbus_det_gpio)
> @@ -432,7 +442,10 @@ static void sun4i_usb_phy0_id_vbus_det_scan(struct 
> work_struct *work)
>   struct phy *phy0 = data->phys[0].phy;
>   int id_det, vbus_det, id_notify = 0, vbus_notify = 0;
>  
> - id_det = gpiod_get_value_cansleep(data->id_det_gpio);
> + if (phy0 == NULL)
> + return;
> +
> + id_det = sun4i_usb_phy0_get_id_det(data);
>   vbus_det = sun4i_usb_phy0_get_vbus_det(data);
>  
>   mutex_lock(>mutex);
> @@ -448,7 +461,8 @@ static void sun4i_usb_phy0_id_vbus_det_scan(struct 
> work_struct *work)
>* without vbus detection report vbus low for long enough for
>* the musb-ip to end the current device session.
>*/
> - if (!sun4i_usb_phy0_have_vbus_det(data) && id_det == 0) {
>

Re: [PATCH v5 3/7] phy: Add set_mode callback

[Kishon Vijay Abraham I]

Hi Bin,

On Monday 27 June 2016 06:17 PM, Kishon Vijay Abraham I wrote:
> Hi,
> 
> On Tuesday 10 May 2016 05:09 AM, David Lechner wrote:
>> The initial use for this is for PHYs that have a mode related to USB OTG.
>> There are several SoCs (e.g. TI OMAP and DA8xx) that have a mode setting
>> in the USB PHY to override OTG VBUS and ID signals.
>>
>> Of course, the enum can be expaned in the future to include modes for
>> other types of PHYs as well.
>>
>> Suggested-by: Kishon Vijay Abraham I <kis...@ti.com>
>> Signed-off-by: David Lechner <da...@lechnology.com>
> 
> I've created a immutable branch for this patch and it can be found here.
> git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy.git
> tags/phy-set-mode

There was a build error in the above tag with allyesconfig. So I have created a
new tag which includes the fix patch in addition to this patch.

new tag:
tags/phy-set-mode-v2

In the patches you sent to Greg [1], I didn't see this series included. However
if you are planning to send another pull request for the next merge window,
request you to use the new tag.

Thanks
Kishon

[1] -> http://www.spinics.net/lists/linux-usb/msg142788.html
> 
> I've merged this tag to my -next.
> 
> Thanks
> Kishon
> 
>> ---
>>  drivers/phy/phy-core.c  | 15 +++
>>  include/linux/phy/phy.h | 17 +
>>  2 files changed, 32 insertions(+)
>>
>> diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
>> index e7e574d..fe0344c 100644
>> --- a/drivers/phy/phy-core.c
>> +++ b/drivers/phy/phy-core.c
>> @@ -342,6 +342,21 @@ int phy_power_off(struct phy *phy)
>>  }
>>  EXPORT_SYMBOL_GPL(phy_power_off);
>>  
>> +int phy_set_mode(struct phy *phy, enum phy_mode mode)
>> +{
>> +int ret;
>> +
>> +if (!phy || !phy->ops->set_mode)
>> +return 0;
>> +
>> +mutex_lock(>mutex);
>> +ret = phy->ops->set_mode(phy, mode);
>> +mutex_unlock(>mutex);
>> +
>> +return ret;
>> +}
>> +EXPORT_SYMBOL_GPL(phy_set_mode);
>> +
>>  /**
>>   * _of_phy_get() - lookup and obtain a reference to a phy by phandle
>>   * @np: device_node for which to get the phy
>> diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
>> index 8cf05e3..4248ade 100644
>> --- a/include/linux/phy/phy.h
>> +++ b/include/linux/phy/phy.h
>> @@ -22,12 +22,20 @@
>>  
>>  struct phy;
>>  
>> +enum phy_mode {
>> +PHY_MODE_INVALID,
>> +PHY_MODE_USB_HOST,
>> +PHY_MODE_USB_DEVICE,
>> +PHY_MODE_USB_OTG,
>> +};
>> +
>>  /**
>>   * struct phy_ops - set of function pointers for performing phy operations
>>   * @init: operation to be performed for initializing phy
>>   * @exit: operation to be performed while exiting
>>   * @power_on: powering on the phy
>>   * @power_off: powering off the phy
>> + * @set_mode: set the mode of the phy
>>   * @owner: the module owner containing the ops
>>   */
>>  struct phy_ops {
>> @@ -35,6 +43,7 @@ struct phy_ops {
>>  int (*exit)(struct phy *phy);
>>  int (*power_on)(struct phy *phy);
>>  int (*power_off)(struct phy *phy);
>> +int (*set_mode)(struct phy *phy, enum phy_mode mode);
>>  struct module *owner;
>>  };
>>  
>> @@ -119,6 +128,7 @@ int phy_init(struct phy *phy);
>>  int phy_exit(struct phy *phy);
>>  int phy_power_on(struct phy *phy);
>>  int phy_power_off(struct phy *phy);
>> +int phy_set_mode(struct phy *phy, enum phy_mode mode);
>>  static inline int phy_get_bus_width(struct phy *phy)
>>  {
>>  return phy->attrs.bus_width;
>> @@ -224,6 +234,13 @@ static inline int phy_power_off(struct phy *phy)
>>  return -ENOSYS;
>>  }
>>  
>> +static inline int phy_set_mode(struct phy *phy, enum phy_mode mode)
>> +{
>> +if (!phy)
>> +return 0;
>> +return -ENOSYS;
>> +}
>> +
>>  static inline int phy_get_bus_width(struct phy *phy)
>>  {
>>  return -ENOSYS;
>>
--
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 resend 0/2] phy-sun4i-usb: peripheral-mode + a31 otg workaround

[Kishon Vijay Abraham I]

On Sunday 03 July 2016 01:38 AM, Hans de Goede wrote:
> Hi,
> 
> On 30-06-16 07:47, Kishon Vijay Abraham I wrote:
>> Hi,
>>
>> On Wednesday 29 June 2016 11:44 PM, Hans de Goede wrote:
>>> Hi Kishon,
>>>
>>> The "USB: Fix of_usb_get_dr_mode_by_phy with a shared phy block"
>>> patch on which this series depends is in usb-next now:
>>>
>>> https://git.kernel.org/cgit/linux/kernel/git/gregkh/usb.git/commit/?h=usb-next=ce15ed4c5dfb3f7757e6611902aed5db253af977
>>>
>>>
>>> Can you please merge this series?
>>
>> This is not applying cleanly against linux-phy -next. Can you rebase and 
>> send?
> 
> I just tried to rebase, the problem is that your -next branch does not
> contain the fixes from your -fixes branch, specifically it is missing
> this commit:
> 
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/phy?id=5cf700ac9d50353dc5b8194a57c6f40bf1fc4424
> 
> 
> Which is causing the conflict you're seeing when trying to merge
> the patches I send. I can send you fixed patches which apply
> cleanly to your linux-phy/next but those then will not merge
> properly with linus' tree.
> 
> So it is probably better to at least cherry-pick the commit
> I've linked to above into your -next, to avoid future merge
> problems. If you cherry-pick that commit then the patches
> I've send you should apply cleanly.

Ah okay.. I'll rebase my next onto my fixes. Thanks for letting me know this.

Thanks
Kishon
--
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 resend 0/2] phy-sun4i-usb: peripheral-mode + a31 otg workaround

[Kishon Vijay Abraham I]

Hi,

On Wednesday 29 June 2016 11:44 PM, Hans de Goede wrote:
> Hi Kishon,
> 
> The "USB: Fix of_usb_get_dr_mode_by_phy with a shared phy block"
> patch on which this series depends is in usb-next now:
> 
> https://git.kernel.org/cgit/linux/kernel/git/gregkh/usb.git/commit/?h=usb-next=ce15ed4c5dfb3f7757e6611902aed5db253af977
> 
> Can you please merge this series?

This is not applying cleanly against linux-phy -next. Can you rebase and send?

Thanks
Kishon
--
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 2/2] phy: rockchip-inno-usb2: add a new driver for Rockchip usb2phy

[Kishon Vijay Abraham I]

Hi,

On Friday 17 June 2016 10:16 PM, Heiko Stübner wrote:
> Hi Kishon,
> 
> Am Freitag, 17. Juni 2016, 17:24:46 schrieb Kishon Vijay Abraham I:
> 
>>> +   ret = of_clk_add_provider(node, of_clk_src_simple_get, rphy->clk480m);
>>> +   if (ret < 0)
>>> +   goto err_clk_provider;
>>> +
>>> +   ret = devm_add_action(rphy->dev, rockchip_usb2phy_clk480m_unregister,
>>> + rphy);
>>> +   if (ret < 0)
>>> +   goto err_unreg_action;
>>> +
>>> +   return 0;
>>> +
>>> +err_unreg_action:
>>> +   of_clk_del_provider(node);
>>> +err_clk_provider:
>>> +   clk_unregister(rphy->clk480m);
>>> +err_register:
>>> +   if (rphy->clk)
>>> +   clk_put(rphy->clk);
>>> +   return ret;
>>> +}
>>
>> I'm seeing lot of similarities specifically w.r.t to clock handling part in
>> drivers/phy/phy-rockchip-usb.c. Why not just re-use that driver?
> 
> It's a completely different phy block (Designware vs. Innosilicon) and a lot 
> of stuff also is handled differently.
> 
> For one on the old block, each phy was somewhat independent and had for 
> examle 
> its own clock-supply, while on this one there is only one for both ports of 
> the phy. Similarly with the clock getting fed back to the clock-controller 
> (one clock per port on the old block, now one clock for the whole phy).
> 
> Then as you can see, the handling for power-up and down is a bit different 
> and 
> I guess one big block might be the still missing special otg handling, Frank 
> wrote about.

All right then.
> 
> 
> [...]
> 
>>> +   /*
>>> +* we don't need to rearm the delayed work when the phy port
>>> +* is suspended.
>>> +*/
>>> +   mutex_unlock(>mutex);
>>> +   return;
>>> +   default:
>>> +   dev_dbg(>phy->dev, "unknown phy state\n");
>>> +   break;
>>> +   }
>>> +
>>> +next_schedule:
>>> +   mutex_unlock(>mutex);
>>> +   schedule_delayed_work(>sm_work, SCHEDULE_DELAY);
>>
>> Why are you scheduling the work again? Interrupt handlers can invoke this
>> right?
> 
> Frank said, that the phy is only able to detect the plug-in event via 
> interrupts, not the removal, so once a plugged device is detected, this gets 
> rescheduled until the device gets removed.

okay.
> 
> [...]
> 
>>> +   /* find out a proper config which can be matched with dt. */
>>> +   index = 0;
>>> +   while (phy_cfgs[index].reg) {
>>> +   if (phy_cfgs[index].reg == reg) {
>>
>> Why not pass these config values from dt? Moreover finding the config using
>> register offset is bound to break.
> 
> As you have probably seen, this phy block is no stand-alone (mmio-)device, 
> but 
> gets controlled through special register/bits in the so called "General 
> Register Files" syscon.
> 
> The values stored and accessed here, are the location and layout of those 
> control registers. Bits in those phy control registers at times move between 
> phy-versions in different socs (rk3036, rk3228, rk3366, rk3368, rk3399) and 
> some are even missing. So I don't really see a nice way to describe that in 
> dt 
> without describing the register and offset of each of those 22 used bits 
> individually.
> 
> 
> I'm also not sure where you expect it to break? The reg-offset is the offset 
> of the phy inside the GRF and the Designware-phy also already does something 
> similar to select some appropriate values.

I'm concerned the phy can be placed in the different reg-offset within GRF
(like in the next silicon revision) and this driver can't be used.

Thanks
Kishon
> 
--
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 0/7] da8xx USB PHY (was da8xx USB clocks)

[Kishon Vijay Abraham I]

On Tuesday 10 May 2016 05:09 AM, David Lechner wrote:
> v5 changes:
> 
> Functionally, nothing has really changed. Just some cleanups based on 
> feedback.
> 
> * Renamed "usbphy" to "usb_phy" or "usb-phy" as appropriate
> * License header matches MODULE_LICENSE in new phy driver

applied all the phy patches to -next branch.

Thanks
Kishon

> 
> David Lechner (7):
>   mfd: da8xx-cfgchip: New header file for CFGCHIP registers.
>   dt-bindings: Add bindings for phy-da8xx-usb
>   phy: Add set_mode callback
>   phy: da8xx-usb: new driver for DA8xx SoC USB PHY
>   usb: ohci-da8xx: Remove code that references mach
>   usb: musb: da8xx: Use devm in probe
>   usb: musb: da8xx: Remove mach code
> 
>  .../devicetree/bindings/phy/phy-da8xx-usb.txt  |  40 
>  drivers/phy/Kconfig|  10 +
>  drivers/phy/Makefile   |   1 +
>  drivers/phy/phy-core.c |  15 ++
>  drivers/phy/phy-da8xx-usb.c| 244 
> +
>  drivers/usb/host/Kconfig   |   1 +
>  drivers/usb/host/ohci-da8xx.c  | 102 +
>  drivers/usb/musb/Kconfig   |   2 +-
>  drivers/usb/musb/da8xx.c   | 154 +
>  include/linux/mfd/da8xx-cfgchip.h  | 153 +
>  include/linux/phy/phy.h|  17 ++
>  include/linux/platform_data/usb-davinci.h  |  22 --
>  12 files changed, 592 insertions(+), 169 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/phy/phy-da8xx-usb.txt
>  create mode 100644 drivers/phy/phy-da8xx-usb.c
>  create mode 100644 include/linux/mfd/da8xx-cfgchip.h
> 
--
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/7] phy: Add set_mode callback

[Kishon Vijay Abraham I]

Hi,

On Tuesday 10 May 2016 05:09 AM, David Lechner wrote:
> The initial use for this is for PHYs that have a mode related to USB OTG.
> There are several SoCs (e.g. TI OMAP and DA8xx) that have a mode setting
> in the USB PHY to override OTG VBUS and ID signals.
> 
> Of course, the enum can be expaned in the future to include modes for
> other types of PHYs as well.
> 
> Suggested-by: Kishon Vijay Abraham I <kis...@ti.com>
> Signed-off-by: David Lechner <da...@lechnology.com>

I've created a immutable branch for this patch and it can be found here.
git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy.git
tags/phy-set-mode

I've merged this tag to my -next.

Thanks
Kishon

> ---
>  drivers/phy/phy-core.c  | 15 +++
>  include/linux/phy/phy.h | 17 +
>  2 files changed, 32 insertions(+)
> 
> diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
> index e7e574d..fe0344c 100644
> --- a/drivers/phy/phy-core.c
> +++ b/drivers/phy/phy-core.c
> @@ -342,6 +342,21 @@ int phy_power_off(struct phy *phy)
>  }
>  EXPORT_SYMBOL_GPL(phy_power_off);
>  
> +int phy_set_mode(struct phy *phy, enum phy_mode mode)
> +{
> + int ret;
> +
> + if (!phy || !phy->ops->set_mode)
> + return 0;
> +
> + mutex_lock(>mutex);
> + ret = phy->ops->set_mode(phy, mode);
> + mutex_unlock(>mutex);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(phy_set_mode);
> +
>  /**
>   * _of_phy_get() - lookup and obtain a reference to a phy by phandle
>   * @np: device_node for which to get the phy
> diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
> index 8cf05e3..4248ade 100644
> --- a/include/linux/phy/phy.h
> +++ b/include/linux/phy/phy.h
> @@ -22,12 +22,20 @@
>  
>  struct phy;
>  
> +enum phy_mode {
> + PHY_MODE_INVALID,
> + PHY_MODE_USB_HOST,
> + PHY_MODE_USB_DEVICE,
> + PHY_MODE_USB_OTG,
> +};
> +
>  /**
>   * struct phy_ops - set of function pointers for performing phy operations
>   * @init: operation to be performed for initializing phy
>   * @exit: operation to be performed while exiting
>   * @power_on: powering on the phy
>   * @power_off: powering off the phy
> + * @set_mode: set the mode of the phy
>   * @owner: the module owner containing the ops
>   */
>  struct phy_ops {
> @@ -35,6 +43,7 @@ struct phy_ops {
>   int (*exit)(struct phy *phy);
>   int (*power_on)(struct phy *phy);
>   int (*power_off)(struct phy *phy);
> + int (*set_mode)(struct phy *phy, enum phy_mode mode);
>   struct module *owner;
>  };
>  
> @@ -119,6 +128,7 @@ int phy_init(struct phy *phy);
>  int phy_exit(struct phy *phy);
>  int phy_power_on(struct phy *phy);
>  int phy_power_off(struct phy *phy);
> +int phy_set_mode(struct phy *phy, enum phy_mode mode);
>  static inline int phy_get_bus_width(struct phy *phy)
>  {
>   return phy->attrs.bus_width;
> @@ -224,6 +234,13 @@ static inline int phy_power_off(struct phy *phy)
>   return -ENOSYS;
>  }
>  
> +static inline int phy_set_mode(struct phy *phy, enum phy_mode mode)
> +{
> + if (!phy)
> + return 0;
> + return -ENOSYS;
> +}
> +
>  static inline int phy_get_bus_width(struct phy *phy)
>  {
>   return -ENOSYS;
> 
--
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] phy-sun4i-usb: Fix irq free conditions to match request conditions

[Kishon Vijay Abraham I]

Hi,

On Saturday 18 June 2016 05:03 PM, Sergei Shtylyov wrote:
> On 6/18/2016 12:31 PM, Hans de Goede wrote:
> 
>> commit 5cf700ac9d50("phy: phy-sun4i-usb: Fix optional gpios failing probe")
>> changed the condition under which irqs are requested, but omitted matching
>> changes to sun4i_usb_phy_remove(). This commit fixes this.
>>
>> Fixes: commit 5cf700ac9d50("phy: phy-sun4i-usb: Fix optional gpios failing
>> probe")
> 
>"Commit" not needed here, this tag has a standardized format.

Fixed it myself and applied.

Thanks
Kishon
--
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/7] phy: Add set_mode callback

[Kishon Vijay Abraham I]

Hi,

On Tuesday 10 May 2016 05:09 AM, David Lechner wrote:
> The initial use for this is for PHYs that have a mode related to USB OTG.
> There are several SoCs (e.g. TI OMAP and DA8xx) that have a mode setting
> in the USB PHY to override OTG VBUS and ID signals.
> 
> Of course, the enum can be expaned in the future to include modes for
> other types of PHYs as well.
> 
> Suggested-by: Kishon Vijay Abraham I <kis...@ti.com>
> Signed-off-by: David Lechner <da...@lechnology.com>

This patch is required for both phy driver and the usb driver. I can create a
immutable branch with only this patch and both me and Bin Liu can merge it in
our next branch.

Thanks
Kishon

> ---
>  drivers/phy/phy-core.c  | 15 +++
>  include/linux/phy/phy.h | 17 +
>  2 files changed, 32 insertions(+)
> 
> diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
> index e7e574d..fe0344c 100644
> --- a/drivers/phy/phy-core.c
> +++ b/drivers/phy/phy-core.c
> @@ -342,6 +342,21 @@ int phy_power_off(struct phy *phy)
>  }
>  EXPORT_SYMBOL_GPL(phy_power_off);
>  
> +int phy_set_mode(struct phy *phy, enum phy_mode mode)
> +{
> + int ret;
> +
> + if (!phy || !phy->ops->set_mode)
> + return 0;
> +
> + mutex_lock(>mutex);
> + ret = phy->ops->set_mode(phy, mode);
> + mutex_unlock(>mutex);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(phy_set_mode);
> +
>  /**
>   * _of_phy_get() - lookup and obtain a reference to a phy by phandle
>   * @np: device_node for which to get the phy
> diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
> index 8cf05e3..4248ade 100644
> --- a/include/linux/phy/phy.h
> +++ b/include/linux/phy/phy.h
> @@ -22,12 +22,20 @@
>  
>  struct phy;
>  
> +enum phy_mode {
> + PHY_MODE_INVALID,
> + PHY_MODE_USB_HOST,
> + PHY_MODE_USB_DEVICE,
> + PHY_MODE_USB_OTG,
> +};
> +
>  /**
>   * struct phy_ops - set of function pointers for performing phy operations
>   * @init: operation to be performed for initializing phy
>   * @exit: operation to be performed while exiting
>   * @power_on: powering on the phy
>   * @power_off: powering off the phy
> + * @set_mode: set the mode of the phy
>   * @owner: the module owner containing the ops
>   */
>  struct phy_ops {
> @@ -35,6 +43,7 @@ struct phy_ops {
>   int (*exit)(struct phy *phy);
>   int (*power_on)(struct phy *phy);
>   int (*power_off)(struct phy *phy);
> + int (*set_mode)(struct phy *phy, enum phy_mode mode);
>   struct module *owner;
>  };
>  
> @@ -119,6 +128,7 @@ int phy_init(struct phy *phy);
>  int phy_exit(struct phy *phy);
>  int phy_power_on(struct phy *phy);
>  int phy_power_off(struct phy *phy);
> +int phy_set_mode(struct phy *phy, enum phy_mode mode);
>  static inline int phy_get_bus_width(struct phy *phy)
>  {
>   return phy->attrs.bus_width;
> @@ -224,6 +234,13 @@ static inline int phy_power_off(struct phy *phy)
>   return -ENOSYS;
>  }
>  
> +static inline int phy_set_mode(struct phy *phy, enum phy_mode mode)
> +{
> + if (!phy)
> + return 0;
> + return -ENOSYS;
> +}
> +
>  static inline int phy_get_bus_width(struct phy *phy)
>  {
>   return -ENOSYS;
> 
--
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/4] phy-sun4i-usb: Add workaround for missing Vbus det interrupts on A31

[Kishon Vijay Abraham I]

On Sunday 05 June 2016 08:29 PM, Hans de Goede wrote:
> The A31 companion pmic (axp221) does not generate vbus change interrupts
> when the board is driving vbus, so we must poll when using the pmic for
> vbus-det _and_ we're driving vbus.
> 
> Signed-off-by: Hans de Goede <hdego...@redhat.com>

Acked-by: Kishon Vijay Abraham I <kis...@ti.com>
> ---
> Changes in v2:
> -No changes
> Changes in v3:
> -No changes
> ---
>  drivers/phy/phy-sun4i-usb.c | 34 --
>  1 file changed, 24 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/phy/phy-sun4i-usb.c b/drivers/phy/phy-sun4i-usb.c
> index e3cbaae..a7abae6 100644
> --- a/drivers/phy/phy-sun4i-usb.c
> +++ b/drivers/phy/phy-sun4i-usb.c
> @@ -95,6 +95,7 @@
>  
>  enum sun4i_usb_phy_type {
>   sun4i_a10_phy,
> + sun6i_a31_phy,
>   sun8i_a33_phy,
>   sun8i_h3_phy,
>  };
> @@ -125,7 +126,6 @@ struct sun4i_usb_phy_data {
>   /* phy0 / otg related variables */
>   struct extcon_dev *extcon;
>   bool phy0_init;
> - bool phy0_poll;
>   struct gpio_desc *id_det_gpio;
>   struct gpio_desc *vbus_det_gpio;
>   struct power_supply *vbus_power_supply;
> @@ -353,6 +353,24 @@ static bool sun4i_usb_phy0_have_vbus_det(struct 
> sun4i_usb_phy_data *data)
>   return data->vbus_det_gpio || data->vbus_power_supply;
>  }
>  
> +static bool sun4i_usb_phy0_poll(struct sun4i_usb_phy_data *data)
> +{
> + if ((data->id_det_gpio && data->id_det_irq < 0) ||
> + (data->vbus_det_gpio && data->vbus_det_irq < 0))
> + return true;
> +
> + /*
> +  * The A31 companion pmic (axp221) does not generate vbus change
> +  * interrupts when the board is driving vbus, so we must poll
> +  * when using the pmic for vbus-det _and_ we're driving vbus.
> +  */
> + if (data->cfg->type == sun6i_a31_phy &&
> + data->vbus_power_supply && data->phys[0].regulator_on)
> + return true;
> +
> + return false;
> +}
> +
>  static int sun4i_usb_phy_power_on(struct phy *_phy)
>  {
>   struct sun4i_usb_phy *phy = phy_get_drvdata(_phy);
> @@ -374,7 +392,7 @@ static int sun4i_usb_phy_power_on(struct phy *_phy)
>   phy->regulator_on = true;
>  
>   /* We must report Vbus high within OTG_TIME_A_WAIT_VRISE msec. */
> - if (phy->index == 0 && data->vbus_det_gpio && data->phy0_poll)
> + if (phy->index == 0 && sun4i_usb_phy0_poll(data))
>   mod_delayed_work(system_wq, >detect, DEBOUNCE_TIME);
>  
>   return 0;
> @@ -395,7 +413,7 @@ static int sun4i_usb_phy_power_off(struct phy *_phy)
>* phy0 vbus typically slowly discharges, sometimes this causes the
>* Vbus gpio to not trigger an edge irq on Vbus off, so force a rescan.
>*/
> - if (phy->index == 0 && data->vbus_det_gpio && !data->phy0_poll)
> + if (phy->index == 0 && !sun4i_usb_phy0_poll(data))
>   mod_delayed_work(system_wq, >detect, POLL_TIME);
>  
>   return 0;
> @@ -483,7 +501,7 @@ static void sun4i_usb_phy0_id_vbus_det_scan(struct 
> work_struct *work)
>   if (vbus_notify)
>   extcon_set_cable_state_(data->extcon, EXTCON_USB, vbus_det);
>  
> - if (data->phy0_poll)
> + if (sun4i_usb_phy0_poll(data))
>   queue_delayed_work(system_wq, >detect, POLL_TIME);
>  }
>  
> @@ -668,11 +686,6 @@ static int sun4i_usb_phy_probe(struct platform_device 
> *pdev)
>   }
>  
>   data->id_det_irq = gpiod_to_irq(data->id_det_gpio);
> - data->vbus_det_irq = gpiod_to_irq(data->vbus_det_gpio);
> - if ((data->id_det_gpio && data->id_det_irq < 0) ||
> - (data->vbus_det_gpio && data->vbus_det_irq < 0))
> - data->phy0_poll = true;
> -
>   if (data->id_det_irq >= 0) {
>   ret = devm_request_irq(dev, data->id_det_irq,
>   sun4i_usb_phy0_id_vbus_det_irq,
> @@ -684,6 +697,7 @@ static int sun4i_usb_phy_probe(struct platform_device 
> *pdev)
>   }
>   }
>  
> + data->vbus_det_irq = gpiod_to_irq(data->vbus_det_gpio);
>   if (data->vbus_det_irq >= 0) {
>   ret = devm_request_irq(dev, data->vbus_det_irq,
>   sun4i_usb_phy0_id_vbus_det_irq,
> @@ -735,7 +749,7 @@ static const struct sun4i_usb_phy_cfg sun5i_a13_cfg = {
>  
>  static const struct sun4i_usb_phy_cfg sun6i_a31_cfg = {
>   .num_phys = 3,
> - .type = sun4i_a10_phy,
> + .type = sun6i_a31_phy,
>   .disc_thresh = 3,
>   .phyctl_offset = REG_PHYCTL_A10,
>   .dedicated_clocks = true,
> 
--
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/4] phy-sun4i-usb: Add support for peripheral-only mode

[Kishon Vijay Abraham I]

On Sunday 05 June 2016 08:29 PM, Hans de Goede wrote:
> Use the new of_usb_get_dr_mode_by_phy() function to get the dr_mode
> from the musb controller node instead of assuming that having an id_det
> gpio means otg mode, and not having one means host mode.
> 
> Implement peripheral-only mode by adding a sun4i_usb_phy0_get_id_det
> helper which looks at the dr_mode, always registering our extcon and
> always monitoring vbus.
> 
> If dr_mode is not specified in the dts, do not register phy0 as we then
> do not know how to treat it. This is actually a good thing as this means
> we will not be registering phy0 on devices where the otg controller is
> not enabled in the devicetree.
> 
> Signed-off-by: Hans de Goede <hdego...@redhat.com>

Acked-by: Kishon Vijay Abraham I <kis...@ti.com>
> ---
> Changes in v2:
> -Adjust for of_usb_get_dr_mode_by_phy now taking an args0 parameter
> Changes in v3:
> -Only toggle the phy vbus-det bit on id-change on systems without vbus-det
>  when in otg mode
> ---
>  drivers/phy/phy-sun4i-usb.c | 68 
> ++---
>  1 file changed, 46 insertions(+), 22 deletions(-)
> 
> diff --git a/drivers/phy/phy-sun4i-usb.c b/drivers/phy/phy-sun4i-usb.c
> index bae54f7..e3cbaae 100644
> --- a/drivers/phy/phy-sun4i-usb.c
> +++ b/drivers/phy/phy-sun4i-usb.c
> @@ -40,6 +40,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  
>  #define REG_ISCR 0x00
> @@ -109,6 +110,7 @@ struct sun4i_usb_phy_cfg {
>  struct sun4i_usb_phy_data {
>   void __iomem *base;
>   const struct sun4i_usb_phy_cfg *cfg;
> + enum usb_dr_mode dr_mode;
>   struct mutex mutex;
>   struct sun4i_usb_phy {
>   struct phy *phy;
> @@ -119,6 +121,7 @@ struct sun4i_usb_phy_data {
>   bool regulator_on;
>   int index;
>   } phys[MAX_PHYS];
> + int first_phy;
>   /* phy0 / otg related variables */
>   struct extcon_dev *extcon;
>   bool phy0_init;
> @@ -285,16 +288,10 @@ static int sun4i_usb_phy_init(struct phy *_phy)
>   sun4i_usb_phy0_update_iscr(_phy, 0, ISCR_DPDM_PULLUP_EN);
>   sun4i_usb_phy0_update_iscr(_phy, 0, ISCR_ID_PULLUP_EN);
>  
> - if (data->id_det_gpio) {
> - /* OTG mode, force ISCR and cable state updates */
> - data->id_det = -1;
> - data->vbus_det = -1;
> - queue_delayed_work(system_wq, >detect, 0);
> - } else {
> - /* Host only mode */
> - sun4i_usb_phy0_set_id_detect(_phy, 0);
> - sun4i_usb_phy0_set_vbus_detect(_phy, 1);
> - }
> + /* Force ISCR and cable state updates */
> + data->id_det = -1;
> + data->vbus_det = -1;
> + queue_delayed_work(system_wq, >detect, 0);
>   }
>  
>   return 0;
> @@ -319,6 +316,19 @@ static int sun4i_usb_phy_exit(struct phy *_phy)
>   return 0;
>  }
>  
> +static int sun4i_usb_phy0_get_id_det(struct sun4i_usb_phy_data *data)
> +{
> + switch (data->dr_mode) {
> + case USB_DR_MODE_OTG:
> + return gpiod_get_value_cansleep(data->id_det_gpio);
> + case USB_DR_MODE_HOST:
> + return 0;
> + case USB_DR_MODE_PERIPHERAL:
> + default:
> + return 1;
> + }
> +}
> +
>  static int sun4i_usb_phy0_get_vbus_det(struct sun4i_usb_phy_data *data)
>  {
>   if (data->vbus_det_gpio)
> @@ -414,7 +424,10 @@ static void sun4i_usb_phy0_id_vbus_det_scan(struct 
> work_struct *work)
>   struct phy *phy0 = data->phys[0].phy;
>   int id_det, vbus_det, id_notify = 0, vbus_notify = 0;
>  
> - id_det = gpiod_get_value_cansleep(data->id_det_gpio);
> + if (phy0 == NULL)
> + return;
> +
> + id_det = sun4i_usb_phy0_get_id_det(data);
>   vbus_det = sun4i_usb_phy0_get_vbus_det(data);
>  
>   mutex_lock(>mutex);
> @@ -430,7 +443,8 @@ static void sun4i_usb_phy0_id_vbus_det_scan(struct 
> work_struct *work)
>* without vbus detection report vbus low for long enough for
>* the musb-ip to end the current device session.
>*/
> - if (!sun4i_usb_phy0_have_vbus_det(data) && id_det == 0) {
> + if (data->dr_mode == USB_DR_MODE_OTG &&
> + !sun4i_usb_phy0_have_vbus_det(data) && id_det == 0) {
>   sun4i_usb_phy0_set_vbus_detect(phy0, 0);
>   msleep(200);
>  

Re: [PATCH v5 2/2] phy: rockchip-inno-usb2: add a new driver for Rockchip usb2phy

[Kishon Vijay Abraham I]

Hi,

On Monday 13 June 2016 07:40 AM, Frank Wang wrote:
> The newer SoCs (rk3366, rk3399) take a different usb-phy IP block
> than rk3288 and before, and most of phy-related registers are also
> different from the past, so a new phy driver is required necessarily.
> 
> Signed-off-by: Frank Wang 
> ---
> 
> Changes in v5:
>  - Added 'reg' in the data block to match the different phy-blocks in dt.
> 
> Changes in v4:
>  - Removed some processes related to 'vbus_host-supply'.
> 
> Changes in v3:
>  - Resolved the mapping defect between fixed value in driver and the property
>in devicetree.
>  - Optimized 480m output clock register function.
>  - Code cleanup.
> 
> Changes in v2:
>  - Changed vbus_host operation from gpio to regulator in *_probe.
>  - Improved the fault treatment relate to 480m clock register.
>  - Cleaned up some meaningless codes in *_clk480m_disable.
>  - made more clear the comment of *_sm_work.
> 
>  drivers/phy/Kconfig  |7 +
>  drivers/phy/Makefile |1 +
>  drivers/phy/phy-rockchip-inno-usb2.c |  645 
> ++
>  3 files changed, 653 insertions(+)
>  create mode 100644 drivers/phy/phy-rockchip-inno-usb2.c
> 
> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> index b869b98..29ef15c 100644
> --- a/drivers/phy/Kconfig
> +++ b/drivers/phy/Kconfig
> @@ -347,6 +347,13 @@ config PHY_ROCKCHIP_USB
>   help
> Enable this to support the Rockchip USB 2.0 PHY.
>  
> +config PHY_ROCKCHIP_INNO_USB2
> + tristate "Rockchip INNO USB2PHY Driver"
> + depends on ARCH_ROCKCHIP && OF

depends on COMMON_CLK, since this is also a clock provider.
> + select GENERIC_PHY
> + help
> +   Support for Rockchip USB2.0 PHY with Innosilicon IP block.
> +
>  config PHY_ROCKCHIP_EMMC
>   tristate "Rockchip EMMC PHY Driver"
>   depends on ARCH_ROCKCHIP && OF
> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
> index 9c3e73c..4963fbc 100644
> --- a/drivers/phy/Makefile
> +++ b/drivers/phy/Makefile
> @@ -38,6 +38,7 @@ phy-exynos-usb2-$(CONFIG_PHY_S5PV210_USB2)  += 
> phy-s5pv210-usb2.o
>  obj-$(CONFIG_PHY_EXYNOS5_USBDRD) += phy-exynos5-usbdrd.o
>  obj-$(CONFIG_PHY_QCOM_APQ8064_SATA)  += phy-qcom-apq8064-sata.o
>  obj-$(CONFIG_PHY_ROCKCHIP_USB) += phy-rockchip-usb.o
> +obj-$(CONFIG_PHY_ROCKCHIP_INNO_USB2) += phy-rockchip-inno-usb2.o
>  obj-$(CONFIG_PHY_ROCKCHIP_EMMC) += phy-rockchip-emmc.o
>  obj-$(CONFIG_PHY_ROCKCHIP_DP)+= phy-rockchip-dp.o
>  obj-$(CONFIG_PHY_QCOM_IPQ806X_SATA)  += phy-qcom-ipq806x-sata.o
> diff --git a/drivers/phy/phy-rockchip-inno-usb2.c 
> b/drivers/phy/phy-rockchip-inno-usb2.c
> new file mode 100644
> index 000..fc599c7
> --- /dev/null
> +++ b/drivers/phy/phy-rockchip-inno-usb2.c
> @@ -0,0 +1,645 @@
> +/*
> + * Rockchip USB2.0 PHY with Innosilicon IP block driver
> + *
> + * Copyright (C) 2016 Fuzhou Rockchip Electronics Co., Ltd
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define BIT_WRITEABLE_SHIFT  16
> +#define SCHEDULE_DELAY   (60 * HZ)
> +
> +enum rockchip_usb2phy_port_id {
> + USB2PHY_PORT_OTG,
> + USB2PHY_PORT_HOST,
> + USB2PHY_NUM_PORTS,
> +};
> +
> +enum rockchip_usb2phy_host_state {
> + PHY_STATE_HS_ONLINE = 0,
> + PHY_STATE_DISCONNECT= 1,
> + PHY_STATE_HS_CONNECT= 2,
> + PHY_STATE_FS_CONNECT= 4,
> +};
> +
> +struct usb2phy_reg {
> + unsigned intoffset;
> + unsigned intbitend;
> + unsigned intbitstart;
> + unsigned intdisable;
> + unsigned intenable;
> +};
> +
> +/**
> + * struct rockchip_usb2phy_port_cfg: usb-phy port configuration.
> + * @phy_sus: phy suspend register.
> + * @ls_det_en: linestate detection enable register.
> + * @ls_det_st: linestate detection state register.
> + * @ls_det_clr: linestate detection clear register.
> + * @utmi_ls: utmi linestate state register.
> + * @utmi_hstdet: utmi host disconnect register.
> + */
> +struct rockchip_usb2phy_port_cfg {
> + struct usb2phy_reg  phy_sus;
> + struct usb2phy_reg  ls_det_en;
> + struct usb2phy_reg  ls_det_st;
> + struct usb2phy_reg  ls_det_clr;
> + struct usb2phy_reg  utmi_ls;
> + struct 

Re: [PATCH 8/10] phy: phy-stih407-usb: Inform the reset framework that our reset line may be shared

[Kishon Vijay Abraham I]

On Monday 06 June 2016 10:38 PM, Lee Jones wrote:
> On the STiH410 B2120 development board the ports on the Generic PHY
> share their reset lines with each other.  New functionality in the
> reset subsystems forces consumers to be explicit when requesting
> shared/exclusive reset lines.
> 
> Signed-off-by: Lee Jones <lee.jo...@linaro.org>

Acked-by: Kishon Vijay Abraham I <kis...@ti.com>
> ---
>  drivers/phy/phy-stih407-usb.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/phy/phy-stih407-usb.c b/drivers/phy/phy-stih407-usb.c
> index 1d5ae5f..b1f44ab 100644
> --- a/drivers/phy/phy-stih407-usb.c
> +++ b/drivers/phy/phy-stih407-usb.c
> @@ -105,13 +105,13 @@ static int stih407_usb2_picophy_probe(struct 
> platform_device *pdev)
>   phy_dev->dev = dev;
>   dev_set_drvdata(dev, phy_dev);
>  
> - phy_dev->rstc = devm_reset_control_get(dev, "global");
> + phy_dev->rstc = devm_reset_control_get_shared(dev, "global");
>   if (IS_ERR(phy_dev->rstc)) {
>   dev_err(dev, "failed to ctrl picoPHY reset\n");
>   return PTR_ERR(phy_dev->rstc);
>   }
>  
> - phy_dev->rstport = devm_reset_control_get(dev, "port");
> + phy_dev->rstport = devm_reset_control_get_exclusive(dev, "port");
>   if (IS_ERR(phy_dev->rstport)) {
>   dev_err(dev, "failed to ctrl picoPHY reset\n");
>   return PTR_ERR(phy_dev->rstport);
> 
--
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/7] phy: miphy28lp: Inform the reset framework that our reset line may be shared

[Kishon Vijay Abraham I]

On Monday 06 June 2016 09:26 PM, Lee Jones wrote:
> On the STiH410 B2120 development board the MiPHY28lp shares its reset
> line with the Synopsys DWC3 SuperSpeed (SS) USB 3.0 Dual-Role-Device
> (DRD).  New functionality in the reset subsystems forces consumers to
> be explicit when requesting shared/exclusive reset lines.
> 
> Signed-off-by: Lee Jones <lee.jo...@linaro.org>

Acked-by: Kishon Vijay Abraham I <kis...@ti.com>
> ---
>  drivers/phy/phy-miphy28lp.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/phy/phy-miphy28lp.c b/drivers/phy/phy-miphy28lp.c
> index 3acd2a1..213e2e1 100644
> --- a/drivers/phy/phy-miphy28lp.c
> +++ b/drivers/phy/phy-miphy28lp.c
> @@ -1143,7 +1143,8 @@ static int miphy28lp_probe_resets(struct device_node 
> *node,
>   struct miphy28lp_dev *miphy_dev = miphy_phy->phydev;
>   int err;
>  
> - miphy_phy->miphy_rst = of_reset_control_get(node, "miphy-sw-rst");
> + miphy_phy->miphy_rst =
> + of_reset_control_get_shared(node, "miphy-sw-rst");
>  
>   if (IS_ERR(miphy_phy->miphy_rst)) {
>   dev_err(miphy_dev->dev,
> 
--
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