From: Vignesh R <vigneshr@ti.com>
To: Evgeniy Polyakov <zbr@ioremap.net>,
"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
Rob Herring <robh+dt@kernel.org>, Pawel Moll <pawel.moll@arm.com>,
Mark Rutland <mark.rutland@arm.com>,
Ian Campbell <ijc+devicetree@hellion.org.uk>,
Kumar Gala <galak@codeaurora.org>,
Jonathan Corbet <corbet@lwn.net>
Cc: Tony Lindgren <tony@atomide.com>, NeilBrown <neilb@suse.de>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Fabian Frederick <fabf@skynet.be>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>
Subject: Re: [PATCH v2] w1: masters: omap_hdq: Add support for 1-wire mode
Date: Fri, 12 Jun 2015 10:53:35 +0530 [thread overview]
Message-ID: <557A6CD7.7060404@ti.com> (raw)
In-Reply-To: <1072261434036874@web13o.yandex.ru>
Hi,
On Thursday 11 June 2015 09:04 PM, Evgeniy Polyakov wrote:
> Hi
>
> 25.05.2015, 08:15, "Vignesh R" <vigneshr@ti.com>:
>>> HDQ mode remains unchanged.
>>>
>>> Signed-off-by: Vignesh R <vigneshr@ti.com>
>
> 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
next prev parent reply other threads:[~2015-06-12 5:23 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-18 12:09 [PATCH v2] w1: masters: omap_hdq: Add support for 1-wire mode Vignesh R
2015-05-18 12:09 ` Vignesh R
2015-05-25 5:15 ` Vignesh R
2015-05-25 5:15 ` Vignesh R
2015-06-11 15:34 ` Evgeniy Polyakov
2015-06-12 5:23 ` Vignesh R [this message]
2015-05-28 21:27 ` Andrew Morton
2015-05-28 21:27 ` Andrew Morton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=557A6CD7.7060404@ti.com \
--to=vigneshr@ti.com \
--cc=akpm@linux-foundation.org \
--cc=corbet@lwn.net \
--cc=devicetree@vger.kernel.org \
--cc=fabf@skynet.be \
--cc=galak@codeaurora.org \
--cc=gregkh@linuxfoundation.org \
--cc=ijc+devicetree@hellion.org.uk \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=neilb@suse.de \
--cc=pawel.moll@arm.com \
--cc=robh+dt@kernel.org \
--cc=tony@atomide.com \
--cc=zbr@ioremap.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.