All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Cameron <jic23@kernel.org>
To: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Quentin Schulz <foss+kernel@0leil.net>,
	Lars-Peter Clausen <lars@metafoo.de>,
	Heiko Stuebner <heiko@sntech.de>,
	AngeloGioacchino Del Regno
	<angelogioacchino.delregno@collabora.com>,
	Shreeya Patel <shreeya.patel@collabora.com>,
	Simon Xue <xxm@rock-chips.com>,
	Philipp Zabel <p.zabel@pengutronix.de>,
	Jonathan Cameron <Jonathan.Cameron@huawei.com>,
	linux-iio@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org,
	Quentin Schulz <quentin.schulz@theobroma-systems.com>
Subject: Re: [PATCH 0/3] iio: adc: rockchip_saradc: fix bitmasking and remove custom logic for getting reset
Date: Sat, 24 Feb 2024 19:25:35 +0000	[thread overview]
Message-ID: <20240224192535.237933de@jic23-huawei> (raw)
In-Reply-To: <CAHp75VfmsDeTP97srRJU09gA988xw68+ZHsXvXT3W_wv1HEauA@mail.gmail.com>

On Fri, 23 Feb 2024 15:01:30 +0200
Andy Shevchenko <andy.shevchenko@gmail.com> wrote:

> On Fri, Feb 23, 2024 at 2:46 PM Quentin Schulz <foss+kernel@0leil.net> wrote:
> >
> > The mask for the channel selection is incorrect as it's specified to be
> > 16b wide by is actually only 4.
> >
> > Also, the 16 lower bits in the SARADC_CONV_CON register are write
> > protected. Whatever their value is can only be written to the hardware
> > block if their associated bit in the higher 16 bits is set. Considering
> > that the channel bitmask is 4b wide but that we can write e.g. 0 in
> > there, we shouldn't use the value shifted by 16 as a mask but rather the
> > bitmask for that value shifted by 16. This is currently NOT an issue
> > because the only SoC with SARADCv2 IP is the RK3588 which has a reset
> > defined in the SoC DTSI. When that is the case, the reset is asserted
> > before every channel conversion is started. This means the registers are
> > reset so effectively, we do not need to write zeros so the wrong mask
> > still works because where we should be writing zeroes, there are already
> > zeroes. However, let's fix this in case there comes a day there's an SoC
> > which doesn't require to reset the controller before every channel
> > conversion is started.
> >
> > Lastly, let's use the appropriate function from the reset subsystem
> > for getting an optional exclusive reset instead of rolling out our own
> > logic.
> >
> > Those three patches should not be changing any behavior.  
> 
> Nice series, I have the comments in patch 3, but no need to resend
> until Jonathan asks for. He might address that whilst applying.
> 
> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
> 

I've take the series through the togreg branch as we are so near the
merge windows.  Note (despite Linus not liking it :)) I use links
in my git tags so anyone really searching for Quentin can find
the discussion.

I'm usually a bit lazy on cleaning out what I would consider unnecessary
CC tags but given Andy comment on these I've dropped the extra
one.

Patches 1 and 2 marked for stable.

Jonathan

WARNING: multiple messages have this Message-ID (diff)
From: Jonathan Cameron <jic23@kernel.org>
To: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Quentin Schulz <foss+kernel@0leil.net>,
	Lars-Peter Clausen <lars@metafoo.de>,
	Heiko Stuebner <heiko@sntech.de>,
	AngeloGioacchino Del Regno
	<angelogioacchino.delregno@collabora.com>,
	Shreeya Patel <shreeya.patel@collabora.com>,
	Simon Xue <xxm@rock-chips.com>,
	Philipp Zabel <p.zabel@pengutronix.de>,
	Jonathan Cameron <Jonathan.Cameron@huawei.com>,
	linux-iio@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org,
	Quentin Schulz <quentin.schulz@theobroma-systems.com>
Subject: Re: [PATCH 0/3] iio: adc: rockchip_saradc: fix bitmasking and remove custom logic for getting reset
Date: Sat, 24 Feb 2024 19:25:35 +0000	[thread overview]
Message-ID: <20240224192535.237933de@jic23-huawei> (raw)
In-Reply-To: <CAHp75VfmsDeTP97srRJU09gA988xw68+ZHsXvXT3W_wv1HEauA@mail.gmail.com>

On Fri, 23 Feb 2024 15:01:30 +0200
Andy Shevchenko <andy.shevchenko@gmail.com> wrote:

> On Fri, Feb 23, 2024 at 2:46 PM Quentin Schulz <foss+kernel@0leil.net> wrote:
> >
> > The mask for the channel selection is incorrect as it's specified to be
> > 16b wide by is actually only 4.
> >
> > Also, the 16 lower bits in the SARADC_CONV_CON register are write
> > protected. Whatever their value is can only be written to the hardware
> > block if their associated bit in the higher 16 bits is set. Considering
> > that the channel bitmask is 4b wide but that we can write e.g. 0 in
> > there, we shouldn't use the value shifted by 16 as a mask but rather the
> > bitmask for that value shifted by 16. This is currently NOT an issue
> > because the only SoC with SARADCv2 IP is the RK3588 which has a reset
> > defined in the SoC DTSI. When that is the case, the reset is asserted
> > before every channel conversion is started. This means the registers are
> > reset so effectively, we do not need to write zeros so the wrong mask
> > still works because where we should be writing zeroes, there are already
> > zeroes. However, let's fix this in case there comes a day there's an SoC
> > which doesn't require to reset the controller before every channel
> > conversion is started.
> >
> > Lastly, let's use the appropriate function from the reset subsystem
> > for getting an optional exclusive reset instead of rolling out our own
> > logic.
> >
> > Those three patches should not be changing any behavior.  
> 
> Nice series, I have the comments in patch 3, but no need to resend
> until Jonathan asks for. He might address that whilst applying.
> 
> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
> 

I've take the series through the togreg branch as we are so near the
merge windows.  Note (despite Linus not liking it :)) I use links
in my git tags so anyone really searching for Quentin can find
the discussion.

I'm usually a bit lazy on cleaning out what I would consider unnecessary
CC tags but given Andy comment on these I've dropped the extra
one.

Patches 1 and 2 marked for stable.

Jonathan

_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

WARNING: multiple messages have this Message-ID (diff)
From: Jonathan Cameron <jic23@kernel.org>
To: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Quentin Schulz <foss+kernel@0leil.net>,
	Lars-Peter Clausen <lars@metafoo.de>,
	Heiko Stuebner <heiko@sntech.de>,
	AngeloGioacchino Del Regno
	<angelogioacchino.delregno@collabora.com>,
	Shreeya Patel <shreeya.patel@collabora.com>,
	Simon Xue <xxm@rock-chips.com>,
	Philipp Zabel <p.zabel@pengutronix.de>,
	Jonathan Cameron <Jonathan.Cameron@huawei.com>,
	linux-iio@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org,
	Quentin Schulz <quentin.schulz@theobroma-systems.com>
Subject: Re: [PATCH 0/3] iio: adc: rockchip_saradc: fix bitmasking and remove custom logic for getting reset
Date: Sat, 24 Feb 2024 19:25:35 +0000	[thread overview]
Message-ID: <20240224192535.237933de@jic23-huawei> (raw)
In-Reply-To: <CAHp75VfmsDeTP97srRJU09gA988xw68+ZHsXvXT3W_wv1HEauA@mail.gmail.com>

On Fri, 23 Feb 2024 15:01:30 +0200
Andy Shevchenko <andy.shevchenko@gmail.com> wrote:

> On Fri, Feb 23, 2024 at 2:46 PM Quentin Schulz <foss+kernel@0leil.net> wrote:
> >
> > The mask for the channel selection is incorrect as it's specified to be
> > 16b wide by is actually only 4.
> >
> > Also, the 16 lower bits in the SARADC_CONV_CON register are write
> > protected. Whatever their value is can only be written to the hardware
> > block if their associated bit in the higher 16 bits is set. Considering
> > that the channel bitmask is 4b wide but that we can write e.g. 0 in
> > there, we shouldn't use the value shifted by 16 as a mask but rather the
> > bitmask for that value shifted by 16. This is currently NOT an issue
> > because the only SoC with SARADCv2 IP is the RK3588 which has a reset
> > defined in the SoC DTSI. When that is the case, the reset is asserted
> > before every channel conversion is started. This means the registers are
> > reset so effectively, we do not need to write zeros so the wrong mask
> > still works because where we should be writing zeroes, there are already
> > zeroes. However, let's fix this in case there comes a day there's an SoC
> > which doesn't require to reset the controller before every channel
> > conversion is started.
> >
> > Lastly, let's use the appropriate function from the reset subsystem
> > for getting an optional exclusive reset instead of rolling out our own
> > logic.
> >
> > Those three patches should not be changing any behavior.  
> 
> Nice series, I have the comments in patch 3, but no need to resend
> until Jonathan asks for. He might address that whilst applying.
> 
> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
> 

I've take the series through the togreg branch as we are so near the
merge windows.  Note (despite Linus not liking it :)) I use links
in my git tags so anyone really searching for Quentin can find
the discussion.

I'm usually a bit lazy on cleaning out what I would consider unnecessary
CC tags but given Andy comment on these I've dropped the extra
one.

Patches 1 and 2 marked for stable.

Jonathan

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2024-02-24 19:25 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-23 12:45 [PATCH 0/3] iio: adc: rockchip_saradc: fix bitmasking and remove custom logic for getting reset Quentin Schulz
2024-02-23 12:45 ` Quentin Schulz
2024-02-23 12:45 ` Quentin Schulz
2024-02-23 12:45 ` [PATCH 1/3] iio: adc: rockchip_saradc: fix bitmask for channels on SARADCv2 Quentin Schulz
2024-02-23 12:45   ` Quentin Schulz
2024-02-23 12:45   ` Quentin Schulz
2024-02-23 13:40   ` Heiko Stübner
2024-02-23 13:40     ` Heiko Stübner
2024-02-23 13:40     ` Heiko Stübner
2024-02-23 12:45 ` [PATCH 2/3] iio: adc: rockchip_saradc: use mask for write_enable bitfield Quentin Schulz
2024-02-23 12:45   ` Quentin Schulz
2024-02-23 12:45   ` Quentin Schulz
2024-02-23 13:43   ` Heiko Stübner
2024-02-23 13:43     ` Heiko Stübner
2024-02-23 13:43     ` Heiko Stübner
2024-02-23 12:45 ` [PATCH 3/3] iio: adc: rockchip_saradc: replace custom logic with devm_reset_control_get_optional_exclusive Quentin Schulz
2024-02-23 12:45   ` Quentin Schulz
2024-02-23 12:45   ` Quentin Schulz
2024-02-23 13:00   ` Andy Shevchenko
2024-02-23 13:00     ` Andy Shevchenko
2024-02-23 13:00     ` Andy Shevchenko
2024-02-23 13:10     ` Quentin Schulz
2024-02-23 13:10       ` Quentin Schulz
2024-02-23 13:10       ` Quentin Schulz
2024-02-23 14:39       ` Andy Shevchenko
2024-02-23 14:39         ` Andy Shevchenko
2024-02-23 14:39         ` Andy Shevchenko
2024-02-26 20:31         ` Dragan Simic
2024-02-26 20:31           ` Dragan Simic
2024-02-26 20:31           ` Dragan Simic
2024-02-27 12:48           ` Andy Shevchenko
2024-02-27 12:48             ` Andy Shevchenko
2024-02-27 12:48             ` Andy Shevchenko
2024-02-27 14:55             ` Dragan Simic
2024-02-27 14:55               ` Dragan Simic
2024-02-27 14:55               ` Dragan Simic
2024-02-23 13:44   ` Heiko Stübner
2024-02-23 13:44     ` Heiko Stübner
2024-02-23 13:44     ` Heiko Stübner
2024-02-23 13:01 ` [PATCH 0/3] iio: adc: rockchip_saradc: fix bitmasking and remove custom logic for getting reset Andy Shevchenko
2024-02-23 13:01   ` Andy Shevchenko
2024-02-23 13:01   ` Andy Shevchenko
2024-02-24 19:25   ` Jonathan Cameron [this message]
2024-02-24 19:25     ` Jonathan Cameron
2024-02-24 19:25     ` Jonathan Cameron

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=20240224192535.237933de@jic23-huawei \
    --to=jic23@kernel.org \
    --cc=Jonathan.Cameron@huawei.com \
    --cc=andy.shevchenko@gmail.com \
    --cc=angelogioacchino.delregno@collabora.com \
    --cc=foss+kernel@0leil.net \
    --cc=heiko@sntech.de \
    --cc=lars@metafoo.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=p.zabel@pengutronix.de \
    --cc=quentin.schulz@theobroma-systems.com \
    --cc=shreeya.patel@collabora.com \
    --cc=xxm@rock-chips.com \
    /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.