Re: [PATCH v2] [media] media-device: handle errors at media_device_init()

[Javier Martinez Canillas]

Hello Mauro,

On 12/15/2015 09:22 AM, Mauro Carvalho Chehab wrote:
> Changeset 43ac4401dca9 ("[media] media-device: split media
> initialization and registration") broke media device register
> into two separate functions, but introduced a BUG_ON() and
> made media_device_init() void. It also introduced several
> warnings.
> 
> Instead of adding BUG_ON(), let's revert to WARN_ON() and fix
> the init code in a way that, if something goes wrong during
> device init, driver probe will fail without causing the Kernel
> to BUG.
> 
> Signed-off-by: Mauro Carvalho Chehab <mche...@osg.samsung.com>
> ---

I agree with your patch, in fact the first version of the media
split patch did exactly this and later media_device_init() was
converted to void and the BUG_ON() introduced to address some
feedback I got during the patches review.

Reviewed-by: Javier Martinez Canillas <jav...@osg.samsung.com>

On an OMAP3 IGEPv2:

Tested-by: Javier Martinez Canillas <jav...@osg.samsung.com>

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] [media] media-device: split media initialization and registration

[Javier Martinez Canillas]

Hello Mauro,

On 12/15/2015 08:13 AM, Mauro Carvalho Chehab wrote:

[snip]

>>>  
>>>  /**
>>> - * media_device_register - register a media device
>>> + * media_device_init() - initialize a media device
>>>   * @mdev:  The media device
>>>   *
>>>   * The caller is responsible for initializing the media device before
>>> @@ -534,12 +534,11 @@ static void media_device_release(struct media_devnode 
>>> *mdev)
>>>   *
>>>   * - dev must point to the parent device
>>>   * - model must be filled with the device model name
>>> + *
>>> + * returns zero on success or a negative error code.
>>>   */
>>> -int __must_check __media_device_register(struct media_device *mdev,
>>> -struct module *owner)
>>> +int __must_check media_device_init(struct media_device *mdev)
>>
>> I think I suggested making media_device_init() return void as the only
>> remaining source of errors would be driver bugs.
>>
>> I'd simply replace the WARN_ON() below with BUG().
> 
> That sounds like bad idea to me, and it is against the current
> Kernel policy of using BUG() only when there's no other way, e. g. on
> event so severe that the Kernel has no other thing to do except to
> stop running.
>

I agree with you, that was exactly my point and what I told Sakari [0] but
he had a strong opinion about it and I didn't mind too much so I decided at
the end to just change it to a BUG_ON() so I could get his ack for this set.
 
> For sure, this is not the case here. Also, all drivers have already
> a logic that checks if the device init happened. So, they should already
> be doing the right thing.
>
> Regards,
> Mauro

[0]: https://lkml.org/lkml/2015/9/10/483

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 v5 3/7] ARM: dts: Exynos542x/5800: add CPU OPP properties

[Javier Martinez Canillas]

Hello Viresh,

On 12/11/2015 12:16 AM, Viresh Kumar wrote:
> On 10-12-15, 17:58, Bartlomiej Zolnierkiewicz wrote:
>> diff --git a/arch/arm/boot/dts/exynos5422-cpus.dtsi 
>> b/arch/arm/boot/dts/exynos5422-cpus.dtsi
>> index b7f60c8..9a5131d 100644
>> --- a/arch/arm/boot/dts/exynos5422-cpus.dtsi
>> +++ b/arch/arm/boot/dts/exynos5422-cpus.dtsi
>> @@ -20,8 +20,10 @@
>>  device_type = "cpu";
>>  compatible = "arm,cortex-a7";
>>  reg = <0x100>;
>> +clocks = < CLK_KFC_CLK>;
>>  clock-frequency = <10>;
>>  cci-control-port = <_control0>;
>> +operating-points-v2 = <_opp_table>;
>>  };
> 
> Why do you need to update this file? This file is included by
> exynos5422-odroidxu3-common.dtsi, which already inherits cpus nodes
> from exynos5800.dtsi (which inherits exynos5420.dtsi).
> 
> i.e. operating-points-v2 should already be set.
>

The problem is that the big and LITTLE cores have different ordering per SoCs:

- Exynos5420 and Exynos5800: cpu0-3 (Cortex-A15) and cpu4-7 (Coretx-A7)
- Exynos5422: cpu0-3 (Cortex-A7) and cpu4-7 (Cortex-A15)

So the OPP tables are set in this DTSI file, to prevent the OPP tables
in the Exynos5422 to be inverted for the cluster 0 and 1.

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] drm/exynos: atomic check only enabled crtc states

[Javier Martinez Canillas]

Hello Inki,

On 11/27/2015 10:00 AM, Javier Martinez Canillas wrote:
> Hello Andrzej,
> 
> On 11/27/2015 03:57 AM, Andrzej Hajda wrote:
>> Since atomic check is called also for disabled crtcs it should skip
>> mode checking as it can be uninitialized. The patch fixes it.
>>
>> Signed-off-by: Andrzej Hajda <a.ha...@samsung.com>
>> Suggested-by: Daniel Vetter <daniel.vet...@ffwll.ch>
>> ---
>> Hi Javier,
>>
>> Could you check with this patch.
>>
> 
> The patch fixes the issue I reported. The display mode is correctly set
> with and without a HDMI monitor plugged. So on an Exynos5800 Peach Pi:
> 
> Tested-by: Javier Martinez Canillas <jav...@osg.samsung.com>
> 

This patch was never picked but fixes and important
bug introduced in the v4.4 merge window so it should
be sent during the v4.4-rc cycle.

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 0/8] cpufreq: add generic cpufreq driver support for Exynos542x/5800 platforms

[Javier Martinez Canillas]

Hello Bartlomiej,

On 12/07/2015 03:18 PM, Bartlomiej Zolnierkiewicz wrote:
> Hi,
> 
> This patch series adds generic cpufreq-dt driver support for
> Exynos542x/5800 (using the new CPU clock type which allows it).
> 
> It has been tested on Exynos5422 based ODROID-XU3 Lite board.
>

I tested on an Exynos5800 Peach Pi and all governors are working
as expected on both the Cortex-A7 and Cortex-A15 cores.

So for the whole series:

Tested-by: Javier Martinez Canillas <jav...@osg.samsung.com>

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 7/8] ARM: dts: Exynos5422: fix OPP tables

[Javier Martinez Canillas]

Hello Krzysztof,

On 12/08/2015 05:13 AM, Krzysztof Kozlowski wrote:
> On 08.12.2015 03:18, Bartlomiej Zolnierkiewicz wrote:
>> From: Ben Gamari <b...@smart-cactus.org>
>>
>> The Exynos 5422 is identical to the 5800 except for the fact that it
>> boots from the A7 cores. Consequently, the core numbering is different:
>> cores 0-3 are A7s whereas 4-7 are A15s.
>>
>> We can reuse the device tree of the 5800 for the 5422 but we must take
>> care to override the OPP tables and CPU clocks.  These are otherwise
>> inherited from the exynos5800 devicetree, which has the CPU clusters
>> reversed compared to the 5422. This results in the A15 cores only
>> reaching 1.4GHz, the maximum rate of the KFC clock.
>>
>> Cc: Javier Martinez Canillas <jav...@osg.samsung.com>
>> Signed-off-by: Ben Gamari <b...@smart-cactus.org>
>> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnier...@samsung.com>
>> ---
>>  arch/arm/boot/dts/exynos5422-cpus.dtsi | 10 ++
>>  1 file changed, 10 insertions(+)
>>
> 
> This looks like a very-non-atomic way of handling a change. You added
> opp tables to exynos5420 before so at that time they will be applied to
> Odroid XU3 family which uses different CPU order. After that you are
> fixing the tables to proper CPU order. Direct bisectability probably
> won't be an issue because all of DTS would go to separate branch... but
> the logic behind confuses.
> 

Agreed.

> I think this should be squashed into 3/8.
> 

I think the patch should be split in two changes, the CPUs device nodes
having the wrong clock for clusters is a bug and has to be fixed in a
patch before adding the OPP tables and the OPP tables changes should be
separated and merged with patch 3/8 as you suggest.

> 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 v4 7/8] ARM: dts: Exynos5422: fix OPP tables

[Javier Martinez Canillas]

Hello Krzysztof,

On 12/08/2015 09:34 PM, Krzysztof Kozlowski wrote:
> On 08.12.2015 22:41, Javier Martinez Canillas wrote:
>> On 12/08/2015 05:13 AM, Krzysztof Kozlowski wrote:
>>>
>>> This looks like a very-non-atomic way of handling a change. You added
>>> opp tables to exynos5420 before so at that time they will be applied to
>>> Odroid XU3 family which uses different CPU order. After that you are
>>> fixing the tables to proper CPU order. Direct bisectability probably
>>> won't be an issue because all of DTS would go to separate branch... but
>>> the logic behind confuses.
>>>
>>
>> Agreed.
>>
>>> I think this should be squashed into 3/8.
>>>
>>
>> I think the patch should be split in two changes, the CPUs device nodes
>> having the wrong clock for clusters is a bug and has to be fixed in a
>> patch before adding the OPP tables and the OPP tables changes should be
>> separated and merged with patch 3/8 as you suggest.
> 
> I don't get the point about wrong clock (bug). Where is the bug? Beside
> of course what was introduced in 3/8 and it is not valid for reversed
> cluster order.
>

You are absolutely correct, for some reason I thought that the CLK_ARM_CLK
and CLK_KFC_CLK clocks were already defined in the cpu0 and cpu4 nodes from
exynos5420.dtsi and commit df09df6f9ac3 ("ARM: dts: add exynos5422-cpus.dtsi
to correct cpu order") missed that when reversing the cores for Exynos5422.

But on a second look to patch 3/8, I see that the clocks are defined in that
patch so I agree that $SUBJECT should just be squashed with 3/8 without doing
any split. Sorry for the noise.

> 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] drm/exynos: decon: remove unused variables

[Javier Martinez Canillas]

Hello Inki,

On 12/07/2015 09:55 AM, Inki Dae wrote:
> This patch just removes unused variables, i and ret.
> 
> Signed-off-by: Inki Dae <inki@samsung.com>
> ---
>  drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c 
> b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> index edfd6e3..2ac1d4d 100644
> --- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> +++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> @@ -377,8 +377,6 @@ static void decon_swreset(struct decon_context *ctx)
>  static void decon_enable(struct exynos_drm_crtc *crtc)
>  {
>   struct decon_context *ctx = crtc->ctx;
> - int ret;
> - int i;
>  
>   if (!test_and_clear_bit(BIT_SUSPENDED, >flags))
>   return;
> 

Reviewed-by: Javier Martinez Canillas <jav...@osg.samsung.com>

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 4/4] ARM: dts: Use OF graph for DP to panel connection in exynos5800-peach-pi

[Javier Martinez Canillas]

Hello Inki,

On 12/07/2015 09:52 AM, Inki Dae wrote:
> From: Javier Martinez Canillas <jav...@osg.samsung.com>
>

Thanks a lot for posting this patch.
 
> The DT binding for the Exynos DRM Display Port (DP) driver isn't consistent
> since it uses a phandle to describe the connection between the DP port and
> the display panel but uses the OF graph ports and endpoints to describe the
> connection betwen the DP port, a bridge chip and the panel.
> 
> The Exynos DP driver and the DT binding have been changed to allow also to
> describe the DP port to panel connection using ports / endpoints (OF graph)
> so this patch changes the Exynos5800 Peach Pi DT to make it consistent with
> the Exynos5420 Peach Pit that has a eDP to LVDS chip and uses OF graph too.
> 
> Signed-off-by: Javier Martinez Canillas <jav...@osg.samsung.com>
> Tested-by: Javier Martinez Canillas <jav...@osg.samsung.com>

This tag was not in my original patch, it's true that I tested
it but will someone believe me? ;)

> Reviewed-by: Inki Dae <inki....@samsung.com>

Thanks for the review.

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 1/2] drm/exynos: dp: add of_graph dt binding support for panel

[Javier Martinez Canillas]

[adding Krzysztof and Kukjin to cc list]

Hello Inki,

On 12/06/2015 01:25 PM, Inki Dae wrote:
> Hi Javier,
> 
> 2015-12-03 22:05 GMT+09:00 Javier Martinez Canillas <jav...@osg.samsung.com>:
>>
>> Hello Inki,
>>
>> On 12/02/2015 11:11 PM, Inki Dae wrote:
>>> Hi Javier,
>>>
>>> 2015년 12월 03일 00:04에 Javier Martinez Canillas 이(가) 쓴 글:
>>>> Hello Inki,
>>>>
>>>> On 12/02/2015 08:57 AM, Inki Dae wrote:
>>>>> This patch adds of_graph dt binding support for panel device
>>>>> and also keeps the backward compatibility.
>>>>>
>>>>
>>>> You have to also update the DT binding doc which seems to be
>>>> outdated already:
>>>>
>>>> Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
>>>
>>> Right. It should be updated.
>>>
>>
>> Great, I see you already posted that.
>>
>>>>
>>>>> i.e.,
>>>>> The dts file for Exynos5800 based peach pi board
>>>>> has a panel property so we need to keep the backward compatibility.
>>>>>
>>>>
>>>> How did you test this patch?
>>>
>>> I thought you will test it and give me tested-by because you commented like 
>>> below,
>>> " Assuming you can make a distinction if the endpoint is a panel or a 
>>> bridge,
>>> then yes, I agree with the idea of the patch. Please feel free to cc me if
>>> you post such a patch and I'll gladly test it on my Exynos5800 Peach Pi."
>>>
>>> That is why I cced you. I really have no any Exynos5800 Peach Pi board.
>>>
>>
>> Yes, but if you didn't test a patch, then it should be marked with a RFT
>> prefix in the subject line or at least mention that needs testing since
>> you lack the HW to test. I've no way to know if you have another board
>> with a similar design :)
>>
>> But what I meant is how the patch is supposed to be tested since there
>> ins't a change in the Exynos5800 Peach Pi DTS? We can of course test
>> that doesn't break backward compatibility but we don't have a way to
>> test the actual change.
>>
>> So I tested with the patch following patch [0] and things are working
>> correctly. Please include that patch in your series.
> 
> Will pick it up. And  I commented on below your patch.
>

Ok, you need an ack from Krzysztof / Kukjin before picking the patch
though and cc them if you are planning to repost the whole series.

Another option is to wait until your Exynos DRM patches hit mainline
and then the DTS change can be posted separately.
 
>>
>> I've some comments on your patch though but I'll comment on your lastest
>> version.
>>
>>> Thanks,
>>> Inki Dae
>>>
>>>>
>>>> Best regards,
>>>>
>>
>> Best regards,
>> --
>> Javier Martinez Canillas
>> Open Source Group
>> Samsung Research America
>>
>> [0]:
>> From 644bab7949ac17a8d42ca0cf36cd55d61bc88928 Mon Sep 17 00:00:00 2001
>> From: Javier Martinez Canillas <jav...@osg.samsung.com>
>> Date: Thu, 3 Dec 2015 09:32:17 -0300
>> Subject: [PATCH 1/1] ARM: dts: Use OF graph for DP to panel connection in
>>  exynos5800-peach-pi
>>
>> The DT binding for the Exynos DRM Display Port (DP) driver isn't consistent
>> since it uses a phandle to describe the connection between the DP port and
>> the display panel but uses the OF graph ports and endpoints to describe the
>> connection betwen the DP port, a bridge chip and the panel.
>>
>> The Exynos DP driver and the DT binding have been changed to allow also to
>> describe the DP port to panel connection using ports / endpoints (OF graph)
>> so this patch changes the Exynos5800 Peach Pi DT to make it consistent with
>> the Exynos5420 Peach Pit that has a eDP to LVDS chip and uses OF graph too.
>>
>> Signed-off-by: Javier Martinez Canillas <jav...@osg.samsung.com>
>> ---
>>  arch/arm/boot/dts/exynos5800-peach-pi.dts | 15 ++-
>>  1 file changed, 14 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts 
>> b/arch/arm/boot/dts/exynos5800-peach-pi.dts
>> index 7b018e451880..9c6fd7314ee0 100644
>> --- a/arch/arm/boot/dts/exynos5800-peach-pi.dts
>> +++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts
>> @@ -122,6 +122,12 @@
>> compatible = "auo,b133htn01";
>> power-supply = <_fet6>;
>> backlight = <&

Re: [PATCH] ARM: multi_v7_defconfig: Enable fan, sensors and audio for Odroid XU3

[Javier Martinez Canillas]

Hello Krzysztof,

On 12/06/2015 09:59 PM, Krzysztof Kozlowski wrote:
> For Odroid XU3-family enable the:
>  - PWM fan (to control the CPU fan using thermal subsystem),
>  - TI INA231 sensors (provide power measurements of big.LITTLE cores,
>DRAM and GPU),
>  - Samsung sound (for Odroid XU3 and Snow as well).
> 
> Signed-off-by: Krzysztof Kozlowski <k.kozlow...@samsung.com>
> ---
>  arch/arm/configs/multi_v7_defconfig | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/configs/multi_v7_defconfig 
> b/arch/arm/configs/multi_v7_defconfig
> index f6a2557b55df..419f9413402c 100644
> --- a/arch/arm/configs/multi_v7_defconfig
> +++ b/arch/arm/configs/multi_v7_defconfig

Reviewed-by: Javier Martinez Canillas <jav...@osg.samsung.com>

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 4/4] ARM: dts: Use OF graph for DP to panel connection in exynos5800-peach-pi

[Javier Martinez Canillas]

Hello Krzysztof,

On 12/07/2015 09:48 PM, Krzysztof Kozlowski wrote:
> On 08.12.2015 00:36, Inki Dae wrote:
>> Hi Javier,
>>
>> 2015-12-07 22:41 GMT+09:00 Javier Martinez Canillas <jav...@osg.samsung.com>:
>>> Hello Inki,
>>>
>>> On 12/07/2015 09:52 AM, Inki Dae wrote:
>>>> From: Javier Martinez Canillas <jav...@osg.samsung.com>
>>>>
>>>
>>> Thanks a lot for posting this patch.
>>>
>>>> The DT binding for the Exynos DRM Display Port (DP) driver isn't consistent
>>>> since it uses a phandle to describe the connection between the DP port and
>>>> the display panel but uses the OF graph ports and endpoints to describe the
>>>> connection betwen the DP port, a bridge chip and the panel.
>>>>
>>>> The Exynos DP driver and the DT binding have been changed to allow also to
>>>> describe the DP port to panel connection using ports / endpoints (OF graph)
>>>> so this patch changes the Exynos5800 Peach Pi DT to make it consistent with
>>>> the Exynos5420 Peach Pit that has a eDP to LVDS chip and uses OF graph too.
>>>>
>>>> Signed-off-by: Javier Martinez Canillas <jav...@osg.samsung.com>
>>>> Tested-by: Javier Martinez Canillas <jav...@osg.samsung.com>
>>>
>>> This tag was not in my original patch, it's true that I tested
>>> it but will someone believe me? ;)
>>
>> Oops. I confused you spread Reviewed-by and Tested-by here and there.
>> Don't worry about that. Will remove it if you don't give me Tested-by.
>> :)
> 
> Actually authorship (the "From") in this case means Tested-by. Author
> always tests the patch so it would look weird if we start adding
> tested-by to our own patches, right?
>

Exactly, that's what I tried to say. It's implied that the
author tested her/his own patch in the best possible way.
 
> Dear Inki,
> However the patch misses your SoB. You touched and sent it so please
> extend the SoB chain-of-blame.
>

Right, I missed that.

> 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 4/4] ARM: dts: Use OF graph for DP to panel connection in exynos5800-peach-pi

[Javier Martinez Canillas]

Hello Krzysztof,

On 12/07/2015 09:45 PM, Krzysztof Kozlowski wrote:
> On 07.12.2015 21:52, Inki Dae wrote:
>> From: Javier Martinez Canillas <jav...@osg.samsung.com>
>>
>> The DT binding for the Exynos DRM Display Port (DP) driver isn't consistent
>> since it uses a phandle to describe the connection between the DP port and
>> the display panel but uses the OF graph ports and endpoints to describe the
>> connection betwen the DP port, a bridge chip and the panel.
>>
>> The Exynos DP driver and the DT binding have been changed to allow also to
>> describe the DP port to panel connection using ports / endpoints (OF graph)
>> so this patch changes the Exynos5800 Peach Pi DT to make it consistent with
>> the Exynos5420 Peach Pit that has a eDP to LVDS chip and uses OF graph too.
>>
>> Signed-off-by: Javier Martinez Canillas <jav...@osg.samsung.com>
>> Tested-by: Javier Martinez Canillas <jav...@osg.samsung.com>
>> Reviewed-by: Inki Dae <inki@samsung.com>
>> ---
>>  arch/arm/boot/dts/exynos5800-peach-pi.dts | 15 ++-
>>  1 file changed, 14 insertions(+), 1 deletion(-)
>>
> 
> Looks sensible:
> Reviewed-by: Krzysztof Kozlowski <k.kozlow...@samsung.com>
> 
> Dependencies are not mentioned, does it depend on patch 1?
>

Yes, it depends on patch 1/4 so it should be merged through the Exynos DRM
tree to maintain bisectability. Inki's patch maintains the DT ABI backward
compatibility though so another option is to wait until the DRM change hit
mainline and then pick $SUBJECT.
 
> 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 v3 1/3] drm/exynos: dp: add of_graph dt binding support for panel

[Javier Martinez Canillas]

Hello Inki,

On 12/04/2015 06:00 AM, Inki Dae wrote:
> Hi Javier,
> 
> 2015년 12월 03일 22:55에 Javier Martinez Canillas 이(가) 쓴 글:
>> Hello Inki,
>>
>> I found that v2 of this patch is alredy in your exynos-drm for-next branch so
>> so I had to revert it in linux-next to apply this one to test. You shouldn't
>> push patches that were still not reviewed (specially the ones that weren't
>> tested like this one) to your branch that gets pulled by -next. The idea of
>> -next is to have some test coverage but it should be as stable as possible.
> 
> exynos-drm/for-next branch is not really for-next branch. This branch is used

Well, it is a for-next branch because is pulled by -next. It is listed in:
http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/Next/Trees

drm-exynos  git 
git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git#exynos-drm/for-next

> only for integration test. As you know, there are many exynos maintainers
> and they have their own repository. So we would need to test the integration.

Integration testing is of course very needed and linux-next is for that but
what should be tested are the patches that are targeted to mainline.

> For this, exynos-drm/for-next is merged to linux-next not Dave's tree.
> Only exynos-drm-next branch will be merged to Dave's tree so only reviewed and
> tested patches will be merged to exynos-drm-next.
>

In that case, exynos-drm-next is what should be pulled by linux-next, no the
for-next branch. Linux-next is a simulation of what Torvalds would do next
so problems are found earlier, ideally before the patches land into mainline.

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 v3 1/3] drm/exynos: dp: add of_graph dt binding support for panel

[Javier Martinez Canillas]

Hello Inki,

On 12/04/2015 11:57 AM, Inki Dae wrote:
> Hi Javier,
> 
> 2015-12-04 21:38 GMT+09:00 Javier Martinez Canillas <jav...@osg.samsung.com>:
>> Hello Inki,
>>
>> On 12/04/2015 06:00 AM, Inki Dae wrote:
>>> Hi Javier,
>>>
>>> 2015년 12월 03일 22:55에 Javier Martinez Canillas 이(가) 쓴 글:
>>>> Hello Inki,
>>>>
>>>> I found that v2 of this patch is alredy in your exynos-drm for-next branch 
>>>> so
>>>> so I had to revert it in linux-next to apply this one to test. You 
>>>> shouldn't
>>>> push patches that were still not reviewed (specially the ones that weren't
>>>> tested like this one) to your branch that gets pulled by -next. The idea of
>>>> -next is to have some test coverage but it should be as stable as possible.
>>>
>>> exynos-drm/for-next branch is not really for-next branch. This branch is 
>>> used
>>
>> Well, it is a for-next branch because is pulled by -next. It is listed in:
>> http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/Next/Trees
>>
>> drm-exynos  git 
>> git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git#exynos-drm/for-next
>>
>>> only for integration test. As you know, there are many exynos maintainers
>>> and they have their own repository. So we would need to test the 
>>> integration.
>>
>> Integration testing is of course very needed and linux-next is for that but
>> what should be tested are the patches that are targeted to mainline.
>>
>>> For this, exynos-drm/for-next is merged to linux-next not Dave's tree.
>>> Only exynos-drm-next branch will be merged to Dave's tree so only reviewed 
>>> and
>>> tested patches will be merged to exynos-drm-next.
>>>
>>
>> In that case, exynos-drm-next is what should be pulled by linux-next, no the
>> for-next branch. Linux-next is a simulation of what Torvalds would do next
>> so problems are found earlier, ideally before the patches land into mainline.
> 
> Seems I didn't comment enough. exynos-drm/for-next branch includes all
> patches of exynos-drm-next
> and actually, they keep same patches for most time but sometimes, I
> merge additional patches only to
> exynos-drm/for-next, which should be more tested with other trees
> before going to Dave's tree.
> 

Ok, but unreviewed and more importantly untested patches should not
go to to exynos-drm/for-next because those will be made available in
linux-next and can cause issues.

Only patches that are known to be good and have been reviewed/acked
should go there.

> One more thing, there is other difference between exynos-drm-next and
> exynos-drm/for-next.
> That is all patches of exynos-drm-next are merged on top of based on
> Dave's drm-next branch.
> On the other hand, all of exynos-drm/for-next are merged on top of
> mainline. So if exynos-drm-next

It's OK if you keep a different branch because you need a different
base before sending your pull request but IMHO the patches in both
branches should always be the same.

> is merged to linux-next then all patches will be conflicted with
> Dave's tree because his branch
> is also merged to linux-next.
>
> I'm not sure that other maintainers always keep only the for-next
> branch in their repository but
> in my case, I use exynos-drm/for-next branch for the test before going
> to drm-next.
> Anyway, exynos-drm-next will go to Dave's tree and then Dave's tree
> will also be pulled by
> linux-next, which would allow exynos-drm-next to be tested altogether
> again before going to mainline.
>

This should be a common problem for subsystems with different levels
of maintainership. I'm not a subsystem maintainer so I don't know how
this should be solved but I thought that git merge would take care
of this when both trees are pulled by linux-next.

Maybe Krzysztof can comment on this since he has to do the same for
the Exynos SoC support? He maintains a for-next branch and has to
send pull request to Kukjin (and sometimes may need to rebase on top
of Kukjin's tree) but both trees are pulled by linux-next to test.

> Thanks,
> Inki Dae
> 

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 3/3] dt-bindings: exynos-dp: update ports node binding for panel

[Javier Martinez Canillas]

Hello Inki,

On 12/03/2015 06:30 AM, Inki Dae wrote:
> This patch updates a ports node binding for panel.
> 
> With this, dp node can have a ports node which describes
> a remote endpoint node that can be connected to panel or bridge
> node.
> 
> Signed-off-by: Inki Dae <inki@samsung.com>
> ---
>  .../bindings/display/exynos/exynos_dp.txt  | 28 
> ++
>  1 file changed, 24 insertions(+), 4 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt 
> b/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
> index 64693f2..15b52cb 100644
> --- a/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
> +++ b/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
> @@ -66,8 +66,15 @@ Optional properties for dp-controller:
>   Hotplug detect GPIO.
>   Indicates which GPIO should be used for hotplug
>   detection
> - -video interfaces: Device node can contain video interface port
> - nodes according to [1].
> +Video interfaces:
> +  Device node can contain video interface port nodes according to [1].
> +  The following are properties specific to those nodes:
> +
> +  endpoint node connected to bridge or panel node:
> +   - remote-endpoint: specifies the endpoint in panel or bridge node.
> +   This node is required in all kinds of exynos dp
> +   to represent the connection between dp and bridge
> +   ,or dp and panel.
>

This is nice but I think the DT binding should also document that it uses
a phandle to define the connection with the panel (but explain that is
deprecated). If only so people looking at a DTS and then going to the DT
binding can understand why there is two ways to define the same.
  
>  [1]: Documentation/devicetree/bindings/media/video-interfaces.txt
>  
> @@ -111,9 +118,22 @@ Board Specific portion:
>   };
>  
>   ports {
> - port@0 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +

These two properties are only needed when there is more than 2 ports and
a reg property is used to number the port nodes but I don't think that's
the case for Exynos DP and certainly is not the case in this example so
I think you should just remove them.

> + port {
>   dp_out: endpoint {
> - remote-endpoint = <_in>;
> + remote-endpoint = <_in>;
> + };
> + };
> + };
> +
> + panel@0 {
> + reg = <0>;
> + ...
> + port {
> + dp_in: endpoint {
> +         remote-endpoint = <_out>;
>       };
>   };
>   };
> 

The rest looks good to me so with the two changes feel free to add:

Reviewed-by: Javier Martinez Canillas <jav...@osg.samsung.com>

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] drm/exynos: dsi: modify a error type when getting a node failed

[Javier Martinez Canillas]

Hello Inki,

On 12/03/2015 02:45 AM, Inki Dae wrote:
> This patch makes it to return -EINVAL instead of -ENXIO
> when getting a port or endpoint node failed.
> 
> Signed-off-by: Inki Dae <inki@samsung.com>
> ---
>  drivers/gpu/drm/exynos/exynos_drm_dsi.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
> b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> index 7c3606a..a24bf8b 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> @@ -1735,13 +1735,13 @@ static int exynos_dsi_parse_dt(struct exynos_dsi *dsi)
>  
>   ep = of_graph_get_next_endpoint(node, NULL);
>   if (!ep) {
> - ret = -ENXIO;
> + ret = -EINVAL;
>   goto end;
>   }
>  
>   dsi->bridge_node = of_graph_get_remote_port_parent(ep);
>   if (!dsi->bridge_node) {
> - ret = -ENXIO;
> + ret = -EINVAL;
>   goto end;
>   }
>  end:
> 

Yes, I also think that -EINVAL is a better error code in this case.

Reviewed-by: Javier Martinez Canillas <jav...@osg.samsung.com>

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 1/2] drm/exynos: dp: add of_graph dt binding support for panel

[Javier Martinez Canillas]

Hello Inki,

On 12/02/2015 11:11 PM, Inki Dae wrote:
> Hi Javier,
> 
> 2015년 12월 03일 00:04에 Javier Martinez Canillas 이(가) 쓴 글:
>> Hello Inki,
>>
>> On 12/02/2015 08:57 AM, Inki Dae wrote:
>>> This patch adds of_graph dt binding support for panel device
>>> and also keeps the backward compatibility.
>>>
>>
>> You have to also update the DT binding doc which seems to be
>> outdated already:
>>
>> Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
> 
> Right. It should be updated.
>

Great, I see you already posted that.

>>
>>> i.e.,
>>> The dts file for Exynos5800 based peach pi board
>>> has a panel property so we need to keep the backward compatibility.
>>>
>>
>> How did you test this patch?
> 
> I thought you will test it and give me tested-by because you commented like 
> below,
> " Assuming you can make a distinction if the endpoint is a panel or a bridge,
> then yes, I agree with the idea of the patch. Please feel free to cc me if
> you post such a patch and I'll gladly test it on my Exynos5800 Peach Pi."
> 
> That is why I cced you. I really have no any Exynos5800 Peach Pi board.
>

Yes, but if you didn't test a patch, then it should be marked with a RFT
prefix in the subject line or at least mention that needs testing since
you lack the HW to test. I've no way to know if you have another board
with a similar design :)

But what I meant is how the patch is supposed to be tested since there
ins't a change in the Exynos5800 Peach Pi DTS? We can of course test
that doesn't break backward compatibility but we don't have a way to
test the actual change.

So I tested with the patch following patch [0] and things are working
correctly. Please include that patch in your series.

I've some comments on your patch though but I'll comment on your lastest
version.

> Thanks,
> Inki Dae
> 
>>  
>> Best regards,
>>

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America

[0]:
>From 644bab7949ac17a8d42ca0cf36cd55d61bc88928 Mon Sep 17 00:00:00 2001
From: Javier Martinez Canillas <jav...@osg.samsung.com>
Date: Thu, 3 Dec 2015 09:32:17 -0300
Subject: [PATCH 1/1] ARM: dts: Use OF graph for DP to panel connection in
 exynos5800-peach-pi

The DT binding for the Exynos DRM Display Port (DP) driver isn't consistent
since it uses a phandle to describe the connection between the DP port and
the display panel but uses the OF graph ports and endpoints to describe the
connection betwen the DP port, a bridge chip and the panel.

The Exynos DP driver and the DT binding have been changed to allow also to
describe the DP port to panel connection using ports / endpoints (OF graph)
so this patch changes the Exynos5800 Peach Pi DT to make it consistent with
the Exynos5420 Peach Pit that has a eDP to LVDS chip and uses OF graph too.

Signed-off-by: Javier Martinez Canillas <jav...@osg.samsung.com>
---
 arch/arm/boot/dts/exynos5800-peach-pi.dts | 15 ++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts 
b/arch/arm/boot/dts/exynos5800-peach-pi.dts
index 7b018e451880..9c6fd7314ee0 100644
--- a/arch/arm/boot/dts/exynos5800-peach-pi.dts
+++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts
@@ -122,6 +122,12 @@
compatible = "auo,b133htn01";
power-supply = <_fet6>;
backlight = <>;
+
+   port {
+   panel_in: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
};
 
mmc1_pwrseq: mmc1_pwrseq {
@@ -148,7 +154,14 @@
samsung,link-rate = <0x0a>;
samsung,lane-count = <2>;
samsung,hpd-gpio = < 6 GPIO_ACTIVE_HIGH>;
-   panel = <>;
+
+   ports {
+   port@0 {
+   dp_out: endpoint {
+   remote-endpoint = <_in>;
+   };
+   };
+   };
 };
 
  {
-- 
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: [PATCH v3 1/3] drm/exynos: dp: add of_graph dt binding support for panel

[Javier Martinez Canillas]

Hello Inki,

I found that v2 of this patch is alredy in your exynos-drm for-next branch so
so I had to revert it in linux-next to apply this one to test. You shouldn't
push patches that were still not reviewed (specially the ones that weren't
tested like this one) to your branch that gets pulled by -next. The idea of
-next is to have some test coverage but it should be as stable as possible.

On 12/03/2015 06:30 AM, Inki Dae wrote:
> This patch adds of_graph dt binding support for panel device
> and also keeps the backward compatibility.
> 
> i.e.,
> The dts file for Exynos5800 based peach pi board
> has a panel property so we need to keep the backward compatibility.
> 
> Changelog v3:
> - bind only one of two nodes outbound - panel or bridge.
>

This patch fixes one of the comments I had for v2 but I've another
comment below.
 
> Changelog v2:
> - return -EINVAL if getting a port node failed.
> 
> Signed-off-by: Inki Dae <inki@samsung.com>
> ---
>  drivers/gpu/drm/exynos/exynos_dp_core.c | 21 -
>  1 file changed, 20 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
> b/drivers/gpu/drm/exynos/exynos_dp_core.c
> index 94f02a0..60260a0 100644
> --- a/drivers/gpu/drm/exynos/exynos_dp_core.c
> +++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
> @@ -1392,7 +1392,7 @@ static const struct component_ops exynos_dp_ops = {
>  static int exynos_dp_probe(struct platform_device *pdev)
>  {
>   struct device *dev = >dev;
> - struct device_node *panel_node, *bridge_node, *endpoint;
> + struct device_node *panel_node = NULL, *bridge_node, *endpoint = NULL;
>   struct exynos_dp_device *dp;
>   int ret;
>  
> @@ -1403,14 +1403,32 @@ static int exynos_dp_probe(struct platform_device 
> *pdev)
>  
>   platform_set_drvdata(pdev, dp);
>  
> + /* This is for the backward compatibility. */
>   panel_node = of_parse_phandle(dev->of_node, "panel", 0);
>   if (panel_node) {
>   dp->panel = of_drm_find_panel(panel_node);
>   of_node_put(panel_node);
>   if (!dp->panel)
>   return -EPROBE_DEFER;
> + } else {
> + endpoint = of_graph_get_next_endpoint(dev->of_node, NULL);
> + if (endpoint) {
> + panel_node = of_graph_get_remote_port_parent(endpoint);

Here is asssumed that the endpoint will be a panel but it could be that there
is no "panel" phandle but the port is for a bridge chip (i.e: Peach Pit) so
this assumption seems fragile to me.

That's what I meant when I said "Assuming you can make a distinction if the
endpoint is a panel or a bridge" in the other thread.

> + if (panel_node) {
> + dp->panel = of_drm_find_panel(panel_node);
> + of_node_put(panel_node);
> + if (!dp->panel)
> + return -EPROBE_DEFER;
> + } else {
> + DRM_ERROR("no port node for panel device.\n");
> + return -EINVAL;
> + }
> + }
>   }
>  
> + if (endpoint)
> + goto out;
> +

Ok, so IIUC what's done here is to test if the panel lookup failed, then the
endpoint is looked up again but this time a call to of_drm_find_bridge() is
made instead of a call to of_drm_find_panel(). I wonder if there is a better
way to do this...

In any case then I think you should test if (panel_node) instead of endpoint.

>   endpoint = of_graph_get_next_endpoint(dev->of_node, NULL);
>   if (endpoint) {
>   bridge_node = of_graph_get_remote_port_parent(endpoint);
> @@ -1423,6 +1441,7 @@ static int exynos_dp_probe(struct platform_device *pdev)
>   return -EPROBE_DEFER;
>   }
>  
> +out:
>   pm_runtime_enable(dev);
>  
>   ret = component_add(>dev, _dp_ops);
> 

I can't think of a better way to lookup either a panel or a bridge though
and I'm not that familiar with DRM so with the correct check, the patch
looks good to me.

Reviewed-by: Javier Martinez Canillas <jav...@osg.samsung.com>

Also on an Exynos5800 Peach Pi with the DTS patch I shared, the display
is working correctly and also I tested without the DTS patch to make
sure that it does not cause a regression for older DTBs.

Tested-by: Javier Martinez Canillas <jav...@osg.samsung.com>

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 1/2] drm/exynos: dp: add of_graph dt binding support for panel

[Javier Martinez Canillas]

Hello Inki,

On 12/02/2015 08:57 AM, Inki Dae wrote:
> This patch adds of_graph dt binding support for panel device
> and also keeps the backward compatibility.
>

You have to also update the DT binding doc which seems to be
outdated already:

Documentation/devicetree/bindings/display/exynos/exynos_dp.txt

> i.e.,
> The dts file for Exynos5800 based peach pi board
> has a panel property so we need to keep the backward compatibility.
>

How did you test this 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 2/2] drm/exynos: dp: fix wrong return type

[Javier Martinez Canillas]

Hello Inki,

On 12/02/2015 08:57 AM, Inki Dae wrote:
> This patch fixes wrong return type when dt binding of bridge device
> failed.
> 
> If a board has a bridge device then of_graph_get_remote_port_parent
> function shouldn't be NULL. So this patch will return a proper error
> type so that the deferred probe isn't triggered.
> 
> Changelog v2:
> - return -EINVAL if getting a port node failed.
> 
> Signed-off-by: Inki Dae <inki....@samsung.com>
> ---

Reviewed-by: Javier Martinez Canillas <jav...@osg.samsung.com>

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] arm: dts: Fix audio card detection on peach boards

[Javier Martinez Canillas]

Hi Alim,

On 11/30/2015 01:59 PM, Alim Akhtar wrote:
> Hi Javier,
> 
> On Mon, Nov 30, 2015 at 7:31 PM, Javier Martinez Canillas
> <jav...@osg.samsung.com> wrote:
>> Hello Alim,
>>
>> On 10/12/2015 09:37 AM, Alim Akhtar wrote:
>>> Since commit 2fad972d45c4 ("ARM: dts: Add mclk entry for Peach boards"),
>>> sound card detection is broken on peach boards and gives below errors:
>>>
>>> [3.630457] max98090 7-0010: MAX98091 REVID=0x51
>>> [3.634233] max98090 7-0010: use default 2.8v micbias
>>> [3.640985] snow-audio sound: HiFi <-> 383.i2s mapping ok
>>> [3.645307] max98090 7-0010: Invalid master clock frequency
>>> [3.650824] snow-audio sound: ASoC: Peach-Pi-I2S-MAX98091 late_probe() 
>>> failed: -22
>>> [3.658914] snow-audio sound: snd_soc_register_card failed (-22)
>>> [3.664366] snow-audio: probe of sound failed with error -22
>>>
>>> This patch adds missing assigned-clocks and assigned-clock-parents for
>>> pmu_system_controller node which is used as "mclk" for audio codec.
>>>
>>> Signed-off-by: Alim Akhtar <alim.akh...@samsung.com>
>>> Fixes: 2fad972d45c4 ("ARM: dts: Add mclk entry for Peach boards")
>>
>> I found that this patch is not enough to have proper audio working
>> on an Exynos5800 Peach Pi. Even playing a simple wav does not work:
>>
>> $ time aplay -D sysdefault /usr/share/sounds/alsa/Front_Center.wav
>> Playing WAVE '/usr/share/sounds/alsa/Front_Center.wav' : Signed 16 bit 
>> Little Endian, Rate 48000 Hz, Mono
>>
>> real0m1.138s
>> user0m0.005s
>> sys 0m0.005s
>>
>> This should be ~1.5 seconds so audio is processed faster than expected.
>>
> Did you tried playing any other file, like 128 KHz rate files etc..?

Yes, I see the same problem with all the files I tested.

>> So something else besides making the CLKOUT to provide a valid frequency
>> for the codec's master clock is needed.
>>
> The $SUBJECT patch actually  fix the audio card detection issue, which
> was failing because of the missing master clock.
>

I thought the problem was not a missing master clock, but an invalid clock
frequency. Since the error message in the patch change log was:

"max98090 7-0010: Invalid master clock frequency"

But what I tried to ask was what else was missing to have playback working.

>> Do you know what's missing in mainline? For instance, I see that the
>> sound/soc/samsung/snow.c ASoC machine driver doesn't have a hw_params
>> but I'm not that familiar with ALSA to know if that makes sense or not.
>>
> I need to check this, currently I am out on a business travel, so
> won't be able to check.

No worries, I was asked in case you had more information. Audio is the
only thing that is missing to have all peripherals working correctly with
mainline.

> Probably we can go back to before "2fad972d45c4" and check that.
>

Do you mean to revert $SUBJECT and "2fad972d45c4" to see if the bootloader
sets this correctly? If I revert both patches then I have no audio at all.
 
>> Also, do you know if the "simple-audio-card" can be used instead for
>> snow and peachs as it is used for other Exynos5 boards or a specific
>> ASoC machine driver is really needed for these Chromebooks?
>>
> Not sure, AFAIR, I used machine driver on chromebooks (snow and peach).
>

Yes, the downstream 3.8 ChromiumOS tree has also a machine driver but I
don't see a simple-audio-card in that tree so it seems that predates it.

-- 
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] ARM: exynos_defconfig: Set recommended options for systemd

[Javier Martinez Canillas]

Hello Krzysztof,

On 11/30/2015 03:31 AM, Krzysztof Kozlowski wrote:
> Set following options to recommended value by systemd (which also
> matches the multi_v7 deconfig):
> 1. Enable AUTOFS4_FS - for systemd.automount [0];
> 2. Enable BLK_DEV_BSG - SG v4 for recend udev [0][1];
> 3. Disable UEVENT_HELPER_PATH - legacy hook for hotplug, forked for each
>uevent, slows down booting [0];
> 
> [0] http://cgit.freedesktop.org/systemd/systemd/tree/README
> [1] http://patchwork.ozlabs.org/patch/47921/
> 
> Signed-off-by: Krzysztof Kozlowski <k.kozlow...@samsung.com>
> ---
>  arch/arm/configs/exynos_defconfig | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 

Reviewed-by: Javier Martinez Canillas <jav...@osg.samsung.com>

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] arm: dts: Fix audio card detection on peach boards

[Javier Martinez Canillas]

Hello Alim,

On 10/12/2015 09:37 AM, Alim Akhtar wrote:
> Since commit 2fad972d45c4 ("ARM: dts: Add mclk entry for Peach boards"),
> sound card detection is broken on peach boards and gives below errors:
> 
> [3.630457] max98090 7-0010: MAX98091 REVID=0x51
> [3.634233] max98090 7-0010: use default 2.8v micbias
> [3.640985] snow-audio sound: HiFi <-> 383.i2s mapping ok
> [3.645307] max98090 7-0010: Invalid master clock frequency
> [3.650824] snow-audio sound: ASoC: Peach-Pi-I2S-MAX98091 late_probe() 
> failed: -22
> [3.658914] snow-audio sound: snd_soc_register_card failed (-22)
> [3.664366] snow-audio: probe of sound failed with error -22
> 
> This patch adds missing assigned-clocks and assigned-clock-parents for
> pmu_system_controller node which is used as "mclk" for audio codec.
> 
> Signed-off-by: Alim Akhtar <alim.akh...@samsung.com>
> Fixes: 2fad972d45c4 ("ARM: dts: Add mclk entry for Peach boards")

I found that this patch is not enough to have proper audio working
on an Exynos5800 Peach Pi. Even playing a simple wav does not work:

$ time aplay -D sysdefault /usr/share/sounds/alsa/Front_Center.wav 
Playing WAVE '/usr/share/sounds/alsa/Front_Center.wav' : Signed 16 bit Little 
Endian, Rate 48000 Hz, Mono

real0m1.138s
user0m0.005s
sys 0m0.005s

This should be ~1.5 seconds so audio is processed faster than expected.

So something else besides making the CLKOUT to provide a valid frequency
for the codec's master clock is needed.

Do you know what's missing in mainline? For instance, I see that the
sound/soc/samsung/snow.c ASoC machine driver doesn't have a hw_params
but I'm not that familiar with ALSA to know if that makes sense or not.

Also, do you know if the "simple-audio-card" can be used instead for
snow and peachs as it is used for other Exynos5 boards or a specific
ASoC machine driver is really needed for these Chromebooks?

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] drm/exynos: atomic check only enabled crtc states

[Javier Martinez Canillas]

Hello Andrzej,

On 11/27/2015 03:57 AM, Andrzej Hajda wrote:
> Since atomic check is called also for disabled crtcs it should skip
> mode checking as it can be uninitialized. The patch fixes it.
> 
> Signed-off-by: Andrzej Hajda <a.ha...@samsung.com>
> Suggested-by: Daniel Vetter <daniel.vet...@ffwll.ch>
> ---
> Hi Javier,
> 
> Could you check with this patch.
>

The patch fixes the issue I reported. The display mode is correctly set
with and without a HDMI monitor plugged. So on an Exynos5800 Peach Pi:

Tested-by: Javier Martinez Canillas <jav...@osg.samsung.com>

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] ARM: dts: exynos5422-odroid*: remove fimd node

[Javier Martinez Canillas]

Hello Andrzej,

On 11/26/2015 08:49 AM, Andrzej Hajda wrote:
> Hi Javier, Krzysztof,
> 
> On 11/26/2015 04:49 AM, Krzysztof Kozlowski wrote:
> ...
>> Do you have some test cases for MFC? I know that Gstreamer has support
>> for it but I don't know what Gst pipelines I can use to test if all is
>> working correctly.
>> Yes, I think we have. I think Jacek Anaszewski or Andrzej Hajda (both
>> Cc-ed) were developing MFC drivers and testing it.
>>
>> Jacek, Andrzej, Marek,
>>
>> Do you have test cases for Exynos MFC drivers? Is it possible to share them?
> 
> There are test apps at:
> http://git.linuxtv.org/cgit.cgi/snawrocki/samsung-utils.git/
> v4l2-mfc-example - MFC decoder,
> v4l2-mfc-encoder - MFC encoder,
>

Great, thanks a lot for the information.
 
> 
> Regards
> Andrzej
> 

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] drm/exynos: dp: fix wrong return type

[Javier Martinez Canillas]

[adding Ajay Kumar who added the bridge support]

Hello Inki,

On 11/26/2015 09:47 AM, Inki Dae wrote:
> This patch fixes wrong return type when dt binding of bridge device
> failed.
> 
> If a board has a bridge device then of_graph_get_remote_port_parent
> function shouldn't be NULL. So this patch will return a proper error
> type so that the deferred probe isn't triggered.
> 
> Signed-off-by: Inki Dae <inki@samsung.com>
> ---
>  drivers/gpu/drm/exynos/exynos_dp_core.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
> b/drivers/gpu/drm/exynos/exynos_dp_core.c
> index 0b53045..c77fb83 100644
> --- a/drivers/gpu/drm/exynos/exynos_dp_core.c
> +++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
> @@ -1436,8 +1436,10 @@ static int exynos_dp_probe(struct platform_device 
> *pdev)
>   of_node_put(bridge_node);
>   if (!dp->ptn_bridge)
>   return -EPROBE_DEFER;
> - } else
> - return -EPROBE_DEFER;
> + } else {
> + DRM_ERROR("no port node for bridge device.\n");
> + return -ENXIO;
> + }
>   }
>  

As I mentioned in the other thread, I wonder if -ENXIO is the best errno
code in this case. Shouldn't -EINVAL be more appropriate since is about
an invalid DTB?

>   pm_runtime_enable(dev);
> 

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] ARM: dts: exynos5422-odroid*: remove fimd node

[Javier Martinez Canillas]

Hello Marek,

On 11/26/2015 11:29 AM, Marek Szyprowski wrote:
> Hello,
> 
> On 2015-11-24 05:32, Javier Martinez Canillas wrote:
>> Hello Krzysztof,
>>
>> On 11/24/2015 12:50 AM, Krzysztof Kozlowski wrote:
>>> On 23.11.2015 22:56, Javier Martinez Canillas wrote:
>>>> Hello Krzysztof,
>>>>
>>>> On 11/10/2015 09:43 PM, Krzysztof Kozlowski wrote:
>>>>
>>>> [snip]
>>>>
>>>>> BTW, do you know why we don't have EXYNOS_IOMMU enabled in defconfig?
>>>>> Any reasons against?
>>>> It was explicitly disabled by commit 6562f3bd396a ("ARM: exynos_defconfig:
>>>> Disable IOMMU support") because Exynos IOMMU support was broken and caused
>>>> a BUG on boot, the discussion of the patch is [0].
>>> Right, now I remember.
>>>
>>>
>>>> But I just tested booting a v4.4-rc2 kernel on an Exynos5800 Peach Pi with
>>>> Exynos IOMMU enabled and the machine boots, display is working and
>>>> /sys/kernel/iommu_grups/*/devices shows that the devices were correctly
>>>> attached to an IOMMU group so things seems to have been sorted out now.
>>>>
>>>> So it seems that EXYNOS_IOMMU could be enabled again. It would be good to
>>>> give such a patch a spin at kernelci before posting IMHO though just to be
>>>> sure there are no issues remaining.
>>> Yes for enabling. No for testing only on kernelci. Booting is not a
>>> sufficient test in this case. I would expect testing also display - at
>> Sorry if I didn't explain myself clearly. I didn't mean that kernelci was
>> enough to test Exynos IOMMU support, what I said is that would be nice to
>> have some boot coverage besides the normal manual (or automated) display
>> testing that someone could do on available platforms as discussed over IRC.
>>
>>> least some frame buffer console on DP or HDMI (or whatever output could
>>> be generated... Xorg/Wayland would be better of course). You need it
>> Yes, as I mentioned in the previous email, I tested display (with X) on an
>> Exynos5800 Peach Pi. I don't have a rootfs with wayland/weston handy but I
>> could prepare one tomorrow to give a try.
>>
>>> because display and camera (including complementary modules like JPEG,
>>> MFC etc) are actually the only users of Exynos IOMMU in mainline.
>>>
>> Do you have some test cases for MFC? I know that Gstreamer has support
>> for it but I don't know what Gst pipelines I can use to test if all is
>> working correctly.
> 
> Please note that mainline driver for MFC doesn't work with IOMMU enabled yet.
> I plan to finish a patch for it when I find some free time.
>

Thanks a lot for the information. Then that's a reason to not enable IOMMU
by default in the defconfig until the MFC driver works correctly with that.
 
> Best regards

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] ARM: exynos_defconfig: Enable NFSv4 client

[Javier Martinez Canillas]

Hello Krzysztof,

On 11/25/2015 01:13 AM, Krzysztof Kozlowski wrote:
> NFS client is already enabled (NFS_FS) and by default it enables clients
> for version 2 and 3. Enable explicitly the version 4 client to utilize
> the newer protocol.
> 
> The NFS client is especially useful for testing kernel in automated
> environments (network boot with network file system).
> 
> Signed-off-by: Krzysztof Kozlowski <k.kozlow...@samsung.com>

Reviewed-by: Javier Martinez Canillas <jav...@osg.samsung.com>

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

[PATCH] ARM: dts: Remove unneeded GPIO include in exynos4412-odroidu3

[Javier Martinez Canillas]

The  header is already included in the
exynos4412-odroid-common DTSI so there's no need to do it again
in the DTS file.

Signed-off-by: Javier Martinez Canillas <jav...@osg.samsung.com>

---

 arch/arm/boot/dts/exynos4412-odroidu3.dts | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm/boot/dts/exynos4412-odroidu3.dts 
b/arch/arm/boot/dts/exynos4412-odroidu3.dts
index 646ff0bd001a..dd89f7b37c9f 100644
--- a/arch/arm/boot/dts/exynos4412-odroidu3.dts
+++ b/arch/arm/boot/dts/exynos4412-odroidu3.dts
@@ -13,7 +13,6 @@
 
 /dts-v1/;
 #include "exynos4412-odroid-common.dtsi"
-#include 
 
 / {
model = "Hardkernel ODROID-U3 board based on Exynos4412";
-- 
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: [PATCH 2/7] drm/exynos/mixer: replace direct cross-driver call with drm mode validation

[Javier Martinez Canillas]

Hello Andrzej,

On Mon, Oct 26, 2015 at 9:03 AM, Andrzej Hajda  wrote:
> HDMI driver called directly function from MIXER driver to invalidate modes
> not supported by MIXER. The patch replaces the hack with proper .atomic_check
> callback.
>
> Signed-off-by: Andrzej Hajda 
> ---

It seems this patch is not a drop-in replacement since it causes a
"Division by zero in kernel" error with v4.4-rc2 on an Exynos5800
Peach Pi, causing the display console to not be initialized. X works
correctly though.

An interesting data point is that it only happens when the HDMI
monitor is not plugged on the first mode set, everything works
correctly when booting with a HDMI monitor plugged.

Following is the relevant messages from the kernel log buffer:

[   14.295702] Division by zero in kernel.
[   14.298191] CPU: 0 PID: 2008 Comm: Xorg Not tainted 4.4.0-rc2 #111
[   14.304243] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[   14.310334] [] (unwind_backtrace) from []
(show_stack+0x10/0x14)
[   14.318072] [] (show_stack) from []
(dump_stack+0x84/0xc4)
[   14.325264] [] (dump_stack) from [] (Ldiv0+0x8/0x10)
[   14.331943] [] (Ldiv0) from [] (fimd_commit+0x1f0/0x2b4)
[   14.338968] [] (fimd_commit) from []
(exynos_drm_crtc_enable+0x1c/0x28)
[   14.347303] [] (exynos_drm_crtc_enable) from []
(drm_atomic_helper_commit_modeset_enables+0x98/0x198)
[   14.358227] [] (drm_atomic_helper_commit_modeset_enables)
from [] (exynos_atomic_commit_complete+0x2c/0x1c4)
[   14.369761] [] (exynos_atomic_commit_complete) from
[] (exynos_atomic_commit+0x180/0x1cc)
[   14.379681] [] (exynos_atomic_commit) from []
(drm_atomic_helper_set_config+0x6c/0x90)
[   14.389301] [] (drm_atomic_helper_set_config) from
[] (drm_mode_set_config_internal+0x58/0xd4)
[   14.399629] [] (drm_mode_set_config_internal) from
[] (drm_mode_setcrtc+0x148/0x4bc)
[   14.409078] [] (drm_mode_setcrtc) from []
(drm_ioctl+0x12c/0x49c)
[   14.416892] [] (drm_ioctl) from []
(do_vfs_ioctl+0x498/0x6c8)
[   14.424346] [] (do_vfs_ioctl) from []
(SyS_ioctl+0x34/0x5c)
[   14.431638] [] (SyS_ioctl) from []
(ret_fast_syscall+0x0/0x3c)

Best regards,
Javier
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 0/7] drm/exynos: add pm runtime support

[Javier Martinez Canillas]

Hello Inki,

On 11/23/2015 11:28 PM, Inki Dae wrote:
> Hi Javier,
> 
> 2015년 11월 24일 03:38에 Javier Martinez Canillas 이(가) 쓴 글:
>> Hello Inki,
>>
>> On 11/23/2015 01:47 PM, Inki Dae wrote:
>>> 2015-11-23 21:25 GMT+09:00 Javier Martinez Canillas 
>>> <jav...@osg.samsung.com>:
>>>> Hello,
>>>>
>>>> On 11/21/2015 11:59 AM, Inki Dae wrote:
>>>>> Hi Daniel,
>>>>>
>>>>>
>>>>> 2015-11-21 22:40 GMT+09:00 Daniel Stone <dan...@fooishbar.org>:
>>>>>> Hi Inki,
>>>>>>
>>>>>> On 21 November 2015 at 09:38, Inki Dae <daei...@gmail.com> wrote:
>>>>>>> 2015-11-21 1:44 GMT+09:00 Javier Martinez Canillas 
>>>>>>> <jav...@osg.samsung.com>:
>>>>>>>> On 11/20/2015 08:13 AM, Inki Dae wrote:
>>>>>>>>> The boot log says,
>>>>>>>>> [5.754493] vdd_ldo9: supplied by vdd_2v
>>>>>>>>> [5.765510] of_graph_get_next_endpoint(): no port node found in 
>>>>>>>>> /dp-controller@145B
>>>>>>>>>
>>>>>>>>
>>>>>>>> This message is a red herring for the reported issue, the message is 
>>>>>>>> also
>>>>>>>> present when the machine boots and the display is brought correctly.
>>>>>>>>
>>>>>>>>> Seems this error is because exynos5800-peach-pit.dts file doesn't 
>>>>>>>>> have 'ports' node in dp node.
>>>>>>>>>
>>>>>>>>> Below is dp node description of exynos5420-peach-pit.dts file.
>>>>>>>>>  {
>>>>>>>>>   status = "okay";
>>>>>>>>>   pinctrl-names = "default";
>>>>>>>>>   pinctrl-0 = <_hpd_gpio>;
>>>>>>>>>   samsung,color-space = <0>;
>>>>>>>>>   samsung,dynamic-range = <0>;
>>>>>>>>>   samsung,ycbcr-coeff = <0>;
>>>>>>>>>   samsung,color-depth = <1>;
>>>>>>>>>   samsung,link-rate = <0x06>;
>>>>>>>>>   samsung,lane-count = <2>;
>>>>>>>>>   samsung,hpd-gpio = < 6 GPIO_ACTIVE_HIGH>;
>>>>>>>>>
>>>>>>>>>   ports {
>>>>>>>>>   port@0 {
>>>>>>>>>   dp_out: endpoint {
>>>>>>>>>   remote-endpoint = <_in>;
>>>>>>>>>   };
>>>>>>>>>   };
>>>>>>>>>   };
>>>>>>>>> };
>>>>>>>>>
>>>>>>>>> And below is for exynos5800-peash-pit.dts,
>>>>>>>>>  {
>>>>>>>>>   status = "okay";
>>>>>>>>>   pinctrl-names = "default";
>>>>>>>>>   pinctrl-0 = <_hpd_gpio>;
>>>>>>>>>   samsung,color-space = <0>;
>>>>>>>>>   samsung,dynamic-range = <0>;
>>>>>>>>>   samsung,ycbcr-coeff = <0>;
>>>>>>>>>   samsung,color-depth = <1>;
>>>>>>>>>   samsung,link-rate = <0x0a>;
>>>>>>>>>   samsung,lane-count = <2>;
>>>>>>>>>   samsung,hpd-gpio = < 6 GPIO_ACTIVE_HIGH>;
>>>>>>>>>   panel = <>;
>>>>>>>>> };
>>>>>>>>>
>>>>>>>>
>>>>>>>> The difference is because the Exynos5420 Peach Pit Display Port is not
>>>>>>>> attached directly to the display panel, there is an eDP/LVDS bridge 
>>>>>>>> chip
>>>>>>>> in the middle (PS8622) while the Exynos5800 Peach Pi doesn't have that.
>>>>>>>>
>>>>>>>> The Exynos DP driver lookups for either a panel phandle or an OF graph
>>>>>>>> endpoint that points to a bridge chip and the bridge enpoint has a port
>>>>>>>> that points

Re: [PATCH v2 0/7] drm/exynos: add pm runtime support

[Javier Martinez Canillas]

Hello Inki,

On 11/23/2015 01:47 PM, Inki Dae wrote:
> 2015-11-23 21:25 GMT+09:00 Javier Martinez Canillas <jav...@osg.samsung.com>:
>> Hello,
>>
>> On 11/21/2015 11:59 AM, Inki Dae wrote:
>>> Hi Daniel,
>>>
>>>
>>> 2015-11-21 22:40 GMT+09:00 Daniel Stone <dan...@fooishbar.org>:
>>>> Hi Inki,
>>>>
>>>> On 21 November 2015 at 09:38, Inki Dae <daei...@gmail.com> wrote:
>>>>> 2015-11-21 1:44 GMT+09:00 Javier Martinez Canillas 
>>>>> <jav...@osg.samsung.com>:
>>>>>> On 11/20/2015 08:13 AM, Inki Dae wrote:
>>>>>>> The boot log says,
>>>>>>> [5.754493] vdd_ldo9: supplied by vdd_2v
>>>>>>> [5.765510] of_graph_get_next_endpoint(): no port node found in 
>>>>>>> /dp-controller@145B
>>>>>>>
>>>>>>
>>>>>> This message is a red herring for the reported issue, the message is also
>>>>>> present when the machine boots and the display is brought correctly.
>>>>>>
>>>>>>> Seems this error is because exynos5800-peach-pit.dts file doesn't have 
>>>>>>> 'ports' node in dp node.
>>>>>>>
>>>>>>> Below is dp node description of exynos5420-peach-pit.dts file.
>>>>>>>  {
>>>>>>>   status = "okay";
>>>>>>>   pinctrl-names = "default";
>>>>>>>   pinctrl-0 = <_hpd_gpio>;
>>>>>>>   samsung,color-space = <0>;
>>>>>>>   samsung,dynamic-range = <0>;
>>>>>>>   samsung,ycbcr-coeff = <0>;
>>>>>>>   samsung,color-depth = <1>;
>>>>>>>   samsung,link-rate = <0x06>;
>>>>>>>   samsung,lane-count = <2>;
>>>>>>>   samsung,hpd-gpio = < 6 GPIO_ACTIVE_HIGH>;
>>>>>>>
>>>>>>>   ports {
>>>>>>>   port@0 {
>>>>>>>   dp_out: endpoint {
>>>>>>>   remote-endpoint = <_in>;
>>>>>>>   };
>>>>>>>   };
>>>>>>>   };
>>>>>>> };
>>>>>>>
>>>>>>> And below is for exynos5800-peash-pit.dts,
>>>>>>>  {
>>>>>>>   status = "okay";
>>>>>>>   pinctrl-names = "default";
>>>>>>>   pinctrl-0 = <_hpd_gpio>;
>>>>>>>   samsung,color-space = <0>;
>>>>>>>   samsung,dynamic-range = <0>;
>>>>>>>   samsung,ycbcr-coeff = <0>;
>>>>>>>   samsung,color-depth = <1>;
>>>>>>>   samsung,link-rate = <0x0a>;
>>>>>>>   samsung,lane-count = <2>;
>>>>>>>   samsung,hpd-gpio = < 6 GPIO_ACTIVE_HIGH>;
>>>>>>>   panel = <>;
>>>>>>> };
>>>>>>>
>>>>>>
>>>>>> The difference is because the Exynos5420 Peach Pit Display Port is not
>>>>>> attached directly to the display panel, there is an eDP/LVDS bridge chip
>>>>>> in the middle (PS8622) while the Exynos5800 Peach Pi doesn't have that.
>>>>>>
>>>>>> The Exynos DP driver lookups for either a panel phandle or an OF graph
>>>>>> endpoint that points to a bridge chip and the bridge enpoint has a port
>>>>>> that points to the panel.
>>>>>>
>>>>>> So the DT is correct but of_graph_get_next_endpoint() always prints an
>>>>>
>>>>> Then, the DT is really incorrect. As you mentioned, if the Exynos5800 
>>>>> Peach PI
>>>>> board doesn't use eDP, then the dp node __should be removed__ from
>>>>> exynos5800-peach-pit.dts.
>>>>>
>>>>> From a common-sense standpoint, there is no any reason to build
>>>>> and probe dp driver if the board doesn't use dp hardware.
>>>>
>>>> I agree with what you say, but unfortunately you've slightly misread
>>>> what Javier has said. :) exynos5420-peach-pit has an LVDS panel, with
>>>> the eD

Re: [PATCH v2 0/7] drm/exynos: add pm runtime support

[Javier Martinez Canillas]

Hello,

On 11/21/2015 11:59 AM, Inki Dae wrote:
> Hi Daniel,
> 
> 
> 2015-11-21 22:40 GMT+09:00 Daniel Stone <dan...@fooishbar.org>:
>> Hi Inki,
>>
>> On 21 November 2015 at 09:38, Inki Dae <daei...@gmail.com> wrote:
>>> 2015-11-21 1:44 GMT+09:00 Javier Martinez Canillas <jav...@osg.samsung.com>:
>>>> On 11/20/2015 08:13 AM, Inki Dae wrote:
>>>>> The boot log says,
>>>>> [5.754493] vdd_ldo9: supplied by vdd_2v
>>>>> [5.765510] of_graph_get_next_endpoint(): no port node found in 
>>>>> /dp-controller@145B
>>>>>
>>>>
>>>> This message is a red herring for the reported issue, the message is also
>>>> present when the machine boots and the display is brought correctly.
>>>>
>>>>> Seems this error is because exynos5800-peach-pit.dts file doesn't have 
>>>>> 'ports' node in dp node.
>>>>>
>>>>> Below is dp node description of exynos5420-peach-pit.dts file.
>>>>>  {
>>>>>   status = "okay";
>>>>>   pinctrl-names = "default";
>>>>>   pinctrl-0 = <_hpd_gpio>;
>>>>>   samsung,color-space = <0>;
>>>>>   samsung,dynamic-range = <0>;
>>>>>   samsung,ycbcr-coeff = <0>;
>>>>>   samsung,color-depth = <1>;
>>>>>   samsung,link-rate = <0x06>;
>>>>>   samsung,lane-count = <2>;
>>>>>   samsung,hpd-gpio = < 6 GPIO_ACTIVE_HIGH>;
>>>>>
>>>>>   ports {
>>>>>   port@0 {
>>>>>   dp_out: endpoint {
>>>>>   remote-endpoint = <_in>;
>>>>>   };
>>>>>   };
>>>>>   };
>>>>> };
>>>>>
>>>>> And below is for exynos5800-peash-pit.dts,
>>>>>  {
>>>>>   status = "okay";
>>>>>   pinctrl-names = "default";
>>>>>   pinctrl-0 = <_hpd_gpio>;
>>>>>   samsung,color-space = <0>;
>>>>>   samsung,dynamic-range = <0>;
>>>>>   samsung,ycbcr-coeff = <0>;
>>>>>   samsung,color-depth = <1>;
>>>>>   samsung,link-rate = <0x0a>;
>>>>>   samsung,lane-count = <2>;
>>>>>   samsung,hpd-gpio = < 6 GPIO_ACTIVE_HIGH>;
>>>>>   panel = <>;
>>>>> };
>>>>>
>>>>
>>>> The difference is because the Exynos5420 Peach Pit Display Port is not
>>>> attached directly to the display panel, there is an eDP/LVDS bridge chip
>>>> in the middle (PS8622) while the Exynos5800 Peach Pi doesn't have that.
>>>>
>>>> The Exynos DP driver lookups for either a panel phandle or an OF graph
>>>> endpoint that points to a bridge chip and the bridge enpoint has a port
>>>> that points to the panel.
>>>>
>>>> So the DT is correct but of_graph_get_next_endpoint() always prints an
>>>
>>> Then, the DT is really incorrect. As you mentioned, if the Exynos5800 Peach 
>>> PI
>>> board doesn't use eDP, then the dp node __should be removed__ from
>>> exynos5800-peach-pit.dts.
>>>
>>> From a common-sense standpoint, there is no any reason to build
>>> and probe dp driver if the board doesn't use dp hardware.
>>
>> I agree with what you say, but unfortunately you've slightly misread
>> what Javier has said. :) exynos5420-peach-pit has an LVDS panel, with
>> the eDP -> LVDS bridge in between (ps8622). exynos5800-peach-pi (from
>> which I am writing this) has an eDP panel directly connected. The DT

Thanks a lot Daniel for clarifying my comments to Inki :)

>> describes both the eDP connector from FIMD and the eDP panel, except
>> that there is no connection between the DT nodes.

There *is* a connection between the FIMD eDP connector and the eDP panel
nodes but these are connected using a phandle while the connection for
the FIMD eDP connector and the eDP/LVDS bridge is using the OF graph DT
bindings (Documentation/devicetree/bindings/graph.txt).

And also the connection between the eDP/LVDS bridge and the LVDS panel
is using an OF graph node, so what I meant is that it would be much more
consistent if both the eDP -> panel and eDP -> eDP/LVDS br

Re: [PATCH] ARM: dts: exynos5422-odroid*: remove fimd node

[Javier Martinez Canillas]

Hello Krzysztof,

On 11/10/2015 09:43 PM, Krzysztof Kozlowski wrote:

[snip]

> 
> 
> BTW, do you know why we don't have EXYNOS_IOMMU enabled in defconfig?
> Any reasons against?
>

It was explicitly disabled by commit 6562f3bd396a ("ARM: exynos_defconfig:
Disable IOMMU support") because Exynos IOMMU support was broken and caused
a BUG on boot, the discussion of the patch is [0].

But I just tested booting a v4.4-rc2 kernel on an Exynos5800 Peach Pi with
Exynos IOMMU enabled and the machine boots, display is working and
/sys/kernel/iommu_grups/*/devices shows that the devices were correctly
attached to an IOMMU group so things seems to have been sorted out now.

So it seems that EXYNOS_IOMMU could be enabled again. It would be good to
give such a patch a spin at kernelci before posting IMHO though just to be
sure there are no issues remaining.

> Best regards,
> Krzysztof
> 
> 

[0]: https://lkml.org/lkml/2015/2/17/163

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] ARM: dts: exynos5422-odroid*: remove fimd node

[Javier Martinez Canillas]

Hello Krzysztof,

On 11/24/2015 12:50 AM, Krzysztof Kozlowski wrote:
> On 23.11.2015 22:56, Javier Martinez Canillas wrote:
>> Hello Krzysztof,
>>
>> On 11/10/2015 09:43 PM, Krzysztof Kozlowski wrote:
>>
>> [snip]
>>
>>>
>>>
>>> BTW, do you know why we don't have EXYNOS_IOMMU enabled in defconfig?
>>> Any reasons against?
>>>
>>
>> It was explicitly disabled by commit 6562f3bd396a ("ARM: exynos_defconfig:
>> Disable IOMMU support") because Exynos IOMMU support was broken and caused
>> a BUG on boot, the discussion of the patch is [0].
> 
> Right, now I remember.
> 
> 
>> But I just tested booting a v4.4-rc2 kernel on an Exynos5800 Peach Pi with
>> Exynos IOMMU enabled and the machine boots, display is working and
>> /sys/kernel/iommu_grups/*/devices shows that the devices were correctly
>> attached to an IOMMU group so things seems to have been sorted out now.
>>
>> So it seems that EXYNOS_IOMMU could be enabled again. It would be good to
>> give such a patch a spin at kernelci before posting IMHO though just to be
>> sure there are no issues remaining.
> 
> Yes for enabling. No for testing only on kernelci. Booting is not a
> sufficient test in this case. I would expect testing also display - at

Sorry if I didn't explain myself clearly. I didn't mean that kernelci was
enough to test Exynos IOMMU support, what I said is that would be nice to
have some boot coverage besides the normal manual (or automated) display
testing that someone could do on available platforms as discussed over IRC.

> least some frame buffer console on DP or HDMI (or whatever output could
> be generated... Xorg/Wayland would be better of course). You need it

Yes, as I mentioned in the previous email, I tested display (with X) on an
Exynos5800 Peach Pi. I don't have a rootfs with wayland/weston handy but I
could prepare one tomorrow to give a try.

> because display and camera (including complementary modules like JPEG,
> MFC etc) are actually the only users of Exynos IOMMU in mainline.
>

Do you have some test cases for MFC? I know that Gstreamer has support
for it but I don't know what Gst pipelines I can use to test if all is
working correctly.

> 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 v2 0/7] drm/exynos: add pm runtime support

[Javier Martinez Canillas]

Hello Inki,

On 11/20/2015 08:13 AM, Inki Dae wrote:
> 
> 
> 2015년 11월 20일 19:59에 Inki Dae 이(가) 쓴 글:
>> Hi Javier,
>>
>> 2015년 11월 20일 00:51에 Javier Martinez Canillas 이(가) 쓴 글:
>>> On 11/19/2015 11:55 AM, Javier Martinez Canillas wrote:
>>>>>>
>>>>>
>>>>> This series causes a boot failure on at least an Exynos5800 Peach Pi
>>>>> Chromebook (tested myself) and seems to be the cause of other Exynos
>>>>> boards failing to boot: http://kernelci.org/boot/?exynos
>>>>>
>>>>> [snip]
>>>>>
>>>>>>   drm/exynos: add pm_runtime to Mixer
>>>>>>   drm/exynos: add pm_runtime to FIMD
>>>>>
>>>>> I had to revert these patches in order to get the machine in a bootable
>>>>> state again, the sha1 hash for these patches in next-20151119 are:
>>>>>
>>>>> 045febd5f813 drm/exynos: add pm_runtime to FIMD
>>>
>>> On a closer look, only reverting the FIMD patch is enough
>>> to make at least the Exynos5800 Peach Pi to boot again.
>>
>> Thanks for report.
>>
>> I assume that the issue is because above patch removed 'suspended' variable
>> for checking the suspend status in runtime so I revived it.
>>
>> I'm not sure that the change could resolve the issue. Could you test it
>> with the change again? I have no Exynos5800 Peach Pi board. :(
>>
>> For this, I pushed it to below exynos-drm/for-next branch,
>>  
>> https://git.kernel.org/cgit/linux/kernel/git/daeinki/drm-exynos.git/commit/?h=exynos-drm/for-next=e84f43e2b2c3388694b0b3a58c2c4447f1fbae7c
>>
>> If the issue is resolved by the change then I will modify other patches for
>> DECON series. And if really so, there may be a corner case we missed.
> 
> Oops, I found out one error at the boot log,
> http://storage.kernelci.org/next/next-20151120/arm-multi_v7_defconfig+CONFIG_LKDTM=y/lab-collabora/boot-exynos5800-peach-pi.html
> 
> The boot log says,
> [5.754493] vdd_ldo9: supplied by vdd_2v
> [5.765510] of_graph_get_next_endpoint(): no port node found in 
> /dp-controller@145B
>

This message is a red herring for the reported issue, the message is also
present when the machine boots and the display is brought correctly.
 
> Seems this error is because exynos5800-peach-pit.dts file doesn't have 
> 'ports' node in dp node.
>
> Below is dp node description of exynos5420-peach-pit.dts file.
>  {
>   status = "okay";
>   pinctrl-names = "default";
>   pinctrl-0 = <_hpd_gpio>;
>   samsung,color-space = <0>;
>   samsung,dynamic-range = <0>;
>   samsung,ycbcr-coeff = <0>;
>   samsung,color-depth = <1>;
>   samsung,link-rate = <0x06>;
>   samsung,lane-count = <2>;
>   samsung,hpd-gpio = < 6 GPIO_ACTIVE_HIGH>;
> 
>   ports {
>   port@0 {
>   dp_out: endpoint {
>   remote-endpoint = <_in>;
>   };
>   };
>   };
> };
> 
> And below is for exynos5800-peash-pit.dts,
>  {
>   status = "okay";
>   pinctrl-names = "default";
>   pinctrl-0 = <_hpd_gpio>;
>   samsung,color-space = <0>;
>   samsung,dynamic-range = <0>;
>   samsung,ycbcr-coeff = <0>;
>   samsung,color-depth = <1>;
>   samsung,link-rate = <0x0a>;
>   samsung,lane-count = <2>;
>   samsung,hpd-gpio = < 6 GPIO_ACTIVE_HIGH>;
>   panel = <>;
> };
> 

The difference is because the Exynos5420 Peach Pit Display Port is not
attached directly to the display panel, there is an eDP/LVDS bridge chip
in the middle (PS8622) while the Exynos5800 Peach Pi doesn't have that.

The Exynos DP driver lookups for either a panel phandle or an OF graph
endpoint that points to a bridge chip and the bridge enpoint has a port
that points to the panel.

So the DT is correct but of_graph_get_next_endpoint() always prints an
error if the port so OF graph endpoints it seems can't be optional as
used in this driver. Maybe that message should be change to debug then?

Another option is to extend the DP driver DT binding to be more generic
supporting having a port to a panel besides a bridge, so we could have
something like this for Exynos5800 Peach and be consistent in both cases:

diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts 
b/arch/arm/boot/dts/exynos5800-peach-pi.dts
index 7b018e451880..9c6fd7314ee0 100644
--- a/arch/arm/boot/dts/exynos5800-peach-pi.dts
+++ b/arch/arm/boot/dts/exyn

Re: [PATCH v2 0/7] drm/exynos: add pm runtime support

[Javier Martinez Canillas]

Hello Inki,

On 11/20/2015 07:59 AM, Inki Dae wrote:
> Hi Javier,
> 
> 2015년 11월 20일 00:51에 Javier Martinez Canillas 이(가) 쓴 글:
>> On 11/19/2015 11:55 AM, Javier Martinez Canillas wrote:
>>>>>
>>>>
>>>> This series causes a boot failure on at least an Exynos5800 Peach Pi
>>>> Chromebook (tested myself) and seems to be the cause of other Exynos
>>>> boards failing to boot: http://kernelci.org/boot/?exynos
>>>>
>>>> [snip]
>>>>
>>>>>   drm/exynos: add pm_runtime to Mixer
>>>>>   drm/exynos: add pm_runtime to FIMD
>>>>
>>>> I had to revert these patches in order to get the machine in a bootable
>>>> state again, the sha1 hash for these patches in next-20151119 are:
>>>>
>>>> 045febd5f813 drm/exynos: add pm_runtime to FIMD
>>
>> On a closer look, only reverting the FIMD patch is enough
>> to make at least the Exynos5800 Peach Pi to boot again.
> 
> Thanks for report.
>

Thanks to you for the quick answer and providing a fix.
 
> I assume that the issue is because above patch removed 'suspended' variable
> for checking the suspend status in runtime so I revived it.
>

It seems your assumption was correct...
 
> I'm not sure that the change could resolve the issue. Could you test it
> with the change again? I have no Exynos5800 Peach Pi board. :(
> 
> For this, I pushed it to below exynos-drm/for-next branch,
>   
> https://git.kernel.org/cgit/linux/kernel/git/daeinki/drm-exynos.git/commit/?h=exynos-drm/for-next=e84f43e2b2c3388694b0b3a58c2c4447f1fbae7c
> 
> If the issue is resolved by the change then I will modify other patches for
> DECON series. And if really so, there may be a corner case we missed.
>

... since I reverted the offending commit and cherry-picked the one
in your for-next branch and the machine booted again.
 
> Thanks,
> Inki Dae
> 

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

[Javier Martinez Canillas]

Hello Alim,

On Thu, Nov 19, 2015 at 3:06 PM, Alim Akhtar  wrote:

[snip]

>>
>> 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.
>>
>
> Is It the right time to get this series in?

The patch that the series had as a dependency made it to v4.4-rc1 as
commit 1c6e58d83615 ("mmc: pwrseq: Use highest priority for eMMC
restart handler") so it should be safe now to pick this series for
v4.5.

> Thanks!!
>

Best regards,
Javier
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 0/7] drm/exynos: add pm runtime support

[Javier Martinez Canillas]

On 11/19/2015 11:55 AM, Javier Martinez Canillas wrote:
>>>
>>
>> This series causes a boot failure on at least an Exynos5800 Peach Pi
>> Chromebook (tested myself) and seems to be the cause of other Exynos
>> boards failing to boot: http://kernelci.org/boot/?exynos
>>
>> [snip]
>>
>>>   drm/exynos: add pm_runtime to Mixer
>>>   drm/exynos: add pm_runtime to FIMD
>>
>> I had to revert these patches in order to get the machine in a bootable
>> state again, the sha1 hash for these patches in next-20151119 are:
>>
>> 045febd5f813 drm/exynos: add pm_runtime to FIMD

On a closer look, only reverting the FIMD patch is enough
to make at least the Exynos5800 Peach Pi to boot again.

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/7] drm/exynos: add pm runtime support

[Javier Martinez Canillas]

[adding Kevin and Tyler to cc list]

Hello Inki and Gustavo,

On 11/03/2015 07:47 AM, Inki Dae wrote:
> This patch series adds pm runtime support for Exynos drm.
> 
> Originally, this patch was posted by Gustavo but there was no any
> answer about some comments. So I rebased this patch series on top of
> exynos-drm-next, removed unnecessary patches and modified wrong macro.
> 
> Changelog v2:
> - Remove patch 5 and 6.
>   . commit callback are already removed so isn't required anymore.
> - Remove patch 8 which makes dp clock enabled directly from FIMD.
>   . Really not mendatory for FIMD uses DP, and it could be different
> according to Board.
> - Modified CONFIG_PM_SLEEP to CONFIG_PM.
>   . In case of runtime pm, CONFIG_PM macro should be used instead of
> CONFIG_PM_SLEEP.
>

This series causes a boot failure on at least an Exynos5800 Peach Pi
Chromebook (tested myself) and seems to be the cause of other Exynos
boards failing to boot: http://kernelci.org/boot/?exynos

[snip]

>   drm/exynos: add pm_runtime to Mixer
>   drm/exynos: add pm_runtime to FIMD

I had to revert these patches in order to get the machine in a bootable
state again, the sha1 hash for these patches in next-20151119 are:

045febd5f813 drm/exynos: add pm_runtime to FIMD
dd766fb8479b drm/exynos: add pm_runtime to Mixer

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/7] drm/exynos: add pm runtime support

[Javier Martinez Canillas]

On 11/19/2015 11:51 AM, Javier Martinez Canillas wrote:
> [adding Kevin and Tyler to cc list]
>
> Hello Inki and Gustavo,

I didn't notice before that Gustavo was not cc'ed in the
original email from Inki so I'm adding him as well.

Sorry to others for the noise.

> 
> On 11/03/2015 07:47 AM, Inki Dae wrote:
>> This patch series adds pm runtime support for Exynos drm.
>>
>> Originally, this patch was posted by Gustavo but there was no any
>> answer about some comments. So I rebased this patch series on top of
>> exynos-drm-next, removed unnecessary patches and modified wrong macro.
>>
>> Changelog v2:
>> - Remove patch 5 and 6.
>>   . commit callback are already removed so isn't required anymore.
>> - Remove patch 8 which makes dp clock enabled directly from FIMD.
>>   . Really not mendatory for FIMD uses DP, and it could be different
>> according to Board.
>> - Modified CONFIG_PM_SLEEP to CONFIG_PM.
>>   . In case of runtime pm, CONFIG_PM macro should be used instead of
>> CONFIG_PM_SLEEP.
>>
> 
> This series causes a boot failure on at least an Exynos5800 Peach Pi
> Chromebook (tested myself) and seems to be the cause of other Exynos
> boards failing to boot: http://kernelci.org/boot/?exynos
> 
> [snip]
> 
>>   drm/exynos: add pm_runtime to Mixer
>>   drm/exynos: add pm_runtime to FIMD
> 
> I had to revert these patches in order to get the machine in a bootable
> state again, the sha1 hash for these patches in next-20151119 are:
> 
> 045febd5f813 drm/exynos: add pm_runtime to FIMD
> dd766fb8479b drm/exynos: add pm_runtime to Mixer
> 
> Best regards,
> 

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

[RESEND PATCH v2 5/6] ARM: dts: Remove broken-cd from eMMC node in exynos5420-peach-pi

[Javier Martinez Canillas]

The eMMC is non-removable so is marked with the non-removable DT
property to avoid having to redetect it after a suspend/resume.

But it also has the broken-cd property which is wrong since only
one of the DT properties for card detection should be used.

Also remove the card-detect-delay property that is not needed with
non-removable.

Signed-off-by: Javier Martinez Canillas <jav...@osg.samsung.com>
Reviewed-by: Krzysztof Kozlowski <k.kozlow...@samsung.com>
Reviewed-by: Alim Akhtar <alim.akh...@samsung.com>
Tested-by: Alim Akhtar <alim.akh...@samsung.com>
---

 arch/arm/boot/dts/exynos5420-peach-pit.dts | 2 --
 1 file changed, 2 deletions(-)

diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts 
b/arch/arm/boot/dts/exynos5420-peach-pit.dts
index 02e99dbafcfb..35cfb07dc4bb 100644
--- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
+++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
@@ -690,11 +690,9 @@
 _0 {
status = "okay";
num-slots = <1>;
-   broken-cd;
mmc-hs200-1_8v;
cap-mmc-highspeed;
non-removable;
-   card-detect-delay = <200>;
clock-frequency = <4>;
samsung,dw-mshc-ciu-div = <3>;
samsung,dw-mshc-sdr-timing = <0 4>;
-- 
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

[RESEND PATCH v2 6/6] ARM: dts: Mark eMMC as non-removable in exynos5250-snow-common

[Javier Martinez Canillas]

The eMMC is non-removable so mark it using the non-removable DT
property to avoid having to redetect it after a suspend/resume.

Also remove the card-detect-delay property that is not needed with
non-removable.

Signed-off-by: Javier Martinez Canillas <jav...@osg.samsung.com>
Reviewed-by: Tomeu Vizoso <tomeu.viz...@collabora.com>
Tested-by: Tomeu Vizoso <tomeu.viz...@collabora.com>
Reviewed-by: Krzysztof Kozlowski <k.kozlow...@samsung.com>
Reviewed-by: Alim Akhtar <alim.akh...@samsung.com>

Series-cc Alim Akhtar <alim.akh...@samsung.com>
---

 arch/arm/boot/dts/exynos5250-snow-common.dtsi | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/exynos5250-snow-common.dtsi 
b/arch/arm/boot/dts/exynos5250-snow-common.dtsi
index 1822c502a25a..5cb33ba5e296 100644
--- a/arch/arm/boot/dts/exynos5250-snow-common.dtsi
+++ b/arch/arm/boot/dts/exynos5250-snow-common.dtsi
@@ -520,8 +520,7 @@
 _0 {
status = "okay";
num-slots = <1>;
-   broken-cd;
-   card-detect-delay = <200>;
+   non-removable;
samsung,dw-mshc-ciu-div = <3>;
samsung,dw-mshc-sdr-timing = <2 3>;
samsung,dw-mshc-ddr-timing = <1 2>;
-- 
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

[RESEND PATCH v2 3/6] ARM: dts: Mark SDIO as non-removable in exynos5250-snow-common

[Javier Martinez Canillas]

The Exynos5250 Snow Chromebooks have a Marvell WiFi SDIO chip which
can't neither be removed nor be detected. But the node isn't marked
as non-removable and instead has the broken-cd DT property.

This causes the device to be removed when the system enters into a
suspend state and the following warnings is shown after a resume:

[  181.944636] mmc2: error -2 during resume (card was removed?)

Also remove the card-detect-delay property that is not needed with
non-removable.

Signed-off-by: Javier Martinez Canillas <jav...@osg.samsung.com>
Reviewed-by: Tomeu Vizoso <tomeu.viz...@collabora.com>
Tested-by: Tomeu Vizoso <tomeu.viz...@collabora.com>
Reviewed-by: Krzysztof Kozlowski <k.kozlow...@samsung.com>
Reviewed-by: Alim Akhtar <alim.akh...@samsung.com>
---

 arch/arm/boot/dts/exynos5250-snow-common.dtsi | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/exynos5250-snow-common.dtsi 
b/arch/arm/boot/dts/exynos5250-snow-common.dtsi
index 0a7f408824d8..1822c502a25a 100644
--- a/arch/arm/boot/dts/exynos5250-snow-common.dtsi
+++ b/arch/arm/boot/dts/exynos5250-snow-common.dtsi
@@ -552,10 +552,9 @@
 _3 {
status = "okay";
num-slots = <1>;
-   broken-cd;
+   non-removable;
cap-sdio-irq;
keep-power-in-suspend;
-   card-detect-delay = <200>;
samsung,dw-mshc-ciu-div = <3>;
samsung,dw-mshc-sdr-timing = <2 3>;
samsung,dw-mshc-ddr-timing = <1 2>;
-- 
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

[RESEND PATCH v2 0/6] ARM: dts: Use correct CD properties for SDIO and eMMC in Snow and Peach

[Javier Martinez Canillas]

Hello Krzysztof and Kukjin,

This is a resend of a series posted a month ago [0] that use the correct
card detection properties in the DTS for Exynos Chromebooks but that was
never picked.

The patches have no changed, the only difference is that I'm including
all the Reviewed-by and Tested-by tags that were previously collected.

[0]: https://lkml.org/lkml/2015/10/15/640

Best regards,
Javier


Javier Martinez Canillas (6):
  ARM: dts: Mark SDIO as non-removable in exynos5800-peach-pi
  ARM: dts: Mark SDIO as non-removable in exynos5420-peach-pit
  ARM: dts: Mark SDIO as non-removable in exynos5250-snow-common
  ARM: dts: Remove broken-cd from eMMC node in exynos5800-peach-pi
  ARM: dts: Remove broken-cd from eMMC node in exynos5420-peach-pi
  ARM: dts: Mark eMMC as non-removable in exynos5250-snow-common

 arch/arm/boot/dts/exynos5250-snow-common.dtsi | 6 ++
 arch/arm/boot/dts/exynos5420-peach-pit.dts| 5 +
 arch/arm/boot/dts/exynos5800-peach-pi.dts | 5 +
 3 files changed, 4 insertions(+), 12 deletions(-)

-- 
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

[RESEND PATCH v2 1/6] ARM: dts: Mark SDIO as non-removable in exynos5800-peach-pi

[Javier Martinez Canillas]

The Exynos5800 Peach Pi Chromebook has a Marvell WiFi SDIO chip which
can't neither be removed nor be detected. But the node isn't marked
as non-removable and instead has the broken-cd DT property.

This causes the device to be removed when the system enters into a
suspend state and the following warnings is shown after a resume:

[  181.944636] mmc2: error -2 during resume (card was removed?)

Also remove the card-detect-delay property that is not needed with
non-removable.

Signed-off-by: Javier Martinez Canillas <jav...@osg.samsung.com>
Reviewed-by: Krzysztof Kozlowski <k.kozlow...@samsung.com>
Reviewed-by: Alim Akhtar <alim.akh...@samsung.com>
---

 arch/arm/boot/dts/exynos5800-peach-pi.dts | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts 
b/arch/arm/boot/dts/exynos5800-peach-pi.dts
index 49a4f43e5ac2..ca3a467a585d 100644
--- a/arch/arm/boot/dts/exynos5800-peach-pi.dts
+++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts
@@ -672,10 +672,9 @@
 _1 {
status = "okay";
num-slots = <1>;
-   broken-cd;
+   non-removable;
cap-sdio-irq;
keep-power-in-suspend;
-   card-detect-delay = <200>;
clock-frequency = <4>;
samsung,dw-mshc-ciu-div = <1>;
samsung,dw-mshc-sdr-timing = <0 1>;
-- 
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

[RESEND PATCH v2 4/6] ARM: dts: Remove broken-cd from eMMC node in exynos5800-peach-pi

[Javier Martinez Canillas]

The eMMC is non-removable so is marked with the non-removable DT
property to avoid having to redetect it after a suspend/resume.

But it also has the broken-cd property which is wrong since only
one of the DT properties for card detection should be used.

Also remove the card-detect-delay property that is not needed with
non-removable.

Signed-off-by: Javier Martinez Canillas <jav...@osg.samsung.com>
Reviewed-by: Krzysztof Kozlowski <k.kozlow...@samsung.com>
Reviewed-by: Alim Akhtar <alim.akh...@samsung.com>
Tested-by: Alim Akhtar <alim.akh...@samsung.com>
---

 arch/arm/boot/dts/exynos5800-peach-pi.dts | 2 --
 1 file changed, 2 deletions(-)

diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts 
b/arch/arm/boot/dts/exynos5800-peach-pi.dts
index ca3a467a585d..7b018e451880 100644
--- a/arch/arm/boot/dts/exynos5800-peach-pi.dts
+++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts
@@ -652,12 +652,10 @@
 _0 {
status = "okay";
num-slots = <1>;
-   broken-cd;
mmc-hs200-1_8v;
mmc-hs400-1_8v;
cap-mmc-highspeed;
non-removable;
-   card-detect-delay = <200>;
clock-frequency = <8>;
samsung,dw-mshc-ciu-div = <3>;
samsung,dw-mshc-sdr-timing = <0 4>;
-- 
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

[RESEND PATCH v2 2/6] ARM: dts: Mark SDIO as non-removable in exynos5420-peach-pit

[Javier Martinez Canillas]

The Exynos5420 Peach Pit Chromebook has a Marvell WiFi SDIO chip which
can't neither be removed nor be detected. But the node isn't marked
as non-removable and instead has the broken-cd DT property.

This causes the device to be removed when the system enters into a
suspend state and the following warnings is shown after a resume:

[  181.944636] mmc2: error -2 during resume (card was removed?)

Also remove the card-detect-delay property that is not needed with
non-removable.

Signed-off-by: Javier Martinez Canillas <jav...@osg.samsung.com>
Reviewed-by: Krzysztof Kozlowski <k.kozlow...@samsung.com>
Reviewed-by: Alim Akhtar <alim.akh...@samsung.com>
---

 arch/arm/boot/dts/exynos5420-peach-pit.dts | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts 
b/arch/arm/boot/dts/exynos5420-peach-pit.dts
index 72ba6f032ed7..02e99dbafcfb 100644
--- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
+++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
@@ -709,10 +709,9 @@
 _1 {
status = "okay";
num-slots = <1>;
-   broken-cd;
+   non-removable;
cap-sdio-irq;
keep-power-in-suspend;
-   card-detect-delay = <200>;
clock-frequency = <4>;
samsung,dw-mshc-ciu-div = <1>;
samsung,dw-mshc-sdr-timing = <0 1>;
-- 
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: [RESEND PATCH v2 6/6] ARM: dts: Mark eMMC as non-removable in exynos5250-snow-common

[Javier Martinez Canillas]

Hello,

On 11/18/2015 10:23 AM, Javier Martinez Canillas wrote:
> The eMMC is non-removable so mark it using the non-removable DT
> property to avoid having to redetect it after a suspend/resume.
> 
> Also remove the card-detect-delay property that is not needed with
> non-removable.
> 
> Signed-off-by: Javier Martinez Canillas <jav...@osg.samsung.com>
> Reviewed-by: Tomeu Vizoso <tomeu.viz...@collabora.com>
> Tested-by: Tomeu Vizoso <tomeu.viz...@collabora.com>
> Reviewed-by: Krzysztof Kozlowski <k.kozlow...@samsung.com>
> Reviewed-by: Alim Akhtar <alim.akh...@samsung.com>
> 
> Series-cc Alim Akhtar <alim.akh...@samsung.com>

Argh, sorry about this, it was a silly typo error where I forgot ':' so
patman didn't process the tag...

I guess it can be removed when applying to avoid resending the whole series.

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

[PATCH] ARM: multi_v7_defconfig: Build ChromeOS EC drivers as modules

[Javier Martinez Canillas]

Since the multi_v7_defconfig is used to build an image for different
platforms, the options should be enabled as module whenever possible.

Signed-off-by: Javier Martinez Canillas <jav...@osg.samsung.com>

---
The patch was tested on an Exynos5800 Peach Pi Chromebook
and the drivers' modules were correctly autoloaded.

 arch/arm/configs/multi_v7_defconfig | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/configs/multi_v7_defconfig 
b/arch/arm/configs/multi_v7_defconfig
index 69a22fdb52a5..a38a1b0f2657 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -241,7 +241,7 @@ CONFIG_KEYBOARD_GPIO=y
 CONFIG_KEYBOARD_TEGRA=y
 CONFIG_KEYBOARD_SPEAR=y
 CONFIG_KEYBOARD_ST_KEYSCAN=y
-CONFIG_KEYBOARD_CROS_EC=y
+CONFIG_KEYBOARD_CROS_EC=m
 CONFIG_MOUSE_PS2_ELANTECH=y
 CONFIG_MOUSE_CYAPA=m
 CONFIG_MOUSE_ELAN_I2C=y
@@ -397,9 +397,9 @@ CONFIG_MFD_AS3722=y
 CONFIG_MFD_ATMEL_FLEXCOM=y
 CONFIG_MFD_BCM590XX=y
 CONFIG_MFD_AXP20X=y
-CONFIG_MFD_CROS_EC=y
+CONFIG_MFD_CROS_EC=m
 CONFIG_MFD_CROS_EC_I2C=m
-CONFIG_MFD_CROS_EC_SPI=y
+CONFIG_MFD_CROS_EC_SPI=m
 CONFIG_MFD_MAX14577=y
 CONFIG_MFD_MAX77686=y
 CONFIG_MFD_MAX77693=y
-- 
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: [PATCH v2 0/6] ARM: dts: Use correct CD properties for SDIO and eMMC in Snow and Peach

[Javier Martinez Canillas]

Hello Kukjin,

On 10/19/2015 12:04 AM, Alim Akhtar wrote:
> Hi Javier,
> 
> On 10/15/2015 10:21 PM, Javier Martinez Canillas wrote:
>> Hello,
>>
>> The Exynos Chromebooks DTS don't use the correct card detection properties
>> since these were carried from the vendor tree that had a reason to do so.
>>
>> There are two things that I noticed:
>>
>> 1) The Marvell WiFi SDIO is marked as broken-cd instead of non-removable:
>>
>> This causes the device to be removed when the system enters into a suspend
>> state which leads to the following warning when the system is resumed:
>>
>> [  181.944636] mmc2: error -2 during resume (card was removed?)
>>
>> The rationale for using broken-cd is explained in downstream commit [0] and
>> was that using the non-removable property caused issues with the mwifiex
>> driver since the reset logic called the mmc_{remove,add}_host() functions.
>>
>> But the reset logic in the mwifiex mainline driver has changed and this is
>> no longer the case so it's safe to use the non-removable property AFAICT.
>>
>> 2) The eMMC node has both broken-cd and non-removable but the MMC DT binding
>> doc (Documentation/devicetree/bindings/mmc/mmc.txt) mentions that only one
>> of these card detection properties should be used.
>>
>> So this series change both the SDIO WiFi and eMMC device nodes in the Snow,
>> Peach Pi and Peach Pit boards DTS to use the non-removable property.
>>
>> To test, I've cherry picked commit [1] from the vendor tree that adds a
>> debugfs entry to force a card reset and after the reset, the WiFi card still
>> works correctly:
>>
>> $ echo 1 > /sys/kernel/debug/mwifiex/mlan0/reset
>>
>> And also tested that both eMMC and WiFi are working correctly after a S2R.
>>
>> The test were made on an Exynos5800 Peach Pi but I don't have access to a
>> Snow anymore so testing patch 3/6 and 6/6 on that board will be appreciated.
>>
>> v1 of the series was [2] and this version fixes issues pointed out by Tomeu.
>>
>> Changes since v1:
>>   - Replace broken-cd for non-removable in the correct mmc node for Snow.
>>   - Correct the card detetion properties for eMMC in Snow, Pit and Pi.
>>   - Also remove the card-detect-delay property when using non-removable.
>>
>> [0]: 
>> https://chromium.googlesource.com/chromiumos/third_party/kernel/+/ad348e1e2381
>> [1]: 
>> https://chromium.googlesource.com/chromiumos/third_party/kernel/+/5995363523de
>> [2]: https://lkml.org/lkml/2015/10/15/294
>>
>> Best regards,
>> Javier
>>
>>
>> Javier Martinez Canillas (6):
>>ARM: dts: Mark SDIO as non-removable in exynos5800-peach-pi
>>ARM: dts: Mark SDIO as non-removable in exynos5420-peach-pit
>>ARM: dts: Mark SDIO as non-removable in exynos5250-snow-common
>>ARM: dts: Remove broken-cd from eMMC node in exynos5800-peach-pi
>>ARM: dts: Remove broken-cd from eMMC node in exynos5420-peach-pi
>>ARM: dts: Mark eMMC as non-removable in exynos5250-snow-common
>>
> This series looks good to me, so feel free to add
> Reviewed-by: Alim Akhtar <alim.akh...@samsung.com>
> and for patch 4 and 5: Tested-by: Alim Akhtar <alim.akh...@samsung.com>
> Thanks.
>

You said that you are going to take this series once Alim tested / gave
his feedback but that happened weeks ago and I still don't see these in
your 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 2/2] arm64: dts: exynos7: Enable HS200 mode operation

[Javier Martinez Canillas]

Hello Alim,

On 11/02/2015 11:04 AM, Alim Akhtar wrote:
> This patch enables HS200 mode operation on exynos7 based
> espresso board.
> This also remove _broken-cd_ property as per mmc binding documentation
> which say one of the properties between broken-cd and non-removable
> should be used. And we already use _non-removable_ as emmc mounted
> on board which is a non-removable device.
> 
> Signed-off-by: Alim Akhtar <alim.akh...@samsung.com>
> ---
>  arch/arm64/boot/dts/exynos/exynos7-espresso.dts |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/boot/dts/exynos/exynos7-espresso.dts 
> b/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
> index 8ce04a0ec928..7f19b99fc85b 100644
> --- a/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
> +++ b/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
> @@ -405,8 +405,8 @@
>  _0 {
>   status = "okay";
>   num-slots = <1>;
> - broken-cd;
>   cap-mmc-highspeed;
> + mmc-hs200-1_8v;
>   non-removable;
>   card-detect-delay = <200>;
>   clock-frequency = <80000>;
> 

Reviewed-by: Javier Martinez Canillas <jav...@osg.samsung.com>

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] arm64: dts: exynos7: Add pmic s2mps15 device tree node

[Javier Martinez Canillas]

Hello Alim,

This patch looks mostly good to me, I just have two comments below:

On 11/02/2015 11:04 AM, Alim Akhtar wrote:
> This patch add pmic (s2mps15) node of espresso board,
> which includes addition of regulators and pmic-clk sub-nodes.
> 
> Signed-off-by: Abhilash Kesavan <a.kesa...@samsung.com>
> Signed-off-by: Alim Akhtar <alim.akh...@samsung.com>
> ---
> This patch should go in after driver side changes [1] lands.
> [1]-> 
> https://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg47736.html
> 
>  arch/arm64/boot/dts/exynos/exynos7-espresso.dts |  349 
> +++
>  1 file changed, 349 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/exynos/exynos7-espresso.dts 
> b/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
> index 838a3626dac1..8ce04a0ec928 100644
> --- a/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
> +++ b/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
> @@ -53,6 +53,355 @@
>   status = "okay";
>  };
>  
> +_4 {
> + samsung,i2c-sda-delay = <100>;
> + samsung,i2c-max-bus-freq = <20>;
> + status = "okay";
> +
> + s2mps15_pmic@66 {
> + compatible = "samsung,s2mps15-pmic";
> + reg = <0x66>;
> + interrupts = <2 0>;

Maybe using IRQ_TYPE_NONE instead of 0?

> + interrupt-parent = <>;
> + pinctrl-names = "default";
> + pinctrl-0 = <_irq>;
> + wakeup-source;
> +
> + s2mps15_osc: clocks {
> + compatible = "samsung,s2mps13-clk";
> + #clock-cells = <1>;
> + clock-output-names = "s2mps13_ap", "s2mps13_cp",
> + "s2mps13_bt";
> + };
> +
> + regulators {
> + ldo1_reg: LDO1 {
> + regulator-name = "vdd_ldo1";
> + regulator-min-microvolt = <50>;
> + regulator-max-microvolt = <90>;
> + regulator-always-on;

I see that all regulators are marked as regulator-always-on but that will
prevent the regulator subsystem to disable unused regulators. Can you please
double check which regulators should really be always on and which ones can
be disabled if are not used?

After those two changes:

Reviewed-by: Javier Martinez Canillas <jav...@osg.samsung.com>

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] mmc: pwrseq: Use highest priority for eMMC restart handler

[Javier Martinez Canillas]

Hello Ulf,

On 10/27/2015 11:10 AM, Ulf Hansson wrote:
> On 21 October 2015 at 17:15, Javier Martinez Canillas
> <jav...@osg.samsung.com> 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 <jav...@osg.samsung.com>
>> Tested-by: Markus Reichl <m.rei...@fivetechno.de>
>> Tested-by: Anand Moon <linux.am...@gmail.com>
>> Reviewed-by: Alim Akhtar <alim.akh...@samsung.com>
>>
>> ---
>> 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
> 
> So it seems like there have been a good discussion around this. I
> don't have any objections, but is more concerned about potential
> regressions.
>

Yes, there was a lot of discussion indeed but it seems we all agree
on the approach and that the patch should not land before having a
lot of testing.
 
> I have queued it up for next (4.4) so we get some testing in
> linux-next. If anyone have issues, please report them.
>

great, some weeks sitting in -next to let the CI infrastructure to
play with it seems reasonable to me. Thanks a lot!
 
> Kind regards
> Uffe
>

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] mmc: pwrseq: Use highest priority for eMMC restart handler

[Javier Martinez Canillas]

Hello Doug,

On 10/22/2015 07:33 PM, Doug Anderson wrote:
> On Thu, Oct 22, 2015 at 9:07 AM, Javier Martinez Canillas

[snip]

>>
>> Do you know why the priority 200 was chosen for veyron gpi-restart ooi?
> 
> In David Riley's original patch the example had 200:
> https://patchwork.kernel.org/patch/4784611/
> 
> In the ChromeOS 3.14 kernel tree I believe we're still using the old
> patch (we still have /bits/ 8).  ...it looks like I'm the one who
> originally added it to the veyron dts file and I set it to 200, so I'd
> presume that I just copied the example and called it "good enough".
>

I see, thanks for the explanation. I asked because I noticed that the
gpio-restart handler default priority was 129 and I didn't find other
restart handler used for this board with a prio > 129 so at least in
mainline, the priority 200 should not be necessary.

But now I see that it was indeed 128 but was bumped to 129 in commit:

bcd56fe1aa97 ("power: reset: gpio-restart: increase priority slightly")

which explains why the priority 200 was in the veyron DTS even when is
not needed anymore after that commit.
 
> I'm sure the upstream dts just used the number from the ChromeOS 3.14 tree...
> 
> Note that the GPIO-restart definitely need to be higher priorities
> than others in the system.  The two I know of off the top of my head
> are the "dw watchdog" and the one in the CRU.  The "dw watchdog" has a
> priority of 128 and so does the one in "rockchip/clk.c".  Hrm,
> actually, the Rockchip-specific one should probably have its priority
> bumped up since it seems better not to just randomly pick between
> these two...

Agreed about bumping the prio for the rockchip specific restart handler.

> 
> 
> -Doug
> --

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] mmc: pwrseq: Use highest priority for eMMC restart handler

[Javier Martinez Canillas]

Hello Anand,

On 10/22/2015 07:03 AM, Anand Moon wrote:
> Hi Javier,
> 
> On 22 October 2015 at 08:22, Javier Martinez Canillas
> <jav...@osg.samsung.com> 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 <jav...@osg.samsung.com>
>>>>>> Tested-by: Markus Reichl <m.rei...@fivetechno.de>
>>>>>> Tested-by: Anand Moon <linux.am...@gmail.com>
>>>>>> Reviewed-by: Alim Akhtar <alim.akh...@samsung.com>
>>>>>>
>>>>>> ---
>>>>>> 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 

Re: [PATCH] mmc: pwrseq: Use highest priority for eMMC restart handler

[Javier Martinez Canillas]

Hello Marek,

On 10/22/2015 12:07 PM, Marek Szyprowski wrote:
> On 2015-10-22 06:14, Alim Akhtar wrote:
>> On 10/22/2015 08:22 AM, Javier Martinez Canillas wrote:
>>> On 10/22/2015 03:43 AM, Krzysztof Kozlowski wrote:
>>>> On 22.10.2015 10:20, Javier Martinez Canillas wrote:> Hello Krzysztof,

[snip]

>>>>> And $SUBJECT should not cause any regressions for the platforms that
>>>>> are currently using the pwrseq_emmc, since the restart handler was
>>>>> already being called before the system restart handler so bumping
>>>>> the priority should not cause any effect.
>>>>
>>>> I found at least one platform where the sequence *might* change. There
>>>> could be more of them.
>>>>
>>>
>>> Agreed, I missed that rk3288-veyron is using a restart handler with higher
>>> priority and could be other boards too as you said.
>>>
>>> Let's see what is Marek's opinion since he added the pwrseq_emmc support
>>> and also what Ulf thinks about always doing a eMMC reset before reboot.
>>>
>>> I can't think how doing a eMMC card reset before reboot could affect a
>>> board but you are right that we don't know without testing.
>>>
>> git grep result shows:
>> ==
>>  git grep mmc-pwrseq-emmc
>> Documentation/devicetree/bindings/mmc/mmc-pwrseq-emmc.txt:- compatible : 
>> contains "mmc-pwrseq-emmc".
>> Documentation/devicetree/bindings/mmc/mmc-pwrseq-emmc.txt: compatible = 
>> "mmc-pwrseq-emmc";
>> arch/arm/boot/dts/am335x-sl50.dts:  compatible = 
>> "mmc-pwrseq-emmc";
>> arch/arm/boot/dts/exynos4412-odroid-common.dtsi: compatible = 
>> "mmc-pwrseq-emmc";
>> arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi: compatible = 
>> "mmc-pwrseq-emmc";
>> arch/arm/boot/dts/rk3288-veyron.dtsi:   compatible = 
>> "mmc-pwrseq-emmc";
>> arch/arm64/boot/dts/rockchip/rk3368-r88.dts:compatible = 
>> "mmc-pwrseq-emmc";
>> drivers/mmc/core/pwrseq.c:  .compatible = "mmc-pwrseq-emmc",
>> =
>> So apart from exynos, there are rk3xxx and am335x which used 
>> pwrseq-emmc-restart. So lets wait for the feedback from these guys as well.
>> Thanks.
>>
> 
> The priority was initially chosen in such a way to do the emmc reset just 
> before performing system reboot. I wanted let other possible handlers 
> potentially use mmc if needed (although there is no such case atm). Now it 
> turns that this approach was not the best idea, because there are other 
> board-specific restart handlers with higher priority than the default I was 
> using. IMHO the change proposed by Javier seems to be the best solution for 
> now. The other possibility would be to entirely get rid of restart handler 
> usage and wire this logic to mmc_shutdown(). This makes sense from the 
> logical point of view, but the drawback of this solution is the lack of 
> proper reset sequence in case of emergency reboot (shutdown callbacks are not 
> called on emergency reboot).
>

Thanks a lot for your feedback, I'm glad that you agree with the change then.
 
> Best regards

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] mmc: pwrseq: Use highest priority for eMMC restart handler

[Javier Martinez Canillas]

Hello Doug,

On 10/22/2015 05:34 PM, Doug Anderson wrote:
> Krzysztof,
> 
> On Wed, Oct 21, 2015 at 6:43 PM, Krzysztof Kozlowski
> <k.kozlow...@samsung.com> wrote:
>> I think at least one platform may be affected because it used
>> mmc-pwrseq-emmc and gpio-restart.
>>
>> Look at rk3288-veyron.dtsi.
>>
>> Both of restart handlers had the priority of 129 which means that the
>> order of execution depends on probing sequence. Now you will make the
>> sequence strict - first mmc then gpio.
>>
>> You seems convinced that this is not a problem... I don't know. I would
>> prefer test this on affected platforms before risking to break them.
>> It's annoying if fix for one SoC breaks another.
> 
> Assuming I'm understanding things properly, veyron isn't using 129 as
> a priority.  In the dts file:
> 
> gpio-restart {
> compatible = "gpio-restart";
> gpios = < 13 GPIO_ACTIVE_HIGH>;
> pinctrl-names = "default";
> pinctrl-0 = <_warm_reset_h>;
> priority = <200>;
> };
> 
> ...so it overrides the default 129 with 200.  Ah, but Javier already
> pointed that out in his reply.
> 
>>> Since the current mmc_pwrseq_emmc_reset_nb notifier priority is 129,
>>> eMMC reset will not work if one of the platforms you mentioned needs
>>> this since the system restart handler with prio 192 will be executed
>>> before the eMMC one, leaving the eMMC in an unknown state on reboot.
>>
>> And now you will "fix this" by making eMMC working correctly. So let's
>> make it straight:
>> 1. Previously the eMMC could be left on these platforms in an unknown
>> state (because emmc handler was not executed).
>> 2. No one complained! Which could mean that in fact this was working fine...
>> 3. Now you will change it.
>> 4. Maybe someone will complain?
> 
> On veyron boards the reset shouldn't hurt.  The eMMC reset will
> actually get asserted at reset anyway since the reset will reset GPIO
> states and the default GPIO state for the eMMC line asserts reset.
>

Exactly, that was my point. Either the board is wired to do a eMMC reset
on reboot (like veyron), the SoC ROM bootloader has some logic to reset
the eMMC or the boards requires the kernel to do a eMMC reset so the hw
is in a known state to read from the eMMC on reboot (like Odroids).

So that's why I was arguing that it's very unlikely that doing an eMMC
reset could cause issues in other boards... but Krzysztof is correct
that you can't be sure without testing.
 
> OK, I just picked this onto Heiko's somewhat "stable-tree"
> (v4.3-rc3-876-g6509232) from
> <https://github.com/mmind/linux-rockchip/>.  I put printouts in
> __mmc_pwrseq_emmc_reset() to confirm it was getting called.  I then
> rebooted.  I then saw:
> 
> [   36.175732] reboot: Restarting system
> [   36.179400] DOUG: resetting emmc
> [   36.182829] DOUG: resetting emmc done
> 
> ...and the reboot worked normally (which means that the GPIO restart
> got called since otherwise I would have gotten TPM errors).
> 
> So I'd say that for rk3288-veyron-jerry:
> 
> Tested-by: Douglas Anderson <diand...@chromium.org>
> 

Thanks a lot for testing!

> 
> Note that personally I would only choose the "highest" priority as an
> absolute last resort.  Leaving a little extra slack in there means
> that when the next person comes up with a really good reason to run
> before you do that they can do it without changing your code.  All
> good BASIC programmers know to skip "10" in their first version for
> just this reason.  ;)
>
> If I were to pick a number, I suppose I'd pick something like "220",
> but that's pretty arbitrary.  I would have picked 200 except that it
> appears that would race with veyron's choice.
>

Yes, I actually gave some thought about choosing a number since I didn't
want to come with another arbitrary one. That's why I tried to understand
the policy as I mentioned before but I didn't find anything besides the
values listed in the register_restart_handler() doc: 0, 128 and 255.

It seems that most default system restart handlers use 128 and that's
the reason why gpio-restart and mmc-pwrseq-emmc use 129 and other restart
handlers that can be registered via DT use 192 (which is in the middle of
128 and 255).

So I actually thought to use a number in between 192 and 255 (i.e: 220)
but then there could be another platform that uses 221 instead of 200
so eMMC restart won't work there. That's why I finally chose the highest.

Do you know why the priority 200 was chosen for veyron gpi-restart ooi?

> -Doug
> --

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

[PATCH] mmc: pwrseq: Use highest priority for eMMC restart handler

[Javier Martinez Canillas]

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 <jav...@osg.samsung.com>
Tested-by: Markus Reichl <m.rei...@fivetechno.de>
Tested-by: Anand Moon <linux.am...@gmail.com>
Reviewed-by: Alim Akhtar <alim.akh...@samsung.com>

---
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(>reset_nb);
 
pwrseq->pwrseq.ops = _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: [PATCH v2 0/6] Switch to generic syscon regmap based drivers

[Javier Martinez Canillas]

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 <jav...@osg.samsung.com>
>> 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 <jav...@osg.samsung.com>
>> ---
> Looks good.
> Reviewed-by: Alim Akhtar <alim.akh...@samsung.com>
>

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] mmc: pwrseq: Use highest priority for eMMC restart handler

[Javier Martinez Canillas]

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 <jav...@osg.samsung.com>
>> Tested-by: Markus Reichl <m.rei...@fivetechno.de>
>> Tested-by: Anand Moon <linux.am...@gmail.com>
>> Reviewed-by: Alim Akhtar <alim.akh...@samsung.com>
>>
>> ---
>> 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
> 

Re: [PATCH] MAINTAINERS: ARM: EXYNOS: Add documentation and dt-bindings

[Javier Martinez Canillas]

Hello Krzysztof,

On 10/21/2015 02:43 PM, Krzysztof Kozlowski wrote:
> 2015-10-21 17:45 GMT+09:00 Javier Martinez Canillas <jav...@osg.samsung.com>:
>>
>> 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 <k.kozlow...@samsung.com>
>>> Cc: Kukjin Kim <kg...@kernel.org>
>>> ---
>>>  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 v2 0/6] Switch to generic syscon regmap based drivers

[Javier Martinez Canillas]

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 v2 0/6] Switch to generic syscon regmap based drivers

[Javier Martinez Canillas]

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 <m.rei...@fivetechno.de>
>>>
>>> Thanks,
>>> --
>>> Markus
>>>
>>>
>>>>
>>>> Best regards,
>>>>
>>>
> 
> Tested on OdroidXU3 emmc. Reboot success.
> 
> Tested-by: Anand Moon <linux.am...@gmail.com>
> 

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] mmc: pwrseq: Use highest priority for eMMC restart handler

[Javier Martinez Canillas]

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 <jav...@osg.samsung.com>
>>>> Tested-by: Markus Reichl <m.rei...@fivetechno.de>
>>>> Tested-by: Anand Moon <linux.am...@gmail.com>
>>>> Reviewed-by: Alim Akhtar <alim.akh...@samsung.com>
>>>>
>>>> ---
>>>> 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
>>  *   

Re: [PATCH v2 0/6] Switch to generic syscon regmap based drivers

[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.

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 <jav...@osg.samsung.com>
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 <jav...@osg.samsung.com>
---
 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(>reset_nb);
 
pwrseq->pwrseq.ops = _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: [PATCH 1/2] dt-bindings: Consolidate Exynos SoC bindings under Samsung directory

[Javier Martinez Canillas]

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 <k.kozlow...@samsung.com>
> Cc: Kukjin Kim <kg...@kernel.org>
> ---

Patch looks good to me.

Reviewed-by: Javier Martinez Canillas <jav...@osg.samsung.com>

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

[Javier Martinez Canillas]

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 <k.kozlow...@samsung.com>
> Cc: Kukjin Kim <kg...@kernel.org>
> Cc: Javier Martinez Canillas <jav...@osg.samsung.com>
> Cc: Hakjoo Kim <ruppi@hardkernel.com>
> ---

Reviewed-by: Javier Martinez Canillas <jav...@osg.samsung.com>

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

[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 <k.kozlow...@samsung.com>
> Cc: Kukjin Kim <kg...@kernel.org>
> ---
>  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 <jav...@osg.samsung.com>

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

[Javier Martinez Canillas]

Hello Alim,

On 10/20/2015 11:24 AM, Alim Akhtar wrote:
> Now we have a nice way to reboot/poweroff system using a generic
> syscon regmap based drivers, this series moves exynos SoCs to
> make use of the same.
> 

I tested this series on an Exynos5800 Peach Pi and an Exynos5422 Odroid XU.
Reboot and poweroff are working correctly on both boards with these patches.

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 v6 0/17] Add Analogix Core Display Port Driver

[Javier Martinez Canillas]

Hello Yakir,

On 10/20/2015 04:10 AM, Yakir Yang wrote:
> Hi Javier,
> 
> On 10/19/2015 06:40 PM, Javier Martinez Canillas wrote:
>> Hello Yakir,
>>
>> On 10/10/2015 05:35 PM, Yakir Yang wrote:
>>> Hi all,
>>>
>>> The Samsung Exynos eDP controller and Rockchip RK3288 eDP controller
>>> share the same IP, so a lot of parts can be re-used. I split the common
>>> code into bridge directory, then rk3288 and exynos only need to keep
>>> some platform code. Cause I can't find the exact IP name of exynos dp
>>> controller, so I decide to name dp core driver with "analogix" which I
>>> find in rk3288 eDP TRM :)
>>>
>>> But  there are still three light registers setting differents bewteen
>>> exynos and rk3288.
>>> 1. RK3288 have five special pll resigters which not indicata in exynos
>>> dp controller.
>>> 2. The address of DP_PHY_PD(dp phy power manager register) are different
>>> between rk3288 and exynos.
>>> 3. Rk3288 and exynos have different setting with AUX_HW_RETRY_CTL(dp debug
>>> register).
>>>
>>> This series have been well tested on Rockchip platform with eDP panel
>>> on Jerry Chromebook and Display Port Monitor on RK3288 board and thanks
>>> to Javier@Samsung help me to find a way to install mainline kernel to
>>> Samsung Exynos Chromebooks, so this series also have been tested on Samsung
>>> Snow and Peach Pit Chromebooks which borrowed from my friends.
>>>
>>> Besides, This version was build on linux-next branch (tag next-20150918), 
>>> and
>>> the above test experiments also base on that tag. But I know the latest tag 
>>> is
>>> next-20151009, so i do rebase this series again on next-20151009, there were
>>> little conflicts(exynos_dp removed the suspend/resume).
>>>
>>> But after I retest this series on next-20151009, I saw kernel crashed in mmc
>>> driver(dw_mci_probe failed to get regulator). So i have to disabled the MMC
>>> module(after all I boot with USB device), and I can see eDP light up 
>>> normally
>>> in startup stage, but kernel keep crashed when it try to mount the 
>>> filesystem.
>>> I thought this isn't related to dp driver directly, so i choice not to debug
>>> more depth.
>>>
>>> That's to say if someone want to test this series, I suggest you applied 
>>> this
>>> series on tag-20150918, just need to fix some light conflicts with the 01 & 
>>> 02
>>> patches (or just email me, I can send you directly).
>>>
>>> Thanks,
>> Do you have a branch that I can use to test this series?
> 
> Thank you for your kind assistance, I have created a tree which checkout from 
> the next-20151019. Surely there were some conflicts to applied this series on 
> that tag, but things still works for me, here is the git address 
> [https://github.com/yakir-Yang/linux/tree/analogix_dp]
>

I tested your branch on an Exynos5800 Peach Pi Chromebook and display is
working on boot. I also tested DPMS and S2R and things are still working
so for the whole series feel free to add:

Tested-by: Javier Martinez Canillas <jav...@osg.samsung.com>

> Best regards,
> - Yakir
> 

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 5/6] ARM: exynos: select POWER_RESET_SYSCON and POWER_RESET_SYSCON_POWEROFF

[Javier Martinez Canillas]

Hello Alim,

On 10/20/2015 11:24 AM, Alim Akhtar wrote:
> Since we switch to use generic syscon regmap based reset/poweroff
> driver for exynos SoC, lets select it from ARCH_EXYNOS instead of
> enabling it from various defconfigs. This also select POWER_RESET
> as SYSCON-{reset, poweroff} drivers depends on it.
> 
> Signed-off-by: Alim Akhtar <alim.akh...@samsung.com>
> ---
> 

Patch looks good to me.

Reviewed-by: Javier Martinez Canillas <jav...@osg.samsung.com>
Tested-by: Javier Martinez Canillas <jav...@osg.samsung.com>

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 6/6] ARM: EXYNOS: Remove code for restart and poweroff for exynos SoCs

[Javier Martinez Canillas]

Hello Alim,

On 10/20/2015 11:24 AM, Alim Akhtar wrote:
> Now we can use the generic syscon-{reboot/poweroff} drivers,
> so we don't need special handling for reboot/poweroff in
> exynos pmu driver. This patch remove the same.
> 
> Note: This will break reboot/poweroff on boards with older dtbs
> with a newer kernel.
> 
> Signed-off-by: Alim Akhtar <alim.akh...@samsung.com>
> Reviewed-by: Javier Martinez Canillas <jav...@osg.samsung.com>
> Acked-by: Moritz Fischer <moritz.fisc...@ettus.com>
> ---
>  arch/arm/mach-exynos/pmu.c |   43 ---
>  1 file changed, 43 deletions(-)
> 

Tested-by: Javier Martinez Canillas <jav...@osg.samsung.com>

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 3/6] arm: dts: Add syscon-{reboot, poweroff} nodes for exynos5

[Javier Martinez Canillas]

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 <alim.akh...@samsung.com>
> Reviewed-by: Pankaj Dubey <pankaj.du...@samsung.com>
> Reviewed-by: Javier Martinez Canillas <jav...@osg.samsung.com>
> Acked-by: Moritz Fischer <moritz.fisc...@ettus.com>
> ---
>  arch/arm/boot/dts/exynos5.dtsi |   14 ++
>  1 file changed, 14 insertions(+)
> 

Tested-by: Javier Martinez Canillas <jav...@osg.samsung.com>

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: [RFC PATCH] ARM: exynos_defconfig: Increase CONFIG_BLK_DEV_RAM_SIZE to 64K

[Javier Martinez Canillas]

Hello Alim,

On 10/19/2015 12:48 PM, Alim Akhtar wrote:
> CONFIG_BLK_DEV_RAM_SIZE is currently set to 8K, which is a bit on the
> smaller side, lets bump it up to 64K so that a bigger RAM_DISK can
> be used with defconfig.
> 
> Signed-off-by: Alim Akhtar <alim.akh...@samsung.com>
> ---

I agree that 8KiB is too small and that should be bumped, I'm also
not sure what the best size would be but 64KiB sounds reasonable
to me. So for this patch:

Reviewed-by: Javier Martinez Canillas <jav...@osg.samsung.com>

> Every time I build exynos_defconfig, I need to manually change RAM_SIZE
> to match my ramdisk image size. I am not sure what is the best ramdisk size
> might be, but bumping it to 64K might be a reasonable one.
>

In case you are interested, I got some stats by doing grep on the ARM
defconfigs using this [0]. Of course the sizes depends on the platform
but just to have an idea about what sizes are more popular than others.

SIZECOUNT
102417
819243
10240   1
16384   20
2   25
32768   36
65536   15

[0]: http://hastebin.com/buqukimede.bash

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 7/7] ARM: EXYNOS: Remove code for restart and poweroff for exynos SoCs

[Javier Martinez Canillas]

Hello,

On 10/19/2015 09:00 AM, Krzysztof Kozlowski wrote:
> On 19.10.2015 15:03, Alim Akhtar wrote:
>> Now we can use the generic syscon-{reboot/poweroff} drivers,
>> so we don't need special handling for reboot/poweroff in
>> exynos pmu driver. This patch remove the same.
>>
>> Signed-off-by: Alim Akhtar <alim.akh...@samsung.com>
>> ---
>>  arch/arm/mach-exynos/pmu.c |   43 
>> ---
>>  1 file changed, 43 deletions(-)
> 
> I think that removal of this stuff will effectively remove the
> restart/poweroff handlers from:
> 1. Other defconfigs, like multi_v7
> 2. Custom configs.
>

This will also break old DTBs that don't have a "syscon-poweroff" device
node that contains the necessary PMU regmap, offset and mask information.
 
> Previously this code was always compiled in for ARCH_EXYNOS. Now it is
> not so I am thinking about selecting necessary drivers from main exynos
> Kconfig symbol. That could be tricky though, because "select" should be
> used only for non-visible symbols.
> 
> Any ideas how to solve that?
>

Is true that select should only be used for non-visible symbols but there
are others user visible symbols that are selected by ARCH_EXYNOS such as
EXYNOS_THERMAL. So I think selecting the regmap syscon reset stuff there
is a sensible option.
 
> 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 v6 0/17] Add Analogix Core Display Port Driver

[Javier Martinez Canillas]

Hello Yakir,

On 10/10/2015 05:35 PM, Yakir Yang wrote:
> 
> Hi all,
> 
>The Samsung Exynos eDP controller and Rockchip RK3288 eDP controller
> share the same IP, so a lot of parts can be re-used. I split the common
> code into bridge directory, then rk3288 and exynos only need to keep
> some platform code. Cause I can't find the exact IP name of exynos dp
> controller, so I decide to name dp core driver with "analogix" which I
> find in rk3288 eDP TRM :)
> 
> But  there are still three light registers setting differents bewteen
> exynos and rk3288.
> 1. RK3288 have five special pll resigters which not indicata in exynos
>dp controller.
> 2. The address of DP_PHY_PD(dp phy power manager register) are different
>between rk3288 and exynos.
> 3. Rk3288 and exynos have different setting with AUX_HW_RETRY_CTL(dp debug
>register).
> 
> This series have been well tested on Rockchip platform with eDP panel
> on Jerry Chromebook and Display Port Monitor on RK3288 board and thanks
> to Javier@Samsung help me to find a way to install mainline kernel to
> Samsung Exynos Chromebooks, so this series also have been tested on Samsung
> Snow and Peach Pit Chromebooks which borrowed from my friends.
> 
> Besides, This version was build on linux-next branch (tag next-20150918), and
> the above test experiments also base on that tag. But I know the latest tag is
> next-20151009, so i do rebase this series again on next-20151009, there were
> little conflicts(exynos_dp removed the suspend/resume).
> 
> But after I retest this series on next-20151009, I saw kernel crashed in mmc
> driver(dw_mci_probe failed to get regulator). So i have to disabled the MMC
> module(after all I boot with USB device), and I can see eDP light up normally
> in startup stage, but kernel keep crashed when it try to mount the filesystem.
> I thought this isn't related to dp driver directly, so i choice not to debug
> more depth.
> 
> That's to say if someone want to test this series, I suggest you applied this
> series on tag-20150918, just need to fix some light conflicts with the 01 & 02
> patches (or just email me, I can send you directly).
> 
> Thanks,

Do you have a branch that I can use to test this series?

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 5/7] ARM: exynos_defconfig: Normalize exynos defconfig

[Javier Martinez Canillas]

Hello Alim,

On 10/19/2015 08:03 AM, Alim Akhtar wrote:
> make savedefconfig result in some difference, lets normalize the
> defconfig.
> 
> Signed-off-by: Alim Akhtar <alim.akh...@samsung.com>
> ---

Did you make savedefconfig against v4.3-rc6 or tot linux-next?

I remember we had issues in the past due savedefconfig made against
linux-next but then some of the patches in linux-next not making it
to the next release. So I think it should be good to mention what's
the base used for this patch.

>  arch/arm/configs/exynos_defconfig |8 ++--
>  1 file changed, 2 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/arm/configs/exynos_defconfig 
> b/arch/arm/configs/exynos_defconfig
> index 1ff2bfa2e183..3349713e6c63 100644
> --- a/arch/arm/configs/exynos_defconfig
> +++ b/arch/arm/configs/exynos_defconfig
> @@ -99,10 +99,8 @@ CONFIG_SENSORS_LM90=y
>  CONFIG_SENSORS_NTC_THERMISTOR=y
>  CONFIG_SENSORS_PWM_FAN=y
>  CONFIG_SENSORS_INA2XX=y
> -CONFIG_THERMAL=y
>  CONFIG_CPU_THERMAL=y
>  CONFIG_THERMAL_EMULATION=y
> -CONFIG_EXYNOS_THERMAL=y

I would prefer to split all the changes that removes symbols into a
separate patch explaining why these are not needed anymore (i.e: it
is selected now by symbol $foo).

>  CONFIG_WATCHDOG=y
>  CONFIG_S3C2410_WATCHDOG=y
>  CONFIG_MFD_CROS_EC=y
> @@ -127,14 +125,14 @@ CONFIG_REGULATOR_S2MPS11=y
>  CONFIG_REGULATOR_S5M8767=y
>  CONFIG_REGULATOR_TPS65090=y
>  CONFIG_DRM=y
> -CONFIG_DRM_NXP_PTN3460=y
> -CONFIG_DRM_PARADE_PS8622=y
>  CONFIG_DRM_EXYNOS=y
>  CONFIG_DRM_EXYNOS_FIMD=y
>  CONFIG_DRM_EXYNOS_DSI=y
>  CONFIG_DRM_EXYNOS_HDMI=y
>  CONFIG_DRM_PANEL_SIMPLE=y
>  CONFIG_DRM_PANEL_SAMSUNG_S6E8AA0=y
> +CONFIG_DRM_NXP_PTN3460=y
> +CONFIG_DRM_PARADE_PS8622=y

Moving these DRM bridge symbols to match savedefconfig is ok IMHO.

>  CONFIG_FB_SIMPLE=y
>  CONFIG_EXYNOS_VIDEO=y
>  CONFIG_EXYNOS_MIPI_DSI=y
> @@ -175,7 +173,6 @@ CONFIG_RTC_DRV_S5M=y
>  CONFIG_RTC_DRV_S3C=y
>  CONFIG_DMADEVICES=y
>  CONFIG_PL330_DMA=y
> -CONFIG_CHROME_PLATFORMS=y
>  CONFIG_CROS_EC_CHARDEV=y
>  CONFIG_COMMON_CLK_MAX77686=y
>  CONFIG_COMMON_CLK_MAX77802=y
> @@ -190,7 +187,6 @@ CONFIG_PWM_SAMSUNG=y
>  CONFIG_PHY_EXYNOS5250_SATA=y
>  CONFIG_EXT2_FS=y
>  CONFIG_EXT3_FS=y
> -CONFIG_EXT4_FS=y
>  CONFIG_MSDOS_FS=y
>  CONFIG_VFAT_FS=y
>  CONFIG_TMPFS=y
> 

Same comment than above, I would prefer these to be split.

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 7/7] ARM: EXYNOS: Remove code for restart and poweroff for exynos SoCs

[Javier Martinez Canillas]

Hello Krzysztof,

On 10/19/2015 03:28 PM, Krzysztof Kozlowski wrote:
> 2015-10-19 18:56 GMT+09:00 Javier Martinez Canillas <jav...@osg.samsung.com>:
>> Hello,
>>
>> On 10/19/2015 09:00 AM, Krzysztof Kozlowski wrote:
>>> On 19.10.2015 15:03, Alim Akhtar wrote:
>>>> Now we can use the generic syscon-{reboot/poweroff} drivers,
>>>> so we don't need special handling for reboot/poweroff in
>>>> exynos pmu driver. This patch remove the same.
>>>>
>>>> Signed-off-by: Alim Akhtar <alim.akh...@samsung.com>
>>>> ---
>>>>  arch/arm/mach-exynos/pmu.c |   43 
>>>> ---
>>>>  1 file changed, 43 deletions(-)
>>>
>>> I think that removal of this stuff will effectively remove the
>>> restart/poweroff handlers from:
>>> 1. Other defconfigs, like multi_v7
>>> 2. Custom configs.
>>>
>>
>> This will also break old DTBs that don't have a "syscon-poweroff" device
>> node that contains the necessary PMU regmap, offset and mask information.
> 
> I am not sure whether this is ABI break issue. There was no compatible
> mentioning that "reset works" which now would be replaced. The
> existing PMU compatible (like samsung,exynos4412-pmu) does not mention
> "reset" as a feature coming with this compatible.
> 
> So no ABI break.
> 
> 

I deliberately didn't use the "DT ABI break" expression since as you said is
not part of the documented DT bindings. But what I said is that this change
will break old DTBs with newer kernels since reboot and power off will stop
working after $SUBJECT.

I'm not a particular fan of the stable DT idea since in practice it seems to
do more harm than good but since that was decided, the expectation for users
is that booting a new kernel with an old DT should not cause any regression.

So I think that at least a comment in the commit message is needed so if
there are people really using old DTs with newer kernels on Exynos boards,
they can know that the commit causes such an issue instead of having to
figure it out themselves.

>>
>>> Previously this code was always compiled in for ARCH_EXYNOS. Now it is
>>> not so I am thinking about selecting necessary drivers from main exynos
>>> Kconfig symbol. That could be tricky though, because "select" should be
>>> used only for non-visible symbols.
>>>
>>> Any ideas how to solve that?
>>>
>>
>> Is true that select should only be used for non-visible symbols but there
>> are others user visible symbols that are selected by ARCH_EXYNOS such as
>> EXYNOS_THERMAL. So I think selecting the regmap syscon reset stuff there
>> is a sensible option.
> 
> Selecting from defconfig is not sufficient... since I do not have
> other idea than selecting then ovak, but Alim please check it whether
> it does not create circular dependencies on various configs.
>

Agreed, Kconfig circular dependencies is the reason why select is avoided.
Fortunately now the 0-day bot analyzes even posted patches so it's possible
that such an issue could be found even before these patches are merged.

> 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 5/7] ARM: exynos_defconfig: Normalize exynos defconfig

[Javier Martinez Canillas]

Hello Alim,

On 10/19/2015 05:58 PM, Alim Akhtar wrote:
> Hi Javier,
> 
> On Mon, Oct 19, 2015 at 6:55 PM, Javier Martinez Canillas
> <jav...@osg.samsung.com> wrote:
>> Hello Alim,
>>
>> On 10/19/2015 08:03 AM, Alim Akhtar wrote:
>>> make savedefconfig result in some difference, lets normalize the
>>> defconfig.
>>>
>>> Signed-off-by: Alim Akhtar <alim.akh...@samsung.com>
>>> ---
>>
>> Did you make savedefconfig against v4.3-rc6 or tot linux-next?
>>
> These are based on v4.3-rc5.
> 
>> I remember we had issues in the past due savedefconfig made against
>> linux-next but then some of the patches in linux-next not making it
>> to the next release. So I think it should be good to mention what's
>> the base used for this patch.
>>
> Ah, ok I didn't follow that, will check again on Linux-next as well as

IIRC the problem was in that case that a patch was adding a new select
that made the symbol not necessary in the defconfig. So a patch against
linux-next was posted removing the unneeded symbol but at the end the
select patch didn't make it to the release but the one removing the
symbol did.

> on 4.3-rc5
>

OK, using 4.3-rcX should be safe AFAICT.

>>>  arch/arm/configs/exynos_defconfig |8 ++--
>>>  1 file changed, 2 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/arch/arm/configs/exynos_defconfig 
>>> b/arch/arm/configs/exynos_defconfig
>>> index 1ff2bfa2e183..3349713e6c63 100644
>>> --- a/arch/arm/configs/exynos_defconfig
>>> +++ b/arch/arm/configs/exynos_defconfig
>>> @@ -99,10 +99,8 @@ CONFIG_SENSORS_LM90=y
>>>  CONFIG_SENSORS_NTC_THERMISTOR=y
>>>  CONFIG_SENSORS_PWM_FAN=y
>>>  CONFIG_SENSORS_INA2XX=y
>>> -CONFIG_THERMAL=y
>>>  CONFIG_CPU_THERMAL=y
>>>  CONFIG_THERMAL_EMULATION=y
>>> -CONFIG_EXYNOS_THERMAL=y
>>
>> I would prefer to split all the changes that removes symbols into a
>> separate patch explaining why these are not needed anymore (i.e: it
>> is selected now by symbol $foo).
>>
> Ok ..let me rebase my patches and check these config changes again


Thanks, the changes looks good to me though so please feel free
to add my Reviewed-by tag if you re-spin and split the changes.

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 7/7] ARM: EXYNOS: Remove code for restart and poweroff for exynos SoCs

[Javier Martinez Canillas]

Hello Alim,

On 10/19/2015 06:13 PM, Alim Akhtar wrote:
> Hi Javier,
> 
> On Mon, Oct 19, 2015 at 7:37 PM, Javier Martinez Canillas
> <jav...@osg.samsung.com> wrote:
>> Hello Krzysztof,
>>
>> On 10/19/2015 03:28 PM, Krzysztof Kozlowski wrote:
>>> 2015-10-19 18:56 GMT+09:00 Javier Martinez Canillas 
>>> <jav...@osg.samsung.com>:
>>>> Hello,
>>>>
>>>> On 10/19/2015 09:00 AM, Krzysztof Kozlowski wrote:
>>>>> On 19.10.2015 15:03, Alim Akhtar wrote:
>>>>>> Now we can use the generic syscon-{reboot/poweroff} drivers,
>>>>>> so we don't need special handling for reboot/poweroff in
>>>>>> exynos pmu driver. This patch remove the same.
>>>>>>
>>>>>> Signed-off-by: Alim Akhtar <alim.akh...@samsung.com>
>>>>>> ---
>>>>>>  arch/arm/mach-exynos/pmu.c |   43 
>>>>>> ---
>>>>>>  1 file changed, 43 deletions(-)
>>>>>
>>>>> I think that removal of this stuff will effectively remove the
>>>>> restart/poweroff handlers from:
>>>>> 1. Other defconfigs, like multi_v7
>>>>> 2. Custom configs.
>>>>>
>>>>
>>>> This will also break old DTBs that don't have a "syscon-poweroff" device
>>>> node that contains the necessary PMU regmap, offset and mask information.
>>>
>>> I am not sure whether this is ABI break issue. There was no compatible
>>> mentioning that "reset works" which now would be replaced. The
>>> existing PMU compatible (like samsung,exynos4412-pmu) does not mention
>>> "reset" as a feature coming with this compatible.
>>>
>>> So no ABI break.
>>>
>>>
>>
>> I deliberately didn't use the "DT ABI break" expression since as you said is
>> not part of the documented DT bindings. But what I said is that this change
>> will break old DTBs with newer kernels since reboot and power off will stop
>> working after $SUBJECT.
>>
>> I'm not a particular fan of the stable DT idea since in practice it seems to
>> do more harm than good but since that was decided, the expectation for users
>> is that booting a new kernel with an old DT should not cause any regression.
>>
>> So I think that at least a comment in the commit message is needed so if
>> there are people really using old DTs with newer kernels on Exynos boards,
>> they can know that the commit causes such an issue instead of having to
>> figure it out themselves.
>>
> Agree, will add a comment about this in commit message.
>

Thanks, with that comment in the commit message, feel free
to add my Reviewed-by tag to this patch as well.
 
>>>>
>>>>> Previously this code was always compiled in for ARCH_EXYNOS. Now it is
>>>>> not so I am thinking about selecting necessary drivers from main exynos
>>>>> Kconfig symbol. That could be tricky though, because "select" should be
>>>>> used only for non-visible symbols.
>>>>>
>>>>> Any ideas how to solve that?
>>>>>
>>>>
>>>> Is true that select should only be used for non-visible symbols but there
>>>> are others user visible symbols that are selected by ARCH_EXYNOS such as
>>>> EXYNOS_THERMAL. So I think selecting the regmap syscon reset stuff there
>>>> is a sensible option.
>>>
>>> Selecting from defconfig is not sufficient... since I do not have
>>> other idea than selecting then ovak, but Alim please check it whether
>>> it does not create circular dependencies on various configs.
>>>
>>
>> Agreed, Kconfig circular dependencies is the reason why select is avoided.
>> Fortunately now the 0-day bot analyzes even posted patches so it's possible
>> that such an issue could be found even before these patches are merged.
>>
> ok..will select it from mach-exynos/Kconfig.
> Thanks.
>

Ok, great.

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 1/2] clk: samsung: exynos5250: Add DISP1 clocks

[Javier Martinez Canillas]

Hello Krzysztof,

On 10/17/2015 10:53 AM, Krzysztof Kozlowski wrote:
> 2015-10-17 8:41 GMT+09:00 Kukjin Kim <kg...@kernel.org>:

[snip]

>>>
>> So...how can I take 2nd patch of this series in samsung(arm-soc) tree?
>> And this series shouldn't be for fixes for 4.3?...Mike how do you think?
> 
> Stephen acked it so I thought everything will go through samsung-soc.
> 
> Dear Kukjin,
> Indeed this can go as fix for current cycle... but in the same time
> this does not fix any specific regression. Tomeu did not describe when
> issue happened for the first time so I assumed it was like that
> always. It's up to you.
>

Sorry for not answering about this series before but I've been in contact
with Tomeu over IRC before he posted it and since you already added your
Reviewed-by tag, I didn't feel the need do to it.

This is a regression for 4.3 since S2R was working correctly for 4.2 in
Snow, I tested after fixing resume with commit 6fd4899a54a5 ("irqchip:
exynos-combiner: Save IRQ enable set on suspend") and the display was
always enabled on resume.

I don't have access to a Snow anymore to bisect but I think the regression
was introduced by some of the changes in 4.3 to migrate the Exynos DRM to
Atomic Mode Settings. But probably that just exposed a latent bug and it
was working out of luck since I had the same issue than Tomeu in Exynos5420
and was fixed in the same way with commits:

885601002998 ("clk: exynos5420: Add IDs for clocks used in DISP1 power domain")
ea08de16eb1b ("ARM: dts: Add DISP1 power domain for exynos5420")

> Both patches (with Stephen's ack) are in my recent pull request but as
> usual feel free to cherry pick. I'll drop them from next branch then.
> 
> 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 v2 0/6] ARM: dts: Use correct CD properties for SDIO and eMMC in Snow and Peach

[Javier Martinez Canillas]

Hello Alim,

On 10/16/2015 01:37 PM, Alim Akhtar wrote:
> Hi Javier,
> 
> On 10/15/2015 10:21 PM, Javier Martinez Canillas wrote:
>> Hello,
>>
>> The Exynos Chromebooks DTS don't use the correct card detection properties
>> since these were carried from the vendor tree that had a reason to do so.
>>
>> There are two things that I noticed:
>>
>> 1) The Marvell WiFi SDIO is marked as broken-cd instead of non-removable:
>>
>> This causes the device to be removed when the system enters into a suspend
>> state which leads to the following warning when the system is resumed:
>>
>> [  181.944636] mmc2: error -2 during resume (card was removed?)
>>
>> The rationale for using broken-cd is explained in downstream commit [0] and
>> was that using the non-removable property caused issues with the mwifiex
>> driver since the reset logic called the mmc_{remove,add}_host() functions.
>>
>> But the reset logic in the mwifiex mainline driver has changed and this is
>> no longer the case so it's safe to use the non-removable property AFAICT.
>>
> Good to know it is fixed now. This is fixed in firmware or in the driver?
>

The fix is only in the driver. In fact, I'm using the same firmware from
the ChromeOS rootfs for both the v3.8 vendor tree and mainline.

So IIUC, the problem with the vendor tree was that the mwifiex SDIO driver
mwifiex_sdio_reset_work() function did a card reset by calling the functions
mmc_remove_host() and then mmc_add_host().

But this didn't play nice with MMC_CAP_NONREMOVABLE since mmc_rescan() just
returns if the flag is set so the card wouldn't be tried to be detected again.

After commit ("b4336a282db8 mwifiex: sdio: reset adapter using mmc_hw_reset"),
the card is reset by doing a power cycle so that's why "non-removable" can be
used now instead of "broken-cd".

>> 2) The eMMC node has both broken-cd and non-removable but the MMC DT binding
>> doc (Documentation/devicetree/bindings/mmc/mmc.txt) mentions that only one
>> of these card detection properties should be used.
>>
> This change looks ok, will take a closer look once I am back to my work 
> station.
>

Thanks a lot for taking a look.

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

[RFT PATCH 3/3] ARM: dts: Mark SDIO as non-removable in exynos5250-snow-common

[Javier Martinez Canillas]

The Exynos5250 Snow Chromebooks have a Marvell WiFi SDIO chip which
can't neither be removed nor be detected. But the node isn't marked
as non-removable and instead has the broken-cd DT property.

This causes the device to be removed when the system enters into a
suspend state and the following warnings is shown after a resume:

[  181.944636] mmc2: error -2 during resume (card was removed?)

Signed-off-by: Javier Martinez Canillas <jav...@osg.samsung.com>

---

 arch/arm/boot/dts/exynos5250-snow-common.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/exynos5250-snow-common.dtsi 
b/arch/arm/boot/dts/exynos5250-snow-common.dtsi
index 0a7f408824d8..bf27957fd660 100644
--- a/arch/arm/boot/dts/exynos5250-snow-common.dtsi
+++ b/arch/arm/boot/dts/exynos5250-snow-common.dtsi
@@ -520,7 +520,7 @@
 _0 {
status = "okay";
num-slots = <1>;
-   broken-cd;
+   non-removable;
card-detect-delay = <200>;
samsung,dw-mshc-ciu-div = <3>;
samsung,dw-mshc-sdr-timing = <2 3>;
-- 
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 0/3] ARM: dts: Mark SDIO as non-removable for Exynos Chromebooks

[Javier Martinez Canillas]

Hello,

The Exynos based Chromebooks have a Marvell WiFi SDIO chip which is always
present and cannot be detected. The mmc device node is marked as broken-cd
since that property is used in the vendor tree instead of non-removable.

This causes the device to be removed when the system enteres into a suspend
gettings the following warning when the system is resumed:

[  181.944636] mmc2: error -2 during resume (card was removed?)

The rationale for that is explained in commit [0] and it was that using the
non-removable property caused issues with the driver whose reset logic used
the mmc_{remove,add}_host() functions.

But the reset logic in the mwifiex mainline driver has changed and this is
longer the case so it's safe to use non-removable. This series changes the
Snow, Peach Pi and Peach Pit boards to use the correct DT property.

To test, I've cherry picked commit [1] from the vendor tree that adds a
debugfs entry to force a card reset and after the reset, WiFi rescanning works
the card gets connected to an AP and works correctly:

$ echo 1 > /sys/kernel/debug/mwifiex/mlan0/reset

I don't have access to a Snow anymore so testing patch 3/3 on that board will
be appreciated.

[0]: 
https://chromium.googlesource.com/chromiumos/third_party/kernel/+/ad348e1e2381
[1]: 
https://chromium.googlesource.com/chromiumos/third_party/kernel/+/5995363523de

Best regards,
Javier


Javier Martinez Canillas (3):
  ARM: dts: Mark SDIO as non-removable in exynos5800-peach-pi
  ARM: dts: Mark SDIO as non-removable in exynos5420-peach-pit
  ARM: dts: Mark SDIO as non-removable in exynos5250-snow-common

 arch/arm/boot/dts/exynos5250-snow-common.dtsi | 2 +-
 arch/arm/boot/dts/exynos5420-peach-pit.dts| 2 +-
 arch/arm/boot/dts/exynos5800-peach-pi.dts | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

-- 
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 2/3] ARM: dts: Mark SDIO as non-removable in exynos5420-peach-pit

[Javier Martinez Canillas]

The Exynos5420 Peach Pit Chromebook has a Marvell WiFi SDIO chip which
can't neither be removed nor be detected. But the node isn't marked
as non-removable and instead has the broken-cd DT property.

This causes the device to be removed when the system enters into a
suspend state and the following warnings is shown after a resume:

[  181.944636] mmc2: error -2 during resume (card was removed?)

Signed-off-by: Javier Martinez Canillas <jav...@osg.samsung.com>
---

 arch/arm/boot/dts/exynos5420-peach-pit.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts 
b/arch/arm/boot/dts/exynos5420-peach-pit.dts
index 72ba6f032ed7..293bf6a76a16 100644
--- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
+++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
@@ -690,7 +690,7 @@
 _0 {
status = "okay";
num-slots = <1>;
-   broken-cd;
+   non-removable;
mmc-hs200-1_8v;
cap-mmc-highspeed;
non-removable;
-- 
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 1/3] ARM: dts: Mark SDIO as non-removable in exynos5800-peach-pi

[Javier Martinez Canillas]

The Exynos5800 Peach Pi Chromebook has a Marvell WiFi SDIO chip which
can't neither be removed nor be detected. But the node isn't marked
as non-removable and instead has the broken-cd DT property.

This causes the device to be removed when the system enters into a
suspend state and the following warnings is shown after a resume:

[  181.944636] mmc2: error -2 during resume (card was removed?)

Signed-off-by: Javier Martinez Canillas <jav...@osg.samsung.com>
---

 arch/arm/boot/dts/exynos5800-peach-pi.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts 
b/arch/arm/boot/dts/exynos5800-peach-pi.dts
index 49a4f43e5ac2..2866ac8e3ad0 100644
--- a/arch/arm/boot/dts/exynos5800-peach-pi.dts
+++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts
@@ -672,7 +672,7 @@
 _1 {
status = "okay";
num-slots = <1>;
-   broken-cd;
+   non-removable;
cap-sdio-irq;
keep-power-in-suspend;
card-detect-delay = <200>;
-- 
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: [RFT PATCH 3/3] ARM: dts: Mark SDIO as non-removable in exynos5250-snow-common

[Javier Martinez Canillas]

Hello Tomeu,

On 10/15/2015 02:30 PM, Tomeu Vizoso wrote:
> On 15 October 2015 at 12:55, Javier Martinez Canillas
> <jav...@osg.samsung.com> wrote:
>> The Exynos5250 Snow Chromebooks have a Marvell WiFi SDIO chip which
>> can't neither be removed nor be detected. But the node isn't marked
>> as non-removable and instead has the broken-cd DT property.
>>
>> This causes the device to be removed when the system enters into a
>> suspend state and the following warnings is shown after a resume:
>>
>> [  181.944636] mmc2: error -2 during resume (card was removed?)
> 
> Hi Javier,
> 
> isn't wifi on snow on mmc_3?
>

Sigh, you are correct. It seems I have a really bad day and missed.

I got confused though because the node for mmc_0 (eMMC) in Snow
also has a broken-cd property instead of non-removable. I'll add
another patch to the series changing that.

I also noticed that the mmc_0 (eMMC) node in Peach boards have both
non-removable and broken-cd which doesn't make sense and the MMC
DT binding is clear that the options are mutually exclusive.

Seems to be copy & paste error from the vendor tree since the
downstream DTS also have both properties in the nodes. So I'll also
add patches to remove the broken-cd from these nodes.

> With your patch, I don't see any change, but if I do it on mmc_3
> instead, the machine fails to resume. Will try to get more info.
>

Yes, I wouldn't expect any changes since the patch is marking the
eMMC as non-removable but I wonder why is causing a fail to resume.
Are you sure the system is resuming without $SUBJECT? You mentioned
in IRC that S2R was broken for Snow in linux-next.

> Regards,
> 
> Tomeu
> 

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

[PATCH v2 1/6] ARM: dts: Mark SDIO as non-removable in exynos5800-peach-pi

[Javier Martinez Canillas]

The Exynos5800 Peach Pi Chromebook has a Marvell WiFi SDIO chip which
can't neither be removed nor be detected. But the node isn't marked
as non-removable and instead has the broken-cd DT property.

This causes the device to be removed when the system enters into a
suspend state and the following warnings is shown after a resume:

[  181.944636] mmc2: error -2 during resume (card was removed?)

Also remove the card-detect-delay property that is not needed with
non-removable.

Signed-off-by: Javier Martinez Canillas <jav...@osg.samsung.com>
---

Changes since v1:
- Remove card-detect-delay property as well.

 arch/arm/boot/dts/exynos5800-peach-pi.dts | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts 
b/arch/arm/boot/dts/exynos5800-peach-pi.dts
index 49a4f43e5ac2..ca3a467a585d 100644
--- a/arch/arm/boot/dts/exynos5800-peach-pi.dts
+++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts
@@ -672,10 +672,9 @@
 _1 {
status = "okay";
num-slots = <1>;
-   broken-cd;
+   non-removable;
cap-sdio-irq;
keep-power-in-suspend;
-   card-detect-delay = <200>;
clock-frequency = <4>;
samsung,dw-mshc-ciu-div = <1>;
samsung,dw-mshc-sdr-timing = <0 1>;
-- 
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

[RFT PATCH v2 6/6] ARM: dts: Mark eMMC as non-removable in exynos5250-snow-common

[Javier Martinez Canillas]

The eMMC is non-removable so mark it using the non-removable DT
property to avoid having to redetect it after a suspend/resume.

Also remove the card-detect-delay property that is not needed with
non-removable.

Signed-off-by: Javier Martinez Canillas <jav...@osg.samsung.com>

---

Changes since v1:
- None, new patch.

 arch/arm/boot/dts/exynos5250-snow-common.dtsi | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/exynos5250-snow-common.dtsi 
b/arch/arm/boot/dts/exynos5250-snow-common.dtsi
index 1822c502a25a..5cb33ba5e296 100644
--- a/arch/arm/boot/dts/exynos5250-snow-common.dtsi
+++ b/arch/arm/boot/dts/exynos5250-snow-common.dtsi
@@ -520,8 +520,7 @@
 _0 {
status = "okay";
num-slots = <1>;
-   broken-cd;
-   card-detect-delay = <200>;
+   non-removable;
samsung,dw-mshc-ciu-div = <3>;
samsung,dw-mshc-sdr-timing = <2 3>;
samsung,dw-mshc-ddr-timing = <1 2>;
-- 
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 v2 5/6] ARM: dts: Remove broken-cd from eMMC node in exynos5420-peach-pi

[Javier Martinez Canillas]

The eMMC is non-removable so is marked with the non-removable DT
property to avoid having to redetect it after a suspend/resume.

But it also has the broken-cd property which is wrong since only
one of the DT properties for card detection should be used.

Also remove the card-detect-delay property that is not needed with
non-removable.

Signed-off-by: Javier Martinez Canillas <jav...@osg.samsung.com>
---

Changes since v1:
- None, new patch.

 arch/arm/boot/dts/exynos5420-peach-pit.dts | 2 --
 1 file changed, 2 deletions(-)

diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts 
b/arch/arm/boot/dts/exynos5420-peach-pit.dts
index 02e99dbafcfb..35cfb07dc4bb 100644
--- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
+++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
@@ -690,11 +690,9 @@
 _0 {
status = "okay";
num-slots = <1>;
-   broken-cd;
mmc-hs200-1_8v;
cap-mmc-highspeed;
non-removable;
-   card-detect-delay = <200>;
clock-frequency = <4>;
samsung,dw-mshc-ciu-div = <3>;
samsung,dw-mshc-sdr-timing = <0 4>;
-- 
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 v2 2/6] ARM: dts: Mark SDIO as non-removable in exynos5420-peach-pit

[Javier Martinez Canillas]

The Exynos5420 Peach Pit Chromebook has a Marvell WiFi SDIO chip which
can't neither be removed nor be detected. But the node isn't marked
as non-removable and instead has the broken-cd DT property.

This causes the device to be removed when the system enters into a
suspend state and the following warnings is shown after a resume:

[  181.944636] mmc2: error -2 during resume (card was removed?)

Also remove the card-detect-delay property that is not needed with
non-removable.

Signed-off-by: Javier Martinez Canillas <jav...@osg.samsung.com>
---

Changes since v1:
- Remove card-detect-delay property as well.

 arch/arm/boot/dts/exynos5420-peach-pit.dts | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts 
b/arch/arm/boot/dts/exynos5420-peach-pit.dts
index 72ba6f032ed7..02e99dbafcfb 100644
--- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
+++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
@@ -709,10 +709,9 @@
 _1 {
status = "okay";
num-slots = <1>;
-   broken-cd;
+   non-removable;
cap-sdio-irq;
keep-power-in-suspend;
-   card-detect-delay = <200>;
clock-frequency = <4>;
samsung,dw-mshc-ciu-div = <1>;
samsung,dw-mshc-sdr-timing = <0 1>;
-- 
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 v2 4/6] ARM: dts: Remove broken-cd from eMMC node in exynos5800-peach-pi

[Javier Martinez Canillas]

The eMMC is non-removable so is marked with the non-removable DT
property to avoid having to redetect it after a suspend/resume.

But it also has the broken-cd property which is wrong since only
one of the DT properties for card detection should be used.

Also remove the card-detect-delay property that is not needed with
non-removable.

Signed-off-by: Javier Martinez Canillas <jav...@osg.samsung.com>
---

Changes since v1:
- None, new patch.

 arch/arm/boot/dts/exynos5800-peach-pi.dts | 2 --
 1 file changed, 2 deletions(-)

diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts 
b/arch/arm/boot/dts/exynos5800-peach-pi.dts
index ca3a467a585d..7b018e451880 100644
--- a/arch/arm/boot/dts/exynos5800-peach-pi.dts
+++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts
@@ -652,12 +652,10 @@
 _0 {
status = "okay";
num-slots = <1>;
-   broken-cd;
mmc-hs200-1_8v;
mmc-hs400-1_8v;
cap-mmc-highspeed;
non-removable;
-   card-detect-delay = <200>;
clock-frequency = <8>;
samsung,dw-mshc-ciu-div = <3>;
samsung,dw-mshc-sdr-timing = <0 4>;
-- 
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 v2 0/6] ARM: dts: Use correct CD properties for SDIO and eMMC in Snow and Peach

[Javier Martinez Canillas]

Hello,

The Exynos Chromebooks DTS don't use the correct card detection properties
since these were carried from the vendor tree that had a reason to do so.

There are two things that I noticed:

1) The Marvell WiFi SDIO is marked as broken-cd instead of non-removable:

This causes the device to be removed when the system enters into a suspend
state which leads to the following warning when the system is resumed:

[  181.944636] mmc2: error -2 during resume (card was removed?)

The rationale for using broken-cd is explained in downstream commit [0] and
was that using the non-removable property caused issues with the mwifiex
driver since the reset logic called the mmc_{remove,add}_host() functions.

But the reset logic in the mwifiex mainline driver has changed and this is
no longer the case so it's safe to use the non-removable property AFAICT.

2) The eMMC node has both broken-cd and non-removable but the MMC DT binding
doc (Documentation/devicetree/bindings/mmc/mmc.txt) mentions that only one
of these card detection properties should be used.

So this series change both the SDIO WiFi and eMMC device nodes in the Snow,
Peach Pi and Peach Pit boards DTS to use the non-removable property.

To test, I've cherry picked commit [1] from the vendor tree that adds a
debugfs entry to force a card reset and after the reset, the WiFi card still
works correctly:

$ echo 1 > /sys/kernel/debug/mwifiex/mlan0/reset

And also tested that both eMMC and WiFi are working correctly after a S2R.

The test were made on an Exynos5800 Peach Pi but I don't have access to a
Snow anymore so testing patch 3/6 and 6/6 on that board will be appreciated.

v1 of the series was [2] and this version fixes issues pointed out by Tomeu.

Changes since v1:
 - Replace broken-cd for non-removable in the correct mmc node for Snow.
 - Correct the card detetion properties for eMMC in Snow, Pit and Pi.
 - Also remove the card-detect-delay property when using non-removable.

[0]: 
https://chromium.googlesource.com/chromiumos/third_party/kernel/+/ad348e1e2381
[1]: 
https://chromium.googlesource.com/chromiumos/third_party/kernel/+/5995363523de
[2]: https://lkml.org/lkml/2015/10/15/294

Best regards,
Javier


Javier Martinez Canillas (6):
  ARM: dts: Mark SDIO as non-removable in exynos5800-peach-pi
  ARM: dts: Mark SDIO as non-removable in exynos5420-peach-pit
  ARM: dts: Mark SDIO as non-removable in exynos5250-snow-common
  ARM: dts: Remove broken-cd from eMMC node in exynos5800-peach-pi
  ARM: dts: Remove broken-cd from eMMC node in exynos5420-peach-pi
  ARM: dts: Mark eMMC as non-removable in exynos5250-snow-common

 arch/arm/boot/dts/exynos5250-snow-common.dtsi | 6 ++
 arch/arm/boot/dts/exynos5420-peach-pit.dts| 5 +
 arch/arm/boot/dts/exynos5800-peach-pi.dts | 5 +
 3 files changed, 4 insertions(+), 12 deletions(-)

-- 
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: [PATCH] dt-bindings: Correct the example for Exynos power domain clocks

[Javier Martinez Canillas]

[dropping my old email address from the cc list]

Hello Krzysztof,

On 10/14/2015 08:02 AM, Krzysztof Kozlowski wrote:
> Since commit 29e5eea06bc1 ("ARM: EXYNOS: Get current parent clock for
> power domain on/off") the "pclkN" names of "clock-names" property is not
> parsed any more. The bindings and driver were updated but the example
> was not. Fix the example now.
> 
> Signed-off-by: Krzysztof Kozlowski <k.kozlow...@samsung.com>
> ---
>  Documentation/devicetree/bindings/arm/exynos/power_domain.txt | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/arm/exynos/power_domain.txt 
> b/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
> index e151057d92f0..4e947372a693 100644
> --- a/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
> +++ b/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
> @@ -43,9 +43,8 @@ Example:
>   mfc_pd: power-domain@10044060 {
>   compatible = "samsung,exynos4210-pd";
>   reg = <0x10044060 0x20>;
> - clocks = < CLK_FIN_PLL>, < CLK_MOUT_SW_ACLK333>,
> - < CLK_MOUT_USER_ACLK333>;
> - clock-names = "oscclk", "pclk0", "clk0";
> + clocks = < CLK_FIN_PLL>, < CLK_MOUT_USER_ACLK333>;
> +     clock-names = "oscclk", "clk0";
>   #power-domain-cells = <0>;
>   };
>  
> 

Reviewed-by: Javier Martinez Canillas <jav...@osg.samsung.com>

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 3/4] ARM: multi_v7_defconfig: Enable Maxim 8997 family drivers

[Javier Martinez Canillas]

Hello Krzysztof,

On 10/13/2015 03:18 PM, Krzysztof Kozlowski wrote:
> W dniu 13.10.2015 o 17:36, Javier Martinez Canillas pisze:
>> Hello Krzysztof,
>>
>> On Tue, Oct 13, 2015 at 3:27 AM, Krzysztof Kozlowski
>> <k.kozlow...@samsung.com> wrote:
>>> Enable support for Maxim 8997 Multi Function Device present on Trats and
>>> Origen boards by toggling on drivers: main MFD, charger, haptic motor,
>>> regulator, LED and RTC.
>>>
>>> This allows to test and usage of these boards with multi_v7 config.
>>>
>>> Signed-off-by: Krzysztof Kozlowski <k.kozlow...@samsung.com>
>>> ---
>>
>> [snip]
>>
>>>  CONFIG_MFD_MAX77686=y
>>>  CONFIG_MFD_MAX77693=y
>>>  CONFIG_MFD_MAX8907=y
>>> +CONFIG_MFD_MAX8997=y
>>
>> Only slightly related with your patch but some of the MFD driver for
>> PMICs used in Exynos boards (like MAX77686) have a tristate Kconfig
>> symbol while others like this one have a boolean. Do you know if there
>> are any restrictions w.r.t build this as module or is just an
>> arbitrary decision? I'm asking since probably we should either allow
>> this to build as a module or convert the others to boolean.
> 
> First, thanks for reviewing the patches.
>

You are welcome.
 
> As for the question, I wasn't involved in development of these older
> drivers for older boards. I don't know their internals. AFAIK there were
> no specific restrictions, except the usual:
> 
> 1. Not all other drivers using resources provided by these, took the
> reference to given resource (e.g. get regulator).
> 
> 2. Not all consumer drivers supported deferred probe for given resource
> (e.g. regulator, clock), see: "regulators: max77693: register driver
> earlier to avoid deferred probe". In general USB gadget subsystem has
> this issue. Actually the mentioned max77693 regulator driver should be
> changed from tristate to built-in because of this.
> 
> I don't remember any other important issues so if you fix 1 and 2 then
> this can be probably safely switched to modules. Of course after testing.
>

Thanks for the explanation. I neither plan to fix these issues nor changing
these symbols to tristate since I don't have access to the hardware to test.

I asked mostly because I was curious and to know if I should change the MFD
drivers to boolean for the PMIC present in boards I have access, to make it
consistent. But as you said is the other way around, that it would be good
to allow these drivers to be built as a module.
 
> 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 4/4] ARM: multi_v7_defconfig: Enable Maxim 77693 LED and haptic drivers

[Javier Martinez Canillas]

Hello Krzysztof,

On 10/13/2015 03:27 AM, Krzysztof Kozlowski wrote:
> Enable support for:
> 1. Haptic motor driver on Trats2 board (Maxim 77693) and Note 4 (Maxim
>77843);
> 2. LED driver on Trats2 board (Maxim 77693).
> 
> Signed-off-by: Krzysztof Kozlowski <k.kozlow...@samsung.com>
> ---

Reviewed-by: Javier Martinez Canillas <jav...@osg.samsung.com>

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/4] ARM: exynos_defconfig: Enable Maxim 77693 LED and haptic drivers

[Javier Martinez Canillas]

Hello Krzysztof,

On 10/13/2015 03:27 AM, Krzysztof Kozlowski wrote:
> Enable support for:
> 1. Haptic motor driver on Trats2 board (Maxim 77693) and Note 4
>(Maxim 77843);
> 2. LED driver on Trats2 board (Maxim 77693).
> 
> Signed-off-by: Krzysztof Kozlowski <k.kozlow...@samsung.com>
> ---

Reviewed-by: Javier Martinez Canillas <jav...@osg.samsung.com>

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/4] ARM: exynos_defconfig: Enable Maxim 8997 family drivers

[Javier Martinez Canillas]

Hello Krzysztof,

On 10/13/2015 03:27 AM, Krzysztof Kozlowski wrote:
> Enable support for Maxim 8997 Multi Functional Device present on Trats and
> Origen boards by toggling on drivers: charger, haptic motor,
> LED, RTC and extcon.
> 
> This allows to test and usage of these boards with exynos config.
> 
> Signed-off-by: Krzysztof Kozlowski <k.kozlow...@samsung.com>
> ---

Patch looks good to me.

Reviewed-by: Javier Martinez Canillas <jav...@osg.samsung.com>

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