[PATCH 0/4] Add support for clocks in S5M8767

[Tushar Behera]

S5M8767 chip has 3 crystal oscillators which are operated in the same
as the crystal oscillators in S2MPS11. Extend s2mps11-clk driver to
support clocks in S5M8767.

The patches are based on next-20131030.

Tushar Behera (4):
  clk: clk-s2mps11: Refactor for including support for other MFD clocks
  clk: clk-s2mps11: Add support for clocks in S5M8767 MFD
  mfd: sec-core: Add cells for S5M8767-clocks
  ARM: dts: Add S5M8767 clock nodes on Arndale board

 arch/arm/boot/dts/exynos5250-arndale.dts |7 +++
 drivers/clk/Kconfig  |6 --
 drivers/clk/clk-s2mps11.c|   25 +
 drivers/mfd/sec-core.c   |4 +++-
 4 files changed, 35 insertions(+), 7 deletions(-)

-- 
1.7.9.5

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

[PATCH 1/4] clk: clk-s2mps11: Refactor for including support for other MFD clocks

[Tushar Behera]

The clocks in S2MPS11 and S5M8767 are managed in the same way, baring
a difference in the register offset. It would be better to update
existing S2MPS11 driver to support the clocks in S5M8767, rather than
creating an almost duplicate driver altogether.

Signed-off-by: Tushar Behera tushar.beh...@linaro.org
CC: Yadwinder Singh Brar yadi.b...@samsung.com
CC: Mike Turquette mturque...@linaro.org
---
 drivers/clk/clk-s2mps11.c |   20 
 1 file changed, 16 insertions(+), 4 deletions(-)

diff --git a/drivers/clk/clk-s2mps11.c b/drivers/clk/clk-s2mps11.c
index 7be41e6..2262cb4 100644
--- a/drivers/clk/clk-s2mps11.c
+++ b/drivers/clk/clk-s2mps11.c
@@ -48,6 +48,7 @@ struct s2mps11_clk {
struct clk_lookup *lookup;
u32 mask;
bool enabled;
+   unsigned int reg;
 };
 
 static struct s2mps11_clk *to_s2mps11_clk(struct clk_hw *hw)
@@ -61,7 +62,7 @@ static int s2mps11_clk_prepare(struct clk_hw *hw)
int ret;
 
ret = regmap_update_bits(s2mps11-iodev-regmap,
-   S2MPS11_REG_RTC_CTRL,
+s2mps11-reg,
 s2mps11-mask, s2mps11-mask);
if (!ret)
s2mps11-enabled = true;
@@ -74,7 +75,7 @@ static void s2mps11_clk_unprepare(struct clk_hw *hw)
struct s2mps11_clk *s2mps11 = to_s2mps11_clk(hw);
int ret;
 
-   ret = regmap_update_bits(s2mps11-iodev-regmap, S2MPS11_REG_RTC_CTRL,
+   ret = regmap_update_bits(s2mps11-iodev-regmap, s2mps11-reg,
   s2mps11-mask, ~s2mps11-mask);
 
if (!ret)
@@ -155,6 +156,7 @@ static int s2mps11_clk_probe(struct platform_device *pdev)
struct sec_pmic_dev *iodev = dev_get_drvdata(pdev-dev.parent);
struct s2mps11_clk *s2mps11_clks, *s2mps11_clk;
struct device_node *clk_np = NULL;
+   unsigned int s2mps11_reg;
int i, ret = 0;
u32 val;
 
@@ -169,13 +171,23 @@ static int s2mps11_clk_probe(struct platform_device *pdev)
if (IS_ERR(clk_np))
return PTR_ERR(clk_np);
 
+   switch(platform_get_device_id(pdev)-driver_data) {
+   case S2MPS11X:
+   s2mps11_reg = S2MPS11_REG_RTC_CTRL;
+   break;
+   default:
+   dev_err(pdev-dev, Invalid device type\n);
+   return -EINVAL;
+   };
+
for (i = 0; i  S2MPS11_CLKS_NUM; i++, s2mps11_clk++) {
s2mps11_clk-iodev = iodev;
s2mps11_clk-hw.init = s2mps11_clks_init[i];
s2mps11_clk-mask = 1  i;
+   s2mps11_clk-reg = s2mps11_reg;
 
ret = regmap_read(s2mps11_clk-iodev-regmap,
- S2MPS11_REG_RTC_CTRL, val);
+ s2mps11_clk-reg, val);
if (ret  0)
goto err_reg;
 
@@ -241,7 +253,7 @@ static int s2mps11_clk_remove(struct platform_device *pdev)
 }
 
 static const struct platform_device_id s2mps11_clk_id[] = {
-   { s2mps11-clk, 0},
+   { s2mps11-clk, S2MPS11X},
{ },
 };
 MODULE_DEVICE_TABLE(platform, s2mps11_clk_id);
-- 
1.7.9.5

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

[PATCH 4/4] ARM: dts: Add S5M8767 clock nodes on Arndale board

[Tushar Behera]

Signed-off-by: Tushar Behera tushar.beh...@linaro.org
CC: Kukjin Kim kgene@samsung.com
---
 arch/arm/boot/dts/exynos5250-arndale.dts |7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5250-arndale.dts 
b/arch/arm/boot/dts/exynos5250-arndale.dts
index b77a37e..34b305d 100644
--- a/arch/arm/boot/dts/exynos5250-arndale.dts
+++ b/arch/arm/boot/dts/exynos5250-arndale.dts
@@ -70,6 +70,13 @@
s5m8767,pmic-buck-ds-gpios = gpx2 3 0,
gpx2 4 0,
gpx2 5 0;
+
+   s5m8767_osc: clocks {
+   #clock-cells = 1;
+   clock-output-names = s5m8767_ap,
+   s5m8767_cp, s5m8767_bt;
+   };
+
regulators {
ldo1_reg: LDO1 {
regulator-name = VDD_ALIVE_1.0V;
-- 
1.7.9.5

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

[PATCH 3/4] mfd: sec-core: Add cells for S5M8767-clocks

[Tushar Behera]

S5M8767 chip has 3 crystal oscillators running at 32KHz. These are
supported by s2mps11-clk driver.

Signed-off-by: Tushar Behera tushar.beh...@linaro.org
CC: Lee Jones lee.jo...@linaro.org
---
 drivers/mfd/sec-core.c |4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/mfd/sec-core.c b/drivers/mfd/sec-core.c
index 34c18fb..020b86b 100644
--- a/drivers/mfd/sec-core.c
+++ b/drivers/mfd/sec-core.c
@@ -56,7 +56,9 @@ static struct mfd_cell s5m8767_devs[] = {
.name = s5m8767-pmic,
}, {
.name = s5m-rtc,
-   },
+   }, {
+   .name = s5m8767-clk,
+   }
 };
 
 static struct mfd_cell s2mps11_devs[] = {
-- 
1.7.9.5

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

[PATCH 2/4] clk: clk-s2mps11: Add support for clocks in S5M8767 MFD

[Tushar Behera]

Since clock operation within S2MPS11 and S5M8767 are similar, we can
support both the devices within a single driver.

Signed-off-by: Tushar Behera tushar.beh...@linaro.org
CC: Yadwinder Singh Brar yadi.b...@samsung.com
CC: Mike Turquette mturque...@linaro.org
---
 drivers/clk/Kconfig   |6 --
 drivers/clk/clk-s2mps11.c |5 +
 2 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index 5c51115..7f2aef2 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -65,10 +65,12 @@ config COMMON_CLK_SI5351
  generators.
 
 config COMMON_CLK_S2MPS11
-   tristate Clock driver for S2MPS11 MFD
+   tristate Clock driver for S2MPS11/S5M8767 MFD
depends on MFD_SEC_CORE
---help---
- This driver supports S2MPS11 crystal oscillator clock.
+ This driver supports S2MPS11/S5M8767 crystal oscillator clock. These
+ multi-function devices have 3 fixed-rate oscillators, clocked at
+ 32KHz each.
 
 config CLK_TWL6040
tristate External McPDM functional clock from twl6040
diff --git a/drivers/clk/clk-s2mps11.c b/drivers/clk/clk-s2mps11.c
index 2262cb4..19c075c 100644
--- a/drivers/clk/clk-s2mps11.c
+++ b/drivers/clk/clk-s2mps11.c
@@ -27,6 +27,7 @@
 #include linux/clk-provider.h
 #include linux/platform_device.h
 #include linux/mfd/samsung/s2mps11.h
+#include linux/mfd/samsung/s5m8767.h
 #include linux/mfd/samsung/core.h
 
 #define s2mps11_name(a) (a-hw.init-name)
@@ -175,6 +176,9 @@ static int s2mps11_clk_probe(struct platform_device *pdev)
case S2MPS11X:
s2mps11_reg = S2MPS11_REG_RTC_CTRL;
break;
+   case S5M8767X:
+   s2mps11_reg = S5M8767_REG_CTRL1;
+   break;
default:
dev_err(pdev-dev, Invalid device type\n);
return -EINVAL;
@@ -254,6 +258,7 @@ static int s2mps11_clk_remove(struct platform_device *pdev)
 
 static const struct platform_device_id s2mps11_clk_id[] = {
{ s2mps11-clk, S2MPS11X},
+   { s5m8767-clk, S5M8767X},
{ },
 };
 MODULE_DEVICE_TABLE(platform, s2mps11_clk_id);
-- 
1.7.9.5

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

Re: [PATCH V5 0/3] Add watchdog DT nodes and use syscon regmap interfac to configure pmu registers

[Sachin Kamat]

Hi Leela,

On 31 October 2013 11:30, Leela Krishna Amudala l.kris...@samsung.com wrote:
 This patchset does the following things
 - Adds pmusysreg device node to exynos5.dtsi file
 - Adds watchdog DT nodes to Exynos5250 and 5420
 - Uses syscon regmap interface to configure pmu registers
   to mask/unmask enable/disable of watchdog.

 This patch set is rebased on Kgene's for-next branch and tested on SMDK5420

 Changes since V4:
 - changed the node name from pmusysreg to syscon and node label from 
 pmu_sys_reg to pmu_syscon
 - changed the property name from samsung,pmusysreg to 
 samsung,syscon-phandle
 - used regmap_update_bits instead of remap_read/regmap_write
 - Addressed other comments given by Tomasz Figa t.f...@samsung.com

 Changes since V3:
 - changed the compatible strings for watchdog node
 - splitted up adding pmusysreg node and made it separate patch
 - Addressed comments given by Sachin Kamat sachin.ka...@linaro.org

 Changes since V2:
 - used syscon regmap interface to configure pmu registers in WDT 
 driver
   (suggested by Tomasz Figa t.f...@samsung.com)

 Changes since V1:
 - Added new compatible string for Exynos5 SoCs
 - Introduced quirk mechanism to program PMU registers
 - Addressed comments given by Tomasz Figa t.f...@samsung.com

 Leela Krishna Amudala (3):
   ARM: dts: Add pmu sysreg node to Exynos5 dtsi file
   ARM: dts: add watchdog device nodes for Exynos5250 and Exynos5420
   watchdog: s3c2410_wdt: use syscon regmap interface to configure pmu
 register

  .../devicetree/bindings/watchdog/samsung-wdt.txt   |   22 ++-
  arch/arm/boot/dts/exynos5.dtsi |   12 +-
  arch/arm/boot/dts/exynos5250.dtsi  |7 +-
  arch/arm/boot/dts/exynos5420.dtsi  |   10 ++
  drivers/watchdog/s3c2410_wdt.c |  150 
 +---
  5 files changed, 175 insertions(+), 26 deletions(-)

 --
 1.7.10.4


Series looks good. However, you would need to add select MFD_SYSCON option to
watchdog Kconfig for ARCH_EXYNOS5.

Tested this series on Origen (4210), Arndale (5250) and SMDK5420 boards.

Tested-by: Sachin Kamat sachin.ka...@linaro.org
Reviewed-by: Sachin Kamat sachin.ka...@linaro.org

-- 
With warm regards,
Sachin
--
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/4] dt: exynos5420: Enable support for DWC3 controller

[Vivek Gautam]

Add device tree nodes for DWC3 controller present on
Exynos 5420 SoC, to enable support for USB 3.0.

Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
 arch/arm/boot/dts/exynos5420.dtsi |   38 +++-
 1 files changed, 36 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/exynos5420.dtsi 
b/arch/arm/boot/dts/exynos5420.dtsi
index 5df3308..4f676c1 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -236,7 +236,24 @@
status = disabled;
};
 
-   usbphy@1210 {
+   usb@1200 {
+   compatible = samsung,exynos5250-dwusb3;
+   clocks = clock 366;
+   clock-names = usbdrd30;
+   #address-cells = 1;
+   #size-cells = 1;
+   ranges;
+
+   dwc3 {
+   compatible = synopsys,dwc3;
+   reg = 0x1200 0x1;
+   interrupts = 0 72 0;
+   phys = usb3_phy0;
+   phy-names = usb3-phy;
+   };
+   };
+
+   usb3_phy0: usbphy@1210 {
compatible = samsung,exynos5420-usb3phy;
reg = 0x1210 0x100 0x10040704 0x4;
clocks = clock 366, clock 1, clock 152;
@@ -244,7 +261,24 @@
#phy-cells = 0;
};
 
-   usbphy@1250 {
+   usb@1240 {
+   compatible = samsung,exynos5250-dwusb3;
+   clocks = clock 367;
+   clock-names = usbdrd30;
+   #address-cells = 1;
+   #size-cells = 1;
+   ranges;
+
+   dwc3 {
+   compatible = synopsys,dwc3;
+   reg = 0x1240 0x1;
+   interrupts = 0 73 0;
+   phys = usb3_phy1;
+   phy-names = usb3-phy;
+   };
+   };
+
+   usb3_phy1: usbphy@1250 {
compatible = samsung,exynos5420-usb3phy;
reg = 0x1250 0x100 0x10040708 0x4;
clocks = clock 367, clock 1, clock 153;
-- 
1.7.6.5

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

[PATCH 3/4] dt: exynos5420: Enable support for USB 3.0 PHY controller

[Vivek Gautam]

Add device tree nodes for USB 3.0 PHY present alongwith
USB 3.0 controller Exynos 5420 SoC. This phy driver is
based on generic phy framework.

Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
 arch/arm/boot/dts/exynos5420.dtsi |   16 
 1 files changed, 16 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/exynos5420.dtsi 
b/arch/arm/boot/dts/exynos5420.dtsi
index d537cd7..5df3308 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -235,4 +235,20 @@
io-channel-ranges;
status = disabled;
};
+
+   usbphy@1210 {
+   compatible = samsung,exynos5420-usb3phy;
+   reg = 0x1210 0x100 0x10040704 0x4;
+   clocks = clock 366, clock 1, clock 152;
+   clock-names = phy, usb3drd, sclk_usbphy30;
+   #phy-cells = 0;
+   };
+
+   usbphy@1250 {
+   compatible = samsung,exynos5420-usb3phy;
+   reg = 0x1250 0x100 0x10040708 0x4;
+   clocks = clock 367, clock 1, clock 153;
+   clock-names = phy, usb3drd, sclk_usbphy30;
+   #phy-cells = 0;
+   };
 };
-- 
1.7.6.5

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

[PATCH 2/4] dt: exynos5250: Enable support for generic USB 3.0 phy

[Vivek Gautam]

Update device tree bindings for DWC3 controller and
USB 3.0 phy present on Exynos 5250 SoC, to start using
the phy driver based on generic phy framework.

Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
 arch/arm/boot/dts/exynos5250.dtsi |   17 ++---
 1 files changed, 6 insertions(+), 11 deletions(-)

diff --git a/arch/arm/boot/dts/exynos5250.dtsi 
b/arch/arm/boot/dts/exynos5250.dtsi
index bbac42a..31a6595 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -472,22 +472,17 @@
compatible = synopsys,dwc3;
reg = 0x1200 0x1;
interrupts = 0 72 0;
-   usb-phy = usb2_phy usb3_phy;
+   phys = usb3_phy;
+   phy-names = usb3-phy;
};
};
 
usb3_phy: usbphy@1210 {
compatible = samsung,exynos5250-usb3phy;
-   reg = 0x1210 0x100;
-   clocks = clock 1, clock 286;
-   clock-names = ext_xtal, usbdrd30;
-   #address-cells = 1;
-   #size-cells = 1;
-   ranges;
-
-   usbphy-sys {
-   reg = 0x10040704 0x8;
-   };
+   reg = 0x1210 0x100 0x10040704 0x4;
+   clocks = clock 286, clock 1;
+   clock-names = phy, usb3drd;
+   #phy-cells = 0;
};
 
usb@1211 {
-- 
1.7.6.5

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

[PATCH RFC 0/4] Add Exynos5 USB 3.0 phy driver based on generic PHY framework

[Vivek Gautam]

Adding a phy driver for USB 3.0 PHY controller present on Exynos5
series of SoCs alongwith DWC3 controller for USB 3.0 operations.

This driver is inline with Kamil's USB 2.0 phy driver. [1]
Few functions used to translate ref clock rate are common to
Kamil's changes. So we can figure out how to re-use them across
these drivers.

Theses patches are based on usb-next branch and tested with
Kishon's patches for adapting DWC3 to generic phy framework, [2]
on smdk5250 as well as smdk5420 board.

[1] [PATCH 0/5] phy: Add new Exynos USB PHY driver
https://lkml.org/lkml/2013/10/25/230
[2] [PATCH v2 1/7] usb: dwc3: get usb_phy only if the platform indicates the 
presence of PHY's
(http://www.spinics.net/lists/linux-usb/msg95733.html)
[PATCH v2 2/7] usb: dwc3: adapt dwc3 core to use Generic PHY Framework
(http://www.spinics.net/lists/linux-usb/msg95734.html)

Vivek Gautam (4):
  phy: Add new Exynos5 USB 3.0 PHY driver
  dt: exynos5250: Enable support for generic USB 3.0 phy
  dt: exynos5420: Enable support for USB 3.0 PHY controller
  dt: exynos5420: Enable support for DWC3 controller

 .../devicetree/bindings/phy/samsung-phy.txt|   20 +
 arch/arm/boot/dts/exynos5250.dtsi  |   17 +-
 arch/arm/boot/dts/exynos5420.dtsi  |   50 ++
 drivers/phy/Kconfig|7 +
 drivers/phy/Makefile   |1 +
 drivers/phy/phy-exynos5-usb3.c |  562 
 6 files changed, 646 insertions(+), 11 deletions(-)
 create mode 100644 drivers/phy/phy-exynos5-usb3.c

-- 
1.7.6.5

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

[PATCH RFC 1/4] phy: Add new Exynos5 USB 3.0 PHY driver

[Vivek Gautam]

Add a new driver for the USB 3.0 PHY on Exynos5 series of SoCs.
The new driver uses the generic PHY framework and will interact
with DWC3 controller present on Exynos5 series of SoCs.

Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
 .../devicetree/bindings/phy/samsung-phy.txt|   20 +
 drivers/phy/Kconfig|7 +
 drivers/phy/Makefile   |1 +
 drivers/phy/phy-exynos5-usb3.c |  562 
 4 files changed, 590 insertions(+), 0 deletions(-)
 create mode 100644 drivers/phy/phy-exynos5-usb3.c

diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt 
b/Documentation/devicetree/bindings/phy/samsung-phy.txt
index c0fccaa..9b5c111 100644
--- a/Documentation/devicetree/bindings/phy/samsung-phy.txt
+++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt
@@ -20,3 +20,23 @@ Required properties:
 - compatible : should be samsung,exynos5250-dp-video-phy;
 - reg : offset and length of the Display Port PHY register set;
 - #phy-cells : from the generic PHY bindings, must be 0;
+
+Samsung Exynos5 SoC seiries USB 3.0 PHY controller
+--
+
+Required properties:
+- compatible :
+   should be samsung,exynos5250-usb3phy for exynos5250 SoC
+   should be samsung,exynos5420-usb3phy for exynos5420 SoC
+- reg : Register offset and length array
+   - first field corresponds to USB 3.0 PHY register set;
+   - second field corresponds to PHY power isolation register
+ present in PMU;
+- clocks: Clock IDs array as required by the controller
+- clock-names: names of clocks correseponding to IDs in the clock property;
+   Required clocks:
+   - first clock is main PHY clock (same as USB 3.0 controller IP clock)
+   - second clock is reference clock (usually crystal clock)
+   optional clock:
+   - third clock is special clock used by PHY for operation
+- #phy-cells : from the generic PHY bindings, must be 0;
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index a344f3d..9a100c6 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -51,4 +51,11 @@ config PHY_EXYNOS_DP_VIDEO
help
  Support for Display Port PHY found on Samsung EXYNOS SoCs.
 
+config PHY_EXYNOS5_USB3
+   tristate Exynos5 SoC series USB 3.0 PHY driver
+   depends on ARCH_EXYNOS5
+   select GENERIC_PHY
+   help
+ Enable USB 3.0 PHY support for Exynos 5 SoC series
+
 endmenu
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index d0caae9..9c06a61 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -7,3 +7,4 @@ obj-$(CONFIG_PHY_EXYNOS_DP_VIDEO)   += phy-exynos-dp-video.o
 obj-$(CONFIG_PHY_EXYNOS_MIPI_VIDEO)+= phy-exynos-mipi-video.o
 obj-$(CONFIG_OMAP_USB2)+= phy-omap-usb2.o
 obj-$(CONFIG_TWL4030_USB)  += phy-twl4030-usb.o
+obj-$(CONFIG_PHY_EXYNOS5_USB3) += phy-exynos5-usb3.o
diff --git a/drivers/phy/phy-exynos5-usb3.c b/drivers/phy/phy-exynos5-usb3.c
new file mode 100644
index 000..b9a2674
--- /dev/null
+++ b/drivers/phy/phy-exynos5-usb3.c
@@ -0,0 +1,562 @@
+/*
+ * Samsung EXYNOS5 SoC series USB 3.0 PHY driver
+ *
+ * Copyright (C) 2013 Samsung Electronics Co., Ltd.
+ * Author: Vivek Gautam gautam.vi...@samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/clk.h
+#include linux/delay.h
+#include linux/io.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/of.h
+#include linux/of_address.h
+#include linux/phy/phy.h
+#include linux/platform_device.h
+#include linux/mutex.h
+
+/* Exynos USB PHY registers */
+#define EXYNOS5_FSEL_9MHZ6 0x0
+#define EXYNOS5_FSEL_10MHZ 0x1
+#define EXYNOS5_FSEL_12MHZ 0x2
+#define EXYNOS5_FSEL_19MHZ20x3
+#define EXYNOS5_FSEL_20MHZ 0x4
+#define EXYNOS5_FSEL_24MHZ 0x5
+#define EXYNOS5_FSEL_50MHZ 0x7
+
+/* EXYNOS5: USB 3.0 DRD PHY registers */
+#define EXYNOS5_DRD_LINKSYSTEM (0x04)
+
+#define LINKSYSTEM_FLADJ_MASK  (0x3f  1)
+#define LINKSYSTEM_FLADJ(_x)   ((_x)  1)
+#define LINKSYSTEM_XHCI_VERSION_CONTROL(0x1  27)
+
+#define EXYNOS5_DRD_PHYUTMI(0x08)
+
+#define PHYUTMI_OTGDISABLE (0x1  6)
+#define PHYUTMI_FORCESUSPEND   (0x1  1)
+#define PHYUTMI_FORCESLEEP (0x1  0)
+
+#define EXYNOS5_DRD_PHYPIPE(0x0c)
+
+#define EXYNOS5_DRD_PHYCLKRST  (0x10)
+
+#define PHYCLKRST_SSC_REFCLKSEL_MASK   (0xff  23)
+#define PHYCLKRST_SSC_REFCLKSEL(_x)((_x)  23)
+
+#define PHYCLKRST_SSC_RANGE_MASK   (0x03  21)
+#define PHYCLKRST_SSC_RANGE(_x) 

[PATCH 1/1] ARM: dts: Enable watchdog in Exynos4

[Sachin Kamat]

Enabled watchdog in Exynos4.

Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
---
 arch/arm/boot/dts/exynos4.dtsi |1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index ce24edba7f6d..b7378154c0a1 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -196,7 +196,6 @@
interrupts = 0 43 0;
clocks = clock 345;
clock-names = watchdog;
-   status = disabled;
};
 
rtc@1007 {
-- 
1.7.9.5

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

Re: [PATCH 1/2] ARM: dts: Update display clock frequency for Origen-4210

[Sachin Kamat]

On 26 September 2013 10:20, Sachin Kamat sachin.ka...@linaro.org wrote:
 From: Tushar Behera tushar.beh...@linaro.org

 As per the timing information for supported panel, the value should
 be between 47.2 MHz to 47.9 MHz for 60Hz refresh rate.

 Total horizontal pixels = 1024 (x-res) + 80 (margin) + 48 (hsync) = 1152
 Total vertical pixels = 600 (y-res) + 80 (margin) + 3 (vsync) = 653

 Target pixel clock rate for refresh rate @60 Hz
 = 1152 * 653 * 60 = 47208960 Hz ~ 47.5 MHz

 Signed-off-by: Tushar Behera tushar.beh...@linaro.org
 Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
 ---
  arch/arm/boot/dts/exynos4210-origen.dts |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/arch/arm/boot/dts/exynos4210-origen.dts 
 b/arch/arm/boot/dts/exynos4210-origen.dts
 index 382d8c7..6906e8a 100644
 --- a/arch/arm/boot/dts/exynos4210-origen.dts
 +++ b/arch/arm/boot/dts/exynos4210-origen.dts
 @@ -301,7 +301,7 @@
 display-timings {
 native-mode = timing0;
 timing0: timing {
 -   clock-frequency = 5;
 +   clock-frequency = 4750;
 hactive = 1024;
 vactive = 600;
 hfront-porch = 64;
 --
 1.7.9.5


Ping Kukjin.

-- 
With warm regards,
Sachin
--
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] spi: s3c64xx: Enable Word transfer

[Rajeshwari Birje]

Hi Mark Brown ,

On Wed, Oct 30, 2013 at 10:36 PM, Tomasz Figa t.f...@samsung.com wrote:
 On Wednesday 30 of October 2013 10:00:29 Mark Brown wrote:
 On Wed, Oct 30, 2013 at 11:52:54AM +0530, Rajeshwari Birje wrote:

  The following patch already sets bits_per_word_mask for
  drivers/spi/spi-s3c64xx.c in s3c64xx_spi_probe, hence I had a doubt do
  I need to set the same again.

 OK, so how did this work before then?  You're just adding new code but
 the driver was previously claiming to support different bits per word
 (and now I look at the code there is some handling for that in code).
 Is this a bug fix?
No idea if it worked before, but now if I try to do 16 bit transfer
without my patch, I get following error.
Xfer length(1) not a multiple of word size(2)
I guess we can consider this as a bug fix then for word transfer.

 That's a good question. Rajeshwari, what SPI device did you test this
 patch with? Does it have a driver in mainline kernel?
@Tomasz: I tested it for W25Q32DW Winbond device which is already has
a driver in mainline Kernel

 Best regards,
 Tomasz

-- 
Regards,
Rajeshwari Shinde
--
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 19/51] DMA-API: media: dt3155v4l: replace dma_set_mask()+dma_set_coherent_mask() with new helper

[Mauro Carvalho Chehab]

Hi Russell,

Em Mon, 30 Sep 2013 13:57:47 +0200
Hans Verkuil hverk...@xs4all.nl escreveu:

 On 09/19/2013 11:44 PM, Russell King wrote:
  Replace the following sequence:
  
  dma_set_mask(dev, mask);
  dma_set_coherent_mask(dev, mask);
  
  with a call to the new helper dma_set_mask_and_coherent().
  
  Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
 
 Acked-by: Hans Verkuil hans.verk...@cisco.com

Somehow, I lost your original post (I got unsubscribed on a few days 
from all vger mailing lists at the end of september).

I suspect that you want to sent this via your tree, right?
If so:

Acked-by: Mauro Carvalho Chehab m.che...@samsung.com

 
 Regards,
 
   Hans
 
  ---
   drivers/staging/media/dt3155v4l/dt3155v4l.c |5 +
   1 files changed, 1 insertions(+), 4 deletions(-)
  
  diff --git a/drivers/staging/media/dt3155v4l/dt3155v4l.c 
  b/drivers/staging/media/dt3155v4l/dt3155v4l.c
  index 90d6ac4..081407b 100644
  --- a/drivers/staging/media/dt3155v4l/dt3155v4l.c
  +++ b/drivers/staging/media/dt3155v4l/dt3155v4l.c
  @@ -901,10 +901,7 @@ dt3155_probe(struct pci_dev *pdev, const struct 
  pci_device_id *id)
  int err;
  struct dt3155_priv *pd;
   
  -   err = dma_set_mask(pdev-dev, DMA_BIT_MASK(32));
  -   if (err)
  -   return -ENODEV;
  -   err = dma_set_coherent_mask(pdev-dev, DMA_BIT_MASK(32));
  +   err = dma_set_mask_and_coherent(pdev-dev, DMA_BIT_MASK(32));
  if (err)
  return -ENODEV;
  pd = kzalloc(sizeof(*pd), GFP_KERNEL);
  
 
 --
 To unsubscribe from this list: send the line unsubscribe linux-media in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html


-- 

Cheers,
Mauro
--
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 1/3] ARM: dts: Add pmu sysreg node to Exynos5 dtsi file

[Tomasz Figa]

Hi Leela,

On Thursday 31 of October 2013 11:30:48 Leela Krishna Amudala wrote:
 This patch adds pmusysreg node to Exynos5 dtsi file to handle PMU
 register accesses in a centralized way using syscon driver
 
 Signed-off-by: Leela Krishna Amudala l.kris...@samsung.com
 ---
  arch/arm/boot/dts/exynos5.dtsi |5 +
  1 file changed, 5 insertions(+)

Reviewed-by: Tomasz Figa t.f...@samsung.com

Best regards,
Tomasz

--
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 2/3] ARM: dts: add watchdog device nodes for Exynos5250 and Exynos5420

[Tomasz Figa]

Hi Leela,

On Thursday 31 of October 2013 11:30:49 Leela Krishna Amudala wrote:
 Adds watchdog device nodes to the DT device list for Exynos5250 and Exynos5420
 
 Signed-off-by: Leela Krishna Amudala l.kris...@samsung.com
 ---
  arch/arm/boot/dts/exynos5.dtsi|7 ---
  arch/arm/boot/dts/exynos5250.dtsi |7 ++-
  arch/arm/boot/dts/exynos5420.dtsi |   10 ++
  3 files changed, 16 insertions(+), 8 deletions(-)
[snip]
 diff --git a/arch/arm/boot/dts/exynos5250.dtsi 
 b/arch/arm/boot/dts/exynos5250.dtsi
 index c4a8662..7e4867f 100644
 --- a/arch/arm/boot/dts/exynos5250.dtsi
 +++ b/arch/arm/boot/dts/exynos5250.dtsi
 @@ -158,9 +158,14 @@
   interrupts = 0 47 0;
   };
  
 - watchdog {
 + watchdog@101D {
 + compatible = samsung,exynos5250-wdt;
 + reg = 0x101D 0x100;
 + interrupts = 0 42 0;
   clocks = clock 336;
   clock-names = watchdog;
 + samsung,syscon-phandle = pmu_syscon;
 + status = okay;

You can drop the status property here, as it's okay by default.

   };
  
   g2d@1085 {
 diff --git a/arch/arm/boot/dts/exynos5420.dtsi 
 b/arch/arm/boot/dts/exynos5420.dtsi
 index 6ffefd1..8585fe7 100644
 --- a/arch/arm/boot/dts/exynos5420.dtsi
 +++ b/arch/arm/boot/dts/exynos5420.dtsi
 @@ -369,4 +369,14 @@
   clock-names = gscl;
   samsung,power-domain = gsc_pd;
   };
 +
 +watchdog@101D {

Is it just my mail client or there is an indentation issue here?

 + compatible = samsung,exynos5420-wdt;
 + reg = 0x101D 0x100;
 + interrupts = 0 42 0;
 + clocks = clock 316;
 + clock-names = watchdog;
 + samsung,syscon-phandle = pmu_syscon;
 + status = okay;

Status property can be dropped.

 +};

Wrong indentation?

Best regards,
Tomasz

--
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/3] watchdog: s3c2410_wdt: use syscon regmap interface to configure pmu register

[Tomasz Figa]

Hi Leela,

On Thursday 31 of October 2013 11:30:50 Leela Krishna Amudala wrote:
 The syscon regmap interface is used to configure AUTOMATIC_WDT_RESET_DISABLE
 and MASK_WDT_RESET_REQUEST registers of PMU to mask/unmask enable/disable of
 watchdog in probe and s2r scenarios.
 
 Signed-off-by: Leela Krishna Amudala l.kris...@samsung.com
 ---
  .../devicetree/bindings/watchdog/samsung-wdt.txt   |   22 ++-
  drivers/watchdog/s3c2410_wdt.c |  150 
 +---
  2 files changed, 154 insertions(+), 18 deletions(-)

This patch looks better now, but there are still several issues remaining.
Please see my comments inline.

 diff --git a/Documentation/devicetree/bindings/watchdog/samsung-wdt.txt 
 b/Documentation/devicetree/bindings/watchdog/samsung-wdt.txt
 index 2aa486c..0b8aa4b 100644
 --- a/Documentation/devicetree/bindings/watchdog/samsung-wdt.txt
 +++ b/Documentation/devicetree/bindings/watchdog/samsung-wdt.txt
 @@ -5,10 +5,30 @@ after a preset amount of time during which the WDT reset 
 event has not
  occurred.
  
  Required properties:
 -- compatible : should be samsung,s3c2410-wdt
 +- compatible : should be one among the following
 + (a) samsung,s3c2410-wdt for Exynos4 and previous SoCs
 + (b) samsung,exynos5250-wdt for Exynos5250
 + (c) samsung,exynos5420-wdt for Exynos5420
 +
  - reg : base physical address of the controller and length of memory mapped
   region.
  - interrupts : interrupt number to the cpu.
 +- samsung,syscon-phandle : reference to syscon node (This property required 
 only
 + in case of compatible being samsung,exynos5250-wdt or 
 samsung,exynos5420-wdt.
 + In case of Exynos5250 and 5420 this property points to syscon node 
 holding the PMU
 + base address)
  
  Optional properties:
  - timeout-sec : contains the watchdog timeout in seconds.
 +
 +Example:
 +
 +watchdog@101D {
 + compatible = samsung,exynos5250-wdt;
 + reg = 0x101D 0x100;
 + interrupts = 0 42 0;
 + clocks = clock 336;
 + clock-names = watchdog;
 + samsung,sysreg = pmu_sys_reg;

Shouldn't it be samsung,syscon-phandle?

 + status = okay;

The status property is not a part of this binding, so can be dropped
from the example.

 +};
 diff --git a/drivers/watchdog/s3c2410_wdt.c b/drivers/watchdog/s3c2410_wdt.c
 index 23aad7c..235d160 100644
 --- a/drivers/watchdog/s3c2410_wdt.c
 +++ b/drivers/watchdog/s3c2410_wdt.c
 @@ -41,6 +41,8 @@
  #include linux/slab.h
  #include linux/err.h
  #include linux/of.h
 +#include linux/mfd/syscon.h
 +#include linux/regmap.h
  
  #define S3C2410_WTCON0x00
  #define S3C2410_WTDAT0x04
 @@ -61,6 +63,10 @@
  #define CONFIG_S3C2410_WATCHDOG_ATBOOT   (0)
  #define CONFIG_S3C2410_WATCHDOG_DEFAULT_TIME (15)
  
 +#define WDT_DISABLE_REG_OFFSET   0x0408
 +#define WDT_MASK_RESET_REG_OFFSET0x040c
 +#define QUIRK_NEEDS_PMU_CONFIG   (1  0)
 +
  static bool nowayout = WATCHDOG_NOWAYOUT;
  static int tmr_margin;
  static int tmr_atboot= CONFIG_S3C2410_WATCHDOG_ATBOOT;
 @@ -84,18 +90,61 @@ MODULE_PARM_DESC(soft_noboot, Watchdog action, set to 1 
 to ignore reboots, 
   0 to reboot (default 0));
  MODULE_PARM_DESC(debug, Watchdog debug, set to 1 for debug (default 0));
  
 +struct s3c2410_wdt_variant {
 + int disable_reg;
 + int mask_reset_reg;
 + int mask_bit;
 + u32 quirks;

nit: To avoid the need of changing the indentation in future, if fields
with longer types gets added, I would simply separate type name from field
name using a single space.

 +};
 +
  struct s3c2410_wdt {
 - struct device   *dev;
 - struct clk  *clock;
 - void __iomem*reg_base;
 - unsigned intcount;
 - spinlock_t  lock;
 - unsigned long   wtcon_save;
 - unsigned long   wtdat_save;
 - struct watchdog_device  wdt_device;
 - struct notifier_block   freq_transition;
 + struct device   *dev;
 + struct clk  *clock;
 + void __iomem*reg_base;
 + unsigned intcount;
 + spinlock_t  lock;
 + unsigned long   wtcon_save;
 + unsigned long   wtdat_save;
 + struct watchdog_device  wdt_device;
 + struct notifier_block   freq_transition;
 + struct s3c2410_wdt_variant  *pmu_config;
 + struct regmap   *pmureg;

And here's an example of such (unnecessary) change. I believe it would
be better to keep indendation of other fields as is, use single space for
the new field and then change remaining fields in a separate patch,
outside of this series.

 +};
 +
 +#ifdef CONFIG_OF
 +static struct s3c2410_wdt_variant pmu_config_s3c2410 = {

static const struct

 + .disable_reg = 0x0,
 + .mask_reset_reg = 0x0,
 + .mask_bit = 0,

Re: [PATCH V4] spi: s3c64xx: Enable Word transfer

[Tomasz Figa]

Hi Rajeshwari,

On Thursday 31 of October 2013 16:17:15 Rajeshwari Birje wrote:
 Hi Mark Brown ,
 
 On Wed, Oct 30, 2013 at 10:36 PM, Tomasz Figa t.f...@samsung.com wrote:
  On Wednesday 30 of October 2013 10:00:29 Mark Brown wrote:
  On Wed, Oct 30, 2013 at 11:52:54AM +0530, Rajeshwari Birje wrote:
 
   The following patch already sets bits_per_word_mask for
   drivers/spi/spi-s3c64xx.c in s3c64xx_spi_probe, hence I had a doubt do
   I need to set the same again.
 
  OK, so how did this work before then?  You're just adding new code but
  the driver was previously claiming to support different bits per word
  (and now I look at the code there is some handling for that in code).
  Is this a bug fix?
 No idea if it worked before, but now if I try to do 16 bit transfer
 without my patch, I get following error.
 Xfer length(1) not a multiple of word size(2)
 I guess we can consider this as a bug fix then for word transfer.
 
  That's a good question. Rajeshwari, what SPI device did you test this
  patch with? Does it have a driver in mainline kernel?
 @Tomasz: I tested it for W25Q32DW Winbond device which is already has
 a driver in mainline Kernel

The driver as of today's linux-next does not seem to support word
transfers. Do you have some additional, out of tree patches that add
such support?

Best regards,
Tomasz

--
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] ARM: dts: Fix sysreg node name in exynos4.dtsi

[Tomasz Figa]

On Thursday 31 of October 2013 10:16:53 Sachin Kamat wrote:
 Fix the name as per DT node naming convention.
 - rename the node to syscon which is a more generic name.
 - append the register value to the node name.
 
 Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
 ---
 Changes since v1:
  * Renamed the node to syscon as suggested by Tomasz Figa.
 ---
  arch/arm/boot/dts/exynos4.dtsi |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

Reviewed-by: Tomasz Figa t.f...@samsung.com

Best regards,
Tomasz

--
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/3] watchdog: s3c2410_wdt: use syscon regmap interface to configure pmu register

[Guenter Roeck]

On 10/31/2013 05:29 AM, Tomasz Figa wrote:

Hi Leela,

On Thursday 31 of October 2013 11:30:50 Leela Krishna Amudala wrote:

The syscon regmap interface is used to configure AUTOMATIC_WDT_RESET_DISABLE
and MASK_WDT_RESET_REQUEST registers of PMU to mask/unmask enable/disable of
watchdog in probe and s2r scenarios.

Signed-off-by: Leela Krishna Amudala l.kris...@samsung.com
---
  .../devicetree/bindings/watchdog/samsung-wdt.txt   |   22 ++-
  drivers/watchdog/s3c2410_wdt.c |  150 +---
  2 files changed, 154 insertions(+), 18 deletions(-)


This patch looks better now, but there are still several issues remaining.
Please see my comments inline.


diff --git a/Documentation/devicetree/bindings/watchdog/samsung-wdt.txt 
b/Documentation/devicetree/bindings/watchdog/samsung-wdt.txt
index 2aa486c..0b8aa4b 100644
--- a/Documentation/devicetree/bindings/watchdog/samsung-wdt.txt
+++ b/Documentation/devicetree/bindings/watchdog/samsung-wdt.txt
@@ -5,10 +5,30 @@ after a preset amount of time during which the WDT reset 
event has not
  occurred.

  Required properties:
-- compatible : should be samsung,s3c2410-wdt
+- compatible : should be one among the following
+   (a) samsung,s3c2410-wdt for Exynos4 and previous SoCs
+   (b) samsung,exynos5250-wdt for Exynos5250
+   (c) samsung,exynos5420-wdt for Exynos5420
+
  - reg : base physical address of the controller and length of memory mapped
region.
  - interrupts : interrupt number to the cpu.
+- samsung,syscon-phandle : reference to syscon node (This property required 
only
+   in case of compatible being samsung,exynos5250-wdt or 
samsung,exynos5420-wdt.
+   In case of Exynos5250 and 5420 this property points to syscon node 
holding the PMU
+   base address)

  Optional properties:
  - timeout-sec : contains the watchdog timeout in seconds.
+
+Example:
+
+watchdog@101D {
+   compatible = samsung,exynos5250-wdt;
+   reg = 0x101D 0x100;
+   interrupts = 0 42 0;
+   clocks = clock 336;
+   clock-names = watchdog;
+   samsung,sysreg = pmu_sys_reg;


Shouldn't it be samsung,syscon-phandle?


+   status = okay;


The status property is not a part of this binding, so can be dropped
from the example.


+};
diff --git a/drivers/watchdog/s3c2410_wdt.c b/drivers/watchdog/s3c2410_wdt.c
index 23aad7c..235d160 100644
--- a/drivers/watchdog/s3c2410_wdt.c
+++ b/drivers/watchdog/s3c2410_wdt.c
@@ -41,6 +41,8 @@
  #include linux/slab.h
  #include linux/err.h
  #include linux/of.h
+#include linux/mfd/syscon.h
+#include linux/regmap.h

  #define S3C2410_WTCON 0x00
  #define S3C2410_WTDAT 0x04
@@ -61,6 +63,10 @@
  #define CONFIG_S3C2410_WATCHDOG_ATBOOT(0)
  #define CONFIG_S3C2410_WATCHDOG_DEFAULT_TIME  (15)

+#define WDT_DISABLE_REG_OFFSET 0x0408
+#define WDT_MASK_RESET_REG_OFFSET  0x040c
+#define QUIRK_NEEDS_PMU_CONFIG (1  0)
+
  static bool nowayout  = WATCHDOG_NOWAYOUT;
  static int tmr_margin;
  static int tmr_atboot = CONFIG_S3C2410_WATCHDOG_ATBOOT;
@@ -84,18 +90,61 @@ MODULE_PARM_DESC(soft_noboot, Watchdog action, set to 1 to 
ignore reboots, 
0 to reboot (default 0));
  MODULE_PARM_DESC(debug, Watchdog debug, set to 1 for debug (default 0));

+struct s3c2410_wdt_variant {
+   int disable_reg;
+   int mask_reset_reg;
+   int mask_bit;
+   u32 quirks;


nit: To avoid the need of changing the indentation in future, if fields
with longer types gets added, I would simply separate type name from field
name using a single space.


+};
+
  struct s3c2410_wdt {
-   struct device   *dev;
-   struct clk  *clock;
-   void __iomem*reg_base;
-   unsigned intcount;
-   spinlock_t  lock;
-   unsigned long   wtcon_save;
-   unsigned long   wtdat_save;
-   struct watchdog_device  wdt_device;
-   struct notifier_block   freq_transition;
+   struct device   *dev;
+   struct clk  *clock;
+   void __iomem*reg_base;
+   unsigned intcount;
+   spinlock_t  lock;
+   unsigned long   wtcon_save;
+   unsigned long   wtdat_save;
+   struct watchdog_device  wdt_device;
+   struct notifier_block   freq_transition;
+   struct s3c2410_wdt_variant  *pmu_config;
+   struct regmap   *pmureg;


And here's an example of such (unnecessary) change. I believe it would
be better to keep indendation of other fields as is, use single space for
the new field and then change remaining fields in a separate patch,
outside of this series.


+};
+
+#ifdef CONFIG_OF
+static struct s3c2410_wdt_variant pmu_config_s3c2410 = {


static const struct


+   .disable_reg = 0x0,
+   .mask_reset_reg = 0x0,
+   

Re: [PATCH v2] videobuf2: Add missing lock held on vb2_fop_relase

[Mauro Carvalho Chehab]

Em Sat, 19 Oct 2013 18:07:57 +0200
Ricardo Ribalda ricardo.riba...@gmail.com escreveu:

 vb2_fop_relase does not held the lock although it is modifying the
 queue-owner field.
 
 This could lead to race conditions on the vb2_perform_io function
 when multiple applications are accessing the video device via
 read/write API:
 
 [ 308.297741] BUG: unable to handle kernel NULL pointer dereference at
 0260
 [ 308.297759] IP: [a07a9fd2] vb2_perform_fileio+0x372/0x610
 [videobuf2_core]
 [ 308.297794] PGD 159719067 PUD 158119067 PMD 0
 [ 308.297812] Oops:  #1 SMP
 [ 308.297826] Modules linked in: qt5023_video videobuf2_dma_sg
 qtec_xform videobuf2_vmalloc videobuf2_memops videobuf2_core
 qtec_white qtec_mem gpio_xilinx qtec_cmosis qtec_pcie fglrx(PO)
 spi_xilinx spi_bitbang qt5023
 [ 308.297888] CPU: 1 PID: 2189 Comm: java Tainted: P O 3.11.0-qtec-standard #1
 [ 308.297919] Hardware name: QTechnology QT5022/QT5022, BIOS
 PM_2.1.0.309 X64 05/23/2013
 [ 308.297952] task: 8801564e1690 ti: 88014dc02000 task.ti:
 88014dc02000
 [ 308.297962] RIP: 0010:[a07a9fd2] [a07a9fd2]
 vb2_perform_fileio+0x372/0x610 [videobuf2_core]
 [ 308.297985] RSP: 0018:88014dc03df8 EFLAGS: 00010202
 [ 308.297995] RAX:  RBX: 880158a23000 RCX: 
 dead00100100
 [ 308.298003] RDX:  RSI: dead00200200 RDI: 
 
 [ 308.298012] RBP: 88014dc03e58 R08:  R09: 
 0001
 [ 308.298020] R10: ea00051e8380 R11: 88014dc03fd8 R12: 
 880158a23070
 [ 308.298029] R13: 8801549040b8 R14: 00198000 R15: 
 01887e60
 [ 308.298040] FS: 7f65130d5700() GS:88015ed0()
 knlGS:
 [ 308.298049] CS: 0010 DS:  ES:  CR0: 80050033
 [ 308.298057] CR2: 0260 CR3: 00015963 CR4: 
 07e0
 [ 308.298064] Stack:
 [ 308.298071] 880156416c00 00198000 
 88010001
 [ 308.298087] 88014dc03f50 810a79ca 00020001
 880154904718
 [ 308.298101] 880156416c00 00198000 880154904338
 88014dc03f50
 [ 308.298116] Call Trace:
 [ 308.298143] [a07aa3c4] vb2_read+0x14/0x20 [videobuf2_core]
 [ 308.298198] [a07aa494] vb2_fop_read+0xc4/0x120 [videobuf2_core]
 [ 308.298252] [8154ee9e] v4l2_read+0x7e/0xc0
 [ 308.298296] [8116e639] vfs_read+0xa9/0x160
 [ 308.298312] [8116e882] SyS_read+0x52/0xb0
 [ 308.298328] [81784179] tracesys+0xd0/0xd5
 [ 308.298335] Code: e5 d6 ff ff 83 3d be 24 00 00 04 89 c2 4c 8b 45 b0
 44 8b 4d b8 0f 8f 20 02 00 00 85 d2 75 32 83 83 78 03 00 00 01 4b 8b
 44 c5 48 8b 88 60 02 00 00 85 c9 0f 84 b0 00 00 00 8b 40 58 89 c2 41
 89
 [ 308.298487] RIP [a07a9fd2] vb2_perform_fileio+0x372/0x610
 [videobuf2_core]
 [ 308.298507] RSP 88014dc03df8
 [ 308.298514] CR2: 0260
 [ 308.298526] ---[ end trace e8f01717c96d1e41 ]---
 
 v2: Add bug found by Sylvester Nawrocki
 
 fimc-capture and fimc-lite where calling vb2_fop_release with the lock held.
 Therefore a new __vb2_fop_release function has been created to be used by
 drivers that overload the release function.
 
 Signed-off-by: Ricardo Ribalda ricardo.riba...@gmail.com
 ---
  drivers/media/platform/exynos4-is/fimc-capture.c |  2 +-
  drivers/media/platform/exynos4-is/fimc-lite.c|  2 +-
  drivers/media/usb/em28xx/em28xx-video.c  |  2 +-
  drivers/media/v4l2-core/videobuf2-core.c | 18 +-
  include/media/videobuf2-core.h   |  2 ++
  5 files changed, 22 insertions(+), 4 deletions(-)
 
 diff --git a/drivers/media/platform/exynos4-is/fimc-capture.c 
 b/drivers/media/platform/exynos4-is/fimc-capture.c
 index fb27ff7..c38d247c 100644
 --- a/drivers/media/platform/exynos4-is/fimc-capture.c
 +++ b/drivers/media/platform/exynos4-is/fimc-capture.c
 @@ -549,7 +549,7 @@ static int fimc_capture_release(struct file *file)
   vc-streaming = false;
   }
  
 - ret = vb2_fop_release(file);
 + ret = __vb2_fop_release(file, true);
  
   if (close) {
   clear_bit(ST_CAPT_BUSY, fimc-state);
 diff --git a/drivers/media/platform/exynos4-is/fimc-lite.c 
 b/drivers/media/platform/exynos4-is/fimc-lite.c
 index e5798f7..021d804 100644
 --- a/drivers/media/platform/exynos4-is/fimc-lite.c
 +++ b/drivers/media/platform/exynos4-is/fimc-lite.c
 @@ -546,7 +546,7 @@ static int fimc_lite_release(struct file *file)
   mutex_unlock(entity-parent-graph_mutex);
   }
  
 - vb2_fop_release(file);
 + __vb2_fop_release(file, true);
   pm_runtime_put(fimc-pdev-dev);
   clear_bit(ST_FLITE_SUSPENDED, fimc-state);
  
 diff --git a/drivers/media/usb/em28xx/em28xx-video.c 
 b/drivers/media/usb/em28xx/em28xx-video.c
 index 9d10334..6a5c147 100644
 --- a/drivers/media/usb/em28xx/em28xx-video.c
 +++ b/drivers/media/usb/em28xx/em28xx-video.c
 @@ -1664,7 +1664,7 @@ static int 

Re: [PATCH v2 2/2] ARM: dts: Update Samsung sysreg binding document

[Tomasz Figa]

Hi Sachin,

On Thursday 31 of October 2013 10:16:54 Sachin Kamat wrote:
 Added a binding example for reference and updated the
 node name.
 
 Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
 ---
  .../devicetree/bindings/arm/samsung/sysreg.txt |8 +++-
  1 file changed, 7 insertions(+), 1 deletion(-)
 
 diff --git a/Documentation/devicetree/bindings/arm/samsung/sysreg.txt 
 b/Documentation/devicetree/bindings/arm/samsung/sysreg.txt
 index 5039c0a12f55..f165567a9df0 100644
 --- a/Documentation/devicetree/bindings/arm/samsung/sysreg.txt
 +++ b/Documentation/devicetree/bindings/arm/samsung/sysreg.txt
 @@ -1,7 +1,13 @@
  SAMSUNG S5P/Exynos SoC series System Registers (SYSREG)
  
  Properties:
 - - name : should be 'sysreg';
 + - name : should be 'syscon';

I didn't notice this before, but a device binding should not rather
require any specific name of its top level node, so I'd simply remove this
line.

Otherwise the patch looks fine.

Best regards,
Tomasz

--
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] videobuf2: Add missing lock held on vb2_fop_relase

[Sylwester Nawrocki]

On 31/10/13 14:42, Mauro Carvalho Chehab wrote:
 Em Sat, 19 Oct 2013 18:07:57 +0200
 Ricardo Ribalda ricardo.riba...@gmail.com escreveu:
 
 vb2_fop_relase does not held the lock although it is modifying the
 queue-owner field.

 This could lead to race conditions on the vb2_perform_io function
 when multiple applications are accessing the video device via
 read/write API:
[...]
 Signed-off-by: Ricardo Ribalda ricardo.riba...@gmail.com
 ---
  drivers/media/platform/exynos4-is/fimc-capture.c |  2 +-
  drivers/media/platform/exynos4-is/fimc-lite.c|  2 +-
  drivers/media/usb/em28xx/em28xx-video.c  |  2 +-
  drivers/media/v4l2-core/videobuf2-core.c | 18 +-
  include/media/videobuf2-core.h   |  2 ++
  5 files changed, 22 insertions(+), 4 deletions(-)

 diff --git a/drivers/media/platform/exynos4-is/fimc-capture.c 
 b/drivers/media/platform/exynos4-is/fimc-capture.c
 index fb27ff7..c38d247c 100644
 --- a/drivers/media/platform/exynos4-is/fimc-capture.c
 +++ b/drivers/media/platform/exynos4-is/fimc-capture.c
 @@ -549,7 +549,7 @@ static int fimc_capture_release(struct file *file)
  vc-streaming = false;
  }
  
 -ret = vb2_fop_release(file);
 +ret = __vb2_fop_release(file, true);
  
  if (close) {
  clear_bit(ST_CAPT_BUSY, fimc-state);
 diff --git a/drivers/media/platform/exynos4-is/fimc-lite.c 
 b/drivers/media/platform/exynos4-is/fimc-lite.c
 index e5798f7..021d804 100644
 --- a/drivers/media/platform/exynos4-is/fimc-lite.c
 +++ b/drivers/media/platform/exynos4-is/fimc-lite.c
 @@ -546,7 +546,7 @@ static int fimc_lite_release(struct file *file)
  mutex_unlock(entity-parent-graph_mutex);
  }
  
 -vb2_fop_release(file);
 +__vb2_fop_release(file, true);
  pm_runtime_put(fimc-pdev-dev);
  clear_bit(ST_FLITE_SUSPENDED, fimc-state);
  
 diff --git a/drivers/media/usb/em28xx/em28xx-video.c 
 b/drivers/media/usb/em28xx/em28xx-video.c
 index 9d10334..6a5c147 100644
 --- a/drivers/media/usb/em28xx/em28xx-video.c
 +++ b/drivers/media/usb/em28xx/em28xx-video.c
 @@ -1664,7 +1664,7 @@ static int em28xx_v4l2_close(struct file *filp)
  em28xx_videodbg(users=%d\n, dev-users);
  
  mutex_lock(dev-lock);
 -vb2_fop_release(filp);
 +__vb2_fop_release(filp, false);
  
  if (dev-users == 1) {
  /* the device is already disconnect,
 diff --git a/drivers/media/v4l2-core/videobuf2-core.c 
 b/drivers/media/v4l2-core/videobuf2-core.c
 index 594c75e..ce309a8 100644
 --- a/drivers/media/v4l2-core/videobuf2-core.c
 +++ b/drivers/media/v4l2-core/videobuf2-core.c
 @@ -2619,16 +2619,32 @@ int vb2_fop_mmap(struct file *file, struct 
 vm_area_struct *vma)
  }
  EXPORT_SYMBOL_GPL(vb2_fop_mmap);
  
 -int vb2_fop_release(struct file *file)
 +int __vb2_fop_release(struct file *file, bool lock_is_held)
  {
  struct video_device *vdev = video_devdata(file);
 +struct mutex *lock;
  
  if (file-private_data == vdev-queue-owner) {
 +if (lock_is_held)
 +lock = NULL;
 +else
 +lock = vdev-queue-lock ?
 +vdev-queue-lock : vdev-lock;
 +if (lock)
 +mutex_lock(lock);
  vb2_queue_release(vdev-queue);
  vdev-queue-owner = NULL;
 +if (lock)
 +mutex_unlock(lock);
  }
  return v4l2_fh_release(file);
  }
 +EXPORT_SYMBOL_GPL(__vb2_fop_release);
 +
 +int vb2_fop_release(struct file *file)
 +{
 +return __vb2_fop_release(file, false);
 +}
  EXPORT_SYMBOL_GPL(vb2_fop_release);
 
 In general, when a symbol has both locked/unlocked versions, we
 use the __symbol for unlocked versions (as the usage of the __symbol
 requires the caller do do additional protection).
 
 On this patch, (and on  Sylwester's version) you're seeming to be doing 
 just the opposite. That sounds inconsistent with other Kernel symbols.

Actually the version with double underscore prefix in my proposed changes
doesn't take the lock internally (please see below). Hence it follows
the common convention you're ponting out.

 Please either use that version or add a suffix (like _locked / __unlocked)
 to allow a clearer understanding about what's the locked version.
 
 Btw, Does it even make sense to have both options, or wouldn't be better
 to just make sure that all drivers will do the same? My concern here is
 with race conditions that may happen at device removal, if the lock is
 released/retaken inside the routine that unbinds the driver.

Exactly for this reason, i.e. not needing to release and reacquire lock
in driver release() callback I suggested to have the
int __vb2_fop_release(struct file *file); version, for cases when drivers
use their custom handler and call __vb2_fop_release() from within it with
the lock already held.

static int _vb2_fop_release(struct file *file, bool locked)
{
struct video_device *vdev = video_devdata(file);
  

Re: [PATCH 1/1] dmaengine: s3c24xx-dma: use DMA_COMPLETE for dma completion status

[Vinod Koul]

On Thu, Oct 31, 2013 at 10:48:09AM +0530, Sachin Kamat wrote:
 Use the recently introduced DMA_COMPLETE instead of DMA_SUCCESS.
 Without this patch we get the following build error:
 drivers/dma/s3c24xx-dma.c: In function ‘s3c24xx_dma_tx_status’:
 drivers/dma/s3c24xx-dma.c:798:13: error: ‘DMA_SUCCESS’ undeclared
 (first use in this function)
I missed it because this is not in my tree! This needs to go thru kgene's tree
and for that you can merge dma_complete branch from my tree. I will not rebase
that

Acked-by: Vinod Koul vinod.k...@intel.com

--
~Vinod
 
 Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
 Cc: Heiko Stuebner he...@sntech.de
 Cc: Vinod Koul vinod.k...@intel.com
 ---
  drivers/dma/s3c24xx-dma.c |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/drivers/dma/s3c24xx-dma.c b/drivers/dma/s3c24xx-dma.c
 index 4cb127978636..085da4fe6613 100644
 --- a/drivers/dma/s3c24xx-dma.c
 +++ b/drivers/dma/s3c24xx-dma.c
 @@ -795,7 +795,7 @@ static enum dma_status s3c24xx_dma_tx_status(struct 
 dma_chan *chan,
  
   spin_lock_irqsave(s3cchan-vc.lock, flags);
   ret = dma_cookie_status(chan, cookie, txstate);
 - if (ret == DMA_SUCCESS) {
 + if (ret == DMA_COMPLETE) {
   spin_unlock_irqrestore(s3cchan-vc.lock, flags);
   return ret;
   }
 -- 
 1.7.9.5
 

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

Re: [PATCH 19/51] DMA-API: media: dt3155v4l: replace dma_set_mask()+dma_set_coherent_mask() with new helper

[Russell King - ARM Linux]

On Thu, Oct 31, 2013 at 09:46:40AM -0200, Mauro Carvalho Chehab wrote:
 Hi Russell,
 
 Em Mon, 30 Sep 2013 13:57:47 +0200
 Hans Verkuil hverk...@xs4all.nl escreveu:
 
  On 09/19/2013 11:44 PM, Russell King wrote:
   Replace the following sequence:
   
 dma_set_mask(dev, mask);
 dma_set_coherent_mask(dev, mask);
   
   with a call to the new helper dma_set_mask_and_coherent().
   
   Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
  
  Acked-by: Hans Verkuil hans.verk...@cisco.com
 
 Somehow, I lost your original post (I got unsubscribed on a few days 
 from all vger mailing lists at the end of september).
 
 I suspect that you want to sent this via your tree, right?

Yes please.

 If so:
 
 Acked-by: Mauro Carvalho Chehab m.che...@samsung.com

Added, thanks.

   - err = dma_set_mask(pdev-dev, DMA_BIT_MASK(32));
   - if (err)
   - return -ENODEV;
   - err = dma_set_coherent_mask(pdev-dev, DMA_BIT_MASK(32));
   + err = dma_set_mask_and_coherent(pdev-dev, DMA_BIT_MASK(32));
 if (err)
 return -ENODEV;

One thing I've just noticed is that return should be return err not
return -ENODEV - are you okay for me to change that in this patch?

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

Re: [PATCH 1/1] dmaengine: s3c24xx-dma: use DMA_COMPLETE for dma completion status

[Heiko Stübner]

Am Donnerstag, 31. Oktober 2013, 06:18:09 schrieb Sachin Kamat:
 Use the recently introduced DMA_COMPLETE instead of DMA_SUCCESS.
 Without this patch we get the following build error:
 drivers/dma/s3c24xx-dma.c: In function ‘s3c24xx_dma_tx_status’:
 drivers/dma/s3c24xx-dma.c:798:13: error: ‘DMA_SUCCESS’ undeclared
 (first use in this function)
 
 Signed-off-by: Sachin Kamat sachin.ka...@linaro.org

thanks for the catch!

Acked-by: Heiko Stuebner he...@sntech.de


 Cc: Heiko Stuebner he...@sntech.de
 Cc: Vinod Koul vinod.k...@intel.com
 ---
  drivers/dma/s3c24xx-dma.c |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/drivers/dma/s3c24xx-dma.c b/drivers/dma/s3c24xx-dma.c
 index 4cb127978636..085da4fe6613 100644
 --- a/drivers/dma/s3c24xx-dma.c
 +++ b/drivers/dma/s3c24xx-dma.c
 @@ -795,7 +795,7 @@ static enum dma_status s3c24xx_dma_tx_status(struct
 dma_chan *chan,
 
   spin_lock_irqsave(s3cchan-vc.lock, flags);
   ret = dma_cookie_status(chan, cookie, txstate);
 - if (ret == DMA_SUCCESS) {
 + if (ret == DMA_COMPLETE) {
   spin_unlock_irqrestore(s3cchan-vc.lock, flags);
   return ret;
   }

--
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] mfd: sec-core: Add cells for S5M8767-clocks

[Lee Jones]

On Thu, 31 Oct 2013, Tushar Behera wrote:

 S5M8767 chip has 3 crystal oscillators running at 32KHz. These are
 supported by s2mps11-clk driver.
 
 Signed-off-by: Tushar Behera tushar.beh...@linaro.org
 CC: Lee Jones lee.jo...@linaro.org
 ---
  drivers/mfd/sec-core.c |4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)
 
 diff --git a/drivers/mfd/sec-core.c b/drivers/mfd/sec-core.c
 index 34c18fb..020b86b 100644
 --- a/drivers/mfd/sec-core.c
 +++ b/drivers/mfd/sec-core.c
 @@ -56,7 +56,9 @@ static struct mfd_cell s5m8767_devs[] = {
   .name = s5m8767-pmic,
   }, {
   .name = s5m-rtc,
 - },
 + }, {
 + .name = s5m8767-clk,
 + }
  };
  
  static struct mfd_cell s2mps11_devs[] = {

Acked-by: Lee Jones lee.jo...@linaro.org

I'd prefer to take this patch in via the MFD tree once you have
support from the other maintainers for the set.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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]] videobuf2: Add missing lock held on vb2_fop_relase

[Ricardo Ribalda Delgado]

From: Ricardo Ribalda ricardo.riba...@gmail.com

vb2_fop_relase does not held the lock although it is modifying the
queue-owner field.

This could lead to race conditions on the vb2_perform_io function
when multiple applications are accessing the video device via
read/write API:

[ 308.297741] BUG: unable to handle kernel NULL pointer dereference at
0260
[ 308.297759] IP: [a07a9fd2] vb2_perform_fileio+0x372/0x610
[videobuf2_core]
[ 308.297794] PGD 159719067 PUD 158119067 PMD 0
[ 308.297812] Oops:  #1 SMP
[ 308.297826] Modules linked in: qt5023_video videobuf2_dma_sg
qtec_xform videobuf2_vmalloc videobuf2_memops videobuf2_core
qtec_white qtec_mem gpio_xilinx qtec_cmosis qtec_pcie fglrx(PO)
spi_xilinx spi_bitbang qt5023
[ 308.297888] CPU: 1 PID: 2189 Comm: java Tainted: P O 3.11.0-qtec-standard #1
[ 308.297919] Hardware name: QTechnology QT5022/QT5022, BIOS
PM_2.1.0.309 X64 05/23/2013
[ 308.297952] task: 8801564e1690 ti: 88014dc02000 task.ti:
88014dc02000
[ 308.297962] RIP: 0010:[a07a9fd2] [a07a9fd2]
vb2_perform_fileio+0x372/0x610 [videobuf2_core]
[ 308.297985] RSP: 0018:88014dc03df8 EFLAGS: 00010202
[ 308.297995] RAX:  RBX: 880158a23000 RCX: dead00100100
[ 308.298003] RDX:  RSI: dead00200200 RDI: 
[ 308.298012] RBP: 88014dc03e58 R08:  R09: 0001
[ 308.298020] R10: ea00051e8380 R11: 88014dc03fd8 R12: 880158a23070
[ 308.298029] R13: 8801549040b8 R14: 00198000 R15: 01887e60
[ 308.298040] FS: 7f65130d5700() GS:88015ed0()
knlGS:
[ 308.298049] CS: 0010 DS:  ES:  CR0: 80050033
[ 308.298057] CR2: 0260 CR3: 00015963 CR4: 07e0
[ 308.298064] Stack:
[ 308.298071] 880156416c00 00198000 
88010001
[ 308.298087] 88014dc03f50 810a79ca 00020001
880154904718
[ 308.298101] 880156416c00 00198000 880154904338
88014dc03f50
[ 308.298116] Call Trace:
[ 308.298143] [a07aa3c4] vb2_read+0x14/0x20 [videobuf2_core]
[ 308.298198] [a07aa494] vb2_fop_read+0xc4/0x120 [videobuf2_core]
[ 308.298252] [8154ee9e] v4l2_read+0x7e/0xc0
[ 308.298296] [8116e639] vfs_read+0xa9/0x160
[ 308.298312] [8116e882] SyS_read+0x52/0xb0
[ 308.298328] [81784179] tracesys+0xd0/0xd5
[ 308.298335] Code: e5 d6 ff ff 83 3d be 24 00 00 04 89 c2 4c 8b 45 b0
44 8b 4d b8 0f 8f 20 02 00 00 85 d2 75 32 83 83 78 03 00 00 01 4b 8b
44 c5 48 8b 88 60 02 00 00 85 c9 0f 84 b0 00 00 00 8b 40 58 89 c2 41
89
[ 308.298487] RIP [a07a9fd2] vb2_perform_fileio+0x372/0x610
[videobuf2_core]
[ 308.298507] RSP 88014dc03df8
[ 308.298514] CR2: 0260
[ 308.298526] ---[ end trace e8f01717c96d1e41 ]---

v2: Add bug found by Sylvester Nawrocki

fimc-capture and fimc-lite where calling vb2_fop_release with the lock held.
Therefore a new __vb2_fop_release function has been created to be used by
drivers that overload the release function.

v3: Comments by Sylvester Nawrocki and Mauro Carvalho Chehab

Use vb2_fop_release_locked instead of __vb2_fop_release

Signed-off-by: Ricardo Ribalda ricardo.riba...@gmail.com
Signed-off-by: Ricardo Ribalda Delgado ricardo.riba...@gmail.com
---
 drivers/media/platform/exynos4-is/fimc-capture.c |  2 +-
 drivers/media/platform/exynos4-is/fimc-lite.c|  2 +-
 drivers/media/v4l2-core/videobuf2-core.c | 24 +++-
 include/media/videobuf2-core.h   |  1 +
 4 files changed, 26 insertions(+), 3 deletions(-)

diff --git a/drivers/media/platform/exynos4-is/fimc-capture.c 
b/drivers/media/platform/exynos4-is/fimc-capture.c
index fb27ff7..c3c3b3b 100644
--- a/drivers/media/platform/exynos4-is/fimc-capture.c
+++ b/drivers/media/platform/exynos4-is/fimc-capture.c
@@ -549,7 +549,7 @@ static int fimc_capture_release(struct file *file)
vc-streaming = false;
}
 
-   ret = vb2_fop_release(file);
+   ret = vb2_fop_release_locked(file);
 
if (close) {
clear_bit(ST_CAPT_BUSY, fimc-state);
diff --git a/drivers/media/platform/exynos4-is/fimc-lite.c 
b/drivers/media/platform/exynos4-is/fimc-lite.c
index e5798f7..b8d417f 100644
--- a/drivers/media/platform/exynos4-is/fimc-lite.c
+++ b/drivers/media/platform/exynos4-is/fimc-lite.c
@@ -546,7 +546,7 @@ static int fimc_lite_release(struct file *file)
mutex_unlock(entity-parent-graph_mutex);
}
 
-   vb2_fop_release(file);
+   vb2_fop_release_locked(file);
pm_runtime_put(fimc-pdev-dev);
clear_bit(ST_FLITE_SUSPENDED, fimc-state);
 
diff --git a/drivers/media/v4l2-core/videobuf2-core.c 
b/drivers/media/v4l2-core/videobuf2-core.c
index 594c75e..06e6dbd 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -2619,18 +2619,40 @@ int 

Re: [PATCH v3 21/32] drm/exynos: Move dp driver from video/ to drm/

[Jingoo Han]

On Thursday, October 31, 2013 7:47 PM, Inki Dae wrote:
 
 CCing Jingoo,
 
 Is that ok to remove eDP driver from video/exynos? Isn't this driver really
 used by Linux framebuffer driver, s3c-fb.c?

+cc Tomi Valkeinen, Jean-Christophe PLAGNIOL-VILLARD,
 linux-fbdev list, linux-samsung-soc list

Yes, it is used by s3c-fb.c.

 
 Of course, now s3c-fb driver is dead code because this driver doesn't
 support device tree yet but we would need more reviews and discussions about
 moving this driver into drm side. Let's watch new rules for device tree
 bindings of DRM world. So I'd not like to merge this driver yet.

's3c-fb' driver is still used for other mass products projects.
Just, device tree support patch is not yet submitted.


Sean Paul,
When moving the driver, notify related Maintainers of that driver.
Please use 'scripts/get_maintainer.pl' next time.

Best regards,
Jingoo Han

--
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 21/32] drm/exynos: Move dp driver from video/ to drm/

[Tomasz Figa]

On Friday 01 of November 2013 08:06:00 Jingoo Han wrote:
 On Thursday, October 31, 2013 7:47 PM, Inki Dae wrote:
  CCing Jingoo,
  
  Is that ok to remove eDP driver from video/exynos? Isn't this driver
  really used by Linux framebuffer driver, s3c-fb.c?
 
 +cc Tomi Valkeinen, Jean-Christophe PLAGNIOL-VILLARD,
  linux-fbdev list, linux-samsung-soc list
 
 Yes, it is used by s3c-fb.c.
 
  Of course, now s3c-fb driver is dead code because this driver doesn't
  support device tree yet but we would need more reviews and discussions
  about moving this driver into drm side. Let's watch new rules for
  device tree bindings of DRM world. So I'd not like to merge this
  driver yet.
 's3c-fb' driver is still used for other mass products projects.
 Just, device tree support patch is not yet submitted.

Current in-tree users of s3c-fb drivers are s3c2443, non-DT s3c64xx and 
all s5p* SoCs. It is not used on Exynos SoCs anymore.

As for Exynos DP driver, what SoCs does it support? If only Exynos (as the 
name suggests) then there is no point in keeping it at video/exynos and 
making it a part of Exynos DRM driver seems reasonable to me.

Best regards,
Tomasz

--
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 21/32] drm/exynos: Move dp driver from video/ to drm/

[Jingoo Han]

On Friday, November 01, 2013 8:12 AM, Tomasz Figa wrote:
 On Friday 01 of November 2013 08:06:00 Jingoo Han wrote:
  On Thursday, October 31, 2013 7:47 PM, Inki Dae wrote:
   CCing Jingoo,
  
   Is that ok to remove eDP driver from video/exynos? Isn't this driver
   really used by Linux framebuffer driver, s3c-fb.c?
 
  +cc Tomi Valkeinen, Jean-Christophe PLAGNIOL-VILLARD,
   linux-fbdev list, linux-samsung-soc list
 
  Yes, it is used by s3c-fb.c.
 
   Of course, now s3c-fb driver is dead code because this driver doesn't
   support device tree yet but we would need more reviews and discussions
   about moving this driver into drm side. Let's watch new rules for
   device tree bindings of DRM world. So I'd not like to merge this
   driver yet.
  's3c-fb' driver is still used for other mass products projects.
  Just, device tree support patch is not yet submitted.
 
 Current in-tree users of s3c-fb drivers are s3c2443, non-DT s3c64xx and
 all s5p* SoCs. It is not used on Exynos SoCs anymore.

Hi Tomasz Figa,

Some mass product projects using Exynos5250 and etc, use s3c-fb driver
and dp driver. Also, these projects are still using Framebuffer, not DRM.

 
 As for Exynos DP driver, what SoCs does it support? If only Exynos (as the
 name suggests) then there is no point in keeping it at video/exynos and
 making it a part of Exynos DRM driver seems reasonable to me.

However, when considering only mainline kernel, I have no strong objection.
As you know, many Linux kernel based OS projects using Exynos, are using
DRM, not Framebuffer.

Also, if moving DP driver to DRM, MAINTAINERS entry for Exynos DP driver
should be updated, too.

Best regards,
Jingoo Han

--
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 21/32] drm/exynos: Move dp driver from video/ to drm/

[Tomasz Figa]

On Friday 01 of November 2013 08:23:59 Jingoo Han wrote:
 On Friday, November 01, 2013 8:12 AM, Tomasz Figa wrote:
  On Friday 01 of November 2013 08:06:00 Jingoo Han wrote:
   On Thursday, October 31, 2013 7:47 PM, Inki Dae wrote:
CCing Jingoo,

Is that ok to remove eDP driver from video/exynos? Isn't this
driver
really used by Linux framebuffer driver, s3c-fb.c?
   
   +cc Tomi Valkeinen, Jean-Christophe PLAGNIOL-VILLARD,
   
linux-fbdev list, linux-samsung-soc list
   
   Yes, it is used by s3c-fb.c.
   
Of course, now s3c-fb driver is dead code because this driver
doesn't
support device tree yet but we would need more reviews and
discussions
about moving this driver into drm side. Let's watch new rules for
device tree bindings of DRM world. So I'd not like to merge this
driver yet.
   
   's3c-fb' driver is still used for other mass products projects.
   Just, device tree support patch is not yet submitted.
  
  Current in-tree users of s3c-fb drivers are s3c2443, non-DT s3c64xx
  and
  all s5p* SoCs. It is not used on Exynos SoCs anymore.
 
 Hi Tomasz Figa,

Just Tomasz. ;)

 Some mass product projects using Exynos5250 and etc, use s3c-fb driver
 and dp driver. Also, these projects are still using Framebuffer, not
 DRM.

Well, those are based on vendor trees anyway, so do not really affect 
mainline kernel.

  As for Exynos DP driver, what SoCs does it support? If only Exynos (as
  the name suggests) then there is no point in keeping it at
  video/exynos and making it a part of Exynos DRM driver seems
  reasonable to me.
 
 However, when considering only mainline kernel, I have no strong
 objection. As you know, many Linux kernel based OS projects using
 Exynos, are using DRM, not Framebuffer.

Generally, fbdev is strongly discouraged in any new systems and DRM is the 
way to go, so I don't think we should ever want to bring s3c-fb support 
back to Exynos platforms.

 
 Also, if moving DP driver to DRM, MAINTAINERS entry for Exynos DP driver
 should be updated, too.

That's correct.

Best regards,
Tomasz

--
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 21/32] drm/exynos: Move dp driver from video/ to drm/

[Jingoo Han]

On Friday, November 01, 2013 8:27 AM, Tomasz Figa wrote:
 On Friday 01 of November 2013 08:23:59 Jingoo Han wrote:
  On Friday, November 01, 2013 8:12 AM, Tomasz Figa wrote:
   On Friday 01 of November 2013 08:06:00 Jingoo Han wrote:
On Thursday, October 31, 2013 7:47 PM, Inki Dae wrote:
 CCing Jingoo,

 Is that ok to remove eDP driver from video/exynos? Isn't this
 driver
 really used by Linux framebuffer driver, s3c-fb.c?
   
+cc Tomi Valkeinen, Jean-Christophe PLAGNIOL-VILLARD,
   
 linux-fbdev list, linux-samsung-soc list
   
Yes, it is used by s3c-fb.c.
   
 Of course, now s3c-fb driver is dead code because this driver
 doesn't
 support device tree yet but we would need more reviews and
 discussions
 about moving this driver into drm side. Let's watch new rules for
 device tree bindings of DRM world. So I'd not like to merge this
 driver yet.
   
's3c-fb' driver is still used for other mass products projects.
Just, device tree support patch is not yet submitted.
  
   Current in-tree users of s3c-fb drivers are s3c2443, non-DT s3c64xx
   and
   all s5p* SoCs. It is not used on Exynos SoCs anymore.
 
  Hi Tomasz Figa,
 
 Just Tomasz. ;)

Hi Tomasz, :-)

 
  Some mass product projects using Exynos5250 and etc, use s3c-fb driver
  and dp driver. Also, these projects are still using Framebuffer, not
  DRM.
 
 Well, those are based on vendor trees anyway, so do not really affect
 mainline kernel.

OK, I see.

 
   As for Exynos DP driver, what SoCs does it support? If only Exynos (as
   the name suggests) then there is no point in keeping it at
   video/exynos and making it a part of Exynos DRM driver seems
   reasonable to me.
 
  However, when considering only mainline kernel, I have no strong
  objection. As you know, many Linux kernel based OS projects using
  Exynos, are using DRM, not Framebuffer.
 
 Generally, fbdev is strongly discouraged in any new systems and DRM is the
 way to go, so I don't think we should ever want to bring s3c-fb support
 back to Exynos platforms.

Yes, you're right.
Personally, I think that all Exynos platforms should go into DRM, not FB.

One more thing, then how about moving Exynos MIPI to DRM side?
Is there any plan on Exynos MIPI?

Best regards,
Jingoo Han

 
 
  Also, if moving DP driver to DRM, MAINTAINERS entry for Exynos DP driver
  should be updated, too.
 
 That's correct.

--
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 21/32] drm/exynos: Move dp driver from video/ to drm/

[Tomasz Figa]

On Friday 01 of November 2013 08:55:12 Jingoo Han wrote:
 On Friday, November 01, 2013 8:27 AM, Tomasz Figa wrote:
  On Friday 01 of November 2013 08:23:59 Jingoo Han wrote:
   On Friday, November 01, 2013 8:12 AM, Tomasz Figa wrote:
On Friday 01 of November 2013 08:06:00 Jingoo Han wrote:
 On Thursday, October 31, 2013 7:47 PM, Inki Dae wrote:
  CCing Jingoo,
  
  Is that ok to remove eDP driver from video/exynos? Isn't this
  driver
  really used by Linux framebuffer driver, s3c-fb.c?
 
 +cc Tomi Valkeinen, Jean-Christophe PLAGNIOL-VILLARD,
 
  linux-fbdev list, linux-samsung-soc list
 
 Yes, it is used by s3c-fb.c.
 
  Of course, now s3c-fb driver is dead code because this driver
  doesn't
  support device tree yet but we would need more reviews and
  discussions
  about moving this driver into drm side. Let's watch new rules
  for
  device tree bindings of DRM world. So I'd not like to merge
  this
  driver yet.
 
 's3c-fb' driver is still used for other mass products projects.
 Just, device tree support patch is not yet submitted.

Current in-tree users of s3c-fb drivers are s3c2443, non-DT
s3c64xx
and
all s5p* SoCs. It is not used on Exynos SoCs anymore.
   
   Hi Tomasz Figa,
  
  Just Tomasz. ;)
 
 Hi Tomasz, :-)
 
   Some mass product projects using Exynos5250 and etc, use s3c-fb
   driver
   and dp driver. Also, these projects are still using Framebuffer, not
   DRM.
  
  Well, those are based on vendor trees anyway, so do not really affect
  mainline kernel.
 
 OK, I see.
 
As for Exynos DP driver, what SoCs does it support? If only Exynos
(as
the name suggests) then there is no point in keeping it at
video/exynos and making it a part of Exynos DRM driver seems
reasonable to me.
   
   However, when considering only mainline kernel, I have no strong
   objection. As you know, many Linux kernel based OS projects using
   Exynos, are using DRM, not Framebuffer.
  
  Generally, fbdev is strongly discouraged in any new systems and DRM is
  the way to go, so I don't think we should ever want to bring s3c-fb
  support back to Exynos platforms.
 
 Yes, you're right.
 Personally, I think that all Exynos platforms should go into DRM, not
 FB.
 
 One more thing, then how about moving Exynos MIPI to DRM side?
 Is there any plan on Exynos MIPI?

Well, it will eventually have to be moved somewhere else than it is, but I 
believe this will have to wait for Common Display Framework.

This is because the case of MIPI DSI is slightly different from 
DisplayPort, since it is not an enumerable/auto-configurable interface and 
requires dedicated panel drivers and static data provided by board 
designers (in DT for example). Handling of such things in a generic way 
will be done by CDF.

Best regards,
Tomasz

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