On 08/13/2010 02:23 AM, Wang, Qi wrote: >> -----Original Message----- >> From: Wolfgang Grandegger [mailto:[email protected]] >> Sent: Thursday, August 12, 2010 5:04 PM >> To: Wang, Qi >> Cc: Daniel Baluta; Masayuki Ohtak; [email protected]; >> [email protected]; [email protected]; Khor, Andrew Chih >> Howe; [email protected]; [email protected]; Wang, Yong Y >> Subject: Re: [MeeGo-Dev][PATCH] Topcliff: Update PCH_CAN driver to 2.6.35 >> >> On 08/12/2010 03:42 AM, Wang, Qi wrote: >>>> -----Original Message----- >>>> From: Daniel Baluta [mailto:[email protected]] >>>> Sent: Wednesday, August 11, 2010 6:37 PM >>>> To: Masayuki Ohtak >>>> Cc: [email protected]; Wolfgang Grandegger; >>>> [email protected]; [email protected]; Khor, Andrew >> Chih >>>> Howe; [email protected]; [email protected]; Wang, Qi; Wang, Yong Y >>>> Subject: Re: [MeeGo-Dev][PATCH] Topcliff: Update PCH_CAN driver to 2.6.35 >>>> >>>> Hi, >>>> >>>> 2010/8/11 Masayuki Ohtak <[email protected]>: >>>>> CAN driver of Topcliff PCH >>>>> >>>>> Topcliff PCH is the platform controller hub that is going to be used in >>>>> Intel's upcoming general embedded platform. All IO peripherals in >>>>> Topcliff PCH are actually devices sitting on AMBA bus. >>>>> Topcliff PCH has CAN I/F. This driver enables CAN function. >>>>> >>>>> Signed-off-by: Masayuki Ohtake <[email protected]> >>>> >>>> I have a few questions: >>>> >>>> 1. Is your code based on Intel's CAN EP80579 ([1]) ? >>> No. >> >> For curiosity, is the controller similar to the OKI MSM9225 or ML9620? > The Topcliff IOH is developed by OKI actually. > >> >>>> 2. Why don't you use kernel existing kfifo infrastructure? ([2]). >>> Just take a look at kfifo.h. This structure has been changed. I remembered >> there was a spin_lock from kfifo previously. Currently it's been removed, >> good. >>> OKI-sans, would you please take a look at ./include/linux/kfifo.h, and try >>> to >> use this structure and APIs? >> >> As I see it, the code related to that fifo is not used (== dead code)? > I'm not familiar with kfifo structure, and I didn't like it because there > need a spin_lock to use it. >> >>> Daniel, >>> >>> We're anxious to integrate those codes now. Perhaps it'll take us quite a >>> long >> time to use kfifo. How about implementing it with the next version? >> >> See above. What do you mean with the next version. The driver posted by >> Masayuki is far away from being accepted as it does not yet comply with >> the Socket-CAN driver API, to say the least. > I've few experience on CAN driver and it's also the first time for OKI-san to > write Can driver. Would you please give us a reference and we'll follow it > up. We only read 'can.txt' from kernel document. Thank you for your help in > advance.
You are welcome. I think I/we already gave useful hints on what is missing and what examples to follow. Wolfgang. _______________________________________________ Socketcan-core mailing list [email protected] https://lists.berlios.de/mailman/listinfo/socketcan-core
