Re: [RFC 0/3] Portable Device Tree Connector

From: Kieran Bingham <kieran.bingham@ideasonboard.com>
To: Pantelis Antoniou <pantelis.antoniou@konsulko.com>,
	Rob Herring <robherring2@gmail.com>
Cc: Frank Rowand <frowand.list@gmail.com>,
	Matt Porter <mporter@konsulko.com>,
	Koen Kooi <koen@dominion.thruhere.net>,
	Guenter Roeck <linux@roeck-us.net>, Marek Vasut <marex@denx.de>,
	Wolfram Sang <wsa@the-dreams.de>,
	Stephen Boyd <stephen.boyd@linaro.org>,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-i2c@vger.kernel.org,
	Pantelis Antoniou <pantelis.antoniou@konsulko.com>,
	Pantelis Antoniou <panto@antoniou-consulting.com>
Subject: Re: [RFC 0/3] Portable Device Tree Connector
Date: Fri, 01 Dec 2023 12:19:14 +0000	[thread overview]
Message-ID: <170143315452.2829918.3199477991260309208@ping.linuxembedded.co.uk> (raw)
In-Reply-To: <1464986273-12039-1-git-send-email-pantelis.antoniou@konsulko.com>

Hi Pantelis,

Digging out a thread from 2016!

Quoting Pantelis Antoniou (2016-06-03 21:37:50)
> This patchset introduces a portable device tree based connector.
> It allows definition of a connector in a portable format so that
> hardware expansion boards that utilize it can use the same
> DT hardware definitions unchanged for all the boards that
> have the same kind of connector.
> 
> It completely abstracts away the baseboard implementation details
> and allows one to describe the expansion board in it's isolated
> domain without having to figure out the per-board specific
> hardware configuration.
> 
> The first patchset is the implementation while the next two
> define a connector for the beaglebone board.
> 
> There was a session at ELC2016 with the slides at
> http://elinux.org/images/d/d0/Panto.pdf
> 
> This patchset is dependent on the previous two patchset I sent out
> some time ago.
> 
> "of: dynamic: Changesets helpers & fixes"
> "gpio: of: Support cascaded GPIO"

Did you go anywhere with this since 2016?

As you perhaps saw on the other thread - we're starting to hit an
explosion of combinatorial arangements of cameras that can be connected
to and supported on different platforms, thanks in part due to the
non-standardised but maybe defacto camera standard port cable on RPi (in
two variations, 15pin with 2 lanes, and 22 pin with 4 data lanes).

I'm wondering how we can build upon or resume this work with DT
connectors to support expressing camera modules independently from the
platform they connect to.

The port/connector usually expects an i2c bus, a gpio to enable power
regulators on the module and perhaps one additional optional gpio, and
then the clock and data lanes for the MIPI port link.

Any thoughts welcome - and if there was any newer work to build upon or
resurrect I'd be happy to help test, or find time to start looking at
how we could build this.

Or of course if there was any reason this work was abandoned (not
feasible, not acceptable) I'd be keen to hear this before diving in!

Thanks and Regards

Kieran

> Pantelis Antoniou (3):
>   of: Portable Device Tree connector
>   dts: Beaglebone portable connector definitions
>   dts: beaglebone: Portable connector BB_RELAY_4PORT definition
> 
>  arch/arm/boot/dts/am335x-bone-common.dtsi | 1678 +++++++++++++++++++++++++++++
>  drivers/extcon/Kconfig                    |   20 +
>  drivers/extcon/Makefile                   |    3 +
>  drivers/extcon/extcon-dt-con-gpio.c       |  337 ++++++
>  drivers/extcon/extcon-dt-con-proxy.c      |  480 +++++++++
>  drivers/extcon/extcon-dt-con.c            |  491 +++++++++
>  drivers/extcon/extcon-dt-con.h            |   93 ++
>  7 files changed, 3102 insertions(+)
>  create mode 100644 drivers/extcon/extcon-dt-con-gpio.c
>  create mode 100644 drivers/extcon/extcon-dt-con-proxy.c
>  create mode 100644 drivers/extcon/extcon-dt-con.c
>  create mode 100644 drivers/extcon/extcon-dt-con.h
> 
> -- 
> 1.7.12