From: Naveen Kaje <nkaje@codeaurora.org>
To: Sricharan <sricharan@codeaurora.org>,
wsa@the-dreams.de, linux-i2c@vger.kernel.org,
linux-kernel@vger.kernel.org
Cc: linux-arm-msm@vger.kernel.org, rruigrok@codeaurora.org,
timur@codeaurora.org, cov@codeaurora.org,
austinwc@codeaurora.org, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v2 2/2] i2c: qup: support SMBus block read
Date: Thu, 19 May 2016 14:14:02 -0600 [thread overview]
Message-ID: <757c18e2-562a-9f43-0fb6-ab3e7ac3af88@codeaurora.org> (raw)
In-Reply-To: <000d01d1b0d3$d70e1f30$852a5d90$@codeaurora.org>
Hi Sricharan,
On 5/18/2016 1:06 AM, Sricharan wrote:
> Hi,
>
> <snip..>
>
>> +static bool qup_i2c_check_msg_len(struct i2c_msg *msg) {
>> + return ((msg->flags & I2C_M_RD) && (msg->flags &
>> I2C_M_RECV_LEN)); }
>> +
>> +static int qup_i2c_set_tags_smb(u16 addr, u8 *tags, struct qup_i2c_dev
>> *qup,
>> + struct i2c_msg *msg)
>> +{
>> + int len = 0;
>> + int data_len = qup_i2c_get_data_len(qup);
>> +
>> + if (msg->len > 1) {
>> + tags[len++] = QUP_TAG_V2_DATARD_STOP;
>> + tags[len++] = data_len - 1;
>> + } else {
> So we hit this else part for msg->len = 1 and this case blk.pos = 0
> will always be true right ?
Yes, will fix that in V3.
>
>> + if (qup->blk.pos == 0) {
>> + tags[len++] = QUP_TAG_V2_START;
>> + tags[len++] = addr & 0xff;
>> +
>> + if (msg->flags & I2C_M_TEN)
>> + tags[len++] = addr >> 8;
>> + }
>> +
>> + tags[len++] = QUP_TAG_V2_DATARD;
>> + /* 0 implies 256 bytes */
>> + if (data_len == QUP_READ_LIMIT)
>> + tags[len++] = 0;
>> + else
>> + tags[len++] = data_len;
>> + }
> Even data_len will always be '1' right ?
Yes, but here preferably we use a variable than a number without a context.
>> + return len;
>> +}
>> +
>> static int qup_i2c_set_tags(u8 *tags, struct qup_i2c_dev *qup,
>> struct i2c_msg *msg, int is_dma) { @@ -526,6
>> +559,10 @@ static int qup_i2c_set_tags(u8 *tags, struct qup_i2c_dev *qup,
>>
>> int last = (qup->blk.pos == (qup->blk.count - 1)) && (qup->is_last);
>>
>> + /* Handle tags for SMBus block read */
>> + if (qup_i2c_check_msg_len(msg))
>> + return qup_i2c_set_tags_smb(addr, tags, qup, msg);
>> +
>> if (qup->blk.pos == 0) {
>> tags[len++] = QUP_TAG_V2_START;
>> tags[len++] = addr & 0xff;
>> @@ -1065,9 +1102,17 @@ static int qup_i2c_read_fifo_v2(struct
>> qup_i2c_dev *qup,
>> struct i2c_msg *msg)
>> {
>> u32 val;
>> - int idx, pos = 0, ret = 0, total;
>> + int idx, pos = 0, ret = 0, total, msg_offset = 0;
>>
>> + /*
>> + * If the message length is already read in
>> + * the first byte of the buffer, account for
>> + * that by setting the offset
>> + */
>> + if (qup_i2c_check_msg_len(msg) && (msg->len > 1))
>> + msg_offset = 1;
>> total = qup_i2c_get_data_len(qup);
>> + total -= msg_offset;
>>
>> /* 2 extra bytes for read tags */
>> while (pos < (total + 2)) {
>> @@ -1087,8 +1132,8 @@ static int qup_i2c_read_fifo_v2(struct
>> qup_i2c_dev *qup,
>>
>> if (pos >= (total + 2))
>> goto out;
>> -
>> - msg->buf[qup->pos++] = val & 0xff;
>> + msg->buf[qup->pos+msg_offset] = val & 0xff;
> A space around '+' ?
Thanks, will fix that.
>
>> + qup->pos++;
>> }
>> }
>>
>> @@ -1128,6 +1173,22 @@ static int qup_i2c_read_one_v2(struct
>> qup_i2c_dev *qup, struct i2c_msg *msg)
>> goto err;
>>
>> qup->blk.pos++;
>> +
>> + /* Handle SMBus block read length */
>> + if (qup_i2c_check_msg_len(msg) && (msg->len == 1)) {
>> + if (msg->buf[0] > I2C_SMBUS_BLOCK_MAX) {
>> + ret = -EPROTO;
>> + goto err;
>> + }
>> + msg->len += msg->buf[0];
>> + qup->pos = 0;
>> + qup_i2c_set_read_mode_v2(qup, msg->len);
>> + qup_i2c_issue_xfer_v2(qup, msg);
>> + ret = qup_i2c_wait_for_complete(qup, msg);
>> + if (ret)
>> + goto err;
> Is the issue_xfer_v2 needed inside this here ?
No, qup_i2c_issue_xfer_v2 is needed so that we read rest of the data
that is indicated by the length we read earlier.
>
>> + qup_i2c_set_blk_data(qup, msg);
>> + }
>> } while (qup->blk.pos < qup->blk.count);
> Regards,
> Sricharan
Thanks,
Naveen
>
next prev parent reply other threads:[~2016-05-19 20:14 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-11 22:45 [PATCH v2 1/2] i2c: qup: add ACPI support Naveen Kaje
2016-05-11 22:45 ` [PATCH v2 2/2] i2c: qup: support SMBus block read Naveen Kaje
2016-05-18 7:06 ` Sricharan
2016-05-19 20:14 ` Naveen Kaje [this message]
2016-05-19 20:21 ` Timur Tabi
2016-05-19 21:16 ` Naveen Kaje
2016-05-20 8:31 ` Sricharan
2016-05-23 17:45 ` Christ, Austin
2016-05-18 6:04 ` [PATCH v2 1/2] i2c: qup: add ACPI support Sricharan
2016-05-19 20:13 ` Naveen Kaje
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=757c18e2-562a-9f43-0fb6-ab3e7ac3af88@codeaurora.org \
--to=nkaje@codeaurora.org \
--cc=austinwc@codeaurora.org \
--cc=cov@codeaurora.org \
--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=rruigrok@codeaurora.org \
--cc=sricharan@codeaurora.org \
--cc=timur@codeaurora.org \
--cc=wsa@the-dreams.de \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome