Hello Mike,
On 04/01/2015 03:29 AM, Michael Turquette wrote:
Quoting Javier Martinez Canillas (2015-03-31 01:59:39)
+Tomeu who I forgot to add to the cc list.
Hello Mike,
Thanks a lot for your feedback.
On 03/31/2015 03:40 AM, Michael Turquette wrote:
I don't performance is a big
2015-04-01 6:03 GMT+02:00 Kevin Hilman khil...@kernel.org:
Abhilash Kesavan kesavan.abhil...@gmail.com writes:
On Wed, Apr 1, 2015 at 2:32 AM, Kevin Hilman khil...@kernel.org wrote:
Javier Martinez Canillas javier.marti...@collabora.co.uk writes:
[...]
Unfortunately I don't fully
Hello Sylwester,
On 04/01/2015 01:03 PM, Sylwester Nawrocki wrote:
On 31/03/15 22:00, Javier Martinez Canillas wrote:
On 03/31/2015 04:38 PM, Abhilash Kesavan wrote:
javier.marti...@collabora.co.uk wrote:
Unfortunately I don't fully understand why this clock needs to be
enabled. It would
Hello,
On 31/03/15 22:00, Javier Martinez Canillas wrote:
On 03/31/2015 04:38 PM, Abhilash Kesavan wrote:
javier.marti...@collabora.co.uk wrote:
Unfortunately I don't fully understand why this clock needs to be
enabled. It would be good if someone at Samsung can explain in
more detail what
Hello Gustavo,
On 2015-03-27 14:11, Gustavo Padovan wrote:
If you can rebase this in on top of my series this would be really
good.
like I said in my other mail, the series doesn't apply cleanly anymore,
so I had to rebase your series.
Then it would just be:
static int
Use the correct spelling for 'progressive'.
Signed-off-by: Tobias Jakobi tjak...@math.uni-bielefeld.de
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 2 +-
drivers/gpu/drm/exynos/exynos_mixer.c | 2 +-
drivers/gpu/drm/exynos/regs-mixer.h | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
The messages are redundant since 'check_fb_gem_memory_type'
already prints out exactly the same string when it fails.
Signed-off-by: Tobias Jakobi tjak...@math.uni-bielefeld.de
---
drivers/gpu/drm/exynos/exynos_drm_fb.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git
While the VP (video processor) supports arbitrary scaling
of its input, the mixer just supports a simple 2x (line
doubling) scaling. Expose this functionality and exit
early when an unsupported scaling configuration is
encountered.
This was tested with modetest's DRM plane test (from
the libdrm
Hi Tobias,
2015-04-01 Tobias Jakobi tjak...@math.uni-bielefeld.de:
While the VP (video processor) supports arbitrary scaling
of its input, the mixer just supports a simple 2x (line
doubling) scaling. Expose this functionality and exit
early when an unsupported scaling configuration is
Hi Tobias,
2015-04-01 Tobias Jakobi tjak...@math.uni-bielefeld.de:
The messages are redundant since 'check_fb_gem_memory_type'
already prints out exactly the same string when it fails.
Signed-off-by: Tobias Jakobi tjak...@math.uni-bielefeld.de
---
drivers/gpu/drm/exynos/exynos_drm_fb.c |
Hi Tobias,
2015-03-31 Tobias Jakobi liquid.a...@gmx.net:
Hello,
I just wanted to point out that this doesn't apply to exynos-drm-fixes, which
was probably caused by Daniel's pitch patch here:
Hi Tobias,
2015-04-01 Tobias Jakobi tjak...@math.uni-bielefeld.de:
Use the correct spelling for 'progressive'.
Signed-off-by: Tobias Jakobi tjak...@math.uni-bielefeld.de
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 2 +-
drivers/gpu/drm/exynos/exynos_mixer.c | 2 +-
From: Gustavo Padovan gustavo.pado...@collabora.co.uk
We already set each plane zpos at init, after that changes to zpos are
not expected. This patch turns zpos into a read-only property so now it is
impossible to set zpos.
Signed-off-by: Gustavo Padovan gustavo.pado...@collabora.co.uk
---
From: Gustavo Padovan gustavo.pado...@collabora.co.uk
Usually userspace don't want to have two overlay planes on the same zpos
so this change assign a different zpos for each plane. Before this change
a zpos of value zero was created for all planes so the userspace had to
set up the zpos of every
From: Gustavo Padovan gustavo.pado...@collabora.co.uk
The .destroy() callback for exynos can be replaced by drm_plane_cleanup().
The only extra operation on exynos_plane_destroy() was a call to
exynos_plane_disable() but the plane is already disabled by a earlier call
to drm_framebuffer_remove().
From: Gustavo Padovan gustavo.pado...@collabora.co.uk
XR24 planes were not shown properly, so now set the right registers
to correctly enable displaying these planes.
It also moves the alpha register settings to fimd_win_set_pixfmt()
to keep all pixel format stuff together.
v2: remove leftover
From: Gustavo Padovan gustavo.pado...@collabora.co.uk
Hi,
Here goes some clean ups to the exynos drivers. The main clean ups is
the presetting and zpos making the property immutable and the removal
of *_win_data structures.
v2 contains a extra patch to fix alpha setting for planes in fimd, so
From: Gustavo Padovan gustavo.pado...@collabora.co.uk
None of the exynos crtc drivers implements win_enable() so remove it for
better clarity of the code.
Signed-off-by: Gustavo Padovan gustavo.pado...@collabora.co.uk
---
drivers/gpu/drm/exynos/exynos_drm_drv.h | 2 --
1 file changed, 2
From: Gustavo Padovan gustavo.pado...@collabora.co.uk
struct {fimd,mixer,vidi}_win_data was just keeping the same data
as struct exynos_drm_plane thus get ride of it and use exynos_drm_plane
directly.
It changes how planes are created and remove .win_mode_set() callback
that was only filling all
From: Gustavo Padovan gustavo.pado...@collabora.co.uk
These functions were already removed by previous cleanup work, but these
ones were left behind.
Signed-off-by: Gustavo Padovan gustavo.pado...@collabora.co.uk
Acked-by: Joonyoung Shim jy0922.s...@samsung.com
---
From: Mandeep Singh Baines m...@chromium.org
The goal of the change is to make sure we send the vblank event on the
current vblank. My hope is to fix any races that might be causing flicker.
After this change I only see a flicker in the transition plymouth and
X11.
Simplified the code by
The following changes since commit c517d838eb7d07bbe9507871fab3931deccff539:
Linux 4.0-rc1 (2015-02-22 18:21:14 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
tags/samsung-defconfig
for you to fetch changes up to
The following changes since commit c517d838eb7d07bbe9507871fab3931deccff539:
Linux 4.0-rc1 (2015-02-22 18:21:14 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
tags/samsung-dt
for you to fetch changes up to
The following changes since commit c517d838eb7d07bbe9507871fab3931deccff539:
Linux 4.0-rc1 (2015-02-22 18:21:14 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
tags/samsung-dt-64
for you to fetch changes up to
The following changes since commit c517d838eb7d07bbe9507871fab3931deccff539:
Linux 4.0-rc1 (2015-02-22 18:21:14 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
tags/samsung-updates
for you to fetch changes up to
Hello Javier,
On 01/04/15 13:44, Javier Martinez Canillas wrote:
On 04/01/2015 01:03 PM, Sylwester Nawrocki wrote:
On 31/03/15 22:00, Javier Martinez Canillas wrote:
On 03/31/2015 04:38 PM, Abhilash Kesavan wrote:
javier.marti...@collabora.co.uk wrote:
I had a look at this some more today.
Hi Arnd, Olof, Kevin,
Here is 2nd Samsung fixes for v4.0 and it fixes arm allmodconfig build
breakage and exynos5250-spring lid, power-pin and mmc nodes dt updates.
Please pull and sorry for pretty late pull-request for v4.0.
Thanks,
Kukjin
The following changes since commit
The following changes since commit c517d838eb7d07bbe9507871fab3931deccff539:
Linux 4.0-rc1 (2015-02-22 18:21:14 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
tags/samsung-fixes-v4.1
for you to fetch changes up to
Quoting Krzysztof Kozlowski (2015-04-01 02:16:08)
2015-04-01 6:03 GMT+02:00 Kevin Hilman khil...@kernel.org:
Abhilash Kesavan kesavan.abhil...@gmail.com writes:
On Wed, Apr 1, 2015 at 2:32 AM, Kevin Hilman khil...@kernel.org wrote:
Javier Martinez Canillas javier.marti...@collabora.co.uk
Hello Sylwester,
On 04/01/2015 07:31 PM, Sylwester Nawrocki wrote:
On 01/04/15 13:44, Javier Martinez Canillas wrote:
On 04/01/2015 01:03 PM, Sylwester Nawrocki wrote:
It's not clear what subsystems affect state of the CG_STATUSx registers, it
would be good if we could get more information on
30 matches
Mail list logo
