Re: Freescale unified driver

[Ilija Koco <ilijak at siva dot com dot mk>]

Gary Thomas wrote:
> Gerster Jochen-B01096 wrote:
>> Hi
>>
>> I don't think it's a good idee to make one unified driver for many
>> archs in one source directory!
>> The problem is the pheripheral from the freescale archs may have some
>> little difference
>> which makes it necessary to do some changes on the unified driver!
>> Also someone want to use other features or an other concept in the
>> driver ....
>>
>> I think it would be better to copy a similar driver to its own source
>> dir
>> and then adjust it to the new arch(I think this is the normal process).
>> So it is ensured running ecos code stay running and not crashs due to
>> a ecos source update
>> because the new unified driver gets a bug for archX while it was
>> modified for archY by an other developer!
>> And the porting/adjusting process becomes shorter/easier because the
>> developer of the new port hasn't to
>> dicuss every change in the mailing list and hasn't to pay attention
>> on the other archs.
>>
>> The problem is that the developers don't seat in the same office
>> where the can have a short meeting and test the unified
>> driver on the different archs it's used for.
>> So easy sourcecode "care"(?) isn't the main goal.
>
> Actually, we try to do this all the time, whenever it's possible.
> The basic idea is to have a driver "template" where the platform
> (and architecture) details are filled in by macros, etc, in separate
> platform files.
>
> Look at how the generic (16x5x) serial drivers work for example.
> There is a basic structure in .../devs/serial/generic/16x5x
> To use the driver, you need the platform details, e.g. for the
> ARM PID board in .../devs/serial/arm/pid or a Super-H platform
> in .../devs/serial/sh/se77x9, etc.  Thus, one very generic driver
> can work on many platforms and multiple architectures.
>
> All it takes is a bit of care in how the driver is written :-)
That's what I had in mind, so I have prepared eSCI driver that way.
However today I re-checked the code and found out that I have left
2platform dependent  macros in device header. I'm moving them in
variant/platform header and I'll post patch following days.
Untill now I have posted my opatches thru bugzilla, but now I see they
can also be posted thru this mailing list. Are there some rules where to
post patches?
>
>>
>>
>> Best regards
>> Jochen
>>
>>
>>
>>
>>
>>
>> -----Original Message-----
>> From: ecos-patches-owner@ecos.sourceware.org
>> [mailto:ecos-patches-owner@ecos.sourceware.org] On Behalf Of Ilija Koco
>> Sent: Donnerstag, 3. August 2006 20:02
>> To: Uwe Kindler
>> Cc: ecos-patches@ecos.sourceware.org
>> Subject: Re: kernel dsr handling new option
>>
>> Hi Uwe
>>
>> I placed eSCI driver in devs/serial/freescale/esci (I created
>> freescale dir for freescale's serial devices employed on various fs
>> architecture chips).
>>
>> There is a possibility for us to get a job that will need can. In
>> that case I'll look for your driver and do same for can
>> (devs/can/flexcan).
>> I'll send you a note.
>>
>> Regards
>> Ilija
>>
>> Uwe Kindler wrote:
>>> Hello Ilija,
>>>
>>>> Making multiple drivers for same device is not a good practice.
>>> The FlexCAN device driver is part of the official eCos CVS since may
>>> 2005. It is in the devs/can/m68k/mcf52xx directory. I know that the
>>> FlexCAN module is not only part of the Coldfire family but it also
>>> implemented in other Freescale microcontrollers. It should be no
>>> proplem for another developer to port this driver for other
>>> Freescale processors. If someone will do a port for another
>>> Freescale product then maybe we should think about moving the driver
>>> into a separate directory and make it common for all Freescale
>>> products that use FlexCAN module.
>>>
>>>
>>> Best Regards
>>>
>>>
>>> Uwe Kindler
>>> Software Engineering
>>>
>>> -- 
>>>
>>> cetoni GmbH
>>> Am Wiesenring 6
>>> D-07554 Korbussen
>>>
>>> Tel.: +49 (0) 36602 338 28
>>> Fax:  +49 (0) 36602 338 11
>>> uwe.kindler@cetoni.de
>>> www.cetoni.de
>>>
>
>