On Fri, Feb 15, 2008 at 02:40:29PM +0300, Anton Vorontsov wrote:
[...]
> > > {
> > > qe_chip = container_of(gpio_to_chip(...), struct qe_chip, chip);
> > > ...
> >
> > You know, you can write all this yourself, without needing any
> > support from the GPIO framework whatsoever. The QE stuff t
On Thu, Feb 14, 2008 at 08:36:40PM -0800, David Brownell wrote:
[...]
> > The point was: GPIOs could be "input only" but you still have
> > "output" callback, and that doesn't troubles anybody. Not sure
> > why set_dedicated() such a big issue then, it could fail too! :-)
>
> See above: you're eq
On Sunday 03 February 2008, Anton Vorontsov wrote:
> On Sun, Feb 03, 2008 at 01:22:08PM -0800, David Brownell wrote:
> [...]
>
> > So when you assume that a GPIO number can uniquely specify a pin for
> > use in function multiplexing ... you're stressing a "nonportable"
> > aspect of this issue.
>
On Sun, Feb 03, 2008 at 01:22:08PM -0800, David Brownell wrote:
[...]
> > One of the biggest things these conventions omit is pin multiplexing,
> > since this is highly chip-specific and nonportable.
> >
> > Let me counter: "chip-specific" is a weak argument, IMO.
>
> Then focus on "nonportab
On Sunday 03 February 2008, Anton Vorontsov wrote:
> This routine sets dedicated functions of the GPIO pin.
>
> ---
>
> Hello David,
>
> Yes, I did read Documentation/gpio.txt's last chapter. :-)
>
> ...that says:
>
> One of the biggest things these conventions omit is pin multiplexing,
>
This routine sets dedicated functions of the GPIO pin.
---
Hello David,
Yes, I did read Documentation/gpio.txt's last chapter. :-)
...that says:
One of the biggest things these conventions omit is pin multiplexing,
since this is highly chip-specific and nonportable.
Let me counter: "chip-
