Re: [PATCH V4 2/2] video: drm: exynos: Add device tree support

[InKi Dae]

Hi,

2012/9/5 Kyungmin Park kmp...@infradead.org:
 Hi,

 On Thu, Sep 6, 2012 at 12:39 AM, Leela Krishna Amudala
 l.kris...@samsung.com wrote:
 Add device tree based discovery support for DRM-FIMD driver.

 Signed-off-by: Leela Krishna Amudala l.kris...@samsung.com
 ---
  Documentation/devicetree/bindings/fb/drm-fimd.txt |   80 +
  drivers/gpu/drm/exynos/exynos_drm_fimd.c  |   95 
 -
  2 files changed, 173 insertions(+), 2 deletions(-)
  create mode 100644 Documentation/devicetree/bindings/fb/drm-fimd.txt

 diff --git a/Documentation/devicetree/bindings/fb/drm-fimd.txt 
 b/Documentation/devicetree/bindings/fb/drm-fimd.txt
 new file mode 100644
 index 000..4ff1829
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/fb/drm-fimd.txt
 @@ -0,0 +1,80 @@
 +* Samsung Display Controller using DRM frame work
 +
 +The display controller is used to transfer image data from memory to an
 +external LCD driver interface. It supports various color formats such as
 +rgb and yuv.
 +
 +Required properties:
 + - compatible: Should be samsung,exynos5-fimd or samsung,exynos4-fb for
 Doesn't better to use single word? fimd or fb?. I think 'fb' is used
 for framebuffer historically.
 but now it's used both fb and drm, so fimd is neutral and architecture
 specific.

 To do this, Modify arch-exynos first and update it at each drivers it 
 properly.

 Thank you,
 Kyungmin Park


I agree with Kyungmin but I'd like to use as is. the reason we used
'exynos4-fb' as device name, is for that it uses fimd driver's
platform device commonly and gets fimd clock. so I think that dts file
should be defined with hardware specific name but not driver name such
as 'exynos4-fb'. but with this, we can't get fimd clock with device's
name because 'exynos4-fb' is used as device name of fimd clock. so to
use 'exynos4-fimd', we should modify the device name of fimd clock
from 'exynos4-fb'  to 'exynos4-fimd' and also ids definitions of
s3c-fb and drm fimd driver. so my conclusion is that it merges this
patch set as is and then let's modify related things later.
any opinions, welcome~ anytime.

Thanks.
Inki Dae
--
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] ASoC: SAMSUNG: Add SND_SOC_DAIFMT_CONT option for snd_soc_set_fmt()

[Sangsu Park]

On Thurs, Sep 06, 2012 at 9:22 AM +0900, Mark Brown wrote:
 On Mon, Sep 03, 2012 at 11:10:03AM +0900, Sangsu Park wrote:
  On Sun, Aug 31, 2012 at 2:43 AM +0900, Mark Brown wrote:
   On Wed, Aug 29, 2012 at 08:06:32PM +0900, Sangsu Park wrote:
 
   Please check your mailer configuration, it looks like it's reformatting
   all the text with much longer line widths.
 
  I've changed line width configuration. Is it ok now?
 
 Looks like it, thanks.
 
  Do you think that changing pcm driver is right approach?
  Then I'll fix pcm driver. (I think that pcm driver has some strange code.)
 
 Well, we could do both.  It'd certainly be more natural to make it have
 a default given that this isn't something that normally needs to be
 configured.
 
Then, I'll fix pcm driver to use default given
and resend that patch.

Thanks.
 ___
 linux-arm-kernel mailing list
 linux-arm-ker...@lists.infradead.org
 http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

[PATCH 0/2] i2c: s3c2410: allow pin pin configuration using pinctrl

[Thomas Abraham]

This patch series adds support for pinctrl interface based i2c-bus
configuration for the s3c2410 i2c controller driver.

The second patch would have conflict with Exynos4 DTS reorganization
patches posted by Tomasz Figa. If those patches are applied prior to this
patch, I will rebase this patch and resubmit.

Thomas Abraham (2):
  i2c: s3c2410: add optional pin configuration using pinctrl interface
  ARM: dts: exynos4: allow i2c0 bus to be configured using pinctrl interface

 arch/arm/boot/dts/exynos4210-smdkv310.dts |2 --
 arch/arm/boot/dts/exynos4210.dtsi |2 ++
 drivers/i2c/busses/i2c-s3c2410.c  |   19 ---
 3 files changed, 18 insertions(+), 5 deletions(-)

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

[PATCH 1/2] i2c: s3c2410: add optional pin configuration using pinctrl interface

[Thomas Abraham]

Add optional support for i2c bus pin configuration using pinctrl interface

Cc: Ben Dooks ben-li...@fluff.org
Signed-off-by: Thomas Abraham thomas.abra...@linaro.org
---
 drivers/i2c/busses/i2c-s3c2410.c |   19 ---
 1 files changed, 16 insertions(+), 3 deletions(-)

diff --git a/drivers/i2c/busses/i2c-s3c2410.c b/drivers/i2c/busses/i2c-s3c2410.c
index 5ae3b02..f4b2d6f 100644
--- a/drivers/i2c/busses/i2c-s3c2410.c
+++ b/drivers/i2c/busses/i2c-s3c2410.c
@@ -38,6 +38,7 @@
 #include linux/io.h
 #include linux/of_i2c.h
 #include linux/of_gpio.h
+#include linux/pinctrl/consumer.h
 
 #include asm/irq.h
 
@@ -83,6 +84,8 @@ struct s3c24xx_i2c {
 
struct s3c2410_platform_i2c *pdata;
int gpios[2];
+   struct pinctrl  *pctrl;
+   struct pinctrl_state*pctrl_state;
 #ifdef CONFIG_CPU_FREQ
struct notifier_block   freq_transition;
 #endif
@@ -859,11 +862,17 @@ static int s3c24xx_i2c_init(struct s3c24xx_i2c *i2c)
 
/* inititalise the gpio */
 
-   if (pdata-cfg_gpio)
+   if (pdata-cfg_gpio) {
pdata-cfg_gpio(to_platform_device(i2c-dev));
-   else
-   if (s3c24xx_i2c_parse_dt_gpio(i2c))
+   } else if (!IS_ERR_OR_NULL(i2c-pctrl) 
+   !IS_ERR_OR_NULL(i2c-pctrl_state)) {
+   if (pinctrl_select_state(i2c-pctrl, i2c-pctrl_state)) {
+   dev_err(i2c-dev, failed to configure io-pins\n);
+   return -ENXIO;
+   }
+   } else if (s3c24xx_i2c_parse_dt_gpio(i2c)) {
return -EINVAL;
+   }
 
/* write slave address */
 
@@ -1013,6 +1022,10 @@ static int s3c24xx_i2c_probe(struct platform_device 
*pdev)
i2c-adap.algo_data = i2c;
i2c-adap.dev.parent = pdev-dev;
 
+   i2c-pctrl = devm_pinctrl_get(i2c-dev);
+   if (!IS_ERR_OR_NULL(i2c-pctrl))
+   i2c-pctrl_state = pinctrl_lookup_state(i2c-pctrl, default);
+
/* initialise the i2c controller */
 
ret = s3c24xx_i2c_init(i2c);
-- 
1.6.6.rc2

--
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/2] ARM: dts: exynos4: allow i2c0 bus to be configured using pinctrl interface

[Thomas Abraham]

Add a default pin state for i2c0 controller which the pinctrl interface can
use to setup the i2c0 bus.

Signed-off-by: Thomas Abraham thomas.abra...@linaro.org
---
 arch/arm/boot/dts/exynos4210-smdkv310.dts |2 --
 arch/arm/boot/dts/exynos4210.dtsi |2 ++
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/exynos4210-smdkv310.dts 
b/arch/arm/boot/dts/exynos4210-smdkv310.dts
index 1beccc8..ea76542 100644
--- a/arch/arm/boot/dts/exynos4210-smdkv310.dts
+++ b/arch/arm/boot/dts/exynos4210-smdkv310.dts
@@ -126,8 +126,6 @@
#size-cells = 0;
samsung,i2c-sda-delay = 100;
samsung,i2c-max-bus-freq = 2;
-   gpios = gpd1 0 2 3 0,
-   gpd1 1 2 3 0;
 
eeprom@50 {
compatible = samsung,24ad0xd1;
diff --git a/arch/arm/boot/dts/exynos4210.dtsi 
b/arch/arm/boot/dts/exynos4210.dtsi
index a4bd0c9..e08387f 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -157,6 +157,8 @@
compatible = samsung,s3c2440-i2c;
reg = 0x1386 0x100;
interrupts = 0 58 0;
+   pinctrl-names = default;
+   pinctrl-0 = i2c0_bus;
};
 
i2c@1387 {
-- 
1.6.6.rc2

--
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] i2c: s3c2410: add optional pin configuration using pinctrl interface

[Tomasz Figa]

Hi,

This patch shows the problem of the need to explicitly migrate all drivers 
to pinctrl.

Maybe we should consider extending the pinctrl subsystem to set the default 
state automatically before binding a driver to a device, at least in case 
of DT-based platforms?

This would be similar to what is done currently with samsung-gpio bindings 
- the pin is being configured by custom xlate callback based on additional 
cells in GPIO specifier, when the driver retrieves the pin using 
of_get{_named,}_gpio without the need of setting it up in the driver.

Best regards,
-- 
Tomasz Figa
Samsung Poland RD Center

On Thursday 06 of September 2012 14:53:00 Thomas Abraham wrote:
 Add optional support for i2c bus pin configuration using pinctrl
 interface
 
 Cc: Ben Dooks ben-li...@fluff.org
 Signed-off-by: Thomas Abraham thomas.abra...@linaro.org
 ---
  drivers/i2c/busses/i2c-s3c2410.c |   19 ---
  1 files changed, 16 insertions(+), 3 deletions(-)
 
 diff --git a/drivers/i2c/busses/i2c-s3c2410.c
 b/drivers/i2c/busses/i2c-s3c2410.c index 5ae3b02..f4b2d6f 100644
 --- a/drivers/i2c/busses/i2c-s3c2410.c
 +++ b/drivers/i2c/busses/i2c-s3c2410.c
 @@ -38,6 +38,7 @@
  #include linux/io.h
  #include linux/of_i2c.h
  #include linux/of_gpio.h
 +#include linux/pinctrl/consumer.h
 
  #include asm/irq.h
 
 @@ -83,6 +84,8 @@ struct s3c24xx_i2c {
 
   struct s3c2410_platform_i2c *pdata;
   int gpios[2];
 + struct pinctrl  *pctrl;
 + struct pinctrl_state*pctrl_state;
  #ifdef CONFIG_CPU_FREQ
   struct notifier_block   freq_transition;
  #endif
 @@ -859,11 +862,17 @@ static int s3c24xx_i2c_init(struct s3c24xx_i2c
 *i2c)
 
   /* inititalise the gpio */
 
 - if (pdata-cfg_gpio)
 + if (pdata-cfg_gpio) {
   pdata-cfg_gpio(to_platform_device(i2c-dev));
 - else
 - if (s3c24xx_i2c_parse_dt_gpio(i2c))
 + } else if (!IS_ERR_OR_NULL(i2c-pctrl) 
 + !IS_ERR_OR_NULL(i2c-pctrl_state)) {
 + if (pinctrl_select_state(i2c-pctrl, i2c-pctrl_state)) {
 + dev_err(i2c-dev, failed to configure io-pins\n);
 + return -ENXIO;
 + }
 + } else if (s3c24xx_i2c_parse_dt_gpio(i2c)) {
   return -EINVAL;
 + }
 
   /* write slave address */
 
 @@ -1013,6 +1022,10 @@ static int s3c24xx_i2c_probe(struct
 platform_device *pdev) i2c-adap.algo_data = i2c;
   i2c-adap.dev.parent = pdev-dev;
 
 + i2c-pctrl = devm_pinctrl_get(i2c-dev);
 + if (!IS_ERR_OR_NULL(i2c-pctrl))
 + i2c-pctrl_state = pinctrl_lookup_state(i2c-pctrl, default);
 +
   /* initialise the i2c controller */
 
   ret = s3c24xx_i2c_init(i2c);

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

[PATCH 0/3] ARM: EXYNOS: Power domain DT support extension

[Tomasz Figa]

This patch series fixes two issues with existing DT support for Exynos
power domains and extends it with the ability of binding devices to domains,
basically making it possible to use power domains when using DT.

Tomasz Figa (3):
  ARM: EXYNOS: pm_domain: Detect domain state on registration from DT
  ARM: EXYNOS: pm_domain: Fix power domain name initialization
  ARM: EXYNOS: pm_domain: Bind devices to power domains using DT

 .../bindings/arm/exynos/power_domain.txt   | 15 +++-
 arch/arm/mach-exynos/pm_domains.c  | 93 +-
 2 files changed, 100 insertions(+), 8 deletions(-)

-- 
1.7.12

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

[PATCH 1/3] ARM: EXYNOS: pm_domain: Detect domain state on registration from DT

[Tomasz Figa]

Initial state of power domains might vary on different boards and with
different bootloaders. This patch adds detection of initial state of
power domains when being registered from DT.

Signed-off-by: Tomasz Figa t.f...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
 Documentation/devicetree/bindings/arm/exynos/power_domain.txt | 4 
 arch/arm/mach-exynos/pm_domains.c | 8 +---
 2 files changed, 5 insertions(+), 7 deletions(-)

diff --git a/Documentation/devicetree/bindings/arm/exynos/power_domain.txt 
b/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
index 6528e21..843b546 100644
--- a/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
+++ b/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
@@ -9,10 +9,6 @@ Required Properties:
 - reg: physical base address of the controller and length of memory mapped
 region.
 
-Optional Properties:
-- samsung,exynos4210-pd-off: Specifies that the power domain is in turned-off
-state during boot and remains to be turned-off until explicitly turned-on.
-
 Example:
 
lcd0: power-domain-lcd0 {
diff --git a/arch/arm/mach-exynos/pm_domains.c 
b/arch/arm/mach-exynos/pm_domains.c
index c0bc83a..d1abc1a 100644
--- a/arch/arm/mach-exynos/pm_domains.c
+++ b/arch/arm/mach-exynos/pm_domains.c
@@ -89,6 +89,7 @@ static __init int exynos_pm_dt_parse_domains(void)
 
for_each_compatible_node(np, NULL, samsung,exynos4210-pd) {
struct exynos_pm_domain *pd;
+   int on;
 
pd = kzalloc(sizeof(*pd), GFP_KERNEL);
if (!pd) {
@@ -97,14 +98,15 @@ static __init int exynos_pm_dt_parse_domains(void)
return -ENOMEM;
}
 
-   if (of_get_property(np, samsung,exynos4210-pd-off, NULL))
-   pd-is_off = true;
pd-name = np-name;
pd-base = of_iomap(np, 0);
pd-pd.power_off = exynos_pd_power_off;
pd-pd.power_on = exynos_pd_power_on;
pd-pd.of_node = np;
-   pm_genpd_init(pd-pd, NULL, false);
+
+   on = __raw_readl(pd-base + 0x4)  S5P_INT_LOCAL_PWR_EN;
+
+   pm_genpd_init(pd-pd, NULL, !on);
}
return 0;
 }
-- 
1.7.12

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

[PATCH 2/3] ARM: EXYNOS: pm_domain: Fix power domain name initialization

[Tomasz Figa]

This patch adds initialization of name field in generic power domain
struct.

Signed-off-by: Tomasz Figa t.f...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
 arch/arm/mach-exynos/pm_domains.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-exynos/pm_domains.c 
b/arch/arm/mach-exynos/pm_domains.c
index d1abc1a..5b7ce7e 100644
--- a/arch/arm/mach-exynos/pm_domains.c
+++ b/arch/arm/mach-exynos/pm_domains.c
@@ -98,7 +98,8 @@ static __init int exynos_pm_dt_parse_domains(void)
return -ENOMEM;
}
 
-   pd-name = np-name;
+   pd-pd.name = kstrdup(np-name, GFP_KERNEL);
+   pd-name = pd-pd.name;
pd-base = of_iomap(np, 0);
pd-pd.power_off = exynos_pd_power_off;
pd-pd.power_on = exynos_pd_power_on;
-- 
1.7.12

--
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/3] ARM: EXYNOS: pm_domain: Bind devices to power domains using DT

[Tomasz Figa]

This patch adds a way to specify bindings between devices and power
domains using device tree.

A device can be bound to particular power domain by adding a
power-domain property containing a phandle to the domain. The device
will be bound to the domain before binding a driver to it and unbound
after unbinding a driver from it.

Signed-off-by: Tomasz Figa t.f...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
 .../bindings/arm/exynos/power_domain.txt   | 13 +++-
 arch/arm/mach-exynos/pm_domains.c  | 82 ++
 2 files changed, 94 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/arm/exynos/power_domain.txt 
b/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
index 843b546..8ed914f 100644
--- a/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
+++ b/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
@@ -4,14 +4,25 @@ Exynos processors include support for multiple power domains 
which are used
 to gate power to one or more peripherals on the processor.
 
 Required Properties:
-- compatiable: should be one of the following.
+- compatible: should be one of the following.
 * samsung,exynos4210-pd - for exynos4210 type power domain.
 - reg: physical base address of the controller and length of memory mapped
 region.
 
+Node of a device using power domains must have a power-domain property defined
+with a phandle to respective power domain.
+
 Example:
 
lcd0: power-domain-lcd0 {
compatible = samsung,exynos4210-pd;
reg = 0x10023C00 0x10;
};
+
+Example of the node using power domain:
+
+   node {
+   /* ... */
+   power-domain = lcd0;
+   /* ... */
+   };
diff --git a/arch/arm/mach-exynos/pm_domains.c 
b/arch/arm/mach-exynos/pm_domains.c
index 5b7ce7e..7b3b8a3 100644
--- a/arch/arm/mach-exynos/pm_domains.c
+++ b/arch/arm/mach-exynos/pm_domains.c
@@ -19,6 +19,8 @@
 #include linux/pm_domain.h
 #include linux/delay.h
 #include linux/of_address.h
+#include linux/of_platform.h
+#include linux/sched.h
 
 #include mach/regs-pmu.h
 #include plat/devs.h
@@ -83,14 +85,89 @@ static struct exynos_pm_domain PD = {   
\
 }
 
 #ifdef CONFIG_OF
+static void exynos_add_device_to_domain(struct exynos_pm_domain *pd,
+   struct device *dev)
+{
+   int ret;
+
+   dev_dbg(dev, adding to power domain %s\n, pd-pd.name);
+
+   while(1) {
+   ret = pm_genpd_add_device(pd-pd, dev);
+   if (ret != -EAGAIN)
+   break;
+   cond_resched();
+   }
+
+   pm_genpd_dev_need_restore(dev, true);
+}
+
+static void exynos_remove_device_from_domain(struct device *dev)
+{
+   struct generic_pm_domain *genpd = dev_to_genpd(dev);
+   int ret;
+
+   dev_dbg(dev, removing from power domain %s\n, genpd-name);
+
+   while(1) {
+   ret = pm_genpd_remove_device(genpd, dev);
+   if (ret != -EAGAIN)
+   break;
+   cond_resched();
+   }
+}
+
+static void exynos_read_domain_from_dt(struct device *dev)
+{
+   struct platform_device *pd_pdev;
+   struct exynos_pm_domain *pd;
+   struct device_node *node;
+
+   node = of_parse_phandle(dev-of_node, power-domain, 0);
+   if (!node)
+   return;
+   pd_pdev = of_find_device_by_node(node);
+   if (!pd_pdev)
+   return;
+   pd = platform_get_drvdata(pd_pdev);
+   exynos_add_device_to_domain(pd, dev);
+}
+
+static int exynos_pm_notifier_call(struct notifier_block *nb,
+   unsigned long event, void *data)
+{
+   struct device *dev = data;
+
+   switch (event) {
+   case BUS_NOTIFY_BIND_DRIVER:
+   if (dev-of_node)
+   exynos_read_domain_from_dt(dev);
+
+   break;
+
+   case BUS_NOTIFY_UNBOUND_DRIVER:
+   exynos_remove_device_from_domain(dev);
+
+   break;
+   }
+   return NOTIFY_DONE;
+}
+
+static struct notifier_block platform_nb = {
+   .notifier_call = exynos_pm_notifier_call,
+};
+
 static __init int exynos_pm_dt_parse_domains(void)
 {
+   struct platform_device *pdev;
struct device_node *np;
 
for_each_compatible_node(np, NULL, samsung,exynos4210-pd) {
struct exynos_pm_domain *pd;
int on;
 
+   pdev = of_find_device_by_node(np);
+
pd = kzalloc(sizeof(*pd), GFP_KERNEL);
if (!pd) {
pr_err(%s: failed to allocate memory for domain\n,
@@ -105,10 +182,15 @@ static __init int exynos_pm_dt_parse_domains(void)
pd-pd.power_on = exynos_pd_power_on;
pd-pd.of_node = np;
 
+   platform_set_drvdata(pdev, pd);
+
on = __raw_readl(pd-base 

Re: [PATCH 2/2] ARM: dts: exynos4: allow i2c0 bus to be configured using pinctrl interface

[Tomasz Figa]

Hi Thomas,

On Thursday 06 of September 2012 14:53:01 Thomas Abraham wrote:
   compatible = samsung,s3c2440-i2c;
   reg = 0x1386 0x100;
   interrupts = 0 58 0;
 + pinctrl-names = default;
 + pinctrl-0 = i2c0_bus;

If pinctrl-names property is omitted then the state index is used as a name 
(e.g. pinctrl-0 would be named 0). Maybe it would be better to use this 
approach (with respective adjustment in first patch)? What do you think?

Best regards,
-- 
Tomasz Figa
Samsung Poland RD Center

--
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 2/2] video: drm: exynos: Add device tree support

[Sylwester Nawrocki]

Hi,

On 09/06/2012 09:21 AM, InKi Dae wrote:
 +Required properties:
 + - compatible: Should be samsung,exynos5-fimd or samsung,exynos4-fb for
 Doesn't better to use single word? fimd or fb?. I think 'fb' is used
 for framebuffer historically.
 but now it's used both fb and drm, so fimd is neutral and architecture
 specific.

 To do this, Modify arch-exynos first and update it at each drivers it 
 properly.

 Thank you,
 Kyungmin Park

 
 I agree with Kyungmin but I'd like to use as is. the reason we used
 'exynos4-fb' as device name, is for that it uses fimd driver's
 platform device commonly and gets fimd clock. so I think that dts file
 should be defined with hardware specific name but not driver name such
 as 'exynos4-fb'. but with this, we can't get fimd clock with device's
 name because 'exynos4-fb' is used as device name of fimd clock. so to
 use 'exynos4-fimd', we should modify the device name of fimd clock
 from 'exynos4-fb'  to 'exynos4-fimd' and also ids definitions of
 s3c-fb and drm fimd driver. so my conclusion is that it merges this

I think it's good moment to put those things in order, i.e. use uniform 
'compatible' names: samsung,exynos4-fimd, samsung,exynos5-fimd. 
Platform device names are separate issue, but could perhaps be unified 
at this time as well.

 patch set as is and then let's modify related things later.
 any opinions, welcome~ anytime.
 
 Thanks.
 Inki Dae

--

Regards,
Sylwester
--
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] i2c: s3c2410: add optional pin configuration using pinctrl interface

[Thomas Abraham]

On 6 September 2012 15:04, Tomasz Figa t.f...@samsung.com wrote:
 Hi,

 This patch shows the problem of the need to explicitly migrate all drivers
 to pinctrl.

 Maybe we should consider extending the pinctrl subsystem to set the default
 state automatically before binding a driver to a device, at least in case
 of DT-based platforms?

The pinctrl driver allows for activating default pin configuration
when the pinctrl driver loads. This is referred to as hogging. But
should hog be used or not is something that needs to be decided. Some
of the factors which favor the driver explicitly setting up the pin
configuration are

1. After a suspend and resume cycle, the pin configuration registers
may be reset to default values. Hence, during resume, the pin
configuration has be redone.

2. Runtime muxing/config is possible.

3. Setting some of the config options such as pull-up by default might
start consuming power from boot time itself, which could be avoided if
such setup is done only when needed.

Adding pinctrl driver support in device drivers seems to be simple
task. And it is just one time effort which can be reused on multiple
SoC's.


 This would be similar to what is done currently with samsung-gpio bindings
 - the pin is being configured by custom xlate callback based on additional
 cells in GPIO specifier, when the driver retrieves the pin using
 of_get{_named,}_gpio without the need of setting it up in the driver.

The Samsung gpio dt bindings was just a bootstrap method to get device
tree support going for Samsung platforms. The gpio xlate callback was
used as a back door to setup the pinmux/pinconfig due to lack of
generic driver interface to setup the pinmux/pinconfig for Samsung
platforms. From a linux perspective, gpio and pinmux/pinconfig are
separate entities. So using gpio xlate to setup pinmux/pinconfig was
not correct but helped getting device tree enabled for Samsung
platforms. With the pinctrl framework available now, there are generic
interfaces to setup gpio and pinmux /pinconfig.

Thanks,
Thomas.


 Best regards,
 --
 Tomasz Figa
 Samsung Poland RD Center

 On Thursday 06 of September 2012 14:53:00 Thomas Abraham wrote:
 Add optional support for i2c bus pin configuration using pinctrl
 interface

 Cc: Ben Dooks ben-li...@fluff.org
 Signed-off-by: Thomas Abraham thomas.abra...@linaro.org
 ---
  drivers/i2c/busses/i2c-s3c2410.c |   19 ---
  1 files changed, 16 insertions(+), 3 deletions(-)

 diff --git a/drivers/i2c/busses/i2c-s3c2410.c
 b/drivers/i2c/busses/i2c-s3c2410.c index 5ae3b02..f4b2d6f 100644
 --- a/drivers/i2c/busses/i2c-s3c2410.c
 +++ b/drivers/i2c/busses/i2c-s3c2410.c
 @@ -38,6 +38,7 @@
  #include linux/io.h
  #include linux/of_i2c.h
  #include linux/of_gpio.h
 +#include linux/pinctrl/consumer.h

  #include asm/irq.h

 @@ -83,6 +84,8 @@ struct s3c24xx_i2c {

   struct s3c2410_platform_i2c *pdata;
   int gpios[2];
 + struct pinctrl  *pctrl;
 + struct pinctrl_state*pctrl_state;
  #ifdef CONFIG_CPU_FREQ
   struct notifier_block   freq_transition;
  #endif
 @@ -859,11 +862,17 @@ static int s3c24xx_i2c_init(struct s3c24xx_i2c
 *i2c)

   /* inititalise the gpio */

 - if (pdata-cfg_gpio)
 + if (pdata-cfg_gpio) {
   pdata-cfg_gpio(to_platform_device(i2c-dev));
 - else
 - if (s3c24xx_i2c_parse_dt_gpio(i2c))
 + } else if (!IS_ERR_OR_NULL(i2c-pctrl) 
 + !IS_ERR_OR_NULL(i2c-pctrl_state)) {
 + if (pinctrl_select_state(i2c-pctrl, i2c-pctrl_state)) {
 + dev_err(i2c-dev, failed to configure io-pins\n);
 + return -ENXIO;
 + }
 + } else if (s3c24xx_i2c_parse_dt_gpio(i2c)) {
   return -EINVAL;
 + }

   /* write slave address */

 @@ -1013,6 +1022,10 @@ static int s3c24xx_i2c_probe(struct
 platform_device *pdev) i2c-adap.algo_data = i2c;
   i2c-adap.dev.parent = pdev-dev;

 + i2c-pctrl = devm_pinctrl_get(i2c-dev);
 + if (!IS_ERR_OR_NULL(i2c-pctrl))
 + i2c-pctrl_state = pinctrl_lookup_state(i2c-pctrl, default);
 +
   /* initialise the i2c controller */

   ret = s3c24xx_i2c_init(i2c);

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

Re: [PATCH 2/2] ARM: dts: exynos4: allow i2c0 bus to be configured using pinctrl interface

[Thomas Abraham]

On 6 September 2012 15:43, Tomasz Figa t.f...@samsung.com wrote:
 Hi Thomas,

 On Thursday 06 of September 2012 14:53:01 Thomas Abraham wrote:
   compatible = samsung,s3c2440-i2c;
   reg = 0x1386 0x100;
   interrupts = 0 58 0;
 + pinctrl-names = default;
 + pinctrl-0 = i2c0_bus;

 If pinctrl-names property is omitted then the state index is used as a name
 (e.g. pinctrl-0 would be named 0). Maybe it would be better to use this
 approach (with respective adjustment in first patch)? What do you think?

I tend to prefer to name the states because it is easier to
cross-reference code and dts files. i2c was a simple one, but for mmc
controllers, there will 1-bit state, 4-bit state and 8-bit state, and
it will be nicer to name then accordingly. So I prefer to use names
but if there is wider consensus on not using names, we can drop names.

Thanks,
Thomas.


 Best regards,
 --
 Tomasz Figa
 Samsung Poland RD Center

--
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] i2c: s3c2410: add optional pin configuration using pinctrl interface

[Tomasz Figa]

Hi,

Thanks for your comments.

On Thursday 06 of September 2012 16:36:08 Thomas Abraham wrote:
  This patch shows the problem of the need to explicitly migrate all
  drivers to pinctrl.
  
  Maybe we should consider extending the pinctrl subsystem to set the
  default state automatically before binding a driver to a device, at
  least in case of DT-based platforms?
 
 The pinctrl driver allows for activating default pin configuration
 when the pinctrl driver loads. This is referred to as hogging.

What I suggested is that such default configuration would be applied just 
before binding a driver, i.e. when it's almost sure that the device will be 
actually used and the configuration will be needed.

Of course such functionality would not have to be obligatory. For example, 
we could add new property, like pinctrl-set-default, to point in device 
tree that this device should have its pinctrl state set up automatically.

 But
 should hog be used or not is something that needs to be decided. Some
 of the factors which favor the driver explicitly setting up the pin
 configuration are
 
 1. After a suspend and resume cycle, the pin configuration registers
 may be reset to default values. Hence, during resume, the pin
 configuration has be redone.

In my opinion it should be saved and restored by pinctrl driver (as it was 
done in case of GPIO subsystem previously). This is because the driver can 
usually quickly restore all pins at once and some hardware even provide 
facilities for restoring pin configuration after suspend. (e.g. s3c6410, 
probably not going to use pinctrl, but possibly there are more systems 
using this kind of solution, which allows to switch all pins at once from 
sleep mode settings to normal mode).

 2. Runtime muxing/config is possible.

Of course, for cases where runtime remuxing is required this would be no 
option, but often there is just a single pin configuration used all the 
time.

 3. Setting some of the config options such as pull-up by default might
 start consuming power from boot time itself, which could be avoided if
 such setup is done only when needed.

Making it optional would solve this issue, because in such cases the driver 
already has to be aware of setting pull-ups and similar.

 Adding pinctrl driver support in device drivers seems to be simple
 task. And it is just one time effort which can be reused on multiple
 SoC's.

I agree. Although not modifying the drivers at all would be nicer.

Best regards,
-- 
Tomasz Figa
Samsung Poland RD Center

--
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/2] ARM: Exynos4: Put PCM, Slimbus, Spdif clocks to off state

[Chander Kashyap]

The clocks for PCM, Slimbus, Spdif added to off list in order
to turn them off at boot time.

Signed-off-by: Chander Kashyap chander.kash...@linaro.org
---
 arch/arm/mach-exynos/clock-exynos4.c |   19 +++
 1 file changed, 19 insertions(+)

diff --git a/arch/arm/mach-exynos/clock-exynos4.c 
b/arch/arm/mach-exynos/clock-exynos4.c
index 7cc5491..6a45c9a 100644
--- a/arch/arm/mach-exynos/clock-exynos4.c
+++ b/arch/arm/mach-exynos/clock-exynos4.c
@@ -627,6 +627,25 @@ static struct clk exynos4_init_clocks_off[] = {
.enable = exynos4_clk_ip_peril_ctrl,
.ctrlbit= (1  21),
}, {
+   .name   = pcm,
+   .devname= samsung-pcm.1,
+   .enable = exynos4_clk_ip_peril_ctrl,
+   .ctrlbit= (1  22),
+   }, {
+   .name   = pcm,
+   .devname= samsung-pcm.2,
+   .enable = exynos4_clk_ip_peril_ctrl,
+   .ctrlbit= (1  23),
+   }, {
+   .name   = slimbus,
+   .enable = exynos4_clk_ip_peril_ctrl,
+   .ctrlbit= (1  25),
+   }, {
+   .name   = spdif,
+   .devname= samsung-spdif,
+   .enable = exynos4_clk_ip_peril_ctrl,
+   .ctrlbit= (1  26),
+   }, {
.name   = ac97,
.devname= samsung-ac97,
.enable = exynos4_clk_ip_peril_ctrl,
-- 
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/2] ARM: SAMSUNG: Add check for NULL in clock interface

[Chander Kashyap]

The clock instance parameter in Samsung clock interface is not being checked
for NULL pointers. Add checks for NULL pointers.

Signed-off-by: Chander Kashyap chander.kash...@linaro.org
---
 arch/arm/plat-samsung/clock.c |8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/plat-samsung/clock.c b/arch/arm/plat-samsung/clock.c
index 65c5eca..7938fbc 100644
--- a/arch/arm/plat-samsung/clock.c
+++ b/arch/arm/plat-samsung/clock.c
@@ -119,7 +119,7 @@ void clk_disable(struct clk *clk)
 
 unsigned long clk_get_rate(struct clk *clk)
 {
-   if (IS_ERR(clk))
+   if (IS_ERR_OR_NULL(clk))
return 0;
 
if (clk-rate != 0)
@@ -136,7 +136,7 @@ unsigned long clk_get_rate(struct clk *clk)
 
 long clk_round_rate(struct clk *clk, unsigned long rate)
 {
-   if (!IS_ERR(clk)  clk-ops  clk-ops-round_rate)
+   if (!IS_ERR_OR_NULL(clk)  clk-ops  clk-ops-round_rate)
return (clk-ops-round_rate)(clk, rate);
 
return rate;
@@ -146,7 +146,7 @@ int clk_set_rate(struct clk *clk, unsigned long rate)
 {
int ret;
 
-   if (IS_ERR(clk))
+   if (IS_ERR_OR_NULL(clk))
return -EINVAL;
 
/* We do not default just do a clk-rate = rate as
@@ -175,7 +175,7 @@ int clk_set_parent(struct clk *clk, struct clk *parent)
 {
int ret = 0;
 
-   if (IS_ERR(clk))
+   if (IS_ERR_OR_NULL(clk) || IS_ERR_OR_NULL(parent))
return -EINVAL;
 
spin_lock(clocks_lock);
-- 
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] ARM: EXYNOS: no duplicate mask/unmask in eint0_15

[Daniel Kurtz]

chained_irq_enter/exit() already maskack/unmask the chained interrupt.
There is no need to also explicitly do it in the handler.

Signed-off-by: Daniel Kurtz djku...@chromium.org
---
 arch/arm/mach-exynos/common.c |7 ---
 1 files changed, 0 insertions(+), 7 deletions(-)

diff --git a/arch/arm/mach-exynos/common.c b/arch/arm/mach-exynos/common.c
index 4eb39cd..0a85aec 100644
--- a/arch/arm/mach-exynos/common.c
+++ b/arch/arm/mach-exynos/common.c
@@ -965,14 +965,7 @@ static void exynos_irq_eint0_15(unsigned int irq, struct 
irq_desc *desc)
struct irq_chip *chip = irq_get_chip(irq);
 
chained_irq_enter(chip, desc);
-   chip-irq_mask(desc-irq_data);
-
-   if (chip-irq_ack)
-   chip-irq_ack(desc-irq_data);
-
generic_handle_irq(*irq_data);
-
-   chip-irq_unmask(desc-irq_data);
chained_irq_exit(chip, desc);
 }
 
-- 
1.7.7.3

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

Re: [PATCH v3 1/4] pinctrl: add samsung pinctrl and gpiolib driver

[Stephen Warren]

On 09/05/2012 12:20 AM, Thomas Abraham wrote:
 Add a new device tree enabled pinctrl and gpiolib driver for Samsung
 SoC's. This driver provides a common and extensible framework for all
 Samsung SoC's to interface with the pinctrl and gpiolib subsystems. This
 driver supports only device tree based instantiation and hence can be
 used only on those Samsung platforms that have device tree enabled.
 
 This driver is split into two parts: the pinctrl interface and the gpiolib
 interface. The pinctrl interface registers pinctrl devices with the pinctrl
 subsystem and gpiolib interface registers gpio chips with the gpiolib
 subsystem. The information about the pins, pin groups, pin functions and
 gpio chips, which are SoC specific, are parsed from device tree node.
 
 Cc: Linus Walleij linus.wall...@linaro.org
 Cc: Kukjin Kim kgene@samsung.com
 Signed-off-by: Thomas Abraham thomas.abra...@linaro.org

Acked-by: Stephen Warren swar...@nvidia.com

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

RE: [PATCH v3 1/4] pinctrl: add samsung pinctrl and gpiolib driver

[Kukjin Kim]

Stephen Warren wrote:
 
 On 09/05/2012 12:20 AM, Thomas Abraham wrote:
  Add a new device tree enabled pinctrl and gpiolib driver for Samsung
  SoC's. This driver provides a common and extensible framework for all
  Samsung SoC's to interface with the pinctrl and gpiolib subsystems. This
  driver supports only device tree based instantiation and hence can be
  used only on those Samsung platforms that have device tree enabled.
 
  This driver is split into two parts: the pinctrl interface and the
 gpiolib
  interface. The pinctrl interface registers pinctrl devices with the
 pinctrl
  subsystem and gpiolib interface registers gpio chips with the gpiolib
  subsystem. The information about the pins, pin groups, pin functions and
  gpio chips, which are SoC specific, are parsed from device tree node.
 
  Cc: Linus Walleij linus.wall...@linaro.org
  Cc: Kukjin Kim kgene@samsung.com
  Signed-off-by: Thomas Abraham thomas.abra...@linaro.org
 
 Acked-by: Stephen Warren swar...@nvidia.com

Applied this whole series, thanks.

Best regards,
Kgene.
--
Kukjin Kim kgene@samsung.com, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.

--
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: S3C24XX: Use module_platform_driver macro in h1940-bluetooth.c

[Kukjin Kim]

Sachin Kamat wrote:
 
 module_platform_driver simplifies the code by eliminating
 module_init and module_exit calls.
 
 Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
 ---
  arch/arm/mach-s3c24xx/h1940-bluetooth.c |   14 +-
  1 files changed, 1 insertions(+), 13 deletions(-)
 
 diff --git a/arch/arm/mach-s3c24xx/h1940-bluetooth.c b/arch/arm/mach-
 s3c24xx/h1940-bluetooth.c
 index a5eeb62..57aee91 100644
 --- a/arch/arm/mach-s3c24xx/h1940-bluetooth.c
 +++ b/arch/arm/mach-s3c24xx/h1940-bluetooth.c
 @@ -138,19 +138,7 @@ static struct platform_driver h1940bt_driver = {
   .remove = h1940bt_remove,
  };
 
 -
 -static int __init h1940bt_init(void)
 -{
 - return platform_driver_register(h1940bt_driver);
 -}
 -
 -static void __exit h1940bt_exit(void)
 -{
 - platform_driver_unregister(h1940bt_driver);
 -}
 -
 -module_init(h1940bt_init);
 -module_exit(h1940bt_exit);
 +module_platform_driver(h1940bt_driver);
 
  MODULE_AUTHOR(Arnaud Patard arnaud.pat...@rtp-net.org);
  MODULE_DESCRIPTION(Driver for the iPAQ H1940 bluetooth chip);
 --
 1.7.4.1

Applied, thanks.

Thanks.

Best regards,
Kgene.
--
Kukjin Kim kgene@samsung.com, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.

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

RE: [PATCH 2/2] ARM: S3C24XX: Use module_platform_driver macro in mach-osiris-dvs.c

[Kukjin Kim]

Sachin Kamat wrote:
 
 module_platform_driver simplifies the code by eliminating
 module_init and module_exit calls.
 
 Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
 ---
  arch/arm/mach-s3c24xx/mach-osiris-dvs.c |   13 +
  1 files changed, 1 insertions(+), 12 deletions(-)
 
 diff --git a/arch/arm/mach-s3c24xx/mach-osiris-dvs.c b/arch/arm/mach-
 s3c24xx/mach-osiris-dvs.c
 index ad2792d..5876c6b 100644
 --- a/arch/arm/mach-s3c24xx/mach-osiris-dvs.c
 +++ b/arch/arm/mach-s3c24xx/mach-osiris-dvs.c
 @@ -175,18 +175,7 @@ static struct platform_driver osiris_dvs_driver = {
   },
  };
 
 -static int __init osiris_dvs_init(void)
 -{
 - return platform_driver_register(osiris_dvs_driver);
 -}
 -
 -static void __exit osiris_dvs_exit(void)
 -{
 - platform_driver_unregister(osiris_dvs_driver);
 -}
 -
 -module_init(osiris_dvs_init);
 -module_exit(osiris_dvs_exit);
 +module_platform_driver(osiris_dvs_driver);
 
  MODULE_DESCRIPTION(Simtec OSIRIS DVS support);
  MODULE_AUTHOR(Ben Dooks b...@simtec.co.uk);
 --
 1.7.4.1

Applied, thanks.

Best regards,
Kgene.
--
Kukjin Kim kgene@samsung.com, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.

--
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] gpio: samsung: add devicetree init for s3c24xx arches

[Kukjin Kim]

Linus Walleij wrote:
 
 On Wed, Aug 29, 2012 at 1:09 AM, Kukjin Kim kgene@samsung.com wrote:
  On 08/28/12 14:55, Heiko Stübner wrote:
 
  Until now the Exynos-SoC was the only Samsung-SoC supporting the GPIOs
  via the device tree. This patch implements dt-support for the
  s3c24xx arches.
 
  The controllers contain only 3 cells, as the underlying gpio controller
  does not support controlling the drive strength on a gpio level.
 
  Tested with the gpio-keys driver on a s3c2416 based machine.
 
  Signed-off-by: Heiko Stuebnerhe...@sntech.de
  Reviewed-by: Thomas Abrahamthomas.abra...@linaro.org
 
 
  Yeah, looks good to me...
 
  Acked-by: Kukjin Kim kgene@samsung.com
 
 OK are you taking this into the Samsung tree or shall I take care of it?
 
Hmm...yeah, Samsung tree is better.
Applied with your ack :-)

Thanks.

Best regards,
Kgene.
--
Kukjin Kim kgene@samsung.com, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.

--
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 2/2] video: drm: exynos: Add device tree support

[Leela Krishna Amudala]

Hi,

On Thu, Sep 6, 2012 at 4:35 PM, Sylwester Nawrocki
s.nawro...@samsung.com wrote:
 Hi,

 On 09/06/2012 09:21 AM, InKi Dae wrote:
 +Required properties:
 + - compatible: Should be samsung,exynos5-fimd or samsung,exynos4-fb 
 for
 Doesn't better to use single word? fimd or fb?. I think 'fb' is used
 for framebuffer historically.
 but now it's used both fb and drm, so fimd is neutral and architecture
 specific.

 To do this, Modify arch-exynos first and update it at each drivers it 
 properly.

 Thank you,
 Kyungmin Park


 I agree with Kyungmin but I'd like to use as is. the reason we used
 'exynos4-fb' as device name, is for that it uses fimd driver's
 platform device commonly and gets fimd clock. so I think that dts file
 should be defined with hardware specific name but not driver name such
 as 'exynos4-fb'. but with this, we can't get fimd clock with device's
 name because 'exynos4-fb' is used as device name of fimd clock. so to
 use 'exynos4-fimd', we should modify the device name of fimd clock
 from 'exynos4-fb'  to 'exynos4-fimd' and also ids definitions of
 s3c-fb and drm fimd driver. so my conclusion is that it merges this

 I think it's good moment to put those things in order, i.e. use uniform
 'compatible' names: samsung,exynos4-fimd, samsung,exynos5-fimd.
 Platform device names are separate issue, but could perhaps be unified
 at this time as well.

Yes, Platform device name is independent of compatible string.
Will change the compatible string to samsung,exynos4-fimd and will keep the
device name as exynos4-fb for now. Will change the platform device
names to exynosX-fimd
later.


 patch set as is and then let's modify related things later.
 any opinions, welcome~ anytime.

 Thanks.
 Inki Dae

 --

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

[PATCH V5 0/2] video: drm: Add Device tree support to DRM-FIMD

[Leela Krishna Amudala]

This patch set adds device tree support for DRM-FIMD for Samsung's Exynos5250.
It includes parsing platform data from dts file. Also, adds the driver data
for exynos4 and exynos5 devices.

This patchset is based and tested on top of v3.6-rc4 on smdk5250 board
Also depends on below patchset
http://lists.freedesktop.org/archives/dri-devel/2012-August/026076.html

Changes since V4:
- Changed the compatible string from samsung,exynos4-fb to
  samsung,exynos4-fimd.

Changes since V3:
- Removed the fimd version from driver data and using timing base
  address instead
- Removed the drm_ prefixes to the structures and fucntions

Changes since V2:
- Added driver data to exynos5-drm-fimd as per Marek Szyprowski 
suggestion

Changes since V1:
- Corrected typo errors and changed compatibility string

Leela Krishna Amudala (2):
  drm/exynos: add platform_device_id table and driver data for drm fimd
  video: drm: exynos: Add device tree support

 Documentation/devicetree/bindings/fb/drm-fimd.txt |   80 
 drivers/gpu/drm/exynos/exynos_drm_fimd.c  |  138 -
 2 files changed, 212 insertions(+), 6 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/fb/drm-fimd.txt

--
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 1/2] drm/exynos: add platform_device_id table and driver data for drm fimd

[Leela Krishna Amudala]

Two device ids are created for exynos4-fb and exynos5-fb.
Also, added driver data for exynos4 and exynos5 to pick the timing base address
at runtime to write data into appropriate register address.

Signed-off-by: Leela Krishna Amudala l.kris...@samsung.com
---
 drivers/gpu/drm/exynos/exynos_drm_fimd.c |   43 +++---
 1 files changed, 39 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 24c0bd4..65e927b 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -57,6 +57,18 @@
 
 #define get_fimd_context(dev)  platform_get_drvdata(to_platform_device(dev))
 
+struct fimd_driver_data {
+   unsigned int timing_base;
+};
+
+struct fimd_driver_data exynos4_fimd_driver_data = {
+   .timing_base = 0x0,
+};
+
+struct fimd_driver_data exynos5_fimd_driver_data = {
+   .timing_base = 0x2,
+};
+
 struct fimd_win_data {
unsigned intoffset_x;
unsigned intoffset_y;
@@ -91,6 +103,13 @@ struct fimd_context {
struct exynos_drm_panel_info *panel;
 };
 
+static inline struct fimd_driver_data *drm_fimd_get_driver_data(
+   struct platform_device *pdev)
+{
+   return (struct fimd_driver_data *)
+   platform_get_device_id(pdev)-driver_data;
+}
+
 static bool fimd_display_is_connected(struct device *dev)
 {
DRM_DEBUG_KMS(%s\n, __FILE__);
@@ -194,32 +213,35 @@ static void fimd_commit(struct device *dev)
struct fimd_context *ctx = get_fimd_context(dev);
struct exynos_drm_panel_info *panel = ctx-panel;
struct fb_videomode *timing = panel-timing;
+   struct fimd_driver_data *driver_data;
+   struct platform_device *pdev = to_platform_device(dev);
u32 val;
 
+   driver_data = drm_fimd_get_driver_data(pdev);
if (ctx-suspended)
return;
 
DRM_DEBUG_KMS(%s\n, __FILE__);
 
/* setup polarity values from machine code. */
-   writel(ctx-vidcon1, ctx-regs + VIDCON1);
+   writel(ctx-vidcon1, ctx-regs + driver_data-timing_base + VIDCON1);
 
/* setup vertical timing values. */
val = VIDTCON0_VBPD(timing-upper_margin - 1) |
   VIDTCON0_VFPD(timing-lower_margin - 1) |
   VIDTCON0_VSPW(timing-vsync_len - 1);
-   writel(val, ctx-regs + VIDTCON0);
+   writel(val, ctx-regs + driver_data-timing_base + VIDTCON0);
 
/* setup horizontal timing values.  */
val = VIDTCON1_HBPD(timing-left_margin - 1) |
   VIDTCON1_HFPD(timing-right_margin - 1) |
   VIDTCON1_HSPW(timing-hsync_len - 1);
-   writel(val, ctx-regs + VIDTCON1);
+   writel(val, ctx-regs + driver_data-timing_base + VIDTCON1);
 
/* setup horizontal and vertical display size. */
val = VIDTCON2_LINEVAL(timing-yres - 1) |
   VIDTCON2_HOZVAL(timing-xres - 1);
-   writel(val, ctx-regs + VIDTCON2);
+   writel(val, ctx-regs + driver_data-timing_base + VIDTCON2);
 
/* setup clock source, clock divider, enable dma. */
val = ctx-vidcon0;
@@ -982,6 +1004,18 @@ static int fimd_runtime_resume(struct device *dev)
 }
 #endif
 
+static struct platform_device_id fimd_driver_ids[] = {
+   {
+   .name   = exynos4-fb,
+   .driver_data= (unsigned long)exynos4_fimd_driver_data,
+   }, {
+   .name   = exynos5-fb,
+   .driver_data= (unsigned long)exynos5_fimd_driver_data,
+   },
+   {},
+};
+MODULE_DEVICE_TABLE(platform, fimd_driver_ids);
+
 static const struct dev_pm_ops fimd_pm_ops = {
SET_SYSTEM_SLEEP_PM_OPS(fimd_suspend, fimd_resume)
SET_RUNTIME_PM_OPS(fimd_runtime_suspend, fimd_runtime_resume, NULL)
@@ -990,6 +1024,7 @@ static const struct dev_pm_ops fimd_pm_ops = {
 struct platform_driver fimd_driver = {
.probe  = fimd_probe,
.remove = __devexit_p(fimd_remove),
+   .id_table   = fimd_driver_ids,
.driver = {
.name   = exynos4-fb,
.owner  = THIS_MODULE,
-- 
1.7.0.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/2] video: drm: exynos: Add device tree support

[Leela Krishna Amudala]

Add device tree based discovery support for DRM-FIMD driver.

Signed-off-by: Leela Krishna Amudala l.kris...@samsung.com
---
 Documentation/devicetree/bindings/fb/drm-fimd.txt |   80 +
 drivers/gpu/drm/exynos/exynos_drm_fimd.c  |   95 -
 2 files changed, 173 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/fb/drm-fimd.txt

diff --git a/Documentation/devicetree/bindings/fb/drm-fimd.txt 
b/Documentation/devicetree/bindings/fb/drm-fimd.txt
new file mode 100644
index 000..bf94cd6
--- /dev/null
+++ b/Documentation/devicetree/bindings/fb/drm-fimd.txt
@@ -0,0 +1,80 @@
+* Samsung Display Controller using DRM frame work
+
+The display controller is used to transfer image data from memory to an
+external LCD driver interface. It supports various color formats such as
+rgb and yuv.
+
+Required properties:
+ - compatible: Should be samsung,exynos5-fimd or samsung,exynos4-fimd for 
+   fimd using DRM frame work.
+ - reg: physical base address of the controller and length of memory
+   mapped region.
+ - interrupts: Three interrupts should be specified. The interrupts should be
+   specified in the following order.
+   - VSYNC interrupt
+   - FIFO level interrupt
+   - FIMD System Interrupt
+
+ - samsung,fimd-display: This property should specify the phandle of the
+   display device node which holds the video interface timing with the
+   below mentioned properties.
+
+   - lcd-htiming: Specifies the horizontal timing for the overlay. The
+ horizontal timing includes four parameters in the following order.
+
+ - horizontal back porch (in number of lcd clocks)
+ - horizontal front porch (in number of lcd clocks)
+ - hsync pulse width (in number of lcd clocks)
+ - Display panels X resolution.
+
+   - lcd-vtiming: Specifies the vertical timing for the overlay. The
+ vertical timing includes four parameters in the following order.
+
+ - vertical back porch (in number of lcd lines)
+ - vertical front porch (in number of lcd lines)
+ - vsync pulse width (in number of lcd clocks)
+ - Display panels Y resolution.
+
+
+ - samsung,default-window: Specifies the default window number of the fimd 
controller.
+
+ - samsung,fimd-win-bpp: Specifies the bits per pixel.
+
+Optional properties:
+ - samsung,fimd-vidout-rgb: Video output format is RGB.
+ - samsung,fimd-inv-vclk: invert video clock polarity.
+ - samsung,fimd-frame-rate: Number of video frames per second.
+
+Example:
+
+   The following is an example for the fimd controller is split into
+   two portions. The SoC specific portion can be specified in the SoC
+   specific dts file. The board specific portion can be specified in the
+   board specific dts file.
+
+   - SoC Specific portion
+
+   fimd {
+   compatible = samsung,exynos5-fimd;
+   interrupt-parent = combiner;
+   reg = 0x1440 0x4;
+   interrupts = 18 5, 18 4, 18 6;
+   };
+
+   - Board Specific portion
+
+   lcd_fimd0: lcd_panel0 {
+   lcd-htiming = 4 4 4 480;
+   lcd-vtiming = 4 4 4 320;
+   supports-mipi-panel;
+   };
+
+   fimd {
+   samsung,fimd-display = lcd_fimd0;
+   samsung,fimd-vidout-rgb;
+   samsung,fimd-inv-vclk;
+   samsung,fimd-frame-rate = 60;
+   samsung,default-window = 0;
+   samsung,fimd-win-bpp = 32;
+   };
+
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 65e927b..cd1b841 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -18,6 +18,7 @@
 #include linux/platform_device.h
 #include linux/clk.h
 #include linux/pm_runtime.h
+#include linux/of.h
 
 #include video/samsung_fimd.h
 #include drm/exynos_drm.h
@@ -103,9 +104,18 @@ struct fimd_context {
struct exynos_drm_panel_info *panel;
 };
 
+static const struct of_device_id fimd_dt_match[];
+
 static inline struct fimd_driver_data *drm_fimd_get_driver_data(
struct platform_device *pdev)
 {
+#ifdef CONFIG_OF
+   if (pdev-dev.of_node) {
+   const struct of_device_id *match;
+   match = of_match_ptr(fimd_dt_match);
+   return (struct fimd_driver_data *)match-data;
+   }
+#endif
return (struct fimd_driver_data *)
platform_get_device_id(pdev)-driver_data;
 }
@@ -809,12 +819,77 @@ static int fimd_power_on(struct fimd_context *ctx, bool 
enable)
return 0;
 }
 
+#ifdef CONFIG_OF
+static struct exynos_drm_fimd_pdata *drm_fimd_dt_parse_pdata(struct device 
*dev)
+{
+   struct device_node *np = dev-of_node;
+   struct device_node *disp_np;
+   struct exynos_drm_fimd_pdata *pd;
+   u32 data[4];
+
+   pd = devm_kzalloc(dev, sizeof(*pd), GFP_KERNEL);
+   if (!pd) {
+   

RE: [PATCH 0/2] ARM: EXYNOS: Set the capability of pdm0 and pdm1 as DMA_PRIVATE

[Kukjin Kim]

Vinod Koul wrote:
 
 On Wed, 2012-08-29 at 10:16 +0530, Tushar Behera wrote:
  DMA clients pdma0 and pdma1 are internal to the SoC and are used only
  by dedicated peripherals. Since they cannot be used for generic
  purpose, their capability should be set as DMA_PRIVATE.
 
  The patches are rebased on top of v3.6-rc3.
 Kukjin, if you ack them I can take thru my tree, other way round is fine
 with me too.

Hi Vinod,

Looks good to me, please pick them into your tree with my ack.

Acked-by: Kukjin Kim kgene@samsung.com

If any problems, please kindly let me know.

Thanks.

Best regards,
Kgene.
--
Kukjin Kim kgene@samsung.com, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.

 
  Tushar Behera (2):
ARM: EXYNOS: Set the capability of pdm0 and pdm1 as DMA_PRIVATE
DMA: PL330: Set the capability of pdm0 and pdm1 as DMA_PRIVATE
 
   arch/arm/mach-exynos/dma.c |2 ++
   drivers/dma/pl330.c|1 +
   2 files changed, 3 insertions(+), 0 deletions(-)
 
 
 --
 ~Vinod Koul
 Intel Corp.

--
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] gpio: samsung: add devicetree init for s3c24xx arches

[Kukjin Kim]

Heiko Stübner wrote:
 
 Until now the Exynos-SoC was the only Samsung-SoC supporting the GPIOs
 via the device tree. This patch implements dt-support for the
 s3c24xx arches.
 
 The controllers contain only 3 cells, as the underlying gpio controller
 does not support controlling the drive strength on a gpio level.
 
 Tested with the gpio-keys driver on a s3c2416 based machine.
 
 Signed-off-by: Heiko Stuebner he...@sntech.de
 Reviewed-by: Thomas Abraham thomas.abra...@linaro.org
 ---

[...]

 +#if defined(CONFIG_PLAT_S3C24XX)  defined(CONFIG_OF)

[...]

 +static __init void s3c24xx_gpiolib_attach_ofnode(struct samsung_gpio_chip
 *chip,
 +  u64 base, u64 offset)
 +{

[...]

 +}
 +#elif defined(CONFIG_PLAT_S3C24XX)

Heiko, above line breaks building for other samsung stuff except s3c24xx. I 
fixed with following which has been amended in your patch. If any problems, 
please let me know.

Thanks.

Best regards,
Kgene.
--
Kukjin Kim kgene@samsung.com, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.

diff --git a/drivers/gpio/gpio-samsung.c b/drivers/gpio/gpio-samsung.c
index 5dcdcda..a006f0d 100644
--- a/drivers/gpio/gpio-samsung.c
+++ b/drivers/gpio/gpio-samsung.c
@@ -991,7 +991,7 @@ static __init void s3c24xx_gpiolib_attach_ofnode(struct 
samsun
gc-of_gpio_n_cells = 3;
gc-of_xlate = s3c24xx_gpio_xlate;
 }
-#elif defined(CONFIG_PLAT_S3C24XX)
+#else
 static __init void s3c24xx_gpiolib_attach_ofnode(struct samsung_gpio_chip 
*chip,
u64 base, u64 offset)
 {

 +static __init void s3c24xx_gpiolib_attach_ofnode(struct samsung_gpio_chip
 *chip,
 +  u64 base, u64 offset)
 +{
 + return;
 +}
 +#endif /* defined(CONFIG_PLAT_S3C24XX)  defined(CONFIG_OF) */
 +
  static void __init s3c24xx_gpiolib_add_chips(struct samsung_gpio_chip
 *chip,
int nr_chips, void __iomem *base)
  {
 @@ -962,6 +1023,8 @@ static void __init s3c24xx_gpiolib_add_chips(struct
 samsung_gpio_chip *chip,
   gc-direction_output = samsung_gpiolib_2bit_output;
 
   samsung_gpiolib_add(chip);
 +
 + s3c24xx_gpiolib_attach_ofnode(chip, S3C24XX_PA_GPIO, i *
 0x10);
   }
  }
 
 --
 1.7.2.3

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

RE: [PATCH v4 0/2] Add device tree and clock support for G-Scaler

[Kukjin Kim]

Shaik Ameer Basha wrote:
  BTW, just wondering...the sign-chain is right? Hoping you know, if sign-
 off
  has been added without their handling on the patches, it's wrong.
 
 
 This sign-chain is fine. Please apply this series to your tree.
 
OK, applied.

Thanks.

Best regards,
Kgene.
--
Kukjin Kim kgene@samsung.com, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.

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