[Bug 1001428] Hal bits for Kinetis K40 SLCD controller

[bugzilla-daemon at bugs dot ecos dot sourceware dot 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 #7 from Ilija Kocho <ilijak@siva.com.mk> 2011-12-23 08:07:51 GMT ---
Hi John
Thank you for your comments

(In reply to comment #6)
> (In reply to comment #5)
> 
> > Provided that it doesn't fit in any of existing directories, I would create
> > directory with general name such as lcd and for device name I would refer to
> > Freescale docs. That would probably give devs/lcd/freescale/slcd .
> > 
> > Note: I wonder if another tree level would be suitable/desirable such as:
> > devs/gui/lcd/... Would anybody comment pse?
> 
> Using an "lcd" hierarchy for LCD segment displays would imply a separate
> hierarchy for LED segment displays with similar controllers. I think a more
> generic name is desirable.
> 
> Historically, support for simple devices with no corresponding I/O
> infrastructure package has tended to be bundled with the relevant HAL package.
> However, I do appreciate the desire for portability across architectures.
> 
> 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).

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.

-- 
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.