From: Jarkko Nikula <jarkko.nikula@linux.intel.com>
To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
Cc: Mika Westerberg <mika.westerberg@linux.intel.com>,
Jan Dabros <jsd@semihalf.com>,
linux-i2c@vger.kernel.org
Subject: Re: [PATCH] i2c: designware: add a new bit check for IC_CON control
Date: Tue, 17 Jan 2023 13:21:52 +0200 [thread overview]
Message-ID: <2e640cb9-476e-6d3c-97c8-5500f59eb5e3@linux.intel.com> (raw)
In-Reply-To: <Y8Z6n7HEXBQx6Nxg@smile.fi.intel.com>
On 1/17/23 12:38, Andy Shevchenko wrote:
> On Tue, Jan 17, 2023 at 04:01:21PM +0530, Shyam Sundar S K wrote:
>> Double checked with our HW and FW teams, and understand that (atleast in
>> AMD platform designs):
>>
>> 1. BIOS actually programs the BUS_CLEAR_FEATURE_CTRL and also enables
>> the detection of SCL/SDA stuck low.
>> 2. Whenever the stuck low is detected, the SMU FW shall do the bus
>> recovery procedure.
>>
>> Currently, the way in which the "master_cfg" is built in the driver it
>> overrides the BUS_CLEAR_FEATURE_CTRL advertised by BIOS and the SMU FW
>> cannot initiate the bus recovery if the stuck low is detected.
>>
>> Hence this proposed check should be sufficient enough.
>
> Maybe you should elaborate this in the commit message and/or the code.
>
Yes indeed. Makes obvious this is not dead code if somebody looks only
the code and specification.
It is also important in the future if somebody adds the same
functionality into driver that this AMD platform must be taken into
account in that code change. I.e. no two instances trying to do the same
recovery.
next prev parent reply other threads:[~2023-01-17 11:22 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-16 4:35 [PATCH] i2c: designware: add a new bit check for IC_CON control Shyam Sundar S K
2023-01-16 9:38 ` Jarkko Nikula
2023-01-17 10:31 ` Shyam Sundar S K
2023-01-17 10:38 ` Andy Shevchenko
2023-01-17 11:21 ` Jarkko Nikula [this message]
2023-01-17 11:39 ` Shyam Sundar S K
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=2e640cb9-476e-6d3c-97c8-5500f59eb5e3@linux.intel.com \
--to=jarkko.nikula@linux.intel.com \
--cc=Shyam-sundar.S-k@amd.com \
--cc=andriy.shevchenko@linux.intel.com \
--cc=jsd@semihalf.com \
--cc=linux-i2c@vger.kernel.org \
--cc=mika.westerberg@linux.intel.com \
/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