Re: [PATCH V4 1/5] phy: Add new Exynos5 USB 3.0 PHY driver
Hi Tomasz,
On Thu, Apr 10, 2014 at 5:09 PM, Vivek Gautam gautamvivek1...@gmail.com wrote:
On Wed, Apr 9, 2014 at 7:03 PM, Tomasz Figa t.f...@samsung.com wrote:
On 09.04.2014 13:49, Vivek Gautam wrote:
Hi,
On Wed, Apr 9, 2014 at 4:36 PM, Tomasz Figa t.f...@samsung.com wrote:
Hi Vivek,
Please see my comments inline.
On 08.04.2014 16:36, Vivek Gautam wrote:
Add a new driver for the USB 3.0 PHY on Exynos5 series of SoCs.
The new driver uses the generic PHY framework and will interact
with DWC3 controller present on Exynos5 series of SoCs.
Thereby, removing old phy-samsung-usb3 driver and related code
used untill now which was based on usb/phy framework.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
.../devicetree/bindings/phy/samsung-phy.txt| 42 ++
drivers/phy/Kconfig| 11 +
drivers/phy/Makefile |1 +
drivers/phy/phy-exynos5-usbdrd.c | 668
4 files changed, 722 insertions(+)
create mode 100644 drivers/phy/phy-exynos5-usbdrd.c
[snip]
+ Additional clock required for Exynos5420:
+ - usb30_sclk_100m: Additional special clock used for PHY
operation
+ depicted as 'sclk_usbphy30' in CMU of
Exynos5420.
Are you sure this isn't simply a gate for the ref clock, as it can be
found
on another SoC that is not upstream yet? I don't have documentation for
Exynos 5420 so I can't tell, but I'd like to ask you to recheck this.
From what i can see in the manual :
sclk_usbphy30 is derived from OSCCLK.
It is coming from a MUX (default input line to this is OSCCLK) and
then through a DIV
there's this gate.
{OSCCLK + other sources} ---[MUX] --- [DIV] -- [GATE for
sclk_usbphy30]
the {rate of sclk_usbphy30} == OSCCLK
However the 'ref' clock that we have been using is the actual oscillator
clock.
And on SoC Exynos5250, we don't have any such gate (sclk_usbphy30).
So should this mean that ref clock and sclk_usbphy30 are still be
controlled by
two different gates ?
Is there maybe a diagram of PHY input clocks in the datasheet, like for USB
2.0 PHY in Exynos4210/4412/5250 datasheets in the chapter about USB2.0
Device? Something like:
||
| ___|
XusbXTI | Phy_fsel[2:0]| ___ |
___[X]___|| __|_|___|\__|_|
| | _v___ | _ ^ | |/ | |
_ | | || | | | | ___ | |
___| | || | | | | | |_|_|
|___| | | X 0 ||_| PLL |__|_|_|CLK|_|_|
_ | | | | || |DIV|_|_|
|___[X] | |_| 12 |_|480 | |___| | |
| MHz MHz |Digital| |
XusbXTO | USB PHY|___| |
||
Below is the block diagram given for DRD controller.
___
||
| |
| | PHY | |
| | controller |-|---
| |__ | | |
||
|
| USB 3.0 | V
| DRD |
---
|Controller | |
|
||USB30_SCLK_100M| USB 3.0 DRD |
| | ---
| PHY |
| | Link cont. | | |
|
| - |
| |
|___| |_|
Does this help ?
So, USB30_SCLK_100M is the SCLK that we are talking in the driver. I
don't see any reference to XXTI in the USB 3.0 DRD controller chapter
(in both Exynos5250 and 5420)
In addition to this there's one more point to be noticed here.
On Exynos5420 system, the sclk_usbphy300 (which is the sclk_usbphy30
for USB DRD channel 0), is also the PICO phy clock, i.e. USB 2.0 phy
clock.
So we should add a similar clk_get() for this clock in the
phy-exynos5250-usb2 driver too, to support Exynos5420.
Is something clear from the above block diagram ? (although the
diagram looks weird - space and tabs problem :-( )
Basically there's the clock USB30_SCLK_100M which is going into the
USB 3.0 DRD PHY controller.
And this is the only sclk mentioned in the block diagram for USB 3.0
DRD controller in Exynos5420.
Same is not
[PATCH] arm: exynos: generalize power register address calculation
Currently status/configuration power register values are hard-coded for cpu1.
Make it generic so that it is useful for SoC's with more than two cpus.
Signed-off-by: Chander Kashyap chander.kash...@linaro.org
---
changes in v3:
1. Move cpunr calculation to a macro
2. Changed printk format specifier from unsigned hex to unsigned decimal
Changes in v2:
1. Used existing macros for clusterid and cpuid calculation
arch/arm/mach-exynos/hotplug.c |7 ---
arch/arm/mach-exynos/platsmp.c | 13 +++--
arch/arm/mach-exynos/regs-pmu.h | 15 +--
3 files changed, 24 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-exynos/hotplug.c b/arch/arm/mach-exynos/hotplug.c
index 5eead53..9f74be2 100644
--- a/arch/arm/mach-exynos/hotplug.c
+++ b/arch/arm/mach-exynos/hotplug.c
@@ -92,11 +92,12 @@ static inline void cpu_leave_lowpower(void)
static inline void platform_do_lowpower(unsigned int cpu, int *spurious)
{
+ unsigned int cpunr = ENYNOS_PMU_CPUNR(cpu_logical_map(cpu));
for (;;) {
- /* make cpu1 to be turned off at next WFI command */
- if (cpu == 1)
- __raw_writel(0, S5P_ARM_CORE1_CONFIGURATION);
+ /* make cpu to be turned off at next WFI command */
+ if (cpu)
+ __raw_writel(0, S5P_ARM_CORE_CONFIGURATION(cpunr));
/*
* here's the WFI
diff --git a/arch/arm/mach-exynos/platsmp.c b/arch/arm/mach-exynos/platsmp.c
index 03e5e9f..d9c182f 100644
--- a/arch/arm/mach-exynos/platsmp.c
+++ b/arch/arm/mach-exynos/platsmp.c
@@ -90,7 +90,7 @@ static int exynos_boot_secondary(unsigned int cpu, struct
task_struct *idle)
{
unsigned long timeout;
unsigned long phys_cpu = cpu_logical_map(cpu);
-
+ unsigned int cpunr = ENYNOS_PMU_CPUNR(cpu_logical_map(cpu));
/*
* Set synchronisation state between this boot processor
* and the secondary one
@@ -107,14 +107,15 @@ static int exynos_boot_secondary(unsigned int cpu, struct
task_struct *idle)
*/
write_pen_release(phys_cpu);
- if (!(__raw_readl(S5P_ARM_CORE1_STATUS) S5P_CORE_LOCAL_PWR_EN)) {
+ if (!(__raw_readl(S5P_ARM_CORE_STATUS(cpunr))
+S5P_CORE_LOCAL_PWR_EN)) {
__raw_writel(S5P_CORE_LOCAL_PWR_EN,
-S5P_ARM_CORE1_CONFIGURATION);
+S5P_ARM_CORE_CONFIGURATION(cpunr));
timeout = 10;
- /* wait max 10 ms until cpu1 is on */
- while ((__raw_readl(S5P_ARM_CORE1_STATUS)
+ /* wait max 10 ms until secondary cpu is on */
+ while ((__raw_readl(S5P_ARM_CORE_STATUS(cpunr))
S5P_CORE_LOCAL_PWR_EN) != S5P_CORE_LOCAL_PWR_EN) {
if (timeout-- == 0)
break;
@@ -123,7 +124,7 @@ static int exynos_boot_secondary(unsigned int cpu, struct
task_struct *idle)
}
if (timeout == 0) {
- printk(KERN_ERR cpu1 power enable failed);
+ pr_err(cpu%u power enable failed, cpu);
spin_unlock(boot_lock);
return -ETIMEDOUT;
}
diff --git a/arch/arm/mach-exynos/regs-pmu.h b/arch/arm/mach-exynos/regs-pmu.h
index 4f6a256..0de6df4 100644
--- a/arch/arm/mach-exynos/regs-pmu.h
+++ b/arch/arm/mach-exynos/regs-pmu.h
@@ -105,8 +105,13 @@
#define S5P_GPS_LOWPWR S5P_PMUREG(0x139C)
#define S5P_GPS_ALIVE_LOWPWR S5P_PMUREG(0x13A0)
-#define S5P_ARM_CORE1_CONFIGURATIONS5P_PMUREG(0x2080)
-#define S5P_ARM_CORE1_STATUS S5P_PMUREG(0x2084)
+#define S5P_ARM_CORE0_CONFIGURATIONS5P_PMUREG(0x2000)
+#define S5P_ARM_CORE0_STATUS S5P_PMUREG(0x2004)
+
+#define S5P_ARM_CORE_CONFIGURATION(_cpunr) \
+ (S5P_ARM_CORE0_CONFIGURATION + 0x80 * (_cpunr))
+#define S5P_ARM_CORE_STATUS(_cpunr)\
+ (S5P_ARM_CORE0_STATUS + 0x80 * (_cpunr))
#define S5P_PAD_RET_MAUDIO_OPTION S5P_PMUREG(0x3028)
#define S5P_PAD_RET_GPIO_OPTIONS5P_PMUREG(0x3108)
@@ -313,4 +318,10 @@
#define EXYNOS5_OPTION_USE_RETENTION (1 4)
+#include asm/cputype.h
+#define MAX_CPUS_IN_CLUSTER4
+#define ENYNOS_PMU_CPUNR(mpidr) \
+ ((MPIDR_AFFINITY_LEVEL(mpidr, 1) * MAX_CPUS_IN_CLUSTER) \
+ + MPIDR_AFFINITY_LEVEL(mpidr, 0));
+
#endif /* __ASM_ARCH_REGS_PMU_H */
--
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 4/4] regulator: s5m8767: Use same binding for external control as in s2mps11
On 15 April 2014 02:41, Mark Brown broo...@kernel.org wrote: On Mon, Apr 14, 2014 at 10:09:09AM +0200, Krzysztof Kozlowski wrote: - - s5m8767,pmic-ext-control-gpios: (optional) GPIO specifier for one + - samsung,ext-control-gpios: (optional) GPIO specifier for one GPIO controlling this regulator (enable/disable); This is valid only for buck9. This is an incompatible change. It's OK to deprecate the old property but it's bad form to just remove it. I agree with Mark. Also, there is no need to make it generic. -- 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 04/14] ARM: dts: add exynos5 compatible to sysreg
Hi YoungJun, On 15 April 2014 11:17, YoungJun Cho yj44@samsung.com wrote: This patch adds sysreg support for exynos5 SoCs. The patch title and commit description seem a bit off here. This patch does not add support per se. It only updates the binding documentaion. -- 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 14/14] ARM: dts: exynos5420: add dsi node
Hi YoungJun,
On 15 April 2014 11:17, YoungJun Cho yj44@samsung.com wrote:
This patch adds common part of dsi node.
Signed-off-by: YoungJun Cho yj44@samsung.com
Signed-off-by: Inki Dae inki@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
arch/arm/boot/dts/exynos5420.dtsi | 14 ++
1 file changed, 14 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch/arm/boot/dts/exynos5420.dtsi
index f0184c7..aa2350a 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -422,6 +422,20 @@
#phy-cells = 1;
};
+ dsi@1450 {
+ compatible = samsung,exynos5420-mipi-dsi;
+ reg = 0x1450 0x1;
+ interrupts = 0 82 0;
+ samsung,power-domain = disp_pd;
+ phys = mipi_phy 1;
+ phy-names = dsim;
+ clocks = clock 411, clock 146;
Please use macros instead of numbers.
+ clock-names = bus_clk, pll_clk;
+ status = disabled;
nit: Move this to the end for readability.
--
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 07/14] ARM: dts: exynos_dsim: add exynos5420 Soc compatible
On 15 April 2014 11:17, YoungJun Cho yj44@samsung.com wrote: This patch adds exynos5420 SoC support. This patch just updates binding documentation :) Signed-off-by: YoungJun Cho yj44@samsung.com Signed-off-by: Inki Dae inki@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com --- .../devicetree/bindings/video/exynos_dsim.txt |4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/video/exynos_dsim.txt b/Documentation/devicetree/bindings/video/exynos_dsim.txt index 33b5730..9bbf82b 100644 --- a/Documentation/devicetree/bindings/video/exynos_dsim.txt +++ b/Documentation/devicetree/bindings/video/exynos_dsim.txt @@ -1,7 +1,9 @@ Exynos MIPI DSI Master Required properties: - - compatible: samsung,exynos4210-mipi-dsi + - compatible: value should be one of the following + samsung,exynos4210-mipi-dsi /* for Exynos4 SoCs */ + samsung,exynos5420-mipi-dsi /* for Exynos5420 Soc */ s/Soc/SoC -- 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 2/8] arm/arm64: KVM: Fix line length exceeding 80 characters
On 15/04/14 01:38, Jungseok Lee wrote: On Tuesday, April 15, 2014 1:19 AM, Marc Zyngier wrote: On 14/04/14 08:40, Jungseok Lee wrote: This patch deals with checkpatch complaint as fixing line length exceeding 80 characters. WARNING: line over 80 characters Signed-off-by: Jungseok Lee jays@samsung.com Reviewed-by: Sungjinn Chung sungjinn.ch...@samsung.com --- arch/arm/kvm/mmu.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c index 80bb1e6..e0d4f24 100644 --- a/arch/arm/kvm/mmu.c +++ b/arch/arm/kvm/mmu.c @@ -563,8 +563,8 @@ void kvm_free_stage2_pgd(struct kvm *kvm) kvm-arch.pgd = NULL; } -static pmd_t *stage2_get_pmd(struct kvm *kvm, struct kvm_mmu_memory_cache *cache, -phys_addr_t addr) +static pmd_t *stage2_get_pmd(struct kvm *kvm, struct kvm_mmu_memory_cache +*cache, phys_addr_t addr) Please don't. This makes the code unreadable (and no, I don't care about checkpatch ;-). Okay. I will drop this patch from the next version. It would be good to change stage2_set_pmd_huge function for readability if you don't care about checkpatch. We usually don't change that kind of thing just for the sake of changing it. It feels like fairly pointless churn. *IF* someone happens to rework that code, then they're welcome to fix it. M. -- Jazz is not dead. It just smells funny... -- 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 3/8] ARM: EXYNOS: Add IO mapping for PMU of Exynos3250
On Tuesday 15 April 2014 10:59:47 Chanwoo Choi wrote: This patch add memory mapping for PMU (Power Management Unit) which is used for power control of Exynos3250. Signed-off-by: Chanwoo Choi cw00.c...@samsung.com Acked-by: Kyungmin Park kyungmin.p...@samsung.com --- Arnd Bergmann suggested that need proper driver instead of static memory mapping. As Chanho Park reply[2], Sachin Kamat already posted the DT support patch[1] for memory mapping for SYSRAM. [1] http://www.spinics.net/lists/linux-samsung-soc/msg27647.html [2] https://lkml.org/lkml/2014/4/10/161 So, I'm going to re-implement following patch related to static memory mapping after merged Sachin Kamat patch[1]. ARM: EXYNOS: Add IO mapping for PMU of Exynos3250 I don't think we have a patch for the PMU yet, Sachin was looking at the SYSRAM only. 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 4/4] regulator: s5m8767: Use same binding for external control as in s2mps11
On wto, 2014-04-15 at 13:26 +0530, Sachin Kamat wrote: On 15 April 2014 02:41, Mark Brown broo...@kernel.org wrote: On Mon, Apr 14, 2014 at 10:09:09AM +0200, Krzysztof Kozlowski wrote: - - s5m8767,pmic-ext-control-gpios: (optional) GPIO specifier for one + - samsung,ext-control-gpios: (optional) GPIO specifier for one GPIO controlling this regulator (enable/disable); This is valid only for buck9. This is an incompatible change. It's OK to deprecate the old property but it's bad form to just remove it. I agree with Mark. Also, there is no need to make it generic. I thought it would be good to make it consistent and to reduce the number of bindings with same meaning on similar drivers. However I don't mind skipping this patch. Thanks for applying rest of patches. Best regards, Krzysztof -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 09/14] ARM: dts: s6e3fa0: add DT bindings
On 15 April 2014 11:17, YoungJun Cho yj44@samsung.com wrote:
This patch adds DT bindings for s6e3fa0 panel.
The bindings describes panel resources, display timings, delays
and physical size.
Signed-off-by: YoungJun Cho yj44@samsung.com
Signed-off-by: Inki Dae inki@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
.../devicetree/bindings/panel/samsung,s6e3fa0.txt | 52
1 file changed, 52 insertions(+)
create mode 100644
Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt
diff --git a/Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt
b/Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt
new file mode 100644
index 000..5986899
--- /dev/null
+++ b/Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt
@@ -0,0 +1,52 @@
+Samsung S6E3FA0 AMOLED LCD 5.7 inch panel
+
+Required properties:
+ - compatible: samsung,s6e3fa0
+ - reg: the virtual channel number of a DSI peripheral
+ - vdd3-supply: core voltage supply
+ - vci-supply: voltage supply for analog circuits
+ - reset-gpio: a GPIO spec for the reset pin
+ - display-timings: timings for the connected panel as described by [1]
+
+Optional properties:
+ - power-on-delay: delay after turning regulators on [ms]
+ - reset-delay: delay after reset sequence [ms]
+ - init-delay: delay after initialization sequence [ms]
+ - panel-width-mm: physical panel width [mm]
+ - panel-height-mm: physical panel height [mm]
+
+The device node can contain one 'port' child node with one child
+'endpoint' node, according to the bindings defined in [2]. This
+node should describe panel's video bus.
+
+[1]: Documentation/devicetree/bindings/video/display-timing.txt
+[2]: Documentation/devicetree/bindings/media/video-interfaces.txt
+
+Example:
+
+ panel {
How about panel@0?
+ compatible = samsung,s6e3fa0;
+ reg = 0;
--
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] regulator: s5m8767: Use same binding for external control as in s2mps11
On 15 April 2014 13:42, Krzysztof Kozlowski k.kozlow...@samsung.com wrote: On wto, 2014-04-15 at 13:26 +0530, Sachin Kamat wrote: On 15 April 2014 02:41, Mark Brown broo...@kernel.org wrote: On Mon, Apr 14, 2014 at 10:09:09AM +0200, Krzysztof Kozlowski wrote: - - s5m8767,pmic-ext-control-gpios: (optional) GPIO specifier for one + - samsung,ext-control-gpios: (optional) GPIO specifier for one GPIO controlling this regulator (enable/disable); This is valid only for buck9. This is an incompatible change. It's OK to deprecate the old property but it's bad form to just remove it. I agree with Mark. Also, there is no need to make it generic. I thought it would be good to make it consistent and to reduce the number of bindings with same meaning on similar drivers. How about making the other one use s5m8767,pmic-ext-control-gpios compatible instead of introducing a new one? -- 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 3/8] ARM: EXYNOS: Add IO mapping for PMU of Exynos3250
Hi, On 04/15/2014 05:11 PM, Arnd Bergmann wrote: On Tuesday 15 April 2014 10:59:47 Chanwoo Choi wrote: This patch add memory mapping for PMU (Power Management Unit) which is used for power control of Exynos3250. Signed-off-by: Chanwoo Choi cw00.c...@samsung.com Acked-by: Kyungmin Park kyungmin.p...@samsung.com --- Arnd Bergmann suggested that need proper driver instead of static memory mapping. As Chanho Park reply[2], Sachin Kamat already posted the DT support patch[1] for memory mapping for SYSRAM. [1] http://www.spinics.net/lists/linux-samsung-soc/msg27647.html [2] https://lkml.org/lkml/2014/4/10/161 So, I'm going to re-implement following patch related to static memory mapping after merged Sachin Kamat patch[1]. ARM: EXYNOS: Add IO mapping for PMU of Exynos3250 I don't think we have a patch for the PMU yet, Sachin was looking at the SYSRAM only. You are right. Sachin's patch only included the solution of SYSRAM memory mapping. I set out the plan that I would implment proper driver for PMU memory mapping instead of static method after merged Sachin's patch for SYSRAM. But, If you'd like me to implment PMU memory mapping instead of static mapping right now, I'll implement it for PMU such as Sachin's patch on next posting(v3). Thanks for your review. Best Regards, Chanwoo Choi -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 3/8] ARM: EXYNOS: Add IO mapping for PMU of Exynos3250
Hi, On Tue, Apr 15, 2014 at 2:02 PM, Chanwoo Choi cw00.c...@samsung.com wrote: Hi, On 04/15/2014 05:11 PM, Arnd Bergmann wrote: On Tuesday 15 April 2014 10:59:47 Chanwoo Choi wrote: This patch add memory mapping for PMU (Power Management Unit) which is used for power control of Exynos3250. Signed-off-by: Chanwoo Choi cw00.c...@samsung.com Acked-by: Kyungmin Park kyungmin.p...@samsung.com --- Arnd Bergmann suggested that need proper driver instead of static memory mapping. As Chanho Park reply[2], Sachin Kamat already posted the DT support patch[1] for memory mapping for SYSRAM. [1] http://www.spinics.net/lists/linux-samsung-soc/msg27647.html [2] https://lkml.org/lkml/2014/4/10/161 So, I'm going to re-implement following patch related to static memory mapping after merged Sachin Kamat patch[1]. ARM: EXYNOS: Add IO mapping for PMU of Exynos3250 I don't think we have a patch for the PMU yet, Sachin was looking at the SYSRAM only. You are right. Sachin's patch only included the solution of SYSRAM memory mapping. I set out the plan that I would implment proper driver for PMU memory mapping instead of static method after merged Sachin's patch for SYSRAM. But, If you'd like me to implment PMU memory mapping instead of static mapping right now, I'll implement it for PMU such as Sachin's patch on next posting(v3). I have already posted patch[1] for mapping PMU through DT as part of my PMU series for exynos5260. You can rebase on the same. [1] http://www.spinics.net/lists/arm-kernel/msg316013.html Thanks for your review. Best Regards, Chanwoo Choi -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- 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 12/14] ARM: dts: exynos5: add system register support
On 15 April 2014 11:17, YoungJun Cho yj44@samsung.com wrote:
This patch adds sysreg device node, and sysreg property to fimd device node
which is required to use I80 interface.
Signed-off-by: YoungJun Cho yj44@samsung.com
Signed-off-by: Inki Dae inki@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
arch/arm/boot/dts/exynos5.dtsi |6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5.dtsi b/arch/arm/boot/dts/exynos5.dtsi
index 258dca4..f938bbb 100644
--- a/arch/arm/boot/dts/exynos5.dtsi
+++ b/arch/arm/boot/dts/exynos5.dtsi
@@ -88,12 +88,18 @@
status = disabled;
};
+ sys_reg: syscon@1005 {
+ compatible = samsung,exynos5-sysreg, syscon;
Do we really need a separate string for this? Can't we use
samsung,exynos4-sysreg itself?
--
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 3/8] ARM: EXYNOS: Add IO mapping for PMU of Exynos3250
Hi, On 04/15/2014 05:39 PM, Vikas Sajjan wrote: Hi, On Tue, Apr 15, 2014 at 2:02 PM, Chanwoo Choi cw00.c...@samsung.com wrote: Hi, On 04/15/2014 05:11 PM, Arnd Bergmann wrote: On Tuesday 15 April 2014 10:59:47 Chanwoo Choi wrote: This patch add memory mapping for PMU (Power Management Unit) which is used for power control of Exynos3250. Signed-off-by: Chanwoo Choi cw00.c...@samsung.com Acked-by: Kyungmin Park kyungmin.p...@samsung.com --- Arnd Bergmann suggested that need proper driver instead of static memory mapping. As Chanho Park reply[2], Sachin Kamat already posted the DT support patch[1] for memory mapping for SYSRAM. [1] http://www.spinics.net/lists/linux-samsung-soc/msg27647.html [2] https://lkml.org/lkml/2014/4/10/161 So, I'm going to re-implement following patch related to static memory mapping after merged Sachin Kamat patch[1]. ARM: EXYNOS: Add IO mapping for PMU of Exynos3250 I don't think we have a patch for the PMU yet, Sachin was looking at the SYSRAM only. You are right. Sachin's patch only included the solution of SYSRAM memory mapping. I set out the plan that I would implment proper driver for PMU memory mapping instead of static method after merged Sachin's patch for SYSRAM. But, If you'd like me to implment PMU memory mapping instead of static mapping right now, I'll implement it for PMU such as Sachin's patch on next posting(v3). I have already posted patch[1] for mapping PMU through DT as part of my PMU series for exynos5260. You can rebase on the same. [1] http://www.spinics.net/lists/arm-kernel/msg316013.html OK, I'll rebase it after merged PMU mapping patch[1]. 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 3/8] ARM: EXYNOS: Add IO mapping for PMU of Exynos3250
On 04/15/2014 05:46 PM, Arnd Bergmann wrote: On Tuesday 15 April 2014 17:32:40 Chanwoo Choi wrote: On 04/15/2014 05:11 PM, Arnd Bergmann wrote: On Tuesday 15 April 2014 10:59:47 Chanwoo Choi wrote: I don't think we have a patch for the PMU yet, Sachin was looking at the SYSRAM only. You are right. Sachin's patch only included the solution of SYSRAM memory mapping. I set out the plan that I would implment proper driver for PMU memory mapping instead of static method after merged Sachin's patch for SYSRAM. But, If you'd like me to implment PMU memory mapping instead of static mapping right now, I'll implement it for PMU such as Sachin's patch on next posting(v3). I don't really want to merge a new SoC type until these are resolved, so it would definitely be better to implement this for v3. OK, I'll rebase this patch on following patch which support PMU memory mapping through DT. [1] http://www.spinics.net/lists/arm-kernel/msg316013.html Thanks for your review. Best Regards, Chanwoo Choi -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] regulator: s5m8767: Use same binding for external control as in s2mps11
On wto, 2014-04-15 at 14:02 +0530, Sachin Kamat wrote: On 15 April 2014 13:42, Krzysztof Kozlowski k.kozlow...@samsung.com wrote: On wto, 2014-04-15 at 13:26 +0530, Sachin Kamat wrote: On 15 April 2014 02:41, Mark Brown broo...@kernel.org wrote: On Mon, Apr 14, 2014 at 10:09:09AM +0200, Krzysztof Kozlowski wrote: - - s5m8767,pmic-ext-control-gpios: (optional) GPIO specifier for one + - samsung,ext-control-gpios: (optional) GPIO specifier for one GPIO controlling this regulator (enable/disable); This is valid only for buck9. This is an incompatible change. It's OK to deprecate the old property but it's bad form to just remove it. I agree with Mark. Also, there is no need to make it generic. I thought it would be good to make it consistent and to reduce the number of bindings with same meaning on similar drivers. How about making the other one use s5m8767,pmic-ext-control-gpios compatible instead of introducing a new one? But then we would introduce semi-generic binding with a driver-specific name. Anyway more drivers seem to use this kind of binding (tps65090, max8952, da9055, arizona) so maybe there is a point in making this generic? Best regards, Krzysztof -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/6] ARM: EXYNOS: Staticize exynos_subsys
Hi Tomasz, On 10 April 2014 18:05, Sachin Kamat sachin.ka...@linaro.org wrote: On 10 April 2014 18:02, Tomasz Figa t.f...@samsung.com wrote: On 10.04.2014 11:22, Sachin Kamat wrote: Hi Tomasz, On 10 April 2014 14:47, Tomasz Figa t.f...@samsung.com wrote: snip Hmm, I don't see why it could break anything as I can't find any users of it. Anyway I just tested removing this code on Exynos4412-trats2 board and didn't find any problems. Thanks for testing. Let me check at my end on other boards and if it doesn't cause any problem, will remove this. Tested after removing this code on various boards and there doesn't seem to be any problems. Will re-send with this change. -- 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 12/14] ARM: dts: exynos5: add system register support
On 15/04/14 10:41, Sachin Kamat wrote:
On 15 April 2014 11:17, YoungJun Cho yj44@samsung.com wrote:
This patch adds sysreg device node, and sysreg property to fimd device node
which is required to use I80 interface.
Signed-off-by: YoungJun Cho yj44@samsung.com
Signed-off-by: Inki Dae inki@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
arch/arm/boot/dts/exynos5.dtsi |6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5.dtsi b/arch/arm/boot/dts/exynos5.dtsi
index 258dca4..f938bbb 100644
--- a/arch/arm/boot/dts/exynos5.dtsi
+++ b/arch/arm/boot/dts/exynos5.dtsi
@@ -88,12 +88,18 @@
status = disabled;
};
+ sys_reg: syscon@1005 {
+ compatible = samsung,exynos5-sysreg, syscon;
Do we really need a separate string for this? Can't we use
samsung,exynos4-sysreg itself?
Currently only syscon is meaningful in Linux, and we add second SoC
specific compatible to be able to distinguish between various SoC
revisions, should any SoC specific quirks be handled in future.
Thus there is no much point in adding samsung,exynos4-sysreg to
exynos5.dtsi. We could as well only leave syscon entry alone.
My suggestion is to keep samsung,exynos5-sysreg, so for instance
Exynos4 and Exynos5 SOC series SYSREG blocks can be identified in
an OS.
--
Regards,
Sylwester
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 0/4] drm: exynos: update/fixes to HDMI driver
Hi everyone, This patchset adds 4 fixes/updates to EXYNOS DRM driver for HDMI subsystem. All comments are welcome. Regards, Tomasz Stanislawski Changelog: v2: * fix check with gpio_is_valid() * use U32_MAX instead of ULONG_MAX to be 64-bit-friendly * use hdmi_driver_data as hdmi's compatile data v1: * initial version Tomasz Stanislawski (4): drm: exynos: hdmi: simplify extracting hpd-gpio from DT drm: exynos: mixer: fix using usleep() in atomic context drm: exynos: add compatibles for HDMI and Mixer chips and exynos4210 SoC drm: exynos: hdmi: add support for pixel clock limitation .../devicetree/bindings/video/exynos_hdmi.txt |4 +++ drivers/gpu/drm/exynos/exynos_hdmi.c | 30 ++-- drivers/gpu/drm/exynos/exynos_mixer.c |5 +++- include/media/s5p_hdmi.h |1 + 4 files changed, 31 insertions(+), 9 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
[PATCHv2 1/4] drm: exynos: hdmi: simplify extracting hpd-gpio from DT
This patch eliminates redundant checks while retrieving HPD gpio from DT during
HDMI's probe().
Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 13 -
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 9a6d652..47c6e85 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -2016,23 +2016,18 @@ static struct s5p_hdmi_platform_data
*drm_hdmi_dt_parse_pdata
{
struct device_node *np = dev-of_node;
struct s5p_hdmi_platform_data *pd;
- u32 value;
pd = devm_kzalloc(dev, sizeof(*pd), GFP_KERNEL);
if (!pd)
- goto err_data;
+ return NULL;
- if (!of_find_property(np, hpd-gpio, value)) {
+ pd-hpd_gpio = of_get_named_gpio(np, hpd-gpio, 0);
+ if (!gpio_is_valid(pd-hpd_gpio)) {
DRM_ERROR(no hpd gpio property found\n);
- goto err_data;
+ return NULL;
}
- pd-hpd_gpio = of_get_named_gpio(np, hpd-gpio, 0);
-
return pd;
-
-err_data:
- return NULL;
}
static struct of_device_id hdmi_match_types[] = {
--
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
[PATCHv2 2/4] drm: exynos: mixer: fix using usleep() in atomic context
This patch fixes calling usleep_range() after taking reg_slock using spin_lock_irqsave(). The mdelay() is used instead. Waiting in atomic context is not the best idea in general. Hopefully, waiting occurs only when Video Processor fails to reset correctly. Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com --- drivers/gpu/drm/exynos/exynos_mixer.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c b/drivers/gpu/drm/exynos/exynos_mixer.c index ce28881..e3306c8 100644 --- a/drivers/gpu/drm/exynos/exynos_mixer.c +++ b/drivers/gpu/drm/exynos/exynos_mixer.c @@ -615,7 +615,7 @@ static void vp_win_reset(struct mixer_context *ctx) /* waiting until VP_SRESET_PROCESSING is 0 */ if (~vp_reg_read(res, VP_SRESET) VP_SRESET_PROCESSING) break; - usleep_range(1, 12000); + mdelay(10); } WARN(tries == 0, failed to reset Video Processor\n); } -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 4/4] drm: exynos: hdmi: add support for pixel clock limitation
Adds support for limitation of maximal pixel clock of HDMI
signal. This feature is needed on boards that contains
lines or bridges with frequency limitations.
Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
---
.../devicetree/bindings/video/exynos_hdmi.txt |4
drivers/gpu/drm/exynos/exynos_hdmi.c | 12
include/media/s5p_hdmi.h |1 +
3 files changed, 17 insertions(+)
diff --git a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
index f9187a2..8718f8d 100644
--- a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
+++ b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
@@ -28,6 +28,10 @@ Required properties:
- ddc: phandle to the hdmi ddc node
- phy: phandle to the hdmi phy node
+Optional properties:
+- max-pixel-clock: used to limit the maximal pixel clock if a board has lines,
+ connectors or bridges not capable of carring higher frequencies
+
Example:
hdmi {
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 2a18f4e..404f1b7 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -195,6 +195,7 @@ struct hdmi_context {
struct hdmi_resources res;
int hpd_gpio;
+ u32 max_pixel_clock;
enum hdmi_type type;
};
@@ -887,6 +888,9 @@ static int hdmi_mode_valid(struct drm_connector *connector,
if (ret)
return MODE_BAD;
+ if (mode-clock * 1000 hdata-max_pixel_clock)
+ return MODE_BAD;
+
ret = hdmi_find_phy_conf(hdata, mode-clock * 1000);
if (ret 0)
return MODE_BAD;
@@ -2031,6 +2035,8 @@ static struct s5p_hdmi_platform_data
*drm_hdmi_dt_parse_pdata
return NULL;
}
+ of_property_read_u32(np, max-pixel-clock, pd-max_pixel_clock);
+
return pd;
}
@@ -2067,6 +2073,11 @@ static int hdmi_probe(struct platform_device *pdev)
if (!pdata)
return -EINVAL;
+ if (!pdata-max_pixel_clock) {
+ DRM_INFO(max-pixel-clock is zero, using INF\n);
+ pdata-max_pixel_clock = U32_MAX;
+ }
+
hdata = devm_kzalloc(dev, sizeof(struct hdmi_context), GFP_KERNEL);
if (!hdata)
return -ENOMEM;
@@ -2083,6 +2094,7 @@ static int hdmi_probe(struct platform_device *pdev)
hdata-type = drv_data-type;
hdata-hpd_gpio = pdata-hpd_gpio;
+ hdata-max_pixel_clock = pdata-max_pixel_clock;
hdata-dev = dev;
ret = hdmi_resources_init(hdata);
diff --git a/include/media/s5p_hdmi.h b/include/media/s5p_hdmi.h
index 181642b..7272d65 100644
--- a/include/media/s5p_hdmi.h
+++ b/include/media/s5p_hdmi.h
@@ -31,6 +31,7 @@ struct s5p_hdmi_platform_data {
int mhl_bus;
struct i2c_board_info *mhl_info;
int hpd_gpio;
+ u32 max_pixel_clock;
};
#endif /* S5P_HDMI_H */
--
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
[PATCHv2 3/4] drm: exynos: add compatibles for HDMI and Mixer chips and exynos4210 SoC
This patch add proper compatibles for Mixer and HDMI chip
available on exynos4210 SoCs.
Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
---
drivers/gpu/drm/exynos/exynos_hdmi.c |7 +++
drivers/gpu/drm/exynos/exynos_mixer.c |3 +++
2 files changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 47c6e85..2a18f4e 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -204,6 +204,10 @@ struct hdmiphy_config {
u8 conf[32];
};
+struct hdmi_driver_data exynos4210_hdmi_driver_data = {
+ .type = HDMI_TYPE13,
+};
+
struct hdmi_driver_data exynos4212_hdmi_driver_data = {
.type = HDMI_TYPE14,
};
@@ -2032,6 +2036,9 @@ static struct s5p_hdmi_platform_data
*drm_hdmi_dt_parse_pdata
static struct of_device_id hdmi_match_types[] = {
{
+ .compatible = samsung,exynos4210-hdmi,
+ .data = exynos4210_hdmi_driver_data,
+ }, {
.compatible = samsung,exynos5-hdmi,
.data = exynos5_hdmi_driver_data,
}, {
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
b/drivers/gpu/drm/exynos/exynos_mixer.c
index e3306c8..fd8a9a0 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -1187,6 +1187,9 @@ static struct platform_device_id mixer_driver_types[] = {
static struct of_device_id mixer_match_types[] = {
{
+ .compatible = samsung,exynos4210-mixer,
+ .data = exynos4210_mxr_drv_data,
+ }, {
.compatible = samsung,exynos5-mixer,
.data = exynos5250_mxr_drv_data,
}, {
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/6] ARM: EXYNOS: Remove exynos_subsys registration
'exynos_subsys' has no users. Remove this code.
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
---
arch/arm/mach-exynos/exynos.c| 11 ---
arch/arm/plat-samsung/include/plat/cpu.h |1 -
2 files changed, 12 deletions(-)
diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
index b32a907d021d..eb1a431a894a 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -308,17 +308,6 @@ void __init exynos_init_io(void)
exynos_map_io();
}
-struct bus_type exynos_subsys = {
- .name = exynos-core,
- .dev_name = exynos-core,
-};
-
-static int __init exynos_core_init(void)
-{
- return subsys_system_register(exynos_subsys, NULL);
-}
-core_initcall(exynos_core_init);
-
static int __init exynos4_l2x0_cache_init(void)
{
int ret;
diff --git a/arch/arm/plat-samsung/include/plat/cpu.h
b/arch/arm/plat-samsung/include/plat/cpu.h
index 5992b8dd9b89..930b4be832cd 100644
--- a/arch/arm/plat-samsung/include/plat/cpu.h
+++ b/arch/arm/plat-samsung/include/plat/cpu.h
@@ -239,7 +239,6 @@ extern struct bus_type s3c2443_subsys;
extern struct bus_type s3c6410_subsys;
extern struct bus_type s5p64x0_subsys;
extern struct bus_type s5pv210_subsys;
-extern struct bus_type exynos_subsys;
extern void (*s5pc1xx_idle)(void);
--
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 v2 0/6] Further cleanup and enable multiplat build
This series is based on latest linux-next and depends on the following patch: ARM: EXYNOS: Consolidate Kconfig entries http://article.gmane.org/gmane.linux.kernel.samsung-soc/28642 Changes since v2: Replaced patch 2, ARM: EXYNOS: Staticize exynos_subsys with ARM: EXYNOS: Remove exynos_subsys registration as that code is no more used. Tested on Exynos4210, 4412, 5250 and 5420 based boards. Arnd Bergmann (1): ARM: EXYNOS: Enable multi-platform build support Sachin Kamat (5): ARM: EXYNOS: Remove duplicate lines in Makefile ARM: EXYNOS: Remove exynos_subsys registration ARM: EXYNOS: Migrate Exynos specific macros from plat to mach ARM: EXYNOS: Remove unnecessary inclusion of cpu.h ARM: multi_v7_defconfig: Enable Exynos platform arch/arm/Kconfig | 27 ++- arch/arm/configs/exynos_defconfig|2 +- arch/arm/configs/multi_v7_defconfig | 10 + arch/arm/mach-exynos/Kconfig | 27 +++ arch/arm/mach-exynos/Makefile|9 ++-- arch/arm/mach-exynos/common.h| 72 ++ arch/arm/mach-exynos/cpuidle.c |1 - arch/arm/mach-exynos/exynos.c| 13 -- arch/arm/mach-exynos/hotplug.c |2 - arch/arm/mach-exynos/platsmp.c |2 - arch/arm/mach-exynos/pm.c|1 - arch/arm/mach-exynos/pmu.c |2 - arch/arm/plat-samsung/Makefile |3 ++ arch/arm/plat-samsung/include/plat/cpu.h | 61 - 14 files changed, 119 insertions(+), 113 deletions(-) -- 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/6] ARM: EXYNOS: Remove unnecessary inclusion of cpu.h
Exynos specific macros and declarations have been moved to mach-exynos. Inclusion of plat/cpu.h is no more necessary. Signed-off-by: Sachin Kamat sachin.ka...@linaro.org --- arch/arm/mach-exynos/cpuidle.c |1 - arch/arm/mach-exynos/exynos.c |2 -- arch/arm/mach-exynos/hotplug.c |2 -- arch/arm/mach-exynos/platsmp.c |2 -- arch/arm/mach-exynos/pm.c |1 - arch/arm/mach-exynos/pmu.c |2 -- 6 files changed, 10 deletions(-) diff --git a/arch/arm/mach-exynos/cpuidle.c b/arch/arm/mach-exynos/cpuidle.c index c57cae0e8779..3dd385ebf195 100644 --- a/arch/arm/mach-exynos/cpuidle.c +++ b/arch/arm/mach-exynos/cpuidle.c @@ -24,7 +24,6 @@ #include asm/unified.h #include asm/cpuidle.h -#include plat/cpu.h #include plat/pm.h #include mach/map.h diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c index eb1a431a894a..59aab756702e 100644 --- a/arch/arm/mach-exynos/exynos.c +++ b/arch/arm/mach-exynos/exynos.c @@ -26,8 +26,6 @@ #include asm/mach/map.h #include asm/memory.h -#include plat/cpu.h - #include common.h #include mfc.h #include regs-pmu.h diff --git a/arch/arm/mach-exynos/hotplug.c b/arch/arm/mach-exynos/hotplug.c index 5eead530c6f8..884e83cfbfbb 100644 --- a/arch/arm/mach-exynos/hotplug.c +++ b/arch/arm/mach-exynos/hotplug.c @@ -19,8 +19,6 @@ #include asm/cp15.h #include asm/smp_plat.h -#include plat/cpu.h - #include common.h #include regs-pmu.h diff --git a/arch/arm/mach-exynos/platsmp.c b/arch/arm/mach-exynos/platsmp.c index 03e5e9f94705..c28cdb1c82cd 100644 --- a/arch/arm/mach-exynos/platsmp.c +++ b/arch/arm/mach-exynos/platsmp.c @@ -26,8 +26,6 @@ #include asm/smp_scu.h #include asm/firmware.h -#include plat/cpu.h - #include common.h #include regs-pmu.h diff --git a/arch/arm/mach-exynos/pm.c b/arch/arm/mach-exynos/pm.c index 15af0ceb0a66..ca672e24b5cd 100644 --- a/arch/arm/mach-exynos/pm.c +++ b/arch/arm/mach-exynos/pm.c @@ -26,7 +26,6 @@ #include asm/smp_scu.h #include asm/suspend.h -#include plat/cpu.h #include plat/pm-common.h #include plat/pll.h #include plat/regs-srom.h diff --git a/arch/arm/mach-exynos/pmu.c b/arch/arm/mach-exynos/pmu.c index 05c7ce15322a..fb0deda3b3a4 100644 --- a/arch/arm/mach-exynos/pmu.c +++ b/arch/arm/mach-exynos/pmu.c @@ -13,8 +13,6 @@ #include linux/kernel.h #include linux/bug.h -#include plat/cpu.h - #include common.h #include regs-pmu.h -- 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 6/6] ARM: multi_v7_defconfig: Enable Exynos platform
Enable Exynos platform and its related IPs. Signed-off-by: Sachin Kamat sachin.ka...@linaro.org --- arch/arm/configs/multi_v7_defconfig | 10 ++ 1 file changed, 10 insertions(+) diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig index d4e8a47a2f7c..298057a0324c 100644 --- a/arch/arm/configs/multi_v7_defconfig +++ b/arch/arm/configs/multi_v7_defconfig @@ -47,6 +47,7 @@ CONFIG_ARCH_SPEAR13XX=y CONFIG_MACH_SPEAR1310=y CONFIG_MACH_SPEAR1340=y CONFIG_ARCH_STI=y +CONFIG_ARCH_EXYNOS=y CONFIG_ARCH_SUNXI=y CONFIG_ARCH_SIRF=y CONFIG_ARCH_TEGRA=y @@ -71,6 +72,7 @@ CONFIG_PCI_MSI=y CONFIG_PCI_MVEBU=y CONFIG_PCI_TEGRA=y CONFIG_SMP=y +CONFIG_NR_CPUS=8 CONFIG_HIGHPTE=y CONFIG_CMA=y CONFIG_ARM_APPENDED_DTB=y @@ -153,6 +155,8 @@ CONFIG_SERIAL_8250_CONSOLE=y CONFIG_SERIAL_8250_DW=y CONFIG_SERIAL_AMBA_PL011=y CONFIG_SERIAL_AMBA_PL011_CONSOLE=y +CONFIG_SERIAL_SAMSUNG=y +CONFIG_SERIAL_SAMSUNG_CONSOLE=y CONFIG_SERIAL_SIRFSOC=y CONFIG_SERIAL_SIRFSOC_CONSOLE=y CONFIG_SERIAL_TEGRA=y @@ -176,6 +180,7 @@ CONFIG_I2C_MUX=y CONFIG_I2C_MUX_PCA954x=y CONFIG_I2C_MUX_PINCTRL=y CONFIG_I2C_DESIGNWARE_PLATFORM=y +CONFIG_I2C_EXYNOS5=y CONFIG_I2C_MV64XXX=y CONFIG_I2C_SIRF=y CONFIG_I2C_TEGRA=y @@ -210,6 +215,7 @@ CONFIG_MFD_AS3722=y CONFIG_MFD_CROS_EC=y CONFIG_MFD_CROS_EC_SPI=y CONFIG_MFD_MAX8907=y +CONFIG_MFD_SEC_CORE=y CONFIG_MFD_PALMAS=y CONFIG_MFD_TPS65090=y CONFIG_MFD_TPS6586X=y @@ -220,6 +226,8 @@ CONFIG_REGULATOR_AS3722=y CONFIG_REGULATOR_GPIO=y CONFIG_REGULATOR_MAX8907=y CONFIG_REGULATOR_PALMAS=y +CONFIG_REGULATOR_S2MPS11=y +CONFIG_REGULATOR_S5M8767=y CONFIG_REGULATOR_TPS51632=y CONFIG_REGULATOR_TPS62360=y CONFIG_REGULATOR_TPS65090=y @@ -280,6 +288,8 @@ CONFIG_MMC_SDHCI_BCM_KONA=y CONFIG_MMC_OMAP=y CONFIG_MMC_OMAP_HS=y CONFIG_MMC_MVSDIO=y +CONFIG_MMC_DW=y +CONFIG_MMC_DW_EXYNOS=y CONFIG_EDAC=y CONFIG_EDAC_MM_EDAC=y CONFIG_EDAC_HIGHBANK_MC=y -- 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/6] ARM: EXYNOS: Enable multi-platform build support
From: Arnd Bergmann a...@arndb.de This makes it possible to enable the exynos platform as part of a multiplatform kernel, in addition to keeping the single-platform Exynos support. sparsemem is currently not supported in multiplatform. Signed-off-by: Arnd Bergmann a...@arndb.de Signed-off-by: Sachin Kamat sachin.ka...@linaro.org --- arch/arm/Kconfig | 27 +++ arch/arm/configs/exynos_defconfig |2 +- arch/arm/mach-exynos/Kconfig | 27 +++ arch/arm/mach-exynos/Makefile |2 ++ arch/arm/plat-samsung/Makefile|3 +++ 5 files changed, 36 insertions(+), 25 deletions(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 4422601059e8..9d459e9c396b 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -828,34 +828,13 @@ config ARCH_S5PV210 help Samsung S5PV210/S5PC110 series based systems -config ARCH_EXYNOS +config ARCH_EXYNOS_SINGLE bool Samsung EXYNOS - select ARCH_HAS_BANDGAP - select ARCH_HAS_CPUFREQ - select ARCH_HAS_HOLES_MEMORYMODEL - select ARCH_REQUIRE_GPIOLIB + select ARCH_EXYNOS select ARCH_SPARSEMEM_ENABLE - select ARM_AMBA - select ARM_GIC - select CLKSRC_OF - select COMMON_CLK - select CPU_V7 - select GENERIC_CLOCKEVENTS - select HAVE_ARM_SCU if SMP - select HAVE_S3C2410_I2C if I2C - select HAVE_S3C2410_WATCHDOG if WATCHDOG - select HAVE_S3C_RTC if RTC_CLASS - select HAVE_SMP select NEED_MACH_MEMORY_H - select PINCTRL - select PINCTRL_EXYNOS - select PM_GENERIC_DOMAINS if PM_RUNTIME - select S5P_DEV_MFC - select SAMSUNG_DMADEV - select SPARSE_IRQ - select USE_OF help - Support for SAMSUNG's EXYNOS SoCs (EXYNOS4/5) + Support for SAMSUNG EXYNOS SoCs (EXYNOS4/5) config ARCH_DAVINCI bool TI DaVinci diff --git a/arch/arm/configs/exynos_defconfig b/arch/arm/configs/exynos_defconfig index 4ce7b70ea901..103a676256cd 100644 --- a/arch/arm/configs/exynos_defconfig +++ b/arch/arm/configs/exynos_defconfig @@ -7,7 +7,7 @@ CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y # CONFIG_BLK_DEV_BSG is not set CONFIG_PARTITION_ADVANCED=y -CONFIG_ARCH_EXYNOS=y +CONFIG_ARCH_EXYNOS_SINGLE=y CONFIG_S3C_LOWLEVEL_UART_PORT=3 CONFIG_S3C24XX_PWM=y CONFIG_ARCH_EXYNOS5=y diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig index 5c34dc26cec6..bc55af76a05f 100644 --- a/arch/arm/mach-exynos/Kconfig +++ b/arch/arm/mach-exynos/Kconfig @@ -7,6 +7,33 @@ # Configuration options for the EXYNOS4 +config ARCH_EXYNOS + bool Samsung EXYNOS if ARCH_MULTI_V7 + select ARCH_HAS_BANDGAP + select ARCH_HAS_CPUFREQ + select ARCH_HAS_HOLES_MEMORYMODEL + select ARCH_REQUIRE_GPIOLIB + select ARM_AMBA + select ARM_GIC + select CLKSRC_OF + select COMMON_CLK + select CPU_V7 + select GENERIC_CLOCKEVENTS + select HAVE_ARM_SCU if SMP + select HAVE_S3C2410_I2C if I2C + select HAVE_S3C2410_WATCHDOG if WATCHDOG + select HAVE_S3C_RTC if RTC_CLASS + select HAVE_SMP + select PINCTRL + select PINCTRL_EXYNOS + select PM_GENERIC_DOMAINS if PM_RUNTIME + select S5P_DEV_MFC + select SAMSUNG_DMADEV + select SPARSE_IRQ + select USE_OF + help + Support for SAMSUNG EXYNOS SoCs (EXYNOS4/5) + if ARCH_EXYNOS menu SAMSUNG EXYNOS SoCs Support diff --git a/arch/arm/mach-exynos/Makefile b/arch/arm/mach-exynos/Makefile index f6dcc256db56..24a8efe3d4bd 100644 --- a/arch/arm/mach-exynos/Makefile +++ b/arch/arm/mach-exynos/Makefile @@ -5,6 +5,8 @@ # # Licensed under GPLv2 +ccflags-$(CONFIG_ARCH_MULTIPLATFORM) += -I$(srctree)/$(src)/include -I$(srctree)/arch/arm/plat-samsung/include + obj-y := obj-m := obj-n := diff --git a/arch/arm/plat-samsung/Makefile b/arch/arm/plat-samsung/Makefile index 25c826ed3b65..5e5beaa9ae15 100644 --- a/arch/arm/plat-samsung/Makefile +++ b/arch/arm/plat-samsung/Makefile @@ -4,6 +4,9 @@ # # Licensed under GPLv2 +ccflags-$(CONFIG_ARCH_MULTI_V7) += -I$(srctree)/$(src)/include +ccflags-$(CONFIG_ARCH_EXYNOS) += -I$(srctree)/arch/arm/mach-exynos/include + obj-y := obj-m := obj-n := dummy.o -- 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/6] ARM: EXYNOS: Migrate Exynos specific macros from plat to mach
Move Exynos specific macros to mach-exynos from plat-samsung to avoid
unnecessary dependency on plat based header files.
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
---
arch/arm/mach-exynos/common.h| 72 ++
arch/arm/plat-samsung/include/plat/cpu.h | 60 -
2 files changed, 72 insertions(+), 60 deletions(-)
diff --git a/arch/arm/mach-exynos/common.h b/arch/arm/mach-exynos/common.h
index 9ef3f83efaff..c1a2f2207af0 100644
--- a/arch/arm/mach-exynos/common.h
+++ b/arch/arm/mach-exynos/common.h
@@ -15,6 +15,75 @@
#include linux/reboot.h
#include linux/of.h
+#define EXYNOS4210_CPU_ID 0x4321
+#define EXYNOS4212_CPU_ID 0x4322
+#define EXYNOS4412_CPU_ID 0xE4412200
+#define EXYNOS4_CPU_MASK 0xFFFE
+
+#define EXYNOS5250_SOC_ID 0x4352
+#define EXYNOS5420_SOC_ID 0xE542
+#define EXYNOS5440_SOC_ID 0xE544
+#define EXYNOS5_SOC_MASK 0xF000
+
+extern unsigned long samsung_cpu_id;
+
+#define IS_SAMSUNG_CPU(name, id, mask) \
+static inline int is_samsung_##name(void) \
+{ \
+ return ((samsung_cpu_id mask) == (id mask));\
+}
+
+IS_SAMSUNG_CPU(exynos4210, EXYNOS4210_CPU_ID, EXYNOS4_CPU_MASK)
+IS_SAMSUNG_CPU(exynos4212, EXYNOS4212_CPU_ID, EXYNOS4_CPU_MASK)
+IS_SAMSUNG_CPU(exynos4412, EXYNOS4412_CPU_ID, EXYNOS4_CPU_MASK)
+IS_SAMSUNG_CPU(exynos5250, EXYNOS5250_SOC_ID, EXYNOS5_SOC_MASK)
+IS_SAMSUNG_CPU(exynos5420, EXYNOS5420_SOC_ID, EXYNOS5_SOC_MASK)
+IS_SAMSUNG_CPU(exynos5440, EXYNOS5440_SOC_ID, EXYNOS5_SOC_MASK)
+
+#if defined(CONFIG_CPU_EXYNOS4210)
+# define soc_is_exynos4210() is_samsung_exynos4210()
+#else
+# define soc_is_exynos4210() 0
+#endif
+
+#if defined(CONFIG_SOC_EXYNOS4212)
+# define soc_is_exynos4212() is_samsung_exynos4212()
+#else
+# define soc_is_exynos4212() 0
+#endif
+
+#if defined(CONFIG_SOC_EXYNOS4412)
+# define soc_is_exynos4412() is_samsung_exynos4412()
+#else
+# define soc_is_exynos4412() 0
+#endif
+
+#define EXYNOS4210_REV_0 (0x0)
+#define EXYNOS4210_REV_1_0 (0x10)
+#define EXYNOS4210_REV_1_1 (0x11)
+
+#if defined(CONFIG_SOC_EXYNOS5250)
+# define soc_is_exynos5250() is_samsung_exynos5250()
+#else
+# define soc_is_exynos5250() 0
+#endif
+
+#if defined(CONFIG_SOC_EXYNOS5420)
+# define soc_is_exynos5420() is_samsung_exynos5420()
+#else
+# define soc_is_exynos5420() 0
+#endif
+
+#if defined(CONFIG_SOC_EXYNOS5440)
+# define soc_is_exynos5440() is_samsung_exynos5440()
+#else
+# define soc_is_exynos5440() 0
+#endif
+
+#define soc_is_exynos4() (soc_is_exynos4210() || soc_is_exynos4212() || \
+ soc_is_exynos4412())
+#define soc_is_exynos5() (soc_is_exynos5250() || soc_is_exynos5420())
+
void mct_init(void __iomem *base, int irq_g0, int irq_l0, int irq_l1);
struct map_desc;
@@ -63,4 +132,7 @@ struct exynos_pmu_conf {
extern void exynos_sys_powerdown_conf(enum sys_powerdown mode);
+extern void s5p_init_cpu(void __iomem *cpuid_addr);
+extern unsigned int samsung_rev(void);
+
#endif /* __ARCH_ARM_MACH_EXYNOS_COMMON_H */
diff --git a/arch/arm/plat-samsung/include/plat/cpu.h
b/arch/arm/plat-samsung/include/plat/cpu.h
index 930b4be832cd..5a237db9f9eb 100644
--- a/arch/arm/plat-samsung/include/plat/cpu.h
+++ b/arch/arm/plat-samsung/include/plat/cpu.h
@@ -43,16 +43,6 @@ extern unsigned long samsung_cpu_id;
#define S5PV210_CPU_ID 0x4311
#define S5PV210_CPU_MASK 0xF000
-#define EXYNOS4210_CPU_ID 0x4321
-#define EXYNOS4212_CPU_ID 0x4322
-#define EXYNOS4412_CPU_ID 0xE4412200
-#define EXYNOS4_CPU_MASK 0xFFFE
-
-#define EXYNOS5250_SOC_ID 0x4352
-#define EXYNOS5420_SOC_ID 0xE542
-#define EXYNOS5440_SOC_ID 0xE544
-#define EXYNOS5_SOC_MASK 0xF000
-
#define IS_SAMSUNG_CPU(name, id, mask) \
static inline int is_samsung_##name(void) \
{ \
@@ -68,12 +58,6 @@ IS_SAMSUNG_CPU(s5p6440, S5P6440_CPU_ID, S5P64XX_CPU_MASK)
IS_SAMSUNG_CPU(s5p6450, S5P6450_CPU_ID, S5P64XX_CPU_MASK)
IS_SAMSUNG_CPU(s5pc100, S5PC100_CPU_ID, S5PC100_CPU_MASK)
IS_SAMSUNG_CPU(s5pv210, S5PV210_CPU_ID, S5PV210_CPU_MASK)
-IS_SAMSUNG_CPU(exynos4210, EXYNOS4210_CPU_ID, EXYNOS4_CPU_MASK)
-IS_SAMSUNG_CPU(exynos4212, EXYNOS4212_CPU_ID, EXYNOS4_CPU_MASK)
-IS_SAMSUNG_CPU(exynos4412, EXYNOS4412_CPU_ID, EXYNOS4_CPU_MASK)
-IS_SAMSUNG_CPU(exynos5250, EXYNOS5250_SOC_ID, EXYNOS5_SOC_MASK)
-IS_SAMSUNG_CPU(exynos5420, EXYNOS5420_SOC_ID, EXYNOS5_SOC_MASK)
-IS_SAMSUNG_CPU(exynos5440, EXYNOS5440_SOC_ID, EXYNOS5_SOC_MASK)
#if defined(CONFIG_CPU_S3C2410) || defined(CONFIG_CPU_S3C2412) || \
defined(CONFIG_CPU_S3C2416) || defined(CONFIG_CPU_S3C2440) || \
@@ -126,50 +110,6 @@ IS_SAMSUNG_CPU(exynos5440, EXYNOS5440_SOC_ID,
EXYNOS5_SOC_MASK)
# define soc_is_s5pv210() 0
#endif
-#if defined(CONFIG_CPU_EXYNOS4210)
-# define
Re: [RFC PATCH 12/14] ARM: dts: exynos5: add system register support
On 15 April 2014 14:48, Sylwester Nawrocki s.nawro...@samsung.com wrote:
On 15/04/14 10:41, Sachin Kamat wrote:
On 15 April 2014 11:17, YoungJun Cho yj44@samsung.com wrote:
This patch adds sysreg device node, and sysreg property to fimd device node
which is required to use I80 interface.
Signed-off-by: YoungJun Cho yj44@samsung.com
Signed-off-by: Inki Dae inki@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
arch/arm/boot/dts/exynos5.dtsi |6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5.dtsi b/arch/arm/boot/dts/exynos5.dtsi
index 258dca4..f938bbb 100644
--- a/arch/arm/boot/dts/exynos5.dtsi
+++ b/arch/arm/boot/dts/exynos5.dtsi
@@ -88,12 +88,18 @@
status = disabled;
};
+ sys_reg: syscon@1005 {
+ compatible = samsung,exynos5-sysreg, syscon;
Do we really need a separate string for this? Can't we use
samsung,exynos4-sysreg itself?
Currently only syscon is meaningful in Linux, and we add second SoC
specific compatible to be able to distinguish between various SoC
revisions, should any SoC specific quirks be handled in future.
Thus there is no much point in adding samsung,exynos4-sysreg to
exynos5.dtsi. We could as well only leave syscon entry alone.
My suggestion is to keep samsung,exynos5-sysreg, so for instance
Exynos4 and Exynos5 SOC series SYSREG blocks can be identified in
an OS.
Yes, this sounds reasonable.
--
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 04/28] Remove EXYNOS_DEV_SYSMMU
On Mon, 2014-02-10 at 10:02 +0530, Sachin Kamat wrote: +cc linux-samsung-soc list On 10 February 2014 01:38, Paul Bolle pebo...@tiscali.nl wrote: I noted this one about a year ago (see https://lkml.org/lkml/2013/3/5/401 ). By now I wonder whether EXYNOS_IOMMU (and everything depending on it) shouldn't be removed. That code has been unbuildable for at least a year now (I have not checked how much code is involved). Please refer to some on-going discussion about it at [1]. [1] http://thread.gmane.org/gmane.linux.kernel.samsung-soc/26842 It's not clear to me whether an actual decision was eventually made. Olof, does it make sense to rebase the patch (that Sachin linked to) on onto v3.15-rc1 and resubmit? Paul Bolle -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] clocksource: exynos_mct: Fix stall after CPU hotplugging
On piÄ…, 2014-03-28 at 14:06 +0100, Krzysztof Kozlowski wrote:
Fix stall after hotplugging CPU1. Affected are SoCs where Multi Core Timer
interrupts are shared (SPI), e.g. Exynos 4210. The stall was a result of
starting the CPU1 local timer not in L1 timer but in L0 (which is used
by CPU0).
Hi,
Do you have any comments on these 3 patches? They fix the CPU stall on
Exynos4210 and also on Exynos3250 (Chanwoo Choi sent patches for it
recently).
Best regards,
Krzysztof
Trigger:
$ echo 0 /sys/bus/cpu/devices/cpu1/online echo 1
/sys/bus/cpu/devices/cpu1/online
Stall information:
[ 530.045259] INFO: rcu_preempt detected stalls on CPUs/tasks:
[ 530.045618] 1: (6 GPs behind) idle=6d0/0/0 softirq=369/369
[ 530.050987] (detected by 0, t=6589 jiffies, g=33, c=32, q=0)
[ 530.056721] Task dump for CPU 1:
[ 530.059928] swapper/1 R running 0 0 1 0x1000
[ 530.066377] [c0524e14] (__schedule+0x414/0x9b4) from [c00b6610]
(rcu_idle_enter+0x18/0x38)
[ 530.074955] [c00b6610] (rcu_idle_enter+0x18/0x38) from [c0079a18]
(cpu_startup_entry+0x60/0x3bc)
[ 530.084069] [c0079a18] (cpu_startup_entry+0x60/0x3bc) from [c0517d34]
(secondary_start_kernel+0x164/0x1a0)
[ 530.094029] [c0517d34] (secondary_start_kernel+0x164/0x1a0) from
[40517244] (0x40517244)
The timers for CPU1 were missed:
[ 591.668436] cpu: 1
[ 591.670430] clock 0:
[ 591.672691] .base: c0ab7750
[ 591.676160] .index: 0
[ 591.679025] .resolution: 1 nsecs
[ 591.682404] .get_time: ktime_get
[ 591.685970] .offset: 0 nsecs
[ 591.689349] active timers:
[ 591.692045] #0: dfb51f40, hrtimer_wakeup, S:01
[ 591.696759] # expires at 454687834257-454687884257 nsecs [in
-136770537232 to -136770487232 nsecs]
And the event_handler for next event was wrong:
[ 591.917120] Tick Device: mode: 1
[ 591.920676] Per CPU device: 0
[ 591.923621] Clock Event Device: mct_tick0
[ 591.927623] max_delta_ns: 178956969027
[ 591.931613] min_delta_ns: 1249
[ 591.934913] mult: 51539608
[ 591.938557] shift: 32
[ 591.941681] mode: 3
[ 591.944724] next_event: 59502500 nsecs
[ 591.949227] set_next_event: exynos4_tick_set_next_event
[ 591.954522] set_mode: exynos4_tick_set_mode
[ 591.959296] event_handler: hrtimer_interrupt
[ 591.963730] retries:0
[ 591.966761]
[ 591.968245] Tick Device: mode: 0
[ 591.971801] Per CPU device: 1
[ 591.974746] Clock Event Device: mct_tick1
[ 591.978750] max_delta_ns: 178956969027
[ 591.982739] min_delta_ns: 1249
[ 591.986037] mult: 51539608
[ 591.989681] shift: 32
[ 591.992806] mode: 3
[ 591.995848] next_event: 45368500 nsecs
[ 592.000353] set_next_event: exynos4_tick_set_next_event
[ 592.005648] set_mode: exynos4_tick_set_mode
[ 592.010421] event_handler: tick_handle_periodic
[ 592.015115] retries:0
[ 592.018145]
After turning off the CPU1, the MCT L1 local timer was disabled but the
interrupt was not cleared. Turning on the CPU1 enabled the IRQ
with setup_irq() but, before setting affinity to CPU1, the pending L1 timer
interrupt was processed by CPU0 in exynos4_mct_tick_isr().
The ISR then called event handler which set up the next timer event for
current CPU (CPU0). Therefore the MCT L1 timer wasn't actually started.
Fix the stall by:
1. Setting next timer event not on current CPU but on the CPU indicated
by cpumask in 'clock_event_device'.
2. Clearing the timer interrupt upon stopping the local timer.
The patch also moves around the call to exynos4_mct_tick_stop() but this
is done only for the code readability as it is not essential for the fix.
Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
Cc: sta...@vger.kernel.org
---
drivers/clocksource/exynos_mct.c | 33 -
1 file changed, 20 insertions(+), 13 deletions(-)
diff --git a/drivers/clocksource/exynos_mct.c
b/drivers/clocksource/exynos_mct.c
index 48f76bc05da0..0b49b09dd1a9 100644
--- a/drivers/clocksource/exynos_mct.c
+++ b/drivers/clocksource/exynos_mct.c
@@ -339,7 +339,14 @@ static void exynos4_mct_tick_start(unsigned long cycles,
static int exynos4_tick_set_next_event(unsigned long cycles,
struct clock_event_device *evt)
{
- struct mct_clock_event_device *mevt = this_cpu_ptr(percpu_mct_tick);
+ /*
+ * In case of hotplugging non-boot CPU, the set_next_event could be
+ * called on CPU0 by ISR before IRQ affinity is set to proper CPU.
+ * Thus for accessing proper MCT Lx timer, 'per_cpu' for cpumask
+ * in event must be used instead of 'this_cpu_ptr'.
+ */
+ struct mct_clock_event_device *mevt = per_cpu(percpu_mct_tick,
+ cpumask_first(evt-cpumask));
exynos4_mct_tick_start(cycles, mevt);
@@ -371,23 +378,13
Re: [PATCHv2 4/4] drm: exynos: hdmi: add support for pixel clock limitation
Hi Tomasz,
On 15 April 2014 14:57, Tomasz Stanislawski t.stanisl...@samsung.com wrote:
Adds support for limitation of maximal pixel clock of HDMI
signal. This feature is needed on boards that contains
lines or bridges with frequency limitations.
Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
---
.../devicetree/bindings/video/exynos_hdmi.txt |4
drivers/gpu/drm/exynos/exynos_hdmi.c | 12
include/media/s5p_hdmi.h |1 +
3 files changed, 17 insertions(+)
diff --git a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
index f9187a2..8718f8d 100644
--- a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
+++ b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
@@ -28,6 +28,10 @@ Required properties:
- ddc: phandle to the hdmi ddc node
- phy: phandle to the hdmi phy node
+Optional properties:
+- max-pixel-clock: used to limit the maximal pixel clock if a board has
lines,
+ connectors or bridges not capable of carring higher frequencies
+
Example:
hdmi {
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 2a18f4e..404f1b7 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -195,6 +195,7 @@ struct hdmi_context {
struct hdmi_resources res;
int hpd_gpio;
+ u32 max_pixel_clock;
enum hdmi_type type;
};
@@ -887,6 +888,9 @@ static int hdmi_mode_valid(struct drm_connector
*connector,
if (ret)
return MODE_BAD;
+ if (mode-clock * 1000 hdata-max_pixel_clock)
+ return MODE_BAD;
+
ret = hdmi_find_phy_conf(hdata, mode-clock * 1000);
if (ret 0)
return MODE_BAD;
@@ -2031,6 +2035,8 @@ static struct s5p_hdmi_platform_data
*drm_hdmi_dt_parse_pdata
return NULL;
}
+ of_property_read_u32(np, max-pixel-clock, pd-max_pixel_clock);
+
return pd;
}
@@ -2067,6 +2073,11 @@ static int hdmi_probe(struct platform_device *pdev)
if (!pdata)
return -EINVAL;
+ if (!pdata-max_pixel_clock) {
+ DRM_INFO(max-pixel-clock is zero, using INF\n);
+ pdata-max_pixel_clock = U32_MAX;
+ }
+
hdata = devm_kzalloc(dev, sizeof(struct hdmi_context), GFP_KERNEL);
if (!hdata)
return -ENOMEM;
@@ -2083,6 +2094,7 @@ static int hdmi_probe(struct platform_device *pdev)
hdata-type = drv_data-type;
hdata-hpd_gpio = pdata-hpd_gpio;
+ hdata-max_pixel_clock = pdata-max_pixel_clock;
hdata-dev = dev;
ret = hdmi_resources_init(hdata);
diff --git a/include/media/s5p_hdmi.h b/include/media/s5p_hdmi.h
index 181642b..7272d65 100644
--- a/include/media/s5p_hdmi.h
+++ b/include/media/s5p_hdmi.h
@@ -31,6 +31,7 @@ struct s5p_hdmi_platform_data {
int mhl_bus;
struct i2c_board_info *mhl_info;
int hpd_gpio;
+ u32 max_pixel_clock;
};
We have already removed Non DT support from the drm hdmi
driver. IMO we should not be extending the pdata struct.
Regards,
Rahul Sharma
#endif /* S5P_HDMI_H */
--
1.7.9.5
___
dri-devel mailing list
dri-de...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 4/4] drm: exynos: hdmi: add support for pixel clock limitation
Am Dienstag, den 15.04.2014, 11:27 +0200 schrieb Tomasz Stanislawski:
Adds support for limitation of maximal pixel clock of HDMI
signal. This feature is needed on boards that contains
lines or bridges with frequency limitations.
Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
---
.../devicetree/bindings/video/exynos_hdmi.txt |4
drivers/gpu/drm/exynos/exynos_hdmi.c | 12
include/media/s5p_hdmi.h |1 +
3 files changed, 17 insertions(+)
diff --git a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
index f9187a2..8718f8d 100644
--- a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
+++ b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
@@ -28,6 +28,10 @@ Required properties:
- ddc: phandle to the hdmi ddc node
- phy: phandle to the hdmi phy node
+Optional properties:
+- max-pixel-clock: used to limit the maximal pixel clock if a board has
lines,
+ connectors or bridges not capable of carring higher frequencies
+
Example:
hdmi {
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 2a18f4e..404f1b7 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -195,6 +195,7 @@ struct hdmi_context {
struct hdmi_resources res;
int hpd_gpio;
+ u32 max_pixel_clock;
enum hdmi_type type;
};
@@ -887,6 +888,9 @@ static int hdmi_mode_valid(struct drm_connector
*connector,
if (ret)
return MODE_BAD;
+ if (mode-clock * 1000 hdata-max_pixel_clock)
+ return MODE_BAD;
+
This should be MODE_CLOCK_HIGH
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 4/4] regulator: s5m8767: Use same binding for external control as in s2mps11
On 15 April 2014 14:25, Krzysztof Kozlowski k.kozlow...@samsung.com wrote: On wto, 2014-04-15 at 14:02 +0530, Sachin Kamat wrote: On 15 April 2014 13:42, Krzysztof Kozlowski k.kozlow...@samsung.com wrote: On wto, 2014-04-15 at 13:26 +0530, Sachin Kamat wrote: On 15 April 2014 02:41, Mark Brown broo...@kernel.org wrote: On Mon, Apr 14, 2014 at 10:09:09AM +0200, Krzysztof Kozlowski wrote: - - s5m8767,pmic-ext-control-gpios: (optional) GPIO specifier for one + - samsung,ext-control-gpios: (optional) GPIO specifier for one GPIO controlling this regulator (enable/disable); This is valid only for buck9. This is an incompatible change. It's OK to deprecate the old property but it's bad form to just remove it. I agree with Mark. Also, there is no need to make it generic. I thought it would be good to make it consistent and to reduce the number of bindings with same meaning on similar drivers. How about making the other one use s5m8767,pmic-ext-control-gpios compatible instead of introducing a new one? But then we would introduce semi-generic binding with a driver-specific name. We can have a IP specific name (first IP to have this property) common across family of IPs. Anyway more drivers seem to use this kind of binding (tps65090, max8952, da9055, arizona) so maybe there is a point in making this generic? In that case we could but probably not with samsung prefix. -- 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/4] ARM: dts: exynos5250-snow: add tps65090 power regulator
Hi Doug,
On 15 April 2014 04:13, Doug Anderson diand...@chromium.org wrote:
Sachin,
On Mon, Apr 14, 2014 at 6:16 AM, Sachin Kamat sachin.ka...@linaro.org wrote:
From: Doug Anderson diand...@chromium.org
Added TPS65090 regulator related nodes to Snow board.
Signed-off-by: Doug Anderson diand...@chromium.org
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
---
arch/arm/boot/dts/exynos5250-snow.dts | 90
+
1 file changed, 90 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5250-snow.dts
b/arch/arm/boot/dts/exynos5250-snow.dts
index 469c85d..a38fd18 100644
--- a/arch/arm/boot/dts/exynos5250-snow.dts
+++ b/arch/arm/boot/dts/exynos5250-snow.dts
@@ -44,6 +44,13 @@
sd3_bus4: sd3-bus-width4 {
samsung,pin-drv = 0;
};
+
+ tps65090_irq: tps65090-irq {
+ samsung,pins = gpx2-6;
+ samsung,pin-function = 0;
+ samsung,pin-pud = 0;
+ samsung,pin-drv = 0;
+ };
};
pinctrl@1340 {
@@ -75,6 +82,12 @@
};
};
+ vbat: vbat-fixed-regulator {
+ compatible = regulator-fixed;
+ regulator-name = vbat-supply;
+ regulator-boot-on;
+ };
+
i2c-arbitrator {
compatible = i2c-arb-gpio-challenge;
#address-cells = 1;
@@ -201,6 +214,83 @@
0x070c0069;/*
LEFT */
};
};
+
+ power-regulator {
+ compatible = ti,tps65090;
+ reg = 0x48;
+
+ /*
+* Config irq to disable internal pulls
+* even though we run in polling mode.
This comment refers to a feature that hasn't yet been sent upstream.
...but it's a good reminder and I can send it upstream now. You can
see it at:
* https://chromium-review.googlesource.com/62630
* https://chromium-review.googlesource.com/175653
Since this is only a comment I guess it's OK to refer to a feature
that hasn't yet landed (?).
+*/
+ pinctrl-names = default;
+ pinctrl-0 = tps65090_irq;
+
+ vsys1-supply = vbat;
+ vsys2-supply = vbat;
+ vsys3-supply = vbat;
+ infet1-supply = vbat;
+ infet2-supply = vbat;
+ infet3-supply = vbat;
+ infet4-supply = vbat;
+ infet5-supply = vbat;
+ infet6-supply = vbat;
+ infet7-supply = vbat;
+ vsys-l1-supply = vbat;
+ vsys-l2-supply = vbat;
+
+ regulators {
+ dcdc1 {
+ ti,enable-ext-control;
+ };
+ dcdc2 {
+ ti,enable-ext-control;
+ };
+ dcdc3 {
+ ti,enable-ext-control;
+ };
+ fet1 {
+ regulator-name = vcd_led;
+ ti,overcurrent-wait = 3;
This is also referring to something that hasn't been sent upstream yet. See:
* https://chromium-review.googlesource.com/184607
+ };
+ tps65090_fet2: fet2 {
+ regulator-name = video_mid;
+ regulator-always-on;
+ ti,overcurrent-wait = 3;
+ };
+ fet3 {
+ regulator-name = wwan_r;
+ regulator-always-on;
+ ti,overcurrent-wait = 3;
+ };
+ fet4 {
+ regulator-name = sdcard;
+ ti,overcurrent-wait = 3;
+ };
+
Re: [PATCH 08/20] cpufreq: exynos5440: Use cpufreq_for_each_entry macro for iteration
On 15/04/2014 08:44 πμ, Viresh Kumar wrote:
On 15 April 2014 02:39, Stratos Karafotis strat...@semaphore.gr wrote:
diff --git a/drivers/cpufreq/exynos5440-cpufreq.c
b/drivers/cpufreq/exynos5440-cpufreq.c
static void exynos_enable_dvfs(unsigned int cur_frequency)
{
- unsigned int tmp, i, cpu;
+ unsigned int tmp, cpu;
struct cpufreq_frequency_table *freq_table = dvfs_info-freq_table;
+ struct cpufreq_frequency_table *pos;
Merge above two.
Then the line will be 82 characters long.
Do you mind to keep it as is?
Stratos
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2 4/7] mmc: dw_mmc: exynos: incorporate ciu_div into timing property
Hi Jaehoon,
On Mon, April 14, 2014, Jaehoon Chung wrote:
Hi, Seungwon.
On 03/26/2014 08:31 PM, Seungwon Jeon wrote:
ciu_div may not be common value for all speed mode.
So, it needs to be attached to CLKSEL timing.
Signed-off-by: Seungwon Jeon tgih@samsung.com
---
drivers/mmc/host/dw_mmc-exynos.c | 75
++
drivers/mmc/host/dw_mmc-exynos.h |1 +
2 files changed, 53 insertions(+), 23 deletions(-)
diff --git a/drivers/mmc/host/dw_mmc-exynos.c
b/drivers/mmc/host/dw_mmc-exynos.c
index bab97e9..39f9114 100644
--- a/drivers/mmc/host/dw_mmc-exynos.c
+++ b/drivers/mmc/host/dw_mmc-exynos.c
@@ -39,6 +39,7 @@ struct dw_mci_exynos_priv_data {
u8 ciu_div;
u32 sdr_timing;
u32 ddr_timing;
+ u32 hs200_timing;
u32 cur_speed;
};
@@ -64,6 +65,18 @@ static struct dw_mci_exynos_compatible {
},
};
+static inline u8 dw_mci_exynos_get_ciu_div(struct dw_mci *host)
+{
+ struct dw_mci_exynos_priv_data *priv = host-priv;
+
+ if (priv-ctrl_type == DW_MCI_TYPE_EXYNOS4412)
+ return EXYNOS4412_FIXED_CIU_CLK_DIV;
+ else if (priv-ctrl_type == DW_MCI_TYPE_EXYNOS4210)
+ return EXYNOS4210_FIXED_CIU_CLK_DIV;
+ else
+ return SDMMC_CLKSEL_GET_DIV(mci_readl(host, CLKSEL)) + 1;
+}
+
static int dw_mci_exynos_priv_init(struct dw_mci *host)
{
struct dw_mci_exynos_priv_data *priv = host-priv;
@@ -77,6 +90,8 @@ static int dw_mci_exynos_priv_init(struct dw_mci *host)
SDMMC_MPSCTRL_NON_SECURE_WRITE_BIT);
}
+ priv-ciu_div = dw_mci_exynos_get_ciu_div(host);
+
return 0;
}
@@ -84,7 +99,7 @@ static int dw_mci_exynos_setup_clock(struct dw_mci *host)
{
struct dw_mci_exynos_priv_data *priv = host-priv;
- host-bus_hz /= (priv-ciu_div + 1);
+ host-bus_hz /= priv-ciu_div;
return 0;
}
@@ -151,9 +166,10 @@ static void dw_mci_exynos_set_ios(struct dw_mci *host,
struct mmc_ios *ios)
struct dw_mci_exynos_priv_data *priv = host-priv;
unsigned int wanted = ios-clock;
unsigned long actual;
- u8 div = priv-ciu_div + 1;
- if (ios-timing == MMC_TIMING_MMC_DDR52) {
+ if (ios-timing == MMC_TIMING_MMC_HS200) {
+ mci_writel(host, CLKSEL, priv-hs200_timing);
+ } else if (ios-timing == MMC_TIMING_MMC_DDR52) {
mci_writel(host, CLKSEL, priv-ddr_timing);
/* Should be double rate for DDR mode */
if (ios-bus_width == MMC_BUS_WIDTH_8)
@@ -174,6 +190,7 @@ static void dw_mci_exynos_set_ios(struct dw_mci *host,
struct mmc_ios *ios)
wanted = EXYNOS_CCLKIN_MIN;
if (wanted != priv-cur_speed) {
+ u8 div = dw_mci_exynos_get_ciu_div(host);
int ret = clk_set_rate(host-ciu_clk, wanted * div);
if (ret)
dev_warn(host-dev,
@@ -186,14 +203,34 @@ static void dw_mci_exynos_set_ios(struct dw_mci
*host, struct mmc_ios *ios)
}
}
+static int dw_mci_exynos_dt_populate_timing(struct dw_mci *host,
+ unsigned int ctrl_type,
+ const char *propname,
+ u32 *out_values)
+{
+ struct device_node *np = host-dev-of_node;
+ u32 timing[3];
+ int ret;
+
+ ret = of_property_read_u32_array(np, propname, timing, 3);
+ if (ret)
+ return ret;
+
+ if (ctrl_type == DW_MCI_TYPE_EXYNOS4412 ||
+ ctrl_type == DW_MCI_TYPE_EXYNOS4210)
+ timing[2] = 0;
+
+ *out_values = SDMMC_CLKSEL_TIMING(timing[0], timing[1], timing[2]);
+
+ return 0;
+}
+
+
static int dw_mci_exynos_parse_dt(struct dw_mci *host)
{
struct dw_mci_exynos_priv_data *priv;
struct device_node *np = host-dev-of_node;
- u32 timing[2];
- u32 div = 0;
- int idx;
- int ret;
+ int idx, ret;
priv = devm_kzalloc(host-dev, sizeof(*priv), GFP_KERNEL);
if (!priv) {
@@ -206,29 +243,21 @@ static int dw_mci_exynos_parse_dt(struct dw_mci *host)
priv-ctrl_type = exynos_compat[idx].ctrl_type;
}
- if (priv-ctrl_type == DW_MCI_TYPE_EXYNOS4412)
- priv-ciu_div = EXYNOS4412_FIXED_CIU_CLK_DIV - 1;
- else if (priv-ctrl_type == DW_MCI_TYPE_EXYNOS4210)
- priv-ciu_div = EXYNOS4210_FIXED_CIU_CLK_DIV - 1;
- else {
- of_property_read_u32(np, samsung,dw-mshc-ciu-div, div);
- priv-ciu_div = div;
- }
Did you remove the property of ciu-div?
I didn't find anywhere it's used, when this is removed.
Then it needs to remove the properties into device-tree.
And i want to maintain the property of ciu-div.
The related patch has been posted with this.
Re: [PATCH] pata_samsung_cf: fix ata_host_activate() failure handling
Hi, Tejun, could you please also pick this one? Best regards, -- Bartlomiej Zolnierkiewicz Samsung RD Institute Poland Samsung Electronics On Tuesday, April 01, 2014 10:18:46 AM Jingoo Han wrote: On Tuesday, April 01, 2014 2:53 AM, Tejun Heo wrote: Add missing clk_disable() call to ata_host_activate() failure path. Cc: Ben Dooks ben-li...@fluff.org Cc: Kukjin Kim kgene@samsung.com Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com Reviewed-by: Jingoo Han jg1@samsung.com Best regards, Jingoo Han --- drivers/ata/pata_samsung_cf.c | 10 +++--- 1 file changed, 7 insertions(+), 3 deletions(-) Index: b/drivers/ata/pata_samsung_cf.c === --- a/drivers/ata/pata_samsung_cf.c 2014-03-14 16:45:04.344724378 +0100 +++ b/drivers/ata/pata_samsung_cf.c 2014-03-31 18:31:58.083631437 +0200 @@ -594,9 +594,13 @@ static int __init pata_s3c_probe(struct platform_set_drvdata(pdev, host); - return ata_host_activate(host, info-irq, - info-irq ? pata_s3c_irq : NULL, - 0, pata_s3c_sht); + ret = ata_host_activate(host, info-irq, + info-irq ? pata_s3c_irq : NULL, + 0, pata_s3c_sht); + if (ret) + goto stop_clk; + + return 0; stop_clk: clk_disable(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 1/3] clocksource: exynos_mct: Fix stall after CPU hotplugging
On 04/15/2014 11:34 AM, Krzysztof Kozlowski wrote:
On piÄ…, 2014-03-28 at 14:06 +0100, Krzysztof Kozlowski wrote:
Fix stall after hotplugging CPU1. Affected are SoCs where Multi Core Timer
interrupts are shared (SPI), e.g. Exynos 4210. The stall was a result of
starting the CPU1 local timer not in L1 timer but in L0 (which is used
by CPU0).
Hi,
Do you have any comments on these 3 patches? They fix the CPU stall on
Exynos4210 and also on Exynos3250 (Chanwoo Choi sent patches for it
recently).
You describe this issue as impacting different SoC not only the exynos,
right ?
Do you know what other SoCs are impacted by this ?
I guess this issue is not reproducible just with the line below, we need
a timer to expire right at the moment CPU1 is hotplugged, right ?
Trigger:
$ echo 0 /sys/bus/cpu/devices/cpu1/online echo 1
/sys/bus/cpu/devices/cpu1/online
Stall information:
[ 530.045259] INFO: rcu_preempt detected stalls on CPUs/tasks:
[ 530.045618] 1: (6 GPs behind) idle=6d0/0/0 softirq=369/369
[ 530.050987] (detected by 0, t=6589 jiffies, g=33, c=32, q=0)
[ 530.056721] Task dump for CPU 1:
[ 530.059928] swapper/1 R running 0 0 1 0x1000
[ 530.066377] [c0524e14] (__schedule+0x414/0x9b4) from [c00b6610]
(rcu_idle_enter+0x18/0x38)
[ 530.074955] [c00b6610] (rcu_idle_enter+0x18/0x38) from [c0079a18]
(cpu_startup_entry+0x60/0x3bc)
[ 530.084069] [c0079a18] (cpu_startup_entry+0x60/0x3bc) from [c0517d34]
(secondary_start_kernel+0x164/0x1a0)
[ 530.094029] [c0517d34] (secondary_start_kernel+0x164/0x1a0) from
[40517244] (0x40517244)
The timers for CPU1 were missed:
[ 591.668436] cpu: 1
[ 591.670430] clock 0:
[ 591.672691] .base: c0ab7750
[ 591.676160] .index: 0
[ 591.679025] .resolution: 1 nsecs
[ 591.682404] .get_time: ktime_get
[ 591.685970] .offset: 0 nsecs
[ 591.689349] active timers:
[ 591.692045] #0: dfb51f40, hrtimer_wakeup, S:01
[ 591.696759] # expires at 454687834257-454687884257 nsecs [in -136770537232
to -136770487232 nsecs]
And the event_handler for next event was wrong:
[ 591.917120] Tick Device: mode: 1
[ 591.920676] Per CPU device: 0
[ 591.923621] Clock Event Device: mct_tick0
[ 591.927623] max_delta_ns: 178956969027
[ 591.931613] min_delta_ns: 1249
[ 591.934913] mult: 51539608
[ 591.938557] shift: 32
[ 591.941681] mode: 3
[ 591.944724] next_event: 59502500 nsecs
[ 591.949227] set_next_event: exynos4_tick_set_next_event
[ 591.954522] set_mode: exynos4_tick_set_mode
[ 591.959296] event_handler: hrtimer_interrupt
[ 591.963730] retries:0
[ 591.966761]
[ 591.968245] Tick Device: mode: 0
[ 591.971801] Per CPU device: 1
[ 591.974746] Clock Event Device: mct_tick1
[ 591.978750] max_delta_ns: 178956969027
[ 591.982739] min_delta_ns: 1249
[ 591.986037] mult: 51539608
[ 591.989681] shift: 32
[ 591.992806] mode: 3
[ 591.995848] next_event: 45368500 nsecs
[ 592.000353] set_next_event: exynos4_tick_set_next_event
[ 592.005648] set_mode: exynos4_tick_set_mode
[ 592.010421] event_handler: tick_handle_periodic
[ 592.015115] retries:0
[ 592.018145]
After turning off the CPU1, the MCT L1 local timer was disabled but the
interrupt was not cleared. Turning on the CPU1 enabled the IRQ
with setup_irq() but, before setting affinity to CPU1, the pending L1 timer
interrupt was processed by CPU0 in exynos4_mct_tick_isr().
The ISR then called event handler which set up the next timer event for
current CPU (CPU0). Therefore the MCT L1 timer wasn't actually started.
Fix the stall by:
1. Setting next timer event not on current CPU but on the CPU indicated
by cpumask in 'clock_event_device'.
2. Clearing the timer interrupt upon stopping the local timer.
The patch also moves around the call to exynos4_mct_tick_stop() but this
is done only for the code readability as it is not essential for the fix.
Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
Cc: sta...@vger.kernel.org
---
drivers/clocksource/exynos_mct.c | 33 -
1 file changed, 20 insertions(+), 13 deletions(-)
diff --git a/drivers/clocksource/exynos_mct.c b/drivers/clocksource/exynos_mct.c
index 48f76bc05da0..0b49b09dd1a9 100644
--- a/drivers/clocksource/exynos_mct.c
+++ b/drivers/clocksource/exynos_mct.c
@@ -339,7 +339,14 @@ static void exynos4_mct_tick_start(unsigned long cycles,
static int exynos4_tick_set_next_event(unsigned long cycles,
struct clock_event_device *evt)
{
- struct mct_clock_event_device *mevt = this_cpu_ptr(percpu_mct_tick);
+ /*
+* In case of hotplugging non-boot CPU, the set_next_event could be
+* called on CPU0 by ISR before IRQ affinity is set to proper CPU.
+* Thus for accessing proper MCT Lx timer, 'per_cpu' for cpumask
+* in event must be used instead of
Re: [PATCH 1/3] clocksource: exynos_mct: Fix stall after CPU hotplugging
On wto, 2014-04-15 at 14:28 +0200, Daniel Lezcano wrote: On 04/15/2014 11:34 AM, Krzysztof Kozlowski wrote: On piÄ…, 2014-03-28 at 14:06 +0100, Krzysztof Kozlowski wrote: Fix stall after hotplugging CPU1. Affected are SoCs where Multi Core Timer interrupts are shared (SPI), e.g. Exynos 4210. The stall was a result of starting the CPU1 local timer not in L1 timer but in L0 (which is used by CPU0). Hi, Do you have any comments on these 3 patches? They fix the CPU stall on Exynos4210 and also on Exynos3250 (Chanwoo Choi sent patches for it recently). You describe this issue as impacting different SoC not only the exynos, right ? Do you know what other SoCs are impacted by this ? No, affected are only Exynos SoC-s. It was confirmed on Exynos4210 (Trats board) and Exynos3250 (new SoC, patches for it were recently posted by Chanwoo). Other Exynos SoC-s where MCT local timers use shared interrupts (SPI) can also be affected. Candidates are Exynos 5250 and 5420 but I haven't tested them. I guess this issue is not reproducible just with the line below, we need a timer to expire right at the moment CPU1 is hotplugged, right ? Right. The timer must fire in short time between enabling local timer for CPU1 and setting the affinity for IRQ. In my case on ~1 GHz 2 core CPU (during idle state, system booted with init=/bin/sh) it was easily triggered with: for i in `seq 200`; do echo 0 /sys/bus/cpu/devices/cpu1/online echo 1 /sys/bus/cpu/devices/cpu1/online sleep 1 done The stall happened typically after 10-30 seconds of such test. Best regards, Krzysztof Trigger: $ echo 0 /sys/bus/cpu/devices/cpu1/online echo 1 /sys/bus/cpu/devices/cpu1/online Stall information: [ 530.045259] INFO: rcu_preempt detected stalls on CPUs/tasks: [ 530.045618] 1: (6 GPs behind) idle=6d0/0/0 softirq=369/369 [ 530.050987] (detected by 0, t=6589 jiffies, g=33, c=32, q=0) [ 530.056721] Task dump for CPU 1: [ 530.059928] swapper/1 R running 0 0 1 0x1000 [ 530.066377] [c0524e14] (__schedule+0x414/0x9b4) from [c00b6610] (rcu_idle_enter+0x18/0x38) [ 530.074955] [c00b6610] (rcu_idle_enter+0x18/0x38) from [c0079a18] (cpu_startup_entry+0x60/0x3bc) [ 530.084069] [c0079a18] (cpu_startup_entry+0x60/0x3bc) from [c0517d34] (secondary_start_kernel+0x164/0x1a0) [ 530.094029] [c0517d34] (secondary_start_kernel+0x164/0x1a0) from [40517244] (0x40517244) The timers for CPU1 were missed: [ 591.668436] cpu: 1 [ 591.670430] clock 0: [ 591.672691] .base: c0ab7750 [ 591.676160] .index: 0 [ 591.679025] .resolution: 1 nsecs [ 591.682404] .get_time: ktime_get [ 591.685970] .offset: 0 nsecs [ 591.689349] active timers: [ 591.692045] #0: dfb51f40, hrtimer_wakeup, S:01 [ 591.696759] # expires at 454687834257-454687884257 nsecs [in -136770537232 to -136770487232 nsecs] And the event_handler for next event was wrong: [ 591.917120] Tick Device: mode: 1 [ 591.920676] Per CPU device: 0 [ 591.923621] Clock Event Device: mct_tick0 [ 591.927623] max_delta_ns: 178956969027 [ 591.931613] min_delta_ns: 1249 [ 591.934913] mult: 51539608 [ 591.938557] shift: 32 [ 591.941681] mode: 3 [ 591.944724] next_event: 59502500 nsecs [ 591.949227] set_next_event: exynos4_tick_set_next_event [ 591.954522] set_mode: exynos4_tick_set_mode [ 591.959296] event_handler: hrtimer_interrupt [ 591.963730] retries:0 [ 591.966761] [ 591.968245] Tick Device: mode: 0 [ 591.971801] Per CPU device: 1 [ 591.974746] Clock Event Device: mct_tick1 [ 591.978750] max_delta_ns: 178956969027 [ 591.982739] min_delta_ns: 1249 [ 591.986037] mult: 51539608 [ 591.989681] shift: 32 [ 591.992806] mode: 3 [ 591.995848] next_event: 45368500 nsecs [ 592.000353] set_next_event: exynos4_tick_set_next_event [ 592.005648] set_mode: exynos4_tick_set_mode [ 592.010421] event_handler: tick_handle_periodic [ 592.015115] retries:0 [ 592.018145] After turning off the CPU1, the MCT L1 local timer was disabled but the interrupt was not cleared. Turning on the CPU1 enabled the IRQ with setup_irq() but, before setting affinity to CPU1, the pending L1 timer interrupt was processed by CPU0 in exynos4_mct_tick_isr(). The ISR then called event handler which set up the next timer event for current CPU (CPU0). Therefore the MCT L1 timer wasn't actually started. Fix the stall by: 1. Setting next timer event not on current CPU but on the CPU indicated by cpumask in 'clock_event_device'. 2. Clearing the timer interrupt upon stopping the local timer. The patch also moves around the call to exynos4_mct_tick_stop() but this is done only for the code readability as it is not essential for
Re: [PATCH] pata_samsung_cf: fix ata_host_activate() failure handling
On Mon, Mar 31, 2014 at 07:52:44PM +0200, Bartlomiej Zolnierkiewicz wrote: Add missing clk_disable() call to ata_host_activate() failure path. Cc: Ben Dooks ben-li...@fluff.org Cc: Kukjin Kim kgene@samsung.com Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com Applied to libata/for-3.15-fixes. Thanks. -- tejun -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC 3/4] xhci: Tune PHY for the DWC3-Exynos host controller
Hi Heikki,
On Tue, Dec 10, 2013 at 7:25 PM, Heikki Krogerus
heikki.kroge...@linux.intel.com wrote:
Giving life to this thread after long time.
Hi,
On Tue, Dec 10, 2013 at 04:25:25PM +0530, Vivek Gautam wrote:
@@ -170,6 +189,15 @@ static int xhci_plat_probe(struct platform_device *pdev)
}
/*
+ * The parent of the xhci-plat device may pass in a PHY via
+ * platform data. If it exists, store it in our struct usb_hcd
+ * so that we can use it later.
+ */
+ phy_generic = dev_get_platdata(pdev-dev);
+ if (phy_generic)
+ xhci-shared_hcd-phy_generic = *phy_generic;
Getting the handle to the phy from platform data like this is not
going to work for long. It should be possible to get it normally with
phy_get(). It's not going to be possible to get the handle from the
platform data like this if the xhci-hcd platform device is created
from ACPI or DT. You are also not considering case where you have two
phys.
Vivek, I have made a patch set for the phy framework allowing
associations between the phys and their users to be made in same way
gpios and clk make them. With those you should be able to create a
lookup entry to the phy framework in drivers/usb/dwc3/host.c. Then we
could use phy_get() here already. Please check them. Subject of the
thread:
phy: remove the need for the phys to know about their users
I had seen your patches in the mailing list, but i don't see any
updated version of these patches.
Are you planning to work on this above mentioned patch-series any time soon ?
Or, should i try to find a different approach for handling the phy
from the host controller (child of DWC3 in this case, which has the
phys).
The lookup table can then be added in drivers/usb/dwc3/host.c with
something like this:
int dwc3_host_init(struct dwc3 *dwc)
{
struct platform_device *xhci;
struct phy_lookup_table *table;
...
table-dev_id = dev_name(xhci-dev);
if (dwc-usb2_generic_phy)
table-table[0].phy_name =
dev_name(dwc-usb2_generic_phy-dev);
if (dwc-usb3_generic_phy)
table-table[1].phy_name =
dev_name(dwc-usb3_generic_phy-dev);
phy_add_lookup_table(table);
...
--
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 4/4] drm: exynos: hdmi: add support for pixel clock limitation
On 04/15/2014 11:42 AM, Rahul Sharma wrote:
Hi Tomasz,
On 15 April 2014 14:57, Tomasz Stanislawski t.stanisl...@samsung.com wrote:
Adds support for limitation of maximal pixel clock of HDMI
signal. This feature is needed on boards that contains
lines or bridges with frequency limitations.
Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
---
.../devicetree/bindings/video/exynos_hdmi.txt |4
drivers/gpu/drm/exynos/exynos_hdmi.c | 12
include/media/s5p_hdmi.h |1 +
3 files changed, 17 insertions(+)
diff --git a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
index f9187a2..8718f8d 100644
--- a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
+++ b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
@@ -28,6 +28,10 @@ Required properties:
- ddc: phandle to the hdmi ddc node
- phy: phandle to the hdmi phy node
+Optional properties:
+- max-pixel-clock: used to limit the maximal pixel clock if a board has
lines,
+ connectors or bridges not capable of carring higher frequencies
+
Example:
hdmi {
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 2a18f4e..404f1b7 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -195,6 +195,7 @@ struct hdmi_context {
struct hdmi_resources res;
int hpd_gpio;
+ u32 max_pixel_clock;
enum hdmi_type type;
};
@@ -887,6 +888,9 @@ static int hdmi_mode_valid(struct drm_connector
*connector,
if (ret)
return MODE_BAD;
+ if (mode-clock * 1000 hdata-max_pixel_clock)
+ return MODE_BAD;
+
ret = hdmi_find_phy_conf(hdata, mode-clock * 1000);
if (ret 0)
return MODE_BAD;
@@ -2031,6 +2035,8 @@ static struct s5p_hdmi_platform_data
*drm_hdmi_dt_parse_pdata
return NULL;
}
+ of_property_read_u32(np, max-pixel-clock, pd-max_pixel_clock);
+
return pd;
}
@@ -2067,6 +2073,11 @@ static int hdmi_probe(struct platform_device *pdev)
if (!pdata)
return -EINVAL;
+ if (!pdata-max_pixel_clock) {
+ DRM_INFO(max-pixel-clock is zero, using INF\n);
+ pdata-max_pixel_clock = U32_MAX;
+ }
+
hdata = devm_kzalloc(dev, sizeof(struct hdmi_context), GFP_KERNEL);
if (!hdata)
return -ENOMEM;
@@ -2083,6 +2094,7 @@ static int hdmi_probe(struct platform_device *pdev)
hdata-type = drv_data-type;
hdata-hpd_gpio = pdata-hpd_gpio;
+ hdata-max_pixel_clock = pdata-max_pixel_clock;
hdata-dev = dev;
ret = hdmi_resources_init(hdata);
diff --git a/include/media/s5p_hdmi.h b/include/media/s5p_hdmi.h
index 181642b..7272d65 100644
--- a/include/media/s5p_hdmi.h
+++ b/include/media/s5p_hdmi.h
@@ -31,6 +31,7 @@ struct s5p_hdmi_platform_data {
int mhl_bus;
struct i2c_board_info *mhl_info;
int hpd_gpio;
+ u32 max_pixel_clock;
};
We have already removed Non DT support from the drm hdmi
driver. IMO we should not be extending the pdata struct.
Regards,
Rahul Sharma
Hi Rahul,
This is not a non-DT patch. The s5p_hdmi_platform_data is
generated from DT itself. This structure is just
a parsed version of DT attributes.
It may be a good idea to rename s5p_hdmi_platform_data
to exynos_hdmi_pdata and move it to exynos_hdmi_drm.c file
or parse DT directly in probe function.
I can prepare a patch for that.
Regards,
Tomasz Stanislawski
#endif /* S5P_HDMI_H */
--
1.7.9.5
___
dri-devel mailing list
dri-de...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] drm/exynos: balance framebuffer refcount
exynos_drm_crtc_mode_set assigns primary framebuffer to plane without taking reference. Then during framebuffer removal it is dereferenced twice, causing oops. The patch fixes it. Signed-off-by: Andrzej Hajda a.ha...@samsung.com --- Hi, This patch fixes framebuffer refcount balancing. The issue appeared after merge of universal plane related patches. Similar issue affected omap [1]. [1]: http://permalink.gmane.org/gmane.comp.video.dri.devel/104108 Regards Andrzej --- drivers/gpu/drm/exynos/exynos_drm_crtc.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c b/drivers/gpu/drm/exynos/exynos_drm_crtc.c index e930d4f..1ef5ab9 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c @@ -145,6 +145,7 @@ exynos_drm_crtc_mode_set(struct drm_crtc *crtc, struct drm_display_mode *mode, plane-crtc = crtc; plane-fb = crtc-primary-fb; + drm_framebuffer_reference(plane-fb); 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
Re: [PATCHv2 4/4] drm: exynos: hdmi: add support for pixel clock limitation
On 15 April 2014 18:41, Tomasz Stanislawski t.stanisl...@samsung.com wrote:
On 04/15/2014 11:42 AM, Rahul Sharma wrote:
Hi Tomasz,
On 15 April 2014 14:57, Tomasz Stanislawski t.stanisl...@samsung.com wrote:
Adds support for limitation of maximal pixel clock of HDMI
signal. This feature is needed on boards that contains
lines or bridges with frequency limitations.
Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
---
.../devicetree/bindings/video/exynos_hdmi.txt |4
drivers/gpu/drm/exynos/exynos_hdmi.c | 12
include/media/s5p_hdmi.h |1 +
3 files changed, 17 insertions(+)
diff --git a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
index f9187a2..8718f8d 100644
--- a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
+++ b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
@@ -28,6 +28,10 @@ Required properties:
- ddc: phandle to the hdmi ddc node
- phy: phandle to the hdmi phy node
+Optional properties:
+- max-pixel-clock: used to limit the maximal pixel clock if a board has
lines,
+ connectors or bridges not capable of carring higher frequencies
+
Example:
hdmi {
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 2a18f4e..404f1b7 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -195,6 +195,7 @@ struct hdmi_context {
struct hdmi_resources res;
int hpd_gpio;
+ u32 max_pixel_clock;
enum hdmi_type type;
};
@@ -887,6 +888,9 @@ static int hdmi_mode_valid(struct drm_connector
*connector,
if (ret)
return MODE_BAD;
+ if (mode-clock * 1000 hdata-max_pixel_clock)
+ return MODE_BAD;
+
ret = hdmi_find_phy_conf(hdata, mode-clock * 1000);
if (ret 0)
return MODE_BAD;
@@ -2031,6 +2035,8 @@ static struct s5p_hdmi_platform_data
*drm_hdmi_dt_parse_pdata
return NULL;
}
+ of_property_read_u32(np, max-pixel-clock, pd-max_pixel_clock);
+
return pd;
}
@@ -2067,6 +2073,11 @@ static int hdmi_probe(struct platform_device *pdev)
if (!pdata)
return -EINVAL;
+ if (!pdata-max_pixel_clock) {
+ DRM_INFO(max-pixel-clock is zero, using INF\n);
+ pdata-max_pixel_clock = U32_MAX;
+ }
+
hdata = devm_kzalloc(dev, sizeof(struct hdmi_context), GFP_KERNEL);
if (!hdata)
return -ENOMEM;
@@ -2083,6 +2094,7 @@ static int hdmi_probe(struct platform_device *pdev)
hdata-type = drv_data-type;
hdata-hpd_gpio = pdata-hpd_gpio;
+ hdata-max_pixel_clock = pdata-max_pixel_clock;
hdata-dev = dev;
ret = hdmi_resources_init(hdata);
diff --git a/include/media/s5p_hdmi.h b/include/media/s5p_hdmi.h
index 181642b..7272d65 100644
--- a/include/media/s5p_hdmi.h
+++ b/include/media/s5p_hdmi.h
@@ -31,6 +31,7 @@ struct s5p_hdmi_platform_data {
int mhl_bus;
struct i2c_board_info *mhl_info;
int hpd_gpio;
+ u32 max_pixel_clock;
};
We have already removed Non DT support from the drm hdmi
driver. IMO we should not be extending the pdata struct.
Regards,
Rahul Sharma
Hi Rahul,
This is not a non-DT patch. The s5p_hdmi_platform_data is
generated from DT itself. This structure is just
a parsed version of DT attributes.
It may be a good idea to rename s5p_hdmi_platform_data
to exynos_hdmi_pdata and move it to exynos_hdmi_drm.c file
or parse DT directly in probe function.
I can prepare a patch for that.
Else we can completely remove the dependency from
s5p_hdmi_platform_data. We can directly assign to hdmi context
variables. Later we can remove that struct itself from include/.
What you say?
Regards,
Rahul Sharma
Regards,
Tomasz Stanislawski
#endif /* S5P_HDMI_H */
--
1.7.9.5
___
dri-devel mailing list
dri-de...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V4 1/5] phy: Add new Exynos5 USB 3.0 PHY driver
Hi,
On Monday 14 April 2014 07:19 PM, Tomasz Figa wrote:
On 14.04.2014 15:40, Vivek Gautam wrote:
On Mon, Apr 14, 2014 at 6:56 PM, Kishon Vijay Abraham I kis...@ti.com
wrote:
On Monday 14 April 2014 06:50 PM, Vivek Gautam wrote:
On Mon, Apr 14, 2014 at 6:29 PM, Kishon Vijay Abraham I kis...@ti.com
wrote:
On Monday 14 April 2014 06:12 PM, Vivek Gautam wrote:
Hi,
On Mon, Apr 14, 2014 at 5:57 PM, Kishon Vijay Abraham I kis...@ti.com
wrote:
Hi,
On Tuesday 08 April 2014 08:06 PM, Vivek Gautam wrote:
Add a new driver for the USB 3.0 PHY on Exynos5 series of SoCs.
The new driver uses the generic PHY framework and will interact
with DWC3 controller present on Exynos5 series of SoCs.
Thereby, removing old phy-samsung-usb3 driver and related code
used untill now which was based on usb/phy framework.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
.../devicetree/bindings/phy/samsung-phy.txt| 42 ++
drivers/phy/Kconfig| 11 +
drivers/phy/Makefile |1 +
drivers/phy/phy-exynos5-usbdrd.c | 668
4 files changed, 722 insertions(+)
create mode 100644 drivers/phy/phy-exynos5-usbdrd.c
diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt
b/Documentation/devicetree/bindings/phy/samsung-phy.txt
index 28f9edb..6d99ba9 100644
--- a/Documentation/devicetree/bindings/phy/samsung-phy.txt
+++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt
@@ -74,3 +74,45 @@ phy-consumer@1234 {
Refer to DT bindings documentation of particular PHY consumer devices
for more
information about required PHYs and the way of specification.
+
+Samsung Exynos5 SoC series USB DRD PHY controller
+--
+
+Required properties:
+- compatible : Should be set to one of the following supported values:
+ - samsung,exynos5250-usbdrd-phy - for exynos5250 SoC,
+ - samsung,exynos5420-usbdrd-phy - for exynos5420 SoC.
+- reg : Register offset and length of USB DRD PHY register set;
+- clocks: Clock IDs array as required by the controller
+- clock-names: names of clocks correseponding to IDs in the clock
property;
+Required clocks:
+ - phy: main PHY clock (same as USB DRD controller i.e. DWC3 IP
clock),
+used for register access.
+ - ref: PHY's reference clock (usually crystal clock), associated
by
+phy name, used to determine bit values for clock settings
+register.
+ Additional clock required for Exynos5420:
+ - usb30_sclk_100m: Additional special clock used for PHY
operation
+depicted as 'sclk_usbphy30' in CMU of
Exynos5420.
+- samsung,syscon-phandle: phandle for syscon interface, which is used
to
+ control pmu registers for power isolation.
+- samsung,pmu-offset: phy power control register offset to
pmu-system-controller
+ base.
+- #phy-cells : from the generic PHY bindings, must be 1;
+
+For samsung,exynos5250-usbdrd-phy and
samsung,exynos5420-usbdrd-phy
+compatible PHYs, the second cell in the PHY specifier identifies the
+PHY id, which is interpreted as follows:
+ 0 - UTMI+ type phy,
+ 1 - PIPE3 type phy,
+
+Example:
+ usb3_phy: usbphy@1210 {
+ compatible = samsung,exynos5250-usbdrd-phy;
+ reg = 0x1210 0x100;
+ clocks = clock 286, clock 1;
+ clock-names = phy, usb3phy_refclk;
+ samsung,syscon-phandle = pmu_syscon;
+ samsung,pmu-offset = 0x704;
+ #phy-cells = 1;
+ };
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 8d3c49c..d955a05 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -166,4 +166,15 @@ config PHY_XGENE
help
This option enables support for APM X-Gene SoC multi-purpose
PHY.
+config PHY_EXYNOS5_USBDRD
+ tristate Exynos5 SoC series USB DRD PHY driver
+ depends on ARCH_EXYNOS5 OF
+ depends on HAS_IOMEM
+ select GENERIC_PHY
+ select MFD_SYSCON
Lets try to avoid select in Kconfig. We've got enough problems with
that.
I hope you meant with select MFD_SYSCON.
We are referencing the syscon for accessing pmu reg, for which we need
this config to be selected.
Other Exynos phy drivers also need this config and for that they have
selected this.
Do you want me to do it any other way ?
depends on is one option.
Ok, i can see there are places where depends_on MFD_SYSCON is used.
drivers/gpu/drm/exynos/Kconfig:60
so, do you want me to fix at other places too ?
But i also have a question here.
MFD_SYSCON is a subsystem that's facilitating us in getting our work
done here by giving an access to pmu_system_controller.
So unless MFD_SYSCON is exposed, the phy driver will not be exposed to us.
So is that valid enough really ?
maybe in
[PATCH] arm: dts: exynos4412-trats2: rename alias for i2c_ak8975 label
The i2c_ak8975 controler uses label i2c8.
This alias is already used for I2C controller 8 defined
in file arch/arm/boot/dts/exynos4.dtsi.
This patch renames a label for i2c_ak8975 to i2c9.
Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
---
arch/arm/boot/dts/exynos4412-trats2.dts |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts
b/arch/arm/boot/dts/exynos4412-trats2.dts
index c16b315..5add765 100644
--- a/arch/arm/boot/dts/exynos4412-trats2.dts
+++ b/arch/arm/boot/dts/exynos4412-trats2.dts
@@ -20,7 +20,7 @@
compatible = samsung,trats2, samsung,exynos4412, samsung,exynos4;
aliases {
- i2c8 = i2c_ak8975;
+ i2c9 = i2c_ak8975;
};
memory {
--
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 4/4] drm: exynos: hdmi: add support for pixel clock limitation
On 04/15/2014 03:42 PM, Rahul Sharma wrote:
On 15 April 2014 18:41, Tomasz Stanislawski t.stanisl...@samsung.com wrote:
On 04/15/2014 11:42 AM, Rahul Sharma wrote:
Hi Tomasz,
On 15 April 2014 14:57, Tomasz Stanislawski t.stanisl...@samsung.com
wrote:
Adds support for limitation of maximal pixel clock of HDMI
signal. This feature is needed on boards that contains
lines or bridges with frequency limitations.
Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
[snip]
diff --git a/include/media/s5p_hdmi.h b/include/media/s5p_hdmi.h
index 181642b..7272d65 100644
--- a/include/media/s5p_hdmi.h
+++ b/include/media/s5p_hdmi.h
@@ -31,6 +31,7 @@ struct s5p_hdmi_platform_data {
int mhl_bus;
struct i2c_board_info *mhl_info;
int hpd_gpio;
+ u32 max_pixel_clock;
};
We have already removed Non DT support from the drm hdmi
driver. IMO we should not be extending the pdata struct.
Regards,
Rahul Sharma
Hi Rahul,
This is not a non-DT patch. The s5p_hdmi_platform_data is
generated from DT itself. This structure is just
a parsed version of DT attributes.
It may be a good idea to rename s5p_hdmi_platform_data
to exynos_hdmi_pdata and move it to exynos_hdmi_drm.c file
or parse DT directly in probe function.
I can prepare a patch for that.
Else we can completely remove the dependency from
s5p_hdmi_platform_data. We can directly assign to hdmi context
variables. Later we can remove that struct itself from include/.
What you say?
This structure cannot be removed from include yet because it is used by s5p-tv
driver.
However its usage can be removed from both drivers.
I can prepare both.
Regards,
Rahul Sharma
Regards,
Tomasz Stanislawski
Regards,
Tomasz Stanislawski
#endif /* S5P_HDMI_H */
--
1.7.9.5
___
dri-devel mailing list
dri-de...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] clocksource: exynos_mct: Fix stall after CPU hotplugging
On Tue, 15 Apr 2014, Krzysztof Kozlowski wrote:
On wto, 2014-04-15 at 14:28 +0200, Daniel Lezcano wrote:
On 04/15/2014 11:34 AM, Krzysztof Kozlowski wrote:
On piÄ…, 2014-03-28 at 14:06 +0100, Krzysztof Kozlowski wrote:
Fix stall after hotplugging CPU1. Affected are SoCs where Multi Core
Timer
interrupts are shared (SPI), e.g. Exynos 4210. The stall was a result of
starting the CPU1 local timer not in L1 timer but in L0 (which is used
by CPU0).
Hi,
Do you have any comments on these 3 patches? They fix the CPU stall on
Exynos4210 and also on Exynos3250 (Chanwoo Choi sent patches for it
recently).
You describe this issue as impacting different SoC not only the exynos,
right ?
Do you know what other SoCs are impacted by this ?
No, affected are only Exynos SoC-s. It was confirmed on Exynos4210
(Trats board) and Exynos3250 (new SoC, patches for it were recently
posted by Chanwoo).
Other Exynos SoC-s where MCT local timers use shared interrupts (SPI)
can also be affected. Candidates are Exynos 5250 and 5420 but I haven't
tested them.
I guess this issue is not reproducible just with the line below, we need
a timer to expire right at the moment CPU1 is hotplugged, right ?
Right. The timer must fire in short time between enabling local timer
for CPU1 and setting the affinity for IRQ.
Why do you set the affinity in the CPU_ONLINE hotplug callback and not
right away when the interrupt is requested?
Thanks,
tglx
Index: linux-2.6/drivers/clocksource/exynos_mct.c
===
--- linux-2.6.orig/drivers/clocksource/exynos_mct.c
+++ linux-2.6/drivers/clocksource/exynos_mct.c
@@ -430,6 +430,7 @@ static int exynos4_local_timer_setup(str
evt-irq);
return -EIO;
}
+ irq_set_affinity(mct_irqs[MCT_L0_IRQ + cpu], cpumask_of(cpu));
} else {
enable_percpu_irq(mct_irqs[MCT_L0_IRQ], 0);
}
@@ -461,12 +462,6 @@ static int exynos4_mct_cpu_notify(struct
mevt = this_cpu_ptr(percpu_mct_tick);
exynos4_local_timer_setup(mevt-evt);
break;
- case CPU_ONLINE:
- cpu = (unsigned long)hcpu;
- if (mct_int_type == MCT_INT_SPI)
- irq_set_affinity(mct_irqs[MCT_L0_IRQ + cpu],
- cpumask_of(cpu));
- break;
case CPU_DYING:
mevt = this_cpu_ptr(percpu_mct_tick);
exynos4_local_timer_stop(mevt-evt);
Re: [PATCH] Exynos4: cpuidle: support dual CPUs with AFTR state
On 04/15/2014 08:37 AM, Lukasz Majewski wrote:
Hi Daniel,
The following driver is for exynos4210. I did not yet finished the
other boards, so I created a specific driver for 4210 which could be
merged later.
If I may ask - do you plan to develop this code for Exynos4412 in a
near future?
Yes it is in my plan.
I did some tests (with hotplug) and it turns out, that due to static
leakage current one can save up to 12 % of power consumption when power
domains for cores are disabled.
Such notable power consumption reduction could drive (and justify) the
further development of power aware scheduling code.
If you don't have time, then I can offer myself to develop the code. I
just want to avoid potential duplication of effort.
I would be very glad if we can cooperate. Thanks for proposing your help.
I have put a branch containing the cleanups + driver moving + dual cpu
support, so you can base your work in it.
git://git.linaro.org/people/daniel.lezcano/linux.git cpuidle/samsung-next
I am wondering if the 5250 board wouldn't make sense as a primary target
before the 4412...
The driver is based on Colin Cross's driver found at:
https://android.googlesource.com/kernel/exynos/+/e686b1ec67423c40b4fdf811f9a4dfa3b393a010%5E%5E!/
This one was based on a 3.4 kernel and an old API.
It has been refreshed, simplified and based on the recent code
cleanup I sent today.
The AFTR could be entered when all the cpus (except cpu0) are down.
In order to reach this situation, the couple idle states are used.
There is a sync barrier at the entry and the exit of the low power
function. So all cpus will enter and exit the function at the same
time.
At this point, CPU0 knows the other cpu will power down itself. CPU0
waits for the CPU1 to be powered down and then initiate the AFTR
power down sequence.
No interrupts are handled by CPU1, this is why we switch to the timer
broadcast even if the local timer is not impacted by the idle state.
When CPU0 wakes up, it powers up CPU1 and waits for it to boot. Then
they both exit the idle function.
This driver allows the exynos4210 to have the same power consumption
at idle time than the one when we have to unplug CPU1 in order to let
CPU0 to reach the AFTR state.
This patch is a RFC because, we have to find a way to remove the
macros definitions and cpu powerdown function without pulling the
arch dependent headers.
Signed-off-by: Daniel Lezcano daniel.lezc...@linaro.org
---
arch/arm/mach-exynos/common.c| 11 +-
drivers/cpuidle/Kconfig.arm |8 ++
drivers/cpuidle/Makefile |1 +
drivers/cpuidle/cpuidle-exynos4210.c | 226
++ 4 files changed, 245
insertions(+), 1 deletion(-) create mode 100644
drivers/cpuidle/cpuidle-exynos4210.c
diff --git a/arch/arm/mach-exynos/common.c
b/arch/arm/mach-exynos/common.c index d5fa21e..1765a98 100644
--- a/arch/arm/mach-exynos/common.c
+++ b/arch/arm/mach-exynos/common.c
@@ -299,9 +299,18 @@ static struct platform_device exynos_cpuidle = {
.id= -1,
};
+static struct platform_device exynos4210_cpuidle = {
+ .name = exynos4210-cpuidle,
+ .dev.platform_data = exynos_sys_powerdown_aftr,
+ .id= -1,
+};
+
void __init exynos_cpuidle_init(void)
{
- platform_device_register(exynos_cpuidle);
+ if (soc_is_exynos4210())
+ platform_device_register(exynos4210_cpuidle);
+ else
+ platform_device_register(exynos_cpuidle);
}
void __init exynos_cpufreq_init(void)
diff --git a/drivers/cpuidle/Kconfig.arm b/drivers/cpuidle/Kconfig.arm
index 92f0c12..2772130 100644
--- a/drivers/cpuidle/Kconfig.arm
+++ b/drivers/cpuidle/Kconfig.arm
@@ -51,3 +51,11 @@ config ARM_EXYNOS_CPUIDLE
depends on ARCH_EXYNOS
help
Select this to enable cpuidle for Exynos processors
+
+config ARM_EXYNOS4210_CPUIDLE
+ bool Cpu Idle Driver for the Exynos 4210 processor
+ default y
+ depends on ARCH_EXYNOS
+ select ARCH_NEEDS_CPU_IDLE_COUPLED if SMP
+ help
+ Select this to enable cpuidle for the Exynos 4210 processors
diff --git a/drivers/cpuidle/Makefile b/drivers/cpuidle/Makefile
index 0d1540a..e0ec9bc 100644
--- a/drivers/cpuidle/Makefile
+++ b/drivers/cpuidle/Makefile
@@ -14,6 +14,7 @@ obj-$(CONFIG_ARM_ZYNQ_CPUIDLE)+=
cpuidle-zynq.o obj-$(CONFIG_ARM_U8500_CPUIDLE) +=
cpuidle-ux500.o obj-$(CONFIG_ARM_AT91_CPUIDLE) +=
cpuidle-at91.o obj-$(CONFIG_ARM_EXYNOS_CPUIDLE)+=
cpuidle-exynos.o +obj-$(CONFIG_ARM_EXYNOS4210_CPUIDLE)+=
cpuidle-exynos4210.o
###
# POWERPC drivers
diff --git a/drivers/cpuidle/cpuidle-exynos4210.c
b/drivers/cpuidle/cpuidle-exynos4210.c new file mode 100644
index 000..56f6d51
--- /dev/null
+++ b/drivers/cpuidle/cpuidle-exynos4210.c
@@ -0,0 +1,226 @@
+/*
+ * Copyright
Re: [PATCH] Exynos4: cpuidle: support dual CPUs with AFTR state
Hi Daniel,
On 04/15/2014 08:37 AM, Lukasz Majewski wrote:
Hi Daniel,
The following driver is for exynos4210. I did not yet finished the
other boards, so I created a specific driver for 4210 which could
be merged later.
If I may ask - do you plan to develop this code for Exynos4412 in a
near future?
Yes it is in my plan.
I did some tests (with hotplug) and it turns out, that due to static
leakage current one can save up to 12 % of power consumption when
power domains for cores are disabled.
Such notable power consumption reduction could drive (and justify)
the further development of power aware scheduling code.
If you don't have time, then I can offer myself to develop the
code. I just want to avoid potential duplication of effort.
I would be very glad if we can cooperate. Thanks for proposing your
help.
You are welcome :-)
I have put a branch containing the cleanups + driver moving + dual
cpu support, so you can base your work in it.
git://git.linaro.org/people/daniel.lezcano/linux.git
cpuidle/samsung-next
Thanks for sharing code. I will look into it.
I am wondering if the 5250 board wouldn't make sense as a primary
target before the 4412...
I'm working on a device based on 4412, not 5250. Therefore, I would
prefer to have this concept implemented on 4412 as soon as possible to
not hinder my scheduler related experiments.
If you have other priorities, then we can split the work. What do you
think?
The driver is based on Colin Cross's driver found at:
https://android.googlesource.com/kernel/exynos/+/e686b1ec67423c40b4fdf811f9a4dfa3b393a010%5E%5E!/
This one was based on a 3.4 kernel and an old API.
It has been refreshed, simplified and based on the recent code
cleanup I sent today.
The AFTR could be entered when all the cpus (except cpu0) are down.
In order to reach this situation, the couple idle states are used.
There is a sync barrier at the entry and the exit of the low power
function. So all cpus will enter and exit the function at the same
time.
At this point, CPU0 knows the other cpu will power down itself.
CPU0 waits for the CPU1 to be powered down and then initiate the
AFTR power down sequence.
No interrupts are handled by CPU1, this is why we switch to the
timer broadcast even if the local timer is not impacted by the
idle state.
When CPU0 wakes up, it powers up CPU1 and waits for it to boot.
Then they both exit the idle function.
This driver allows the exynos4210 to have the same power
consumption at idle time than the one when we have to unplug CPU1
in order to let CPU0 to reach the AFTR state.
This patch is a RFC because, we have to find a way to remove the
macros definitions and cpu powerdown function without pulling the
arch dependent headers.
Signed-off-by: Daniel Lezcano daniel.lezc...@linaro.org
---
arch/arm/mach-exynos/common.c| 11 +-
drivers/cpuidle/Kconfig.arm |8 ++
drivers/cpuidle/Makefile |1 +
drivers/cpuidle/cpuidle-exynos4210.c | 226
++ 4 files changed, 245
insertions(+), 1 deletion(-) create mode 100644
drivers/cpuidle/cpuidle-exynos4210.c
diff --git a/arch/arm/mach-exynos/common.c
b/arch/arm/mach-exynos/common.c index d5fa21e..1765a98 100644
--- a/arch/arm/mach-exynos/common.c
+++ b/arch/arm/mach-exynos/common.c
@@ -299,9 +299,18 @@ static struct platform_device exynos_cpuidle
= { .id= -1,
};
+static struct platform_device exynos4210_cpuidle = {
+ .name = exynos4210-cpuidle,
+ .dev.platform_data = exynos_sys_powerdown_aftr,
+ .id= -1,
+};
+
void __init exynos_cpuidle_init(void)
{
- platform_device_register(exynos_cpuidle);
+ if (soc_is_exynos4210())
+ platform_device_register(exynos4210_cpuidle);
+ else
+ platform_device_register(exynos_cpuidle);
}
void __init exynos_cpufreq_init(void)
diff --git a/drivers/cpuidle/Kconfig.arm
b/drivers/cpuidle/Kconfig.arm index 92f0c12..2772130 100644
--- a/drivers/cpuidle/Kconfig.arm
+++ b/drivers/cpuidle/Kconfig.arm
@@ -51,3 +51,11 @@ config ARM_EXYNOS_CPUIDLE
depends on ARCH_EXYNOS
help
Select this to enable cpuidle for Exynos processors
+
+config ARM_EXYNOS4210_CPUIDLE
+ bool Cpu Idle Driver for the Exynos 4210 processor
+ default y
+ depends on ARCH_EXYNOS
+ select ARCH_NEEDS_CPU_IDLE_COUPLED if SMP
+ help
+ Select this to enable cpuidle for the Exynos 4210
processors diff --git a/drivers/cpuidle/Makefile
b/drivers/cpuidle/Makefile index 0d1540a..e0ec9bc 100644
--- a/drivers/cpuidle/Makefile
+++ b/drivers/cpuidle/Makefile
@@ -14,6 +14,7 @@ obj-$(CONFIG_ARM_ZYNQ_CPUIDLE)+=
cpuidle-zynq.o obj-$(CONFIG_ARM_U8500_CPUIDLE)
Re: [PATCH 1/3] clocksource: exynos_mct: Fix stall after CPU hotplugging
On wto, 2014-04-15 at 17:20 +0200, Thomas Gleixner wrote:
On Tue, 15 Apr 2014, Krzysztof Kozlowski wrote:
On wto, 2014-04-15 at 14:28 +0200, Daniel Lezcano wrote:
On 04/15/2014 11:34 AM, Krzysztof Kozlowski wrote:
On piÄ…, 2014-03-28 at 14:06 +0100, Krzysztof Kozlowski wrote:
Fix stall after hotplugging CPU1. Affected are SoCs where Multi Core
Timer
interrupts are shared (SPI), e.g. Exynos 4210. The stall was a result
of
starting the CPU1 local timer not in L1 timer but in L0 (which is used
by CPU0).
Hi,
Do you have any comments on these 3 patches? They fix the CPU stall on
Exynos4210 and also on Exynos3250 (Chanwoo Choi sent patches for it
recently).
You describe this issue as impacting different SoC not only the exynos,
right ?
Do you know what other SoCs are impacted by this ?
No, affected are only Exynos SoC-s. It was confirmed on Exynos4210
(Trats board) and Exynos3250 (new SoC, patches for it were recently
posted by Chanwoo).
Other Exynos SoC-s where MCT local timers use shared interrupts (SPI)
can also be affected. Candidates are Exynos 5250 and 5420 but I haven't
tested them.
I guess this issue is not reproducible just with the line below, we need
a timer to expire right at the moment CPU1 is hotplugged, right ?
Right. The timer must fire in short time between enabling local timer
for CPU1 and setting the affinity for IRQ.
Why do you set the affinity in the CPU_ONLINE hotplug callback and not
right away when the interrupt is requested?
Hi,
I think the problem in such code is in GIC. The gic_set_affinity() uses
cpu_online_mask:
unsigned int cpu = cpumask_any_and(mask_val, cpu_online_mask);
In that time this CPU is not present in that mask so -EINVAL would be
returned.
The stall occurred also on 3.10 where the IRQ affinity is set just after
setup_irq():
if (cpu == 0) {
mct_tick0_event_irq.dev_id = mevt;
evt-irq = mct_irqs[MCT_L0_IRQ];
setup_irq(evt-irq, mct_tick0_event_irq);
} else {
mct_tick1_event_irq.dev_id = mevt;
evt-irq = mct_irqs[MCT_L1_IRQ];
setup_irq(evt-irq, mct_tick1_event_irq);
irq_set_affinity(evt-irq, cpumask_of(1));
}
Best regards,
Krzysztof
Thanks,
tglx
Index: linux-2.6/drivers/clocksource/exynos_mct.c
===
--- linux-2.6.orig/drivers/clocksource/exynos_mct.c
+++ linux-2.6/drivers/clocksource/exynos_mct.c
@@ -430,6 +430,7 @@ static int exynos4_local_timer_setup(str
evt-irq);
return -EIO;
}
+ irq_set_affinity(mct_irqs[MCT_L0_IRQ + cpu], cpumask_of(cpu));
} else {
enable_percpu_irq(mct_irqs[MCT_L0_IRQ], 0);
}
@@ -461,12 +462,6 @@ static int exynos4_mct_cpu_notify(struct
mevt = this_cpu_ptr(percpu_mct_tick);
exynos4_local_timer_setup(mevt-evt);
break;
- case CPU_ONLINE:
- cpu = (unsigned long)hcpu;
- if (mct_int_type == MCT_INT_SPI)
- irq_set_affinity(mct_irqs[MCT_L0_IRQ + cpu],
- cpumask_of(cpu));
- break;
case CPU_DYING:
mevt = this_cpu_ptr(percpu_mct_tick);
exynos4_local_timer_stop(mevt-evt);
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] clocksource: exynos_mct: Fix stall after CPU hotplugging
B1;3202;0cOn Tue, 15 Apr 2014, Krzysztof Kozlowski wrote:
On wto, 2014-04-15 at 17:20 +0200, Thomas Gleixner wrote:
On Tue, 15 Apr 2014, Krzysztof Kozlowski wrote:
On wto, 2014-04-15 at 14:28 +0200, Daniel Lezcano wrote:
On 04/15/2014 11:34 AM, Krzysztof Kozlowski wrote:
On piÄ…, 2014-03-28 at 14:06 +0100, Krzysztof Kozlowski wrote:
Fix stall after hotplugging CPU1. Affected are SoCs where Multi Core
Timer
interrupts are shared (SPI), e.g. Exynos 4210. The stall was a
result of
starting the CPU1 local timer not in L1 timer but in L0 (which is
used
by CPU0).
Hi,
Do you have any comments on these 3 patches? They fix the CPU stall on
Exynos4210 and also on Exynos3250 (Chanwoo Choi sent patches for it
recently).
You describe this issue as impacting different SoC not only the exynos,
right ?
Do you know what other SoCs are impacted by this ?
No, affected are only Exynos SoC-s. It was confirmed on Exynos4210
(Trats board) and Exynos3250 (new SoC, patches for it were recently
posted by Chanwoo).
Other Exynos SoC-s where MCT local timers use shared interrupts (SPI)
can also be affected. Candidates are Exynos 5250 and 5420 but I haven't
tested them.
I guess this issue is not reproducible just with the line below, we
need
a timer to expire right at the moment CPU1 is hotplugged, right ?
Right. The timer must fire in short time between enabling local timer
for CPU1 and setting the affinity for IRQ.
Why do you set the affinity in the CPU_ONLINE hotplug callback and not
right away when the interrupt is requested?
Hi,
I think the problem in such code is in GIC. The gic_set_affinity() uses
cpu_online_mask:
unsigned int cpu = cpumask_any_and(mask_val, cpu_online_mask);
In that time this CPU is not present in that mask so -EINVAL would be
returned.
Hmm, indeed. Stupid me.
Here is a complete solution to the problem. We really want the drivers
to be fast and clean and not work around such issues.
I'm quite happy that I kept the 'force' argument of set_affinity
callbacks. I knew that I'd need it at some point.
So with the flag set we can disable the online mask check and force
the interrupt to the proper cpu.
Thanks,
tglx
Index: linux-2.6/drivers/clocksource/exynos_mct.c
===
--- linux-2.6.orig/drivers/clocksource/exynos_mct.c
+++ linux-2.6/drivers/clocksource/exynos_mct.c
@@ -430,6 +430,7 @@ static int exynos4_local_timer_setup(str
evt-irq);
return -EIO;
}
+ irq_force_affinity(mct_irqs[MCT_L0_IRQ + cpu], cpumask_of(cpu));
} else {
enable_percpu_irq(mct_irqs[MCT_L0_IRQ], 0);
}
@@ -461,12 +462,6 @@ static int exynos4_mct_cpu_notify(struct
mevt = this_cpu_ptr(percpu_mct_tick);
exynos4_local_timer_setup(mevt-evt);
break;
- case CPU_ONLINE:
- cpu = (unsigned long)hcpu;
- if (mct_int_type == MCT_INT_SPI)
- irq_set_affinity(mct_irqs[MCT_L0_IRQ + cpu],
- cpumask_of(cpu));
- break;
case CPU_DYING:
mevt = this_cpu_ptr(percpu_mct_tick);
exynos4_local_timer_stop(mevt-evt);
Index: linux-2.6/drivers/irqchip/irq-gic.c
===
--- linux-2.6.orig/drivers/irqchip/irq-gic.c
+++ linux-2.6/drivers/irqchip/irq-gic.c
@@ -246,10 +246,14 @@ static int gic_set_affinity(struct irq_d
bool force)
{
void __iomem *reg = gic_dist_base(d) + GIC_DIST_TARGET + (gic_irq(d)
~3);
- unsigned int shift = (gic_irq(d) % 4) * 8;
- unsigned int cpu = cpumask_any_and(mask_val, cpu_online_mask);
+ unsigned int cpu, shift = (gic_irq(d) % 4) * 8;
u32 val, mask, bit;
+ if (!force)
+ cpu = cpumask_any_and(mask_val, cpu_online_mask);
+ else
+ cpu = cpumask_first(mask_val);
+
if (cpu = NR_GIC_CPU_IF || cpu = nr_cpu_ids)
return -EINVAL;
Index: linux-2.6/include/linux/interrupt.h
===
--- linux-2.6.orig/include/linux/interrupt.h
+++ linux-2.6/include/linux/interrupt.h
@@ -204,6 +204,7 @@ static inline int check_wakeup_irqs(void
extern cpumask_var_t irq_default_affinity;
extern int irq_set_affinity(unsigned int irq, const struct cpumask *cpumask);
+extern int irq_force_affinity(unsigned int irq, const struct cpumask *cpumask);
extern int irq_can_set_affinity(unsigned int irq);
extern int irq_select_affinity(unsigned int irq);
Index: linux-2.6/kernel/irq/manage.c
===
---
[PATCH] clk: exynos4: Use single clock ID for CLK_MDMA gate clocks
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_LITE0 353 /* Exynos4x12 only */
--
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] Exynos4: cpuidle: support dual CPUs with AFTR state
On 04/15/2014 05:54 PM, Lukasz Majewski wrote:
Hi Daniel,
On 04/15/2014 08:37 AM, Lukasz Majewski wrote:
Hi Daniel,
The following driver is for exynos4210. I did not yet finished the
other boards, so I created a specific driver for 4210 which could
be merged later.
If I may ask - do you plan to develop this code for Exynos4412 in a
near future?
Yes it is in my plan.
I did some tests (with hotplug) and it turns out, that due to static
leakage current one can save up to 12 % of power consumption when
power domains for cores are disabled.
Such notable power consumption reduction could drive (and justify)
the further development of power aware scheduling code.
If you don't have time, then I can offer myself to develop the
code. I just want to avoid potential duplication of effort.
I would be very glad if we can cooperate. Thanks for proposing your
help.
You are welcome :-)
I have put a branch containing the cleanups + driver moving + dual
cpu support, so you can base your work in it.
git://git.linaro.org/people/daniel.lezcano/linux.git
cpuidle/samsung-next
Thanks for sharing code. I will look into it.
I am wondering if the 5250 board wouldn't make sense as a primary
target before the 4412...
I'm working on a device based on 4412, not 5250. Therefore, I would
prefer to have this concept implemented on 4412 as soon as possible to
not hinder my scheduler related experiments.
If you have other priorities, then we can split the work. What do you
think?
It is ok for me if you want to handle the cpuidle driver 4412. Will you
create a new driver or extend this dual cpu driver to support 4 cpus ?
The driver is based on Colin Cross's driver found at:
https://android.googlesource.com/kernel/exynos/+/e686b1ec67423c40b4fdf811f9a4dfa3b393a010%5E%5E!/
This one was based on a 3.4 kernel and an old API.
It has been refreshed, simplified and based on the recent code
cleanup I sent today.
The AFTR could be entered when all the cpus (except cpu0) are down.
In order to reach this situation, the couple idle states are used.
There is a sync barrier at the entry and the exit of the low power
function. So all cpus will enter and exit the function at the same
time.
At this point, CPU0 knows the other cpu will power down itself.
CPU0 waits for the CPU1 to be powered down and then initiate the
AFTR power down sequence.
No interrupts are handled by CPU1, this is why we switch to the
timer broadcast even if the local timer is not impacted by the
idle state.
When CPU0 wakes up, it powers up CPU1 and waits for it to boot.
Then they both exit the idle function.
This driver allows the exynos4210 to have the same power
consumption at idle time than the one when we have to unplug CPU1
in order to let CPU0 to reach the AFTR state.
This patch is a RFC because, we have to find a way to remove the
macros definitions and cpu powerdown function without pulling the
arch dependent headers.
Signed-off-by: Daniel Lezcano daniel.lezc...@linaro.org
---
arch/arm/mach-exynos/common.c| 11 +-
drivers/cpuidle/Kconfig.arm |8 ++
drivers/cpuidle/Makefile |1 +
drivers/cpuidle/cpuidle-exynos4210.c | 226
++ 4 files changed, 245
insertions(+), 1 deletion(-) create mode 100644
drivers/cpuidle/cpuidle-exynos4210.c
diff --git a/arch/arm/mach-exynos/common.c
b/arch/arm/mach-exynos/common.c index d5fa21e..1765a98 100644
--- a/arch/arm/mach-exynos/common.c
+++ b/arch/arm/mach-exynos/common.c
@@ -299,9 +299,18 @@ static struct platform_device exynos_cpuidle
= { .id= -1,
};
+static struct platform_device exynos4210_cpuidle = {
+ .name = exynos4210-cpuidle,
+ .dev.platform_data = exynos_sys_powerdown_aftr,
+ .id= -1,
+};
+
void __init exynos_cpuidle_init(void)
{
- platform_device_register(exynos_cpuidle);
+ if (soc_is_exynos4210())
+ platform_device_register(exynos4210_cpuidle);
+ else
+ platform_device_register(exynos_cpuidle);
}
void __init exynos_cpufreq_init(void)
diff --git a/drivers/cpuidle/Kconfig.arm
b/drivers/cpuidle/Kconfig.arm index 92f0c12..2772130 100644
--- a/drivers/cpuidle/Kconfig.arm
+++ b/drivers/cpuidle/Kconfig.arm
@@ -51,3 +51,11 @@ config ARM_EXYNOS_CPUIDLE
depends on ARCH_EXYNOS
help
Select this to enable cpuidle for Exynos processors
+
+config ARM_EXYNOS4210_CPUIDLE
+ bool Cpu Idle Driver for the Exynos 4210 processor
+ default y
+ depends on ARCH_EXYNOS
+ select ARCH_NEEDS_CPU_IDLE_COUPLED if SMP
+ help
+ Select this to enable cpuidle for the Exynos 4210
processors diff --git a/drivers/cpuidle/Makefile
b/drivers/cpuidle/Makefile index 0d1540a..e0ec9bc 100644
--- a/drivers/cpuidle/Makefile
+++ b/drivers/cpuidle/Makefile
@@ -14,6 +14,7 @@ obj-$(CONFIG_ARM_ZYNQ_CPUIDLE)+=
cpuidle-zynq.o
Re: [PATCH] clk: exynos4: Use single clock ID for CLK_MDMA gate clocks
Hi Sylwester,
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 */
Looks good, will apply. Thanks.
Best regards,
Tomasz
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/7] clk: exynos5420: Add more clock register offsets
Hi Shaik, On 27.03.2014 12:07, Shaik Ameer Basha wrote: From: Rahul Sharma rahul.sha...@samsung.com This patch adds the missing clock register offsets for Exynos5420. Signed-off-by: Rahul Sharma rahul.sha...@samsung.com Signed-off-by: Shaik Ameer Basha shaik.am...@samsung.com --- drivers/clk/samsung/clk-exynos5420.c | 29 - 1 file changed, 28 insertions(+), 1 deletion(-) diff --git a/drivers/clk/samsung/clk-exynos5420.c b/drivers/clk/samsung/clk-exynos5420.c index 13f624d..3d0fb77 100644 --- a/drivers/clk/samsung/clk-exynos5420.c +++ b/drivers/clk/samsung/clk-exynos5420.c @@ -27,6 +27,9 @@ #define DIV_CPU1 0x504 #define GATE_BUS_CPU 0x700 #define GATE_SCLK_CPU 0x800 +#define CLKOUT_CMU_CPU 0xa00 +#define DIV_G2D0x8500 +#define GATE_BUS_G2D 0x8700 #define GATE_IP_G2D 0x8800 #define CPLL_LOCK 0x10020 #define DPLL_LOCK 0x10030 @@ -39,7 +42,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 @@ -57,10 +64,13 @@ #define SRC_FSYS 0x10244 #define SRC_PERIC00x10250 #define SRC_PERIC10x10254 +#define SRC_ISP0x10270 #define SRC_TOP10 0x10280 #define SRC_TOP11 0x10284 #define SRC_TOP12 0x10288 -#defineSRC_MASK_DISP10 0x1032c +#define SRC_MASK_TOP2 0x10308 +#define SRC_MASK_DISP100x1032c +#define SRC_MASK_MAU 0x10334 #define SRC_MASK_FSYS 0x10340 #define SRC_MASK_PERIC0 0x10350 #define SRC_MASK_PERIC1 0x10354 @@ -77,24 +87,41 @@ #define DIV_PERIC20x10560 #define DIV_PERIC30x10564 #define DIV_PERIC40x10568 +#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_GSCL0 0x10710 +#define GATE_BUS_GSCL1 0x10720 +#define GATE_BUS_DISP1 0x10728 +#define GATE_BUS_MFC 0x10734 +#define GATE_BUS_GEN 0x1073c #define GATE_BUS_FSYS00x10740 +#define GATE_BUS_FSYS2 0x10748 +#define GATE_BUS_MSCL 0x1074C #define GATE_BUS_PERIC0x10750 #define GATE_BUS_PERIC1 0x10754 #define GATE_BUS_PERIS0 0x10760 #define GATE_BUS_PERIS1 0x10764 +#define GATE_BUS_NOC 0x10770 +#define GATE_TOP_SCLK_ISP 0x10870 #define GATE_IP_GSCL0 0x10910 #define GATE_IP_GSCL1 0x10920 #define GATE_IP_MFC 0x1092c #define GATE_IP_DISP1 0x10928 #define GATE_IP_G3D 0x10930 #define GATE_IP_GEN 0x10934 +#define GATE_IP_FSYS 0x10944 +#define GATE_IP_PERIC 0x10950 +#define GATE_IP_PERIS 0x10960 #define GATE_IP_MSCL 0x10970 #define GATE_TOP_SCLK_GSCL0x10820 #define GATE_TOP_SCLK_DISP1 0x10828 #define GATE_TOP_SCLK_MAU 0x1083c #define GATE_TOP_SCLK_FSYS0x10840 #define GATE_TOP_SCLK_PERIC 0x10850 +#define TOP_SPARE2 0x10b08 #define BPLL_LOCK 0x20010 #define BPLL_CON0 0x20110 #define SRC_CDREX 0x20200 From this patch, it's hard to tell what is the use for those registers. I think they should be added along with definitions that need them. Best regards, Tomasz -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/7] clk: exynos5420: Add more clock IDs
Hi Shaik, On 27.03.2014 12:07, Shaik Ameer Basha wrote: From: Rahul Sharma rahul.sha...@samsung.com Add more clock IDs to be used in DT bindings for Exynos5420. Signed-off-by: Rahul Sharma rahul.sha...@samsung.com Signed-off-by: Shaik Ameer Basha shaik.am...@samsung.com --- include/dt-bindings/clock/exynos5420.h | 62 ++-- 1 file changed, 60 insertions(+), 2 deletions(-) diff --git a/include/dt-bindings/clock/exynos5420.h b/include/dt-bindings/clock/exynos5420.h index 5eefd88..e921913 100644 --- a/include/dt-bindings/clock/exynos5420.h +++ b/include/dt-bindings/clock/exynos5420.h @@ -58,6 +58,16 @@ #define CLK_SCLK_GSCL_WA 156 #define CLK_SCLK_GSCL_WB 157 #define CLK_SCLK_HDMIPHY 158 +#define CLK_SCLK_MPHY_REFCLK 159 +#define CLK_SCLK_SPI0_ISP 160 +#define CLK_SCLK_SPI1_ISP 161 +#define CLK_SCLK_UART_ISP 162 +#define CLK_SCLK_ISP_SENSOR0 163 +#define CLK_SCLK_ISP_SENSOR1 164 +#define CLK_SCLK_ISP_SENSOR2 165 +#define CLK_SCLK_PWM_ISP 166 +#define CLK_SCLK_HSIC_12M 167 +#define CLK_SCLK_MPHY_IXTAL24 168 /* gate clocks */ #define CLK_ACLK66_PERIC 256 @@ -123,6 +133,7 @@ #define CLK_USBH20365 #define CLK_USBD300 366 #define CLK_USBD301 367 +#define CLK_PCLK200_FSYS 370 #define CLK_ACLK400_MSCL 380 #define CLK_MSCL0 381 #define CLK_MSCL1 382 @@ -141,6 +152,8 @@ #define CLK_ACLK300_DISP1 420 #define CLK_FIMD1 421 #define CLK_SMMU_FIMD1422 +#define CLK_SMMU_FIMD1M1 423 +#define CLK_ACLK400_DISP1 424 #define CLK_ACLK166 430 #define CLK_MIXER 431 #define CLK_ACLK266 440 @@ -172,12 +185,57 @@ #define CLK_SMMU_FIMCL1 493 #define CLK_SMMU_FIMCL3 494 #define CLK_FIMC_LITE3495 -#define CLK_ACLK_G3D 500 -#define CLK_G3D501 +#define CLK_G3D500 What is the reason for this ID change? Even if CLK_ACLK_G3D is removed, as it wasn't even referenced by the driver, original clock IDs should remain fixed. #define CLK_SMMU_MIXER502 +#define CLK_PCLK_TZPC10503 +#define CLK_PCLK_TZPC11504 +#define CLK_PCLK_MC505 +#define CLK_PCLK_TOP_RTC 506 +#define CLK_SMMU_JPEG2 507 +#define CLK_PCLK_ROTATOR 508 +#define CLK_SMMU_RTIC 509 +#define CLK_PCLK_G2D 510 +#define CLK_ACLK_SMMU_G2D 511 +#define CLK_SMMU_G2D 512 +#define CLK_ACLK_SMMU_MDMA0513 +#define CLK_SMMU_MDMA0 514 +#define CLK_ACLK_SMMU_SSS 515 +#define CLK_SMMU_SSS 516 +#define CLK_SMMU_SLIM_SSS 517 +#define CLK_ACLK_SMMU_SLIM_SSS 518 +#define CLK_ACLK266_ISP519 +#define CLK_ACLK400_ISP520 +#define CLK_ACLK333_432_ISP0 521 +#define CLK_ACLK333_432_ISP522 +#define CLK_ACLK_SMMU_MIXER523 +#define CLK_PCLK_HDMIPHY 524 +#define CLK_PCLK_GSCL0 525 +#define CLK_PCLK_GSCL1 526 +#define CLK_PCLK_FIMC_3AA 527 +#define CLK_ACLK_FIMC_LITE0528 +#define CLK_ACLK_FIMC_LITE1529 +#define CLK_PCLK_FIMC_LITE0530 +#define CLK_PCLK_FIMC_LITE1531 +#define CLK_PCLK_FIMC_LITE3532 +#define CLK_PCLK_MSCL0 533 +#define CLK_PCLK_MSCL1 534 +#define CLK_PCLK_MSCL2 535 +#define CLK_PCLK_MFC 536 /* mux clocks */ #define CLK_MOUT_HDMI 640 +#define CLK_MOUT_FIMD1 641 +#define CLK_MOUT_MAUDIO0 642 +#define CLK_MOUT_SPI0 643 +#define CLK_MOUT_SPI1 644 +#define CLK_MOUT_SPI2 645 +#define CLK_MOUT_SW_ACLK333646 +#define CLK_MOUT_USER_ACLK333 647 +#define CLK_MOUT_SW_ACLK300_GSCL 648 +#define CLK_MOUT_USER_ACLK300_GSCL 649 +#define CLK_MOUT_SW_ACLK333_432_GSCL 650 +#define CLK_MOUT_USER_ACLK333_432_GSCL 651 +#define CLK_MOUT_G3D 652 /* divider clocks */ #define CLK_DOUT_PIXEL768 Also similar comment as for patch 1/7, it's hard to tell why this change is needed at all. Best regards, Tomasz -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/7] clk: exynos5420: Rename clock IDs
Hi Shaik,
On 27.03.2014 12:07, Shaik Ameer Basha wrote:
From: Rahul Sharma rahul.sha...@samsung.com
This patch renames the clock IDs used for the DT bindings as
per Exynos5420 datasheet.
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
Signed-off-by: Shaik Ameer Basha shaik.am...@samsung.com
---
drivers/clk/samsung/clk-exynos5420.c | 162 +---
include/dt-bindings/clock/exynos5420.h | 138 +--
2 files changed, 154 insertions(+), 146 deletions(-)
diff --git a/drivers/clk/samsung/clk-exynos5420.c
b/drivers/clk/samsung/clk-exynos5420.c
index 3d0fb77..1402554 100644
--- a/drivers/clk/samsung/clk-exynos5420.c
+++ b/drivers/clk/samsung/clk-exynos5420.c
@@ -544,8 +544,8 @@ 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_A(CLK_PCLK_MCT, pclk_st, aclk66_psgen,
+ GATE_BUS_PERIS1, 2, 0, 0, mct),
Clock IDs should generally match clock names, while this one obviously
does not. Either you should update both, or... (see below)
GATE(0, aclk200_fsys, mout_user_aclk200_fsys,
GATE_BUS_FSYS0, 9, CLK_IGNORE_UNUSED, 0),
@@ -643,83 +643,90 @@ static struct samsung_gate_clock exynos5420_gate_clks[]
__initdata = {
GATE_TOP_SCLK_MAU, 1, CLK_SET_RATE_PARENT, 0),
/* FSYS */
GATE(CLK_TSI, tsi, aclk200_fsys, GATE_BUS_FSYS0, 0, 0, 0),
- GATE(CLK_PDMA0, pdma0, aclk200_fsys, GATE_BUS_FSYS0, 1, 0, 0),
- GATE(CLK_PDMA1, pdma1, aclk200_fsys, GATE_BUS_FSYS0, 2, 0, 0),
+ GATE(CLK_ACLK_PDMA0, pdma0, aclk200_fsys, GATE_BUS_FSYS0, 1, 0, 0),
+ GATE(CLK_ACLK_PDMA1, pdma1, aclk200_fsys, GATE_BUS_FSYS0, 2, 0, 0),
GATE(CLK_UFS, ufs, aclk200_fsys2, GATE_BUS_FSYS0, 3, 0, 0),
- GATE(CLK_RTIC, rtic, aclk200_fsys, GATE_BUS_FSYS0, 5, 0, 0),
- GATE(CLK_MMC0, mmc0, aclk200_fsys2, GATE_BUS_FSYS0, 12, 0, 0),
- GATE(CLK_MMC1, mmc1, aclk200_fsys2, GATE_BUS_FSYS0, 13, 0, 0),
- GATE(CLK_MMC2, mmc2, aclk200_fsys2, GATE_BUS_FSYS0, 14, 0, 0),
- GATE(CLK_SROMC, sromc, aclk200_fsys2,
+ GATE(CLK_ACLK_RTIC, rtic, aclk200_fsys, GATE_BUS_FSYS0, 5, 0, 0),
+ GATE(CLK_ACLK_MMC0, mmc0, aclk200_fsys2, GATE_BUS_FSYS0, 12, 0, 0),
+ GATE(CLK_ACLK_MMC1, mmc1, aclk200_fsys2, GATE_BUS_FSYS0, 13, 0, 0),
+ GATE(CLK_ACLK_MMC2, mmc2, aclk200_fsys2, GATE_BUS_FSYS0, 14, 0, 0),
+ GATE(CLK_HCLK_SROMC, sromc, aclk200_fsys2,
GATE_BUS_FSYS0, 19, CLK_IGNORE_UNUSED, 0),
- GATE(CLK_USBH20, usbh20, aclk200_fsys, GATE_BUS_FSYS0, 20, 0, 0),
- GATE(CLK_USBD300, usbd300, aclk200_fsys, GATE_BUS_FSYS0, 21, 0, 0),
- GATE(CLK_USBD301, usbd301, aclk200_fsys, GATE_BUS_FSYS0, 28, 0, 0),
+ GATE(CLK_HCLK_USBH20, usbh20, aclk200_fsys,
+ GATE_BUS_FSYS0, 20, 0, 0),
+ GATE(CLK_HCLK_USBD300, usbd300, aclk200_fsys,
+ GATE_BUS_FSYS0, 21, 0, 0),
+ GATE(CLK_HCLK_USBD301, usbd301, aclk200_fsys,
+ GATE_BUS_FSYS0, 28, 0, 0),
/* UART */
- GATE(CLK_UART0, uart0, aclk66_peric, GATE_BUS_PERIC, 4, 0, 0),
- GATE(CLK_UART1, uart1, aclk66_peric, GATE_BUS_PERIC, 5, 0, 0),
- GATE_A(CLK_UART2, uart2, aclk66_peric,
+ GATE(CLK_PCLK_UART0, uart0, aclk66_peric, GATE_BUS_PERIC, 4, 0, 0),
+ GATE(CLK_PCLK_UART1, uart1, aclk66_peric, GATE_BUS_PERIC, 5, 0, 0),
+ GATE_A(CLK_PCLK_UART2, uart2, aclk66_peric,
GATE_BUS_PERIC, 6, CLK_IGNORE_UNUSED, 0, uart2),
- GATE(CLK_UART3, uart3, aclk66_peric, GATE_BUS_PERIC, 7, 0, 0),
+ GATE(CLK_PCLK_UART3, uart3, aclk66_peric, GATE_BUS_PERIC, 7, 0, 0),
/* I2C */
- GATE(CLK_I2C0, i2c0, aclk66_peric, GATE_BUS_PERIC, 9, 0, 0),
- GATE(CLK_I2C1, i2c1, aclk66_peric, GATE_BUS_PERIC, 10, 0, 0),
- GATE(CLK_I2C2, i2c2, aclk66_peric, GATE_BUS_PERIC, 11, 0, 0),
- GATE(CLK_I2C3, i2c3, aclk66_peric, GATE_BUS_PERIC, 12, 0, 0),
- GATE(CLK_I2C4, i2c4, aclk66_peric, GATE_BUS_PERIC, 13, 0, 0),
- GATE(CLK_I2C5, i2c5, aclk66_peric, GATE_BUS_PERIC, 14, 0, 0),
- GATE(CLK_I2C6, i2c6, aclk66_peric, GATE_BUS_PERIC, 15, 0, 0),
- GATE(CLK_I2C7, i2c7, aclk66_peric, GATE_BUS_PERIC, 16, 0, 0),
- GATE(CLK_I2C_HDMI, i2c_hdmi, aclk66_peric, GATE_BUS_PERIC, 17, 0,
- 0),
- GATE(CLK_TSADC, tsadc, aclk66_peric, GATE_BUS_PERIC, 18, 0, 0),
+ GATE(CLK_PCLK_I2C0, i2c0, aclk66_peric, GATE_BUS_PERIC, 9, 0, 0),
+ GATE(CLK_PCLK_I2C1, i2c1, aclk66_peric, GATE_BUS_PERIC, 10, 0, 0),
+ GATE(CLK_PCLK_I2C2, i2c2, aclk66_peric, GATE_BUS_PERIC, 11, 0, 0),
+ GATE(CLK_PCLK_I2C3, i2c3, aclk66_peric, GATE_BUS_PERIC, 12, 0, 0),
+
Re: [PATCH v2 4/7] clk: exynos5420: Rename clock names
Hi Shaik, On 27.03.2014 12:07, Shaik Ameer Basha wrote: From: Rahul Sharma rahul.sha...@samsung.com Maintain the mout_, dout_, sclk_ prefix to the clock names wherever applicable. Looking at the patch, it does seem to do more than that. Considering my comments to patch 3/7, I would drop the renames simply adding *CLK_ prefix (except SCLK_, which is fine as it specifies clock type, just as MOUT_/DOUT_/etc.). Best regards, Tomasz -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] exynos4-is: Fix compilation for !CONFIG_COMMON_CLK
CONFIG_COMMON_CLK is not enabled on S5PV210 platform, so include
some clk API data structures conditionally to avoid compilation
errors. These #ifdefs will be removed for next kernel release,
when the S5PV210 platform moves to DT and the common clk API.
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/platform/exynos4-is/media-dev.c |2 +-
drivers/media/platform/exynos4-is/media-dev.h |4
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/exynos4-is/media-dev.c
b/drivers/media/platform/exynos4-is/media-dev.c
index 2a2d42e..002abbf 100644
--- a/drivers/media/platform/exynos4-is/media-dev.c
+++ b/drivers/media/platform/exynos4-is/media-dev.c
@@ -1523,7 +1523,7 @@ err:
}
#else
#define fimc_md_register_clk_provider(fmd) (0)
-#define fimc_md_unregister_clk_provider(fmd) (0)
+#define fimc_md_unregister_clk_provider(fmd)
#endif
static int subdev_notifier_bound(struct v4l2_async_notifier *notifier,
diff --git a/drivers/media/platform/exynos4-is/media-dev.h
b/drivers/media/platform/exynos4-is/media-dev.h
index ee1e251..58c4945 100644
--- a/drivers/media/platform/exynos4-is/media-dev.h
+++ b/drivers/media/platform/exynos4-is/media-dev.h
@@ -94,7 +94,9 @@ struct fimc_sensor_info {
};
struct cam_clk {
+#ifdef CONFIG_COMMON_CLK
struct clk_hw hw;
+#endif
struct fimc_md *fmd;
};
#define to_cam_clk(_hw) container_of(_hw, struct cam_clk, hw)
@@ -142,7 +144,9 @@ struct fimc_md {
struct cam_clk_provider {
struct clk *clks[FIMC_MAX_CAMCLKS];
+#ifdef CONFIG_COMMON_CLK
struct clk_onecell_data clk_data;
+#endif
struct device_node *of_node;
struct cam_clk camclk[FIMC_MAX_CAMCLKS];
int num_clocks;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/5] ARM: S5PV210: Remove camera support from mach-goni.c
S5PV210 is going to get DT support, so we can remove the camera
bits from the only board using camera on S5PV210. This allows to
clean the exynos4-is driver by dropping code for non-dt platforms.
This patch can be dropped if a patch removing the whole board
file is applied first.
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
arch/arm/mach-s5pv210/mach-goni.c | 51 -
1 file changed, 51 deletions(-)
diff --git a/arch/arm/mach-s5pv210/mach-goni.c
b/arch/arm/mach-s5pv210/mach-goni.c
index b41a38a..6c719ec 100644
--- a/arch/arm/mach-s5pv210/mach-goni.c
+++ b/arch/arm/mach-s5pv210/mach-goni.c
@@ -49,11 +49,6 @@
#include plat/clock.h
#include plat/samsung-time.h
#include plat/mfc.h
-#include plat/camport.h
-
-#include media/v4l2-mediabus.h
-#include media/s5p_fimc.h
-#include media/noon010pc30.h
#include common.h
@@ -285,14 +280,6 @@ static void __init goni_tsp_init(void)
/* USB OTG */
static struct s3c_hsotg_plat goni_hsotg_pdata;
-static void goni_camera_init(void)
-{
- s5pv210_fimc_setup_gpio(S5P_CAMPORT_A);
-
- /* Set max driver strength on CAM_A_CLKOUT pin. */
- s5p_gpio_set_drvstr(S5PV210_GPE1(3), S5P_GPIO_DRVSTR_LV4);
-}
-
/* MAX8998 regulators */
#if defined(CONFIG_REGULATOR_MAX8998) ||
defined(CONFIG_REGULATOR_MAX8998_MODULE)
@@ -825,34 +812,6 @@ static void goni_setup_sdhci(void)
s3c_sdhci2_set_platdata(goni_hsmmc2_data);
};
-static struct noon010pc30_platform_data noon010pc30_pldata = {
- .clk_rate = 1600UL,
- .gpio_nreset= S5PV210_GPB(2), /* CAM_CIF_NRST */
- .gpio_nstby = S5PV210_GPB(0), /* CAM_CIF_NSTBY */
-};
-
-static struct i2c_board_info noon010pc30_board_info = {
- I2C_BOARD_INFO(NOON010PC30, 0x60 1),
- .platform_data = noon010pc30_pldata,
-};
-
-static struct fimc_source_info goni_camera_sensors[] = {
- {
- .mux_id = 0,
- .flags = V4L2_MBUS_PCLK_SAMPLE_FALLING |
- V4L2_MBUS_VSYNC_ACTIVE_LOW,
- .fimc_bus_type = FIMC_BUS_TYPE_ITU_601,
- .board_info = noon010pc30_board_info,
- .i2c_bus_num= 0,
- .clk_frequency = 1600UL,
- },
-};
-
-static struct s5p_platform_fimc goni_fimc_md_platdata __initdata = {
- .source_info= goni_camera_sensors,
- .num_clients= ARRAY_SIZE(goni_camera_sensors),
-};
-
/* Audio device */
static struct platform_device goni_device_audio = {
.name = smdk-audio,
@@ -874,10 +833,6 @@ static struct platform_device *goni_devices[] __initdata =
{
s5p_device_mixer,
s5p_device_sdo,
s3c_device_i2c0,
- s5p_device_fimc0,
- s5p_device_fimc1,
- s5p_device_fimc2,
- s5p_device_fimc_md,
s3c_device_hsmmc0,
s3c_device_hsmmc1,
s3c_device_hsmmc2,
@@ -946,14 +901,8 @@ static void __init goni_machine_init(void)
/* FB */
s3c_fb_set_platdata(goni_lcd_pdata);
- /* FIMC */
- s3c_set_platdata(goni_fimc_md_platdata, sizeof(goni_fimc_md_platdata),
-s5p_device_fimc_md);
-
s3c_hsotg_set_platdata(goni_hsotg_pdata);
- goni_camera_init();
-
/* SPI */
spi_register_board_info(spi_board_info, ARRAY_SIZE(spi_board_info));
--
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] Exynos4 SoC camera subsystem driver cleanups
This patch series removes support for non-dt platforms from the
Exynos4/S5P SoC camera interface drivers and removes (ab)use
of simple-bus compatible string.
Sylwester Nawrocki (5):
ARM: S5PV210: Remove camera support from mach-goni.c
exynos4-is: Fix compilation for !CONFIG_COMMON_CLK
exynos4-is: Remove support for non-dt platforms
exynos4-is: Remove requirement for simple-bus compatible
ARM: dts: exynos4: Remove simple-bus compatible from camera subsystem
nodes
.../devicetree/bindings/media/samsung-fimc.txt |6 +-
Documentation/video4linux/fimc.txt | 30 --
MAINTAINERS|1 -
arch/arm/boot/dts/exynos4.dtsi |2 +-
arch/arm/boot/dts/exynos4x12.dtsi |2 +-
arch/arm/mach-s5pv210/mach-goni.c | 51 ---
drivers/media/platform/exynos4-is/Kconfig |3 +-
drivers/media/platform/exynos4-is/common.c | 49 ++-
drivers/media/platform/exynos4-is/common.h |6 +-
drivers/media/platform/exynos4-is/fimc-core.h |2 +-
drivers/media/platform/exynos4-is/fimc-is.c| 12 +-
drivers/media/platform/exynos4-is/fimc-isp-video.c |2 +-
drivers/media/platform/exynos4-is/fimc-isp.h |2 +-
drivers/media/platform/exynos4-is/fimc-lite-reg.c |2 +-
drivers/media/platform/exynos4-is/fimc-lite.c |2 +-
drivers/media/platform/exynos4-is/fimc-lite.h |2 +-
drivers/media/platform/exynos4-is/fimc-reg.c |2 +-
drivers/media/platform/exynos4-is/media-dev.c | 356 +++-
drivers/media/platform/exynos4-is/media-dev.h |2 +-
drivers/media/platform/exynos4-is/mipi-csis.c | 43 +--
include/linux/platform_data/mipi-csis.h| 28 --
include/media/{s5p_fimc.h = exynos-fimc.h}| 21 --
22 files changed, 138 insertions(+), 488 deletions(-)
delete mode 100644 include/linux/platform_data/mipi-csis.h
rename include/media/{s5p_fimc.h = exynos-fimc.h} (87%)
--
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] exynos4-is: Fix compilation for !CONFIG_COMMON_CLK
CONFIG_COMMON_CLK is not enabled on S5PV210 platform, so include
some clk API data structures conditionally to avoid compilation
errors. These #ifdefs will be removed for next kernel release,
when the S5PV210 platform moves to DT and the common clk API.
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/platform/exynos4-is/media-dev.c |2 +-
drivers/media/platform/exynos4-is/media-dev.h |4
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/exynos4-is/media-dev.c
b/drivers/media/platform/exynos4-is/media-dev.c
index 2a2d42e..002abbf 100644
--- a/drivers/media/platform/exynos4-is/media-dev.c
+++ b/drivers/media/platform/exynos4-is/media-dev.c
@@ -1523,7 +1523,7 @@ err:
}
#else
#define fimc_md_register_clk_provider(fmd) (0)
-#define fimc_md_unregister_clk_provider(fmd) (0)
+#define fimc_md_unregister_clk_provider(fmd)
#endif
static int subdev_notifier_bound(struct v4l2_async_notifier *notifier,
diff --git a/drivers/media/platform/exynos4-is/media-dev.h
b/drivers/media/platform/exynos4-is/media-dev.h
index ee1e251..58c4945 100644
--- a/drivers/media/platform/exynos4-is/media-dev.h
+++ b/drivers/media/platform/exynos4-is/media-dev.h
@@ -94,7 +94,9 @@ struct fimc_sensor_info {
};
struct cam_clk {
+#ifdef CONFIG_COMMON_CLK
struct clk_hw hw;
+#endif
struct fimc_md *fmd;
};
#define to_cam_clk(_hw) container_of(_hw, struct cam_clk, hw)
@@ -142,7 +144,9 @@ struct fimc_md {
struct cam_clk_provider {
struct clk *clks[FIMC_MAX_CAMCLKS];
+#ifdef CONFIG_COMMON_CLK
struct clk_onecell_data clk_data;
+#endif
struct device_node *of_node;
struct cam_clk camclk[FIMC_MAX_CAMCLKS];
int num_clocks;
--
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] exynos4-is: Remove support for non-dt platforms
All platforms supported by this driver are going to get device tree
support in this kernel release so remove code that would have been
actually not used any more.
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
Documentation/video4linux/fimc.txt | 30 --
MAINTAINERS|1 -
drivers/media/platform/exynos4-is/Kconfig |3 +-
drivers/media/platform/exynos4-is/common.c |2 +-
drivers/media/platform/exynos4-is/fimc-core.h |2 +-
drivers/media/platform/exynos4-is/fimc-isp-video.c |2 +-
drivers/media/platform/exynos4-is/fimc-isp.h |2 +-
drivers/media/platform/exynos4-is/fimc-lite-reg.c |2 +-
drivers/media/platform/exynos4-is/fimc-lite.c |2 +-
drivers/media/platform/exynos4-is/fimc-lite.h |2 +-
drivers/media/platform/exynos4-is/fimc-reg.c |2 +-
drivers/media/platform/exynos4-is/media-dev.c | 329 ++--
drivers/media/platform/exynos4-is/media-dev.h |6 +-
drivers/media/platform/exynos4-is/mipi-csis.c | 43 +--
include/linux/platform_data/mipi-csis.h| 28 --
include/media/{s5p_fimc.h = exynos-fimc.h}| 21 --
16 files changed, 50 insertions(+), 427 deletions(-)
delete mode 100644 include/linux/platform_data/mipi-csis.h
rename include/media/{s5p_fimc.h = exynos-fimc.h} (87%)
diff --git a/Documentation/video4linux/fimc.txt
b/Documentation/video4linux/fimc.txt
index 7d6e160..e0c6b8b 100644
--- a/Documentation/video4linux/fimc.txt
+++ b/Documentation/video4linux/fimc.txt
@@ -140,39 +140,9 @@ You can either grep through the kernel log to find
relevant information, i.e.
or retrieve the information from /dev/media? with help of the media-ctl tool:
# media-ctl -p
-6. Platform support
-===
-
-The machine code (arch/arm/plat-samsung and arch/arm/mach-*) must select
-following options:
-
-CONFIG_S5P_DEV_FIMC0 mandatory
-CONFIG_S5P_DEV_FIMC1 \
-CONFIG_S5P_DEV_FIMC2 |optional
-CONFIG_S5P_DEV_FIMC3 |
-CONFIG_S5P_SETUP_FIMC /
-CONFIG_S5P_DEV_CSIS0 \optional for MIPI-CSI interface
-CONFIG_S5P_DEV_CSIS1 /
-
-Except that, relevant s5p_device_fimc? should be registered in the machine code
-in addition to a s5p-fimc-md platform device to which the media device driver
-is bound. The s5p-fimc-md device instance is required even if only
mem-to-mem
-operation is used.
-
-The description of sensor(s) attached to FIMC/MIPI-CSIS camera inputs should be
-passed as the s5p-fimc-md device platform_data. The platform data structure
-is defined in file include/media/s5p_fimc.h.
-
7. Build
-This driver depends on following config options:
-PLAT_S5P,
-PM_RUNTIME,
-I2C,
-REGULATOR,
-VIDEO_V4L2_SUBDEV_API,
-
If the driver is built as a loadable kernel module
(CONFIG_VIDEO_SAMSUNG_S5P_FIMC=m)
two modules are created (in addition to the core v4l2 modules): s5p-fimc.ko and
optional s5p-csis.ko (MIPI-CSI receiver subdev).
diff --git a/MAINTAINERS b/MAINTAINERS
index 6dc67b1..e2f5dfe 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7641,7 +7641,6 @@ L:linux-me...@vger.kernel.org
Q: https://patchwork.linuxtv.org/project/linux-media/list/
S: Supported
F: drivers/media/platform/exynos4-is/
-F: include/media/s5p_fimc.h
SAMSUNG S3C24XX/S3C64XX SOC SERIES CAMIF DRIVER
M: Sylwester Nawrocki sylvester.nawro...@gmail.com
diff --git a/drivers/media/platform/exynos4-is/Kconfig
b/drivers/media/platform/exynos4-is/Kconfig
index e1b2ceb..5dcaa0a 100644
--- a/drivers/media/platform/exynos4-is/Kconfig
+++ b/drivers/media/platform/exynos4-is/Kconfig
@@ -3,6 +3,7 @@ config VIDEO_SAMSUNG_EXYNOS4_IS
bool Samsung S5P/EXYNOS4 SoC series Camera Subsystem driver
depends on VIDEO_V4L2 VIDEO_V4L2_SUBDEV_API
depends on (PLAT_S5P || ARCH_EXYNOS)
+ depends on OF COMMON_CLK
help
Say Y here to enable camera host interface devices for
Samsung S5P and EXYNOS SoC series.
@@ -17,7 +18,7 @@ config VIDEO_S5P_FIMC
depends on I2C
select VIDEOBUF2_DMA_CONTIG
select V4L2_MEM2MEM_DEV
- select MFD_SYSCON if OF
+ select MFD_SYSCON
select VIDEO_EXYNOS4_IS_COMMON
help
This is a V4L2 driver for Samsung S5P and EXYNOS4 SoC camera host
diff --git a/drivers/media/platform/exynos4-is/common.c
b/drivers/media/platform/exynos4-is/common.c
index 0ec210b..0eb34ec 100644
--- a/drivers/media/platform/exynos4-is/common.c
+++ b/drivers/media/platform/exynos4-is/common.c
@@ -10,7 +10,7 @@
*/
#include linux/module.h
-#include media/s5p_fimc.h
+#include media/exynos-fimc.h
#include common.h
/* Called with the media graph mutex held or entity-stream_count 0. */
diff --git a/drivers/media/platform/exynos4-is/fimc-core.h
b/drivers/media/platform/exynos4-is/fimc-core.h
index 1790fb4..6c75c6c 100644
---
[PATCH 4/5] exynos4-is: Remove requirement for simple-bus compatible
This patch makes the driver instantiating its child devices itself,
rather than relying on an OS to instantiate devices as children
of simple-bus. This removes an incorrect usage of simple-bus
compatible.
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
This patch addresses Mark's review comments:
https://patchwork.linuxtv.org/patch/23008/
---
.../devicetree/bindings/media/samsung-fimc.txt |6 +--
drivers/media/platform/exynos4-is/common.c | 47 +++-
drivers/media/platform/exynos4-is/common.h |6 ++-
drivers/media/platform/exynos4-is/fimc-is.c| 12 -
drivers/media/platform/exynos4-is/media-dev.c | 33 ++
5 files changed, 89 insertions(+), 15 deletions(-)
diff --git a/Documentation/devicetree/bindings/media/samsung-fimc.txt
b/Documentation/devicetree/bindings/media/samsung-fimc.txt
index 922d6f8..8ce5984 100644
--- a/Documentation/devicetree/bindings/media/samsung-fimc.txt
+++ b/Documentation/devicetree/bindings/media/samsung-fimc.txt
@@ -15,9 +15,9 @@ Common 'camera' node
Required properties:
-- compatible: must be samsung,fimc, simple-bus
+- compatible: should be samsung,fimc,
- clocks: list of clock specifiers, corresponding to entries in
- the clock-names property;
+ the clock-names property,
- clock-names : must contain sclk_cam0, sclk_cam1, pxl_async0,
pxl_async1 entries, matching entries in the clocks property.
@@ -157,7 +157,7 @@ Example:
};
camera {
- compatible = samsung,fimc, simple-bus;
+ compatible = samsung,fimc;
clocks = clock 132, clock 133, clock 351,
clock 352;
clock-names = sclk_cam0, sclk_cam1, pxl_async0,
diff --git a/drivers/media/platform/exynos4-is/common.c
b/drivers/media/platform/exynos4-is/common.c
index 0eb34ec..1e50a48 100644
--- a/drivers/media/platform/exynos4-is/common.c
+++ b/drivers/media/platform/exynos4-is/common.c
@@ -1,7 +1,7 @@
/*
* Samsung S5P/EXYNOS4 SoC Camera Subsystem driver
*
- * Copyright (C) 2013 Samsung Electronics Co., Ltd.
+ * Copyright (C) 2013 - 2014 Samsung Electronics Co., Ltd.
* Author: Sylwester Nawrocki s.nawro...@samsung.com
*
* This program is free software; you can redistribute it and/or modify
@@ -11,6 +11,7 @@
#include linux/module.h
#include media/exynos-fimc.h
+#include linux/of_device.h
#include common.h
/* Called with the media graph mutex held or entity-stream_count 0. */
@@ -50,4 +51,48 @@ void __fimc_vidioc_querycap(struct device *dev, struct
v4l2_capability *cap,
}
EXPORT_SYMBOL(__fimc_vidioc_querycap);
+static int __remove_child_device(struct device *dev, void *unused)
+{
+of_device_unregister(to_platform_device(dev));
+return 0;
+}
+
+void fimc_unregister_child_devices(struct device *parent)
+{
+device_for_each_child(parent, NULL, __remove_child_device);
+}
+EXPORT_SYMBOL(fimc_unregister_child_devices);
+
+struct platform_device *fimc_register_child_device(struct device_node *child,
+ struct device *parent)
+{
+ struct platform_device *pdev;
+
+ pdev = of_platform_device_create(child, NULL, parent);
+ if (!pdev)
+ dev_err(parent,
+ failed to create device for node %s\n,
+ child-full_name);
+ return pdev;
+}
+EXPORT_SYMBOL(fimc_register_child_device);
+
+int fimc_register_child_devices(struct device *parent)
+{
+ struct platform_device *pdev;
+ struct device_node *child;
+
+ for_each_available_child_of_node(parent-of_node, child) {
+ pdev = fimc_register_child_device(child, parent);
+ if (!pdev) {
+ of_node_put(child);
+ fimc_unregister_child_devices(parent);
+ return -ENXIO;
+ }
+
+ }
+ return 0;
+}
+EXPORT_SYMBOL(fimc_register_child_devices);
+
MODULE_LICENSE(GPL);
diff --git a/drivers/media/platform/exynos4-is/common.h
b/drivers/media/platform/exynos4-is/common.h
index 75b9c71..1d06715 100644
--- a/drivers/media/platform/exynos4-is/common.h
+++ b/drivers/media/platform/exynos4-is/common.h
@@ -1,5 +1,5 @@
/*
- * Copyright (C) 2013 Samsung Electronics Co., Ltd.
+ * Copyright (C) 2013 - 2014 Samsung Electronics Co., Ltd.
*
* 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
@@ -14,3 +14,7 @@
struct v4l2_subdev *fimc_find_remote_sensor(struct media_entity *entity);
void __fimc_vidioc_querycap(struct device *dev, struct v4l2_capability *cap,
unsigned int caps);
+struct platform_device *fimc_register_child_device(struct device_node *child,
+ struct device *parent);
+int
[PATCH 5/5] ARM: dts: exynos4: Remove simple-bus compatible from camera subsystem nodes
The usage of simple-bus was incorrect and the drivers now will also
work without it so remove it.
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
arch/arm/boot/dts/exynos4.dtsi|2 +-
arch/arm/boot/dts/exynos4x12.dtsi |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index 912fe72..ad06a1d 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -125,7 +125,7 @@
};
camera {
- compatible = samsung,fimc, simple-bus;
+ compatible = samsung,fimc;
status = disabled;
#address-cells = 1;
#size-cells = 1;
diff --git a/arch/arm/boot/dts/exynos4x12.dtsi
b/arch/arm/boot/dts/exynos4x12.dtsi
index 192617b..3fec920 100644
--- a/arch/arm/boot/dts/exynos4x12.dtsi
+++ b/arch/arm/boot/dts/exynos4x12.dtsi
@@ -190,7 +190,7 @@
};
fimc_is: fimc-is@1200 {
- compatible = samsung,exynos4212-fimc-is, simple-bus;
+ compatible = samsung,exynos4212-fimc-is;
reg = 0x1200 0x26;
interrupts = 0 90 0, 0 95 0;
samsung,power-domain = pd_isp;
--
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 v2 5/7] clk: exynos5420: Add missing clocks
Hi Shaik,
On 27.03.2014 12:07, Shaik Ameer Basha wrote:
From: Rahul Sharma rahul.sha...@samsung.com
This patch adds the missing clocks related to the modules
like FIMD, DP, GSCL, MSCL, ISP, MFC etc.
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
Signed-off-by: Shaik Ameer Basha shaik.am...@samsung.com
---
drivers/clk/samsung/clk-exynos5420.c | 221 +-
1 file changed, 219 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/samsung/clk-exynos5420.c
b/drivers/clk/samsung/clk-exynos5420.c
index 793fb3d..26ddf33 100644
--- a/drivers/clk/samsung/clk-exynos5420.c
+++ b/drivers/clk/samsung/clk-exynos5420.c
@@ -269,15 +269,36 @@ PNAME(mout_group3_p) = {mout_sclk_rpll,
mout_sclk_spll};
PNAME(mout_group4_p) = {mout_sclk_ipll, mout_sclk_dpll, mout_sclk_mpll};
PNAME(mout_group5_p) = {mout_sclk_vpll, mout_sclk_dpll};
+PNAME(mout_fimd1_final_p) = {mout_fimd1, mout_fimd1_opt};
PNAME(mout_sw_aclk66_p) = {dout_aclk66, mout_sclk_spll};
PNAME(mout_user_aclk66_peric_p) = {fin_pll, mout_sw_aclk66};
+PNAME(mout_user_aclk66_gpio_p) = {mout_sw_aclk66, ffactor_sw_aclk66};
PNAME(mout_sw_aclk200_fsys_p) = {dout_aclk200_fsys, mout_sclk_spll};
+PNAME(mout_sw_pclk200_fsys_p) = {dout_pclk200_fsys, mout_sclk_spll};
+PNAME(mout_user_pclk200_fsys_p)= {fin_pll, mout_sw_pclk200_fsys};
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};
+
+PNAME(mout_sw_aclk333_432_isp0_p) = {dout_aclk333_432_isp0,
+ mout_sclk_spll};
+PNAME(mout_user_aclk333_432_isp0_p) = {fin_pll, mout_sw_aclk333_432_isp0};
+
+PNAME(mout_sw_aclk333_432_isp_p) = {dout_aclk333_432_isp, mout_sclk_spll};
+PNAME(mout_user_aclk333_432_isp_p) = {fin_pll, mout_sw_aclk333_432_isp};
+
PNAME(mout_sw_aclk200_p) = {dout_aclk200, mout_sclk_spll};
PNAME(mout_aclk200_disp1_p) = {fin_pll, mout_sw_aclk200};
@@ -292,6 +313,7 @@ PNAME(mout_user_aclk166_p) = {fin_pll, mout_sw_aclk166};
PNAME(mout_sw_aclk266_p) = {dout_aclk266, mout_sclk_spll};
PNAME(mout_user_aclk266_p) = {fin_pll, mout_sw_aclk266};
+PNAME(mout_user_aclk266_isp_p) = {fin_pll, mout_sw_aclk266};
PNAME(mout_sw_aclk333_432_gscl_p) = {dout_aclk333_432_gscl,
mout_sclk_spll};
PNAME(mout_user_aclk333_432_gscl_p) = {fin_pll, mout_sw_aclk333_432_gscl};
@@ -300,7 +322,9 @@ PNAME(mout_sw_aclk300_gscl_p) = {dout_aclk300_gscl,
mout_sclk_spll};
PNAME(mout_user_aclk300_gscl_p) = {fin_pll, mout_sw_aclk300_gscl};
PNAME(mout_sw_aclk300_disp1_p) = {dout_aclk300_disp1, mout_sclk_spll};
+PNAME(mout_sw_aclk400_disp1_p) = {dout_aclk400_disp1, mout_sclk_spll};
PNAME(mout_user_aclk300_disp1_p) = {fin_pll, mout_sw_aclk300_disp1};
+PNAME(mout_user_aclk400_disp1_p) = {fin_pll, mout_sw_aclk400_disp1};
PNAME(mout_sw_aclk300_jpeg_p) = {dout_aclk300_jpeg, mout_sclk_spll};
PNAME(mout_user_aclk300_jpeg_p) = {fin_pll, mout_sw_aclk300_jpeg};
@@ -330,6 +354,8 @@ PNAME(mout_hdmi_p) = {dout_hdmi_pixel, sclk_hdmiphy};
PNAME(mout_maudio0_p) = {fin_pll, maudio_clk, mout_sclk_dpll,
mout_sclk_mpll, mout_sclk_spll, mout_sclk_ipll,
mout_sclk_epll, mout_sclk_rpll};
+PNAME(mout_mau_epll_clk_p) = {mout_sclk_epll, mout_sclk_dpll,
+ mout_sclk_mpll, mout_sclk_spll};
/* fixed rate clocks generated outside the soc */
static struct samsung_fixed_rate_clock exynos5420_fixed_rate_ext_clks[]
__initdata = {
@@ -347,6 +373,7 @@ static struct samsung_fixed_rate_clock
exynos5420_fixed_rate_clks[] __initdata =
static struct samsung_fixed_factor_clock exynos5420_fixed_factor_clks[]
__initdata = {
FFACTOR(0, ffactor_hsic_12m, fin_pll, 1, 2, 0),
+ FFACTOR(0, ffactor_sw_aclk66, mout_sw_aclk66, 1, 2, 0),
};
static struct samsung_mux_clock exynos5420_mux_clks[] __initdata = {
@@ -452,6 +479,10 @@ static struct samsung_mux_clock exynos5420_mux_clks[]
__initdata = {
MUX(0, mout_dp1, mout_group2_p, SRC_DISP10, 20, 3),
MUX(0, mout_pixel, mout_group2_p, SRC_DISP10, 24, 3),
MUX(CLK_MOUT_HDMI, mout_hdmi, mout_hdmi_p, SRC_DISP10, 28, 1),
+ MUX_F(0, mout_fimd1_opt, mout_group2_p, SRC_DISP10, 8, 3,
+ CLK_SET_RATE_PARENT, 0),
+ MUX_F(0, mout_fimd1_final, mout_fimd1_final_p, TOP_SPARE2, 8, 1,
+
Re: [PATCH v2 7/7] ARM: dts: update macros in clock bindings for exynos5420
Hi Shaik, On 27.03.2014 12:07, Shaik Ameer Basha wrote: From: Rahul Sharma rahul.sha...@samsung.com This patch updates the macros as per the latest changes and replaces magic numbers with macros defined in DT header for exynos5420. Contents of dts files are not bindings, they are just device tree sources/data, defined according to some bindings. Bindings are defined sets of nodes and properties and their formats, as you can see in Documentation/devicetree/bindings/, where documentation of supported bindings is available. So this patch doesn't update clock bindings, but rather device nodes. Following would be more appropriate: ARM: dts: update clock IDs in device tree of Exynos5420. However, as mentioned in comments to previous patches, most (if not all) of the changes below could be probably dropped. Best regards, Tomasz -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/3] ARM: EXYNOS: Map PMU address through DT
Hi Vikas,
On 17.03.2014 14:09, Vikas Sajjan wrote:
Instead of hardcoding the PMU details for each SoC, pass this information
through device tree (DT).
Signed-off-by: Vikas Sajjan vikas.saj...@samsung.com
---
.../devicetree/bindings/arm/samsung/pmu.txt|5 +-
arch/arm/boot/dts/exynos4.dtsi |5 ++
arch/arm/boot/dts/exynos5260.dtsi |5 ++
arch/arm/mach-exynos/common.c | 51 +---
arch/arm/mach-exynos/include/mach/map.h|3 --
5 files changed, 47 insertions(+), 22 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/samsung/pmu.txt
b/Documentation/devicetree/bindings/arm/samsung/pmu.txt
index f1f1552..667a7f0 100644
--- a/Documentation/devicetree/bindings/arm/samsung/pmu.txt
+++ b/Documentation/devicetree/bindings/arm/samsung/pmu.txt
@@ -2,14 +2,15 @@ SAMSUNG Exynos SoC series PMU Registers
Properties:
- compatible : should contain two values. First value must be one from
following list:
+ - samsung,exynos4210-pmu - for Exynos4210 and Exynos4x12
SoC,
- samsung,exynos5250-pmu - for Exynos5250 SoC,
- - samsung,exynos5420-pmu - for Exynos5420 SoC.
+ - samsung,exynos5420-pmu - for Exynos5420 and Exynos5260
SoC.
Do Exynos5420 and 5260 really have identical PMU blocks with the same
register layouts? If not, they should have different compatible strings.
second value must be always syscon.
- reg : offset and length of the register set.
Example :
pmu_system_controller: system-controller@1004 {
- compatible = samsung,exynos5250-pmu, syscon;
+ compatible = samsung,exynos5250-pmu;
reg = 0x1004 0x5000;
};
diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index 08452e1..94cbafa 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -55,6 +55,11 @@
#phy-cells = 1;
};
+ pmu_system_controller: system-controller@1002 {
+ compatible = samsung,exynos4210-pmu;
Missing syscon compatible string.
+ reg = 0x1002 0x4000;
+ };
+
pd_mfc: mfc-power-domain@10023C40 {
compatible = samsung,exynos4210-pd;
reg = 0x10023C40 0x20;
diff --git a/arch/arm/boot/dts/exynos5260.dtsi
b/arch/arm/boot/dts/exynos5260.dtsi
index a93fea8..2a4dace 100644
--- a/arch/arm/boot/dts/exynos5260.dtsi
+++ b/arch/arm/boot/dts/exynos5260.dtsi
@@ -264,6 +264,11 @@
};
};
+ pmu_system_controller: system-controller@10D5 {
+ compatible = samsung,exynos5420-pmu;
Missing syscon compatible string.
+ reg = 0x10D5 0x5000;
+ };
+
pinctrl_0: pinctrl@1160 {
compatible = samsung,exynos5260-pinctrl;
reg = 0x1160 0x1000;
diff --git a/arch/arm/mach-exynos/common.c b/arch/arm/mach-exynos/common.c
index 1df81ff..c75733b 100644
--- a/arch/arm/mach-exynos/common.c
+++ b/arch/arm/mach-exynos/common.c
@@ -79,11 +79,6 @@ static struct map_desc exynos4_iodesc[] __initdata = {
.length = SZ_4K,
.type = MT_DEVICE,
}, {
- .virtual= (unsigned long)S5P_VA_PMU,
- .pfn= __phys_to_pfn(EXYNOS4_PA_PMU),
- .length = SZ_64K,
- .type = MT_DEVICE,
- }, {
.virtual= (unsigned long)S5P_VA_COMBINER_BASE,
.pfn= __phys_to_pfn(EXYNOS4_PA_COMBINER),
.length = SZ_4K,
@@ -157,11 +152,6 @@ static struct map_desc exynos5_iodesc[] __initdata = {
.pfn= __phys_to_pfn(EXYNOS5_PA_CMU),
.length = 144 * SZ_1K,
.type = MT_DEVICE,
- }, {
- .virtual= (unsigned long)S5P_VA_PMU,
- .pfn= __phys_to_pfn(EXYNOS5_PA_PMU),
- .length = SZ_64K,
- .type = MT_DEVICE,
},
};
@@ -243,12 +233,12 @@ static int __init exynos_fdt_map_chipid(unsigned long
node, const char *uname,
return 1;
}
-struct __sysram_desc {
+struct __exynos_reg_desc {
char name[32];
unsigned long addr;
};
-static struct __sysram_desc sysram_desc[] __initdata = {
+static struct __exynos_reg_desc exynos_sysram_desc[] __initdata = {
{
.name = samsung,exynos4210-sysram,
.addr = (unsigned long)S5P_VA_SYSRAM,
@@ -258,7 +248,20 @@ static struct __sysram_desc sysram_desc[] __initdata = {
},
};
-static int __init exynos_fdt_map_sysram(unsigned long node, const char *uname,
+static struct __exynos_reg_desc exynos_pmu_desc[] __initdata = {
+ {
+
Re: [PATCH v2 2/6] PCI: tegra: use new OF interrupt mapping when possible
On Tue, Apr 15, 2014 at 12:07:34PM +0200, Lucas Stach wrote: Hi Bjorn, Am Freitag, den 04.04.2014, 10:55 -0600 schrieb Bjorn Helgaas: On Wed, Mar 05, 2014 at 02:25:47PM +0100, Lucas Stach wrote: This is the recommended method of doing the IRQ mapping. For old devicetrees we fall back to the previous practice. Signed-off-by: Lucas Stach l.st...@pengutronix.de Acked-by: Arnd Bergmann a...@arndb.de Applied with Stephen's Tested-by to my pending/host-tegra branch. I'll rebase and rename it after v3.15-rc1, and I think we can squeeze it into v3.15 shortly after that. Thanks. Are you still planning to push this into 3.15, or has this slipped to 3.16? Yes, I'm hoping to put them in v3.15. I assume these actually fix something, e.g., we need these changes to boot with new devicetrees, or something? The changelogs don't make it clear that these are fixes, and I want to heed Linus' guidance: Anyway, because -rc1 is already pretty darn big, I do *not* want to hear about 'sorry this missed the window, can I still sneak in'. Fixes only. I should have applied these sooner to make the merge window; I apologize for that. Anyway, if you outline what these fix, I'll update the changelogs in my tree. Bjorn -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/3] ARM: EXYNOS: Add initial support of PMU for Exynos5260
Hi Vikas,
On 17.03.2014 14:09, Vikas Sajjan wrote:
Adds PMU support of PMU for Exynos5260. Suspend-to-RAM can be built on
top this.
Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com
Signed-off-by: Vikas Sajjan vikas.saj...@samsung.com
---
arch/arm/mach-exynos/common.h| 26
arch/arm/mach-exynos/pm.c| 34 +++--
arch/arm/mach-exynos/pmu.c | 238 ++
arch/arm/mach-exynos/regs-pmu.h | 232 +
arch/arm/plat-samsung/include/plat/cpu.h |8 +
5 files changed, 529 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-exynos/common.h b/arch/arm/mach-exynos/common.h
index aba6a2a..a17f701 100644
--- a/arch/arm/mach-exynos/common.h
+++ b/arch/arm/mach-exynos/common.h
@@ -56,6 +56,32 @@ enum sys_powerdown {
NUM_SYS_POWERDOWN,
};
+enum running_cpu {
+ EXYNOS5_KFC,
+ EXYNOS5_ARM,
+};
+
+enum reg_op {
+ REG_INIT, /* write new value */
+ REG_RESET, /* clear with zero */
+ REG_SET,/* bit set */
+ REG_CLEAR, /* bit clear */
+};
+
+/* reg/value set */
+#define EXYNOS_PMU_REG(REG, VAL, OP) \
+{ \
+ .reg= (void __iomem *)REG,\
+ .val= VAL,\
+ .op = OP, \
+}
+
+struct exynos_pmu_init_reg {
+ void __iomem *reg;
+ unsigned int val;
+ enum reg_op op;
+};
+
extern unsigned long l2x0_regs_phys;
struct exynos_pmu_conf {
void __iomem *reg;
diff --git a/arch/arm/mach-exynos/pm.c b/arch/arm/mach-exynos/pm.c
index 15af0ce..dbe9670 100644
--- a/arch/arm/mach-exynos/pm.c
+++ b/arch/arm/mach-exynos/pm.c
@@ -109,7 +109,7 @@ static int exynos_cpu_suspend(unsigned long arg)
outer_flush_all();
#endif
- if (soc_is_exynos5250())
+ if (soc_is_exynos5250() || soc_is_exynos5260())
flush_cache_all();
I think it's the right time for this code to be restructured. Adding
more and more SoCs over this cruft is making this code worse and worse.
I believe this should be done as follows:
- a generic struct describing particular PMU variant should be
defined, with things like
bool flush_cache_on_suspend;
struct exynos_pmu_conf *pmu_conf;
or even function pointers, like
void (*cpu_suspend)(unsigned long arg);
to handle things done currently using soc_is_*() macros, which we should
get rid of.
- a DT match table would bind particular compatible strings with
respective PMU variants structs,
- in general, this code should be made more like a normal driver, e.g.
bind to a DT node and map registers dynamically.
Best regards,
Tomasz
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/3] arm: exynos5260: add support for S2R
Hi Vikas,
On 17.03.2014 14:09, Vikas Sajjan wrote:
Adds Suspend to RAM (S2R) support to exynos5260.
Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com
Signed-off-by: Vikas Sajjan vikas.saj...@samsung.com
---
arch/arm/mach-exynos/pm.c | 62 +++
arch/arm/mach-exynos/regs-pmu.h | 12
2 files changed, 61 insertions(+), 13 deletions(-)
diff --git a/arch/arm/mach-exynos/pm.c b/arch/arm/mach-exynos/pm.c
index dbe9670..12cc241 100644
--- a/arch/arm/mach-exynos/pm.c
+++ b/arch/arm/mach-exynos/pm.c
@@ -77,12 +77,20 @@ static const struct exynos_wkup_irq exynos5250_wkup_irq[] =
{
{ /* sentinel */ },
};
+static const struct exynos_wkup_irq exynos5260_wkup_irq[] = {
+ { 105, BIT(1) }, /* RTC alarm */
+ { 106, BIT(2) }, /* RTC tick */
+ { /* sentinel */ },
+};
+
static int exynos_irq_set_wake(struct irq_data *data, unsigned int state)
{
const struct exynos_wkup_irq *wkup_irq;
if (soc_is_exynos5250())
wkup_irq = exynos5250_wkup_irq;
+ else if (soc_is_exynos5260())
+ wkup_irq = exynos5260_wkup_irq;
else
wkup_irq = exynos4_wkup_irq;
This should probably be tied to some DT match table as match data for
particular compatible strings. Also to eliminate the need to add such
change for every new SoC, the mapping between wake-up sources and GIC
interrupts should be probably parsed from DT.
Adding some people on CC for further comments.
@@ -124,10 +132,20 @@ static void exynos_pm_prepare(void)
unsigned int tmp;
/* Set wake-up mask registers */
- __raw_writel(exynos_get_eint_wake_mask(), S5P_EINT_WAKEUP_MASK);
- __raw_writel(exynos_irqwake_intmask ~(1 31), S5P_WAKEUP_MASK);
+ if (soc_is_exynos5260()) {
+ __raw_writel(exynos_get_eint_wake_mask(),
+ EXYNOS5260_EINT_WAKEUP_MASK);
+ __raw_writel(exynos_irqwake_intmask ~(1 31),
+ EXYNOS5260_WAKEUP_MASK);
+ } else {
+ __raw_writel(exynos_get_eint_wake_mask(),
+ S5P_EINT_WAKEUP_MASK);
+ __raw_writel(exynos_irqwake_intmask ~(1 31),
+ S5P_WAKEUP_MASK);
+ }
Same here. I wonder what we could do to eliminate the need for such changes.
By the way, don't you need to handle here EXYNOS5260_WAKEUP_MASK2 and
EXYNOS5260_WAKEUP_MASK3 as well?
- s3c_pm_do_save(exynos_core_save, ARRAY_SIZE(exynos_core_save));
+ if (!soc_is_exynos5260())
+ s3c_pm_do_save(exynos_core_save, ARRAY_SIZE(exynos_core_save));
Ugly.
if (soc_is_exynos5250()) {
s3c_pm_do_save(exynos5_sys_save, ARRAY_SIZE(exynos5_sys_save));
@@ -221,21 +239,39 @@ static void exynos_pm_resume(void)
: cc);
}
- /* For release retention */
-
- __raw_writel((1 28), S5P_PAD_RET_MAUDIO_OPTION);
- __raw_writel((1 28), S5P_PAD_RET_GPIO_OPTION);
- __raw_writel((1 28), S5P_PAD_RET_UART_OPTION);
- __raw_writel((1 28), S5P_PAD_RET_MMCA_OPTION);
- __raw_writel((1 28), S5P_PAD_RET_MMCB_OPTION);
- __raw_writel((1 28), S5P_PAD_RET_EBIA_OPTION);
- __raw_writel((1 28), S5P_PAD_RET_EBIB_OPTION);
+ if (soc_is_exynos5250()) {
+ /* For release retention */
+
+ __raw_writel((1 28), S5P_PAD_RET_MAUDIO_OPTION);
+ __raw_writel((1 28), S5P_PAD_RET_GPIO_OPTION);
+ __raw_writel((1 28), S5P_PAD_RET_UART_OPTION);
+ __raw_writel((1 28), S5P_PAD_RET_MMCA_OPTION);
+ __raw_writel((1 28), S5P_PAD_RET_MMCB_OPTION);
+ __raw_writel((1 28), S5P_PAD_RET_EBIA_OPTION);
+ __raw_writel((1 28), S5P_PAD_RET_EBIB_OPTION);
+ } else if (soc_is_exynos5260()) {
+ /* For release retention */
+ __raw_writel((1 28), EXYNOS5260_PAD_RETENTION_LPDDR3_OPTION);
+ __raw_writel((1 28), EXYNOS5260_PAD_RET_MAUDIO_OPTION);
+ __raw_writel((1 28), EXYNOS5260_PAD_RET_JTAG_OPTION);
+ __raw_writel((1 28), EXYNOS5260_PAD_RETENTION_MMC2_OPTION);
+ __raw_writel((1 28), EXYNOS5260_PAD_RETENTION_TOP_OPTION);
+ __raw_writel((1 28), EXYNOS5260_PAD_RETENTION_UART_OPTION);
+ __raw_writel((1 28), EXYNOS5260_PAD_RETENTION_MMC0_OPTION);
+ __raw_writel((1 28), EXYNOS5260_PAD_RETENTION_MMC1_OPTION);
+ __raw_writel((1 28), EXYNOS5260_PAD_RETENTION_SPI_OPTION);
+ __raw_writel((1 28), EXYNOS5260_PAD_RETENTION_MIF_OPTION);
+ __raw_writel((1 28),
+ EXYNOS5260_PAD_RETENTION_BOOTLDO_OPTION);
+ }
Ugly.
if (soc_is_exynos5250())
s3c_pm_do_restore(exynos5_sys_save,
Re: [PATCH V2 1/3] ARM: EXYNOS5: Add PMU settings for exynos5420
Hi Vikas,
Basically the same comments apply as for the series:
[PATCH v2 0/3] Add initial support of PMU for exynos5260
(https://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg27339.html)
In addition to above, please see some comments inline.
On 27.03.2014 07:13, Vikas Sajjan wrote:
Add intial PMU settings for exynos5420. This is required for
future S2R and Switching support.
Signed-off-by: Thomas Abraham thomas...@samsung.com
Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com
Signed-off-by: Vikas Sajjan vikas.saj...@samsung.com
---
arch/arm/mach-exynos/common.h | 10 ++
arch/arm/mach-exynos/pmu.c | 307 +++
arch/arm/mach-exynos/regs-pmu.h | 228 +
3 files changed, 545 insertions(+)
diff --git a/arch/arm/mach-exynos/common.h b/arch/arm/mach-exynos/common.h
index 9ef3f83..347afc2 100644
--- a/arch/arm/mach-exynos/common.h
+++ b/arch/arm/mach-exynos/common.h
@@ -15,6 +15,16 @@
#include linux/reboot.h
#include linux/of.h
+#define EXYNOS5420_USE_STANDBY_WFI_ALL (EXYNOS5420_ARM_USE_STANDBY_WFI0 \
+| EXYNOS5420_ARM_USE_STANDBY_WFI1 \
+| EXYNOS5420_ARM_USE_STANDBY_WFI2 \
+| EXYNOS5420_ARM_USE_STANDBY_WFI3 \
+| EXYNOS5420_KFC_USE_STANDBY_WFI0 \
+| EXYNOS5420_KFC_USE_STANDBY_WFI1 \
+| EXYNOS5420_KFC_USE_STANDBY_WFI2 \
+| EXYNOS5420_KFC_USE_STANDBY_WFI3)
+
+
void mct_init(void __iomem *base, int irq_g0, int irq_l0, int irq_l1);
struct map_desc;
diff --git a/arch/arm/mach-exynos/pmu.c b/arch/arm/mach-exynos/pmu.c
index 05c7ce1..f69a6ed 100644
--- a/arch/arm/mach-exynos/pmu.c
+++ b/arch/arm/mach-exynos/pmu.c
@@ -12,9 +12,14 @@
#include linux/io.h
#include linux/kernel.h
#include linux/bug.h
+#include linux/cpumask.h
+#include linux/delay.h
+#include linux/pm.h
#include plat/cpu.h
+#include asm/cputype.h
+
#include common.h
#include regs-pmu.h
@@ -318,6 +323,212 @@ static const struct exynos_pmu_conf
exynos5250_pmu_config[] = {
{ PMU_TABLE_END,},
};
+static const struct exynos_pmu_conf exynos5420_pmu_config[] = {
+ /* { .reg = address, .val = { AFTR, LPA, SLEEP } */
+ { EXYNOS5_ARM_CORE0_SYS_PWR_REG,{ 0x0, 0x0,
0x0} },
+ { EXYNOS5_DIS_IRQ_ARM_CORE0_LOCAL_SYS_PWR_REG, { 0x0, 0x0,
0x0} },
+ { EXYNOS5_DIS_IRQ_ARM_CORE0_CENTRAL_SYS_PWR_REG,{ 0x0, 0x0,
0x0} },
+ { EXYNOS5_ARM_CORE1_SYS_PWR_REG,{ 0x0, 0x0,
0x0} },
+ { EXYNOS5_DIS_IRQ_ARM_CORE1_LOCAL_SYS_PWR_REG, { 0x0, 0x0,
0x0} },
+ { EXYNOS5_DIS_IRQ_ARM_CORE1_CENTRAL_SYS_PWR_REG,{ 0x0, 0x0,
0x0} },
+ { EXYNOS5420_ARM_CORE2_SYS_PWR_REG, { 0x0, 0x0,
0x0} },
+ { EXYNOS5420_DIS_IRQ_ARM_CORE2_LOCAL_SYS_PWR_REG, { 0x0, 0x0,
0x0} },
+ { EXYNOS5420_DIS_IRQ_ARM_CORE2_CENTRAL_SYS_PWR_REG, { 0x0, 0x0,
0x0} },
+ { EXYNOS5420_ARM_CORE3_SYS_PWR_REG, { 0x0, 0x0,
0x0} },
+ { EXYNOS5420_DIS_IRQ_ARM_CORE3_LOCAL_SYS_PWR_REG, { 0x0, 0x0,
0x0} },
+ { EXYNOS5420_DIS_IRQ_ARM_CORE3_CENTRAL_SYS_PWR_REG, { 0x0, 0x0,
0x0} },
+ { EXYNOS5420_KFC_CORE0_SYS_PWR_REG, { 0x0, 0x0,
0x0} },
+ { EXYNOS5420_DIS_IRQ_KFC_CORE0_LOCAL_SYS_PWR_REG, { 0x0, 0x0,
0x0} },
+ { EXYNOS5420_DIS_IRQ_KFC_CORE0_CENTRAL_SYS_PWR_REG, { 0x0, 0x0,
0x0} },
+ { EXYNOS5420_KFC_CORE1_SYS_PWR_REG, { 0x0, 0x0,
0x0} },
+ { EXYNOS5420_DIS_IRQ_KFC_CORE1_LOCAL_SYS_PWR_REG, { 0x0, 0x0,
0x0} },
+ { EXYNOS5420_DIS_IRQ_KFC_CORE1_CENTRAL_SYS_PWR_REG, { 0x0, 0x0,
0x0} },
+ { EXYNOS5420_KFC_CORE2_SYS_PWR_REG, { 0x0, 0x0,
0x0} },
+ { EXYNOS5420_DIS_IRQ_KFC_CORE2_LOCAL_SYS_PWR_REG, { 0x0, 0x0,
0x0} },
+ { EXYNOS5420_DIS_IRQ_KFC_CORE2_CENTRAL_SYS_PWR_REG, { 0x0, 0x0,
0x0} },
+ { EXYNOS5420_KFC_CORE3_SYS_PWR_REG, { 0x0, 0x0,
0x0} },
+ { EXYNOS5420_DIS_IRQ_KFC_CORE3_LOCAL_SYS_PWR_REG, { 0x0, 0x0,
0x0} },
+ { EXYNOS5420_DIS_IRQ_KFC_CORE3_CENTRAL_SYS_PWR_REG, { 0x0, 0x0,
0x0} },
+ { EXYNOS5_ISP_ARM_SYS_PWR_REG, { 0x1, 0x0,
0x0} },
+ { EXYNOS5_DIS_IRQ_ISP_ARM_LOCAL_SYS_PWR_REG,{ 0x1, 0x0,
0x0} },
+ { EXYNOS5_DIS_IRQ_ISP_ARM_CENTRAL_SYS_PWR_REG, { 0x1, 0x0,
0x0} },
+ { EXYNOS5420_ARM_COMMON_SYS_PWR_REG,{ 0x0, 0x0,
0x0} },
+ { EXYNOS5420_KFC_COMMON_SYS_PWR_REG,{ 0x0, 0x0,
0x0} },
+ { EXYNOS5_ARM_L2_SYS_PWR_REG, { 0x0, 0x0,
0x0} },
+ {
Re: [PATCH V2 2/3] ARM: EXYNOS5: Support Suspend-to-RAM on EXYNOS5420
Hi Vikas,
Basically same comments as for the series for Exynos5260. Also see more
comments inline.
On 27.03.2014 07:13, Vikas Sajjan wrote:
Adds Suspend-to-RAM support for EXYNOS5420
Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com
Signed-off-by: Vikas Sajjan vikas.saj...@samsung.com
---
arch/arm/mach-exynos/pm.c| 148 ++
arch/arm/mach-exynos/regs-pmu.h |4 +-
arch/arm/plat-samsung/include/plat/map-s5p.h |2 +
drivers/clk/samsung/clk-exynos5420.c | 32 ++
4 files changed, 167 insertions(+), 19 deletions(-)
diff --git a/arch/arm/mach-exynos/pm.c b/arch/arm/mach-exynos/pm.c
index 15af0ce..aa3c2c8 100644
--- a/arch/arm/mach-exynos/pm.c
+++ b/arch/arm/mach-exynos/pm.c
@@ -59,6 +59,16 @@ static struct sleep_save exynos_core_save[] = {
SAVE_ITEM(S5P_SROM_BC3),
};
+static struct sleep_save exynos5420_cpustate_save[] = {
+ SAVE_ITEM(EXYNOS5420_VA_CPU_STATE),
+};
+
+static struct sleep_save exynos5420_reg_save[] = {
+ SAVE_ITEM(EXYNOS5_SYS_DISP1_BLK_CFG),
+ SAVE_ITEM(S5P_PMU_SPARE3),
+};
+
+
/*
* GIC wake-up support
*/
@@ -81,7 +91,7 @@ static int exynos_irq_set_wake(struct irq_data *data,
unsigned int state)
{
const struct exynos_wkup_irq *wkup_irq;
- if (soc_is_exynos5250())
+ if (soc_is_exynos5250() || soc_is_exynos5420())
wkup_irq = exynos5250_wkup_irq;
else
wkup_irq = exynos4_wkup_irq;
@@ -109,7 +119,15 @@ static int exynos_cpu_suspend(unsigned long arg)
outer_flush_all();
#endif
- if (soc_is_exynos5250())
+ /*
+* Clear IRAM register for cpu state so that primary CPU does
+* not enter low power start in U-Boot.
+* This is specific to exynos5420 SoC only.
+*/
+ if (soc_is_exynos5420())
+ __raw_writel(0x0, EXYNOS5420_VA_CPU_STATE);
+
+ if (soc_is_exynos5250() || soc_is_exynos5420())
flush_cache_all();
/* issue the standby signal into the pm unit. */
@@ -135,6 +153,20 @@ static void exynos_pm_prepare(void)
tmp = __raw_readl(EXYNOS5_JPEG_MEM_OPTION);
tmp = ~EXYNOS5_OPTION_USE_RETENTION;
__raw_writel(tmp, EXYNOS5_JPEG_MEM_OPTION);
+ } else if (soc_is_exynos5420()) {
+
nit: Unnecessary blank line.
+ s3c_pm_do_save(exynos5420_reg_save,
+ ARRAY_SIZE(exynos5420_reg_save));
+
+ /*
+* The cpu state needs to be saved and restored so that the
+* secondary CPUs will enter low power start. Though the U-Boot
+* is setting the cpu state with low power flag, the kernel
+* needs to restore it back in case, the primary cpu fails to
+* suspend for any reason
+*/
+ s3c_pm_do_save(exynos5420_cpustate_save,
+ ARRAY_SIZE(exynos5420_cpustate_save));
}
/* Set value of power down register for sleep mode */
@@ -145,11 +177,34 @@ static void exynos_pm_prepare(void)
/* ensure at least INFORM0 has the resume address */
__raw_writel(virt_to_phys(exynos_cpu_resume), S5P_INFORM0);
+
+ if (soc_is_exynos5420()) {
+
+ tmp = __raw_readl(EXYNOS5_ARM_L2_OPTION);
+ tmp = ~EXYNOS5_USE_RETENTION;
+ __raw_writel(tmp, EXYNOS5_ARM_L2_OPTION);
+
+ tmp = __raw_readl(EXYNOS5420_SFR_AXI_CGDIS1);
+ tmp |= EXYNOS5420_UFS;
+ __raw_writel(tmp, EXYNOS5420_SFR_AXI_CGDIS1);
+
+ tmp = __raw_readl(EXYNOS5420_ARM_COMMON_OPTION);
+ tmp = ~EXYNOS5420_L2RSTDISABLE_VALUE;
+ __raw_writel(tmp, EXYNOS5420_ARM_COMMON_OPTION);
+ tmp = __raw_readl(EXYNOS5420_FSYS2_OPTION);
+ tmp |= EXYNOS5420_EMULATION;
+ __raw_writel(tmp, EXYNOS5420_FSYS2_OPTION);
+ tmp = __raw_readl(EXYNOS5420_PSGEN_OPTION);
+ tmp |= EXYNOS5420_EMULATION;
+ __raw_writel(tmp, EXYNOS5420_PSGEN_OPTION);
+ }
+
}
static int exynos_pm_suspend(void)
{
unsigned long tmp;
+ unsigned long cluster_id;
/* Setting Central Sequence Register for power down mode */
@@ -159,10 +214,20 @@ static int exynos_pm_suspend(void)
/* Setting SEQ_OPTION register */
- tmp = (S5P_USE_STANDBY_WFI0 | S5P_USE_STANDBY_WFE0);
- __raw_writel(tmp, S5P_CENTRAL_SEQ_OPTION);
+ if (soc_is_exynos5420()) {
+ cluster_id = (read_cpuid(CPUID_MPIDR) 8) 0xf;
+ if (!cluster_id)
+ __raw_writel(EXYNOS5420_ARM_USE_STANDBY_WFI0,
+S5P_CENTRAL_SEQ_OPTION);
+ else
+ __raw_writel(EXYNOS5420_KFC_USE_STANDBY_WFI0,
+S5P_CENTRAL_SEQ_OPTION);
+ } else {
+
Re: [PATCH V2 2/3] ARM: EXYNOS5: Support Suspend-to-RAM on EXYNOS5420
One more thing. The change to the clock driver should be separated from
arch changes.
Best regards,
Tomasz
On 15.04.2014 21:03, Tomasz Figa wrote:
Hi Vikas,
Basically same comments as for the series for Exynos5260. Also see more
comments inline.
On 27.03.2014 07:13, Vikas Sajjan wrote:
Adds Suspend-to-RAM support for EXYNOS5420
Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com
Signed-off-by: Vikas Sajjan vikas.saj...@samsung.com
---
arch/arm/mach-exynos/pm.c| 148
++
arch/arm/mach-exynos/regs-pmu.h |4 +-
arch/arm/plat-samsung/include/plat/map-s5p.h |2 +
drivers/clk/samsung/clk-exynos5420.c | 32 ++
4 files changed, 167 insertions(+), 19 deletions(-)
diff --git a/arch/arm/mach-exynos/pm.c b/arch/arm/mach-exynos/pm.c
index 15af0ce..aa3c2c8 100644
--- a/arch/arm/mach-exynos/pm.c
+++ b/arch/arm/mach-exynos/pm.c
@@ -59,6 +59,16 @@ static struct sleep_save exynos_core_save[] = {
SAVE_ITEM(S5P_SROM_BC3),
};
+static struct sleep_save exynos5420_cpustate_save[] = {
+SAVE_ITEM(EXYNOS5420_VA_CPU_STATE),
+};
+
+static struct sleep_save exynos5420_reg_save[] = {
+SAVE_ITEM(EXYNOS5_SYS_DISP1_BLK_CFG),
+SAVE_ITEM(S5P_PMU_SPARE3),
+};
+
+
/*
* GIC wake-up support
*/
@@ -81,7 +91,7 @@ static int exynos_irq_set_wake(struct irq_data
*data, unsigned int state)
{
const struct exynos_wkup_irq *wkup_irq;
-if (soc_is_exynos5250())
+if (soc_is_exynos5250() || soc_is_exynos5420())
wkup_irq = exynos5250_wkup_irq;
else
wkup_irq = exynos4_wkup_irq;
@@ -109,7 +119,15 @@ static int exynos_cpu_suspend(unsigned long arg)
outer_flush_all();
#endif
-if (soc_is_exynos5250())
+/*
+ * Clear IRAM register for cpu state so that primary CPU does
+ * not enter low power start in U-Boot.
+ * This is specific to exynos5420 SoC only.
+ */
+if (soc_is_exynos5420())
+__raw_writel(0x0, EXYNOS5420_VA_CPU_STATE);
+
+if (soc_is_exynos5250() || soc_is_exynos5420())
flush_cache_all();
/* issue the standby signal into the pm unit. */
@@ -135,6 +153,20 @@ static void exynos_pm_prepare(void)
tmp = __raw_readl(EXYNOS5_JPEG_MEM_OPTION);
tmp = ~EXYNOS5_OPTION_USE_RETENTION;
__raw_writel(tmp, EXYNOS5_JPEG_MEM_OPTION);
+} else if (soc_is_exynos5420()) {
+
nit: Unnecessary blank line.
+s3c_pm_do_save(exynos5420_reg_save,
+ARRAY_SIZE(exynos5420_reg_save));
+
+/*
+ * The cpu state needs to be saved and restored so that the
+ * secondary CPUs will enter low power start. Though the U-Boot
+ * is setting the cpu state with low power flag, the kernel
+ * needs to restore it back in case, the primary cpu fails to
+ * suspend for any reason
+ */
+s3c_pm_do_save(exynos5420_cpustate_save,
+ARRAY_SIZE(exynos5420_cpustate_save));
}
/* Set value of power down register for sleep mode */
@@ -145,11 +177,34 @@ static void exynos_pm_prepare(void)
/* ensure at least INFORM0 has the resume address */
__raw_writel(virt_to_phys(exynos_cpu_resume), S5P_INFORM0);
+
+if (soc_is_exynos5420()) {
+
+tmp = __raw_readl(EXYNOS5_ARM_L2_OPTION);
+tmp = ~EXYNOS5_USE_RETENTION;
+__raw_writel(tmp, EXYNOS5_ARM_L2_OPTION);
+
+tmp = __raw_readl(EXYNOS5420_SFR_AXI_CGDIS1);
+tmp |= EXYNOS5420_UFS;
+__raw_writel(tmp, EXYNOS5420_SFR_AXI_CGDIS1);
+
+tmp = __raw_readl(EXYNOS5420_ARM_COMMON_OPTION);
+tmp = ~EXYNOS5420_L2RSTDISABLE_VALUE;
+__raw_writel(tmp, EXYNOS5420_ARM_COMMON_OPTION);
+tmp = __raw_readl(EXYNOS5420_FSYS2_OPTION);
+tmp |= EXYNOS5420_EMULATION;
+__raw_writel(tmp, EXYNOS5420_FSYS2_OPTION);
+tmp = __raw_readl(EXYNOS5420_PSGEN_OPTION);
+tmp |= EXYNOS5420_EMULATION;
+__raw_writel(tmp, EXYNOS5420_PSGEN_OPTION);
+}
+
}
static int exynos_pm_suspend(void)
{
unsigned long tmp;
+unsigned long cluster_id;
/* Setting Central Sequence Register for power down mode */
@@ -159,10 +214,20 @@ static int exynos_pm_suspend(void)
/* Setting SEQ_OPTION register */
-tmp = (S5P_USE_STANDBY_WFI0 | S5P_USE_STANDBY_WFE0);
-__raw_writel(tmp, S5P_CENTRAL_SEQ_OPTION);
+if (soc_is_exynos5420()) {
+cluster_id = (read_cpuid(CPUID_MPIDR) 8) 0xf;
+if (!cluster_id)
+__raw_writel(EXYNOS5420_ARM_USE_STANDBY_WFI0,
+ S5P_CENTRAL_SEQ_OPTION);
+else
+__raw_writel(EXYNOS5420_KFC_USE_STANDBY_WFI0,
+ S5P_CENTRAL_SEQ_OPTION);
+} else {
+tmp = (S5P_USE_STANDBY_WFI0 | S5P_USE_STANDBY_WFE0);
+__raw_writel(tmp, S5P_CENTRAL_SEQ_OPTION);
+}
-if (!soc_is_exynos5250()) {
+if (!(soc_is_exynos5250() || soc_is_exynos5420())) {
/* Save Power control register
Re: [PATCH V2 3/3] ARM: dts: Add node for GPIO keys on SMDK5420
Hi,
On 27.03.2014 07:13, Vikas Sajjan wrote:
From: Abhilash Kesavan a.kesa...@samsung.com
Add support for the suspend/resume button (SW7) on SMDK5420 using
gpio-keys driver.
Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com
Signed-off-by: Vikas Sajjan vikas.saj...@samsung.com
---
arch/arm/boot/dts/exynos5420-smdk5420.dts | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5420-smdk5420.dts
b/arch/arm/boot/dts/exynos5420-smdk5420.dts
index 6910485..5ae0dd4 100644
--- a/arch/arm/boot/dts/exynos5420-smdk5420.dts
+++ b/arch/arm/boot/dts/exynos5420-smdk5420.dts
@@ -158,6 +158,17 @@
};
};
+ gpio-keys {
+ compatible = gpio-keys;
+
+ wakeup {
Is wakeup the label of this key on the PCB? The label property below
would suggest otherwise. This should probably be called key-sw7 or
something like this.
Moreover, is this the only GPIO key on the board? If there are also
SW0-SW6, you should add them too.
+ label = SW7;
+ gpios = gpx0 0 1;
+ linux,code = 143; /* KEY_WAKEUP */
Why not use KEY_WAKEUP defined in include/dt-bindings/input/input.h
directly?
Best regards,
Tomasz
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] mfd: tps65090: Allow charger module to be used when no irq
On the ARM Chromebook tps65090 has two masters: the AP (the main
processor running linux) and the EC (the embedded controller). The AP
is allowed to mess with FETs but the EC is in charge of charge control.
The tps65090 interupt line is routed to both the AP and the EC, which
can cause quite a headache. Having two people adjusting masks and
acking interrupts is a recipe for disaster.
In the shipping kernel we had a hack to have the AP pay attention to
the IRQ but not to ack it. It also wasn't supposed to configure the
IRQ in any way. That hack allowed us to detect when the device was
charging without messing with the EC's state.
The current tps65090 infrastructure makes the above difficult, and it
was a bit of a hack to begin with. Rather than uglify the driver to
support it, just extend the driver's existing notion of no irq to
the charger. This makes the charger code poll every 2 seconds for AC
detect, which is sufficient.
Signed-off-by: Doug Anderson diand...@chromium.org
---
drivers/mfd/tps65090.c | 14 ++--
drivers/power/tps65090-charger.c | 76 +++-
2 files changed, 70 insertions(+), 20 deletions(-)
diff --git a/drivers/mfd/tps65090.c b/drivers/mfd/tps65090.c
index ba1a25d..c3cddb4 100644
--- a/drivers/mfd/tps65090.c
+++ b/drivers/mfd/tps65090.c
@@ -64,11 +64,16 @@ static struct resource charger_resources[] = {
}
};
-static const struct mfd_cell tps65090s[] = {
- {
+enum tps65090_cells {
+ PMIC = 0,
+ CHARGER = 1,
+};
+
+static struct mfd_cell tps65090s[] = {
+ [PMIC] = {
.name = tps65090-pmic,
},
- {
+ [CHARGER] = {
.name = tps65090-charger,
.num_resources = ARRAY_SIZE(charger_resources),
.resources = charger_resources[0],
@@ -211,6 +216,9 @@ static int tps65090_i2c_probe(struct i2c_client *client,
IRQ init failed with err: %d\n, ret);
return ret;
}
+ } else {
+ /* Don't tell children they have an IRQ that'll never fire */
+ tps65090s[CHARGER].num_resources = 0;
}
ret = mfd_add_devices(tps65090-dev, -1, tps65090s,
diff --git a/drivers/power/tps65090-charger.c b/drivers/power/tps65090-charger.c
index 8fc9d6d..cc26c12 100644
--- a/drivers/power/tps65090-charger.c
+++ b/drivers/power/tps65090-charger.c
@@ -17,9 +17,11 @@
*/
#include linux/delay.h
#include linux/err.h
+#include linux/freezer.h
#include linux/init.h
#include linux/interrupt.h
#include linux/kernel.h
+#include linux/kthread.h
#include linux/module.h
#include linux/of_device.h
#include linux/platform_device.h
@@ -43,11 +45,15 @@
#define TPS65090_VACG BIT(1)
#define TPS65090_NOITERM BIT(5)
+#define POLL_INTERVAL (HZ * 2)/* Used when no irq */
+
struct tps65090_charger {
struct device *dev;
int ac_online;
int prev_ac_online;
int irq;
+ struct task_struct *poll_task;
+ boolpassive_mode;
struct power_supply ac;
struct tps65090_platform_data *pdata;
};
@@ -60,6 +66,9 @@ static int tps65090_low_chrg_current(struct tps65090_charger
*charger)
{
int ret;
+ if (charger-passive_mode)
+ return 0;
+
ret = tps65090_write(charger-dev-parent, TPS65090_REG_CG_CTRL5,
TPS65090_NOITERM);
if (ret 0) {
@@ -75,6 +84,9 @@ static int tps65090_enable_charging(struct tps65090_charger
*charger)
int ret;
uint8_t ctrl0 = 0;
+ if (charger-passive_mode)
+ return 0;
+
ret = tps65090_read(charger-dev-parent, TPS65090_REG_CG_CTRL0,
ctrl0);
if (ret 0) {
@@ -98,6 +110,9 @@ static int tps65090_config_charger(struct tps65090_charger
*charger)
uint8_t intrmask = 0;
int ret;
+ if (charger-passive_mode)
+ return 0;
+
if (charger-pdata-enable_low_current_chrg) {
ret = tps65090_low_chrg_current(charger);
if (ret 0) {
@@ -175,10 +190,14 @@ static irqreturn_t tps65090_charger_isr(int irq, void
*dev_id)
}
/* Clear interrupts. */
- ret = tps65090_write(charger-dev-parent, TPS65090_REG_INTR_STS, 0x00);
- if (ret 0) {
- dev_err(charger-dev, %s(): Error in writing reg 0x%x\n,
+ if (!charger-passive_mode) {
+ ret = tps65090_write(charger-dev-parent,
+TPS65090_REG_INTR_STS, 0x00);
+ if (ret 0) {
+ dev_err(charger-dev,
+ %s(): Error in writing reg 0x%x\n,
__func__, TPS65090_REG_INTR_STS);
+ }
}
if (charger-prev_ac_online != charger-ac_online)
@@ -209,6 +228,18 @@ static
[PATCH 3/3] regulator: tps65090: Make FETs more reliable
An issue was discovered with tps65090 where sometimes the FETs
wouldn't actually turn on when requested. The most problematic FET
was the one use for the LCD backlight on the Samsung ARM Chromebook
(FET1). Problems were especially prevalent when the device was
plugged in to AC power, making the backlight voltage higher.
Mitigate the problem by:
* Allow setting the overcurrent wait time so devices with this problem
can set it to the max.
* Add retry logic on enables of FETs.
Signed-off-by: Doug Anderson diand...@chromium.org
Signed-off-by: Simon Glass s...@chromium.org
Signed-off-by: Michael Spang sp...@chromium.org
Signed-off-by: Sean Paul seanp...@chromium.org
---
.../devicetree/bindings/regulator/tps65090.txt | 4 +
drivers/regulator/tps65090-regulator.c | 197 +++--
include/linux/mfd/tps65090.h | 5 +
3 files changed, 194 insertions(+), 12 deletions(-)
diff --git a/Documentation/devicetree/bindings/regulator/tps65090.txt
b/Documentation/devicetree/bindings/regulator/tps65090.txt
index 313a60b..34098023 100644
--- a/Documentation/devicetree/bindings/regulator/tps65090.txt
+++ b/Documentation/devicetree/bindings/regulator/tps65090.txt
@@ -21,6 +21,10 @@ Optional properties:
number should be provided. If it is externally controlled and no GPIO
entry then driver will just configure this rails as external control
and will not provide any enable/disable APIs.
+- ti,overcurrent-wait: This is applicable to FET registers, which have a
+ poorly defined overcurrent wait field. If this property is present it
+ should be between 0 - 3. If this property isn't present we won't touch the
+ overcurrent wait field and we'll leave it to the BIOS/EC to deal with.
Each regulator is defined using the standard binding for regulators.
diff --git a/drivers/regulator/tps65090-regulator.c
b/drivers/regulator/tps65090-regulator.c
index 2e92ef6..e8d1c62 100644
--- a/drivers/regulator/tps65090-regulator.c
+++ b/drivers/regulator/tps65090-regulator.c
@@ -17,6 +17,7 @@
*/
#include linux/module.h
+#include linux/delay.h
#include linux/init.h
#include linux/gpio.h
#include linux/of_gpio.h
@@ -28,21 +29,186 @@
#include linux/regulator/of_regulator.h
#include linux/mfd/tps65090.h
+#define MAX_CTRL_READ_TRIES5
+#define MAX_FET_ENABLE_TRIES 1000
+
+#define CTRL_EN_BIT0 /* Regulator enable bit, active high */
+#define CTRL_WT_BIT2 /* Regulator wait time 0 bit */
+#define CTRL_PG_BIT4 /* Regulator power good bit, 1=good */
+#define CTRL_TO_BIT7 /* Regulator timeout bit, 1=wait */
+
+#define MAX_OVERCURRENT_WAIT 3 /* Overcurrent wait must be less than this */
+
+/**
+ * struct tps65090_regulator - Per-regulator data for a tps65090 regulator
+ *
+ * @dev: Pointer to our device.
+ * @desc: The struct regulator_desc for the regulator.
+ * @rdev: The struct regulator_dev for the regulator.
+ * @overcurrent_wait_valid: True if overcurrent_wait is valid.
+ * @overcurrent_wait: For FETs, the value to put in the WTFET bitfield.
+ */
+
struct tps65090_regulator {
struct device *dev;
struct regulator_desc *desc;
struct regulator_dev*rdev;
+ boolovercurrent_wait_valid;
+ int overcurrent_wait;
};
static struct regulator_ops tps65090_ext_control_ops = {
};
-static struct regulator_ops tps65090_reg_contol_ops = {
+/**
+ * tps65090_fet_is_enabled - Tell if a fet is enabled
+ *
+ * @rdev: Regulator device
+ * @return true if the fet is enabled and its power is good; false otherwise.
+ */
+static int tps65090_fet_is_enabled(struct regulator_dev *rdev)
+{
+ unsigned int control;
+ unsigned int expected = rdev-desc-enable_mask | BIT(CTRL_PG_BIT);
+ int ret;
+
+ ret = regmap_read(rdev-regmap, rdev-desc-enable_reg, control);
+ if (ret != 0)
+ return ret;
+
+ return (control expected) == expected;
+}
+
+/**
+ * tps65090_reg_set_overcurrent_wait - Setup overcurrent wait
+ *
+ * This will set the overcurrent wait time based on what's in the regulator
+ * info.
+ *
+ * @rdev: Regulator device
+ * @return 0 if no error, non-zero if there was an error writing the register.
+ */
+static int tps65090_reg_set_overcurrent_wait(struct regulator_dev *rdev)
+{
+ struct tps65090_regulator *ri = rdev_get_drvdata(rdev);
+ int ret;
+
+ if (!ri-overcurrent_wait_valid)
+ return 0;
+
+ ret = regmap_update_bits(rdev-regmap, rdev-desc-enable_reg,
+MAX_OVERCURRENT_WAIT CTRL_WT_BIT,
+ri-overcurrent_wait CTRL_WT_BIT);
+ if (ret) {
+ dev_err(rdev-dev, Error updating overcurrent wait %#x\n,
+ rdev-desc-enable_reg);
+ }
+
+ return ret;
+}
+
+/**
+ * tps6090_try_enable_fet - Try to enable a FET
+ *
+ * @rdev: Regulator
[PATCH 2/3] mfd: tps65090: Stop caching registers
Nearly all of the registers in tps65090 combine control bits and
status bits. Turn off caching of registers so that we can read status
bits reliably.
NOTE: the IRQnMASK and CG_CTRLn registers are the exception and could
be cached. If we find that we spend a lot of time reading those we
can turn on cache for just those registers.
Signed-off-by: Doug Anderson diand...@chromium.org
---
drivers/mfd/tps65090.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/drivers/mfd/tps65090.c b/drivers/mfd/tps65090.c
index c3cddb4..4cfdd07 100644
--- a/drivers/mfd/tps65090.c
+++ b/drivers/mfd/tps65090.c
@@ -149,21 +149,11 @@ static struct regmap_irq_chip tps65090_irq_chip = {
.mask_invert = true,
};
-static bool is_volatile_reg(struct device *dev, unsigned int reg)
-{
- if ((reg == TPS65090_INT_STS) || (reg == TPS65090_INT_STS2))
- return true;
- else
- return false;
-}
-
static const struct regmap_config tps65090_regmap_config = {
.reg_bits = 8,
.val_bits = 8,
.max_register = TOTAL_NUM_REG,
.num_reg_defaults_raw = TOTAL_NUM_REG,
- .cache_type = REGCACHE_RBTREE,
- .volatile_reg = is_volatile_reg,
};
#ifdef CONFIG_OF
--
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 0/3] Fixes for tps65090 for Samsung ARM Chromebook
These three patches bring tps65090 up to speed with what's currently in the Chromium OS kernel 3.8 tree and running on the Samsung ARM Chromebook. Changes were tested atop the current linux tree (v3.15-rc1). FET retries were tested on a machine with a known flaky tps65090. Since display isn't working on pure upstream, I augmented the code to turn FET1 (vcd_led) on/off 500 times at bootup. When testing I included https://patchwork.kernel.org/patch/3980731/ to make sure tps65090 was in exynos5250-snow's device tree. Doug Anderson (3): mfd: tps65090: Allow charger module to be used when no irq mfd: tps65090: Stop caching registers regulator: tps65090: Make FETs more reliable .../devicetree/bindings/regulator/tps65090.txt | 4 + drivers/mfd/tps65090.c | 24 ++- drivers/power/tps65090-charger.c | 76 ++-- drivers/regulator/tps65090-regulator.c | 197 +++-- include/linux/mfd/tps65090.h | 5 + 5 files changed, 264 insertions(+), 42 deletions(-) -- 1.9.1.423.g4596e3a -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] ARM: dts: exynos5250-snow: add tps65090 power regulator
Sachin, On Mon, Apr 14, 2014 at 6:16 AM, Sachin Kamat sachin.ka...@linaro.org wrote: From: Doug Anderson diand...@chromium.org Added TPS65090 regulator related nodes to Snow board. Signed-off-by: Doug Anderson diand...@chromium.org Signed-off-by: Sachin Kamat sachin.ka...@linaro.org --- arch/arm/boot/dts/exynos5250-snow.dts | 90 + 1 file changed, 90 insertions(+) I've now sent up the relevant patches: * https://patchwork.kernel.org/patch/3995361/ * https://patchwork.kernel.org/patch/3995401/ * https://patchwork.kernel.org/patch/3995411/ So assuming those land then I think we're all good with this one. I've also done basic testing with it. Reviewed-by: Doug Anderson diand...@chromium.org Tested-by: Doug Anderson diand...@chromium.org -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/8] cpufreq: Use cpufreq_for_each_* macros for frequency table iteration
The cpufreq core now supports the cpufreq_for_each_entry and
cpufreq_for_each_valid_entry macros helpers for iteration over the
cpufreq_frequency_table, so use them.
It should have no functional changes.
Signed-off-by: Stratos Karafotis strat...@semaphore.gr
---
drivers/cpufreq/acpi-cpufreq.c | 9 +++---
drivers/cpufreq/arm_big_little.c | 16 +--
drivers/cpufreq/cpufreq_stats.c | 24 ++--
drivers/cpufreq/dbx500-cpufreq.c | 8 ++
drivers/cpufreq/elanfreq.c | 9 +++---
drivers/cpufreq/exynos-cpufreq.c | 11 ---
drivers/cpufreq/exynos5440-cpufreq.c | 30 +--
drivers/cpufreq/freq_table.c | 56
drivers/cpufreq/longhaul.c | 13 -
drivers/cpufreq/pasemi-cpufreq.c | 10 +++
drivers/cpufreq/powernow-k6.c| 14 -
drivers/cpufreq/ppc_cbe_cpufreq.c| 9 +++---
drivers/cpufreq/s3c2416-cpufreq.c| 40 +++---
drivers/cpufreq/s3c64xx-cpufreq.c| 15 --
14 files changed, 117 insertions(+), 147 deletions(-)
diff --git a/drivers/cpufreq/acpi-cpufreq.c b/drivers/cpufreq/acpi-cpufreq.c
index 000e4e0..b0c18ed 100644
--- a/drivers/cpufreq/acpi-cpufreq.c
+++ b/drivers/cpufreq/acpi-cpufreq.c
@@ -213,7 +213,7 @@ static unsigned extract_io(u32 value, struct
acpi_cpufreq_data *data)
static unsigned extract_msr(u32 msr, struct acpi_cpufreq_data *data)
{
- int i;
+ struct cpufreq_frequency_table *pos;
struct acpi_processor_performance *perf;
if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD)
@@ -223,10 +223,9 @@ static unsigned extract_msr(u32 msr, struct
acpi_cpufreq_data *data)
perf = data-acpi_data;
- for (i = 0; data-freq_table[i].frequency != CPUFREQ_TABLE_END; i++) {
- if (msr == perf-states[data-freq_table[i].driver_data].status)
- return data-freq_table[i].frequency;
- }
+ cpufreq_for_each_entry(pos, data-freq_table)
+ if (msr == perf-states[pos-driver_data].status)
+ return pos-frequency;
return data-freq_table[0].frequency;
}
diff --git a/drivers/cpufreq/arm_big_little.c b/drivers/cpufreq/arm_big_little.c
index bad2ed3..1f4d4e3 100644
--- a/drivers/cpufreq/arm_big_little.c
+++ b/drivers/cpufreq/arm_big_little.c
@@ -226,22 +226,22 @@ static inline u32 get_table_count(struct
cpufreq_frequency_table *table)
/* get the minimum frequency in the cpufreq_frequency_table */
static inline u32 get_table_min(struct cpufreq_frequency_table *table)
{
- int i;
+ struct cpufreq_frequency_table *pos;
uint32_t min_freq = ~0;
- for (i = 0; (table[i].frequency != CPUFREQ_TABLE_END); i++)
- if (table[i].frequency min_freq)
- min_freq = table[i].frequency;
+ cpufreq_for_each_entry(pos, table)
+ if (pos-frequency min_freq)
+ min_freq = pos-frequency;
return min_freq;
}
/* get the maximum frequency in the cpufreq_frequency_table */
static inline u32 get_table_max(struct cpufreq_frequency_table *table)
{
- int i;
+ struct cpufreq_frequency_table *pos;
uint32_t max_freq = 0;
- for (i = 0; (table[i].frequency != CPUFREQ_TABLE_END); i++)
- if (table[i].frequency max_freq)
- max_freq = table[i].frequency;
+ cpufreq_for_each_entry(pos, table)
+ if (pos-frequency max_freq)
+ max_freq = pos-frequency;
return max_freq;
}
diff --git a/drivers/cpufreq/cpufreq_stats.c b/drivers/cpufreq/cpufreq_stats.c
index ecaaebf..0cd9b4d 100644
--- a/drivers/cpufreq/cpufreq_stats.c
+++ b/drivers/cpufreq/cpufreq_stats.c
@@ -182,11 +182,11 @@ static void cpufreq_stats_free_table(unsigned int cpu)
static int __cpufreq_stats_create_table(struct cpufreq_policy *policy)
{
- unsigned int i, j, count = 0, ret = 0;
+ unsigned int i, count = 0, ret = 0;
struct cpufreq_stats *stat;
unsigned int alloc_size;
unsigned int cpu = policy-cpu;
- struct cpufreq_frequency_table *table;
+ struct cpufreq_frequency_table *pos, *table;
table = cpufreq_frequency_get_table(cpu);
if (unlikely(!table))
@@ -205,12 +205,8 @@ static int __cpufreq_stats_create_table(struct
cpufreq_policy *policy)
stat-cpu = cpu;
per_cpu(cpufreq_stats_table, cpu) = stat;
- for (i = 0; table[i].frequency != CPUFREQ_TABLE_END; i++) {
- unsigned int freq = table[i].frequency;
- if (freq == CPUFREQ_ENTRY_INVALID)
- continue;
+ cpufreq_for_each_valid_entry(pos, table)
count++;
- }
alloc_size = count * sizeof(int) + count * sizeof(u64);
@@ -228,15 +224,11 @@ static int __cpufreq_stats_create_table(struct
cpufreq_policy *policy)
#ifdef
Re: [PATCH 3/3] regulator: tps65090: Make FETs more reliable
On Tue, Apr 15, 2014 at 01:14:36PM -0700, Doug Anderson wrote:
Mitigate the problem by:
* Allow setting the overcurrent wait time so devices with this problem
can set it to the max.
* Add retry logic on enables of FETs.
This is two changes, should really be two patches.
+- ti,overcurrent-wait: This is applicable to FET registers, which have a
+ poorly defined overcurrent wait field. If this property is present it
+ should be between 0 - 3. If this property isn't present we won't touch the
+ overcurrent wait field and we'll leave it to the BIOS/EC to deal with.
I take it this is the raw value to write to the register?
+static int tps65090_fet_is_enabled(struct regulator_dev *rdev)
+{
+ unsigned int control;
+ unsigned int expected = rdev-desc-enable_mask | BIT(CTRL_PG_BIT);
+ int ret;
+
+ ret = regmap_read(rdev-regmap, rdev-desc-enable_reg, control);
+ if (ret != 0)
+ return ret;
+
+ return (control expected) == expected;
+}
No need to open code this, regulator_is_enabled_regmap() can check for
any value in a bitfield.
+static int tps6090_try_enable_fet(struct regulator_dev *rdev)
Why is this called tps6090_try_enable_fet(), looks like a missing 5?
+ /*
+ * Try enabling multiple times until we succeed since sometimes the
+ * first try times out.
+ */
+ for (tries = 0; ; tries++) {
+ ret = tps6090_try_enable_fet(rdev);
+ if (!ret)
+ break;
+ if (ret != -ENOTRECOVERABLE || tries == MAX_FET_ENABLE_TRIES)
+ goto err;
Make this a do { } while so we don't have the exit condition missing in
the for loop please, it's doing the right thing but it's not as obvious
as it could be.
+ if (tries) {
+ dev_warn(rdev-dev, reg %#x enable ok after %d tries\n,
+ rdev-desc-enable_reg, tries);
+ }
No need for braces here, and I guess that ought to be retries rather
than tries (though that is pedantry).
signature.asc
Description: Digital signature
Re: [PATCH] Exynos4: cpuidle: support dual CPUs with AFTR state
On Tue, 15 Apr 2014 18:38:39 +0200
Daniel Lezcano daniel.lezc...@linaro.org wrote:
On 04/15/2014 05:54 PM, Lukasz Majewski wrote:
Hi Daniel,
On 04/15/2014 08:37 AM, Lukasz Majewski wrote:
Hi Daniel,
The following driver is for exynos4210. I did not yet finished
the other boards, so I created a specific driver for 4210 which
could be merged later.
If I may ask - do you plan to develop this code for Exynos4412 in
a near future?
Yes it is in my plan.
I did some tests (with hotplug) and it turns out, that due to
static leakage current one can save up to 12 % of power
consumption when power domains for cores are disabled.
Such notable power consumption reduction could drive (and justify)
the further development of power aware scheduling code.
If you don't have time, then I can offer myself to develop the
code. I just want to avoid potential duplication of effort.
I would be very glad if we can cooperate. Thanks for proposing your
help.
You are welcome :-)
I have put a branch containing the cleanups + driver moving + dual
cpu support, so you can base your work in it.
git://git.linaro.org/people/daniel.lezcano/linux.git
cpuidle/samsung-next
Thanks for sharing code. I will look into it.
I am wondering if the 5250 board wouldn't make sense as a primary
target before the 4412...
I'm working on a device based on 4412, not 5250. Therefore, I would
prefer to have this concept implemented on 4412 as soon as possible
to not hinder my scheduler related experiments.
If you have other priorities, then we can split the work. What do
you think?
It is ok for me if you want to handle the cpuidle driver 4412.
Ok. Thanks :-)
Will
you create a new driver or extend this dual cpu driver to support 4
cpus ?
For the beginning, I will try to extend the solution proposed for
Exynos4210.
However, because of the Easter break, the code will be delivered at
next week.
The driver is based on Colin Cross's driver found at:
https://android.googlesource.com/kernel/exynos/+/e686b1ec67423c40b4fdf811f9a4dfa3b393a010%5E%5E!/
This one was based on a 3.4 kernel and an old API.
It has been refreshed, simplified and based on the recent code
cleanup I sent today.
The AFTR could be entered when all the cpus (except cpu0) are
down. In order to reach this situation, the couple idle states
are used.
There is a sync barrier at the entry and the exit of the low
power function. So all cpus will enter and exit the function at
the same time.
At this point, CPU0 knows the other cpu will power down itself.
CPU0 waits for the CPU1 to be powered down and then initiate the
AFTR power down sequence.
No interrupts are handled by CPU1, this is why we switch to the
timer broadcast even if the local timer is not impacted by the
idle state.
When CPU0 wakes up, it powers up CPU1 and waits for it to boot.
Then they both exit the idle function.
This driver allows the exynos4210 to have the same power
consumption at idle time than the one when we have to unplug CPU1
in order to let CPU0 to reach the AFTR state.
This patch is a RFC because, we have to find a way to remove the
macros definitions and cpu powerdown function without pulling the
arch dependent headers.
Signed-off-by: Daniel Lezcano daniel.lezc...@linaro.org
---
arch/arm/mach-exynos/common.c| 11 +-
drivers/cpuidle/Kconfig.arm |8 ++
drivers/cpuidle/Makefile |1 +
drivers/cpuidle/cpuidle-exynos4210.c | 226
++ 4 files changed, 245
insertions(+), 1 deletion(-) create mode 100644
drivers/cpuidle/cpuidle-exynos4210.c
diff --git a/arch/arm/mach-exynos/common.c
b/arch/arm/mach-exynos/common.c index d5fa21e..1765a98 100644
--- a/arch/arm/mach-exynos/common.c
+++ b/arch/arm/mach-exynos/common.c
@@ -299,9 +299,18 @@ static struct platform_device exynos_cpuidle
= { .id= -1,
};
+static struct platform_device exynos4210_cpuidle = {
+ .name = exynos4210-cpuidle,
+ .dev.platform_data = exynos_sys_powerdown_aftr,
+ .id= -1,
+};
+
void __init exynos_cpuidle_init(void)
{
- platform_device_register(exynos_cpuidle);
+ if (soc_is_exynos4210())
+ platform_device_register(exynos4210_cpuidle);
+ else
+ platform_device_register(exynos_cpuidle);
}
void __init exynos_cpufreq_init(void)
diff --git a/drivers/cpuidle/Kconfig.arm
b/drivers/cpuidle/Kconfig.arm index 92f0c12..2772130 100644
--- a/drivers/cpuidle/Kconfig.arm
+++ b/drivers/cpuidle/Kconfig.arm
@@ -51,3 +51,11 @@ config ARM_EXYNOS_CPUIDLE
depends on ARCH_EXYNOS
help
Select this to enable cpuidle for Exynos processors
+
+config ARM_EXYNOS4210_CPUIDLE
+ bool Cpu Idle
Re: [PATCHv2 1/2] iio: adc: exynos_adc: Control special clock of ADC to support Exynos3250 ADC
Hi Jonathan,
Any comment of this patchset?
Best Regards,
Chanwoo Choi
On 04/14/2014 06:07 PM, Chanwoo Choi wrote:
This patch control special clock for ADC in Exynos series's FSYS block.
If special clock of ADC is registerd on clock list of common clk framework,
Exynos ADC drvier have to control this clock.
Exynos3250/Exynos4/Exynos5 has 'adc' clock as following:
- 'adc' clock: bus clock for ADC
Exynos3250 has additional 'sclk_tsadc' clock as following:
- 'sclk_tsadc' clock: special clock for ADC which provide clock to internal
ADC
Exynos 4210/4212/4412 and Exynos5250/5420 has not included 'sclk_tsadc' clock
in FSYS_BLK. But, Exynos3250 based on Cortex-A7 has only included 'sclk_tsadc'
clock in FSYS_BLK.
Cc: Jonathan Cameron ji...@kernel.org
Cc: Kukjin Kim kgene@samsung.com
Cc: Naveen Krishna Chatradhi
Cc: linux-...@vger.kernel.org
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/iio/adc/exynos_adc.c | 54
+---
1 file changed, 41 insertions(+), 13 deletions(-)
diff --git a/drivers/iio/adc/exynos_adc.c b/drivers/iio/adc/exynos_adc.c
index d25b262..3c99243 100644
--- a/drivers/iio/adc/exynos_adc.c
+++ b/drivers/iio/adc/exynos_adc.c
@@ -40,8 +40,9 @@
#include linux/iio/driver.h
enum adc_version {
- ADC_V1,
- ADC_V2
+ ADC_V1 = 0x1,
+ ADC_V2 = 0x2,
+ ADC_V3 = (ADC_V1 | ADC_V2),
};
/* EXYNOS4412/5250 ADC_V1 registers definitions */
@@ -88,6 +89,7 @@ struct exynos_adc {
void __iomem*regs;
void __iomem*enable_reg;
struct clk *clk;
+ struct clk *sclk;
unsigned intirq;
struct regulator*vdd;
@@ -100,6 +102,7 @@ struct exynos_adc {
static const struct of_device_id exynos_adc_match[] = {
{ .compatible = samsung,exynos-adc-v1, .data = (void *)ADC_V1 },
{ .compatible = samsung,exynos-adc-v2, .data = (void *)ADC_V2 },
+ { .compatible = samsung,exynos-adc-v3, .data = (void *)ADC_V3 },
{},
};
MODULE_DEVICE_TABLE(of, exynos_adc_match);
@@ -128,7 +131,7 @@ static int exynos_read_raw(struct iio_dev *indio_dev,
mutex_lock(indio_dev-mlock);
/* Select the channel to be used and Trigger conversion */
- if (info-version == ADC_V2) {
+ if (info-version ADC_V2) {
con2 = readl(ADC_V2_CON2(info-regs));
con2 = ~ADC_V2_CON2_ACH_MASK;
con2 |= ADC_V2_CON2_ACH_SEL(chan-address);
@@ -165,7 +168,7 @@ static irqreturn_t exynos_adc_isr(int irq, void *dev_id)
info-value = readl(ADC_V1_DATX(info-regs))
ADC_DATX_MASK;
/* clear irq */
- if (info-version == ADC_V2)
+ if (info-version ADC_V2)
writel(1, ADC_V2_INT_ST(info-regs));
else
writel(1, ADC_V1_INTCLR(info-regs));
@@ -226,11 +229,25 @@ static int exynos_adc_remove_devices(struct device
*dev, void *c)
return 0;
}
+static void exynos_adc_enable_clock(struct exynos_adc *info, bool enable)
+{
+ if (enable) {
+ clk_prepare_enable(info-clk);
+ if (info-version == ADC_V3)
+ clk_prepare_enable(info-sclk);
+
+ } else {
+ if (info-version == ADC_V3)
+ clk_disable_unprepare(info-sclk);
+ clk_disable_unprepare(info-clk);
+ }
+}
+
static void exynos_adc_hw_init(struct exynos_adc *info)
{
u32 con1, con2;
- if (info-version == ADC_V2) {
+ if (info-version ADC_V2) {
con1 = ADC_V2_CON1_SOFT_RESET;
writel(con1, ADC_V2_CON1(info-regs));
@@ -300,6 +317,8 @@ static int exynos_adc_probe(struct platform_device *pdev)
writel(1, info-enable_reg);
+ info-version = exynos_adc_get_version(pdev);
+
info-clk = devm_clk_get(pdev-dev, adc);
if (IS_ERR(info-clk)) {
dev_err(pdev-dev, failed getting clock, err = %ld\n,
@@ -308,6 +327,17 @@ static int exynos_adc_probe(struct platform_device *pdev)
goto err_irq;
}
+ if (info-version == ADC_V3) {
+ info-sclk = devm_clk_get(pdev-dev, sclk_tsadc);
+ if (IS_ERR(info-sclk)) {
+ dev_warn(pdev-dev,
+ failed getting sclk clock, err = %ld\n,
+ PTR_ERR(info-sclk));
+ ret = PTR_ERR(info-sclk);
+ goto err_irq;
+ }
+ }
+
info-vdd = devm_regulator_get(pdev-dev, vdd);
if (IS_ERR(info-vdd)) {
dev_err(pdev-dev, failed getting regulator, err = %ld\n,
@@ -316,8 +346,6 @@ static int exynos_adc_probe(struct platform_device *pdev)
goto err_irq;
}
- info-version = exynos_adc_get_version(pdev);
-
Re: [PATCHv2 4/4] drm: exynos: hdmi: add support for pixel clock limitation
On 15 April 2014 19:59, Tomasz Stanislawski t.stanisl...@samsung.com wrote:
On 04/15/2014 03:42 PM, Rahul Sharma wrote:
On 15 April 2014 18:41, Tomasz Stanislawski t.stanisl...@samsung.com wrote:
On 04/15/2014 11:42 AM, Rahul Sharma wrote:
Hi Tomasz,
On 15 April 2014 14:57, Tomasz Stanislawski t.stanisl...@samsung.com
wrote:
Adds support for limitation of maximal pixel clock of HDMI
signal. This feature is needed on boards that contains
lines or bridges with frequency limitations.
Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
[snip]
diff --git a/include/media/s5p_hdmi.h b/include/media/s5p_hdmi.h
index 181642b..7272d65 100644
--- a/include/media/s5p_hdmi.h
+++ b/include/media/s5p_hdmi.h
@@ -31,6 +31,7 @@ struct s5p_hdmi_platform_data {
int mhl_bus;
struct i2c_board_info *mhl_info;
int hpd_gpio;
+ u32 max_pixel_clock;
};
We have already removed Non DT support from the drm hdmi
driver. IMO we should not be extending the pdata struct.
Regards,
Rahul Sharma
Hi Rahul,
This is not a non-DT patch. The s5p_hdmi_platform_data is
generated from DT itself. This structure is just
a parsed version of DT attributes.
It may be a good idea to rename s5p_hdmi_platform_data
to exynos_hdmi_pdata and move it to exynos_hdmi_drm.c file
or parse DT directly in probe function.
I can prepare a patch for that.
Else we can completely remove the dependency from
s5p_hdmi_platform_data. We can directly assign to hdmi context
variables. Later we can remove that struct itself from include/.
What you say?
This structure cannot be removed from include yet because it is used by
s5p-tv driver.
However its usage can be removed from both drivers.
I can prepare both.
yea correct. but if you doing it for both of them, it can be removed, I guess.
your call.
Regards,
Rahul Sharma
Regards,
Rahul Sharma
Regards,
Tomasz Stanislawski
Regards,
Tomasz Stanislawski
#endif /* S5P_HDMI_H */
--
1.7.9.5
___
dri-devel mailing list
dri-de...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 1/2] iio: adc: exynos_adc: Control special clock of ADC to support Exynos3250 ADC
Hi Chanwoo,
On 14 April 2014 14:37, Chanwoo Choi cw00.c...@samsung.com wrote:
This patch control special clock for ADC in Exynos series's FSYS block.
If special clock of ADC is registerd on clock list of common clk framework,
Exynos ADC drvier have to control this clock.
Exynos3250/Exynos4/Exynos5 has 'adc' clock as following:
- 'adc' clock: bus clock for ADC
Exynos3250 has additional 'sclk_tsadc' clock as following:
- 'sclk_tsadc' clock: special clock for ADC which provide clock to internal
ADC
Exynos 4210/4212/4412 and Exynos5250/5420 has not included 'sclk_tsadc' clock
in FSYS_BLK. But, Exynos3250 based on Cortex-A7 has only included 'sclk_tsadc'
clock in FSYS_BLK.
Cc: Jonathan Cameron ji...@kernel.org
Cc: Kukjin Kim kgene@samsung.com
Cc: Naveen Krishna Chatradhi
Cc: linux-...@vger.kernel.org
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/iio/adc/exynos_adc.c | 54
+---
1 file changed, 41 insertions(+), 13 deletions(-)
diff --git a/drivers/iio/adc/exynos_adc.c b/drivers/iio/adc/exynos_adc.c
index d25b262..3c99243 100644
--- a/drivers/iio/adc/exynos_adc.c
+++ b/drivers/iio/adc/exynos_adc.c
@@ -40,8 +40,9 @@
#include linux/iio/driver.h
enum adc_version {
- ADC_V1,
- ADC_V2
+ ADC_V1 = 0x1,
+ ADC_V2 = 0x2,
+ ADC_V3 = (ADC_V1 | ADC_V2),
Can't this be simply 0x3? Or is this not really a h/w version?
};
/* EXYNOS4412/5250 ADC_V1 registers definitions */
@@ -88,6 +89,7 @@ struct exynos_adc {
void __iomem*regs;
void __iomem*enable_reg;
struct clk *clk;
+ struct clk *sclk;
unsigned intirq;
struct regulator*vdd;
@@ -100,6 +102,7 @@ struct exynos_adc {
static const struct of_device_id exynos_adc_match[] = {
{ .compatible = samsung,exynos-adc-v1, .data = (void *)ADC_V1 },
{ .compatible = samsung,exynos-adc-v2, .data = (void *)ADC_V2 },
+ { .compatible = samsung,exynos-adc-v3, .data = (void *)ADC_V3 },
{},
};
MODULE_DEVICE_TABLE(of, exynos_adc_match);
@@ -128,7 +131,7 @@ static int exynos_read_raw(struct iio_dev *indio_dev,
mutex_lock(indio_dev-mlock);
/* Select the channel to be used and Trigger conversion */
- if (info-version == ADC_V2) {
+ if (info-version ADC_V2) {
So, now this would be applicable for ADC_V3 too, right?
con2 = readl(ADC_V2_CON2(info-regs));
con2 = ~ADC_V2_CON2_ACH_MASK;
con2 |= ADC_V2_CON2_ACH_SEL(chan-address);
@@ -165,7 +168,7 @@ static irqreturn_t exynos_adc_isr(int irq, void *dev_id)
info-value = readl(ADC_V1_DATX(info-regs))
ADC_DATX_MASK;
/* clear irq */
- if (info-version == ADC_V2)
+ if (info-version ADC_V2)
writel(1, ADC_V2_INT_ST(info-regs));
else
writel(1, ADC_V1_INTCLR(info-regs));
@@ -226,11 +229,25 @@ static int exynos_adc_remove_devices(struct device
*dev, void *c)
return 0;
}
+static void exynos_adc_enable_clock(struct exynos_adc *info, bool enable)
+{
+ if (enable) {
+ clk_prepare_enable(info-clk);
This could fail. Is it OK without any checks?
+ if (info-version == ADC_V3)
+ clk_prepare_enable(info-sclk);
ditto.
+
+ } else {
+ if (info-version == ADC_V3)
+ clk_disable_unprepare(info-sclk);
+ clk_disable_unprepare(info-clk);
+ }
+}
+
static void exynos_adc_hw_init(struct exynos_adc *info)
{
u32 con1, con2;
- if (info-version == ADC_V2) {
+ if (info-version ADC_V2) {
con1 = ADC_V2_CON1_SOFT_RESET;
writel(con1, ADC_V2_CON1(info-regs));
@@ -300,6 +317,8 @@ static int exynos_adc_probe(struct platform_device *pdev)
writel(1, info-enable_reg);
+ info-version = exynos_adc_get_version(pdev);
+
info-clk = devm_clk_get(pdev-dev, adc);
if (IS_ERR(info-clk)) {
dev_err(pdev-dev, failed getting clock, err = %ld\n,
@@ -308,6 +327,17 @@ static int exynos_adc_probe(struct platform_device *pdev)
goto err_irq;
}
+ if (info-version == ADC_V3) {
+ info-sclk = devm_clk_get(pdev-dev, sclk_tsadc);
+ if (IS_ERR(info-sclk)) {
+ dev_warn(pdev-dev,
+ failed getting sclk clock, err = %ld\n,
+ PTR_ERR(info-sclk));
+ ret = PTR_ERR(info-sclk);
nit: you could move this line above dev_warn and use 'ret' in the print
statement.
--
With warm regards,
Sachin
--
To unsubscribe from this list: send the line
[PATCH v8 1/3] ARM: EXYNOS: initial board support for exynos5260 SoC
From: Pankaj Dubey pankaj.du...@samsung.com This patch add basic arch side support for exynos5260 SoC. Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com Signed-off-by: Rahul Sharma rahul.sha...@samsung.com Reviewed-by: Tomasz Figa t.f...@samsung.com --- arch/arm/mach-exynos/Kconfig |5 + 1 file changed, 5 insertions(+) diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig index fc8bf18..bf4ed87 100644 --- a/arch/arm/mach-exynos/Kconfig +++ b/arch/arm/mach-exynos/Kconfig @@ -84,6 +84,11 @@ config SOC_EXYNOS5250 help Enable EXYNOS5250 SoC support +config SOC_EXYNOS5260 + bool SAMSUNG EXYNOS5260 + default y + depends on ARCH_EXYNOS5 + config SOC_EXYNOS5420 bool SAMSUNG EXYNOS5420 default y -- 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 v8 3/3] ARM: dts: add dts files for xyref5260 board
The patch adds the dts files for xyref5260 board which
is based on Exynos5260 Evt0 sample.
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
---
arch/arm/boot/dts/Makefile |1 +
arch/arm/boot/dts/exynos5260-xyref5260.dts | 103
2 files changed, 104 insertions(+)
create mode 100644 arch/arm/boot/dts/exynos5260-xyref5260.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 35c146f..34ccea4 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -73,6 +73,7 @@ dtb-$(CONFIG_ARCH_EXYNOS) += exynos4210-origen.dtb \
exynos5250-arndale.dtb \
exynos5250-smdk5250.dtb \
exynos5250-snow.dtb \
+ exynos5260-xyref5260.dtb \
exynos5420-arndale-octa.dtb \
exynos5420-smdk5420.dtb \
exynos5440-sd5v1.dtb \
diff --git a/arch/arm/boot/dts/exynos5260-xyref5260.dts
b/arch/arm/boot/dts/exynos5260-xyref5260.dts
new file mode 100644
index 000..8c84ab2
--- /dev/null
+++ b/arch/arm/boot/dts/exynos5260-xyref5260.dts
@@ -0,0 +1,103 @@
+/*
+ * SAMSUNG XYREF5260 board device tree source
+ *
+ * Copyright (c) 2013 Samsung Electronics Co., Ltd.
+ * http://www.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.
+*/
+
+/dts-v1/;
+#include exynos5260.dtsi
+
+/ {
+ model = SAMSUNG XYREF5260 board based on EXYNOS5260;
+ compatible = samsung,xyref5260, samsung,exynos5260,
samsung,exynos5;
+
+ memory {
+ reg = 0x2000 0x8000;
+ };
+
+ chosen {
+ bootargs = console=ttySAC2,115200;
+ };
+
+ fin_pll: xxti {
+ compatible = fixed-clock;
+ clock-frequency = 2400;
+ clock-output-names = fin_pll;
+ #clock-cells = 0;
+ };
+
+ xrtcxti: xrtcxti {
+ compatible = fixed-clock;
+ clock-frequency = 32768;
+ clock-output-names = xrtcxti;
+ #clock-cells = 0;
+ };
+};
+
+pinctrl_0 {
+ hdmi_hpd_irq: hdmi-hpd-irq {
+ samsung,pins = gpx3-7;
+ samsung,pin-function = 0;
+ samsung,pin-pud = 1;
+ samsung,pin-drv = 0;
+ };
+};
+
+uart0 {
+ status = okay;
+};
+
+uart1 {
+ status = okay;
+};
+
+uart2 {
+ status = okay;
+};
+
+uart3 {
+ status = okay;
+};
+
+mmc_0 {
+ status = okay;
+ num-slots = 1;
+ broken-cd;
+ bypass-smu;
+ supports-highspeed;
+ supports-hs200-mode; /* 200 Mhz */
+ card-detect-delay = 200;
+ 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_rdqs sd0_clk sd0_cmd sd0_bus1 sd0_bus4 sd0_bus8;
+
+ slot@0 {
+ reg = 0;
+ bus-width = 8;
+ };
+};
+
+mmc_2 {
+ status = okay;
+ num-slots = 1;
+ supports-highspeed;
+ card-detect-delay = 200;
+ 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_bus1 sd2_bus4;
+
+ slot@0 {
+ reg = 0;
+ bus-width = 4;
+ disable-wp;
+ };
+};
--
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 v8 2/3] ARM: dts: add dts files for exynos5260 SoC
The patch adds the dts files for exynos5260.
Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
Signed-off-by: Arun Kumar K arun...@samsung.com
Reviewed-by: Tomasz Figa t.f...@samsung.com
---
arch/arm/boot/dts/exynos5260-pinctrl.dtsi | 574 +
arch/arm/boot/dts/exynos5260.dtsi | 304 +++
2 files changed, 878 insertions(+)
create mode 100644 arch/arm/boot/dts/exynos5260-pinctrl.dtsi
create mode 100644 arch/arm/boot/dts/exynos5260.dtsi
diff --git a/arch/arm/boot/dts/exynos5260-pinctrl.dtsi
b/arch/arm/boot/dts/exynos5260-pinctrl.dtsi
new file mode 100644
index 000..f6ee55e
--- /dev/null
+++ b/arch/arm/boot/dts/exynos5260-pinctrl.dtsi
@@ -0,0 +1,574 @@
+/*
+ * Samsung's Exynos5260 SoC pin-mux and pin-config device tree source
+ *
+ * Copyright (c) 2013 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * Samsung's Exynos5260 SoC pin-mux and pin-config options are listed as device
+ * tree nodes are listed in this file.
+ *
+ * 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.
+*/
+
+#define PIN_PULL_NONE 0
+#define PIN_PULL_DOWN 1
+#define PIN_PULL_UP3
+
+pinctrl_0 {
+ gpa0: gpa0 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+
+ gpa1: gpa1 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+
+ gpa2: gpa2 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+
+ gpb0: gpb0 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+
+ gpb1: gpb1 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+
+ gpb2: gpb2 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+
+ gpb3: gpb3 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+
+ gpb4: gpb4 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+
+ gpb5: gpb5 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+
+ gpd0: gpd0 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+
+ gpd1: gpd1 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+
+ gpd2: gpd2 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+
+ gpe0: gpe0 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+
+ gpe1: gpe1 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+
+ gpf0: gpf0 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+
+ gpf1: gpf1 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+
+ gpk0: gpk0 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+
+ gpx0: gpx0 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+
+ gpx1: gpx1 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+
+ gpx2: gpx2 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+
+ gpx3: gpx3 {
+ gpio-controller;
+
[PATCH v8 0/3] exynos: arch: add support for exynos5260 SoC
From: Rahul Sharma rahul.sha...@samsung.com v8: 1) Removed exynos5260 compatible from mach/exynos5.c 2) Added generic exynos5 compatible in board and soc dts file. v7: 1) Renamed board file V6: 1) Renamed mmc nodes. 2) Removed PHY clocks from DT and put them inside clock driver. 3) Added clock-cells property for all fixed clocks. 4) Removed spdif_ext_clk fixed rate clock. V5: 1) Removed SYSRAM related code. 2) Fixed mct clocks. 3) Add SoC and Board specifc fixed-rate clocks in respective files. V4: 1) Removed duplicate MMC Soc property from Board file. V3: 1) Addressed review comments from Tomasz figa. V2: 1) Split up DT patch into SoC and Board patch. This series is based on Kukjin's for-next branch at http://git.kernel.org/?p=linux/kernel/git/kgene/linux-samsung.git Pankaj Dubey (1): ARM: EXYNOS: initial board support for exynos5260 SoC Rahul Sharma (2): ARM: dts: add dts files for exynos5260 SoC ARM: dts: add dts files for xyref5260 board arch/arm/boot/dts/Makefile |1 + arch/arm/boot/dts/exynos5260-pinctrl.dtsi | 574 arch/arm/boot/dts/exynos5260-xyref5260.dts | 103 + arch/arm/boot/dts/exynos5260.dtsi | 304 +++ arch/arm/mach-exynos/Kconfig |5 + 5 files changed, 987 insertions(+) create mode 100644 arch/arm/boot/dts/exynos5260-pinctrl.dtsi create mode 100644 arch/arm/boot/dts/exynos5260-xyref5260.dts create mode 100644 arch/arm/boot/dts/exynos5260.dtsi -- 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 v8 0/3] exynos: arch: add support for exynos5260 SoC
Hi Rahul, On 16 April 2014 09:28, Rahul Sharma rahul.sha...@samsung.com wrote: From: Rahul Sharma rahul.sha...@samsung.com v8: 1) Removed exynos5260 compatible from mach/exynos5.c 2) Added generic exynos5 compatible in board and soc dts file. v7: 1) Renamed board file V6: 1) Renamed mmc nodes. 2) Removed PHY clocks from DT and put them inside clock driver. 3) Added clock-cells property for all fixed clocks. 4) Removed spdif_ext_clk fixed rate clock. V5: 1) Removed SYSRAM related code. 2) Fixed mct clocks. 3) Add SoC and Board specifc fixed-rate clocks in respective files. V4: 1) Removed duplicate MMC Soc property from Board file. V3: 1) Addressed review comments from Tomasz figa. V2: 1) Split up DT patch into SoC and Board patch. This series is based on Kukjin's for-next branch at http://git.kernel.org/?p=linux/kernel/git/kgene/linux-samsung.git Pankaj Dubey (1): ARM: EXYNOS: initial board support for exynos5260 SoC Rahul Sharma (2): ARM: dts: add dts files for exynos5260 SoC ARM: dts: add dts files for xyref5260 board arch/arm/boot/dts/Makefile |1 + arch/arm/boot/dts/exynos5260-pinctrl.dtsi | 574 arch/arm/boot/dts/exynos5260-xyref5260.dts | 103 + arch/arm/boot/dts/exynos5260.dtsi | 304 +++ arch/arm/mach-exynos/Kconfig |5 + 5 files changed, 987 insertions(+) create mode 100644 arch/arm/boot/dts/exynos5260-pinctrl.dtsi create mode 100644 arch/arm/boot/dts/exynos5260-xyref5260.dts create mode 100644 arch/arm/boot/dts/exynos5260.dtsi Series looks good. 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
[PATCH v2 0/7] Support 4 levels of translation tables for ARM64
Hi All, This the 2nd patchset supports 4 levels of tranlsation tables for ARM64. Firstly, The patchset decouples page size from level of translation tables as taking account into the comment from Catalin Marinas: http://www.spinics.net/linux/lists/arm-kernel/msg319552.html Then, it implements 4 levels of translation tables for native, HYP and stage2 sides. All ARMv8 and ARMv7 related changes are validated with FastModels+kvmtool and A15+QEMU, respectively. Changes since v1: - fixed unmatched data types as per Steve's comment - removed unnecessary #ifdef in arch/arm64/mm/* as per Steve's comment - revised create_pgd_entry to deal with PUD entry as per Steve's comment - introduced a macro for initial memblock limit as per Steve's comment - dropped Fix line length exceeding 80 characters patch as per Marc's comment - removed unnecessary #ifdef in arch/arm/kvm/mmu.c as per Marc's comment - added a macro for a number of objects of as per Marc's comment Jungseok Lee (7): arm64: Use pr_* instead of printk arm64: Decouple page size from level of translation tables arm64: Introduce a kernel configuration option for VA_BITS arm64: Add a description on 48-bit address space with 4KB pages arm64: Add 4 levels of page tables definition with 4KB pages arm64: mm: Implement 4 levels of translation tables arm64: KVM: Implement 4 levels of translation tables for HYP and stage2 Documentation/arm64/memory.txt| 59 +-- arch/arm/include/asm/kvm_mmu.h| 10 ++ arch/arm/kvm/mmu.c| 88 ++--- arch/arm64/Kconfig| 51 +- arch/arm64/include/asm/kvm_arm.h | 20 arch/arm64/include/asm/kvm_mmu.h | 10 ++ arch/arm64/include/asm/memblock.h |6 ++ arch/arm64/include/asm/memory.h |6 +- arch/arm64/include/asm/page.h |6 +- arch/arm64/include/asm/pgalloc.h | 24 - arch/arm64/include/asm/pgtable-4level-hwdef.h | 50 ++ arch/arm64/include/asm/pgtable-4level-types.h | 71 + arch/arm64/include/asm/pgtable-hwdef.h|8 +- arch/arm64/include/asm/pgtable.h | 52 -- arch/arm64/include/asm/tlb.h | 10 +- arch/arm64/kernel/head.S | 40 +--- arch/arm64/kernel/traps.c | 19 ++-- arch/arm64/mm/fault.c |1 + arch/arm64/mm/mmu.c | 16 ++- 19 files changed, 485 insertions(+), 62 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/7] 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
Signed-off-by: Jungseok Lee jays@samsung.com
Reviewed-by: Sungjinn Chung sungjinn.ch...@samsung.com
---
arch/arm64/kernel/traps.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
index 7ffaddd..0484e81 100644
--- a/arch/arm64/kernel/traps.c
+++ b/arch/arm64/kernel/traps.c
@@ -65,7 +65,7 @@ static void dump_mem(const char *lvl, const char *str,
unsigned long bottom,
fs = get_fs();
set_fs(KERNEL_DS);
- printk(%s%s(0x%016lx to 0x%016lx)\n, lvl, str, bottom, top);
+ pr_emerg(%s%s(0x%016lx to 0x%016lx)\n, lvl, str, bottom, top);
for (first = bottom ~31; first top; first += 32) {
unsigned long p;
@@ -83,7 +83,7 @@ static void dump_mem(const char *lvl, const char *str,
unsigned long bottom,
sprintf(str + i * 9, );
}
}
- printk(%s%04lx:%s\n, lvl, first 0x, str);
+ pr_emerg(%s%04lx:%s\n, lvl, first 0x, str);
}
set_fs(fs);
@@ -124,7 +124,7 @@ static void dump_instr(const char *lvl, struct pt_regs
*regs)
break;
}
}
- printk(%sCode: %s\n, lvl, str);
+ pr_emerg(%sCode: %s\n, lvl, str);
set_fs(fs);
}
@@ -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 v2 7/7] arm64: KVM: Implement 4 levels of translation tables for HYP and stage2
This patch adds 4 levels of translation tables implementation for both
HYP and stage2. A combination of 4KB + 4 levels host and 4KB + 4 levels
guest can run on ARMv8 architecture as introducing this feature.
Signed-off-by: Jungseok Lee jays@samsung.com
Reviewed-by: Sungjinn Chung sungjinn.ch...@samsung.com
---
arch/arm/include/asm/kvm_mmu.h | 10 +
arch/arm/kvm/mmu.c | 88 +-
arch/arm64/include/asm/kvm_arm.h | 20 +
arch/arm64/include/asm/kvm_mmu.h | 10 +
4 files changed, 117 insertions(+), 11 deletions(-)
diff --git a/arch/arm/include/asm/kvm_mmu.h b/arch/arm/include/asm/kvm_mmu.h
index 5c7aa3c..6f7906e 100644
--- a/arch/arm/include/asm/kvm_mmu.h
+++ b/arch/arm/include/asm/kvm_mmu.h
@@ -37,6 +37,11 @@
*/
#define TRAMPOLINE_VA UL(CONFIG_VECTORS_BASE)
+/*
+ * NUM_OBJS depends on the number of page table translation levels
+ */
+#define NUM_OBJS 2
+
#ifndef __ASSEMBLY__
#include asm/cacheflush.h
@@ -94,6 +99,11 @@ static inline void kvm_clean_pgd(pgd_t *pgd)
clean_dcache_area(pgd, PTRS_PER_S2_PGD * sizeof(pgd_t));
}
+static inline void kvm_clean_pmd(pmd_t *pmd)
+{
+ clean_dcache_area(pmd, PTRS_PER_PMD * sizeof(pmd_t));
+}
+
static inline void kvm_clean_pmd_entry(pmd_t *pmd)
{
clean_pmd_entry(pmd);
diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
index 80bb1e6..7fc9e55 100644
--- a/arch/arm/kvm/mmu.c
+++ b/arch/arm/kvm/mmu.c
@@ -388,13 +388,44 @@ static int create_hyp_pmd_mappings(pud_t *pud, unsigned
long start,
return 0;
}
+static int create_hyp_pud_mappings(pgd_t *pgd, unsigned long start,
+ unsigned long end, unsigned long pfn,
+ pgprot_t prot)
+{
+ pud_t *pud;
+ pmd_t *pmd;
+ unsigned long addr, next;
+
+ addr = start;
+ do {
+ pud = pud_offset(pgd, addr);
+
+ if (pud_none_or_clear_bad(pud)) {
+ pmd = pmd_alloc_one(NULL, addr);
+ if (!pmd) {
+ kvm_err(Cannot allocate Hyp pmd\n);
+ return -ENOMEM;
+ }
+ pud_populate(NULL, pud, pmd);
+ get_page(virt_to_page(pud));
+ kvm_flush_dcache_to_poc(pud, sizeof(*pud));
+ }
+
+ next = pud_addr_end(addr, end);
+
+ create_hyp_pmd_mappings(pud, addr, next, pfn, prot);
+ pfn += (next - addr) PAGE_SHIFT;
+ } while (addr = next, addr != end);
+
+ return 0;
+}
+
static int __create_hyp_mappings(pgd_t *pgdp,
unsigned long start, unsigned long end,
unsigned long pfn, pgprot_t prot)
{
pgd_t *pgd;
pud_t *pud;
- pmd_t *pmd;
unsigned long addr, next;
int err = 0;
@@ -403,22 +434,23 @@ static int __create_hyp_mappings(pgd_t *pgdp,
end = PAGE_ALIGN(end);
do {
pgd = pgdp + pgd_index(addr);
- pud = pud_offset(pgd, addr);
- if (pud_none_or_clear_bad(pud)) {
- pmd = pmd_alloc_one(NULL, addr);
- if (!pmd) {
- kvm_err(Cannot allocate Hyp pmd\n);
+ if (pgd_none(*pgd)) {
+ pud = pud_alloc_one(NULL, addr);
+ if (!pud) {
+ kvm_err(Cannot allocate Hyp pud\n);
err = -ENOMEM;
goto out;
}
- pud_populate(NULL, pud, pmd);
- get_page(virt_to_page(pud));
- kvm_flush_dcache_to_poc(pud, sizeof(*pud));
+ pgd_populate(NULL, pgd, pud);
+ get_page(virt_to_page(pgd));
+ kvm_flush_dcache_to_poc(pgd, sizeof(*pgd));
}
next = pgd_addr_end(addr, end);
- err = create_hyp_pmd_mappings(pud, addr, next, pfn, prot);
+
+ err = create_hyp_pud_mappings(pgd, addr, next, pfn, prot);
+
if (err)
goto out;
pfn += (next - addr) PAGE_SHIFT;
@@ -563,6 +595,24 @@ void kvm_free_stage2_pgd(struct kvm *kvm)
kvm-arch.pgd = NULL;
}
+static pud_t *stage2_get_pud(struct kvm *kvm, struct kvm_mmu_memory_cache
*cache,
+phys_addr_t addr)
+{
+ pgd_t *pgd;
+ pud_t *pud;
+
+ pgd = kvm-arch.pgd + pgd_index(addr);
+ if (pgd_none(*pgd)) {
+ if (!cache)
+ return NULL;
+ pud = mmu_memory_cache_alloc(cache);
+ pgd_populate(NULL, pgd, pud);
+ get_page(virt_to_page(pgd));
+ }
+
+ return pud_offset(pgd,
[PATCH v2 6/7] 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
Signed-off-by: Jungseok Lee jays@samsung.com
Reviewed-by: Sungjinn Chung sungjinn.ch...@samsung.com
---
arch/arm64/Kconfig |7 +
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 | 44 ++--
arch/arm64/include/asm/tlb.h |8 ++
arch/arm64/kernel/head.S | 40 -
arch/arm64/kernel/traps.c |5
arch/arm64/mm/fault.c |1 +
arch/arm64/mm/mmu.c| 16 +---
11 files changed, 136 insertions(+), 21 deletions(-)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 431acbc..7f5270b 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -184,12 +184,19 @@ config ARM64_3_LEVELS
help
This feature enables 3 levels of translation tables.
+config ARM64_4_LEVELS
+ bool 4 level
+ depends on ARM64_4K_PAGES
+ help
+ This feature enables 4 levels of translation tables.
+
endchoice
config ARM64_VA_BITS
int Virtual address space size
range 39 39 if ARM64_4K_PAGES ARM64_3_LEVELS
range 42 42 if ARM64_64K_PAGES ARM64_2_LEVELS
+ range 48 48 if ARM64_4K_PAGES ARM64_4_LEVELS
help
This feature is determined by a combination of page size and
level of translation tables.
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
/*
@@ -27,7 +29,7 @@
*
* Level 1 descriptor (PUD).
*/
-
+#define PUD_TYPE_TABLE (_AT(pudval_t, 3) 0)
#define PUD_TABLE_BIT
[PATCH v2 3/7] arm64: Introduce a kernel configuration option for VA_BITS
This patch adds a kernel configuration for VA_BITS. It helps to prevent unnecessary #ifdef statements insertions for VA_BITS when implementing different page sizes and level of translation tables. Signed-off-by: Jungseok Lee jays@samsung.com Reviewed-by: Sungjinn Chung sungjinn.ch...@samsung.com --- arch/arm64/Kconfig |8 arch/arm64/include/asm/memory.h |6 +- 2 files changed, 9 insertions(+), 5 deletions(-) diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index 1a2faf9..431acbc 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -186,6 +186,14 @@ config ARM64_3_LEVELS endchoice +config ARM64_VA_BITS + int Virtual address space size + range 39 39 if ARM64_4K_PAGES ARM64_3_LEVELS + range 42 42 if ARM64_64K_PAGES ARM64_2_LEVELS + help + This feature is determined by a combination of page size and + level of translation tables. + 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) -- 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
