Fix the bug in modifying the interrupt enable register.
Signed-off-by: Tony K Nadackal
---
drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c
b/drivers/media/platform/s5p-jpe
Fimp_jpeg used in Exynos7 is a revised version. Some register
configurations are slightly different from JPEG in Exynos4.
Added one more variant SJPEG_EXYNOS7 to handle these differences.
Signed-off-by: Tony K Nadackal
---
.../bindings/media/exynos-jpeg-codec.txt | 2 +-
drivers/media
This patch series adds support for Exynos7 JPEG variant, which is mostly
same as Exynos4 JPEG variants with few register configuration differences.
At the same time it modifies #define based JPEG variant macros into enum.
Patch 1/2 fixes possible bug in setting INT EN register,
where EXYNOS4_INT_EN
On 19 December 2014 at 03:03, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
>
> Having switched over all of the users of CONFIG_PM_RUNTIME to use
> CONFIG_PM directly, turn the latter into a user-selectable option
> and drop the former entirely from the tree.
>
> Signed-off-by: Rafael J. Wys
Dear Myungjoo,
On 12/19/2014 11:11 AM, MyungJoo Ham wrote:
>>
>> Dear Myungjoo,
>>
>> Thanks for your review.
>>
>> On 12/18/2014 03:24 PM, MyungJoo Ham wrote:
>>> Hi Chanwoo,
>>>
>>> I love the idea and I now have a little mechanical issues in your code.
>>>
---
drivers/devfreq/Kco
Hi Jacek,
On Wednesday, December 17, 2014 7:46 PM Jacek Anaszewski wrote,
> Hi Tony,
>
> Thanks for the patches.
>
Thanks for the review.
> Please process them with scripts/checkpatch.pl as you will be submitting the
next
> version - they contain many coding style related issues.
>
I ran che
>
> Dear Myungjoo,
>
> Thanks for your review.
>
> On 12/18/2014 03:24 PM, MyungJoo Ham wrote:
> > Hi Chanwoo,
> >
> > I love the idea and I now have a little mechanical issues in your code.
> >
> >> ---
> >> drivers/devfreq/Kconfig | 2 +
> >> drivers/devfreq/Makefile|
On Thursday, December 18, 2014 11:05:18 AM Sylwester Nawrocki wrote:
> On 18/12/14 01:58, Rafael J. Wysocki wrote:
> What's needed to solve this problem is a generalized way to have runtime
> > >> PM dependencies between devices. Runtime PM already automatically
> > >> handles paren
From: Rafael J. Wysocki
Having switched over all of the users of CONFIG_PM_RUNTIME to use
CONFIG_PM directly, turn the latter into a user-selectable option
and drop the former entirely from the tree.
Signed-off-by: Rafael J. Wysocki
---
arch/arm/configs/ape6evm_defconfig |2 +-
arc
On Thursday 18 December 2014 22:36:14 Laurent Pinchart wrote:
>
> > (currently only on ARM64, not ARM32, until someone adds support). I can see
> > your point regarding machines that have a mandatory IOMMU with no fallback
> > when there is no driver, but we can support them by making the iommu dr
On Wed, Dec 17, 2014 at 10:58 PM, Mike Turquette wrote:
> Quoting Mike Turquette (2014-12-17 07:23:22)
>> Quoting Krzysztof Kozlowski (2014-12-16 00:20:15)
>> > On pon, 2014-12-15 at 14:26 -0800, Kevin Hilman wrote:
>> > > Kevin Hilman writes:
>> > >
>> > > > Sylwester Nawrocki writes:
>> > > >
Geert Uytterhoeven writes:
> On Tue, Dec 16, 2014 at 11:10 PM, Kevin Hilman wrote:
>> At a deeper level, the problem with this approach is that this is more
>> generically a runtime PM dependency problem, not a genpd problem. For
>> example, what happens when the same kind of dependency exists
Hi Arnd,
On Wednesday 17 December 2014 16:56:53 Arnd Bergmann wrote:
> On Wednesday 17 December 2014 15:53:25 Lucas Stach wrote:
> > Am Mittwoch, den 17.12.2014, 15:27 +0100 schrieb Arnd Bergmann:
> >> On Wednesday 17 December 2014 01:24:42 Laurent Pinchart wrote:
> >>> If we forbid the IOMMU driv
Hi Stefan,
Am Donnerstag, 18. Dezember 2014, 14:43:01 schrieb Stefan Hengelein:
> So you actually tested the code I removed in the patch? can you
> provide a configuration that compiles that piece of code?
Yep, one of my boards (Asus eeeReader DR-900) was actually able to transmit
stuff via the l
On Thu, Dec 18, 2014 at 11:58:51AM -0200, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> The atomic helper to disable planes also uses exynos_update_plane() to
> disable plane so we had to adapt it to both commit and disable planes.
>
> A check for NULL CRTC was added to exynos_plane_mode_se
On Thu, Dec 18, 2014 at 9:34 AM, Vasily Khoruzhick wrote:
> Can I change pin function after gpio was requested? In low-power state
> (i.e. when display is disabled) it's gpio driving some level,
> and in active state it's some LCD controller pin (don't remember which
> one exactly)
Please read t
On 12/18/2014 02:13 AM, Lukasz Majewski wrote:
Several new properties to allow PWM fan working as a cooling device have been
combined into this single commit.
Signed-off-by: Lukasz Majewski
---
.../devicetree/bindings/hwmon/pwm-fan.txt | 28 ++
1 file changed, 28
On 18/12/14 15:48, nick wrote:
> Lucas,
> That's fair do you known of anyone who does have the hardware so we can test
> my patch. If you do then we can get this fixed rather
> easily.
> Cheers Nick
>
> On 2014-12-18 08:39 AM, Lucas Stach wrote:
>> Am Donnerstag, den 18.12.2014, 08:35 -0500 schr
From: Gustavo Padovan
Set CRTC, planes and connectors to use the default implementations from
the atomic helper library. The helpers will work to keep track of state
for each DRM object.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/bridge/ptn3460.c | 4
drivers/gpu/drm/
From: Gustavo Padovan
Use drm_atomic_set_fb_for_plane() in the legacy page_flip path to keep
track of the framebuffer pointer and reference.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos/exynos_drm_crtc.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/exyno
From: Gustavo Padovan
Add CRTC callbacks .atomic_begin() .atomic_flush(). On exynos they
unprotect the windows before the commit and protects it after based on
a plane mask tha store which plane will be updated.
For that we create two new exynos_crtc callbacks: .win_protect() and
.win_unprotect(
From: Gustavo Padovan
It is not used outside of the plane scope anymore.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos/exynos_drm_plane.c | 11 ++-
drivers/gpu/drm/exynos/exynos_drm_plane.h | 5 -
2 files changed, 6 insertions(+), 10 deletions(-)
diff --git a/drivers/
From: Gustavo Padovan
The new atomic infrastructure needs the .mode_set_nofb() callback to
update CRTC timings before setting any plane.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos/exynos_drm_crtc.c | 61
1 file changed, 14 insertions(+), 47 delet
From: Gustavo Padovan
It is no longer used anywhere.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos/exynos_drm_drv.h | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index 4c930d0..d490b49 100644
From: Gustavo Padovan
Rip out the check from exynos_update_plane() and create
exynos_check_plane() for the check phase enabling use to use
the atomic helpers to call our check and update phases when updating
planes.
Update all users of exynos_update_plane() accordingly to call
exynos_check_plane
From: Gustavo Padovan
The atomic helper to disable planes also uses exynos_update_plane() to
disable plane so we had to adapt it to both commit and disable planes.
A check for NULL CRTC was added to exynos_plane_mode_set() since planes
to be disabled have plane_state->crtc set to NULL.
Also win
From: Gustavo Padovan
We can safely use the mode stored in the crtc.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos/exynos_drm_crtc.c | 5 -
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 12 +---
2 files changed, 1 insertion(+), 16 deletions(-)
diff --git a/drivers/gpu/dr
From: Gustavo Padovan
Split update plane in two parts, an initial check part that can fail
and the update part that can't fail.
This is a important step for the upcoming atomic modesetting support.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos/exynos_drm_crtc.c | 11 --
d
From: Gustavo Padovan
exynos_drm_manager was just a redundant struct to represent the crtc as
well. In this commit we merge exynos_drm_manager into exynos_drm_crtc to
remove an unnecessary level of indirection easing the understand of the
flow on exynos.
Signed-off-by: Gustavo Padovan
---
driv
From: Gustavo Padovan
manager-drm_dev is only accessed by exynos_drm_crtc_create() so this patch
pass drm_dev as argument on exynos_drm_crtc_create() and remove it from
struct exynos_drm_manager.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos/exynos_drm_crtc.c | 9 +
drivers
From: Gustavo Padovan
'type' is now part of the struct exynos_drm_crtc. This is just another
step in the struct exynos_drm_manager removal.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos/exynos_drm_crtc.c | 6 --
drivers/gpu/drm/exynos/exynos_drm_crtc.h | 3 ++-
drivers/gpu/drm/
From: Gustavo Padovan
Get the pipe value from a parameter instead of getting it from
manager->pipe. We are removing manager->pipe.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos/exynos_drm_crtc.c | 8
drivers/gpu/drm/exynos/exynos_drm_crtc.h | 2 +-
drivers/gpu/drm/exynos/e
From: Gustavo Padovan
It is not longer used. This is part of the process of removing
struct exynos_drm_manager entirely.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos/exynos_drm_crtc.c | 2 +-
drivers/gpu/drm/exynos/exynos_drm_drv.h | 2 --
drivers/gpu/drm/exynos/exynos_drm_fimd.c
From: Gustavo Padovan
Avoid an extra call to exynos_drm_crtc_mode_set_commit() that only calls
exynos_update_plane().
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos/exynos_drm_crtc.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/exynos/e
From: Gustavo Padovan
This was just as extra chain in the call stack. We just rename it to
_set_base() and let it do everything alone.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos/exynos_drm_crtc.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/
From: Gustavo Padovan
DPMS settings should only be changed by a full modeset.
exynos_plane_update() should only care about updating the planes itself
and nothing else.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos/exynos_drm_plane.c | 1 -
1 file changed, 1 deletion(-)
diff --git
From: Gustavo Padovan
struct exynos_drm_overlay has no practical advantage nor serves as
important piece of the exynos API design. The only place it was used
was inside the struct exynos_plane which was just causing a extra
access overhead. Users had to access the overlay first and just then
get
From: Gustavo Padovan
'base' is more widely used name in the drm subsystem for the base object.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos/exynos_drm_crtc.c | 4 ++--
drivers/gpu/drm/exynos/exynos_drm_drv.h | 7 +++
2 files changed, 5 insertions(+), 6 deletions(-)
diff --g
From: Gustavo Padovan
DPMS only makes sense when the mode changes, for plane update changes do
not perform any dpms operation.
This move places the win_commit() and commit() calls directly in the code
instead of calling exynos_drm_crtc_commit() thus avoiding DPMS operations.
Signed-off-by: Gust
From: Gustavo Padovan
We set it in the beginning of the function, thus no need to set it at
initialization.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
From: Gustavo Padovan
We can safely use the exynos_update_plane() to update the plane
framebuffer for both the overlay and primary planes.
Note that this patch removes a call to manager->ops->commit() in
exynos_drm_crtc_mode_set_commit(). The commit() call is used only by the
fimd driver to set
From: Gustavo Padovan
vidi_commit does nothing, remove it and its callers.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos/exynos_drm_vidi.c | 12
1 file changed, 12 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
b/drivers/gpu/drm/exynos/exynos_drm_
From: Gustavo Padovan
It's doing nothing but calling exynos_crtc->ops->win_commit(), so let's
call this directly to avoid extra layers of abstraction.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos/exynos_drm_crtc.c | 4 +++-
drivers/gpu/drm/exynos/exynos_drm_plane.c | 15 +---
From: Gustavo Padovan
Let other pieces of the driver access struct exynos_drm_crtc as well.
struct exynos_drm_manager will be merged into struct exynos_drm_crtc, in
the sense we will move all its members to exynos_drm_crtc, so to start
this conversion exynos_drm_crtc need to be exposed as well.
From: Gustavo Padovan
With this change we allow other pieces of the code to use this macro.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos/exynos_drm_crtc.c | 3 ---
drivers/gpu/drm/exynos/exynos_drm_drv.h | 3 +++
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/driv
From: Daniel Kurtz
A framebuffer gets committed to FIMD's default window like this:
exynos_drm_crtc_update()
exynos_plane_commit()
fimd_win_commit()
fimd_win_commit() programs BUF_START[0]. At each vblank, FIMD hardware
copies the value from BUF_START to BUF_START_S (BUF_START's shadow
re
From: Gustavo Padovan
This functions were doing nothing but calling a manager op function,
so remove them and call the manager directly.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos/exynos_drm_crtc.c | 33 ---
drivers/gpu/drm/exynos/exynos_drm_plane.c
From: Gustavo Padovan
Hi,
In this series:
- fix to FIMD pageflips, only finish pageflips if START == START_S.
- remove struct exynos_drm_overlay and struct exynos_drm_manager.
exynos_drm_overlay was merged with exynos_drm_plane and exynos_drm_manager
with exynos_drm_crtc removing two extra
So you actually tested the code I removed in the patch? can you
provide a configuration that compiles that piece of code?
2014-12-17 17:16 GMT+01:00 Heiko Stübner :
> Am Mittwoch, 17. Dezember 2014, 16:52:40 schrieb Arnd Bergmann:
>> On Wednesday 17 December 2014 16:40:37 Stefan Hengelein wrote:
>
On Thu, Dec 18, 2014 at 5:34 PM, Vasily Khoruzhick wrote:
> On Thu, Dec 18, 2014 at 10:52 AM, Uwe Kleine-König
> wrote:
>> Hello,
>
> Hi Uwe,
>
>> [Cc += linusw, linux-gpio]
>>
>> On Wed, Dec 17, 2014 at 10:04:24PM +0300, Vasily Khoruzhick wrote:
>>> I'd like to port several s3c24xx to DT, and I'
Am Donnerstag, den 18.12.2014, 08:35 -0500 schrieb nick:
> Krzysztof,
> If we look at the code for this function, it already is handling the data
> correctly. In addition the locks
> seem to be better protection then msleep. Further more is no reason for this
> delay as we are neither resetting
On Thu, 2014-12-18 at 11:13 +0100, Lukasz Majewski wrote:
> Several new properties to allow PWM fan working as a cooling device have been
> combined into this single commit.
>
> Signed-off-by: Lukasz Majewski
> ---
> .../devicetree/bindings/hwmon/pwm-fan.txt | 28
>
On 17.12.2014 23:57, nick wrote:
> Greetings Fellow Maintainers,
> Sorry if I wasting your time but it seems there is a unneeded call to msleep
Hi,
1. Please describe exactly why do you think this is not needed.
2. Do you have Exynos-based hardware to test your changes?
Best regards,
Krzysztof
Several new properties to allow PWM fan working as a cooling device have been
combined into this single commit.
Signed-off-by: Lukasz Majewski
---
.../devicetree/bindings/hwmon/pwm-fan.txt | 28 ++
1 file changed, 28 insertions(+)
diff --git a/Documentation/devicetr
It was necessary to decouple code handling writing to sysfs from the one
responsible for setting PWM of the fan.
Due to that, new __set_pwm() method was extracted, which is responsible for
only setting new PWM duty cycle.
Signed-off-by: Lukasz Majewski
---
drivers/hwmon/pwm-fan.c | 35 ++
Presented patches add support for Odroid's U3 optional CPU FAN, which uses PWM
subsystem for low level control.
After successful probe it registers itself as a cooling device for thermal
subsystem. To preserve ability to use this fan as a PWM device a stub for
thermal_of_cooling_device_register()
With those bindings it is possible to use pwm-fan device available at
Odroid U3 as a cooling device.
Signed-off-by: Lukasz Majewski
---
arch/arm/boot/dts/exynos4412-odroidu3.dts | 33 ++-
1 file changed, 32 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/
From: Kamil Debski
Add pwm-fan node to the Odroid-U3 board file to enable PWM control of the
cooling fan. In addition, add the "pwm" label to the pwm@139D node
in the exynos4412.dtsi.
Signed-off-by: Kamil Debski
[Rebased on the newest mainline by l.majew...@samsung.com]
---
Changes since v1
Code for reading PWM FAN configuration data via device tree has been added.
Signed-off-by: Lukasz Majewski
---
drivers/hwmon/pwm-fan.c | 51 -
1 file changed, 50 insertions(+), 1 deletion(-)
diff --git a/drivers/hwmon/pwm-fan.c b/drivers/hwmon/pwm
The PWM FAN device can now be used as a thermal cooling device. Necessary
infrastructure has been added in this commit.
Signed-off-by: Lukasz Majewski
---
drivers/hwmon/pwm-fan.c | 79 -
1 file changed, 78 insertions(+), 1 deletion(-)
diff --git a
Up till now the PWM fan was enabled by default in the pwm-fan driver.
Now, by defining 'default-pulse-width' device tree property, it is possible
to configure the fan RPM on boot. By specifying value of 0, one can disable it.
Signed-off-by: Lukasz Majewski
---
drivers/hwmon/pwm-fan.c | 34 ++
By specifying default-pulse-width to zero, disable FAN on boot.
Signed-off-by: Lukasz Majewski
---
arch/arm/boot/dts/exynos4412-odroidu3.dts | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/exynos4412-odroidu3.dts
b/arch/arm/boot/dts/exynos4412-odroidu3.dts
index cc50e96..f
Odroid U3 fan can work without being registered as OF cooling device
(with CONFIG_THERMAL_OF disabled).
In this situation it can be controlled via PWM entry at
/sys/class/hwmon/hwmon0/pwm1.
Therefore, the thermal_of_cooling_device_register() function needs a stub
to allow clean compilation.
Signe
On 18/12/14 01:58, Rafael J. Wysocki wrote:
What's needed to solve this problem is a generalized way to have runtime
> >> PM dependencies between devices. Runtime PM already automatically
> >> handles parent devices as one type of dependent device (e.g. a parent
> >> device nee
On Thu, Dec 18, 2014 at 10:52 AM, Uwe Kleine-König
wrote:
> Hello,
Hi Uwe,
> [Cc += linusw, linux-gpio]
>
> On Wed, Dec 17, 2014 at 10:04:24PM +0300, Vasily Khoruzhick wrote:
>> I'd like to port several s3c24xx to DT, and I'm stuck with s3c24xx LCD
>> controller and power drivers for H1940 and R
Hi Rafael,
Thanks for your comments!
On Thu, Dec 18, 2014 at 1:57 AM, Rafael J. Wysocki wrote:
> On Wednesday, December 17, 2014 08:33:13 PM Geert Uytterhoeven wrote:
>> On Tue, Dec 16, 2014 at 11:10 PM, Kevin Hilman wrote:
>> > At a deeper level, the problem with this approach is that this is
66 matches
Mail list logo
