From: Stefan Strobl <hidden> Date: 2009-06-02 17:02:29
Hi
I still don't quite understand how to use the Flattened Device Tree /
Open Firmware. I see there's a driver (mpc52xx_gpt.c) that supports to
use the Pins on the GPT as simple GPIOs. I activated it by adding these
lines to my dts file:
gpt2: timer@620 {
compatible = "fsl,mpc5200b-gpt-gpio","fsl,mpc5200-gpt-gpio";
reg = <0x620 0x10>;
interrupts = <1 11 0>;
gpio-controller;
#gpio-cells = <2>;
};
I can see the appropriate entries in sysfs
(/sys/devices/f0000000.soc5200/f0000620.timer), but how can I actually
use these GPIO's now?
Many thanks
Stefan.
From: Anton Vorontsov <hidden> Date: 2009-06-02 17:15:30
Hi Stefan,
On Tue, Jun 02, 2009 at 07:02:25PM +0200, Stefan Strobl wrote:
Hi
I still don't quite understand how to use the Flattened Device Tree /
Open Firmware. I see there's a driver (mpc52xx_gpt.c) that supports to
use the Pins on the GPT as simple GPIOs. I activated it by adding these
lines to my dts file:
gpt2: timer@620 {
compatible = "fsl,mpc5200b-gpt-gpio","fsl,mpc5200-gpt-gpio";
reg = <0x620 0x10>;
interrupts = <1 11 0>;
gpio-controller;
#gpio-cells = <2>;
};
I can see the appropriate entries in sysfs
(/sys/devices/f0000000.soc5200/f0000620.timer), but how can I actually
use these GPIO's now?
For in-kernel usage example you can take a look at:
arch/powerpc/boot/dts/mpc836x_rdk.dts (upm node, notice gpios = <>)
drivers/mtd/nand/fsl_upm.c (of_get_gpio() then gpio_request()).
For userland usage you need to enable CONFIG_GPIO_SYSFS, and then
look into /sys/class/gpio/{gpiochip,export,gpioNNN}.
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
From: Stefan Strobl <hidden> Date: 2009-06-03 12:42:59
Anton Vorontsov wrote:
Hi Stefan,
On Tue, Jun 02, 2009 at 07:02:25PM +0200, Stefan Strobl wrote:
quoted
Hi
I still don't quite understand how to use the Flattened Device Tree /
Open Firmware. I see there's a driver (mpc52xx_gpt.c) that supports to
use the Pins on the GPT as simple GPIOs.
I can see the appropriate entries in sysfs
(/sys/devices/f0000000.soc5200/f0000620.timer), but how can I actually
use these GPIO's now?
For in-kernel usage example you can take a look at:
arch/powerpc/boot/dts/mpc836x_rdk.dts (upm node, notice gpios = <>)
drivers/mtd/nand/fsl_upm.c (of_get_gpio() then gpio_request()).
For userland usage you need to enable CONFIG_GPIO_SYSFS, and then
look into /sys/class/gpio/{gpiochip,export,gpioNNN}.
Thanks. With CONFIG_GPIO_SYSFS I can see the gpios as you mentioned, but
cannot change its state there.
I've now also added CONFIG_LEDS_GPIO and was able to connect the GPIOs
to LEDs like this:
gpt2: timer@620 {
compatible = "fsl,mpc5200b-gpt-gpio","fsl,mpc5200-gpt-gpio";
reg = <0x620 0x10>;
interrupts = <1 11 0>;
gpio-controller;
#gpio-cells = <2>;
};
leds {
compatible = "gpio-leds";
dbg {
label = "DbgLED";
gpios = <&gpt2 0 1>; /* Active low */
linux,default-trigger = "heartbeat";
};
};
I can now manipulate the state of the LED in /sys/class/led/DbgLED/,
which is cool.
The led class provides support for setting the brightness, which
obviously the gpio driver doesn't support. The hardware (mpc52xx_gpt)
would support it in PWM mode though. I'm now wandering how this could be
best implemented.
1) - Create some PWM class similar to the GPIO class
- Add support for PWM mode in mpc52xx_gpt.c that uses that PWM class
- And add an interface for the LED to use the PWM class
2) - Create an LED driver that accesses the mpc52xx_gpt directly.
I think I would be overwhelmed trying to implement (1) but am confident
to do (2). What do you think is the right approach?
Cheers, Stefan.
From: Anton Vorontsov <hidden> Date: 2009-06-03 13:22:24
On Wed, Jun 03, 2009 at 02:42:26PM +0200, Stefan Strobl wrote:
[...]
The led class provides support for setting the brightness, which
obviously the gpio driver doesn't support. The hardware (mpc52xx_gpt)
would support it in PWM mode though. I'm now wandering how this could be
best implemented.
1) - Create some PWM class similar to the GPIO class
- Add support for PWM mode in mpc52xx_gpt.c that uses that PWM class
- And add an interface for the LED to use the PWM class
2) - Create an LED driver that accesses the mpc52xx_gpt directly.
I think I would be overwhelmed trying to implement (1) but am confident
to do (2). What do you think is the right approach?
I'd suggest creating a generic PWM class, i.e. PWMLIB, alike to
GPIOLIB. (2) can be an acceptable approach for now, but for the
long-term solution (1) is the way to go.
The non-lib PWM API is already there, see include/linux/pwm.h,
and arch/arm/mach-pxa/pwm.c as an implementation example.
Note that PXA implementation is SOC-specific, which is not very
good.
So I'd suggest creating drivers/pwm/pwmlib.c, borrowing
ideas from gpiolib. And then we can reuse drivers/leds/leds-pwm.c
driver (of course, after adding appropriate OF code into it).
Sure, as you've said, it could be quite boringly to implement,
could take quite some time to pass all review cycles etc.
But someday someone will have to do this. :-)
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
From: Jon Smirl <hidden> Date: 2009-06-03 15:38:51
On Wed, Jun 3, 2009 at 9:22 AM, Anton Vorontsov
[off-list ref] wrote:
On Wed, Jun 03, 2009 at 02:42:26PM +0200, Stefan Strobl wrote:
[...]
quoted
The led class provides support for setting the brightness, which
obviously the gpio driver doesn't support. The hardware (mpc52xx_gpt)
would support it in PWM mode though. I'm now wandering how this could be
best implemented.
1) - Create some PWM class similar to the GPIO class
=A0 =A0- Add support for PWM mode in mpc52xx_gpt.c that uses that PWM cl=
ass
quoted
=A0 =A0- And add an interface for the LED to use the PWM class
2) - Create an LED driver that accesses the mpc52xx_gpt directly.
I think I would be overwhelmed trying to implement (1) but am confident
to do (2). What do you think is the right approach?
I'd suggest creating a generic PWM class, i.e. PWMLIB, alike to
GPIOLIB. (2) can be an acceptable approach for now, but for the
long-term solution (1) is the way to go.
The non-lib PWM API is already there, see include/linux/pwm.h,
and arch/arm/mach-pxa/pwm.c as an implementation example.
Note that PXA implementation is SOC-specific, which is not very
good.
So I'd suggest creating drivers/pwm/pwmlib.c, borrowing
ideas from gpiolib. And then we can reuse drivers/leds/leds-pwm.c
driver (of course, after adding appropriate OF code into it).
Sure, as you've said, it could be quite boringly to implement,
could take quite some time to pass all review cycles etc.
But someday someone will have to do this. :-)
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" i=
From: Trilok Soni <hidden> Date: 2009-06-03 15:54:58
Hi Jon,
On Wed, Jun 3, 2009 at 9:08 PM, Jon Smirl [off-list ref] wrote:
On Wed, Jun 3, 2009 at 9:22 AM, Anton Vorontsov
[off-list ref] wrote:
quoted
On Wed, Jun 03, 2009 at 02:42:26PM +0200, Stefan Strobl wrote:
[...]
quoted
The led class provides support for setting the brightness, which
obviously the gpio driver doesn't support. The hardware (mpc52xx_gpt)
would support it in PWM mode though. I'm now wandering how this could b=
e
quoted
quoted
best implemented.
1) - Create some PWM class similar to the GPIO class
=A0 =A0- Add support for PWM mode in mpc52xx_gpt.c that uses that PWM c=
lass
quoted
quoted
=A0 =A0- And add an interface for the LED to use the PWM class
2) - Create an LED driver that accesses the mpc52xx_gpt directly.
I think I would be overwhelmed trying to implement (1) but am confident
to do (2). What do you think is the right approach?
I'd suggest creating a generic PWM class, i.e. PWMLIB, alike to
GPIOLIB. (2) can be an acceptable approach for now, but for the
long-term solution (1) is the way to go.
From: Grant Likely <hidden> Date: 2009-06-11 22:01:28
On Wed, Jun 3, 2009 at 7:22 AM, Anton Vorontsov[off-list ref] w=
rote:
On Wed, Jun 03, 2009 at 02:42:26PM +0200, Stefan Strobl wrote:
[...]
quoted
The led class provides support for setting the brightness, which
obviously the gpio driver doesn't support. The hardware (mpc52xx_gpt)
would support it in PWM mode though. I'm now wandering how this could be
best implemented.
1) - Create some PWM class similar to the GPIO class
=A0 =A0- Add support for PWM mode in mpc52xx_gpt.c that uses that PWM cl=
ass
quoted
=A0 =A0- And add an interface for the LED to use the PWM class
2) - Create an LED driver that accesses the mpc52xx_gpt directly.
I think I would be overwhelmed trying to implement (1) but am confident
to do (2). What do you think is the right approach?
I'd suggest creating a generic PWM class, i.e. PWMLIB, alike to
GPIOLIB. (2) can be an acceptable approach for now, but for the
long-term solution (1) is the way to go.
The non-lib PWM API is already there, see include/linux/pwm.h,
and arch/arm/mach-pxa/pwm.c as an implementation example.
Note that PXA implementation is SOC-specific, which is not very
good.
So I'd suggest creating drivers/pwm/pwmlib.c, borrowing
ideas from gpiolib. And then we can reuse drivers/leds/leds-pwm.c
driver (of course, after adding appropriate OF code into it).
Ugh. The referenced pwm api is about as trivial as it gets; it is an
anonymous context pointer (anonymous struct pwm_device *) with a set
of accessor functions. PWMs are also not nearly as common as GPIO
pins, and I am not interested in gpiolib being duplicated for PWMs, at
least not until there are more that just two examples of use to draw
from.
If anything, I'd rather struct pwm_device be non-anonymous and contain
a set of ops which call directly into the driver. That way is at
least multiplatform friendly. I don't think the gpio API is the
example to follow here. But even then I think it is premature to try
and define a PWM api. Personally, I'd modify mpc52xx_gpt to export
its own PWM interface for the time being using the existing GPIO
infrastructure to find the appropriate pin.
If you do decide to do a generic PWM api, then I think the way to go
is to build it as an extension to gpiolib.
Cheers,
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
From: Anton Vorontsov <hidden> Date: 2009-06-12 00:37:23
On Thu, Jun 11, 2009 at 04:00:51PM -0600, Grant Likely wrote:
On Wed, Jun 3, 2009 at 7:22 AM, Anton Vorontsov[off-list ref] wrote:
quoted
On Wed, Jun 03, 2009 at 02:42:26PM +0200, Stefan Strobl wrote:
[...]
quoted
The led class provides support for setting the brightness, which
obviously the gpio driver doesn't support. The hardware (mpc52xx_gpt)
would support it in PWM mode though. I'm now wandering how this could be
best implemented.
1) - Create some PWM class similar to the GPIO class
- Add support for PWM mode in mpc52xx_gpt.c that uses that PWM class
- And add an interface for the LED to use the PWM class
2) - Create an LED driver that accesses the mpc52xx_gpt directly.
I think I would be overwhelmed trying to implement (1) but am confident
to do (2). What do you think is the right approach?
I'd suggest creating a generic PWM class, i.e. PWMLIB, alike to
GPIOLIB. (2) can be an acceptable approach for now, but for the
long-term solution (1) is the way to go.
The non-lib PWM API is already there, see include/linux/pwm.h,
and arch/arm/mach-pxa/pwm.c as an implementation example.
Note that PXA implementation is SOC-specific, which is not very
good.
So I'd suggest creating drivers/pwm/pwmlib.c, borrowing
ideas from gpiolib. And then we can reuse drivers/leds/leds-pwm.c
driver (of course, after adding appropriate OF code into it).
Ugh. The referenced pwm api is about as trivial as it gets; it is an
anonymous context pointer (anonymous struct pwm_device *) with a set
of accessor functions. PWMs are also not nearly as common as GPIO
pins, and I am not interested in gpiolib being duplicated for PWMs, at
least not until there are more that just two examples of use to draw
from.
I didn't say that we should duplicate gpiolib. I said that we
might borrow some ideas. ;-)
If anything, I'd rather struct pwm_device be non-anonymous and contain
a set of ops which call directly into the driver. That way is at
least multiplatform friendly. I don't think the gpio API is the
example to follow here. But even then I think it is premature to try
and define a PWM api. Personally, I'd modify mpc52xx_gpt to export
its own PWM interface for the time being using the existing GPIO
infrastructure to find the appropriate pin.
Jon Smirl found that there were already some efforts put
into making generic PWM class:
http://thread.gmane.org/gmane.linux.kernel.embedded/1160
Briefly looking, the class is pretty cool. Somebody should just
continue this work.
If you do decide to do a generic PWM api, then I think the way to go
is to build it as an extension to gpiolib.
I don't think David Brownell will like this idea. But
who knows... maybe.
Thanks,
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2