This is the mail archive of the ecos-bugs@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 1001428] Hal bits for Kinetis K40 SLCD controller


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

--- Comment #9 from Ilija Kocho <ilijak@siva.com.mk> 2011-12-23 09:23:33 GMT ---
(In reply to comment #8)
> (In reply to comment #7)
> 
> > > A few possibilities for consideration:
> > > 
> > > 1) Introduce a hal/devs/ hierarchy for HAL-level device definitions which
> > > may be required across multiple architectures. Accessed directly as if part
> > > of a platform HAL or variant HAL package.
> > 
> > I would avoid putting directory named "devs" under "hal" since it may have
> > strong gravitational pull for any kind of device drivers (esp from new
> > developers).
> 
> Yes. Perhaps hal/shared/ or hal/misc/ would be better.

Both sound good to me with slight preference to hal/misc.

> 
> > But there are some devices that are close to the HAL but can be still shared
> > among different architectures such as: DMA, some RAM chips with
> > configurability features, etc. For this purpose I would propose hal/misc
> > This may be off-topic, but for me this is kind of actual question and I was
> > going to put it on devel list as I am near to submit a driver that employs
> > DMA and HAL support for external RAM chip(s) that have some registers for
> > configuration.
> > 
> > > 2) Introduce a devs/misc/ hierarchy for miscellaneous simple eCos devices
> > > with no corresponding I/O layer. Accessed via eCos device lookup.
> > > 
> > > 3) Create an I/O infrastructure package for segment displays.
> > 
> > I would vote for this with little further generalization: may it be
> > devs/displays (eventually abbreviated)? Or could it be: /devs/hmi?
> > Note: This may raise question what to do with (existing) framebuffer, but I
> > think at present it shouldn't be a big issue to move it in because there's
> > only one entry within framebuffer.
> 
> In general, device drivers under devs/$TYPE/ are accessed via the I/O layer at
> io/$TYPE/ and I see no reason to change this. For example devs/framebuf/ is
> accessed via the Framebuffer I/O  layer at io/framebuf/.
> 
> Also, in general, drivers under devs/ present themselves via the eCos device
> driver API.
> 
> If the Freescale SLCD package will simply provide some HAL definitions and
> HAL-level API then perhaps hal/misc/freescale/slcd/ is indeed the better place.

OK. Thank you for clarification.

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


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