Re: [PATCH v5 05/14] drm/exynos: dsi: add pass TE host ops to support LCD I80 interface
On Wed, Jul 16, 2014 at 11:23:09AM +0900, YoungJun Cho wrote: Hi Inki, On 07/15/2014 11:34 AM, Inki Dae wrote: On 2014년 07월 14일 20:03, Thierry Reding wrote: On Mon, Jul 14, 2014 at 07:45:28PM +0900, YoungJun Cho wrote: On 07/14/2014 06:41 PM, Thierry Reding wrote: [...] That said, I've been doing some research and it seems like we have a somewhat similar feature on Tegra. What happens there is that there are three GPIO pins that can be repurposed for TE signalling. But as opposed to using them as interrupts the display controller can be configured to use them, upon which it will automatically handle the TE signal by sending the next frame. Could you explain more detail how the Tegra display controller could be configured with this GPIO pins? I have no idea except that the display controller registers this GPIO as an IRQ. On Tegra the display controller has a special register that can be programmed to use one of the three GPIOs as TE signal. Then the display controller can be configured in one-shot (non-continuous) mode, which means that software needs to explicitly set a trigger bit to tell the display controller to send a new frame. If TE signalling is enabled, then the display controller will not immediately send a new frame when triggered but wait for signalling of this GPIO. So we have at least two very different implementations of this on two different SoCs. Further the specification explicitly recommends using the BTA sequence and DSI protocol to wait for TE. So I still think that controllers that provide an additional, non-spec compliant method to signal TE should handle it separately rather than within DSI. Otherwise we essentially need to make the DSI core aware of all these quirks, and I'd rather avoid that. You mean, the DSI specification guides to use BTA, so it's better to use display controller rather than DSIM, right? What I'm saying is that there's nothing about a side-band TE wire in the DSI spec. In fact the spec explicitly says that this mechanism of an external TE wire from older protocols (DBI) was replaced by the BTA sequence over the protocol. Now, my understanding is that using the BTA sequence over the DSI protocol would introduce some latency and that forces some panel vendors to still provide a side-band TE wire even in DSI compliant panels. But since this is not part of the specification there is no standard way to do this (as evidenced by Tegra and Exynos). Therefore putting such functionality into the core DSI code is bad. But that doesn't mean that you have to put this functionality into the display controller driver on Exynos. What I'm saying is that it should be handled by the SoC driver rather than the core. Where exactly probably depends on the particular case. As Inki commented before, I'll try to use remote-endpoint property of DSI device node in exynos DSIM driver and call FIMD notifier. Sounds like it matches what I said above. I'm not a huge fan of notifiers, but if it works for you I suppose that's fine. The alternative would be to directly call a FIMD function, which is somewhat more explicit than a notifier. Yes, I also like explicit call, so I want to use dsi_host_ops and calls it in panel. But there is an objection to use dis_host_ops, we think notifier in exynos dsim for fimd(display controller). There are other ways to explicitly call into the display controller. You could for example get access to the CRTC that DSIM is currently connected to (via exynos_dsi.encoder-crtc) and then cast that to a struct exynos_drm_crtc and call a function to trigger a new frame to be sent (for example exynos_drm_crtc_send_frame()). This assumes that you can safely cast struct drm_crtc * to struct exynos_drm_crtc *, but that shouldn't be a problem. With the above, you could make the DSIM handle the TE signal interrupts and trigger the DC using the new exynos_drm_crtc_send_frame() function. It seems better than the use of notifier. Actually, original patch used this way except TE event. Mr. Cho, let's use remote-endpoint property and this way instead of notifier. The struct exynos_dsi has panel_node, which is valid by exynos_dsi_host_attach() is called from panel, we could use it instead of getting new remote-endpoint node. So after called exynos_dsi_host_attach(), the dsi driver could know that the panel supports mipi command mode or video mode, and if the panel is for mipi command mode one, dsi driver gets panel te gpio and registers its irq. Why does the TE GPIO even need to be in the panel's device tree node? Wouldn't it make more sense for it to be in the DSIM node? After all that's what the GPIO is connected to, right? Well, at least logically if not physically. Thierry pgpjDEWotwi21.pgp Description: PGP signature
[PATCH v4 2/4] usb: host: xhci-plat: Get PHYs for xhci's hcds
The host controller by itself may sometimes need to handle PHY
and/or calibrate some of the PHY settings to get full support out
of the PHY controller. The PHY core provides a calibration
funtionality now to do so.
Therefore, facilitate getting the two possible PHYs, viz.
USB 2.0 type (UTMI+) and USB 3.0 type (PIPE3).
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
Changes from v3:
- Modified error message as per review comments from Julius.
drivers/usb/host/xhci-plat.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index 1a0cf9f..b1c0364 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -16,6 +16,7 @@
#include linux/module.h
#include linux/of.h
#include linux/platform_device.h
+#include linux/phy/phy.h
#include linux/slab.h
#include linux/usb/xhci_pdriver.h
@@ -180,6 +181,15 @@ static int xhci_plat_probe(struct platform_device *pdev)
goto put_hcd;
}
+ /* Get possile USB 2.0 type PHY (UTMI+) available with xhci */
+ hcd-gen_phy = devm_phy_get(pdev-dev, usb2-phy);
+ if (IS_ERR(hcd-gen_phy)) {
+ ret = PTR_ERR(hcd-gen_phy);
+ if (ret != -ENOSYS ret != -ENODEV)
+ dev_warn(pdev-dev,
+Error retrieving usb2 phy: %d\n, ret);
+ }
+
ret = usb_add_hcd(hcd, irq, IRQF_SHARED);
if (ret)
goto disable_clk;
@@ -209,6 +219,15 @@ static int xhci_plat_probe(struct platform_device *pdev)
if (HCC_MAX_PSA(xhci-hcc_params) = 4)
xhci-shared_hcd-can_do_streams = 1;
+ /* Get possile USB 3.0 type PHY (PIPE3) available with xhci */
+ xhci-shared_hcd-gen_phy = devm_phy_get(pdev-dev, usb3-phy);
+ if (IS_ERR(xhci-shared_hcd-gen_phy)) {
+ ret = PTR_ERR(xhci-shared_hcd-gen_phy);
+ if (ret != -ENOSYS ret != -ENODEV)
+ dev_warn(pdev-dev,
+Error retrieving usb3 phy: %d\n, ret);
+ }
+
ret = usb_add_hcd(xhci-shared_hcd, irq, IRQF_SHARED);
if (ret)
goto put_usb3_hcd;
--
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
[RESEND PATCH v2] ARM: exynos4: hotplug: Fix CPU idle clock down after CPU off
On Exynos4 USE_DELAYED_RESET_ASSERTION must be set in
ARM_COREx_OPTION register during CPU power down. This is the proper way
of powering down CPU on Exynos4.
Additionally on Exynos4212 without this the CPU clock down feature won't
work after powering down some CPU and the online CPUs will work at full
frequency chosen by CPUfreq governor.
Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
---
Changes since v1:
1. Use delayed reset assertion on all Exynos4 family and all cores, not
only on core 1 of Exynos4212.
2. Rebase on Tomasz Figa's patch:
ARM: EXYNOS: Fix core ID used by platsmp and hotplug code
http://www.spinics.net/lists/linux-samsung-soc/msg31604.html
Tomasz's patch is currently applied to Kukjin's v3.16-samsung-fixes-4
---
arch/arm/mach-exynos/hotplug.c | 27 +--
arch/arm/mach-exynos/regs-pmu.h | 3 +++
2 files changed, 28 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-exynos/hotplug.c b/arch/arm/mach-exynos/hotplug.c
index 920a4baa53cd..e6340b645f9d 100644
--- a/arch/arm/mach-exynos/hotplug.c
+++ b/arch/arm/mach-exynos/hotplug.c
@@ -22,7 +22,7 @@
#include common.h
#include regs-pmu.h
-static inline void cpu_leave_lowpower(void)
+static inline void cpu_leave_lowpower(u32 core_id)
{
unsigned int v;
@@ -36,6 +36,14 @@ static inline void cpu_leave_lowpower(void)
: =r (v)
: Ir (CR_C), Ir (0x40)
: cc);
+
+ if (soc_is_exynos4()) {
+ unsigned int tmp;
+
+ tmp = __raw_readl(EXYNOS_ARM_CORE_OPTION(core_id));
+ tmp = ~(S5P_USE_DELAYED_RESET_ASSERTION);
+ __raw_writel(tmp, EXYNOS_ARM_CORE_OPTION(core_id));
+ }
}
static inline void platform_do_lowpower(unsigned int cpu, int *spurious)
@@ -47,6 +55,19 @@ static inline void platform_do_lowpower(unsigned int cpu,
int *spurious)
/* Turn the CPU off on next WFI instruction. */
exynos_cpu_power_down(core_id);
+ if (soc_is_exynos4()) {
+ unsigned int tmp;
+
+ /*
+* Exynos 4 SoCs require setting
+* USE_DELAYED_RESET_ASSERTION so the CPU idle
+* clock down feature could properly detect
+* global idle state when CPUx is off.
+*/
+ tmp = __raw_readl(EXYNOS_ARM_CORE_OPTION(core_id));
+ tmp |= S5P_USE_DELAYED_RESET_ASSERTION;
+ __raw_writel(tmp, EXYNOS_ARM_CORE_OPTION(core_id));
+ }
wfi();
@@ -76,6 +97,8 @@ static inline void platform_do_lowpower(unsigned int cpu, int
*spurious)
void __ref exynos_cpu_die(unsigned int cpu)
{
int spurious = 0;
+ u32 mpidr = cpu_logical_map(cpu);
+ u32 core_id = MPIDR_AFFINITY_LEVEL(mpidr, 0);
v7_exit_coherency_flush(louis);
@@ -85,7 +108,7 @@ void __ref exynos_cpu_die(unsigned int cpu)
* bring this CPU back into the world of cache
* coherency, and then restore interrupts
*/
- cpu_leave_lowpower();
+ cpu_leave_lowpower(core_id);
if (spurious)
pr_warn(CPU%u: %u spurious wakeup calls\n, cpu, spurious);
diff --git a/arch/arm/mach-exynos/regs-pmu.h b/arch/arm/mach-exynos/regs-pmu.h
index 1d13b08708f0..59bd92112842 100644
--- a/arch/arm/mach-exynos/regs-pmu.h
+++ b/arch/arm/mach-exynos/regs-pmu.h
@@ -25,6 +25,7 @@
#define S5P_USE_STANDBY_WFI0 (1 16)
#define S5P_USE_STANDBY_WFE0 (1 24)
+#define S5P_USE_DELAYED_RESET_ASSERTIONBIT(12)
#define EXYNOS_SWRESET S5P_PMUREG(0x0400)
#define EXYNOS5440_SWRESET S5P_PMUREG(0x00C4)
@@ -111,6 +112,8 @@
(EXYNOS_ARM_CORE0_CONFIGURATION + (0x80 * (_nr)))
#define EXYNOS_ARM_CORE_STATUS(_nr)\
(EXYNOS_ARM_CORE_CONFIGURATION(_nr) + 0x4)
+#define EXYNOS_ARM_CORE_OPTION(_nr)\
+ (EXYNOS_ARM_CORE_CONFIGURATION(_nr) + 0x8)
#define EXYNOS_ARM_COMMON_CONFIGURATIONS5P_PMUREG(0x2500)
#define EXYNOS_COMMON_CONFIGURATION(_nr) \
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] ARM: dts: ODROID i2c improvements
Increase max i2c bus frequency beyond the default for faster
data transfers. According to the manual, these faster speeds are
only available when the board is wired up the right way. In this case,
the vendor kernel has run at this speed for a long time.
sda-delay is needed for talking to RTC on PMIC, otherwise the i2c
controller never sees an ACK. Strangely the other PMIC i2c slave (the
main one) works fine even without this delay. I Chose value 100 to
match the vendor kernel.
Signed-off-by: Daniel Drake dr...@endlessm.com
---
arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
index cb6f55f..adadaf9 100644
--- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
+++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
@@ -134,6 +134,8 @@
i2c@1386 {
pinctrl-0 = i2c0_bus;
pinctrl-names = default;
+ samsung,i2c-sda-delay = 100;
+ samsung,i2c-max-bus-freq = 40;
status = okay;
usb3503: usb3503@08 {
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] ARM: dts: Enable PMIC interrupts on ODROID
The ODROID kernel shows that the PMIC interrupt line is hooked up
to pin GPX3-2.
This is needed for the max77686-irq driver to create the PMIC IRQ
domain, which is needed by max77686-rtc.
Signed-off-by: Daniel Drake dr...@endlessm.com
---
arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
index 6d6d23c..cb6f55f 100644
--- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
+++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
@@ -148,6 +148,10 @@
max77686: pmic@09 {
compatible = maxim,max77686;
+ interrupt-parent = gpx3;
+ interrupts = 2 0;
+ pinctrl-names = default;
+ pinctrl-0 = max77686_irq;
reg = 0x09;
#clock-cells = 1;
@@ -368,4 +372,11 @@
samsung,pins = gpx1-3;
samsung,pin-pud = 0;
};
+
+ max77686_irq: max77686-irq {
+ samsung,pins = gpx3-2;
+ samsung,pin-function = 0;
+ samsung,pin-pud = 0;
+ samsung,pin-drv = 0;
+ };
};
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 04/19] serial: samsung: Remove support for legacy clock code
On Fri, 2014-07-04 at 19:48 +0200, Tomasz Figa wrote: All Samsung platforms are now using the Common Clock Framework and the legacy clock code is being removed, so remove related dead code from samsung-serial driver as well. Reported-by: Arnd Bergmann a...@arndb.de Signed-off-by: Tomasz Figa t.f...@samsung.com Cc: Greg Kroah-Hartman gre...@linuxfoundation.org (maintainer:SERIAL DRIVERS) Cc: Jiri Slaby jsl...@suse.cz (supporter:TTY LAYER) Cc: linux-ser...@vger.kernel.org (open list:SERIAL DRIVERS) --- drivers/tty/serial/samsung.c | 4 1 file changed, 4 deletions(-) This just entered linux-next (see next-20140716). diff --git a/drivers/tty/serial/samsung.c b/drivers/tty/serial/samsung.c index 36c7747..cae8ebd 100644 --- a/drivers/tty/serial/samsung.c +++ b/drivers/tty/serial/samsung.c @@ -47,10 +47,6 @@ #include asm/irq.h -#ifdef CONFIG_SAMSUNG_CLOCK -#include plat/clock.h -#endif - #include samsung.h #if defined(CONFIG_SERIAL_SAMSUNG_DEBUG) \ There are three further references to CONFIG_SAMSUNG_CLOCK in this file. Those should be removed too, shouldn't they? 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 18/19] ARM: SAMSUNG: Remove remaining legacy code
On Fri, 2014-07-04 at 19:48 +0200, Tomasz Figa wrote: After refactoring suspend/resume, which was last part with dependencies on legacy code, all Kconfig symbols related to Samsung ATAGS support can be deselected and more unused code removed. This includes most of s5p-* code as well, as s5pv210 was their last user. Signed-off-by: Tomasz Figa t.f...@samsung.com --- This one also landed in today's linux-next (ie, next-20140716). [...] diff --git a/arch/arm/mach-s5pv210/include/mach/gpio.h b/arch/arm/mach-s5pv210/include/mach/gpio.h deleted file mode 100644 index 6c8b903..000 This removed the single case were CONFIG_SAMSUNG_GPIO_EXTRA was used. [...] diff --git a/arch/arm/plat-samsung/Kconfig b/arch/arm/plat-samsung/Kconfig [...] @@ -64,31 +51,6 @@ config SAMSUNG_ATAGS if SAMSUNG_ATAGS -# options for IRQ support - -config S5P_IRQ - def_bool ARCH_S5PV210 - help - Support common interrupt part for ARCH_S5P SoCs - -config S5P_EXT_INT - bool - help - Use the external interrupts (other than GPIO interrupts.) - -config S5P_GPIO_INT - bool - help - Common code for the GPIO interrupts (other than external interrupts.) - -# options for gpio configuration support - -config S5P_GPIO_DRVSTR - bool - help - Internal configuration to get and set correct GPIO driver strength - helper - config SAMSUNG_GPIO_EXTRA int Number of additional GPIO pins default 128 if SAMSUNG_GPIO_EXTRA128 So a second order effect is that SAMSUNG_GPIO_EXTRA can now be removed. Which implies that SAMSUNG_GPIO_EXTRA64 and SAMSUNG_GPIO_EXTRA128 can also be removed. Should I submit the trivial patch to do that or is a patch already queued somewhere? 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 11/19] ARM: S5PV210: Remove support for board files
On Fri, 2014-07-04 at 19:48 +0200, Tomasz Figa wrote: Since all in-tree boards have been moved to device tree, we can now drop legacy code and make mach-s5pv210 DT-only. This patch does it. Signed-off-by: Tomasz Figa t.f...@samsung.com --- This patch showed up in next-20140716 too. [...] diff --git a/arch/arm/mach-s5pv210/Kconfig b/arch/arm/mach-s5pv210/Kconfig index ed492cf..d6d0f92 100644 --- a/arch/arm/mach-s5pv210/Kconfig +++ b/arch/arm/mach-s5pv210/Kconfig @@ -19,181 +19,8 @@ config CPU_S5PV210 help Enable S5PV210 CPU support -config S5PV210_SETUP_I2C1 - bool - help - Common setup code for i2c bus 1. - -config S5PV210_SETUP_I2C2 - bool - help - Common setup code for i2c bus 2. - -config S5PV210_SETUP_IDE - bool - help - Common setup code for S5PV210 IDE GPIO configurations - -config S5PV210_SETUP_FB_24BPP - bool - help - Common setup code for S5PV210 with an 24bpp RGB display helper. - -config S5PV210_SETUP_KEYPAD - bool - help - Common setup code for keypad. - -config S5PV210_SETUP_SDHCI -bool -select S5PV210_SETUP_SDHCI_GPIO -help - Internal helper functions for S5PV210 based SDHCI systems - -config S5PV210_SETUP_SDHCI_GPIO - bool - help - Common setup code for SDHCI gpio. - -config S5PV210_SETUP_FIMC - bool - help - Common setup code for the camera interfaces. - -config S5PV210_SETUP_SPI - bool - help - Common setup code for SPI GPIO configurations. - -config S5PV210_SETUP_USB_PHY - bool - help - Common setup code for USB PHY controller - -menu S5PC110 Machines - -config MACH_AQUILA - bool Aquila - select CPU_S5PV210 - select S3C_DEV_FB - select S3C_DEV_HSMMC - select S3C_DEV_HSMMC1 - select S3C_DEV_HSMMC2 - select S5PV210_SETUP_FB_24BPP - select S5PV210_SETUP_SDHCI - select S5PV210_SETUP_USB_PHY - select S5P_DEV_FIMC0 - select S5P_DEV_FIMC1 - select S5P_DEV_FIMC2 - select S5P_DEV_ONENAND - help - Machine support for the Samsung Aquila target based on S5PC110 SoC - This symbol is still referenced in sound/soc/samsung/Kconfig. -config MACH_GONI - bool GONI - select CPU_S5PV210 - select S3C_DEV_FB - select S3C_DEV_HSMMC - select S3C_DEV_HSMMC1 - select S3C_DEV_HSMMC2 - select S3C_DEV_I2C1 - select S3C_DEV_I2C2 - select S3C_DEV_USB_HSOTG - select S5PV210_SETUP_FB_24BPP - select S5PV210_SETUP_FIMC - select S5PV210_SETUP_I2C1 - select S5PV210_SETUP_I2C2 - select S5PV210_SETUP_KEYPAD - select S5PV210_SETUP_SDHCI - select S5PV210_SETUP_USB_PHY - select S5P_DEV_FIMC0 - select S5P_DEV_FIMC1 - select S5P_DEV_FIMC2 - select S5P_DEV_MFC - select S5P_DEV_ONENAND - select S5P_DEV_TV - select S5P_GPIO_INT - select SAMSUNG_DEV_KEYPAD - help - Machine support for Samsung GONI board - S5PC110(MCP) is one of package option of S5PV210 Ditto. -config MACH_SMDKC110 - bool SMDKC110 - select CPU_S5PV210 - select S3C_DEV_I2C1 - select S3C_DEV_I2C2 - select S3C_DEV_RTC - select S3C_DEV_WDT - select S5PV210_SETUP_I2C1 - select S5PV210_SETUP_I2C2 - select S5PV210_SETUP_IDE - select S5P_DEV_FIMC0 - select S5P_DEV_FIMC1 - select S5P_DEV_FIMC2 - select S5P_DEV_MFC - select SAMSUNG_DEV_IDE - help - Machine support for Samsung SMDKC110 - S5PC110(MCP) is one of package option of S5PV210 Ditto. -endmenu - menu S5PV210 Machines -config MACH_SMDKV210 - bool SMDKV210 - select CPU_S5PV210 - select S3C_DEV_FB - select S3C_DEV_HSMMC - select S3C_DEV_HSMMC1 - select S3C_DEV_HSMMC2 - select S3C_DEV_HSMMC3 - select S3C_DEV_I2C1 - select S3C_DEV_I2C2 - select S3C_DEV_RTC - select S3C_DEV_USB_HSOTG - select S3C_DEV_WDT - select S5PV210_SETUP_FB_24BPP - select S5PV210_SETUP_I2C1 - select S5PV210_SETUP_I2C2 - select S5PV210_SETUP_IDE - select S5PV210_SETUP_KEYPAD - select S5PV210_SETUP_SDHCI - select S5PV210_SETUP_USB_PHY - select S5P_DEV_FIMC0 - select S5P_DEV_FIMC1 - select S5P_DEV_FIMC2 - select S5P_DEV_JPEG - select S5P_DEV_MFC - select SAMSUNG_DEV_ADC - select SAMSUNG_DEV_BACKLIGHT - select SAMSUNG_DEV_IDE - select SAMSUNG_DEV_KEYPAD - select SAMSUNG_DEV_PWM - select SAMSUNG_DEV_TS - help - Machine support for Samsung SMDKV210 - Ditto. -config MACH_TORBRECK - bool Torbreck - select ARCH_SPARSEMEM_ENABLE - select CPU_S5PV210 - select S3C_DEV_HSMMC - select S3C_DEV_HSMMC1 - select S3C_DEV_HSMMC2 - select S3C_DEV_HSMMC3 - select S3C_DEV_I2C1 - select S3C_DEV_I2C2 - select
Re: [PATCH v5 05/14] drm/exynos: dsi: add pass TE host ops to support LCD I80 interface
Hi Thierry, On 07/16/2014 04:54 PM, Thierry Reding wrote: On Wed, Jul 16, 2014 at 11:23:09AM +0900, YoungJun Cho wrote: Hi Inki, On 07/15/2014 11:34 AM, Inki Dae wrote: On 2014년 07월 14일 20:03, Thierry Reding wrote: On Mon, Jul 14, 2014 at 07:45:28PM +0900, YoungJun Cho wrote: On 07/14/2014 06:41 PM, Thierry Reding wrote: [...] That said, I've been doing some research and it seems like we have a somewhat similar feature on Tegra. What happens there is that there are three GPIO pins that can be repurposed for TE signalling. But as opposed to using them as interrupts the display controller can be configured to use them, upon which it will automatically handle the TE signal by sending the next frame. Could you explain more detail how the Tegra display controller could be configured with this GPIO pins? I have no idea except that the display controller registers this GPIO as an IRQ. On Tegra the display controller has a special register that can be programmed to use one of the three GPIOs as TE signal. Then the display controller can be configured in one-shot (non-continuous) mode, which means that software needs to explicitly set a trigger bit to tell the display controller to send a new frame. If TE signalling is enabled, then the display controller will not immediately send a new frame when triggered but wait for signalling of this GPIO. So we have at least two very different implementations of this on two different SoCs. Further the specification explicitly recommends using the BTA sequence and DSI protocol to wait for TE. So I still think that controllers that provide an additional, non-spec compliant method to signal TE should handle it separately rather than within DSI. Otherwise we essentially need to make the DSI core aware of all these quirks, and I'd rather avoid that. You mean, the DSI specification guides to use BTA, so it's better to use display controller rather than DSIM, right? What I'm saying is that there's nothing about a side-band TE wire in the DSI spec. In fact the spec explicitly says that this mechanism of an external TE wire from older protocols (DBI) was replaced by the BTA sequence over the protocol. Now, my understanding is that using the BTA sequence over the DSI protocol would introduce some latency and that forces some panel vendors to still provide a side-band TE wire even in DSI compliant panels. But since this is not part of the specification there is no standard way to do this (as evidenced by Tegra and Exynos). Therefore putting such functionality into the core DSI code is bad. But that doesn't mean that you have to put this functionality into the display controller driver on Exynos. What I'm saying is that it should be handled by the SoC driver rather than the core. Where exactly probably depends on the particular case. As Inki commented before, I'll try to use remote-endpoint property of DSI device node in exynos DSIM driver and call FIMD notifier. Sounds like it matches what I said above. I'm not a huge fan of notifiers, but if it works for you I suppose that's fine. The alternative would be to directly call a FIMD function, which is somewhat more explicit than a notifier. Yes, I also like explicit call, so I want to use dsi_host_ops and calls it in panel. But there is an objection to use dis_host_ops, we think notifier in exynos dsim for fimd(display controller). There are other ways to explicitly call into the display controller. You could for example get access to the CRTC that DSIM is currently connected to (via exynos_dsi.encoder-crtc) and then cast that to a struct exynos_drm_crtc and call a function to trigger a new frame to be sent (for example exynos_drm_crtc_send_frame()). This assumes that you can safely cast struct drm_crtc * to struct exynos_drm_crtc *, but that shouldn't be a problem. With the above, you could make the DSIM handle the TE signal interrupts and trigger the DC using the new exynos_drm_crtc_send_frame() function. It seems better than the use of notifier. Actually, original patch used this way except TE event. Mr. Cho, let's use remote-endpoint property and this way instead of notifier. The struct exynos_dsi has panel_node, which is valid by exynos_dsi_host_attach() is called from panel, we could use it instead of getting new remote-endpoint node. So after called exynos_dsi_host_attach(), the dsi driver could know that the panel supports mipi command mode or video mode, and if the panel is for mipi command mode one, dsi driver gets panel te gpio and registers its irq. Why does the TE GPIO even need to be in the panel's device tree node? Wouldn't it make more sense for it to be in the DSIM node? After all that's what the GPIO is connected to, right? Well, at least logically if not physically. I also agree that the GPIO in DT means the connection after all. But the panel provides the TE pin(this is obvious) and decides the DSIM mode(command or video). This TE pin is useless in video mode. So I think
Re: [PATCH 18/19] ARM: SAMSUNG: Remove remaining legacy code
On Fri, 2014-07-04 at 19:48 +0200, Tomasz Figa wrote: After refactoring suspend/resume, which was last part with dependencies on legacy code, all Kconfig symbols related to Samsung ATAGS support can be deselected and more unused code removed. This includes most of s5p-* code as well, as s5pv210 was their last user. Signed-off-by: Tomasz Figa t.f...@samsung.com --- I noticed another thing now this patch showed up in next-20140716. [...] diff --git a/arch/arm/plat-samsung/Kconfig b/arch/arm/plat-samsung/Kconfig index f8185b5..1091b0a 100644 --- a/arch/arm/plat-samsung/Kconfig +++ b/arch/arm/plat-samsung/Kconfig @@ -6,29 +6,16 @@ config PLAT_SAMSUNG bool - depends on PLAT_S3C24XX || ARCH_S3C64XX || PLAT_S5P || ARCH_EXYNOS + depends on PLAT_S3C24XX || ARCH_S3C64XX || ARCH_EXYNOS || ARCH_S5PV210 default y select GENERIC_IRQ_CHIP select NO_IOPORT_MAP help Base platform code for all Samsung SoC based systems -config PLAT_S5P - bool - depends on ARCH_S5PV210 - default y - select ARCH_REQUIRE_GPIOLIB - select ARM_VIC - select NO_IOPORT_MAP - select PLAT_SAMSUNG - select S3C_GPIO_TRACK - select S5P_GPIO_DRVSTR - help - Base platform code for Samsung's S5P series SoC. - After this patch that symbol is still referenced in: drivers/media/platform/Kconfig:159: depends on VIDEO_DEV VIDEO_V4L2 (PLAT_S5P || ARCH_EXYNOS) drivers/media/platform/Kconfig:169: depends on VIDEO_DEV VIDEO_V4L2 (PLAT_S5P || ARCH_EXYNOS) drivers/media/platform/Kconfig:177: depends on VIDEO_DEV VIDEO_V4L2 (PLAT_S5P || ARCH_EXYNOS) drivers/media/platform/exynos4-is/Kconfig:5:depends on (PLAT_S5P || ARCH_EXYNOS) drivers/media/platform/s5p-tv/Kconfig:11: depends on (PLAT_S5P || ARCH_EXYNOS) PM_RUNTIME drivers/usb/host/Kconfig:223: depends on PLAT_S5P || ARCH_EXYNOS drivers/usb/host/Kconfig:530: depends on PLAT_S5P || ARCH_EXYNOS Again, I assume patches to remove these references are pending. But is that correct? 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 18/19] ARM: SAMSUNG: Remove remaining legacy code
On Fri, 2014-07-04 at 19:48 +0200, Tomasz Figa wrote: After refactoring suspend/resume, which was last part with dependencies on legacy code, all Kconfig symbols related to Samsung ATAGS support can be deselected and more unused code removed. This includes most of s5p-* code as well, as s5pv210 was their last user. Signed-off-by: Tomasz Figa t.f...@samsung.com --- And I noticed another issue as this patch showed up in linux-next (this should be the last issue for this series). [...] diff --git a/arch/arm/plat-samsung/Kconfig b/arch/arm/plat-samsung/Kconfig index f8185b5..1091b0a 100644 --- a/arch/arm/plat-samsung/Kconfig +++ b/arch/arm/plat-samsung/Kconfig [...] @@ -64,31 +51,6 @@ config SAMSUNG_ATAGS if SAMSUNG_ATAGS -# options for IRQ support - -config S5P_IRQ - def_bool ARCH_S5PV210 - help - Support common interrupt part for ARCH_S5P SoCs - -config S5P_EXT_INT - bool - help - Use the external interrupts (other than GPIO interrupts.) - -config S5P_GPIO_INT - bool - help - Common code for the GPIO interrupts (other than external interrupts.) - -# options for gpio configuration support - -config S5P_GPIO_DRVSTR - bool - help - Internal configuration to get and set correct GPIO driver strength - helper - This one is used (as a macro) in drivers/gpio/gpio-samsung.c. Is a patch that touches that macro queued somewhere? config SAMSUNG_GPIO_EXTRA int Number of additional GPIO pins default 128 if SAMSUNG_GPIO_EXTRA128 Thanks, 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: [RESEND PATCH v2] ARM: exynos4: hotplug: Fix CPU idle clock down after CPU off
Hi Krzysztof,
Please see my comment below.
On 16.07.2014 10:23, Krzysztof Kozlowski wrote:
On Exynos4 USE_DELAYED_RESET_ASSERTION must be set in
ARM_COREx_OPTION register during CPU power down. This is the proper way
of powering down CPU on Exynos4.
Additionally on Exynos4212 without this the CPU clock down feature won't
work after powering down some CPU and the online CPUs will work at full
frequency chosen by CPUfreq governor.
Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
[snip]
@@ -36,6 +36,14 @@ static inline void cpu_leave_lowpower(void)
: =r (v)
: Ir (CR_C), Ir (0x40)
: cc);
+
+ if (soc_is_exynos4()) {
+ unsigned int tmp;
+
+ tmp = __raw_readl(EXYNOS_ARM_CORE_OPTION(core_id));
+ tmp = ~(S5P_USE_DELAYED_RESET_ASSERTION);
+ __raw_writel(tmp, EXYNOS_ARM_CORE_OPTION(core_id));
+ }
This code is executed only if the CPU doesn't manage to power off before
already receiving a wake-up event. Otherwise the context is lost after
wfi(), as the core power is being cut down.
The normal wake-up path goes through platsmp's exynos_boot_secondary()
and I believe that setting of S5P_USE_DELAYED_RESET_ASSERTION should be
taken care there as well.
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: [RESEND PATCH v2] ARM: exynos4: hotplug: Fix CPU idle clock down after CPU off
On śro, 2014-07-16 at 12:48 +0200, Tomasz Figa wrote:
Hi Krzysztof,
Please see my comment below.
On 16.07.2014 10:23, Krzysztof Kozlowski wrote:
On Exynos4 USE_DELAYED_RESET_ASSERTION must be set in
ARM_COREx_OPTION register during CPU power down. This is the proper way
of powering down CPU on Exynos4.
Additionally on Exynos4212 without this the CPU clock down feature won't
work after powering down some CPU and the online CPUs will work at full
frequency chosen by CPUfreq governor.
Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
[snip]
@@ -36,6 +36,14 @@ static inline void cpu_leave_lowpower(void)
: =r (v)
: Ir (CR_C), Ir (0x40)
: cc);
+
+ if (soc_is_exynos4()) {
+ unsigned int tmp;
+
+ tmp = __raw_readl(EXYNOS_ARM_CORE_OPTION(core_id));
+ tmp = ~(S5P_USE_DELAYED_RESET_ASSERTION);
+ __raw_writel(tmp, EXYNOS_ARM_CORE_OPTION(core_id));
+ }
This code is executed only if the CPU doesn't manage to power off before
already receiving a wake-up event. Otherwise the context is lost after
wfi(), as the core power is being cut down.
The normal wake-up path goes through platsmp's exynos_boot_secondary()
and I believe that setting of S5P_USE_DELAYED_RESET_ASSERTION should be
taken care there as well.
You're right. Thanks for pointing this, I'll fix it.
Best regards,
Krzysztof
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] ARM: EXYNOS: Fix build with PM_SLEEP=n
Hi Krzysztof, On 14.07.2014 09:45, Krzysztof Kozlowski wrote: Fix building of exynos defconfig with disabled PM_SLEEP: CONFIG_PM_SLEEP=n CONFIG_PM_SLEEP_SMP=n CONFIG_SUSPEND=n by moving functions for power up/down of CPU and cluster to platsmp.c The build error messages: arch/arm/mach-exynos/built-in.o: In function `exynos_boot_secondary': arch/arm/mach-exynos/platsmp.c:111: undefined reference to `exynos_cpu_power_state' arch/arm/mach-exynos/platsmp.c:112: undefined reference to `exynos_cpu_power_up' arch/arm/mach-exynos/platsmp.c:116: undefined reference to `exynos_cpu_power_state' make: *** [vmlinux] Error 1 Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com --- Changes since v1: 1. Use different solution - just move the power up/down functions to a common place instead of adding stubs in common.h. Suggested by Tomasz Figa. --- arch/arm/mach-exynos/platsmp.c | 66 ++ arch/arm/mach-exynos/pm.c | 66 -- 2 files changed, 66 insertions(+), 66 deletions(-) Reviewed-by: Tomasz Figa t.f...@samsung.com -- Best regards, Tomasz -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] serial: samsung: get fifosize from DT and clean up
Hi Naveen, On 14.07.2014 13:37, Naveen Krishna Chatradhi wrote: This patch set does the following 1: Get fifosize from DT node. But, not mandating it. 2. Corrects the case and default order in a switch 3. Defines a variable to simply the code. Console messages on Exynos5420 based peach pit and pi works fine. Naveen Krishna Chatradhi (3): serial: samsung: get fifosize via device tree serial: samsung: correct the case and default order in switch serial: samsung: improve code clarity by defining a variable .../devicetree/bindings/serial/samsung_uart.txt|4 drivers/tty/serial/samsung.c | 19 +-- 2 files changed, 17 insertions(+), 6 deletions(-) Reviewed-by: Tomasz Figa t.f...@samsung.com -- Best regards, Tomasz -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3] ARM: exynos4: hotplug: Fix CPU idle clock down after CPU off
On Exynos4 USE_DELAYED_RESET_ASSERTION must be set in
ARM_COREx_OPTION register during CPU power down. This is the proper way
of powering down CPU on Exynos4.
Additionally on Exynos4212 without this the CPU clock down feature won't
work after powering down some CPU and the online CPUs will work at full
frequency chosen by CPUfreq governor.
Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
---
Changes since v2:
1. Add missing disable of the use delayed reset assertion feature
when starting secondary CPU (suggested by Tomasz Figa).
Changes since v1:
1. Use delayed reset assertion on all Exynos4 family and all cores, not
only on core 1 of Exynos4212.
2. Rebase on Tomasz Figa's patch:
ARM: EXYNOS: Fix core ID used by platsmp and hotplug code
http://www.spinics.net/lists/linux-samsung-soc/msg31604.html
Tomasz's patch is currently applied to Kukjin's v3.16-samsung-fixes-4
---
arch/arm/mach-exynos/common.h | 4
arch/arm/mach-exynos/hotplug.c | 21 +++--
arch/arm/mach-exynos/platsmp.c | 24
arch/arm/mach-exynos/regs-pmu.h | 3 +++
4 files changed, 50 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-exynos/common.h b/arch/arm/mach-exynos/common.h
index 1ee91763fa7c..2e08fa793aff 100644
--- a/arch/arm/mach-exynos/common.h
+++ b/arch/arm/mach-exynos/common.h
@@ -137,6 +137,10 @@ extern void __init exynos_pm_init(void);
static inline void exynos_pm_init(void) {}
#endif
+#ifdef CONFIG_SMP
+extern void exynos_clear_delayed_reset_assertion(u32 core_id);
+#endif
+
extern void exynos_cpu_resume(void);
extern struct smp_operations exynos_smp_ops;
diff --git a/arch/arm/mach-exynos/hotplug.c b/arch/arm/mach-exynos/hotplug.c
index 920a4baa53cd..c58aa0f161bf 100644
--- a/arch/arm/mach-exynos/hotplug.c
+++ b/arch/arm/mach-exynos/hotplug.c
@@ -22,7 +22,7 @@
#include common.h
#include regs-pmu.h
-static inline void cpu_leave_lowpower(void)
+static inline void cpu_leave_lowpower(u32 core_id)
{
unsigned int v;
@@ -36,6 +36,8 @@ static inline void cpu_leave_lowpower(void)
: =r (v)
: Ir (CR_C), Ir (0x40)
: cc);
+
+ exynos_clear_delayed_reset_assertion(core_id);
}
static inline void platform_do_lowpower(unsigned int cpu, int *spurious)
@@ -47,6 +49,19 @@ static inline void platform_do_lowpower(unsigned int cpu,
int *spurious)
/* Turn the CPU off on next WFI instruction. */
exynos_cpu_power_down(core_id);
+ if (soc_is_exynos4()) {
+ unsigned int tmp;
+
+ /*
+* Exynos 4 SoCs require setting
+* USE_DELAYED_RESET_ASSERTION so the CPU idle
+* clock down feature could properly detect
+* global idle state when CPUx is off.
+*/
+ tmp = __raw_readl(EXYNOS_ARM_CORE_OPTION(core_id));
+ tmp |= S5P_USE_DELAYED_RESET_ASSERTION;
+ __raw_writel(tmp, EXYNOS_ARM_CORE_OPTION(core_id));
+ }
wfi();
@@ -76,6 +91,8 @@ static inline void platform_do_lowpower(unsigned int cpu, int
*spurious)
void __ref exynos_cpu_die(unsigned int cpu)
{
int spurious = 0;
+ u32 mpidr = cpu_logical_map(cpu);
+ u32 core_id = MPIDR_AFFINITY_LEVEL(mpidr, 0);
v7_exit_coherency_flush(louis);
@@ -85,7 +102,7 @@ void __ref exynos_cpu_die(unsigned int cpu)
* bring this CPU back into the world of cache
* coherency, and then restore interrupts
*/
- cpu_leave_lowpower();
+ cpu_leave_lowpower(core_id);
if (spurious)
pr_warn(CPU%u: %u spurious wakeup calls\n, cpu, spurious);
diff --git a/arch/arm/mach-exynos/platsmp.c b/arch/arm/mach-exynos/platsmp.c
index 50b9aad5e27b..9ce0567fbe87 100644
--- a/arch/arm/mach-exynos/platsmp.c
+++ b/arch/arm/mach-exynos/platsmp.c
@@ -32,6 +32,27 @@
extern void exynos4_secondary_startup(void);
+/*
+ * Clear the USE_DELAYED_RESET_ASSERTION option, set on Exynos4 SoCs
+ * during hot-unplugging CPUx.
+ *
+ * It won't harm if this is called during first boot of secondary CPU.
+ *
+ * Exynos4 SoCs require setting USE_DELAYED_RESET_ASSERTION so the CPU idle
+ * clock down feature could properly detect global idle state when
+ * CPUx is off.
+ */
+void exynos_clear_delayed_reset_assertion(u32 core_id)
+{
+ if (soc_is_exynos4()) {
+ unsigned int tmp;
+
+ tmp = __raw_readl(EXYNOS_ARM_CORE_OPTION(core_id));
+ tmp = ~(S5P_USE_DELAYED_RESET_ASSERTION);
+ __raw_writel(tmp, EXYNOS_ARM_CORE_OPTION(core_id));
+ }
+}
+
static inline void __iomem *cpu_boot_reg_base(void)
{
if (soc_is_exynos4210() samsung_rev() == EXYNOS4210_REV_1_1)
@@ -170,6 +191,9 @@ static int exynos_boot_secondary(unsigned int cpu, struct
task_struct *idle)
Re: [PATCH 2/2] ARM: dts: ODROID i2c improvements
On 16.07.2014 10:50, Daniel Drake wrote:
Increase max i2c bus frequency beyond the default for faster
data transfers. According to the manual, these faster speeds are
only available when the board is wired up the right way. In this case,
the vendor kernel has run at this speed for a long time.
sda-delay is needed for talking to RTC on PMIC, otherwise the i2c
controller never sees an ACK. Strangely the other PMIC i2c slave (the
main one) works fine even without this delay. I Chose value 100 to
match the vendor kernel.
Signed-off-by: Daniel Drake dr...@endlessm.com
---
arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
index cb6f55f..adadaf9 100644
--- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
+++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
@@ -134,6 +134,8 @@
i2c@1386 {
pinctrl-0 = i2c0_bus;
pinctrl-names = default;
+ samsung,i2c-sda-delay = 100;
+ samsung,i2c-max-bus-freq = 40;
status = okay;
usb3503: usb3503@08 {
Reviewed-by: Tomasz Figa t.f...@samsung.com
--
Best regards,
Tomasz
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ARM: dts: Enable PMIC interrupts on ODROID
On 16.07.2014 10:50, Daniel Drake wrote:
The ODROID kernel shows that the PMIC interrupt line is hooked up
to pin GPX3-2.
This is needed for the max77686-irq driver to create the PMIC IRQ
domain, which is needed by max77686-rtc.
Signed-off-by: Daniel Drake dr...@endlessm.com
---
arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
index 6d6d23c..cb6f55f 100644
--- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
+++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
@@ -148,6 +148,10 @@
max77686: pmic@09 {
compatible = maxim,max77686;
+ interrupt-parent = gpx3;
+ interrupts = 2 0;
+ pinctrl-names = default;
+ pinctrl-0 = max77686_irq;
reg = 0x09;
#clock-cells = 1;
@@ -368,4 +372,11 @@
samsung,pins = gpx1-3;
samsung,pin-pud = 0;
};
+
+ max77686_irq: max77686-irq {
+ samsung,pins = gpx3-2;
+ samsung,pin-function = 0;
+ samsung,pin-pud = 0;
+ samsung,pin-drv = 0;
+ };
};
Reviewed-by: Tomasz Figa t.f...@samsung.com
--
Best regards,
Tomasz
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 04/19] serial: samsung: Remove support for legacy clock code
On 16.07.2014 11:27, Paul Bolle wrote: On Fri, 2014-07-04 at 19:48 +0200, Tomasz Figa wrote: All Samsung platforms are now using the Common Clock Framework and the legacy clock code is being removed, so remove related dead code from samsung-serial driver as well. Reported-by: Arnd Bergmann a...@arndb.de Signed-off-by: Tomasz Figa t.f...@samsung.com Cc: Greg Kroah-Hartman gre...@linuxfoundation.org (maintainer:SERIAL DRIVERS) Cc: Jiri Slaby jsl...@suse.cz (supporter:TTY LAYER) Cc: linux-ser...@vger.kernel.org (open list:SERIAL DRIVERS) --- drivers/tty/serial/samsung.c | 4 1 file changed, 4 deletions(-) This just entered linux-next (see next-20140716). diff --git a/drivers/tty/serial/samsung.c b/drivers/tty/serial/samsung.c index 36c7747..cae8ebd 100644 --- a/drivers/tty/serial/samsung.c +++ b/drivers/tty/serial/samsung.c @@ -47,10 +47,6 @@ #include asm/irq.h -#ifdef CONFIG_SAMSUNG_CLOCK -#include plat/clock.h -#endif - #include samsung.h #if defined(CONFIG_SERIAL_SAMSUNG_DEBUG) \ There are three further references to CONFIG_SAMSUNG_CLOCK in this file. Those should be removed too, shouldn't they? That's right. Apparently I missed them. I guess that's not critical, though, and could be done in separate patch, right? 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 11/19] ARM: S5PV210: Remove support for board files
On 16.07.2014 12:04, Paul Bolle wrote: On Fri, 2014-07-04 at 19:48 +0200, Tomasz Figa wrote: [snip] - -config MACH_AQUILA -bool Aquila -select CPU_S5PV210 -select S3C_DEV_FB -select S3C_DEV_HSMMC -select S3C_DEV_HSMMC1 -select S3C_DEV_HSMMC2 -select S5PV210_SETUP_FB_24BPP -select S5PV210_SETUP_SDHCI -select S5PV210_SETUP_USB_PHY -select S5P_DEV_FIMC0 -select S5P_DEV_FIMC1 -select S5P_DEV_FIMC2 -select S5P_DEV_ONENAND -help - Machine support for the Samsung Aquila target based on S5PC110 SoC - This symbol is still referenced in sound/soc/samsung/Kconfig. More code that I missed. I believe that both sound card drivers for Goni and Aquilla could be replaced with simple cards in DT, so I'll send a follow-up patch for this. Most likely the same is the case for SMDK boards, but they don't seem to have any active users (see cover letter for more details), which means that probably they could be simply dropped from sound/soc/samsung/Kconfig in another follow-up patch. 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 18/19] ARM: SAMSUNG: Remove remaining legacy code
On 16.07.2014 11:47, Paul Bolle wrote: On Fri, 2014-07-04 at 19:48 +0200, Tomasz Figa wrote: [snip] config SAMSUNG_GPIO_EXTRA int Number of additional GPIO pins default 128 if SAMSUNG_GPIO_EXTRA128 So a second order effect is that SAMSUNG_GPIO_EXTRA can now be removed. Which implies that SAMSUNG_GPIO_EXTRA64 and SAMSUNG_GPIO_EXTRA128 can also be removed. Should I submit the trivial patch to do that or is a patch already queued somewhere? Please do if you don't mind. That's one more thing I missed. 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 18/19] ARM: SAMSUNG: Remove remaining legacy code
On 16.07.2014 12:15, Paul Bolle wrote: On Fri, 2014-07-04 at 19:48 +0200, Tomasz Figa wrote: [snip] -config PLAT_S5P -bool -depends on ARCH_S5PV210 -default y -select ARCH_REQUIRE_GPIOLIB -select ARM_VIC -select NO_IOPORT_MAP -select PLAT_SAMSUNG -select S3C_GPIO_TRACK -select S5P_GPIO_DRVSTR -help - Base platform code for Samsung's S5P series SoC. - After this patch that symbol is still referenced in: drivers/media/platform/Kconfig:159: depends on VIDEO_DEV VIDEO_V4L2 (PLAT_S5P || ARCH_EXYNOS) drivers/media/platform/Kconfig:169: depends on VIDEO_DEV VIDEO_V4L2 (PLAT_S5P || ARCH_EXYNOS) drivers/media/platform/Kconfig:177: depends on VIDEO_DEV VIDEO_V4L2 (PLAT_S5P || ARCH_EXYNOS) drivers/media/platform/exynos4-is/Kconfig:5:depends on (PLAT_S5P || ARCH_EXYNOS) drivers/media/platform/s5p-tv/Kconfig:11: depends on (PLAT_S5P || ARCH_EXYNOS) PM_RUNTIME drivers/usb/host/Kconfig:223: depends on PLAT_S5P || ARCH_EXYNOS drivers/usb/host/Kconfig:530: depends on PLAT_S5P || ARCH_EXYNOS Again, I assume patches to remove these references are pending. But is that correct? I had two patches fixing those, but apparently this was lost in action. The correct solution is s/PLAT_S5P/ARCH_S5PV210/. I will include this in a follow-up series if nobody objects. 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 18/19] ARM: SAMSUNG: Remove remaining legacy code
On 16.07.2014 12:24, Paul Bolle wrote: On Fri, 2014-07-04 at 19:48 +0200, Tomasz Figa wrote: [snip] -config S5P_GPIO_DRVSTR -bool -help - Internal configuration to get and set correct GPIO driver strength - helper - This one is used (as a macro) in drivers/gpio/gpio-samsung.c. Is a patch that touches that macro queued somewhere? The code you mention should be removed as well as it's no longer needed. Will include in a follow-up series. Thanks for reporting this and remaining missed parts. 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 v3] ARM: exynos4: hotplug: Fix CPU idle clock down after CPU off
Hi Krzysztof,
On 16.07.2014 14:07, Krzysztof Kozlowski wrote:
[snip]
+#ifdef CONFIG_SMP
+extern void exynos_clear_delayed_reset_assertion(u32 core_id);
+#endif
Is the ifdef really needed? The only difference it makes if the function
is used but not compiled in is that with it the compilation will fail,
while without it the kernel won't link.
+
extern void exynos_cpu_resume(void);
extern struct smp_operations exynos_smp_ops;
[snip]
+/*
+ * Clear the USE_DELAYED_RESET_ASSERTION option, set on Exynos4 SoCs
+ * during hot-unplugging CPUx.
+ *
+ * It won't harm if this is called during first boot of secondary CPU.
+ *
+ * Exynos4 SoCs require setting USE_DELAYED_RESET_ASSERTION so the CPU idle
+ * clock down feature could properly detect global idle state when
+ * CPUx is off.
+ */
+void exynos_clear_delayed_reset_assertion(u32 core_id)
+{
+ if (soc_is_exynos4()) {
+ unsigned int tmp;
+
+ tmp = __raw_readl(EXYNOS_ARM_CORE_OPTION(core_id));
+ tmp = ~(S5P_USE_DELAYED_RESET_ASSERTION);
+ __raw_writel(tmp, EXYNOS_ARM_CORE_OPTION(core_id));
+ }
+}
The idea to make this a helper function is quite nice, but maybe it
could be extended into exynos_set_delayed_reset_assertion() and disable
or enable delayed assertion depending on another argument?
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 v3] ARM: exynos4: hotplug: Fix CPU idle clock down after CPU off
On śro, 2014-07-16 at 15:05 +0200, Tomasz Figa wrote:
Hi Krzysztof,
On 16.07.2014 14:07, Krzysztof Kozlowski wrote:
[snip]
+#ifdef CONFIG_SMP
+extern void exynos_clear_delayed_reset_assertion(u32 core_id);
+#endif
Is the ifdef really needed? The only difference it makes if the function
is used but not compiled in is that with it the compilation will fail,
while without it the kernel won't link.
Hmmm... I'll take another approach - just merge hotplug.c into
platsmp.c.
+
extern void exynos_cpu_resume(void);
extern struct smp_operations exynos_smp_ops;
[snip]
+/*
+ * Clear the USE_DELAYED_RESET_ASSERTION option, set on Exynos4 SoCs
+ * during hot-unplugging CPUx.
+ *
+ * It won't harm if this is called during first boot of secondary CPU.
+ *
+ * Exynos4 SoCs require setting USE_DELAYED_RESET_ASSERTION so the CPU idle
+ * clock down feature could properly detect global idle state when
+ * CPUx is off.
+ */
+void exynos_clear_delayed_reset_assertion(u32 core_id)
+{
+ if (soc_is_exynos4()) {
+ unsigned int tmp;
+
+ tmp = __raw_readl(EXYNOS_ARM_CORE_OPTION(core_id));
+ tmp = ~(S5P_USE_DELAYED_RESET_ASSERTION);
+ __raw_writel(tmp, EXYNOS_ARM_CORE_OPTION(core_id));
+ }
+}
The idea to make this a helper function is quite nice, but maybe it
could be extended into exynos_set_delayed_reset_assertion() and disable
or enable delayed assertion depending on another argument?
Sure, I'll change it.
Best regards,
Krzysztof
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] ARM: EXYNOS: Move code from hotplug.c to platsmp.c
Cleanup a little the SMP/hotplug code for Exynos by:
1. Moving completely all functions from hotplug.c into the platsmp.c;
2. Deleting the hotplug.c file.
After recent cleanups (e.g. 75ad2ab28f0f ARM: EXYNOS: use
v7_exit_coherency_flush macro for cache disabling) there was only CPU
power down related code in hotplug.c file. Keeping this file does not
give any benefits.
The commit only moves code around with one additional observable change:
the hotplug.c was compiled with custom CFLAGS (-march=armv7-a). These
CFLAGS are not necessary any more.
Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
---
arch/arm/mach-exynos/Makefile | 3 --
arch/arm/mach-exynos/common.h | 2 -
arch/arm/mach-exynos/hotplug.c | 92 --
arch/arm/mach-exynos/platsmp.c | 74 +
4 files changed, 74 insertions(+), 97 deletions(-)
delete mode 100644 arch/arm/mach-exynos/hotplug.c
diff --git a/arch/arm/mach-exynos/Makefile b/arch/arm/mach-exynos/Makefile
index 788f26d21141..0095de99d703 100644
--- a/arch/arm/mach-exynos/Makefile
+++ b/arch/arm/mach-exynos/Makefile
@@ -21,9 +21,6 @@ obj-$(CONFIG_PM_GENERIC_DOMAINS) += pm_domains.o
obj-$(CONFIG_SMP) += platsmp.o headsmp.o
-obj-$(CONFIG_HOTPLUG_CPU) += hotplug.o
-CFLAGS_hotplug.o += -march=armv7-a
-
plus_sec := $(call as-instr,.arch_extension sec,+sec)
AFLAGS_exynos-smc.o:=-Wa,-march=armv7-a$(plus_sec)
diff --git a/arch/arm/mach-exynos/common.h b/arch/arm/mach-exynos/common.h
index 1ee91763fa7c..907349d20c25 100644
--- a/arch/arm/mach-exynos/common.h
+++ b/arch/arm/mach-exynos/common.h
@@ -141,8 +141,6 @@ extern void exynos_cpu_resume(void);
extern struct smp_operations exynos_smp_ops;
-extern void exynos_cpu_die(unsigned int cpu);
-
/* PMU(Power Management Unit) support */
#define PMU_TABLE_END NULL
diff --git a/arch/arm/mach-exynos/hotplug.c b/arch/arm/mach-exynos/hotplug.c
deleted file mode 100644
index 920a4baa53cd..
--- a/arch/arm/mach-exynos/hotplug.c
+++ /dev/null
@@ -1,92 +0,0 @@
-/* linux arch/arm/mach-exynos4/hotplug.c
- *
- * Cloned from linux/arch/arm/mach-realview/hotplug.c
- *
- * Copyright (C) 2002 ARM Ltd.
- * All Rights Reserved
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
-*/
-
-#include linux/kernel.h
-#include linux/errno.h
-#include linux/smp.h
-#include linux/io.h
-
-#include asm/cacheflush.h
-#include asm/cp15.h
-#include asm/smp_plat.h
-
-#include common.h
-#include regs-pmu.h
-
-static inline void cpu_leave_lowpower(void)
-{
- unsigned int v;
-
- asm volatile(
- mrcp15, 0, %0, c1, c0, 0\n
- orr %0, %0, %1\n
- mcr p15, 0, %0, c1, c0, 0\n
- mrc p15, 0, %0, c1, c0, 1\n
- orr %0, %0, %2\n
- mcr p15, 0, %0, c1, c0, 1\n
- : =r (v)
- : Ir (CR_C), Ir (0x40)
- : cc);
-}
-
-static inline void platform_do_lowpower(unsigned int cpu, int *spurious)
-{
- u32 mpidr = cpu_logical_map(cpu);
- u32 core_id = MPIDR_AFFINITY_LEVEL(mpidr, 0);
-
- for (;;) {
-
- /* Turn the CPU off on next WFI instruction. */
- exynos_cpu_power_down(core_id);
-
- wfi();
-
- if (pen_release == core_id) {
- /*
-* OK, proper wakeup, we're done
-*/
- break;
- }
-
- /*
-* Getting here, means that we have come out of WFI without
-* having been woken up - this shouldn't happen
-*
-* Just note it happening - when we're woken, we can report
-* its occurrence.
-*/
- (*spurious)++;
- }
-}
-
-/*
- * platform-specific code to shutdown a CPU
- *
- * Called with IRQs disabled
- */
-void __ref exynos_cpu_die(unsigned int cpu)
-{
- int spurious = 0;
-
- v7_exit_coherency_flush(louis);
-
- platform_do_lowpower(cpu, spurious);
-
- /*
-* bring this CPU back into the world of cache
-* coherency, and then restore interrupts
-*/
- cpu_leave_lowpower();
-
- if (spurious)
- pr_warn(CPU%u: %u spurious wakeup calls\n, cpu, spurious);
-}
diff --git a/arch/arm/mach-exynos/platsmp.c b/arch/arm/mach-exynos/platsmp.c
index 50b9aad5e27b..b0679b6d5161 100644
--- a/arch/arm/mach-exynos/platsmp.c
+++ b/arch/arm/mach-exynos/platsmp.c
@@ -23,6 +23,7 @@
#include linux/of_address.h
#include asm/cacheflush.h
+#include asm/cp15.h
#include asm/smp_plat.h
#include asm/smp_scu.h
#include asm/firmware.h
@@ -32,6 +33,54 @@
extern void exynos4_secondary_startup(void);
+#ifdef CONFIG_HOTPLUG_CPU
+static inline void
[PATCH 3/3] ARM: exynos4: hotplug: Fix CPU idle clock down after CPU off
On Exynos4 USE_DELAYED_RESET_ASSERTION must be set in
ARM_COREx_OPTION register during CPU power down. This is the proper way
of powering down CPU on Exynos4.
Additionally on Exynos4212 without this the CPU clock down feature won't
work after powering down some CPU and the online CPUs will work at full
frequency chosen by CPUfreq governor.
Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
---
Changes since v3:
1. Remove declaration of exynos_clear_delayed_reset_assertion() in
header as hotplug code is integrated into platsmp.c file. Suggested
by Tomasz Figa.
2. Replace 'clear' helper with 'set' helper. Suggested by Tomasz Figa.
Changes since v2:
1. Add missing disable of the use delayed reset assertion feature
when starting secondary CPU (suggested by Tomasz Figa).
Changes since v1:
1. Use delayed reset assertion on all Exynos4 family and all cores, not
only on core 1 of Exynos4212.
2. Rebase on Tomasz Figa's patch:
ARM: EXYNOS: Fix core ID used by platsmp and hotplug code
http://www.spinics.net/lists/linux-samsung-soc/msg31604.html
Tomasz's patch is currently applied to Kukjin's v3.16-samsung-fixes-4
---
arch/arm/mach-exynos/platsmp.c | 43 +++--
arch/arm/mach-exynos/regs-pmu.h | 3 +++
2 files changed, 44 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-exynos/platsmp.c b/arch/arm/mach-exynos/platsmp.c
index 6a0de7591f73..393b1a00dbcb 100644
--- a/arch/arm/mach-exynos/platsmp.c
+++ b/arch/arm/mach-exynos/platsmp.c
@@ -33,8 +33,32 @@
extern void exynos4_secondary_startup(void);
+/*
+ * Set or clear the USE_DELAYED_RESET_ASSERTION option, set on Exynos4 SoCs
+ * during hot-(un)plugging CPUx.
+ *
+ * The feature can be cleared safely during first boot of secondary CPU.
+ *
+ * Exynos4 SoCs require setting USE_DELAYED_RESET_ASSERTION during powering
+ * down a CPU so the CPU idle clock down feature could properly detect global
+ * idle state when CPUx is off.
+ */
+static void exynos_set_delayed_reset_assertion(u32 core_id, bool enable)
+{
+ if (soc_is_exynos4()) {
+ unsigned int tmp;
+
+ tmp = __raw_readl(EXYNOS_ARM_CORE_OPTION(core_id));
+ if (enable)
+ tmp |= S5P_USE_DELAYED_RESET_ASSERTION;
+ else
+ tmp = ~(S5P_USE_DELAYED_RESET_ASSERTION);
+ __raw_writel(tmp, EXYNOS_ARM_CORE_OPTION(core_id));
+ }
+}
+
#ifdef CONFIG_HOTPLUG_CPU
-static inline void cpu_leave_lowpower(void)
+static inline void cpu_leave_lowpower(u32 core_id)
{
unsigned int v;
@@ -48,6 +72,8 @@ static inline void cpu_leave_lowpower(void)
: =r (v)
: Ir (CR_C), Ir (0x40)
: cc);
+
+exynos_set_delayed_reset_assertion(core_id, false);
}
static inline void platform_do_lowpower(unsigned int cpu, int *spurious)
@@ -60,6 +86,14 @@ static inline void platform_do_lowpower(unsigned int cpu,
int *spurious)
/* Turn the CPU off on next WFI instruction. */
exynos_cpu_power_down(core_id);
+ /*
+* Exynos4 SoCs require setting
+* USE_DELAYED_RESET_ASSERTION so the CPU idle
+* clock down feature could properly detect
+* global idle state when CPUx is off.
+*/
+ exynos_set_delayed_reset_assertion(core_id, true);
+
wfi();
if (pen_release == core_id) {
@@ -219,6 +253,9 @@ static int exynos_boot_secondary(unsigned int cpu, struct
task_struct *idle)
udelay(10);
}
+ /* No harm if this is called during first boot of secondary CPU */
+ exynos_set_delayed_reset_assertion(core_id, false);
+
/*
* now the secondary core is starting up let it run its
* calibrations, then wait for it to finish
@@ -309,6 +346,8 @@ static void __init exynos_smp_prepare_cpus(unsigned int
max_cpus)
static void exynos_cpu_die(unsigned int cpu)
{
int spurious = 0;
+ u32 mpidr = cpu_logical_map(cpu);
+ u32 core_id = MPIDR_AFFINITY_LEVEL(mpidr, 0);
v7_exit_coherency_flush(louis);
@@ -318,7 +357,7 @@ static void exynos_cpu_die(unsigned int cpu)
* bring this CPU back into the world of cache
* coherency, and then restore interrupts
*/
- cpu_leave_lowpower();
+ cpu_leave_lowpower(core_id);
if (spurious)
pr_warn(CPU%u: %u spurious wakeup calls\n, cpu, spurious);
diff --git a/arch/arm/mach-exynos/regs-pmu.h b/arch/arm/mach-exynos/regs-pmu.h
index 1d13b08708f0..59bd92112842 100644
--- a/arch/arm/mach-exynos/regs-pmu.h
+++ b/arch/arm/mach-exynos/regs-pmu.h
@@ -25,6 +25,7 @@
#define S5P_USE_STANDBY_WFI0 (1 16)
#define S5P_USE_STANDBY_WFE0 (1 24)
+#define S5P_USE_DELAYED_RESET_ASSERTIONBIT(12)
#define EXYNOS_SWRESET
[PATCH 2/3] ARM: EXYNOS: Remove unneeded __ref annotation for cpu_die function
The __ref annotation for exynos_cpu_die() is not needed because the
function does not reference any __init/__exit symbol or call.
Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
---
arch/arm/mach-exynos/platsmp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-exynos/platsmp.c b/arch/arm/mach-exynos/platsmp.c
index b0679b6d5161..6a0de7591f73 100644
--- a/arch/arm/mach-exynos/platsmp.c
+++ b/arch/arm/mach-exynos/platsmp.c
@@ -306,7 +306,7 @@ static void __init exynos_smp_prepare_cpus(unsigned int
max_cpus)
*
* Called with IRQs disabled
*/
-static void __ref exynos_cpu_die(unsigned int cpu)
+static void exynos_cpu_die(unsigned int cpu)
{
int spurious = 0;
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 2/7] arm64: Introduce VA_BITS and translation level options
On Jul 16, 2014, at 6:44 AM, Catalin Marinas wrote: On 15 Jul 2014, at 15:53, Jungseok Lee jungseokle...@gmail.com wrote: On Jul 15, 2014, at 7:41 AM, Catalin Marinas wrote: On Mon, Jul 14, 2014 at 09:38:59PM +0100, Joel Schopp wrote: I agree that these patches would be very useful. I just rebased my fix for a VTTBR_BADDR_MASK bug on one of these patches that could be pulled out independently. See https://lists.cs.columbia.edu/pipermail/kvmarm/2014-July/010480.html The original author Jungseok Lee is no longer available to work on future versions of these patches. I was thinking that if they didn't get picked up as they are that with the original author's blessing I would pick them up and keep them forward ported/resubmitted. I have an SOC to test them on. The patches are pretty good. I'll give them a try tomorrow and if there isn't something fundamental missing I'll consider taking them for 3.17. Hi All, If only stage1 side is taken and merged, KVM should be disabled under 4 level lookups with the following configuration adjustment. I've tested it on top of arm64/for-next/core branch and it works fine. --- a/arch/arm64/kvm/Kconfig +++ b/arch/arm64/kvm/Kconfig @@ -18,6 +18,7 @@ if VIRTUALIZATION config KVM bool Kernel-based Virtual Machine (KVM) support + depends on !ARM64_4_LEVELS select MMU_NOTIFIER select PREEMPT_NOTIFIERS select ANON_INODES However, I don't know whether it does make sense or not. I added some patches on top of your series, I hope to be able to post them tomorrow. My interim approach was to disable 4-levels if KVM is enabled. Hi Catalin, Thanks for the work! I will take a close look at them. - Jungseok Lee-- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 04/19] serial: samsung: Remove support for legacy clock code
On Wed, 2014-07-16 at 14:43 +0200, Tomasz Figa wrote: On 16.07.2014 11:27, Paul Bolle wrote: There are three further references to CONFIG_SAMSUNG_CLOCK in this file. Those should be removed too, shouldn't they? That's right. Apparently I missed them. I guess that's not critical, though, and could be done in separate patch, right? This is not critical at all, so that's fine with me. 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 04/19] serial: samsung: Remove support for legacy clock code
On Wed, 2014-07-16 at 16:26 +0200, Paul Bolle wrote: On Wed, 2014-07-16 at 14:43 +0200, Tomasz Figa wrote: That's right. Apparently I missed them. I guess that's not critical, though, and could be done in separate patch, right? This is not critical at all, so that's fine with me. Actually, that's only correct if the solution here is to just remove the (currently) dead code hidden behind CONFIG_SAMSUNG_CLOCK. But if the solution requires something less trivial, that might be quite wrong. So please disregard my comment! 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 04/19] serial: samsung: Remove support for legacy clock code
On 16.07.2014 16:35, Paul Bolle wrote: On Wed, 2014-07-16 at 16:26 +0200, Paul Bolle wrote: On Wed, 2014-07-16 at 14:43 +0200, Tomasz Figa wrote: That's right. Apparently I missed them. I guess that's not critical, though, and could be done in separate patch, right? This is not critical at all, so that's fine with me. Actually, that's only correct if the solution here is to just remove the (currently) dead code hidden behind CONFIG_SAMSUNG_CLOCK. But if the solution requires something less trivial, that might be quite wrong. So please disregard my comment! The code between those ifdefs is no longer used, because all Samsung platforms use the Common Clock Framework after this series. So I believe we can safely remove this dead code. Best regards, Tomasz -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 2/4] usb: host: xhci-plat: Get PHYs for xhci's hcds
On Wed, Jul 16, 2014 at 01:51:40PM +0530, Vivek Gautam wrote:
The host controller by itself may sometimes need to handle PHY
and/or calibrate some of the PHY settings to get full support out
of the PHY controller. The PHY core provides a calibration
funtionality now to do so.
Therefore, facilitate getting the two possible PHYs, viz.
USB 2.0 type (UTMI+) and USB 3.0 type (PIPE3).
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
Changes from v3:
- Modified error message as per review comments from Julius.
drivers/usb/host/xhci-plat.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index 1a0cf9f..b1c0364 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -16,6 +16,7 @@
#include linux/module.h
#include linux/of.h
#include linux/platform_device.h
+#include linux/phy/phy.h
#include linux/slab.h
#include linux/usb/xhci_pdriver.h
@@ -180,6 +181,15 @@ static int xhci_plat_probe(struct platform_device *pdev)
goto put_hcd;
}
+ /* Get possile USB 2.0 type PHY (UTMI+) available with xhci */
+ hcd-gen_phy = devm_phy_get(pdev-dev, usb2-phy);
+ if (IS_ERR(hcd-gen_phy)) {
+ ret = PTR_ERR(hcd-gen_phy);
+ if (ret != -ENOSYS ret != -ENODEV)
+ dev_warn(pdev-dev,
+ Error retrieving usb2 phy: %d\n, ret);
+ }
should you treat -EPROBE_DEFER differently here ?
--
balbi
signature.asc
Description: Digital signature
[PATCH 0/4] spi: s3c64xx: fix DT binding breakage
Hello Mark, The s3c64xx SPI driver DT binding is currently broken. Commit 3146bee (spi: s3c64xx: Added provision for dedicated cs pin) added a new cs-gpio property and made it a requirement in order to make the driver behave in the same way that it used to. The motivation of the offending commit was to allow boards that want to use the native chip select (instead of a GPIO) to work with the s3c64xx SPI driver. Something that was not possible before since the driver made it mandatory to specify a GPIO. Unfortunately the commit also changed the driver defaults since now besides specifying a GPIO, it makes mandatory to also specify that a GPIO is used while the default used to be the opposite. That mean that old FDT are not working anymore after 3146bee so DT backward compatibility was not ensured by that commit. This is a follow-up series from a previous one posted by Naveen Krishna [0] which attempts to solve the issue. The feedback from Naveen's series was that the patches did not provide a clear explanation about the rationale and goal of both the series as a whole and the individual changes [1]. So I tried to take Navee's series and rework them to provide an easier to understand patch series. The series is composed of the following patches: Javier Martinez Canillas (1): Revert spi: s3c64xx: Added provision for dedicated cs pin Naveen Krishna Chatradhi (3): spi: s3c64xx: use the generic SPI cs-gpios property spi: samsung: Update binding documentation ARM: DTS: fix the chip select gpios definition in the SPI nodes .../devicetree/bindings/spi/spi-samsung.txt| 8 ++-- arch/arm/boot/dts/exynos4210-smdkv310.dts | 2 +- arch/arm/boot/dts/exynos4412-trats2.dts| 2 +- arch/arm/boot/dts/exynos5250-smdk5250.dts | 2 +- drivers/spi/spi-s3c64xx.c | 54 ++ 5 files changed, 30 insertions(+), 38 deletions(-) Patch 01/04 reverts the offending commit since it not only broke the DT binding but also introduced a confusing cs-gpio property while the driver already used a property with the same name. Patch 02/04 fixes the DT binding for good by using the SPI core cs-gpios property to specify the chip select GPIO instead of using a custom property only used by this driver. This change breaks backward compatibility but this has been broken for more than a year and nobody complained so I think it's safe to change it again in favor of using standard DT binding properties. A benefit of Patch 02/04 is that it allows DT and legacy boards that need to use the built-in CS instead of a GPIO to work with the driver which was the original motivation of the broken commit. Patch 03/04 updates the driver binding documentation accordingly and patch 04/04 updates all the DTS board files in mainline. Best regards, Javier [0]: http://www.spinics.net/lists/linux-samsung-soc/msg34163.html [1]: http://www.spinics.net/lists/linux-samsung-soc/msg34309.html -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/4] spi: samsung: Update binding documentation
From: Naveen Krishna Chatradhi ch.nav...@samsung.com
Samsung SPI driver now uses the generic SPI cs-gpios
binding so update the documentation accordingly.
Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
[javier.marti...@collabora.co.uk: split changes and improve commit message]
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
Reviewed-by: Tomasz Figa t.f...@samsung.com
---
Documentation/devicetree/bindings/spi/spi-samsung.txt | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/Documentation/devicetree/bindings/spi/spi-samsung.txt
b/Documentation/devicetree/bindings/spi/spi-samsung.txt
index 7f2d88d..1e8a857 100644
--- a/Documentation/devicetree/bindings/spi/spi-samsung.txt
+++ b/Documentation/devicetree/bindings/spi/spi-samsung.txt
@@ -38,15 +38,13 @@ Optional Board Specific Properties:
- num-cs: Specifies the number of chip select lines supported. If
not specified, the default number of chip select lines is set to 1.
+- cs-gpios: should specify GPIOs used for chipselects (see spi-bus.txt)
+
SPI Controller specific data in SPI slave nodes:
- The spi slave nodes should provide the following information which is
required
by the spi controller.
- - cs-gpio: A gpio specifier that specifies the gpio line used as
-the slave select line by the spi controller. The format of the gpio
-specifier depends on the gpio controller.
-
- samsung,spi-feedback-delay: The sampling phase shift to be applied on the
miso line (to account for any lag in the miso line). The following are the
valid values.
@@ -84,6 +82,7 @@ Example:
#size-cells = 0;
pinctrl-names = default;
pinctrl-0 = spi0_bus;
+ cs-gpios = gpa2 5 0;
w25q80bw@0 {
#address-cells = 1;
@@ -93,7 +92,6 @@ Example:
spi-max-frequency = 1;
controller-data {
- cs-gpio = gpa2 5 1 0 3;
samsung,spi-feedback-delay = 0;
};
--
2.0.0.rc2
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] Revert spi: s3c64xx: Added provision for dedicated cs pin
This reverts commit 3146beec21b64f4551fcf0ac148381d54dc41b1b.
This commit resulted in a DT backward compatibility breakage.
Some devices use the native chip select (CS) instead of a GPIO
pin to drive the CS line. But the SPI driver made it mandatory
to specify a GPIO pin in the SPI device node controller-data.
So, using the built-in CS was not possible with the driver.
Commit 3146bee tried to fix that by adding a cs-gpio property
which could be defined in the SPI device node to make the driver
request the GPIO from the controller-data node.
Unfortunately that changed the old DT binding semantics since
now it's mandatory to have the cs-gpio property defined in
the SPI device node in order to use a GPIO pin to drive the CS.
As an example, a SPI device was defined before the commit with:
spi@12d2 {
slave-node@0 {
controller-data {
cs-gpio = gpb1 2 0;
}
}
}
and after the commit, the following DTS snippet must be used:
spi@12d2 {
cs-gpio;
slave-node@0 {
controller-data {
cs-gpio = gpb1 2 0;
}
}
}
So, after commit 3146bee the driver does not look for the GPIO
by default and it only looks for it if the top level cs-gpio
property is defined while the default used to be the opposite.
To always request the GPIO defined in the controller-data node.
This means that old FDT that of course didn't have this added
cs-gpio DT property in the SPI node broke after this change.
The offending commit can't be reverted cleanly since more than
a year have passed and other changes were made in the meantime
but this patch partially reverts the driver to it's original
state so old FDT can work again.
This patch will break Device Trees that were relying on the new
behavior of course but the patch should be reverted because:
a) There aren't DTS in mainline that use this new property.
b) They were relying on a behavior that broke DT compatibility.
c) The new binding is awkard, needing two properties with the
same name (cs-gpio) on different nodes is confusing at least.
d) The new property was not added to the DT binding doc:
Documentation/devicetree/bindings/spi/spi-samsung.txt
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
Reviewed-by: Tomasz Figa t.f...@samsung.com
---
drivers/spi/spi-s3c64xx.c | 37 +++--
1 file changed, 11 insertions(+), 26 deletions(-)
diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
index a771a3a..e48c6fa 100644
--- a/drivers/spi/spi-s3c64xx.c
+++ b/drivers/spi/spi-s3c64xx.c
@@ -197,7 +197,6 @@ struct s3c64xx_spi_driver_data {
struct s3c64xx_spi_dma_data tx_dma;
struct s3c64xx_spi_port_config *port_conf;
unsigned intport_id;
- boolcs_gpio;
};
static void flush_fifo(struct s3c64xx_spi_driver_data *sdd)
@@ -754,10 +753,8 @@ static struct s3c64xx_spi_csinfo
*s3c64xx_get_slave_ctrldata(
{
struct s3c64xx_spi_csinfo *cs;
struct device_node *slave_np, *data_np = NULL;
- struct s3c64xx_spi_driver_data *sdd;
u32 fb_delay = 0;
- sdd = spi_master_get_devdata(spi-master);
slave_np = spi-dev.of_node;
if (!slave_np) {
dev_err(spi-dev, device node not found\n);
@@ -776,10 +773,7 @@ static struct s3c64xx_spi_csinfo
*s3c64xx_get_slave_ctrldata(
return ERR_PTR(-ENOMEM);
}
- /* The CS line is asserted/deasserted by the gpio pin */
- if (sdd-cs_gpio)
- cs-line = of_get_named_gpio(data_np, cs-gpio, 0);
-
+ cs-line = of_get_named_gpio(data_np, cs-gpio, 0);
if (!gpio_is_valid(cs-line)) {
dev_err(spi-dev, chip select gpio is not specified or
invalid\n);
kfree(cs);
@@ -818,20 +812,17 @@ static int s3c64xx_spi_setup(struct spi_device *spi)
}
if (!spi_get_ctldata(spi)) {
- /* Request gpio only if cs line is asserted by gpio pins */
- if (sdd-cs_gpio) {
- err = gpio_request_one(cs-line, GPIOF_OUT_INIT_HIGH,
- dev_name(spi-dev));
- if (err) {
- dev_err(spi-dev,
- Failed to get /CS gpio [%d]: %d\n,
- cs-line, err);
- goto err_gpio_req;
- }
-
- spi-cs_gpio = cs-line;
+ err = gpio_request_one(cs-line, GPIOF_OUT_INIT_HIGH,
+ dev_name(spi-dev));
+ if (err) {
+ dev_err(spi-dev,
+ Failed to get /CS gpio [%d]: %d\n,
+ cs-line, err);
+ goto err_gpio_req;
}
+ spi-cs_gpio = cs-line;
+
spi_set_ctldata(spi,
[PATCH 2/4] spi: s3c64xx: use the generic SPI cs-gpios property
From: Naveen Krishna Chatradhi ch.nav...@samsung.com
The s3c64xx SPI driver uses a custom DT binding to specify
the GPIO used to drive the chip select (CS) line instead of
using the generic cs-gpios property already defined in:
Documentation/devicetree/bindings/spi/spi-bus.txt.
It's unfortunate that drivers are not using standard bindings
and creating custom ones instead but in most cases this can't
be changed without breaking Device Tree backward compatibility.
But in the case of this driver, its DT binding has been broken
for more than a year. Since after commit (dated June, 21 2013):
3146bee (spi: s3c64xx: Added provision for dedicated cs pin)
DT backward compatibility was broken and nobody noticed until
now when the commit was reverted. So it seems to be safe to
change the binding to use the standard SPI cs-gpios property
instead of using a custom one just for this driver.
This patch also allows boards that don't use a GPIO pin for the
CS to work with the driver since the SPI core will take care of
setting spi-cs_gpio to -ENOENT if a board wants to use the built
in CS instead of a GPIO as explained in the SPI bus DT binding:
Documentation/devicetree/bindings/spi/spi-bus.txt.
For non-DT platforms, spi-cs_gpio will be set to -ENOENT as well
unless they specify a GPIO pin in their platform data. So both
native and GPIO chip select is also supported for legacy boards.
The above use case was what motivated commit 3146bee which broke
the DT binding backward compatibility in the first place.
Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
[javier.marti...@collabora.co.uk: split changes and improve commit message]
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
Reviewed-by: Tomasz Figa t.f...@samsung.com
---
drivers/spi/spi-s3c64xx.c | 49 ---
1 file changed, 29 insertions(+), 20 deletions(-)
diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
index e48c6fa..480133e 100644
--- a/drivers/spi/spi-s3c64xx.c
+++ b/drivers/spi/spi-s3c64xx.c
@@ -773,14 +773,6 @@ static struct s3c64xx_spi_csinfo
*s3c64xx_get_slave_ctrldata(
return ERR_PTR(-ENOMEM);
}
- cs-line = of_get_named_gpio(data_np, cs-gpio, 0);
- if (!gpio_is_valid(cs-line)) {
- dev_err(spi-dev, chip select gpio is not specified or
invalid\n);
- kfree(cs);
- of_node_put(data_np);
- return ERR_PTR(-EINVAL);
- }
-
of_property_read_u32(data_np, samsung,spi-feedback-delay, fb_delay);
cs-fb_delay = fb_delay;
of_node_put(data_np);
@@ -801,9 +793,16 @@ static int s3c64xx_spi_setup(struct spi_device *spi)
int err;
sdd = spi_master_get_devdata(spi-master);
- if (!cs spi-dev.of_node) {
+ if (spi-dev.of_node) {
cs = s3c64xx_get_slave_ctrldata(spi);
spi-controller_data = cs;
+ } else if (cs) {
+ /* On non-DT platforms the SPI core will set spi-cs_gpio
+* to -ENOENT. The GPIO pin used to drive the chip select
+* is defined by using platform data so spi-cs_gpio value
+* has to be override to have the proper GPIO pin number.
+*/
+ spi-cs_gpio = cs-line;
}
if (IS_ERR_OR_NULL(cs)) {
@@ -812,17 +811,17 @@ static int s3c64xx_spi_setup(struct spi_device *spi)
}
if (!spi_get_ctldata(spi)) {
- err = gpio_request_one(cs-line, GPIOF_OUT_INIT_HIGH,
- dev_name(spi-dev));
- if (err) {
- dev_err(spi-dev,
- Failed to get /CS gpio [%d]: %d\n,
- cs-line, err);
- goto err_gpio_req;
+ if (gpio_is_valid(spi-cs_gpio)) {
+ err = gpio_request_one(spi-cs_gpio,
GPIOF_OUT_INIT_HIGH,
+ dev_name(spi-dev));
+ if (err) {
+ dev_err(spi-dev,
+ Failed to get /CS gpio [%d]: %d\n,
+ spi-cs_gpio, err);
+ goto err_gpio_req;
+ }
}
- spi-cs_gpio = cs-line;
-
spi_set_ctldata(spi, cs);
}
@@ -875,7 +874,8 @@ setup_exit:
/* setup() returns with device de-selected */
writel(S3C64XX_SPI_SLAVE_SIG_INACT, sdd-regs + S3C64XX_SPI_SLAVE_SEL);
- gpio_free(cs-line);
+ if (gpio_is_valid(spi-cs_gpio))
+ gpio_free(spi-cs_gpio);
spi_set_ctldata(spi, NULL);
err_gpio_req:
@@ -889,11 +889,20 @@ static void s3c64xx_spi_cleanup(struct spi_device *spi)
{
struct s3c64xx_spi_csinfo *cs = spi_get_ctldata(spi);
- if (cs) {
+ if (gpio_is_valid(spi-cs_gpio)) {
Re: [PATCH 0/4] spi: s3c64xx: fix DT binding breakage
Hello Javier, On 16 July 2014 20:49, Javier Martinez Canillas javier.marti...@collabora.co.uk wrote: Hello Mark, The s3c64xx SPI driver DT binding is currently broken. Commit 3146bee (spi: s3c64xx: Added provision for dedicated cs pin) added a new cs-gpio property and made it a requirement in order to make the driver behave in the same way that it used to. The motivation of the offending commit was to allow boards that want to use the native chip select (instead of a GPIO) to work with the s3c64xx SPI driver. Something that was not possible before since the driver made it mandatory to specify a GPIO. Unfortunately the commit also changed the driver defaults since now besides specifying a GPIO, it makes mandatory to also specify that a GPIO is used while the default used to be the opposite. That mean that old FDT are not working anymore after 3146bee so DT backward compatibility was not ensured by that commit. This is a follow-up series from a previous one posted by Naveen Krishna [0] which attempts to solve the issue. The feedback from Naveen's series was that the patches did not provide a clear explanation about the rationale and goal of both the series as a whole and the individual changes [1]. So I tried to take Navee's series and rework them to provide an easier to understand patch series. The series is composed of the following patches: Javier Martinez Canillas (1): Revert spi: s3c64xx: Added provision for dedicated cs pin Naveen Krishna Chatradhi (3): spi: s3c64xx: use the generic SPI cs-gpios property spi: samsung: Update binding documentation ARM: DTS: fix the chip select gpios definition in the SPI nodes I should have mentioned what was the issue being fixed. Your explanation is very clear. I'm working on getting the terminology correct. Thank you. .../devicetree/bindings/spi/spi-samsung.txt| 8 ++-- arch/arm/boot/dts/exynos4210-smdkv310.dts | 2 +- arch/arm/boot/dts/exynos4412-trats2.dts| 2 +- arch/arm/boot/dts/exynos5250-smdk5250.dts | 2 +- drivers/spi/spi-s3c64xx.c | 54 ++ 5 files changed, 30 insertions(+), 38 deletions(-) Patch 01/04 reverts the offending commit since it not only broke the DT binding but also introduced a confusing cs-gpio property while the driver already used a property with the same name. Patch 02/04 fixes the DT binding for good by using the SPI core cs-gpios property to specify the chip select GPIO instead of using a custom property only used by this driver. This change breaks backward compatibility but this has been broken for more than a year and nobody complained so I think it's safe to change it again in favor of using standard DT binding properties. A benefit of Patch 02/04 is that it allows DT and legacy boards that need to use the built-in CS instead of a GPIO to work with the driver which was the original motivation of the broken commit. Patch 03/04 updates the driver binding documentation accordingly and patch 04/04 updates all the DTS board files in mainline. Best regards, Javier [0]: http://www.spinics.net/lists/linux-samsung-soc/msg34163.html [1]: http://www.spinics.net/lists/linux-samsung-soc/msg34309.html -- To unsubscribe from this list: send the line unsubscribe linux-spi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Shine bright, (: Nav :) -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] spi: s3c64xx: fix DT binding breakage
On 07/16/2014 06:02 PM, Mark Brown wrote: On Wed, Jul 16, 2014 at 05:19:06PM +0200, Javier Martinez Canillas wrote: *sigh* Yesterday Naveen submitted another, different, patch series also attempting to improve things which I'm not seeing any reference to here. Please coordinate with Naveen about what you are doing. Yes, I answered Naveen on his latest series and told him that I thought his v6 was better and also that the commit messages where still not clearly explaining the motivation for the changes [0]. So after that I asked him in private if he wouldn't mind if I try to rework his series to make it easier to understand and he agreed on that. I should had mentioned it the cover later, sorry about that. Please take a look to this series instead of the latest that was posted by Naveen. Thanks a lot and best regards, Javier [0]: https://www.mail-archive.com/devicetree@vger.kernel.org/msg34860.html -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] i2c: exynos5: Properly use the noirq variants of suspend/resume
On Wed, Jun 25, 2014 at 09:39:20AM -0700, Doug Anderson wrote: The original code for the exynos i2c controller registered for the noirq variants. However during review feedback it was moved to SIMPLE_DEV_PM_OPS without anyone noticing that it meant we were no longer actually noirq (despite functions named exynos5_i2c_suspend_noirq and exynos5_i2c_resume_noirq). i2c controllers that might have wakeup sources on them seem to need to resume at noirq time so that the individual drivers can actually read the i2c bus to handle their wakeup. NOTE: I took the original review feedback from Wolfram and added poweroff, thaw, freeze, restore. This patch has only been compile-tested since I don't have all the patches needed to make my machine using this i2c driver actually suspend/resume. Signed-off-by: Doug Anderson diand...@chromium.org Acked-by: Kukjin Kim kgene@samsung.com Applied to for-next, thanks! signature.asc Description: Digital signature
Re: [PATCH] Exynos4: cpuidle: support dual CPUs with AFTR state
Hi, On Friday, May 30, 2014 03:53:09 PM Bartlomiej Zolnierkiewicz wrote: Hi, On Friday, May 30, 2014 01:34:45 PM Tomasz Figa wrote: Hi Daniel, On 30.05.2014 11:30, Daniel Lezcano wrote: On 04/24/2014 07:42 PM, Tomasz Figa wrote: Hi Daniel, Please see my comments inline. Btw. Please fix your e-mail composer to properly wrap your messages around 7xth column, as otherwise they're hard to read. On 04.04.2014 11:48, Daniel Lezcano wrote: 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. 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 ++ [ ... ] Otherwise, I quite like the whole idea. I need to play a bit with CPU hotplug and PMU to verify that things couldn't really be simplified a bit, but in general this looks reasonably. Hi Tomasz, did you have time to look at this simplification ? Unfortunately I got preempted with other things to do and now I'm on vacation. I worked a bit with Bart (added on CC) on this and generally the conclusion was that all the things are necessary. He was also working to extend the driver to support Exynos4x12. Bart, has anything interesting showed up since we talked about this last time? Since we last looked into this I have fixed the standard AFTR support for Exynos3250 and started to work on adding Exynos3250 support to this driver (as Exynos3250 support has bigger priority than Exynos4x12 one). Unfortunately I also got preempted with other things so it is still unfinished and doesn't work yet. Moreover I had no possibility to test the new driver on Exynos4210 based Origen yet (I hope to do this next week). I have tested this patch on Origen board (Exynos4210 rev 1.1) and it causes system lockup (it seems that the code gets stuck on waiting for CPU1 to wake up). The kernels I have tried: * current -next + this patch + few fixes to bring it up to date * commit cd245f5 + this patch + some fixes * next-20140403 + your Exynos cpuidle patch series + this patch I have also tried with S5P_VA_SYSRAM replaced by S5P_INFORM5 to match Exynos 4210 rev 1.1 but it didn't help. U-Boot version used is: U-Boot 2012.07 (Sep 22 2012 - 05:12:41) for ORIGEN Could you please tell me which hardware/bootloader/kernel exactly have you used to test this patch? Also could you please port/retest your patch over the current -next? Best regards, -- Bartlomiej Zolnierkiewicz Samsung RD Institute Poland Samsung Electronics -- To unsubscribe from this list: send the line unsubscribe linux-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] i2c: s3c2410: resume the I2C controller earlier
On Tue, Jun 24, 2014 at 04:56:54PM -0700, Doug Anderson wrote: From: Vincent Palatin vpala...@chromium.org When the wake-up is triggered by the PMIC RTC, the RTC driver is trying to read the PMIC interrupt status over I2C and fails because the I2C controller is not resumed yet. Let's resume the I2C controller earlier in the _noirq phase (as other hardwares are doing), so we can properly get the wake-up condition. Signed-off-by: Vincent Palatin vpala...@chromium.org Signed-off-by: Doug Anderson diand...@chromium.org Applied to for-current (because Tomasz said it fixes issues), thanks! If you think the exynos patch of the same style should also be in current, please let me know... signature.asc Description: Digital signature
Re: [PATCH 1/1] i2c: Kconfig: Enable HSI2C for Exynos5 platform
On Wed, Jun 25, 2014 at 10:55:31AM -0700, Doug Anderson wrote: Sachin, On Wed, Jun 25, 2014 at 3:02 AM, Sachin Kamat sachin.ka...@samsung.com wrote: All Exynos5 platforms have HSI2C controllers and are needed by various IPs connected to the boards based on these SoCs. Thus select this by default for Exynos5 platforms. Signed-off-by: Sachin Kamat sachin.ka...@samsung.com Cc: Doug Anderson diand...@chromium.org --- drivers/i2c/busses/Kconfig |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig index 9f7d5859cf65..c7918cffe790 100644 --- a/drivers/i2c/busses/Kconfig +++ b/drivers/i2c/busses/Kconfig @@ -465,9 +465,9 @@ config I2C_EG20T config I2C_EXYNOS5 tristate Exynos5 high-speed I2C driver depends on ARCH_EXYNOS5 OF + default y help - Say Y here to include support for high-speed I2C controller in the - Exynos5 based Samsung SoCs. + High-speed I2C controller on Exynos5 based Samsung SoCs. config I2C_GPIO tristate GPIO-based bitbanging I2C -- 1.7.9.5 This seems reasonable to me and I will also take the blame for suggesting this. It's hard to imagine running a real exynos5 system without I2C. One could argue that on an exynos5250 the high speed I2C controller is not mandatory (since all the ports can be muxed to use the old controller) but on newer exynos5 products you're expected to have the main PMIC on one of the i2c ports. An exynos system without access to its PMIC will just sorta limp by. ...but I've added Arnd to this thread as he expressed some reservations about this type of thing, so we'll see what he says. Ping. Arnd? I have no strong opinion and would take this patch... Reviewed-by: Doug Anderson diand...@chromium.org signature.asc Description: Digital signature
Re: [PATCH v2] i2c: s3c2410: resume the I2C controller earlier
Wolfram, On Wed, Jul 16, 2014 at 10:35 AM, Wolfram Sang w...@the-dreams.de wrote: On Tue, Jun 24, 2014 at 04:56:54PM -0700, Doug Anderson wrote: From: Vincent Palatin vpala...@chromium.org When the wake-up is triggered by the PMIC RTC, the RTC driver is trying to read the PMIC interrupt status over I2C and fails because the I2C controller is not resumed yet. Let's resume the I2C controller earlier in the _noirq phase (as other hardwares are doing), so we can properly get the wake-up condition. Signed-off-by: Vincent Palatin vpala...@chromium.org Signed-off-by: Doug Anderson diand...@chromium.org Applied to for-current (because Tomasz said it fixes issues), thanks! If you think the exynos patch of the same style should also be in current, please let me know... Thanks! I don't think the exynos one needs to go into for-current. for-next is enough. :) -Doug -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 05/14] drm/exynos: dsi: add pass TE host ops to support LCD I80 interface
On 2014년 07월 16일 19:12, YoungJun Cho wrote: Hi Thierry, On 07/16/2014 04:54 PM, Thierry Reding wrote: On Wed, Jul 16, 2014 at 11:23:09AM +0900, YoungJun Cho wrote: Hi Inki, On 07/15/2014 11:34 AM, Inki Dae wrote: On 2014년 07월 14일 20:03, Thierry Reding wrote: On Mon, Jul 14, 2014 at 07:45:28PM +0900, YoungJun Cho wrote: On 07/14/2014 06:41 PM, Thierry Reding wrote: [...] That said, I've been doing some research and it seems like we have a somewhat similar feature on Tegra. What happens there is that there are three GPIO pins that can be repurposed for TE signalling. But as opposed to using them as interrupts the display controller can be configured to use them, upon which it will automatically handle the TE signal by sending the next frame. Could you explain more detail how the Tegra display controller could be configured with this GPIO pins? I have no idea except that the display controller registers this GPIO as an IRQ. On Tegra the display controller has a special register that can be programmed to use one of the three GPIOs as TE signal. Then the display controller can be configured in one-shot (non-continuous) mode, which means that software needs to explicitly set a trigger bit to tell the display controller to send a new frame. If TE signalling is enabled, then the display controller will not immediately send a new frame when triggered but wait for signalling of this GPIO. So we have at least two very different implementations of this on two different SoCs. Further the specification explicitly recommends using the BTA sequence and DSI protocol to wait for TE. So I still think that controllers that provide an additional, non-spec compliant method to signal TE should handle it separately rather than within DSI. Otherwise we essentially need to make the DSI core aware of all these quirks, and I'd rather avoid that. You mean, the DSI specification guides to use BTA, so it's better to use display controller rather than DSIM, right? What I'm saying is that there's nothing about a side-band TE wire in the DSI spec. In fact the spec explicitly says that this mechanism of an external TE wire from older protocols (DBI) was replaced by the BTA sequence over the protocol. Now, my understanding is that using the BTA sequence over the DSI protocol would introduce some latency and that forces some panel vendors to still provide a side-band TE wire even in DSI compliant panels. But since this is not part of the specification there is no standard way to do this (as evidenced by Tegra and Exynos). Therefore putting such functionality into the core DSI code is bad. But that doesn't mean that you have to put this functionality into the display controller driver on Exynos. What I'm saying is that it should be handled by the SoC driver rather than the core. Where exactly probably depends on the particular case. As Inki commented before, I'll try to use remote-endpoint property of DSI device node in exynos DSIM driver and call FIMD notifier. Sounds like it matches what I said above. I'm not a huge fan of notifiers, but if it works for you I suppose that's fine. The alternative would be to directly call a FIMD function, which is somewhat more explicit than a notifier. Yes, I also like explicit call, so I want to use dsi_host_ops and calls it in panel. But there is an objection to use dis_host_ops, we think notifier in exynos dsim for fimd(display controller). There are other ways to explicitly call into the display controller. You could for example get access to the CRTC that DSIM is currently connected to (via exynos_dsi.encoder-crtc) and then cast that to a struct exynos_drm_crtc and call a function to trigger a new frame to be sent (for example exynos_drm_crtc_send_frame()). This assumes that you can safely cast struct drm_crtc * to struct exynos_drm_crtc *, but that shouldn't be a problem. With the above, you could make the DSIM handle the TE signal interrupts and trigger the DC using the new exynos_drm_crtc_send_frame() function. It seems better than the use of notifier. Actually, original patch used this way except TE event. Mr. Cho, let's use remote-endpoint property and this way instead of notifier. The struct exynos_dsi has panel_node, which is valid by exynos_dsi_host_attach() is called from panel, we could use it instead of getting new remote-endpoint node. So after called exynos_dsi_host_attach(), the dsi driver could know that the panel supports mipi command mode or video mode, and if the panel is for mipi command mode one, dsi driver gets panel te gpio and registers its irq. Why does the TE GPIO even need to be in the panel's device tree node? Wouldn't it make more sense for it to be in the DSIM node? After all that's what the GPIO is connected to, right? Well, at least logically if not physically. I also agree that the GPIO in DT means the connection after all. But the panel
Re: [PATCH v7 0/6] cpufreq: use generic cpufreq drivers for exynos platforms
Hi Mike, On Tue, Jul 15, 2014 at 9:20 AM, Thomas Abraham ta.oma...@gmail.com wrote: Hi Tomasz, On Mon, Jul 14, 2014 at 7:08 PM, Thomas Abraham thomas...@samsung.com wrote: Changes since v6: - Fixes suggested by Amit Daniel amit.dan...@samsung.com. This patch series removes the use of Exynos4210 and Exynos5250 specific cpufreq drivers and enables the use of cpufreq-cpu0 driver for these platforms. This series also enabled cpufreq support for Exynos5420 using arm_big_little cpufreq driver. Thomas Abraham (6): clk: samsung: add infrastructure to register cpu clocks clk: samsung: register exynos5420 apll/kpll configuration data clk: exynos: use cpu-clock provider type to represent arm clock ARM: dts: Exynos: add cpu nodes, opp and cpu clock configuration data ARM: Exynos: switch to using generic cpufreq driver for exynos4210/5250 cpufreq: exynos: remove exynos4210/5250 specific cpufreq driver support In this series, support for Exynos5420 has been included. If there are any more changes required, could you please let me know. This patch series migrates exynos cpufreq support to use generic cpufreq drivers. For this, cpu clock blocks are encapsulated into a cpu clock type and cpufreq driver operates the cpu clock type. We had discussed in the [1] about using coordinated clocks. This series is not using the concept of coordinated clocks but the code in this series can be migrated to use coordinated clocks when it is available. Is it okay to consider this series for v3.17-rc1. I will update this code to use coordinated clocks when it is available. This series helps with cpufreq support for newer Exynos SoCs such as Exynos5420/3250. [1] http://www.spinics.net/lists/cpufreq/msg10042.html Thanks, Thomas Thanks, Thomas. arch/arm/boot/dts/exynos4210-origen.dts |6 + arch/arm/boot/dts/exynos4210-trats.dts |6 + arch/arm/boot/dts/exynos4210-universal_c210.dts |6 + arch/arm/boot/dts/exynos4210.dtsi | 27 ++ arch/arm/boot/dts/exynos5250-arndale.dts|6 + arch/arm/boot/dts/exynos5250-cros-common.dtsi |6 + arch/arm/boot/dts/exynos5250-smdk5250.dts |6 + arch/arm/boot/dts/exynos5250.dtsi | 23 + arch/arm/boot/dts/exynos5420-smdk5420.dts |6 + arch/arm/boot/dts/exynos5420.dtsi | 32 ++ arch/arm/mach-exynos/exynos.c | 15 +- drivers/clk/samsung/Makefile|2 +- drivers/clk/samsung/clk-cpu.c | 576 +++ drivers/clk/samsung/clk-exynos4.c | 25 +- drivers/clk/samsung/clk-exynos5250.c| 16 +- drivers/clk/samsung/clk-exynos5420.c| 60 ++- drivers/clk/samsung/clk.h |5 + drivers/cpufreq/Kconfig.arm | 22 - drivers/cpufreq/Makefile|2 - drivers/cpufreq/exynos4210-cpufreq.c| 184 drivers/cpufreq/exynos5250-cpufreq.c| 210 - include/dt-bindings/clock/exynos5250.h |1 + include/dt-bindings/clock/exynos5420.h |2 + 23 files changed, 802 insertions(+), 442 deletions(-) create mode 100644 drivers/clk/samsung/clk-cpu.c delete mode 100644 drivers/cpufreq/exynos4210-cpufreq.c delete mode 100644 drivers/cpufreq/exynos5250-cpufreq.c -- 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
