Re: Fundamental Design Flaw of the Device Driver Model?

[Liam Girdwood]

On Fri, 2008-08-22 at 14:25 +0800, Eric Miao wrote:
> Fundamental Design Flaw of the Device Driver Model?
> ===================================================
> 
> Sorry for the misleading subject, its purpose is to draw your attention :-)
> The ideas below are preliminary and I hope I'm not making serious mistakes
> here.
> 
> This question has actually been around in my mind for several months, when
> I started to work on some devices with multiple functions. Specifically, a
> Power Management IC (PMIC in short in the following text) usually includes
> LEDs support (charging, indication...) audio, touch screen, power monitoring,
> LDOs, DC-DC bucks, and possibly some others.
> 
> The initial two ideas came into my mind were:
> 
>    1. separate the functions into multiple devices, write a driver for each
>       of these devices
> 

I've opted for this option with the WM8350 PMIC driver.


>    This, however, creates many questions you have to face with:
> 
>    1. on what bus shall these sub-devices be?
>       ** this is the reason I choose to use "platform_device", at least they
>       can reside on the platform_bus_type, thus platform_driver can be used
>       for this sub-device

My WM8350 clients are all platform_devices too.

> 
>    2. these devices are actually useless except for linking the sub-device
>       to it's sub-device driver and of course, wasting memory. Normally in
>       the driver, another dedicated device will be created. E.g. let's take
>       a typical simple LED driver as an example:
> 

They are not useless as most of my client devices _need_ some sort of
platform data to be passed on for their probe() e.g. my LED driver needs
to know it's brightness values, trigger etc. They also all need a PMIC
reference (passed in the platform_data) which they will need to call any
core PMIC functions e.g. chip read/write


> 
>    3. Who should be the correct parent of these LED devices, the intermediate
>       sub-device we created just now? Or the pmic device on the I2C bus?
>       My answer is the the latter, obviously. However, writing code like:
> 
>       led_classdev_register(pdev->dev.parent, &led_cdev)

Fwiw, I've made the WM8350 I2C driver the parent. The I2C driver also
contains the core PMIC services e.g. IRQs, GPIO's, IO, etc 


> A normal device layout would be:
> 
>                                         device specific
> 					virtual bus type
> 					       |
>          platform_bus_type      i2c_bus_type   |  virtual devices
>                  |                   |         |        |
>      (device)    V                   V         V        V
>    Platform BUS ---> I2C Controller ---> PMIC -+-> LED device (1)
>                                                |
> 					       +-> LED device (2)
> 					       |
> 					       +-> LED device (3)
> 					       |
> 					       +-> DC-DC Buck1
> 					       |
> 					       +-> DC-DC Buck2
> 					       |
> 					       +-> LDO1
> 					       |
> 					       +-> LDO2
> 					       |
> 					       +-> Backlight PWM1
> 					       |
> 					       +-> Backlight PWM2
> 					       |
> 					      ...
> 

Ok, I basically have :-

                                 Platform devices
                                     |        |
                                     V        V
Platform Bus --> I2C controller --> PMIC +-> LED1
                                         +-> LED2
                                         +-> Audio
                                         +-> DCDC1
                                         +-> Backlight

I originally had a PMIC bus (like above) but decided it was easier just
to use the existing kernel infrastructure. My I2C PMIC driver just
registers the client platform_devices when it probes.

Cheers

Liam

--
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/