linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Lukasz Majewski <lukma@denx.de>
To: Lee Jones <lee.jones@linaro.org>
Cc: linux-kernel@vger.kernel.org,
	Dmitry Torokhov <dmitry.torokhov@gmail.com>,
	Sascha Hauer <s.hauer@pengutronix.de>,
	Enrico Weigelt <info@metux.net>,
	Thomas Gleixner <tglx@linutronix.de>,
	Kate Stewart <kstewart@linuxfoundation.org>,
	linux-input@vger.kernel.org
Subject: Re: [PATCH v4 1/3] mfd: mc13xxx: Add mc34708 adc support
Date: Fri, 2 Aug 2019 15:19:12 +0200	[thread overview]
Message-ID: <20190802151912.26dbb296@jawa> (raw)
In-Reply-To: <20190725182020.3948c8d9@jawa>

[-- Attachment #1: Type: text/plain, Size: 4752 bytes --]

Hi Lee,

> Hi Lee,
> 
> > On Thu, 18 Jul 2019, Lukasz Majewski wrote:
> >   
> > > From: Sascha Hauer <s.hauer@pengutronix.de>
> > > 
> > > The mc34708 has an improved adc. The older variants will always
> > > convert a fixed order of channels. The mc34708 can do up to eight
> > > conversions in arbitrary channel order. Currently this extended
> > > feature is not supported. We only support touchscreen conversions
> > > now, which will be sampled in a data format compatible to the
> > > older chips in order to keep the API between the mfd and the
> > > touchscreen driver.
> > > 
> > > Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> > > Signed-off-by: Lukasz Majewski <lukma@denx.de>
> > > 
> > > ---
> > > Changes for v4:
> > > - None
> > > 
> > > Changes for v3:
> > > - None
> > > 
> > > Changes for v2:
> > > - Change the return code patch when the mc13xxx ADC is performing
> > > conversion
> > > - Introduce new include/linux/mfd/mc34708.h header file for
> > > mc34708 specific defines
> > > 
> > > Changes from the original patches:
> > > - ADC conversion functions prototypes added to fix build error
> > > - Adjustments to make checkpatch clean (-ENOSYS, line over 80
> > > char)
> > > 
> > > This patch applies on top of v5.2 - SHA1:
> > > 0ecfebd2b52404ae0c54a878c872bb93363ada36 ---
> > >  drivers/mfd/mc13xxx-core.c  | 102
> > > +++++++++++++++++++++++++++++++++++++++++++-
> > > drivers/mfd/mc13xxx.h       |   3 ++ include/linux/mfd/mc34708.h |
> > > 37 ++++++++++++++++ 3 files changed, 141 insertions(+), 1
> > > deletion(-) create mode 100644 include/linux/mfd/mc34708.h
> > > 
> > > diff --git a/drivers/mfd/mc13xxx-core.c
> > > b/drivers/mfd/mc13xxx-core.c index 1abe7432aad8..01473d6fda21
> > > 100644 --- a/drivers/mfd/mc13xxx-core.c
> > > +++ b/drivers/mfd/mc13xxx-core.c
> > > @@ -12,6 +12,7 @@
> > >  #include <linux/of_device.h>
> > >  #include <linux/platform_device.h>
> > >  #include <linux/mfd/core.h>
> > > +#include <linux/mfd/mc34708.h>
> > >  
> > >  #include "mc13xxx.h"
> > >  
> > > @@ -45,6 +46,8 @@
> > >  
> > >  #define MC13XXX_ADC2		45
> > >  
> > > +#define MC13XXX_ADC_WORKING		(1 << 0)    
> > 
> > BIT(0) ?  
> 
> The same convention - i.e. (1 << 0) is used in the rest of the file.
> 
> >   
> > >  void mc13xxx_lock(struct mc13xxx *mc13xxx)
> > >  {
> > >  	if (!mutex_trylock(&mc13xxx->lock)) {
> > > @@ -198,22 +201,30 @@ static void mc34708_print_revision(struct
> > > mc13xxx *mc13xxx, u32 revision) maskval(revision,
> > > MC34708_REVISION_FAB)); }
> > >  
> > > +static int mc13xxx_adc_conversion(struct mc13xxx *, unsigned int,
> > > +				  unsigned int, u8, bool,
> > > unsigned int *); +static int mc34708_adc_conversion(struct
> > > mc13xxx *, unsigned int,
> > > +				  unsigned int, u8, bool,
> > > unsigned int *); +
> > >  /* These are only exported for mc13xxx-i2c and mc13xxx-spi */
> > >  struct mc13xxx_variant mc13xxx_variant_mc13783 = {
> > >  	.name = "mc13783",
> > >  	.print_revision = mc13xxx_print_revision,
> > > +	.adc_do_conversion = mc13xxx_adc_conversion,
> > >  };
> > >  EXPORT_SYMBOL_GPL(mc13xxx_variant_mc13783);    
> > 
> > I'd prefer to keep the call-back functions as close to zero as
> > possible.  
> 
> If I may ask - what is wrong with having per device callback(s) ?
> 
> > 
> > It would be better to turn mc13xxx_adc_conversion() in to the catch
> > function  
> 
> Could you share any example? 
> 
> > choose an execution route based on some platform matching.
> >   
> 
> Could you help me with giving a hint of how shall I do the "platform
> matching" in this particular driver ? 
> 
> The mc13xxx driver seems rather complex with SPI and I2C support and
> in which the subdevices are added (e.g. rtc, adc, etc).
> 
> This particular patch just follows current driver design and fixes its
> usability for mc13708 drvice.
> 
> > If you could do the same for print_revision too, that would be even
> > better.
> >   
> 
> I would prefer to fix the driver (for mc13708) without the need to
> change the working code.
> 

Lee, would you find time to reply to this message?

> 
> Best regards,
> 
> Lukasz Majewski
> 
> --
> 
> DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email:
> lukma@denx.de




Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@denx.de

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  reply	other threads:[~2019-08-02 13:19 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-17 22:25 [PATCH v4 0/3] mfd: mc13xxx: Fixes and enhancements for NXP's mc34708 Lukasz Majewski
2019-07-17 22:26 ` [PATCH v4 1/3] mfd: mc13xxx: Add mc34708 adc support Lukasz Majewski
2019-07-25 12:36   ` Lee Jones
2019-07-25 16:20     ` Lukasz Majewski
2019-08-02 13:19       ` Lukasz Majewski [this message]
2019-08-12 10:08       ` Lee Jones
2019-07-17 22:26 ` [PATCH v4 2/3] input: touchscreen mc13xxx: Make platform data optional Lukasz Majewski
2019-07-17 22:26 ` [PATCH v4 3/3] input: touchscreen mc13xxx: Add mc34708 support Lukasz Majewski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190802151912.26dbb296@jawa \
    --to=lukma@denx.de \
    --cc=dmitry.torokhov@gmail.com \
    --cc=info@metux.net \
    --cc=kstewart@linuxfoundation.org \
    --cc=lee.jones@linaro.org \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=s.hauer@pengutronix.de \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).