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
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
