Re: [microblaze-uclinux] GPIO thoughts

[John Williams <jwilliams@xxxxxxxxxxxxxx>]

Hi Paul,

Thanks for your thoughts, see my comments below:

Paul Hartke wrote:

> The IBMGPIO_IN and IBMGPIO_OUT ioctls operate as I would expect:
> http://cvs.uclinux.org/cgi-bin/cvsweb.cgi/uClinux-2.4.x/drivers/char/xilinx_gpio/adapter.c?rev=1.2;content-type=text%2Fplain
> However, IBMGPIO_TRISTATE uses the MASK field to set the data direction
> instead of the data field.  That seems counterintuitive to me.
> 
> Anyhow, to use the GPIO as outputs--even if the pcore is configured to only
> use inputs, the IBMGPIO_TRISTATE ioctl must write out all 0s to set the
> current direction.

When I did this GPIO driver, however many aeons ago, I based it on the
one MontaVista had written for the PPC.  However, the IOCTL protocol, in
fact its entire operation, made absolutely no sense to me whatsoever -
utterly counter-intuitive  So, I just rejigged it into something that
seemed (at the time) a bit more logical.

I haven't looked at it since, and am definitely open to ideas on what it
should look like.  If merging back to the MV/PPC driver is a good idea,
then go for it.

> The first GPIO device is accessed via mach_hearbeat() in
> linux-2.4.x/arch/microblaze/platform/uclinux-auto/machine.c  It took me a
> little while to figure out that this was overriding my GPIO usage.  Are
> folks out there actively utilizing this heartbeat?  I suggest disabling it
> by default and letting those that want to use it to enable it.  John
> Williams: what say you?

Disabling it is probably a reasonable idea - but this is actually is the
tip of a pretty subtle iceberg:

autoconfig is great but it's simple.  One of the assumptions it makes is
that you want all of your peripherals, of whatever type, exported to the
auto-config process.  This is generally a reasonable assumption.

But, not all GPIOs are equal.  Some you might want exported to the
device driver on /dev/gpio, others, like a heartbeat LED, or reset
button, or, or.... really have a special purpose.  auto-config cannot
figure this out by itself.

To that end, you may have noticed a special, undocumented parameter
supported by the uClinux MLD/TCL scripts, "periph_type_overrides".  This
is a tricky hack that allows you to specify, in the MSS file, that a
certain peripheral is to be treated specially, rather than just dumped
along with all aother peripherals.  Example of use is like:

PARAMETER PERIPH_TYPE_OVERRIDES={opb_gpio1 heartbeat_led}

This will cause the peripheral instance "opb_gpio1" to be exported as
thought its type is actually HEARTBEAT_LED, not OPB_GPIO

So, the auto-config.in file will end up with parameters like

CONFIG_XILINX_HEARTBEAT_LED_0_BASEADDR
CONFIG_XILINX_HEARTBEAT_LED_0_HIGHADDR

and so on.

Hard to explain, easy to play with.

This might seem a bit strange, but in auto-config I was determined not
to require a specific peripheral naming scheme in the MHS file, as is
required by the MV/Linux BSP stuff.  Instead, the periph_type_overrides
parameter is a relatively simple way of making a mapping between certain
periphs in the MHS file, and some "special meaning" in the kernel.

Anyway that's enough explanation, have a play with it and see if any
brilliant ideas come to mind!

Cheers,

John
___________________________
microblaze-uclinux mailing list
microblaze-uclinux@xxxxxxxxxxxxxx
Project Home Page : http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux
Mailing List Archive : http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/