Hi, On Fri, 2011-08-05 at 00:17 -0700, Arve Hjønnevåg wrote: > 2011/8/5 Tomi Valkeinen <tomi.valkeinen@xxxxxx>: > > On Thu, 2011-08-04 at 18:15 -0700, Arve Hjønnevåg wrote: > >> 2011/8/4 Tomi Valkeinen <tomi.valkeinen@xxxxxx>: > >> > Hi, > >> > > >> > On Wed, 2011-06-29 at 20:44 -0700, Arve Hjønnevåg wrote: > >> >> Change-Id: I18168c887e1384c07dc033a1ffc57abdacb26073 > >> >> Signed-off-by: Arve Hjønnevåg <arve@xxxxxxxxxxx> > >> >> --- > >> >> drivers/video/omap2/dss/dsi.c | 7 ++++++- > >> >> 1 files changed, 6 insertions(+), 1 deletions(-) > >> > > >> > This feels somehow partial... Why do you want to read generic packets if > >> > there are no functions to send generic packets? > >> > > >> > >> The chip responds with a generic packet when reading from some > >> registers. This is a simple fix while adding support for sending > >> generic packets would probably require an api change. > > > > What command do you use to read the register? DCS? If so, sounds rather > > strange HW implementation. > > > > This change modifies dsi_vc_dcs_read to accept a generic response Ok, so you do send a DCS read command, and you get a generic response. > packet. If you want a separate generic read command that would also > work, but the it would make it a little harder to write the driver > since you then would need to know what type of response the chip > sends. Well, you do know what type of response the chip sends. According to MIPI DSI spec, a DCS read is answered with DCS short/long response, and a generic read is answered with generic short/long response. If your HW doesn't work like that, it's against the spec. If a broken chip like that was widely used, I guess we would have to add a hack for that, but until such day I want to keep the driver working as the spec says. Tomi -- 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
