All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marek Vasut <marex@denx.de>
To: "Lars-Peter Clausen" <lars@metafoo.de>
Cc: "Michał Mirosław" <mirqus@gmail.com>,
	linux-iio@vger.kernel.org,
	"Fabio Estevam" <fabio.estevam@freescale.com>,
	"Shawn Guo" <shawn.guo@linaro.org>,
	"Jonathan Cameron" <jic23@kernel.org>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 1/2] iio: mxs: Add MX23 support into the IIO driver
Date: Mon, 21 Jan 2013 22:49:10 +0100	[thread overview]
Message-ID: <201301212249.11173.marex@denx.de> (raw)
In-Reply-To: <50FDB517.700@metafoo.de>

Dear Lars-Peter Clausen,

> On 01/21/2013 10:32 PM, Marek Vasut wrote:
> > Dear Micha=C5=82 Miros=C5=82aw,
> >=20
> >> 2013/1/21 Marek Vasut <marex@denx.de>:
> >>> Dear Micha=C5=82 Miros=C5=82aw,
> >>>=20
> >>>> 2013/1/21 Marek Vasut <marex@denx.de>:
> >>>>> This patch adds support for i.MX23 into the LRADC driver. The LRADC
> >>>>> block on MX23 is not much different from the one on MX28, thus this
> >>>>> is only a few changes fixing the parts that are specific to MX23.
> >>>>=20
> >>>> [...]
> >>>>=20
> >>>>> +struct mxs_lradc_of_config {
> >>>>> +       const int               irq_count;
> >>>>> +       const char * const      *irq_name;
> >>>>> +};
> >>>>> +
> >>>>> +static const struct mxs_lradc_of_config const mxs_lradc_of_config[]
> >>>>> =3D { +       [IMX23_LRADC] =3D {
> >>>>> +               .irq_count      =3D ARRAY_SIZE(mx23_lradc_irq_names=
),
> >>>>> +               .irq_name       =3D mx23_lradc_irq_names,
> >>>>> +       },
> >>>>> +       [IMX28_LRADC] =3D {
> >>>>> +               .irq_count      =3D ARRAY_SIZE(mx28_lradc_irq_names=
),
> >>>>> +               .irq_name       =3D mx28_lradc_irq_names,
> >>>>> +       },
> >>>>> +};
> >>>>> +
> >>>>>=20
> >>>>>  enum mxs_lradc_ts {
> >>>>> =20
> >>>>>         MXS_LRADC_TOUCHSCREEN_NONE =3D 0,
> >>>>>         MXS_LRADC_TOUCHSCREEN_4WIRE,
> >>>>>=20
> >>>>> @@ -857,8 +890,19 @@ static void mxs_lradc_hw_stop(struct mxs_lradc
> >>>>> *lradc)
> >>>>>=20
> >>>>>                 writel(0, lradc->base + LRADC_DELAY(i));
> >>>>> =20
> >>>>>  }
> >>>>>=20
> >>>>> +static const struct of_device_id mxs_lradc_dt_ids[] =3D {
> >>>>> +       { .compatible =3D "fsl,imx23-lradc", .data =3D (void
> >>>>> *)IMX23_LRADC, }, +       { .compatible =3D "fsl,imx28-lradc", .dat=
a =3D
> >>>>> (void
> >>>>> *)IMX28_LRADC, }, +       { /* sentinel */ }
> >>>>> +};
> >>>>> +MODULE_DEVICE_TABLE(of, mxs_lradc_dt_ids);
> >>>>> +
> >>>>=20
> >>>> Why not s/(void \*)\(IMX.._LRADC\)/\&mxs_lradc_of_config[\1]/ ?
> >>>=20
> >>> Check the register layout, it differs between MX23 and MX28, that's o=
ne
> >>> reason, since were we to access differently placed registers, we can =
do
> >>> it easily as in the SSP/I2C drivers.
> >>>=20
> >>> Moreover, there are some features on the MX28 that are not on the MX23
> >>> (like voltage treshold triggers and touchbuttons), with this setup, we
> >>> can easily check what we're running at at runtime and determine to
> >>> disallow these.
> >>>=20
> >>> From my point of view, using the number (IMX23_LRADC / IMX28_LRADC) is
> >>> much more convenient in the long run.
> >>=20
> >> I'm asking, because you don't use this number anywhere other than in
> >> mxs_lradc_probe()
> >> and there only to dereference the irq-names table. After that the
> >> structure and number
> >> are forgotten.
> >=20
> > Certainly, so far it's used only this way. But please see my argument
> > about register layout, that's why I went down this road of abstraction.
>=20
> You'll probably be better of by putting these differences into the
> mxs_lradc_of_config struct as well, instead of adding switch statements
> here and there throughout the code.

Certainly. All that is needed is in place now.

Best regards,
Marek Vasut

WARNING: multiple messages have this Message-ID (diff)
From: marex@denx.de (Marek Vasut)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/2] iio: mxs: Add MX23 support into the IIO driver
Date: Mon, 21 Jan 2013 22:49:10 +0100	[thread overview]
Message-ID: <201301212249.11173.marex@denx.de> (raw)
In-Reply-To: <50FDB517.700@metafoo.de>

Dear Lars-Peter Clausen,

> On 01/21/2013 10:32 PM, Marek Vasut wrote:
> > Dear Micha? Miros?aw,
> > 
> >> 2013/1/21 Marek Vasut <marex@denx.de>:
> >>> Dear Micha? Miros?aw,
> >>> 
> >>>> 2013/1/21 Marek Vasut <marex@denx.de>:
> >>>>> This patch adds support for i.MX23 into the LRADC driver. The LRADC
> >>>>> block on MX23 is not much different from the one on MX28, thus this
> >>>>> is only a few changes fixing the parts that are specific to MX23.
> >>>> 
> >>>> [...]
> >>>> 
> >>>>> +struct mxs_lradc_of_config {
> >>>>> +       const int               irq_count;
> >>>>> +       const char * const      *irq_name;
> >>>>> +};
> >>>>> +
> >>>>> +static const struct mxs_lradc_of_config const mxs_lradc_of_config[]
> >>>>> = { +       [IMX23_LRADC] = {
> >>>>> +               .irq_count      = ARRAY_SIZE(mx23_lradc_irq_names),
> >>>>> +               .irq_name       = mx23_lradc_irq_names,
> >>>>> +       },
> >>>>> +       [IMX28_LRADC] = {
> >>>>> +               .irq_count      = ARRAY_SIZE(mx28_lradc_irq_names),
> >>>>> +               .irq_name       = mx28_lradc_irq_names,
> >>>>> +       },
> >>>>> +};
> >>>>> +
> >>>>> 
> >>>>>  enum mxs_lradc_ts {
> >>>>>  
> >>>>>         MXS_LRADC_TOUCHSCREEN_NONE = 0,
> >>>>>         MXS_LRADC_TOUCHSCREEN_4WIRE,
> >>>>> 
> >>>>> @@ -857,8 +890,19 @@ static void mxs_lradc_hw_stop(struct mxs_lradc
> >>>>> *lradc)
> >>>>> 
> >>>>>                 writel(0, lradc->base + LRADC_DELAY(i));
> >>>>>  
> >>>>>  }
> >>>>> 
> >>>>> +static const struct of_device_id mxs_lradc_dt_ids[] = {
> >>>>> +       { .compatible = "fsl,imx23-lradc", .data = (void
> >>>>> *)IMX23_LRADC, }, +       { .compatible = "fsl,imx28-lradc", .data =
> >>>>> (void
> >>>>> *)IMX28_LRADC, }, +       { /* sentinel */ }
> >>>>> +};
> >>>>> +MODULE_DEVICE_TABLE(of, mxs_lradc_dt_ids);
> >>>>> +
> >>>> 
> >>>> Why not s/(void \*)\(IMX.._LRADC\)/\&mxs_lradc_of_config[\1]/ ?
> >>> 
> >>> Check the register layout, it differs between MX23 and MX28, that's one
> >>> reason, since were we to access differently placed registers, we can do
> >>> it easily as in the SSP/I2C drivers.
> >>> 
> >>> Moreover, there are some features on the MX28 that are not on the MX23
> >>> (like voltage treshold triggers and touchbuttons), with this setup, we
> >>> can easily check what we're running at at runtime and determine to
> >>> disallow these.
> >>> 
> >>> From my point of view, using the number (IMX23_LRADC / IMX28_LRADC) is
> >>> much more convenient in the long run.
> >> 
> >> I'm asking, because you don't use this number anywhere other than in
> >> mxs_lradc_probe()
> >> and there only to dereference the irq-names table. After that the
> >> structure and number
> >> are forgotten.
> > 
> > Certainly, so far it's used only this way. But please see my argument
> > about register layout, that's why I went down this road of abstraction.
> 
> You'll probably be better of by putting these differences into the
> mxs_lradc_of_config struct as well, instead of adding switch statements
> here and there throughout the code.

Certainly. All that is needed is in place now.

Best regards,
Marek Vasut

  reply	other threads:[~2013-01-21 21:49 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-21 20:05 [PATCH 1/2] iio: mxs: Add MX23 support into the IIO driver Marek Vasut
2013-01-21 20:05 ` Marek Vasut
2013-01-21 20:05 ` [PATCH 2/2] ARM: mxs: Add OF props for MX23 LRADC Marek Vasut
2013-01-21 20:05   ` Marek Vasut
2013-01-22 12:06   ` Jonathan Cameron
2013-01-22 12:06     ` Jonathan Cameron
2013-01-22 12:41     ` Shawn Guo
2013-01-22 12:41       ` Shawn Guo
2013-01-22 13:02       ` Jonathan Cameron
2013-01-22 13:02         ` Jonathan Cameron
2013-01-21 20:36 ` [PATCH 1/2] iio: mxs: Add MX23 support into the IIO driver Michał Mirosław
2013-01-21 20:36   ` Michał Mirosław
2013-01-21 21:00   ` Marek Vasut
2013-01-21 21:00     ` Marek Vasut
2013-01-21 21:19     ` Michał Mirosław
2013-01-21 21:19       ` Michał Mirosław
2013-01-21 21:32       ` Marek Vasut
2013-01-21 21:32         ` Marek Vasut
2013-01-21 21:37         ` Lars-Peter Clausen
2013-01-21 21:37           ` Lars-Peter Clausen
2013-01-21 21:49           ` Marek Vasut [this message]
2013-01-21 21:49             ` Marek Vasut
2013-01-22 12:09             ` Jonathan Cameron
2013-01-22 12:09               ` Jonathan Cameron
2013-01-21 21:48         ` Michał Mirosław
2013-01-21 21:48           ` Michał Mirosław
2013-01-21 21:53           ` Marek Vasut
2013-01-21 21:53             ` Marek Vasut

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=201301212249.11173.marex@denx.de \
    --to=marex@denx.de \
    --cc=fabio.estevam@freescale.com \
    --cc=jic23@kernel.org \
    --cc=lars@metafoo.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-iio@vger.kernel.org \
    --cc=mirqus@gmail.com \
    --cc=shawn.guo@linaro.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.