Re: [PATCH v2 03/10] qcom: spm: Add Subsystem Power Manager (SPM) driver for QCOM chipsets

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



>>> diff --git a/drivers/soc/qcom/spm.c b/drivers/soc/qcom/spm.c
>>> new file mode 100644
>>> index 0000000..7dbdb64
>>> --- /dev/null
>>> +++ b/drivers/soc/qcom/spm.c
>>> @@ -0,0 +1,482 @@
>>> +/* Copyright (c) 2011-2014, The Linux Foundation. All rights reserved.
>>> + *
>>> + * This program is free software; you can redistribute it and/or modify
>>> + * it under the terms of the GNU General Public License version 2 and
>>> + * only version 2 as published by the Free Software Foundation.
>>> + *
>>> + * This program is distributed in the hope that it will be useful,
>>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>>> + * GNU General Public License for more details.
>>> + *
>>> + */
>>> +
>>> +#include <linux/module.h>
>>> +#include <linux/kernel.h>
>>> +#include <linux/delay.h>
>>> +#include <linux/init.h>
>>> +#include <linux/io.h>
>>> +#include <linux/slab.h>
>>> +
>>> +#include "spm_driver.h"
>>> +
>>> +#define MSM_SPM_PMIC_STATE_IDLE  0
>>> +
>>> +enum {
>>> +	MSM_SPM_DEBUG_SHADOW = 1U << 0,
>>> +	MSM_SPM_DEBUG_VCTL = 1U << 1,
>>> +};
>>> +
>>> +static int msm_spm_debug_mask;
>>> +module_param_named(
>>> +	debug_mask, msm_spm_debug_mask, int, S_IRUGO | S_IWUSR | S_IWGRP
>>> +);
>>> +
>>> +struct saw2_data {
>>> +	const char *ver_name;
>>> +	uint32_t major;
>>> +	uint32_t minor;
>>> +	uint32_t *spm_reg_offset_ptr;
>>> +};
>>> +
>>> +static uint32_t msm_spm_reg_offsets_saw2_v2_1[MSM_SPM_REG_NR] = {
>>> +	[MSM_SPM_REG_SAW2_SECURE]		= 0x00,
>>> +	[MSM_SPM_REG_SAW2_ID]			= 0x04,
>>> +	[MSM_SPM_REG_SAW2_CFG]			= 0x08,
>>> +	[MSM_SPM_REG_SAW2_SPM_STS]		= 0x0C,
>>> +	[MSM_SPM_REG_SAW2_AVS_STS]		= 0x10,
>>> +	[MSM_SPM_REG_SAW2_PMIC_STS]		= 0x14,
>>> +	[MSM_SPM_REG_SAW2_RST]			= 0x18,
>>> +	[MSM_SPM_REG_SAW2_VCTL]			= 0x1C,
>>> +	[MSM_SPM_REG_SAW2_AVS_CTL]		= 0x20,
>>> +	[MSM_SPM_REG_SAW2_AVS_LIMIT]		= 0x24,
>>> +	[MSM_SPM_REG_SAW2_AVS_DLY]		= 0x28,
>>> +	[MSM_SPM_REG_SAW2_AVS_HYSTERESIS]	= 0x2C,
>>> +	[MSM_SPM_REG_SAW2_SPM_CTL]		= 0x30,
>>> +	[MSM_SPM_REG_SAW2_SPM_DLY]		= 0x34,
>>> +	[MSM_SPM_REG_SAW2_PMIC_DATA_0]		= 0x40,
>>> +	[MSM_SPM_REG_SAW2_PMIC_DATA_1]		= 0x44,
>>> +	[MSM_SPM_REG_SAW2_PMIC_DATA_2]		= 0x48,
>>> +	[MSM_SPM_REG_SAW2_PMIC_DATA_3]		= 0x4C,
>>> +	[MSM_SPM_REG_SAW2_PMIC_DATA_4]		= 0x50,
>>> +	[MSM_SPM_REG_SAW2_PMIC_DATA_5]		= 0x54,
>>> +	[MSM_SPM_REG_SAW2_PMIC_DATA_6]		= 0x58,
>>> +	[MSM_SPM_REG_SAW2_PMIC_DATA_7]		= 0x5C,
>>> +	[MSM_SPM_REG_SAW2_SEQ_ENTRY]		= 0x80,
>>> +	[MSM_SPM_REG_SAW2_VERSION]		= 0xFD0,
>>> +};
>>> +
>>> +static uint32_t msm_spm_reg_offsets_saw2_v3_0[MSM_SPM_REG_NR] = {
>>> +	[MSM_SPM_REG_SAW2_SECURE]		= 0x00,
>>> +	[MSM_SPM_REG_SAW2_ID]			= 0x04,
>>> +	[MSM_SPM_REG_SAW2_CFG]			= 0x08,
>>> +	[MSM_SPM_REG_SAW2_SPM_STS]		= 0x0C,
>>> +	[MSM_SPM_REG_SAW2_AVS_STS]		= 0x10,
>>> +	[MSM_SPM_REG_SAW2_PMIC_STS]		= 0x14,
>>> +	[MSM_SPM_REG_SAW2_RST]			= 0x18,
>>> +	[MSM_SPM_REG_SAW2_VCTL]			= 0x1C,
>>> +	[MSM_SPM_REG_SAW2_AVS_CTL]		= 0x20,
>>> +	[MSM_SPM_REG_SAW2_AVS_LIMIT]		= 0x24,
>>> +	[MSM_SPM_REG_SAW2_AVS_DLY]		= 0x28,
>>> +	[MSM_SPM_REG_SAW2_AVS_HYSTERESIS]	= 0x2C,
>>> +	[MSM_SPM_REG_SAW2_SPM_CTL]		= 0x30,
>>> +	[MSM_SPM_REG_SAW2_SPM_DLY]		= 0x34,
>>> +	[MSM_SPM_REG_SAW2_STS2]			= 0x38,
>>> +	[MSM_SPM_REG_SAW2_PMIC_DATA_0]		= 0x40,
>>> +	[MSM_SPM_REG_SAW2_PMIC_DATA_1]		= 0x44,
>>> +	[MSM_SPM_REG_SAW2_PMIC_DATA_2]		= 0x48,
>>> +	[MSM_SPM_REG_SAW2_PMIC_DATA_3]		= 0x4C,
>>> +	[MSM_SPM_REG_SAW2_PMIC_DATA_4]		= 0x50,
>>> +	[MSM_SPM_REG_SAW2_PMIC_DATA_5]		= 0x54,
>>> +	[MSM_SPM_REG_SAW2_PMIC_DATA_6]		= 0x58,
>>> +	[MSM_SPM_REG_SAW2_PMIC_DATA_7]		= 0x5C,
>>> +	[MSM_SPM_REG_SAW2_SEQ_ENTRY]		= 0x400,
>>> +	[MSM_SPM_REG_SAW2_VERSION]		= 0xFD0,
>>> +};
>> 
>> I don’t see what having these arrays provides as the only differences are that v3.0 has MSM_SPM_REG_SAW2_STS2 and the offset of MSM_SPM_REG_SAW2_SEQ_ENTRY.  If so we can remove all this extra code and just add a simple check in msm_spm_drv_flush_seq_entry that looks at the compatible and picks the proper offset when updating MSM_SPM_REG_SAW2_SEQ_ENTRY.
>> 
> Isnt that an hack ?

Why would it be a hack, if the only difference in the driver can be reduced down to 5 lines of code, versus what is currently there I don’t see that as a hack at all.

[ snip ]

>>> diff --git a/include/soc/qcom/spm.h b/include/soc/qcom/spm.h
>>> new file mode 100644
>>> index 0000000..f39e0c4
>>> --- /dev/null
>>> +++ b/include/soc/qcom/spm.h
>>> @@ -0,0 +1,70 @@
>>> +/* Copyright (c) 2010-2014, The Linux Foundation. All rights reserved.
>>> + *
>>> + * This program is free software; you can redistribute it and/or modify
>>> + * it under the terms of the GNU General Public License version 2 and
>>> + * only version 2 as published by the Free Software Foundation.
>>> + *
>>> + * This program is distributed in the hope that it will be useful,
>>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>>> + * GNU General Public License for more details.
>>> + */
>>> +
>>> +#ifndef __QCOM_SPM_H
>>> +#define __QCOM_SPM_H
>>> +
>>> +enum {
>>> +	MSM_SPM_MODE_DISABLED,
>>> +	MSM_SPM_MODE_CLOCK_GATING,
>>> +	MSM_SPM_MODE_RETENTION,
>>> +	MSM_SPM_MODE_GDHS,
>>> +	MSM_SPM_MODE_POWER_COLLAPSE,
>>> +	MSM_SPM_MODE_NR
>>> +};
>>> +
>>> +struct msm_spm_device;
>>> +
>>> +#if defined(CONFIG_QCOM_PM)
>> 
>> Where is CONFIG_QCOM_PM defined?  Wondering if we should have a CONFIG_QCOM_SPM and it can depend on any future ‘QCOM_PM’ in the Kconfig.
> In the following patch that introduces SoC interface layer (msm-pm.c).
> I will restructure the patches and blend in QCOM_PM as part of this
> driver. So this driver may be compiled in. But it may not be of much use
> until msm-pm.c comes along.

Yeah, is probably best to at least introduce CONFIG_QCOM_PM with this patch so the driver can be built, even if it doesn’t really do much but initialize.

[ snip ]

- k

-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [Linux for Sparc]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux