[RFC] SAMA7D65 SoC I3C controller driver

[RFC] SAMA7D65 SoC I3C controller driver

[Durai.ManickamKR]

Hi All,

We have an I3C controller in SAMA7D65 SoC based on ARM-Cortex A7. I am 
trying to add driver support for I3C controller which is based on 
mipi-hci spec 1.0 version of synopsys IP.  Supported driver for this IP 
is drivers/i3c/master/mipi-i3c-hci/core.c. We are using LSM6DSO IMU 
sensor as I3C slave device for verifying the common command codes (CCC) 
and I3C messages. Enabled the following configs in the kernel and added 
the I3C controller & I3C slave node in the device tree. With this kernel 
image, we are able successfully probe the mipi-i3c-hci driver. The host 
& slave controller devices are created as 0-208006c100b/ & 
e9000000.i3c/. So I hope RSTDAA, DISEC, DAA and configuring the I3C 
slave device by the I3C host controller is fine.

Kernel config:
CONFIG_I3C=y
CONFIG_MIPI_I3C_HCI=y

Device tree:
compatible = "mipi-i3c-hci";

Though we used synopsys IP,  we don't have support for DMA and few other 
register configurations like lets say setting endianess, setting command 
version and so on. So, I have to remove and modify these in the existing 
driver to make it work for our SoC. So, what i did was, i have created a 
copy of core.c file and included all the related dependent functions 
used in other files (pio.c, cmd_v1.c, dat_v1.c etc) in the same file. 
Created as a separate platform driver to support the i3c controller  in 
the path drivers/i3c/master/mchp-i3c-master.c.

So my query here are,

 1.
    Whether this approach is correct or not.
 2.
    Instead of creating a new driver file, shall we introduce a quirck
    for Microchip I3C and integrate the changes in the existing driver.

Please suggest us the best way to provide support for the SAMA7D65 I3C 
in kernel.


-- 
linux-i3c mailing list
linux-i3c@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-i3c

[RFC] SAMA7D65 SoC I3C controller driver

[Durai.ManickamKR]

Hi All,

We have an I3C controller in SAMA7D65 SoC based on ARM-Cortex A7. I am 
trying to add driver support for I3C controller which is based on 
mipi-hci spec 1.0 version of synopsys IP.  Supported driver for this IP 
is drivers/i3c/master/mipi-i3c-hci/core.c. We are using LSM6DSO IMU 
sensor as I3C slave device for verifying the common command codes (CCC) 
and I3C messages. Enabled the following configs in the kernel and added 
the I3C controller & I3C slave node in the device tree. With this kernel 
image, we are able successfully probe the mipi-i3c-hci driver. The host 
& slave controller devices are created as 0-208006c100b/ & 
e9000000.i3c/. So I hope RSTDAA, DISEC, DAA and configuring the I3C 
slave device by the I3C host controller is fine.

Kernel config:
CONFIG_I3C=y
CONFIG_MIPI_I3C_HCI=y

Device tree:
compatible = "mipi-i3c-hci";

Though we used synopsys IP,  we don't have support for DMA and few other 
register configurations like lets say setting endianess, setting command 
version and so on. So, I have to remove and modify these in the existing 
driver to make it work for our SoC. So, what i did was, i have created a 
copy of core.c file and included all the related dependent functions 
used in other files (pio.c, cmd_v1.c, dat_v1.c etc) in the same file. 
Created as a separate platform driver to support the i3c controller  in 
the path drivers/i3c/master/mchp-i3c-master.c.

So my query here are,

1.
    Whether this approach is correct or not.
2.
    Instead of creating a new driver file, shall we introduce a quirck
    for Microchip I3C and integrate the changes in the existing driver.

Please suggest us the best way to provide support for the SAMA7D65 I3C 
in kernel.

-- 
linux-i3c mailing list
linux-i3c@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-i3c

Re: [RFC] SAMA7D65 SoC I3C controller driver

[Wolfram Sang]

Hi,

> So my query here are,
> 
> 1.
>     Whether this approach is correct or not.
> 2.
>     Instead of creating a new driver file, shall we introduce a quirck
>     for Microchip I3C and integrate the changes in the existing driver.

It depends, I would say. I would start with approach 2), but maybe not
call it 'quirks' but 'config'. If the code stays readable while working
on that, it probably is worth it to follow that road. If you are adding
so much code handling the differences that the result is hardly readable
anymore, then approach 1) might be the better one in the end. I don't
know your hardware, so I can't guess. But you might already have a gut
feeling which is better.

This is how it is handled in most subsystems I work with. Note that
Frank and Alexandre have the ultimate call here.

Happy hacking,

   Wolfram


-- 
linux-i3c mailing list
linux-i3c@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-i3c