<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7654.12">
<TITLE>RE: Device tree BSP</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<BR>
<P><FONT SIZE=2>My (limited) understanding from reading other posts is that there is already a GPIO subsystem for handling such misc-GPIO things.<BR>
To me the cost of gates for multiple GPIO cores is small compared to the system cost of having<BR>
a separate OF binding. IMHO, this should be exposed the way any other GPIO with such capabilities<BR>
is on any other OF/device-tree enabled system.<BR>
<BR>
Steve<BR>
<BR>
-----Original Message-----<BR>
From: John Williams [<A HREF="mailto:john.williams@petalogix.com">mailto:john.williams@petalogix.com</A>]<BR>
Sent: Sun 7/5/2009 2:18 AM<BR>
To: Stephen Neuendorffer<BR>
Cc: michal.simek@petalogix.com; John Linn; David DeBonis; devicetree-discuss@ozlabs.org<BR>
Subject: Re: Device tree BSP<BR>
<BR>
On Sun, Jul 5, 2009 at 4:15 AM, Stephen Neuendorffer <<BR>
stephen.neuendorffer@xilinx.com> wrote:<BR>
<BR>
><BR>
><BR>
> I'm not exactly sure what you're trying to do here, but it doesn't look<BR>
> right to me.<BR>
> In particular, why would I have to have a separate core for these<BR>
> functions?<BR>
> Furthermore, I'm sure there must be some generic mechanisms that can/should<BR>
> be used for these kind of things.<BR>
> In general, we shouldn't reinvent the wheel here..<BR>
><BR>
<BR>
The issue as I see it is that in a hardware design, the GPIO is a very<BR>
convenient core to drive a heartbeat LED, and aux input on proc_sys_reset<BR>
(for software-driven reset), or whatever.<BR>
<BR>
Clearly you don't want these GPIO cores to enumerate as regular xps_gpio<BR>
devices, binding to the standard GPIO driver and appearing in /dev/gpioN<BR>
<BR>
Is your concern the manual override of OF_ binding (the "compatible"<BR>
strings), or just the HW overhead of an extra core to drive these HW utility<BR>
functions? Save us from the bad old days of "misc_logic" IP cores that<BR>
drove this stuff in older Xilinx reference designs!<BR>
<BR>
Would you propose to get tricky and allocate specific bits on existing GPIOs<BR>
for these "special" functions, and write the GPIO driver/framework to mask<BR>
off these bits etc? Seems like a complicated software solution to a problem<BR>
trivially solved with a few extra gates.<BR>
<BR>
Cheers,<BR>
<BR>
John<BR>
--<BR>
John Williams, PhD, B.Eng, B.IT<BR>
PetaLogix - Linux Solutions for a Reconfigurable World<BR>
w: www.petalogix.com p: +61-7-30090663 f: +61-7-30090663<BR>
<BR>
</FONT>
</P>
<br clear=all> This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.
</BODY>
</HTML>