Re: [PATCHv2 1/2] iio: adc: exynos_adc: Control special clock of ADC to support Exynos3250 ADC
On April 16, 2014 2:13:39 AM GMT+01:00, Chanwoo Choi cw00.c...@samsung.com
wrote:
Hi Jonathan,
Any comment of this patchset?
Best Regards,
Chanwoo Choi
Hi Chanwoo
Not got to it yet I'm afraid. May be sometime next week before I do.
Jonathan
On 04/14/2014 06:07 PM, Chanwoo Choi wrote:
This patch control special clock for ADC in Exynos series's FSYS
block.
If special clock of ADC is registerd on clock list of common clk
framework,
Exynos ADC drvier have to control this clock.
Exynos3250/Exynos4/Exynos5 has 'adc' clock as following:
- 'adc' clock: bus clock for ADC
Exynos3250 has additional 'sclk_tsadc' clock as following:
- 'sclk_tsadc' clock: special clock for ADC which provide clock to
internal ADC
Exynos 4210/4212/4412 and Exynos5250/5420 has not included
'sclk_tsadc' clock
in FSYS_BLK. But, Exynos3250 based on Cortex-A7 has only included
'sclk_tsadc'
clock in FSYS_BLK.
Cc: Jonathan Cameron ji...@kernel.org
Cc: Kukjin Kim kgene@samsung.com
Cc: Naveen Krishna Chatradhi
Cc: linux-...@vger.kernel.org
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/iio/adc/exynos_adc.c | 54
+---
1 file changed, 41 insertions(+), 13 deletions(-)
diff --git a/drivers/iio/adc/exynos_adc.c
b/drivers/iio/adc/exynos_adc.c
index d25b262..3c99243 100644
--- a/drivers/iio/adc/exynos_adc.c
+++ b/drivers/iio/adc/exynos_adc.c
@@ -40,8 +40,9 @@
#include linux/iio/driver.h
enum adc_version {
-ADC_V1,
-ADC_V2
+ADC_V1 = 0x1,
+ADC_V2 = 0x2,
+ADC_V3 = (ADC_V1 | ADC_V2),
};
/* EXYNOS4412/5250 ADC_V1 registers definitions */
@@ -88,6 +89,7 @@ struct exynos_adc {
void __iomem*regs;
void __iomem*enable_reg;
struct clk *clk;
+struct clk *sclk;
unsigned intirq;
struct regulator*vdd;
@@ -100,6 +102,7 @@ struct exynos_adc {
static const struct of_device_id exynos_adc_match[] = {
{ .compatible = samsung,exynos-adc-v1, .data = (void *)ADC_V1 },
{ .compatible = samsung,exynos-adc-v2, .data = (void *)ADC_V2 },
+{ .compatible = samsung,exynos-adc-v3, .data = (void *)ADC_V3 },
{},
};
MODULE_DEVICE_TABLE(of, exynos_adc_match);
@@ -128,7 +131,7 @@ static int exynos_read_raw(struct iio_dev
*indio_dev,
mutex_lock(indio_dev-mlock);
/* Select the channel to be used and Trigger conversion */
-if (info-version == ADC_V2) {
+if (info-version ADC_V2) {
con2 = readl(ADC_V2_CON2(info-regs));
con2 = ~ADC_V2_CON2_ACH_MASK;
con2 |= ADC_V2_CON2_ACH_SEL(chan-address);
@@ -165,7 +168,7 @@ static irqreturn_t exynos_adc_isr(int irq, void
*dev_id)
info-value = readl(ADC_V1_DATX(info-regs))
ADC_DATX_MASK;
/* clear irq */
-if (info-version == ADC_V2)
+if (info-version ADC_V2)
writel(1, ADC_V2_INT_ST(info-regs));
else
writel(1, ADC_V1_INTCLR(info-regs));
@@ -226,11 +229,25 @@ static int exynos_adc_remove_devices(struct
device *dev, void *c)
return 0;
}
+static void exynos_adc_enable_clock(struct exynos_adc *info, bool
enable)
+{
+if (enable) {
+clk_prepare_enable(info-clk);
+if (info-version == ADC_V3)
+clk_prepare_enable(info-sclk);
+
+} else {
+if (info-version == ADC_V3)
+clk_disable_unprepare(info-sclk);
+clk_disable_unprepare(info-clk);
+}
+}
+
static void exynos_adc_hw_init(struct exynos_adc *info)
{
u32 con1, con2;
-if (info-version == ADC_V2) {
+if (info-version ADC_V2) {
con1 = ADC_V2_CON1_SOFT_RESET;
writel(con1, ADC_V2_CON1(info-regs));
@@ -300,6 +317,8 @@ static int exynos_adc_probe(struct
platform_device *pdev)
writel(1, info-enable_reg);
+info-version = exynos_adc_get_version(pdev);
+
info-clk = devm_clk_get(pdev-dev, adc);
if (IS_ERR(info-clk)) {
dev_err(pdev-dev, failed getting clock, err = %ld\n,
@@ -308,6 +327,17 @@ static int exynos_adc_probe(struct
platform_device *pdev)
goto err_irq;
}
+if (info-version == ADC_V3) {
+info-sclk = devm_clk_get(pdev-dev, sclk_tsadc);
+if (IS_ERR(info-sclk)) {
+dev_warn(pdev-dev,
+failed getting sclk clock, err = %ld\n,
+PTR_ERR(info-sclk));
+ret = PTR_ERR(info-sclk);
+goto err_irq;
+}
+}
+
info-vdd = devm_regulator_get(pdev-dev, vdd);
if (IS_ERR(info-vdd)) {
dev_err(pdev-dev, failed getting regulator, err = %ld\n,
@@ -316,8 +346,6 @@ static int exynos_adc_probe(struct
platform_device *pdev)
Re: [PATCH v8 1/3] ARM: EXYNOS: initial board support for exynos5260 SoC
Hi Rahul, On 16.04.2014 05:58, Rahul Sharma wrote: From: Pankaj Dubey pankaj.du...@samsung.com This patch add basic arch side support for exynos5260 SoC. Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com Signed-off-by: Rahul Sharma rahul.sha...@samsung.com Reviewed-by: Tomasz Figa t.f...@samsung.com --- arch/arm/mach-exynos/Kconfig |5 + 1 file changed, 5 insertions(+) diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig index fc8bf18..bf4ed87 100644 --- a/arch/arm/mach-exynos/Kconfig +++ b/arch/arm/mach-exynos/Kconfig @@ -84,6 +84,11 @@ config SOC_EXYNOS5250 help Enable EXYNOS5250 SoC support +config SOC_EXYNOS5260 + bool SAMSUNG EXYNOS5260 + default y + depends on ARCH_EXYNOS5 + config SOC_EXYNOS5420 bool SAMSUNG EXYNOS5420 default y Is this patch necessary now? After Sachin's consolidation series there are no per SoC entries anymore. Best regards, Tomasz -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 1/2] iio: adc: exynos_adc: Control special clock of ADC to support Exynos3250 ADC
On April 16, 2014 5:55:17 AM GMT+01:00, Chanwoo Choi cw00.c...@samsung.com
wrote:
Hi Sachin,
On 04/16/2014 01:44 PM, Chanwoo Choi wrote:
Hi Sachin,
On 04/16/2014 12:48 PM, Sachin Kamat wrote:
Hi Chanwoo,
On 14 April 2014 14:37, Chanwoo Choi cw00.c...@samsung.com wrote:
This patch control special clock for ADC in Exynos series's FSYS
block.
If special clock of ADC is registerd on clock list of common clk
framework,
Exynos ADC drvier have to control this clock.
Exynos3250/Exynos4/Exynos5 has 'adc' clock as following:
- 'adc' clock: bus clock for ADC
Exynos3250 has additional 'sclk_tsadc' clock as following:
- 'sclk_tsadc' clock: special clock for ADC which provide clock to
internal ADC
Exynos 4210/4212/4412 and Exynos5250/5420 has not included
'sclk_tsadc' clock
in FSYS_BLK. But, Exynos3250 based on Cortex-A7 has only included
'sclk_tsadc'
clock in FSYS_BLK.
Cc: Jonathan Cameron ji...@kernel.org
Cc: Kukjin Kim kgene@samsung.com
Cc: Naveen Krishna Chatradhi
Cc: linux-...@vger.kernel.org
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/iio/adc/exynos_adc.c | 54
+---
1 file changed, 41 insertions(+), 13 deletions(-)
diff --git a/drivers/iio/adc/exynos_adc.c
b/drivers/iio/adc/exynos_adc.c
index d25b262..3c99243 100644
--- a/drivers/iio/adc/exynos_adc.c
+++ b/drivers/iio/adc/exynos_adc.c
@@ -40,8 +40,9 @@
#include linux/iio/driver.h
enum adc_version {
- ADC_V1,
- ADC_V2
+ ADC_V1 = 0x1,
+ ADC_V2 = 0x2,
+ ADC_V3 = (ADC_V1 | ADC_V2),
Can't this be simply 0x3? Or is this not really a h/w version?
Even thought ADC_V3 isn't h/w revision, ADC_V3 include all featues of
ADC_V2
and only one difference of clock(sclk_tsadc) from ADC_V2.
I want to describethat ADC_V3 include ADC_V2 feature So, I add as
following:
+ ADC_V3 = (ADC_V1 | ADC_V2),
};
/* EXYNOS4412/5250 ADC_V1 registers definitions */
@@ -88,6 +89,7 @@ struct exynos_adc {
void __iomem*regs;
void __iomem*enable_reg;
struct clk *clk;
+ struct clk *sclk;
unsigned intirq;
struct regulator*vdd;
@@ -100,6 +102,7 @@ struct exynos_adc {
static const struct of_device_id exynos_adc_match[] = {
{ .compatible = samsung,exynos-adc-v1, .data = (void
*)ADC_V1 },
{ .compatible = samsung,exynos-adc-v2, .data = (void
*)ADC_V2 },
+ { .compatible = samsung,exynos-adc-v3, .data = (void
*)ADC_V3 },
{},
};
MODULE_DEVICE_TABLE(of, exynos_adc_match);
@@ -128,7 +131,7 @@ static int exynos_read_raw(struct iio_dev
*indio_dev,
mutex_lock(indio_dev-mlock);
/* Select the channel to be used and Trigger conversion */
- if (info-version == ADC_V2) {
+ if (info-version ADC_V2) {
So, now this would be applicable for ADC_V3 too, right?
ADC_V3 isn't h/w version. So, I think this code is proper instead of
using ADC_V3 direclty.
I want to use ADC_V3 version on checking clock(sclk_tsadc).
con2 = readl(ADC_V2_CON2(info-regs));
con2 = ~ADC_V2_CON2_ACH_MASK;
con2 |= ADC_V2_CON2_ACH_SEL(chan-address);
@@ -165,7 +168,7 @@ static irqreturn_t exynos_adc_isr(int irq, void
*dev_id)
info-value = readl(ADC_V1_DATX(info-regs))
ADC_DATX_MASK;
/* clear irq */
- if (info-version == ADC_V2)
+ if (info-version ADC_V2)
writel(1, ADC_V2_INT_ST(info-regs));
else
writel(1, ADC_V1_INTCLR(info-regs));
@@ -226,11 +229,25 @@ static int exynos_adc_remove_devices(struct
device *dev, void *c)
return 0;
}
+static void exynos_adc_enable_clock(struct exynos_adc *info, bool
enable)
+{
+ if (enable) {
+ clk_prepare_enable(info-clk);
This could fail. Is it OK without any checks?
OK, I'll check return value.
Do you want to check return value always?
I think again, Some device drivers in mainline would not check
return value of clock function. If maintainer confirm this
modification,
I'll fix it as your comment.
Its general good practice to check all return values. Even if a function
doesn't return an
error now, it might in future. There is lots of old or lazy code out there
doing many much
stranger things than this!
So yes, please check return values and pass on up the call stack if an error.
Best Regards,
Chanwoo Choi
--
To unsubscribe from this list: send the line unsubscribe linux-iio in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to
Re: [PATCH v8 1/3] ARM: EXYNOS: initial board support for exynos5260 SoC
Hi Tomasz, On 16 April 2014 13:27, Tomasz Figa tomasz.f...@gmail.com wrote: Hi Rahul, On 16.04.2014 05:58, Rahul Sharma wrote: From: Pankaj Dubey pankaj.du...@samsung.com This patch add basic arch side support for exynos5260 SoC. Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com Signed-off-by: Rahul Sharma rahul.sha...@samsung.com Reviewed-by: Tomasz Figa t.f...@samsung.com --- arch/arm/mach-exynos/Kconfig |5 + 1 file changed, 5 insertions(+) diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig index fc8bf18..bf4ed87 100644 --- a/arch/arm/mach-exynos/Kconfig +++ b/arch/arm/mach-exynos/Kconfig @@ -84,6 +84,11 @@ config SOC_EXYNOS5250 help Enable EXYNOS5250 SoC support +config SOC_EXYNOS5260 + bool SAMSUNG EXYNOS5260 + default y + depends on ARCH_EXYNOS5 + config SOC_EXYNOS5420 bool SAMSUNG EXYNOS5420 default y Is this patch necessary now? After Sachin's consolidation series there are no per SoC entries anymore. Kukjin still wanted individual SoCs to be selectable. Please refer [1]. [1] http://www.spinics.net/lists/devicetree/msg27040.html -- With warm regards, Sachin -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8 1/3] ARM: EXYNOS: initial board support for exynos5260 SoC
On 16.04.2014 10:08, Sachin Kamat wrote: Hi Tomasz, On 16 April 2014 13:27, Tomasz Figa tomasz.f...@gmail.com wrote: Hi Rahul, On 16.04.2014 05:58, Rahul Sharma wrote: From: Pankaj Dubey pankaj.du...@samsung.com This patch add basic arch side support for exynos5260 SoC. Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com Signed-off-by: Rahul Sharma rahul.sha...@samsung.com Reviewed-by: Tomasz Figa t.f...@samsung.com --- arch/arm/mach-exynos/Kconfig |5 + 1 file changed, 5 insertions(+) diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig index fc8bf18..bf4ed87 100644 --- a/arch/arm/mach-exynos/Kconfig +++ b/arch/arm/mach-exynos/Kconfig @@ -84,6 +84,11 @@ config SOC_EXYNOS5250 help Enable EXYNOS5250 SoC support +config SOC_EXYNOS5260 + bool SAMSUNG EXYNOS5260 + default y + depends on ARCH_EXYNOS5 + config SOC_EXYNOS5420 bool SAMSUNG EXYNOS5420 default y Is this patch necessary now? After Sachin's consolidation series there are no per SoC entries anymore. Kukjin still wanted individual SoCs to be selectable. Please refer [1]. [1] http://www.spinics.net/lists/devicetree/msg27040.html I don't think any valid reason was presented there. Features in code should not be selected using #ifdef CONFIG_ anymore, so I don't really see any reason to not proceed with this consolidation. Olof, Arnd? Best regards, Tomasz -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 1/2] iio: adc: exynos_adc: Control special clock of ADC to support Exynos3250 ADC
Hi Jonathan,
On 04/16/2014 04:05 PM, Jonathan Cameron wrote:
On April 16, 2014 5:55:17 AM GMT+01:00, Chanwoo Choi cw00.c...@samsung.com
wrote:
Hi Sachin,
On 04/16/2014 01:44 PM, Chanwoo Choi wrote:
Hi Sachin,
On 04/16/2014 12:48 PM, Sachin Kamat wrote:
Hi Chanwoo,
On 14 April 2014 14:37, Chanwoo Choi cw00.c...@samsung.com wrote:
This patch control special clock for ADC in Exynos series's FSYS
block.
If special clock of ADC is registerd on clock list of common clk
framework,
Exynos ADC drvier have to control this clock.
Exynos3250/Exynos4/Exynos5 has 'adc' clock as following:
- 'adc' clock: bus clock for ADC
Exynos3250 has additional 'sclk_tsadc' clock as following:
- 'sclk_tsadc' clock: special clock for ADC which provide clock to
internal ADC
Exynos 4210/4212/4412 and Exynos5250/5420 has not included
'sclk_tsadc' clock
in FSYS_BLK. But, Exynos3250 based on Cortex-A7 has only included
'sclk_tsadc'
clock in FSYS_BLK.
Cc: Jonathan Cameron ji...@kernel.org
Cc: Kukjin Kim kgene@samsung.com
Cc: Naveen Krishna Chatradhi
Cc: linux-...@vger.kernel.org
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/iio/adc/exynos_adc.c | 54
+---
1 file changed, 41 insertions(+), 13 deletions(-)
diff --git a/drivers/iio/adc/exynos_adc.c
b/drivers/iio/adc/exynos_adc.c
index d25b262..3c99243 100644
--- a/drivers/iio/adc/exynos_adc.c
+++ b/drivers/iio/adc/exynos_adc.c
@@ -40,8 +40,9 @@
#include linux/iio/driver.h
enum adc_version {
- ADC_V1,
- ADC_V2
+ ADC_V1 = 0x1,
+ ADC_V2 = 0x2,
+ ADC_V3 = (ADC_V1 | ADC_V2),
Can't this be simply 0x3? Or is this not really a h/w version?
Even thought ADC_V3 isn't h/w revision, ADC_V3 include all featues of
ADC_V2
and only one difference of clock(sclk_tsadc) from ADC_V2.
I want to describethat ADC_V3 include ADC_V2 feature So, I add as
following:
+ ADC_V3 = (ADC_V1 | ADC_V2),
};
/* EXYNOS4412/5250 ADC_V1 registers definitions */
@@ -88,6 +89,7 @@ struct exynos_adc {
void __iomem*regs;
void __iomem*enable_reg;
struct clk *clk;
+ struct clk *sclk;
unsigned intirq;
struct regulator*vdd;
@@ -100,6 +102,7 @@ struct exynos_adc {
static const struct of_device_id exynos_adc_match[] = {
{ .compatible = samsung,exynos-adc-v1, .data = (void
*)ADC_V1 },
{ .compatible = samsung,exynos-adc-v2, .data = (void
*)ADC_V2 },
+ { .compatible = samsung,exynos-adc-v3, .data = (void
*)ADC_V3 },
{},
};
MODULE_DEVICE_TABLE(of, exynos_adc_match);
@@ -128,7 +131,7 @@ static int exynos_read_raw(struct iio_dev
*indio_dev,
mutex_lock(indio_dev-mlock);
/* Select the channel to be used and Trigger conversion */
- if (info-version == ADC_V2) {
+ if (info-version ADC_V2) {
So, now this would be applicable for ADC_V3 too, right?
ADC_V3 isn't h/w version. So, I think this code is proper instead of
using ADC_V3 direclty.
I want to use ADC_V3 version on checking clock(sclk_tsadc).
con2 = readl(ADC_V2_CON2(info-regs));
con2 = ~ADC_V2_CON2_ACH_MASK;
con2 |= ADC_V2_CON2_ACH_SEL(chan-address);
@@ -165,7 +168,7 @@ static irqreturn_t exynos_adc_isr(int irq, void
*dev_id)
info-value = readl(ADC_V1_DATX(info-regs))
ADC_DATX_MASK;
/* clear irq */
- if (info-version == ADC_V2)
+ if (info-version ADC_V2)
writel(1, ADC_V2_INT_ST(info-regs));
else
writel(1, ADC_V1_INTCLR(info-regs));
@@ -226,11 +229,25 @@ static int exynos_adc_remove_devices(struct
device *dev, void *c)
return 0;
}
+static void exynos_adc_enable_clock(struct exynos_adc *info, bool
enable)
+{
+ if (enable) {
+ clk_prepare_enable(info-clk);
This could fail. Is it OK without any checks?
OK, I'll check return value.
Do you want to check return value always?
I think again, Some device drivers in mainline would not check
return value of clock function. If maintainer confirm this
modification,
I'll fix it as your comment.
Its general good practice to check all return values. Even if a function
doesn't return an
error now, it might in future. There is lots of old or lazy code out there
doing many much
stranger things than this!
So yes, please check return values and pass on up the call stack if an error.
OK, I'll check return value of clock function. Thanks.
Best Regards,
Chanwoo Choi
--
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 2/6] PCI: tegra: use new OF interrupt mapping when possible
Am Dienstag, den 15.04.2014, 12:30 -0600 schrieb Bjorn Helgaas: On Tue, Apr 15, 2014 at 12:07:34PM +0200, Lucas Stach wrote: Hi Bjorn, Am Freitag, den 04.04.2014, 10:55 -0600 schrieb Bjorn Helgaas: On Wed, Mar 05, 2014 at 02:25:47PM +0100, Lucas Stach wrote: This is the recommended method of doing the IRQ mapping. For old devicetrees we fall back to the previous practice. Signed-off-by: Lucas Stach l.st...@pengutronix.de Acked-by: Arnd Bergmann a...@arndb.de Applied with Stephen's Tested-by to my pending/host-tegra branch. I'll rebase and rename it after v3.15-rc1, and I think we can squeeze it into v3.15 shortly after that. Thanks. Are you still planning to push this into 3.15, or has this slipped to 3.16? Yes, I'm hoping to put them in v3.15. I assume these actually fix something, e.g., we need these changes to boot with new devicetrees, or something? The changelogs don't make it clear that these are fixes, and I want to heed Linus' guidance: Anyway, because -rc1 is already pretty darn big, I do *not* want to hear about 'sorry this missed the window, can I still sneak in'. Fixes only. I should have applied these sooner to make the merge window; I apologize for that. Anyway, if you outline what these fix, I'll update the changelogs in my tree. Actually they are a bit on the fence. The i.MX and thus the designware patch actually fixes wrong behavior, where all PCI legacy interrupts would be mapped to a single GIC interrupt, which would leave INT B,C,D nonfunctional on i.MX. The others only make DT interrupt mapping functional for all drivers, so they would be useful if you need to remap interrupts across bridges or something. But apparently nobody had the need to to this on platforms other than i.MX until now, so those patches only fix a theoretical issue. Regards, Lucas -- Pengutronix e.K. | Lucas Stach | Industrial Linux Solutions | http://www.pengutronix.de/ | -- 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/3] clocksource: exynos_mct: Fix stall after CPU hotplugging
On wto, 2014-04-15 at 18:20 +0200, Thomas Gleixner wrote:
B1;3202;0cOn Tue, 15 Apr 2014, Krzysztof Kozlowski wrote:
On wto, 2014-04-15 at 17:20 +0200, Thomas Gleixner wrote:
On Tue, 15 Apr 2014, Krzysztof Kozlowski wrote:
On wto, 2014-04-15 at 14:28 +0200, Daniel Lezcano wrote:
On 04/15/2014 11:34 AM, Krzysztof Kozlowski wrote:
On pią, 2014-03-28 at 14:06 +0100, Krzysztof Kozlowski wrote:
Fix stall after hotplugging CPU1. Affected are SoCs where Multi
Core Timer
interrupts are shared (SPI), e.g. Exynos 4210. The stall was a
result of
starting the CPU1 local timer not in L1 timer but in L0 (which is
used
by CPU0).
Hi,
Do you have any comments on these 3 patches? They fix the CPU stall
on
Exynos4210 and also on Exynos3250 (Chanwoo Choi sent patches for it
recently).
You describe this issue as impacting different SoC not only the
exynos,
right ?
Do you know what other SoCs are impacted by this ?
No, affected are only Exynos SoC-s. It was confirmed on Exynos4210
(Trats board) and Exynos3250 (new SoC, patches for it were recently
posted by Chanwoo).
Other Exynos SoC-s where MCT local timers use shared interrupts (SPI)
can also be affected. Candidates are Exynos 5250 and 5420 but I haven't
tested them.
I guess this issue is not reproducible just with the line below, we
need
a timer to expire right at the moment CPU1 is hotplugged, right ?
Right. The timer must fire in short time between enabling local timer
for CPU1 and setting the affinity for IRQ.
Why do you set the affinity in the CPU_ONLINE hotplug callback and not
right away when the interrupt is requested?
Hi,
I think the problem in such code is in GIC. The gic_set_affinity() uses
cpu_online_mask:
unsigned int cpu = cpumask_any_and(mask_val, cpu_online_mask);
In that time this CPU is not present in that mask so -EINVAL would be
returned.
Hmm, indeed. Stupid me.
Here is a complete solution to the problem. We really want the drivers
to be fast and clean and not work around such issues.
I'm quite happy that I kept the 'force' argument of set_affinity
callbacks. I knew that I'd need it at some point.
So with the flag set we can disable the online mask check and force
the interrupt to the proper cpu.
Thanks for the solution.
I tested your patch on Exynos 3250 and it is still not sufficient. After
hotplugging CPU1 ~10 times the stall happens (set_next_event is called
on wrong CPU).
The patch 3/3 (clocksource: exynos_mct: Fix too early ISR fire up on
wrong CPU) is needed as the clockevents_config_and_register should be
called a little later.
Do you have rest of patches (2/3 and 3/3) or should I resend them?
And one minor nit in your patch: 'cpu' local variable in
exynos4_mct_cpu_notify() is no longer used so it can be removed.
Best regards,
Krzysztof
Thanks,
tglx
Index: linux-2.6/drivers/clocksource/exynos_mct.c
===
--- linux-2.6.orig/drivers/clocksource/exynos_mct.c
+++ linux-2.6/drivers/clocksource/exynos_mct.c
@@ -430,6 +430,7 @@ static int exynos4_local_timer_setup(str
evt-irq);
return -EIO;
}
+ irq_force_affinity(mct_irqs[MCT_L0_IRQ + cpu], cpumask_of(cpu));
} else {
enable_percpu_irq(mct_irqs[MCT_L0_IRQ], 0);
}
@@ -461,12 +462,6 @@ static int exynos4_mct_cpu_notify(struct
mevt = this_cpu_ptr(percpu_mct_tick);
exynos4_local_timer_setup(mevt-evt);
break;
- case CPU_ONLINE:
- cpu = (unsigned long)hcpu;
- if (mct_int_type == MCT_INT_SPI)
- irq_set_affinity(mct_irqs[MCT_L0_IRQ + cpu],
- cpumask_of(cpu));
- break;
case CPU_DYING:
mevt = this_cpu_ptr(percpu_mct_tick);
exynos4_local_timer_stop(mevt-evt);
Index: linux-2.6/drivers/irqchip/irq-gic.c
===
--- linux-2.6.orig/drivers/irqchip/irq-gic.c
+++ linux-2.6/drivers/irqchip/irq-gic.c
@@ -246,10 +246,14 @@ static int gic_set_affinity(struct irq_d
bool force)
{
void __iomem *reg = gic_dist_base(d) + GIC_DIST_TARGET + (gic_irq(d)
~3);
- unsigned int shift = (gic_irq(d) % 4) * 8;
- unsigned int cpu = cpumask_any_and(mask_val, cpu_online_mask);
+ unsigned int cpu, shift = (gic_irq(d) % 4) * 8;
u32 val, mask, bit;
+ if (!force)
+ cpu = cpumask_any_and(mask_val, cpu_online_mask);
+ else
+ cpu = cpumask_first(mask_val);
+
if (cpu = NR_GIC_CPU_IF || cpu = nr_cpu_ids)
return -EINVAL;
Re: [PATCH 1/3] clocksource: exynos_mct: Fix stall after CPU hotplugging
On Wed, 16 Apr 2014, Krzysztof Kozlowski wrote: On wto, 2014-04-15 at 18:20 +0200, Thomas Gleixner wrote: Here is a complete solution to the problem. We really want the drivers to be fast and clean and not work around such issues. I'm quite happy that I kept the 'force' argument of set_affinity callbacks. I knew that I'd need it at some point. So with the flag set we can disable the online mask check and force the interrupt to the proper cpu. Thanks for the solution. I tested your patch on Exynos 3250 and it is still not sufficient. After hotplugging CPU1 ~10 times the stall happens (set_next_event is called on wrong CPU). The patch 3/3 (clocksource: exynos_mct: Fix too early ISR fire up on wrong CPU) is needed as the clockevents_config_and_register should be called a little later. Ok. That makes sense. Do you have rest of patches (2/3 and 3/3) or should I resend them? And one minor nit in your patch: 'cpu' local variable in exynos4_mct_cpu_notify() is no longer used so it can be removed. Right. I'm going to create a proper patch for the interrupt side and stick that into irq/urgent. It's trivial enough to go in right away and I'll tag it stable as well. You can build your changes on top then. Thanks, tglx -- 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/3] mfd: tps65090: Allow charger module to be used when no irq
On the ARM Chromebook tps65090 has two masters: the AP (the main processor running linux) and the EC (the embedded controller). The AP is allowed to mess with FETs but the EC is in charge of charge control. The tps65090 interupt line is routed to both the AP and the EC, which can cause quite a headache. Having two people adjusting masks and acking interrupts is a recipe for disaster. In the shipping kernel we had a hack to have the AP pay attention to the IRQ but not to ack it. It also wasn't supposed to configure the IRQ in any way. That hack allowed us to detect when the device was charging without messing with the EC's state. The current tps65090 infrastructure makes the above difficult, and it was a bit of a hack to begin with. Rather than uglify the driver to support it, just extend the driver's existing notion of no irq to the charger. This makes the charger code poll every 2 seconds for AC detect, which is sufficient. Signed-off-by: Doug Anderson diand...@chromium.org --- drivers/mfd/tps65090.c | 14 ++-- drivers/power/tps65090-charger.c | 76 +++- 2 files changed, 70 insertions(+), 20 deletions(-) For the MFD part: Acked-by: Lee Jones lee.jo...@linaro.org Anton, If you are okay with this patch I'd be happy to create an immutable branch for you to pull from? Doug, What is the relationship (dependencies) between this and the other patches in the set? -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] mfd: tps65090: Stop caching registers
Nearly all of the registers in tps65090 combine control bits and
status bits. Turn off caching of registers so that we can read status
bits reliably.
NOTE: the IRQnMASK and CG_CTRLn registers are the exception and could
be cached. If we find that we spend a lot of time reading those we
can turn on cache for just those registers.
Signed-off-by: Doug Anderson diand...@chromium.org
---
drivers/mfd/tps65090.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/drivers/mfd/tps65090.c b/drivers/mfd/tps65090.c
index c3cddb4..4cfdd07 100644
--- a/drivers/mfd/tps65090.c
+++ b/drivers/mfd/tps65090.c
@@ -149,21 +149,11 @@ static struct regmap_irq_chip tps65090_irq_chip = {
.mask_invert = true,
};
-static bool is_volatile_reg(struct device *dev, unsigned int reg)
-{
- if ((reg == TPS65090_INT_STS) || (reg == TPS65090_INT_STS2))
- return true;
- else
- return false;
-}
-
I don't know enough about Regmap internals to know what this actually
affects in real terms.
Mark,
Does this change seem sane to you?
static const struct regmap_config tps65090_regmap_config = {
.reg_bits = 8,
.val_bits = 8,
.max_register = TOTAL_NUM_REG,
.num_reg_defaults_raw = TOTAL_NUM_REG,
- .cache_type = REGCACHE_RBTREE,
- .volatile_reg = is_volatile_reg,
};
#ifdef CONFIG_OF
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv3 1/2] iio: adc: exynos_adc: Control special clock of ADC to support Exynos3250 ADC
This patch control special clock for ADC in Exynos series's FSYS block.
If special clock of ADC is registerd on clock list of common clk framework,
Exynos ADC drvier have to control this clock.
Exynos3250/Exynos4/Exynos5 has 'adc' clock as following:
- 'adc' clock: bus clock for ADC
Exynos3250 has additional 'sclk_tsadc' clock as following:
- 'sclk_tsadc' clock: special clock for ADC which provide clock to internal ADC
Exynos 4210/4212/4412 and Exynos5250/5420 has not included 'sclk_tsadc' clock
in FSYS_BLK. But, Exynos3250 based on Cortex-A7 has only included 'sclk_tsadc'
clock in FSYS_BLK.
Cc: Jonathan Cameron ji...@kernel.org
Cc: Kukjin Kim kgene@samsung.com
Cc: Naveen Krishna Chatradhi
Cc: linux-...@vger.kernel.org
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/iio/adc/exynos_adc.c | 86 +---
1 file changed, 73 insertions(+), 13 deletions(-)
diff --git a/drivers/iio/adc/exynos_adc.c b/drivers/iio/adc/exynos_adc.c
index d25b262..486771e 100644
--- a/drivers/iio/adc/exynos_adc.c
+++ b/drivers/iio/adc/exynos_adc.c
@@ -40,8 +40,9 @@
#include linux/iio/driver.h
enum adc_version {
- ADC_V1,
- ADC_V2
+ ADC_V1 = 0x1,
+ ADC_V2 = 0x2,
+ ADC_V3 = (ADC_V1 | ADC_V2),
};
/* EXYNOS4412/5250 ADC_V1 registers definitions */
@@ -85,9 +86,11 @@ enum adc_version {
#define EXYNOS_ADC_TIMEOUT (msecs_to_jiffies(1000))
struct exynos_adc {
+ struct device *dev;
void __iomem*regs;
void __iomem*enable_reg;
struct clk *clk;
+ struct clk *sclk;
unsigned intirq;
struct regulator*vdd;
@@ -100,6 +103,7 @@ struct exynos_adc {
static const struct of_device_id exynos_adc_match[] = {
{ .compatible = samsung,exynos-adc-v1, .data = (void *)ADC_V1 },
{ .compatible = samsung,exynos-adc-v2, .data = (void *)ADC_V2 },
+ { .compatible = samsung,exynos-adc-v3, .data = (void *)ADC_V3 },
{},
};
MODULE_DEVICE_TABLE(of, exynos_adc_match);
@@ -128,7 +132,7 @@ static int exynos_read_raw(struct iio_dev *indio_dev,
mutex_lock(indio_dev-mlock);
/* Select the channel to be used and Trigger conversion */
- if (info-version == ADC_V2) {
+ if (info-version = ADC_V2) {
con2 = readl(ADC_V2_CON2(info-regs));
con2 = ~ADC_V2_CON2_ACH_MASK;
con2 |= ADC_V2_CON2_ACH_SEL(chan-address);
@@ -165,7 +169,7 @@ static irqreturn_t exynos_adc_isr(int irq, void *dev_id)
info-value = readl(ADC_V1_DATX(info-regs))
ADC_DATX_MASK;
/* clear irq */
- if (info-version == ADC_V2)
+ if (info-version = ADC_V2)
writel(1, ADC_V2_INT_ST(info-regs));
else
writel(1, ADC_V1_INTCLR(info-regs));
@@ -226,11 +230,43 @@ static int exynos_adc_remove_devices(struct device *dev,
void *c)
return 0;
}
+static int exynos_adc_enable_clock(struct exynos_adc *info, bool enable)
+{
+ int ret;
+
+ if (enable) {
+ ret = clk_prepare_enable(info-clk);
+ if (ret) {
+ dev_err(info-dev, failed to enable adc clock\n);
+ return ret;
+ }
+ if (info-version == ADC_V3) {
+ ret = clk_prepare_enable(info-sclk);
+ if (ret) {
+ dev_err(info-dev,
+ failed to enable sclk_tsadc clock\n);
+ goto err;
+ }
+ }
+
+ } else {
+ if (info-version == ADC_V3)
+ clk_disable_unprepare(info-sclk);
+ clk_disable_unprepare(info-clk);
+ }
+
+ return 0;
+err:
+ clk_disable_unprepare(info-clk);
+
+ return ret;
+}
+
static void exynos_adc_hw_init(struct exynos_adc *info)
{
u32 con1, con2;
- if (info-version == ADC_V2) {
+ if (info-version = ADC_V2) {
con1 = ADC_V2_CON1_SOFT_RESET;
writel(con1, ADC_V2_CON1(info-regs));
@@ -287,6 +323,7 @@ static int exynos_adc_probe(struct platform_device *pdev)
}
info-irq = irq;
+ info-dev = pdev-dev;
init_completion(info-completion);
@@ -300,6 +337,8 @@ static int exynos_adc_probe(struct platform_device *pdev)
writel(1, info-enable_reg);
+ info-version = exynos_adc_get_version(pdev);
+
info-clk = devm_clk_get(pdev-dev, adc);
if (IS_ERR(info-clk)) {
dev_err(pdev-dev, failed getting clock, err = %ld\n,
@@ -308,6 +347,16 @@ static int exynos_adc_probe(struct platform_device *pdev)
goto err_irq;
}
+ if (info-version == ADC_V3) {
+
[PATCHv3 0/2] iio: adc: exynos_adc: Support Exynos3250 ADC
This patchset support Exynos3250 ADC (Analog Digital Converter) because Exynos3250 has additional special clock for ADC IP. Changes from v2: - Check return value of clock function to deal with error exception - Fix minor coding style to improve readability Changes from v1: - Add new samsung,exynos-adc-v3 compatible to support Exynos3250 ADC - Add a patch about DT binding documentation Chanwoo Choi (2): iio: adc: exynos_adc: Control special clock of ADC to support Exynos3250 ADC iio: devicetree: Add DT binding documentation for Exynos3250 ADC .../devicetree/bindings/arm/samsung/exynos-adc.txt | 20 + drivers/iio/adc/exynos_adc.c | 86 ++ 2 files changed, 93 insertions(+), 13 deletions(-) -- 1.8.0 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv3 2/2] iio: devicetree: Add DT binding documentation for Exynos3250 ADC
This patch add DT binding documentation for Exynos3250 ADC IP. Exynos3250 has
special clock ('sclk_tsadc') for ADC which provide clock to internal ADC.
Cc: Rob Herring robh...@kernel.org
Cc: Pawel Moll pawel.m...@arm.com
Cc: Mark Rutland mark.rutl...@arm.com
Cc: Ian Campbell ijc+devicet...@hellion.org.uk
Cc: Kumar Gala ga...@codeaurora.org
Cc: Randy Dunlap rdun...@infradead.org
Cc: Kukjin Kim kgene@samsung.com
Cc: Naveen Krishna Chatradhi ch.nav...@samsung.com
Cc: Tomasz Figa t.f...@samsung.com
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
.../devicetree/bindings/arm/samsung/exynos-adc.txt | 20
1 file changed, 20 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
b/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
index 5d49f2b..7532ec3 100644
--- a/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
+++ b/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
@@ -14,6 +14,8 @@ Required properties:
for exynos4412/5250 controllers.
Must be samsung,exynos-adc-v2 for
future controllers.
+ Must be samsung,exynos-adc-v3 for
+ for exynos3250 controllers.
- reg: Contains ADC register address range (base address and
length) and the address of the phy enable register.
- interrupts: Contains the interrupt information for the timer. The
@@ -21,7 +23,11 @@ Required properties:
the Samsung device uses.
- #io-channel-cells = 1; As ADC has multiple outputs
- clocks From common clock binding: handle to adc clock.
+ From common clock binding: handle to sclk_tsadc clock
+ if using Exynos3250.
- clock-names From common clock binding: Shall be adc.
+ From common clock binding: Shall be sclk_tsadc
+ if using Exynos3250.
- vdd-supply VDD input supply.
Note: child nodes can be added for auto probing from device tree.
@@ -41,6 +47,20 @@ adc: adc@12D1 {
vdd-supply = buck5_reg;
};
+If Exynos3250 uses ADC,
+adc: adc@126C {
+ compatible = samsung,exynos-adc-v3;
+ reg = 0x126C 0x100, 0x10020718 0x4;
+ interrupts = 0 137 0;
+ #io-channel-cells = 1;
+ io-channel-ranges;
+
+ clock-names = adc, sclk_tsadc;
+ clocks = cmu CLK_TSADC, cmu CLK_SCLK_TSADC;
+
+ vdd-supply = buck5_reg;
+};
+
Example: Adding child nodes in dts file
--
1.8.0
--
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/3] mfd: tps65090: Stop caching registers
On Wed, Apr 16, 2014 at 10:59:22AM +0100, Lee Jones wrote:
NOTE: the IRQnMASK and CG_CTRLn registers are the exception and could
be cached. If we find that we spend a lot of time reading those we
can turn on cache for just those registers.
-static bool is_volatile_reg(struct device *dev, unsigned int reg)
-{
- if ((reg == TPS65090_INT_STS) || (reg == TPS65090_INT_STS2))
- return true;
- else
- return false;
-}
-
I don't know enough about Regmap internals to know what this actually
affects in real terms.
Mark,
Does this change seem sane to you?
It does what it says, it stops us caching stuff. It would seem better
to do what the changelog suggests above and keep caching the registers
that can be cached - especially the interrupt masks, they should get
read in the interrupt path and that tends to be a bit latency sensitive.
signature.asc
Description: Digital signature
Re: [PATCHv2] pinctrl: exynos: Add driver data for Exynos3250
Hi Linus Walleij,
I sent this patch with minor modification.
Any comment of this patch?
Best Regards,
Chanwoo Choi
On 04/14/2014 10:45 AM, Chanwoo Choi wrote:
From: Tomasz Figa t.f...@samsung.com
This patch adds driver data (bank list and EINT layout) for Exynos3250
to pinctrl-exynos driver. Exynos3250 includes 158 multi-functional
input/output
ports. There are 23 general port groups.
Changes from v1:
- Add signed-off of sender
- Post only separated patch for pinctrl from following patchset(v1)
: https://lkml.org/lkml/2014/4/10/286
Cc: Thomas Abraham thomas.abra...@linaro.org
Cc: Linus Walleij linus.wall...@linaro.org
Cc: Kukjin Kim kgene@samsung.com
Signed-off-by: Tomasz Figa t.f...@samsung.com
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/pinctrl/pinctrl-exynos.c | 67
+++
drivers/pinctrl/pinctrl-samsung.c | 2 ++
drivers/pinctrl/pinctrl-samsung.h | 1 +
3 files changed, 70 insertions(+)
diff --git a/drivers/pinctrl/pinctrl-exynos.c
b/drivers/pinctrl/pinctrl-exynos.c
index 07c8130..9609c23 100644
--- a/drivers/pinctrl/pinctrl-exynos.c
+++ b/drivers/pinctrl/pinctrl-exynos.c
@@ -718,6 +718,73 @@ struct samsung_pin_ctrl s5pv210_pin_ctrl[] = {
},
};
+/* pin banks of exynos3250 pin-controller 0 */
+static struct samsung_pin_bank exynos3250_pin_banks0[] = {
+ EXYNOS_PIN_BANK_EINTG(8, 0x000, gpa0, 0x00),
+ EXYNOS_PIN_BANK_EINTG(6, 0x020, gpa1, 0x04),
+ EXYNOS_PIN_BANK_EINTG(8, 0x040, gpb, 0x08),
+ EXYNOS_PIN_BANK_EINTG(5, 0x060, gpc0, 0x0c),
+ EXYNOS_PIN_BANK_EINTG(5, 0x080, gpc1, 0x10),
+ EXYNOS_PIN_BANK_EINTG(4, 0x0a0, gpd0, 0x14),
+ EXYNOS_PIN_BANK_EINTG(4, 0x0c0, gpd1, 0x18),
+};
+
+/* pin banks of exynos3250 pin-controller 1 */
+static struct samsung_pin_bank exynos3250_pin_banks1[] = {
+ EXYNOS_PIN_BANK_EINTN(8, 0x120, gpe0),
+ EXYNOS_PIN_BANK_EINTN(8, 0x140, gpe1),
+ EXYNOS_PIN_BANK_EINTN(3, 0x180, gpe2),
+ EXYNOS_PIN_BANK_EINTG(8, 0x040, gpk0, 0x08),
+ EXYNOS_PIN_BANK_EINTG(7, 0x060, gpk1, 0x0c),
+ EXYNOS_PIN_BANK_EINTG(7, 0x080, gpk2, 0x10),
+ EXYNOS_PIN_BANK_EINTG(4, 0x0c0, gpl0, 0x18),
+ EXYNOS_PIN_BANK_EINTG(8, 0x260, gpm0, 0x24),
+ EXYNOS_PIN_BANK_EINTG(7, 0x280, gpm1, 0x28),
+ EXYNOS_PIN_BANK_EINTG(5, 0x2a0, gpm2, 0x2c),
+ EXYNOS_PIN_BANK_EINTG(8, 0x2c0, gpm3, 0x30),
+ EXYNOS_PIN_BANK_EINTG(8, 0x2e0, gpm4, 0x34),
+ EXYNOS_PIN_BANK_EINTW(8, 0xc00, gpx0, 0x00),
+ EXYNOS_PIN_BANK_EINTW(8, 0xc20, gpx1, 0x04),
+ EXYNOS_PIN_BANK_EINTW(8, 0xc40, gpx2, 0x08),
+ EXYNOS_PIN_BANK_EINTW(8, 0xc60, gpx3, 0x0c),
+};
+
+/*
+ * Samsung pinctrl driver data for Exynos3250 SoC. Exynos3250 SoC includes
+ * two gpio/pin-mux/pinconfig controllers.
+ */
+struct samsung_pin_ctrl exynos3250_pin_ctrl[] = {
+ {
+ /* pin-controller instance 0 data */
+ .pin_banks = exynos3250_pin_banks0,
+ .nr_banks = ARRAY_SIZE(exynos3250_pin_banks0),
+ .geint_con = EXYNOS_GPIO_ECON_OFFSET,
+ .geint_mask = EXYNOS_GPIO_EMASK_OFFSET,
+ .geint_pend = EXYNOS_GPIO_EPEND_OFFSET,
+ .svc= EXYNOS_SVC_OFFSET,
+ .eint_gpio_init = exynos_eint_gpio_init,
+ .suspend= exynos_pinctrl_suspend,
+ .resume = exynos_pinctrl_resume,
+ .label = exynos3250-gpio-ctrl0,
+ }, {
+ /* pin-controller instance 1 data */
+ .pin_banks = exynos3250_pin_banks1,
+ .nr_banks = ARRAY_SIZE(exynos3250_pin_banks1),
+ .geint_con = EXYNOS_GPIO_ECON_OFFSET,
+ .geint_mask = EXYNOS_GPIO_EMASK_OFFSET,
+ .geint_pend = EXYNOS_GPIO_EPEND_OFFSET,
+ .weint_con = EXYNOS_WKUP_ECON_OFFSET,
+ .weint_mask = EXYNOS_WKUP_EMASK_OFFSET,
+ .weint_pend = EXYNOS_WKUP_EPEND_OFFSET,
+ .svc= EXYNOS_SVC_OFFSET,
+ .eint_gpio_init = exynos_eint_gpio_init,
+ .eint_wkup_init = exynos_eint_wkup_init,
+ .suspend= exynos_pinctrl_suspend,
+ .resume = exynos_pinctrl_resume,
+ .label = exynos3250-gpio-ctrl1,
+ },
+};
+
/* pin banks of exynos4210 pin-controller 0 */
static struct samsung_pin_bank exynos4210_pin_banks0[] = {
EXYNOS_PIN_BANK_EINTG(8, 0x000, gpa0, 0x00),
diff --git a/drivers/pinctrl/pinctrl-samsung.c
b/drivers/pinctrl/pinctrl-samsung.c
index 0324d4c..3e61d0f 100644
--- a/drivers/pinctrl/pinctrl-samsung.c
+++ b/drivers/pinctrl/pinctrl-samsung.c
@@ -1114,6 +1114,8 @@ static struct syscore_ops samsung_pinctrl_syscore_ops =
{
static const struct of_device_id samsung_pinctrl_dt_match[] = {
#ifdef
Re: [PATCHv3 1/2] iio: adc: exynos_adc: Control special clock of ADC to support Exynos3250 ADC
Hi Chanwoo,
On 16.04.2014 12:11, Chanwoo Choi wrote:
This patch control special clock for ADC in Exynos series's FSYS block.
If special clock of ADC is registerd on clock list of common clk framework,
Exynos ADC drvier have to control this clock.
Exynos3250/Exynos4/Exynos5 has 'adc' clock as following:
- 'adc' clock: bus clock for ADC
Exynos3250 has additional 'sclk_tsadc' clock as following:
- 'sclk_tsadc' clock: special clock for ADC which provide clock to internal ADC
Exynos 4210/4212/4412 and Exynos5250/5420 has not included 'sclk_tsadc' clock
in FSYS_BLK. But, Exynos3250 based on Cortex-A7 has only included 'sclk_tsadc'
clock in FSYS_BLK.
Cc: Jonathan Cameron ji...@kernel.org
Cc: Kukjin Kim kgene@samsung.com
Cc: Naveen Krishna Chatradhi
Cc: linux-...@vger.kernel.org
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/iio/adc/exynos_adc.c | 86 +---
1 file changed, 73 insertions(+), 13 deletions(-)
diff --git a/drivers/iio/adc/exynos_adc.c b/drivers/iio/adc/exynos_adc.c
index d25b262..486771e 100644
--- a/drivers/iio/adc/exynos_adc.c
+++ b/drivers/iio/adc/exynos_adc.c
@@ -40,8 +40,9 @@
#include linux/iio/driver.h
enum adc_version {
- ADC_V1,
- ADC_V2
+ ADC_V1 = 0x1,
+ ADC_V2 = 0x2,
+ ADC_V3 = (ADC_V1 | ADC_V2),
I don't think Exynos3250 has really a V3 of the ADC block. It looks like
a V2, just with different integration details. This approach is
confusing and will create problems if real V3 shows up.
In general, using a version enum and a lot of ifs for particular
versions in the code is rather a bad practice, especially when multiple
versions happen to require the same quirks.
Instead, a variant struct should be introduced with bitfields for
particular quirks and/or register offsets and/or function pointers. Let
me show example solutions inline with your changes below.
};
/* EXYNOS4412/5250 ADC_V1 registers definitions */
@@ -85,9 +86,11 @@ enum adc_version {
#define EXYNOS_ADC_TIMEOUT(msecs_to_jiffies(1000))
struct exynos_adc {
+ struct device *dev;
void __iomem*regs;
void __iomem*enable_reg;
struct clk *clk;
+ struct clk *sclk;
unsigned intirq;
struct regulator*vdd;
@@ -100,6 +103,7 @@ struct exynos_adc {
static const struct of_device_id exynos_adc_match[] = {
{ .compatible = samsung,exynos-adc-v1, .data = (void *)ADC_V1 },
{ .compatible = samsung,exynos-adc-v2, .data = (void *)ADC_V2 },
+ { .compatible = samsung,exynos-adc-v3, .data = (void *)ADC_V3 },
{},
};
MODULE_DEVICE_TABLE(of, exynos_adc_match);
@@ -128,7 +132,7 @@ static int exynos_read_raw(struct iio_dev *indio_dev,
mutex_lock(indio_dev-mlock);
/* Select the channel to be used and Trigger conversion */
- if (info-version == ADC_V2) {
+ if (info-version = ADC_V2) {
con2 = readl(ADC_V2_CON2(info-regs));
con2 = ~ADC_V2_CON2_ACH_MASK;
con2 |= ADC_V2_CON2_ACH_SEL(chan-address);
This function should be split into exynos_adc_v1_read_raw() and
exynos_adc_v2_read_raw(). Then a function pointer for int
(*read_raw)(...) should be added to the variant struct I mentioned
above. Then the generic part of existing exynos_read_raw() would just
call variant-read_raw().
@@ -165,7 +169,7 @@ static irqreturn_t exynos_adc_isr(int irq, void *dev_id)
info-value = readl(ADC_V1_DATX(info-regs))
ADC_DATX_MASK;
/* clear irq */
- if (info-version == ADC_V2)
+ if (info-version = ADC_V2)
writel(1, ADC_V2_INT_ST(info-regs));
else
writel(1, ADC_V1_INTCLR(info-regs));
void (*clear_irq)().
@@ -226,11 +230,43 @@ static int exynos_adc_remove_devices(struct device *dev,
void *c)
return 0;
}
+static int exynos_adc_enable_clock(struct exynos_adc *info, bool enable)
+{
+ int ret;
+
+ if (enable) {
+ ret = clk_prepare_enable(info-clk);
+ if (ret) {
+ dev_err(info-dev, failed to enable adc clock\n);
+ return ret;
+ }
+ if (info-version == ADC_V3) {
Here, a bitfield bool needs_sclk:1; in the variant struct would be
sufficient.
+ ret = clk_prepare_enable(info-sclk);
+ if (ret) {
+ dev_err(info-dev,
+ failed to enable sclk_tsadc clock\n);
+ goto err;
+ }
+ }
+
+ } else {
+ if (info-version == ADC_V3)
+ clk_disable_unprepare(info-sclk);
+ clk_disable_unprepare(info-clk);
+ }
+
+
Re: [PATCH Resend 3/3] ARM: EXYNOS: Map SYSRAM address through DT
Hi Sachin,
I want to use this patch to remove static SYSRAM memory mapping for Exynos3250.
But this patch has conflict on 3.15-rc1 base.
Do you have a plan to resend this patch?
Thanks,
Chanwoo Choi
On 03/19/2014 07:25 PM, Sachin Kamat wrote:
Instead of hardcoding the SYSRAM details for each SoC,
pass this information through device tree (DT) and make
the code SoC agnostic.
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
---
.../devicetree/bindings/arm/samsung-boards.txt | 11 +++
arch/arm/boot/dts/exynos4210-universal_c210.dts|9 ++
arch/arm/boot/dts/exynos4210.dtsi | 10 ++
arch/arm/boot/dts/exynos4x12.dtsi | 10 ++
arch/arm/boot/dts/exynos5.dtsi |5 +
arch/arm/boot/dts/exynos5250.dtsi |5 +
arch/arm/boot/dts/exynos5420.dtsi |5 +
arch/arm/mach-exynos/common.c | 104
arch/arm/mach-exynos/include/mach/map.h|7 --
9 files changed, 95 insertions(+), 71 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/samsung-boards.txt
b/Documentation/devicetree/bindings/arm/samsung-boards.txt
index 2168ed31e1b0..f79710eb7e79 100644
--- a/Documentation/devicetree/bindings/arm/samsung-boards.txt
+++ b/Documentation/devicetree/bindings/arm/samsung-boards.txt
@@ -7,6 +7,17 @@ Required root node properties:
(a) samsung,smdkv310 - for Samsung's SMDKV310 eval board.
(b) samsung,exynos4210 - for boards based on Exynos4210 SoC.
+- sysram node, specifying the type (secure or non-secure) of SYSRAM
+ - compatible: following types are supported
+ samsung,exynos4210-sysram : Secure SYSRAM
+ samsung,exynos4210-sysram-ns : Non-secure SYSRAM
+ - reg: address of SYSRAM bank
+
+ sysram@0202 {
+ compatible = samsung,exynos4210-sysram;
+ reg = 0x0202 0x1000;
+ };
+
Optional:
- firmware node, specifying presence and type of secure firmware:
- compatible: only samsung,secure-firmware is currently supported
diff --git a/arch/arm/boot/dts/exynos4210-universal_c210.dts
b/arch/arm/boot/dts/exynos4210-universal_c210.dts
index d2e3f5f5916d..b893a042e3f7 100644
--- a/arch/arm/boot/dts/exynos4210-universal_c210.dts
+++ b/arch/arm/boot/dts/exynos4210-universal_c210.dts
@@ -28,6 +28,15 @@
bootargs = console=ttySAC2,115200N8 root=/dev/mmcblk0p5 rw
rootwait earlyprintk panic=5 maxcpus=1;
};
+ sysram@0202 {
+ status = disabled;
+ };
+
+ sysram@02025000 {
+ compatible = samsung,exynos4210-sysram;
+ reg = 0x02025000 0x1000;
+ };
+
mct@1005 {
compatible = none;
};
diff --git a/arch/arm/boot/dts/exynos4210.dtsi
b/arch/arm/boot/dts/exynos4210.dtsi
index cb0e768dc6d4..b92982b9607e 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -31,6 +31,16 @@
pinctrl2 = pinctrl_2;
};
+ sysram@0202 {
+ compatible = samsung,exynos4210-sysram;
+ reg = 0x0202 0x1000;
+ };
+
+ sysram-ns@0203F000 {
+ compatible = samsung,exynos4210-sysram-ns;
+ reg = 0x0203F000 0x1000;
+ };
+
pd_lcd1: lcd1-power-domain@10023CA0 {
compatible = samsung,exynos4210-pd;
reg = 0x10023CA0 0x20;
diff --git a/arch/arm/boot/dts/exynos4x12.dtsi
b/arch/arm/boot/dts/exynos4x12.dtsi
index c4a9306f8529..d57e3120223f 100644
--- a/arch/arm/boot/dts/exynos4x12.dtsi
+++ b/arch/arm/boot/dts/exynos4x12.dtsi
@@ -37,6 +37,16 @@
interrupts = 2 2, 3 2, 18 2, 19 2;
};
+ sysram@0202 {
+ compatible = samsung,exynos4210-sysram;
+ reg = 0x0202 0x1000;
+ };
+
+ sysram-ns@0204F000 {
+ compatible = samsung,exynos4210-sysram-ns;
+ reg = 0x0204F000 0x1000;
+ };
+
pd_isp: isp-power-domain@10023CA0 {
compatible = samsung,exynos4210-pd;
reg = 0x10023CA0 0x20;
diff --git a/arch/arm/boot/dts/exynos5.dtsi b/arch/arm/boot/dts/exynos5.dtsi
index 79d0608d6dcc..c03bd09ec37d 100644
--- a/arch/arm/boot/dts/exynos5.dtsi
+++ b/arch/arm/boot/dts/exynos5.dtsi
@@ -18,6 +18,11 @@
/ {
interrupt-parent = gic;
+ sysram@0202 {
+ compatible = samsung,exynos4210-sysram;
+ reg = 0x0202 0x1000;
+ };
+
chipid@1000 {
compatible = samsung,exynos4210-chipid;
reg = 0x1000 0x100;
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index fdeed7c29ac9..abfceadbb1ea 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -72,6 +72,11 @@
};
};
+
Re: [PATCHv3 2/2] iio: devicetree: Add DT binding documentation for Exynos3250 ADC
Hi Chanwoo,
On 16.04.2014 12:11, Chanwoo Choi wrote:
This patch add DT binding documentation for Exynos3250 ADC IP. Exynos3250 has
special clock ('sclk_tsadc') for ADC which provide clock to internal ADC.
Cc: Rob Herring robh...@kernel.org
Cc: Pawel Moll pawel.m...@arm.com
Cc: Mark Rutland mark.rutl...@arm.com
Cc: Ian Campbell ijc+devicet...@hellion.org.uk
Cc: Kumar Gala ga...@codeaurora.org
Cc: Randy Dunlap rdun...@infradead.org
Cc: Kukjin Kim kgene@samsung.com
Cc: Naveen Krishna Chatradhi ch.nav...@samsung.com
Cc: Tomasz Figa t.f...@samsung.com
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
.../devicetree/bindings/arm/samsung/exynos-adc.txt | 20
1 file changed, 20 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
b/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
index 5d49f2b..7532ec3 100644
--- a/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
+++ b/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
@@ -14,6 +14,8 @@ Required properties:
for exynos4412/5250 controllers.
Must be samsung,exynos-adc-v2 for
future controllers.
+ Must be samsung,exynos-adc-v3 for
+ for exynos3250 controllers.
I don't think adc-v3 is correct here. It looks like a normal V2 with
additional special clock input. Possibly samsung,exynos3250-adc-v2 or
samsung,exynos-adc-v2-sclk would be better choices.
- reg:Contains ADC register address range (base
address and
length) and the address of the phy enable register.
- interrupts: Contains the interrupt information for the
timer. The
@@ -21,7 +23,11 @@ Required properties:
the Samsung device uses.
- #io-channel-cells = 1; As ADC has multiple outputs
- clocks From common clock binding: handle to adc clock.
+ From common clock binding: handle to sclk_tsadc clock
+ if using Exynos3250.
- clock-names From common clock binding: Shall be adc.
+ From common clock binding: Shall be sclk_tsadc
+ if using Exynos3250.
- vdd-supply VDD input supply.
Note: child nodes can be added for auto probing from device tree.
@@ -41,6 +47,20 @@ adc: adc@12D1 {
vdd-supply = buck5_reg;
};
+If Exynos3250 uses ADC,
Please keep proper formatting:
Example: Node for ADC of Exynos3250 with additional special clock
Best regards,
Tomasz
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH Resend] ARM: EXYNOS: Map SYSRAM address through DT
Instead of hardcoding the SYSRAM details for each SoC,
pass this information through device tree (DT) and make
the code SoC agnostic.
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
---
Rebased on latest linux-next.
---
.../devicetree/bindings/arm/samsung-boards.txt | 11 +++
arch/arm/boot/dts/exynos4210-universal_c210.dts|9 ++
arch/arm/boot/dts/exynos4210.dtsi | 10 ++
arch/arm/boot/dts/exynos4x12.dtsi | 10 ++
arch/arm/boot/dts/exynos5.dtsi |5 +
arch/arm/boot/dts/exynos5250.dtsi |5 +
arch/arm/boot/dts/exynos5420.dtsi |5 +
arch/arm/mach-exynos/exynos.c | 104
arch/arm/mach-exynos/include/mach/map.h|7 --
9 files changed, 95 insertions(+), 71 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/samsung-boards.txt
b/Documentation/devicetree/bindings/arm/samsung-boards.txt
index 2168ed31e1b0..f79710eb7e79 100644
--- a/Documentation/devicetree/bindings/arm/samsung-boards.txt
+++ b/Documentation/devicetree/bindings/arm/samsung-boards.txt
@@ -7,6 +7,17 @@ Required root node properties:
(a) samsung,smdkv310 - for Samsung's SMDKV310 eval board.
(b) samsung,exynos4210 - for boards based on Exynos4210 SoC.
+- sysram node, specifying the type (secure or non-secure) of SYSRAM
+ - compatible: following types are supported
+ samsung,exynos4210-sysram : Secure SYSRAM
+ samsung,exynos4210-sysram-ns : Non-secure SYSRAM
+ - reg: address of SYSRAM bank
+
+ sysram@0202 {
+ compatible = samsung,exynos4210-sysram;
+ reg = 0x0202 0x1000;
+ };
+
Optional:
- firmware node, specifying presence and type of secure firmware:
- compatible: only samsung,secure-firmware is currently supported
diff --git a/arch/arm/boot/dts/exynos4210-universal_c210.dts
b/arch/arm/boot/dts/exynos4210-universal_c210.dts
index 63e34b24b04f..cf4158728108 100644
--- a/arch/arm/boot/dts/exynos4210-universal_c210.dts
+++ b/arch/arm/boot/dts/exynos4210-universal_c210.dts
@@ -28,6 +28,15 @@
bootargs = console=ttySAC2,115200N8 root=/dev/mmcblk0p5 rw
rootwait earlyprintk panic=5 maxcpus=1;
};
+ sysram@0202 {
+ status = disabled;
+ };
+
+ sysram@02025000 {
+ compatible = samsung,exynos4210-sysram;
+ reg = 0x02025000 0x1000;
+ };
+
mct@1005 {
compatible = none;
};
diff --git a/arch/arm/boot/dts/exynos4210.dtsi
b/arch/arm/boot/dts/exynos4210.dtsi
index cacf6140dd2f..a3f4bba099e6 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -31,6 +31,16 @@
pinctrl2 = pinctrl_2;
};
+ sysram@0202 {
+ compatible = samsung,exynos4210-sysram;
+ reg = 0x0202 0x1000;
+ };
+
+ sysram-ns@0203F000 {
+ compatible = samsung,exynos4210-sysram-ns;
+ reg = 0x0203F000 0x1000;
+ };
+
pd_lcd1: lcd1-power-domain@10023CA0 {
compatible = samsung,exynos4210-pd;
reg = 0x10023CA0 0x20;
diff --git a/arch/arm/boot/dts/exynos4x12.dtsi
b/arch/arm/boot/dts/exynos4x12.dtsi
index c4a9306f8529..d57e3120223f 100644
--- a/arch/arm/boot/dts/exynos4x12.dtsi
+++ b/arch/arm/boot/dts/exynos4x12.dtsi
@@ -37,6 +37,16 @@
interrupts = 2 2, 3 2, 18 2, 19 2;
};
+ sysram@0202 {
+ compatible = samsung,exynos4210-sysram;
+ reg = 0x0202 0x1000;
+ };
+
+ sysram-ns@0204F000 {
+ compatible = samsung,exynos4210-sysram-ns;
+ reg = 0x0204F000 0x1000;
+ };
+
pd_isp: isp-power-domain@10023CA0 {
compatible = samsung,exynos4210-pd;
reg = 0x10023CA0 0x20;
diff --git a/arch/arm/boot/dts/exynos5.dtsi b/arch/arm/boot/dts/exynos5.dtsi
index 79d0608d6dcc..c03bd09ec37d 100644
--- a/arch/arm/boot/dts/exynos5.dtsi
+++ b/arch/arm/boot/dts/exynos5.dtsi
@@ -18,6 +18,11 @@
/ {
interrupt-parent = gic;
+ sysram@0202 {
+ compatible = samsung,exynos4210-sysram;
+ reg = 0x0202 0x1000;
+ };
+
chipid@1000 {
compatible = samsung,exynos4210-chipid;
reg = 0x1000 0x100;
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index 37423314a028..bae6c3f253f0 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -72,6 +72,11 @@
};
};
+ sysram-ns@0204F000 {
+ compatible = samsung,exynos4210-sysram-ns;
+ reg = 0x0204F000 0x1000;
+ };
+
pd_gsc: gsc-power-domain@10044000 {
compatible = samsung,exynos4210-pd;
Re: [PATCH Resend 3/3] ARM: EXYNOS: Map SYSRAM address through DT
Hi Chanwoo, On 16 April 2014 16:36, Chanwoo Choi cw00.c...@samsung.com wrote: Hi Sachin, I want to use this patch to remove static SYSRAM memory mapping for Exynos3250. But this patch has conflict on 3.15-rc1 base. Do you have a plan to resend this patch? Rebased and resent (CC'd you). Please let me have your tested-by on it. --- With warm regards, Sachin -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/3] ARM: EXYNOS: Add initial support of PMU for Exynos5260
Hi Vikas,
On 16.04.2014 07:34, Vikas Sajjan wrote:
Hi Tomasz,
On Wed, Apr 16, 2014 at 12:04 AM, Tomasz Figa tomasz.f...@gmail.com wrote:
Hi Vikas,
On 17.03.2014 14:09, Vikas Sajjan wrote:
Adds PMU support of PMU for Exynos5260. Suspend-to-RAM can be built on
top this.
Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com
Signed-off-by: Vikas Sajjan vikas.saj...@samsung.com
---
arch/arm/mach-exynos/common.h| 26
arch/arm/mach-exynos/pm.c| 34 +++--
arch/arm/mach-exynos/pmu.c | 238
++
arch/arm/mach-exynos/regs-pmu.h | 232
+
arch/arm/plat-samsung/include/plat/cpu.h |8 +
5 files changed, 529 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-exynos/common.h b/arch/arm/mach-exynos/common.h
index aba6a2a..a17f701 100644
--- a/arch/arm/mach-exynos/common.h
+++ b/arch/arm/mach-exynos/common.h
@@ -56,6 +56,32 @@ enum sys_powerdown {
NUM_SYS_POWERDOWN,
};
+enum running_cpu {
+ EXYNOS5_KFC,
+ EXYNOS5_ARM,
+};
+
+enum reg_op {
+ REG_INIT, /* write new value */
+ REG_RESET, /* clear with zero */
+ REG_SET,/* bit set */
+ REG_CLEAR, /* bit clear */
+};
+
+/* reg/value set */
+#define EXYNOS_PMU_REG(REG, VAL, OP) \
+{ \
+ .reg= (void __iomem *)REG,\
+ .val= VAL,\
+ .op = OP, \
+}
+
+struct exynos_pmu_init_reg {
+ void __iomem *reg;
+ unsigned int val;
+ enum reg_op op;
+};
+
extern unsigned long l2x0_regs_phys;
struct exynos_pmu_conf {
void __iomem *reg;
diff --git a/arch/arm/mach-exynos/pm.c b/arch/arm/mach-exynos/pm.c
index 15af0ce..dbe9670 100644
--- a/arch/arm/mach-exynos/pm.c
+++ b/arch/arm/mach-exynos/pm.c
@@ -109,7 +109,7 @@ static int exynos_cpu_suspend(unsigned long arg)
outer_flush_all();
#endif
- if (soc_is_exynos5250())
+ if (soc_is_exynos5250() || soc_is_exynos5260())
flush_cache_all();
I think it's the right time for this code to be restructured. Adding more
and more SoCs over this cruft is making this code worse and worse.
I recently came across RFC [1] posted by pankaj on similar lines, did
you get a chance to have look at this series.
[1] https://lkml.org/lkml/2014/4/2/69
Right. I noticed it once, but didn't get to review it yet, as I'm a bit
busy with other things right now. Will try to take a look in next days.
Best regards,
Tomasz
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH Resend] ARM: EXYNOS: Map SYSRAM address through DT
Hi,
On 04/16/2014 08:50 PM, Sachin Kamat wrote:
Instead of hardcoding the SYSRAM details for each SoC,
pass this information through device tree (DT) and make
the code SoC agnostic.
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
---
Rebased on latest linux-next.
---
.../devicetree/bindings/arm/samsung-boards.txt | 11 +++
arch/arm/boot/dts/exynos4210-universal_c210.dts|9 ++
arch/arm/boot/dts/exynos4210.dtsi | 10 ++
arch/arm/boot/dts/exynos4x12.dtsi | 10 ++
arch/arm/boot/dts/exynos5.dtsi |5 +
arch/arm/boot/dts/exynos5250.dtsi |5 +
arch/arm/boot/dts/exynos5420.dtsi |5 +
arch/arm/mach-exynos/exynos.c | 104
arch/arm/mach-exynos/include/mach/map.h|7 --
9 files changed, 95 insertions(+), 71 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/samsung-boards.txt
b/Documentation/devicetree/bindings/arm/samsung-boards.txt
index 2168ed31e1b0..f79710eb7e79 100644
--- a/Documentation/devicetree/bindings/arm/samsung-boards.txt
+++ b/Documentation/devicetree/bindings/arm/samsung-boards.txt
@@ -7,6 +7,17 @@ Required root node properties:
(a) samsung,smdkv310 - for Samsung's SMDKV310 eval board.
(b) samsung,exynos4210 - for boards based on Exynos4210 SoC.
+- sysram node, specifying the type (secure or non-secure) of SYSRAM
+ - compatible: following types are supported
+ samsung,exynos4210-sysram : Secure SYSRAM
+ samsung,exynos4210-sysram-ns : Non-secure SYSRAM
+ - reg: address of SYSRAM bank
+
+ sysram@0202 {
+ compatible = samsung,exynos4210-sysram;
+ reg = 0x0202 0x1000;
+ };
+
Optional:
- firmware node, specifying presence and type of secure firmware:
- compatible: only samsung,secure-firmware is currently supported
diff --git a/arch/arm/boot/dts/exynos4210-universal_c210.dts
b/arch/arm/boot/dts/exynos4210-universal_c210.dts
index 63e34b24b04f..cf4158728108 100644
--- a/arch/arm/boot/dts/exynos4210-universal_c210.dts
+++ b/arch/arm/boot/dts/exynos4210-universal_c210.dts
@@ -28,6 +28,15 @@
bootargs = console=ttySAC2,115200N8 root=/dev/mmcblk0p5 rw
rootwait earlyprintk panic=5 maxcpus=1;
};
+ sysram@0202 {
+ status = disabled;
+ };
+
+ sysram@02025000 {
+ compatible = samsung,exynos4210-sysram;
+ reg = 0x02025000 0x1000;
+ };
+
mct@1005 {
compatible = none;
};
diff --git a/arch/arm/boot/dts/exynos4210.dtsi
b/arch/arm/boot/dts/exynos4210.dtsi
index cacf6140dd2f..a3f4bba099e6 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -31,6 +31,16 @@
pinctrl2 = pinctrl_2;
};
+ sysram@0202 {
+ compatible = samsung,exynos4210-sysram;
+ reg = 0x0202 0x1000;
+ };
+
+ sysram-ns@0203F000 {
+ compatible = samsung,exynos4210-sysram-ns;
+ reg = 0x0203F000 0x1000;
+ };
+
pd_lcd1: lcd1-power-domain@10023CA0 {
compatible = samsung,exynos4210-pd;
reg = 0x10023CA0 0x20;
diff --git a/arch/arm/boot/dts/exynos4x12.dtsi
b/arch/arm/boot/dts/exynos4x12.dtsi
index c4a9306f8529..d57e3120223f 100644
--- a/arch/arm/boot/dts/exynos4x12.dtsi
+++ b/arch/arm/boot/dts/exynos4x12.dtsi
@@ -37,6 +37,16 @@
interrupts = 2 2, 3 2, 18 2, 19 2;
};
+ sysram@0202 {
+ compatible = samsung,exynos4210-sysram;
+ reg = 0x0202 0x1000;
+ };
+
+ sysram-ns@0204F000 {
+ compatible = samsung,exynos4210-sysram-ns;
+ reg = 0x0204F000 0x1000;
+ };
+
pd_isp: isp-power-domain@10023CA0 {
compatible = samsung,exynos4210-pd;
reg = 0x10023CA0 0x20;
diff --git a/arch/arm/boot/dts/exynos5.dtsi b/arch/arm/boot/dts/exynos5.dtsi
index 79d0608d6dcc..c03bd09ec37d 100644
--- a/arch/arm/boot/dts/exynos5.dtsi
+++ b/arch/arm/boot/dts/exynos5.dtsi
@@ -18,6 +18,11 @@
/ {
interrupt-parent = gic;
+ sysram@0202 {
+ compatible = samsung,exynos4210-sysram;
+ reg = 0x0202 0x1000;
+ };
+
chipid@1000 {
compatible = samsung,exynos4210-chipid;
reg = 0x1000 0x100;
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index 37423314a028..bae6c3f253f0 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -72,6 +72,11 @@
};
};
+ sysram-ns@0204F000 {
+ compatible = samsung,exynos4210-sysram-ns;
+ reg = 0x0204F000 0x1000;
+ };
+
pd_gsc:
[PATCH] arm: dts: exynos4: add missing pinctrls for I2C controllers
This patch adds missing pinctrls for I2C controllers 2-7. Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com --- arch/arm/boot/dts/exynos4.dtsi | 12 1 file changed, 12 insertions(+) diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi index 0401f4d..288aa81 100644 --- a/arch/arm/boot/dts/exynos4.dtsi +++ b/arch/arm/boot/dts/exynos4.dtsi @@ -357,6 +357,8 @@ interrupts = 0 60 0; clocks = clock CLK_I2C2; clock-names = i2c; + pinctrl-names = default; + pinctrl-0 = i2c2_bus; status = disabled; }; @@ -368,6 +370,8 @@ interrupts = 0 61 0; clocks = clock CLK_I2C3; clock-names = i2c; + pinctrl-names = default; + pinctrl-0 = i2c3_bus; status = disabled; }; @@ -379,6 +383,8 @@ interrupts = 0 62 0; clocks = clock CLK_I2C4; clock-names = i2c; + pinctrl-names = default; + pinctrl-0 = i2c4_bus; status = disabled; }; @@ -390,6 +396,8 @@ interrupts = 0 63 0; clocks = clock CLK_I2C5; clock-names = i2c; + pinctrl-names = default; + pinctrl-0 = i2c5_bus; status = disabled; }; @@ -401,6 +409,8 @@ interrupts = 0 64 0; clocks = clock CLK_I2C6; clock-names = i2c; + pinctrl-names = default; + pinctrl-0 = i2c6_bus; status = disabled; }; @@ -412,6 +422,8 @@ interrupts = 0 65 0; clocks = clock CLK_I2C7; clock-names = i2c; + pinctrl-names = default; + pinctrl-0 = i2c7_bus; status = disabled; }; -- 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] [media] s5p-mfc: Add support for resolution change event
From: Pawel Osciak posc...@chromium.org
When a resolution change point is reached, queue an event to signal the
userspace that a new set of buffers is required before decoding can
continue.
Signed-off-by: Pawel Osciak posc...@chromium.org
Signed-off-by: Arun Kumar K arun...@samsung.com
---
drivers/media/platform/s5p-mfc/s5p_mfc.c |6 ++
drivers/media/platform/s5p-mfc/s5p_mfc_dec.c |2 ++
2 files changed, 8 insertions(+)
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c
b/drivers/media/platform/s5p-mfc/s5p_mfc.c
index 4ee5a02..2efa758 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
@@ -308,6 +308,7 @@ static void s5p_mfc_handle_frame(struct s5p_mfc_ctx *ctx,
struct s5p_mfc_buf *src_buf;
unsigned long flags;
unsigned int res_change;
+ struct v4l2_event ev;
dst_frame_status = s5p_mfc_hw_call(dev-mfc_ops, get_dspl_status, dev)
S5P_FIMV_DEC_STATUS_DECODING_STATUS_MASK;
@@ -339,6 +340,11 @@ static void s5p_mfc_handle_frame(struct s5p_mfc_ctx *ctx,
if (ctx-state == MFCINST_RES_CHANGE_FLUSH) {
s5p_mfc_handle_frame_all_extracted(ctx);
ctx-state = MFCINST_RES_CHANGE_END;
+
+ memset(ev, 0, sizeof(struct v4l2_event));
+ ev.type = V4L2_EVENT_RESOLUTION_CHANGE;
+ v4l2_event_queue_fh(ctx-fh, ev);
+
goto leave_handle_frame;
} else {
s5p_mfc_handle_frame_all_extracted(ctx);
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
index 4586186..dd0ec6f 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
@@ -851,6 +851,8 @@ static int vidioc_subscribe_event(struct v4l2_fh *fh,
switch (sub-type) {
case V4L2_EVENT_EOS:
return v4l2_event_subscribe(fh, sub, 2, NULL);
+ case V4L2_EVENT_RESOLUTION_CHANGE:
+ return v4l2_event_subscribe(fh, sub, 2, NULL);
default:
return -EINVAL;
}
--
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] v4l: Add resolution change event.
From: Pawel Osciak posc...@chromium.org
This event indicates that the decoder has reached a point in the stream,
at which the resolution changes. The userspace is expected to provide a new
set of CAPTURE buffers for the new format before decoding can continue.
Signed-off-by: Pawel Osciak posc...@chromium.org
Signed-off-by: Arun Kumar K arun...@samsung.com
---
.../DocBook/media/v4l/vidioc-subscribe-event.xml |8
include/uapi/linux/videodev2.h |1 +
2 files changed, 9 insertions(+)
diff --git a/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml
b/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml
index 5c70b61..d848628 100644
--- a/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml
@@ -155,6 +155,14 @@
/entry
/row
row
+ entryconstantV4L2_EVENT_RESOLUTION_CHANGE/constant/entry
+ entry5/entry
+ entryThis event is triggered when a resolution change is detected
+ during runtime by the video decoder. Application may need to
+ reinitialize buffers before proceeding further.
+ /entry
+ /row
+ row
entryconstantV4L2_EVENT_PRIVATE_START/constant/entry
entry0x0800/entry
entryBase event number for driver-private events./entry
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 6ae7bbe..58488b7 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -1733,6 +1733,7 @@ struct v4l2_streamparm {
#define V4L2_EVENT_EOS 2
#define V4L2_EVENT_CTRL3
#define V4L2_EVENT_FRAME_SYNC 4
+#define V4L2_EVENT_RESOLUTION_CHANGE 5
#define V4L2_EVENT_PRIVATE_START 0x0800
/* Payload for V4L2_EVENT_VSYNC */
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] arm: dts: exynos4: add missing pinctrls for I2C controllers
Hi Tomasz, On 16.04.2014 14:40, Tomasz Stanislawski wrote: This patch adds missing pinctrls for I2C controllers 2-7. Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com --- arch/arm/boot/dts/exynos4.dtsi | 12 1 file changed, 12 insertions(+) diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi index 0401f4d..288aa81 100644 --- a/arch/arm/boot/dts/exynos4.dtsi +++ b/arch/arm/boot/dts/exynos4.dtsi @@ -357,6 +357,8 @@ interrupts = 0 60 0; clocks = clock CLK_I2C2; clock-names = i2c; + pinctrl-names = default; + pinctrl-0 = i2c2_bus; status = disabled; }; @@ -368,6 +370,8 @@ interrupts = 0 61 0; clocks = clock CLK_I2C3; clock-names = i2c; + pinctrl-names = default; + pinctrl-0 = i2c3_bus; status = disabled; }; @@ -379,6 +383,8 @@ interrupts = 0 62 0; clocks = clock CLK_I2C4; clock-names = i2c; + pinctrl-names = default; + pinctrl-0 = i2c4_bus; status = disabled; }; @@ -390,6 +396,8 @@ interrupts = 0 63 0; clocks = clock CLK_I2C5; clock-names = i2c; + pinctrl-names = default; + pinctrl-0 = i2c5_bus; status = disabled; }; @@ -401,6 +409,8 @@ interrupts = 0 64 0; clocks = clock CLK_I2C6; clock-names = i2c; + pinctrl-names = default; + pinctrl-0 = i2c6_bus; status = disabled; }; @@ -412,6 +422,8 @@ interrupts = 0 65 0; clocks = clock CLK_I2C7; clock-names = i2c; + pinctrl-names = default; + pinctrl-0 = i2c7_bus; status = disabled; }; Reviewed-by: Tomasz Figa t.f...@samsung.com -- Best regards, Tomasz -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V4 5/5] usb-phy: samsung-usb3: Remove older phy-samsung-usb3 driver
Hi Vivek, 2014-04-09 13:34 GMT+02:00 Vivek Gautam gautam.vi...@samsung.com: Hi Tomasz, ' On Wed, Apr 9, 2014 at 4:43 PM, Tomasz Figa t.f...@samsung.com wrote: Hi Vivek, Thanks for reviewing the patch series. On 08.04.2014 16:36, Vivek Gautam wrote: Removing this older USB 3.0 DRD controller PHY driver, since a new driver based on generic phy framework is now available. Also removing the dt node for older driver from Exynos5250 device tree and updating the dt node for DWC3 controller. Signed-off-by: Vivek Gautam gautam.vi...@samsung.com --- NOTE: This patch should be merged only when the new USB 3.0 DRD phy controller driver is available in the tree from the patches: phy: Add new Exynos5 USB 3.0 PHY driver; and dt: exynos5250: Enable support for generic USB DRD phy arch/arm/boot/dts/exynos5250.dtsi | 17 +- drivers/usb/phy/phy-samsung-usb.h | 83 - drivers/usb/phy/phy-samsung-usb3.c | 350 3 files changed, 2 insertions(+), 448 deletions(-) delete mode 100644 drivers/usb/phy/phy-samsung-usb3.c diff --git a/arch/arm/boot/dts/exynos5250.dtsi b/arch/arm/boot/dts/exynos5250.dtsi index 92c6fcd..1cb1e91 100644 --- a/arch/arm/boot/dts/exynos5250.dtsi +++ b/arch/arm/boot/dts/exynos5250.dtsi IMHO driver and dts changes should be separated into two patches, first updating device tree to use the new driver and second removing the driver. Sure will separate the patch into driver and dts change. After fixing this issue, Reviewed-by: Tomasz Figa t.f...@samsung.com I guess you should also remove phy-samsung-usb3.c references in the Makefile, Kconfig and exynos_defconfig Richard. -- 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 1/5] phy: Add new Exynos5 USB 3.0 PHY driver
Hi Vivek,
On 15.04.2014 08:09, Vivek Gautam wrote:
Hi Tomasz,
On Thu, Apr 10, 2014 at 5:09 PM, Vivek Gautam gautamvivek1...@gmail.com wrote:
On Wed, Apr 9, 2014 at 7:03 PM, Tomasz Figa t.f...@samsung.com wrote:
On 09.04.2014 13:49, Vivek Gautam wrote:
Hi,
On Wed, Apr 9, 2014 at 4:36 PM, Tomasz Figa t.f...@samsung.com wrote:
Hi Vivek,
Please see my comments inline.
On 08.04.2014 16:36, Vivek Gautam wrote:
Add a new driver for the USB 3.0 PHY on Exynos5 series of SoCs.
The new driver uses the generic PHY framework and will interact
with DWC3 controller present on Exynos5 series of SoCs.
Thereby, removing old phy-samsung-usb3 driver and related code
used untill now which was based on usb/phy framework.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
.../devicetree/bindings/phy/samsung-phy.txt| 42 ++
drivers/phy/Kconfig| 11 +
drivers/phy/Makefile |1 +
drivers/phy/phy-exynos5-usbdrd.c | 668
4 files changed, 722 insertions(+)
create mode 100644 drivers/phy/phy-exynos5-usbdrd.c
[snip]
+ Additional clock required for Exynos5420:
+ - usb30_sclk_100m: Additional special clock used for PHY
operation
+ depicted as 'sclk_usbphy30' in CMU of
Exynos5420.
Are you sure this isn't simply a gate for the ref clock, as it can be
found
on another SoC that is not upstream yet? I don't have documentation for
Exynos 5420 so I can't tell, but I'd like to ask you to recheck this.
From what i can see in the manual :
sclk_usbphy30 is derived from OSCCLK.
It is coming from a MUX (default input line to this is OSCCLK) and
then through a DIV
there's this gate.
{OSCCLK + other sources} ---[MUX] --- [DIV] -- [GATE for
sclk_usbphy30]
the {rate of sclk_usbphy30} == OSCCLK
However the 'ref' clock that we have been using is the actual oscillator
clock.
And on SoC Exynos5250, we don't have any such gate (sclk_usbphy30).
So should this mean that ref clock and sclk_usbphy30 are still be
controlled by
two different gates ?
Is there maybe a diagram of PHY input clocks in the datasheet, like for USB
2.0 PHY in Exynos4210/4412/5250 datasheets in the chapter about USB2.0
Device? Something like:
||
| ___|
XusbXTI | Phy_fsel[2:0]| ___ |
___[X]___|| __|_|___|\__|_|
| | _v___ | _ ^ | |/ | |
_ | | || | | | | ___ | |
___| | || | | | | | |_|_|
|___| | | X 0 ||_| PLL |__|_|_|CLK|_|_|
_ | | | | || |DIV|_|_|
|___[X] | |_| 12 |_|480 | |___| | |
| MHz MHz |Digital| |
XusbXTO | USB PHY|___| |
||
Below is the block diagram given for DRD controller.
___
||
| |
| | PHY | |
| | controller |-|---
| |__ | | |
||
|
| USB 3.0 | V
| DRD |
---
|Controller | |
|
||USB30_SCLK_100M| USB 3.0 DRD |
| | ---
| PHY |
| | Link cont. | | |
|
| - |
| |
|___| |_|
Does this help ?
So, USB30_SCLK_100M is the SCLK that we are talking in the driver. I
don't see any reference to XXTI in the USB 3.0 DRD controller chapter
(in both Exynos5250 and 5420)
In addition to this there's one more point to be noticed here.
On Exynos5420 system, the sclk_usbphy300 (which is the sclk_usbphy30
for USB DRD channel 0), is also the PICO phy clock, i.e. USB 2.0 phy
clock.
So we should add a similar clk_get() for this clock in the
phy-exynos5250-usb2 driver too, to support Exynos5420.
Is something clear from the above block diagram ? (although the
diagram looks weird - space and tabs problem :-( )
Basically there's the clock USB30_SCLK_100M which is going into the
USB 3.0 DRD PHY controller.
And this is the only sclk mentioned in the block diagram for USB 3.0
DRD controller in Exynos5420.
Same is not
Re: [PATCH 5/6] ARM: EXYNOS: Enable multi-platform build support
Hi Sachin, On 15.04.2014 11:28, Sachin Kamat wrote: From: Arnd Bergmann a...@arndb.de This makes it possible to enable the exynos platform as part of a multiplatform kernel, in addition to keeping the single-platform Exynos support. sparsemem is currently not supported in multiplatform. Is this still true as of today? Otherwise looks fine. Best regards, Tomasz -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/6] Further cleanup and enable multiplat build
Hi Sachin, On 15.04.2014 11:28, Sachin Kamat wrote: This series is based on latest linux-next and depends on the following patch: ARM: EXYNOS: Consolidate Kconfig entries http://article.gmane.org/gmane.linux.kernel.samsung-soc/28642 Changes since v2: Replaced patch 2, ARM: EXYNOS: Staticize exynos_subsys with ARM: EXYNOS: Remove exynos_subsys registration as that code is no more used. Tested on Exynos4210, 4412, 5250 and 5420 based boards. Arnd Bergmann (1): ARM: EXYNOS: Enable multi-platform build support Sachin Kamat (5): ARM: EXYNOS: Remove duplicate lines in Makefile ARM: EXYNOS: Remove exynos_subsys registration ARM: EXYNOS: Migrate Exynos specific macros from plat to mach ARM: EXYNOS: Remove unnecessary inclusion of cpu.h ARM: multi_v7_defconfig: Enable Exynos platform arch/arm/Kconfig | 27 ++- arch/arm/configs/exynos_defconfig|2 +- arch/arm/configs/multi_v7_defconfig | 10 + arch/arm/mach-exynos/Kconfig | 27 +++ arch/arm/mach-exynos/Makefile|9 ++-- arch/arm/mach-exynos/common.h| 72 ++ arch/arm/mach-exynos/cpuidle.c |1 - arch/arm/mach-exynos/exynos.c| 13 -- arch/arm/mach-exynos/hotplug.c |2 - arch/arm/mach-exynos/platsmp.c |2 - arch/arm/mach-exynos/pm.c|1 - arch/arm/mach-exynos/pmu.c |2 - arch/arm/plat-samsung/Makefile |3 ++ arch/arm/plat-samsung/include/plat/cpu.h | 61 - 14 files changed, 119 insertions(+), 113 deletions(-) For the whole series: Reviewed-by: Tomasz Figa t.f...@samsung.com -- Best regards, Tomasz -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] v4l: Add resolution change event.
Hi Arun,
Thank you for the patch.
On Wednesday 16 April 2014 18:29:21 Arun Kumar K wrote:
From: Pawel Osciak posc...@chromium.org
This event indicates that the decoder has reached a point in the stream,
at which the resolution changes. The userspace is expected to provide a new
set of CAPTURE buffers for the new format before decoding can continue.
Signed-off-by: Pawel Osciak posc...@chromium.org
Signed-off-by: Arun Kumar K arun...@samsung.com
---
.../DocBook/media/v4l/vidioc-subscribe-event.xml |8
include/uapi/linux/videodev2.h |1 +
2 files changed, 9 insertions(+)
diff --git a/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml
b/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml index
5c70b61..d848628 100644
--- a/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml
@@ -155,6 +155,14 @@
/entry
/row
row
+ entryconstantV4L2_EVENT_RESOLUTION_CHANGE/constant/entry
+ entry5/entry
+ entryThis event is triggered when a resolution change is detected
+ during runtime by the video decoder. Application may need to
+ reinitialize buffers before proceeding further.
+ /entry
+ /row
Would it make sense to report the new resolution in the event data ? I suppose
it might not be available in all cases though. If we can't report it, would it
make sense to document how applications should proceed to retrieve it ?
A similar resolution change event might be useful on subdevs, in which case we
would need to add a pad number to the event data. We could possibly leave that
for later, but it would be worth considering the problem already.
+ row
entryconstantV4L2_EVENT_PRIVATE_START/constant/entry
entry0x0800/entry
entryBase event number for driver-private events./entry
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 6ae7bbe..58488b7 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -1733,6 +1733,7 @@ struct v4l2_streamparm {
#define V4L2_EVENT_EOS 2
#define V4L2_EVENT_CTRL 3
#define V4L2_EVENT_FRAME_SYNC4
+#define V4L2_EVENT_RESOLUTION_CHANGE 5
#define V4L2_EVENT_PRIVATE_START 0x0800
/* Payload for V4L2_EVENT_VSYNC */
--
Regards,
Laurent Pinchart
--
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 RFC 3/4] xhci: Tune PHY for the DWC3-Exynos host controller
Hi,
On Tue, Apr 15, 2014 at 06:24:11PM +0530, Vivek Gautam wrote:
I had seen your patches in the mailing list, but i don't see any
updated version of these patches.
Are you planning to work on this above mentioned patch-series any time soon ?
I'm sorry, I forgot this completely. I have not prepared new version
of those patches as the drivers I need them for are not ready yet, but
I guess I can also use this case as justification for them.
Or, should i try to find a different approach for handling the phy
from the host controller (child of DWC3 in this case, which has the
phys).
Well, there is now an issue with the lookup method I'm suggesting in
this case. Since the device ID is now generated automatically for
xhci-hcd in dwc3, we don't know the xhci-hcd device name before
platform_device_add(), and that is too late. I don't see why the
device could not be named when platform_device_alloc() is called, so I
think I'll suggest something like the attached patch to fix this
issue.
In any case, I'll send an updated version of the phy patches soon.
Thanks,
--
heikki
diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index e714709..13f8edb 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -169,11 +169,47 @@ struct platform_object {
*/
void platform_device_put(struct platform_device *pdev)
{
- if (pdev)
- put_device(pdev-dev);
+ if (!pdev)
+ return;
+
+ if (pdev-id_auto) {
+ ida_simple_remove(platform_devid_ida, pdev-id);
+ pdev-id = PLATFORM_DEVID_AUTO;
+ }
+
+ put_device(pdev-dev);
}
EXPORT_SYMBOL_GPL(platform_device_put);
+static int pdev_set_name(struct platform_device *pdev)
+{
+ int ret;
+
+ switch (pdev-id) {
+ default:
+ dev_set_name(pdev-dev, %s.%d, pdev-name, pdev-id);
+ break;
+ case PLATFORM_DEVID_NONE:
+ dev_set_name(pdev-dev, %s, pdev-name);
+ break;
+ case PLATFORM_DEVID_AUTO:
+ /*
+ * Automatically allocated device ID. We mark it as such so
+ * that we remember it must be freed, and we append a suffix
+ * to avoid namespace collision with explicit IDs.
+ */
+ ret = ida_simple_get(platform_devid_ida, 0, 0, GFP_KERNEL);
+ if (ret 0)
+ return ret;
+ pdev-id = ret;
+ pdev-id_auto = true;
+ dev_set_name(pdev-dev, %s.%d.auto, pdev-name, pdev-id);
+ break;
+ }
+
+ return 0;
+}
+
static void platform_device_release(struct device *dev)
{
struct platform_object *pa = container_of(dev, struct platform_object,
@@ -206,6 +242,10 @@ struct platform_device *platform_device_alloc(const char *name, int id)
device_initialize(pa-pdev.dev);
pa-pdev.dev.release = platform_device_release;
arch_setup_pdev_archdata(pa-pdev);
+ if (pdev_set_name(pa-pdev)) {
+ kfree(pa);
+ return NULL;
+ }
}
return pa ? pa-pdev : NULL;
@@ -286,28 +326,6 @@ int platform_device_add(struct platform_device *pdev)
pdev-dev.bus = platform_bus_type;
- switch (pdev-id) {
- default:
- dev_set_name(pdev-dev, %s.%d, pdev-name, pdev-id);
- break;
- case PLATFORM_DEVID_NONE:
- dev_set_name(pdev-dev, %s, pdev-name);
- break;
- case PLATFORM_DEVID_AUTO:
- /*
- * Automatically allocated device ID. We mark it as such so
- * that we remember it must be freed, and we append a suffix
- * to avoid namespace collision with explicit IDs.
- */
- ret = ida_simple_get(platform_devid_ida, 0, 0, GFP_KERNEL);
- if (ret 0)
- goto err_out;
- pdev-id = ret;
- pdev-id_auto = true;
- dev_set_name(pdev-dev, %s.%d.auto, pdev-name, pdev-id);
- break;
- }
-
for (i = 0; i pdev-num_resources; i++) {
struct resource *p, *r = pdev-resource[i];
@@ -350,7 +368,6 @@ int platform_device_add(struct platform_device *pdev)
release_resource(r);
}
- err_out:
return ret;
}
EXPORT_SYMBOL_GPL(platform_device_add);
@@ -370,11 +387,6 @@ void platform_device_del(struct platform_device *pdev)
if (pdev) {
device_del(pdev-dev);
- if (pdev-id_auto) {
- ida_simple_remove(platform_devid_ida, pdev-id);
- pdev-id = PLATFORM_DEVID_AUTO;
- }
-
for (i = 0; i pdev-num_resources; i++) {
struct resource *r = pdev-resource[i];
unsigned long type = resource_type(r);
@@ -392,8 +404,15 @@ EXPORT_SYMBOL_GPL(platform_device_del);
*/
int platform_device_register(struct platform_device *pdev)
{
+ int ret;
+
device_initialize(pdev-dev);
arch_setup_pdev_archdata(pdev);
+
+ ret = pdev_set_name(pdev);
+ if (ret)
+ return ret;
+
return platform_device_add(pdev);
}
EXPORT_SYMBOL_GPL(platform_device_register);
Re: [PATCH 1/2] v4l: Add resolution change event.
On 04/16/2014 04:09 PM, Laurent Pinchart wrote:
Hi Arun,
Thank you for the patch.
On Wednesday 16 April 2014 18:29:21 Arun Kumar K wrote:
From: Pawel Osciak posc...@chromium.org
This event indicates that the decoder has reached a point in the stream,
at which the resolution changes. The userspace is expected to provide a new
set of CAPTURE buffers for the new format before decoding can continue.
Signed-off-by: Pawel Osciak posc...@chromium.org
Signed-off-by: Arun Kumar K arun...@samsung.com
---
.../DocBook/media/v4l/vidioc-subscribe-event.xml |8
include/uapi/linux/videodev2.h |1 +
2 files changed, 9 insertions(+)
diff --git a/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml
b/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml index
5c70b61..d848628 100644
--- a/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml
@@ -155,6 +155,14 @@
/entry
/row
row
+entryconstantV4L2_EVENT_RESOLUTION_CHANGE/constant/entry
+entry5/entry
+entryThis event is triggered when a resolution change is detected
+during runtime by the video decoder. Application may need to
+reinitialize buffers before proceeding further.
+/entry
+ /row
Would it make sense to report the new resolution in the event data ? I
suppose
it might not be available in all cases though. If we can't report it, would
it
make sense to document how applications should proceed to retrieve it ?
I wouldn't report that. We played with this in Cisco, and in the end you just
want to know something changed and you can take it from there. Besides, what
constitutes a 'resolution' change? If my HDMI input switches from 720p60 to
720p30 the resolution stays the same, but I most definitely have to get the new
timings.
So I would call the event something different: EVENT_SOURCE_CHANGE or something
like that.
Getting the new timings is done through QUERYSTD or QUERY_DV_TIMINGS.
A similar resolution change event might be useful on subdevs, in which case
we
would need to add a pad number to the event data. We could possibly leave
that
for later, but it would be worth considering the problem already.
Actually, I would add that right away. That's some thing that the adv7604
driver can implement right away: it has multiple inputs and it can detect
when something is plugged in or unplugged.
Regards,
Hans
+ row
entryconstantV4L2_EVENT_PRIVATE_START/constant/entry
entry0x0800/entry
entryBase event number for driver-private events./entry
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 6ae7bbe..58488b7 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -1733,6 +1733,7 @@ struct v4l2_streamparm {
#define V4L2_EVENT_EOS 2
#define V4L2_EVENT_CTRL 3
#define V4L2_EVENT_FRAME_SYNC 4
+#define V4L2_EVENT_RESOLUTION_CHANGE5
#define V4L2_EVENT_PRIVATE_START0x0800
/* Payload for V4L2_EVENT_VSYNC */
--
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: [PATCHv2 5/8] ARM: EXYNOS: Support secondary CPU boot of Exynos3250
Hi Chanwoo,
On 15.04.2014 03:59, Chanwoo Choi wrote:
This patch fix the offset of CPU boot address and don't operate smc call
of SMC_CMD_CPU1BOOT command for Exynos3250.
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
arch/arm/mach-exynos/firmware.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-exynos/firmware.c b/arch/arm/mach-exynos/firmware.c
index aa01c42..6205d4f 100644
--- a/arch/arm/mach-exynos/firmware.c
+++ b/arch/arm/mach-exynos/firmware.c
@@ -30,13 +30,16 @@ static int exynos_do_idle(void)
static int exynos_cpu_boot(int cpu)
{
+ if (soc_is_exynos3250()) {
+ return 0;
This is strange. How the firmware knows when to boot the CPU then, if
CPU1BOOT command is not called?
Best regards,
Tomasz
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/6] ARM: EXYNOS: Enable multi-platform build support
On Wednesday 16 April 2014 15:51:29 Tomasz Figa wrote: On 15.04.2014 11:28, Sachin Kamat wrote: From: Arnd Bergmann a...@arndb.de This makes it possible to enable the exynos platform as part of a multiplatform kernel, in addition to keeping the single-platform Exynos support. sparsemem is currently not supported in multiplatform. Is this still true as of today? Otherwise looks fine. sparsemem is still not supported in multiplatform, but after I looked at it in more detail, I came to the conclusion that there is no reason why it couldn't be. It just needs testing so we are confident that it doesn't break other platforms, and we need to find good platform-independent values for MAX_PHYSMEM_BITS and SECTION_SIZE_BITS to put into asm/memory.h, since we can't have them set in mach/memory.h for multiplatform. Looking at my patch again now, I would actually prefer to kill off the single-platform support for exynos right away. I don't see any reason to keep it now, and it complicates the test matrix. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/7] drm/panel: Add driver for exynos_dp based panels
This patch adds a simple driver to handle all the LCD and LED
powerup/down routines needed to support eDP/eDP-LVDS panels
supported on exynos boards.
Most of the eDP/LVDS panels need this sequence for powerup:
-- LCD unit powerup/LCD_EN
-- video data on
-- LED unit powerup/BL_EN
The LCD and LED units are usually powered up via regulators,
and almost on all boards, we will have a BL_EN pin to enable/
disable the backlight. Sometimes, we can have LCD_EN switches
as well. The routines in this driver can be used to control
panel power sequence on such boards.
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
---
.../devicetree/bindings/panel/exynos-dp-panel.txt | 32
drivers/gpu/drm/panel/Kconfig | 9 +
drivers/gpu/drm/panel/Makefile | 1 +
drivers/gpu/drm/panel/panel-exynos-dp.c| 213 +
4 files changed, 255 insertions(+)
create mode 100644 Documentation/devicetree/bindings/panel/exynos-dp-panel.txt
create mode 100644 drivers/gpu/drm/panel/panel-exynos-dp.c
diff --git a/Documentation/devicetree/bindings/panel/exynos-dp-panel.txt
b/Documentation/devicetree/bindings/panel/exynos-dp-panel.txt
new file mode 100644
index 000..a1428d2
--- /dev/null
+++ b/Documentation/devicetree/bindings/panel/exynos-dp-panel.txt
@@ -0,0 +1,32 @@
+exynos_DP_panel/DP_to_LVDS_panel
+==
+
+Required properties:
+ - compatible: samsung,exynos-dp-panel
+
+Optional properties:
+ -samsung,lcd-en-gpio:
+ eDP panel LCD poweron GPIO.
+ Indicates which GPIO needs to be powered up as output
+ to powerup/enable the switch to the LCD panel.
+ -samsung,led-en-gpio:
+ eDP panel LED enable GPIO.
+ Indicates which GPIO needs to be powered up as output
+ to enable the backlight.
+ -samsung,power-up-delay:
+ eDP panel powerup delay value in ms.
+ Delay in ms needed for the eDP panel to properly
+ powerup after giving powerup signals to the panel.
+ -samsung,power-down-delay:
+ eDP panel powerdown delay value in ms.
+ Delay in ms needed for the eDP panel to properly
+ powerdown after giving powerdown signals to the panel.
+
+Example:
+
+ dp-panel {
+ compatible = samsung,exynos-dp-panel;
+ samsung,led-en-gpio = gpx3 0 1;
+ samsung,power-up-delay = 40;
+ samsung,power-down-delay = 50;
+ };
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 4ec874d..ea9d5ac 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -30,4 +30,13 @@ config DRM_PANEL_S6E8AA0
select DRM_MIPI_DSI
select VIDEOMODE_HELPERS
+config DRM_PANEL_EXYNOS_DP
+ tristate support for DP panels
+ depends on OF DRM_PANEL DRM_EXYNOS_DP
+ help
+ DRM panel driver for DP panels and LVDS connected via DP bridges
+ that need at most a regulator for LCD unit, a regulator for LED unit
+ and/or enable GPIOs for LCD or LED units. Delay values can also be
+ specified to support powerup and powerdown process.
+
endmenu
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 8b92921..30311a4 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -1,3 +1,4 @@
obj-$(CONFIG_DRM_PANEL_SIMPLE) += panel-simple.o
obj-$(CONFIG_DRM_PANEL_LD9040) += panel-ld9040.o
obj-$(CONFIG_DRM_PANEL_S6E8AA0) += panel-s6e8aa0.o
+obj-$(CONFIG_DRM_PANEL_EXYNOS_DP) += panel-exynos-dp.o
diff --git a/drivers/gpu/drm/panel/panel-exynos-dp.c
b/drivers/gpu/drm/panel/panel-exynos-dp.c
new file mode 100644
index 000..e85a7b2
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-exynos-dp.c
@@ -0,0 +1,213 @@
+/*
+ * Exynos DP panel driver
+ *
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd
+ *
+ * Ajay Kumar ajaykumar...@samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/component.h
+#include linux/gpio.h
+#include linux/module.h
+#include linux/of_gpio.h
+#include linux/of_platform.h
+#include linux/platform_device.h
+#include linux/regulator/consumer.h
+
+#include drm/drmP.h
+#include drm/drm_crtc.h
+#include drm/drm_panel.h
+
+struct panel_exynos_dp {
+ struct drm_panelbase;
+ struct regulator*bck_fet;
+ struct regulator*lcd_fet;
+ int led_en_gpio;
+ int lcd_en_gpio;
+ int power_up_delay;
+ int power_down_delay;
+ boolenabled;
+};
+
+static
[PATCH 1/7] drm/exynos: dp: support hotplug detection via GPIO
From: Andrew Bresticker abres...@chromium.org
Certain bridge chips use a GPIO to indicate the cable status instead
of the I_DP_HPD pin. This adds an optional device-tree property,
samsung,hpd-gpio, to the exynos-dp controller which indicates that
the specified GPIO should be used for hotplug detection.
The GPIO is then set up as an edge-triggered interrupt where the
rising edge indicates hotplug-in and the falling edge indicates hotplug-out.
Signed-off-by: Andrew Bresticker abres...@chromium.org
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
---
.../devicetree/bindings/video/exynos_dp.txt| 4 +++
drivers/gpu/drm/exynos/exynos_dp_core.c| 32 --
drivers/gpu/drm/exynos/exynos_dp_core.h| 1 +
drivers/gpu/drm/exynos/exynos_dp_reg.c | 26 --
4 files changed, 57 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/video/exynos_dp.txt
b/Documentation/devicetree/bindings/video/exynos_dp.txt
index 57ccdde..53dbccf 100644
--- a/Documentation/devicetree/bindings/video/exynos_dp.txt
+++ b/Documentation/devicetree/bindings/video/exynos_dp.txt
@@ -62,6 +62,10 @@ Optional properties for dp-controller:
-hsync-active-high:
HSYNC polarity configuration.
High if defined, Low if not defined
+ -samsung,hpd-gpio:
+ Hotplug detect GPIO.
+ Indicates which GPIO should be used for hotplug
+ detection
Example:
diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c
b/drivers/gpu/drm/exynos/exynos_dp_core.c
index 1cc3981..18fd9c5 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -18,6 +18,8 @@
#include linux/interrupt.h
#include linux/delay.h
#include linux/of.h
+#include linux/of_gpio.h
+#include linux/gpio.h
#include linux/component.h
#include linux/phy/phy.h
#include video/of_display_timing.h
@@ -1226,6 +1228,7 @@ static int exynos_dp_bind(struct device *dev, struct
device *master, void *data)
struct drm_device *drm_dev = data;
struct resource *res;
struct exynos_dp_device *dp;
+ unsigned int irq_flags;
int ret = 0;
@@ -1265,7 +1268,30 @@ static int exynos_dp_bind(struct device *dev, struct
device *master, void *data)
if (IS_ERR(dp-reg_base))
return PTR_ERR(dp-reg_base);
- dp-irq = platform_get_irq(pdev, 0);
+ dp-hpd_gpio = of_get_named_gpio(dev-of_node, samsung,hpd-gpio, 0);
+
+ if (gpio_is_valid(dp-hpd_gpio)) {
+ /*
+* Set up the hotplug GPIO from the device tree as an interrupt.
+* Simply specifying a different interrupt in the device tree
+* doesn't work since we handle hotplug rather differently when
+* using a GPIO. We also need the actual GPIO specifier so
+* that we can get the current state of the GPIO.
+*/
+ ret = devm_gpio_request_one(pdev-dev, dp-hpd_gpio, GPIOF_IN,
+ hpd_gpio);
+ if (ret) {
+ dev_err(pdev-dev, failed to get hpd gpio\n);
+ return ret;
+ }
+ dp-irq = gpio_to_irq(dp-hpd_gpio);
+ irq_flags = IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING;
+ } else {
+ dp-hpd_gpio = -ENODEV;
+ dp-irq = platform_get_irq(pdev, 0);
+ irq_flags = 0;
+ }
+
if (dp-irq == -ENXIO) {
dev_err(pdev-dev, failed to get irq\n);
return -ENODEV;
@@ -1277,8 +1303,8 @@ static int exynos_dp_bind(struct device *dev, struct
device *master, void *data)
exynos_dp_init_dp(dp);
- ret = devm_request_irq(pdev-dev, dp-irq, exynos_dp_irq_handler, 0,
- exynos-dp, dp);
+ ret = devm_request_irq(pdev-dev, dp-irq, exynos_dp_irq_handler,
+ irq_flags, exynos-dp, dp);
if (ret) {
dev_err(pdev-dev, failed to request irq\n);
return ret;
diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.h
b/drivers/gpu/drm/exynos/exynos_dp_core.h
index d6a900d..56fa43e 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.h
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.h
@@ -159,6 +159,7 @@ struct exynos_dp_device {
struct work_struct hotplug_work;
struct phy *phy;
int dpms_mode;
+ int hpd_gpio;
struct exynos_drm_panel_info panel;
};
diff --git a/drivers/gpu/drm/exynos/exynos_dp_reg.c
b/drivers/gpu/drm/exynos/exynos_dp_reg.c
index b70da50..82475de 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_reg.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_reg.c
@@ -13,6 +13,7 @@
#include linux/device.h
#include
[PATCH 6/7] drm/bridge: ptn3460: enable polling based detection
From: Rahul Sharma rahul.sha...@samsung.com Add DRM_CONNECTOR_POLL_HPD to the set of connector flags while registering drm_connector for ptn3460. Signed-off-by: Rahul Sharma rahul.sha...@samsung.com Signed-off-by: Ajay Kumar ajaykumar...@samsung.com --- drivers/gpu/drm/bridge/ptn3460.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/bridge/ptn3460.c b/drivers/gpu/drm/bridge/ptn3460.c index b171901..f1d2afc 100644 --- a/drivers/gpu/drm/bridge/ptn3460.c +++ b/drivers/gpu/drm/bridge/ptn3460.c @@ -326,6 +326,7 @@ int ptn3460_init(struct drm_device *dev, struct drm_encoder *encoder, bridge-driver_private = ptn_bridge; encoder-bridge = bridge; + ptn_bridge-connector.polled = DRM_CONNECTOR_POLL_HPD; ret = drm_connector_init(dev, ptn_bridge-connector, ptn3460_connector_funcs, DRM_MODE_CONNECTOR_LVDS); -- 1.8.1.2 -- 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/7] drm/panel: add pre_enable routine to drm panel
Most of the panels need an init sequence as mentioned below:
-- poweron LCD unit/LCD_EN
-- start video data
-- poweron LED unit/BL_EN
With existing callbacks for drm panel, we cannot accomodate such
panels, since only one callback, i.e panel_enable is supported.
This patch adds a pre_enable callback which can be called before
the actual video data is on, and then call the enable callback
after the video data is available.
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
---
include/drm/drm_panel.h | 9 +
1 file changed, 9 insertions(+)
diff --git a/include/drm/drm_panel.h b/include/drm/drm_panel.h
index c2ab77a..89210bf 100644
--- a/include/drm/drm_panel.h
+++ b/include/drm/drm_panel.h
@@ -32,6 +32,7 @@ struct drm_panel;
struct drm_panel_funcs {
int (*disable)(struct drm_panel *panel);
+ int (*pre_enable)(struct drm_panel *panel);
int (*enable)(struct drm_panel *panel);
int (*get_modes)(struct drm_panel *panel);
};
@@ -54,6 +55,14 @@ static inline int drm_panel_disable(struct drm_panel *panel)
return panel ? -ENOSYS : -EINVAL;
}
+static inline int drm_panel_pre_enable(struct drm_panel *panel)
+{
+ if (panel panel-funcs panel-funcs-pre_enable)
+ return panel-funcs-pre_enable(panel);
+
+ return panel ? -ENOSYS : -EINVAL;
+}
+
static inline int drm_panel_enable(struct drm_panel *panel)
{
if (panel panel-funcs panel-funcs-enable)
--
1.8.1.2
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/7] drm/exynos: dp: modify driver to support drm_panel
This patch attaches the dp connector to exynos_dp_panel, and adds
calls to drm_panel functions to control panel power sequence.
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
---
drivers/gpu/drm/exynos/Kconfig | 1 +
drivers/gpu/drm/exynos/exynos_dp_core.c | 19 +++
drivers/gpu/drm/exynos/exynos_dp_core.h | 1 +
3 files changed, 21 insertions(+)
diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 5bf5bca..56af433 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -52,6 +52,7 @@ config DRM_EXYNOS_DP
bool EXYNOS DRM DP driver support
depends on DRM_EXYNOS ARCH_EXYNOS
default DRM_EXYNOS
+ select DRM_PANEL
help
This enables support for DP device.
diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c
b/drivers/gpu/drm/exynos/exynos_dp_core.c
index 18fd9c5..6beeab6 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -28,6 +28,7 @@
#include drm/drmP.h
#include drm/drm_crtc.h
#include drm/drm_crtc_helper.h
+#include drm/drm_panel.h
#include drm/bridge/ptn3460.h
#include exynos_drm_drv.h
@@ -1028,6 +1029,9 @@ static int exynos_dp_create_connector(struct
exynos_drm_display *display,
drm_sysfs_connector_add(connector);
drm_mode_connector_attach_encoder(connector, encoder);
+ if (dp-drm_panel)
+ drm_panel_attach(dp-drm_panel, dp-connector);
+
return 0;
}
@@ -1062,10 +1066,12 @@ static void exynos_dp_poweron(struct exynos_dp_device
*dp)
if (dp-dpms_mode == DRM_MODE_DPMS_ON)
return;
+ drm_panel_pre_enable(dp-drm_panel);
clk_prepare_enable(dp-clock);
exynos_dp_phy_init(dp);
exynos_dp_init_dp(dp);
enable_irq(dp-irq);
+ drm_panel_enable(dp-drm_panel);
}
static void exynos_dp_poweroff(struct exynos_dp_device *dp)
@@ -1073,6 +1079,7 @@ static void exynos_dp_poweroff(struct exynos_dp_device
*dp)
if (dp-dpms_mode != DRM_MODE_DPMS_ON)
return;
+ drm_panel_disable(dp-drm_panel);
disable_irq(dp-irq);
flush_work(dp-hotplug_work);
exynos_dp_phy_exit(dp);
@@ -1225,6 +1232,7 @@ static int exynos_dp_dt_parse_panel(struct
exynos_dp_device *dp)
static int exynos_dp_bind(struct device *dev, struct device *master, void
*data)
{
struct platform_device *pdev = to_platform_device(dev);
+ struct device_node *panel_node;
struct drm_device *drm_dev = data;
struct resource *res;
struct exynos_dp_device *dp;
@@ -1299,6 +1307,17 @@ static int exynos_dp_bind(struct device *dev, struct
device *master, void *data)
INIT_WORK(dp-hotplug_work, exynos_dp_hotplug);
+ panel_node = of_find_compatible_node(NULL, NULL,
+ samsung,exynos-dp-panel);
+ if (panel_node) {
+ dp-drm_panel = of_drm_find_panel(panel_node);
+ if (!dp-drm_panel) {
+ of_node_put(panel_node);
+ return -ENODEV;
+ }
+ of_node_put(panel_node);
+ }
+
exynos_dp_phy_init(dp);
exynos_dp_init_dp(dp);
diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.h
b/drivers/gpu/drm/exynos/exynos_dp_core.h
index 56fa43e..9dc7991 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.h
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.h
@@ -148,6 +148,7 @@ struct exynos_dp_device {
struct drm_device *drm_dev;
struct drm_connectorconnector;
struct drm_encoder *encoder;
+ struct drm_panel*drm_panel;
struct clk *clock;
unsigned intirq;
void __iomem*reg_base;
--
1.8.1.2
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/7] drm/exynos: add exynos_dp_panel driver registration to drm driver
Register exynos_dp_panel before the list of exynos crtcs and connectors are probed. This is needed because exynos_dp_panel should be registered to the drm_panel list via panel-exynos-dp probe, i.e much before exynos_dp_bind calls of_drm_find_panel(). Signed-off-by: Ajay Kumar ajaykumar...@samsung.com --- drivers/gpu/drm/exynos/exynos_drm_drv.c | 11 +++ drivers/gpu/drm/exynos/exynos_drm_drv.h | 1 + 2 files changed, 12 insertions(+) diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c b/drivers/gpu/drm/exynos/exynos_drm_drv.c index 1d1c604..47266e7 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c @@ -560,12 +560,23 @@ static int exynos_drm_platform_probe(struct platform_device *pdev) goto err_unregister_ipp; #endif +#ifdef CONFIG_DRM_PANEL_EXYNOS_DP + ret = platform_driver_register(exynos_dp_panel_driver); + if (ret 0) + goto err_unregister_dp_panel; +#endif + ret = component_master_add(pdev-dev, exynos_drm_ops); if (ret 0) DRM_DEBUG_KMS(re-tried by last sub driver probed later.\n); return 0; +#ifdef CONFIG_DRM_PANEL_EXYNOS_DP + platform_driver_unregister(exynos_dp_panel_driver); +err_unregister_dp_panel: +#endif + #ifdef CONFIG_DRM_EXYNOS_IPP exynos_platform_device_ipp_unregister(); err_unregister_ipp: diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h b/drivers/gpu/drm/exynos/exynos_drm_drv.h index 257ce09..f606290 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_drv.h +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h @@ -368,4 +368,5 @@ extern struct platform_driver fimc_driver; extern struct platform_driver rotator_driver; extern struct platform_driver gsc_driver; extern struct platform_driver ipp_driver; +extern struct platform_driver exynos_dp_panel_driver; #endif -- 1.8.1.2 -- 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 7/7] drm/bridge: ptn3460: add drm_panel controls
attach ptn3460 connector to drm_panel and support drm_panel routines,
if a valid drm_panel object is passed to ptn3460_init.
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
---
drivers/gpu/drm/bridge/Kconfig | 1 +
drivers/gpu/drm/bridge/ptn3460.c| 17 -
drivers/gpu/drm/exynos/exynos_dp_core.c | 15 +++
include/drm/bridge/ptn3460.h| 6 --
4 files changed, 32 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 884923f..3bc6845 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -2,4 +2,5 @@ config DRM_PTN3460
tristate PTN3460 DP/LVDS bridge
depends on DRM
select DRM_KMS_HELPER
+ select DRM_PANEL
---help---
diff --git a/drivers/gpu/drm/bridge/ptn3460.c b/drivers/gpu/drm/bridge/ptn3460.c
index f1d2afc..736c7a8 100644
--- a/drivers/gpu/drm/bridge/ptn3460.c
+++ b/drivers/gpu/drm/bridge/ptn3460.c
@@ -24,6 +24,7 @@
#include drm_edid.h
#include drm_crtc.h
#include drm_crtc_helper.h
+#include drm/drm_panel.h
#include bridge/ptn3460.h
@@ -38,6 +39,7 @@ struct ptn3460_bridge {
struct i2c_client *client;
struct drm_encoder *encoder;
struct drm_bridge *bridge;
+ struct drm_panel *panel;
struct edid *edid;
int gpio_pd_n;
int gpio_rst_n;
@@ -126,6 +128,8 @@ static void ptn3460_pre_enable(struct drm_bridge *bridge)
gpio_set_value(ptn_bridge-gpio_rst_n, 1);
}
+ drm_panel_pre_enable(ptn_bridge-panel);
+
/*
* There's a bug in the PTN chip where it falsely asserts hotplug before
* it is fully functional. We're forced to wait for the maximum start up
@@ -142,6 +146,9 @@ static void ptn3460_pre_enable(struct drm_bridge *bridge)
static void ptn3460_enable(struct drm_bridge *bridge)
{
+ struct ptn3460_bridge *ptn_bridge = bridge-driver_private;
+
+ drm_panel_enable(ptn_bridge-panel);
}
static void ptn3460_disable(struct drm_bridge *bridge)
@@ -153,6 +160,8 @@ static void ptn3460_disable(struct drm_bridge *bridge)
ptn_bridge-enabled = false;
+ drm_panel_disable(ptn_bridge-panel);
+
if (gpio_is_valid(ptn_bridge-gpio_rst_n))
gpio_set_value(ptn_bridge-gpio_rst_n, 1);
@@ -265,7 +274,8 @@ struct drm_connector_funcs ptn3460_connector_funcs = {
};
int ptn3460_init(struct drm_device *dev, struct drm_encoder *encoder,
- struct i2c_client *client, struct device_node *node)
+ struct i2c_client *client, struct device_node *node,
+ struct drm_panel *panel)
{
int ret;
struct drm_bridge *bridge;
@@ -324,6 +334,11 @@ int ptn3460_init(struct drm_device *dev, struct
drm_encoder *encoder,
goto err;
}
+ if (panel) {
+ ptn_bridge-panel = panel;
+ drm_panel_attach(ptn_bridge-panel, ptn_bridge-connector);
+ }
+
bridge-driver_private = ptn_bridge;
encoder-bridge = bridge;
ptn_bridge-connector.polled = DRM_CONNECTOR_POLL_HPD;
diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c
b/drivers/gpu/drm/exynos/exynos_dp_core.c
index 6beeab6..7f550b6 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -989,13 +989,14 @@ static bool find_bridge(const char *compat, struct
bridge_init *bridge)
/* returns the number of bridges attached */
static int exynos_drm_attach_lcd_bridge(struct drm_device *dev,
- struct drm_encoder *encoder)
+ struct drm_encoder *encoder, struct drm_panel *panel)
{
struct bridge_init bridge;
int ret;
if (find_bridge(nxp,ptn3460, bridge)) {
- ret = ptn3460_init(dev, encoder, bridge.client, bridge.node);
+ ret = ptn3460_init(dev, encoder, bridge.client, bridge.node,
+ panel);
if (!ret)
return 1;
}
@@ -1012,9 +1013,15 @@ static int exynos_dp_create_connector(struct
exynos_drm_display *display,
dp-encoder = encoder;
/* Pre-empt DP connector creation if there's a bridge */
- ret = exynos_drm_attach_lcd_bridge(dp-drm_dev, encoder);
- if (ret)
+ ret = exynos_drm_attach_lcd_bridge(dp-drm_dev, encoder, dp-drm_panel);
+ if (ret) {
+ /* Also set dp-drm_panel = NULL so that we don't end up
+* controlling panel power both in exynos_dp and bridge
+* DPMS routines.
+*/
+ dp-drm_panel = NULL;
return 0;
+ }
connector-polled = DRM_CONNECTOR_POLL_HPD;
diff --git a/include/drm/bridge/ptn3460.h b/include/drm/bridge/ptn3460.h
index ff62344..570cebb 100644
--- a/include/drm/bridge/ptn3460.h
+++ b/include/drm/bridge/ptn3460.h
@@ -18,16
[PATCH 0/7] drm: exynos: few patches to enhance bridge chip support
This series is based on exynos-drm-next-todo branch of Inki Dae's tree at: git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git This set of drm patches are needed to support bridge chips and eDP/LVDS panels with exynos_dp. For testing, I have used exynos5250-snow board along with a few local arch side patches. This patchset tries to create a simple exynos_dp panel framework to control power up/down sequence of the eDP/eDP-LVDS panel, and the same is used to control the panel power sequence for the LVDS panel on snow. Andrew Bresticker (1): [PATCH 1/7] drm/exynos: dp: support hotplug detection via GPIO Ajay Kumar (5): [PATCH 2/7] drm/panel: add pre_enable routine to drm panel [PATCH 3/7] drm/panel: Add driver for exynos_dp based panels [PATCH 4/7] drm/exynos: add exynos_dp_panel driver registration to drm driver [PATCH 5/7] drm/exynos: dp: modify driver to support drm_panel [PATCH 7/7] drm/bridge: ptn3460: add drm_panel controls Rahul Sharma (1): [PATCH 6/7] drm/bridge: ptn3460: enable polling based detection .../devicetree/bindings/panel/exynos-dp-panel.txt | 32 .../devicetree/bindings/video/exynos_dp.txt| 4 + drivers/gpu/drm/bridge/Kconfig | 1 + drivers/gpu/drm/bridge/ptn3460.c | 18 +- drivers/gpu/drm/exynos/Kconfig | 1 + drivers/gpu/drm/exynos/exynos_dp_core.c| 66 ++- drivers/gpu/drm/exynos/exynos_dp_core.h| 2 + drivers/gpu/drm/exynos/exynos_dp_reg.c | 26 ++- drivers/gpu/drm/exynos/exynos_drm_drv.c| 11 ++ drivers/gpu/drm/exynos/exynos_drm_drv.h| 1 + drivers/gpu/drm/panel/Kconfig | 9 + drivers/gpu/drm/panel/Makefile | 1 + drivers/gpu/drm/panel/panel-exynos-dp.c| 213 + include/drm/bridge/ptn3460.h | 6 +- include/drm/drm_panel.h| 9 + 15 files changed, 387 insertions(+), 13 deletions(-) create mode 100644 Documentation/devicetree/bindings/panel/exynos-dp-panel.txt create mode 100644 drivers/gpu/drm/panel/panel-exynos-dp.c -- 1.8.1.2 -- 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: [PATCHv2 6/8] ARM: EXYNOS: Enter a15 lowpower mode for Exynos3250 based on Cortex-a7
Hi Tomasz, On Wed, Apr 16, 2014 at 11:35 PM, Tomasz Figa t.f...@samsung.com wrote: Hi Chanwoo, On 15.04.2014 03:59, Chanwoo Choi wrote: This patch decide proper lowpower mode of either a15 or a9 according to own ID from Main ID register. Signed-off-by: Chanwoo Choi cw00.c...@samsung.com Acked-by: Kyungmin Park kyungmin.p...@samsung.com --- arch/arm/mach-exynos/hotplug.c | 16 +++- 1 file changed, 11 insertions(+), 5 deletions(-) diff --git a/arch/arm/mach-exynos/hotplug.c b/arch/arm/mach-exynos/hotplug.c index 5eead53..99e54e0 100644 --- a/arch/arm/mach-exynos/hotplug.c +++ b/arch/arm/mach-exynos/hotplug.c @@ -135,16 +135,22 @@ void __ref exynos_cpu_die(unsigned int cpu) int primary_part = 0; /* -* we're ready for shutdown now, so do it. -* Exynos4 is A9 based while Exynos5 is A15; check the CPU part +* we're ready for shutdown now, so do it. Exynos4 is A9 based +* while Exynos5 is A15/Exynos3 is A7; check the CPU part * number by reading the Main ID register and then perform the * appropriate sequence for entering low power. If changing this comment anyway, I'd suggest removing particular SoC series from it and also correct writing style. My suggestion is: OK, I'll fix it. Best regards, Chanwoo Choi /* * Prepare the CPU for shutting down. The required sequence of * operations depends on core type. CPUID part number can be used to * determine the right way. */ Best regards, Tomasz -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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 5/5] usb-phy: samsung-usb3: Remove older phy-samsung-usb3 driver
Hi Richard, On Wed, Apr 16, 2014 at 7:03 PM, Richard Genoud richard.gen...@gmail.com wrote: Hi Vivek, 2014-04-09 13:34 GMT+02:00 Vivek Gautam gautam.vi...@samsung.com: Hi Tomasz, ' On Wed, Apr 9, 2014 at 4:43 PM, Tomasz Figa t.f...@samsung.com wrote: Hi Vivek, Thanks for reviewing the patch series. On 08.04.2014 16:36, Vivek Gautam wrote: Removing this older USB 3.0 DRD controller PHY driver, since a new driver based on generic phy framework is now available. Also removing the dt node for older driver from Exynos5250 device tree and updating the dt node for DWC3 controller. Signed-off-by: Vivek Gautam gautam.vi...@samsung.com --- NOTE: This patch should be merged only when the new USB 3.0 DRD phy controller driver is available in the tree from the patches: phy: Add new Exynos5 USB 3.0 PHY driver; and dt: exynos5250: Enable support for generic USB DRD phy arch/arm/boot/dts/exynos5250.dtsi | 17 +- drivers/usb/phy/phy-samsung-usb.h | 83 - drivers/usb/phy/phy-samsung-usb3.c | 350 3 files changed, 2 insertions(+), 448 deletions(-) delete mode 100644 drivers/usb/phy/phy-samsung-usb3.c diff --git a/arch/arm/boot/dts/exynos5250.dtsi b/arch/arm/boot/dts/exynos5250.dtsi index 92c6fcd..1cb1e91 100644 --- a/arch/arm/boot/dts/exynos5250.dtsi +++ b/arch/arm/boot/dts/exynos5250.dtsi IMHO driver and dts changes should be separated into two patches, first updating device tree to use the new driver and second removing the driver. Sure will separate the patch into driver and dts change. After fixing this issue, Reviewed-by: Tomasz Figa t.f...@samsung.com I guess you should also remove phy-samsung-usb3.c references in the Makefile, Kconfig and exynos_defconfig You are correct. In fact i identified this issue once i submitted the patch :-( I have amended the things in my next series which i will be posting soon. Thanks Vivek -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/6] ARM: EXYNOS: Enable multi-platform build support
On 16.04.2014 16:31, Arnd Bergmann wrote: On Wednesday 16 April 2014 15:51:29 Tomasz Figa wrote: On 15.04.2014 11:28, Sachin Kamat wrote: From: Arnd Bergmann a...@arndb.de This makes it possible to enable the exynos platform as part of a multiplatform kernel, in addition to keeping the single-platform Exynos support. sparsemem is currently not supported in multiplatform. Is this still true as of today? Otherwise looks fine. sparsemem is still not supported in multiplatform, but after I looked at it in more detail, I came to the conclusion that there is no reason why it couldn't be. It just needs testing so we are confident that it doesn't break other platforms, and we need to find good platform-independent values for MAX_PHYSMEM_BITS and SECTION_SIZE_BITS to put into asm/memory.h, since we can't have them set in mach/memory.h for multiplatform. Looking at my patch again now, I would actually prefer to kill off the single-platform support for exynos right away. I don't see any reason to keep it now, and it complicates the test matrix. That would be the best option, assuming that it wouldn't introduce feature regressions. Unfortunately there is still ongoing work on cpufreq driver to make it multiplatform-aware, so dropping single platform support right now would introduce at least this one regression. Thomas, is there any progress on new version of Exynos cpufreq rework series? Best regards, Tomasz -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V4 1/5] phy: Add new Exynos5 USB 3.0 PHY driver
Hi,
On Wed, Apr 16, 2014 at 7:14 PM, Tomasz Figa t.f...@samsung.com wrote:
Hi Vivek,
On 15.04.2014 08:09, Vivek Gautam wrote:
Hi Tomasz,
On Thu, Apr 10, 2014 at 5:09 PM, Vivek Gautam gautamvivek1...@gmail.com
wrote:
On Wed, Apr 9, 2014 at 7:03 PM, Tomasz Figa t.f...@samsung.com wrote:
On 09.04.2014 13:49, Vivek Gautam wrote:
Hi,
On Wed, Apr 9, 2014 at 4:36 PM, Tomasz Figa t.f...@samsung.com wrote:
Hi Vivek,
Please see my comments inline.
On 08.04.2014 16:36, Vivek Gautam wrote:
Add a new driver for the USB 3.0 PHY on Exynos5 series of SoCs.
The new driver uses the generic PHY framework and will interact
with DWC3 controller present on Exynos5 series of SoCs.
Thereby, removing old phy-samsung-usb3 driver and related code
used untill now which was based on usb/phy framework.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
.../devicetree/bindings/phy/samsung-phy.txt| 42 ++
drivers/phy/Kconfig| 11 +
drivers/phy/Makefile |1 +
drivers/phy/phy-exynos5-usbdrd.c | 668
4 files changed, 722 insertions(+)
create mode 100644 drivers/phy/phy-exynos5-usbdrd.c
[snip]
+ Additional clock required for Exynos5420:
+ - usb30_sclk_100m: Additional special clock used for PHY
operation
+ depicted as 'sclk_usbphy30' in CMU of
Exynos5420.
Are you sure this isn't simply a gate for the ref clock, as it can be
found
on another SoC that is not upstream yet? I don't have documentation
for
Exynos 5420 so I can't tell, but I'd like to ask you to recheck this.
From what i can see in the manual :
sclk_usbphy30 is derived from OSCCLK.
It is coming from a MUX (default input line to this is OSCCLK) and
then through a DIV
there's this gate.
{OSCCLK + other sources} ---[MUX] --- [DIV] -- [GATE for
sclk_usbphy30]
the {rate of sclk_usbphy30} == OSCCLK
However the 'ref' clock that we have been using is the actual
oscillator
clock.
And on SoC Exynos5250, we don't have any such gate (sclk_usbphy30).
So should this mean that ref clock and sclk_usbphy30 are still be
controlled by
two different gates ?
Is there maybe a diagram of PHY input clocks in the datasheet, like for
USB
2.0 PHY in Exynos4210/4412/5250 datasheets in the chapter about USB2.0
Device? Something like:
||
| ___|
XusbXTI | Phy_fsel[2:0]| ___ |
___[X]___|| __|_|___|\__|_|
| | _v___ | _ ^ | |/ | |
_ | | || | | | | ___ | |
___| | || | | | | | |_|_|
|___| | | X 0 ||_| PLL |__|_|_|CLK|_|_|
_ | | | | || |DIV|_|_|
|___[X] | |_| 12 |_|480 | |___| | |
| MHz MHz |Digital| |
XusbXTO | USB PHY|___| |
||
Below is the block diagram given for DRD controller.
___
||
| |
| | PHY | |
| | controller
|-|---
| |__ | |
|
||
|
| USB 3.0 |
V
| DRD |
---
|Controller | |
|
||USB30_SCLK_100M| USB 3.0 DRD |
| | ---
| PHY |
| | Link cont. | | |
|
| - |
| |
|___| |_|
Does this help ?
So, USB30_SCLK_100M is the SCLK that we are talking in the driver. I
don't see any reference to XXTI in the USB 3.0 DRD controller chapter
(in both Exynos5250 and 5420)
In addition to this there's one more point to be noticed here.
On Exynos5420 system, the sclk_usbphy300 (which is the sclk_usbphy30
for USB DRD channel 0), is also the PICO phy clock, i.e. USB 2.0 phy
clock.
So we should add a similar clk_get() for this clock in the
phy-exynos5250-usb2 driver too, to support Exynos5420.
Is something clear from the above block diagram ? (although the
diagram looks weird - space and tabs problem :-( )
Basically there's the clock USB30_SCLK_100M which is going into the
USB 3.0 DRD PHY controller.
And this is the only sclk
Re: [PATCH 1/2] v4l: Add resolution change event.
Hi Laurent and Hans, Thank you for the review. On Wed, Apr 16, 2014 at 7:46 PM, Hans Verkuil hverk...@xs4all.nl wrote: On 04/16/2014 04:09 PM, Laurent Pinchart wrote: Hi Arun, Thank you for the patch. On Wednesday 16 April 2014 18:29:21 Arun Kumar K wrote: From: Pawel Osciak posc...@chromium.org This event indicates that the decoder has reached a point in the stream, at which the resolution changes. The userspace is expected to provide a new set of CAPTURE buffers for the new format before decoding can continue. Signed-off-by: Pawel Osciak posc...@chromium.org Signed-off-by: Arun Kumar K arun...@samsung.com --- .../DocBook/media/v4l/vidioc-subscribe-event.xml |8 include/uapi/linux/videodev2.h |1 + 2 files changed, 9 insertions(+) diff --git a/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml b/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml index 5c70b61..d848628 100644 --- a/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml +++ b/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml @@ -155,6 +155,14 @@ /entry /row row +entryconstantV4L2_EVENT_RESOLUTION_CHANGE/constant/entry +entry5/entry +entryThis event is triggered when a resolution change is detected +during runtime by the video decoder. Application may need to +reinitialize buffers before proceeding further. +/entry + /row Would it make sense to report the new resolution in the event data ? I suppose it might not be available in all cases though. If we can't report it, would it make sense to document how applications should proceed to retrieve it ? I wouldn't report that. We played with this in Cisco, and in the end you just want to know something changed and you can take it from there. Besides, what constitutes a 'resolution' change? If my HDMI input switches from 720p60 to 720p30 the resolution stays the same, but I most definitely have to get the new timings. So I would call the event something different: EVENT_SOURCE_CHANGE or something like that. Getting the new timings is done through QUERYSTD or QUERY_DV_TIMINGS. Ok will use the name V4L2_EVENT_SOURCE_CHANGE and update description to reflect the generic usecase (not just for video decoders). A similar resolution change event might be useful on subdevs, in which case we would need to add a pad number to the event data. We could possibly leave that for later, but it would be worth considering the problem already. Actually, I would add that right away. That's some thing that the adv7604 driver can implement right away: it has multiple inputs and it can detect when something is plugged in or unplugged. Ok will add support for mentioning pad number in event data. Regards Arun -- 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: [PATCHv2 6/8] ARM: EXYNOS: Enter a15 lowpower mode for Exynos3250 based on Cortex-a7
Hi Chanwoo, On 15.04.2014 03:59, Chanwoo Choi wrote: This patch decide proper lowpower mode of either a15 or a9 according to own ID from Main ID register. Signed-off-by: Chanwoo Choi cw00.c...@samsung.com Acked-by: Kyungmin Park kyungmin.p...@samsung.com --- arch/arm/mach-exynos/hotplug.c | 16 +++- 1 file changed, 11 insertions(+), 5 deletions(-) diff --git a/arch/arm/mach-exynos/hotplug.c b/arch/arm/mach-exynos/hotplug.c index 5eead53..99e54e0 100644 --- a/arch/arm/mach-exynos/hotplug.c +++ b/arch/arm/mach-exynos/hotplug.c @@ -135,16 +135,22 @@ void __ref exynos_cpu_die(unsigned int cpu) int primary_part = 0; /* -* we're ready for shutdown now, so do it. -* Exynos4 is A9 based while Exynos5 is A15; check the CPU part +* we're ready for shutdown now, so do it. Exynos4 is A9 based +* while Exynos5 is A15/Exynos3 is A7; check the CPU part * number by reading the Main ID register and then perform the * appropriate sequence for entering low power. If changing this comment anyway, I'd suggest removing particular SoC series from it and also correct writing style. My suggestion is: /* * Prepare the CPU for shutting down. The required sequence of * operations depends on core type. CPUID part number can be used to * determine the right way. */ Best regards, Tomasz -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/6] ARM: EXYNOS: Enable multi-platform build support
On Wed, Apr 16, 2014 at 8:18 PM, Tomasz Figa t.f...@samsung.com wrote: On 16.04.2014 16:31, Arnd Bergmann wrote: On Wednesday 16 April 2014 15:51:29 Tomasz Figa wrote: On 15.04.2014 11:28, Sachin Kamat wrote: From: Arnd Bergmann a...@arndb.de This makes it possible to enable the exynos platform as part of a multiplatform kernel, in addition to keeping the single-platform Exynos support. sparsemem is currently not supported in multiplatform. Is this still true as of today? Otherwise looks fine. sparsemem is still not supported in multiplatform, but after I looked at it in more detail, I came to the conclusion that there is no reason why it couldn't be. It just needs testing so we are confident that it doesn't break other platforms, and we need to find good platform-independent values for MAX_PHYSMEM_BITS and SECTION_SIZE_BITS to put into asm/memory.h, since we can't have them set in mach/memory.h for multiplatform. Looking at my patch again now, I would actually prefer to kill off the single-platform support for exynos right away. I don't see any reason to keep it now, and it complicates the test matrix. That would be the best option, assuming that it wouldn't introduce feature regressions. Unfortunately there is still ongoing work on cpufreq driver to make it multiplatform-aware, so dropping single platform support right now would introduce at least this one regression. Thomas, is there any progress on new version of Exynos cpufreq rework series? Hi Tomasz, Yes, I am preparing the fourth version of the cpufreq patches and will post it next week. Mostly, the changes will be addressing your review comments. Thanks, Thomas. Best regards, Tomasz -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH Resend] ARM: EXYNOS: Map SYSRAM address through DT
On Wednesday 16 April 2014 17:20:51 Sachin Kamat wrote:
Instead of hardcoding the SYSRAM details for each SoC,
pass this information through device tree (DT) and make
the code SoC agnostic.
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
---
Rebased on latest linux-next.
Thanks for sending this again. I'd like Heiko to have a look
and provide an Ack if he's happy with it.
It seems similar to what he did with the SRAM for mach-rockchip,
and if it is we should use the same binding that he introduced,
which would be a minor variation of this.
Arnd
.../devicetree/bindings/arm/samsung-boards.txt | 11 +++
arch/arm/boot/dts/exynos4210-universal_c210.dts|9 ++
arch/arm/boot/dts/exynos4210.dtsi | 10 ++
arch/arm/boot/dts/exynos4x12.dtsi | 10 ++
arch/arm/boot/dts/exynos5.dtsi |5 +
arch/arm/boot/dts/exynos5250.dtsi |5 +
arch/arm/boot/dts/exynos5420.dtsi |5 +
arch/arm/mach-exynos/exynos.c | 104
arch/arm/mach-exynos/include/mach/map.h|7 --
9 files changed, 95 insertions(+), 71 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/samsung-boards.txt
b/Documentation/devicetree/bindings/arm/samsung-boards.txt
index 2168ed31e1b0..f79710eb7e79 100644
--- a/Documentation/devicetree/bindings/arm/samsung-boards.txt
+++ b/Documentation/devicetree/bindings/arm/samsung-boards.txt
@@ -7,6 +7,17 @@ Required root node properties:
(a) samsung,smdkv310 - for Samsung's SMDKV310 eval board.
(b) samsung,exynos4210 - for boards based on Exynos4210 SoC.
+- sysram node, specifying the type (secure or non-secure) of SYSRAM
+ - compatible: following types are supported
+ samsung,exynos4210-sysram : Secure SYSRAM
+ samsung,exynos4210-sysram-ns : Non-secure SYSRAM
+ - reg: address of SYSRAM bank
+
+ sysram@0202 {
+ compatible = samsung,exynos4210-sysram;
+ reg = 0x0202 0x1000;
+ };
+
Optional:
- firmware node, specifying presence and type of secure firmware:
- compatible: only samsung,secure-firmware is currently supported
diff --git a/arch/arm/boot/dts/exynos4210-universal_c210.dts
b/arch/arm/boot/dts/exynos4210-universal_c210.dts
index 63e34b24b04f..cf4158728108 100644
--- a/arch/arm/boot/dts/exynos4210-universal_c210.dts
+++ b/arch/arm/boot/dts/exynos4210-universal_c210.dts
@@ -28,6 +28,15 @@
bootargs = console=ttySAC2,115200N8 root=/dev/mmcblk0p5 rw
rootwait earlyprintk panic=5 maxcpus=1;
};
+ sysram@0202 {
+ status = disabled;
+ };
+
+ sysram@02025000 {
+ compatible = samsung,exynos4210-sysram;
+ reg = 0x02025000 0x1000;
+ };
+
mct@1005 {
compatible = none;
};
diff --git a/arch/arm/boot/dts/exynos4210.dtsi
b/arch/arm/boot/dts/exynos4210.dtsi
index cacf6140dd2f..a3f4bba099e6 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -31,6 +31,16 @@
pinctrl2 = pinctrl_2;
};
+ sysram@0202 {
+ compatible = samsung,exynos4210-sysram;
+ reg = 0x0202 0x1000;
+ };
+
+ sysram-ns@0203F000 {
+ compatible = samsung,exynos4210-sysram-ns;
+ reg = 0x0203F000 0x1000;
+ };
+
pd_lcd1: lcd1-power-domain@10023CA0 {
compatible = samsung,exynos4210-pd;
reg = 0x10023CA0 0x20;
diff --git a/arch/arm/boot/dts/exynos4x12.dtsi
b/arch/arm/boot/dts/exynos4x12.dtsi
index c4a9306f8529..d57e3120223f 100644
--- a/arch/arm/boot/dts/exynos4x12.dtsi
+++ b/arch/arm/boot/dts/exynos4x12.dtsi
@@ -37,6 +37,16 @@
interrupts = 2 2, 3 2, 18 2, 19 2;
};
+ sysram@0202 {
+ compatible = samsung,exynos4210-sysram;
+ reg = 0x0202 0x1000;
+ };
+
+ sysram-ns@0204F000 {
+ compatible = samsung,exynos4210-sysram-ns;
+ reg = 0x0204F000 0x1000;
+ };
+
pd_isp: isp-power-domain@10023CA0 {
compatible = samsung,exynos4210-pd;
reg = 0x10023CA0 0x20;
diff --git a/arch/arm/boot/dts/exynos5.dtsi b/arch/arm/boot/dts/exynos5.dtsi
index 79d0608d6dcc..c03bd09ec37d 100644
--- a/arch/arm/boot/dts/exynos5.dtsi
+++ b/arch/arm/boot/dts/exynos5.dtsi
@@ -18,6 +18,11 @@
/ {
interrupt-parent = gic;
+ sysram@0202 {
+ compatible = samsung,exynos4210-sysram;
+ reg = 0x0202 0x1000;
+ };
+
chipid@1000 {
compatible = samsung,exynos4210-chipid;
reg = 0x1000 0x100;
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index 37423314a028..bae6c3f253f0 100644
---
Re: [PATCH 5/6] ARM: EXYNOS: Enable multi-platform build support
Hi Thomas, On 16.04.2014 16:55, Thomas Abraham wrote: On Wed, Apr 16, 2014 at 8:18 PM, Tomasz Figa t.f...@samsung.com wrote: On 16.04.2014 16:31, Arnd Bergmann wrote: On Wednesday 16 April 2014 15:51:29 Tomasz Figa wrote: On 15.04.2014 11:28, Sachin Kamat wrote: From: Arnd Bergmann a...@arndb.de This makes it possible to enable the exynos platform as part of a multiplatform kernel, in addition to keeping the single-platform Exynos support. sparsemem is currently not supported in multiplatform. Is this still true as of today? Otherwise looks fine. sparsemem is still not supported in multiplatform, but after I looked at it in more detail, I came to the conclusion that there is no reason why it couldn't be. It just needs testing so we are confident that it doesn't break other platforms, and we need to find good platform-independent values for MAX_PHYSMEM_BITS and SECTION_SIZE_BITS to put into asm/memory.h, since we can't have them set in mach/memory.h for multiplatform. Looking at my patch again now, I would actually prefer to kill off the single-platform support for exynos right away. I don't see any reason to keep it now, and it complicates the test matrix. That would be the best option, assuming that it wouldn't introduce feature regressions. Unfortunately there is still ongoing work on cpufreq driver to make it multiplatform-aware, so dropping single platform support right now would introduce at least this one regression. Thomas, is there any progress on new version of Exynos cpufreq rework series? Hi Tomasz, Yes, I am preparing the fourth version of the cpufreq patches and will post it next week. Mostly, the changes will be addressing your review comments. OK. Looking forward to it. Thanks for an update on this. Best regards, Tomasz -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv3 2/5] drm: exynos: hdmi: simplify extracting hpd-gpio from DT
This patch eliminates redundant checks while retrieving HPD gpio from DT during
HDMI's probe().
Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
---
drivers/gpu/drm/exynos/exynos_hdmi.c |7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 482ca77..176e764 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -2012,15 +2012,12 @@ fail:
static int drm_hdmi_dt_parse(struct hdmi_context *hdata, struct device_node
*np)
{
- u32 value;
-
- if (!of_find_property(np, hpd-gpio, value)) {
+ hdata-hpd_gpio = of_get_named_gpio(np, hpd-gpio, 0);
+ if (!gpio_is_valid(hdata-hpd_gpio)) {
DRM_ERROR(no hpd gpio property found\n);
return -ENOENT;
}
- hdata-hpd_gpio = of_get_named_gpio(np, hpd-gpio, 0);
-
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
[PATCHv3 0/5] drm: exynos: update/fixes to HDMI driver
Hi everyone, This patchset adds 5 fixes/updates to EXYNOS DRM driver for HDMI subsystem. All comments are welcome. Regards, Tomasz Stanislawski Changelog: v3: * remove usage of s5p_hdmi_platform_data * return MODE_CLOCK_HIGH instead of MODE_CLOCK_BAD v2: * fix check with gpio_is_valid() * use U32_MAX instead of ULONG_MAX to be 64-bit-friendly * use hdmi_driver_data as hdmi's compatile data v1: * initial version Tomasz Stanislawski (5): drm: exynos: hdmi: remove usage of struct s5p_hdmi_platform_data drm: exynos: hdmi: simplify extracting hpd-gpio from DT drm: exynos: mixer: fix using usleep() in atomic context drm: exynos: add compatibles for HDMI and Mixer chips and exynos4210 SoC drm: exynos: hdmi: add support for pixel clock limitation .../devicetree/bindings/video/exynos_hdmi.txt |4 ++ drivers/gpu/drm/exynos/exynos_hdmi.c | 49 ++-- drivers/gpu/drm/exynos/exynos_mixer.c |5 +- 3 files changed, 33 insertions(+), 25 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
[PATCHv3 3/5] drm: exynos: mixer: fix using usleep() in atomic context
This patch fixes calling usleep_range() after taking reg_slock using spin_lock_irqsave(). The mdelay() is used instead. Waiting in atomic context is not the best idea in general. Hopefully, waiting occurs only when Video Processor fails to reset correctly. Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com --- drivers/gpu/drm/exynos/exynos_mixer.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c b/drivers/gpu/drm/exynos/exynos_mixer.c index ce28881..e3306c8 100644 --- a/drivers/gpu/drm/exynos/exynos_mixer.c +++ b/drivers/gpu/drm/exynos/exynos_mixer.c @@ -615,7 +615,7 @@ static void vp_win_reset(struct mixer_context *ctx) /* waiting until VP_SRESET_PROCESSING is 0 */ if (~vp_reg_read(res, VP_SRESET) VP_SRESET_PROCESSING) break; - usleep_range(1, 12000); + mdelay(10); } WARN(tries == 0, failed to reset Video Processor\n); } -- 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
[PATCHv3 1/5] drm: exynos: hdmi: remove usage of struct s5p_hdmi_platform_data
This patch continues shift of DRM EXYNOS to DT-only configuration.
The usage of the old structure for HDMI's platform data is
removed.
Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 30 --
1 file changed, 8 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 9a6d652..482ca77 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -43,7 +43,6 @@
#include exynos_mixer.h
#include linux/gpio.h
-#include media/s5p_hdmi.h
#define get_hdmi_display(dev) platform_get_drvdata(to_platform_device(dev))
#define ctx_from_connector(c) container_of(c, struct hdmi_context, connector)
@@ -2011,28 +2010,18 @@ fail:
return -ENODEV;
}
-static struct s5p_hdmi_platform_data *drm_hdmi_dt_parse_pdata
- (struct device *dev)
+static int drm_hdmi_dt_parse(struct hdmi_context *hdata, struct device_node
*np)
{
- struct device_node *np = dev-of_node;
- struct s5p_hdmi_platform_data *pd;
u32 value;
- pd = devm_kzalloc(dev, sizeof(*pd), GFP_KERNEL);
- if (!pd)
- goto err_data;
-
if (!of_find_property(np, hpd-gpio, value)) {
DRM_ERROR(no hpd gpio property found\n);
- goto err_data;
+ return -ENOENT;
}
- pd-hpd_gpio = of_get_named_gpio(np, hpd-gpio, 0);
-
- return pd;
+ hdata-hpd_gpio = of_get_named_gpio(np, hpd-gpio, 0);
-err_data:
- return NULL;
+ return 0;
}
static struct of_device_id hdmi_match_types[] = {
@@ -2051,7 +2040,6 @@ static int hdmi_probe(struct platform_device *pdev)
{
struct device *dev = pdev-dev;
struct hdmi_context *hdata;
- struct s5p_hdmi_platform_data *pdata;
struct resource *res;
const struct of_device_id *match;
struct device_node *ddc_node, *phy_node;
@@ -2061,14 +2049,14 @@ static int hdmi_probe(struct platform_device *pdev)
if (!dev-of_node)
return -ENODEV;
- pdata = drm_hdmi_dt_parse_pdata(dev);
- if (!pdata)
- return -EINVAL;
-
hdata = devm_kzalloc(dev, sizeof(struct hdmi_context), GFP_KERNEL);
if (!hdata)
return -ENOMEM;
+ ret = drm_hdmi_dt_parse(hdata, dev-of_node);
+ if (ret)
+ return -EINVAL;
+
mutex_init(hdata-hdmi_mutex);
platform_set_drvdata(pdev, hdmi_display);
@@ -2079,8 +2067,6 @@ static int hdmi_probe(struct platform_device *pdev)
drv_data = (struct hdmi_driver_data *)match-data;
hdata-type = drv_data-type;
-
- hdata-hpd_gpio = pdata-hpd_gpio;
hdata-dev = dev;
ret = hdmi_resources_init(hdata);
--
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
[PATCHv3 5/5] drm: exynos: hdmi: add support for pixel clock limitation
Adds support for limitation of maximal pixel clock of HDMI
signal. This feature is needed on boards that contains
lines or bridges with frequency limitations.
Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
---
.../devicetree/bindings/video/exynos_hdmi.txt |4
drivers/gpu/drm/exynos/exynos_hdmi.c | 11 +++
2 files changed, 15 insertions(+)
diff --git a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
index f9187a2..8718f8d 100644
--- a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
+++ b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
@@ -28,6 +28,10 @@ Required properties:
- ddc: phandle to the hdmi ddc node
- phy: phandle to the hdmi phy node
+Optional properties:
+- max-pixel-clock: used to limit the maximal pixel clock if a board has lines,
+ connectors or bridges not capable of carring higher frequencies
+
Example:
hdmi {
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 9adbd34..e012ba9 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -194,6 +194,7 @@ struct hdmi_context {
struct hdmi_resources res;
int hpd_gpio;
+ u32 max_pixel_clock;
enum hdmi_type type;
};
@@ -886,6 +887,9 @@ static int hdmi_mode_valid(struct drm_connector *connector,
if (ret)
return MODE_BAD;
+ if (mode-clock * 1000 hdata-max_pixel_clock)
+ return MODE_CLOCK_HIGH;
+
ret = hdmi_find_phy_conf(hdata, mode-clock * 1000);
if (ret 0)
return MODE_BAD;
@@ -2022,6 +2026,13 @@ static int drm_hdmi_dt_parse(struct hdmi_context *hdata,
struct device_node *np)
return -ENOENT;
}
+ of_property_read_u32(np, max-pixel-clock, hdata-max_pixel_clock);
+ if (!hdata-max_pixel_clock) {
+ DRM_INFO(max-pixel-clock is zero, using INF\n);
+ hdata-max_pixel_clock = U32_MAX;
+ }
+
+
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
[PATCHv3 4/5] drm: exynos: add compatibles for HDMI and Mixer chips and exynos4210 SoC
This patch add proper compatibles for Mixer and HDMI chip
available on exynos4210 SoCs.
Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
---
drivers/gpu/drm/exynos/exynos_hdmi.c |7 +++
drivers/gpu/drm/exynos/exynos_mixer.c |3 +++
2 files changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 176e764..9adbd34 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -203,6 +203,10 @@ struct hdmiphy_config {
u8 conf[32];
};
+struct hdmi_driver_data exynos4210_hdmi_driver_data = {
+ .type = HDMI_TYPE13,
+};
+
struct hdmi_driver_data exynos4212_hdmi_driver_data = {
.type = HDMI_TYPE14,
};
@@ -2023,6 +2027,9 @@ static int drm_hdmi_dt_parse(struct hdmi_context *hdata,
struct device_node *np)
static struct of_device_id hdmi_match_types[] = {
{
+ .compatible = samsung,exynos4210-hdmi,
+ .data = exynos4210_hdmi_driver_data,
+ }, {
.compatible = samsung,exynos5-hdmi,
.data = exynos5_hdmi_driver_data,
}, {
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
b/drivers/gpu/drm/exynos/exynos_mixer.c
index e3306c8..fd8a9a0 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -1187,6 +1187,9 @@ static struct platform_device_id mixer_driver_types[] = {
static struct of_device_id mixer_match_types[] = {
{
+ .compatible = samsung,exynos4210-mixer,
+ .data = exynos4210_mxr_drv_data,
+ }, {
.compatible = samsung,exynos5-mixer,
.data = exynos5250_mxr_drv_data,
}, {
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH Resend] ARM: EXYNOS: Map SYSRAM address through DT
On Wed, Apr 16, 2014 at 6:50 AM, Sachin Kamat sachin.ka...@linaro.org wrote:
Instead of hardcoding the SYSRAM details for each SoC,
pass this information through device tree (DT) and make
the code SoC agnostic.
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
---
Rebased on latest linux-next.
---
.../devicetree/bindings/arm/samsung-boards.txt | 11 +++
arch/arm/boot/dts/exynos4210-universal_c210.dts|9 ++
arch/arm/boot/dts/exynos4210.dtsi | 10 ++
arch/arm/boot/dts/exynos4x12.dtsi | 10 ++
arch/arm/boot/dts/exynos5.dtsi |5 +
arch/arm/boot/dts/exynos5250.dtsi |5 +
arch/arm/boot/dts/exynos5420.dtsi |5 +
arch/arm/mach-exynos/exynos.c | 104
arch/arm/mach-exynos/include/mach/map.h|7 --
9 files changed, 95 insertions(+), 71 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/samsung-boards.txt
b/Documentation/devicetree/bindings/arm/samsung-boards.txt
index 2168ed31e1b0..f79710eb7e79 100644
--- a/Documentation/devicetree/bindings/arm/samsung-boards.txt
+++ b/Documentation/devicetree/bindings/arm/samsung-boards.txt
@@ -7,6 +7,17 @@ Required root node properties:
(a) samsung,smdkv310 - for Samsung's SMDKV310 eval board.
(b) samsung,exynos4210 - for boards based on Exynos4210 SoC.
+- sysram node, specifying the type (secure or non-secure) of SYSRAM
+ - compatible: following types are supported
+ samsung,exynos4210-sysram : Secure SYSRAM
+ samsung,exynos4210-sysram-ns : Non-secure SYSRAM
Base this on mmio-sram binding please.
+ - reg: address of SYSRAM bank
+
+ sysram@0202 {
+ compatible = samsung,exynos4210-sysram;
+ reg = 0x0202 0x1000;
+ };
+
Optional:
- firmware node, specifying presence and type of secure firmware:
- compatible: only samsung,secure-firmware is currently supported
diff --git a/arch/arm/boot/dts/exynos4210-universal_c210.dts
b/arch/arm/boot/dts/exynos4210-universal_c210.dts
index 63e34b24b04f..cf4158728108 100644
--- a/arch/arm/boot/dts/exynos4210-universal_c210.dts
+++ b/arch/arm/boot/dts/exynos4210-universal_c210.dts
@@ -28,6 +28,15 @@
bootargs = console=ttySAC2,115200N8 root=/dev/mmcblk0p5 rw
rootwait earlyprintk panic=5 maxcpus=1;
};
+ sysram@0202 {
+ status = disabled;
+ };
+
+ sysram@02025000 {
+ compatible = samsung,exynos4210-sysram;
+ reg = 0x02025000 0x1000;
+ };
+
mct@1005 {
compatible = none;
};
diff --git a/arch/arm/boot/dts/exynos4210.dtsi
b/arch/arm/boot/dts/exynos4210.dtsi
index cacf6140dd2f..a3f4bba099e6 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -31,6 +31,16 @@
pinctrl2 = pinctrl_2;
};
+ sysram@0202 {
+ compatible = samsung,exynos4210-sysram;
+ reg = 0x0202 0x1000;
+ };
+
+ sysram-ns@0203F000 {
+ compatible = samsung,exynos4210-sysram-ns;
+ reg = 0x0203F000 0x1000;
hex should be lower case.
[...]
@@ -268,6 +218,44 @@ static int __init exynos_fdt_map_chipid(unsigned long
node, const char *uname,
return 1;
}
+struct __sysram_desc {
+ char name[32];
+ unsigned long addr;
+};
+
+static struct __sysram_desc sysram_desc[] __initdata = {
+ {
+ .name = samsung,exynos4210-sysram,
+ .addr = (unsigned long)S5P_VA_SYSRAM,
+ }, {
+ .name = samsung,exynos4210-sysram-ns,
+ .addr = (unsigned long)S5P_VA_SYSRAM_NS,
+ },
+};
+
+static int __init exynos_fdt_map_sysram(unsigned long node, const char
*uname,
+ int depth, void *data)
+{
+ struct map_desc iodesc;
+ __be32 *reg;
+ unsigned long len;
+ int i;
+
+ for (i = 0; i ARRAY_SIZE(sysram_desc); i++) {
+ if (of_flat_dt_is_compatible(node, sysram_desc[i].name)) {
+ reg = of_get_flat_dt_prop(node, reg, len);
+ if (!reg || len != (sizeof(unsigned long) * 2))
+ return -ENODEV;
+ iodesc.virtual = sysram_desc[i].addr;
+ iodesc.pfn = __phys_to_pfn(be32_to_cpu(reg[0]));
+ iodesc.length = be32_to_cpu(reg[1]);
+ iodesc.type = MT_DEVICE;
+ iotable_init(iodesc, 1);
I don't think this needs to be a static mapping at all. Fix your SMP
code. Move the code setting the boot address in prepare_cpus to
boot_secondary.
Also, the pen code is all unnecessary if you can properly reset
Re: [PATCH 4/5] exynos4-is: Remove requirement for simple-bus compatible
On Tue, Apr 15, 2014 at 12:34 PM, Sylwester Nawrocki s.nawro...@samsung.com wrote: This patch makes the driver instantiating its child devices itself, rather than relying on an OS to instantiate devices as children of simple-bus. This removes an incorrect usage of simple-bus compatible. Good, but why can't you use of_platform_populate with the root being the samsung,fimc node? The code to instantiate the devices belongs in the core OF code. Rob -- 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/3] mfd: tps65090: Allow charger module to be used when no irq
Lee On Wed, Apr 16, 2014 at 2:52 AM, Lee Jones lee.jo...@linaro.org wrote: On the ARM Chromebook tps65090 has two masters: the AP (the main processor running linux) and the EC (the embedded controller). The AP is allowed to mess with FETs but the EC is in charge of charge control. The tps65090 interupt line is routed to both the AP and the EC, which can cause quite a headache. Having two people adjusting masks and acking interrupts is a recipe for disaster. In the shipping kernel we had a hack to have the AP pay attention to the IRQ but not to ack it. It also wasn't supposed to configure the IRQ in any way. That hack allowed us to detect when the device was charging without messing with the EC's state. The current tps65090 infrastructure makes the above difficult, and it was a bit of a hack to begin with. Rather than uglify the driver to support it, just extend the driver's existing notion of no irq to the charger. This makes the charger code poll every 2 seconds for AC detect, which is sufficient. Signed-off-by: Doug Anderson diand...@chromium.org --- drivers/mfd/tps65090.c | 14 ++-- drivers/power/tps65090-charger.c | 76 +++- 2 files changed, 70 insertions(+), 20 deletions(-) For the MFD part: Acked-by: Lee Jones lee.jo...@linaro.org Anton, If you are okay with this patch I'd be happy to create an immutable branch for you to pull from? Doug, What is the relationship (dependencies) between this and the other patches in the set? This patch can be applied irrespective of other others in the series. -Doug -- 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 01/27] ARM: EXYNOS: Add Exynos3250 SoC ID
Hi Chanwoo,
On 14.04.2014 07:13, Chanwoo Choi wrote:
On 04/11/2014 05:39 PM, Tomasz Figa wrote:
On 11.04.2014 08:32, Chanwoo Choi wrote:
On 04/11/2014 10:46 AM, Olof Johansson wrote:
On Thu, Apr 10, 2014 at 06:37:12PM +0900, Chanwoo Choi wrote:
diff --git a/arch/arm/plat-samsung/include/plat/cpu.h
b/arch/arm/plat-samsung/include/plat/cpu.h
index 5992b8d..3d808f6b 100644
--- a/arch/arm/plat-samsung/include/plat/cpu.h
+++ b/arch/arm/plat-samsung/include/plat/cpu.h
@@ -43,6 +43,9 @@ extern unsigned long samsung_cpu_id;
#define S5PV210_CPU_ID0x4311
#define S5PV210_CPU_MASK0xF000
+#define EXYNOS3250_SOC_ID 0xE3472000
+#define EXYNOS3_SOC_MASK0xF000
+
#define EXYNOS4210_CPU_ID0x4321
#define EXYNOS4212_CPU_ID0x4322
#define EXYNOS4412_CPU_ID0xE4412200
@@ -68,6 +71,7 @@ IS_SAMSUNG_CPU(s5p6440, S5P6440_CPU_ID, S5P64XX_CPU_MASK)
IS_SAMSUNG_CPU(s5p6450, S5P6450_CPU_ID, S5P64XX_CPU_MASK)
IS_SAMSUNG_CPU(s5pc100, S5PC100_CPU_ID, S5PC100_CPU_MASK)
IS_SAMSUNG_CPU(s5pv210, S5PV210_CPU_ID, S5PV210_CPU_MASK)
+IS_SAMSUNG_CPU(exynos3250, EXYNOS3250_SOC_ID, EXYNOS3_SOC_MASK)
IS_SAMSUNG_CPU(exynos4210, EXYNOS4210_CPU_ID, EXYNOS4_CPU_MASK)
IS_SAMSUNG_CPU(exynos4212, EXYNOS4212_CPU_ID, EXYNOS4_CPU_MASK)
IS_SAMSUNG_CPU(exynos4412, EXYNOS4412_CPU_ID, EXYNOS4_CPU_MASK)
@@ -126,6 +130,12 @@ IS_SAMSUNG_CPU(exynos5440, EXYNOS5440_SOC_ID,
EXYNOS5_SOC_MASK)
# define soc_is_s5pv210()0
#endif
+#if defined(CONFIG_SOC_EXYNOS3250)
+# define soc_is_exynos3250()is_samsung_exynos3250()
+#else
+# define soc_is_exynos3250()0
+#endif
In general, I think we have too much code littered with soc_is_foo() going
on, so please try to avoid adding more for this SoC. Especially in cases where
you just want to bail out of certain features where we might already have
function pointers to control if a function is called or not, such as the
firmware interfaces.
Do you prefer dt helper function such as following function instead of new
soc_is_xx() ?
- of_machine_is_compatible(samsung,exynos3250)
If you are OK, I'll use of_machine_is_compatible() instead of soc_is_xx().
First of all, there is still a lot of code in mach-exynos/ using the
soc_is_xx() macros, so having some SoCs use them and other SoCs use
of_machine_is_compatible() wouldn't make the code cleaner.
For now, I wouldn't mind adding soc_is_exynos3250(), but in general such code
surrounded with if (soc_is_xx()) blocks should be reworked to use something
better, for example function pointers, as Olof suggested.
I thought 'function pointers' method instead of soc_is_xxx() macro as following
two case:
I need more detailed explanation/example of for example function pointers, as Olof
suggested. sentence.
[case 1]
Each Exynos SoC has other function pointers according to compatible name of DT.
For example, arch/arm/mach-exynos/firmware.c
static const struct firmware_ops exynos_firmware_ops = {
.do_idle= exynos_do_idle,
.set_cpu_boot_addr = exynos_set_cpu_boot_addr,
.cpu_boot = exynos_cpu_boot,
};
static const struct firmware_ops exynos3250_firmware_ops = {
.do_idle= exynos_do_idle,
.set_cpu_boot_addr = exynos4212_set_cpu_boot_addr,
.cpu_boot = exynos3250_cpu_boot,
};
static const struct firmware_ops exynos4212_firmware_ops = {
.do_idle= exynos_do_idle,
.set_cpu_boot_addr = exynos4212_set_cpu_boot_addr,
.cpu_boot = exynos4212_cpu_boot,
};
struct secure_firmware {
char *name;
const struct firmware_ops *ops;
} exynos_secure_firmware[] __initconst = {
{ samsung,secure-firmware, exynos_firmware_ops },
{ samsung,exynos3250-secure-firmware, exynos3250_firmware_ops },
{ samsung,exynos4212-secure-firmware, exynos4212_firmware_ops },
};
This is probably the right solution. Another would be to detect which
firmware ops to use by matching root node with particular SoC compatible
strings.
Best regards,
Tomasz
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] mfd: tps65090: Allow charger module to be used when no irq
On the ARM Chromebook tps65090 has two masters: the AP (the main processor running linux) and the EC (the embedded controller). The AP is allowed to mess with FETs but the EC is in charge of charge control. The tps65090 interupt line is routed to both the AP and the EC, which can cause quite a headache. Having two people adjusting masks and acking interrupts is a recipe for disaster. In the shipping kernel we had a hack to have the AP pay attention to the IRQ but not to ack it. It also wasn't supposed to configure the IRQ in any way. That hack allowed us to detect when the device was charging without messing with the EC's state. The current tps65090 infrastructure makes the above difficult, and it was a bit of a hack to begin with. Rather than uglify the driver to support it, just extend the driver's existing notion of no irq to the charger. This makes the charger code poll every 2 seconds for AC detect, which is sufficient. Signed-off-by: Doug Anderson diand...@chromium.org --- drivers/mfd/tps65090.c | 14 ++-- drivers/power/tps65090-charger.c | 76 +++- 2 files changed, 70 insertions(+), 20 deletions(-) For the MFD part: Acked-by: Lee Jones lee.jo...@linaro.org Anton, If you are okay with this patch I'd be happy to create an immutable branch for you to pull from? Doug, What is the relationship (dependencies) between this and the other patches in the set? This patch can be applied irrespective of other others in the series. What about the files in the patch? Could you make two separate patches from this one patch and it would still compile okay? I'm _guessing_ the answer is yes? -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/6] PCI: tegra: use new OF interrupt mapping when possible
On Wed, Apr 16, 2014 at 10:20:45AM +0200, Lucas Stach wrote: Am Dienstag, den 15.04.2014, 12:30 -0600 schrieb Bjorn Helgaas: On Tue, Apr 15, 2014 at 12:07:34PM +0200, Lucas Stach wrote: Hi Bjorn, Am Freitag, den 04.04.2014, 10:55 -0600 schrieb Bjorn Helgaas: On Wed, Mar 05, 2014 at 02:25:47PM +0100, Lucas Stach wrote: This is the recommended method of doing the IRQ mapping. For old devicetrees we fall back to the previous practice. Signed-off-by: Lucas Stach l.st...@pengutronix.de Acked-by: Arnd Bergmann a...@arndb.de Applied with Stephen's Tested-by to my pending/host-tegra branch. I'll rebase and rename it after v3.15-rc1, and I think we can squeeze it into v3.15 shortly after that. Thanks. Are you still planning to push this into 3.15, or has this slipped to 3.16? Yes, I'm hoping to put them in v3.15. I assume these actually fix something, e.g., we need these changes to boot with new devicetrees, or something? The changelogs don't make it clear that these are fixes, and I want to heed Linus' guidance: Anyway, because -rc1 is already pretty darn big, I do *not* want to hear about 'sorry this missed the window, can I still sneak in'. Fixes only. I should have applied these sooner to make the merge window; I apologize for that. Anyway, if you outline what these fix, I'll update the changelogs in my tree. Actually they are a bit on the fence. The i.MX and thus the designware patch actually fixes wrong behavior, where all PCI legacy interrupts would be mapped to a single GIC interrupt, which would leave INT B,C,D nonfunctional on i.MX. The others only make DT interrupt mapping functional for all drivers, so they would be useful if you need to remap interrupts across bridges or something. But apparently nobody had the need to to this on platforms other than i.MX until now, so those patches only fix a theoretical issue. It sounds like the others should fix real problems; it's just that nobody has actually tested relevant configurations yet. I think that's fair game, so I updated the changelogs and put them in my for-linus branch for v3.15. This includes the designware, rcar, and tegra patches. Bjorn -- 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 Resend] ARM: EXYNOS: Map SYSRAM address through DT
Hi,
Am Mittwoch, 16. April 2014, 16:35:36 schrieb Arnd Bergmann:
On Wednesday 16 April 2014 17:20:51 Sachin Kamat wrote:
Instead of hardcoding the SYSRAM details for each SoC,
pass this information through device tree (DT) and make
the code SoC agnostic.
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
---
Rebased on latest linux-next.
Thanks for sending this again. I'd like Heiko to have a look
and provide an Ack if he's happy with it.
It seems similar to what he did with the SRAM for mach-rockchip,
and if it is we should use the same binding that he introduced,
which would be a minor variation of this.
The sram binding is derived from the generic reserved-memory bindings to
enable the sram in general to be used generically through the sram driver,
while still retaining some areas for special purposes, like the smp-trampoline
in my case.
From my reading of platsmp.c, it looks like offset+0x4 starts the so called
boot-registesr, which get the smp-start-address written to.
So I guess it all depends on what is contained in the rest of the sysram. If
it is all covered with such special registers or other special uses, the code
below is fine. But if the most of the area is just general purpose sram, a
solution like on rockchip might be nicer - i.e. handling the sysram via the
sram driver and declaring a reserved section for the boot registers.
So, depending on the above:
Acked-by: Heiko Stuebner he...@sntech.de
Heiko
Arnd
.../devicetree/bindings/arm/samsung-boards.txt | 11 +++
arch/arm/boot/dts/exynos4210-universal_c210.dts|9 ++
arch/arm/boot/dts/exynos4210.dtsi | 10 ++
arch/arm/boot/dts/exynos4x12.dtsi | 10 ++
arch/arm/boot/dts/exynos5.dtsi |5 +
arch/arm/boot/dts/exynos5250.dtsi |5 +
arch/arm/boot/dts/exynos5420.dtsi |5 +
arch/arm/mach-exynos/exynos.c | 104
arch/arm/mach-exynos/include/mach/map.h
|7 --
9 files changed, 95 insertions(+), 71 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/samsung-boards.txt
b/Documentation/devicetree/bindings/arm/samsung-boards.txt index
2168ed31e1b0..f79710eb7e79 100644
--- a/Documentation/devicetree/bindings/arm/samsung-boards.txt
+++ b/Documentation/devicetree/bindings/arm/samsung-boards.txt
@@ -7,6 +7,17 @@ Required root node properties:
(a) samsung,smdkv310 - for Samsung's SMDKV310 eval board.
(b) samsung,exynos4210 - for boards based on Exynos4210 SoC.
+- sysram node, specifying the type (secure or non-secure) of SYSRAM
+ - compatible: following types are supported
+ samsung,exynos4210-sysram : Secure SYSRAM
+ samsung,exynos4210-sysram-ns : Non-secure SYSRAM
+ - reg: address of SYSRAM bank
+
+ sysram@0202 {
+ compatible = samsung,exynos4210-sysram;
+ reg = 0x0202 0x1000;
+ };
+
Optional:
- firmware node, specifying presence and type of secure firmware:
- compatible: only samsung,secure-firmware is currently
supported
diff --git a/arch/arm/boot/dts/exynos4210-universal_c210.dts
b/arch/arm/boot/dts/exynos4210-universal_c210.dts index
63e34b24b04f..cf4158728108 100644
--- a/arch/arm/boot/dts/exynos4210-universal_c210.dts
+++ b/arch/arm/boot/dts/exynos4210-universal_c210.dts
@@ -28,6 +28,15 @@
bootargs = console=ttySAC2,115200N8 root=/dev/mmcblk0p5 rw
rootwait
earlyprintk panic=5 maxcpus=1;
};
+ sysram@0202 {
+ status = disabled;
+ };
+
+ sysram@02025000 {
+ compatible = samsung,exynos4210-sysram;
+ reg = 0x02025000 0x1000;
+ };
+
mct@1005 {
compatible = none;
};
diff --git a/arch/arm/boot/dts/exynos4210.dtsi
b/arch/arm/boot/dts/exynos4210.dtsi index cacf6140dd2f..a3f4bba099e6
100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -31,6 +31,16 @@
pinctrl2 = pinctrl_2;
};
+ sysram@0202 {
+ compatible = samsung,exynos4210-sysram;
+ reg = 0x0202 0x1000;
+ };
+
+ sysram-ns@0203F000 {
+ compatible = samsung,exynos4210-sysram-ns;
+ reg = 0x0203F000 0x1000;
+ };
+
pd_lcd1: lcd1-power-domain@10023CA0 {
compatible = samsung,exynos4210-pd;
reg = 0x10023CA0 0x20;
diff --git a/arch/arm/boot/dts/exynos4x12.dtsi
b/arch/arm/boot/dts/exynos4x12.dtsi index c4a9306f8529..d57e3120223f
100644
--- a/arch/arm/boot/dts/exynos4x12.dtsi
+++ b/arch/arm/boot/dts/exynos4x12.dtsi
@@ -37,6 +37,16 @@
interrupts = 2 2, 3 2, 18 2, 19 2;
};
+ sysram@0202
Re: [PATCH 1/3] mfd: tps65090: Allow charger module to be used when no irq
Lee, On Wed, Apr 16, 2014 at 9:26 AM, Lee Jones lee.jo...@linaro.org wrote: On the ARM Chromebook tps65090 has two masters: the AP (the main processor running linux) and the EC (the embedded controller). The AP is allowed to mess with FETs but the EC is in charge of charge control. The tps65090 interupt line is routed to both the AP and the EC, which can cause quite a headache. Having two people adjusting masks and acking interrupts is a recipe for disaster. In the shipping kernel we had a hack to have the AP pay attention to the IRQ but not to ack it. It also wasn't supposed to configure the IRQ in any way. That hack allowed us to detect when the device was charging without messing with the EC's state. The current tps65090 infrastructure makes the above difficult, and it was a bit of a hack to begin with. Rather than uglify the driver to support it, just extend the driver's existing notion of no irq to the charger. This makes the charger code poll every 2 seconds for AC detect, which is sufficient. Signed-off-by: Doug Anderson diand...@chromium.org --- drivers/mfd/tps65090.c | 14 ++-- drivers/power/tps65090-charger.c | 76 +++- 2 files changed, 70 insertions(+), 20 deletions(-) For the MFD part: Acked-by: Lee Jones lee.jo...@linaro.org Anton, If you are okay with this patch I'd be happy to create an immutable branch for you to pull from? Doug, What is the relationship (dependencies) between this and the other patches in the set? This patch can be applied irrespective of other others in the series. What about the files in the patch? Could you make two separate patches from this one patch and it would still compile okay? I'm _guessing_ the answer is yes? Yes, they'll compile and even boot on their own. I just tested it. If I put only the MFD part in, then at boot I see: tps65090-charger tps65090-charger: Unable to get charger irq = -6 ...but otherwise the system functions. If I put only the charger part in, then at boot: tps65090-charger tps65090-charger: Unable to register irq 1 err -22 tps65090-charger: probe of tps65090-charger failed with error -22 ...so you need both patches in order to make things function, but they can be applied separately. I'll assume it will make your life easier if I split this into two patches so I'll do that. -Doug -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/6] ARM: EXYNOS: Enable multi-platform build support
On Wednesday 16 April 2014 16:58:43 Tomasz Figa wrote: On 16.04.2014 16:55, Thomas Abraham wrote: On Wed, Apr 16, 2014 at 8:18 PM, Tomasz Figa t.f...@samsung.com wrote: On 16.04.2014 16:31, Arnd Bergmann wrote: sparsemem is still not supported in multiplatform, but after I looked at it in more detail, I came to the conclusion that there is no reason why it couldn't be. It just needs testing so we are confident that it doesn't break other platforms, and we need to find good platform-independent values for MAX_PHYSMEM_BITS and SECTION_SIZE_BITS to put into asm/memory.h, since we can't have them set in mach/memory.h for multiplatform. Looking at my patch again now, I would actually prefer to kill off the single-platform support for exynos right away. I don't see any reason to keep it now, and it complicates the test matrix. That would be the best option, assuming that it wouldn't introduce feature regressions. Unfortunately there is still ongoing work on cpufreq driver to make it multiplatform-aware, so dropping single platform support right now would introduce at least this one regression. Thomas, is there any progress on new version of Exynos cpufreq rework series? Hi Tomasz, Yes, I am preparing the fourth version of the cpufreq patches and will post it next week. Mostly, the changes will be addressing your review comments. OK. Looking forward to it. Thanks for an update on this. Cool! This is the only major issue I'm aware of, so I think we're good. If SPARSEMEM support is still relevant to anybody, I'm sure we can get that to work as well. There is one small issue with the sound drivers that came up, and I assume it was just a mistake. If not, some more work on that might be needed. See patch below. Arnd 8--- From 6f3921c3218509114e855a8ea5932aeea5d3ddfd Mon Sep 17 00:00:00 2001 From: Arnd Bergmann a...@arndb.de Date: Tue, 18 Mar 2014 17:04:59 +0100 Subject: [PATCH] ASoC: samsung: don't build pcm and spdif on exynos In commit d37bdf736d9b ASoC: samsung: Use ASoC dmaengine code where possible, Mark Brown changed the EXYNOS ASoC code to no longer use the private dma interfaces that are standing in the way of multiplatform enablement. However, in 313367e7bfa ASoC: Samsung: Update Kconfig for I2S,SPDIF and PCM audio, two new users of that interface appeared, since it is now possible to enable SND_SOC_SAMSUNG_SMDK_SPDIF and SND_SOC_SMDK_WM8994_PCM on all Samsung SoCs including EXYNOS. This patch does a partial revert of 313367e7bfa by allowing these drivers on all samsung platforms except EXYNOS, so we can proceed with the multiplatform patches. If support for these drivers is actually needed on EXYNOS machines, the drivers should first be moved over to use the dmaengine code. Signed-off-by: Arnd Bergmann a...@arndb.de Cc: Sangsu Park sangsu4u.p...@samsung.com Cc: Sangbeom Kim sbki...@samsung.com Cc: Padmavathi Venna padm...@samsung.com Cc: Mark Brown broo...@kernel.org diff --git a/sound/soc/samsung/Kconfig b/sound/soc/samsung/Kconfig index 7b610a8..efc01e0 100644 --- a/sound/soc/samsung/Kconfig +++ b/sound/soc/samsung/Kconfig @@ -167,7 +167,7 @@ config SND_SOC_GONI_AQUILA_WM8994 config SND_SOC_SAMSUNG_SMDK_SPDIF tristate SoC S/PDIF Audio support for SMDK - depends on SND_SOC_SAMSUNG + depends on SND_SOC_SAMSUNG !ARCH_EXYNOS select SND_SAMSUNG_SPDIF help Say Y if you want to add support for SoC S/PDIF audio on the SMDK. @@ -183,7 +183,7 @@ config SND_SOC_SMDK_WM8580_PCM config SND_SOC_SMDK_WM8994_PCM tristate SoC PCM Audio support for WM8994 on SMDK - depends on SND_SOC_SAMSUNG + depends on SND_SOC_SAMSUNG !ARCH_EXYNOS depends on I2C=y select MFD_WM8994 select SND_SOC_WM8994 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/5] charger: tps65090: Allow charger module to be used when no irq
On the ARM Chromebook tps65090 has two masters: the AP (the main
processor running linux) and the EC (the embedded controller). The AP
is allowed to mess with FETs but the EC is in charge of charge control.
The tps65090 interupt line is routed to both the AP and the EC, which
can cause quite a headache. Having two people adjusting masks and
acking interrupts is a recipe for disaster.
In the shipping kernel we had a hack to have the AP pay attention to
the IRQ but not to ack it. It also wasn't supposed to configure the
IRQ in any way. That hack allowed us to detect when the device was
charging without messing with the EC's state.
The current tps65090 infrastructure makes the above difficult, and it
was a bit of a hack to begin with. Rather than uglify the driver to
support it, just extend the driver's existing notion of no irq to
the charger. This makes the charger code poll every 2 seconds for AC
detect, which is sufficient.
For proper functioning, requires (mfd: tps65090: Don't tell child
devices we have an IRQ if we don't). If we don't have that patch
we'll simply fail to probe on devices without an interrupt (just like
we did before this patch).
Signed-off-by: Doug Anderson diand...@chromium.org
---
Changes in v2:
- Split noirq (polling mode) changes into MFD and charger
drivers/power/tps65090-charger.c | 76 +++-
1 file changed, 59 insertions(+), 17 deletions(-)
diff --git a/drivers/power/tps65090-charger.c b/drivers/power/tps65090-charger.c
index 8fc9d6d..cc26c12 100644
--- a/drivers/power/tps65090-charger.c
+++ b/drivers/power/tps65090-charger.c
@@ -17,9 +17,11 @@
*/
#include linux/delay.h
#include linux/err.h
+#include linux/freezer.h
#include linux/init.h
#include linux/interrupt.h
#include linux/kernel.h
+#include linux/kthread.h
#include linux/module.h
#include linux/of_device.h
#include linux/platform_device.h
@@ -43,11 +45,15 @@
#define TPS65090_VACG BIT(1)
#define TPS65090_NOITERM BIT(5)
+#define POLL_INTERVAL (HZ * 2)/* Used when no irq */
+
struct tps65090_charger {
struct device *dev;
int ac_online;
int prev_ac_online;
int irq;
+ struct task_struct *poll_task;
+ boolpassive_mode;
struct power_supply ac;
struct tps65090_platform_data *pdata;
};
@@ -60,6 +66,9 @@ static int tps65090_low_chrg_current(struct tps65090_charger
*charger)
{
int ret;
+ if (charger-passive_mode)
+ return 0;
+
ret = tps65090_write(charger-dev-parent, TPS65090_REG_CG_CTRL5,
TPS65090_NOITERM);
if (ret 0) {
@@ -75,6 +84,9 @@ static int tps65090_enable_charging(struct tps65090_charger
*charger)
int ret;
uint8_t ctrl0 = 0;
+ if (charger-passive_mode)
+ return 0;
+
ret = tps65090_read(charger-dev-parent, TPS65090_REG_CG_CTRL0,
ctrl0);
if (ret 0) {
@@ -98,6 +110,9 @@ static int tps65090_config_charger(struct tps65090_charger
*charger)
uint8_t intrmask = 0;
int ret;
+ if (charger-passive_mode)
+ return 0;
+
if (charger-pdata-enable_low_current_chrg) {
ret = tps65090_low_chrg_current(charger);
if (ret 0) {
@@ -175,10 +190,14 @@ static irqreturn_t tps65090_charger_isr(int irq, void
*dev_id)
}
/* Clear interrupts. */
- ret = tps65090_write(charger-dev-parent, TPS65090_REG_INTR_STS, 0x00);
- if (ret 0) {
- dev_err(charger-dev, %s(): Error in writing reg 0x%x\n,
+ if (!charger-passive_mode) {
+ ret = tps65090_write(charger-dev-parent,
+TPS65090_REG_INTR_STS, 0x00);
+ if (ret 0) {
+ dev_err(charger-dev,
+ %s(): Error in writing reg 0x%x\n,
__func__, TPS65090_REG_INTR_STS);
+ }
}
if (charger-prev_ac_online != charger-ac_online)
@@ -209,6 +228,18 @@ static struct tps65090_platform_data *
}
+static int tps65090_charger_poll_task(void *data)
+{
+ set_freezable();
+
+ while (!kthread_should_stop()) {
+ schedule_timeout_interruptible(POLL_INTERVAL);
+ try_to_freeze();
+ tps65090_charger_isr(-1, data);
+ }
+ return 0;
+}
+
static int tps65090_charger_probe(struct platform_device *pdev)
{
struct tps65090_charger *cdata;
@@ -255,22 +286,10 @@ static int tps65090_charger_probe(struct platform_device
*pdev)
}
irq = platform_get_irq(pdev, 0);
- if (irq = 0) {
- dev_warn(pdev-dev, Unable to get charger irq = %d\n, irq);
- ret = irq;
- goto fail_unregister_supply;
- }
-
+ if (irq 0)
+ irq = NO_IRQ;
[PATCH v2 0/5] Fixes for tps65090 for Samsung ARM Chromebook
These five patches bring tps65090 up to speed with what's currently in the Chromium OS kernel 3.8 tree and running on the Samsung ARM Chromebook. Changes were tested atop the current linux tree (v3.15-rc1). FET retries were tested on a machine with a known flaky tps65090. Since display isn't working on pure upstream, I augmented the code to turn FET1 (vcd_led) on/off 500 times at bootup. When testing I included https://patchwork.kernel.org/patch/3980731/ to make sure tps65090 was in exynos5250-snow's device tree. Dependencies: - Patch #1 (mfd no irq) has no dependencies, though patch #2 won't work without it. - Patch #2 (charger polling) can be applied without patch #1 but won't actually make charger polling work without it. - Patch #3 (caching) can be applied before retries patch but not after. - Patch #4 (overcurrent wait time) can be applied before retries patch but not after (just due to merge conflicts, no other reason). - Patch #5 (retries) absolutely requires patch #3 (caching). Changes in v2: - Split noirq (polling mode) changes into MFD and charger - Leave cache on for the registers that can be cached. - Move register offsets to mfd header file. - Separated the overcurrent and retries changes into two patches. - Now set overcurrent at probe time since it doesn't change. - Separated the overcurrent and retries changes into two patches. - No longer open code fet_is_enabled(). - Fixed tps6090 typo. - For loop = while true. - Removed a set of braces. Doug Anderson (5): mfd: tps65090: Don't tell child devices we have an IRQ if we don't charger: tps65090: Allow charger module to be used when no irq mfd: tps65090: Stop caching most registers regulator: tps65090: Allow setting the overcurrent wait time regulator: tps65090: Make FETs more reliable by adding retries .../devicetree/bindings/regulator/tps65090.txt | 4 + drivers/mfd/tps65090.c | 41 ++-- drivers/power/tps65090-charger.c | 87 ++--- drivers/regulator/tps65090-regulator.c | 208 +++-- include/linux/mfd/tps65090.h | 19 ++ 5 files changed, 300 insertions(+), 59 deletions(-) -- 1.9.1.423.g4596e3a -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 3/5] mfd: tps65090: Stop caching most registers
Nearly all of the registers in tps65090 combine control bits and
status bits. Turn off caching of all registers except the select few
that can be cached.
In order to avoid adding more duplicate #defines, we also move some
register offset definitions to the mfd driver (and resolve
inconsistent names).
Signed-off-by: Doug Anderson diand...@chromium.org
---
Changes in v2:
- Leave cache on for the registers that can be cached.
- Move register offsets to mfd header file.
drivers/mfd/tps65090.c | 27 ++-
drivers/power/tps65090-charger.c | 11 ---
include/linux/mfd/tps65090.h | 14 ++
3 files changed, 28 insertions(+), 24 deletions(-)
diff --git a/drivers/mfd/tps65090.c b/drivers/mfd/tps65090.c
index c3cddb4..1c3e6e2 100644
--- a/drivers/mfd/tps65090.c
+++ b/drivers/mfd/tps65090.c
@@ -32,14 +32,6 @@
#define NUM_INT_REG 2
#define TOTAL_NUM_REG 0x18
-/* interrupt status registers */
-#define TPS65090_INT_STS 0x0
-#define TPS65090_INT_STS2 0x1
-
-/* interrupt mask registers */
-#define TPS65090_INT_MSK 0x2
-#define TPS65090_INT_MSK2 0x3
-
#define TPS65090_INT1_MASK_VAC_STATUS_CHANGE 1
#define TPS65090_INT1_MASK_VSYS_STATUS_CHANGE 2
#define TPS65090_INT1_MASK_BAT_STATUS_CHANGE 3
@@ -144,17 +136,26 @@ static struct regmap_irq_chip tps65090_irq_chip = {
.irqs = tps65090_irqs,
.num_irqs = ARRAY_SIZE(tps65090_irqs),
.num_regs = NUM_INT_REG,
- .status_base = TPS65090_INT_STS,
- .mask_base = TPS65090_INT_MSK,
+ .status_base = TPS65090_REG_INTR_STS,
+ .mask_base = TPS65090_REG_INTR_MASK,
.mask_invert = true,
};
static bool is_volatile_reg(struct device *dev, unsigned int reg)
{
- if ((reg == TPS65090_INT_STS) || (reg == TPS65090_INT_STS2))
- return true;
- else
+ /* Nearly all registers have status bits mixed in, except a few */
+ switch (reg) {
+ case TPS65090_REG_INTR_MASK:
+ case TPS65090_REG_INTR_MASK2:
+ case TPS65090_REG_CG_CTRL0:
+ case TPS65090_REG_CG_CTRL1:
+ case TPS65090_REG_CG_CTRL2:
+ case TPS65090_REG_CG_CTRL3:
+ case TPS65090_REG_CG_CTRL4:
+ case TPS65090_REG_CG_CTRL5:
return false;
+ }
+ return true;
}
static const struct regmap_config tps65090_regmap_config = {
diff --git a/drivers/power/tps65090-charger.c b/drivers/power/tps65090-charger.c
index cc26c12..31a3ba4 100644
--- a/drivers/power/tps65090-charger.c
+++ b/drivers/power/tps65090-charger.c
@@ -30,17 +30,6 @@
#include linux/mfd/tps65090.h
-#define TPS65090_REG_INTR_STS 0x00
-#define TPS65090_REG_INTR_MASK 0x02
-#define TPS65090_REG_CG_CTRL0 0x04
-#define TPS65090_REG_CG_CTRL1 0x05
-#define TPS65090_REG_CG_CTRL2 0x06
-#define TPS65090_REG_CG_CTRL3 0x07
-#define TPS65090_REG_CG_CTRL4 0x08
-#define TPS65090_REG_CG_CTRL5 0x09
-#define TPS65090_REG_CG_STATUS10x0a
-#define TPS65090_REG_CG_STATUS20x0b
-
#define TPS65090_CHARGER_ENABLEBIT(0)
#define TPS65090_VACG BIT(1)
#define TPS65090_NOITERM BIT(5)
diff --git a/include/linux/mfd/tps65090.h b/include/linux/mfd/tps65090.h
index 3f43069..45f0f9d 100644
--- a/include/linux/mfd/tps65090.h
+++ b/include/linux/mfd/tps65090.h
@@ -64,6 +64,20 @@ enum {
TPS65090_REGULATOR_MAX,
};
+/* Register addresses */
+#define TPS65090_REG_INTR_STS 0x00
+#define TPS65090_REG_INTR_STS2 0x01
+#define TPS65090_REG_INTR_MASK 0x02
+#define TPS65090_REG_INTR_MASK20x03
+#define TPS65090_REG_CG_CTRL0 0x04
+#define TPS65090_REG_CG_CTRL1 0x05
+#define TPS65090_REG_CG_CTRL2 0x06
+#define TPS65090_REG_CG_CTRL3 0x07
+#define TPS65090_REG_CG_CTRL4 0x08
+#define TPS65090_REG_CG_CTRL5 0x09
+#define TPS65090_REG_CG_STATUS10x0a
+#define TPS65090_REG_CG_STATUS20x0b
+
struct tps65090 {
struct device *dev;
struct regmap *rmap;
--
1.9.1.423.g4596e3a
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] regulator: tps65090: Make FETs more reliable
Mark,
On Tue, Apr 15, 2014 at 3:52 PM, Mark Brown broo...@kernel.org wrote:
On Tue, Apr 15, 2014 at 01:14:36PM -0700, Doug Anderson wrote:
Mitigate the problem by:
* Allow setting the overcurrent wait time so devices with this problem
can set it to the max.
* Add retry logic on enables of FETs.
This is two changes, should really be two patches.
OK, sure.
+- ti,overcurrent-wait: This is applicable to FET registers, which have a
+ poorly defined overcurrent wait field. If this property is present it
+ should be between 0 - 3. If this property isn't present we won't touch
the
+ overcurrent wait field and we'll leave it to the BIOS/EC to deal with.
I take it this is the raw value to write to the register?
Yes.
+static int tps65090_fet_is_enabled(struct regulator_dev *rdev)
+{
+ unsigned int control;
+ unsigned int expected = rdev-desc-enable_mask | BIT(CTRL_PG_BIT);
+ int ret;
+
+ ret = regmap_read(rdev-regmap, rdev-desc-enable_reg, control);
+ if (ret != 0)
+ return ret;
+
+ return (control expected) == expected;
+}
No need to open code this, regulator_is_enabled_regmap() can check for
any value in a bitfield.
The overall problem was that we were checking a different bit than we
were setting. We set enabled to turn things on and then we check
power good.
I can avoid the open coding by doing something that's slightly a hack.
I'll put that in V2 and you can tell me if you like it better. I'll
set enable_mask and enable_val to include both bits. The power
good is read only so it won't hurt to set it. ...and it doesn't hurt
to check the enabled bit in addition to the power good bit.
+static int tps6090_try_enable_fet(struct regulator_dev *rdev)
Why is this called tps6090_try_enable_fet(), looks like a missing 5?
typo. fixed.
+ /*
+ * Try enabling multiple times until we succeed since sometimes the
+ * first try times out.
+ */
+ for (tries = 0; ; tries++) {
+ ret = tps6090_try_enable_fet(rdev);
+ if (!ret)
+ break;
+ if (ret != -ENOTRECOVERABLE || tries == MAX_FET_ENABLE_TRIES)
+ goto err;
Make this a do { } while so we don't have the exit condition missing in
the for loop please, it's doing the right thing but it's not as obvious
as it could be.
It's not quite a do { } while since the break is in the middle, but
happy to change to a while (true). Hope that's OK.
+ if (tries) {
+ dev_warn(rdev-dev, reg %#x enable ok after %d tries\n,
+ rdev-desc-enable_reg, tries);
+ }
No need for braces here, and I guess that ought to be retries rather
than tries (though that is pedantry).
LOL. I've been yelled at for the opposite. ;) There's at least
someone out there who thinks that we should have braces if you've got
a single statement like this that wraps to two lines, but I can't
remember who.
In any case, fixed.
-Doug
--
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/3] mfd: tps65090: Stop caching registers
Mark,
On Wed, Apr 16, 2014 at 3:13 AM, Mark Brown broo...@kernel.org wrote:
On Wed, Apr 16, 2014 at 10:59:22AM +0100, Lee Jones wrote:
NOTE: the IRQnMASK and CG_CTRLn registers are the exception and could
be cached. If we find that we spend a lot of time reading those we
can turn on cache for just those registers.
-static bool is_volatile_reg(struct device *dev, unsigned int reg)
-{
- if ((reg == TPS65090_INT_STS) || (reg == TPS65090_INT_STS2))
- return true;
- else
- return false;
-}
-
I don't know enough about Regmap internals to know what this actually
affects in real terms.
Mark,
Does this change seem sane to you?
It does what it says, it stops us caching stuff. It would seem better
to do what the changelog suggests above and keep caching the registers
that can be cached - especially the interrupt masks, they should get
read in the interrupt path and that tends to be a bit latency sensitive.
Done
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 4/5] regulator: tps65090: Allow setting the overcurrent wait time
The tps65090 regulator allows you to specify how long you want it to
wait before detecting an overcurrent condition. Allow specifying that
through the device tree (or through platform data).
Signed-off-by: Doug Anderson diand...@chromium.org
Signed-off-by: Simon Glass s...@chromium.org
Signed-off-by: Michael Spang sp...@chromium.org
Signed-off-by: Sean Paul seanp...@chromium.org
---
Changes in v2:
- Separated the overcurrent and retries changes into two patches.
- Now set overcurrent at probe time since it doesn't change.
.../devicetree/bindings/regulator/tps65090.txt | 4 ++
drivers/regulator/tps65090-regulator.c | 55 ++
include/linux/mfd/tps65090.h | 5 ++
3 files changed, 64 insertions(+)
diff --git a/Documentation/devicetree/bindings/regulator/tps65090.txt
b/Documentation/devicetree/bindings/regulator/tps65090.txt
index 313a60b..34098023 100644
--- a/Documentation/devicetree/bindings/regulator/tps65090.txt
+++ b/Documentation/devicetree/bindings/regulator/tps65090.txt
@@ -21,6 +21,10 @@ Optional properties:
number should be provided. If it is externally controlled and no GPIO
entry then driver will just configure this rails as external control
and will not provide any enable/disable APIs.
+- ti,overcurrent-wait: This is applicable to FET registers, which have a
+ poorly defined overcurrent wait field. If this property is present it
+ should be between 0 - 3. If this property isn't present we won't touch the
+ overcurrent wait field and we'll leave it to the BIOS/EC to deal with.
Each regulator is defined using the standard binding for regulators.
diff --git a/drivers/regulator/tps65090-regulator.c
b/drivers/regulator/tps65090-regulator.c
index 2e92ef6..ca13a1a 100644
--- a/drivers/regulator/tps65090-regulator.c
+++ b/drivers/regulator/tps65090-regulator.c
@@ -28,15 +28,57 @@
#include linux/regulator/of_regulator.h
#include linux/mfd/tps65090.h
+#define CTRL_WT_BIT2 /* Regulator wait time 0 bit */
+
+#define MAX_OVERCURRENT_WAIT 3 /* Overcurrent wait must be = this */
+
+/**
+ * struct tps65090_regulator - Per-regulator data for a tps65090 regulator
+ *
+ * @dev: Pointer to our device.
+ * @desc: The struct regulator_desc for the regulator.
+ * @rdev: The struct regulator_dev for the regulator.
+ * @overcurrent_wait_valid: True if overcurrent_wait is valid.
+ * @overcurrent_wait: For FETs, the value to put in the WTFET bitfield.
+ */
+
struct tps65090_regulator {
struct device *dev;
struct regulator_desc *desc;
struct regulator_dev*rdev;
+ boolovercurrent_wait_valid;
+ int overcurrent_wait;
};
static struct regulator_ops tps65090_ext_control_ops = {
};
+/**
+ * tps65090_reg_set_overcurrent_wait - Setup overcurrent wait
+ *
+ * This will set the overcurrent wait time based on what's in the regulator
+ * info.
+ *
+ * @ri:Overall regulator data
+ * @rdev: Regulator device
+ * @return 0 if no error, non-zero if there was an error writing the register.
+ */
+static int tps65090_reg_set_overcurrent_wait(struct tps65090_regulator *ri,
+struct regulator_dev *rdev)
+{
+ int ret;
+
+ ret = regmap_update_bits(rdev-regmap, rdev-desc-enable_reg,
+MAX_OVERCURRENT_WAIT CTRL_WT_BIT,
+ri-overcurrent_wait CTRL_WT_BIT);
+ if (ret) {
+ dev_err(rdev-dev, Error updating overcurrent wait %#x\n,
+ rdev-desc-enable_reg);
+ }
+
+ return ret;
+}
+
static struct regulator_ops tps65090_reg_contol_ops = {
.enable = regulator_enable_regmap,
.disable= regulator_disable_regmap,
@@ -209,6 +251,11 @@ static struct tps65090_platform_data
*tps65090_parse_dt_reg_data(
rpdata-gpio = of_get_named_gpio(np,
dcdc-ext-control-gpios, 0);
+ if (of_property_read_u32(tps65090_matches[idx].of_node,
+ti,overcurrent-wait,
+rpdata-overcurrent_wait) == 0)
+ rpdata-overcurrent_wait_valid = true;
+
tps65090_pdata-reg_pdata[idx] = rpdata;
}
return tps65090_pdata;
@@ -258,6 +305,8 @@ static int tps65090_regulator_probe(struct platform_device
*pdev)
ri = pmic[num];
ri-dev = pdev-dev;
ri-desc = tps65090_regulator_desc[num];
+ ri-overcurrent_wait_valid = tps_pdata-overcurrent_wait_valid;
+ ri-overcurrent_wait = tps_pdata-overcurrent_wait;
/*
* TPS5090 DCDC support the control from external digital input.
@@ -299,6 +348,12 @@ static int tps65090_regulator_probe(struct platform_device
*pdev)
}
[PATCH v2 5/5] regulator: tps65090: Make FETs more reliable by adding retries
An issue was discovered with tps65090 where sometimes the FETs
wouldn't actually turn on when requested (they would report
overcurrent). The most problematic FET was the one used for the LCD
backlight on the Samsung ARM Chromebook (FET1). Problems were
especially prevalent when the device was plugged in to AC power (when
the backlight voltage was higher).
Mitigate the problem by adding retries on the enables of the FETs,
which works around the problem fairly effectively.
Signed-off-by: Doug Anderson diand...@chromium.org
Signed-off-by: Simon Glass s...@chromium.org
Signed-off-by: Michael Spang sp...@chromium.org
Signed-off-by: Sean Paul seanp...@chromium.org
---
Changes in v2:
- Separated the overcurrent and retries changes into two patches.
- No longer open code fet_is_enabled().
- Fixed tps6090 typo.
- For loop = while true.
- Removed a set of braces.
drivers/regulator/tps65090-regulator.c | 153 +
1 file changed, 138 insertions(+), 15 deletions(-)
diff --git a/drivers/regulator/tps65090-regulator.c
b/drivers/regulator/tps65090-regulator.c
index ca13a1a..c37ffb72 100644
--- a/drivers/regulator/tps65090-regulator.c
+++ b/drivers/regulator/tps65090-regulator.c
@@ -17,6 +17,7 @@
*/
#include linux/module.h
+#include linux/delay.h
#include linux/init.h
#include linux/gpio.h
#include linux/of_gpio.h
@@ -28,7 +29,13 @@
#include linux/regulator/of_regulator.h
#include linux/mfd/tps65090.h
+#define MAX_CTRL_READ_TRIES5
+#define MAX_FET_ENABLE_TRIES 1000
+
+#define CTRL_EN_BIT0 /* Regulator enable bit, active high */
#define CTRL_WT_BIT2 /* Regulator wait time 0 bit */
+#define CTRL_PG_BIT4 /* Regulator power good bit, 1=good */
+#define CTRL_TO_BIT7 /* Regulator timeout bit, 1=wait */
#define MAX_OVERCURRENT_WAIT 3 /* Overcurrent wait must be = this */
@@ -79,40 +86,156 @@ static int tps65090_reg_set_overcurrent_wait(struct
tps65090_regulator *ri,
return ret;
}
-static struct regulator_ops tps65090_reg_contol_ops = {
+/**
+ * tps65090_try_enable_fet - Try to enable a FET
+ *
+ * @rdev: Regulator device
+ * @return 0 if ok, -ENOTRECOVERABLE if the FET power good bit did not get set,
+ * or some other -ve value if another error occurred (e.g. i2c error)
+ */
+static int tps65090_try_enable_fet(struct regulator_dev *rdev)
+{
+ unsigned int control;
+ int ret, i;
+
+ ret = regmap_update_bits(rdev-regmap, rdev-desc-enable_reg,
+rdev-desc-enable_mask,
+rdev-desc-enable_mask);
+ if (ret 0) {
+ dev_err(rdev-dev, Error in updating reg %#x\n,
+ rdev-desc-enable_reg);
+ return ret;
+ }
+
+ for (i = 0; i MAX_CTRL_READ_TRIES; i++) {
+ ret = regmap_read(rdev-regmap, rdev-desc-enable_reg,
+ control);
+ if (ret 0)
+ return ret;
+
+ if (!(control BIT(CTRL_TO_BIT)))
+ break;
+
+ usleep_range(1000, 1500);
+ }
+ if (!(control BIT(CTRL_PG_BIT)))
+ return -ENOTRECOVERABLE;
+
+ return 0;
+}
+
+/**
+ * tps65090_fet_enable - Enable a FET, trying a few times if it fails
+ *
+ * Some versions of the tps65090 have issues when turning on the FETs.
+ * This function goes through several steps to ensure the best chance of the
+ * FET going on. Specifically:
+ * - We'll make sure that we bump the overcurrent wait to the maximum, which
+ * increases the chances that we'll turn on properly.
+ * - We'll retry turning the FET on multiple times (turning off in between).
+ *
+ * @rdev: Regulator device
+ * @return 0 if ok, non-zero if it fails.
+ */
+static int tps65090_fet_enable(struct regulator_dev *rdev)
+{
+ int ret, tries;
+
+ /*
+* Try enabling multiple times until we succeed since sometimes the
+* first try times out.
+*/
+ tries = 0;
+ while (true) {
+ ret = tps65090_try_enable_fet(rdev);
+ if (!ret)
+ break;
+ if (ret != -ENOTRECOVERABLE || tries == MAX_FET_ENABLE_TRIES)
+ goto err;
+
+ /* Try turning the FET off (and then on again) */
+ ret = regmap_update_bits(rdev-regmap, rdev-desc-enable_reg,
+rdev-desc-enable_mask, 0);
+ if (ret)
+ goto err;
+
+ tries++;
+ }
+
+ if (tries)
+ dev_warn(rdev-dev, reg %#x enable ok after %d tries\n,
+rdev-desc-enable_reg, tries);
+
+ return 0;
+err:
+ dev_warn(rdev-dev, reg %#x enable failed\n, rdev-desc-enable_reg);
+ WARN_ON(1);
+
+ return ret;
+}
+
+static struct regulator_ops tps65090_reg_control_ops = {
.enable =
[PATCH v2 1/5] mfd: tps65090: Don't tell child devices we have an IRQ if we don't
If we weren't given an interrupt we shouldn't tell child devices (like
the tps65090 charger) that they have an interrupt. This is needed so
that we can support polling mode in the tps65090 charger driver.
See also (charger: tps65090: Allow charger module to be used when no
irq).
Signed-off-by: Doug Anderson diand...@chromium.org
Acked-by: Lee Jones lee.jo...@linaro.org
---
Changes in v2:
- Split noirq (polling mode) changes into MFD and charger
drivers/mfd/tps65090.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/mfd/tps65090.c b/drivers/mfd/tps65090.c
index ba1a25d..c3cddb4 100644
--- a/drivers/mfd/tps65090.c
+++ b/drivers/mfd/tps65090.c
@@ -64,11 +64,16 @@ static struct resource charger_resources[] = {
}
};
-static const struct mfd_cell tps65090s[] = {
- {
+enum tps65090_cells {
+ PMIC = 0,
+ CHARGER = 1,
+};
+
+static struct mfd_cell tps65090s[] = {
+ [PMIC] = {
.name = tps65090-pmic,
},
- {
+ [CHARGER] = {
.name = tps65090-charger,
.num_resources = ARRAY_SIZE(charger_resources),
.resources = charger_resources[0],
@@ -211,6 +216,9 @@ static int tps65090_i2c_probe(struct i2c_client *client,
IRQ init failed with err: %d\n, ret);
return ret;
}
+ } else {
+ /* Don't tell children they have an IRQ that'll never fire */
+ tps65090s[CHARGER].num_resources = 0;
}
ret = mfd_add_devices(tps65090-dev, -1, tps65090s,
--
1.9.1.423.g4596e3a
--
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/3] mfd: tps65090: Allow charger module to be used when no irq
On the ARM Chromebook tps65090 has two masters: the AP (the main processor running linux) and the EC (the embedded controller). The AP is allowed to mess with FETs but the EC is in charge of charge control. The tps65090 interupt line is routed to both the AP and the EC, which can cause quite a headache. Having two people adjusting masks and acking interrupts is a recipe for disaster. In the shipping kernel we had a hack to have the AP pay attention to the IRQ but not to ack it. It also wasn't supposed to configure the IRQ in any way. That hack allowed us to detect when the device was charging without messing with the EC's state. The current tps65090 infrastructure makes the above difficult, and it was a bit of a hack to begin with. Rather than uglify the driver to support it, just extend the driver's existing notion of no irq to the charger. This makes the charger code poll every 2 seconds for AC detect, which is sufficient. Signed-off-by: Doug Anderson diand...@chromium.org --- drivers/mfd/tps65090.c | 14 ++-- drivers/power/tps65090-charger.c | 76 +++- 2 files changed, 70 insertions(+), 20 deletions(-) For the MFD part: Acked-by: Lee Jones lee.jo...@linaro.org Anton, If you are okay with this patch I'd be happy to create an immutable branch for you to pull from? Doug, What is the relationship (dependencies) between this and the other patches in the set? This patch can be applied irrespective of other others in the series. What about the files in the patch? Could you make two separate patches from this one patch and it would still compile okay? I'm _guessing_ the answer is yes? Yes, they'll compile and even boot on their own. I just tested it. If I put only the MFD part in, then at boot I see: tps65090-charger tps65090-charger: Unable to get charger irq = -6 ...but otherwise the system functions. If I put only the charger part in, then at boot: tps65090-charger tps65090-charger: Unable to register irq 1 err -22 tps65090-charger: probe of tps65090-charger failed with error -22 ...so you need both patches in order to make things function, but they can be applied separately. I'll assume it will make your life easier if I split this into two patches so I'll do that. Yes please. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 4/5] regulator: tps65090: Allow setting the overcurrent wait time
On 04/16/2014 11:25 AM, Doug Anderson wrote:
diff --git a/drivers/regulator/tps65090-regulator.c
b/drivers/regulator/tps65090-regulator.c
index 2e92ef6..ca13a1a 100644
--- a/drivers/regulator/tps65090-regulator.c
+++ b/drivers/regulator/tps65090-regulator.c
@@ -28,15 +28,57 @@
+/**
+ * tps65090_reg_set_overcurrent_wait - Setup overcurrent wait
+ *
+ * This will set the overcurrent wait time based on what's in the regulator
+ * info.
+ *
+ * @ri: Overall regulator data
+ * @rdev:Regulator device
+ * @return 0 if no error, non-zero if there was an error writing the
register.
kernel-doc notation here should be:
* Return: 0 if no error, non-zero if there was an error writing the register.
+ */
+static int tps65090_reg_set_overcurrent_wait(struct tps65090_regulator *ri,
+ struct regulator_dev *rdev)
+{
--
~Randy
--
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 5/5] regulator: tps65090: Make FETs more reliable by adding retries
Hi Doug, (take 2)
On 16 April 2014 12:25, Doug Anderson diand...@chromium.org wrote:
An issue was discovered with tps65090 where sometimes the FETs
wouldn't actually turn on when requested (they would report
overcurrent). The most problematic FET was the one used for the LCD
backlight on the Samsung ARM Chromebook (FET1). Problems were
especially prevalent when the device was plugged in to AC power (when
the backlight voltage was higher).
Mitigate the problem by adding retries on the enables of the FETs,
which works around the problem fairly effectively.
Signed-off-by: Doug Anderson diand...@chromium.org
Signed-off-by: Simon Glass s...@chromium.org
Signed-off-by: Michael Spang sp...@chromium.org
Signed-off-by: Sean Paul seanp...@chromium.org
---
Changes in v2:
- Separated the overcurrent and retries changes into two patches.
- No longer open code fet_is_enabled().
- Fixed tps6090 typo.
- For loop = while true.
- Removed a set of braces.
drivers/regulator/tps65090-regulator.c | 153
+
1 file changed, 138 insertions(+), 15 deletions(-)
Reviewed-by: Simon Glass s...@chromium.org
(see minor comment below)
diff --git a/drivers/regulator/tps65090-regulator.c
b/drivers/regulator/tps65090-regulator.c
index ca13a1a..c37ffb72 100644
--- a/drivers/regulator/tps65090-regulator.c
+++ b/drivers/regulator/tps65090-regulator.c
@@ -17,6 +17,7 @@
*/
#include linux/module.h
+#include linux/delay.h
#include linux/init.h
#include linux/gpio.h
#include linux/of_gpio.h
@@ -28,7 +29,13 @@
#include linux/regulator/of_regulator.h
#include linux/mfd/tps65090.h
+#define MAX_CTRL_READ_TRIES5
+#define MAX_FET_ENABLE_TRIES 1000
Gosh that is a lot of tries - should we maybe give up sooner?
+
+#define CTRL_EN_BIT0 /* Regulator enable bit, active high */
#define CTRL_WT_BIT2 /* Regulator wait time 0 bit */
+#define CTRL_PG_BIT4 /* Regulator power good bit, 1=good */
+#define CTRL_TO_BIT7 /* Regulator timeout bit, 1=wait */
#define MAX_OVERCURRENT_WAIT 3 /* Overcurrent wait must be = this */
@@ -79,40 +86,156 @@ static int tps65090_reg_set_overcurrent_wait(struct
tps65090_regulator *ri,
return ret;
}
-static struct regulator_ops tps65090_reg_contol_ops = {
+/**
+ * tps65090_try_enable_fet - Try to enable a FET
+ *
+ * @rdev: Regulator device
+ * @return 0 if ok, -ENOTRECOVERABLE if the FET power good bit did not get
set,
+ * or some other -ve value if another error occurred (e.g. i2c error)
+ */
+static int tps65090_try_enable_fet(struct regulator_dev *rdev)
+{
+ unsigned int control;
+ int ret, i;
+
+ ret = regmap_update_bits(rdev-regmap, rdev-desc-enable_reg,
+rdev-desc-enable_mask,
+rdev-desc-enable_mask);
+ if (ret 0) {
+ dev_err(rdev-dev, Error in updating reg %#x\n,
+ rdev-desc-enable_reg);
+ return ret;
+ }
+
+ for (i = 0; i MAX_CTRL_READ_TRIES; i++) {
+ ret = regmap_read(rdev-regmap, rdev-desc-enable_reg,
+ control);
+ if (ret 0)
+ return ret;
+
+ if (!(control BIT(CTRL_TO_BIT)))
+ break;
+
+ usleep_range(1000, 1500);
+ }
+ if (!(control BIT(CTRL_PG_BIT)))
+ return -ENOTRECOVERABLE;
+
+ return 0;
+}
+
+/**
+ * tps65090_fet_enable - Enable a FET, trying a few times if it fails
+ *
+ * Some versions of the tps65090 have issues when turning on the FETs.
+ * This function goes through several steps to ensure the best chance of the
+ * FET going on. Specifically:
+ * - We'll make sure that we bump the overcurrent wait to the maximum,
which
+ * increases the chances that we'll turn on properly.
+ * - We'll retry turning the FET on multiple times (turning off in between).
+ *
+ * @rdev: Regulator device
+ * @return 0 if ok, non-zero if it fails.
+ */
+static int tps65090_fet_enable(struct regulator_dev *rdev)
+{
+ int ret, tries;
+
+ /*
+* Try enabling multiple times until we succeed since sometimes the
+* first try times out.
+*/
+ tries = 0;
+ while (true) {
+ ret = tps65090_try_enable_fet(rdev);
+ if (!ret)
+ break;
+ if (ret != -ENOTRECOVERABLE || tries == MAX_FET_ENABLE_TRIES)
+ goto err;
+
+ /* Try turning the FET off (and then on again) */
+ ret = regmap_update_bits(rdev-regmap, rdev-desc-enable_reg,
+rdev-desc-enable_mask, 0);
+ if (ret)
+ goto err;
+
+ tries++;
+ }
+
+ if (tries)
+
Re: [PATCH v2 5/5] regulator: tps65090: Make FETs more reliable by adding retries
On Wed, Apr 16, 2014 at 11:25:24AM -0700, Doug Anderson wrote: An issue was discovered with tps65090 where sometimes the FETs wouldn't actually turn on when requested (they would report overcurrent). The most problematic FET was the one used for the LCD Please don't send new patches as replies in the middle of threads, it makes it confusing trying to work out which versions of things should be applied. signature.asc Description: Digital signature
Re: [PATCH 5/6] ARM: EXYNOS: Enable multi-platform build support
On Wed, Apr 16, 2014 at 08:14:27PM +0200, Arnd Bergmann wrote: This patch does a partial revert of 313367e7bfa by allowing these drivers on all samsung platforms except EXYNOS, so we can proceed with the multiplatform patches. If support for these drivers is actually needed on EXYNOS machines, the drivers should first be moved over to use the dmaengine code. I would be surprised if neither IP is present on any Exynos SoC, they were added in the s5p range. Is Sachin's fix for building these (present in -rc1) not doing the job? signature.asc Description: Digital signature
Re: [PATCH 5/6] ARM: EXYNOS: Enable multi-platform build support
On Wednesday 16 April 2014 21:50:01 Mark Brown wrote: On Wed, Apr 16, 2014 at 08:14:27PM +0200, Arnd Bergmann wrote: This patch does a partial revert of 313367e7bfa by allowing these drivers on all samsung platforms except EXYNOS, so we can proceed with the multiplatform patches. If support for these drivers is actually needed on EXYNOS machines, the drivers should first be moved over to use the dmaengine code. I would be surprised if neither IP is present on any Exynos SoC, they were added in the s5p range. Is Sachin's fix for building these (present in -rc1) not doing the job? I hadn't noticed that patch, it probably does, so nevermind. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 5/5] regulator: tps65090: Make FETs more reliable by adding retries
Simon, On Wed, Apr 16, 2014 at 1:50 PM, Simon Glass s...@chromium.org wrote: +#define MAX_CTRL_READ_TRIES5 +#define MAX_FET_ENABLE_TRIES 1000 Gosh that is a lot of tries - should we maybe give up sooner? That's actually a squash of a recent patch. See https://chromium-review.googlesource.com/189239. I've specifically seen at least one case on my device where it needed 888 retries at bootup! ...on my really old Chromebook, it seems to get into a bad state if it sits on my desk for a long time. After I use it a bit it rarely needs more than 10 retries. -Doug -- 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: [RFC PATCH 05/14] ARM: dts: samsung-fimd: add I80 specific properties
Hi YoungJun, Thank you for the patch. On Tuesday 15 April 2014 14:47:33 YoungJun Cho wrote: In case of using CPU interface panel, the relevant registers should be set. So this patch adds relevant dt bindings. Signed-off-by: YoungJun Cho yj44@samsung.com Signed-off-by: Inki Dae inki@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com --- .../devicetree/bindings/video/samsung-fimd.txt |9 + 1 file changed, 9 insertions(+) diff --git a/Documentation/devicetree/bindings/video/samsung-fimd.txt b/Documentation/devicetree/bindings/video/samsung-fimd.txt index 2dad41b..924c2e1 100644 --- a/Documentation/devicetree/bindings/video/samsung-fimd.txt +++ b/Documentation/devicetree/bindings/video/samsung-fimd.txt @@ -44,6 +44,15 @@ Optional Properties: - display-timings: timing settings for FIMD, as described in document [1]. Can be used in case timings cannot be provided otherwise or to override timings provided by the panel. +- samsung,sysreg-phandle: handle to syscon used to control the system registers +- vidout-i80-ldi: boolean to support i80 interface instead of rgb one +- cs-setup: clock cycles for the active period of address signal enable until +chip select is enable in i80 interface +- wr-setup: clock cycles for the active period of CS signal enable until + write signal is enable in i80 interface +- wr-act: clock cycles for the active period of CS enable in i80 interface +- wr-hold: clock cycles for the active period of CS disable until write signal + is disable in i80 interface Shouldn't the interface parameters be considered as a property of the slave device instead ? The bus master side is programmable, and different slaves would have different timing requirements. I think it would make more sense to specify the timings on the slave (panel) side and query them dynamically at runtime. Depending on the slave the timings could be hardcoded in the driver (as they're usually an intrinsic property of the slave) or partially or fully specified in the slave DT node. The device node can contain 'port' child nodes according to the bindings defined in [2]. The following are properties specific to those nodes: -- Regards, Laurent Pinchart -- 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 5/5] regulator: tps65090: Make FETs more reliable by adding retries
Mark, On Wed, Apr 16, 2014 at 1:51 PM, Mark Brown broo...@kernel.org wrote: On Wed, Apr 16, 2014 at 11:25:24AM -0700, Doug Anderson wrote: An issue was discovered with tps65090 where sometimes the FETs wouldn't actually turn on when requested (they would report overcurrent). The most problematic FET was the one used for the LCD Please don't send new patches as replies in the middle of threads, it makes it confusing trying to work out which versions of things should be applied. I'm a little confused about what I did wrong. Can you give more details? * V1 had 3 patches plus a cover letter. * I was asked to split two patches, so V2 has 5 patches plus a cover letter. * My v2 series was all in reply to the v1 cover letter, which I thought was best practice. * All of my v2 patches were marked with v2 and included changes between v1 and v2. * Everyone was CCed on the cover letter. Only appropriate people were CCed on the individual patches (as per get_maintainer, automated by patman). * All patches were resent at v2. If I had to answer your question, I'd say that you should now completely ignore v1 and look at v2. -Doug -- 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: [RFC PATCH v2 09/14] ARM: dts: s6e3fa0: add DT bindings
Hi YoungJun,
Thank you for the patch.
On Wednesday 16 April 2014 13:38:57 YoungJun Cho wrote:
This patch adds DT bindings for s6e3fa0 panel.
The bindings describes panel resources, display timings, delays
and physical size.
Changelog v2:
- Adds unit address (commented by Sachin Kamat)
Signed-off-by: YoungJun Cho yj44@samsung.com
Signed-off-by: Inki Dae inki@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
.../devicetree/bindings/panel/samsung,s6e3fa0.txt | 52 +
1 file changed, 52 insertions(+)
create mode 100644
Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt
diff --git a/Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt
b/Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt new file mode
100644
index 000..889a74d
--- /dev/null
+++ b/Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt
@@ -0,0 +1,52 @@
+Samsung S6E3FA0 AMOLED LCD 5.7 inch panel
+
+Required properties:
+ - compatible: samsung,s6e3fa0
+ - reg: the virtual channel number of a DSI peripheral
+ - vdd3-supply: core voltage supply
+ - vci-supply: voltage supply for analog circuits
+ - reset-gpio: a GPIO spec for the reset pin
+ - display-timings: timings for the connected panel as described by [1]
+
+Optional properties:
+ - power-on-delay: delay after turning regulators on [ms]
+ - reset-delay: delay after reset sequence [ms]
+ - init-delay: delay after initialization sequence [ms]
+ - panel-width-mm: physical panel width [mm]
+ - panel-height-mm: physical panel height [mm]
Based on the next patch the panel seems to require quite a lot of device-
specific handling, although I might be mistaken as I'm not too familiar with
DSI. If my understanding is correct, do we really need to specify all those
properties in DT, or could they be hardcoded in the driver ? I would usually
push for generic drivers that read device information from DT, but I'm
wondering whether that is the right choice here.
If you decide to keep the information in DT I think you should document what
happens when optional properties are not specified. I suppose the driver uses
a default value, I would document it in the DT bindings.
+The device node can contain one 'port' child node with one child
+'endpoint' node, according to the bindings defined in [2]. This
+node should describe panel's video bus.
+
+[1]: Documentation/devicetree/bindings/video/display-timing.txt
+[2]: Documentation/devicetree/bindings/media/video-interfaces.txt
+
+Example:
+
+ panel@0 {
+ compatible = samsung,s6e3fa0;
+ reg = 0;
+ vdd3-supply = vcclcd_reg;
+ vci-supply = vlcd_reg;
+ reset-gpio = gpy7 4 0;
+ power-on-delay= 10;
+ reset-delay = 5;
+ init-delay = 120;
+ panel-width-mm = 71;
+ panel-height-mm = 126;
+
+ display-timings {
+ timing0: timing-0 {
+ clock-frequency = 57153600;
+ hactive = 1080;
+ vactive = 1920;
+ hfront-porch = 2;
+ hback-porch = 2;
+ hsync-len = 1;
+ vfront-porch = 1;
+ vback-porch = 4;
+ vsync-len = 1;
+ };
+ };
+ };
--
Regards,
Laurent Pinchart
--
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 5/5] regulator: tps65090: Make FETs more reliable by adding retries
On Wed, Apr 16, 2014 at 02:34:47PM -0700, Doug Anderson wrote: On Wed, Apr 16, 2014 at 1:51 PM, Mark Brown broo...@kernel.org wrote: Please don't send new patches as replies in the middle of threads, it makes it confusing trying to work out which versions of things should be applied. I'm a little confused about what I did wrong. Can you give more details? I'm seeing a reply which looks like it was sent as a followup to Randy's comment, although now I look at everything together I think that's due to you sending your new thread in reply to the old thread (that can also be a problem due to threading either burying the new mail or putting things in odd places) and my mailer trying to tie the one mail from your first series that I'd not deleted into the thread. signature.asc Description: Digital signature
Re: [PATCH v2 5/5] regulator: tps65090: Make FETs more reliable by adding retries
Mark, On Wed, Apr 16, 2014 at 2:54 PM, Mark Brown broo...@kernel.org wrote: On Wed, Apr 16, 2014 at 02:34:47PM -0700, Doug Anderson wrote: On Wed, Apr 16, 2014 at 1:51 PM, Mark Brown broo...@kernel.org wrote: Please don't send new patches as replies in the middle of threads, it makes it confusing trying to work out which versions of things should be applied. I'm a little confused about what I did wrong. Can you give more details? I'm seeing a reply which looks like it was sent as a followup to Randy's comment, although now I look at everything together I think that's due to you sending your new thread in reply to the old thread (that can also be a problem due to threading either burying the new mail or putting things in odd places) and my mailer trying to tie the one mail from your first series that I'd not deleted into the thread. OK, I'm about to send my v3 of the thread taking Randy's comments about kernel-doc into account. I'll explicitly not mark it as in-reply-to the previous thread and hope that solves the problems you were seeing. -Doug -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 1/5] mfd: tps65090: Don't tell child devices we have an IRQ if we don't
If we weren't given an interrupt we shouldn't tell child devices (like
the tps65090 charger) that they have an interrupt. This is needed so
that we can support polling mode in the tps65090 charger driver.
See also (charger: tps65090: Allow charger module to be used when no
irq).
Signed-off-by: Doug Anderson diand...@chromium.org
Acked-by: Lee Jones lee.jo...@linaro.org
---
Changes in v3: None
Changes in v2:
- Split noirq (polling mode) changes into MFD and charger
drivers/mfd/tps65090.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/mfd/tps65090.c b/drivers/mfd/tps65090.c
index ba1a25d..c3cddb4 100644
--- a/drivers/mfd/tps65090.c
+++ b/drivers/mfd/tps65090.c
@@ -64,11 +64,16 @@ static struct resource charger_resources[] = {
}
};
-static const struct mfd_cell tps65090s[] = {
- {
+enum tps65090_cells {
+ PMIC = 0,
+ CHARGER = 1,
+};
+
+static struct mfd_cell tps65090s[] = {
+ [PMIC] = {
.name = tps65090-pmic,
},
- {
+ [CHARGER] = {
.name = tps65090-charger,
.num_resources = ARRAY_SIZE(charger_resources),
.resources = charger_resources[0],
@@ -211,6 +216,9 @@ static int tps65090_i2c_probe(struct i2c_client *client,
IRQ init failed with err: %d\n, ret);
return ret;
}
+ } else {
+ /* Don't tell children they have an IRQ that'll never fire */
+ tps65090s[CHARGER].num_resources = 0;
}
ret = mfd_add_devices(tps65090-dev, -1, tps65090s,
--
1.9.1.423.g4596e3a
--
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 4/5] regulator: tps65090: Allow setting the overcurrent wait time
Randy, On Wed, Apr 16, 2014 at 1:33 PM, Randy Dunlap rdun...@infradead.org wrote: On 04/16/2014 11:25 AM, Doug Anderson wrote: diff --git a/drivers/regulator/tps65090-regulator.c b/drivers/regulator/tps65090-regulator.c index 2e92ef6..ca13a1a 100644 --- a/drivers/regulator/tps65090-regulator.c +++ b/drivers/regulator/tps65090-regulator.c @@ -28,15 +28,57 @@ +/** + * tps65090_reg_set_overcurrent_wait - Setup overcurrent wait + * + * This will set the overcurrent wait time based on what's in the regulator + * info. + * + * @ri: Overall regulator data + * @rdev:Regulator device + * @return 0 if no error, non-zero if there was an error writing the register. kernel-doc notation here should be: * Return: 0 if no error, non-zero if there was an error writing the register. Done in v3. -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 0/5] Fixes for tps65090 for Samsung ARM Chromebook
These five patches bring tps65090 up to speed with what's currently in the Chromium OS kernel 3.8 tree and running on the Samsung ARM Chromebook. Changes were tested atop the current linux tree (v3.15-rc1). FET retries were tested on a machine with a known flaky tps65090. Since display isn't working on pure upstream, I augmented the code to turn FET1 (vcd_led) on/off 500 times at bootup. When testing I included https://patchwork.kernel.org/patch/3980731/ to make sure tps65090 was in exynos5250-snow's device tree. Dependencies: - Patch #1 (mfd no irq) has no dependencies, though patch #2 won't work without it. - Patch #2 (charger polling) can be applied without patch #1 but won't actually make charger polling work without it. - Patch #3 (caching) can be applied before retries patch but not after. - Patch #4 (overcurrent wait time) can be applied before retries patch but not after (just due to merge conflicts, no other reason). - Patch #5 (retries) absolutely requires patch #3 (caching). Changes in v3: - Fixed kernel-doc notation for return Changes in v2: - Split noirq (polling mode) changes into MFD and charger - Leave cache on for the registers that can be cached. - Move register offsets to mfd header file. - Separated the overcurrent and retries changes into two patches. - Now set overcurrent at probe time since it doesn't change. - Separated the overcurrent and retries changes into two patches. - No longer open code fet_is_enabled(). - Fixed tps6090 typo. - For loop = while true. - Removed a set of braces. Doug Anderson (5): mfd: tps65090: Don't tell child devices we have an IRQ if we don't charger: tps65090: Allow charger module to be used when no irq mfd: tps65090: Stop caching most registers regulator: tps65090: Allow setting the overcurrent wait time regulator: tps65090: Make FETs more reliable by adding retries .../devicetree/bindings/regulator/tps65090.txt | 4 + drivers/mfd/tps65090.c | 41 ++-- drivers/power/tps65090-charger.c | 87 ++--- drivers/regulator/tps65090-regulator.c | 211 +++-- include/linux/mfd/tps65090.h | 19 ++ 5 files changed, 303 insertions(+), 59 deletions(-) -- 1.9.1.423.g4596e3a -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 4/5] regulator: tps65090: Allow setting the overcurrent wait time
The tps65090 regulator allows you to specify how long you want it to
wait before detecting an overcurrent condition. Allow specifying that
through the device tree (or through platform data).
Signed-off-by: Doug Anderson diand...@chromium.org
Signed-off-by: Simon Glass s...@chromium.org
Signed-off-by: Michael Spang sp...@chromium.org
Signed-off-by: Sean Paul seanp...@chromium.org
---
Changes in v3:
- Fixed kernel-doc notation for return
Changes in v2:
- Separated the overcurrent and retries changes into two patches.
- Now set overcurrent at probe time since it doesn't change.
.../devicetree/bindings/regulator/tps65090.txt | 4 ++
drivers/regulator/tps65090-regulator.c | 56 ++
include/linux/mfd/tps65090.h | 5 ++
3 files changed, 65 insertions(+)
diff --git a/Documentation/devicetree/bindings/regulator/tps65090.txt
b/Documentation/devicetree/bindings/regulator/tps65090.txt
index 313a60b..34098023 100644
--- a/Documentation/devicetree/bindings/regulator/tps65090.txt
+++ b/Documentation/devicetree/bindings/regulator/tps65090.txt
@@ -21,6 +21,10 @@ Optional properties:
number should be provided. If it is externally controlled and no GPIO
entry then driver will just configure this rails as external control
and will not provide any enable/disable APIs.
+- ti,overcurrent-wait: This is applicable to FET registers, which have a
+ poorly defined overcurrent wait field. If this property is present it
+ should be between 0 - 3. If this property isn't present we won't touch the
+ overcurrent wait field and we'll leave it to the BIOS/EC to deal with.
Each regulator is defined using the standard binding for regulators.
diff --git a/drivers/regulator/tps65090-regulator.c
b/drivers/regulator/tps65090-regulator.c
index 2e92ef6..ca04e9f 100644
--- a/drivers/regulator/tps65090-regulator.c
+++ b/drivers/regulator/tps65090-regulator.c
@@ -28,15 +28,58 @@
#include linux/regulator/of_regulator.h
#include linux/mfd/tps65090.h
+#define CTRL_WT_BIT2 /* Regulator wait time 0 bit */
+
+#define MAX_OVERCURRENT_WAIT 3 /* Overcurrent wait must be = this */
+
+/**
+ * struct tps65090_regulator - Per-regulator data for a tps65090 regulator
+ *
+ * @dev: Pointer to our device.
+ * @desc: The struct regulator_desc for the regulator.
+ * @rdev: The struct regulator_dev for the regulator.
+ * @overcurrent_wait_valid: True if overcurrent_wait is valid.
+ * @overcurrent_wait: For FETs, the value to put in the WTFET bitfield.
+ */
+
struct tps65090_regulator {
struct device *dev;
struct regulator_desc *desc;
struct regulator_dev*rdev;
+ boolovercurrent_wait_valid;
+ int overcurrent_wait;
};
static struct regulator_ops tps65090_ext_control_ops = {
};
+/**
+ * tps65090_reg_set_overcurrent_wait - Setup overcurrent wait
+ *
+ * This will set the overcurrent wait time based on what's in the regulator
+ * info.
+ *
+ * @ri:Overall regulator data
+ * @rdev: Regulator device
+ *
+ * Return: 0 if no error, non-zero if there was an error writing the register.
+ */
+static int tps65090_reg_set_overcurrent_wait(struct tps65090_regulator *ri,
+struct regulator_dev *rdev)
+{
+ int ret;
+
+ ret = regmap_update_bits(rdev-regmap, rdev-desc-enable_reg,
+MAX_OVERCURRENT_WAIT CTRL_WT_BIT,
+ri-overcurrent_wait CTRL_WT_BIT);
+ if (ret) {
+ dev_err(rdev-dev, Error updating overcurrent wait %#x\n,
+ rdev-desc-enable_reg);
+ }
+
+ return ret;
+}
+
static struct regulator_ops tps65090_reg_contol_ops = {
.enable = regulator_enable_regmap,
.disable= regulator_disable_regmap,
@@ -209,6 +252,11 @@ static struct tps65090_platform_data
*tps65090_parse_dt_reg_data(
rpdata-gpio = of_get_named_gpio(np,
dcdc-ext-control-gpios, 0);
+ if (of_property_read_u32(tps65090_matches[idx].of_node,
+ti,overcurrent-wait,
+rpdata-overcurrent_wait) == 0)
+ rpdata-overcurrent_wait_valid = true;
+
tps65090_pdata-reg_pdata[idx] = rpdata;
}
return tps65090_pdata;
@@ -258,6 +306,8 @@ static int tps65090_regulator_probe(struct platform_device
*pdev)
ri = pmic[num];
ri-dev = pdev-dev;
ri-desc = tps65090_regulator_desc[num];
+ ri-overcurrent_wait_valid = tps_pdata-overcurrent_wait_valid;
+ ri-overcurrent_wait = tps_pdata-overcurrent_wait;
/*
* TPS5090 DCDC support the control from external digital input.
@@ -299,6 +349,12 @@ static int
[PATCH v3 2/5] charger: tps65090: Allow charger module to be used when no irq
On the ARM Chromebook tps65090 has two masters: the AP (the main
processor running linux) and the EC (the embedded controller). The AP
is allowed to mess with FETs but the EC is in charge of charge control.
The tps65090 interupt line is routed to both the AP and the EC, which
can cause quite a headache. Having two people adjusting masks and
acking interrupts is a recipe for disaster.
In the shipping kernel we had a hack to have the AP pay attention to
the IRQ but not to ack it. It also wasn't supposed to configure the
IRQ in any way. That hack allowed us to detect when the device was
charging without messing with the EC's state.
The current tps65090 infrastructure makes the above difficult, and it
was a bit of a hack to begin with. Rather than uglify the driver to
support it, just extend the driver's existing notion of no irq to
the charger. This makes the charger code poll every 2 seconds for AC
detect, which is sufficient.
For proper functioning, requires (mfd: tps65090: Don't tell child
devices we have an IRQ if we don't). If we don't have that patch
we'll simply fail to probe on devices without an interrupt (just like
we did before this patch).
Signed-off-by: Doug Anderson diand...@chromium.org
---
Changes in v3: None
Changes in v2:
- Split noirq (polling mode) changes into MFD and charger
drivers/power/tps65090-charger.c | 76 +++-
1 file changed, 59 insertions(+), 17 deletions(-)
diff --git a/drivers/power/tps65090-charger.c b/drivers/power/tps65090-charger.c
index 8fc9d6d..cc26c12 100644
--- a/drivers/power/tps65090-charger.c
+++ b/drivers/power/tps65090-charger.c
@@ -17,9 +17,11 @@
*/
#include linux/delay.h
#include linux/err.h
+#include linux/freezer.h
#include linux/init.h
#include linux/interrupt.h
#include linux/kernel.h
+#include linux/kthread.h
#include linux/module.h
#include linux/of_device.h
#include linux/platform_device.h
@@ -43,11 +45,15 @@
#define TPS65090_VACG BIT(1)
#define TPS65090_NOITERM BIT(5)
+#define POLL_INTERVAL (HZ * 2)/* Used when no irq */
+
struct tps65090_charger {
struct device *dev;
int ac_online;
int prev_ac_online;
int irq;
+ struct task_struct *poll_task;
+ boolpassive_mode;
struct power_supply ac;
struct tps65090_platform_data *pdata;
};
@@ -60,6 +66,9 @@ static int tps65090_low_chrg_current(struct tps65090_charger
*charger)
{
int ret;
+ if (charger-passive_mode)
+ return 0;
+
ret = tps65090_write(charger-dev-parent, TPS65090_REG_CG_CTRL5,
TPS65090_NOITERM);
if (ret 0) {
@@ -75,6 +84,9 @@ static int tps65090_enable_charging(struct tps65090_charger
*charger)
int ret;
uint8_t ctrl0 = 0;
+ if (charger-passive_mode)
+ return 0;
+
ret = tps65090_read(charger-dev-parent, TPS65090_REG_CG_CTRL0,
ctrl0);
if (ret 0) {
@@ -98,6 +110,9 @@ static int tps65090_config_charger(struct tps65090_charger
*charger)
uint8_t intrmask = 0;
int ret;
+ if (charger-passive_mode)
+ return 0;
+
if (charger-pdata-enable_low_current_chrg) {
ret = tps65090_low_chrg_current(charger);
if (ret 0) {
@@ -175,10 +190,14 @@ static irqreturn_t tps65090_charger_isr(int irq, void
*dev_id)
}
/* Clear interrupts. */
- ret = tps65090_write(charger-dev-parent, TPS65090_REG_INTR_STS, 0x00);
- if (ret 0) {
- dev_err(charger-dev, %s(): Error in writing reg 0x%x\n,
+ if (!charger-passive_mode) {
+ ret = tps65090_write(charger-dev-parent,
+TPS65090_REG_INTR_STS, 0x00);
+ if (ret 0) {
+ dev_err(charger-dev,
+ %s(): Error in writing reg 0x%x\n,
__func__, TPS65090_REG_INTR_STS);
+ }
}
if (charger-prev_ac_online != charger-ac_online)
@@ -209,6 +228,18 @@ static struct tps65090_platform_data *
}
+static int tps65090_charger_poll_task(void *data)
+{
+ set_freezable();
+
+ while (!kthread_should_stop()) {
+ schedule_timeout_interruptible(POLL_INTERVAL);
+ try_to_freeze();
+ tps65090_charger_isr(-1, data);
+ }
+ return 0;
+}
+
static int tps65090_charger_probe(struct platform_device *pdev)
{
struct tps65090_charger *cdata;
@@ -255,22 +286,10 @@ static int tps65090_charger_probe(struct platform_device
*pdev)
}
irq = platform_get_irq(pdev, 0);
- if (irq = 0) {
- dev_warn(pdev-dev, Unable to get charger irq = %d\n, irq);
- ret = irq;
- goto fail_unregister_supply;
- }
-
+ if (irq 0)
+ irq =
[PATCH v3 3/5] mfd: tps65090: Stop caching most registers
Nearly all of the registers in tps65090 combine control bits and
status bits. Turn off caching of all registers except the select few
that can be cached.
In order to avoid adding more duplicate #defines, we also move some
register offset definitions to the mfd driver (and resolve
inconsistent names).
Signed-off-by: Doug Anderson diand...@chromium.org
---
Changes in v3: None
Changes in v2:
- Leave cache on for the registers that can be cached.
- Move register offsets to mfd header file.
drivers/mfd/tps65090.c | 27 ++-
drivers/power/tps65090-charger.c | 11 ---
include/linux/mfd/tps65090.h | 14 ++
3 files changed, 28 insertions(+), 24 deletions(-)
diff --git a/drivers/mfd/tps65090.c b/drivers/mfd/tps65090.c
index c3cddb4..1c3e6e2 100644
--- a/drivers/mfd/tps65090.c
+++ b/drivers/mfd/tps65090.c
@@ -32,14 +32,6 @@
#define NUM_INT_REG 2
#define TOTAL_NUM_REG 0x18
-/* interrupt status registers */
-#define TPS65090_INT_STS 0x0
-#define TPS65090_INT_STS2 0x1
-
-/* interrupt mask registers */
-#define TPS65090_INT_MSK 0x2
-#define TPS65090_INT_MSK2 0x3
-
#define TPS65090_INT1_MASK_VAC_STATUS_CHANGE 1
#define TPS65090_INT1_MASK_VSYS_STATUS_CHANGE 2
#define TPS65090_INT1_MASK_BAT_STATUS_CHANGE 3
@@ -144,17 +136,26 @@ static struct regmap_irq_chip tps65090_irq_chip = {
.irqs = tps65090_irqs,
.num_irqs = ARRAY_SIZE(tps65090_irqs),
.num_regs = NUM_INT_REG,
- .status_base = TPS65090_INT_STS,
- .mask_base = TPS65090_INT_MSK,
+ .status_base = TPS65090_REG_INTR_STS,
+ .mask_base = TPS65090_REG_INTR_MASK,
.mask_invert = true,
};
static bool is_volatile_reg(struct device *dev, unsigned int reg)
{
- if ((reg == TPS65090_INT_STS) || (reg == TPS65090_INT_STS2))
- return true;
- else
+ /* Nearly all registers have status bits mixed in, except a few */
+ switch (reg) {
+ case TPS65090_REG_INTR_MASK:
+ case TPS65090_REG_INTR_MASK2:
+ case TPS65090_REG_CG_CTRL0:
+ case TPS65090_REG_CG_CTRL1:
+ case TPS65090_REG_CG_CTRL2:
+ case TPS65090_REG_CG_CTRL3:
+ case TPS65090_REG_CG_CTRL4:
+ case TPS65090_REG_CG_CTRL5:
return false;
+ }
+ return true;
}
static const struct regmap_config tps65090_regmap_config = {
diff --git a/drivers/power/tps65090-charger.c b/drivers/power/tps65090-charger.c
index cc26c12..31a3ba4 100644
--- a/drivers/power/tps65090-charger.c
+++ b/drivers/power/tps65090-charger.c
@@ -30,17 +30,6 @@
#include linux/mfd/tps65090.h
-#define TPS65090_REG_INTR_STS 0x00
-#define TPS65090_REG_INTR_MASK 0x02
-#define TPS65090_REG_CG_CTRL0 0x04
-#define TPS65090_REG_CG_CTRL1 0x05
-#define TPS65090_REG_CG_CTRL2 0x06
-#define TPS65090_REG_CG_CTRL3 0x07
-#define TPS65090_REG_CG_CTRL4 0x08
-#define TPS65090_REG_CG_CTRL5 0x09
-#define TPS65090_REG_CG_STATUS10x0a
-#define TPS65090_REG_CG_STATUS20x0b
-
#define TPS65090_CHARGER_ENABLEBIT(0)
#define TPS65090_VACG BIT(1)
#define TPS65090_NOITERM BIT(5)
diff --git a/include/linux/mfd/tps65090.h b/include/linux/mfd/tps65090.h
index 3f43069..45f0f9d 100644
--- a/include/linux/mfd/tps65090.h
+++ b/include/linux/mfd/tps65090.h
@@ -64,6 +64,20 @@ enum {
TPS65090_REGULATOR_MAX,
};
+/* Register addresses */
+#define TPS65090_REG_INTR_STS 0x00
+#define TPS65090_REG_INTR_STS2 0x01
+#define TPS65090_REG_INTR_MASK 0x02
+#define TPS65090_REG_INTR_MASK20x03
+#define TPS65090_REG_CG_CTRL0 0x04
+#define TPS65090_REG_CG_CTRL1 0x05
+#define TPS65090_REG_CG_CTRL2 0x06
+#define TPS65090_REG_CG_CTRL3 0x07
+#define TPS65090_REG_CG_CTRL4 0x08
+#define TPS65090_REG_CG_CTRL5 0x09
+#define TPS65090_REG_CG_STATUS10x0a
+#define TPS65090_REG_CG_STATUS20x0b
+
struct tps65090 {
struct device *dev;
struct regmap *rmap;
--
1.9.1.423.g4596e3a
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 5/5] regulator: tps65090: Make FETs more reliable by adding retries
An issue was discovered with tps65090 where sometimes the FETs
wouldn't actually turn on when requested (they would report
overcurrent). The most problematic FET was the one used for the LCD
backlight on the Samsung ARM Chromebook (FET1). Problems were
especially prevalent when the device was plugged in to AC power (when
the backlight voltage was higher).
Mitigate the problem by adding retries on the enables of the FETs,
which works around the problem fairly effectively.
Signed-off-by: Doug Anderson diand...@chromium.org
Signed-off-by: Simon Glass s...@chromium.org
Signed-off-by: Michael Spang sp...@chromium.org
Signed-off-by: Sean Paul seanp...@chromium.org
Reviewed-by: Simon Glass s...@chromium.org
---
Changes in v3:
- Fixed kernel-doc notation for return
Changes in v2:
- Separated the overcurrent and retries changes into two patches.
- No longer open code fet_is_enabled().
- Fixed tps6090 typo.
- For loop = while true.
- Removed a set of braces.
drivers/regulator/tps65090-regulator.c | 155 +
1 file changed, 140 insertions(+), 15 deletions(-)
diff --git a/drivers/regulator/tps65090-regulator.c
b/drivers/regulator/tps65090-regulator.c
index ca04e9f..2057e2e 100644
--- a/drivers/regulator/tps65090-regulator.c
+++ b/drivers/regulator/tps65090-regulator.c
@@ -17,6 +17,7 @@
*/
#include linux/module.h
+#include linux/delay.h
#include linux/init.h
#include linux/gpio.h
#include linux/of_gpio.h
@@ -28,7 +29,13 @@
#include linux/regulator/of_regulator.h
#include linux/mfd/tps65090.h
+#define MAX_CTRL_READ_TRIES5
+#define MAX_FET_ENABLE_TRIES 1000
+
+#define CTRL_EN_BIT0 /* Regulator enable bit, active high */
#define CTRL_WT_BIT2 /* Regulator wait time 0 bit */
+#define CTRL_PG_BIT4 /* Regulator power good bit, 1=good */
+#define CTRL_TO_BIT7 /* Regulator timeout bit, 1=wait */
#define MAX_OVERCURRENT_WAIT 3 /* Overcurrent wait must be = this */
@@ -80,40 +87,158 @@ static int tps65090_reg_set_overcurrent_wait(struct
tps65090_regulator *ri,
return ret;
}
-static struct regulator_ops tps65090_reg_contol_ops = {
+/**
+ * tps65090_try_enable_fet - Try to enable a FET
+ *
+ * @rdev: Regulator device
+ *
+ * Return: 0 if ok, -ENOTRECOVERABLE if the FET power good bit did not get
+ * set, or some other -ve value if another error occurred (e.g. i2c error)
+ */
+static int tps65090_try_enable_fet(struct regulator_dev *rdev)
+{
+ unsigned int control;
+ int ret, i;
+
+ ret = regmap_update_bits(rdev-regmap, rdev-desc-enable_reg,
+rdev-desc-enable_mask,
+rdev-desc-enable_mask);
+ if (ret 0) {
+ dev_err(rdev-dev, Error in updating reg %#x\n,
+ rdev-desc-enable_reg);
+ return ret;
+ }
+
+ for (i = 0; i MAX_CTRL_READ_TRIES; i++) {
+ ret = regmap_read(rdev-regmap, rdev-desc-enable_reg,
+ control);
+ if (ret 0)
+ return ret;
+
+ if (!(control BIT(CTRL_TO_BIT)))
+ break;
+
+ usleep_range(1000, 1500);
+ }
+ if (!(control BIT(CTRL_PG_BIT)))
+ return -ENOTRECOVERABLE;
+
+ return 0;
+}
+
+/**
+ * tps65090_fet_enable - Enable a FET, trying a few times if it fails
+ *
+ * Some versions of the tps65090 have issues when turning on the FETs.
+ * This function goes through several steps to ensure the best chance of the
+ * FET going on. Specifically:
+ * - We'll make sure that we bump the overcurrent wait to the maximum, which
+ * increases the chances that we'll turn on properly.
+ * - We'll retry turning the FET on multiple times (turning off in between).
+ *
+ * @rdev: Regulator device
+ *
+ * Return: 0 if ok, non-zero if it fails.
+ */
+static int tps65090_fet_enable(struct regulator_dev *rdev)
+{
+ int ret, tries;
+
+ /*
+* Try enabling multiple times until we succeed since sometimes the
+* first try times out.
+*/
+ tries = 0;
+ while (true) {
+ ret = tps65090_try_enable_fet(rdev);
+ if (!ret)
+ break;
+ if (ret != -ENOTRECOVERABLE || tries == MAX_FET_ENABLE_TRIES)
+ goto err;
+
+ /* Try turning the FET off (and then on again) */
+ ret = regmap_update_bits(rdev-regmap, rdev-desc-enable_reg,
+rdev-desc-enable_mask, 0);
+ if (ret)
+ goto err;
+
+ tries++;
+ }
+
+ if (tries)
+ dev_warn(rdev-dev, reg %#x enable ok after %d tries\n,
+rdev-desc-enable_reg, tries);
+
+ return 0;
+err:
+ dev_warn(rdev-dev, reg %#x enable failed\n, rdev-desc-enable_reg);
+ WARN_ON(1);
+
+
Re: [PATCH v2 5/5] regulator: tps65090: Make FETs more reliable by adding retries
Hi Doug, On 16 April 2014 15:25, Doug Anderson diand...@chromium.org wrote: Simon, On Wed, Apr 16, 2014 at 1:50 PM, Simon Glass s...@chromium.org wrote: +#define MAX_CTRL_READ_TRIES5 +#define MAX_FET_ENABLE_TRIES 1000 Gosh that is a lot of tries - should we maybe give up sooner? That's actually a squash of a recent patch. See https://chromium-review.googlesource.com/189239. I've specifically seen at least one case on my device where it needed 888 retries at bootup! ...on my really old Chromebook, it seems to get into a bad state if it sits on my desk for a long time. After I use it a bit it rarely needs more than 10 retries. Try to be kinder to your hardware? Anyway, fair enough, if you've seen 888 then we need to deal with that case. Regards, Simon -- 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 01/27] ARM: EXYNOS: Add Exynos3250 SoC ID
Hi Tomasz,
On 04/17/2014 12:53 AM, Tomasz Figa wrote:
Hi Chanwoo,
On 14.04.2014 07:13, Chanwoo Choi wrote:
On 04/11/2014 05:39 PM, Tomasz Figa wrote:
On 11.04.2014 08:32, Chanwoo Choi wrote:
On 04/11/2014 10:46 AM, Olof Johansson wrote:
On Thu, Apr 10, 2014 at 06:37:12PM +0900, Chanwoo Choi wrote:
diff --git a/arch/arm/plat-samsung/include/plat/cpu.h
b/arch/arm/plat-samsung/include/plat/cpu.h
index 5992b8d..3d808f6b 100644
--- a/arch/arm/plat-samsung/include/plat/cpu.h
+++ b/arch/arm/plat-samsung/include/plat/cpu.h
@@ -43,6 +43,9 @@ extern unsigned long samsung_cpu_id;
#define S5PV210_CPU_ID0x4311
#define S5PV210_CPU_MASK0xF000
+#define EXYNOS3250_SOC_ID 0xE3472000
+#define EXYNOS3_SOC_MASK0xF000
+
#define EXYNOS4210_CPU_ID0x4321
#define EXYNOS4212_CPU_ID0x4322
#define EXYNOS4412_CPU_ID0xE4412200
@@ -68,6 +71,7 @@ IS_SAMSUNG_CPU(s5p6440, S5P6440_CPU_ID,
S5P64XX_CPU_MASK)
IS_SAMSUNG_CPU(s5p6450, S5P6450_CPU_ID, S5P64XX_CPU_MASK)
IS_SAMSUNG_CPU(s5pc100, S5PC100_CPU_ID, S5PC100_CPU_MASK)
IS_SAMSUNG_CPU(s5pv210, S5PV210_CPU_ID, S5PV210_CPU_MASK)
+IS_SAMSUNG_CPU(exynos3250, EXYNOS3250_SOC_ID, EXYNOS3_SOC_MASK)
IS_SAMSUNG_CPU(exynos4210, EXYNOS4210_CPU_ID, EXYNOS4_CPU_MASK)
IS_SAMSUNG_CPU(exynos4212, EXYNOS4212_CPU_ID, EXYNOS4_CPU_MASK)
IS_SAMSUNG_CPU(exynos4412, EXYNOS4412_CPU_ID, EXYNOS4_CPU_MASK)
@@ -126,6 +130,12 @@ IS_SAMSUNG_CPU(exynos5440, EXYNOS5440_SOC_ID,
EXYNOS5_SOC_MASK)
# define soc_is_s5pv210()0
#endif
+#if defined(CONFIG_SOC_EXYNOS3250)
+# define soc_is_exynos3250()is_samsung_exynos3250()
+#else
+# define soc_is_exynos3250()0
+#endif
In general, I think we have too much code littered with soc_is_foo()
going
on, so please try to avoid adding more for this SoC. Especially in cases
where
you just want to bail out of certain features where we might already have
function pointers to control if a function is called or not, such as the
firmware interfaces.
Do you prefer dt helper function such as following function instead of new
soc_is_xx() ?
- of_machine_is_compatible(samsung,exynos3250)
If you are OK, I'll use of_machine_is_compatible() instead of soc_is_xx().
First of all, there is still a lot of code in mach-exynos/ using the
soc_is_xx() macros, so having some SoCs use them and other SoCs use
of_machine_is_compatible() wouldn't make the code cleaner.
For now, I wouldn't mind adding soc_is_exynos3250(), but in general such
code surrounded with if (soc_is_xx()) blocks should be reworked to use
something better, for example function pointers, as Olof suggested.
I thought 'function pointers' method instead of soc_is_xxx() macro as
following two case:
I need more detailed explanation/example of for example function pointers,
as Olof suggested. sentence.
[case 1]
Each Exynos SoC has other function pointers according to compatible name of
DT.
For example, arch/arm/mach-exynos/firmware.c
static const struct firmware_ops exynos_firmware_ops = {
.do_idle= exynos_do_idle,
.set_cpu_boot_addr= exynos_set_cpu_boot_addr,
.cpu_boot= exynos_cpu_boot,
};
static const struct firmware_ops exynos3250_firmware_ops = {
.do_idle= exynos_do_idle,
.set_cpu_boot_addr= exynos4212_set_cpu_boot_addr,
.cpu_boot= exynos3250_cpu_boot,
};
static const struct firmware_ops exynos4212_firmware_ops = {
.do_idle= exynos_do_idle,
.set_cpu_boot_addr= exynos4212_set_cpu_boot_addr,
.cpu_boot= exynos4212_cpu_boot,
};
struct secure_firmware {
char *name;
const struct firmware_ops *ops;
} exynos_secure_firmware[] __initconst = {
{ samsung,secure-firmware,exynos_firmware_ops },
{ samsung,exynos3250-secure-firmware, exynos3250_firmware_ops },
{ samsung,exynos4212-secure-firmware, exynos4212_firmware_ops },
};
This is probably the right solution. Another would be to detect which
firmware ops to use by matching root node with particular SoC compatible
strings.
OK, I'll modify firmware.c using this method on separated patch apart from
Exynos3250 patchset.
But, I want to implment it after completed Exynos3250 patchset.
Because Exynos3250 patchset needs other patch such as following patch:
Following patches has not yet to be confirmed or merged.
[PATCH Resend] ARM: EXYNOS: Map SYSRAM address through DT
- http://www.spinics.net/lists/arm-kernel/msg323011.html
[PATCH v2 1/3] ARM: EXYNOS: Map PMU address through DT
- http://www.spinics.net/lists/arm-kernel/msg316013.html
Thanks for your review.
Best regards,
Chanwoo Choi
--
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: [PATCHv3 1/5] drm: exynos: hdmi: remove usage of struct s5p_hdmi_platform_data
Hi Tomasz,
On 04/17/2014 12:12 AM, Tomasz Stanislawski wrote:
This patch continues shift of DRM EXYNOS to DT-only configuration.
The usage of the old structure for HDMI's platform data is
removed.
Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 30 --
1 file changed, 8 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 9a6d652..482ca77 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -43,7 +43,6 @@
#include exynos_mixer.h
#include linux/gpio.h
-#include media/s5p_hdmi.h
#define get_hdmi_display(dev) platform_get_drvdata(to_platform_device(dev))
#define ctx_from_connector(c) container_of(c, struct hdmi_context, connector)
@@ -2011,28 +2010,18 @@ fail:
return -ENODEV;
}
-static struct s5p_hdmi_platform_data *drm_hdmi_dt_parse_pdata
- (struct device *dev)
+static int drm_hdmi_dt_parse(struct hdmi_context *hdata, struct device_node
*np)
{
- struct device_node *np = dev-of_node;
- struct s5p_hdmi_platform_data *pd;
u32 value;
- pd = devm_kzalloc(dev, sizeof(*pd), GFP_KERNEL);
- if (!pd)
- goto err_data;
-
if (!of_find_property(np, hpd-gpio, value)) {
DRM_ERROR(no hpd gpio property found\n);
- goto err_data;
+ return -ENOENT;
}
- pd-hpd_gpio = of_get_named_gpio(np, hpd-gpio, 0);
-
- return pd;
+ hdata-hpd_gpio = of_get_named_gpio(np, hpd-gpio, 0);
-err_data:
- return NULL;
+ return 0;
}
static struct of_device_id hdmi_match_types[] = {
@@ -2051,7 +2040,6 @@ static int hdmi_probe(struct platform_device *pdev)
{
struct device *dev = pdev-dev;
struct hdmi_context *hdata;
- struct s5p_hdmi_platform_data *pdata;
struct resource *res;
const struct of_device_id *match;
struct device_node *ddc_node, *phy_node;
@@ -2061,14 +2049,14 @@ static int hdmi_probe(struct platform_device *pdev)
if (!dev-of_node)
return -ENODEV;
- pdata = drm_hdmi_dt_parse_pdata(dev);
- if (!pdata)
- return -EINVAL;
-
hdata = devm_kzalloc(dev, sizeof(struct hdmi_context), GFP_KERNEL);
if (!hdata)
return -ENOMEM;
+ ret = drm_hdmi_dt_parse(hdata, dev-of_node);
+ if (ret)
+ return -EINVAL;
It's better to return ret value.
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/3] ARM: EXYNOS: Map PMU address through DT
Hi Vikas,
As you comment, I found the history of this patch in mailing list.
It seems like that this patch stop the review.
Besides, Pankaj posted same patch to support PMU as following:
- https://lkml.org/lkml/2014/4/2/48
Do you have a plan to resend or not?
because I need this patch to remove PMU static memory mapping for Exynos3250.
Best Regards,
Chanwoo Choi
On 03/17/2014 10:09 PM, Vikas Sajjan wrote:
Instead of hardcoding the PMU details for each SoC, pass this information
through device tree (DT).
Signed-off-by: Vikas Sajjan vikas.saj...@samsung.com
---
.../devicetree/bindings/arm/samsung/pmu.txt|5 +-
arch/arm/boot/dts/exynos4.dtsi |5 ++
arch/arm/boot/dts/exynos5260.dtsi |5 ++
arch/arm/mach-exynos/common.c | 51
+---
arch/arm/mach-exynos/include/mach/map.h|3 --
5 files changed, 47 insertions(+), 22 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/samsung/pmu.txt
b/Documentation/devicetree/bindings/arm/samsung/pmu.txt
index f1f1552..667a7f0 100644
--- a/Documentation/devicetree/bindings/arm/samsung/pmu.txt
+++ b/Documentation/devicetree/bindings/arm/samsung/pmu.txt
@@ -2,14 +2,15 @@ SAMSUNG Exynos SoC series PMU Registers
Properties:
- compatible : should contain two values. First value must be one from
following list:
+- samsung,exynos4210-pmu - for Exynos4210 and Exynos4x12
SoC,
- samsung,exynos5250-pmu - for Exynos5250 SoC,
-- samsung,exynos5420-pmu - for Exynos5420 SoC.
+- samsung,exynos5420-pmu - for Exynos5420 and Exynos5260
SoC.
second value must be always syscon.
- reg : offset and length of the register set.
Example :
pmu_system_controller: system-controller@1004 {
- compatible = samsung,exynos5250-pmu, syscon;
+ compatible = samsung,exynos5250-pmu;
reg = 0x1004 0x5000;
};
diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index 08452e1..94cbafa 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -55,6 +55,11 @@
#phy-cells = 1;
};
+ pmu_system_controller: system-controller@1002 {
+ compatible = samsung,exynos4210-pmu;
+ reg = 0x1002 0x4000;
+ };
+
pd_mfc: mfc-power-domain@10023C40 {
compatible = samsung,exynos4210-pd;
reg = 0x10023C40 0x20;
diff --git a/arch/arm/boot/dts/exynos5260.dtsi
b/arch/arm/boot/dts/exynos5260.dtsi
index a93fea8..2a4dace 100644
--- a/arch/arm/boot/dts/exynos5260.dtsi
+++ b/arch/arm/boot/dts/exynos5260.dtsi
@@ -264,6 +264,11 @@
};
};
+ pmu_system_controller: system-controller@10D5 {
+ compatible = samsung,exynos5420-pmu;
+ reg = 0x10D5 0x5000;
+ };
+
pinctrl_0: pinctrl@1160 {
compatible = samsung,exynos5260-pinctrl;
reg = 0x1160 0x1000;
diff --git a/arch/arm/mach-exynos/common.c b/arch/arm/mach-exynos/common.c
index 1df81ff..c75733b 100644
--- a/arch/arm/mach-exynos/common.c
+++ b/arch/arm/mach-exynos/common.c
@@ -79,11 +79,6 @@ static struct map_desc exynos4_iodesc[] __initdata = {
.length = SZ_4K,
.type = MT_DEVICE,
}, {
- .virtual= (unsigned long)S5P_VA_PMU,
- .pfn= __phys_to_pfn(EXYNOS4_PA_PMU),
- .length = SZ_64K,
- .type = MT_DEVICE,
- }, {
.virtual= (unsigned long)S5P_VA_COMBINER_BASE,
.pfn= __phys_to_pfn(EXYNOS4_PA_COMBINER),
.length = SZ_4K,
@@ -157,11 +152,6 @@ static struct map_desc exynos5_iodesc[] __initdata = {
.pfn= __phys_to_pfn(EXYNOS5_PA_CMU),
.length = 144 * SZ_1K,
.type = MT_DEVICE,
- }, {
- .virtual= (unsigned long)S5P_VA_PMU,
- .pfn= __phys_to_pfn(EXYNOS5_PA_PMU),
- .length = SZ_64K,
- .type = MT_DEVICE,
},
};
@@ -243,12 +233,12 @@ static int __init exynos_fdt_map_chipid(unsigned long
node, const char *uname,
return 1;
}
-struct __sysram_desc {
+struct __exynos_reg_desc {
char name[32];
unsigned long addr;
};
-static struct __sysram_desc sysram_desc[] __initdata = {
+static struct __exynos_reg_desc exynos_sysram_desc[] __initdata = {
{
.name = samsung,exynos4210-sysram,
.addr = (unsigned long)S5P_VA_SYSRAM,
@@ -258,7 +248,20 @@ static struct __sysram_desc sysram_desc[] __initdata = {
},
};
-static int __init
Re: [RFC PATCH 05/14] ARM: dts: samsung-fimd: add I80 specific properties
Hi Laurent Thank you for the comment. On 04/17/2014 06:26 AM, Laurent Pinchart wrote: Hi YoungJun, Thank you for the patch. On Tuesday 15 April 2014 14:47:33 YoungJun Cho wrote: In case of using CPU interface panel, the relevant registers should be set. So this patch adds relevant dt bindings. Signed-off-by: YoungJun Cho yj44@samsung.com Signed-off-by: Inki Dae inki@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com --- .../devicetree/bindings/video/samsung-fimd.txt |9 + 1 file changed, 9 insertions(+) diff --git a/Documentation/devicetree/bindings/video/samsung-fimd.txt b/Documentation/devicetree/bindings/video/samsung-fimd.txt index 2dad41b..924c2e1 100644 --- a/Documentation/devicetree/bindings/video/samsung-fimd.txt +++ b/Documentation/devicetree/bindings/video/samsung-fimd.txt @@ -44,6 +44,15 @@ Optional Properties: - display-timings: timing settings for FIMD, as described in document [1]. Can be used in case timings cannot be provided otherwise or to override timings provided by the panel. +- samsung,sysreg-phandle: handle to syscon used to control the system Oops... I have to change samsung,sysreg-phandle to samsung,sysreg. registers +- vidout-i80-ldi: boolean to support i80 interface instead of rgb one +- cs-setup: clock cycles for the active period of address signal enable until + chip select is enable in i80 interface +- wr-setup: clock cycles for the active period of CS signal enable until + write signal is enable in i80 interface +- wr-act: clock cycles for the active period of CS enable in i80 interface +- wr-hold: clock cycles for the active period of CS disable until write signal +is disable in i80 interface Shouldn't the interface parameters be considered as a property of the slave device instead ? The bus master side is programmable, and different slaves would have different timing requirements. I think it would make more sense to specify the timings on the slave (panel) side and query them dynamically at runtime. Depending on the slave the timings could be hardcoded in the driver (as they're usually an intrinsic property of the slave) or partially or fully specified in the slave DT node. Yes, you're right. These properties are related to panel in a sense. But my intention is to use these properties to fimd node in the board specific dts file, because it decides the interface with panel and these are required by fimd only. If dynamic query is more logical approach, I should find some ways with considering probing order. Thank you. Best regards YJ The device node can contain 'port' child nodes according to the bindings defined in [2]. The following are properties specific to those nodes: -- 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
