[PATCH] arm: dts: AM43x: Add usb_otg_hs node

[George Cherian]

Adds device node for HS USB Host module for AM437x

Signed-off-by: George Cherian 
---
 This patch is on top of 
 git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git 
for_3.11/dts

 arch/arm/boot/dts/am4372.dtsi | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index ddc1df7..e4f5eb8 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -64,5 +64,24 @@
compatible = 
"ti,am4372-counter32k","ti,omap-counter32k";
reg = <0x44e86000 0x40>;
};
+
+   usb_otg_hs1: am4372_dwc3@4838 {
+   compatible = "ti,am437x-dwc3";
+   reg = <0x4838 0x1ff>;
+   interrupts = ;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   utmi-mode = <1>;
+   ranges;
+
+   dwc3@4839 {
+   compatible = "synopsys,dwc3";
+   reg = <0x4839 0xcfff>;
+   interrupts = ;
+   tx-fifo-resize;
+   };
+
+   };
+
};
 };
-- 
1.8.1.4

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

Re: [PATCH v9 1/8] drivers: phy: add generic PHY framework

[Kishon Vijay Abraham I]

On Friday 28 June 2013 08:57 AM, Jingoo Han wrote:

On Wed, 26 Jun 2013 17:17:29 +0530, Kishon Vijay Abraham Iwrote:

The PHY framework provides a set of APIs for the PHY drivers to
create/destroy a PHY and APIs for the PHY users to obtain a reference to the
PHY with or without using phandle. For dt-boot, the PHY drivers should
also register *PHY provider* with the framework.

PHY drivers should create the PHY by passing id and ops like init, exit,
power_on and power_off. This framework is also pm runtime enabled.

The documentation for the generic PHY framework is added in
Documentation/phy.txt and the documentation for dt binding can be found at
Documentation/devicetree/bindings/phy/phy-bindings.txt

Signed-off-by: Kishon Vijay Abraham I 
Tested-by: Sylwester Nawrocki 


Tested-by: Jingoo Han 

It looks great to me!

I tested this General PHY framework with Exynos5250 eDP.
It works properly.


Thanks for testing this :-)


I will share the patch 'Generic PHY driver for the Exynos SoC DP PHY', soon.
Thanks.


Cool.

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

[PATCH] ARM: dts: remove previously generated .dtb files on clean

[Lokesh Vutla]

*.dtb used to be generated in the *arch/arm/boot* directory
which is different from where it is generated now.
Current rules delete the previously generated files only for
*make dtbs*.
Let distclean delete all the generated dtb files.

Signed-off-by: Lokesh Vutla 
Signed-off-by: Nishanth Menon 
---
 arch/arm/boot/dts/Makefile |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index f0895c5..d293167 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -219,4 +219,4 @@ endif
 dtbs: $(addprefix $(obj)/, $(dtb-y))
$(Q)rm -f $(obj)/../*.dtb
 
-clean-files := *.dtb
+clean-files := *.dtb ../*.dtb
-- 
1.7.9.5

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

Re: [PATCH v9 1/8] drivers: phy: add generic PHY framework

[Jingoo Han]

On Wed, 26 Jun 2013 17:17:29 +0530, Kishon Vijay Abraham Iwrote:
> The PHY framework provides a set of APIs for the PHY drivers to
> create/destroy a PHY and APIs for the PHY users to obtain a reference to the
> PHY with or without using phandle. For dt-boot, the PHY drivers should
> also register *PHY provider* with the framework.
>
> PHY drivers should create the PHY by passing id and ops like init, exit,
> power_on and power_off. This framework is also pm runtime enabled.
>
> The documentation for the generic PHY framework is added in
> Documentation/phy.txt and the documentation for dt binding can be found at
> Documentation/devicetree/bindings/phy/phy-bindings.txt
>
> Signed-off-by: Kishon Vijay Abraham I 
> Tested-by: Sylwester Nawrocki 

Tested-by: Jingoo Han 

It looks great to me!

I tested this General PHY framework with Exynos5250 eDP.
It works properly.
I will share the patch 'Generic PHY driver for the Exynos SoC DP PHY', soon.
Thanks.

Best regards,
Jingoo Han

> ---
>  .../devicetree/bindings/phy/phy-bindings.txt   |   66 +++
>  Documentation/phy.txt  |  129 +
>  MAINTAINERS|7 +
>  drivers/Kconfig|2 +
>  drivers/Makefile   |2 +
>  drivers/phy/Kconfig|   13 +
>  drivers/phy/Makefile   |5 +
>  drivers/phy/phy-core.c |  544 
> 
>  include/linux/phy/phy.h|  344 +
>  9 files changed, 1112 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/phy/phy-bindings.txt
>  create mode 100644 Documentation/phy.txt
>  create mode 100644 drivers/phy/Kconfig
>  create mode 100644 drivers/phy/Makefile
>  create mode 100644 drivers/phy/phy-core.c
>  create mode 100644 include/linux/phy/phy.h

--
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: omap4 ehci sporadic resume issue

[Michael Trimarchi]

Hi

On Thu, Jun 27, 2013 at 11:07:11PM +0300, Ruslan Bilovol wrote:
> On Thu, Jun 27, 2013 at 10:24 PM, Michael Trimarchi
>  wrote:
> > Hi
> >
> > On Thu, Jun 27, 2013 at 09:59:35PM +0300, Ruslan Bilovol wrote:
> >> Hello guys,
> >>
> >> On Thu, Jun 27, 2013 at 8:56 PM, Michael Trimarchi
> >>  wrote:
> >> > Hi Roger
> >> >
> >> > On Thu, Jun 27, 2013 at 05:49:41PM +0300, Roger Quadros wrote:
> >> >> +Ruslan
> >> >>
> >> >> On 06/27/2013 05:17 PM, Michael Trimarchi wrote:
> >> >> > Hi Roger
> >> >> >
> >> >> > On Thu, Jun 27, 2013 at 04:59:38PM +0300, Roger Quadros wrote:
> >> >> >> Hi Michael,
> >> >> >>
> >> >> >> On 06/27/2013 02:51 PM, Michael Trimarchi wrote:
> >> >> >>> Hi
> >> >> >>>
> >> >> >>> I'm working on omap4460 with two ulpi connected to (SMSC3320 -> HUB 
> >> >> >>> SMSC2514) or (TUSB1210 -> HUB SMSC2514).
> >> >> >>> The problem only happen when both port are used and after few 
> >> >> >>> suspend resume are triggered.
> >> >> >>> If I use just one port there is no issue on suspend resume. I 
> >> >> >>> already covered all TI
> >> >> >>> errata that I know and I'm working on TI kernel.
> >> >> >>>
> >> >> >>> The problem is here
> >> >> >>>
> >> >> >>> [   77.701934] ehci-omap ehci-omap.0: irq status a004 Async Recl PCD
> >> >> >>>
> >> >> >>> Both ports change status from 001005 to 001009 (you have a log just 
> >> >> >>> after).
> >> >> >>> So from host point of view both hub connected are not working in HS 
> >> >> >>> mode.
> >> >> >>> After that the omap ehci has gone because the bus can not work in 
> >> >> >>> FS and LS and I can not recover from here.
> >> >> >>> Status of transceivers are dumped and they are ok after resume.
> >> >> >>>
> >> >> >>> Do you have any suggestion?
> >> >> >>
> >> >> >> I'm not very sure but both ports suddenly changing state like that 
> >> >> >> look like
> >> >> >> a hardware issue. Also, it is strange that you can reproduce it only 
> >> >> >> when two
> >> >> >> ports are simultaneously in use. Unfortunately, I can't match your 
> >> >> >> setup with 2 ULPI
> >> >> >
> >> >> > Yes I know that TI doesn't have any setup like that.
> >> >> >
> >> >> >> ports.
> >> >> >>
> >> >> >> I have a OMAP5 uEVM that uses 2 ports but it won't be identical to 
> >> >> >> your setup as
> >> >> >> they are on HSIC and not ULPI.
> >> >> >>
> >> >> >> Did you try errata i693?
> >> >> >
> >> >> > Yes I have it. It's not clear if I need to wait after
> >> >> > ehci_writel(ehci, temp | PORT_SUSPEND, status_reg);
> >> >> > polling the suspendM of the SMSC or the suspend status of the PORT or 
> >> >> > I can
> >> >> > switch just after this instruction. Because TI kernel use an msleep 
> >> >> > of 4 mseconds and then switch. It could be a timing issue on how 
> >> >> > errata is implemented when I have two ports? How this internal count 
> >> >> > works?
> >> >>
> >> >>
> >> >> The OMAP EHCI controller transparently sets the suspendM bit of the PHY 
> >> >> when you
> >> >> set the PORT_SUSPEND feature on the EHCI port. So you don't need to 
> >> >> poll for anything.
> >> >>
> >> >
> >> > A delay is necessary. If we apply the errata to the port before a delay 
> >> > the errata
> >> > doesn't work.
> >> >
> >> > /* Use internal 60Mhz clock ULPIBx */
> >> > temp_reg = omap_readl(L3INIT_HSUSBHOST_CLKCTRL);
> >> > temp_reg |= 1 << (8 + port);
> >> > temp_reg &= ~(1 << (24 + port));
> >> > omap_writel(temp_reg, L3INIT_HSUSBHOST_CLKCTRL);
> >> >
> >> > /* Wait 2ms to have transceiver transaction */
> >> > mdelay(2);
> >> >
> >> > /* Use external clock ULPIBx */
> >> > temp_reg &= ~(1 << (8 + port));
> >> > temp_reg |= 1 << (24 + port);
> >> > omap_writel(temp_reg, L3INIT_HSUSBHOST_CLKCTRL);
> >> >
> >> > Now it's not clear to me what happen if I apply this clock too early 
> >> > (transeceiver still
> >> > driver the clock) or too late. Any clue?
> >>
> >> We need to wait 3ms for entire USB bus to go into suspend after
> >> setting the PORT_SUSPEND bit. During this time, internal OMAP EHCI logic
> >> will communicate with PHY so it is not safe to switch the clocks to
> >> internal source.
> >> That's why with 2ms delay it fails. 4ms delay (3ms + 1ms for safety)
> >> is enough here
> >> and is successfully used last few years for production devices.
> >
> > Well this mdelay is the switch of the clock and not the delay after
> > PORT_SUSPEND. So after writing PORT_SUSPEND I need to wait
> > 4ms and then in 2ms you have a lot of clock to reach the 18 count. Correct?
> 
> Yes, sorry for confusing :)
> Moreover, 2ms is more than enough, errata document says about 1ms delay
> (and probably may be decreased up to few useconds)
> 
> >
> > Anyway I understand, but why both hub connected to the smsc3320 move from
> > HS to FS? So it's not important if there is a drift of delay but it must
> > be >= 4ms. Correct?
> >
> > The code works if I just use one port or remove one hub ;)
> >
> > Now the code is like this:
> >
> > temp &= ~(PORT_WKCONN_E | PORT_RWC_BITS);
> > temp |= PORT_WKDIS

Re: [PATCH] Documentation: dt: bindings: TI WiLink modules

[Nishanth Menon]

On 06/27/2013 02:46 PM, Luciano Coelho wrote:

On Thu, 2013-06-27 at 14:12 -0500, Nishanth Menon wrote:

[...]

Indexes to another entity is always a maintenance burden in the longer
run and needs judicious control. If it is possible to avoid it by
selecting the right parameters, I am a hard advocate for the same.


I tend to agree.  But you need a balance.  In theory you're right.  But
I think if you take the real world example, it is over-engineering.

Anyway, if you *really* think this needs to be changed, I think we're in
a deadlock here and I'd like to hear other people's opinions.  I don't
mind making the change, but I'm still not convinced it is worth it,
since it just adds complexity.

And hey, this is too much bikeshedding for such a small detail.

Lol :)

Alrite, if no one else is complaining, I am not going to block it either.

--
Regards,
Nishanth Menon
--
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: omap4 ehci sporadic resume issue

[Ruslan Bilovol]

On Thu, Jun 27, 2013 at 10:24 PM, Michael Trimarchi
 wrote:
> Hi
>
> On Thu, Jun 27, 2013 at 09:59:35PM +0300, Ruslan Bilovol wrote:
>> Hello guys,
>>
>> On Thu, Jun 27, 2013 at 8:56 PM, Michael Trimarchi
>>  wrote:
>> > Hi Roger
>> >
>> > On Thu, Jun 27, 2013 at 05:49:41PM +0300, Roger Quadros wrote:
>> >> +Ruslan
>> >>
>> >> On 06/27/2013 05:17 PM, Michael Trimarchi wrote:
>> >> > Hi Roger
>> >> >
>> >> > On Thu, Jun 27, 2013 at 04:59:38PM +0300, Roger Quadros wrote:
>> >> >> Hi Michael,
>> >> >>
>> >> >> On 06/27/2013 02:51 PM, Michael Trimarchi wrote:
>> >> >>> Hi
>> >> >>>
>> >> >>> I'm working on omap4460 with two ulpi connected to (SMSC3320 -> HUB 
>> >> >>> SMSC2514) or (TUSB1210 -> HUB SMSC2514).
>> >> >>> The problem only happen when both port are used and after few suspend 
>> >> >>> resume are triggered.
>> >> >>> If I use just one port there is no issue on suspend resume. I already 
>> >> >>> covered all TI
>> >> >>> errata that I know and I'm working on TI kernel.
>> >> >>>
>> >> >>> The problem is here
>> >> >>>
>> >> >>> [   77.701934] ehci-omap ehci-omap.0: irq status a004 Async Recl PCD
>> >> >>>
>> >> >>> Both ports change status from 001005 to 001009 (you have a log just 
>> >> >>> after).
>> >> >>> So from host point of view both hub connected are not working in HS 
>> >> >>> mode.
>> >> >>> After that the omap ehci has gone because the bus can not work in FS 
>> >> >>> and LS and I can not recover from here.
>> >> >>> Status of transceivers are dumped and they are ok after resume.
>> >> >>>
>> >> >>> Do you have any suggestion?
>> >> >>
>> >> >> I'm not very sure but both ports suddenly changing state like that 
>> >> >> look like
>> >> >> a hardware issue. Also, it is strange that you can reproduce it only 
>> >> >> when two
>> >> >> ports are simultaneously in use. Unfortunately, I can't match your 
>> >> >> setup with 2 ULPI
>> >> >
>> >> > Yes I know that TI doesn't have any setup like that.
>> >> >
>> >> >> ports.
>> >> >>
>> >> >> I have a OMAP5 uEVM that uses 2 ports but it won't be identical to 
>> >> >> your setup as
>> >> >> they are on HSIC and not ULPI.
>> >> >>
>> >> >> Did you try errata i693?
>> >> >
>> >> > Yes I have it. It's not clear if I need to wait after
>> >> > ehci_writel(ehci, temp | PORT_SUSPEND, status_reg);
>> >> > polling the suspendM of the SMSC or the suspend status of the PORT or I 
>> >> > can
>> >> > switch just after this instruction. Because TI kernel use an msleep of 
>> >> > 4 mseconds and then switch. It could be a timing issue on how errata is 
>> >> > implemented when I have two ports? How this internal count works?
>> >>
>> >>
>> >> The OMAP EHCI controller transparently sets the suspendM bit of the PHY 
>> >> when you
>> >> set the PORT_SUSPEND feature on the EHCI port. So you don't need to poll 
>> >> for anything.
>> >>
>> >
>> > A delay is necessary. If we apply the errata to the port before a delay 
>> > the errata
>> > doesn't work.
>> >
>> > /* Use internal 60Mhz clock ULPIBx */
>> > temp_reg = omap_readl(L3INIT_HSUSBHOST_CLKCTRL);
>> > temp_reg |= 1 << (8 + port);
>> > temp_reg &= ~(1 << (24 + port));
>> > omap_writel(temp_reg, L3INIT_HSUSBHOST_CLKCTRL);
>> >
>> > /* Wait 2ms to have transceiver transaction */
>> > mdelay(2);
>> >
>> > /* Use external clock ULPIBx */
>> > temp_reg &= ~(1 << (8 + port));
>> > temp_reg |= 1 << (24 + port);
>> > omap_writel(temp_reg, L3INIT_HSUSBHOST_CLKCTRL);
>> >
>> > Now it's not clear to me what happen if I apply this clock too early 
>> > (transeceiver still
>> > driver the clock) or too late. Any clue?
>>
>> We need to wait 3ms for entire USB bus to go into suspend after
>> setting the PORT_SUSPEND bit. During this time, internal OMAP EHCI logic
>> will communicate with PHY so it is not safe to switch the clocks to
>> internal source.
>> That's why with 2ms delay it fails. 4ms delay (3ms + 1ms for safety)
>> is enough here
>> and is successfully used last few years for production devices.
>
> Well this mdelay is the switch of the clock and not the delay after
> PORT_SUSPEND. So after writing PORT_SUSPEND I need to wait
> 4ms and then in 2ms you have a lot of clock to reach the 18 count. Correct?

Yes, sorry for confusing :)
Moreover, 2ms is more than enough, errata document says about 1ms delay
(and probably may be decreased up to few useconds)

>
> Anyway I understand, but why both hub connected to the smsc3320 move from
> HS to FS? So it's not important if there is a drift of delay but it must
> be >= 4ms. Correct?
>
> The code works if I just use one port or remove one hub ;)
>
> Now the code is like this:
>
> temp &= ~(PORT_WKCONN_E | PORT_RWC_BITS);
> temp |= PORT_WKDISC_E | PORT_WKOC_E;
> ehci_writel(ehci, temp | PORT_SUSPEND, status_reg);
>
> mdelay(4);
> omap_ehci_erratum_i693(ehci, ((wIndex & 0xff) - 1));
>
> The code of the function is up on this email.

Do you have locks around this software workaround?
The patch I did against 3.4 linux kernel may be helpful for
you in such case: http://r

Re: [PATCH] Documentation: dt: bindings: TI WiLink modules

[Luciano Coelho]

On Thu, 2013-06-27 at 14:12 -0500, Nishanth Menon wrote:
> On 06/27/2013 01:51 PM, Luciano Coelho wrote:
> > On Thu, 2013-06-27 at 08:39 -0500, Nishanth Menon wrote:
> >> On Thu, Jun 27, 2013 at 8:30 AM, Luciano Coelho  wrote:
> >>> On Thu, 2013-06-27 at 08:23 -0500, Nishanth Menon wrote:
>  On 06/27/2013 08:19 AM, Luciano Coelho wrote:
> > On Thu, 2013-06-27 at 08:15 -0500, Nishanth Menon wrote:
> >> On Thu, Jun 27, 2013 at 7:58 AM, Luciano Coelho  wrote:
> >>> For the actual DTS files, I could add a wilink.dtsi with enumerations
> >>> for these values so they could be used in the node definitions.  But 
> >>> I'm
> >>> not sure it's going to be that valuable in the end.
> >> The  way GPIO HIGH was defined might help to provide guidance I think 
> >> :)
> >
> > Where? As far as I can see, the GPIO flags are defined in a bitmap.
> 
>  include/dt-bindings/gpio/gpio.h
> >>>
> >>> Thanks! I don't see these macros used anywhere, though.
> >> umm... I'd think you have'nt looked deep enough / lists :)
> >
> > If you mean mailing lists, you're right, I didn't.  I just did a git
> > grep for the macros and didn't find any users.
> git grep "GPIO_ACTIVE_[HIGH|LOW]" arch/arm/boot/dts/|wc -l
> 344
> on next-20130626. anyways, besides the point.
> 
> 
> >>> This seems to be a completely different thing.  This is the header that
> >>> contains the helper functions to get GPIO-related device tree nodes,
> >>> isn't it?
> >> That is true, but it also contains the flag for level which needs to
> >> be in sync with the gpio.h dts header.
>  just a hint. not saying frequencies were defined in header. for systems
>  that define frequencies - example cpufreq OPPs, clock node usage, we do
>  not use indexing to frequency, instead, that is the responsibility of
>  driver to convert frequency back to required index.
>  git grep frequency Documentation/devicetree/bindings gives you how the
>  precedence looks like.
> 
>  Personally, if given a choice, I'd go with actual frequencies rather
>  than indexes.
> >>>
> >>> If I do that, I need to add also a separate flag to define whether the
> >>> XTAL clock is used or not.  For instance, we have 26MHz and 26MHz
> >>> crystal; and 38.4MHz and 38.4MHz crystal...
> >> Yes, you would have to. at the same time, it is easy for module maker
> >> to provide dtsi corresponding to exact h/w representation on his
> >> module using wilink chip without being worried about weird index value
> >> whose meaning is hidden in binding
> >
> > The module makers need to know about the bindings and read the document
> > before they specify the node in DTS.  I think for clarity, a comment in
> > the DTS file stating the actual frequency is good enough.  Simpler and
> > more efficient (in terms of DT binary size and module code size) than
> > adding the actual frequencies.
> >
> >
> >> On the flip side, It also allows driver to reject frequencies /
> >> configurations that are not supported by the corresponding chip.
> >
> > It's actually much easier to reject frequencies that are not valid with
> > the enumeration.  "if (refclock > 5) { bail_out(); }".  If I need to
> > check every frequency, I need to add an array of valid frequencies and
> > so on.  Waste of code, IMHO.
> >
> >
> >> As I said, just my 2 cents. Personally, I'd like dts files to be as
> >> readable as c files without having to dig through bindings document.
> >
> > As I said before, for readability, adding a comment with the frequency
> > is good enough.  This is what I did for PandaES's DTS (not sent out
> > yet):
> >
> > wlan {
> >  compatible = "ti,wilink6";
> >  interrupt-parent = <&gpio2>;
> >  interrupts = <21 0x4>; /* gpio line 53, high level triggered */
> >  refclock = <2>;/* 38.4 MHz */
> >  };
> >
> > Looks more readable to me than:
> >
> > wlan {
> >  compatible = "ti,wilink6";
> >  interrupt-parent = <&gpio2>;
> >  interrupts = <21 0x4>; /* gpio line 53, high level triggered */
> >  refclock = <38400>;
> >  refclock_xtal = <0>;
> >  };
> >
> > The macro idea sounds better to me, but in this case this code is so
> > simple that I don't think it's really worth it.
> >
> > And, from another point of view, I see this as only a specification of
> > the module's details.  The frequency value is not really used anywhere
> > outside the module, so we don't see it.  I don't think there's a good
> > reason to expose the actual frequency to the kernel (and parse it back
> > to the values the firmware needs), since nothing else inside the kernel
> > will care about it.
> Overview: we are adding bindings for 
> Documentation/devicetree/bindings/net/wireless/ti-wilink.txt Which I 
> believe is intended to be generic.
> 
> Current frequencies supported for tcxoclock is the following for WiLink7
> + 0 = 19.200 MHz
> + 1 = 26.000 MHz
> + 2

Re: omap4 ehci sporadic resume issue

[Michael Trimarchi]

Hi

On Thu, Jun 27, 2013 at 09:59:35PM +0300, Ruslan Bilovol wrote:
> Hello guys,
> 
> On Thu, Jun 27, 2013 at 8:56 PM, Michael Trimarchi
>  wrote:
> > Hi Roger
> >
> > On Thu, Jun 27, 2013 at 05:49:41PM +0300, Roger Quadros wrote:
> >> +Ruslan
> >>
> >> On 06/27/2013 05:17 PM, Michael Trimarchi wrote:
> >> > Hi Roger
> >> >
> >> > On Thu, Jun 27, 2013 at 04:59:38PM +0300, Roger Quadros wrote:
> >> >> Hi Michael,
> >> >>
> >> >> On 06/27/2013 02:51 PM, Michael Trimarchi wrote:
> >> >>> Hi
> >> >>>
> >> >>> I'm working on omap4460 with two ulpi connected to (SMSC3320 -> HUB 
> >> >>> SMSC2514) or (TUSB1210 -> HUB SMSC2514).
> >> >>> The problem only happen when both port are used and after few suspend 
> >> >>> resume are triggered.
> >> >>> If I use just one port there is no issue on suspend resume. I already 
> >> >>> covered all TI
> >> >>> errata that I know and I'm working on TI kernel.
> >> >>>
> >> >>> The problem is here
> >> >>>
> >> >>> [   77.701934] ehci-omap ehci-omap.0: irq status a004 Async Recl PCD
> >> >>>
> >> >>> Both ports change status from 001005 to 001009 (you have a log just 
> >> >>> after).
> >> >>> So from host point of view both hub connected are not working in HS 
> >> >>> mode.
> >> >>> After that the omap ehci has gone because the bus can not work in FS 
> >> >>> and LS and I can not recover from here.
> >> >>> Status of transceivers are dumped and they are ok after resume.
> >> >>>
> >> >>> Do you have any suggestion?
> >> >>
> >> >> I'm not very sure but both ports suddenly changing state like that look 
> >> >> like
> >> >> a hardware issue. Also, it is strange that you can reproduce it only 
> >> >> when two
> >> >> ports are simultaneously in use. Unfortunately, I can't match your 
> >> >> setup with 2 ULPI
> >> >
> >> > Yes I know that TI doesn't have any setup like that.
> >> >
> >> >> ports.
> >> >>
> >> >> I have a OMAP5 uEVM that uses 2 ports but it won't be identical to your 
> >> >> setup as
> >> >> they are on HSIC and not ULPI.
> >> >>
> >> >> Did you try errata i693?
> >> >
> >> > Yes I have it. It's not clear if I need to wait after
> >> > ehci_writel(ehci, temp | PORT_SUSPEND, status_reg);
> >> > polling the suspendM of the SMSC or the suspend status of the PORT or I 
> >> > can
> >> > switch just after this instruction. Because TI kernel use an msleep of 4 
> >> > mseconds and then switch. It could be a timing issue on how errata is 
> >> > implemented when I have two ports? How this internal count works?
> >>
> >>
> >> The OMAP EHCI controller transparently sets the suspendM bit of the PHY 
> >> when you
> >> set the PORT_SUSPEND feature on the EHCI port. So you don't need to poll 
> >> for anything.
> >>
> >
> > A delay is necessary. If we apply the errata to the port before a delay the 
> > errata
> > doesn't work.
> >
> > /* Use internal 60Mhz clock ULPIBx */
> > temp_reg = omap_readl(L3INIT_HSUSBHOST_CLKCTRL);
> > temp_reg |= 1 << (8 + port);
> > temp_reg &= ~(1 << (24 + port));
> > omap_writel(temp_reg, L3INIT_HSUSBHOST_CLKCTRL);
> >
> > /* Wait 2ms to have transceiver transaction */
> > mdelay(2);
> >
> > /* Use external clock ULPIBx */
> > temp_reg &= ~(1 << (8 + port));
> > temp_reg |= 1 << (24 + port);
> > omap_writel(temp_reg, L3INIT_HSUSBHOST_CLKCTRL);
> >
> > Now it's not clear to me what happen if I apply this clock too early 
> > (transeceiver still
> > driver the clock) or too late. Any clue?
> 
> We need to wait 3ms for entire USB bus to go into suspend after
> setting the PORT_SUSPEND bit. During this time, internal OMAP EHCI logic
> will communicate with PHY so it is not safe to switch the clocks to
> internal source.
> That's why with 2ms delay it fails. 4ms delay (3ms + 1ms for safety)
> is enough here
> and is successfully used last few years for production devices.

Well this mdelay is the switch of the clock and not the delay after
PORT_SUSPEND. So after writing PORT_SUSPEND I need to wait
4ms and then in 2ms you have a lot of clock to reach the 18 count. Correct?

Anyway I understand, but why both hub connected to the smsc3320 move from
HS to FS? So it's not important if there is a drift of delay but it must
be >= 4ms. Correct?

The code works if I just use one port or remove one hub ;)

Now the code is like this:

temp &= ~(PORT_WKCONN_E | PORT_RWC_BITS);
temp |= PORT_WKDISC_E | PORT_WKOC_E;
ehci_writel(ehci, temp | PORT_SUSPEND, status_reg);

mdelay(4);
omap_ehci_erratum_i693(ehci, ((wIndex & 0xff) - 1));

The code of the function is up on this email.

Michael

> 
> -- 
> Best regards,
> Ruslan Bilvol
> 
> >
> >
> >> What the errata says is that once software sets the PORT_SUSPEND feature, 
> >> the PHY will
> >> got into suspend and cut the PHY clock sooner than required for the EHCI 
> >> controller to
> >> complete its suspend operations. (NOTE: this is only applicable when the 
> >> PHY is providing the
> >> ulpi_clk).
> >>
> >
> > Yes this is the case
> >
> >> What the workaround does is to just wait for a while (don't know why

Re: [PATCH] Documentation: dt: bindings: TI WiLink modules

[Nishanth Menon]

On 06/27/2013 01:51 PM, Luciano Coelho wrote:

On Thu, 2013-06-27 at 08:39 -0500, Nishanth Menon wrote:

On Thu, Jun 27, 2013 at 8:30 AM, Luciano Coelho  wrote:

On Thu, 2013-06-27 at 08:23 -0500, Nishanth Menon wrote:

On 06/27/2013 08:19 AM, Luciano Coelho wrote:

On Thu, 2013-06-27 at 08:15 -0500, Nishanth Menon wrote:

On Thu, Jun 27, 2013 at 7:58 AM, Luciano Coelho  wrote:

For the actual DTS files, I could add a wilink.dtsi with enumerations
for these values so they could be used in the node definitions.  But I'm
not sure it's going to be that valuable in the end.

The  way GPIO HIGH was defined might help to provide guidance I think :)


Where? As far as I can see, the GPIO flags are defined in a bitmap.


include/dt-bindings/gpio/gpio.h


Thanks! I don't see these macros used anywhere, though.

umm... I'd think you have'nt looked deep enough / lists :)


If you mean mailing lists, you're right, I didn't.  I just did a git
grep for the macros and didn't find any users.

git grep "GPIO_ACTIVE_[HIGH|LOW]" arch/arm/boot/dts/|wc -l
344
on next-20130626. anyways, besides the point.



This seems to be a completely different thing.  This is the header that
contains the helper functions to get GPIO-related device tree nodes,
isn't it?

That is true, but it also contains the flag for level which needs to
be in sync with the gpio.h dts header.

just a hint. not saying frequencies were defined in header. for systems
that define frequencies - example cpufreq OPPs, clock node usage, we do
not use indexing to frequency, instead, that is the responsibility of
driver to convert frequency back to required index.
git grep frequency Documentation/devicetree/bindings gives you how the
precedence looks like.

Personally, if given a choice, I'd go with actual frequencies rather
than indexes.


If I do that, I need to add also a separate flag to define whether the
XTAL clock is used or not.  For instance, we have 26MHz and 26MHz
crystal; and 38.4MHz and 38.4MHz crystal...

Yes, you would have to. at the same time, it is easy for module maker
to provide dtsi corresponding to exact h/w representation on his
module using wilink chip without being worried about weird index value
whose meaning is hidden in binding


The module makers need to know about the bindings and read the document
before they specify the node in DTS.  I think for clarity, a comment in
the DTS file stating the actual frequency is good enough.  Simpler and
more efficient (in terms of DT binary size and module code size) than
adding the actual frequencies.



On the flip side, It also allows driver to reject frequencies /
configurations that are not supported by the corresponding chip.


It's actually much easier to reject frequencies that are not valid with
the enumeration.  "if (refclock > 5) { bail_out(); }".  If I need to
check every frequency, I need to add an array of valid frequencies and
so on.  Waste of code, IMHO.



As I said, just my 2 cents. Personally, I'd like dts files to be as
readable as c files without having to dig through bindings document.


As I said before, for readability, adding a comment with the frequency
is good enough.  This is what I did for PandaES's DTS (not sent out
yet):

wlan {
 compatible = "ti,wilink6";
 interrupt-parent = <&gpio2>;
 interrupts = <21 0x4>;   /* gpio line 53, high level triggered 
*/
 refclock = <2>;  /* 38.4 MHz */
 };

Looks more readable to me than:

wlan {
 compatible = "ti,wilink6";
 interrupt-parent = <&gpio2>;
 interrupts = <21 0x4>;   /* gpio line 53, high level triggered 
*/
 refclock = <38400>;
 refclock_xtal = <0>;
 };

The macro idea sounds better to me, but in this case this code is so
simple that I don't think it's really worth it.

And, from another point of view, I see this as only a specification of
the module's details.  The frequency value is not really used anywhere
outside the module, so we don't see it.  I don't think there's a good
reason to expose the actual frequency to the kernel (and parse it back
to the values the firmware needs), since nothing else inside the kernel
will care about it.
Overview: we are adding bindings for 
Documentation/devicetree/bindings/net/wireless/ti-wilink.txt Which I 
believe is intended to be generic.


Current frequencies supported for tcxoclock is the following for WiLink7
+   0 = 19.200 MHz
+   1 = 26.000 MHz
+   2 = 38.400 MHz
+   3 = 52.000 MHz
+   4 = 16.368 MHz
+   5 = 32.736 MHz
+   6 = 16.800 MHz
+   7 = 33.600 MHz
Say wilink9 comes along and redefines this map OR introduces support for 
20MHz support making the map 0-8, you'd no longer be able to support 
this map. or say a new update of firmware magically changes this mapping 
or something unexpected.


If the translation and validation is done in the driver, it is trivial 
to handle without redefini

Re: omap4 ehci sporadic resume issue

[Ruslan Bilovol]

Hello guys,

On Thu, Jun 27, 2013 at 8:56 PM, Michael Trimarchi
 wrote:
> Hi Roger
>
> On Thu, Jun 27, 2013 at 05:49:41PM +0300, Roger Quadros wrote:
>> +Ruslan
>>
>> On 06/27/2013 05:17 PM, Michael Trimarchi wrote:
>> > Hi Roger
>> >
>> > On Thu, Jun 27, 2013 at 04:59:38PM +0300, Roger Quadros wrote:
>> >> Hi Michael,
>> >>
>> >> On 06/27/2013 02:51 PM, Michael Trimarchi wrote:
>> >>> Hi
>> >>>
>> >>> I'm working on omap4460 with two ulpi connected to (SMSC3320 -> HUB 
>> >>> SMSC2514) or (TUSB1210 -> HUB SMSC2514).
>> >>> The problem only happen when both port are used and after few suspend 
>> >>> resume are triggered.
>> >>> If I use just one port there is no issue on suspend resume. I already 
>> >>> covered all TI
>> >>> errata that I know and I'm working on TI kernel.
>> >>>
>> >>> The problem is here
>> >>>
>> >>> [   77.701934] ehci-omap ehci-omap.0: irq status a004 Async Recl PCD
>> >>>
>> >>> Both ports change status from 001005 to 001009 (you have a log just 
>> >>> after).
>> >>> So from host point of view both hub connected are not working in HS mode.
>> >>> After that the omap ehci has gone because the bus can not work in FS and 
>> >>> LS and I can not recover from here.
>> >>> Status of transceivers are dumped and they are ok after resume.
>> >>>
>> >>> Do you have any suggestion?
>> >>
>> >> I'm not very sure but both ports suddenly changing state like that look 
>> >> like
>> >> a hardware issue. Also, it is strange that you can reproduce it only when 
>> >> two
>> >> ports are simultaneously in use. Unfortunately, I can't match your setup 
>> >> with 2 ULPI
>> >
>> > Yes I know that TI doesn't have any setup like that.
>> >
>> >> ports.
>> >>
>> >> I have a OMAP5 uEVM that uses 2 ports but it won't be identical to your 
>> >> setup as
>> >> they are on HSIC and not ULPI.
>> >>
>> >> Did you try errata i693?
>> >
>> > Yes I have it. It's not clear if I need to wait after
>> > ehci_writel(ehci, temp | PORT_SUSPEND, status_reg);
>> > polling the suspendM of the SMSC or the suspend status of the PORT or I can
>> > switch just after this instruction. Because TI kernel use an msleep of 4 
>> > mseconds and then switch. It could be a timing issue on how errata is 
>> > implemented when I have two ports? How this internal count works?
>>
>>
>> The OMAP EHCI controller transparently sets the suspendM bit of the PHY when 
>> you
>> set the PORT_SUSPEND feature on the EHCI port. So you don't need to poll for 
>> anything.
>>
>
> A delay is necessary. If we apply the errata to the port before a delay the 
> errata
> doesn't work.
>
> /* Use internal 60Mhz clock ULPIBx */
> temp_reg = omap_readl(L3INIT_HSUSBHOST_CLKCTRL);
> temp_reg |= 1 << (8 + port);
> temp_reg &= ~(1 << (24 + port));
> omap_writel(temp_reg, L3INIT_HSUSBHOST_CLKCTRL);
>
> /* Wait 2ms to have transceiver transaction */
> mdelay(2);
>
> /* Use external clock ULPIBx */
> temp_reg &= ~(1 << (8 + port));
> temp_reg |= 1 << (24 + port);
> omap_writel(temp_reg, L3INIT_HSUSBHOST_CLKCTRL);
>
> Now it's not clear to me what happen if I apply this clock too early 
> (transeceiver still
> driver the clock) or too late. Any clue?

We need to wait 3ms for entire USB bus to go into suspend after
setting the PORT_SUSPEND bit. During this time, internal OMAP EHCI logic
will communicate with PHY so it is not safe to switch the clocks to
internal source.
That's why with 2ms delay it fails. 4ms delay (3ms + 1ms for safety)
is enough here
and is successfully used last few years for production devices.

-- 
Best regards,
Ruslan Bilvol

>
>
>> What the errata says is that once software sets the PORT_SUSPEND feature, 
>> the PHY will
>> got into suspend and cut the PHY clock sooner than required for the EHCI 
>> controller to
>> complete its suspend operations. (NOTE: this is only applicable when the PHY 
>> is providing the
>> ulpi_clk).
>>
>
> Yes this is the case
>
>> What the workaround does is to just wait for a while (don't know why 4ms), 
>> and remux the
>> ulpi_clock to an internal 60MHz clock for a while so that it can complete 
>> its suspend operations.
>
> What happen if I apply a big delay after PORT_SUSPEND. Will the internal 
> state machine of the omap
> continue to wait the clock?
>
> Michael
>
>>
>> >
>> > First time is 18, and then?
>> >
>> I think it is 18 for every port suspend.
>>
>> >>
>> >> Also, are you suspending and resuming only the USB or the entire system?
>> >>
>> >
>> > Whole system. Right the only susbsytem that doens't go to suspend is the 
>> > FSUSB
>> > but this depends on the bootloader.
>>
>> OK.
>>
>> cheers,
>> -roger
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
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] Documentation: dt: bindings: TI WiLink modules

[Luciano Coelho]

On Thu, 2013-06-27 at 08:39 -0500, Nishanth Menon wrote:
> On Thu, Jun 27, 2013 at 8:30 AM, Luciano Coelho  wrote:
> > On Thu, 2013-06-27 at 08:23 -0500, Nishanth Menon wrote:
> >> On 06/27/2013 08:19 AM, Luciano Coelho wrote:
> >> > On Thu, 2013-06-27 at 08:15 -0500, Nishanth Menon wrote:
> >> >> On Thu, Jun 27, 2013 at 7:58 AM, Luciano Coelho  wrote:
> >> >>> For the actual DTS files, I could add a wilink.dtsi with enumerations
> >> >>> for these values so they could be used in the node definitions.  But 
> >> >>> I'm
> >> >>> not sure it's going to be that valuable in the end.
> >> >> The  way GPIO HIGH was defined might help to provide guidance I think :)
> >> >
> >> > Where? As far as I can see, the GPIO flags are defined in a bitmap.
> >>
> >> include/dt-bindings/gpio/gpio.h
> >
> > Thanks! I don't see these macros used anywhere, though.
> umm... I'd think you have'nt looked deep enough / lists :)

If you mean mailing lists, you're right, I didn't.  I just did a git
grep for the macros and didn't find any users.


> >> And corresponding kernel header:
> >> include/linux/of_gpio.h
> >
> > This seems to be a completely different thing.  This is the header that
> > contains the helper functions to get GPIO-related device tree nodes,
> > isn't it?
> That is true, but it also contains the flag for level which needs to
> be in sync with the gpio.h dts header.
> >> just a hint. not saying frequencies were defined in header. for systems
> >> that define frequencies - example cpufreq OPPs, clock node usage, we do
> >> not use indexing to frequency, instead, that is the responsibility of
> >> driver to convert frequency back to required index.
> >> git grep frequency Documentation/devicetree/bindings gives you how the
> >> precedence looks like.
> >>
> >> Personally, if given a choice, I'd go with actual frequencies rather
> >> than indexes.
> >
> > If I do that, I need to add also a separate flag to define whether the
> > XTAL clock is used or not.  For instance, we have 26MHz and 26MHz
> > crystal; and 38.4MHz and 38.4MHz crystal...
> Yes, you would have to. at the same time, it is easy for module maker
> to provide dtsi corresponding to exact h/w representation on his
> module using wilink chip without being worried about weird index value
> whose meaning is hidden in binding

The module makers need to know about the bindings and read the document
before they specify the node in DTS.  I think for clarity, a comment in
the DTS file stating the actual frequency is good enough.  Simpler and
more efficient (in terms of DT binary size and module code size) than
adding the actual frequencies.


> On the flip side, It also allows driver to reject frequencies /
> configurations that are not supported by the corresponding chip.

It's actually much easier to reject frequencies that are not valid with
the enumeration.  "if (refclock > 5) { bail_out(); }".  If I need to
check every frequency, I need to add an array of valid frequencies and
so on.  Waste of code, IMHO.


> As I said, just my 2 cents. Personally, I'd like dts files to be as
> readable as c files without having to dig through bindings document.

As I said before, for readability, adding a comment with the frequency
is good enough.  This is what I did for PandaES's DTS (not sent out
yet):

wlan {
 compatible = "ti,wilink6";
 interrupt-parent = <&gpio2>;
 interrupts = <21 0x4>; /* gpio line 53, high level triggered */
 refclock = <2>;/* 38.4 MHz */
 };

Looks more readable to me than:

wlan {
 compatible = "ti,wilink6";
 interrupt-parent = <&gpio2>;
 interrupts = <21 0x4>; /* gpio line 53, high level triggered */
 refclock = <38400>;
 refclock_xtal = <0>;
 };

The macro idea sounds better to me, but in this case this code is so
simple that I don't think it's really worth it.

And, from another point of view, I see this as only a specification of
the module's details.  The frequency value is not really used anywhere
outside the module, so we don't see it.  I don't think there's a good
reason to expose the actual frequency to the kernel (and parse it back
to the values the firmware needs), since nothing else inside the kernel
will care about it.

--
Luca.

--
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 v2] ARM: DTS: OMAP4: Add OMAP4 Blaze Tablet support

[Ruslan Bilovol]

Hi Nishanth,

On Wed, Jun 26, 2013 at 4:13 PM, Nishanth Menon  wrote:
> On Wed, Jun 26, 2013 at 3:03 AM, Ruslan Bilovol  wrote:
>> Hi Nishanth,
>>
>> On Tue, Jun 25, 2013 at 3:43 PM, Nishanth Menon  wrote:
>>> On 06/25/2013 07:01 AM, Nishanth Menon wrote:

 On 06/25/2013 06:32 AM, Ruslan Bilovol wrote:
>
> The OMAP4 Blaze Tablet is TI OMAP4 processor-based
> development platform in a tablet formfactor.
> The platform contains many of the features found in
> present-day handsets (such as audio, video, wireless
> functions and user interfaces) and in addition
> contains features for software development and test.
>
> This patch adds initial support for the OMAP4 Blaze
> Tablet development platform. Additional functionality
> depends on different drivers and code modifications that
> are not upstreamed yet or do not support DT yet, so will
> be added later.--


 http://svtronics.com/omap/sevm4460,blaze,omap might help too :)
>>
>> Yes, forgot to add this information from cover-letter from previous
>> version of patch :)
>
> ;) - link was wrong!

I know, but don't worry about it - I will put correct one in v3 :)

> http://svtronics.com/omap?product_id=15 is more like it -> Blaze
> tablet by default comes in 4460/4470 variants. I suggest introducing
> 4470 variant here.
> I am aware of the SOM compatibility and ability to support 4430 SOM on
> tablet as well, but to keep tablet alive and reduce scope of testing,
> keeping just 4470 in place might be a good choice.

Yes, this makes sense. I think as soon as OMAP4470 reach upstream, we can easily
switch the BlazeTablet's  .dts to 4470

>
> just my 2 cents, no strong feelings towards either. :)
>
>>
 [...]
>
> +
> +#include "twl6030.dtsi"
> +

 Might be good to see the TWL interrupt pin information made available as
 well?
>>>
>>> Allow me to rephrase a comment a little bit more :)
>>> Similar to twl4030_omap3.dtsi, we could introduce twl6030_omap4.dtsi. this
>>> could contain the common pins used for 6030.
>>>  &omap4_pmx_wkup {
>>>  pinctrl-names = "default";
>>>  pinctrl-0 = <
>>>  &twl6030_wkup_pins
>>>  >;
>>>
>>>  twl6030_wkup_pins: pinmux_twl6030_wkup_pins {
>>>  pinctrl-single,pins = <
>>>  0x14 (PIN_OUTPUT | MUX_MODE2)
>>>  >;
>>>  };
>>>  };
>>>
>>> twl6030_pins: pinmux_twl6030_pins {
>>> pinctrl-single,pins = <
>>> 0x15e (WAKEUP_EN | PIN_INPUT_PULLUP | MUX_MODE0)
>>> /* sys_nirq1.sys_nirq1 */
>>> >;
>>> };
>>>
>>> which is now already duplicated in 2 places (SDP and Panda), and in this
>>> patch duplicated again.
>>
>> Agree, I'm planning to do this later as part of moving common things into
>> some System-On-Module(SOM)-specific files, as discussed previously
>> here https://patchwork.kernel.org/patch/2118371/
>>
> I dont think I was mentioning about that - I just would really like to
> avoid duplication of 6030 information all over the place. if we can
> avoid it, lets start consolidating.

Okay, I got your point. Will prepare the patch in v3..

> Regards,
> Nishanth Menon


-- 
Best regards,
Ruslan Bilvol


> --
> 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
--
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 0/5] AM33xx: MMC resources from DT without HWMOD data

[Fernandes, Joel]

Adding Benoit's other email as current one is marked Away. Thanks.

> -Original Message-
> From: Krishnamoorthy, Balaji T
> Sent: Thursday, June 27, 2013 11:27 AM
> To: Cousson, Benoit; Fernandes, Joel
> Cc: l...@metafoo.de; Tony Lindgren; Nori, Sekhar; Matt Porter; Grant Likely;
> Rob Herring; Vinod Koul; Mark Brown; Russell King; Rob Landley; Andrew
> Morton; Jason Kridner; Koen Kooi; Chris Ball; Devicetree Discuss; Linux OMAP
> List; Linux ARM Kernel List; Linux DaVinci Kernel List; Linux Kernel Mailing 
> List;
> Linux MMC List; Arnd Bergmann
> Subject: Re: [PATCH 0/5] AM33xx: MMC resources from DT without HWMOD
> data
> 
> On Thursday 27 June 2013 07:56 PM, Joel A Fernandes wrote:
> > Hi Benoit,
> >
> > On Thu, Jun 27, 2013 at 7:03 AM, Benoit Cousson  wrote:
> >> Hi Joel,
> >>
> >> On 06/26/2013 05:28 AM, Joel A Fernandes wrote:
> >>> On Tue, Jun 25, 2013 at 8:23 PM, Joel A Fernandes 
> wrote:
>  From: Joel A Fernandes 
> 
>  This series is fixes to get MMC working on AM33XX without HWMOD
> data.
>  On removal of HWMOD data, interrupt and register properties need to
>  be provided for the driver to function correctly.
> >>>
> >>> Please don't pull patches authored by me in this series. I have
> >>> posted them with my wrong email address by mistake. I will correct
> >>> my email during the next repost, after a round of review. Matt's
> >>> patches in the series are still good though.
> >>
> >> In that case, please repost these in two series to avoid pulling the
> >> DTS files in the MMC tree.
> >
> > The series has been replaced with the single patch:
> > "[PATCH v2] ARM: dts: add AM33XX MMC support"
> > http://marc.info/?l=linux-omap&m=137230403815943&w=2
> >
> > Some patches were squashed and others dropped in the series resulting
> > in the single patch above. This patch should be good to apply
> Hi Joel,
> 
> Before pushing mmc dts support for am335x, Can you please let me
> know if below 2 patches [1] are merged/accepted,
> IIRC these patches are needed for MMC to work properly.
> 
> I suggest to hold the dts patch until slave_sg_limit gets merged
> otherwise it will cause regression in am335x mmc.
> 
> [PATCH v4 1/3] dmaengine: add dma_get_slave_sg_limits()
> [PATCH v4 2/3] dma: edma: add device_slave_sg_limits() support
> 
> [1]
> https://groups.google.com/forum/#!topic/linux.kernel/khTTcPtQpag
> 
> >
> > Thanks,
> >
> > -Joel
> >
--
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 0/5] AM33xx: MMC resources from DT without HWMOD data

[Fernandes, Joel]

Hi Balaji,

> -Original Message-
> From: Krishnamoorthy, Balaji T
> Sent: Thursday, June 27, 2013 11:27 AM
> To: Cousson, Benoit; Fernandes, Joel
> Cc: l...@metafoo.de; Tony Lindgren; Nori, Sekhar; Matt Porter; Grant Likely;
> Rob Herring; Vinod Koul; Mark Brown; Russell King; Rob Landley; Andrew
> Morton; Jason Kridner; Koen Kooi; Chris Ball; Devicetree Discuss; Linux OMAP
> List; Linux ARM Kernel List; Linux DaVinci Kernel List; Linux Kernel Mailing 
> List;
> Linux MMC List; Arnd Bergmann
> Subject: Re: [PATCH 0/5] AM33xx: MMC resources from DT without HWMOD
> data
> 
> On Thursday 27 June 2013 07:56 PM, Joel A Fernandes wrote:
> > Hi Benoit,
> >
> > On Thu, Jun 27, 2013 at 7:03 AM, Benoit Cousson  wrote:
> >> Hi Joel,
> >>
> >> On 06/26/2013 05:28 AM, Joel A Fernandes wrote:
> >>> On Tue, Jun 25, 2013 at 8:23 PM, Joel A Fernandes 
> wrote:
>  From: Joel A Fernandes 
> 
>  This series is fixes to get MMC working on AM33XX without HWMOD
> data.
>  On removal of HWMOD data, interrupt and register properties need to
>  be provided for the driver to function correctly.
> >>>
> >>> Please don't pull patches authored by me in this series. I have
> >>> posted them with my wrong email address by mistake. I will correct
> >>> my email during the next repost, after a round of review. Matt's
> >>> patches in the series are still good though.
> >>
> >> In that case, please repost these in two series to avoid pulling the
> >> DTS files in the MMC tree.
> >
> > The series has been replaced with the single patch:
> > "[PATCH v2] ARM: dts: add AM33XX MMC support"
> > http://marc.info/?l=linux-omap&m=137230403815943&w=2
> >
> > Some patches were squashed and others dropped in the series resulting
> > in the single patch above. This patch should be good to apply
> Hi Joel,
> 
> Before pushing mmc dts support for am335x, Can you please let me
> know if below 2 patches [1] are merged/accepted,
> IIRC these patches are needed for MMC to work properly.
> 
> I suggest to hold the dts patch until slave_sg_limit gets merged
> otherwise it will cause regression in am335x mmc.
> 
> [PATCH v4 1/3] dmaengine: add dma_get_slave_sg_limits()
> [PATCH v4 2/3] dma: edma: add device_slave_sg_limits() support

Actually this is an independent regression and is currently worked on by 
Lars-Peter Clausen [1].

Currently not having the MMC DTS merged is also a regression, so I suggest lets 
take it one
step at a time and get the DTS merged in first. Also there will be overhead of 
reposting this
DTS patch later again which will not change. What do you say?

Thanks,

-Joel

[1] https://patchwork.kernel.org/patch/2228041/
--
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: omap4 ehci sporadic resume issue

[Michael Trimarchi]

Hi Roger

On Thu, Jun 27, 2013 at 05:49:41PM +0300, Roger Quadros wrote:
> +Ruslan
> 
> On 06/27/2013 05:17 PM, Michael Trimarchi wrote:
> > Hi Roger
> > 
> > On Thu, Jun 27, 2013 at 04:59:38PM +0300, Roger Quadros wrote:
> >> Hi Michael,
> >>
> >> On 06/27/2013 02:51 PM, Michael Trimarchi wrote:
> >>> Hi
> >>>
> >>> I'm working on omap4460 with two ulpi connected to (SMSC3320 -> HUB 
> >>> SMSC2514) or (TUSB1210 -> HUB SMSC2514). 
> >>> The problem only happen when both port are used and after few suspend 
> >>> resume are triggered.
> >>> If I use just one port there is no issue on suspend resume. I already 
> >>> covered all TI
> >>> errata that I know and I'm working on TI kernel.
> >>>
> >>> The problem is here
> >>>
> >>> [   77.701934] ehci-omap ehci-omap.0: irq status a004 Async Recl PCD
> >>>
> >>> Both ports change status from 001005 to 001009 (you have a log just 
> >>> after). 
> >>> So from host point of view both hub connected are not working in HS mode. 
> >>> After that the omap ehci has gone because the bus can not work in FS and 
> >>> LS and I can not recover from here.
> >>> Status of transceivers are dumped and they are ok after resume.
> >>>
> >>> Do you have any suggestion?
> >>
> >> I'm not very sure but both ports suddenly changing state like that look 
> >> like
> >> a hardware issue. Also, it is strange that you can reproduce it only when 
> >> two
> >> ports are simultaneously in use. Unfortunately, I can't match your setup 
> >> with 2 ULPI
> > 
> > Yes I know that TI doesn't have any setup like that.
> > 
> >> ports.
> >>
> >> I have a OMAP5 uEVM that uses 2 ports but it won't be identical to your 
> >> setup as
> >> they are on HSIC and not ULPI.
> >>
> >> Did you try errata i693?
> > 
> > Yes I have it. It's not clear if I need to wait after
> > ehci_writel(ehci, temp | PORT_SUSPEND, status_reg);
> > polling the suspendM of the SMSC or the suspend status of the PORT or I can
> > switch just after this instruction. Because TI kernel use an msleep of 4 
> > mseconds and then switch. It could be a timing issue on how errata is 
> > implemented when I have two ports? How this internal count works?
> 
> 
> The OMAP EHCI controller transparently sets the suspendM bit of the PHY when 
> you
> set the PORT_SUSPEND feature on the EHCI port. So you don't need to poll for 
> anything.
> 

A delay is necessary. If we apply the errata to the port before a delay the 
errata
doesn't work. 

/* Use internal 60Mhz clock ULPIBx */
temp_reg = omap_readl(L3INIT_HSUSBHOST_CLKCTRL);
temp_reg |= 1 << (8 + port);
temp_reg &= ~(1 << (24 + port));
omap_writel(temp_reg, L3INIT_HSUSBHOST_CLKCTRL);

/* Wait 2ms to have transceiver transaction */
mdelay(2);

/* Use external clock ULPIBx */
temp_reg &= ~(1 << (8 + port));
temp_reg |= 1 << (24 + port);
omap_writel(temp_reg, L3INIT_HSUSBHOST_CLKCTRL);

Now it's not clear to me what happen if I apply this clock too early 
(transeceiver still
driver the clock) or too late. Any clue?


> What the errata says is that once software sets the PORT_SUSPEND feature, the 
> PHY will
> got into suspend and cut the PHY clock sooner than required for the EHCI 
> controller to
> complete its suspend operations. (NOTE: this is only applicable when the PHY 
> is providing the
> ulpi_clk).
> 

Yes this is the case

> What the workaround does is to just wait for a while (don't know why 4ms), 
> and remux the
> ulpi_clock to an internal 60MHz clock for a while so that it can complete its 
> suspend operations.

What happen if I apply a big delay after PORT_SUSPEND. Will the internal state 
machine of the omap
continue to wait the clock?

Michael

> 
> > 
> > First time is 18, and then?
> >
> I think it is 18 for every port suspend.
>  
> >>
> >> Also, are you suspending and resuming only the USB or the entire system?
> >>
> > 
> > Whole system. Right the only susbsytem that doens't go to suspend is the 
> > FSUSB
> > but this depends on the bootloader.
> 
> OK. 
> 
> 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 v3 0/4] mtd:nand:omap2: clean-up of supported ECC schemes

[Gupta, Pekon]

To OMAP3/4/5 and AM335x users,

Though I have tested the following series on AM335x-EVM, 
but it would be good if it can also be tested on other platforms like
OMAP3/4/5 custom boards which use NAND.

This would be helpful, as this patch series provides base for further 
enhancement and cleanup of omap2-nand driver.


with regards, pekon


> -Original Message-
> From: Gupta, Pekon
> Sent: Sunday, June 23, 2013 11:28 PM
> To: t...@atomide.com; artem.bityuts...@linux.intel.com; Cousson, Benoit
> Cc: a...@arndb.de; Philip, Avinash; Balbi, Felipe; linux-
> m...@lists.infradead.org; linux-omap@vger.kernel.org;
> jp.franc...@cynove.com; Gupta, Pekon
> Subject: [PATCH v3 0/4] mtd:nand:omap2: clean-up of supported ECC
> schemes
> 
> (with Author Name fixed)
> Changes v2 -> v3
> - PATCH-1: re-arranged code to remove redundancy, added
> NAND_BUSWIDTH_AUTO
> - PATCH-2: updated nand-ecc-opt DT mapping and Documentation
> - PATCH-3: code-cleaning + changes to match PATCH-1
> - PATCH-4  update DT attribute for ti,nand-ecc-opt
>   - received feedback to keep DT mapping independent of linuxism
> - PATCH-4: : ARM: dts: AM33xx: updated default ECC scheme in nand-
> ecc-opt
>   - independent patch for AM335x-evm.dts update based on PATCH-2
> 
> Changes v1 -> v2
>   added   [PATCH 3/4] and [PATCH 4/4]
> 
> Patches in this series:
> [PATCH 1/4]: clean-up and optimization for supported ECC schemes.
> [PATCH 2/4]: add separate DT options each supported ECC scheme.
> [PATCH 3/4]: update BCH4 ECC implementation (using ELM or using lib/bch.h)
> [PATCH 4/4]: ARM: dts: AM33xx: updated default ECC scheme in nand-ecc-
> opt
> 
> After this patch series, omap2-nand driver will supports following ECC
> schemes:
> +---+---+---+
> | ECC scheme  |ECC calculation|Error detection|
> +---+---+---+
> |OMAP_ECC_HAMMING_CODE_DEFAULT|S/W|S/W
>   |
> |OMAP_ECC_HAMMING_CODE_HW |H/W (GPMC) |S/W
>   |
> |OMAP_ECC_HAMMING_CODE_HW_ROMCODE |H/W (GPMC) |S/W
>   |
> +---+---+---+
> |OMAP_ECC_BCH4_CODE_HW_DETECTION_SW   |H/W (GPMC) |S/W
> (lib/bch.h)|
> |OMAP_ECC_BCH4_CODE_HW|H/W (GPMC) |H/W (ELM)
>   |
> +---+---+---+
> |OMAP_ECC_BCH8_CODE_HW_DETECTION_SW   |H/W (GPMC) |S/W
> (lib/bch.h)|
> |OMAP_ECC_BCH8_CODE_HW|H/W (GPMC) |H/W (ELM)
>   |
> +---+---+---+
> - Selection of OMAP_ECC_BCHx_CODE_HW_DETECTION_SW requires,
>   Kconfig: CONFIG_MTD_NAND_ECC_BCH: enables S/W based BCH
> ECC algorithm.
> 
> - Selection of OMAP_ECC_BCHx_CODE_HW requires,
>   Kconfig: CONFIG_MTD_NAND_OMAP_BCH: enables ELM H/W
> module.
> 
> 
> Pekon Gupta (4):
>   mtd:nand:omap2: clean-up BCHx_HW and BCHx_SW ECC configurations in
> device_probe
>   ARM: OMAP2+: cleaned-up DT support of various ECC schemes
>   mtd:nand:omap2: updated support for BCH4 ECC scheme
>   ARM: dts: AM33xx: updated default ECC scheme in nand-ecc-opt
> 
>  .../devicetree/bindings/mtd/gpmc-nand.txt  |  65 ++-
>  arch/arm/boot/dts/am335x-evm.dts   |   2 +-
>  arch/arm/mach-omap2/gpmc.c |  14 +-
>  drivers/mtd/nand/Kconfig   |   7 +-
>  drivers/mtd/nand/omap2.c   | 482 
> ++---
>  include/linux/platform_data/elm.h  |   4 +
>  include/linux/platform_data/mtd-nand-omap2.h   |  22 +-
>  7 files changed, 307 insertions(+), 289 deletions(-)
> 
> --
> 1.8.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 0/5] AM33xx: MMC resources from DT without HWMOD data

[Balaji T K]

On Thursday 27 June 2013 07:56 PM, Joel A Fernandes wrote:

Hi Benoit,

On Thu, Jun 27, 2013 at 7:03 AM, Benoit Cousson  wrote:

Hi Joel,

On 06/26/2013 05:28 AM, Joel A Fernandes wrote:

On Tue, Jun 25, 2013 at 8:23 PM, Joel A Fernandes  wrote:

From: Joel A Fernandes 

This series is fixes to get MMC working on AM33XX without HWMOD data.
On removal of HWMOD data, interrupt and register properties need to be provided
for the driver to function correctly.


Please don't pull patches authored by me in this series. I have posted
them with my wrong email address by mistake. I will correct my email
during the next repost, after a round of review. Matt's patches in the
series are still good though.


In that case, please repost these in two series to avoid pulling the DTS
files in the MMC tree.


The series has been replaced with the single patch:
"[PATCH v2] ARM: dts: add AM33XX MMC support"
http://marc.info/?l=linux-omap&m=137230403815943&w=2

Some patches were squashed and others dropped in the series resulting
in the single
patch above. This patch should be good to apply

Hi Joel,

Before pushing mmc dts support for am335x, Can you please let me
know if below 2 patches [1] are merged/accepted,
IIRC these patches are needed for MMC to work properly.

I suggest to hold the dts patch until slave_sg_limit gets merged
otherwise it will cause regression in am335x mmc.

[PATCH v4 1/3] dmaengine: add dma_get_slave_sg_limits()
[PATCH v4 2/3] dma: edma: add device_slave_sg_limits() support

[1]
https://groups.google.com/forum/#!topic/linux.kernel/khTTcPtQpag



Thanks,

-Joel


--
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: [RFC] ARM: OMAP2+: omap_device: add pinctrl handling

[Grygorii Strashko]

On 06/27/2013 05:45 PM, Tony Lindgren wrote:

* Grygorii Strashko  [130627 07:12]:


As you can see, from 12 pins only 3 pins need to be reconfigured
while switching from "active"->"idle" states and back (and as I
mentioned above for OMAP "idle" == "sleep" now).

Regarding "OFF" state:
OMAP mux HW defines special state for unused pins which is selected
by default after reset and need to be selected when device isn't
used, for example:
_MUXMODE - Functional multiplexing selection for pad
0x0: Select usbb1_hsic_data
0x3: Select gpio_96
0x7: Select safe_mode <<--- pin unused


The off mode bits can be enabled continuously, the mux hardware
automatically sets them. So sounds like you don't need any
separate "idle" "sleep" and "off" states, the following should
do:

"default" (or "static") static pins that don't need to be touched
after consumer driver probe

"active"  dynamic pins that are not a subset of
"default" needed for runtime; these pins
are the same as "idle" below, but with
different muxing or pinconf device
runtime

"idle"dynamic pins that are not a subset of
"default" needed for various idle modes;
these pins are the same as "active" above,
but with different muxing or pinconf for
various idle states

Can you please confirm that these named modes are enough for
your needs?

 Confirm )


If your hardware does not have specific off mode bits, then
I can understand that you may need one mor state "off".

Regards,

Tony



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

Re: [PATCH] mmc: omap: remove unnecessary #if 0's

[Chris Ball]

Hi Luciano,

On Thu, Jun 13 2013, Luciano Coelho wrote:
> In commit 3451c067 (mmc: omap: add DMA engine support), some #if 0's
> were used to comment out parts of the code.  This has been in the code
> for over a year and are not needed anymore (and the commented-out code
> doesn't even compile).  Remove them.
>
> Signed-off-by: Luciano Coelho 

Thanks, pushed to mmc-next for 3.11.

- Chris.
-- 
Chris Ball  
One Laptop Per Child
--
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: [RFC PATCH 4/6] USB: ehci-omap: Suspend the controller during bus suspend

[Alan Stern]

On Wed, 26 Jun 2013, Roger Quadros wrote:

> > Could the mapping be changed so that a different interrupt vector was 
> > used for wakeups and normal I/O?  That would make this a little easier, 
> > although it wouldn't solve the general problem.
> 
> I'm not sure which IRQ we can map it to, but it could be mapped to some
> free IRQ number. Since it doesn't make things easier, I think we can leave
> it as it is for now.

All right.

> > There's still a race problem.  Suppose a normal wakeup interrupt occurs
> > just before or as the controller gets suspended.  By the time the code
> > here runs, HCD_HW_ACCESSIBLE may have been cleared by the suspend
> > routine.  The interrupt would be lost.  Depending on the design of the
> > controller, the entire wakeup signal could end up getting lost as well.
> 
> But if I call ehci_suspend() in the runtime_suspend handler, this race
> won't happen right?

That race doesn't apply to your system anyway; it matters only on 
systems where hcd->has_wakeup_irq isn't set.  The only way to fix it 
involves changing ehci_suspend() somewhat (and making the equivalent 
change for other HCDs too).  Those musings above were just me thinking 
out loud about the problems involved in implementing reliable wakeups.

> > Do you know how the OMAP EHCI controller behaves?  Under what 
> > conditions does it send the wakeup IRQ?  How do you tell it to turn off 
> > the wakeup IRQ?
> 
> Once the controller is suspended, the wakeup IRQ comes out-of-band. i.e. 
> through
> pad wakeup and pinctrl subsystem.
> The only way to turn that wakeup off is to disable the wakeup enable bit on 
> the pad.
> This could be done by not putting the pins in the IDLE_WAKEUP state during
> suspend.

That's not what I meant.  Never mind the pinctrl; I was asking about
the EHCI controller itself.  Under what circumstances does the
controller assert its wakeup signal?  And how do you tell it to stop
asserting that signal?

> Thanks for the review.
> 
> I updated the ehci-omap.c driver to call ehci_suspend/resume during 
> runtime_suspend/resume.
> After that, it stopped detecting the port status change event when a device 
> was plugged
> to an external HUB. The wakeup irq was coming and the root hub/controller 
> were being resumed,
> but after that, no hub_irq.

Wait a minute.  I'm not clear on what happened.  You're starting out
with the controller, the root hub, and the external hub all suspended, 
right?  Then you plugged a new device into the external hub.  This 
caused the controller and the root hub to wake up, but not the external 
hub?

> Adding some delay (or printk) somewhere in the resume path fixes the issue. 
> I'm not sure what
> is going on and why the delay is needed. Below is the ehci-omap patch. I've 
> put the delay
> in the runtime_resume handler.
> 
> e.g. log
> 
> [8.674377] usb usb1: usb wakeup-resume
> [8.678833] ehci-omap 48064800.ehci: omap_ehci_runtime_resume
> [8.695190] usb usb1: usb auto-resume
> [8.699066] ehci-omap 48064800.ehci: resume root hub
> [8.704437] hub 1-0:1.0: hub_resume
> [8.708312] hub 1-0:1.0: port 2: status 0507 change 
> [8.714630] hub 1-0:1.0: state 7 ports 3 chg  evt 
> 
> < gets stuck here in the failing case>
> 
> [8.723541] hub 1-0:1.0: state 7 ports 3 chg  evt 0004
> [8.729400] ehci-omap 48064800.ehci: GetStatus port:2 status 001005 0  ACK 
> POWER sig=se0 PE CONNECT
> [8.753204] usb 1-2: usb wakeup-resume
> [8.757293] usb 1-2: finish resume
> [8.761627] hub 1-2:1.0: hub_resume

Yeah, we need more debugging info.  In ehci_irq(), right after the
"pstatus = ehci_readl(..." line, what is the value of pstatus?  And in
the GetPortStatus case of ehci_hub_control(), right after the "temp =
ehci_readl(..." line, what is the value of temp?

> @@ -286,15 +293,70 @@ static const struct of_device_id omap_ehci_dt_ids[] = {
>  
>  MODULE_DEVICE_TABLE(of, omap_ehci_dt_ids);
>  
> +static int omap_ehci_suspend(struct device *dev)
> +{
> + struct usb_hcd *hcd = dev_get_drvdata(dev);
> + bool do_wakeup = device_may_wakeup(dev);
> +
> + dev_dbg(dev, "%s: do_wakeup: %d\n", __func__, do_wakeup);
> +
> + return ehci_suspend(hcd, do_wakeup);
> +}
> +
> +static int omap_ehci_resume(struct device *dev)
> +{
> + struct usb_hcd *hcd = dev_get_drvdata(dev);
> +
> + dev_dbg(dev, "%s\n", __func__);
> +
> + return ehci_resume(hcd, false);
> +}

Those two routines look okay.

> +static int omap_ehci_runtime_suspend(struct device *dev)
> +{
> + struct usb_hcd *hcd = dev_get_drvdata(dev);
> + struct omap_hcd *omap = (struct omap_hcd *)hcd_to_ehci(hcd)->priv;
> + bool do_wakeup = device_may_wakeup(dev);
> +
> + dev_dbg(dev, "%s\n", __func__);
> +
> + if (omap->initialized)
> + ehci_suspend(hcd, do_wakeup);

Here you should not use do_wakeup.  The second argument should always
be "true", because wakeup is always enabled during runtime suspend.

Also, why do you 

Re: omap4 ehci sporadic resume issue

[Roger Quadros]

+Ruslan

On 06/27/2013 05:17 PM, Michael Trimarchi wrote:
> Hi Roger
> 
> On Thu, Jun 27, 2013 at 04:59:38PM +0300, Roger Quadros wrote:
>> Hi Michael,
>>
>> On 06/27/2013 02:51 PM, Michael Trimarchi wrote:
>>> Hi
>>>
>>> I'm working on omap4460 with two ulpi connected to (SMSC3320 -> HUB 
>>> SMSC2514) or (TUSB1210 -> HUB SMSC2514). 
>>> The problem only happen when both port are used and after few suspend 
>>> resume are triggered.
>>> If I use just one port there is no issue on suspend resume. I already 
>>> covered all TI
>>> errata that I know and I'm working on TI kernel.
>>>
>>> The problem is here
>>>
>>> [   77.701934] ehci-omap ehci-omap.0: irq status a004 Async Recl PCD
>>>
>>> Both ports change status from 001005 to 001009 (you have a log just after). 
>>> So from host point of view both hub connected are not working in HS mode. 
>>> After that the omap ehci has gone because the bus can not work in FS and LS 
>>> and I can not recover from here.
>>> Status of transceivers are dumped and they are ok after resume.
>>>
>>> Do you have any suggestion?
>>
>> I'm not very sure but both ports suddenly changing state like that look like
>> a hardware issue. Also, it is strange that you can reproduce it only when two
>> ports are simultaneously in use. Unfortunately, I can't match your setup 
>> with 2 ULPI
> 
> Yes I know that TI doesn't have any setup like that.
> 
>> ports.
>>
>> I have a OMAP5 uEVM that uses 2 ports but it won't be identical to your 
>> setup as
>> they are on HSIC and not ULPI.
>>
>> Did you try errata i693?
> 
> Yes I have it. It's not clear if I need to wait after
> ehci_writel(ehci, temp | PORT_SUSPEND, status_reg);
> polling the suspendM of the SMSC or the suspend status of the PORT or I can
> switch just after this instruction. Because TI kernel use an msleep of 4 
> mseconds and then switch. It could be a timing issue on how errata is 
> implemented when I have two ports? How this internal count works?


The OMAP EHCI controller transparently sets the suspendM bit of the PHY when you
set the PORT_SUSPEND feature on the EHCI port. So you don't need to poll for 
anything.

What the errata says is that once software sets the PORT_SUSPEND feature, the 
PHY will
got into suspend and cut the PHY clock sooner than required for the EHCI 
controller to
complete its suspend operations. (NOTE: this is only applicable when the PHY is 
providing the
ulpi_clk).

What the workaround does is to just wait for a while (don't know why 4ms), and 
remux the
ulpi_clock to an internal 60MHz clock for a while so that it can complete its 
suspend operations.

> 
> First time is 18, and then?
>
I think it is 18 for every port suspend.
 
>>
>> Also, are you suspending and resuming only the USB or the entire system?
>>
> 
> Whole system. Right the only susbsytem that doens't go to suspend is the FSUSB
> but this depends on the bootloader.

OK. 

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: [RFC] ARM: OMAP2+: omap_device: add pinctrl handling

[Tony Lindgren]

* Grygorii Strashko  [130627 07:12]:
> 
> As you can see, from 12 pins only 3 pins need to be reconfigured
> while switching from "active"->"idle" states and back (and as I
> mentioned above for OMAP "idle" == "sleep" now).
> 
> Regarding "OFF" state:
> OMAP mux HW defines special state for unused pins which is selected
> by default after reset and need to be selected when device isn't
> used, for example:
> _MUXMODE - Functional multiplexing selection for pad
> 0x0: Select usbb1_hsic_data
> 0x3: Select gpio_96
> 0x7: Select safe_mode <<--- pin unused

The off mode bits can be enabled continuously, the mux hardware
automatically sets them. So sounds like you don't need any
separate "idle" "sleep" and "off" states, the following should
do:

"default" (or "static") static pins that don't need to be touched
after consumer driver probe

"active"dynamic pins that are not a subset of
"default" needed for runtime; these pins
are the same as "idle" below, but with
different muxing or pinconf device
runtime

"idle"  dynamic pins that are not a subset of
"default" needed for various idle modes;
these pins are the same as "active" above,
but with different muxing or pinconf for
various idle states

Can you please confirm that these named modes are enough for
your needs?

If your hardware does not have specific off mode bits, then
I can understand that you may need one mor state "off".

Regards,

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

Re: omap4 ehci sporadic resume issue

[Michael Trimarchi]

Hi Roger

On Thu, Jun 27, 2013 at 04:59:38PM +0300, Roger Quadros wrote:
> Hi Michael,
> 
> On 06/27/2013 02:51 PM, Michael Trimarchi wrote:
> > Hi
> > 
> > I'm working on omap4460 with two ulpi connected to (SMSC3320 -> HUB 
> > SMSC2514) or (TUSB1210 -> HUB SMSC2514). 
> > The problem only happen when both port are used and after few suspend 
> > resume are triggered.
> > If I use just one port there is no issue on suspend resume. I already 
> > covered all TI
> > errata that I know and I'm working on TI kernel.
> > 
> > The problem is here
> > 
> > [   77.701934] ehci-omap ehci-omap.0: irq status a004 Async Recl PCD
> > 
> > Both ports change status from 001005 to 001009 (you have a log just after). 
> > So from host point of view both hub connected are not working in HS mode. 
> > After that the omap ehci has gone because the bus can not work in FS and LS 
> > and I can not recover from here.
> > Status of transceivers are dumped and they are ok after resume.
> > 
> > Do you have any suggestion?
> 
> I'm not very sure but both ports suddenly changing state like that look like
> a hardware issue. Also, it is strange that you can reproduce it only when two
> ports are simultaneously in use. Unfortunately, I can't match your setup with 
> 2 ULPI

Yes I know that TI doesn't have any setup like that.

> ports.
> 
> I have a OMAP5 uEVM that uses 2 ports but it won't be identical to your setup 
> as
> they are on HSIC and not ULPI.
> 
> Did you try errata i693?

Yes I have it. It's not clear if I need to wait after
ehci_writel(ehci, temp | PORT_SUSPEND, status_reg);
polling the suspendM of the SMSC or the suspend status of the PORT or I can
switch just after this instruction. Because TI kernel use an msleep of 4 
mseconds and then switch. It could be a timing issue on how errata is 
implemented when I have two ports? How this internal count works?

First time is 18, and then?

> 
> Also, are you suspending and resuming only the USB or the entire system?
> 

Whole system. Right the only susbsytem that doens't go to suspend is the FSUSB
but this depends on the bootloader.

Michael


> cheers,
> -roger

-- 
| Michael Nazzareno Trimarchi Amarula Solutions BV |
| COO  -  Founder  Cruquiuskade 47 |
| +31(0)851119172 Amsterdam 1018 AM NL |
--
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: [RFC] ARM: OMAP2+: omap_device: add pinctrl handling

[Grygorii Strashko]

Hi Linus,
On 06/26/2013 10:31 PM, Linus Walleij wrote:

On Wed, Jun 26, 2013 at 3:20 PM, Grygorii Strashko
 wrote:


The "Sleep" pinctrl state is optional - if "sleep" state isn't defined
then "Idle" pinctrl state will be used during suspend.


Why? If we have a clear cut semantic that "idle" is for runtime
suspend, why should it be a fallback for suspend?


Seems, some misunderstanding is here :)

This is OMAP specific - for OMAP the "Idle" state is typically used, and 
"sleep" state is rather optional. Historically, three states have been 
defined for OMAP:

- "enabled"
- "idle"
- "off"

Most of OMAP drivers use Runtime PM only to manage their states - but, 
any calls to pm_runtime_xxx() helpers are redirected to *OMAP device* 
framework which physically configures power state/clocks/pins of device.


It's the usual situation, when the device is in "Active/ON" state when 
system is going to suspend, because PM runtime *do not allow* to disable 
device during system wide suspend. To workaround this, the *OMAP device* 
framework disables all active devices forcibly at .suspend_noirq() stage 
- and, at this moment, it should apply "Idle" or "Sleep" configuration 
on PINs.


I need to note here that "Sleep" state is/will be *not* used during PM 
runtime operation - it's very specific.


"off" state is used very rare now - and for the cases when device driver 
is removed or device need to completely switched off (HSI omap_hsi.c and 
RPROC remoteproc.c).


I think, In the future the OMAP pinctrl configurations would be manged 
in more flexible way then now (thanks to "pinctrl PM helpers" and you;))

- "Idle" state will be splitted to "Idle"/"sleep"
- "default" state will be splitted to "default"/"active"



You do realize that can just be turned around (as common suspend
is more widely implemented than runtime suspend) so that we
could say that if "idle" does not exist, we go to "sleep" in
runtime suspend.


So, final list of default pnctrl states may be defined as "default",
"active", "idle", "sleep", "off":
- "active", "idle", "sleep": will be handled by omap_device core
- "default", "off": will be handled by driver itself (or Device core).


Currently the pinctrl system combines what is called "default"
and "active" into one, assuming that all devices shall come up
in the active state.

Also we haven't seen a device that need some "off" state that
is different from "sleep".

If you want to drive this state list home you have to give a
*real world example*.

I want to see a *real* example, for a device and it's pins,
that define totally different things for these states, as a
rationale.

Else we are just defining states to make nice figures or mental
maps and that is not helpful for drivers writers.
OK. Please pay attention to the following example (taken from TI Android 
product kernel 3.4 - need to have the same in mainline kernel):

static const struct omap_device_pad port1_phy_pads[] __initconst = {
{
.name = "usbb1_ulpitll_stp.usbb1_ulpiphy_stp",
.flags  = OMAP_DEVICE_PAD_REMUX,
.enable = OMAP_PIN_OUTPUT | OMAP_MUX_MODE4,
.idle = OMAP_PIN_INPUT_PULLDOWN | OMAP_MUX_MODE7,
.off = OMAP_PIN_OFF_OUTPUT_LOW | OMAP_MUX_MODE7,
},
{
.name = "usbb1_ulpitll_clk.usbb1_ulpiphy_clk",
.enable = OMAP_PIN_INPUT_PULLDOWN | OMAP_MUX_MODE4,
},
{
.name = "usbb1_ulpitll_dir.usbb1_ulpiphy_dir",
.enable = OMAP_PIN_INPUT_PULLDOWN | OMAP_MUX_MODE4,
},
{
.name = "usbb1_ulpitll_nxt.usbb1_ulpiphy_nxt",
.enable = OMAP_PIN_INPUT_PULLDOWN | OMAP_MUX_MODE4,
},
{
.name = "usbb1_ulpitll_dat0.usbb1_ulpiphy_dat0",
.flags  = OMAP_DEVICE_PAD_REMUX |OMAP_DEVICE_PAD_WAKEUP,
.enable = OMAP_PIN_INPUT_PULLDOWN | OMAP_MUX_MODE4,
.idle = OMAP_PIN_INPUT_PULLDOWN | OMAP_MUX_MODE4,
},
{
.name = "usbb1_ulpitll_dat1.usbb1_ulpiphy_dat1",
.flags  = OMAP_DEVICE_PAD_REMUX |OMAP_DEVICE_PAD_WAKEUP,
.enable = OMAP_PIN_INPUT_PULLDOWN | OMAP_MUX_MODE4,
.idle = OMAP_PIN_INPUT_PULLDOWN | OMAP_MUX_MODE4,
},
{
.name = "usbb1_ulpitll_dat2.usbb1_ulpiphy_dat2",
.enable = OMAP_PIN_INPUT_PULLDOWN | OMAP_MUX_MODE4,
},
{
.name = "usbb1_ulpitll_dat3.usbb1_ulpiphy_dat3",
.enable = OMAP_PIN_INPUT_PULLDOWN | OMAP_MUX_MODE4,
},
{
.name = "usbb1_ulpitll_dat4.usbb1_ulpiphy_dat4",
.enable = OMAP_PIN_INPUT_PULLDOWN | OMAP_MUX_MODE4,
},
{
.name = "usbb1_ulpitll_dat5.usbb1_ulpiphy_dat5",
.enable = OMAP_PIN_INPUT_PULLDOWN | OMAP_MUX_MODE4,
},
{
.name = "usbb1_ulpitll_dat6.usbb1_u

Re: omap4 ehci sporadic resume issue

[Roger Quadros]

Hi Michael,

On 06/27/2013 02:51 PM, Michael Trimarchi wrote:
> Hi
> 
> I'm working on omap4460 with two ulpi connected to (SMSC3320 -> HUB SMSC2514) 
> or (TUSB1210 -> HUB SMSC2514). 
> The problem only happen when both port are used and after few suspend resume 
> are triggered.
> If I use just one port there is no issue on suspend resume. I already covered 
> all TI
> errata that I know and I'm working on TI kernel.
> 
> The problem is here
> 
> [   77.701934] ehci-omap ehci-omap.0: irq status a004 Async Recl PCD
> 
> Both ports change status from 001005 to 001009 (you have a log just after). 
> So from host point of view both hub connected are not working in HS mode. 
> After that the omap ehci has gone because the bus can not work in FS and LS 
> and I can not recover from here.
> Status of transceivers are dumped and they are ok after resume.
> 
> Do you have any suggestion?

I'm not very sure but both ports suddenly changing state like that look like
a hardware issue. Also, it is strange that you can reproduce it only when two
ports are simultaneously in use. Unfortunately, I can't match your setup with 2 
ULPI
ports.

I have a OMAP5 uEVM that uses 2 ports but it won't be identical to your setup as
they are on HSIC and not ULPI.

Did you try errata i693?

Also, are you suspending and resuming only the USB or the entire system?

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] Documentation: dt: bindings: TI WiLink modules

[Nishanth Menon]

On Thu, Jun 27, 2013 at 8:30 AM, Luciano Coelho  wrote:
> On Thu, 2013-06-27 at 08:23 -0500, Nishanth Menon wrote:
>> On 06/27/2013 08:19 AM, Luciano Coelho wrote:
>> > On Thu, 2013-06-27 at 08:15 -0500, Nishanth Menon wrote:
>> >> On Thu, Jun 27, 2013 at 7:58 AM, Luciano Coelho  wrote:
>> >>> For the actual DTS files, I could add a wilink.dtsi with enumerations
>> >>> for these values so they could be used in the node definitions.  But I'm
>> >>> not sure it's going to be that valuable in the end.
>> >> The  way GPIO HIGH was defined might help to provide guidance I think :)
>> >
>> > Where? As far as I can see, the GPIO flags are defined in a bitmap.
>>
>> include/dt-bindings/gpio/gpio.h
>
> Thanks! I don't see these macros used anywhere, though.
umm... I'd think you have'nt looked deep enough / lists :)

>
>> And corresponding kernel header:
>> include/linux/of_gpio.h
>
> This seems to be a completely different thing.  This is the header that
> contains the helper functions to get GPIO-related device tree nodes,
> isn't it?
That is true, but it also contains the flag for level which needs to
be in sync with the gpio.h dts header.
>> just a hint. not saying frequencies were defined in header. for systems
>> that define frequencies - example cpufreq OPPs, clock node usage, we do
>> not use indexing to frequency, instead, that is the responsibility of
>> driver to convert frequency back to required index.
>> git grep frequency Documentation/devicetree/bindings gives you how the
>> precedence looks like.
>>
>> Personally, if given a choice, I'd go with actual frequencies rather
>> than indexes.
>
> If I do that, I need to add also a separate flag to define whether the
> XTAL clock is used or not.  For instance, we have 26MHz and 26MHz
> crystal; and 38.4MHz and 38.4MHz crystal...
Yes, you would have to. at the same time, it is easy for module maker
to provide dtsi corresponding to exact h/w representation on his
module using wilink chip without being worried about weird index value
whose meaning is hidden in binding
On the flip side, It also allows driver to reject frequencies /
configurations that are not supported by the corresponding chip.

As I said, just my 2 cents. Personally, I'd like dts files to be as
readable as c files without having to dig through bindings document.

Regards,
Nishanth Menon
--
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] Documentation: dt: bindings: TI WiLink modules

[Luciano Coelho]

On Thu, 2013-06-27 at 08:23 -0500, Nishanth Menon wrote:
> On 06/27/2013 08:19 AM, Luciano Coelho wrote:
> > On Thu, 2013-06-27 at 08:15 -0500, Nishanth Menon wrote:
> >> On Thu, Jun 27, 2013 at 7:58 AM, Luciano Coelho  wrote:
> >>> For the actual DTS files, I could add a wilink.dtsi with enumerations
> >>> for these values so they could be used in the node definitions.  But I'm
> >>> not sure it's going to be that valuable in the end.
> >> The  way GPIO HIGH was defined might help to provide guidance I think :)
> >
> > Where? As far as I can see, the GPIO flags are defined in a bitmap.
> 
> include/dt-bindings/gpio/gpio.h

Thanks! I don't see these macros used anywhere, though.

> And corresponding kernel header:
> include/linux/of_gpio.h

This seems to be a completely different thing.  This is the header that
contains the helper functions to get GPIO-related device tree nodes,
isn't it?


> just a hint. not saying frequencies were defined in header. for systems 
> that define frequencies - example cpufreq OPPs, clock node usage, we do 
> not use indexing to frequency, instead, that is the responsibility of 
> driver to convert frequency back to required index.
> git grep frequency Documentation/devicetree/bindings gives you how the 
> precedence looks like.
> 
> Personally, if given a choice, I'd go with actual frequencies rather 
> than indexes.

If I do that, I need to add also a separate flag to define whether the
XTAL clock is used or not.  For instance, we have 26MHz and 26MHz
crystal; and 38.4MHz and 38.4MHz crystal...

--
Luca.

--
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] Documentation: dt: bindings: TI WiLink modules

[Nishanth Menon]

On 06/27/2013 08:19 AM, Luciano Coelho wrote:

On Thu, 2013-06-27 at 08:15 -0500, Nishanth Menon wrote:

On Thu, Jun 27, 2013 at 7:58 AM, Luciano Coelho  wrote:

For the actual DTS files, I could add a wilink.dtsi with enumerations
for these values so they could be used in the node definitions.  But I'm
not sure it's going to be that valuable in the end.

The  way GPIO HIGH was defined might help to provide guidance I think :)


Where? As far as I can see, the GPIO flags are defined in a bitmap.


include/dt-bindings/gpio/gpio.h
And corresponding kernel header:
include/linux/of_gpio.h

just a hint. not saying frequencies were defined in header. for systems 
that define frequencies - example cpufreq OPPs, clock node usage, we do 
not use indexing to frequency, instead, that is the responsibility of 
driver to convert frequency back to required index.
git grep frequency Documentation/devicetree/bindings gives you how the 
precedence looks like.


Personally, if given a choice, I'd go with actual frequencies rather 
than indexes.


--
Regards,
Nishanth Menon
--
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: [RFC] am33xx: create child nodes for the two musb controllers

[Felipe Balbi]

On Thu, Jun 27, 2013 at 01:23:59PM +0200, Benoit Cousson wrote:
> Hi Sebastian,
> 
> On 06/26/2013 05:33 PM, Sebastian Andrzej Siewior wrote:
> > I've been thinkig about creating two child nodes for the independent musb
> > controllers on the am33. I've been thinking about the following:
> > 
> > diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
> > index 8e1248f..6aa9506 100644
> > --- a/arch/arm/boot/dts/am33xx.dtsi
> > +++ b/arch/arm/boot/dts/am33xx.dtsi
> > @@ -326,21 +326,78 @@
> > status = "disabled";
> > };
> >  
> > usb@4740 {
> > compatible = "ti,musb-am33xx";
> > -   reg = <0x4740 0x1000/* usbss */
> > -  0x47401000 0x800 /* musb instance 0 */
> > -  0x47401800 0x800>;   /* musb instance 1 */
> > -   interrupts = <17/* usbss */
> > - 18/* musb instance 0 */
> > - 19>;  /* musb instance 1 */
> > -   multipoint = <1>;
> > -   num-eps = <16>;
> > -   ram-bits = <12>;
> > -   port0-mode = <3>;
> > -   port1-mode = <3>;
> > -   power = <250>;
> > +   reg = <0x4740 0x1000>;  /* usbss */
> > +   interrupts = <17>;  

trailing whitespaces here

> BTW, why do have so many DMA compared to the previous version?
> /* usbss */
> > ti,hwmods = "usb_otg_hs";
> > +
> > +   usb0@0x47401000 {
> > +   reg = <0x47401000 0x800>;   /* musb 
> > instance 0 */
> > +   interrupts = <18>;  /* musb 
> > instance 0 */
> > +   multipoint = <1>;
> > +   num-eps = <16>;
> > +   ram-bits = <12>;
> > +   port-mode = <3>;
> > +   power = <250>;
> > +
> > +   phys = <&nopphy0>;
> > +   dmas = <&cppi41dma 0
> > +   &cppi41dma 1
> > +   &cppi41dma 2
> > +   &cppi41dma 3
> > +   &cppi41dma 4
> > +   &cppi41dma 32
> > +   &cppi41dma 34
> > +   &cppi41dma 36
> > +   &cppi41dma 38
> > +   &cppi41dma 40>;
> > +   dma-names = "rx1", "rx2", "rx3", "rx4", "rx5",
> > +   "tx1", "tx2", "tx3", "tx4", "tx5";
> > +   };
> > +
> > +   usb0@0x47401800 {
> > +   reg = <0x47401800 0x800>;   /* musb 
> > instance 1 */
> > +   interrupts = <19>;  /* musb 
> > instance 1 */
> > +   multipoint = <1>;
> > +   num-eps = <16>;
> > +   ram-bits = <12>;
> > +   port-mode = <3>;
> > +   power = <250>;
> > +
> > +   phys = <&nopphy1>;
> > +   dmas = <&cppi41dma 0
> > +   &cppi41dma 1
> > +   &cppi41dma 2
> > +   &cppi41dma 3
> > +   &cppi41dma 4
> > +   &cppi41dma 62
> > +   &cppi41dma 64
> > +   &cppi41dma 66
> > +   &cppi41dma 68
> > +   &cppi41dma 70>;
> > +   dma-names = "rx1", "rx2", "rx3", "rx4", "rx5",
> > +   "tx1", "tx2", "tx3", "tx4", "tx5";
> > +   };
> > +   };
> > 
> > Please keep in mind that his is not a proper patch it should point out
> > what I have in mind.
> > This would easy the for instance the dma channel assignment. Also, it will
> > move back to the port-mode property instead of portX-mode one which it has
> > now. This is kind of confusing since it is not a root hub or anything like
> > that it is a complete musb controller. Plus for the phys property could
> > easily take the one avaible and would not require which instance it
> > really it is.
> 
> I don't know the HW in detail, but that looks indeed much better and
> seems to reflect the partitioning with multiple instances accurately.
> 
> If Felipe is OK with that partitioning, I'll take it.

it's alright with me

Acked-by: Felipe Balbi 

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH] Documentation: dt: bindings: TI WiLink modules

[Luciano Coelho]

On Thu, 2013-06-27 at 08:15 -0500, Nishanth Menon wrote:
> On Thu, Jun 27, 2013 at 7:58 AM, Luciano Coelho  wrote:
> > For the actual DTS files, I could add a wilink.dtsi with enumerations
> > for these values so they could be used in the node definitions.  But I'm
> > not sure it's going to be that valuable in the end.
> The  way GPIO HIGH was defined might help to provide guidance I think :)

Where? As far as I can see, the GPIO flags are defined in a bitmap.

--
Luca.

--
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 linux-next] ARM: OMAP2+: fix omap4-restart compilation

[Nishanth Menon]

On 06/27/2013 07:26 AM, Vincent Stehlé wrote:

Fix following compilation error due to missing include file:

   arch/arm/mach-omap2/omap4-restart.c:21:28: warning: ‘enum reboot_mode’ 
declared inside parameter list [enabled by default]
   arch/arm/mach-omap2/omap4-restart.c:21:28: warning: its scope is only this 
definition or declaration, which is probably not what you want [enabled by 
default]
   arch/arm/mach-omap2/omap4-restart.c:21:40: error: parameter 1 (‘mode’) has 
incomplete type
   arch/arm/mach-omap2/omap4-restart.c:21:6: warning: function declaration 
isn’t a prototype [-Wstrict-prototypes]
   make[1]: *** [arch/arm/mach-omap2/omap4-restart.o] Error 1

Signed-off-by: Vincent Stehlé 
Cc: Robin Holt 
Cc: Russell King 
Cc: Tony Lindgren 
Cc: triv...@kernel.org
---


Hi,

This fixes the build of linux-next for arch ARM, config multi_v7_defconfig, tag
next-20130627.

Best regards,

V.


  arch/arm/mach-omap2/omap4-restart.c |1 +
  1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-omap2/omap4-restart.c 
b/arch/arm/mach-omap2/omap4-restart.c
index 652adde..41dfd7d 100644
--- a/arch/arm/mach-omap2/omap4-restart.c
+++ b/arch/arm/mach-omap2/omap4-restart.c
@@ -8,6 +8,7 @@
   */

  #include 
+#include 
  #include "prminst44xx.h"

  /**


Same was covered already?
http://lists.infradead.org/pipermail/linux-arm-kernel/2013-June/178209.html

--
Regards,
Nishanth Menon
--
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] Documentation: dt: bindings: TI WiLink modules

[Nishanth Menon]

On Thu, Jun 27, 2013 at 7:58 AM, Luciano Coelho  wrote:
> On Thu, 2013-06-27 at 07:51 -0500, Nishanth Menon wrote:
>> On 11:47-20130627, Luciano Coelho wrote:
>> > (added mailing lists and everyone back to the thread)
>> >
>> > On Wed, 2013-06-26 at 23:38 -0500, Nishanth Menon wrote:
>> > > On 06/25/2013 03:35 AM, Luciano Coelho wrote:
>> > > > +Optional properties:
>> > > > +
>> > > > +
>> > > > +- refclock: the internal WLAN reference clock frequency (required for
>> > > > +  WiLink6 and WiLink7; not used for WiLink8).  Must be one of the
>> > > > +  following:
>> > > > +   0 = 19.2 MHz
>> > > > +   1 = 26.0 MHz
>> > > > +   2 = 38.4 MHz
>> > > > +   3 = 52.0 MHz
>> > > > +   4 = 38.4 MHz, XTAL
>> > > > +   5 = 26.0 MHz, XTAL
>> > > > +
>> > > > +- tcxoclock: the internal WLAN TCXO clock frequency (required for
>> > > > +  WiLink7 not used for WiLink6 and WiLink8).  Must be one of the
>> > > > +  following:
>> > > > +   0 = 19.200 MHz
>> > > > +   1 = 26.000 MHz
>> > > > +   2 = 38.400 MHz
>> > > > +   3 = 52.000 MHz
>> > > > +   4 = 16.368 MHz
>> > > > +   5 = 32.736 MHz
>> > > > +   6 = 16.800 MHz
>> > > > +   7 = 33.600 MHz
>> > > >
>> > > just a gentle query - why not use frequency itself here in Hz for
>> > > refclock and txoclk?
>> >
>> > I thought about using the actual frequencies, but I decided not to do
>> > so, because I'd have to convert them to these values anyway.  These
>> > values are used to configure the firmware and it uses these
>> > "enumerations".
>> Could we not hide this under preprocessor macros instead? just wondering
>> of txoclock = <6>; kind of usage.. easy to make mistakes and easier to
>> confuse a new reader :).
>
> Yes, I guess we could create some preprocessor macros for this.  But the
> documentation would remain the same.  I can't add preprocessor macros to
> the bindings documentation. ;)
>
> For the actual DTS files, I could add a wilink.dtsi with enumerations
> for these values so they could be used in the node definitions.  But I'm
> not sure it's going to be that valuable in the end.
The  way GPIO HIGH was defined might help to provide guidance I think :)

Regards,
NM
--
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] Documentation: dt: bindings: TI WiLink modules

[Luciano Coelho]

On Thu, 2013-06-27 at 07:51 -0500, Nishanth Menon wrote:
> On 11:47-20130627, Luciano Coelho wrote:
> > (added mailing lists and everyone back to the thread)
> > 
> > On Wed, 2013-06-26 at 23:38 -0500, Nishanth Menon wrote:
> > > On 06/25/2013 03:35 AM, Luciano Coelho wrote:
> > > > +Optional properties:
> > > > +
> > > > +
> > > > +- refclock: the internal WLAN reference clock frequency (required for
> > > > +  WiLink6 and WiLink7; not used for WiLink8).  Must be one of the
> > > > +  following:
> > > > +   0 = 19.2 MHz
> > > > +   1 = 26.0 MHz
> > > > +   2 = 38.4 MHz
> > > > +   3 = 52.0 MHz
> > > > +   4 = 38.4 MHz, XTAL
> > > > +   5 = 26.0 MHz, XTAL
> > > > +
> > > > +- tcxoclock: the internal WLAN TCXO clock frequency (required for
> > > > +  WiLink7 not used for WiLink6 and WiLink8).  Must be one of the
> > > > +  following:
> > > > +   0 = 19.200 MHz
> > > > +   1 = 26.000 MHz
> > > > +   2 = 38.400 MHz
> > > > +   3 = 52.000 MHz
> > > > +   4 = 16.368 MHz
> > > > +   5 = 32.736 MHz
> > > > +   6 = 16.800 MHz
> > > > +   7 = 33.600 MHz
> > > >
> > > just a gentle query - why not use frequency itself here in Hz for 
> > > refclock and txoclk?
> > 
> > I thought about using the actual frequencies, but I decided not to do
> > so, because I'd have to convert them to these values anyway.  These
> > values are used to configure the firmware and it uses these
> > "enumerations".
> Could we not hide this under preprocessor macros instead? just wondering
> of txoclock = <6>; kind of usage.. easy to make mistakes and easier to
> confuse a new reader :).

Yes, I guess we could create some preprocessor macros for this.  But the
documentation would remain the same.  I can't add preprocessor macros to
the bindings documentation. ;)

For the actual DTS files, I could add a wilink.dtsi with enumerations
for these values so they could be used in the node definitions.  But I'm
not sure it's going to be that valuable in the end.

--
Luca.

--
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] Documentation: dt: bindings: TI WiLink modules

[Nishanth Menon]

On 11:47-20130627, Luciano Coelho wrote:
> (added mailing lists and everyone back to the thread)
> 
> On Wed, 2013-06-26 at 23:38 -0500, Nishanth Menon wrote:
> > On 06/25/2013 03:35 AM, Luciano Coelho wrote:
> > > +Optional properties:
> > > +
> > > +
> > > +- refclock: the internal WLAN reference clock frequency (required for
> > > +  WiLink6 and WiLink7; not used for WiLink8).  Must be one of the
> > > +  following:
> > > + 0 = 19.2 MHz
> > > + 1 = 26.0 MHz
> > > + 2 = 38.4 MHz
> > > + 3 = 52.0 MHz
> > > + 4 = 38.4 MHz, XTAL
> > > + 5 = 26.0 MHz, XTAL
> > > +
> > > +- tcxoclock: the internal WLAN TCXO clock frequency (required for
> > > +  WiLink7 not used for WiLink6 and WiLink8).  Must be one of the
> > > +  following:
> > > + 0 = 19.200 MHz
> > > + 1 = 26.000 MHz
> > > + 2 = 38.400 MHz
> > > + 3 = 52.000 MHz
> > > + 4 = 16.368 MHz
> > > + 5 = 32.736 MHz
> > > + 6 = 16.800 MHz
> > > + 7 = 33.600 MHz
> > >
> > just a gentle query - why not use frequency itself here in Hz for 
> > refclock and txoclk?
> 
> I thought about using the actual frequencies, but I decided not to do
> so, because I'd have to convert them to these values anyway.  These
> values are used to configure the firmware and it uses these
> "enumerations".
Could we not hide this under preprocessor macros instead? just wondering
of txoclock = <6>; kind of usage.. easy to make mistakes and easier to
confuse a new reader :).

just my 2 cents.
> 
> 
> > might not another option of using
> > node {
> > clocks=<&clk>;
> > }
> > 
> > Usually refclock is an external clock source, no?
> 
> No.  In the WiLink case, both refclock and tcxoclock are internal
> clocks.  They are in the module itself and what we need to do is tell
> the WiLink chip what the module's clocks look like.
> 
> 
> > the above allows you to do an devm_clk_get and clk_get_rate() to figure 
> > out the exact clock frequency.
> 
> No, we can't use these calls, because they are internal clocks.
> 
> Please see my more complete explanation as an answer to Tony's email.
K thanks.
> 
> Thanks for your review!

Glad to be of help.

-- 
Regards,
Nishanth Menon
--
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 linux-next] ARM: OMAP2+: fix omap4-restart compilation

[Vincent Stehlé]

Fix following compilation error due to missing include file:

  arch/arm/mach-omap2/omap4-restart.c:21:28: warning: ‘enum reboot_mode’ 
declared inside parameter list [enabled by default]
  arch/arm/mach-omap2/omap4-restart.c:21:28: warning: its scope is only this 
definition or declaration, which is probably not what you want [enabled by 
default]
  arch/arm/mach-omap2/omap4-restart.c:21:40: error: parameter 1 (‘mode’) has 
incomplete type
  arch/arm/mach-omap2/omap4-restart.c:21:6: warning: function declaration isn’t 
a prototype [-Wstrict-prototypes]
  make[1]: *** [arch/arm/mach-omap2/omap4-restart.o] Error 1

Signed-off-by: Vincent Stehlé 
Cc: Robin Holt 
Cc: Russell King 
Cc: Tony Lindgren 
Cc: triv...@kernel.org
---


Hi,

This fixes the build of linux-next for arch ARM, config multi_v7_defconfig, tag
next-20130627.

Best regards,

V.


 arch/arm/mach-omap2/omap4-restart.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-omap2/omap4-restart.c 
b/arch/arm/mach-omap2/omap4-restart.c
index 652adde..41dfd7d 100644
--- a/arch/arm/mach-omap2/omap4-restart.c
+++ b/arch/arm/mach-omap2/omap4-restart.c
@@ -8,6 +8,7 @@
  */
 
 #include 
+#include 
 #include "prminst44xx.h"
 
 /**
-- 
1.7.10.4



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

N900 device tree conversion: next steps

[Pavel Machek]

Hi!

> > Anyway... here's my current version, and thanks for all the help. I
> > guess I'll need to figure out clocks next, because I'd really like to
> > have video going on device.
> 
> Well DSS is still using pdata based init because of the DT bindings
> are not ready yet.

Yes, I know. But as nokia already initializes DSS "by hand", that
should not be a problem.

I have something working at this point: remaining issue was that to
get display working, tsc2005 binding has to be present. (That is true
both before and after devicetree conversion).

What would be procedure for merging the patch? Would you be able to
take it in one piece, or does it need to be split somehow?

Thanks,
Pavel

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 9c62558..7b1a075 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -119,6 +119,7 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
omap3-beagle-xm.dtb \
omap3-evm.dtb \
omap3-tobi.dtb \
+   omap3-n900.dtb \
omap4-panda.dtb \
omap4-panda-a4.dtb \
omap4-panda-es.dtb \
diff --git a/arch/arm/boot/dts/omap3-n900.dts b/arch/arm/boot/dts/omap3-n900.dts
new file mode 100644
index 000..c5538a6
--- /dev/null
+++ b/arch/arm/boot/dts/omap3-n900.dts
@@ -0,0 +1,94 @@
+/*
+ * Copyright (C) 2013 Pavel Machek 
+ * Copyright 2013 Aaro Koskinen 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 (or later) as
+ * published by the Free Software Foundation.
+ */
+
+/dts-v1/;
+
+/include/ "omap34xx.dtsi"
+
+/ {
+   model = "Nokia N900";
+   compatible = "nokia,omap3-n900", "ti,omap3";
+
+   cpus {
+   cpu@0 {
+// cpu0-supply = <&vcc>;
+   };
+   };
+
+   memory {
+   device_type = "memory";
+   reg = <0x8000 0x1000>; /* 256 MB */
+   };
+
+};
+
+&i2c1 {
+   clock-frequency = <220>;
+
+   twl: twl@48 {
+   reg = <0x48>;
+   interrupts = <7>; /* SYS_NIRQ cascaded to intc */
+   interrupt-parent = <&intc>;
+   };
+};
+
+/include/ "twl4030.dtsi"
+
+&twl_gpio {
+   ti,pullups  = <0x0>;
+   ti,pulldowns= <0x03ff3f>; /* BIT(0..5) | BIT(8..17) */
+};
+
+&i2c2 {
+   clock-frequency = <40>;
+};
+
+&i2c3 {
+   clock-frequency = <10>;
+};
+
+&mmc1 {
+   status = "disabled";
+};
+
+&mmc2 {
+   status = "disabled";
+};
+
+&mmc3 {
+   status = "disabled";
+};
+
+&mcspi1 {
+   // For some reason, touchscreen is neccessary for screen to work at 
+   // all on real hw. It works well without it on emulator.
+   //
+   // Also... order in the device tree actually matters here.
+   tsc2005@0 {
+   compatible = "tsc2005";
+   spi-max-frequency = <600>;
+   reg = <0>;
+   };
+   mipid@2 {
+   compatible = "acx565akm";
+   spi-max-frequency = <600>;
+   reg = <2>;
+   // turbo_mode = 0,
+   // cs_per_word = 0
+   };
+};
+
+/*
+&usb_otg_hs {
+   interface-type = <0>;
+   usb-phy = <&usb2_phy>;
+   mode = <2>;
+   power = <50>;
+};
+*/
diff --git a/arch/arm/boot/dts/omap34xx.dtsi b/arch/arm/boot/dts/omap34xx.dtsi
new file mode 100644
index 000..75ed4ae
--- /dev/null
+++ b/arch/arm/boot/dts/omap34xx.dtsi
@@ -0,0 +1,28 @@
+/*
+ * Device Tree Source for OMAP34xx/OMAP35xx SoC
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2.  This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+/include/ "omap3.dtsi"
+
+/ {
+   cpus {
+   cpu@0 {
+   /* OMAP343x/OMAP35xx variants OPP1-5 */
+   operating-points = <
+   /* kHzuV */
+   125000   975000
+   25  1075000
+   50  120
+   55  127
+   60  135
+   >;
+   clock-latency = <30>; /* From legacy driver */
+   };
+   };
+};
diff --git a/arch/arm/mach-omap2/board-rx51-compat.c 
b/arch/arm/mach-omap2/board-rx51-compat.c
index 0ffa909..f4223ff 100644
--- a/arch/arm/mach-omap2/board-rx51-compat.c
+++ b/arch/arm/mach-omap2/board-rx51-compat.c
@@ -131,6 +131,7 @@ static long twl4030_madc_ioctl(struct file *filp, unsigned 
int cmd,
 
switch (cmd) {
case TWL4030_MADC_IOCX_ADC_RAW_READ: {
+#if 0
struct twl4030_madc_request req;
if (par.channel >= TWL4030_MADC_

Re: [PATCH 0/5] AM33xx: MMC resources from DT without HWMOD data

[Benoit Cousson]

Hi Joel,

On 06/26/2013 05:28 AM, Joel A Fernandes wrote:
> On Tue, Jun 25, 2013 at 8:23 PM, Joel A Fernandes  wrote:
>> From: Joel A Fernandes 
>>
>> This series is fixes to get MMC working on AM33XX without HWMOD data.
>> On removal of HWMOD data, interrupt and register properties need to be 
>> provided
>> for the driver to function correctly.
> 
> Please don't pull patches authored by me in this series. I have posted
> them with my wrong email address by mistake. I will correct my email
> during the next repost, after a round of review. Matt's patches in the
> series are still good though.

In that case, please repost these in two series to avoid pulling the DTS
files in the MMC tree.

Thanks,
Benoit

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

omap4 ehci sporadic resume issue

[Michael Trimarchi]

Hi

I'm working on omap4460 with two ulpi connected to (SMSC3320 -> HUB SMSC2514) 
or (TUSB1210 -> HUB SMSC2514). 
The problem only happen when both port are used and after few suspend resume 
are triggered.
If I use just one port there is no issue on suspend resume. I already covered 
all TI
errata that I know and I'm working on TI kernel.

The problem is here

[   77.701934] ehci-omap ehci-omap.0: irq status a004 Async Recl PCD

Both ports change status from 001005 to 001009 (you have a log just after). 
So from host point of view both hub connected are not working in HS mode. 
After that the omap ehci has gone because the bus can not work in FS and LS and 
I can not recover from here.
Status of transceivers are dumped and they are ok after resume.

Do you have any suggestion?

Normal case

SUSPEND

DIR HIGH
CLOCK is OFF

AFTER RESUME

DIR has signal

CLOCK is 60 Mhz

Disconnect case

SUSPEND

DIR HIGH
CLOCK is OFF

AFTER RESUME
DIR is LOW
CLOCK is 60Mhz



[   77.593566] ehci-omap ehci-omap.0: ehci_omap_bus_resume
[   77.593658] ehci-omap ehci-omap.0: resume root hub
[   77.615814] hub 2-0:1.0: hub_resume
[   77.639251] hub 1-0:1.0: hub_resume
[   77.639282] ehci-omap ehci-omap.0: GetStatus port:1 status 001885 0  ACK 
POWER sig=j SUSPEND PE CONNECT
[   77.639282] hub 1-0:1.0: port 1: status 0507 change 
[   77.639312] ehci-omap ehci-omap.0: GetStatus port:2 status 001885 0  ACK 
POWER sig=j SUSPEND PE CONNECT
[   77.639312] hub 1-0:1.0: port 2: status 0507 change 
[   77.639312] ehci-omap ehci-omap.0: GetStatus port:3 status 001000 0  ACK 
POWER sig=se0
[   77.639373] ehci-omap ehci-omap.0: GetStatus port:1 status 001885 0  ACK 
POWER sig=j SUSPEND PE CONNECT
[   77.639404] usb 1-1: usb resume
[   77.639434] ehci-omap ehci-omap.0: GetStatus port:2 status 001885 0  ACK 
POWER sig=j SUSPEND PE CONNECT
[   77.639434] usb 1-2: usb resume
[   77.678314] dump_tranceiver ---> on port 1
[   77.678314] ULPI_FUNC_CTRL 0x40
[   77.678344] ULPI_IFC_CTRL 0x00
[   77.678344] ULPI_OTG_CTRL 0x06
[   77.678344] ULPI_DEBUG 0x00
[   77.678344] ULPI_USB_INT_STS 0x14
[   77.678344] dump_tranceiver <-- on port 1
[   77.678375] ehci-omap ehci-omap.0: GetStatus port:1 status 001005 0  ACK 
POWER sig=se0 PE CONNECT
[   77.678405] dump_tranceiver ---> on port 2
[   77.678405] ULPI_FUNC_CTRL 0x40
[   77.678405] ULPI_IFC_CTRL 0x00
[   77.678436] ULPI_OTG_CTRL 0x06
[   77.678436] ULPI_DEBUG 0x00
[   77.678436] ULPI_USB_INT_STS 0x14
[   77.678436] dump_tranceiver <-- on port 2
[   77.678466] ehci-omap ehci-omap.0: GetStatus port:2 status 001005 0  ACK 
POWER sig=se0 PE CONNECT
[   77.701782] usb 1-1: finish resume
[   77.701812] usb 1-2: finish resume
[   77.701934] ehci-omap ehci-omap.0: irq status a004 Async Recl PCD
[   77.701934] Port 2 Status 0x1000
[   77.701934] Port 1 Status 0x1009
[   77.701965] Port 0 Status 0x1009
[   82.717529] ehci-omap ehci-omap.0: IAA watchdog: status a008 cmd 10065
[   82.717590] usb 1-2: kworker/u:12 timed out on ep0in len=0/2
[   82.717590] usb 1-2: gone after usb resume? status -110
[   82.717590] usb 1-2: can't resume, status -110
[   82.717620] hub 1-0:1.0: logical disconnect on port 2
[   82.717620] Disable PORT_PE
[   82.717651] pm_op(): usb_dev_resume+0x0/0x18 returns -110
[   82.717651] PM: Device 1-2 failed to resume async: error -110
[   82.733154] ehci-omap ehci-omap.0: IAA watchdog: status a008 cmd 10065
[   82.733184] usb 1-1: kworker/u:15 timed out on ep0in len=0/2
[   82.733215] usb 1-1: gone after usb resume? status -110
[   82.733215] usb 1-1: can't resume, status -110
[   82.733215] hub 1-0:1.0: logical disconnect on port 1
[   82.733215] Disable PORT_PE
[   82.733245] pm_op(): usb_dev_resume+0x0/0x18 returns -110
[   82.733245] PM: Device 1-1 failed to resume async: error -110
[   82.734741] PM: resume of devices complete after 5229.652 msecs
[   83.303863] PM: Finishing wakeup.
[   83.307525] Restarting tasks ... 
[   83.311157] hub 2-0:1.0: state 7 ports 1 chg  evt 
[   83.317504] hub 2-0:1.0: hub_resume
[   83.321716] done.
[   83.323974] suspend: exit suspend, ret = 0 (2000-01-02 21:07:12.171992466 
UTC)
[   83.323974] hub 2-0:1.0: activate --> -22
[   83.324005] hub 1-0:1.0: state 7 ports 3 chg 0006 evt 0006
[   83.324035] ehci-omap ehci-omap.0: GetStatus port:1 status 001801 0  ACK 
POWER sig=j CONNECT
[   83.324035] hub 1-0:1.0: port 1, status 0501, change , 480 Mb/s
[   83.324035] usb 1-1: USB disconnect, device number 2
[   83.324066] usb 1-1.2: USB disconnect, device number 4
[   83.324066] usb 1-1.2: unregistering device
[   83.324066] usb 1-1.2: unregistering interface 1-1.2:1.0
[   83.530700] usb 1-1.2: usb_disable_device nuking all URBs
[   83.537200] usb 1-1.3: USB disconnect, device number 5
[   83.542907] usb 1-1.3: unregistering device
[   83.547546] usb 1-1.3: unregistering interface 1-1.3:1.0
[   83.554107] usb 1-1.3: usb_disable_device nuking all URBs
[   83.560577] usb 1-1: unregistering device
[   83.56506

Re: [RFC] am33xx: create child nodes for the two musb controllers

[Sebastian Andrzej Siewior]

On 06/27/2013 01:23 PM, Benoit Cousson wrote:
> Hi Sebastian,

Hi Benoit,

> BTW, why do have so many DMA compared to the previous version?
I added them, the previous had none and is PIO only.
I currently use three cells per dma channel (the posted example had
two).
In general I think I have to request 2 * 15 dma channels for the 15 TX
and RX endpoints. So we end up with 30 channels per device (and we have
two of them).
The DMA engine has specific queues which depend on the USB endpoint
that is used. Instead of hacking this information in some kind of
platform data I decided to push this detail into device tree.

> I don't know the HW in detail, but that looks indeed much better and
> seems to reflect the partitioning with multiple instances accurately.
> 
> If Felipe is OK with that partitioning, I'll take it.

Okay, thanks.

> 
> Thanks,
> Benoit

Sebastian
--
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: [RFC] am33xx: create child nodes for the two musb controllers

[Benoit Cousson]

Hi Sebastian,

On 06/26/2013 05:33 PM, Sebastian Andrzej Siewior wrote:
> I've been thinkig about creating two child nodes for the independent musb
> controllers on the am33. I've been thinking about the following:
> 
> diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
> index 8e1248f..6aa9506 100644
> --- a/arch/arm/boot/dts/am33xx.dtsi
> +++ b/arch/arm/boot/dts/am33xx.dtsi
> @@ -326,21 +326,78 @@
>   status = "disabled";
>   };
>  
>   usb@4740 {
>   compatible = "ti,musb-am33xx";
> - reg = <0x4740 0x1000/* usbss */
> -0x47401000 0x800 /* musb instance 0 */
> -0x47401800 0x800>;   /* musb instance 1 */
> - interrupts = <17/* usbss */
> -   18/* musb instance 0 */
> -   19>;  /* musb instance 1 */
> - multipoint = <1>;
> - num-eps = <16>;
> - ram-bits = <12>;
> - port0-mode = <3>;
> - port1-mode = <3>;
> - power = <250>;
> + reg = <0x4740 0x1000>;  /* usbss */
> + interrupts = <17>;  
BTW, why do have so many DMA compared to the previous version?
/* usbss */
>   ti,hwmods = "usb_otg_hs";
> +
> + usb0@0x47401000 {
> + reg = <0x47401000 0x800>;   /* musb 
> instance 0 */
> + interrupts = <18>;  /* musb 
> instance 0 */
> + multipoint = <1>;
> + num-eps = <16>;
> + ram-bits = <12>;
> + port-mode = <3>;
> + power = <250>;
> +
> + phys = <&nopphy0>;
> + dmas = <&cppi41dma 0
> + &cppi41dma 1
> + &cppi41dma 2
> + &cppi41dma 3
> + &cppi41dma 4
> + &cppi41dma 32
> + &cppi41dma 34
> + &cppi41dma 36
> + &cppi41dma 38
> + &cppi41dma 40>;
> + dma-names = "rx1", "rx2", "rx3", "rx4", "rx5",
> + "tx1", "tx2", "tx3", "tx4", "tx5";
> + };
> +
> + usb0@0x47401800 {
> + reg = <0x47401800 0x800>;   /* musb 
> instance 1 */
> + interrupts = <19>;  /* musb 
> instance 1 */
> + multipoint = <1>;
> + num-eps = <16>;
> + ram-bits = <12>;
> + port-mode = <3>;
> + power = <250>;
> +
> + phys = <&nopphy1>;
> + dmas = <&cppi41dma 0
> + &cppi41dma 1
> + &cppi41dma 2
> + &cppi41dma 3
> + &cppi41dma 4
> + &cppi41dma 62
> + &cppi41dma 64
> + &cppi41dma 66
> + &cppi41dma 68
> + &cppi41dma 70>;
> + dma-names = "rx1", "rx2", "rx3", "rx4", "rx5",
> + "tx1", "tx2", "tx3", "tx4", "tx5";
> + };
> + };
> 
> Please keep in mind that his is not a proper patch it should point out
> what I have in mind.
> This would easy the for instance the dma channel assignment. Also, it will
> move back to the port-mode property instead of portX-mode one which it has
> now. This is kind of confusing since it is not a root hub or anything like
> that it is a complete musb controller. Plus for the phys property could
> easily take the one avaible and would not require which instance it
> really it is.

I don't know the HW in detail, but that looks indeed much better and
seems to reflect the partitioning with multiple instances accurately.

If Felipe is OK with that partitioning, I'll take it.

Thanks,
Benoit


--
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: AM35xx i2c3 issues

[Grygorii Strashko]

Hi Marc,

Could you try these patches first:
https://patchwork.kernel.org/patch/2685541/
http://patchwork.ozlabs.org/patch/252639/

Then try this patch alone:
https://patchwork.kernel.org/patch/2689171/

Also could you provide your .config?  Do you have lm75 (or any other 
hwmon devices) enabled?


-grygorii

On 06/27/2013 12:15 PM, Marc Murphy wrote:

Hi Michael,
The bus is correctly terminated with 2.2k pullups on SCL and SDA lines.

Kind Regards
Marc


From: Michael Trimarchi [mich...@amarulasolutions.com]
Sent: 27 June 2013 09:46
To: Marc Murphy
Cc: linux-omap@vger.kernel.org
Subject: Re: AM35xx i2c3 issues

Hi

On Thu, Jun 27, 2013 at 08:29:05AM +, Marc Murphy wrote:

Hello Grygorii/All,

I have been trying to address an issue I am having with 3.6rc6 kernel and even 
with the latest 3.9 and trying to use i2c3 channel on an AM3517.

I see that there has been some work done on the OMAP4 and issues with i2c which 
looks like the controller being suspended during boot.

I would like to know how I can enable the debug so I can see the messages for 
warning and debug and whether anyone has tested i2c3 channel on an AM3517 ?

I find the problem a little confusing as the system initializes the interfaces 
1-3

[0.168182] omap_i2c omap_i2c.1: bus 1 rev1.3.12 at 400 kHz
[0.169830] VDCDC1: 1200 <--> 1600 mV at 1200 mV normal
[0.169830] VDCDC1: Voltage range but no REGULATOR_CHANGE_VOLTAGE
[0.170684] VDCDC2: 3300 mV normal
[0.171264] VDCDC3: 1800 mV normal
[0.171905] LDO1: 1800 mV normal
[0.172729] LDO2: 3300 mV normal
[0.174102] omap_i2c omap_i2c.2: bus 2 rev1.3.12 at 400 kHz
[0.187530] omap_i2c omap_i2c.3: bus 3 rev1.3.12 at 400 kHz

But when it comes to probe the i2c3 interface for the mpu6050 that is connected 
it fails

[3.896606] omap_i2c omap_i2c.3: timeout waiting for bus ready
[3.902832] inv-mpu6050: probe of 3-0068 failed with error -110



Can you check if your bus is correctly pull up on the line?

Michael


If I move the mpu6050 onto the i2c2 channel it’s OK so its not an issue with 
the core omap_i2c.

I also have a scope connected to the scl line and see no activity.  I have 
proved to myself that the pin is connected and working by configuring as a GPIO 
output and toggling 0/1/0 and I can see the output changing on the scope.

The mux is configured correctly from what I can see using debugfs
#  cat /sys/kernel/debug/omap_mux/i2c3_scl
name: i2c3_scl.i2c3_scl (0x480021c2/0x192 = 0x0100), b af14, t NA
mode: OMAP_PIN_INPUT | OMAP_MUX_MODE0
signals: i2c3_scl | NA | NA | NA | gpio_184 | NA | NA | safe_mode

#  cat /sys/kernel/debug/omap_mux/i2c3_sda
name: i2c3_sda.i2c3_sda (0x480021c4/0x194 = 0x0100), b ag14, t NA
mode: OMAP_PIN_INPUT | OMAP_MUX_MODE0
signals: i2c3_sda | NA | NA | NA | gpio_185 | NA | NA | safe_mode


If I probe with i2cdetect for all 3 buses there is only an issue with i2c3
# i2cdetect -r 1
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-1 using read byte commands.
I will probe address range 0x03-0x77.
Continue? [Y/n]
  0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:  -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- UU -- -- -- -- -- -- --
50: 50 -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --

# i2cdetect -r 2
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-2 using read byte commands.
I will probe address range 0x03-0x77.
Continue? [Y/n]
  0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:  -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --

# i2cdetect -r 3
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-3 using read byte commands.
I will probe address range 0x03-0x77.
Continue? [Y/n]
  0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:  [  837.943481] omap_i2c omap_i2c.3: timeout waiting for bus ready
-- [  838.958984] omap_i2c omap_i2c.3: timeout waiting for bus ready
-- [  839.974731] omap_i2c omap_i2c.3: timeout waiting for bus ready


Any pointers/help appreciated as I have the accelerometer and RTC chip 
connected on i2c3 but cannot get anything working.

Kind Regards

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

Re: [PATCH v1 0/2] TWL6030, TWL6032 GPADC driver

[Graeme Gregory]

I suspect this will find a better home in drivers/iio that subsystem did
not exist when driver was originally written.

It would need converted to new API.

Graeme

On 27/06/13 11:43, Oleksandr Kozaruk wrote:
> Hello
>
> TWL603[02] GPADC is used to measure battery voltage,
> battery temperature, battery presence ID, and could
> be used to measure twl603[02] die temperature.
> This is used on TI blaze, blaze tablet platforms.
>
> The TWL6030 and TWL6032 have GPADC with 17 and 19
> channels respectively. Some channels have current
> source and are used for measuring voltage drop
> on resistive load for detecting battery ID resistance,
> or measuring voltage drop on NTC resistors for external
> temperature measurements. Some channels measure voltage,
> (i.e. battery voltage), and have inbuilt voltage dividers,
> thus, capable to scale voltage. Some channels are dedicated
> for measuring die temperature.
>
> Some channels could be calibrated in 2 points, having
> offsets from ideal values in trim registers.
>
> The difference between GPADC in TWL6030 and TWL6032:
> - 10 bit vs 12 bit ADC;
> - 17 vs 19 channels;
> - channels have different purpose(i. e. battery voltage
>   channel 8 vs channel 18);
> - trim values are interpreted differently.
>
> The driver exports function returning converted value for
> requested channels: raw code, corrected code, and converted
> to mV result.
>
> Sysfs entries are added to start and read conversion result
> in millivolts for channel if it has calibration data, or
> ADC code(for temperature and test network channels).
>
> The driver is derived from git://git.omapzoom.org/kernel/omap.git
> The original driver's authors and contributors are Balaji T K,
> Graeme Gregory, Ambresh K, Girish S Ghongdemath.
>
> The changes to the original driver:
> - device tree adaptation;
> - drop ioctl support - never been used;
> - unified measurement method for both devices;
> - get rid of "if (device == X)" code style to data driven;
> - drop polling end of conversion and use interrupt instead;
> - simplified (hopefully) exported external function interface to the driver.
>
> Tested with on blaze tablet 2 with OMAP4430(twl6030), and
> OMAP4470(twl6032) SOMs.
>
> The patches were tested against 3.10-rc7
>
> Oleksandr Kozaruk (2):
>   ARM: dts: twl: Add GPADC data to device tree
>   mfd: twl6030-gpadc: TWL6030, TWL6032 GPADC driver
>
>  .../testing/sysfs-devices-platform-twl6030_gpadc   |5 +
>  arch/arm/boot/dts/twl6030.dtsi |5 +
>  drivers/mfd/Kconfig|8 +
>  drivers/mfd/Makefile   |1 +
>  drivers/mfd/twl6030-gpadc.c| 1053 
> 
>  include/linux/i2c/twl6030-gpadc.h  |   51 +
>  6 files changed, 1123 insertions(+)
>  create mode 100644 
> Documentation/ABI/testing/sysfs-devices-platform-twl6030_gpadc
>  create mode 100644 drivers/mfd/twl6030-gpadc.c
>  create mode 100644 include/linux/i2c/twl6030-gpadc.h
>

--
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 v1 1/2] ARM: dts: twl: Add GPADC data to device tree

[Oleksandr Kozaruk]

GPADC is the general purpose ADC present on twl6030.
The dt data is interrupt used to trigger end of ADC
conversion.

Signed-off-by: Oleksandr Kozaruk 
---
 arch/arm/boot/dts/twl6030.dtsi |5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/twl6030.dtsi b/arch/arm/boot/dts/twl6030.dtsi
index 2e3bd31..189872c 100644
--- a/arch/arm/boot/dts/twl6030.dtsi
+++ b/arch/arm/boot/dts/twl6030.dtsi
@@ -103,4 +103,9 @@
compatible = "ti,twl6030-pwmled";
#pwm-cells = <2>;
};
+
+   twl6030_gpadc {
+   compatible = "ti,twl6030_gpadc";
+   interrupts = <3>;
+   };
 };
-- 
1.7.9.5

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

[PATCH v1 2/2] mfd: twl6030-gpadc: TWL6030, TWL6032 GPADC driver

[Oleksandr Kozaruk]

The GPADC is general purpose ADC found on TWL6030,
and TWL6032 PMIC, known also as Phoenix and PhoenixLite.

The TWL6030 and TWL6032 have GPADC with 17 and 19
channels respectively. Some channels have current
source and are used for measuring voltage drop
on resistive load for detecting battery ID resistance,
or measuring voltage drop on NTC resistors for external
temperature measurements. Some channels measure voltage,
(i.e. battery voltage), and have voltage dividers,
thus, capable to scale voltage. Some channels are dedicated
for measuring die temperature.

Some channels are calibrated in 2 points, having
offsets from ideal values kept in trim registers. This
is used to correct measurements.

The differences between GPADC in TWL6030 and TWL6032:
- 10 bit vs 12 bit ADC;
- 17 vs 19 channels;
- channels have different purpose(i. e. battery voltage
  channel 8 vs channel 18);
- trim values are interpreted differently.

The driver exports function returning converted value for
requested channels.

Based on the driver patched from Balaji TK, Graeme Gregory, Ambresh K,
Girish S Ghongdemath.

Signed-off-by: Balaji T K 
Graeme Gregory 
Signed-off-by: Oleksandr Kozaruk 
---
 .../testing/sysfs-devices-platform-twl6030_gpadc   |5 +
 drivers/mfd/Kconfig|8 +
 drivers/mfd/Makefile   |1 +
 drivers/mfd/twl6030-gpadc.c| 1053 
 include/linux/i2c/twl6030-gpadc.h  |   51 +
 5 files changed, 1118 insertions(+)
 create mode 100644 
Documentation/ABI/testing/sysfs-devices-platform-twl6030_gpadc
 create mode 100644 drivers/mfd/twl6030-gpadc.c
 create mode 100644 include/linux/i2c/twl6030-gpadc.h

diff --git a/Documentation/ABI/testing/sysfs-devices-platform-twl6030_gpadc 
b/Documentation/ABI/testing/sysfs-devices-platform-twl6030_gpadc
new file mode 100644
index 000..e9c5812
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-devices-platform-twl6030_gpadc
@@ -0,0 +1,5 @@
+What:  /sys/bus/platform/devices/twl603X_gpadc.26/inX_channel
+Date:  June 2013
+Contact:   Oleksandr Kozaruk 
+Description:   Start GPADC conversion for chosen channel X and report the 
result.
+   The result is returned in millivolts.
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index d54e985..8eb7494 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -970,6 +970,14 @@ config MFD_TC3589X
  additional drivers must be enabled in order to use the
  functionality of the device.
 
+config TWL6030_GPADC
+   tristate "TWL6030 GPADC (General Purpose A/D Convertor) Support"
+   depends on TWL4030_CORE
+   default n
+   help
+ Say yes here if you want support for the TWL6030 General Purpose
+ A/D Convertor.
+
 config MFD_TMIO
bool
default n
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 718e94a..59f504f 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -70,6 +70,7 @@ obj-$(CONFIG_MENELAUS)+= menelaus.o
 obj-$(CONFIG_TWL4030_CORE) += twl-core.o twl4030-irq.o twl6030-irq.o
 obj-$(CONFIG_TWL4030_MADC)  += twl4030-madc.o
 obj-$(CONFIG_TWL4030_POWER)+= twl4030-power.o
+obj-$(CONFIG_TWL6030_GPADC)+= twl6030-gpadc.o
 obj-$(CONFIG_MFD_TWL4030_AUDIO)+= twl4030-audio.o
 obj-$(CONFIG_TWL6040_CORE) += twl6040.o
 
diff --git a/drivers/mfd/twl6030-gpadc.c b/drivers/mfd/twl6030-gpadc.c
new file mode 100644
index 000..1868bc0
--- /dev/null
+++ b/drivers/mfd/twl6030-gpadc.c
@@ -0,0 +1,1053 @@
+/*
+ * TWL6030 GPADC module driver
+ *
+ * Copyright (C) 2009-2013 Texas Instruments Inc.
+ * Nishant Kamat 
+ * Balaji T K 
+ * Graeme Gregory 
+ * Girish S Ghongdemath 
+ * Ambresh K 
+ * Oleksandr Kozaruk 
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ *
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DRIVER_NAME"twl6030_gpadc"
+
+#define TWL6030_GPADC_MAX_CHANNELS 17
+#define TWL6032_GPADC_MAX_CHANNELS 19
+/* Define this as the biggest of all chips using this driver */
+#define GPADC_MAX_CHANNELS TWL6032_GPADC_MAX_CHANNELS
+
+#define TWL6030_GPADC_CTRL 0x00/* 0x2e */
+#define TWL6030_GPADC_CTRL20x01/* 0x2f */

[PATCH v1 0/2] TWL6030, TWL6032 GPADC driver

[Oleksandr Kozaruk]

Hello

TWL603[02] GPADC is used to measure battery voltage,
battery temperature, battery presence ID, and could
be used to measure twl603[02] die temperature.
This is used on TI blaze, blaze tablet platforms.

The TWL6030 and TWL6032 have GPADC with 17 and 19
channels respectively. Some channels have current
source and are used for measuring voltage drop
on resistive load for detecting battery ID resistance,
or measuring voltage drop on NTC resistors for external
temperature measurements. Some channels measure voltage,
(i.e. battery voltage), and have inbuilt voltage dividers,
thus, capable to scale voltage. Some channels are dedicated
for measuring die temperature.

Some channels could be calibrated in 2 points, having
offsets from ideal values in trim registers.

The difference between GPADC in TWL6030 and TWL6032:
- 10 bit vs 12 bit ADC;
- 17 vs 19 channels;
- channels have different purpose(i. e. battery voltage
  channel 8 vs channel 18);
- trim values are interpreted differently.

The driver exports function returning converted value for
requested channels: raw code, corrected code, and converted
to mV result.

Sysfs entries are added to start and read conversion result
in millivolts for channel if it has calibration data, or
ADC code(for temperature and test network channels).

The driver is derived from git://git.omapzoom.org/kernel/omap.git
The original driver's authors and contributors are Balaji T K,
Graeme Gregory, Ambresh K, Girish S Ghongdemath.

The changes to the original driver:
- device tree adaptation;
- drop ioctl support - never been used;
- unified measurement method for both devices;
- get rid of "if (device == X)" code style to data driven;
- drop polling end of conversion and use interrupt instead;
- simplified (hopefully) exported external function interface to the driver.

Tested with on blaze tablet 2 with OMAP4430(twl6030), and
OMAP4470(twl6032) SOMs.

The patches were tested against 3.10-rc7

Oleksandr Kozaruk (2):
  ARM: dts: twl: Add GPADC data to device tree
  mfd: twl6030-gpadc: TWL6030, TWL6032 GPADC driver

 .../testing/sysfs-devices-platform-twl6030_gpadc   |5 +
 arch/arm/boot/dts/twl6030.dtsi |5 +
 drivers/mfd/Kconfig|8 +
 drivers/mfd/Makefile   |1 +
 drivers/mfd/twl6030-gpadc.c| 1053 
 include/linux/i2c/twl6030-gpadc.h  |   51 +
 6 files changed, 1123 insertions(+)
 create mode 100644 
Documentation/ABI/testing/sysfs-devices-platform-twl6030_gpadc
 create mode 100644 drivers/mfd/twl6030-gpadc.c
 create mode 100644 include/linux/i2c/twl6030-gpadc.h

-- 
1.7.9.5

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

Re: [PATCH 2/4] ARM: OMAP5: clockdomain data: add init file for omap54xx

[Felipe Balbi]

HI,

On Thu, Jun 27, 2013 at 12:24:25PM +0300, Tero Kristo wrote:
> On 06/27/2013 11:44 AM, Felipe Balbi wrote:
> >Hi,
> >
> >On Thu, Jun 27, 2013 at 11:38:17AM +0300, Tero Kristo wrote:
> >>+   rc = clk_set_parent(abe_dpll_ref, sys_32k_ck);
> >>+   abe_dpll = clk_get_sys(NULL, "dpll_abe_ck");
> >
> >should these two lines be swaped ?
> 
> No, its a different clock. clk_set_parent is done for a clock that is
> a parent of dpll_abe_ck.

hah, just now I noticed clk_set_parent() has abe_dpll_ref, not abe_dpll
as argument :-p

> >>+   if (!rc)
> >>+   rc = clk_set_rate(abe_dpll, OMAP5_DPLL_ABE_DEFFREQ);
> >>+   if (rc)
> >>+   pr_err("%s: failed to configure ABE DPLL!\n", __func__);
> >>+
> >>+   return 0;
> >
> >so even if (rc) you still return 0 ? Shouldn't you return rc instead ?
> 
> Hmm yea, this could be improved. :) Same should be done for O4 / DRA7
> also. Seems like a long lasting feature actually.

I see... ;-)

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH 2/4] ARM: OMAP5: clockdomain data: add init file for omap54xx

[Tero Kristo]

On 06/27/2013 11:44 AM, Felipe Balbi wrote:

Hi,

On Thu, Jun 27, 2013 at 11:38:17AM +0300, Tero Kristo wrote:

+   rc = clk_set_parent(abe_dpll_ref, sys_32k_ck);
+   abe_dpll = clk_get_sys(NULL, "dpll_abe_ck");


should these two lines be swaped ?


No, its a different clock. clk_set_parent is done for a clock that is a 
parent of dpll_abe_ck.





+   if (!rc)
+   rc = clk_set_rate(abe_dpll, OMAP5_DPLL_ABE_DEFFREQ);
+   if (rc)
+   pr_err("%s: failed to configure ABE DPLL!\n", __func__);
+
+   return 0;


so even if (rc) you still return 0 ? Shouldn't you return rc instead ?


Hmm yea, this could be improved. :) Same should be done for O4 / DRA7 
also. Seems like a long lasting feature actually.


-Tero
--
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: AM35xx i2c3 issues

[Marc Murphy]

Hi Michael,
The bus is correctly terminated with 2.2k pullups on SCL and SDA lines.

Kind Regards
Marc


From: Michael Trimarchi [mich...@amarulasolutions.com]
Sent: 27 June 2013 09:46
To: Marc Murphy
Cc: linux-omap@vger.kernel.org
Subject: Re: AM35xx i2c3 issues

Hi

On Thu, Jun 27, 2013 at 08:29:05AM +, Marc Murphy wrote:
> Hello Grygorii/All,
>
> I have been trying to address an issue I am having with 3.6rc6 kernel and 
> even with the latest 3.9 and trying to use i2c3 channel on an AM3517.
>
> I see that there has been some work done on the OMAP4 and issues with i2c 
> which looks like the controller being suspended during boot.
>
> I would like to know how I can enable the debug so I can see the messages for 
> warning and debug and whether anyone has tested i2c3 channel on an AM3517 ?
>
> I find the problem a little confusing as the system initializes the 
> interfaces 1-3
>
> [0.168182] omap_i2c omap_i2c.1: bus 1 rev1.3.12 at 400 kHz
> [0.169830] VDCDC1: 1200 <--> 1600 mV at 1200 mV normal
> [0.169830] VDCDC1: Voltage range but no REGULATOR_CHANGE_VOLTAGE
> [0.170684] VDCDC2: 3300 mV normal
> [0.171264] VDCDC3: 1800 mV normal
> [0.171905] LDO1: 1800 mV normal
> [0.172729] LDO2: 3300 mV normal
> [0.174102] omap_i2c omap_i2c.2: bus 2 rev1.3.12 at 400 kHz
> [0.187530] omap_i2c omap_i2c.3: bus 3 rev1.3.12 at 400 kHz
>
> But when it comes to probe the i2c3 interface for the mpu6050 that is 
> connected it fails
>
> [3.896606] omap_i2c omap_i2c.3: timeout waiting for bus ready
> [3.902832] inv-mpu6050: probe of 3-0068 failed with error -110
>

Can you check if your bus is correctly pull up on the line?

Michael

> If I move the mpu6050 onto the i2c2 channel it’s OK so its not an issue with 
> the core omap_i2c.
>
> I also have a scope connected to the scl line and see no activity.  I have 
> proved to myself that the pin is connected and working by configuring as a 
> GPIO output and toggling 0/1/0 and I can see the output changing on the scope.
>
> The mux is configured correctly from what I can see using debugfs
> #  cat /sys/kernel/debug/omap_mux/i2c3_scl
> name: i2c3_scl.i2c3_scl (0x480021c2/0x192 = 0x0100), b af14, t NA
> mode: OMAP_PIN_INPUT | OMAP_MUX_MODE0
> signals: i2c3_scl | NA | NA | NA | gpio_184 | NA | NA | safe_mode
>
> #  cat /sys/kernel/debug/omap_mux/i2c3_sda
> name: i2c3_sda.i2c3_sda (0x480021c4/0x194 = 0x0100), b ag14, t NA
> mode: OMAP_PIN_INPUT | OMAP_MUX_MODE0
> signals: i2c3_sda | NA | NA | NA | gpio_185 | NA | NA | safe_mode
>
>
> If I probe with i2cdetect for all 3 buses there is only an issue with i2c3
> # i2cdetect -r 1
> WARNING! This program can confuse your I2C bus, cause data loss and worse!
> I will probe file /dev/i2c-1 using read byte commands.
> I will probe address range 0x03-0x77.
> Continue? [Y/n]
>  0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
> 00:  -- -- -- -- -- -- -- -- -- -- -- -- --
> 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 40: -- -- -- -- -- -- -- -- UU -- -- -- -- -- -- --
> 50: 50 -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 70: -- -- -- -- -- -- -- --
>
> # i2cdetect -r 2
> WARNING! This program can confuse your I2C bus, cause data loss and worse!
> I will probe file /dev/i2c-2 using read byte commands.
> I will probe address range 0x03-0x77.
> Continue? [Y/n]
>  0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
> 00:  -- -- -- -- -- -- -- -- -- -- -- -- --
> 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 70: -- -- -- -- -- -- -- --
>
> # i2cdetect -r 3
> WARNING! This program can confuse your I2C bus, cause data loss and worse!
> I will probe file /dev/i2c-3 using read byte commands.
> I will probe address range 0x03-0x77.
> Continue? [Y/n]
>  0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
> 00:  [  837.943481] omap_i2c omap_i2c.3: timeout waiting for bus ready
> -- [  838.958984] omap_i2c omap_i2c.3: timeout waiting for bus ready
> -- [  839.974731] omap_i2c omap_i2c.3: timeout waiting for bus ready
>
>
> Any pointers/help appreciated as I have the accelerometer and RTC chip 
> connected on i2c3 but cannot get anything working.
>
> Kind Regards
>
> Marc
> --
> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majord

Re: [PATCH] Documentation: dt: bindings: TI WiLink modules

[Luciano Coelho]

(added mailing lists and everyone back to the thread)

On Wed, 2013-06-26 at 23:38 -0500, Nishanth Menon wrote:
> On 06/25/2013 03:35 AM, Luciano Coelho wrote:
> > +Optional properties:
> > +
> > +
> > +- refclock: the internal WLAN reference clock frequency (required for
> > +  WiLink6 and WiLink7; not used for WiLink8).  Must be one of the
> > +  following:
> > +   0 = 19.2 MHz
> > +   1 = 26.0 MHz
> > +   2 = 38.4 MHz
> > +   3 = 52.0 MHz
> > +   4 = 38.4 MHz, XTAL
> > +   5 = 26.0 MHz, XTAL
> > +
> > +- tcxoclock: the internal WLAN TCXO clock frequency (required for
> > +  WiLink7 not used for WiLink6 and WiLink8).  Must be one of the
> > +  following:
> > +   0 = 19.200 MHz
> > +   1 = 26.000 MHz
> > +   2 = 38.400 MHz
> > +   3 = 52.000 MHz
> > +   4 = 16.368 MHz
> > +   5 = 32.736 MHz
> > +   6 = 16.800 MHz
> > +   7 = 33.600 MHz
> >
> just a gentle query - why not use frequency itself here in Hz for 
> refclock and txoclk?

I thought about using the actual frequencies, but I decided not to do
so, because I'd have to convert them to these values anyway.  These
values are used to configure the firmware and it uses these
"enumerations".


> might not another option of using
> node {
> clocks=<&clk>;
> }
> 
> Usually refclock is an external clock source, no?

No.  In the WiLink case, both refclock and tcxoclock are internal
clocks.  They are in the module itself and what we need to do is tell
the WiLink chip what the module's clocks look like.


> the above allows you to do an devm_clk_get and clk_get_rate() to figure 
> out the exact clock frequency.

No, we can't use these calls, because they are internal clocks.

Please see my more complete explanation as an answer to Tony's email.

Thanks for your review!

--
Luca.

--
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: AM35xx i2c3 issues

[Michael Trimarchi]

Hi

On Thu, Jun 27, 2013 at 08:29:05AM +, Marc Murphy wrote:
> Hello Grygorii/All,
> 
> I have been trying to address an issue I am having with 3.6rc6 kernel and 
> even with the latest 3.9 and trying to use i2c3 channel on an AM3517.
> 
> I see that there has been some work done on the OMAP4 and issues with i2c 
> which looks like the controller being suspended during boot.
> 
> I would like to know how I can enable the debug so I can see the messages for 
> warning and debug and whether anyone has tested i2c3 channel on an AM3517 ?
> 
> I find the problem a little confusing as the system initializes the 
> interfaces 1-3
> 
> [0.168182] omap_i2c omap_i2c.1: bus 1 rev1.3.12 at 400 kHz
> [0.169830] VDCDC1: 1200 <--> 1600 mV at 1200 mV normal
> [0.169830] VDCDC1: Voltage range but no REGULATOR_CHANGE_VOLTAGE
> [0.170684] VDCDC2: 3300 mV normal
> [0.171264] VDCDC3: 1800 mV normal
> [0.171905] LDO1: 1800 mV normal
> [0.172729] LDO2: 3300 mV normal
> [0.174102] omap_i2c omap_i2c.2: bus 2 rev1.3.12 at 400 kHz
> [0.187530] omap_i2c omap_i2c.3: bus 3 rev1.3.12 at 400 kHz
> 
> But when it comes to probe the i2c3 interface for the mpu6050 that is 
> connected it fails
> 
> [3.896606] omap_i2c omap_i2c.3: timeout waiting for bus ready
> [3.902832] inv-mpu6050: probe of 3-0068 failed with error -110
> 

Can you check if your bus is correctly pull up on the line?

Michael

> If I move the mpu6050 onto the i2c2 channel it’s OK so its not an issue with 
> the core omap_i2c.
> 
> I also have a scope connected to the scl line and see no activity.  I have 
> proved to myself that the pin is connected and working by configuring as a 
> GPIO output and toggling 0/1/0 and I can see the output changing on the scope.
> 
> The mux is configured correctly from what I can see using debugfs
> #  cat /sys/kernel/debug/omap_mux/i2c3_scl
> name: i2c3_scl.i2c3_scl (0x480021c2/0x192 = 0x0100), b af14, t NA
> mode: OMAP_PIN_INPUT | OMAP_MUX_MODE0
> signals: i2c3_scl | NA | NA | NA | gpio_184 | NA | NA | safe_mode
> 
> #  cat /sys/kernel/debug/omap_mux/i2c3_sda
> name: i2c3_sda.i2c3_sda (0x480021c4/0x194 = 0x0100), b ag14, t NA
> mode: OMAP_PIN_INPUT | OMAP_MUX_MODE0
> signals: i2c3_sda | NA | NA | NA | gpio_185 | NA | NA | safe_mode
> 
> 
> If I probe with i2cdetect for all 3 buses there is only an issue with i2c3
> # i2cdetect -r 1
> WARNING! This program can confuse your I2C bus, cause data loss and worse!
> I will probe file /dev/i2c-1 using read byte commands.
> I will probe address range 0x03-0x77.
> Continue? [Y/n]
>  0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
> 00:  -- -- -- -- -- -- -- -- -- -- -- -- --
> 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 40: -- -- -- -- -- -- -- -- UU -- -- -- -- -- -- --
> 50: 50 -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 70: -- -- -- -- -- -- -- --
> 
> # i2cdetect -r 2
> WARNING! This program can confuse your I2C bus, cause data loss and worse!
> I will probe file /dev/i2c-2 using read byte commands.
> I will probe address range 0x03-0x77.
> Continue? [Y/n]
>  0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
> 00:  -- -- -- -- -- -- -- -- -- -- -- -- --
> 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 70: -- -- -- -- -- -- -- --
> 
> # i2cdetect -r 3
> WARNING! This program can confuse your I2C bus, cause data loss and worse!
> I will probe file /dev/i2c-3 using read byte commands.
> I will probe address range 0x03-0x77.
> Continue? [Y/n]
>  0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
> 00:  [  837.943481] omap_i2c omap_i2c.3: timeout waiting for bus ready
> -- [  838.958984] omap_i2c omap_i2c.3: timeout waiting for bus ready
> -- [  839.974731] omap_i2c omap_i2c.3: timeout waiting for bus ready
> 
> 
> Any pointers/help appreciated as I have the accelerometer and RTC chip 
> connected on i2c3 but cannot get anything working.
> 
> Kind Regards
> 
> Marc
> --
> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/4] ARM: OMAP5: clockdomain data: add init file for omap54xx

[Felipe Balbi]

Hi,

On Thu, Jun 27, 2013 at 11:38:17AM +0300, Tero Kristo wrote:
> + rc = clk_set_parent(abe_dpll_ref, sys_32k_ck);
> + abe_dpll = clk_get_sys(NULL, "dpll_abe_ck");

should these two lines be swaped ?

> + if (!rc)
> + rc = clk_set_rate(abe_dpll, OMAP5_DPLL_ABE_DEFFREQ);
> + if (rc)
> + pr_err("%s: failed to configure ABE DPLL!\n", __func__);
> +
> + return 0;

so even if (rc) you still return 0 ? Shouldn't you return rc instead ?

-- 
balbi


signature.asc
Description: Digital signature

[PATCH 3/4] ARM: dts: dra7xx clock data

[Tero Kristo]

This patch creates the clock node mapping for DRA7xx.

TODO: 1) include this from base dra7.dtsi file once available
  2) apll_pcie_ck is currently broken, proper support code missing

Signed-off-by: Tero Kristo 
---
 arch/arm/boot/dts/dra7-clocks.dtsi | 2099 
 1 file changed, 2099 insertions(+)
 create mode 100644 arch/arm/boot/dts/dra7-clocks.dtsi

diff --git a/arch/arm/boot/dts/dra7-clocks.dtsi 
b/arch/arm/boot/dts/dra7-clocks.dtsi
new file mode 100644
index 000..5b1e107
--- /dev/null
+++ b/arch/arm/boot/dts/dra7-clocks.dtsi
@@ -0,0 +1,2099 @@
+/*
+ * Device Tree Source for DRA7xx Clock data
+ *
+ * Copyright (C) 2013 Texas Instruments, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/* Root clocks */
+atl_clkin0_ck: atl_clkin0_ck {
+   #clock-cells = <0>;
+   compatible = "fixed-clock";
+   clock-frequency = <0>;
+};
+
+atl_clkin1_ck: atl_clkin1_ck {
+   #clock-cells = <0>;
+   compatible = "fixed-clock";
+   clock-frequency = <0>;
+};
+
+atl_clkin2_ck: atl_clkin2_ck {
+   #clock-cells = <0>;
+   compatible = "fixed-clock";
+   clock-frequency = <0>;
+};
+
+atlclkin3_ck: atlclkin3_ck {
+   #clock-cells = <0>;
+   compatible = "fixed-clock";
+   clock-frequency = <0>;
+};
+
+hdmi_clkin_ck: hdmi_clkin_ck {
+   #clock-cells = <0>;
+   compatible = "fixed-clock";
+   clock-frequency = <0>;
+};
+
+mlb_clkin_ck: mlb_clkin_ck {
+   #clock-cells = <0>;
+   compatible = "fixed-clock";
+   clock-frequency = <0>;
+};
+
+mlbp_clkin_ck: mlbp_clkin_ck {
+   #clock-cells = <0>;
+   compatible = "fixed-clock";
+   clock-frequency = <0>;
+};
+
+pciesref_acs_clk_ck: pciesref_acs_clk_ck {
+   #clock-cells = <0>;
+   compatible = "fixed-clock";
+   clock-frequency = <1>;
+};
+
+ref_clkin0_ck: ref_clkin0_ck {
+   #clock-cells = <0>;
+   compatible = "fixed-clock";
+   clock-frequency = <0>;
+};
+
+ref_clkin1_ck: ref_clkin1_ck {
+   #clock-cells = <0>;
+   compatible = "fixed-clock";
+   clock-frequency = <0>;
+};
+
+ref_clkin2_ck: ref_clkin2_ck {
+   #clock-cells = <0>;
+   compatible = "fixed-clock";
+   clock-frequency = <0>;
+};
+
+ref_clkin3_ck: ref_clkin3_ck {
+   #clock-cells = <0>;
+   compatible = "fixed-clock";
+   clock-frequency = <0>;
+};
+
+rmii_clk_ck: rmii_clk_ck {
+   #clock-cells = <0>;
+   compatible = "fixed-clock";
+   clock-frequency = <0>;
+};
+
+sdvenc_clkin_ck: sdvenc_clkin_ck {
+   #clock-cells = <0>;
+   compatible = "fixed-clock";
+   clock-frequency = <0>;
+};
+
+secure_32k_clk_src_ck: secure_32k_clk_src_ck {
+   #clock-cells = <0>;
+   compatible = "fixed-clock";
+   clock-frequency = <32768>;
+};
+
+sys_32k_ck: sys_32k_ck {
+   #clock-cells = <0>;
+   compatible = "fixed-clock";
+   clock-frequency = <32768>;
+};
+
+virt_1200_ck: virt_1200_ck {
+   #clock-cells = <0>;
+   compatible = "fixed-clock";
+   clock-frequency = <1200>;
+};
+
+virt_1300_ck: virt_1300_ck {
+   #clock-cells = <0>;
+   compatible = "fixed-clock";
+   clock-frequency = <1300>;
+};
+
+virt_1680_ck: virt_1680_ck {
+   #clock-cells = <0>;
+   compatible = "fixed-clock";
+   clock-frequency = <1680>;
+};
+
+virt_1920_ck: virt_1920_ck {
+   #clock-cells = <0>;
+   compatible = "fixed-clock";
+   clock-frequency = <1920>;
+};
+
+virt_2000_ck: virt_2000_ck {
+   #clock-cells = <0>;
+   compatible = "fixed-clock";
+   clock-frequency = <2000>;
+};
+
+virt_2600_ck: virt_2600_ck {
+   #clock-cells = <0>;
+   compatible = "fixed-clock";
+   clock-frequency = <2600>;
+};
+
+virt_2700_ck: virt_2700_ck {
+   #clock-cells = <0>;
+   compatible = "fixed-clock";
+   clock-frequency = <2700>;
+};
+
+virt_3840_ck: virt_3840_ck {
+   #clock-cells = <0>;
+   compatible = "fixed-clock";
+   clock-frequency = <3840>;
+};
+
+sys_clkin1: sys_clkin1@4ae06110 {
+   compatible = "mux-clock";
+   clocks = <&virt_1200_ck>, <&virt_2000_ck>, <&virt_1680_ck>, 
<&virt_1920_ck>, <&virt_2600_ck>, <&virt_2700_ck>, 
<&virt_3840_ck>;
+   #clock-cells = <0>;
+   reg = <0x4ae06110 0x4>;
+   bit-mask = <0x7>;
+   index-starts-at-one;
+};
+
+sys_clkin2: sys_clkin2 {
+   #clock-cells = <0>;
+   compatible = "fixed-clock";
+   clock-frequency = <22579200>;
+};
+
+usb_otg_clkin_ck: usb_otg_clkin_ck {
+   #clock-cells = <0>;
+   compatible = "fixed-clock";
+   clock-frequency = <0>;
+};
+
+video1_clkin_ck: video1_clkin_ck {
+   #clock-cells = <0>;
+   compatible = "fixed-clock";
+   clock-frequency

[PATCH 1/4] ARM: dts: omap5 clock data

[Tero Kristo]

This patch creates the clock node mapping for OMAP5, and includes it to
the base omap5.dtsi file.

Signed-off-by: Tero Kristo 
---
 arch/arm/boot/dts/omap5-clocks.dtsi | 1442 +++
 arch/arm/boot/dts/omap5.dtsi|2 +
 2 files changed, 1444 insertions(+)
 create mode 100644 arch/arm/boot/dts/omap5-clocks.dtsi

diff --git a/arch/arm/boot/dts/omap5-clocks.dtsi 
b/arch/arm/boot/dts/omap5-clocks.dtsi
new file mode 100644
index 000..5767195
--- /dev/null
+++ b/arch/arm/boot/dts/omap5-clocks.dtsi
@@ -0,0 +1,1442 @@
+/*
+ * Device Tree Source for OMAP5 clock data
+ *
+ * Copyright (C) 2013 Texas Instruments, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/* Root clocks */
+pad_clks_src_ck: pad_clks_src_ck {
+   #clock-cells = <0>;
+   compatible = "fixed-clock";
+   clock-frequency = <1200>;
+};
+
+pad_clks_ck: pad_clks_ck@4a004108 {
+   compatible = "gate-clock";
+   reg = <0x4a004108 0x4>;
+   bit-shift = <8>;
+   clocks = <&pad_clks_src_ck>;
+   #clock-cells = <0>;
+};
+
+secure_32k_clk_src_ck: secure_32k_clk_src_ck {
+   #clock-cells = <0>;
+   compatible = "fixed-clock";
+   clock-frequency = <32768>;
+};
+
+slimbus_src_clk: slimbus_src_clk {
+   #clock-cells = <0>;
+   compatible = "fixed-clock";
+   clock-frequency = <1200>;
+};
+
+slimbus_clk: slimbus_clk@4a004108 {
+   compatible = "gate-clock";
+   reg = <0x4a004108 0x4>;
+   bit-shift = <10>;
+   clocks = <&slimbus_src_clk>;
+   #clock-cells = <0>;
+};
+
+sys_32k_ck: sys_32k_ck {
+   #clock-cells = <0>;
+   compatible = "fixed-clock";
+   clock-frequency = <32768>;
+};
+
+virt_1200_ck: virt_1200_ck {
+   #clock-cells = <0>;
+   compatible = "fixed-clock";
+   clock-frequency = <1200>;
+};
+
+virt_1300_ck: virt_1300_ck {
+   #clock-cells = <0>;
+   compatible = "fixed-clock";
+   clock-frequency = <1300>;
+};
+
+virt_1680_ck: virt_1680_ck {
+   #clock-cells = <0>;
+   compatible = "fixed-clock";
+   clock-frequency = <1680>;
+};
+
+virt_1920_ck: virt_1920_ck {
+   #clock-cells = <0>;
+   compatible = "fixed-clock";
+   clock-frequency = <1920>;
+};
+
+virt_2600_ck: virt_2600_ck {
+   #clock-cells = <0>;
+   compatible = "fixed-clock";
+   clock-frequency = <2600>;
+};
+
+virt_2700_ck: virt_2700_ck {
+   #clock-cells = <0>;
+   compatible = "fixed-clock";
+   clock-frequency = <2700>;
+};
+
+virt_3840_ck: virt_3840_ck {
+   #clock-cells = <0>;
+   compatible = "fixed-clock";
+   clock-frequency = <3840>;
+};
+
+sys_clkin: sys_clkin@4ae06110 {
+   compatible = "mux-clock";
+   clocks = <&virt_1200_ck>, <&virt_1300_ck>, <&virt_1680_ck>, 
<&virt_1920_ck>, <&virt_2600_ck>, <&virt_2700_ck>, 
<&virt_3840_ck>;
+   #clock-cells = <0>;
+   reg = <0x4ae06110 0x4>;
+   bit-mask = <0x7>;
+   index-starts-at-one;
+};
+
+xclk60mhsp1_ck: xclk60mhsp1_ck {
+   #clock-cells = <0>;
+   compatible = "fixed-clock";
+   clock-frequency = <6000>;
+};
+
+xclk60mhsp2_ck: xclk60mhsp2_ck {
+   #clock-cells = <0>;
+   compatible = "fixed-clock";
+   clock-frequency = <6000>;
+};
+
+/* Module clocks and DPLL outputs */
+abe_dpll_bypass_clk_mux: abe_dpll_bypass_clk_mux@4ae06108 {
+   compatible = "mux-clock";
+   clocks = <&sys_clkin>, <&sys_32k_ck>;
+   #clock-cells = <0>;
+   reg = <0x4ae06108 0x4>;
+   bit-mask = <0x1>;
+};
+
+abe_dpll_clk_mux: abe_dpll_clk_mux@4ae0610c {
+   compatible = "mux-clock";
+   clocks = <&sys_clkin>, <&sys_32k_ck>;
+   #clock-cells = <0>;
+   reg = <0x4ae0610c 0x4>;
+   bit-mask = <0x1>;
+};
+
+/* DPLL_ABE */
+dpll_abe_ck: dpll_abe_ck {
+   clocks = <&abe_dpll_clk_mux>, <&abe_dpll_bypass_clk_mux>;
+   #clock-cells = <0>;
+   reg = <0x4a0041e0 0x4>, <0x4a0041e4 0x4>, <0x4a0041e8 0x4>, <0x4a0041ec 
0x4>;
+   ti,clk-bypass = <&abe_dpll_bypass_clk_mux>;
+   ti,clk-ref = <&abe_dpll_clk_mux>;
+   compatible = "ti,omap4-dpll-clock";
+   ti,dpll-regm4xen;
+};
+
+dpll_abe_x2_ck: dpll_abe_x2_ck {
+   clocks = <&dpll_abe_ck>;
+   #clock-cells = <0>;
+   compatible = "ti,omap4-dpll-clock";
+   ti,dpll-clk-x2;
+};
+
+dpll_abe_m2x2_ck: dpll_abe_m2x2_ck@4a0041f0 {
+   compatible = "divider-clock";
+   clocks = <&dpll_abe_x2_ck>;
+   #clock-cells = <0>;
+   reg = <0x4a0041f0 0x4>;
+   bit-mask = <0x1f>;
+   ti,autoidle-shift = <8>;
+   ti,autoidle-low;
+   index-starts-at-one;
+};
+
+abe_24m_fclk: abe_24m_fclk {
+   compatible = "fixed-factor-clock";
+   clocks = <&dpll_abe_m2x2_ck>;
+   #clock-cells = 

[PATCH 0/4] ARM: OMAP5 and DRA7 clock data

[Tero Kristo]

Hi,

These patches provide clock data for TI OMAP5 and DRA7 SoCs. Clock data
is mostly in device tree format, and only a small init portion is needed
under mach-omap2. These patches come on top of the base OMAP4 clock data
conversion I posted earlier this week:

  http://comments.gmane.org/gmane.linux.ports.arm.omap/100117

These patches need the basic SoC boot support before they are of any use.

Boot tested with private tree and compile tested against 3.10-rc6.

-Tero

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

[PATCH 2/4] ARM: OMAP5: clockdomain data: add init file for omap54xx

[Tero Kristo]

cclock54xx_data.c now contains only init function and the clkdev mapping
that is still needed by some drivers. Eventually most of this file can
be removed, once a common location for the clk init can be found, and
the clkdev mapping is no longer needed.

Signed-off-by: Tero Kristo 
---
 arch/arm/mach-omap2/cclock54xx_data.c |   80 +
 1 file changed, 80 insertions(+)
 create mode 100644 arch/arm/mach-omap2/cclock54xx_data.c

diff --git a/arch/arm/mach-omap2/cclock54xx_data.c 
b/arch/arm/mach-omap2/cclock54xx_data.c
new file mode 100644
index 000..f23f44e
--- /dev/null
+++ b/arch/arm/mach-omap2/cclock54xx_data.c
@@ -0,0 +1,74 @@
+/*
+ * OMAP54xx Clock data
+ *
+ * Copyright (C) 2013 Texas Instruments, Inc.
+ *
+ * Paul Walmsley (p...@pwsan.com)
+ * Rajendra Nayak (rna...@ti.com)
+ * Benoit Cousson (b-cous...@ti.com)
+ * Mike Turquette (mturque...@linaro.org)
+ * Tero Kristo (t-kri...@ti.com)
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "soc.h"
+#include "clock.h"
+
+#define OMAP5_DPLL_ABE_DEFFREQ 98304000
+
+/*
+ * clkdev
+ */
+static struct omap_dt_clk omap54xx_clks[] = {
+   DT_CLK(NULL,"timer_32k_ck", "sys_32k_ck"),
+   DT_CLK("omap_timer.1",  "sys_ck",   "sys_clkin"),
+   DT_CLK("omap_timer.2",  "sys_ck",   "sys_clkin"),
+   DT_CLK("omap_timer.3",  "sys_ck",   "sys_clkin"),
+   DT_CLK("omap_timer.4",  "sys_ck",   "sys_clkin"),
+   DT_CLK("omap_timer.9",  "sys_ck",   "sys_clkin"),
+   DT_CLK("omap_timer.10", "sys_ck",   "sys_clkin"),
+   DT_CLK("omap_timer.11", "sys_ck",   "sys_clkin"),
+   DT_CLK("omap_timer.5",  "sys_ck",   "dss_syc_gfclk_div"),
+   DT_CLK("omap_timer.6",  "sys_ck",   "dss_syc_gfclk_div"),
+   DT_CLK("omap_timer.7",  "sys_ck",   "dss_syc_gfclk_div"),
+   DT_CLK("omap_timer.8",  "sys_ck",   "dss_syc_gfclk_div"),
+};
+
+int __init omap5xxx_clk_init(void)
+{
+   struct clk *abe_dpll_ref, *sys_32k_ck, *abe_dpll;
+   int rc;
+
+   /*
+* Must stay commented until all OMAP SoC drivers are
+* converted to runtime PM, or drivers may start crashing
+*
+* omap2_clk_disable_clkdm_control();
+*/
+   dt_omap_clk_init();
+
+   omap_dt_clocks_register(omap54xx_clks, ARRAY_SIZE(omap54xx_clks));
+
+   omap2_clk_disable_autoidle_all();
+
+   abe_dpll_ref = clk_get_sys(NULL, "abe_dpll_clk_mux");
+   sys_32k_ck = clk_get_sys(NULL, "sys_32k_ck");
+   rc = clk_set_parent(abe_dpll_ref, sys_32k_ck);
+   abe_dpll = clk_get_sys(NULL, "dpll_abe_ck");
+   if (!rc)
+   rc = clk_set_rate(abe_dpll, OMAP5_DPLL_ABE_DEFFREQ);
+   if (rc)
+   pr_err("%s: failed to configure ABE DPLL!\n", __func__);
+
+   return 0;
+}
-- 
1.7.9.5

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

[PATCH 4/4] ARM: DRA7: clockdomain data: add init file for dra7

[Tero Kristo]

cclock7xx_data.c now contains only init function and the clkdev mapping
that is still needed by some drivers. Eventually most of this file can
be removed, once a common location for the clk init can be found, and
the clkdev mapping is no longer needed.

Signed-off-by: Tero Kristo 
---
 arch/arm/mach-omap2/cclock7xx_data.c |   93 ++
 1 file changed, 93 insertions(+)
 create mode 100644 arch/arm/mach-omap2/cclock7xx_data.c

diff --git a/arch/arm/mach-omap2/cclock7xx_data.c 
b/arch/arm/mach-omap2/cclock7xx_data.c
new file mode 100644
index 000..dba528a
--- /dev/null
+++ b/arch/arm/mach-omap2/cclock7xx_data.c
@@ -0,0 +1,83 @@
+/*
+ * DRA7xx Clock data
+ *
+ * Copyright (C) 2013 Texas Instruments, Inc.
+ *
+ * Paul Walmsley (p...@pwsan.com)
+ * Rajendra Nayak (rna...@ti.com)
+ * Benoit Cousson (b-cous...@ti.com)
+ * Mike Turquette (mturque...@linaro.org)
+ * Tero Kristo (t-kri...@ti.com)
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "soc.h"
+#include "clock.h"
+
+#define DRA7_DPLL_ABE_DEFFREQ  361267200
+#define DRA7_DPLL_GMAC_DEFFREQ 10
+
+/*
+ * clkdev
+ */
+
+static struct omap_dt_clk dra7xx_clks[] = {
+   DT_CLK(NULL,"timer_32k_ck", "sys_32k_ck"),
+   DT_CLK("4ae18000.timer","timer_sys_ck", "sys_clkin2"),
+   DT_CLK("48032000.timer","timer_sys_ck", "sys_clkin2"),
+   DT_CLK("48034000.timer","timer_sys_ck", "sys_clkin2"),
+   DT_CLK("48036000.timer","timer_sys_ck", "sys_clkin2"),
+   DT_CLK("4803e000.timer","timer_sys_ck", "sys_clkin2"),
+   DT_CLK("48086000.timer","timer_sys_ck", "sys_clkin2"),
+   DT_CLK("48088000.timer","timer_sys_ck", "sys_clkin2"),
+   DT_CLK("4882.timer","timer_sys_ck", 
"timer_sys_clk_div"),
+   DT_CLK("48822000.timer","timer_sys_ck", 
"timer_sys_clk_div"),
+   DT_CLK("48824000.timer","timer_sys_ck", 
"timer_sys_clk_div"),
+   DT_CLK("48826000.timer","timer_sys_ck", 
"timer_sys_clk_div"),
+   DT_CLK(NULL,   "sys_clkin","sys_clkin1"),
+};
+
+int __init dra7xx_clk_init(void)
+{
+   struct clk *abe_dpll_mux, *sys_clkin2, *dpll_ck;
+   int rc;
+   /*
+* Must stay commented until all OMAP SoC drivers are
+* converted to runtime PM, or drivers may start crashing
+*
+* omap2_clk_disable_clkdm_control();
+*/
+
+   dt_omap_clk_init();
+
+   omap_dt_clocks_register(dra7xx_clks, ARRAY_SIZE(dra7xx_clks));
+
+   omap2_clk_disable_autoidle_all();
+
+   abe_dpll_mux = clk_get_sys(NULL, "abe_dpll_sys_clk_mux");
+   sys_clkin2 = clk_get_sys(NULL, "sys_clkin2");
+   dpll_ck = clk_get_sys(NULL, "dpll_abe_ck");
+
+   rc = clk_set_parent(abe_dpll_mux, sys_clkin2);
+   if (!rc)
+   rc = clk_set_rate(dpll_ck, DRA7_DPLL_ABE_DEFFREQ);
+   if (rc)
+   pr_err("%s: failed to configure ABE DPLL!\n", __func__);
+
+   dpll_ck = clk_get_sys(NULL, "dpll_gmac_ck");
+   rc = clk_set_rate(dpll_ck, DRA7_DPLL_GMAC_DEFFREQ);
+   if (rc)
+   pr_err("%s: failed to configure GMAC DPLL!\n", __func__);
+
+   return 0;
+}
-- 
1.7.9.5

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

AM35xx i2c3 issues

[Marc Murphy]

Hello Grygorii/All,

I have been trying to address an issue I am having with 3.6rc6 kernel and even 
with the latest 3.9 and trying to use i2c3 channel on an AM3517.

I see that there has been some work done on the OMAP4 and issues with i2c which 
looks like the controller being suspended during boot.

I would like to know how I can enable the debug so I can see the messages for 
warning and debug and whether anyone has tested i2c3 channel on an AM3517 ?

I find the problem a little confusing as the system initializes the interfaces 
1-3

[0.168182] omap_i2c omap_i2c.1: bus 1 rev1.3.12 at 400 kHz
[0.169830] VDCDC1: 1200 <--> 1600 mV at 1200 mV normal
[0.169830] VDCDC1: Voltage range but no REGULATOR_CHANGE_VOLTAGE
[0.170684] VDCDC2: 3300 mV normal
[0.171264] VDCDC3: 1800 mV normal
[0.171905] LDO1: 1800 mV normal
[0.172729] LDO2: 3300 mV normal
[0.174102] omap_i2c omap_i2c.2: bus 2 rev1.3.12 at 400 kHz
[0.187530] omap_i2c omap_i2c.3: bus 3 rev1.3.12 at 400 kHz

But when it comes to probe the i2c3 interface for the mpu6050 that is connected 
it fails

[3.896606] omap_i2c omap_i2c.3: timeout waiting for bus ready
[3.902832] inv-mpu6050: probe of 3-0068 failed with error -110

If I move the mpu6050 onto the i2c2 channel it’s OK so its not an issue with 
the core omap_i2c.

I also have a scope connected to the scl line and see no activity.  I have 
proved to myself that the pin is connected and working by configuring as a GPIO 
output and toggling 0/1/0 and I can see the output changing on the scope.

The mux is configured correctly from what I can see using debugfs
#  cat /sys/kernel/debug/omap_mux/i2c3_scl
name: i2c3_scl.i2c3_scl (0x480021c2/0x192 = 0x0100), b af14, t NA
mode: OMAP_PIN_INPUT | OMAP_MUX_MODE0
signals: i2c3_scl | NA | NA | NA | gpio_184 | NA | NA | safe_mode

#  cat /sys/kernel/debug/omap_mux/i2c3_sda
name: i2c3_sda.i2c3_sda (0x480021c4/0x194 = 0x0100), b ag14, t NA
mode: OMAP_PIN_INPUT | OMAP_MUX_MODE0
signals: i2c3_sda | NA | NA | NA | gpio_185 | NA | NA | safe_mode


If I probe with i2cdetect for all 3 buses there is only an issue with i2c3
# i2cdetect -r 1
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-1 using read byte commands.
I will probe address range 0x03-0x77.
Continue? [Y/n]
 0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:  -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- UU -- -- -- -- -- -- --
50: 50 -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --

# i2cdetect -r 2
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-2 using read byte commands.
I will probe address range 0x03-0x77.
Continue? [Y/n]
 0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:  -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --

# i2cdetect -r 3
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-3 using read byte commands.
I will probe address range 0x03-0x77.
Continue? [Y/n]
 0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:  [  837.943481] omap_i2c omap_i2c.3: timeout waiting for bus ready
-- [  838.958984] omap_i2c omap_i2c.3: timeout waiting for bus ready
-- [  839.974731] omap_i2c omap_i2c.3: timeout waiting for bus ready


Any pointers/help appreciated as I have the accelerometer and RTC chip 
connected on i2c3 but cannot get anything working.

Kind Regards

Marc
--
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 3/3] ARM: dts: omap3-igep0030: add mux conf for GPIO LED

[Enric Balletbo Serra]

2013/6/20 Javier Martinez Canillas :
> The IGEP COM MOdule has a GPIO LED connected to OMAP
> pins. Configure this pin as output GPIO.
>
> Signed-off-by: Javier Martinez Canillas 
> ---
>  arch/arm/boot/dts/omap3-igep0030.dts |9 +
>  1 files changed, 9 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/boot/dts/omap3-igep0030.dts 
> b/arch/arm/boot/dts/omap3-igep0030.dts
> index 644d053..eee3c63 100644
> --- a/arch/arm/boot/dts/omap3-igep0030.dts
> +++ b/arch/arm/boot/dts/omap3-igep0030.dts
> @@ -16,7 +16,10 @@
> compatible = "isee,omap3-igep0030", "ti,omap3";
>
> leds {
> +   pinctrl-names = "default";
> +   pinctrl-0 = <&leds_pins>;
> compatible = "gpio-leds";
> +
> boot {
>  label = "omap3:green:boot";
>  gpios = <&twl_gpio 13 GPIO_ACTIVE_LOW>;
> @@ -43,6 +46,12 @@
> };
>  };
>
> +&leds_pins {
> +   pinctrl-single,pins = <
> +   0x5b0 (PIN_OUTPUT | MUX_MODE4) /* etk_d2.gpio_16 */
> +   >;
> +};
> +
>  &gpmc {
> ranges = <0 0 0x 0x2000>;
>
> --
> 1.7.7.6
>
Tested-by: Enric Balletbo i Serra 
--
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/3] ARM: dts: omap3-igep0020: add mux conf for GPIO LEDs

[Enric Balletbo Serra]

2013/6/20 Javier Martinez Canillas 
>
> The IGEPv2 has a number of GPIO LED connected to OMAP
> pins. Configure these pins as output GPIO.
>
> Signed-off-by: Javier Martinez Canillas 
> ---
>  arch/arm/boot/dts/omap3-igep0020.dts |   11 +++
>  1 files changed, 11 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/boot/dts/omap3-igep0020.dts
> b/arch/arm/boot/dts/omap3-igep0020.dts
> index e8c4828..51c084e 100644
> --- a/arch/arm/boot/dts/omap3-igep0020.dts
> +++ b/arch/arm/boot/dts/omap3-igep0020.dts
> @@ -16,7 +16,10 @@
> compatible = "isee,omap3-igep0020", "ti,omap3";
>
> leds {
> +   pinctrl-names = "default";
> +   pinctrl-0 = <&leds_pins>;
> compatible = "gpio-leds";
> +
> boot {
>  label = "omap3:green:boot";
>  gpios = <&gpio1 26 GPIO_ACTIVE_HIGH>;
> @@ -54,6 +57,14 @@
> };
>  };
>
> +&leds_pins {
> +   pinctrl-single,pins = <
> +   0x5c4 (PIN_OUTPUT | MUX_MODE4) /* etk_d12.gpio_26 */
> +   0x5c6 (PIN_OUTPUT | MUX_MODE4) /* etk_d13.gpio_27 */
> +   0x5c8 (PIN_OUTPUT | MUX_MODE4) /* etk_d14.gpio_28 */
> +   >;
> +};
> +
>  &i2c3 {
> clock-frequency = <10>;
>
> --
> 1.7.7.6
>
Tested-by: Enric Balletbo i Serra 
--
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: regression caused by commit 8357b48549e17b3e4e402c7f977b65708922e60f

[Stephen Rothwell]

Hi balbi,

On Thu, 27 Jun 2013 10:04:24 +0300 Felipe Balbi  wrote:
>
> On Thu, Jun 27, 2013 at 04:36:55PM +1000, Stephen Rothwell wrote:
> > 
> > That commit has been reverted in today's kbuild tree and thus in today's
> > linux-next.
> 
> thanks, I should fetch again :-)

Let me finish first :-)  (an hour or so ...)

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpFlKTG6mihW.pgp
Description: PGP signature

Re: [PATCH 4/4] regulator: Palmas: Add TPS659038 support

[Samuel Ortiz]

Hi,

On Thu, Jun 20, 2013 at 04:32:15PM +0530, J Keerthy wrote:
> Add TPS659038 support.
> 
> Signed-off-by: J Keerthy 
> Acked-by: Mark Brown 
> ---
>  drivers/regulator/palmas-regulator.c |1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
Applied to mfd-next, thanks.

Cheers,
Samuel.

-- 
Intel Open Source Technology Centre
http://oss.intel.com/
--
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: [RFC] am33xx: create child nodes for the two musb controllers

[Felipe Balbi]

Hi,

On Thu, Jun 27, 2013 at 09:31:34AM +0200, Sebastian Andrzej Siewior wrote:
> > the patch is alright, but what about the giant amoutn of function 
> > pointers we have ? Are you planning to use of_dev_auxdata ??
> 
> I didn't plan to use of_dev_auxdata. What do you mean by "giant amount
> of function pointers"?

every glue layer has:

467 static const struct musb_platform_ops omap2430_ops = {
468 .init   = omap2430_musb_init,
469 .exit   = omap2430_musb_exit,
470 
471 .set_mode   = omap2430_musb_set_mode,
472 .try_idle   = omap2430_musb_try_idle,
473 
474 .set_vbus   = omap2430_musb_set_vbus,
475 
476 .enable = omap2430_musb_enable,
477 .disable= omap2430_musb_disable,
478 };

note that in the glue layer, they have access to musb itself (biggest
mistake of my life, btw :-)

-- 
balbi


signature.asc
Description: Digital signature

Re: [RFC] am33xx: create child nodes for the two musb controllers

[Sebastian Andrzej Siewior]

On 06/27/2013 08:51 AM, Felipe Balbi wrote:
> Hi,

Hi Felipe,

> the patch is alright, but what about the giant amoutn of function 
> pointers we have ? Are you planning to use of_dev_auxdata ??

I didn't plan to use of_dev_auxdata. What do you mean by "giant amount
of function pointers"?

Sebastian
--
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] usb: dwc3: core: continue probe even if usb3 phy is not available

[Felipe Balbi]

Hi,

On Thu, Jun 27, 2013 at 09:24:08AM +0200, Michael Grzeschik wrote:
> > > > > right, but in DT you will define both instances and each instance will
> > > > > have a seaparate snps,maximum_speed attribute :-)
> > > > >
> > > > > I'm now considering if we should make maximum_speed a generic 
> > > > > attribute,
> > > > > Kishon ? Alex ? Alan ?
> > > > >
> > > > > anyone else needs such thing ?
> > > > 
> > > > We have a force-full-speed attibute for chipidea on the way. This
> > > > maximum_speed looks like a more generic alternative. Michael, what say
> > > > you?
> > > 
> > > The maximum_speed attribute sounds more reasonable. I will change my
> > > patch to it.
> > 
> > thanks, perhaps we can add a generic helper in udc-core or usb-common ?
> 
> As this function is not only udc specific, this should go into usb-common.
> But right, we should go with a helper here. I will write one in addition
> to my full-speed patch as first user of it.

alright, thanks :-)

-- 
balbi


signature.asc
Description: Digital signature

Re: [RFC] ARM: OMAP2+: omap_device: add pinctrl handling

[Tony Lindgren]

* Linus Walleij  [130626 12:37]:
> On Wed, Jun 26, 2013 at 3:20 PM, Grygorii Strashko
>  wrote:
> 
> > The "Sleep" pinctrl state is optional - if "sleep" state isn't defined
> > then "Idle" pinctrl state will be used during suspend.
> 
> Why? If we have a clear cut semantic that "idle" is for runtime
> suspend, why should it be a fallback for suspend?
> 
> You do realize that can just be turned around (as common suspend
> is more widely implemented than runtime suspend) so that we
> could say that if "idle" does not exist, we go to "sleep" in
> runtime suspend.
> 
> > So, final list of default pnctrl states may be defined as "default",
> > "active", "idle", "sleep", "off":
> > - "active", "idle", "sleep": will be handled by omap_device core
> > - "default", "off": will be handled by driver itself (or Device core).
> 
> Currently the pinctrl system combines what is called "default"
> and "active" into one, assuming that all devices shall come up
> in the active state.
> 
> Also we haven't seen a device that need some "off" state that
> is different from "sleep".

Right, this is what I've been wondering too.

Do we really need "idle", "sleep", "off"? Or is "idle" enough?
Or "idle" and "sleep"?

Only one of the should be set at a time, but it would be nice
to handle most cases in a generic way in drivers/base/pinctrl.c.
 
> If you want to drive this state list home you have to give a
> *real world example*.
> 
> I want to see a *real* example, for a device and it's pins,
> that define totally different things for these states, as a
> rationale.

Yeah me too :)
 
> Else we are just defining states to make nice figures or mental
> maps and that is not helpful for drivers writers.

Regards,

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

Re: [PATCH] usb: dwc3: core: continue probe even if usb3 phy is not available

[Michael Grzeschik]

Hi,

On Thu, Jun 27, 2013 at 09:35:26AM +0300, Felipe Balbi wrote:
> Hi,
> 
> On Thu, Jun 27, 2013 at 08:14:16AM +0200, Michael Grzeschik wrote:
> > > > right, but in DT you will define both instances and each instance will
> > > > have a seaparate snps,maximum_speed attribute :-)
> > > >
> > > > I'm now considering if we should make maximum_speed a generic attribute,
> > > > Kishon ? Alex ? Alan ?
> > > >
> > > > anyone else needs such thing ?
> > > 
> > > We have a force-full-speed attibute for chipidea on the way. This
> > > maximum_speed looks like a more generic alternative. Michael, what say
> > > you?
> > 
> > The maximum_speed attribute sounds more reasonable. I will change my
> > patch to it.
> 
> thanks, perhaps we can add a generic helper in udc-core or usb-common ?

As this function is not only udc specific, this should go into usb-common.
But right, we should go with a helper here. I will write one in addition
to my full-speed patch as first user of it.

Thanks,
Michael

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
--
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: regression caused by commit 8357b48549e17b3e4e402c7f977b65708922e60f

[Felipe Balbi]

On Thu, Jun 27, 2013 at 04:36:55PM +1000, Stephen Rothwell wrote:
> Hi,
> 
> On Thu, 27 Jun 2013 09:14:19 +0300 Felipe Balbi  wrote:
> >
> > after commit 8357b48549e17b3e4e402c7f977b65708922e60f,
> > omap2plus_defconfig doesn't 'hold' the answer to USB Gadget Drivers
> > anymore. Everytime I run oldconfig, it asks me again and again what USB
> > Gadget Drivers should be (M/y/?).
> > 
> > That's certainly not expected considering it wasn't like that before.
> 
> That commit has been reverted in today's kbuild tree and thus in today's
> linux-next.

thanks, I should fetch again :-)

-- 
balbi


signature.asc
Description: Digital signature