[PATCH 1/2] ARM: dts: omap5-uevm: remove always_on, boot_on from smps10_out1

[PATCH 1/2] ARM: dts: omap5-uevm: remove always_on, boot_on from smps10_out1

[Kishon Vijay Abraham I]

smps10 should be enabled only in the case of host mode. So stop
doing always_on, boot_on from smps10_out1. The driver will enable it in host
mode.

Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
---
 arch/arm/boot/dts/omap5-uevm.dts |    2 --
 1 file changed, 2 deletions(-)

diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index d784b3a..e06a04a 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -334,8 +334,6 @@
 					regulator-name = "smps10_out1";
 					regulator-min-microvolt = <5000000>;
 					regulator-max-microvolt = <5000000>;
-					regulator-always-on;
-					regulator-boot-on;
 				};
 
 				ldo1_reg: ldo1 {
-- 
1.7.10.4

[PATCH 2/2] ARM: dts: omap5: Add dr_mode for dwc3

[Kishon Vijay Abraham I]

From: George Cherian <george.cherian@ti.com>

Added dr_mode property in dwc3 and set its default mode to device.

Signed-off-by: George Cherian <george.cherian@ti.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
---
 arch/arm/boot/dts/omap5.dtsi |    1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 6d0a1d5..ef598af 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -652,6 +652,7 @@
 				reg = <0x4a030000 0x10000>;
 				interrupts = <GIC_SPI 92 IRQ_TYPE_LEVEL_HIGH>;
 				usb-phy = <&usb2_phy>, <&usb3_phy>;
+				dr_mode = "peripheral";
 				tx-fifo-resize;
 			};
 		};
-- 
1.7.10.4

Re: [PATCH 2/2] ARM: dts: omap5: Add dr_mode for dwc3

[Roger Quadros]

Hi,

On 10/10/2013 01:49 PM, Kishon Vijay Abraham I wrote:
> From: George Cherian <george.cherian@ti.com>
> 
> Added dr_mode property in dwc3 and set its default mode to device.

If there is a specific reason why this is not set to "otg", we need
to explain it here.

AFAIK the port is meant to be used as OTG port.

> 
> Signed-off-by: George Cherian <george.cherian@ti.com>
> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
> ---
>  arch/arm/boot/dts/omap5.dtsi |    1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
> index 6d0a1d5..ef598af 100644
> --- a/arch/arm/boot/dts/omap5.dtsi
> +++ b/arch/arm/boot/dts/omap5.dtsi
> @@ -652,6 +652,7 @@
>  				reg = <0x4a030000 0x10000>;
>  				interrupts = <GIC_SPI 92 IRQ_TYPE_LEVEL_HIGH>;
>  				usb-phy = <&usb2_phy>, <&usb3_phy>;
> +				dr_mode = "peripheral";
>  				tx-fifo-resize;
>  			};
>  		};
> 

cheers,
-roger

[PATCH v2 2/2] ARM: dts: omap5: Add dr_mode for dwc3

[Kishon Vijay Abraham I]

From: George Cherian <george.cherian@ti.com>

Added dr_mode property in dwc3 and set its default mode to device.
Currently dwc3 driver doesn't have support for OTG mode. So explicitly
setting to peripheral even dwc3 is a OTG controller since OMAP5 has
already got an EHCI host.

Signed-off-by: George Cherian <george.cherian@ti.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
---
Changes from v1:
Changed the commit log to explain why dr_mode was not set to OTG.
 arch/arm/boot/dts/omap5.dtsi |    1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 6d0a1d5..ef598af 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -652,6 +652,7 @@
 				reg = <0x4a030000 0x10000>;
 				interrupts = <GIC_SPI 92 IRQ_TYPE_LEVEL_HIGH>;
 				usb-phy = <&usb2_phy>, <&usb3_phy>;
+				dr_mode = "peripheral";
 				tx-fifo-resize;
 			};
 		};
-- 
1.7.10.4

Re: [PATCH v2 2/2] ARM: dts: omap5: Add dr_mode for dwc3

[Kishon Vijay Abraham I]

Benoit,

On Tuesday 15 October 2013 11:19 AM, Kishon Vijay Abraham I wrote:
> From: George Cherian <george.cherian@ti.com>
> 
> Added dr_mode property in dwc3 and set its default mode to device.
> Currently dwc3 driver doesn't have support for OTG mode. So explicitly
> setting to peripheral even dwc3 is a OTG controller since OMAP5 has
> already got an EHCI host.
> 
> Signed-off-by: George Cherian <george.cherian@ti.com>
> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>

Can you take this patch for 3.13?

Thanks
Kishon
> ---
> Changes from v1:
> Changed the commit log to explain why dr_mode was not set to OTG.
>  arch/arm/boot/dts/omap5.dtsi |    1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
> index 6d0a1d5..ef598af 100644
> --- a/arch/arm/boot/dts/omap5.dtsi
> +++ b/arch/arm/boot/dts/omap5.dtsi
> @@ -652,6 +652,7 @@
>  				reg = <0x4a030000 0x10000>;
>  				interrupts = <GIC_SPI 92 IRQ_TYPE_LEVEL_HIGH>;
>  				usb-phy = <&usb2_phy>, <&usb3_phy>;
> +				dr_mode = "peripheral";
>  				tx-fifo-resize;
>  			};
>  		};
> 

Re: [PATCH v2 2/2] ARM: dts: omap5: Add dr_mode for dwc3

[Benoit Cousson]

Hi Kishon,

On 16/10/2013 15:17, Kishon Vijay Abraham I wrote:
> Benoit,
>
> On Tuesday 15 October 2013 11:19 AM, Kishon Vijay Abraham I wrote:
>> From: George Cherian <george.cherian@ti.com>
>>
>> Added dr_mode property in dwc3 and set its default mode to device.
>> Currently dwc3 driver doesn't have support for OTG mode. So explicitly
>> setting to peripheral even dwc3 is a OTG controller since OMAP5 has
>> already got an EHCI host.
>>
>> Signed-off-by: George Cherian <george.cherian@ti.com>
>> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
>
> Can you take this patch for 3.13?

I've just applied it.

Thanks,
Benoit


-- 
Benoît Cousson
BayLibre
Embedded Linux Technology Lab
www.baylibre.com

Re: [PATCH v2 2/2] ARM: dts: omap5: Add dr_mode for dwc3

[Kishon Vijay Abraham I]

On Friday 18 October 2013 01:38 AM, Benoit Cousson wrote:
> Hi Kishon,
> 
> On 16/10/2013 15:17, Kishon Vijay Abraham I wrote:
>> Benoit,
>>
>> On Tuesday 15 October 2013 11:19 AM, Kishon Vijay Abraham I wrote:
>>> From: George Cherian <george.cherian@ti.com>
>>>
>>> Added dr_mode property in dwc3 and set its default mode to device.
>>> Currently dwc3 driver doesn't have support for OTG mode. So explicitly
>>> setting to peripheral even dwc3 is a OTG controller since OMAP5 has
>>> already got an EHCI host.
>>>
>>> Signed-off-by: George Cherian <george.cherian@ti.com>
>>> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
>>
>> Can you take this patch for 3.13?
> 
> I've just applied it.

Thanks :-)

-Kishon

> 
> Thanks,
> Benoit
> 
> 

Re: [PATCH 2/2] ARM: dts: omap5: Add dr_mode for dwc3

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 594 bytes --]

On Fri, Oct 11, 2013 at 05:46:12PM +0300, Roger Quadros wrote:
> Hi,
> 
> On 10/10/2013 01:49 PM, Kishon Vijay Abraham I wrote:
> > From: George Cherian <george.cherian@ti.com>
> > 
> > Added dr_mode property in dwc3 and set its default mode to device.
> 
> If there is a specific reason why this is not set to "otg", we need
> to explain it here.
> 
> AFAIK the port is meant to be used as OTG port.

we still don't have the workaround for dual role ports, I've been
working on it but still need to retest and make sure it's working fine
before merging upstream.

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH 2/2] ARM: dts: omap5: Add dr_mode for dwc3

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 732 bytes --]

On Wed, Apr 16, 2014 at 11:16:19AM -0500, Felipe Balbi wrote:
> On Fri, Oct 11, 2013 at 05:46:12PM +0300, Roger Quadros wrote:
> > Hi,
> > 
> > On 10/10/2013 01:49 PM, Kishon Vijay Abraham I wrote:
> > > From: George Cherian <george.cherian@ti.com>
> > > 
> > > Added dr_mode property in dwc3 and set its default mode to device.
> > 
> > If there is a specific reason why this is not set to "otg", we need
> > to explain it here.
> > 
> > AFAIK the port is meant to be used as OTG port.
> 
> we still don't have the workaround for dual role ports, I've been
> working on it but still need to retest and make sure it's working fine
> before merging upstream.

man, I went back in time. Nevermind :-)

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH 2/2] ARM: dts: omap5: Add dr_mode for dwc3

[Dmitry Lifshitz]

Hi Felipe, Roger

On 04/16/2014 07:16 PM, Felipe Balbi wrote:
> On Fri, Oct 11, 2013 at 05:46:12PM +0300, Roger Quadros wrote:
>> Hi,
>>
>> On 10/10/2013 01:49 PM, Kishon Vijay Abraham I wrote:
>>> From: George Cherian <george.cherian@ti.com>
>>>
>>> Added dr_mode property in dwc3 and set its default mode to device.
>>
>> If there is a specific reason why this is not set to "otg", we need
>> to explain it here.
>>
>> AFAIK the port is meant to be used as OTG port.
>
> we still don't have the workaround for dual role ports, I've been
> working on it but still need to retest and make sure it's working fine
> before merging upstream.
>


Does the OTG port suppose to work with OMAP5? I mean role switching 
mechanism?

I'm testing kernel v3.16 with OMAP5 based board (CM-T54).

If I set CONFIG_USB_DWC3_DUAL_ROLE, than nothing is going on when I plug 
some device/host cable into micro USB3.0 port (VBUS/ID detection with 
extcon events works fine).

CONFIG_USB_DWC3_HOST/CONFIG_USB_DWC3_GADGET bring port to appropriate 
mode and it works.

What is the purpose of setting dr_mode = "peripheral" in omap5.dtsi, 
since it is overridden by config options in dwc3_probe()?

Thank you in advance for the assistance,

Dmitry

Re: [PATCH 2/2] ARM: dts: omap5: Add dr_mode for dwc3

[Roger Quadros]

On 09/08/2014 02:34 PM, Dmitry Lifshitz wrote:
> Hi Felipe, Roger
> 
> On 04/16/2014 07:16 PM, Felipe Balbi wrote:
>> On Fri, Oct 11, 2013 at 05:46:12PM +0300, Roger Quadros wrote:
>>> Hi,
>>>
>>> On 10/10/2013 01:49 PM, Kishon Vijay Abraham I wrote:
>>>> From: George Cherian <george.cherian@ti.com>
>>>>
>>>> Added dr_mode property in dwc3 and set its default mode to device.
>>>
>>> If there is a specific reason why this is not set to "otg", we need
>>> to explain it here.
>>>
>>> AFAIK the port is meant to be used as OTG port.
>>
>> we still don't have the workaround for dual role ports, I've been
>> working on it but still need to retest and make sure it's working fine
>> before merging upstream.
>>
> 
> 
> Does the OTG port suppose to work with OMAP5? I mean role switching mechanism?
> 
> I'm testing kernel v3.16 with OMAP5 based board (CM-T54).
> 
> If I set CONFIG_USB_DWC3_DUAL_ROLE, than nothing is going on when I plug some device/host cable into micro USB3.0 port (VBUS/ID detection with extcon events works fine).
> 
> CONFIG_USB_DWC3_HOST/CONFIG_USB_DWC3_GADGET bring port to appropriate mode and it works.
> 
> What is the purpose of setting dr_mode = "peripheral" in omap5.dtsi, since it is overridden by config options in dwc3_probe()?

If dual role works it should be "otg" then. I'm not sure why it was set to peripheral. Maybe the role switching mechanism
was not in place earlier.

George any objections for "otg"?

cheers,
-roger

Re: [PATCH 2/2] ARM: dts: omap5: Add dr_mode for dwc3

[Dmitry Lifshitz]

Hi Roger,

Thank you for a quick reply. See, my reply below.

On 09/08/2014 02:39 PM, Roger Quadros wrote:
> On 09/08/2014 02:34 PM, Dmitry Lifshitz wrote:
>> Hi Felipe, Roger
>>
>> On 04/16/2014 07:16 PM, Felipe Balbi wrote:
>>> On Fri, Oct 11, 2013 at 05:46:12PM +0300, Roger Quadros wrote:
>>>> Hi,
>>>>
>>>> On 10/10/2013 01:49 PM, Kishon Vijay Abraham I wrote:
>>>>> From: George Cherian <george.cherian@ti.com>
>>>>>
>>>>> Added dr_mode property in dwc3 and set its default mode to device.
>>>>
>>>> If there is a specific reason why this is not set to "otg", we need
>>>> to explain it here.
>>>>
>>>> AFAIK the port is meant to be used as OTG port.
>>>
>>> we still don't have the workaround for dual role ports, I've been
>>> working on it but still need to retest and make sure it's working fine
>>> before merging upstream.
>>>
>>
>>
>> Does the OTG port suppose to work with OMAP5? I mean role switching mechanism?
>>
>> I'm testing kernel v3.16 with OMAP5 based board (CM-T54).
>>
>> If I set CONFIG_USB_DWC3_DUAL_ROLE, than nothing is going on when I plug some device/host cable into micro USB3.0 port (VBUS/ID detection with extcon events works fine).
>>
>> CONFIG_USB_DWC3_HOST/CONFIG_USB_DWC3_GADGET bring port to appropriate mode and it works.
>>
>> What is the purpose of setting dr_mode = "peripheral" in omap5.dtsi, since it is overridden by config options in dwc3_probe()?
>
> If dual role works it should be "otg" then. I'm not sure why it was set to peripheral. Maybe the role switching mechanism
> was not in place earlier.


This is what I have when setting dr_mode = "otg" (and compiling with 
CONFIG_USB_DWC3_DUAL_ROLE):

when load gadget driver and plugging host PC cable:

root@cm-debian:~# modprobe g_ether
using random self ethernet address
using random host ethernet address
usb0: HOST MAC fa:db:52:7f:95:c5
usb0: MAC be:75:8d:71:6d:02
using random self ethernet address
using random host ethernet address
g_ether gadget: Ethernet Gadget, version: Memorial Day 2008
g_ether gadget: g_ether ready
root@cm-debian:~# ------------[ cut here ]------------
WARNING: CPU: 0 PID: 65 at 
/home/lifshitz/workroot/git-repo/OMAP5/omap5-kernel/drivers/bus/omap_l3_noc.c:147 
l3_handle_target.isra.2+0x230/0x27c()
44000000.ocp:L3 Standard Error: MASTER UN IDENTIFIED TARGET OCMRAM 
(Read): At Address: 0x00000000 : Data Access in User mode during 
Functional access
Modules linked in: usb_f_eem g_ether usb_f_rndis libcomposite u_ether 
configfs rfcomm ecb btmrvl_sdio btmrvl bluetooth mwifiex_sdio mwifiex 
dwc3 ahci_platform libahci_platform libahci libata snd_soc_cm_t54 
ads7846 dwc3_omap extcon_palmas rtc_palmas extcon_class at24 
snd_soc_wm8731 snd_soc_omap_mcbsp
CPU: 0 PID: 65 Comm: irq/39-palmas Tainted: G        W 
3.16.0-cm-t54+ #99
[<c00156d0>] (unwind_backtrace) from [<c00124ac>] (show_stack+0x10/0x14)
[<c00124ac>] (show_stack) from [<c05e29dc>] (dump_stack+0x74/0x8c)
[<c05e29dc>] (dump_stack) from [<c0037dbc>] (warn_slowpath_common+0x70/0x88)
[<c0037dbc>] (warn_slowpath_common) from [<c0037e68>] 
(warn_slowpath_fmt+0x30/0x40)
[<c0037e68>] (warn_slowpath_fmt) from [<c02d88b8>] 
(l3_handle_target.isra.2+0x230/0x27c)
[<c02d88b8>] (l3_handle_target.isra.2) from [<c02d89b0>] 
(l3_interrupt_handler+0xac/0x13c)
[<c02d89b0>] (l3_interrupt_handler) from [<c007ea00>] 
(handle_irq_event_percpu+0x7c/0x230)
[<c007ea00>] (handle_irq_event_percpu) from [<c007ebf8>] 
(handle_irq_event+0x44/0x64)
[<c007ebf8>] (handle_irq_event) from [<c0081b78>] 
(handle_fasteoi_irq+0xa8/0x134)
[<c0081b78>] (handle_fasteoi_irq) from [<c007e398>] 
(generic_handle_irq+0x20/0x30)
[<c007e398>] (generic_handle_irq) from [<c000f4ac>] (handle_IRQ+0x40/0x90)
[<c000f4ac>] (handle_IRQ) from [<c0008620>] (gic_handle_irq+0x2c/0x60)
[<c0008620>] (gic_handle_irq) from [<c05eacc0>] (__irq_svc+0x40/0x50)
Exception stack(0xec939d80 to 0xec939dc8)
9d80: ecb729b0 20000013 00000000 00000001 ecb72800 eca1e000 00000000 
ec939e44
9da0: ec939ed0 20000013 ecb72818 ed005e14 ec939ec8 ec939dc8 bf015f54 
c05ea548
9dc0: 80000013 ffffffff
[<c05eacc0>] (__irq_svc) from [<c05ea548>] 
(_raw_spin_unlock_irqrestore+0x1c/0x20)
[<c05ea548>] (_raw_spin_unlock_irqrestore) from [<bf015f54>] 
(extcon_update_state+0x144/0x1c4 [extcon_class])
[<bf015f54>] (extcon_update_state [extcon_class]) from [<bf023288>] 
(palmas_vbus_irq_handler+0x64/0xa0 [extcon_palmas])
[<bf023288>] (palmas_vbus_irq_handler [extcon_palmas]) from [<c00815a8>] 
(handle_nested_irq+0xa0/0x10c)
[<c00815a8>] (handle_nested_irq) from [<c03ab85c>] 
(regmap_irq_thread+0x184/0x300)
[<c03ab85c>] (regmap_irq_thread) from [<c007f8b8>] (irq_thread_fn+0x1c/0x40)
[<c007f8b8>] (irq_thread_fn) from [<c007f6a4>] (irq_thread+0x120/0x15c)
[<c007f6a4>] (irq_thread) from [<c0056434>] (kthread+0xdc/0xf0)
[<c0056434>] (kthread) from [<c000eb98>] (ret_from_fork+0x14/0x3c)
---[ end trace 3b365a734f7f3202 ]---
palmas-usb 48070000.i2c:palmas@48:palmas_usb: USB cable is attached



when plugging storage device:

root@cm-debian:~# dmesg | tail -n20
...
omap-dwc3 4a020000.omap_dwc3: ID GND
palmas-usb 48070000.i2c:palmas@48:palmas_usb: USB-HOST cable is attached
palmas-usb 48070000.i2c:palmas@48:palmas_usb: USB cable is attached

and nothing is going on.

Once again, when compiling with predefined role 
(CONFIG_USB_DWC3_HOST/CONFIG_USB_DWC3_GADGET) the port is functional in 
both modes.

I'm wondering, if dwc3_probe() calls
dwc3_core_init_mode() -> dwc3_set_mode() than why it is not required in 
dwc3_omap_set_mailbox()?


>
> George any objections for "otg"?
>
> cheers,
> -roger
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>

Thanks,

Dmitry

Re: [PATCH 2/2] ARM: dts: omap5: Add dr_mode for dwc3

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 6025 bytes --]

Hi,

On Mon, Sep 08, 2014 at 03:32:37PM +0300, Dmitry Lifshitz wrote:
> Hi Roger,
> 
> Thank you for a quick reply. See, my reply below.
> 
> On 09/08/2014 02:39 PM, Roger Quadros wrote:
> >On 09/08/2014 02:34 PM, Dmitry Lifshitz wrote:
> >>Hi Felipe, Roger
> >>
> >>On 04/16/2014 07:16 PM, Felipe Balbi wrote:
> >>>On Fri, Oct 11, 2013 at 05:46:12PM +0300, Roger Quadros wrote:
> >>>>Hi,
> >>>>
> >>>>On 10/10/2013 01:49 PM, Kishon Vijay Abraham I wrote:
> >>>>>From: George Cherian <george.cherian@ti.com>
> >>>>>
> >>>>>Added dr_mode property in dwc3 and set its default mode to device.
> >>>>
> >>>>If there is a specific reason why this is not set to "otg", we need
> >>>>to explain it here.
> >>>>
> >>>>AFAIK the port is meant to be used as OTG port.
> >>>
> >>>we still don't have the workaround for dual role ports, I've been
> >>>working on it but still need to retest and make sure it's working fine
> >>>before merging upstream.
> >>>
> >>
> >>
> >>Does the OTG port suppose to work with OMAP5? I mean role switching mechanism?
> >>
> >>I'm testing kernel v3.16 with OMAP5 based board (CM-T54).
> >>
> >>If I set CONFIG_USB_DWC3_DUAL_ROLE, than nothing is going on when I plug some device/host cable into micro USB3.0 port (VBUS/ID detection with extcon events works fine).
> >>
> >>CONFIG_USB_DWC3_HOST/CONFIG_USB_DWC3_GADGET bring port to appropriate mode and it works.
> >>
> >>What is the purpose of setting dr_mode = "peripheral" in omap5.dtsi, since it is overridden by config options in dwc3_probe()?
> >
> >If dual role works it should be "otg" then. I'm not sure why it was set to peripheral. Maybe the role switching mechanism
> >was not in place earlier.
> 
> 
> This is what I have when setting dr_mode = "otg" (and compiling with
> CONFIG_USB_DWC3_DUAL_ROLE):
> 
> when load gadget driver and plugging host PC cable:
> 
> root@cm-debian:~# modprobe g_ether
> using random self ethernet address
> using random host ethernet address
> usb0: HOST MAC fa:db:52:7f:95:c5
> usb0: MAC be:75:8d:71:6d:02
> using random self ethernet address
> using random host ethernet address
> g_ether gadget: Ethernet Gadget, version: Memorial Day 2008
> g_ether gadget: g_ether ready
> root@cm-debian:~# ------------[ cut here ]------------
> WARNING: CPU: 0 PID: 65 at /home/lifshitz/workroot/git-repo/OMAP5/omap5-kernel/drivers/bus/omap_l3_noc.c:147
> l3_handle_target.isra.2+0x230/0x27c()
> 44000000.ocp:L3 Standard Error: MASTER UN IDENTIFIED TARGET OCMRAM (Read):
> At Address: 0x00000000 : Data Access in User mode during Functional access
> Modules linked in: usb_f_eem g_ether usb_f_rndis libcomposite u_ether
> configfs rfcomm ecb btmrvl_sdio btmrvl bluetooth mwifiex_sdio mwifiex dwc3
> ahci_platform libahci_platform libahci libata snd_soc_cm_t54 ads7846
> dwc3_omap extcon_palmas rtc_palmas extcon_class at24 snd_soc_wm8731
> snd_soc_omap_mcbsp
> CPU: 0 PID: 65 Comm: irq/39-palmas Tainted: G        W 3.16.0-cm-t54+ #99
> [<c00156d0>] (unwind_backtrace) from [<c00124ac>] (show_stack+0x10/0x14)
> [<c00124ac>] (show_stack) from [<c05e29dc>] (dump_stack+0x74/0x8c)
> [<c05e29dc>] (dump_stack) from [<c0037dbc>] (warn_slowpath_common+0x70/0x88)
> [<c0037dbc>] (warn_slowpath_common) from [<c0037e68>]
> (warn_slowpath_fmt+0x30/0x40)
> [<c0037e68>] (warn_slowpath_fmt) from [<c02d88b8>]
> (l3_handle_target.isra.2+0x230/0x27c)
> [<c02d88b8>] (l3_handle_target.isra.2) from [<c02d89b0>]
> (l3_interrupt_handler+0xac/0x13c)
> [<c02d89b0>] (l3_interrupt_handler) from [<c007ea00>]
> (handle_irq_event_percpu+0x7c/0x230)
> [<c007ea00>] (handle_irq_event_percpu) from [<c007ebf8>]
> (handle_irq_event+0x44/0x64)
> [<c007ebf8>] (handle_irq_event) from [<c0081b78>]
> (handle_fasteoi_irq+0xa8/0x134)
> [<c0081b78>] (handle_fasteoi_irq) from [<c007e398>]
> (generic_handle_irq+0x20/0x30)
> [<c007e398>] (generic_handle_irq) from [<c000f4ac>] (handle_IRQ+0x40/0x90)
> [<c000f4ac>] (handle_IRQ) from [<c0008620>] (gic_handle_irq+0x2c/0x60)
> [<c0008620>] (gic_handle_irq) from [<c05eacc0>] (__irq_svc+0x40/0x50)
> Exception stack(0xec939d80 to 0xec939dc8)
> 9d80: ecb729b0 20000013 00000000 00000001 ecb72800 eca1e000 00000000
> ec939e44
> 9da0: ec939ed0 20000013 ecb72818 ed005e14 ec939ec8 ec939dc8 bf015f54
> c05ea548
> 9dc0: 80000013 ffffffff
> [<c05eacc0>] (__irq_svc) from [<c05ea548>]
> (_raw_spin_unlock_irqrestore+0x1c/0x20)
> [<c05ea548>] (_raw_spin_unlock_irqrestore) from [<bf015f54>]
> (extcon_update_state+0x144/0x1c4 [extcon_class])
> [<bf015f54>] (extcon_update_state [extcon_class]) from [<bf023288>]
> (palmas_vbus_irq_handler+0x64/0xa0 [extcon_palmas])
> [<bf023288>] (palmas_vbus_irq_handler [extcon_palmas]) from [<c00815a8>]
> (handle_nested_irq+0xa0/0x10c)
> [<c00815a8>] (handle_nested_irq) from [<c03ab85c>]
> (regmap_irq_thread+0x184/0x300)
> [<c03ab85c>] (regmap_irq_thread) from [<c007f8b8>] (irq_thread_fn+0x1c/0x40)
> [<c007f8b8>] (irq_thread_fn) from [<c007f6a4>] (irq_thread+0x120/0x15c)
> [<c007f6a4>] (irq_thread) from [<c0056434>] (kthread+0xdc/0xf0)
> [<c0056434>] (kthread) from [<c000eb98>] (ret_from_fork+0x14/0x3c)
> ---[ end trace 3b365a734f7f3202 ]---
> palmas-usb 48070000.i2c:palmas@48:palmas_usb: USB cable is attached
> 
> 
> 
> when plugging storage device:
> 
> root@cm-debian:~# dmesg | tail -n20
> ...
> omap-dwc3 4a020000.omap_dwc3: ID GND
> palmas-usb 48070000.i2c:palmas@48:palmas_usb: USB-HOST cable is attached
> palmas-usb 48070000.i2c:palmas@48:palmas_usb: USB cable is attached
> 
> and nothing is going on.
> 
> Once again, when compiling with predefined role
> (CONFIG_USB_DWC3_HOST/CONFIG_USB_DWC3_GADGET) the port is functional in both
> modes.
> 
> I'm wondering, if dwc3_probe() calls
> dwc3_core_init_mode() -> dwc3_set_mode() than why it is not required in
> dwc3_omap_set_mailbox()?

no, it's not required there. that mailbox is basically just telling the
IP about VBUS levels and ID state. Nothing more.

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH 2/2] ARM: dts: omap5: Add dr_mode for dwc3

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 1358 bytes --]

Hi,

On Mon, Sep 08, 2014 at 02:34:33PM +0300, Dmitry Lifshitz wrote:
> Hi Felipe, Roger
> 
> On 04/16/2014 07:16 PM, Felipe Balbi wrote:
> >On Fri, Oct 11, 2013 at 05:46:12PM +0300, Roger Quadros wrote:
> >>Hi,
> >>
> >>On 10/10/2013 01:49 PM, Kishon Vijay Abraham I wrote:
> >>>From: George Cherian <george.cherian@ti.com>
> >>>
> >>>Added dr_mode property in dwc3 and set its default mode to device.
> >>
> >>If there is a specific reason why this is not set to "otg", we need
> >>to explain it here.
> >>
> >>AFAIK the port is meant to be used as OTG port.
> >
> >we still don't have the workaround for dual role ports, I've been
> >working on it but still need to retest and make sure it's working fine
> >before merging upstream.
> >
> 
> 
> Does the OTG port suppose to work with OMAP5? I mean role switching
> mechanism?
> 
> I'm testing kernel v3.16 with OMAP5 based board (CM-T54).
> 
> If I set CONFIG_USB_DWC3_DUAL_ROLE, than nothing is going on when I plug
> some device/host cable into micro USB3.0 port (VBUS/ID detection with extcon
> events works fine).

Dual role does not work. We allow the driver to the built with both Host
and Peripheral support because some platforms have more than one port
and building the driver with dual role allows us to make one port host
and one peripheral.

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH 2/2] ARM: dts: omap5: Add dr_mode for dwc3

[Dmitry Lifshitz]

Hi,

On 09/08/2014 04:24 PM, Felipe Balbi wrote:
> Hi,
>
> On Mon, Sep 08, 2014 at 02:34:33PM +0300, Dmitry Lifshitz wrote:
>> Hi Felipe, Roger
>>
>> On 04/16/2014 07:16 PM, Felipe Balbi wrote:
>>> On Fri, Oct 11, 2013 at 05:46:12PM +0300, Roger Quadros wrote:
>>>> Hi,
>>>>
>>>> On 10/10/2013 01:49 PM, Kishon Vijay Abraham I wrote:
>>>>> From: George Cherian <george.cherian@ti.com>
>>>>>
>>>>> Added dr_mode property in dwc3 and set its default mode to device.
>>>>
>>>> If there is a specific reason why this is not set to "otg", we need
>>>> to explain it here.
>>>>
>>>> AFAIK the port is meant to be used as OTG port.
>>>
>>> we still don't have the workaround for dual role ports, I've been
>>> working on it but still need to retest and make sure it's working fine
>>> before merging upstream.
>>>
>>
>>
>> Does the OTG port suppose to work with OMAP5? I mean role switching
>> mechanism?
>>
>> I'm testing kernel v3.16 with OMAP5 based board (CM-T54).
>>
>> If I set CONFIG_USB_DWC3_DUAL_ROLE, than nothing is going on when I plug
>> some device/host cable into micro USB3.0 port (VBUS/ID detection with extcon
>> events works fine).
>
> Dual role does not work. We allow the driver to the built with both Host
> and Peripheral support because some platforms have more than one port
> and building the driver with dual role allows us to make one port host
> and one peripheral.
>

Please, can you provide some detail about platforms with several ports.
How do that ports are connected to DWC3?


Thanks,

Dmitry

Re: [PATCH 2/2] ARM: dts: omap5: Add dr_mode for dwc3

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 1730 bytes --]

On Wed, Sep 10, 2014 at 03:03:33PM +0300, Dmitry Lifshitz wrote:
> Hi,
> 
> On 09/08/2014 04:24 PM, Felipe Balbi wrote:
> >Hi,
> >
> >On Mon, Sep 08, 2014 at 02:34:33PM +0300, Dmitry Lifshitz wrote:
> >>Hi Felipe, Roger
> >>
> >>On 04/16/2014 07:16 PM, Felipe Balbi wrote:
> >>>On Fri, Oct 11, 2013 at 05:46:12PM +0300, Roger Quadros wrote:
> >>>>Hi,
> >>>>
> >>>>On 10/10/2013 01:49 PM, Kishon Vijay Abraham I wrote:
> >>>>>From: George Cherian <george.cherian@ti.com>
> >>>>>
> >>>>>Added dr_mode property in dwc3 and set its default mode to device.
> >>>>
> >>>>If there is a specific reason why this is not set to "otg", we need
> >>>>to explain it here.
> >>>>
> >>>>AFAIK the port is meant to be used as OTG port.
> >>>
> >>>we still don't have the workaround for dual role ports, I've been
> >>>working on it but still need to retest and make sure it's working fine
> >>>before merging upstream.
> >>>
> >>
> >>
> >>Does the OTG port suppose to work with OMAP5? I mean role switching
> >>mechanism?
> >>
> >>I'm testing kernel v3.16 with OMAP5 based board (CM-T54).
> >>
> >>If I set CONFIG_USB_DWC3_DUAL_ROLE, than nothing is going on when I plug
> >>some device/host cable into micro USB3.0 port (VBUS/ID detection with extcon
> >>events works fine).
> >
> >Dual role does not work. We allow the driver to the built with both Host
> >and Peripheral support because some platforms have more than one port
> >and building the driver with dual role allows us to make one port host
> >and one peripheral.
> >
> 
> Please, can you provide some detail about platforms with several ports.
> How do that ports are connected to DWC3?

you have several dwc3 instances.

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH 1/2] ARM: dts: omap5-uevm: remove always_on, boot_on from smps10_out1

[Nishanth Menon]

On 16:19-20131010, Kishon Vijay Abraham I wrote:
> smps10 should be enabled only in the case of host mode. So stop
> doing always_on, boot_on from smps10_out1. The driver will enable it in host
> mode.
> 
> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
> ---
>  arch/arm/boot/dts/omap5-uevm.dts |    2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
> index d784b3a..e06a04a 100644
> --- a/arch/arm/boot/dts/omap5-uevm.dts
> +++ b/arch/arm/boot/dts/omap5-uevm.dts
> @@ -334,8 +334,6 @@
>  					regulator-name = "smps10_out1";
>  					regulator-min-microvolt = <5000000>;
>  					regulator-max-microvolt = <5000000>;
> -					regulator-always-on;
> -					regulator-boot-on;
>  				};
>  
>  				ldo1_reg: ldo1 {
> -- 
Always good to get rid of regulator-always-on. Thanks for it.

regulator-boot-on indicates that PMIC enables it by default as part of
OTP or some internal behavior -> Looking at the measurements done on
uEVM and OTP information -> regulator-boot-on should be kept here.

Hence Nak.
-- 
Regards,
Nishanth Menon

Re: [PATCH 1/2] ARM: dts: omap5-uevm: remove always_on, boot_on from smps10_out1

[Kishon Vijay Abraham I]

On Thursday 10 October 2013 07:49 PM, Nishanth Menon wrote:
> On 16:19-20131010, Kishon Vijay Abraham I wrote:
>> smps10 should be enabled only in the case of host mode. So stop
>> doing always_on, boot_on from smps10_out1. The driver will enable it in host
>> mode.
>>
>> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
>> ---
>>  arch/arm/boot/dts/omap5-uevm.dts |    2 --
>>  1 file changed, 2 deletions(-)
>>
>> diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
>> index d784b3a..e06a04a 100644
>> --- a/arch/arm/boot/dts/omap5-uevm.dts
>> +++ b/arch/arm/boot/dts/omap5-uevm.dts
>> @@ -334,8 +334,6 @@
>>  					regulator-name = "smps10_out1";
>>  					regulator-min-microvolt = <5000000>;
>>  					regulator-max-microvolt = <5000000>;
>> -					regulator-always-on;
>> -					regulator-boot-on;
>>  				};
>>  
>>  				ldo1_reg: ldo1 {
>> -- 
> Always good to get rid of regulator-always-on. Thanks for it.
> 
> regulator-boot-on indicates that PMIC enables it by default as part of
> OTP or some internal behavior -> Looking at the measurements done on
> uEVM and OTP information -> regulator-boot-on should be kept here.

No. Actually I don’t want PMIC to enable it by default. I want the palmas-usb
driver to handle it.
Enabling it by default makes palmas-usb to detect VBUS interrupt. This should
ideally be detected only when you connect a host cable.
Btw I didn't exactly get why you want regulator-boot-on should be kept here.

Thanks
Kishon

Re: [PATCH 1/2] ARM: dts: omap5-uevm: remove always_on, boot_on from smps10_out1

[Nishanth Menon]

On Fri, Oct 11, 2013 at 1:13 AM, Kishon Vijay Abraham I <kishon@ti.com> wrote:
>
>> regulator-boot-on indicates that PMIC enables it by default as part of
>> OTP or some internal behavior -> Looking at the measurements done on
>> uEVM and OTP information -> regulator-boot-on should be kept here.
>
> No. Actually I don’t want PMIC to enable it by default. I want the palmas-usb
> driver to handle it.
> Enabling it by default makes palmas-usb to detect VBUS interrupt. This should
> ideally be detected only when you connect a host cable.
> Btw I didn't exactly get why you want regulator-boot-on should be kept here.

binding description states:
- regulator-boot-on: bootloader/firmware enabled regulator
Further info: include/linux/regulator/machine.h
* @boot_on: Set if the regulator is enabled when the system is initially
*           started.  If the regulator is not enabled by the hardware or
*           bootloader then it will be enabled when the constraints are
*           applied.

What that means is that it is enabled by firmware/bootloader (in our
case One Time Program {OTP} inside Palmas) when the system switches on
even before the kernel starts. and we know SMPS10 is autoenabled by
Palmas OTP configuration even before first instruction in A15
executes.

I think you misunderstand this to mean that you'd like the regulator
to be *switched on* automatically at kernel boot by regulator
framework - there is no reasoning why we'd want such a binding since
we'd expect drivers to do their job of requesting and enabling
regulators on need..

Hope this helps. Let me know if I misunderstood something here.

Regards,
Nishanth Menon

Re: [PATCH 1/2] ARM: dts: omap5-uevm: remove always_on, boot_on from smps10_out1

[Kishon Vijay Abraham I]

Hi,

On Friday 11 October 2013 12:00 PM, Nishanth Menon wrote:
> On Fri, Oct 11, 2013 at 1:13 AM, Kishon Vijay Abraham I <kishon@ti.com> wrote:
>>
>>> regulator-boot-on indicates that PMIC enables it by default as part of
>>> OTP or some internal behavior -> Looking at the measurements done on
>>> uEVM and OTP information -> regulator-boot-on should be kept here.
>>
>> No. Actually I don’t want PMIC to enable it by default. I want the palmas-usb
>> driver to handle it.
>> Enabling it by default makes palmas-usb to detect VBUS interrupt. This should
>> ideally be detected only when you connect a host cable.
>> Btw I didn't exactly get why you want regulator-boot-on should be kept here.
> 
> binding description states:
> - regulator-boot-on: bootloader/firmware enabled regulator
> Further info: include/linux/regulator/machine.h
> * @boot_on: Set if the regulator is enabled when the system is initially
> *           started.  If the regulator is not enabled by the hardware or
> *           bootloader then it will be enabled when the constraints are
> *           applied.
> 
> What that means is that it is enabled by firmware/bootloader (in our
> case One Time Program {OTP} inside Palmas) when the system switches on
> even before the kernel starts. and we know SMPS10 is autoenabled by
> Palmas OTP configuration even before first instruction in A15
> executes.

Not sure about that. Please note SMPS10 has two outputs OUT1 and OUT2 and I
tend to think that it might be OUT2 that's getting enabled by the OTP.
> 
> I think you misunderstand this to mean that you'd like the regulator
> to be *switched on* automatically at kernel boot by regulator
> framework - there is no reasoning why we'd want such a binding since
> we'd expect drivers to do their job of requesting and enabling
> regulators on need..

The comment you just quoted tells it enables the regulator if its not enabled
by hardware. "If the regulator is not enabled by the hardware or bootloader
then it will be enabled when the constraints are applied." At-least that's what
I understood from that comment.

Also from our experiments it doesn't look like SMPS10_OUT1 is enabled by the
OTP and it gets enabled when we have *regulator-boot-on* constraints.

Thanks
Kishon

Re: [PATCH 1/2] ARM: dts: omap5-uevm: remove always_on, boot_on from smps10_out1

[Kishon Vijay Abraham I]

On Friday 11 October 2013 12:23 PM, Kishon Vijay Abraham I wrote:
> Hi,
> 
> On Friday 11 October 2013 12:00 PM, Nishanth Menon wrote:
>> On Fri, Oct 11, 2013 at 1:13 AM, Kishon Vijay Abraham I <kishon@ti.com> wrote:
>>>
>>>> regulator-boot-on indicates that PMIC enables it by default as part of
>>>> OTP or some internal behavior -> Looking at the measurements done on
>>>> uEVM and OTP information -> regulator-boot-on should be kept here.
>>>
>>> No. Actually I don’t want PMIC to enable it by default. I want the palmas-usb
>>> driver to handle it.
>>> Enabling it by default makes palmas-usb to detect VBUS interrupt. This should
>>> ideally be detected only when you connect a host cable.
>>> Btw I didn't exactly get why you want regulator-boot-on should be kept here.
>>
>> binding description states:
>> - regulator-boot-on: bootloader/firmware enabled regulator
>> Further info: include/linux/regulator/machine.h
>> * @boot_on: Set if the regulator is enabled when the system is initially
>> *           started.  If the regulator is not enabled by the hardware or
>> *           bootloader then it will be enabled when the constraints are
>> *           applied.
>>
>> What that means is that it is enabled by firmware/bootloader (in our
>> case One Time Program {OTP} inside Palmas) when the system switches on
>> even before the kernel starts. and we know SMPS10 is autoenabled by
>> Palmas OTP configuration even before first instruction in A15
>> executes.
> 
> Not sure about that. Please note SMPS10 has two outputs OUT1 and OUT2 and I
> tend to think that it might be OUT2 that's getting enabled by the OTP.
>>
>> I think you misunderstand this to mean that you'd like the regulator
>> to be *switched on* automatically at kernel boot by regulator
>> framework - there is no reasoning why we'd want such a binding since
>> we'd expect drivers to do their job of requesting and enabling
>> regulators on need..
> 
> The comment you just quoted tells it enables the regulator if its not enabled
> by hardware. "If the regulator is not enabled by the hardware or bootloader
> then it will be enabled when the constraints are applied." At-least that's what
> I understood from that comment.
> 
> Also from our experiments it doesn't look like SMPS10_OUT1 is enabled by the
> OTP and it gets enabled when we have *regulator-boot-on* constraints.

btw.. I think this is the code in regulator fw that's responsible for enabling..

	/* If the constraints say the regulator should be on at this point
	 * and we have control then make sure it is enabled.
	 */
	if ((rdev->constraints->always_on || rdev->constraints->boot_on) &&
	    ops->enable) {
		ret = ops->enable(rdev);
		if (ret < 0) {
			rdev_err(rdev, "failed to enable\n");
			goto out;
		}
	}

Thanks
Kishon

Re: [PATCH 1/2] ARM: dts: omap5-uevm: remove always_on, boot_on from smps10_out1

[Nishanth Menon]

On Fri, Oct 11, 2013 at 1:54 AM, Kishon Vijay Abraham I <kishon@ti.com> wrote:
> On Friday 11 October 2013 12:23 PM, Kishon Vijay Abraham I wrote:
>> Hi,
>>
>> On Friday 11 October 2013 12:00 PM, Nishanth Menon wrote:
>>> On Fri, Oct 11, 2013 at 1:13 AM, Kishon Vijay Abraham I <kishon@ti.com> wrote:
>>>>
>>>>> regulator-boot-on indicates that PMIC enables it by default as part of
>>>>> OTP or some internal behavior -> Looking at the measurements done on
>>>>> uEVM and OTP information -> regulator-boot-on should be kept here.
>>>>
>>>> No. Actually I don’t want PMIC to enable it by default. I want the palmas-usb
>>>> driver to handle it.
>>>> Enabling it by default makes palmas-usb to detect VBUS interrupt. This should
>>>> ideally be detected only when you connect a host cable.
>>>> Btw I didn't exactly get why you want regulator-boot-on should be kept here.
>>>
>>> binding description states:
>>> - regulator-boot-on: bootloader/firmware enabled regulator
>>> Further info: include/linux/regulator/machine.h
>>> * @boot_on: Set if the regulator is enabled when the system is initially
>>> *           started.  If the regulator is not enabled by the hardware or
>>> *           bootloader then it will be enabled when the constraints are
>>> *           applied.
>>>
>>> What that means is that it is enabled by firmware/bootloader (in our
>>> case One Time Program {OTP} inside Palmas) when the system switches on
>>> even before the kernel starts. and we know SMPS10 is autoenabled by
>>> Palmas OTP configuration even before first instruction in A15
>>> executes.
>>
>> Not sure about that. Please note SMPS10 has two outputs OUT1 and OUT2 and I
>> tend to think that it might be OUT2 that's getting enabled by the OTP.
>>>
>>> I think you misunderstand this to mean that you'd like the regulator
>>> to be *switched on* automatically at kernel boot by regulator
>>> framework - there is no reasoning why we'd want such a binding since
>>> we'd expect drivers to do their job of requesting and enabling
>>> regulators on need..
>>
>> The comment you just quoted tells it enables the regulator if its not enabled
>> by hardware. "If the regulator is not enabled by the hardware or bootloader
>> then it will be enabled when the constraints are applied." At-least that's what
>> I understood from that comment.
>>
>> Also from our experiments it doesn't look like SMPS10_OUT1 is enabled by the
>> OTP and it gets enabled when we have *regulator-boot-on* constraints.
>
> btw.. I think this is the code in regulator fw that's responsible for enabling..
>
>         /* If the constraints say the regulator should be on at this point
>          * and we have control then make sure it is enabled.
>          */
>         if ((rdev->constraints->always_on || rdev->constraints->boot_on) &&
>             ops->enable) {
>                 ret = ops->enable(rdev);
>                 if (ret < 0) {
>                         rdev_err(rdev, "failed to enable\n");
>                         goto out;
>                 }
>         }

Drat, you are right, I did not really dig deep. thanks for correcting
my understanding here.

I propose the following change in binding as it seems completely
misleading to me.

diff --git a/Documentation/devicetree/bindings/regulator/regulator.txt
b/Documentation/devicetree/bindings/regulator/regulator.txt
index 2bd8f09..d999f096 100644
--- a/Documentation/devicetree/bindings/regulator/regulator.txt
+++ b/Documentation/devicetree/bindings/regulator/regulator.txt
@@ -8,7 +8,9 @@ Optional properties:
 - regulator-min-microamp: smallest current consumers may set
 - regulator-max-microamp: largest current consumers may set
 - regulator-always-on: boolean, regulator should never be disabled
-- regulator-boot-on: bootloader/firmware enabled regulator
+- regulator-boot-on: regulator is enabled when the system is initially started.
+  If the regulator is not enabled by the hardware or bootloader then it will be
+  enabled when the constraints are applied.
 - regulator-allow-bypass: allow the regulator to go into bypass mode
 - <name>-supply: phandle to the parent supply/regulator node
 - regulator-ramp-delay: ramp delay for regulator(in uV/uS)

Re: [PATCH 1/2] ARM: dts: omap5-uevm: remove always_on, boot_on from smps10_out1

[Kishon Vijay Abraham I]

Benoit,

On Thursday 10 October 2013 04:19 PM, Kishon Vijay Abraham I wrote:
> smps10 should be enabled only in the case of host mode. So stop
> doing always_on, boot_on from smps10_out1. The driver will enable it in host
> mode.

Can you take this patch too?

Thanks
Kishon
> 
> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
> ---
>  arch/arm/boot/dts/omap5-uevm.dts |    2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
> index d784b3a..e06a04a 100644
> --- a/arch/arm/boot/dts/omap5-uevm.dts
> +++ b/arch/arm/boot/dts/omap5-uevm.dts
> @@ -334,8 +334,6 @@
>  					regulator-name = "smps10_out1";
>  					regulator-min-microvolt = <5000000>;
>  					regulator-max-microvolt = <5000000>;
> -					regulator-always-on;
> -					regulator-boot-on;
>  				};
>  
>  				ldo1_reg: ldo1 {
> 

Re: [PATCH 1/2] ARM: dts: omap5-uevm: remove always_on, boot_on from smps10_out1

[Nishanth Menon]

On 10/16/2013 08:17 AM, Kishon Vijay Abraham I wrote:
> Benoit,
> 
> On Thursday 10 October 2013 04:19 PM, Kishon Vijay Abraham I wrote:
>> smps10 should be enabled only in the case of host mode. So stop
>> doing always_on, boot_on from smps10_out1. The driver will enable it in host
>> mode.
> 
> Can you take this patch too?

Acked-by: Nishanth Menon <nm@ti.com>
> 
> Thanks
> Kishon
>>
>> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
>> ---
>>  arch/arm/boot/dts/omap5-uevm.dts |    2 --
>>  1 file changed, 2 deletions(-)
>>
>> diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
>> index d784b3a..e06a04a 100644
>> --- a/arch/arm/boot/dts/omap5-uevm.dts
>> +++ b/arch/arm/boot/dts/omap5-uevm.dts
>> @@ -334,8 +334,6 @@
>>  					regulator-name = "smps10_out1";
>>  					regulator-min-microvolt = <5000000>;
>>  					regulator-max-microvolt = <5000000>;
>> -					regulator-always-on;
>> -					regulator-boot-on;
>>  				};
>>  
>>  				ldo1_reg: ldo1 {
>>
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 


-- 
Regards,
Nishanth Menon

Re: [PATCH 1/2] ARM: dts: omap5-uevm: remove always_on, boot_on from smps10_out1

[Benoit Cousson]

Hi Kishon,

On 16/10/2013 15:27, Nishanth Menon wrote:
> On 10/16/2013 08:17 AM, Kishon Vijay Abraham I wrote:
>> Benoit,
>>
>> On Thursday 10 October 2013 04:19 PM, Kishon Vijay Abraham I wrote:
>>> smps10 should be enabled only in the case of host mode. So stop
>>> doing always_on, boot_on from smps10_out1. The driver will enable it in host
>>> mode.
>>
>> Can you take this patch too?
>
> Acked-by: Nishanth Menon <nm@ti.com>

I've just applied it.

Thanks,
Benoit


-- 
Benoît Cousson
BayLibre
Embedded Linux Technology Lab
www.baylibre.com

Re: [PATCH 1/2] ARM: dts: omap5-uevm: remove always_on, boot_on from smps10_out1

[Kishon Vijay Abraham I]

On Friday 18 October 2013 01:39 AM, Benoit Cousson wrote:
> Hi Kishon,
> 
> On 16/10/2013 15:27, Nishanth Menon wrote:
>> On 10/16/2013 08:17 AM, Kishon Vijay Abraham I wrote:
>>> Benoit,
>>>
>>> On Thursday 10 October 2013 04:19 PM, Kishon Vijay Abraham I wrote:
>>>> smps10 should be enabled only in the case of host mode. So stop
>>>> doing always_on, boot_on from smps10_out1. The driver will enable it in host
>>>> mode.
>>>
>>> Can you take this patch too?
>>
>> Acked-by: Nishanth Menon <nm@ti.com>
> 
> I've just applied it.

Thanks :-)

-Kishon
> 
> Thanks,
> Benoit
> 
>