Hi Tomi, Am 11.10.2013 um 12:09 schrieb Tomi Valkeinen: > On 11/10/13 12:50, Dr. H. Nikolaus Schaller wrote: > >> 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. > > Lars-Peter said "Back in the OpenMoko days we used the panel in normal > 4-wire SPI mode with the GPIO bitbang SPI master." > > I don't know much about SPI, so I can't answer to that. If the serial > bus is indeed not any kind of more or less standard SPI version, but > really a custom bus for this controller, then the case is a bit unclear. I have thought over lunch time that it is worth to look into how the Openmoko did physically hook up the display and if parts of that code (it was for 2.6.26 or so and for a Samsung SoC) is understandable and reusable (e.g. hints how to set up the board file for a bitbang SPI on OMAP3 - we have never done this before). > >> 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). > > I don't have anything against that as long as we use only platform data. > > But DT data is not an in-kernel API, it's an external API. Once we > define that the DT data for this panel is something, that's it, we > should stick to it. Of course, we can build compatibility layers for old > DT data, but I would avoid that if at all possible. Ah, I see. I already think that using the DT makes such things not easier but more difficult - but I am not at all familiar with it. > If we now create the DT data with gpios, and the panel as platform > device, it'd be rather nasty change to make it a child of an spi bus. (I > presume, I have never made such a change). > > And, as the gpios and platform device approach is clearly wrong way to > describe the hardware, I'm quite against using that description in the > DT data. Since we are not familiar with DT yet, it is difficult to see the consequences of such a step. > That said, one option is to describe the hardware correctly in the DT > data, but have a platform device for the panel, with panel driver doing > the bitbanging. In that case it is possible to update the system to use > SPI framework if needed, without changing the DT data. However, I'm not > sure how easy that would be. Sounds quite complex, indeed. So our next step will be to look into the GTA02 SPI thing to get more knowlegde about thier solution. 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
