All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wei Ni <wni-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
To: Thierry Reding <thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: rui.zhang-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org,
	MLongnecker-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org,
	swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org,
	mikko.perttunen-/1wQRMveznE@public.gmane.org,
	linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH V3 04/11] thermal: tegra: split tegra_soctherm driver
Date: Fri, 22 Jan 2016 16:52:20 +0800	[thread overview]
Message-ID: <56A1EDC4.6000401@nvidia.com> (raw)
In-Reply-To: <20160121144605.GB32301@ulmo>



On 2016年01月21日 22:46, Thierry Reding wrote:
> * PGP Signed by an unknown key
> 
> On Mon, Jan 18, 2016 at 06:02:29PM +0800, Wei Ni wrote:
> [...]
>> +int tegra_soctherm_calculate_tsensor_calibration(
>> +				struct tegra_tsensor *sensor,
>> +				const struct tsensor_shared_calibration *shared)
> 
> The need to ident weirdly here should be an indication that the function
> name is too long, how about:

Hmm, yes, it's too long.

> 
> int tegra_tsensor_calc_calib(struct tegra_tsensor *sensor,
> 			     const struct tsensor_shared_calibration *shared)
> 
> ?

There have two functions about calibration, I prefer to name them as:
tegra_calc_tsensor_calib() and tegra_calc_shared_calib().

> 
>> +{
>> +	const struct tegra_tsensor_group *sensor_group;
>> +	u32 val, calib;
>> +	s32 actual_tsensor_ft, actual_tsensor_cp;
>> +	s32 delta_sens, delta_temp;
>> +	s32 mult, div;
>> +	s16 therma, thermb;
>> +	int err;
>> +
>> +	sensor_group = sensor->group;
>> +
>> +	err = tegra_fuse_readl(sensor->calib_fuse_offset, &val);
>> +	if (err)
>> +		return err;
>> +
>> +	actual_tsensor_cp = (shared->base_cp * 64) + sign_extend32(val, 12);
>> +	val = (val & FUSE_TSENSOR_CALIB_FT_TS_BASE_MASK)
>> +		>> FUSE_TSENSOR_CALIB_FT_TS_BASE_SHIFT;
> 
> I think it's more canonical to put the >> on the first line line.

Ok, will fix it.

> 
>> +	actual_tsensor_ft = (shared->base_ft * 32) + sign_extend32(val, 12);
>> +
>> +	delta_sens = actual_tsensor_ft - actual_tsensor_cp;
>> +	delta_temp = shared->actual_temp_ft - shared->actual_temp_cp;
>> +
>> +	mult = sensor_group->pdiv * sensor->config->tsample_ate;
>> +	div = sensor->config->tsample * sensor_group->pdiv_ate;
>> +
>> +	therma = div64_s64_precise((s64)delta_temp * (1LL << 13) * mult,
>> +			(s64)delta_sens * div);
> 
> Are the explicit casts necessary? Shouldn't an s32 be automatically
> promoted to s64? Also arguments on subsequent lines should be aligned
> with the first argument on the first line.

I made a mistake, the div64_s64_precise(s64 a, s64 b) should be
div64_s64_precise(s64 a, s32b), so to make the value more precise, I added (s64)
cast in here.
And I will use temporary variable, and align the arguments.

> 
>> +	thermb = div64_s64_precise(
>> +			((s64)actual_tsensor_ft * shared->actual_temp_cp) -
>> +			((s64)actual_tsensor_cp * shared->actual_temp_ft),
>> +			(s64)delta_sens);
> 
> Perhaps add a temporary variable for the first parameter here for
> readability?

Yes, will use temporary variable, and remove the cast for delta_sens.

> 
>> +
>> +	therma = div64_s64_precise((s64)therma * sensor->fuse_corr_alpha,
>> +			(s64)1000000LL);
>> +	thermb = div64_s64_precise((s64)thermb * sensor->fuse_corr_alpha +
>> +			sensor->fuse_corr_beta,
>> +			(s64)1000000LL);
> 
> What are the 1000000LL? Does it perhaps make sense to have a macro for
> it, or perhaps a comment would help.

It's the coefficient data for the therma and thermb. I will use macro for it.
#define CALIB_COEFFICIENT 1000000LL

> 
>> +	calib = ((u16)therma << SENSOR_CONFIG2_THERMA_SHIFT) |
>> +		 ((u16)thermb << SENSOR_CONFIG2_THERMB_SHIFT);
> 
> Alignment here isn't right.

will do it.

> 
>> diff --git a/drivers/thermal/tegra/soctherm.h b/drivers/thermal/tegra/soctherm.h
> [...]
>> +struct tegra_soctherm_soc {
>> +	struct tegra_tsensor *tsensors;
> 
> Can't these be const? Do they ever need to be modified? If so, they
> should probably not be part of this structure. Or at least only part of
> them should be. The invariant part.
> 
> The reason is that if ever a second instance of this device was present
> both instances would share this same data. I know it's unlikely to
> happen, but setting a bad example would be... well... bad.
> 
> Instead I think if you need to have non-const fields you could separate
> this further into struct tegra_tsensor_soc, with only the static
> information about the sensor, and make struct tegra_tsensor contain a
> pointer to that SoC structure and provide the variable fields in
> addition. That way you can create a struct tegra_tsensor for each struct
> tegra_tsensor_soc and store those per-instance.

There has a member "calib" in the tsensors which will be written in the driver,
so I didn't make it as const.
But you are right, I need to consider the risk that the system have two more SOCs.
I will remove the "calib" to struct tegra_soctherm, then can fix this issue, and
can make all data to "const" in the chip-specific file.

> 
>> diff --git a/drivers/thermal/tegra/tegra124-soctherm.c b/drivers/thermal/tegra/tegra124-soctherm.c
> [...]
>> +static struct tegra_tsensor tegra124_tsensors[] = {
> 
> Can this be "static const" instead?

Will fix this one.

> 
>> +	{
>> +		.name = "cpu0",
>> +		.base = 0xc0,
>> +		.config = &t124_tsensor_config,
>> +		.calib_fuse_offset = 0x098,
>> +		.fuse_corr_alpha = 1135400,
>> +		.fuse_corr_beta = -6266900,
>> +		.group = &tegra124_tsensor_group_cpu,
>> +	},
>> +	{
> 
> "}," and "{" can go on the same line.

Got it, will change it.

> 
>> +struct tegra_soctherm_soc tegra124_soctherm = {
> 
> "const"?

Will fix it.

> 
> Thierry
> 
> * Unknown Key
> * 0x7F3EB3A1
> 

WARNING: multiple messages have this Message-ID (diff)
From: Wei Ni <wni@nvidia.com>
To: Thierry Reding <thierry.reding@gmail.com>
Cc: <rui.zhang@intel.com>, <MLongnecker@nvidia.com>,
	<swarren@wwwdotorg.org>, <mikko.perttunen@kapsi.fi>,
	<linux-tegra@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH V3 04/11] thermal: tegra: split tegra_soctherm driver
Date: Fri, 22 Jan 2016 16:52:20 +0800	[thread overview]
Message-ID: <56A1EDC4.6000401@nvidia.com> (raw)
In-Reply-To: <20160121144605.GB32301@ulmo>



On 2016年01月21日 22:46, Thierry Reding wrote:
> * PGP Signed by an unknown key
> 
> On Mon, Jan 18, 2016 at 06:02:29PM +0800, Wei Ni wrote:
> [...]
>> +int tegra_soctherm_calculate_tsensor_calibration(
>> +				struct tegra_tsensor *sensor,
>> +				const struct tsensor_shared_calibration *shared)
> 
> The need to ident weirdly here should be an indication that the function
> name is too long, how about:

Hmm, yes, it's too long.

> 
> int tegra_tsensor_calc_calib(struct tegra_tsensor *sensor,
> 			     const struct tsensor_shared_calibration *shared)
> 
> ?

There have two functions about calibration, I prefer to name them as:
tegra_calc_tsensor_calib() and tegra_calc_shared_calib().

> 
>> +{
>> +	const struct tegra_tsensor_group *sensor_group;
>> +	u32 val, calib;
>> +	s32 actual_tsensor_ft, actual_tsensor_cp;
>> +	s32 delta_sens, delta_temp;
>> +	s32 mult, div;
>> +	s16 therma, thermb;
>> +	int err;
>> +
>> +	sensor_group = sensor->group;
>> +
>> +	err = tegra_fuse_readl(sensor->calib_fuse_offset, &val);
>> +	if (err)
>> +		return err;
>> +
>> +	actual_tsensor_cp = (shared->base_cp * 64) + sign_extend32(val, 12);
>> +	val = (val & FUSE_TSENSOR_CALIB_FT_TS_BASE_MASK)
>> +		>> FUSE_TSENSOR_CALIB_FT_TS_BASE_SHIFT;
> 
> I think it's more canonical to put the >> on the first line line.

Ok, will fix it.

> 
>> +	actual_tsensor_ft = (shared->base_ft * 32) + sign_extend32(val, 12);
>> +
>> +	delta_sens = actual_tsensor_ft - actual_tsensor_cp;
>> +	delta_temp = shared->actual_temp_ft - shared->actual_temp_cp;
>> +
>> +	mult = sensor_group->pdiv * sensor->config->tsample_ate;
>> +	div = sensor->config->tsample * sensor_group->pdiv_ate;
>> +
>> +	therma = div64_s64_precise((s64)delta_temp * (1LL << 13) * mult,
>> +			(s64)delta_sens * div);
> 
> Are the explicit casts necessary? Shouldn't an s32 be automatically
> promoted to s64? Also arguments on subsequent lines should be aligned
> with the first argument on the first line.

I made a mistake, the div64_s64_precise(s64 a, s64 b) should be
div64_s64_precise(s64 a, s32b), so to make the value more precise, I added (s64)
cast in here.
And I will use temporary variable, and align the arguments.

> 
>> +	thermb = div64_s64_precise(
>> +			((s64)actual_tsensor_ft * shared->actual_temp_cp) -
>> +			((s64)actual_tsensor_cp * shared->actual_temp_ft),
>> +			(s64)delta_sens);
> 
> Perhaps add a temporary variable for the first parameter here for
> readability?

Yes, will use temporary variable, and remove the cast for delta_sens.

> 
>> +
>> +	therma = div64_s64_precise((s64)therma * sensor->fuse_corr_alpha,
>> +			(s64)1000000LL);
>> +	thermb = div64_s64_precise((s64)thermb * sensor->fuse_corr_alpha +
>> +			sensor->fuse_corr_beta,
>> +			(s64)1000000LL);
> 
> What are the 1000000LL? Does it perhaps make sense to have a macro for
> it, or perhaps a comment would help.

It's the coefficient data for the therma and thermb. I will use macro for it.
#define CALIB_COEFFICIENT 1000000LL

> 
>> +	calib = ((u16)therma << SENSOR_CONFIG2_THERMA_SHIFT) |
>> +		 ((u16)thermb << SENSOR_CONFIG2_THERMB_SHIFT);
> 
> Alignment here isn't right.

will do it.

> 
>> diff --git a/drivers/thermal/tegra/soctherm.h b/drivers/thermal/tegra/soctherm.h
> [...]
>> +struct tegra_soctherm_soc {
>> +	struct tegra_tsensor *tsensors;
> 
> Can't these be const? Do they ever need to be modified? If so, they
> should probably not be part of this structure. Or at least only part of
> them should be. The invariant part.
> 
> The reason is that if ever a second instance of this device was present
> both instances would share this same data. I know it's unlikely to
> happen, but setting a bad example would be... well... bad.
> 
> Instead I think if you need to have non-const fields you could separate
> this further into struct tegra_tsensor_soc, with only the static
> information about the sensor, and make struct tegra_tsensor contain a
> pointer to that SoC structure and provide the variable fields in
> addition. That way you can create a struct tegra_tsensor for each struct
> tegra_tsensor_soc and store those per-instance.

There has a member "calib" in the tsensors which will be written in the driver,
so I didn't make it as const.
But you are right, I need to consider the risk that the system have two more SOCs.
I will remove the "calib" to struct tegra_soctherm, then can fix this issue, and
can make all data to "const" in the chip-specific file.

> 
>> diff --git a/drivers/thermal/tegra/tegra124-soctherm.c b/drivers/thermal/tegra/tegra124-soctherm.c
> [...]
>> +static struct tegra_tsensor tegra124_tsensors[] = {
> 
> Can this be "static const" instead?

Will fix this one.

> 
>> +	{
>> +		.name = "cpu0",
>> +		.base = 0xc0,
>> +		.config = &t124_tsensor_config,
>> +		.calib_fuse_offset = 0x098,
>> +		.fuse_corr_alpha = 1135400,
>> +		.fuse_corr_beta = -6266900,
>> +		.group = &tegra124_tsensor_group_cpu,
>> +	},
>> +	{
> 
> "}," and "{" can go on the same line.

Got it, will change it.

> 
>> +struct tegra_soctherm_soc tegra124_soctherm = {
> 
> "const"?

Will fix it.

> 
> Thierry
> 
> * Unknown Key
> * 0x7F3EB3A1
> 

  reply	other threads:[~2016-01-22  8:52 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-18 10:02 [PATCH V3 00/11] Add T210 support in Tegra soctherm Wei Ni
2016-01-18 10:02 ` Wei Ni
2016-01-18 10:02 ` [PATCH V3 01/11] thermal: tegra: move tegra thermal files into tegra directory Wei Ni
2016-01-18 10:02   ` Wei Ni
2016-01-18 10:02 ` [PATCH V3 02/11] thermal: tegra: combine sensor group-related data Wei Ni
2016-01-18 10:02   ` Wei Ni
2016-01-18 10:02 ` [PATCH V3 03/11] thermal: tegra: get rid of PDIV/HOTSPOT hack Wei Ni
2016-01-18 10:02   ` Wei Ni
     [not found] ` <1453111356-12298-1-git-send-email-wni-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2016-01-18 10:02   ` [PATCH V3 04/11] thermal: tegra: split tegra_soctherm driver Wei Ni
2016-01-18 10:02     ` Wei Ni
2016-01-21 14:46     ` Thierry Reding
2016-01-22  8:52       ` Wei Ni [this message]
2016-01-22  8:52         ` Wei Ni
2016-01-21 14:56   ` [PATCH V3 00/11] Add T210 support in Tegra soctherm Thierry Reding
2016-01-21 14:56     ` Thierry Reding
2016-01-22  7:27     ` Wei Ni
2016-01-22  7:27       ` Wei Ni

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=56A1EDC4.6000401@nvidia.com \
    --to=wni-ddmlm1+adcrqt0dzr+alfa@public.gmane.org \
    --cc=MLongnecker-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=mikko.perttunen-/1wQRMveznE@public.gmane.org \
    --cc=rui.zhang-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
    --cc=swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org \
    --cc=thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.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.