A very simple binding, the only property is the phandle to the PWM.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
Documentation/devicetree/bindings/input/pwm-beeper.txt | 7 +++++++
drivers/input/misc/pwm-beeper.c | 11 ++++++++++-
2 files changed, 17 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/input/pwm-beeper.txt
@@ -0,0 +1,7 @@+* PWM beeper device tree bindings++Registers a PWM device as beeper.++Required properties:+- compatible: should be "pwm-beeper"+- pwms: phandle to the physical pwm device
@@ -0,0 +1,7 @@+* PWM beeper device tree bindings++Registers a PWM device as beeper.++Required properties:+- compatible: should be "pwm-beeper"+- pwms: phandle to the physical pwm device
@@ -0,0 +1,7 @@+* PWM beeper device tree bindings++Registers a PWM device as beeper.++Required properties:+- compatible: should be "pwm-beeper"+- pwms: phandle to the physical pwm device
@@ -0,0 +1,7 @@+* PWM beeper device tree bindings++Registers a PWM device as beeper.++Required properties:+- compatible: should be "pwm-beeper"+- pwms: phandle to the physical pwm device
Hmm, pwm_id == 0 is a valid ID I think, but your change makes it go into
DT branch, potentially breaking it.
Yes, this a bit tricky, but we only have a single in-tree user of the
pwm-beeper which uses a id != 0. And now that all the PWM providers have
been converted to the new generic PWM framework the old legacy API will go
away soon anyway. So this if () else branch should hopefully only be
necessary for a transitional period of 1-2 releases. So I think this change
should be OK.
But I think the patch is missing a change to the Kconfig entry to allow the
driver to be selected if the generic PWM framework is available.
@@ -0,0 +1,7 @@+* PWM beeper device tree bindings++Registers a PWM device as beeper.++Required properties:+- compatible: should be "pwm-beeper"+- pwms: phandle to the physical pwm device
Hmm, pwm_id == 0 is a valid ID I think, but your change makes it go into
DT branch, potentially breaking it.
My bad, I missed that platform_data is casted to an unsigned long. I
thought I would test for a pointer.
The obvious clean way would be to use a pointer for platform_data, but
given that this will vanish anyway soon, I think we could just test for
existence of dev->of_node instead of dev->platform_data.
quoted hunk
Yes, this a bit tricky, but we only have a single in-tree user of the
pwm-beeper which uses a id != 0. And now that all the PWM providers have
been converted to the new generic PWM framework the old legacy API will go
away soon anyway. So this if () else branch should hopefully only be
necessary for a transitional period of 1-2 releases. So I think this change
should be OK.
But I think the patch is missing a change to the Kconfig entry to allow the
driver to be selected if the generic PWM framework is available.
Is this the preferred way to do this? Instead of doing the above I added
a 'select HAVE_PWM' to the pwm framework instead. I found a patch for that,
but there were comments to it that this is not good
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
@@ -0,0 +1,7 @@+* PWM beeper device tree bindings++Registers a PWM device as beeper.++Required properties:+- compatible: should be "pwm-beeper"+- pwms: phandle to the physical pwm device
Hmm, pwm_id == 0 is a valid ID I think, but your change makes it go into
DT branch, potentially breaking it.
My bad, I missed that platform_data is casted to an unsigned long. I
thought I would test for a pointer.
The obvious clean way would be to use a pointer for platform_data, but
given that this will vanish anyway soon, I think we could just test for
existence of dev->of_node instead of dev->platform_data.
I think the plan is to convert the existing board file platforms to pwm_table
and then remove the old pwm_request API. So this wouldn't work too well if we'd
test for of_node. Maybe we can just run pwm_get unconditionally and fallback to
pwm_request if it failed. That's also what the PWM backlight driver currently does.
quoted
Yes, this a bit tricky, but we only have a single in-tree user of the
pwm-beeper which uses a id != 0. And now that all the PWM providers have
been converted to the new generic PWM framework the old legacy API will go
away soon anyway. So this if () else branch should hopefully only be
necessary for a transitional period of 1-2 releases. So I think this change
should be OK.
But I think the patch is missing a change to the Kconfig entry to allow the
driver to be selected if the generic PWM framework is available.
Is this the preferred way to do this? Instead of doing the above I added
a 'select HAVE_PWM' to the pwm framework instead. I found a patch for that,
but there were comments to it that this is not good
Thierry said that this is his preferred solution. Given that HAVE_PWM will be
extinct soon anyway I think it is fine.
- Lars
On Mon, Sep 24, 2012 at 09:05:59PM +0200, Lars-Peter Clausen wrote:
On 09/24/2012 08:49 PM, Sascha Hauer wrote:
quoted
My bad, I missed that platform_data is casted to an unsigned long. I
thought I would test for a pointer.
The obvious clean way would be to use a pointer for platform_data, but
given that this will vanish anyway soon, I think we could just test for
existence of dev->of_node instead of dev->platform_data.
I think the plan is to convert the existing board file platforms to pwm_table
and then remove the old pwm_request API. So this wouldn't work too well if we'd
test for of_node. Maybe we can just run pwm_get unconditionally and fallback to
pwm_request if it failed. That's also what the PWM backlight driver currently does.
Fine with me.
quoted
quoted
Yes, this a bit tricky, but we only have a single in-tree user of the
pwm-beeper which uses a id != 0. And now that all the PWM providers have
been converted to the new generic PWM framework the old legacy API will go
away soon anyway. So this if () else branch should hopefully only be
necessary for a transitional period of 1-2 releases. So I think this change
should be OK.
But I think the patch is missing a change to the Kconfig entry to allow the
driver to be selected if the generic PWM framework is available.
Is this the preferred way to do this? Instead of doing the above I added
a 'select HAVE_PWM' to the pwm framework instead. I found a patch for that,
but there were comments to it that this is not good
Thierry said that this is his preferred solution. Given that HAVE_PWM will be
extinct soon anyway I think it is fine.
Ok. Will send an updated patch tomorrow.
Thanks
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
@@ -0,0 +1,7 @@+* PWM beeper device tree bindings++Registers a PWM device as beeper.++Required properties:+- compatible: should be "pwm-beeper"+- pwms: phandle to the physical pwm device
Hmm, pwm_id == 0 is a valid ID I think, but your change makes it go into
DT branch, potentially breaking it.
My bad, I missed that platform_data is casted to an unsigned long. I
thought I would test for a pointer.
The obvious clean way would be to use a pointer for platform_data, but
given that this will vanish anyway soon, I think we could just test for
existence of dev->of_node instead of dev->platform_data.
I think the plan is to convert the existing board file platforms to pwm_table
and then remove the old pwm_request API. So this wouldn't work too well if we'd
test for of_node. Maybe we can just run pwm_get unconditionally and fallback to
pwm_request if it failed. That's also what the PWM backlight driver currently does.
I agree. Calling pwm_get() will automatically switch to using the
entries from a PWM table if the board adds it.
quoted
quoted
Yes, this a bit tricky, but we only have a single in-tree user of the
pwm-beeper which uses a id != 0. And now that all the PWM providers have
been converted to the new generic PWM framework the old legacy API will go
away soon anyway. So this if () else branch should hopefully only be
necessary for a transitional period of 1-2 releases. So I think this change
should be OK.
But I think the patch is missing a change to the Kconfig entry to allow the
driver to be selected if the generic PWM framework is available.
Is this the preferred way to do this? Instead of doing the above I added
a 'select HAVE_PWM' to the pwm framework instead. I found a patch for that,
but there were comments to it that this is not good
Thierry said that this is his preferred solution. Given that HAVE_PWM will be
extinct soon anyway I think it is fine.
The reason is that some platforms, actually the majority, do not define
HAVE_PWM property. We ran into that problem when the PWM tree was first
added to linux-next because builds would break on PowerPC, which is one
of the architectures that doesn't define HAVE_PWM.
Conceptually what we're saying here is that either the legacy PWM API
(HAVE_PWM) or the new PWM framework (PWM) can satisfy the dependency.
Note that if you make the change above, it is no longer enough to depend
on HAVE_PWM because that doesn't provide the pwm_get() function.
Also we should be able to remove HAVE_PWM for 3.7 already as all legacy
implementations have been moved. The plan is to get rid of pwm_request()
and pwm_free() for 3.8. All that's required is converting all the board
files to use PWM lookup tables.
Thierry