mbox series

[v3,0/3] i3c dw,ast2600: Add a driver for the AST2600 i3c controller

Message ID 20230331091501.3800299-1-jk@codeconstruct.com.au (mailing list archive)
Headers show
Series i3c dw,ast2600: Add a driver for the AST2600 i3c controller | expand

Message

Jeremy Kerr March 31, 2023, 9:14 a.m. UTC
This series adds a new i3c controller driver, for the ASPEED AST2600 i3c
SoC peripheral. This device is very similar to the dw i3c controller, so
we implement this by adding a little platform abstraction to the dw
driver, and then a platform implementation for ast2600.

For those testing at home: there's a couple of prereqs for getting this
running: we need the ast2600 i3c clocks in their proper configuration,
as implemented in:

  https://lore.kernel.org/all/20230302005834.13171-1-jk@codeconstruct.com.au/

- this series has been merged to clk-next, but has not hit Linus'
upstream yet. The series will still build fine without this.

You'll also want the dts definitions for the i3c controller and
pincontrol setup on the ast2600 platform. I have changes for those in my
dev/i3c branch:

  https://github.com/CodeConstruct/linux/commits/dev/i3c

- and will send those once we have the driver accepted.

v3: expand the prereqs & background above, and implement some feedback
from review. Mainly: rather that using a platform_data pointer, assume
platforms will use an encapsulating struct for their platform-specific
data

v2: This is a rework from an earlier series that implemented this as
part of the dw driver; I have adopted Ben Dooks' suggestion to split
into a new driver + exported hooks from the dw base.

As always: comments, queries etc. are most welcome.

Cheers,


Jeremy

Jeremy Kerr (3):
  i3c: dw: Add infrastructure for platform-specific implementations
  dt-bindings: i3c: Add AST2600 i3c controller
  i3c: ast2600: Add AST2600 platform-specific driver

 .../bindings/i3c/aspeed,ast2600-i3c.yaml      |  72 ++++++++
 MAINTAINERS                                   |   6 +
 drivers/i3c/master/Kconfig                    |  14 ++
 drivers/i3c/master/Makefile                   |   1 +
 drivers/i3c/master/ast2600-i3c-master.c       | 168 ++++++++++++++++++
 drivers/i3c/master/dw-i3c-master.c            |  76 ++++----
 drivers/i3c/master/dw-i3c-master.h            |  54 ++++++
 7 files changed, 358 insertions(+), 33 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/i3c/aspeed,ast2600-i3c.yaml
 create mode 100644 drivers/i3c/master/ast2600-i3c-master.c
 create mode 100644 drivers/i3c/master/dw-i3c-master.h

Comments

Joel Stanley April 5, 2023, 1:52 a.m. UTC | #1
On Fri, 31 Mar 2023 at 09:15, Jeremy Kerr <jk@codeconstruct.com.au> wrote:
>
> This series adds a new i3c controller driver, for the ASPEED AST2600 i3c
> SoC peripheral. This device is very similar to the dw i3c controller, so
> we implement this by adding a little platform abstraction to the dw
> driver, and then a platform implementation for ast2600.

Reviewed-by: Joel Stanley <joel@jms.id.au>

I have also tested it in qemu.

>
> For those testing at home: there's a couple of prereqs for getting this
> running: we need the ast2600 i3c clocks in their proper configuration,
> as implemented in:
>
>   https://lore.kernel.org/all/20230302005834.13171-1-jk@codeconstruct.com.au/
>
> - this series has been merged to clk-next, but has not hit Linus'
> upstream yet. The series will still build fine without this.
>
> You'll also want the dts definitions for the i3c controller and
> pincontrol setup on the ast2600 platform. I have changes for those in my
> dev/i3c branch:
>
>   https://github.com/CodeConstruct/linux/commits/dev/i3c
>
> - and will send those once we have the driver accepted.

Given we have acks on the bindings, I think it's safe to send the
device tree changes now so we can merge what you have in the upcoming
merge window. If there's changes we can modify or revert.

Cheers,

Joel

>
> v3: expand the prereqs & background above, and implement some feedback
> from review. Mainly: rather that using a platform_data pointer, assume
> platforms will use an encapsulating struct for their platform-specific
> data
>
> v2: This is a rework from an earlier series that implemented this as
> part of the dw driver; I have adopted Ben Dooks' suggestion to split
> into a new driver + exported hooks from the dw base.
>
> As always: comments, queries etc. are most welcome.
>
> Cheers,
>
>
> Jeremy
>
> Jeremy Kerr (3):
>   i3c: dw: Add infrastructure for platform-specific implementations
>   dt-bindings: i3c: Add AST2600 i3c controller
>   i3c: ast2600: Add AST2600 platform-specific driver
>
>  .../bindings/i3c/aspeed,ast2600-i3c.yaml      |  72 ++++++++
>  MAINTAINERS                                   |   6 +
>  drivers/i3c/master/Kconfig                    |  14 ++
>  drivers/i3c/master/Makefile                   |   1 +
>  drivers/i3c/master/ast2600-i3c-master.c       | 168 ++++++++++++++++++
>  drivers/i3c/master/dw-i3c-master.c            |  76 ++++----
>  drivers/i3c/master/dw-i3c-master.h            |  54 ++++++
>  7 files changed, 358 insertions(+), 33 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/i3c/aspeed,ast2600-i3c.yaml
>  create mode 100644 drivers/i3c/master/ast2600-i3c-master.c
>  create mode 100644 drivers/i3c/master/dw-i3c-master.h
>
> --
> 2.39.1
>
Jeremy Kerr April 5, 2023, 4:34 a.m. UTC | #2
Hi Joel,

> Given we have acks on the bindings, I think it's safe to send the
> device tree changes now so we can merge what you have in the upcoming
> merge window. If there's changes we can modify or revert.

OK, I'll get those into shape.

There is one dependency on this though, and unfortunately it requires
solving *two* of the known-hard problems in computer science:

Do we start at i3c0 or i3c1?

[i3c1 would match the schematic...]

Cheers,


Jeremy
Joel Stanley April 5, 2023, 4:56 a.m. UTC | #3
On Wed, 5 Apr 2023 at 04:34, Jeremy Kerr <jk@codeconstruct.com.au> wrote:
>
> Hi Joel,
>
> > Given we have acks on the bindings, I think it's safe to send the
> > device tree changes now so we can merge what you have in the upcoming
> > merge window. If there's changes we can modify or revert.
>
> OK, I'll get those into shape.
>
> There is one dependency on this though, and unfortunately it requires
> solving *two* of the known-hard problems in computer science:
>
> Do we start at i3c0 or i3c1?

I'd vote for i3c0, like we do for ethernet, i2c, spi, etc.

It is annoying that aspeed chooses to start counting at 1, but at
least we would be consistent with other parts of the kernel.

Starting at 1 reminds me of doing matlab assignments at uni, so that's
another reason to avoid it.

>
> [i3c1 would match the schematic...]
>
> Cheers,
>
>
> Jeremy
Andrew Jeffery April 5, 2023, 5:15 a.m. UTC | #4
On Wed, 5 Apr 2023, at 14:26, Joel Stanley wrote:
> On Wed, 5 Apr 2023 at 04:34, Jeremy Kerr <jk@codeconstruct.com.au> wrote:
>>
>> Hi Joel,
>>
>> > Given we have acks on the bindings, I think it's safe to send the
>> > device tree changes now so we can merge what you have in the upcoming
>> > merge window. If there's changes we can modify or revert.
>>
>> OK, I'll get those into shape.
>>
>> There is one dependency on this though, and unfortunately it requires
>> solving *two* of the known-hard problems in computer science:
>>
>> Do we start at i3c0 or i3c1?
>
> I'd vote for i3c0, like we do for ethernet, i2c, spi, etc.
>
> It is annoying that aspeed chooses to start counting at 1, but at
> least we would be consistent with other parts of the kernel.
>
> Starting at 1 reminds me of doing matlab assignments at uni, so that's
> another reason to avoid it.

I've heard rumors that Aspeed will number their devices from zero in the future :)

Andrew