[PATCH v5 1/4] Documentation: dt-bindings: Describe SROMc configuration

2015-11-03 Thread Pavel Fedin 
Add documentation for new subnode properties, allowing bank configuration.
Based on u-boot implementation, but heavily reworked.

Signed-off-by: Pavel Fedin 
---
 .../bindings/arm/samsung/exynos-srom.txt   | 68 +-
 1 file changed, 66 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt 
b/Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt
index 33886d5..ee378ca 100644
--- a/Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt
+++ b/Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt
@@ -5,8 +5,72 @@ Required properties:
 
 - reg: offset and length of the register set
 
-Example:
+- #address-cells: Must be set to 2 to allow memory address translation
+
+- #size-cells: Must be set to 1 to allow CS address passing
+
+- ranges: Must be set up to reflect the memory layout with four integer values
+ per bank:
+0  
+
+Sub-nodes:
+The SROM controller can be used to attach external peripherials. In this case
+device nodes should be added as subnodes to the SROMc node. These subnodes,
+except regular device specification, should contain the following properties,
+describing configuration of the relevant SROM bank:
+
+Required properties:
+- reg: bank number, base address (relative to start of the bank) and size of
+   the memory mapped for the device. Note that base address will be
+   typically 0 as this is the start of the bank.
+
+- samsung,srom-timing : array of 6 integers, specifying bank timings in the
+following order: Tacp, Tcah, Tcoh, Tacc, Tcos, Tacs.
+Each value is specified in cycles (0 - 15) and has the
+following meaning:
+Tacp : Page mode access cycle at Page mode
+Tcah : Address holding time after CSn
+Tcoh : Chip selection hold on OEn
+Tacc : Access cycle
+Tcos : Chip selection set-up before OEn
+Tacs : Address set-up before CSn
+
+Optional properties:
+- reg-io-width : data width in bytes (1 or 2). If omitted, default of 1 is 
used.
+
+- samsung,srom-page-mode : page mode configuration for the bank:
+  0 - normal (one data)
+  1 - four data
+  If omitted, default of 0 is used.
+
+Example: basic definition, no banks are configured
+   sromc@1257 {
+   compatible = "samsung,exynos-srom";
+   reg = <0x1257 0x14>;
+   };
+
+Example: SROMc with smsc 911x ethernet chip on bank 3
sromc@1257 {
+   #address-cells = <2>;
+   #size-cells = <1>;
+   ranges = <0 0 0x0400 0x2   // Bank0
+ 1 0 0x0500 0x2   // Bank1
+ 2 0 0x0600 0x2   // Bank2
+ 3 0 0x0700 0x2>; // Bank3
+
compatible = "samsung,exynos-srom";
-   reg = <0x1257 0x10>;
+   reg = <0x1257 0x14>;
+
+   ethernet@3 {
+   compatible = "smsc,lan9115";
+   reg = <3 0 0x1>;   // Bank 3, offset = 0
+   phy-mode = "mii";
+   interrupt-parent = <>;
+   interrupts = <5 8>;
+   reg-io-width = <2>;
+   smsc,irq-push-pull;
+   smsc,force-internal-phy;
+
+   samsung,srom-config = <1 9 12 1 9 1 1>;
+   };
};
-- 
2.4.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

[PATCH v5 0/4] Exynos SROMc configuration and Ethernet support for SMDK5410

2015-11-03 Thread Pavel Fedin 
This patch extends Exynos SROM controller driver with ability to configure
controller outputs and enables SMSC9115 Ethernet chip on SMDK5410 board,
which is connected via SROMc bank #3.

With this patchset, support for the whole existing SMDK range can be added.
Actually, only bank number is different.

This patchset also depends on Exynos 5410 pinctrl support, introduced by
patches 0003 and 0004 from this set:
[PATCH v4 0/5] ARM: EXYNOS: ODROID-XU DT and LEDs
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/330862.html

Pinctrl support is necessary in order to correctly configure
multifunctional pins of the Exynos chip.

v4 => v5:
- Some cosmetic changes in the dtsi ("compatible" goes first)
- Use correctly specified ranges for the SROMc node
- Reuse existing properties where possible ("reg" for bank# and
  "reg-io-width" for data width)
- Separated page-mode property from timings array
- More improvements to the documentation

v3 => v4:
- Devices are now added as subnodes, with additional properties. This allows
  to cleary specify dependency. If configuration fails, error will be reported
  and child devices will not be probed.
- These additional properties now have "samsung,srom-XXX" format
- Fixed code style, now better understood.

v2 => v3:
- Fixed up SROMc region size in the device tree
- Reordered patches, documentation goes first now

v1 => v2:
- Fixed some typos and bad labels in device tree
- Improved documentation

Pavel Fedin (4):
  Documentation: dt-bindings: Describe SROMc configuration
  ARM: dts: Add SROMc to Exynos 5410
  drivers: exynos-srom: Add support for bank configuration
  ARM: dts: Add Ethernet chip to SMDK5410

 .../bindings/arm/samsung/exynos-srom.txt   | 68 +-
 arch/arm/boot/dts/exynos5410-smdk5410.dts  | 40 +
 arch/arm/boot/dts/exynos5410.dtsi  | 11 
 arch/arm/mach-exynos/Kconfig   |  2 +-
 drivers/soc/samsung/Kconfig|  2 +-
 drivers/soc/samsung/exynos-srom.c  | 60 ++-
 6 files changed, 177 insertions(+), 6 deletions(-)

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

[PATCH v5 3/4] drivers: exynos-srom: Add support for bank configuration

2015-11-03 Thread Pavel Fedin 
Implement handling properties in subnodes and adding child devices to the
system. Child devices will not be added if configuration fails.

Since the driver now does more than suspend-resume support, dependency on
CONFIG_PM is removed.

Signed-off-by: Pavel Fedin 
---
 arch/arm/mach-exynos/Kconfig  |  2 +-
 drivers/soc/samsung/Kconfig   |  2 +-
 drivers/soc/samsung/exynos-srom.c | 60 +--
 3 files changed, 60 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index 83c85f5..c22dc42 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -16,7 +16,7 @@ menuconfig ARCH_EXYNOS
select ARM_GIC
select COMMON_CLK_SAMSUNG
select EXYNOS_THERMAL
-   select EXYNOS_SROM if PM
+   select EXYNOS_SROM
select HAVE_ARM_SCU if SMP
select HAVE_S3C2410_I2C if I2C
select HAVE_S3C2410_WATCHDOG if WATCHDOG
diff --git a/drivers/soc/samsung/Kconfig b/drivers/soc/samsung/Kconfig
index 2833b5b..ea4bc2a 100644
--- a/drivers/soc/samsung/Kconfig
+++ b/drivers/soc/samsung/Kconfig
@@ -8,6 +8,6 @@ config SOC_SAMSUNG
 
 config EXYNOS_SROM
bool
-   depends on ARM && ARCH_EXYNOS && PM
+   depends on ARM && ARCH_EXYNOS
 
 endmenu
diff --git a/drivers/soc/samsung/exynos-srom.c 
b/drivers/soc/samsung/exynos-srom.c
index 57a232d..49b5c9e 100644
--- a/drivers/soc/samsung/exynos-srom.c
+++ b/drivers/soc/samsung/exynos-srom.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -67,11 +68,50 @@ static struct exynos_srom_reg_dump 
*exynos_srom_alloc_reg_dump(
return rd;
 }
 
+static int decode_sromc(struct exynos_srom *srom, struct device_node *np)
+{
+   u32 bank, width, pmc;
+   u32 timing[6];
+   u32 cs, bw;
+
+   if (of_property_read_u32(np, "reg", ))
+   return -EINVAL;
+   if (of_property_read_u32(np, "reg-io-width", ))
+   width = 1;
+   if (of_property_read_u32(np, "samsung,srom-page-mode", ))
+   pmc = 0;
+   if (of_property_read_u32_array(np, "samsung,srom-timing", timing,
+  ARRAY_SIZE(timing)))
+   return -EINVAL;
+
+   bank *= 4; /* Convert bank into shift/offset */
+
+   cs = 1 << EXYNOS_SROM_BW__BYTEENABLE__SHIFT;
+   if (width == 2)
+   cs |= 1 << EXYNOS_SROM_BW__DATAWIDTH__SHIFT;
+
+   bw = __raw_readl(srom->reg_base + EXYNOS_SROM_BW);
+   bw = (bw & ~(EXYNOS_SROM_BW__CS_MASK << bank)) | (cs << bank);
+   __raw_writel(bw, srom->reg_base + EXYNOS_SROM_BW);
+
+   __raw_writel((pmc << EXYNOS_SROM_BCX__PMC__SHIFT) |
+   (timing[0] << EXYNOS_SROM_BCX__TACP__SHIFT) |
+   (timing[1] << EXYNOS_SROM_BCX__TCAH__SHIFT) |
+   (timing[2] << EXYNOS_SROM_BCX__TCOH__SHIFT) |
+   (timing[3] << EXYNOS_SROM_BCX__TACC__SHIFT) |
+   (timing[4] << EXYNOS_SROM_BCX__TCOS__SHIFT) |
+   (timing[5] << EXYNOS_SROM_BCX__TACS__SHIFT),
+   srom->reg_base + EXYNOS_SROM_BC0 + bank);
+
+   return 0;
+}
+
 static int exynos_srom_probe(struct platform_device *pdev)
 {
-   struct device_node *np;
+   struct device_node *np, *child;
struct exynos_srom *srom;
struct device *dev = >dev;
+   bool error = false;
 
np = dev->of_node;
if (!np) {
@@ -100,7 +140,23 @@ static int exynos_srom_probe(struct platform_device *pdev)
return -ENOMEM;
}
 
-   return 0;
+   for_each_child_of_node(np, child) {
+   if (decode_sromc(srom, child)) {
+   dev_err(dev,
+   "Could not decode bank configuration for %s\n",
+   child->name);
+   error = true;
+   }
+   }
+
+   /*
+* If any bank failed to configure, we still provide suspend/resume,
+* but do not probe child devices
+*/
+   if (error)
+   return 0;
+
+   return of_platform_populate(np, NULL, NULL, dev);
 }
 
 static int exynos_srom_remove(struct platform_device *pdev)
-- 
2.4.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

[PATCH v5 2/4] ARM: dts: Add SROMc to Exynos 5410

2015-11-03 Thread Pavel Fedin 
This machine uses own SoC device tree file, add missing part.
We insert the complete description, with ranges, because we are going to
connect devices to it. Values in ranges are SoC-specific, so they go here
in order not to duplicate them for every machine.

Signed-off-by: Pavel Fedin 
---
 arch/arm/boot/dts/exynos5410.dtsi | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5410.dtsi 
b/arch/arm/boot/dts/exynos5410.dtsi
index 4603356..9cfb814 100644
--- a/arch/arm/boot/dts/exynos5410.dtsi
+++ b/arch/arm/boot/dts/exynos5410.dtsi
@@ -101,6 +101,17 @@
reg = <0x1000 0x100>;
};
 
+   sromc: sromc@1225 {
+   compatible = "samsung,exynos-srom";
+   reg = <0x1225 0x14>;
+   #address-cells = <2>;
+   #size-cells = <1>;
+   ranges = <0 0 0x0400 0x2
+ 1 0 0x0500 0x2
+ 2 0 0x0600 0x2
+ 3 0 0x0700 0x2>;
+   };
+
pmu_system_controller: system-controller@1004 {
compatible = "samsung,exynos5410-pmu", "syscon";
reg = <0x1004 0x5000>;
-- 
2.4.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

[PATCH v5 4/4] ARM: dts: Add Ethernet chip to SMDK5410

2015-11-03 Thread Pavel Fedin 
The chip is smsc9115, connected via SROMc bank 3. Additionally, some GPIO
initialization is required.

Signed-off-by: Pavel Fedin 
---
 arch/arm/boot/dts/exynos5410-smdk5410.dts | 40 +++
 1 file changed, 40 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5410-smdk5410.dts 
b/arch/arm/boot/dts/exynos5410-smdk5410.dts
index cebeaab..f41952f 100644
--- a/arch/arm/boot/dts/exynos5410-smdk5410.dts
+++ b/arch/arm/boot/dts/exynos5410-smdk5410.dts
@@ -61,6 +61,27 @@
disable-wp;
 };
 
+_0 {
+   srom_ctl: srom-ctl {
+   samsung,pins = "gpy0-3", "gpy0-4", "gpy0-5",
+  "gpy1-0", "gpy1-1", "gpy1-2", "gpy1-3";
+   samsung,pin-function = <2>;
+   samsung,pin-drv = <0>;
+   };
+
+   srom_ebi: srom-ebi {
+   samsung,pins = "gpy3-0", "gpy3-1", "gpy3-2", "gpy3-3",
+  "gpy3-4", "gpy3-5", "gpy3-6", "gpy3-7",
+  "gpy5-0", "gpy5-1", "gpy5-2", "gpy5-3",
+  "gpy5-4", "gpy5-5", "gpy5-6", "gpy5-7",
+  "gpy6-0", "gpy6-1", "gpy6-2", "gpy6-3",
+  "gpy6-4", "gpy6-5", "gpy6-6", "gpy6-7";
+   samsung,pin-function = <2>;
+   samsung,pin-pud = <3>;
+   samsung,pin-drv = <0>;
+   };
+};
+
  {
status = "okay";
 };
@@ -72,3 +93,22 @@
  {
status = "okay";
 };
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_ctl>, <_ebi>;
+
+   ethernet@3 {
+   compatible = "smsc,lan9115";
+   reg = <3 0 0x1>;
+   phy-mode = "mii";
+   interrupt-parent = <>;
+   interrupts = <5 8>;
+   reg-io-width = <2>;
+   smsc,irq-push-pull;
+   smsc,force-internal-phy;
+
+   samsung,srom-page-mode = <1>;
+   samsung,srom-timing = <9 12 1 9 1 1>;
+   };
+};
-- 
2.4.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 20/22] clocksource/drivers/exynos_mct: Fix Kconfig and add COMPILE_TEST option

2015-11-03 Thread Daniel Lezcano 

On 11/03/2015 01:59 AM, Krzysztof Kozlowski wrote:

On 03.11.2015 09:30, Krzysztof Kozlowski wrote:

On 02.11.2015 21:56, Daniel Lezcano wrote:

Let the platform's Kconfig to select the clock instead of having a reverse
dependency from the driver to the platform options.


Selecting user-visible symbols is rather discouraged so why not
something like this:

-   def_bool y if ARCH_EXYNOS
-   depends on !ARM64
+   bool "Exynos multi core timer driver"
+   depends on ARCH_EXYNOS || (COMPILE_TEST && ARM)


Nope, that was wrong as we loose auto-select on Exynos. Instead:
-   def_bool y if ARCH_EXYNOS
-   depends on !ARM64
+   bool "Exynos multi core timer driver" if ARM
+   depends on ARCH_EXYNOS || COMPILE_TEST
+   default y if ARCH_EXYNOS

This way we avoid select (which is a reverse dependency for the driver),
have it auto-selectable and compile tested on arm.


I think you misunderstood the patch I sent.

It does two things:

1. Follow the thumb of rule of the current Kconfig format

   - The timer driver is selected by the platform (exynos in this case)
   - User can't select the driver in the menuconfig
   - There is no dependency on the platform except for compilation test

2. Add the COMPILE_TEST

   - User can select the driver for compilation testing. This is for 
allyesconfig when doing compilation test coverage (exynos timer could be 
compiled on other platform). As the delay code is not portable, we have 
to restrict the compilation on the ARM platform, this is why there is 
the dependency on ARM.


I am currently looking at splitting the delay code in order to prevent 
this restriction on this driver and some others drivers.




Add the COMPILE_TEST option for the compilation test coverage. Due to the
non portable 'delay' code, this driver is only compilable on ARM.

Signed-off-by: Daniel Lezcano 
---
  arch/arm/mach-exynos/Kconfig | 1 +
  drivers/clocksource/Kconfig  | 4 ++--
  2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index 3a10f1a..ff10539 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -27,6 +27,7 @@ menuconfig ARCH_EXYNOS
select SRAM
select THERMAL
select MFD_SYSCON
+   select CLKSRC_EXYNOS_MCT
help
  Support for SAMSUNG EXYNOS SoCs (EXYNOS4/5)

diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index 916c36d..d829cbe 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -213,8 +213,8 @@ config CLKSRC_METAG_GENERIC
  This option enables support for the Meta per-thread timers.

  config CLKSRC_EXYNOS_MCT
-   def_bool y if ARCH_EXYNOS
-   depends on !ARM64
+   bool "Exynos multi core timer driver" if COMPILE_TEST
+   depends on ARM
help
  Support for Multi Core Timer controller on Exynos SoCs.










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

Re: [PATCH 20/22] clocksource/drivers/exynos_mct: Fix Kconfig and add COMPILE_TEST option

2015-11-03 Thread Arnd Bergmann 
On Tuesday 03 November 2015 09:40:02 Daniel Lezcano wrote:
> On 11/03/2015 01:59 AM, Krzysztof Kozlowski wrote:
> > On 03.11.2015 09:30, Krzysztof Kozlowski wrote:
> >> On 02.11.2015 21:56, Daniel Lezcano wrote:
> >>> Let the platform's Kconfig to select the clock instead of having a reverse
> >>> dependency from the driver to the platform options.
> >>
> >> Selecting user-visible symbols is rather discouraged so why not
> >> something like this:
> >>
> >> -   def_bool y if ARCH_EXYNOS
> >> -   depends on !ARM64
> >> +   bool "Exynos multi core timer driver"
> >> +   depends on ARCH_EXYNOS || (COMPILE_TEST && ARM)
> >
> > Nope, that was wrong as we loose auto-select on Exynos. Instead:
> > -   def_bool y if ARCH_EXYNOS
> > -   depends on !ARM64
> > +   bool "Exynos multi core timer driver" if ARM
> > +   depends on ARCH_EXYNOS || COMPILE_TEST
> > +   default y if ARCH_EXYNOS
> >
> > This way we avoid select (which is a reverse dependency for the driver),
> > have it auto-selectable and compile tested on arm.
> 
> I think you misunderstood the patch I sent.
> 
> It does two things:
> 
> 1. Follow the thumb of rule of the current Kconfig format
> 
> - The timer driver is selected by the platform (exynos in this case)
> - User can't select the driver in the menuconfig
> - There is no dependency on the platform except for compilation test
> 
> 2. Add the COMPILE_TEST
> 
> - User can select the driver for compilation testing. This is for 
> allyesconfig when doing compilation test coverage (exynos timer could be 
> compiled on other platform). As the delay code is not portable, we have 
> to restrict the compilation on the ARM platform, this is why there is 
> the dependency on ARM.
> 
> I am currently looking at splitting the delay code in order to prevent 
> this restriction on this driver and some others drivers.

I suspect this will come up again in the future. The problem is
really that drivers/clocksource has different rules from almost
everything else, by requiring the platform to 'select' the driver.

The second version that Krzysztof posted is how we handle this in
other driver subsystems, and I would generally prefer it to do this
consistently for everything, but John Stultz has in the past argued
strongly for using 'select' in all clocksource drivers. The reason
is that for each platform we know in advance which driver we want,
and there is never a need for the user to have to select the right
one.

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

[PATCH v2 6/7] drm/exynos: add pm_runtime to DECON 5433

2015-11-03 Thread Inki Dae 
From: Gustavo Padovan 

Let pm_runtime handle the enabling/disabling of the device with
proper refcnt instead of rely on specific flags to track the enabled
state.

Changelog v2:
- Change CONFIG_PM_SLEEP -> CONFIG_PM

Signed-off-by: Gustavo Padovan 
Signed-off-by: Inki Dae 
---
 drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 54 +++
 1 file changed, 39 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c 
b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
index fbe1b31..edfd6e3 100644
--- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
@@ -385,12 +385,6 @@ static void decon_enable(struct exynos_drm_crtc *crtc)
 
pm_runtime_get_sync(ctx->dev);
 
-   for (i = 0; i < ARRAY_SIZE(decon_clks_name); i++) {
-   ret = clk_prepare_enable(ctx->clks[i]);
-   if (ret < 0)
-   goto err;
-   }
-
set_bit(BIT_CLKS_ENABLED, >flags);
 
/* if vblank was enabled status, enable it again. */
@@ -399,11 +393,6 @@ static void decon_enable(struct exynos_drm_crtc *crtc)
 
decon_commit(ctx->crtc);
 
-   return;
-err:
-   while (--i >= 0)
-   clk_disable_unprepare(ctx->clks[i]);
-
set_bit(BIT_SUSPENDED, >flags);
 }
 
@@ -425,9 +414,6 @@ static void decon_disable(struct exynos_drm_crtc *crtc)
 
decon_swreset(ctx);
 
-   for (i = 0; i < ARRAY_SIZE(decon_clks_name); i++)
-   clk_disable_unprepare(ctx->clks[i]);
-
clear_bit(BIT_CLKS_ENABLED, >flags);
 
pm_runtime_put_sync(ctx->dev);
@@ -478,7 +464,6 @@ err:
 static struct exynos_drm_crtc_ops decon_crtc_ops = {
.enable = decon_enable,
.disable= decon_disable,
-   .commit = decon_commit,
.enable_vblank  = decon_enable_vblank,
.disable_vblank = decon_disable_vblank,
.atomic_begin   = decon_atomic_begin,
@@ -581,6 +566,44 @@ out:
return IRQ_HANDLED;
 }
 
+#ifdef CONFIG_PM
+static int exynos5433_decon_suspend(struct device *dev)
+{
+   struct decon_context *ctx = dev_get_drvdata(dev);
+   int i;
+
+   for (i = 0; i < ARRAY_SIZE(decon_clks_name); i++)
+   clk_disable_unprepare(ctx->clks[i]);
+
+   return 0;
+}
+
+static int exynos5433_decon_resume(struct device *dev)
+{
+   struct decon_context *ctx = dev_get_drvdata(dev);
+   int i, ret;
+
+   for (i = 0; i < ARRAY_SIZE(decon_clks_name); i++) {
+   ret = clk_prepare_enable(ctx->clks[i]);
+   if (ret < 0)
+   goto err;
+   }
+
+   return 0;
+
+err:
+   while (--i >= 0)
+   clk_disable_unprepare(ctx->clks[i]);
+
+   return ret;
+}
+#endif
+
+static const struct dev_pm_ops exynos5433_decon_pm_ops = {
+   SET_RUNTIME_PM_OPS(exynos5433_decon_suspend, exynos5433_decon_resume,
+  NULL)
+};
+
 static const struct of_device_id exynos5433_decon_driver_dt_match[] = {
{
.compatible = "samsung,exynos5433-decon",
@@ -684,6 +707,7 @@ struct platform_driver exynos5433_decon_driver = {
.remove = exynos5433_decon_remove,
.driver = {
.name   = "exynos5433-decon",
+   .pm = _decon_pm_ops,
.of_match_table = exynos5433_decon_driver_dt_match,
},
 };
-- 
1.9.1

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

[PATCH v2 2/7] drm/exynos: add pm_runtime to DP

2015-11-03 Thread Inki Dae 
From: Gustavo Padovan 

Let pm_runtime handle the enabling/disabling of the device with
proper refcnt instead of rely on specific flags to track the enabled
state.

Changelog v2:
- no change

Signed-off-by: Gustavo Padovan 
Signed-off-by: Inki Dae 
---
 drivers/gpu/drm/exynos/exynos_dp_core.c | 58 ++---
 1 file changed, 46 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
b/drivers/gpu/drm/exynos/exynos_dp_core.c
index e4d32a1..b6e8b89 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -1058,8 +1058,7 @@ static void exynos_dp_bridge_enable(struct drm_bridge 
*bridge)
struct exynos_dp_device *dp = bridge->driver_private;
struct exynos_drm_crtc *crtc = dp_to_crtc(dp);
 
-   if (dp->dpms_mode == DRM_MODE_DPMS_ON)
-   return;
+   pm_runtime_get_sync(dp->dev);
 
if (dp->panel) {
if (drm_panel_prepare(dp->panel)) {
@@ -1071,13 +1070,10 @@ static void exynos_dp_bridge_enable(struct drm_bridge 
*bridge)
if (crtc->ops->clock_enable)
crtc->ops->clock_enable(dp_to_crtc(dp), true);
 
-   clk_prepare_enable(dp->clock);
phy_power_on(dp->phy);
exynos_dp_init_dp(dp);
enable_irq(dp->irq);
exynos_dp_commit(>encoder);
-
-   dp->dpms_mode = DRM_MODE_DPMS_ON;
 }
 
 static void exynos_dp_bridge_disable(struct drm_bridge *bridge)
@@ -1085,9 +1081,6 @@ static void exynos_dp_bridge_disable(struct drm_bridge 
*bridge)
struct exynos_dp_device *dp = bridge->driver_private;
struct exynos_drm_crtc *crtc = dp_to_crtc(dp);
 
-   if (dp->dpms_mode != DRM_MODE_DPMS_ON)
-   return;
-
if (dp->panel) {
if (drm_panel_disable(dp->panel)) {
DRM_ERROR("failed to disable the panel\n");
@@ -1098,7 +1091,6 @@ static void exynos_dp_bridge_disable(struct drm_bridge 
*bridge)
disable_irq(dp->irq);
flush_work(>hotplug_work);
phy_power_off(dp->phy);
-   clk_disable_unprepare(dp->clock);
 
if (crtc->ops->clock_enable)
crtc->ops->clock_enable(dp_to_crtc(dp), false);
@@ -1108,7 +1100,7 @@ static void exynos_dp_bridge_disable(struct drm_bridge 
*bridge)
DRM_ERROR("failed to turnoff the panel\n");
}
 
-   dp->dpms_mode = DRM_MODE_DPMS_OFF;
+   pm_runtime_put_sync(dp->dev);
 }
 
 static void exynos_dp_bridge_nop(struct drm_bridge *bridge)
@@ -1267,7 +1259,6 @@ static int exynos_dp_bind(struct device *dev, struct 
device *master, void *data)
int pipe, ret = 0;
 
dp->dev = >dev;
-   dp->dpms_mode = DRM_MODE_DPMS_OFF;
 
dp->video_info = exynos_dp_dt_parse_pdata(>dev);
if (IS_ERR(dp->video_info))
@@ -1392,6 +1383,7 @@ static int exynos_dp_probe(struct platform_device *pdev)
struct device *dev = >dev;
struct device_node *panel_node, *bridge_node, *endpoint;
struct exynos_dp_device *dp;
+   int ret;
 
dp = devm_kzalloc(>dev, sizeof(struct exynos_dp_device),
GFP_KERNEL);
@@ -1420,16 +1412,57 @@ static int exynos_dp_probe(struct platform_device *pdev)
return -EPROBE_DEFER;
}
 
-   return component_add(>dev, _dp_ops);
+   pm_runtime_enable(dev);
+
+   ret = component_add(>dev, _dp_ops);
+   if (ret)
+   goto err_disable_pm_runtime;
+
+   return ret;
+
+err_disable_pm_runtime:
+   pm_runtime_disable(dev);
+
+   return ret;
 }
 
 static int exynos_dp_remove(struct platform_device *pdev)
 {
+   pm_runtime_disable(>dev);
component_del(>dev, _dp_ops);
 
return 0;
 }
 
+#ifdef CONFIG_PM
+static int exynos_dp_suspend(struct device *dev)
+{
+   struct exynos_dp_device *dp = dev_get_drvdata(dev);
+
+   clk_disable_unprepare(dp->clock);
+
+   return 0;
+}
+
+static int exynos_dp_resume(struct device *dev)
+{
+   struct exynos_dp_device *dp = dev_get_drvdata(dev);
+   int ret;
+
+   ret = clk_prepare_enable(dp->clock);
+   if (ret < 0) {
+   DRM_ERROR("Failed to prepare_enable the clock clk [%d]\n", ret);
+   return ret;
+   }
+
+   return 0;
+}
+#endif
+
+static const struct dev_pm_ops exynos_dp_pm_ops = {
+   SET_RUNTIME_PM_OPS(exynos_dp_suspend, exynos_dp_resume, NULL)
+};
+
 static const struct of_device_id exynos_dp_match[] = {
{ .compatible = "samsung,exynos5-dp" },
{},
@@ -1442,6 +1475,7 @@ struct platform_driver dp_driver = {
.driver = {
.name   = "exynos-dp",
.owner  = THIS_MODULE,
+   .pm = _dp_pm_ops,
.of_match_table = exynos_dp_match,
},
 };
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe

[PATCH v2 7/7] drm/exynos: add pm_runtime to DECON 7

2015-11-03 Thread Inki Dae 
From: Gustavo Padovan 

Let pm_runtime handle the enabling/disabling of the device with
proper refcnt instead of rely on specific flags to track the enabled
state.

Changelog v2:
- Modify CONFIG_PM_SLEEP -> CONFIG_PM

Signed-off-by: Gustavo Padovan 
Signed-off-by: Inki Dae 
---
 drivers/gpu/drm/exynos/exynos7_drm_decon.c | 125 -
 1 file changed, 53 insertions(+), 72 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c 
b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
index ead2b16..3119aba 100644
--- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
@@ -54,7 +54,6 @@ struct decon_context {
void __iomem*regs;
unsigned long   irq_flags;
booli80_if;
-   boolsuspended;
int pipe;
wait_queue_head_t   wait_vsync_queue;
atomic_twait_vsync_event;
@@ -85,9 +84,6 @@ static void decon_wait_for_vblank(struct exynos_drm_crtc 
*crtc)
 {
struct decon_context *ctx = crtc->ctx;
 
-   if (ctx->suspended)
-   return;
-
atomic_set(>wait_vsync_event, 1);
 
/*
@@ -119,13 +115,8 @@ static void decon_clear_channels(struct exynos_drm_crtc 
*crtc)
}
 
/* Wait for vsync, as disable channel takes effect at next vsync */
-   if (ch_enabled) {
-   unsigned int state = ctx->suspended;
-
-   ctx->suspended = 0;
+   if (ch_enabled)
decon_wait_for_vblank(ctx->crtc);
-   ctx->suspended = state;
-   }
 }
 
 static int decon_ctx_initialize(struct decon_context *ctx,
@@ -170,9 +161,6 @@ static void decon_commit(struct exynos_drm_crtc *crtc)
struct drm_display_mode *mode = >base.state->adjusted_mode;
u32 val, clkdiv;
 
-   if (ctx->suspended)
-   return;
-
/* nothing to do if we haven't set the mode yet */
if (mode->htotal == 0 || mode->vtotal == 0)
return;
@@ -234,9 +222,6 @@ static int decon_enable_vblank(struct exynos_drm_crtc *crtc)
struct decon_context *ctx = crtc->ctx;
u32 val;
 
-   if (ctx->suspended)
-   return -EPERM;
-
if (!test_and_set_bit(0, >irq_flags)) {
val = readl(ctx->regs + VIDINTCON0);
 
@@ -259,9 +244,6 @@ static void decon_disable_vblank(struct exynos_drm_crtc 
*crtc)
struct decon_context *ctx = crtc->ctx;
u32 val;
 
-   if (ctx->suspended)
-   return;
-
if (test_and_clear_bit(0, >irq_flags)) {
val = readl(ctx->regs + VIDINTCON0);
 
@@ -389,9 +371,6 @@ static void decon_atomic_begin(struct exynos_drm_crtc *crtc,
 {
struct decon_context *ctx = crtc->ctx;
 
-   if (ctx->suspended)
-   return;
-
decon_shadow_protect_win(ctx, plane->zpos, true);
 }
 
@@ -409,9 +388,6 @@ static void decon_update_plane(struct exynos_drm_crtc *crtc,
unsigned int bpp = state->fb->bits_per_pixel >> 3;
unsigned int pitch = state->fb->pitches[0];
 
-   if (ctx->suspended)
-   return;
-
/*
 * SHADOWCON/PRTCON register is used for enabling timing.
 *
@@ -508,9 +484,6 @@ static void decon_disable_plane(struct exynos_drm_crtc 
*crtc,
unsigned int win = plane->zpos;
u32 val;
 
-   if (ctx->suspended)
-   return;
-
/* protect windows */
decon_shadow_protect_win(ctx, win, true);
 
@@ -529,9 +502,6 @@ static void decon_atomic_flush(struct exynos_drm_crtc *crtc,
 {
struct decon_context *ctx = crtc->ctx;
 
-   if (ctx->suspended)
-   return;
-
decon_shadow_protect_win(ctx, plane->zpos, false);
 }
 
@@ -555,39 +525,9 @@ static void decon_init(struct decon_context *ctx)
 static void decon_enable(struct exynos_drm_crtc *crtc)
 {
struct decon_context *ctx = crtc->ctx;
-   int ret;
-
-   if (!ctx->suspended)
-   return;
-
-   ctx->suspended = false;
 
pm_runtime_get_sync(ctx->dev);
 
-   ret = clk_prepare_enable(ctx->pclk);
-   if (ret < 0) {
-   DRM_ERROR("Failed to prepare_enable the pclk [%d]\n", ret);
-   return;
-   }
-
-   ret = clk_prepare_enable(ctx->aclk);
-   if (ret < 0) {
-   DRM_ERROR("Failed to prepare_enable the aclk [%d]\n", ret);
-   return;
-   }
-
-   ret = clk_prepare_enable(ctx->eclk);
-   if  (ret < 0) {
-   DRM_ERROR("Failed to prepare_enable the eclk [%d]\n", ret);
-   return;
-   }
-
-   ret = clk_prepare_enable(ctx->vclk);
-   if  (ret < 0) {
-   DRM_ERROR("Failed to prepare_enable the vclk [%d]\n", ret);
-   return;
-   }
-

[PATCH v2 3/7] drm/exynos: add pm_runtime to HDMI

2015-11-03 Thread Inki Dae 
From: Gustavo Padovan 

Let pm_runtime handle the enabling/disabling of the device with proper
refcnt instead of rely on specific flags to track the enabled state.

Changelog v2:
- Mofidy CONFIG_PM_SLEEP -> CONFIG_PM

Signed-off-by: Gustavo Padovan 
Signed-off-by: Inki Dae 
---
 drivers/gpu/drm/exynos/exynos_hdmi.c | 56 
 1 file changed, 38 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 57b6755..d0362af 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -102,7 +102,6 @@ struct hdmi_context {
struct device   *dev;
struct drm_device   *drm_dev;
struct drm_connectorconnector;
-   boolpowered;
booldvi_mode;
struct delayed_work hotplug_work;
struct drm_display_mode current_mode;
@@ -113,7 +112,7 @@ struct hdmi_context {
void __iomem*regs_hdmiphy;
struct i2c_client   *hdmiphy_port;
struct i2c_adapter  *ddc_adpt;
-   struct gpio_desc*hpd_gpio;
+   struct gpio_desc*hpd_gpio;
int irq;
struct regmap   *pmureg;
struct clk  *hdmi;
@@ -1585,11 +1584,6 @@ static void hdmi_enable(struct drm_encoder *encoder)
 {
struct hdmi_context *hdata = encoder_to_hdmi(encoder);
 
-   if (hdata->powered)
-   return;
-
-   hdata->powered = true;
-
pm_runtime_get_sync(hdata->dev);
 
if (regulator_bulk_enable(ARRAY_SIZE(supply), hdata->regul_bulk))
@@ -1599,9 +1593,6 @@ static void hdmi_enable(struct drm_encoder *encoder)
regmap_update_bits(hdata->pmureg, PMU_HDMI_PHY_CONTROL,
PMU_HDMI_PHY_ENABLE_BIT, 1);
 
-   clk_prepare_enable(hdata->hdmi);
-   clk_prepare_enable(hdata->sclk_hdmi);
-
hdmi_conf_apply(hdata);
 }
 
@@ -1611,9 +1602,6 @@ static void hdmi_disable(struct drm_encoder *encoder)
struct drm_crtc *crtc = encoder->crtc;
const struct drm_crtc_helper_funcs *funcs = NULL;
 
-   if (!hdata->powered)
-   return;
-
/*
 * The SFRs of VP and Mixer are updated by Vertical Sync of
 * Timing generator which is a part of HDMI so the sequence
@@ -1633,9 +1621,6 @@ static void hdmi_disable(struct drm_encoder *encoder)
 
cancel_delayed_work(>hotplug_work);
 
-   clk_disable_unprepare(hdata->sclk_hdmi);
-   clk_disable_unprepare(hdata->hdmi);
-
/* reset pmu hdmiphy control bit to disable hdmiphy */
regmap_update_bits(hdata->pmureg, PMU_HDMI_PHY_CONTROL,
PMU_HDMI_PHY_ENABLE_BIT, 0);
@@ -1643,8 +1628,6 @@ static void hdmi_disable(struct drm_encoder *encoder)
regulator_bulk_disable(ARRAY_SIZE(supply), hdata->regul_bulk);
 
pm_runtime_put_sync(hdata->dev);
-
-   hdata->powered = false;
 }
 
 static struct drm_encoder_helper_funcs exynos_hdmi_encoder_helper_funcs = {
@@ -1978,12 +1961,49 @@ static int hdmi_remove(struct platform_device *pdev)
return 0;
 }
 
+#ifdef CONFIG_PM
+static int exynos_hdmi_suspend(struct device *dev)
+{
+   struct hdmi_context *hdata = dev_get_drvdata(dev);
+
+   clk_disable_unprepare(hdata->sclk_hdmi);
+   clk_disable_unprepare(hdata->hdmi);
+
+   return 0;
+}
+
+static int exynos_hdmi_resume(struct device *dev)
+{
+   struct hdmi_context *hdata = dev_get_drvdata(dev);
+   int ret;
+
+   ret = clk_prepare_enable(hdata->hdmi);
+   if (ret < 0) {
+   DRM_ERROR("Failed to prepare_enable the hdmi clk [%d]\n", ret);
+   return ret;
+   }
+   ret = clk_prepare_enable(hdata->sclk_hdmi);
+   if (ret < 0) {
+   DRM_ERROR("Failed to prepare_enable the sclk_mixer clk [%d]\n",
+ ret);
+   return ret;
+   }
+
+   return 0;
+}
+#endif
+
+static const struct dev_pm_ops exynos_hdmi_pm_ops = {
+   SET_RUNTIME_PM_OPS(exynos_hdmi_suspend, exynos_hdmi_resume, NULL)
+};
+
 struct platform_driver hdmi_driver = {
.probe  = hdmi_probe,
.remove = hdmi_remove,
.driver = {
.name   = "exynos-hdmi",
.owner  = THIS_MODULE,
+   .pm = _hdmi_pm_ops,
.of_match_table = hdmi_match_types,
},
 };
-- 
1.9.1

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

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

2015-11-03 Thread Inki Dae 
This patch series adds pm runtime support for Exynos drm.

Originally, this patch was posted by Gustavo but there was no any
answer about some comments. So I rebased this patch series on top of
exynos-drm-next, removed unnecessary patches and modified wrong macro.

Changelog v2:
- Remove patch 5 and 6.
  . commit callback are already removed so isn't required anymore.
- Remove patch 8 which makes dp clock enabled directly from FIMD.
  . Really not mendatory for FIMD uses DP, and it could be different
according to Board.
- Modified CONFIG_PM_SLEEP to CONFIG_PM.
  . In case of runtime pm, CONFIG_PM macro should be used instead of
CONFIG_PM_SLEEP.

Gustavo Padovan (7):
  drm/exynos: do not start enabling DP at bind() phase
  drm/exynos: add pm_runtime to DP
  drm/exynos: add pm_runtime to HDMI
  drm/exynos: add pm_runtime to Mixer
  drm/exynos: add pm_runtime to FIMD
  drm/exynos: add pm_runtime to DECON 5433
  drm/exynos: add pm_runtime to DECON 7

 drivers/gpu/drm/exynos/exynos5433_drm_decon.c |  54 ++---
 drivers/gpu/drm/exynos/exynos7_drm_decon.c| 125 +--
 drivers/gpu/drm/exynos/exynos_dp_core.c   | 165 +++---
 drivers/gpu/drm/exynos/exynos_dp_core.h   |   1 +
 drivers/gpu/drm/exynos/exynos_drm_fimd.c  |  91 ++
 drivers/gpu/drm/exynos/exynos_hdmi.c  |  56 ++---
 drivers/gpu/drm/exynos/exynos_mixer.c | 125 ++-
 7 files changed, 352 insertions(+), 265 deletions(-)

-- 
1.9.1

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

[PATCH v2 4/7] drm/exynos: add pm_runtime to Mixer

2015-11-03 Thread Inki Dae 
From: Gustavo Padovan 

Let pm_runtime handle the enabling/disabling of the device with proper
refcnt instead of rely on specific flags to track the enabled state.

Signed-off-by: Gustavo Padovan 
Signed-off-by: Inki Dae 
---
 drivers/gpu/drm/exynos/exynos_mixer.c | 125 +-
 1 file changed, 61 insertions(+), 64 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
b/drivers/gpu/drm/exynos/exynos_mixer.c
index d09f8f9..7498c6e 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -70,7 +70,6 @@ enum mixer_version_id {
 };
 
 enum mixer_flag_bits {
-   MXR_BIT_POWERED,
MXR_BIT_VSYNC,
 };
 
@@ -926,8 +925,6 @@ static int mixer_enable_vblank(struct exynos_drm_crtc *crtc)
struct mixer_resources *res = _ctx->mixer_res;
 
__set_bit(MXR_BIT_VSYNC, _ctx->flags);
-   if (!test_bit(MXR_BIT_POWERED, _ctx->flags))
-   return 0;
 
/* enable vsync interrupt */
mixer_reg_writemask(res, MXR_INT_STATUS, ~0, MXR_INT_CLEAR_VSYNC);
@@ -943,9 +940,6 @@ static void mixer_disable_vblank(struct exynos_drm_crtc 
*crtc)
 
__clear_bit(MXR_BIT_VSYNC, _ctx->flags);
 
-   if (!test_bit(MXR_BIT_POWERED, _ctx->flags))
-   return;
-
/* disable vsync interrupt */
mixer_reg_writemask(res, MXR_INT_STATUS, ~0, MXR_INT_CLEAR_VSYNC);
mixer_reg_writemask(res, MXR_INT_EN, 0, MXR_INT_EN_VSYNC);
@@ -958,9 +952,6 @@ static void mixer_update_plane(struct exynos_drm_crtc *crtc,
 
DRM_DEBUG_KMS("win: %d\n", plane->zpos);
 
-   if (!test_bit(MXR_BIT_POWERED, _ctx->flags))
-   return;
-
if (plane->zpos > 1 && mixer_ctx->vp_enabled)
vp_video_buffer(mixer_ctx, plane);
else
@@ -976,9 +967,6 @@ static void mixer_disable_plane(struct exynos_drm_crtc 
*crtc,
 
DRM_DEBUG_KMS("win: %d\n", plane->zpos);
 
-   if (!test_bit(MXR_BIT_POWERED, _ctx->flags))
-   return;
-
spin_lock_irqsave(>reg_slock, flags);
mixer_vsync_set_update(mixer_ctx, false);
 
@@ -993,9 +981,6 @@ static void mixer_wait_for_vblank(struct exynos_drm_crtc 
*crtc)
struct mixer_context *mixer_ctx = crtc->ctx;
int err;
 
-   if (!test_bit(MXR_BIT_POWERED, _ctx->flags))
-   return;
-
err = drm_vblank_get(mixer_ctx->drm_dev, mixer_ctx->pipe);
if (err < 0) {
DRM_DEBUG_KMS("failed to acquire vblank counter\n");
@@ -1020,43 +1005,9 @@ static void mixer_enable(struct exynos_drm_crtc *crtc)
 {
struct mixer_context *ctx = crtc->ctx;
struct mixer_resources *res = >mixer_res;
-   int ret;
-
-   if (test_bit(MXR_BIT_POWERED, >flags))
-   return;
 
pm_runtime_get_sync(ctx->dev);
 
-   ret = clk_prepare_enable(res->mixer);
-   if (ret < 0) {
-   DRM_ERROR("Failed to prepare_enable the mixer clk [%d]\n", ret);
-   return;
-   }
-   ret = clk_prepare_enable(res->hdmi);
-   if (ret < 0) {
-   DRM_ERROR("Failed to prepare_enable the hdmi clk [%d]\n", ret);
-   return;
-   }
-   if (ctx->vp_enabled) {
-   ret = clk_prepare_enable(res->vp);
-   if (ret < 0) {
-   DRM_ERROR("Failed to prepare_enable the vp clk [%d]\n",
- ret);
-   return;
-   }
-   if (ctx->has_sclk) {
-   ret = clk_prepare_enable(res->sclk_mixer);
-   if (ret < 0) {
-   DRM_ERROR("Failed to prepare_enable the " \
-  "sclk_mixer clk [%d]\n",
- ret);
-   return;
-   }
-   }
-   }
-
-   set_bit(MXR_BIT_POWERED, >flags);
-
mixer_reg_writemask(res, MXR_STATUS, ~0, MXR_STATUS_SOFT_RESET);
 
if (test_bit(MXR_BIT_VSYNC, >flags)) {
@@ -1069,29 +1020,15 @@ static void mixer_enable(struct exynos_drm_crtc *crtc)
 static void mixer_disable(struct exynos_drm_crtc *crtc)
 {
struct mixer_context *ctx = crtc->ctx;
-   struct mixer_resources *res = >mixer_res;
int i;
 
-   if (!test_bit(MXR_BIT_POWERED, >flags))
-   return;
-
mixer_stop(ctx);
mixer_regs_dump(ctx);
 
for (i = 0; i < MIXER_WIN_NR; i++)
mixer_disable_plane(crtc, >planes[i]);
 
-   clear_bit(MXR_BIT_POWERED, >flags);
-
-   clk_disable_unprepare(res->hdmi);
-   clk_disable_unprepare(res->mixer);
-   if (ctx->vp_enabled) {
-   clk_disable_unprepare(res->vp);
-   if (ctx->has_sclk)
-   clk_disable_unprepare(res->sclk_mixer);
-   }
-
-   pm_runtime_put_sync(ctx->dev);
+

[PATCH v2 1/7] drm/exynos: do not start enabling DP at bind() phase

2015-11-03 Thread Inki Dae 
From: Gustavo Padovan 

The DP device will be properly enabled at the enable() call just
after the bind call finishes.

Changelog v2:
- no change

Signed-off-by: Gustavo Padovan 
Signed-off-by: Inki Dae 
---
 drivers/gpu/drm/exynos/exynos_dp_core.c | 107 +++-
 drivers/gpu/drm/exynos/exynos_dp_core.h |   1 +
 2 files changed, 78 insertions(+), 30 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
b/drivers/gpu/drm/exynos/exynos_dp_core.c
index 124fb9a..e4d32a1 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -1009,9 +1009,9 @@ static int exynos_drm_attach_lcd_bridge(struct 
exynos_dp_device *dp,
 {
int ret;
 
-   encoder->bridge = dp->bridge;
-   dp->bridge->encoder = encoder;
-   ret = drm_bridge_attach(encoder->dev, dp->bridge);
+   encoder->bridge->next = dp->ptn_bridge;
+   dp->ptn_bridge->encoder = encoder;
+   ret = drm_bridge_attach(encoder->dev, dp->ptn_bridge);
if (ret) {
DRM_ERROR("Failed to attach bridge to drm\n");
return ret;
@@ -1020,14 +1020,15 @@ static int exynos_drm_attach_lcd_bridge(struct 
exynos_dp_device *dp,
return 0;
 }
 
-static int exynos_dp_create_connector(struct drm_encoder *encoder)
+static int exynos_dp_bridge_attach(struct drm_bridge *bridge)
 {
-   struct exynos_dp_device *dp = encoder_to_dp(encoder);
+   struct exynos_dp_device *dp = bridge->driver_private;
+   struct drm_encoder *encoder = >encoder;
struct drm_connector *connector = >connector;
int ret;
 
/* Pre-empt DP connector creation if there's a bridge */
-   if (dp->bridge) {
+   if (dp->ptn_bridge) {
ret = exynos_drm_attach_lcd_bridge(dp, encoder);
if (!ret)
return 0;
@@ -1052,22 +1053,9 @@ static int exynos_dp_create_connector(struct drm_encoder 
*encoder)
return ret;
 }
 
-static bool exynos_dp_mode_fixup(struct drm_encoder *encoder,
-const struct drm_display_mode *mode,
-struct drm_display_mode *adjusted_mode)
-{
-   return true;
-}
-
-static void exynos_dp_mode_set(struct drm_encoder *encoder,
-  struct drm_display_mode *mode,
-  struct drm_display_mode *adjusted_mode)
-{
-}
-
-static void exynos_dp_enable(struct drm_encoder *encoder)
+static void exynos_dp_bridge_enable(struct drm_bridge *bridge)
 {
-   struct exynos_dp_device *dp = encoder_to_dp(encoder);
+   struct exynos_dp_device *dp = bridge->driver_private;
struct exynos_drm_crtc *crtc = dp_to_crtc(dp);
 
if (dp->dpms_mode == DRM_MODE_DPMS_ON)
@@ -1092,9 +1080,9 @@ static void exynos_dp_enable(struct drm_encoder *encoder)
dp->dpms_mode = DRM_MODE_DPMS_ON;
 }
 
-static void exynos_dp_disable(struct drm_encoder *encoder)
+static void exynos_dp_bridge_disable(struct drm_bridge *bridge)
 {
-   struct exynos_dp_device *dp = encoder_to_dp(encoder);
+   struct exynos_dp_device *dp = bridge->driver_private;
struct exynos_drm_crtc *crtc = dp_to_crtc(dp);
 
if (dp->dpms_mode != DRM_MODE_DPMS_ON)
@@ -1123,6 +,69 @@ static void exynos_dp_disable(struct drm_encoder 
*encoder)
dp->dpms_mode = DRM_MODE_DPMS_OFF;
 }
 
+static void exynos_dp_bridge_nop(struct drm_bridge *bridge)
+{
+   /* do nothing */
+}
+
+static const struct drm_bridge_funcs exynos_dp_bridge_funcs = {
+   .enable = exynos_dp_bridge_enable,
+   .disable = exynos_dp_bridge_disable,
+   .pre_enable = exynos_dp_bridge_nop,
+   .post_disable = exynos_dp_bridge_nop,
+   .attach = exynos_dp_bridge_attach,
+};
+
+static int exynos_dp_create_connector(struct drm_encoder *encoder)
+{
+   struct exynos_dp_device *dp = encoder_to_dp(encoder);
+   struct drm_device *drm_dev = dp->drm_dev;
+   struct drm_bridge *bridge;
+   int ret;
+
+   bridge = devm_kzalloc(drm_dev->dev, sizeof(*bridge), GFP_KERNEL);
+   if (!bridge) {
+   DRM_ERROR("failed to allocate for drm bridge\n");
+   return -ENOMEM;
+   }
+
+   dp->bridge = bridge;
+
+   encoder->bridge = bridge;
+   bridge->driver_private = dp;
+   bridge->encoder = encoder;
+   bridge->funcs = _dp_bridge_funcs;
+
+   ret = drm_bridge_attach(drm_dev, bridge);
+   if (ret) {
+   DRM_ERROR("failed to attach drm bridge\n");
+   return -EINVAL;
+   }
+
+   return 0;
+}
+
+static bool exynos_dp_mode_fixup(struct drm_encoder *encoder,
+const struct drm_display_mode *mode,
+struct drm_display_mode *adjusted_mode)
+{
+   return true;
+}
+
+static void exynos_dp_mode_set(struct drm_encoder *encoder,
+

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

2015-11-03 Thread Andrzej Hajda 
Hi Inki,

On 11/03/2015 11:47 AM, Inki Dae wrote:
> This patch series adds pm runtime support for Exynos drm.
> 
> Originally, this patch was posted by Gustavo but there was no any
> answer about some comments. So I rebased this patch series on top of
> exynos-drm-next, removed unnecessary patches and modified wrong macro.

I have sent comment to original patchset[1], but for some strange reasons
it went only to mailing lists.
My concerns were as follows:
- exynos_drm has already pm_runtime support via exynos_drm_drv pm ops,
  why should we add per component support?
- component suspend sequence is non deterministic, but in case of
  video pipelines, specification often requires fixed order,
- the patchset adds implicit dependency on PM_SLEEP.


Current solution should work correctly and it was OK last time I have tested it.
I am not sure about atomic requirements, are there special ones?

There are other issues with current solution, rather easy to solve:
- it assumes that exynos-drm device will be suspended first - it should be true,
 as it is created at the end and suspend order is reverse to creation order, but
 I am not sure if we can rely on it - some solution is to add pm callbacks to
 all components, and from those callbacks call one centralized pm routine,
- suspend/resume callbacks theoretically can be called during component
  master initialization/deinitailization it could be racy,
- exynos_drm_sys_suspend/resume calls exynos_drm_suspend/resume
  for historical reasons, these function can be merged together.

[1]: http://permalink.gmane.org/gmane.linux.kernel.samsung-soc/48395

Regards
Andrzej

> 
> Changelog v2:
> - Remove patch 5 and 6.
>   . commit callback are already removed so isn't required anymore.
> - Remove patch 8 which makes dp clock enabled directly from FIMD.
>   . Really not mendatory for FIMD uses DP, and it could be different
> according to Board.
> - Modified CONFIG_PM_SLEEP to CONFIG_PM.
>   . In case of runtime pm, CONFIG_PM macro should be used instead of
> CONFIG_PM_SLEEP.
> 
> Gustavo Padovan (7):
>   drm/exynos: do not start enabling DP at bind() phase
>   drm/exynos: add pm_runtime to DP
>   drm/exynos: add pm_runtime to HDMI
>   drm/exynos: add pm_runtime to Mixer
>   drm/exynos: add pm_runtime to FIMD
>   drm/exynos: add pm_runtime to DECON 5433
>   drm/exynos: add pm_runtime to DECON 7
> 
>  drivers/gpu/drm/exynos/exynos5433_drm_decon.c |  54 ++---
>  drivers/gpu/drm/exynos/exynos7_drm_decon.c| 125 +--
>  drivers/gpu/drm/exynos/exynos_dp_core.c   | 165 
> +++---
>  drivers/gpu/drm/exynos/exynos_dp_core.h   |   1 +
>  drivers/gpu/drm/exynos/exynos_drm_fimd.c  |  91 ++
>  drivers/gpu/drm/exynos/exynos_hdmi.c  |  56 ++---
>  drivers/gpu/drm/exynos/exynos_mixer.c | 125 ++-
>  7 files changed, 352 insertions(+), 265 deletions(-)
> 

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

Re: [PATCH 20/22] clocksource/drivers/exynos_mct: Fix Kconfig and add COMPILE_TEST option

2015-11-03 Thread Daniel Lezcano 

On 11/03/2015 11:02 AM, Arnd Bergmann wrote:

On Tuesday 03 November 2015 09:40:02 Daniel Lezcano wrote:

On 11/03/2015 01:59 AM, Krzysztof Kozlowski wrote:

On 03.11.2015 09:30, Krzysztof Kozlowski wrote:

On 02.11.2015 21:56, Daniel Lezcano wrote:

Let the platform's Kconfig to select the clock instead of having a reverse
dependency from the driver to the platform options.


Selecting user-visible symbols is rather discouraged so why not
something like this:

-   def_bool y if ARCH_EXYNOS
-   depends on !ARM64
+   bool "Exynos multi core timer driver"
+   depends on ARCH_EXYNOS || (COMPILE_TEST && ARM)


Nope, that was wrong as we loose auto-select on Exynos. Instead:
-   def_bool y if ARCH_EXYNOS
-   depends on !ARM64
+   bool "Exynos multi core timer driver" if ARM
+   depends on ARCH_EXYNOS || COMPILE_TEST
+   default y if ARCH_EXYNOS

This way we avoid select (which is a reverse dependency for the driver),
have it auto-selectable and compile tested on arm.


I think you misunderstood the patch I sent.

It does two things:

1. Follow the thumb of rule of the current Kconfig format

 - The timer driver is selected by the platform (exynos in this case)
 - User can't select the driver in the menuconfig
 - There is no dependency on the platform except for compilation test

2. Add the COMPILE_TEST

 - User can select the driver for compilation testing. This is for
allyesconfig when doing compilation test coverage (exynos timer could be
compiled on other platform). As the delay code is not portable, we have
to restrict the compilation on the ARM platform, this is why there is
the dependency on ARM.

I am currently looking at splitting the delay code in order to prevent
this restriction on this driver and some others drivers.


I suspect this will come up again in the future. The problem is
really that drivers/clocksource has different rules from almost
everything else, by requiring the platform to 'select' the driver.

The second version that Krzysztof posted is how we handle this in
other driver subsystems, and I would generally prefer it to do this
consistently for everything, but John Stultz has in the past argued
strongly for using 'select' in all clocksource drivers. The reason
is that for each platform we know in advance which driver we want,
and there is never a need for the user to have to select the right
one.


Yes, and I second John in this.



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

Re: [PATCH 20/22] clocksource/drivers/exynos_mct: Fix Kconfig and add COMPILE_TEST option

2015-11-03 Thread Krzysztof Kozlowski 
W dniu 03.11.2015 o 19:02, Arnd Bergmann pisze:
> On Tuesday 03 November 2015 09:40:02 Daniel Lezcano wrote:
>> On 11/03/2015 01:59 AM, Krzysztof Kozlowski wrote:
>>> On 03.11.2015 09:30, Krzysztof Kozlowski wrote:
 On 02.11.2015 21:56, Daniel Lezcano wrote:
> Let the platform's Kconfig to select the clock instead of having a reverse
> dependency from the driver to the platform options.

 Selecting user-visible symbols is rather discouraged so why not
 something like this:

 -   def_bool y if ARCH_EXYNOS
 -   depends on !ARM64
 +   bool "Exynos multi core timer driver"
 +   depends on ARCH_EXYNOS || (COMPILE_TEST && ARM)
>>>
>>> Nope, that was wrong as we loose auto-select on Exynos. Instead:
>>> -   def_bool y if ARCH_EXYNOS
>>> -   depends on !ARM64
>>> +   bool "Exynos multi core timer driver" if ARM
>>> +   depends on ARCH_EXYNOS || COMPILE_TEST
>>> +   default y if ARCH_EXYNOS
>>>
>>> This way we avoid select (which is a reverse dependency for the driver),
>>> have it auto-selectable and compile tested on arm.
>>
>> I think you misunderstood the patch I sent.
>>
>> It does two things:
>>
>> 1. Follow the thumb of rule of the current Kconfig format
>>
>> - The timer driver is selected by the platform (exynos in this case)
>> - User can't select the driver in the menuconfig
>> - There is no dependency on the platform except for compilation test
>>
>> 2. Add the COMPILE_TEST
>>
>> - User can select the driver for compilation testing. This is for 
>> allyesconfig when doing compilation test coverage (exynos timer could be 
>> compiled on other platform). As the delay code is not portable, we have 
>> to restrict the compilation on the ARM platform, this is why there is 
>> the dependency on ARM.
>>
>> I am currently looking at splitting the delay code in order to prevent 
>> this restriction on this driver and some others drivers.
> 
> I suspect this will come up again in the future. The problem is
> really that drivers/clocksource has different rules from almost
> everything else, by requiring the platform to 'select' the driver.
> 
> The second version that Krzysztof posted is how we handle this in
> other driver subsystems, and I would generally prefer it to do this
> consistently for everything, but John Stultz has in the past argued
> strongly for using 'select' in all clocksource drivers. The reason
> is that for each platform we know in advance which driver we want,
> and there is never a need for the user to have to select the right
> one.

Arnd, Daniel,

Sure, makes sense to me, thanks for explanation. Actually this makes me
thinking that drivers/soc/* should probably follow the same
convention... but not all of them do that.

Anyway the patch worked fine and with explanation I can only confirm:

Tested-by: Krzysztof Kozlowski 
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 20/22] clocksource/drivers/exynos_mct: Fix Kconfig and add COMPILE_TEST option

2015-11-03 Thread Daniel Lezcano 

On 11/03/2015 01:01 PM, Krzysztof Kozlowski wrote:

Anyway the patch worked fine and with explanation I can only confirm:


Great ! Thanks Krzysztof for testing.

  -- Daniel

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

Re: [PATCH v9 10/17] phy: Add driver for rockchip Display Port PHY

2015-11-03 Thread Brian Norris 
Hi Yakir,

On Wed, Nov 04, 2015 at 08:48:38AM +0800, Yakir Yang wrote:
> On 11/03/2015 12:38 PM, Brian Norris wrote:
> >On Thu, Oct 29, 2015 at 09:58:38AM +0800, Yakir Yang wrote:
> >(FYI, I came across this by inspection when comparing Heiko's
> >'somewhat-stable' branch [1] with this series. The former brings up eDP
> >fine on veyron-jaq, whereas this one doesn't yet, even with the above
> >change. Still debugging the issue.)
> 
> Hmm... I'm not sure whether your eDP screen have the hotplug signal, so I

I believe hotplug is hooked up but...

> think you can try to add "analogix,force-hpd" flag into
> rk3288-veyron-jaq.dts
> 
>  {
> analogix,need-force-hpd;
> }

...already tried, just in case. No luck.

> If that changes couldn't fix the problem, guess you may need max the panel
> power up delay time which pointed by Heiko. Like:
> 
> Thanks,
> - Yakir
> 
> 
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> index 4fa5f69..546a506 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> @@ -82,6 +82,13 @@ static int analogix_dp_detect_hpd(struct
> analogix_dp_device *dp)
>  */
> dev_dbg(dp->dev, "failed to get hpd plug status, try to
> force hpd\n");
> 
> +   /*
> +* Hotplug signal would indicate the right time to operate
> +* panel after poweron, but if the hotplug is missing, then
> +* panel would need wait hundreds of milliseconds at here.
> +*/
> +   mdelay(100);
> +
> analogix_dp_force_hpd(dp);
> 
> if (analogix_dp_get_plug_in_status(dp) != 0) {

I'll give that a try. Per Heiko's suggestion, I've already hacked around
with adding delays in the regulator node, but this could give slightly
different behavior. I doubt it'll help, but I'll let you know if it
does.

Regards,
Brian
--
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 v9 10/17] phy: Add driver for rockchip Display Port PHY

2015-11-03 Thread Yakir Yang 

Hi Brain,

On 11/03/2015 12:38 PM, Brian Norris wrote:

Hi Yakir,

On Thu, Oct 29, 2015 at 09:58:38AM +0800, Yakir Yang wrote:

Add phy driver for the Rockchip DisplayPort PHY module. This
is required to get DisplayPort working in Rockchip SoCs.

Reviewed-by: Heiko Stuebner
Signed-off-by: Yakir Yang
---

...

diff --git a/drivers/phy/phy-rockchip-dp.c b/drivers/phy/phy-rockchip-dp.c
new file mode 100644
index 000..f3e0058
--- /dev/null
+++ b/drivers/phy/phy-rockchip-dp.c
@@ -0,0 +1,151 @@
+/*
+ * Rockchip DP PHY driver
+ *
+ * Copyright (C) 2015 FuZhou Rockchip Co., Ltd.
+ * Author: Yakir Yang
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define GRF_SOC_CON12   0x0274
+
+#define GRF_EDP_REF_CLK_SEL_INTER_HIWORD_MASK   BIT(4)
+#define GRF_EDP_REF_CLK_SEL_INTER   BIT(4)

Why are the above two macros the same? Judging by the RK3288 manual and
other downstream drivers, it seems like you want the _MASK one to be
shifted left by 16 (i.e., BIT(20)).


Oops, yes, you're right, it should be BIT(20), thanks for the catch.


+
+#define GRF_EDP_PHY_SIDDQ_HIWORD_MASK   BIT(21)
+#define GRF_EDP_PHY_SIDDQ_ON0
+#define GRF_EDP_PHY_SIDDQ_OFF   BIT(5)
+

...


+   ret = regmap_write(dp->grf, GRF_SOC_CON12, GRF_EDP_REF_CLK_SEL_INTER |
+  GRF_EDP_REF_CLK_SEL_INTER_HIWORD_MASK);

IOW, the above is writing:

BIT(4) | BIT(4)

whereas I think you want:

BIT(4) | BIT(20)


+   if (ret != 0) {
+   dev_err(dp->dev, "Could not config GRF edp ref clk: %d\n", ret);
+   return ret;
+   }
+

...

(FYI, I came across this by inspection when comparing Heiko's
'somewhat-stable' branch [1] with this series. The former brings up eDP
fine on veyron-jaq, whereas this one doesn't yet, even with the above
change. Still debugging the issue.)


Hmm... I'm not sure whether your eDP screen have the hotplug signal, so I
think you can try to add "analogix,force-hpd" flag into 
rk3288-veyron-jaq.dts


 {
analogix,need-force-hpd;
}


If that changes couldn't fix the problem, guess you may need max the panel
power up delay time which pointed by Heiko. Like:

Thanks,
- Yakir


diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c

index 4fa5f69..546a506 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -82,6 +82,13 @@ static int analogix_dp_detect_hpd(struct 
analogix_dp_device *dp)

 */
dev_dbg(dp->dev, "failed to get hpd plug status, try to force 
hpd\n");


+   /*
+* Hotplug signal would indicate the right time to operate
+* panel after poweron, but if the hotplug is missing, then
+* panel would need wait hundreds of milliseconds at here.
+*/
+   mdelay(100);
+
analogix_dp_force_hpd(dp);

if (analogix_dp_get_plug_in_status(dp) != 0) {



Brian

[1]https://github.com/mmind/linux-rockchip/tree/devel/somewhat-stable






--
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/4] Exynos SROMc configuration and Ethernet support for SMDK5410

2015-11-03 Thread Krzysztof Kozlowski 
On 03.11.2015 18:16, Pavel Fedin wrote:
> This patch extends Exynos SROM controller driver with ability to configure
> controller outputs and enables SMSC9115 Ethernet chip on SMDK5410 board,
> which is connected via SROMc bank #3.
> 
> With this patchset, support for the whole existing SMDK range can be added.
> Actually, only bank number is different.
> 
> This patchset also depends on Exynos 5410 pinctrl support, introduced by
> patches 0003 and 0004 from this set:
> [PATCH v4 0/5] ARM: EXYNOS: ODROID-XU DT and LEDs
> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/330862.html

Only the first patch made up to kernel. The rest (2-5) received feedback
and I am waiting for fixing it. Andreas apparently loose the interest...

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

2015-11-03 Thread Andrzej Hajda 
On 11/03/2015 04:38 PM, Inki Dae wrote:
>  
> 2015-11-03 22:24 GMT+09:00 Andrzej Hajda  >:
> > Hi Inki,
> >
> > On 11/03/2015 11:47 AM, Inki Dae wrote:
> >> This patch series adds pm runtime support for Exynos drm.
> >>
> >> Originally, this patch was posted by Gustavo but there was no any
> >> answer about some comments. So I rebased this patch series on top of
> >> exynos-drm-next, removed unnecessary patches and modified wrong macro.
> >
> > I have sent comment to original patchset[1], but for some strange reasons
> > it went only to mailing lists.
> > My concerns were as follows:
> > - exynos_drm has already pm_runtime support via exynos_drm_drv pm ops,
> >   why should we add per component support?
>  
> For this, I think I already mentioned enough,
> http://www.spinics.net/lists/linux-samsung-soc/msg47695.html
>
> In brief, exynos_drm_drv doesn't control each power domain of each kms device.
> It means that we cannot power off fully without pm runtime interface of each
> kms device - just they can only control their clock not power domain. So
> question. How we could control power domain of each kms device without runtime
> pm interface?

Hmm, but to enable pm_runtime in components it is enough to use
pm_runtime_enable/disable and pm_runtime_get/put(_sync), there is no need to add
pm callbacks.
In fact most of the components already supports runtime pm,  but quick grep
shows that it is not implemented in:
exynos_drm_dsi.c, exynos_dp_core.c, exynos_drm_mic.c.
So I guess adding pm_runtime support by adding calls pm_runtime_enable/disable
and pm_runtime_get/put(_sync) in appropriate places should be enough.

>
> > - component suspend sequence is non deterministic, but in case of
> >   video pipelines, specification often requires fixed order,
>
> Can your show me an example? I think component suspend and resume are invoked
> by only drm dpms interface, and the dpms interface has a fixed order - when
> dpms goes to off, encoder first, and when dpms goes to on, crtc first.

Now as I understand you do not want to remove exynos_drm_drv pm callbacks so
they will disable devices properly, after that clock disabling order should not
matter, so the whole point is not valid.

>
> My only concern is that runtime pm interface of each kms driver is called
> within pm sleep context of Exynos drm driver. So I will look into this no 
> problem.
>
> > - the patchset adds implicit dependency on PM_SLEEP.
> >
> >
> > Current solution should work correctly and it was OK last time I have 
> > tested it.
> > I am not sure about atomic requirements, are there special ones?
>
> Not related to atomic feature.
>
> >
> > There are other issues with current solution, rather easy to solve:
> > - it assumes that exynos-drm device will be suspended first - it should be 
> > true,
> >  as it is created at the end and suspend order is reverse to creation 
> > order, but
> >  I am not sure if we can rely on it - some solution is to add pm callbacks 
> > to
> >  all components, and from those callbacks call one centralized pm routine,
>
> You mean pm callbacks are pm sleep interface? And you mean let's add sleep pm
> interface to each kms driver?  If so, I'm not agree with you because sleep pm
> should be controlled by only drm top like single driver does.

Lets look at an example:
Assume we have present only fimd and dsi components.
In such case kernel creates two platform devices for fimd and dsi in early stage
of parsing device tree blob.
During exynos_drm_drv initialization exynos-drm platform device is created, the
important thing it is created after fimd and dsi.
Now when platform enters sleep mode suspend callbacks are called, the important
thing here is
in which order. If I remember correctly PM guarantees only that children will be
handled before parents.
Since we have no parent-child relation between exynos-drm, fimd and dsi, the
order is unknown.
So it will be possible that component will enter sleep mode before exynos-drm
and in such case system can even
hang if exynos-drm callbacks will try to access registers of such component.
Fortunately in current implementation of PM order of suspending is reversed
order of device creation, so
it will be always exynos-drm first.

So in short we rely here on implementation detail of PM framework.

>
> > - suspend/resume callbacks theoretically can be called during component
> >   master initialization/deinitailization it could be racy,
>
> I'm not sure what you mean but component master
> initialization/deinitailization mean bind and unbind? If so, bind/unbind
> interfaces of all components will never call pm relevant interfaces but the
> the pm relevant interfaces are called by only dpms interface.

exynos_drm_sys_suspend and exynos_drm_sys_resume takes pointer
to drm_device and uses it. It is possible that in the same time drm_driver
is destroyed for some reason it will result in invalid pointer in resume/suspend
callbacks.

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

2015-11-03 Thread Inki Dae 


2015년 11월 04일 16:24에 Andrzej Hajda 이(가) 쓴 글:
> On 11/03/2015 04:38 PM, Inki Dae wrote:
>>  
>> 2015-11-03 22:24 GMT+09:00 Andrzej Hajda > >:
>>> Hi Inki,
>>>
>>> On 11/03/2015 11:47 AM, Inki Dae wrote:
 This patch series adds pm runtime support for Exynos drm.

 Originally, this patch was posted by Gustavo but there was no any
 answer about some comments. So I rebased this patch series on top of
 exynos-drm-next, removed unnecessary patches and modified wrong macro.
>>>
>>> I have sent comment to original patchset[1], but for some strange reasons
>>> it went only to mailing lists.
>>> My concerns were as follows:
>>> - exynos_drm has already pm_runtime support via exynos_drm_drv pm ops,
>>>   why should we add per component support?
>>  
>> For this, I think I already mentioned enough,
>> http://www.spinics.net/lists/linux-samsung-soc/msg47695.html
>>
>> In brief, exynos_drm_drv doesn't control each power domain of each kms 
>> device.
>> It means that we cannot power off fully without pm runtime interface of each
>> kms device - just they can only control their clock not power domain. So
>> question. How we could control power domain of each kms device without 
>> runtime
>> pm interface?
> 
> Hmm, but to enable pm_runtime in components it is enough to use
> pm_runtime_enable/disable and pm_runtime_get/put(_sync), there is no need to 
> add
> pm callbacks.

That is this patch series does, and pm callback is implemented in 
exynos_drm_drv not in component drivers.

> In fact most of the components already supports runtime pm,  but quick grep
> shows that it is not implemented in:
> exynos_drm_dsi.c, exynos_dp_core.c, exynos_drm_mic.c.

exynos_dp_core already has runtime pm interface with this patch series. For dsi 
and mic, we need to add the runtime pm interfaces.

> So I guess adding pm_runtime support by adding calls pm_runtime_enable/disable
> and pm_runtime_get/put(_sync) in appropriate places should be enough.
> 
>>
>>> - component suspend sequence is non deterministic, but in case of
>>>   video pipelines, specification often requires fixed order,
>>
>> Can your show me an example? I think component suspend and resume are invoked
>> by only drm dpms interface, and the dpms interface has a fixed order - when
>> dpms goes to off, encoder first, and when dpms goes to on, crtc first.
> 
> Now as I understand you do not want to remove exynos_drm_drv pm callbacks so
> they will disable devices properly, after that clock disabling order should 
> not
> matter, so the whole point is not valid.

In this case, the dpms actually is invoked by SLEEP PM of Linux power 
management framework. DRM KMS has a interface to control power of kms device, 
which is really different from SLEEP PM.
So this request can be done by userspace in runtime - just Display power off/on.

> 
>>
>> My only concern is that runtime pm interface of each kms driver is called
>> within pm sleep context of Exynos drm driver. So I will look into this no 
>> problem.
>>
>>> - the patchset adds implicit dependency on PM_SLEEP.
>>>
>>>
>>> Current solution should work correctly and it was OK last time I have 
>>> tested it.
>>> I am not sure about atomic requirements, are there special ones?
>>
>> Not related to atomic feature.
>>
>>>
>>> There are other issues with current solution, rather easy to solve:
>>> - it assumes that exynos-drm device will be suspended first - it should be 
>>> true,
>>>  as it is created at the end and suspend order is reverse to creation 
>>> order, but
>>>  I am not sure if we can rely on it - some solution is to add pm callbacks 
>>> to
>>>  all components, and from those callbacks call one centralized pm routine,
>>
>> You mean pm callbacks are pm sleep interface? And you mean let's add sleep pm
>> interface to each kms driver?  If so, I'm not agree with you because sleep pm
>> should be controlled by only drm top like single driver does.
> 
> Lets look at an example:
> Assume we have present only fimd and dsi components.
> In such case kernel creates two platform devices for fimd and dsi in early 
> stage
> of parsing device tree blob.
> During exynos_drm_drv initialization exynos-drm platform device is created, 
> the
> important thing it is created after fimd and dsi.
> Now when platform enters sleep mode suspend callbacks are called, the 
> important
> thing here is
> in which order. If I remember correctly PM guarantees only that children will 
> be
> handled before parents.
> Since we have no parent-child relation between exynos-drm, fimd and dsi, the
> order is unknown.

exynos-drm is not real hardware. So the order is only valid for kms devices - 
components.
The only thing exynos-drm does is to invoke dpms so that kms devices are 
enabled or disabled in fixed order.

And as I mentioned before, my only concern is that runtime pm interface of each 
kms driver is called
within pm sleep context of Exynos drm driver. So required

Re: [PATCH 20/22] clocksource/drivers/exynos_mct: Fix Kconfig and add COMPILE_TEST option

2015-11-03 Thread John Stultz 
On Tue, Nov 3, 2015 at 2:02 AM, Arnd Bergmann  wrote:
> I suspect this will come up again in the future. The problem is
> really that drivers/clocksource has different rules from almost
> everything else, by requiring the platform to 'select' the driver.
>
> The second version that Krzysztof posted is how we handle this in
> other driver subsystems, and I would generally prefer it to do this
> consistently for everything, but John Stultz has in the past argued
> strongly for using 'select' in all clocksource drivers. The reason
> is that for each platform we know in advance which driver we want,
> and there is never a need for the user to have to select the right
> one.

And just to clarify, I don't necessarily think "select" is the right
method, as creating an option that defaults to Y if the right
architecture/platform support is present is fine too.

I just don't want users to have to search deeply through menuconfig to
find a clocksource driver checkbox when they have already selected a
platform and provided enough information for us to know which
clocksource driver is needed.  So my argument its really all about
avoiding user-prompts in kconfig for clocksources.  It is conceptually
easier to do this w/ select, but you can also do it via default y and
proper dependencies.

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

[PATCH v2 5/7] drm/exynos: add pm_runtime to FIMD

2015-11-03 Thread Inki Dae 
From: Gustavo Padovan 

Let pm_runtime handle the enabling/disabling of the device with proper
refcnt instead of rely on specific flags to track the enabled state.

Changelog v2:
- Remove unnecessary changes which removed commit callback from decon drivers
  and modify CONFIG_PM_SLEEP -> CONFIG_PM

Signed-off-by: Gustavo Padovan 
Signed-off-by: Inki Dae 
---
 drivers/gpu/drm/exynos/exynos_drm_fimd.c | 91 +---
 1 file changed, 37 insertions(+), 54 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index bd75c15..ae97271 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -160,7 +160,6 @@ struct fimd_context {
u32 vidout_con;
u32 i80ifcon;
booli80_if;
-   boolsuspended;
int pipe;
wait_queue_head_t   wait_vsync_queue;
atomic_twait_vsync_event;
@@ -209,9 +208,6 @@ static int fimd_enable_vblank(struct exynos_drm_crtc *crtc)
struct fimd_context *ctx = crtc->ctx;
u32 val;
 
-   if (ctx->suspended)
-   return -EPERM;
-
if (!test_and_set_bit(0, >irq_flags)) {
val = readl(ctx->regs + VIDINTCON0);
 
@@ -241,9 +237,6 @@ static void fimd_disable_vblank(struct exynos_drm_crtc 
*crtc)
struct fimd_context *ctx = crtc->ctx;
u32 val;
 
-   if (ctx->suspended)
-   return;
-
if (test_and_clear_bit(0, >irq_flags)) {
val = readl(ctx->regs + VIDINTCON0);
 
@@ -264,9 +257,6 @@ static void fimd_wait_for_vblank(struct exynos_drm_crtc 
*crtc)
 {
struct fimd_context *ctx = crtc->ctx;
 
-   if (ctx->suspended)
-   return;
-
atomic_set(>wait_vsync_event, 1);
 
/*
@@ -339,14 +329,12 @@ static void fimd_clear_channels(struct exynos_drm_crtc 
*crtc)
int pipe = ctx->pipe;
 
/* ensure that vblank interrupt won't be reported to core */
-   ctx->suspended = false;
ctx->pipe = -1;
 
fimd_enable_vblank(ctx->crtc);
fimd_wait_for_vblank(ctx->crtc);
fimd_disable_vblank(ctx->crtc);
 
-   ctx->suspended = true;
ctx->pipe = pipe;
}
 
@@ -384,9 +372,6 @@ static void fimd_commit(struct exynos_drm_crtc *crtc)
void *timing_base = ctx->regs + driver_data->timing_base;
u32 val, clkdiv;
 
-   if (ctx->suspended)
-   return;
-
/* nothing to do if we haven't set the mode yet */
if (mode->htotal == 0 || mode->vtotal == 0)
return;
@@ -620,9 +605,6 @@ static void fimd_atomic_begin(struct exynos_drm_crtc *crtc,
 {
struct fimd_context *ctx = crtc->ctx;
 
-   if (ctx->suspended)
-   return;
-
fimd_shadow_protect_win(ctx, plane->zpos, true);
 }
 
@@ -631,9 +613,6 @@ static void fimd_atomic_flush(struct exynos_drm_crtc *crtc,
 {
struct fimd_context *ctx = crtc->ctx;
 
-   if (ctx->suspended)
-   return;
-
fimd_shadow_protect_win(ctx, plane->zpos, false);
 }
 
@@ -649,9 +628,6 @@ static void fimd_update_plane(struct exynos_drm_crtc *crtc,
unsigned int bpp = state->fb->bits_per_pixel >> 3;
unsigned int pitch = state->fb->pitches[0];
 
-   if (ctx->suspended)
-   return;
-
offset = plane->src_x * bpp;
offset += plane->src_y * pitch;
 
@@ -733,9 +709,6 @@ static void fimd_disable_plane(struct exynos_drm_crtc *crtc,
struct fimd_context *ctx = crtc->ctx;
unsigned int win = plane->zpos;
 
-   if (ctx->suspended)
-   return;
-
fimd_enable_video_output(ctx, win, false);
 
if (ctx->driver_data->has_shadowcon)
@@ -745,27 +718,9 @@ static void fimd_disable_plane(struct exynos_drm_crtc 
*crtc,
 static void fimd_enable(struct exynos_drm_crtc *crtc)
 {
struct fimd_context *ctx = crtc->ctx;
-   int ret;
-
-   if (!ctx->suspended)
-   return;
-
-   ctx->suspended = false;
 
pm_runtime_get_sync(ctx->dev);
 
-   ret = clk_prepare_enable(ctx->bus_clk);
-   if (ret < 0) {
-   DRM_ERROR("Failed to prepare_enable the bus clk [%d]\n", ret);
-   return;
-   }
-
-   ret = clk_prepare_enable(ctx->lcd_clk);
-   if  (ret < 0) {
-   DRM_ERROR("Failed to prepare_enable the lcd clk [%d]\n", ret);
-   return;
-   }
-
/* if vblank was enabled status, enable it again. */
if (test_and_clear_bit(0, >irq_flags))
fimd_enable_vblank(ctx->crtc);
@@ -778,9 +733,6 @@ static void fimd_disable(struct