Re: [PATCH 1/3] ARM: OMAP2+: clockdomain: Add mechanism for disabling HW_AUTO

2015-09-21 Thread Roger Quadros 
Paul,

On 16/07/15 16:56, Roger Quadros wrote:
> On 16/07/15 04:25, Paul Walmsley wrote:
>> Hi
>>
>> On Tue, 23 Jun 2015, Roger Quadros wrote:
>>
>>> For some hwmods (e.g. DCAN on DRA7) we need the possibility to
>>> disable HW_AUTO for the clockdomain while the module is active.
>>>
>>> To achieve this there needs to be a refcounting mechanism to
>>> indicate whether any module in the clockdomain has requested
>>> to disable HW_AUTO. We keep track of this in 'noidlecount'.
>>>
>>> Hwmod code must use clkdm_hwmod_prevent_hwauto() to prevent
>>> HW_AUTO of the clockdomain in the future clkdm_hwmod_hwauto() calls.
>>>
>>> It must use clkdm_hwmod_allow_hwauto() to allow HW_AUTO in
>>> the future clkdm_hwmod_hwauto() calls.
>>>
>>> Hwmod code must use clkdm_hwmod_allow_hwauto() whenever it needs
>>> to request HW_AUTO of any clockdomain. (Typically after it has
>>> enabled the module).
>>
>> How about just modifying clkdm_{allow,deny}_idle*() to do the 
>> idle-block-counting?  The default state would be to allow idle, assuming 
>> that the clockdomain flags support that state, and then clkdm_deny_idle*() 
>> would increment the idle-blocking count, clkdm_allow_idle*() would 
>> decrement it.  Then on the 0 -> 1 or 1 -> 0 transitions, the hardware 
>> would be reprogrammed appropiately.
> 
> That is not possible with current hwmod code as clkdm_allow_idle() and 
> clkdm_deny_idle()
> are not symmetrically placed.
> 
> The usual flow is
>   clkdm_enable_hwmod();
>   if (hwsup)
>   clkdm_allow_idle();
> 
> This is mainly because it is redundant to disable auto idle before enableing
> (SW_WKUP) the clockdomain.
> 
> If we take your proposal above then we have to modify all users like so.
> 
>   if (hwsup)
>   clkdm_deny_idle();
>   clkdm_enable_hwmod();
>   if (hwsup)
>   clkdm_allow_idle();
> 
> Is this really what we want?

Need your view on this before I can re-spin this series. Thanks.

cheers,
-roger

> 
>>
>> Anyway, seems like that would avoid races with any 
>> clkdm_{allow,deny}_idle*() users.  
>>
>> A few other comments below:
>>
>>
>>>
>>> Signed-off-by: Roger Quadros 
>>> ---
>>>  arch/arm/mach-omap2/clockdomain.c | 71 
>>> +++
>>>  arch/arm/mach-omap2/clockdomain.h |  5 +++
>>>  2 files changed, 76 insertions(+)
>>>
>>> diff --git a/arch/arm/mach-omap2/clockdomain.c 
>>> b/arch/arm/mach-omap2/clockdomain.c
>>> index 2da3b5e..a7190d2 100644
>>> --- a/arch/arm/mach-omap2/clockdomain.c
>>> +++ b/arch/arm/mach-omap2/clockdomain.c
>>> @@ -1212,6 +1212,77 @@ ccd_exit:
>>> return 0;
>>>  }
>>>  
>>> +/*
>>> + * prevent future hwauto for this clkdm. If clkdm->usecount becomes hwauto 
>>> isn't prevented.
>>> + * It will only prevnt future hwauto but not bring it out of hwauto.
>>> + */
>>
>> If you modify clkdm_{allow,deny}_idle*(), this shouldn't be a major issue 
>> - but all of the function comments should be fixed so that they are 
>> understandable and follow kernel-doc-nano specs.
> 
> OK for updating the comments.
> 
> 
> cheers,
> -roger
> 
>>
>>> +int clkdm_hwmod_prevent_hwauto(struct clockdomain *clkdm, struct 
>>> omap_hwmod *oh)
>>> +{
>>> +   /* The clkdm attribute does not exist yet prior OMAP4 */
>>> +   if (cpu_is_omap24xx() || cpu_is_omap34xx())
>>> +   return 0;
>>> +
>>> +   if (!clkdm || !oh || !arch_clkdm || !arch_clkdm->clkdm_clk_disable)
>>> +   return -EINVAL;
>>> +
>>> +
>>> +   pwrdm_lock(clkdm->pwrdm.ptr);
>>> +   clkdm->noidlecount++;
>>> +   pwrdm_unlock(clkdm->pwrdm.ptr);
>>> +
>>> +   return 0;
>>> +}
>>> +
>>> +/*
>>> + * allow future hwauto for this clkdm
>>> + * It won't put clkdm into hwauto. use clkdm_hwmod_hwauto() for that.
>>> + */
>>> +int clkdm_hwmod_allow_hwauto(struct clockdomain *clkdm, struct omap_hwmod 
>>> *oh)
>>> +{
>>> +   /* The clkdm attribute does not exist yet prior OMAP4 */
>>> +   if (cpu_is_omap24xx() || cpu_is_omap34xx())
>>> +   return 0;
>>> +
>>> +   if (!clkdm || !oh || !arch_clkdm || !arch_clkdm->clkdm_clk_disable)
>>> +   return -EINVAL;
>>> +
>>> +
>>> +   pwrdm_lock(clkdm->pwrdm.ptr);
>>> +
>>> +   if (clkdm->noidlecount == 0) {
>>> +   pwrdm_unlock(clkdm->pwrdm.ptr);
>>> +   WARN_ON(1); /* underflow */
>>> +   return -ERANGE;
>>> +   }
>>> +
>>> +   clkdm->noidlecount--;
>>> +   pwrdm_unlock(clkdm->pwrdm.ptr);
>>> +
>>> +   return 0;
>>> +}
>>> +
>>> +/*
>>> + * put clkdm in hwauto if we can. checks noidlecount to see if we can.
>>> + */
>>> +int clkdm_hwmod_hwauto(struct clockdomain *clkdm, struct omap_hwmod *oh)
>>> +{
>>> +   /* The clkdm attribute does not exist yet prior OMAP4 */
>>> +   if (cpu_is_omap24xx() || cpu_is_omap34xx())
>>> +   return 0;
>>> +
>>> +   if (!clkdm || !oh || !arch_clkdm || !arch_clkdm->clkdm_clk_disable)
>>> +   return -EINVAL;
>>> +
>>> +
>>> +   pwrdm_lock(clkdm->pwrdm.ptr);
>>> +   if (clkdm->noidlecount == 0)
>>> +

[PATCH 1/1] ARM: DTS: dra72-evm: remove cpsw gpio hogging and add select-slave-gpio

2015-09-21 Thread Mugunthan V N 
Since GPIO hogging fails to through error when booting with
gpio-pcf857x as module and NFS root filesystem. So by having
mode-gpio, it throw error to user so that the used can make
gpio-pcf857x as inbuilt for NFS. When using mmc/ramdisk as root
fs, cpsw will probe defer and re-probes again when gpio-pcf857x
module is inserted and ethernet becomes operational.

Signed-off-by: Mugunthan V N 
---

The driver patch is applied to net-next branch (also present in
linux-next) with commit '1d147ccbfc35 ("drivers: net: cpsw: Add
support to drive gpios for ethernet to be functional") and logs
[1] also pushed a branch [2] for testing.

[1]: http://pastebin.ubuntu.com/12306224/
[2]: git://git.ti.com/~mugunthanvnm/ti-linux-kernel/linux.git 
cpsw-gpio-optional-v3

---
 arch/arm/boot/dts/dra72-evm.dts | 7 +--
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/arch/arm/boot/dts/dra72-evm.dts b/arch/arm/boot/dts/dra72-evm.dts
index c11ccb1..b7eca13 100644
--- a/arch/arm/boot/dts/dra72-evm.dts
+++ b/arch/arm/boot/dts/dra72-evm.dts
@@ -353,12 +353,6 @@
interrupts = <11 IRQ_TYPE_EDGE_FALLING>;
interrupt-controller;
#interrupt-cells = <2>;
-
-   cpsw_sel_s0 {
-   gpio-hog;
-   gpios = <4 GPIO_ACTIVE_HIGH>;
-   output-low;
-   };
};
 };
 
@@ -590,6 +584,7 @@
pinctrl-0 = <_default>;
pinctrl-1 = <_sleep>;
slaves = <1>;
+   mode-gpios = <_gpio_21 4 GPIO_ACTIVE_HIGH>;
 };
 
 _emac0 {
-- 
2.6.0.rc2.10.gf4d9753

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

usb: dwc3: gadget: warning on v4.3-rc1

2015-09-21 Thread Roger Quadros 
Hi Felipe,

I see the following warning when g_zero is loaded
and USB cable is plugged to host on dra7-evm's USB1 port.

It happens only once and no longer appears on re-loading gadget
or plugging/unplugging cable.

root@rockdesk:~# modprobe g_zero
[   28.414895] zero gadget: Gadget Zero, version: Cinco de Mayo 2008
[   28.421284] zero gadget: zero ready
root@rockdesk:~# [   35.298997] zero gadget: high-speed config #3: source/sink
[   35.305079] [ cut here ]
[   35.309948] WARNING: CPU: 1 PID: 2269 at drivers/usb/dwc3/gadget.c:697 
dwc3_gadget_ep_disable+0xa8/0xc8 [dwc3]()
[   35.320613] dwc3 4889.usb: ep1in is already disabled
[   35.326174] Modules linked in: usb_f_ss_lb g_zero libcomposite xhci_plat_hcd 
xhci_hcd usbcore dwc3 m25p80 spi_nor udc_core usb_common c_can_platform c_can 
spi_ti_qspi can_dev cpufreq_dt omap_wdt extcon_usb_gx
[   35.353787] CPU: 1 PID: 2269 Comm: irq/415-dwc3 Not tainted 
4.3.0-rc2-1-g895eac6 #289
[   35.362349] Hardware name: Generic DRA74X (Flattened Device Tree)
[   35.368749] [] (unwind_backtrace) from [] 
(show_stack+0x10/0x14)
[   35.376877] [] (show_stack) from [] 
(dump_stack+0x80/0x9c)
[   35.384459] [] (dump_stack) from [] 
(warn_slowpath_common+0x7c/0xb8)
[   35.392952] [] (warn_slowpath_common) from [] 
(warn_slowpath_fmt+0x30/0x40)
[   35.402088] [] (warn_slowpath_fmt) from [] 
(dwc3_gadget_ep_disable+0xa8/0xc8 [dwc3])
[   35.412080] [] (dwc3_gadget_ep_disable [dwc3]) from [] 
(disable_ep+0x2c/0x6c [usb_f_ss_lb])
[   35.422676] [] (disable_ep [usb_f_ss_lb]) from [] 
(disable_endpoints+0x18/0x50 [usb_f_ss_lb])
[   35.433445] [] (disable_endpoints [usb_f_ss_lb]) from [] 
(disable_source_sink+0x2c/0x34 [usb_f_ss_lb])
[   35.445032] [] (disable_source_sink [usb_f_ss_lb]) from 
[] (sourcesink_set_alt+0x2c/0x264 [usb_f_ss_lb])
[   35.456810] [] (sourcesink_set_alt [usb_f_ss_lb]) from 
[] (composite_setup+0xc28/0x1574 [libcomposite])
[   35.468500] [] (composite_setup [libcomposite]) from [] 
(dwc3_ep0_delegate_req+0x2c/0x40 [dwc3])
[   35.479559] [] (dwc3_ep0_delegate_req [dwc3]) from [] 
(dwc3_ep0_interrupt+0x984/0xc40 [dwc3])
[   35.490353] [] (dwc3_ep0_interrupt [dwc3]) from [] 
(dwc3_thread_interrupt+0x7a8/0x9c8 [dwc3])
[   35.501195] [] (dwc3_thread_interrupt [dwc3]) from [] 
(irq_thread_fn+0x1c/0x34)
[   35.510689] [] (irq_thread_fn) from [] 
(irq_thread+0x148/0x1a4)
[   35.518724] [] (irq_thread) from [] (kthread+0xd0/0xec)
[   35.526024] [] (kthread) from [] 
(ret_from_fork+0x14/0x24)
[   35.533593] ---[ end trace fe01e35c4677ca2f ]---

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] ARM: OMAP: Remove duplicated operand in OR operation

2015-09-21 Thread Roger Quadros 
On 17/09/15 16:22, Javier Martinez Canillas wrote:
> Commit b483a4a5a711 ("ARM: OMAP4+: hwmod data: Don't prevent RESET of
> USB Host module") added the SYSC_HAS_RESET_STATUS flag to both OMAP4
> and OMAP5 USB host module hwmon sysconfig but that flag was already
> set for OMAP5. So now the flag appears twice in the expression.
> 
> make coccicheck complains with the following message:
> 
> omap_hwmod_54xx_data.c:1846:37-58: duplicated argument to & or |
> 
> Signed-off-by: Javier Martinez Canillas 

Acked-by: Roger Quadros 

> 
> ---
> 
>  arch/arm/mach-omap2/omap_hwmod_54xx_data.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c 
> b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
> index 7c3fac035e93..8cdfd9b7ab4f 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
> @@ -1844,8 +1844,7 @@ static struct omap_hwmod_class_sysconfig 
> omap54xx_usb_host_hs_sysc = {
>   .rev_offs   = 0x,
>   .sysc_offs  = 0x0010,
>   .sysc_flags = (SYSC_HAS_MIDLEMODE | SYSC_HAS_RESET_STATUS |
> -SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET |
> -SYSC_HAS_RESET_STATUS),
> +SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET),
>   .idlemodes  = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
>  SIDLE_SMART_WKUP | MSTANDBY_FORCE | MSTANDBY_NO |
>  MSTANDBY_SMART | MSTANDBY_SMART_WKUP),
> 

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

[net-next PATCH 4/4] arm: dts: am4372: add syscon phandle to cpsw node

2015-09-21 Thread Mugunthan V N 
There are 2 MACIDs stored in the control module of the am4372.
These are read by the cpsw driver if no valid MACID was found
in the devicetree.

Signed-off-by: Mugunthan V N 
---
 arch/arm/boot/dts/am4372.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index 0447c04a..d83ff9c 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -591,6 +591,7 @@
cpts_clock_mult = <0x8000>;
cpts_clock_shift = <29>;
ranges;
+   syscon = <_conf>;
 
davinci_mdio: mdio@4a101000 {
compatible = "ti,am4372-mdio","ti,davinci_mdio";
-- 
2.6.0.rc2.10.gf4d9753

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

[net-next PATCH 0/4] Add support for reading macid when DT macid not found

2015-09-21 Thread Mugunthan V N 
Did a boot test on dra7-evm [1] and am437x-gp-evm [2].
Pushed a branch [3] for others to test the patch.

[1]: http://pastebin.ubuntu.com/12513420/
[2]: http://pastebin.ubuntu.com/12513428/
[3]: git://git.ti.com/~mugunthanvnm/ti-linux-kernel/linux.git 
cpsw-macid-read-support

Mugunthan V N (4):
  drivers: net: cpsw: davinci_emac: move reading mac id to common file
  drivers: net: cpsw-common: add support for reading mac address for
dra7 and am437x platforms
  arm: dts: dra7: add syscon phandle to cpsw node
  arm: dts: am4372: add syscon phandle to cpsw node

 arch/arm/boot/dts/am4372.dtsi  |  1 +
 arch/arm/boot/dts/dra7.dtsi|  1 +
 drivers/net/ethernet/ti/cpsw-common.c  | 64 +-
 drivers/net/ethernet/ti/cpsw.c | 11 +++---
 drivers/net/ethernet/ti/cpsw.h |  3 +-
 drivers/net/ethernet/ti/davinci_emac.c | 44 ++-
 6 files changed, 65 insertions(+), 59 deletions(-)

-- 
2.6.0.rc2.10.gf4d9753

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

[net-next PATCH 3/4] arm: dts: dra7: add syscon phandle to cpsw node

2015-09-21 Thread Mugunthan V N 
There are 2 MACIDs stored in the control module of the dra7.
These are read by the cpsw driver if no valid MACID was found
in the devicetree.

Signed-off-by: Mugunthan V N 
---
 arch/arm/boot/dts/dra7.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 5d65db9..76c739d 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -1447,6 +1447,7 @@
 ,
 ;
ranges;
+   syscon = <_conf>;
status = "disabled";
 
davinci_mdio: mdio@48485000 {
-- 
2.6.0.rc2.10.gf4d9753

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

[net-next PATCH 2/4] drivers: net: cpsw-common: add support for reading mac address for dra7 and am437x platforms

2015-09-21 Thread Mugunthan V N 
Adding support for reading mac address using syscon driver for
dra7 and am437x platforms

Signed-off-by: Mugunthan V N 
---
 drivers/net/ethernet/ti/cpsw-common.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/net/ethernet/ti/cpsw-common.c 
b/drivers/net/ethernet/ti/cpsw-common.c
index c70417c..c08be62 100644
--- a/drivers/net/ethernet/ti/cpsw-common.c
+++ b/drivers/net/ethernet/ti/cpsw-common.c
@@ -87,6 +87,12 @@ int ti_cm_get_macid(struct device *dev, int slave, u8 
*mac_addr)
if (of_device_is_compatible(dev->of_node, "ti,dm816-emac"))
return cpsw_am33xx_cm_get_macid(dev, 0x30, slave, mac_addr);
 
+   if (of_machine_is_compatible("ti,am4372"))
+   return cpsw_am33xx_cm_get_macid(dev, 0x630, slave, mac_addr);
+
+   if (of_machine_is_compatible("ti,dra7"))
+   return davinci_emac_3517_get_macid(dev, 0x514, slave, mac_addr);
+
dev_err(dev, "incompatible machine/device type for reading mac 
address\n");
return -ENOENT;
 }
-- 
2.6.0.rc2.10.gf4d9753

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

[net-next PATCH 1/4] drivers: net: cpsw: davinci_emac: move reading mac id to common file

2015-09-21 Thread Mugunthan V N 
Moving mac address reading from ethernet driver to common
file for better maintenance and for code reusable.

Signed-off-by: Mugunthan V N 
---
 drivers/net/ethernet/ti/cpsw-common.c  | 58 --
 drivers/net/ethernet/ti/cpsw.c | 11 +++
 drivers/net/ethernet/ti/cpsw.h |  3 +-
 drivers/net/ethernet/ti/davinci_emac.c | 44 ++
 4 files changed, 57 insertions(+), 59 deletions(-)

diff --git a/drivers/net/ethernet/ti/cpsw-common.c 
b/drivers/net/ethernet/ti/cpsw-common.c
index f595094..c70417c 100644
--- a/drivers/net/ethernet/ti/cpsw-common.c
+++ b/drivers/net/ethernet/ti/cpsw-common.c
@@ -19,11 +19,38 @@
 
 #include "cpsw.h"
 
-#define AM33XX_CTRL_MAC_LO_REG(offset, id) ((offset) + 0x8 * (id))
-#define AM33XX_CTRL_MAC_HI_REG(offset, id) ((offset) + 0x8 * (id) + 0x4)
+#define CTRL_MAC_LO_REG(offset, id) ((offset) + 0x8 * (id))
+#define CTRL_MAC_HI_REG(offset, id) ((offset) + 0x8 * (id) + 0x4)
 
-int cpsw_am33xx_cm_get_macid(struct device *dev, u16 offset, int slave,
-u8 *mac_addr)
+static int davinci_emac_3517_get_macid(struct device *dev, u16 offset,
+  int slave, u8 *mac_addr)
+{
+   u32 macid_lsb;
+   u32 macid_msb;
+   struct regmap *syscon;
+
+   syscon = syscon_regmap_lookup_by_phandle(dev->of_node, "syscon");
+   if (IS_ERR(syscon)) {
+   if (PTR_ERR(syscon) == -ENODEV)
+   return 0;
+   return PTR_ERR(syscon);
+   }
+
+   regmap_read(syscon, CTRL_MAC_LO_REG(offset, slave), _lsb);
+   regmap_read(syscon, CTRL_MAC_HI_REG(offset, slave), _msb);
+
+   mac_addr[0] = (macid_msb >> 16) & 0xff;
+   mac_addr[1] = (macid_msb >> 8)  & 0xff;
+   mac_addr[2] = macid_msb & 0xff;
+   mac_addr[3] = (macid_lsb >> 16) & 0xff;
+   mac_addr[4] = (macid_lsb >> 8)  & 0xff;
+   mac_addr[5] = macid_lsb & 0xff;
+
+   return 0;
+}
+
+static int cpsw_am33xx_cm_get_macid(struct device *dev, u16 offset, int slave,
+   u8 *mac_addr)
 {
u32 macid_lo;
u32 macid_hi;
@@ -36,10 +63,8 @@ int cpsw_am33xx_cm_get_macid(struct device *dev, u16 offset, 
int slave,
return PTR_ERR(syscon);
}
 
-   regmap_read(syscon, AM33XX_CTRL_MAC_LO_REG(offset, slave),
-   _lo);
-   regmap_read(syscon, AM33XX_CTRL_MAC_HI_REG(offset, slave),
-   _hi);
+   regmap_read(syscon, CTRL_MAC_LO_REG(offset, slave), _lo);
+   regmap_read(syscon, CTRL_MAC_HI_REG(offset, slave), _hi);
 
mac_addr[5] = (macid_lo >> 8) & 0xff;
mac_addr[4] = macid_lo & 0xff;
@@ -50,6 +75,21 @@ int cpsw_am33xx_cm_get_macid(struct device *dev, u16 offset, 
int slave,
 
return 0;
 }
-EXPORT_SYMBOL_GPL(cpsw_am33xx_cm_get_macid);
+
+int ti_cm_get_macid(struct device *dev, int slave, u8 *mac_addr)
+{
+   if (of_machine_is_compatible("ti,am33xx"))
+   return cpsw_am33xx_cm_get_macid(dev, 0x630, slave, mac_addr);
+
+   if (of_device_is_compatible(dev->of_node, "ti,am3517-emac"))
+   return davinci_emac_3517_get_macid(dev, 0x110, slave, mac_addr);
+
+   if (of_device_is_compatible(dev->of_node, "ti,dm816-emac"))
+   return cpsw_am33xx_cm_get_macid(dev, 0x30, slave, mac_addr);
+
+   dev_err(dev, "incompatible machine/device type for reading mac 
address\n");
+   return -ENOENT;
+}
+EXPORT_SYMBOL_GPL(ti_cm_get_macid);
 
 MODULE_LICENSE("GPL");
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index c670317..75584cc 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -2058,13 +2058,10 @@ no_phy_slave:
if (mac_addr) {
memcpy(slave_data->mac_addr, mac_addr, ETH_ALEN);
} else {
-   if (of_machine_is_compatible("ti,am33xx")) {
-   ret = cpsw_am33xx_cm_get_macid(>dev,
-   0x630, i,
-   slave_data->mac_addr);
-   if (ret)
-   return ret;
-   }
+   ret = ti_cm_get_macid(>dev, i,
+ slave_data->mac_addr);
+   if (ret)
+   return ret;
}
if (data->dual_emac) {
if (of_property_read_u32(slave_node, 
"dual_emac_res_vlan",
diff --git a/drivers/net/ethernet/ti/cpsw.h b/drivers/net/ethernet/ti/cpsw.h
index ca90efa..442a703 100644
--- a/drivers/net/ethernet/ti/cpsw.h
+++ b/drivers/net/ethernet/ti/cpsw.h
@@ -41,7 +41,6 @@ struct cpsw_platform_data {
 };
 
 void cpsw_phy_sel(struct device *dev, phy_interface_t phy_mode, int slave);
-int

Re: [PATCH 00/38] Fixes related to incorrect usage of unsigned types

2015-09-21 Thread David Howells 
Andrzej Hajda  wrote:

> Semantic patch finds comparisons of types:
> unsigned < 0
> unsigned >= 0
> The former is always false, the latter is always true.
> Such comparisons are useless, so theoretically they could be
> safely removed, but their presence quite often indicates bugs.

Or someone has left them in because they don't matter and there's the
possibility that the type being tested might be or become signed under some
circumstances.  If the comparison is useless, I'd expect the compiler to just
discard it - for such cases your patch is pointless.

If I have, for example:

unsigned x;

if (x == 0 || x > 27)
give_a_range_error();

I will write this as:

unsigned x;

if (x <= 0 || x > 27)
give_a_range_error();

because it that gives a way to handle x being changed to signed at some point
in the future for no cost.  In which case, your changing the <= to an ==
"because the < part of the case is useless" is arguably wrong.

David
--
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 RFC v4 3/8] ASoC: hdmi-codec: Add hdmi-codec for external HDMI-encoders

2015-09-21 Thread Jyri Sarha 

On 09/21/15 12:31, Russell King - ARM Linux wrote:

On Sat, Sep 19, 2015 at 10:54:51AM -0700, Mark Brown wrote:

On Fri, Sep 18, 2015 at 02:06:40PM +0300, Jyri Sarha wrote:

+#define SPDIF_FORMATS  (SNDRV_PCM_FMTBIT_S16_LE | SNDRV_PCM_FMTBIT_S16_BE |\
+SNDRV_PCM_FMTBIT_S20_3LE | SNDRV_PCM_FMTBIT_S20_3BE |\
+SNDRV_PCM_FMTBIT_S24_3LE | SNDRV_PCM_FMTBIT_S24_3BE |\
+SNDRV_PCM_FMTBIT_S24_LE | SNDRV_PCM_FMTBIT_S24_BE)
+
+#define I2S_FORMATS(SNDRV_PCM_FMTBIT_S16_LE | SNDRV_PCM_FMTBIT_S16_BE |\
+SNDRV_PCM_FMTBIT_S18_3LE | SNDRV_PCM_FMTBIT_S18_3BE |\
+SNDRV_PCM_FMTBIT_S20_3LE | SNDRV_PCM_FMTBIT_S20_3BE |\
+SNDRV_PCM_FMTBIT_S24_3LE | SNDRV_PCM_FMTBIT_S24_3BE |\
+SNDRV_PCM_FMTBIT_S24_LE | SNDRV_PCM_FMTBIT_S24_BE |\
+SNDRV_PCM_FMTBIT_S32_LE | SNDRV_PCM_FMTBIT_S32_BE)


I'm not sure how abstracted this I2S and S/PDIF DAI business is - it
doesn't feel like something that's going to be a property of all HDMI
devices, and the specific sets of formats above cause me to raise a bit
of an eyebrow.  Should this be an interface where the HDMI chip
registers multiple interfaces if it has them instead of automatically
getting this split as is?


The inclusion of the 32-bit formats does raise an eyebrow here too.
Audio transmission across the HDMI link is S/PDIF, supporting up to
24-bit uncompressed audio (aka L-PCM).

The device may accept 32 bit I2S, but it would have to be truncated to
24 bit before transmitting it to the sink.  This should be mentioned
somewhere.



There is ".sig_bits = 24" in hdmi_i2s_dai, but I can add an explicit 
comment about it.


We needed 32bit format in practice until Peter got 24_LE properly 
working with McASP. I just thought the may still be some platforms out 
there that can not produce 24bit i2s samples for some reason, but work 
just fine with 32bit samples. Those platforms would be limited to less 
than 24bit precision without 32bit formats. But as said, it is not 
critical to us any more and I can drop the 32bit formats as well.


BR,
Jyri



--
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: [net-next PATCH 0/4] Add support for reading macid when DT macid not found

2015-09-21 Thread David Miller 
From: Mugunthan V N 
Date: Mon, 21 Sep 2015 15:56:49 +0530

> Did a boot test on dra7-evm [1] and am437x-gp-evm [2].
> Pushed a branch [3] for others to test the patch.
> 
> [1]: http://pastebin.ubuntu.com/12513420/
> [2]: http://pastebin.ubuntu.com/12513428/
> [3]: git://git.ti.com/~mugunthanvnm/ti-linux-kernel/linux.git 
> cpsw-macid-read-support

Series applied, 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 12/17] ARM: OMAP2+: remove misuse of IRQF_NO_SUSPEND flag

2015-09-21 Thread Sudeep Holla 
The IRQF_NO_SUSPEND flag is used to identify the interrupts that should
be left enabled so as to allow them to work as expected during the
suspend-resume cycle, but doesn't guarantee that it will wake the system
from a suspended state, enable_irq_wake is recommended to be used for
the wakeup.

This patch removes the use of IRQF_NO_SUSPEND flags replacing it with
enable_irq_wake instead.

Cc: Tony Lindgren 
Cc: Kevin Hilman 
Cc: linux-omap@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Signed-off-by: Sudeep Holla 
---
 arch/arm/mach-omap2/mux.c| 4 ++--
 arch/arm/mach-omap2/pm34xx.c | 9 -
 2 files changed, 6 insertions(+), 7 deletions(-)

diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
index 176eef6ef338..12012bef8e63 100644
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -810,13 +810,13 @@ int __init omap_mux_late_init(void)
return 0;
 
ret = request_irq(omap_prcm_event_to_irq("io"),
-   omap_hwmod_mux_handle_irq, IRQF_SHARED | IRQF_NO_SUSPEND,
+   omap_hwmod_mux_handle_irq, IRQF_SHARED,
"hwmod_io", omap_mux_late_init);
 
if (ret)
pr_warn("mux: Failed to setup hwmod io irq %d\n", ret);
 
-   return 0;
+   return enable_irq_wake(omap_prcm_event_to_irq("io"));
 }
 
 static void __init omap_mux_package_fixup(struct omap_mux *p,
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 87b98bf92366..4b7ac7cd633a 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -472,23 +472,22 @@ int __init omap3_pm_init(void)
prcm_setup_regs();
 
ret = request_irq(omap_prcm_event_to_irq("wkup"),
-   _prcm_int_handle_wakeup, IRQF_NO_SUSPEND, "pm_wkup", NULL);
+   _prcm_int_handle_wakeup, 0, "pm_wkup", NULL);
 
if (ret) {
pr_err("pm: Failed to request pm_wkup irq\n");
goto err1;
}
+   enable_irq_wake(omap_prcm_event_to_irq("wkup"));
 
/* IO interrupt is shared with mux code */
ret = request_irq(omap_prcm_event_to_irq("io"),
-   _prcm_int_handle_io, IRQF_SHARED | IRQF_NO_SUSPEND, "pm_io",
-   omap3_pm_init);
-   enable_irq(omap_prcm_event_to_irq("io"));
-
+   _prcm_int_handle_io, IRQF_SHARED, "pm_io", omap3_pm_init);
if (ret) {
pr_err("pm: Failed to request pm_io irq\n");
goto err2;
}
+   enable_irq_wake(omap_prcm_event_to_irq("io"));
 
ret = pwrdm_for_each(pwrdms_setup, NULL);
if (ret) {
-- 
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: [alsa-devel] [PATCH RFC v4 2/8] ALSA: pcm: add IEC958 channel status helper for hw_params

2015-09-21 Thread Clemens Ladisch 
Jyri Sarha wrote:
> On 09/21/15 12:37, Russell King - ARM Linux wrote:
>> ALSA documentation (which may be out of date) says that the hw_params
>> callback can be called multiple times during stream setup.  Do we want
>> to be repeatedly programming the HDMI infoframe with different settings,
>> potentially confusing the attached device, or would it be better to do
>> it slightly later (in the prepare callback) after the parameters have
>> been fully negotiated?
>
> If it is possible that hw_params() can be called multiple times, at
> least it does not happen very often. I wonder if it would ever happen
> again after a successful hw_params() call.

It is certainly allowed, and it happens regularly when using OSS
emulation.  AFAIK PulseAudio does something similar when enumerating
devices.

> But there is no downside in using prepare callback.

The prepare callback also can be called multiple times.  This certainly
happens when the stream is stopped/restarted multiple times.

If something does not need to be done again when a stream is restarted,
then it should be done in the hw_params callback.


Regards,
Clemens
--
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: usb: dwc3: gadget: warning on v4.3-rc1

2015-09-21 Thread Felipe Balbi 
On Mon, Sep 21, 2015 at 11:06:27AM +0300, Roger Quadros wrote:
> Hi Felipe,
> 
> I see the following warning when g_zero is loaded
> and USB cable is plugged to host on dra7-evm's USB1 port.
> 
> It happens only once and no longer appears on re-loading gadget
> or plugging/unplugging cable.

already fixed, -rc2 should have the fix.

thanks

-- 
balbi


signature.asc
Description: PGP signature

Re: [alsa-devel] [PATCH RFC v4 2/8] ALSA: pcm: add IEC958 channel status helper for hw_params

2015-09-21 Thread Jyri Sarha 

On 09/21/15 18:08, Clemens Ladisch wrote:

>But there is no downside in using prepare callback.

The prepare callback also can be called multiple times.  This certainly
happens when the stream is stopped/restarted multiple times.

If something does not need to be done again when a stream is restarted,
then it should be done in the hw_params callback.


Oh, forgot about that. This would suggest to keep the stream header 
configuration in the hw_params().


Thanks,
Jyri
--
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/2] ARM: dts: Fix WLAN regression on omap5-uevm

2015-09-21 Thread Tony Lindgren 
* Javier Martinez Canillas  [150921 02:17]:
> [adding Ulf and Tomeu to cc list]
> 
> On Fri, Sep 18, 2015 at 10:27 PM, Tony Lindgren  wrote:
> > * Tony Lindgren  [150918 10:54]:
> >> * Javier Martinez Canillas  [150918 10:39]:
> >> > Hello Tony,
> >> >
> >> > [snip]
> >> >
> >> > >
> >> > > +   vmmcsdio_fixed: fixedregulator-mmcsdio {
> >> > > +   compatible = "regulator-fixed";
> >> > > +   regulator-name = "vmmcsdio_fixed";
> >> > > +   regulator-min-microvolt = <180>;
> >> > > +   regulator-max-microvolt = <180>;
> >> > > +   gpio = < 12 GPIO_ACTIVE_HIGH>;/* gpio140 
> >> > > WLAN_EN */
> >> >
> >> > I know that other OMAP boards use a fake fixed regulator to toggle the
> >> > WiFi enable pin but now the MMC subsystem has proper support for power
> >> > sequence providers so that should be used instead. For simple uses
> >> > like this, Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt
> >> > should be enough.
> >>
> >> Hmm OK great, I'll take a look. Looks like that might also provide a
> >> nice solution for handling the 32k clock from palmas to the wl12xx.
> >
> > It seems it's not quite working yet.. It seems pwrseq_simple.c can't
> > deal with delay on a power pin. It might be best to treat those using
> > the regulator framework because of the refcounting and start-up delay.
> 
> Yes, pwrseq_simple does not support delaying a power pin. IIRC Tomeu
> wanted to add a delay for power / reset pins at some point but then
> the SDIO device he wanted to power up didn't need it so he dropped
> that change at the end. I may be missremembering though.
>
> > I don't think also having regulator handling in pwrseq_simple.c
> > conflicts with the MMC regulators as they can be separate?
> >
> 
> The original "mmc: add support for power-on sequencing through DT" [0]
> patch from Olof that added just properties to the MMC controller slot
> dev node had a "card-external-vcc-supply" for SDIO devices that needed
> an external supply separate to vqmmc and vmmc supplies. The
> pwrseq_simple does not support having an input supply regulator right
> now but one can be added if that is needed.

Yes I think adding support for regulators to pwerseq_simple would
solve the issues for power line for start-up latency and usecount for
shared resources.

> > Also not related to wl12xx, the power pin on mwifiex_sdio 8787 wlan
> > must be asserted low while reset is asserted and must stay low for
> > 300ms after power pin has deasserted. Again using a regulator there
> > for the power pin might make more sense.
> >
> 
> Interesting, I've a patch queued on my tree to convert pwrseq_simple
> to use the GPIO descriptors array API since all the code do now is to
> set GPIO levels high or low for all the pins at the same time. But for
> such a fine grained timing control as you said, I wonder if we should
> just keep the code as it is now. Even when is open coding what
> gpiod_{get,set,put}_array already do, it may make sense if we add
> assert and deassert delay time for each pin.

Well the power pin typically has a latency because of a regulator
somewhere.. And it needs to disabled for PM when not used.. And
it may be shared.. So rather than reinvent the roundish thingy
again, I suggest we just let a regulator handle that.

A reset pin just needs to be toggled, but may have a dependency
to the power pin like in the 8787 case.

> Or maybe such a HW should have its own power sequence provider instead
> of making pwrseq_simple more and more complex?
> 
> > Then getting the 32k clock from palmas is not working either, it
> > seems some better deferred probe handling is needed there if
> > omap_hsmmc is built-in and palmas-clk is a loadable module.
> >
> 
> IIUC from another email, you already solved this.

That deferred probe fix did not solve this one, need to debug further.

> > I think for the fix I'll stick with regulator fixed, let's update
> > it later on unless you have better suggestions.
> 
> Yes, I didn't want to block your fixed regulator approach. I was just
> pointing out that the MMC infrastructure already has support for power
> sequence providers but if what is there doesn't fit your use case, I
> agree that we can go with the regulator fixed for now and then change
> it later.

OK yeah let's fix the issues in the pwrseq so we can finally have
resets working for 8787 too :)

Regards,

Tony

> [0]: http://patchwork.ozlabs.org/patch/312444/

--
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 RFC v4 2/8] ALSA: pcm: add IEC958 channel status helper for hw_params

2015-09-21 Thread Jyri Sarha 

On 09/21/15 12:37, Russell King - ARM Linux wrote:

On Fri, Sep 18, 2015 at 02:06:39PM +0300, Jyri Sarha wrote:

Add IEC958 channel status helper that gets the audio properties from
snd_pcm_hw_params instead of snd_pcm_runtime. This is needed to
produce the channel status bits already in audio stream configuration
phase.


What is the reason for doing this early?



After some thinking, there is no good reason. It makes the codec bit 
more complicated, but that is not a good reason. I'll change that and 
use the prepare callback.


This patch can be dropped.


ALSA documentation (which may be out of date) says that the hw_params
callback can be called multiple times during stream setup.  Do we want
to be repeatedly programming the HDMI infoframe with different settings,
potentially confusing the attached device, or would it be better to do
it slightly later (in the prepare callback) after the parameters have
been fully negotiated?



If it is possible that hw_params() can be called multiple times, at 
least it does not happen very often. I wonder if it would ever happen 
again after a successful hw_params() call. But there is no downside in 
using prepare callback. I was just too much following the way ASoC 
codecs usually do the thing by writing everything to iron as the 
callbacks come in.


Best regards,
Jyri




--
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] mfd: twl6040: Fix deferred probe handling for clk32k

2015-09-21 Thread Tony Lindgren 
* Peter Ujfalusi  [150921 02:59]:
> On 09/18/2015 07:29 PM, Tony Lindgren wrote:
> > Commit 68bab8662f49 ("mfd: twl6040: Optional clk32k clock handling")
> > added clock handling for the 32k clock from palmas-clk. However, that
> > patch did not consider a typical situation where twl6040 is built-in,
> > and palmas-clk is a loadable module like we have in omap2plus_defconfig.
> > 
> > If palmas-clk is not loaded before twl6040 probes, we will get a
> > "clk32k is not handled" warning during booting. This means that any
> > drivers relying on this clock will mysteriously fail, including
> > omap5-uevm WLAN and audio.
> > 
> > Note that for WLAN, we probably should also eventually get
> > the clk32kgaudio for MMC3 directly as that's shared between
> > audio and WLAN SDIO at least for omap5-uevm. It seems the
> > WLAN chip cannot get it as otherwise MMC3 won't get properly
> > probed.
> 
> While this is going to 'fix' the WLAN because currently the twl6040 is powered
> on all the time (32k clock is enabled). My plan is to finally implement the
> power state handling for the twl6040, which means that w/o audio activity the
> twl6040 will be turned off. This will imply that any clock which is only used
> by twl6040 will be off as well.
> The proper solution would be to add clock handling to the WLAN driver stack.

Yes the place to request this clock is using pwrseq_simple.c for MMC3.
It seems there are some issues with deferred probe handling there too
though.

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

[PATCH v2 1/1] ARM: DTS: dra72-evm: remove cpsw gpio hogging and add mode-gpios

2015-09-21 Thread Mugunthan V N 
With the current implementation of GPIO hogging and with
gpio-pcf857x is built as module, ethernet doesn't work on boot
and doesn't throw any error/warning to user. Ethernet becomes
operational when inserting gpio-pcf857x module, even this time
there is no error/warning logs to user that ethernet is
operational.

When using with NFS rootfs and gpio-pcf857x as module, board
doesn't boot as it doesn't get any ip address and doesn't throw
any error/warning. To over come this, now cpsw driver tries to
get mode-gpios. When gpio-pcf857x is built as module it will
throw error, so that user can decide either to built in
gpio-pcf857x to continue with nfs boot or choose alternate rootfs
filesystem like sd/ramdisk.

When using mmc/ramdisk as root fs, cpsw will probe defer and
re-probes again when gpio-pcf857x module is inserted and ethernet
becomes operational.

Signed-off-by: Mugunthan V N 
---

The driver patch is applied to net-next branch (also present in
linux-next) with commit: '1d147ccbfc35 ("drivers: net: cpsw: Add
support to drive gpios for ethernet to be functional")

Tested on DRA72x EVM, logs [1] and pushed a branch [2] for testing

[1]: http://pastebin.ubuntu.com/12514591/
[2]: git://git.ti.com/~mugunthanvnm/ti-linux-kernel/linux.git 
cpsw-mode-gpios-dt 

Changes from initial version:
* Modified the commit message to add more information

---
 arch/arm/boot/dts/dra72-evm.dts | 7 +--
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/arch/arm/boot/dts/dra72-evm.dts b/arch/arm/boot/dts/dra72-evm.dts
index 6f6bd98..a12c6f4 100644
--- a/arch/arm/boot/dts/dra72-evm.dts
+++ b/arch/arm/boot/dts/dra72-evm.dts
@@ -353,12 +353,6 @@
interrupts = <11 IRQ_TYPE_EDGE_FALLING>;
interrupt-controller;
#interrupt-cells = <2>;
-
-   cpsw_sel_s0 {
-   gpio-hog;
-   gpios = <4 GPIO_ACTIVE_HIGH>;
-   output-low;
-   };
};
 };
 
@@ -590,6 +584,7 @@
pinctrl-0 = <_default>;
pinctrl-1 = <_sleep>;
slaves = <1>;
+   mode-gpios = <_gpio_21 4 GPIO_ACTIVE_HIGH>;
 };
 
 _emac0 {
-- 
2.6.0.rc2.10.gf4d9753

--
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 RFC v4 3/8] ASoC: hdmi-codec: Add hdmi-codec for external HDMI-encoders

2015-09-21 Thread Russell King - ARM Linux 
On Sat, Sep 19, 2015 at 10:54:51AM -0700, Mark Brown wrote:
> On Fri, Sep 18, 2015 at 02:06:40PM +0300, Jyri Sarha wrote:
> > +#define SPDIF_FORMATS  (SNDRV_PCM_FMTBIT_S16_LE | 
> > SNDRV_PCM_FMTBIT_S16_BE |\
> > +SNDRV_PCM_FMTBIT_S20_3LE | SNDRV_PCM_FMTBIT_S20_3BE |\
> > +SNDRV_PCM_FMTBIT_S24_3LE | SNDRV_PCM_FMTBIT_S24_3BE |\
> > +SNDRV_PCM_FMTBIT_S24_LE | SNDRV_PCM_FMTBIT_S24_BE)
> > +
> > +#define I2S_FORMATS(SNDRV_PCM_FMTBIT_S16_LE | 
> > SNDRV_PCM_FMTBIT_S16_BE |\
> > +SNDRV_PCM_FMTBIT_S18_3LE | SNDRV_PCM_FMTBIT_S18_3BE |\
> > +SNDRV_PCM_FMTBIT_S20_3LE | SNDRV_PCM_FMTBIT_S20_3BE |\
> > +SNDRV_PCM_FMTBIT_S24_3LE | SNDRV_PCM_FMTBIT_S24_3BE |\
> > +SNDRV_PCM_FMTBIT_S24_LE | SNDRV_PCM_FMTBIT_S24_BE |\
> > +SNDRV_PCM_FMTBIT_S32_LE | SNDRV_PCM_FMTBIT_S32_BE)
> 
> I'm not sure how abstracted this I2S and S/PDIF DAI business is - it
> doesn't feel like something that's going to be a property of all HDMI
> devices, and the specific sets of formats above cause me to raise a bit
> of an eyebrow.  Should this be an interface where the HDMI chip
> registers multiple interfaces if it has them instead of automatically
> getting this split as is?

The inclusion of the 32-bit formats does raise an eyebrow here too.
Audio transmission across the HDMI link is S/PDIF, supporting up to
24-bit uncompressed audio (aka L-PCM).

The device may accept 32 bit I2S, but it would have to be truncated to
24 bit before transmitting it to the sink.  This should be mentioned
somewhere.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
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/1] ARM: DTS: dra72-evm: remove cpsw gpio hogging and add select-slave-gpio

2015-09-21 Thread Mugunthan V N 
On Monday 21 September 2015 01:34 PM, Mugunthan V N wrote:
> Since GPIO hogging fails to through error when booting with
> gpio-pcf857x as module and NFS root filesystem. So by having
> mode-gpio, it throw error to user so that the used can make
> gpio-pcf857x as inbuilt for NFS. When using mmc/ramdisk as root
> fs, cpsw will probe defer and re-probes again when gpio-pcf857x
> module is inserted and ethernet becomes operational.
> 
> Signed-off-by: Mugunthan V N 

There is some typo error. Will submit a v2 ASAP

Regards
Mugunthan V N

--
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 RFC v4 2/8] ALSA: pcm: add IEC958 channel status helper for hw_params

2015-09-21 Thread Russell King - ARM Linux 
On Fri, Sep 18, 2015 at 02:06:39PM +0300, Jyri Sarha wrote:
> Add IEC958 channel status helper that gets the audio properties from
> snd_pcm_hw_params instead of snd_pcm_runtime. This is needed to
> produce the channel status bits already in audio stream configuration
> phase.

What is the reason for doing this early?

ALSA documentation (which may be out of date) says that the hw_params
callback can be called multiple times during stream setup.  Do we want
to be repeatedly programming the HDMI infoframe with different settings,
potentially confusing the attached device, or would it be better to do
it slightly later (in the prepare callback) after the parameters have
been fully negotiated?

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
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] mfd: twl6040: Fix deferred probe handling for clk32k

2015-09-21 Thread Peter Ujfalusi 
On 09/18/2015 07:29 PM, Tony Lindgren wrote:
> Commit 68bab8662f49 ("mfd: twl6040: Optional clk32k clock handling")
> added clock handling for the 32k clock from palmas-clk. However, that
> patch did not consider a typical situation where twl6040 is built-in,
> and palmas-clk is a loadable module like we have in omap2plus_defconfig.
> 
> If palmas-clk is not loaded before twl6040 probes, we will get a
> "clk32k is not handled" warning during booting. This means that any
> drivers relying on this clock will mysteriously fail, including
> omap5-uevm WLAN and audio.
> 
> Note that for WLAN, we probably should also eventually get
> the clk32kgaudio for MMC3 directly as that's shared between
> audio and WLAN SDIO at least for omap5-uevm. It seems the
> WLAN chip cannot get it as otherwise MMC3 won't get properly
> probed.

While this is going to 'fix' the WLAN because currently the twl6040 is powered
on all the time (32k clock is enabled). My plan is to finally implement the
power state handling for the twl6040, which means that w/o audio activity the
twl6040 will be turned off. This will imply that any clock which is only used
by twl6040 will be off as well.
The proper solution would be to add clock handling to the WLAN driver stack.

Otherwise:
Acked-by: Peter Ujfalusi 

> Fixes: 68bab8662f49 ("mfd: twl6040: Optional clk32k clock handling")
> Cc: Benoit Cousson 
> Cc: Dr. H. Nikolaus Schaller 
> Cc: Grazvydas Ignotas 
> Cc: Lee Jones 
> Cc: Peter Ujfalusi 
> Cc: Samuel Ortiz 
> Cc: Sourav Poddar 
> Signed-off-by: Tony Lindgren 
> ---
>  drivers/mfd/twl6040.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> --- a/drivers/mfd/twl6040.c
> +++ b/drivers/mfd/twl6040.c
> @@ -647,6 +647,8 @@ static int twl6040_probe(struct i2c_client *client,
>  
>   twl6040->clk32k = devm_clk_get(>dev, "clk32k");
>   if (IS_ERR(twl6040->clk32k)) {
> + if (PTR_ERR(twl6040->clk32k) == -EPROBE_DEFER)
> + return -EPROBE_DEFER;
>   dev_info(>dev, "clk32k is not handled\n");
>   twl6040->clk32k = NULL;
>   }
> 


-- 
Péter
--
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 28/38] video/omap: remove invalid check

2015-09-21 Thread Andrzej Hajda 
regno is unsigned so it cannot be negative.

The problem has been detected using proposed semantic patch
scripts/coccinelle/tests/unsigned_lesser_than_zero.cocci [1].

[1]: http://permalink.gmane.org/gmane.linux.kernel/2038576

Signed-off-by: Andrzej Hajda 
---
 drivers/video/fbdev/omap/omapfb_main.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/drivers/video/fbdev/omap/omapfb_main.c 
b/drivers/video/fbdev/omap/omapfb_main.c
index 1fb3ea3..393ae1b 100644
--- a/drivers/video/fbdev/omap/omapfb_main.c
+++ b/drivers/video/fbdev/omap/omapfb_main.c
@@ -276,11 +276,6 @@ static int _setcolreg(struct fb_info *info, u_int regno, 
u_int red, u_int green,
if (r != 0)
break;
 
-   if (regno < 0) {
-   r = -EINVAL;
-   break;
-   }
-
if (regno < 16) {
u16 pal;
pal = ((red >> (16 - var->red.length)) <<
-- 
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 RFC v4 3/8] ASoC: hdmi-codec: Add hdmi-codec for external HDMI-encoders

2015-09-21 Thread Mark Brown 
On Mon, Sep 21, 2015 at 04:41:20PM +0300, Jyri Sarha wrote:
> On 09/21/15 12:31, Russell King - ARM Linux wrote:

> >The device may accept 32 bit I2S, but it would have to be truncated to
> >24 bit before transmitting it to the sink.  This should be mentioned
> >somewhere.

> There is ".sig_bits = 24" in hdmi_i2s_dai, but I can add an explicit comment
> about it.

> We needed 32bit format in practice until Peter got 24_LE properly working
> with McASP. I just thought the may still be some platforms out there that
> can not produce 24bit i2s samples for some reason, but work just fine with
> 32bit samples. Those platforms would be limited to less than 24bit precision
> without 32bit formats. But as said, it is not critical to us any more and I
> can drop the 32bit formats as well.

Yes, this is currently a bit messy - we should really be able to allow
S24_LE and S32 to interoperate better without drivers having to know
about it since physically they are essentially compatible in memory.
I'm pretty much OK with it for now since even with that framework
support it should be harmless.


signature.asc
Description: Digital signature

Re: [PATCH RFC v4 4/8] drm/i2c: tda998x: Add support of a DT graph of ports

2015-09-21 Thread Rob Herring 
On 09/18/2015 06:06 AM, Jyri Sarha wrote:
> From: Jean-Francois Moine 
> 
> Two kinds of ports may be declared in a DT graph of ports: video and audio.
> This patch accepts the port value from a video port as an alternative
> to the video-ports property.
> It also accepts audio ports in the case the transmitter is not used as
> a slave encoder.
> The new file include/sound/tda998x.h prepares to the definition of
> a tda998x CODEC.
> 
> Signed-off-by: Jean-Francois Moine 
> Signed-off-by: Jyri Sarha 
> ---
>  .../devicetree/bindings/drm/i2c/tda998x.txt| 51 
>  drivers/gpu/drm/i2c/tda998x_drv.c  | 90 
> +++---
>  include/sound/tda998x.h|  8 ++
>  3 files changed, 140 insertions(+), 9 deletions(-)
>  create mode 100644 include/sound/tda998x.h
> 
> diff --git a/Documentation/devicetree/bindings/drm/i2c/tda998x.txt 
> b/Documentation/devicetree/bindings/drm/i2c/tda998x.txt
> index e9e4bce..35f6a80 100644
> --- a/Documentation/devicetree/bindings/drm/i2c/tda998x.txt
> +++ b/Documentation/devicetree/bindings/drm/i2c/tda998x.txt
> @@ -16,6 +16,35 @@ Optional properties:
>  
>- video-ports: 24 bits value which defines how the video controller
>   output is wired to the TDA998x input - default: <0x230145>
> + This property is not used when ports are defined.
> +
> +Optional nodes:
> +
> +  - port: up to three ports.
> + The ports are defined according to [1].
> +
> +Video port.
> + There may be only one video port.
> + This one must contain the following property:
> +
> + - port-type: must be "rgb"

Why do you need this if there is no other choice? The port number should
define which one is video.

> +
> + and may contain the optional property:
> +
> + - reg: 24 bits value which defines how the video controller
> + output is wired to the TDA998x input (video pins)
> + When absent, the default value is <0x230145>.

I'm failing to decode how this value works. In any case, I would keep
this as a vendor specific property rather than abusing reg.

> +
> +Audio ports.
> + There may be one or two audio ports.
> + These ones must contain the following properties:
> +
> + - port-type: must be "i2s" or "spdif"
> +
> + - reg: 8 bits value which defines how the audio controller
> + output is wired to the TDA998x input (audio pins)

reg is 32-bits.

> +
> +[1] Documentation/devicetree/bindings/graph.txt
>  
>  Example:
>  
> @@ -26,4 +55,26 @@ Example:
>   interrupts = <27 2>;/* falling edge */
>   pinctrl-0 = <_camera>;
>   pinctrl-names = "default";
> +
> + port@230145 {
> + port-type = "rgb";
> + reg = <0x230145>;
> + hdmi_0: endpoint {
> + remote-endpoint = <_0>;
> + };
> + };
> + port@3 {/* AP1 = I2S */

Is 3 significant? What happened to 0-2?

> + port-type = "i2s";
> + reg = <0x03>;
> + tda998x_i2s: endpoint {
> + remote-endpoint = <_i2s>;
> + };
> + };
> + port@4 { /* AP2 = S/PDIF */
> + port-type = "spdif";
> + reg = <0x04>;
> + tda998x_spdif: endpoint {
> + remote-endpoint = <_spdif1>;
> + };
> + };
>   };
> diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c 
> b/drivers/gpu/drm/i2c/tda998x_drv.c
> index 424228b..0952eac 100644
> --- a/drivers/gpu/drm/i2c/tda998x_drv.c
> +++ b/drivers/gpu/drm/i2c/tda998x_drv.c
> @@ -27,6 +27,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #define DBG(fmt, ...) DRM_DEBUG(fmt"\n", ##__VA_ARGS__)
>  
> @@ -47,6 +48,8 @@ struct tda998x_priv {
>   wait_queue_head_t wq_edid;
>   volatile int wq_edid_wait;
>   struct drm_encoder *encoder;
> +
> + struct tda998x_audio audio;
>  };
>  
>  #define to_tda998x_priv(x)  ((struct tda998x_priv 
> *)to_encoder_slave(x)->slave_priv)
> @@ -774,6 +777,8 @@ static void tda998x_encoder_set_config(struct 
> tda998x_priv *priv,
>   (p->mirr_f ? VIP_CNTRL_2_MIRR_F : 0);
>  
>   priv->params = *p;
> + priv->audio.port_types[0] = p->audio_format;
> + priv->audio.ports[0] = p->audio_cfg;
>  }
>  
>  static void tda998x_encoder_dpms(struct tda998x_priv *priv, int mode)
> @@ -1230,9 +1235,57 @@ static struct drm_encoder_slave_funcs 
> tda998x_encoder_slave_funcs = {
>  
>  /* I2C driver functions */
>  
> +static int tda998x_parse_ports(struct tda998x_priv *priv,
> + struct device_node *np)
> +{
> + struct device_node *of_port;
> + const char *port_type;
> +

Re: usb: dwc3: gadget: warning on v4.3-rc1

2015-09-21 Thread Felipe Balbi 
On Mon, Sep 21, 2015 at 09:41:50AM -0500, Felipe Balbi wrote:
> On Mon, Sep 21, 2015 at 11:06:27AM +0300, Roger Quadros wrote:
> > Hi Felipe,
> > 
> > I see the following warning when g_zero is loaded
> > and USB cable is plugged to host on dra7-evm's USB1 port.
> > 
> > It happens only once and no longer appears on re-loading gadget
> > or plugging/unplugging cable.
> 
> already fixed, -rc2 should have the fix.

actually, the commit is Greg's queue, should hit -rc3 if LC doesn't
take all of Greg's time :-)

cheers

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH 2/2] ARM: dts: Fix WLAN regression on omap5-uevm

2015-09-21 Thread Javier Martinez Canillas 
[adding Ulf and Tomeu to cc list]

On Fri, Sep 18, 2015 at 10:27 PM, Tony Lindgren  wrote:
> * Tony Lindgren  [150918 10:54]:
>> * Javier Martinez Canillas  [150918 10:39]:
>> > Hello Tony,
>> >
>> > [snip]
>> >
>> > >
>> > > +   vmmcsdio_fixed: fixedregulator-mmcsdio {
>> > > +   compatible = "regulator-fixed";
>> > > +   regulator-name = "vmmcsdio_fixed";
>> > > +   regulator-min-microvolt = <180>;
>> > > +   regulator-max-microvolt = <180>;
>> > > +   gpio = < 12 GPIO_ACTIVE_HIGH>;/* gpio140 
>> > > WLAN_EN */
>> >
>> > I know that other OMAP boards use a fake fixed regulator to toggle the
>> > WiFi enable pin but now the MMC subsystem has proper support for power
>> > sequence providers so that should be used instead. For simple uses
>> > like this, Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt
>> > should be enough.
>>
>> Hmm OK great, I'll take a look. Looks like that might also provide a
>> nice solution for handling the 32k clock from palmas to the wl12xx.
>
> It seems it's not quite working yet.. It seems pwrseq_simple.c can't
> deal with delay on a power pin. It might be best to treat those using
> the regulator framework because of the refcounting and start-up delay.

Yes, pwrseq_simple does not support delaying a power pin. IIRC Tomeu
wanted to add a delay for power / reset pins at some point but then
the SDIO device he wanted to power up didn't need it so he dropped
that change at the end. I may be missremembering though.

> I don't think also having regulator handling in pwrseq_simple.c
> conflicts with the MMC regulators as they can be separate?
>

The original "mmc: add support for power-on sequencing through DT" [0]
patch from Olof that added just properties to the MMC controller slot
dev node had a "card-external-vcc-supply" for SDIO devices that needed
an external supply separate to vqmmc and vmmc supplies. The
pwrseq_simple does not support having an input supply regulator right
now but one can be added if that is needed.

> Also not related to wl12xx, the power pin on mwifiex_sdio 8787 wlan
> must be asserted low while reset is asserted and must stay low for
> 300ms after power pin has deasserted. Again using a regulator there
> for the power pin might make more sense.
>

Interesting, I've a patch queued on my tree to convert pwrseq_simple
to use the GPIO descriptors array API since all the code do now is to
set GPIO levels high or low for all the pins at the same time. But for
such a fine grained timing control as you said, I wonder if we should
just keep the code as it is now. Even when is open coding what
gpiod_{get,set,put}_array already do, it may make sense if we add
assert and deassert delay time for each pin.

Or maybe such a HW should have its own power sequence provider instead
of making pwrseq_simple more and more complex?

> Then getting the 32k clock from palmas is not working either, it
> seems some better deferred probe handling is needed there if
> omap_hsmmc is built-in and palmas-clk is a loadable module.
>

IIUC from another email, you already solved this.

> I think for the fix I'll stick with regulator fixed, let's update
> it later on unless you have better suggestions.
>

Yes, I didn't want to block your fixed regulator approach. I was just
pointing out that the MMC infrastructure already has support for power
sequence providers but if what is there doesn't fit your use case, I
agree that we can go with the regulator fixed for now and then change
it later.

>
> Cheers,
>
> Tony

[0]: http://patchwork.ozlabs.org/patch/312444/

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