OMAP support in mainline?
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 :)
Signature · 1 line
Kalle Valo
Quoted 7 lines · 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 :)
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/[email protected]/msg02499.html
Don't recall what the current LM8323 status is.
- Paul
Quoted 10 lines · Paul Walmsley
Quoted 7 lines · 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 :)
Quoted 7 lines
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/[email protected]/msg02499.html
Don't recall what the current LM8323 status is.
Bluetooth is also missing on mainline, but the driver needs some rework.
Signature · 1 line
balbi
Quoted 15 lines · Felipe Balbi
Quoted 14 lines · Paul Walmsley
Quoted 7 lines · 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 :)
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:
Quoted 5 lines
Quoted 3 lines
http://www.mail-archive.com/[email protected]/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
Quoted 4 lines · On Tue, 16 Sep 2008 16:25:06 -0700 "ext Tony Lindgren" <[email protected]> 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
Quoted 3 lines · Jarkko Nikula
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. :)
Quoted 3 lines
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
Op 17 sep 2008, om 07:55 heeft David Brownell het volgende geschreven:
Quoted 8 lines · Jarkko Nikula
Quoted 3 lines
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
Quoted 26 lines
Quoted 6 lines
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 updatesFB 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 3 lines · Koen Kooi
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
Op 17 sep 2008, om 14:24 heeft Steve Sakoman het volgende geschreven:
Quoted 10 lines · Koen Kooi
Quoted 4 lines
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
Quoted 8 lines
Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 16 lines · ext Koen Kooi
Op 17 sep 2008, om 14:24 heeft Steve Sakoman het volgende geschreven:
Quoted 8 lines
Quoted 4 lines · Koen Kooi
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.Quoted 4 lines
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)
Quoted 6 lines
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 ?
drivers/usb/musb/omap2430.c +2 -0
@@ -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 );
Signature · 1 line
balbi
Quoted 9 lines
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Felipe Balbi
Sent: Thursday, September 18, 2008 3:26 PM
To: ext Koen Kooi
Cc: [email protected] Mailing List
Subject: Re: OMAP support in mainline?
Quoted 23 lines
Quoted 22 lines · ext Koen Kooi
Op 17 sep 2008, om 14:24 heeft Steve Sakoman het volgende geschreven:
Quoted 8 lines
Quoted 4 lines · Koen Kooi
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.Quoted 4 lines
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
Quoted 32 lines
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 ?
drivers/usb/musb/omap2430.c +2
-1@@ -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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Op 18 sep 2008, om 11:55 heeft Felipe Balbi het volgende geschreven:
Quoted 48 lines · ext Koen Kooi
Quoted 17 lines
Op 17 sep 2008, om 14:24 heeft Steve Sakoman het volgende geschreven:
Quoted 9 lines
On Wed, Sep 17, 2008 at 12:16 AM, Koen Kooi <[email protected]
Quoted 1 line
Quoted 4 lines · 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.Quoted 4 lines
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)
Quoted 6 lines
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 ?
drivers/usb/musb/omap2430.c +2
-0@@ -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);
Quoted 2 lines
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
Quoted 4 lines
Signature · 2 lines
-- balbi
Quoted 52 lines · ext Koen Kooi
Op 18 sep 2008, om 11:55 heeft Felipe Balbi het volgende geschreven:
Quoted 49 lines · ext Koen Kooi
Quoted 16 lines
Op 17 sep 2008, om 14:24 heeft Steve Sakoman het volgende geschreven:
Quoted 8 lines
Quoted 4 lines · Koen Kooi
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.Quoted 4 lines
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)
Quoted 8 lines
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 ?
drivers/usb/musb/omap2430.c +2
-0@@ -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);
Quoted 6 lines
Quoted 2 lines
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 ;-)
Quoted 3 lines
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 ;-)
Signature · 1 line
balbi
Quoted 27 lines
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Koen Kooi
Sent: Thursday, September 18, 2008 4:47 PM
To: [email protected]
Cc: [email protected] Mailing List
Subject: Re: OMAP support in mainline?Op 18 sep 2008, om 11:55 heeft Felipe Balbi het volgende geschreven:
Quoted 8 lines · ext Koen Kooi
Quoted 6 lines
Op 17 sep 2008, om 14:24 heeft Steve Sakoman het volgende geschreven:
Quoted 3 lines
On Wed, Sep 17, 2008 at 12:16 AM, Koen Kooi <[email protected]
Quoted 1 line
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 :(
Quoted 3 lines
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 !!!
Quoted 11 lines
regards,
Koen
Quoted 4 lines
--
balbi
Quoted 6 lines · Vikram
Quoted 3 lines
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.
Signature · 6 lines
Cheers, Igor --- Igor Stoppa Maemo Software - Nokia Devices R&D - Helsinki
Quoted 15 lines
-----Original Message-----
From: Igor Stoppa [mailto:[email protected]]
Sent: Thursday, September 18, 2008 5:24 PM
To: Pandita, Vikram
Cc: Koen Kooi; [email protected]; [email protected] Mailing List
Subject: RE: OMAP support in mainline?Quoted 4 lines · Vikram
Quoted 3 lines
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.
Quoted 5 lines
Quoted 2 lines
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.
Quoted 10 lines
It could not have been formulated in a better way.
--
Cheers, Igor
---
Igor Stoppa
Maemo Software - Nokia Devices R&D - Helsinki
Quoted 6 lines
Quoted 1 line
Quoted 1 line
And, no, I'm not going to try omapzoom stuff, I want it working on
the
Quoted 1 line
Quoted 1 line
canonical linux-omap kernel, not some corporate version with god
knows
Quoted 2 lines
Quoted 1 line
how many hacks.
Quoted 7 lines
Quoted 2 lines
Your wish.
I thought debugging and fixing the issue was more important than thesource 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.
Quoted 2 lines · Richard
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.
Quoted 2 lines
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
Quoted 2 lines
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
Quoted 1 line · Richard
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>
Quoted 1 line
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.
Quoted 3 lines
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.
Signature · 6 lines
Cheers, Igor --- Igor Stoppa Maemo Software - Nokia Devices R&D - Helsinki
Hi Igor,
Quoted 11 lines
-----Original Message-----
Quoted 1 line
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...
Quoted 5 lines
Quoted 1 line
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.
Quoted 1 line
Quoted 7 lines
Quoted 1 line
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.
Quoted 8 lines
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.
Quoted 9 lines · Richard
Hi Igor,
Quoted 7 lines
-----Original Message-----
Quoted 1 line
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.
Quoted 8 lines
Quoted 4 lines
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.
Signature · 1 line
Felipe Contreras
Quoted 4 lines
From: Felipe Contreras [mailto:[email protected]]
Sent: Sunday, September 21, 2008 10:03 AM
Quoted 8 lines
Quoted 1 line
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.
Quoted 8 lines · Vikram
Quoted 4 lines
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.
Op 18 sep 2008, om 18:31 heeft David Brownell het volgende geschreven:
Quoted 6 lines · Vikram
Quoted 5 lines
Quoted 4 lines
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.
Quoted 6 lines
Quoted 3 lines
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
MUSB not workin in .27rc6, was: Re: OMAP support in mainline?
In reply to Felipe BalbiOp 18 sep 2008, om 11:55 heeft Felipe Balbi het volgende geschreven:
Quoted 48 lines · ext Koen Kooi
Quoted 17 lines
Op 17 sep 2008, om 14:24 heeft Steve Sakoman het volgende geschreven:
Quoted 9 lines
On Wed, Sep 17, 2008 at 12:16 AM, Koen Kooi <[email protected]
Quoted 1 line
Quoted 4 lines · 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.Quoted 4 lines
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)
Quoted 6 lines
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 ?
drivers/usb/musb/omap2430.c +2
-0@@ -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);
Quoted 1 line
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
Re: MUSB not workin in .27rc6, was: Re: OMAP support in mainline?
Quoted 55 lines · Koen Kooi
Op 18 sep 2008, om 11:55 heeft Felipe Balbi het volgende geschreven:
Quoted 52 lines · ext Koen Kooi
Quoted 19 lines
Op 17 sep 2008, om 14:24 heeft Steve Sakoman het volgende geschreven:
Quoted 11 lines
Quoted 6 lines · Koen Kooi
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.Quoted 4 lines
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)
Quoted 10 lines
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 ?drivers/usb/musb/omap2430.c +1
-0@@ -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
Quoted 8 lines
Quoted 4 lines
drivers/usb/musb/omap2430.c +1
-0+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).
Signature · 5 lines
balbi -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: MUSB not workin in .27rc6, was: Re: OMAP support in mainline?
Op 19 sep 2008, om 23:24 heeft Felipe Balbi het volgende geschreven:
Quoted 65 lines · Koen Kooi
Quoted 55 lines
Op 18 sep 2008, om 11:55 heeft Felipe Balbi het volgende geschreven:
Quoted 52 lines · ext Koen Kooi
Quoted 19 lines
Op 17 sep 2008, om 14:24 heeft Steve Sakoman het volgende geschreven:
Quoted 11 lines
Quoted 6 lines · Koen Kooi
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.Quoted 4 lines
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)
Quoted 10 lines
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 ?drivers/usb/musb/omap2430.c +1
-0@@ -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 Quoted 8 lines
Quoted 4 lines
drivers/usb/musb/omap2430.c +1
-0+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).
Quoted 4 lines
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
Quoted 3 lines
Signature · 1 line
balbi
Re: MUSB not workin in .27rc6, was: Re: OMAP support in mainline?
Quoted 2 lines · Koen Kooi
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.
Signature · 1 line
balbi
Re: MUSB not workin in .27rc6, was: Re: OMAP support in mainline?
In reply to Koen KooiQuoted 3 lines · Koen Kooi
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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: MUSB not workin in .27rc6, was: Re: OMAP support in mainline?
Quoted 8 lines · David Brownell
Quoted 3 lines · Koen Kooi
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.
Signature · 5 lines
balbi -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 34 lines · Felipe Balbi
Quoted 16 lines · ext Koen Kooi
Op 17 sep 2008, om 14:24 heeft Steve Sakoman het volgende geschreven:
Quoted 8 lines
Quoted 4 lines · Koen Kooi
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.Quoted 4 lines
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)
Quoted 6 lines
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 ?
drivers/usb/musb/omap2430.c +0
-0@@ -215,12 +215,14 @@ void musb_platform_set_mode(struct musb *musb, u8 musb_mode)
drivers/usb/musb/omap2430.c void musb_platform_set_mode(struct musb *musb, u8 musb_mode) · line 225
Quoted 10 lines
drivers/usb/musb/omap2430.c +2
-0int __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;
Signature · 7 lines
Måns Rullgård [email protected] -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 10 lines · Steve Sakoman
Quoted 3 lines · Koen Kooi
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
Quoted 15 lines · Philip Balister
Quoted 9 lines · Steve Sakoman
Quoted 4 lines · Koen Kooi
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.Quoted 4 lines
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)
Quoted 5 lines
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
Op 19 sep 2008, om 22:57 heeft Ashwin Bihari het volgende geschreven:
Quoted 29 lines · Philip Balister
Quoted 16 lines
Quoted 10 lines · Steve Sakoman
On Wed, Sep 17, 2008 at 12:16 AM, Koen Kooi <[email protected]
Quoted 1 line
Quoted 4 lines · 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.Quoted 4 lines
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)
Quoted 5 lines
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.
Quoted 3 lines
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
Quoted 13 lines
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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 9 lines · Jarkko Nikula
Quoted 4 lines · On Tue, 16 Sep 2008 16:25:06 -0700 "ext Tony Lindgren" <[email protected]> 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?
Signature · 1 line
Kalle Valo
Quoted 9 lines · Kalle Valo
Quoted 7 lines · Jarkko Nikula
Quoted 4 lines · On Tue, 16 Sep 2008 16:25:06 -0700 "ext Tony Lindgren" <[email protected]> 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.
Quoted 7 lines
Quoted 2 lines
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
Quoted 22 lines · Tony Lindgren
Quoted 9 lines · Kalle Valo
Quoted 7 lines · Jarkko Nikula
Quoted 4 lines · On Tue, 16 Sep 2008 16:25:06 -0700 "ext Tony Lindgren" <[email protected]> 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.
Quoted 7 lines
Quoted 2 lines
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/cbusneeds to be cleaned and submitted via LKML
Quoted 7 lines
-
arch/arm/mach-omap2/board-n800*.cmaybe should be called board-n8x0*.c instead?-
blizzard_enable_clocks()needs to create a virtual clock so thatdrivers/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
Quoted 2 lines · Tony Lindgren
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.
Quoted 7 lines · Russell King - ARM Linux
Quoted 2 lines · Tony Lindgren
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
Quoted 5 lines · Tony Lindgren
Quoted 4 lines · Russell King - ARM Linux
Quoted 2 lines · Tony Lindgren
If any ATAGs are needed, such as for the serial console, it needs to be a generic ATAG for whole
arch/arm.
Quoted 7 lines
Quoted 3 lines
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.)
Quoted 2 lines
I guess console= could set
UPF_DEADor something similar for 8250.c to ignore that port rather than leave it out of theplat_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.
Quoted 10 lines · Russell King - ARM Linux
Quoted 9 lines · Tony Lindgren
Quoted 7 lines · Russell King - ARM Linux
Quoted 2 lines · Tony Lindgren
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.
Quoted 7 lines
Quoted 3 lines
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?
Quoted 10 lines
Quoted 2 lines
I guess console= could set
UPF_DEADor something similar for 8250.c to ignore that port rather than leave it out of theplat_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
Quoted 3 lines · Tony Lindgren
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 ?