About to tag 2.6.23-omap1

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

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

Looking into my pending patches list, I think you mean

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

?

Dirk

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

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

Tony

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

Hello,

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?

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.

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:[email protected]]
Sent: Tuesday, October 23, 2007 3:43 PM
To: Heilpern, Mark; [email protected]
Subject: RE: SPI support working?

Hello,

it

a

manage

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

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

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

Thank you,
Kyungmin Park

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