Messages in this thread | | | Date | Sat, 19 Sep 2009 12:40:44 +0800 | Subject | Re: [PATCH] gpiolib: introduce for_each_gpio_in_chip macro | From | Jaya Kumar <> |
| |
On Sat, Sep 19, 2009 at 8:42 AM, H Hartley Sweeten <hartleys@visionengravers.com> wrote: > On Friday, September 18, 2009 5:03 PM, Jaya Kumar wrote: > > Hmm.. That patchset is a lot different than what I was thinking of. Your > patch allows a variable width to the number of gpio's in the "port". But > it also still gets/sets the "port" by individual bit accesses to the > gpio_chip. By doing this I don't see how you could get a performance > increase.
It only does individual bit set/get if the specific arch does not offer a multi bit set/get. See __gpio_set_batch_generic which calls chip->set versus __gpio_set_batch which calls chip->set_batch so that if the underlying architecture supports it then we do multi-bit access. I provided one for pxa here: http://marc.info/?l=linux-kernel&m=123287743104542&w=2 . So, the following scenarios should all be optimized for:
a) if the user calls gpio_s/get_batch with a width that fits the native register width and all those bits fit into the said register, then it results in a call directly to the multibit register set/get function/inline. For example, on pxa with above implementation, gpio_set_batch(1, mask=0xFFFFFFF, value=0xc001f00d), at compile time, that will result in a single GPSR/GPCR. b) if the user calls gpio_s/get_batch with a width that more than one register, the implementation walks the bits and splits it across the registers as needed. This is done in __gpio_s/get_batch c) if the user calls the gpio_s/get_batch with non-consecutive bits using the 32-bit mask, then the implementation walks the bits and splits it across the registers as needed.
So, it is fairly optimized. If I understood David's suggested design correctly, it is one where the user does not need to worry about masks or widths at all. Instead, you register with the library, a list of bits you want to make a bus out of, and then the library is responsible for taking that and optimizing that further as much as possible. I agree that that would be a more elegant API. What I was hoping for is that my implementation above could be a starting point for that by first providing optimized multi-bit access that could be used by the more elegant API.
Thanks, jaya -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |