Re: [PATCH 1/2] mmc: dw_mmc: exynos: Add the exynos3250 compatible
On 22.10.2015 14:14, Jaehoon Chung wrote:
> On 10/22/2015 12:51 PM, Krzysztof Kozlowski wrote:
>> On 22.10.2015 11:54, Jaehoon Chung wrote:
>>> Hi, Krzysztof.
>>>
>>> On 10/22/2015 09:06 AM, Krzysztof Kozlowski wrote:
On 21.10.2015 15:39, Jaehoon Chung wrote:
> To check more exactly, add the exynos3250 compatible.
> Not use exynos5250 compatibility.
Hi,
I can't find any difference between old and new compatible. Maybe I am
missing something? Maybe there is a difference for these devices?
>>>
>>> Sorry, I needs to add more explanation about changing compatible.
>>> Exynos3250 has more registers than exynos5250 in dwmmc IP.
>>> Now, we used dwmmc controller with exynos5250 compatible.
>>> Then some codes can't run in dw-mmc.c, if SoC is exynos3250.
>>> For example, there is the checking point in dw_mci_exynos_config_hs400().
>>>
>>> static void dw_mci_exynos_config_hs400(struct dw_mci *host, u32 timing)
>>> {
>>> struct dw_mci_exynos_priv_data *priv = host->priv;
>>> u32 dqs, strobe;
>>>
>>> /*
>>> * Not supported to configure register
>>> * related to HS400
>>> */
>>> if (priv->ctrl_type < DW_MCI_TYPE_EXYNOS5420)
>>> return;
>>>
>>> dqs = priv->saved_dqs_en;
>>> strobe = priv->saved_strobe_ctrl;
>>>
>>> It can't use this feature with exynos5250 compatible.
>>
>> Ahh, I see it now. I missed that context and commit message wasn't
>> explaining this real reason. This real reason - supporting HS400 or
>> other features not present on Exynos5250 - was not mentioned.
>
> Right, it's not enough to explain why needs this patch.
>
>>
>> The new compatible make sense now... but I am wondering if instead just
>> "samsung,exynos5420-dw-mshc" should be used? I think it would give the
>> same result as your change and if new compatible is not required then it
>> will be better not to add it.
>
> I need to check whether it can be used with "samsung,exynos5420-dw-mshc".
> If you don't want to add new compatible, then i will check Exynos5420 TRM.
> Maybe, i think it can be used with it.
>
> Is it good that use more exact compatible?
>
Actually one thing is the real compatibility of devices and second is
the source code.
Looking at the source code, the behaviour for new exynos3250 compatible
and "samsung,exynos5420-dw-mshc" would be the same, right? This would be
a indication for reusing existing compatible. No need to create new one.
However maybe the devices aren't really compatible and using the same
compatible would prevent adding new features to Exynos5420?
Best regards,
Krzysztof
--
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/2] mmc: dw_mmc: exynos: Add the exynos3250 compatible
On 10/22/2015 12:51 PM, Krzysztof Kozlowski wrote:
> On 22.10.2015 11:54, Jaehoon Chung wrote:
>> Hi, Krzysztof.
>>
>> On 10/22/2015 09:06 AM, Krzysztof Kozlowski wrote:
>>> On 21.10.2015 15:39, Jaehoon Chung wrote:
To check more exactly, add the exynos3250 compatible.
Not use exynos5250 compatibility.
>>>
>>> Hi,
>>>
>>> I can't find any difference between old and new compatible. Maybe I am
>>> missing something? Maybe there is a difference for these devices?
>>
>> Sorry, I needs to add more explanation about changing compatible.
>> Exynos3250 has more registers than exynos5250 in dwmmc IP.
>> Now, we used dwmmc controller with exynos5250 compatible.
>> Then some codes can't run in dw-mmc.c, if SoC is exynos3250.
>> For example, there is the checking point in dw_mci_exynos_config_hs400().
>>
>> static void dw_mci_exynos_config_hs400(struct dw_mci *host, u32 timing)
>> {
>> struct dw_mci_exynos_priv_data *priv = host->priv;
>> u32 dqs, strobe;
>>
>> /*
>> * Not supported to configure register
>> * related to HS400
>> */
>> if (priv->ctrl_type < DW_MCI_TYPE_EXYNOS5420)
>> return;
>>
>> dqs = priv->saved_dqs_en;
>> strobe = priv->saved_strobe_ctrl;
>>
>> It can't use this feature with exynos5250 compatible.
>
> Ahh, I see it now. I missed that context and commit message wasn't
> explaining this real reason. This real reason - supporting HS400 or
> other features not present on Exynos5250 - was not mentioned.
Right, it's not enough to explain why needs this patch.
>
> The new compatible make sense now... but I am wondering if instead just
> "samsung,exynos5420-dw-mshc" should be used? I think it would give the
> same result as your change and if new compatible is not required then it
> will be better not to add it.
I need to check whether it can be used with "samsung,exynos5420-dw-mshc".
If you don't want to add new compatible, then i will check Exynos5420 TRM.
Maybe, i think it can be used with it.
Is it good that use more exact compatible?
Best Regards,
Jaehoon Chung
>
> Best regards,
> Krzysztof
>
>>
>> Does it need to change the compatible from exynos5250 to exynos3250?
>>
>> Beset Regards,
>> Jaehoon Chung
>>
>>>
>>> Anyway if the code is the same then it should use exactly the same
>>> compatible.
>>>
>>> Best regards,
>>> Krzysztof
>>>
Signed-off-by: Jaehoon Chung
---
Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt | 2 ++
drivers/mmc/host/dw_mmc-exynos.c | 7 +++
2 files changed, 9 insertions(+)
diff --git a/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt
b/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt
index aad9844..cd22ac9 100644
--- a/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt
+++ b/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt
@@ -22,6 +22,8 @@ Required Properties:
specific extensions.
- "samsung,exynos7-dw-mshc-smu": for controllers with Samsung Exynos7
specific extensions having an SMU.
+ - "samsung,exynos3250-dw-mshc": for controllers with Samsung Exynos3250
+specific extensions.
* samsung,dw-mshc-ciu-div: Specifies the divider value for the card
interface
unit (ciu) clock. This property is applicable only for Exynos5 SoC's and
diff --git a/drivers/mmc/host/dw_mmc-exynos.c
b/drivers/mmc/host/dw_mmc-exynos.c
index 1e75309..1c96218 100644
--- a/drivers/mmc/host/dw_mmc-exynos.c
+++ b/drivers/mmc/host/dw_mmc-exynos.c
@@ -32,6 +32,7 @@ enum dw_mci_exynos_type {
DW_MCI_TYPE_EXYNOS5420_SMU,
DW_MCI_TYPE_EXYNOS7,
DW_MCI_TYPE_EXYNOS7_SMU,
+ DW_MCI_TYPE_EXYNOS3250,
};
/* Exynos implementation specific driver private data */
@@ -73,6 +74,9 @@ static struct dw_mci_exynos_compatible {
}, {
.compatible = "samsung,exynos7-dw-mshc-smu",
.ctrl_type = DW_MCI_TYPE_EXYNOS7_SMU,
+ }, {
+ .compatible = "samsung,exynos3250-dw-mshc",
+ .ctrl_type = DW_MCI_TYPE_EXYNOS3250,
},
};
@@ -467,6 +471,7 @@ static int dw_mci_exynos_execute_tuning(struct
dw_mci_slot *slot)
} while (start_smpl != smpl);
found = dw_mci_exynos_get_best_clksmpl(candiates);
+
if (found >= 0) {
dw_mci_exynos_set_clksmpl(host, found);
priv->tuned_sample = found;
@@ -520,6 +525,8 @@ static const struct of_device_id dw_mci_exynos_match[]
= {
.data = &exynos_drv_data, },
{ .compatible = "samsung,exynos7-dw-mshc-smu",
.data = &exynos_drv_data, },
+ { .compatible = "samsung,exynos3250-dw-mshc",
+ .data = &exynos_drv_data, },
{},
};
MODULE_DEVICE_TAB
Re: [PATCH] mmc: pwrseq: Use highest priority for eMMC restart handler
Hi Javier, On 22 October 2015 at 08:22, Javier Martinez Canillas wrote: > Hello Krzysztof, > > On 10/22/2015 03:43 AM, Krzysztof Kozlowski wrote: >> On 22.10.2015 10:20, Javier Martinez Canillas wrote:> Hello Krzysztof, >>> >>> Thanks for your feedback. >>> >>> On 10/22/2015 02:36 AM, Krzysztof Kozlowski wrote: On 22.10.2015 00:15, Javier Martinez Canillas wrote: > The pwrseq_emmc driver does a eMMC card reset before a system reboot to > allow broken or limited ROM boot-loaders (that don't have an eMMC reset > logic) to be able to read the second stage from the eMMC. > > But this has to be called before a system reboot handler and while most > of them use the priority 128, there are other restart handlers (such as > the syscon-reboot one) that use a higher priority. So, use the highest > priority to make sure that the eMMC hw is reset before a system reboot. > > Signed-off-by: Javier Martinez Canillas > Tested-by: Markus Reichl > Tested-by: Anand Moon > Reviewed-by: Alim Akhtar > > --- > Hello, > > This patch was needed since a recent series from Alim [0] added > syscon reboot and poweroff support to Exynos SoCs and removed > the reset handler in the Exynos Power Management Unit (PMU) code. > > But the PMU and syscon-reboot restart handler have a different > priority so [0] breaks restart when eMMC is used on these boards. > > [0]: http://www.spinics.net/lists/arm-kernel/msg454396.html > > So this patch must be merged before [0] to avoid regressions. > > Best regards, > Javier > > drivers/mmc/core/pwrseq_emmc.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/drivers/mmc/core/pwrseq_emmc.c > b/drivers/mmc/core/pwrseq_emmc.c > index 137c97fb7aa8..ad4f94ec7e8d 100644 > --- a/drivers/mmc/core/pwrseq_emmc.c > +++ b/drivers/mmc/core/pwrseq_emmc.c > @@ -84,11 +84,11 @@ struct mmc_pwrseq *mmc_pwrseq_emmc_alloc(struct > mmc_host *host, > >/* > * register reset handler to ensure emmc reset also from > - * emergency_reboot(), priority 129 schedules it just before > - * system reboot > + * emergency_reboot(), priority 255 is the highest priority > + * so it will be executed before any system reboot handler. > */ >pwrseq->reset_nb.notifier_call = mmc_pwrseq_emmc_reset_nb; > - pwrseq->reset_nb.priority = 129; > + pwrseq->reset_nb.priority = 255; I see the problem which you are trying to solve but this may be tricker then just kicking the number. Some of restart handlers are registered with priority 192. I found few of such, like: at91_restart_nb, zynq_slcr_restart_nb, rmobile_reset_nb (maybe more, I did not grep too much). >>> >>> Yes, the syscon-reboot restart handler also uses a priority 192 and that >>> is why reboot with eMMC broke with Alim's patches since the PMU restart >>> handler priority is 128. >>> I guess they chose the "192" priority on purpose. >>> >>> I tried to understand what's the policy w.r.t priority numbering for >>> restart handlers but only found this in the register_restart_handler >>> kernel-doc [0]: >>> >>> /** >>> * register_restart_handler - Register function to be called to reset >>> * the system >>> * @nb: Info about handler function to be called >>> * @nb->priority: Handler priority. Handlers should follow the >>> * following guidelines for setting priorities. >>> * 0: Restart handler of last resort, >>> * with limited restart capabilities >>> * 128:Default restart handler; use if no other >>> * restart handler is expected to be available, >>> * and/or if restart functionality is >>> * sufficient to restart the entire system >>> * 255:Highest priority restart handler, will >>> * preempt all other restart handlers >>> >>> So, reading that is not clear to me if only the values 0, 128 and 255 >>> should be used or any value from 0-255. >>> >>> What's clear to me is that restart handlers to reset a specific hw block >>> should be called before the restart handler that resets the whole system. >>> >>> The 192 seems to be used because there are other default restart handlers >>> that are using a prio of 128. See for example the commit that changed the >>> syscon-reboot prio from 128 to 192: >>> >>> b81180b3fd48 power: reset: adjust priority of simple syscon reboot driver >> >> But were are here not talking about syscon handler but the others. Now >> you will be ahead of them. >> > > Yes, I know that. My point was that the platforms were either not using the > mmc-pwrseq-emmc or their system restart handler already had
Re: [PATCH] mmc: pwrseq: Use highest priority for eMMC restart handler
CCing Doug, Heiko and Enric Balletbo To help us by testing on rk3288-veyron and am335x-sl50 boards. On 10/22/2015 08:22 AM, Javier Martinez Canillas wrote: Hello Krzysztof, On 10/22/2015 03:43 AM, Krzysztof Kozlowski wrote: On 22.10.2015 10:20, Javier Martinez Canillas wrote:> Hello Krzysztof, Thanks for your feedback. On 10/22/2015 02:36 AM, Krzysztof Kozlowski wrote: On 22.10.2015 00:15, Javier Martinez Canillas wrote: The pwrseq_emmc driver does a eMMC card reset before a system reboot to allow broken or limited ROM boot-loaders (that don't have an eMMC reset logic) to be able to read the second stage from the eMMC. But this has to be called before a system reboot handler and while most of them use the priority 128, there are other restart handlers (such as the syscon-reboot one) that use a higher priority. So, use the highest priority to make sure that the eMMC hw is reset before a system reboot. Signed-off-by: Javier Martinez Canillas Tested-by: Markus Reichl Tested-by: Anand Moon Reviewed-by: Alim Akhtar --- Hello, This patch was needed since a recent series from Alim [0] added syscon reboot and poweroff support to Exynos SoCs and removed the reset handler in the Exynos Power Management Unit (PMU) code. But the PMU and syscon-reboot restart handler have a different priority so [0] breaks restart when eMMC is used on these boards. [0]: http://www.spinics.net/lists/arm-kernel/msg454396.html So this patch must be merged before [0] to avoid regressions. Best regards, Javier drivers/mmc/core/pwrseq_emmc.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/mmc/core/pwrseq_emmc.c b/drivers/mmc/core/pwrseq_emmc.c index 137c97fb7aa8..ad4f94ec7e8d 100644 --- a/drivers/mmc/core/pwrseq_emmc.c +++ b/drivers/mmc/core/pwrseq_emmc.c @@ -84,11 +84,11 @@ struct mmc_pwrseq *mmc_pwrseq_emmc_alloc(struct mmc_host *host, /* * register reset handler to ensure emmc reset also from -* emergency_reboot(), priority 129 schedules it just before -* system reboot +* emergency_reboot(), priority 255 is the highest priority +* so it will be executed before any system reboot handler. */ pwrseq->reset_nb.notifier_call = mmc_pwrseq_emmc_reset_nb; - pwrseq->reset_nb.priority = 129; + pwrseq->reset_nb.priority = 255; I see the problem which you are trying to solve but this may be tricker then just kicking the number. Some of restart handlers are registered with priority 192. I found few of such, like: at91_restart_nb, zynq_slcr_restart_nb, rmobile_reset_nb (maybe more, I did not grep too much). Yes, the syscon-reboot restart handler also uses a priority 192 and that is why reboot with eMMC broke with Alim's patches since the PMU restart handler priority is 128. I guess they chose the "192" priority on purpose. I tried to understand what's the policy w.r.t priority numbering for restart handlers but only found this in the register_restart_handler kernel-doc [0]: /** * register_restart_handler - Register function to be called to reset *the system * @nb: Info about handler function to be called * @nb->priority: Handler priority. Handlers should follow the * following guidelines for setting priorities. * 0: Restart handler of last resort, * with limited restart capabilities * 128:Default restart handler; use if no other * restart handler is expected to be available, * and/or if restart functionality is * sufficient to restart the entire system * 255:Highest priority restart handler, will * preempt all other restart handlers So, reading that is not clear to me if only the values 0, 128 and 255 should be used or any value from 0-255. What's clear to me is that restart handlers to reset a specific hw block should be called before the restart handler that resets the whole system. The 192 seems to be used because there are other default restart handlers that are using a prio of 128. See for example the commit that changed the syscon-reboot prio from 128 to 192: b81180b3fd48 power: reset: adjust priority of simple syscon reboot driver But were are here not talking about syscon handler but the others. Now you will be ahead of them. Yes, I know that. My point was that the platforms were either not using the mmc-pwrseq-emmc or their system restart handler already had a lower priority but that is not true for at least rk3288-veyron as you said. So probably the 192 value was chosen because is in the middle of 128 and 255 but it seems to me a rather arbitrary value and I would prefer it to be documented in some place. Effectively, now the emmc handler will be executed before their handlers.
Re: [PATCH v2 0/6] Switch to generic syscon regmap based drivers
On 10/22/2015 05:47 AM, Krzysztof Kozlowski wrote:
On 22.10.2015 00:01, Alim Akhtar wrote:
On Wed, Oct 21, 2015 at 8:25 PM, Javier Martinez Canillas
wrote:
Hello Alim,
On 10/21/2015 04:50 PM, Alim Akhtar wrote:
[snip]
[0]:
From c9b250ee03bae338339b70693e906145c719f783 Mon Sep 17 00:00:00 2001
From: Javier Martinez Canillas
Date: Wed, 21 Oct 2015 11:59:44 +0200
Subject: [RFT PATCH] mmc: pwrseq: Use highest priority for eMMC restart
handler
The pwrseq_emmc driver does a eMMC card reset before a system reboot to
allow broken or limited ROM boot-loaders, that don't have an eMMC reset
logic, to be able to read the second stage from the eMMC.
But this has to be called before a system reboot handler and while most
of them use the priority 128, there are other restart handlers (such as
the syscon-reboot one) that use a higher priority. So, use the highest
priority to make sure that the eMMC hw is reset before a system reboot.
Signed-off-by: Javier Martinez Canillas
---
Looks good.
Reviewed-by: Alim Akhtar
+Cc Ulf,
Javier,
First of all, thanks Javier for digging into the issue. Actually I have
Odroid U3 but because of user-space limitations (which I need for other
work) I cannot test all of mainline patches there.
Thanks, should I post it as a proper patch or are adding it to your
series?
Suggest you to post as a patch collecting {Tested, Reviewed}-by (easy
for maintainers to pickup ) and probably CCing Ulf for his feedback.
I think the latter is more reasonable so with an ack from Ulf,
all patches can go through the linux-samsung tree.
yes, that is reasonable, as I said, let Krzysztof and Ulf take a call here.
Javier, Alim, Ulf,
I am not grabbing any more patches for v4.4 because I doubt that they
could be merged to arm-soc for this cycle. My last pull requests for
v4.4 is still pending...
This means that I plan to pick up these series for v4.5, after closing
v4.4 merge window (unless Kukjin picks it also). Because of that, we
have plenty of time, so my idea is:
1. Wait for some comments from Ulf on Javier's fix.
2. If the fix goes into v4.4, then problem solved.
3. If not and it get acked, then it can go with this set.
4. If not and it get applied by Ulf for v4.5, then a tag from him would
be a nice way to solve dependency.
Either way we don't have to hurry, I think.
I am fine, no hurry, lets give these a bit more time to hear from other.
Thanks
Best regards,
Krzysztof
--
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/2] mmc: dw_mmc: exynos: Add the exynos3250 compatible
On 22.10.2015 11:54, Jaehoon Chung wrote:
> Hi, Krzysztof.
>
> On 10/22/2015 09:06 AM, Krzysztof Kozlowski wrote:
>> On 21.10.2015 15:39, Jaehoon Chung wrote:
>>> To check more exactly, add the exynos3250 compatible.
>>> Not use exynos5250 compatibility.
>>
>> Hi,
>>
>> I can't find any difference between old and new compatible. Maybe I am
>> missing something? Maybe there is a difference for these devices?
>
> Sorry, I needs to add more explanation about changing compatible.
> Exynos3250 has more registers than exynos5250 in dwmmc IP.
> Now, we used dwmmc controller with exynos5250 compatible.
> Then some codes can't run in dw-mmc.c, if SoC is exynos3250.
> For example, there is the checking point in dw_mci_exynos_config_hs400().
>
> static void dw_mci_exynos_config_hs400(struct dw_mci *host, u32 timing)
> {
> struct dw_mci_exynos_priv_data *priv = host->priv;
> u32 dqs, strobe;
>
> /*
> * Not supported to configure register
> * related to HS400
> */
> if (priv->ctrl_type < DW_MCI_TYPE_EXYNOS5420)
> return;
>
> dqs = priv->saved_dqs_en;
> strobe = priv->saved_strobe_ctrl;
>
> It can't use this feature with exynos5250 compatible.
Ahh, I see it now. I missed that context and commit message wasn't
explaining this real reason. This real reason - supporting HS400 or
other features not present on Exynos5250 - was not mentioned.
The new compatible make sense now... but I am wondering if instead just
"samsung,exynos5420-dw-mshc" should be used? I think it would give the
same result as your change and if new compatible is not required then it
will be better not to add it.
Best regards,
Krzysztof
>
> Does it need to change the compatible from exynos5250 to exynos3250?
>
> Beset Regards,
> Jaehoon Chung
>
>>
>> Anyway if the code is the same then it should use exactly the same
>> compatible.
>>
>> Best regards,
>> Krzysztof
>>
>>>
>>> Signed-off-by: Jaehoon Chung
>>> ---
>>> Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt | 2 ++
>>> drivers/mmc/host/dw_mmc-exynos.c | 7 +++
>>> 2 files changed, 9 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt
>>> b/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt
>>> index aad9844..cd22ac9 100644
>>> --- a/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt
>>> +++ b/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt
>>> @@ -22,6 +22,8 @@ Required Properties:
>>> specific extensions.
>>> - "samsung,exynos7-dw-mshc-smu": for controllers with Samsung Exynos7
>>> specific extensions having an SMU.
>>> + - "samsung,exynos3250-dw-mshc": for controllers with Samsung Exynos3250
>>> + specific extensions.
>>>
>>> * samsung,dw-mshc-ciu-div: Specifies the divider value for the card
>>> interface
>>>unit (ciu) clock. This property is applicable only for Exynos5 SoC's and
>>> diff --git a/drivers/mmc/host/dw_mmc-exynos.c
>>> b/drivers/mmc/host/dw_mmc-exynos.c
>>> index 1e75309..1c96218 100644
>>> --- a/drivers/mmc/host/dw_mmc-exynos.c
>>> +++ b/drivers/mmc/host/dw_mmc-exynos.c
>>> @@ -32,6 +32,7 @@ enum dw_mci_exynos_type {
>>> DW_MCI_TYPE_EXYNOS5420_SMU,
>>> DW_MCI_TYPE_EXYNOS7,
>>> DW_MCI_TYPE_EXYNOS7_SMU,
>>> + DW_MCI_TYPE_EXYNOS3250,
>>> };
>>>
>>> /* Exynos implementation specific driver private data */
>>> @@ -73,6 +74,9 @@ static struct dw_mci_exynos_compatible {
>>> }, {
>>> .compatible = "samsung,exynos7-dw-mshc-smu",
>>> .ctrl_type = DW_MCI_TYPE_EXYNOS7_SMU,
>>> + }, {
>>> + .compatible = "samsung,exynos3250-dw-mshc",
>>> + .ctrl_type = DW_MCI_TYPE_EXYNOS3250,
>>> },
>>> };
>>>
>>> @@ -467,6 +471,7 @@ static int dw_mci_exynos_execute_tuning(struct
>>> dw_mci_slot *slot)
>>> } while (start_smpl != smpl);
>>>
>>> found = dw_mci_exynos_get_best_clksmpl(candiates);
>>> +
>>> if (found >= 0) {
>>> dw_mci_exynos_set_clksmpl(host, found);
>>> priv->tuned_sample = found;
>>> @@ -520,6 +525,8 @@ static const struct of_device_id dw_mci_exynos_match[]
>>> = {
>>> .data = &exynos_drv_data, },
>>> { .compatible = "samsung,exynos7-dw-mshc-smu",
>>> .data = &exynos_drv_data, },
>>> + { .compatible = "samsung,exynos3250-dw-mshc",
>>> + .data = &exynos_drv_data, },
>>> {},
>>> };
>>> MODULE_DEVICE_TABLE(of, dw_mci_exynos_match);
>>>
>>
>>
>
>
--
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/2] mmc: dw_mmc: exynos: Add the exynos3250 compatible
Hi, Krzysztof.
On 10/22/2015 09:06 AM, Krzysztof Kozlowski wrote:
> On 21.10.2015 15:39, Jaehoon Chung wrote:
>> To check more exactly, add the exynos3250 compatible.
>> Not use exynos5250 compatibility.
>
> Hi,
>
> I can't find any difference between old and new compatible. Maybe I am
> missing something? Maybe there is a difference for these devices?
Sorry, I needs to add more explanation about changing compatible.
Exynos3250 has more registers than exynos5250 in dwmmc IP.
Now, we used dwmmc controller with exynos5250 compatible.
Then some codes can't run in dw-mmc.c, if SoC is exynos3250.
For example, there is the checking point in dw_mci_exynos_config_hs400().
static void dw_mci_exynos_config_hs400(struct dw_mci *host, u32 timing)
{
struct dw_mci_exynos_priv_data *priv = host->priv;
u32 dqs, strobe;
/*
* Not supported to configure register
* related to HS400
*/
if (priv->ctrl_type < DW_MCI_TYPE_EXYNOS5420)
return;
dqs = priv->saved_dqs_en;
strobe = priv->saved_strobe_ctrl;
It can't use this feature with exynos5250 compatible.
Does it need to change the compatible from exynos5250 to exynos3250?
Beset Regards,
Jaehoon Chung
>
> Anyway if the code is the same then it should use exactly the same
> compatible.
>
> Best regards,
> Krzysztof
>
>>
>> Signed-off-by: Jaehoon Chung
>> ---
>> Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt | 2 ++
>> drivers/mmc/host/dw_mmc-exynos.c | 7 +++
>> 2 files changed, 9 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt
>> b/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt
>> index aad9844..cd22ac9 100644
>> --- a/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt
>> +++ b/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt
>> @@ -22,6 +22,8 @@ Required Properties:
>>specific extensions.
>> - "samsung,exynos7-dw-mshc-smu": for controllers with Samsung Exynos7
>>specific extensions having an SMU.
>> +- "samsung,exynos3250-dw-mshc": for controllers with Samsung Exynos3250
>> + specific extensions.
>>
>> * samsung,dw-mshc-ciu-div: Specifies the divider value for the card
>> interface
>>unit (ciu) clock. This property is applicable only for Exynos5 SoC's and
>> diff --git a/drivers/mmc/host/dw_mmc-exynos.c
>> b/drivers/mmc/host/dw_mmc-exynos.c
>> index 1e75309..1c96218 100644
>> --- a/drivers/mmc/host/dw_mmc-exynos.c
>> +++ b/drivers/mmc/host/dw_mmc-exynos.c
>> @@ -32,6 +32,7 @@ enum dw_mci_exynos_type {
>> DW_MCI_TYPE_EXYNOS5420_SMU,
>> DW_MCI_TYPE_EXYNOS7,
>> DW_MCI_TYPE_EXYNOS7_SMU,
>> +DW_MCI_TYPE_EXYNOS3250,
>> };
>>
>> /* Exynos implementation specific driver private data */
>> @@ -73,6 +74,9 @@ static struct dw_mci_exynos_compatible {
>> }, {
>> .compatible = "samsung,exynos7-dw-mshc-smu",
>> .ctrl_type = DW_MCI_TYPE_EXYNOS7_SMU,
>> +}, {
>> +.compatible = "samsung,exynos3250-dw-mshc",
>> +.ctrl_type = DW_MCI_TYPE_EXYNOS3250,
>> },
>> };
>>
>> @@ -467,6 +471,7 @@ static int dw_mci_exynos_execute_tuning(struct
>> dw_mci_slot *slot)
>> } while (start_smpl != smpl);
>>
>> found = dw_mci_exynos_get_best_clksmpl(candiates);
>> +
>> if (found >= 0) {
>> dw_mci_exynos_set_clksmpl(host, found);
>> priv->tuned_sample = found;
>> @@ -520,6 +525,8 @@ static const struct of_device_id dw_mci_exynos_match[] =
>> {
>> .data = &exynos_drv_data, },
>> { .compatible = "samsung,exynos7-dw-mshc-smu",
>> .data = &exynos_drv_data, },
>> +{ .compatible = "samsung,exynos3250-dw-mshc",
>> +.data = &exynos_drv_data, },
>> {},
>> };
>> MODULE_DEVICE_TABLE(of, dw_mci_exynos_match);
>>
>
>
--
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] mmc: pwrseq: Use highest priority for eMMC restart handler
Hello Krzysztof, On 10/22/2015 03:43 AM, Krzysztof Kozlowski wrote: > On 22.10.2015 10:20, Javier Martinez Canillas wrote:> Hello Krzysztof, >> >> Thanks for your feedback. >> >> On 10/22/2015 02:36 AM, Krzysztof Kozlowski wrote: >>> On 22.10.2015 00:15, Javier Martinez Canillas wrote: The pwrseq_emmc driver does a eMMC card reset before a system reboot to allow broken or limited ROM boot-loaders (that don't have an eMMC reset logic) to be able to read the second stage from the eMMC. But this has to be called before a system reboot handler and while most of them use the priority 128, there are other restart handlers (such as the syscon-reboot one) that use a higher priority. So, use the highest priority to make sure that the eMMC hw is reset before a system reboot. Signed-off-by: Javier Martinez Canillas Tested-by: Markus Reichl Tested-by: Anand Moon Reviewed-by: Alim Akhtar --- Hello, This patch was needed since a recent series from Alim [0] added syscon reboot and poweroff support to Exynos SoCs and removed the reset handler in the Exynos Power Management Unit (PMU) code. But the PMU and syscon-reboot restart handler have a different priority so [0] breaks restart when eMMC is used on these boards. [0]: http://www.spinics.net/lists/arm-kernel/msg454396.html So this patch must be merged before [0] to avoid regressions. Best regards, Javier drivers/mmc/core/pwrseq_emmc.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/mmc/core/pwrseq_emmc.c b/drivers/mmc/core/pwrseq_emmc.c index 137c97fb7aa8..ad4f94ec7e8d 100644 --- a/drivers/mmc/core/pwrseq_emmc.c +++ b/drivers/mmc/core/pwrseq_emmc.c @@ -84,11 +84,11 @@ struct mmc_pwrseq *mmc_pwrseq_emmc_alloc(struct mmc_host *host, /* * register reset handler to ensure emmc reset also from - * emergency_reboot(), priority 129 schedules it just before - * system reboot + * emergency_reboot(), priority 255 is the highest priority + * so it will be executed before any system reboot handler. */ pwrseq->reset_nb.notifier_call = mmc_pwrseq_emmc_reset_nb; - pwrseq->reset_nb.priority = 129; + pwrseq->reset_nb.priority = 255; >>> >>> I see the problem which you are trying to solve but this may be tricker >>> then just kicking the number. Some of restart handlers are registered >>> with priority 192. I found few of such, like: at91_restart_nb, >>> zynq_slcr_restart_nb, rmobile_reset_nb (maybe more, I did not grep too >>> much). >>> >> >> Yes, the syscon-reboot restart handler also uses a priority 192 and that >> is why reboot with eMMC broke with Alim's patches since the PMU restart >> handler priority is 128. >> >>> I guess they chose the "192" priority on purpose. >>> >> >> I tried to understand what's the policy w.r.t priority numbering for >> restart handlers but only found this in the register_restart_handler >> kernel-doc [0]: >> >> /** >> * register_restart_handler - Register function to be called to reset >> * the system >> * @nb: Info about handler function to be called >> * @nb->priority: Handler priority. Handlers should follow the >> * following guidelines for setting priorities. >> * 0: Restart handler of last resort, >> * with limited restart capabilities >> * 128:Default restart handler; use if no other >> * restart handler is expected to be available, >> * and/or if restart functionality is >> * sufficient to restart the entire system >> * 255:Highest priority restart handler, will >> * preempt all other restart handlers >> >> So, reading that is not clear to me if only the values 0, 128 and 255 >> should be used or any value from 0-255. >> >> What's clear to me is that restart handlers to reset a specific hw block >> should be called before the restart handler that resets the whole system. >> >> The 192 seems to be used because there are other default restart handlers >> that are using a prio of 128. See for example the commit that changed the >> syscon-reboot prio from 128 to 192: >> >> b81180b3fd48 power: reset: adjust priority of simple syscon reboot driver > > But were are here not talking about syscon handler but the others. Now > you will be ahead of them. > Yes, I know that. My point was that the platforms were either not using the mmc-pwrseq-emmc or their system restart handler already had a lower priority but that is not true for at least rk3288-veyron as you said. >> >> So probably the 192 value was chosen because is in the middle of 128 and >> 255 but it seems to me a r
Re: [PATCH v2 0/9] Add tune support of Mediatek MMC driver
On Tue, 2015-10-20 at 18:41 +0200, Ulf Hansson wrote: > On 20 October 2015 at 11:13, Chaotian Jing wrote: > > Change in v2: > > Drop the 400mhz and use assigned-clock-parents to instead > > Split the original tune patch to several independent patches > > Re-write the mmc_send_tuning() > > Fix GPD checksum error > > Move the HS400 setting to ops->prepare_hs400_tuning() > > Modify SD driving settings > > > > Change in v1: > > Add DT bindings for eMMC hardware reset > > Add pinctrl of data strobe pin for HS400 mode > > Modify eMMC driving settings > > Add 400mhz source clock for HS400 mode > > Add eMMC HS200/HS400 mode support > > Add SD SDR50/SDR104 mode support > > Add implement of tune function with CMD19/CMD21 > > > > Chaotian Jing (9): > > mmc: core: Add DT bindings for eMMC hardware reset support > > mmc: dt-bindings: update Mediatek MMC bindings > > mmc: mediatek: make cmd_ints_mask to const > > mmc: mediatek: change the argument "ddr" to "timing" > > mmc: mediatek: fix got GPD checksum error interrupt when data transfer > > mmc: mediatek: add implement of ops->hw_reset() > > mmc: mmc: extend the mmc_send_tuning() > > mmc: mediatek: add HS400 support > > arm64: dts: mediatek: add HS200/HS400/SDR50/SDR104 support > > > > Documentation/devicetree/bindings/mmc/mmc.txt| 1 + > > Documentation/devicetree/bindings/mmc/mtk-sd.txt | 11 +- > > arch/arm64/boot/dts/mediatek/mt8173-evb.dts | 27 ++- > > drivers/mmc/core/host.c | 2 + > > drivers/mmc/core/mmc_ops.c | 8 +- > > drivers/mmc/host/dw_mmc-exynos.c | 4 +- > > drivers/mmc/host/dw_mmc.c| 2 +- > > drivers/mmc/host/dw_mmc.h| 2 +- > > drivers/mmc/host/mtk-sd.c| 296 > > --- > > drivers/mmc/host/sdhci-esdhc-imx.c | 6 +- > > drivers/mmc/host/sdhci-msm.c | 2 +- > > drivers/mmc/host/sdhci-sirf.c| 2 +- > > include/linux/mmc/core.h | 2 +- > > 13 files changed, 314 insertions(+), 51 deletions(-) > > > > -- > > 1.8.1.1.dirty > > I have reviewed the patches, I think they overall looks good! Some > comments though. > > You need to split patch 9, the DT parts enabling hw reset shall go in > separately. > Ok, will separate it at next revision. > Regarding the hw-reset changes in patch1, patch6 and patch9, I believe > I requested you to separate the HW reset changes from $subject > patchset as they are unrelated, please do this. > As you know, the hw-reset is a part of mmc retune. so that I add it to this series. > Running checkpatch, it gave me warnings and errors for patch 8. > Patch7 didn't apply to my next branch. > I will fix the checkpatch warnings and errors at next revision. by the way, I tried to use "git am 0007-mmc-mmc-extend-the-mmc_send_tuning.patch" in your branch, there was no conflict, so why couldn't apply it ? Thx! > Kind regards > Uffe -- 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] mmc: pwrseq: Use highest priority for eMMC restart handler
On 22.10.2015 10:20, Javier Martinez Canillas wrote:> Hello Krzysztof, > > Thanks for your feedback. > > On 10/22/2015 02:36 AM, Krzysztof Kozlowski wrote: >> On 22.10.2015 00:15, Javier Martinez Canillas wrote: >>> The pwrseq_emmc driver does a eMMC card reset before a system reboot to >>> allow broken or limited ROM boot-loaders (that don't have an eMMC reset >>> logic) to be able to read the second stage from the eMMC. >>> >>> But this has to be called before a system reboot handler and while most >>> of them use the priority 128, there are other restart handlers (such as >>> the syscon-reboot one) that use a higher priority. So, use the highest >>> priority to make sure that the eMMC hw is reset before a system reboot. >>> >>> Signed-off-by: Javier Martinez Canillas >>> Tested-by: Markus Reichl >>> Tested-by: Anand Moon >>> Reviewed-by: Alim Akhtar >>> >>> --- >>> Hello, >>> >>> This patch was needed since a recent series from Alim [0] added >>> syscon reboot and poweroff support to Exynos SoCs and removed >>> the reset handler in the Exynos Power Management Unit (PMU) code. >>> >>> But the PMU and syscon-reboot restart handler have a different >>> priority so [0] breaks restart when eMMC is used on these boards. >>> >>> [0]: http://www.spinics.net/lists/arm-kernel/msg454396.html >>> >>> So this patch must be merged before [0] to avoid regressions. >>> >>> Best regards, >>> Javier >>> >>> drivers/mmc/core/pwrseq_emmc.c | 6 +++--- >>> 1 file changed, 3 insertions(+), 3 deletions(-) >>> >>> diff --git a/drivers/mmc/core/pwrseq_emmc.c b/drivers/mmc/core/pwrseq_emmc.c >>> index 137c97fb7aa8..ad4f94ec7e8d 100644 >>> --- a/drivers/mmc/core/pwrseq_emmc.c >>> +++ b/drivers/mmc/core/pwrseq_emmc.c >>> @@ -84,11 +84,11 @@ struct mmc_pwrseq *mmc_pwrseq_emmc_alloc(struct >>> mmc_host *host, >>> >>> /* >>> * register reset handler to ensure emmc reset also from >>> -* emergency_reboot(), priority 129 schedules it just before >>> -* system reboot >>> +* emergency_reboot(), priority 255 is the highest priority >>> +* so it will be executed before any system reboot handler. >>> */ >>> pwrseq->reset_nb.notifier_call = mmc_pwrseq_emmc_reset_nb; >>> - pwrseq->reset_nb.priority = 129; >>> + pwrseq->reset_nb.priority = 255; >> >> I see the problem which you are trying to solve but this may be tricker >> then just kicking the number. Some of restart handlers are registered >> with priority 192. I found few of such, like: at91_restart_nb, >> zynq_slcr_restart_nb, rmobile_reset_nb (maybe more, I did not grep too >> much). >> > > Yes, the syscon-reboot restart handler also uses a priority 192 and that > is why reboot with eMMC broke with Alim's patches since the PMU restart > handler priority is 128. > >> I guess they chose the "192" priority on purpose. >> > > I tried to understand what's the policy w.r.t priority numbering for > restart handlers but only found this in the register_restart_handler > kernel-doc [0]: > > /** > *register_restart_handler - Register function to be called to reset > * the system > *@nb: Info about handler function to be called > *@nb->priority: Handler priority. Handlers should follow the > *following guidelines for setting priorities. > *0: Restart handler of last resort, > *with limited restart capabilities > *128:Default restart handler; use if no other > *restart handler is expected to be available, > *and/or if restart functionality is > *sufficient to restart the entire system > *255:Highest priority restart handler, will > *preempt all other restart handlers > > So, reading that is not clear to me if only the values 0, 128 and 255 > should be used or any value from 0-255. > > What's clear to me is that restart handlers to reset a specific hw block > should be called before the restart handler that resets the whole system. > > The 192 seems to be used because there are other default restart handlers > that are using a prio of 128. See for example the commit that changed the > syscon-reboot prio from 128 to 192: > > b81180b3fd48 power: reset: adjust priority of simple syscon reboot driver But were are here not talking about syscon handler but the others. Now you will be ahead of them. > > So probably the 192 value was chosen because is in the middle of 128 and > 255 but it seems to me a rather arbitrary value and I would prefer it to > be documented in some place. > >> Effectively, now the emmc handler will be executed before their >> handlers... is it an issue? Maybe some testing on these platforms is >> necessary? >> > > I don't think is an issue, the reason why I chose 255 is that it is > a documented value in the kernel-doc and since is the highe
[PATCH v2] MAINTAINERS: ARM: EXYNOS: Add documentation and dt-bindings
Extend the Samsung Exynos maintainer entry to match SoC documentation and SoC dt-bindings directories. Without that some files, like bindings/arm/samsung/pmu.txt, are not matched by existing patterns. This also may serve as a hint where new documentation and bindings (not matching specific subsystem) should be put. Signed-off-by: Krzysztof Kozlowski Cc: Kukjin Kim Reviewed-by: Javier Martinez Canillas --- Changes since v1: 1. Added Javier's reviewed-by 2. Cover also power domain and sram bindings located now in separate directory. --- MAINTAINERS | 4 1 file changed, 4 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index b556aad90930..6339926c77d6 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1459,6 +1459,10 @@ F: drivers/*/*s3c2410* F: drivers/*/*/*s3c2410* F: drivers/spi/spi-s3c* F: sound/soc/samsung/* +F: Documentation/arm/Samsung/ +F: Documentation/devicetree/bindings/arm/samsung/ +F: Documentation/devicetree/bindings/sram/samsung-sram.txt +F: Documentation/devicetree/bindings/power/pd-samsung.txt N: exynos ARM/SAMSUNG MOBILE MACHINE SUPPORT -- 1.9.1 -- 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/3] dt-bindings: Consolidate SRAM bindings from all vendors
SRAM bindings for various SoCs, using the mmio-sram genalloc
API, are spread over different places - per SoC vendor. Since all of
these are quite similar (they depend on mmio-sram) move them to a common
place.
Signed-off-by: Krzysztof Kozlowski
Cc: Heiko Stuebner
Cc: Maxime Ripard
Cc: Chen-Yu Tsai
Cc: Kukjin Kim
Suggested-by: Rob Herring
---
Changes since v1:
1. New patch. Extended suggestion from Rob.
---
.../bindings/{arm/rockchip/pmu-sram.txt => sram/rockchip-pmu-sram.txt}| 0
.../bindings/{arm/rockchip/smp-sram.txt => sram/rockchip-smp-sram.txt}| 0
.../bindings/{arm/exynos/smp-sysram.txt => sram/samsung-sram.txt} | 0
Documentation/devicetree/bindings/{misc => sram}/sram.txt | 0
.../devicetree/bindings/{soc/sunxi/sram.txt => sram/sunxi-sram.txt} | 0
5 files changed, 0 insertions(+), 0 deletions(-)
rename Documentation/devicetree/bindings/{arm/rockchip/pmu-sram.txt =>
sram/rockchip-pmu-sram.txt} (100%)
rename Documentation/devicetree/bindings/{arm/rockchip/smp-sram.txt =>
sram/rockchip-smp-sram.txt} (100%)
rename Documentation/devicetree/bindings/{arm/exynos/smp-sysram.txt =>
sram/samsung-sram.txt} (100%)
rename Documentation/devicetree/bindings/{misc => sram}/sram.txt (100%)
rename Documentation/devicetree/bindings/{soc/sunxi/sram.txt =>
sram/sunxi-sram.txt} (100%)
diff --git a/Documentation/devicetree/bindings/arm/rockchip/pmu-sram.txt
b/Documentation/devicetree/bindings/sram/rockchip-pmu-sram.txt
similarity index 100%
rename from Documentation/devicetree/bindings/arm/rockchip/pmu-sram.txt
rename to Documentation/devicetree/bindings/sram/rockchip-pmu-sram.txt
diff --git a/Documentation/devicetree/bindings/arm/rockchip/smp-sram.txt
b/Documentation/devicetree/bindings/sram/rockchip-smp-sram.txt
similarity index 100%
rename from Documentation/devicetree/bindings/arm/rockchip/smp-sram.txt
rename to Documentation/devicetree/bindings/sram/rockchip-smp-sram.txt
diff --git a/Documentation/devicetree/bindings/arm/exynos/smp-sysram.txt
b/Documentation/devicetree/bindings/sram/samsung-sram.txt
similarity index 100%
rename from Documentation/devicetree/bindings/arm/exynos/smp-sysram.txt
rename to Documentation/devicetree/bindings/sram/samsung-sram.txt
diff --git a/Documentation/devicetree/bindings/misc/sram.txt
b/Documentation/devicetree/bindings/sram/sram.txt
similarity index 100%
rename from Documentation/devicetree/bindings/misc/sram.txt
rename to Documentation/devicetree/bindings/sram/sram.txt
diff --git a/Documentation/devicetree/bindings/soc/sunxi/sram.txt
b/Documentation/devicetree/bindings/sram/sunxi-sram.txt
similarity index 100%
rename from Documentation/devicetree/bindings/soc/sunxi/sram.txt
rename to Documentation/devicetree/bindings/sram/sunxi-sram.txt
--
1.9.1
--
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/3] dt-bindings: Consolidate Exynos SoC bindings
Exynos SoC Device Tree bindings are spread over arm/exynos/ and
arm/samsung/ directories. There is no need for that separation and it
actually confuses. Put power domain bindings under power/ and
remaining samsung-boards.txt under arm/samsung/.
Signed-off-by: Krzysztof Kozlowski
Cc: Kukjin Kim
Reviewed-by: Javier Martinez Canillas
---
Changes since v1:
1. Move power_domain.txt to power/pd-samsung.txt.
2. The smp-sysram.txt is moved in previous patch to sram/ directory
(Suggested by Rob Herring).
3. Added Javier's reviewed-by. Although there are some differences since
v1 but this is merely re-organization. Please let me know if the
review tag is no longer valid.
---
Documentation/devicetree/bindings/arm/{ => samsung}/samsung-boards.txt| 0
.../bindings/{arm/exynos/power_domain.txt => power/pd-samsung.txt}| 0
2 files changed, 0 insertions(+), 0 deletions(-)
rename Documentation/devicetree/bindings/arm/{ => samsung}/samsung-boards.txt
(100%)
rename Documentation/devicetree/bindings/{arm/exynos/power_domain.txt =>
power/pd-samsung.txt} (100%)
diff --git a/Documentation/devicetree/bindings/arm/samsung-boards.txt
b/Documentation/devicetree/bindings/arm/samsung/samsung-boards.txt
similarity index 100%
rename from Documentation/devicetree/bindings/arm/samsung-boards.txt
rename to Documentation/devicetree/bindings/arm/samsung/samsung-boards.txt
diff --git a/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
b/Documentation/devicetree/bindings/power/pd-samsung.txt
similarity index 100%
rename from Documentation/devicetree/bindings/arm/exynos/power_domain.txt
rename to Documentation/devicetree/bindings/power/pd-samsung.txt
--
1.9.1
--
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/3] dt-bindings: EXYNOS: Document compatibles from other vendors
Document compatibles used on other Exynos-based boards (non-Samsung): FriendlyARM, Google, Hardkernel and Insignal. Signed-off-by: Krzysztof Kozlowski Cc: Kukjin Kim Cc: Javier Martinez Canillas Cc: Hakjoo Kim Reviewed-by: Javier Martinez Canillas --- Changes since v1: 1. Added Javier's reviewed-by --- .../bindings/arm/samsung/samsung-boards.txt| 44 +- 1 file changed, 43 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/arm/samsung/samsung-boards.txt b/Documentation/devicetree/bindings/arm/samsung/samsung-boards.txt index 43589d2466a7..da078702ae73 100644 --- a/Documentation/devicetree/bindings/arm/samsung/samsung-boards.txt +++ b/Documentation/devicetree/bindings/arm/samsung/samsung-boards.txt @@ -16,7 +16,49 @@ Required root node properties: - "samsung,sd5v1" - for Exynos5440-based Samsung board. - "samsung,ssdk5440"- for Exynos5440-based Samsung board. -Optional: +* Other companies Exynos SoC based + * FriendlyARM +- "friendlyarm,tiny4412" - for Exynos4412-based FriendlyARM +TINY4412 board. + + * Google +- "google,pi" - for Exynos5800-based Google Peach Pi +Rev 10+ board, + also: "google,pi-rev16", "google,pi-rev15", "google,pi-rev14", + "google,pi-rev13", "google,pi-rev12", "google,pi-rev11", +"google,pi-rev10", "google,peach". + +- "google,pit"- for Exynos5420-based Google Peach Pit +Rev 6+ (Exynos5420), + also: "google,pit-rev16", "google,pit-rev15", "google,pit-rev14", +"google,pit-rev13", "google,pit-rev12", "google,pit-rev11", +"google,pit-rev10", "google,pit-rev9", "google,pit-rev8", +"google,pit-rev7", "google,pit-rev6", "google,peach". + +- "google,snow-rev4" - for Exynos5250-based Google Snow board, + also: "google,snow" +- "google,snow-rev5" - for Exynos5250-based Google Snow +Rev 5+ board. +- "google,spring" - for Exynos5250-based Google Spring board. + + * Hardkernel +- "hardkernel,odroid-u3" - for Exynos4412-based Hardkernel Odroid U3. +- "hardkernel,odroid-x" - for Exynos4412-based Hardkernel Odroid X. +- "hardkernel,odroid-x2" - for Exynos4412-based Hardkernel Odroid X2. +- "hardkernel,odroid-xu3" - for Exynos5422-based Hardkernel Odroid XU3. +- "hardkernel,odroid-xu3-lite" - for Exynos5422-based Hardkernel + Odroid XU3 Lite board. +- "hardkernel,odroid-xu4" - for Exynos5422-based Hardkernel Odroid XU4. + + * Insignal +- "insignal,arndale" - for Exynos5250-based Insignal Arndale board. +- "insignal,arndale-octa" - for Exynos5420-based Insignal Arndale +Octa board. +- "insignal,origen" - for Exynos4210-based Insignal Origen board. +- "insignal,origen4412- for Exynos4412-based Insignal Origen board. + + +Optional nodes: - firmware node, specifying presence and type of secure firmware: - compatible: only "samsung,secure-firmware" is currently supported - reg: address of non-secure SYSRAM used for communication with firmware -- 1.9.1 -- 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] mmc: pwrseq: Use highest priority for eMMC restart handler
Hello Krzysztof, Thanks for your feedback. On 10/22/2015 02:36 AM, Krzysztof Kozlowski wrote: > On 22.10.2015 00:15, Javier Martinez Canillas wrote: >> The pwrseq_emmc driver does a eMMC card reset before a system reboot to >> allow broken or limited ROM boot-loaders (that don't have an eMMC reset >> logic) to be able to read the second stage from the eMMC. >> >> But this has to be called before a system reboot handler and while most >> of them use the priority 128, there are other restart handlers (such as >> the syscon-reboot one) that use a higher priority. So, use the highest >> priority to make sure that the eMMC hw is reset before a system reboot. >> >> Signed-off-by: Javier Martinez Canillas >> Tested-by: Markus Reichl >> Tested-by: Anand Moon >> Reviewed-by: Alim Akhtar >> >> --- >> Hello, >> >> This patch was needed since a recent series from Alim [0] added >> syscon reboot and poweroff support to Exynos SoCs and removed >> the reset handler in the Exynos Power Management Unit (PMU) code. >> >> But the PMU and syscon-reboot restart handler have a different >> priority so [0] breaks restart when eMMC is used on these boards. >> >> [0]: http://www.spinics.net/lists/arm-kernel/msg454396.html >> >> So this patch must be merged before [0] to avoid regressions. >> >> Best regards, >> Javier >> >> drivers/mmc/core/pwrseq_emmc.c | 6 +++--- >> 1 file changed, 3 insertions(+), 3 deletions(-) >> >> diff --git a/drivers/mmc/core/pwrseq_emmc.c b/drivers/mmc/core/pwrseq_emmc.c >> index 137c97fb7aa8..ad4f94ec7e8d 100644 >> --- a/drivers/mmc/core/pwrseq_emmc.c >> +++ b/drivers/mmc/core/pwrseq_emmc.c >> @@ -84,11 +84,11 @@ struct mmc_pwrseq *mmc_pwrseq_emmc_alloc(struct mmc_host >> *host, >> >> /* >> * register reset handler to ensure emmc reset also from >> - * emergency_reboot(), priority 129 schedules it just before >> - * system reboot >> + * emergency_reboot(), priority 255 is the highest priority >> + * so it will be executed before any system reboot handler. >> */ >> pwrseq->reset_nb.notifier_call = mmc_pwrseq_emmc_reset_nb; >> -pwrseq->reset_nb.priority = 129; >> +pwrseq->reset_nb.priority = 255; > > I see the problem which you are trying to solve but this may be tricker > then just kicking the number. Some of restart handlers are registered > with priority 192. I found few of such, like: at91_restart_nb, > zynq_slcr_restart_nb, rmobile_reset_nb (maybe more, I did not grep too > much). > Yes, the syscon-reboot restart handler also uses a priority 192 and that is why reboot with eMMC broke with Alim's patches since the PMU restart handler priority is 128. > I guess they chose the "192" priority on purpose. > I tried to understand what's the policy w.r.t priority numbering for restart handlers but only found this in the register_restart_handler kernel-doc [0]: /** * register_restart_handler - Register function to be called to reset * the system * @nb: Info about handler function to be called * @nb->priority: Handler priority. Handlers should follow the * following guidelines for setting priorities. * 0: Restart handler of last resort, * with limited restart capabilities * 128:Default restart handler; use if no other * restart handler is expected to be available, * and/or if restart functionality is * sufficient to restart the entire system * 255:Highest priority restart handler, will * preempt all other restart handlers So, reading that is not clear to me if only the values 0, 128 and 255 should be used or any value from 0-255. What's clear to me is that restart handlers to reset a specific hw block should be called before the restart handler that resets the whole system. The 192 seems to be used because there are other default restart handlers that are using a prio of 128. See for example the commit that changed the syscon-reboot prio from 128 to 192: b81180b3fd48 power: reset: adjust priority of simple syscon reboot driver So probably the 192 value was chosen because is in the middle of 128 and 255 but it seems to me a rather arbitrary value and I would prefer it to be documented in some place. > Effectively, now the emmc handler will be executed before their > handlers... is it an issue? Maybe some testing on these platforms is > necessary? > I don't think is an issue, the reason why I chose 255 is that it is a documented value in the kernel-doc and since is the highest prio, it makes sure the eMMC will be reset before any system restart handler. Also, the pwrseq_emmc driver is only used in platforms whose SoC ROM can either leave the eMMC in an unknown state so the kernel needs to hw reset the eMMC or does not have a reset logic so it ca
Re: [PATCH] MAINTAINERS: ARM: EXYNOS: Add documentation and dt-bindings
On 21.10.2015 22:08, Javier Martinez Canillas wrote: > Hello Krzysztof, > > On 10/21/2015 02:43 PM, Krzysztof Kozlowski wrote: >> 2015-10-21 17:45 GMT+09:00 Javier Martinez Canillas : >>> >>> Hello Krzysztof, >>> >>> Patch looks good to me, I've only one comment. >>> >>> On 10/21/2015 03:33 AM, Krzysztof Kozlowski wrote: Extend the Samsung Exynos maintainer entry to match SoC documentation and SoC dt-bindings directories. Without that some files, like bindings/arm/samsung/pmu.txt, are not matched by existing patterns. This also may serve as a hint where new documentation and bindings (not matching specific subsystem) should be put. Signed-off-by: Krzysztof Kozlowski Cc: Kukjin Kim --- MAINTAINERS | 2 ++ 1 file changed, 2 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index b556aad90930..cad7b6b628b2 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1459,6 +1459,8 @@ F: drivers/*/*s3c2410* F: drivers/*/*/*s3c2410* F: drivers/spi/spi-s3c* F: sound/soc/samsung/* +F: Documentation/arm/Samsung/ >>> >>> That there is also a Documentation/arm/Samsung-S3C24XX/ so >>> I think this should be Documentation/arm/Samsung*/ instead. >> >> I am not sure... I think this is documentation from the Ben Dooks' >> work and there is a entry for S3C241x machines: >> SIMTEC EB2410ITX ) >> > > I'm not familiar with S3C241x but the EB2410ITX entry only covers > a couple of files under arch/arm/mach-s3c24xx, basically all that > are related to the BAST machine (board file and platform data). > > But arch/arm/mach-s3c24* and drivers/*/*s3c2410* are covered by > the ARM/SAMSUNG entry so that's why I thought the Samsung-S3C24XX > docs should be there too since are SoC and not board specific. Right, but in the same time the documentation clearly is related to the boards from that time (pre-Exynos). > It's your call but I would put it in ARM/SAMSUNG and only the file > Documentation/arm/Samsung-S3C24XX/EB2410ITX.txt in the BAST entry. I would prefer to leave it as is... Anyway thanks for comments and if anyone feels like doing re-organization and cleanup on this old documents - please go ahead. Best regards, Krzysztof -- 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: [PATCHv2] ARM: dts: use vmmc-supply of emmc/sd for exynos5422-odroidxu3
On 20.10.2015 21:56, Anand Moon wrote:
> Changes need for host controller to detect UHS-I highspeed cards.
> Changes in VDDQ_MMC2 voltage range help scale
> the required voltage to detect and load the microSD cards.
Thanks for updating description of commit.
>
> Signed-off-by: Anand Moon
> ---
> Changes based on
> git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
> v4.4-next/dt-samsung branch
>
> Changes:
> Drop the ranp_delay for LDO9.
>
> Thanks to : Krzysztof, Doug Anderson, Jaehoon Chung for helping
> me out figure out the mmc core requirement.
>
> Also drop the previous changes:
> use cd-gpio method to detect sd-card.
> Added UHS-I bus speed support.
>
> [4.713553] random: nonblocking pool is initialized
> [4.718423] 1453.hdmi supply hdmi-en not found, using dummy regulator
> [4.726206] exynos-drm exynos-drm: bound 1440.fimd (ops
> fimd_component_ops)
> [4.732555] exynos-drm exynos-drm: bound 1445.mixer (ops
> mixer_component_ops)
> [4.740180] exynos-drm exynos-drm: bound 1453.hdmi (ops
> hdmi_component_ops)
> [4.746936] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
> [4.753428] [drm] No driver support for vblank timestamp query.
> [4.940794] Console: switching to colour frame buffer device 274x77
> [4.995344] exynos-drm exynos-drm: fb0: frame buffer device
> [5.024573] [drm] Initialized exynos 1.0.0 20110530 on minor 0
> [5.031164] exynos-dwc3 usb@1200: no suspend clk specified
> [5.054571] usb 2-1: new full-speed USB device number 2 using exynos-ohci
> [5.159527] dwmmc_exynos 1222.mmc: Busy; trying anyway
> [5.163705] mmc_host mmc1: Timeout sending command (cmd 0x202000 arg 0x0
> status 0x0)
> ---
> arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
> b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
> index 1af5bdc..a4be3e0 100644
> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
> @@ -182,9 +182,10 @@
>
> ldo13_reg: LDO13 {
> regulator-name = "vdd_ldo13";
> - regulator-min-microvolt = <280>;
> + regulator-min-microvolt = <180>;
You did not convinced me in previous discussion about the change to
1.8V. I said that:
> On the same diagram few lines below:
> VDDQ_MMC2: 2.8V 250mA
You responded:
> You are correct.
So I am confused. Are you sure that this SD card block can/should
operate on 1.8V? Have you actually tried this?
> regulator-max-microvolt = <280>;
> regulator-always-on;
> + regulator-ramp-delay = <12000>;
NAK
We've been talking about this. Sooo mn times.
If you are going to send v3 please come up with detailed reasoning,
which will convince my stubborn mind.
Best regards,
Krzysztof
> };
>
> ldo15_reg: LDO15 {
> @@ -213,6 +214,7 @@
> regulator-min-microvolt = <280>;
> regulator-max-microvolt = <280>;
> regulator-always-on;
> + regulator-ramp-delay = <12000>;
> };
>
> ldo24_reg: LDO24 {
> @@ -338,6 +340,7 @@
> samsung,dw-mshc-ddr-timing = <0 2>;
> samsung,dw-mshc-hs400-timing = <0 2>;
> samsung,read-strobe-delay = <90>;
> + vmmc-supply = <&ldo3_reg>;
> pinctrl-names = "default";
> pinctrl-0 = <&sd0_clk &sd0_cmd &sd0_bus1 &sd0_bus4 &sd0_bus8 &sd0_cd
> &sd0_rclk>;
> bus-width = <8>;
> @@ -355,6 +358,8 @@
> pinctrl-names = "default";
> pinctrl-0 = <&sd2_clk &sd2_cmd &sd2_cd &sd2_bus1 &sd2_bus4>;
> bus-width = <4>;
> + vmmc-supply = <&ldo19_reg>;
> + vqmmc-supply = <&ldo13_reg>;
> cap-sd-highspeed;
> };
>
>
--
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] mmc: pwrseq: Use highest priority for eMMC restart handler
On 22.10.2015 00:15, Javier Martinez Canillas wrote: > The pwrseq_emmc driver does a eMMC card reset before a system reboot to > allow broken or limited ROM boot-loaders (that don't have an eMMC reset > logic) to be able to read the second stage from the eMMC. > > But this has to be called before a system reboot handler and while most > of them use the priority 128, there are other restart handlers (such as > the syscon-reboot one) that use a higher priority. So, use the highest > priority to make sure that the eMMC hw is reset before a system reboot. > > Signed-off-by: Javier Martinez Canillas > Tested-by: Markus Reichl > Tested-by: Anand Moon > Reviewed-by: Alim Akhtar > > --- > Hello, > > This patch was needed since a recent series from Alim [0] added > syscon reboot and poweroff support to Exynos SoCs and removed > the reset handler in the Exynos Power Management Unit (PMU) code. > > But the PMU and syscon-reboot restart handler have a different > priority so [0] breaks restart when eMMC is used on these boards. > > [0]: http://www.spinics.net/lists/arm-kernel/msg454396.html > > So this patch must be merged before [0] to avoid regressions. > > Best regards, > Javier > > drivers/mmc/core/pwrseq_emmc.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/drivers/mmc/core/pwrseq_emmc.c b/drivers/mmc/core/pwrseq_emmc.c > index 137c97fb7aa8..ad4f94ec7e8d 100644 > --- a/drivers/mmc/core/pwrseq_emmc.c > +++ b/drivers/mmc/core/pwrseq_emmc.c > @@ -84,11 +84,11 @@ struct mmc_pwrseq *mmc_pwrseq_emmc_alloc(struct mmc_host > *host, > > /* >* register reset handler to ensure emmc reset also from > - * emergency_reboot(), priority 129 schedules it just before > - * system reboot > + * emergency_reboot(), priority 255 is the highest priority > + * so it will be executed before any system reboot handler. >*/ > pwrseq->reset_nb.notifier_call = mmc_pwrseq_emmc_reset_nb; > - pwrseq->reset_nb.priority = 129; > + pwrseq->reset_nb.priority = 255; I see the problem which you are trying to solve but this may be tricker then just kicking the number. Some of restart handlers are registered with priority 192. I found few of such, like: at91_restart_nb, zynq_slcr_restart_nb, rmobile_reset_nb (maybe more, I did not grep too much). I guess they chose the "192" priority on purpose. Effectively, now the emmc handler will be executed before their handlers... is it an issue? Maybe some testing on these platforms is necessary? Best regards, Krzysztof > register_restart_handler(&pwrseq->reset_nb); > > pwrseq->pwrseq.ops = &mmc_pwrseq_emmc_ops; > -- 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/2] dt-bindings: Consolidate Exynos SoC bindings under Samsung directory
On 22.10.2015 09:22, Rob Herring wrote:
> On Tue, Oct 20, 2015 at 8:30 PM, Krzysztof Kozlowski
> wrote:
>> Exynos SoC Device Tree bindings are spread over arm/exynos/ and
>> arm/samsung/ directories. There is no need for that separation and it
>> actually confuses. Put everything under arm/samsung/.
>
> Thanks for the clean-up.
>
>>
>> Signed-off-by: Krzysztof Kozlowski
>> Cc: Kukjin Kim
>> ---
>> .../devicetree/bindings/arm/{exynos => samsung}/power_domain.txt | >> 0
>> Documentation/devicetree/bindings/arm/{ => samsung}/samsung-boards.txt| >> 0
>> Documentation/devicetree/bindings/arm/{exynos => samsung}/smp-sysram.txt | >> 0
>> 3 files changed, 0 insertions(+), 0 deletions(-)
>> rename Documentation/devicetree/bindings/arm/{exynos =>
>> samsung}/power_domain.txt (100%)
>
> I'd rather see this with other power domain bindings. So
> bindings/power/pd-samsung.txt I guess.
OK
>
>> rename Documentation/devicetree/bindings/arm/{ =>
>> samsung}/samsung-boards.txt (100%)
>> rename Documentation/devicetree/bindings/arm/{exynos =>
>> samsung}/smp-sysram.txt (100%)
>
> Probably need to move misc/sram.txt to bindings/sram/ and put both there.
Right, that make sense. I'll send v2 moving pd-samsung and smp-sysram to
these locations.
Best regards,
Krzysztof
--
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/2] dt-bindings: Consolidate Exynos SoC bindings under Samsung directory
On Tue, Oct 20, 2015 at 8:30 PM, Krzysztof Kozlowski
wrote:
> Exynos SoC Device Tree bindings are spread over arm/exynos/ and
> arm/samsung/ directories. There is no need for that separation and it
> actually confuses. Put everything under arm/samsung/.
Thanks for the clean-up.
>
> Signed-off-by: Krzysztof Kozlowski
> Cc: Kukjin Kim
> ---
> .../devicetree/bindings/arm/{exynos => samsung}/power_domain.txt | 0
> Documentation/devicetree/bindings/arm/{ => samsung}/samsung-boards.txt| 0
> Documentation/devicetree/bindings/arm/{exynos => samsung}/smp-sysram.txt | 0
> 3 files changed, 0 insertions(+), 0 deletions(-)
> rename Documentation/devicetree/bindings/arm/{exynos =>
> samsung}/power_domain.txt (100%)
I'd rather see this with other power domain bindings. So
bindings/power/pd-samsung.txt I guess.
> rename Documentation/devicetree/bindings/arm/{ =>
> samsung}/samsung-boards.txt (100%)
> rename Documentation/devicetree/bindings/arm/{exynos =>
> samsung}/smp-sysram.txt (100%)
Probably need to move misc/sram.txt to bindings/sram/ and put both there.
Rob
>
> diff --git a/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
> b/Documentation/devicetree/bindings/arm/samsung/power_domain.txt
> similarity index 100%
> rename from Documentation/devicetree/bindings/arm/exynos/power_domain.txt
> rename to Documentation/devicetree/bindings/arm/samsung/power_domain.txt
> diff --git a/Documentation/devicetree/bindings/arm/samsung-boards.txt
> b/Documentation/devicetree/bindings/arm/samsung/samsung-boards.txt
> similarity index 100%
> rename from Documentation/devicetree/bindings/arm/samsung-boards.txt
> rename to Documentation/devicetree/bindings/arm/samsung/samsung-boards.txt
> diff --git a/Documentation/devicetree/bindings/arm/exynos/smp-sysram.txt
> b/Documentation/devicetree/bindings/arm/samsung/smp-sysram.txt
> similarity index 100%
> rename from Documentation/devicetree/bindings/arm/exynos/smp-sysram.txt
> rename to Documentation/devicetree/bindings/arm/samsung/smp-sysram.txt
> --
> 1.9.1
>
--
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 0/6] Switch to generic syscon regmap based drivers
On 22.10.2015 00:01, Alim Akhtar wrote:
> On Wed, Oct 21, 2015 at 8:25 PM, Javier Martinez Canillas
> wrote:
>> Hello Alim,
>>
>> On 10/21/2015 04:50 PM, Alim Akhtar wrote:
>>
>> [snip]
>>
[0]:
From c9b250ee03bae338339b70693e906145c719f783 Mon Sep 17 00:00:00 2001
From: Javier Martinez Canillas
Date: Wed, 21 Oct 2015 11:59:44 +0200
Subject: [RFT PATCH] mmc: pwrseq: Use highest priority for eMMC restart
handler
The pwrseq_emmc driver does a eMMC card reset before a system reboot to
allow broken or limited ROM boot-loaders, that don't have an eMMC reset
logic, to be able to read the second stage from the eMMC.
But this has to be called before a system reboot handler and while most
of them use the priority 128, there are other restart handlers (such as
the syscon-reboot one) that use a higher priority. So, use the highest
priority to make sure that the eMMC hw is reset before a system reboot.
Signed-off-by: Javier Martinez Canillas
---
>>> Looks good.
>>> Reviewed-by: Alim Akhtar
>>>
>>
+Cc Ulf,
Javier,
First of all, thanks Javier for digging into the issue. Actually I have
Odroid U3 but because of user-space limitations (which I need for other
work) I cannot test all of mainline patches there.
>> Thanks, should I post it as a proper patch or are adding it to your
>> series?
> Suggest you to post as a patch collecting {Tested, Reviewed}-by (easy
> for maintainers to pickup ) and probably CCing Ulf for his feedback.
>
>> I think the latter is more reasonable so with an ack from Ulf,
>> all patches can go through the linux-samsung tree.
>>
> yes, that is reasonable, as I said, let Krzysztof and Ulf take a call here.
Javier, Alim, Ulf,
I am not grabbing any more patches for v4.4 because I doubt that they
could be merged to arm-soc for this cycle. My last pull requests for
v4.4 is still pending...
This means that I plan to pick up these series for v4.5, after closing
v4.4 merge window (unless Kukjin picks it also). Because of that, we
have plenty of time, so my idea is:
1. Wait for some comments from Ulf on Javier's fix.
2. If the fix goes into v4.4, then problem solved.
3. If not and it get acked, then it can go with this set.
4. If not and it get applied by Ulf for v4.5, then a tag from him would
be a nice way to solve dependency.
Either way we don't have to hurry, I think.
Best regards,
Krzysztof
--
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/2] mmc: dw_mmc: exynos: Add the exynos3250 compatible
On 21.10.2015 15:39, Jaehoon Chung wrote:
> To check more exactly, add the exynos3250 compatible.
> Not use exynos5250 compatibility.
Hi,
I can't find any difference between old and new compatible. Maybe I am
missing something? Maybe there is a difference for these devices?
Anyway if the code is the same then it should use exactly the same
compatible.
Best regards,
Krzysztof
>
> Signed-off-by: Jaehoon Chung
> ---
> Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt | 2 ++
> drivers/mmc/host/dw_mmc-exynos.c | 7 +++
> 2 files changed, 9 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt
> b/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt
> index aad9844..cd22ac9 100644
> --- a/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt
> +++ b/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt
> @@ -22,6 +22,8 @@ Required Properties:
> specific extensions.
> - "samsung,exynos7-dw-mshc-smu": for controllers with Samsung Exynos7
> specific extensions having an SMU.
> + - "samsung,exynos3250-dw-mshc": for controllers with Samsung Exynos3250
> + specific extensions.
>
> * samsung,dw-mshc-ciu-div: Specifies the divider value for the card interface
>unit (ciu) clock. This property is applicable only for Exynos5 SoC's and
> diff --git a/drivers/mmc/host/dw_mmc-exynos.c
> b/drivers/mmc/host/dw_mmc-exynos.c
> index 1e75309..1c96218 100644
> --- a/drivers/mmc/host/dw_mmc-exynos.c
> +++ b/drivers/mmc/host/dw_mmc-exynos.c
> @@ -32,6 +32,7 @@ enum dw_mci_exynos_type {
> DW_MCI_TYPE_EXYNOS5420_SMU,
> DW_MCI_TYPE_EXYNOS7,
> DW_MCI_TYPE_EXYNOS7_SMU,
> + DW_MCI_TYPE_EXYNOS3250,
> };
>
> /* Exynos implementation specific driver private data */
> @@ -73,6 +74,9 @@ static struct dw_mci_exynos_compatible {
> }, {
> .compatible = "samsung,exynos7-dw-mshc-smu",
> .ctrl_type = DW_MCI_TYPE_EXYNOS7_SMU,
> + }, {
> + .compatible = "samsung,exynos3250-dw-mshc",
> + .ctrl_type = DW_MCI_TYPE_EXYNOS3250,
> },
> };
>
> @@ -467,6 +471,7 @@ static int dw_mci_exynos_execute_tuning(struct
> dw_mci_slot *slot)
> } while (start_smpl != smpl);
>
> found = dw_mci_exynos_get_best_clksmpl(candiates);
> +
> if (found >= 0) {
> dw_mci_exynos_set_clksmpl(host, found);
> priv->tuned_sample = found;
> @@ -520,6 +525,8 @@ static const struct of_device_id dw_mci_exynos_match[] = {
> .data = &exynos_drv_data, },
> { .compatible = "samsung,exynos7-dw-mshc-smu",
> .data = &exynos_drv_data, },
> + { .compatible = "samsung,exynos3250-dw-mshc",
> + .data = &exynos_drv_data, },
> {},
> };
> MODULE_DEVICE_TABLE(of, dw_mci_exynos_match);
>
--
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] mmc: pwrseq: Use highest priority for eMMC restart handler
The pwrseq_emmc driver does a eMMC card reset before a system reboot to allow broken or limited ROM boot-loaders (that don't have an eMMC reset logic) to be able to read the second stage from the eMMC. But this has to be called before a system reboot handler and while most of them use the priority 128, there are other restart handlers (such as the syscon-reboot one) that use a higher priority. So, use the highest priority to make sure that the eMMC hw is reset before a system reboot. Signed-off-by: Javier Martinez Canillas Tested-by: Markus Reichl Tested-by: Anand Moon Reviewed-by: Alim Akhtar --- Hello, This patch was needed since a recent series from Alim [0] added syscon reboot and poweroff support to Exynos SoCs and removed the reset handler in the Exynos Power Management Unit (PMU) code. But the PMU and syscon-reboot restart handler have a different priority so [0] breaks restart when eMMC is used on these boards. [0]: http://www.spinics.net/lists/arm-kernel/msg454396.html So this patch must be merged before [0] to avoid regressions. Best regards, Javier drivers/mmc/core/pwrseq_emmc.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/mmc/core/pwrseq_emmc.c b/drivers/mmc/core/pwrseq_emmc.c index 137c97fb7aa8..ad4f94ec7e8d 100644 --- a/drivers/mmc/core/pwrseq_emmc.c +++ b/drivers/mmc/core/pwrseq_emmc.c @@ -84,11 +84,11 @@ struct mmc_pwrseq *mmc_pwrseq_emmc_alloc(struct mmc_host *host, /* * register reset handler to ensure emmc reset also from -* emergency_reboot(), priority 129 schedules it just before -* system reboot +* emergency_reboot(), priority 255 is the highest priority +* so it will be executed before any system reboot handler. */ pwrseq->reset_nb.notifier_call = mmc_pwrseq_emmc_reset_nb; - pwrseq->reset_nb.priority = 129; + pwrseq->reset_nb.priority = 255; register_restart_handler(&pwrseq->reset_nb); pwrseq->pwrseq.ops = &mmc_pwrseq_emmc_ops; -- 2.4.3 -- 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] Samsung 2nd fixes for v4.3
On Saturday 17 October 2015 08:30:34 Kukjin Kim wrote: > Hello Arnd, Olof, Kevin > > Here is 2nd Samsung fixes for v4.3 and it is including fix of exynos > thermal driver with exynos thermal driver maintainer(Lukasz)'s ack. > > Please pull. > > Thanks, > Kukjin > > > The following changes since commit 6ff33f3902c3b1c5d0db6b1e2c70b6d76fba357f: > > Linux 4.3-rc1 (2015-09-12 16:35:56 -0700) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git > tags/samsung-fixes-2 > Merged into fixes, thanks! Arnd -- 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 0/6] Switch to generic syscon regmap based drivers
On Wed, Oct 21, 2015 at 8:25 PM, Javier Martinez Canillas
wrote:
> Hello Alim,
>
> On 10/21/2015 04:50 PM, Alim Akhtar wrote:
>
> [snip]
>
>>>
>>> [0]:
>>> From c9b250ee03bae338339b70693e906145c719f783 Mon Sep 17 00:00:00 2001
>>> From: Javier Martinez Canillas
>>> Date: Wed, 21 Oct 2015 11:59:44 +0200
>>> Subject: [RFT PATCH] mmc: pwrseq: Use highest priority for eMMC restart
>>> handler
>>>
>>> The pwrseq_emmc driver does a eMMC card reset before a system reboot to
>>> allow broken or limited ROM boot-loaders, that don't have an eMMC reset
>>> logic, to be able to read the second stage from the eMMC.
>>>
>>> But this has to be called before a system reboot handler and while most
>>> of them use the priority 128, there are other restart handlers (such as
>>> the syscon-reboot one) that use a higher priority. So, use the highest
>>> priority to make sure that the eMMC hw is reset before a system reboot.
>>>
>>> Signed-off-by: Javier Martinez Canillas
>>> ---
>> Looks good.
>> Reviewed-by: Alim Akhtar
>>
>
> Thanks, should I post it as a proper patch or are adding it to your
> series?
Suggest you to post as a patch collecting {Tested, Reviewed}-by (easy
for maintainers to pickup ) and probably CCing Ulf for his feedback.
> I think the latter is more reasonable so with an ack from Ulf,
> all patches can go through the linux-samsung tree.
>
yes, that is reasonable, as I said, let Krzysztof and Ulf take a call here.
> Best regards,
> --
> Javier Martinez Canillas
> Open Source Group
> Samsung Research America
--
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
Re: [PATCH v2 0/6] Switch to generic syscon regmap based drivers
Hello Alim, On 10/21/2015 04:50 PM, Alim Akhtar wrote: [snip] >> >> [0]: >> From c9b250ee03bae338339b70693e906145c719f783 Mon Sep 17 00:00:00 2001 >> From: Javier Martinez Canillas >> Date: Wed, 21 Oct 2015 11:59:44 +0200 >> Subject: [RFT PATCH] mmc: pwrseq: Use highest priority for eMMC restart >> handler >> >> The pwrseq_emmc driver does a eMMC card reset before a system reboot to >> allow broken or limited ROM boot-loaders, that don't have an eMMC reset >> logic, to be able to read the second stage from the eMMC. >> >> But this has to be called before a system reboot handler and while most >> of them use the priority 128, there are other restart handlers (such as >> the syscon-reboot one) that use a higher priority. So, use the highest >> priority to make sure that the eMMC hw is reset before a system reboot. >> >> Signed-off-by: Javier Martinez Canillas >> --- > Looks good. > Reviewed-by: Alim Akhtar > Thanks, should I post it as a proper patch or are adding it to your series? I think the latter is more reasonable so with an ack from Ulf, all patches can go through the linux-samsung tree. Best regards, -- Javier Martinez Canillas Open Source Group Samsung Research America -- 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 0/6] Switch to generic syscon regmap based drivers
Hi Javier,
On Wed, Oct 21, 2015 at 6:53 PM, Javier Martinez Canillas
wrote:
> Hello Alim,
>
> On 10/21/2015 12:44 PM, Alim Akhtar wrote:
>
> [snip]
>
>>>
>>> Can you please test following patch [0] on top of Alim's series? If that
>>> works then it should either be part of Alim's series or the patches will
>>> have to wait until that patch lands into mainline. I don't have an eMMC
>>> to test it in XU4 but I'm pretty confident that it will solve the issue.
>>>
>> I am fine with including this with my series or lowering
>> syscon_restart_handler priority to 128.
>
> Yes, I also considered changing the syscon-reboot handler priority to 128 but
> then I noticed this commit:
>
> b81180b3fd48 ("power: reset: adjust priority of simple syscon reboot driver").
>
> So as you can see, it was 128 before but was bumped to 192 so it was called
> before restart handlers registered by watchdogs. So, changing to 128 would
> break other people use cases.
>
> Now, I don't know if that is the right fix since register_restart_handler()
> explanation about the policy used for restart handler priority numbers is
> scarce. It only mentions 0, 128 and 255 so probably the correct thing to do
> is to change all watchdog restart handler to 0 but that is a separate issue.
>
>> It also make sense to increase eMMC priority as you suggested as before
>> system reboot, devices should have reseted itself.
>
> That was my rationale as well and is why I think the handler for devices
> should use the highest priority regardless if the syscon-reboot is later
> changed to prio 128 and the watchdog handlers to 0.
>
I agree, in any case dumping up eMMC reset priority make sense.
If all is good here, over to Krzysztof and Ulf to handle these patches.
Thanks.
> Best regards,
>
> [0]: http://lxr.free-electrons.com/source/kernel/reboot.c#L113
>
> Best regards,
> --
> Javier Martinez Canillas
> Open Source Group
> Samsung Research America
--
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
Re: [PATCH v2 0/6] Switch to generic syscon regmap based drivers
Hi Javier, On Wed, Oct 21, 2015 at 3:46 PM, Javier Martinez Canillas wrote: > Hello Alim, > > On 10/21/2015 08:09 AM, Alim Akhtar wrote: > > [snip] > >> >> Hi Alim, >> >> I have installed your patch set above with git am on top of >> 4.3.0-rc6-00108-gce1fad2 torvalds/linux of today >> with make exynos_defconfig on Odroid U3. >> > which exynos soc Odroid U3 uses? > OK, I can see its uses exynos4412 and exynos4412-odroidu3.dts does include exynos4.dtsi, so these should have worked. >> "halt -p" worked (power 0.0W). >> "reboot" got stuck at 0.5W. >> > reboot stuck mean system does not reboot any more? >>> >>> It freezes when going for reboot. >>> Have to power off/on to boot again. >>> >>> Btw I use an mmc, not an sd-card. >>> No other HW connected, just LAN-cable. >>> Bootloader is u-boot v2015.10. >>> o >> Have checked on 4.3.0-rc6-6-gd03c139e7e77, still works on peach boards. >> Sorry I don't have Odroid U3 with me, may be Javier or Krzysztof might help >> here to check whats wrong. To me its looks more of a board specific issue >> for now. >> > > Krzysztof has an Odroid XU3 lite and I have an Odroid XU4, both uses an > Exynos5422 so we can't check what's wrong with Odroid U3 (Exynos4412). > > Having said that I think I know what is the issue here. Markus said that > he is using an eMMC instead of an uSD (which is what I used and my guess > is that Krzysztof did too). > > Now, there is a subtle difference between the old PMU restart handler > and the syscon-reboot one, and that is the restart handler priorities: > > notifierpriority > > pmu_restart_notify 128 > mmc_pwrseq_emmc_reset_nb129 > syscon_restart_handle 192 > > So, without Alim's patches, first the eMMC reset handler will be called > and then the PMU restart handler but after his series, the syscon reset > handler has a higher priority so the eMMC reset will never be called. > > But the problem is that the eMMC card has to be properly reset on system > restart to allow the SoC iROM to be able to read the bootloader from the > eMMC since the iROM doesn't have restart logic and the card shouldn't be > left in an unknown state. > > So the problem here is not that the system is not being reset (that I > think that works) but that on reboot, the system is not able to boot > again since the ROM is not able to read the second stage bootloader. > > Markus, > > Can you please test following patch [0] on top of Alim's series? If that > works then it should either be part of Alim's series or the patches will > have to wait until that patch lands into mainline. I don't have an eMMC > to test it in XU4 but I'm pretty confident that it will solve the issue. > > Best regards, > -- > Javier Martinez Canillas > Open Source Group > Samsung Research America > > [0]: > From c9b250ee03bae338339b70693e906145c719f783 Mon Sep 17 00:00:00 2001 > From: Javier Martinez Canillas > Date: Wed, 21 Oct 2015 11:59:44 +0200 > Subject: [RFT PATCH] mmc: pwrseq: Use highest priority for eMMC restart > handler > > The pwrseq_emmc driver does a eMMC card reset before a system reboot to > allow broken or limited ROM boot-loaders, that don't have an eMMC reset > logic, to be able to read the second stage from the eMMC. > > But this has to be called before a system reboot handler and while most > of them use the priority 128, there are other restart handlers (such as > the syscon-reboot one) that use a higher priority. So, use the highest > priority to make sure that the eMMC hw is reset before a system reboot. > > Signed-off-by: Javier Martinez Canillas > --- Looks good. Reviewed-by: Alim Akhtar > drivers/mmc/core/pwrseq_emmc.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/drivers/mmc/core/pwrseq_emmc.c b/drivers/mmc/core/pwrseq_emmc.c > index 137c97fb7aa8..ad4f94ec7e8d 100644 > --- a/drivers/mmc/core/pwrseq_emmc.c > +++ b/drivers/mmc/core/pwrseq_emmc.c > @@ -84,11 +84,11 @@ struct mmc_pwrseq *mmc_pwrseq_emmc_alloc(struct mmc_host > *host, > > /* > * register reset handler to ensure emmc reset also from > -* emergency_reboot(), priority 129 schedules it just before > -* system reboot > +* emergency_reboot(), priority 255 is the highest priority > +* so it will be executed before any system reboot handler. > */ > pwrseq->reset_nb.notifier_call = mmc_pwrseq_emmc_reset_nb; > - pwrseq->reset_nb.priority = 129; > + pwrseq->reset_nb.priority = 255; > register_restart_handler(&pwrseq->reset_nb); > > pwrseq->pwrseq.ops = &mmc_pwrseq_emmc_ops; > -- > 2.4.3 -- 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
Re: [PATCH v2 0/6] Switch to generic syscon regmap based drivers
Hello Anand and Markus, On 10/21/2015 01:46 PM, Anand Moon wrote: [snip] Markus, Can you please test following patch [0] on top of Alim's series? If that works then it should either be part of Alim's series or the patches will have to wait until that patch lands into mainline. I don't have an eMMC to test it in XU4 but I'm pretty confident that it will solve the issue. >>> >>> >>> Hi Javier, >>> >>> your patch fixes the issue, reboot works now on U3. >>> >> Good to know that. >> Thanks >>> >>> Tested-by: Markus Reichl >>> >>> Thanks, >>> -- >>> Markus >>> >>> Best regards, >>> > > Tested on OdroidXU3 emmc. Reboot success. > > Tested-by: Anand Moon > Thanks a lot to both for testing the patch. Best regards, -- Javier Martinez Canillas Open Source Group Samsung Research America -- 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 0/6] Switch to generic syscon regmap based drivers
Hello Alim,
On 10/21/2015 12:44 PM, Alim Akhtar wrote:
[snip]
>>
>> Can you please test following patch [0] on top of Alim's series? If that
>> works then it should either be part of Alim's series or the patches will
>> have to wait until that patch lands into mainline. I don't have an eMMC
>> to test it in XU4 but I'm pretty confident that it will solve the issue.
>>
> I am fine with including this with my series or lowering
> syscon_restart_handler priority to 128.
Yes, I also considered changing the syscon-reboot handler priority to 128 but
then I noticed this commit:
b81180b3fd48 ("power: reset: adjust priority of simple syscon reboot driver").
So as you can see, it was 128 before but was bumped to 192 so it was called
before restart handlers registered by watchdogs. So, changing to 128 would
break other people use cases.
Now, I don't know if that is the right fix since register_restart_handler()
explanation about the policy used for restart handler priority numbers is
scarce. It only mentions 0, 128 and 255 so probably the correct thing to do
is to change all watchdog restart handler to 0 but that is a separate issue.
> It also make sense to increase eMMC priority as you suggested as before
> system reboot, devices should have reseted itself.
That was my rationale as well and is why I think the handler for devices
should use the highest priority regardless if the syscon-reboot is later
changed to prio 128 and the watchdog handlers to 0.
Best regards,
[0]: http://lxr.free-electrons.com/source/kernel/reboot.c#L113
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
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] MAINTAINERS: ARM: EXYNOS: Add documentation and dt-bindings
Hello Krzysztof, On 10/21/2015 02:43 PM, Krzysztof Kozlowski wrote: > 2015-10-21 17:45 GMT+09:00 Javier Martinez Canillas : >> >> Hello Krzysztof, >> >> Patch looks good to me, I've only one comment. >> >> On 10/21/2015 03:33 AM, Krzysztof Kozlowski wrote: >>> Extend the Samsung Exynos maintainer entry to match SoC documentation >>> and SoC dt-bindings directories. Without that some files, like >>> bindings/arm/samsung/pmu.txt, are not matched by existing patterns. >>> >>> This also may serve as a hint where new documentation and bindings (not >>> matching specific subsystem) should be put. >>> >>> Signed-off-by: Krzysztof Kozlowski >>> Cc: Kukjin Kim >>> --- >>> MAINTAINERS | 2 ++ >>> 1 file changed, 2 insertions(+) >>> >>> diff --git a/MAINTAINERS b/MAINTAINERS >>> index b556aad90930..cad7b6b628b2 100644 >>> --- a/MAINTAINERS >>> +++ b/MAINTAINERS >>> @@ -1459,6 +1459,8 @@ F: drivers/*/*s3c2410* >>> F: drivers/*/*/*s3c2410* >>> F: drivers/spi/spi-s3c* >>> F: sound/soc/samsung/* >>> +F: Documentation/arm/Samsung/ >> >> That there is also a Documentation/arm/Samsung-S3C24XX/ so >> I think this should be Documentation/arm/Samsung*/ instead. > > I am not sure... I think this is documentation from the Ben Dooks' > work and there is a entry for S3C241x machines: > SIMTEC EB2410ITX ) > I'm not familiar with S3C241x but the EB2410ITX entry only covers a couple of files under arch/arm/mach-s3c24xx, basically all that are related to the BAST machine (board file and platform data). But arch/arm/mach-s3c24* and drivers/*/*s3c2410* are covered by the ARM/SAMSUNG entry so that's why I thought the Samsung-S3C24XX docs should be there too since are SoC and not board specific. It's your call but I would put it in ARM/SAMSUNG and only the file Documentation/arm/Samsung-S3C24XX/EB2410ITX.txt in the BAST entry. > Best regards, > Krzysztof > Best regards, -- Javier Martinez Canillas Open Source Group Samsung Research America -- 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] MAINTAINERS: ARM: EXYNOS: Add documentation and dt-bindings
2015-10-21 17:45 GMT+09:00 Javier Martinez Canillas : > > Hello Krzysztof, > > Patch looks good to me, I've only one comment. > > On 10/21/2015 03:33 AM, Krzysztof Kozlowski wrote: > > Extend the Samsung Exynos maintainer entry to match SoC documentation > > and SoC dt-bindings directories. Without that some files, like > > bindings/arm/samsung/pmu.txt, are not matched by existing patterns. > > > > This also may serve as a hint where new documentation and bindings (not > > matching specific subsystem) should be put. > > > > Signed-off-by: Krzysztof Kozlowski > > Cc: Kukjin Kim > > --- > > MAINTAINERS | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > index b556aad90930..cad7b6b628b2 100644 > > --- a/MAINTAINERS > > +++ b/MAINTAINERS > > @@ -1459,6 +1459,8 @@ F: drivers/*/*s3c2410* > > F: drivers/*/*/*s3c2410* > > F: drivers/spi/spi-s3c* > > F: sound/soc/samsung/* > > +F: Documentation/arm/Samsung/ > > That there is also a Documentation/arm/Samsung-S3C24XX/ so > I think this should be Documentation/arm/Samsung*/ instead. I am not sure... I think this is documentation from the Ben Dooks' work and there is a entry for S3C241x machines: SIMTEC EB2410ITX (BAST) Best regards, Krzysztof > > > +F: Documentation/devicetree/bindings/arm/samsung/ > > N: exynos > > > > ARM/SAMSUNG MOBILE MACHINE SUPPORT > > > > Reviewed-by: Javier Martinez Canillas > > Best regards, > -- > Javier Martinez Canillas > Open Source Group > Samsung Research America > -- > 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 -- 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 3/6] arm: dts: Add syscon-{reboot, poweroff} nodes for exynos5
hi Alim,
On 20 October 2015 at 16:00, Javier Martinez Canillas
wrote:
> Hello Alim,
>
> On 10/20/2015 11:24 AM, Alim Akhtar wrote:
>> This patch adds syscon-{reboot, poweroff} nodes to allow the
>> generic syscon-{reboot, poweroff} driver to reset/poweroff exynos5 SoCs.
>>
>> Signed-off-by: Alim Akhtar
>> Reviewed-by: Pankaj Dubey
>> Reviewed-by: Javier Martinez Canillas
>> Acked-by: Moritz Fischer
>> ---
>> arch/arm/boot/dts/exynos5.dtsi | 14 ++
>> 1 file changed, 14 insertions(+)
>>
>
> Tested-by: Javier Martinez Canillas
>
> Best regards,
> --
> Javier Martinez Canillas
> Open Source Group
> Samsung Research America
> --
Tested on OdroidXU3.
Tested-by: Anand Moon
-Anand Moon
> 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
--
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 0/6] Switch to generic syscon regmap based drivers
Hi Javier, On 21 October 2015 at 16:16, Alim Akhtar wrote: > > > On 10/21/2015 04:12 PM, Markus Reichl wrote: >> >> Am 21.10.2015 um 12:16 schrieb Javier Martinez Canillas: >>> >>> Hello Alim, >>> >>> On 10/21/2015 08:09 AM, Alim Akhtar wrote: >>> >>> [snip] >>> Hi Alim, I have installed your patch set above with git am on top of 4.3.0-rc6-00108-gce1fad2 torvalds/linux of today with make exynos_defconfig on Odroid U3. >>> which exynos soc Odroid U3 uses? >>> >> OK, I can see its uses exynos4412 and exynos4412-odroidu3.dts does >> include exynos4.dtsi, >> so these should have worked. >> "halt -p" worked (power 0.0W). "reboot" got stuck at 0.5W. >>> reboot stuck mean system does not reboot any more? > > > It freezes when going for reboot. > Have to power off/on to boot again. > > Btw I use an mmc, not an sd-card. > No other HW connected, just LAN-cable. > Bootloader is u-boot v2015.10. > o Have checked on 4.3.0-rc6-6-gd03c139e7e77, still works on peach boards. Sorry I don't have Odroid U3 with me, may be Javier or Krzysztof might help here to check whats wrong. To me its looks more of a board specific issue for now. >>> >>> Krzysztof has an Odroid XU3 lite and I have an Odroid XU4, both uses an >>> Exynos5422 so we can't check what's wrong with Odroid U3 (Exynos4412). >>> >>> Having said that I think I know what is the issue here. Markus said that >>> he is using an eMMC instead of an uSD (which is what I used and my guess >>> is that Krzysztof did too). >>> >>> Now, there is a subtle difference between the old PMU restart handler >>> and the syscon-reboot one, and that is the restart handler priorities: >>> >>> notifierpriority >>> >>> pmu_restart_notify 128 >>> mmc_pwrseq_emmc_reset_nb129 >>> syscon_restart_handle 192 >>> >>> So, without Alim's patches, first the eMMC reset handler will be called >>> and then the PMU restart handler but after his series, the syscon reset >>> handler has a higher priority so the eMMC reset will never be called. >>> >>> But the problem is that the eMMC card has to be properly reset on system >>> restart to allow the SoC iROM to be able to read the bootloader from the >>> eMMC since the iROM doesn't have restart logic and the card shouldn't be >>> left in an unknown state. >>> >>> So the problem here is not that the system is not being reset (that I >>> think that works) but that on reboot, the system is not able to boot >>> again since the ROM is not able to read the second stage bootloader. >>> >>> Markus, >>> >>> Can you please test following patch [0] on top of Alim's series? If that >>> works then it should either be part of Alim's series or the patches will >>> have to wait until that patch lands into mainline. I don't have an eMMC >>> to test it in XU4 but I'm pretty confident that it will solve the issue. >> >> >> Hi Javier, >> >> your patch fixes the issue, reboot works now on U3. >> > Good to know that. > Thanks >> >> Tested-by: Markus Reichl >> >> Thanks, >> -- >> Markus >> >> >>> >>> Best regards, >>> >> Tested on OdroidXU3 emmc. Reboot success. Tested-by: Anand Moon -Anand Moon >> >> > -- > 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 -- 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 0/6] Switch to generic syscon regmap based drivers
On 10/21/2015 04:12 PM, Markus Reichl wrote: Am 21.10.2015 um 12:16 schrieb Javier Martinez Canillas: Hello Alim, On 10/21/2015 08:09 AM, Alim Akhtar wrote: [snip] Hi Alim, I have installed your patch set above with git am on top of 4.3.0-rc6-00108-gce1fad2 torvalds/linux of today with make exynos_defconfig on Odroid U3. which exynos soc Odroid U3 uses? OK, I can see its uses exynos4412 and exynos4412-odroidu3.dts does include exynos4.dtsi, so these should have worked. "halt -p" worked (power 0.0W). "reboot" got stuck at 0.5W. reboot stuck mean system does not reboot any more? It freezes when going for reboot. Have to power off/on to boot again. Btw I use an mmc, not an sd-card. No other HW connected, just LAN-cable. Bootloader is u-boot v2015.10. o Have checked on 4.3.0-rc6-6-gd03c139e7e77, still works on peach boards. Sorry I don't have Odroid U3 with me, may be Javier or Krzysztof might help here to check whats wrong. To me its looks more of a board specific issue for now. Krzysztof has an Odroid XU3 lite and I have an Odroid XU4, both uses an Exynos5422 so we can't check what's wrong with Odroid U3 (Exynos4412). Having said that I think I know what is the issue here. Markus said that he is using an eMMC instead of an uSD (which is what I used and my guess is that Krzysztof did too). Now, there is a subtle difference between the old PMU restart handler and the syscon-reboot one, and that is the restart handler priorities: notifierpriority pmu_restart_notify 128 mmc_pwrseq_emmc_reset_nb129 syscon_restart_handle 192 So, without Alim's patches, first the eMMC reset handler will be called and then the PMU restart handler but after his series, the syscon reset handler has a higher priority so the eMMC reset will never be called. But the problem is that the eMMC card has to be properly reset on system restart to allow the SoC iROM to be able to read the bootloader from the eMMC since the iROM doesn't have restart logic and the card shouldn't be left in an unknown state. So the problem here is not that the system is not being reset (that I think that works) but that on reboot, the system is not able to boot again since the ROM is not able to read the second stage bootloader. Markus, Can you please test following patch [0] on top of Alim's series? If that works then it should either be part of Alim's series or the patches will have to wait until that patch lands into mainline. I don't have an eMMC to test it in XU4 but I'm pretty confident that it will solve the issue. Hi Javier, your patch fixes the issue, reboot works now on U3. Good to know that. Thanks Tested-by: Markus Reichl Thanks, -- Markus Best regards, -- 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 0/6] Switch to generic syscon regmap based drivers
Hi Javier, On 10/21/2015 03:46 PM, Javier Martinez Canillas wrote: Hello Alim, On 10/21/2015 08:09 AM, Alim Akhtar wrote: [snip] Hi Alim, I have installed your patch set above with git am on top of 4.3.0-rc6-00108-gce1fad2 torvalds/linux of today with make exynos_defconfig on Odroid U3. which exynos soc Odroid U3 uses? OK, I can see its uses exynos4412 and exynos4412-odroidu3.dts does include exynos4.dtsi, so these should have worked. "halt -p" worked (power 0.0W). "reboot" got stuck at 0.5W. reboot stuck mean system does not reboot any more? It freezes when going for reboot. Have to power off/on to boot again. Btw I use an mmc, not an sd-card. No other HW connected, just LAN-cable. Bootloader is u-boot v2015.10. o Have checked on 4.3.0-rc6-6-gd03c139e7e77, still works on peach boards. Sorry I don't have Odroid U3 with me, may be Javier or Krzysztof might help here to check whats wrong. To me its looks more of a board specific issue for now. Krzysztof has an Odroid XU3 lite and I have an Odroid XU4, both uses an Exynos5422 so we can't check what's wrong with Odroid U3 (Exynos4412). Having said that I think I know what is the issue here. Markus said that he is using an eMMC instead of an uSD (which is what I used and my guess is that Krzysztof did too). Now, there is a subtle difference between the old PMU restart handler and the syscon-reboot one, and that is the restart handler priorities: notifierpriority pmu_restart_notify 128 mmc_pwrseq_emmc_reset_nb129 syscon_restart_handle 192 So, without Alim's patches, first the eMMC reset handler will be called and then the PMU restart handler but after his series, the syscon reset handler has a higher priority so the eMMC reset will never be called. But the problem is that the eMMC card has to be properly reset on system restart to allow the SoC iROM to be able to read the bootloader from the eMMC since the iROM doesn't have restart logic and the card shouldn't be left in an unknown state. So the problem here is not that the system is not being reset (that I think that works) but that on reboot, the system is not able to boot again since the ROM is not able to read the second stage bootloader. Thanks for nailing it down, this make lots of sense and probably the main cause of Odroid U3 reboot failure. I was going to suggest Markus to try a uSD boot. But looks like your suggested patch will do the trick for him. Markus, Can you please test following patch [0] on top of Alim's series? If that works then it should either be part of Alim's series or the patches will have to wait until that patch lands into mainline. I don't have an eMMC to test it in XU4 but I'm pretty confident that it will solve the issue. I am fine with including this with my series or lowering syscon_restart_handler priority to 128. It also make sense to increase eMMC priority as you suggested as before system reboot, devices should have reseted itself. Thanks! Best regards, -- 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 0/6] Switch to generic syscon regmap based drivers
Am 21.10.2015 um 12:16 schrieb Javier Martinez Canillas: > Hello Alim, > > On 10/21/2015 08:09 AM, Alim Akhtar wrote: > > [snip] > >> >> Hi Alim, >> >> I have installed your patch set above with git am on top of >> 4.3.0-rc6-00108-gce1fad2 torvalds/linux of today >> with make exynos_defconfig on Odroid U3. >> > which exynos soc Odroid U3 uses? > OK, I can see its uses exynos4412 and exynos4412-odroidu3.dts does include exynos4.dtsi, so these should have worked. >> "halt -p" worked (power 0.0W). >> "reboot" got stuck at 0.5W. >> > reboot stuck mean system does not reboot any more? >>> >>> It freezes when going for reboot. >>> Have to power off/on to boot again. >>> >>> Btw I use an mmc, not an sd-card. >>> No other HW connected, just LAN-cable. >>> Bootloader is u-boot v2015.10. >>> o >> Have checked on 4.3.0-rc6-6-gd03c139e7e77, still works on peach boards. >> Sorry I don't have Odroid U3 with me, may be Javier or Krzysztof might help >> here to check whats wrong. To me its looks more of a board specific issue >> for now. >> > > Krzysztof has an Odroid XU3 lite and I have an Odroid XU4, both uses an > Exynos5422 so we can't check what's wrong with Odroid U3 (Exynos4412). > > Having said that I think I know what is the issue here. Markus said that > he is using an eMMC instead of an uSD (which is what I used and my guess > is that Krzysztof did too). > > Now, there is a subtle difference between the old PMU restart handler > and the syscon-reboot one, and that is the restart handler priorities: > > notifierpriority > > pmu_restart_notify 128 > mmc_pwrseq_emmc_reset_nb129 > syscon_restart_handle 192 > > So, without Alim's patches, first the eMMC reset handler will be called > and then the PMU restart handler but after his series, the syscon reset > handler has a higher priority so the eMMC reset will never be called. > > But the problem is that the eMMC card has to be properly reset on system > restart to allow the SoC iROM to be able to read the bootloader from the > eMMC since the iROM doesn't have restart logic and the card shouldn't be > left in an unknown state. > > So the problem here is not that the system is not being reset (that I > think that works) but that on reboot, the system is not able to boot > again since the ROM is not able to read the second stage bootloader. > > Markus, > > Can you please test following patch [0] on top of Alim's series? If that > works then it should either be part of Alim's series or the patches will > have to wait until that patch lands into mainline. I don't have an eMMC > to test it in XU4 but I'm pretty confident that it will solve the issue. Hi Javier, your patch fixes the issue, reboot works now on U3. Tested-by: Markus Reichl Thanks, -- Markus > > Best regards, > -- 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/3] ARM: dts: exynos5422-odroidxu3: Added UHS-I bus speed support
Hi, Anand. On 10/14/2015 12:58 PM, Anand Moon wrote: > hi Krzysztof, > > On 14 October 2015 at 05:29, Krzysztof Kozlowski > wrote: >> On 14.10.2015 01:27, Anand Moon wrote: >>> Hi Krzysztof, >>> >>> On 13 October 2015 at 09:13, Krzysztof Kozlowski >>> wrote: On 13.10.2015 12:08, Anand Moon wrote: > Hi Krzysztof, > > On 13 October 2015 at 05:44, Krzysztof Kozlowski > wrote: >> On 13.10.2015 00:32, Anand Moon wrote: >>> Hi Krzysztof, >>> >>> On 12 October 2015 at 11:14, Krzysztof Kozlowski >>> wrote: On 12.10.2015 00:46, Anand Moon wrote: > Added support for UHS-I bus speed 50MB/s (SDR50, DDR50) 104MB/s > (SDR104) This description is not entirely correct. The MMC driver already supports these UHS speeds (you did not any code) so you rather enabled it (description of bindings says "is supported"). You mentioned DDR50 but I don't see respective property below. How do you know that these modes are really supported? I don't know. Can you convince me? >>> >>> Setting this DDR50 capability give me this error. That's the reason to >>> drop this capability. >> >> But you mentioned it in commit message! "Added support for UHS-I ... >> (DDR50)" >> >> In the same time dropping DDR50 is not an sufficient proof that "SDR50 >> and SDR104 are really supported". >> > > These changes are related to the microSD card capabilities. > So SDR50 have better frequency over DDR50. On the same Sandisk card. > > When the card select the capability for DDR50 > --- > [4.001477] mmc_host mmc1: Bus speed (slot 0) = 5000Hz (slot > req 5000Hz, actual 5000HZ div = 0) > [4.001604] mmc1: new ultra high speed DDR50 SDHC card at address > [4.004505] mmcblk0: mmc1: SL32G 29.7 GiB > [4.009179] mmcblk0: error -110 sending status command, retrying > [4.009271] mmcblk0: error -115 sending stop command, original cmd > response 0x900, card status 0x900 > [4.009275] mmcblk0: error -84 transferring data, sector 0, nr 8, > cmd response 0x900, card status 0x0 > [4.025563] mmc_host mmc1: Bus speed (slot 0) = 5000Hz (slot > req 40Hz, actual 396825HZ div = 63) > [4.067770] Console: switching to colour frame buffer device 274x77 > [4.098782] mmc_host mmc1: Bus speed (slot 0) = 5000Hz (slot > req 5000Hz, actual 5000HZ div = 0) > [4.099692] mmc1: tried to reset card > [4.101332] mmcblk0: p1 p2 I found this issue that produced on your board. I will send the patch and test DDR50 on your board. Best Regards, Jaehoon Chung > > > When the card select the capability for SDR50 > - > [ 2.439806] mmc_host mmc1: Bus speed (slot 0) = 1Hz (slot req > 1Hz, actual 1HZ div = 0) > [ 2.449729] mmc1: new ultra high speed SDR50 SDHC card at address > [ 2.455984] mmcblk0: mmc1: SL32G 29.7 GiB > [ 2.461743] mmcblk0: p1 p2 > > Which will relate to better read/write speed. Which is not an answer to my question. To none of my previous questions. >>> >>> Basically UHS-I capability (sd-uhs-sdr12, sd-uhs-sdr25, sd-uhs-sdr50, >>> sd-uhs-sdr104) help tune speed supported for mmc >>> >>> I have tired to compare the speed on high speed UHS-I vs ultra high >>> speed UHS-I using izone utility. >>> >>> [2.572469] mmc_host mmc1: Bus speed (slot 0) = 5000Hz (slot >>> req 5000Hz, actual 5000HZ div = 0) >>> [2.572609] mmc1: new high speed SDHC card at address >>> >>> Command line used: ./iozone -L64 -S32 -azecwI -+n -r4k -r64k >>> -r128k -s10M -i0 -i1 -i2 -f datafile -Rb out.xls >>> Output is in kBytes/sec >>> Time Resolution = 0.01 seconds. >>> Processor cache size set to 32 kBytes. >>> Processor cache line size set to 64 bytes. >>> File stride size set to 17 * record size. >>> random >>> random bkwdrecordstride >>> kB reclenwrite rewritereadrereadread >>> write read rewrite read fwrite frewritefread >>> freread >>>10240 4 16310 65560 5538 >>> 982 >>>10240 64 8828018897017994 >>> 303 >>>10240 128 6269020670020128 >>> 1096 >>> - >>> [2.613761] mmc_host mmc1: Bus speed (slot 0) = 1Hz (slot >>> req 1Hz, actual 1HZ div = 0) >>> [
Re: [PATCH v2 0/6] Switch to generic syscon regmap based drivers
Hello Alim, On 10/21/2015 08:09 AM, Alim Akhtar wrote: [snip] > > Hi Alim, > > I have installed your patch set above with git am on top of > 4.3.0-rc6-00108-gce1fad2 torvalds/linux of today > with make exynos_defconfig on Odroid U3. > which exynos soc Odroid U3 uses? >>> OK, I can see its uses exynos4412 and exynos4412-odroidu3.dts does >>> include exynos4.dtsi, >>> so these should have worked. >>> > "halt -p" worked (power 0.0W). > "reboot" got stuck at 0.5W. > reboot stuck mean system does not reboot any more? >> >> It freezes when going for reboot. >> Have to power off/on to boot again. >> >> Btw I use an mmc, not an sd-card. >> No other HW connected, just LAN-cable. >> Bootloader is u-boot v2015.10. >> o > Have checked on 4.3.0-rc6-6-gd03c139e7e77, still works on peach boards. > Sorry I don't have Odroid U3 with me, may be Javier or Krzysztof might help > here to check whats wrong. To me its looks more of a board specific issue for > now. > Krzysztof has an Odroid XU3 lite and I have an Odroid XU4, both uses an Exynos5422 so we can't check what's wrong with Odroid U3 (Exynos4412). Having said that I think I know what is the issue here. Markus said that he is using an eMMC instead of an uSD (which is what I used and my guess is that Krzysztof did too). Now, there is a subtle difference between the old PMU restart handler and the syscon-reboot one, and that is the restart handler priorities: notifierpriority pmu_restart_notify 128 mmc_pwrseq_emmc_reset_nb129 syscon_restart_handle 192 So, without Alim's patches, first the eMMC reset handler will be called and then the PMU restart handler but after his series, the syscon reset handler has a higher priority so the eMMC reset will never be called. But the problem is that the eMMC card has to be properly reset on system restart to allow the SoC iROM to be able to read the bootloader from the eMMC since the iROM doesn't have restart logic and the card shouldn't be left in an unknown state. So the problem here is not that the system is not being reset (that I think that works) but that on reboot, the system is not able to boot again since the ROM is not able to read the second stage bootloader. Markus, Can you please test following patch [0] on top of Alim's series? If that works then it should either be part of Alim's series or the patches will have to wait until that patch lands into mainline. I don't have an eMMC to test it in XU4 but I'm pretty confident that it will solve the issue. Best regards, -- Javier Martinez Canillas Open Source Group Samsung Research America [0]: >From c9b250ee03bae338339b70693e906145c719f783 Mon Sep 17 00:00:00 2001 From: Javier Martinez Canillas Date: Wed, 21 Oct 2015 11:59:44 +0200 Subject: [RFT PATCH] mmc: pwrseq: Use highest priority for eMMC restart handler The pwrseq_emmc driver does a eMMC card reset before a system reboot to allow broken or limited ROM boot-loaders, that don't have an eMMC reset logic, to be able to read the second stage from the eMMC. But this has to be called before a system reboot handler and while most of them use the priority 128, there are other restart handlers (such as the syscon-reboot one) that use a higher priority. So, use the highest priority to make sure that the eMMC hw is reset before a system reboot. Signed-off-by: Javier Martinez Canillas --- drivers/mmc/core/pwrseq_emmc.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/mmc/core/pwrseq_emmc.c b/drivers/mmc/core/pwrseq_emmc.c index 137c97fb7aa8..ad4f94ec7e8d 100644 --- a/drivers/mmc/core/pwrseq_emmc.c +++ b/drivers/mmc/core/pwrseq_emmc.c @@ -84,11 +84,11 @@ struct mmc_pwrseq *mmc_pwrseq_emmc_alloc(struct mmc_host *host, /* * register reset handler to ensure emmc reset also from -* emergency_reboot(), priority 129 schedules it just before -* system reboot +* emergency_reboot(), priority 255 is the highest priority +* so it will be executed before any system reboot handler. */ pwrseq->reset_nb.notifier_call = mmc_pwrseq_emmc_reset_nb; - pwrseq->reset_nb.priority = 129; + pwrseq->reset_nb.priority = 255; register_restart_handler(&pwrseq->reset_nb); pwrseq->pwrseq.ops = &mmc_pwrseq_emmc_ops; -- 2.4.3 -- 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 12/19] ARM: dts: exynos: replace legacy *,wakeup property with wakeup-source
Though the keyboard and other driver will continue to support the legacy
"gpio-key,wakeup", "linux-keypad,wakeup" boolean property to enable the
wakeup source, "wakeup-source" is the new standard binding.
This patch replaces all the legacy wakeup properties with the unified
"wakeup-source" property in order to avoid any futher copy-paste
duplication.
Cc: Kukjin Kim
Cc: Krzysztof Kozlowski
Cc: linux-samsung-soc@vger.kernel.org
Signed-off-by: Sudeep Holla
---
arch/arm/boot/dts/exynos3250-monk.dts | 6 +++---
arch/arm/boot/dts/exynos3250-rinato.dts | 6 +++---
arch/arm/boot/dts/exynos4210-origen.dts | 10 +-
arch/arm/boot/dts/exynos4210-smdkv310.dts | 2 +-
arch/arm/boot/dts/exynos4210-trats.dts | 2 +-
arch/arm/boot/dts/exynos4210-universal_c210.dts | 4 ++--
arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 2 +-
arch/arm/boot/dts/exynos4412-odroidx.dts| 2 +-
arch/arm/boot/dts/exynos4412-origen.dts | 2 +-
arch/arm/boot/dts/exynos4412-smdk4412.dts | 2 +-
arch/arm/boot/dts/exynos4412-trats2.dts | 4 ++--
arch/arm/boot/dts/exynos5250-arndale.dts| 12 ++--
arch/arm/boot/dts/exynos5250-snow.dts | 4 ++--
arch/arm/boot/dts/exynos5250-spring.dts | 4 ++--
arch/arm/boot/dts/exynos5420-arndale-octa.dts | 2 +-
arch/arm/boot/dts/exynos5420-peach-pit.dts | 4 ++--
arch/arm/boot/dts/exynos5800-peach-pi.dts | 4 ++--
17 files changed, 36 insertions(+), 36 deletions(-)
diff --git a/arch/arm/boot/dts/exynos3250-monk.dts
b/arch/arm/boot/dts/exynos3250-monk.dts
index 540a0adf2be6..b77ea2163a0a 100644
--- a/arch/arm/boot/dts/exynos3250-monk.dts
+++ b/arch/arm/boot/dts/exynos3250-monk.dts
@@ -43,7 +43,7 @@
linux,code = ;
label = "power key";
debounce-interval = <10>;
- gpio-key,wakeup;
+ wakeup-source;
};
};
@@ -67,7 +67,7 @@
interrupt-parent = <&gpx1>;
interrupts = <5 0>;
reg = <0x25>;
- wakeup;
+ wakeup-source;
muic: max77836-muic {
compatible = "maxim,max77836-muic";
@@ -184,7 +184,7 @@
interrupt-parent = <&gpx0>;
interrupts = <7 0>;
reg = <0x66>;
- wakeup;
+ wakeup-source;
s2mps14_osc: clocks {
compatible = "samsung,s2mps14-clk";
diff --git a/arch/arm/boot/dts/exynos3250-rinato.dts
b/arch/arm/boot/dts/exynos3250-rinato.dts
index 41a5fafb9aa9..7acd11d2d957 100644
--- a/arch/arm/boot/dts/exynos3250-rinato.dts
+++ b/arch/arm/boot/dts/exynos3250-rinato.dts
@@ -43,7 +43,7 @@
linux,code = ;
label = "power key";
debounce-interval = <10>;
- gpio-key,wakeup;
+ wakeup-source;
};
};
@@ -58,7 +58,7 @@
interrupt-parent = <&gpx1>;
interrupts = <5 0>;
reg = <0x25>;
- wakeup;
+ wakeup-source;
muic: max77836-muic {
compatible = "maxim,max77836-muic";
@@ -245,7 +245,7 @@
interrupt-parent = <&gpx0>;
interrupts = <7 0>;
reg = <0x66>;
- wakeup;
+ wakeup-source;
s2mps14_osc: clocks {
compatible = "samsung,s2mps14-clk";
diff --git a/arch/arm/boot/dts/exynos4210-origen.dts
b/arch/arm/boot/dts/exynos4210-origen.dts
index e050d85cdacd..9e97f6065493 100644
--- a/arch/arm/boot/dts/exynos4210-origen.dts
+++ b/arch/arm/boot/dts/exynos4210-origen.dts
@@ -59,35 +59,35 @@
label = "Up";
gpios = <&gpx2 0 1>;
linux,code = ;
- gpio-key,wakeup;
+ wakeup-source;
};
down {
label = "Down";
gpios = <&gpx2 1 1>;
linux,code = ;
- gpio-key,wakeup;
+ wakeup-source;
};
back {
label = "Back";
gpios = <&gpx1 7 1>;
linux,code = ;
- gpio-key,wakeup;
+ wakeup-source;
};
home {
label = "Home";
gpios = <&gpx1 6 1>;
linux,code = ;
- gpio-key,wakeup;
+ wakeup-source;
};
menu {
[PATCH 16/19] ARM: dts: s5pv210: replace legacy *,wakeup property with wakeup-source
Though the keyboard and other driver will continue to support the legacy
"gpio-key,wakeup", "linux,input-wakeup" boolean property to enable the
wakeup source, "wakeup-source" is the new standard binding.
This patch replaces all the legacy wakeup properties with the unified
"wakeup-source" property in order to avoid any futher copy-paste
duplication.
Cc: Marek Szyprowski
Cc: Kukjin Kim
Cc: linux-samsung-soc@vger.kernel.org
Signed-off-by: Sudeep Holla
---
arch/arm/boot/dts/s5pv210-aquila.dts | 4 ++--
arch/arm/boot/dts/s5pv210-goni.dts | 4 ++--
arch/arm/boot/dts/s5pv210-smdkv210.dts | 2 +-
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm/boot/dts/s5pv210-aquila.dts
b/arch/arm/boot/dts/s5pv210-aquila.dts
index f00cea7aca2f..72f162e7040b 100644
--- a/arch/arm/boot/dts/s5pv210-aquila.dts
+++ b/arch/arm/boot/dts/s5pv210-aquila.dts
@@ -257,7 +257,7 @@
linux,code = ;
label = "power";
debounce-interval = <1>;
- gpio-key,wakeup;
+ wakeup-source;
};
};
};
@@ -268,7 +268,7 @@
&keypad {
linux,input-no-autorepeat;
- linux,input-wakeup;
+ wakeup-source;
samsung,keypad-num-rows = <3>;
samsung,keypad-num-columns = <3>;
pinctrl-names = "default";
diff --git a/arch/arm/boot/dts/s5pv210-goni.dts
b/arch/arm/boot/dts/s5pv210-goni.dts
index a3d4643b202e..f4d0a023c31c 100644
--- a/arch/arm/boot/dts/s5pv210-goni.dts
+++ b/arch/arm/boot/dts/s5pv210-goni.dts
@@ -239,7 +239,7 @@
linux,code = ;
label = "power";
debounce-interval = <1>;
- gpio-key,wakeup;
+ wakeup-source;
};
};
};
@@ -250,7 +250,7 @@
&keypad {
linux,input-no-autorepeat;
- linux,input-wakeup;
+ wakeup-source;
samsung,keypad-num-rows = <3>;
samsung,keypad-num-columns = <3>;
pinctrl-names = "default";
diff --git a/arch/arm/boot/dts/s5pv210-smdkv210.dts
b/arch/arm/boot/dts/s5pv210-smdkv210.dts
index da7d210df670..54fcc3fc82e2 100644
--- a/arch/arm/boot/dts/s5pv210-smdkv210.dts
+++ b/arch/arm/boot/dts/s5pv210-smdkv210.dts
@@ -59,7 +59,7 @@
&keypad {
linux,input-no-autorepeat;
- linux,input-wakeup;
+ wakeup-source;
samsung,keypad-num-rows = <8>;
samsung,keypad-num-columns = <8>;
pinctrl-names = "default";
--
1.9.1
--
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] MAINTAINERS: ARM: EXYNOS: Add documentation and dt-bindings
Hello Krzysztof, Patch looks good to me, I've only one comment. On 10/21/2015 03:33 AM, Krzysztof Kozlowski wrote: > Extend the Samsung Exynos maintainer entry to match SoC documentation > and SoC dt-bindings directories. Without that some files, like > bindings/arm/samsung/pmu.txt, are not matched by existing patterns. > > This also may serve as a hint where new documentation and bindings (not > matching specific subsystem) should be put. > > Signed-off-by: Krzysztof Kozlowski > Cc: Kukjin Kim > --- > MAINTAINERS | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index b556aad90930..cad7b6b628b2 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -1459,6 +1459,8 @@ F: drivers/*/*s3c2410* > F: drivers/*/*/*s3c2410* > F: drivers/spi/spi-s3c* > F: sound/soc/samsung/* > +F: Documentation/arm/Samsung/ That there is also a Documentation/arm/Samsung-S3C24XX/ so I think this should be Documentation/arm/Samsung*/ instead. > +F: Documentation/devicetree/bindings/arm/samsung/ > N: exynos > > ARM/SAMSUNG MOBILE MACHINE SUPPORT > Reviewed-by: Javier Martinez Canillas Best regards, -- Javier Martinez Canillas Open Source Group Samsung Research America -- 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/2] dt-bindings: EXYNOS: Document compatibles from other vendors
Hello Krzysztof, On 10/21/2015 03:30 AM, Krzysztof Kozlowski wrote: > Document compatibles used on other Exynos-based boards (non-Samsung): > FriendlyARM, Google, Hardkernel and Insignal. > > Signed-off-by: Krzysztof Kozlowski > Cc: Kukjin Kim > Cc: Javier Martinez Canillas > Cc: Hakjoo Kim > --- Reviewed-by: Javier Martinez Canillas Best regards, -- Javier Martinez Canillas Open Source Group Samsung Research America -- 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/2] dt-bindings: Consolidate Exynos SoC bindings under Samsung directory
Hello Krzysztof, On 10/21/2015 03:30 AM, Krzysztof Kozlowski wrote: > Exynos SoC Device Tree bindings are spread over arm/exynos/ and > arm/samsung/ directories. There is no need for that separation and it > actually confuses. Put everything under arm/samsung/. > > Signed-off-by: Krzysztof Kozlowski > Cc: Kukjin Kim > --- Patch looks good to me. Reviewed-by: Javier Martinez Canillas Best regards, -- Javier Martinez Canillas Open Source Group Samsung Research America -- 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 v4 6/8] drivers: soc: add support for exynos SROM driver
Hello! > can we add the "depends on ... && PM" now, later, once > you'll extend it, you remove it again? Yes, you can. However, i think i'll post my patches as soon as the code gets integrated into some repository, before it even goes to the RC. So, it's up to you. Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia -- 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
