This is the mail archive of the
ecos-bugs@sourceware.org
mailing list for the eCos project.
[Bug 1001428] Hal bits for Kinetis K40 SLCD controller
- From: bugzilla-daemon at bugs dot ecos dot sourceware dot org
- To: unassigned at bugs dot ecos dot sourceware dot org
- Date: Fri, 23 Dec 2011 09:23:36 +0000
- Subject: [Bug 1001428] Hal bits for Kinetis K40 SLCD controller
- Auto-submitted: auto-generated
- References: <bug-1001428-777@http.bugs.ecos.sourceware.org/>
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.