Hi, On Thursday 11 June 2015 09:04 PM, Evgeniy Polyakov wrote: > Hi > > 25.05.2015, 08:15, "Vignesh R" <vigneshr@xxxxxx>: >>> HDQ mode remains unchanged. >>> >>> Signed-off-by: Vignesh R <vigneshr@xxxxxx> > > I have no experience with omap_hdq platform, but there are quite a few questions > related to IO - you never check whether write was successful or read returned actually > valid data, is it ok? I mean is it correct to assume that read can not return 0xff for example > and it is a sign that something is wrong, or this can not happen? > Referring to AM437x TRM SPRUHL7C (www.ti.com/lit/ug/spruhl7c/spruhl7c.pdf) section 23.3.5.4, Successful or failed completion is not indicated for write operation, so there is no way to verify whether write succeeded (though TX_COMPLETE interrupt bit is set on transaction completion). But, as for as read operation is concerned, the TRM says, if RX_COMPLETE bit is set, then read is successful and I think that implies valid data is present in RX reg. My patch does look for TX/RX_COMPLETE bits to be set after write/read operations. > As for me, I have no objection, but this patch must go via omap tree imo. > Andrew Morton has already picked this patch (its on linux-next). Although he has a minor comment on use of mutex_lock_interruptible. But that comment applies to many places in the existing driver code. I plan to cleanup all those mutex calls in near future. Regards Vignesh -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
