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,
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
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
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
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;
+
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.
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.
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
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.
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
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
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
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
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.
-
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
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 ++
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
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 ++
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,
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
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
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
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
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
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
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
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
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
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
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,
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
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].
32 matches
Mail list logo
