linux-kernel - Re: [RFC 0/2] drm/dsi: DSI for devices with different control bus

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20150819131300.GC15607@ulmo.nvidia.com>
Date:	Wed, 19 Aug 2015 15:13:02 +0200
From:	Thierry Reding <treding@...dia.com>
To:	Archit Taneja <architt@...eaurora.org>
CC:	<dri-devel@...ts.freedesktop.org>, <linux-arm-msm@...r.kernel.org>,
	<inki.dae@...sung.com>, <a.hajda@...sung.com>,
	<linux-kernel@...r.kernel.org>, <airlied@...ux.ie>,
	<daniel@...ll.ch>, <jani.nikula@...ux.intel.com>
Subject: Re: [RFC 0/2] drm/dsi: DSI for devices with different control bus

On Wed, Aug 19, 2015 at 10:37:54AM +0530, Archit Taneja wrote:
> Hi,
> 
> On 06/30/2015 10:54 AM, Archit Taneja wrote:
> >We are currently restricted when it comes to supporting DSI on devices
> >that have a non-DSI control bus. For example, DSI encoder chips are
> >available in the market that are configured via i2c. Configuring their
> >registers via DSI bus is either optional or not available at all.
> >
> >These devices still need to pass DSI parameters (data lanes, mode flags
> >etc) to the DSI host they are connected to. We don't have a way to do
> >that at the moment.
> >
> >The method presented in these patches is to provide an API to create a
> >'dummy' mipi_dsi_device. This device is populated with the desired DSI
> >params, which are passed on to the host via mipi_dsi_attach().
> >
> >This method will require the device driver to get a phandle to the DSI
> >host since there is no parent-child relation between the two.
> >
> >Is there a better way to do this? Please let me know!
> 
> Any comments on this?

Perhaps a better way would be to invert this relationship. According to
your proposal we'd have to have DT like this:

	i2c@... {
		...

		dsi-device@... {
			...
			dsi-bus = <&dsi>;
			...
		};

		...
	};

	dsi@... {
		...
	};

Inversing the relationship would become something like this:

	i2c@... {
		...
	};

	dsi@... {
		...

		peripheral@... {
			...
			i2c-bus = <&i2c>;
			...
		};

		...
	};

Both of those aren't fundamentally different, and they both have the
disavantage of lacking ways to transport configuration data that the
other bus needs to instantiate the dummy device (such as the reg
property for example, denoting the I2C slave address or the DSI VC).

So how about we create two devices in the device tree and fuse them at
the driver level:

	i2c@... {
		...

		i2cdsi: dsi-device@... {
			...
		};

		...
	};

	dsi@... {
		...

		peripheral@... {
			...
			control = <&i2cdsi>;
			...
		};

		...
	};

This way we'll get both an I2C device and a DSI device that we can fully
describe using the standard device tree bindings. At driver time we can
get the I2C device from the phandle in the control property of the DSI
device and use it to execute I2C transactions.

Thierry

Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)