On 9/16/24 06:15, Stephen Rothwell wrote:
Hi all,
Today's linux-next merge of the drm tree got a conflict in:
drivers/gpu/drm/amd/display/dc/hwss/dcn35/dcn35_hwseq.c
between commit:
e835d5144f5e ("drm/amd/display: Avoid race between dcn35_set_drr() and
dc_state_destruct()")
from Linu
On 9/9/24 19:18, Harry Wentland wrote:
On 2024-09-09 13:11, Alex Deucher wrote:
On Sun, Sep 8, 2024 at 7:23 AM Tobias Jakobi
wrote:
On 9/8/24 09:35, Christopher Snowhill wrote:
On Mon Sep 2, 2024 at 2:40 AM PDT, tjakobi wrote:
From: Tobias Jakobi
Hello,
this fixes a nasty race
On 9/8/24 09:35, Christopher Snowhill wrote:
On Mon Sep 2, 2024 at 2:40 AM PDT, tjakobi wrote:
From: Tobias Jakobi
Hello,
this fixes a nasty race condition in the set_drr() callbacks for DCN10
and DCN35 that has existed now since quite some time, see this GitLab
issue for reference.
https
On 3/10/24 23:04, tjak...@math.uni-bielefeld.de wrote:
From: Tobias Jakobi
Similar to the other Aya Neo devices this one features
again a portrait screen, here with a native resolution
of 1600x2560.
Signed-off-by: Tobias Jakobi
---
drivers/gpu/drm/drm_panel_orientation_quirks.c | 6
On 3/10/24 23:04, tjak...@math.uni-bielefeld.de wrote:
From: Tobias Jakobi
Similar to the other Aya Neo devices this one features
again a portrait screen, here with a native resolution
of 1600x2560.
Signed-off-by: Tobias Jakobi
---
drivers/gpu/drm/drm_panel_orientation_quirks.c | 6
On 3/9/24 02:47, tjak...@math.uni-bielefeld.de wrote:
From: Tobias Jakobi
This 8.4 inch panel is integrated in the Ayaneo Kun handheld
device. The panel resolution is 2560×1600, i.e. it has
portrait dimensions.
Decoding the EDID shows:
Manufacturer: MSF
Model: 4099
Display Product Name
On 3/10/24 23:04, tjak...@math.uni-bielefeld.de wrote:
From: Tobias Jakobi
Similar to the other Aya Neo devices this one features
again a portrait screen, here with a native resolution
of 1600x2560.
Signed-off-by: Tobias Jakobi
---
drivers/gpu/drm/drm_panel_orientation_quirks.c | 6
On 3/9/24 02:47, tjak...@math.uni-bielefeld.de wrote:
From: Tobias Jakobi
This 8.4 inch panel is integrated in the Ayaneo Kun handheld
device. The panel resolution is 2560×1600, i.e. it has
portrait dimensions.
Decoding the EDID shows:
Manufacturer: MSF
Model: 4099
Display Product Name
Hi Dmitry,
On 2/7/24 12:00, Dmitry Baryshkov wrote:
On Tue, 6 Feb 2024 at 01:57, wrote:
From: Tobias Jakobi
Similar to the other Aya Neo devices this one features
again a portrait screen, here with a native resolution
of 1600x2560.
Signed-off-by: Tobias Jakobi
As you don't seem to b
Hello Krzysztof,
looks good to me!
Reviewed-by: Tobias Jakobi
- Tobias
Krzysztof Kozlowski wrote:
> Remove local variable 'priv' to fix GCC warning:
>
> drivers/gpu/drm/exynos/exynos_mixer.c: In function 'mixer_initialize':
> drivers/gpu/drm/exyno
Hey Arnd,
looks good to me!
Reviewed-by: Tobias Jakobi
- Tobias
Arnd Bergmann wrote:
> The exynos DRM driver uses real-time 'struct timeval' values
> for exporting its timestamps to user space. This has multiple
> problems:
>
> 1. signed seconds overflow in y2038
Inki Dae wrote:
> Hi Tobias,
>
> Thanks for touching this code.
>
> But I think below changes chould be explained exactly. Anyway, below are my
> comments,
>
> 2017년 11월 23일 23:19에 Tobias Jakobi 이(가) 쓴 글:
>> If an interlaced video mode is selected, a IOMM
pagefaults.
Signed-off-by: Tobias Jakobi
---
drivers/gpu/drm/exynos/exynos_mixer.c | 21 +++--
1 file changed, 11 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
b/drivers/gpu/drm/exynos/exynos_mixer.c
index dc5d79465f9b..a18426379e57 100644
Please disregard this one, need to rebase. v2 in a minute...
- Tobias
Tobias Jakobi wrote:
> If an interlaced video mode is selected, a IOMMU pagefault is
> triggered by vp_video_buffer().
>
> Fix the most apparent bugs:
> - pitch value for chroma plane
> - divide by two
pagefaults.
Signed-off-by: Tobias Jakobi
---
drivers/gpu/drm/exynos/exynos_mixer.c | 21 +++--
1 file changed, 11 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
b/drivers/gpu/drm/exynos/exynos_mixer.c
index dc5d79465f9b..c382f99e0f5b 100644
Inki Dae wrote:
>
>
> 2017년 11월 22일 22:14에 Marek Szyprowski 이(가) 쓴 글:
>> When no IOMMU is available, all GEM buffers allocated by Exynos DRM driver
>> are contiguous, because of the underlying dma_alloc_attrs() function
>> provides only such buffers. In such case it makes no sense to keep
>> BO_N
uffers. This allows to avoid
> failures for buffer contiguity checks in the subsequent operations on GEM
> objects.
Reviewed-by: Tobias Jakobi
- Tobias
> Signed-off-by: Marek Szyprowski
> CC: sta...@vger.kernel.org # v4.4+
> ---
> This issue is there since commit 0519f9a
Hello Arnd,
I guess you could coordinate the IPP changes with Marek, who is rewriting the
IPP subsystem anyway (added Marek to Cc).
Here is the most recent IPPv2 series:
https://www.spinics.net/lists/linux-samsung-soc/msg61066.html
Concerning the G2D changes, I don't think anything in userspace
;> + * and/or sell copies of the Software, and to permit persons to whom the
>> + * Software is furnished to do so, subject to the following conditions:
>> + *
>> + * The above copyright notice and this permission notice (including the next
>> + * paragraph) shall be included
Dave Airlie wrote:
> On 23 October 2017 at 17:54, Marek Szyprowski
> wrote:
>> This patch adds Exynos IPP v2 subsystem and userspace API.
>>
>> New userspace API is focused ONLY on memory-to-memory image processing.
>> The two remainging IPP operation modes (framebuffer writeback and
>> local-pat
smmu_irq+0x1d0/0x24c
> LR is at exynos_sysmmu_irq+0x154/0x24c
> [ cut here ]
Reviewed-by: Tobias Jakobi
- Tobias
> Reported-by: Marian Mihailescu
> Fixes: f43c35966a5a ("drm/exynos: use real device for DMA-mapping operations")
> Signed-off-by: Marek Szyprow
Marek Szyprowski wrote:
> This patch adapts Exynos DRM rotator driver to new IPP v2 core API.
"DRM FIMC driver"
- Tobias
> The side effect of this conversion is a switch to driver component API
> to register properly in the Exynos DRM core.
>
> Signed-off-by: Marek Szyprowski
> ---
> drivers/
Hey Marek,
Marek Szyprowski wrote:
> This patch adapts Exynos DRM rotator driver to new IPP v2 core API.
you probably mean "DRM gsc driver" here (or GSC, not sure about capitalisation).
- Tobias
> The side effect of this conversion is a switch to driver component API
> to register properly in
Hello everyone,
I have finished some first (working) version of my mpv video backend for IPPv2.
You can find the tree here:
https://github.com/tobiasjakobi/mpv
I've also created some RFC pull request upstream, to get some input on the
current patches:
https://github.com/mpv-player/mpv/pull/4986
Both drmModeAddFB2() and drmModeAddFB2WithModifiers() have some
arguments that are just pointers to uint32_t in disguise. These
are not modified (just copied) in the function, so we can add a
const qualifier here.
Signed-off-by: Tobias Jakobi
---
xf86drmMode.c | 10 +-
xf86drmMode.h
Hello Marek,
I just tested this series, and I noticed a lot of these lines:
> exynos-sysmmu 11a4.sysmmu: restoring state
> exynos-sysmmu 11a4.sysmmu: saving state
I guess it would make sense to enable autosuspend for runtime PM in each of the
hw drivers.
I've just send a patch that does
Signed-off-by: Tobias Jakobi
---
drivers/gpu/drm/exynos/exynos_drm_fimc.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
index 1c48c57381f1..bffb4b513453 100644
--- a/drivers/gpu
Hello everyone,
just finished a first draft of the libdrm API and some test application:
https://github.com/tobiasjakobi/libdrm/blob/ippv2/exynos/exynos_ipp.h
https://github.com/tobiasjakobi/libdrm/blob/ippv2/tests/exynos/exynos_ipp_test.c
Needs a small patch to the kernel to prevent an Oops when
Hello Marek,
Marek Szyprowski wrote:
> This patch adds Exynos IPP v2 subsystem and userspace API.
>
> New userspace API is focused ONLY on memory-to-memory image processing.
> The two remainging IPP operation modes (framebuffer writeback and
> local-path output with image processing) can be impl
Hey Marek,
first of all thanks for keeping this series alive. Looks pretty good so far.
I have started to rewrite my IPP userspace API in libdrm and when this is done,
I'm going to adapt my mpv video backend to it.
With best wishes,
Tobias
Marek Szyprowski wrote:
> Dear all,
>
> This patchse
Hello Andrzej,
Andrzej Hajda wrote:
> Since HDMI can handle these modes despite of MIXER limitations lets
> enable them.
lets --> let's
Reviewed-by: Tobias Jakobi
> Signed-off-by: Andrzej Hajda
> ---
> drivers/gpu/drm/exynos/exynos_mixer.c | 3 +++
> 1
Hello Andrzej,
Andrzej Hajda wrote:
> Screen resolution configuration depends on HW version, let put it into
> single function to make it consistent and simplify the code.
"...let's put it into..."
Reviewed-by: Tobias Jakobi
> Signed-off-by: Andrzej Hajda
> --
Hello Andrzej,
Andrzej Hajda wrote:
> crtc::mode_fixup callback is required by crtcs which use internally
> different mode than requested by user - case of Exynos Mixer.
"...which internally use a different..."
Reviewed-by: Tobias Jakobi
With one suggestion below.
> Sig
way to do it is to modify
> adjusted_mode property in crtc::mode_fixup callback. Adding such callback
> allows also to simplify mixer_cfg_scan code - choosing mode is performed
> already in crtc::mode_fixup. mode_fixup is also better place to check
> interlace flag.
Reviewed-by: Tobia
> With this patch it is possible to enable 1024x768 and 1280x1024
> modes in MIXER.
Reviewed-by: Tobias Jakobi
And some question below.
> Suggested-by: Daniel Drake
> Signed-off-by: Andrzej Hajda
> ---
> drivers/gpu/drm/exynos/exynos_hdmi.c | 15 +--
> 1
Hello Andrzej,
Andrzej Hajda wrote:
> Mode setup code is called from video plane update and mixer plane update.
> Lets group it together in mixer_commit function like in case of other
> Exynos CRTCs.
Minor typo: Lets --> Let's
Reviewed-by: Tobias Jakobi
With some sma
d regression.
"...also requires that the interlace check is moved to..."
Reviewed-by: Tobias Jakobi
> Signed-off-by: Andrzej Hajda
> ---
> drivers/gpu/drm/exynos/exynos_mixer.c | 20
> 1 file changed, 8 insertions(+), 12 deletions(-)
>
> diff --git
nally little cleanup is performed.
Reviewed-by: Tobias Jakobi
And some small suggestion below.
> Signed-off-by: Andrzej Hajda
> ---
> drivers/gpu/drm/exynos/exynos_mixer.c | 24 +++-
> 1 file changed, 11 insertions(+), 13 deletions(-)
>
> diff --git a/drivers
functionally it does not change anything, but
> subsequent patches will make the difference.
Reviewed-by: Tobias Jakobi
> Signed-off-by: Andrzej Hajda
> ---
> drivers/gpu/drm/exynos/exynos_hdmi.c | 34 +-
> 1 file changed, 9 insertions(+), 25 del
Hello Andrzej,
Andrzej Hajda wrote:
> mixer_resources adds only unnecessary redirection, removing it makes the
> code shorter and cleaner.
Reviewed-by: Tobias Jakobi
> Signed-off-by: Andrzej Hajda
> ---
> drivers/gpu/drm/exynos/exynos_mixer.c | 323
> -
From: Daniel Drake
Configuration details from Samsung. This enables 1366x768@60Hz,
which also needs the 257px timing hack to work around a mixer
limitation.
Signed-off-by: Daniel Drake
Signed-off-by: Tobias Jakobi
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 9 +
drivers/gpu/drm
:
> Hi all,
>
> This patchset does two main things:
> - removes mode limitation for Exynos542x chips, multiple modes were filtered
> out due to lack of HW version checking code,
> - enables two modes on older chips, thanks to quirk found by Daniel Drake,
> and published by Tobias
Hello Marek,
first of all thanks for checking this!
Marek Szyprowski wrote:
> Hi Tobias,
>
> On 2017-08-22 16:19, Tobias Jakobi wrote:
>> In some of subdrivers we compute something like 'pitch / cpp' at some
>> point, silently assuming that the pitch (which is i
g the top row of pixels,
and the rightmost column too.
Apply the timing hack to both 1280x1024 and 1024x768.
Signed-off-by: Daniel Drake
Signed-off-by: Tobias Jakobi
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 16
drivers/gpu/drm/exynos/exynos_mixer.c | 6 ++
2 files change
Hello,
I was asked by a user of my kernel tree to try to upstream this. The patch is
originally by Daniel who figured out this peculiar behaviour of the HDMI block.
Since this is clearly a hack, should it even be upstreamed?
Some more questions/thoughts:
- I know that it works for the HDMI bloc
> drm/exynos: add BYTE_PITCH cap for all supported planes
>
> Thanks,
> Inki Dae
>
> 2017년 08월 22일 23:19에 Tobias Jakobi 이(가) 쓴 글:
>> Hello,
>>
>> this is the second iteration of [1], with the following changes:
>> - split patch 3/8 (suggested by Inki)
>> -
Tobias Jakobi wrote:
> Hello Andrzej,
>
>
> Andrzej Hajda wrote:
>> Linux core provide helpers for polling with timeout, lets use them.
>>
>> Signed-off-by: Andrzej Hajda
>> ---
>> drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 20 --
Hello Andrzej,
Andrzej Hajda wrote:
> Linux core provide helpers for polling with timeout, lets use them.
>
> Signed-off-by: Andrzej Hajda
> ---
> drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 20
> 1 file changed, 8 insertions(+), 12 deletions(-)
>
> diff --git a/drive
DRM core already checks the validity of the pixelformat.
Signed-off-by: Tobias Jakobi
---
drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 4 +---
drivers/gpu/drm/exynos/exynos7_drm_decon.c| 7 +--
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 8 +---
3 files changed, 3 insertions
IMD, DECON7 and DECON5433 drivers.
Signed-off-by: Tobias Jakobi
---
drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 12 ++--
drivers/gpu/drm/exynos/exynos7_drm_decon.c| 6 +++---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 8
3 files changed, 13 insertions(+), 13 deletions
Both FIMD and DECON5433 support a pitch in bytes.
Signed-off-by: Tobias Jakobi
---
drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 1 +
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
b/drivers
etup, we should communicate this.
Introduce a new cap which indicates that the hardware supports a
pitch with 'byte-granularity'. If the cap is not set, assume that
we need a pitch aligned to cpp.
We set this cap in a later patch for the drivers/planes which
support it.
Signed-off-by: Tobias
We always translate the dma address such that the offsets of
the source image are zero. Hence we can remove manipulation of
the MXR_GRAPHIC_SXY(win) register and just zero them once
in mixer_win_reset().
Signed-off-by: Tobias Jakobi
---
drivers/gpu/drm/exynos/exynos_mixer.c | 15
DRM core already checks in drm_atomic_plane_check() if the
pixelformat is valid. Hence we can collapse the default case
of the switch statement with the XRGB case.
No functional change.
Signed-off-by: Tobias Jakobi
---
drivers/gpu/drm/exynos/exynos_mixer.c | 5 +
1 file changed, 1
functional change.
Signed-off-by: Tobias Jakobi
---
drivers/gpu/drm/exynos/exynos_mixer.c | 26 ++
1 file changed, 6 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
b/drivers/gpu/drm/exynos/exynos_mixer.c
index 4c894d97aba3..beef4d6c41ca
can now properly support
this format again.
Tested with a hacked up modetest from libdrm's test suite on
an ODROID-X2 (Exynos4412).
Signed-off-by: Tobias Jakobi
---
drivers/gpu/drm/exynos/exynos_drm_drv.h | 1 +
drivers/gpu/drm/exynos/exynos_drm_fb.c| 2 ++
drivers/gpu/drm/e
modifier in patch 2/8
Summary:
(a) Enables support for NV12MT in the mixer.
(b) Sanitizes buffer pitch for HW with restrictions.
(c) Misc fixes
With best wishes,
Tobias
[1] https://www.spinics.net/lists/linux-samsung-soc/msg60235.html
Tobias Jakobi (9):
drm/exynos: mixer: fix chroma comment
The current comment sounds like the division op is done to
compensate for some hardware erratum. But the chroma plane
having half the height of the luma plane is just the way
NV12/NV21 is defined, so clarify this behaviour.
Signed-off-by: Tobias Jakobi
---
drivers/gpu/drm/exynos/exynos_mixer.c
Inki Dae wrote:
>
>
> 2017년 08월 09일 20:48에 Tobias Jakobi 이(가) 쓴 글:
>> We always translate the dma address such that the offsets of
>> the source image are zero. Hence we can remove manipulation of
>> the MXR_GRAPHIC_SXY(win) register.
>>
>> We leave th
Inki Dae wrote:
>
>
> 2017년 08월 09일 20:48에 Tobias Jakobi 이(가) 쓴 글:
>> In some of drivers we compute something like 'pitch / cpp' at some
>> point, silently assuming that the pitch (which is in bytes) is
>> divisible by the buffer's cpp. This is not alway
Inki Dae wrote:
>
>
> 2017년 08월 09일 20:48에 Tobias Jakobi 이(가) 쓴 글:
>> DRM core already checks the validity of the pixelformats, so we
>> can simplify the checks here. The same applies to the FB modifier,
>> which is now checked in common Exynos plane code.
>&g
x27;s totally missing here.
More comments inline.
With these changes you have my
Acked-by: Tobias Jakobi
- Tobias
[1] http://www.spinics.net/lists/linux-samsung-soc/msg59230.html
Inki Dae wrote:
> Chnage GPL license of Exynos relevant code to X11/MIT.
"Chnage" -> "Chan
DRM core already checks the validity of the pixelformat.
Signed-off-by: Tobias Jakobi
---
drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 4 +---
drivers/gpu/drm/exynos/exynos7_drm_decon.c| 7 +--
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 8 +---
3 files changed, 3 insertions
IMD, DECON7 and DECON5433 drivers.
Signed-off-by: Tobias Jakobi
---
drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 12 ++--
drivers/gpu/drm/exynos/exynos7_drm_decon.c| 6 +++---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 8
3 files changed, 13 insertions(+), 13 deletions
Both FIMD and DECON5433 support a pitch in bytes.
Signed-off-by: Tobias Jakobi
---
drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 1 +
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
b/drivers
a new cap which indicates that the hardware supports a
pitch with 'byte-granularity'. If the cap is not set, assume that
we need pitch aligned to cpp.
We set this cap later for the drivers/planes that support it.
Signed-off-by: Tobias Jakobi
---
drivers/gpu/drm/exynos/exynos_drm_drv.h | 1
DRM core already checks the validity of the pixelformats, so we
can simplify the checks here. The same applies to the FB modifier,
which is now checked in common Exynos plane code.
Also rename the booleans to reflect what true/false actually
means.
Signed-off-by: Tobias Jakobi
---
drivers/gpu
The current comment sounds like the division op is done to
compensate for some hardware erratum. But the chroma plane
having half the height of the luma plane is just the way
NV12/NV21 is defined, so clarify this behaviour.
Signed-off-by: Tobias Jakobi
---
drivers/gpu/drm/exynos/exynos_mixer.c
can now properly support
this format again.
Tested with a hacked up modetest from libdrm's test suite on
an ODROID-X2 (Exynos4412).
Signed-off-by: Tobias Jakobi
---
drivers/gpu/drm/exynos/exynos_drm_drv.h | 1 +
drivers/gpu/drm/exynos/exynos_drm_fb.c| 2 ++
drivers/gpu/drm/e
] https://lists.freedesktop.org/archives/dri-devel/2017-April/138040.html
Tobias Jakobi (8):
drm/exynos: mixer: fix chroma comment in vp_video_buffer()
drm/exynos: mixer: enable NV12MT support for the video plane
drm/exynos: mixer: simplify {vp_video,mixer_graph}_buffer()
drm/exynos: mixer
We always translate the dma address such that the offsets of
the source image are zero. Hence we can remove manipulation of
the MXR_GRAPHIC_SXY(win) register.
We leave the register defines (in regs_mixer.h) in place, since
they document the hardware.
Signed-off-by: Tobias Jakobi
---
drivers
Hello Marek,
I have a similar patch in my tree, so this one is
Reviewed-by: Tobias Jakobi
- Tobias
Marek Szyprowski wrote:
> Add a check if the framebuffer described by the provided drm_mode_fb_cmd2
> structure fits into provided GEM buffers. Without this check it is
> possible to
Hello Hoegeun,
my last question (does this regress the case "node required, but
absent") still stands.
Hoegeun Kwon wrote:
> Remove the error handling of bridge_node because the bridge_node is
> required optionally.
I don't think a construction like that exists. Either it's required, or
it's opt
Hey,
Nicolas Dufresne wrote:
> Le mercredi 26 avril 2017 à 18:52 +0200, Tobias Jakobi a écrit :
>> Hello again,
>>
>>
>> Nicolas Dufresne wrote:
>>> Le mercredi 26 avril 2017 à 01:21 +0300, Sakari Ailus a écrit :
>>>> Hi Marek,
>>>>
>
Hello again,
Nicolas Dufresne wrote:
> Le mercredi 26 avril 2017 à 01:21 +0300, Sakari Ailus a écrit :
>> Hi Marek,
>>
>> On Thu, Apr 20, 2017 at 01:23:09PM +0200, Marek Szyprowski wrote:
>>> Hi Laurent,
>>>
>>> On 2017-04-20 12:25, Laurent Pinchart wrote:
Hi Marek,
(CC'ing Sakari
Hello everyone,
Nicolas Dufresne wrote:
> Le mercredi 26 avril 2017 à 01:21 +0300, Sakari Ailus a écrit :
>> Hi Marek,
>>
>> On Thu, Apr 20, 2017 at 01:23:09PM +0200, Marek Szyprowski wrote:
>>> Hi Laurent,
>>>
>>> On 2017-04-20 12:25, Laurent Pinchart wrote:
Hi Marek,
(CC'ing Saka
Hello everyone,
Marek Szyprowski wrote:
> Hi Laurent,
>
> On 2017-04-20 12:25, Laurent Pinchart wrote:
>> Hi Marek,
>>
>> (CC'ing Sakari Ailus)
>>
>> Thank you for the patches.
>>
>> On Thursday 20 Apr 2017 11:13:36 Marek Szyprowski wrote:
>>> Dear all,
>>>
>>> This is an updated proposal for ex
Hello Inki,
Inki Dae wrote:
> Hello Tobias,
>
> 2017년 04월 11일 19:52에 Tobias Jakobi 이(가) 쓴 글:
>> Hello Inki,
>>
>> please don't forget to review this series.
>
> Thanks for your contribution, and don't worry about that. Will review this
> ser
Hello Inki,
Inki Dae wrote:
> 2017년 04월 11일 17:17에 Tobias Jakobi 이(가) 쓴 글:
>> Another thing that I noticed. Why wasn't the v2 that ended up in your
>> git ever submitted to the mailing list? Because it should have, in
>> particular to spot these obvious errors.
&g
; - Tobias
>>
>>
>>
>>>
>>> Thanks,
>>> Inki Dae
>>>
>>>>
>>>> - Tobias
>>>>
>>>>
>>>>> Thanks,
>>>>> Inki Dae
>>>>>
>>>>>> With be
wrong.
While I can somehow guess that VP_MODE_LINE_SKIP does, the
VP_MODE_FIELD_ID_AUTO_TOGGLING flag still remains a mystery to me. If
possible, I request some documentation for this as well.
With best wishes,
Tobias
Tobias Jakobi wrote:
> Hello,
>
> some recent work I did on Exyno
Another thing that I noticed. Why wasn't the v2 that ended up in your
git ever submitted to the mailing list? Because it should have, in
particular to spot these obvious errors.
- Tobias
Tobias Jakobi wrote:
> Inki Dae wrote:
>>
>>
>> 2017년 04월 10일 19:29에 Tobias Jak
Inki Dae wrote:
>
>
> 2017년 04월 10일 19:27에 Tobias Jakobi 이(가) 쓴 글:
>> Inki Dae wrote:
>>> 2017-03-29 20:56 GMT+09:00 Tobias Jakobi :
>>>> Hello Daniel,
>>>>
>>>> same question here. Patch doesn't introduce any functional changes
Inki Dae wrote:
>
>
> 2017년 04월 10일 19:29에 Tobias Jakobi 이(가) 쓴 글:
>> Inki Dae wrote:
>>> 2017-04-07 20:40 GMT+09:00 Tobias Jakobi :
>>>> Hello Inki,
>>>>
>>>>
>>>> Inki Dae wrote:
>>>>> Hello T
Inki Dae wrote:
> 2017-04-07 20:40 GMT+09:00 Tobias Jakobi :
>> Hello Inki,
>>
>>
>> Inki Dae wrote:
>>> Hello Tobias,
>>>
>>>
>>> 2017년 04월 07일 02:10에 Tobias Jakobi 이(가) 쓴 글:
>>>> Hello Inki,
>>>>
>>>&
Inki Dae wrote:
> 2017-03-29 20:56 GMT+09:00 Tobias Jakobi :
>> Hello Daniel,
>>
>> same question here. Patch doesn't introduce any functional changes (just
>> adds code documentation), so can you merge it through drm-misc?
>>
>
> Sorry for late. Confir
Emil Velikov wrote:
> FTR, only the installed headers (~50) need the extern C guard.
> None of that is not a blocker for this patch, so I've just pushed it to
> master.
Thanks Emil. I'll see what I can do about the other ones.
- Tobias
> Thanks!
> Emil
>
__
Hello Inki,
Inki Dae wrote:
> Hello Tobias,
>
>
> 2017년 04월 07일 02:10에 Tobias Jakobi 이(가) 쓴 글:
>> Hello Inki,
>>
>>
>> Inki Dae wrote:
>>> This patch removes unnecessary descriptions on
>>> exynos_drm_crtc structure and adds one des
Hello Inki,
Inki Dae wrote:
> This patch removes unnecessary descriptions on
> exynos_drm_crtc structure and adds one description
> which specifies what pipe_clk member does.
>
> pipe_clk support had been added by below patch without any description,
>drm/exynos: add support for pipeline
Hello Eric,
Eric Engestrom wrote:
> On Wednesday, 2017-04-05 16:22:24 +0200, Tobias Jakobi wrote:
>> Add the usual extern "C" when compiling in C++ mode.
>
> Thanks, but why specifically this header? The other exynos/*.h headers
> also lack the c++ mangling guard.
I
Add the usual extern "C" when compiling in C++ mode.
Signed-off-by: Tobias Jakobi
---
exynos/exynos_drmif.h | 8
1 file changed, 8 insertions(+)
diff --git a/exynos/exynos_drmif.h b/exynos/exynos_drmif.h
index 626e399..154439b 100644
--- a/exynos/exynos_drmif.h
++
DRM core already checks the validity of the pixelformat.
Signed-off-by: Tobias Jakobi
---
drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 4 +---
drivers/gpu/drm/exynos/exynos7_drm_decon.c| 7 +--
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 8 +---
3 files changed, 3 insertions
IMD, DECON7 and DECON5433 drivers.
Signed-off-by: Tobias Jakobi
---
drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 12 ++--
drivers/gpu/drm/exynos/exynos7_drm_decon.c| 6 +++---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 8
3 files changed, 13 insertions(+), 13 deletions
Both FIMD and DECON5433 support a pitch in bytes.
Signed-off-by: Tobias Jakobi
---
drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 1 +
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
b/drivers
p which signals that the hardware supports a
pitch with 'byte-granularity'. If the cap is not set, assume that
we need pitch aligned to cpp.
We set the cap later for the drivers/planes that support it.
Signed-off-by: Tobias Jakobi
---
drivers/gpu/drm/exynos/exynos_drm_drv.h | 1
We always translate the dma address such that the offsets of
the source image are zero. Hence we can remove manipulation of
the MXR_GRAPHIC_SXY(win) register.
We leave the register defines (in regs_mixer.h) in place, since
they document the hardware.
Signed-off-by: Tobias Jakobi
---
drivers
DRM core already checks the validity of the pixelformats, to we
can simplify the checks here. The same applies to the FB modifier,
which is now check in common Exynos plane code.
Also rename the booleans to reflect what true/false actually
encodes.
Signed-off-by: Tobias Jakobi
---
drivers/gpu
, we can now properly support
this format again.
Tested with a hacked up modetest from libdrm's test suite on
an ODROID-X2 (Exynos4412).
Signed-off-by: Tobias Jakobi
---
drivers/gpu/drm/exynos/exynos_drm_drv.h | 1 +
drivers/gpu/drm/exynos/exynos_drm_fb.c| 2 ++
drivers/gpu/drm/e
:-)
With best wishes,
Tobias
[1] http://www.spinics.net/lists/linux-samsung-soc/msg58640.html
[2] http://www.spinics.net/lists/linux-samsung-soc/msg58644.html
Tobias Jakobi (8):
drm/exynos: mixer: fix chroma comment in vp_video_buffer()
drm/exynos: mixer: enable NV12MT support for the video p
The current comment sounds like the division is done to
compensate for some hardware erratum. But the chroma plane
having half the height of the luma plane is just the way
NV12/NV21 is defined, so clarify this behaviour.
Signed-off-by: Tobias Jakobi
---
drivers/gpu/drm/exynos/exynos_mixer.c | 2
1 - 100 of 621 matches
Mail list logo
