RE: OMAP support in mainline?

RE: OMAP support in mainline?

[Nathan Monson]

On Thu, Sep 18, 2008 at 3:26PM, Felipe Balbi wrote:
> 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 ?

This patch has been working for me until the latest round of twl4030 changes.

Commit fde13f8fc7de977e71304fd500fed029b41ceb19/"move twl4030-usb to
platform-device" changed subsys_initcall to module_init in
twl4030-usb.

Now, twl4030-usb is initialized after musb.  This means
otg_set_transceiver is called later in boot, so the patch below gets
null back from otg_get_transceiver and oopses on *xceiv.

Unfortunately, without the patch, USB host doesn't work on the BeagleBoard.

Other than this, the new kernel seems to work pretty well for me.

- Nathan

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

Re: OMAP support in mainline?

[Felipe Balbi]

On Fri, Oct 03, 2008 at 12:20:56AM -0700, Nathan Monson wrote:
> On Thu, Sep 18, 2008 at 3:26PM, Felipe Balbi wrote:
> > 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 ?
> 
> This patch has been working for me until the latest round of twl4030 changes.
> 
> Commit fde13f8fc7de977e71304fd500fed029b41ceb19/"move twl4030-usb to
> platform-device" changed subsys_initcall to module_init in
> twl4030-usb.
> 
> Now, twl4030-usb is initialized after musb.  This means
> otg_set_transceiver is called later in boot, so the patch below gets
> null back from otg_get_transceiver and oopses on *xceiv.
> 
> Unfortunately, without the patch, USB host doesn't work on the BeagleBoard.
> 
> Other than this, the new kernel seems to work pretty well for me.

Dave, this will be fixed when i2c with your patch initializing i2c
earlier on boot. Right ?

For now, let's keep subsys_initcall() on twl4030_usb. I'll prepare a
patch and send it really soon.

Thanks for notifying me Nathan.

-- 
balbi

Re: OMAP support in mainline?

[David Brownell]

On Friday 03 October 2008, Felipe Balbi wrote:
> On Fri, Oct 03, 2008 at 12:20:56AM -0700, Nathan Monson wrote:
> > On Thu, Sep 18, 2008 at 3:26PM, Felipe Balbi wrote:
> > > 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 ?
> > 
> > This patch has been working for me until the latest round of twl4030 changes.
> > 
> > Commit fde13f8fc7de977e71304fd500fed029b41ceb19/"move twl4030-usb to
> > platform-device" changed subsys_initcall to module_init in
> > twl4030-usb.
> > 
> > Now, twl4030-usb is initialized after musb.  This means
> > otg_set_transceiver is called later in boot, so the patch below gets
> > null back from otg_get_transceiver and oopses on *xceiv.
> > 
> > Unfortunately, without the patch, USB host doesn't work on the BeagleBoard.

I see it working ... there's a bit of oddness in a host-only config,
devices have to be plugged in after boot, but "doesn't work" seems
pretty wrong.

 
> > Other than this, the new kernel seems to work pretty well for me.
> 
> Dave, this will be fixed when i2c with your patch initializing i2c
> earlier on boot. Right ?

That's just driver model init, allowing i2c drivers to register
earlier, so subsys initcalls can rely on i2c to already have been
initialized ... so, no.

Within a given initcall level -- like subsys, or (later) driver -- the
initialization sequence is controlled by kernel link order, which is
a function of location in the source tree. 


> For now, let's keep subsys_initcall() on twl4030_usb. I'll prepare a
> patch and send it really soon.

That's the right longer-term answer, I think.

- Dave


> 
> Thanks for notifying me Nathan.
> 
> -- 
> balbi
> 
> 

[PATCH] i2c: change twl4030-usb back to subsys_initcall

[Felipe Balbi]

without it, otg_get/set_transceiver won't be useful and
twl4030-usb transceiver won't get to musb code.

Signed-off-by: Felipe Balbi <felipe.balbi@nokia.com>
---
 drivers/i2c/chips/twl4030-usb.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/i2c/chips/twl4030-usb.c b/drivers/i2c/chips/twl4030-usb.c
index 133cc0f..922d7d6 100644
--- a/drivers/i2c/chips/twl4030-usb.c
+++ b/drivers/i2c/chips/twl4030-usb.c
@@ -774,7 +774,7 @@ static int __init twl4030_usb_init(void)
 {
 	return platform_driver_register(&twl4030_driver);
 }
-module_init(twl4030_usb_init);
+subsys_init(twl4030_usb_init);
 
 static void __exit twl4030_usb_exit(void)
 {
-- 
1.6.0.2.307.gc427

Re: [PATCH] i2c: change twl4030-usb back to subsys_initcall

[Koen Kooi]

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


Op 3 okt 2008, om 11:45 heeft Felipe Balbi het volgende geschreven:

> without it, otg_get/set_transceiver won't be useful and
> twl4030-usb transceiver won't get to musb code.

Is the 'fix-something' patch still needed, and if yes, why isn't it in  
l-o git yet?

regards,

Koen


>
>
> Signed-off-by: Felipe Balbi <felipe.balbi@nokia.com>
> ---
> drivers/i2c/chips/twl4030-usb.c |    2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/i2c/chips/twl4030-usb.c b/drivers/i2c/chips/ 
> twl4030-usb.c
> index 133cc0f..922d7d6 100644
> --- a/drivers/i2c/chips/twl4030-usb.c
> +++ b/drivers/i2c/chips/twl4030-usb.c
> @@ -774,7 +774,7 @@ static int __init twl4030_usb_init(void)
> {
> 	return platform_driver_register(&twl4030_driver);
> }
> -module_init(twl4030_usb_init);
> +subsys_init(twl4030_usb_init);
>
> static void __exit twl4030_usb_exit(void)
> {
> -- 
> 1.6.0.2.307.gc427
>
> --
> 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: [PATCH] i2c: change twl4030-usb back to subsys_initcall

[Felipe Balbi]

On Fri, Oct 03, 2008 at 12:19:33PM +0200, ext Koen Kooi wrote:
>
> Op 3 okt 2008, om 11:45 heeft Felipe Balbi het volgende geschreven:
>
>> without it, otg_get/set_transceiver won't be useful and
>> twl4030-usb transceiver won't get to musb code.
>
> Is the 'fix-something' patch still needed, and if yes, why isn't it in l-o 
> git yet?

we need that otg_get/set_transceiver call, yes. But those are omap
specifc. there's a patch pending in linux-usb making those calls
generic.

I'd say we can keep a patch in l-o only untill otg_get/set_transceiver
hooks get accepted.

What say you Tony ?

-- 
balbi

Re: [PATCH] i2c: change twl4030-usb back to subsys_initcall

[Tony Lindgren]

* Felipe Balbi <felipe.balbi@nokia.com> [081003 15:05]:
> On Fri, Oct 03, 2008 at 12:19:33PM +0200, ext Koen Kooi wrote:
> >
> > Op 3 okt 2008, om 11:45 heeft Felipe Balbi het volgende geschreven:
> >
> >> without it, otg_get/set_transceiver won't be useful and
> >> twl4030-usb transceiver won't get to musb code.
> >
> > Is the 'fix-something' patch still needed, and if yes, why isn't it in l-o 
> > git yet?
> 
> we need that otg_get/set_transceiver call, yes. But those are omap
> specifc. there's a patch pending in linux-usb making those calls
> generic.
> 
> I'd say we can keep a patch in l-o only untill otg_get/set_transceiver
> hooks get accepted.
> 
> What say you Tony ?

Sure, we should keep things working for all the omap users while
waiting for the necessary stuff to get merged into mainline.

Felipe, just let me know what we need for l-o tree for musb.

Tony

Re: [PATCH] i2c: change twl4030-usb back to subsys_initcall

[Felipe Balbi]

On Fri, Oct 03, 2008 at 04:28:32PM +0300, Tony Lindgren wrote:
> * Felipe Balbi <felipe.balbi@nokia.com> [081003 15:05]:
> > On Fri, Oct 03, 2008 at 12:19:33PM +0200, ext Koen Kooi wrote:
> > >
> > > Op 3 okt 2008, om 11:45 heeft Felipe Balbi het volgende geschreven:
> > >
> > >> without it, otg_get/set_transceiver won't be useful and
> > >> twl4030-usb transceiver won't get to musb code.
> > >
> > > Is the 'fix-something' patch still needed, and if yes, why isn't it in l-o 
> > > git yet?
> > 
> > we need that otg_get/set_transceiver call, yes. But those are omap
> > specifc. there's a patch pending in linux-usb making those calls
> > generic.
> > 
> > I'd say we can keep a patch in l-o only untill otg_get/set_transceiver
> > hooks get accepted.
> > 
> > What say you Tony ?
> 
> Sure, we should keep things working for all the omap users while
> waiting for the necessary stuff to get merged into mainline.
> 
> Felipe, just let me know what we need for l-o tree for musb.

I'll send you a patch in a jiffy

-- 
balbi

Re: [PATCH] i2c: change twl4030-usb back to subsys_initcall

[Nathan Monson]

On Fri, Oct 3, 2008 at 2:45 AM, Felipe Balbi <felipe.balbi@nokia.com> wrote:
> without it, otg_get/set_transceiver won't be useful and
> twl4030-usb transceiver won't get to musb code.
>
> +subsys_init(twl4030_usb_init);

Should this be subsys_initcall?

- Nathan

Re: [PATCH] i2c: change twl4030-usb back to subsys_initcall

[Felipe Balbi]

On Fri, Oct 03, 2008 at 01:05:14PM -0700, Nathan Monson wrote:
> On Fri, Oct 3, 2008 at 2:45 AM, Felipe Balbi <felipe.balbi@nokia.com> wrote:
> > without it, otg_get/set_transceiver won't be useful and
> > twl4030-usb transceiver won't get to musb code.
> >
> > +subsys_init(twl4030_usb_init);
> 
> Should this be subsys_initcall?

Crap... good catch. Sorry for that. new one coming.

-- 
balbi

[PATCH] i2c: change twl4030-usb back to subsys_initcall

[Felipe Balbi]

without it, otg_get/set_transceiver won't be useful and
twl4030-usb transceiver won't get to musb code.

Signed-off-by: Felipe Balbi <felipe.balbi@nokia.com>
---
 drivers/i2c/chips/twl4030-usb.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/i2c/chips/twl4030-usb.c b/drivers/i2c/chips/twl4030-usb.c
index 133cc0f..922d7d6 100644
--- a/drivers/i2c/chips/twl4030-usb.c
+++ b/drivers/i2c/chips/twl4030-usb.c
@@ -774,7 +774,7 @@ static int __init twl4030_usb_init(void)
 {
 	return platform_driver_register(&twl4030_driver);
 }
-module_init(twl4030_usb_init);
+subsys_initcall(twl4030_usb_init);
 
 static void __exit twl4030_usb_exit(void)
 {
-- 
1.6.0.2.307.gc427

-- 
balbi

Re: [PATCH] i2c: change twl4030-usb back to subsys_initcall

[Tony Lindgren]

* Felipe Balbi <me@felipebalbi.com> [081004 02:50]:
> without it, otg_get/set_transceiver won't be useful and
> twl4030-usb transceiver won't get to musb code.

Pushed to l-o tree.

Tony

> 
> Signed-off-by: Felipe Balbi <felipe.balbi@nokia.com>
> ---
>  drivers/i2c/chips/twl4030-usb.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/i2c/chips/twl4030-usb.c b/drivers/i2c/chips/twl4030-usb.c
> index 133cc0f..922d7d6 100644
> --- a/drivers/i2c/chips/twl4030-usb.c
> +++ b/drivers/i2c/chips/twl4030-usb.c
> @@ -774,7 +774,7 @@ static int __init twl4030_usb_init(void)
>  {
>  	return platform_driver_register(&twl4030_driver);
>  }
> -module_init(twl4030_usb_init);
> +subsys_initcall(twl4030_usb_init);
>  
>  static void __exit twl4030_usb_exit(void)
>  {
> -- 
> 1.6.0.2.307.gc427
> 
> -- 
> 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?

[Nathan Monson]

On Fri, Oct 3, 2008 at 1:36 AM, David Brownell <david-b@pacbell.net> wrote:
>> > Unfortunately, without the patch, USB host doesn't work on the BeagleBoard.
>
> I see it working ... there's a bit of oddness in a host-only config,
> devices have to be plugged in after boot, but "doesn't work" seems
> pretty wrong.

The secret is to unplug the A cable from the mini-AB port on the
Beagleboard.  I was un/replugging my cable from the hub repeatedly,
thinking it was broken.  But un/replugging from the mini-AB port makes
everything appear.  Thanks for the hint -- I was ready to give up.

- Nathan

Re: OMAP support in mainline?

[David Brownell]

On Friday 03 October 2008, Nathan Monson wrote:
> On Fri, Oct 3, 2008 at 1:36 AM, David Brownell <david-b@pacbell.net> wrote:
> >> > Unfortunately, without the patch, USB host doesn't work on the BeagleBoard.
> >
> > I see it working ... there's a bit of oddness in a host-only config,
> > devices have to be plugged in after boot, but "doesn't work" seems
> > pretty wrong.
> 
> The secret is to unplug the A cable from the mini-AB port on the
> Beagleboard.  I was un/replugging my cable from the hub repeatedly,
> thinking it was broken.  But un/replugging from the mini-AB port makes
> everything appear.  Thanks for the hint -- I was ready to give up.

Yeah, I was pleased to discover that trick!

Of course, it's supposed to work without the unplug step too.  :)

- Dave

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?

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

[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, 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?

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

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

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

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?

[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: 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?

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

[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

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 ?