Re: [RFC PATCH v2 6/6] HACK: i2c: aspeed: Comment clock out and make reset optional

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 30 May 2023 22:59:50 +0300
Andy Shevchenko <andy.shevchenko@xxxxxxxxx> wrote:

> On Tue, May 30, 2023 at 5:59 PM Jonathan Cameron
> <Jonathan.Cameron@xxxxxxxxxx> 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



[Index of Archives]     [Linux IBM ACPI]     [Linux Power Management]     [Linux Kernel]     [Linux Laptop]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]
  Powered by Linux