Hi, On Thu, Apr 24, 2014 at 11:41:15AM +1000, NeilBrown wrote: > On Wed, 23 Apr 2014 20:21:00 -0500 Felipe Balbi <balbi@xxxxxx> wrote: > > > I have no problem either way, just that unused code doesn't have to be > > sitting in the tree and I'm not entirely sure this GPIO should be > > handled by omap-serial.c, perhaps something more generic inside > > serial-core so other UART drivers can benefit from it. > > Perhaps. But there there are more people I need to convince :-) heh, Greg is in Cc, that'd be a good start. > > > On the other hand, if you can point out to me what I'm missing, and how I can > > > solve my problem with any virtual GPIOs, I'm all ears. > > > > > > To make my problem simple and explicit: I have a device attached to a UART > > > which has a separate regulator. The regulator should be powered on if and > > > > So you're using DTR to power the GPIO and hoping that the regulator > > stabilizes quickly enough so that by the time your open() finishes you > > don't have to add nonsensical msleep() calls before writing to the > > device. Sounds a bit fragile to me. > > The gpio_set call is synchronous, and the gpio-regulator driver could add a sure, but it's synchronous towards toggling the GPIO, pulling it high. It doesn't guarantee that the far-end regulator's output will be fully changed. > delay (I think). yeah, that'd be part of the regulator-gpio with the startup-delay-ns property (IIRC) > > > only if the /dev/ttyXX interface to the UART is open. The device is a > > > bluetooth transceiver. > > > > considering this is a BTUART device, why didn't you do this at the ldisc > > level ? hci_uart_open() sounds like a good choice from a quick thinking. > > > > I'll have a look into that, thanks. so, Ack for $subject or not ? -- balbi
Attachment:
signature.asc
Description: Digital signature
