tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: RFC: gpio attachment for ppbus

>> One thing I would suggest is that you document which order the data
>> pins and the control pins are written in, when changing both.  (Or
>> does the scaffolding allow userland to control that order?  I don't
>> know gpiobus.)
> The current gpio API does not allow changing more than one pin at a
> time, so you are forced to implement the order yourself.

If that means it takes five syscalls to change five pins, I think I'd
stick with hacking the lpt driver.  But if there's some way to batch
changes, to send many of them across the kernel/user boundary at once,
it'd be somewhat awkward but probably OK.  (Indeed, I might hack the
infrastructure to provide a way to change multiple pins at once insofar
as the harware permits it, rather than hacking the lpt driver.  Depends
on whether the difficulty of doing it seems worth the additional

> There is also no distinction between data pins, status pins and
> control pins, they are all just gpio pins.

I wouldn't expect there'd be any difference at the API level, but there
is a difference at the hardware level - as far as I can tell, you can
change multiple data pins, or multiple control pins, simultaneously but
you can't change data pins and control pins simultaneously, hence the

/~\ The ASCII                           der Mouse
\ / Ribbon Campaign
 X  Against HTML     
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

Home | Main Index | Thread Index | Old Index