From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5755 invoked by alias); 23 Dec 2011 08:08:22 -0000 Received: (qmail 5742 invoked by uid 22791); 23 Dec 2011 08:08:18 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from hagrid.ecoscentric.com (HELO mail.ecoscentric.com) (212.13.207.197) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 23 Dec 2011 08:08:02 +0000 Received: from localhost (hagrid.ecoscentric.com [127.0.0.1]) by mail.ecoscentric.com (Postfix) with ESMTP id F09FB2F78011 for ; Fri, 23 Dec 2011 08:08:00 +0000 (GMT) Received: from mail.ecoscentric.com ([127.0.0.1]) by localhost (hagrid.ecoscentric.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YaKKnKnDD0JT; Fri, 23 Dec 2011 08:07:59 +0000 (GMT) From: bugzilla-daemon@bugs.ecos.sourceware.org To: ecos-patches@ecos.sourceware.org Subject: [Bug 1001428] Hal bits for Kinetis K40 SLCD controller X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: eCos X-Bugzilla-Component: Patches and contributions X-Bugzilla-Keywords: X-Bugzilla-Severity: enhancement X-Bugzilla-Who: ilijak@siva.com.mk X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: low X-Bugzilla-Assigned-To: unassigned@bugs.ecos.sourceware.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: In-Reply-To: References: X-Bugzilla-URL: http://bugs.ecos.sourceware.org/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Date: Fri, 23 Dec 2011 08:08:00 -0000 Message-Id: <20111223080758.DA24C2F78005@mail.ecoscentric.com> Mailing-List: contact ecos-patches-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: ecos-patches-owner@ecos.sourceware.org X-SW-Source: 2011-12/txt/msg00042.txt.bz2 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 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.