| Message ID | 20180101133749.29567-1-linus.walleij@linaro.org |
|---|---|
| Headers | show |
| Series | Rewrite GPIO SPI to use descriptors | expand |
On Mon, Jan 1, 2018 at 2:37 PM, Linus Walleij <linus.walleij@linaro.org> wrote: > Just as it says, this rewrites the GPIO bit-banged SPI driver to > just use GPIO descriptors and pushes the configuration of the GPIO > lines down into devices trees and board files. I pulled this into my Gemini tree where I have a bit-banged SPI device based on device tree, and everything works smoothly. So all DT-based users of GPIO SPI should be working fine after this series. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-spi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
T24gTW9uLCAyMDE4LTAxLTAxIGF0IDE0OjM3ICswMTAwLCBMaW51cyBXYWxsZWlqIHdyb3RlOg0K PiBKdXN0IGFzIGl0IHNheXMsIHRoaXMgcmV3cml0ZXMgdGhlIEdQSU8gYml0LWJhbmdlZCBTUEkg ZHJpdmVyIHRvDQo+IGp1c3QgdXNlIEdQSU8gZGVzY3JpcHRvcnMgYW5kIHB1c2hlcyB0aGUgY29u ZmlndXJhdGlvbiBvZiB0aGUgR1BJTw0KPiBsaW5lcyBkb3duIGludG8gZGV2aWNlcyB0cmVlcyBh bmQgYm9hcmQgZmlsZXMuDQoNCkFueSBiZWZvcmUvYWZ0ZXIgYmVuY2htYXJrIGZvciBzcGVlZCBv ciBjb2RlIHNpemU/DQoNCj4gDQo+ICAxMiBmaWxlcyBjaGFuZ2VkLCAzMTEgaW5zZXJ0aW9ucygr KSwgMzIwIGRlbGV0aW9ucygtKQ0KPiANCg0KTG9va3MgbGlrZSBjb2RlIHNpemUgaXMgcHJldHR5 IGV2ZW4u -- To unsubscribe from this list: send the line "unsubscribe linux-spi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Jan 2, 2018 at 7:42 PM, Trent Piepho <tpiepho@impinj.com> wrote: > On Mon, 2018-01-01 at 14:37 +0100, Linus Walleij wrote: >> Just as it says, this rewrites the GPIO bit-banged SPI driver to >> just use GPIO descriptors and pushes the configuration of the GPIO >> lines down into devices trees and board files. > > Any before/after benchmark for speed or code size? Not really, the main motivation for the change is neither performance nor object code size, but to get rid of the global GPIO numbers, which does not scale very well and makes stuff messy. Istead we aim to make code deal with abstract GPIO handles known as GPIO descriptors. The motivation is the same as for moving IRQ numbers to IRQ descriptors which has been going on for some time: it is easy when you have just say 64 IRQs or GPIOs. The subsystems were designed for that. As the number IRQ controllers and GPIO controllers on a system grows, managing the number space and the hardware descriptions becomes a pain. I'd be surprised if either performance or object code size is affected in a bad way though. I don't have any high-speed SPI devices I can test really, and loopback would require some special hardware set-up I don't have. The last patch in the series remove remnants of an unused mechanism that seemed to be for performance critical bitbanged SPI, that was never put to use, I kind of assume noone is really doing performance critical SPI over GPIO but I've been wrong before. > Looks like code size is pretty even. Number of lines yes, readability I would argue is better but it is a matter of taste. I would hope some bytes have been pushed away from the core and into the board files (etc) but I could be wrong. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-spi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Jan 03, 2018 at 12:17:07AM +0100, Linus Walleij wrote: > I'd be surprised if either performance or object code size is affected > in a bad way though. I don't have any high-speed SPI devices I can test > really, and loopback would require some special hardware set-up I > don't have. You could just do something like spin on register reads on some device or something? Something like dumping a regmap via debugfs would do the trick probably. I too would be surprised if there were a substantial hit but it'd be good to check, while they've never been fast equally the slowness can make people more sensitive to performance (including impact on the rest of the system). One of the reasons people can end up with the GPIO controller is discovering some hardware bug in a hardware controller (like the issues a lot of the Freescale controllers have with trying to deassert chip select on every word transferred). > The last patch in the series remove remnants of an unused mechanism > that seemed to be for performance critical bitbanged SPI, that was never > put to use, I kind of assume noone is really doing performance critical > SPI over GPIO but I've been wrong before. It was never really possible to upstream users of that code, AFAICT it was always for custom out of tree builds.
On Wed, Jan 3, 2018 at 5:24 PM, Mark Brown <broonie@kernel.org> wrote: > On Wed, Jan 03, 2018 at 12:17:07AM +0100, Linus Walleij wrote: > >> I'd be surprised if either performance or object code size is affected >> in a bad way though. I don't have any high-speed SPI devices I can test >> really, and loopback would require some special hardware set-up I >> don't have. > > You could just do something like spin on register reads on some device > or something? Something like dumping a regmap via debugfs would do the > trick probably. OK I tried this on my new Ilitek ILI9322 panel driver: A script like this dumping the regmap 10000 times (it has no caching obviously) on an otherwise idle system in two iterations before and after the patches: #!/bin/sh for run in `seq 10000` do cat /debug/regmap/spi0.0/registers > /dev/null done Before the patch: time test.sh real 3m 41.03s user 0m 29.41s sys 3m 7.22s time test.sh real 3m 44.24s user 0m 32.31s sys 3m 7.60s After the patch: time test.sh real 3m 41.32s user 0m 28.92s sys 3m 8.08s time test.sh real 3m 39.92s user 0m 30.20s sys 3m 5.56s So any performance differences seems to be in the error margin. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-spi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html