Re: [PATCH V4 2/2] video: drm: exynos: Add device tree support
Hi, 2012/9/5 Kyungmin Park : > Hi, > > On Thu, Sep 6, 2012 at 12:39 AM, Leela Krishna Amudala > wrote: >> Add device tree based discovery support for DRM-FIMD driver. >> >> Signed-off-by: Leela Krishna Amudala >> --- >> 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()
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
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
Add optional support for i2c bus pin configuration using pinctrl interface
Cc: Ben Dooks
Signed-off-by: Thomas Abraham
---
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
#include
#include
+#include
#include
@@ -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
Add a default pin state for i2c0 controller which the pinctrl interface can
use to setup the i2c0 bus.
Signed-off-by: Thomas Abraham
---
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
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 R&D 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
> Signed-off-by: Thomas Abraham
> ---
> 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
> #include
> #include
> +#include
>
> #include
>
> @@ -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
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
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
Signed-off-by: Kyungmin Park
---
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
This patch adds initialization of name field in generic power domain struct. Signed-off-by: Tomasz Figa Signed-off-by: Kyungmin Park --- 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
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
Signed-off-by: Kyungmin Park
---
.../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
#include
#include
+#include
+#include
#include
#include
@@ -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 + 0x4) & S5P_INT_LOCAL_PWR_EN;
pm_genpd_init(&pd->pd, NULL, !on);
}
+
+ bus_register_notifi
Re: [PATCH 2/2] ARM: dts: exynos4: allow i2c0 bus to be configured using pinctrl interface
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 R&D 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
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
On 6 September 2012 15:04, Tomasz Figa 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 R&D 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
>> Signed-off-by: Thomas Abraham
>> ---
>> 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
>> #include
>> #include
>> +#include
>>
>> #include
>>
>> @@ -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
On 6 September 2012 15:43, Tomasz Figa 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 R&D 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
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 R&D 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
The clocks for PCM, Slimbus, Spdif added to off list in order
to turn them off at boot time.
Signed-off-by: Chander Kashyap
---
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
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
---
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
chained_irq_enter/exit() already mask&ack/unmask the chained interrupt. There is no need to also explicitly do it in the handler. Signed-off-by: Daniel Kurtz --- 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] ARM: EXYNOS: no duplicate mask/unmask in eint0_15
On Thu, Sep 6, 2012 at 8:21 AM, Daniel Kurtz wrote: > chained_irq_enter/exit() already mask&ack/unmask the chained interrupt. > There is no need to also explicitly do it in the handler. > > Signed-off-by: Daniel Kurtz > --- > 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 > Acked-by: Doug Anderson -- 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
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 > Cc: Kukjin Kim > Signed-off-by: Thomas Abraham Acked-by: Stephen Warren -- 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 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 > > Cc: Kukjin Kim > > Signed-off-by: Thomas Abraham > > Acked-by: Stephen Warren Applied this whole series, thanks. Best regards, Kgene. -- Kukjin Kim , 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
Sachin Kamat wrote:
>
> module_platform_driver simplifies the code by eliminating
> module_init and module_exit calls.
>
> Signed-off-by: Sachin Kamat
> ---
> 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 ");
> MODULE_DESCRIPTION("Driver for the iPAQ H1940 bluetooth chip");
> --
> 1.7.4.1
Applied, thanks.
Thanks.
Best regards,
Kgene.
--
Kukjin Kim , 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
Sachin Kamat wrote:
>
> module_platform_driver simplifies the code by eliminating
> module_init and module_exit calls.
>
> Signed-off-by: Sachin Kamat
> ---
> 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 ");
> --
> 1.7.4.1
Applied, thanks.
Best regards,
Kgene.
--
Kukjin Kim , 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
Linus Walleij wrote: > > On Wed, Aug 29, 2012 at 1:09 AM, Kukjin Kim 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 Stuebner > >> Reviewed-by: Thomas Abraham > > > > > > Yeah, looks good to me... > > > > Acked-by: Kukjin Kim > > 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 , 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
Hi, On Thu, Sep 6, 2012 at 4:35 PM, Sylwester Nawrocki 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
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
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
---
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
Add device tree based discovery support for DRM-FIMD driver.
Signed-off-by: Leela Krishna Amudala
---
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
#include
#include
+#include
#include
#include
@@ -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) {
+ dev_err(dev, "memory allocation for pdata failed\n");
+ return ERR_PTR(-ENOMEM);
RE: [PATCH 0/2] ARM: EXYNOS: Set the capability of pdm0 and pdm1 as DMA_PRIVATE
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 If any problems, please kindly let me know. Thanks. Best regards, Kgene. -- Kukjin Kim , 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
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
> Reviewed-by: Thomas Abraham
> ---
[...]
> +#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 , 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
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 , 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
Hi 2012/9/7 Leela Krishna Amudala : > Hi, > > On Thu, Sep 6, 2012 at 4:35 PM, Sylwester Nawrocki > 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. > I'm not sure that clk_get is worked well with this change. I think, when driver called clk_get(), first of all, it tries to get a clk from the registered list of clock providers in the dts file and next in legacy way. but now legacy way(needing clock name and device' name) would be failed if the dts file has no the list because platform device's name differs from device name of clock. so I think we should change device name of clock and also ids of related drivers for compatibility with non-dt. for this, we need some patch sets, changing arch/arm/mach-exynos/common.c and changing arch/arm/mach-exynos/clock-exynos4/5.c and changing s3c-fb.c and last this patch. if there are no other opinions, I'd like to merge this patch set(v5) and next we can update others(maybe common.c, clock-exynos4/5.c and s3c-fb.c) later. Thanks. Inki Dae >> >>> 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 > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel -- 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: SAMSUNG: Use spin_lock_{irqsave,irqrestore} in clk_set_rate
The spinlock clocks_lock can be held during ISR, hence it is not safe to
hold that lock with disabling interrupts.
It fixes following potential deadlock.
=
[ INFO: possible irq lock inversion dependency detected ]
3.6.0-rc4+ #2 Not tainted
-
swapper/0/1 just changed the state of lock:
(&(&host->lock)->rlock){-.}, at: [] sdhci_irq+0x15/0x564
but this lock took another, HARDIRQ-unsafe lock in the past:
(clocks_lock){+.+...}
and interrupts could create inverse lock ordering between them.
other info that might help us debug this:
Possible interrupt unsafe locking scenario:
CPU0CPU1
lock(clocks_lock);
local_irq_disable();
lock(&(&host->lock)->rlock);
lock(clocks_lock);
lock(&(&host->lock)->rlock);
*** DEADLOCK ***
Signed-off-by: Tushar Behera
---
arch/arm/plat-samsung/clock.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/arm/plat-samsung/clock.c b/arch/arm/plat-samsung/clock.c
index 65c5eca..9b71719 100644
--- a/arch/arm/plat-samsung/clock.c
+++ b/arch/arm/plat-samsung/clock.c
@@ -144,6 +144,7 @@ long clk_round_rate(struct clk *clk, unsigned long rate)
int clk_set_rate(struct clk *clk, unsigned long rate)
{
+ unsigned long flags;
int ret;
if (IS_ERR(clk))
@@ -159,9 +160,9 @@ int clk_set_rate(struct clk *clk, unsigned long rate)
if (clk->ops == NULL || clk->ops->set_rate == NULL)
return -EINVAL;
- spin_lock(&clocks_lock);
+ spin_lock_irqsave(&clocks_lock, flags);
ret = (clk->ops->set_rate)(clk, rate);
- spin_unlock(&clocks_lock);
+ spin_unlock_irqrestore(&clocks_lock, flags);
return ret;
}
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] ARM: SAMSUNG: Fix HDMI related warnings
Sachin Kamat wrote: > > Silences the following warnings: > arch/arm/plat-samsung/devs.c:765:31: warning: > symbol 's5p_hdmi_def_platdata' was not declared. Should it be static? > arch/arm/plat-samsung/devs.c:767:13: warning: > symbol 's5p_hdmi_set_platdata' was not declared. Should it be static? > > Signed-off-by: Sachin Kamat > --- > arch/arm/plat-samsung/devs.c |3 ++- > 1 files changed, 2 insertions(+), 1 deletions(-) > > diff --git a/arch/arm/plat-samsung/devs.c b/arch/arm/plat-samsung/devs.c > index 6ff45d5..565cea7 100644 > --- a/arch/arm/plat-samsung/devs.c > +++ b/arch/arm/plat-samsung/devs.c > @@ -51,6 +51,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -762,7 +763,7 @@ void __init s5p_i2c_hdmiphy_set_platdata(struct > s3c2410_platform_i2c *pd) > &s5p_device_i2c_hdmiphy); > } > > -struct s5p_hdmi_platform_data s5p_hdmi_def_platdata; > +static struct s5p_hdmi_platform_data s5p_hdmi_def_platdata; > > void __init s5p_hdmi_set_platdata(struct i2c_board_info *hdmiphy_info, > struct i2c_board_info *mhl_info, int mhl_bus) > -- > 1.7.4.1 Applied, thanks. Best regards, Kgene. -- Kukjin Kim , 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 v5 4/9] mmc: dw_mmc: lookup for optional biu and ciu clocks
Hi Jaehoon,
Thanks for reviewing the patch.
On 5 September 2012 14:00, Jaehoon Chung wrote:
> On 09/05/2012 04:46 AM, Thomas Abraham wrote:
>> Some platforms allow for clock gating and control of bus interface unit clock
>> and card interface unit clock. Add support for clock lookup of optional biu
>> and ciu clocks for clock gating and clock speed determination.
>>
>> Signed-off-by: Abhilash Kesavan
>> Signed-off-by: Thomas Abraham
>> Acked-by: Will Newton
>> ---
>> drivers/mmc/host/dw_mmc.c | 50
>> +--
>> include/linux/mmc/dw_mmc.h |4 +++
>> 2 files changed, 51 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
>> index 227c42e..e8c8491 100644
>> --- a/drivers/mmc/host/dw_mmc.c
>> +++ b/drivers/mmc/host/dw_mmc.c
>> @@ -1960,13 +1960,40 @@ int dw_mci_probe(struct dw_mci *host)
>> return -ENODEV;
>> }
>>
>> - if (!host->pdata->bus_hz) {
>> + host->biu_clk = clk_get(host->dev, "biu");
>> + if (IS_ERR(host->biu_clk)) {
>> + dev_dbg(host->dev, "biu clock not available\n");
>> + } else {
>> + ret = clk_prepare_enable(host->biu_clk);
>> + if (ret) {
>> + dev_err(host->dev, "failed to enable biu clock\n");
>> + return ret;
> didn't clk_put() for biu_clk?
Yes, I missed that. Thanks for pointing this out. I will fix this.
>> + }
>> + }
>> +
>> + host->ciu_clk = clk_get(host->dev, "ciu");
>> + if (IS_ERR(host->ciu_clk)) {
>> + dev_dbg(host->dev, "ciu clock not available\n");
>> + } else {
>> + ret = clk_prepare_enable(host->ciu_clk);
>> + if (ret) {
>> + dev_err(host->dev, "failed to enable ciu clock\n");
>> + goto err_clk_biu;
>> + }
>> + }
>> +
>> + if (IS_ERR(host->ciu_clk))
>> + host->bus_hz = host->pdata->bus_hz;
>> + else
>> + host->bus_hz = clk_get_rate(host->ciu_clk);
>> +
>> + if (!host->bus_hz) {
>> dev_err(host->dev,
>> "Platform data must supply bus speed\n");
>> - return -ENODEV;
>> + ret = -ENODEV;
>> + goto err_clk_ciu;
>> }
>>
>> - host->bus_hz = host->pdata->bus_hz;
>> host->quirks = host->pdata->quirks;
>>
>> spin_lock_init(&host->lock);
>> @@ -2116,6 +2143,17 @@ err_dmaunmap:
>> regulator_disable(host->vmmc);
>> regulator_put(host->vmmc);
>> }
>> +
>> +err_clk_ciu:
>> + if (!IS_ERR(host->ciu_clk)) {
>> + clk_disable_unprepare(host->ciu_clk);
>> + clk_put(host->ciu_clk);
>> + }
>> +err_clk_biu:
> I think right that is located the clk_put(host->ciu_clk) at here
In the next version of this patch, if clk_prepare_enable() fails for
host->ciu_clk, the put(host->ciu_clk) is also done before returning.
Thanks,
Thomas.
>> + if (!IS_ERR(host->biu_clk)) {
>> + clk_disable_unprepare(host->biu_clk);
>> + clk_put(host->biu_clk);
>> + }
>> return ret;
>> }
>> EXPORT_SYMBOL(dw_mci_probe);
>> @@ -2149,6 +2187,12 @@ void dw_mci_remove(struct dw_mci *host)
>> regulator_put(host->vmmc);
>> }
>>
>> + if (!IS_ERR(host->ciu_clk))
>> + clk_disable_unprepare(host->ciu_clk);
>> + if (!IS_ERR(host->biu_clk))
>> + clk_disable_unprepare(host->biu_clk);
>> + clk_put(host->ciu_clk);
>> + clk_put(host->biu_clk);
>> }
>> EXPORT_SYMBOL(dw_mci_remove);
>>
>> diff --git a/include/linux/mmc/dw_mmc.h b/include/linux/mmc/dw_mmc.h
>> index a37a573..787ad56 100644
>> --- a/include/linux/mmc/dw_mmc.h
>> +++ b/include/linux/mmc/dw_mmc.h
>> @@ -78,6 +78,8 @@ struct mmc_data;
>> * @data_offset: Set the offset of DATA register according to VERID.
>> * @dev: Device associated with the MMC controller.
>> * @pdata: Platform data associated with the MMC controller.
>> + * @biu_clk: Pointer to bus interface unit clock instance.
>> + * @ciu_clk: Pointer to card interface unit clock instance.
>> * @slot: Slots sharing this MMC controller.
>> * @fifo_depth: depth of FIFO.
>> * @data_shift: log2 of FIFO item size.
>> @@ -158,6 +160,8 @@ struct dw_mci {
>> u16 data_offset;
>> struct device *dev;
>> struct dw_mci_board *pdata;
>> + struct clk *biu_clk;
>> + struct clk *ciu_clk;
>> struct dw_mci_slot *slot[MAX_MCI_SLOTS];
>>
>> /* FIFO push and pull */
>>
>
--
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] DMA: PL330: Clock and runtime cleanup
The controller clock is being managed at AMBA bus level probe/remove and pm_runtime/suspend functions. The existing driver does the clock enable/disable again in the same code paths, which unneccessarily increments the usage count of the clock for the same device. The following patches remove the redundant clock enable/disable from the driver. Inderpal Singh (2): DMA: PL330: Remove controller clock enable/disable DMA: PL330: Remove redundant runtime_suspend/resume functions drivers/dma/pl330.c | 73 --- 1 file changed, 5 insertions(+), 68 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] DMA: PL330: Remove controller clock enable/disable
The controller clock is being enabled/disabled in AMBA bus infrastructre in probe/remove functions. Hence, its not required at driver level probe/remove. Signed-off-by: Inderpal Singh --- drivers/dma/pl330.c | 12 1 file changed, 12 deletions(-) diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c index e4feba6..f70e783 100644 --- a/drivers/dma/pl330.c +++ b/drivers/dma/pl330.c @@ -2896,11 +2896,6 @@ pl330_probe(struct amba_device *adev, const struct amba_id *id) amba_set_drvdata(adev, pdmac); -#ifndef CONFIG_PM_RUNTIME - /* enable dma clk */ - clk_enable(pdmac->clk); -#endif - irq = adev->irq[0]; ret = request_irq(irq, pl330_irq_handler, 0, dev_name(&adev->dev), pi); @@ -2987,9 +2982,6 @@ probe_err5: probe_err4: free_irq(irq, pi); probe_err3: -#ifndef CONFIG_PM_RUNTIME - clk_disable(pdmac->clk); -#endif clk_put(pdmac->clk); probe_err2: iounmap(pi->base); @@ -3037,10 +3029,6 @@ static int __devexit pl330_remove(struct amba_device *adev) res = &adev->res; release_mem_region(res->start, resource_size(res)); -#ifndef CONFIG_PM_RUNTIME - clk_disable(pdmac->clk); -#endif - kfree(pdmac); return 0; -- 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] DMA: PL330: Remove redundant runtime_suspend/resume functions
The driver's runtime_suspend/resume functions just disable/enable
the clock which is already being managed at AMBA bus level
runtime_suspend/resume functions.
Hence, remove the driver's runtime_suspend/resume functions.
Signed-off-by: Inderpal Singh
---
drivers/dma/pl330.c | 61 +--
1 file changed, 5 insertions(+), 56 deletions(-)
diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
index f70e783..d9e1433 100644
--- a/drivers/dma/pl330.c
+++ b/drivers/dma/pl330.c
@@ -23,7 +23,6 @@
#include
#include
#include
-#include
#include
#include
@@ -586,8 +585,6 @@ struct dma_pl330_dmac {
/* Peripheral channels connected to this DMAC */
struct dma_pl330_chan *peripherals; /* keep at end */
-
- struct clk *clk;
};
struct dma_pl330_desc {
@@ -2887,24 +2884,17 @@ pl330_probe(struct amba_device *adev, const struct
amba_id *id)
goto probe_err1;
}
- pdmac->clk = clk_get(&adev->dev, "dma");
- if (IS_ERR(pdmac->clk)) {
- dev_err(&adev->dev, "Cannot get operation clock.\n");
- ret = -EINVAL;
- goto probe_err2;
- }
-
amba_set_drvdata(adev, pdmac);
irq = adev->irq[0];
ret = request_irq(irq, pl330_irq_handler, 0,
dev_name(&adev->dev), pi);
if (ret)
- goto probe_err3;
+ goto probe_err2;
ret = pl330_add(pi);
if (ret)
- goto probe_err4;
+ goto probe_err3;
INIT_LIST_HEAD(&pdmac->desc_pool);
spin_lock_init(&pdmac->pool_lock);
@@ -2964,7 +2954,7 @@ pl330_probe(struct amba_device *adev, const struct
amba_id *id)
ret = dma_async_device_register(pd);
if (ret) {
dev_err(&adev->dev, "unable to register DMAC\n");
- goto probe_err5;
+ goto probe_err4;
}
dev_info(&adev->dev,
@@ -2977,12 +2967,10 @@ pl330_probe(struct amba_device *adev, const struct
amba_id *id)
return 0;
-probe_err5:
- pl330_del(pi);
probe_err4:
- free_irq(irq, pi);
+ pl330_del(pi);
probe_err3:
- clk_put(pdmac->clk);
+ free_irq(irq, pi);
probe_err2:
iounmap(pi->base);
probe_err1:
@@ -3044,49 +3032,10 @@ static struct amba_id pl330_ids[] = {
MODULE_DEVICE_TABLE(amba, pl330_ids);
-#ifdef CONFIG_PM_RUNTIME
-static int pl330_runtime_suspend(struct device *dev)
-{
- struct dma_pl330_dmac *pdmac = dev_get_drvdata(dev);
-
- if (!pdmac) {
- dev_err(dev, "failed to get dmac\n");
- return -ENODEV;
- }
-
- clk_disable(pdmac->clk);
-
- return 0;
-}
-
-static int pl330_runtime_resume(struct device *dev)
-{
- struct dma_pl330_dmac *pdmac = dev_get_drvdata(dev);
-
- if (!pdmac) {
- dev_err(dev, "failed to get dmac\n");
- return -ENODEV;
- }
-
- clk_enable(pdmac->clk);
-
- return 0;
-}
-#else
-#define pl330_runtime_suspend NULL
-#define pl330_runtime_resume NULL
-#endif /* CONFIG_PM_RUNTIME */
-
-static const struct dev_pm_ops pl330_pm_ops = {
- .runtime_suspend = pl330_runtime_suspend,
- .runtime_resume = pl330_runtime_resume,
-};
-
static struct amba_driver pl330_driver = {
.drv = {
.owner = THIS_MODULE,
.name = "dma-pl330",
- .pm = &pl330_pm_ops,
},
.id_table = pl330_ids,
.probe = pl330_probe,
--
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
