I configured the u-boot to have SPI, UART and GPIO pins on the expansion header. SPI and UART works fine.
The problem is that all the GPIO are not in the state in which I set on “beagle.h”. After booting I can change the status of all the GPIO using /sys/class… so no problem with this.
The problem is that one of the GPIO (gpio158) is connected to a buzzer and the state of this pin on boot is “1”, then the buzzer start always making noise throughout the boot process (approx. 1 minute). This is not what I want :).
Below, I write the “beagle.h” configuration file:
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
The above solution solves the problem but after I started the system I don’t have access to gpio158 on /sys/class/gpio. This is because it was never exported to user space. I added some lines to the previous code to achieve export gpio158 and now everything works fine.
Below, I write the modified code:
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 { gpio_export(gpio, 0); }
}
}
The only thing missing is the direction on /sys/class/gpio/gpio158/direction but no problem for me.
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.
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.
