[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1414598848.32383.4.camel@mm-sol.com>
Date: Wed, 29 Oct 2014 18:07:28 +0200
From: "Ivan T. Ivanov" <iivanov@...sol.com>
To: Bjorn Andersson <bjorn.andersson@...ymobile.com>
Cc: Dmitry Torokhov <dmitry.torokhov@...il.com>,
Rob Herring <robh+dt@...nel.org>,
Pawel Moll <pawel.moll@....com>,
Mark Rutland <mark.rutland@....com>,
Ian Campbell <ijc+devicetree@...lion.org.uk>,
Grant Likely <grant.likely@...aro.org>,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-input@...r.kernel.org" <linux-input@...r.kernel.org>,
"linux-arm-msm@...r.kernel.org" <linux-arm-msm@...r.kernel.org>
Subject: Re: [PATCH 0/2] Qualcomm PM8941 power key driver
Hi Bjorn,
On Fri, 2014-10-24 at 08:23 -0700, Bjorn Andersson wrote:
> On Wed 08 Oct 02:50 PDT 2014, Ivan T. Ivanov wrote:
>
> > On Tue, 2014-10-07 at 11:46 -0700, Bjorn Andersson wrote:
> > > On Tue 07 Oct 02:01 PDT 2014, Ivan T. Ivanov wrote:
> > >
> > > > Hi Bjorn,
> > > >
> > > > On Mon, 2014-10-06 at 18:11 -0700, Bjorn Andersson wrote:
> [..]
> > > > > create mode 100644 drivers/input/misc/pm8941-pwrkey.c
> > > >
> > > > Any reason why we cannot reuse pm8xxx-pwrkey driver? It have been
> > > > converted to regmap already.
> > > >
> > >
> > > The boilerplate code is the same,
> >
> > The boilerplate code is almost 100% :-)
> >
> > > but configuration registers have different
> > > layout and values written in them are different.
> >
> > We talk about 3 registers and 2 bit defines. struct regmap_field
> > should be able to help here.
> >
>
> You're totally right, we could rewrite the driver to use regmap_field and make
> the rest of the differences conditional. In my eyes we end up with two drivers
> in one file - but it can be done.
>
> A difference however is that in pm8941 the ps hold behavious (reboot vs power
> off) is controlled by this same block. So I have an additional patch that adds
> a restart handler here that sets the pmic in the right state before we pull
> pshold (but I haven't been able to test it properly).
>
> In pm8xxx this is handled in the pmic misc block and does not belong in this
> driver.
Ok, Your plan is to bring up support for QPNP power-on PMIC sub function into this
driver. In this case, I agree, it will be cleaner to have separate driver for this.
Regards,
Ivan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists