video: tegra: host: use platform bus/driver/device

- this commit replaces the custom nvhost bus/driver/device
with platform bus/driver/device
- this is in preparation to add DT support
- following is the list of notable changes done:

1. chip_ops: The per SoC differences is encapsulated by chip_ops structure.
With nvhost_bus:
- It is hidden in nvhost_bus and exposed APIs to rest of the code.
These APIs land up in correct implementation for current SoC.
With platform_bus:
- I had to make this global and adjust the API accordingly.

2. nvhost_device
With nvhost_bus:
- The struct nvhost_device encapsulates both Linux device driver parts
as well as tegra specific parts.
With platform_bus:
- I had to move the current nvhost_device as a platform_data
for each platform_device. For this I renamed the struct nvhost_device
to struct nvhost_device_data.
- Also, since nvhost_driver is gone, I had to move all the
function pointers in it to struct nvhost_device_data.

3. Device specific private data: Host1x master device has its own
static data (called nvhost_master) which stores the per SoC
sync-point, IRQ info etc.
With nvhost_bus:
- This was stored as device specific platform_data.
With platform_bus:
- The device specific platform_data is now struct nvhost_device_data
(as mentioned above).
- I need to keep it common for all the devices whose code is
part of host1x directory, so that other parts of code that need per-device
info have a unique interface of platform_get_drvdata.
- As a result, I had to add a void * field in struct nvhost_device_data
which now holds per-device specific data and expose APIs to get/set this data.
- As of now, only host1x master parent device code uses this.

4. Per SoC device names:
With nvhost_bus:
- Per SoC device name is SAME for all the SoCs.
- The correct driver get linked to this device via the concept of id_table.
This id_table allows us to connect multiple devices to single driver code
and pass appropriate function pointer specific to SoC (you can check gr3d.c for details).
With platform_bus:
- The id_table usage of platform_bus is different from above.
- To adhere to its need, I had to append the per-SoC device name
with a version field (so gr3d for t20 became gr3d01, for t30 became gr3d02 etc).
- I adjusted the correct names in _probe of such devices.
Also, I adjusted the node names exposed to user space (/dev/host-gr3d etc)
to be consistent across SoCs.
- But this fails for the sysfs entries created by device registration code
of Linux, since during this time the _probe is not called.
So, device name is still appended with version field.

5. Per SoC device registration function: tegraXXX_register_host1x_devices
is the per SoC specific APIs which is called by board-file to register
the host1x and client devices. Host1x has strict requirements for the
parent->child relations i.e. any client of host1x device should have the
parent set properly BEFORE device registration.
With nvhost_bus:
- Setting of parent was taken care by nvhost_device_register call and other helpers.
With platform_bus:
- It is not possible to change parent till _probe of client device returns
(meaning not much of control in our hand). The device driver core,
takes a mutex lock of parent BEFORE calling _probe to avoid changing parent during _probe.
- So, to set correct parent, I changed the return type of
tegraXXX_register_host1x_devices to return pointer to master host1x parent device.

6. platform_get_drvdata calls:
With nvhost_bus:
- Only host1x master parent calls this.
With platform_bus:
- Almost all the common code ends up calling this.
Fortunately, we had designed the APIs such that they take nvhost_device * as argument.
So changing them to platform_device * is in a way easy.

7. Device list: The debug-fs dump code & module-reg-read-write
functionality rely on having a list of host1x devices registered currently.
With nvhost_bus:
- This is readily available since struct bus_type of Linux holds this list.
Moreover, it provides an iterators to access this list.
With platform_bus:
- Since it holds large number of devices in system, it is inefficient
to use the above iterators. Also, it is difficult to have a common matching
criteria for all the devices who have different platform_data.
- As a result, I had to add a simple list using Linux kernel's list implementation.
It holds the list of devices which have their code within host1x directory
and actually use channels (remember tegra-dc and nvavp are outside
host1x code && do not use physical channels they only need sync-point
and host1x hardware alive when they are alive).
I also had to provide 2 iterators one which is used for
module-reg-read-write and other for debug-fs dump.

8. I changed how tegra-dc and nvavp called the host1x externally exposed APIs
(such APIs end with _ext). In current code, they know little too much of
host1x code internals. I now changed to make them independent of host1x internal
implementation and structure know-how. They now simply send their own
platform_device * to the external visible APIs and these APIs
ensures that the call ends up in correct function call.

bug 1041377

Change-Id: I9cd4d506e6f3bde805923ce7c7bbbd37c9ec13c4
Signed-off-by: Mayuresh Kulkarni <mkulkarni@nvidia.com>
Reviewed-on: http://git-master/r/131403
Reviewed-by: Simone Willett <swillett@nvidia.com>
Tested-by: Simone Willett <swillett@nvidia.com>

1 files changed, 1 insertions, 1 deletions

diff --git a/drivers/video/tegra/dc/mipi_cal.c b/drivers/video/tegra/dc/mipi_cal.c
index f53154c61e14..bf6b9f7bd045 100644
--- a/drivers/video/tegra/dc/mipi_cal.c
+++ b/drivers/video/tegra/dc/mipi_cal.c
@@ -49,7 +49,7 @@ struct tegra_mipi_cal *tegra_mipi_cal_init_sw(struct tegra_dc *dc)
 		goto fail;
 	}
 
-	res = nvhost_get_resource_byname(dc->ndev, IORESOURCE_MEM, "mipi_cal");
+	res = platform_get_resource_byname(dc->ndev, IORESOURCE_MEM, "mipi_cal");
 	if (!res) {
 		dev_err(&dc->ndev->dev, "mipi_cal: no entry in resource\n");
 		err = -ENOENT;