OMAP2 SPI Driver update:
------------------------
* I have started writing the OMAP2 SPI (Serial Peripheral Interface) driver using David Brownell's Simple SPI Framework.
* I am writing this driver as bit fancy, means "interrupt based transfers" in first phase and later with "dma based transfers".
* If interrupt based transfers works, then my plan is to move this driver using Bitbang interface also, to be useful while testing new OMAP2 series processors and custom boards based on the same too.
Today is 28th December, Time for for Tony to comeback from Vacation. Let's hope for fireworks !!!
Wednesday, December 28, 2005
Sunday, December 25, 2005
Submitting OMAP drivers to upstream
Tony,
How about starting to submit OMAP drivers to respective maintainers in
upstream [A]?
As discussed on linux-arm-kernel mailing list about "clock framework"
changes, we can think of submitting drivers to upstream after resolving
"clock fwk" issue.
[1]
I am sure you guys, must have put thought on that, but by doing this we
might not have to do some trivial changes to all the drivers, if any
driver model gets changes. e.g struct device_driver to platform_driver.
[1.1] We will get close reviews outside OMAP community.
[1.2] This might increase the acceptance time of patches by resp.
maintainer.
[2]
Yes, if we submit all the drivers to upstream, then our linux-omap-git
tree becomes obsolete, _or_ initially we have to follow two-step process
for submission.
[2.1] Submit new drivers/bugs fixes to linux-omap tree.
[2.2] Then to resp. maintainer in upstream.
But, if someone(a new user) picks up kernel from the upstream(with
drivers, whose bugs are fixed in linux-omap tree, but yet not submitted
to upstream), then it will be a big problem initially.
[A]
As of my knowledge, right now only OMAP nor flash mapping driver is in
upstream.
---Komal Shah
PS: This e-mail is still in my "draft" folder. I will wait for conclusion of "clock fwk".
How about starting to submit OMAP drivers to respective maintainers in
upstream [A]?
As discussed on linux-arm-kernel mailing list about "clock framework"
changes, we can think of submitting drivers to upstream after resolving
"clock fwk" issue.
[1]
I am sure you guys, must have put thought on that, but by doing this we
might not have to do some trivial changes to all the drivers, if any
driver model gets changes. e.g struct device_driver to platform_driver.
[1.1] We will get close reviews outside OMAP community.
[1.2] This might increase the acceptance time of patches by resp.
maintainer.
[2]
Yes, if we submit all the drivers to upstream, then our linux-omap-git
tree becomes obsolete, _or_ initially we have to follow two-step process
for submission.
[2.1] Submit new drivers/bugs fixes to linux-omap tree.
[2.2] Then to resp. maintainer in upstream.
But, if someone(a new user) picks up kernel from the upstream(with
drivers, whose bugs are fixed in linux-omap tree, but yet not submitted
to upstream), then it will be a big problem initially.
[A]
As of my knowledge, right now only OMAP nor flash mapping driver is in
upstream.
---Komal Shah
PS: This e-mail is still in my "draft" folder. I will wait for conclusion of "clock fwk".
Thursday, December 22, 2005
Komal Shah
Komal Shah: "TODO:
1. IrDA: See, if workqueues can be seemlessly integrated for GPIO Exapander access on H3 and H4. I will wait for few suggestions from Tony and other members."
Solutions, keeping board-specific data out of driver:
* transceiver_mode(struct omap_irda *si, int mode)
- Passing private omap irda structure to transceiver_mode function.
- but for this, we need to move "struct omap_irda" from our driver file to include/asm-arm/arch-omap/irda.h ? It may not look as clean interface.
* Ugly way: Pass work_struct as transceiver_mode() argument. No applicable to all the platform, so ruled out.
* Add "struct work" in irda platform_data.
1. IrDA: See, if workqueues can be seemlessly integrated for GPIO Exapander access on H3 and H4. I will wait for few suggestions from Tony and other members."
Solutions, keeping board-specific data out of driver:
* transceiver_mode(struct omap_irda *si, int mode)
- Passing private omap irda structure to transceiver_mode function.
- but for this, we need to move "struct omap_irda" from our driver file to include/asm-arm/arch-omap/irda.h ? It may not look as clean interface.
* Ugly way: Pass work_struct as transceiver_mode() argument. No applicable to all the platform, so ruled out.
* Add "struct work" in irda platform_data.
Tuesday, December 20, 2005
OMAP-L: TODO
DONE:
* Watchdog fix submitted and accepted.
* IrDA testing on H4 board. - Discovery testing done.
* Submitted updated patch for IrDA to list.
* Submitted 2.6.9-TI based SPI commo. hack and touchscreen patch to the list. I am not going to work on this anymore.
TODO:
1. IrDA: See, if workqueues can be seemlessly integrated for GPIO Exapander access on H3 and H4. I will wait for few suggestions from Tony and other members.
* I need ARM cross-compiled "irdadump" utiltiy. Anyone?
2. NAND:
* I tried hard for different switch positons, but no success. Send your experiements to corresponding developers to test. I have kept this work aside for a while.
3. RTC
* I don't know how we will accomodate Menelaus RTC framework in existing 2.6.9-TI tree with git-omap2 tree.
4. SPI
* Start using David Brownells framework. Atleast experiments first polling based method with this framework and in second phase move to Interrupt and DMA support.
5. Video
* Work suspended until Imre Deak responds back.
* Watchdog fix submitted and accepted.
* IrDA testing on H4 board. - Discovery testing done.
* Submitted updated patch for IrDA to list.
* Submitted 2.6.9-TI based SPI commo. hack and touchscreen patch to the list. I am not going to work on this anymore.
TODO:
1. IrDA: See, if workqueues can be seemlessly integrated for GPIO Exapander access on H3 and H4. I will wait for few suggestions from Tony and other members.
* I need ARM cross-compiled "irdadump" utiltiy. Anyone?
2. NAND:
* I tried hard for different switch positons, but no success. Send your experiements to corresponding developers to test. I have kept this work aside for a while.
3. RTC
* I don't know how we will accomodate Menelaus RTC framework in existing 2.6.9-TI tree with git-omap2 tree.
4. SPI
* Start using David Brownells framework. Atleast experiments first polling based method with this framework and in second phase move to Interrupt and DMA support.
5. Video
* Work suspended until Imre Deak responds back.
Saturday, December 17, 2005
OMAP-L Dev. Update
Patches submitted to linux-omap-open-source mailing list:
1. IrDA Patch
- Cleanup of H2/H3 support, and moved platform specifc information to board-*.c files.
- Added support for 24xx.
Update:
- Patch was having few errors, which I have now resolved, but I am still not getting the interrupt and discovery test failes. But
#ifconfig irda0 up/down commands works on 24xx.
2. Video Out patch
- I have just cleanup of video out patch for git-omap tree and submitted for Imre Deak and Tony to review it.
- There were quite conflict in the development method and usage of vout along with existing git-omap2-fb driver. Need to resolve. It seems that Imre will reply only after x'-mas.
3. 24xx NAND patch
- It is not yet released, but it sitting under my tree. Submitted to Jian for review
- I got confused about flashing x-loader and u-boot for Nand flashing on 2420. Thanx Jian and team for giving me direction. I will try that on Monday it seems. I feel that PATCH will work straight away, and will publish it to list soon.
Bug fixing: TODO:
o Watchdog
- driver name should be changed from "omap-wdt" to "omap_wdt", as _probe function is not working in the current tree. I will submit that patch soon.
o RTC
- I don't know how we will accomodate Menelaus RTC framework in existing 2.6.9-TI tree with git-omap2 tree.
1. IrDA Patch
- Cleanup of H2/H3 support, and moved platform specifc information to board-*.c files.
- Added support for 24xx.
Update:
- Patch was having few errors, which I have now resolved, but I am still not getting the interrupt and discovery test failes. But
#ifconfig irda0 up/down commands works on 24xx.
2. Video Out patch
- I have just cleanup of video out patch for git-omap tree and submitted for Imre Deak and Tony to review it.
- There were quite conflict in the development method and usage of vout along with existing git-omap2-fb driver. Need to resolve. It seems that Imre will reply only after x'-mas.
3. 24xx NAND patch
- It is not yet released, but it sitting under my tree. Submitted to Jian for review
- I got confused about flashing x-loader and u-boot for Nand flashing on 2420. Thanx Jian and team for giving me direction. I will try that on Monday it seems. I feel that PATCH will work straight away, and will publish it to list soon.
Bug fixing: TODO:
o Watchdog
- driver name should be changed from "omap-wdt" to "omap_wdt", as _probe function is not working in the current tree. I will submit that patch soon.
o RTC
- I don't know how we will accomodate Menelaus RTC framework in existing 2.6.9-TI tree with git-omap2 tree.
Sunday, December 04, 2005
OMAP Linux Update
o Submitted remaining platform_driver usage patches to list.
o Working on SPI Controller driver. - Understanding David's framework in detail.
o Will be also looking at Video out and IVA bridge support too.
TI Dev Conf, was good, lot's of presentations/talks. Da Vinci Rocks. The companies I remember showing demos were (most of them were on DM642/320/270 series).
o Ittiam Systems, Bangalore - H.264 codec 3-way conference.
- Custom made boards on DM320/642.
- Their video conferencing phone was on display.
- Custom made PMP was there too.
o EPIGON - Audio codecs guys.
- Not concentrated much on the demo.
o ADMIYA - Wireless capabilities demo.
o SlingMedia - SlingBox - A cool use of DMXXX series of chip for TV on your laptop.
o HalloSoft - VoIP suite on OMAP1710 and some DM series.
o Intervideo - Again Audio Codecs guys - OMAP310/DM320 with Micro C Linux. Not open-sourced, so I hate them.
o Mistral - Their LCD module for OMAP5912 - Their marketting guys told me pricing at about 799$ plus taxes. :-).
o Emuzed - Only company showing OMAP2420 demos. Amazing performance of their codecs on OMAP2. They were using Open Source Linux (not MV ...Yo...) I was happy seeing that. Pointed them to latest development on linux-omap-open-source series too.
o Working on SPI Controller driver. - Understanding David's framework in detail.
o Will be also looking at Video out and IVA bridge support too.
TI Dev Conf, was good, lot's of presentations/talks. Da Vinci Rocks. The companies I remember showing demos were (most of them were on DM642/320/270 series).
o Ittiam Systems, Bangalore - H.264 codec 3-way conference.
- Custom made boards on DM320/642.
- Their video conferencing phone was on display.
- Custom made PMP was there too.
o EPIGON - Audio codecs guys.
- Not concentrated much on the demo.
o ADMIYA - Wireless capabilities demo.
o SlingMedia - SlingBox - A cool use of DMXXX series of chip for TV on your laptop.
o HalloSoft - VoIP suite on OMAP1710 and some DM series.
o Intervideo - Again Audio Codecs guys - OMAP310/DM320 with Micro C Linux. Not open-sourced, so I hate them.
o Mistral - Their LCD module for OMAP5912 - Their marketting guys told me pricing at about 799$ plus taxes. :-).
o Emuzed - Only company showing OMAP2420 demos. Amazing performance of their codecs on OMAP2. They were using Open Source Linux (not MV ...Yo...) I was happy seeing that. Pointed them to latest development on linux-omap-open-source series too.
Subscribe to:
Posts (Atom)