linux-kernel - Re: [PATCH RFC 1/2] gpio: Add a block GPIO API to gpiolib

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAOY=C6ERUegNVbVST-OB0ztRYZJGD5g9-HTnASn7E3OaLfxXAA@mail.gmail.com>
Date:	Sun, 30 Sep 2012 17:11:01 +0200
From:	Stijn Devriendt <highguy@...il.com>
To:	Roland Stigge <stigge@...com.de>
Cc:	Jean-Christophe PLAGNIOL-VILLARD <plagnioj@...osoft.com>,
	linus.walleij@...aro.org, linux-kernel@...r.kernel.org,
	w.sang@...gutronix.de, grant.likely@...retlab.ca,
	linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH RFC 1/2] gpio: Add a block GPIO API to gpiolib

On Sun, Sep 30, 2012 at 12:34 PM, Roland Stigge <stigge@...com.de> wrote:
> On 29/09/12 21:57, Jean-Christophe PLAGNIOL-VILLARD wrote:
>>> Problem here is that it's only an intermediate format since hardware
>>> often needs special preparation of the data.
>>>
>>> But will evaluate what makes most sense.
>> the key point here is to avoid to manipualte data each time we call
>> gpio_block_set
>>
>> hardware specific will have to be handle at driver level
>
> Understand, thanks! I'm just trying to prevent overly complex API because:
>
> * In our discussed scheme, the driver still needs to convert the data bits
The u32 mask scheme fits simple-gpio drivers (1 register for input/output,
1 for direction, e.g. mpc8xxx driver) pretty well. Consider that to get
true synchronous output behavior of multiple pins, this is probably the only
option anyway.
For the cavium octeon driver (which doesn't seem to be upstream yet; sports
a single register for readout, per-pin write register) you can only emulate
group behavior by looping over the mask, without synchronous behavior.

> * In practice, the block gpio API is especially useful for use on single
> gpio_chips (only there, a real simultaneous i/o is possible anyway)
> * Wouldn't introduce this kind of optimization in lack of measurable
> improvement
> * The actual i/o data bits still need handling, generating a bit CPU
> load anyway.

I believe it's not worth it to try and save some tens of CPU cycles, considering
that GPIO pins might be on some slower bus anyway. Even then, simple-gpio
drivers have 0 added overhead, because they can use the mask
straight away. That means all processing is done in gpiolib's code and
is limited
to a loop of 32 iterations at most...

For drivers where performance really is critical, you could probably precompute
the needed values:
sclmask = gpio_group_precompute(MY_I2C_SCL)
sdamask = gpio_group_precompute(MY_I2C_SDA)
gpio_group_set_direct(sclmask | sdamask)

Regards,
Stijn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/