Re: [PATCH v4 00/14] ARM: samsung-time: Prepare for multiplatform support
On Thursday 04 of April 2013 18:36:57 Tomasz Figa wrote: > This series is an attempt to make the samsung-time clocksource driver > ready for multiplatform kernels. It moves the driver to > drivers/clocksource, cleans it up from uses of static platform-specific > definitions, simplifies timer interrupt handling and adds Device Tree > support. > > Only samsung-time driver is reworked to use the master driver at this > time, since the PWM driver can be already considered broken at the > moment and needs separate series of several patches to fix and clean it > up, which I am already working on. > > Tested on Universal C210 board with Device Tree. Not tested without > Device Tree, since it has been already broken before this series. > Compile tested for other related SoCs. > > Changes since v3: > (http://thread.gmane.org/gmane.linux.kernel.samsung-soc/16664/) > - Changed the design to use common (master) driver for operations that >can be done from both clocksource and PWM drivers (as suggested by >Arnd Bergmann) - needed to properly synchronize access to PWM > registers - Moved handling of PWM prescaler and divider to master > driver > > Changes since v2: > (http://thread.gmane.org/gmane.linux.kernel.samsung-soc/16158) > - Addressed comments from Rob Herring and Mark Rutland > - Removed unused register definitions > - Replaced samsung,source-timer and samsung,event-timer properties >with samsung,pwm-outputs property that defines which PWM channels >are reserved for PWM outputs on particular platform > - Split non-DT and DT initialization into two functions > - Fixed a copy paste error > > Changes since v1: > (http://thread.gmane.org/gmane.linux.kernel.samsung-soc/16005) > - Addressed comments from Mark Rutland > - Documented struct samsung_timer_variant > - Dropped inactive mail addresses from CC > > Tomasz Figa (14): > ARM: SAMSUNG: Move samsung-time to drivers/clocksource > clocksource: samsung-time: Drop useless defines from public header > clocksource: samsung-time: Use local register definitions > mfd: Add Samsung PWM/timer master driver > ARM: SAMSUNG: Unify base address definitions of timer block > ARM: SAMSUNG: Add new PWM platform device > ARM: SAMSUNG: Set PWM platform data > clocksource: samsung-time: Use Samsung PWM/timer master driver > clocksource: samsung-time: Use variant data to get SoC-specific bits > clocksource: samsung-time: Use master driver to configure dividers > clocksource: samsung-time: Use clk_prepare_enable > clocksource: samsung-time: Use master driver to control PWM channels > clocksource: samsung-time: Move IRQ mask/ack handling to the driver > ARM: SAMSUNG: Remove unused PWM timer IRQ chip code On FriendlyARM's Tiny6410 board (Mini6410-compatible), both with (using my patches adding S3C64xx Device Tree and pinctrl support) and without Device Tree: Tested-by: Tomasz Figa 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 04/14] mfd: Add Samsung PWM/timer master driver
On Friday 05 of April 2013 21:54:21 Arnd Bergmann wrote: > On Friday 05 April 2013, Tomasz Figa wrote: > > > I don't think anyone ever suggested using a private API though. > > > > I must have gotten the last paragraph of > > http://article.gmane.org/gmane.linux.kernel.samsung-soc/16638 > > wrong then. For me it seemed like the timer driver would expose a > > private API to the PWM driver. > > Yes, sorry I wasn't clear enough. I meant a register-level interface > exposed from the base driver, not a high-level interface like you > did. I'm not sure what you mean by a register-level interface. Something like samsung_pwm_update_reg(reg, mask, val), which modifies bitfields according to the mask and value with appropriate synchronization? If yes, this solves only the problem of access to shared registers. The other problems that remain: - negotiation of PWM channels to use for clock source and clock events, because each board can use different channels for PWM outputs, - code duplication caused by both of the drivers doing mostly the same things and or having to parse the same data from device tree, - both non-DT and DT platforms must be supported, - how to keep the ability to load PWM driver as a module (or not load it at all when PWM is not used on particular board), while retaining everything that is needed for the clocksource driver in kernel, - some platforms can't use PWM timers as system clocksources, while on others this is the only timekeeping hardware available. > > > I think > > > it's ok if the driver lives in drivers/mfd when it doesn't fit > > > anywhere > > > else easily, but you should really register it to the pwm subsystem > > > to > > > expose that functionality, not export functions that can be used by > > > a pwm shim driver, which even seems to be missing from the series. > > > > Anyway, using PWM API in a clocksource driver that needs to be running > > very early (before any initcalls get called) seems a bit weird for > > me, especially when PWM API doesn't provide such fine grained control > > over PWM timers that is required in the clocksource drivers. > > Exactly, that's why you should have a regular PWM driver that gets > loaded at a convenient time and just uses an interface exported by the > base driver to access the common registers. Well, this is basically what my patches do, except that the PWM driver isn't reworked to use the base driver yet. The private API exported to the samsung-time and pwm-samsung drivers isn't maybe the most fortunate one, but it clearly has the advantage of solving all the problems I mentioned before. Same goes for calling this an MFD driver. It doesn't even use the MFD core, but there seems to be no better place to put it. Maybe drivers/platform/arm would be better, if it existed, just as currently available drivers/platform/x86? 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 04/14] mfd: Add Samsung PWM/timer master driver
On Friday 05 April 2013, Tomasz Figa wrote: > > I don't think anyone ever suggested using a private API though. > > I must have gotten the last paragraph of > http://article.gmane.org/gmane.linux.kernel.samsung-soc/16638 > wrong then. For me it seemed like the timer driver would expose a private API > to the PWM driver. Yes, sorry I wasn't clear enough. I meant a register-level interface exposed from the base driver, not a high-level interface like you did. > > I think > > it's ok if the driver lives in drivers/mfd when it doesn't fit anywhere > > else easily, but you should really register it to the pwm subsystem to > > expose that functionality, not export functions that can be used by > > a pwm shim driver, which even seems to be missing from the series. > > Anyway, using PWM API in a clocksource driver that needs to be running very > early (before any initcalls get called) seems a bit weird for me, especially > when PWM API doesn't provide such fine grained control over PWM timers that > is > required in the clocksource drivers. Exactly, that's why you should have a regular PWM driver that gets loaded at a convenient time and just uses an interface exported by the base driver to access the common registers. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] clk: exynos4: export clocks required for fimc-is
Quoting Sylwester Nawrocki (2013-04-05 10:49:45)
> This patch adds clock indexes for ACLK_DIV0, ACLK_DIV1,
> ACLK_400_MCUISP, ACLK_MCUISP_DIV0, ACLK_MCUISP_DIV1,
> DIVACLK_400_MCUISP and DIVACLK_200 so these clocks are
> available to the consumers (Exynos4x12 FIMC-IS subsystem).
> While at it, indentation of the mux clocks table is
> corrected.
>
> Signed-off-by: Sylwester Nawrocki
> Signed-off-by: Kyungmin Park
Acked-by: Mike Turquette
> ---
> Rebased onto git://git.kernel.org/pub/scm/linux/kernel/git/
> kgene/linux-samsung.git for-next
>
> .../devicetree/bindings/clock/exynos4-clock.txt| 42
> +---
> drivers/clk/samsung/clk-exynos4.c | 20 ++
> 2 files changed, 41 insertions(+), 21 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/clock/exynos4-clock.txt
> b/Documentation/devicetree/bindings/clock/exynos4-clock.txt
> index 662007e..ea5e26f 100644
> --- a/Documentation/devicetree/bindings/clock/exynos4-clock.txt
> +++ b/Documentation/devicetree/bindings/clock/exynos4-clock.txt
> @@ -236,22 +236,36 @@ Exynos4 SoC and this is specified where applicable.
>spi1_isp_sclk 381 Exynos4x12
>uart_isp_sclk 382 Exynos4x12
>
> - [Mux Clocks]
> + [Mux Clocks]
>
> - Clock ID SoC (if specific)
> - ---
> + ClockID SoC (if specific)
> + ---
> +
> + mout_fimc0 384
> + mout_fimc1 385
> + mout_fimc2 386
> + mout_fimc3 387
> + mout_cam0388
> + mout_cam1389
> + mout_csis0 390
> + mout_csis1 391
> + mout_g3d0392
> + mout_g3d1393
> + mout_g3d 394
> + aclk400_mcuisp 395 Exynos4x12
> +
> + [Div Clocks]
> +
> + ClockID SoC (if specific)
> + ---
> +
> + div_isp0 450 Exynos4x12
> + div_isp1 451 Exynos4x12
> + div_mcuisp0 452 Exynos4x12
> + div_mcuisp1 453 Exynos4x12
> + div_aclk200 454 Exynos4x12
> + div_aclk400_mcuisp 455 Exynos4x12
>
> - mout_fimc0 384
> - mout_fimc1 385
> - mout_fimc2 386
> - mout_fimc3 387
> - mout_cam0 388
> - mout_cam1 389
> - mout_csis0 390
> - mout_csis1 391
> - mout_g3d0 392
> - mout_g3d1 393
> - mout_g3d394
>
> Example 1: An example of a clock controller node is listed below.
>
> diff --git a/drivers/clk/samsung/clk-exynos4.c
> b/drivers/clk/samsung/clk-exynos4.c
> index 17674da..7104669 100644
> --- a/drivers/clk/samsung/clk-exynos4.c
> +++ b/drivers/clk/samsung/clk-exynos4.c
> @@ -175,6 +175,11 @@ enum exynos4_clks {
> /* mux clocks */
> mout_fimc0 = 384, mout_fimc1, mout_fimc2, mout_fimc3, mout_cam0,
> mout_cam1, mout_csis0, mout_csis1, mout_g3d0, mout_g3d1, mout_g3d,
> + aclk400_mcuisp,
> +
> + /* div clocks */
> + div_isp0 = 450, div_isp1, div_mcuisp0, div_mcuisp1, div_aclk200,
> + div_aclk400_mcuisp,
>
> nr_clks,
> };
> @@ -429,7 +434,7 @@ struct samsung_mux_clock exynos4x12_mux_clks[] __initdata
> = {
> MUX(none, "mout_user_aclk266_gps", mout_user_aclk266_gps_p4x12,
> SRC_TOP1, 16, 1),
> MUX(aclk200, "aclk200", mout_user_aclk200_p4x12, SRC_TOP1, 20, 1),
> - MUX(none, "aclk400_mcuisp", mout_user_aclk400_mcuisp_p4x12,
> + MUX(aclk400_mcuisp, "aclk400_mcuisp", mout_user_aclk400_mcuisp_p4x12,
> SRC_TOP1, 24, 1),
> MUX(none, "mout_aclk200", aclk_p4412, SRC_TOP0, 12, 1),
> MUX(none, "mout_aclk100", aclk_p4412, SRC_TOP0, 16, 1),
> @@ -563,20 +568,21 @@ struct samsung_div_clock exynos4x12_div_clks[]
> __initdata = {
> DIV(none, "div_mdnie_pwm_pre0", "div_mdnie_pwm0", DIV_LCD0, 12, 4),
> DIV(none, "div_mipihsi", "mout_mipihsi", DIV_FSYS0, 20, 4),
> DIV(none, "div_jpeg", "mout_jpeg", E4X12_DIV_CAM1, 0, 4),
> - DIV(none, "div_aclk200", "mout_aclk200", DIV_TOP, 0, 3),
> + DIV(div_aclk200, "div_aclk200", "mout_aclk200", DIV_TOP, 0, 3),
> DIV(none, "div_aclk266_gps", "mout_aclk266_gps", DIV_TOP, 20, 3),
> - DIV(none, "div_aclk400_mcuisp", "mout_aclk400_mcuisp", DIV_TOP, 24,
> 3),
> + DIV(div_aclk400_mcuisp, "div_aclk400_mcuisp", "mout_aclk400_mcuisp",
> + DIV_TOP, 24, 3),
> DIV(none, "div_pwm_isp", "mout_pwm_isp", E4X12_DIV_ISP, 0, 4),
> DIV(none, "div_spi0_isp", "mout_spi0_isp", E4X12_DIV_ISP, 4, 4),
> DIV(none, "div_spi0_isp_pre", "div_spi0_isp", E4X12_DIV_ISP, 8, 8),
> DIV(none, "div_spi1_isp", "mout_spi1_isp",
[PATCH] clk: exynos4: export clocks required for fimc-is
This patch adds clock indexes for ACLK_DIV0, ACLK_DIV1,
ACLK_400_MCUISP, ACLK_MCUISP_DIV0, ACLK_MCUISP_DIV1,
DIVACLK_400_MCUISP and DIVACLK_200 so these clocks are
available to the consumers (Exynos4x12 FIMC-IS subsystem).
While at it, indentation of the mux clocks table is
corrected.
Signed-off-by: Sylwester Nawrocki
Signed-off-by: Kyungmin Park
---
Rebased onto git://git.kernel.org/pub/scm/linux/kernel/git/
kgene/linux-samsung.git for-next
.../devicetree/bindings/clock/exynos4-clock.txt| 42 +---
drivers/clk/samsung/clk-exynos4.c | 20 ++
2 files changed, 41 insertions(+), 21 deletions(-)
diff --git a/Documentation/devicetree/bindings/clock/exynos4-clock.txt
b/Documentation/devicetree/bindings/clock/exynos4-clock.txt
index 662007e..ea5e26f 100644
--- a/Documentation/devicetree/bindings/clock/exynos4-clock.txt
+++ b/Documentation/devicetree/bindings/clock/exynos4-clock.txt
@@ -236,22 +236,36 @@ Exynos4 SoC and this is specified where applicable.
spi1_isp_sclk 381 Exynos4x12
uart_isp_sclk 382 Exynos4x12
- [Mux Clocks]
+ [Mux Clocks]
- Clock ID SoC (if specific)
- ---
+ ClockID SoC (if specific)
+ ---
+
+ mout_fimc0 384
+ mout_fimc1 385
+ mout_fimc2 386
+ mout_fimc3 387
+ mout_cam0388
+ mout_cam1389
+ mout_csis0 390
+ mout_csis1 391
+ mout_g3d0392
+ mout_g3d1393
+ mout_g3d 394
+ aclk400_mcuisp 395 Exynos4x12
+
+ [Div Clocks]
+
+ ClockID SoC (if specific)
+ ---
+
+ div_isp0 450 Exynos4x12
+ div_isp1 451 Exynos4x12
+ div_mcuisp0 452 Exynos4x12
+ div_mcuisp1 453 Exynos4x12
+ div_aclk200 454 Exynos4x12
+ div_aclk400_mcuisp 455 Exynos4x12
- mout_fimc0 384
- mout_fimc1 385
- mout_fimc2 386
- mout_fimc3 387
- mout_cam0 388
- mout_cam1 389
- mout_csis0 390
- mout_csis1 391
- mout_g3d0 392
- mout_g3d1 393
- mout_g3d394
Example 1: An example of a clock controller node is listed below.
diff --git a/drivers/clk/samsung/clk-exynos4.c
b/drivers/clk/samsung/clk-exynos4.c
index 17674da..7104669 100644
--- a/drivers/clk/samsung/clk-exynos4.c
+++ b/drivers/clk/samsung/clk-exynos4.c
@@ -175,6 +175,11 @@ enum exynos4_clks {
/* mux clocks */
mout_fimc0 = 384, mout_fimc1, mout_fimc2, mout_fimc3, mout_cam0,
mout_cam1, mout_csis0, mout_csis1, mout_g3d0, mout_g3d1, mout_g3d,
+ aclk400_mcuisp,
+
+ /* div clocks */
+ div_isp0 = 450, div_isp1, div_mcuisp0, div_mcuisp1, div_aclk200,
+ div_aclk400_mcuisp,
nr_clks,
};
@@ -429,7 +434,7 @@ struct samsung_mux_clock exynos4x12_mux_clks[] __initdata =
{
MUX(none, "mout_user_aclk266_gps", mout_user_aclk266_gps_p4x12,
SRC_TOP1, 16, 1),
MUX(aclk200, "aclk200", mout_user_aclk200_p4x12, SRC_TOP1, 20, 1),
- MUX(none, "aclk400_mcuisp", mout_user_aclk400_mcuisp_p4x12,
+ MUX(aclk400_mcuisp, "aclk400_mcuisp", mout_user_aclk400_mcuisp_p4x12,
SRC_TOP1, 24, 1),
MUX(none, "mout_aclk200", aclk_p4412, SRC_TOP0, 12, 1),
MUX(none, "mout_aclk100", aclk_p4412, SRC_TOP0, 16, 1),
@@ -563,20 +568,21 @@ struct samsung_div_clock exynos4x12_div_clks[] __initdata
= {
DIV(none, "div_mdnie_pwm_pre0", "div_mdnie_pwm0", DIV_LCD0, 12, 4),
DIV(none, "div_mipihsi", "mout_mipihsi", DIV_FSYS0, 20, 4),
DIV(none, "div_jpeg", "mout_jpeg", E4X12_DIV_CAM1, 0, 4),
- DIV(none, "div_aclk200", "mout_aclk200", DIV_TOP, 0, 3),
+ DIV(div_aclk200, "div_aclk200", "mout_aclk200", DIV_TOP, 0, 3),
DIV(none, "div_aclk266_gps", "mout_aclk266_gps", DIV_TOP, 20, 3),
- DIV(none, "div_aclk400_mcuisp", "mout_aclk400_mcuisp", DIV_TOP, 24, 3),
+ DIV(div_aclk400_mcuisp, "div_aclk400_mcuisp", "mout_aclk400_mcuisp",
+ DIV_TOP, 24, 3),
DIV(none, "div_pwm_isp", "mout_pwm_isp", E4X12_DIV_ISP, 0, 4),
DIV(none, "div_spi0_isp", "mout_spi0_isp", E4X12_DIV_ISP, 4, 4),
DIV(none, "div_spi0_isp_pre", "div_spi0_isp", E4X12_DIV_ISP, 8, 8),
DIV(none, "div_spi1_isp", "mout_spi1_isp", E4X12_DIV_ISP, 16, 4),
DIV(none, "div_spi1_isp_pre", "div_spi1_isp", E4X12_DIV_ISP, 20, 8),
DIV(none, "div_uart_isp", "mout_uart_isp", E4X12_DIV_ISP, 28, 4),
- DIV(none, "div_isp0", "aclk200", E4X12_DIV_ISP0, 0, 3),
- DIV(none, "div_isp1", "aclk200", E4X12_DIV_ISP0, 4, 3),
+ DIV
Re: [PATCH v4 04/14] mfd: Add Samsung PWM/timer master driver
On Friday 05 of April 2013 19:05:24 Arnd Bergmann wrote: > On Friday 05 April 2013, Tomasz Figa wrote: > > On Friday 05 of April 2013 18:39:58 Samuel Ortiz wrote: > > > Hi Tomasz, > > > > > > On Thu, Apr 04, 2013 at 06:37:01PM +0200, Tomasz Figa wrote: > > > > This patch adds master driver for PWM/timer block available on many > > > > Samsung SoCs providing clocksource and PWM output capabilities. > > > > > > Why is that an MFD driver, and why aren't you using the PWM APIs for it > > > ? > > > Also, you probably want to look at using the regmap APIs for your IO. > > > > The case of Samsung PWM timers is rather complicated. It is a hardware > > block that can be used at the same time to generate PWM signal and as a > > system clocksource. > > > > There was a discussion on how to solve the problem of sharing the > > hardware: > > http://thread.gmane.org/gmane.linux.kernel.samsung-soc/16480/focus=16500 > > (see the linked post and replies to it). > > I don't think anyone ever suggested using a private API though. I must have gotten the last paragraph of http://article.gmane.org/gmane.linux.kernel.samsung-soc/16638 wrong then. For me it seemed like the timer driver would expose a private API to the PWM driver. > I think > it's ok if the driver lives in drivers/mfd when it doesn't fit anywhere > else easily, but you should really register it to the pwm subsystem to > expose that functionality, not export functions that can be used by > a pwm shim driver, which even seems to be missing from the series. Anyway, using PWM API in a clocksource driver that needs to be running very early (before any initcalls get called) seems a bit weird for me, especially when PWM API doesn't provide such fine grained control over PWM timers that is required in the clocksource drivers. Best regards, -- Tomasz Figa Samsung Poland R&D Center SW Solution Development, Kernel and System Framework -- To unsubscribe from this list: send the line "unsubscribe linux-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 04/14] mfd: Add Samsung PWM/timer master driver
On Friday 05 April 2013, Tomasz Figa wrote: > On Friday 05 of April 2013 18:39:58 Samuel Ortiz wrote: > > Hi Tomasz, > > > > On Thu, Apr 04, 2013 at 06:37:01PM +0200, Tomasz Figa wrote: > > > This patch adds master driver for PWM/timer block available on many > > > Samsung SoCs providing clocksource and PWM output capabilities. > > > Why is that an MFD driver, and why aren't you using the PWM APIs for it ? > > Also, you probably want to look at using the regmap APIs for your IO. > > The case of Samsung PWM timers is rather complicated. It is a hardware block > that can be used at the same time to generate PWM signal and as a system > clocksource. > > There was a discussion on how to solve the problem of sharing the hardware: > http://thread.gmane.org/gmane.linux.kernel.samsung-soc/16480/focus=16500 > (see the linked post and replies to it). > I don't think anyone ever suggested using a private API though. I think it's ok if the driver lives in drivers/mfd when it doesn't fit anywhere else easily, but you should really register it to the pwm subsystem to expose that functionality, not export functions that can be used by a pwm shim driver, which even seems to be missing from the series. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 04/14] mfd: Add Samsung PWM/timer master driver
Hi Samuel, On Friday 05 of April 2013 18:39:58 Samuel Ortiz wrote: > Hi Tomasz, > > On Thu, Apr 04, 2013 at 06:37:01PM +0200, Tomasz Figa wrote: > > This patch adds master driver for PWM/timer block available on many > > Samsung SoCs providing clocksource and PWM output capabilities. > > > > Signed-off-by: Tomasz Figa > > Signed-off-by: Kyungmin Park > > --- > > > > .../devicetree/bindings/pwm/pwm-samsung.txt| 37 ++ > > drivers/clocksource/Kconfig| 1 + > > drivers/mfd/Kconfig| 3 + > > drivers/mfd/Makefile | 1 + > > drivers/mfd/samsung-pwm.c | 439 > > + drivers/pwm/Kconfig > > | 1 + > > include/linux/mfd/samsung-pwm.h| 49 +++ > > include/linux/platform_data/samsung-pwm.h | 28 ++ > > 8 files changed, 559 insertions(+) > > create mode 100644 Documentation/devicetree/bindings/pwm/pwm-samsung.txt > > create mode 100644 drivers/mfd/samsung-pwm.c > > create mode 100644 include/linux/mfd/samsung-pwm.h > > create mode 100644 include/linux/platform_data/samsung-pwm.h > > Why is that an MFD driver, and why aren't you using the PWM APIs for it ? > Also, you probably want to look at using the regmap APIs for your IO. The case of Samsung PWM timers is rather complicated. It is a hardware block that can be used at the same time to generate PWM signal and as a system clocksource. There was a discussion on how to solve the problem of sharing the hardware: http://thread.gmane.org/gmane.linux.kernel.samsung-soc/16480/focus=16500 (see the linked post and replies to it). Best regards, -- Tomasz Figa Samsung Poland R&D Center SW Solution Development, Kernel and System Framework -- To unsubscribe from this list: send the line "unsubscribe linux-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 04/14] mfd: Add Samsung PWM/timer master driver
Hi Tomasz, On Thu, Apr 04, 2013 at 06:37:01PM +0200, Tomasz Figa wrote: > This patch adds master driver for PWM/timer block available on many > Samsung SoCs providing clocksource and PWM output capabilities. > > Signed-off-by: Tomasz Figa > Signed-off-by: Kyungmin Park > --- > .../devicetree/bindings/pwm/pwm-samsung.txt| 37 ++ > drivers/clocksource/Kconfig| 1 + > drivers/mfd/Kconfig| 3 + > drivers/mfd/Makefile | 1 + > drivers/mfd/samsung-pwm.c | 439 > + > drivers/pwm/Kconfig| 1 + > include/linux/mfd/samsung-pwm.h| 49 +++ > include/linux/platform_data/samsung-pwm.h | 28 ++ > 8 files changed, 559 insertions(+) > create mode 100644 Documentation/devicetree/bindings/pwm/pwm-samsung.txt > create mode 100644 drivers/mfd/samsung-pwm.c > create mode 100644 include/linux/mfd/samsung-pwm.h > create mode 100644 include/linux/platform_data/samsung-pwm.h Why is that an MFD driver, and why aren't you using the PWM APIs for it ? Also, you probably want to look at using the regmap APIs for your IO. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC: PATCH 2/2] iio: adc: exynos_adc: Handle timeout and race conditions
On 04/05/2013 04:56 PM, Doug Anderson wrote: > Lars, > > On Fri, Apr 5, 2013 at 1:53 AM, Lars-Peter Clausen wrote: >> Since we sleep inside the protected section we need to use a mutex. > > Ah, good point. > >> It's not the timeout case I'm worried about, but the case where the transfer >> is interrupted by the user. Even though it is rather unlikely for the >> problem to occur we should still try to avoid it, this is one of these >> annoying heisenbugs that happen once in a while and nobody is able to >> reproduce them. > > Yes, of course. Then we can also get extra confidence that the reset > logic works well by stressing out this case... :) > > This makes me think, though. Given how fast we expect the ADC > transaction to finish, would there be any benefit to making the wait > non-interruptible and then shortening the timeout a whole lot. If we > shortened to 1ms then we're really not "non-interruptible" for very > long and there's less chance of subtle bugs in the way that reset > works. Yes, that could also work. - Lars -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC: PATCH 2/2] iio: adc: exynos_adc: Handle timeout and race conditions
Lars, On Fri, Apr 5, 2013 at 1:53 AM, Lars-Peter Clausen wrote: > Since we sleep inside the protected section we need to use a mutex. Ah, good point. > It's not the timeout case I'm worried about, but the case where the transfer > is interrupted by the user. Even though it is rather unlikely for the > problem to occur we should still try to avoid it, this is one of these > annoying heisenbugs that happen once in a while and nobody is able to > reproduce them. Yes, of course. Then we can also get extra confidence that the reset logic works well by stressing out this case... :) This makes me think, though. Given how fast we expect the ADC transaction to finish, would there be any benefit to making the wait non-interruptible and then shortening the timeout a whole lot. If we shortened to 1ms then we're really not "non-interruptible" for very long and there's less chance of subtle bugs in the way that reset works. -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 1/3] clk: exynos: register audio subsystem clocks using common clock framework
On 04/05/2013 08:23 AM, Padmavathi Venna wrote:
> Audio subsystem is introduced in exynos platforms. This has seperate
> clock controller which can control i2s0 and pcm0 clocks. This patch
> registers the audio subsystem clocks with the common clock framework.
>
> Signed-off-by: Padmavathi Venna
> ---
> drivers/clk/samsung/Makefile |1 +
> drivers/clk/samsung/clk-exynos-audss.c | 139
>
> 2 files changed, 140 insertions(+), 0 deletions(-)
> create mode 100644 drivers/clk/samsung/clk-exynos-audss.c
>
> diff --git a/drivers/clk/samsung/Makefile b/drivers/clk/samsung/Makefile
> index b7c232e..1876810 100644
> --- a/drivers/clk/samsung/Makefile
> +++ b/drivers/clk/samsung/Makefile
> @@ -6,3 +6,4 @@ obj-$(CONFIG_COMMON_CLK) += clk.o clk-pll.o
> obj-$(CONFIG_ARCH_EXYNOS4) += clk-exynos4.o
> obj-$(CONFIG_SOC_EXYNOS5250) += clk-exynos5250.o
> obj-$(CONFIG_SOC_EXYNOS5440) += clk-exynos5440.o
> +obj-$(CONFIG_ARCH_EXYNOS)+= clk-exynos-audss.o
> diff --git a/drivers/clk/samsung/clk-exynos-audss.c
> b/drivers/clk/samsung/clk-exynos-audss.c
> new file mode 100644
> index 000..d7f9aa8
> --- /dev/null
> +++ b/drivers/clk/samsung/clk-exynos-audss.c
> @@ -0,0 +1,139 @@
> +/*
> + * Copyright (c) 2013 Samsung Electronics Co., Ltd.
> + * Author: Padmavathi Venna
> + *
> + * 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.
> + *
> + * Common Clock Framework support for Audio clks.
s/clks/Subsystem Clock Controller ?
> +*/
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +static DEFINE_SPINLOCK(lock);
> +static struct clk **clk_table;
> +static void __iomem *reg_base;
> +#ifdef CONFIG_OF
Is this really required ? This driver is for ARCH_EXYNOS which is
going to be DT only anyway - presumably it would depend on OF.
> +static struct clk_onecell_data clk_data;
> +#endif
> +
> +#define ASS_CLK_SRC 0x0
> +#define ASS_CLK_DIV 0x4
> +#define ASS_CLK_GATE 0x8
> +
> +static unsigned long reg_save[][2] = {
> + {ASS_CLK_SRC, 0x0},
nit: '0x' could be probably omitted.
> + {ASS_CLK_DIV, 0x0},
> + {ASS_CLK_GATE, 0x0},
> +};
> +
> +/*
> + * Let each supported clock get a unique id. This id is used to lookup the
> clock
> + * for device tree based platforms.
> + *
> + * When adding a new clock to this list, it is advised to add it to the end.
> + * That is because the device tree source file is referring to these ids and
> + * any change in the sequence number of existing clocks will require
> + * corresponding change in the device tree files. This limitation would go
> away
> + * when pre-processor support for dtc would be available.
It's already available. Also please see [1]. IMO the best would be to
create a header file including #defines for all the clocks indexes as
per enum exynos_audss_clks. This header would be put in a common location
so it can be included by the driver and the dts files.
> + */
> +enum exynos_audss_clks {
> + /* audss clocks */
> + mout_audss, mout_i2s,
> + dout_srp, dout_bus, dout_i2s,
> + srp_clk, i2s_bus, sclk_i2s0,
> +
> + nr_clks,
> +};
> +
> +/* list of all parent clock list */
> +static const char *mout_audss_p[] = { "fin_pll", "fout_epll" };
> +static const char *mout_i2s_p[] = { "mout_audss", "cdclk0", "sclk_audio0" };
> +
> +#ifdef CONFIG_PM_SLEEP
> +static int exynos_audss_clk_suspend(void)
> +{
> + int i;
> +
> + for (i = 0; i < 3; i++)
> + reg_save[i][1] = __raw_readl(reg_base + reg_save[i][0]);
Why using the __raw_* accessors ? I think it should be readl().
> +
> + return 0;
> +}
> +
> +static void exynos_audss_clk_resume(void)
> +{
> + int i;
> +
> + for (i = 0; i < 3; i++)
> + __raw_writel(reg_save[i][1], reg_base + reg_save[i][0]);
Same here, writel().
> +}
> +
> +static struct syscore_ops exynos_audss_clk_syscore_ops = {
> + .suspend= exynos_audss_clk_suspend,
> + .resume = exynos_audss_clk_resume,
> +};
> +#endif /* CONFIG_PM_SLEEP */
> +
> +/* register exynos_audss clocks */
> +void __init exynos_audss_clk_init(struct device_node *np)
> +{
Isn't it better to just do
if (np == NULL)
return;
i.e. just skip the initialization altogether ? panic() seems
unreasonable here.
> + if (np) {
> + reg_base = of_iomap(np, 0);
> + if (!reg_base)
> + panic("%s: failed to map registers\n", __func__);
> + } else
> + panic("%s: unable to determine soc\n", __func__);
> +
> + clk_table = kzalloc(sizeof(struct clk *) * nr_clks, GFP_KERNEL);
> + if (!clk_table)
> + panic("could not allocate clock lookup table\n");
> +
> + clk_data.clks = clk_table;
> + clk_data.clk_num = nr_clks;
> + of_clk_add_provider(np, of_clk_src_onecell_get, &clk_data);
[PATCH v3] mmc: dw_mmc: let device core setup the default pin configuration
With device core now able to setup the default pin configuration,
the pin configuration code based on the deprecated Samsung specific
gpio bindings is removed.
Signed-off-by: Thomas Abraham
---
Changes since v2:
- Changed patch subject from "mmc: dwmmc: let..." to "mmc: dw_mmc: let..."
- Rebased to Chris's latest mmc-next branch.
drivers/mmc/host/dw_mmc-exynos.c | 38 --
drivers/mmc/host/dw_mmc.c| 12 ++--
drivers/mmc/host/dw_mmc.h|3 ---
3 files changed, 2 insertions(+), 51 deletions(-)
diff --git a/drivers/mmc/host/dw_mmc-exynos.c b/drivers/mmc/host/dw_mmc-exynos.c
index c7f0976..f013e7e 100644
--- a/drivers/mmc/host/dw_mmc-exynos.c
+++ b/drivers/mmc/host/dw_mmc-exynos.c
@@ -152,43 +152,6 @@ static int dw_mci_exynos_parse_dt(struct dw_mci *host)
return 0;
}
-static int dw_mci_exynos_setup_bus(struct dw_mci *host,
- struct device_node *slot_np, u8 bus_width)
-{
- int idx, gpio, ret;
-
- if (!slot_np)
- return -EINVAL;
-
- /* cmd + clock + bus-width pins */
- for (idx = 0; idx < NUM_PINS(bus_width); idx++) {
- gpio = of_get_gpio(slot_np, idx);
- if (!gpio_is_valid(gpio)) {
- dev_err(host->dev, "invalid gpio: %d\n", gpio);
- return -EINVAL;
- }
-
- ret = devm_gpio_request(host->dev, gpio, "dw-mci-bus");
- if (ret) {
- dev_err(host->dev, "gpio [%d] request failed\n", gpio);
- return -EBUSY;
- }
- }
-
- if (host->pdata->quirks & DW_MCI_QUIRK_BROKEN_CARD_DETECTION)
- return 0;
-
- gpio = of_get_named_gpio(slot_np, "samsung,cd-pinmux-gpio", 0);
- if (gpio_is_valid(gpio)) {
- if (devm_gpio_request(host->dev, gpio, "dw-mci-cd"))
- dev_err(host->dev, "gpio [%d] request failed\n", gpio);
- } else {
- dev_info(host->dev, "cd gpio not available");
- }
-
- return 0;
-}
-
/* Common capabilities of Exynos4/Exynos5 SoC */
static unsigned long exynos_dwmmc_caps[4] = {
MMC_CAP_UHS_DDR50 | MMC_CAP_1_8V_DDR |
@@ -205,7 +168,6 @@ static const struct dw_mci_drv_data exynos_drv_data = {
.prepare_command= dw_mci_exynos_prepare_command,
.set_ios= dw_mci_exynos_set_ios,
.parse_dt = dw_mci_exynos_parse_dt,
- .setup_bus = dw_mci_exynos_setup_bus,
};
static const struct of_device_id dw_mci_exynos_match[] = {
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index a443820..2ed9989 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -1945,14 +1945,6 @@ static int dw_mci_init_slot(struct dw_mci *host,
unsigned int id)
else
bus_width = 1;
- if (drv_data && drv_data->setup_bus) {
- struct device_node *slot_np;
- slot_np = dw_mci_of_find_slot_node(host->dev, slot->id);
- ret = drv_data->setup_bus(host, slot_np, bus_width);
- if (ret)
- goto err_setup_bus;
- }
-
switch (bus_width) {
case 8:
mmc->caps |= MMC_CAP_8_BIT_DATA;
@@ -2002,7 +1994,7 @@ static int dw_mci_init_slot(struct dw_mci *host, unsigned
int id)
ret = mmc_add_host(mmc);
if (ret)
- goto err_setup_bus;
+ goto err_add_host;
#if defined(CONFIG_DEBUG_FS)
dw_mci_init_debugfs(slot);
@@ -2019,7 +2011,7 @@ static int dw_mci_init_slot(struct dw_mci *host, unsigned
int id)
return 0;
-err_setup_bus:
+err_add_host:
mmc_free_host(mmc);
return -EINVAL;
}
diff --git a/drivers/mmc/host/dw_mmc.h b/drivers/mmc/host/dw_mmc.h
index 53b8fd9..0b74189 100644
--- a/drivers/mmc/host/dw_mmc.h
+++ b/drivers/mmc/host/dw_mmc.h
@@ -190,7 +190,6 @@ extern int dw_mci_resume(struct dw_mci *host);
* @prepare_command: handle CMD register extensions.
* @set_ios: handle bus specific extensions.
* @parse_dt: parse implementation specific device tree properties.
- * @setup_bus: initialize io-interface
*
* Provide controller implementation specific extensions. The usage of this
* data structure is fully optional and usage of each member in this structure
@@ -203,7 +202,5 @@ struct dw_mci_drv_data {
void(*prepare_command)(struct dw_mci *host, u32 *cmdr);
void(*set_ios)(struct dw_mci *host, struct mmc_ios *ios);
int (*parse_dt)(struct dw_mci *host);
- int (*setup_bus)(struct dw_mci *host,
- struct device_node *slot_np, u8 bus_width);
};
#endif /* _DW_MMC_H_ */
--
1.6.6.rc2
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More ma
Re: [PATCH 0/3] clk: Exynos: Register audio subsytem clocks using common clk framework
Hi Padmavathi,
On 04/05/2013 08:40 AM, Padmavathi Venna wrote:
> Samsung Exynos SoC has a separate subsystem for audio. This subsystem
> has a internal clock controller which controls i2s0 and pcm0 clocks.
> This patch series adds the Samsung Exynos SoC audio subsytem clock code
> to the common clock framework and provides the I2S0 clock information in
> the dtsi file.
>
> Padmavathi Venna (3):
> clk: exynos: register audio subsystem clocks using common clock
> framework
> ARM: dts: add Exynos audio subsystem clock controller node
> ARM: dts: add clock provider information for i2s0 controller in
> Exynos5250
>
> arch/arm/boot/dts/exynos5250.dtsi |8 ++
> drivers/clk/samsung/Makefile |1 +
> drivers/clk/samsung/clk-exynos-audss.c | 139
>
> 3 files changed, 148 insertions(+), 0 deletions(-)
> create mode 100644 drivers/clk/samsung/clk-exynos-audss.c
It looks good, it's very similar what we have written recently for Exynos4.
It seems the binding documentation is missing in this patch set. I've included
below content of our .../bindings/clock/exynos4-audss-clock.txt file. Feel free
to reuse any parts of it.
>From a brief look Exynos4 and Exynos5 Audio Subsystem CLKCON very similar.
I've just found bit 2 of 0x0381_0008 register is not used on Exynos5250.
Additionally the Audio Subsystem Clock controller is present on S5PV210
SoCs and IMO compatible property you used is too generic. I would propose
to use at least:
"samsung,s5pv210-audss-clock"- for S5PV210
"samsung,exynos4210-audss-clock" - for Exynos4
"samsung,exynos5250-audss-clock" - for Exynos5
8<---
* Samsung Exynos4 Audio Subsystem Clock Controller
The Exynos4 Audio Subsystem clock controller generates and supplies clocks
to Audio Subsystem block available in the Exynos4 SoCs. The clock binding
described here is applicable to all SoC's in the Exynos4 family.
Required Properties:
- compatible: should be one of the following:
- "samsung,exynos4210-audss-clock" - controller compatible with all Exynos4
SoCs.
- reg: physical base address and length of the controller's register set.
- #clock-cells: should be 1.
The following is the list of clocks generated by the controller. Each clock is
assigned an identifier and client nodes use this identifier to specify the
clock which they consume. Some of the clocks are available only on a particular
Exynos4 SoC and this is specified where applicable.
Provided clocks:
Clock ID SoC (if specific)
---
mout_audss 0
dout_rp 1
dout_aud_bus2
mout_i2s3
dout_i2sclk04
clk_i2s05
clk_pcm06
Example 1: An example of a clock controller node is listed below.
clock_audss: clock-controller@0381 {
compatible = "samsung,exynos4-audss-clock";
reg = <0x0381 0x0C>;
#clock-cells = <1>;
};
Example 2: I2S controller node that consumes the clock generated by the clock
controller. Refer to the standard clock bindings for information
about 'clocks' and 'clock-names' property.
i2s0: i2s@0383 {
compatible = "samsung,i2s-v5";
reg = <0x0383 0x100>;
clocks = <&clock_audss 0>, <&clock_audss 3>, <&clock_audss 1>,
<&clock_audss 2>, <&clock_audss 4>, <&clock_audss 2>;
clock-names = "mout_audss", "mout_i2s", "dout_srp",
"dout_bus", "dout_i2s", "i2s_opclk0";
};
8<---
Thanks,
Sylwester
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V5 0/4] cpufreq: exynos5440: support for cpufreq driver
On Thursday, March 28, 2013 01:35:18 PM Amit Daniel Kachhap wrote: > Submitting the V5 version of exynos5440 cpufreq driver. This patchset > addresses > all the coding and design concerns raised especially by Viresh. > > Changes in V5: > * Removed the unnecessary DT look up entry from mach-exynos5-dt.c. > * Fixed all coding and comments issue raised by Viresh. > > Changes in V4: > * Added dev_err logs instead of pr_err. > * Used the devm_ioremap_resource API. > * Implemented several coding guidelines and minor error comments from > Sylwester, > Russell and Viresh. > > Changes in V3: > * Converted the driver to probe based as suggested by Viresh. This is also > beneficial for multiplatform kernel. > * Other coding guidelines related changes. > * Moved the DT node outside cpu0 node as the driver is now a platform > driver. > > Changes in V2: > * Added OPP library support to parse DT parameters. > * Removed a hack to handle interrupts in bootup. > * Implemented other review comments from Viresh and Inder. > > All these patches are dependent on Thomas Abraham common clock patches. > (http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg15860.html) > This whole patch series is based on 3.9-rc4. > > Amit Daniel Kachhap (4): > cpufreq: exynos: Add cpufreq driver for exynos5440 > cpufreq: exynos: Remove error return even if no soc is found > arm: exynos: Enable OPP library support for exynos5440 > arm: dts: Add cpufreq controller node for Exynos5440 SoC > > .../bindings/cpufreq/cpufreq-exynos5440.txt| 28 ++ > arch/arm/boot/dts/exynos5440.dtsi | 12 + > arch/arm/mach-exynos/Kconfig |2 + > drivers/cpufreq/Kconfig.arm|9 + > drivers/cpufreq/Makefile |1 + > drivers/cpufreq/exynos-cpufreq.c |2 +- > drivers/cpufreq/exynos5440-cpufreq.c | 474 > > 7 files changed, 527 insertions(+), 1 deletions(-) > create mode 100644 > Documentation/devicetree/bindings/cpufreq/cpufreq-exynos5440.txt > create mode 100644 drivers/cpufreq/exynos5440-cpufreq.c Is this for me or the Samsung tree? If it's for me, I need ACKs from the Samsung tree maintainers. Also, please address the Viresh's comments. Thanks, Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 07/18] cpufreq: s3c24xx: move cpufreq driver to drivers/cpufreq
On Friday, April 05, 2013 12:36:34 PM Viresh Kumar wrote: > On 5 April 2013 12:18, Kukjin Kim wrote: > > Basically, this moving looks good to me, but should be re-worked based on > > for-next of samsung tree because this touches too many samsung stuff so this > > should be sent to upstream via samsung tree. > > Hmm... Its already applied in Rafael's tree. But it doesn't mean that > it can't be > moved to your tree if there is a issue. Well, I'm dropping it. Please merge via the Samsung tree. Thanks, Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 00/14] ARM: samsung-time: Prepare for multiplatform support
Hi Heiko, On Friday 05 of April 2013 01:15:02 Heiko Stübner wrote: > Am Donnerstag, 4. April 2013, 18:36:57 schrieb Tomasz Figa: > > This series is an attempt to make the samsung-time clocksource driver > > ready > > for multiplatform kernels. It moves the driver to drivers/clocksource, > > cleans it up from uses of static platform-specific definitions, simplifies > > timer interrupt handling and adds Device Tree support. > > > > Only samsung-time driver is reworked to use the master driver at this > > time, > > since the PWM driver can be already considered broken at the moment and > > needs separate series of several patches to fix and clean it up, which > > I am already working on. > > > > Tested on Universal C210 board with Device Tree. Not tested without > > Device Tree, since it has been already broken before this series. > > Compile tested for other related SoCs. > > Looks nice. > > On a non-DT S3C2416 board: > Tested-by: Heiko Stuebner Thanks for testing. > And just so I don't search myself silly, am I right in thinking that the > driver does not use the generic clocksource registration yet and dt machines > must still use samsung_timer_init at this point? Yes. Because of the build failures it caused recently I have decided not to use it yet. It can be added with a small patch later, though. Best regards, -- Tomasz Figa Samsung Poland R&D Center SW Solution Development, Kernel and System Framework -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] regulator: max8952: Add Device Tree support
On Thu, Apr 04, 2013 at 06:17:20PM +0200, Tomasz Figa wrote: > + if (of_property_read_u32(np, "max8952,ramp-speed", &pd->ramp_speed)) > + dev_warn(dev, "max8952,ramp-speed property not specified, > defaulting to 32mV/us\n"); Applied both, though the above warning seems a bit harsh - it seems like assuming a worst case ramp rate ought to be totally safe and just a minor performance issue so silently accepted. signature.asc Description: Digital signature
[PATCH v11 3/3] ARM: dts: Add FIMD DT binding Documentation
Add DT binding documentation for the FIMD IP block found in Samsung SoCs.
Signed-off-by: Vikas Sajjan
Reviewed-by: Sylwester Nawrocki
---
.../devicetree/bindings/video/samsung-fimd.txt | 65
1 file changed, 65 insertions(+)
create mode 100644 Documentation/devicetree/bindings/video/samsung-fimd.txt
diff --git a/Documentation/devicetree/bindings/video/samsung-fimd.txt
b/Documentation/devicetree/bindings/video/samsung-fimd.txt
new file mode 100644
index 000..1984dbb
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/samsung-fimd.txt
@@ -0,0 +1,65 @@
+Device-Tree bindings for Samsung SoC display controller (FIMD)
+
+FIMD (Fully Interactive Mobile Display) is the Display Controller for the
+Samsung series of SoCs which transfers the image data from a video memory
+buffer to an external LCD interface.
+
+Required properties:
+- compatible: value should be one of the following
+ "samsung,s3c2443-fimd"; /* for S3C24XX SoCs */
+ "samsung,s3c6400-fimd"; /* for S3C64XX SoCs */
+ "samsung,s5p6440-fimd"; /* for S5P64X0 SoCs */
+ "samsung,s5pc100-fimd"; /* for S5PC100 SoC */
+ "samsung,s5pv210-fimd"; /* for S5PV210 SoC */
+ "samsung,exynos4210-fimd"; /* for Exynos4 SoCs */
+ "samsung,exynos5250-fimd"; /* for Exynos5 SoCs */
+
+- reg: physical base address and length of the FIMD registers set.
+
+- interrupt-parent: should be the phandle of the fimd controller's
+ parent interrupt controller.
+
+- interrupts: should contain a list of all FIMD IP block interrupts in the
+order: FIFO Level, VSYNC, LCD_SYSTEM. The interrupt specifier
+format depends on the interrupt controller used.
+
+- interrupt-names: should contain the interrupt names: "fifo", "vsync",
+ "lcd_sys", in the same order as they were listed in the interrupts
+property.
+
+- pinctrl-0: pin control group to be used for this controller.
+
+- pinctrl-names: must contain a "default" entry.
+
+- clocks: must include clock specifiers corresponding to entries in the
+ clock-names property.
+
+- clock-names: list of clock names sorted in the same order as the clocks
+ property. Must contain "sclk_fimd" and "fimd".
+
+Optional Properties:
+- samsung,power-domain: a phandle to FIMD power domain node.
+
+Example:
+
+SoC specific DT entry:
+
+ fimd@11c0 {
+ compatible = "samsung,exynos4210-fimd";
+ interrupt-parent = <&combiner>;
+ reg = <0x11c0 0x2>;
+ interrupt-names = "fifo", "vsync", "lcd_sys";
+ interrupts = <11 0>, <11 1>, <11 2>;
+ clocks = <&clock 140>, <&clock 283>;
+ clock-names = "sclk_fimd", "fimd";
+ samsung,power-domain = <&pd_lcd0>;
+ status = "disabled";
+ };
+
+Board specific DT entry:
+
+ fimd@11c0 {
+ pinctrl-0 = <&lcd_clk &lcd_data24 &pwm1_out>;
+ pinctrl-names = "default";
+ status = "okay";
+ };
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v11 0/3] Add DRM FIMD DT support for Exynos4 DT Machines
This patch series adds support for DRM FIMD DT for Exynos4 DT Machines, specifically for Exynos4412 SoC. changes since v10: - addressed comments from Sylwester Nawrocki changes since v9: - dropped the patch "ARM: dts: Add lcd pinctrl node entries for EXYNOS4412 SoC" as the gpios in the newly added nodes "lcd_en" and "lcd_sync" in this patch were already PULLed high by existing "lcd_clk" node. - addressed comments from Sylwester Nawrocki and Thomas Abraham changes since v8: - addressed comments to add missing documentation for clock and clock-names properties as pointed out by Sachin Kamat changes since v7: - rebased to kgene's "for-next" - Migrated to Common Clock Framework - removed the patch "ARM: dts: Add FIMD AUXDATA node entry for exynos4 DT", as migration to Common Clock Framework will NOT need this. - addressed the comments raised by Sachin Kamat changes since v6: - addressed comments and added interrupt-names = "fifo", "vsync", "lcd_sys" in exynos4.dtsi and re-ordered the interrupt numbering to match the order in interrupt combiner IP as suggested by Sylwester Nawrocki . changes since v5: - renamed the fimd binding documentation file name as "samsung-fimd.txt", since it not only talks about exynos display controller but also about previous samsung display controllers. - rephrased an abmigious statement about the interrupt combiner in the fimd binding documentation as pointed out by Sachin Kamat changes since v4: - moved the fimd binding documentation to Documentation/devicetree/bindings/video/ as suggested by Sylwester Nawrocki - added more fimd compatiblity strings in fimd documentation as discussed at https://patchwork.kernel.org/patch/2144861/ with Sylwester Nawrocki and Tomasz Figa - modified compatible string for exynos4 fimd as "exynos4210-fimd" exynos5 fimd as "exynos5250-fimd" to stick to the rule that compatible value should be named after first specific SoC model in which this particular IP version was included as discussed at https://patchwork.kernel.org/patch/2144861/ - documented more about the interrupt combiner and their order as suggested by Sylwester Nawrocki changes since v3: - rebased on http://git.kernel.org/?p=linux/kernel/git/kgene/linux-samsung.git;a=shortlog;h=refs/heads/for-next-next changes since v2: - added alias to 'fimd@11c0' node (reported by: Rahul Sharma ) - removed 'lcd0_data' node as there was already a similar node lcd_data24 (reported by: Jingoo Han - replaced spaces with tabs in display-timing node changes since v1: - added new patch to add FIMD DT binding Documentation - removed patch enabling SAMSUNG_DEV_BACKLIGHT and SAMSUNG_DEV_PMW for mach-exynos4 DT - added 'status' property to fimd DT node Is based on branch kgene's "for-next" https://git.kernel.org/cgit/linux/kernel/git/kgene/linux-samsung.git/log/?h=for-next Vikas Sajjan (3): ARM: dts: Add FIMD node to exynos4 ARM: dts: Add FIMD node and display timing node to exynos4412-origen.dts ARM: dts: Add FIMD DT binding Documentation .../devicetree/bindings/video/samsung-fimd.txt | 65 arch/arm/boot/dts/exynos4.dtsi | 12 arch/arm/boot/dts/exynos4412-origen.dts| 21 +++ 3 files changed, 98 insertions(+) create mode 100644 Documentation/devicetree/bindings/video/samsung-fimd.txt -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v11 2/3] ARM: dts: Add FIMD node and display timing node to exynos4412-origen.dts
This patch adds FIMD related nodes for the Origen Quad board.
Signed-off-by: Vikas Sajjan
Reviewed-by: Sylwester Nawrocki
---
arch/arm/boot/dts/exynos4412-origen.dts | 21 +
1 file changed, 21 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4412-origen.dts
b/arch/arm/boot/dts/exynos4412-origen.dts
index a5478bd..b39bffc 100644
--- a/arch/arm/boot/dts/exynos4412-origen.dts
+++ b/arch/arm/boot/dts/exynos4412-origen.dts
@@ -70,6 +70,27 @@
status = "okay";
};
+ fimd@11c0 {
+ pinctrl-0 = <&lcd_clk &lcd_data24 &pwm1_out>;
+ pinctrl-names = "default";
+ status = "okay";
+ };
+
+ display-timings {
+ native-mode = <&timing0>;
+ timing0: timing {
+ clock-frequency = <5>;
+ hactive = <1024>;
+ vactive = <600>;
+ hfront-porch = <64>;
+ hback-porch = <16>;
+ hsync-len = <48>;
+ vback-porch = <64>;
+ vfront-porch = <16>;
+ vsync-len = <3>;
+ };
+ };
+
serial@1380 {
status = "okay";
};
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v11 1/3] ARM: dts: Add FIMD node to exynos4
This patch adds a common FIMD device node for all Exynos4 SoCs.
Signed-off-by: Vikas Sajjan
Reviewed-by: Sylwester Nawrocki
---
arch/arm/boot/dts/exynos4.dtsi | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index 800ff11..b8771c5 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -371,4 +371,16 @@
#dma-requests = <1>;
};
};
+
+ fimd: fimd@11c0 {
+ compatible = "samsung,exynos4210-fimd";
+ interrupt-parent = <&combiner>;
+ reg = <0x11c0 0x2>;
+ interrupt-names = "fifo", "vsync", "lcd_sys";
+ interrupts = <11 0>, <11 1>, <11 2>;
+ clocks = <&clock 140>, <&clock 283>;
+ clock-names = "sclk_fimd", "fimd";
+ samsung,power-domain = <&pd_lcd0>;
+ status = "disabled";
+ };
};
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC: PATCH 2/2] iio: adc: exynos_adc: Handle timeout and race conditions
On 04/03/2013 07:06 PM, Doug Anderson wrote: > Lars, > > On Sat, Mar 16, 2013 at 7:41 AM, Lars-Peter Clausen wrote: >> I think you still need the mutex for serialization, otherwise the requests >> would just cancel each other out. Btw. what happens if you start a conversion >> while another is still in progress? Is it possible to abort a conversion? > > I was thinking that the spinlock would just replace the mutex for the > purposes of serialization. > Since we sleep inside the protected section we need to use a mutex. > I stepped back a bit, though, and I'm wondering if we're over-thinking > things. The timeout case should certainly be handled properly (thanks > for pointing it out), but getting a timeout is really not expected and > adding a lot of extra overhead to handle it elegantly seems a bit > much? > > Specifically, the mutex means that we have one user of the ADC at a > time, and ADC conversion has nothing variable about it. The user > manual that I have access to talks about 12-bit conversion happening > in 1 microsecond with a 5MHz input clock or 5 microseconds with a 1MHz > input clock. Even if someone has clocks configured very differently, > it would be hard to imagine a conversion actually taking a full > second. > > ...so that means that if the timeout actually fires then something > else fairly drastic has gone wrong. It's _very_ unlikely that the IRQ > will still go off for this conversion sometime in the future. > It's not the timeout case I'm worried about, but the case where the transfer is interrupted by the user. Even though it is rather unlikely for the problem to occur we should still try to avoid it, this is one of these annoying heisenbugs that happen once in a while and nobody is able to reproduce them. > To me, total modifications to what's landed already ought to be: > > * Change timeout to long (from unsigned long) > > * Make sure we return errors (negative results) from > wait_for_completion_interruptible_timeout() properly. > > * If we get back a value of 0 from > wait_for_completion_interruptible_timeout() then we should print a > warning and attempt machinations to reset the ADC. Without ever > seeing real-world situtations that would cause a real timeout these > machinations would be a bit of a guess (is resetting the adc useful > when it's more likely that someone accidentally messed with the clock > tree or power gated the ADC?)... ...or perhaps a warning and a TODO > in the code would be enough? > > > Thoughts? I think most of this is already implemented and Naveen sent a patch to reset the controller in case of a timeout, which is a good idea and works fine, but you still should handle the case where the user aborted the transfer. Just resetting the core should work as well in that case. - Lars -- To unsubscribe from this list: send the line "unsubscribe linux-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 07/18] cpufreq: s3c24xx: move cpufreq driver to drivers/cpufreq
On 5 April 2013 12:18, Kukjin Kim wrote: > Basically, this moving looks good to me, but should be re-worked based on > for-next of samsung tree because this touches too many samsung stuff so this > should be sent to upstream via samsung tree. Hmm... Its already applied in Rafael's tree. But it doesn't mean that it can't be moved to your tree if there is a issue. What tree/branch? I used: git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git for-next > Applying: cpufreq: s3c24xx: move cpufreq driver to drivers/cpufreq > error: patch failed: arch/arm/Kconfig:2166 > error: arch/arm/Kconfig: patch does not apply above two are obvious as you haven't applied other patches in this series. > error: patch failed: arch/arm/mach-s3c24xx/Kconfig:28 > error: arch/arm/mach-s3c24xx/Kconfig: patch does not apply > error: patch failed: arch/arm/mach-s3c24xx/Makefile:17 > error: arch/arm/mach-s3c24xx/Makefile: patch does not apply > error: patch failed: drivers/cpufreq/Makefile:63 > error: drivers/cpufreq/Makefile: patch does not apply Same here. > error: drivers/cpufreq/s3c2412-cpufreq.c: does not exist in index I can still see it in for-next. Attached is my patch based of your for-next 0001-cpufreq-s3c24xx-move-cpufreq-driver-to-drivers-cpufr.patch Description: Binary data
