video: tegra: dc: change enable and hotplug_init arguments

pass device as argument for enable and hotplug_init so that it
can be used in board files to get the regulator using device name.
arm: tegra: kai: fix coverity issue

Check return values of gpio_request
and gpio_direction_input/output for
panel, audio and touch.
dc: mach-tegra: pass sd settings bl_device_name

We can't always pass the backlight device directly to
nvsd. This change gives the backlight device name
to nvsd (which is known at build time) and then at
runtime can lookup the backlight device.
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.
ARM: tegra: __tegra_move_framebuffer takes dev

For T30+ based boards, FB needs to create 1-1 linear mapping, which
requires dma mapping API from device itself.
Merge branch 'board-grouper-panel-testing' of https://github.com/enssorcel/Grouper-3.4 into board-grouper-panel-testing