Problem with uboot gpio pin status...
daicav
Sudheer D
and check the response
From: daicav <dai...@gmail.com>
To: beagl...@googlegroups.com
Sent: Saturday, 25 June 2011 10:41 PM
Subject: [beagleboard] Problem with uboot gpio pin status...
You received this message because you are subscribed to the Google Groups "Beagle Board" group.
To view this discussion on the web visit https://groups.google.com/d/msg/beagleboard/-/wfOgxjSOm4gJ.
To post to this group, send email to beagl...@googlegroups.com.
To unsubscribe from this group, send email to beagleboard...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/beagleboard?hl=en.
daicav
Ueli Niederer
Quoting daicav <dai...@gmail.com>:
> cat /sys/class/gpio/gpio158/direction : in
> cat /sys/class/gpio/gpio158/value : 1
Telling from this output, I'd say, the kernel did not care about the
direction settings in U-Boot. Actually I'm not too sure if it's the
right strategy to do the whole pinmux in the secondary stage loader.
Anyway, I think what you have to do is telling the kernel at board
init time what you want to do with your GPIO: If I were in your shoes,
I'd request the gpio and set it's direction in the board init file of
your kernel like in the following "patch":
in arch/arm/mach-omap2/board-omap3beagle.c:
create a new static function like this:
/*! \brief Initializes a gpio as output and sets it to 0
\param gpio Number of the GPIO to be initialized */
static void __init buzzer_init(unsigned gpio)
{
/* Tell the kernel, we want to use the GPIO 158 */
if (gpio_request(gpio, "myBuzzer") != 0)
{
printk(KERN_ALERT "Buzzer: Unable to request GPIO %d", gpio);
}
else
{
/* Now tell the kernel that GPIO 158 is an output and should
be set to 0 */
if (gpio_direction_output(gpio, 0) != 0)
{
printk(KERN_ALERT "Buzzer: Unable to set GPIO direction
for GPIO %d", gpio);
}
}
}
in function static void __init omap3_beagle_init(void)
add a call to above function like this:
buzzer_init(158);
But maybe theres a better way to achieve the same goal. Honestly the
whole init concept seems to me not very standardized (at least for the
omap tree) or is at least a little mistery for me ;-)
I hope that helps
Ueli
daicav
daicav
Ueli Niederer
> I read something else!
> *gpio_export(gpioNumber, 0)* means that there's no "direction" on
> /sys/class/gpio/gpioNumber/ (you can't change direction)
> *gpio_export(gpioNumber, 1)* means that you can access (and change) the
> direction of the gpio.
Nothing wrong with your explaination. Except the fact that taku tried
to access GPIO from user space using sysfs. And according to gpiolib,
if you export a gpio using the /sys/class/gpio/export file, the gpio
is exported with following line (ln 625 in gpiolib.c of 2.6.39 kernel):
status = gpio_export(gpio, true);
So he should be able to manipluate the direction from userspace.
regards
ueli
Ueli Niederer
> Quoting daicav <dai...@gmail.com>:
>> I read something else!
>> [...]
> Nothing wrong with your explaination. Except the fact that taku
> tried to [...]
I just realized that, while writing my answer, I falsely attributed
your answer to another discussion in this group[1], mea culpa.
Of course your addition and it's correction is totally right.
To summarize the discussion, your final solution including all
modifications is now
in arch/arm/mach-omap2/board-omap3beagle.c:
create a new static function like this:
/*! \brief Initializes a gpio as output and sets it to 0
\param gpio Number of the GPIO to be initialized */
static void __init buzzer_init(unsigned gpio)
{
/* Tell the kernel, we want to use the GPIO 158 */
if (gpio_request(gpio, "myBuzzer") != 0)
{
printk(KERN_ALERT "Buzzer: Unable to request GPIO %d", gpio);
}
else
{
/* Now tell the kernel that GPIO 158 is an output and should
be set to 0 */
if (gpio_direction_output(gpio, 0) != 0)
{
printk(KERN_ALERT "Buzzer: Unable to set GPIO direction
for GPIO %d", gpio);
}
else
{
/* Export the gpio to userspace without the possibility of changing
direction. If this is needed, pass 1 instead of 0 */
gpio_export(gpio, 0);
}
}
}
in function static void __init omap3_beagle_init(void)
add a call to above function like this:
buzzer_init(158);
Is this correct? In fact, I think in your case it's not optional to be
able to change direction settings from userspace, it's even more
mandatory to prevent such an action from userspace since you have some
hardware outside expecting an output connected to it.
regards
ueli