Re: [PATCH 16/21] OMAPDSS: handle output-driver reg/unreg more dynamically

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, 2012-03-08 at 14:04 +0530, Archit Taneja wrote:
> On Wednesday 07 March 2012 06:14 PM, Tomi Valkeinen wrote:

> > -	r = hdmi_init_platform_driver();
> > -	if (r) {
> > -		DSSERR("Failed to initialize hdmi\n");
> > -		goto err_hdmi;
> > +	/*
> > +	 * It's ok if the output-driver register fails. It happens, for example,
> > +	 * when there is no output-device (e.g. SDI for OMAP4).
> > +	 */
> 
> Suppose we do a omap2plus_defconfig, CONFIG_OMAP2_DSS_SDI would be 
> selected, and sdi.c would be built, if we boot on OMAP4, why would a sdi 
> driver register cause a failure? Wouldn't the sdi driver just get 
> registered, and wait till eternity for the corresponding sdi platform 
> device to get registered?

No. Well, yes.

Currently we use platform_driver_register() to register the drivers, and
it does just what you described. But a few patches later I change
platform_driver_register() to platform_driver_probe(), which will return
ENODEV if there are no matching devices for the driver.

I originally had the platform_driver_probe() patch before this patch,
and thus the comment above made sense. Now the patch is after this
patch, so the comment is not exactly right until the probe patch is also
applied.

The point with platform_driver_probe() is that it can be used with
non-removable devices which are created at boot time, like the DSS
components. With platform_driver_probe() the probe function is called
only at that one time, and never afterwards. So probe can be in __init
section, and thrown away after init.

One side effect of using platform_driver_probe() is that it returns
ENODEV is there are no devices. In a simple module, the error can be
then returned from module_init, thus causing the whole module to be
unloaded. Our case is a bit more complex as we have multiple drivers in
the same module.

A downside with that is that we don't really know if the ENODEV error
happened because there were no devices (which is ok), or if it came from
probe function (which is not so ok). However, I thought that it doesn't
matter if an output driver has failed. We can still continue with the
other output drivers just fine.

Actually, there is a small problem. If, for example, DSI driver fails to
load, and DPI driver tries to use DSI PLL...

 Tomi

Attachment: signature.asc
Description: This is a digitally signed message part


[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux