Re: [PATCH v3 0/3] usb: renesas_usbhs: More compat strings

[Felipe Balbi]

Hi,

Simon Horman  writes:
> Hi,
>
> this short series adds generic, and soc-specific r8a7792 and r8a7793 compat
> strings to the Renesas USBHS driver. The intention is to provide a complete
> set of compat strings for known R-Car SoCs.
>
> Changes since v2:
> * Split documentation of SoC names into separate patch
> * Use correct fallback compatibility string in example
>
> Changes since v1:
> * Add R-Car Gen2 and Gen3 fallback compatibility strings rather than
>   a single compatibility string for all of R-Car.
>
> Simon Horman (3):
>   usb: renesas_usbhs: add SoC names to compatibility string
> documentation
>   usb: renesas_usbhs: add fallback compatibility strings
>   usb: renesas_usbhs: add device tree support for r8a779[23]

since patch 2 got a few comments, I'll wait a new series. While
resending, please collect all Acks to ease my life a bit ;-)

cheers

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH] usb: gadget: renesas_usb3: add support for Renesas USB3.0 peripheral controller

[Felipe Balbi]

Hi,

Arnd Bergmann  writes:
>> +struct renesas_usb3;
>> +struct renesas_usb3_request {
>> +struct usb_request  req;
>> +struct list_headqueue;
>> +};
>
> There is already a list_head in struct usb_request. Could you use that?
> (I don't know, just asking because this looks odd)

no, no. Don't do that. The list_head in usb_request is for use by the
gadget drivers and the gadget drivers only.

-- 
balbi


signature.asc
Description: PGP signature

Re: [4.4-rc][PATCH v2] ARM: dts: am4372: fix clock source for arm twd and global timers

[Felipe Balbi]

Hi,

Grygorii Strashko  writes:
> ARM TWD and Global timer are clocked by PERIPHCLK which is MPU_CLK/2.
> But now they are clocked by dpll_mpu_m2_ck == MPU_CLK and, as result.
> Timekeeping core misbehaves. For example, execution of command
> "sleep 5" will take 10 sec instead of 5.
>
> Hence, fix it by adding mpu_periphclk ("fixed-factor-clock") and use
> it for clocking ARM TWD and Global timer (same way as on OMAP4).
>
> Cc: Tony Lindgren 
> Cc: Felipe Balbi 
> Cc: Tero Kristo 
> Fixes:commit 8cbd4c2f6a99 ("arm: boot: dts: am4372: add ARM timers and SCU 
> nodes")
> Signed-off-by: Grygorii Strashko 

this seems to be the best fix for this problem, yeah.

Reviewed-by: Felipe Balbi 

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH 1/3] usb: misc: generic_onboard_hub: add generic onboard USB HUB driver

[Felipe Balbi]

Hi,

Peter Chen  writes:
>> seriously ? Is this really all ? What about that reset line below ?
>
> The clock is PHY input clock on the HUB, this clock may from SoC's
> PLL.

oh, you might have misunderstood my comment. I'm saying that there is
more than one thing you could cache in your private structure. That's
all.

>> > +static int usb_hub_generic_probe(struct platform_device *pdev)
>> > +{
>> > +  struct device *dev = &pdev->dev;
>> > +  struct usb_hub_generic_platform_data *pdata = dev->platform_data;
>> > +  struct usb_hub_generic_data *hub_data;
>> > +  int reset_pol = 0, duration_us = 50, ret = 0;
>> > +  struct gpio_desc *gpiod_reset = NULL;
>> > +
>> > +  hub_data = devm_kzalloc(dev, sizeof(*hub_data), GFP_KERNEL);
>> > +  if (!hub_data)
>> > +  return -ENOMEM;
>> > +
>> > +  if (dev->of_node) {
>> > +  struct device_node *node = dev->of_node;
>> > +
>> > +  hub_data->clk = devm_clk_get(dev, "external_clk");
>> > +  if (IS_ERR(hub_data->clk)) {
>> > +  dev_dbg(dev, "Can't get external clock: %ld\n",
>> > +  PTR_ERR(hub_data->clk));
>> 
>> how about setting clock to NULL to here ? then you don't need IS_ERR()
>> checks anywhere else.
>> 
>> > +  }
>> 
>> braces shouldn't be used here, if you add NULL trick above,
>> however... then you can keep them.
>> 
>
> Braces aren't needed, it may not too much useful to using NULL
> as a indicator for error pointer.

heh, it's not about using it as an error pointer. I'm merely trying to
make clk optional. NULL is a valid clk, meaning you won't get NULL
pointer dereferences when passing it along clk_*() calls (if you find
any, it's likely a bug in CCF), so NULL can be used to cope with
optional clocks:

 clk = clk_get(dev, "foo");
 if (IS_ERR(clk)) {
if (PTR_ERR(clk) == -EPROBE_DEFER)
return -EPROBE_DEFER;
else
clk = NULL;
 }

>> > +  /*
>> > +   * Try to get the information for HUB reset, the
>> > +   * default setting like below:
>> > +   *
>> > +   * - Reset state is low
>> > +   * - The duration is 50us
>> > +   */
>> > +  if (of_find_property(node, "hub-reset-active-high", NULL))
>> > +  reset_pol = 1;
>> 
>> you see, this is definitely *not* generic. You should write a generic
>> reset-gpio.c reset controller and describe the polarity on the gpio
>> binding. This driver *always* uses reset_assert(); reset_deassert(); and
>> reset-gpio implements though by gpiod_set_value() correctly.
>> 
>> Polarity _must_ be described elsewhere in DT.
>> 
>> > +  of_property_read_u32(node, "hub-reset-duration-us",
>> > +  &duration_us);
>> 
>> likewise, this should be described as a debounce time for the GPIO.
>> 
>
> Yes, if we are a reset gpio driver.

even if you use a raw GPIO, polarity and duration must come through DT.

>> > +  usleep_range(duration_us, duration_us + 100);
>> > +  gpiod_set_value(gpiod_reset, reset_pol ? 0 : 1);
>> 
>> wrong. You should _not_ have polarity checks here. You should have
>> already initialized the gpio as ACTIVE_HIGH or ACTIVE_LOW and gpiolib
>> will handle the polarity for you.
>
> Yes, you are right. I did not understand ACTIVE_LOW for gpio flag
> before.

with open source code, that's a rather poor excuse, Peter.

>> > +static int __init usb_hub_generic_init(void)
>> > +{
>> > +  return platform_driver_register(&usb_hub_generic_driver);
>> > +}
>> > +subsys_initcall(usb_hub_generic_init);
>> > +
>> > +static void __exit usb_hub_generic_exit(void)
>> > +{
>> > +  platform_driver_unregister(&usb_hub_generic_driver);
>> > +}
>> > +module_exit(usb_hub_generic_exit);
>> 
>> module_platform_driver();
>
> I want this driver to be called before module init's.

why ?

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH 1/3] usb: misc: generic_onboard_hub: add generic onboard USB HUB driver

[Felipe Balbi]

Hi,

Peter Chen  writes:
> diff --git a/drivers/usb/misc/Makefile b/drivers/usb/misc/Makefile
> index 45fd4ac..da52e9a 100644
> --- a/drivers/usb/misc/Makefile
> +++ b/drivers/usb/misc/Makefile
> @@ -29,3 +29,4 @@ obj-$(CONFIG_USB_CHAOSKEY)  += chaoskey.o
>  
>  obj-$(CONFIG_USB_SISUSBVGA)  += sisusbvga/
>  obj-$(CONFIG_USB_LINK_LAYER_TEST)+= lvstest.o
> +obj-$(CONFIG_USB_ONBOARD_HUB)+= generic_onboard_hub.o
> diff --git a/drivers/usb/misc/generic_onboard_hub.c 
> b/drivers/usb/misc/generic_onboard_hub.c
> new file mode 100644
> index 000..df722a0
> --- /dev/null
> +++ b/drivers/usb/misc/generic_onboard_hub.c
> @@ -0,0 +1,162 @@
> +/*
> + * usb_hub_generic.c The generic onboard USB HUB driver
> + *
> + * Copyright (C) 2015 Freescale Semiconductor, Inc.
> + * Author: Peter Chen 
> + *
> + * This program is free software: you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2  of
> + * the License as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program.  If not, see .
> + */
> +
> +/*
> + * This driver is only for the USB HUB devices which need to control
> + * their external pins(clock, reset, etc), and these USB HUB devices
> + * are soldered at the board.
> + */
> +
> +#define DEBUG

nope

> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 

 ?

> +struct usb_hub_generic_data {
> + struct clk *clk;

seriously ? Is this really all ? What about that reset line below ?

In fact, that reset line should be using a generic reset-gpio.c instead
of a raw gpio.

> +static int usb_hub_generic_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct usb_hub_generic_platform_data *pdata = dev->platform_data;
> + struct usb_hub_generic_data *hub_data;
> + int reset_pol = 0, duration_us = 50, ret = 0;
> + struct gpio_desc *gpiod_reset = NULL;
> +
> + hub_data = devm_kzalloc(dev, sizeof(*hub_data), GFP_KERNEL);
> + if (!hub_data)
> + return -ENOMEM;
> +
> + if (dev->of_node) {
> + struct device_node *node = dev->of_node;
> +
> + hub_data->clk = devm_clk_get(dev, "external_clk");
> + if (IS_ERR(hub_data->clk)) {
> + dev_dbg(dev, "Can't get external clock: %ld\n",
> + PTR_ERR(hub_data->clk));

how about setting clock to NULL to here ? then you don't need IS_ERR()
checks anywhere else.

> + }

braces shouldn't be used here, if you add NULL trick above,
however... then you can keep them.

> + /*
> +  * Try to get the information for HUB reset, the
> +  * default setting like below:
> +  *
> +  * - Reset state is low
> +  * - The duration is 50us
> +  */
> + if (of_find_property(node, "hub-reset-active-high", NULL))
> + reset_pol = 1;

you see, this is definitely *not* generic. You should write a generic
reset-gpio.c reset controller and describe the polarity on the gpio
binding. This driver *always* uses reset_assert(); reset_deassert(); and
reset-gpio implements though by gpiod_set_value() correctly.

Polarity _must_ be described elsewhere in DT.

> + of_property_read_u32(node, "hub-reset-duration-us",
> + &duration_us);

likewise, this should be described as a debounce time for the GPIO.

> + gpiod_reset = devm_gpiod_get_optional(dev, "hub-reset",
> + reset_pol ? GPIOD_OUT_HIGH : GPIOD_OUT_LOW);
> + ret = PTR_ERR_OR_ZERO(gpiod_reset);
> + if (ret) {
> + dev_err(dev, "Failed to get reset gpio, err = %d\n",
> + ret);
> + return ret;
> + }
> + } else if (pdata) {
> + hub_data->clk = pdata->ext_clk;
> + duration_us = pdata->gpio_reset_duration_us;
> + reset_pol = pdata->gpio_reset_polarity;
> +
> + if (gpio_is_valid(pdata->gpio_reset)) {
> + ret = devm_gpio_request_one(
> + dev, pdata->gpio_reset, reset_pol
> + ? GPIOF_OUT_INIT_HIGH : GPIOF_OUT_INIT_LOW,
> + dev_name(dev));
> + if (!ret)
> + gpiod_reset = gpio_to_desc(pdata->gpio_reset);
> + }
> + }
> +
> + if (!IS_ERR(hub_data->clk)) {
> + 

Re: [PATCH] ARM: DTS: am33xx: Use the new DT bindings for the eDMA3

[Felipe Balbi]

Hi,

Peter Ujfalusi  writes:
> @@ -174,12 +182,44 @@
>   };
>  
>   edma: edma@4900 {
> - compatible = "ti,edma3";
> - ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2";
> - reg =   <0x4900 0x1>,
> - <0x44e10f90 0x40>;
> + compatible = "ti,edma3-tpcc";
> + ti,hwmods = "tpcc";
> + reg =   <0x4900 0x1>;
> + reg-names = "edma3_cc";
>   interrupts = <12 13 14>;
> - #dma-cells = <1>;
> + interrupt-names = "edma3_ccint", "emda3_mperr",
> +   "edma3_ccerrint";
> + dma-requests = <64>;
> + #dma-cells = <2>;
> +
> + ti,tptcs = <&edma_tptc0 7>, <&edma_tptc1 5>,
> +<&edma_tptc2 0>;
> +
> + ti,edma-memcpy-channels = /bits/ 16 <20 21>;

can you explain this property here ? Are you setting bits 20 and 21 on a
16-bit field ?

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH v4 2/5] spi: spi-ti-qspi: add mmap mode read support

[Felipe Balbi]

Hi,

Vignesh R  writes:
> ti-qspi controller provides mmap port to read data from SPI flashes.
> mmap port is enabled in QSPI_SPI_SWITCH_REG. ctrl module register may
> also need to be accessed for some SoCs. The QSPI_SPI_SETUP_REGx needs to
> be populated with flash specific information like read opcode, read
> mode(quad, dual, normal), address width and dummy bytes. Once,
> controller is in mmap mode, the whole flash memory is available as a
> memory region at SoC specific address. This region can be accessed using
> normal memcpy() (or mem-to-mem dma copy). The ti-qspi controller hardware
> will internally communicate with SPI flash over SPI bus and get the
> requested data.
>
> Implement spi_flash_read() callback to support mmap read over SPI
> flash devices. With this, the read throughput increases from ~100kB/s to
> ~2.5 MB/s.
>
> Signed-off-by: Vignesh R 
> ---
>
>  drivers/spi/spi-ti-qspi.c | 101 
> ++
>  1 file changed, 94 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/spi/spi-ti-qspi.c b/drivers/spi/spi-ti-qspi.c
> index 64318fcfacf2..cd4e63f45e65 100644
> --- a/drivers/spi/spi-ti-qspi.c
> +++ b/drivers/spi/spi-ti-qspi.c
> @@ -56,6 +56,7 @@ struct ti_qspi {
>   u32 dc;
>  
>   bool ctrl_mod;
> + bool mmap_enabled;
>  };
>  
>  #define QSPI_PID (0x0)
> @@ -65,11 +66,8 @@ struct ti_qspi {
>  #define QSPI_SPI_CMD_REG (0x48)
>  #define QSPI_SPI_STATUS_REG  (0x4c)
>  #define QSPI_SPI_DATA_REG(0x50)
> -#define QSPI_SPI_SETUP0_REG  (0x54)
> +#define QSPI_SPI_SETUP_REG(n)((0x54 + 4 * n))
>  #define QSPI_SPI_SWITCH_REG  (0x64)
> -#define QSPI_SPI_SETUP1_REG  (0x58)
> -#define QSPI_SPI_SETUP2_REG  (0x5c)
> -#define QSPI_SPI_SETUP3_REG  (0x60)
>  #define QSPI_SPI_DATA_REG_1  (0x68)
>  #define QSPI_SPI_DATA_REG_2  (0x6c)
>  #define QSPI_SPI_DATA_REG_3  (0x70)
> @@ -109,6 +107,16 @@ struct ti_qspi {
>  
>  #define QSPI_AUTOSUSPEND_TIMEOUT 2000
>  
> +#define MEM_CS_EN(n) ((n + 1) << 8)
> +
> +#define MM_SWITCH0x1
> +
> +#define QSPI_SETUP_RD_NORMAL (0x0 << 12)
> +#define QSPI_SETUP_RD_DUAL   (0x1 << 12)
> +#define QSPI_SETUP_RD_QUAD   (0x3 << 12)
> +#define QSPI_SETUP_ADDR_SHIFT8
> +#define QSPI_SETUP_DUMMY_SHIFT   10
> +
>  static inline unsigned long ti_qspi_read(struct ti_qspi *qspi,
>   unsigned long reg)
>  {
> @@ -366,6 +374,78 @@ static int qspi_transfer_msg(struct ti_qspi *qspi, 
> struct spi_transfer *t)
>   return 0;
>  }
>  
> +static void ti_qspi_enable_memory_map(struct spi_device *spi)
> +{
> + struct ti_qspi  *qspi = spi_master_get_devdata(spi->master);
> + u32 val;
> +
> + ti_qspi_write(qspi, MM_SWITCH, QSPI_SPI_SWITCH_REG);
> + if (qspi->ctrl_mod) {
> + val = readl(qspi->ctrl_base);
> + val |= MEM_CS_EN(spi->chip_select);
> + writel(val, qspi->ctrl_base);
> + /* dummy readl to ensure bus sync */
> + readl(qspi->ctrl_base);
> + }
> + qspi->mmap_enabled = true;
> +}
> +
> +static void ti_qspi_disable_memory_map(struct spi_device *spi)
> +{
> + struct ti_qspi  *qspi = spi_master_get_devdata(spi->master);
> + u32 val;
> +
> + ti_qspi_write(qspi, 0, QSPI_SPI_SWITCH_REG);
> + if (qspi->ctrl_mod) {
> + val = readl(qspi->ctrl_base);
> + val &= ~MEM_CS_EN(spi->chip_select);
> + writel(val, qspi->ctrl_base);
> + }
> + qspi->mmap_enabled = false;
> +}
> +
> +static void ti_qspi_setup_mmap_read(struct spi_device *spi,
> + struct spi_flash_read_message *msg)
> +{
> + struct ti_qspi  *qspi = spi_master_get_devdata(spi->master);
> + u32 memval = msg->read_opcode;
> +
> + switch (msg->data_nbits) {
> + case SPI_NBITS_QUAD:
> + memval |= QSPI_SETUP_RD_QUAD;
> + break;
> + case SPI_NBITS_DUAL:
> + memval |= QSPI_SETUP_RD_DUAL;
> + break;
> + default:
> + memval |= QSPI_SETUP_RD_NORMAL;
> + break;
> + }
> + memval |= ((msg->addr_width - 1) << QSPI_SETUP_ADDR_SHIFT |
> +msg->dummy_bytes << QSPI_SETUP_DUMMY_SHIFT);
> + ti_qspi_write(qspi, memval,
> +   QSPI_SPI_SETUP_REG(spi->chip_select));
> +}
> +
> +static int ti_qspi_spi_flash_read(struct  spi_device *spi,
> +   struct spi_flash_read_message *msg)
> +{
> + struct ti_qspi *qspi = spi_master_get_devdata(spi->master);
> + int ret = 0;
> +
> + mutex_lock(&qspi->list_lock);
> +
> + if (!qspi->mmap_enabled)
> + ti_qspi_enable_memory_map(spi);
> + ti_qspi_setup_mmap_read(spi, msg);
> + memcpy_fromio(msg->buf, qspi->mmap_base + msg->from, msg->len);
> + msg->retlen = msg->len;

the way I

Re: [PATCH 2/2] usb: phy: msm: fix connect/disconnect bug for dragonboard OTG port

[Felipe Balbi]

Hi,

Tim Bird  writes:
> On 11/16/2015 09:21 AM, Felipe Balbi wrote:
>> 
>> Hi,
>> 
>> Peter Chen  writes:
>>> On Wed, Nov 11, 2015 at 09:48:00AM -0800, Tim Bird wrote:
>>>>
>>>>
>>>> On 11/10/2015 07:14 PM, Peter Chen wrote:
>>>>> On Tue, Nov 10, 2015 at 04:46:51PM -0800, Tim Bird wrote:
>>>>>> This fixes a bug where if you disconnect and re-connect the USB cable,
>>>>>> the gadget driver stops working.
>>>>>>
>>>>>> Add support for async_irq to wake up driver from low power mode.
>>>>>> Without this, the power management code never calls resume.
>>>>>> Also, have the phy driver kick the gadget driver (chipidea otg)
>>>>>> by having the chipidea driver register with it, for vbus connect
>>>>>> notifications.
>>>>>>
>>>>>> Signed-off-by: Tim Bird 
>>>>>> ---
>>>>>>  drivers/usb/chipidea/udc.c|  6 ++
>>>>>>  drivers/usb/phy/phy-msm-usb.c | 16 
>>>>>>  include/linux/usb/msm_hsusb.h |  1 +
>>>>>>  3 files changed, 23 insertions(+)
>> 
>> I just wanna know how you guys want this to be handled ? Through my tree
>> or chipidea's ? Or do we break the dependencies between the changes ?
>
> I'm fine with splitting it up.  I'm sending a new series with 3 patches
> right after this message.  Do both trees go to linux-next?

I have my fixes and next branches both on next. Not sure about chipidea.

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH] usb: dwc2: add support of hi6220

[Felipe Balbi]

"Herrero, Gregory"  writes:

> Hi Felipe,
>
> I just realized this patch miss "dma_desc_fs_enable" property in
> params_hi6220. (drivers/usb/dwc2/platform.c:57)
>
> You need to apply this patch:
>
> diff --git a/drivers/usb/dwc2/platform.c b/drivers/usb/dwc2/platform.c
> index d5102c4..2dfdae3 100644
> --- a/drivers/usb/dwc2/platform.c
> +++ b/drivers/usb/dwc2/platform.c
> @@ -59,6 +59,7 @@ static const struct dwc2_core_params params_hi6220 = {
> .otg_ver= 0,/* 1.3 */
> .dma_enable = 1,
> .dma_desc_enable= 0,
> +   .dma_desc_fs_enable = 0,
> .speed  = 0,/* High Speed */
> .enable_dynamic_fifo= 1,
> .en_multiple_tx_fifo= 1,
>
>
> Note that it is needed due to below patch.
> "usb: dwc2: host: enable descriptor dma for fs devices"

done, thanks.

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH] usb: dwc2: add support of hi6220

[Felipe Balbi]

Hi,

John Youn  writes:
> On 11/19/2015 11:04 AM, Felipe Balbi wrote:
>> 
>> Hi,
>> 
>> Zhangfei Gao  writes:
>>> Support hisilicon,hi6220-usb for HiKey board
>>>
>>> Signed-off-by: Zhangfei Gao 
>> 
>> doesn't apply:
>> 
>> Applying: usb: dwc2: add support of hi6220
>> error: drivers/usb/dwc2/platform.c: does not match index
>> Patch failed at 0001 usb: dwc2: add support of hi6220
>> The copy of the patch that failed is found in: 
>> workspace/linux/.git/rebase-apply/patch
>> When you have resolved this problem, run "git am --continue".
>> If you prefer to skip this patch, run "git am --skip" instead.
>> To restore the original branch and stop patching, run "git am --abort".
>> 
>> Care to rebase on my testing/next and also collect John's and Rob's ack ?
>> 
>
>
> That's weird. I just sync'd to your testing/next and it seems to
> apply fine.
>
> Same with the series from Gregory Herrero.
>
> Any chance it's something to do with your local repo?

odd. Seems like it works if I apply manually with git am, but fails if I
pipe message from emacs to git am. Oh well, let me try again.

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH 4/4] Documentation: usb: dwc3: qcom: Add TCSR mux usage

[Felipe Balbi]

Hi,

Andy Gross  writes:
> This patch adds documentation for the optional syscon-tcsr property in the
> Qualcomm DWC3 node.  The syscon-tcsr specifies the register and bit used to
> configure the TCSR USB phy mux register.
>
> Signed-off-by: Andy Gross 
> ---
>  Documentation/devicetree/bindings/usb/qcom,dwc3.txt | 11 +++
>  1 file changed, 11 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/usb/qcom,dwc3.txt 
> b/Documentation/devicetree/bindings/usb/qcom,dwc3.txt
> index ca164e7..dfa222d 100644
> --- a/Documentation/devicetree/bindings/usb/qcom,dwc3.txt
> +++ b/Documentation/devicetree/bindings/usb/qcom,dwc3.txt
> @@ -8,6 +8,10 @@ Required properties:
>"core" Master/Core clock, have to be >= 125 MHz for SS
>   operation and >= 60MHz for HS operation
>  
> +Optional properties:
> +- syscon-tcsrSpecifies TCSR handle, register offset, and bit 
> position for
> + configuring the phy mux setting.

oh, it's a PHY mux ? I don't think it should be part of any dwc3-* glue
layer then. By the time we reach dwc3, the mux should be properly
configured.

Kishon, any ideas ?

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH 2/4] usb: dwc3: qcom: Configure TCSR phy mux register

[Felipe Balbi]

Hi,

Andy Gross  writes:
> This patch adds automatic configuration of the TCSR phy mux register based on
> the syscon-tcsr devicetree entry.  This configuration is optional, as some
> platforms may not require the mux selection.
>
> Signed-off-by: Andy Gross 

just when I find a way to make a generic dwc3-of-simple.c glue layer :-p

I can, certainly drop my patches but I need more details on the syscon
usage below.

> ---
>  drivers/usb/dwc3/dwc3-qcom.c | 25 +
>  1 file changed, 25 insertions(+)
>
> diff --git a/drivers/usb/dwc3/dwc3-qcom.c b/drivers/usb/dwc3/dwc3-qcom.c
> index 0880260..fcf264c 100644
> --- a/drivers/usb/dwc3/dwc3-qcom.c
> +++ b/drivers/usb/dwc3/dwc3-qcom.c
> @@ -17,6 +17,8 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>  
>  struct dwc3_qcom {
>   struct device   *dev;
> @@ -30,6 +32,9 @@ static int dwc3_qcom_probe(struct platform_device *pdev)
>  {
>   struct device_node *node = pdev->dev.of_node;
>   struct dwc3_qcom *qdwc;
> + struct regmap *regmap;
> + u32 mux_offset;
> + u32 mux_bit;
>   int ret;
>  
>   qdwc = devm_kzalloc(&pdev->dev, sizeof(*qdwc), GFP_KERNEL);
> @@ -58,6 +63,26 @@ static int dwc3_qcom_probe(struct platform_device *pdev)
>   qdwc->sleep_clk = NULL;
>   }
>  
> + /* look for tcsr and if present, provision it */
> + regmap = syscon_regmap_lookup_by_phandle(node, "syscon-tcsr");
> + if (!IS_ERR(regmap)) {
> + if (of_property_read_u32_index(node, "syscon-tcsr", 1,
> +&mux_offset)) {
> + dev_err(qdwc->dev, "missing USB TCSR mux offset\n");
> + return -EINVAL;
> + }
> + if (of_property_read_u32_index(node, "syscon-tcsr", 2,
> +&mux_bit)) {
> + dev_err(qdwc->dev, "missing USB TCSR mux bit\n");
> + return -EINVAL;
> + }
> +
> + regmap_update_bits(regmap, mux_offset, BIT(mux_bit),
> +BIT(mux_bit));

what is tcsr and what does it ? It also seems to be optional, why's that ?

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH] usb: dwc2: add support of hi6220

[Felipe Balbi]

Hi,

Zhangfei Gao  writes:
> Support hisilicon,hi6220-usb for HiKey board
>
> Signed-off-by: Zhangfei Gao 

doesn't apply:

Applying: usb: dwc2: add support of hi6220
error: drivers/usb/dwc2/platform.c: does not match index
Patch failed at 0001 usb: dwc2: add support of hi6220
The copy of the patch that failed is found in: 
workspace/linux/.git/rebase-apply/patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

Care to rebase on my testing/next and also collect John's and Rob's ack ?

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH 1/2] usb: doc: dwc3-xilinx: Add devicetree bindings

[Felipe Balbi]

Hi,

Rob Herring  writes:
> On Wed, Nov 18, 2015 at 5:02 PM, Felipe Balbi  wrote:
>>
>> Hi,
>>
>> Rob Herring  writes:
>>> On Wed, Nov 18, 2015 at 06:20:31PM +0530, Subbaraya Sundeep Bhatta wrote:
>>>> This patch adds binding doc for Xilinx DWC3 glue driver.
>>>>
>>>> Signed-off-by: Subbaraya Sundeep Bhatta 
>>>
>>> I really dislike how the DWC3 binding has been done. The sub-node here
>>> is pointless. The only thing the outer node does is add clocks which
>>> should simply be part of the DWC3 node. Presumably the IP block needs
>>> some clocks...
>>>
>>> Anyway, it's self-contained within the DWC3, so I won't make you clean
>>> up the mess.
>>
>> heh, it's definitely not pointless. We get a lot of free goodies by
>> doing it that way. I'm just not going to repeat it once again. But in
>> summary:
>>
>> a) we force people to write glue layers for *only* their HW specific
>> details
>>
>> b) there's really no way to abuse dwc3 core because there's no symbol
>> exported from dwc3 core to glue
>
> Both are doable independent of DT.
>
>> c) PM (both system sleep and runtime) becomes a lot simpler with core
>> only caring about what PM details delivered by SNPS (e.g. Hibernation
>> mode from DWC3) and glue only has to consider the SoC integration parts
>> of PM (for OMAP that would be PRCM details, hwmod, etc).
>
> No doubt OMAP is special.

not only OMAP. Every single SoC will integrate a particular IP in its
own way.

>> I'm definitely not going to change dwc3 because it has made my life a
>> lot saner. Definitely a lot saner than MUSB. Besides, DTS is supposed to
>> describe the HW and that's, really, how the HW is.
>
> So reading the description, the DWC3 has no clocks?

of course it has, and you have registers in DWC3 to change some of the
parents of the clocks it uses internally.

>> There's a piece of HW which is somewhat platform agnostic and delivered
>> by SNPS as a black box (SNPS customers don't touch SNPS RTL) and there's
>> another piece of HW which bridges this dwc3 to the platform specific
>> details and integration context of the platform (for OMAP that would the
>> SYSCONFIG/SYSSTATUS registers, Clock autogating, PRCM, etc, etc etc).
>
> It is a black box, but with dozens of configuration options typically.

all of which are detected within the driver. For those which can't be,
we have bindings.

>> So you _do_ in fact, have two separate pieces of HW which are SW visible
>> and controllable independently. They each have their own IRQs (though in
>> some SoCs they share the same line), they're own address space, yada
>> yada yada.
>
> When that is the case, I have no problem with this split, but I don't
> see any of these examples in this particular case. So how should the
> binding look when there is no vendor specific glue? Are we supposed to
> keep the binding structure to appease the needs of the driver?

If there really is *no* vendor specific glue, nothing prevents them from
patching dwc3 to understand *OPTIONAL* clocks and use dwc3 directly. As
long as it doesn't break any of the platforms currently supported and
doesn't look ugly, fine with me.

In fact, there's one company which has been using dwc3 without a glue
layer. I forgot who told me they didn't need a glue layer, but it's in
the archives.

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH 1/2] usb: doc: dwc3-xilinx: Add devicetree bindings

[Felipe Balbi]

Hi,

Rob Herring  writes:
> On Wed, Nov 18, 2015 at 06:20:31PM +0530, Subbaraya Sundeep Bhatta wrote:
>> This patch adds binding doc for Xilinx DWC3 glue driver.
>> 
>> Signed-off-by: Subbaraya Sundeep Bhatta 
>
> I really dislike how the DWC3 binding has been done. The sub-node here 
> is pointless. The only thing the outer node does is add clocks which 
> should simply be part of the DWC3 node. Presumably the IP block needs 
> some clocks...
>
> Anyway, it's self-contained within the DWC3, so I won't make you clean 
> up the mess.

heh, it's definitely not pointless. We get a lot of free goodies by
doing it that way. I'm just not going to repeat it once again. But in
summary:

a) we force people to write glue layers for *only* their HW specific
details

b) there's really no way to abuse dwc3 core because there's no symbol
exported from dwc3 core to glue

c) PM (both system sleep and runtime) becomes a lot simpler with core
only caring about what PM details delivered by SNPS (e.g. Hibernation
mode from DWC3) and glue only has to consider the SoC integration parts
of PM (for OMAP that would be PRCM details, hwmod, etc).

I'm definitely not going to change dwc3 because it has made my life a
lot saner. Definitely a lot saner than MUSB. Besides, DTS is supposed to
describe the HW and that's, really, how the HW is.

There's a piece of HW which is somewhat platform agnostic and delivered
by SNPS as a black box (SNPS customers don't touch SNPS RTL) and there's
another piece of HW which bridges this dwc3 to the platform specific
details and integration context of the platform (for OMAP that would the
SYSCONFIG/SYSSTATUS registers, Clock autogating, PRCM, etc, etc etc).

So you _do_ in fact, have two separate pieces of HW which are SW visible
and controllable independently. They each have their own IRQs (though in
some SoCs they share the same line), they're own address space, yada
yada yada.

cheers

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH 2/2] usb: dwc3: Add Xilinx ZynqMP platform specific glue layer

[Felipe Balbi]

Hi,

Subbaraya Sundeep Bhatta  writes:
> This patch adds glue driver for DWC3 core in Xilinx ZynqMP SOC.
> DWC3 glue layer is hardware layer around Synopsys DesignWare
> USB3 core. Its purpose is to supply Synopsys IP with required clocks
> and interface it with the rest of the SoC.
>
> Signed-off-by: Subbaraya Sundeep Bhatta 
> ---
>  drivers/usb/dwc3/Kconfig   |   8 +++
>  drivers/usb/dwc3/Makefile  |   1 +
>  drivers/usb/dwc3/dwc3-xilinx.c | 131 
> +
>  3 files changed, 140 insertions(+)
>  create mode 100644 drivers/usb/dwc3/dwc3-xilinx.c
>
> diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig
> index 5a42c45..a447879 100644
> --- a/drivers/usb/dwc3/Kconfig
> +++ b/drivers/usb/dwc3/Kconfig
> @@ -104,4 +104,12 @@ config USB_DWC3_QCOM
> Recent Qualcomm SoCs ship with one DesignWare Core USB3 IP inside,
> say 'Y' or 'M' if you have one such device.
>  
> +config USB_DWC3_XILINX
> + tristate "Xilinx ZynqMP Platform"
> + depends on ARCH_ZYNQMP || COMPILE_TEST
> + default USB_DWC3
> + help
> +   Xilinx ZynqMP SOC ship with two DesignWare Core USB3 IPs inside,
> +   say 'Y' or 'M' if you have one such device.
> +
>  endif
> diff --git a/drivers/usb/dwc3/Makefile b/drivers/usb/dwc3/Makefile
> index acc951d..50cb626 100644
> --- a/drivers/usb/dwc3/Makefile
> +++ b/drivers/usb/dwc3/Makefile
> @@ -39,3 +39,4 @@ obj-$(CONFIG_USB_DWC3_PCI)  += dwc3-pci.o
>  obj-$(CONFIG_USB_DWC3_KEYSTONE)  += dwc3-keystone.o
>  obj-$(CONFIG_USB_DWC3_QCOM)  += dwc3-qcom.o
>  obj-$(CONFIG_USB_DWC3_ST)+= dwc3-st.o
> +obj-$(CONFIG_USB_DWC3_XILINX)+= dwc3-xilinx.o
> diff --git a/drivers/usb/dwc3/dwc3-xilinx.c b/drivers/usb/dwc3/dwc3-xilinx.c
> new file mode 100644
> index 000..a0dce3e
> --- /dev/null
> +++ b/drivers/usb/dwc3/dwc3-xilinx.c
> @@ -0,0 +1,131 @@
> +/**
> + * dwc3-xilinx.c - Xilinx ZynqMP specific Glue layer
> + *
> + * Copyright (C) 2015 Xilinx Inc.
> + *
> + * Author: Subbaraya Sundeep 
> + *
> + * This program is free software: you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2  of
> + * the License as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/**
> + * struct xilinx_dwc3 - dwc3 xilinx glue structure
> + * @dev: device pointer
> + * @ref_clk: clock input to core during PHY power down
> + * @bus_clk: bus clock input to core
> + */
> +struct xilinx_dwc3 {
> + struct device   *dev;
> + struct clk  *ref_clk;
> + struct clk  *bus_clk;
> +};
> +
> +/**
> + * xilinx_dwc3_probe - The device probe function for driver initialization.
> + * @pdev: pointer to the platform device structure.
> + *
> + * Return: 0 for success and error value on failure
> + */
> +static int xilinx_dwc3_probe(struct platform_device *pdev)
> +{
> + struct device_node *node = pdev->dev.of_node;
> + struct xilinx_dwc3 *xdwc3;
> + int ret;
> +
> + xdwc3 = devm_kzalloc(&pdev->dev, sizeof(*xdwc3), GFP_KERNEL);
> + if (!xdwc3)
> + return -ENOMEM;
> +
> + xdwc3->dev = &pdev->dev;
> +
> + xdwc3->bus_clk = devm_clk_get(xdwc3->dev, "bus_clk");
> + if (IS_ERR(xdwc3->bus_clk)) {
> + dev_err(xdwc3->dev, "unable to get usb bus clock");
> + return PTR_ERR(xdwc3->bus_clk);
> + }
> +
> + xdwc3->ref_clk = devm_clk_get(xdwc3->dev, "ref_clk");
> + if (IS_ERR(xdwc3->ref_clk)) {
> + dev_err(xdwc3->dev, "unable to get usb ref clock");
> + return PTR_ERR(xdwc3->ref_clk);
> + }
> +
> + ret = clk_prepare_enable(xdwc3->bus_clk);
> + if (ret)
> + goto err_bus_clk;
> + ret = clk_prepare_enable(xdwc3->ref_clk);
> + if (ret)
> + goto err_ref_clk;
> +
> + platform_set_drvdata(pdev, xdwc3);
> +
> + ret = of_platform_populate(node, NULL, NULL, xdwc3->dev);
> + if (ret) {
> + dev_err(xdwc3->dev, "failed to create dwc3 core\n");
> + goto err_dwc3_core;
> + }
> +
> + return 0;
> +
> +err_dwc3_core:
> + clk_disable_unprepare(xdwc3->ref_clk);
> +err_ref_clk:
> + clk_disable_unprepare(xdwc3->bus_clk);
> +err_bus_clk:
> + return ret;
> +}
> +
> +/**
> + * xilinx_dwc3_remove - Releases the resources allocated during 
> initialization.
> + * @pdev: pointer to the platform device structure.
> + *
> + * Return: 0 always
> + */
> +static int xilinx_dwc3_remove(struct platform_device *pdev)
> +{
> + struct xilinx_dwc3 *xdwc3 = platform_get_drvdata(pdev);
> +
> + of_platform_depopulate(xdwc3->dev);
> +
> +  

Re: [PATCH 2/2] usb: phy: msm: fix connect/disconnect bug for dragonboard OTG port

[Felipe Balbi]

Hi,

Peter Chen  writes:
> On Wed, Nov 11, 2015 at 09:48:00AM -0800, Tim Bird wrote:
>> 
>> 
>> On 11/10/2015 07:14 PM, Peter Chen wrote:
>> > On Tue, Nov 10, 2015 at 04:46:51PM -0800, Tim Bird wrote:
>> >> This fixes a bug where if you disconnect and re-connect the USB cable,
>> >> the gadget driver stops working.
>> >>
>> >> Add support for async_irq to wake up driver from low power mode.
>> >> Without this, the power management code never calls resume.
>> >> Also, have the phy driver kick the gadget driver (chipidea otg)
>> >> by having the chipidea driver register with it, for vbus connect
>> >> notifications.
>> >>
>> >> Signed-off-by: Tim Bird 
>> >> ---
>> >>  drivers/usb/chipidea/udc.c|  6 ++
>> >>  drivers/usb/phy/phy-msm-usb.c | 16 
>> >>  include/linux/usb/msm_hsusb.h |  1 +
>> >>  3 files changed, 23 insertions(+)

I just wanna know how you guys want this to be handled ? Through my tree
or chipidea's ? Or do we break the dependencies between the changes ?

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH v2 5/5] ARM: dts: AM4372: add entry for qspi mmap region

[Felipe Balbi]

Hi,

Rob Herring  writes:
> On Tue, Nov 03, 2015 at 03:36:14PM +0530, Vignesh R wrote:
>> Add qspi memory mapped region entries for AM43xx based SoCs. Also,
>> update the binding documents for the controller to document this change.
>> 
>> Signed-off-by: Vignesh R 
>
> Acked-by: Rob Herring 
>
>> ---
>>  Documentation/devicetree/bindings/spi/ti_qspi.txt | 5 +++--
>>  arch/arm/boot/dts/am4372.dtsi | 4 +++-
>>  2 files changed, 6 insertions(+), 3 deletions(-)
>> 
>> diff --git a/Documentation/devicetree/bindings/spi/ti_qspi.txt 
>> b/Documentation/devicetree/bindings/spi/ti_qspi.txt
>> index f05dd631bef1..05488970060b 100644
>> --- a/Documentation/devicetree/bindings/spi/ti_qspi.txt
>> +++ b/Documentation/devicetree/bindings/spi/ti_qspi.txt
>> @@ -17,9 +17,10 @@ Recommended properties:
>>  
>>  Example:
>>  
>> +For am4372:
>>  qspi: qspi@4b30 {
>> -compatible = "ti,dra7xxx-qspi";
>> -reg = <0x4790 0x100>, <0x3000 0x3ff>;
>> +compatible = "ti,am4372-qspi";
>> +reg = <0x4790 0x100>, <0x3000 0x400>;
>>  reg-names = "qspi_base", "qspi_mmap";
>>  #address-cells = <1>;
>>  #size-cells = <0>;

and how does the user for this look like ? Don't you need to give this a
proper 'ranges' binding ?

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH] dmaengine: edma: Add dummy driver skeleton for edma3-tptc

[Felipe Balbi]

Peter Ujfalusi  writes:

> The eDMA3 TPTC does not need any software configuration, but it is a
> separate IP block in the SoC. In order the omap hwmod core to be able to
> handle the TPTC resources correctly in regards of PM we need to have a
> driver loaded for it.
> This patch will add a dummy driver skeleton without probe or remove
> callbacks provided.
>
> Signed-off-by: Peter Ujfalusi 
> Reported-by: Olof Johansson 

This fixes the problem I also reported on linux-omap [1]

Tested-by: Felipe Balbi 

[1] http://marc.info/?l=linux-omap&m=144665429032014&w=2

> ---
> Hi,
>
> while it would have been possible to add the edma3-tptc compatible to be 
> handled
> by the edma-tpcc driver (and when the device is tptc, do nothing) it would
> make the driver code a bit harder to follow.
> I think having separate structure for the tptc looks better and if we ever 
> need
> to have separate driver for the tptc it will be cleaner for us the separate 
> it.
>
> This patch alone w/o any hwmod flag changes will make sure that the edma-tptc 
> is
> not powered down after the kernel is finished it's booting.
>
> Regards,
> Peter
>
>  drivers/dma/edma.c | 19 +++
>  1 file changed, 19 insertions(+)
>
> diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
> index 31722d436a42..6b03e4e84e6b 100644
> --- a/drivers/dma/edma.c
> +++ b/drivers/dma/edma.c
> @@ -269,6 +269,11 @@ static const struct of_device_id edma_of_ids[] = {
>   {}
>  };
>  
> +static const struct of_device_id edma_tptc_of_ids[] = {
> + { .compatible = "ti,edma3-tptc", },
> + {}
> +};
> +
>  static inline unsigned int edma_read(struct edma_cc *ecc, int offset)
>  {
>   return (unsigned int)__raw_readl(ecc->base + offset);
> @@ -2399,6 +2404,13 @@ static struct platform_driver edma_driver = {
>   },
>  };
>  
> +static struct platform_driver edma_tptc_driver = {
> + .driver = {
> + .name   = "edma3-tptc",
> + .of_match_table = edma_tptc_of_ids,
> + },
> +};
> +
>  bool edma_filter_fn(struct dma_chan *chan, void *param)
>  {
>   bool match = false;
> @@ -2418,6 +2430,12 @@ EXPORT_SYMBOL(edma_filter_fn);
>  
>  static int edma_init(void)
>  {
> + int ret;
> +
> + ret = platform_driver_register(&edma_tptc_driver);
> + if (ret)
> + return ret;
> +
>   return platform_driver_register(&edma_driver);
>  }
>  subsys_initcall(edma_init);
> @@ -2425,6 +2443,7 @@ subsys_initcall(edma_init);
>  static void __exit edma_exit(void)
>  {
>   platform_driver_unregister(&edma_driver);
> + platform_driver_unregister(&edma_tptc_driver);
>  }
>  module_exit(edma_exit);
>  
> -- 
> 2.6.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH v2 3/4] ARM: dts: DRA7: Add timer12 node

[Felipe Balbi]

Suman Anna  writes:

> Add the DT node for Timer12 present on DRA7 family of
> SoCs. Timer12 is present in PD_WKUPAON power domain, and
> has the same capabilities as the other timers, except for
> the fact that it serves as a secure timer on HS devices
> and is clocked only from the secure 32K clock.
>
> The node is marked disabled for now, and the kernel should
> refrain from using this secure timer on HS devices.
>
> Signed-off-by: Suman Anna 
> ---
>  arch/arm/boot/dts/dra7.dtsi | 10 ++
>  1 file changed, 10 insertions(+)
>
> diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
> index e289c706d27d..37d632dad576 100644
> --- a/arch/arm/boot/dts/dra7.dtsi
> +++ b/arch/arm/boot/dts/dra7.dtsi
> @@ -762,6 +762,16 @@
>   ti,hwmods = "timer11";
>   };
>  
> + timer12: timer@4ae2 {
> + compatible = "ti,omap5430-timer";
> + reg = <0x4ae2 0x80>;
> + interrupts = ;
> + ti,hwmods = "timer12";
> + ti,timer-alwon;
> + ti,timer-secure;
> + status = "disabled";

according to Tony we should avoid using status at all for in-SoC
devices.

Tony, can you confirm I understood you correctly ?

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH 1/3][v4] Documentation: dt: dwc3: Add snps,quirk-frame-length-adjustment property

[Felipe Balbi]

On Thu, Sep 24, 2015 at 09:42:59AM +, RAJESH BHAGAT wrote:
> Hi Felipe, 
> 
> Any comments on the below [v4] patches?
> 
> [PATCH 1/3][v4] Documentation: dt: dwc3: Add 
> snps,quirk-frame-length-adjustment property

https://git.kernel.org/cgit/linux/kernel/git/balbi/usb.git/commit/?h=next&id=3737c54418c35034127bf2837e9b27a3c3c67940

> [PATCH 2/3][v4] drivers: usb: dwc3: Add frame length adjustment quirk

https://git.kernel.org/cgit/linux/kernel/git/balbi/usb.git/commit/?h=next&id=db2be4e9e30c6e43e48c5749d3fc74cee0a6bbb3

> [PATCH 3/3][v4] arm: dts: ls1021a: Add quirk for Erratum A009116

talk to you ARM-SoC maintainer.

> I will be taking forward these patches, as Nikhil has left freescale.

okay, thanks for letting me know.

-- 
balbi


signature.asc
Description: PGP signature

Re: [RFC PATCH 1/2] usb: doc: Add bindings for ULPI platform driver

[Felipe Balbi]

On Thu, Sep 24, 2015 at 11:18:01AM -0500, Rob Herring wrote:
> On Thu, Sep 24, 2015 at 4:26 AM, Subbaraya Sundeep Bhatta
>  wrote:
> > Hi Peter,
> >
> >> -Original Message-
> >> From: Peter Chen [mailto:peter.c...@freescale.com]
> >> Sent: Thursday, September 24, 2015 2:41 PM
> >> To: Subbaraya Sundeep Bhatta
> >> Cc: ba...@ti.com; devicetree@vger.kernel.org; kis...@ti.com;
> >> gre...@linuxfoundation.org; linux-...@vger.kernel.org; linux-
> >> ker...@vger.kernel.org; Punnaiah Choudary Kalluri; Subbaraya Sundeep 
> >> Bhatta;
> >> linux-arm-ker...@lists.infradead.org
> >> Subject: Re: [RFC PATCH 1/2] usb: doc: Add bindings for ULPI platform 
> >> driver
> >>
> >> On Wed, Sep 23, 2015 at 06:24:01PM +0530, Subbaraya Sundeep Bhatta
> >> wrote:
> >> > This patch adds binding doc info for generic ULPI PHYs platform
> >> > driver.
> >> >
> >> > Signed-off-by: Subbaraya Sundeep Bhatta 
> >> > ---
> >> >  .../devicetree/bindings/usb/ulpi-platform-phy.txt  |   34
> >> 
> >> >  1 files changed, 34 insertions(+), 0 deletions(-)  create mode 100644
> >> > Documentation/devicetree/bindings/usb/ulpi-platform-phy.txt
> >> >
> >> > diff --git
> >> > a/Documentation/devicetree/bindings/usb/ulpi-platform-phy.txt
> >> > b/Documentation/devicetree/bindings/usb/ulpi-platform-phy.txt
> >> > new file mode 100644
> >> > index 000..7b8cbb4
> >> > --- /dev/null
> >> > +++ b/Documentation/devicetree/bindings/usb/ulpi-platform-phy.txt
> >> > @@ -0,0 +1,34 @@
> >> > +Platform driver for generic ULPI PHYs
> >> > +
> >> > +Required properties:
> >> > +- compatible   : Should be "ulpi-phy"
> >> > +- reg  : Physical base address and size of the USB
> >> > + controller registers map to which this PHY
> >> > + is connected.
> >> > +- view-port: Should contain viewport register offset of 
> >> > the
> >> > + USB controller to which this PHY is connected 
> >> > Optional
> >> > +properties:
> >> > +- drv-vbus : required if turning VBUS on/off has to be driven
> >> > + by writing to PHY. This feature depends on board
> >> > + design.
> >> > +
> >> > +Example:
> >> > +Below example shows the PHY binding for Chipidea USB controller which
> >> > +has ulpi viewport register at 0x0170
> >> > +
> >> > +   usb_phy0: phy0 {
> >> > +   compatible = "ulpi-phy";
> >> > +   reg = <0xe0002000 0x1000>;
> >> > +   view-port = <0x0170>;
> >> > +   drv-vbus;
> >> > +   };
> >> > +
> >> > +   usb0: usb@e0002000 {
> >> > +compatible = "chipidea,usb2";
> >> > +interrupt-parent = <&intc>;
> >> > +interrupts = <0 21 4>;
> >> > +reg = <0xe0002000 0x1000>;
> >>
> >> Although just call devm_ioremap twice for the same register region does not
> >> cause any errors, I am not sure if it will has other potential problems. 
> >> Cc: arm
> >> list.
> >
> > Yes Peter I was also in doubt to call devm_ioremap twice for same register 
> > region.
> > devm_ioremap_resource complained hence modified to devm_ioremap. Thanks for
> > adding arm-list.
> 
> Don't put overlapping resources in the DT. Having 2 drivers accessing
> the same registers is not a clean or safe design.

thanks, saves me the trouble of saying the same thing.

Bottom line, if devm_ioremap_resource() fails, you're wrong. Just fix
your driver and move on.

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH 6/6] ARM: dts: set up trigger type for edt-ft5x06 interrupts

[Felipe Balbi]

On Sat, Sep 12, 2015 at 10:45:51AM -0700, Dmitry Torokhov wrote:
> Now that the driver respects IRQ trigger settings from device tree, let's
> fix them up in individual DTSes (note that the driver is still compatible
> with older DTSes).
> 
> Signed-off-by: Dmitry Torokhov 
> ---
>  arch/arm/boot/dts/am437x-sk-evm.dts   | 2 +-
>  arch/arm/boot/dts/imx28-tx28.dts  | 3 ++-
>  arch/arm/boot/dts/imx53-tx53-x03x.dts | 3 ++-
>  arch/arm/boot/dts/imx6qdl-tx6.dtsi| 3 ++-
>  4 files changed, 7 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/am437x-sk-evm.dts 
> b/arch/arm/boot/dts/am437x-sk-evm.dts
> index c17097d..d83fdcd 100644
> --- a/arch/arm/boot/dts/am437x-sk-evm.dts
> +++ b/arch/arm/boot/dts/am437x-sk-evm.dts
> @@ -471,7 +471,7 @@
>  
>   reg = <0x38>;
>   interrupt-parent = <&gpio0>;
> - interrupts = <31 0>;
> + interrupts = <31 IRQ_TYPE_EDGE_FALLING>;

for AM437x SK:

Acked-by: Felipe Balbi 

Seems like there are no changes considering driver was always using
IRQF_TRIGGER_FALLING.

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH] of: device: fix NULL pointer dereference on driver removal

[Felipe Balbi]

On Wed, Aug 26, 2015 at 08:14:36AM -0500, Rob Herring wrote:
> On Tue, Aug 25, 2015 at 2:34 PM, Felipe Balbi  wrote:
> > If we don't insert resources into the resource tree,
> > calls to of_platform_depopulate() will end up in NULL
> > pointer dereferences because the resource parent will
> > be set to NULL even though we still have more resources
> > to go through.
> 
> Long standing problem. A fix is in -next now and will go into 4.3 (plus 
> stable):
> 
> commit 11c63e4718acad3d8f04601c80fddd4b3d1455b1
> Author: Grant Likely 
> Date:   Sun Jun 7 15:20:11 2015 +0100
> 
> drivercore: Fix unregistration path of platform devices

that commit works, but too late to add a Tested-by :-)

-- 
balbi


signature.asc
Description: Digital signature

[PATCH] of: device: fix NULL pointer dereference on driver removal

[Felipe Balbi]

If we don't insert resources into the resource tree,
calls to of_platform_depopulate() will end up in NULL
pointer dereferences because the resource parent will
be set to NULL even though we still have more resources
to go through.

Without this patch, the result is as follows:

[   28.238158] Unable to handle kernel NULL pointer dereference at virtual 
address 0008
[   28.246646] pgd = ed3d8000
[   28.249480] [0008] *pgd=
[   28.253247] Internal error: Oops: 5 [#1] SMP ARM
[   28.258072] Modules linked in: input_leds hid_generic usbkbd usbhid
xhci_plat_hcd xhci_hcd usbcore joydev dwc3 udc_core usb_common m25p80 evdev 
spi_nor omapfb cfbfillrect cfbimg blt cpufreq_dt cfbcopyarea thermal_sys 
snd_soc_simple_card leds_gpio matrix_keypad pwm_bl hwmon led_class 
matrix_keymap panel_dpi snd_soc_tlv320aic3x snd_soc_davinci_mcasp snd_soc_edma 
snd_soc_omap snd_soc_core omapdss snd_compress snd_pcm_dmaengine snd_pcm 
dwc3_omap(-) extcon snd_timer pwm_tiecap snd lis3lv02d_i2c lis3lv02d soundcore 
input_polldev rtc_omap spi_ti_qspi tps65218_pwrbutton omap_wdt phy_omap_usb2 
autofs4
[   28.313186] CPU: 0 PID: 289 Comm: modprobe Not tainted 
4.2.0-rc7-next-20150824-2-g5681a109a938-dirty #1093
[   28.323643] Hardware name: Generic AM43 (Flattened Device Tree)
[   28.329836] task: ed39d180 ti: ed076000 task.ti: ed076000
[   28.335496] PC is at __release_resource+0x30/0x13c
[   28.340501] LR is at __release_resource+0x24/0x13c
[   28.345501] pc : []lr : []psr: 600d0013
[   28.345501] sp : ed077e98  ip : 0007  fp : befb3e14
[   28.357487] r10:   r9 : ed076000  r8 : c000f724
[   28.362941] r7 :   r6 : ee6f9800  r5 : ed268d40  r4 : c094679c
[   28.369755] r3 :   r2 : 00f4  r1 : c0648b34  r0 : 0045
[   28.376560] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM Segment user
[   28.384008] Control: 10c5387d  Table: ad3d8059  DAC: 0015
[   28.390005] Process modprobe (pid: 289, stack limit = 0xed076218)
[   28.396375] Stack: (0xed077e98 to 0xed078000)
[   28.400924] 7e80: ed268d40 
[   28.409455] 7ea0: befb3e14 c0640838 0001 c094679c ed268d40 ee6f9800 
0081 c0043b1c
[   28.417996] 7ec0: 001c 0001 ee6f9800 c03e2674 ee6f9800  
c04d3f20 c03e26ac
[   28.426537] 7ee0: ee6f9810 c04d3fac  c03dcf10 ee1592c0 ed268cf0 
ee170010 ee170010
[   28.435065] 7f00: ee170044 c04d3f08 ed268ed0 bf093208 ee170010 bf093c94 
ee170044 c03e2754
[   28.443607] 7f20: ee170010 bf093c94 ee170044 c03e095c ee170010 bf093c94 
ee170044 c03e116c
[   28.452150] 7f40: bf093c94 7f6232fc 0800 c03e04e4 bf093d00 c00c8a80 
 33637764
[   28.460703] 7f60: 616d6f5f b6f70070 ed39d180  ed076000  
befb3e14 c005be74
[   28.469241] 7f80:  ed076000 7f6232c0 7f6232c0 0001 f67c 
7f6232c0 7f6232c0
[   28.477783] 7fa0: 0001 c000f540 7f6232c0 7f6232c0 7f6232fc 0800 
66d19c00 
[   28.486341] 7fc0: 7f6232c0 7f6232c0 0001 0081  0001 
7f6232c0 befb3e14
[   28.494903] 7fe0: b6f1c2e1 befb2a3c 7f60638f b6f1c2e6 800d0030 7f6232fc 
 
[   28.503476] [] (__release_resource) from [] 
(release_resource+0x30/0x54)
[   28.512299] [] (release_resource) from [] 
(platform_device_del+0x70/0x9c)
[   28.521218] [] (platform_device_del) from [] 
(platform_device_unregister+0xc/0x20)
[   28.530962] [] (platform_device_unregister) from [] 
(of_platform_device_destroy+0x8c/0x98)
[   28.541425] [] (of_platform_device_destroy) from [] 
(device_for_each_child+0x50/0x7c)
[   28.551430] [] (device_for_each_child) from [] 
(of_platform_depopulate+0x2c/0x44)
[   28.561101] [] (of_platform_depopulate) from [] 
(dwc3_omap_remove+0x3c/0x5c [dwc3_omap])
[   28.571390] [] (dwc3_omap_remove [dwc3_omap]) from [] 
(platform_drv_remove+0x18/0x30)
[   28.581387] [] (platform_drv_remove) from [] 
(__device_release_driver+0x88/0x114)
[   28.591023] [] (__device_release_driver) from [] 
(driver_detach+0xb4/0xb8)
[   28.600014] [] (driver_detach) from [] 
(bus_remove_driver+0x4c/0xa0)
[   28.608485] [] (bus_remove_driver) from [] 
(SyS_delete_module+0x11c/0x1e4)
[   28.617518] [] (SyS_delete_module) from [] 
(ret_fast_syscall+0x0/0x54)
[   28.626172] Code: eb0354bf e5957010 e3a020f4 e59f10f0 (e5973008)
[   28.632722] ---[ end trace d2a21fc5d73a2dfd ]---

Cc: 
Signed-off-by: Felipe Balbi 
---

very easy to trigger with 'modprobe -r dwc3-omap' on any of TI's platform
sporting dwc3

 drivers/of/device.c | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/drivers/of/device.c b/drivers/of/device.c
index 8b91ea241b10..c03600c08207 100644
--- a/drivers/of/device.c
+++ b/drivers/of/device.c
@@ -53,6 +53,8 @@ EXPORT_SYMBOL(of_dev_put);
 
 int of_device_add(struct platform_device *ofdev)
 {
+   int i;
+
BUG_ON(ofdev->dev.of_node == NULL);
 
/* name and id have to be set so that the platform bus doesn't get
@@ -66,6 +68,27 @@ int of_device_add(struct platfo

Re: [PATCH 1/8] ARM: dts: AM4372: Reorder the rtc compatible string

[Felipe Balbi]

On Thu, Aug 06, 2015 at 06:55:57AM +0530, Keerthy wrote:
> 
> 
> On Wednesday 05 August 2015 10:21 PM, Felipe Balbi wrote:
> >On Wed, Aug 05, 2015 at 09:48:08PM +0530, Keerthy wrote:
> >>
> >>
> >>On Wednesday 05 August 2015 09:44 PM, Felipe Balbi wrote:
> >>>On Wed, Aug 05, 2015 at 09:21:05PM +0530, Keerthy wrote:
> >>>>Felipe,
> >>>>
> >>>>On Wednesday 05 August 2015 09:01 PM, Felipe Balbi wrote:
> >>>>>On Wed, Aug 05, 2015 at 04:19:45PM +0530, Keerthy wrote:
> >>>>>>Compared to da830-rtc compatibility am3352-rtc is more compatible to
> >>>>>>the one in am437x. Hence adding the am3352-rtc compatible to cover the
> >>>>>>entire feature set.
> >>>>>>
> >>>>>>The ti,am4372-rtc has no Documentation and not used even in the driver
> >>>>>>hence removing it.
> >>>>>
> >>>>>why don't you do the inverse ? Document am4372-rtc and make driver use
> >>>>>it ?
> >>>>
> >>>>am3352-rtc suffices for am4372 too. No need to add additional one for
> >>>>am4372.
> >>>
> >>>Until we end up needing it, right ? :-)
> >>>
> >>>Besides, it's already used in a DTS. What happens if someone branched
> >>>from that DTS and ships that in a product. RTC will just stop working
> >>>for them. Sure, it wasn't documented, but that's a problem of commit
> >>>73456012734b80442b33916406cfd13bf1b73acb (ARM: dts: AM4372: add few
> >>>nodes) which, essentially, added that compatible flag without
> >>>documenting it.
> >>>
> >>>BTW, this compatible has been in tree since August 2013, IMO it's unfar
> >>>to drop it just like that. Documenting it would be a better approach.
> >>
> >>Okay. Can you point me to a file which is already accessing it in dts?
> >
> >Accessing what ? Also, once DTS reaches a major kernel release, it's
> >deemed stable and should be supported. Are we dropping that ?
> 
> I meant getting used in any other dts files than the one i just dropped it.

how can you ever know that for sure ? There are already quite a few
third party platforms based on AM437x, how can you be sure those
companies don't have their own DTS ?

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH 1/8] ARM: dts: AM4372: Reorder the rtc compatible string

[Felipe Balbi]

On Wed, Aug 05, 2015 at 09:48:08PM +0530, Keerthy wrote:
> 
> 
> On Wednesday 05 August 2015 09:44 PM, Felipe Balbi wrote:
> >On Wed, Aug 05, 2015 at 09:21:05PM +0530, Keerthy wrote:
> >>Felipe,
> >>
> >>On Wednesday 05 August 2015 09:01 PM, Felipe Balbi wrote:
> >>>On Wed, Aug 05, 2015 at 04:19:45PM +0530, Keerthy wrote:
> >>>>Compared to da830-rtc compatibility am3352-rtc is more compatible to
> >>>>the one in am437x. Hence adding the am3352-rtc compatible to cover the
> >>>>entire feature set.
> >>>>
> >>>>The ti,am4372-rtc has no Documentation and not used even in the driver
> >>>>hence removing it.
> >>>
> >>>why don't you do the inverse ? Document am4372-rtc and make driver use
> >>>it ?
> >>
> >>am3352-rtc suffices for am4372 too. No need to add additional one for
> >>am4372.
> >
> >Until we end up needing it, right ? :-)
> >
> >Besides, it's already used in a DTS. What happens if someone branched
> >from that DTS and ships that in a product. RTC will just stop working
> >for them. Sure, it wasn't documented, but that's a problem of commit
> >73456012734b80442b33916406cfd13bf1b73acb (ARM: dts: AM4372: add few
> >nodes) which, essentially, added that compatible flag without
> >documenting it.
> >
> >BTW, this compatible has been in tree since August 2013, IMO it's unfar
> >to drop it just like that. Documenting it would be a better approach.
> 
> Okay. Can you point me to a file which is already accessing it in dts?

Accessing what ? Also, once DTS reaches a major kernel release, it's
deemed stable and should be supported. Are we dropping that ?

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH 1/8] ARM: dts: AM4372: Reorder the rtc compatible string

[Felipe Balbi]

On Wed, Aug 05, 2015 at 09:21:05PM +0530, Keerthy wrote:
> Felipe,
> 
> On Wednesday 05 August 2015 09:01 PM, Felipe Balbi wrote:
> >On Wed, Aug 05, 2015 at 04:19:45PM +0530, Keerthy wrote:
> >>Compared to da830-rtc compatibility am3352-rtc is more compatible to
> >>the one in am437x. Hence adding the am3352-rtc compatible to cover the
> >>entire feature set.
> >>
> >>The ti,am4372-rtc has no Documentation and not used even in the driver
> >>hence removing it.
> >
> >why don't you do the inverse ? Document am4372-rtc and make driver use
> >it ?
> 
> am3352-rtc suffices for am4372 too. No need to add additional one for
> am4372.

Until we end up needing it, right ? :-)

Besides, it's already used in a DTS. What happens if someone branched
from that DTS and ships that in a product. RTC will just stop working
for them. Sure, it wasn't documented, but that's a problem of commit
73456012734b80442b33916406cfd13bf1b73acb (ARM: dts: AM4372: add few
nodes) which, essentially, added that compatible flag without
documenting it.

BTW, this compatible has been in tree since August 2013, IMO it's unfar
to drop it just like that. Documenting it would be a better approach.

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH 2/7] phy: ti-pipe3: use ti_pipe3_power_off to power off the PHY during probe

[Felipe Balbi]

On Wed, Aug 05, 2015 at 07:42:24PM +0530, Kishon Vijay Abraham I wrote:
> Hi,
> 
> On Tuesday 04 August 2015 09:36 PM, Felipe Balbi wrote:
> > On Tue, Aug 04, 2015 at 08:50:41PM +0530, Kishon Vijay Abraham I wrote:
> >> No functional change. Previously omap_control_phy_power() was used to power
> > 
> > there is a slight functional change. You moved PHY power off from before
> > to after pm_runtime_enable(), clk_prepare_enable() and creation of the
> > PHY device. That ought to have a slight impact on how the driver
> > behaves.
> 
> okay. I'll modify the commit log. I think it won't impact the functionality as
> such since the ->init and ->power_on callbacks won't be invoked at that point.

all right, then

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH 1/8] ARM: dts: AM4372: Reorder the rtc compatible string

[Felipe Balbi]

On Wed, Aug 05, 2015 at 04:19:45PM +0530, Keerthy wrote:
> Compared to da830-rtc compatibility am3352-rtc is more compatible to
> the one in am437x. Hence adding the am3352-rtc compatible to cover the
> entire feature set.
> 
> The ti,am4372-rtc has no Documentation and not used even in the driver
> hence removing it.

why don't you do the inverse ? Document am4372-rtc and make driver use
it ?

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH 5/7] phy: omap-usb2: use omap_usb_power_off to power off the PHY during probe

[Felipe Balbi]

On Tue, Aug 04, 2015 at 08:50:44PM +0530, Kishon Vijay Abraham I wrote:
> No functional change. Previously omap_control_phy_power() was used to power

same comment as before.

> off the PHY during probe. But once phy-omap-usb2 driver is adapted to
> use syscon, omap_control_phy_power() cannot be used. Hence used
> omap_usb_power_off to power off the PHY.
> 
> Signed-off-by: Kishon Vijay Abraham I 
> Acked-by: Roger Quadros 
> ---
>  drivers/phy/phy-omap-usb2.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/phy/phy-omap-usb2.c b/drivers/phy/phy-omap-usb2.c
> index c1a4686..b5c266a 100644
> --- a/drivers/phy/phy-omap-usb2.c
> +++ b/drivers/phy/phy-omap-usb2.c
> @@ -241,7 +241,6 @@ static int omap_usb2_probe(struct platform_device *pdev)
>   }
>  
>   phy->control_dev = &control_pdev->dev;
> - omap_control_phy_power(phy->control_dev, 0);
>  
>   otg->set_host   = omap_usb_set_host;
>   otg->set_peripheral = omap_usb_set_peripheral;
> @@ -261,6 +260,7 @@ static int omap_usb2_probe(struct platform_device *pdev)
>   }
>  
>   phy_set_drvdata(generic_phy, phy);
> + omap_usb_power_off(generic_phy);
>  
>   phy_provider = devm_of_phy_provider_register(phy->dev,
>   of_phy_simple_xlate);
> -- 
> 1.7.9.5
> 

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH 2/7] phy: ti-pipe3: use ti_pipe3_power_off to power off the PHY during probe

[Felipe Balbi]

On Tue, Aug 04, 2015 at 08:50:41PM +0530, Kishon Vijay Abraham I wrote:
> No functional change. Previously omap_control_phy_power() was used to power

there is a slight functional change. You moved PHY power off from before
to after pm_runtime_enable(), clk_prepare_enable() and creation of the
PHY device. That ought to have a slight impact on how the driver
behaves.

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH 1/7] phy: ti-pipe3: cleanup ti_pipe3_probe()

[Felipe Balbi]

On Tue, Aug 04, 2015 at 08:50:40PM +0530, Kishon Vijay Abraham I wrote:
> No functional change. Add separate functions for pll,
> clocks and syscon to make ti_pipe3_probe clean.
> 
> Signed-off-by: Kishon Vijay Abraham I 

I think this needs to be splitted into smaller patches.

Seems like the very first patch would be to introduce a local struct
device pointer to be used. Than add each and every new function on their
own patch. This will help big time making your refactoring a lot clearer
and, should anything go wrong, we can atomically revert a specific
change, instead of loosing the entire refactor.

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH] usb: musb: omap2430: use *syscon* framework API to write to mailbox register

[Felipe Balbi]

Hi,

On Tue, Aug 04, 2015 at 07:36:09PM +0530, Kishon Vijay Abraham I wrote:
> Deprecate using phy-omap-control driver to write to the mailbox register
> and start using *syscon* framework to do the same.
> 
> Signed-off-by: Kishon Vijay Abraham I 
> ---
>  Documentation/devicetree/bindings/usb/omap-usb.txt |7 +-
>  drivers/usb/musb/omap2430.c|  115 
> 
>  2 files changed, 99 insertions(+), 23 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt 
> b/Documentation/devicetree/bindings/usb/omap-usb.txt
> index 38d9bb8..c001306 100644
> --- a/Documentation/devicetree/bindings/usb/omap-usb.txt
> +++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
> @@ -20,10 +20,15 @@ OMAP MUSB GLUE
>   - phy-names : the names of the PHY corresponding to the PHYs present in the
> *phy* phandle.
>  
> -Optional properties:
> +Optional Properties:
> +Deprecated properties:
>   - ctrl-module : phandle of the control module this glue uses to write to
> mailbox
>  
> +Recommended properies:
> + - syscon-otghs : phandle/offset pair. Phandle to the system control module 
> and the
> +   register offset of the mailbox.
> +
>  SOC specific device node entry
>  usb_otg_hs: usb_otg_hs@4a0ab000 {
>   compatible = "ti,omap4-musb";
> diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
> index 70f2b8a..a03cf1e 100644
> --- a/drivers/usb/musb/omap2430.c
> +++ b/drivers/usb/musb/omap2430.c
> @@ -39,16 +39,27 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>  
>  #include "musb_core.h"
>  #include "omap2430.h"
>  
> +#define OMAP2430_MUSB_MODE_MASK  0x1f
> +#define OMAP2430_MUSB_AVALID BIT(0)
> +#define OMAP2430_MUSB_BVALID BIT(1)
> +#define OMAP2430_MUSB_VBUSVALID  BIT(2)
> +#define OMAP2430_MUSB_SESSENDBIT(3)
> +#define OMAP2430_MUSB_IDDIG  BIT(4)
> +
>  struct omap2430_glue {
>   struct device   *dev;
>   struct platform_device  *musb;
>   enum omap_musb_vbus_id_status status;
>   struct work_struct  omap_musb_mailbox_work;
>   struct device   *control_otghs;
> + struct regmap   *syscon_otghs; /* ctrl. reg. acces */
> + unsigned intotghs_reg; /* otghs reg. index within syscon */
>  };
>  #define glue_to_musb(g)  platform_get_drvdata(g->musb)
>  
> @@ -253,6 +264,44 @@ void omap_musb_mailbox(enum omap_musb_vbus_id_status 
> status)
>  }
>  EXPORT_SYMBOL_GPL(omap_musb_mailbox);
>  
> +static void omap2430_musb_set_usbmode(struct omap2430_glue *glue,
> +   enum omap_control_usb_mode mode)
> +{
> + u32 val;
> + int ret;
> +

if (!glue->syscon_otghs) {
omap_control_usb_set_mode(glue->control_otghs, mode);
return;
}

switch (mode) {
case USB_MODE_HOST:
val = OMAP2430_MUSB_AVALID | OMAP2430_MUSB_VBUSVALID;
break;
case USB_MODE_DEVICE:
val = OMAP2430_MUSB_IDDIG | OMAP2430_MUSB_AVALID |
OMAP2430_MUSB_VBUSVALID;
break;
case USB_MODE_DISCONNECT:
val = OMAP2430_MUSB_IDDIG | OMAP2430_MUSB_SESSEND;
break;
default:
dev_dbg(glue->dev, "Invalid mode\n");
dev_err(glue->dev, "Failed to set mode to %d\n", mode);
}

ret = regmap_update_bits(glue->syscon_otghs,
 glue->otghs_reg,
 OMAP2430_MUSB_MODE_MASK, val);
if (ret < 0)
dev_err(glue->dev, "Failed to update regmap\n");

other than that, looks fine.

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH v8 00/23] usb gadget update for OTG 2.0

[Felipe Balbi]

On Tue, Aug 04, 2015 at 08:00:31AM +0800, Li Jun wrote:
> On Thu, Jul 30, 2015 at 09:10:06AM -0500, Felipe Balbi wrote:
> > On Thu, Jul 30, 2015 at 09:46:58AM +0800, Li Jun wrote:
> > > On Wed, Jul 29, 2015 at 09:11:41PM -0500, Felipe Balbi wrote:
> > > > On Thu, Jul 30, 2015 at 07:24:03AM +0800, Li Jun wrote:
> > > > > On Wed, Jul 29, 2015 at 10:04:27AM -0500, Felipe Balbi wrote:
> > > > > > On Mon, Jul 27, 2015 at 03:21:59PM +0800, Peter Chen wrote:
> > > > > > > On Thu, Jul 23, 2015 at 11:37:24AM +0800, Li Jun wrote:
> > > > > > > > Change for v8:
> > > > > > > > - Add Peter's ACk for chipidea driver; and Roger's Reviewed-by 
> > > > > > > > for patch
> > > > > > > >   07, 21~23.
> > > > > > > > - Add ci->is_otg condition before enable ci->gadget.is_otg for 
> > > > > > > > chipidea
> > > > > > > >   driver in patch 8.
> > > > > > > > 
> > > > > > > 
> > > > > > > Hi Felipe,
> > > > > > > 
> > > > > > > For chipidea patches in this series, help to queue them in your 
> > > > > > > tree 
> > > > > > > please, thanks.
> > > > > > 
> > > > > > all there, please make sure they're correct. There were so many 
> > > > > > versions
> > > > > > of this series that I might have picked up the wrong one :-p
> > > > > > 
> > > > > 
> > > > > Patch [8/23]: "usb: chipidea: set usb otg capabilities", you picked 
> > > > > up the V7,
> > > > > I have a small change for V8, others are correct.
> > > > 
> > > > Can you send an incremental diff, please ?
> > > > 
> > > 
> > > diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
> > > index 61fde89..c6d1595 100644
> > > --- a/drivers/usb/chipidea/udc.c
> > > +++ b/drivers/usb/chipidea/udc.c
> > > @@ -1838,8 +1838,8 @@ static int udc_start(struct ci_hdrc *ci)
> > >   ci->gadget.name = ci->platdata->name;
> > >   ci->gadget.otg_caps = otg_caps;
> > >  
> > > - if (otg_caps->hnp_support || otg_caps->srp_support ||
> > > - otg_caps->adp_support)
> > > + if (ci->is_otg && (otg_caps->hnp_support || otg_caps->srp_support ||
> > > + otg_caps->adp_support))
> > >   ci->gadget.is_otg = 1;
> > >  
> > >   INIT_LIST_HEAD(&ci->gadget.ep_list);
> > 
> > I need it as a real patch with Signed-off-by and all, so I can apply :-)
> > 
> Hi Felipe,
> 
> I have sent it out as a formal patch for this incremental diff, but still not
> in your next tree.

it's in testing/next :-) I should be able to merge that back into next
today.

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH v8 00/23] usb gadget update for OTG 2.0

[Felipe Balbi]

On Thu, Jul 30, 2015 at 09:46:58AM +0800, Li Jun wrote:
> On Wed, Jul 29, 2015 at 09:11:41PM -0500, Felipe Balbi wrote:
> > On Thu, Jul 30, 2015 at 07:24:03AM +0800, Li Jun wrote:
> > > On Wed, Jul 29, 2015 at 10:04:27AM -0500, Felipe Balbi wrote:
> > > > On Mon, Jul 27, 2015 at 03:21:59PM +0800, Peter Chen wrote:
> > > > > On Thu, Jul 23, 2015 at 11:37:24AM +0800, Li Jun wrote:
> > > > > > Change for v8:
> > > > > > - Add Peter's ACk for chipidea driver; and Roger's Reviewed-by for 
> > > > > > patch
> > > > > >   07, 21~23.
> > > > > > - Add ci->is_otg condition before enable ci->gadget.is_otg for 
> > > > > > chipidea
> > > > > >   driver in patch 8.
> > > > > > 
> > > > > 
> > > > > Hi Felipe,
> > > > > 
> > > > > For chipidea patches in this series, help to queue them in your tree 
> > > > > please, thanks.
> > > > 
> > > > all there, please make sure they're correct. There were so many versions
> > > > of this series that I might have picked up the wrong one :-p
> > > > 
> > > 
> > > Patch [8/23]: "usb: chipidea: set usb otg capabilities", you picked up 
> > > the V7,
> > > I have a small change for V8, others are correct.
> > 
> > Can you send an incremental diff, please ?
> > 
> 
> diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
> index 61fde89..c6d1595 100644
> --- a/drivers/usb/chipidea/udc.c
> +++ b/drivers/usb/chipidea/udc.c
> @@ -1838,8 +1838,8 @@ static int udc_start(struct ci_hdrc *ci)
>   ci->gadget.name = ci->platdata->name;
>   ci->gadget.otg_caps = otg_caps;
>  
> - if (otg_caps->hnp_support || otg_caps->srp_support ||
> - otg_caps->adp_support)
> + if (ci->is_otg && (otg_caps->hnp_support || otg_caps->srp_support ||
> + otg_caps->adp_support))
>   ci->gadget.is_otg = 1;
>  
>   INIT_LIST_HEAD(&ci->gadget.ep_list);

I need it as a real patch with Signed-off-by and all, so I can apply :-)

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH v8 00/23] usb gadget update for OTG 2.0

[Felipe Balbi]

On Thu, Jul 30, 2015 at 07:24:03AM +0800, Li Jun wrote:
> On Wed, Jul 29, 2015 at 10:04:27AM -0500, Felipe Balbi wrote:
> > On Mon, Jul 27, 2015 at 03:21:59PM +0800, Peter Chen wrote:
> > > On Thu, Jul 23, 2015 at 11:37:24AM +0800, Li Jun wrote:
> > > > Change for v8:
> > > > - Add Peter's ACk for chipidea driver; and Roger's Reviewed-by for patch
> > > >   07, 21~23.
> > > > - Add ci->is_otg condition before enable ci->gadget.is_otg for chipidea
> > > >   driver in patch 8.
> > > > 
> > > 
> > > Hi Felipe,
> > > 
> > > For chipidea patches in this series, help to queue them in your tree 
> > > please, thanks.
> > 
> > all there, please make sure they're correct. There were so many versions
> > of this series that I might have picked up the wrong one :-p
> > 
> 
> Patch [8/23]: "usb: chipidea: set usb otg capabilities", you picked up the V7,
> I have a small change for V8, others are correct.

Can you send an incremental diff, please ?

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH v8 00/23] usb gadget update for OTG 2.0

[Felipe Balbi]

On Mon, Jul 27, 2015 at 03:21:59PM +0800, Peter Chen wrote:
> On Thu, Jul 23, 2015 at 11:37:24AM +0800, Li Jun wrote:
> > Change for v8:
> > - Add Peter's ACk for chipidea driver; and Roger's Reviewed-by for patch
> >   07, 21~23.
> > - Add ci->is_otg condition before enable ci->gadget.is_otg for chipidea
> >   driver in patch 8.
> > 
> 
> Hi Felipe,
> 
> For chipidea patches in this series, help to queue them in your tree 
> please, thanks.

all there, please make sure they're correct. There were so many versions
of this series that I might have picked up the wrong one :-p

cheers

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH 1/3] Documentation: dt: dwc3: Add snps,configure-fladj property

[Felipe Balbi]

On Thu, Jul 23, 2015 at 11:07:09AM +, Badola Nikhil wrote:
> > -Original Message-
> > From: Mark Rutland [mailto:mark.rutl...@arm.com]
> > Sent: Thursday, July 23, 2015 4:27 PM
> > To: Badola Nikhil-B46172
> > Cc: linux-ker...@vger.kernel.org; devicetree@vger.kernel.org; ba...@ti.com
> > Subject: Re: [PATCH 1/3] Documentation: dt: dwc3: Add snps,configure-fladj
> > property
> > 
> > On Thu, Jul 23, 2015 at 11:52:19AM +0100, Badola Nikhil wrote:
> > > > -Original Message-
> > > > From: Mark Rutland [mailto:mark.rutl...@arm.com]
> > > > Sent: Thursday, July 23, 2015 3:27 PM
> > > > To: Badola Nikhil-B46172
> > > > Cc: linux-ker...@vger.kernel.org; devicetree@vger.kernel.org;
> > > > ba...@ti.com
> > > > Subject: Re: [PATCH 1/3] Documentation: dt: dwc3: Add
> > > > snps,configure-fladj property
> > > >
> > > > On Thu, Jul 23, 2015 at 11:09:21AM +0100, Nikhil Badola wrote:
> > > > > Add property snps,configure-fladj for enabling post silicon frame
> > > > > length adjustment
> > > > >
> > > > > Signed-off-by: Nikhil Badola 
> > > > > ---
> > > > >  Documentation/devicetree/bindings/usb/dwc3.txt | 1 +
> > > > >  1 file changed, 1 insertion(+)
> > > > >
> > > > > diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt
> > > > > b/Documentation/devicetree/bindings/usb/dwc3.txt
> > > > > index 0815eac..90c3972 100644
> > > > > --- a/Documentation/devicetree/bindings/usb/dwc3.txt
> > > > > +++ b/Documentation/devicetree/bindings/usb/dwc3.txt
> > > > > @@ -40,6 +40,7 @@ Optional properties:
> > > > >   - snps,hird-threshold: HIRD threshold
> > > > >   - snps,hsphy_interface: High-Speed PHY interface selection
> > > > > between
> > > > "utmi" for
> > > > > UTMI+ and "ulpi" for ULPI when the DWC_USB3_HSPHY_INTERFACE
> > > > > has
> > > > value 3.
> > > > > + - snps,configure-fladj: enables post-silicon frame length
> > > > > + adjustment
> > > >
> > > > Could you elaborate on what this means and why you think it's
> > necessary?
> > >
> > > This property enables the use of GFLADJ_30MHZ field value of gfladj
> > > register for frame length adjustment instead of considering from the
> > sideband input signal fladj_30mhz_reg from SOC.
> > > This is required when signal fladj_30mhz_reg is connected to a wrong
> > > value or is not valid as in our case, hence post-silicon.
> > 
> > Ok, so this is basically an override for the GFLADJ_30MHZ field of the 
> > gfladj
> > register when there was a problem at integration time.
> >
> 
> That's right. 
>  
> > > However this field can be used to adjust any offset ranging from 00h
> > > to 3Fh, from the clock source generating SOF(start of frame) packets.
> > > Thus, this property can be added to device tree with appropriate
> > adjustment value.
> > 
> > It takes a value? The description above makes it sound like a boolean
> > property.
> > 
> > I'd expect a description more like:
> > 
> > - snps,fladj-override: Value for GFLADJ_30MHZ when the fladj_30mhz_reg
> >   signal is invalid or incorrect.
> > 
> > Which makes it clear what the value is and when it should be set.
> 
> Agreed. Will change and send a new version of the patch-set.

BTW, I'm not going to accept this without a glue layer making use of it.
Also, this patch needs to go to linux-usb as well, please resend.

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH v7 08/23] usb: chipidea: set usb otg capabilities

[Felipe Balbi]

On Mon, Jul 13, 2015 at 09:03:14AM +0800, Peter Chen wrote:
> On Thu, Jul 09, 2015 at 09:22:09PM +0800, Li Jun wrote:
> > On Thu, Jul 09, 2015 at 11:57:39AM +0300, Roger Quadros wrote:
> > > Hi,
> > > 
> > > On 09/07/15 10:18, Li Jun wrote:
> > > > Init and update otg capabilities by DT, set gadget's otg capabilities
> > > > accordingly.
> > > > 
> > > > Signed-off-by: Li Jun 
> > > > ---
> > > >  drivers/usb/chipidea/core.c  | 15 +++
> > > >  drivers/usb/chipidea/udc.c   |  7 ++-
> > > >  include/linux/usb/chipidea.h |  1 +
> > > >  3 files changed, 22 insertions(+), 1 deletion(-)
> > > > 
> > > > diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
> > > > index 74fea4f..1e6d5f0 100644
> > > > --- a/drivers/usb/chipidea/core.c
> > > > +++ b/drivers/usb/chipidea/core.c
> > > > @@ -560,6 +560,8 @@ static irqreturn_t ci_irq(int irq, void *data)
> > > >  static int ci_get_platdata(struct device *dev,
> > > > struct ci_hdrc_platform_data *platdata)
> > > >  {
> > > > +   int ret;
> > > > +
> > > > if (!platdata->phy_mode)
> > > > platdata->phy_mode = of_usb_get_phy_mode(dev->of_node);
> > > >  
> > > > @@ -588,6 +590,19 @@ static int ci_get_platdata(struct device *dev,
> > > > of_usb_host_tpl_support(dev->of_node);
> > > > }
> > > >  
> > > > +   if (platdata->dr_mode == USB_DR_MODE_OTG) {
> > > > +   /* We can support HNP and SRP of OTG 2.0 */
> > > > +   platdata->ci_otg_caps.otg_rev = 0x0200;
> > > > +   platdata->ci_otg_caps.hnp_support = true;
> > > > +   platdata->ci_otg_caps.srp_support = true;
> > > > +
> > > > +   /* Update otg capabilities by DT properties */
> > > > +   ret = of_usb_update_otg_caps(dev->of_node,
> > > > +   &platdata->ci_otg_caps);
> > > > +   if (ret)
> > > > +   return ret;
> > > > +   }
> > > > +
> > > > if (of_usb_get_maximum_speed(dev->of_node) == USB_SPEED_FULL)
> > > > platdata->flags |= CI_HDRC_FORCE_FULLSPEED;
> > > >  
> > > > diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
> > > > index 764f668..b7cca3e 100644
> > > > --- a/drivers/usb/chipidea/udc.c
> > > > +++ b/drivers/usb/chipidea/udc.c
> > > > @@ -1827,6 +1827,7 @@ static irqreturn_t udc_irq(struct ci_hdrc *ci)
> > > >  static int udc_start(struct ci_hdrc *ci)
> > > >  {
> > > > struct device *dev = ci->dev;
> > > > +   struct usb_otg_caps *otg_caps = &ci->platdata->ci_otg_caps;
> > > > int retval = 0;
> > > >  
> > > > spin_lock_init(&ci->lock);
> > > > @@ -1834,8 +1835,12 @@ static int udc_start(struct ci_hdrc *ci)
> > > > ci->gadget.ops  = &usb_gadget_ops;
> > > > ci->gadget.speed= USB_SPEED_UNKNOWN;
> > > > ci->gadget.max_speed= USB_SPEED_HIGH;
> > > > -   ci->gadget.is_otg   = ci->is_otg ? 1 : 0;
> > > > ci->gadget.name = ci->platdata->name;
> > > > +   ci->gadget.otg_caps = otg_caps;
> > > > +
> > > > +   if (otg_caps->hnp_support || otg_caps->srp_support ||
> > > > +   otg_caps->adp_support)
> > > > +   ci->gadget.is_otg = 1;
> > > 
> > > It seems there are non OTG capable dual-role only ci controllers as well
> > > looking at ci_get_otg_capable() code.
> > > 
> > > If so then this should be
> > >   if (ci->is_otg && (otg_caps->hnp_support || otg_caps->srp_support ||
> > >  otg_caps->adp_support))
> > >   ci->gadget.is_otg = 1
> > > 
> > > cheers,
> > > -roger
> > > 
> > Seems it was in my previous version but dropped it by mistake later,
> > I will add it.
> > 
> 
> 
> After you adding roger's comments, add my ack.
> 
> Acked-by: Peter Chen 

am I getting a new version for this patch ?

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH v7 00/23] usb gadget update for OTG 2.0

[Felipe Balbi]

On Thu, Jul 09, 2015 at 03:18:37PM +0800, Li Jun wrote:
> Change for v7:
> - Free otg descriptor when failure of bind in patch 21, 22, 23.
>   add Roger's Reviewed-by for patch 10~20.
> - Choose the lesser otg-rev if otg-rev has been set before update by DT,
>   remove 0x0300 in supported otg-rev list, and add code comments in case
>   otg-rev is not passed in DT in patch 7.
> - Fail chipidea usb initilization if DT pass an unsupported otg-rev in patch 
> 8.
> 
> Change for v6:
> - Change of_usb_set_otg_caps to be of_usb_update_otg_caps, and add
>   sanity check of otg-rev.
> - Add chipidea otg-rev ability to be 0x0200, which will be updated
>   in DT, if not passed, will be reset to be 0.
> - Remove unnecessary change: move config's descriptor and bmAttributes
>   init from xxxi_config() to xxx_bind() in leagcy gadget drivers.
> 
> This is a follow-up of Macpaul Lin's previous patchset to resolve usb
> gadget driver working with OTG 2.0, and set otg features by not only
> usb driver config but also usb hardware property in DT, main changes:
> 1. Add usb_otg20_descriptor definition for OTG 2.0 which introduces bcdOTG
>field for otg revision, bcdOTG can be passed via device tree.
> 2. OTG features(SRP/HNP/ADP) can be decided by combination of usb HW
>properties and usb driver config.
> 3. Change the chipidea usb driver to use the updated mechanism.
> 4. Remove static usb otg descriptor definition, but allocate and init it
>according to otg capabilities in each gadget driver, if otg capabilities
>is not defined for legacy platforms, the usb otg descriptor content is
>kept the same as current static definition.
> 
> Li Jun (19):
>   usb: otg: add usb_otg_caps structure for otg capabilities
>   doc: dt-binding: usb: add otg related properties
>   usb: common: add API to update usb otg capabilities by device tree
>   usb: chipidea: set usb otg capabilities
>   usb: chipidea: update ci_otg_is_fsm_mode conditions
>   usb: gadget: add usb otg descriptor allocate and init interface
>   usb: gadget: configfs: allocate and init otg descriptor by otg
> capabilities
>   usb: gadget: ether: allocate and init otg descriptor by otg
> capabilities
>   usb: gadget: acm_ms: allocate and init otg descriptor by otg
> capabilities
>   usb: gadget: audio: allocate and init otg descriptor by otg
> capabilities
>   usb: gadget: cdc2: allocate and init otg descriptor by otg
> capabilities
>   usb: gadget: g_ffs: allocate and init otg descriptor by otg
> capabilities
>   usb: gadget: hid: allocate and init otg descriptor by otg capabilities
>   usb: gadget: mass_storage: allocate and init otg descriptor by otg
> capabilities
>   usb: gadget: multi: allocate and init otg descriptor by otg
> capabilities
>   usb: gadget: ncm: allocate and init otg descriptor by otg capabilities
>   usb: gadget: printer: allocate and init otg descriptor by otg
> capabilities
>   usb: gadget: serial: allocate and init otg descriptor by otg
> capabilities
>   usb: gadget: zero: allocate and init otg descriptor by otg
> capabilities
> 
> Macpaul Lin (4):
>   usb: add usb_otg20_descriptor for OTG 2.0 and above
>   usb: add USB_OTG_ADP definition
>   usb: add usb_otg_caps to usb_gadget structure.
>   usb: gadget: composite: add USB_DT_OTG request handling

ok, so how you guys want to handle this series ? Should I take
everything through my tree ? I'd need Acked-by for all chipidea drivers
if that's the case.

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH v3 3/5] usb: phy: add usb3.0 phy driver for mt65xx SoCs

[Felipe Balbi]

Hi,

On Wed, Jul 22, 2015 at 10:05:43PM +0800, Chunfeng Yun wrote:
> support usb3.0 phy of mt65xx SoCs
> 
> Signed-off-by: Chunfeng Yun 

you missed Kishon here.

> ---
>  drivers/phy/Kconfig   |   9 +
>  drivers/phy/Makefile  |   1 +
>  drivers/phy/phy-mt65xx-usb3.c | 426 
> ++
>  3 files changed, 436 insertions(+)
>  create mode 100644 drivers/phy/phy-mt65xx-usb3.c
> 
> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> index c0e6ede..019cf8b 100644
> --- a/drivers/phy/Kconfig
> +++ b/drivers/phy/Kconfig
> @@ -193,6 +193,15 @@ config PHY_HIX5HD2_SATA
>   help
> Support for SATA PHY on Hisilicon hix5hd2 Soc.
>  
> +config PHY_MT65XX_USB3
> + tristate "Mediatek USB3.0 PHY Driver"
> + depends on ARCH_MEDIATEK && OF
> + select GENERIC_PHY
> + help
> +   Say 'Y' here to add support for Mediatek USB3.0 PHY driver
> +   for mt65xx SoCs. it supports two usb2.0 ports and
> +   one usb3.0 port.
> +
>  config PHY_SUN4I_USB
>   tristate "Allwinner sunxi SoC USB PHY driver"
>   depends on ARCH_SUNXI && HAS_IOMEM && OF
> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
> index f344e1b..3ceff2a 100644
> --- a/drivers/phy/Makefile
> +++ b/drivers/phy/Makefile
> @@ -22,6 +22,7 @@ obj-$(CONFIG_TI_PIPE3)  += 
> phy-ti-pipe3.o
>  obj-$(CONFIG_TWL4030_USB)+= phy-twl4030-usb.o
>  obj-$(CONFIG_PHY_EXYNOS5250_SATA)+= phy-exynos5250-sata.o
>  obj-$(CONFIG_PHY_HIX5HD2_SATA)   += phy-hix5hd2-sata.o
> +obj-$(CONFIG_PHY_MT65XX_USB3)+= phy-mt65xx-usb3.o
>  obj-$(CONFIG_PHY_SUN4I_USB)  += phy-sun4i-usb.o
>  obj-$(CONFIG_PHY_SUN9I_USB)  += phy-sun9i-usb.o
>  obj-$(CONFIG_PHY_SAMSUNG_USB2)   += phy-exynos-usb2.o
> diff --git a/drivers/phy/phy-mt65xx-usb3.c b/drivers/phy/phy-mt65xx-usb3.c
> new file mode 100644
> index 000..5da4534
> --- /dev/null
> +++ b/drivers/phy/phy-mt65xx-usb3.c
> @@ -0,0 +1,426 @@
> +/*
> + * Copyright (c) 2015 MediaTek Inc.
> + * Author: Chunfeng.Yun 
> + *
> + * This software is licensed under the terms of the GNU General Public
> + * License version 2, as published by the Free Software Foundation, and
> + * may be copied, distributed, and modified under those terms.
> + *
> + * 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 
> +
> +/*
> + * for sifslv2 register
> + * relative to USB3_SIF2_BASE base address
> + */
> +#define SSUSB_SIFSLV_SPLLC   (0x)
> +#define SSUSB_SIFSLV_U2PHY_COM_BASE  (0x0800)
> +#define SSUSB_SIFSLV_U3PHYD_BASE (0x0900)
> +#define SSUSB_USB30_PHYA_SIV_B_BASE  (0x0b00)
> +#define SSUSB_SIFSLV_U3PHYA_DA_BASE  (0x0c00)
> +
> +/*port1 refs. +0x800(refer to port0)*/
> +#define U3P_PORT_INTERVAL (0x800)/*based on port0 */
> +#define U3P_PHY_DELTA(index) ((U3P_PORT_INTERVAL) * (index))
> +
> +#define U3P_USBPHYACR0   (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x)
> +#define PA0_RG_U2PLL_FORCE_ON(0x1 << 15)
> +
> +#define U3P_USBPHYACR2   (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x0008)
> +#define PA2_RG_SIF_U2PLL_FORCE_EN(0x1 << 18)
> +
> +#define U3P_USBPHYACR5   (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x0014)
> +#define PA5_RG_U2_HSTX_SRCTRL(0x7 << 12)
> +#define PA5_RG_U2_HSTX_SRCTRL_VAL(x) ((0x7 & (x)) << 12)
> +#define PA5_RG_U2_HS_100U_U3_EN  (0x1 << 11)
> +
> +#define U3P_USBPHYACR6   (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x0018)
> +#define PA6_RG_U2_ISO_EN (0x1 << 31)
> +#define PA6_RG_U2_BC11_SW_EN (0x1 << 23)
> +#define PA6_RG_U2_OTG_VBUSCMP_EN (0x1 << 20)
> +
> +#define U3P_U2PHYACR4(SSUSB_SIFSLV_U2PHY_COM_BASE + 0x0020)
> +#define P2C_RG_USB20_GPIO_CTL(0x1 << 9)
> +#define P2C_USB20_GPIO_MODE  (0x1 << 8)
> +#define P2C_U2_GPIO_CTR_MSK  (P2C_RG_USB20_GPIO_CTL | P2C_USB20_GPIO_MODE)
> +
> +#define U3D_U2PHYDCR0(SSUSB_SIFSLV_U2PHY_COM_BASE + 0x0060)
> +#define P2C_RG_SIF_U2PLL_FORCE_ON(0x1 << 24)
> +
> +#define U3P_U2PHYDTM0(SSUSB_SIFSLV_U2PHY_COM_BASE + 0x0068)
> +#define P2C_FORCE_UART_EN(0x1 << 26)
> +#define P2C_FORCE_DATAIN (0x1 << 23)
> +#define P2C_FORCE_DM_PULLDOWN(0x1 << 21)
> +#define P2C_FORCE_DP_PULLDOWN(0x1 << 20)
> +#define P2C_FORCE_XCVRSEL(0x1 << 19)
> +#define P2C_FORCE_SUSPENDM   (0x1 << 18)
> +#define P2C_FORCE_TERMSEL(0x1 << 17)
> +#define P2C_RG_DATAIN(0xf << 10)
> +#define P2C_RG_DATAIN_VAL(x) ((0xf & (x)) << 10)
> +#define P2C_RG_DMPULLDOWN(0x1 << 7)
> +#define P2C_RG_DPPULLDOWN(0x1 << 6)
> +#define P2C_RG_XCVRSEL   (0x3 

Re: [PATCH] usb: phy: msm: Add D+/D- lines route control

[Felipe Balbi]

On Wed, Jul 08, 2015 at 12:45:54PM +0300, Ivan T. Ivanov wrote:
> apq8016-sbc board is using Dual SPDT USB Switch (TC7USB40MU),
> witch is controlled by GPIO to de/multiplex D+/D- USB lines to
> USB2513B Hub and uB connector. Add support for this.
> 
> Signed-off-by: Ivan T. Ivanov 

doesn't apply:

checking file Documentation/devicetree/bindings/usb/msm-hsusb.txt
checking file drivers/usb/phy/phy-msm-usb.c
Hunk #5 succeeded at 1632 (offset 2 lines).
Hunk #6 succeeded at 1809 (offset 2 lines).
Hunk #7 FAILED at 1844.
1 out of 7 hunks FAILED
checking file include/linux/usb/msm_hsusb.h

Please rebase on my testing/next

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH v5 1/3] musb: sunxi: Add support for the Allwinner sunxi musb controller

[Felipe Balbi]

On Sat, Jun 13, 2015 at 02:42:08PM +0200, Hans de Goede wrote:
> This is based on initial code to get the Allwinner sunxi musb controller
> supported by Chen-Yu Tsai and Roman Byshko.
> 
> This adds support for the Allwinner sunxi musb controller in both host only
> and otg mode. Peripheral only mode is not supported, as no boards use that.
> 
> This has been tested on a cubietruck (A20 SoC) and an UTOO P66 tablet
> (A13 SoC) with a variety of devices in host mode and with the g_serial gadget
> driver in peripheral mode, plugging otg / host cables in/out a lot of times
> in all possible imaginable plug orders.
> 
> Signed-off-by: Hans de Goede 
> ---
> Changes in v2:
> -Move polling of id and vbus-det gpio-s to the phy driver
> -Use extcon to get id (USB_HOST mode) status changes from the phy driver
> -Stop using syscon, instead use Maxime Ripard's sunxi SRAM controller driver
> Changes in v3:
> -Check that USB_MUSB_FOO config is compatible with the dr_mode setting from dt
> Changes in v4:
> -Squash in "musb: sunxi: Add pre/post root reset end platform functions" patch
> -Adjust for sunxi_sram controller driver changes
> -Stop musb work from turning vbus off again when in host mode
> Changes in v5:
> -Squash in "musb: sunxi: Remove special MUSB_SUN4I flag" patch, as it was
>  mostly revering changes done by this patch
> -Adjust for extcon api changes landing in 4.2

drivers/usb/musb/sunxi.c:75:13: warning: symbol 'sunxi_musb' was not declared. 
Should it be static?
drivers/usb/musb/sunxi.c:151:6: warning: symbol 'sunxi_musb_pre_root_reset_end' 
was not declared. Should it be static?
drivers/usb/musb/sunxi.c:158:6: warning: symbol 
'sunxi_musb_post_root_reset_end' was not declared. Should it be static?

please fix.

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH 0/3] dwc2 patches to allow wakeup on Rockchip rk3288

[Felipe Balbi]

On Mon, Jul 06, 2015 at 11:06:35AM -0700, Doug Anderson wrote:
> Felipe,
> 
> On Mon, Jul 6, 2015 at 10:48 AM, Felipe Balbi  wrote:
> > On Mon, Jun 22, 2015 at 04:52:21PM -0700, Douglas Anderson wrote:
> >> This series of patches, together with
> >> <https://patchwork.kernel.org/patch/6652341/> from Chris Zhong and a
> >> dts change allow us to wake up from a USB device on rk3288 boards.
> >> The patches were tested on rk3288-jerry in the chromeos-3.14 kernel.
> >> The chromeos-3.14 kernel tested included a full set of dwc2 backports
> >> from upstream, so this is expected to function upstream once we get
> >> everything setup there.
> >>
> >>
> >> Douglas Anderson (3):
> >>   USB: Export usb_wakeup_enabled_descendants()
> >>   Documentation: dt-bindings: Add snps,need-phy-for-wake for dwc2 USB
> >
> > I didn't get 2/3 :-(
> 
> Odd.  I'm happy to repost the series, but you were certainly on the
> "To" for the whole series.  You can see the Headers at
> <https://patchwork.kernel.org/patch/6658421/>
> 
> ...please let me know if you'd like me to repost and we can hope the
> email system works better next time...

If you can, that would help me. Just make sure to Cc linux-usb on all
patches, since that's where I tend to get my patches from.

Thanks and sorry for the extra step resending this.

ps: dropping Paul Z as he's not in SNPS anymore

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH 0/3] dwc2 patches to allow wakeup on Rockchip rk3288

[Felipe Balbi]

On Mon, Jun 22, 2015 at 04:52:21PM -0700, Douglas Anderson wrote:
> This series of patches, together with
>  from Chris Zhong and a
> dts change allow us to wake up from a USB device on rk3288 boards.
> The patches were tested on rk3288-jerry in the chromeos-3.14 kernel.
> The chromeos-3.14 kernel tested included a full set of dwc2 backports
> from upstream, so this is expected to function upstream once we get
> everything setup there.
> 
> 
> Douglas Anderson (3):
>   USB: Export usb_wakeup_enabled_descendants()
>   Documentation: dt-bindings: Add snps,need-phy-for-wake for dwc2 USB

I didn't get 2/3 :-(

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH v2 01/20] ARM: omap2plus_defconfig: Enable audio related config options

[Felipe Balbi]

On Thu, Jul 02, 2015 at 05:06:16PM +0300, Peter Ujfalusi wrote:
> More and more boards are moving to have audio support via simple-card.
> At the same time enable options needed for most am335x and am43xx board for
> audio support: McASP and TLV320AIC3X codecs.
> The later two has been selected by the CONFIG_SND_AM33XX_SOC_EVM option, but
> the aim is to convert all boards to use simple card.
> 
> Signed-off-by: Peter Ujfalusi 

Acked-by: Felipe Balbi 

> ---
>  arch/arm/configs/omap2plus_defconfig | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/arch/arm/configs/omap2plus_defconfig 
> b/arch/arm/configs/omap2plus_defconfig
> index ac521e764d10..b001f7ae67f3 100644
> --- a/arch/arm/configs/omap2plus_defconfig
> +++ b/arch/arm/configs/omap2plus_defconfig
> @@ -324,10 +324,13 @@ CONFIG_SND_USB_AUDIO=m
>  CONFIG_SND_SOC=m
>  CONFIG_SND_EDMA_SOC=m
>  CONFIG_SND_AM33XX_SOC_EVM=m
> +CONFIG_SND_DAVINCI_SOC_MCASP=m
>  CONFIG_SND_OMAP_SOC=m
>  CONFIG_SND_OMAP_SOC_OMAP_TWL4030=m
>  CONFIG_SND_OMAP_SOC_OMAP_ABE_TWL6040=m
>  CONFIG_SND_OMAP_SOC_OMAP3_PANDORA=m
> +CONFIG_SND_SIMPLE_CARD=m
> +CONFIG_SND_SOC_TLV320AIC3X=m
>  CONFIG_HID_GENERIC=m
>  CONFIG_USB_HIDDEV=y
>  CONFIG_USB_KBD=m
> -- 
> 2.4.5
> 

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH 2/2] ARM: DTS: am437x-sk-evm: Switch using simple-audio-card for audio support

[Felipe Balbi]

On Thu, Jul 02, 2015 at 03:52:49PM +0300, Peter Ujfalusi wrote:
> On 07/02/2015 03:23 PM, Felipe Balbi wrote:
> > On Thu, Jul 02, 2015 at 02:58:06PM +0300, Peter Ujfalusi wrote:
> >> The sound support consist only Headset output on the board and can be
> >> handled by "simple-audio-card"
> >>
> >> Signed-off-by: Peter Ujfalusi 
> > 
> > Still works fine:
> > 
> > Tested-by: Felipe Balbi 
> > 
> > one question though, should Line In be listed below ?
> 
> Does the board have Line-in? I don't have the board, but I know this patch

yeah, it does :-)

> works on it ;)
> We only had playback path before also.

indeed, should go for -next only :-s

> > Also, unrelated to
> > $subject, but if I wait for a few seconds between runs of speaker-test
> > (iow, if I allow mcasp to idle) then I hear a slight chopping sound when
> > starting, perhaps we're unmuting too early ?
> 
> Is it only with this patch (via simple-card) or was it the same via the
> davinci-evm (ti,da830-evm-audio)?

/me goes test again

also without this patch :-)

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH 2/2] ARM: DTS: am437x-sk-evm: Switch using simple-audio-card for audio support

[Felipe Balbi]

On Thu, Jul 02, 2015 at 02:58:06PM +0300, Peter Ujfalusi wrote:
> The sound support consist only Headset output on the board and can be
> handled by "simple-audio-card"
> 
> Signed-off-by: Peter Ujfalusi 

Still works fine:

Tested-by: Felipe Balbi 

one question though, should Line In be listed below ? Also, unrelated to
$subject, but if I wait for a few seconds between runs of speaker-test
(iow, if I allow mcasp to idle) then I hear a slight chopping sound when
starting, perhaps we're unmuting too early ?

> ---
>  arch/arm/boot/dts/am437x-sk-evm.dts | 30 ++
>  1 file changed, 22 insertions(+), 8 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/am437x-sk-evm.dts 
> b/arch/arm/boot/dts/am437x-sk-evm.dts
> index b5de6b0d622c..e09216cb14df 100644
> --- a/arch/arm/boot/dts/am437x-sk-evm.dts
> +++ b/arch/arm/boot/dts/am437x-sk-evm.dts
> @@ -32,14 +32,26 @@
>   };
>  
>   sound {
> - compatible = "ti,da830-evm-audio";
> - ti,model = "AM437x-SK-EVM";
> - ti,audio-codec = <&tlv320aic3106>;
> - ti,mcasp-controller = <&mcasp1>;
> - ti,codec-clock-rate = <2400>;
> - ti,audio-routing =
> - "Headphone Jack",   "HPLOUT",
> - "Headphone Jack",   "HPROUT";
> + compatible = "simple-audio-card";
> + simple-audio-card,name = "AM437x-SK-EVM";
> + simple-audio-card,widgets =
> + "Headphone", "Headphone Jack";
> + simple-audio-card,routing =
> + "Headphone Jack",   "HPLOUT",
> + "Headphone Jack",   "HPROUT";
> + simple-audio-card,format = "dsp_b";
> + simple-audio-card,bitclock-master = <&sound_master>;
> + simple-audio-card,frame-master = <&sound_master>;
> + simple-audio-card,bitclock-inversion;
> +
> + simple-audio-card,cpu {
> + sound-dai = <&mcasp1>;
> + };
> +
> + sound_master: simple-audio-card,codec {
> + sound-dai = <&tlv320aic3106>;
> + system-clock-frequency = <2400>;
> + };
>   };
>  
>   matrix_keypad: matrix_keypad@0 {
> @@ -489,6 +501,7 @@
>   };
>  
>   tlv320aic3106: tlv320aic3106@1b {
> + #sound-dai-cells = <0>;
>   compatible = "ti,tlv320aic3106";
>   reg = <0x1b>;
>   status = "okay";
> @@ -649,6 +662,7 @@
>  };
>  
>  &mcasp1 {
> + #sound-dai-cells = <0>;
>   pinctrl-names = "default", "sleep";
>   pinctrl-0 = <&mcasp1_pins>;
>   pinctrl-1 = <&mcasp1_pins_sleep>;
> -- 
> 2.4.5
> 

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH 1/2] ARM: DTS: am437x-sk-evm: Add sleep pin settings for mcasp1

[Felipe Balbi]

On Thu, Jul 02, 2015 at 02:58:05PM +0300, Peter Ujfalusi wrote:
> When McASP is not in use the pins can be put to sleep mode to conserve
> power.
> 
> Signed-off-by: Peter Ujfalusi 

Tested-by: Felipe Balbi 

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH 0/2] ARM: DTS: am437x-sk-evm: Use simple-card for audio support

[Felipe Balbi]

Hi,

On Thu, Jul 02, 2015 at 02:58:04PM +0300, Peter Ujfalusi wrote:
> Hi,
> 
> There is no reason to use the davinci-evm machine driver's compatible for 
> audio
> support since the setup is simple and the common simple-audio-card can handle 
> it
> just fine.
> Also add McASP1 sleep pin configuration.
> 
> Regards,
> Peter
> ---
> Peter Ujfalusi (2):
>   ARM: DTS: am437x-sk-evm: Add sleep pin settings for mcasp1
>   ARM: DTS: am437x-sk-evm: Switch using simple-audio-card for audio
> support

you should add a patch enabling CONFIG_SND_SIMPLE_CARD=m in
omap2plus_defconfig

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH 2/2] ARM: dts: am4372: Add emif node

[Felipe Balbi]

On Wed, May 06, 2015 at 12:25:33PM -0500, Dave Gerlach wrote:
> Add node for TI AM4372 EMIF.
> 
> Signed-off-by: Dave Gerlach 

Tony, this patch fixes the regression I just reported at [1], care to
pick this one up ?

Tested-by: Felipe Balbi 
Acked-by: Felipe Balbi 

[1] http://marc.info/?l=linux-omap&m=143327283632248&w=2

> ---
>  Documentation/devicetree/bindings/memory-controllers/ti/emif.txt | 1 +
>  arch/arm/boot/dts/am4372.dtsi| 6 ++
>  2 files changed, 7 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/memory-controllers/ti/emif.txt 
> b/Documentation/devicetree/bindings/memory-controllers/ti/emif.txt
> index 938f8e1..0db6047 100644
> --- a/Documentation/devicetree/bindings/memory-controllers/ti/emif.txt
> +++ b/Documentation/devicetree/bindings/memory-controllers/ti/emif.txt
> @@ -8,6 +8,7 @@ of the EMIF IP and memory parts attached to it.
>  Required properties:
>  - compatible : Should be of the form "ti,emif-" where 
>is the IP revision of the specific EMIF instance.
> +   For am437x should be ti,emif-am4372.
>  
>  - phy-type   :  indicating the DDR phy type. Following are the
>allowed values
> diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
> index c80a3e2..9521a38 100644
> --- a/arch/arm/boot/dts/am4372.dtsi
> +++ b/arch/arm/boot/dts/am4372.dtsi
> @@ -132,6 +132,12 @@
>   };
>   };
>  
> + emif: emif@4c00 {
> + compatible = "ti,emif-am4372";
> + reg = <0x4c00 0x100>;
> + ti,hwmods = "emif";
> + };
> +
>   edma: edma@4900 {
>   compatible = "ti,edma3";
>   ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2";
> -- 
> 2.3.6
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH v4 2/2] musb: Add support for the Allwinner sunxi musb controller

[Felipe Balbi]

On Sun, May 31, 2015 at 06:10:26PM +0200, Hans de Goede wrote:
> This is based on initial code to get the Allwinner sunxi musb controller
> supported by Chen-Yu Tsai and Roman Byshko.
> 
> This adds support for the Allwinner sunxi musb controller in both host only
> and otg mode. Peripheral only mode is not supported, as no boards use that.
> 
> This has been tested on a cubietruck (A20 SoC) and an UTOO P66 tablet
> (A13 SoC) with a variety of devices in host mode and with the g_serial gadget
> driver in peripheral mode, plugging otg / host cables in/out a lot of times
> in all possible imaginable plug orders.
> 
> Signed-off-by: Hans de Goede 

this looks good, I'd say it's ready for v4.3

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH v4 0/2] Remaining sunxi musb patches

[Felipe Balbi]

Hi,

On Tue, Jun 02, 2015 at 09:14:05AM +0200, Hans de Goede wrote:
> >>>Here is an updated version of the remaining (not yet merged in Felipe's
> >>>tree)
> >>>sunxi musb patches.
> >>>
> >>>The "phy-sun4i-usb: Add full support for usb0 phy / OTG" patch has been
> >>>updated with a small bug-fix and is ready for merging.
> >>>
> >>>The "musb: Add support for the Allwinner sunxi musb" patch has been
> >>>updated
> >>>to use the latest version of Maxime's sunxi sram controller driver. This
> >>>one has a compile-time dependency on Maxime's sunxi sram controller
> >>>driver,
> >>>so it cannot be merged until that is merged.
> >>>
> >>
> >>
> >>Arnd has just merged the updated sram controller into the next branch
> >>of the soc-drivers repo, so both these patches are now ready to merge.
> >
> >all right, so for v4.3 merge window there will be no issues in queues
> >the two remaining patches. Thanks
> 
> So I take it that it is too late to get these 2 into 4.2 ? I've a bunch
> of (small) follow up patches coming up to enable support for the musb
> controller on new boards, merging those would be easier if these were
> already merged. And there also is a largish set of sunxi dts patches
> actually enabling the musb code which is sorta waiting for merging
> these 2 (waiting for the dt binding to be stable).

DTS should not have to wait. If we know what the compatible should look
like, you can send your DTS upstream no problem. There will just be a
few devices which will not trigger a driver probe, but that's just fine.

> If this is not going to make 4.2, can you and Kishon at least review
> them and let me know of they will get merged for 4.3 as is (baring
> any merge issues) ?

Sure, that I can do, no issues.

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH v4 0/2] Remaining sunxi musb patches

[Felipe Balbi]

On Mon, Jun 01, 2015 at 11:30:45AM -0700, Hans de Goede wrote:
> Hi,
> 
> On Sunday, May 31, 2015 at 6:10:32 PM UTC+2, Hans de Goede wrote:
> >
> > Hi Kishon & Felipe, 
> >
> > Here is an updated version of the remaining (not yet merged in Felipe's 
> > tree) 
> > sunxi musb patches. 
> >
> > The "phy-sun4i-usb: Add full support for usb0 phy / OTG" patch has been 
> > updated with a small bug-fix and is ready for merging. 
> >
> > The "musb: Add support for the Allwinner sunxi musb" patch has been 
> > updated 
> > to use the latest version of Maxime's sunxi sram controller driver. This 
> > one has a compile-time dependency on Maxime's sunxi sram controller 
> > driver, 
> > so it cannot be merged until that is merged. 
> >
> 
> 
> Arnd has just merged the updated sram controller into the next branch
> of the soc-drivers repo, so both these patches are now ready to merge.

all right, so for v4.3 merge window there will be no issues in queues
the two remaining patches. Thanks

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH 4/6] usb: phy: add usb3.0 phy driver for mt65xx SoCs

[Felipe Balbi]

On Wed, May 27, 2015 at 07:48:01PM +0800, chunfeng@mediatek.com wrote:
> From: Chunfeng Yun 
> 
> Signed-off-by: Chunfeng Yun 

no commit log => no commit, sorry. And it's too late for v4.2. I'll
defer this until v4.3

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH 3/6] xhci: probe phy before add usb_hcd

[Felipe Balbi]

On Wed, May 27, 2015 at 07:48:00PM +0800, chunfeng@mediatek.com wrote:
> From: Chunfeng Yun 
> 
> find the phy driver before add primary usb_hcd to avoid acessing
> xHCI register which may hangup the system when the phy is not loaded
> yet and the related powers or clocks put in phy driver are not
> enabled.

it seems like the same clock is needed by PHY and XHCI. This patch looks
incorrect.

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH v2 06/13] musb: Add support for the Allwinner sunxi musb controller

[Felipe Balbi]

On Tue, May 26, 2015 at 06:36:30PM +0200, Hans de Goede wrote:
> Hi,
> 
> On 05/26/2015 05:48 PM, Felipe Balbi wrote:
> >On Fri, Mar 20, 2015 at 08:11:15PM +0100, Hans de Goede wrote:
> >>This is based on initial code to get the Allwinner sunxi musb controller
> >>supported by Chen-Yu Tsai and Roman Byshko.
> >>
> >>This adds support for the Allwinner sunxi musb controller in both host only
> >>and otg mode. Peripheral only mode is not supported, as no boards use that.
> >>
> >>This has been tested on a cubietruck (A20 SoC) and an UTOO P66 tablet
> >>(A13 SoC) with a variety of devices in host mode and with the g_serial 
> >>gadget
> >>driver in peripheral mode, plugging otg / host cables in/out a lot of times
> >>in all possible imaginable plug orders.
> >>
> >>Signed-off-by: Hans de Goede 
> >
> >drivers/usb/musb/sunxi.c:28:11: error: unable to open 
> >'linux/soc/sunxi/sunxi_sram.h'
> >scripts/Makefile.build:264: recipe for target 'drivers/usb/musb/sunxi.o' 
> >failed
> >make[2]: *** [drivers/usb/musb/sunxi.o] Error 1
> >make[2]: *** Waiting for unfinished jobs
> >scripts/Makefile.build:403: recipe for target 'drivers/usb/musb' failed
> >make[1]: *** [drivers/usb/musb] Error 2
> >Makefile:1548: recipe for target 'drivers/usb/' failed
> >make: *** [drivers/usb/] Error 2
> >
> >What is the dependency ?
> 
> Thanks you that you're working on this, the dependency is the sunxi sram
> controller driver which was supposed to get pulled for 4.1, but like many
> other ARM related pull-reqs did not get pulled. And now for 4.2 Arnd
> has decided that he does not like the driver even though it was
> ok for 4.1, and has not yet answered how else we should solve this...
> 
> Arnd, we would really like to move forward with musb support for sunxi
> which means we need a solution for the sram controller, can you please
> answer Maxime's latest mails on this, or accept the driver as is ?

all right, most of the other patches are in my testing/next (please have
a look when you have some extra time) so ony this patch will be pending
for v4.2.

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH v2 06/13] musb: Add support for the Allwinner sunxi musb controller

[Felipe Balbi]

On Fri, Mar 20, 2015 at 08:11:15PM +0100, Hans de Goede wrote:
> This is based on initial code to get the Allwinner sunxi musb controller
> supported by Chen-Yu Tsai and Roman Byshko.
> 
> This adds support for the Allwinner sunxi musb controller in both host only
> and otg mode. Peripheral only mode is not supported, as no boards use that.
> 
> This has been tested on a cubietruck (A20 SoC) and an UTOO P66 tablet
> (A13 SoC) with a variety of devices in host mode and with the g_serial gadget
> driver in peripheral mode, plugging otg / host cables in/out a lot of times
> in all possible imaginable plug orders.
> 
> Signed-off-by: Hans de Goede 

drivers/usb/musb/sunxi.c:28:11: error: unable to open 
'linux/soc/sunxi/sunxi_sram.h'
scripts/Makefile.build:264: recipe for target 'drivers/usb/musb/sunxi.o' failed
make[2]: *** [drivers/usb/musb/sunxi.o] Error 1
make[2]: *** Waiting for unfinished jobs
scripts/Makefile.build:403: recipe for target 'drivers/usb/musb' failed
make[1]: *** [drivers/usb/musb] Error 2
Makefile:1548: recipe for target 'drivers/usb/' failed
make: *** [drivers/usb/] Error 2

What is the dependency ?

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH 1/3] phy-sun4i-usb: Add a sunxi specific function for setting squelch-detect

[Felipe Balbi]

On Sun, Mar 29, 2015 at 12:50:46PM +0200, Hans de Goede wrote:
> The sunxi otg phy has a bug where it wrongly detects a high speed squelch
> when reset on the root port gets de-asserted with a lo-speed device.
> 
> The workaround for this is to disable squelch detect before de-asserting
> reset, and re-enabling it after the reset de-assert is done. Add a sunxi
> specific phy function to allow the sunxi-musb glue to do this.
> 
> Signed-off-by: Hans de Goede 

Kishon, do you want to take this patch?

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH v2 04/13] musb: Do not use musb_read[b|w] / _write[b|w] wrappers in generic fifo functions

[Felipe Balbi]

On Fri, Mar 20, 2015 at 08:11:13PM +0100, Hans de Goede wrote:
> The generic fifo functions already use non wrapped accesses in various
> cases through the iowrite#_rep functions, and all platforms which override
> the default musb_read[b|w] / _write[b|w] functions also provide their own
> fifo access functions, so we can safely drop the unnecessary indirection
> from the fifo access functions.
> 
> Signed-off-by: Hans de Goede 
> ---
>  drivers/usb/musb/musb_core.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
> index 01ed3a6..016b5b9 100644
> --- a/drivers/usb/musb/musb_core.c
> +++ b/drivers/usb/musb/musb_core.c
> @@ -313,7 +313,7 @@ static void musb_default_write_fifo(struct musb_hw_ep 
> *hw_ep, u16 len,
>   index += len & ~0x03;
>   }
>   if (len & 0x02) {
> - musb_writew(fifo, 0, *(u16 *)&src[index]);
> + __raw_writew(*(u16 *)&src[index], fifo);

not all architectures provide __raw_* accessors, right ?

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH] ARM: dts: dra7x-evm: beagle-x14: Fix USB Peripheral

[Felipe Balbi]

Hi,

On Tue, Mar 17, 2015 at 11:43:51AM +0200, Roger Quadros wrote:
> Now that we have EXTCON_USB_GPIO queued for v4.1, revert
> commit addfcde7c485 ("ARM: dts: dra7x-evm: beagle-x15: Fix USB Host")
> 
> On these EVMs, the USB cable state has to be determined via the
> ID pin tied to a GPIO line. We use the gpio-usb-extcon driver
> to read the ID pin and the extcon framework to forward
> the USB cable state information to the USB driver so the
> controller can be configured in the right mode (host/peripheral).
> 
> Gets USB peripheral mode to work on this EVM.
> 
> Signed-off-by: Roger Quadros 

on subject: x14 ? other than that

Reviewed-by: Felipe Balbi 

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH v2 1/4] usb: renesas_usbhs: fix spinlock suspected in a gadget complete function

[Felipe Balbi]

Hi,

On Fri, Mar 13, 2015 at 01:14:01AM +, yoshihiro shimoda wrote:
> > > > diff --git a/drivers/usb/renesas_usbhs/mod_gadget.c 
> > > > b/drivers/usb/renesas_usbhs/mod_gadget.c
> > > > index e0384af77e56..e9d75d85be59 100644
> > > > --- a/drivers/usb/renesas_usbhs/mod_gadget.c
> > > > +++ b/drivers/usb/renesas_usbhs/mod_gadget.c
> > > > @@ -119,7 +119,7 @@ struct usbhsg_recip_handle {
> > > >  /*
> > > >   * queue push/pop
> > > >   */
> > > > -static void usbhsg_queue_pop(struct usbhsg_uep *uep,
> > > > +static void __usbhsg_queue_pop(struct usbhsg_uep *uep,
> > > >  struct usbhsg_request *ureq,
> > > >  int status)
> > > >  {
> > > > @@ -133,6 +133,15 @@ static void usbhsg_queue_pop(struct usbhsg_uep 
> > > > *uep,
> > > > usb_gadget_giveback_request(&uep->ep, &ureq->req);
> > > >  }
> > > >
> > > > +static void usbhsg_queue_pop(struct usbhsg_uep *uep,
> > > > +struct usbhsg_request *ureq,
> > > > +int status)
> > > > +{
> > > > +   usbhs_lock(priv, flags);
> > > > +   __usbhsg_queue_pop(uep, ureq, status);
> > > > +   usbhs_unlock(priv, flags);
> > > > +}
> > > > +
> > > >  static void usbhsg_queue_done(struct usbhs_priv *priv, struct 
> > > > usbhs_pkt *pkt)
> > > >  {
> > > > struct usbhs_pipe *pipe = pkt->pipe;
> > > >
> > > >
> > > > then, for cases where lock is already held you call __usbhsg_queue_pop()
> > > > and for all other cases, call usbhsg_queue_pop().
> > >
> > > Thank you for the suggestion. However, we cannot use this
> > > usbhsg_queue_pop() because a gadget driver might call usb_ep_queue()
> > > in the "complete" function and this driver calls usbhs_lock() in the
> > > usb_ep_queue().
> > 
> > right, in that case just call __usbhs_queue_pop() directly.
> 
> Yes. So, my understanding is that this driver always calls __usbhs_queue_pop()
> because this driver cannot know that a gadget driver calls usb_ep_queue() or 
> not
> in the "complete" function.

but you don't need to know that. All you have to do is spin_unlock()
before calling usb_gadget_giveback_request(), look at
drivers/usb/dwc3/gadget.c::dwc3_gadget_giveback()

> > > Perhaps my explanation was bad, but this issue was caused by the
> > > following conditions:
> > >  - I use the renesas_usbhs driver as udc.
> > >  - I use an old usb-dmac driver that the callback runs on a kthread.
> > >  - I use the ncm driver. In this environment, the ncm driver might
> > >   cause a spinlock suspected.
> > >
> > > As an old solution, I fixed the renesas_usbhs driver by this patch.
> > > However, if I use a new usb-dmac driver that the callback runs on a
> > > tasklet, I don't need this patch. (This is a new solution.)
> > 
> > then differentiate based on some revision register or something like
> > that ?
> 
> Sorry for the lack information. I am submitting this usb-dmac driver that
> the callback runs on a tasklet now. This means that the driver is not
> merged yet. So, I think that we don't need to differentiate.

But as soon as your driver gets merged, you will need to differentiate,
right ?

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH v2 1/4] usb: renesas_usbhs: fix spinlock suspected in a gadget complete function

[Felipe Balbi]

Hi,

On Thu, Mar 12, 2015 at 05:40:56AM +, yoshihiro shimoda wrote:
> Hi,
> 
> > On Thu, Mar 12, 2015 at 04:33:41AM +, yoshihiro shimoda wrote:
> > > Hi Geert-san again,
> > >
> > > > Hi Geert-san,
> > > >
> > > > Thank you for the reply again!
> > > >
> > > > > Hi Shimoda-san,
> > > > >
> > > > > On Mon, Feb 16, 2015 at 2:52 AM, Yoshihiro Shimoda
> > > > >  wrote:
> > > > > > According to the gadget.h, a "complete" function will always be 
> > > > > > called
> > > > > > with interrupts disabled. However, sometimes usbhsg_queue_pop() 
> > > > > > function
> > > > > > is called with interrupts enabled. So, this function should calls
> > > > > > local_irq_save() before this calls the 
> > > > > > usb_gadget_giveback_request().
> > > > > > Otherwise, there is possible to cause a spinlock suspected in a 
> > > > > > gadget
> > > > > > complete function.
> > > > >
> > > > > I still feel uneasy about adding the call to local_irq_save(), as the 
> > > > > need for
> > > > > this is usually an indicator of another locking problem.
> > > >
> > > > I also think that I would like to avoid using local_irq_save().
> > > > But, I have no idea to resolve this issue for now.
> > >
> > > After I modified usb-dmac driver to use a tasklet instead of a kthread,
> > > this issue disappeared.
> > >
> > > My understanding is the followings:
> > > - According to the backtrace below, during usbhsf_dma_complete() was 
> > > running,
> > >  a softirq happened. After ncm_tx_tasklet() was called, the issue 
> > > happened.
> > > http://thread.gmane.org/gmane.linux.usb.general/122023/focus=43729
> > >
> > > - This means that usbhsf_dma_complete() ran on a kthread. So, ncm driver 
> > > is able
> > >   to do the ncm_tx_tasklet().
> > >
> > > - After the current usb-dmac driver, since usbhsf_dma_complete() runs on 
> > > a tasklet,
> > >   ncm driver is not able to do the ncm_tx_tasklet during 
> > > usbhsf_dma_complete() was running.
> > >
> > >
> > > So, I would like to recall this patch and I will resubmit this patch 
> > > series as v3.
> > 
> > try something like below:
> > 
> > diff --git a/drivers/usb/renesas_usbhs/mod_gadget.c 
> > b/drivers/usb/renesas_usbhs/mod_gadget.c
> > index e0384af77e56..e9d75d85be59 100644
> > --- a/drivers/usb/renesas_usbhs/mod_gadget.c
> > +++ b/drivers/usb/renesas_usbhs/mod_gadget.c
> > @@ -119,7 +119,7 @@ struct usbhsg_recip_handle {
> >  /*
> >   * queue push/pop
> >   */
> > -static void usbhsg_queue_pop(struct usbhsg_uep *uep,
> > +static void __usbhsg_queue_pop(struct usbhsg_uep *uep,
> >  struct usbhsg_request *ureq,
> >  int status)
> >  {
> > @@ -133,6 +133,15 @@ static void usbhsg_queue_pop(struct usbhsg_uep *uep,
> > usb_gadget_giveback_request(&uep->ep, &ureq->req);
> >  }
> > 
> > +static void usbhsg_queue_pop(struct usbhsg_uep *uep,
> > +struct usbhsg_request *ureq,
> > +int status)
> > +{
> > +   usbhs_lock(priv, flags);
> > +   __usbhsg_queue_pop(uep, ureq, status);
> > +   usbhs_unlock(priv, flags);
> > +}
> > +
> >  static void usbhsg_queue_done(struct usbhs_priv *priv, struct usbhs_pkt 
> > *pkt)
> >  {
> > struct usbhs_pipe *pipe = pkt->pipe;
> > 
> > 
> > then, for cases where lock is already held you call __usbhsg_queue_pop()
> > and for all other cases, call usbhsg_queue_pop().
> 
> Thank you for the suggestion. However, we cannot use this
> usbhsg_queue_pop() because a gadget driver might call usb_ep_queue()
> in the "complete" function and this driver calls usbhs_lock() in the
> usb_ep_queue().

right, in that case just call __usbhs_queue_pop() directly.

> Perhaps my explanation was bad, but this issue was caused by the
> following conditions:
>  - I use the renesas_usbhs driver as udc.
>  - I use an old usb-dmac driver that the callback runs on a kthread.
>  - I use the ncm driver. In this environment, the ncm driver might
>   cause a spinlock suspected.
> 
> As an old solution, I fixed the renesas_usbhs driver by this patch.
> However, if I use a new usb-dmac driver that the callback runs on a
> tasklet, I don't need this patch. (This is a new solution.)

then differentiate based on some revision register or something like
that ?

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH v2 1/4] usb: renesas_usbhs: fix spinlock suspected in a gadget complete function

[Felipe Balbi]

Hi,

On Thu, Mar 12, 2015 at 04:33:41AM +, yoshihiro shimoda wrote:
> Hi Geert-san again,
> 
> > Hi Geert-san,
> > 
> > Thank you for the reply again!
> > 
> > > Hi Shimoda-san,
> > >
> > > On Mon, Feb 16, 2015 at 2:52 AM, Yoshihiro Shimoda
> > >  wrote:
> > > > According to the gadget.h, a "complete" function will always be called
> > > > with interrupts disabled. However, sometimes usbhsg_queue_pop() function
> > > > is called with interrupts enabled. So, this function should calls
> > > > local_irq_save() before this calls the usb_gadget_giveback_request().
> > > > Otherwise, there is possible to cause a spinlock suspected in a gadget
> > > > complete function.
> > >
> > > I still feel uneasy about adding the call to local_irq_save(), as the 
> > > need for
> > > this is usually an indicator of another locking problem.
> > 
> > I also think that I would like to avoid using local_irq_save().
> > But, I have no idea to resolve this issue for now.
> 
> After I modified usb-dmac driver to use a tasklet instead of a kthread,
> this issue disappeared.
> 
> My understanding is the followings:
> - According to the backtrace below, during usbhsf_dma_complete() was running,
>  a softirq happened. After ncm_tx_tasklet() was called, the issue happened.
> http://thread.gmane.org/gmane.linux.usb.general/122023/focus=43729
> 
> - This means that usbhsf_dma_complete() ran on a kthread. So, ncm driver is 
> able
>   to do the ncm_tx_tasklet().
> 
> - After the current usb-dmac driver, since usbhsf_dma_complete() runs on a 
> tasklet,
>   ncm driver is not able to do the ncm_tx_tasklet during 
> usbhsf_dma_complete() was running.
> 
> 
> So, I would like to recall this patch and I will resubmit this patch series 
> as v3.

try something like below:

diff --git a/drivers/usb/renesas_usbhs/mod_gadget.c 
b/drivers/usb/renesas_usbhs/mod_gadget.c
index e0384af77e56..e9d75d85be59 100644
--- a/drivers/usb/renesas_usbhs/mod_gadget.c
+++ b/drivers/usb/renesas_usbhs/mod_gadget.c
@@ -119,7 +119,7 @@ struct usbhsg_recip_handle {
 /*
  * queue push/pop
  */
-static void usbhsg_queue_pop(struct usbhsg_uep *uep,
+static void __usbhsg_queue_pop(struct usbhsg_uep *uep,
 struct usbhsg_request *ureq,
 int status)
 {
@@ -133,6 +133,15 @@ static void usbhsg_queue_pop(struct usbhsg_uep *uep,
usb_gadget_giveback_request(&uep->ep, &ureq->req);
 }
 
+static void usbhsg_queue_pop(struct usbhsg_uep *uep,
+struct usbhsg_request *ureq,
+int status)
+{
+   usbhs_lock(priv, flags);
+   __usbhsg_queue_pop(uep, ureq, status);
+   usbhs_unlock(priv, flags);
+}
+
 static void usbhsg_queue_done(struct usbhs_priv *priv, struct usbhs_pkt *pkt)
 {
struct usbhs_pipe *pipe = pkt->pipe;


then, for cases where lock is already held you call __usbhsg_queue_pop()
and for all other cases, call usbhsg_queue_pop().

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH v5 0/5] Add support for Fujitsu USB host controller

[Felipe Balbi]

On Sun, Feb 22, 2015 at 12:25:35PM +0800, Sneeker Yeh wrote:
> These patches add support for XHCI compliant Host controller found
> on Fujitsu Socs, and are based on http://lwn.net/Articles/629162/
> The first patch is to add Fujitsu glue layer of Synopsis DesignWare USB3 
> driver
> and last four patch is about quirk implementation of errata in Synopsis
> DesignWare USB3 IP.
> 
> Patch 1 introduces a quirk with device disconnection management necessary
> Synopsys Designware USB3 IP with versions < 3.00a and hardware configuration
> DWC_USB3_SUSPEND_ON_DISCONNECT_EN=1. It solves a problem where without the
> quirk, that host controller will die after a usb device is disconnected from
> port of root hub.
> 
> Patch 2 is to set Synopsis quirk in xhci platform driver based on xhci 
> platform
> data.
> 
> Patch 3 is to add a revison number 2.90a and 3.00a of Synopsis DesignWare USB3
> IP core driver.
> 
> Patch 4 introduces using a quirk based on a errata of Synopsis
> DesignWare USB3 IP which is versions < 3.00a and has hardware configuration
> DWC_USB3_SUSPEND_ON_DISCONNECT_EN=1, which cannot be read from software. As a
> result this quirk has to be enabled via platform data or device tree.
> 
> Patch 5 introduces Fujitsu Specific Glue layer in Synopsis DesignWare USB3 IP
> driver. 
> 
> Successfully tested on Fujitsu mb86s7x board.
> 
> Changes since v4 (RFC):
> [https://lkml.org/lkml/2015/2/17/13]
>  - based on Felipe's comment, rename dwc3-mb86s70.c to dwc3-fujitsu.c which is
>more generic.
>  - based on Mathias's comment, remove unhelpful comment, and change the
>function name of xhci_try_to_clear_csc() to xhci_late_csc_clear_quirk()
>which is more appropriate.  
> 
> Changes since v3 (RFC):
> [https://lkml.org/lkml/2015/1/25/8]
>  - based on Mathias's comment, fix bug and using xhci_port_state_to_neutral()
>helper function to mask out some RW1C bits, prevent writing back all the
>bits read from the PORTSC register.
> 
> Changes since v2 (RFC):
> [https://lkml.org/lkml/2015/1/19/55]
>  - based on Felipe's comment, re-order patches to avoid breaking 
> bisectability,
>  - based on Felipe's comment, add comment to structure's member, and sort it
>alphabetically,
>  - based on Felipe's comment, add another v2.90 revision number in dwc3 IP.
> 
> Changes since v1 (RFC):
> [https://lkml.org/lkml/2014/12/15/929]
>  - based on Arnd's comment, remove entire unnecessary Fujitsu EHCI/OHCI glue,
>  - based on Felipe's comment, fix mis-using of runtime-pm API and setting dma
>mask, remove unnecessary comment, and refactor suspend/resume handler in
>Fujitsu Specific Glue layer in dwc3,
>  - based on Felipe's comment, add more commit log and comments in Synopsis
>quirk implementation, and separate it into four patches.
> 
> Sneeker Yeh (5):
>   xhci: add a quirk for device disconnection errata for Synopsis
> Designware USB3 core
>   xhci: Platform: Set Synopsis device disconnection quirk based on
> platform data
>   usb: dwc3: add revision number DWC3_REVISION_290A and
> DWC3_REVISION_300A
>   usb: dwc3: Add quirk for Synopsis device disconnection errata
>   usb: dwc3: add Fujitsu Specific Glue layer

Mathias, if you want me to take this series I need your Acked-by,
otherwise I can give you mine, just let me know.

-- 
balbi


signature.asc
Description: Digital signature

Re: SPDX-License-Identifier

[Felipe Balbi]

On Wed, Feb 25, 2015 at 10:49:51PM +0100, Pavel Machek wrote:
> Hi!
> 
> > > >Is one tag per directory sufficient?  Is one tag per file sufficient?
> > > >How about one tag per package?  If package, then isn't a single tag for
> > > >the whole kernel source tree sufficient, as we all know the overall
> > > >license for the kernel source tree.
> > > 
> > > We really need one tag per file.
> > 
> > I fail to see the justification for this, why?  Why not per directory?
> > Why not per function?  Why not per driver?  Why not per line?  Why not
> > per project?  Who has dictated this seemingly arbitrary rule?
> 
> That's how licenses are done today.
> 
> Why would I like to see SPDX?
> 
> So that GPL header at begining of each file becomes one line... and so
> that if it is BSD/GPL dual licensed is plain to see, and I don't have
> to read the notices saying "oh this is gpl.. but if you want to,
> delete gpl above and use license below".

why isn't git grep -e 'MODULE_LICENSE' enough ? It's also a single line
and gives you the license for that driver.

> > Our DCO process ensures that.
> > 
> > > - Some parts of the Linux source code are also used by other projects.
> > >   Or are derived from other projects. Because of this they are
> > >   explicitly licensed under different licenses than the GPLv2
> > >   (compatible to it though of course). Or are dual-licensed. So that
> > >   they can be used by these other projects.
> > 
> > That's fine, we encourage that and want to see that happen.  How will
> > SPDX change that at all?  It's obvious as to the license of the files
> > that this happens with, why do anything extra?
> 
> Well, sometimes parsing license agreements at the top of file is
> interesting, that's where SPDX would help, and that's why having
> single SPDX per linux kernel would not work.

if you can parse SPDX, why can't you parse MODULE_LICENSE() ?

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH v4 4/4] phy: add phy-hi6220-usb

[Felipe Balbi]

On Wed, Feb 25, 2015 at 09:28:36PM +0800, zhangfei wrote:
> +static void hi6220_detect_work(struct work_struct *work)
> +{
> + struct hi6220_priv *priv =
> + container_of(work, struct hi6220_priv, work.work);
> + int gpio_id, gpio_vbus;
> + enum usb_otg_state state;
> +
> + if (!gpio_is_valid(priv->gpio_id) || 
> !gpio_is_valid(priv->gpio_vbus))
> + return;
> +
> + gpio_id = gpio_get_value_cansleep(priv->gpio_id);
> + gpio_vbus = gpio_get_value_cansleep(priv->gpio_vbus);
> >>>
> >>>looks like this should be using extcon
> >>Not used extcon before.
> >>However, we need gpio_vbus interrupt.
> >>Checked phy-tahvo.c and phy-omap-otg.c, not find extcon related with
> >>interrupt.
> >>Will investigate tomorrow.
> >
> >drivers/extcon/extcon-gpio.c
> I think there is no need to use extcon, gpio is clear enough.
> extcon-gpio.c even do not support dt.
> >>>
> >>>well, add DT. The whole idea of free software is that we improve on
> >>>things we already have. EXTCON is *the* API to handle such things.
> >>
> >>I think I am still not understanding extcon-gpio, not sure why need
> >>use this API here.
> >
> >because extcon is the API to use for external connectors. The same way
> >you use regulator framework to control that single GPIO tied to an
> >enable signal of a fixed regulator, you use extcon when you need to read
> >that gpio signal tied to id pin of the USB connector.
> >
> >>Here two gpio requires, one gpio as interrupt, in the interrupt
> >>handler, we detect the gpio status judging the otg status.
> >>extcon-gpio.c use the interrupt, then can we also use the gpio
> >>interrupt.  Using extcon-gpio is used for saving gpio_request?
> >
> >extcon is used to hide gpio_request from dwc2. dwc2 only knows about
> >extcon, not gpios. extcon will request the gpio and use it as interrupt
> >source. When an IRQ fires, it will read the gpio state and decide if it
> >should broadcast a message to tell dwc2 to become host or peripheral.
> 
> Thanks for the kind education, understand now.

hey, no problem ;-)

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH] ARM: dts: am335x-bone*: usb0 is hardwired for peripheral

[Felipe Balbi]

On Tue, Feb 24, 2015 at 10:10:43AM -0600, Robert Nelson wrote:
> Fixes: http://bugs.elinux.org/issues/127
> 
> the bb.org community was seeing random reboots before this change.
> 
> Signed-off-by: Robert Nelson 

that's a dead giveaway considering the connector in the board :-)

Thanks

Reviewed-by: Felipe Balbi 
Acked-by: Felipe Balbi 

> ---
>  arch/arm/boot/dts/am335x-bone-common.dtsi | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi 
> b/arch/arm/boot/dts/am335x-bone-common.dtsi
> index 6cc25ed..2c6248d 100644
> --- a/arch/arm/boot/dts/am335x-bone-common.dtsi
> +++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
> @@ -195,6 +195,7 @@
>  
>  &usb0 {
>   status = "okay";
> + dr_mode = "peripheral";
>  };
>  
>  &usb1 {
> -- 
> 2.1.4
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH v4 4/4] phy: add phy-hi6220-usb

[Felipe Balbi]

Hi,

On Sun, Feb 22, 2015 at 11:10:36AM +0800, zhangfei wrote:
> >>+static void hi6220_start_peripheral(struct hi6220_priv *priv, bool on)
> >>+{
> >>+   struct usb_otg *otg = priv->phy.otg;
> >>+
> >>+   if (!otg->gadget)
> >>+   return;
> >>+
> >>+   if (on)
> >>+   usb_gadget_connect(otg->gadget);
> >>+   else
> >>+   usb_gadget_disconnect(otg->gadget);
> >
> >why is the PHY fiddling with pullups ?
> 
> We use this to enable/disable otg gadget mode.
> >>>
> >>>I got that, but the pullups don't belong to the PHY, they belong to the
> >>>gadget.
> >>>
> The gpio_id & gpio_vbus are used to distinguish otg gadget mode or
> host mode.
> When micro usb or otg device attached to otg, gpio_vbus falling down.
> And gpio_id = 1 is micro usb, gpio_id = 0 is otg device.
> >>>
> >>>all of that I understood clearly :-)
> >>>
> So when micro usb attached, we enable gadget mode; while micro usb
> detached, we disable gadget mode, and dwc2 will automatically set to
> host mode.
> >>>
> >>>that's all fine, I'm concerned about letting the PHY fiddle with
> >>>something it doesn't own. If I am to change pullups rules in udc-core,
> >>>this is likely to break down miserably and I don't want to have to go
> >>>through that.
> >>
> >>Thanks for the clarifying.
> >
> >no problem.
> >
> >>How about using usb_gadget_vbus_connect/disconnect, which are used in many
> >>files under drivers/usb/phy.
> >>There is no vbus_session in dwc2/gadget.c, I thought it would be same as
> >>pullup.
> >>
> >>However, usb_gadget_vbus_connect still need para gadget, where should we put
> >>this file, drivers/usb/phy or drivers/phy
> >
> >drivers/phy, if the framework misses anything you need, it's a great
> >opportunity to give back to the community by extending the framework.
> 
> Sorry, I am a little confused.
> I need some concrete suggestion for the next step of this patch, which is
> required for the community board, hikey board.
> 
> Do you mean in the future we need use hsotg->phy instead of hsotg->uphy.
> struct phy *phy;
> struct usb_phy *uphy;

yes, we need to move everybody to use struct phy, instead of struct
usb_phy.

> usb_phy has many members that struct phy does not have, including otg.
> struct usb_otg  *otg;
> Is that mean we need port such member from usb_phy to phy.

This means we have a little ground work to do before we can add your phy
driver to that framework, right ? As I said, if the framework is missing
anything, work with Kishon (generic phy maintainer) to add those missing
pieces generically.

> Besides, are you ok with using usb_gadget_vbus_connect/disconnect.
> 
> >
> >Scratching one's own itch kinda thing...
> >
> >>+static void hi6220_detect_work(struct work_struct *work)
> >>+{
> >>+   struct hi6220_priv *priv =
> >>+   container_of(work, struct hi6220_priv, work.work);
> >>+   int gpio_id, gpio_vbus;
> >>+   enum usb_otg_state state;
> >>+
> >>+   if (!gpio_is_valid(priv->gpio_id) || 
> >>!gpio_is_valid(priv->gpio_vbus))
> >>+   return;
> >>+
> >>+   gpio_id = gpio_get_value_cansleep(priv->gpio_id);
> >>+   gpio_vbus = gpio_get_value_cansleep(priv->gpio_vbus);
> >
> >looks like this should be using extcon
> Not used extcon before.
> However, we need gpio_vbus interrupt.
> Checked phy-tahvo.c and phy-omap-otg.c, not find extcon related with
> interrupt.
> Will investigate tomorrow.
> >>>
> >>>drivers/extcon/extcon-gpio.c
> >>I think there is no need to use extcon, gpio is clear enough.
> >>extcon-gpio.c even do not support dt.
> >
> >well, add DT. The whole idea of free software is that we improve on
> >things we already have. EXTCON is *the* API to handle such things.
> 
> I think I am still not understanding extcon-gpio, not sure why need
> use this API here.

because extcon is the API to use for external connectors. The same way
you use regulator framework to control that single GPIO tied to an
enable signal of a fixed regulator, you use extcon when you need to read
that gpio signal tied to id pin of the USB connector.

> Here two gpio requires, one gpio as interrupt, in the interrupt
> handler, we detect the gpio status judging the otg status.
> extcon-gpio.c use the interrupt, then can we also use the gpio
> interrupt.  Using extcon-gpio is used for saving gpio_request?

extcon is used to hide gpio_request from dwc2. dwc2 only knows about
extcon, not gpios. extcon will request the gpio and use it as interrupt
source. When an IRQ fires, it will read the gpio state and decide if it
should broadcast a message to tell dwc2 to become host or peripheral.

> >Quite frankly, though, Roger Quadros (now in Cc) has been working to get
> >DT support on extcon-gpio, so perhaps wait for that and base your
> >patches on top of his.
> >
>

Re: [resend PATCH v3 4/4] usb: phy: add phy-hi6220-usb

[Felipe Balbi]

On Wed, Feb 11, 2015 at 11:10:31AM +0200, Baruch Siach wrote:
> Hi Peter, Felipe,
> 
> > > new drivers only on drivers/phy/, sorry.
> > 
> > This driver has many USB dependencies, like otg, gadget. I don't know it
> > can use generic phy currently.
> 
> I would like to remind you the thread at 
> http://thread.gmane.org/gmane.linux.kernel/1858137. I have a USB PHY driver 
> here that depends on notify_connect/notify_disconnect, which are not 
> currently 
> provided by the generic phy infrastructure (drivers/phy/). What would be 
> acceptable solution for this case?

work with Kishon (generic phy maintainer) to add missing pieces you
need.

-- 
balbi


signature.asc
Description: Digital signature

Re: [resend PATCH v3 4/4] usb: phy: add phy-hi6220-usb

[Felipe Balbi]

On Tue, Feb 10, 2015 at 10:53:23PM +0800, zhangfei wrote:
> 
> 
> On 02/10/2015 10:48 PM, Felipe Balbi wrote:
> >On Tue, Feb 10, 2015 at 05:10:04PM +0800, Zhangfei Gao wrote:
> >>Add usb phy controller for hi6220 platform
> >>
> >>Signed-off-by: Zhangfei Gao 
> >>---
> >>  drivers/usb/phy/Kconfig  |   9 ++
> >>  drivers/usb/phy/Makefile |   1 +
> >>  drivers/usb/phy/phy-hi6220-usb.c | 306 
> >> +++
> >>  3 files changed, 316 insertions(+)
> >>  create mode 100644 drivers/usb/phy/phy-hi6220-usb.c
> >>
> >>diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
> >>index c6d0c8e..405a3d0 100644
> >>--- a/drivers/usb/phy/Kconfig
> >>+++ b/drivers/usb/phy/Kconfig
> >>@@ -173,6 +173,15 @@ config USB_MXS_PHY
> >>
> >>  MXS Phy is used by some of the i.MX SoCs, for example imx23/28/6x.
> >>
> >>+config USB_HI6220_PHY
> >>+   tristate "hi6220 USB PHY support"
> >>+   select USB_PHY
> >>+   select MFD_SYSCON
> >>+   help
> >>+ Enable this to support the HISILICON HI6220 USB PHY.
> >>+
> >>+ To compile this driver as a module, choose M here.
> >>+
> >>  config USB_RCAR_PHY
> >>tristate "Renesas R-Car USB PHY support"
> >>depends on USB || USB_GADGET
> >>diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile
> >>index 75f2bba..00172d3 100644
> >>--- a/drivers/usb/phy/Makefile
> >>+++ b/drivers/usb/phy/Makefile
> >>@@ -18,6 +18,7 @@ obj-$(CONFIG_SAMSUNG_USBPHY)  += 
> >>phy-samsung-usb.o
> >>  obj-$(CONFIG_TWL6030_USB) += phy-twl6030-usb.o
> >>  obj-$(CONFIG_USB_EHCI_TEGRA)  += phy-tegra-usb.o
> >>  obj-$(CONFIG_USB_GPIO_VBUS)   += phy-gpio-vbus-usb.o
> >>+obj-$(CONFIG_USB_HI6220_PHY)   += phy-hi6220-usb.o
> >
> >new drivers only on drivers/phy/, sorry.
> >
> OK, thanks for the info, I don't know this at all.
> So even usb phy should be put under drivers/phy/.
> 
> Will change that.

yes, thank you

-- 
balbi


signature.asc
Description: Digital signature

Re: [resend PATCH v3 4/4] usb: phy: add phy-hi6220-usb

[Felipe Balbi]

On Wed, Feb 11, 2015 at 01:30:53AM +, Peter Chen wrote:
>  
> > > Signed-off-by: Zhangfei Gao 
> > > ---
> > >  drivers/usb/phy/Kconfig  |   9 ++
> > >  drivers/usb/phy/Makefile |   1 +
> > >  drivers/usb/phy/phy-hi6220-usb.c | 306
> > > +++
> > >  3 files changed, 316 insertions(+)
> > >  create mode 100644 drivers/usb/phy/phy-hi6220-usb.c
> > >
> > > diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig index
> > > c6d0c8e..405a3d0 100644
> > > --- a/drivers/usb/phy/Kconfig
> > > +++ b/drivers/usb/phy/Kconfig
> > > @@ -173,6 +173,15 @@ config USB_MXS_PHY
> > >
> > > MXS Phy is used by some of the i.MX SoCs, for example imx23/28/6x.
> > >
> > > +config USB_HI6220_PHY
> > > + tristate "hi6220 USB PHY support"
> > > + select USB_PHY
> > > + select MFD_SYSCON
> > > + help
> > > +   Enable this to support the HISILICON HI6220 USB PHY.
> > > +
> > > +   To compile this driver as a module, choose M here.
> > > +
> > >  config USB_RCAR_PHY
> > >   tristate "Renesas R-Car USB PHY support"
> > >   depends on USB || USB_GADGET
> > > diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile index
> > > 75f2bba..00172d3 100644
> > > --- a/drivers/usb/phy/Makefile
> > > +++ b/drivers/usb/phy/Makefile
> > > @@ -18,6 +18,7 @@ obj-$(CONFIG_SAMSUNG_USBPHY)+= phy-
> > samsung-usb.o
> > >  obj-$(CONFIG_TWL6030_USB)+= phy-twl6030-usb.o
> > >  obj-$(CONFIG_USB_EHCI_TEGRA) += phy-tegra-usb.o
> > >  obj-$(CONFIG_USB_GPIO_VBUS)  += phy-gpio-vbus-usb.o
> > > +obj-$(CONFIG_USB_HI6220_PHY) += phy-hi6220-usb.o
> > 
> > new drivers only on drivers/phy/, sorry.
> > 
> 
> This driver has many USB dependencies, like otg, gadget. I don't know it
> can use generic phy currently.

then we improve generic phy framework. It's about time we moved
everything to that anyway.

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH v4 4/4] phy: add phy-hi6220-usb

[Felipe Balbi]

Hi,

On Sat, Feb 21, 2015 at 11:03:05PM +0800, zhangfei wrote:
> +static void hi6220_start_peripheral(struct hi6220_priv *priv, bool on)
> +{
> + struct usb_otg *otg = priv->phy.otg;
> +
> + if (!otg->gadget)
> + return;
> +
> + if (on)
> + usb_gadget_connect(otg->gadget);
> + else
> + usb_gadget_disconnect(otg->gadget);
> >>>
> >>>why is the PHY fiddling with pullups ?
> >>
> >>We use this to enable/disable otg gadget mode.
> >
> >I got that, but the pullups don't belong to the PHY, they belong to the
> >gadget.
> >
> >>The gpio_id & gpio_vbus are used to distinguish otg gadget mode or
> >>host mode.
> >>When micro usb or otg device attached to otg, gpio_vbus falling down.
> >>And gpio_id = 1 is micro usb, gpio_id = 0 is otg device.
> >
> >all of that I understood clearly :-)
> >
> >>So when micro usb attached, we enable gadget mode; while micro usb
> >>detached, we disable gadget mode, and dwc2 will automatically set to
> >>host mode.
> >
> >that's all fine, I'm concerned about letting the PHY fiddle with
> >something it doesn't own. If I am to change pullups rules in udc-core,
> >this is likely to break down miserably and I don't want to have to go
> >through that.
> 
> Thanks for the clarifying.

no problem.

> How about using usb_gadget_vbus_connect/disconnect, which are used in many
> files under drivers/usb/phy.
> There is no vbus_session in dwc2/gadget.c, I thought it would be same as
> pullup.
> 
> However, usb_gadget_vbus_connect still need para gadget, where should we put
> this file, drivers/usb/phy or drivers/phy

drivers/phy, if the framework misses anything you need, it's a great
opportunity to give back to the community by extending the framework.

Scratching one's own itch kinda thing...

> +static void hi6220_detect_work(struct work_struct *work)
> +{
> + struct hi6220_priv *priv =
> + container_of(work, struct hi6220_priv, work.work);
> + int gpio_id, gpio_vbus;
> + enum usb_otg_state state;
> +
> + if (!gpio_is_valid(priv->gpio_id) || !gpio_is_valid(priv->gpio_vbus))
> + return;
> +
> + gpio_id = gpio_get_value_cansleep(priv->gpio_id);
> + gpio_vbus = gpio_get_value_cansleep(priv->gpio_vbus);
> >>>
> >>>looks like this should be using extcon
> >>Not used extcon before.
> >>However, we need gpio_vbus interrupt.
> >>Checked phy-tahvo.c and phy-omap-otg.c, not find extcon related with
> >>interrupt.
> >>Will investigate tomorrow.
> >
> >drivers/extcon/extcon-gpio.c
> I think there is no need to use extcon, gpio is clear enough.
> extcon-gpio.c even do not support dt.

well, add DT. The whole idea of free software is that we improve on
things we already have. EXTCON is *the* API to handle such things.

Quite frankly, though, Roger Quadros (now in Cc) has been working to get
DT support on extcon-gpio, so perhaps wait for that and base your
patches on top of his.

Now your statement that GPIO is clear enough is completely bogus to me.

Why do we have fixed regulators with GPIO enable signals, right ? Might
as well just fiddle with the GPIO directly, right ? Wrong, the idea of
using these frameworks is to encapsulate implementation details and make
sure that if things change from one board to another, we can still use
our SW without major modifications.

> + if (gpio_vbus == 0) {
> + if (gpio_id == 1)
> + state = OTG_STATE_B_PERIPHERAL;
> + else
> + state = OTG_STATE_A_HOST;
> + } else {
> + state = OTG_STATE_A_HOST;
> + }
> +
> + if (priv->state != state) {
> + hi6220_start_peripheral(priv, state == OTG_STATE_B_PERIPHERAL);
> + priv->state = state;
> + }
> +}
> +
> +static irqreturn_t hiusb_gpio_intr(int irq, void *data)
> +{
> + struct hi6220_priv *priv = (struct hi6220_priv *)data;
> +
> + /* add debounce time */
> + schedule_delayed_work(&priv->work, msecs_to_jiffies(100));
> >>>
> >>>this is really bad. We have threaded interrupt support, right ?
> >>
> >>Since we use two gpio to distinguish gadget mode or host mode.
> >>Debounce time can introduce more accuracy.
> >
> >gpio_set_debounce() ?
> Not all gpio.c support set_debounce, including gpio-pl061.c.

then the framework should implement it in SW. That was the whole idea of
adding set_debounce() to gpiolib. If the controller can't handle it,
gpiolib handles it in SW. Again, encapsulating details.

> >>I think threaded interrupt can not be used for adding debounce time.
> >>Here add debounce is just for safety.
> >
> >add the debounce to the gpio itself.
> 
> Here the debounce added only for safety.
> gpio_id may mis-report when unplug usb, but it is correct for plug usb & otg
> device.
> So debounce can be omitted.
> If you think using delayed work for debounce is ugly, it is fine switch to
> threaded_irq.

debounce might be very well needed. We *do* wan

Re: [PATCH v4 4/4] phy: add phy-hi6220-usb

[Felipe Balbi]

Hi,

On Fri, Feb 20, 2015 at 11:44:37PM +0800, zhangfei wrote:
> Hi, Balbi
> 
> On 02/20/2015 10:41 PM, Felipe Balbi wrote:
> 
> >>+static void hi6220_start_peripheral(struct hi6220_priv *priv, bool on)
> >>+{
> >>+   struct usb_otg *otg = priv->phy.otg;
> >>+
> >>+   if (!otg->gadget)
> >>+   return;
> >>+
> >>+   if (on)
> >>+   usb_gadget_connect(otg->gadget);
> >>+   else
> >>+   usb_gadget_disconnect(otg->gadget);
> >
> >why is the PHY fiddling with pullups ?
> 
> We use this to enable/disable otg gadget mode.

I got that, but the pullups don't belong to the PHY, they belong to the
gadget.

> The gpio_id & gpio_vbus are used to distinguish otg gadget mode or
> host mode.
> When micro usb or otg device attached to otg, gpio_vbus falling down.
> And gpio_id = 1 is micro usb, gpio_id = 0 is otg device.

all of that I understood clearly :-)

> So when micro usb attached, we enable gadget mode; while micro usb
> detached, we disable gadget mode, and dwc2 will automatically set to
> host mode.

that's all fine, I'm concerned about letting the PHY fiddle with
something it doesn't own. If I am to change pullups rules in udc-core,
this is likely to break down miserably and I don't want to have to go
through that.

> >>+static void hi6220_detect_work(struct work_struct *work)
> >>+{
> >>+   struct hi6220_priv *priv =
> >>+   container_of(work, struct hi6220_priv, work.work);
> >>+   int gpio_id, gpio_vbus;
> >>+   enum usb_otg_state state;
> >>+
> >>+   if (!gpio_is_valid(priv->gpio_id) || !gpio_is_valid(priv->gpio_vbus))
> >>+   return;
> >>+
> >>+   gpio_id = gpio_get_value_cansleep(priv->gpio_id);
> >>+   gpio_vbus = gpio_get_value_cansleep(priv->gpio_vbus);
> >
> >looks like this should be using extcon
> Not used extcon before.
> However, we need gpio_vbus interrupt.
> Checked phy-tahvo.c and phy-omap-otg.c, not find extcon related with
> interrupt.
> Will investigate tomorrow.

drivers/extcon/extcon-gpio.c

> >>+   if (gpio_vbus == 0) {
> >>+   if (gpio_id == 1)
> >>+   state = OTG_STATE_B_PERIPHERAL;
> >>+   else
> >>+   state = OTG_STATE_A_HOST;
> >>+   } else {
> >>+   state = OTG_STATE_A_HOST;
> >>+   }
> >>+
> >>+   if (priv->state != state) {
> >>+   hi6220_start_peripheral(priv, state == OTG_STATE_B_PERIPHERAL);
> >>+   priv->state = state;
> >>+   }
> >>+}
> >>+
> >>+static irqreturn_t hiusb_gpio_intr(int irq, void *data)
> >>+{
> >>+   struct hi6220_priv *priv = (struct hi6220_priv *)data;
> >>+
> >>+   /* add debounce time */
> >>+   schedule_delayed_work(&priv->work, msecs_to_jiffies(100));
> >
> >this is really bad. We have threaded interrupt support, right ?
> 
> Since we use two gpio to distinguish gadget mode or host mode.
> Debounce time can introduce more accuracy.

gpio_set_debounce() ?

> I think threaded interrupt can not be used for adding debounce time.
> Here add debounce is just for safety.

add the debounce to the gpio itself.

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH v4 4/4] phy: add phy-hi6220-usb

[Felipe Balbi]

Hi,

On Thu, Feb 12, 2015 at 03:37:26PM +0800, Zhangfei Gao wrote:
> Add usb phy controller for hi6220 platform
> 
> Signed-off-by: Zhangfei Gao 
> ---
>  drivers/phy/Kconfig  |   9 ++
>  drivers/phy/Makefile |   1 +
>  drivers/phy/phy-hi6220-usb.c | 306 
> +++
>  3 files changed, 316 insertions(+)
>  create mode 100644 drivers/phy/phy-hi6220-usb.c
> 
> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> index ccad880..40a1ef1 100644
> --- a/drivers/phy/Kconfig
> +++ b/drivers/phy/Kconfig
> @@ -162,6 +162,15 @@ config PHY_HIX5HD2_SATA
>   help
> Support for SATA PHY on Hisilicon hix5hd2 Soc.
>  
> +config PHY_HI6220_USB
> + tristate "hi6220 USB PHY support"
> + select USB_PHY
> + select MFD_SYSCON
> + help
> +   Enable this to support the HISILICON HI6220 USB PHY.
> +
> +   To compile this driver as a module, choose M here.
> +
>  config PHY_SUN4I_USB
>   tristate "Allwinner sunxi SoC USB PHY driver"
>   depends on ARCH_SUNXI && HAS_IOMEM && OF
> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
> index aa74f96..ec43c2d 100644
> --- a/drivers/phy/Makefile
> +++ b/drivers/phy/Makefile
> @@ -19,6 +19,7 @@ obj-$(CONFIG_TI_PIPE3)  += 
> phy-ti-pipe3.o
>  obj-$(CONFIG_TWL4030_USB)+= phy-twl4030-usb.o
>  obj-$(CONFIG_PHY_EXYNOS5250_SATA)+= phy-exynos5250-sata.o
>  obj-$(CONFIG_PHY_HIX5HD2_SATA)   += phy-hix5hd2-sata.o
> +obj-$(CONFIG_PHY_HI6220_USB) += phy-hi6220-usb.o
>  obj-$(CONFIG_PHY_SUN4I_USB)  += phy-sun4i-usb.o
>  obj-$(CONFIG_PHY_SAMSUNG_USB2)   += phy-exynos-usb2.o
>  phy-exynos-usb2-y+= phy-samsung-usb2.o
> diff --git a/drivers/phy/phy-hi6220-usb.c b/drivers/phy/phy-hi6220-usb.c
> new file mode 100644
> index 000..0d9f5ac
> --- /dev/null
> +++ b/drivers/phy/phy-hi6220-usb.c
> @@ -0,0 +1,306 @@
> +/*
> + * Copyright (c) 2015 Linaro Ltd.
> + * Copyright (c) 2015 Hisilicon Limited.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define SC_PERIPH_CTRL4  0x00c
> +
> +#define CTRL4_PICO_SIDDQ BIT(6)
> +#define CTRL4_PICO_OGDISABLE BIT(8)
> +#define CTRL4_PICO_VBUSVLDEXTBIT(10)
> +#define CTRL4_PICO_VBUSVLDEXTSEL BIT(11)
> +#define CTRL4_OTG_PHY_SELBIT(21)
> +
> +#define SC_PERIPH_CTRL5  0x010
> +
> +#define CTRL5_USBOTG_RES_SEL BIT(3)
> +#define CTRL5_PICOPHY_ACAENB BIT(4)
> +#define CTRL5_PICOPHY_BC_MODEBIT(5)
> +#define CTRL5_PICOPHY_CHRGSELBIT(6)
> +#define CTRL5_PICOPHY_VDATSRCEND BIT(7)
> +#define CTRL5_PICOPHY_VDATDETENB BIT(8)
> +#define CTRL5_PICOPHY_DCDENB BIT(9)
> +#define CTRL5_PICOPHY_IDDIG  BIT(10)
> +
> +#define SC_PERIPH_CTRL8  0x018
> +#define SC_PERIPH_RSTEN0 0x300
> +#define SC_PERIPH_RSTDIS00x304
> +
> +#define RST0_USBOTG_BUS  BIT(4)
> +#define RST0_POR_PICOPHY BIT(5)
> +#define RST0_USBOTG  BIT(6)
> +#define RST0_USBOTG_32K  BIT(7)
> +
> +#define EYE_PATTERN_PARA 0x7053348c
> +
> +struct hi6220_priv {
> + struct usb_phy phy;
> + struct delayed_work work;
> + struct regmap *reg;
> + struct clk *clk;
> + struct regulator *vcc;
> + struct device *dev;
> + int gpio_vbus;
> + int gpio_id;
> + enum usb_otg_state state;
> +};
> +
> +static void hi6220_start_peripheral(struct hi6220_priv *priv, bool on)
> +{
> + struct usb_otg *otg = priv->phy.otg;
> +
> + if (!otg->gadget)
> + return;
> +
> + if (on)
> + usb_gadget_connect(otg->gadget);
> + else
> + usb_gadget_disconnect(otg->gadget);

why is the PHY fiddling with pullups ?

> +}
> +
> +static void hi6220_detect_work(struct work_struct *work)
> +{
> + struct hi6220_priv *priv =
> + container_of(work, struct hi6220_priv, work.work);
> + int gpio_id, gpio_vbus;
> + enum usb_otg_state state;
> +
> + if (!gpio_is_valid(priv->gpio_id) || !gpio_is_valid(priv->gpio_vbus))
> + return;
> +
> + gpio_id = gpio_get_value_cansleep(priv->gpio_id);
> + gpio_vbus = gpio_get_value_cansleep(priv->gpio_vbus);

looks like this should be using extcon

> +
> + if (gpio_vbus == 0) {
> + if (gpio_id == 1)
> + state = OTG_STATE_B_PERIPHERAL;
> + else
> + state = OTG_STATE_A_HOST;
> + } else {
> + state = OTG_STATE_A_HOST;
>

Re: [PATCH v4 4/4] phy: add phy-hi6220-usb

[Felipe Balbi]

On Fri, Feb 20, 2015 at 11:07:21AM +0800, zhangfei wrote:
> Hi, Balbi
> 
> On 02/18/2015 10:35 PM, Felipe Balbi wrote:
> >On Wed, Feb 18, 2015 at 01:44:21PM +0800, zhangfei wrote:
> >>Hi, Kishon
> >>
> >>On 02/18/2015 01:35 PM, Kishon Vijay Abraham I wrote:
> >>>Hi,
> >>>
> >>>On Thursday 12 February 2015 01:07 PM, Zhangfei Gao wrote:
> >>>>Add usb phy controller for hi6220 platform
> >>>>
> >>>>Signed-off-by: Zhangfei Gao 
> >>>>---
> >>>>  drivers/phy/Kconfig  |   9 ++
> >>>>  drivers/phy/Makefile |   1 +
> >>>>  drivers/phy/phy-hi6220-usb.c | 306
> >>>>+++
> >>>>  3 files changed, 316 insertions(+)
> >>>>  create mode 100644 drivers/phy/phy-hi6220-usb.c
> >>>
> >>>why is this driver in drivers/phy when it doesn't use the generic PHY
> >>>framework at all?
> >>>
> >>
> >>Balbi recommended "new drivers only on drivers/phy/", including usb
> >>phy.
> >
> >but it should use the API too. It's not only about a directory, you need
> >to use the new API.
> >
> >>So Move drivers/usb/phy/phy-hi6220-usb.c to
> >>drivers/phy/phy-hi6220-usb.c, required by Balbi.
> >
> >you're reading what I stated the way you like.
> 
> Sorry for my bad understanding.
> 
> Still not clear about the otg_set_peripheral, which is required in
> phy-hi6220-usb.c
> 
> 1. drivers/usb/dwc2/gadget.c use
> otg_set_peripheral(hsotg->uphy->otg, &hsotg->gadget);
> 
> 2. include/linux/phy/phy.h
> struct phy do not have member otg, while struct usb_phy has.
> 
> Could you give more hints?

your set_peripheral doesn't do anything, just holds a pointer. Might as
well not implement it. I'll review your driver more fully tomorrow.

There a few things which must be changed.

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH v4 1/5] xhci: add a quirk for device disconnection errata for Synopsis Designware USB3 core

[Felipe Balbi]

On Wed, Feb 18, 2015 at 10:39:53PM +0800, Sneeker Yeh wrote:
> Hi,
> 2015/2/18 下午10:34 於 "Felipe Balbi"  寫道：
> >
> > On Wed, Feb 18, 2015 at 10:47:45AM +0200, Mathias Nyman wrote:
> > > Hi
> > >
> > > This looks correct, but if you are still going to make a new series
> fixing
> > > Felipe's comments then the following tiny nitpicks could be fixed as
> well.
> > >
> > > Otherwise
> > >
> > > Acked-by: Mathias Nyman 
> > >
> > > Felipe, Do you want to take this series through your tree?
> >
> > I can, no issues :-)
> >
> > > On 17.02.2015 07:41, Sneeker Yeh wrote:
> > > >
> > > > +static void xhci_try_to_clear_csc(struct usb_hcd *hcd, int
> dev_port_num)
> > >
> > > Either add a function description explaining something like "Late
> > > clearing of connect status.
> > > Some quirky hardware will suspend the controller when CSC bit is
> > > cleared and leave URBs unhandled"
> > >
> > > Or change the function name to something like
> > > xhci_late_csc_clear_quirk() or xhci_deferred_csc_clear_quirk()
> >
> > I have a feeling xhci_late_csc_clear_quirk() is a better name, much more
> > descriptive than xhci_try_to_clear_csc() :-)
> 
> Hmm, I'll use this one, ^^
> Thanks for comment it.

alright, either one is fine :-)

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH v4 4/4] phy: add phy-hi6220-usb

[Felipe Balbi]

On Wed, Feb 18, 2015 at 01:44:21PM +0800, zhangfei wrote:
> Hi, Kishon
> 
> On 02/18/2015 01:35 PM, Kishon Vijay Abraham I wrote:
> >Hi,
> >
> >On Thursday 12 February 2015 01:07 PM, Zhangfei Gao wrote:
> >>Add usb phy controller for hi6220 platform
> >>
> >>Signed-off-by: Zhangfei Gao 
> >>---
> >>  drivers/phy/Kconfig  |   9 ++
> >>  drivers/phy/Makefile |   1 +
> >>  drivers/phy/phy-hi6220-usb.c | 306
> >>+++
> >>  3 files changed, 316 insertions(+)
> >>  create mode 100644 drivers/phy/phy-hi6220-usb.c
> >
> >why is this driver in drivers/phy when it doesn't use the generic PHY
> >framework at all?
> >
> 
> Balbi recommended "new drivers only on drivers/phy/", including usb
> phy.

but it should use the API too. It's not only about a directory, you need
to use the new API.

> So Move drivers/usb/phy/phy-hi6220-usb.c to
> drivers/phy/phy-hi6220-usb.c, required by Balbi.

you're reading what I stated the way you like.

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH v4 1/5] xhci: add a quirk for device disconnection errata for Synopsis Designware USB3 core

[Felipe Balbi]

On Wed, Feb 18, 2015 at 10:47:45AM +0200, Mathias Nyman wrote:
> Hi
> 
> This looks correct, but if you are still going to make a new series fixing
> Felipe's comments then the following tiny nitpicks could be fixed as well. 
> 
> Otherwise
> 
> Acked-by: Mathias Nyman 
> 
> Felipe, Do you want to take this series through your tree?

I can, no issues :-)

> On 17.02.2015 07:41, Sneeker Yeh wrote:
> >  
> > +static void xhci_try_to_clear_csc(struct usb_hcd *hcd, int dev_port_num)
> 
> Either add a function description explaining something like "Late
> clearing of connect status.
> Some quirky hardware will suspend the controller when CSC bit is
> cleared and leave URBs unhandled"
> 
> Or change the function name to something like
> xhci_late_csc_clear_quirk() or xhci_deferred_csc_clear_quirk()

I have a feeling xhci_late_csc_clear_quirk() is a better name, much more
descriptive than xhci_try_to_clear_csc() :-)

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH v4 5/5] usb: dwc3: add Fujitsu Specific Glue layer

[Felipe Balbi]

On Tue, Feb 17, 2015 at 01:41:37PM +0800, Sneeker Yeh wrote:
> This patch adds support for Synopsis DesignWare USB3 IP Core found
> on Fujitsu Socs.
> 
> Signed-off-by: Sneeker Yeh 
> ---
>  .../devicetree/bindings/usb/fujitsu-dwc3.txt   |   33 
>  drivers/usb/dwc3/Kconfig   |   11 ++
>  drivers/usb/dwc3/Makefile  |1 +
>  drivers/usb/dwc3/dwc3-mb86s70.c|  206 
> 
>  4 files changed, 251 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/usb/fujitsu-dwc3.txt
>  create mode 100644 drivers/usb/dwc3/dwc3-mb86s70.c

what's the possibility that fujitsu will make another SoC with dwc3 in
it ? I wonder if we should use a slightly more generic name here:

dwc3-fujitsu.c ?

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH 1/4] arm: omap: hwmod: 43xx: add DebugSS hwmod data

[Felipe Balbi]

Hi,

On Tue, Feb 10, 2015 at 11:12:40PM +, Paul Walmsley wrote:
> > > > > > > > hm... modulemode SWCTRL causes wait_target_ready to fail. Any 
> > > > > > > > hints ?
> > > > > > > 
> > > > > > > gets stuck in transition state. PRCM_CM_WKUP_DBGSS_CLKCTRL is 
> > > > > > > always
> > > > > > > read as 0x 12510f00 which would translate into:
> > > > > > > 
> > > > > > > - module disabled
> > > > > > > - all opt clocks are on
> > > > > > > - module is transitioning
> > > > > > > - module in standby
> > > > > > > - clkA as TPIU and STM trace clock
> > > > > > > - all dividers set to 2
> > > > > > 
> > > > > > just fyi, checking with HW folks, this might be a new bug, unless
> > > > > > debugss needs something special.
> > > > > 
> > > > > If that happens on DEBUGSS disable, it's probably the same issue as 
> > > > > on 
> > > > > AM33xx:
> > > > > 
> > > > > http://www.spinics.net/lists/arm-kernel/msg320801.html
> > > > > http://www.spinics.net/lists/arm-kernel/msg321930.html
> > > > > http://www.spinics.net/lists/arm-kernel/msg329151.html
> > > > > 
> > > > > Does adding HWMOD_INIT_NO_IDLE fix the issue you're seeing?
> > > > 
> > > > I'll try it out in a bit...
> > > 
> > > nope, same thing.
> > > 
> > > [   27.633235] omap_hwmod: debugss: _wait_target_disable failed
> > 
> > OK, looking at the code, this makes sense.  So here's what I'd suggest 
> > asking the hardware team: is the right approach to:
> > 
> > 1. keep the DEBUGSS CLKCTRL MODULEMODE bitfield at 0x2 all the time, even 
> > when it's not in use or when entering chip low-power states, or
> > 
> > 2. program the DEBUGSS CLKCTRL MODULEMODE bitfield to 0x0 when the DEBUGSS 
> > is not in use or when entering chip low-power states, but ignore the 
> > DEBUGSS CLKCTRL IDLEST register 
> > 
> > We'll need a new hwmod flag either way; the question is whether it should 
> > be something like HWMOD_CANNOT_DISABLE (case 1), or 
> > HWMOD_DISABLE_IGNORE_IDLEST (case 2).
> 
> Just checking on this.  Heard anything from the hardware team?  If not I'd 
> say the HWMOD_CANNOT_DISABLE approach is probably the right one for now...

nothing from HW team yet. Last I heard is that they can reproduce the
issue, and are now digging through documentation (and maybe RTL, but I'm
speculating) to see if that should be supported or not.

From my point of view, however, the thing idles, it just doesn't report
it.

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH v3 4/5] usb: phy: load usb phy earlier

[Felipe Balbi]

On Tue, Feb 10, 2015 at 03:04:28PM +0800, Peter Chen wrote:
> This patch does not belong to phy, so, doesn't need to
> add phy in subject, meanwhile, please add GregKH as TO list,
> he is the right one to queue this patch.
> 
> Reply-To: 
> In-Reply-To: <1423554627-694-5-git-send-email-zhangfei@linaro.org>
> 
> On Tue, Feb 10, 2015 at 03:50:26PM +0800, Zhangfei Gao wrote:
> > Since phy is definitely used in usb controller, load the phy
> > earlier to make boot time shorter.
> > 
> > Signed-off-by: Zhangfei Gao 
> > Acked-by: Peter Chen 

NAK, make sure there are no such dependencies with your controller
driver. They should know how to defer probing if their resources aren't
available yet.

-- 
balbi


signature.asc
Description: Digital signature

Re: [resend PATCH v3 4/4] usb: phy: add phy-hi6220-usb

[Felipe Balbi]

On Tue, Feb 10, 2015 at 05:10:04PM +0800, Zhangfei Gao wrote:
> Add usb phy controller for hi6220 platform
> 
> Signed-off-by: Zhangfei Gao 
> ---
>  drivers/usb/phy/Kconfig  |   9 ++
>  drivers/usb/phy/Makefile |   1 +
>  drivers/usb/phy/phy-hi6220-usb.c | 306 
> +++
>  3 files changed, 316 insertions(+)
>  create mode 100644 drivers/usb/phy/phy-hi6220-usb.c
> 
> diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
> index c6d0c8e..405a3d0 100644
> --- a/drivers/usb/phy/Kconfig
> +++ b/drivers/usb/phy/Kconfig
> @@ -173,6 +173,15 @@ config USB_MXS_PHY
>  
> MXS Phy is used by some of the i.MX SoCs, for example imx23/28/6x.
>  
> +config USB_HI6220_PHY
> + tristate "hi6220 USB PHY support"
> + select USB_PHY
> + select MFD_SYSCON
> + help
> +   Enable this to support the HISILICON HI6220 USB PHY.
> +
> +   To compile this driver as a module, choose M here.
> +
>  config USB_RCAR_PHY
>   tristate "Renesas R-Car USB PHY support"
>   depends on USB || USB_GADGET
> diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile
> index 75f2bba..00172d3 100644
> --- a/drivers/usb/phy/Makefile
> +++ b/drivers/usb/phy/Makefile
> @@ -18,6 +18,7 @@ obj-$(CONFIG_SAMSUNG_USBPHY)+= 
> phy-samsung-usb.o
>  obj-$(CONFIG_TWL6030_USB)+= phy-twl6030-usb.o
>  obj-$(CONFIG_USB_EHCI_TEGRA) += phy-tegra-usb.o
>  obj-$(CONFIG_USB_GPIO_VBUS)  += phy-gpio-vbus-usb.o
> +obj-$(CONFIG_USB_HI6220_PHY) += phy-hi6220-usb.o

new drivers only on drivers/phy/, sorry.

-- 
balbi


signature.asc
Description: Digital signature

[RFC/PATCH 1/2] of: move of_property_read_bool further down

[Felipe Balbi]

A follow-up patch will make use of of_property_read_u32()
to allow for boolean properties to have a value, this
is just in preparation for that patch in order to make
review easier.

Signed-off-by: Felipe Balbi 
---
 include/linux/of.h | 32 
 1 file changed, 16 insertions(+), 16 deletions(-)

diff --git a/include/linux/of.h b/include/linux/of.h
index dfde07e77a63..76c055b20fef 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -765,22 +765,6 @@ static inline int of_property_read_string_index(struct 
device_node *np,
return rc < 0 ? rc : 0;
 }
 
-/**
- * of_property_read_bool - Findfrom a property
- * @np:device node from which the property value is to be read.
- * @propname:  name of the property to be searched.
- *
- * Search for a property in a device node.
- * Returns true if the property exist false otherwise.
- */
-static inline bool of_property_read_bool(const struct device_node *np,
-const char *propname)
-{
-   struct property *prop = of_find_property(np, propname, NULL);
-
-   return prop ? true : false;
-}
-
 static inline int of_property_read_u8(const struct device_node *np,
   const char *propname,
   u8 *out_value)
@@ -802,6 +786,22 @@ static inline int of_property_read_u32(const struct 
device_node *np,
return of_property_read_u32_array(np, propname, out_value, 1);
 }
 
+/**
+ * of_property_read_bool - Findfrom a property
+ * @np:device node from which the property value is to be read.
+ * @propname:  name of the property to be searched.
+ *
+ * Search for a property in a device node.
+ * Returns true if the property exist false otherwise.
+ */
+static inline bool of_property_read_bool(const struct device_node *np,
+const char *propname)
+{
+   struct property *prop = of_find_property(np, propname, NULL);
+
+   return prop ? true : false;
+}
+
 static inline int of_property_read_s32(const struct device_node *np,
   const char *propname,
   s32 *out_value)
-- 
2.3.0-rc1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC/PATCH 2/2] of: allow for boolean flags to have value

[Felipe Balbi]

allowing values to boolean flags lets us setup
defaults on DTSI which can get disabled later
at board DTS if, for whatever reason, board can't
use that default.

One such example is DM81xx EVM where we can't use
MUSB's multipoint feature even though SoC supports
it. Something at the board level prevents us from
using the feature.

Instead of removing "multipoint;" from DTSI and
adding it to all board DTS just so we can remove
it from our quirky board seems like overkill when
we could just add:

multipoint = <0>;

to that quirky board's DTS.

Note that the description here is but one example
and it's likely many others have faced something
similar.

Signed-off-by: Felipe Balbi 
---
 include/linux/of.h | 22 --
 1 file changed, 20 insertions(+), 2 deletions(-)

diff --git a/include/linux/of.h b/include/linux/of.h
index 76c055b20fef..c5ee9320f237 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -792,14 +792,32 @@ static inline int of_property_read_u32(const struct 
device_node *np,
  * @propname:  name of the property to be searched.
  *
  * Search for a property in a device node.
- * Returns true if the property exist false otherwise.
+ * Returns true if the property exist and has a value greater than zero,
+ * fals otherwise.
  */
 static inline bool of_property_read_bool(const struct device_node *np,
 const char *propname)
 {
struct property *prop = of_find_property(np, propname, NULL);
+   int rc;
+   u32 val;
 
-   return prop ? true : false;
+   if (!prop)
+   return false;
+
+   rc = of_property_read_u32(np, propname, &val);
+
+   /*
+* if property doesn't have a value, or prop->length == 0 and
+* we overflow, treat it as simple value-less flag.
+*/
+   if (rc == -ENODATA || rc == -EOVERFLOW)
+   return true;
+   if (WARN(rc < 0, "failed to read '%s' value -> %d\n",
+   propname, rc))
+   return false;
+
+   return !!val;
 }
 
 static inline int of_property_read_s32(const struct device_node *np,
-- 
2.3.0-rc1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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 0/5] Add support for Fujitsu USB host controller

[Felipe Balbi]

Hi,

On Thu, Jan 29, 2015 at 10:23:12AM -0600, Felipe Balbi wrote:
> On Tue, Jan 27, 2015 at 09:22:50AM -0600, Felipe Balbi wrote:
> > Hi,
> > 
> > On Sun, Jan 25, 2015 at 04:13:23PM +0800, Sneeker Yeh wrote:
> > > These patches add support for XHCI compliant Host controller found
> > > on Fujitsu Socs, and are based on http://lwn.net/Articles/629162/
> > > The first patch is to add Fujitsu glue layer of Synopsis DesignWare USB3 
> > > driver
> > > and last four patch is about quirk implementation of errata in Synopsis
> > > DesignWare USB3 IP.
> > > 
> > > Patch 1 introduces a quirk with device disconnection management necessary
> > > Synopsys Designware USB3 IP with versions < 3.00a and hardware 
> > > configuration
> > > DWC_USB3_SUSPEND_ON_DISCONNECT_EN=1. It solves a problem where without the
> > > quirk, that host controller will die after a usb device is disconnected 
> > > from
> > > port of root hub.
> > > 
> > > Patch 2 is to set Synopsis quirk in xhci platform driver based on xhci 
> > > platform
> > > data.
> > > 
> > > Patch 3 is to add a revison number 2.90a and 3.00a of Synopsis DesignWare 
> > > USB3
> > > IP core driver.
> > > 
> > > Patch 4 introduces using a quirk based on a errata of Synopsis
> > > DesignWare USB3 IP which is versions < 3.00a and has hardware 
> > > configuration
> > > DWC_USB3_SUSPEND_ON_DISCONNECT_EN=1, which cannot be read from software. 
> > > As a
> > > result this quirk has to be enabled via platform data or device tree.
> > > 
> > > Patch 5 introduces Fujitsu Specific Glue layer in Synopsis DesignWare 
> > > USB3 IP
> > > driver. 
> > > 
> > 
> > Mathias, let me know how you want to handle this. Either I take them
> > all, or you take them all. What do you prefer ?
> 
> Mathias ?

Mathias, a reminder on this series.

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH v3 0/5] Add support for Fujitsu USB host controller

[Felipe Balbi]

On Tue, Jan 27, 2015 at 09:22:50AM -0600, Felipe Balbi wrote:
> Hi,
> 
> On Sun, Jan 25, 2015 at 04:13:23PM +0800, Sneeker Yeh wrote:
> > These patches add support for XHCI compliant Host controller found
> > on Fujitsu Socs, and are based on http://lwn.net/Articles/629162/
> > The first patch is to add Fujitsu glue layer of Synopsis DesignWare USB3 
> > driver
> > and last four patch is about quirk implementation of errata in Synopsis
> > DesignWare USB3 IP.
> > 
> > Patch 1 introduces a quirk with device disconnection management necessary
> > Synopsys Designware USB3 IP with versions < 3.00a and hardware configuration
> > DWC_USB3_SUSPEND_ON_DISCONNECT_EN=1. It solves a problem where without the
> > quirk, that host controller will die after a usb device is disconnected from
> > port of root hub.
> > 
> > Patch 2 is to set Synopsis quirk in xhci platform driver based on xhci 
> > platform
> > data.
> > 
> > Patch 3 is to add a revison number 2.90a and 3.00a of Synopsis DesignWare 
> > USB3
> > IP core driver.
> > 
> > Patch 4 introduces using a quirk based on a errata of Synopsis
> > DesignWare USB3 IP which is versions < 3.00a and has hardware configuration
> > DWC_USB3_SUSPEND_ON_DISCONNECT_EN=1, which cannot be read from software. As 
> > a
> > result this quirk has to be enabled via platform data or device tree.
> > 
> > Patch 5 introduces Fujitsu Specific Glue layer in Synopsis DesignWare USB3 
> > IP
> > driver. 
> > 
> 
> Mathias, let me know how you want to handle this. Either I take them
> all, or you take them all. What do you prefer ?

Mathias ?

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH] usb: phy-generic: Don't fail on missing gpio reset

[Felipe Balbi]

On Tue, Jan 27, 2015 at 11:13:08AM -0800, Sören Brinkmann wrote:
> On Tue, 2015-01-27 at 09:20AM -0600, Felipe Balbi wrote:
> > On Mon, Jan 26, 2015 at 05:45:29PM -0800, Soren Brinkmann wrote:
> > > A reset through a GPIO is optional. Don't fail probing when it is
> > > missing.
> > > 
> > > Reported-by: Andreas Färber 
> > > Signed-off-by: Soren Brinkmann 
> > > ---
> > > Hi Andreas,
> > > 
> > > does this do the trick?
> > > 
> > >   Thanks,
> > >   Sören
> > > 
> > >  drivers/usb/phy/phy-generic.c | 6 ++
> > >  1 file changed, 2 insertions(+), 4 deletions(-)
> > > 
> > > diff --git a/drivers/usb/phy/phy-generic.c b/drivers/usb/phy/phy-generic.c
> > > index dd05254241fb..a73d4c738f0b 100644
> > > --- a/drivers/usb/phy/phy-generic.c
> > > +++ b/drivers/usb/phy/phy-generic.c
> > > @@ -241,10 +241,8 @@ int usb_phy_gen_create_phy(struct device *dev, 
> > > struct usb_phy_generic *nop,
> > >  
> > >   if (err == -EPROBE_DEFER)
> > >   return -EPROBE_DEFER;
> > > - if (err) {
> > > - dev_err(dev, "Error requesting RESET GPIO\n");
> > > - return err;
> > > - }
> > > + if (err)
> > > + nop->gpiod_reset = NULL;
> > 
> > there's a better patch to use gpiod_get_optional(), instead.
> 
> Great, apparently that wasn't in linux-next yesterday. I'll give it a
> shot once it arrives there.

It's still under discussion ;-)

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH 1/4] arm: omap: hwmod: 43xx: add DebugSS hwmod data

[Felipe Balbi]

On Tue, Jan 27, 2015 at 11:15:32AM -0600, Felipe Balbi wrote:
> On Tue, Jan 27, 2015 at 05:12:05PM +, Paul Walmsley wrote:
> > Hi
> > 
> > On Tue, 27 Jan 2015, Felipe Balbi wrote:
> > 
> > > On Mon, Jan 26, 2015 at 01:49:33PM -0600, Felipe Balbi wrote:
> > > > On Mon, Jan 26, 2015 at 10:56:40AM -0600, Felipe Balbi wrote:
> > > >
> > > > > hm... modulemode SWCTRL causes wait_target_ready to fail. Any hints ?
> > > > 
> > > > gets stuck in transition state. PRCM_CM_WKUP_DBGSS_CLKCTRL is always
> > > > read as 0x 12510f00 which would translate into:
> > > > 
> > > > - module disabled
> > > > - all opt clocks are on
> > > > - module is transitioning
> > > > - module in standby
> > > > - clkA as TPIU and STM trace clock
> > > > - all dividers set to 2
> > > 
> > > just fyi, checking with HW folks, this might be a new bug, unless
> > > debugss needs something special.
> > 
> > If that happens on DEBUGSS disable, it's probably the same issue as on 
> > AM33xx:
> > 
> > http://www.spinics.net/lists/arm-kernel/msg320801.html
> > http://www.spinics.net/lists/arm-kernel/msg321930.html
> > http://www.spinics.net/lists/arm-kernel/msg329151.html
> > 
> > Does adding HWMOD_INIT_NO_IDLE fix the issue you're seeing?
> 
> I'll try it out in a bit...

nope, same thing.

[   27.633235] omap_hwmod: debugss: _wait_target_disable failed

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH 1/4] arm: omap: hwmod: 43xx: add DebugSS hwmod data

[Felipe Balbi]

On Tue, Jan 27, 2015 at 05:12:05PM +, Paul Walmsley wrote:
> Hi
> 
> On Tue, 27 Jan 2015, Felipe Balbi wrote:
> 
> > On Mon, Jan 26, 2015 at 01:49:33PM -0600, Felipe Balbi wrote:
> > > On Mon, Jan 26, 2015 at 10:56:40AM -0600, Felipe Balbi wrote:
> > >
> > > > hm... modulemode SWCTRL causes wait_target_ready to fail. Any hints ?
> > > 
> > > gets stuck in transition state. PRCM_CM_WKUP_DBGSS_CLKCTRL is always
> > > read as 0x 12510f00 which would translate into:
> > > 
> > > - module disabled
> > > - all opt clocks are on
> > > - module is transitioning
> > > - module in standby
> > > - clkA as TPIU and STM trace clock
> > > - all dividers set to 2
> > 
> > just fyi, checking with HW folks, this might be a new bug, unless
> > debugss needs something special.
> 
> If that happens on DEBUGSS disable, it's probably the same issue as on 
> AM33xx:
> 
> http://www.spinics.net/lists/arm-kernel/msg320801.html
> http://www.spinics.net/lists/arm-kernel/msg321930.html
> http://www.spinics.net/lists/arm-kernel/msg329151.html
> 
> Does adding HWMOD_INIT_NO_IDLE fix the issue you're seeing?

I'll try it out in a bit...

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH 1/4] arm: omap: hwmod: 43xx: add DebugSS hwmod data

[Felipe Balbi]

On Mon, Jan 26, 2015 at 01:49:33PM -0600, Felipe Balbi wrote:
> Hi,
> 
> On Mon, Jan 26, 2015 at 10:56:40AM -0600, Felipe Balbi wrote:
> > > the references below are from SPRUHL7
> > > 
> > > On Fri, 23 Jan 2015, Felipe Balbi wrote:
> > > 
> > > > Without hwmod data for DebugSS, performance monitors
> > > > have no chance of running on AM43xx devices.
> > > > 
> > > > Signed-off-by: Felipe Balbi 
> > > > ---
> > > >  arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 40 
> > > > ++
> > > >  arch/arm/mach-omap2/prcm43xx.h |  1 +
> > > >  2 files changed, 41 insertions(+)
> > > > 
> > > > diff --git a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c 
> > > > b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
> > > > index 5c6c8410160e..6709704dd5b5 100644
> > > > --- a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
> > > > +++ b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
> > > > @@ -19,6 +19,7 @@
> > > >  #include "omap_hwmod.h"
> > > >  #include "omap_hwmod_33xx_43xx_common_data.h"
> > > >  #include "prcm43xx.h"
> > > > +#include "prm44xx.h"
> > > >  #include "omap_hwmod_common_data.h"
> > > >  
> > > >  
> > > > @@ -60,6 +61,44 @@ static struct omap_hwmod am43xx_wkup_m3_hwmod = {
> > > > .rst_lines_cnt  = ARRAY_SIZE(am33xx_wkup_m3_resets),
> > > >  };
> > > >  
> > > > +/*
> > > > + * 'debugss' class
> > > > + * debug and emulation sub system
> > > > + */
> > > > +static struct omap_hwmod_opt_clk am43xx_debugss_opt_clks[] = {
> > > > +   { .role = "dbg_sysclk", .clk = "dbg_sysclk_ck" },
> > > > +   { .role = "dbg_clka", .clk = "dbg_clka_ck", },
> > > > +   { .role = "dbg_clkb", .clk = "dbg_clkb_ck", },
> > > > +   { .role = "dbg_clkc", .clk = "dbg_clkc_ck", },
> > > > +};
> > > > +
> > > > +static struct omap_hwmod_class am43xx_debugss_hwmod_class = {
> > > > +   .name   = "debugss",
> > > > +};
> > > > +
> > > > +/* debugss */
> > > > +static struct omap_hwmod am43xx_debugss_hwmod = {
> > > > +   .name   = "debugss",
> > > > +   .class  = &am43xx_debugss_hwmod_class,
> > > > +   .clkdm_name = "l3_aon_clkdm",
> > > > +   .main_clk   = "trace_clk_div_ck",
> > > > +   .prcm = {
> > > > +   .omap4 = {
> > > > +   .clkctrl_offs = 
> > > > AM43XX_CM_WKUP_DBGSS_CLKCTRL_OFFSET,
> > > 
> > > According to Table 6-275 "PRCM_CM_WKUP_DBGSS_CLKCTRL Register Field 
> > > Descriptions" this should have a 
> > > 
> > >   .modulemode   = MODULEMODE_SWCTRL,
> > 
> > hm... modulemode SWCTRL causes wait_target_ready to fail. Any hints ?
> 
> gets stuck in transition state. PRCM_CM_WKUP_DBGSS_CLKCTRL is always
> read as 0x 12510f00 which would translate into:
> 
> - module disabled
> - all opt clocks are on
> - module is transitioning
> - module in standby
> - clkA as TPIU and STM trace clock
> - all dividers set to 2

just fyi, checking with HW folks, this might be a new bug, unless
debugss needs something special.

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH v3 0/5] Add support for Fujitsu USB host controller

[Felipe Balbi]

Hi,

On Sun, Jan 25, 2015 at 04:13:23PM +0800, Sneeker Yeh wrote:
> These patches add support for XHCI compliant Host controller found
> on Fujitsu Socs, and are based on http://lwn.net/Articles/629162/
> The first patch is to add Fujitsu glue layer of Synopsis DesignWare USB3 
> driver
> and last four patch is about quirk implementation of errata in Synopsis
> DesignWare USB3 IP.
> 
> Patch 1 introduces a quirk with device disconnection management necessary
> Synopsys Designware USB3 IP with versions < 3.00a and hardware configuration
> DWC_USB3_SUSPEND_ON_DISCONNECT_EN=1. It solves a problem where without the
> quirk, that host controller will die after a usb device is disconnected from
> port of root hub.
> 
> Patch 2 is to set Synopsis quirk in xhci platform driver based on xhci 
> platform
> data.
> 
> Patch 3 is to add a revison number 2.90a and 3.00a of Synopsis DesignWare USB3
> IP core driver.
> 
> Patch 4 introduces using a quirk based on a errata of Synopsis
> DesignWare USB3 IP which is versions < 3.00a and has hardware configuration
> DWC_USB3_SUSPEND_ON_DISCONNECT_EN=1, which cannot be read from software. As a
> result this quirk has to be enabled via platform data or device tree.
> 
> Patch 5 introduces Fujitsu Specific Glue layer in Synopsis DesignWare USB3 IP
> driver. 
> 

Mathias, let me know how you want to handle this. Either I take them
all, or you take them all. What do you prefer ?

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH] usb: phy-generic: Don't fail on missing gpio reset

[Felipe Balbi]

On Mon, Jan 26, 2015 at 05:45:29PM -0800, Soren Brinkmann wrote:
> A reset through a GPIO is optional. Don't fail probing when it is
> missing.
> 
> Reported-by: Andreas Färber 
> Signed-off-by: Soren Brinkmann 
> ---
> Hi Andreas,
> 
> does this do the trick?
> 
>   Thanks,
>   Sören
> 
>  drivers/usb/phy/phy-generic.c | 6 ++
>  1 file changed, 2 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/usb/phy/phy-generic.c b/drivers/usb/phy/phy-generic.c
> index dd05254241fb..a73d4c738f0b 100644
> --- a/drivers/usb/phy/phy-generic.c
> +++ b/drivers/usb/phy/phy-generic.c
> @@ -241,10 +241,8 @@ int usb_phy_gen_create_phy(struct device *dev, struct 
> usb_phy_generic *nop,
>  
>   if (err == -EPROBE_DEFER)
>   return -EPROBE_DEFER;
> - if (err) {
> - dev_err(dev, "Error requesting RESET GPIO\n");
> - return err;
> - }
> + if (err)
> + nop->gpiod_reset = NULL;

there's a better patch to use gpiod_get_optional(), instead.

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH 1/4] arm: omap: hwmod: 43xx: add DebugSS hwmod data

[Felipe Balbi]

Hi,

On Mon, Jan 26, 2015 at 10:56:40AM -0600, Felipe Balbi wrote:
> > the references below are from SPRUHL7
> > 
> > On Fri, 23 Jan 2015, Felipe Balbi wrote:
> > 
> > > Without hwmod data for DebugSS, performance monitors
> > > have no chance of running on AM43xx devices.
> > > 
> > > Signed-off-by: Felipe Balbi 
> > > ---
> > >  arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 40 
> > > ++
> > >  arch/arm/mach-omap2/prcm43xx.h |  1 +
> > >  2 files changed, 41 insertions(+)
> > > 
> > > diff --git a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c 
> > > b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
> > > index 5c6c8410160e..6709704dd5b5 100644
> > > --- a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
> > > +++ b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
> > > @@ -19,6 +19,7 @@
> > >  #include "omap_hwmod.h"
> > >  #include "omap_hwmod_33xx_43xx_common_data.h"
> > >  #include "prcm43xx.h"
> > > +#include "prm44xx.h"
> > >  #include "omap_hwmod_common_data.h"
> > >  
> > >  
> > > @@ -60,6 +61,44 @@ static struct omap_hwmod am43xx_wkup_m3_hwmod = {
> > >   .rst_lines_cnt  = ARRAY_SIZE(am33xx_wkup_m3_resets),
> > >  };
> > >  
> > > +/*
> > > + * 'debugss' class
> > > + * debug and emulation sub system
> > > + */
> > > +static struct omap_hwmod_opt_clk am43xx_debugss_opt_clks[] = {
> > > + { .role = "dbg_sysclk", .clk = "dbg_sysclk_ck" },
> > > + { .role = "dbg_clka", .clk = "dbg_clka_ck", },
> > > + { .role = "dbg_clkb", .clk = "dbg_clkb_ck", },
> > > + { .role = "dbg_clkc", .clk = "dbg_clkc_ck", },
> > > +};
> > > +
> > > +static struct omap_hwmod_class am43xx_debugss_hwmod_class = {
> > > + .name   = "debugss",
> > > +};
> > > +
> > > +/* debugss */
> > > +static struct omap_hwmod am43xx_debugss_hwmod = {
> > > + .name   = "debugss",
> > > + .class  = &am43xx_debugss_hwmod_class,
> > > + .clkdm_name = "l3_aon_clkdm",
> > > + .main_clk   = "trace_clk_div_ck",
> > > + .prcm = {
> > > + .omap4 = {
> > > + .clkctrl_offs = AM43XX_CM_WKUP_DBGSS_CLKCTRL_OFFSET,
> > 
> > According to Table 6-275 "PRCM_CM_WKUP_DBGSS_CLKCTRL Register Field 
> > Descriptions" this should have a 
> > 
> > .modulemode   = MODULEMODE_SWCTRL,
> 
> hm... modulemode SWCTRL causes wait_target_ready to fail. Any hints ?

gets stuck in transition state. PRCM_CM_WKUP_DBGSS_CLKCTRL is always
read as 0x 12510f00 which would translate into:

- module disabled
- all opt clocks are on
- module is transitioning
- module in standby
- clkA as TPIU and STM trace clock
- all dividers set to 2

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH 1/4] arm: omap: hwmod: 43xx: add DebugSS hwmod data

[Felipe Balbi]

Hi,

On Mon, Jan 26, 2015 at 02:04:35AM +, Paul Walmsley wrote:
> Hi
> 
> the references below are from SPRUHL7
> 
> On Fri, 23 Jan 2015, Felipe Balbi wrote:
> 
> > Without hwmod data for DebugSS, performance monitors
> > have no chance of running on AM43xx devices.
> > 
> > Signed-off-by: Felipe Balbi 
> > ---
> >  arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 40 
> > ++
> >  arch/arm/mach-omap2/prcm43xx.h |  1 +
> >  2 files changed, 41 insertions(+)
> > 
> > diff --git a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c 
> > b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
> > index 5c6c8410160e..6709704dd5b5 100644
> > --- a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
> > +++ b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
> > @@ -19,6 +19,7 @@
> >  #include "omap_hwmod.h"
> >  #include "omap_hwmod_33xx_43xx_common_data.h"
> >  #include "prcm43xx.h"
> > +#include "prm44xx.h"
> >  #include "omap_hwmod_common_data.h"
> >  
> >  
> > @@ -60,6 +61,44 @@ static struct omap_hwmod am43xx_wkup_m3_hwmod = {
> > .rst_lines_cnt  = ARRAY_SIZE(am33xx_wkup_m3_resets),
> >  };
> >  
> > +/*
> > + * 'debugss' class
> > + * debug and emulation sub system
> > + */
> > +static struct omap_hwmod_opt_clk am43xx_debugss_opt_clks[] = {
> > +   { .role = "dbg_sysclk", .clk = "dbg_sysclk_ck" },
> > +   { .role = "dbg_clka", .clk = "dbg_clka_ck", },
> > +   { .role = "dbg_clkb", .clk = "dbg_clkb_ck", },
> > +   { .role = "dbg_clkc", .clk = "dbg_clkc_ck", },
> > +};
> > +
> > +static struct omap_hwmod_class am43xx_debugss_hwmod_class = {
> > +   .name   = "debugss",
> > +};
> > +
> > +/* debugss */
> > +static struct omap_hwmod am43xx_debugss_hwmod = {
> > +   .name   = "debugss",
> > +   .class  = &am43xx_debugss_hwmod_class,
> > +   .clkdm_name = "l3_aon_clkdm",
> > +   .main_clk   = "trace_clk_div_ck",
> > +   .prcm = {
> > +   .omap4 = {
> > +   .clkctrl_offs = AM43XX_CM_WKUP_DBGSS_CLKCTRL_OFFSET,
> 
> According to Table 6-275 "PRCM_CM_WKUP_DBGSS_CLKCTRL Register Field 
> Descriptions" this should have a 
> 
>   .modulemode   = MODULEMODE_SWCTRL,

hm... modulemode SWCTRL causes wait_target_ready to fail. Any hints ?

> > +   },
> > +   },
> > +   .opt_clks   = am43xx_debugss_opt_clks,
> > +   .opt_clks_cnt   = ARRAY_SIZE(am43xx_debugss_opt_clks),
> > +};
> > +
> > +/* debugss -> l3_main_2 */
> > +static struct omap_hwmod_ocp_if am43xx_debugss__l3_main = {
> > +   .master = &am43xx_debugss_hwmod,
> > +   .slave  = &am33xx_l3_main_hwmod,
> > +   .clk= "sys_clkin_ck",
> > +   .user   = OCP_USER_MPU | OCP_USER_SDMA,
> > +};
> > +
> 
> According to Table 31-25 "Debug Modules Memory Mapping" there are a few 
> initiator ports on the DEBUGSS that are connected to various slave ports 
> on various chip-wide interconnects: L3_EMU, L4_PER, L4_WAKEUP, L4_CFG. I 
> would suggest starting by adding at least one of them as a struct 
> omap_hwmod_ocp_if record.  The one attached to L3_EMU would seem like a 
> good one to start with.

I'll have a look.

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH 3/4] clk: ti: 43xx: add debugss clocks to DT_CLK() table

[Felipe Balbi]

On Fri, Jan 23, 2015 at 05:11:43PM -0600, Felipe Balbi wrote:
> without these entries, omap_hwmod will not be
> able to find debugss clocks.
> 
> Signed-off-by: Felipe Balbi 
> ---
>  drivers/clk/ti/clk-43xx.c | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/drivers/clk/ti/clk-43xx.c b/drivers/clk/ti/clk-43xx.c
> index 3795fce8a830..46a597c815c9 100644
> --- a/drivers/clk/ti/clk-43xx.c
> +++ b/drivers/clk/ti/clk-43xx.c
> @@ -83,6 +83,12 @@ static struct ti_dt_clk am43xx_clks[] = {
>   DT_CLK(NULL, "gfx_fck_div_ck", "gfx_fck_div_ck"),
>   DT_CLK(NULL, "timer_32k_ck", "clkdiv32k_ick"),
>   DT_CLK(NULL, "timer_sys_ck", "sys_clkin_ck"),
> + DT_CLK(NULL, "trace_clk_div_ck", "trace_clk_div_ck"),
> + DT_CLK(NULL, "trace_pm_clk_mux_ck", "trace_pm_clk_mux_ck"),

hmmm, this should be trace_pmd_clk_mux_ck. How did this even work ? I'll
fix and retest.

Won't resend until tomorrow though.

-- 
balbi


signature.asc
Description: Digital signature

[PATCH 2/4] arm: dts: am4372: add missing debugss clocks

[Felipe Balbi]

These clocks are needed so that OMAP HWMOD can
control them when we're using performance
monitors.

Signed-off-by: Felipe Balbi 
---
 arch/arm/boot/dts/am43xx-clocks.dtsi | 51 
 1 file changed, 51 insertions(+)

diff --git a/arch/arm/boot/dts/am43xx-clocks.dtsi 
b/arch/arm/boot/dts/am43xx-clocks.dtsi
index c7dc9dab93a4..9000a5c5b719 100644
--- a/arch/arm/boot/dts/am43xx-clocks.dtsi
+++ b/arch/arm/boot/dts/am43xx-clocks.dtsi
@@ -362,6 +362,57 @@
clock-div = <1>;
};
 
+   dbg_sysclk_ck: dbg_sysclk_ck {
+   #clock-cells = <0>;
+   compatible = "ti,gate-clock";
+   clocks = <&sys_clkin_ck>;
+   ti,bit-shift = <8>;
+   reg = <0x20>;
+   };
+
+   dbg_clka_ck: dbg_clka_ck {
+   #clock-cells = <0>;
+   compatible = "ti,gate-clock";
+   clocks = <&sys_clkin_ck>;
+   ti,bit-shift = <9>;
+   reg = <0x20>;
+   };
+
+   dbg_clkb_ck: dbg_clkb_ck {
+   #clock-cells = <0>;
+   compatible = "ti,gate-clock";
+   clocks = <&sys_clkin_ck>;
+   ti,bit-shift = <10>;
+   reg = <0x20>;
+   };
+
+   dbg_clkc_ck: dbg_clkc_ck {
+   #clock-cells = <0>;
+   compatible = "ti,gate-clock";
+   clocks = <&sys_clkin_ck>;
+   ti,bit-shift = <11>;
+   reg = <0x20>;
+   };
+
+   trace_pmd_clk_mux_ck: trace_pmd_clk_mux_ck {
+   #clock-cells = <0>;
+   compatible = "ti,mux-clock";
+   clocks = <&dbg_sysclk_ck>, <&dbg_clka_ck>,
+   <&dbg_clkb_ck>, <&dbg_clkc_ck>;
+   ti,bit-shift = <22>;
+   reg = <0x20>;
+   };
+
+   trace_clk_div_ck: trace_clk_div_ck {
+   #clock-cells = <0>;
+   compatible = "ti,divider-clock";
+   clocks = <&trace_pmd_clk_mux_ck>;
+   ti,bit-shift = <24>;
+   ti,max-div = <4>;
+   reg = <0x20>;
+   ti,index-power-of-two;
+   };
+
pruss_ocp_gclk: pruss_ocp_gclk {
#clock-cells = <0>;
compatible = "ti,mux-clock";
-- 
2.3.0-rc1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/4] arm: omap: hwmod: 43xx: add DebugSS hwmod data

[Felipe Balbi]

Without hwmod data for DebugSS, performance monitors
have no chance of running on AM43xx devices.

Signed-off-by: Felipe Balbi 
---
 arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 40 ++
 arch/arm/mach-omap2/prcm43xx.h |  1 +
 2 files changed, 41 insertions(+)

diff --git a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
index 5c6c8410160e..6709704dd5b5 100644
--- a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
@@ -19,6 +19,7 @@
 #include "omap_hwmod.h"
 #include "omap_hwmod_33xx_43xx_common_data.h"
 #include "prcm43xx.h"
+#include "prm44xx.h"
 #include "omap_hwmod_common_data.h"
 
 
@@ -60,6 +61,44 @@ static struct omap_hwmod am43xx_wkup_m3_hwmod = {
.rst_lines_cnt  = ARRAY_SIZE(am33xx_wkup_m3_resets),
 };
 
+/*
+ * 'debugss' class
+ * debug and emulation sub system
+ */
+static struct omap_hwmod_opt_clk am43xx_debugss_opt_clks[] = {
+   { .role = "dbg_sysclk", .clk = "dbg_sysclk_ck" },
+   { .role = "dbg_clka", .clk = "dbg_clka_ck", },
+   { .role = "dbg_clkb", .clk = "dbg_clkb_ck", },
+   { .role = "dbg_clkc", .clk = "dbg_clkc_ck", },
+};
+
+static struct omap_hwmod_class am43xx_debugss_hwmod_class = {
+   .name   = "debugss",
+};
+
+/* debugss */
+static struct omap_hwmod am43xx_debugss_hwmod = {
+   .name   = "debugss",
+   .class  = &am43xx_debugss_hwmod_class,
+   .clkdm_name = "l3_aon_clkdm",
+   .main_clk   = "trace_clk_div_ck",
+   .prcm = {
+   .omap4 = {
+   .clkctrl_offs = AM43XX_CM_WKUP_DBGSS_CLKCTRL_OFFSET,
+   },
+   },
+   .opt_clks   = am43xx_debugss_opt_clks,
+   .opt_clks_cnt   = ARRAY_SIZE(am43xx_debugss_opt_clks),
+};
+
+/* debugss -> l3_main_2 */
+static struct omap_hwmod_ocp_if am43xx_debugss__l3_main = {
+   .master = &am43xx_debugss_hwmod,
+   .slave  = &am33xx_l3_main_hwmod,
+   .clk= "sys_clkin_ck",
+   .user   = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
 static struct omap_hwmod am43xx_control_hwmod = {
.name   = "control",
.class  = &am33xx_control_hwmod_class,
@@ -875,6 +914,7 @@ static struct omap_hwmod_ocp_if *am43xx_hwmod_ocp_ifs[] 
__initdata = {
&am33xx_l3_main__tptc1,
&am33xx_l3_main__tptc2,
&am33xx_l3_main__ocmc,
+   &am43xx_debugss__l3_main,
&am43xx_l4_hs__cpgmac0,
&am33xx_cpgmac0__mdio,
&am33xx_l3_main__sha0,
diff --git a/arch/arm/mach-omap2/prcm43xx.h b/arch/arm/mach-omap2/prcm43xx.h
index ad7b3e9977f8..bb42cd80526d 100644
--- a/arch/arm/mach-omap2/prcm43xx.h
+++ b/arch/arm/mach-omap2/prcm43xx.h
@@ -93,6 +93,7 @@
 #define AM43XX_CM_PER_TIMER5_CLKCTRL_OFFSET0x0548
 #define AM43XX_CM_PER_TIMER6_CLKCTRL_OFFSET0x0550
 #define AM43XX_CM_PER_TIMER7_CLKCTRL_OFFSET0x0558
+#define AM43XX_CM_WKUP_DBGSS_CLKCTRL_OFFSET0x0020
 #define AM43XX_CM_WKUP_WKUP_M3_CLKCTRL_OFFSET  0x0228
 #define AM43XX_CM_WKUP_CONTROL_CLKCTRL_OFFSET  0x0360
 #define AM43XX_CM_WKUP_SMARTREFLEX0_CLKCTRL_OFFSET 0x0350
-- 
2.3.0-rc1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 0/4] arm: am43xx: add PMU support

[Felipe Balbi]

Hi all,

with these patches we can use perf with AM43xx devices
and get actual statistics.

Full boot logs: http://hastebin.com/yoxaxurohu

Felipe Balbi (4):
  arm: omap: hwmod: 43xx: add DebugSS hwmod data
  arm: dts: am4372: add missing debugss clocks
  clk: ti: 43xx: add debugss clocks to DT_CLK() table
  arm: dts: am4372: add pmu DT data

 arch/arm/boot/dts/am4372.dtsi  |  8 +
 arch/arm/boot/dts/am43xx-clocks.dtsi   | 51 ++
 arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 40 +++
 arch/arm/mach-omap2/prcm43xx.h |  1 +
 drivers/clk/ti/clk-43xx.c  |  6 
 5 files changed, 106 insertions(+)

-- 
2.3.0-rc1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html