Hi all, Am 11.10.2013 um 11:06 schrieb Lars-Peter Clausen: > On 10/11/2013 10:59 AM, Belisko Marek wrote: >> Hi Tomi, >> >> On Fri, Oct 11, 2013 at 10:17 AM, Tomi Valkeinen <tomi.valkeinen@xxxxxx> wrote: >>> 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. >> I disagree. There are different drivers which pass in platform data >> gpios (encoder-tfp410.c or encoder-tpd12s015.c) >> and those must be covered by DT then. I cannot see problem why to have >> for td028 panel 3 or 4 gpios defined in DT. > > The problem is not representing it in the devicetree, but representing it > correctly. This is a SPI slave device, hence it should be presented in the > devicetree as a SPI slave device and not as a platform device with 4 GPIOs. Hm. Is this a SPI or does it just look like one? Or is it some - otherwise unknown - "3 wire serial interface". Or is it a "3(+1) GPIO slave device"? I am still not sure about this. If we really want to do it correctly, we may have to write a driver for that special serial protocol as well. If it turns out that we can't mis-use and tweak it into a standard SPI driver with bit-bang backend. I simply fear that we get dependencies with the SPI subsystem and have to test, debug and maintain it. Maintaining the GPIO thing we currently have is easy. What would be against taking the GPIO approach first and then upgrade as soon as someone raises his/her finger that he/she wants to really interface this display differently and is not happy with the 3/4 GPIOs? Either they come up with a patch or contact the driver author (=me). BR, Nikolaus -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
