[PATCH v3 0/4] Add support for new IMX8MP based board

Michal Vokáč posted 4 patches 2 months ago
There is a newer version of this series
.../devicetree/bindings/arm/fsl.yaml          |   1 +
.../bindings/usb/diodes,pi5usb30213a.yaml     |  88 +++
arch/arm64/boot/dts/freescale/Makefile        |   1 +
.../boot/dts/freescale/imx8mp-iota2-lumpy.dts | 517 ++++++++++++++++++
4 files changed, 607 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/diodes,pi5usb30213a.yaml
create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-iota2-lumpy.dts
[PATCH v3 0/4] Add support for new IMX8MP based board
Posted by Michal Vokáč 2 months ago
Hi,

this series adds support for a new member in our IOTA platform.
The board is based on the i.MX8MP SoC. The first two patches
add support for most of the board functionality except USB Type-C
port and some other minor things.

[PATCH 3] adds new device tree binding for a Diodes Incorporated
PI5USB30213A Type-C Controller and [PATCH 4] enables that port on
the IOTA2 Lumpy board.

We also wrote a driver for that Type-C port controller. I would like
to get that driver upstream as well but I expect it will take much
more iterations and effort to get it into mainline-ready shape so
I intentionally excluded it from this series. AFAIK it should not
be a problem to accept a device tree binding for a HW that does not
have a driver in the kernel yet.

Michal Vokáč (2):
  dt-bindings: arm: Add i.MX8MP IOTA2 Lumpy board
  arm64: dts: imx: Add imx8mp-iota2-lumpy board

Petr Benes (2):
  dt-bindings: usb: Add Diodes Incorporated PI5USB30213A Type-C
    Controller
  arm64: dts: imx8mp-iota2: Enable the USB Type-C port

 .../devicetree/bindings/arm/fsl.yaml          |   1 +
 .../bindings/usb/diodes,pi5usb30213a.yaml     |  88 +++
 arch/arm64/boot/dts/freescale/Makefile        |   1 +
 .../boot/dts/freescale/imx8mp-iota2-lumpy.dts | 517 ++++++++++++++++++
 4 files changed, 607 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/usb/diodes,pi5usb30213a.yaml
 create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-iota2-lumpy.dts

-- 
2.43.0

Re: [PATCH v3 0/4] Add support for new IMX8MP based board
Posted by Krzysztof Kozlowski 2 months ago
On Mon, Sep 23, 2024 at 05:14:13PM +0200, Michal Vokáč wrote:
> Hi,
> 
> this series adds support for a new member in our IOTA platform.
> The board is based on the i.MX8MP SoC. The first two patches
> add support for most of the board functionality except USB Type-C
> port and some other minor things.
> 
> [PATCH 3] adds new device tree binding for a Diodes Incorporated
> PI5USB30213A Type-C Controller and [PATCH 4] enables that port on
> the IOTA2 Lumpy board.
> 
> We also wrote a driver for that Type-C port controller. I would like
> to get that driver upstream as well but I expect it will take much
> more iterations and effort to get it into mainline-ready shape so
> I intentionally excluded it from this series. AFAIK it should not
> be a problem to accept a device tree binding for a HW that does not
> have a driver in the kernel yet.

It's unusual but okay. It will be however more difficult for you - any
changes in the binding in the future (when writing driver) will be
rejected on basis of breaking ABI, even if Linux does not use that ABI.

Best regards,
Krzysztof
Re: [PATCH v3 0/4] Add support for new IMX8MP based board
Posted by Michal Vokáč 2 months ago
On 24. 09. 24 10:22, Krzysztof Kozlowski wrote:
> On Mon, Sep 23, 2024 at 05:14:13PM +0200, Michal Vokáč wrote:
>> Hi,
>>
>> this series adds support for a new member in our IOTA platform.
>> The board is based on the i.MX8MP SoC. The first two patches
>> add support for most of the board functionality except USB Type-C
>> port and some other minor things.
>>
>> [PATCH 3] adds new device tree binding for a Diodes Incorporated
>> PI5USB30213A Type-C Controller and [PATCH 4] enables that port on
>> the IOTA2 Lumpy board.
>>
>> We also wrote a driver for that Type-C port controller. I would like
>> to get that driver upstream as well but I expect it will take much
>> more iterations and effort to get it into mainline-ready shape so
>> I intentionally excluded it from this series. AFAIK it should not
>> be a problem to accept a device tree binding for a HW that does not
>> have a driver in the kernel yet.
> 
> It's unusual but okay. It will be however more difficult for you - any
> changes in the binding in the future (when writing driver) will be
> rejected on basis of breaking ABI, even if Linux does not use that ABI.
OK, your argument is valid and I would be better on the safer side.
I will remove the binding for the Type-C controller from this series
and post it a bit later including the driver.

I will reduce this series to just add basic support for the board.
Can I keep your R-b tag for the Type-C dt-binding for the future
submission or should I better remove it?

Best regards,
Michal