[RFC v2 0/5] drm/dsi: DSI for devices with different control bus

[Archit Taneja]

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.

After some discussions on the previous RFC[1], we decided to support this
by providing additional API in drm_mipi_dsi which lets us create new DSI
devices without the need of them to have a DT node.

There are a couple of concerns I have about this patchset which I
couldn't figure out a solution to (they are addressed in the individual
patches too):

- Matching of non-DT devices: buses like i2c/spi populate id_table in
  their drivers to perform a match for the non-DT case. Is this something
  that we should do too?

- Race between host_unregister and device_unregister: The new API provides
  peripheral drivers to unregister the DSI devices they created by using
  mipi_dsi_device_unregister. If the dsi host unregisters first, the
  peripheral driver might have an unregistered device pointer without
  being aware of it.

Some comments on these would help.

[1]: https://lkml.org/lkml/2015/6/30/42

Archit Taneja (5):
  drm/dsi: Refactor device creation
  drm/dsi: Try to match non-DT dsi devices
  drm/dsi: Check for used channels
  drm/dsi: Add routine to unregister dsi device
  drm/dsi: Get DSI host by DT device node

 drivers/gpu/drm/drm_mipi_dsi.c | 135 ++++++++++++++++++++++++++++++++---------
 include/drm/drm_mipi_dsi.h     |  27 +++++++++
 2 files changed, 132 insertions(+), 30 deletions(-)

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/