From mboxrd@z Thu Jan 1 00:00:00 1970 From: John Williams Subject: Re: Device tree BSP Date: Sun, 5 Jul 2009 19:18:12 +1000 Message-ID: <1d3f23370907050218l6b2eb9emdbcb7dc321dbab5a@mail.gmail.com> References: <4A49F472.3030902@petalogix.com> <20090704181837.4DC219B0051@mail75-va3.bigfish.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0427579397==" Return-path: In-Reply-To: <20090704181837.4DC219B0051-AP5P7IoXhpo/OHOHf44ZtvYhGscHeamf@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Mime-version: 1.0 Sender: devicetree-discuss-bounces+gldd-devicetree-discuss=m.gmane.org-mnsaURCQ41sdnm+yROfE0A@public.gmane.org Errors-To: devicetree-discuss-bounces+gldd-devicetree-discuss=m.gmane.org-mnsaURCQ41sdnm+yROfE0A@public.gmane.org To: Stephen Neuendorffer Cc: John Linn , michal.simek-g5w7nrANp4BDPfheJLI6IQ@public.gmane.org, devicetree-discuss-mnsaURCQ41sdnm+yROfE0A@public.gmane.org, David DeBonis List-Id: devicetree@vger.kernel.org --===============0427579397== Content-Type: multipart/alternative; boundary=0016364ee590616b5f046df1de2e --0016364ee590616b5f046df1de2e Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Sun, Jul 5, 2009 at 4:15 AM, Stephen Neuendorffer < stephen.neuendorffer-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org> wrote: > > > I'm not exactly sure what you're trying to do here, but it doesn't look > right to me. > In particular, why would I have to have a separate core for these > functions? > Furthermore, I'm sure there must be some generic mechanisms that can/should > be used for these kind of things. > In general, we shouldn't reinvent the wheel here.. > The issue as I see it is that in a hardware design, the GPIO is a very convenient core to drive a heartbeat LED, and aux input on proc_sys_reset (for software-driven reset), or whatever. Clearly you don't want these GPIO cores to enumerate as regular xps_gpio devices, binding to the standard GPIO driver and appearing in /dev/gpioN Is your concern the manual override of OF_ binding (the "compatible" strings), or just the HW overhead of an extra core to drive these HW utility functions? Save us from the bad old days of "misc_logic" IP cores that drove this stuff in older Xilinx reference designs! Would you propose to get tricky and allocate specific bits on existing GPIOs for these "special" functions, and write the GPIO driver/framework to mask off these bits etc? Seems like a complicated software solution to a problem trivially solved with a few extra gates. Cheers, John -- John Williams, PhD, B.Eng, B.IT PetaLogix - Linux Solutions for a Reconfigurable World w: www.petalogix.com p: +61-7-30090663 f: +61-7-30090663 --0016364ee590616b5f046df1de2e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Sun, Jul 5, 2009 at 4:15 AM, Stephen = Neuendorffer <stephen.neuendorffer-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org> wrote:


I'm not exactly sure what you're trying to do h= ere, but it doesn't look right to me.
In particular, why would I have to have a separate core for these functions= ?
Furthermore, I'm sure there must be some generic mechanisms that can/sh= ould be used for these kind of things.
In general, we shouldn't reinvent the wheel here..


The issue as I see it is that in a hardware design, the G= PIO is a very convenient core to drive a heartbeat LED, and aux input on pr= oc_sys_reset (for software-driven reset), or whatever.
=A0
Clearly you don't want these GPIO cores to enumerate as regular = xps_gpio devices, binding to the standard GPIO driver and appearing in /dev= /gpioN

Is your concern the manual override of OF_ binding (the "= ;compatible" strings), or just the HW overhead of an extra core to dri= ve these HW utility functions?=A0 Save us from the bad old days of "mi= sc_logic"=A0 IP cores that drove this stuff in older Xilinx reference = designs!

Would you propose to get tricky and allocate specific bits on existing = GPIOs for these "special" functions, and write the GPIO driver/fr= amework to mask off these bits etc?=A0 Seems like a complicated software so= lution to a problem trivially solved with a few extra gates.

Cheers,

John
--
John Williams, PhD, B.Eng, B.IT
PetaLogix - Linux Solutions for a Reconfi= gurable World
w: www.petalogix.com<= /a> =A0p: +61-7-30090663 =A0f: +61-7-30090663
--0016364ee590616b5f046df1de2e-- --===============0427579397== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ devicetree-discuss mailing list devicetree-discuss-mnsaURCQ41sdnm+yROfE0A@public.gmane.org https://ozlabs.org/mailman/listinfo/devicetree-discuss --===============0427579397==--