On Fri, Dec 02, 2016 at 11:17:35AM +0100, Hans de Goede wrote:
The primary consumer of the lpss pwm is the i915 kms driver, but currently that driver cannot get the pwm because i915 platforms are not using devicetree and pwm-lpss does not call pwm_add_table.
Another problem is that i915 does not support get_pwm returning -EPROBE_DEFER and i915's init is very complex and this is almost impossible to fix.
This commit changes the PWM_LPSS Kconfig from a tristate to a bool, so that when the i915 driver loads the lpss pwm will be available avoiding the -EPROBE_DEFER issue. Note that this is identical to how the same problem was solved for the pwm-crc driver.
Being builtin also allows calling pwm_add_table directly from the pwm-lpss code, otherwise the pwm_add_table call would need to be put somewhere else to ensure it happens before i915 calls pwm_get, even if i915 would support -EPROBE_DEFER.
Signed-off-by: Hans de Goede hdegoede@redhat.com
drivers/pwm/Kconfig | 12 +++--------- drivers/pwm/pwm-lpss.c | 11 +++++++++++ 2 files changed, 14 insertions(+), 9 deletions(-)
This is completely backwards. You're putting board-specific bits into a generic driver.
And no, this is not the same as pwm-crc because the board-specific bits went into the MFD driver. I don't like that very much either, but there is documentation that suggests that the Crystal Cove PMIC is used on a single platform, whereas there's no such evidence for LPSS.
Why can't you just add something to drivers/platform/x86 to register the table? You could base that on some kind of identifier (ACPI, DMI, ...) to only do so if necessary.
I could probably live with making this builtin, but your justification sounds like a bit of a lame excuse rather than a good technical reason.
Thierry