Hi Lars-Peter, ah, I didn't see your mail while writing mine - so some overlap. Am 11.10.2013 um 09:08 schrieb Lars-Peter Clausen: > On 10/11/2013 06:41 AM, Tomi Valkeinen wrote: >> On 10/10/13 21:58, Lars-Peter Clausen wrote: >> >>> According to the datasheet the the panel as a dedicated dout pin. Maybe >>> you did not connect it in your design, which means you won't be able to >>> read any data from the panel at all. >> >> I don't see a dedicated dout in the datasheet... >> http://dl.wolfgang-draxinger.net/openmoko/doc/TD028TTEC1.pdf > > Hm, ok, looks like the display controller used in the panel (the jbt6k74) has separate DIN and DOUT, but the panel only has one pin. Yes > But the datasheet for the panel is not exactly clear Yes > on whether it's DIN pin is both the DIN and DOUT pin from the controller or, just DIN and DOUT not being connected at all. I think they have a 4-wire controller in the panel and tied the lines together. This works if they properly control the data direction. There are some read commands where this direction reversal happens. > >> >>> Also your custom bitbang code looks a bit strange: >>> >>> gpio_set_value(data->dout_gpio, 1); >>> if (gpio_get_value(data->din_gpio) == 0) >>> return 1; >>> >>> You set the state on the dout pin and then read the din pin, if both do >>> not match you abort with an error. This suggest that, for whatever >>> reason, you feed the dout pin back into the din pin in your design. Btw. >>> this is also the only place where din is used in your driver. >> >> Yes, he said the single "Serial interface data input/output" pin is >> connected to both din and dout on the SoC. I guess the purpose of that >> gpio_get_value() is to ensure that the panel is not pulling the line >> when the SoC is writing to it. Not that I really understand how that can >> work, but I'm not a HW guy =). > > Hm, ok. I don't think the panel will ever actively drive the line. Well it will drive it if we issue some read command (but I have no information about these commands). > So in my opinion using either the McBSP SPI master or the GPIO bitbang SPI master should work just fine. You just wouldn't be able to read any register from the device. But the driver is not attempting to do this, so it should be fine. 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. BR, Nikolaus http://lists.infradead.org/pipermail/linux-arm-kernel/2011-June/053064.html -- 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
