This is the mail archive of the ecos-patches@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug 1001397] I2C driver for Kinetic microcontrollers


Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001397

--- Comment #8 from Ilija Kocho <ilijak@siva.com.mk> 2011-12-24 11:58:57 GMT ---
(In reply to comment #7)
> (In reply to comment #5)
> > As there is existing devs/i2c directory, I propose following path:
> >     - devs/i2c/freescale/<freescale_i2c>
> 
> OK, but the situation is exactly the same for the SLCD controller, and so we
> end up with bits under devs/ and bits under hal/misc, with no clear logic for
> the distinction I can see.
> 

We need to distinguish/combine two sources of information:
   Device structure (registers, bits)
   Device instantiation (base address, pins, etc).

Device structure is needed only by the driver and should live there (in
driver's .c file or in a header file). Also the naming should be in device name
space, common patterns are: CYGHWR_IO_I2C_FREESCALE_I2C_xxxx or
CYGHWR_DEV_I2C_FREESCALE_I2C_xxx 

Device instants are HAL dependent, hence var_io_devs.h or plf_io.h.

Example:
var_io_devs.h -----------------------------

#define CYGHWR_IO_I2C_FREESCALE_I2C1_P \
((cyghwr_io_i2c_freescale_i2c_t*)0x40067000)

--------------------------------------------

plf_io.h -----------------------------------

#define CYGHWR_IO_I2C_FREESCALE_I2C0_PIN_SDA CYGHWR_HAL_KINETIS_PIN(D, 9, 2, 0)

--------------------------------------------

>
> > where <freescale_i2c> is the name of this particular freescale spi instance
> > (typically as referred to in ref. man.).
> 
> The services have only generic names in the Freescale RMs, so we end up with
> very generic names. That is fine if Freescale only make a single i2c controller
> and never will design another one, perhaps that is the case?

It seem that to be the case with i2c. I checked Coldfire+ seem to have the same
i2c but PXN have some older version looks like some bits match but probably not
all. Maybe we can use i2c now and if there's next entry with generic name we
add the new device name some suffix/prefix.

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]