<br><br><div class="gmail_quote">On Sun, Jul 5, 2009 at 4:15 AM, Stephen Neuendorffer <span dir="ltr"><<a href="mailto:stephen.neuendorffer@xilinx.com">stephen.neuendorffer@xilinx.com</a>></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'm not exactly sure what you're trying to do here, but it doesn't look right to me.<br>
In particular, why would I have to have a separate core for these functions?<br>
Furthermore, I'm sure there must be some generic mechanisms that can/should be used for these kind of things.<br>
In general, we shouldn'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'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 "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!<br>
<br>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.<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>