RE: [GIT PULL 2/2] Samsung defconfig updates for v3.18
Sjoerd Simons wrote: > > On Tue, 2014-10-14 at 23:32 -0700, Olof Johansson wrote: > > On Tue, Oct 14, 2014 at 4:27 PM, Kukjin Kim wrote: > > > git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git > > > tags/samsung-defconfig > > > > > > for you to fetch changes up to 508423bebcda29eb0ba7c627f895387dad7cdcd6: > > > > > > ARM: exynos_defconfig: enable USB gadget support (2014-09-25 18:20:18 > > > +0900) > > > > Merged, thanks. > > Hrm, enabling USB gadget support will actually regress USB on Exynos > peach boards and Arndale Octa without some of the DT fixes that landed > in armsoc next/late branch. Specifically: > > 5c42acdb9bab595482b966b22ab5e2f6f359 > dbb62ef9ade6e92737d3fac199665b8b7c455959 > Yeah...I've missed it. Sorry. > Might be good to cherry-pick those into for-next at this point (they're > rather trivial) > So...Olof, can you please cherry pick them into arm-soc/fixes? Or shall I send pull-request for them again? - Kukjin -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] ARM: EXYNOS: Call regulator core suspend prepare and finish functions
Hello Doug,
Thanks a lot for your feedback.
On 10/15/2014 06:19 PM, Doug Anderson wrote:
> Javier,
>
> On Wed, Oct 15, 2014 at 5:01 AM, Javier Martinez Canillas
> wrote:
>> The regulator framework has a set of helpers functions to be used when
>> the system is entering and leaving from suspend but these are not called
>> on Exynos platforms. This means that the .set_suspend_* function handlers
>> defined in regulator drivers are never called when the system is suspended.
>>
>> Suggested-by: Doug Anderson
>> Signed-off-by: Javier Martinez Canillas
>
> Could you also add a patch to your series ripping out the call in
> "drivers/mfd/sec-core.c" since it doesn't belong there. If you don't
> rip that out then it will be called twice on systems with that
> regulator.
>
Sure, in fact I thought the same before sending $subject but didn't remove it
because mfd sec-core only calls regulator_suspend_prepare() but does not call
regulator_suspend_finish() on resume. So I wondered if $subject would not break
it anyways since it may change the driver assumption that the regulators .enable
function won't be called on resume. That's why I added Chanwoo Choi to the cc
list so he can be aware of this change and give his opinion is on that regard.
I should had commented that on the patch...
>
>> ---
>> arch/arm/mach-exynos/suspend.c | 16
>> 1 file changed, 16 insertions(+)
>>
>> diff --git a/arch/arm/mach-exynos/suspend.c b/arch/arm/mach-exynos/suspend.c
>> index f5d9773..5b9c551 100644
>> --- a/arch/arm/mach-exynos/suspend.c
>> +++ b/arch/arm/mach-exynos/suspend.c
>> @@ -20,6 +20,7 @@
>> #include
>> #include
>> #include
>> +#include
>>
>> #include
>> #include
>> @@ -270,14 +271,29 @@ static int exynos_suspend_enter(suspend_state_t state)
>>
>> static int exynos_suspend_prepare(void)
>> {
>> + int ret;
>> +
>> s3c_pm_check_prepare();
>>
>> + /*
>> +* REVISIT: It would be better if struct platform_suspend_ops
>> +* .prepare handler get the suspend_state_t as a parameter to
>> +* avoid hard-coding the suspend to mem state. It's safe to do
>> +* it only because the suspend_valid_only_mem function is the
>> +* .valid callback used to check if a given state is supported
>> +* by the platform.
>> +*/
>> + ret = regulator_suspend_prepare(PM_SUSPEND_MEM);
>> + if (ret)
>> + pr_info("Failed to prepare regulators for system suspend\n");
>> +
>
> nit: can you put this before s3c_pm_check_prepare(). pm_check is
> pretty darn broken and I have a feeling that it will eventually be
> ripped out (or in the very least ported to not be Samsung-specific and
> include all of the "suspend volatile" crud that we have in the
> chromeos-3.8 kernel), but might as well try not to break it further.
>
> Changing the order also has the advantage of making prepare / finish
> opposite orders (good!) and handling the fact that you would call
> s3c_pm_check_prepare() but not s3c_pm_check_cleanup() if
> regulator_suspend_prepare() fails.
>
Good point, I'll change that on v2. I'll wait until tomorrow to see if there
are more comments and re-post with your suggestions.
>
>> return 0;
>> }
>>
>> static void exynos_suspend_finish(void)
>> {
>> s3c_pm_check_cleanup();
>> + regulator_suspend_finish();
>> }
>>
>> static const struct platform_suspend_ops exynos_suspend_ops = {
Best regards,
Javier
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/9] regulator: max77802: Add .{get,set}_mode callbacks
Some max77802 LDOs (1, 3, 20 and 21) support to be configured in Low
Power Mode during system normal operation. Add function handlers for
the .get_mode and .set_mode operations to set the mode on these LDOs.
Signed-off-by: Javier Martinez Canillas
---
drivers/regulator/max77802.c | 44
1 file changed, 44 insertions(+)
diff --git a/drivers/regulator/max77802.c b/drivers/regulator/max77802.c
index 26f6963..baf834d 100644
--- a/drivers/regulator/max77802.c
+++ b/drivers/regulator/max77802.c
@@ -51,6 +51,9 @@
#define MAX77802_OFF_PWRREQ0x1
+#define MAX77802_MODE(pval) ((pval == MAX77802_OPMODE_NORMAL) ?\
+REGULATOR_MODE_NORMAL : REGULATOR_MODE_STANDBY)
+
/* MAX77802 has two register formats: 2-bit and 4-bit */
static const unsigned int ramp_table_77802_2bit[] = {
12500,
@@ -105,6 +108,45 @@ static int max77802_set_suspend_disable(struct
regulator_dev *rdev)
}
/*
+ * Some LDOs support Low Power Mode while the system is running.
+ *
+ * LDOs 1, 3, 20, 21.
+ */
+static int max77802_set_mode(struct regulator_dev *rdev, unsigned int mode)
+{
+ struct max77802_regulator_prv *max77802 = rdev_get_drvdata(rdev);
+ int id = rdev_get_id(rdev);
+ unsigned int val;
+ int shift = max77802_get_opmode_shift(id);
+
+ switch (mode) {
+ case REGULATOR_MODE_IDLE:
+ case REGULATOR_MODE_STANDBY:
+ val = MAX77802_OPMODE_LP; /* ON in Low Power Mode */
+ break;
+ case REGULATOR_MODE_NORMAL:
+ val = MAX77802_OPMODE_NORMAL; /* ON in Normal Mode */
+ break;
+ default:
+ dev_warn(&rdev->dev, "%s: regulator mode: 0x%x not supported\n",
+rdev->desc->name, mode);
+ return -EINVAL;
+ }
+
+ max77802->opmode[id] = val;
+ return regmap_update_bits(rdev->regmap, rdev->desc->enable_reg,
+ rdev->desc->enable_mask, val << shift);
+}
+
+static unsigned max77802_get_mode(struct regulator_dev *rdev)
+{
+ struct max77802_regulator_prv *max77802 = rdev_get_drvdata(rdev);
+ int id = rdev_get_id(rdev);
+
+ return MAX77802_MODE(max77802->opmode[id]);
+}
+
+/*
* Some LDOs supports LPM-ON/OFF/Normal-ON mode during suspend state
* (Enable Control Logic1 by PWRREQ)
*
@@ -268,6 +310,8 @@ static struct regulator_ops max77802_ldo_ops_logic2 = {
.get_voltage_sel= regulator_get_voltage_sel_regmap,
.set_voltage_sel= regulator_set_voltage_sel_regmap,
.set_voltage_time_sel = regulator_set_voltage_time_sel,
+ .set_mode = max77802_set_mode,
+ .get_mode = max77802_get_mode,
.set_suspend_mode = max77802_ldo_set_suspend_mode_logic2,
};
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/9] regulator: max77802: Split regulator operations for BUCKs
Not all the max77802 BUCKs regulators have the same functionality, for
example BUCKs 2-4 support the output to be configured as normal or Low
Power Mode by the PWRREQ enable pin while the other BUCKs only support
their output to be set ON or OFF by PWRREQ. As a preparation for adding
a set_suspend_mode function handler for all the regulators that support
Low Power Mode by PWRREQ, split the operations for BUCKs regulators.
Signed-off-by: Javier Martinez Canillas
---
drivers/regulator/max77802.c | 19 +--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/drivers/regulator/max77802.c b/drivers/regulator/max77802.c
index baf834d..a621700 100644
--- a/drivers/regulator/max77802.c
+++ b/drivers/regulator/max77802.c
@@ -330,7 +330,22 @@ static struct regulator_ops max77802_buck_16_dvs_ops = {
.set_suspend_disable= max77802_set_suspend_disable,
};
-/* BUCKs 2-4, 5, 7-10 */
+/* BUCKs 2-4 */
+static struct regulator_ops max77802_buck_234_ops = {
+ .list_voltage = regulator_list_voltage_linear,
+ .map_voltage= regulator_map_voltage_linear,
+ .is_enabled = regulator_is_enabled_regmap,
+ .enable = max77802_enable,
+ .disable= regulator_disable_regmap,
+ .get_voltage_sel= regulator_get_voltage_sel_regmap,
+ .set_voltage_sel= regulator_set_voltage_sel_regmap,
+ .set_voltage_time_sel = regulator_set_voltage_time_sel,
+ .set_ramp_delay = max77802_set_ramp_delay_2bit,
+ .set_suspend_enable = max77802_enable,
+ .set_suspend_disable= max77802_set_suspend_disable,
+};
+
+/* BUCKs 5, 7-10 */
static struct regulator_ops max77802_buck_dvs_ops = {
.list_voltage = regulator_list_voltage_linear,
.map_voltage= regulator_map_voltage_linear,
@@ -404,7 +419,7 @@ static struct regulator_ops max77802_buck_dvs_ops = {
.name = "BUCK"#num, \
.id = MAX77802_BUCK##num, \
.supply_name= "inb"#num,\
- .ops= &max77802_buck_dvs_ops, \
+ .ops= &max77802_buck_234_ops, \
.type = REGULATOR_VOLTAGE,\
.owner = THIS_MODULE, \
.min_uV = 60, \
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/9] Add max77802 regulator operating mode support
Hello Mark,
This is the second attempt to add operating modes support for the
regulators in the max77802 PMIC. Instead of trying to come up with
a generic solution like in the previous attempt [0], I added DT
properties that are specific to the max77802 PMIC so is documented
clearly what are the operating modes that each regulator support. The
series version is not v2 because it's a completely different approach.
There is a "maxim,regulator-initial-mode" property to configure at
startup the operating mode for the regulators that support changing
its mode during normal operation and "maxim,regulator-{disk,mem}-mode"
properties for the regulators that only support changing its operating
mode when the system enters in a suspend state.
The regulators can be enabled or disabled during suspend by using the
standard "regulator-{on,off}-in-suspend" properties from Chanwoo Choi's
regulator suspend state series [1].
I tried to use as much as possible the infrastructure that is already
provided in the regulator framework by adding the needed handlers for
the set_suspend_* operations.
Also, the driver still had some assumptions and didn't clearly made a
distinction between the valid modes (normal and low power) and off which
is not an operating mode as you explained. So I reworked a bit to better
treat them separately as is expected by the regulator API.
This series depend on [1] and also patch:
"ARM: EXYNOS: Call regulator core suspend prepare and finish functions" [2].
Javier Martinez Canillas (9):
regulator: max77802: Add .set_suspend_{enable,disable} callbacks
regulator: max77802: Add .{get,set}_mode callbacks
regulator: max77802: Split regulator operations for BUCKs
regulator: max77802: Add set suspend mode for BUCKs and simplify code
regulator: max77802: Don't treat OFF as an operating mode
regulator: max77802: Add header for operating modes
regulator: max77802: Document regulator opmode DT properties
regulator: max77802: Parse regulator operating mode properties
ARM: dts: Configure regulators for suspend on exynos Peach boards
.../devicetree/bindings/regulator/max77802.txt | 45 ++
arch/arm/boot/dts/exynos5420-peach-pit.dts | 81 ++
arch/arm/boot/dts/exynos5800-peach-pi.dts | 81 ++
drivers/regulator/max77802.c | 168 -
include/dt-bindings/regulator/maxim,max77802.h | 18 +++
include/linux/mfd/max77686.h | 7 -
6 files changed, 353 insertions(+), 47 deletions(-)
create mode 100644 include/dt-bindings/regulator/maxim,max77802.h
Patch #1 adds handlers for all regulators that can be enabled and disabled
during suspend
Patch #2 adds a get and set mode function handlers for the regulators whose
operating mode can be changed at runtime.
Patch #3 split the regulator operations for the BUCK regulators since don't
have the exact functionality.
Patch #4 add support for changing the operating mode for all regulators that
support setting a different opmode during suspend.
Patch #5 is a cleanup to not call OFF an operating mode.
Patch #6 adds a header file with the valid operating modes so it can be used
by Device Tree source files.
Patch #7 extend the max77802 DT binding to include the properties used to
setup the regulators modes.
Patch #8 adds the support to parse these from the driver.
Patch #9 configures the modes for the max77802 regulators in the Device Tree
source file of the Peach Chromebooks.
Best regards,
Javier
[0]: https://lkml.org/lkml/2014/10/8/331
[1]: https://lkml.org/lkml/2014/10/10/161
[2]: https://lkml.org/lkml/2014/10/15/228
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/9] regulator: max77802: Add .set_suspend_{enable,disable} callbacks
The max77802 PMIC has an enable pin (PWRREQ) that can be used to switch
regulators ON and OFF automatically by the Application Processor when
the system is leaving and entering sleep mode.
Only the BUCKs regulators had a .set_suspend_disable function handler
that used the enable pin to turn OFF the regulators during suspend.
But most LDOs also support that functionality (besides 1, 3, 20 and 21)
so rename the function to a more generic name and use the same function
for the LDOs. Also add a .set_suspend_enable handler for all regulators
and use the same function used for the .enable operation.
Finally, don't treat output ON/OFF controlled by PWRREQ as an operating
mode using the ambiguous MAX77802_OPMODE_STANDBY since it's not an opmode.
Instead make it clear that is a control value to switch the regulator OFF
by PWRREQ when the system is entering in a suspend state.
Signed-off-by: Javier Martinez Canillas
---
drivers/regulator/max77802.c | 28 ++--
1 file changed, 18 insertions(+), 10 deletions(-)
diff --git a/drivers/regulator/max77802.c b/drivers/regulator/max77802.c
index d89792b..26f6963 100644
--- a/drivers/regulator/max77802.c
+++ b/drivers/regulator/max77802.c
@@ -49,6 +49,8 @@
#define MAX77802_RAMP_RATE_MASK_4BIT 0xF0
#define MAX77802_RAMP_RATE_SHIFT_4BIT 4
+#define MAX77802_OFF_PWRREQ0x1
+
/* MAX77802 has two register formats: 2-bit and 4-bit */
static const unsigned int ramp_table_77802_2bit[] = {
12500,
@@ -83,17 +85,16 @@ static int max77802_get_opmode_shift(int id)
return -EINVAL;
}
-/*
- * Some BUCKS supports Normal[ON/OFF] mode during suspend
+/**
+ * max77802_set_suspend_disable - Disable the regulator during system suspend
+ * @rdev: regulator to mark as disabled
*
- * BUCK 1, 6, 2-4, 5, 7-10 (all)
- *
- * The other mode (0x02) will make PWRREQ switch between normal
- * and low power.
+ * All regulators expect LDO 1, 3, 20 and 21 support OFF by PWRREQ.
+ * Configure the regulator so the PMIC will turn it OFF during system suspend.
*/
-static int max77802_buck_set_suspend_disable(struct regulator_dev *rdev)
+static int max77802_set_suspend_disable(struct regulator_dev *rdev)
{
- unsigned int val = MAX77802_OPMODE_STANDBY;
+ unsigned int val = MAX77802_OFF_PWRREQ;
struct max77802_regulator_prv *max77802 = rdev_get_drvdata(rdev);
int id = rdev_get_id(rdev);
int shift = max77802_get_opmode_shift(id);
@@ -178,6 +179,9 @@ static int max77802_enable(struct regulator_dev *rdev)
int id = rdev_get_id(rdev);
int shift = max77802_get_opmode_shift(id);
+ if (max77802->opmode[id] == MAX77802_OFF_PWRREQ)
+ max77802->opmode[id] = MAX77802_OPMODE_NORMAL;
+
return regmap_update_bits(rdev->regmap, rdev->desc->enable_reg,
rdev->desc->enable_mask,
max77802->opmode[id] << shift);
@@ -247,6 +251,8 @@ static struct regulator_ops max77802_ldo_ops_logic1 = {
.get_voltage_sel= regulator_get_voltage_sel_regmap,
.set_voltage_sel= regulator_set_voltage_sel_regmap,
.set_voltage_time_sel = regulator_set_voltage_time_sel,
+ .set_suspend_enable = max77802_enable,
+ .set_suspend_disable= max77802_set_suspend_disable,
.set_suspend_mode = max77802_ldo_set_suspend_mode_logic1,
};
@@ -276,7 +282,8 @@ static struct regulator_ops max77802_buck_16_dvs_ops = {
.set_voltage_sel= regulator_set_voltage_sel_regmap,
.set_voltage_time_sel = regulator_set_voltage_time_sel,
.set_ramp_delay = max77802_set_ramp_delay_4bit,
- .set_suspend_disable= max77802_buck_set_suspend_disable,
+ .set_suspend_enable = max77802_enable,
+ .set_suspend_disable= max77802_set_suspend_disable,
};
/* BUCKs 2-4, 5, 7-10 */
@@ -290,7 +297,8 @@ static struct regulator_ops max77802_buck_dvs_ops = {
.set_voltage_sel= regulator_set_voltage_sel_regmap,
.set_voltage_time_sel = regulator_set_voltage_time_sel,
.set_ramp_delay = max77802_set_ramp_delay_2bit,
- .set_suspend_disable= max77802_buck_set_suspend_disable,
+ .set_suspend_enable = max77802_enable,
+ .set_suspend_disable= max77802_set_suspend_disable,
};
/* LDOs 3-7, 9-14, 18-26, 28, 29, 32-34 */
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/9] regulator: max77802: Don't treat OFF as an operating mode
The only operating modes that are supported by the regulators in the max77802 PMIC are Output ON (normal) and Output On in Low Power Mode. OFF was wrongly counted as an operating mode while is only a regulator status. Make clear in the code that OFF is not an operating mode. Signed-off-by: Javier Martinez Canillas --- drivers/regulator/max77802.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/regulator/max77802.c b/drivers/regulator/max77802.c index 150eb3a..046b9b7 100644 --- a/drivers/regulator/max77802.c +++ b/drivers/regulator/max77802.c @@ -49,6 +49,7 @@ #define MAX77802_RAMP_RATE_MASK_4BIT 0xF0 #define MAX77802_RAMP_RATE_SHIFT_4BIT 4 +#define MAX77802_STATUS_OFF0x0 #define MAX77802_OFF_PWRREQ0x1 #define MAX77802_LP_PWRREQ 0x2 @@ -614,7 +615,7 @@ static int max77802_pmic_probe(struct platform_device *pdev) * the hardware reports OFF as the regulator operating mode. * Default to operating mode NORMAL in that case. */ - if (val == MAX77802_OPMODE_OFF) + if (val == MAX77802_STATUS_OFF) max77802->opmode[id] = MAX77802_OPMODE_NORMAL; else max77802->opmode[id] = val; -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/9] regulator: max77802: Add set suspend mode for BUCKs and simplify code
The max77802 PMIC has a special enable pin (PWRREQ) that can be used
by the Application Processor (AP) to power down and up voltage rails.
The max77802 PMIC regulators have 3 different enable control logics.
Some regulators support to be configured on different operational mode
during normal operation while others only support to be put in a Low
Power Mode while the system has entered in sleep mode. Some regulators
don't even support that configuration. The logics are the following:
Enable Control Logic1 by PWRREQ (BUCK 2-4, LDO2, LDO4-19, LDO22, LDO35)
---
0: Output OFF
1: Output ON/OFF (Controlled by PWRREQ)
PWRREQ = HIGH (1): Output ON in Normal Mode
PWRREQ = LOW (0): Output OFF
2: Output On with Low Power Mode (Controlled by PWRREQ)
PWRREQ = HIGH (1) : Output ON in Normal Mode
PWRREQ = LOW (0): Output ON in Low Power Mode
3: Output ON in Normal Mode
Enable Control Logic2 by PWRREQ (LDO1, LDO20, LDO21)
---
0: Output ON/OFF by ENx
1: Output ON in Low Power Mode
2: Output ON in Low Power Mode (Controlled by PWRREQ)
PWRREQ = HIGH (1): Output ON in Normal Mode
PWRREQ = LOW (0): Output ON in Low Power Mode
3: Output ON in Normal Mode
Enable Control Logic3 by PWRREQ (LDO3)
---
0 or 3: Output ON in Normal Mode
1: Output ON in Low Power Mode
2: Output ON in Low Power Mode (Controlled by PWRREQ)
PWRREQ = HIGH (1): Output ON in Normal Mode
PWRREQ = LOW (0): Output ON in Low Power Mode
The driver only implemented .set_suspend_mode for the LDOs regulators
but some BUCKs also support to be put in Low Power Mode on system wide
suspend so they should be supported as well. Two different functions
were used for the logic 1 and 2 but this is not necessary.
Only normal and Low Power Mode are valid operational modes, OFF is not
an mode but is a regulator state that is handled by .set_suspend_enable
ad .set_suspend_disable. So the same .set_suspend_mode function can be
used by all the regulators that support Output On with Low Power Mode
by PWRREQ, making much simpler the code to set the suspend mode.
Signed-off-by: Javier Martinez Canillas
---
drivers/regulator/max77802.c | 94 ++--
1 file changed, 47 insertions(+), 47 deletions(-)
diff --git a/drivers/regulator/max77802.c b/drivers/regulator/max77802.c
index a621700..150eb3a 100644
--- a/drivers/regulator/max77802.c
+++ b/drivers/regulator/max77802.c
@@ -50,6 +50,7 @@
#define MAX77802_RAMP_RATE_SHIFT_4BIT 4
#define MAX77802_OFF_PWRREQ0x1
+#define MAX77802_LP_PWRREQ 0x2
#define MAX77802_MODE(pval) ((pval == MAX77802_OPMODE_NORMAL) ?\
REGULATOR_MODE_NORMAL : REGULATOR_MODE_STANDBY)
@@ -146,71 +147,69 @@ static unsigned max77802_get_mode(struct regulator_dev
*rdev)
return MAX77802_MODE(max77802->opmode[id]);
}
-/*
- * Some LDOs supports LPM-ON/OFF/Normal-ON mode during suspend state
- * (Enable Control Logic1 by PWRREQ)
+/**
+ * max77802_set_suspend_mode - set regulator opmode when the system is
suspended
+ * @rdev: regulator to change mode
+ * @mode: operating mode to be set
+ *
+ * Will set the operating mode for the regulators during system suspend.
+ * This function is valid for the three different enable control logics:
*
- * LDOs 2, 4-19, 22-35.
+ * Enable Control Logic1 by PWRREQ (BUCK 2-4 and LDOs 2, 4-19, 22-35)
+ * Enable Control Logic2 by PWRREQ (LDOs 1, 20, 21)
+ * Enable Control Logic3 by PWRREQ (LDO 3)
*
+ * If setting the regulator mode fails, the function only warns but does
+ * not return an error code to avoid the regulator core to stop setting
+ * the operating mode for the remaining regulators.
*/
-static int max77802_ldo_set_suspend_mode_logic1(struct regulator_dev *rdev,
- unsigned int mode)
+static int max77802_set_suspend_mode(struct regulator_dev *rdev,
+unsigned int mode)
{
struct max77802_regulator_prv *max77802 = rdev_get_drvdata(rdev);
int id = rdev_get_id(rdev);
unsigned int val;
int shift = max77802_get_opmode_shift(id);
- switch (mode) {
- case REGULATOR_MODE_IDLE: /* ON in LP Mode */
- val = MAX77802_OPMODE_LP;
- break;
- case REGULATOR_MODE_NORMAL: /* ON in Normal Mode */
- val = MAX77802_OPMODE_NORMAL;
- break;
- case REGULATOR_MODE_STANDBY:/* ON/OFF by PWRREQ */
- val = MAX77802_OPMODE_STANDBY;
- break;
- default:
- dev_warn(&rdev->dev, "%s: regulator mode: 0x%x not supported\n",
+ /*
+* If the regulator has been disabled for suspend
+* then is invalid to try setting a suspend mode.
+*/
+ if (!max77802->opmode[id] == MAX77802_OFF_PWRREQ) {
+
[PATCH 6/9] regulator: max77802: Add header for operating modes
Add a header file for the max77802 constants that could be shared between
the regulator driver and Device Tree source files. Also, remove standby
and off opmodes since only normal and low power are valid operating modes.
Signed-off-by: Javier Martinez Canillas
---
drivers/regulator/max77802.c | 1 +
include/dt-bindings/regulator/maxim,max77802.h | 18 ++
include/linux/mfd/max77686.h | 7 ---
3 files changed, 19 insertions(+), 7 deletions(-)
create mode 100644 include/dt-bindings/regulator/maxim,max77802.h
diff --git a/drivers/regulator/max77802.c b/drivers/regulator/max77802.c
index 046b9b7..43e34dd 100644
--- a/drivers/regulator/max77802.c
+++ b/drivers/regulator/max77802.c
@@ -33,6 +33,7 @@
#include
#include
#include
+#include
/* Default ramp delay in case it is not manually set */
#define MAX77802_RAMP_DELAY10 /* uV/us */
diff --git a/include/dt-bindings/regulator/maxim,max77802.h
b/include/dt-bindings/regulator/maxim,max77802.h
new file mode 100644
index 000..cf28631
--- /dev/null
+++ b/include/dt-bindings/regulator/maxim,max77802.h
@@ -0,0 +1,18 @@
+/*
+ * Copyright (C) 2014 Google, Inc
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * Device Tree binding constants for the Maxim 77802 PMIC regulators
+ */
+
+#ifndef _DT_BINDINGS_REGULATOR_MAXIM_MAX77802_H
+#define _DT_BINDINGS_REGULATOR_MAXIM_MAX77802_H
+
+/* Regulator operating modes */
+#define MAX77802_OPMODE_LP 1
+#define MAX77802_OPMODE_NORMAL 3
+
+#endif /* _DT_BINDINGS_REGULATOR_MAXIM_MAX77802_H */
diff --git a/include/linux/mfd/max77686.h b/include/linux/mfd/max77686.h
index 7e6dc4b..553f7d0 100644
--- a/include/linux/mfd/max77686.h
+++ b/include/linux/mfd/max77686.h
@@ -131,13 +131,6 @@ enum max77686_opmode {
MAX77686_OPMODE_STANDBY,
};
-enum max77802_opmode {
- MAX77802_OPMODE_OFF,
- MAX77802_OPMODE_STANDBY,
- MAX77802_OPMODE_LP,
- MAX77802_OPMODE_NORMAL,
-};
-
struct max77686_opmode_data {
int id;
int mode;
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 7/9] regulator: max77802: Document regulator opmode DT properties
Some regulators from the max77802 PMIC support to be configured in one
of two operating mode: Output ON (normal) and Output On Low Power Mode.
Not all regulators support these two modes and for some of them, the
mode can be changed while the system is running in normal operation
while others only support their mode to be changed on system suspend.
Extend the max77802 PMIC binding adding Device Tree properties so the
regulators operating modes can be configured.
Signed-off-by: Javier Martinez Canillas
---
.../devicetree/bindings/regulator/max77802.txt | 45 ++
1 file changed, 45 insertions(+)
diff --git a/Documentation/devicetree/bindings/regulator/max77802.txt
b/Documentation/devicetree/bindings/regulator/max77802.txt
index 5aeaffc..34812e0 100644
--- a/Documentation/devicetree/bindings/regulator/max77802.txt
+++ b/Documentation/devicetree/bindings/regulator/max77802.txt
@@ -25,6 +25,39 @@ with their hardware counterparts as follow. The valid names
are:
example: LDO1, LDO2, LDO35.
-BUCKn : for BUCKs, where n can lie in range 1 to 10.
example: BUCK1, BUCK5, BUCK10.
+
+Besides the standard regulator constraints, the max77802 regulator supports
+two different operating modes: Normal and Low Power Mode. Some regulators
+support the modes to be changed at startup or by the consumers during normal
+operation while others only support to change the mode during system suspend.
+The following optional properties can be used to configure the operating modes:
+
+- maxim,regulator-initial-mode: initial operating mode.
+ This property can only be used on regulators that support changing their mode
+ during normal operation. These regulators are LDO1, LDO3, LDO20 and LDO21.
+- maxim,regulator-disk-mode: operating mode for the regulator when the system
+ enters in the Suspend-to-Disk state.
+- maxim,regulator-mem-mode: operating mode for the regulator when the system
+ enters in the Suspend-to-RAM state.
+
+The value for maxim,regulator-[initial,disk,mem]-mode is one of the following:
+ 1: Normal regulator voltage output mode.
+ 3: Low Power which reduces the quiescent current down to only 1uA
+
+The list of valid modes are defined in the dt-bindings/regulator/regulator.h
+header and can be included by device tree source files. If no mode is defined,
+then the OS will not manage the modes and the HW default values will be used.
+
+The maxim,regulator-[initial,disk,mem]-mode properties can only be used with
+regulators that support changing their mode to Low Power Mode during suspend.
+These regulators are BUCKs 2-4 and LDOs 1-35.
+
+The maxim,regulator-[disk,mem]-mode property only takes effect if the regulator
+has been marked as enabled for the given suspend mode using the standard
+"regulator-on-in-suspend" property. If the regulator has not been explicitly
+enabled or if it was marked as disabled with "regulator-off-in-suspend", then
+setting the operating mode for that state will have no effect.
+
Example:
max77802@09 {
@@ -36,11 +69,23 @@ Example:
#size-cells = <0>;
regulators {
+ ldo1_reg: LDO1 {
+ regulator-name = "vdd_1v0";
+ regulator-min-microvolt = <100>;
+ regulator-max-microvolt = <100>;
+ regulator-always-on;
+ maxim,regulator-initial-mode =
;
+ };
+
ldo11_reg: LDO11 {
regulator-name = "vdd_ldo11";
regulator-min-microvolt = <190>;
regulator-max-microvolt = <190>;
regulator-always-on;
+ maxim,regulator-mem-mode = ;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ };
};
buck1_reg: BUCK1 {
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 9/9] ARM: dts: Configure regulators for suspend on exynos Peach boards
The regulator core now has support to choose if a regulator
has to be enabled or disabled during system suspend and also
the max77802 driver supports changing the regulator operating
mode during runtime and when the system enters into sleep mode.
To lower power during suspend, configure the regulators state
using the same configuration found in the ChromeOS 3.8 kernel.
Signed-off-by: Javier Martinez Canillas
---
arch/arm/boot/dts/exynos5420-peach-pit.dts | 81 ++
arch/arm/boot/dts/exynos5800-peach-pi.dts | 81 ++
2 files changed, 162 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts
b/arch/arm/boot/dts/exynos5420-peach-pit.dts
index 9a050e1..72d4e14 100644
--- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
+++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
@@ -13,6 +13,7 @@
#include
#include
#include
+#include
#include "exynos5420.dtsi"
/ {
@@ -192,6 +193,9 @@
regulator-always-on;
regulator-boot-on;
regulator-ramp-delay = <12500>;
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
};
buck2_reg: BUCK2 {
@@ -201,6 +205,9 @@
regulator-always-on;
regulator-boot-on;
regulator-ramp-delay = <12500>;
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
};
buck3_reg: BUCK3 {
@@ -210,6 +217,9 @@
regulator-always-on;
regulator-boot-on;
regulator-ramp-delay = <12500>;
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
};
buck4_reg: BUCK4 {
@@ -219,6 +229,9 @@
regulator-always-on;
regulator-boot-on;
regulator-ramp-delay = <12500>;
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
};
buck5_reg: BUCK5 {
@@ -227,6 +240,9 @@
regulator-max-microvolt = <120>;
regulator-always-on;
regulator-boot-on;
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
};
buck6_reg: BUCK6 {
@@ -236,6 +252,9 @@
regulator-always-on;
regulator-boot-on;
regulator-ramp-delay = <12500>;
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
};
buck7_reg: BUCK7 {
@@ -244,6 +263,9 @@
regulator-max-microvolt = <135>;
regulator-always-on;
regulator-boot-on;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ };
};
buck8_reg: BUCK8 {
@@ -252,6 +274,9 @@
regulator-max-microvolt = <285>;
regulator-always-on;
regulator-boot-on;
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
};
buck9_reg: BUCK9 {
@@ -260,6 +285,9 @@
regulator-max-microvolt = <200>;
regulator-always-on;
regulator-boot-on;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ };
};
buck10_reg: BUCK10 {
@@ -268,6 +296,9 @@
regulator-max-microvolt = <180>;
regulator-always-on;
regulator-boot-on;
+ regulator-state-mem {
+ regulator-on-i
[PATCH 8/9] regulator: max77802: Parse regulator operating mode properties
The max77802 PMIC regulators output can be configured in one of two
modes: Output ON (normal) and Output ON in Low Power Mode. Some of
the regulators support their operating mode to be changed on startup
or by consumers when the system is running while others only support
their operating mode to be changed while the system has entered in a
suspend state.
The max77802 PMIC Device Tree binding document a set of properties to
configure the regulators operating modes from a FDT. This patch parse
those properties and fills the regulator constraints so the regulator
core can call the suspend handlers when the system enters into sleep.
Signed-off-by: Javier Martinez Canillas
---
drivers/regulator/max77802.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/regulator/max77802.c b/drivers/regulator/max77802.c
index 43e34dd..c922edc 100644
--- a/drivers/regulator/max77802.c
+++ b/drivers/regulator/max77802.c
@@ -517,6 +517,22 @@ static struct regulator_desc regulators[] = {
};
#ifdef CONFIG_OF
+
+static void max77802_parse_opmodes(struct device_node *np,
+ struct regulation_constraints *cons)
+{
+ u32 pval;
+
+ if (!of_property_read_u32(np, "maxim,regulator-initial-mode", &pval))
+ cons->initial_mode = MAX77802_MODE(pval);
+
+ if (!of_property_read_u32(np, "maxim,regulator-disk-mode", &pval))
+ cons->state_disk.mode = MAX77802_MODE(pval);
+
+ if (!of_property_read_u32(np, "maxim,regulator-mem-mode", &pval))
+ cons->state_mem.mode = MAX77802_MODE(pval);
+}
+
static int max77802_pmic_dt_parse_pdata(struct platform_device *pdev,
struct max77686_platform_data *pdata)
{
@@ -554,6 +570,8 @@ static int max77802_pmic_dt_parse_pdata(struct
platform_device *pdev,
rdata[i].initdata = rmatch.init_data;
rdata[i].of_node = rmatch.of_node;
rdata[i].id = regulators[i].id;
+ max77802_parse_opmodes(rdata[i].of_node,
+ &rdata[i].initdata->constraints);
}
pdata->regulators = rdata;
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] ARM: EXYNOS: Call regulator core suspend prepare and finish functions
Javier,
On Wed, Oct 15, 2014 at 5:01 AM, Javier Martinez Canillas
wrote:
> The regulator framework has a set of helpers functions to be used when
> the system is entering and leaving from suspend but these are not called
> on Exynos platforms. This means that the .set_suspend_* function handlers
> defined in regulator drivers are never called when the system is suspended.
>
> Suggested-by: Doug Anderson
> Signed-off-by: Javier Martinez Canillas
Could you also add a patch to your series ripping out the call in
"drivers/mfd/sec-core.c" since it doesn't belong there. If you don't
rip that out then it will be called twice on systems with that
regulator.
> ---
> arch/arm/mach-exynos/suspend.c | 16
> 1 file changed, 16 insertions(+)
>
> diff --git a/arch/arm/mach-exynos/suspend.c b/arch/arm/mach-exynos/suspend.c
> index f5d9773..5b9c551 100644
> --- a/arch/arm/mach-exynos/suspend.c
> +++ b/arch/arm/mach-exynos/suspend.c
> @@ -20,6 +20,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -270,14 +271,29 @@ static int exynos_suspend_enter(suspend_state_t state)
>
> static int exynos_suspend_prepare(void)
> {
> + int ret;
> +
> s3c_pm_check_prepare();
>
> + /*
> +* REVISIT: It would be better if struct platform_suspend_ops
> +* .prepare handler get the suspend_state_t as a parameter to
> +* avoid hard-coding the suspend to mem state. It's safe to do
> +* it only because the suspend_valid_only_mem function is the
> +* .valid callback used to check if a given state is supported
> +* by the platform.
> +*/
> + ret = regulator_suspend_prepare(PM_SUSPEND_MEM);
> + if (ret)
> + pr_info("Failed to prepare regulators for system suspend\n");
> +
nit: can you put this before s3c_pm_check_prepare(). pm_check is
pretty darn broken and I have a feeling that it will eventually be
ripped out (or in the very least ported to not be Samsung-specific and
include all of the "suspend volatile" crud that we have in the
chromeos-3.8 kernel), but might as well try not to break it further.
Changing the order also has the advantage of making prepare / finish
opposite orders (good!) and handling the fact that you would call
s3c_pm_check_prepare() but not s3c_pm_check_cleanup() if
regulator_suspend_prepare() fails.
> return 0;
> }
>
> static void exynos_suspend_finish(void)
> {
> s3c_pm_check_cleanup();
> + regulator_suspend_finish();
> }
>
> static const struct platform_suspend_ops exynos_suspend_ops = {
> --
> 2.1.0
>
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/4] dwc3: exynos: Add support for SCLK present on Exynos7
Hi,
On Tue, Oct 14, 2014 at 10:25:00AM +0530, Vivek Gautam wrote:
> Hi Felipe,
>
>
> On Tue, Oct 14, 2014 at 4:14 AM, Felipe Balbi wrote:
> > Hi,
> >
> > On Mon, Oct 13, 2014 at 01:54:59PM +0900, Anton Tikhomirov wrote:
> >> Hi Vivek,
> >>
> >> > Exynos7 also has a separate special gate clock going to the IP
> >> > apart from the usual AHB clock. So add support for the same.
> >>
> >> As we discussed before, Exynos7 SoCs have 7 clocks to be controlled
> >> by the driver. Adding only sclk is not enough.
> >>
> >> >
> >> > Signed-off-by: Vivek Gautam
> >> > ---
> >> > drivers/usb/dwc3/dwc3-exynos.c | 16
> >> > 1 file changed, 16 insertions(+)
> >> >
> >> > diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-
> >> > exynos.c
> >> > index 3951a65..7dc6a98 100644
> >> > --- a/drivers/usb/dwc3/dwc3-exynos.c
> >> > +++ b/drivers/usb/dwc3/dwc3-exynos.c
> >> > @@ -35,6 +35,7 @@ struct dwc3_exynos {
> >> > struct device *dev;
> >> >
> >> > struct clk *clk;
> >>
> >> The clock "clk" in Exynos5 just gated all that above 7 clocks, which
> >> we should control separately now in Exynos7.
> >>
> >
> > should I drop this patch for now ?
>
> Yes, better to hold this for some time till we get more clarity
> from our h/w team.
now dropped. Please a new one if needed.
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH] arm64: dts: exynos7: add support for cpuidle core power down
On Wed, Oct 15, 2014 at 02:02:18PM +0100, Mark Rutland wrote:
> > > + CPU_SLEEP: cpu-sleep {
> > > + compatible = "arm,idle-state";
> > > + local-timer-stop;
> > > + arm,psci-suspend-param = <0x001>;
> > > + entry-latency-us = <20>;
> > > + exit-latency-us = <150>;
> > > + min-residency-us = <2100>;
> > > + status = "enabled";
>
> While status is a relatively standard property, it's absence implies
> everything is OK. There no need for it here as-is.
>
> Additionally, the canonical value is "okay", not "enabled", so this
> would fail were we to use of_device_is_available in the idle states
> parsing.
Good point. I still want it documented in the bindings, keeping in mind
your remark above.
> > status ? This is not a documented property. If you need it please explain
> > why, define its bindings and we can see how to accommodate it.
>
> Do we expect that some idle states won't be available on some boards
> built from the same platform?
I think it is something we should expect and be able to cope with that.
I will add status to idle-states bindings updates for this cycle and patch DT
parsing code accordingly.
Lorenzo
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL 2/2] Samsung defconfig updates for v3.18
On Tue, 2014-10-14 at 23:32 -0700, Olof Johansson wrote: > On Tue, Oct 14, 2014 at 4:27 PM, Kukjin Kim wrote: > > git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git > > tags/samsung-defconfig > > > > for you to fetch changes up to 508423bebcda29eb0ba7c627f895387dad7cdcd6: > > > > ARM: exynos_defconfig: enable USB gadget support (2014-09-25 18:20:18 > > +0900) > > Merged, thanks. Hrm, enabling USB gadget support will actually regress USB on Exynos peach boards and Arndale Octa without some of the DT fixes that landed in armsoc next/late branch. Specifically: 5c42acdb9bab595482b966b22ab5e2f6f359 dbb62ef9ade6e92737d3fac199665b8b7c455959 Might be good to cherry-pick those into for-next at this point (they're rather trivial) -- Sjoerd Simons Collabora Ltd. smime.p7s Description: S/MIME cryptographic signature
Re: [PATCH] arm64: dts: exynos7: add support for cpuidle core power down
> > + CPU_SLEEP: cpu-sleep {
> > + compatible = "arm,idle-state";
> > + local-timer-stop;
> > + arm,psci-suspend-param = <0x001>;
> > + entry-latency-us = <20>;
> > + exit-latency-us = <150>;
> > + min-residency-us = <2100>;
> > + status = "enabled";
While status is a relatively standard property, it's absence implies
everything is OK. There no need for it here as-is.
Additionally, the canonical value is "okay", not "enabled", so this
would fail were we to use of_device_is_available in the idle states
parsing.
> status ? This is not a documented property. If you need it please explain
> why, define its bindings and we can see how to accommodate it.
Do we expect that some idle states won't be available on some boards
built from the same platform?
Mark.
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/1] ARM: EXYNOS: Call regulator core suspend prepare and finish functions
The regulator framework has a set of helpers functions to be used when
the system is entering and leaving from suspend but these are not called
on Exynos platforms. This means that the .set_suspend_* function handlers
defined in regulator drivers are never called when the system is suspended.
Suggested-by: Doug Anderson
Signed-off-by: Javier Martinez Canillas
---
arch/arm/mach-exynos/suspend.c | 16
1 file changed, 16 insertions(+)
diff --git a/arch/arm/mach-exynos/suspend.c b/arch/arm/mach-exynos/suspend.c
index f5d9773..5b9c551 100644
--- a/arch/arm/mach-exynos/suspend.c
+++ b/arch/arm/mach-exynos/suspend.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#include
#include
@@ -270,14 +271,29 @@ static int exynos_suspend_enter(suspend_state_t state)
static int exynos_suspend_prepare(void)
{
+ int ret;
+
s3c_pm_check_prepare();
+ /*
+* REVISIT: It would be better if struct platform_suspend_ops
+* .prepare handler get the suspend_state_t as a parameter to
+* avoid hard-coding the suspend to mem state. It's safe to do
+* it only because the suspend_valid_only_mem function is the
+* .valid callback used to check if a given state is supported
+* by the platform.
+*/
+ ret = regulator_suspend_prepare(PM_SUSPEND_MEM);
+ if (ret)
+ pr_info("Failed to prepare regulators for system suspend\n");
+
return 0;
}
static void exynos_suspend_finish(void)
{
s3c_pm_check_cleanup();
+ regulator_suspend_finish();
}
static const struct platform_suspend_ops exynos_suspend_ops = {
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: exynos5422-odroid-xu3: MCPM: only 6 of 8 CPUs coming online
Hi, Kevin Hilman kernel.org> writes: > > Hi Abhilash, > > Abhilash Kesavan samsung.com> writes: > > > I had noticed a similar issue where only 6 cores would come up during > > development on 5420. This was because there was a check in our u-boot > > secondary boot-up path which would put a core into WFI if a flag was > > not present and hence fail to boot. I wonder if it is the same > > situation in your case too. > > Is the u-boot for odroid-xu3 publically available or can you check if there is any such code present in your > secondary bring-up path. > > I'm using the hardkernel u-boot[1], branch: odroidxu3-v2012.07. I'm > currently using the pre-built binaries that are in the > sd_fuse/hardkernel directory of that branch, but I can rebuild u-boot if > needed. > > I'm not very familiar with u-boot, but if f you have some pointers where > to start looking in that code, that would be helpful. > > Kevin > > [1] https://github.com/hardkernel/u-boot.git > > It seems to need magic code. Please refer https://github.com/abhijeet-dev/linux-samsung/commit /553b7f40465ab4fad6c270f289cd4780942f7fae Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] arm64: dts: exynos7: add support for cpuidle core power down
On Wed, Oct 15, 2014 at 07:35:20AM +0100, Chander Kashyap wrote:
> Exynos7 has core power down state where cores can be powered off
> independently.
> This patch adds support for this state.
Please tell us more about the idle-state values you are adding, in particular
entry, exit latencies and min-residency values.
> Signed-off-by: Chander Kashyap
> ---
> This patch has following dependencies:
> - [PATCH v5 0/8] arch: arm64: Enable support for Samsung Exynos7 SoC
> http://www.spinics.net/lists/linux-samsung-soc/msg37047.html
> - [PATCH v9 0/8] ARM generic idle states
>
> http://permalink.gmane.org/gmane.linux.power-management.general/49224
Series above was merged, so dependency is stale.
> arch/arm64/boot/dts/exynos/exynos7.dtsi | 18 ++
> 1 file changed, 18 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/exynos/exynos7.dtsi
> b/arch/arm64/boot/dts/exynos/exynos7.dtsi
> index ce221ac..8e0a034 100644
> --- a/arch/arm64/boot/dts/exynos/exynos7.dtsi
> +++ b/arch/arm64/boot/dts/exynos/exynos7.dtsi
> @@ -36,6 +36,7 @@
> device_type = "cpu";
> compatible = "arm,cortex-a57", "arm,armv8";
> enable-method = "psci";
> + cpu-idle-states = <&CPU_SLEEP>;
I would add cpu-idle-states phandle after the reg property, as defined
in the idle states bindings.
> reg = <0x0>;
> };
>
> @@ -43,6 +44,7 @@
> device_type = "cpu";
> compatible = "arm,cortex-a57", "arm,armv8";
> enable-method = "psci";
> + cpu-idle-states = <&CPU_SLEEP>;
> reg = <0x1>;
> };
>
> @@ -50,6 +52,7 @@
> device_type = "cpu";
> compatible = "arm,cortex-a57", "arm,armv8";
> enable-method = "psci";
> + cpu-idle-states = <&CPU_SLEEP>;
> reg = <0x2>;
> };
>
> @@ -57,8 +60,23 @@
> device_type = "cpu";
> compatible = "arm,cortex-a57", "arm,armv8";
> enable-method = "psci";
> + cpu-idle-states = <&CPU_SLEEP>;
> reg = <0x3>;
> };
> +
> + idle-states {
> + entry-method = "arm,psci";
> +
> + CPU_SLEEP: cpu-sleep {
> + compatible = "arm,idle-state";
> + local-timer-stop;
> + arm,psci-suspend-param = <0x001>;
> + entry-latency-us = <20>;
> + exit-latency-us = <150>;
> + min-residency-us = <2100>;
> + status = "enabled";
status ? This is not a documented property. If you need it please explain
why, define its bindings and we can see how to accommodate it.
Thank you,
Lorenzo
> + };
> + };
> };
>
> psci {
> --
> 1.7.9.5
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
