On Wed, Feb 27, 2013 at 1:22 AM, Alexandre Courbot <gnu...@gmail.com> wrote: > On Wed, Feb 27, 2013 at 2:53 AM, Grant Likely <grant.lik...@secretlab.ca> > wrote: >> On Fri, 22 Feb 2013 11:19:44 +0900, Alexandre Courbot <gnu...@gmail.com> >> wrote: >>> Grant, will you be able to include these for 3.9? They fix code that >>> you merged recently, so I'd be glad if they could be squashed into the >>> patch mentioned in the description. >> >> They won't get squashed in because the tree is already composed and in >> linux-next. I don't rebase unless I really need to. I've applied them >> and I'll probably push to Linus since they are effectively bug fixes of >> a sort and the merge window hasn't closed yet. > > That's fine too - as long as the patches with side-effects are merged. > That will allow me to continue going forward with GPIO, thanks!
While you're working on that, I'd like you to keep the following in mind. I'm getting concerned with the level of overhead that the gpio access routines are incuring. They're doing a lot of checks right now when with GPIOs we want it to be as fast as possible for the case of mmio gpios. (i2c and spi gpios are always going to be slow, so I'm not so concerned here). gpio_get, gpio_set and gpio_direction all need to be fast. Basically, I think the model should be that if you've got a gpio_desc pointer, then you've got a valid gpio. A lot of the checks that are currently performed in the gpiod_ versions of functions can be moved to the gpio_ versions where a lookup has to be performed anyway. For example, right now gpiod_direction_output() is 61 lines long. Madness! :-) I've been playing with an idea of pulling in some basic MMIO gpio access directly into gpiolib so that when appropriate gpiolib itself can have a fast path for doing the register access and shadow register management. g. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
