<br><br><div class="gmail_quote">On Sun, Jul 5, 2009 at 4:15 AM, Stephen Neuendorffer <span dir="ltr">&lt;<a href="mailto:stephen.neuendorffer@xilinx.com">stephen.neuendorffer@xilinx.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">







<div>

<br>
<br>

<p><font size="2">I&#39;m not exactly sure what you&#39;re trying to do here, but it doesn&#39;t look right to me.<br>
In particular, why would I have to have a separate core for these functions?<br>
Furthermore, I&#39;m sure there must be some generic mechanisms that can/should be used for these kind of things.<br>
In general, we shouldn&#39;t reinvent the wheel here..</font></p></div></blockquote><div><br>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.<br>
 <br>Clearly you don&#39;t want these GPIO cores to enumerate as regular xps_gpio devices, binding to the standard GPIO driver and appearing in /dev/gpioN<br><br>Is your concern the manual override of OF_ binding (the &quot;compatible&quot; strings), or just the HW overhead of an extra core to drive these HW utility functions?  Save us from the bad old days of &quot;misc_logic&quot;  IP cores that drove this stuff in older Xilinx reference designs!<br>
<br>Would you propose to get tricky and allocate specific bits on existing GPIOs for these &quot;special&quot; 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.<br>
<br>Cheers,<br><br>John<br></div></div>-- <br>John Williams, PhD, B.Eng, <a href="http://B.IT">B.IT</a><br>PetaLogix - Linux Solutions for a Reconfigurable World<br>w: <a href="http://www.petalogix.com">www.petalogix.com</a>  p: +61-7-30090663  f: +61-7-30090663<br>