About to tag 2.6.23-omap1

About to tag 2.6.23-omap1

[Tony Lindgren]

Hi all,

I'm planning to tag 2.6.23-omap1 tomorrow morning PST with current
linux-omap git tree unless somebody comes up with fixes that still
should go in.

So only fixes right now please, then let's update the tree to
mainline kernel, and try to get most of the pending patches such as
mmc, v4l, osk-2420, omap2-nand etc applied (and fixed if needed).

After that, let's plan on doing the move of arch/arm/plat-omap/dsp
to drivers/dsp/omap. And then we prepare patches do the fixes needed
for Russell for plat-omap and mach-omap1 before 2.6.24-rc5 to try to
get them mostly in sync with mainline. Then we can hopefully sync up
mach-omap2 for 2.6.25-rc5.

Cheers,

Tony

Re: About to tag 2.6.23-omap1

[Kyungmin Park]

Hi,

There is a pending patch related with OMAP2 USB device DMA support.
I think now there's one user to use this feature, Apollon.

As David's comment, it has board specific code.
but the DMA patch don't update the board specific code. it only adds
the DMA codes.

So if you don't mind I hope to merge this one too.

Thank you,
Kyungmin Park

On 10/23/07, Tony Lindgren <tony@atomide.com> wrote:
> Hi all,
>
> I'm planning to tag 2.6.23-omap1 tomorrow morning PST with current
> linux-omap git tree unless somebody comes up with fixes that still
> should go in.
>
> So only fixes right now please, then let's update the tree to
> mainline kernel, and try to get most of the pending patches such as
> mmc, v4l, osk-2420, omap2-nand etc applied (and fixed if needed).
>
> After that, let's plan on doing the move of arch/arm/plat-omap/dsp
> to drivers/dsp/omap. And then we prepare patches do the fixes needed
> for Russell for plat-omap and mach-omap1 before 2.6.24-rc5 to try to
> get them mostly in sync with mainline. Then we can hopefully sync up
> mach-omap2 for 2.6.25-rc5.
>
> Cheers,
>
> Tony
> _______________________________________________
> Linux-omap-open-source mailing list
> Linux-omap-open-source@linux.omap.com
> http://linux.omap.com/mailman/listinfo/linux-omap-open-source
>

Re: About to tag 2.6.23-omap1

[Dirk Behme]

Kyungmin Park wrote:
> There is a pending patch related with OMAP2 USB device DMA support.
> I think now there's one user to use this feature, Apollon.
> 
> As David's comment, it has board specific code.
> but the DMA patch don't update the board specific code. it only adds
> the DMA codes.
> 
> So if you don't mind I hope to merge this one too.

Looking into my pending patches list, I think you mean

http://linux.omap.com/pipermail/linux-omap-open-source/2007-October/011579.html

?

Dirk

> Thank you,
> Kyungmin Park
> 
> On 10/23/07, Tony Lindgren <tony@atomide.com> wrote:
> 
>>Hi all,
>>
>>I'm planning to tag 2.6.23-omap1 tomorrow morning PST with current
>>linux-omap git tree unless somebody comes up with fixes that still
>>should go in.
>>
>>So only fixes right now please, then let's update the tree to
>>mainline kernel, and try to get most of the pending patches such as
>>mmc, v4l, osk-2420, omap2-nand etc applied (and fixed if needed).
>>
>>After that, let's plan on doing the move of arch/arm/plat-omap/dsp
>>to drivers/dsp/omap. And then we prepare patches do the fixes needed
>>for Russell for plat-omap and mach-omap1 before 2.6.24-rc5 to try to
>>get them mostly in sync with mainline. Then we can hopefully sync up
>>mach-omap2 for 2.6.25-rc5.
>>
>>Cheers,
>>
>>Tony
>>_______________________________________________
>>Linux-omap-open-source mailing list
>>Linux-omap-open-source@linux.omap.com
>>http://linux.omap.com/mailman/listinfo/linux-omap-open-source
>>
> 
> _______________________________________________
> Linux-omap-open-source mailing list
> Linux-omap-open-source@linux.omap.com
> http://linux.omap.com/mailman/listinfo/linux-omap-open-source
> 

Re: About to tag 2.6.23-omap1

[Tony Lindgren]

* Dirk Behme <dirk.behme@googlemail.com> [071023 08:30]:
> Kyungmin Park wrote:
>> There is a pending patch related with OMAP2 USB device DMA support.
>> I think now there's one user to use this feature, Apollon.
>> As David's comment, it has board specific code.
>> but the DMA patch don't update the board specific code. it only adds
>> the DMA codes.
>> So if you don't mind I hope to merge this one too.
>
> Looking into my pending patches list, I think you mean
>
> http://linux.omap.com/pipermail/linux-omap-open-source/2007-October/011579.html
>
> ?

Let's plan on pushing that over after updating to current mainline
kernel. That way if it breaks stuff for non-DMA configurations :)

>> On 10/23/07, Tony Lindgren <tony@atomide.com> wrote:
>>> Hi all,
>>>
>>> I'm planning to tag 2.6.23-omap1 tomorrow morning PST with current
>>> linux-omap git tree unless somebody comes up with fixes that still
>>> should go in.
>>>
>>> So only fixes right now please, then let's update the tree to
>>> mainline kernel, and try to get most of the pending patches such as
>>> mmc, v4l, osk-2420, omap2-nand etc applied (and fixed if needed).
>>>
>>> After that, let's plan on doing the move of arch/arm/plat-omap/dsp
>>> to drivers/dsp/omap. And then we prepare patches do the fixes needed
>>> for Russell for plat-omap and mach-omap1 before 2.6.24-rc5 to try to
>>> get them mostly in sync with mainline. Then we can hopefully sync up
>>> mach-omap2 for 2.6.25-rc5.

I've tagged v2.6.23-omap1 and posted the patch to usual location.

Tony

SPI support working?

[Heilpern, Mark]

Hello,

I'm new to OMAP Linux, and on a project I'm working on I need to use it
to implement SPI. I'm using an OMAP 2430 board that brings SPI2 out to a
header, and the vendor kernel is at version 2.6.19. Applying their
board-specific patch to a 2.6.22 source base (after applying
patch-2.6.22-omap1, of course) resulted in a large number of patch
rejects.

So far I haven't been able to build a kernel with OMAP McSPI support
enabled in it; there have been errors that suggest this stuff has not
recently been compiled... wrong number of arguments to a function
(omap_set_dma_dest_params) and numerous macros undefined anywhere
(OMAP24XX_DMA_SPI[12]_[TR]X[123]).

Is anyone using SPI on an OMAP these days? Am I going to have to manage
my own register driver rather than being able to rely on something
already written? Can I simply rip these definitions from a different
kernel source base and use them (along with fixing the function call
issues, of course)?

Thanks for any replies...


NOTE: The information in this message is intended for the personal and confidential use
of the designated recipient(s) named above. To the extent the recipient(s) is/are bound
by a non-disclosure agreement, or other agreement that contains an obligation of
confidentiality, with AuthenTec, then this message and/or any attachments shall be
considered confidential information and subject to the confidentiality terms of that
agreement.  If the reader of this message is not the intended recipient named above, you
are notified that you have received this document in error, and any review, dissemination,
distribution or copying of this message is strictly prohibited. If you have received this
document in error, please delete the original message and notify the sender immediately.
Thank you.

AuthenTec, Inc.  http://www.authentec.com

RE: SPI support working?

[Woodruff, Richard]

Hello,

> I'm new to OMAP Linux, and on a project I'm working on I need to use it
> to implement SPI. I'm using an OMAP 2430 board that brings SPI2 out to a
> header, and the vendor kernel is at version 2.6.19. Applying their
> board-specific patch to a 2.6.22 source base (after applying
> patch-2.6.22-omap1, of course) resulted in a large number of patch
> rejects.
> 
> So far I haven't been able to build a kernel with OMAP McSPI support
> enabled in it; there have been errors that suggest this stuff has not
> recently been compiled... wrong number of arguments to a function
> (omap_set_dma_dest_params) and numerous macros undefined anywhere
> (OMAP24XX_DMA_SPI[12]_[TR]X[123]).
> 
> Is anyone using SPI on an OMAP these days? Am I going to have to manage
> my own register driver rather than being able to rely on something
> already written? Can I simply rip these definitions from a different
> kernel source base and use them (along with fixing the function call
> issues, of course)?

A couple paths exist here.

The omap-git tree is using a nice and relatively newer SPI frame work.  It would have the most community usage probably against OMAP2420 not OMAP2430.  Making it work on 2430 should be doable, especially using some example working TI code.  It might be someone already has it going.

On the TI website in example kernels, a McSPI library helper implementation as opposed to the newer driver exists.  This would have been tested and will work against the older kernel version on reference hardware.  Drivers will call these helpers to get work done.

TI does have some newer version as used with OMAP3430 which is jumping to use the new frame work.  This kernel through some TI channels (FAE) likely can be made available, or after some delay it likely will be posted on TI's website, and will eventually show up in the community omap-git.

Regards,
Richard W.

BTW: Are you the same Mark who wrote the OS9 Primer?

RE: SPI support working?

[Heilpern, Mark]

Hi Richard,

Thanks much for the response. It sounds to me like exploring the "McSPI
library helper" may be my best option, if this is a kernel mode library
that can be included in a loadable module. The work I'm doing is on a
prototype board, and when it reaches the end user's hardware it will be
on an even older kernel (2.6.18), so anything I can do to not require
kernel changes would be for the best.

I'll talk to my local TI rep to see if I can get some FAE support.

> BTW: Are you the same Mark who wrote the OS9 Primer?
Not much use for the Primer these days, but it's been on my shelf for
about 12 years now. I look more-or-less the same as the picture on the
back, sans beard. Nice to hear from you and to see you're at TI. I
recognized your name as soon as I saw it in email; it's a small world.

Mark




-----Original Message-----
From: Woodruff, Richard [mailto:r-woodruff2@ti.com] 
Sent: Tuesday, October 23, 2007 3:43 PM
To: Heilpern, Mark; linux-omap-open-source@linux.omap.com
Subject: RE: SPI support working?

Hello,

> I'm new to OMAP Linux, and on a project I'm working on I need to use
it
> to implement SPI. I'm using an OMAP 2430 board that brings SPI2 out to
a
> header, and the vendor kernel is at version 2.6.19. Applying their
> board-specific patch to a 2.6.22 source base (after applying
> patch-2.6.22-omap1, of course) resulted in a large number of patch
> rejects.
> 
> So far I haven't been able to build a kernel with OMAP McSPI support
> enabled in it; there have been errors that suggest this stuff has not
> recently been compiled... wrong number of arguments to a function
> (omap_set_dma_dest_params) and numerous macros undefined anywhere
> (OMAP24XX_DMA_SPI[12]_[TR]X[123]).
> 
> Is anyone using SPI on an OMAP these days? Am I going to have to
manage
> my own register driver rather than being able to rely on something
> already written? Can I simply rip these definitions from a different
> kernel source base and use them (along with fixing the function call
> issues, of course)?

A couple paths exist here.

The omap-git tree is using a nice and relatively newer SPI frame work.
It would have the most community usage probably against OMAP2420 not
OMAP2430.  Making it work on 2430 should be doable, especially using
some example working TI code.  It might be someone already has it going.

On the TI website in example kernels, a McSPI library helper
implementation as opposed to the newer driver exists.  This would have
been tested and will work against the older kernel version on reference
hardware.  Drivers will call these helpers to get work done.

TI does have some newer version as used with OMAP3430 which is jumping
to use the new frame work.  This kernel through some TI channels (FAE)
likely can be made available, or after some delay it likely will be
posted on TI's website, and will eventually show up in the community
omap-git.

Regards,
Richard W.

BTW: Are you the same Mark who wrote the OS9 Primer?


NOTE: The information in this message is intended for the personal and confidential use
of the designated recipient(s) named above. To the extent the recipient(s) is/are bound
by a non-disclosure agreement, or other agreement that contains an obligation of
confidentiality, with AuthenTec, then this message and/or any attachments shall be
considered confidential information and subject to the confidentiality terms of that
agreement.  If the reader of this message is not the intended recipient named above, you
are notified that you have received this document in error, and any review, dissemination,
distribution or copying of this message is strictly prohibited. If you have received this
document in error, please delete the original message and notify the sender immediately.
Thank you.

AuthenTec, Inc.  http://www.authentec.com

RE: About to tag 2.6.23-omap1

[Kyungmin Park]

> 
> * Dirk Behme <dirk.behme@googlemail.com> [071023 08:30]:
> > Kyungmin Park wrote:
> >> There is a pending patch related with OMAP2 USB device DMA support.
> >> I think now there's one user to use this feature, Apollon.
> >> As David's comment, it has board specific code.
> >> but the DMA patch don't update the board specific code. it only adds
> >> the DMA codes.
> >> So if you don't mind I hope to merge this one too.
> >
> > Looking into my pending patches list, I think you mean
> >
> > http://linux.omap.com/pipermail/linux-omap-open-source/2007-October/011579.html
> >
> > ?

Yes, it is.
For more detail, it only happens at windows connection.
Without the small packet handling, it's working well at linux host.

> 
> Let's plan on pushing that over after updating to current mainline
> kernel. That way if it breaks stuff for non-DMA configurations :)

No problem, the goal is that it goes to mainline.

Thank you,
Kyungmin Park

Re: About to tag 2.6.23-omap1

[Tony Lindgren]

* Tony Lindgren <tony@atomide.com> [071023 10:41]:
> * Dirk Behme <dirk.behme@googlemail.com> [071023 08:30]:
> > Kyungmin Park wrote:
> >> There is a pending patch related with OMAP2 USB device DMA support.
> >> I think now there's one user to use this feature, Apollon.
> >> As David's comment, it has board specific code.
> >> but the DMA patch don't update the board specific code. it only adds
> >> the DMA codes.
> >> So if you don't mind I hope to merge this one too.
> >
> > Looking into my pending patches list, I think you mean
> >
> > http://linux.omap.com/pipermail/linux-omap-open-source/2007-October/011579.html
> >
> > ?
> 
> Let's plan on pushing that over after updating to current mainline
> kernel. That way if it breaks stuff for non-DMA configurations :)
> 
> >> On 10/23/07, Tony Lindgren <tony@atomide.com> wrote:
> >>> Hi all,
> >>>
> >>> I'm planning to tag 2.6.23-omap1 tomorrow morning PST with current
> >>> linux-omap git tree unless somebody comes up with fixes that still
> >>> should go in.
> >>>
> >>> So only fixes right now please, then let's update the tree to
> >>> mainline kernel, and try to get most of the pending patches such as
> >>> mmc, v4l, osk-2420, omap2-nand etc applied (and fixed if needed).
> >>>
> >>> After that, let's plan on doing the move of arch/arm/plat-omap/dsp
> >>> to drivers/dsp/omap. And then we prepare patches do the fixes needed
> >>> for Russell for plat-omap and mach-omap1 before 2.6.24-rc5 to try to
> >>> get them mostly in sync with mainline. Then we can hopefully sync up
> >>> mach-omap2 for 2.6.25-rc5.
> 
> I've tagged v2.6.23-omap1 and posted the patch to usual location.

Just FYI everybody, I'm updating linux-omap to mainline tree today.

I had to travel to go deal with some product specific bugs, but now that's
out of the way so I'll have more time for linux-omap tree again.

Cheers,

Tony