Hello,
while playing around with FIMD enabled, I noticed that when first using
the device a zero division was triggered in fimd_calc_clkdiv(). I
remembered that I had a similar issue some time ago.
I added a stub fimd_atomic_check() which shows that vrefresh is zero
when fimd_calc_clkdiv() is cal
Hey Marek,
I had a quick look at the series and I really like the new approach.
I was wondering about the following though. If I understand this
correctly I can only perform m2m operations on buffers which are
registered as framebuffers. Is this possible to weaken that requirements
such that arbi
Hello Marek,
Marek Szyprowski wrote:
> Dear Tobias
>
>
> On 2016-08-22 12:07, Tobias Jakobi wrote:
>> Hey Marek,
>>
>> I had a quick look at the series and I really like the new approach.
>>
>> I was wondering about the following though. If I understan
Hello,
I think this patch was never picked up. So just a short 'ping' from my side.
With best wishes,
Tobias
Shuah Khan wrote:
> Fix exynos_drm_gem_create() error messages to include flags and size when
> flags and size are invalid.
>
> Signed-off-by: Shuah Khan
> ---
> drivers/gpu/drm/exyno
Hello Dan,
sorry for the blunder! Patch looks good to me.
Reviewed-by: Tobias Jakobi
With best wishes,
Tobias
Dan Carpenter wrote:
> We were trying to print an error message if we timed out here, but the
> loop actually ends with "tries" set to UINT_MAX and not zero. Fix th
Hello Shuah,
just a short note that more misleading comments about default allocation
flags can be found in libdrm.
https://cgit.freedesktop.org/mesa/drm/tree/exynos/exynos_drm.c
See e.g. the comment for exynos_bo_create().
In my opinion, the whole approach to _set_ a bit to get non-contigious
Hello Seung-Woo,
looks good to me. Also, g2d_reset() never worked in the first place,
since the kernel driver rejects writes to SOFT_RESET_REG.
Reviewed-by: Tobias Jakobi
With best wishes,
Tobias
Seung-Woo Kim wrote:
> The function g2d_reset() is not anymore used after the com
Hello Seung-Woo,
Reviewed-by: Tobias Jakobi
With best wishes,
Tobias
Seung-Woo Kim wrote:
> As like the commit ecc2a097294d ("xf86drm: Fix type-punned pointer
> build warning"), this fixes following build warning.
>
>exynos_drm.c: In function 'exynos_handle_ev
:-)
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
, 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
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
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
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
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
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
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
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
++
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
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 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
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
>
__
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
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년 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월 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
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
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
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
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 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 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 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
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,
I'm not sure if I'm missing something here, but I don't see how this is
supposed to work.
This just multiplies the height of the drm_mode_fb_cmd2 object with the
number of buffers. Let's say I have width=1024, height=768, then now I
have a framebuffer which has height=2304 (in the num_buff
Hello,
I was wondering about the following. Wasn't there some strict
requirement about code going upstream, which also included that there
was a full open-source driver stack for it?
I don't see how this is the case for Mali, neither in the kernel, nor in
userspace. I'm aware that the Mali kernel
Hello Maxime,
Maxime Ripard wrote:
> Hi,
>
> On Thu, Feb 16, 2017 at 01:43:06PM +0100, Tobias Jakobi wrote:
>> I was wondering about the following. Wasn't there some strict
>> requirement about code going upstream, which also included that there
>> was a full
Hello Maxime,
Maxime Ripard wrote:
> Hi,
>
> On Thu, Feb 16, 2017 at 01:28:24PM +0100, Tobias Jakobi wrote:
>> Hello,
>>
>> I'm not sure if I'm missing something here, but I don't see how this is
>> supposed to work.
>>
>> This just m
Alexandre Belloni wrote:
> On 17/02/2017 at 13:45:44 +0100, Tobias Jakobi wrote:
>>> The device tree is a representation of the hardware itself. The state
>>> of the driver support doesn't change the hardware you're running on,
>>> just like your BIOS/UEFI o
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
.
While at it, unify wording of comments in the register header.
Signed-off-by: Tobias Jakobi
---
drivers/gpu/drm/exynos/exynos_mixer.c | 35 +++
drivers/gpu/drm/exynos/regs-mixer.h | 7 +--
2 files changed, 32 insertions(+), 10 deletions(-)
diff --git a
Convert if-statements to switch statement. Removes
duplicated code.
Signed-off-by: Tobias Jakobi
---
drivers/gpu/drm/exynos/exynos_mixer.c | 30 --
1 file changed, 8 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
b/drivers/gpu/drm
Hello Andrzej,
Andrzej Hajda wrote:
> Hi Tobias,
>
> On 03.03.2017 14:40, Tobias Jakobi wrote:
>> Convert if-statements to switch statement. Removes
>> duplicated code.
>>
>> Signed-off-by: Tobias Jakobi
>> ---
>> drivers/gpu/drm/exynos/exynos_mixe
Hello Andrzej,
Andrzej Hajda wrote:
> On 03.03.2017 14:40, Tobias Jakobi wrote:
>> The output stage of the mixer uses YCbCr for the internal
>> computations, which is the reason that some registers take
>> YCbCr related data as input. In particular this applies
>>
Convert if-statements to switch statement. Removes
duplicated code.
Reviewed-by: Andrzej Hajda
Signed-off-by: Tobias Jakobi
---
drivers/gpu/drm/exynos/exynos_mixer.c | 30 --
1 file changed, 8 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/exynos
.
While at it, unify wording of comments in the register header.
Signed-off-by: Tobias Jakobi
---
Changes in v2:
- use floating point values as input for the macros, as
suggested by Andrzej
- the floating point values have been tuned to exactly match
the values that are currently used
drivers
.
While at it, unify wording of comments in the register header.
Reviewed-by: Andrzej Hajda
Signed-off-by: Tobias Jakobi
---
Changes in v2:
- use floating point values as input for the macros, as
suggested by Andrzej
- the floating point values have been tuned to exactly match
the values that
Hello Krzysztof,
I was wondering about the benefit of this. From a quick look these are
all messages that end up in the kernel log / dmesg.
IIRC %pK does nothing there, since dmest_restrict is supposed to be used
to deny an unpriviliged user the access to the kernel log.
Or am I missing somethin
Krzysztof Kozlowski wrote:
> On Tue, Mar 14, 2017 at 08:01:41PM +0100, Tobias Jakobi wrote:
>> Hello Krzysztof,
>>
>> I was wondering about the benefit of this. From a quick look these are
>> all messages that end up in the kernel log / dmesg.
>>
>
Krzysztof Kozlowski wrote:
> On Tue, Mar 14, 2017 at 08:17:35PM +0100, Tobias Jakobi wrote:
>> Krzysztof Kozlowski wrote:
>>> On Tue, Mar 14, 2017 at 08:01:41PM +0100, Tobias Jakobi wrote:
>>>> Hello Krzysztof,
>>>>
>>>> I was wondering
Hello Andrzej,
note that i had already pointed Krzysztof to that documentation in my
previous mail.
- Tobias
Andrzej Hajda wrote:
> Hi Tobias,
>
> On 14.03.2017 21:41, Tobias Jakobi wrote:
>> Krzysztof Kozlowski wrote:
>>> On Tue, Mar 14, 2017 at 08:17:35PM +0
Gentle ping.
- Tobias
Tobias Jakobi wrote:
> Convert if-statements to switch statement. Removes
> duplicated code.
>
> Reviewed-by: Andrzej Hajda
> Signed-off-by: Tobias Jakobi
> ---
> drivers/gpu/drm/exynos/exynos_mixer.c | 30 --
> 1 fi
Gentle ping.
- Tobias
Tobias Jakobi wrote:
> The output stage of the mixer uses YCbCr for the internal
> computations, which is the reason that some registers take
> YCbCr related data as input. In particular this applies
> to MXR_BG_COLOR{0,1,2} and MXR_CM_COEFF_{Y,CB,CR}.
>
Hello Daniel,
I'm not getting any response from the Exynos DRM maintainer concerning
this patch. Since this is just a simple cleanup, and Andrzej has already
review, could you perhaps merge it through drm-misc?
With best wishes,
Tobias
Tobias Jakobi wrote:
> Convert if-statements t
Hello Daniel,
same question here. Patch doesn't introduce any functional changes (just
adds code documentation), so can you merge it through drm-misc?
With best wishes,
Tobias
Tobias Jakobi wrote:
> The output stage of the mixer uses YCbCr for the internal
> computations, which is
Hello Shuah,
Shuah Khan wrote:
> On 10/19/2016 04:27 PM, Shuah Khan wrote:
>> On 10/19/2016 08:16 AM, Inki Dae wrote:
>>> Hi Shuah,
>>>
>>> 2016-10-13 8:11 GMT+09:00 Shuah Khan :
Hi Inki,
On 08/15/2016 10:40 PM, Inki Dae wrote:
>>
>> okay the very first commit that add
Hello everyone,
any update on this issue? I can see that the old/custom wait-for-vblank
code is still in place.
Andrzej mentioned that this patch is quick/dirty, but isn't using DRM
core functionality actually the better approach?
With best wishes,
Tobias
Andrzej Hajda wrote:
> Exynos DRM devi
. I think one could even move more code there, like e.g.
mixer_cfg_scan() and mixer_cfg_rgb_fmt().
Anyway, feedback is appreciated a lot!
With best wishes,
Tobias
Tobias Jakobi (2):
drm/exynos: mixer: convert booleans to flags in mixer context
drm/exynos: mixer: configure layers once in
The mixer context struct already has a 'flags' field, so
we can use it to store the 'interlace', 'vp_enabled' and
'has_sclk' booleans.
We use the non-atomic helper functions to access these bits.
Signed-off-by: Tobias Jakobi
---
dr
Only manipulate the MXR_CFG and MXR_LAYER_CFG registers once
in mixer_cfg_layer().
Trigger this via atomic flush.
Signed-off-by: Tobias Jakobi
---
drivers/gpu/drm/exynos/exynos_mixer.c | 104 ++
drivers/gpu/drm/exynos/regs-mixer.h | 2 +
2 files changed, 69
Hello Andrzej,
first of all, I've noticed an error myself. mixer_disable() calls
mixer_disable_plane(), so it should also be modified. I'll send a v2 later.
Now to your points...
Andrzej Hajda wrote:
> On 19.09.2016 16:16, Tobias Jakobi wrote:
>> Only manipulate the MXR_CF
Hello,
I'm currently facing the following problem.
I want to use a devfreq device in one of the Exynos sub drivers, namely
the G2D sub driver. My current approach is to use
devfreq_get_devfreq_by_phandle() in g2d_probe(). But at the G2D probing
time the devfreq subsystem isn't initialized yet, an
Hi Andrzej,
Andrzej Hajda wrote:
> On 20.09.2016 14:34, Andrzej Hajda wrote:
>> On 20.09.2016 13:23, Tobias Jakobi wrote:
>>> Hello Andrzej,
>>>
>>> first of all, I've noticed an error myself. mixer_disable() calls
>>> mixer_disable_plane(), s
Hey Andrzej,
Andrzej Hajda wrote:
> On 21.09.2016 00:07, Tobias Jakobi wrote:
>> Hello,
>>
>> I'm currently facing the following problem.
>>
>> I want to use a devfreq device in one of the Exynos sub drivers, namely
>> the G
Hello,
here's v2 of this patchset. I've added two other 'cosmetic' patches as well.
Anyway, I have fixed up the second patch and integrated Andrzej's suggestions.
First patch is unmodified except for the Reviewed-By tag.
With best wishes,
Tobias
Tobias Jakobi (4):
d
The mixer context struct already has a 'flags' field, so
we can use it to store the 'interlace', 'vp_enabled' and
'has_sclk' booleans.
We use the non-atomic helper functions to access these bits.
Reviewed-by: Andrzej Hajda
Signed-off-by: Tobias Jakobi
--
-off-by: Tobias Jakobi
---
drivers/gpu/drm/exynos/exynos_mixer.c | 133 ++
drivers/gpu/drm/exynos/regs-mixer.h | 2 +
2 files changed, 90 insertions(+), 45 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
b/drivers/gpu/drm/exynos/exynos_mixer.c
A simple while loop should do the same here.
Signed-off-by: Tobias Jakobi
---
drivers/gpu/drm/exynos/exynos_mixer.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
b/drivers/gpu/drm/exynos/exynos_mixer.c
index c3dad66..4f39d6b
Apply some 'make-up' in g2d_probe().
Signed-off-by: Tobias Jakobi
---
drivers/gpu/drm/exynos/exynos_drm_g2d.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
index 73cd83f..410d
. the reason for the
aforementioned patch, is that sleep ops (suspend/resume) are now called during
runpm suspend time. I think that my approach should handle this situation.
In any case, feedback is much appreciated.
With best wishes,
Tobias
Tobias Jakobi (1):
drm/exynos: g2d: fix runtime PM
ch, should
something be in queue, continues its work, or just exits.
Signed-off-by: Tobias Jakobi
---
drivers/gpu/drm/exynos/exynos_drm_g2d.c | 235 +---
1 file changed, 186 insertions(+), 49 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
b/drivers/gpu/
Tobias Jakobi wrote:
> The commit b05984e21a7e000bf5074ace00d7a574944b2c16 broke
> operation of the G2D. After this commit the following
> happens.
> - exynos_g2d_exec_ioctl() prepares a runqueue node and
> calls g2d_exec_runqueue()
> - g2d_exec_runqueue() calls g2d_dma_
something be in queue, continues its work, or just exits.
Changes in v2:
- disable autosuspend mode again in g2d_remove()
- only get sync in g2d_runqueue_worker() if there is node
in the queue left
Signed-off-by: Tobias Jakobi
---
drivers/gpu/drm/exynos/exynos_drm_g
something be in queue, continues its work, or just exits.
Changes in v2:
- disable autosuspend mode again in g2d_remove()
- only get sync in g2d_runqueue_worker() if there is node
in the queue left
Changes in v3:
- actually delete node in g2d_remove_runqueue_nodes()
Signed-off-by: Tob
Dear Inki,
Inki Dae wrote:
>
>
> 2016ë
09ì 22ì¼ 23:57ì Tobias Jakobi ì´(ê°) ì´ ê¸:
>> Only manipulate the MXR_CFG and MXR_LAYER_CFG registers once
>> in mixer_cfg_layer().
>> Trigger this via atomic flush.
>>
>> Changes in v2:
>&g
in v3:
- simplify some conditions as suggested by Inki
- add docu to mixer_cfg_layer()
- fold switch statements into a single one
Signed-off-by: Tobias Jakobi
---
drivers/gpu/drm/exynos/exynos_mixer.c | 135 ++
drivers/gpu/drm/exynos/regs-mixer.h | 2 +
2 files
Hello Marek,
Marek Szyprowski wrote:
> Dear Tobias,
>
> On 2016-09-24 20:58, Tobias Jakobi wrote:
>> The commit b05984e21a7e000bf5074ace00d7a574944b2c16 broke
>> operation of the G2D. After this commit the following
>> happens.
>> - exynos_g2d_exec_ioc
Inki Dae wrote:
>
>
> 2016ë
09ì 26ì¼ 20:36ì Tobias Jakobi ì´(ê°) ì´ ê¸:
>> Only manipulate the MXR_CFG and MXR_LAYER_CFG registers once
>> in mixer_cfg_layer().
>> Trigger this via atomic flush.
>>
>> Changes in v2:
>> - issue mixer_cfg_lay
Hello Inki,
Inki Dae wrote:
> 2016ë
09ì 26ì¼ 20:36ì Tobias Jakobi ì´(ê°) ì´ ê¸:
>> Only manipulate the MXR_CFG and MXR_LAYER_CFG registers once
>> in mixer_cfg_layer().
>> Trigger this via atomic flush.
>>
>> Changes in v2:
>> - issue mixer_cfg
Hey Inki,
Inki Dae wrote:
> 2016ë
09ì 27ì¼ 14:40ì Tobias Jakobi ì´(ê°) ì´ ê¸:
>> Inki Dae wrote:
>>>
>>>
>>> 2016ë
09ì 26ì¼ 20:36ì Tobias Jakobi ì´(ê°) ì´ ê¸:
>>>> Only manipulate the MXR_CFG and MXR_LAYER_CFG registers once
Hello Marek,
Marek Szyprowski wrote:
> Hi Tobias,
>
> On 2016-09-26 16:15, Tobias Jakobi wrote:
>> Marek Szyprowski wrote:
>>> On 2016-09-24 20:58, Tobias Jakobi wrote:
>>>> The commit b05984e21a7e000bf5074ace00d7a574944b2c16 broke
>>>> opera
Hello everyone,
as discussed with Marek I have broken down my initial patch into smaller piecer.
Anyway, this series fixes a regression introduced by commit
b05984e21a7e000bf5074ace00d7a574944b2c16.
With best wishes,
Tobias
Tobias Jakobi (6):
Revert "drm/exynos: g2d: fix system and ru
runtime PM sync
(3) runtime PM core calls g2d_runtime_resume()
(4) g2d_runtime_resume() calls g2d_exec_runqueue(), which
loops back to (2)
Due to mutexes that are in place, a deadlock situation is created.
Signed-off-by: Tobias Jakobi
---
drivers/gpu/drm/exynos/exynos_drm_g2d.c | 29
Do all pm_runtime_{get,put}() calls in the runqueue worker.
Also keep track of the engine's idle/busy state.
Signed-off-by: Tobias Jakobi
---
drivers/gpu/drm/exynos/exynos_drm_g2d.c | 78 +++--
1 file changed, 56 insertions(+), 22 deletions(-)
diff --git a/dr
The driver might be closed (and/or removed) while there are still
nodes queued for processing.
Make sure to remove these nodes, which means all of them in
the case of g2d_remove() and only those belonging to the
corresponding process in g2d_close().
Signed-off-by: Tobias Jakobi
---
drivers/gpu
unmapped.
We have to take into account that the engine might be in an undefined
state, i.e. it hangs and doesn't become idle. In this case, we issue
a hardware reset to return the hardware and the driver context into a
proper state.
Signed-off-by: Tobias Jakobi
---
drivers/gpu/drm/e
()) and disabled (for put()). This
introduces performance regressions with we mitigate here.
Switch PM runtime to autosuspend, such that clock gating
and IOMMU control only happens when the engine is idle for
a 'long' time.
Signed-off-by: Tobias Jakobi
---
drivers/gpu/drm/exynos/exynos
The function is never called with zero 'runqueue_node'.
Signed-off-by: Tobias Jakobi
---
drivers/gpu/drm/exynos/exynos_drm_g2d.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
index 1a000c1..fa25
Hello Andrzej,
Andrzej Hajda wrote:
> On 27.09.2016 13:22, Tobias Jakobi wrote:
>> Hello Inki,
>>
>>
>> Inki Dae wrote:
>>> 2016ë
09ì 26ì¼ 20:36ì Tobias Jakobi ì´(ê°) ì´ ê¸:
>>>> Only manipulate the MXR_CFG and MXR_LAYER_CFG registers o
Hey Inki,
Inki Dae wrote:
>
>
> 2016ë
09ì 28ì¼ 01:52ì Tobias Jakobi ì´(ê°) ì´ ê¸:
>> Hello Andrzej,
>>
>>
>> Andrzej Hajda wrote:
>>> On 27.09.2016 13:22, Tobias Jakobi wrote:
>>>> Hello Inki,
>>>>
>>>>
&g
c execution mode
with the first version of the patch (the big one, before the split), and
there everything seemed to work.
So this should apply for this series as well... hopefully :)
With best wishes,
Tobias
> 2016ë
09ì 28ì¼ 00:50ì Tobias Jakobi ì´(ê°) ì´ ê¸:
>> Hello everyone
Hello Inki,
Inki Dae wrote:
>
>
> 2016ë
09ì 28ì¼ 08:31ì Inki Dae ì´(ê°) ì´ ê¸:
>>
>>
>> 2016ë
09ì 28ì¼ 01:52ì Tobias Jakobi ì´(ê°) ì´ ê¸:
>>> Hello Andrzej,
>>>
>>>
>>> Andrzej Hajda wrote:
Inki Dae wrote:
>
>
> 2016ë
09ì 28ì¼ 09:03ì Tobias Jakobi ì´(ê°) ì´ ê¸:
>> Hey Inki,
>>
>>
>> Inki Dae wrote:
>>>
>>>
>>> 2016ë
09ì 28ì¼ 01:52ì Tobias Jakobi ì´(ê°) ì´ ê¸:
>>>> Hello Andrzej,
>>&g
Hello Inki,
Inki Dae wrote:
>
>
> 2016ë
09ì 28ì¼ 09:03ì Tobias Jakobi ì´(ê°) ì´ ê¸:
>> Hey Inki,
>>
>>
>> Inki Dae wrote:
>>>
>>>
>>> 2016ë
09ì 28ì¼ 01:52ì Tobias Jakobi ì´(ê°) ì´ ê¸:
>>>> Hell
Hello Inki,
Inki Dae wrote:
>
>
> 2016ë
09ì 28ì¼ 09:12ì Tobias Jakobi ì´(ê°) ì´ ê¸:
>> Hello Inki,
>>
>>
>> Inki Dae wrote:
>>>
>>>
>>> 2016ë
09ì 28ì¼ 08:31ì Inki Dae ì´(ê°) ì´ ê¸:
>>>>
>>&g
Inki Dae wrote:
> 2016-09-28 18:06 GMT+09:00 Tobias Jakobi :
>> Hello Inki,
>>
>>
>> Inki Dae wrote:
>>>
>>>
>>> 2016ë
09ì 28ì¼ 09:03ì Tobias Jakobi ì´(ê°) ì´ ê¸:
>>>> Hey Inki,
>>>>
>>>>
>&g
Hello Marek,
Marek Szyprowski wrote:
> Dear Tobias,
>
>
> On 2016-09-27 17:50, Tobias Jakobi wrote:
>> Hello everyone,
>>
>> as discussed with Marek I have broken down my initial patch into
>> smaller piecer.
>>
>> Anyway, thi
obias
Tobias Jakobi (1):
drm/exynos: mixer: configure layers once in mixer_atomic_flush()
drivers/gpu/drm/exynos/exynos_mixer.c | 135 ++
drivers/gpu/drm/exynos/regs-mixer.h | 2 +
2 files changed, 92 insertions(+), 45 deletions(-)
--
2.7.3
an() and mixer_cfg_rgb_fmt()
as well.
To point out:
- this is not fixing any bugs
- this is not going to improve performance (at least not
noticeable)
This is merely some micro-optimisation and the aforementioned
consolidation of register manipulation.
Signed-off-by: Tobias Jakobi
---
drivers
1 - 100 of 621 matches
Mail list logo
