From: Lucas De Marchi <lucas.demarchi@intel.com>
To: Jarkko Nikula <jarkko.nikula@linux.intel.com>,
"linux-i2c@vger.kernel.org" <linux-i2c@vger.kernel.org>
Cc: "wsa@the-dreams.de" <wsa@the-dreams.de>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"mika.westerberg@linux.intel.com"
<mika.westerberg@linux.intel.com>,
Christian Ruppert <christian.ruppert@alitech.com>
Subject: Re: [PATCH] i2c: designware: do not disable adapter after transfer
Date: Mon, 25 Apr 2016 12:04:47 -0300 [thread overview]
Message-ID: <571E320F.1020607@intel.com> (raw)
In-Reply-To: <571E04BA.3030301@linux.intel.com>
On 04/25/2016 08:51 AM, Jarkko Nikula wrote:
[ ... ]
>> @@ -413,8 +416,16 @@ static void i2c_dw_xfer_init(struct dw_i2c_dev *dev)
>> struct i2c_msg *msgs = dev->msgs;
>> u32 ic_con, ic_tar = 0;
>>
>> - /* Disable the adapter */
>> - __i2c_dw_enable(dev, false);
>> + if (dev->enabled) {
>> + u32 ic_status;
>> +
>> + /* check ic_tar and ic_con can be dynamically updated */
>> + ic_status = dw_readl(dev, DW_IC_STATUS);
>> + if (ic_status & DW_IC_STATUS_ACTIVITY
>> + || !(ic_status & DW_IC_STATUS_TX_EMPTY)) {
>> + __i2c_dw_enable(dev, false);
>> + }
>> + }
>>
> Worth to double check this. I see bit 1 means TX FIFO not full and bit 2
> is TX FIFO completely empty.
the conditions to be able to update IC_TAR dynamically are:
- Adapter isn't doing any TX/RX operation (IC_STATUS[5] == 0) and
- There are no entries in TX FIFO (IC_STATUS[2] == 1)
So... yeah, the condition above seems wrong. I should be reading bit 5,
not bit 1. Thanks! However:
IC_STATUS[5] signals activity for master mode
IC_STATUS[6] signals activity for slave mode
IC_STATUS[0] is IC_STATUS[5]|IC_STATUS[6]
And this controller is never in slave mode, only master mode, so it
should be equivalent.
I wonder if I even have to check bit 5 since AFAICS we wouldn't be able
to even call this function if there were any operation on tx/rx.
>
> Otherwise I'm fine with the patch as long as it works for Christian.
>
Anyway, I'll re-test with bit 5 checked and send an update.
Lucas De Marchi
next prev parent reply other threads:[~2016-04-25 15:04 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-01 2:47 [PATCH] i2c: designware: do not disable adapter after transfer Lucas De Marchi
2016-04-07 13:37 ` Christian Ruppert
2016-04-07 17:28 ` De Marchi, Lucas
2016-04-08 14:01 ` Christian Ruppert
2016-04-22 15:08 ` Lucas De Marchi
2016-04-22 15:19 ` Lucas De Marchi
2016-05-02 10:11 ` Christian Ruppert
2016-05-04 14:38 ` Lucas De Marchi
2016-05-09 8:50 ` Christian Ruppert
2016-04-25 11:51 ` Jarkko Nikula
2016-04-25 15:04 ` Lucas De Marchi [this message]
2016-04-27 7:47 ` Jarkko Nikula
2016-04-08 12:17 ` Jarkko Nikula
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=571E320F.1020607@intel.com \
--to=lucas.demarchi@intel.com \
--cc=christian.ruppert@alitech.com \
--cc=jarkko.nikula@linux.intel.com \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mika.westerberg@linux.intel.com \
--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 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.