On Sun, Jul 5, 2009 at 4:15 AM, Stephen Neuendorffer < [email protected]> 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
_______________________________________________ devicetree-discuss mailing list [email protected] https://ozlabs.org/mailman/listinfo/devicetree-discuss
