On Wed, 30 Jan 2019 15:06:12 +0100 "H. Nikolaus Schaller" <hns@xxxxxxxxxxxxx> wrote: > Hi Andreas, > > > Am 30.01.2019 um 10:02 schrieb Johan Hovold <johan@xxxxxxxxxx>: > > > > On Mon, Jan 28, 2019 at 05:44:29PM +0100, Andreas Kemnade wrote: > >> On Mon, 28 Jan 2019 08:53:56 +0100 > >> Johan Hovold <johan@xxxxxxxxxx> wrote: > >> > >>> On Fri, Jan 25, 2019 at 08:43:10PM +0100, Andreas Kemnade wrote: > >>>> The GTA04 has a w2sg0004 or w2sg0084 gps chip. Not detectable > >>>> which one is mounted so use the compatibility entry for w2sg0004 > >>>> for all which will work for both. > >>>> > >>>> Signed-off-by: Andreas Kemnade <andreas@xxxxxxxxxxxx> > >>>> --- > >>>> w2sg0004 bindings (together with the corresponding support is in > >>>> https://git.kernel.org/pub/scm/linux/kernel/git/johan/gnss gnss-next) > >>>> arch/arm/boot/dts/omap3-gta04.dtsi | 13 +++++++++++++ > >>>> 1 file changed, 13 insertions(+) > > > >>>> + gps: gps { > >>> > >>> The node should be named "gnss" as per the binding. > >>> > >>>> + compatible = "wi2wi,w2sg0004"; > >>>> + pinctrl-names = "default"; > >>>> + pinctrl-0 = <&gps_pins>; > >>>> + sirf,onoff-gpios = <&gpio5 17 GPIO_ACTIVE_HIGH>; > >>>> + lna-supply = <&vsim>; > >>> > >>> Also, the vcc-supply is a required property. > >>> > >> well, it is not require in the driver and it has different behavior > >> (on even when not opened if on-off is there) than the lna-supply used > >> here. So maybe fix the binding documentation? > > > > The device-tree describes hardware, and how a particular driver happens > > to implement a binding is not relevant. > > > > That said, there is a bit of an on-going, shall we say philosophical, > > debate about this. The regulator maintainer takes a firm position that > > all mandatory physical supplies should be represented in firmware > > > > https://lore.kernel.org/lkml/20181123133126.GF2089@xxxxxxxxxxxxx/T/#u > > https://lore.kernel.org/lkml/20180409102244.GB11532@xxxxxxxxxxxxx/T/#u > > > > while Rob appears to take a slightly different stance on fixed > > regulators while admitting that this an issue which has not yet been > > fully resolved: > > > > https://lore.kernel.org/lkml/20180425171123.xhyoay3nu463btoq@rob-hp-laptop/T/#u > > > > Since this is a new binding, and the hardware requires the vcc supply > > and this is reflected in the binding, I think you should add a fixed > > regulator. At least until you hear otherwise. ;) > > Assuming that there is no REGEN signal from the twl4030 unless 1V8 is also > stable, I'd suggest as a simple solution: > > vcc-supply = <&vio>; > > Alternatively, we could define a dedicated fixed-regulator in omap3-gta04.dtsi > for the 3V3 rail. Which is always-on. This would allow to describe that e.g. the > itg3200, panel and other chips and sensors are also supplied by this. But since > no driver can really make use of it (turn on/off on demand) this is IMHO quite > needless. > well, probably better to add that regulator, so we match the real hardware and not doing some fake here just to satisfy that binding requirement. I will send a new version with that regulator added. Regards, Andreas
Attachment:
pgp5fm1S8G7TI.pgp
Description: OpenPGP digital signature
