mbox series

[0/2] i2c: at91: Add support for programmable clock source

Message ID 20211012140718.2138278-1-horatiu.vultur@microchip.com
Headers show
Series i2c: at91: Add support for programmable clock source | expand

Message

Horatiu Vultur Oct. 12, 2021, 2:07 p.m. UTC
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(-)

Comments

Codrin Ciubotariu Oct. 13, 2021, 8:49 a.m. UTC | #1
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
Horatiu Vultur Oct. 13, 2021, 11:41 a.m. UTC | #2
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
Codrin Ciubotariu Oct. 13, 2021, 1:10 p.m. UTC | #3
> 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
Wolfram Sang Nov. 5, 2021, 9:47 p.m. UTC | #4
> 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?
Codrin Ciubotariu Nov. 8, 2021, 8:35 a.m. UTC | #5
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
Horatiu Vultur Nov. 8, 2021, 9:29 a.m. UTC | #6
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
Wolfram Sang Nov. 29, 2021, 10:06 a.m. UTC | #7
> > > 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.