linux-pm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Gregory CLEMENT <gregory.clement@free-electrons.com>
To: Baruch Siach <baruch@tkos.co.il>,
	Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
Cc: Miquel RAYNAL <miquel.raynal@free-electrons.com>,
	Zhang Rui <rui.zhang@intel.com>,
	Eduardo Valentin <edubezval@gmail.com>,
	devicetree@vger.kernel.org, Jason Cooper <jason@lakedaemon.net>,
	Andrew Lunn <andrew@lunn.ch>,
	Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>,
	Russell King <linux@armlinux.org.uk>,
	linux-pm@vger.kernel.org, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v2 3/4] thermal: armada: add support for CP110
Date: Mon, 11 Dec 2017 18:02:49 +0100	[thread overview]
Message-ID: <87y3m9qjt2.fsf@free-electrons.com> (raw)
In-Reply-To: <20171211152731.glkkes5errcxmsvz@sapphire.tkos.co.il> (Baruch Siach's message of "Mon, 11 Dec 2017 17:27:31 +0200")

Hi Baruch,
 
 On lun., déc. 11 2017, Baruch Siach <baruch@tkos.co.il> wrote:

> Hi Miquel,
>
> On Mon, Dec 11, 2017 at 04:09:32PM +0100, Miquel RAYNAL wrote:
>> On Sun,  3 Dec 2017 13:11:23 +0200
>> Baruch Siach <baruch@tkos.co.il> wrote:
>> 
>> > The CP110 component is integrated in the Armada 8k and 7k lines of
>> > processors.
>> > 
>> > This patch also adds an option of offset to the MSB of the control
>> > register. The existing DT binding for Armada 38x refers to a single
>> > 32 bit control register. It turns out that this is actually only the
>> > MSB of the control area. Changing the binding to fix that would break
>> > existing DT files, so the Armada 38x binding is left as is.
>> > 
>> > The new CP110 binding increases the size of the control area to 64
>> > bits, thus moving the MSB to offset 4.
>> > 
>> > Signed-off-by: Baruch Siach <baruch@tkos.co.il>
>> > ---
>> > v2: No change
>> > ---
>> >  drivers/thermal/armada_thermal.c | 24 ++++++++++++++++++++++--
>> >  1 file changed, 22 insertions(+), 2 deletions(-)
>> > 
>> > diff --git a/drivers/thermal/armada_thermal.c
>> > b/drivers/thermal/armada_thermal.c index 0eb82097571f..59b75f63945d
>> > 100644 --- a/drivers/thermal/armada_thermal.c
>> > +++ b/drivers/thermal/armada_thermal.c
>> > @@ -73,6 +73,7 @@ struct armada_thermal_data {
>> >  	unsigned int temp_shift;
>> >  	unsigned int temp_mask;
>> >  	unsigned int is_valid_shift;
>> > +	unsigned int control_msb_offset;
>> >  };
>> >  
>> >  static void armadaxp_init_sensor(struct platform_device *pdev,
>> > @@ -142,12 +143,14 @@ static void armada375_init_sensor(struct
>> > platform_device *pdev, static void armada380_init_sensor(struct
>> > platform_device *pdev, struct armada_thermal_priv *priv)
>> >  {
>> > -	unsigned long reg = readl_relaxed(priv->control);
>> > +	void __iomem *control_msb =
>> > +		priv->control + priv->data->control_msb_offset;
>> > +	unsigned long reg = readl_relaxed(control_msb);
>> >  
>> >  	/* Reset hardware once */
>> >  	if (!(reg & A380_HW_RESET)) {
>> >  		reg |= A380_HW_RESET;
>> > -		writel(reg, priv->control);
>> > +		writel(reg, control_msb);
>> >  		mdelay(10);
>> >  	}
>> >  }
>> > @@ -266,6 +269,19 @@ static const struct armada_thermal_data
>> > armada_ap806_data = { .signed_sample = true,
>> >  };
>> >  
>> > +static const struct armada_thermal_data armada_cp110_data = {
>> > +	.is_valid = armada_is_valid,
>> > +	.init_sensor = armada380_init_sensor,
>> 
>> I see the initialization for CP110 thermal IP is close to
>> Armada-380's, but, as you point it in the commit log it is still
>> different.
>> 
>> I don't know what is the best way to handle this but until now each
>> new compatible had his own ->init_sensor function, shouldn't we do
>> the same here as changes are requested? This would naturally avoid the
>> situation with Armada-380 bindings.
>
> I'm not sure I understand your suggestion.
>
> There is no difference between the CP110 and the Armada 38x, as far as I can 
> see. The only quirk is that the existing Armada 38x DT binding is wrong I that 
> the 'reg' property references the control MSB, while leaving the LSB
> out. We

Well I would not say it was wrong but more incomplete :)


> can't change the Armada 38x binding without breaking existing DTs. The 
> 'control_msb_offset' field that this patch adds allows correct binding for 
> CP110, while keeping compatibility with the existing Armada 38x
> binding.

I am not against adding a new compatible string for CP110 but ot be
honest the new binding for CP110 does not bring anything as you don't
use at all the LSB register.

Actually, if on Armada 375 we initially mapped the LSB register it was
to support an very early release of the SoC (stepping Z) and only for
resetting its value. So I guess you started to write the AP860 part
based on the Armada 375 and then found that we could map a more complete
range of the registers.

>
> How would a separate init_sensor routine improve things?

So yes please do it, thanks to this you won't have to add the
control_msb_offset member and can use a clean function. Moreover if in
the future we see some usefulness for this LSB register then we could use
the new compatible for the Armada 38x.

Thanks,

Gregory

>
> baruch
>
> -- 
>      http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
> =}------------------------------------------------ooO--U--Ooo------------{=
>    - baruch@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

  reply	other threads:[~2017-12-11 17:03 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-03 11:11 [PATCH v2 1/4] dt-bindings: thermal/armada: describe AP806 and CP110 Baruch Siach
2017-12-03 11:11 ` [PATCH v2 2/4] thermal: armada: add support for AP806 Baruch Siach
     [not found] ` <f8c589337a4fb78852eadf15058e8f8d132d4dc0.1512299484.git.baruch-NswTu9S1W3P6gbPvEgmw2w@public.gmane.org>
2017-12-03 11:11   ` [PATCH v2 3/4] thermal: armada: add support for CP110 Baruch Siach
2017-12-11 15:09     ` Miquel RAYNAL
2017-12-11 15:27       ` Baruch Siach
2017-12-11 17:02         ` Gregory CLEMENT [this message]
     [not found]           ` <87y3m9qjt2.fsf-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
2017-12-13  8:38             ` Baruch Siach
2017-12-13  8:55               ` Miquel RAYNAL
2017-12-13  9:10                 ` Baruch Siach
     [not found]                   ` <20171213091040.jwsphlax4yidm4qp-MwjkAAnuF3khR1HGirfZ1z4kX+cae0hd@public.gmane.org>
2017-12-13  9:21                     ` Gregory CLEMENT
2017-12-13  9:13               ` Gregory CLEMENT
     [not found]                 ` <874lovq9cx.fsf-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
2017-12-13  9:42                   ` Baruch Siach
2017-12-03 11:11   ` [PATCH v2 4/4] thermal: armada: use msleep for long delays Baruch Siach
2017-12-04 22:33   ` [PATCH v2 1/4] dt-bindings: thermal/armada: describe AP806 and CP110 Rob Herring

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=87y3m9qjt2.fsf@free-electrons.com \
    --to=gregory.clement@free-electrons.com \
    --cc=andrew@lunn.ch \
    --cc=baruch@tkos.co.il \
    --cc=devicetree@vger.kernel.org \
    --cc=edubezval@gmail.com \
    --cc=ezequiel@vanguardiasur.com.ar \
    --cc=jason@lakedaemon.net \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=miquel.raynal@free-electrons.com \
    --cc=rui.zhang@intel.com \
    --cc=sebastian.hesselbarth@gmail.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 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).