| Message ID | 20211012140718.2138278-1-horatiu.vultur@microchip.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | i2c: at91: Add support for programmable clock source | expand |
On 12.10.2021 17:07, Horatiu Vultur wrote: > Add support to be able to set BRSRCCLK. This feature is support on lan966x > > Horatiu Vultur (2): > dt-bindings: i2c: at91: Extend compatible list for lan966x > i2c: at91: add support for brsrcclk > > .../devicetree/bindings/i2c/i2c-at91.txt | 6 +++-- > drivers/i2c/busses/i2c-at91-core.c | 16 +++++++++++++ > drivers/i2c/busses/i2c-at91-master.c | 23 +++++++++++++++++-- > drivers/i2c/busses/i2c-at91.h | 1 + > 4 files changed, 42 insertions(+), 4 deletions(-) > Hi Horatiu, From what I understand, on your DTS, you replaced the peripheral clock with the GCLK in the I2C node. This means that you are forcing all the variants that support clk_brsrcclk to treat the current clock as GCLK. This is not necessarily correct, since this newer variants can also work fine with only the peripheral clock and we should keep these option available. I would add an optional GCLK clock binding in the I2C node. This way GCLK will be used only if it is present in DT and clk_brsrcclk set. Best regards, Codrin
The 10/13/2021 08:49, Codrin Ciubotariu - M19940 wrote: > On 12.10.2021 17:07, Horatiu Vultur wrote: > > Add support to be able to set BRSRCCLK. This feature is support on lan966x > > > > Horatiu Vultur (2): > > dt-bindings: i2c: at91: Extend compatible list for lan966x > > i2c: at91: add support for brsrcclk > > > > .../devicetree/bindings/i2c/i2c-at91.txt | 6 +++-- > > drivers/i2c/busses/i2c-at91-core.c | 16 +++++++++++++ > > drivers/i2c/busses/i2c-at91-master.c | 23 +++++++++++++++++-- > > drivers/i2c/busses/i2c-at91.h | 1 + > > 4 files changed, 42 insertions(+), 4 deletions(-) > > > > Hi Horatiu, Hi Codrin, > > From what I understand, on your DTS, you replaced the peripheral clock > with the GCLK in the I2C node. This means that you are forcing all the > variants that support clk_brsrcclk to treat the current clock as GCLK. > This is not necessarily correct, since this newer variants can also work > fine with only the peripheral clock and we should keep these option > available. > > I would add an optional GCLK clock binding in the I2C node. This way > GCLK will be used only if it is present in DT and clk_brsrcclk set. Thanks for the explanation. I think actually I will drop this patch series because apparently lan966x works fine also with the peripheral clock. So then no changes are required. If you think is worth it, I can do another version with the proposed changes. > > Best regards, > Codrin
> I think actually I will drop this patch series because apparently > lan966x works fine also with the peripheral clock. So then no changes > are required. > > If you think is worth it, I can do another version with the proposed > changes. Probably not until we have an implemented good reason to use GCLK. Best regards, Codrin
> I think actually I will drop this patch series because apparently > lan966x works fine also with the peripheral clock. So then no changes > are required. Not even patch 1/2?
On 05.11.2021 23:47, Wolfram Sang wrote: > >> I think actually I will drop this patch series because apparently >> lan966x works fine also with the peripheral clock. So then no changes >> are required. > > Not even patch 1/2? > we can keep the new compatible, but patch 2/2 needs to be split. Best regards, Codrin
The 11/08/2021 08:35, Codrin Ciubotariu - M19940 wrote: > On 05.11.2021 23:47, Wolfram Sang wrote: > > > >> I think actually I will drop this patch series because apparently > >> lan966x works fine also with the peripheral clock. So then no changes > >> are required. > > > > Not even patch 1/2? > > > > we can keep the new compatible, but patch 2/2 needs to be split. For me it is OK to use the compatible string 'microchip,sam9x60-i2c' > > Best regards, > Codrin
> > > Not even patch 1/2? > > > > we can keep the new compatible, but patch 2/2 needs to be split. > > For me it is OK to use the compatible string 'microchip,sam9x60-i2c' I'll drop this patch for now. If anyone is still interested in it, please resend.