Device tree BSP
John Williams
john.williams at petalogix.com
Sun Jul 5 19:18:12 EST 2009
On Sun, Jul 5, 2009 at 4:15 AM, Stephen Neuendorffer <
stephen.neuendorffer at xilinx.com> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/devicetree-discuss/attachments/20090705/203081ff/attachment.htm>
More information about the devicetree-discuss
mailing list