[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <BD79186B4FD85F4B8E60E381CAEE190902153515@mi8nycmail19.Mi8.com>
Date: Fri, 12 Feb 2010 08:53:30 -0500
From: "H Hartley Sweeten" <hartleys@...ionengravers.com>
To: "Bill Gatliff" <bgat@...lgatliff.com>,
"Pavel Machek" <pavel@....cz>
Cc: <linux-embedded@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: RE: [PWM PATCH 2/5] Emulates PWM hardware using a high-resolution timer and a GPIO pin
Thursday, February 11, 2010 1:35 PM, Bill Gatliff wrote:
> Pavel Machek wrote:
>>> +static void
>>> +gpio_pwm_work (struct work_struct *work)
>>> +{
>>> + struct gpio_pwm *gp = container_of(work, struct gpio_pwm, work);
>>> +
>>> + if (gp->active)
>>> + gpio_direction_output(gp->gpio, gp->polarity ? 1 : 0);
>>> + else
>>> + gpio_direction_output(gp->gpio, gp->polarity ? 0 : 1);
>>> +}
>>>
>>
>> ...polarity ^ active ?
>>
>
> ... except that if polarity and/or active are >1, I don't send the
> values 1 or 0 to gpio_direction_output. I don't know if the API is
> specifically intended to accept nonzero values that are greater than 1.
FWIW, the gpiolib API will accept any non-zero value to "set" a gpio pin
and a zero value to "clear" the pin.
For that matter, some of the gpiolib drivers end up returning the bit
position mask for a given gpio pin and not 1 or 0. For instance if the
gpio pin in question is bit 6 in an 8-bit register and it is set, a
__gpio_get_value will end up returning 0x40 and not '1'.
Regards,
Hartley
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists