From: Wolfram Sang <wsa@the-dreams.de>
To: Sricharan R <sricharan@codeaurora.org>
Cc: devicetree@vger.kernel.org, linux-arm-msm@vger.kernel.org,
agross@codeaurora.org, linux-kernel@vger.kernel.org,
linux-i2c@vger.kernel.org, iivanov@mm-sol.com,
galak@codeaurora.org, dmaengine@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, andy.gross@linaro.org,
ntelkar@codeaurora.org, architt@codeaurora.org
Subject: Re: [PATCH V7 3/6] i2c: qup: Transfer each i2c_msg in i2c_msgs without a stop bit
Date: Sun, 24 Jan 2016 12:29:16 +0100 [thread overview]
Message-ID: <20160124112915.GA1775@katana> (raw)
In-Reply-To: <1453197766-18976-4-git-send-email-sricharan@codeaurora.org>
[-- Attachment #1: Type: text/plain, Size: 997 bytes --]
Hi,
> "If this is the last message in a group, it is followed by a STOP.
> Otherwise it is followed by the next @i2c_msg transaction segment,
> beginning with a (repeated) START"
This is correct.
> So the expectation is that there is no 'STOP' bit inbetween individual
> i2c_msg segments with repeated 'START'. The QUP i2c hardware has no way
> to inform that there should not be a 'STOP' at the end of transaction.
> The only way to implement this is to coalesce all the i2c_msg in i2c_msgs
> in to one transaction and transfer them. Adding the support for the same.
So, there will not be a REP_START condition on the bus? I am sorry to
say that I can't accept this. A REP_START is a REP_START and nothing
else. There are devices which will get confused if there is no real
REP_START condition.
Without knowing the HW in detail, can't you implement I2C_M_NOSTART and
let the touchscreen driver use it via regmap? That would be the proper
way (from what I understand).
Regards,
Wolfram
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: wsa@the-dreams.de (Wolfram Sang)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH V7 3/6] i2c: qup: Transfer each i2c_msg in i2c_msgs without a stop bit
Date: Sun, 24 Jan 2016 12:29:16 +0100 [thread overview]
Message-ID: <20160124112915.GA1775@katana> (raw)
In-Reply-To: <1453197766-18976-4-git-send-email-sricharan@codeaurora.org>
Hi,
> "If this is the last message in a group, it is followed by a STOP.
> Otherwise it is followed by the next @i2c_msg transaction segment,
> beginning with a (repeated) START"
This is correct.
> So the expectation is that there is no 'STOP' bit inbetween individual
> i2c_msg segments with repeated 'START'. The QUP i2c hardware has no way
> to inform that there should not be a 'STOP' at the end of transaction.
> The only way to implement this is to coalesce all the i2c_msg in i2c_msgs
> in to one transaction and transfer them. Adding the support for the same.
So, there will not be a REP_START condition on the bus? I am sorry to
say that I can't accept this. A REP_START is a REP_START and nothing
else. There are devices which will get confused if there is no real
REP_START condition.
Without knowing the HW in detail, can't you implement I2C_M_NOSTART and
let the touchscreen driver use it via regmap? That would be the proper
way (from what I understand).
Regards,
Wolfram
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160124/7cc28096/attachment.sig>
next prev parent reply other threads:[~2016-01-24 11:29 UTC|newest]
Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-19 10:02 [PATCH V7 0/6] i2c: qup: Add support for v2 tags and bam dma Sricharan R
2016-01-19 10:02 ` Sricharan R
2016-01-19 10:02 ` [PATCH V7 1/6] i2c: qup: Change qup_wait_writeready function to use for all timeouts Sricharan R
2016-01-19 10:02 ` Sricharan R
2016-01-19 10:02 ` Sricharan R
2016-02-12 18:37 ` Wolfram Sang
2016-02-12 18:37 ` Wolfram Sang
2016-01-19 10:02 ` [PATCH V7 2/6] i2c: qup: Add V2 tags support Sricharan R
2016-01-19 10:02 ` Sricharan R
2016-02-12 18:37 ` Wolfram Sang
2016-02-12 18:37 ` Wolfram Sang
2016-01-19 10:02 ` [PATCH V7 3/6] i2c: qup: Transfer each i2c_msg in i2c_msgs without a stop bit Sricharan R
2016-01-19 10:02 ` Sricharan R
2016-01-24 11:29 ` Wolfram Sang [this message]
2016-01-24 11:29 ` Wolfram Sang
2016-01-28 4:57 ` Sricharan
2016-01-28 4:57 ` Sricharan
2016-01-28 4:57 ` Sricharan
2016-02-04 20:09 ` Wolfram Sang
2016-02-04 20:09 ` Wolfram Sang
2016-02-05 8:00 ` Sricharan
2016-02-05 8:00 ` Sricharan
2016-02-05 8:00 ` Sricharan
2016-02-12 18:38 ` Wolfram Sang
2016-02-12 18:38 ` Wolfram Sang
2016-01-19 10:02 ` [PATCH V7 4/6] i2c: qup: Add bam dma capabilities Sricharan R
2016-01-19 10:02 ` Sricharan R
2016-02-12 18:37 ` Wolfram Sang
2016-02-12 18:37 ` Wolfram Sang
2016-02-12 18:42 ` Wolfram Sang
2016-02-12 18:42 ` Wolfram Sang
2016-02-13 6:58 ` Sricharan
2016-02-13 6:58 ` Sricharan
2016-02-13 6:58 ` Sricharan
2016-02-22 12:24 ` Sricharan
2016-02-22 12:24 ` Sricharan
2016-02-22 12:24 ` Sricharan
2016-02-22 12:32 ` Wolfram Sang
2016-02-22 12:32 ` Wolfram Sang
2016-02-22 13:41 ` Sricharan
2016-02-22 13:41 ` Sricharan
2016-02-22 13:41 ` Sricharan
2016-01-19 10:02 ` [PATCH V7 5/6] dts: msm8974: Add blsp2_bam dma node Sricharan R
2016-01-19 10:02 ` Sricharan R
[not found] ` <1453197766-18976-6-git-send-email-sricharan-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2016-03-25 23:17 ` Bjorn Andersson
2016-03-25 23:17 ` Bjorn Andersson
2016-03-25 23:17 ` Bjorn Andersson
2016-03-26 2:26 ` Andy Gross
2016-03-26 2:26 ` Andy Gross
2016-03-28 12:59 ` Sricharan
2016-03-28 12:59 ` Sricharan
2016-03-28 12:59 ` Sricharan
2016-01-19 10:02 ` [PATCH V7 6/6] dts: msm8974: Add dma channels for blsp2_i2c1 node Sricharan R
2016-01-19 10:02 ` Sricharan R
2016-01-19 10:14 ` [PATCH V7 0/6] i2c: qup: Add support for v2 tags and bam dma Sricharan
2016-01-19 10:14 ` Sricharan
2016-01-19 10:14 ` Sricharan
2016-01-24 11:33 ` Wolfram Sang
2016-01-24 11:33 ` Wolfram Sang
2016-01-28 5:27 ` Sricharan
2016-01-28 5:27 ` Sricharan
2016-01-28 5:27 ` Sricharan
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=20160124112915.GA1775@katana \
--to=wsa@the-dreams.de \
--cc=agross@codeaurora.org \
--cc=andy.gross@linaro.org \
--cc=architt@codeaurora.org \
--cc=devicetree@vger.kernel.org \
--cc=dmaengine@vger.kernel.org \
--cc=galak@codeaurora.org \
--cc=iivanov@mm-sol.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ntelkar@codeaurora.org \
--cc=sricharan@codeaurora.org \
/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.