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 08:30:59 +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 #8 from John Dallaway <john@dallaway.org.uk> 2011-12-23 08:30:57 GMT ---
(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.
> 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.
--
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.