On Wed, Jan 13, 2016 at 03:58:41PM +0800, Wei Ni wrote:
> Combine sensor group-related data structures into struct
> tegra_tsensor_group. This provides a single location for
> sensor group data storage.
> More sensor group data will be added in subsequent patches.
>
> Get rid of T124-specific PDIV/HOTSPOT hack.
> tegra-soctherm.c contained a hack to set the SENSOR_PDIV and
> SENSOR_HOTSPOT_OFFSET registers - it just did two writes of
> T124-specific opaque values. Convert these into a form that can be
> substituted on a per-chip basis, and into structure fields that have
> at least some independent meaning.
This reads as two completely separate commit messages. Should the patch
be split up to separate out the two logical changes?
> diff --git a/drivers/thermal/tegra/tegra_soctherm.c b/drivers/thermal/tegra/tegra_soctherm.c
[...]
> +static struct tegra_tsensor_group tegra124_tsensor_group_cpu = {
[...]
> +};
> +
> +static struct tegra_tsensor_group tegra124_tsensor_group_gpu = {
[...]
> +};
> +
> +static struct tegra_tsensor_group tegra124_tsensor_group_pll = {
[...]
> +};
> +
> +static struct tegra_tsensor_group tegra124_tsensor_group_mem = {
[...]
> +};
> +
> +static struct tegra_tsensor_group *
> +tegra124_tsensor_groups[TEGRA124_SOCTHERM_SENSOR_NUM] = {
[...]
> };
These look like they should all be static const.
> @@ -168,7 +268,7 @@ struct tegra_soctherm {
> struct clk *clock_soctherm;
> void __iomem *regs;
>
> - struct thermal_zone_device *thermctl_tzs[4];
> + struct thermal_zone_device *thermctl_tzs[TEGRA124_SOCTHERM_SENSOR_NUM];
> };
Does it make sense to use macros here for the number of zones? I suspect
that since you do parameterize the Tegra210 support that will be added
later on will have a different maximum number, in which case macros will
not work very well.
But perhaps I'll see how you solved that problem in a later patch.
Thierry
Attachment:
signature.asc
Description: PGP signature
