From: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
To: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: <linux-i2c@vger.kernel.org>, Wolfram Sang <wsa@kernel.org>,
Niyas Sait <niyas.sait@linaro.org>,
Klaus Jensen <its@irrelevant.dk>,
Andy Shevchenko <andy@kernel.org>, <linux-acpi@vger.kernel.org>,
Jeremy Kerr <jk@codeconstruct.com.au>,
Matt Johnston <matt@codeconstruct.com.au>,
Shesha Bhushan Sreenivasamurthy <sheshas@marvell.com>,
<linux-cxl@vger.kernel.org>, <linuxarm@huawei.com>,
"Viacheslav A . Dubeyko" <viacheslav.dubeyko@bytedance.com>
Subject: Re: [RFC PATCH v2 6/6] HACK: i2c: aspeed: Comment clock out and make reset optional
Date: Wed, 31 May 2023 10:32:50 +0100 [thread overview]
Message-ID: <20230531103250.00006911@Huawei.com> (raw)
In-Reply-To: <CAHp75VcaE2-9ZKgmcZXaA668mLZ8XETcUuUdt2asF4aEzx97gg@mail.gmail.com>
On Tue, 30 May 2023 22:59:50 +0300
Andy Shevchenko <andy.shevchenko@gmail.com> wrote:
> On Tue, May 30, 2023 at 5:59 PM Jonathan Cameron
> <Jonathan.Cameron@huawei.com> wrote:
> >
> > Needs tidying up - hopefully can do clock right using ongoing
> > work from Niyas
> > https://linaro.atlassian.net/wiki/spaces/CLIENTPC/pages/28832333867/ACPI+Clock+Management
>
> I'm wondering how this will be solved for the cases where the
> "clock-frequency" property is used, see below.
>
> > ACPI does not provide an equivalent reset deassert / assert. _RST
> > doesn't fit that model, so for now make the reset optional.
>
> ...
>
> > - Left the clock with the hideous hack to keep it obvious that it is
> > a hack given no way for us to get the clk rate on ACPI firmware yet
> > and I don't want to pretend there is.
>
> The workaround in some cases is to read the "clock-frequency"
> property, which is standard de facto in several drivers / subsystems.
That's the wrong clock frequency. I believe that property is the i2c bus clock
frequency Documentation/devicetree/bindings/i2c/i2c.txt
The one being used here is the input clock. I'd imagine there is some division
done, but probably doesn't make sense to represent that using the clock framework
as the i2c bus clock signal isn't directly derived from the input clock
(pulse stretching and all sorts of other fun in I2C). Also massive overkill
given no one else can use this clock.
>
> That said, why not split this patch into two and switch the clock to
> be optional and use the above property? Okay, one thing is that this
> can collide probably with the generic I2C bus timings, which this
> driver uses with a non-standard property name.
>
I'd rather provide the clock from ACPI using Niyas' stuff when ready -
it looks like a promising general solution so don't want to put an
partial solution in before that.
I kept these two changes in the last patch as I suspect they are the
ones that can be considered a hack, given we don't actually have a
real platform using ACPI with this device. Anyone on aspeed know if
anyone cares about ACPI on those BMCs?
Jonathan
prev parent reply other threads:[~2023-05-31 9:33 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-30 14:55 [RFC PATCH v2 0/6] i2c: Enabling use of aspeed-i2c with ACPI Jonathan Cameron
2023-05-30 14:55 ` [RFC PATCH v2 1/6] i2c: acpi: set slave mode flag Jonathan Cameron
2023-05-30 14:55 ` [RFC PATCH v2 2/6] i2c: aspeed: Use platform_get_irq() instead of opencoding Jonathan Cameron
2023-05-30 19:45 ` Andy Shevchenko
2023-05-31 9:36 ` Jonathan Cameron
2023-05-30 14:55 ` [RFC PATCH v2 3/6] i2c: aspeed: Don't report error when optional dt bus-frequency not supplied Jonathan Cameron
2023-05-30 19:47 ` Andy Shevchenko
2023-05-30 14:55 ` [RFC PATCH v2 4/6] i2c: aspeed: switch to generic fw properties Jonathan Cameron
2023-05-30 19:50 ` Andy Shevchenko
2023-05-31 10:46 ` Jonathan Cameron
2023-05-30 14:56 ` [RFC PATCH v2 5/6] i2c: aspeed: Set the fwnode for the adap->dev Jonathan Cameron
2023-05-30 19:51 ` Andy Shevchenko
2023-05-30 14:56 ` [RFC PATCH v2 6/6] HACK: i2c: aspeed: Comment clock out and make reset optional Jonathan Cameron
2023-05-30 19:59 ` Andy Shevchenko
2023-05-31 9:32 ` Jonathan Cameron [this message]
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=20230531103250.00006911@Huawei.com \
--to=jonathan.cameron@huawei.com \
--cc=andy.shevchenko@gmail.com \
--cc=andy@kernel.org \
--cc=its@irrelevant.dk \
--cc=jk@codeconstruct.com.au \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-cxl@vger.kernel.org \
--cc=linux-i2c@vger.kernel.org \
--cc=linuxarm@huawei.com \
--cc=matt@codeconstruct.com.au \
--cc=niyas.sait@linaro.org \
--cc=sheshas@marvell.com \
--cc=viacheslav.dubeyko@bytedance.com \
--cc=wsa@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox