[Bug 1001428] Hal bits for Kinetis K40 SLCD controller

[bugzilla-daemon@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 on the CC list for the bug.