From: Archit Taneja <architt@codeaurora.org>
To: Rob Herring <robh@kernel.org>,
Thierry Reding <treding@nvidia.com>,
Mark Rutland <mark.rutland@arm.com>,
Rob Herring <robh+dt@kernel.org>
Cc: Andrzej Hajda <a.hajda@samsung.com>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org,
dri-devel@lists.freedesktop.org,
Lucas Stach <l.stach@pengutronix.de>
Subject: Re: [RFC 0/2] drm/dsi: DSI for devices with different control bus
Date: Thu, 17 Sep 2015 14:26:18 +0530 [thread overview]
Message-ID: <55FA8032.50101@codeaurora.org> (raw)
In-Reply-To: <55F83CB1.5070102@kernel.org>
On 9/15/2015 9:13 PM, Rob Herring wrote:
> On 09/15/2015 05:32 AM, Archit Taneja wrote:
>> Hi Rob, Mark,
>>
>> We've been trying to figure out the right way to represent a class
>> of display encoder devices in DT.
>
> I've been meaning to reply on this.
>
>> These devices have registers that are generally configured via i2c. Once
>> the device is configured, it takes in video data from the mipi
>> dsi bus.
>>
>> Until now, all the devices we've supported devices that can be are
>> configured by the dsi bus itself, and hence, we've been able to
>> represent them in DT as children under the dsi host.
>>
>> For the above class of devices (using both i2c and dsi), we aren't
>> able to conclude upon what's the better approach among the two:
>>
>> 1. Represent the device via 2 different nodes in DT. One would be
>> a child under an i2c adapter, the other a child of a dsi host. We
>> would have two device drivers, one i2c client, and the other a
>> mipi dsi device.
>>
>> 2. Represent the device as an i2c client in DT. Provide an api
>> to create "dummy" dsi devices. The i2c client driver would use
>> this api to register a dsi device, and link itself with the dsi
>> host.
>>
>> What do you think would be the way to go here? I guess you
>> might have faced something similar in other subsystems.
>
> The closest thing I can think of are WiFi/BT combo chips that use
> SDIO+UART. In that case, 2 nodes makes sense as these chips are
> essentially 2 independent functions in a single chip and both interfaces
> are control interfaces (as well as data). This case is a bit different
> with both interfaces being tied to the same function.
>
> So in this case, I think option 2 is the right way for the reasons
> already outlined in this thread. I think there needs to be more
> consistency in how the of-graph connections are defined with the core
> doing more of the graph traversing. So having an i2c device plus
> of-graph seems more consistent with other non-DSI cases.
>
> The main open issue seemed to be setting the VC. At least for the
> ADV7533, it can be whatever you want it to be. The host and device just
> need to agree. I see no need for that to be in DT at least in this case.
> But then I'm not sure what are typical constraints for VC assignment.
> I'd guess that constraints are on the device side and hosts can support
> whatever the device wants. If so, then it can purely be up to the driver
> to set.
2 DSI devices connected to the same host shouldn't have the same VC.
When representing the DSI nodes via DT, we use the 'reg' property to
assign the VC.
Although, in practice, we don't generally have multiple devices
on the same bus. The trend is to have multiple DSI hosts on the
platform to support more devices.
If we have checks that ensures the DT way and the new manual way
of creation of DSI devices doesn't result in having conflicting VCs
for devices, we should be okay.
>
> Implementation-wise, I don't think that I'd call this a dummy device.
> There are multiple ways for devices to get created in the driver model.
> DT is just one way. You are just creating the device in a different way
> outside of DT which is fine.
>
Thanks for the feedback.
Archit
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
next prev parent reply other threads:[~2015-09-17 8:56 UTC|newest]
Thread overview: 84+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-30 5:24 [RFC 0/2] drm/dsi: DSI for devices with different control bus Archit Taneja
2015-06-30 5:24 ` [RFC 1/2] drm/dsi: Create dummy DSI devices Archit Taneja
2015-08-19 8:10 ` Andrzej Hajda
2015-08-19 9:30 ` Archit Taneja
2015-06-30 5:24 ` [RFC 2/2] drm/dsi: Get DSI host by DT device node Archit Taneja
2015-08-19 8:46 ` Andrzej Hajda
2015-08-19 5:07 ` [RFC 0/2] drm/dsi: DSI for devices with different control bus Archit Taneja
2015-08-19 13:13 ` Thierry Reding
2015-08-19 14:17 ` Lucas Stach
2015-08-19 14:34 ` Thierry Reding
2015-08-19 14:52 ` Lucas Stach
2015-08-19 15:02 ` Thierry Reding
2015-08-19 15:39 ` Jani Nikula
2015-08-20 4:16 ` Archit Taneja
2015-08-20 11:48 ` Thierry Reding
2015-08-21 6:09 ` Archit Taneja
2015-09-07 11:46 ` Archit Taneja
2015-09-08 10:27 ` Andrzej Hajda
2015-09-10 6:15 ` Archit Taneja
2015-09-10 7:32 ` Thierry Reding
2015-09-15 10:32 ` Archit Taneja
2015-09-15 15:43 ` Rob Herring
2015-09-17 8:56 ` Archit Taneja [this message]
2015-09-15 10:41 ` Archit Taneja
2015-10-06 9:24 ` [RFC v2 0/5] " Archit Taneja
2015-10-06 9:24 ` [RFC v2 1/5] drm/dsi: Refactor device creation Archit Taneja
2015-10-30 11:28 ` Andrzej Hajda
2015-10-06 9:24 ` [RFC v2 2/5] drm/dsi: Try to match non-DT dsi devices Archit Taneja
2015-10-30 12:42 ` Andrzej Hajda
2015-11-02 5:26 ` Archit Taneja
2015-10-06 9:24 ` [RFC v2 3/5] drm/dsi: Check for used channels Archit Taneja
2015-10-30 12:52 ` Andrzej Hajda
2015-11-02 5:28 ` Archit Taneja
2015-10-06 9:24 ` [RFC v2 4/5] drm/dsi: Add routine to unregister dsi device Archit Taneja
2015-10-30 14:21 ` Andrzej Hajda
2015-11-02 6:28 ` Archit Taneja
2015-11-02 10:42 ` Andrzej Hajda
2015-11-03 7:18 ` Archit Taneja
2015-10-06 9:24 ` [RFC v2 5/5] drm/dsi: Get DSI host by DT device node Archit Taneja
2015-10-06 10:00 ` kbuild test robot
2015-11-02 10:50 ` Andrzej Hajda
2015-11-03 7:20 ` Archit Taneja
2015-11-30 12:01 ` [PATCH v3 0/5] drm/dsi: DSI for devices with different control bus Archit Taneja
2015-11-30 12:01 ` [PATCH v3 1/5] drm/dsi: Refactor device creation Archit Taneja
2015-11-30 12:01 ` [PATCH v3 2/5] drm/dsi: Try to match non-DT dsi devices Archit Taneja
2015-11-30 12:45 ` kbuild test robot
2015-12-07 5:29 ` Archit Taneja
2015-12-07 8:45 ` Jani Nikula
2015-12-07 8:59 ` Archit Taneja
2015-12-07 9:10 ` Jani Nikula
2015-12-07 9:18 ` Archit Taneja
2015-12-07 10:07 ` Jani Nikula
2015-12-07 16:55 ` Rob Clark
2015-11-30 12:01 ` [PATCH v3 3/5] drm/dsi: Check for used channels Archit Taneja
2015-11-30 12:01 ` [PATCH v3 4/5] drm/dsi: Add routine to unregister dsi device Archit Taneja
2015-11-30 12:34 ` Andrzej Hajda
2015-11-30 12:01 ` [PATCH v3 5/5] drm/dsi: Get DSI host by DT device node Archit Taneja
2015-12-10 12:41 ` [PATCH v4 0/6] drm/dsi: DSI for devices with different control bus Archit Taneja
2015-12-10 12:41 ` [PATCH v4 1/6] drm/dsi: check for CONFIG_OF when defining of_mipi_dsi_device_add Archit Taneja
2016-01-21 15:31 ` Thierry Reding
2016-01-26 14:59 ` Archit Taneja
2015-12-10 12:41 ` [PATCH v4 2/6] drm/dsi: Refactor device creation Archit Taneja
2016-01-21 15:46 ` Thierry Reding
2016-01-26 17:05 ` Archit Taneja
2015-12-10 12:41 ` [PATCH v4 3/6] drm/dsi: Try to match non-DT dsi devices Archit Taneja
2016-01-21 16:05 ` Thierry Reding
2016-01-26 18:04 ` Archit Taneja
2015-12-10 12:41 ` [PATCH v4 4/6] drm/dsi: Check for used channels Archit Taneja
2016-01-21 16:11 ` Thierry Reding
2016-01-27 5:16 ` Archit Taneja
2015-12-10 12:41 ` [PATCH v4 5/6] drm/dsi: Add routine to unregister dsi device Archit Taneja
2016-01-21 16:12 ` Thierry Reding
2016-01-27 5:20 ` Archit Taneja
2015-12-10 12:41 ` [PATCH v4 6/6] drm/dsi: Get DSI host by DT device node Archit Taneja
2016-01-21 16:16 ` Thierry Reding
2016-01-27 5:21 ` Archit Taneja
2016-01-05 5:29 ` [PATCH v4 0/6] drm/dsi: DSI for devices with different control bus Archit Taneja
2016-02-12 9:18 ` [PATCH v5 0/5] " Archit Taneja
2016-02-12 9:18 ` [PATCH v5 1/5] drm/dsi: check for CONFIG_OF when defining of_mipi_dsi_device_add Archit Taneja
2016-02-12 9:18 ` [PATCH v5 2/5] drm/dsi: Use mipi_dsi_device_register_full for DSI device creation Archit Taneja
2016-02-12 9:18 ` [PATCH v5 3/5] drm/dsi: Try to match non-DT DSI devices Archit Taneja
2016-02-12 9:18 ` [PATCH v5 4/5] drm/dsi: Add routine to unregister a DSI device Archit Taneja
2016-02-12 9:18 ` [PATCH v5 5/5] drm/dsi: Get DSI host by DT device node Archit Taneja
2016-03-02 16:05 ` [PATCH v5 0/5] drm/dsi: DSI for devices with different control bus Thierry Reding
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55FA8032.50101@codeaurora.org \
--to=architt@codeaurora.org \
--cc=a.hajda@samsung.com \
--cc=devicetree@vger.kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=l.stach@pengutronix.de \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=robh+dt@kernel.org \
--cc=robh@kernel.org \
--cc=treding@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).