"Peter 'p2' De Schrijver" <[EMAIL PROTECTED]> writes:

> On Thu, Sep 25, 2008 at 02:40:19PM +0300, ext Kevin Hilman wrote:
>> "Peter 'p2' De Schrijver" <[EMAIL PROTECTED]> writes:
>> 
>> >> 
>> >> The cross-platform gpiolib calls should be used here.
>> >> 
>> >> > +                       snprintf(name, sizeof(name), "hw_dbg%d", i);
>> >> > +                       err = _new_debobs_pad(&debobs_pads[i], name, i,
>> >> > +                                               debobs_root);
>> >> > +                       if (err) {
>> >> > +                               omap_free_gpio(ETK_GPIO(i));
>> >> > +                               return err;
>> >> > +                       }
>> >> > +               }
>> >> > +       }
>> >> 
>> >> In the successful case, future calls to gpio_request() to use these
>> >> lines will fail, since the line is reserved by the omap_request_gpio()
>> >> call.
>> >> 
>> >
>> > Yes. That's intended. If debobs sucessfully claims the GPIO line, noone
>> > else should be allowed to claim it, unless debobs releases it again.
>> >
>> 
>> In that case, what is the proposed method for other kernel code to use
>> the debobs lines?
>
> Hmm, good point :) My idea was to use the gpiolib calls on GPIO12 -
> GPIO29, but then there is no way for a user to know if the GPIO was
> assigned to debobs or not... Maybe debobs should register as gpiolib
> 'chip' and reexport those lines ? Would that make sense ?

I think debobs should simply 'gpio_export' each pin.  It does not need
to hold them.

Later on, if other kernel code comes along and does a gpio_request() I
think the /sysfs entry for that line will disappear until it has been
gpio_free'd.

Kevin
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to