On 11/10/13 10:42, Dr. H. Nikolaus Schaller wrote: > I am not sure if there is a SPI driver for a McBSP port [1]? And to make that > work (reliably) and tested it might need a lot of work for us. At least I think > such a change (e.g. setting up clock polarity etc.) is not done in some minutes. > And the only feedback we have from the panel is "does not work"/"works". I.e. > if we are not lucky that it works immediately we have no real means to debug. > > IMHO it also gives more flexibility to board designers to choose GPIOs instead > of enforcing some SPI interface by the driver (and encapsulate this arguable > protocol in the driver). Maybe some board has 3 spare GPIOs but neither > McBSPs nor McSPIs available. This has been an interesting thread, I've learnt a lot =). I still think the panel driver should not handle this, but there should be a separate spi bitbang driver for it. I understand you're not enthusiastic going that way, as the current version works for you. However, when using DT, we need to think how to represent the hardware in the device tree data, and it has to be right from the beginning. That's why I won't allow representing this panel as having 4 gpios in the DT data, because that is not correct. The panel has 3 pins. But then, the panel does allow reading, which could be implemented using 4 gpios as you have done. This data should be in the spi-bitbang data, and the panel should just use the standard SPI framework. Using SPI framework does not mean you should use McBSP or McSPI. It's up to you how the 3-wire SPI is implemented on the SoC side, the panel would just work in all the cases. Tomi
Attachment:
signature.asc
Description: OpenPGP digital signature
