Re: [PATCH 2/2 v2] ARM: DRA7/335x/437x: hwmod: Remove gpmc address space from hwmod data

2015-10-23 Thread Paul Walmsley 
On Thu, 15 Oct 2015, Franklin S Cooper Jr wrote:

> GPMC address information is provided by device tree. No longer need
> to include this information within hwmod.
> 
> Signed-off-by: Franklin S Cooper Jr 

Thanks, queued.

- Paul
--
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

Re: MUSB peripheral DMA regression caused by driver core runtime PM change

2015-10-23 Thread Grygorii Strashko 
On 10/23/2015 07:48 PM, Felipe Balbi wrote:
> 
> Hi,
> 
> Tony Lindgren  writes:
>> From: Tony Lindgren 
>> Date: Fri, 23 Oct 2015 09:03:22 -0700
>> Subject: [PATCH] usb: musb: omap2430: Fix regression caused by driver core
>>   change
>>
>> Commit ddef08dd00f5 ("Driver core: wakeup the parent device before trying
>> probe") started automatically ensuring the parent device is enabled when
>> the child gets probed.
>>
>> This however caused a regression for MUSB omap2430 interface as the
>> runtime PM for the parent device needs the child initialized to access
>> the MUSB hardware registers.
>>
>> Let's delay the enabling of PM runtime for the parent until the child
>> has been properly initialized as suggested in an earlier patch by
>> Grygorii Strashko .
>>
>> In addition to delaying pm_runtime_enable, we now also need to make sure
>> the parent is enabled during omap2430_musb_init. We also want to propagate
>> an error from omap2430_runtime_resume if struct musb is not initialized.
>>
>> Note that we use pm_runtime_put_noidle here for both the child and parent
>> to prevent an extra runtime_suspend/resume cycle.
>>
>> Let's also add some comments to avoid confusion between the
>> two different devices.
>>
>> Fixes: ddef08dd00f5 ("Driver core: wakeup the parent device before
>> trying probe")
>> Suggested-by: Grygorii Strashko 
>> Signed-off-by: Tony Lindgren 
> 
> I'm fine with this patch to fix this v4.3 regression. Greg, do you want
> a pull request or can you take this in as a patch ? In any case:
> 
> Acked-by: Felipe Balbi 

Reviewed-by: Grygorii Strashko 

It always fun when DD/PM core is updated to fix some driver/subsystem's
specific PM issue :(

> 
>> --- a/drivers/usb/musb/omap2430.c
>> +++ b/drivers/usb/musb/omap2430.c
>> @@ -391,9 +391,20 @@ static int omap2430_musb_init(struct musb *musb)
>>  }
>>  musb->isr = omap2430_musb_interrupt;
>>   
>> +/*
>> + * Enable runtime PM for musb parent (this driver). We can't
>> + * do it earlier as struct musb is not yet allocated and we
>> + * need to touch the musb registers for runtime PM.
>> + */
>> +pm_runtime_enable(glue->dev);
>> +status = pm_runtime_get_sync(glue->dev);
>> +if (status < 0)
>> +goto err1;
>> +
>>  status = pm_runtime_get_sync(dev);

Hm. My assumption was that *Parent* device (omap2430) will be enabled
here :( But as I can see this will not happen:

static int rpm_resume(struct device *dev, int rpmflags)
{...
if (!parent && dev->parent) {
/*
 * Increment the parent's usage counter and resume it if
 * necessary.  Not needed if dev is irq-safe; then the
 * parent is permanently resumed.
 */
parent = dev->parent;
if (dev->power.irq_safe)
goto skip_parent;

^^^ and musb device is irq_safe :( 



>>  if (status < 0) {
>>  dev_err(dev, "pm_runtime_get_sync FAILED %d\n", status);
>> +pm_runtime_put_sync(glue->dev);
>>  goto err1;
>>  }
>>   
>> @@ -426,6 +437,7 @@ static int omap2430_musb_init(struct musb *musb)
>>  phy_power_on(musb->phy);
>>   
>>  pm_runtime_put_noidle(musb->controller);
>> +pm_runtime_put_noidle(glue->dev);
>>  return 0;
>>   
>>   err1:
>> @@ -626,7 +638,11 @@ static int omap2430_probe(struct platform_device *pdev)
>>  goto err2;
>>  }
>>   
>> -pm_runtime_enable(>dev);
>> +/*
>> + * Note that we cannot enable PM runtime yet for this
>> + * driver as we need struct musb initialized first.
>> + * See omap2430_musb_init above.
>> + */
>>   
>>  ret = platform_device_add(musb);
>>  if (ret) {
>> @@ -675,11 +691,12 @@ static int omap2430_runtime_resume(struct device *dev)
>>  struct omap2430_glue*glue = dev_get_drvdata(dev);
>>  struct musb *musb = glue_to_musb(glue);
>>   
>> -if (musb) {
>> -omap2430_low_level_init(musb);
>> -musb_writel(musb->mregs, OTG_INTERFSEL,
>> -musb->context.otg_interfsel);
>> -}
>> +if (!musb)
>> +return -EPROBE_DEFER;
>> +
>> +omap2430_low_level_init(musb);
>> +musb_writel(musb->mregs, OTG_INTERFSEL,
>> +musb->context.otg_interfsel);
>>   
>>  return 0;
>>   }
> 


-- 
regards,
-grygorii
--
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

Re: MUSB peripheral DMA regression caused by driver core runtime PM change

2015-10-23 Thread Alan Stern 
On Fri, 23 Oct 2015, Grygorii Strashko wrote:

> Reviewed-by: Grygorii Strashko 
> 
> It always fun when DD/PM core is updated to fix some driver/subsystem's
> specific PM issue :(
> 
> > 
> >> --- a/drivers/usb/musb/omap2430.c
> >> +++ b/drivers/usb/musb/omap2430.c
> >> @@ -391,9 +391,20 @@ static int omap2430_musb_init(struct musb *musb)
> >>}
> >>musb->isr = omap2430_musb_interrupt;
> >>   
> >> +  /*
> >> +   * Enable runtime PM for musb parent (this driver). We can't
> >> +   * do it earlier as struct musb is not yet allocated and we
> >> +   * need to touch the musb registers for runtime PM.
> >> +   */
> >> +  pm_runtime_enable(glue->dev);
> >> +  status = pm_runtime_get_sync(glue->dev);
> >> +  if (status < 0)
> >> +  goto err1;
> >> +
> >>status = pm_runtime_get_sync(dev);
> 
> Hm. My assumption was that *Parent* device (omap2430) will be enabled
> here :( But as I can see this will not happen:
> 
> static int rpm_resume(struct device *dev, int rpmflags)
> {...
>   if (!parent && dev->parent) {
>   /*
>* Increment the parent's usage counter and resume it if
>* necessary.  Not needed if dev is irq-safe; then the
>* parent is permanently resumed.
>*/
>   parent = dev->parent;
>   if (dev->power.irq_safe)
>   goto skip_parent;
> 
> ^^^ and musb device is irq_safe :( 

This way of doing things looks very strange.

If the omap2430 is the parent of the musb device, and
pm_runtime_irq_safe() has been called for the musb device, then after
that the omap2430 will never be runtime suspended.  Therefore it
doesn't matter whether you enable it for runtime PM or not.

It seems to me that the real problem must be that the musb device gets
runtime-enabled and marked irq_safe too early.  These things should 
happen before the musb device gets registered and exposed to userspace, 
but not before the omap2430 parent is runtime-enabled.

Thus the sequence of events should be:

Allocate the musb device;
Runtime-enable the omap2430 (since it is now safe to do so);
Runtime-enable the musb and declare it irq_safe (this will
automatically runtime-resume the omap2430);
Register the musb.

If things are done this way, no special action needs to be taken.

Alan Stern

--
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

Re: [PATCH 1/2 v2] ARM: DRA7/335x/437x/OMAP4: hwmod: Remove elm address space from hwmod data

2015-10-23 Thread Paul Walmsley 
On Thu, 15 Oct 2015, Franklin S Cooper Jr wrote:

> ELM address information is provided by device tree. No longer need
> to include this information within hwmod.
> 
> Signed-off-by: Franklin S Cooper Jr 

The OMAP4 DTS files don't have the ELM address space declared.  I'm going 
to drop that portion of your patch.  Could you please send a two-patch 
series that first adds the ELM address space to the OMAP4 DTS file and 
then subsequently drops it from the OMAP4 hwmod data file?


- Paul
--
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

[PATCH 1/5] Make am35x helper function declarations accessible

2015-10-23 Thread Rolf Peukert 
To be able to call these four helper functions from the M-USB AM35xx
glue code, their declarations need to be moved to a header file in the
kernels include hierarchy.

Signed-off-by: Rolf Peukert 
---
 arch/arm/mach-omap2/usb.h  | 5 -
 include/linux/platform_data/usb-omap.h | 5 +
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/arm/mach-omap2/usb.h b/arch/arm/mach-omap2/usb.h
index 3395365..8b0cdf5 100644
--- a/arch/arm/mach-omap2/usb.h
+++ b/arch/arm/mach-omap2/usb.h
@@ -63,8 +63,3 @@ struct usbhs_phy_data {
 extern void usb_musb_init(struct omap_musb_board_data *board_data);
 extern void usbhs_init(struct usbhs_omap_platform_data *pdata);
 extern int usbhs_init_phys(struct usbhs_phy_data *phy, int num_phys);
-
-extern void am35x_musb_reset(void);
-extern void am35x_musb_phy_power(u8 on);
-extern void am35x_musb_clear_irq(void);
-extern void am35x_set_mode(u8 musb_mode);
diff --git a/include/linux/platform_data/usb-omap.h
b/include/linux/platform_data/usb-omap.h
index fa579b4..328e899 100644
--- a/include/linux/platform_data/usb-omap.h
+++ b/include/linux/platform_data/usb-omap.h
@@ -86,3 +86,8 @@ enum musb_interface {
MUSB_INTERFACE_ULPI,
MUSB_INTERFACE_UTMI
 };
+
+extern void am35x_musb_reset(void);
+extern void am35x_musb_phy_power(u8 on);
+extern void am35x_musb_clear_irq(void);
+extern void am35x_set_mode(u8 musb_mode);
-- 
2.4.10

--
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

[PATCH 3/5] Add device tree support for M-USB on AM35xx SOCs

2015-10-23 Thread Rolf Peukert 
Add a function that sets up necessary data structures. In older kernels
this was done in a board_ file. To support initialization via a DT, this
now needs to be included in the probe() function.
Also declare a new device 'compatible' name (am35x-musb) to
differentiate it from omap3-musb.

Signed-off-by: Rolf Peukert 
---
 drivers/usb/musb/am35x.c | 73

 1 file changed, 73 insertions(+)

diff --git a/drivers/usb/musb/am35x.c b/drivers/usb/musb/am35x.c
index c41fe58..3c1477a 100644
--- a/drivers/usb/musb/am35x.c
+++ b/drivers/usb/musb/am35x.c
@@ -462,6 +462,59 @@ static const struct platform_device_info
am35x_dev_info = {
.dma_mask   = DMA_BIT_MASK(32),
 };

+static struct musb_hdrc_platform_data *am35x_get_config(
+   struct platform_device *pdev)
+{
+   struct musb_hdrc_platform_data *pdata;
+   struct omap_musb_board_data *bdata;
+   struct musb_hdrc_config *config;
+   struct device_node *np;
+   int val, ret;
+
+   pdata = devm_kzalloc(>dev, sizeof(*pdata), GFP_KERNEL);
+   if (!pdata)
+   goto err_out;
+
+   bdata = devm_kzalloc(>dev, sizeof(*bdata), GFP_KERNEL);
+   if (!bdata)
+   goto err_pdata;
+
+   config = devm_kzalloc(>dev, sizeof(*config), GFP_KERNEL);
+   if (!config)
+   goto err_bdata;
+
+   bdata->clear_irq = am35x_musb_clear_irq;
+   bdata->reset = am35x_musb_reset;
+   bdata->set_mode = am35x_set_mode;
+   bdata->set_phy_power = am35x_musb_phy_power;
+
+   pdata->board_data = bdata;
+   pdata->config = config;
+
+   /* Read settings from device tree */
+   np = pdev->dev.of_node;
+   if (np) {
+   of_property_read_u32(np, "mode", (u32 *)>mode);
+   of_property_read_u32(np, "interface-type",
+   (u32 *)>interface_type);
+   of_property_read_u32(np, "num-eps", (u32 *)>num_eps);
+   of_property_read_u32(np, "ram-bits", (u32 *)>ram_bits);
+   of_property_read_u32(np, "power", (u32 *)>power);
+
+   ret = of_property_read_u32(np, "multipoint", );
+   if (!ret && val)
+   config->multipoint = true;
+   }
+   return pdata;
+
+err_bdata:
+   devm_kfree(>dev, bdata);
+err_pdata:
+   devm_kfree(>dev, pdata);
+err_out:
+   return NULL;
+}
+
 static int am35x_probe(struct platform_device *pdev)
 {
struct musb_hdrc_platform_data  *pdata = dev_get_platdata(>dev);
@@ -479,6 +532,12 @@ static int am35x_probe(struct platform_device *pdev)
goto err0;
}

+   if (!pdata) {
+   pdata = am35x_get_config(pdev);
+   if (!pdata)
+   goto err1;
+   }
+
phy_clk = clk_get(>dev, "fck");
if (IS_ERR(phy_clk)) {
dev_err(>dev, "failed to get PHY clock\n");
@@ -548,6 +607,7 @@ err4:
clk_put(phy_clk);

 err3:
+err1:
kfree(glue);

 err0:
@@ -615,12 +675,25 @@ static int am35x_resume(struct device *dev)

 static SIMPLE_DEV_PM_OPS(am35x_pm_ops, am35x_suspend, am35x_resume);

+#ifdef CONFIG_OF
+static const struct of_device_id am35x_id_table[] = {
+   {
+   .compatible = "ti,am35x-musb"
+   },
+   {},
+};
+MODULE_DEVICE_TABLE(of, am35x_id_table);
+#endif
+
 static struct platform_driver am35x_driver = {
.probe  = am35x_probe,
.remove = am35x_remove,
.driver = {
.name   = "musb-am35x",
.pm = _pm_ops,
+#ifdef CONFIG_OF
+   .of_match_table = of_match_ptr(am35x_id_table),
+#endif
},
 };

-- 
2.4.10

--
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

[PATCH 0/5] Device tree support for AM35xx M-USB driver

2015-10-23 Thread Rolf Peukert 
The M-USB drivers glue code for AM35xx SOCs does not yet support device
trees.

In legacy kernels, it was left to the respective board_ file to set up
some necessary data structures before calling am35x_probe(). To support
initialization using a DT, this now needs to be done in am35x.c.

These data structures including a set of four pointers to CPU-specific
helper functions from the mach-omap2 directory.

Unfortunately those functions are only declared locally under
arch/arm/mach-omap2/, and they can not easily be moved over to am35x.c.
(While they just set a few bits in some system control module registers,
they call functions from control.c to access the SCM. These control.c
functions are also declared locally in mach-omap2 and not exported,
and use some static variables and several other local include files.)

So if we want these four functions to be accessible from the driver glue
code, their declarations have to be moved to the include/ hierarchy and
their names need to be exported. This makes it possible to use the am35x
M-USB driver as a kernel module.

The patch defines a new device 'compatible' name (am35x-musb) to
differentiate it from omap3-musb. It also adds clock name declarations
for interface and function clock to the device tree, so the am35x
glue code's clk_get() calls can find them.

Rolf Peukert (5):
  Make am35x helper function declarations accessible
  Export am35x helper functions
  Add device tree support for M-USB on AM35xx SOCs
  Use new MUSB device name in AM3517 device tree.
  Add some information about the new DT device name

 Documentation/devicetree/bindings/usb/omap-usb.txt | 35 +++
 arch/arm/boot/dts/am3517.dtsi  |  4 +-
 arch/arm/mach-omap2/omap_phy_internal.c|  4 ++
 arch/arm/mach-omap2/usb.h  |  5 --
 drivers/usb/musb/am35x.c   | 73
++
 include/linux/platform_data/usb-omap.h |  5 ++
 6 files changed, 120 insertions(+), 6 deletions(-)

-- 
2.4.10
--
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

[PATCH 2/5] Export am35x helper functions

2015-10-23 Thread Rolf Peukert 
To be able to call these four helper functions from a M-USB AM35x driver
module, their name symbols need to be exported.

Signed-off-by: Rolf Peukert 
---
 arch/arm/mach-omap2/omap_phy_internal.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/mach-omap2/omap_phy_internal.c
b/arch/arm/mach-omap2/omap_phy_internal.c
index 8e90356..648a60f 100644
--- a/arch/arm/mach-omap2/omap_phy_internal.c
+++ b/arch/arm/mach-omap2/omap_phy_internal.c
@@ -82,6 +82,7 @@ void am35x_musb_reset(void)

regval = omap_ctrl_readl(AM35XX_CONTROL_IP_SW_RESET);
 }
+EXPORT_SYMBOL(am35x_musb_reset);

 void am35x_musb_phy_power(u8 on)
 {
@@ -120,6 +121,7 @@ void am35x_musb_phy_power(u8 on)
omap_ctrl_writel(devconf2, AM35XX_CONTROL_DEVCONF2);
}
 }
+EXPORT_SYMBOL(am35x_musb_phy_power);

 void am35x_musb_clear_irq(void)
 {
@@ -130,6 +132,7 @@ void am35x_musb_clear_irq(void)
omap_ctrl_writel(regval, AM35XX_CONTROL_LVL_INTR_CLEAR);
regval = omap_ctrl_readl(AM35XX_CONTROL_LVL_INTR_CLEAR);
 }
+EXPORT_SYMBOL(am35x_musb_clear_irq);

 void am35x_set_mode(u8 musb_mode)
 {
@@ -152,3 +155,4 @@ void am35x_set_mode(u8 musb_mode)

omap_ctrl_writel(devconf2, AM35XX_CONTROL_DEVCONF2);
 }
+EXPORT_SYMBOL(am35x_set_mode);
-- 
2.4.10

--
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

[PATCH 4/5] Use new MUSB device name in AM3517 device tree.

2015-10-23 Thread Rolf Peukert 
Use new MUSB device name in AM3517 device tree and add name declarations
for interface and function clock, so the am35x drivers clk_get() calls
can find them.

Signed-off-by: Rolf Peukert 
---
 arch/arm/boot/dts/am3517.dtsi | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/am3517.dtsi b/arch/arm/boot/dts/am3517.dtsi
index 0b1c07f5..10838b5 100644
--- a/arch/arm/boot/dts/am3517.dtsi
+++ b/arch/arm/boot/dts/am3517.dtsi
@@ -17,9 +17,11 @@

ocp {
am35x_otg_hs: am35x_otg_hs@5c04 {
-   compatible = "ti,omap3-musb";
+   compatible = "ti,am35x-musb";
ti,hwmods = "am35x_otg_hs";
status = "disabled";
+   clocks = <_ick_am35xx>, <_fck_am35xx>;
+   clock-names = "ick", "fck";
reg = <0x5c04 0x1000>;
interrupts = <71>;
interrupt-names = "mc";
-- 
2.4.10

--
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

[PATCH 5/5] Add information about the new DT device name

2015-10-23 Thread Rolf Peukert 
Add some information about the new device name to the DT documentation.

Signed-off-by: Rolf Peukert 
---
 Documentation/devicetree/bindings/usb/omap-usb.txt | 35
++
 1 file changed, 35 insertions(+)

diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt
b/Documentation/devicetree/bindings/usb/omap-usb.txt
index 38d9bb8..cf98f61 100644
--- a/Documentation/devicetree/bindings/usb/omap-usb.txt
+++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
@@ -78,3 +78,38 @@ omap_dwc3 {
ranges;
 };

+AM35x MUSB GLUE
+ - compatible : Should be "ti,am35x-musb"
+ - ti,hwmods : must be "am35x_otg_hs"
+ - multipoint : Should be "1" indicating the musb controller supports
+   multipoint. This is a MUSB configuration-specific setting.
+ - num-eps : Specifies the number of endpoints. This is also a
+   MUSB configuration-specific setting. Should be set to "16"
+ - ram-bits : Specifies the ram address size. Should be set to "12"
+ - interface-type : Should be set to "1". (The AM35xx SOCs feature an
+   integrated phy, connected via UTMI+)
+ - mode : Should be "3" to represent OTG. "1" signifies HOST and "2"
+   represents PERIPHERAL.
+ - power : Should be "50". This signifies the controller can supply up to
+   100mA when operating in host mode.
+
+SOC specific device node entry
+am35x_otg_hs: am35x_otg_hs@5c04 {
+   compatible = "ti,am35x-musb";
+   ti,hwmods = "am35x_otg_hs";
+   clocks = <_ick_am35xx>, <_fck_am35xx>;
+   clock-names = "ick", "fck";
+   reg = <0x5c04 0x1000>;
+   interrupts = <71>;
+   interrupt-names = "mc";
+};
+
+Board specific device node entry
+_otg_hs {
+   mode = <1>;
+   interface-type = <1>;
+   multipoint = <1>;
+   num-eps = <16>;
+   ram-bits = <12>;
+   power = <50>;
+};
-- 
2.4.10

--
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

[PATCH] ARM: dts: Change I2C2 and I2C3 to 400KHz for LogicPD Torpedo DM3730 devkit

2015-10-23 Thread Adam Ford 
When used with the Logic PD development kit, this makes the I2C buses match
the BSP released by Logic PD.
---
 arch/arm/boot/dts/logicpd-torpedo-som.dtsi | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/logicpd-torpedo-som.dtsi 
b/arch/arm/boot/dts/logicpd-torpedo-som.dtsi
index 9777ff4..c8091ff 100644
--- a/arch/arm/boot/dts/logicpd-torpedo-som.dtsi
+++ b/arch/arm/boot/dts/logicpd-torpedo-som.dtsi
@@ -104,6 +104,14 @@
};
 };
 
+ {
+   clock-frequency = <40>;
+};
+
+ {
+   clock-frequency = <40>;
+};
+
 /*
  * Only found on the wireless SOM. For the SOM without wireless, the pins for
  * MMC3 can be routed with jumpers to the second MMC slot on the devkit and
-- 
1.9.1

--
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

Re: [PATCH] ARM: dts: am335x-boneblack: Use pinctrl constants

2015-10-23 Thread Andrew F. Davis 

On 10/22/2015 04:23 PM, Tony Lindgren wrote:

* Andrew F. Davis  [151022 09:21]:

Using constants for pinctrl allows better readability and removes
redundancy with comments.


You should use the include/dt-bindings/pinctrl/omap.h macro
AM33XX_IOPAD(pa, val) while at it. Otherwise we'll end up patching
the same things again later on.



Hmm, I haven't really been following this change, it kind of seems to add
some unnecessary abstraction by using physical hardware addresses instead
of offsets, then just converting them back to offsets. The offset style DT
nodes are already auto-generated with existing tools anyway:
https://dev.ti.com/pinmux

I'm sure this has been discussed already so if this is a blocker I'll
re-spin this.

Andrew


Regards,

Tony


Signed-off-by: Andrew F. Davis 
---
  arch/arm/boot/dts/am335x-boneblack.dts | 44 +-
  1 file changed, 22 insertions(+), 22 deletions(-)

diff --git a/arch/arm/boot/dts/am335x-boneblack.dts 
b/arch/arm/boot/dts/am335x-boneblack.dts
index eadbba3..a540a10 100644
--- a/arch/arm/boot/dts/am335x-boneblack.dts
+++ b/arch/arm/boot/dts/am335x-boneblack.dts
@@ -36,32 +36,32 @@
  _pinmux {
nxp_hdmi_bonelt_pins: nxp_hdmi_bonelt_pins {
pinctrl-single,pins = <
-   0x1b0 0x03  /* xdma_event_intr0, OMAP_MUX_MODE3 | 
AM33XX_PIN_OUTPUT */
-   0xa0 0x08   /* lcd_data0.lcd_data0, OMAP_MUX_MODE0 
| AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
-   0xa4 0x08   /* lcd_data1.lcd_data1, OMAP_MUX_MODE0 
| AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
-   0xa8 0x08   /* lcd_data2.lcd_data2, OMAP_MUX_MODE0 
| AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
-   0xac 0x08   /* lcd_data3.lcd_data3, OMAP_MUX_MODE0 
| AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
-   0xb0 0x08   /* lcd_data4.lcd_data4, OMAP_MUX_MODE0 
| AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
-   0xb4 0x08   /* lcd_data5.lcd_data5, OMAP_MUX_MODE0 
| AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
-   0xb8 0x08   /* lcd_data6.lcd_data6, OMAP_MUX_MODE0 
| AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
-   0xbc 0x08   /* lcd_data7.lcd_data7, OMAP_MUX_MODE0 
| AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
-   0xc0 0x08   /* lcd_data8.lcd_data8, OMAP_MUX_MODE0 
| AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
-   0xc4 0x08   /* lcd_data9.lcd_data9, OMAP_MUX_MODE0 
| AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
-   0xc8 0x08   /* lcd_data10.lcd_data10, 
OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
-   0xcc 0x08   /* lcd_data11.lcd_data11, 
OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
-   0xd0 0x08   /* lcd_data12.lcd_data12, 
OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
-   0xd4 0x08   /* lcd_data13.lcd_data13, 
OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
-   0xd8 0x08   /* lcd_data14.lcd_data14, 
OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
-   0xdc 0x08   /* lcd_data15.lcd_data15, 
OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
-   0xe0 0x00   /* lcd_vsync.lcd_vsync, OMAP_MUX_MODE0 
| AM33XX_PIN_OUTPUT */
-   0xe4 0x00   /* lcd_hsync.lcd_hsync, OMAP_MUX_MODE0 
| AM33XX_PIN_OUTPUT */
-   0xe8 0x00   /* lcd_pclk.lcd_pclk, OMAP_MUX_MODE0 | 
AM33XX_PIN_OUTPUT */
-   0xec 0x00   /* lcd_ac_bias_en.lcd_ac_bias_en, 
OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT */
+   0x1b0 (PIN_OUTPUT_PULLDOWN | MUX_MODE3) /* 
xdma_event_intr0 */
+   0xa0 (PIN_OUTPUT | MUX_MODE0)   /* 
lcd_data0.lcd_data0 */
+   0xa4 (PIN_OUTPUT | MUX_MODE0)   /* 
lcd_data1.lcd_data1 */
+   0xa8 (PIN_OUTPUT | MUX_MODE0)   /* 
lcd_data2.lcd_data2 */
+   0xac (PIN_OUTPUT | MUX_MODE0)   /* 
lcd_data3.lcd_data3 */
+   0xb0 (PIN_OUTPUT | MUX_MODE0)   /* 
lcd_data4.lcd_data4 */
+   0xb4 (PIN_OUTPUT | MUX_MODE0)   /* 
lcd_data5.lcd_data5 */
+   0xb8 (PIN_OUTPUT | MUX_MODE0)   /* 
lcd_data6.lcd_data6 */
+   0xbc (PIN_OUTPUT | MUX_MODE0)   /* 
lcd_data7.lcd_data7 */
+   0xc0 (PIN_OUTPUT | MUX_MODE0)   /* 
lcd_data8.lcd_data8 */
+   0xc4 (PIN_OUTPUT | MUX_MODE0)   /* 
lcd_data9.lcd_data9 */
+   0xc8 (PIN_OUTPUT | MUX_MODE0)   /* 
lcd_data10.lcd_data10 */
+   0xcc (PIN_OUTPUT | MUX_MODE0)   /* 
lcd_data11.lcd_data11 */
+   0xd0

Re: MUSB peripheral DMA regression caused by driver core runtime PM change

2015-10-23 Thread Grygorii Strashko 

On 10/23/2015 02:01 AM, Tony Lindgren wrote:

* Tony Lindgren  [151022 11:03]:

* Tony Lindgren  [151021 16:44]:

Hi all,

I noticed a regresssino in v4.3-rc series to day with MUSB gadgets
and DMA. Doing a git bisect between v4.2..v4.3-rc1 on it pointed to:

ddef08dd00f5 ("Driver core: wakeup the parent device before trying probe")

With the commit above reverted things work fine with DMA and USB gadgets.

This is on omap3 with CONFIG_USB_INVENTRA_DMA selected. Selecting
CONFIG_MUSB_PIO_ONLY still works even without reverting ddef08dd00f5.

Anybody got ideas what might be wrong? Some wrong runtime PM usage
under drivers/usb/musb?


Here's some more debug info on where things are different initializing
the USB gadgets. I added some printks and diffed the dmesg output. The
added calls from commit ddef08dd00f5 start with dd:


Well turns out the problem actually happens earlier. We end up calling
omap2430_runtime_resume with NULL struct musb while EPROBE_DEFER
probing.

No ideas yet how it should be fixed though.



I'm not sure, but below diff might help

diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index 70f2b8a..aba8ca7 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -391,6 +391,8 @@ static int omap2430_musb_init(struct musb *musb)
}
musb->isr = omap2430_musb_interrupt;

+   pm_runtime_enable(glue->dev);
+
status = pm_runtime_get_sync(dev);
if (status < 0) {
dev_err(dev, "pm_runtime_get_sync FAILED %d\n", status);
@@ -626,8 +628,6 @@ static int omap2430_probe(struct platform_device *pdev)
goto err2;
}

-   pm_runtime_enable(>dev);
-
ret = platform_device_add(musb);
if (ret) {
dev_err(>dev, "failed to register musb device\n");




--
regards,
-grygorii
--
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

[PATCH] drivers: net: cpsw: use module_platform_driver

2015-10-23 Thread Grygorii Strashko 
There is no reasons to probe cpsw from late_initcall level
and it's not recommended. Hence, use module_platform_driver()
to register and probe cpsw driver from module_init() level.

Cc: Tony Lindgren 
Acked-by: Mugunthan V N 
Signed-off-by: Grygorii Strashko 
---
 drivers/net/ethernet/ti/cpsw.c | 12 +---
 1 file changed, 1 insertion(+), 11 deletions(-)

diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index 8fc90f1..e35a34d 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -2578,17 +2578,7 @@ static struct platform_driver cpsw_driver = {
.remove = cpsw_remove,
 };
 
-static int __init cpsw_init(void)
-{
-   return platform_driver_register(_driver);
-}
-late_initcall(cpsw_init);
-
-static void __exit cpsw_exit(void)
-{
-   platform_driver_unregister(_driver);
-}
-module_exit(cpsw_exit);
+module_platform_driver(cpsw_driver);
 
 MODULE_LICENSE("GPL");
 MODULE_AUTHOR("Cyril Chemparathy ");
-- 
2.6.2

--
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

[PATCH] ARM: dts: Set VAUX1 and VAUX4 to 3.0V and 1.8V respectively

2015-10-23 Thread Adam Ford 
The development kit schematic expects VAUX1 to be 3.0V.  Most users use the 
development kit as a reference.
The development kit schematic expects VAUX4 to be 1.8V.  VAUX4 powers VDDS_CSI2 
on processor.  If the voltage is too high it could damage the processor.
If it's too low, it won't work.
---
 arch/arm/boot/dts/logicpd-torpedo-37xx-devkit.dts | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/boot/dts/logicpd-torpedo-37xx-devkit.dts 
b/arch/arm/boot/dts/logicpd-torpedo-37xx-devkit.dts
index afc13e5..b07d1d9 100644
--- a/arch/arm/boot/dts/logicpd-torpedo-37xx-devkit.dts
+++ b/arch/arm/boot/dts/logicpd-torpedo-37xx-devkit.dts
@@ -73,6 +73,16 @@
};
 };
 
+ {
+   regulator-min-microvolt = <300>;
+   regulator-max-microvolt = <300>;
+};
+
+ {
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <180>;
+};
+
  {
status = "okay";
 };
-- 
1.9.1

--
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

Re: [PATCH] drivers: net: cpsw: use module_platform_driver

2015-10-23 Thread David Miller 
From: Grygorii Strashko 
Date: Fri, 23 Oct 2015 14:41:12 +0300

> There is no reasons to probe cpsw from late_initcall level
> and it's not recommended. Hence, use module_platform_driver()
> to register and probe cpsw driver from module_init() level.
> 
> Cc: Tony Lindgren 
> Acked-by: Mugunthan V N 
> Signed-off-by: Grygorii Strashko 

Applied to net-next, thanks.
--
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

[PATCH] ARM: dts: Add audio support for LogicPD Torpedo DM3730 devkit

2015-10-23 Thread Adam Ford 
Use the TWL4030 Codec with mcbsp2 on Torpedo.

Signed-off-by: Adam Ford 
---
 arch/arm/boot/dts/logicpd-torpedo-37xx-devkit.dts | 10 ++
 arch/arm/boot/dts/logicpd-torpedo-som.dtsi| 13 +
 2 files changed, 23 insertions(+)

diff --git a/arch/arm/boot/dts/logicpd-torpedo-37xx-devkit.dts 
b/arch/arm/boot/dts/logicpd-torpedo-37xx-devkit.dts
index 5b04300..afc13e5 100644
--- a/arch/arm/boot/dts/logicpd-torpedo-37xx-devkit.dts
+++ b/arch/arm/boot/dts/logicpd-torpedo-37xx-devkit.dts
@@ -48,6 +48,12 @@
};
};
 
+   sound {
+   compatible = "ti,omap-twl4030";
+   ti,model = "omap3logic";
+   ti,mcbsp = <>;
+   };
+
leds {
compatible = "gpio-leds";
pinctrl-names = "default";
@@ -67,6 +73,10 @@
};
 };
 
+ {
+   status = "okay";
+};
+
  {
ti,bb-uvolt = <320>;
ti,bb-uamp = <150>;
diff --git a/arch/arm/boot/dts/logicpd-torpedo-som.dtsi 
b/arch/arm/boot/dts/logicpd-torpedo-som.dtsi
index 36387b1..9777ff4 100644
--- a/arch/arm/boot/dts/logicpd-torpedo-som.dtsi
+++ b/arch/arm/boot/dts/logicpd-torpedo-som.dtsi
@@ -96,6 +96,11 @@
reg = <0x48>;
interrupts = <7>; /* SYS_NIRQ cascaded to intc */
interrupt-parent = <>;
+   twl_audio: audio {
+   compatible = "ti,twl4030-audio";
+   codec {
+   };
+   };
};
 };
 
@@ -136,6 +141,14 @@
OMAP3_CORE1_IOPAD(0x218e, PIN_OUTPUT | MUX_MODE4)   
/* mcbsp1_fsr.gpio_157 */
>;
};
+   mcbsp2_pins: pinmux_mcbsp2_pins {
+   pinctrl-single,pins = <
+   OMAP3_CORE1_IOPAD(0x213c, PIN_INPUT | MUX_MODE0)
/* mcbsp2_fsx */
+   OMAP3_CORE1_IOPAD(0x213e, PIN_INPUT | MUX_MODE0)
/* mcbsp2_clkx */
+   OMAP3_CORE1_IOPAD(0x2140, PIN_INPUT | MUX_MODE0)
/* mcbsp2_dr */
+   OMAP3_CORE1_IOPAD(0x2142, PIN_OUTPUT | MUX_MODE0)   
/* mcbsp2_dx */
+   >;
+   };
 };
 
 _pmx_core2 {
-- 
1.9.1

--
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

OMAP baseline test results for v4.3-rc6

2015-10-23 Thread Paul Walmsley 

Here are some basic OMAP test results for Linux v4.3-rc6.
Logs and other details at:

http://www.pwsan.com/omap/testlogs/test_v4.3-rc6/20151018200945/


Test summary


Build: uImage:
Pass ( 3/ 3): omap1_defconfig, omap1_defconfig_1510innovator_only,
  omap1_defconfig_5912osk_only

Build: uImage+dtb:
Pass (13/13): omap2plus_defconfig_am33xx_only/am335x-bone,
  omap2plus_defconfig/omap4-panda,
  omap2plus_defconfig/omap4-panda-es,
  omap2plus_defconfig/omap4-var-stk-om44,
  omap2plus_defconfig/omap3-evm-37xx,
  omap2plus_defconfig_n800_only_a/omap2420-n800,
  omap2plus_defconfig/omap2430-sdp,
  omap2plus_defconfig/am3517-evm,
  omap2plus_defconfig/omap3-beagle,
  omap2plus_defconfig/omap3-beagle-xm,
  omap2plus_defconfig/omap3-sbc-t3517,
  omap2plus_defconfig/omap5-uevm,
  omap2plus_defconfig/omap5-sbc-t54

Build: zImage:
Pass (17/17): omap2plus_defconfig, omap2plus_defconfig_am33xx_only,
  omap2plus_defconfig_n800_only_a,
  omap2plus_defconfig_n800_multi_omap2xxx,
  omap2plus_defconfig_2430sdp_only,
  omap2plus_defconfig_cpupm, omap2plus_defconfig_no_pm,
  omap2plus_defconfig_omap2_4_only,
  omap2plus_defconfig_omap3_4_only,
  omap2plus_defconfig_omap5_only,
  omap2plus_defconfig_dra7xx_only,
  omap2plus_defconfig_am43xx_only,
  rmk_omap3430_ldp_oldconfig,
  rmk_omap3430_ldp_allnoconfig,
  rmk_omap4430_sdp_oldconfig,
  rmk_omap4430_sdp_allnoconfig, multi_v7_defconfig

Build warnings from toolchain: uImage:
(none)

Build warnings from toolchain: uImage+dtb:
(none)

Build warnings from toolchain: zImage:
FAIL (10/17): omap2plus_defconfig, omap2plus_defconfig_am33xx_only,
  omap2plus_defconfig_2430sdp_only,
  omap2plus_defconfig_cpupm, omap2plus_defconfig_no_pm,
  omap2plus_defconfig_omap2_4_only,
  omap2plus_defconfig_omap3_4_only,
  omap2plus_defconfig_omap5_only,
  omap2plus_defconfig_dra7xx_only,
  omap2plus_defconfig_am43xx_only

Boot to userspace:
FAIL ( 1/17): 2430sdp
skip ( 3/17): 5912osk, 3517evm, 5430es2sbct54
Pass (13/17): am335xbonelt, am335xbone, 4430es2panda, 4460pandaes,
  4460varsomom, 37xxevm, 3530es3beagle, 3530es31beagle,
  3730beaglexm, 3730es12beaglexm, cmt3517, 5430es2uevm,
  2420n800

Kernel warnings during boot to userspace:
FAIL ( 2/17): 4430es2panda, cmt3517

PM: chip retention via suspend:
FAIL ( 6/11): am335xbonelt, 4430es2panda, 4460varsomom, 37xxevm,
  2430sdp, 5430es2uevm
Pass ( 5/11): 4460pandaes, 3530es3beagle, 3530es31beagle,
  3730beaglexm, 3730es12beaglexm

PM: chip retention via dynamic idle:
FAIL ( 7/11): am335xbonelt, 4430es2panda, 4460pandaes,
  4460varsomom, 37xxevm, 2430sdp, 5430es2uevm
Pass ( 4/11): 3530es3beagle, 3530es31beagle, 3730beaglexm,
  3730es12beaglexm

PM: chip off (except CORE, due to errata) via suspend:
Pass ( 1/ 1): 3730beaglexm

PM: chip off (except CORE, due to errata) via dynamic idle:
Pass ( 1/ 1): 3730beaglexm

PM: chip off via suspend:
FAIL ( 1/ 4): 37xxevm
Pass ( 3/ 4): 3530es3beagle, 3530es31beagle, 3730es12beaglexm

PM: chip off via dynamic idle:
FAIL ( 1/ 4): 37xxevm
Pass ( 3/ 4): 3530es3beagle, 3530es31beagle, 3730es12beaglexm

Kernel warnings during PM test:
FAIL ( 1/17): 4430es2panda

Obsolete Kconfig symbols:
FAIL ( 2/20): omap2plus_defconfig, multi_v7_defconfig


vmlinux object size
(delta in bytes from test_v4.3-rc5 (25cb62b76430a91cc6195f902e61c2cb84ade622)):
   text data  bsstotal  kernel
+7200  +72  omap1_defconfig
+8000  +80  omap1_defconfig_1510innovator_only
+8000  +80  omap1_defconfig_5912osk_only
 +400   +4  multi_v7_defconfig
   +12400 +124  omap2plus_defconfig
+9200  +92  omap2plus_defconfig_2430sdp_only
   +12400 +124  omap2plus_defconfig_am33xx_only
+6000  +60  omap2plus_defconfig_am43xx_only
+6000  +60  omap2plus_defconfig_cpupm
+6000  +60  omap2plus_defconfig_dra7xx_only
+6000  +60  omap2plus_defconfig_n800_multi_omap2xxx
+3200  +32  omap2plus_defconfig_n800_only_a
+6000  +60  omap2plus_defconfig_no_pm
+60   -80  +52  omap2plus_defconfig_omap2_4_only
   +124

Re: MUSB peripheral DMA regression caused by driver core runtime PM change

2015-10-23 Thread Tony Lindgren 
* Grygorii Strashko  [151023 05:50]:
> On 10/23/2015 02:01 AM, Tony Lindgren wrote:
> >* Tony Lindgren  [151022 11:03]:
> >>* Tony Lindgren  [151021 16:44]:
> >>>Hi all,
> >>>
> >>>I noticed a regresssino in v4.3-rc series to day with MUSB gadgets
> >>>and DMA. Doing a git bisect between v4.2..v4.3-rc1 on it pointed to:
> >>>
> >>>ddef08dd00f5 ("Driver core: wakeup the parent device before trying probe")
> >>>
> >>>With the commit above reverted things work fine with DMA and USB gadgets.
> >>>
> >>>This is on omap3 with CONFIG_USB_INVENTRA_DMA selected. Selecting
> >>>CONFIG_MUSB_PIO_ONLY still works even without reverting ddef08dd00f5.
> >>>
> >>>Anybody got ideas what might be wrong? Some wrong runtime PM usage
> >>>under drivers/usb/musb?
> >>
> >>Here's some more debug info on where things are different initializing
> >>the USB gadgets. I added some printks and diffed the dmesg output. The
> >>added calls from commit ddef08dd00f5 start with dd:
> >
> >Well turns out the problem actually happens earlier. We end up calling
> >omap2430_runtime_resume with NULL struct musb while EPROBE_DEFER
> >probing.
> >
> >No ideas yet how it should be fixed though.
> >
> 
> I'm not sure, but below diff might help
> 
> diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
> index 70f2b8a..aba8ca7 100644
> --- a/drivers/usb/musb/omap2430.c
> +++ b/drivers/usb/musb/omap2430.c
> @@ -391,6 +391,8 @@ static int omap2430_musb_init(struct musb *musb)
> }
> musb->isr = omap2430_musb_interrupt;
> 
> +   pm_runtime_enable(glue->dev);
> +
> status = pm_runtime_get_sync(dev);
> if (status < 0) {
> dev_err(dev, "pm_runtime_get_sync FAILED %d\n", status);
> @@ -626,8 +628,6 @@ static int omap2430_probe(struct platform_device *pdev)
> goto err2;
> }
> 
> -   pm_runtime_enable(>dev);
> -
> ret = platform_device_add(musb);
> if (ret) {
> dev_err(>dev, "failed to register musb device\n");

Well almost.. We need to now also ensure that things are enabled during
omap2430_musb_init. Something like this might be the minimal fix for the
-rc cycle.

8< -
From: Tony Lindgren 
Date: Fri, 23 Oct 2015 09:03:22 -0700
Subject: [PATCH] usb: musb: omap2430: Fix regression caused by driver core
 change

Commit ddef08dd00f5 ("Driver core: wakeup the parent device before trying
probe") started automatically ensuring the parent device is enabled when
the child gets probed.

This however caused a regression for MUSB omap2430 interface as the
runtime PM for the parent device needs the child initialized to access
the MUSB hardware registers.

Let's delay the enabling of PM runtime for the parent until the child
has been properly initialized as suggested in an earlier patch by
Grygorii Strashko .

In addition to delaying pm_runtime_enable, we now also need to make sure
the parent is enabled during omap2430_musb_init. We also want to propagate
an error from omap2430_runtime_resume if struct musb is not initialized.

Note that we use pm_runtime_put_noidle here for both the child and parent
to prevent an extra runtime_suspend/resume cycle.

Let's also add some comments to avoid confusion between the
two different devices.

Fixes: ddef08dd00f5 ("Driver core: wakeup the parent device before
trying probe")
Suggested-by: Grygorii Strashko 
Signed-off-by: Tony Lindgren 

--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -391,9 +391,20 @@ static int omap2430_musb_init(struct musb *musb)
}
musb->isr = omap2430_musb_interrupt;
 
+   /*
+* Enable runtime PM for musb parent (this driver). We can't
+* do it earlier as struct musb is not yet allocated and we
+* need to touch the musb registers for runtime PM.
+*/
+   pm_runtime_enable(glue->dev);
+   status = pm_runtime_get_sync(glue->dev);
+   if (status < 0)
+   goto err1;
+
status = pm_runtime_get_sync(dev);
if (status < 0) {
dev_err(dev, "pm_runtime_get_sync FAILED %d\n", status);
+   pm_runtime_put_sync(glue->dev);
goto err1;
}
 
@@ -426,6 +437,7 @@ static int omap2430_musb_init(struct musb *musb)
phy_power_on(musb->phy);
 
pm_runtime_put_noidle(musb->controller);
+   pm_runtime_put_noidle(glue->dev);
return 0;
 
 err1:
@@ -626,7 +638,11 @@ static int omap2430_probe(struct platform_device *pdev)
goto err2;
}
 
-   pm_runtime_enable(>dev);
+   /*
+* Note that we cannot enable PM runtime yet for this
+* driver as we need struct musb initialized first.
+* See omap2430_musb_init above.
+*/
 
ret = platform_device_add(musb);
if (ret) {
@@ -675,11 +691,12 @@

Re: MUSB peripheral DMA regression caused by driver core runtime PM change

2015-10-23 Thread Felipe Balbi 

Hi,

Tony Lindgren  writes:
> From: Tony Lindgren 
> Date: Fri, 23 Oct 2015 09:03:22 -0700
> Subject: [PATCH] usb: musb: omap2430: Fix regression caused by driver core
>  change
>
> Commit ddef08dd00f5 ("Driver core: wakeup the parent device before trying
> probe") started automatically ensuring the parent device is enabled when
> the child gets probed.
>
> This however caused a regression for MUSB omap2430 interface as the
> runtime PM for the parent device needs the child initialized to access
> the MUSB hardware registers.
>
> Let's delay the enabling of PM runtime for the parent until the child
> has been properly initialized as suggested in an earlier patch by
> Grygorii Strashko .
>
> In addition to delaying pm_runtime_enable, we now also need to make sure
> the parent is enabled during omap2430_musb_init. We also want to propagate
> an error from omap2430_runtime_resume if struct musb is not initialized.
>
> Note that we use pm_runtime_put_noidle here for both the child and parent
> to prevent an extra runtime_suspend/resume cycle.
>
> Let's also add some comments to avoid confusion between the
> two different devices.
>
> Fixes: ddef08dd00f5 ("Driver core: wakeup the parent device before
> trying probe")
> Suggested-by: Grygorii Strashko 
> Signed-off-by: Tony Lindgren 

I'm fine with this patch to fix this v4.3 regression. Greg, do you want
a pull request or can you take this in as a patch ? In any case:

Acked-by: Felipe Balbi 

> --- a/drivers/usb/musb/omap2430.c
> +++ b/drivers/usb/musb/omap2430.c
> @@ -391,9 +391,20 @@ static int omap2430_musb_init(struct musb *musb)
>   }
>   musb->isr = omap2430_musb_interrupt;
>  
> + /*
> +  * Enable runtime PM for musb parent (this driver). We can't
> +  * do it earlier as struct musb is not yet allocated and we
> +  * need to touch the musb registers for runtime PM.
> +  */
> + pm_runtime_enable(glue->dev);
> + status = pm_runtime_get_sync(glue->dev);
> + if (status < 0)
> + goto err1;
> +
>   status = pm_runtime_get_sync(dev);
>   if (status < 0) {
>   dev_err(dev, "pm_runtime_get_sync FAILED %d\n", status);
> + pm_runtime_put_sync(glue->dev);
>   goto err1;
>   }
>  
> @@ -426,6 +437,7 @@ static int omap2430_musb_init(struct musb *musb)
>   phy_power_on(musb->phy);
>  
>   pm_runtime_put_noidle(musb->controller);
> + pm_runtime_put_noidle(glue->dev);
>   return 0;
>  
>  err1:
> @@ -626,7 +638,11 @@ static int omap2430_probe(struct platform_device *pdev)
>   goto err2;
>   }
>  
> - pm_runtime_enable(>dev);
> + /*
> +  * Note that we cannot enable PM runtime yet for this
> +  * driver as we need struct musb initialized first.
> +  * See omap2430_musb_init above.
> +  */
>  
>   ret = platform_device_add(musb);
>   if (ret) {
> @@ -675,11 +691,12 @@ static int omap2430_runtime_resume(struct device *dev)
>   struct omap2430_glue*glue = dev_get_drvdata(dev);
>   struct musb *musb = glue_to_musb(glue);
>  
> - if (musb) {
> - omap2430_low_level_init(musb);
> - musb_writel(musb->mregs, OTG_INTERFSEL,
> - musb->context.otg_interfsel);
> - }
> + if (!musb)
> + return -EPROBE_DEFER;
> +
> + omap2430_low_level_init(musb);
> + musb_writel(musb->mregs, OTG_INTERFSEL,
> + musb->context.otg_interfsel);
>  
>   return 0;
>  }

-- 
balbi


signature.asc
Description: PGP signature

[GIT PULL] ARM: OMAP2+: hwmod cleanup for v4.4

2015-10-23 Thread Paul Walmsley 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Tony

The following changes since commit 049e6dde7e57f0054fdc49102e7ef4830c698b46:

  Linux 4.3-rc4 (2015-10-04 16:57:17 +0100)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git 
tags/for-v4.4/omap-hwmod-cleanup-a

for you to fetch changes up to c4384a97af852121f66e52ba96e98d6f13ad19eb:

  ARM: OMAP3: hwmod data: Remove legacy mailbox data and addrs (2015-10-23 
13:01:25 -0600)

- 
ARM: OMAP2+: hwmod cleanup for v4.4

Remove some superfluous data from the OMAP2+ hwmod data files.  Mostly
this is a result of data being moved to DT files.  Nothing too
controversial, here.

Basic build, boot, and PM test results are available here:

http://www.pwsan.com/omap/testlogs/hwmod-cleanup-a-for-v4.4/20151023130140/

- 
Franklin S Cooper Jr (2):
  ARM: DRA7/AM335x/AM437x: hwmod: Remove elm address space from hwmod data
  ARM: DRA7/AM335x/AM437x: hwmod: Remove gpmc address space from hwmod data

Javier Martinez Canillas (1):
  ARM: OMAP: Remove duplicated operand in OR operation

Suman Anna (3):
  ARM: OMAP4: hwmod data: Remove spinlock hwmod addrs
  ARM: DRA7: hwmod data: Remove spinlock hwmod addrs
  ARM: OMAP3: hwmod data: Remove legacy mailbox data and addrs

 .../omap_hwmod_33xx_43xx_interconnect_data.c   | 20 ---
 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 29 -
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 10 
 arch/arm/mach-omap2/omap_hwmod_54xx_data.c |  3 +--
 arch/arm/mach-omap2/omap_hwmod_7xx_data.c  | 30 --
 5 files changed, 1 insertion(+), 91 deletions(-)
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJWKpEYAAoJEMePsQ0LvSpLYf0P/3TFvwtzWalFbYbNdvBZ67q2
MLuA/cow3OXOsvVLwPKtfn60Z/wW4u/juUFpuL/1zTmcoFOiQe9Sx1FpI8W1YqXY
zAbRLqbkHip/QUsAEEMjDqbQwWacNmpwChG1tCn7Ji9govi/oP3lYa+GzRXPyone
NqhpwW7cV/OjgoKR8yxFEkdGdZT3I3EO2s0SyULJ+zYvrOSGHwX5SKNhh5Nd6iQV
NbkiHuGospSoY9GHDHESaqabgto4l2XALN5N0fuWAmgeNjeQIwo5wLnGZFU2gHMH
+zZ8inQ+RTtIJfMRNwlr8BJVHKOf20dVEZsPGypxt/H+Sg2I68hoxojDPlrRClLn
K5G4PCwnPBGj/f4UM4oiWBV+qbp26WlSed1CgeS1CJZ2wZM+uDhnYBy29JI3PGz1
Mcov9FRKP06GcRTORC3q2uOuLTDWg+KAff9BidDO6oZR/UAwd+brKsfNWHYGlU8T
n5r9LCkyF0Sk5aGcYizYMO7Nmh+LrDhm7SKbsI6vI8cZUbabuNp3tN4BEmtceh7h
yzqj1Oe+MTmsNOwNSwApckkLAHrvMtDCB0dKEbjtwbFXvMftgd8RPESlxD1TJu2F
H1gSWu+aVJx8J5GeFc9kLF4S8Nz6RdwbmYluqMWBaN8tGi75pEdjipI+f3Y6Iu/U
/sm0vwOxTne0TkBbfhjK
=PPb6
-END PGP SIGNATURE-
--
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

Re: [GIT PULL] omap dts changes for v4.4 merge window, part 2

2015-10-23 Thread Arnd Bergmann 
On Tuesday 20 October 2015 12:35:02 Tony Lindgren wrote:
> Few more omap dts changes for v4.4 merge window, mostly to fix and clean
> up some omap5 issues to allow adding other omap5 boards. Also some other
> fixes and clean-up:
> 
> - Fix SDIO WLAN for omap5 that's been broken for a while. As further
>   patches are still needed for wl18xx, no need for stable on this one.
> 
> - Move most of omap5 support into omap5-board-common.dtsi as most omap5
>   boards seem to share the same basic set of devices.
> 
> - Add minimal IGEPv5 support using based on omap5-board-common.dtsi
> 
> - Remove now unneedes gpio hogging for dra72-evm
> 
> - Update Javier Martinez Canillas email address
> 
> - Change earlier IGEP boards to use IOPAD pinmux macros
> 

Pulled into next/dt, thanks!

Arnd
--
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

Re: MUSB peripheral DMA regression caused by driver core runtime PM change

2015-10-23 Thread Tony Lindgren 
* Alan Stern  [151023 11:27]:
> On Fri, 23 Oct 2015, Grygorii Strashko wrote:
> 
> > Reviewed-by: Grygorii Strashko 
> > 
> > It always fun when DD/PM core is updated to fix some driver/subsystem's
> > specific PM issue :(
> > 
> > > 
> > >> --- a/drivers/usb/musb/omap2430.c
> > >> +++ b/drivers/usb/musb/omap2430.c
> > >> @@ -391,9 +391,20 @@ static int omap2430_musb_init(struct musb *musb)
> > >>  }
> > >>  musb->isr = omap2430_musb_interrupt;
> > >>   
> > >> +/*
> > >> + * Enable runtime PM for musb parent (this driver). We can't
> > >> + * do it earlier as struct musb is not yet allocated and we
> > >> + * need to touch the musb registers for runtime PM.
> > >> + */
> > >> +pm_runtime_enable(glue->dev);
> > >> +status = pm_runtime_get_sync(glue->dev);
> > >> +if (status < 0)
> > >> +goto err1;
> > >> +
> > >>  status = pm_runtime_get_sync(dev);
> > 
> > Hm. My assumption was that *Parent* device (omap2430) will be enabled
> > here :( But as I can see this will not happen:

Yes the parent child stuff here is very confusing right now :)

> > static int rpm_resume(struct device *dev, int rpmflags)
> > {...
> > if (!parent && dev->parent) {
> > /*
> >  * Increment the parent's usage counter and resume it if
> >  * necessary.  Not needed if dev is irq-safe; then the
> >  * parent is permanently resumed.
> >  */
> > parent = dev->parent;
> > if (dev->power.irq_safe)
> > goto skip_parent;
> > 
> > ^^^ and musb device is irq_safe :( 
> 
> This way of doing things looks very strange.
> 
> If the omap2430 is the parent of the musb device, and
> pm_runtime_irq_safe() has been called for the musb device, then after
> that the omap2430 will never be runtime suspended.  Therefore it
> doesn't matter whether you enable it for runtime PM or not.
> 
> It seems to me that the real problem must be that the musb device gets
> runtime-enabled and marked irq_safe too early.  These things should 
> happen before the musb device gets registered and exposed to userspace, 
> but not before the omap2430 parent is runtime-enabled.
> 
> Thus the sequence of events should be:
> 
>   Allocate the musb device;
>   Runtime-enable the omap2430 (since it is now safe to do so);
>   Runtime-enable the musb and declare it irq_safe (this will
>   automatically runtime-resume the omap2430);
>   Register the musb.
> 
> If things are done this way, no special action needs to be taken.

Yes good point, that requires changing the init for the whole
drivers/musb though. Also, we should reorganize the whole musb and make
the platform glue and musb core drivers completely separate using a
shared interrupt where needed.

For the regression for the -rc series? Do you see any better
alternatives to what I posted?

Regards,

Tony
--
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

Re: [PATCH 5/5] Add information about the new DT device name

2015-10-23 Thread Sergei Shtylyov 

Hello.

On 10/23/2015 06:57 PM, Rolf Peukert wrote:


Add some information about the new device name to the DT documentation.

Signed-off-by: Rolf Peukert 
---
  Documentation/devicetree/bindings/usb/omap-usb.txt | 35
++
  1 file changed, 35 insertions(+)

diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt
b/Documentation/devicetree/bindings/usb/omap-usb.txt
index 38d9bb8..cf98f61 100644
--- a/Documentation/devicetree/bindings/usb/omap-usb.txt
+++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
@@ -78,3 +78,38 @@ omap_dwc3 {
ranges;
  };

+AM35x MUSB GLUE
+ - compatible : Should be "ti,am35x-musb"


   Wildcards in  "compatible" are not allowed; you should select a "least 
common denominator" model and use it.



+ - ti,hwmods : must be "am35x_otg_hs"
+ - multipoint : Should be "1" indicating the musb controller supports
+   multipoint. This is a MUSB configuration-specific setting.


   Hm, I would think this should be boolean prop...


+ - num-eps : Specifies the number of endpoints. This is also a
+   MUSB configuration-specific setting. Should be set to "16"
+ - ram-bits : Specifies the ram address size. Should be set to "12"
+ - interface-type : Should be set to "1". (The AM35xx SOCs feature an
+   integrated phy, connected via UTMI+)


   Again, maybe boolean?


+ - mode : Should be "3" to represent OTG. "1" signifies HOST and "2"


   There's already standardized "dr_mode" prop for that.


+   represents PERIPHERAL.
+ - power : Should be "50". This signifies the controller can supply up to
+   100mA when operating in host mode.


   Why not just exparess it in mA?

MBR, Sergei

--
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

Re: MUSB peripheral DMA regression caused by driver core runtime PM change

2015-10-23 Thread Tony Lindgren 
* Alan Stern  [151023 13:34]:
> On Fri, 23 Oct 2015, Tony Lindgren wrote:
> 
> > > Thus the sequence of events should be:
> > > 
> > >   Allocate the musb device;
> > >   Runtime-enable the omap2430 (since it is now safe to do so);
> > >   Runtime-enable the musb and declare it irq_safe (this will
> > >   automatically runtime-resume the omap2430);
> > >   Register the musb.
> > > 
> > > If things are done this way, no special action needs to be taken.
> > 
> > Yes good point, that requires changing the init for the whole
> > drivers/musb though.
> 
> This will have to be done anyway, since the way it is now (if I 
> understand correctly), the musb is registered and made available to 
> userspace before its parent is operational (i.e., at full power).

Yes I agree.

> > Also, we should reorganize the whole musb and make
> > the platform glue and musb core drivers completely separate using a
> > shared interrupt where needed.
> > 
> > For the regression for the -rc series? Do you see any better
> > alternatives to what I posted?
> 
> No.

OK thanks,

Tony
--
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

Re: MUSB peripheral DMA regression caused by driver core runtime PM change

2015-10-23 Thread Alan Stern 
On Fri, 23 Oct 2015, Tony Lindgren wrote:

> > Thus the sequence of events should be:
> > 
> > Allocate the musb device;
> > Runtime-enable the omap2430 (since it is now safe to do so);
> > Runtime-enable the musb and declare it irq_safe (this will
> > automatically runtime-resume the omap2430);
> > Register the musb.
> > 
> > If things are done this way, no special action needs to be taken.
> 
> Yes good point, that requires changing the init for the whole
> drivers/musb though.

This will have to be done anyway, since the way it is now (if I 
understand correctly), the musb is registered and made available to 
userspace before its parent is operational (i.e., at full power).

> Also, we should reorganize the whole musb and make
> the platform glue and musb core drivers completely separate using a
> shared interrupt where needed.
> 
> For the regression for the -rc series? Do you see any better
> alternatives to what I posted?

No.

Alan Stern

--
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

Re: [GIT PULL] ARM: OMAP2+: hwmod cleanup for v4.4

2015-10-23 Thread Tony Lindgren 
* Paul Walmsley  [151023 12:58]:
> Hi Tony
> 
> The following changes since commit 049e6dde7e57f0054fdc49102e7ef4830c698b46:
> 
>   Linux 4.3-rc4 (2015-10-04 16:57:17 +0100)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git 
> tags/for-v4.4/omap-hwmod-cleanup-a
> 
> for you to fetch changes up to c4384a97af852121f66e52ba96e98d6f13ad19eb:
> 
>   ARM: OMAP3: hwmod data: Remove legacy mailbox data and addrs (2015-10-23 
> 13:01:25 -0600)
> 
> 
> ARM: OMAP2+: hwmod cleanup for v4.4
> 
> Remove some superfluous data from the OMAP2+ hwmod data files.  Mostly
> this is a result of data being moved to DT files.  Nothing too
> controversial, here.
> 
> Basic build, boot, and PM test results are available here:
> 
> http://www.pwsan.com/omap/testlogs/hwmod-cleanup-a-for-v4.4/20151023130140/

Thanks pulling into omap-for-v4.4/soc. FYI, that's most likely the last branch 
I'll
do for the upcoming merge window as we're already late with all the regression
fixes. Planning to send it off tomorrow.

Regards,

Tony

> 
> 
> Franklin S Cooper Jr (2):
>   ARM: DRA7/AM335x/AM437x: hwmod: Remove elm address space from hwmod data
>   ARM: DRA7/AM335x/AM437x: hwmod: Remove gpmc address space from hwmod 
> data
> 
> Javier Martinez Canillas (1):
>   ARM: OMAP: Remove duplicated operand in OR operation
> 
> Suman Anna (3):
>   ARM: OMAP4: hwmod data: Remove spinlock hwmod addrs
>   ARM: DRA7: hwmod data: Remove spinlock hwmod addrs
>   ARM: OMAP3: hwmod data: Remove legacy mailbox data and addrs
> 
>  .../omap_hwmod_33xx_43xx_interconnect_data.c   | 20 ---
>  arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 29 -
>  arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 10 
>  arch/arm/mach-omap2/omap_hwmod_54xx_data.c |  3 +--
>  arch/arm/mach-omap2/omap_hwmod_7xx_data.c  | 30 
> --
>  5 files changed, 1 insertion(+), 91 deletions(-)
--
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

Re: [PATCH 2/4] clk: ti816x: Add missing dmtimer clkdev entries

2015-10-23 Thread Tony Lindgren 
* Neil Armstrong  [151022 02:19]:
> Add missing clkdev dmtimer related entries for dm816x.
> 32Khz and ext sources were missing.
> 
> Cc: Brian Hutchinson 
> Signed-off-by: Neil Armstrong 

Tero should queue this one:

Acked-by: Tony Lindgren 

> ---
>  drivers/clk/ti/clk-816x.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/clk/ti/clk-816x.c b/drivers/clk/ti/clk-816x.c
> index 1dfad0c..2a5d84f 100644
> --- a/drivers/clk/ti/clk-816x.c
> +++ b/drivers/clk/ti/clk-816x.c
> @@ -20,6 +20,8 @@ static struct ti_dt_clk dm816x_clks[] = {
>   DT_CLK(NULL, "sys_clkin", "sys_clkin_ck"),
>   DT_CLK(NULL, "timer_sys_ck", "sys_clkin_ck"),
>   DT_CLK(NULL, "sys_32k_ck", "sys_32k_ck"),
> + DT_CLK(NULL, "timer_32k_ck", "sysclk18_ck"),
> + DT_CLK(NULL, "timer_ext_ck", "tclkin_ck"),
>   DT_CLK(NULL, "mpu_ck", "mpu_ck"),
>   DT_CLK(NULL, "timer1_fck", "timer1_fck"),
>   DT_CLK(NULL, "timer2_fck", "timer2_fck"),
> -- 
> 1.9.1
--
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

Re: [PATCH 1/4] arm: omap2+: add missing HWMOD_NO_IDLEST in 81xx hwmod data

2015-10-23 Thread Tony Lindgren 
Hi,

* Neil Armstrong  [151022 02:19]:
> Add missing HWMOD_NO_IDLEST hwmod flag for entries no
> having omap4 clkctrl values.

Have you checked this is the case both in dm814x and dm816x TRM?
Also the documentation may not be complete FYI, might be also
worth checking the legacy TI kernel tree to be sure.

Regards,

Tony

> Cc: Brian Hutchinson 
> Signed-off-by: Neil Armstrong 
> ---
>  arch/arm/mach-omap2/omap_hwmod_81xx_data.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/arch/arm/mach-omap2/omap_hwmod_81xx_data.c 
> b/arch/arm/mach-omap2/omap_hwmod_81xx_data.c
> index b1288f5..6256052 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_81xx_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_81xx_data.c
> @@ -144,6 +144,7 @@ static struct omap_hwmod dm81xx_l4_ls_hwmod = {
>   .name   = "l4_ls",
>   .clkdm_name = "alwon_l3s_clkdm",
>   .class  = _hwmod_class,
> + .flags  = HWMOD_NO_IDLEST,
>  };
> 
>  /*
> @@ -155,6 +156,7 @@ static struct omap_hwmod dm81xx_l4_hs_hwmod = {
>   .name   = "l4_hs",
>   .clkdm_name = "alwon_l3_med_clkdm",
>   .class  = _hwmod_class,
> + .flags  = HWMOD_NO_IDLEST,
>  };
> 
>  /* L3 slow -> L4 ls peripheral interface running at 125MHz */
> @@ -850,6 +852,7 @@ static struct omap_hwmod dm816x_emac0_hwmod = {
>   .name   = "emac0",
>   .clkdm_name = "alwon_ethernet_clkdm",
>   .class  = _emac_hwmod_class,
> + .flags  = HWMOD_NO_IDLEST,
>  };
> 
>  static struct omap_hwmod_ocp_if dm81xx_l4_hs__emac0 = {
> -- 
> 1.9.1
--
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

Re: [PATCH 2/5] Export am35x helper functions

2015-10-23 Thread Tony Lindgren 
* Rolf Peukert  [151023 08:46]:
> To be able to call these four helper functions from a M-USB AM35x driver
> module, their name symbols need to be exported.

I'd rather get rid of this file completely.. How about just do a minimal
drivers/phy driver? Maybe take a look at the drivers/phy/phy-dm816x-usb.c
for an example. Then you probably want to use the musb_dsps.c driver if
possible instead of the legacy am35x.c :)

Regards,

Tony

> Signed-off-by: Rolf Peukert 
> ---
>  arch/arm/mach-omap2/omap_phy_internal.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/arch/arm/mach-omap2/omap_phy_internal.c
> b/arch/arm/mach-omap2/omap_phy_internal.c
> index 8e90356..648a60f 100644
> --- a/arch/arm/mach-omap2/omap_phy_internal.c
> +++ b/arch/arm/mach-omap2/omap_phy_internal.c
> @@ -82,6 +82,7 @@ void am35x_musb_reset(void)
> 
>   regval = omap_ctrl_readl(AM35XX_CONTROL_IP_SW_RESET);
>  }
> +EXPORT_SYMBOL(am35x_musb_reset);
> 
>  void am35x_musb_phy_power(u8 on)
>  {
> @@ -120,6 +121,7 @@ void am35x_musb_phy_power(u8 on)
>   omap_ctrl_writel(devconf2, AM35XX_CONTROL_DEVCONF2);
>   }
>  }
> +EXPORT_SYMBOL(am35x_musb_phy_power);
> 
>  void am35x_musb_clear_irq(void)
>  {
> @@ -130,6 +132,7 @@ void am35x_musb_clear_irq(void)
>   omap_ctrl_writel(regval, AM35XX_CONTROL_LVL_INTR_CLEAR);
>   regval = omap_ctrl_readl(AM35XX_CONTROL_LVL_INTR_CLEAR);
>  }
> +EXPORT_SYMBOL(am35x_musb_clear_irq);
> 
>  void am35x_set_mode(u8 musb_mode)
>  {
> @@ -152,3 +155,4 @@ void am35x_set_mode(u8 musb_mode)
> 
>   omap_ctrl_writel(devconf2, AM35XX_CONTROL_DEVCONF2);
>  }
> +EXPORT_SYMBOL(am35x_set_mode);
> -- 
> 2.4.10
> 
--
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

Re: [PATCH] ARM: dts: am335x-boneblack: Use pinctrl constants

2015-10-23 Thread Javier Martinez Canillas 
Hello Andrew,

On Fri, Oct 23, 2015 at 3:08 PM, Andrew F. Davis  wrote:
> On 10/22/2015 04:23 PM, Tony Lindgren wrote:
>>
>> * Andrew F. Davis  [151022 09:21]:
>>>
>>> Using constants for pinctrl allows better readability and removes
>>> redundancy with comments.
>>
>>
>> You should use the include/dt-bindings/pinctrl/omap.h macro
>> AM33XX_IOPAD(pa, val) while at it. Otherwise we'll end up patching
>> the same things again later on.
>>
>
> Hmm, I haven't really been following this change, it kind of seems to add
> some unnecessary abstraction by using physical hardware addresses instead
> of offsets, then just converting them back to offsets. The offset style DT
> nodes are already auto-generated with existing tools anyway:
> https://dev.ti.com/pinmux
>
> I'm sure this has been discussed already so if this is a blocker I'll
> re-spin this.
>

The good thing about the IOPAD pinmux macros is that matches what is
in the TRM so it is easier to read the DTS and verify that is correct.

I've on my queue to migrate all the remaining DTS for TI SoCs to use
the IOPAD macros but is just that I didn't have time to do it this
week. Probably I'll do it at the end of the next week.

> Andrew
>
>
>> Regards,
>>

Best regards,
Javier
--
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

Re: [PATCH] ARM: dts: am335x-boneblack: Use pinctrl constants

2015-10-23 Thread Andrew F. Davis 

On 10/23/2015 09:29 AM, Javier Martinez Canillas wrote:

Hello Andrew,

On Fri, Oct 23, 2015 at 3:08 PM, Andrew F. Davis  wrote:

On 10/22/2015 04:23 PM, Tony Lindgren wrote:


* Andrew F. Davis  [151022 09:21]:


Using constants for pinctrl allows better readability and removes
redundancy with comments.



You should use the include/dt-bindings/pinctrl/omap.h macro
AM33XX_IOPAD(pa, val) while at it. Otherwise we'll end up patching
the same things again later on.



Hmm, I haven't really been following this change, it kind of seems to add
some unnecessary abstraction by using physical hardware addresses instead
of offsets, then just converting them back to offsets. The offset style DT
nodes are already auto-generated with existing tools anyway:
https://dev.ti.com/pinmux

I'm sure this has been discussed already so if this is a blocker I'll
re-spin this.



The good thing about the IOPAD pinmux macros is that matches what is
in the TRM so it is easier to read the DTS and verify that is correct.

I've on my queue to migrate all the remaining DTS for TI SoCs to use
the IOPAD macros but is just that I didn't have time to do it this
week. Probably I'll do it at the end of the next week.



Then this patch can probably be dropped, hopefully the converted constants
in this patch can be of some help for you though.

Andrew


Andrew



Regards,



Best regards,
Javier


--
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

Re: [PATCH] ARM: dts: am335x-boneblack: Use pinctrl constants

2015-10-23 Thread Javier Martinez Canillas 
Hello Andrew,

On Fri, Oct 23, 2015 at 4:36 PM, Andrew F. Davis  wrote:
> On 10/23/2015 09:29 AM, Javier Martinez Canillas wrote:
>>
>> Hello Andrew,
>>
>> On Fri, Oct 23, 2015 at 3:08 PM, Andrew F. Davis  wrote:
>>>
>>> On 10/22/2015 04:23 PM, Tony Lindgren wrote:


 * Andrew F. Davis  [151022 09:21]:
>
>
> Using constants for pinctrl allows better readability and removes
> redundancy with comments.



 You should use the include/dt-bindings/pinctrl/omap.h macro
 AM33XX_IOPAD(pa, val) while at it. Otherwise we'll end up patching
 the same things again later on.

>>>
>>> Hmm, I haven't really been following this change, it kind of seems to add
>>> some unnecessary abstraction by using physical hardware addresses instead
>>> of offsets, then just converting them back to offsets. The offset style
>>> DT
>>> nodes are already auto-generated with existing tools anyway:
>>> https://dev.ti.com/pinmux
>>>
>>> I'm sure this has been discussed already so if this is a blocker I'll
>>> re-spin this.
>>>
>>
>> The good thing about the IOPAD pinmux macros is that matches what is
>> in the TRM so it is easier to read the DTS and verify that is correct.
>>
>> I've on my queue to migrate all the remaining DTS for TI SoCs to use
>> the IOPAD macros but is just that I didn't have time to do it this
>> week. Probably I'll do it at the end of the next week.
>>
>
> Then this patch can probably be dropped, hopefully the converted constants
> in this patch can be of some help for you though.
>

Yes they are but feel free to re-spin your patch if you wish, it will
be one less DTS to convert :-)

But yes, if you don't then I'll do it when changing all DTS.

> Andrew
>
>

Best regards,
Javier
--
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

[PATCH] rtc: ds1307: Fix alarm programming for mcp794xx

2015-10-23 Thread Tero Kristo 
mcp794xx alarm registers must be written in BCD format. However, the
alarm programming logic neglected this by adding one to the value
after bin2bcd conversion has been already done, writing bad values
to month register in case the alarm being set is in October. In this
case, the alarm month value becomes 0x0a instead of the expected 0x10.

Fix by moving the +1 addition within the bin2bcd call also.

Fixes: 1d1945d261a2 ("drivers/rtc/rtc-ds1307.c: add alarm support for mcp7941x 
chips")

Signed-off-by: Tero Kristo 
---
 drivers/rtc/rtc-ds1307.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/rtc/rtc-ds1307.c b/drivers/rtc/rtc-ds1307.c
index a705e64..188006c 100644
--- a/drivers/rtc/rtc-ds1307.c
+++ b/drivers/rtc/rtc-ds1307.c
@@ -718,9 +718,9 @@ static int mcp794xx_set_alarm(struct device *dev, struct 
rtc_wkalrm *t)
regs[3] = bin2bcd(t->time.tm_sec);
regs[4] = bin2bcd(t->time.tm_min);
regs[5] = bin2bcd(t->time.tm_hour);
-   regs[6] = bin2bcd(t->time.tm_wday) + 1;
+   regs[6] = bin2bcd(t->time.tm_wday + 1);
regs[7] = bin2bcd(t->time.tm_mday);
-   regs[8] = bin2bcd(t->time.tm_mon) + 1;
+   regs[8] = bin2bcd(t->time.tm_mon + 1);
 
/* Clear the alarm 0 interrupt flag. */
regs[6] &= ~MCP794XX_BIT_ALMX_IF;
-- 
1.7.9.5

--
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

Re: [PATCH v3 00/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms

2015-10-23 Thread Roger Quadros 
On 21/10/15 18:20, Tony Lindgren wrote:
> * Roger Quadros  [151021 01:31]:
>> On 19/10/15 10:08, Roger Quadros wrote:
>>> On 17/10/15 00:25, Tony Lindgren wrote:
 * Roger Quadros  [151006 04:13]:
>
> Fine. The updated series is now at
>
> g...@github.com:rogerq/linux.git
>  * [new branch]  for-v4.4/gpmc-v4

 Looks like it produces some build errors, this with RMKs 3430 and 4430
 only .configs:

 drivers/memory/omap-gpmc.c:2035:43: error: ‘struct gpio_chip’ has no
 member named ‘irqdomain’
 drivers/memory/omap-gpmc.c:2116:8: error: implicit declaration of
 function ‘gpiochip_irqchip_add’ [-Werror=implicit-function-declaration]

>>>
>>> Good catch. We'll have to select GPIOLIB_IRQCHIP for this driver.
>>>
 Maybe run randconfig builds on it for overnight?
>>>
>>> OK. I'll do that.
>>
>> I couldn't run randconfig beyond few iterations as it keeps failing
>> everywhere. How do we limit the randconfig options to OMAP only
>> platforms?
> 
> You can use Felipe's scripts from github.

Thanks. I used his scripts and ran 10 randconfigs per platform.
Didn't find any issues with this series.

How can we proceed?
Patches are on https://github.com/rogerq/linux/commits/for-v4.4/gpmc-v4

cheers,
-roger
--
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

Re: [PATCH] clk: ti: drop locking code from mux/divider drivers

2015-10-23 Thread Grygorii Strashko 

On 10/01/2015 10:20 PM, Grygorii Strashko wrote:

TI's mux and divider clock drivers do not require locking and they do
not initialize internal spinlocks. This code was occasionally
copy-posted from generic mux/divider drivers. So remove it.

Cc: Tony Lindgren 
Cc: Sekhar Nori 
Signed-off-by: Grygorii Strashko 
---


Gentle ping.


  drivers/clk/ti/divider.c | 16 +++-
  drivers/clk/ti/mux.c | 15 +++
  2 files changed, 6 insertions(+), 25 deletions(-)



--
regards,
-grygorii
--
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