Re: [PATCH v3 01/12] ARM: EXYNOS: Make exynos machine_ops as static
Hi Pankaj,
On 30 April 2014 10:47, Pankaj Dubey pankaj.du...@samsung.com wrote:
As machine function ops are used only in this file let's make
them static.
Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com
---
arch/arm/mach-exynos/exynos.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
index 3d69e8d..06dcce5 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -198,7 +198,7 @@ static struct map_desc exynos5_iodesc[] __initdata = {
},
};
-void exynos_restart(enum reboot_mode mode, const char *cmd)
+static void exynos_restart(enum reboot_mode mode, const char *cmd)
{
struct device_node *np;
u32 val = 0x1;
@@ -239,7 +239,7 @@ void __init exynos_cpufreq_init(void)
platform_device_register_simple(exynos-cpufreq, -1, NULL, 0);
}
-void __init exynos_init_late(void)
+static void __init exynos_init_late(void)
{
if (of_machine_is_compatible(samsung,exynos5440))
/* to be supported later */
@@ -300,7 +300,7 @@ static void __init exynos_map_io(void)
iotable_init(exynos5250_iodesc,
ARRAY_SIZE(exynos5250_iodesc));
}
-void __init exynos_init_io(void)
+static void __init exynos_init_io(void)
{
debug_ll_io_init();
The declarations from common.h should also be removed in this patch to
avoid the below
build errors:
arch/arm/mach-exynos/exynos.c:198:13: error: static declaration of
‘exynos_restart’ follows non-static declaration
static void exynos_restart(enum reboot_mode mode, const char *cmd)
^
In file included from arch/arm/mach-exynos/exynos.c:31:0:
arch/arm/mach-exynos/common.h:22:6: note: previous declaration of
‘exynos_restart’ was here
void exynos_restart(enum reboot_mode mode, const char *cmd);
^
arch/arm/mach-exynos/exynos.c:235:20: error: static declaration of
‘exynos_init_late’ follows non-static declaration
static void __init exynos_init_late(void)
^
In file included from arch/arm/mach-exynos/exynos.c:31:0:
arch/arm/mach-exynos/common.h:25:6: note: previous declaration of
‘exynos_init_late’ was here
void exynos_init_late(void);
^
arch/arm/mach-exynos/exynos.c:296:20: error: static declaration of
‘exynos_init_io’ follows non-static declaration
static void __init exynos_init_io(void)
^
In file included from arch/arm/mach-exynos/exynos.c:31:0:
arch/arm/mach-exynos/common.h:21:6: note: previous declaration of
‘exynos_init_io’ was here
void exynos_init_io(void);
--
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 3/8] ARM: dts: imx6: update pcie to bring in line with new binding
On Fri, Mar 28, 2014 at 05:52:54PM +0100, Lucas Stach wrote: The new bindings drops one clock, renames the others and drops the old interrupt mapping. Signed-off-by: Lucas Stach l.st...@pengutronix.de It does not apply on my branch, and I had to apply it manually. Please check my imx/dt branch to see if I did it right. Shawn -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 11/12] ARM: EXYNOS: Add platform driver support for Exynos PMU.
Hi Pankaj,
On Wed, Apr 30, 2014 at 10:47 AM, Pankaj Dubey pankaj.du...@samsung.com wrote:
This patch modifies Exynos Power Management Unit (PMU) initialization
implementation in following way:
- Added platform_device support by registering static platform device.
- Added platform struct exynos_pmu_data to hold platform specific data.
- For each SoC's PMU support now we can add platform data and statically
bind PMU configuration and SoC specific initialization function.
- Probe function will scan DT and based on matching PMU compatibility
string initialize pmu_context which will be platform_data for driver.
- Obtain PMU regmap handle using syscon_regmap_lookup_by_phandle so
that we can reduce dependency over machine header files.
- Separate each SoC's PMU initialization function and make it as part of
platform data.
- It also removes uses of soc_is_exynos() thus making PMU implementation
independent of plat/cpu.h.
Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com
Signed-off-by: Young-Gun Jang yg1004.j...@samsung.com
---
arch/arm/mach-exynos/pmu.c | 280
+++-
1 file changed, 224 insertions(+), 56 deletions(-)
diff --git a/arch/arm/mach-exynos/pmu.c b/arch/arm/mach-exynos/pmu.c
index 67116a5..030df96 100644
--- a/arch/arm/mach-exynos/pmu.c
+++ b/arch/arm/mach-exynos/pmu.c
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2011-2012 Samsung Electronics Co., Ltd.
+ * Copyright (c) 2011-2014 Samsung Electronics Co., Ltd.
* http://www.samsung.com/
*
* EXYNOS - CPU PMU(Power Management Unit) support
@@ -9,20 +9,33 @@
* published by the Free Software Foundation.
*/
-#include linux/io.h
-#include linux/kernel.h
+#include linux/module.h
#include linux/regmap.h
-
-#include plat/cpu.h
+#include linux/of.h
+#include linux/platform_device.h
+#include linux/slab.h
+#include linux/mfd/syscon.h
#include common.h
#include regs-pmu.h
-static const struct exynos_pmu_conf *exynos_pmu_config;
-static struct regmap *pmu_regmap;
+struct exynos_pmu_data {
+ const struct exynos_pmu_conf *pmu_config;
+ const struct exynos_pmu_conf *pmu_config_extra;
+ void (*pmu_init)(void);
+ void (*powerdown_conf)(enum sys_powerdown);
+};
+
+struct exynos_pmu_context {
+ struct device *dev;
+ struct exynos_pmu_data *pmu_data;
+ struct regmap *pmu_regmap;
+};
+
+static struct exynos_pmu_context *pmu_context;
static const struct exynos_pmu_conf exynos4210_pmu_config[] = {
- /* { .reg = address, .val = { AFTR, LPA, SLEEP } */
+ /* { .offset = address, .val = { AFTR, LPA, SLEEP } */
{ S5P_ARM_CORE0_LOWPWR, { 0x0, 0x0, 0x2 } },
{ S5P_DIS_IRQ_CORE0,{ 0x0, 0x0, 0x0 } },
{ S5P_DIS_IRQ_CENTRAL0, { 0x0, 0x0, 0x0 } },
@@ -216,7 +229,7 @@ static const struct exynos_pmu_conf
exynos4412_pmu_config[] = {
};
static const struct exynos_pmu_conf exynos5250_pmu_config[] = {
- /* { .reg = address, .val = { AFTR, LPA, SLEEP } */
+ /* { .offset = address, .val = { AFTR, LPA, SLEEP } */
{ EXYNOS5_ARM_CORE0_SYS_PWR_REG,{ 0x0, 0x0, 0x2} },
{ EXYNOS5_DIS_IRQ_ARM_CORE0_LOCAL_SYS_PWR_REG, { 0x0, 0x0, 0x0} },
{ EXYNOS5_DIS_IRQ_ARM_CORE0_CENTRAL_SYS_PWR_REG,{ 0x0, 0x0,
0x0} },
@@ -339,7 +352,7 @@ static unsigned int const exynos5_list_diable_wfi_wfe[] =
{
EXYNOS5_ISP_ARM_OPTION,
};
-static void exynos5_init_pmu(void)
+void exynos5_powerdown_conf(enum sys_powerdown mode)
{
unsigned int i;
unsigned int tmp;
@@ -348,81 +361,236 @@ static void exynos5_init_pmu(void)
* Enable both SC_FEEDBACK and SC_COUNTER
*/
for (i = 0 ; i ARRAY_SIZE(exynos5_list_both_cnt_feed) ; i++) {
- regmap_read(pmu_regmap, exynos5_list_both_cnt_feed[i], tmp);
+ regmap_read(pmu_context-pmu_regmap,
+ exynos5_list_both_cnt_feed[i], tmp);
tmp |= (EXYNOS5_USE_SC_FEEDBACK |
EXYNOS5_USE_SC_COUNTER);
- regmap_write(pmu_regmap, exynos5_list_both_cnt_feed[i], tmp);
+ regmap_write(pmu_context-pmu_regmap,
+ exynos5_list_both_cnt_feed[i], tmp);
}
/*
* SKIP_DEACTIVATE_ACEACP_IN_PWDN_BITFIELD Enable
*/
- regmap_read(pmu_regmap, EXYNOS5_ARM_COMMON_OPTION, tmp);
+ regmap_read(pmu_context-pmu_regmap, EXYNOS5_ARM_COMMON_OPTION, tmp);
tmp |= EXYNOS5_SKIP_DEACTIVATE_ACEACP_IN_PWDN;
- regmap_write(pmu_regmap, EXYNOS5_ARM_COMMON_OPTION, tmp);
+ regmap_write(pmu_context-pmu_regmap, EXYNOS5_ARM_COMMON_OPTION, tmp);
/*
* Disable WFI/WFE on XXX_OPTION
*/
for (i = 0 ; i ARRAY_SIZE(exynos5_list_diable_wfi_wfe) ; i++) {
-
Re: [PATCH 51/97] ARM: l2c: remove platforms/SoCs setting early BRESP
On Tue, Apr 29, 2014 at 10:17:01AM -0600, Stephen Warren wrote: On 04/28/2014 06:02 PM, Simon Horman wrote: On Mon, Apr 28, 2014 at 08:30:32PM +0100, Russell King wrote: Since we now automatically enable early BRESP in core L2C-310 code when we detect a Cortex-A9, we don't need platforms/SoCs to set this bit explicitly. Instead, they should seek to preserve the value of bit 30 in the auxiliary control register. Acked-by: Tony Lindgren t...@atomide.com Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk I would prefer if this patch was broken out into individual patches for each board or SoC file and that they were then picked up by their respective platform maintainers. Likewise for patch 66/97. Although it is only for shmobile I would prefer it broken out. There are far too many dependencies in this series to break out the board file patches to be merged separately; it'd take either a whole bunch of kernel releases to merge it all that way, or a twisty maze of tiny topic branches cross-merged all over the place. Neither option is realistic. Understood, that seems reasonable to me. For the shmobile portions this patch and 66/97. Acked-by: Simon Horman horms+rene...@verge.net.au -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] cpufreq: Removed exynos_sort_descend_freq_table funtion
After applying PM / OPP: Add support for descending order for cpufreq
table
,to make the table descending we can use OPP_TABLE_ORDER_DESCEND flag.
Signed-off-by: Jonghwan Choi jhbird.c...@samsung.com
---
drivers/cpufreq/exynos5440-cpufreq.c | 22 +-
1 file changed, 1 insertion(+), 21 deletions(-)
diff --git a/drivers/cpufreq/exynos5440-cpufreq.c
b/drivers/cpufreq/exynos5440-cpufreq.c
index a6b8214..fc19beb 100644
--- a/drivers/cpufreq/exynos5440-cpufreq.c
+++ b/drivers/cpufreq/exynos5440-cpufreq.c
@@ -279,25 +279,6 @@ static irqreturn_t exynos_cpufreq_irq(int irq, void
*id)
return IRQ_HANDLED;
}
-static void exynos_sort_descend_freq_table(void)
-{
- struct cpufreq_frequency_table *freq_tbl = dvfs_info-freq_table;
- int i = 0, index;
- unsigned int tmp_freq;
- /*
-* Exynos5440 clock controller state logic expects the cpufreq table
to
-* be in descending order. But the OPP library constructs the table
in
-* ascending order. So to make the table descending we just need to
-* swap the i element with the N - i element.
-*/
- for (i = 0; i dvfs_info-freq_count / 2; i++) {
- index = dvfs_info-freq_count - i - 1;
- tmp_freq = freq_tbl[i].frequency;
- freq_tbl[i].frequency = freq_tbl[index].frequency;
- freq_tbl[index].frequency = tmp_freq;
- }
-}
-
static int exynos_cpufreq_cpu_init(struct cpufreq_policy *policy)
{
policy-clk = dvfs_info-cpu_clk;
@@ -367,14 +348,13 @@ static int exynos_cpufreq_probe(struct platform_device
*pdev)
}
ret = dev_pm_opp_init_cpufreq_table(dvfs_info-dev,
- dvfs_info-freq_table);
+ dvfs_info-freq_table, OPP_TABLE_ORDER_DESCEND);
if (ret) {
dev_err(dvfs_info-dev,
failed to init cpufreq table: %d\n, ret);
goto err_put_node;
}
dvfs_info-freq_count = dev_pm_opp_get_opp_count(dvfs_info-dev);
- exynos_sort_descend_freq_table();
if (of_property_read_u32(np, clock-latency, dvfs_info-latency))
dvfs_info-latency = DEF_TRANS_LATENCY;
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] cpufreq: Pass third argument as function parameter is
In dev_pm_opp_init_cpufreq_table, flags parameter is added to
indicate descending order. If flags is zero, it is a ascending
order.
Signed-off-by: Jonghwan Choi jhbird.c...@samsung.com
---
drivers/cpufreq/arm_big_little.c |2 +-
drivers/cpufreq/cpufreq-cpu0.c |2 +-
drivers/cpufreq/imx6q-cpufreq.c |2 +-
drivers/cpufreq/omap-cpufreq.c |2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/cpufreq/arm_big_little.c
b/drivers/cpufreq/arm_big_little.c
index bad2ed3..851f53b 100644
--- a/drivers/cpufreq/arm_big_little.c
+++ b/drivers/cpufreq/arm_big_little.c
@@ -332,7 +332,7 @@ static int _get_cluster_clk_and_freq_table(struct device
*cpu_dev)
goto out;
}
- ret = dev_pm_opp_init_cpufreq_table(cpu_dev, freq_table[cluster]);
+ ret = dev_pm_opp_init_cpufreq_table(cpu_dev, freq_table[cluster],
0);
if (ret) {
dev_err(cpu_dev, %s: failed to init cpufreq table, cpu: %d,
err: %d\n,
__func__, cpu_dev-id, ret);
diff --git a/drivers/cpufreq/cpufreq-cpu0.c b/drivers/cpufreq/cpufreq-cpu0.c
index 1bf6bba..2557860 100644
--- a/drivers/cpufreq/cpufreq-cpu0.c
+++ b/drivers/cpufreq/cpufreq-cpu0.c
@@ -158,7 +158,7 @@ static int cpu0_cpufreq_probe(struct platform_device
*pdev)
goto out_put_node;
}
- ret = dev_pm_opp_init_cpufreq_table(cpu_dev, freq_table);
+ ret = dev_pm_opp_init_cpufreq_table(cpu_dev, freq_table, 0);
if (ret) {
pr_err(failed to init cpufreq table: %d\n, ret);
goto out_put_node;
diff --git a/drivers/cpufreq/imx6q-cpufreq.c
b/drivers/cpufreq/imx6q-cpufreq.c
index e27fca8..c2bf03f 100644
--- a/drivers/cpufreq/imx6q-cpufreq.c
+++ b/drivers/cpufreq/imx6q-cpufreq.c
@@ -212,7 +212,7 @@ static int imx6q_cpufreq_probe(struct platform_device
*pdev)
}
}
- ret = dev_pm_opp_init_cpufreq_table(cpu_dev, freq_table);
+ ret = dev_pm_opp_init_cpufreq_table(cpu_dev, freq_table, 0);
if (ret) {
dev_err(cpu_dev, failed to init cpufreq table: %d\n, ret);
goto put_node;
diff --git a/drivers/cpufreq/omap-cpufreq.c b/drivers/cpufreq/omap-cpufreq.c
index 5f69c9a..afe9bf8 100644
--- a/drivers/cpufreq/omap-cpufreq.c
+++ b/drivers/cpufreq/omap-cpufreq.c
@@ -119,7 +119,7 @@ static int omap_cpu_init(struct cpufreq_policy *policy)
return PTR_ERR(policy-clk);
if (!freq_table) {
- result = dev_pm_opp_init_cpufreq_table(mpu_dev,
freq_table);
+ result = dev_pm_opp_init_cpufreq_table(mpu_dev, freq_table,
0);
if (result) {
dev_err(mpu_dev,
%s: cpu%d: failed creating freq
table[%d]\n,
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] ARM: dts: Add peach-pit board support
Hi,
On Sat, Apr 26, 2014 at 5:02 PM, Tomasz Figa tomasz.f...@gmail.com wrote:
Hi Arun,
On 24.04.2014 06:17, Arun Kumar K wrote:
Adds the google peach-pit board dts file which uses
exynos5420 SoC.
Signed-off-by: Arun Kumar K arun...@samsung.com
Signed-off-by: Doug Anderson diand...@chromium.org
---
Changes from v1
---
- Addressed review comments from Doug, Sachin Tushar
- Removed adc and lid-switch nodes
---
arch/arm/boot/dts/Makefile |1 +
arch/arm/boot/dts/exynos5420-peach-pit.dts | 182
2 files changed, 183 insertions(+)
create mode 100644 arch/arm/boot/dts/exynos5420-peach-pit.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 35c146f..3220e29 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -74,6 +74,7 @@ dtb-$(CONFIG_ARCH_EXYNOS) += exynos4210-origen.dtb \
exynos5250-smdk5250.dtb \
exynos5250-snow.dtb \
exynos5420-arndale-octa.dtb \
+ exynos5420-peach-pit.dtb \
exynos5420-smdk5420.dtb \
exynos5440-sd5v1.dtb \
exynos5440-ssdk5440.dtb
diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts
b/arch/arm/boot/dts/exynos5420-peach-pit.dts
new file mode 100644
index 000..fbb0469
--- /dev/null
+++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
@@ -0,0 +1,182 @@
+/*
+ * Google Peach Pit Rev 6+ board device tree source
+ *
+ * Copyright (c) 2014 Google, Inc
+ *
+ * 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.
+ */
+
+/dts-v1/;
+#include dt-bindings/input/input.h
+#include dt-bindings/gpio/gpio.h
+#include exynos5420.dtsi
+
+/ {
+ model = Google Peach Pit Rev 6+;
+
+ compatible = google,pit-rev16,
+ google,pit-rev15, google,pit-rev14,
+ google,pit-rev13, google,pit-rev12,
+ google,pit-rev11, google,pit-rev10,
+ google,pit-rev9, google,pit-rev8,
+ google,pit-rev7, google,pit-rev6,
+ google,pit, google,peach,samsung,exynos5420,
+ samsung,exynos5;
Do you really need so many compatible strings here? Furthermore, are all the
newer revisions really fully backwards compatible with older ones?
Also, do you have a way to check the revision in hardware, e.g. by some GPIO
pins? If so, I don't think there would be any need to revision number as a
part of compatible string.
+
+ memory {
+ reg = 0x2000 0x8000;
+ };
+
+ fixed-rate-clocks {
+ oscclk {
+ compatible = samsung,exynos5420-oscclk;
+ clock-frequency = 2400;
+ };
+ };
+
+ pinctrl@1340 {
Please convert this dts file into reference-based syntax. It has multiple
advantages over the legacy way of replicating full paths every time a node
needs to be updated.
You can see other dts files for examples how this can be used, e.g.
s3c64*.dts* (for a quite simple setup), imx6*.dts* (for more complex
things), etc.
+ tpm_irq: tpm-irq {
+ samsung,pins = gpx1-0;
+ samsung,pin-function = 0;
+ samsung,pin-pud = 0;
+ samsung,pin-drv = 0;
+ };
+
+ power_key_irq: power-key-irq {
+ samsung,pins = gpx1-2;
+ samsung,pin-function = 0;
+ samsung,pin-pud = 0;
+ samsung,pin-drv = 0;
+ };
+ };
+
+ pinctrl@1401 {
+ spi_flash_cs: spi-flash-cs {
+ samsung,pins = gpa2-5;
+ samsung,pin-function = 1;
+ samsung,pin-pud = 0;
+ samsung,pin-drv = 3;
+ };
+
+ backlight_pwm: backlight-pwm {
+ samsung,pins = gpb2-0;
+ samsung,pin-function = 2;
+ samsung,pin-pud = 0;
+ samsung,pin-drv = 0;
+ };
+ };
+
+ gpio-keys {
+ compatible = gpio-keys;
+
+ pinctrl-names = default;
+ pinctrl-0 = power_key_irq;
+
+ power {
+ label = Power;
+ gpios = gpx1 2 GPIO_ACTIVE_LOW;
+ linux,code = KEY_POWER;
+ gpio-key,wakeup;
+ };
+ };
+
+ rtc@101E {
+ status = okay;
+ };
+
+ serial@12C3 {
+ status = okay;
+ };
+
+ mmc@1220 {
+ status = okay;
+ num-slots = 1;
+ broken-cd;
Re: [PATCHv2 1/3] phy: Add exynos-simple-phy driver
Hi Tomasz,
I have tested your patches for exynos5250 and 5420. Works fine. Are
you planning to post v3? If you want I can share hand with you for v3.
Regards,
Rahul Sharma
On 9 April 2014 17:17, Andreas Oberritter o...@saftware.de wrote:
Hello Andrzej,
On 09.04.2014 10:37, Andrzej Hajda wrote:
+static int exynos_phy_probe(struct platform_device *pdev)
+{
+const struct of_device_id *of_id = of_match_device(
+of_match_ptr(exynos_phy_of_match), pdev-dev);
+const u32 *offsets = of_id-data;
+int count;
+struct device *dev = pdev-dev;
+struct phy **phys;
+struct resource *res;
+void __iomem *regs;
+int i;
+struct phy_provider *phy_provider;
+
+/* count number of phys to create */
+for (count = 0; offsets[count] != ~0; ++count)
+;
count = ARRAY_SIZE(offsets) - 1;
u32 *offsets is not an array.
Regards,
Andreas
--
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 4/7] arm64: Add a description on 48-bit address space with 4KB pages
On Tuesday, April 29, 2014 11:48 PM, Catalin Marinas wrote: On Tue, Apr 29, 2014 at 05:59:27AM +0100, Jungseok Lee wrote: --- a/Documentation/arm64/memory.txt +++ b/Documentation/arm64/memory.txt @@ -8,10 +8,11 @@ This document describes the virtual memory layout used by the AArch64 Linux kernel. The architecture allows up to 4 levels of translation tables with a 4KB page size and up to 3 levels with a 64KB page size. -AArch64 Linux uses 3 levels of translation tables with the 4KB page -configuration, allowing 39-bit (512GB) virtual addresses for both user -and kernel. With 64KB pages, only 2 levels of translation tables are -used but the memory layout is the same. +AArch64 Linux uses 3 levels and 4 levels of translation tables with +the 4KB page configuration, allowing 39-bit (512GB) and 48-bit +(256TB) virtual addresses, respectively, for both user and kernel. +With 64KB pages, only 2 levels of translation tables are used but the +memory layout is the same. Any reason why we couldn't use 48-bit address space with 64K pages (implying 3 levels)? No technical reason. Since 64K+3levels is not implemented in this set, I didn't add it. Should 64K+3levels be prepared in this patchset? -AArch64 Linux memory layout with 64KB pages: +AArch64 Linux memory layout with 4KB pages + 4 levels: + +Start End SizeUse +--- + 256TB user + + 7bfe~124TB vmalloc BTW, maybe as a separate patch we should change the end to be exclusive. It becomes harder to modify (I've been through this a few times already ;)) and even follow the changes. Does exclusive mean that is changed to 0001? Or Does it mean that End column is dropped? If you are okay, I will make it as a separate patch. Best Regards Jungseok Lee -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 01/12] ARM: EXYNOS: Make exynos machine_ops as static
Hi Sachin,
On 04/30/2014 03:00 PM, Sachin Kamat wrote:
Hi Pankaj,
On 30 April 2014 10:47, Pankaj Dubey pankaj.du...@samsung.com wrote:
As machine function ops are used only in this file let's make
them static.
Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com
---
arch/arm/mach-exynos/exynos.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
index 3d69e8d..06dcce5 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -198,7 +198,7 @@ static struct map_desc exynos5_iodesc[] __initdata = {
},
};
-void exynos_restart(enum reboot_mode mode, const char *cmd)
+static void exynos_restart(enum reboot_mode mode, const char *cmd)
{
struct device_node *np;
u32 val = 0x1;
@@ -239,7 +239,7 @@ void __init exynos_cpufreq_init(void)
platform_device_register_simple(exynos-cpufreq, -1, NULL, 0);
}
-void __init exynos_init_late(void)
+static void __init exynos_init_late(void)
{
if (of_machine_is_compatible(samsung,exynos5440))
/* to be supported later */
@@ -300,7 +300,7 @@ static void __init exynos_map_io(void)
iotable_init(exynos5250_iodesc, ARRAY_SIZE(exynos5250_iodesc));
}
-void __init exynos_init_io(void)
+static void __init exynos_init_io(void)
{
debug_ll_io_init();
The declarations from common.h should also be removed in this patch to
avoid the below
build errors:
Thanks. I will merge changes in common.h in this patch itself.
arch/arm/mach-exynos/exynos.c:198:13: error: static declaration of
‘exynos_restart’ follows non-static declaration
static void exynos_restart(enum reboot_mode mode, const char *cmd)
^
In file included from arch/arm/mach-exynos/exynos.c:31:0:
arch/arm/mach-exynos/common.h:22:6: note: previous declaration of
‘exynos_restart’ was here
void exynos_restart(enum reboot_mode mode, const char *cmd);
^
arch/arm/mach-exynos/exynos.c:235:20: error: static declaration of
‘exynos_init_late’ follows non-static declaration
static void __init exynos_init_late(void)
^
In file included from arch/arm/mach-exynos/exynos.c:31:0:
arch/arm/mach-exynos/common.h:25:6: note: previous declaration of
‘exynos_init_late’ was here
void exynos_init_late(void);
^
arch/arm/mach-exynos/exynos.c:296:20: error: static declaration of
‘exynos_init_io’ follows non-static declaration
static void __init exynos_init_io(void)
^
In file included from arch/arm/mach-exynos/exynos.c:31:0:
arch/arm/mach-exynos/common.h:21:6: note: previous declaration of
‘exynos_init_io’ was here
void exynos_init_io(void);
--
Best Regards,
Pankaj Dubey
--
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: [PATCHv4 4/7] ARM: EXYNOS: Enter a15 lowpower mode for Exynos3250 based on Cortex-a7
Hi Tomasz,
On 04/26/2014 09:25 AM, Tomasz Figa wrote:
Hi Chanwoo,
On 25.04.2014 03:16, Chanwoo Choi wrote:
This patch decide proper lowpower mode of either a15 or a9 according to own
ID
from Main ID register.
Cc: Arnd Bergmann a...@arndb.de
Cc: Marc Zynigier marc.zyng...@arm.com
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
arch/arm/mach-exynos/hotplug.c | 19 ---
1 file changed, 12 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-exynos/hotplug.c b/arch/arm/mach-exynos/hotplug.c
index 5eead53..acf3119 100644
--- a/arch/arm/mach-exynos/hotplug.c
+++ b/arch/arm/mach-exynos/hotplug.c
@@ -135,16 +135,21 @@ 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
- * number by reading the Main ID register and then perform the
- * appropriate sequence for entering low power.
+ * 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.
*/
-asm(mrc p15, 0, %0, c0, c0, 0 : =r(primary_part) : : cc);
-if ((primary_part 0xfff0) == 0xc0f0)
+primary_part = read_cpuid_part_number();
+
+switch (primary_part) {
+case ARM_CPU_PART_CORTEX_A7:
+case ARM_CPU_PART_CORTEX_A15:
cpu_enter_lowpower_a15();
-else
+break;
+default:
cpu_enter_lowpower_a9();
+break;
+}
platform_do_lowpower(cpu, spurious);
I have noticed Leela Krishna Amudala's patch [1] that removes this
distinction completely and simply uses generic code. Could you check if this
works on Exynos3250 as well? If yes, then this patch could be dropped and
Leela's one would be enough.
[1]
http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg29064.html
OK, I tested this patch[1] to turn on secondary CPu on Exynos3250.
I'll drop following patch on next posting(v5) by using Leela Krishna Amudala's
patch [1].
- ARM: EXYNOS: Enter a15 lowpower mode for Exynos3250 based on Cortex-a7
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] ARM: EXYNOS: cpu hotplug: use v7_exit_coherency_flush macro for cache disabling
Hi,
On 04/23/2014 02:52 PM, Leela Krishna Amudala wrote:
A common macro v7_exit_coherency_flush available which does the below tasks in
the seqeunce.
-clearing C bit
-clearing L1 cache
-exit SMP
-instruction and data synchronization
So removing the local functions which does the same thing and use the macro
instead.
Signed-off-by: Leela Krishna Amudala leela.kris...@linaro.org
Acked-by: Nicolas Pitre n...@linaro.org
---
Changes since V1:
- removed unwanted primary_part variable in exynos_cpu_die()
- given more description in commit message
suggested by Daniel Lezcano daniel.lezc...@linaro.org
arch/arm/mach-exynos/hotplug.c | 63
+---
1 file changed, 1 insertion(+), 62 deletions(-)
diff --git a/arch/arm/mach-exynos/hotplug.c b/arch/arm/mach-exynos/hotplug.c
index 5eead53..9ca692d 100644
--- a/arch/arm/mach-exynos/hotplug.c
+++ b/arch/arm/mach-exynos/hotplug.c
@@ -24,56 +24,6 @@
#include common.h
#include regs-pmu.h
-static inline void cpu_enter_lowpower_a9(void)
-{
- unsigned int v;
-
- asm volatile(
-mcr p15, 0, %1, c7, c5, 0\n
-mcr p15, 0, %1, c7, c10, 4\n
- /*
- * Turn off coherency
- */
-mrc p15, 0, %0, c1, c0, 1\n
-bic %0, %0, %3\n
-mcr p15, 0, %0, c1, c0, 1\n
-mrc p15, 0, %0, c1, c0, 0\n
-bic %0, %0, %2\n
-mcr p15, 0, %0, c1, c0, 0\n
- : =r (v)
- : r (0), Ir (CR_C), Ir (0x40)
- : cc);
-}
-
-static inline void cpu_enter_lowpower_a15(void)
-{
- unsigned int v;
-
- asm volatile(
-mrc p15, 0, %0, c1, c0, 0\n
-bic %0, %0, %1\n
-mcr p15, 0, %0, c1, c0, 0\n
- : =r (v)
- : Ir (CR_C)
- : cc);
-
- flush_cache_louis();
-
- asm volatile(
- /*
- * Turn off coherency
- */
-mrc p15, 0, %0, c1, c0, 1\n
-bic %0, %0, %1\n
-mcr p15, 0, %0, c1, c0, 1\n
- : =r (v)
- : Ir (0x40)
- : cc);
-
- isb();
- dsb();
-}
-
static inline void cpu_leave_lowpower(void)
{
unsigned int v;
@@ -132,19 +82,8 @@ static inline void platform_do_lowpower(unsigned int cpu,
int *spurious)
void __ref exynos_cpu_die(unsigned int cpu)
{
int spurious = 0;
- 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
- * number by reading the Main ID register and then perform the
- * appropriate sequence for entering low power.
- */
- asm(mrc p15, 0, %0, c0, c0, 0 : =r(primary_part) : : cc);
- if ((primary_part 0xfff0) == 0xc0f0)
- cpu_enter_lowpower_a15();
- else
- cpu_enter_lowpower_a9();
+ v7_exit_coherency_flush(louis);
platform_do_lowpower(cpu, spurious);
I tested this patch on Exynos3250 based on Cortex-A7 dual core.
Tested-by: Chanwoo Choi cw00.c...@samsung.com
Thanks,
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] ARM: EXYNOS: cpu hotplug: use v7_exit_coherency_flush macro for cache disabling
Hello Kgene,
Can you please pick this patch to your tree ?
Best Wishes,
Leela Krishna.
On Wed, Apr 30, 2014 at 1:32 PM, Chanwoo Choi cw00.c...@samsung.com wrote:
Hi,
On 04/23/2014 02:52 PM, Leela Krishna Amudala wrote:
A common macro v7_exit_coherency_flush available which does the below tasks
in
the seqeunce.
-clearing C bit
-clearing L1 cache
-exit SMP
-instruction and data synchronization
So removing the local functions which does the same thing and use the macro
instead.
Signed-off-by: Leela Krishna Amudala leela.kris...@linaro.org
Acked-by: Nicolas Pitre n...@linaro.org
---
Changes since V1:
- removed unwanted primary_part variable in exynos_cpu_die()
- given more description in commit message
suggested by Daniel Lezcano daniel.lezc...@linaro.org
arch/arm/mach-exynos/hotplug.c | 63
+---
1 file changed, 1 insertion(+), 62 deletions(-)
diff --git a/arch/arm/mach-exynos/hotplug.c b/arch/arm/mach-exynos/hotplug.c
index 5eead53..9ca692d 100644
--- a/arch/arm/mach-exynos/hotplug.c
+++ b/arch/arm/mach-exynos/hotplug.c
@@ -24,56 +24,6 @@
#include common.h
#include regs-pmu.h
-static inline void cpu_enter_lowpower_a9(void)
-{
- unsigned int v;
-
- asm volatile(
-mcr p15, 0, %1, c7, c5, 0\n
-mcr p15, 0, %1, c7, c10, 4\n
- /*
- * Turn off coherency
- */
-mrc p15, 0, %0, c1, c0, 1\n
-bic %0, %0, %3\n
-mcr p15, 0, %0, c1, c0, 1\n
-mrc p15, 0, %0, c1, c0, 0\n
-bic %0, %0, %2\n
-mcr p15, 0, %0, c1, c0, 0\n
- : =r (v)
- : r (0), Ir (CR_C), Ir (0x40)
- : cc);
-}
-
-static inline void cpu_enter_lowpower_a15(void)
-{
- unsigned int v;
-
- asm volatile(
-mrc p15, 0, %0, c1, c0, 0\n
-bic %0, %0, %1\n
-mcr p15, 0, %0, c1, c0, 0\n
- : =r (v)
- : Ir (CR_C)
- : cc);
-
- flush_cache_louis();
-
- asm volatile(
- /*
- * Turn off coherency
- */
-mrc p15, 0, %0, c1, c0, 1\n
-bic %0, %0, %1\n
-mcr p15, 0, %0, c1, c0, 1\n
- : =r (v)
- : Ir (0x40)
- : cc);
-
- isb();
- dsb();
-}
-
static inline void cpu_leave_lowpower(void)
{
unsigned int v;
@@ -132,19 +82,8 @@ static inline void platform_do_lowpower(unsigned int
cpu, int *spurious)
void __ref exynos_cpu_die(unsigned int cpu)
{
int spurious = 0;
- 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
- * number by reading the Main ID register and then perform the
- * appropriate sequence for entering low power.
- */
- asm(mrc p15, 0, %0, c0, c0, 0 : =r(primary_part) : : cc);
- if ((primary_part 0xfff0) == 0xc0f0)
- cpu_enter_lowpower_a15();
- else
- cpu_enter_lowpower_a9();
+ v7_exit_coherency_flush(louis);
platform_do_lowpower(cpu, spurious);
I tested this patch on Exynos3250 based on Cortex-A7 dual core.
Tested-by: Chanwoo Choi cw00.c...@samsung.com
Thanks,
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: [PATCHv2 1/3] phy: Add exynos-simple-phy driver
Hi Rahul,
I will prepare we v3 version.
Do you want me to add your patches for exynos5?50 to the patchset?
Regards,
Tomasz Stanislawski
On 04/30/2014 08:37 AM, Rahul Sharma wrote:
Hi Tomasz,
I have tested your patches for exynos5250 and 5420. Works fine. Are
you planning to post v3? If you want I can share hand with you for v3.
Regards,
Rahul Sharma
On 9 April 2014 17:17, Andreas Oberritter o...@saftware.de wrote:
Hello Andrzej,
On 09.04.2014 10:37, Andrzej Hajda wrote:
+static int exynos_phy_probe(struct platform_device *pdev)
+{
+const struct of_device_id *of_id = of_match_device(
+of_match_ptr(exynos_phy_of_match), pdev-dev);
+const u32 *offsets = of_id-data;
+int count;
+struct device *dev = pdev-dev;
+struct phy **phys;
+struct resource *res;
+void __iomem *regs;
+int i;
+struct phy_provider *phy_provider;
+
+/* count number of phys to create */
+for (count = 0; offsets[count] != ~0; ++count)
+;
count = ARRAY_SIZE(offsets) - 1;
u32 *offsets is not an array.
Regards,
Andreas
--
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 v3 05/12] ARM: EXYNOS: Remove file path from comment section
Hi Pankaj, On 30 April 2014 10:47, Pankaj Dubey pankaj.du...@samsung.com wrote: Many files under arm/mach-exynos are having file path in file comment section which is invalid now. So for better code maintainability let's remove them. Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com Reviewed-by: Tomasz Figa t.f...@samsung.com --- The change is sensible. However Kukjin had refused to accept such patches when I had submitted patches doing such cleanup for all Samsung platform files. Anyway, FWIW Reviewed-by: Sachin Kamat sachin.ka...@linaro.org -- With warm regards, Sachin -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 1/3] phy: Add exynos-simple-phy driver
Sure (5250, 5420). I will wait for the same to update DT patches, if any.
Regards,
Rahul Sharma.
On 30 April 2014 14:02, Tomasz Stanislawski t.stanisl...@samsung.com wrote:
Hi Rahul,
I will prepare we v3 version.
Do you want me to add your patches for exynos5?50 to the patchset?
Regards,
Tomasz Stanislawski
On 04/30/2014 08:37 AM, Rahul Sharma wrote:
Hi Tomasz,
I have tested your patches for exynos5250 and 5420. Works fine. Are
you planning to post v3? If you want I can share hand with you for v3.
Regards,
Rahul Sharma
On 9 April 2014 17:17, Andreas Oberritter o...@saftware.de wrote:
Hello Andrzej,
On 09.04.2014 10:37, Andrzej Hajda wrote:
+static int exynos_phy_probe(struct platform_device *pdev)
+{
+const struct of_device_id *of_id = of_match_device(
+of_match_ptr(exynos_phy_of_match), pdev-dev);
+const u32 *offsets = of_id-data;
+int count;
+struct device *dev = pdev-dev;
+struct phy **phys;
+struct resource *res;
+void __iomem *regs;
+int i;
+struct phy_provider *phy_provider;
+
+/* count number of phys to create */
+for (count = 0; offsets[count] != ~0; ++count)
+;
count = ARRAY_SIZE(offsets) - 1;
u32 *offsets is not an array.
Regards,
Andreas
--
To unsubscribe from this list: send the line unsubscribe
linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/4] ARM: dts: Add usb 2.0 support on exynos5420
Add required device node for ehci and ohci controllers to
enable USB 2.0 support.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
arch/arm/boot/dts/exynos5420.dtsi | 36 +++-
1 file changed, 35 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch/arm/boot/dts/exynos5420.dtsi
index 16b860a..392d340 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -738,7 +738,41 @@
samsung,power-domain = g2d_pd;
};
- phy@1213 {
+ usb@1211 {
+ compatible = samsung,exynos4210-ehci;
+ reg = 0x1211 0x100;
+ interrupts = 0 71 0;
+
+ clocks = clock CLK_USBH20;
+ clock-names = usbhost;
+ #address-cells = 1;
+ #size-cells = 0;
+ port@0 {
+ reg = 0;
+ phys = usb2_phy_gen 1;
+ phy-names = host;
+ status = ok;
+ };
+ };
+
+ usb@1212 {
+ compatible = samsung,exynos4210-ohci;
+ reg = 0x1212 0x100;
+ interrupts = 0 71 0;
+
+ clocks = clock CLK_USBH20;
+ clock-names = usbhost;
+ #address-cells = 1;
+ #size-cells = 0;
+ port@0 {
+ reg = 0;
+ phys = usb2_phy_gen 1;
+ phy-names = host;
+ status = ok;
+ };
+ };
+
+ usb2_phy_gen: phy@1213 {
compatible = samsung,exynos5250-usb2-phy;
reg = 0x1213 0x100;
clocks = clock CLK_USBH20, clock CLK_SCLK_USBPHY300;
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/4] ARM: dts: Add usb2phy support on exynos5420
Add required device node for usb2phy to let enable USB 2.0
support.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
arch/arm/boot/dts/exynos5420.dtsi | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch/arm/boot/dts/exynos5420.dtsi
index cfa3755..16b860a 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -737,4 +737,14 @@
clock-names = secss;
samsung,power-domain = g2d_pd;
};
+
+ phy@1213 {
+ compatible = samsung,exynos5250-usb2-phy;
+ reg = 0x1213 0x100;
+ clocks = clock CLK_USBH20, clock CLK_SCLK_USBPHY300;
+ clock-names = phy, ref;
+ #phy-cells = 1;
+ samsung,sysreg-phandle = sysreg_system_controller;
+ samsung,pmureg-phandle = pmu_system_controller;
+ };
};
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/4] dts: Add usb2phy to Exynos 5250/5420
Next version for earlier patch-series: [PATCH v7 0/2] dts: Add usb2phy to Exynos 5250 Based on 'for-next' branch of Kgene's linux-samsung tree. Tested with driver side patches: [PATCH v2 1/4] usb: ohci-exynos: Use struct device instead of platform_device [PATCH v2 2/4] usb: ehci-exynos: Use struct device instead of platform_device [PATCH v4 1/2] usb: ohci-exynos: Add facility to use phy provided by the generic phy framework [PATCH v10 4/4] usb: ehci-exynos: Change to use phy provided by the generic phy framework Changes from v7 series: - Added patches to enable usb 2.0 support on exynos5420; which include dt nodes for usb2phy as well as ehci and ohci controllers. Changes from v6: - Splitted the patch into two: adding syscon nodes to Exynos5250 and Exynos5420 in first; and phy entry change in the second. - Changed the name of phandle for usb2phy from 'usb2_phy_new' to 'usb2_phy_gen' indicating generic phy. - Using clock macros in dt entries. Kamil Debski (1): ARM: dts: Add usb2phy to Exynos 5250 Vivek Gautam (3): ARM: dts: Add sysreg sytem controller node to exynos5250 and exynos5420 ARM: dts: Add usb2phy support on exynos5420 ARM: dts: Add usb 2.0 support on exynos5420 arch/arm/boot/dts/exynos5250.dtsi | 31 +++ arch/arm/boot/dts/exynos5420.dtsi | 49 + 2 files changed, 80 insertions(+) -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/4] ARM: dts: Add usb2phy to Exynos 5250
From: Kamil Debski k.deb...@samsung.com
Add support to PHY of USB2 of the Exynos 5250 SoC.
Signed-off-by: Kamil Debski k.deb...@samsung.com
[gautam.vi...@samsung.com: Split the usb phy entries from
syscon entries from earlier patch: dts: Add usb2phy to Exynos 5250]
[gautam.vi...@samsung.com: Added phy entry for OHCI also along with EHCI]
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
Changes from v7:
None
arch/arm/boot/dts/exynos5250.dtsi | 26 ++
1 file changed, 26 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index 70f0cd5..51e554c 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -563,6 +563,14 @@
clocks = clock CLK_USB2;
clock-names = usbhost;
+ #address-cells = 1;
+ #size-cells = 0;
+ port@0 {
+ reg = 0;
+ phys = usb2_phy_gen 1;
+ phy-names = host;
+ status = ok;
+ };
};
usb@1212 {
@@ -572,6 +580,14 @@
clocks = clock CLK_USB2;
clock-names = usbhost;
+ #address-cells = 1;
+ #size-cells = 0;
+ port@0 {
+ reg = 0;
+ phys = usb2_phy_gen 1;
+ phy-names = host;
+ status = ok;
+ };
};
usb2_phy: usbphy@1213 {
@@ -589,6 +605,16 @@
};
};
+ usb2_phy_gen: phy@1213 {
+ compatible = samsung,exynos5250-usb2-phy;
+ reg = 0x1213 0x100;
+ clocks = clock CLK_USB2, clock CLK_FIN_PLL;
+ clock-names = phy, ref;
+ #phy-cells = 1;
+ samsung,sysreg-phandle = sysreg_system_controller;
+ samsung,pmureg-phandle = pmu_system_controller;
+ };
+
pwm: pwm@12dd {
compatible = samsung,exynos4210-pwm;
reg = 0x12dd 0x100;
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v8 1/4] ARM: dts: Add sysreg sytem controller node to exynos5250 and exynos5420
This patch adds sysreg-syscon node to exynos5250 and exynos5420 device
tree, to access System Register's registers using syscon driver.
Signed-off-by: Kamil Debski k.deb...@samsung.com
[gautam.vi...@samsung.com: Split this syreg-syscon dts entry from
dts: Add usb2phy to Exynos 5250 patch]
[gautam.vi...@samsung.com: added similar syscon entry for exynos5420]
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
Changes from v7:
None
arch/arm/boot/dts/exynos5250.dtsi |5 +
arch/arm/boot/dts/exynos5420.dtsi |5 +
2 files changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index 3742331..70f0cd5 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -175,6 +175,11 @@
reg = 0x1004 0x5000;
};
+ sysreg_system_controller: syscon@1005 {
+ compatible = samsung,exynos5250-sys, syscon;
+ reg = 0x1005 0x5000;
+ };
+
watchdog@101D {
compatible = samsung,exynos5250-wdt;
reg = 0x101D 0x100;
diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch/arm/boot/dts/exynos5420.dtsi
index c3a9a66..cfa3755 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -675,6 +675,11 @@
reg = 0x1004 0x5000;
};
+ sysreg_system_controller: syscon@1005 {
+ compatible = samsung,exynos5420-sys, syscon;
+ reg = 0x1005 0x5000;
+ };
+
tmu_cpu0: tmu@1006 {
compatible = samsung,exynos5420-tmu;
reg = 0x1006 0x100;
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/5 v3] iio: exynos_adc: use indio_dev-dev structure to handle child nodes
From: Naveen Krishna Ch ch.nav...@samsung.com
Using pdev-dev with device_for_each_child() would iterate over all
of the children of the platform device and delete them.
Thus, causing crashes during module unload.
We should be using the indio_dev-dev structure for
registering/unregistering child nodes.
Signed-off-by: Naveen Krishna Ch ch.nav...@samsung.com
Reported-by: Doug Anderson diand...@chromium.org
Reviewed-by: Doug Anderson diand...@chromium.org
Tested-by: Doug Anderson diand...@chromium.org
---
Changes since v2:
None
Changes since v1:
Adding Doug's tags
v0:
This change was tested on top of
https://lkml.org/lkml/2014/4/21/481 from Doug.
drivers/iio/adc/exynos_adc.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/iio/adc/exynos_adc.c b/drivers/iio/adc/exynos_adc.c
index d25b262..affa93f 100644
--- a/drivers/iio/adc/exynos_adc.c
+++ b/drivers/iio/adc/exynos_adc.c
@@ -344,7 +344,7 @@ static int exynos_adc_probe(struct platform_device *pdev)
exynos_adc_hw_init(info);
- ret = of_platform_populate(np, exynos_adc_match, NULL, pdev-dev);
+ ret = of_platform_populate(np, exynos_adc_match, NULL, indio_dev-dev);
if (ret 0) {
dev_err(pdev-dev, failed adding child nodes\n);
goto err_of_populate;
@@ -353,7 +353,7 @@ static int exynos_adc_probe(struct platform_device *pdev)
return 0;
err_of_populate:
- device_for_each_child(pdev-dev, NULL,
+ device_for_each_child(indio_dev-dev, NULL,
exynos_adc_remove_devices);
regulator_disable(info-vdd);
clk_disable_unprepare(info-clk);
@@ -369,7 +369,7 @@ static int exynos_adc_remove(struct platform_device *pdev)
struct iio_dev *indio_dev = platform_get_drvdata(pdev);
struct exynos_adc *info = iio_priv(indio_dev);
- device_for_each_child(pdev-dev, NULL,
+ device_for_each_child(indio_dev-dev, NULL,
exynos_adc_remove_devices);
regulator_disable(info-vdd);
clk_disable_unprepare(info-clk);
--
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 5/5 v3] iio: exynos_adc: do a reinit_completion before the conversion
Add reinit_completion() before the wait_for_completion_timeout in
raw_read() call.
Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
Reviewed-by: Doug Anderson diand...@chromium.org
---
Changes since v2:
None
Changes since v1:
None
v0:
This change is a part of the patch reviewed at
https://lkml.org/lkml/2013/11/5/92
drivers/iio/adc/exynos_adc.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/iio/adc/exynos_adc.c b/drivers/iio/adc/exynos_adc.c
index eddc58e..010578f 100644
--- a/drivers/iio/adc/exynos_adc.c
+++ b/drivers/iio/adc/exynos_adc.c
@@ -151,6 +151,7 @@ static int exynos_read_raw(struct iio_dev *indio_dev,
return -EINVAL;
mutex_lock(indio_dev-mlock);
+ reinit_completion(info-completion);
/* Select the channel to be used and Trigger conversion */
if (info-version == ADC_V2) {
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/5 v3] iio: exynos_adc: do a soft reset in case of timeout
Do a soft reset software if a timeout happens.
This is applicable only for ADC_V2.
Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
Reviewed-by: Doug Anderson diand...@chromium.org
---
Changes since v2:
None
Changes since v1:
None
v0:
This change is a part of the patch reviewed at
https://lkml.org/lkml/2013/11/5/92
drivers/iio/adc/exynos_adc.c | 50 ++
1 file changed, 26 insertions(+), 24 deletions(-)
diff --git a/drivers/iio/adc/exynos_adc.c b/drivers/iio/adc/exynos_adc.c
index 939aaf7..eddc58e 100644
--- a/drivers/iio/adc/exynos_adc.c
+++ b/drivers/iio/adc/exynos_adc.c
@@ -112,6 +112,30 @@ static inline unsigned int exynos_adc_get_version(struct
platform_device *pdev)
return (unsigned int)match-data;
}
+static void exynos_adc_hw_init(struct exynos_adc *info)
+{
+ u32 con1, con2;
+
+ if (info-version == ADC_V2) {
+ con1 = ADC_V2_CON1_SOFT_RESET;
+ writel(con1, ADC_V2_CON1(info-regs));
+
+ con2 = ADC_V2_CON2_OSEL | ADC_V2_CON2_ESEL |
+ ADC_V2_CON2_HIGHF | ADC_V2_CON2_C_TIME(0);
+ writel(con2, ADC_V2_CON2(info-regs));
+
+ /* Enable interrupts */
+ writel(1, ADC_V2_INT_EN(info-regs));
+ } else {
+ /* set default prescaler values and Enable prescaler */
+ con1 = ADC_V1_CON_PRSCLV(49) | ADC_V1_CON_PRSCEN;
+
+ /* Enable 12-bit ADC resolution */
+ con1 |= ADC_V1_CON_RES;
+ writel(con1, ADC_V1_CON(info-regs));
+ }
+}
+
static int exynos_read_raw(struct iio_dev *indio_dev,
struct iio_chan_spec const *chan,
int *val,
@@ -149,6 +173,8 @@ static int exynos_read_raw(struct iio_dev *indio_dev,
timeout = wait_for_completion_timeout
(info-completion, EXYNOS_ADC_TIMEOUT);
if (timeout == 0) {
+ dev_warn(indio_dev-dev, Conversion timed out! Resetting\n);
+ exynos_adc_hw_init(info);
ret = -ETIMEDOUT;
} else {
*val = info-value;
@@ -230,30 +256,6 @@ static int exynos_adc_remove_devices(struct device *dev,
void *c)
return 0;
}
-static void exynos_adc_hw_init(struct exynos_adc *info)
-{
- u32 con1, con2;
-
- if (info-version == ADC_V2) {
- con1 = ADC_V2_CON1_SOFT_RESET;
- writel(con1, ADC_V2_CON1(info-regs));
-
- con2 = ADC_V2_CON2_OSEL | ADC_V2_CON2_ESEL |
- ADC_V2_CON2_HIGHF | ADC_V2_CON2_C_TIME(0);
- writel(con2, ADC_V2_CON2(info-regs));
-
- /* Enable interrupts */
- writel(1, ADC_V2_INT_EN(info-regs));
- } else {
- /* set default prescaler values and Enable prescaler */
- con1 = ADC_V1_CON_PRSCLV(49) | ADC_V1_CON_PRSCEN;
-
- /* Enable 12-bit ADC resolution */
- con1 |= ADC_V1_CON_RES;
- writel(con1, ADC_V1_CON(info-regs));
- }
-}
-
static int exynos_adc_probe(struct platform_device *pdev)
{
struct exynos_adc *info = NULL;
--
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 0/5 v3] iio: exynos_adc: fix minor nits in the driver
This patchset fixes the 1. bug causing a crash during module removal for exynos_adc.ko. - The bug was seen by Doug, while trying to compile the whole IIO subsystem as module @ https://lkml.org/lkml/2014/4/21/481 from Doug. 2. rearrange the clock and regulator enable/disable calls during probe, remove, suspend and resume calls - Comments give by Jonathan @ https://lkml.org/lkml/2014/4/23/644 3. reduces the timeout and uses wait_for_completion_timeout instead of the interruptible varient. - This change was under review @ https://lkml.org/lkml/2013/11/5/92 Final comments were given by Tomasz, to split and submit. Naveen Krishna Ch (2): iio: exynos_adc: use indio_dev-dev structure to handle child nodes iio: exynos_adc: rearrange clk and regulator enable/disable calls Naveen Krishna Chatradhi (3): iio: exynos_adc: reduce timeout and use wait_for_completion_timeout iio: exynos_adc: do a soft reset in case of timeout iio: exynos_adc: do a reinit_completion before the conversion drivers/iio/adc/exynos_adc.c | 137 +++--- 1 file changed, 74 insertions(+), 63 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/5 v3] iio: exynos_adc: reduce timeout and use wait_for_completion_timeout
ADC module on Exynos5 SoCs runs at 600KSPS. At this conversion rate,
waiting for 1000 msecs is wasteful (incase of h/w failure).
Hence, reduce the time out to 100msecs and use
wait_for_completion_timeout() instead of
wait_for_completion_interruptible_timeout()
Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
Reviewed-by: Doug Anderson diand...@chromium.org
---
Changes since v2:
None
Changes since v1:
None
v0:
This change is a part of the patch reviewd at https://lkml.org/lkml/2013/11/5/92
drivers/iio/adc/exynos_adc.c | 18 +++---
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/drivers/iio/adc/exynos_adc.c b/drivers/iio/adc/exynos_adc.c
index ff98c5d..939aaf7 100644
--- a/drivers/iio/adc/exynos_adc.c
+++ b/drivers/iio/adc/exynos_adc.c
@@ -82,7 +82,7 @@ enum adc_version {
#define ADC_CON_EN_START (1u 0)
#define ADC_DATX_MASK 0xFFF
-#define EXYNOS_ADC_TIMEOUT (msecs_to_jiffies(1000))
+#define EXYNOS_ADC_TIMEOUT (msecs_to_jiffies(100))
struct exynos_adc {
void __iomem*regs;
@@ -121,6 +121,7 @@ static int exynos_read_raw(struct iio_dev *indio_dev,
struct exynos_adc *info = iio_priv(indio_dev);
unsigned long timeout;
u32 con1, con2;
+ int ret;
if (mask != IIO_CHAN_INFO_RAW)
return -EINVAL;
@@ -145,16 +146,19 @@ static int exynos_read_raw(struct iio_dev *indio_dev,
ADC_V1_CON(info-regs));
}
- timeout = wait_for_completion_interruptible_timeout
+ timeout = wait_for_completion_timeout
(info-completion, EXYNOS_ADC_TIMEOUT);
- *val = info-value;
+ if (timeout == 0) {
+ ret = -ETIMEDOUT;
+ } else {
+ *val = info-value;
+ *val2 = 0;
+ ret = IIO_VAL_INT;
+ }
mutex_unlock(indio_dev-mlock);
- if (timeout == 0)
- return -ETIMEDOUT;
-
- return IIO_VAL_INT;
+ return ret;
}
static irqreturn_t exynos_adc_isr(int irq, void *dev_id)
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/5 v3] iio: exynos_adc: rearrange clk and regulator enable/disable calls
From: Naveen Krishna Ch ch.nav...@samsung.com
This patch maintains the following order in
probe(), remove(), resume() and suspend() calls
regulator enable, clk prepare enable
...
clk disable unprepare, regulator disable
While at it,
1. enable the regulator before the iio_device_register()
2. handle the return values for enable/disable calls
Signed-off-by: Naveen Krishna Ch ch.nav...@samsung.com
Reviewed-by: Doug Anderson diand...@chromium.org
---
Changes since v2:
Remove extra unused line and add Doug's Reviewed-by
Changes since v1:
corrected the register/unregister and enabling/disbaling sequences
drivers/iio/adc/exynos_adc.c | 62 ++
1 file changed, 33 insertions(+), 29 deletions(-)
diff --git a/drivers/iio/adc/exynos_adc.c b/drivers/iio/adc/exynos_adc.c
index affa93f..ff98c5d 100644
--- a/drivers/iio/adc/exynos_adc.c
+++ b/drivers/iio/adc/exynos_adc.c
@@ -290,32 +290,30 @@ static int exynos_adc_probe(struct platform_device *pdev)
init_completion(info-completion);
- ret = request_irq(info-irq, exynos_adc_isr,
- 0, dev_name(pdev-dev), info);
- if (ret 0) {
- dev_err(pdev-dev, failed requesting irq, irq = %d\n,
- info-irq);
- return ret;
- }
-
- writel(1, info-enable_reg);
-
info-clk = devm_clk_get(pdev-dev, adc);
if (IS_ERR(info-clk)) {
dev_err(pdev-dev, failed getting clock, err = %ld\n,
PTR_ERR(info-clk));
- ret = PTR_ERR(info-clk);
- goto err_irq;
+ return PTR_ERR(info-clk);
}
info-vdd = devm_regulator_get(pdev-dev, vdd);
if (IS_ERR(info-vdd)) {
dev_err(pdev-dev, failed getting regulator, err = %ld\n,
PTR_ERR(info-vdd));
- ret = PTR_ERR(info-vdd);
- goto err_irq;
+ return PTR_ERR(info-vdd);
}
+ ret = regulator_enable(info-vdd);
+ if (ret)
+ return ret;
+
+ ret = clk_prepare_enable(info-clk);
+ if (ret)
+ goto err_disable_reg;
+
+ writel(1, info-enable_reg);
+
info-version = exynos_adc_get_version(pdev);
platform_set_drvdata(pdev, indio_dev);
@@ -332,16 +330,18 @@ static int exynos_adc_probe(struct platform_device *pdev)
else
indio_dev-num_channels = MAX_ADC_V2_CHANNELS;
+ ret = request_irq(info-irq, exynos_adc_isr,
+ 0, dev_name(pdev-dev), info);
+ if (ret 0) {
+ dev_err(pdev-dev, failed requesting irq, irq = %d\n,
+ info-irq);
+ goto err_disable_clk;
+ }
+
ret = iio_device_register(indio_dev);
if (ret)
goto err_irq;
- ret = regulator_enable(info-vdd);
- if (ret)
- goto err_iio_dev;
-
- clk_prepare_enable(info-clk);
-
exynos_adc_hw_init(info);
ret = of_platform_populate(np, exynos_adc_match, NULL, indio_dev-dev);
@@ -355,12 +355,14 @@ static int exynos_adc_probe(struct platform_device *pdev)
err_of_populate:
device_for_each_child(indio_dev-dev, NULL,
exynos_adc_remove_devices);
- regulator_disable(info-vdd);
- clk_disable_unprepare(info-clk);
-err_iio_dev:
iio_device_unregister(indio_dev);
err_irq:
free_irq(info-irq, info);
+err_disable_clk:
+ writel(0, info-enable_reg);
+ clk_disable_unprepare(info-clk);
+err_disable_reg:
+ regulator_disable(info-vdd);
return ret;
}
@@ -371,11 +373,11 @@ static int exynos_adc_remove(struct platform_device *pdev)
device_for_each_child(indio_dev-dev, NULL,
exynos_adc_remove_devices);
- regulator_disable(info-vdd);
- clk_disable_unprepare(info-clk);
- writel(0, info-enable_reg);
iio_device_unregister(indio_dev);
free_irq(info-irq, info);
+ writel(0, info-enable_reg);
+ clk_disable_unprepare(info-clk);
+ regulator_disable(info-vdd);
return 0;
}
@@ -397,8 +399,8 @@ static int exynos_adc_suspend(struct device *dev)
writel(con, ADC_V1_CON(info-regs));
}
- clk_disable_unprepare(info-clk);
writel(0, info-enable_reg);
+ clk_disable_unprepare(info-clk);
regulator_disable(info-vdd);
return 0;
@@ -414,9 +416,11 @@ static int exynos_adc_resume(struct device *dev)
if (ret)
return ret;
- writel(1, info-enable_reg);
- clk_prepare_enable(info-clk);
+ ret = clk_prepare_enable(info-clk);
+ if (ret)
+ return ret;
+ writel(1, info-enable_reg);
Re: [PATCH 3/8] ARM: dts: imx6: update pcie to bring in line with new binding
Am Mittwoch, den 30.04.2014, 14:02 +0800 schrieb Shawn Guo: On Fri, Mar 28, 2014 at 05:52:54PM +0100, Lucas Stach wrote: The new bindings drops one clock, renames the others and drops the old interrupt mapping. Signed-off-by: Lucas Stach l.st...@pengutronix.de It does not apply on my branch, and I had to apply it manually. Please check my imx/dt branch to see if I did it right. The diff as applied in your imx/dt looks good to me. 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 3/4] ARM: dts: Add usb2phy support on exynos5420
Hi Vivek,
On 04/30/14 14:25, Vivek Gautam wrote:
Add required device node for usb2phy to let enable USB 2.0
support.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
arch/arm/boot/dts/exynos5420.dtsi | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch/arm/boot/dts/exynos5420.dtsi
index cfa3755..16b860a 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -737,4 +737,14 @@
clock-names = secss;
samsung,power-domain = g2d_pd;
};
+
+ phy@1213 {
As we will be changing over to reference-based updation of nodes in the
board dts files, it would be good to add node reference also while
adding new nodes. Like : usb_phy: phy@1213 {
Regards
Arun
+ compatible = samsung,exynos5250-usb2-phy;
+ reg = 0x1213 0x100;
+ clocks = clock CLK_USBH20, clock CLK_SCLK_USBPHY300;
+ clock-names = phy, ref;
+ #phy-cells = 1;
+ samsung,sysreg-phandle = sysreg_system_controller;
+ samsung,pmureg-phandle = pmu_system_controller;
+ };
};
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] ARM: dts: Add usb2phy support on exynos5420
Hi Arun,
On Wed, Apr 30, 2014 at 3:55 PM, Arun Kumar K arunkk.sams...@gmail.com wrote:
Hi Vivek,
On 04/30/14 14:25, Vivek Gautam wrote:
Add required device node for usb2phy to let enable USB 2.0
support.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
arch/arm/boot/dts/exynos5420.dtsi | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch/arm/boot/dts/exynos5420.dtsi
index cfa3755..16b860a 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -737,4 +737,14 @@
clock-names = secss;
samsung,power-domain = g2d_pd;
};
+
+ phy@1213 {
As we will be changing over to reference-based updation of nodes in the
board dts files, it would be good to add node reference also while
adding new nodes. Like : usb_phy: phy@1213 {
Sure, i will add node-references to phy as well as the usb nodes in
the subsequent patch.
[snip]
--
Best Regards
Vivek Gautam
Samsung RD Institute, Bangalore
India
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ARM: dts: Add sound node for Snow board
On 04/24/2014 11:46 AM, Tushar Behera wrote:
The audio codec on Snow board, MAX98095 is connected on I2C7 bus.
Also it requires the GPX1-7 line to be pulled up.
Updated Snow DTS file to incorporate above changes and added a
sound node to instantiate the I2S-based sound card.
Signed-off-by: Tushar Behera tushar.beh...@linaro.org
---
arch/arm/boot/dts/exynos5250-snow.dts | 32
1 file changed, 32 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5250-snow.dts
b/arch/arm/boot/dts/exynos5250-snow.dts
index 1bc9b50..f63df3c 100644
--- a/arch/arm/boot/dts/exynos5250-snow.dts
+++ b/arch/arm/boot/dts/exynos5250-snow.dts
@@ -196,6 +196,38 @@
};
};
+ regulators {
+ compatible = simple-bus;
+ #address-cells = 1;
+ #size-cells = 0;
+
+ max98095-en-regulator {
+ compatible = regulator-fixed;
+ gpio = gpx1 7 0;
+ enable-active-high;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+ };
+
Instead of relying on regulator framework, I will add a related
pin-control entry and update sound node accordingly.
+ i2c@12CD {
+ max98095: codec@11 {
+ compatible = maxim,max98095;
+ reg = 0x11;
+ };
+ };
+
+ i2s0: i2s@0383 {
+ status = okay;
+ };
+
+ sound {
+ compatible = google,snow-audio-max98095;
+
+ samsung,i2s-controller = i2s0;
+ samsung,audio-codec = max98095;
+ };
+
usb@1211 {
samsung,vbus-gpio = gpx1 1 0;
};
--
Tushar Behera
--
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 30 April 2014 09:39:54 Sachin Kamat wrote: On 16 April 2014 22:55, Heiko Stübner he...@sntech.de wrote: 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. Thanks for your inputs. In our case, we use sram for secondary boot addresses but could not find any other general purpose use. So, depending on the above: Acked-by: Heiko Stuebner he...@sntech.de So I believe your ack applies to our case :). Thanks again. My interpretation is the opposite. :) For what I can tell, you use only part of the SRAM for this, and the rest could be used for something else, you just haven't had the need for it. If this is the case, you really should be using Heiko's binding instead, to make it future-proof in case some other use for the SRAM comes up. 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 v12 00/31] iommu/exynos: Fixes and Enhancements of System MMU driver with DT
On Mon, Apr 28, 2014 at 2:04 PM, Arnd Bergmann a...@arndb.de wrote: On Sunday 27 April 2014 13:07:32 Shaik Ameer Basha wrote: The current exynos-iommu(System MMU) driver does not work autonomously since it is lack of support for power management of peripheral blocks. For example, MFC device driver must ensure that its System MMU is disabled before MFC block is power-down not to invalidate IOTLB in the System MMU when I/O memory mapping is changed. Because a System MMU resides in the same H/W block, access to control registers of System MMU while the H/W block is turned off must be prohibited. This set of changes solves the above problem with setting each System MMUs as the parent of the device which owns the System MMU to receive the information when the device is turned off or turned on. Another big change to the driver is the support for devicetree. The bindings for System MMU is described in Documentation/devicetree/bindings/arm/samsung/system-mmu.txt Sorry I've been absent from the review so far. Most of the patches seem entirely reasonable to me, but I'm worried about the DT binding aspect. We are going to see more systems shipping with IOMMUs now, and we are seeing an increasing number of submissions for 64-bit systems. We really have to work out what the DT representation for IOMMUs should look like in general before adding another ad-hod implementation that is private to one driver. I have one question. This series is going on for quite a long time and most of the patches here doesn't depend on dt bindings. As Exynos IOMMU h/w is introducing new versions very frequently, maintaining and reviewing all these patches again and again is quite a hard job. If it is acceptable, I can post one more series with the subset of above patches, which doesn't depend on dt-bindings. As all the patches which doesn't depend on DT bindings are already tested, I hope merging these subset of patches may help in reducing the rework and review effort every time. Once we finalize the generic DT bindings for the IOMMU devices, the driver can be updated with the proposed DT bindings in mind. Regards, Shaik 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 -- 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 0/7 v8] crypto:s5p-sss: Add Device tree and Exynos support
Hello All, On 28 April 2014 16:14, Naveen Krishna Chatradhi ch.nav...@samsung.com wrote: SSS module on Exynos4210, Exynos5250 and Exynos5420 SoCs has added features to the one on S5PV210. However with minor changes the s5p-sss.c driver can be reused to support SSS modules on Exynos4 and 5 SoCs. This patch set 1. Adds device tree support to the s5p-sss.c driver and Documentation 2. Adds code to support SSS module on Exynos4 and 5 SoCs 3. Adds variant struct to handle the differences in SSS modules 4. Adds clk_prepare/clk_unprepare clocks to the s5p-sss.c driver Note: Compatible exynos4210-secss should work for Exynos4412 and Exynos5260 (Exynos5260, for which ARCH code is under review) I couldn't test on Exynos4412 and Exynos4210 boards, Should be able to test with addition of DT node and clocks support. These patches are under review at https://lkml.org/lkml/2014/2/17/124 Naveen Krishna Chatradhi (7): crypto:s5p-sss: Use platform_get_irq() instead of _byname() crypto:s5p-sss: Kconfig: Let Exynos SoCs select SSS driver crypto:s5p-sss: Look for the next request in the queue crypto:s5p-sss: Add device tree support crypto:s5p-sss: Add support for SSS module on Exynos crypto:s5p-sss: validate iv before memcpy crypto:s5p-sss: Use clk_prepare/clk_unprepare .../devicetree/bindings/crypto/samsung-sss.txt | 35 + drivers/crypto/Kconfig |6 +- drivers/crypto/s5p-sss.c | 145 +++- 3 files changed, 150 insertions(+), 36 deletions(-) create mode 100644 Documentation/devicetree/bindings/crypto/samsung-sss.txt Can we get this series merged in. Its has got reviewed and re-based several times and got acked by a couple of seniors. Thanks, -- 1.7.9.5 -- Shine bright, (: Nav :) -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 01/16] clk: exynos5420: rename parent clocks
Hi Shaik
On Thu, Apr 24, 2014 at 6:33 PM, Shaik Ameer Basha
shaik.am...@samsung.com wrote:
This patch modifies the defined parent clock names as per the
exynos5420 datasheet.
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
Signed-off-by: Shaik Ameer Basha shaik.am...@samsung.com
---
This looks good. Mostly renaming is done here.
For this you have my
Reviewed-by: Alim Akhtar alim.akh...@samsung.com
drivers/clk/samsung/clk-exynos5420.c | 359
++
1 file changed, 187 insertions(+), 172 deletions(-)
mode change 100644 = 100755 drivers/clk/samsung/clk-exynos5420.c
diff --git a/drivers/clk/samsung/clk-exynos5420.c
b/drivers/clk/samsung/clk-exynos5420.c
old mode 100644
new mode 100755
index 35311e1..389d4b1
--- a/drivers/clk/samsung/clk-exynos5420.c
+++ b/drivers/clk/samsung/clk-exynos5420.c
@@ -217,85 +217,92 @@ static void exynos5420_clk_sleep_init(void) {}
#endif
/* list of all parent clocks */
-PNAME(mspll_cpu_p) = { sclk_cpll, sclk_dpll,
- sclk_mpll, sclk_spll };
-PNAME(cpu_p) = { mout_apll , mout_mspll_cpu };
-PNAME(kfc_p) = { mout_kpll , mout_mspll_kfc };
-PNAME(apll_p) = { fin_pll, fout_apll, };
-PNAME(bpll_p) = { fin_pll, fout_bpll, };
-PNAME(cpll_p) = { fin_pll, fout_cpll, };
-PNAME(dpll_p) = { fin_pll, fout_dpll, };
-PNAME(epll_p) = { fin_pll, fout_epll, };
-PNAME(ipll_p) = { fin_pll, fout_ipll, };
-PNAME(kpll_p) = { fin_pll, fout_kpll, };
-PNAME(mpll_p) = { fin_pll, fout_mpll, };
-PNAME(rpll_p) = { fin_pll, fout_rpll, };
-PNAME(spll_p) = { fin_pll, fout_spll, };
-PNAME(vpll_p) = { fin_pll, fout_vpll, };
-
-PNAME(group1_p)= { sclk_cpll, sclk_dpll, sclk_mpll };
-PNAME(group2_p)= { fin_pll, sclk_cpll, sclk_dpll,
sclk_mpll,
- sclk_spll, sclk_ipll, sclk_epll, sclk_rpll
};
-PNAME(group3_p)= { sclk_rpll, sclk_spll };
-PNAME(group4_p)= { sclk_ipll, sclk_dpll, sclk_mpll };
-PNAME(group5_p)= { sclk_vpll, sclk_dpll };
-
-PNAME(sw_aclk66_p) = { dout_aclk66, sclk_spll };
-PNAME(aclk66_peric_p) = { fin_pll, mout_sw_aclk66 };
-
-PNAME(sw_aclk200_fsys_p) = { dout_aclk200_fsys, sclk_spll};
-PNAME(user_aclk200_fsys_p) = { fin_pll, mout_sw_aclk200_fsys };
-
-PNAME(sw_aclk200_fsys2_p) = { dout_aclk200_fsys2, sclk_spll};
-PNAME(user_aclk200_fsys2_p)= { fin_pll, mout_sw_aclk200_fsys2 };
-
-PNAME(sw_aclk200_p) = { dout_aclk200, sclk_spll};
-PNAME(aclk200_disp1_p) = { fin_pll, mout_sw_aclk200 };
-
-PNAME(sw_aclk400_mscl_p) = { dout_aclk400_mscl, sclk_spll};
-PNAME(user_aclk400_mscl_p) = { fin_pll, mout_sw_aclk400_mscl };
-
-PNAME(sw_aclk333_p) = { dout_aclk333, sclk_spll};
-PNAME(user_aclk333_p) = { fin_pll, mout_sw_aclk333 };
-
-PNAME(sw_aclk166_p) = { dout_aclk166, sclk_spll};
-PNAME(user_aclk166_p) = { fin_pll, mout_sw_aclk166 };
-
-PNAME(sw_aclk266_p) = { dout_aclk266, sclk_spll};
-PNAME(user_aclk266_p) = { fin_pll, mout_sw_aclk266 };
-
-PNAME(sw_aclk333_432_gscl_p) = { dout_aclk333_432_gscl, sclk_spll};
-PNAME(user_aclk333_432_gscl_p) = { fin_pll, mout_sw_aclk333_432_gscl };
-
-PNAME(sw_aclk300_gscl_p) = { dout_aclk300_gscl, sclk_spll};
-PNAME(user_aclk300_gscl_p) = { fin_pll, mout_sw_aclk300_gscl };
-
-PNAME(sw_aclk300_disp1_p) = { dout_aclk300_disp1, sclk_spll};
-PNAME(user_aclk300_disp1_p)= { fin_pll, mout_sw_aclk300_disp1 };
-
-PNAME(sw_aclk300_jpeg_p) = { dout_aclk300_jpeg, sclk_spll};
-PNAME(user_aclk300_jpeg_p) = { fin_pll, mout_sw_aclk300_jpeg };
-
-PNAME(sw_aclk_g3d_p) = { dout_aclk_g3d, sclk_spll};
-PNAME(user_aclk_g3d_p) = { fin_pll, mout_sw_aclk_g3d };
-
-PNAME(sw_aclk266_g2d_p) = { dout_aclk266_g2d, sclk_spll};
-PNAME(user_aclk266_g2d_p) = { fin_pll, mout_sw_aclk266_g2d };
-
-PNAME(sw_aclk333_g2d_p) = { dout_aclk333_g2d, sclk_spll};
-PNAME(user_aclk333_g2d_p) = { fin_pll, mout_sw_aclk333_g2d };
-
-PNAME(audio0_p)= { fin_pll, cdclk0, sclk_dpll, sclk_mpll,
- sclk_spll, sclk_ipll, sclk_epll, sclk_rpll };
-PNAME(audio1_p)= { fin_pll, cdclk1, sclk_dpll, sclk_mpll,
- sclk_spll, sclk_ipll, sclk_epll, sclk_rpll };
-PNAME(audio2_p)= { fin_pll, cdclk2, sclk_dpll, sclk_mpll,
- sclk_spll, sclk_ipll, sclk_epll, sclk_rpll };
-PNAME(spdif_p) = { fin_pll, dout_audio0, dout_audio1, dout_audio2,
- spdif_extclk, sclk_ipll, sclk_epll, sclk_rpll };
-PNAME(hdmi_p) = { dout_hdmi_pixel, sclk_hdmiphy };
-PNAME(maudio0_p) = { fin_pll, maudio_clk, sclk_dpll, sclk_mpll,
- sclk_spll, sclk_ipll, sclk_epll, sclk_rpll
};
+PNAME(mout_mspll_cpu_p) = {mout_sclk_cpll, mout_sclk_dpll,
+ mout_sclk_mpll, mout_sclk_spll};
+PNAME(mout_cpu_p) = {mout_apll
[PATCH v3 0/2] Add peach-pit board support
Changes from v2 -- - Use reference based node addressing in board dts file as suggested by Tomasz. - Included patch to update 5420.dtsi with node references for all existing nodes. Changes from v1 -- - Addressed review comments from Doug, Sachin Tushar - Removed adc and lid-switch nodes Arun Kumar K (2): ARM: dts: Add node references to 5420 ARM: dts: Add peach-pit board support arch/arm/boot/dts/Makefile |1 + arch/arm/boot/dts/exynos5420-peach-pit.dts | 156 arch/arm/boot/dts/exynos5420.dtsi | 26 ++--- 3 files changed, 170 insertions(+), 13 deletions(-) create mode 100644 arch/arm/boot/dts/exynos5420-peach-pit.dts -- 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 v3 2/2] ARM: dts: Add peach-pit board support
Adds the google peach-pit board dts file which uses
exynos5420 SoC.
Signed-off-by: Arun Kumar K arun...@samsung.com
Signed-off-by: Doug Anderson diand...@chromium.org
---
arch/arm/boot/dts/Makefile |1 +
arch/arm/boot/dts/exynos5420-peach-pit.dts | 156
2 files changed, 157 insertions(+)
create mode 100644 arch/arm/boot/dts/exynos5420-peach-pit.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 35c146f..3220e29 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -74,6 +74,7 @@ dtb-$(CONFIG_ARCH_EXYNOS) += exynos4210-origen.dtb \
exynos5250-smdk5250.dtb \
exynos5250-snow.dtb \
exynos5420-arndale-octa.dtb \
+ exynos5420-peach-pit.dtb \
exynos5420-smdk5420.dtb \
exynos5440-sd5v1.dtb \
exynos5440-ssdk5440.dtb
diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts
b/arch/arm/boot/dts/exynos5420-peach-pit.dts
new file mode 100644
index 000..03ef094
--- /dev/null
+++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
@@ -0,0 +1,156 @@
+/*
+ * Google Peach Pit Rev 6+ board device tree source
+ *
+ * Copyright (c) 2014 Google, Inc
+ *
+ * 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.
+ */
+
+/dts-v1/;
+#include dt-bindings/input/input.h
+#include dt-bindings/gpio/gpio.h
+#include exynos5420.dtsi
+
+/ {
+ model = Google Peach Pit Rev 6+;
+
+ compatible = google,pit-rev16,
+ google,pit-rev15, google,pit-rev14,
+ google,pit-rev13, google,pit-rev12,
+ google,pit-rev11, google,pit-rev10,
+ google,pit-rev9, google,pit-rev8,
+ google,pit-rev7, google,pit-rev6,
+ google,pit, google,peach,samsung,exynos5420,
+ samsung,exynos5;
+
+ memory {
+ reg = 0x2000 0x8000;
+ };
+
+ fixed-rate-clocks {
+ oscclk {
+ compatible = samsung,exynos5420-oscclk;
+ clock-frequency = 2400;
+ };
+ };
+
+ gpio-keys {
+ compatible = gpio-keys;
+
+ pinctrl-names = default;
+ pinctrl-0 = power_key_irq;
+
+ power {
+ label = Power;
+ gpios = gpx1 2 GPIO_ACTIVE_LOW;
+ linux,code = KEY_POWER;
+ gpio-key,wakeup;
+ };
+ };
+
+ backlight {
+ compatible = pwm-backlight;
+ pwms = pwm 0 100 0;
+ brightness-levels = 0 100 500 1000 1500 2000 2500 2800;
+ default-brightness-level = 7;
+ pinctrl-0 = backlight_pwm;
+ pinctrl-names = default;
+ };
+};
+
+pinctrl_0 {
+ tpm_irq: tpm-irq {
+ samsung,pins = gpx1-0;
+ samsung,pin-function = 0;
+ samsung,pin-pud = 0;
+ samsung,pin-drv = 0;
+ };
+
+ power_key_irq: power-key-irq {
+ samsung,pins = gpx1-2;
+ samsung,pin-function = 0;
+ samsung,pin-pud = 0;
+ samsung,pin-drv = 0;
+ };
+};
+
+pinctrl_3 {
+ backlight_pwm: backlight-pwm {
+ samsung,pins = gpb2-0;
+ samsung,pin-function = 2;
+ samsung,pin-pud = 0;
+ samsung,pin-drv = 0;
+ };
+};
+
+rtc {
+ status = okay;
+};
+
+serial_3 {
+ status = okay;
+};
+
+mmc_0 {
+ status = okay;
+ num-slots = 1;
+ broken-cd;
+ caps2-mmc-hs200-1_8v;
+ supports-highspeed;
+ non-removable;
+ card-detect-delay = 200;
+ clock-frequency = 4;
+ samsung,dw-mshc-ciu-div = 3;
+ samsung,dw-mshc-sdr-timing = 0 4;
+ samsung,dw-mshc-ddr-timing = 0 2;
+ pinctrl-names = default;
+ pinctrl-0 = sd0_clk sd0_cmd sd0_bus4 sd0_bus8;
+
+ slot@0 {
+ reg = 0;
+ bus-width = 8;
+ };
+};
+
+mmc_2 {
+ status = okay;
+ num-slots = 1;
+ supports-highspeed;
+ card-detect-delay = 200;
+ clock-frequency = 4;
+ samsung,dw-mshc-ciu-div = 3;
+ samsung,dw-mshc-sdr-timing = 2 3;
+ samsung,dw-mshc-ddr-timing = 1 2;
+ pinctrl-names = default;
+ pinctrl-0 = sd2_clk sd2_cmd sd2_cd sd2_bus4;
+
+ slot@0 {
+ reg = 0;
+ bus-width = 4;
+ };
+};
+
+hsi2c_9 {
+ status = okay;
+ clock-frequency = 40;
+
+ tpm@20 {
+ compatible = infineon,slb9645tt;
+ reg = 0x20;
+
+ /* Unused irq; but still need to configure the pins */
+ pinctrl-names = default;
+ pinctrl-0 = tpm_irq;
+ };
+};
+
+/*
+ * Use longest HW watchdog in
[PATCH v3 1/2] ARM: dts: Add node references to 5420
Adding references to nodes which do not have it yet
in exynos5420.dtsi. This is done so as to use reference
based node updation in board files.
Signed-off-by: Arun Kumar K arun...@samsung.com
---
arch/arm/boot/dts/exynos5420.dtsi | 26 +-
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch/arm/boot/dts/exynos5420.dtsi
index c3a9a66..2058276 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -125,7 +125,7 @@
clock-names = pll_ref, pll_in, sclk_audio, sclk_pcm_in;
};
- codec@1100 {
+ codec: codec@1100 {
compatible = samsung,mfc-v7;
reg = 0x1100 0x1;
interrupts = 0 96 0;
@@ -169,7 +169,7 @@
status = disabled;
};
- mct@101C {
+ mct: mct@101C {
compatible = samsung,exynos4210-mct;
reg = 0x101C 0x800;
interrupt-controller;
@@ -270,7 +270,7 @@
interrupts = 0 47 0;
};
- rtc@101E {
+ rtc: rtc@101E {
clocks = clock CLK_RTC;
clock-names = rtc;
status = disabled;
@@ -430,22 +430,22 @@
status = disabled;
};
- serial@12C0 {
+ serial_0: serial@12C0 {
clocks = clock CLK_UART0, clock CLK_SCLK_UART0;
clock-names = uart, clk_uart_baud0;
};
- serial@12C1 {
+ serial_1: serial@12C1 {
clocks = clock CLK_UART1, clock CLK_SCLK_UART1;
clock-names = uart, clk_uart_baud0;
};
- serial@12C2 {
+ serial_2: serial@12C2 {
clocks = clock CLK_UART2, clock CLK_SCLK_UART2;
clock-names = uart, clk_uart_baud0;
};
- serial@12C3 {
+ serial_3: serial@12C3 {
clocks = clock CLK_UART3, clock CLK_SCLK_UART3;
clock-names = uart, clk_uart_baud0;
};
@@ -465,14 +465,14 @@
#phy-cells = 0;
};
- dp-controller@145B {
+ dp: dp-controller@145B {
clocks = clock CLK_DP1;
clock-names = dp;
phys = dp_phy;
phy-names = dp;
};
- fimd@1440 {
+ fimd: fimd@1440 {
samsung,power-domain = disp_pd;
clocks = clock CLK_SCLK_FIMD1, clock CLK_FIMD1;
clock-names = sclk_fimd, fimd;
@@ -632,7 +632,7 @@
status = disabled;
};
- hdmi@1453 {
+ hdmi: hdmi@1453 {
compatible = samsung,exynos4212-hdmi;
reg = 0x1453 0x7;
interrupts = 0 95 0;
@@ -644,7 +644,7 @@
status = disabled;
};
- mixer@1445 {
+ mixer: mixer@1445 {
compatible = samsung,exynos5420-mixer;
reg = 0x1445 0x1;
interrupts = 0 94 0;
@@ -715,7 +715,7 @@
clock-names = tmu_apbif, tmu_triminfo_apbif;
};
-watchdog@101D {
+watchdog: watchdog@101D {
compatible = samsung,exynos5420-wdt;
reg = 0x101D 0x100;
interrupts = 0 42 0;
@@ -724,7 +724,7 @@
samsung,syscon-phandle = pmu_system_controller;
};
- sss@1083 {
+ sss: sss@1083 {
compatible = samsung,exynos4210-secss;
reg = 0x1083 0x1;
interrupts = 0 112 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
Re: [PATCH v3 07/16] clk: exynos5420: update clocks for PERIC block
HI shaik,
On Thu, Apr 24, 2014 at 6:33 PM, Shaik Ameer Basha
shaik.am...@samsung.com wrote:
This patch includes,
1] renaming of the HSI2C clocks
2] renaming of spi clocks according to the datasheet
3] fixes for child-parent relationships
4] adding of more clocks related to PERIC block
You are also fixing the gate clock, GATE_BUS_PERIC - GATE_IP_PERIC
Please add them in your commit message.
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
Signed-off-by: Shaik Ameer Basha shaik.am...@samsung.com
---
arch/arm/boot/dts/exynos5420.dtsi | 14 +++---
drivers/clk/samsung/clk-exynos5420.c | 73
include/dt-bindings/clock/exynos5420.h | 14 +++---
3 files changed, 50 insertions(+), 51 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch/arm/boot/dts/exynos5420.dtsi
index c3a9a66..67ba2c5 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -549,7 +549,7 @@
#size-cells = 0;
pinctrl-names = default;
pinctrl-0 = i2c4_hs_bus;
- clocks = clock CLK_I2C4;
+ clocks = clock CLK_USI0;
clock-names = hsi2c;
status = disabled;
};
@@ -562,7 +562,7 @@
#size-cells = 0;
pinctrl-names = default;
pinctrl-0 = i2c5_hs_bus;
- clocks = clock CLK_I2C5;
+ clocks = clock CLK_USI1;
clock-names = hsi2c;
status = disabled;
};
@@ -575,7 +575,7 @@
#size-cells = 0;
pinctrl-names = default;
pinctrl-0 = i2c6_hs_bus;
- clocks = clock CLK_I2C6;
+ clocks = clock CLK_USI2;
clock-names = hsi2c;
status = disabled;
};
@@ -588,7 +588,7 @@
#size-cells = 0;
pinctrl-names = default;
pinctrl-0 = i2c7_hs_bus;
- clocks = clock CLK_I2C7;
+ clocks = clock CLK_USI3;
clock-names = hsi2c;
status = disabled;
};
@@ -601,7 +601,7 @@
#size-cells = 0;
pinctrl-names = default;
pinctrl-0 = i2c8_hs_bus;
- clocks = clock CLK_I2C8;
+ clocks = clock CLK_USI4;
clock-names = hsi2c;
status = disabled;
};
@@ -614,7 +614,7 @@
#size-cells = 0;
pinctrl-names = default;
pinctrl-0 = i2c9_hs_bus;
- clocks = clock CLK_I2C9;
+ clocks = clock CLK_USI5;
clock-names = hsi2c;
status = disabled;
};
@@ -627,7 +627,7 @@
#size-cells = 0;
pinctrl-names = default;
pinctrl-0 = i2c10_hs_bus;
- clocks = clock CLK_I2C10;
+ clocks = clock CLK_USI6;
clock-names = hsi2c;
status = disabled;
};
diff --git a/drivers/clk/samsung/clk-exynos5420.c
b/drivers/clk/samsung/clk-exynos5420.c
index cd75661..b4cf4c1 100755
--- a/drivers/clk/samsung/clk-exynos5420.c
+++ b/drivers/clk/samsung/clk-exynos5420.c
@@ -95,6 +95,7 @@
#define GATE_IP_DISP1 0x10928
#define GATE_IP_G3D0x10930
#define GATE_IP_GEN0x10934
+#define GATE_IP_PERIC 0x10950
#define GATE_IP_MSCL 0x10970
#define GATE_TOP_SCLK_GSCL 0x10820
#define GATE_TOP_SCLK_DISP10x10828
@@ -183,6 +184,7 @@ static unsigned long exynos5420_clk_regs[] __initdata = {
GATE_IP_DISP1,
GATE_IP_G3D,
GATE_IP_GEN,
+ GATE_IP_PERIC,
GATE_IP_MSCL,
GATE_TOP_SCLK_GSCL,
GATE_TOP_SCLK_DISP1,
@@ -588,9 +590,9 @@ static struct samsung_div_clock exynos5420_div_clks[]
__initdata = {
DIV(0, dout_audio2, mout_audio2, DIV_PERIC3, 28, 4),
/* SPI Pre-Ratio */
- DIV(0, dout_pre_spi0, dout_spi0, DIV_PERIC4, 8, 8),
- DIV(0, dout_pre_spi1, dout_spi1, DIV_PERIC4, 16, 8),
- DIV(0, dout_pre_spi2, dout_spi2, DIV_PERIC4, 24, 8),
+ DIV(0, dout_spi0_pre, dout_spi0, DIV_PERIC4, 8, 8),
+ DIV(0, dout_spi1_pre, dout_spi1, DIV_PERIC4, 16, 8),
+ DIV(0, dout_spi2_pre, dout_spi2, DIV_PERIC4, 24, 8),
/* GSCL Block */
DIV(0, dout_gscl_blk_300, mout_user_aclk300_gscl,
@@ -641,8 +643,8 @@ static struct samsung_gate_clock exynos5420_gate_clks[]
__initdata = {
GATE_BUS_TOP, 9, CLK_IGNORE_UNUSED, 0),
GATE(0, aclk66_psgen, mout_aclk66_psgen,
GATE_BUS_TOP, 10, CLK_IGNORE_UNUSED, 0),
- GATE(0, aclk66_peric, mout_aclk66_peric,
- GATE_BUS_TOP, 11, 0, 0),
+ GATE(0, aclk66_peric, mout_user_aclk66_peric,
+
Re: [PATCH v3 08/16] clk: exynos5420: update clocks for PERIS and GEN blocks
Hi Shaik,
On Thu, Apr 24, 2014 at 6:33 PM, Shaik Ameer Basha
shaik.am...@samsung.com wrote:
This patch fixes some parent-child relationships according
to the latest datasheet and adds more clocks related to
PERIS and GEN blocks.
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
Signed-off-by: Shaik Ameer Basha shaik.am...@samsung.com
---
Looks Good.
Reviewed-by: Alim Akhtar alim.akh...@samsung.com
drivers/clk/samsung/clk-exynos5420.c | 70
include/dt-bindings/clock/exynos5420.h |5 +++
2 files changed, 48 insertions(+), 27 deletions(-)
diff --git a/drivers/clk/samsung/clk-exynos5420.c
b/drivers/clk/samsung/clk-exynos5420.c
index b4cf4c1..6ad87d1 100755
--- a/drivers/clk/samsung/clk-exynos5420.c
+++ b/drivers/clk/samsung/clk-exynos5420.c
@@ -83,6 +83,7 @@
#define SCLK_DIV_ISP1 0x10584
#define DIV2_RATIO00x10590
#define GATE_BUS_TOP 0x10700
+#define GATE_BUS_GEN 0x1073c
#define GATE_BUS_FSYS0 0x10740
#define GATE_BUS_PERIC 0x10750
#define GATE_BUS_PERIC10x10754
@@ -96,6 +97,7 @@
#define GATE_IP_G3D0x10930
#define GATE_IP_GEN0x10934
#define GATE_IP_PERIC 0x10950
+#define GATE_IP_PERIS 0x10960
#define GATE_IP_MSCL 0x10970
#define GATE_TOP_SCLK_GSCL 0x10820
#define GATE_TOP_SCLK_DISP10x10828
@@ -172,6 +174,7 @@ static unsigned long exynos5420_clk_regs[] __initdata = {
SCLK_DIV_ISP1,
DIV2_RATIO0,
GATE_BUS_TOP,
+ GATE_BUS_GEN,
GATE_BUS_FSYS0,
GATE_BUS_PERIC,
GATE_BUS_PERIC1,
@@ -185,6 +188,7 @@ static unsigned long exynos5420_clk_regs[] __initdata = {
GATE_IP_G3D,
GATE_IP_GEN,
GATE_IP_PERIC,
+ GATE_IP_PERIS,
GATE_IP_MSCL,
GATE_TOP_SCLK_GSCL,
GATE_TOP_SCLK_DISP1,
@@ -602,6 +606,10 @@ static struct samsung_div_clock exynos5420_div_clks[]
__initdata = {
/* MSCL Blk */
DIV(0, dout_mscl_blk, aclk400_mscl, DIV2_RATIO0, 28, 2),
+ /* PSGEN */
+ DIV(0, dout_gen_blk, mout_user_aclk266, DIV2_RATIO0, 8, 1),
+ DIV(0, dout_jpg_blk, aclk166, DIV2_RATIO0, 20, 1),
+
/* ISP Block */
DIV(0, dout_aclk400_isp, mout_aclk400_isp, DIV_TOP0, 0, 3),
DIV(0, dout_aclk333_432_isp0, mout_aclk333_432_isp0,
@@ -620,9 +628,7 @@ static struct samsung_div_clock exynos5420_div_clks[]
__initdata = {
};
static struct samsung_gate_clock exynos5420_gate_clks[] __initdata = {
- /* TODO: Re-verify the CG bits for all the gate clocks */
- GATE_A(CLK_MCT, pclk_st, aclk66_psgen, GATE_BUS_PERIS1, 2, 0, 0,
- mct),
+ GATE(CLK_MCT, mct, aclk66_psgen, GATE_IP_PERIS, 18, 0, 0),
GATE(0, aclk200_fsys, mout_user_aclk200_fsys,
GATE_BUS_FSYS0, 9, CLK_IGNORE_UNUSED, 0),
@@ -769,27 +775,30 @@ static struct samsung_gate_clock exynos5420_gate_clks[]
__initdata = {
GATE(CLK_SPDIF, spdif, aclk66_peric, GATE_IP_PERIC, 26, 0, 0),
GATE(CLK_CHIPID, chipid, aclk66_psgen,
- GATE_BUS_PERIS0, 12, CLK_IGNORE_UNUSED, 0),
+ GATE_IP_PERIS, 0, CLK_IGNORE_UNUSED, 0),
GATE(CLK_SYSREG, sysreg, aclk66_psgen,
- GATE_BUS_PERIS0, 13, CLK_IGNORE_UNUSED, 0),
- GATE(CLK_TZPC0, tzpc0, aclk66_psgen, GATE_BUS_PERIS0, 18, 0, 0),
- GATE(CLK_TZPC1, tzpc1, aclk66_psgen, GATE_BUS_PERIS0, 19, 0, 0),
- GATE(CLK_TZPC2, tzpc2, aclk66_psgen, GATE_BUS_PERIS0, 20, 0, 0),
- GATE(CLK_TZPC3, tzpc3, aclk66_psgen, GATE_BUS_PERIS0, 21, 0, 0),
- GATE(CLK_TZPC4, tzpc4, aclk66_psgen, GATE_BUS_PERIS0, 22, 0, 0),
- GATE(CLK_TZPC5, tzpc5, aclk66_psgen, GATE_BUS_PERIS0, 23, 0, 0),
- GATE(CLK_TZPC6, tzpc6, aclk66_psgen, GATE_BUS_PERIS0, 24, 0, 0),
- GATE(CLK_TZPC7, tzpc7, aclk66_psgen, GATE_BUS_PERIS0, 25, 0, 0),
- GATE(CLK_TZPC8, tzpc8, aclk66_psgen, GATE_BUS_PERIS0, 26, 0, 0),
- GATE(CLK_TZPC9, tzpc9, aclk66_psgen, GATE_BUS_PERIS0, 27, 0, 0),
-
- GATE(CLK_HDMI_CEC, hdmi_cec, aclk66_psgen, GATE_BUS_PERIS1, 0, 0,
- 0),
+ GATE_IP_PERIS, 1, CLK_IGNORE_UNUSED, 0),
+ GATE(CLK_TZPC0, tzpc0, aclk66_psgen, GATE_IP_PERIS, 6, 0, 0),
+ GATE(CLK_TZPC1, tzpc1, aclk66_psgen, GATE_IP_PERIS, 7, 0, 0),
+ GATE(CLK_TZPC2, tzpc2, aclk66_psgen, GATE_IP_PERIS, 8, 0, 0),
+ GATE(CLK_TZPC3, tzpc3, aclk66_psgen, GATE_IP_PERIS, 9, 0, 0),
+ GATE(CLK_TZPC4, tzpc4, aclk66_psgen, GATE_IP_PERIS, 10, 0, 0),
+ GATE(CLK_TZPC5, tzpc5, aclk66_psgen, GATE_IP_PERIS, 11, 0, 0),
+ GATE(CLK_TZPC6, tzpc6, aclk66_psgen, GATE_IP_PERIS, 12, 0, 0),
+ GATE(CLK_TZPC7, tzpc7, aclk66_psgen, GATE_IP_PERIS, 13, 0, 0),
+ GATE(CLK_TZPC8, tzpc8, aclk66_psgen, GATE_IP_PERIS, 14, 0, 0),
+ GATE(CLK_TZPC9,
Re: [PATCH v3 09/16] clk: exynos5420: update clocks for WCORE block
Hi Shaik,
On Thu, Apr 24, 2014 at 6:33 PM, Shaik Ameer Basha
shaik.am...@samsung.com wrote:
This patch adds missing clocks from WCORE block.
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
Signed-off-by: Shaik Ameer Basha shaik.am...@samsung.com
---
Reviewed-by: Alim Akhtar alim.akh...@samsung.com
drivers/clk/samsung/clk-exynos5420.c | 28
1 file changed, 28 insertions(+)
diff --git a/drivers/clk/samsung/clk-exynos5420.c
b/drivers/clk/samsung/clk-exynos5420.c
index 6ad87d1..d9996dd 100755
--- a/drivers/clk/samsung/clk-exynos5420.c
+++ b/drivers/clk/samsung/clk-exynos5420.c
@@ -89,6 +89,7 @@
#define GATE_BUS_PERIC10x10754
#define GATE_BUS_PERIS00x10760
#define GATE_BUS_PERIS10x10764
+#define GATE_BUS_NOC 0x10770
#define GATE_TOP_SCLK_ISP 0x10870
#define GATE_IP_GSCL0 0x10910
#define GATE_IP_GSCL1 0x10920
@@ -180,6 +181,7 @@ static unsigned long exynos5420_clk_regs[] __initdata = {
GATE_BUS_PERIC1,
GATE_BUS_PERIS0,
GATE_BUS_PERIS1,
+ GATE_BUS_NOC,
GATE_TOP_SCLK_ISP,
GATE_IP_GSCL0,
GATE_IP_GSCL1,
@@ -271,6 +273,13 @@ PNAME(mout_user_aclk200_fsys_p)= {fin_pll,
mout_sw_aclk200_fsys};
PNAME(mout_sw_aclk200_fsys2_p) = {dout_aclk200_fsys2, mout_sclk_spll};
PNAME(mout_user_aclk200_fsys2_p) = {fin_pll, mout_sw_aclk200_fsys2};
+PNAME(mout_sw_aclk100_noc_p) = {dout_aclk100_noc, mout_sclk_spll};
+PNAME(mout_user_aclk100_noc_p) = {fin_pll, mout_sw_aclk100_noc};
+
+PNAME(mout_sw_aclk400_wcore_p) = {dout_aclk400_wcore, mout_sclk_spll};
+PNAME(mout_aclk400_wcore_bpll_p) = {mout_aclk400_wcore, sclk_bpll};
+PNAME(mout_user_aclk400_wcore_p) = {fin_pll, mout_sw_aclk400_wcore};
+
PNAME(mout_sw_aclk400_isp_p) = {dout_aclk400_isp, mout_sclk_spll};
PNAME(mout_user_aclk400_isp_p) = {fin_pll, mout_sw_aclk400_isp};
@@ -486,6 +495,18 @@ static struct samsung_mux_clock exynos5420_mux_clks[]
__initdata = {
MUX(0, mout_spi0, mout_group2_p, SRC_PERIC1, 20, 3),
MUX(0, mout_spi1, mout_group2_p, SRC_PERIC1, 24, 3),
MUX(0, mout_spi2, mout_group2_p, SRC_PERIC1, 28, 3),
+ MUX(0, mout_aclk100_noc, mout_group1_p, SRC_TOP0, 20, 2),
+ MUX(0, mout_sw_aclk100_noc, mout_sw_aclk100_noc_p,
+ SRC_TOP10, 20, 1),
+ MUX(0, mout_user_aclk100_noc, mout_user_aclk100_noc_p,
+ SRC_TOP3, 20, 1),
+ MUX(0, mout_aclk400_wcore, mout_group1_p, SRC_TOP0, 16, 2),
+ MUX(0, mout_aclk400_wcore_bpll, mout_aclk400_wcore_bpll_p,
+ TOP_SPARE2, 4, 1),
+ MUX(0, mout_sw_aclk400_wcore, mout_sw_aclk400_wcore_p,
+ SRC_TOP10, 16, 1),
+ MUX(0, mout_user_aclk400_wcore, mout_user_aclk400_wcore_p,
+ SRC_TOP3, 16, 1),
MUX(0, mout_aclk400_isp, mout_group1_p, SRC_TOP0, 0, 2),
MUX(0, mout_sw_aclk400_isp, mout_sw_aclk400_isp_p,
SRC_TOP10, 0, 1),
@@ -553,6 +574,10 @@ static struct samsung_div_clock exynos5420_div_clks[]
__initdata = {
DIV(0, dout_disp1_blk, aclk200_disp1, DIV2_RATIO0, 16, 2),
DIV(0, dout_aclk400_disp1, mout_aclk400_disp1, DIV_TOP2, 4, 3),
+ DIV(0, dout_aclk100_noc, mout_aclk100_noc, DIV_TOP0, 20, 3),
+ DIV(0, dout_aclk400_wcore, mout_aclk400_wcore_bpll,
+ DIV_TOP0, 16, 3),
+
/* Audio Block */
DIV(0, dout_maudio0, mout_maudio0, DIV_MAU, 20, 4),
DIV(0, dout_maupcm0, dout_maudio0, DIV_MAU, 24, 8),
@@ -867,6 +892,9 @@ static struct samsung_gate_clock exynos5420_gate_clks[]
__initdata = {
GATE_IP_MSCL, 10, 0, 0),
GATE(CLK_SMMU_MIXER, smmu_mixer, aclk200_disp1,
GATE_IP_DISP1, 9, 0, 0),
+ /* aclk266 also gates other IPs in psgen. It should not be gated. */
+ GATE(0, aclk266, mout_user_aclk266,
+ GATE_BUS_NOC, 22, CLK_IGNORE_UNUSED, 0),
GATE(0, aclk200_disp1, mout_user_aclk200_disp1,
GATE_BUS_TOP, 18, CLK_IGNORE_UNUSED, 0),
GATE(0, aclk300_disp1, mout_user_aclk300_disp1,
--
1.7.9.5
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
Regards,
Alim
--
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] ASoC: SAMSUNG: Add sound card driver for Snow board
On 04/30/2014 03:59 AM, Mark Brown wrote:
On Fri, Apr 25, 2014 at 09:46:11AM +0530, Tushar Behera wrote:
On 04/24/2014 07:09 PM, Mark Brown wrote:
defined. Why is that? Also, why is the secondary I2S playback stream
not supported (this may be a reason to restrict to only the one I2S
interface)?
AFAICS, I2S driver doesn't support secondary DAI with DT (dai type is
always TYPE_PRI in case of DT). Hence I could not find a setup to test
secondary dai with this board.
OK, that should be fixed at some point. I will hopefully be able to
look at this myself on the Arndale Octa though (or Chromebook or Arndale
once XCLKOUT is implemented).
XCLKOUT mux register (0x10040a00) is not part of core clock SFR range,
rather it is part of pmu-system-controller node.
One option would be to add a clock provider for XCLKOUT. That would
require me to extend current clock driver to get the
pmu-system-controller phandle which in turn is dependent on the patch to
early initialize syscon driver.[1]
Will it be okay to configure XCLKOUT in snow sound-card driver by taking
the phandle of pmu-system-controller from device tree? The
implementation is provided below.
[1] article.gmane.org/gmane.linux.kernel/1679446
diff --git a/sound/soc/samsung/snow.c b/sound/soc/samsung/snow.c
index 0fa89a4..d7fe7a0 100644
--- a/sound/soc/samsung/snow.c
+++ b/sound/soc/samsung/snow.c
@@ -15,6 +15,7 @@
#include linux/platform_device.h
#include linux/of.h
#include linux/of_device.h
+#include linux/mfd/syscon.h
#include sound/soc.h
@@ -22,6 +23,10 @@
#define FIN_PLL_RATE 2400
+#define XCLKOUT_OFFSET 0x0a00
+#define XCLKOUT_PARENT_MASK0x1f00
+#define XCLKOUT_PARENT_XXTI0x1000
+
static struct snd_soc_dai_link snow_dai[] = {
{
.name = Primary,
@@ -66,6 +71,7 @@ static int snow_probe(struct platform_device *pdev)
{
struct snd_soc_card *card = snow_snd;
struct device_node *i2s_node, *codec_node;
+ struct regmap *pmureg;
int i, ret;
i2s_node = of_parse_phandle(pdev-dev.of_node,
@@ -84,6 +90,19 @@ static int snow_probe(struct platform_device *pdev)
return -EINVAL;
}
+ /*
+* On Snow board, SoC XCLKOUT line is connected to codec MCLK.
+* One option would be to add another clock provider to configure
+* XCLKOUT mux register. Else we can get pmu-syscon phandle from
+* device tree and update the register here.
+*/
+ pmureg = syscon_regmap_lookup_by_phandle(pdev-dev.of_node,
+ samsung,pmu-syscon);
+ if (!IS_ERR(pmureg)) {
+ regmap_update_bits(pmureg, XCLKOUT_OFFSET,
+ XCLKOUT_PARENT_MASK, XCLKOUT_PARENT_XXTI);
+ }
+
for (i = 0; i ARRAY_SIZE(snow_dai); i++) {
snow_dai[i].codec_of_node = codec_node;
snow_dai[i].cpu_of_node = i2s_node;
--
Tushar Behera
--
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 0/7 v8] crypto:s5p-sss: Add Device tree and Exynos support
On Wed, Apr 30, 2014 at 04:38:05PM +0530, Naveen Krishna Ch wrote: Hello All, On 28 April 2014 16:14, Naveen Krishna Chatradhi ch.nav...@samsung.com wrote: SSS module on Exynos4210, Exynos5250 and Exynos5420 SoCs has added features to the one on S5PV210. However with minor changes the s5p-sss.c driver can be reused to support SSS modules on Exynos4 and 5 SoCs. This patch set 1. Adds device tree support to the s5p-sss.c driver and Documentation 2. Adds code to support SSS module on Exynos4 and 5 SoCs 3. Adds variant struct to handle the differences in SSS modules 4. Adds clk_prepare/clk_unprepare clocks to the s5p-sss.c driver Note: Compatible exynos4210-secss should work for Exynos4412 and Exynos5260 (Exynos5260, for which ARCH code is under review) I couldn't test on Exynos4412 and Exynos4210 boards, Should be able to test with addition of DT node and clocks support. These patches are under review at https://lkml.org/lkml/2014/2/17/124 Naveen Krishna Chatradhi (7): crypto:s5p-sss: Use platform_get_irq() instead of _byname() crypto:s5p-sss: Kconfig: Let Exynos SoCs select SSS driver crypto:s5p-sss: Look for the next request in the queue crypto:s5p-sss: Add device tree support crypto:s5p-sss: Add support for SSS module on Exynos crypto:s5p-sss: validate iv before memcpy crypto:s5p-sss: Use clk_prepare/clk_unprepare .../devicetree/bindings/crypto/samsung-sss.txt | 35 + drivers/crypto/Kconfig |6 +- drivers/crypto/s5p-sss.c | 145 +++- 3 files changed, 150 insertions(+), 36 deletions(-) create mode 100644 Documentation/devicetree/bindings/crypto/samsung-sss.txt Can we get this series merged in. Its has got reviewed and re-based several times and got acked by a couple of seniors. Do you want me to pick these series up? Cheers, -- Email: Herbert Xu herb...@gondor.apana.org.au Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/7 v8] crypto:s5p-sss: Add Device tree and Exynos support
Hello Herbert, On 30 April 2014 17:44, Herbert Xu herb...@gondor.apana.org.au wrote: On Wed, Apr 30, 2014 at 04:38:05PM +0530, Naveen Krishna Ch wrote: Hello All, On 28 April 2014 16:14, Naveen Krishna Chatradhi ch.nav...@samsung.com wrote: SSS module on Exynos4210, Exynos5250 and Exynos5420 SoCs has added features to the one on S5PV210. However with minor changes the s5p-sss.c driver can be reused to support SSS modules on Exynos4 and 5 SoCs. This patch set 1. Adds device tree support to the s5p-sss.c driver and Documentation 2. Adds code to support SSS module on Exynos4 and 5 SoCs 3. Adds variant struct to handle the differences in SSS modules 4. Adds clk_prepare/clk_unprepare clocks to the s5p-sss.c driver Note: Compatible exynos4210-secss should work for Exynos4412 and Exynos5260 (Exynos5260, for which ARCH code is under review) I couldn't test on Exynos4412 and Exynos4210 boards, Should be able to test with addition of DT node and clocks support. These patches are under review at https://lkml.org/lkml/2014/2/17/124 Naveen Krishna Chatradhi (7): crypto:s5p-sss: Use platform_get_irq() instead of _byname() crypto:s5p-sss: Kconfig: Let Exynos SoCs select SSS driver crypto:s5p-sss: Look for the next request in the queue crypto:s5p-sss: Add device tree support crypto:s5p-sss: Add support for SSS module on Exynos crypto:s5p-sss: validate iv before memcpy crypto:s5p-sss: Use clk_prepare/clk_unprepare .../devicetree/bindings/crypto/samsung-sss.txt | 35 + drivers/crypto/Kconfig |6 +- drivers/crypto/s5p-sss.c | 145 +++- 3 files changed, 150 insertions(+), 36 deletions(-) create mode 100644 Documentation/devicetree/bindings/crypto/samsung-sss.txt Can we get this series merged in. Its has got reviewed and re-based several times and got acked by a couple of seniors. Do you wa1nt me to pick these series up? Yes please. Cheers, Thanks, Naveen -- Email: Herbert Xu herb...@gondor.apana.org.au Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- Shine bright, (: Nav :) -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] v4l: Add resolution change event.
Hi Hans,
On 04/22/14 18:22, Hans Verkuil wrote:
On 04/21/2014 11:26 AM, 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.
The event can also be used for more generic events involving resolution
or format changes at runtime for all kinds of video devices.
Signed-off-by: Pawel Osciak posc...@chromium.org
Signed-off-by: Arun Kumar K arun...@samsung.com
---
.../DocBook/media/v4l/vidioc-subscribe-event.xml | 16
include/uapi/linux/videodev2.h |6 ++
2 files changed, 22 insertions(+)
diff --git a/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml
b/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml
index 5c70b61..0aec831 100644
--- a/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml
@@ -155,6 +155,22 @@
/entry
/row
row
+entryconstantV4L2_EVENT_SOURCE_CHANGE/constant/entry
+entry5/entry
+entry
+ paraThis event is triggered when a resolution or format change
+ is detected during runtime by the video device. It can be a
+ runtime resolution change triggered by a video decoder or the
+ format change happening on an HDMI connector. Application may
+ need to reinitialize buffers before proceeding further./para
+
+ paraThis event has a v4l2-event-source-change; associated
+ with it. This has significance only for v4l2 subdevs where the
+ structfieldpad_num/structfield field will be updated with
+ the pad number on which the event is triggered./para
+/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..12e0614 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_SOURCE_CHANGE5
#define V4L2_EVENT_PRIVATE_START0x0800
/* Payload for V4L2_EVENT_VSYNC */
@@ -1764,12 +1765,17 @@ struct v4l2_event_frame_sync {
__u32 frame_sequence;
};
+struct v4l2_event_source_change {
+__u32 pad_num;
+};
+
struct v4l2_event {
__u32 type;
union {
struct v4l2_event_vsync vsync;
struct v4l2_event_ctrl ctrl;
struct v4l2_event_frame_syncframe_sync;
+struct v4l2_event_source_change source_change;
__u8data[64];
} u;
__u32 pending;
This needs to be done differently. The problem is that you really have
multiple
events that you want to subscribe to: one for each pad (or input: see the way
VIDIOC_G/S_EDID maps pad to an input or output index when used with a video
node,
we have to support that for this event as well).
What you want to do is similar to what is done for control events: there you
can
subscribe for a specific control and get notified when that control changes.
The way that works in the event code is that the 'id' field in the v4l2_event
struct contains that control ID, or, in this case, the pad/input/output index.
As I am new to v4l2-events itself, I might have some noob questions.
I understood filling pad index into id field. But for video nodes,
the application is supposed to put v4l2_buf_type in the id field?
In the application you will subscribe to the SOURCE_CHANGE event for a
specific
pad/input/output index.
In other words, the pad_num field should be dropped and the id field used
instead.
Assuming we will also add a 'changes' field (see my reply to the other post
on that topic), then you should also provide replace and merge ops (see
v4l2-ctrls.c). That way it is sufficient to use just one element when calling
v4l2_event_subscribe(): you will never loose information since if multiple
events arrive before the application can dequeue them, the 'changes'
information
will be the ORed value of all those intermediate events.
If I understand correctly, the implementation should go somewhat in the
following lines:
+void v4l2_event_src_replace(struct v4l2_event *old, const struct
v4l2_event *new)
+{
+ u32 old_changes = old-u.src_change.changes;
+
+ old-u.src_change = new-u.src_change;
+
Re: [PATCH 4/4] ARM: dts: exynos5250-snow: add ptn3460 node
Hi, On Tue, Apr 15, 2014 at 4:24 AM, Olof Johansson o...@lixom.net wrote: Hi Sachin, On Mon, Apr 14, 2014 at 6:16 AM, Sachin Kamat sachin.ka...@linaro.org wrote: From: Doug Anderson diand...@chromium.org Added nodes for ptn3460 driver to Snow board. Signed-off-by: Doug Anderson diand...@chromium.org Signed-off-by: Ajay Kumar ajaykumar...@samsung.com Signed-off-by: Sachin Kamat sachin.ka...@linaro.org I'm curious, how are you testing this code on the upstream kernel before you post the patches? Especially since Doug was referring to some of these containing parts that is needed for drivers that are not yet upstreamed. Its better to ignore this patch as of now, since discussion is still going on, at http://www.spinics.net/lists/dri-devel/msg58474.html I guess we will have few more DT bindings. Once it is finalized, I shall resend this again. Regards, Ajay Kumar -- 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 4/7] arm64: Add a description on 48-bit address space with 4KB pages
On Wed, Apr 30, 2014 at 07:41:40AM +0100, Jungseok Lee wrote: On Tuesday, April 29, 2014 11:48 PM, Catalin Marinas wrote: On Tue, Apr 29, 2014 at 05:59:27AM +0100, Jungseok Lee wrote: --- a/Documentation/arm64/memory.txt +++ b/Documentation/arm64/memory.txt @@ -8,10 +8,11 @@ This document describes the virtual memory layout used by the AArch64 Linux kernel. The architecture allows up to 4 levels of translation tables with a 4KB page size and up to 3 levels with a 64KB page size. -AArch64 Linux uses 3 levels of translation tables with the 4KB page -configuration, allowing 39-bit (512GB) virtual addresses for both user -and kernel. With 64KB pages, only 2 levels of translation tables are -used but the memory layout is the same. +AArch64 Linux uses 3 levels and 4 levels of translation tables with +the 4KB page configuration, allowing 39-bit (512GB) and 48-bit +(256TB) virtual addresses, respectively, for both user and kernel. +With 64KB pages, only 2 levels of translation tables are used but the +memory layout is the same. Any reason why we couldn't use 48-bit address space with 64K pages (implying 3 levels)? No technical reason. Since 64K+3levels is not implemented in this set, I didn't add it. Should 64K+3levels be prepared in this patchset? -AArch64 Linux memory layout with 64KB pages: +AArch64 Linux memory layout with 4KB pages + 4 levels: + +StartEnd SizeUse +--- + 256TB user + + 7bfe~124TB vmalloc BTW, maybe as a separate patch we should change the end to be exclusive. It becomes harder to modify (I've been through this a few times already ;)) and even follow the changes. Does exclusive mean that is changed to 0001? Or Does it mean that End column is dropped? Not dropped but changed to 0001 (the kernel already prints the memory layout in a similar way). -- Catalin -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 11/16] clk: exynos5420: correct sysmmu-mfc parent clocks
Hi Shaik,
On Thu, Apr 24, 2014 at 6:33 PM, Shaik Ameer Basha
shaik.am...@samsung.com wrote:
This patch corrects the wrong parent-child relationship
between sysmmu-mfc clocks.
Signed-off-by: Shaik Ameer Basha shaik.am...@samsung.com
---
Hoping you have tested vedio playback with this patch, especially
after across a suspend/resume cycles.
This looks ok.
Reviewed-by: Alim Akhtar alim.akh...@samsung.com
drivers/clk/samsung/clk-exynos5420.c |9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/samsung/clk-exynos5420.c
b/drivers/clk/samsung/clk-exynos5420.c
index d8fe6d8..6daf739 100755
--- a/drivers/clk/samsung/clk-exynos5420.c
+++ b/drivers/clk/samsung/clk-exynos5420.c
@@ -82,6 +82,7 @@
#define SCLK_DIV_ISP0 0x10580
#define SCLK_DIV_ISP1 0x10584
#define DIV2_RATIO00x10590
+#define DIV4_RATIO 0x105a0
#define GATE_BUS_TOP 0x10700
#define GATE_BUS_GEN 0x1073c
#define GATE_BUS_FSYS0 0x10740
@@ -176,6 +177,7 @@ static unsigned long exynos5420_clk_regs[] __initdata = {
SCLK_DIV_ISP0,
SCLK_DIV_ISP1,
DIV2_RATIO0,
+ DIV4_RATIO,
GATE_BUS_TOP,
GATE_BUS_GEN,
GATE_BUS_FSYS0,
@@ -636,6 +638,9 @@ static struct samsung_div_clock exynos5420_div_clks[]
__initdata = {
DIV(0, dout_spi1_pre, dout_spi1, DIV_PERIC4, 16, 8),
DIV(0, dout_spi2_pre, dout_spi2, DIV_PERIC4, 24, 8),
+ /* Mfc Blk */
+ DIV(0, dout_mfc_blk, mout_user_aclk333, DIV4_RATIO, 0, 2),
+
/* GSCL Block */
DIV(0, dout_gscl_blk_300, mout_user_aclk300_gscl,
DIV2_RATIO0, 4, 2),
@@ -873,8 +878,8 @@ static struct samsung_gate_clock exynos5420_gate_clks[]
__initdata = {
GATE_IP_DISP1, 8, 0, 0),
GATE(CLK_MFC, mfc, aclk333, GATE_IP_MFC, 0, 0, 0),
- GATE(CLK_SMMU_MFCL, smmu_mfcl, aclk333, GATE_IP_MFC, 1, 0, 0),
- GATE(CLK_SMMU_MFCR, smmu_mfcr, aclk333, GATE_IP_MFC, 2, 0, 0),
+ GATE(CLK_SMMU_MFCL, smmu_mfcl, dout_mfc_blk, GATE_IP_MFC, 1, 0,
0),
+ GATE(CLK_SMMU_MFCR, smmu_mfcr, dout_mfc_blk, GATE_IP_MFC, 2, 0,
0),
GATE(CLK_G3D, g3d, aclkg3d, GATE_IP_G3D, 9, 0, 0),
--
1.7.9.5
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
Regards,
Alim
--
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] drm/exynos: fix nested calls to lock mutex in drm resume
From: Rahul Sharma rahul.sha...@samsung.com While testing S2R on exynos board, system is hanging and rebooting due to nested mutex_lock calls in exynos drm resume callback. Changing the order of the calls is fixing the issue. Signed-off-by: Rahul Sharma rahul.sha...@samsung.com --- Based on exynos-drm-next branch in Inki Dae's tree. drivers/gpu/drm/exynos/exynos_drm_drv.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c b/drivers/gpu/drm/exynos/exynos_drm_drv.c index bb7dfee..2bb6233 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c @@ -184,8 +184,8 @@ static int exynos_drm_resume(struct drm_device *dev) connector-funcs-dpms(connector, connector-dpms); } - drm_helper_resume_force_mode(dev); drm_modeset_unlock_all(dev); + drm_helper_resume_force_mode(dev); 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
Re: [PATCH v3 12/16] clk: exynos5420: fix register offset for sclk_bpll
Hi shaik,
On Thu, Apr 24, 2014 at 6:33 PM, Shaik Ameer Basha
shaik.am...@samsung.com wrote:
This patch fixes the wrong register offset for sclk_bpll clock.
Signed-off-by: Shaik Ameer Basha shaik.am...@samsung.com
---
Reviwed-by: Alim Akhtar alim.akh...@samsung.com
drivers/clk/samsung/clk-exynos5420.c |4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/clk/samsung/clk-exynos5420.c
b/drivers/clk/samsung/clk-exynos5420.c
index 6daf739..3afc112 100755
--- a/drivers/clk/samsung/clk-exynos5420.c
+++ b/drivers/clk/samsung/clk-exynos5420.c
@@ -111,7 +111,6 @@
#define TOP_SPARE2 0x10b08
#define BPLL_LOCK 0x20010
#define BPLL_CON0 0x20110
-#define SRC_CDREX 0x20200
#define KPLL_LOCK 0x28000
#define KPLL_CON0 0x28100
#define SRC_KFC0x28200
@@ -204,7 +203,6 @@ static unsigned long exynos5420_clk_regs[] __initdata = {
GATE_TOP_SCLK_FSYS,
GATE_TOP_SCLK_PERIC,
TOP_SPARE2,
- SRC_CDREX,
SRC_KFC,
DIV_KFC0,
};
@@ -380,7 +378,7 @@ static struct samsung_mux_clock exynos5420_mux_clks[]
__initdata = {
MUX(0, mout_kpll, mout_kpll_p, SRC_KFC, 0, 1),
MUX(0, mout_kfc, mout_kfc_p, SRC_KFC, 16, 1),
- MUX(0, sclk_bpll, mout_bpll_p, SRC_CDREX, 0, 1),
+ MUX(0, sclk_bpll, mout_bpll_p, TOP_SPARE2, 0, 1),
Hmmm. Nice catch
MUX_A(0, mout_aclk400_mscl, mout_group1_p,
SRC_TOP0, 4, 2, aclk400_mscl),
--
1.7.9.5
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
Regards,
Alim
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 16/16] clk: exynos5420: add more registers to restore list
Hi Shaik
On Thu, Apr 24, 2014 at 6:33 PM, Shaik Ameer Basha
shaik.am...@samsung.com wrote:
This patch adds more register offsets to the restore list.
Signed-off-by: Shaik Ameer Basha shaik.am...@samsung.com
---
Reviewed-by: Alim Akhtar alim.akh...@samsung.com
drivers/clk/samsung/clk-exynos5420.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/clk/samsung/clk-exynos5420.c
b/drivers/clk/samsung/clk-exynos5420.c
index 33a48d2..6dfd3fd 100755
--- a/drivers/clk/samsung/clk-exynos5420.c
+++ b/drivers/clk/samsung/clk-exynos5420.c
@@ -27,6 +27,7 @@
#define DIV_CPU1 0x504
#define GATE_BUS_CPU 0x700
#define GATE_SCLK_CPU 0x800
+#define CLKOUT_CMU_CPU 0xa00
#define GATE_IP_G2D0x8800
#define CPLL_LOCK 0x10020
#define DPLL_LOCK 0x10030
@@ -39,7 +40,11 @@
#define CPLL_CON0 0x10120
#define DPLL_CON0 0x10128
#define EPLL_CON0 0x10130
+#define EPLL_CON1 0x10134
+#define EPLL_CON2 0x10138
#define RPLL_CON0 0x10140
+#define RPLL_CON1 0x10144
+#define RPLL_CON2 0x10148
#define IPLL_CON0 0x10150
#define SPLL_CON0 0x10160
#define VPLL_CON0 0x10170
@@ -139,6 +144,13 @@ static unsigned long exynos5420_clk_regs[] __initdata = {
DIV_CPU1,
GATE_BUS_CPU,
GATE_SCLK_CPU,
+ CLKOUT_CMU_CPU,
+ EPLL_CON0,
+ EPLL_CON1,
+ EPLL_CON2,
+ RPLL_CON0,
+ RPLL_CON1,
+ RPLL_CON2,
SRC_TOP0,
SRC_TOP1,
SRC_TOP2,
--
1.7.9.5
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
Regards,
Alim
--
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
[RFC PATCH 0/4] drivers/base: Generic framework for tracking internal interfaces
Generic framework for tracking internal interfaces == Summary --- interface_tracker is a generic framework which allows to track appearance and disappearance of different interfaces provided by kernel/driver code inside the kernel. Examples of such interfaces: clocks, phys, regulators, drm_panel... Interface is specified by a pair of object pointer and interface type. Object type depends on interface type, for example interface type drm_panel determines that object is a device_node. Object pointer is used to distinguish different interfaces of the same type and should identify object the interface is bound to. For example it could be DT node, struct device,... The framework provides two functions for interface providers which should be called just after interface becomes available or just before interface removal. Interface consumers can register callback which will be called when requested interface changes its state, if during callback registration the interface is already up, notification will be sent also. The framework allows nesting calls, for example it is possible to signal one interface in tracker callback of another interface. It is done by putting every request into the queue. If the queue is empty before adding the request, the queue will be processed after, if there is already another request in the queue it means the queue is already processed by different thread so no additional action is required. With this pattern only spinlock is necessary to protect the queue. However in case of removal of either callback or interface caller should be sure that his request has been processed so framework waits until the queue becomes empty, it is done using completion mechanism. The framework functions should not be called in atomic context. Callbacks should be aware that they can be called in any time between registration and de-registration, so they should use synchronization mechanisms carefully. Callbacks should also avoid to perform time consuming tasks, the framework serializes them, so it could stall other callbacks. Use cases - The interface is very generic, there are many situations it can be useful: 1. Replacement for subsystem specific methods of publishing/unpublishing interfaces. Currently many frameworks allows only querying for presence of given interface. In such cases client can defer probing or implement interface polling, which is usually subobtimal. Additionally subsystems often do not provide methods to signal to the consumers that they are about to be destroyed. 2. Monitoring for different interfaces provided by the same object. An example should explain it better. Lets assume in device tree drm crtc device node have video link to another node, so it knows only that there is something connected to its RGB output. It can be a RGB panel (drm_panel framework), it can be an image enhancer (SoC specific framework) or it can be some signal converter (drm_encoder, drm_bridge, drm_encoder_slave...). Driver have only phandle to another node. Currently it is difficult to handle such situations in a generic way. interface_tracker should make it simple: crtc should monitor all supported interface types that appears at the device_node pointed by the phandle. Potential use cases --- Points mentioned above were the reasons for writing this framework. During development I have realized that this framework can be also useful for other tasks. 3. Replacement for deferred probing - if for some reason driver do not wants to defer but it requires given resources it can use interface_tracker. It should be possible to create an helper which will wait for appearance of all interfaces from a given list, and 'continue' probe only when all resources becomes available. 4. Replacement or helper for subsystem specific solutions: - V4L2 subdev async registration, - component framework. Both frameworks solves a problem of tracking sub-components (un-)registration by master device, it should be possible to do the same with interface_tracker framework. Some additional helpers can be convienent to make the implementation easier. 5. Cure the situation with sysfs 'unbind' property. Currently many drivers are providers of different resources/interfaces: regulators, clocks, phys, V4L2 subdevs, ... They are usually protected from module unloading by getting module reference, but there is no protection from driver unbinding using sysfs method: echo 'device' /sys/bus/.../drivers/.../unbind. After unbind consumer stays with the pointer to non-existing object, next time it tries to use it system usually crashes. interface_tracker do not add any protection, but it adds a way to signal to the consumer that given resource will disappear. It allows to handle such situations more gently. Potential issues/extensions --- 1. Scalability - the framework serializes all tasks and callbacks. In case there are no many users
Re: [PATCH v3 15/16] clk: exynos5420: create clock ID for mout_sclk_vpll
Hi Shaik
On Thu, Apr 24, 2014 at 6:33 PM, Shaik Ameer Basha
shaik.am...@samsung.com wrote:
This patch adds clock ID for mout_sclk_vpll clock
Signed-off-by: Shaik Ameer Basha shaik.am...@samsung.com
---
drivers/clk/samsung/clk-exynos5420.c |2 +-
include/dt-bindings/clock/exynos5420.h |1 +
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/samsung/clk-exynos5420.c
b/drivers/clk/samsung/clk-exynos5420.c
index 944ff20..33a48d2 100755
--- a/drivers/clk/samsung/clk-exynos5420.c
+++ b/drivers/clk/samsung/clk-exynos5420.c
@@ -437,7 +437,7 @@ static struct samsung_mux_clock exynos5420_mux_clks[]
__initdata = {
SRC_TOP5, 28, 1),
MUX(0, mout_sclk_mpll, mout_mpll_p, SRC_TOP6, 0, 1),
- MUX(0, mout_sclk_vpll, mout_vpll_p, SRC_TOP6, 4, 1),
+ MUX(CLK_MOUT_VPLL, mout_sclk_vpll, mout_vpll_p, SRC_TOP6, 4, 1),
Any perticular reason for just this change??
MUX(0, mout_sclk_spll, mout_spll_p, SRC_TOP6, 8, 1),
MUX(0, mout_sclk_ipll, mout_ipll_p, SRC_TOP6, 12, 1),
MUX(0, mout_sclk_rpll, mout_rpll_p, SRC_TOP6, 16, 1),
diff --git a/include/dt-bindings/clock/exynos5420.h
b/include/dt-bindings/clock/exynos5420.h
index b2410bc..7c80443 100755
--- a/include/dt-bindings/clock/exynos5420.h
+++ b/include/dt-bindings/clock/exynos5420.h
@@ -190,6 +190,7 @@
#define CLK_MOUT_HDMI 640
#define CLK_MOUT_MAUDIO0 642
#define CLK_MOUT_G3D 643
+#define CLK_MOUT_VPLL 644
/* divider clocks */
#define CLK_DOUT_PIXEL 768
--
1.7.9.5
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
Regards,
Alim
--
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
[RFC PATCH 2/4] drm/panel: add interface tracker support
drm_panel framework allows only query for presence of given panel.
It also does not protect panel module from unloading and does not
provide solution for driver unbinding. interface_tracker
should solve both issues.
Signed-off-by: Andrzej Hajda a.ha...@samsung.com
---
---
drivers/gpu/drm/drm_panel.c | 5 +
include/linux/interface_tracker.h | 2 ++
2 files changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/drm_panel.c b/drivers/gpu/drm/drm_panel.c
index 2ef988e..72a3c5c 100644
--- a/drivers/gpu/drm/drm_panel.c
+++ b/drivers/gpu/drm/drm_panel.c
@@ -22,6 +22,7 @@
*/
#include linux/err.h
+#include linux/interface_tracker.h
#include linux/module.h
#include drm/drm_crtc.h
@@ -41,6 +42,8 @@ int drm_panel_add(struct drm_panel *panel)
mutex_lock(panel_lock);
list_add_tail(panel-list, panel_list);
mutex_unlock(panel_lock);
+ interface_tracker_ifup(panel-dev-of_node,
+ INTERFACE_TRACKER_TYPE_DRM_PANEL, panel);
return 0;
}
@@ -48,6 +51,8 @@ EXPORT_SYMBOL(drm_panel_add);
void drm_panel_remove(struct drm_panel *panel)
{
+ interface_tracker_ifdown(panel-dev-of_node,
+INTERFACE_TRACKER_TYPE_DRM_PANEL, panel);
mutex_lock(panel_lock);
list_del_init(panel-list);
mutex_unlock(panel_lock);
diff --git a/include/linux/interface_tracker.h
b/include/linux/interface_tracker.h
index e1eff00..0a08cba 100644
--- a/include/linux/interface_tracker.h
+++ b/include/linux/interface_tracker.h
@@ -6,6 +6,8 @@
struct list_head;
struct interface_tracker_block;
+#define INTERFACE_TRACKER_TYPE_DRM_PANEL 1
+
typedef void (*interface_tracker_fn_t)(struct interface_tracker_block *itb,
const void *object, unsigned long type,
bool on, void *data);
--
1.8.3.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
[RFC PATCH 4/4] drm/panel/ld9040: do not power off panel on removal
Panel is powered off already by connector during drm_panel_remove call.
Signed-off-by: Andrzej Hajda a.ha...@samsung.com
---
drivers/gpu/drm/panel/panel-ld9040.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/panel/panel-ld9040.c
b/drivers/gpu/drm/panel/panel-ld9040.c
index 1f1f837..1def4b0 100644
--- a/drivers/gpu/drm/panel/panel-ld9040.c
+++ b/drivers/gpu/drm/panel/panel-ld9040.c
@@ -348,7 +348,6 @@ static int ld9040_remove(struct spi_device *spi)
{
struct ld9040 *ctx = spi_get_drvdata(spi);
- ld9040_power_off(ctx);
drm_panel_remove(ctx-panel);
return 0;
--
1.8.3.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
[RFC PATCH 3/4] drm/exynos/dpi: add interface tracker support
exynos_dpi uses connector polling for tracking panel presence,
this solution introduces unnecessary 10s delay before panel activation.
Moreover it is unsafe, module unloading or driver unbinding can
cause system crash. interface_tracker support solves both problems.
Signed-off-by: Andrzej Hajda a.ha...@samsung.com
---
drivers/gpu/drm/exynos/exynos_drm_dpi.c | 58 ++---
1 file changed, 47 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dpi.c
b/drivers/gpu/drm/exynos/exynos_drm_dpi.c
index 2b09c7c..4c6682f 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dpi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dpi.c
@@ -14,6 +14,7 @@
#include drm/drm_crtc_helper.h
#include drm/drm_panel.h
+#include linux/interface_tracker.h
#include linux/regulator/consumer.h
#include video/of_videomode.h
@@ -21,6 +22,8 @@
#include exynos_drm_drv.h
+static void exynos_dpi_dpms(struct exynos_drm_display *display, int mode);
+
struct exynos_dpi {
struct device *dev;
struct device_node *panel_node;
@@ -28,6 +31,7 @@ struct exynos_dpi {
struct drm_panel *panel;
struct drm_connector connector;
struct drm_encoder *encoder;
+ struct interface_tracker_block itb;
struct videomode *vm;
int dpms_mode;
@@ -41,15 +45,9 @@ exynos_dpi_detect(struct drm_connector *connector, bool
force)
struct exynos_dpi *ctx = connector_to_dpi(connector);
/* panels supported only by boot-loader are always connected */
- if (!ctx-panel_node)
+ if (ctx-vm)
return connector_status_connected;
- if (!ctx-panel) {
- ctx-panel = of_drm_find_panel(ctx-panel_node);
- if (ctx-panel)
- drm_panel_attach(ctx-panel, ctx-connector);
- }
-
if (ctx-panel)
return connector_status_connected;
@@ -114,6 +112,28 @@ static struct drm_connector_helper_funcs
exynos_dpi_connector_helper_funcs = {
.best_encoder = exynos_dpi_best_encoder,
};
+void exynos_dpi_notifier(struct interface_tracker_block *itb,
+const void *object, unsigned long type, bool on,
+void *data)
+{
+ struct exynos_dpi *ctx = container_of(itb, struct exynos_dpi, itb);
+
+ mutex_lock(ctx-connector.dev-mode_config.mutex);
+ if (on) {
+ ctx-panel = data;
+ drm_panel_attach(ctx-panel, ctx-connector);
+ } else {
+ struct exynos_drm_display *display;
+
+ display = platform_get_drvdata(to_platform_device(ctx-dev));
+ exynos_dpi_dpms(display, DRM_MODE_DPMS_OFF);
+ drm_panel_detach(ctx-panel);
+ ctx-panel = NULL;
+ }
+ mutex_unlock(ctx-connector.dev-mode_config.mutex);
+ drm_helper_hpd_irq_event(ctx-connector.dev);
+}
+
static int exynos_dpi_create_connector(struct exynos_drm_display *display,
struct drm_encoder *encoder)
{
@@ -123,10 +143,7 @@ static int exynos_dpi_create_connector(struct
exynos_drm_display *display,
ctx-encoder = encoder;
- if (ctx-panel_node)
- connector-polled = DRM_CONNECTOR_POLL_CONNECT;
- else
- connector-polled = DRM_CONNECTOR_POLL_HPD;
+ connector-polled = DRM_CONNECTOR_POLL_HPD;
ret = drm_connector_init(encoder-dev, connector,
exynos_dpi_connector_funcs,
@@ -140,9 +157,27 @@ static int exynos_dpi_create_connector(struct
exynos_drm_display *display,
drm_sysfs_connector_add(connector);
drm_mode_connector_attach_encoder(connector, encoder);
+ if (ctx-panel_node) {
+ ctx-itb.callback = exynos_dpi_notifier;
+ interface_tracker_register(ctx-panel_node,
+ INTERFACE_TRACKER_TYPE_DRM_PANEL,
+ ctx-itb);
+ }
+
return 0;
}
+static void exynos_dpi_display_remove(struct exynos_drm_display *display)
+{
+ struct exynos_dpi *ctx = display-ctx;
+
+ if (ctx-panel_node) {
+ interface_tracker_unregister(ctx-panel_node,
+INTERFACE_TRACKER_TYPE_DRM_PANEL,
+ctx-itb);
+ }
+}
+
static void exynos_dpi_poweron(struct exynos_dpi *ctx)
{
if (ctx-panel)
@@ -178,6 +213,7 @@ static void exynos_dpi_dpms(struct exynos_drm_display
*display, int mode)
static struct exynos_drm_display_ops exynos_dpi_display_ops = {
.create_connector = exynos_dpi_create_connector,
+ .remove = exynos_dpi_display_remove,
.dpms = exynos_dpi_dpms
};
--
1.8.3.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
[RFC PATCH 1/4] drivers/base: add interface tracker framework
interface_tracker is a generic framework which allows to track appearance
and disappearance of different interfaces provided by kernel/driver code inside
the kernel. Examples of such interfaces: clocks, phys, regulators, drm_panel...
Interface is specified by a pair of object pointer and interface type. Object
type depends on interface type, for example interface type drm_panel determines
that object is a device_node. Object pointer is used to distinguish different
interfaces of the same type and should identify object the interface is bound
to.
Signed-off-by: Andrzej Hajda a.ha...@samsung.com
---
drivers/base/Makefile | 2 +-
drivers/base/interface_tracker.c | 307 ++
include/linux/interface_tracker.h | 27
3 files changed, 335 insertions(+), 1 deletion(-)
create mode 100644 drivers/base/interface_tracker.c
create mode 100644 include/linux/interface_tracker.h
diff --git a/drivers/base/Makefile b/drivers/base/Makefile
index 04b314e..5a45c41 100644
--- a/drivers/base/Makefile
+++ b/drivers/base/Makefile
@@ -4,7 +4,7 @@ obj-y := component.o core.o bus.o dd.o
syscore.o \
driver.o class.o platform.o \
cpu.o firmware.o init.o map.o devres.o \
attribute_container.o transport_class.o \
- topology.o container.o
+ topology.o container.o interface_tracker.o
obj-$(CONFIG_DEVTMPFS) += devtmpfs.o
obj-$(CONFIG_DMA_CMA) += dma-contiguous.o
obj-y += power/
diff --git a/drivers/base/interface_tracker.c b/drivers/base/interface_tracker.c
new file mode 100644
index 000..3d36cba
--- /dev/null
+++ b/drivers/base/interface_tracker.c
@@ -0,0 +1,307 @@
+/*
+ * Generic framework for tracking kernel interfaces
+ *
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd
+ * Andrzej Hajda a.ha...@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.
+ *
+ * interface_tracker is a generic framework which allows to track appearance
+ * and disappearance of different interfaces provided by kernel/driver code
+ * inside the kernel. Examples of such interfaces: clocks, phys, regulators,
+ * drm_panel...
+ * Interface is specified by a pair of object pointer and interface type.
Object
+ * type depends on interface type, for example interface type drm_panel
+ * determines that object is a device_node. Object pointer is used
+ * to distinguish different interfaces of the same type and should identify
+ * object the interface is bound to. For example it could be DT node,
+ * struct device...
+ *
+ * The framework provides two functions for interface providers which should be
+ * called just after interface becomes available or just before interface
+ * removal. Interface consumers can register callback which will be called when
+ * the requested interface changes its state, if during callback registration
+ * the interface is already up, notification will be sent also.
+ *
+ * The framework allows nesting calls, for example it is possible to signal one
+ * interface in tracker callback of another interface. It is done by putting
+ * every request into the queue. If the queue is empty before adding
+ * the request, the queue will be processed after, if there is already another
+ * request in the queue it means the queue is already processed by different
+ * thread so no additional action is required. With this pattern only spinlock
+ * is necessary to protect the queue. However in case of removal of either
+ * callback or interface caller should be sure that his request has been
+ * processed so framework waits until the queue becomes empty, it is done using
+ * completion mechanism.
+ * The framework functions should not be called in atomic context. Callbacks
+ * should be aware that they can be called in any time between registration and
+ * unregistration, so they should use synchronization mechanisms carefully.
+ * Callbacks should also avoid to perform time consuming tasks, the framework
+ * serializes them, so it could stall other callbacks.
+ */
+
+#include linux/completion.h
+#include linux/interface_tracker.h
+#include linux/list.h
+#include linux/slab.h
+#include linux/spinlock.h
+
+enum interface_tracker_task_id {
+ interface_tracker_task_register,
+ interface_tracker_task_unregister,
+ interface_tracker_task_ifup,
+ interface_tracker_task_ifdown,
+};
+
+struct interface_tracker_task {
+ struct list_head list;
+ enum interface_tracker_task_id task_id;
+
+ const void *object;
+ unsigned long type;
+ union {
+ struct interface_tracker_block *itb;
+ void *data;
+ };
+};
+
+struct interface_tracker_node {
+ struct list_head list;
+ struct list_head itb_head;
Re: [PATCH v2 1/2] v4l: Add resolution change event.
On 04/30/2014 12:38 PM, Arun Kumar K wrote:
Hi Hans,
On 04/22/14 18:22, Hans Verkuil wrote:
On 04/21/2014 11:26 AM, 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.
The event can also be used for more generic events involving resolution
or format changes at runtime for all kinds of video devices.
Signed-off-by: Pawel Osciak posc...@chromium.org
Signed-off-by: Arun Kumar K arun...@samsung.com
---
.../DocBook/media/v4l/vidioc-subscribe-event.xml | 16
include/uapi/linux/videodev2.h |6 ++
2 files changed, 22 insertions(+)
diff --git a/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml
b/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml
index 5c70b61..0aec831 100644
--- a/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml
@@ -155,6 +155,22 @@
/entry
/row
row
+ entryconstantV4L2_EVENT_SOURCE_CHANGE/constant/entry
+ entry5/entry
+ entry
+ paraThis event is triggered when a resolution or format change
+ is detected during runtime by the video device. It can be a
+ runtime resolution change triggered by a video decoder or the
+ format change happening on an HDMI connector. Application may
+ need to reinitialize buffers before proceeding further./para
+
+ paraThis event has a v4l2-event-source-change; associated
+ with it. This has significance only for v4l2 subdevs where the
+ structfieldpad_num/structfield field will be updated with
+ the pad number on which the event is triggered./para
+ /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..12e0614 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_SOURCE_CHANGE 5
#define V4L2_EVENT_PRIVATE_START 0x0800
/* Payload for V4L2_EVENT_VSYNC */
@@ -1764,12 +1765,17 @@ struct v4l2_event_frame_sync {
__u32 frame_sequence;
};
+struct v4l2_event_source_change {
+ __u32 pad_num;
+};
+
struct v4l2_event {
__u32 type;
union {
struct v4l2_event_vsync vsync;
struct v4l2_event_ctrl ctrl;
struct v4l2_event_frame_syncframe_sync;
+ struct v4l2_event_source_change source_change;
__u8data[64];
} u;
__u32 pending;
This needs to be done differently. The problem is that you really have
multiple
events that you want to subscribe to: one for each pad (or input: see the way
VIDIOC_G/S_EDID maps pad to an input or output index when used with a video
node,
we have to support that for this event as well).
What you want to do is similar to what is done for control events: there you
can
subscribe for a specific control and get notified when that control changes.
The way that works in the event code is that the 'id' field in the v4l2_event
struct contains that control ID, or, in this case, the pad/input/output
index.
As I am new to v4l2-events itself, I might have some noob questions.
I understood filling pad index into id field. But for video nodes,
the application is supposed to put v4l2_buf_type in the id field?
No, a capture video node can have multiple inputs (those are enumerated with
VIDIOC_ENUMINPUTS), and each input can generate a SOURCE_CHANGE event, even if
it
is not the currently active input. Hence the need of setting id to the input
index. v4l2_buf_type makes no sense here.
In the application you will subscribe to the SOURCE_CHANGE event for a
specific
pad/input/output index.
In other words, the pad_num field should be dropped and the id field used
instead.
Assuming we will also add a 'changes' field (see my reply to the other post
on that topic), then you should also provide replace and merge ops (see
v4l2-ctrls.c). That way it is sufficient to use just one element when calling
v4l2_event_subscribe(): you will never loose information since if multiple
events arrive before the application can dequeue them, the 'changes'
information
will be the ORed value of all those intermediate events.
Re: [PATCH v3 12/16] clk: exynos5420: fix register offset for sclk_bpll
Hi Shaik,
On 24 April 2014 18:33, Shaik Ameer Basha shaik.am...@samsung.com wrote:
This patch fixes the wrong register offset for sclk_bpll clock.
Since this patch is a fix, it is better to send it separately so that
it gets into one of
the upcoming RCs (and if needed to stable).
Signed-off-by: Shaik Ameer Basha shaik.am...@samsung.com
---
drivers/clk/samsung/clk-exynos5420.c |4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/clk/samsung/clk-exynos5420.c
b/drivers/clk/samsung/clk-exynos5420.c
index 6daf739..3afc112 100755
--- a/drivers/clk/samsung/clk-exynos5420.c
+++ b/drivers/clk/samsung/clk-exynos5420.c
@@ -111,7 +111,6 @@
#define TOP_SPARE2 0x10b08
#define BPLL_LOCK 0x20010
#define BPLL_CON0 0x20110
-#define SRC_CDREX 0x20200
#define KPLL_LOCK 0x28000
#define KPLL_CON0 0x28100
#define SRC_KFC0x28200
@@ -204,7 +203,6 @@ static unsigned long exynos5420_clk_regs[] __initdata = {
GATE_TOP_SCLK_FSYS,
GATE_TOP_SCLK_PERIC,
TOP_SPARE2,
- SRC_CDREX,
SRC_KFC,
DIV_KFC0,
};
@@ -380,7 +378,7 @@ static struct samsung_mux_clock exynos5420_mux_clks[]
__initdata = {
MUX(0, mout_kpll, mout_kpll_p, SRC_KFC, 0, 1),
MUX(0, mout_kfc, mout_kfc_p, SRC_KFC, 16, 1),
- MUX(0, sclk_bpll, mout_bpll_p, SRC_CDREX, 0, 1),
+ MUX(0, sclk_bpll, mout_bpll_p, TOP_SPARE2, 0, 1),
MUX_A(0, mout_aclk400_mscl, mout_group1_p,
SRC_TOP0, 4, 2, aclk400_mscl),
--
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
--
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 v3 08/16] clk: exynos5420: update clocks for PERIS and GEN blocks
Hi Shaik, On 24 April 2014 18:33, Shaik Ameer Basha shaik.am...@samsung.com wrote: This patch fixes some parent-child relationships according to the latest datasheet and adds more clocks related to PERIS and GEN blocks. Again, it is better to split up the fixes from other stuff so that it can go in the -rc and can be back ported to stable if needed. -- 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: [RFC PATCH 0/4] drivers/base: Generic framework for tracking internal interfaces
On Wed, Apr 30, 2014 at 04:02:50PM +0200, Andrzej Hajda wrote: Generic framework for tracking internal interfaces == Summary --- interface_tracker is a generic framework which allows to track appearance and disappearance of different interfaces provided by kernel/driver code inside the kernel. Examples of such interfaces: clocks, phys, regulators, drm_panel... Interface is specified by a pair of object pointer and interface type. Object type depends on interface type, for example interface type drm_panel determines that object is a device_node. Object pointer is used to distinguish different interfaces of the same type and should identify object the interface is bound to. For example it could be DT node, struct device,... The framework provides two functions for interface providers which should be called just after interface becomes available or just before interface removal. Interface consumers can register callback which will be called when requested interface changes its state, if during callback registration the interface is already up, notification will be sent also. The framework allows nesting calls, for example it is possible to signal one interface in tracker callback of another interface. It is done by putting every request into the queue. If the queue is empty before adding the request, the queue will be processed after, if there is already another request in the queue it means the queue is already processed by different thread so no additional action is required. With this pattern only spinlock is necessary to protect the queue. However in case of removal of either callback or interface caller should be sure that his request has been processed so framework waits until the queue becomes empty, it is done using completion mechanism. The framework functions should not be called in atomic context. Callbacks should be aware that they can be called in any time between registration and de-registration, so they should use synchronization mechanisms carefully. Callbacks should also avoid to perform time consuming tasks, the framework serializes them, so it could stall other callbacks. Use cases - The interface is very generic, there are many situations it can be useful: 1. Replacement for subsystem specific methods of publishing/unpublishing interfaces. Currently many frameworks allows only querying for presence of given interface. In such cases client can defer probing or implement interface polling, which is usually subobtimal. Additionally subsystems often do not provide methods to signal to the consumers that they are about to be destroyed. 2. Monitoring for different interfaces provided by the same object. An example should explain it better. Lets assume in device tree drm crtc device node have video link to another node, so it knows only that there is something connected to its RGB output. It can be a RGB panel (drm_panel framework), it can be an image enhancer (SoC specific framework) or it can be some signal converter (drm_encoder, drm_bridge, drm_encoder_slave...). Driver have only phandle to another node. Currently it is difficult to handle such situations in a generic way. interface_tracker should make it simple: crtc should monitor all supported interface types that appears at the device_node pointed by the phandle. Potential use cases --- Points mentioned above were the reasons for writing this framework. During development I have realized that this framework can be also useful for other tasks. 3. Replacement for deferred probing - if for some reason driver do not wants to defer but it requires given resources it can use interface_tracker. It should be possible to create an helper which will wait for appearance of all interfaces from a given list, and 'continue' probe only when all resources becomes available. 4. Replacement or helper for subsystem specific solutions: - V4L2 subdev async registration, - component framework. Both frameworks solves a problem of tracking sub-components (un-)registration by master device, it should be possible to do the same with interface_tracker framework. Some additional helpers can be convienent to make the implementation easier. 5. Cure the situation with sysfs 'unbind' property. Currently many drivers are providers of different resources/interfaces: regulators, clocks, phys, V4L2 subdevs, ... They are usually protected from module unloading by getting module reference, but there is no protection from driver unbinding using sysfs method: echo 'device' /sys/bus/.../drivers/.../unbind. After unbind consumer stays with the pointer to non-existing object, next time it tries to use it system usually crashes. interface_tracker do not add any protection, but it adds a way to signal to the consumer that given resource will disappear. It allows to handle such
Re: [PATCH 2/4] ARM: dts: Add usb2phy to Exynos 5250
Hi Vivek,
On 30 April 2014 14:25, Vivek Gautam gautam.vi...@samsung.com wrote:
From: Kamil Debski k.deb...@samsung.com
Add support to PHY of USB2 of the Exynos 5250 SoC.
Signed-off-by: Kamil Debski k.deb...@samsung.com
[gautam.vi...@samsung.com: Split the usb phy entries from
syscon entries from earlier patch: dts: Add usb2phy to Exynos 5250]
[gautam.vi...@samsung.com: Added phy entry for OHCI also along with EHCI]
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
Changes from v7:
None
arch/arm/boot/dts/exynos5250.dtsi | 26 ++
1 file changed, 26 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index 70f0cd5..51e554c 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -563,6 +563,14 @@
clocks = clock CLK_USB2;
clock-names = usbhost;
+ #address-cells = 1;
+ #size-cells = 0;
+ port@0 {
+ reg = 0;
+ phys = usb2_phy_gen 1;
+ phy-names = host;
+ status = ok;
This should be okay.
+ };
};
usb@1212 {
@@ -572,6 +580,14 @@
clocks = clock CLK_USB2;
clock-names = usbhost;
+ #address-cells = 1;
+ #size-cells = 0;
+ port@0 {
+ reg = 0;
+ phys = usb2_phy_gen 1;
+ phy-names = host;
+ status = ok;
ditto.
--
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 4/4] ARM: dts: Add usb 2.0 support on exynos5420
On 30 April 2014 14:25, Vivek Gautam gautam.vi...@samsung.com wrote:
Add required device node for ehci and ohci controllers to
enable USB 2.0 support.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
arch/arm/boot/dts/exynos5420.dtsi | 36 +++-
1 file changed, 35 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch/arm/boot/dts/exynos5420.dtsi
index 16b860a..392d340 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -738,7 +738,41 @@
samsung,power-domain = g2d_pd;
};
- phy@1213 {
+ usb@1211 {
+ compatible = samsung,exynos4210-ehci;
+ reg = 0x1211 0x100;
+ interrupts = 0 71 0;
+
+ clocks = clock CLK_USBH20;
+ clock-names = usbhost;
+ #address-cells = 1;
+ #size-cells = 0;
+ port@0 {
+ reg = 0;
+ phys = usb2_phy_gen 1;
+ phy-names = host;
+ status = ok;
s/ok/okay
+ };
+ };
+
+ usb@1212 {
+ compatible = samsung,exynos4210-ohci;
+ reg = 0x1212 0x100;
+ interrupts = 0 71 0;
+
+ clocks = clock CLK_USBH20;
+ clock-names = usbhost;
+ #address-cells = 1;
+ #size-cells = 0;
+ port@0 {
+ reg = 0;
+ phys = usb2_phy_gen 1;
+ phy-names = host;
+ status = ok;
ditto
--
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] ARM: dts: Add peach-pit board support
Arun,
On Wed, Apr 23, 2014 at 9:17 PM, Arun Kumar K arun...@samsung.com wrote:
Adds the google peach-pit board dts file which uses
exynos5420 SoC.
Signed-off-by: Arun Kumar K arun...@samsung.com
Signed-off-by: Doug Anderson diand...@chromium.org
---
Changes from v1
---
- Addressed review comments from Doug, Sachin Tushar
- Removed adc and lid-switch nodes
---
arch/arm/boot/dts/Makefile |1 +
arch/arm/boot/dts/exynos5420-peach-pit.dts | 182
2 files changed, 183 insertions(+)
create mode 100644 arch/arm/boot/dts/exynos5420-peach-pit.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 35c146f..3220e29 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -74,6 +74,7 @@ dtb-$(CONFIG_ARCH_EXYNOS) += exynos4210-origen.dtb \
exynos5250-smdk5250.dtb \
exynos5250-snow.dtb \
exynos5420-arndale-octa.dtb \
+ exynos5420-peach-pit.dtb \
exynos5420-smdk5420.dtb \
exynos5440-sd5v1.dtb \
exynos5440-ssdk5440.dtb
diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts
b/arch/arm/boot/dts/exynos5420-peach-pit.dts
new file mode 100644
index 000..fbb0469
--- /dev/null
+++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
@@ -0,0 +1,182 @@
+/*
+ * Google Peach Pit Rev 6+ board device tree source
+ *
+ * Copyright (c) 2014 Google, Inc
+ *
+ * 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.
+ */
+
+/dts-v1/;
+#include dt-bindings/input/input.h
+#include dt-bindings/gpio/gpio.h
+#include exynos5420.dtsi
+
+/ {
+ model = Google Peach Pit Rev 6+;
+
+ compatible = google,pit-rev16,
+ google,pit-rev15, google,pit-rev14,
+ google,pit-rev13, google,pit-rev12,
+ google,pit-rev11, google,pit-rev10,
+ google,pit-rev9, google,pit-rev8,
+ google,pit-rev7, google,pit-rev6,
+ google,pit, google,peach,samsung,exynos5420,
+ samsung,exynos5;
+
+ memory {
+ reg = 0x2000 0x8000;
+ };
One other thing that came up at ELC: it might not be so wise to
include actual values here. We're expecting that the bootloader will
probe memory and tell you whether you're on a 2GB board or a 4GB
board. IIRC the proper thing to do here is to use 0 for both, so:
reg = 0 0;
-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 6/7] i2c: ChromeOS EC tunnel driver
On ARM Chromebooks we have a few devices that are accessed by both the
AP (the main Application Processor) and the EC (the Embedded
Controller). These are:
* The battery (sbs-battery).
* The power management unit tps65090.
On the original Samsung ARM Chromebook these devices were on an I2C
bus that was shared between the AP and the EC and arbitrated using
some extranal GPIOs (see i2c-arb-gpio-challenge).
The original arbitration scheme worked well enough but had some
downsides:
* It was nonstandard (not using standard I2C multimaster)
* It only worked if the EC-AP communication was I2C
* It was relatively hard to debug problems (hard to tell if i2c issues
were caused by the EC, the AP, or some device on the bus).
On the HP Chromebook 11 the design was changed to:
* The AP/EC comms were still i2c, but the battery/tps65090 were no
longer on the bus used for AP/EC communication. The battery was
exposed to the AP through a limited i2c tunnel and tps65090 was
exposed to the AP through a custom Linux driver.
On the Samsung ARM Chromebook 2 the scheme is changed yet again, now:
* The AP/EC comms are now using SPI for faster speeds.
* The EC's i2c bus is exposed to the AP through a full i2c tunnel.
The upstream tegra124-venice2 uses the same scheme as the Samsung
ARM Chromebook 2, though it has a different set of components on the
other side of the bus.
This driver supports the scheme used by the Samsung ARM Chromebook 2.
Future patches to this driver could add support for the battery tunnel
on the HP Chromebook 11 (and perhaps could even be used to access
tps65090 on the HP Chromebook 11 instead of using a special driver,
but I haven't researched that enough).
Signed-off-by: Vincent Palatin vpala...@chromium.org
Signed-off-by: Simon Glass s...@chromium.org
Signed-off-by: Doug Anderson diand...@chromium.org
---
Changes in v3:
- Separate out packet sizing from packet stuffing.
- Get rid of useless dev_dbg.
- Check command_sendrecv against NULL.
- Don't check np against NULL.
- Get rid of useless error on memory alloc fail.
- Get rid of useless platform_set_drvdata(dev, NULL);
Changes in v2:
- Update tunnel binding as per swarren
.../devicetree/bindings/i2c/i2c-cros-ec-tunnel.txt | 39 +++
drivers/i2c/busses/Kconfig | 9 +
drivers/i2c/busses/Makefile| 1 +
drivers/i2c/busses/i2c-cros-ec-tunnel.c| 318 +
drivers/mfd/cros_ec.c | 5 +
5 files changed, 372 insertions(+)
create mode 100644 Documentation/devicetree/bindings/i2c/i2c-cros-ec-tunnel.txt
create mode 100644 drivers/i2c/busses/i2c-cros-ec-tunnel.c
diff --git a/Documentation/devicetree/bindings/i2c/i2c-cros-ec-tunnel.txt
b/Documentation/devicetree/bindings/i2c/i2c-cros-ec-tunnel.txt
new file mode 100644
index 000..898f030
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-cros-ec-tunnel.txt
@@ -0,0 +1,39 @@
+I2C bus that tunnels through the ChromeOS EC (cros-ec)
+==
+On some ChromeOS board designs we've got a connection to the EC (embedded
+controller) but no direct connection to some devices on the other side of
+the EC (like a battery and PMIC). To get access to those devices we need
+to tunnel our i2c commands through the EC.
+
+The node for this device should be under a cros-ec node like google,cros-ec-spi
+or google,cros-ec-i2c.
+
+
+Required properties:
+- compatible: google,cros-ec-i2c-tunnel
+- google,remote-bus: The EC bus we'd like to talk to.
+
+Optional child nodes:
+- One node per I2C device connected to the tunnelled I2C bus.
+
+
+Example:
+ cros-ec@0 {
+ compatible = google,cros-ec-spi;
+
+ ...
+
+ i2c-tunnel {
+ compatible = google,cros-ec-i2c-tunnel;
+ #address-cells = 1;
+ #size-cells = 0;
+
+ google,remote-bus = 0;
+
+ battery: sbs-battery@b {
+ compatible = sbs,sbs-battery;
+ reg = 0xb;
+ sbs,poll-retry-count = 1;
+ };
+ };
+ }
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index c94db1c..9a0a6cc 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -993,6 +993,15 @@ config I2C_SIBYTE
help
Supports the SiByte SOC on-chip I2C interfaces (2 channels).
+config I2C_CROS_EC_TUNNEL
+ tristate ChromeOS EC tunnel I2C bus
+ depends on MFD_CROS_EC
+ help
+ If you say yes here you get an I2C bus that will tunnel i2c commands
+ through to the other side of the ChromeOS EC to the i2c bus
+ connected there. This will work whatever the interface used to
+ talk to the EC (SPI, I2C or LPC).
+
config SCx200_I2C
tristate NatSemi SCx200 I2C using GPIO
[PATCH v3 3/7] mfd: cros_ec: spi: Make the cros_ec_spi timeout more reliable
The cros_ec_spi transfer had two problems with its timeout code:
1. It looked at the timeout even in the case that it found valid data.
2. If the cros_ec_spi code got switched out for a while, it's possible
it could get a timeout after a single loop. Let's be paranoid and
make sure we do one last transfer after the timeout expires.
Signed-off-by: Doug Anderson diand...@chromium.org
Acked-by: Lee Jones lee.jo...@linaro.org
Reviewed-by: Simon Glass s...@chromium.org
Tested-by: Andrew Bresticker abres...@chromium.org
Tested-by: Stephen Warren swar...@nvidia.com
---
Changes in v3: None
Changes in v2: None
drivers/mfd/cros_ec_spi.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/mfd/cros_ec_spi.c b/drivers/mfd/cros_ec_spi.c
index a2a605d..4f863c3 100644
--- a/drivers/mfd/cros_ec_spi.c
+++ b/drivers/mfd/cros_ec_spi.c
@@ -113,7 +113,9 @@ static int cros_ec_spi_receive_response(struct
cros_ec_device *ec_dev,
/* Receive data until we see the header byte */
deadline = jiffies + msecs_to_jiffies(EC_MSG_DEADLINE_MS);
- do {
+ while (true) {
+ unsigned long start_jiffies = jiffies;
+
memset(trans, 0, sizeof(trans));
trans.cs_change = 1;
trans.rx_buf = ptr = ec_dev-din;
@@ -134,12 +136,19 @@ static int cros_ec_spi_receive_response(struct
cros_ec_device *ec_dev,
break;
}
}
+ if (ptr != end)
+ break;
- if (time_after(jiffies, deadline)) {
+ /*
+* Use the time at the start of the loop as a timeout. This
+* gives us one last shot at getting the transfer and is useful
+* in case we got context switched out for a while.
+*/
+ if (time_after(start_jiffies, deadline)) {
dev_warn(ec_dev-dev, EC failed to respond in time\n);
return -ETIMEDOUT;
}
- } while (ptr == end);
+ }
/*
* ptr now points to the header byte. Copy any valid data to the
--
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/7] mfd: cros_ec: spi: Increase cros_ec_spi deadline from 5ms to 100ms
We're adding i2c tunneling to the list of things that goes over cros_ec. i2c tunneling can be slooow, so increase our deadline to 100ms to account for that. Signed-off-by: Doug Anderson diand...@chromium.org Acked-by: Lee Jones lee.jo...@linaro.org Reviewed-by: Simon Glass s...@chromium.org Tested-by: Andrew Bresticker abres...@chromium.org Tested-by: Stephen Warren swar...@nvidia.com --- Changes in v3: None Changes in v2: None drivers/mfd/cros_ec_spi.c | 24 1 file changed, 16 insertions(+), 8 deletions(-) diff --git a/drivers/mfd/cros_ec_spi.c b/drivers/mfd/cros_ec_spi.c index 4f863c3..0b8d328 100644 --- a/drivers/mfd/cros_ec_spi.c +++ b/drivers/mfd/cros_ec_spi.c @@ -39,14 +39,22 @@ #define EC_MSG_PREAMBLE_COUNT 32 /* - * We must get a response from the EC in 5ms. This is a very long - * time, but the flash write command can take 2-3ms. The EC command - * processing is currently not very fast (about 500us). We could - * look at speeding this up and making the flash write command a - * 'slow' command, requiring a GET_STATUS wait loop, like flash - * erase. - */ -#define EC_MSG_DEADLINE_MS 5 + * Allow for a long time for the EC to respond. We support i2c + * tunneling and support fairly long messages for the tunnel (249 + * bytes long at the moment). If we're talking to a 100 kHz device + * on the other end and need to transfer ~256 bytes, then we need: + * 10 us/bit * ~10 bits/byte * ~256 bytes = ~25ms + * + * We'll wait 4 times that to handle clock stretching and other + * paranoia. + * + * It's pretty unlikely that we'll really see a 249 byte tunnel in + * anything other than testing. If this was more common we might + * consider having slow commands like this require a GET_STATUS + * wait loop. The 'flash write' command would be another candidate + * for this, clocking in at 2-3ms. + */ +#define EC_MSG_DEADLINE_MS 100 /* * Time between raising the SPI chip select (for the end of a -- 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 2/7] mfd: cros_ec: spi: Add mutex to cros_ec_spi
The main transfer function for cros_ec_spi can be called by more than
one client at a time. Make sure that those clients don't stomp on
each other by locking the bus for the duration of the transfer
function.
Signed-off-by: Doug Anderson diand...@chromium.org
Acked-by: Lee Jones lee.jo...@linaro.org
Reviewed-by: Simon Glass s...@chromium.org
Tested-by: Andrew Bresticker abres...@chromium.org
Tested-by: Stephen Warren swar...@nvidia.com
---
Changes in v3: None
Changes in v2: None
drivers/mfd/cros_ec_spi.c | 26 +-
1 file changed, 21 insertions(+), 5 deletions(-)
diff --git a/drivers/mfd/cros_ec_spi.c b/drivers/mfd/cros_ec_spi.c
index c185eb6..a2a605d 100644
--- a/drivers/mfd/cros_ec_spi.c
+++ b/drivers/mfd/cros_ec_spi.c
@@ -65,11 +65,13 @@
* if no record
* @end_of_msg_delay: used to set the delay_usecs on the spi_transfer that
* is sent when we want to turn off CS at the end of a transaction.
+ * @lock: mutex to ensure only one user of cros_ec_command_spi_xfer at a time
*/
struct cros_ec_spi {
struct spi_device *spi;
s64 last_transfer_ns;
unsigned int end_of_msg_delay;
+ struct mutex lock;
};
static void debug_packet(struct device *dev, const char *name, u8 *ptr,
@@ -208,6 +210,13 @@ static int cros_ec_command_spi_xfer(struct cros_ec_device
*ec_dev,
int ret = 0, final_ret;
struct timespec ts;
+ /*
+* We have the shared ec_dev buffer plus we do lots of separate spi_sync
+* calls, so we need to make sure only one person is using this at a
+* time.
+*/
+ mutex_lock(ec_spi-lock);
+
len = cros_ec_prepare_tx(ec_dev, ec_msg);
dev_dbg(ec_dev-dev, prepared, len=%d\n, len);
@@ -260,7 +269,7 @@ static int cros_ec_command_spi_xfer(struct cros_ec_device
*ec_dev,
ret = final_ret;
if (ret 0) {
dev_err(ec_dev-dev, spi transfer failed: %d\n, ret);
- return ret;
+ goto exit;
}
/* check response error code */
@@ -269,14 +278,16 @@ static int cros_ec_command_spi_xfer(struct cros_ec_device
*ec_dev,
dev_warn(ec_dev-dev, command 0x%02x returned an error %d\n,
ec_msg-cmd, ptr[0]);
debug_packet(ec_dev-dev, in_err, ptr, len);
- return -EINVAL;
+ ret = -EINVAL;
+ goto exit;
}
len = ptr[1];
sum = ptr[0] + ptr[1];
if (len ec_msg-in_len) {
dev_err(ec_dev-dev, packet too long (%d bytes, expected %d),
len, ec_msg-in_len);
- return -ENOSPC;
+ ret = -ENOSPC;
+ goto exit;
}
/* copy response packet payload and compute checksum */
@@ -293,10 +304,14 @@ static int cros_ec_command_spi_xfer(struct cros_ec_device
*ec_dev,
dev_err(ec_dev-dev,
bad packet checksum, expected %02x, got %02x\n,
sum, ptr[len + 2]);
- return -EBADMSG;
+ ret = -EBADMSG;
+ goto exit;
}
- return 0;
+ ret = 0;
+exit:
+ mutex_unlock(ec_spi-lock);
+ return ret;
}
static void cros_ec_spi_dt_probe(struct cros_ec_spi *ec_spi, struct device
*dev)
@@ -327,6 +342,7 @@ static int cros_ec_spi_probe(struct spi_device *spi)
if (ec_spi == NULL)
return -ENOMEM;
ec_spi-spi = spi;
+ mutex_init(ec_spi-lock);
ec_dev = devm_kzalloc(dev, sizeof(*ec_dev), GFP_KERNEL);
if (!ec_dev)
return -ENOMEM;
--
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 7/7] ARM: tegra: Add the EC i2c tunnel to tegra124-venice2
This adds the EC i2c tunnel (and devices under it) to the
tegra124-venice2 device tree.
Signed-off-by: Doug Anderson diand...@chromium.org
Tested-by: Andrew Bresticker abres...@chromium.org
Tested-by: Stephen Warren swar...@nvidia.com
---
Changes in v3: None
Changes in v2:
- Removed i2c20 alias for i2c tunnel
arch/arm/boot/dts/tegra124-venice2.dts | 26 ++
1 file changed, 26 insertions(+)
diff --git a/arch/arm/boot/dts/tegra124-venice2.dts
b/arch/arm/boot/dts/tegra124-venice2.dts
index c17283c..89cf776 100644
--- a/arch/arm/boot/dts/tegra124-venice2.dts
+++ b/arch/arm/boot/dts/tegra124-venice2.dts
@@ -813,6 +813,32 @@
google,cros-ec-spi-msg-delay = 2000;
+ i2c-tunnel {
+ compatible = google,cros-ec-i2c-tunnel;
+ #address-cells = 1;
+ #size-cells = 0;
+
+ google,remote-bus = 0;
+
+ charger: bq24735@9 {
+ compatible = ti,bq24735;
+ reg = 0x9;
+ interrupt-parent = gpio;
+ interrupts = TEGRA_GPIO(J, 0)
+ GPIO_ACTIVE_HIGH;
+ ti,ac-detect-gpios = gpio
+ TEGRA_GPIO(J, 0)
+ GPIO_ACTIVE_HIGH;
+ };
+
+ battery: sbs-battery@b {
+ compatible = sbs,sbs-battery;
+ reg = 0xb;
+ sbs,i2c-retry-count = 2;
+ sbs,poll-retry-count = 1;
+ };
+ };
+
cros-ec-keyb {
compatible = google,cros-ec-keyb;
keypad,num-rows = 8;
--
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 0/7] Add cros_ec changes for newer boards
This series adds the most critical cros_ec changes for newer boards using cros_ec. Specifically: * Fixes timing/locking issues with the previously upstreamed (but never used upstream) cros_ec_spi driver. * Updates the cros_ec header file to the latest version which allows us to use newer EC features like i2c tunneling. * Adds an i2c tunnel driver to allow communication to the EC's i2c devices. This _doesn't_ get the EC driver fully up to speed with what's in the current Chromium OS trees. There are a whole slew of cleanup patches there, an addition of an LPC transport mode, and exports of functions to userspace. Once these patches land and we have functionality we can continue to pick more cleanup patches. Changes in v3: - Separate out packet sizing from packet stuffing. - Get rid of useless dev_dbg. - Check command_sendrecv against NULL. - Don't check np against NULL. - Get rid of useless error on memory alloc fail. - Get rid of useless platform_set_drvdata(dev, NULL); Changes in v2: - Update tunnel binding as per swarren - Removed i2c20 alias for i2c tunnel Bill Richardson (1): mfd: cros_ec: Sync to the latest cros_ec_commands.h from EC sources David Hendricks (1): mfd: cros_ec: spi: calculate delay between transfers correctly Doug Anderson (5): mfd: cros_ec: spi: Add mutex to cros_ec_spi mfd: cros_ec: spi: Make the cros_ec_spi timeout more reliable mfd: cros_ec: spi: Increase cros_ec_spi deadline from 5ms to 100ms i2c: ChromeOS EC tunnel driver ARM: tegra: Add the EC i2c tunnel to tegra124-venice2 .../devicetree/bindings/i2c/i2c-cros-ec-tunnel.txt | 39 + arch/arm/boot/dts/tegra124-venice2.dts | 26 + drivers/i2c/busses/Kconfig |9 + drivers/i2c/busses/Makefile|1 + drivers/i2c/busses/i2c-cros-ec-tunnel.c| 318 ++ drivers/mfd/cros_ec.c |7 +- drivers/mfd/cros_ec_spi.c | 67 +- include/linux/mfd/cros_ec.h|4 +- include/linux/mfd/cros_ec_commands.h | 1128 ++-- 9 files changed, 1507 insertions(+), 92 deletions(-) create mode 100644 Documentation/devicetree/bindings/i2c/i2c-cros-ec-tunnel.txt create mode 100644 drivers/i2c/busses/i2c-cros-ec-tunnel.c -- 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 1/7] mfd: cros_ec: spi: calculate delay between transfers correctly
From: David Hendricks dhend...@chromium.org To avoid spamming the EC we calculate the time between the previous transfer and the current transfer and force a delay if the time delta is too small. However, a small miscalculation causes the delay period to be far too short. Most noticably this impacts commands with a long turnaround time such as EC firmware reads and writes. Signed-off-by: David Hendricks dhend...@chromium.org Signed-off-by: Doug Anderson diand...@chromium.org Acked-by: Lee Jones lee.jo...@linaro.org Reviewed-by: Simon Glass s...@chromium.org Tested-by: Andrew Bresticker abres...@chromium.org Tested-by: Stephen Warren swar...@nvidia.com --- Changes in v3: None Changes in v2: None drivers/mfd/cros_ec_spi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mfd/cros_ec_spi.c b/drivers/mfd/cros_ec_spi.c index 84af8d7..c185eb6 100644 --- a/drivers/mfd/cros_ec_spi.c +++ b/drivers/mfd/cros_ec_spi.c @@ -219,7 +219,7 @@ static int cros_ec_command_spi_xfer(struct cros_ec_device *ec_dev, ktime_get_ts(ts); delay = timespec_to_ns(ts) - ec_spi-last_transfer_ns; if (delay EC_SPI_RECOVERY_TIME_NS) - ndelay(delay); + ndelay(EC_SPI_RECOVERY_TIME_NS - delay); } /* Transmit phase - send our message */ -- 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/7] mfd: cros_ec: Sync to the latest cros_ec_commands.h from EC sources
From: Bill Richardson wfric...@chromium.org
This just updates include/linux/mfd/cros_ec_commands.h to match the
latest EC version (which is the One True Source for such things). See
https://chromium.googlesource.com/chromiumos/platform/ec
[dianders: took today's ToT version from the Chromium OS EC; deleted
references to cros_ec_dev and cros_ec_lpc since those aren't upstream
yet]
Signed-off-by: Bill Richardson wfric...@chromium.org
Signed-off-by: Doug Anderson diand...@chromium.org
Acked-by: Lee Jones lee.jo...@linaro.org
Reviewed-by: Simon Glass s...@chromium.org
Tested-by: Andrew Bresticker abres...@chromium.org
Tested-by: Stephen Warren swar...@nvidia.com
---
Changes in v3: None
Changes in v2: None
drivers/mfd/cros_ec.c|2 +-
include/linux/mfd/cros_ec.h |4 +-
include/linux/mfd/cros_ec_commands.h | 1128 +++---
3 files changed, 1059 insertions(+), 75 deletions(-)
diff --git a/drivers/mfd/cros_ec.c b/drivers/mfd/cros_ec.c
index 783fe2e..c58ab96 100644
--- a/drivers/mfd/cros_ec.c
+++ b/drivers/mfd/cros_ec.c
@@ -30,7 +30,7 @@ int cros_ec_prepare_tx(struct cros_ec_device *ec_dev,
uint8_t *out;
int csum, i;
- BUG_ON(msg-out_len EC_HOST_PARAM_SIZE);
+ BUG_ON(msg-out_len EC_PROTO2_MAX_PARAM_SIZE);
out = ec_dev-dout;
out[0] = EC_CMD_VERSION0 + msg-version;
out[1] = msg-cmd;
diff --git a/include/linux/mfd/cros_ec.h b/include/linux/mfd/cros_ec.h
index 032af7f..887ef4f 100644
--- a/include/linux/mfd/cros_ec.h
+++ b/include/linux/mfd/cros_ec.h
@@ -29,8 +29,8 @@ enum {
EC_MSG_RX_PROTO_BYTES = 3,
/* Max length of messages */
- EC_MSG_BYTES= EC_HOST_PARAM_SIZE + EC_MSG_TX_PROTO_BYTES,
-
+ EC_MSG_BYTES= EC_PROTO2_MAX_PARAM_SIZE +
+ EC_MSG_TX_PROTO_BYTES,
};
/**
diff --git a/include/linux/mfd/cros_ec_commands.h
b/include/linux/mfd/cros_ec_commands.h
index 86fd069..7853a64 100644
--- a/include/linux/mfd/cros_ec_commands.h
+++ b/include/linux/mfd/cros_ec_commands.h
@@ -24,25 +24,12 @@
#define __CROS_EC_COMMANDS_H
/*
- * Protocol overview
+ * Current version of this protocol
*
- * request: CMD [ P0 P1 P2 ... Pn S ]
- * response: ERR [ P0 P1 P2 ... Pn S ]
- *
- * where the bytes are defined as follow :
- * - CMD is the command code. (defined by EC_CMD_ constants)
- * - ERR is the error code. (defined by EC_RES_ constants)
- * - Px is the optional payload.
- *it is not sent if the error code is not success.
- *(defined by ec_params_ and ec_response_ structures)
- * - S is the checksum which is the sum of all payload bytes.
- *
- * On LPC, CMD and ERR are sent/received at EC_LPC_ADDR_KERNEL|USER_CMD
- * and the payloads are sent/received at EC_LPC_ADDR_KERNEL|USER_PARAM.
- * On I2C, all bytes are sent serially in the same message.
+ * TODO(crosbug.com/p/11223): This is effectively useless; protocol is
+ * determined in other ways. Remove this once the kernel code no longer
+ * depends on it.
*/
-
-/* Current version of this protocol */
#define EC_PROTO_VERSION 0x0002
/* Command version mask */
@@ -57,13 +44,19 @@
#define EC_LPC_ADDR_HOST_CMD 0x204
/* I/O addresses for host command args and params */
-#define EC_LPC_ADDR_HOST_ARGS 0x800
-#define EC_LPC_ADDR_HOST_PARAM 0x804
-#define EC_HOST_PARAM_SIZE 0x0fc /* Size of param area in bytes */
-
-/* I/O addresses for host command params, old interface */
-#define EC_LPC_ADDR_OLD_PARAM 0x880
-#define EC_OLD_PARAM_SIZE 0x080 /* Size of param area in bytes */
+/* Protocol version 2 */
+#define EC_LPC_ADDR_HOST_ARGS0x800 /* And 0x801, 0x802, 0x803 */
+#define EC_LPC_ADDR_HOST_PARAM 0x804 /* For version 2 params; size is
+* EC_PROTO2_MAX_PARAM_SIZE */
+/* Protocol version 3 */
+#define EC_LPC_ADDR_HOST_PACKET 0x800 /* Offset of version 3 packet */
+#define EC_LPC_HOST_PACKET_SIZE 0x100 /* Max size of version 3 packet */
+
+/* The actual block is 0x800-0x8ff, but some BIOSes think it's 0x880-0x8ff
+ * and they tell the kernel that so we have to think of it as two parts. */
+#define EC_HOST_CMD_REGION00x800
+#define EC_HOST_CMD_REGION10x880
+#define EC_HOST_CMD_REGION_SIZE 0x80
/* EC command register bit functions */
#define EC_LPC_CMDR_DATA (1 0) /* Data ready for host to read */
@@ -79,18 +72,22 @@
#define EC_MEMMAP_TEXT_MAX 8 /* Size of a string in the memory map */
/* The offset address of each type of data in mapped memory. */
-#define EC_MEMMAP_TEMP_SENSOR 0x00 /* Temp sensors */
-#define EC_MEMMAP_FAN 0x10 /* Fan speeds */
-#define EC_MEMMAP_TEMP_SENSOR_B0x18 /* Temp sensors (second set) */
-#define EC_MEMMAP_ID 0x20 /* 'E' 'C' */
+#define EC_MEMMAP_TEMP_SENSOR 0x00 /* Temp sensors 0x00 - 0x0f */
+#define EC_MEMMAP_FAN 0x10 /* Fan speeds 0x10 -
Re: [PATCH V2] ASoC: SAMSUNG: Add sound card driver for Snow board
On Wed, Apr 30, 2014 at 05:30:39PM +0530, Tushar Behera wrote: XCLKOUT mux register (0x10040a00) is not part of core clock SFR range, rather it is part of pmu-system-controller node. One option would be to add a clock provider for XCLKOUT. That would require me to extend current clock driver to get the pmu-system-controller phandle which in turn is dependent on the patch to early initialize syscon driver.[1] Will it be okay to configure XCLKOUT in snow sound-card driver by taking the phandle of pmu-system-controller from device tree? The implementation is provided below. I can't think of any reason why we'd not want to have this visible as a clock? Ideally we don't want to have any ASoC specific clock APIs when we're done, the reason we do at the minute is that the clock API isn't available as standard. signature.asc Description: Digital signature
Re: [RFC v2 PATCH v3 10/14] drm/panel: add S6E3FA0 driver
Hi Thierry,
On Monday 28 April 2014 23:25:50 Thierry Reding wrote:
On Mon, Apr 28, 2014 at 05:05:24PM +0200, Laurent Pinchart wrote:
On Tuesday 22 April 2014 10:24:39 YoungJun Cho wrote:
On 04/22/2014 08:00 AM, Laurent Pinchart wrote:
Hi YoungJun,
Thank you for the patch.
On Monday 21 April 2014 21:28:37 YoungJun Cho wrote:
This patch adds MIPI-DSI command mode based S6E3FA0 AMOLED LCD Panel
driver.
Changelog v2:
- Declares delay, size properties in probe routine instead of DT
Changelog v3:
- Moves CPU timings relevant properties from FIMD DT
(commented by Laurent Pinchart, Andrzej Hajda)
Signed-off-by: YoungJun Cho yj44@samsung.com
Acked-by: Inki Dae inki@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/gpu/drm/panel/Kconfig |7 +
drivers/gpu/drm/panel/Makefile|1 +
drivers/gpu/drm/panel/panel-s6e3fa0.c | 569 ++
3 files changed, 577 insertions(+)
create mode 100644 drivers/gpu/drm/panel/panel-s6e3fa0.c
[snip]
diff --git a/drivers/gpu/drm/panel/panel-s6e3fa0.c
b/drivers/gpu/drm/panel/panel-s6e3fa0.c new file mode 100644
index 000..1282678
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-s6e3fa0.c
@@ -0,0 +1,569 @@
[snip]
+static int s6e3fa0_get_modes(struct drm_panel *panel)
+{
+ struct drm_connector *connector = panel-connector;
+ struct s6e3fa0 *ctx = panel_to_s6e3fa0(panel);
+ struct drm_display_mode *mode;
+
+ mode = drm_mode_create(connector-dev);
+ if (!mode) {
+ DRM_ERROR(failed to create a new display mode\n);
+ return 0;
+ }
+
+ drm_display_mode_from_videomode(ctx-vm, mode);
+ mode-width_mm = ctx-width_mm;
+ mode-height_mm = ctx-height_mm;
+ connector-display_info.width_mm = mode-width_mm;
+ connector-display_info.height_mm = mode-height_mm;
+
+ mode-type = DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED;
+ mode-private = (void *)ctx-cpu_timings;
Wouldn't it make sense to create a new get_interface_params (or
similar)
operation for drm_panel to query interface configuration parameters
instead of shoving it in the mode private field ?
You mean new get_interface_params operation is different from
get_modes() ?
Till now, struct drm_display_mode and most of mode relevant APIs are
only for video interface.
And CPU interface also needs video mode configurations.
I have a plan to implement the CPU interface relevant APIs like video
mode ones, but I think they should be used under current DRM mode APIs
like fill_modes, get_modes and so on.
So after that implementation, this private field will be replaced by
new ones.
Could you explain it in more detail?
The idea is that the interface parameters (RD/WR signals timings in this
case, but this could also include MIPI DSI lane configuration or any
other kind of physical interface parameters) are distinct from the video
modes.
We already have the lanes field in struct mipi_dsi_device.
Seems I've missed the addition of mipi_dsi_device to DRM.
I think in general I'd prefer to not spread these parameters around too
wildly. If this is a general requirement for DBI devices, perhaps what we
need is struct mipi_dbi_device?
That could be done, but I'm not sure we should expose the nature of the panel
device (i.e. I'm a mipi_dsi_device) to the display controller. I would be
worried about using container_of() on panel-dev to get a mipi_dsi_device
pointer, as we would then need a strict guarantee that the panel-dev pointer
is embedded directly in a mipi_dsi_device. This might be doable for DSI, but
other kind of panels might be connected to different control busses (I'm
thinking about I2C and SPI in particular) and still need to expose video
interface parameters to the display controller driver.
--
Regards,
Laurent Pinchart
signature.asc
Description: This is a digitally signed message part.
Re: [PATCH 0/7 v8] crypto:s5p-sss: Add Device tree and Exynos support
Hi Naveen, Herbert, On 04/30/14 15:14, Herbert Xu wrote: On Wed, Apr 30, 2014 at 04:38:05PM +0530, Naveen Krishna Ch wrote: Hello All, On 28 April 2014 16:14, Naveen Krishna Chatradhich.nav...@samsung.com wrote: SSS module on Exynos4210, Exynos5250 and Exynos5420 SoCs has added features to the one on S5PV210. However with minor changes the s5p-sss.c driver can be reused to support SSS modules on Exynos4 and 5 SoCs. This patch set 1. Adds device tree support to the s5p-sss.c driver and Documentation 2. Adds code to support SSS module on Exynos4 and 5 SoCs 3. Adds variant struct to handle the differences in SSS modules 4. Adds clk_prepare/clk_unprepare clocks to the s5p-sss.c driver Note: Compatible exynos4210-secss should work for Exynos4412 and Exynos5260 (Exynos5260, for which ARCH code is under review) I couldn't test on Exynos4412 and Exynos4210 boards, Should be able to test with addition of DT node and clocks support. These patches are under review at https://lkml.org/lkml/2014/2/17/124 Naveen Krishna Chatradhi (7): crypto:s5p-sss: Use platform_get_irq() instead of _byname() crypto:s5p-sss: Kconfig: Let Exynos SoCs select SSS driver crypto:s5p-sss: Look for the next request in the queue crypto:s5p-sss: Add device tree support crypto:s5p-sss: Add support for SSS module on Exynos crypto:s5p-sss: validate iv before memcpy crypto:s5p-sss: Use clk_prepare/clk_unprepare .../devicetree/bindings/crypto/samsung-sss.txt | 35 + drivers/crypto/Kconfig |6 +- drivers/crypto/s5p-sss.c | 145 +++- 3 files changed, 150 insertions(+), 36 deletions(-) create mode 100644 Documentation/devicetree/bindings/crypto/samsung-sss.txt Can we get this series merged in. Its has got reviewed and re-based several times and got acked by a couple of seniors. Do you want me to pick these series up? Cheers, thank you for this changeset, in my opinion it is quite good. To all changes Acked-by: Vladimir Zapolskiy v...@mleia.com -- With best wishes, Vladimir -- 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] net: sxgbe: Added rxqueue enable function
From: Byungho An bh74...@samsung.com Date: Tue, 29 Apr 2014 13:15:17 +0900 This patch adds rxqueue enable function according to number of rxqueue and adds rxqueue disable function for removing. Signed-off-by: Byungho An bh74...@samsung.com Applied. -- 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] net: sxgbe: sw reset moved to probe function
From: Byungho An bh74...@samsung.com Date: Tue, 29 Apr 2014 13:15:15 +0900 This patch moves sw reset to probe function because sw reset is needed early stage before open function. Signed-off-by: Byungho An bh74...@samsung.net Applied. -- 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] net: sxgbe: Added set function for interrupt on complete
From: Byungho An bh74...@samsung.com Date: Tue, 29 Apr 2014 13:15:27 +0900 This patch adds set_rx_int_on_com function for interrupt when dma is completed. Signed-off-by: Byungho An bh74...@samsung.com Applied. -- 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/5 v3] iio: exynos_adc: use indio_dev-dev structure to handle child nodes
On 30/04/14 10:26, Naveen Krishna Chatradhi wrote:
From: Naveen Krishna Ch ch.nav...@samsung.com
Using pdev-dev with device_for_each_child() would iterate over all
of the children of the platform device and delete them.
Thus, causing crashes during module unload.
We should be using the indio_dev-dev structure for
registering/unregistering child nodes.
Signed-off-by: Naveen Krishna Ch ch.nav...@samsung.com
Reported-by: Doug Anderson diand...@chromium.org
Reviewed-by: Doug Anderson diand...@chromium.org
Tested-by: Doug Anderson diand...@chromium.org
This one has been in my fixes-togreg branch for a few days and
a pull request has gone to Greg.
---
Changes since v2:
None
Changes since v1:
Adding Doug's tags
v0:
This change was tested on top of
https://lkml.org/lkml/2014/4/21/481 from Doug.
drivers/iio/adc/exynos_adc.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/iio/adc/exynos_adc.c b/drivers/iio/adc/exynos_adc.c
index d25b262..affa93f 100644
--- a/drivers/iio/adc/exynos_adc.c
+++ b/drivers/iio/adc/exynos_adc.c
@@ -344,7 +344,7 @@ static int exynos_adc_probe(struct platform_device *pdev)
exynos_adc_hw_init(info);
- ret = of_platform_populate(np, exynos_adc_match, NULL, pdev-dev);
+ ret = of_platform_populate(np, exynos_adc_match, NULL, indio_dev-dev);
if (ret 0) {
dev_err(pdev-dev, failed adding child nodes\n);
goto err_of_populate;
@@ -353,7 +353,7 @@ static int exynos_adc_probe(struct platform_device *pdev)
return 0;
err_of_populate:
- device_for_each_child(pdev-dev, NULL,
+ device_for_each_child(indio_dev-dev, NULL,
exynos_adc_remove_devices);
regulator_disable(info-vdd);
clk_disable_unprepare(info-clk);
@@ -369,7 +369,7 @@ static int exynos_adc_remove(struct platform_device *pdev)
struct iio_dev *indio_dev = platform_get_drvdata(pdev);
struct exynos_adc *info = iio_priv(indio_dev);
- device_for_each_child(pdev-dev, NULL,
+ device_for_each_child(indio_dev-dev, NULL,
exynos_adc_remove_devices);
regulator_disable(info-vdd);
clk_disable_unprepare(info-clk);
--
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/5 v3] iio: exynos_adc: rearrange clk and regulator enable/disable calls
On 30/04/14 10:26, Naveen Krishna Chatradhi wrote:
From: Naveen Krishna Ch ch.nav...@samsung.com
This patch maintains the following order in
probe(), remove(), resume() and suspend() calls
regulator enable, clk prepare enable
...
clk disable unprepare, regulator disable
While at it,
1. enable the regulator before the iio_device_register()
2. handle the return values for enable/disable calls
Signed-off-by: Naveen Krishna Ch ch.nav...@samsung.com
Reviewed-by: Doug Anderson diand...@chromium.org
Applied to the togreg branch of iio.git.
Thanks,
---
Changes since v2:
Remove extra unused line and add Doug's Reviewed-by
Changes since v1:
corrected the register/unregister and enabling/disbaling sequences
drivers/iio/adc/exynos_adc.c | 62 ++
1 file changed, 33 insertions(+), 29 deletions(-)
diff --git a/drivers/iio/adc/exynos_adc.c b/drivers/iio/adc/exynos_adc.c
index affa93f..ff98c5d 100644
--- a/drivers/iio/adc/exynos_adc.c
+++ b/drivers/iio/adc/exynos_adc.c
@@ -290,32 +290,30 @@ static int exynos_adc_probe(struct platform_device *pdev)
init_completion(info-completion);
- ret = request_irq(info-irq, exynos_adc_isr,
- 0, dev_name(pdev-dev), info);
- if (ret 0) {
- dev_err(pdev-dev, failed requesting irq, irq = %d\n,
- info-irq);
- return ret;
- }
-
- writel(1, info-enable_reg);
-
info-clk = devm_clk_get(pdev-dev, adc);
if (IS_ERR(info-clk)) {
dev_err(pdev-dev, failed getting clock, err = %ld\n,
PTR_ERR(info-clk));
- ret = PTR_ERR(info-clk);
- goto err_irq;
+ return PTR_ERR(info-clk);
}
info-vdd = devm_regulator_get(pdev-dev, vdd);
if (IS_ERR(info-vdd)) {
dev_err(pdev-dev, failed getting regulator, err = %ld\n,
PTR_ERR(info-vdd));
- ret = PTR_ERR(info-vdd);
- goto err_irq;
+ return PTR_ERR(info-vdd);
}
+ ret = regulator_enable(info-vdd);
+ if (ret)
+ return ret;
+
+ ret = clk_prepare_enable(info-clk);
+ if (ret)
+ goto err_disable_reg;
+
+ writel(1, info-enable_reg);
+
info-version = exynos_adc_get_version(pdev);
platform_set_drvdata(pdev, indio_dev);
@@ -332,16 +330,18 @@ static int exynos_adc_probe(struct platform_device *pdev)
else
indio_dev-num_channels = MAX_ADC_V2_CHANNELS;
+ ret = request_irq(info-irq, exynos_adc_isr,
+ 0, dev_name(pdev-dev), info);
+ if (ret 0) {
+ dev_err(pdev-dev, failed requesting irq, irq = %d\n,
+ info-irq);
+ goto err_disable_clk;
+ }
+
ret = iio_device_register(indio_dev);
if (ret)
goto err_irq;
- ret = regulator_enable(info-vdd);
- if (ret)
- goto err_iio_dev;
-
- clk_prepare_enable(info-clk);
-
exynos_adc_hw_init(info);
ret = of_platform_populate(np, exynos_adc_match, NULL, indio_dev-dev);
@@ -355,12 +355,14 @@ static int exynos_adc_probe(struct platform_device *pdev)
err_of_populate:
device_for_each_child(indio_dev-dev, NULL,
exynos_adc_remove_devices);
- regulator_disable(info-vdd);
- clk_disable_unprepare(info-clk);
-err_iio_dev:
iio_device_unregister(indio_dev);
err_irq:
free_irq(info-irq, info);
+err_disable_clk:
+ writel(0, info-enable_reg);
+ clk_disable_unprepare(info-clk);
+err_disable_reg:
+ regulator_disable(info-vdd);
return ret;
}
@@ -371,11 +373,11 @@ static int exynos_adc_remove(struct platform_device *pdev)
device_for_each_child(indio_dev-dev, NULL,
exynos_adc_remove_devices);
- regulator_disable(info-vdd);
- clk_disable_unprepare(info-clk);
- writel(0, info-enable_reg);
iio_device_unregister(indio_dev);
free_irq(info-irq, info);
+ writel(0, info-enable_reg);
+ clk_disable_unprepare(info-clk);
+ regulator_disable(info-vdd);
return 0;
}
@@ -397,8 +399,8 @@ static int exynos_adc_suspend(struct device *dev)
writel(con, ADC_V1_CON(info-regs));
}
- clk_disable_unprepare(info-clk);
writel(0, info-enable_reg);
+ clk_disable_unprepare(info-clk);
regulator_disable(info-vdd);
return 0;
@@ -414,9 +416,11 @@ static int exynos_adc_resume(struct device *dev)
if (ret)
return ret;
- writel(1, info-enable_reg);
- clk_prepare_enable(info-clk);
+ ret = clk_prepare_enable(info-clk);
+
Re: [PATCH 3/5 v3] iio: exynos_adc: reduce timeout and use wait_for_completion_timeout
On 30/04/14 10:26, Naveen Krishna Chatradhi wrote:
ADC module on Exynos5 SoCs runs at 600KSPS. At this conversion rate,
waiting for 1000 msecs is wasteful (incase of h/w failure).
Hence, reduce the time out to 100msecs and use
wait_for_completion_timeout() instead of
wait_for_completion_interruptible_timeout()
Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
Reviewed-by: Doug Anderson diand...@chromium.org
Applied to the togreg branch of iio.git
Thanks
---
Changes since v2:
None
Changes since v1:
None
v0:
This change is a part of the patch reviewd at https://lkml.org/lkml/2013/11/5/92
drivers/iio/adc/exynos_adc.c | 18 +++---
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/drivers/iio/adc/exynos_adc.c b/drivers/iio/adc/exynos_adc.c
index ff98c5d..939aaf7 100644
--- a/drivers/iio/adc/exynos_adc.c
+++ b/drivers/iio/adc/exynos_adc.c
@@ -82,7 +82,7 @@ enum adc_version {
#define ADC_CON_EN_START (1u 0)
#define ADC_DATX_MASK 0xFFF
-#define EXYNOS_ADC_TIMEOUT (msecs_to_jiffies(1000))
+#define EXYNOS_ADC_TIMEOUT (msecs_to_jiffies(100))
struct exynos_adc {
void __iomem*regs;
@@ -121,6 +121,7 @@ static int exynos_read_raw(struct iio_dev *indio_dev,
struct exynos_adc *info = iio_priv(indio_dev);
unsigned long timeout;
u32 con1, con2;
+ int ret;
if (mask != IIO_CHAN_INFO_RAW)
return -EINVAL;
@@ -145,16 +146,19 @@ static int exynos_read_raw(struct iio_dev *indio_dev,
ADC_V1_CON(info-regs));
}
- timeout = wait_for_completion_interruptible_timeout
+ timeout = wait_for_completion_timeout
(info-completion, EXYNOS_ADC_TIMEOUT);
- *val = info-value;
+ if (timeout == 0) {
+ ret = -ETIMEDOUT;
+ } else {
+ *val = info-value;
+ *val2 = 0;
+ ret = IIO_VAL_INT;
+ }
mutex_unlock(indio_dev-mlock);
- if (timeout == 0)
- return -ETIMEDOUT;
-
- return IIO_VAL_INT;
+ return ret;
}
static irqreturn_t exynos_adc_isr(int irq, void *dev_id)
--
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 4/5 v3] iio: exynos_adc: do a soft reset in case of timeout
On 30/04/14 10:26, Naveen Krishna Chatradhi wrote:
Do a soft reset software if a timeout happens.
This is applicable only for ADC_V2.
Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
Reviewed-by: Doug Anderson diand...@chromium.org
Applied to the togreg branch of iio.git
Thanks,
---
Changes since v2:
None
Changes since v1:
None
v0:
This change is a part of the patch reviewed at
https://lkml.org/lkml/2013/11/5/92
drivers/iio/adc/exynos_adc.c | 50 ++
1 file changed, 26 insertions(+), 24 deletions(-)
diff --git a/drivers/iio/adc/exynos_adc.c b/drivers/iio/adc/exynos_adc.c
index 939aaf7..eddc58e 100644
--- a/drivers/iio/adc/exynos_adc.c
+++ b/drivers/iio/adc/exynos_adc.c
@@ -112,6 +112,30 @@ static inline unsigned int exynos_adc_get_version(struct
platform_device *pdev)
return (unsigned int)match-data;
}
+static void exynos_adc_hw_init(struct exynos_adc *info)
+{
+ u32 con1, con2;
+
+ if (info-version == ADC_V2) {
+ con1 = ADC_V2_CON1_SOFT_RESET;
+ writel(con1, ADC_V2_CON1(info-regs));
+
+ con2 = ADC_V2_CON2_OSEL | ADC_V2_CON2_ESEL |
+ ADC_V2_CON2_HIGHF | ADC_V2_CON2_C_TIME(0);
+ writel(con2, ADC_V2_CON2(info-regs));
+
+ /* Enable interrupts */
+ writel(1, ADC_V2_INT_EN(info-regs));
+ } else {
+ /* set default prescaler values and Enable prescaler */
+ con1 = ADC_V1_CON_PRSCLV(49) | ADC_V1_CON_PRSCEN;
+
+ /* Enable 12-bit ADC resolution */
+ con1 |= ADC_V1_CON_RES;
+ writel(con1, ADC_V1_CON(info-regs));
+ }
+}
+
static int exynos_read_raw(struct iio_dev *indio_dev,
struct iio_chan_spec const *chan,
int *val,
@@ -149,6 +173,8 @@ static int exynos_read_raw(struct iio_dev *indio_dev,
timeout = wait_for_completion_timeout
(info-completion, EXYNOS_ADC_TIMEOUT);
if (timeout == 0) {
+ dev_warn(indio_dev-dev, Conversion timed out! Resetting\n);
+ exynos_adc_hw_init(info);
ret = -ETIMEDOUT;
} else {
*val = info-value;
@@ -230,30 +256,6 @@ static int exynos_adc_remove_devices(struct device *dev,
void *c)
return 0;
}
-static void exynos_adc_hw_init(struct exynos_adc *info)
-{
- u32 con1, con2;
-
- if (info-version == ADC_V2) {
- con1 = ADC_V2_CON1_SOFT_RESET;
- writel(con1, ADC_V2_CON1(info-regs));
-
- con2 = ADC_V2_CON2_OSEL | ADC_V2_CON2_ESEL |
- ADC_V2_CON2_HIGHF | ADC_V2_CON2_C_TIME(0);
- writel(con2, ADC_V2_CON2(info-regs));
-
- /* Enable interrupts */
- writel(1, ADC_V2_INT_EN(info-regs));
- } else {
- /* set default prescaler values and Enable prescaler */
- con1 = ADC_V1_CON_PRSCLV(49) | ADC_V1_CON_PRSCEN;
-
- /* Enable 12-bit ADC resolution */
- con1 |= ADC_V1_CON_RES;
- writel(con1, ADC_V1_CON(info-regs));
- }
-}
-
static int exynos_adc_probe(struct platform_device *pdev)
{
struct exynos_adc *info = NULL;
--
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/5 v3] iio: exynos_adc: do a reinit_completion before the conversion
On 30/04/14 10:26, Naveen Krishna Chatradhi wrote:
Add reinit_completion() before the wait_for_completion_timeout in
raw_read() call.
Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
Reviewed-by: Doug Anderson diand...@chromium.org
Applied to the togreg branch of iio.git
I wasn't sure if this one was technically a fix, but as it isn't
marked clearly as such it can go in during the next merge window.
I won't have pushed this out to a non rebasing branch until tomorrow
so if this fixes an observed issue then let me know and it might move
to the fixes-togreg branch.
Thanks,
Jonathan
---
Changes since v2:
None
Changes since v1:
None
v0:
This change is a part of the patch reviewed at
https://lkml.org/lkml/2013/11/5/92
drivers/iio/adc/exynos_adc.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/iio/adc/exynos_adc.c b/drivers/iio/adc/exynos_adc.c
index eddc58e..010578f 100644
--- a/drivers/iio/adc/exynos_adc.c
+++ b/drivers/iio/adc/exynos_adc.c
@@ -151,6 +151,7 @@ static int exynos_read_raw(struct iio_dev *indio_dev,
return -EINVAL;
mutex_lock(indio_dev-mlock);
+ reinit_completion(info-completion);
/* Select the channel to be used and Trigger conversion */
if (info-version == ADC_V2) {
--
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 0/4] drivers/base: Generic framework for tracking internal interfaces
Hi Greg, Thanks for comments. I CC Laurent, I hope it could be interesting for him also. Greg Kroah-Hartman wrote, On 30.04.2014 17:49: On Wed, Apr 30, 2014 at 04:02:50PM +0200, Andrzej Hajda wrote: Generic framework for tracking internal interfaces == Summary --- interface_tracker is a generic framework which allows to track appearance and disappearance of different interfaces provided by kernel/driver code inside the kernel. Examples of such interfaces: clocks, phys, regulators, drm_panel... Interface is specified by a pair of object pointer and interface type. Object type depends on interface type, for example interface type drm_panel determines that object is a device_node. Object pointer is used to distinguish different interfaces of the same type and should identify object the interface is bound to. For example it could be DT node, struct device,... The framework provides two functions for interface providers which should be called just after interface becomes available or just before interface removal. Interface consumers can register callback which will be called when requested interface changes its state, if during callback registration the interface is already up, notification will be sent also. The framework allows nesting calls, for example it is possible to signal one interface in tracker callback of another interface. It is done by putting every request into the queue. If the queue is empty before adding the request, the queue will be processed after, if there is already another request in the queue it means the queue is already processed by different thread so no additional action is required. With this pattern only spinlock is necessary to protect the queue. However in case of removal of either callback or interface caller should be sure that his request has been processed so framework waits until the queue becomes empty, it is done using completion mechanism. The framework functions should not be called in atomic context. Callbacks should be aware that they can be called in any time between registration and de-registration, so they should use synchronization mechanisms carefully. Callbacks should also avoid to perform time consuming tasks, the framework serializes them, so it could stall other callbacks. Use cases - The interface is very generic, there are many situations it can be useful: 1. Replacement for subsystem specific methods of publishing/unpublishing interfaces. Currently many frameworks allows only querying for presence of given interface. In such cases client can defer probing or implement interface polling, which is usually subobtimal. Additionally subsystems often do not provide methods to signal to the consumers that they are about to be destroyed. 2. Monitoring for different interfaces provided by the same object. An example should explain it better. Lets assume in device tree drm crtc device node have video link to another node, so it knows only that there is something connected to its RGB output. It can be a RGB panel (drm_panel framework), it can be an image enhancer (SoC specific framework) or it can be some signal converter (drm_encoder, drm_bridge, drm_encoder_slave...). Driver have only phandle to another node. Currently it is difficult to handle such situations in a generic way. interface_tracker should make it simple: crtc should monitor all supported interface types that appears at the device_node pointed by the phandle. Potential use cases --- Points mentioned above were the reasons for writing this framework. During development I have realized that this framework can be also useful for other tasks. 3. Replacement for deferred probing - if for some reason driver do not wants to defer but it requires given resources it can use interface_tracker. It should be possible to create an helper which will wait for appearance of all interfaces from a given list, and 'continue' probe only when all resources becomes available. 4. Replacement or helper for subsystem specific solutions: - V4L2 subdev async registration, - component framework. Both frameworks solves a problem of tracking sub-components (un-)registration by master device, it should be possible to do the same with interface_tracker framework. Some additional helpers can be convienent to make the implementation easier. 5. Cure the situation with sysfs 'unbind' property. Currently many drivers are providers of different resources/interfaces: regulators, clocks, phys, V4L2 subdevs, ... They are usually protected from module unloading by getting module reference, but there is no protection from driver unbinding using sysfs method: echo 'device' /sys/bus/.../drivers/.../unbind. After unbind consumer stays with the pointer to non-existing object, next time it tries to use it system usually crashes. interface_tracker do not add any protection, but it adds a way to signal to the consumer that given resource will disappear.
Re: [PATCH 1/4] clk: propagate parent change up one level
Mike,
On 08.04.2014 17:45, Tomasz Figa wrote:
Hi,
On 04.04.2014 16:53, Tomasz Stanislawski wrote:
This patch adds support for propagation of setup of clock's parent one
level
up.
This feature is helpful when a driver changes topology of its clocks
using
clk_set_parent(). The problem occurs when on one platform/SoC
driver's clock
is located at MUX output but on the other platform/SoC there is a
gated proxy
clock between the MUX and driver's clock. In such a case, driver's
code has to
be modified to use one clock for enabling and the other clock for
setup of a
parent.
The code updates are avoided by propagating setup of a parent up one
level.
Additionally, this patch adds CLK_SET_PARENT_PARENT (sorry for naming)
flag to
inform clk-core that clk_set_parent() should be propagated.
Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
---
drivers/clk/clk.c|6 ++
include/linux/clk-provider.h |1 +
2 files changed, 7 insertions(+)
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index dff0373..53bbfda 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -1737,6 +1737,12 @@ int clk_set_parent(struct clk *clk, struct clk
*parent)
/* try finding the new parent index */
if (parent) {
+if ((clk-flags CLK_SET_PARENT_PARENT)
+ clk-num_parents == 1) {
+ret = clk_set_parent(clk-parent, parent);
+goto out;
+}
+
p_index = clk_fetch_parent_index(clk, parent);
p_rate = parent-rate;
if (p_index 0) {
diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
index 5119174..daa0b03 100644
--- a/include/linux/clk-provider.h
+++ b/include/linux/clk-provider.h
@@ -30,6 +30,7 @@
#define CLK_GET_RATE_NOCACHEBIT(6) /* do not use the cached clk
rate */
#define CLK_SET_RATE_NO_REPARENT BIT(7) /* don't re-parent on rate
change */
#define CLK_GET_ACCURACY_NOCACHE BIT(8) /* do not use the cached clk
accuracy */
+#define CLK_SET_PARENT_PARENTBIT(9) /* propagate parent change up
one level */
struct clk_hw;
struct dentry;
This would be very useful, at least on Exynos platforms, with
mux-div-gate clock paths. PARENT_PARENT sounds a bit funny, though.
Reviewed-by: Tomasz Figa t.f...@samsung.com
Your opinion on this would be greatly appreciated.
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: [RFC PATCH 0/4] drivers/base: Generic framework for tracking internal interfaces
On Wed, Apr 30, 2014 at 11:42:09PM +0200, Andrzej Hajda wrote: The main problem with component framework is that componentization significantly changes every driver and changes it in a way which is not compatible with traditional drivers, so devices which are intended to work with different DRM masters are hard to componentize if some of DRMs are componentized and some not. Many of the problems which the component helpers are designed to solve are those where you need the drm_device structure (or snd_card, or whatever subsystem specific card/device representation structure) pre-created in order to initialise the components. In the case of DRM, you can't initialise encoders or connectors without their drm_device structure pre-existing - because these components are attached to the drm_device. Your solution to that is to delay those calls, but the DRM subsystem is not designed to cope like that - it's designed such that when the connector or encoder initialisation functions are called, it is assumed that the driver is initialising its state. (I've raised this point before but you've just fobbed it off in the past.) Another issue here is that the order of initialisation matters greatly. Take CRTCs for example. In DRM, the order of attachment of CRTCs defines their identity, changing the order changes their identity, and changes how they are bound to their respective connectors. -- FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly improving, and getting towards what was expected from it. -- 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] clk: exynos4: Use single clock ID for CLK_MDMA gate clocks
On 15.04.2014 18:30, Sylwester Nawrocki wrote:
Exynos4210 and Exynos4x12 SoCs have the PL330 MDMA IP block clock
defined exactly in same way in documentation. Using different
names for these clocks is a bit misleading. Since there is no users
of CLK_MDMA2 in existing dts files this patch drops CLK_MDMA2 and
replaces it with CLK_MDMA in the driver. This ensures PL330 MDMA
has correct clock assigned on Exynos4x12 SoCs.
Suggested-by: Tomasz Figa t.f...@samsung.com
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/clk/samsung/clk-exynos4.c |2 +-
include/dt-bindings/clock/exynos4.h |1 -
2 files changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/clk/samsung/clk-exynos4.c
b/drivers/clk/samsung/clk-exynos4.c
index b4f9672..5247caa 100644
--- a/drivers/clk/samsung/clk-exynos4.c
+++ b/drivers/clk/samsung/clk-exynos4.c
@@ -903,7 +903,7 @@ static struct samsung_gate_clock exynos4x12_gate_clks[]
__initdata = {
GATE(CLK_AUDSS, audss, sclk_epll, E4X12_GATE_IP_MAUDIO, 0, 0, 0),
GATE(CLK_MDNIE0, mdnie0, aclk160, GATE_IP_LCD0, 2, 0, 0),
GATE(CLK_ROTATOR, rotator, aclk200, E4X12_GATE_IP_IMAGE, 1, 0, 0),
- GATE(CLK_MDMA2, mdma2, aclk200, E4X12_GATE_IP_IMAGE, 2, 0, 0),
+ GATE(CLK_MDMA, mdma, aclk200, E4X12_GATE_IP_IMAGE, 2, 0, 0),
GATE(CLK_SMMU_MDMA, smmu_mdma, aclk200, E4X12_GATE_IP_IMAGE, 5, 0,
0),
GATE(CLK_MIPI_HSI, mipi_hsi, aclk133, GATE_IP_FSYS, 10, 0, 0),
diff --git a/include/dt-bindings/clock/exynos4.h
b/include/dt-bindings/clock/exynos4.h
index 75aff33..3ff13bc 100644
--- a/include/dt-bindings/clock/exynos4.h
+++ b/include/dt-bindings/clock/exynos4.h
@@ -181,7 +181,6 @@
#define CLK_KEYIF 347
#define CLK_AUDSS 348
#define CLK_MIPI_HSI 349 /* Exynos4210 only */
-#define CLK_MDMA2 350 /* Exynos4210 only */
#define CLK_PIXELASYNCM0 351
#define CLK_PIXELASYNCM1 352
#define CLK_FIMC_LITE0353 /* Exynos4x12 only */
Applied.
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 v6] clk: Exynos5250: Add clocks for G3D
On 28.04.2014 11:37, Arun Kumar K wrote:
This patch adds the required clocks for ARM Mali IP
in Exynos5250.
Signed-off-by: Arun Kumar K arun...@samsung.com
---
Changes from v5
- Addressed comments from Tomasz Figa
http://www.spinics.net/lists/arm-kernel/msg326118.html
Changes from v4
- Rebased on latest kernel
- Added macros
Changes from v3
- Renamed some clocks as per Tomasz Figa's comments
Changes from v2
- Rebased on clk-next
Changes from v1
- Removed exporting of parent DIV clock for g3d
as per Tomsz Figa's comment.
---
drivers/clk/samsung/clk-exynos5250.c | 15 ++-
include/dt-bindings/clock/exynos5250.h |4 +++-
2 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/samsung/clk-exynos5250.c
b/drivers/clk/samsung/clk-exynos5250.c
index e7ee442..df02526 100644
--- a/drivers/clk/samsung/clk-exynos5250.c
+++ b/drivers/clk/samsung/clk-exynos5250.c
@@ -37,6 +37,7 @@
#define VPLL_CON0 0x10140
#define GPLL_CON0 0x10150
#define SRC_TOP0 0x10210
+#define SRC_TOP1 0x10214
#define SRC_TOP2 0x10218
#define SRC_TOP3 0x1021c
#define SRC_GSCL 0x10220
@@ -71,6 +72,7 @@
#define GATE_IP_GSCL 0x10920
#define GATE_IP_DISP1 0x10928
#define GATE_IP_MFC 0x1092c
+#define GATE_IP_G3D0x10930
#define GATE_IP_GEN 0x10934
#define GATE_IP_FSYS 0x10944
#define GATE_IP_PERIC 0x10950
@@ -100,6 +102,7 @@ static unsigned long exynos5250_clk_regs[] __initdata = {
DIV_CPU0,
SRC_CORE1,
SRC_TOP0,
+ SRC_TOP1,
SRC_TOP2,
SRC_TOP3,
SRC_GSCL,
@@ -133,6 +136,7 @@ static unsigned long exynos5250_clk_regs[] __initdata = {
DIV_PERIC5,
GATE_IP_GSCL,
GATE_IP_MFC,
+ GATE_IP_G3D,
GATE_IP_GEN,
GATE_IP_FSYS,
GATE_IP_PERIC,
@@ -189,10 +193,12 @@ PNAME(mout_vpllsrc_p) = { fin_pll, sclk_hdmi27m };
PNAME(mout_vpll_p)= { mout_vpllsrc, fout_vpll };
PNAME(mout_cpll_p)= { fin_pll, fout_cpll };
PNAME(mout_epll_p)= { fin_pll, fout_epll };
+PNAME(mout_gpll_p) = { fin_pll, fout_gpll };
PNAME(mout_mpll_user_p) = { fin_pll, mout_mpll };
PNAME(mout_bpll_user_p) = { fin_pll, mout_bpll };
PNAME(mout_aclk166_p) = { mout_cpll, mout_mpll_user };
PNAME(mout_aclk200_p) = { mout_mpll_user, mout_bpll_user };
+PNAME(mout_aclk400_p) = { mout_aclk400_g3d_mid, mout_gpll };
PNAME(mout_aclk200_sub_p) = { fin_pll, div_aclk200 };
PNAME(mout_aclk266_sub_p) = { fin_pll, div_aclk266 };
PNAME(mout_aclk333_sub_p) = { fin_pll, div_aclk333 };
@@ -273,12 +279,16 @@ static struct samsung_mux_clock exynos5250_mux_clks[]
__initdata = {
MUX(0, mout_aclk166, mout_aclk166_p, SRC_TOP0, 8, 1),
MUX(0, mout_aclk200, mout_aclk200_p, SRC_TOP0, 12, 1),
MUX(0, mout_aclk333, mout_aclk166_p, SRC_TOP0, 16, 1),
+ MUX(0, mout_aclk400_g3d_mid, mout_aclk200_p, SRC_TOP0, 20, 1),
+
+ MUX(0, mout_aclk400_g3d, mout_aclk400_p, SRC_TOP1, 28, 1),
MUX(0, mout_cpll, mout_cpll_p, SRC_TOP2, 8, 1),
MUX(0, mout_epll, mout_epll_p, SRC_TOP2, 12, 1),
MUX(0, mout_vpll, mout_vpll_p, SRC_TOP2, 16, 1),
MUX(0, mout_mpll_user, mout_mpll_user_p, SRC_TOP2, 20, 1),
MUX(0, mout_bpll_user, mout_bpll_user_p, SRC_TOP2, 24, 1),
+ MUX(CLK_MOUT_GPLL, mout_gpll, mout_gpll_p, SRC_TOP2, 28, 1),
MUX(0, mout_aclk200_disp1_sub, mout_aclk200_sub_p, SRC_TOP3, 4, 1),
MUX(0, mout_aclk266_gscl_sub, mout_aclk266_sub_p, SRC_TOP3, 8, 1),
@@ -351,6 +361,8 @@ static struct samsung_div_clock exynos5250_div_clks[]
__initdata = {
DIV(0, div_aclk200, mout_aclk200, DIV_TOP0, 12, 3),
DIV(0, div_aclk266, mout_mpll_user, DIV_TOP0, 16, 3),
DIV(0, div_aclk333, mout_aclk333, DIV_TOP0, 20, 3),
+ DIV(0, div_aclk400_g3d, mout_aclk400_g3d, DIV_TOP0,
+ 24, 3),
DIV(0, div_aclk66_pre, mout_mpll_user, DIV_TOP1, 24, 3),
@@ -533,7 +545,8 @@ static struct samsung_gate_clock exynos5250_gate_clks[]
__initdata = {
0),
GATE(CLK_SMMU_MFCL, smmu_mfcl, mout_aclk333_sub, GATE_IP_MFC, 2, 0,
0),
-
+ GATE(CLK_G3D, g3d, div_aclk400_g3d, GATE_IP_G3D, 0,
+ CLK_SET_RATE_PARENT, 0),
GATE(CLK_ROTATOR, rotator, div_aclk266, GATE_IP_GEN, 1, 0, 0),
GATE(CLK_JPEG, jpeg, div_aclk166, GATE_IP_GEN, 2, 0, 0),
GATE(CLK_MDMA1, mdma1, div_aclk266, GATE_IP_GEN, 4, 0, 0),
diff --git a/include/dt-bindings/clock/exynos5250.h
b/include/dt-bindings/clock/exynos5250.h
index 922f2dc..a3c6777 100644
--- a/include/dt-bindings/clock/exynos5250.h
+++ b/include/dt-bindings/clock/exynos5250.h
@@ -150,11 +150,13 @@
#define CLK_G2D 345
#define CLK_MDMA0 346
#define CLK_SMMU_MDMA0347
Re: [PATCH 2/4] clk: exynos4: export sclk_hdmiphy clock
On 04.04.2014 16:53, Tomasz Stanislawski wrote:
Export sclk_hdmiphy clock to be usable from DT.
Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
---
drivers/clk/samsung/clk-exynos4.c |2 +-
include/dt-bindings/clock/exynos4.h |1 +
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/samsung/clk-exynos4.c
b/drivers/clk/samsung/clk-exynos4.c
index b4f9672..528f8eb 100644
--- a/drivers/clk/samsung/clk-exynos4.c
+++ b/drivers/clk/samsung/clk-exynos4.c
@@ -428,7 +428,7 @@ static struct samsung_fixed_rate_clock
exynos4_fixed_rate_ext_clks[] __initdata
/* fixed rate clocks generated inside the soc */
static struct samsung_fixed_rate_clock exynos4_fixed_rate_clks[] __initdata =
{
FRATE(0, sclk_hdmi24m, NULL, CLK_IS_ROOT, 2400),
- FRATE(0, sclk_hdmiphy, NULL, CLK_IS_ROOT, 2700),
+ FRATE(CLK_SCLK_HDMIPHY, sclk_hdmiphy, NULL, CLK_IS_ROOT, 2700),
FRATE(0, sclk_usbphy0, NULL, CLK_IS_ROOT, 4800),
};
diff --git a/include/dt-bindings/clock/exynos4.h
b/include/dt-bindings/clock/exynos4.h
index 75aff33..0e245eb 100644
--- a/include/dt-bindings/clock/exynos4.h
+++ b/include/dt-bindings/clock/exynos4.h
@@ -33,6 +33,7 @@
#define CLK_MOUT_MPLL_USER_C 18 /* Exynos4x12 only */
#define CLK_MOUT_CORE 19
#define CLK_MOUT_APLL 20
+#define CLK_SCLK_HDMIPHY 22
/* gate for special clocks (sclk) */
#define CLK_SCLK_FIMC0128
Applied.
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/5 v3] iio: exynos_adc: do a reinit_completion before the conversion
Jonathan, On Wed, Apr 30, 2014 at 1:49 PM, Jonathan Cameron ji...@kernel.org wrote: On 30/04/14 10:26, Naveen Krishna Chatradhi wrote: Add reinit_completion() before the wait_for_completion_timeout in raw_read() call. Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com Reviewed-by: Doug Anderson diand...@chromium.org Applied to the togreg branch of iio.git I wasn't sure if this one was technically a fix, but as it isn't marked clearly as such it can go in during the next merge window. I won't have pushed this out to a non rebasing branch until tomorrow so if this fixes an observed issue then let me know and it might move to the fixes-togreg branch. As far as I know this doesn't fix an observed issue. I believe it was requested as part of a previous review and is finally reposted. I believe it's just extra precautions to make sure that some old IRQ didn't accidentally complete us between the last transaction and this one. Old discussion is somewhere around here https://patchwork.kernel.org/patch/2279591/ Thanks! -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 v4 4/7] arm64: Add a description on 48-bit address space with 4KB pages
On Wednesday, April 30, 2014 10:12 PM, Catalin Marinas wrote: On Wed, Apr 30, 2014 at 07:41:40AM +0100, Jungseok Lee wrote: On Tuesday, April 29, 2014 11:48 PM, Catalin Marinas wrote: On Tue, Apr 29, 2014 at 05:59:27AM +0100, Jungseok Lee wrote: --- a/Documentation/arm64/memory.txt +++ b/Documentation/arm64/memory.txt @@ -8,10 +8,11 @@ This document describes the virtual memory layout used by the AArch64 Linux kernel. The architecture allows up to 4 levels of translation tables with a 4KB page size and up to 3 levels with a 64KB page size. -AArch64 Linux uses 3 levels of translation tables with the 4KB page -configuration, allowing 39-bit (512GB) virtual addresses for both user -and kernel. With 64KB pages, only 2 levels of translation tables are -used but the memory layout is the same. +AArch64 Linux uses 3 levels and 4 levels of translation tables +with the 4KB page configuration, allowing 39-bit (512GB) and +48-bit +(256TB) virtual addresses, respectively, for both user and kernel. +With 64KB pages, only 2 levels of translation tables are used but +the memory layout is the same. Any reason why we couldn't use 48-bit address space with 64K pages (implying 3 levels)? No technical reason. Since 64K+3levels is not implemented in this set, I didn't add it. Should 64K+3levels be prepared in this patchset? -AArch64 Linux memory layout with 64KB pages: +AArch64 Linux memory layout with 4KB pages + 4 levels: + +Start End SizeUse +--- + 256TB user + + 7bfe~124TB vmalloc BTW, maybe as a separate patch we should change the end to be exclusive. It becomes harder to modify (I've been through this a few times already ;)) and even follow the changes. Does exclusive mean that is changed to 0001? Or Does it mean that End column is dropped? Not dropped but changed to 0001 (the kernel already prints the memory layout in a similar way). I see. I will make it as a separate patch. Best Regards Jungseok Lee -- 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/15] ASoC: CS42L51 and WM8962 codecs depend on INPUT
On Tue, Apr 29, 2014 at 07:18:22PM +0800, Xia Kaixu wrote: From: Arnd Bergmann a...@arndb.de Building ARM randconfig got into a situation where CONFIG_INPUT is turned off and SND_SOC_ALL_CODECS is turned on, which failed for two codecs trying to use the input subsystem. Some other Applied, but... Cc: Mark Brown broo...@kernel.org Cc: Liam Girdwood l...@slimlogic.co.uk Cc: Ben Dooks ben-li...@fluff.org Cc: Kukjin Kim kgene@samsung.com Cc: Sangbeom Kim sbki...@samsung.com Cc: Lars-Peter Clausen l...@metafoo.de Cc: Timur Tabi ti...@tabi.org Cc: linux-arm-ker...@lists.infradead.org Cc: linux-samsung-soc@vger.kernel.org Cc: linux-in...@vger.kernel.org Cc: alsa-de...@alsa-project.org ...please don't include noise like this in patch submissions, especially with such long lists (which still manage to miss the driver maintainers concerned). signature.asc Description: Digital signature
Re: [alsa-devel] [PATCH 01/15] ASoC: CS42L51 and WM8962 codecs depend on INPUT
On Tue, Apr 29, 2014 at 09:31:30PM -0500, Brian Austin wrote: I assume you mean the CS42L52 instead of the L51. INPUT is used for a BEEP Generator but when I disable CONFIG_INPUT I do not get an error. Is there any information available on what the error is? I suspect it's ASoC built in and INPUT build as a module. signature.asc Description: Digital signature
Re: [alsa-devel] [PATCH 01/15] ASoC: CS42L51 and WM8962 codecs depend on INPUT
On Apr 30, 2014, at 20:31, Mark Brown broo...@kernel.org wrote: On Tue, Apr 29, 2014 at 09:31:30PM -0500, Brian Austin wrote: I assume you mean the CS42L52 instead of the L51. INPUT is used for a BEEP Generator but when I disable CONFIG_INPUT I do not get an error. Is there any information available on what the error is? I suspect it's ASoC built in and INPUT build as a module. Ok, I'll try that next. Doesn't IS_ENABLED cover that? -- 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: [alsa-devel] [PATCH 01/15] ASoC: CS42L51 and WM8962 codecs depend on INPUT
On Apr 30, 2014, at 8:54 PM, Austin, Brian brian.aus...@cirrus.com wrote: On Apr 30, 2014, at 20:31, Mark Brown broo...@kernel.org wrote: On Tue, Apr 29, 2014 at 09:31:30PM -0500, Brian Austin wrote: I assume you mean the CS42L52 instead of the L51. INPUT is used for a BEEP Generator but when I disable CONFIG_INPUT I do not get an error. Is there any information available on what the error is? I suspect it's ASoC built in and INPUT build as a module. Ok, I'll try that next. Doesn't IS_ENABLED cover that? Apparently not. I would like to come up with a better solution than making INPUT a requirement. I just need some time. In the meantime I suppose it’s OK to apply it? signature.asc Description: Message signed with OpenPGP using GPGMail
[PATCH v5 1/6] arm64: Use pr_* instead of printk
This patch fixed the following checkpatch complaint as using pr_*
instead of printk.
WARNING: printk() should include KERN_ facility level
Cc: Catalin Marinas catalin.mari...@arm.com
Signed-off-by: Jungseok Lee jays@samsung.com
Reviewed-by: Sungjinn Chung sungjinn.ch...@samsung.com
---
arch/arm64/kernel/traps.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
index 7ffaddd..268ce96 100644
--- a/arch/arm64/kernel/traps.c
+++ b/arch/arm64/kernel/traps.c
@@ -156,7 +156,7 @@ static void dump_backtrace(struct pt_regs *regs, struct
task_struct *tsk)
frame.pc = thread_saved_pc(tsk);
}
- printk(Call trace:\n);
+ pr_emerg(Call trace:\n);
while (1) {
unsigned long where = frame.pc;
int ret;
@@ -328,17 +328,17 @@ asmlinkage void bad_mode(struct pt_regs *regs, int
reason, unsigned int esr)
void __pte_error(const char *file, int line, unsigned long val)
{
- printk(%s:%d: bad pte %016lx.\n, file, line, val);
+ pr_crit(%s:%d: bad pte %016lx.\n, file, line, val);
}
void __pmd_error(const char *file, int line, unsigned long val)
{
- printk(%s:%d: bad pmd %016lx.\n, file, line, val);
+ pr_crit(%s:%d: bad pmd %016lx.\n, file, line, val);
}
void __pgd_error(const char *file, int line, unsigned long val)
{
- printk(%s:%d: bad pgd %016lx.\n, file, line, val);
+ pr_crit(%s:%d: bad pgd %016lx.\n, file, line, val);
}
void __init trap_init(void)
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 3/6] arm64: Add a description on 48-bit address space with 4KB pages
This patch adds memory layout and translation lookup information about 48-bit address space with 4K pages. The description is based on 4 levels of translation tables. Cc: Catalin Marinas catalin.mari...@arm.com Cc: Steve Capper steve.cap...@linaro.org Signed-off-by: Jungseok Lee jays@samsung.com Reviewed-by: Sungjinn Chung sungjinn.ch...@samsung.com --- Documentation/arm64/memory.txt | 59 ++-- 1 file changed, 51 insertions(+), 8 deletions(-) diff --git a/Documentation/arm64/memory.txt b/Documentation/arm64/memory.txt index d50fa61..8142709 100644 --- a/Documentation/arm64/memory.txt +++ b/Documentation/arm64/memory.txt @@ -8,10 +8,11 @@ This document describes the virtual memory layout used by the AArch64 Linux kernel. The architecture allows up to 4 levels of translation tables with a 4KB page size and up to 3 levels with a 64KB page size. -AArch64 Linux uses 3 levels of translation tables with the 4KB page -configuration, allowing 39-bit (512GB) virtual addresses for both user -and kernel. With 64KB pages, only 2 levels of translation tables are -used but the memory layout is the same. +AArch64 Linux uses 3 levels and 4 levels of translation tables with +the 4KB page configuration, allowing 39-bit (512GB) and 48-bit (256TB) +virtual addresses, respectively, for both user and kernel. With 64KB +pages, only 2 levels of translation tables are used but the memory layout +is the same. User addresses have bits 63:39 set to 0 while the kernel addresses have the same bits set to 1. TTBRx selection is given by bit 63 of the @@ -21,7 +22,7 @@ The swapper_pgd_dir address is written to TTBR1 and never written to TTBR0. -AArch64 Linux memory layout with 4KB pages: +AArch64 Linux memory layout with 4KB pages + 3 levels: Start End SizeUse --- @@ -48,7 +49,34 @@ ffbffc00 ffbf 64MB modules ffc0 256GB kernel logical memory map -AArch64 Linux memory layout with 64KB pages: +AArch64 Linux memory layout with 4KB pages + 4 levels: + +Start End SizeUse +--- + 256TB user + + 7bfe~124TB vmalloc + +7bff 7bff 64KB [guard page] + +7c00 7dff 2TB vmemmap + +7e00 7bbf ~2TB [guard, future vmmemap] + +7a00 7aff 16MB PCI I/O space + +7b00 7bbf 12MB [guard] + +7bc0 7bdf 2MB earlyprintk device + +7be0 7bff 2MB [guard] + +7c00 7fff 64MB modules + +8000 128TB kernel logical memory map + + +AArch64 Linux memory layout with 64KB pages + 2 levels: Start End SizeUse --- @@ -75,7 +103,7 @@ fdfffc00 fdff 64MB modules fe00 2TB kernel logical memory map -Translation table lookup with 4KB pages: +Translation table lookup with 4KB pages + 3 levels: +++++++++ |6356|5548|4740|3932|3124|2316|15 8|7 0| @@ -90,7 +118,22 @@ Translation table lookup with 4KB pages: +- [63] TTBR0/1 -Translation table lookup with 64KB pages: +Translation table lookup with 4KB pages + 4 levels: + ++++++++++ +|6356|5548|4740|3932|3124|2316|15 8|7 0| ++++++++++ + | | | | | | + | | | | | v + | | | | | [11:0] in-page offset + | | | | +- [20:12] L3 index + | | | +--- [29:21] L2 index + | | +- [38:30] L1 index + | +--- [47:39] L0 index + +- [63] TTBR0/1 + + +Translation table lookup with 64KB pages + 2 levels:
[PATCH v5 4/6] arm64: Add 4 levels of page tables definition with 4KB pages
This patch adds hardware definition and types for 4 levels of
translation tables with 4KB pages.
Cc: Catalin Marinas catalin.mari...@arm.com
Cc: Steve Capper steve.cap...@linaro.org
Signed-off-by: Jungseok Lee jays@samsung.com
Reviewed-by: Sungjinn Chung sungjinn.ch...@samsung.com
---
arch/arm64/include/asm/pgtable-4level-hwdef.h | 50 +
arch/arm64/include/asm/pgtable-4level-types.h | 71 +
2 files changed, 121 insertions(+)
create mode 100644 arch/arm64/include/asm/pgtable-4level-hwdef.h
create mode 100644 arch/arm64/include/asm/pgtable-4level-types.h
diff --git a/arch/arm64/include/asm/pgtable-4level-hwdef.h
b/arch/arm64/include/asm/pgtable-4level-hwdef.h
new file mode 100644
index 000..0ec84e2
--- /dev/null
+++ b/arch/arm64/include/asm/pgtable-4level-hwdef.h
@@ -0,0 +1,50 @@
+/*
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see http://www.gnu.org/licenses/.
+ */
+#ifndef __ASM_PGTABLE_4LEVEL_HWDEF_H
+#define __ASM_PGTABLE_4LEVEL_HWDEF_H
+
+#define PTRS_PER_PTE 512
+#define PTRS_PER_PMD 512
+#define PTRS_PER_PUD 512
+#define PTRS_PER_PGD 512
+
+/*
+ * PGDIR_SHIFT determines the size a top-level page table entry can map.
+ */
+#define PGDIR_SHIFT39
+#define PGDIR_SIZE (_AC(1, UL) PGDIR_SHIFT)
+#define PGDIR_MASK (~(PGDIR_SIZE-1))
+
+/*
+ * PUD_SHIFT determines the size the second level page table entry can map.
+ */
+#define PUD_SHIFT 30
+#define PUD_SIZE (_AC(1, UL) PUD_SHIFT)
+#define PUD_MASK (~(PUD_SIZE-1))
+
+/*
+ * PMD_SHIFT determines the size the third level page table entry can map.
+ */
+#define PMD_SHIFT 21
+#define PMD_SIZE (_AC(1, UL) PMD_SHIFT)
+#define PMD_MASK (~(PMD_SIZE-1))
+
+/*
+ * section address mask and size definitions.
+ */
+#define SECTION_SHIFT 21
+#define SECTION_SIZE (_AC(1, UL) SECTION_SHIFT)
+#define SECTION_MASK (~(SECTION_SIZE-1))
+
+#endif
diff --git a/arch/arm64/include/asm/pgtable-4level-types.h
b/arch/arm64/include/asm/pgtable-4level-types.h
new file mode 100644
index 000..7ad8dd2
--- /dev/null
+++ b/arch/arm64/include/asm/pgtable-4level-types.h
@@ -0,0 +1,71 @@
+/*
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see http://www.gnu.org/licenses/.
+ */
+#ifndef __ASM_PGTABLE_4LEVEL_TYPES_H
+#define __ASM_PGTABLE_4LEVEL_TYPES_H
+
+#include asm/types.h
+
+typedef u64 pteval_t;
+typedef u64 pmdval_t;
+typedef u64 pudval_t;
+typedef u64 pgdval_t;
+
+#undef STRICT_MM_TYPECHECKS
+
+#ifdef STRICT_MM_TYPECHECKS
+
+/*
+ * These are used to make use of C type-checking..
+ */
+typedef struct { pteval_t pte; } pte_t;
+typedef struct { pmdval_t pmd; } pmd_t;
+typedef struct { pudval_t pud; } pud_t;
+typedef struct { pgdval_t pgd; } pgd_t;
+typedef struct { pteval_t pgprot; } pgprot_t;
+
+#define pte_val(x) ((x).pte)
+#define pmd_val(x) ((x).pmd)
+#define pud_val(x) ((x).pud)
+#define pgd_val(x) ((x).pgd)
+#define pgprot_val(x) ((x).pgprot)
+
+#define __pte(x) ((pte_t) { (x) } )
+#define __pmd(x) ((pmd_t) { (x) } )
+#define __pud(x) ((pud_t) { (x) } )
+#define __pgd(x) ((pgd_t) { (x) } )
+#define __pgprot(x)((pgprot_t) { (x) } )
+
+#else /* !STRICT_MM_TYPECHECKS */
+
+typedef pteval_t pte_t;
+typedef pmdval_t pmd_t;
+typedef pudval_t pud_t;
+typedef pgdval_t pgd_t;
+typedef pteval_t pgprot_t;
+
+#define pte_val(x) (x)
+#define pmd_val(x) (x)
+#define pud_val(x) (x)
+#define pgd_val(x) (x)
+#define pgprot_val(x) (x)
+
+#define __pte(x) (x)
+#define __pmd(x) (x)
+#define __pud(x) (x)
+#define __pgd(x) (x)
+#define __pgprot(x)(x)
+
+#endif /* STRICT_MM_TYPECHECKS */
+
+#endif /* __ASM_PGTABLE_4LEVEL_TYPES_H */
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to
[PATCH v5 2/6] arm64: Introduce VA_BITS and translation level options
This patch adds virtual address space size and a level of translation
tables to kernel configuration. It facilicates introduction of
different MMU options, such as 4KB + 4 levels, 16KB + 4 levels and
64KB + 3 levels, easily.
The idea is based on the discussion with Catalin Marinas:
http://www.spinics.net/linux/lists/arm-kernel/msg319552.html
Cc: Catalin Marinas catalin.mari...@arm.com
Cc: Steve Capper steve.cap...@linaro.org
Signed-off-by: Jungseok Lee jays@samsung.com
Reviewed-by: Sungjinn Chung sungjinn.ch...@samsung.com
---
arch/arm64/Kconfig | 45 +++-
arch/arm64/include/asm/memory.h|6 +
arch/arm64/include/asm/page.h |2 +-
arch/arm64/include/asm/pgalloc.h |4 +--
arch/arm64/include/asm/pgtable-hwdef.h |2 +-
arch/arm64/include/asm/pgtable.h |8 +++---
arch/arm64/include/asm/tlb.h |2 +-
7 files changed, 54 insertions(+), 15 deletions(-)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index e759af5..b438540 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -144,14 +144,57 @@ endmenu
menu Kernel Features
+choice
+ prompt Page size
+ default ARM64_4K_PAGES
+ help
+ Allows page size.
+
+config ARM64_4K_PAGES
+ bool 4KB
+ help
+ This feature enables 4KB pages support.
+
config ARM64_64K_PAGES
- bool Enable 64KB pages support
+ bool 64KB
help
This feature enables 64KB pages support (4KB by default)
allowing only two levels of page tables and faster TLB
look-up. AArch32 emulation is not available when this feature
is enabled.
+endchoice
+
+choice
+ prompt Virtual address space size
+ default ARM64_VA_BITS_39 if ARM64_4K_PAGES
+ default ARM64_VA_BITS_42 if ARM64_64K_PAGES
+ help
+ Allows virtual address space size. A level of translation tables
+ is determined by a combination of page size and virtual address
+ space size.
+
+config ARM64_VA_BITS_39
+ bool 39-bit
+ depends on ARM64_4K_PAGES
+
+config ARM64_VA_BITS_42
+ bool 42-bit
+ depends on ARM64_64K_PAGES
+
+endchoice
+
+config ARM64_VA_BITS
+ int
+ default 39 if ARM64_VA_BITS_39
+ default 42 if ARM64_VA_BITS_42
+
+config ARM64_2_LEVELS
+ def_bool y if ARM64_64K_PAGES ARM64_VA_BITS_42
+
+config ARM64_3_LEVELS
+ def_bool y if ARM64_4K_PAGES ARM64_VA_BITS_39
+
config CPU_BIG_ENDIAN
bool Build big-endian kernel
help
diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
index e94f945..f6e7480 100644
--- a/arch/arm64/include/asm/memory.h
+++ b/arch/arm64/include/asm/memory.h
@@ -41,11 +41,7 @@
* The module space lives between the addresses given by TASK_SIZE
* and PAGE_OFFSET - it must be within 128MB of the kernel text.
*/
-#ifdef CONFIG_ARM64_64K_PAGES
-#define VA_BITS(42)
-#else
-#define VA_BITS(39)
-#endif
+#define VA_BITS(CONFIG_ARM64_VA_BITS)
#define PAGE_OFFSET(UL(0x) (VA_BITS - 1))
#define MODULES_END(PAGE_OFFSET)
#define MODULES_VADDR (MODULES_END - SZ_64M)
diff --git a/arch/arm64/include/asm/page.h b/arch/arm64/include/asm/page.h
index 46bf666..268e53d 100644
--- a/arch/arm64/include/asm/page.h
+++ b/arch/arm64/include/asm/page.h
@@ -33,7 +33,7 @@
#ifndef __ASSEMBLY__
-#ifdef CONFIG_ARM64_64K_PAGES
+#ifdef CONFIG_ARM64_2_LEVELS
#include asm/pgtable-2level-types.h
#else
#include asm/pgtable-3level-types.h
diff --git a/arch/arm64/include/asm/pgalloc.h b/arch/arm64/include/asm/pgalloc.h
index 9bea6e7..4829837 100644
--- a/arch/arm64/include/asm/pgalloc.h
+++ b/arch/arm64/include/asm/pgalloc.h
@@ -26,7 +26,7 @@
#define check_pgt_cache() do { } while (0)
-#ifndef CONFIG_ARM64_64K_PAGES
+#ifndef CONFIG_ARM64_2_LEVELS
static inline pmd_t *pmd_alloc_one(struct mm_struct *mm, unsigned long addr)
{
@@ -44,7 +44,7 @@ static inline void pud_populate(struct mm_struct *mm, pud_t
*pud, pmd_t *pmd)
set_pud(pud, __pud(__pa(pmd) | PMD_TYPE_TABLE));
}
-#endif /* CONFIG_ARM64_64K_PAGES */
+#endif /* CONFIG_ARM64_2_LEVELS */
extern pgd_t *pgd_alloc(struct mm_struct *mm);
extern void pgd_free(struct mm_struct *mm, pgd_t *pgd);
diff --git a/arch/arm64/include/asm/pgtable-hwdef.h
b/arch/arm64/include/asm/pgtable-hwdef.h
index 5fc8a66..9cd86c6 100644
--- a/arch/arm64/include/asm/pgtable-hwdef.h
+++ b/arch/arm64/include/asm/pgtable-hwdef.h
@@ -16,7 +16,7 @@
#ifndef __ASM_PGTABLE_HWDEF_H
#define __ASM_PGTABLE_HWDEF_H
-#ifdef CONFIG_ARM64_64K_PAGES
+#ifdef CONFIG_ARM64_2_LEVELS
#include asm/pgtable-2level-hwdef.h
#else
#include asm/pgtable-3level-hwdef.h
diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index 90c811f..a64ce5e 100644
--- a/arch/arm64/include/asm/pgtable.h
[PATCH v5 5/6] arm64: mm: Implement 4 levels of translation tables
This patch implements 4 levels of translation tables since 3 levels
of page tables with 4KB pages cannot support 40-bit physical address
space described in [1] due to the following issue.
It is a restriction that kernel logical memory map with 4KB + 3 levels
(0xffc0-0x) cannot cover RAM region from
544GB to 1024GB in [1]. Specifically, ARM64 kernel fails to create
mapping for this region in map_mem function since __phys_to_virt for
this region reaches to address overflow.
If SoC design follows the document, [1], over 32GB RAM would be placed
from 544GB. Even 64GB system is supposed to use the region from 544GB
to 576GB for only 32GB RAM. Naturally, it would reach to enable 4 levels
of page tables to avoid hacking __virt_to_phys and __phys_to_virt.
However, it is recommended 4 levels of page table should be only enabled
if memory map is too sparse or there is about 512GB RAM.
References
--
[1]: Principles of ARM Memory Maps, White Paper, Issue C
Cc: Catalin Marinas catalin.mari...@arm.com
Cc: Steve Capper steve.cap...@linaro.org
Signed-off-by: Jungseok Lee jays@samsung.com
Reviewed-by: Sungjinn Chung sungjinn.ch...@samsung.com
---
arch/arm64/Kconfig |8 ++
arch/arm64/include/asm/memblock.h |6 +
arch/arm64/include/asm/page.h |4 ++-
arch/arm64/include/asm/pgalloc.h | 20 ++
arch/arm64/include/asm/pgtable-hwdef.h |6 +++--
arch/arm64/include/asm/pgtable.h | 45 +++
arch/arm64/include/asm/tlb.h |9 +++
arch/arm64/kernel/head.S | 46 +---
arch/arm64/kernel/traps.c |5
arch/arm64/mm/fault.c |1 +
arch/arm64/mm/mmu.c| 16 ---
11 files changed, 150 insertions(+), 16 deletions(-)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index b438540..3e49671 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -182,12 +182,17 @@ config ARM64_VA_BITS_42
bool 42-bit
depends on ARM64_64K_PAGES
+config ARM64_VA_BITS_48
+ bool 48-bit
+ depends on ARM64_4K_PAGES
+
endchoice
config ARM64_VA_BITS
int
default 39 if ARM64_VA_BITS_39
default 42 if ARM64_VA_BITS_42
+ default 48 if ARM64_VA_BITS_48
config ARM64_2_LEVELS
def_bool y if ARM64_64K_PAGES ARM64_VA_BITS_42
@@ -195,6 +200,9 @@ config ARM64_2_LEVELS
config ARM64_3_LEVELS
def_bool y if ARM64_4K_PAGES ARM64_VA_BITS_39
+config ARM64_4_LEVELS
+ def_bool y if ARM64_4K_PAGES ARM64_VA_BITS_48
+
config CPU_BIG_ENDIAN
bool Build big-endian kernel
help
diff --git a/arch/arm64/include/asm/memblock.h
b/arch/arm64/include/asm/memblock.h
index 6afeed2..e4ac8bf 100644
--- a/arch/arm64/include/asm/memblock.h
+++ b/arch/arm64/include/asm/memblock.h
@@ -16,6 +16,12 @@
#ifndef __ASM_MEMBLOCK_H
#define __ASM_MEMBLOCK_H
+#ifndef CONFIG_ARM64_4_LEVELS
+#define MEMBLOCK_INITIAL_LIMIT PGDIR_SIZE
+#else
+#define MEMBLOCK_INITIAL_LIMIT PUD_SIZE
+#endif
+
extern void arm64_memblock_init(void);
#endif
diff --git a/arch/arm64/include/asm/page.h b/arch/arm64/include/asm/page.h
index 268e53d..83b5289 100644
--- a/arch/arm64/include/asm/page.h
+++ b/arch/arm64/include/asm/page.h
@@ -35,8 +35,10 @@
#ifdef CONFIG_ARM64_2_LEVELS
#include asm/pgtable-2level-types.h
-#else
+#elif defined(CONFIG_ARM64_3_LEVELS)
#include asm/pgtable-3level-types.h
+#else
+#include asm/pgtable-4level-types.h
#endif
extern void __cpu_clear_user_page(void *p, unsigned long user);
diff --git a/arch/arm64/include/asm/pgalloc.h b/arch/arm64/include/asm/pgalloc.h
index 4829837..8d745fa 100644
--- a/arch/arm64/include/asm/pgalloc.h
+++ b/arch/arm64/include/asm/pgalloc.h
@@ -26,6 +26,26 @@
#define check_pgt_cache() do { } while (0)
+#ifdef CONFIG_ARM64_4_LEVELS
+
+static inline pud_t *pud_alloc_one(struct mm_struct *mm, unsigned long addr)
+{
+ return (pud_t *)get_zeroed_page(GFP_KERNEL | __GFP_REPEAT);
+}
+
+static inline void pud_free(struct mm_struct *mm, pud_t *pud)
+{
+ BUG_ON((unsigned long)pud (PAGE_SIZE-1));
+ free_page((unsigned long)pud);
+}
+
+static inline void pgd_populate(struct mm_struct *mm, pgd_t *pgd, pud_t *pud)
+{
+ set_pgd(pgd, __pgd(__pa(pud) | PUD_TYPE_TABLE));
+}
+
+#endif /* CONFIG_ARM64_4_LEVELS */
+
#ifndef CONFIG_ARM64_2_LEVELS
static inline pmd_t *pmd_alloc_one(struct mm_struct *mm, unsigned long addr)
diff --git a/arch/arm64/include/asm/pgtable-hwdef.h
b/arch/arm64/include/asm/pgtable-hwdef.h
index 9cd86c6..ba30053 100644
--- a/arch/arm64/include/asm/pgtable-hwdef.h
+++ b/arch/arm64/include/asm/pgtable-hwdef.h
@@ -18,8 +18,10 @@
#ifdef CONFIG_ARM64_2_LEVELS
#include asm/pgtable-2level-hwdef.h
-#else
+#elif defined(CONFIG_ARM64_3_LEVELS)
#include asm/pgtable-3level-hwdef.h
+#else
+#include asm/pgtable-4level-hwdef.h
#endif
/*
