Re: [GIT PULL 2/2] Samsung defconfig updates for v3.18
Hello Kukjin,
On Fri, Oct 17, 2014 at 1:00 AM, Kukjin Kim wrote:
> On 10/16/14 16:59, Kukjin Kim wrote:
>>
>> Javier Martinez Canillas wrote:
>>>
>>>
>>> Hello Kukjin,
>>>
>> Hi,
>>
>>> On Thu, Oct 16, 2014 at 3:01 AM, Kukjin Kim wrote:
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?
>>>
>> + Arnd, Olof and regarding MLs
>>
>>> There are other bugfixes for 3.18 that ended in next/late so it would
>>> be good if you do a new pull request to include those as well.
>>>
>>> The commits (with hashes from linux-next) are:
>>>
>>> 3f3d046 ARM: dts: Remove display timings node from exynos5250-snow
>>> dd12ac7 ARM: dts: Fix chip select GPIO on exynos5250-smdk5250
>>
>>
> Above patches are not required because there is no my wrong merge ;)
>
Right, for some reason I thought that Andreas' rebased patches ended
in for-next but now I see that are in next/late as well so yes, those
patches are not required for 3.18.
Sorry for the noise then, -ETOOMANYBRANCHES
>>> c04c92e ARM: dts: Add rtc_src clk for s3c-rtc on exynos5250-snow
>>> 8bd43b6 ARM: dts: Add rtc_src clk for s3c-rtc on exynos Peach boards
>>>
>> I checked its dependent clock patches have been merged into mainline just
>> now.
>> As you know, the patches blocked dt patches in this time :( Anyway, I'll
>> try
>> to send a pull-request with including above patches tonight.
>>
> Hmm...
>
> + Chanwoo
>
> I didn't look at the Chanwoo's patch closely at that time but I think we
> don't need to register rtc_src clock for all other Samsung stuff if we don't
> want to gate the clock for rtc driver. So the rtc driver would be fixed like
> below for all Samsung stuff...
>
> diff --git a/drivers/rtc/rtc-s3c.c b/drivers/rtc/rtc-s3c.c
> index a6b1252..84f3cbd 100644
> --- a/drivers/rtc/rtc-s3c.c
> +++ b/drivers/rtc/rtc-s3c.c
> @@ -535,13 +535,14 @@ static int s3c_rtc_probe(struct platform_device *pdev)
> }
> clk_prepare_enable(info->rtc_clk);
>
> - info->rtc_src_clk = devm_clk_get(&pdev->dev, "rtc_src");
> - if (IS_ERR(info->rtc_src_clk)) {
> - dev_err(&pdev->dev, "failed to find rtc source clock\n");
> - return PTR_ERR(info->rtc_src_clk);
> + if (info->data->needs_src_clk)
> + info->rtc_src_clk = devm_clk_get(&pdev->dev, "rtc_src");
> + if (IS_ERR(info->rtc_src_clk)) {
> + dev_err(&pdev->dev, "failed to find rtc source
> clock\n");
> + return PTR_ERR(info->rtc_src_clk);
> + }
> + clk_prepare_enable(info->rtc_src_clk);
> }
> - clk_prepare_enable(info->rtc_src_clk);
> -
>
> /* check to see if everything is setup correctly */
> if (info->data->enable)
>
>
>
The Snow/Peach rtc_src clk for s3c-rtc patches are still needed on
those platforms since the S3C RTC uses the Maxim 77802 32kHz AP clock
as its source clock and this will be disabled by the common clock
framework if are not used.
In practice, most people using mainline are booting with a U-Boot
version that passes the clk_ignore_unused parameter to the kernel
command line so if Marek's patch makes for the 3.18 rc cycle, the
Snow/Peach rtc_src patches can indeed wait for 3.19.
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
Re: [GIT PULL 2/2] Samsung defconfig updates for v3.18
Dear Kukjin,
On 10/17/2014 08:00 AM, Kukjin Kim wrote:
> On 10/16/14 16:59, Kukjin Kim wrote:
>> Javier Martinez Canillas wrote:
>>>
>>> Hello Kukjin,
>>>
>> Hi,
>>
>>> On Thu, Oct 16, 2014 at 3:01 AM, Kukjin Kim wrote:
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?
>>>
>> + Arnd, Olof and regarding MLs
>>
>>> There are other bugfixes for 3.18 that ended in next/late so it would
>>> be good if you do a new pull request to include those as well.
>>>
>>> The commits (with hashes from linux-next) are:
>>>
>>> 3f3d046 ARM: dts: Remove display timings node from exynos5250-snow
>>> dd12ac7 ARM: dts: Fix chip select GPIO on exynos5250-smdk5250
>>
> Above patches are not required because there is no my wrong merge ;)
>
>>> c04c92e ARM: dts: Add rtc_src clk for s3c-rtc on exynos5250-snow
>>> 8bd43b6 ARM: dts: Add rtc_src clk for s3c-rtc on exynos Peach boards
>>>
>> I checked its dependent clock patches have been merged into mainline just
>> now.
>> As you know, the patches blocked dt patches in this time :( Anyway, I'll try
>> to send a pull-request with including above patches tonight.
>>
> Hmm...
>
> + Chanwoo
>
> I didn't look at the Chanwoo's patch closely at that time but I think we
> don't need to register rtc_src clock for all other Samsung stuff if we don't
> want to gate the clock for rtc driver. So the rtc driver would be fixed like
> below for all Samsung stuff...
You are right. It is my mistake when sending rtc patchset.
So, Marek sent a patch[1] to fix this bug as following:
[1] https://lkml.org/lkml/2014/10/15/605
- [PATCH] drivers: rtc: fix s3c-rtc initialization failure without rtc source
clock
And then Andrew Morton (a...@linux-foundation.org) picked up this patch and
will apply it on linux-next branch.
http://ozlabs.org/~akpm/mmots/broken-out/drivers-rtc-fix-s3c-rtc-initialization-failure-without-rtc-source-clock.patch
Best Regards,
Chanwoo Choi
>
> diff --git a/drivers/rtc/rtc-s3c.c b/drivers/rtc/rtc-s3c.c
> index a6b1252..84f3cbd 100644
> --- a/drivers/rtc/rtc-s3c.c
> +++ b/drivers/rtc/rtc-s3c.c
> @@ -535,13 +535,14 @@ static int s3c_rtc_probe(struct platform_device *pdev)
> }
> clk_prepare_enable(info->rtc_clk);
>
> -info->rtc_src_clk = devm_clk_get(&pdev->dev, "rtc_src");
> -if (IS_ERR(info->rtc_src_clk)) {
> -dev_err(&pdev->dev, "failed to find rtc source clock\n");
> -return PTR_ERR(info->rtc_src_clk);
> +if (info->data->needs_src_clk)
> +info->rtc_src_clk = devm_clk_get(&pdev->dev, "rtc_src");
> +if (IS_ERR(info->rtc_src_clk)) {
> +dev_err(&pdev->dev, "failed to find rtc source clock\n");
> +return PTR_ERR(info->rtc_src_clk);
> +}
> +clk_prepare_enable(info->rtc_src_clk);
> }
> -clk_prepare_enable(info->rtc_src_clk);
> -
>
> /* check to see if everything is setup correctly */
> if (info->data->enable)
>
>
>> Thanks for your gentle reminder.
>>
>> Olof, I think it makes sense because it is related fixes for 3.18 ;)
>>
>> Sorry for late noise...
>>
>> Thanks,
>> 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 v2 2/2] ARM: EXYNOS: Call regulator core suspend prepare and finish functions
Hi Javier,
On 10/16/2014 07:13 PM, 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 by regulator drivers are not called when the system is suspended.
>
> Suggested-by: Doug Anderson
> Signed-off-by: Javier Martinez Canillas
> ---
> arch/arm/mach-exynos/suspend.c | 18 ++
> 1 file changed, 18 insertions(+)
>
> diff --git a/arch/arm/mach-exynos/suspend.c b/arch/arm/mach-exynos/suspend.c
> index cc8d237..ee9a8e0 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
> @@ -443,6 +444,22 @@ static int exynos_suspend_enter(suspend_state_t state)
>
> static int exynos_suspend_prepare(void)
> {
> + int ret;
> +
> + /*
> + * 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 now only because the suspend_valid_only_mem function is
> + * used as the .valid callback used to check if a given state
> + * is supported by the platform anyways.
> + */
> + ret = regulator_suspend_prepare(PM_SUSPEND_MEM);
> + if (ret) {
> + pr_err("Failed to prepare regulators for system suspend\n");
> + return ret;
> + }
> +
> s3c_pm_check_prepare();
>
> return 0;
> @@ -451,6 +468,7 @@ static int exynos_suspend_prepare(void)
> static void exynos_suspend_finish(void)
> {
> s3c_pm_check_cleanup();
> + regulator_suspend_finish();
> }
>
> static const struct platform_suspend_ops exynos_suspend_ops = {
>
Looks good to me.
Reviewed-by: Chanwoo Choi
Thanks,
Chanwoo Choi
--
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
[GIT PULL 2nd] Samsung fixes 2nd for v3.18
Hi, This is required for previous exynos_defconfig updates including USB gadget. Please pull. Note, this branch is based on previous tags/samsung-defconfig. Thanks, Kukjin --- The following changes since commit 508423bebcda29eb0ba7c627f895387dad7cdcd6: ARM: exynos_defconfig: enable USB gadget support (2014-09-25 18:20:18 +0900) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git tags/samsung-fixes-2 for you to fetch changes up to 4e03394e939135adcd453bd538ea02d98a30473b: ARM: dts: Explicitly set dr_mode on exynos5420-arndale-octa (2014-10-17 08:17:35 +0900) 2nd Samsung fixes for v3.18 - Explicitly set dr_mode on exynos5800-peach-pi, exynos5420-peach-pit and exynos5420-arndale-octa boards, because the USB dwc3 controller will not work properly without dr_mode as host on above boards if the USB host and gadget are enabled in kernel configuration both. Sjoerd Simons (2): ARM: dts: Explicitly set dr_mode on exynos Peach boards ARM: dts: Explicitly set dr_mode on exynos5420-arndale-octa arch/arm/boot/dts/exynos5420-arndale-octa.dts | 4 arch/arm/boot/dts/exynos5420-peach-pit.dts| 8 arch/arm/boot/dts/exynos5420.dtsi | 4 ++-- arch/arm/boot/dts/exynos5800-peach-pi.dts | 8 4 files changed, 22 insertions(+), 2 deletions(-) -- 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 10/16/14 16:59, Kukjin Kim wrote:
Javier Martinez Canillas wrote:
Hello Kukjin,
Hi,
On Thu, Oct 16, 2014 at 3:01 AM, Kukjin Kim wrote:
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?
+ Arnd, Olof and regarding MLs
There are other bugfixes for 3.18 that ended in next/late so it would
be good if you do a new pull request to include those as well.
The commits (with hashes from linux-next) are:
3f3d046 ARM: dts: Remove display timings node from exynos5250-snow
dd12ac7 ARM: dts: Fix chip select GPIO on exynos5250-smdk5250
Above patches are not required because there is no my wrong merge ;)
c04c92e ARM: dts: Add rtc_src clk for s3c-rtc on exynos5250-snow
8bd43b6 ARM: dts: Add rtc_src clk for s3c-rtc on exynos Peach boards
I checked its dependent clock patches have been merged into mainline just now.
As you know, the patches blocked dt patches in this time :( Anyway, I'll try
to send a pull-request with including above patches tonight.
Hmm...
+ Chanwoo
I didn't look at the Chanwoo's patch closely at that time but I think we
don't need to register rtc_src clock for all other Samsung stuff if we
don't want to gate the clock for rtc driver. So the rtc driver would be
fixed like below for all Samsung stuff...
diff --git a/drivers/rtc/rtc-s3c.c b/drivers/rtc/rtc-s3c.c
index a6b1252..84f3cbd 100644
--- a/drivers/rtc/rtc-s3c.c
+++ b/drivers/rtc/rtc-s3c.c
@@ -535,13 +535,14 @@ static int s3c_rtc_probe(struct platform_device *pdev)
}
clk_prepare_enable(info->rtc_clk);
- info->rtc_src_clk = devm_clk_get(&pdev->dev, "rtc_src");
- if (IS_ERR(info->rtc_src_clk)) {
- dev_err(&pdev->dev, "failed to find rtc source clock\n");
- return PTR_ERR(info->rtc_src_clk);
+ if (info->data->needs_src_clk)
+ info->rtc_src_clk = devm_clk_get(&pdev->dev, "rtc_src");
+ if (IS_ERR(info->rtc_src_clk)) {
+ dev_err(&pdev->dev, "failed to find rtc source
clock\n");
+ return PTR_ERR(info->rtc_src_clk);
+ }
+ clk_prepare_enable(info->rtc_src_clk);
}
- clk_prepare_enable(info->rtc_src_clk);
-
/* check to see if everything is setup correctly */
if (info->data->enable)
Thanks for your gentle reminder.
Olof, I think it makes sense because it is related fixes for 3.18 ;)
Sorry for late noise...
Thanks,
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
[PATCH v2 2/7] 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
---
Changes since v1:
- Don't map both IDLE and STANDBY modes to the hw Low Power Mode.
Suggested by Mark Brown.
drivers/regulator/max77802.c | 93 ++--
1 file changed, 46 insertions(+), 47 deletions(-)
diff --git a/drivers/regulator/max77802.c b/drivers/regulator/max77802.c
index 6eabb95..dae2c1a 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
/* MAX77802 has two register formats: 2-bit and 4-bit */
static const unsigned int ramp_table_77802_2bit[] = {
@@ -148,71 +149,68 @@ static unsigned max77802_get_mode(struct regulator_dev
*rdev)
return max77802_map_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.
+
[PATCH v2 1/7] 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
---
Changes since v1:
- Use a static inline function instead of a macro to map the modes.
Suggested by Mark Brown.
- Don't have multiple standard modes mapping onto a single hw mode.
Suggested by Mark Brown.
drivers/regulator/max77802.c | 46
1 file changed, 46 insertions(+)
diff --git a/drivers/regulator/max77802.c b/drivers/regulator/max77802.c
index 8425c0d..6eabb95 100644
--- a/drivers/regulator/max77802.c
+++ b/drivers/regulator/max77802.c
@@ -70,6 +70,12 @@ struct max77802_regulator_prv {
unsigned int opmode[MAX77802_REG_MAX];
};
+static inline int max77802_map_mode(int mode)
+{
+ return mode == MAX77802_OPMODE_NORMAL ?
+ REGULATOR_MODE_NORMAL : REGULATOR_MODE_STANDBY;
+}
+
static int max77802_get_opmode_shift(int id)
{
if (id == MAX77802_BUCK1 || (id >= MAX77802_BUCK5 &&
@@ -105,6 +111,44 @@ 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_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_map_mode(max77802->opmode[id]);
+}
+
+/*
* Some LDOs supports LPM-ON/OFF/Normal-ON mode during suspend state
* (Enable Control Logic1 by PWRREQ)
*
@@ -268,6 +312,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 v2 4/7] 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
---
Changes since v1: None
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 3abf99d..5839c45 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 v2 5/7] 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
---
Changes since v1: None
.../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 v2 3/7] 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 --- Changes since v1: None 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 dae2c1a..3abf99d 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 @@ -615,7 +616,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 v2 7/7] 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
---
Changes since v1: None
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 {
+
[PATCH v2 6/7] 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
---
Changes since v1:
- Use the static inline max77802_map_mode() function instead of a macro.
Suggested by Mark Brown.
drivers/regulator/max77802.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/regulator/max77802.c b/drivers/regulator/max77802.c
index 5839c45..e2fbd45 100644
--- a/drivers/regulator/max77802.c
+++ b/drivers/regulator/max77802.c
@@ -518,6 +518,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_map_mode(pval);
+
+ if (!of_property_read_u32(np, "maxim,regulator-disk-mode", &pval))
+ cons->state_disk.mode = max77802_map_mode(pval);
+
+ if (!of_property_read_u32(np, "maxim,regulator-mem-mode", &pval))
+ cons->state_mem.mode = max77802_map_mode(pval);
+}
+
static int max77802_pmic_dt_parse_pdata(struct platform_device *pdev,
struct max77686_platform_data *pdata)
{
@@ -555,6 +571,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
[PATCH v2 0/7] Add max77802 regulator operating mode support
Hello Mark,
This is the second version of the series that adds operating modes
support for the regulators in the max77802 PMIC. It address issues
pointed out in "regulator: max77802: Add .{get,set}_mode callbacks"
and also removes the patches you already picked on the topic branch.
The first version of the series was [0].
The series adds 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 v2 of patch:
"ARM: EXYNOS: Call regulator core suspend prepare and finish functions" [2].
NOTE: Patch #4 touches a header in include/linux/mfd so some coordination
with the mfd maintainer (added as cc) will be needed.
Javier Martinez Canillas (7):
regulator: max77802: Add .{get,set}_mode callbacks
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 | 122 -
include/dt-bindings/regulator/maxim,max77802.h | 18 +++
include/linux/mfd/max77686.h | 7 --
6 files changed, 319 insertions(+), 35 deletions(-)
create mode 100644 include/dt-bindings/regulator/maxim,max77802.h
Patch #1 adds a get and set mode function handlers for the regulators whose
operating mode can be changed at runtime.
Patch #2 adds support for changing the operating mode for all regulators
that support setting a different opmode during suspend.
Patch #3 is a cleanup to not call OFF an operating mode.
Patch #4 adds a header file with the valid operating modes so it can be used
by Device Tree source files.
Patch #5 extend the max77802 DT binding to include the properties used to
setup the regulators modes.
Patch #6 adds the support to parse these from the driver.
Patch #7 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]: http://www.spinics.net/lists/arm-kernel/msg369923.html
--
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 8/9] usb: dwc2/gadget: fix calls to phy control functions in suspend/resume code
Hi, On Thu, Oct 16, 2014 at 02:58:04PM +0200, Marek Szyprowski wrote: > This patch moves calls to phy enable/disable out of spinlock protected > blocks in device suspend/resume to fix incorrect caller context. Phy > related functions must not be called from atomic context. > > Signed-off-by: Marek Szyprowski > --- > drivers/usb/dwc2/gadget.c | 9 ++--- > 1 file changed, 6 insertions(+), 3 deletions(-) > > diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c > index cdf417a7ae63..052b1a857291 100644 > --- a/drivers/usb/dwc2/gadget.c > +++ b/drivers/usb/dwc2/gadget.c > @@ -3656,11 +3656,13 @@ static int s3c_hsotg_suspend(struct platform_device > *pdev, pm_message_t state) >hsotg->driver->driver.name); > > spin_lock_irqsave(&hsotg->lock, flags); > + s3c_hsotg_core_disconnect(hsotg); > s3c_hsotg_disconnect(hsotg); > - s3c_hsotg_phy_disable(hsotg); > hsotg->gadget.speed = USB_SPEED_UNKNOWN; > spin_unlock_irqrestore(&hsotg->lock, flags); > > + s3c_hsotg_phy_disable(hsotg); this is aching to have a locked version as well as an unlocked version. Look at what you do here. There's a minor race when you release that spinlock. By the time ->suspend() is called, IRQs are not yet disabled. -- balbi signature.asc Description: Digital signature
Re: [PATCH 2/9] usb: dwc2/gadget: fix enumeration issues
On Thu, Oct 16, 2014 at 02:57:58PM +0200, Marek Szyprowski wrote: > Excessive debug messages might cause timing issues that prevent correct > usb enumeration. This patch hides information about USB bus reset to let > driver enumerate fast enough to avoid making host angry. This fixes > endless enumeration and usb reset loop observed with some Linux hosts. > > Signed-off-by: Marek Szyprowski > --- > drivers/usb/dwc2/gadget.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c > index 119c8a3effc2..8870e38c1d82 100644 > --- a/drivers/usb/dwc2/gadget.c > +++ b/drivers/usb/dwc2/gadget.c > @@ -2333,7 +2333,7 @@ irq_retry: > > u32 usb_status = readl(hsotg->regs + GOTGCTL); > > - dev_info(hsotg->dev, "%s: USBRst\n", __func__); > + dev_dbg(hsotg->dev, "%s: USBRst\n", __func__); considering this is inside an IRQ handler, I'd rather use dev_vdbg() but no strong feelings: Reviewed-by: Felipe Balbi -- balbi signature.asc Description: Digital signature
Re: [PATCH 7/9] usb: dwc2/gadget: use soft disconnect mode for implementing pullup control
Hi,
your subject line is wrong. ->pullup() is already implemented, you're
moving unnecessary code from ->pullup() to other places.
On Thu, Oct 16, 2014 at 02:58:03PM +0200, Marek Szyprowski wrote:
> This patch moves PHY enable and disable calls from pullup method to
> udc_start/stop functions and adds calls to recently introduces soft
> disconnect mode in pullup method. This improves dwc2 gadget driver
> compatibility with gadget API requirements (now pullup method really
> forces soft disconnect mode instead of shutting down the whole hardware)
> and as a side effect also solves the issue related to limited caller
> context for PHY related functions (they cannot be called from
> non-sleeping context).
you're doing two things in one patch. See below
> Signed-off-by: Marek Szyprowski
> ---
> drivers/usb/dwc2/gadget.c | 16 +---
> 1 file changed, 13 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
> index d039334967d7..cdf417a7ae63 100644
> --- a/drivers/usb/dwc2/gadget.c
> +++ b/drivers/usb/dwc2/gadget.c
> @@ -2883,6 +2883,7 @@ static int s3c_hsotg_udc_start(struct usb_gadget
> *gadget,
> struct usb_gadget_driver *driver)
> {
> struct s3c_hsotg *hsotg = to_hsotg(gadget);
> + unsigned long flags;
> int ret;
>
> if (!hsotg) {
> @@ -2919,7 +2920,15 @@ static int s3c_hsotg_udc_start(struct usb_gadget
> *gadget,
> goto err;
> }
>
> + s3c_hsotg_phy_enable(hsotg);
you moved phy_enable to udc_start/udc_stop (one patch)
> +
> + spin_lock_irqsave(&hsotg->lock, flags);
> + s3c_hsotg_init(hsotg);
> + s3c_hsotg_core_init_disconnected(hsotg);
you moved core init here (another patch).
> + spin_unlock_irqrestore(&hsotg->lock, flags);
> +
> dev_info(hsotg->dev, "bound driver %s\n", driver->driver.name);
> +
> return 0;
>
> err:
> @@ -2957,6 +2966,8 @@ static int s3c_hsotg_udc_stop(struct usb_gadget *gadget,
>
> spin_unlock_irqrestore(&hsotg->lock, flags);
>
> + s3c_hsotg_phy_disable(hsotg);
> +
> regulator_bulk_disable(ARRAY_SIZE(hsotg->supplies), hsotg->supplies);
>
> clk_disable(hsotg->clk);
> @@ -2990,14 +3001,13 @@ static int s3c_hsotg_pullup(struct usb_gadget
> *gadget, int is_on)
> dev_dbg(hsotg->dev, "%s: is_on: %d\n", __func__, is_on);
>
> spin_lock_irqsave(&hsotg->lock, flags);
> +
> if (is_on) {
> - s3c_hsotg_phy_enable(hsotg);
> clk_enable(hsotg->clk);
> - s3c_hsotg_core_init_disconnected(hsotg);
> s3c_hsotg_core_connect(hsotg);
> } else {
> + s3c_hsotg_core_disconnect(hsotg);
> clk_disable(hsotg->clk);
> - s3c_hsotg_phy_disable(hsotg);
> }
>
> hsotg->gadget.speed = USB_SPEED_UNKNOWN;
> --
> 1.9.2
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH 6/9] usb: dwc2/gadget: decouple setting soft disconnect from s3c_hsotg_core_init
On Thu, Oct 16, 2014 at 02:58:02PM +0200, Marek Szyprowski wrote:
> This patch changes s3c_hsotg_core_init function to leave hardware in
> soft disconnect mode, so the actual moment of coupling the hardware to
> the usb bus can be later controlled by the driver in the more accurate
what is this "more accurate way" you talk about ? Why is it more
accurate ? Perhaps you have failed some USB Certification test ? Which
test id was that ? Why did it fail ? and why does this patch solve the
issue ?
> way. For this purpose, separate functions for enabling and disabling
> soft disconnect mode have been added.
>
> Signed-off-by: Marek Szyprowski
> ---
> drivers/usb/dwc2/gadget.c | 22 +-
> 1 file changed, 17 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
> index 1ba0682fb252..d039334967d7 100644
> --- a/drivers/usb/dwc2/gadget.c
> +++ b/drivers/usb/dwc2/gadget.c
> @@ -2124,7 +2124,7 @@ static int s3c_hsotg_corereset(struct s3c_hsotg *hsotg)
> *
> * Issue a soft reset to the core, and await the core finishing it.
> */
> -static void s3c_hsotg_core_init(struct s3c_hsotg *hsotg)
> +static void s3c_hsotg_core_init_disconnected(struct s3c_hsotg *hsotg)
> {
> s3c_hsotg_corereset(hsotg);
>
> @@ -2241,14 +2241,23 @@ static void s3c_hsotg_core_init(struct s3c_hsotg
> *hsotg)
> readl(hsotg->regs + DOEPCTL0));
>
> /* clear global NAKs */
> - writel(DCTL_CGOUTNAK | DCTL_CGNPINNAK,
> + writel(DCTL_CGOUTNAK | DCTL_CGNPINNAK | DCTL_SFTDISCON,
> hsotg->regs + DCTL);
>
> /* must be at-least 3ms to allow bus to see disconnect */
> mdelay(3);
>
> hsotg->last_rst = jiffies;
> +}
> +
> +static void s3c_hsotg_core_disconnect(struct s3c_hsotg *hsotg)
> +{
> + /* set the soft-disconnect bit */
> + __orr32(hsotg->regs + DCTL, DCTL_SFTDISCON);
> +}
>
> +static void s3c_hsotg_core_connect(struct s3c_hsotg *hsotg)
> +{
> /* remove the soft-disconnect and let's go */
> __bic32(hsotg->regs + DCTL, DCTL_SFTDISCON);
> }
> @@ -2348,7 +2357,8 @@ irq_retry:
> kill_all_requests(hsotg, &hsotg->eps[0],
> -ECONNRESET, true);
>
> - s3c_hsotg_core_init(hsotg);
> + s3c_hsotg_core_init_disconnected(hsotg);
> + s3c_hsotg_core_connect(hsotg);
> }
> }
> }
> @@ -2983,7 +2993,8 @@ static int s3c_hsotg_pullup(struct usb_gadget *gadget,
> int is_on)
> if (is_on) {
> s3c_hsotg_phy_enable(hsotg);
> clk_enable(hsotg->clk);
> - s3c_hsotg_core_init(hsotg);
> + s3c_hsotg_core_init_disconnected(hsotg);
> + s3c_hsotg_core_connect(hsotg);
> } else {
> clk_disable(hsotg->clk);
> s3c_hsotg_phy_disable(hsotg);
> @@ -3670,7 +3681,8 @@ static int s3c_hsotg_resume(struct platform_device
> *pdev)
>
> spin_lock_irqsave(&hsotg->lock, flags);
> s3c_hsotg_phy_enable(hsotg);
> - s3c_hsotg_core_init(hsotg);
> + s3c_hsotg_core_init_disconnect(hsotg);
> + s3c_hsotg_core_connect(hsotg);
> spin_unlock_irqrestore(&hsotg->lock, flags);
>
> return ret;
> --
> 1.9.2
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH 3/9] usb: dwc2/gadget: fix support for soft_connect udc framework feature
Hi, On Thu, Oct 16, 2014 at 02:57:59PM +0200, Marek Szyprowski wrote: > Enabling and disabling usb gadget by writing to > /sys/class/udc/*hsotg/soft_connect results in calling udc_start/udc_stop > functions with the same usb gadget driver, so the driver should not WARN > about such case. > > Signed-off-by: Marek Szyprowski > --- > drivers/usb/dwc2/gadget.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c > index 8870e38c1d82..37fda4c03397 100644 > --- a/drivers/usb/dwc2/gadget.c > +++ b/drivers/usb/dwc2/gadget.c > @@ -2892,7 +2892,7 @@ static int s3c_hsotg_udc_start(struct usb_gadget > *gadget, > return -EINVAL; > } > > - WARN_ON(hsotg->driver); > + WARN_ON(hsotg->driver && hsotg->driver != driver); the bug is in your ->udc_stop(). You should clear hsotg->driver to NULL there. -- balbi signature.asc Description: Digital signature
Re: [PATCH 1/9] usb: dwc2/gadget: report disconnect event from 'end session' irq
On Thu, Oct 16, 2014 at 02:57:57PM +0200, Marek Szyprowski wrote:
> This patch adds a call to s3c_hsotg_disconnect() from 'end session'
> interrupt to correctly notify gadget subsystem about unplugged usb
> cable.
>
> Signed-off-by: Marek Szyprowski
> ---
> drivers/usb/dwc2/gadget.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
> index 7b5856fadd93..119c8a3effc2 100644
> --- a/drivers/usb/dwc2/gadget.c
> +++ b/drivers/usb/dwc2/gadget.c
> @@ -2279,6 +2279,12 @@ irq_retry:
> dev_info(hsotg->dev, "OTGInt: %08x\n", otgint);
>
> writel(otgint, hsotg->regs + GOTGINT);
> +
> + if (otgint & GOTGINT_SES_END_DET) {
looks like this should be done for GINTSTS_DISCONNINT.
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH v2 0/2] serial: samsung: add support for early console
Hi Marek, On Sat, Sep 27, 2014 at 4:58 AM, Alim Akhtar wrote: > HI Marek, > > On Thu, Sep 25, 2014 at 3:24 PM, Marek Szyprowski > wrote: >> This patchset adds support for early console defined in device tree. As >> an example, DTS files for all Exynos4 based machines are updated with >> the correct value for common chosen/sdtout property. >> >> To get it fully functional on ARM architecture, additional improvements >> (support for early_ioremap) are needed in early console code. >> >> Best regards >> Marek Szyprowski >> Samsung R&D Institute Poland >> >> Change log: >> >> v2: >> - added support for command line based initialization >> >> v1: http://www.spinics.net/lists/linux-samsung-soc/msg37094.html >> - initial version >> >> >> Patch summary: >> >> Tomasz Figa (2): >> serial: samsung: Add support for early console >> ARM: dts: exynos4: Add stdout-path properties >> >> Documentation/kernel-parameters.txt | 10 +++ >> arch/arm/boot/dts/exynos4210-origen.dts | 1 + >> arch/arm/boot/dts/exynos4210-smdkv310.dts | 1 + >> arch/arm/boot/dts/exynos4210-trats.dts | 1 + >> arch/arm/boot/dts/exynos4210-universal_c210.dts | 1 + >> arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 4 + >> arch/arm/boot/dts/exynos4412-origen.dts | 1 + >> arch/arm/boot/dts/exynos4412-smdk4412.dts | 1 + >> arch/arm/boot/dts/exynos4412-tiny4412.dts | 4 + >> arch/arm/boot/dts/exynos4412-trats2.dts | 1 + >> drivers/tty/serial/Kconfig | 1 + >> drivers/tty/serial/samsung.c| 103 >> >> 12 files changed, 129 insertions(+) > > Tested this on ARM64 based exynos7 platform, both command line and DT > ways. Both works well. > Compile tested on ARM. > Not sure if my ACK matters here, but you certainly have my > > Reviewed-by: Alim Akhtar > Tested-by: Alim Akhtar > > I think this is good to go in with a minor comment addressed on 1st patch. > Thanks! A gentle ping. >> >> -- >> 1.9.2 >> >> -- >> 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 > > > > -- > Regards, > Alim -- Regards, Alim -- 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] more dwc2/gadget fixes
Hi! This patchset contains a set of fixes to solve vaious minor issues related to cable connect/disconnect events, pull-up control, soft-disconnect mode, proper usb phy operation and restoring gadget state after suspend/resume cycle. Best regards Marek Szyprowski, PhD Samsung R&D Institute Poland Marek Szyprowski (9): usb: dwc2/gadget: report disconnect event from 'end session' irq usb: dwc2/gadget: fix enumeration issues usb: dwc2/gadget: fix support for soft_connect udc framework feature usb: dwc2/gadget: disable phy before turning off power regulators usb: dwc2/gadget: move setting last reset time to s3c_hsotg_core_init usb: dwc2/gadget: decouple setting soft disconnect from s3c_hsotg_core_init usb: dwc2/gadget: use soft disconnect mode for implementing pullup control usb: dwc2/gadget: fix calls to phy control functions in suspend/resume code usb: dwc2/gadget: rework suspend/resume code to correctly restore gadget state drivers/usb/dwc2/core.h | 4 +- drivers/usb/dwc2/gadget.c | 93 +-- 2 files changed, 69 insertions(+), 28 deletions(-) -- 1.9.2 -- 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] usb: dwc2/gadget: rework suspend/resume code to correctly restore gadget state
Suspend/resume code assumed that the gadget was always enabled and
connected to usb bus. This means that the actual state of the gadget
(soft-enabled/disabled or connected/disconnected) was not correctly
preserved on suspend/resume cycle. This patch fixes this issue.
Signed-off-by: Marek Szyprowski
---
drivers/usb/dwc2/core.h | 4 +++-
drivers/usb/dwc2/gadget.c | 42 ++
2 files changed, 29 insertions(+), 17 deletions(-)
diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
index bf015ab3b44c..3648b76a18b4 100644
--- a/drivers/usb/dwc2/core.h
+++ b/drivers/usb/dwc2/core.h
@@ -210,7 +210,9 @@ struct s3c_hsotg {
u8 ctrl_buff[8];
struct usb_gadget gadget;
- unsigned intsetup;
+ unsigned intsetup:1;
+ unsigned intconnected:1;
+ unsigned intenabled:1;
unsigned long last_rst;
struct s3c_hsotg_ep *eps;
};
diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index 052b1a857291..83fe123ede05 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -2925,6 +2925,8 @@ static int s3c_hsotg_udc_start(struct usb_gadget *gadget,
spin_lock_irqsave(&hsotg->lock, flags);
s3c_hsotg_init(hsotg);
s3c_hsotg_core_init_disconnected(hsotg);
+ hsotg->enabled = 1;
+ hsotg->connected = 0;
spin_unlock_irqrestore(&hsotg->lock, flags);
dev_info(hsotg->dev, "bound driver %s\n", driver->driver.name);
@@ -2963,6 +2965,8 @@ static int s3c_hsotg_udc_stop(struct usb_gadget *gadget,
hsotg->driver = NULL;
hsotg->gadget.speed = USB_SPEED_UNKNOWN;
+ hsotg->enabled = 0;
+ hsotg->connected = 0;
spin_unlock_irqrestore(&hsotg->lock, flags);
@@ -3004,9 +3008,11 @@ static int s3c_hsotg_pullup(struct usb_gadget *gadget,
int is_on)
if (is_on) {
clk_enable(hsotg->clk);
+ hsotg->connected = 1;
s3c_hsotg_core_connect(hsotg);
} else {
s3c_hsotg_core_disconnect(hsotg);
+ hsotg->connected = 0;
clk_disable(hsotg->clk);
}
@@ -3655,16 +3661,18 @@ static int s3c_hsotg_suspend(struct platform_device
*pdev, pm_message_t state)
dev_info(hsotg->dev, "suspending usb gadget %s\n",
hsotg->driver->driver.name);
- spin_lock_irqsave(&hsotg->lock, flags);
- s3c_hsotg_core_disconnect(hsotg);
- s3c_hsotg_disconnect(hsotg);
- hsotg->gadget.speed = USB_SPEED_UNKNOWN;
- spin_unlock_irqrestore(&hsotg->lock, flags);
+ if (hsotg->enabled) {
+ int ep;
- s3c_hsotg_phy_disable(hsotg);
+ spin_lock_irqsave(&hsotg->lock, flags);
+ if (hsotg->connected)
+ s3c_hsotg_core_disconnect(hsotg);
+ s3c_hsotg_disconnect(hsotg);
+ hsotg->gadget.speed = USB_SPEED_UNKNOWN;
+ spin_unlock_irqrestore(&hsotg->lock, flags);
+
+ s3c_hsotg_phy_disable(hsotg);
- if (hsotg->driver) {
- int ep;
for (ep = 0; ep < hsotg->num_of_eps; ep++)
s3c_hsotg_ep_disable(&hsotg->eps[ep].ep);
@@ -3682,21 +3690,23 @@ static int s3c_hsotg_resume(struct platform_device
*pdev)
unsigned long flags;
int ret = 0;
- if (hsotg->driver) {
+ if (hsotg->driver)
dev_info(hsotg->dev, "resuming usb gadget %s\n",
hsotg->driver->driver.name);
+ if (hsotg->enabled) {
clk_enable(hsotg->clk);
ret = regulator_bulk_enable(ARRAY_SIZE(hsotg->supplies),
- hsotg->supplies);
- }
+ hsotg->supplies);
- s3c_hsotg_phy_enable(hsotg);
+ s3c_hsotg_phy_enable(hsotg);
- spin_lock_irqsave(&hsotg->lock, flags);
- s3c_hsotg_core_init_disconnected(hsotg);
- s3c_hsotg_core_connect(hsotg);
- spin_unlock_irqrestore(&hsotg->lock, flags);
+ spin_lock_irqsave(&hsotg->lock, flags);
+ s3c_hsotg_core_init_disconnected(hsotg);
+ if (hsotg->connected)
+ s3c_hsotg_core_connect(hsotg);
+ spin_unlock_irqrestore(&hsotg->lock, flags);
+ }
return ret;
}
--
1.9.2
--
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] usb: dwc2/gadget: fix support for soft_connect udc framework feature
Enabling and disabling usb gadget by writing to /sys/class/udc/*hsotg/soft_connect results in calling udc_start/udc_stop functions with the same usb gadget driver, so the driver should not WARN about such case. Signed-off-by: Marek Szyprowski --- drivers/usb/dwc2/gadget.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c index 8870e38c1d82..37fda4c03397 100644 --- a/drivers/usb/dwc2/gadget.c +++ b/drivers/usb/dwc2/gadget.c @@ -2892,7 +2892,7 @@ static int s3c_hsotg_udc_start(struct usb_gadget *gadget, return -EINVAL; } - WARN_ON(hsotg->driver); + WARN_ON(hsotg->driver && hsotg->driver != driver); driver->driver.bus = NULL; hsotg->driver = driver; -- 1.9.2 -- 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] usb: dwc2/gadget: disable phy before turning off power regulators
This patch fixes probe function to match the pattern used elsewhere in the driver, where power regulators are turned off as the last element in the device shutdown procedure. Signed-off-by: Marek Szyprowski --- drivers/usb/dwc2/gadget.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c index 37fda4c03397..178a6ea5eef8 100644 --- a/drivers/usb/dwc2/gadget.c +++ b/drivers/usb/dwc2/gadget.c @@ -3573,6 +3573,7 @@ static int s3c_hsotg_probe(struct platform_device *pdev) s3c_hsotg_initep(hsotg, &hsotg->eps[epnum], epnum); /* disable power and clock */ + s3c_hsotg_phy_disable(hsotg); ret = regulator_bulk_disable(ARRAY_SIZE(hsotg->supplies), hsotg->supplies); @@ -3581,8 +3582,6 @@ static int s3c_hsotg_probe(struct platform_device *pdev) goto err_ep_mem; } - s3c_hsotg_phy_disable(hsotg); - ret = usb_add_gadget_udc(&pdev->dev, &hsotg->gadget); if (ret) goto err_ep_mem; -- 1.9.2 -- 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] usb: dwc2/gadget: use soft disconnect mode for implementing pullup control
This patch moves PHY enable and disable calls from pullup method to
udc_start/stop functions and adds calls to recently introduces soft
disconnect mode in pullup method. This improves dwc2 gadget driver
compatibility with gadget API requirements (now pullup method really
forces soft disconnect mode instead of shutting down the whole hardware)
and as a side effect also solves the issue related to limited caller
context for PHY related functions (they cannot be called from
non-sleeping context).
Signed-off-by: Marek Szyprowski
---
drivers/usb/dwc2/gadget.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index d039334967d7..cdf417a7ae63 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -2883,6 +2883,7 @@ static int s3c_hsotg_udc_start(struct usb_gadget *gadget,
struct usb_gadget_driver *driver)
{
struct s3c_hsotg *hsotg = to_hsotg(gadget);
+ unsigned long flags;
int ret;
if (!hsotg) {
@@ -2919,7 +2920,15 @@ static int s3c_hsotg_udc_start(struct usb_gadget *gadget,
goto err;
}
+ s3c_hsotg_phy_enable(hsotg);
+
+ spin_lock_irqsave(&hsotg->lock, flags);
+ s3c_hsotg_init(hsotg);
+ s3c_hsotg_core_init_disconnected(hsotg);
+ spin_unlock_irqrestore(&hsotg->lock, flags);
+
dev_info(hsotg->dev, "bound driver %s\n", driver->driver.name);
+
return 0;
err:
@@ -2957,6 +2966,8 @@ static int s3c_hsotg_udc_stop(struct usb_gadget *gadget,
spin_unlock_irqrestore(&hsotg->lock, flags);
+ s3c_hsotg_phy_disable(hsotg);
+
regulator_bulk_disable(ARRAY_SIZE(hsotg->supplies), hsotg->supplies);
clk_disable(hsotg->clk);
@@ -2990,14 +3001,13 @@ static int s3c_hsotg_pullup(struct usb_gadget *gadget,
int is_on)
dev_dbg(hsotg->dev, "%s: is_on: %d\n", __func__, is_on);
spin_lock_irqsave(&hsotg->lock, flags);
+
if (is_on) {
- s3c_hsotg_phy_enable(hsotg);
clk_enable(hsotg->clk);
- s3c_hsotg_core_init_disconnected(hsotg);
s3c_hsotg_core_connect(hsotg);
} else {
+ s3c_hsotg_core_disconnect(hsotg);
clk_disable(hsotg->clk);
- s3c_hsotg_phy_disable(hsotg);
}
hsotg->gadget.speed = USB_SPEED_UNKNOWN;
--
1.9.2
--
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] usb: dwc2/gadget: report disconnect event from 'end session' irq
This patch adds a call to s3c_hsotg_disconnect() from 'end session'
interrupt to correctly notify gadget subsystem about unplugged usb
cable.
Signed-off-by: Marek Szyprowski
---
drivers/usb/dwc2/gadget.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index 7b5856fadd93..119c8a3effc2 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -2279,6 +2279,12 @@ irq_retry:
dev_info(hsotg->dev, "OTGInt: %08x\n", otgint);
writel(otgint, hsotg->regs + GOTGINT);
+
+ if (otgint & GOTGINT_SES_END_DET) {
+ if (hsotg->gadget.speed != USB_SPEED_UNKNOWN)
+ s3c_hsotg_disconnect(hsotg);
+ hsotg->gadget.speed = USB_SPEED_UNKNOWN;
+ }
}
if (gintsts & GINTSTS_SESSREQINT) {
--
1.9.2
--
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 6/9] usb: dwc2/gadget: decouple setting soft disconnect from s3c_hsotg_core_init
This patch changes s3c_hsotg_core_init function to leave hardware in
soft disconnect mode, so the actual moment of coupling the hardware to
the usb bus can be later controlled by the driver in the more accurate
way. For this purpose, separate functions for enabling and disabling
soft disconnect mode have been added.
Signed-off-by: Marek Szyprowski
---
drivers/usb/dwc2/gadget.c | 22 +-
1 file changed, 17 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index 1ba0682fb252..d039334967d7 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -2124,7 +2124,7 @@ static int s3c_hsotg_corereset(struct s3c_hsotg *hsotg)
*
* Issue a soft reset to the core, and await the core finishing it.
*/
-static void s3c_hsotg_core_init(struct s3c_hsotg *hsotg)
+static void s3c_hsotg_core_init_disconnected(struct s3c_hsotg *hsotg)
{
s3c_hsotg_corereset(hsotg);
@@ -2241,14 +2241,23 @@ static void s3c_hsotg_core_init(struct s3c_hsotg *hsotg)
readl(hsotg->regs + DOEPCTL0));
/* clear global NAKs */
- writel(DCTL_CGOUTNAK | DCTL_CGNPINNAK,
+ writel(DCTL_CGOUTNAK | DCTL_CGNPINNAK | DCTL_SFTDISCON,
hsotg->regs + DCTL);
/* must be at-least 3ms to allow bus to see disconnect */
mdelay(3);
hsotg->last_rst = jiffies;
+}
+
+static void s3c_hsotg_core_disconnect(struct s3c_hsotg *hsotg)
+{
+ /* set the soft-disconnect bit */
+ __orr32(hsotg->regs + DCTL, DCTL_SFTDISCON);
+}
+static void s3c_hsotg_core_connect(struct s3c_hsotg *hsotg)
+{
/* remove the soft-disconnect and let's go */
__bic32(hsotg->regs + DCTL, DCTL_SFTDISCON);
}
@@ -2348,7 +2357,8 @@ irq_retry:
kill_all_requests(hsotg, &hsotg->eps[0],
-ECONNRESET, true);
- s3c_hsotg_core_init(hsotg);
+ s3c_hsotg_core_init_disconnected(hsotg);
+ s3c_hsotg_core_connect(hsotg);
}
}
}
@@ -2983,7 +2993,8 @@ static int s3c_hsotg_pullup(struct usb_gadget *gadget,
int is_on)
if (is_on) {
s3c_hsotg_phy_enable(hsotg);
clk_enable(hsotg->clk);
- s3c_hsotg_core_init(hsotg);
+ s3c_hsotg_core_init_disconnected(hsotg);
+ s3c_hsotg_core_connect(hsotg);
} else {
clk_disable(hsotg->clk);
s3c_hsotg_phy_disable(hsotg);
@@ -3670,7 +3681,8 @@ static int s3c_hsotg_resume(struct platform_device *pdev)
spin_lock_irqsave(&hsotg->lock, flags);
s3c_hsotg_phy_enable(hsotg);
- s3c_hsotg_core_init(hsotg);
+ s3c_hsotg_core_init_disconnect(hsotg);
+ s3c_hsotg_core_connect(hsotg);
spin_unlock_irqrestore(&hsotg->lock, flags);
return ret;
--
1.9.2
--
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] usb: dwc2/gadget: fix enumeration issues
Excessive debug messages might cause timing issues that prevent correct usb enumeration. This patch hides information about USB bus reset to let driver enumerate fast enough to avoid making host angry. This fixes endless enumeration and usb reset loop observed with some Linux hosts. Signed-off-by: Marek Szyprowski --- drivers/usb/dwc2/gadget.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c index 119c8a3effc2..8870e38c1d82 100644 --- a/drivers/usb/dwc2/gadget.c +++ b/drivers/usb/dwc2/gadget.c @@ -2333,7 +2333,7 @@ irq_retry: u32 usb_status = readl(hsotg->regs + GOTGCTL); - dev_info(hsotg->dev, "%s: USBRst\n", __func__); + dev_dbg(hsotg->dev, "%s: USBRst\n", __func__); dev_dbg(hsotg->dev, "GNPTXSTS=%08x\n", readl(hsotg->regs + GNPTXSTS)); -- 1.9.2 -- 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] usb: dwc2/gadget: move setting last reset time to s3c_hsotg_core_init
This patch removes duplicated code and sets last_rst variable in the function which does the hardware reset. Signed-off-by: Marek Szyprowski --- drivers/usb/dwc2/gadget.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c index 178a6ea5eef8..1ba0682fb252 100644 --- a/drivers/usb/dwc2/gadget.c +++ b/drivers/usb/dwc2/gadget.c @@ -2247,6 +2247,8 @@ static void s3c_hsotg_core_init(struct s3c_hsotg *hsotg) /* must be at-least 3ms to allow bus to see disconnect */ mdelay(3); + hsotg->last_rst = jiffies; + /* remove the soft-disconnect and let's go */ __bic32(hsotg->regs + DCTL, DCTL_SFTDISCON); } @@ -2347,7 +2349,6 @@ irq_retry: -ECONNRESET, true); s3c_hsotg_core_init(hsotg); - hsotg->last_rst = jiffies; } } } @@ -2908,7 +2909,6 @@ static int s3c_hsotg_udc_start(struct usb_gadget *gadget, goto err; } - hsotg->last_rst = jiffies; dev_info(hsotg->dev, "bound driver %s\n", driver->driver.name); return 0; @@ -3669,7 +3669,6 @@ static int s3c_hsotg_resume(struct platform_device *pdev) } spin_lock_irqsave(&hsotg->lock, flags); - hsotg->last_rst = jiffies; s3c_hsotg_phy_enable(hsotg); s3c_hsotg_core_init(hsotg); spin_unlock_irqrestore(&hsotg->lock, flags); -- 1.9.2 -- 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 8/9] usb: dwc2/gadget: fix calls to phy control functions in suspend/resume code
This patch moves calls to phy enable/disable out of spinlock protected
blocks in device suspend/resume to fix incorrect caller context. Phy
related functions must not be called from atomic context.
Signed-off-by: Marek Szyprowski
---
drivers/usb/dwc2/gadget.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index cdf417a7ae63..052b1a857291 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -3656,11 +3656,13 @@ static int s3c_hsotg_suspend(struct platform_device
*pdev, pm_message_t state)
hsotg->driver->driver.name);
spin_lock_irqsave(&hsotg->lock, flags);
+ s3c_hsotg_core_disconnect(hsotg);
s3c_hsotg_disconnect(hsotg);
- s3c_hsotg_phy_disable(hsotg);
hsotg->gadget.speed = USB_SPEED_UNKNOWN;
spin_unlock_irqrestore(&hsotg->lock, flags);
+ s3c_hsotg_phy_disable(hsotg);
+
if (hsotg->driver) {
int ep;
for (ep = 0; ep < hsotg->num_of_eps; ep++)
@@ -3689,9 +3691,10 @@ static int s3c_hsotg_resume(struct platform_device *pdev)
hsotg->supplies);
}
- spin_lock_irqsave(&hsotg->lock, flags);
s3c_hsotg_phy_enable(hsotg);
- s3c_hsotg_core_init_disconnect(hsotg);
+
+ spin_lock_irqsave(&hsotg->lock, flags);
+ s3c_hsotg_core_init_disconnected(hsotg);
s3c_hsotg_core_connect(hsotg);
spin_unlock_irqrestore(&hsotg->lock, flags);
--
1.9.2
--
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 v3] ARM: dts: add CPU nodes for Exynos4 SoCs
On Thu, Sep 25, 2014 at 09:26:03AM +0100, Kukjin Kim wrote: > On 09/25/14 17:17, Lorenzo Pieralisi wrote: > > [CC'ed Daniel to make him aware this patch goes through your tree] > > > Thanks and just note the branch which is including this change actually > v4 is just rebased not v3 will be sent out to arm-soc last tonight or > tomorrow. What's the plan for patch ? I do not see it upstream and would like to rebase the Exynos CPUidle changes on top of it. Thanks, 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: [PATCH 2/9] regulator: max77802: Add .{get,set}_mode callbacks
Hello Mark,
Thanks a lot for your feedback.
On 10/16/2014 10:36 AM, Mark Brown wrote:
> On Wed, Oct 15, 2014 at 06:20:32PM +0200, Javier Martinez Canillas wrote:
>
>> +#define MAX77802_MODE(pval) ((pval == MAX77802_OPMODE_NORMAL) ? \
>> + REGULATOR_MODE_NORMAL : REGULATOR_MODE_STANDBY)
>> +
>
> Make this a static inline function if there's any need for it, this is
> both more legible and more helpful for the compiler.
>
Ok, will change that.
>> +switch (mode) {
>> +case REGULATOR_MODE_IDLE:
>> +case REGULATOR_MODE_STANDBY:
>> +val = MAX77802_OPMODE_LP; /* ON in Low Power Mode */
>> +break;
>
> You should never have multiple modes mapping onto a singel value - if
> the user sets a mode they should find that the device has that mode.
>
I see, thanks for the clarification. I think STANDBY better maps the device
Low Power Mode according the description in include/linux/regulator/consumer.h
so I'll just make IDLE invalid in v2.
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 v2 1/2] Revert "mfd: sec-core: Prepare regulators for suspend state to reduce power-consumption"
This reverts commit b7cde7078d2344073c310aa65fc2b0a845d2cb5b
("mfd: sec-core: Prepare regulators for suspend state to reduce
power-consumption")
Commit b7cde7078d23 called regulator_suspend_prepare() to prepare the
regulators for a suspend state. But did it from the device pm suspend
handler but regulator_suspend_prepare() iterates over all regulators
and not only the one managed by this device so it doesn't seems to be
correct to call it from a device driver.
It is better to call the regulator suspend prepare/finish functions
from platform code instead so this patch reverts the mentioned commit.
---
drivers/mfd/Kconfig| 1 -
drivers/mfd/sec-core.c | 10 --
2 files changed, 11 deletions(-)
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 1456ea7..fd8cc4c 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -655,7 +655,6 @@ config MFD_SEC_CORE
select MFD_CORE
select REGMAP_I2C
select REGMAP_IRQ
- select REGULATOR
help
Support for the Samsung Electronics MFD series.
This driver provides common support for accessing the device,
diff --git a/drivers/mfd/sec-core.c b/drivers/mfd/sec-core.c
index dba7e2b..5993608 100644
--- a/drivers/mfd/sec-core.c
+++ b/drivers/mfd/sec-core.c
@@ -31,7 +31,6 @@
#include
#include
#include
-#include
#include
static const struct mfd_cell s5m8751_devs[] = {
@@ -432,15 +431,6 @@ static int sec_pmic_suspend(struct device *dev)
*/
disable_irq(sec_pmic->irq);
- switch (sec_pmic->device_type) {
- case S2MPS14X:
- case S2MPU02:
- regulator_suspend_prepare(PM_SUSPEND_MEM);
- break;
- default:
- break;
- }
-
return 0;
}
--
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 v2 0/2] ARM: EXYNOS: Call regulator suspend prepare/finish
Hello, This series add support for Exynos platforms to prepare regulators for system suspend. The regulator core has a set of helpers functions to be used when the system is entering and leaving from a suspend state but currently there is only one user in mainline. This user is drivers/mfd/sec-core.c but it calls regulator_suspend_prepare() from within the driver power-management suspend function. This does not seems to be correct since the regulator suspend prepare function affects all regulators in the system and not only the ones managed by this device. So patch #1 in this series revert the commit that introduced that change and patch #2 calls the regulator framework suspend/finish functions from the Exynos platform power-management code. The first patch should be queued through the mfd tree and the second through the linux-samsung tree. Changes since v1: - Remove the call to regulator_suspend_prepare() from drivers/mfd/sec-core.c as suggested by Doug Anderson. - Call regulator_suspend_prepare() before s3c_pm_check_prepare() as suggested by Doug Anderson. - Added Lee Jones to cc list since there is a change for the mfd framework. Javier Martinez Canillas (2): Revert "mfd: sec-core: Prepare regulators for suspend state to reduce power-consumption" ARM: EXYNOS: Call regulator core suspend prepare and finish functions arch/arm/mach-exynos/suspend.c | 18 ++ drivers/mfd/Kconfig| 1 - drivers/mfd/sec-core.c | 10 -- 3 files changed, 18 insertions(+), 11 deletions(-) NOTES: * The drivers/mfd/sec-core.c only called regulator_suspend_prepare() on suspend but did not call regulator_suspend_finish() on resume so this series changes the assumption the driver did that the regulators .enable functions won't be called on resume and the regulators should be recovered automatically from suspend. So it may cause issues on this device since the semantics are changed. But I think not calling suspend finish was not correct in the first place. * This could also be made from the suspend core (kernel/power/suspend.c) to avoid each platform support having the same code but I was not sure about this so I decided to it at the platform level. Another option is that the regulator core register a pm_notifier that could handle the PM_SUSPEND_PREPARE and PM_POST_SUSPEND events. 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 v2 2/2] 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 by regulator drivers are not called when the system is suspended.
Suggested-by: Doug Anderson
Signed-off-by: Javier Martinez Canillas
---
arch/arm/mach-exynos/suspend.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/arch/arm/mach-exynos/suspend.c b/arch/arm/mach-exynos/suspend.c
index cc8d237..ee9a8e0 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
@@ -443,6 +444,22 @@ static int exynos_suspend_enter(suspend_state_t state)
static int exynos_suspend_prepare(void)
{
+ int ret;
+
+ /*
+* 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 now only because the suspend_valid_only_mem function is
+* used as the .valid callback used to check if a given state
+* is supported by the platform anyways.
+*/
+ ret = regulator_suspend_prepare(PM_SUSPEND_MEM);
+ if (ret) {
+ pr_err("Failed to prepare regulators for system suspend\n");
+ return ret;
+ }
+
s3c_pm_check_prepare();
return 0;
@@ -451,6 +468,7 @@ static int exynos_suspend_prepare(void)
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 V7 11/12] Documentation: bridge: Add documentation for ps8622 DT properties
Hi Ajay, On Friday 10 October 2014 18:33:05 Ajay kumar wrote: > On Wed, Oct 8, 2014 at 12:39 PM, Thierry Reding wrote: > > On Tue, Oct 07, 2014 at 05:49:24PM +0300, Laurent Pinchart wrote: > >> On Tuesday 07 October 2014 16:06:55 Ajay kumar wrote: > >> > On Tue, Oct 7, 2014 at 4:00 PM, Tomi Valkeinen wrote: > >> > > On 20/09/14 14:22, Ajay kumar wrote: > >> > >> Well, I am okay with using video ports to describe the relationship > >> > >> between the encoder, bridge and the panel. > >> > >> But, its just that I need to make use of 2 functions when phandle > >> > >> does it using just one function ;) > >> > >> -panel_node = of_parse_phandle(dev->of_node, "panel", 0) > >> > >> + endpoint = of_graph_get_next_endpoint(dev->of_node, NULL); > >> > >> + if (!endpoint) > >> > >> + return -EPROBE_DEFER; > >> > >> + > >> > >> + panel_node = of_graph_get_remote_port_parent(endpoint); > >> > >> + if (!panel_node) > >> > >> + return -EPROBE_DEFER; > >> > >> > >> > >> > >> > >> If nobody else has objections over using of_graph functions instead > >> > >> of phandles, I can respin this patchset by making use of video > >> > >> ports. > >> > > > >> > > The discussion did digress somewhat. > >> > > > >> > > As a clarification, I'm in no way nack'ing this series because it > >> > > doesn't use the graphs for video connections. I don't see the simple > >> > > phandle bindings used here as broken as such. > >> > > >> > Well, I am okay with any approach you guys decide on. I desperately > >> > want this to get this in since it has been floating around for quite > >> > sometime. The more we drag this, the more rework for me since the > >> > number of platforms using bridge support is increasing daily! > >> > >> I won't nack this patch either. I'm however concerned that we'll run > >> straight into the wall if we don't come up with an agreement on a > >> standard way to describe connections in DT for display devices, which is > >> why I would prefer the ps8622 bindings to use OF graph to describe > >> connections. > > > > I think there's not really an easy way out here. It's pretty bold trying > > to come up with a common way to describe bridges when we have only a > > single one (and a single use-case at that). The worst that can happen is > > that we need to change the binding at some point, in which case we may > > have to special-case early drivers, but I really don't think that's as > > much of an issue as everybody seems to think. > > > > This series has been floating around for months because we're being > > overly prudent to accept a binding that /may/ turn out to not be generic > > enough. > > Right. It would be great if you guys come to agreement ASAP! I don't think we'll agree any time soon, so I believe it's up to you to decide which option is best based on all arguments that have been presented. If you ask me, of course, OF graph is best :-) -- Regards, Laurent Pinchart -- 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 3/9] regulator: max77802: Split regulator operations for BUCKs
On Wed, Oct 15, 2014 at 06:20:33PM +0200, Javier Martinez Canillas wrote: > 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. Applied, thanks. signature.asc Description: Digital signature
Re: [PATCH 1/9] regulator: max77802: Add .set_suspend_{enable,disable} callbacks
On Wed, Oct 15, 2014 at 06:20:31PM +0200, Javier Martinez Canillas wrote: > 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. Applied, thanks. signature.asc Description: Digital signature
Re: [PATCH 2/9] regulator: max77802: Add .{get,set}_mode callbacks
On Wed, Oct 15, 2014 at 06:20:32PM +0200, Javier Martinez Canillas wrote:
> +#define MAX77802_MODE(pval) ((pval == MAX77802_OPMODE_NORMAL) ? \
> + REGULATOR_MODE_NORMAL : REGULATOR_MODE_STANDBY)
> +
Make this a static inline function if there's any need for it, this is
both more legible and more helpful for the compiler.
> + switch (mode) {
> + case REGULATOR_MODE_IDLE:
> + case REGULATOR_MODE_STANDBY:
> + val = MAX77802_OPMODE_LP; /* ON in Low Power Mode */
> + break;
You should never have multiple modes mapping onto a singel value - if
the user sets a mode they should find that the device has that mode.
signature.asc
Description: Digital signature
Re: [PATCH V7 11/12] Documentation: bridge: Add documentation for ps8622 DT properties
ping! On Fri, Oct 10, 2014 at 6:33 PM, Ajay kumar wrote: > On Wed, Oct 8, 2014 at 12:39 PM, Thierry Reding > wrote: >> On Tue, Oct 07, 2014 at 05:49:24PM +0300, Laurent Pinchart wrote: >>> Hi Ajay, >>> >>> On Tuesday 07 October 2014 16:06:55 Ajay kumar wrote: >>> > On Tue, Oct 7, 2014 at 4:00 PM, Tomi Valkeinen wrote: >>> > > On 20/09/14 14:22, Ajay kumar wrote: >>> > >> Well, I am okay with using video ports to describe the relationship >>> > >> between the encoder, bridge and the panel. >>> > >> But, its just that I need to make use of 2 functions when phandle >>> > >> does it using just one function ;) >>> > >> -panel_node = of_parse_phandle(dev->of_node, "panel", 0) >>> > >> + endpoint = of_graph_get_next_endpoint(dev->of_node, NULL); >>> > >> + if (!endpoint) >>> > >> + return -EPROBE_DEFER; >>> > >> + >>> > >> + panel_node = of_graph_get_remote_port_parent(endpoint); >>> > >> + if (!panel_node) >>> > >> + return -EPROBE_DEFER; >>> > >> >>> > >> >>> > >> If nobody else has objections over using of_graph functions instead >>> > >> of phandles, I can respin this patchset by making use of video ports. >>> > > >>> > > The discussion did digress somewhat. >>> > > >>> > > As a clarification, I'm in no way nack'ing this series because it >>> > > doesn't use the graphs for video connections. I don't see the simple >>> > > phandle bindings used here as broken as such. >>> > >>> > Well, I am okay with any approach you guys decide on. I desperately want >>> > this to get this in since it has been floating around for quite sometime. >>> > The more we drag this, the more rework for me since the number of >>> > platforms >>> > using bridge support is increasing daily! >>> >>> I won't nack this patch either. I'm however concerned that we'll run >>> straight >>> into the wall if we don't come up with an agreement on a standard way to >>> describe connections in DT for display devices, which is why I would prefer >>> the ps8622 bindings to use OF graph to describe connections. >> >> I think there's not really an easy way out here. It's pretty bold trying >> to come up with a common way to describe bridges when we have only a >> single one (and a single use-case at that). The worst that can happen is >> that we need to change the binding at some point, in which case we may >> have to special-case early drivers, but I really don't think that's as >> much of an issue as everybody seems to think. >> >> This series has been floating around for months because we're being >> overly prudent to accept a binding that /may/ turn out to not be generic >> enough. > Right. It would be great if you guys come to agreement ASAP! > > Ajay -- 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
Javier Martinez Canillas wrote: > > Hello Kukjin, > Hi, > On Thu, Oct 16, 2014 at 3:01 AM, Kukjin Kim wrote: > > 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? > > > + Arnd, Olof and regarding MLs > There are other bugfixes for 3.18 that ended in next/late so it would > be good if you do a new pull request to include those as well. > > The commits (with hashes from linux-next) are: > > 3f3d046 ARM: dts: Remove display timings node from exynos5250-snow > dd12ac7 ARM: dts: Fix chip select GPIO on exynos5250-smdk5250 > c04c92e ARM: dts: Add rtc_src clk for s3c-rtc on exynos5250-snow > 8bd43b6 ARM: dts: Add rtc_src clk for s3c-rtc on exynos Peach boards > I checked its dependent clock patches have been merged into mainline just now. As you know, the patches blocked dt patches in this time :( Anyway, I'll try to send a pull-request with including above patches tonight. Thanks for your gentle reminder. Olof, I think it makes sense because it is related fixes for 3.18 ;) Sorry for late noise... Thanks, 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
