Re: [GIT PULL] ARM: dts: Exynos improvements for 4.4-2

[Kukjin Kim]

On 10/06/15 10:54, Krzysztof Kozlowski wrote:
> Dear Kukjin,
> 
> This is an updated pull request with DTS related changes for 4.4.
> 
> Description along with a tag.
> You can find them also on the lists with my reviewed-by.
> 
> Best regards,
> Krzysztof
> 
> 
> The following changes since commit 6ff33f3902c3b1c5d0db6b1e2c70b6d76fba357f:
> 
>   Linux 4.3-rc1 (2015-09-12 16:35:56 -0700)
> 
> are available in the git repository at:
> 
>   https://github.com/krzk/linux.git tags/samsung-dt-4.4-2
> 
> for you to fetch changes up to c21dbcfefc9dc9abc42971dc1f2681b6a8677c3c:
> 
>   ARM: dts: Remove regulator-compatible usage in exynos4412-trats2 
> (2015-10-06 10:47:13 +0900)
> 
> 
> Device Tree improvements for Exynos based boards (updated pull request):
> 1. Enable DMA on Exynos4 serial ports. This old patch uncovered
>a number of other issues in dmaengine and samsung serial driver.
>All of known issues are resolved so finally enable the DMA for UART.
> 2. Fix incorrect location of display-timings node (FIMD->DP node)
>on Arndale, SMDK5250 and SMDK5240 boards.
> 3. Minor cleanups.
> 
> 
> Javier Martinez Canillas (1):
>   ARM: dts: Remove regulator-compatible usage in exynos4412-trats2
> 
> Robert Baldyga (1):
>   ARM: dts: Add DMA support for serial ports in exynos4
> 
> Sean Paul (1):
>   ARM: dts: Move display-timings node from fimd to dp in 
> exynos5250-arndale, smdk5250 and smdk5420
> 
> Tobias Jakobi (2):
>   ARM: dts: Remove redundant pinctrl settings in exynos4412-odroid
>   ARM: dts: Unify voltage regulator style in exynos4412-odroid
> 
> Vladimir Zapolskiy (1):
>   ARM: dts: Fix cpu compatible value for s3c2416
> 
>  arch/arm/boot/dts/exynos4.dtsi  |   8 ++
>  arch/arm/boot/dts/exynos4412-odroid-common.dtsi |  12 +--
>  arch/arm/boot/dts/exynos4412-trats2.dts | 105 
> 
>  arch/arm/boot/dts/exynos5250-arndale.dts|   8 +-
>  arch/arm/boot/dts/exynos5250-smdk5250.dts   |  16 ++--
>  arch/arm/boot/dts/exynos5420-smdk5420.dts   |   7 +-
>  arch/arm/boot/dts/s3c2416.dtsi  |   2 +-
>  7 files changed, 62 insertions(+), 96 deletions(-)

Pulled, thanks.

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

Re: [PATCH v3 4/4] ARM: dts: Enable EC vboot context support on Peach boards

[Kukjin Kim]

On 09/21/15 22:38, Emilio López wrote:
> The Peach boards use the EC to store the vboot context information,
> so add the corresponding properties on the EC node to indicate so.
> 
> Reviewed-by: Krzysztof Kozlowski 
> Acked-by: Javier Martinez Canillas 
> Signed-off-by: Emilio López 
> ---
> 
> Changes from v1:
>  - none
> 
> Changes from v2:
>  - collect tags from Krzysztof & Javier
> 
>  arch/arm/boot/dts/exynos5420-peach-pit.dts | 1 +
>  arch/arm/boot/dts/exynos5800-peach-pi.dts  | 1 +
>  2 files changed, 2 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts 
> b/arch/arm/boot/dts/exynos5420-peach-pit.dts
> index 8f4d76c..ac02fb4 100644
> --- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
> +++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
> @@ -935,6 +935,7 @@
>   pinctrl-0 = <_spi_cs _irq>;
>   reg = <0>;
>   spi-max-frequency = <3125000>;
> + google,has-vbc-nvram;
>  
>   controller-data {
>   samsung,spi-feedback-delay = <1>;
> diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts 
> b/arch/arm/boot/dts/exynos5800-peach-pi.dts
> index 7d5b386..b60dec0 100644
> --- a/arch/arm/boot/dts/exynos5800-peach-pi.dts
> +++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts
> @@ -898,6 +898,7 @@
>   pinctrl-0 = <_spi_cs _irq>;
>   reg = <0>;
>   spi-max-frequency = <3125000>;
> + google,has-vbc-nvram;
>  
>   controller-data {
>   samsung,spi-feedback-delay = <1>;

Applied, thanks.

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

Re: [PATCH 1/4] sysfs: Support is_visible() on binary attributes

[Olof Johansson]

On Sun, Oct 04, 2015 at 07:33:34PM +0100, Greg KH wrote:
> On Mon, Sep 21, 2015 at 10:38:20AM -0300, Emilio L?pez wrote:
> > According to the sysfs header file:
> > 
> > "The returned value will replace static permissions defined in
> >  struct attribute or struct bin_attribute."
> > 
> > but this isn't the case, as is_visible is only called on struct attribute
> > only. This patch introduces a new is_bin_visible() function to implement
> > the same functionality for binary attributes, and updates documentation
> > accordingly.
> > 
> > Note that to keep functionality and code similar to that of normal
> > attributes, the mode is now checked as well to ensure it contains only
> > read/write permissions or SYSFS_PREALLOC.
> > 
> > Reviewed-by: Guenter Roeck 
> > Signed-off-by: Emilio L?pez 
> 
> As this should probably go through the "platform drivers" maintainer,
> I'll just give you this:
> 
> Acked-by: Greg Kroah-Hartman 
> 
> So it can go through their tree and not require me to just take this
> one.

Thanks, applied to the chrome-platform tree now.


-Olof
--
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 3/4] platform/chrome: Support reading/writing the vboot context

[Olof Johansson]

On Mon, Sep 21, 2015 at 10:38:22AM -0300, Emilio L??pez wrote:
> Some EC implementations include a small nvram space used to store
> verified boot context data. This patch offers a way to expose this
> data to userspace.
> 
> Reviewed-by: Javier Martinez Canillas 
> Signed-off-by: Emilio L??pez 

Applied, thanks!


-Olof
--
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 0/5] ARM: dts: Use GPIO constants for flags cells in exynos boards

[Kukjin Kim]

On 10/07/15 22:14, Javier Martinez Canillas wrote:
> Hello,
> 
> This series contains trivial patches that use the GPIO constants
> defined in include/dt-bindings/gpio/gpio.h to express GPIO polarity
> instead of numeric values.
> 
> There is no functional change and the compiled dtbs are unchanged but
> is a good practice to use the defined macros instead of magic numbers
> since that makes the DTS more readable.
> 
> Since the changes are trivial, I thought that split the changes per
> board DTS would create an unnecessary churn but a single patch would
> maybe be harder to review so I decided that split it by SoC family
> would be a good trade off.
> 
> Please let me know if you prefer another approach.
> 
> Best regards,
> Javier
> 
> 
> Javier Martinez Canillas (5):
>   ARM: dts: Use GPIO constants for flags cells in exynos3250 boards
>   ARM: dts: Use GPIO constants for flags cells in exynos4120 boards
>   ARM: dts: Use GPIO constants for flags cells in exynos4412 boards
>   ARM: dts: Use GPIO constants for flags cells in exynos5420/5422/5800
> boards
>   ARM: dts: Use GPIO constants for flags cells in exynos5440 boards
> 
>  arch/arm/boot/dts/exynos3250-monk.dts  |  8 ++---
>  arch/arm/boot/dts/exynos3250-rinato.dts| 10 +++---
>  arch/arm/boot/dts/exynos4210-origen.dts| 15 
>  arch/arm/boot/dts/exynos4210-smdkv310.dts  |  3 +-
>  arch/arm/boot/dts/exynos4210-trats.dts | 29 +++
>  arch/arm/boot/dts/exynos4210-universal_c210.dts| 42 
> +++---
>  arch/arm/boot/dts/exynos4412-odroid-common.dtsi| 15 
>  arch/arm/boot/dts/exynos4412-odroidu3.dts  |  2 +-
>  arch/arm/boot/dts/exynos4412-odroidx.dts   |  8 ++---
>  arch/arm/boot/dts/exynos4412-origen.dts| 15 
>  arch/arm/boot/dts/exynos4412-tiny4412.dts  |  9 ++---
>  arch/arm/boot/dts/exynos4412-trats2.dts| 34 +-
>  arch/arm/boot/dts/exynos5420-arndale-octa.dts  |  3 +-
>  arch/arm/boot/dts/exynos5420-peach-pit.dts |  8 ++---
>  arch/arm/boot/dts/exynos5420-smdk5420.dts  |  7 ++--
>  arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi |  4 +--
>  arch/arm/boot/dts/exynos5440-ssdk5440.dts  |  5 +--
>  arch/arm/boot/dts/exynos5800-peach-pi.dts  |  8 ++---
>  18 files changed, 118 insertions(+), 107 deletions(-)
> 
Applied this whole series, thanks.

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

Re: [PATCH v5 0/17] Add Analogix Core Display Port Driver

[Yakir Yang]

Hi all,

Friendly ping.   :)


Best regards,
- Yakir


On 09/22/2015 03:20 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 :)

This time I create this version on linux-next branch (tag is next-20150918),
and also applied this version to Heiko github eDP branch to verify the function.
(https://github.com/mmind/linux-rockchip/tree/tmp/edp-with-veyron)
Glad to say my chromebook "cnm,n116bgeea2" eDP panel just lighted rightly on
Heiko branch. And after back port this series to chromeos-3.14 tree, my rk3288
SDK board still can light my 2K DisplayPort monitor. So this time would be okay
on mainline kernel and chromeos-3.14 tree. ;)

Due to no Exynos board in my side, so I haven't verified the eDP function on
samsung platform, I only ensure that there are no obvious compiled error. Any
help would be greatly appreciated. :)

Thanks,
- Yakir

Changes in v5:
- Correct the check condition of gpio_is_valid when driver try to get
   the "hpd-gpios" DT propery. (Heiko)
- Move the platform attach callback in the front of core driver bridge
   attch function. Cause once platform failed at attach, core driver should
   still failed, so no need to init connector before platform attached 
(Krzysztof)
- Keep code style no changes with the previous exynos_dp_code.c in this
   patch, and update commit message about the new export symbol (Krzysztof)
- Gather the device type patch (v4 11/16) into this one. (Krzysztof)
- leave out the connector registration to analogix platform driver. (Thierry)
- Resequence this patch after analogix_dp driver have been split
   from exynos_dp code, and rephrase reasonable commit message, and
   remove some controversial style (Krzysztof)
 -  analogix_dp_write_byte_to_dpcd(
 -  dp, DP_TEST_RESPONSE,
 +  analogix_dp_write_byte_to_dpcd(dp,
 +  DP_TEST_RESPONSE,
DP_TEST_EDID_CHECKSUM_WRITE);
- Switch video timing type to "u32", so driver could use "of_property_read_u32"
   to get the backword timing values. Krzysztof suggest me that driver could use
   the "of_property_read_bool" to get backword timing values, but that interfacs
   would modify the original drm_display_mode timing directly (whether those
   properties exists or not).
- Correct the misspell in commit message. (Krzysztof)
- Remove the empty line at the end of document, and correct the endpoint
   numbers in the example DT node, and remove the regulator iomux setting
   in driver code while using the pinctl in devicetree instead. (Heiko)
- Add device type declared, cause the previous "platform device type
   support (v4 11/16)" already merge into (v5 02/14).
- Implement connector registration code. (Thierry)
- Split binding doc's from driver changes. (Rob)
- Add eDP hotplug pinctrl property. (Heiko)
- Remove "reg" DT property, cause driver could poweron/poweroff phy via
   the exist "grf" syscon already. And rename the example DT node from
   "edp_phy: phy@ff770274" to "edp_phy: edp-phy" directly. (Heiko)
- Add deivce_node at the front of driver, update phy_ops type from "static
   struct" to "static const struct". And correct the input paramters of
   devm_phy_create() interfaces. (Heiko)
- Split binding doc's from driver changes. (Rob)
- Update the rockchip,grf explain in document, and correct the clock required
   elemets in document. (Rob & Heiko)
- Fix compiled error (Heiko)
- Using the connector display info message to configure eDP driver input
   video mode, but hard code CRTC video output mode to RGBaaa.

Changes in v4:
- Update "analogix,hpd-gpios" to "hpd-gpios" DT propery. (Rob)
- Rename "analogix_dp-exynos.c" file name to "exynos_dp.c" (Jingoo)
- Create a separate folder for analogix code in bridge/ (Archit)
- Update commit message more readable. (Jingoo)
- Adjust the order from 05 to 04
- Provide backword compatibility with samsung. (Krzysztof)
- Split all DTS changes, and provide backward compatibility. Mark old
   properties as deprecated but still support them. (Krzysztof)
- Update "analogix,hpd-gpio" to "hpd-gpios" prop name. (Rob)
- Deprecated some properties which could parsed from Edid/Mode/DPCD. (Thierry)
 "analogix,color-space" & "analogix,color-depth"   &
 "analogix,link-rate"   & "analogix,lane-count"&
 "analogix,ycbcr-coeff" & "analogix,dynamic-range" &
 "vsync-active-high"& "hsync-active-high"  & "interlaces"
- Separate all DTS changes to a separate patch. (Krzysztof)
- Remove some deprecated DT properties in rockchip dp document.
- Add commit message, and remove the redundant rockchip_dp_phy_init()
   function, 

Re: [PATCH v5 0/17] Add Analogix Core Display Port Driver

[Yakir Yang]

Hi Javier,

On 10/07/2015 04:46 PM, Javier Martinez Canillas wrote:

Hello Yakir,

On 10/07/2015 08:25 AM, Yakir Yang wrote:

Hi all,

Friendly ping.   :)


Best regards,
- Yakir



Do you have a tree that I can use to test these patches?


Wow, thanks a lot, I do have a tree on github 
[https://github.com/yakir-Yang/linux/tree/analogix_dp],

crossing my finger, wish things works..;)

Thanks,
- Yakir



Best regards,



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

Re: [PATCH v5 0/17] Add Analogix Core Display Port Driver

[Javier Martinez Canillas]

Hello Yakir,

On 10/07/2015 08:25 AM, Yakir Yang wrote:
> Hi all,
> 
> Friendly ping.   :)
> 
> 
> Best regards,
> - Yakir
> 
> 

Do you have a tree that I can use to test 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] ARM: dts: exynos4412-odroid: unify voltage regulator style

[Krzysztof Kozlowski]

On 07.10.2015 08:26, Tobias Jakobi wrote:
> Gentle ping!

Both patches are now in Kukjin's tree.

Best regards,
Krzysztof

> 
> - Tobias
> 
> Tobias Jakobi wrote:
>> Use 'ldoN_reg: LDON' syntax and drop the deprecated
>> 'regulator-compatible' property.
>>
>> Signed-off-by: Tobias Jakobi 
>> ---
>>  arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 6 ++
>>  1 file changed, 2 insertions(+), 4 deletions(-)

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

[PATCH 1/5] thermal: exynos: Fix unbalanced regulator disable on probe failure

[Krzysztof Kozlowski]

During probe if the regulator could not be enabled, the error exit path
would still disable it. This could lead to unbalanced counter of
regulator enable/disable.

The patch moves code for getting and enabling the regulator from
exynos_map_dt_data() to probe function because it is really not a part
of getting Device Tree properties.

Signed-off-by: Krzysztof Kozlowski 
Fixes: 5f09a5cbd14a ("thermal: exynos: Disable the regulator on probe failure")
Cc: 
---
 drivers/thermal/samsung/exynos_tmu.c | 34 +-
 1 file changed, 17 insertions(+), 17 deletions(-)

diff --git a/drivers/thermal/samsung/exynos_tmu.c 
b/drivers/thermal/samsung/exynos_tmu.c
index 0bae8cc6c23a..23f4320f8ef7 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -1168,27 +1168,10 @@ static int exynos_map_dt_data(struct platform_device 
*pdev)
struct exynos_tmu_data *data = platform_get_drvdata(pdev);
struct exynos_tmu_platform_data *pdata;
struct resource res;
-   int ret;
 
if (!data || !pdev->dev.of_node)
return -ENODEV;
 
-   /*
-* Try enabling the regulator if found
-* TODO: Add regulator as an SOC feature, so that regulator enable
-* is a compulsory call.
-*/
-   data->regulator = devm_regulator_get(>dev, "vtmu");
-   if (!IS_ERR(data->regulator)) {
-   ret = regulator_enable(data->regulator);
-   if (ret) {
-   dev_err(>dev, "failed to enable vtmu\n");
-   return ret;
-   }
-   } else {
-   dev_info(>dev, "Regulator node (vtmu) not found\n");
-   }
-
data->id = of_alias_get_id(pdev->dev.of_node, "tmuctrl");
if (data->id < 0)
data->id = 0;
@@ -1312,6 +1295,23 @@ static int exynos_tmu_probe(struct platform_device *pdev)
pr_err("thermal: tz: %p ERROR\n", data->tzd);
return PTR_ERR(data->tzd);
}
+
+   /*
+* Try enabling the regulator if found
+* TODO: Add regulator as an SOC feature, so that regulator enable
+* is a compulsory call.
+*/
+   data->regulator = devm_regulator_get(>dev, "vtmu");
+   if (!IS_ERR(data->regulator)) {
+   ret = regulator_enable(data->regulator);
+   if (ret) {
+   dev_err(>dev, "failed to enable vtmu\n");
+   return ret;
+   }
+   } else {
+   dev_info(>dev, "Regulator node (vtmu) not found\n");
+   }
+
ret = exynos_map_dt_data(pdev);
if (ret)
goto err_sensor;
-- 
1.9.1

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

[PATCH 2/5] thermal: exynos: Fix first temperature read after registering sensor

[Krzysztof Kozlowski]

Thermal core could not read the temperature after registering the
thermal sensor with thermal_zone_of_sensor_register() because the driver
was not yet initialized.

The call trace looked like:
exynos_tmu_probe()
thermal_zone_of_sensor_register()
of_thermal_set_mode()
thermal_zone_device_update()
exynos_get_temp()
if (!data->tmu_read) return -EINVAL;
exynos_map_dt_data()
data->tmu_read = ...

This produced an error in dmesg:
thermal thermal_zone0: failed to read out thermal zone (-22)

Register the thermal_zone_device later, after parsing Device Tree and
enabling necessary clocks, but before calling exynos_tmu_initialize()
which uses the registered thermal_zone_device.

Signed-off-by: Krzysztof Kozlowski 
Fixes: 3b6a1a805f34 ("thermal: samsung: core: Exynos TMU rework to use device 
tree for configuration")
---
 drivers/thermal/samsung/exynos_tmu.c | 27 +--
 1 file changed, 17 insertions(+), 10 deletions(-)

diff --git a/drivers/thermal/samsung/exynos_tmu.c 
b/drivers/thermal/samsung/exynos_tmu.c
index 23f4320f8ef7..bc71a61f0c4a 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -1289,13 +1289,6 @@ static int exynos_tmu_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, data);
mutex_init(>lock);
 
-   data->tzd = thermal_zone_of_sensor_register(>dev, 0, data,
-   _sensor_ops);
-   if (IS_ERR(data->tzd)) {
-   pr_err("thermal: tz: %p ERROR\n", data->tzd);
-   return PTR_ERR(data->tzd);
-   }
-
/*
 * Try enabling the regulator if found
 * TODO: Add regulator as an SOC feature, so that regulator enable
@@ -1365,21 +1358,36 @@ static int exynos_tmu_probe(struct platform_device 
*pdev)
break;
};
 
+   /*
+* data->tzd must be registered before calling exynos_tmu_initialize(),
+* requesting irq and calling exynos_tmu_control().
+*/
+   data->tzd = thermal_zone_of_sensor_register(>dev, 0, data,
+   _sensor_ops);
+   if (IS_ERR(data->tzd)) {
+   ret = PTR_ERR(data->tzd);
+   dev_err(>dev, "Failed to register sensor: %d\n", ret);
+   goto err_sclk;
+   }
+
ret = exynos_tmu_initialize(pdev);
if (ret) {
dev_err(>dev, "Failed to initialize TMU\n");
-   goto err_sclk;
+   goto err_thermal;
}
 
ret = devm_request_irq(>dev, data->irq, exynos_tmu_irq,
IRQF_TRIGGER_RISING | IRQF_SHARED, dev_name(>dev), data);
if (ret) {
dev_err(>dev, "Failed to request irq: %d\n", data->irq);
-   goto err_sclk;
+   goto err_thermal;
}
 
exynos_tmu_control(pdev, true);
return 0;
+
+err_thermal:
+   thermal_zone_of_sensor_unregister(>dev, data->tzd);
 err_sclk:
clk_disable_unprepare(data->sclk);
 err_clk:
@@ -1390,7 +1398,6 @@ err_clk_sec:
 err_sensor:
if (!IS_ERR_OR_NULL(data->regulator))
regulator_disable(data->regulator);
-   thermal_zone_of_sensor_unregister(>dev, data->tzd);
 
return ret;
 }
-- 
1.9.1

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

[PATCH 3/5] thermal: exynos: Use IS_ERR() because regulator cannot be NULL

[Krzysztof Kozlowski]

The NULL check in probe's error path is not needed because in that time
the regulator cannot be NULL (regulator_get() returns valid pointer or
ERR_PTR).

Signed-off-by: Krzysztof Kozlowski 
---
 drivers/thermal/samsung/exynos_tmu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/thermal/samsung/exynos_tmu.c 
b/drivers/thermal/samsung/exynos_tmu.c
index bc71a61f0c4a..eac6aebf82f3 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -1396,7 +1396,7 @@ err_clk_sec:
if (!IS_ERR(data->clk_sec))
clk_unprepare(data->clk_sec);
 err_sensor:
-   if (!IS_ERR_OR_NULL(data->regulator))
+   if (!IS_ERR(data->regulator))
regulator_disable(data->regulator);
 
return ret;
-- 
1.9.1

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

[PATCH 4/5] thermal: exynos: Remove unneeded semicolon

[Krzysztof Kozlowski]

Remove semicolons after switch statement.

Signed-off-by: Krzysztof Kozlowski 
---
 drivers/thermal/samsung/exynos_tmu.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/thermal/samsung/exynos_tmu.c 
b/drivers/thermal/samsung/exynos_tmu.c
index eac6aebf82f3..1af7ea8dda71 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -548,7 +548,7 @@ static int exynos5433_tmu_initialize(struct platform_device 
*pdev)
default:
pdata->cal_type = TYPE_ONE_POINT_TRIMMING;
break;
-   };
+   }
 
dev_info(>dev, "Calibration type is %d-point calibration\n",
cal_type ?  2 : 1);
@@ -1356,7 +1356,7 @@ static int exynos_tmu_probe(struct platform_device *pdev)
break;
default:
break;
-   };
+   }
 
/*
 * data->tzd must be registered before calling exynos_tmu_initialize(),
-- 
1.9.1

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

[PATCH 5/5] thermal: exynos: Directly return 0 instead of using local ret variable

[Krzysztof Kozlowski]

The 'ret' variable in exynos5440_tmu_initialize() is initialized to 0
and returned as is. Replace it with direct return statement. This also
fixes coccinelle warning:
drivers/thermal/samsung/exynos_tmu.c:611:5-8: Unneeded variable: "ret". Return 
"0" on line 654

Signed-off-by: Krzysztof Kozlowski 
---
 drivers/thermal/samsung/exynos_tmu.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/thermal/samsung/exynos_tmu.c 
b/drivers/thermal/samsung/exynos_tmu.c
index 1af7ea8dda71..f340e6edcb49 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -608,7 +608,7 @@ static int exynos5440_tmu_initialize(struct platform_device 
*pdev)
 {
struct exynos_tmu_data *data = platform_get_drvdata(pdev);
unsigned int trim_info = 0, con, rising_threshold;
-   int ret = 0, threshold_code;
+   int threshold_code;
int crit_temp = 0;
 
/*
@@ -651,7 +651,8 @@ static int exynos5440_tmu_initialize(struct platform_device 
*pdev)
/* Clear the PMIN in the common TMU register */
if (!data->id)
writel(0, data->base_second + EXYNOS5440_TMU_PMIN);
-   return ret;
+
+   return 0;
 }
 
 static int exynos7_tmu_initialize(struct platform_device *pdev)
-- 
1.9.1

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

Re: [PATCH v5 0/17] Add Analogix Core Display Port Driver

[Yakir Yang]

Hi Javier,

On 10/07/2015 07:25 PM, Javier Martinez Canillas wrote:

Hello Yakir,

On 10/07/2015 01:05 PM, Yakir Yang wrote:

Hi Javier,

On 10/07/2015 05:26 PM, Javier Martinez Canillas wrote:

Hello Yakir,

On 10/07/2015 11:02 AM, Yakir Yang wrote:

Hi Javier,

On 10/07/2015 04:46 PM, Javier Martinez Canillas wrote:

Hello Yakir,

On 10/07/2015 08:25 AM, Yakir Yang wrote:

Hi all,

Friendly ping.   :)


Best regards,
- Yakir



Do you have a tree that I can use to test these patches?

Wow, thanks a lot, I do have a tree on github 
[https://github.com/yakir-Yang/linux/tree/analogix_dp],
crossing my finger, wish things works..;)


I tried your analogix_dp branch on an Exynos5800 Peach Pi Chromebook
but the machine didn't boot. Unfortunately I need to do some soldering
to have a serial console on this board so don't have a kernel boot log.

I'll let you know if I can get more info about this issue.

Whoops, sorry for the failed, much appreciated for your works.

Besides, I thought maybe I can find a Peach Pit Chromebook in my side,
I remember that some of our guys have brought one, but previously I
thought that mainline kernel wouldn't run on Peach Pit directly.


Great, mainline works correctly on all Exynos based Chromebooks.


Maybe you can email me the method the run mainline kernel on Peach
Pit, so I can debug the analogix_dp driver at the same time, that would
be great.

I wrote a little blog post explaining how to run mainline on these boards:

http://blogs.s-osg.org/install-linux-mainline-kernel-distro-exynos-chromebooks/

That explains the simplest setup though so if you need a different one
(i.e: chain loading a non verified u-boot) or if you have any questions,
feel free to contact me in private and I can help you with the setup.



Ah, thanks, gonna to step-by-step.

- Yakir


Also, there is Kconfig recursive dependency that you may want to fix:

$ make exynos_defconfig
drivers/video/fbdev/Kconfig:5:error: recursive dependency detected!
drivers/video/fbdev/Kconfig:5: symbol FB is selected by DRM_KMS_FB_HELPER
drivers/gpu/drm/Kconfig:34: symbol DRM_KMS_FB_HELPER depends on DRM_KMS_HELPER
drivers/gpu/drm/Kconfig:28: symbol DRM_KMS_HELPER is selected by DRM_ANALOGIX_DP
drivers/gpu/drm/bridge/analogix/Kconfig:1: symbol DRM_ANALOGIX_DP is selected 
by DRM_EXYNOS_DP
drivers/gpu/drm/exynos/Kconfig:57: symbol DRM_EXYNOS_DP depends on 
DRM_EXYNOS_FIMD
drivers/gpu/drm/exynos/Kconfig:19: symbol DRM_EXYNOS_FIMD depends on FB_S3C
drivers/video/fbdev/Kconfig:2023: symbol FB_S3C depends on FB
   

Yeah, recursive dependency detected, guess I should remove the
"DRM_KMS_HELPER" from bridge analogix_dp Kconfig file, thanks
for your remind.

--- a/drivers/gpu/drm/bridge/analogix/Kconfig
+++ b/drivers/gpu/drm/bridge/analogix/Kconfig
@@ -1,4 +1,3 @@
  config DRM_ANALOGIX_DP
 tristate
 depends on DRM
-   select DRM_KMS_HELPER



That fixes the recursive dependency issue indeed. Thanks.


Thanks,
- Yakir

Best regards,



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

Re: [PATCH 5/6] ARM: s3c64xx: hmt: Use PWM lookup table

[Krzysztof Kozlowski]

On 08.10.2015 00:37, Thierry Reding wrote:
> On Wed, Oct 07, 2015 at 10:37:42AM +0900, Krzysztof Kozlowski wrote:
>> On 05.10.2015 21:47, Thierry Reding wrote:
>>> Use a PWM lookup table to provide the PWM to the pwm-backlight device.
>>> The driver has a legacy code path that is required only because boards
>>> still use the legacy method of requesting PWMs by global ID. Replacing
>>> these usages allows that legacy fallback to be removed.
>>>
>>> Cc: Kukjin Kim 
>>> Cc: Krzysztof Kozlowski 
>>> Signed-off-by: Thierry Reding 
>>> ---
>>>  arch/arm/mach-s3c64xx/mach-hmt.c | 9 +++--
>>>  1 file changed, 7 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/arch/arm/mach-s3c64xx/mach-hmt.c 
>>> b/arch/arm/mach-s3c64xx/mach-hmt.c
>>> index e4b087c58ee6..816b39d1e6d1 100644
>>> --- a/arch/arm/mach-s3c64xx/mach-hmt.c
>>> +++ b/arch/arm/mach-s3c64xx/mach-hmt.c
>>> @@ -19,6 +19,7 @@
>>>  #include 
>>>  #include 
>>>  #include 
>>> +#include 
>>>  #include 
>>>  #include 
>>>  #include 
>>> @@ -73,6 +74,11 @@ static struct s3c2410_uartcfg hmt_uartcfgs[] __initdata 
>>> = {
>>> },
>>>  };
>>>  
>>> +static struct pwm_lookup hmt_pwm_lookup[] = {
>>> +   PWM_LOOKUP("samsung-pwm", 1, "pwm-backlight.0", NULL,
>>
>> Same questions as in patch 2 - why suffix ".0" for "pwm-backlight"?
> 
> For the same reason that I explained in patch 2. Not sure if the .id = 0
> was really supposed to be. For most devices it would probably make sense
> to initialize it to -1 because they typically only have a single
> backlight. But given that userspace might be using the name to control
> the backlight via sysfs it's probably not a good idea to go and change
> that.

Thanks for explanation.

Reviewed-by: Krzysztof Kozlowski 

Best regards,
Krzysztof

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

Re: [PATCH 3/6] ARM: s3c64xx: smdk6410: Use PWM lookup table

[Krzysztof Kozlowski]

On 05.10.2015 21:47, Thierry Reding wrote:
> Use a PWM lookup table to provide the PWM to the pwm-backlight device.
> The driver has a legacy code path that is required only because boards
> still use the legacy method of requesting PWMs by global ID. Replacing
> these usages allows that legacy fallback to be removed.
> 
> Cc: Kukjin Kim 
> Cc: Krzysztof Kozlowski 
> Signed-off-by: Thierry Reding 
> ---
>  arch/arm/mach-s3c64xx/dev-backlight.c | 4 
>  arch/arm/mach-s3c64xx/mach-smdk6410.c | 8 +++-
>  2 files changed, 7 insertions(+), 5 deletions(-)

Reviewed-by: Krzysztof Kozlowski 

Best regards,
Krzysztof

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

Re: [PATCH 2/6] ARM: s3c24xx: rx1950: Use PWM lookup table

[Krzysztof Kozlowski]

On 08.10.2015 00:31, Thierry Reding wrote:
> On Wed, Oct 07, 2015 at 10:35:54AM +0900, Krzysztof Kozlowski wrote:
>> On 05.10.2015 21:47, Thierry Reding wrote:
>>> Use a PWM lookup table to provide the PWM to the pwm-backlight device.
>>> The driver has a legacy code path that is required only because boards
>>> still use the legacy method of requesting PWMs by global ID. Replacing
>>> these usages allows that legacy fallback to be removed.
>>>
>>> Cc: Kukjin Kim 
>>> Cc: Krzysztof Kozlowski 
>>> Signed-off-by: Thierry Reding 
>>> ---
>>>  arch/arm/mach-s3c24xx/mach-rx1950.c | 8 ++--
>>>  1 file changed, 6 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/arch/arm/mach-s3c24xx/mach-rx1950.c 
>>> b/arch/arm/mach-s3c24xx/mach-rx1950.c
>>> index 1d35ff375a01..774c982a7b7e 100644
>>> --- a/arch/arm/mach-s3c24xx/mach-rx1950.c
>>> +++ b/arch/arm/mach-s3c24xx/mach-rx1950.c
>>> @@ -375,6 +375,11 @@ static struct s3c2410fb_mach_info rx1950_lcd_cfg = {
>>>  
>>>  };
>>>  
>>> +static struct pwm_lookup rx1950_pwm_lookup[] = {
>>> +   PWM_LOOKUP("samsung-pwm", 0, "pwm-backlight.0", NULL, 48000,
>>
>> Why the dev_id is "pwm-backlight.0"? Created platform device name is
>> "pwm-backlight".
> 
> "pwm-backlight" is only the base name. The platform bus code will use
> the platform_device.id field and append it to the name as . unless
> it is -1 in which case it will be skipped. So in the rx1950_backlight
> device the .id field isn't initialized at all, so it will be zeroed
> out and hence the device name will become "pwm-backlight.0".

Right, I missed the difference in device id.

The patch is fine:

Reviewed-by: Krzysztof Kozlowski 

Best regards,
Krzysztof

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

[PATCHv3 2/2] ARM: multi_v7_defconfig: Enable rtl8152 ethernet driver for Odroid-XU4

[Anand Moon]

Odroid XU4 has a RTL8153-CG gigabit Ethernet adapter, connected over
USB 3.0.

Signed-off-by: Anand Moon 
Reviewed-by: Krzysztof Kozlowski 

---
Changes: Fixed the commit message thanks to Krzysztof Kozlowski
 Added reviewed by Krzysztof Kozlowski
---
 arch/arm/configs/multi_v7_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/multi_v7_defconfig 
b/arch/arm/configs/multi_v7_defconfig
index 03deb7f..009d714 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -221,6 +221,7 @@ CONFIG_BROADCOM_PHY=y
 CONFIG_ICPLUS_PHY=y
 CONFIG_MICREL_PHY=y
 CONFIG_USB_PEGASUS=y
+CONFIG_USB_RTL8152=y
 CONFIG_USB_USBNET=y
 CONFIG_USB_NET_SMSC75XX=y
 CONFIG_USB_NET_SMSC95XX=y
-- 
2.1.4

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

[PATCHv3 1/2] ARM: exynos_defconfig: Enable rtl8152 ethernet driver for Odroid-XU4

[Anand Moon]

Odroid XU4 has a RTL8153-CG gigabit Ethernet adapter, connected over
USB 3.0.

Signed-off-by: Anand Moon 
Reviewed-by: Krzysztof Kozlowski 

---
Changes: Fixed the commit message thanks to Krzysztof Kozlowski
 Added reviewed by Krzysztof Kozlowski
---
 arch/arm/configs/exynos_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/exynos_defconfig 
b/arch/arm/configs/exynos_defconfig
index 1ff2bfa..5d1937b 100644
--- a/arch/arm/configs/exynos_defconfig
+++ b/arch/arm/configs/exynos_defconfig
@@ -61,6 +61,7 @@ CONFIG_BLK_DEV_DM=y
 CONFIG_DM_CRYPT=m
 CONFIG_NETDEVICES=y
 CONFIG_SMSC911X=y
+CONFIG_USB_RTL8152=y
 CONFIG_USB_USBNET=y
 CONFIG_USB_NET_SMSC75XX=y
 CONFIG_USB_NET_SMSC95XX=y
-- 
2.1.4

--
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 6/6] ARM: s3c64xx: smartq: Use PWM lookup table

[Krzysztof Kozlowski]

On 05.10.2015 21:47, Thierry Reding wrote:
> Use a PWM lookup table to provide the PWM to the pwm-backlight device.
> The driver has a legacy code path that is required only because boards
> still use the legacy method of requesting PWMs by global ID. Replacing
> these usages allows that legacy fallback to be removed.
> 
> Cc: Kukjin Kim 
> Cc: Krzysztof Kozlowski 
> Signed-off-by: Thierry Reding 
> ---
>  arch/arm/mach-s3c64xx/mach-smartq.c | 9 +++--
>  1 file changed, 7 insertions(+), 2 deletions(-)

Reviewed-by: Krzysztof Kozlowski 

Best regards,
Krzysztof

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

[PATCH v3 2/2] s5p-mfc: use MFC_BUF_FLAG_EOS to identify last buffers in decoder capture queue

[Andrzej Hajda]

MFC driver never delivered EOS event to apps feeding constantly its capture
buffer with fresh buffers. The patch fixes it by marking last buffers
returned by MFC with MFC_BUF_FLAG_EOS flag and firing EOS event on
de-queuing such buffers.

Signed-off-by: Andrzej Hajda 
---
Hi Kamil,

Commit message fixed.

Regards
Andrzej
---
 drivers/media/platform/s5p-mfc/s5p_mfc.c |  1 +
 drivers/media/platform/s5p-mfc/s5p_mfc_dec.c | 21 +
 2 files changed, 14 insertions(+), 8 deletions(-)

diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc.c
index 05a31ee..3ffe2ec 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
@@ -196,6 +196,7 @@ static void s5p_mfc_handle_frame_all_extracted(struct 
s5p_mfc_ctx *ctx)
vb2_set_plane_payload(_buf->b->vb2_buf, 0, 0);
vb2_set_plane_payload(_buf->b->vb2_buf, 1, 0);
list_del(_buf->list);
+   dst_buf->flags |= MFC_BUF_FLAG_EOS;
ctx->dst_queue_cnt--;
dst_buf->b->sequence = (ctx->sequence++);
 
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
index 1734775..8d3d40c 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
@@ -645,17 +645,22 @@ static int vidioc_dqbuf(struct file *file, void *priv, 
struct v4l2_buffer *buf)
mfc_err("Call on DQBUF after unrecoverable error\n");
return -EIO;
}
-   if (buf->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE)
-   ret = vb2_dqbuf(>vq_src, buf, file->f_flags & O_NONBLOCK);
-   else if (buf->type == V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE) {
+
+   switch (buf->type) {
+   case V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE:
+   return vb2_dqbuf(>vq_src, buf, file->f_flags & O_NONBLOCK);
+   case V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE:
ret = vb2_dqbuf(>vq_dst, buf, file->f_flags & O_NONBLOCK);
-   if (ret == 0 && ctx->state == MFCINST_FINISHED &&
-   list_empty(>vq_dst.done_list))
+   if (ret)
+   return ret;
+
+   if (ctx->state == MFCINST_FINISHED &&
+   (ctx->dst_bufs[buf->index].flags & MFC_BUF_FLAG_EOS))
v4l2_event_queue_fh(>fh, );
-   } else {
-   ret = -EINVAL;
+   return 0;
+   default:
+   return -EINVAL;
}
-   return ret;
 }
 
 /* Export DMA buffer */
-- 
1.9.1

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

[PATCH v3 1/2] s5p-mfc: end-of-stream handling for newer encoders

[Andrzej Hajda]

MFC encoder supports end-of-stream handling for encoder
in version 5 of hardware. This patch adds it also for newer version.
It was successfully tested on MFC-v8.

Signed-off-by: Andrzej Hajda 
---
Hi Kamil,

Incorrect format fixed.

Regards
Andrzej
---
 drivers/media/platform/s5p-mfc/s5p_mfc.c| 25 ++---
 drivers/media/platform/s5p-mfc/s5p_mfc_enc.c|  5 ++-
 drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c | 49 +
 3 files changed, 48 insertions(+), 31 deletions(-)

diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc.c
index 7b646c2..05a31ee 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
@@ -181,13 +181,6 @@ unlock:
mutex_unlock(>mfc_mutex);
 }
 
-static void s5p_mfc_clear_int_flags(struct s5p_mfc_dev *dev)
-{
-   mfc_write(dev, 0, S5P_FIMV_RISC_HOST_INT);
-   mfc_write(dev, 0, S5P_FIMV_RISC2HOST_CMD);
-   mfc_write(dev, 0x, S5P_FIMV_SI_RTN_CHID);
-}
-
 static void s5p_mfc_handle_frame_all_extracted(struct s5p_mfc_ctx *ctx)
 {
struct s5p_mfc_buf *dst_buf;
@@ -579,17 +572,13 @@ static void s5p_mfc_handle_init_buffers(struct 
s5p_mfc_ctx *ctx,
}
 }
 
-static void s5p_mfc_handle_stream_complete(struct s5p_mfc_ctx *ctx,
-unsigned int reason, unsigned int err)
+static void s5p_mfc_handle_stream_complete(struct s5p_mfc_ctx *ctx)
 {
struct s5p_mfc_dev *dev = ctx->dev;
struct s5p_mfc_buf *mb_entry;
 
mfc_debug(2, "Stream completed\n");
 
-   s5p_mfc_clear_int_flags(dev);
-   ctx->int_type = reason;
-   ctx->int_err = err;
ctx->state = MFCINST_FINISHED;
 
spin_lock(>irqlock);
@@ -646,6 +635,13 @@ static irqreturn_t s5p_mfc_irq(int irq, void *priv)
if (ctx->c_ops->post_frame_start) {
if (ctx->c_ops->post_frame_start(ctx))
mfc_err("post_frame_start() failed\n");
+
+   if (ctx->state == MFCINST_FINISHING &&
+   list_empty(>ref_queue)) {
+   s5p_mfc_hw_call_void(dev->mfc_ops, 
clear_int_flags, dev);
+   s5p_mfc_handle_stream_complete(ctx);
+   break;
+   }
s5p_mfc_hw_call_void(dev->mfc_ops, clear_int_flags, 
dev);
wake_up_ctx(ctx, reason, err);
WARN_ON(test_and_clear_bit(0, >hw_lock) == 0);
@@ -691,7 +687,10 @@ static irqreturn_t s5p_mfc_irq(int irq, void *priv)
break;
 
case S5P_MFC_R2H_CMD_COMPLETE_SEQ_RET:
-   s5p_mfc_handle_stream_complete(ctx, reason, err);
+   s5p_mfc_hw_call_void(dev->mfc_ops, clear_int_flags, dev);
+   ctx->int_type = reason;
+   ctx->int_err = err;
+   s5p_mfc_handle_stream_complete(ctx);
break;
 
case S5P_MFC_R2H_CMD_DPB_FLUSH_RET:
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
index 94868f7..d082d47 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
@@ -907,9 +907,9 @@ static int enc_post_frame_start(struct s5p_mfc_ctx *ctx)
list_add_tail(_entry->list, >ref_queue);
ctx->ref_queue_cnt++;
}
-   mfc_debug(2, "enc src count: %d, enc ref count: %d\n",
- ctx->src_queue_cnt, ctx->ref_queue_cnt);
}
+   mfc_debug(2, "enc src count: %d, enc ref count: %d\n",
+ ctx->src_queue_cnt, ctx->ref_queue_cnt);
if ((ctx->dst_queue_cnt > 0) && (strm_size > 0)) {
mb_entry = list_entry(ctx->dst_queue.next, struct s5p_mfc_buf,
list);
@@ -932,6 +932,7 @@ static int enc_post_frame_start(struct s5p_mfc_ctx *ctx)
spin_unlock_irqrestore(>irqlock, flags);
if ((ctx->src_queue_cnt == 0) || (ctx->dst_queue_cnt == 0))
clear_work_bit(ctx);
+
return 0;
 }
 
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
index e0924a52..b958453 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
@@ -554,7 +554,7 @@ static void s5p_mfc_get_enc_frame_buffer_v6(struct 
s5p_mfc_ctx *ctx,
enc_recon_y_addr = readl(mfc_regs->e_recon_luma_dpb_addr);
enc_recon_c_addr = readl(mfc_regs->e_recon_chroma_dpb_addr);
 
-   mfc_debug(2, "recon y addr: 0x%08lx\n", enc_recon_y_addr);
+   mfc_debug(2, "recon y addr: 0x%08lx y_addr: 0x%08lx\n", 
enc_recon_y_addr, *y_addr);
mfc_debug(2, "recon c addr: 0x%08lx\n", enc_recon_c_addr);
 }
 

Re: [PATCH v5 0/17] Add Analogix Core Display Port Driver

[Javier Martinez Canillas]

Hello Yakir,

On 10/07/2015 11:02 AM, Yakir Yang wrote:
> Hi Javier,
> 
> On 10/07/2015 04:46 PM, Javier Martinez Canillas wrote:
>> Hello Yakir,
>>
>> On 10/07/2015 08:25 AM, Yakir Yang wrote:
>>> Hi all,
>>>
>>> Friendly ping.   :)
>>>
>>>
>>> Best regards,
>>> - Yakir
>>>
>>>
>> Do you have a tree that I can use to test these patches?
> 
> Wow, thanks a lot, I do have a tree on github 
> [https://github.com/yakir-Yang/linux/tree/analogix_dp],
> crossing my finger, wish things works..;)
>

I tried your analogix_dp branch on an Exynos5800 Peach Pi Chromebook
but the machine didn't boot. Unfortunately I need to do some soldering
to have a serial console on this board so don't have a kernel boot log.

I'll let you know if I can get more info about this issue.

Also, there is Kconfig recursive dependency that you may want to fix:

$ make exynos_defconfig
drivers/video/fbdev/Kconfig:5:error: recursive dependency detected!
drivers/video/fbdev/Kconfig:5: symbol FB is selected by DRM_KMS_FB_HELPER
drivers/gpu/drm/Kconfig:34: symbol DRM_KMS_FB_HELPER depends on DRM_KMS_HELPER
drivers/gpu/drm/Kconfig:28: symbol DRM_KMS_HELPER is selected by DRM_ANALOGIX_DP
drivers/gpu/drm/bridge/analogix/Kconfig:1: symbol DRM_ANALOGIX_DP is selected 
by DRM_EXYNOS_DP
drivers/gpu/drm/exynos/Kconfig:57: symbol DRM_EXYNOS_DP depends on 
DRM_EXYNOS_FIMD
drivers/gpu/drm/exynos/Kconfig:19: symbol DRM_EXYNOS_FIMD depends on FB_S3C
drivers/video/fbdev/Kconfig:2023: symbol FB_S3C depends on FB
 
> Thanks,
> - 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 v5 0/17] Add Analogix Core Display Port Driver

[Javier Martinez Canillas]

Hello Yakir,

On 10/07/2015 01:05 PM, Yakir Yang wrote:
> Hi Javier,
> 
> On 10/07/2015 05:26 PM, Javier Martinez Canillas wrote:
>> Hello Yakir,
>>
>> On 10/07/2015 11:02 AM, Yakir Yang wrote:
>>> Hi Javier,
>>>
>>> On 10/07/2015 04:46 PM, Javier Martinez Canillas wrote:
 Hello Yakir,

 On 10/07/2015 08:25 AM, Yakir Yang wrote:
> Hi all,
>
> Friendly ping.   :)
>
>
> Best regards,
> - Yakir
>
>
 Do you have a tree that I can use to test these patches?
>>> Wow, thanks a lot, I do have a tree on github 
>>> [https://github.com/yakir-Yang/linux/tree/analogix_dp],
>>> crossing my finger, wish things works..;)
>>>
>> I tried your analogix_dp branch on an Exynos5800 Peach Pi Chromebook
>> but the machine didn't boot. Unfortunately I need to do some soldering
>> to have a serial console on this board so don't have a kernel boot log.
>>
>> I'll let you know if I can get more info about this issue.
> 
> Whoops, sorry for the failed, much appreciated for your works.
> 
> Besides, I thought maybe I can find a Peach Pit Chromebook in my side,
> I remember that some of our guys have brought one, but previously I
> thought that mainline kernel wouldn't run on Peach Pit directly.
> 

Great, mainline works correctly on all Exynos based Chromebooks.

> Maybe you can email me the method the run mainline kernel on Peach
> Pit, so I can debug the analogix_dp driver at the same time, that would
> be great.

I wrote a little blog post explaining how to run mainline on these boards:

http://blogs.s-osg.org/install-linux-mainline-kernel-distro-exynos-chromebooks/

That explains the simplest setup though so if you need a different one
(i.e: chain loading a non verified u-boot) or if you have any questions,
feel free to contact me in private and I can help you with the setup.

>> Also, there is Kconfig recursive dependency that you may want to fix:
>>
>> $ make exynos_defconfig
>> drivers/video/fbdev/Kconfig:5:error: recursive dependency detected!
>> drivers/video/fbdev/Kconfig:5: symbol FB is selected by DRM_KMS_FB_HELPER
>> drivers/gpu/drm/Kconfig:34: symbol DRM_KMS_FB_HELPER depends on 
>> DRM_KMS_HELPER
>> drivers/gpu/drm/Kconfig:28: symbol DRM_KMS_HELPER is selected by 
>> DRM_ANALOGIX_DP
>> drivers/gpu/drm/bridge/analogix/Kconfig:1: symbol DRM_ANALOGIX_DP is 
>> selected by DRM_EXYNOS_DP
>> drivers/gpu/drm/exynos/Kconfig:57: symbol DRM_EXYNOS_DP depends on 
>> DRM_EXYNOS_FIMD
>> drivers/gpu/drm/exynos/Kconfig:19: symbol DRM_EXYNOS_FIMD depends on FB_S3C
>> drivers/video/fbdev/Kconfig:2023: symbol FB_S3C depends on FB
>>   
> 
> Yeah, recursive dependency detected, guess I should remove the
> "DRM_KMS_HELPER" from bridge analogix_dp Kconfig file, thanks
> for your remind.
> 
> --- a/drivers/gpu/drm/bridge/analogix/Kconfig
> +++ b/drivers/gpu/drm/bridge/analogix/Kconfig
> @@ -1,4 +1,3 @@
>  config DRM_ANALOGIX_DP
> tristate
> depends on DRM
> -   select DRM_KMS_HELPER
> 
> 

That fixes the recursive dependency issue indeed. Thanks.

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

[PATCH 2/5] ARM: dts: Use GPIO constants for flags cells in exynos4120 boards

[Javier Martinez Canillas]

The board DTS are using numeric values instead of the defined GPIO
constanst to express polarity, use them to make the DTS more clear.

Signed-off-by: Javier Martinez Canillas 
---

 arch/arm/boot/dts/exynos4210-origen.dts | 15 -
 arch/arm/boot/dts/exynos4210-smdkv310.dts   |  3 +-
 arch/arm/boot/dts/exynos4210-trats.dts  | 29 -
 arch/arm/boot/dts/exynos4210-universal_c210.dts | 42 +
 4 files changed, 47 insertions(+), 42 deletions(-)

diff --git a/arch/arm/boot/dts/exynos4210-origen.dts 
b/arch/arm/boot/dts/exynos4210-origen.dts
index e050d85cdacd..b8f866991bdd 100644
--- a/arch/arm/boot/dts/exynos4210-origen.dts
+++ b/arch/arm/boot/dts/exynos4210-origen.dts
@@ -16,6 +16,7 @@
 
 /dts-v1/;
 #include "exynos4210.dtsi"
+#include 
 #include 
 
 / {
@@ -45,7 +46,7 @@
regulator-name = "VMEM_VDD_2.8V";
regulator-min-microvolt = <280>;
regulator-max-microvolt = <280>;
-   gpio = < 1 0>;
+   gpio = < 1 GPIO_ACTIVE_HIGH>;
enable-active-high;
};
};
@@ -57,35 +58,35 @@
 
up {
label = "Up";
-   gpios = < 0 1>;
+   gpios = < 0 GPIO_ACTIVE_LOW>;
linux,code = ;
gpio-key,wakeup;
};
 
down {
label = "Down";
-   gpios = < 1 1>;
+   gpios = < 1 GPIO_ACTIVE_LOW>;
linux,code = ;
gpio-key,wakeup;
};
 
back {
label = "Back";
-   gpios = < 7 1>;
+   gpios = < 7 GPIO_ACTIVE_LOW>;
linux,code = ;
gpio-key,wakeup;
};
 
home {
label = "Home";
-   gpios = < 6 1>;
+   gpios = < 6 GPIO_ACTIVE_LOW>;
linux,code = ;
gpio-key,wakeup;
};
 
menu {
label = "Menu";
-   gpios = < 5 1>;
+   gpios = < 5 GPIO_ACTIVE_LOW>;
linux,code = ;
gpio-key,wakeup;
};
@@ -94,7 +95,7 @@
leds {
compatible = "gpio-leds";
status {
-   gpios = < 3 1>;
+   gpios = < 3 GPIO_ACTIVE_LOW>;
linux,default-trigger = "heartbeat";
};
};
diff --git a/arch/arm/boot/dts/exynos4210-smdkv310.dts 
b/arch/arm/boot/dts/exynos4210-smdkv310.dts
index 043b03caff8f..bc1448ba95d3 100644
--- a/arch/arm/boot/dts/exynos4210-smdkv310.dts
+++ b/arch/arm/boot/dts/exynos4210-smdkv310.dts
@@ -16,6 +16,7 @@
 
 /dts-v1/;
 #include "exynos4210.dtsi"
+#include 
 
 / {
model = "Samsung smdkv310 evaluation board based on Exynos4210";
@@ -182,7 +183,7 @@
 };
 
 _2 {
-   cs-gpios = < 2 0>;
+   cs-gpios = < 2 GPIO_ACTIVE_HIGH>;
status = "okay";
 
w25x80@0 {
diff --git a/arch/arm/boot/dts/exynos4210-trats.dts 
b/arch/arm/boot/dts/exynos4210-trats.dts
index ba34886f8b65..c69e468efd2e 100644
--- a/arch/arm/boot/dts/exynos4210-trats.dts
+++ b/arch/arm/boot/dts/exynos4210-trats.dts
@@ -14,6 +14,7 @@
 
 /dts-v1/;
 #include "exynos4210.dtsi"
+#include 
 
 / {
model = "Samsung Trats based on Exynos4210";
@@ -39,7 +40,7 @@
regulator-name = "VMEM_VDD_2.8V";
regulator-min-microvolt = <280>;
regulator-max-microvolt = <280>;
-   gpio = < 2 0>;
+   gpio = < 2 GPIO_ACTIVE_HIGH>;
enable-active-high;
};
 
@@ -48,7 +49,7 @@
regulator-name = "TSP_FIXED_VOLTAGES";
regulator-min-microvolt = <280>;
regulator-max-microvolt = <280>;
-   gpio = < 3 0>;
+   gpio = < 3 GPIO_ACTIVE_HIGH>;
enable-active-high;
};
 
@@ -57,7 +58,7 @@
regulator-name = "8M_AF_2.8V_EN";
regulator-min-microvolt = <280>;
regulator-max-microvolt = <280>;
-   gpio = < 1 0>;
+   gpio = < 1 GPIO_ACTIVE_HIGH>;
enable-active-high;
};
 
@@ -66,7 +67,7 @@
regulator-name = "CAM_IO_EN";
regulator-min-microvolt = <280>;
regulator-max-microvolt = <280>;
-   gpio = < 1 0>;
+ 

[PATCH 1/5] ARM: dts: Use GPIO constants for flags cells in exynos3250 boards

[Javier Martinez Canillas]

The board DTS are using numeric values instead of the defined GPIO
constanst to express polarity, use them to make the DTS more clear.

Signed-off-by: Javier Martinez Canillas 
---

 arch/arm/boot/dts/exynos3250-monk.dts   |  8 
 arch/arm/boot/dts/exynos3250-rinato.dts | 10 +-
 2 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/arch/arm/boot/dts/exynos3250-monk.dts 
b/arch/arm/boot/dts/exynos3250-monk.dts
index 540a0adf2be6..c14129e0761d 100644
--- a/arch/arm/boot/dts/exynos3250-monk.dts
+++ b/arch/arm/boot/dts/exynos3250-monk.dts
@@ -52,13 +52,13 @@
regulator-name = "V_EMMC_2.8V-fixed";
regulator-min-microvolt = <280>;
regulator-max-microvolt = <280>;
-   gpio = < 2 0>;
+   gpio = < 2 GPIO_ACTIVE_HIGH>;
enable-active-high;
};
 
i2c_max77836: i2c-gpio-0 {
compatible = "i2c-gpio";
-   gpios = < 2 0>, < 3 0>;
+   gpios = < 2 GPIO_ACTIVE_HIGH>, < 3 GPIO_ACTIVE_HIGH>;
#address-cells = <1>;
#size-cells = <0>;
 
@@ -266,14 +266,14 @@
regulator-name = "V_EMMC_1.8V";
regulator-min-microvolt = <180>;
regulator-max-microvolt = <180>;
-   samsung,ext-control-gpios = < 2 0>;
+   samsung,ext-control-gpios = < 2 
GPIO_ACTIVE_HIGH>;
};
 
ldo12_reg: LDO12 {
regulator-name = "V_EMMC_2.8V";
regulator-min-microvolt = <280>;
regulator-max-microvolt = <280>;
-   samsung,ext-control-gpios = < 2 0>;
+   samsung,ext-control-gpios = < 2 
GPIO_ACTIVE_HIGH>;
};
 
ldo13_reg: LDO13 {
diff --git a/arch/arm/boot/dts/exynos3250-rinato.dts 
b/arch/arm/boot/dts/exynos3250-rinato.dts
index 41a5fafb9aa9..830e216f7e10 100644
--- a/arch/arm/boot/dts/exynos3250-rinato.dts
+++ b/arch/arm/boot/dts/exynos3250-rinato.dts
@@ -49,7 +49,7 @@
 
i2c_max77836: i2c-gpio-0 {
compatible = "i2c-gpio";
-   gpios = < 2 0>, < 3 0>;
+   gpios = < 2 GPIO_ACTIVE_HIGH>, < 3 GPIO_ACTIVE_HIGH>;
#address-cells = <1>;
#size-cells = <0>;
 
@@ -188,8 +188,8 @@
reg = <0>;
vdd3-supply = <_reg>;
vci-supply = <_reg>;
-   reset-gpios = < 1 0>;
-   te-gpios = < 6 0>;
+   reset-gpios = < 1 GPIO_ACTIVE_HIGH>;
+   te-gpios = < 6 GPIO_ACTIVE_HIGH>;
power-on-delay= <30>;
power-off-delay= <120>;
reset-delay = <5>;
@@ -368,14 +368,14 @@
regulator-name = "V_EMMC_1.8V";
regulator-min-microvolt = <180>;
regulator-max-microvolt = <180>;
-   samsung,ext-control-gpios = < 2 0>;
+   samsung,ext-control-gpios = < 2 
GPIO_ACTIVE_HIGH>;
};
 
ldo12_reg: LDO12 {
regulator-name = "V_EMMC_2.8V";
regulator-min-microvolt = <280>;
regulator-max-microvolt = <280>;
-   samsung,ext-control-gpios = < 2 0>;
+   samsung,ext-control-gpios = < 2 
GPIO_ACTIVE_HIGH>;
};
 
ldo13_reg: LDO13 {
-- 
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 4/5] ARM: dts: Use GPIO constants for flags cells in exynos5420/5422/5800 boards

[Javier Martinez Canillas]

The board DTS are using numeric values instead of the defined GPIO
constanst to express polarity, use them to make the DTS more clear.

Signed-off-by: Javier Martinez Canillas 
---

 arch/arm/boot/dts/exynos5420-arndale-octa.dts  | 3 ++-
 arch/arm/boot/dts/exynos5420-peach-pit.dts | 8 
 arch/arm/boot/dts/exynos5420-smdk5420.dts  | 7 ---
 arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 4 ++--
 arch/arm/boot/dts/exynos5800-peach-pi.dts  | 8 
 5 files changed, 16 insertions(+), 14 deletions(-)

diff --git a/arch/arm/boot/dts/exynos5420-arndale-octa.dts 
b/arch/arm/boot/dts/exynos5420-arndale-octa.dts
index eeb4ac22cfce..4ecef6981d5c 100644
--- a/arch/arm/boot/dts/exynos5420-arndale-octa.dts
+++ b/arch/arm/boot/dts/exynos5420-arndale-octa.dts
@@ -11,6 +11,7 @@
 
 /dts-v1/;
 #include "exynos5420.dtsi"
+#include 
 #include 
 #include 
 #include 
@@ -44,7 +45,7 @@
 
wakeup {
label = "SW-TACT1";
-   gpios = < 7 1>;
+   gpios = < 7 GPIO_ACTIVE_LOW>;
linux,code = ;
gpio-key,wakeup;
};
diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts 
b/arch/arm/boot/dts/exynos5420-peach-pit.dts
index 8f4d76c5e11c..c53fca8440a1 100644
--- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
+++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
@@ -94,7 +94,7 @@
regulator-name = "P5.0V_USB3CON0";
regulator-min-microvolt = <500>;
regulator-max-microvolt = <500>;
-   gpio = < 0 0>;
+   gpio = < 0 GPIO_ACTIVE_HIGH>;
pinctrl-names = "default";
pinctrl-0 = <_vbus_en>;
enable-active-high;
@@ -105,7 +105,7 @@
regulator-name = "P5.0V_USB3CON1";
regulator-min-microvolt = <500>;
regulator-max-microvolt = <500>;
-   gpio = < 1 0>;
+   gpio = < 1 GPIO_ACTIVE_HIGH>;
pinctrl-names = "default";
pinctrl-0 = <_vbus_en>;
enable-active-high;
@@ -153,7 +153,7 @@
samsung,color-depth = <1>;
samsung,link-rate = <0x06>;
samsung,lane-count = <2>;
-   samsung,hpd-gpio = < 6 0>;
+   samsung,hpd-gpio = < 6 GPIO_ACTIVE_HIGH>;
 
ports {
port@0 {
@@ -925,7 +925,7 @@
status = "okay";
num-cs = <1>;
samsung,spi-src-clk = <0>;
-   cs-gpios = < 2 0>;
+   cs-gpios = < 2 GPIO_ACTIVE_HIGH>;
 
cros_ec: cros-ec@0 {
compatible = "google,cros-ec-spi";
diff --git a/arch/arm/boot/dts/exynos5420-smdk5420.dts 
b/arch/arm/boot/dts/exynos5420-smdk5420.dts
index 7520d52f4e22..ac35aefd320f 100644
--- a/arch/arm/boot/dts/exynos5420-smdk5420.dts
+++ b/arch/arm/boot/dts/exynos5420-smdk5420.dts
@@ -11,6 +11,7 @@
 
 /dts-v1/;
 #include "exynos5420.dtsi"
+#include 
 
 / {
model = "Samsung SMDK5420 board based on EXYNOS5420";
@@ -69,7 +70,7 @@
regulator-name = "VBUS0";
regulator-min-microvolt = <500>;
regulator-max-microvolt = <500>;
-   gpio = < 5 0>;
+   gpio = < 5 GPIO_ACTIVE_HIGH>;
pinctrl-names = "default";
pinctrl-0 = <_vbus_en>;
enable-active-high;
@@ -80,7 +81,7 @@
regulator-name = "VBUS1";
regulator-min-microvolt = <500>;
regulator-max-microvolt = <500>;
-   gpio = < 4 0>;
+   gpio = < 4 GPIO_ACTIVE_HIGH>;
pinctrl-names = "default";
pinctrl-0 = <_vbus_en>;
enable-active-high;
@@ -121,7 +122,7 @@
 
  {
status = "okay";
-   hpd-gpio = < 7 0>;
+   hpd-gpio = < 7 GPIO_ACTIVE_HIGH>;
pinctrl-names = "default";
pinctrl-0 = <_hpd_irq>;
 };
diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi 
b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
index a83d569baea8..1af5bdc2bdb1 100644
--- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
+++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
@@ -43,7 +43,7 @@
pinctrl-0 = <_nrst_pin>;
pinctrl-names = "default";
compatible = "mmc-pwrseq-emmc";
-   reset-gpios = < 0 1>;
+   reset-gpios = < 0 GPIO_ACTIVE_LOW>;
};
 
fan0: pwm-fan {
@@ -74,7 +74,7 @@
 
  {
status = "okay";
-   hpd-gpio = < 7 0>;
+   hpd-gpio = < 7 GPIO_ACTIVE_HIGH>;
pinctrl-names = "default";
pinctrl-0 = <_hpd_irq>;
 
diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts 
b/arch/arm/boot/dts/exynos5800-peach-pi.dts
index 7d5b386b5ae6..39ecc38aa54f 100644
--- a/arch/arm/boot/dts/exynos5800-peach-pi.dts
+++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts
@@ -94,7 +94,7 @@

[PATCH 3/5] ARM: dts: Use GPIO constants for flags cells in exynos4412 boards

[Javier Martinez Canillas]

The board DTS are using numeric values instead of the defined GPIO
constanst to express polarity, use them to make the DTS more clear.

Signed-off-by: Javier Martinez Canillas 
---

 arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 15 ++-
 arch/arm/boot/dts/exynos4412-odroidu3.dts   |  2 +-
 arch/arm/boot/dts/exynos4412-odroidx.dts|  8 +++---
 arch/arm/boot/dts/exynos4412-origen.dts | 15 ++-
 arch/arm/boot/dts/exynos4412-tiny4412.dts   |  9 ---
 arch/arm/boot/dts/exynos4412-trats2.dts | 34 -
 6 files changed, 43 insertions(+), 40 deletions(-)

diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi 
b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
index c3e978d77367..edf0fc8db6ff 100644
--- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
+++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include "exynos4412.dtsi"
+#include 
 
 / {
chosen {
@@ -30,7 +31,7 @@
power_key {
interrupt-parent = <>;
interrupts = <3 0>;
-   gpios = < 3 1>;
+   gpios = < 3 GPIO_ACTIVE_LOW>;
linux,code = ;
label = "power key";
debounce-interval = <10>;
@@ -70,7 +71,7 @@
pinctrl-0 = <_cd>;
pinctrl-names = "default";
compatible = "mmc-pwrseq-emmc";
-   reset-gpios = < 2 1>;
+   reset-gpios = < 2 GPIO_ACTIVE_LOW>;
};
 
camera {
@@ -181,7 +182,7 @@
 };
 
  {
-   hpd-gpio = < 7 0>;
+   hpd-gpio = < 7 GPIO_ACTIVE_HIGH>;
pinctrl-names = "default";
pinctrl-0 = <_hpd>;
vdd-supply = <_reg>;
@@ -207,9 +208,9 @@
compatible = "smsc,usb3503";
reg = <0x08>;
 
-   intn-gpios = < 0 0>;
-   connect-gpios = < 4 0>;
-   reset-gpios = < 5 0>;
+   intn-gpios = < 0 GPIO_ACTIVE_HIGH>;
+   connect-gpios = < 4 GPIO_ACTIVE_HIGH>;
+   reset-gpios = < 5 GPIO_ACTIVE_HIGH>;
initial-mode = <1>;
};
 
@@ -482,7 +483,7 @@
pinctrl-0 = <_clk _cmd _cd _bus4>;
pinctrl-names = "default";
vmmc-supply = <_reg _reg>;
-   cd-gpios = < 2 0>;
+   cd-gpios = < 2 GPIO_ACTIVE_HIGH>;
cd-inverted;
status = "okay";
 };
diff --git a/arch/arm/boot/dts/exynos4412-odroidu3.dts 
b/arch/arm/boot/dts/exynos4412-odroidu3.dts
index 1e6ef99eef59..646ff0bd001a 100644
--- a/arch/arm/boot/dts/exynos4412-odroidu3.dts
+++ b/arch/arm/boot/dts/exynos4412-odroidu3.dts
@@ -27,7 +27,7 @@
compatible = "gpio-leds";
led1 {
label = "led1:heart";
-   gpios = < 0 1>;
+   gpios = < 0 GPIO_ACTIVE_LOW>;
default-state = "on";
linux,default-trigger = "heartbeat";
};
diff --git a/arch/arm/boot/dts/exynos4412-odroidx.dts 
b/arch/arm/boot/dts/exynos4412-odroidx.dts
index 679ac103ebf6..b44bb682e976 100644
--- a/arch/arm/boot/dts/exynos4412-odroidx.dts
+++ b/arch/arm/boot/dts/exynos4412-odroidx.dts
@@ -26,13 +26,13 @@
compatible = "gpio-leds";
led1 {
label = "led1:heart";
-   gpios = < 0 1>;
+   gpios = < 0 GPIO_ACTIVE_LOW>;
default-state = "on";
linux,default-trigger = "heartbeat";
};
led2 {
label = "led2:mmc0";
-   gpios = < 2 1>;
+   gpios = < 2 GPIO_ACTIVE_LOW>;
default-state = "on";
linux,default-trigger = "mmc0";
};
@@ -44,7 +44,7 @@
home_key {
interrupt-parent = <>;
interrupts = <2 0>;
-   gpios = < 2 0>;
+   gpios = < 2 GPIO_ACTIVE_HIGH>;
linux,code = ;
label = "home key";
debounce-interval = <10>;
@@ -57,7 +57,7 @@
regulator-name = "p3v3_en";
regulator-min-microvolt = <330>;
regulator-max-microvolt = <330>;
-   gpio = < 1 1>;
+   gpio = < 1 GPIO_ACTIVE_LOW>;
enable-active-high;
regulator-always-on;
};
diff --git a/arch/arm/boot/dts/exynos4412-origen.dts 
b/arch/arm/boot/dts/exynos4412-origen.dts
index 9d528af68c1a..c8d86af2fb98 100644
--- a/arch/arm/boot/dts/exynos4412-origen.dts
+++ b/arch/arm/boot/dts/exynos4412-origen.dts
@@ -14,6 +14,7 @@
 
 /dts-v1/;
 #include "exynos4412.dtsi"
+#include 
 #include 
 
 / {
@@ -45,7 +46,7 @@
   

[PATCH 0/5] ARM: dts: Use GPIO constants for flags cells in exynos boards

[Javier Martinez Canillas]

Hello,

This series contains trivial patches that use the GPIO constants
defined in include/dt-bindings/gpio/gpio.h to express GPIO polarity
instead of numeric values.

There is no functional change and the compiled dtbs are unchanged but
is a good practice to use the defined macros instead of magic numbers
since that makes the DTS more readable.

Since the changes are trivial, I thought that split the changes per
board DTS would create an unnecessary churn but a single patch would
maybe be harder to review so I decided that split it by SoC family
would be a good trade off.

Please let me know if you prefer another approach.

Best regards,
Javier


Javier Martinez Canillas (5):
  ARM: dts: Use GPIO constants for flags cells in exynos3250 boards
  ARM: dts: Use GPIO constants for flags cells in exynos4120 boards
  ARM: dts: Use GPIO constants for flags cells in exynos4412 boards
  ARM: dts: Use GPIO constants for flags cells in exynos5420/5422/5800
boards
  ARM: dts: Use GPIO constants for flags cells in exynos5440 boards

 arch/arm/boot/dts/exynos3250-monk.dts  |  8 ++---
 arch/arm/boot/dts/exynos3250-rinato.dts| 10 +++---
 arch/arm/boot/dts/exynos4210-origen.dts| 15 
 arch/arm/boot/dts/exynos4210-smdkv310.dts  |  3 +-
 arch/arm/boot/dts/exynos4210-trats.dts | 29 +++
 arch/arm/boot/dts/exynos4210-universal_c210.dts| 42 +++---
 arch/arm/boot/dts/exynos4412-odroid-common.dtsi| 15 
 arch/arm/boot/dts/exynos4412-odroidu3.dts  |  2 +-
 arch/arm/boot/dts/exynos4412-odroidx.dts   |  8 ++---
 arch/arm/boot/dts/exynos4412-origen.dts| 15 
 arch/arm/boot/dts/exynos4412-tiny4412.dts  |  9 ++---
 arch/arm/boot/dts/exynos4412-trats2.dts| 34 +-
 arch/arm/boot/dts/exynos5420-arndale-octa.dts  |  3 +-
 arch/arm/boot/dts/exynos5420-peach-pit.dts |  8 ++---
 arch/arm/boot/dts/exynos5420-smdk5420.dts  |  7 ++--
 arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi |  4 +--
 arch/arm/boot/dts/exynos5440-ssdk5440.dts  |  5 +--
 arch/arm/boot/dts/exynos5800-peach-pi.dts  |  8 ++---
 18 files changed, 118 insertions(+), 107 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 5/5] ARM: dts: Use GPIO constants for flags cells in exynos5440 boards

[Javier Martinez Canillas]

The board DTS are using numeric values instead of the defined GPIO
constanst to express polarity, use them to make the DTS more clear.

Signed-off-by: Javier Martinez Canillas 

---

 arch/arm/boot/dts/exynos5440-ssdk5440.dts | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/exynos5440-ssdk5440.dts 
b/arch/arm/boot/dts/exynos5440-ssdk5440.dts
index e4443f4e6572..6a0d802e87c8 100644
--- a/arch/arm/boot/dts/exynos5440-ssdk5440.dts
+++ b/arch/arm/boot/dts/exynos5440-ssdk5440.dts
@@ -11,6 +11,7 @@
 
 /dts-v1/;
 #include "exynos5440.dtsi"
+#include 
 
 / {
model = "SAMSUNG SSDK5440 board based on EXYNOS5440";
@@ -29,12 +30,12 @@
 };
 
 _0 {
-   reset-gpio = <_ctrl 5 0>;
+   reset-gpio = <_ctrl 5 GPIO_ACTIVE_HIGH>;
status = "okay";
 };
 
 _1 {
-   reset-gpio = <_ctrl 22 0>;
+   reset-gpio = <_ctrl 22 GPIO_ACTIVE_HIGH>;
status = "okay";
 };
 
-- 
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 0/3] usb: usb3503: Fix probing on Arndale board (missing phy)

[Marek Szyprowski]

Hello,

On 2015-10-07 02:30, Krzysztof Kozlowski wrote:

Introduction

This patchset tries to fix probing of usb3503 on Arndale board
if the Samsung PHY driver is probed later (or built as a module).

*The patchset was not tested on Arndale board.*
I don't have that board. Please test it and say if the usb3503 deferred probe
works fine and the issue is solved.

The patchset was tested on Odroid U3 board (which is different!)
in a simulated environment. It is not sufficient testing.


Difference
==
The usb3503 device driver can be used as a I2C device (on Odroid U3)
or as a platform device connected through phy (on Arndale). In the second
case the necessary phy reference has to be obtained and enabled.

For some details please look also at thread [0][1].

[0] http://lists.infradead.org/pipermail/linux-arm-kernel/2015-June/348524.html
[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2015-June/348875.html



I'm not sure that this is the correct approach. usb3503 chip is simply 
connected
to Exynos USB2 phy, so it visible on the USB bus. The real driver that 
controls USB2

PHY is Exynos EHCI driver and USB3503 should not mess around it.

In my opinion all that is needed in case of Arndale board is forcing 
reset of
usb3503 chip after successful EHCI and USB2 PHY initialization (for some 
reason

initialization of usb3503 chip must be done after usb host initialization).
However I have no idea which driver should trigger this reset. Right now 
I didn't
find any good solution for additional control for devices which are on 
autoprobed

bus like usb.

Best regards
--
Marek Szyprowski, PhD
Samsung R Institute Poland

--
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/6] ARM: s3c24xx: rx1950: Use PWM lookup table

[Thierry Reding]

On Wed, Oct 07, 2015 at 10:35:54AM +0900, Krzysztof Kozlowski wrote:
> On 05.10.2015 21:47, Thierry Reding wrote:
> > Use a PWM lookup table to provide the PWM to the pwm-backlight device.
> > The driver has a legacy code path that is required only because boards
> > still use the legacy method of requesting PWMs by global ID. Replacing
> > these usages allows that legacy fallback to be removed.
> > 
> > Cc: Kukjin Kim 
> > Cc: Krzysztof Kozlowski 
> > Signed-off-by: Thierry Reding 
> > ---
> >  arch/arm/mach-s3c24xx/mach-rx1950.c | 8 ++--
> >  1 file changed, 6 insertions(+), 2 deletions(-)
> > 
> > diff --git a/arch/arm/mach-s3c24xx/mach-rx1950.c 
> > b/arch/arm/mach-s3c24xx/mach-rx1950.c
> > index 1d35ff375a01..774c982a7b7e 100644
> > --- a/arch/arm/mach-s3c24xx/mach-rx1950.c
> > +++ b/arch/arm/mach-s3c24xx/mach-rx1950.c
> > @@ -375,6 +375,11 @@ static struct s3c2410fb_mach_info rx1950_lcd_cfg = {
> >  
> >  };
> >  
> > +static struct pwm_lookup rx1950_pwm_lookup[] = {
> > +   PWM_LOOKUP("samsung-pwm", 0, "pwm-backlight.0", NULL, 48000,
> 
> Why the dev_id is "pwm-backlight.0"? Created platform device name is
> "pwm-backlight".

"pwm-backlight" is only the base name. The platform bus code will use
the platform_device.id field and append it to the name as . unless
it is -1 in which case it will be skipped. So in the rx1950_backlight
device the .id field isn't initialized at all, so it will be zeroed
out and hence the device name will become "pwm-backlight.0".

Thierry


signature.asc
Description: PGP signature

Re: [PATCH 5/6] ARM: s3c64xx: hmt: Use PWM lookup table

[Thierry Reding]

On Wed, Oct 07, 2015 at 10:37:42AM +0900, Krzysztof Kozlowski wrote:
> On 05.10.2015 21:47, Thierry Reding wrote:
> > Use a PWM lookup table to provide the PWM to the pwm-backlight device.
> > The driver has a legacy code path that is required only because boards
> > still use the legacy method of requesting PWMs by global ID. Replacing
> > these usages allows that legacy fallback to be removed.
> > 
> > Cc: Kukjin Kim 
> > Cc: Krzysztof Kozlowski 
> > Signed-off-by: Thierry Reding 
> > ---
> >  arch/arm/mach-s3c64xx/mach-hmt.c | 9 +++--
> >  1 file changed, 7 insertions(+), 2 deletions(-)
> > 
> > diff --git a/arch/arm/mach-s3c64xx/mach-hmt.c 
> > b/arch/arm/mach-s3c64xx/mach-hmt.c
> > index e4b087c58ee6..816b39d1e6d1 100644
> > --- a/arch/arm/mach-s3c64xx/mach-hmt.c
> > +++ b/arch/arm/mach-s3c64xx/mach-hmt.c
> > @@ -19,6 +19,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -73,6 +74,11 @@ static struct s3c2410_uartcfg hmt_uartcfgs[] __initdata 
> > = {
> > },
> >  };
> >  
> > +static struct pwm_lookup hmt_pwm_lookup[] = {
> > +   PWM_LOOKUP("samsung-pwm", 1, "pwm-backlight.0", NULL,
> 
> Same questions as in patch 2 - why suffix ".0" for "pwm-backlight"?

For the same reason that I explained in patch 2. Not sure if the .id = 0
was really supposed to be. For most devices it would probably make sense
to initialize it to -1 because they typically only have a single
backlight. But given that userspace might be using the name to control
the backlight via sysfs it's probably not a good idea to go and change
that.

Thierry


signature.asc
Description: PGP signature

Re: [PATCH 00/13] drm/exynos: async G2D and g2d_move()

[Tobias Jakobi]

Gentle ping! :-)

- Tobias


Tobias Jakobi wrote:
> Hello,
> 
> this series mostly touches G2D code. It introduces the following:
> 
> (1) drmHandleEvent2() is added to enable processing of vendor-specific
> events. This will be used to expose asynchronous operation of the
> G2D. The necessary kernel infrastructure is already there since
> a lot of kernel versions. [This touches libdrm core code!]
> 
> (2) The necessary infrastructure to handle G2D events. This includes
> adding g2d_config_event() and g2d_exec2() to the public API.
> A test application is provided to ensure that everything works
> as expected.
> 
> (3) A small performance test application which can be used to measure
> the speed of solid color clear operations. Interesting for
> benchmarking and plotting colorful graphs (e.g. through
> Mathematica).
> 
> (4) g2d_move() which works similar to g2d_copy() but like the C
> memmove() properly handles overlapping buffer copies.
> Again a test application is present to check that this
> indeed does what it should.
> 
> (5) Various small changes. A framebuffer colorformat fix for the
> general G2D test application. Moving the currently unused
> g2d_reset() to the public API. Adding a counterpart to
> exynos_bo_map() to unmap buffers again.
> 
> (6) Last but not least a small bump of the Exynos version number.
> 
> Please review and let me know what I should change/improve.
> 
> 
> With best wishes,
> Tobias
> 
> P.S.: Most patches were submitted already some time ago but never
> made it upstream. So if something looks familiar, don't worry! ;)
> 
> Tobias Jakobi (13):
>   drm: Implement drmHandleEvent2()
>   exynos: Introduce exynos_handle_event()
>   tests/exynos: add fimg2d performance analysis
>   exynos/fimg2d: add g2d_config_event
>   exynos: fimg2d: add g2d_exec2
>   tests/exynos: add fimg2d event test
>   tests/exynos: use XRGB for framebuffer
>   exynos: fimg2d: add g2d_set_direction
>   exynos/fimg2d: add g2d_move
>   tests/exynos: add test for g2d_move
>   exynos/fimg2d: add exynos_bo_unmap()
>   exynos/fimg2d: add g2d_reset() to public API
>   exynos: bump version number
> 
>  exynos/exynos-symbol-check |   5 +
>  exynos/exynos_drm.c|  48 ++
>  exynos/exynos_drm.h|  12 ++
>  exynos/exynos_drmif.h  |  27 +++
>  exynos/exynos_fimg2d.c | 164 +--
>  exynos/exynos_fimg2d.h |  49 ++
>  exynos/libdrm_exynos.pc.in |   2 +-
>  tests/exynos/Makefile.am   |  26 ++-
>  tests/exynos/exynos_fimg2d_event.c | 326 
> +
>  tests/exynos/exynos_fimg2d_perf.c  | 320 
>  tests/exynos/exynos_fimg2d_test.c  | 134 ++-
>  xf86drm.h  |  21 +++
>  xf86drmMode.c  |  10 +-
>  13 files changed, 1128 insertions(+), 16 deletions(-)
>  create mode 100644 tests/exynos/exynos_fimg2d_event.c
>  create mode 100644 tests/exynos/exynos_fimg2d_perf.c
> 

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