[PATCH v8 0/4] 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 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 sachin.ka...@linaro.org 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 sylvester.nawro...@gmail.com. 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 sachin.ka...@linaro.org changes since v4: - moved the fimd binding documentation to Documentation/devicetree/bindings/video/ as suggested by Sylwester Nawrocki sylvester.nawro...@gmail.com - added more fimd compatiblity strings in fimd documentation as discussed at https://patchwork.kernel.org/patch/2144861/ with Sylwester Nawrocki sylvester.nawro...@gmail.com and Tomasz Figa tomasz.f...@gmail.com - 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 sylvester.nawro...@gmail.com 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 r.sh.o...@gmail.com) - removed 'lcd0_data' node as there was already a similar node lcd_data24 (reported by: Jingoo Han jg1@samsung.com - 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 Sachin Kamat (1): ARM: dts: Add lcd pinctrl node entries for EXYNOS4412 SoC 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 | 61 arch/arm/boot/dts/exynos4.dtsi | 11 arch/arm/boot/dts/exynos4412-origen.dts| 22 +++ arch/arm/boot/dts/exynos4x12-pinctrl.dtsi | 14 + 4 files changed, 108 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 v8 2/4] ARM: dts: Add lcd pinctrl node entries for EXYNOS4412 SoC
From: Sachin Kamat sachin.ka...@linaro.org
Adds the lcd panel related picntrl nodes for Exynos4412 SoC
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
Signed-off-by: Vikas Sajjan vikas.saj...@linaro.org
---
arch/arm/boot/dts/exynos4x12-pinctrl.dtsi | 14 ++
1 file changed, 14 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4x12-pinctrl.dtsi
b/arch/arm/boot/dts/exynos4x12-pinctrl.dtsi
index 099cec7..a59d69c 100644
--- a/arch/arm/boot/dts/exynos4x12-pinctrl.dtsi
+++ b/arch/arm/boot/dts/exynos4x12-pinctrl.dtsi
@@ -354,6 +354,20 @@
samsung,pin-drv = 0;
};
+ lcd_sync: lcd-sync {
+ samsung,pins = gpf0-0, gpf0-1;
+ samsung,pin-function = 2;
+ samsung,pin-pud = 0;
+ samsung,pin-drv = 0;
+ };
+
+ lcd_en: lcd-en {
+ samsung,pins = gpf0-3;
+ samsung,pin-function = 2;
+ samsung,pin-pud = 0;
+ samsung,pin-drv = 0;
+ };
+
lcd_clk: lcd-clk {
samsung,pins = gpf0-0, gpf0-1, gpf0-2, gpf0-3;
samsung,pin-function = 2;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v8 3/4] ARM: dts: Add FIMD node and display timing node to exynos4412-origen.dts
Adds FIMD DT support to Origen quad board
Signed-off-by: Vikas Sajjan vikas.saj...@linaro.org
---
arch/arm/boot/dts/exynos4412-origen.dts | 22 ++
1 file changed, 22 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4412-origen.dts
b/arch/arm/boot/dts/exynos4412-origen.dts
index a5478bd..8953c92 100644
--- a/arch/arm/boot/dts/exynos4412-origen.dts
+++ b/arch/arm/boot/dts/exynos4412-origen.dts
@@ -70,6 +70,28 @@
status = okay;
};
+ fimd@11c0 {
+ samsung,power-domain = pd_lcd0;
+ pinctrl-0 = lcd_sync lcd_clk lcd_en lcd_data24 pwm1_out;
+ pinctrl-names = default;
+ status = okay;
+ };
+
+ display-timings {
+ native-mode = timing0;
+ timing0: timing@0 {
+ 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 v8 4/4] ARM: dts: Add FIMD DT binding Documentation
Adds FIMD DT binding documentation for both Samsung SoC and Board, with an
example
Signed-off-by: Vikas Sajjan vikas.saj...@linaro.org
---
.../devicetree/bindings/video/samsung-fimd.txt | 61
1 file changed, 61 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..d4b32d6
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/samsung-fimd.txt
@@ -0,0 +1,61 @@
+Device-Tree bindings for Samsung SoC display controller (FIMD)
+
+FIMD stands for Fully Interactive Mobile Display, is the Display Controller for
+the Samsung series of SoCs which transfers the image data from a video buffer
+located in the system memory 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 of the FIMD and length of memory mapped region
+
+- interrupt-parent : a phandle to the interrupt combiner node
+
+- interrupts : should contain a list of all FIMD IP block interrupts:
+ 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 : property defining the pinctrl configurations with a phandle
+
+- pinctrl-names : default state needs to be specified in the fimd node
+ The pinctrl bindings defined in
+ ../../../pinctrl/pinctrl-bindings.txt must be used to define a
+ pinctrl state named default.
+
+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;
+ status = disabled;
+ };
+
+Board specific DT Entry:
+
+ fimd@11c0 {
+ samsung,power-domain = pd_lcd0;
+ pinctrl-0 = lcd_sync lcd_clk lcd_en lcd0_data 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
Re: [PATCH v8 4/4] ARM: dts: Add FIMD DT binding Documentation
Hi Vikas,
+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;
Now that you have added clock properties, you need to make a mention
about them too in the description above.
--
With warm regards,
Sachin
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] drm/exynos: enable FIMD clocks
While migrating to common clock framework (CCF), found that the FIMD clocks were pulled down by the CCF. If CCF finds any clock(s) which has NOT been claimed by any of the drivers, then such clock(s) are PULLed low by CCF. By calling clk_prepare_enable() for FIMD clocks fixes the issue. Signed-off-by: Vikas Sajjan vikas.saj...@linaro.org --- drivers/gpu/drm/exynos/exynos_drm_fimd.c |3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c b/drivers/gpu/drm/exynos/exynos_drm_fimd.c index 9537761..d93dd8a 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c @@ -934,6 +934,9 @@ static int fimd_probe(struct platform_device *pdev) return ret; } + clk_prepare_enable(ctx-lcd_clk); + clk_prepare_enable(ctx-bus_clk); + ctx-vidcon0 = pdata-vidcon0; ctx-vidcon1 = pdata-vidcon1; ctx-default_win = pdata-default_win; -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] drm/exynos: enable FIMD clocks
On 19 March 2013 15:29, Vikas Sajjan vikas.saj...@linaro.org wrote: While migrating to common clock framework (CCF), found that the FIMD clocks were pulled down by the CCF. If CCF finds any clock(s) which has NOT been claimed by any of the drivers, then such clock(s) are PULLed low by CCF. By calling clk_prepare_enable() for FIMD clocks fixes the issue. Signed-off-by: Vikas Sajjan vikas.saj...@linaro.org --- drivers/gpu/drm/exynos/exynos_drm_fimd.c |3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c b/drivers/gpu/drm/exynos/exynos_drm_fimd.c index 9537761..d93dd8a 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c @@ -934,6 +934,9 @@ static int fimd_probe(struct platform_device *pdev) return ret; } + clk_prepare_enable(ctx-lcd_clk); + clk_prepare_enable(ctx-bus_clk); + Ideally you should check return values here. -- To unsubscribe from this list: send the line unsubscribe linux-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 1/7] media: V4L2: add temporary clock helpers
On Tue, 19 Mar 2013, Sylwester Nawrocki wrote:
+ if (!IS_ERR(clk) !try_module_get(clk-ops-owner))
+ clk = ERR_PTR(-ENODEV);
+ mutex_unlock(clk_lock);
+
+ if (!IS_ERR(clk)) {
+ clk-subdev = sd;
Why is this needed ? It seems a strange addition that might potentially
make transition to the common clocks API more difficult.
We got rid of the v4l2_clk_bind() function and the .bind() callback. Now I
need a pointer to subdevice _before_ v4l2_clk_register() (former
v4l2_clk_bound()), that's why I have to store it here.
Hmm, sorry, I'm not following. How can we store a subdev pointer in the clock
data structure that has not been registered yet and thus cannot be found
with v4l2_clk_find() ?
sorry, I meant v4l2_async_subdev_register(), not v4l2_clk_register(), my
mistake. And I meant v4l2_async_subdev_bind(), v4l2_async_subdev_unbind().
Before we had in the subdev driver (see imx074 example)
/* Tell the bridge the subdevice is about to bind */
v4l2_async_subdev_bind();
/* get a clock */
clk = v4l2_clk_get();
if (IS_ERR(clk))
return -EPROBE_DEFER;
/*
* enable the clock - this needs a subdev pointer, that we passed
* to the bridge with v4l2_async_subdev_bind() above
*/
v4l2_clk_enable(clk);
do_probe();
v4l2_clk_disable(clk);
/* inform the bridge: binding successful */
v4l2_async_subdev_bound();
Now we have just
/* get a clock */
clk = v4l2_clk_get();
if (IS_ERR(clk))
return -EPROBE_DEFER;
/*
* enable the clock - this needs a subdev pointer, that we stored
* in the clock object for the bridge driver to use with
* v4l2_clk_get() above
*/
v4l2_clk_enable(clk);
do_probe();
v4l2_clk_disable(clk);
/* inform the bridge: binding successful */
v4l2_async_subdev_bound();
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] drm/exynos: enable FIMD clocks
On 19 March 2013 15:29, Vikas Sajjan vikas.saj...@linaro.org wrote: While migrating to common clock framework (CCF), found that the FIMD clocks were pulled down by the CCF. If CCF finds any clock(s) which has NOT been claimed by any of the drivers, then such clock(s) are PULLed low by CCF. By calling clk_prepare_enable() for FIMD clocks fixes the issue. Signed-off-by: Vikas Sajjan vikas.saj...@linaro.org --- drivers/gpu/drm/exynos/exynos_drm_fimd.c |3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c b/drivers/gpu/drm/exynos/exynos_drm_fimd.c index 9537761..d93dd8a 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c @@ -934,6 +934,9 @@ static int fimd_probe(struct platform_device *pdev) return ret; } + clk_prepare_enable(ctx-lcd_clk); + clk_prepare_enable(ctx-bus_clk); + You also need to do clk_disable_unprepare during exit. -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] These two patches to s3c_pm_arch_prepare_irqs() were part of the work
to make suspend/resume reliable on the ARM Chromebook (exynos5250-snow). A few more details: - The first patch is not strictly needed but was a nice cleanup. Our understanding was that EINT0 was originally turned on for exynos evt0 silicon and not needed for evt1. - The second patch is more important and (also) more obvious. The function was modifying the S5P_WAKEUP_MASK register and then clobbering its own modifications. For some history, see: - https://gerrit.chromium.org/gerrit/31337 - https://gerrit.chromium.org/gerrit/31341 Jonathan Kliegman (2): arm: exynos: Remove hardcode wakeup unmask for EINT_0 arm: exynos: Clear ENABLE_WAKEUP_SW bit when entering suspend arch/arm/mach-exynos/include/mach/pm-core.h | 9 ++--- 1 file changed, 2 insertions(+), 7 deletions(-) -- 1.8.1.3 -- To unsubscribe from this list: send the line unsubscribe linux-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: exynos: Remove hardcode wakeup unmask for EINT_0
From: Jonathan Kliegman kli...@chromium.org For legacy reasons EINT_0 was being forced on for all exynos systems as a wake interrupt. For boards that need EINT_0 they should probably enable it with enable_irq_wake Signed-off-by: Jonathan Kliegman kli...@chromium.org Signed-off-by: Doug Anderson diand...@chromium.org Reviewed-by: Doug Anderson diand...@chromium.org Reviewed-by: Thomas Abraham thomas...@samsung.com --- arch/arm/mach-exynos/include/mach/pm-core.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/mach-exynos/include/mach/pm-core.h b/arch/arm/mach-exynos/include/mach/pm-core.h index a67ecfa..9d8da51e3 100644 --- a/arch/arm/mach-exynos/include/mach/pm-core.h +++ b/arch/arm/mach-exynos/include/mach/pm-core.h @@ -33,7 +33,7 @@ static inline void s3c_pm_arch_prepare_irqs(void) __raw_writel(tmp, S5P_WAKEUP_MASK); __raw_writel(s3c_irqwake_intmask, S5P_WAKEUP_MASK); - __raw_writel(s3c_irqwake_eintmask 0xFFFE, S5P_EINT_WAKEUP_MASK); + __raw_writel(s3c_irqwake_eintmask, S5P_EINT_WAKEUP_MASK); } static inline void s3c_pm_arch_stop_clocks(void) -- 1.8.1.3 -- To unsubscribe from this list: send the line unsubscribe linux-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: exynos: Clear ENABLE_WAKEUP_SW bit when entering suspend
From: Jonathan Kliegman kli...@chromium.org
Setting this bit to 0 causes the system to wait until suspended
to use the wakeup masks. With it being set high previously,
masked interrupts were being received and processed before the
EINT_WAKEUP_MASK was configured.
Signed-off-by: Jonathan Kliegman kli...@chromium.org
Signed-off-by: Doug Anderson diand...@chromium.org
Reviewed-by: Doug Anderson diand...@chromium.org
---
arch/arm/mach-exynos/include/mach/pm-core.h | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/arch/arm/mach-exynos/include/mach/pm-core.h
b/arch/arm/mach-exynos/include/mach/pm-core.h
index 9d8da51e3..7dbbfec 100644
--- a/arch/arm/mach-exynos/include/mach/pm-core.h
+++ b/arch/arm/mach-exynos/include/mach/pm-core.h
@@ -27,13 +27,8 @@ static inline void s3c_pm_debug_init_uart(void)
static inline void s3c_pm_arch_prepare_irqs(void)
{
- unsigned int tmp;
- tmp = __raw_readl(S5P_WAKEUP_MASK);
- tmp = ~(1 31);
- __raw_writel(tmp, S5P_WAKEUP_MASK);
-
- __raw_writel(s3c_irqwake_intmask, S5P_WAKEUP_MASK);
__raw_writel(s3c_irqwake_eintmask, S5P_EINT_WAKEUP_MASK);
+ __raw_writel(s3c_irqwake_intmask ~(1 31), S5P_WAKEUP_MASK);
}
static inline void s3c_pm_arch_stop_clocks(void)
--
1.8.1.3
--
To unsubscribe from this list: send the line unsubscribe linux-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 6/6] irqchip: s3c24xx: add s3c2450 interrupt definitions
Am Dienstag, 19. März 2013, 03:28:59 schrieb Rob Herring:
On 03/18/2013 06:34 PM, Heiko Stübner wrote:
Am Montag, 18. März 2013, 23:14:52 schrieb Rob Herring:
On 03/18/2013 11:53 AM, Heiko Stübner wrote:
[...]
My first thought here is this information should not be centralized in
the controller node, but placed with each source node (2D, I2C1, etc).
I'm not sure I can follow currently :-)
I'll try an example:
The s3c serial driver expects the interrupts for uart tx and rx and the
dt
entry would look like:
serial@5000 {
compatible = samsung,s3c2410-uart;
reg = 0x5000 0x4000;
interrupt-parent = subintc;
interrupts = 0, 1;
So what does 0 and 1 correspond to? These are the bits in the subintc?
Yep, the bits in the subintc register.
};
the map for these in the subintc looks like
s3c24xx,irqlist = 3 28 /* UART0-RX */
3 28 /* UART0-TX */
3 28 /* UART0-ERR */
marking them as using the level-handler and being children of the
interrupt in bit 28 of the intc handler.
So the irq_entry would check the intc, see the waiting interrupt in bit
28, jump to the demux function which would then handle which ever of
rx,tx or err would be waiting, which then get sent to the serial driver.
These mappings between sub- and parent irqs also vary very much between
the different s3c24xx variants, as can be seen by the multitude of lists
in [0] and the parent interrupts are only used for demuxing purposes.
-
A notable speciality are the AC97 (sound) and watchdog interrupts (bits
27 and 28 of the subregister), as they share a common parent interrupt
(bit 9 of the main interrupt register).
So irq_entry checks the main register, sees bit 9 (ac97/watchdog),
demuxes it to either coming from the ac97 or watchdog and sends it to
the relevant driver.
I don't think this should be exposed to the drivers at all :-) .
---
So I'm not sure, how this would be able to go in the driver nodes.
The information in an interrupts property is transparent to the driver,
but can contain extra cells with whatever information you need. The GIC
binding has SPI or PPI interrupt type information for example.
so you mean something like bit flags parent-bit, right?
The only thing I could think of, would be to make the handler adjustable
via the regular interrupts properties (i.e. as two_cell) which would
bring the list down to only list the parent relationships.
Hmm ... and this parent list might be doable via the regular interrupts
property, so the subintc would look like:
subintc: subintc = {
interrupt-parent = intc;
interrupts = 28 0, 28 0, 28 0, 23 0, 23 0, .
/* bit0bit1bit2bit3bit4 . */
}
i.e. naming the parent interrupt for each of the interrupt bits of the
sub- controller. Would this be the right direction?
I think you may want to use an interrupt-map property. That should allow
you to do arbitrary mappings from one interrupt controller's numbering
to another's numbering. The VExpress and several PPC platforms have
examples.
Yep, I've read the examples and also a bit more in-depth on devicetree.org and
it seems, as you suggested, interrupt-maps are the right concept to describe
such mappings.
In general, what would be the preferred way to solve this?
Like described above, having the parent bit encoded in the interrupt property
or doing it with a mapping of sorts like we discussed down here?
I don't have a preference for one or the other right now and both look like
interesting concepts.
Thanks
Heiko
--
To unsubscribe from this list: send the line unsubscribe linux-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 00/16] clk: exynos4/5: migrate to common clock framework
Quoting Thomas Abraham (2013-02-18 00:21:10) Changes since v5: - Squashed several Exynos4 fixes patch from Tomasz Figa - Included support for Exynos5250 and Exynos5440, thus converting all Exynos4 and Exynos5 platforms to common clock framework. - Depends on the following patch series. - http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg15849.html - http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg15852.html Changes since v4: - Rebased to linux-3.8-rc1. Changes since v3: - Includes changes suggested by Tomasz Figa tomasz.f...@gmail.com This patch series migrates the Samsung Exynos4/5 SoC clock code to adopt the common clock framework. The use of Samsung specific clock structures has been removed and all board support code has been updated. imx-style of clock registration and lookup has been adopted for device tree based exynos4/5 platforms. Thomas, Are you planning a V7 series which includes the clock alias bits from patch #1? Regards, Mike -- To unsubscribe from this list: send the line unsubscribe linux-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 V4 0/9] Add mandatory regulator for all users of pwm-backlight.
Many backlights are enabled via GPIO. We can generalize the GPIO to a fixed regulator. The enable regulator needs to be mandatory because there was no good way to determine the difference between opting out of the regulator, and probe deferral. This series of patches is intended to add a dummy regulator (or a GPIO regulator) for all users of the pwm-backlight. The last patch in the series will always be the pwm-backlight change to add this mandatory regulator. Patches following up to that patch add the mandatory regulator on a per mach family basis. Once all users of pwm-backlight have been patched, this series can be applied in order to maintain bisectability. All I did in every case was to provide a dummy fixed regulator to pwm-backlight. If your platform actually uses a regulator (or a GPIO) to enable the backlight, please either let me know so that I can make the modifications and give you something back to test. Or (better yet), provide me with a tested, alternate patch that I can fold into this patch series. I made sure that where there was a defconfig for an affected board, that it builds. I did not test-build the unicore patch. V3 and earlier versions of this series only had the OMAP patch, which I used for ironing out some early, obvious stuff. V4 and later is the complete patch set. Andrew Chew (9): ARM: OMAP: board-4430sdp: Provide regulator to pwm-backlight ARM: S3C24XX: Provide regulator to pwm-backlight ARM: pxa: Provide regulator to pwm-backlight ARM: EXYNOS: Provide regulator to pwm-backlight unicore32: Provide regulator to pwm-backlight ARM: mxs: Provide regulator to pwm-backlight ARM: vt8500: Provide regulator to pwm-backlight ARM: tegra: Provide regulator to pwm-backlight pwm_bl: Add mandatory backlight enable regulator .../bindings/video/backlight/pwm-backlight.txt | 14 + arch/arm/boot/dts/imx23-evk.dts| 6 +++ arch/arm/boot/dts/imx28-apf28dev.dts | 6 +++ arch/arm/boot/dts/imx28-cfa10049.dts | 6 +++ arch/arm/boot/dts/imx28-evk.dts| 6 +++ arch/arm/boot/dts/imx28-tx28.dts | 6 +++ arch/arm/boot/dts/tegra20-medcom-wide.dts | 6 +++ arch/arm/boot/dts/wm8850-w70v2.dts | 6 +++ arch/arm/mach-exynos/mach-nuri.c | 7 +++ arch/arm/mach-omap2/board-4430sdp.c| 6 +++ arch/arm/mach-pxa/cm-x300.c| 7 +++ arch/arm/mach-pxa/colibri-pxa270-income.c | 8 +++ arch/arm/mach-pxa/ezx.c| 9 arch/arm/mach-pxa/hx4700.c | 8 +++ arch/arm/mach-pxa/lpd270.c | 9 arch/arm/mach-pxa/magician.c | 8 +++ arch/arm/mach-pxa/mainstone.c | 13 - arch/arm/mach-pxa/mioa701.c| 8 +++ arch/arm/mach-pxa/palm27x.c| 8 +++ arch/arm/mach-pxa/palmtc.c | 8 +++ arch/arm/mach-pxa/palmte2.c| 9 arch/arm/mach-pxa/pcm990-baseboard.c | 8 +++ arch/arm/mach-pxa/raumfeld.c | 6 +++ arch/arm/mach-pxa/tavorevb.c | 11 arch/arm/mach-pxa/viper.c | 8 +++ arch/arm/mach-pxa/z2.c | 10 arch/arm/mach-pxa/zylonite.c | 7 +++ arch/arm/mach-s3c24xx/mach-h1940.c | 8 +++ arch/arm/mach-s3c24xx/mach-rx1950.c| 9 arch/arm/plat-samsung/dev-backlight.c | 9 arch/unicore32/kernel/puv3-nb0916.c| 9 drivers/video/backlight/pwm_bl.c | 59 ++ 32 files changed, 297 insertions(+), 11 deletions(-) -- 1.8.1.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 V4 6/9] ARM: mxs: Provide regulator to pwm-backlight
The pwm-backlight driver now takes a mandatory regulator that is gotten
during driver probe. Initialize a dummy regulator to satisfy this
requirement.
Signed-off-by: Andrew Chew ac...@nvidia.com
---
arch/arm/boot/dts/imx23-evk.dts | 6 ++
arch/arm/boot/dts/imx28-apf28dev.dts | 6 ++
arch/arm/boot/dts/imx28-cfa10049.dts | 6 ++
arch/arm/boot/dts/imx28-evk.dts | 6 ++
arch/arm/boot/dts/imx28-tx28.dts | 6 ++
5 files changed, 30 insertions(+)
diff --git a/arch/arm/boot/dts/imx23-evk.dts b/arch/arm/boot/dts/imx23-evk.dts
index 035c13f..e48e36c 100644
--- a/arch/arm/boot/dts/imx23-evk.dts
+++ b/arch/arm/boot/dts/imx23-evk.dts
@@ -97,10 +97,16 @@
};
};
+ bl_en: fixed-regulator {
+ compatible = regulator-fixed;
+ regulator-name = bl-en-supply;
+};
+
backlight {
compatible = pwm-backlight;
pwms = pwm 2 500;
brightness-levels = 0 4 8 16 32 64 128 255;
default-brightness-level = 6;
+ enable-supply = bl_en;
};
};
diff --git a/arch/arm/boot/dts/imx28-apf28dev.dts
b/arch/arm/boot/dts/imx28-apf28dev.dts
index 6d8865b..866e26f 100644
--- a/arch/arm/boot/dts/imx28-apf28dev.dts
+++ b/arch/arm/boot/dts/imx28-apf28dev.dts
@@ -144,11 +144,17 @@
};
};
+ bl_en: fixed-regulator {
+ compatible = regulator-fixed;
+ regulator-name = bl-en-supply;
+ };
+
backlight {
compatible = pwm-backlight;
pwms = pwm 3 191000;
brightness-levels = 0 4 8 16 32 64 128 255;
default-brightness-level = 6;
+ enable-supply = bl_en;
};
};
diff --git a/arch/arm/boot/dts/imx28-cfa10049.dts
b/arch/arm/boot/dts/imx28-cfa10049.dts
index a0d3e9f..a8477b6 100644
--- a/arch/arm/boot/dts/imx28-cfa10049.dts
+++ b/arch/arm/boot/dts/imx28-cfa10049.dts
@@ -299,10 +299,16 @@
rotary-encoder,relative-axis;
};
+ bl_en: fixed-regulator {
+ compatible = regulator-fixed;
+ regulator-name = bl-en-supply;
+ };
+
backlight {
compatible = pwm-backlight;
pwms = pwm 3 500;
brightness-levels = 0 4 8 16 32 64 128 255;
default-brightness-level = 6;
+ enable-supply = bl_en;
};
};
diff --git a/arch/arm/boot/dts/imx28-evk.dts b/arch/arm/boot/dts/imx28-evk.dts
index 2da316e..810f1e4 100644
--- a/arch/arm/boot/dts/imx28-evk.dts
+++ b/arch/arm/boot/dts/imx28-evk.dts
@@ -307,10 +307,16 @@
};
};
+ bl_en: fixed-regulator {
+ compatible = regulator-fixed;
+ regulator-name = bl-en-supply;
+ };
+
backlight {
compatible = pwm-backlight;
pwms = pwm 2 500;
brightness-levels = 0 4 8 16 32 64 128 255;
default-brightness-level = 6;
+ enable-supply = bl_en;
};
};
diff --git a/arch/arm/boot/dts/imx28-tx28.dts b/arch/arm/boot/dts/imx28-tx28.dts
index 37be532..ea3c88a 100644
--- a/arch/arm/boot/dts/imx28-tx28.dts
+++ b/arch/arm/boot/dts/imx28-tx28.dts
@@ -107,10 +107,16 @@
};
};
+ bl_en: fixed-regulator {
+ compatible = regulator-fixed;
+ regulator-name = bl-en-supply;
+ };
+
backlight {
compatible = pwm-backlight;
pwms = pwm 0 500;
brightness-levels = 0 4 8 16 32 64 128 255;
default-brightness-level = 6;
+ enable-supply = bl_en;
};
};
--
1.8.1.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 V4 7/9] ARM: vt8500: Provide regulator to pwm-backlight
The pwm-backlight driver now takes a mandatory regulator that is gotten
during driver probe. Initialize a dummy regulator to satisfy this
requirement.
Signed-off-by: Andrew Chew ac...@nvidia.com
---
arch/arm/boot/dts/wm8850-w70v2.dts | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/wm8850-w70v2.dts
b/arch/arm/boot/dts/wm8850-w70v2.dts
index fcc660c..47a0b1a 100644
--- a/arch/arm/boot/dts/wm8850-w70v2.dts
+++ b/arch/arm/boot/dts/wm8850-w70v2.dts
@@ -37,11 +37,17 @@
};
};
+ bl_en: fixed-regulator {
+ compatible = regulator-fixed;
+ regulator-name = bl-en-supply;
+ };
+
backlight {
compatible = pwm-backlight;
pwms = pwm 0 5 1;/* duty inverted */
brightness-levels = 0 40 60 80 100 130 190 255;
default-brightness-level = 5;
+ enable-supply = bl_en;
};
};
--
1.8.1.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 V4 1/9] ARM: OMAP: board-4430sdp: Provide regulator to pwm-backlight
The pwm-backlight driver now takes a mandatory regulator that is gotten
during driver probe. Initialize a dummy regulator to satisfy this
requirement.
Signed-off-by: Andrew Chew ac...@nvidia.com
Tested-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/mach-omap2/board-4430sdp.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index 35f3ad0..a01a39a 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -291,6 +291,10 @@ static struct platform_device sdp4430_leds_pwm = {
},
};
+/* Dummy regulator for pwm-backlight driver */
+static struct regulator_consumer_supply backlight_supply =
+ REGULATOR_SUPPLY(enable, pwm-backlight);
+
static struct platform_pwm_backlight_data sdp4430_backlight_data = {
.max_brightness = 127,
.dft_brightness = 127,
@@ -718,6 +722,8 @@ static void __init omap_4430sdp_init(void)
omap4_i2c_init();
omap_sfh7741prox_init();
+ regulator_register_always_on(-1, backlight-enable,
+backlight_supply, 1, 0);
platform_add_devices(sdp4430_devices, ARRAY_SIZE(sdp4430_devices));
omap_serial_init();
omap_sdrc_init(NULL, NULL);
--
1.8.1.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 V4 9/9] pwm_bl: Add mandatory backlight enable regulator
Many backlights need to be explicitly enabled. Typically, this is done
with a GPIO. For flexibility, we generalize the enable mechanism to a
regulator.
If an enable regulator is not needed, then a dummy regulator can be given
to the backlight driver. If a GPIO is used to enable the backlight,
then a fixed regulator can be instantiated to control the GPIO.
The backlight enable regulator can be specified in the device tree node
for the backlight, or can be done with legacy board setup code in the
usual way.
Signed-off-by: Andrew Chew ac...@nvidia.com
Reviewed-by: Alexandre Courbot acour...@nvidia.com
Tested-by: Peter Ujfalusi peter.ujfal...@ti.com
---
.../bindings/video/backlight/pwm-backlight.txt | 14 +
drivers/video/backlight/pwm_bl.c | 59 ++
2 files changed, 63 insertions(+), 10 deletions(-)
diff --git
a/Documentation/devicetree/bindings/video/backlight/pwm-backlight.txt
b/Documentation/devicetree/bindings/video/backlight/pwm-backlight.txt
index 1e4fc72..7e2e089 100644
--- a/Documentation/devicetree/bindings/video/backlight/pwm-backlight.txt
+++ b/Documentation/devicetree/bindings/video/backlight/pwm-backlight.txt
@@ -10,6 +10,11 @@ Required properties:
last value in the array represents a 100% duty cycle (brightest).
- default-brightness-level: the default brightness level (index into the
array defined by the brightness-levels property)
+ - enable-supply: A phandle to the regulator device tree node. This
+ regulator will be turned on and off as the pwm is enabled and disabled.
+ Many backlights are enabled via a GPIO. In this case, we instantiate
+ a fixed regulator and give that to enable-supply. If a regulator
+ is not needed, then provide a dummy fixed regulator.
Optional properties:
- pwm-names: a list of names for the PWM devices specified in the
@@ -19,10 +24,19 @@ Optional properties:
Example:
+ bl_en: fixed-regulator {
+compatible = regulator-fixed;
+regulator-name = bl-en-supply;
+regulator-boot-on;
+gpio = some_gpio;
+enable-active-high;
+ };
+
backlight {
compatible = pwm-backlight;
pwms = pwm 0 500;
brightness-levels = 0 4 8 16 32 64 128 255;
default-brightness-level = 6;
+ enable-supply = bl_en;
};
diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
index 1fea627..e4922f5 100644
--- a/drivers/video/backlight/pwm_bl.c
+++ b/drivers/video/backlight/pwm_bl.c
@@ -20,10 +20,13 @@
#include linux/pwm.h
#include linux/pwm_backlight.h
#include linux/slab.h
+#include linux/regulator/consumer.h
struct pwm_bl_data {
struct pwm_device *pwm;
struct device *dev;
+ boolenabled;
+ struct regulator*enable_supply;
unsigned intperiod;
unsigned intlth_brightness;
unsigned int*levels;
@@ -35,6 +38,42 @@ struct pwm_bl_data {
void(*exit)(struct device *);
};
+static void pwm_backlight_enable(struct backlight_device *bl)
+{
+ struct pwm_bl_data *pb = dev_get_drvdata(bl-dev);
+ int ret;
+
+ /* Bail if we are already enabled. */
+ if (pb-enabled)
+ return;
+
+ pwm_enable(pb-pwm);
+
+ ret = regulator_enable(pb-enable_supply);
+ if (ret)
+ dev_warn(bl-dev, Failed to enable regulator: %d, ret);
+
+ pb-enabled = true;
+}
+
+static void pwm_backlight_disable(struct backlight_device *bl)
+{
+ struct pwm_bl_data *pb = dev_get_drvdata(bl-dev);
+ int ret;
+
+ /* Bail if we are already disabled. */
+ if (!pb-enabled)
+ return;
+
+ ret = regulator_disable(pb-enable_supply);
+ if (ret)
+ dev_warn(bl-dev, Failed to disable regulator: %d, ret);
+
+ pwm_disable(pb-pwm);
+
+ pb-enabled = false;
+}
+
static int pwm_backlight_update_status(struct backlight_device *bl)
{
struct pwm_bl_data *pb = bl_get_data(bl);
@@ -51,7 +90,7 @@ static int pwm_backlight_update_status(struct
backlight_device *bl)
if (brightness == 0) {
pwm_config(pb-pwm, 0, pb-period);
- pwm_disable(pb-pwm);
+ pwm_backlight_disable(bl);
} else {
int duty_cycle;
@@ -65,7 +104,7 @@ static int pwm_backlight_update_status(struct
backlight_device *bl)
duty_cycle = pb-lth_brightness +
(duty_cycle * (pb-period - pb-lth_brightness) / max);
pwm_config(pb-pwm, duty_cycle, pb-period);
- pwm_enable(pb-pwm);
+ pwm_backlight_enable(bl);
}
if (pb-notify_after)
@@ -138,12 +177,6 @@ static int pwm_backlight_parse_dt(struct device *dev,
[PATCH V4 2/9] ARM: S3C24XX: Provide regulator to pwm-backlight
The pwm-backlight driver now takes a mandatory regulator that is gotten
during driver probe. Initialize a dummy regulator to satisfy this
requirement.
Signed-off-by: Andrew Chew ac...@nvidia.com
---
arch/arm/mach-s3c24xx/mach-h1940.c | 8
arch/arm/mach-s3c24xx/mach-rx1950.c | 9 +
2 files changed, 17 insertions(+)
diff --git a/arch/arm/mach-s3c24xx/mach-h1940.c
b/arch/arm/mach-s3c24xx/mach-h1940.c
index 8dd6601..d2594b8 100644
--- a/arch/arm/mach-s3c24xx/mach-h1940.c
+++ b/arch/arm/mach-s3c24xx/mach-h1940.c
@@ -24,6 +24,8 @@
#include linux/gpio.h
#include linux/input.h
#include linux/gpio_keys.h
+#include linux/regulator/machine.h
+#include linux/regulator/fixed.h
#include linux/pwm_backlight.h
#include linux/i2c.h
#include linux/leds.h
@@ -497,6 +499,9 @@ static void h1940_backlight_exit(struct device *dev)
gpio_set_value(H1940_LATCH_MAX1698_nSHUTDOWN, 0);
}
+/* Dummy regulator for pwm-backlight driver */
+static struct regulator_consumer_supply backlight_supply =
+ REGULATOR_SUPPLY(enable, pwm-backlight);
static struct platform_pwm_backlight_data backlight_data = {
.pwm_id = 0,
@@ -720,6 +725,9 @@ static void __init h1940_init(void)
gpio_request(H1940_LATCH_SD_POWER, SD power);
gpio_direction_output(H1940_LATCH_SD_POWER, 0);
+ regulator_register_always_on(-1, backlight-enable,
+backlight_supply, 1, 0);
+
platform_add_devices(h1940_devices, ARRAY_SIZE(h1940_devices));
gpio_request(S3C2410_GPA(1), Red LED blink);
diff --git a/arch/arm/mach-s3c24xx/mach-rx1950.c
b/arch/arm/mach-s3c24xx/mach-rx1950.c
index e4d67a3..ac674b6 100644
--- a/arch/arm/mach-s3c24xx/mach-rx1950.c
+++ b/arch/arm/mach-s3c24xx/mach-rx1950.c
@@ -25,6 +25,8 @@
#include linux/gpio_keys.h
#include linux/device.h
#include linux/pda_power.h
+#include linux/regulator/machine.h
+#include linux/regulator/fixed.h
#include linux/pwm_backlight.h
#include linux/pwm.h
#include linux/s3c_adc_battery.h
@@ -518,6 +520,10 @@ static int rx1950_backlight_notify(struct device *dev, int
brightness)
return brightness;
}
+/* Dummy regulator for pwm-backlight driver */
+static struct regulator_consumer_supply backlight_supply =
+ REGULATOR_SUPPLY(enable, pwm-backlight);
+
static struct platform_pwm_backlight_data rx1950_backlight_data = {
.pwm_id = 0,
.max_brightness = 24,
@@ -795,6 +801,9 @@ static void __init rx1950_init_machine(void)
gpio_direction_output(S3C2410_GPA(4), 0);
gpio_direction_output(S3C2410_GPJ(6), 0);
+ regulator_register_always_on(-1, backlight-enable,
+backlight_supply, 1, 0);
+
platform_add_devices(rx1950_devices, ARRAY_SIZE(rx1950_devices));
i2c_register_board_info(0, rx1950_i2c_devices,
--
1.8.1.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 V4 5/9] unicore32: Provide regulator to pwm-backlight
The pwm-backlight driver now takes a mandatory regulator that is gotten
during driver probe. Initialize a dummy regulator to satisfy this
requirement.
Signed-off-by: Andrew Chew ac...@nvidia.com
---
arch/unicore32/kernel/puv3-nb0916.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/unicore32/kernel/puv3-nb0916.c
b/arch/unicore32/kernel/puv3-nb0916.c
index 181108b..ff84d77 100644
--- a/arch/unicore32/kernel/puv3-nb0916.c
+++ b/arch/unicore32/kernel/puv3-nb0916.c
@@ -19,6 +19,8 @@
#include linux/reboot.h
#include linux/interrupt.h
#include linux/i2c.h
+#include linux/regulator/machine.h
+#include linux/regulator/fixed.h
#include linux/pwm_backlight.h
#include linux/gpio.h
#include linux/gpio_keys.h
@@ -49,6 +51,10 @@ static struct resource puv3_i2c_resources[] = {
}
};
+/* Dummy regulator for pwm-backlight driver */
+static struct regulator_consumer_supply backlight_supply =
+ REGULATOR_SUPPLY(enable, pwm-backlight);
+
static struct platform_pwm_backlight_data nb0916_backlight_data = {
.pwm_id = 0,
.max_brightness = 100,
@@ -111,6 +117,9 @@ int __init mach_nb0916_init(void)
platform_device_register_simple(PKUnity-v3-I2C, -1,
puv3_i2c_resources, ARRAY_SIZE(puv3_i2c_resources));
+ regulator_register_always_on(-1, backlight-enable,
+backlight_supply, 1, 0);
+
platform_device_register_data(platform_bus, pwm-backlight, -1,
nb0916_backlight_data, sizeof(nb0916_backlight_data));
--
1.8.1.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 V4 8/9] ARM: tegra: Provide regulator to pwm-backlight
The pwm-backlight driver now takes a mandatory regulator that is gotten
during driver probe. Initialize a dummy regulator to satisfy this
requirement.
Signed-off-by: Andrew Chew ac...@nvidia.com
---
arch/arm/boot/dts/tegra20-medcom-wide.dts | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/tegra20-medcom-wide.dts
b/arch/arm/boot/dts/tegra20-medcom-wide.dts
index a2d6d65..bf7fdd7 100644
--- a/arch/arm/boot/dts/tegra20-medcom-wide.dts
+++ b/arch/arm/boot/dts/tegra20-medcom-wide.dts
@@ -26,12 +26,18 @@
};
};
+ bl_en: fixed-regulator {
+ compatible = regulator-fixed;
+ regulator-name = bl-en-supply;
+ };
+
backlight {
compatible = pwm-backlight;
pwms = pwm 0 500;
brightness-levels = 0 4 8 16 32 64 128 255;
default-brightness-level = 6;
+ enable-supply = bl_en;
};
sound {
--
1.8.1.5
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V4 6/9] ARM: mxs: Provide regulator to pwm-backlight
Dear Andrew Chew, The pwm-backlight driver now takes a mandatory regulator that is gotten during driver probe. Initialize a dummy regulator to satisfy this requirement. Signed-off-by: Andrew Chew ac...@nvidia.com Do we really need a mandatory regulator? Why can't it be optional? Best regards, Marek Vasut -- To unsubscribe from this list: send the line unsubscribe linux-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 00/16] clk: exynos4/5: migrate to common clock framework
Am Dienstag, 19. März 2013, 19:49:38 schrieb Mike Turquette: Quoting Thomas Abraham (2013-02-18 00:21:10) Changes since v5: - Squashed several Exynos4 fixes patch from Tomasz Figa - Included support for Exynos5250 and Exynos5440, thus converting all Exynos4 and Exynos5 platforms to common clock framework. - Depends on the following patch series. - http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg15849 .html - http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg15852 .html Changes since v4: - Rebased to linux-3.8-rc1. Changes since v3: - Includes changes suggested by Tomasz Figa tomasz.f...@gmail.com This patch series migrates the Samsung Exynos4/5 SoC clock code to adopt the common clock framework. The use of Samsung specific clock structures has been removed and all board support code has been updated. imx-style of clock registration and lookup has been adopted for device tree based exynos4/5 platforms. Thomas, Are you planning a V7 series which includes the clock alias bits from patch #1? Kukjin has already applied this series into the linux-samsung tree [0]. The alias changes are available in the series clk: samsung: pm fixes and multiple aliases from last wednesday to on top, which you should hopefully also have received. This v2 series implements the changes discussed in the previous v1 clk: samsung: small fixes and enhancements from 2013-03-12, but didn't get any responses yet. Heiko [0] https://git.kernel.org/cgit/linux/kernel/git/kgene/linux-samsung.git/log/?h=next/clk-exynos -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: add interrupt-names property to get interrupt resource by name
On 03/18/2013 04:50 PM, Rob Herring wrote: On 03/13/2013 05:42 PM, Sylwester Nawrocki wrote: On 03/13/2013 03:39 PM, Rob Herring wrote: I fail to see what the hack is. The order of interrupt properties must be defined by the binding. interrupt-names is auxiliary data and must not be required by an OS. It is clear that the order of the interrupts must be defined by the bindings. But how usefulresource-names properties are when we cannot define them as required ? If an OS cannot rely on them then it must use some other, reliable, method to identify the resources, e.g. by hard coding the indexes. If we have to do it then why even bother with theresource-names properties ? I can see interrupt-names property specified as required in at least 2 bindings' documentation and all bindings having reg-names property define it as required. Are they wrong them ? You can require the name for a binding definition, but that does not remove the requirement that the order and index of interrupts also be defined by the binding. Then it is up to the OS to use names or hard-coded indexes. Hard-coded indexes are not a hack. This is how FDT and OF are defined to work. OK, that makes it all crystal clear for me, thanks. I'm still not clear how changing the order of the interrupts removes a hack. Originally the binding in question was not specifying the interrupt order at all. And the drivers required order of the interrupt resources different than in what they were normally defined in the SoC interrupt combiner. So I suggested to use the interrupt-names property to make it all more explicit and less error prone. I once had to fix the order of the FIMD interrupts in the device tree to make the display work, since I used a patch where the interrupts were listed in the IRQ combiner order, and not the order expected by the driver. I wasn't really clear then whether the order of interrupts needs to be still fixed by the binding when the interrupt-names property was used. That said I don't think there was previously any hack there. Just an undocumented expected order of the interrupts in DT, different than the normal order in the IRQ combiner. So it is really hard to agree with what's written in the $subject patch description as it is now. 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 V4 6/9] ARM: mxs: Provide regulator to pwm-backlight
On 03/19/2013 03:27 PM, Marek Vasut wrote: Dear Andrew Chew, The pwm-backlight driver now takes a mandatory regulator that is gotten during driver probe. Initialize a dummy regulator to satisfy this requirement. Signed-off-by: Andrew Chew ac...@nvidia.com Do we really need a mandatory regulator? Why can't it be optional? IIRC, the previous advice I've seen is that if a device (driver) uses a regulator, it must /require/ a regulator, and if a particular board doesn't actually have a SW-controlled regulator, then a fixed- or dummy- regulator should be provided to satisfy this requirement. CC'ing Mark Brown to make sure I really do Recall Correctly. -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: add interrupt-names property to get interrupt resource by name
On 03/19/2013 12:05 AM, Stephen Warren wrote: On 03/18/2013 04:27 PM, Rob Herring wrote: On 03/18/2013 01:11 PM, Stephen Warren wrote: On 03/18/2013 09:50 AM, Rob Herring wrote: On 03/13/2013 05:42 PM, Sylwester Nawrocki wrote: Rob, On 03/13/2013 03:39 PM, Rob Herring wrote: I fail to see what the hack is. The order of interrupt properties must be defined by the binding. interrupt-names is auxiliary data and must not be required by an OS. Is that true for all foo-names properties, or only for interrupt-names? I was under the impression that foo-names was specifically invented so that the order of the entries didn't matter, and instead they could be requested by name. I think it depends on the specific name the property is tied too. For interrupt and reg properties which have a long history and convention, the order should be defined. IIRC, this was Grant's position too. For new bindings, perhaps we can be more lenient. OK, that makes sense for interrupts/reg. Can we decide that clock-namess are new-style and that order is not significant? I guess gpio-names too? I guess this should be documented in whatever binding describes the core interrupts/reg-names/gpio-names/clock-names/dma-names properties. It certainly would be useful to have it documented somewhere. Not sure if resource-names.txt would be a good place to have more information about the order for each property. -- To unsubscribe from this list: send the line unsubscribe linux-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 00/16] clk: exynos4/5: migrate to common clock framework
Mike Turquette wrote: [...] Thomas, Are you planning a V7 series which includes the clock alias bits from patch #1? Kukjin has already applied this series into the linux-samsung tree [0]. Thanks, Heiko. Mike, yes I did, as we discussed before. Since I missed in last window for v3.9, so I merged every common clock stuff for exynos into samsung tree in the early 3.9-rc time for v3.10. That really is too much code to go into drivers/clk without my ACK. I have not made much noise about this in the past but there has been more and more bonus code slipping into drivers/clk each merge window. Let's not do that any more. Hmm, I remember you already agreed on previous version, and I thought if any further codes are required, we could do it on top of that. http://lists.infradead.org/pipermail/linux-arm-kernel/2013-January/143429.html However, if you don't want current codes to be sent to upstream, let me know, but I don't think it would be better to us though. Thanks. - Kukjin -- To unsubscribe from this list: send the line unsubscribe linux-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 0/9] Add mandatory regulator for all users of pwm-backlight.
On Tue, Mar 19, 2013 at 11:59:24AM -0700, Andrew Chew wrote: Many backlights are enabled via GPIO. We can generalize the GPIO to a fixed regulator. I think we should push the series of Runtime Interpreted Power Sequences moving forward, which should be useful this case and many other cases as well. http://thread.gmane.org/gmane.linux.kernel/1395912 Shawn -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RE: [PATCH v6 00/16] clk: exynos4/5: migrate to common clock framework
Quoting Kukjin Kim (2013-03-19 17:00:09) Mike Turquette wrote: [...] Thomas, Are you planning a V7 series which includes the clock alias bits from patch #1? Kukjin has already applied this series into the linux-samsung tree [0]. Thanks, Heiko. Mike, yes I did, as we discussed before. Since I missed in last window for v3.9, so I merged every common clock stuff for exynos into samsung tree in the early 3.9-rc time for v3.10. That really is too much code to go into drivers/clk without my ACK. I have not made much noise about this in the past but there has been more and more bonus code slipping into drivers/clk each merge window. Let's not do that any more. Hmm, I remember you already agreed on previous version, and I thought if any further codes are required, we could do it on top of that. http://lists.infradead.org/pipermail/linux-arm-kernel/2013-January/143429.html In the email you linked to my use of the word merged did not imply an ACK. I was asking about merging the two separate exynos4 and exynos5 ccf development efforts together. Furthermore if I *had* agreed on the previous version it would still have been appropriate to put my Acked-by on those patches, which is clearly missing today. However, if you don't want current codes to be sent to upstream, let me know, but I don't think it would be better to us though. No, I am not asking you to revert/drop the patches, but I am using this as a public example. Regards, Mike Thanks. - Kukjin -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: add interrupt-names property to get interrupt resource by name
HI, On Wed, Mar 20, 2013 at 3:10 AM, Sylwester Nawrocki sylvester.nawro...@gmail.com wrote: On 03/18/2013 04:50 PM, Rob Herring wrote: On 03/13/2013 05:42 PM, Sylwester Nawrocki wrote: On 03/13/2013 03:39 PM, Rob Herring wrote: I fail to see what the hack is. The order of interrupt properties must be defined by the binding. interrupt-names is auxiliary data and must not be required by an OS. It is clear that the order of the interrupts must be defined by the bindings. But how usefulresource-names properties are when we cannot define them as required ? If an OS cannot rely on them then it must use some other, reliable, method to identify the resources, e.g. by hard coding the indexes. If we have to do it then why even bother with theresource-names properties ? I can see interrupt-names property specified as required in at least 2 bindings' documentation and all bindings having reg-names property define it as required. Are they wrong them ? You can require the name for a binding definition, but that does not remove the requirement that the order and index of interrupts also be defined by the binding. Then it is up to the OS to use names or hard-coded indexes. Hard-coded indexes are not a hack. This is how FDT and OF are defined to work. OK, that makes it all crystal clear for me, thanks. I'm still not clear how changing the order of the interrupts removes a hack. Originally the binding in question was not specifying the interrupt order at all. And the drivers required order of the interrupt resources different than in what they were normally defined in the SoC interrupt combiner. So I suggested to use the interrupt-names property to make it all more explicit and less error prone. I once had to fix the order of the FIMD interrupts in the device tree to make the display work, since I used a patch where the interrupts were listed in the IRQ combiner order, and not the order expected by the driver. I wasn't really clear then whether the order of interrupts needs to be still fixed by the binding when the interrupt-names property was used. That said I don't think there was previously any hack there. Just an undocumented expected order of the interrupts in DT, different than the normal order in the IRQ combiner. So it is really hard to agree with what's written in the $subject patch description as it is now. Yes, there was NO hack as such earlier, just the documentation was not clear. But IMO, as suggested by Sylwester using interrupt-names property makes it more explicit and less error prone. Regarding this patch, it will be abandoned, Leela will post a single patch by squash this patch and https://patchwork.kernel.org/patch/2184981/ 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 -- To unsubscribe from this list: send the line unsubscribe linux-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: RE: [PATCH v6 00/16] clk: exynos4/5: migrate to common clock framework
Mike Turquette wrote: Quoting Kukjin Kim (2013-03-19 17:00:09) Mike Turquette wrote: [...] Thomas, Are you planning a V7 series which includes the clock alias bits from patch #1? Kukjin has already applied this series into the linux-samsung tree [0]. Thanks, Heiko. Mike, yes I did, as we discussed before. Since I missed in last window for v3.9, so I merged every common clock stuff for exynos into samsung tree in the early 3.9-rc time for v3.10. That really is too much code to go into drivers/clk without my ACK. I have not made much noise about this in the past but there has been more and more bonus code slipping into drivers/clk each merge window. Let's not do that any more. Hmm, I remember you already agreed on previous version, and I thought if any further codes are required, we could do it on top of that. http://lists.infradead.org/pipermail/linux-arm-kernel/2013- January/143429.html In the email you linked to my use of the word merged did not imply an ACK. I was asking about merging the two separate exynos4 and exynos5 ccf development efforts together. OK, I see. Furthermore if I *had* agreed on the previous version it would still have been appropriate to put my Acked-by on those patches, which is clearly missing today. BTW, how about following? http://www.spinics.net/lists/arm-kernel/msg210266.html In my understanding, it should be your agreement, it cannot be 'ack' though. However, if you don't want current codes to be sent to upstream, let me know, but I don't think it would be better to us though. No, I am not asking you to revert/drop the patches, but I am using this as a public example. What's the 'public example'? As I linked, you already said 'sounds good to me' on my asking. - Kukjin -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
