OMAP support in mainline?

OMAP support in mainline?

[Kalle Valo]

Hello Linux OMAP community,

I have seen a lot of patches going to Russell and general talk about
mainline support. What is actually the current situation? Is there
hope to have good support in mainline soon? If yes, when?

Unsurprisingly I'm especially interested about N800/N810 support :)

-- 
Kalle Valo

Re: OMAP support in mainline?

[Paul Walmsley]

On Tue, 16 Sep 2008, Kalle Valo wrote:

> Hello Linux OMAP community,
> 
> I have seen a lot of patches going to Russell and general talk about
> mainline support. What is actually the current situation? Is there
> hope to have good support in mainline soon? If yes, when?
> 
> Unsurprisingly I'm especially interested about N800/N810 support :)

Parts of N800/N810 are still broken in linux-omap tree.  At least sound 
did not work as of early September, and MMC still emits errors as 
described in:

http://www.mail-archive.com/linux-omap@vger.kernel.org/msg02499.html

Don't recall what the current LM8323 status is.


- Paul

Re: OMAP support in mainline?

[Felipe Balbi]

On Tue, Sep 16, 2008 at 09:13:21AM -0600, Paul Walmsley wrote:
> On Tue, 16 Sep 2008, Kalle Valo wrote:
> 
> > Hello Linux OMAP community,
> > 
> > I have seen a lot of patches going to Russell and general talk about
> > mainline support. What is actually the current situation? Is there
> > hope to have good support in mainline soon? If yes, when?
> > 
> > Unsurprisingly I'm especially interested about N800/N810 support :)
> 
> Parts of N800/N810 are still broken in linux-omap tree.  At least sound 
> did not work as of early September, and MMC still emits errors as 
> described in:
> 
> http://www.mail-archive.com/linux-omap@vger.kernel.org/msg02499.html
> 
> Don't recall what the current LM8323 status is.

Bluetooth is also missing on mainline, but the driver needs some rework.

-- 
balbi

Re: OMAP support in mainline?

[Tony Lindgren]

* Felipe Balbi <me@felipebalbi.com> [080916 11:42]:
> On Tue, Sep 16, 2008 at 09:13:21AM -0600, Paul Walmsley wrote:
> > On Tue, 16 Sep 2008, Kalle Valo wrote:
> > 
> > > Hello Linux OMAP community,
> > > 
> > > I have seen a lot of patches going to Russell and general talk about
> > > mainline support. What is actually the current situation? Is there
> > > hope to have good support in mainline soon? If yes, when?
> > > 
> > > Unsurprisingly I'm especially interested about N800/N810 support :)
> > 
> > Parts of N800/N810 are still broken in linux-omap tree.  At least sound 
> > did not work as of early September, and MMC still emits errors as 
> > described in:
> > 
> > http://www.mail-archive.com/linux-omap@vger.kernel.org/msg02499.html
> > 
> > Don't recall what the current LM8323 status is.
> 
> Bluetooth is also missing on mainline, but the driver needs some rework.

Hopefully we'll get all core 24xx and 34xx files integrated soon. But
then there are tons of board-*.c files missing from mainline that
probably need to be cleaned up a bit. 

Tony

Re: OMAP support in mainline?

[Jarkko Nikula]

On Tue, 16 Sep 2008 16:25:06 -0700
"ext Tony Lindgren" <tony@atomide.com> wrote:

> Hopefully we'll get all core 24xx and 34xx files integrated soon. But
> then there are tons of board-*.c files missing from mainline that
> probably need to be cleaned up a bit. 
> 
I think one good measure for this whole work when one can can run
Beagle or Overo with mainline kernel.

That would require some "spring-cleaning" effort and getting core,
TWL4030, etc. patches out but then it is much more easier to send
remaining board files and other drivers to their relevant lists.


Jarkko

Re: OMAP support in mainline?

[David Brownell]

On Tuesday 16 September 2008, Jarkko Nikula wrote:
> 
> I think one good measure for this whole work when one can can run
> Beagle or Overo with mainline kernel.

Yes ... ideally for 2.6.28 for both.  The Overo boards handed
out at the kernel summit are a bit visible right now as not
yet booting with mainline code.  :)


> That would require some "spring-cleaning" effort and getting core,
> TWL4030, etc. patches out but then it is much more easier to send
> remaining board files and other drivers to their relevant lists.

My quick audit:

  - core updates
  - board files
  - twl4030 ... converted to new-style, gpiolib, drivers/mfd
  - hsmmc
  - omap2 nand
  - various pending musb updates

FB support would be nice too, but IMO not if that means rushing
the updates discussed lately.  Not all the TWL components would
need to go upstream at once.

- Dave

Re: OMAP support in mainline?

[Budhee Jamaich]

On Wed, Sep 17, 2008 at 2:25 AM, Tony Lindgren <tony@atomide.com> wrote:
> Hopefully we'll get all core 24xx and 34xx files integrated soon. But
> then there are tons of board-*.c files missing from mainline that
> probably need to be cleaned up a bit.

What about sending the board to standby via /sys/power/state and
waking it up via pressing one of the keypad buttons ? Is it already
supported in mainline ?

Re: OMAP support in mainline?

[Kalle Valo]

Jarkko Nikula <jarkko.nikula@nokia.com> writes:

> On Tue, 16 Sep 2008 16:25:06 -0700
> "ext Tony Lindgren" <tony@atomide.com> wrote:
>
>> Hopefully we'll get all core 24xx and 34xx files integrated soon. But
>> then there are tons of board-*.c files missing from mainline that
>> probably need to be cleaned up a bit. 
>> 
> I think one good measure for this whole work when one can can run
> Beagle or Overo with mainline kernel.

I really would like to run N800/N810 with mainline kernel (ie. with
Linus' tree), at least get it booting. For example, sound and
bluetooth are not that important for me right now. What kind of
cleanup is needed for that?

-- 
Kalle Valo

Re: OMAP support in mainline?

[Koen Kooi]

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


Op 17 sep 2008, om 07:55 heeft David Brownell het volgende geschreven:

> On Tuesday 16 September 2008, Jarkko Nikula wrote:
>>
>> I think one good measure for this whole work when one can can run
>> Beagle or Overo with mainline kernel.
>
> Yes ... ideally for 2.6.28 for both.  The Overo boards handed
> out at the kernel summit are a bit visible right now as not
> yet booting with mainline code.  :)

And they aren't working too well with current l-o git either with MUSB  
being broken. There's a patch to fix client mode, but host mode still  
isn't working.

regards,

Koen




>
>
>
>> That would require some "spring-cleaning" effort and getting core,
>> TWL4030, etc. patches out but then it is much more easier to send
>> remaining board files and other drivers to their relevant lists.
>
> My quick audit:
>
>  - core updates
>  - board files
>  - twl4030 ... converted to new-style, gpiolib, drivers/mfd
>  - hsmmc
>  - omap2 nand
>  - various pending musb updates
>
> FB support would be nice too, but IMO not if that means rushing
> the updates discussed lately.  Not all the TWL components would
> need to go upstream at once.
>
> - Dave
> --
> To unsubscribe from this list: send the line "unsubscribe linux- 
> omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]

Re: OMAP support in mainline?

[Steve Sakoman]

On Wed, Sep 17, 2008 at 12:16 AM, Koen Kooi <k.kooi@student.utwente.nl> wrote:

> And they aren't working too well with current l-o git either with MUSB being
> broken. There's a patch to fix client mode, but host mode still isn't
> working.

Host mode musb is working just fine on Overo with the "set
transceiver" patch.  Not sure why you are having trouble with Beagle
(and can't check since I don't have my Beagle board with me at the
moment)

Steve

Re: OMAP support in mainline?

[Koen Kooi]

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


Op 17 sep 2008, om 14:24 heeft Steve Sakoman het volgende geschreven:

> On Wed, Sep 17, 2008 at 12:16 AM, Koen Kooi  
> <k.kooi@student.utwente.nl> wrote:
>
>> And they aren't working too well with current l-o git either with  
>> MUSB being
>> broken. There's a patch to fix client mode, but host mode still isn't
>> working.
>
> Host mode musb is working just fine on Overo with the "set
> transceiver" patch.  Not sure why you are having trouble with Beagle
> (and can't check since I don't have my Beagle board with me at the
> moment)

I should clarify: OTG mode with a host cable doesn't work in .27rc, it  
does work in 2.6.26. I haven't tried specifying pure hostmode, only OTG.
I would try it on the evm as well, but that is having serious irq  
issues with .27rc, pressing a key on the keypad triggers an irq  
overrun, ethernet gives an oops on boot when trying to register and  
irq etc,etc. 2.6.27 is looking really, really bad on omap3 at the  
moment.

regards,

Koen


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


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]

Re: OMAP support in mainline?

[Tony Lindgren]

* Kalle Valo <kalle.valo@nokia.com> [080916 23:32]:
> Jarkko Nikula <jarkko.nikula@nokia.com> writes:
> 
> > On Tue, 16 Sep 2008 16:25:06 -0700
> > "ext Tony Lindgren" <tony@atomide.com> wrote:
> >
> >> Hopefully we'll get all core 24xx and 34xx files integrated soon. But
> >> then there are tons of board-*.c files missing from mainline that
> >> probably need to be cleaned up a bit. 
> >> 
> > I think one good measure for this whole work when one can can run
> > Beagle or Overo with mainline kernel.
> 
> I really would like to run N800/N810 with mainline kernel (ie. with
> Linus' tree), at least get it booting. For example, sound and
> bluetooth are not that important for me right now. What kind of
> cleanup is needed for that?

Well here are few things that come to mind for N8X0:

- drivers/cbus needs to be cleaned and submitted via LKML

- arch/arm/mach-omap2/board-n800*.c maybe should be called board-n8x0*.c
  instead?

- blizzard_enable_clocks() needs to create a virtual clock so that
  drivers/video/omap/ can just call clk_enable/disable(). Other board
  files may need this done too, at least nokia770*.c has the same
  problem

Regards,

Tony

Re: OMAP support in mainline?

[Tony Lindgren]

* Tony Lindgren <tony@atomide.com> [080917 09:55]:
> * Kalle Valo <kalle.valo@nokia.com> [080916 23:32]:
> > Jarkko Nikula <jarkko.nikula@nokia.com> writes:
> > 
> > > On Tue, 16 Sep 2008 16:25:06 -0700
> > > "ext Tony Lindgren" <tony@atomide.com> wrote:
> > >
> > >> Hopefully we'll get all core 24xx and 34xx files integrated soon. But
> > >> then there are tons of board-*.c files missing from mainline that
> > >> probably need to be cleaned up a bit. 
> > >> 
> > > I think one good measure for this whole work when one can can run
> > > Beagle or Overo with mainline kernel.
> > 
> > I really would like to run N800/N810 with mainline kernel (ie. with
> > Linus' tree), at least get it booting. For example, sound and
> > bluetooth are not that important for me right now. What kind of
> > cleanup is needed for that?
> 
> Well here are few things that come to mind for N8X0:
> 
> - drivers/cbus needs to be cleaned and submitted via LKML
> 
> - arch/arm/mach-omap2/board-n800*.c maybe should be called board-n8x0*.c
>   instead?
> 
> - blizzard_enable_clocks() needs to create a virtual clock so that
>   drivers/video/omap/ can just call clk_enable/disable(). Other board
>   files may need this done too, at least nokia770*.c has the same
>   problem

Oh, one more thing: All the ATAG_OMAP data needs to be set in the
board-*.c files as platform_data, omap specific ATAGs won't be going
to mainline as discussed earlier on linux-arm-kernel.

If any ATAGs are needed, such as for the serial console, it needs to
be a generic ATAG for whole arch/arm.

Tony

Re: OMAP support in mainline?

[Russell King - ARM Linux]

On Wed, Sep 17, 2008 at 09:57:25AM -0700, Tony Lindgren wrote:
> If any ATAGs are needed, such as for the serial console, it needs to
> be a generic ATAG for whole arch/arm.

Why is it needed for serial console anyway?  We already have a cross-
architecture way of defining the console - it's the 'console=' argument
given to the kernel at boot time via the argument string.

Re: OMAP support in mainline?

[Felipe Balbi]

On Wed, Sep 17, 2008 at 03:23:49PM +0200, ext Koen Kooi wrote:
>
> Op 17 sep 2008, om 14:24 heeft Steve Sakoman het volgende geschreven:
>
>> On Wed, Sep 17, 2008 at 12:16 AM, Koen Kooi <k.kooi@student.utwente.nl> 
>> wrote:
>>
>>> And they aren't working too well with current l-o git either with MUSB 
>>> being
>>> broken. There's a patch to fix client mode, but host mode still isn't
>>> working.
>>
>> Host mode musb is working just fine on Overo with the "set
>> transceiver" patch.  Not sure why you are having trouble with Beagle
>> (and can't check since I don't have my Beagle board with me at the
>> moment)
>
> I should clarify: OTG mode with a host cable doesn't work in .27rc, it does 
> work in 2.6.26. I haven't tried specifying pure hostmode, only OTG.
> I would try it on the evm as well, but that is having serious irq issues 
> with .27rc, pressing a key on the keypad triggers an irq overrun, ethernet 
> gives an oops on boot when trying to register and irq etc,etc. 2.6.27 is 
> looking really, really bad on omap3 at the moment.

Yeah, we lost some musb history when it went to mainline. I didn't test
this patch yet cuz I've been quite busy at work, but it should make
beagle work. Could you tell me if makes it work ?

diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index 9d2dcb1..f7fe91e 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -215,12 +215,14 @@ void musb_platform_set_mode(struct musb *musb, u8 musb_mode)

 int __init musb_platform_init(struct musb *musb)
 {
+       struct otg_transceiver *xceiv = otg_get_transceiver();
        u32 l;

 #if defined(CONFIG_ARCH_OMAP2430)
        omap_cfg_reg(AE5_2430_USB0HS_STP);
 #endif

+       memcpy(musb->xceiv, xceiv, sizeof(*xceiv));
        musb_platform_resume(musb);

        l = omap_readl(OTG_SYSCONFIG);


-- 
balbi

RE: OMAP support in mainline?

[Pandita, Vikram]

> -----Original Message-----
> From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-owner@vger.kernel.org] On Behalf Of Felipe
> Balbi
> Sent: Thursday, September 18, 2008 3:26 PM
> To: ext Koen Kooi
> Cc: linux-omap@vger.kernel.org Mailing List
> Subject: Re: OMAP support in mainline?
> 
> On Wed, Sep 17, 2008 at 03:23:49PM +0200, ext Koen Kooi wrote:
> >
> > Op 17 sep 2008, om 14:24 heeft Steve Sakoman het volgende geschreven:
> >
> >> On Wed, Sep 17, 2008 at 12:16 AM, Koen Kooi <k.kooi@student.utwente.nl>
> >> wrote:
> >>
> >>> And they aren't working too well with current l-o git either with MUSB
> >>> being
> >>> broken. There's a patch to fix client mode, but host mode still isn't
> >>> working.
> >>
> >> Host mode musb is working just fine on Overo with the "set
> >> transceiver" patch.  Not sure why you are having trouble with Beagle
> >> (and can't check since I don't have my Beagle board with me at the
> >> moment)
> >
> > I should clarify: OTG mode with a host cable doesn't work in .27rc, it does
> > work in 2.6.26. I haven't tried specifying pure hostmode, only OTG.
> > I would try it on the evm as well, but that is having serious irq issues
> > with .27rc, pressing a key on the keypad triggers an irq overrun, ethernet
> > gives an oops on boot when trying to register and irq etc,etc. 2.6.27 is
> > looking really, really bad on omap3 at the moment.

Omapzoom.org I got the musb driver working for 2.6.27rc6.
Though there will be additional features of MUSB like OFF mode support, System DMA support, but the code base is good working reference on 2.6.27rc6.

For reference you can check the branch: branch_2.6.27rc6_migration
http://git.omapzoom.org/?p=omapkernel;a=shortlog;h=refs/heads/branch_2.6.27rc6_migration


> 
> Yeah, we lost some musb history when it went to mainline. I didn't test
> this patch yet cuz I've been quite busy at work, but it should make
> beagle work. Could you tell me if makes it work ?
> 
> diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
> index 9d2dcb1..f7fe91e 100644
> --- a/drivers/usb/musb/omap2430.c
> +++ b/drivers/usb/musb/omap2430.c
> @@ -215,12 +215,14 @@ void musb_platform_set_mode(struct musb *musb, u8 musb_mode)
> 
>  int __init musb_platform_init(struct musb *musb)
>  {
> +       struct otg_transceiver *xceiv = otg_get_transceiver();
>         u32 l;
> 
>  #if defined(CONFIG_ARCH_OMAP2430)
>         omap_cfg_reg(AE5_2430_USB0HS_STP);
>  #endif
> 
> +       memcpy(musb->xceiv, xceiv, sizeof(*xceiv));
>         musb_platform_resume(musb);
> 
>         l = omap_readl(OTG_SYSCONFIG);
> 
> 
> --
> balbi
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: OMAP support in mainline?

[Koen Kooi]

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


Op 18 sep 2008, om 11:55 heeft Felipe Balbi het volgende geschreven:

> On Wed, Sep 17, 2008 at 03:23:49PM +0200, ext Koen Kooi wrote:
>>
>> Op 17 sep 2008, om 14:24 heeft Steve Sakoman het volgende geschreven:
>>
>>> On Wed, Sep 17, 2008 at 12:16 AM, Koen Kooi <k.kooi@student.utwente.nl 
>>> >
>>> wrote:
>>>
>>>> And they aren't working too well with current l-o git either with  
>>>> MUSB
>>>> being
>>>> broken. There's a patch to fix client mode, but host mode still  
>>>> isn't
>>>> working.
>>>
>>> Host mode musb is working just fine on Overo with the "set
>>> transceiver" patch.  Not sure why you are having trouble with Beagle
>>> (and can't check since I don't have my Beagle board with me at the
>>> moment)
>>
>> I should clarify: OTG mode with a host cable doesn't work in .27rc,  
>> it does
>> work in 2.6.26. I haven't tried specifying pure hostmode, only OTG.
>> I would try it on the evm as well, but that is having serious irq  
>> issues
>> with .27rc, pressing a key on the keypad triggers an irq overrun,  
>> ethernet
>> gives an oops on boot when trying to register and irq etc,etc.  
>> 2.6.27 is
>> looking really, really bad on omap3 at the moment.
>
> Yeah, we lost some musb history when it went to mainline. I didn't  
> test
> this patch yet cuz I've been quite busy at work, but it should make
> beagle work. Could you tell me if makes it work ?
>
> diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
> index 9d2dcb1..f7fe91e 100644
> --- a/drivers/usb/musb/omap2430.c
> +++ b/drivers/usb/musb/omap2430.c
> @@ -215,12 +215,14 @@ void musb_platform_set_mode(struct musb *musb,  
> u8 musb_mode)
>
> int __init musb_platform_init(struct musb *musb)
> {
> +       struct otg_transceiver *xceiv = otg_get_transceiver();
>        u32 l;
>
> #if defined(CONFIG_ARCH_OMAP2430)
>        omap_cfg_reg(AE5_2430_USB0HS_STP);
> #endif
>
> +       memcpy(musb->xceiv, xceiv, sizeof(*xceiv));
>        musb_platform_resume(musb);
>
>        l = omap_readl(OTG_SYSCONFIG);
>

That looks like http://gitweb.openembedded.net/?p=org.openembedded.dev.git;a=blob;f=packages/linux/linux-omap/musb-mru-otgfix.diff;h=767858b8b1580ed7cd67d8e7627301600dda111c;hb=d733dd05e030a67dfbf4540fa1a041adccbe4ffc 
  which doesn't work for me :(

And, no, I'm not going to try omapzoom stuff, I want it working on the  
canonical linux-omap kernel, not some corporate version with god knows  
how many hacks.

regards,

Koen



>
> -- 
> balbi
>


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]

Re: OMAP support in mainline?

[Felipe Balbi]

On Thu, Sep 18, 2008 at 01:16:55PM +0200, ext Koen Kooi wrote:
>
> Op 18 sep 2008, om 11:55 heeft Felipe Balbi het volgende geschreven:
>
>> On Wed, Sep 17, 2008 at 03:23:49PM +0200, ext Koen Kooi wrote:
>>>
>>> Op 17 sep 2008, om 14:24 heeft Steve Sakoman het volgende geschreven:
>>>
>>>> On Wed, Sep 17, 2008 at 12:16 AM, Koen Kooi <k.kooi@student.utwente.nl>
>>>> wrote:
>>>>
>>>>> And they aren't working too well with current l-o git either with MUSB
>>>>> being
>>>>> broken. There's a patch to fix client mode, but host mode still isn't
>>>>> working.
>>>>
>>>> Host mode musb is working just fine on Overo with the "set
>>>> transceiver" patch.  Not sure why you are having trouble with Beagle
>>>> (and can't check since I don't have my Beagle board with me at the
>>>> moment)
>>>
>>> I should clarify: OTG mode with a host cable doesn't work in .27rc, it 
>>> does
>>> work in 2.6.26. I haven't tried specifying pure hostmode, only OTG.
>>> I would try it on the evm as well, but that is having serious irq issues
>>> with .27rc, pressing a key on the keypad triggers an irq overrun, 
>>> ethernet
>>> gives an oops on boot when trying to register and irq etc,etc. 2.6.27 is
>>> looking really, really bad on omap3 at the moment.
>>
>> Yeah, we lost some musb history when it went to mainline. I didn't test
>> this patch yet cuz I've been quite busy at work, but it should make
>> beagle work. Could you tell me if makes it work ?
>>
>> diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
>> index 9d2dcb1..f7fe91e 100644
>> --- a/drivers/usb/musb/omap2430.c
>> +++ b/drivers/usb/musb/omap2430.c
>> @@ -215,12 +215,14 @@ void musb_platform_set_mode(struct musb *musb, u8 
>> musb_mode)
>>
>> int __init musb_platform_init(struct musb *musb)
>> {
>> +       struct otg_transceiver *xceiv = otg_get_transceiver();
>>        u32 l;
>>
>> #if defined(CONFIG_ARCH_OMAP2430)
>>        omap_cfg_reg(AE5_2430_USB0HS_STP);
>> #endif
>>
>> +       memcpy(musb->xceiv, xceiv, sizeof(*xceiv));
>>        musb_platform_resume(musb);
>>
>>        l = omap_readl(OTG_SYSCONFIG);
>>
>
> That looks like 
> http://gitweb.openembedded.net/?p=org.openembedded.dev.git;a=blob;f=packages/linux/linux-omap/musb-mru-otgfix.diff;h=767858b8b1580ed7cd67d8e7627301600dda111c;hb=d733dd05e030a67dfbf4540fa1a041adccbe4ffc 
> which doesn't work for me :(

I got a report from another beagle user that this patch of mine is helping.
Well, if I have extra time I'll try it out on my 3430sdp and beagle ;-)

> And, no, I'm not going to try omapzoom stuff, I want it working on the 
> canonical linux-omap kernel, not some corporate version with god knows how 
> many hacks.

That was just a suggestion. We're just trying to narrow down the issues.
If it works with omapzoom.org, then we just diff both drivers and get
the fix to l-o as well ;-)

-- 
balbi

RE: OMAP support in mainline?

[Pandita, Vikram]

> -----Original Message-----
> From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-owner@vger.kernel.org] On Behalf Of Koen
> Kooi
> Sent: Thursday, September 18, 2008 4:47 PM
> To: felipe.balbi@nokia.com
> Cc: linux-omap@vger.kernel.org Mailing List
> Subject: Re: OMAP support in mainline?
> 
> 
> Op 18 sep 2008, om 11:55 heeft Felipe Balbi het volgende geschreven:
> 
> > On Wed, Sep 17, 2008 at 03:23:49PM +0200, ext Koen Kooi wrote:
> >>
> >> Op 17 sep 2008, om 14:24 heeft Steve Sakoman het volgende geschreven:
> >>
> >>> On Wed, Sep 17, 2008 at 12:16 AM, Koen Kooi <k.kooi@student.utwente.nl
> >>> >
> >>> wrote:
> >
> 
> That looks like
> http://gitweb.openembedded.net/?p=org.openembedded.dev.git;a=blob;f=packages/linux/linux-omap/musb-
> mru-
> otgfix.diff;h=767858b8b1580ed7cd67d8e7627301600dda111c;hb=d733dd05e030a67dfbf4540fa1a041adccbe4ffc
>   which doesn't work for me :(
> 
> And, no, I'm not going to try omapzoom stuff, I want it working on the
> canonical linux-omap kernel, not some corporate version with god knows
> how many hacks.

Your wish. 
I thought debugging and fixing the issue was more important than the source of the fix !!!

> 
> regards,
> 
> Koen
> 
> 
> 
> >
> > --
> > balbi
> >

RE: OMAP support in mainline?

[Igor Stoppa]

On Thu, 2008-09-18 at 17:21 +0530, ext Pandita, Vikram wrote:

> > And, no, I'm not going to try omapzoom stuff, I want it working on the
> > canonical linux-omap kernel, not some corporate version with god knows
> > how many hacks.
> 
> Your wish. 
> I thought debugging and fixing the issue was more important than the source of the fix !!!

YES!
You have precisely exposed the problem with TI.
It could not have been formulated in a better way.

-- 

Cheers, Igor

---

Igor Stoppa
Maemo Software - Nokia Devices R&D - Helsinki

RE: OMAP support in mainline?

[Pandita, Vikram]

> -----Original Message-----
> From: Igor Stoppa [mailto:igor.stoppa@nokia.com]
> Sent: Thursday, September 18, 2008 5:24 PM
> To: Pandita, Vikram
> Cc: Koen Kooi; felipe.balbi@nokia.com; linux-omap@vger.kernel.org Mailing List
> Subject: RE: OMAP support in mainline?
> 
> On Thu, 2008-09-18 at 17:21 +0530, ext Pandita, Vikram wrote:
> 
> > > And, no, I'm not going to try omapzoom stuff, I want it working on the
> > > canonical linux-omap kernel, not some corporate version with god knows
> > > how many hacks.
> >
> > Your wish.
> > I thought debugging and fixing the issue was more important than the source of the fix !!!
> 
> YES!
> You have precisely exposed the problem with TI.

Not sure what problem you are referring to?
Exposing advanced features to outside world cannot be an issue for sure.

Example MUSB on zoom has additional features like:  
OFF Mode support
System DMA implementation

It is up to the community to see the features and comment.

> It could not have been formulated in a better way.
> 
> --
> 
> Cheers, Igor
> 
> ---
> 
> Igor Stoppa
> Maemo Software - Nokia Devices R&D - Helsinki

RE: OMAP support in mainline?

[Woodruff, Richard]

> > > And, no, I'm not going to try omapzoom stuff, I want it working on
> the
> > > canonical linux-omap kernel, not some corporate version with god
> knows
> > > how many hacks.
> >
> > Your wish.
> > I thought debugging and fixing the issue was more important than the
> source of the fix !!!
>
> YES!
> You have precisely exposed the problem with TI.
> It could not have been formulated in a better way.

Where do you think the lineage of the hardware and software is?  Do you believe it just jumped into being in open source?  All hardware and software is full of deliberate design and hacks. Its true cooperate design constraints are driven by the bottom line and for some in open source it is not.

If I look at this particular MUSB hardware/software stack I know it's a mix of purest work, semi-pure (sponsored by cooperate), and cooperate.  A lot of parties have advanced the technology with different agendas.  I've followed it from its start of life in hardware to its current state.

One positive bit for this block is most of the parties today are publicly making their work and specifications available. Hopefully with this enablement code will be free to evolve.

It would be nice if whatever code was on the main branch was not so frequently broken. Maybe those who are interested in it should work on a branch in the tree and periodically merge back at stable points.  Maybe finally merged drivers at kernel.org will server that purpose and the local tree's can be all development.

Where we need something working for a customer 'today' we export a tree to do this. ...many strong statements in open source might be grouped as religious, lobbyist, or novice. We all use some mix of these in work.  What's your mix on this issue?

Regards,
Richard W.

Re: OMAP support in mainline?

[David Brownell]

On Thursday 18 September 2008, Pandita, Vikram wrote:
> 
> > And, no, I'm not going to try omapzoom stuff, I want it working on the
> > canonical linux-omap kernel, not some corporate version with god knows
> > how many hacks.
> 
> Your wish. 
> I thought debugging and fixing the issue was more important than the
> source of the fix !!! 

Right, but the point is to fix the linux-omap tree...
switching to zoom kernels would be a non-trivial detour.

Re: OMAP support in mainline?

[David Brownell]

On Thursday 18 September 2008, Woodruff, Richard wrote:
> It would be nice if whatever code was on the main branch was not
> so frequently broken.

That's (at least) a current problem.  And the issue is how
to fix it... a *big* part of that involves having enough
(and current-enough) OMAP code in mainline that using one
of the OMAP branches (linux-omap, zoom, etc) isn't the
only realistic choice.


> Maybe those who are interested in it should work on a branch
> in the tree and periodically merge back at stable points.

Right, the basic model for code in mainline is that the
code there should be stable, with updates merged during
the RC0 window and otherwise just bugfixes.

Problem right now:  it seems most development on OMAP
branches (BTW, having two wastes effort/resources) isn't
working within that model.  Movement upstream is sluggish


> Maybe finally merged drivers at kernel.org will server that
> purpose and the local tree's can be all development.     

That requires discipline that has to some extent been missing.
Consider just the hsmmc driver ... it's been in OMAP branches
for how long now?  Yet it's never been submitted upstream.

- Dave

RE: OMAP support in mainline?

[Igor Stoppa]

On Thu, 2008-09-18 at 08:36 -0500, ext Woodruff, Richard wrote:

> Where do you think the lineage of the hardware and software is?  Do you believe it just jumped into being in open source?  All hardware and software is full of deliberate design and hacks. Its true cooperate design constraints are driven by the bottom line and for some in open source it is not.

Getting the HW to work somewhere is not good enough. It must be
supported in mainline, the more code you generate out of mainline, the
less likely anybody can get it to work after a while and it slows down
everybody.

<snip>

> It would be nice if whatever code was on the main branch was not so frequently broken. 

That's why having more people working on the same code and doing review
would help.

> Maybe those who are interested in it should work on a branch in the tree and periodically merge back at stable points.  Maybe finally merged drivers at kernel.org will server that purpose and the local tree's can be all development.
> 
> Where we need something working for a customer 'today' we export a tree to do this. ...many strong statements in open source might be grouped as religious, lobbyist, or novice. We all use some mix of these in work.  What's your mix on this issue?

I'm no open source zealot, I'm being just very selfish and I think my
life would be much simpler if there were less trees.

Notice that Kevin Hilman has just created a pm branch from linux-omap,
but that is named actually pm-0 and it means that it will be rebased and
it is expected to disappear and dissolve into the main.

That doesn't really apply to your omapzoom tree.

Notice also that most of the patches not ready for being merged in pm-0,
which justify its existence, are coming from omapzoom.

-- 

Cheers, Igor

---

Igor Stoppa
Maemo Software - Nokia Devices R&D - Helsinki

RE: OMAP support in mainline?

[Woodruff, Richard]

Hi Igor,

> -----Original Message-----
> > Where do you think the lineage of the hardware and software is?  Do
> you believe it just jumped into being in open source?  All hardware and
> software is full of deliberate design and hacks. Its true cooperate
> design constraints are driven by the bottom line and for some in open
> source it is not.
>
> Getting the HW to work somewhere is not good enough. It must be
> supported in mainline, the more code you generate out of mainline, the
> less likely anybody can get it to work after a while and it slows down
> everybody.

Sure. In this case I'm just airing some frustration. It is not like some version of this isn't already shipping years back in N800. Rapid development/advancement is great but there should be a working spot which isn't by just by chance.

In this case a tree is just like a branch.  We have done some new development outside on this branch to enable a new dma mode to boost performance.  Hopefully that will be folded back in before too much time. I think I've seen a patch even. In the past we would have just 2x the performance on some old kernel and made it available.  But probably so out of phase you really had to work to get it.  Today using a current tree it is there and there is a lot better chance we or some community person will push it back.

Maybe a custodian for pieces would help.  This is like what Wolfgang Denk did on u-boot...

> > Maybe those who are interested in it should work on a branch in the
> tree and periodically merge back at stable points.  Maybe finally merged
> drivers at kernel.org will server that purpose and the local tree's can
> be all development.
> >
> > Where we need something working for a customer 'today' we export a
> tree to do this. ...many strong statements in open source might be
> grouped as religious, lobbyist, or novice. We all use some mix of these
> in work.  What's your mix on this issue?
>
> I'm no open source zealot, I'm being just very selfish and I think my
> life would be much simpler if there were less trees.

Probably not more simple, but perhaps more efficient in translating things to mainline. But this does require more compromises then most are able to do. How do you 'rush' some critical piece in?  Rush is very much a relative thing.

This is an area where perhaps branching and tags along with use of kconfig-experimental can help.  This hasn't been explored in the tree.  Tony _DID_ offer to do a branch back in OMAP2. However, we weren't structured to support it then. Even if we were so structured, there was a bit difference in timeline need. We would have done a functional (proven w/test) version 1.0, where others with different constraints would have been shooting for a v3.0. Why not start at a 3.0 you say it in theory its great, you can even skip a 2.0. Who can argue with that?

The answer here lies in the fact that a v3.0 design might catch you an A even if it doesn't work for 2 years in a University but you will get an F in industry if you are on a 1 year cycle.  Most people in business here are aggressive and selfish. And they are not selling the code they are selling the device.

All customers & users are different.  If you are starting a new business you might have 3 years before you need to make money, others want to protect what they have and keep shipping with out change, and yet others are desperate and need something yesterday or they will die.  The way each act and their tradeoffs are at very different thresholds.

To me, it seems you should look at your users and their capabilities and their cycles and try to best harness them to create the best tree possible.  This does lead to some unevenness but it tries to catch all the energy which is out there. If you look at it this way you might be able to plan a 1.0, 2.0, 3.0 on a per piece basis and then let it happen in a distributed way.  Perhaps this is the way upper Linux operates.  Linus can't tailor every bit and has written it is not possible and will drive those who try crazy.

Zealots will say they don't want any of that evil energy, realists and engineers will try to optimize, and marketers will try to take advantage.

This all is too much talk and takes away from more interesting playing with devices. Having different tree's about is kind of natural.  They only way you get away with one are with flexibility and commitment.

> Notice that Kevin Hilman has just created a pm branch from linux-omap,
> but that is named actually pm-0 and it means that it will be rebased and
> it is expected to disappear and dissolve into the main.
>
> That doesn't really apply to your omapzoom tree.
>
> Notice also that most of the patches not ready for being merged in pm-0,
> which justify its existence, are coming from omapzoom.

Yes.  This is great and productive.  Many people have contributed to the patches which his is organizing. The idea for it came from TI/Nokia/Tony/Kevin/Paul dialog. Kevin before as part of MV also contributed to the zoom tree in some form and in many many other places.

Regards,
Richard W.

Re: OMAP support in mainline?

[Koen Kooi]

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


Op 18 sep 2008, om 18:31 heeft David Brownell het volgende geschreven:

> On Thursday 18 September 2008, Pandita, Vikram wrote:
>>
>>> And, no, I'm not going to try omapzoom stuff, I want it working on  
>>> the
>>> canonical linux-omap kernel, not some corporate version with god  
>>> knows
>>> how many hacks.
>>
>> Your wish.
>> I thought debugging and fixing the issue was more important than the
>> source of the fix !!!
>
> Right, but the point is to fix the linux-omap tree...
> switching to zoom kernels would be a non-trivial detour.

Zoom kernels differ too much from l-o to be able to say "musb works  
there, let's just use their musb driver". That is, *if* musb works  
there.

regards,

Koen

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]

MUSB not workin in .27rc6, was: Re: OMAP support in mainline?

[Koen Kooi]

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


Op 18 sep 2008, om 11:55 heeft Felipe Balbi het volgende geschreven:

> On Wed, Sep 17, 2008 at 03:23:49PM +0200, ext Koen Kooi wrote:
>>
>> Op 17 sep 2008, om 14:24 heeft Steve Sakoman het volgende geschreven:
>>
>>> On Wed, Sep 17, 2008 at 12:16 AM, Koen Kooi <k.kooi@student.utwente.nl 
>>> >
>>> wrote:
>>>
>>>> And they aren't working too well with current l-o git either with  
>>>> MUSB
>>>> being
>>>> broken. There's a patch to fix client mode, but host mode still  
>>>> isn't
>>>> working.
>>>
>>> Host mode musb is working just fine on Overo with the "set
>>> transceiver" patch.  Not sure why you are having trouble with Beagle
>>> (and can't check since I don't have my Beagle board with me at the
>>> moment)
>>
>> I should clarify: OTG mode with a host cable doesn't work in .27rc,  
>> it does
>> work in 2.6.26. I haven't tried specifying pure hostmode, only OTG.
>> I would try it on the evm as well, but that is having serious irq  
>> issues
>> with .27rc, pressing a key on the keypad triggers an irq overrun,  
>> ethernet
>> gives an oops on boot when trying to register and irq etc,etc.  
>> 2.6.27 is
>> looking really, really bad on omap3 at the moment.
>
> Yeah, we lost some musb history when it went to mainline. I didn't  
> test
> this patch yet cuz I've been quite busy at work, but it should make
> beagle work. Could you tell me if makes it work ?
>
> diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
> index 9d2dcb1..f7fe91e 100644
> --- a/drivers/usb/musb/omap2430.c
> +++ b/drivers/usb/musb/omap2430.c
> @@ -215,12 +215,14 @@ void musb_platform_set_mode(struct musb *musb,  
> u8 musb_mode)
>
> int __init musb_platform_init(struct musb *musb)
> {
> +       struct otg_transceiver *xceiv = otg_get_transceiver();
>        u32 l;
>
> #if defined(CONFIG_ARCH_OMAP2430)
>        omap_cfg_reg(AE5_2430_USB0HS_STP);
> #endif
>
> +       memcpy(musb->xceiv, xceiv, sizeof(*xceiv));
>        musb_platform_resume(musb);
>
>        l = omap_readl(OTG_SYSCONFIG);

Ok, another datapoint: client mode (tested on beagle by Måns) and host  
mode (tested on overo by Steve) work with a similar patch as above,  
OTG mode is broken (tested on beagle and evm by me).

regards,

Koen



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]

Re: OMAP support in mainline?

[Philip Balister]

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

Steve Sakoman wrote:
> On Wed, Sep 17, 2008 at 12:16 AM, Koen Kooi <k.kooi@student.utwente.nl> wrote:
> 
>> And they aren't working too well with current l-o git either with MUSB being
>> broken. There's a patch to fix client mode, but host mode still isn't
>> working.
> 
> Host mode musb is working just fine on Overo with the "set
> transceiver" patch.  Not sure why you are having trouble with Beagle
> (and can't check since I don't have my Beagle board with me at the
> moment)

Does anyone have any suggestions how to figure out what is broken about 
OTG used a host on the Beagle?

Philip

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3303 bytes --]

Re: OMAP support in mainline?

[Ashwin Bihari]

On Fri, Sep 19, 2008 at 3:10 PM, Philip Balister <philip@balister.org> wrote:
> Steve Sakoman wrote:
>>
>> On Wed, Sep 17, 2008 at 12:16 AM, Koen Kooi <k.kooi@student.utwente.nl>
>> wrote:
>>
>>> And they aren't working too well with current l-o git either with MUSB
>>> being
>>> broken. There's a patch to fix client mode, but host mode still isn't
>>> working.
>>
>> Host mode musb is working just fine on Overo with the "set
>> transceiver" patch.  Not sure why you are having trouble with Beagle
>> (and can't check since I don't have my Beagle board with me at the
>> moment)
>
> Does anyone have any suggestions how to figure out what is broken about OTG
> used a host on the Beagle?
>
> Philip
>

On a related point..I built Kernel v.2.6.27-rc3 from the OMAPZOOM tree
with MUSB OTG support. I plug in the mini-B connector into our board,
and I get the interrupt and proper recognition that a peripheral mode
should be used. When the mini-A connector is plugged in, however,
nothing happens.

Since there is only one interrupt that triggers the check on which
cable-type was plugged in, why would the mini-A cable not cause an
interrupt to be generated?

I've also tried compiling the code in just MUSB HOST. Nothing happens,
when I plug in the mini-B cable, it's detected by markedly less things
happen because I don't have peripheral support.

Regards
~ Ashwin

Re: OMAP support in mainline?

[Koen Kooi]

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


Op 19 sep 2008, om 22:57 heeft Ashwin Bihari het volgende geschreven:

> On Fri, Sep 19, 2008 at 3:10 PM, Philip Balister  
> <philip@balister.org> wrote:
>> Steve Sakoman wrote:
>>>
>>> On Wed, Sep 17, 2008 at 12:16 AM, Koen Kooi <k.kooi@student.utwente.nl 
>>> >
>>> wrote:
>>>
>>>> And they aren't working too well with current l-o git either with  
>>>> MUSB
>>>> being
>>>> broken. There's a patch to fix client mode, but host mode still  
>>>> isn't
>>>> working.
>>>
>>> Host mode musb is working just fine on Overo with the "set
>>> transceiver" patch.  Not sure why you are having trouble with Beagle
>>> (and can't check since I don't have my Beagle board with me at the
>>> moment)
>>
>> Does anyone have any suggestions how to figure out what is broken  
>> about OTG
>> used a host on the Beagle?
>>
>> Philip
>>
>
> On a related point..I built Kernel v.2.6.27-rc3 from the OMAPZOOM tree
> with MUSB OTG support. I plug in the mini-B connector into our board,
> and I get the interrupt and proper recognition that a peripheral mode
> should be used. When the mini-A connector is plugged in, however,
> nothing happens.
>
> Since there is only one interrupt that triggers the check on which
> cable-type was plugged in, why would the mini-A cable not cause an
> interrupt to be generated?

I can crash my evm by pressing a key on the keypad triggering an irq  
storm (see other thread), so it could be that something is wrong with  
irqs in .27rc :(

regards

Koen






>
>
> I've also tried compiling the code in just MUSB HOST. Nothing happens,
> when I plug in the mini-B cable, it's detected by markedly less things
> happen because I don't have peripheral support.
>
> Regards
> ~ Ashwin
> --
> To unsubscribe from this list: send the line "unsubscribe linux- 
> omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]

Re: MUSB not workin in .27rc6, was: Re: OMAP support in mainline?

[Felipe Balbi]

On Fri, Sep 19, 2008 at 06:09:04PM +0200, Koen Kooi wrote:
>
> Op 18 sep 2008, om 11:55 heeft Felipe Balbi het volgende geschreven:
>
>> On Wed, Sep 17, 2008 at 03:23:49PM +0200, ext Koen Kooi wrote:
>>>
>>> Op 17 sep 2008, om 14:24 heeft Steve Sakoman het volgende geschreven:
>>>
>>>> On Wed, Sep 17, 2008 at 12:16 AM, Koen Kooi 
>>>> <k.kooi@student.utwente.nl>
>>>> wrote:
>>>>
>>>>> And they aren't working too well with current l-o git either with 
>>>>> MUSB
>>>>> being
>>>>> broken. There's a patch to fix client mode, but host mode still  
>>>>> isn't
>>>>> working.
>>>>
>>>> Host mode musb is working just fine on Overo with the "set
>>>> transceiver" patch.  Not sure why you are having trouble with Beagle
>>>> (and can't check since I don't have my Beagle board with me at the
>>>> moment)
>>>
>>> I should clarify: OTG mode with a host cable doesn't work in .27rc,  
>>> it does
>>> work in 2.6.26. I haven't tried specifying pure hostmode, only OTG.
>>> I would try it on the evm as well, but that is having serious irq  
>>> issues
>>> with .27rc, pressing a key on the keypad triggers an irq overrun,  
>>> ethernet
>>> gives an oops on boot when trying to register and irq etc,etc.  
>>> 2.6.27 is
>>> looking really, really bad on omap3 at the moment.
>>
>> Yeah, we lost some musb history when it went to mainline. I didn't  
>> test
>> this patch yet cuz I've been quite busy at work, but it should make
>> beagle work. Could you tell me if makes it work ?
>>
>> diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
>> index 9d2dcb1..f7fe91e 100644
>> --- a/drivers/usb/musb/omap2430.c
>> +++ b/drivers/usb/musb/omap2430.c
>> @@ -215,12 +215,14 @@ void musb_platform_set_mode(struct musb *musb,  
>> u8 musb_mode)
>>
>> int __init musb_platform_init(struct musb *musb)
>> {
>> +       struct otg_transceiver *xceiv = otg_get_transceiver();
>>        u32 l;
>>
>> #if defined(CONFIG_ARCH_OMAP2430)
>>        omap_cfg_reg(AE5_2430_USB0HS_STP);
>> #endif
>>
>> +       memcpy(musb->xceiv, xceiv, sizeof(*xceiv));
>>        musb_platform_resume(musb);
>>
>>        l = omap_readl(OTG_SYSCONFIG);
>
> Ok, another datapoint: client mode (tested on beagle by Måns) and host  
> mode (tested on overo by Steve) work with a similar patch as above, OTG 
> mode is broken (tested on beagle and evm by me).

I don't recall having otg (id pin handling) working on omap3. I have
some experimental patches on my local branch (they work, but need
clean up).

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

Re: MUSB not workin in .27rc6, was: Re: OMAP support in mainline?

[Koen Kooi]

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


Op 19 sep 2008, om 23:24 heeft Felipe Balbi het volgende geschreven:

> On Fri, Sep 19, 2008 at 06:09:04PM +0200, Koen Kooi wrote:
>>
>> Op 18 sep 2008, om 11:55 heeft Felipe Balbi het volgende geschreven:
>>
>>> On Wed, Sep 17, 2008 at 03:23:49PM +0200, ext Koen Kooi wrote:
>>>>
>>>> Op 17 sep 2008, om 14:24 heeft Steve Sakoman het volgende  
>>>> geschreven:
>>>>
>>>>> On Wed, Sep 17, 2008 at 12:16 AM, Koen Kooi
>>>>> <k.kooi@student.utwente.nl>
>>>>> wrote:
>>>>>
>>>>>> And they aren't working too well with current l-o git either with
>>>>>> MUSB
>>>>>> being
>>>>>> broken. There's a patch to fix client mode, but host mode still
>>>>>> isn't
>>>>>> working.
>>>>>
>>>>> Host mode musb is working just fine on Overo with the "set
>>>>> transceiver" patch.  Not sure why you are having trouble with  
>>>>> Beagle
>>>>> (and can't check since I don't have my Beagle board with me at the
>>>>> moment)
>>>>
>>>> I should clarify: OTG mode with a host cable doesn't work in .27rc,
>>>> it does
>>>> work in 2.6.26. I haven't tried specifying pure hostmode, only OTG.
>>>> I would try it on the evm as well, but that is having serious irq
>>>> issues
>>>> with .27rc, pressing a key on the keypad triggers an irq overrun,
>>>> ethernet
>>>> gives an oops on boot when trying to register and irq etc,etc.
>>>> 2.6.27 is
>>>> looking really, really bad on omap3 at the moment.
>>>
>>> Yeah, we lost some musb history when it went to mainline. I didn't
>>> test
>>> this patch yet cuz I've been quite busy at work, but it should make
>>> beagle work. Could you tell me if makes it work ?
>>>
>>> diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/ 
>>> omap2430.c
>>> index 9d2dcb1..f7fe91e 100644
>>> --- a/drivers/usb/musb/omap2430.c
>>> +++ b/drivers/usb/musb/omap2430.c
>>> @@ -215,12 +215,14 @@ void musb_platform_set_mode(struct musb *musb,
>>> u8 musb_mode)
>>>
>>> int __init musb_platform_init(struct musb *musb)
>>> {
>>> +       struct otg_transceiver *xceiv = otg_get_transceiver();
>>>       u32 l;
>>>
>>> #if defined(CONFIG_ARCH_OMAP2430)
>>>       omap_cfg_reg(AE5_2430_USB0HS_STP);
>>> #endif
>>>
>>> +       memcpy(musb->xceiv, xceiv, sizeof(*xceiv));
>>>       musb_platform_resume(musb);
>>>
>>>       l = omap_readl(OTG_SYSCONFIG);
>>
>> Ok, another datapoint: client mode (tested on beagle by Måns) and  
>> host
>> mode (tested on overo by Steve) work with a similar patch as above,  
>> OTG
>> mode is broken (tested on beagle and evm by me).
>
> I don't recall having otg (id pin handling) working on omap3. I have
> some experimental patches on my local branch (they work, but need
> clean up).
>

If I boot up the .26 l-o kernel with mini-a attached, it works as  
expected.

regards,

Koen

> -- 
> balbi
>


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]

Re: MUSB not workin in .27rc6, was: Re: OMAP support in mainline?

[Felipe Balbi]

On Fri, Sep 19, 2008 at 11:34:13PM +0200, Koen Kooi wrote:
> If I boot up the .26 l-o kernel with mini-a attached, it works as
> expected.

What happens if you boot without anything attached then, after probe,
attach the mini-/micro-A ? The behavior you describe I recall having
working on one version of 3430sdp. Maybe the loader was keeping
twl4030-usb in a "working" state so we could get the id pin interrupt
before probing the device and after that, it doesn't work as it should.

Doesn't that mean otg is broken even in .26 l-o ? I'll only consider it
working when I attach the cable at any time and struct
xceiv->state switches to a_idle (at least). I don't even care about vbus
since it can (and most likely should) be exported to userland.

-- 
balbi

Re: MUSB not workin in .27rc6, was: Re: OMAP support in mainline?

[David Brownell]

On Friday 19 September 2008, Koen Kooi wrote:
> Ok, another datapoint: client mode (tested on beagle by Måns) and host  
> mode (tested on overo by Steve) work with a similar patch as above,  
> OTG mode is broken (tested on beagle and evm by me).

one issue being that TWL4030 irqs don't cause the OTG state machine
to change from the "Default_B" side to the "Default_A" side ... that
is, ID sense isn't operational.

- Dave

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

Re: MUSB not workin in .27rc6, was: Re: OMAP support in mainline?

[Felipe Balbi]

On Fri, Sep 19, 2008 at 05:49:00PM -0700, David Brownell wrote:
> On Friday 19 September 2008, Koen Kooi wrote:
> > Ok, another datapoint: client mode (tested on beagle by Måns) and host  
> > mode (tested on overo by Steve) work with a similar patch as above,  
> > OTG mode is broken (tested on beagle and evm by me).
> 
> one issue being that TWL4030 irqs don't cause the OTG state machine
> to change from the "Default_B" side to the "Default_A" side ... that
> is, ID sense isn't operational.

Exactly! I have some patches I wrote a few months ago regarding that.

Unfortunately I ran out of time to finish them due to other tasks having
a bigger priority.

I'll try to get back that work, since it's pretty necessary.

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

Re: OMAP support in mainline?

[Måns Rullgård]

Felipe Balbi <felipe.balbi@nokia.com> writes:

> On Wed, Sep 17, 2008 at 03:23:49PM +0200, ext Koen Kooi wrote:
>>
>> Op 17 sep 2008, om 14:24 heeft Steve Sakoman het volgende geschreven:
>>
>>> On Wed, Sep 17, 2008 at 12:16 AM, Koen Kooi <k.kooi@student.utwente.nl> 
>>> wrote:
>>>
>>>> And they aren't working too well with current l-o git either with MUSB 
>>>> being
>>>> broken. There's a patch to fix client mode, but host mode still isn't
>>>> working.
>>>
>>> Host mode musb is working just fine on Overo with the "set
>>> transceiver" patch.  Not sure why you are having trouble with Beagle
>>> (and can't check since I don't have my Beagle board with me at the
>>> moment)
>>
>> I should clarify: OTG mode with a host cable doesn't work in .27rc, it does 
>> work in 2.6.26. I haven't tried specifying pure hostmode, only OTG.
>> I would try it on the evm as well, but that is having serious irq issues 
>> with .27rc, pressing a key on the keypad triggers an irq overrun, ethernet 
>> gives an oops on boot when trying to register and irq etc,etc. 2.6.27 is 
>> looking really, really bad on omap3 at the moment.
>
> Yeah, we lost some musb history when it went to mainline. I didn't test
> this patch yet cuz I've been quite busy at work, but it should make
> beagle work. Could you tell me if makes it work ?
>
> diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
> index 9d2dcb1..f7fe91e 100644
> --- a/drivers/usb/musb/omap2430.c
> +++ b/drivers/usb/musb/omap2430.c
> @@ -215,12 +215,14 @@ void musb_platform_set_mode(struct musb *musb, u8 musb_mode)
>
>  int __init musb_platform_init(struct musb *musb)
>  {
> +       struct otg_transceiver *xceiv = otg_get_transceiver();
>         u32 l;
>
>  #if defined(CONFIG_ARCH_OMAP2430)
>         omap_cfg_reg(AE5_2430_USB0HS_STP);
>  #endif
>
> +       memcpy(musb->xceiv, xceiv, sizeof(*xceiv));

Does this even compile?  It doesn't match my patch, which is simply a
diff between the original l-o tree and what went upstream, and there
that last line looks like this:

+	musb->xceiv = *xceiv;

-- 
Måns Rullgård
mans@mansr.com

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

Re: OMAP support in mainline?

[Felipe Contreras]

On Fri, Sep 19, 2008 at 4:50 PM, Woodruff, Richard <r-woodruff2@ti.com> wrote:
> Hi Igor,
>
>> -----Original Message-----
>> > Where do you think the lineage of the hardware and software is?  Do
>> you believe it just jumped into being in open source?  All hardware and
>> software is full of deliberate design and hacks. Its true cooperate
>> design constraints are driven by the bottom line and for some in open
>> source it is not.
>>
>> Getting the HW to work somewhere is not good enough. It must be
>> supported in mainline, the more code you generate out of mainline, the
>> less likely anybody can get it to work after a while and it slows down
>> everybody.
>
> Sure. In this case I'm just airing some frustration. It is not like some version of this isn't already shipping years back in N800. Rapid development/advancement is great but there should be a working spot which isn't by just by chance.
>
> In this case a tree is just like a branch.  We have done some new development outside on this branch to enable a new dma mode to boost performance.  Hopefully that will be folded back in before too much time. I think I've seen a patch even. In the past we would have just 2x the performance on some old kernel and made it available.  But probably so out of phase you really had to work to get it.  Today using a current tree it is there and there is a lot better chance we or some community person will push it back.

Nobody cares about tree vs branch, the problem is that the branch is
forked from way back in the history.

If you want your changes to be merged you need to rebase continuously,
and not have a single ompazoom branch, but many. That way people can
pick the patches they are interested in.

The difference is a branch for changes to-be-merged vs a fork.

For the vast majority of people, code that is not in upstream, is code
that doesn't exist. That's why good branches should be temporal forks;
as short in time as possible. Permanent forks go against
collaboration.

-- 
Felipe Contreras

RE: OMAP support in mainline?

[Woodruff, Richard]

> From: Felipe Contreras [mailto:felipe.contreras@gmail.com]
> Sent: Sunday, September 21, 2008 10:03 AM

> > In this case a tree is just like a branch.  We have done some new
> development outside on this branch to enable a new dma mode to boost
> performance.  Hopefully that will be folded back in before too much time.
> I think I've seen a patch even. In the past we would have just 2x the
> performance on some old kernel and made it available.  But probably so
> out of phase you really had to work to get it.  Today using a current
> tree it is there and there is a lot better chance we or some community
> person will push it back.

I agree with the way you have put this.  Ideally short branches from a central root would be best.

Part of the challenge here is we would have worked for over a year before chip specifications are releasable. Having a way to absorb the functional parts of that time is something not easily done.  That is not to say we have done it in the best or only way.  It is not always completely done for that matter.

For the legacy drivers or new simple ones keeping in sync or resync'ing makes sense.  It is always the right answer. For long lead time things like ISP-camera, bridge, display, power its really hard. Each of those systems takes a multi-year focus just to get it working with most functionality.  There really isn't a short cut for some of these.

In these areas there usually is someone willing to jump in with their own reasons. But unless they really are capable, supported and willing to devote 1.5 years chances are they can not deliver. There is a real danger of never getting it done.

Regards,
Richard W.

Re: OMAP support in mainline?

[Tony Lindgren]

* Russell King - ARM Linux <linux@arm.linux.org.uk> [080917 13:33]:
> On Wed, Sep 17, 2008 at 09:57:25AM -0700, Tony Lindgren wrote:
> > If any ATAGs are needed, such as for the serial console, it needs to
> > be a generic ATAG for whole arch/arm.
> 
> Why is it needed for serial console anyway?  We already have a cross-
> architecture way of defining the console - it's the 'console=' argument
> given to the kernel at boot time via the argument string.

In this case the hardware changes when the device is connected to a
service jig. The serial port won't work without an external level
converter that is on the jig. I guess console= could set UPF_DEAD
or something similar for 8250.c to ignore that port rather than leave
it out of the plat_serial8250_port.

Regards,

Tony

Re: OMAP support in mainline?

[Russell King - ARM Linux]

On Sun, Sep 21, 2008 at 11:42:33AM -0700, Tony Lindgren wrote:
> * Russell King - ARM Linux <linux@arm.linux.org.uk> [080917 13:33]:
> > On Wed, Sep 17, 2008 at 09:57:25AM -0700, Tony Lindgren wrote:
> > > If any ATAGs are needed, such as for the serial console, it needs to
> > > be a generic ATAG for whole arch/arm.
> > 
> > Why is it needed for serial console anyway?  We already have a cross-
> > architecture way of defining the console - it's the 'console=' argument
> > given to the kernel at boot time via the argument string.
> 
> In this case the hardware changes when the device is connected to a
> service jig. The serial port won't work without an external level
> converter that is on the jig.

If the external level converter is missing, UARTs behave in exactly the
same way as if the cable isn't connected (provided they have the pull-up
on the RXD line to keep it at mark state.)

> I guess console= could set UPF_DEAD or something similar for 8250.c to
> ignore that port rather than leave it out of the plat_serial8250_port.

Well, by passing an ATAG, you're saying that the boot loader has this
knowledge.  So, if the boot loader has this knowledge, why can't it
pass the relevant 'console=' argument appropriate to the hardware
configuration?

If it's already doing this via an ATAG, there's no reason it can't do
it via the command line.

Re: OMAP support in mainline?

[Tony Lindgren]

* Russell King - ARM Linux <linux@arm.linux.org.uk> [080921 11:51]:
> On Sun, Sep 21, 2008 at 11:42:33AM -0700, Tony Lindgren wrote:
> > * Russell King - ARM Linux <linux@arm.linux.org.uk> [080917 13:33]:
> > > On Wed, Sep 17, 2008 at 09:57:25AM -0700, Tony Lindgren wrote:
> > > > If any ATAGs are needed, such as for the serial console, it needs to
> > > > be a generic ATAG for whole arch/arm.
> > > 
> > > Why is it needed for serial console anyway?  We already have a cross-
> > > architecture way of defining the console - it's the 'console=' argument
> > > given to the kernel at boot time via the argument string.
> > 
> > In this case the hardware changes when the device is connected to a
> > service jig. The serial port won't work without an external level
> > converter that is on the jig.
> 
> If the external level converter is missing, UARTs behave in exactly the
> same way as if the cable isn't connected (provided they have the pull-up
> on the RXD line to keep it at mark state.)

Yeah but 8250 does not know anything about the clock fwk right now. And
unless the service jig is connected, you want to have uarts powered down
and clocks off as they block core retention during idle.

Hmm, does 8250.c even currently know about serial ports that should be
ignored and kept powered down?

> > I guess console= could set UPF_DEAD or something similar for 8250.c to
> > ignore that port rather than leave it out of the plat_serial8250_port.
> 
> Well, by passing an ATAG, you're saying that the boot loader has this
> knowledge.  So, if the boot loader has this knowledge, why can't it
> pass the relevant 'console=' argument appropriate to the hardware
> configuration?
> 
> If it's already doing this via an ATAG, there's no reason it can't do
> it via the command line.

Sure console= could be used. Currently the user must tell the bootloader
to enable "RD mode" over USB, which then tells the kernel to enable the
serial port.

It would be nice to specify all the ports and the status (enabled or
disabled) during uart low-level setup code. Current solution of adding
ports depending on the mode also rearranges the order of the ports,
which is not nice.

Regards,

Tony