lkml.org 
[lkml]   [2018]   [Oct]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v2] regulator/gpio: Allow nonexclusive GPIO access
Hi Mark,

On Fri, Oct 12, 2018 at 06:44:24PM +0200, Mark Brown wrote:
> On Fri, Oct 12, 2018 at 04:26:12PM +0200, jacopo mondi wrote:
>
> > Sorry, I'm going slightly OT with this, but please read below.
>
> > On Fri, Oct 12, 2018 at 02:54:12PM +0200, Linus Walleij wrote:
> > > This allows nonexclusive (simultaneous) access to a single
> > > GPIO line for the fixed regulator enable line. This happens
>
> > I might have a use case for shared GPIO lines used as 'simple' reset
> > signal for camera devices and not for regulators.
>
> This recently came up in ASoC too with audio CODECs sharing reset lines,
> there was a discussion started with the reset API maintainer though no
> response yet. CCing in Cheng-yi who had that problem. Not deleting
> context for that.
>

Thanks

> > See drivers/media/i2c/ov772x.c FIXME note in power_on() function at:
> > https://elixir.bootlin.com/linux/latest/source/drivers/media/i2c/ov772x.c#L832
> >
> > The reset line is in this case is passed to the driver by board file:
> > https://elixir.bootlin.com/linux/latest/source/arch/sh/boards/mach-migor/setup.c#L350
> >
> > As you can see PTT3 is used for both sensors (I know, questionable
> > HW design...)
> >
> > Do you think extending gpiod_lookup_flags with this newly introduced
> > NONEXCLUSIVE one is an acceptable solution to avoid handling this in
> > the sensor driver like we're doing today?
>
> One problem you've got there is that you need the two devices to know
> about each other so they coordinate their use of the reset line. This

That's exactly why the current implementation in those drivers is not
even sub-optimal :)

> was relatively easy in the sysetm Cheng-yi has as it's just one driver
> but what if there's mutiple drivers? That's relatively likely with
> audio where you might have something like a CODEC with a separate power
> amplifier. The regulator enable stuff is handling this in the core but
> it's less clear where to put that for reset lines.
>

Isn't DT the natural place where to define a reset line (or any kind of
shared GPIO line) as shared? And for non-OF archs, the board file?

Maybe I should start by adding the NONEXCLUSIVE flags to the ones accepted
by gpio lookup tables and see how it looks?

Thanks
j


> > Please note this is an ancient architecture that boots from board
> > files, but the same might happen in modern designs with OF support. Is
> > there any clean way to handle shared GPIOs I might not be aware of for
> > those systems?


[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2018-10-12 19:17    [W:0.101 / U:1.616 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site