Re: [PATCH -next] drm/exynos: g2d: fix missing unlock on error in g2d_runqueue_worker()

2021-07-25 Thread Inki Dae
Sorry for late and thanks for fixing it.

Thanks,
Inki Dae

2021년 6월 16일 수요일, Wei Yongjun 님이 작성:

> Add the missing unlock before return from function g2d_runqueue_worker()
> in the error handling case.
>
> Fixes: 445d3bed75de ("drm/exynos: use pm_runtime_resume_and_get()")
> Reported-by: Hulk Robot 
> Signed-off-by: Wei Yongjun 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_g2d.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
> b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
> index cab4d2c370a7..0ed665501ac4 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
> @@ -897,13 +897,14 @@ static void g2d_runqueue_worker(struct work_struct
> *work)
> ret = pm_runtime_resume_and_get(g2d->dev);
> if (ret < 0) {
> dev_err(g2d->dev, "failed to enable G2D
> device.\n");
> -   return;
> +   goto out;
> }
>
> g2d_dma_start(g2d, g2d->runqueue_node);
> }
> }
>
> +out:
> mutex_unlock(&g2d->runqueue_mutex);
>  }
>
>
>


Re: [PATCH 03/12] drm/exynos: Don't set allow_fb_modifiers explicitly

2021-04-19 Thread Inki Dae


21. 4. 13. 오후 6:48에 Daniel Vetter 이(가) 쓴 글:
> Since
> 
> commit 890880ddfdbe256083170866e49c87618b706ac7
> Author: Paul Kocialkowski 
> Date:   Fri Jan 4 09:56:10 2019 +0100
> 
> drm: Auto-set allow_fb_modifiers when given modifiers at plane init
> 
> this is done automatically as part of plane init, if drivers set the
> modifier list correctly. Which is the case here.
> 
> Signed-off-by: Daniel Vetter 

Acked-by: Inki Dae 

Thanks,
Inki Dae

> Cc: Inki Dae 
> Cc: Joonyoung Shim 
> Cc: Seung-Woo Kim 
> Cc: Kyungmin Park 
> Cc: Krzysztof Kozlowski 
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-samsung-...@vger.kernel.org
> ---
>  drivers/gpu/drm/exynos/exynos_drm_fb.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c 
> b/drivers/gpu/drm/exynos/exynos_drm_fb.c
> index 64370b634cca..79fa3649185c 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fb.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fb.c
> @@ -177,7 +177,5 @@ void exynos_drm_mode_config_init(struct drm_device *dev)
>   dev->mode_config.funcs = &exynos_drm_mode_config_funcs;
>   dev->mode_config.helper_private = &exynos_drm_mode_config_helpers;
>  
> - dev->mode_config.allow_fb_modifiers = true;
> -
>   dev->mode_config.normalize_zpos = true;
>  }
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [RFC PATCH 06/17] drm/exynos: dsi: Handle exynos specifics via driver_data

2021-08-12 Thread Inki Dae
Hi,

21. 7. 26. 오전 2:25에 Sam Ravnborg 이(가) 쓴 글:
> On Sun, Jul 04, 2021 at 02:32:19PM +0530, Jagan Teki wrote:
>> Exynos DSI driver is actually a Samsung MIPI DSIM bridge
>> IP which is also used in i.MX8MM platforms.
>>
>> Right now the existing driver has some exynos drm specific
>> code bases like te_irq, crtc and component_ops.
>>
>> In order to switch this driver into a common bridge driver
>> We can see 2 options to handle the exynos specific code.
>>
>> A. Drop the component_ops, and rework other specifics.
>>This may lead to more foundation work as it requires
>>more changes in exynos drm drivers stack.
>>
>> B. Handle the exynos specifics via driver data, and make
>>the common bridge work in different platforms and plan
>>for option A in future.
>>
>> So, this patch is trying to add option B) changes to handle
>> exynos specifics via driver_data.
> 
> We really should find someone that has the time, energy, knowledge and
> hardware that can include device_link support once anf for all for
> bridges.
> Then we would avoid hacks like this.
> 
> I see no other options at the moment, but look forward for a better
> solution.
> 
>   Sam
> 

I'm not sure that it's correct to share this mipi dsi driver with I.MX8MM SoC 
even though it's a same IP because this MIPI DSI device isn't peripheral device 
but in SoC.
It would mean that Exynos MIPI DSI device depends on SoC architecture, and 
Exynos and I.MX series are totally different SoC. So if we share the same 
driver for the MIPI DSI device then many things we didn't predict may happen in 
the future. I don't want to make Jagan's efforts in vain for the community but 
clarify whether this is correct way or not. If this is only the way we have to 
go then we could more focus on actual solution not such hack. Impossible work 
with Jagan alone I think.

So let's get started with a question,
- Is MIPI-DSI bridge device or Encoder device? I think that MIPI-DSI is a 
Encoder device managed by atomic KMS. If MIPI-DSI should be handled as bridge 
device then does now drm bridge framework provide everything to share one 
driver with one more SoC? I mean something that drm bridge has to consider for 
such driver support, which is shared with one more SoC.  


And Display mode - VIDEO and COMMAND mode - is generic type of MIPI DSI, and 
also componentised subsystem is a generic solution to resolve probing order 
issue not Exynos specific feature. These are driver specific ones not Exynos 
SoC I think. As SoC specific things should be considered, I think MIPI DSI 
Driver - interrupt handler and probing order things are really specific to 
device driver - should be separated but we could share the control part of the 
device.

I was busy with other projects so didn't care of Linux DRM world so there may 
be my missing something.

Thanks,
Inki Dae

> 
>>
>> Signed-off-by: Jagan Teki 
>> ---
>>  drivers/gpu/drm/exynos/exynos_drm_dsi.c | 37 +++--
>>  1 file changed, 29 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
>> b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>> index 99a1b8c22313..53d878d4d2d7 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>> @@ -250,6 +250,7 @@ struct exynos_dsi_driver_data {
>>  unsigned int wait_for_reset;
>>  unsigned int num_bits_resol;
>>  const unsigned int *reg_values;
>> +bool exynos_specific;
>>  };
>>  
>>  struct exynos_dsi {
>> @@ -459,6 +460,7 @@ static const struct exynos_dsi_driver_data 
>> exynos3_dsi_driver_data = {
>>  .wait_for_reset = 1,
>>  .num_bits_resol = 11,
>>  .reg_values = reg_values,
>> +.exynos_specific = true,
>>  };
>>  
>>  static const struct exynos_dsi_driver_data exynos4_dsi_driver_data = {
>> @@ -471,6 +473,7 @@ static const struct exynos_dsi_driver_data 
>> exynos4_dsi_driver_data = {
>>  .wait_for_reset = 1,
>>  .num_bits_resol = 11,
>>  .reg_values = reg_values,
>> +.exynos_specific = true,
>>  };
>>  
>>  static const struct exynos_dsi_driver_data exynos5_dsi_driver_data = {
>> @@ -481,6 +484,7 @@ static const struct exynos_dsi_driver_data 
>> exynos5_dsi_driver_data = {
>>  .wait_for_reset = 1,
>>  .num_bits_resol = 11,
>>  .reg_values = reg_values,
>> +.exynos_specific = true,
>>  };
>>  
>>  static const struct exynos_dsi_driver_data exynos5433_dsi_driver_data = {
>> @@ -492,6 +496,7 @@ static const struct exynos_d

Re: [RFC PATCH 06/17] drm/exynos: dsi: Handle exynos specifics via driver_data

2021-08-17 Thread Inki Dae
Hi Laurent,

21. 8. 13. 오후 9:16에 Laurent Pinchart 이(가) 쓴 글:
> Hi Inki,
> 
> On Fri, Aug 13, 2021 at 03:50:56PM +0900, Inki Dae wrote:
>> 21. 7. 26. 오전 2:25에 Sam Ravnborg 이(가) 쓴 글:
>>> On Sun, Jul 04, 2021 at 02:32:19PM +0530, Jagan Teki wrote:
>>>> Exynos DSI driver is actually a Samsung MIPI DSIM bridge
>>>> IP which is also used in i.MX8MM platforms.
>>>>
>>>> Right now the existing driver has some exynos drm specific
>>>> code bases like te_irq, crtc and component_ops.
>>>>
>>>> In order to switch this driver into a common bridge driver
>>>> We can see 2 options to handle the exynos specific code.
>>>>
>>>> A. Drop the component_ops, and rework other specifics.
>>>>This may lead to more foundation work as it requires
>>>>more changes in exynos drm drivers stack.
>>>>
>>>> B. Handle the exynos specifics via driver data, and make
>>>>the common bridge work in different platforms and plan
>>>>for option A in future.
>>>>
>>>> So, this patch is trying to add option B) changes to handle
>>>> exynos specifics via driver_data.
>>>
>>> We really should find someone that has the time, energy, knowledge and
>>> hardware that can include device_link support once anf for all for
>>> bridges.
>>> Then we would avoid hacks like this.
>>>
>>> I see no other options at the moment, but look forward for a better
>>> solution.
>>
>> I'm not sure that it's correct to share this mipi dsi driver with
>> I.MX8MM SoC even though it's a same IP because this MIPI DSI device
>> isn't peripheral device but in SoC.
>>
>> It would mean that Exynos MIPI DSI device depends on SoC architecture,
>> and Exynos and I.MX series are totally different SoC. So if we share
>> the same driver for the MIPI DSI device then many things we didn't
>> predict may happen in the future.
> 
> Isn't that true for external components true thought ? Any driver shared
> by multiple systems will face this issue, where it will be developed
> with some use cases in mind, and regressions may happen when the driver
> is then extended to support other use cases not required for the
> original platform.
> 
> In general we don't want multiple drivers for the same IP core unless
> there are valid technical reasons for that. It's the whole point of the
> device tree, being able to describe how IP cores are integrated, so that
> code can be reused across platforms. Of course, integration differences
> between SoCs can sometimes vary wildly and require some amount of glue
> code.

Agree with you. It would be a good chance to clarify what we need to share same 
device driver without any regress in this time.

> 
>> I don't want to make Jagan's efforts
>> in vain for the community but clarify whether this is correct way or
>> not. If this is only the way we have to go then we could more focus on
>> actual solution not such hack. Impossible work with Jagan alone I
>> think.
> 
> I do agree that we need more correct solutions and less hacks in general
> :-) The issues faced on Exynos also exist on other platforms, so it
> would be much better to solve them well once that duplicating
> implementations with less test coverage and reviews. There have been
> efforts in the past to address some of these issues, which have resulted
> in solutions such as the component framework. However, I'd argued that

Yeah, most of ARM systems have various separate devices but DRM subsytem wanted 
each ARM driver to work like one device driver for all of them. And the 
component framework has been adopted by several ARM DRM drivers for it 
including Exynos.

> we've never taken it to the last step, and have always stopped with half
> solutions. The component framework, for instance, is painful to use, and
> the handling of .remove() in most drivers is completely broken because
> of that (not just because of that though, we have issues in the DRM core
> that make hot-unplug just impossible to handle safetly).

This may be one of what we have to clarify. I think ARM DRM drivers need 
component framework or similar thing to address probing order issue.
So would we need to enhance existing compoent framework to be suitable for DRM 
subsystem, or introducing an alternative solution?

Otherwise, would there be some way to address the probing order issue without 
the compoment framework?

> 
>> So let's get started with a question,
>> - Is MIPI-DSI bridge device or Encoder device? I think that MIPI-DSI
>> is a Encoder 

[GIT PULL] exynos-drm-next

2021-08-21 Thread Inki Dae
Hi Dave,

   Just two fixups - fixing one build warning and missing unlock,
   and one cleanup - replaceing atomic_t with refcount_t.

   Please kindly let me know if there is any problem.

Thanks,
Inki Dae

The following changes since commit 397ab98e2d69cede8a28eab77a171983d14e:

  Merge tag 'drm-msm-next-2021-08-12' of https://gitlab.freedesktop.org/drm/msm 
into drm-next (2021-08-17 10:53:52 +1000)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos 
tags/exynos-drm-next-for-v5.15

for you to fetch changes up to c626f386428bbe06476b0b497c1330aa4463:

  drm/exynos: Always initialize mapping in exynos_drm_register_dma() 
(2021-08-22 01:56:39 +0900)


Two fixups
- Fix missing unlock issue in exynos_drm_g2d.c
- Fix a build warning in exynos_drm_dma.c

One cleanup
- Replace atomic_t with refcount_t in exynos_drm_g2d.c


Nathan Chancellor (1):
  drm/exynos: Always initialize mapping in exynos_drm_register_dma()

Wei Yongjun (1):
  drm/exynos: g2d: fix missing unlock on error in g2d_runqueue_worker()

Xiyu Yang (1):
  drm/exynos: Convert from atomic_t to refcount_t on 
g2d_cmdlist_userptr->refcount

 drivers/gpu/drm/exynos/exynos_drm_dma.c |  2 ++
 drivers/gpu/drm/exynos/exynos_drm_g2d.c | 14 --
 2 files changed, 10 insertions(+), 6 deletions(-)


Re: [PATCH] drm/exynos/decon5433: Clean up GPIO includes

2021-03-14 Thread Inki Dae
Hi Tian Tao,

21. 3. 2. 오후 12:03에 Tian Tao 이(가) 쓴 글:
> remove the legacy GPIO headers  but what it really
> uses is  since only gpio_desc structs are ever
> referenced.

This driver doesn't reference even linux/gpio/consumer.h so could you drop only 
of_gpio.h inclusion?

Thanks,
Inki Dae

> 
> Signed-off-by: Tian Tao 
> ---
>  drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c 
> b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> index 1f79bc2..9fc51a6 100644
> --- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> +++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> @@ -11,9 +11,9 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH] drm/exynos/decon5433: Clean up GPIO includes

2021-03-15 Thread Inki Dae


21. 3. 15. 오후 3:45에 tiantao (H) 이(가) 쓴 글:
> 
> 在 2021/3/15 14:35, Inki Dae 写道:
>> Hi Tian Tao,
>>
>> 21. 3. 2. 오후 12:03에 Tian Tao 이(가) 쓴 글:
>>> remove the legacy GPIO headers  but what it really
>>> uses is  since only gpio_desc structs are ever
>>> referenced.
>> This driver doesn't reference even linux/gpio/consumer.h so could you drop 
>> only of_gpio.h inclusion?
> 
> Thanks for helping to review patch,I've posted a new patch to fix this 
> problem  If you can give me review-by, I can help push to drm-misc.

I can merge this patch and other one[1] to exynos drm tree after review, and 
will have a pull-request soon so no need to land to drm-misc tree.
Let's not bother Daniel. :)

[1] 
https://patchwork.kernel.org/project/dri-devel/patch/1615549385-33784-1-git-send-email-tiant...@hisilicon.com/

Thanks,
Inki Dae

> 
> Subject: [PATCH] drm/exynos/decon5433: Remove the unused include statements
> 
> This driver doesn't reference of_gpio.h, so drop it.
> 
> Signed-off-by: Tian Tao 
> ---
>  drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c 
> b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> index 1f79bc2..1510e4e 100644
> --- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> +++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> @@ -13,7 +13,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> 
>>
>> Thanks,
>> Inki Dae
>>
>>> Signed-off-by: Tian Tao 
>>> ---
>>>   drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 2 +-
>>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c 
>>> b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
>>> index 1f79bc2..9fc51a6 100644
>>> --- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
>>> +++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
>>> @@ -11,9 +11,9 @@
>>>   #include 
>>>   #include 
>>>   #include 
>>> +#include 
>>>   #include 
>>>   #include 
>>> -#include 
>>>   #include 
>>>   #include 
>>>   #include 
>>>
>> .
>>
> 
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[GIT PULL] exynos-drm-fixes

2021-03-29 Thread Inki Dae
Hi Dave,

   Just one cleanup to drop unused header inclusion.

   Please kindly let me know if there is any problem.

Thanks,
Inki Dae

The following changes since commit 09d78dde88ef95a27b54a6e450ee700ccabdf39d:

  Merge tag 'drm-msm-fixes-2021-02-25' of 
https://gitlab.freedesktop.org/drm/msm into drm-fixes (2021-03-26 13:04:17 
+1000)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos 
tags/exynos-drm-fixes-for-v5.12-rc6

for you to fetch changes up to 6161a435c1910d07ee00cc25af010889010e1f08:

  drm/exynos/decon5433: Remove the unused include statements (2021-03-29 
19:53:23 +0900)


Just one cleanup which drops of_gpio.h inclusion.
- This header file isn't used anymore so drop it.


Tian Tao (1):
  drm/exynos/decon5433: Remove the unused include statements

 drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 1 -
 1 file changed, 1 deletion(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[GIT PULL] exynos-drm-next

2021-03-30 Thread Inki Dae
Hi Dave,

   Just one patch to clean up the use of request_irq funtion.

   This patch has a dependency of one patch[1] so merged it on top of
   tag 'irq-no-autoen-2021-03-25' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip after top of drm next 
branch.

   Please kindly let me know if there is any problem.

Thanks,
Inki Dae

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next-history.git/commit/?id=cbe16f35bee6880becca6f20d2ebf6b457148552

The following changes since commit 99e5730dd2b11fedc890bbc9c803f69aad24e3ca:

  Merge tag 'irq-no-autoen-2021-03-25' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip into exynos-drm-next 
(2021-03-29 20:35:13 +0900)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos 
tags/exynos-drm-next-for-v5.13

for you to fetch changes up to a4e5eed2c6a689ef2b6ad8d7ae86665c69039379:

  drm/exynos: move to use request_irq by IRQF_NO_AUTOEN flag (2021-03-29 
20:37:17 +0900)


One cleanup
- Based on the patch[1], clean up the use of request_irq function
  series.

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next-history.git/commit/?id=cbe16f35bee6880becca6f20d2ebf6b457148552


Tian Tao (1):
  drm/exynos: move to use request_irq by IRQF_NO_AUTOEN flag

 drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 4 ++--
 drivers/gpu/drm/exynos/exynos_drm_dsi.c   | 7 +++
 2 files changed, 5 insertions(+), 6 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[GIT PULL] exynos-drm-fixes

2021-05-19 Thread Inki Dae
Hi Dave,

   Just one fixup to kerneldoc and two cleanups to drop redundant error
   messages.

   Please kindly let me know if there is any problem.

Thanks,
Inki Dae

The following changes since commit d07f6ca923ea0927a1024dfccafc5b53b61cfecc:

  Linux 5.13-rc2 (2021-05-16 15:27:44 -0700)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos 
tags/exynos-drm-fixes-for-v5.13-rc3

for you to fetch changes up to a470c5665b3b918c31bcc912234862803b10ba00:

  drm/exynos/decon5433: Remove redundant error printing in 
exynos5433_decon_probe() (2021-05-17 20:31:39 +0900)


Fixup
- Correct kerneldoc of fimd_shadow_protect_win function.

Cleanup
- Drop redundant error messages.


Krzysztof Kozlowski (1):
  drm/exynos: correct exynos_drm_fimd kerneldoc

Zhen Lei (2):
  drm/exynos: Remove redundant error printing in exynos_dsi_probe()
  drm/exynos/decon5433: Remove redundant error printing in 
exynos5433_decon_probe()

 drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 4 +---
 drivers/gpu/drm/exynos/exynos_drm_dsi.c   | 4 +---
 drivers/gpu/drm/exynos/exynos_drm_fimd.c  | 2 +-
 3 files changed, 3 insertions(+), 7 deletions(-)


[GIT PULL] exynos-drm-fixes

2020-11-23 Thread Inki Dae
Hi Dave,

   Just one bug fix to a build error due to common framework dependency.

   Please kindly let me know if there is any problem.


Thanks,
Inki Dae


The following changes since commit 6600f9d52213b5c3455481b5c9e61cf5e305c0e6:

  Merge tag 'drm-intel-fixes-2020-11-19' of 
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes (2020-11-20 11:21:54 
+1000)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos 
tags/exynos-drm-fixes-for-v5.10-rc6

for you to fetch changes up to e2d3d2e904ad3d381753798dcd5cae03e3c47242:

  drm/exynos: depend on COMMON_CLK to fix compile tests (2020-11-23 10:01:32 
+0900)


One bug fix
. Add COMMON_CLK dependency to fix a build error below,
/usr/bin/mips-linux-gnu-ld: drivers/gpu/drm/exynos/exynos_mixer.o: in 
function `mixer_bind':
exynos_mixer.c:(.text+0x958): undefined reference to `clk_set_parent'


Krzysztof Kozlowski (1):
  drm/exynos: depend on COMMON_CLK to fix compile tests

 drivers/gpu/drm/exynos/Kconfig | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[GIT PULL] exynos-drm-next

2020-11-30 Thread Inki Dae
Hi Dave,

   Just a new mode support for HDMI and two clenups.

   Please kindly let me know if there is any problem.

Thanks,
Inki Dae


The following changes since commit 22f8c80566c4a29a0d8b5ebf24aa1fd1679b39e5:

  Merge tag 'drm-misc-next-2020-11-18' of 
ssh://git.freedesktop.org/git/drm/drm-misc into drm-next (2020-11-27 09:36:33 
+1000)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos 
tags/exynos-drm-next-for-v5.11

for you to fetch changes up to e11e6df2a86779cfc73c4fb2e957ff7a70d89f68:

  drm/exynos: use exynos_dsi as drvdata (2020-12-01 11:38:29 +0900)


Add a new mode support for HDMI
- support for 1920x1200x60Hz mode.

Cleanups
- Drop in_bridge_node from exynos_dsi
- Use a exynos_dsi object instead of a encoder object as drvdata.


Marek Szyprowski (1):
  drm/exynos/hdmi: add support for 1920x1200@60Hz mode

Michael Tretter (2):
  drm/exynos: remove in_bridge_node from exynos_dsi
  drm/exynos: use exynos_dsi as drvdata

 drivers/gpu/drm/exynos/exynos_drm_dsi.c | 31 ---
 drivers/gpu/drm/exynos/exynos_hdmi.c|  9 +
 2 files changed, 21 insertions(+), 19 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v2 03/16] drm/exynos: use exynos_dsi as drvdata

2020-11-08 Thread Inki Dae


20. 11. 8. 오전 7:24에 Sam Ravnborg 이(가) 쓴 글:
> On Fri, Sep 11, 2020 at 03:54:00PM +0200, Michael Tretter wrote:
>> Use the exynos_dsi as drvdata instead of the encoder to further decouple
>> the driver from the encoder.
>>
>> Signed-off-by: Michael Tretter 
> Reviewed-by: Sam Ravnborg 
> 
> Likewise, the exynos people are expected to pick this up.

Cleanup patch so picked it up.

Thanks,
Inki Dae


> 
>   Sam
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v2 02/16] drm/exynos: remove in_bridge_node from exynos_dsi

2020-11-08 Thread Inki Dae


20. 11. 8. 오전 7:19에 Sam Ravnborg 이(가) 쓴 글:
> On Fri, Sep 11, 2020 at 03:53:59PM +0200, Michael Tretter wrote:
>> We do not need to keep a reference to the in_bridge_node, but we can
>> simply drop it, once we found and attached the previous bridge.
>>
>> Signed-off-by: Michael Tretter 
> Reviewed-by: Sam Ravnborg 
> 
> Note: I expect exynos people to pick it up.

Cleanup patch so picked it up.

Thanks,
Inki Dae

> 
>   Sam
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://protect2.fireeye.com/v1/url?k=0ba8a77f-54339e66-0ba92c30-000babff3793-ff3020eaa6c16149&q=1&e=eadf6490-86ef-461e-b39a-892e3aec0194&u=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fdri-devel
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v2 04/16] drm/exynos: extract helper functions for probe

2020-11-08 Thread Inki Dae


20. 11. 8. 오전 7:27에 Sam Ravnborg 이(가) 쓴 글:
> On Fri, Sep 11, 2020 at 03:54:01PM +0200, Michael Tretter wrote:
>> As the driver shall be usable with drivers that use the component
>> framework and drivers that don't, split the common probing code into a
>> separate function that can be called from different locations.
>>
>> Signed-off-by: Michael Tretter 
> Reviewed-by: Sam Ravnborg 

This patch and other are related to what this patch series do. However, this 
patch makes Exynos board not working yet.
So excepting patches 2 to 3, I will wait for that this patch series will be 
fixed and reviewed more.

Thanks,
Inki Dae

> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v2 00/16] drm/exynos: Convert driver to drm bridge

2020-11-08 Thread Inki Dae
Hi Michael,

Thanks for your contribution.

20. 9. 11. 오후 10:53에 Michael Tretter 이(가) 쓴 글:
> This is v2 of the series to convert the Exynos MIPI DSI driver into a drm
> bridge and make it usable with other drivers. Although the driver is
> converted, it still supports the component framework API to stay compliant
> with the Exynos DRM driver.
> 
> The Exynos MIPI DSI Phy is also found on the i.MX8M Mini. However, on the
> i.MX8M Mini, the bridge is driven by an LCDIF display controller instead of
> the Exynos Decon. The driver for the LCDIF does not use the component
> framework, but uses drm bridges.
> 
> I don't have any Exynos SoC to actually test the series. I build a dummy to
> test the bridge with a component driver, to make sure that at least the
> initialization is working. Furthermore, tested the driver as a bridge with a
> few additional unfinished patches on the i.MX8M Mini EVK. However, somebody
> should verify that the driver is still working on Exynos hardware.
> 
> I also changed the order of the patches to first make the driver more platform
> independent (patches 2 to 8), then convert to a drm bridge driver (patches 10

Just a fundamental question,
A MIPI-DSI(Display Serial Interface) bus device would be one of an encoder type 
of devices not bridge such as DSI to LVDS and LVDS to DSI bridge devices, and 
also image enhancer and image compressor in case of Exynos.
Why do you want to convert such MIPI-DSI driver to bridge type of driver? Seems 
not sensible. The reason would be just to share MIPI-DSI phy driver for Exynos 
with i.MX8M Mini?

Thanks,
Inki Dae


> to 13) and finally expose the API, split the code and move the platform
> independent driver to the bridges (patches 14 - 16). Hopefully this simplifies
> testing/bisecting and helps me to understand potential error reports.
> 
> Also I added host_ops for attach/detach and the tearing effect handler to make
> the calls into the platform code more visible.
> 
> Furthermore, the series should now apply to linux-next and correctly build the
> exynos_defconfig.
> 
> Thanks,
> 
> Michael
> 
> Changelog:
> 
> v2:
> - rebase on linux-next
> - verify with exynos_defconfig
> - fix crashes reported by Marek Szyprowski Exynos3250-based Rinato
> - reorder patches
> - add host_ops for platform specific code
> - roughly test component framework integration with dummy
> 
> Michael Tretter (16):
>   drm/encoder: remove obsolete documentation of bridge
>   drm/exynos: remove in_bridge_node from exynos_dsi
>   drm/exynos: use exynos_dsi as drvdata
>   drm/exynos: extract helper functions for probe
>   drm/exynos: move dsi host registration to probe
>   drm/exynos: shift register values to fields on write
>   drm/exynos: use identifier instead of register offsets
>   drm/exynos: add host_ops callback for platform drivers
>   drm/exynos: add callback for tearing effect handler
>   drm/exynos: implement a drm bridge
>   drm/exynos: convert encoder functions to bridge function
>   drm/exynos: configure mode on drm bridge
>   drm/exynos: get encoder from bridge whenever possible
>   drm/exynos: add API functions for platform drivers
>   drm/exynos: split out platform specific code
>   drm/exynos: move bridge driver to bridges
> 
>  drivers/gpu/drm/bridge/Kconfig  |9 +
>  drivers/gpu/drm/bridge/Makefile |1 +
>  drivers/gpu/drm/bridge/samsung-dsim.c   | 1790 +
>  drivers/gpu/drm/exynos/Kconfig  |5 +-
>  drivers/gpu/drm/exynos/exynos_drm_dsi.c | 1927 ++-
>  include/drm/bridge/samsung-dsim.h   |   64 +
>  include/drm/drm_encoder.h   |1 -
>  7 files changed, 2027 insertions(+), 1770 deletions(-)
>  create mode 100644 drivers/gpu/drm/bridge/samsung-dsim.c
>  create mode 100644 include/drm/bridge/samsung-dsim.h
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v2 00/16] drm/exynos: Convert driver to drm bridge

2020-11-10 Thread Inki Dae


20. 11. 10. 오후 5:13에 Michael Tretter 이(가) 쓴 글:
> On Mon, 09 Nov 2020 12:15:39 +0900, Inki Dae wrote:
>> 20. 9. 11. 오후 10:53에 Michael Tretter 이(가) 쓴 글:
>>> This is v2 of the series to convert the Exynos MIPI DSI driver into a drm
>>> bridge and make it usable with other drivers. Although the driver is
>>> converted, it still supports the component framework API to stay compliant
>>> with the Exynos DRM driver.
>>>
>>> The Exynos MIPI DSI Phy is also found on the i.MX8M Mini. However, on the
>>> i.MX8M Mini, the bridge is driven by an LCDIF display controller instead of
>>> the Exynos Decon. The driver for the LCDIF does not use the component
>>> framework, but uses drm bridges.
>>>
>>> I don't have any Exynos SoC to actually test the series. I build a dummy to
>>> test the bridge with a component driver, to make sure that at least the
>>> initialization is working. Furthermore, tested the driver as a bridge with a
>>> few additional unfinished patches on the i.MX8M Mini EVK. However, somebody
>>> should verify that the driver is still working on Exynos hardware.
>>>
>>> I also changed the order of the patches to first make the driver more 
>>> platform
>>> independent (patches 2 to 8), then convert to a drm bridge driver (patches 
>>> 10
>>
>> Just a fundamental question, A MIPI-DSI(Display Serial Interface) bus device
>> would be one of an encoder type of devices not bridge such as DSI to LVDS
>> and LVDS to DSI bridge devices, and also image enhancer and image compressor
>> in case of Exynos.
> 
> I don't understand, why the MIPI-DSI bus device would be an encoder type and
> DSI to LVDS or MIPI-DSI to HDMI would be bridges. For example, the device tree
> documentation for the DSIM states that the DSIM receives RGB video as input
> and produces MIPI-DSI as output. Thus, the DSIM is basically a parallel RGB to

MIPI-DSI receives RGB video as input and encodes it to MIPI packet and then 
transfers the packet to MIPI panel.
And finally, MIPI panel decodes the packet and updates it - RGB data - on its 
SRAM.

MIPI-DSI driver programs how the RGB video should be made as MIPI packet. For 
more detail, you could refer to MIPI-DSI spec.
This would be why we handle MIPI-DSI driver as an encoder like other ARM SoC 
DRM drivers did.

> MIPI-DSI bridge and the encoder is the LCD controller that encodes the video
> data as parallel RGB.
> 
> On the i.MX8MM, the LCDIF is already the encoder. On Exynos, the series
> implements the encoder in the platform glue, but in the end the encoder can
> probably be moved to the DECON.

As you know, Display controller can transfer RGB video to various devices such 
as RGB panel, CPU panel, LVDS panel via LVDS bridge, MIPI panel via MIPI-DSI 
bus device, and so on like below,

Display Controller --> RGB panel or CPU panel.
Display Controller --> LVDS bridge --> LVDS panel.
Display Controller --> MIPI DSI bus device --> MIPI Panel.
...

Display controller drivers such as FIMD and DECON series in case of Exynos 
don't create an encoder driver-internally instead of it depends on Display 
pipeline configuration - what kind of Display panel is used.
In fact, if the Display pipeline uses RGB panel or CPU panel without Display 
bus device such as MIPI-DSI, then FIMD and DECON drivers create an encoder for 
it internally - just we separated the code to consider other type of panels.

On the I.MX8MM, could you share how to handle an encoder if some board has only 
MIPI-DSI panel, and in this case, where is an encoder for it created? I looked 
into I.MX8MM DRM driver but didn't find MIPI-DSI driver.
Seems that they support only parallel display, HDMI and LVDS panel.

Thanks,
Inki Dae

> 
>> Why do you want to convert such MIPI-DSI driver to bridge type of driver?
>> Seems not sensible. The reason would be just to share MIPI-DSI phy driver
>> for Exynos with i.MX8M Mini?
> 
> Yes, the reason is that the driver should be shared between Exynos and
> i.MX8MM. It is the same IP and I don't see a reason why we should introduce
> another driver for the same IP if the driver works for both SoCs.
> 
> Michael
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v2 00/16] drm/exynos: Convert driver to drm bridge

2020-11-10 Thread Inki Dae


20. 11. 11. 오후 12:04에 Inki Dae 이(가) 쓴 글:
> 
> 
> 20. 11. 10. 오후 5:13에 Michael Tretter 이(가) 쓴 글:
>> On Mon, 09 Nov 2020 12:15:39 +0900, Inki Dae wrote:
>>> 20. 9. 11. 오후 10:53에 Michael Tretter 이(가) 쓴 글:
>>>> This is v2 of the series to convert the Exynos MIPI DSI driver into a drm
>>>> bridge and make it usable with other drivers. Although the driver is
>>>> converted, it still supports the component framework API to stay compliant
>>>> with the Exynos DRM driver.
>>>>
>>>> The Exynos MIPI DSI Phy is also found on the i.MX8M Mini. However, on the
>>>> i.MX8M Mini, the bridge is driven by an LCDIF display controller instead of
>>>> the Exynos Decon. The driver for the LCDIF does not use the component
>>>> framework, but uses drm bridges.
>>>>
>>>> I don't have any Exynos SoC to actually test the series. I build a dummy to
>>>> test the bridge with a component driver, to make sure that at least the
>>>> initialization is working. Furthermore, tested the driver as a bridge with 
>>>> a
>>>> few additional unfinished patches on the i.MX8M Mini EVK. However, somebody
>>>> should verify that the driver is still working on Exynos hardware.
>>>>
>>>> I also changed the order of the patches to first make the driver more 
>>>> platform
>>>> independent (patches 2 to 8), then convert to a drm bridge driver (patches 
>>>> 10
>>>
>>> Just a fundamental question, A MIPI-DSI(Display Serial Interface) bus device
>>> would be one of an encoder type of devices not bridge such as DSI to LVDS
>>> and LVDS to DSI bridge devices, and also image enhancer and image compressor
>>> in case of Exynos.
>>
>> I don't understand, why the MIPI-DSI bus device would be an encoder type and
>> DSI to LVDS or MIPI-DSI to HDMI would be bridges. For example, the device 
>> tree
>> documentation for the DSIM states that the DSIM receives RGB video as input
>> and produces MIPI-DSI as output. Thus, the DSIM is basically a parallel RGB 
>> to
> 
> MIPI-DSI receives RGB video as input and encodes it to MIPI packet and then 
> transfers the packet to MIPI panel.
> And finally, MIPI panel decodes the packet and updates it - RGB data - on its 
> SRAM.
> 
> MIPI-DSI driver programs how the RGB video should be made as MIPI packet. For 
> more detail, you could refer to MIPI-DSI spec.
> This would be why we handle MIPI-DSI driver as an encoder like other ARM SoC 
> DRM drivers did.
> 
>> MIPI-DSI bridge and the encoder is the LCD controller that encodes the video
>> data as parallel RGB.
>>
>> On the i.MX8MM, the LCDIF is already the encoder. On Exynos, the series
>> implements the encoder in the platform glue, but in the end the encoder can
>> probably be moved to the DECON.
> 
> As you know, Display controller can transfer RGB video to various devices 
> such as RGB panel, CPU panel, LVDS panel via LVDS bridge, MIPI panel via 
> MIPI-DSI bus device, and so on like below,
> 
> Display Controller --> RGB panel or CPU panel.
> Display Controller --> LVDS bridge --> LVDS panel.
> Display Controller --> MIPI DSI bus device --> MIPI Panel.
> ...
> 
> Display controller drivers such as FIMD and DECON series in case of Exynos 
> don't create an encoder driver-internally instead of it depends on Display 
> pipeline configuration - what kind of Display panel is used.
> In fact, if the Display pipeline uses RGB panel or CPU panel without Display 
> bus device such as MIPI-DSI, then FIMD and DECON drivers create an encoder 
> for it internally - just we separated the code to consider other type of 
> panels.
> 
> On the I.MX8MM, could you share how to handle an encoder if some board has 
> only MIPI-DSI panel, and in this case, where is an encoder for it created? I 
> looked into I.MX8MM DRM driver but didn't find MIPI-DSI driver.
> Seems that they support only parallel display, HDMI and LVDS panel.

One more thing, If I saw correctly, the LVDS driver of IMX DRM - lmx_ldb - 
creates an encoder internally like MIPI-DSI driver of Exynos DRM did.

> 
> Thanks,
> Inki Dae
> 
>>
>>> Why do you want to convert such MIPI-DSI driver to bridge type of driver?
>>> Seems not sensible. The reason would be just to share MIPI-DSI phy driver
>>> for Exynos with i.MX8M Mini?
>>
>> Yes, the reason is that the driver should be shared between Exynos and
>> i.MX8MM. It is the same IP and I don't see a reason why we should introduce
>> another driver for the same IP if the driver works for both SoCs.
>>
>> Michael
>>
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v2 00/16] drm/exynos: Convert driver to drm bridge

2020-11-13 Thread Inki Dae


20. 11. 11. 오후 7:18에 Michael Tretter 이(가) 쓴 글:
> On Wed, 11 Nov 2020 12:11:15 +0900, Inki Dae wrote:
>> 20. 11. 11. 오후 12:04에 Inki Dae 이(가) 쓴 글:
>>> 20. 11. 10. 오후 5:13에 Michael Tretter 이(가) 쓴 글:
>>>> On Mon, 09 Nov 2020 12:15:39 +0900, Inki Dae wrote:
>>>>> 20. 9. 11. 오후 10:53에 Michael Tretter 이(가) 쓴 글:
>>>>>> This is v2 of the series to convert the Exynos MIPI DSI driver into a drm
>>>>>> bridge and make it usable with other drivers. Although the driver is
>>>>>> converted, it still supports the component framework API to stay 
>>>>>> compliant
>>>>>> with the Exynos DRM driver.
>>>>>>
>>>>>> The Exynos MIPI DSI Phy is also found on the i.MX8M Mini. However, on the
>>>>>> i.MX8M Mini, the bridge is driven by an LCDIF display controller instead 
>>>>>> of
>>>>>> the Exynos Decon. The driver for the LCDIF does not use the component
>>>>>> framework, but uses drm bridges.
>>>>>>
>>>>>> I don't have any Exynos SoC to actually test the series. I build a dummy 
>>>>>> to
>>>>>> test the bridge with a component driver, to make sure that at least the
>>>>>> initialization is working. Furthermore, tested the driver as a bridge 
>>>>>> with a
>>>>>> few additional unfinished patches on the i.MX8M Mini EVK. However, 
>>>>>> somebody
>>>>>> should verify that the driver is still working on Exynos hardware.
>>>>>>
>>>>>> I also changed the order of the patches to first make the driver more 
>>>>>> platform
>>>>>> independent (patches 2 to 8), then convert to a drm bridge driver 
>>>>>> (patches 10
>>>>>
>>>>> Just a fundamental question, A MIPI-DSI(Display Serial Interface) bus 
>>>>> device
>>>>> would be one of an encoder type of devices not bridge such as DSI to LVDS
>>>>> and LVDS to DSI bridge devices, and also image enhancer and image 
>>>>> compressor
>>>>> in case of Exynos.
>>>>
>>>> I don't understand, why the MIPI-DSI bus device would be an encoder type 
>>>> and
>>>> DSI to LVDS or MIPI-DSI to HDMI would be bridges. For example, the device 
>>>> tree
>>>> documentation for the DSIM states that the DSIM receives RGB video as input
>>>> and produces MIPI-DSI as output. Thus, the DSIM is basically a parallel 
>>>> RGB to
>>>
>>> MIPI-DSI receives RGB video as input and encodes it to MIPI packet and then 
>>> transfers the packet to MIPI panel.
>>> And finally, MIPI panel decodes the packet and updates it - RGB data - on 
>>> its SRAM.
>>>
>>> MIPI-DSI driver programs how the RGB video should be made as MIPI packet. 
>>> For more detail, you could refer to MIPI-DSI spec.
>>> This would be why we handle MIPI-DSI driver as an encoder like other ARM 
>>> SoC DRM drivers did.
>>>
>>>> MIPI-DSI bridge and the encoder is the LCD controller that encodes the 
>>>> video
>>>> data as parallel RGB.
>>>>
>>>> On the i.MX8MM, the LCDIF is already the encoder. On Exynos, the series
>>>> implements the encoder in the platform glue, but in the end the encoder can
>>>> probably be moved to the DECON.
>>>
>>> As you know, Display controller can transfer RGB video to various devices 
>>> such as RGB panel, CPU panel, LVDS panel via LVDS bridge, MIPI panel via 
>>> MIPI-DSI bus device, and so on like below,
>>>
>>> Display Controller --> RGB panel or CPU panel.
>>> Display Controller --> LVDS bridge --> LVDS panel.
>>> Display Controller --> MIPI DSI bus device --> MIPI Panel.
>>> ...
>>>
>>> Display controller drivers such as FIMD and DECON series in case of Exynos 
>>> don't create an encoder driver-internally instead of it depends on Display 
>>> pipeline configuration - what kind of Display panel is used.
>>> In fact, if the Display pipeline uses RGB panel or CPU panel without 
>>> Display bus device such as MIPI-DSI, then FIMD and DECON drivers create an 
>>> encoder for it internally - just we separated the code to consider other 
>>> type of panels.
> 
> What happens if I add a MIPI-DSI --> HDMI bridge to the Display pipeline? Then
> the Pipeline is
> 
> Di

Re: [PATCH 1/2] drm/exynos: depend on COMMON_CLK to fix compile tests

2020-11-22 Thread Inki Dae
HI Krzysztof,

20. 11. 17. 오전 2:53에 Krzysztof Kozlowski 이(가) 쓴 글:
> The Exynos DRM uses Common Clock Framework thus it cannot be built on
> platforms without it (e.g. compile test on MIPS with RALINK and
> SOC_RT305X):
> 
> /usr/bin/mips-linux-gnu-ld: drivers/gpu/drm/exynos/exynos_mixer.o: in 
> function `mixer_bind':
> exynos_mixer.c:(.text+0x958): undefined reference to `clk_set_parent'
> 
> Reported-by: kernel test robot 
> Signed-off-by: Krzysztof Kozlowski 

Picked it up.

Thanks,
Inki Dae

> ---
>  drivers/gpu/drm/exynos/Kconfig | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
> index 6417f374b923..951d5f708e92 100644
> --- a/drivers/gpu/drm/exynos/Kconfig
> +++ b/drivers/gpu/drm/exynos/Kconfig
> @@ -1,7 +1,8 @@
>  # SPDX-License-Identifier: GPL-2.0-only
>  config DRM_EXYNOS
>   tristate "DRM Support for Samsung SoC Exynos Series"
> - depends on OF && DRM && (ARCH_S3C64XX || ARCH_S5PV210 || ARCH_EXYNOS || 
> ARCH_MULTIPLATFORM || COMPILE_TEST)
> + depends on OF && DRM && COMMON_CLK
> + depends on ARCH_S3C64XX || ARCH_S5PV210 || ARCH_EXYNOS || 
> ARCH_MULTIPLATFORM || COMPILE_TEST
>   depends on MMU
>   select DRM_KMS_HELPER
>   select VIDEOMODE_HELPERS
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [GIT PULL] exynos-drm-fixes

2022-02-22 Thread Inki Dae
Hi Dave,

Seems you missed. Is there any issue?

Thanks,
Inki Dae

22. 2. 10. 20:07에 Inki Dae 이(가) 쓴 글:
> Hi Dave and Daniel,
> 
>Just two fixup series - one is to fix irq chaining issue and other is
>regressions to TE-gpio handling.
> 
> Please let me know if there is any problem.
> 
> Thanks,
> Inki Dae
> 
> The following changes since commit dfd42facf1e4ada021b939b4e19c935dcdd55566:
> 
>   Linux 5.17-rc3 (2022-02-06 12:20:50 -0800)
> 
> are available in the Git repository at:
> 
>   gitolite.kernel.org:/pub/scm/linux/kernel/git/daeinki/drm-exynos 
> tags/exynos-drm-fixes-for-v5.17-rc4
> 
> for you to fetch changes up to 38103fa72e0b70e3067fed489f8316dc5998f26c:
> 
>   drm/exynos: Search for TE-gpio in DSI panel's node (2022-02-10 19:17:22 
> +0900)
> 
> 
> Fixups
> - Make display controller drivers for Exynos series to use platform_get_irq
>   and platform_get_irq_byname functions to get the interrupt, which prevents
>   irq chaining from messed up when using hierarchical interrupt domains
>   which use "interrupts" property in the node.
> - Fix two regressions to TE-gpio handling.
> 
> 
> Lad Prabhakar (5):
>   drm/exynos/exynos7_drm_decon: Use platform_get_irq_byname() to get the 
> interrupt
>   drm/exynos: mixer: Use platform_get_irq() to get the interrupt
>   drm/exynos/exynos_drm_fimd: Use platform_get_irq_byname() to get the 
> interrupt
>   drm/exynos/fimc: Use platform_get_irq() to get the interrupt
>   drm/exynos: gsc: Use platform_get_irq() to get the interrupt
> 
> Marek Szyprowski (2):
>   drm/exynos: Don't fail if no TE-gpio is defined for DSI driver
>   drm/exynos: Search for TE-gpio in DSI panel's node
> 
>  drivers/gpu/drm/exynos/exynos7_drm_decon.c | 12 +++-
>  drivers/gpu/drm/exynos/exynos_drm_dsi.c|  6 --
>  drivers/gpu/drm/exynos/exynos_drm_fimc.c   | 13 +
>  drivers/gpu/drm/exynos/exynos_drm_fimd.c   | 13 -
>  drivers/gpu/drm/exynos/exynos_drm_gsc.c| 10 +++---
>  drivers/gpu/drm/exynos/exynos_mixer.c  | 14 ++
>  6 files changed, 25 insertions(+), 43 deletions(-)
> 


Re: [PATCH] drm/exynos: fimd: add BGR support for exynos4/5

2022-02-23 Thread Inki Dae
Hi Martin.

I found that exynos4 and 5 data sheet include documented same register.
RGB_ORDER_E field of VIDCONx registers will do same thing.

I'm not sure whether the use of undocumented register is safe or not - maybe 
some HW bug exists.

Anyway, I'd like to recommend you to use documented register only.

Sorry for late and thanks,
Inki Dae

22. 1. 30. 07:01에 Martin Jücker 이(가) 쓴 글:
> In the downstream kernels for exynos4 and exynos5 devices, there is an
> undocumented register that controls the order of the RGB output. It can
> be set to either normal order or reversed, which enables BGR support for
> those SoCs.
> 
> This patch enables the BGR support for all the SoCs that were found to
> have at least one device with this logic in the corresponding downstream
> kernels.
> 
> Signed-off-by: Martin Jücker 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_fimd.c | 42 ++--
>  include/video/samsung_fimd.h |  4 +++
>  2 files changed, 44 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> index c735e53939d8..cb632360c968 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> @@ -109,6 +109,7 @@ struct fimd_driver_data {
>   unsigned int has_dp_clk:1;
>   unsigned int has_hw_trigger:1;
>   unsigned int has_trigger_per_te:1;
> + unsigned int has_bgr_support:1;
>  };
>  
>  static struct fimd_driver_data s3c64xx_fimd_driver_data = {
> @@ -138,6 +139,7 @@ static struct fimd_driver_data exynos4_fimd_driver_data = 
> {
>   .lcdblk_bypass_shift = 1,
>   .has_shadowcon = 1,
>   .has_vtsel = 1,
> + .has_bgr_support = 1,
>  };
>  
>  static struct fimd_driver_data exynos5_fimd_driver_data = {
> @@ -149,6 +151,7 @@ static struct fimd_driver_data exynos5_fimd_driver_data = 
> {
>   .has_vidoutcon = 1,
>   .has_vtsel = 1,
>   .has_dp_clk = 1,
> + .has_bgr_support = 1,
>  };
>  
>  static struct fimd_driver_data exynos5420_fimd_driver_data = {
> @@ -162,6 +165,7 @@ static struct fimd_driver_data 
> exynos5420_fimd_driver_data = {
>   .has_vtsel = 1,
>   .has_mic_bypass = 1,
>   .has_dp_clk = 1,
> + .has_bgr_support = 1,
>  };
>  
>  struct fimd_context {
> @@ -226,6 +230,18 @@ static const uint32_t fimd_formats[] = {
>   DRM_FORMAT_ARGB,
>  };
>  
> +static const uint32_t fimd_extended_formats[] = {
> + DRM_FORMAT_C8,
> + DRM_FORMAT_XRGB1555,
> + DRM_FORMAT_XBGR1555,
> + DRM_FORMAT_RGB565,
> + DRM_FORMAT_BGR565,
> + DRM_FORMAT_XRGB,
> + DRM_FORMAT_XBGR,
> + DRM_FORMAT_ARGB,
> + DRM_FORMAT_ABGR,
> +};
> +
>  static const unsigned int capabilities[WINDOWS_NR] = {
>   0,
>   EXYNOS_DRM_PLANE_CAP_WIN_BLEND | EXYNOS_DRM_PLANE_CAP_PIX_BLEND,
> @@ -673,21 +689,25 @@ static void fimd_win_set_pixfmt(struct fimd_context 
> *ctx, unsigned int win,
>   val |= WINCONx_BYTSWP;
>   break;
>   case DRM_FORMAT_XRGB1555:
> + case DRM_FORMAT_XBGR1555:
>   val |= WINCON0_BPPMODE_16BPP_1555;
>   val |= WINCONx_HAWSWP;
>   val |= WINCONx_BURSTLEN_16WORD;
>   break;
>   case DRM_FORMAT_RGB565:
> + case DRM_FORMAT_BGR565:
>   val |= WINCON0_BPPMODE_16BPP_565;
>   val |= WINCONx_HAWSWP;
>   val |= WINCONx_BURSTLEN_16WORD;
>   break;
>   case DRM_FORMAT_XRGB:
> + case DRM_FORMAT_XBGR:
>   val |= WINCON0_BPPMODE_24BPP_888;
>   val |= WINCONx_WSWP;
>   val |= WINCONx_BURSTLEN_16WORD;
>   break;
>   case DRM_FORMAT_ARGB:
> + case DRM_FORMAT_ABGR:
>   default:
>   val |= WINCON1_BPPMODE_25BPP_A1888;
>   val |= WINCONx_WSWP;
> @@ -695,6 +715,18 @@ static void fimd_win_set_pixfmt(struct fimd_context 
> *ctx, unsigned int win,
>   break;
>   }
>  
> + switch (pixel_format) {
> + case DRM_FORMAT_XBGR1555:
> + case DRM_FORMAT_XBGR:
> + case DRM_FORMAT_ABGR:
> + case DRM_FORMAT_BGR565:
> + writel(WIN_RGB_ORDER_REVERSE, ctx->regs + WIN_RGB_ORDER(win));
> + break;
> + default:
> + writel(WIN_RGB_ORDER_FORWARD, ctx->regs + WIN_RGB_ORDER(win));
> + break;
> + }
> +
>   /*
>* Setting dma-burst to 16Word causes permanent tearing for very small
>* buffers, e.g. cursor buffer. Burst Mode switching which based on
> @@ -1074,8 +1106,14 @@ 

[GIT PULL] exynos-drm-fixes for rc6

2022-02-24 Thread Inki Dae
Hi Dave and Daniel,

   Just fixups series.

   Ps. my previous git-pull request[1] isn't merged so I'm sending it again
   after rebasing on top of drm-fixes.

   Please kindly let me know if there is any problem.

Thanks,
Inki Dae

[1] https://www.spinics.net/lists/dri-devel/msg333237.html

The following changes since commit ecf8a99f4807c17fa310a83067a95964cedd9ac1:

  Merge tag 'drm-intel-fixes-2022-02-24' of 
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes (2022-02-25 05:51:04 
+1000)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos 
tags/exynos-drm-fixes-v5.17-rc6

for you to fetch changes up to 4188db23285e28d9e9b9096f856cdcd7868005ee:

  drm/exynos: Search for TE-gpio in DSI panel's node (2022-02-25 09:50:48 +0900)


Fixups
- Make display controller drivers for Exynos series to use
  platform_get_irq and platform_get_irq_byname functions
  to get the interrupt, which prevents irq chaning from messed up
  when using hierarchical interrupt domains which use "interrupts"
  property in the node.
- Fix two regressions to TE-gpio handling.


Lad Prabhakar (5):
  drm/exynos/exynos7_drm_decon: Use platform_get_irq_byname() to get the 
interrupt
  drm/exynos: mixer: Use platform_get_irq() to get the interrupt
  drm/exynos/exynos_drm_fimd: Use platform_get_irq_byname() to get the 
interrupt
  drm/exynos/fimc: Use platform_get_irq() to get the interrupt
  drm/exynos: gsc: Use platform_get_irq() to get the interrupt

Marek Szyprowski (2):
  drm/exynos: Don't fail if no TE-gpio is defined for DSI driver
  drm/exynos: Search for TE-gpio in DSI panel's node

 drivers/gpu/drm/exynos/exynos7_drm_decon.c | 12 +++-
 drivers/gpu/drm/exynos/exynos_drm_dsi.c|  6 --
 drivers/gpu/drm/exynos/exynos_drm_fimc.c   | 13 +
 drivers/gpu/drm/exynos/exynos_drm_fimd.c   | 13 -
 drivers/gpu/drm/exynos/exynos_drm_gsc.c| 10 +++---
 drivers/gpu/drm/exynos/exynos_mixer.c  | 14 ++
 6 files changed, 25 insertions(+), 43 deletions(-)


Re: [PATCH] drm/exynos: fimd: add BGR support for exynos4/5

2022-02-24 Thread Inki Dae
Hi Martin,

22. 2. 25. 08:27에 Martin Jücker 이(가) 쓴 글:
> Hello Inki,
> 
> On Thu, Feb 24, 2022 at 10:41:04AM +0900, Inki Dae wrote:
>> Hi Martin.
>>
>> I found that exynos4 and 5 data sheet include documented same register.
>> RGB_ORDER_E field of VIDCONx registers will do same thing.
> 
> If I read the manual correctly, this register combined with the
> RGB_ORDER_O makes it possible to map the whole RGB interface output to a
> different order. What my patch provides is a way to configure each
> hardware plane separately while maintaining a consistent output on the
> RGB interface.
> 

Understood. Your patch will allow BGR pixel order per a plane. Seems to be 
useful because a framebuffer with BGR pixel format can be displayed on screen 
without any color space conversion. :)

> Implementing the RGB_ORDER_O and E would need some logic to make sure
> that all planes are always using the same RGB order.
> 
>>
>> I'm not sure whether the use of undocumented register is safe or not - maybe 
>> some HW bug exists.
> 
> I see, that makes sense. Would it be possible then to introduce a new
> compatible, e.g. samsung,exynos4210-fimd-ext which can be used on tested

Seems providing a new compatible is not a good idea.

> devices? I know that some other Galaxy Note and S devices with the
> exynos4 chip have the same problem (and solution).

Could you give me more details about the same problem and its solution on the 
devices?
It would be useful for us to decide the upstream direction.

If necessary then we may need to contact HW engineer for clarity.

Thanks,
Inki Dae

> 
>>
>> Anyway, I'd like to recommend you to use documented register only.
>>
>> Sorry for late and thanks,
>> Inki Dae
> 
> Kind Regards
> Martin
> 
>>
>> 22. 1. 30. 07:01에 Martin Jücker 이(가) 쓴 글:
>>> In the downstream kernels for exynos4 and exynos5 devices, there is an
>>> undocumented register that controls the order of the RGB output. It can
>>> be set to either normal order or reversed, which enables BGR support for
>>> those SoCs.
>>>
>>> This patch enables the BGR support for all the SoCs that were found to
>>> have at least one device with this logic in the corresponding downstream
>>> kernels.
>>>
>>> Signed-off-by: Martin Jücker 
>>> ---
>>>  drivers/gpu/drm/exynos/exynos_drm_fimd.c | 42 ++--
>>>  include/video/samsung_fimd.h |  4 +++
>>>  2 files changed, 44 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
>>> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>>> index c735e53939d8..cb632360c968 100644
>>> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>>> @@ -109,6 +109,7 @@ struct fimd_driver_data {
>>> unsigned int has_dp_clk:1;
>>> unsigned int has_hw_trigger:1;
>>> unsigned int has_trigger_per_te:1;
>>> +   unsigned int has_bgr_support:1;
>>>  };
>>>  
>>>  static struct fimd_driver_data s3c64xx_fimd_driver_data = {
>>> @@ -138,6 +139,7 @@ static struct fimd_driver_data exynos4_fimd_driver_data 
>>> = {
>>> .lcdblk_bypass_shift = 1,
>>> .has_shadowcon = 1,
>>> .has_vtsel = 1,
>>> +   .has_bgr_support = 1,
>>>  };
>>>  
>>>  static struct fimd_driver_data exynos5_fimd_driver_data = {
>>> @@ -149,6 +151,7 @@ static struct fimd_driver_data exynos5_fimd_driver_data 
>>> = {
>>> .has_vidoutcon = 1,
>>> .has_vtsel = 1,
>>> .has_dp_clk = 1,
>>> +   .has_bgr_support = 1,
>>>  };
>>>  
>>>  static struct fimd_driver_data exynos5420_fimd_driver_data = {
>>> @@ -162,6 +165,7 @@ static struct fimd_driver_data 
>>> exynos5420_fimd_driver_data = {
>>> .has_vtsel = 1,
>>> .has_mic_bypass = 1,
>>> .has_dp_clk = 1,
>>> +   .has_bgr_support = 1,
>>>  };
>>>  
>>>  struct fimd_context {
>>> @@ -226,6 +230,18 @@ static const uint32_t fimd_formats[] = {
>>> DRM_FORMAT_ARGB,
>>>  };
>>>  
>>> +static const uint32_t fimd_extended_formats[] = {
>>> +   DRM_FORMAT_C8,
>>> +   DRM_FORMAT_XRGB1555,
>>> +   DRM_FORMAT_XBGR1555,
>>> +   DRM_FORMAT_RGB565,
>>> +   DRM_FORMAT_BGR565,
>>> +   DRM_FORMAT_XRGB,
>>> +   DRM_FORMAT_XBGR,
>>> +   DRM_FORMAT_ARGB,
>>> +   DRM_FORMAT_ABGR,
>>

Re: [PATCH] drm/exynos: fimd: add BGR support for exynos4/5

2022-02-28 Thread Inki Dae
Hi Martin,

22. 2. 25. 18:33에 Martin Jücker 이(가) 쓴 글:
> Hello Inki,
> 
> On Fri, Feb 25, 2022 at 12:52:56PM +0900, Inki Dae wrote:
>> Hi Martin,
>>
>> 22. 2. 25. 08:27에 Martin Jücker 이(가) 쓴 글:
>>> Hello Inki,
>>>
>>> On Thu, Feb 24, 2022 at 10:41:04AM +0900, Inki Dae wrote:
>>>> Hi Martin.
>>>>
>>>> I found that exynos4 and 5 data sheet include documented same register.
>>>> RGB_ORDER_E field of VIDCONx registers will do same thing.
>>>
>>> If I read the manual correctly, this register combined with the
>>> RGB_ORDER_O makes it possible to map the whole RGB interface output to a
>>> different order. What my patch provides is a way to configure each
>>> hardware plane separately while maintaining a consistent output on the
>>> RGB interface.
>>>
>>
>> Understood. Your patch will allow BGR pixel order per a plane. Seems to be 
>> useful because a framebuffer with BGR pixel format can be displayed on 
>> screen without any color space conversion. :)
>>
>>> Implementing the RGB_ORDER_O and E would need some logic to make sure
>>> that all planes are always using the same RGB order.
>>>
>>>>
>>>> I'm not sure whether the use of undocumented register is safe or not - 
>>>> maybe some HW bug exists.
>>>
>>> I see, that makes sense. Would it be possible then to introduce a new
>>> compatible, e.g. samsung,exynos4210-fimd-ext which can be used on tested
>>
>> Seems providing a new compatible is not a good idea.
>>
>>> devices? I know that some other Galaxy Note and S devices with the
>>> exynos4 chip have the same problem (and solution).
>>
>> Could you give me more details about the same problem and its solution on 
>> the devices?
>> It would be useful for us to decide the upstream direction.
>>
>> If necessary then we may need to contact HW engineer for clarity.
> 
> Here is my current understanding of the situation:
> 
> The issue is related to Android and a recovery image having conflicting
> pixel formats on the same device. There is a solution in Replicant[1]
> for this using parameters for the fimd driver to force the pixel format
> to RGB or BGR. It's using the PNRMODE register on VIDCON0, but this
> solution needs two separate kernels to be built to add the parameter as
> the boot loader is not adjustable.
> 
> This was also discussed in dri-devel irc and it was proposed to expose
> both formats and fail the atomic commit if userspace tried to use both
> RGB and BGR formats at the same time. With this approach there should be
> something on the screen but it might happen that some users can't deal
> with the failing commits as it's rather difficult to find the cause and
> fix it on the go.

Thanks for sharing.

> 
> After that I accidentally discovered this undocumented register while
> reading the old vendor sources and it seems that it fixes all the

Are the old vendor sources using this undocumented register? If so then the use 
of the register would be safe.

> issues. At least if there are no HW bugs as you mentioned.

I will try to contact HW engineer and check if no problem.

Thanks,
Inki Dae

> 



> Kind Regards
> Martin
> 
> [1] 
> https://protect2.fireeye.com/v1/url?k=d515db34-b4683348-d514507b-74fe485cc33c-0ee001ffdcafd932&q=1&e=851ccfed-b6fa-4794-8989-27ef28bc7ac6&u=https%3A%2F%2Fgit.replicant.us%2Freplicant-next%2Fkernel_replicant_linux%2Fcommit%2F%3Fh%3Dreplicant-11%26id%3Dcc5a0615b40cd5ede1eb87a60daa50333701a135
> 
>>
>> Thanks,
>> Inki Dae
>>
>>>
>>>>
>>>> Anyway, I'd like to recommend you to use documented register only.
>>>>
>>>> Sorry for late and thanks,
>>>> Inki Dae
>>>
>>> Kind Regards
>>> Martin
>>>
>>>>
>>>> 22. 1. 30. 07:01에 Martin Jücker 이(가) 쓴 글:
>>>>> In the downstream kernels for exynos4 and exynos5 devices, there is an
>>>>> undocumented register that controls the order of the RGB output. It can
>>>>> be set to either normal order or reversed, which enables BGR support for
>>>>> those SoCs.
>>>>>
>>>>> This patch enables the BGR support for all the SoCs that were found to
>>>>> have at least one device with this logic in the corresponding downstream
>>>>> kernels.
>>>>>
>>>>> Signed-off-by: Martin Jücker 
>>>>> ---
>>>>>  drivers/gpu/drm/exynos/exyn

Re: [PATCH v3 RESEND 21/24] drm/exynos/decon5433: add local path support

2022-03-01 Thread Inki Dae
Hi Krzysztof,

22. 2. 7. 01:51에 Krzysztof Kozlowski 이(가) 쓴 글:
> On 25/03/2019 08:13, Andrzej Hajda wrote:
>> GSCALERs in Exynos5433 have local path to DECON and DECON_TV.
>> They can be used as extra planes with support for non-RGB formats and 
>> scaling.
>> To enable it on DECON update_plane and disable_plane callback should
>> be modified. Moreover DSD mux should be set accordingly, and finally
>> atomic_check callback should be used to limit the number of active planes.
>>
>> Signed-off-by: Andrzej Hajda 
>> ---
>>  drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 80 +++
>>  drivers/gpu/drm/exynos/regs-decon5433.h   |  6 ++
>>  2 files changed, 72 insertions(+), 14 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/ex
> Hi guys!
> 
> I am working on DRM bindings conversion to DT schema format and I found
> this set only partially applied. I merged the DTS patches ("dsd" clock),
> but I think the driver and bindings were not picked up.
> 
> Nevertheless I am going to include the "dsd" clock in the new bindings,
> so the DTS passes DT schema checks. Let me know if other approach
> (revert of DTS change) should be taken.
> 

Sorry for late response.

As of now, "dsd" is a dead property not used anywhere.
This patch series makes real user not to work correctly due to ABI change.
How about reverting it until this patch series is merged after fixing the real 
user problem?

Thanks,
Inki Dae

> Best regards,
> Krzysztof
> 


[GIT PULL] exynos-drm-next for v5.18

2022-03-04 Thread Inki Dae
Hi Dave and Daniel,

   Just adding BGR pixel format support per a plane.

   Please kindly let me know if there is any problem.

Thanks,
Inki Dae

The following changes since commit fedc89821990013608bc210c9aef5bb33a1345a7:

  drm/exynos: Search for TE-gpio in DSI panel's node (2022-03-04 17:13:51 +0900)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos 
tags/exynos-drm-next-v5.18

for you to fetch changes up to 2d684f4e155c1e80ff63bd503930171c460eac5b:

  drm/exynos: fimd: add BGR support for exynos4/5 (2022-03-04 17:13:52 +0900)


New feature
- Add BGR pixel format support for FIMD device. As for this,
  this patch uses undocumented register, WIN_RGB_ORDER, but
  it is safe because product kernels have been using same
  register.


Martin Jücker (1):
  drm/exynos: fimd: add BGR support for exynos4/5

 drivers/gpu/drm/exynos/exynos_drm_fimd.c | 42 ++--
 include/video/samsung_fimd.h |  4 +++
 2 files changed, 44 insertions(+), 2 deletions(-)


Re: [PATCH] drm/exynos: Make use of the helper function devm_platform_ioremap_resource()

2021-09-15 Thread Inki Dae



21. 8. 31. 오후 4:49에 Cai Huoqing 이(가) 쓴 글:
> Use the devm_platform_ioremap_resource() helper instead of
> calling platform_get_resource() and devm_ioremap_resource()
> separately
> 

Picked it up.

Thanks,
Inki Dae

> Signed-off-by: Cai Huoqing 
> ---
>  drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 4 +---
>  drivers/gpu/drm/exynos/exynos_drm_dsi.c   | 4 +---
>  drivers/gpu/drm/exynos/exynos_drm_fimc.c  | 5 +
>  drivers/gpu/drm/exynos/exynos_drm_fimd.c  | 4 +---
>  drivers/gpu/drm/exynos/exynos_drm_g2d.c   | 5 +
>  drivers/gpu/drm/exynos/exynos_drm_gsc.c   | 6 +-
>  drivers/gpu/drm/exynos/exynos_drm_rotator.c   | 4 +---
>  drivers/gpu/drm/exynos/exynos_drm_scaler.c| 4 +---
>  drivers/gpu/drm/exynos/exynos_hdmi.c  | 4 +---
>  9 files changed, 9 insertions(+), 31 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c 
> b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> index 9870c4e6af36..b5001db7a95c 100644
> --- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> +++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> @@ -793,7 +793,6 @@ static int exynos5433_decon_probe(struct platform_device 
> *pdev)
>  {
>   struct device *dev = &pdev->dev;
>   struct decon_context *ctx;
> - struct resource *res;
>   int ret;
>   int i;
>  
> @@ -818,8 +817,7 @@ static int exynos5433_decon_probe(struct platform_device 
> *pdev)
>   ctx->clks[i] = clk;
>   }
>  
> - res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> - ctx->addr = devm_ioremap_resource(dev, res);
> + ctx->addr = devm_platform_ioremap_resource(pdev, 0);
>   if (IS_ERR(ctx->addr))
>   return PTR_ERR(ctx->addr);
>  
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
> b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> index e39fac889edc..8d137857818c 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> @@ -1738,7 +1738,6 @@ static const struct component_ops 
> exynos_dsi_component_ops = {
>  static int exynos_dsi_probe(struct platform_device *pdev)
>  {
>   struct device *dev = &pdev->dev;
> - struct resource *res;
>   struct exynos_dsi *dsi;
>   int ret, i;
>  
> @@ -1789,8 +1788,7 @@ static int exynos_dsi_probe(struct platform_device 
> *pdev)
>   }
>   }
>  
> - res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> - dsi->reg_base = devm_ioremap_resource(dev, res);
> + dsi->reg_base = devm_platform_ioremap_resource(pdev, 0);
>   if (IS_ERR(dsi->reg_base))
>   return PTR_ERR(dsi->reg_base);
>  
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimc.c 
> b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
> index a3c718148c45..ecfd82d0afb7 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
> @@ -85,7 +85,6 @@ struct fimc_scaler {
>  /*
>   * A structure of fimc context.
>   *
> - * @regs_res: register resources.
>   * @regs: memory mapped io registers.
>   * @lock: locking of operations.
>   * @clocks: fimc clocks.
> @@ -103,7 +102,6 @@ struct fimc_context {
>   struct exynos_drm_ipp_formats   *formats;
>   unsigned intnum_formats;
>  
> - struct resource *regs_res;
>   void __iomem*regs;
>   spinlock_t  lock;
>   struct clk  *clocks[FIMC_CLKS_MAX];
> @@ -1327,8 +1325,7 @@ static int fimc_probe(struct platform_device *pdev)
>   ctx->num_formats = num_formats;
>  
>   /* resource memory */
> - ctx->regs_res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> - ctx->regs = devm_ioremap_resource(dev, ctx->regs_res);
> + ctx->regs = devm_platform_ioremap_resource(pdev, 0);
>   if (IS_ERR(ctx->regs))
>   return PTR_ERR(ctx->regs);
>  
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> index 700ca4fa6665..c735e53939d8 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> @@ -1202,9 +1202,7 @@ static int fimd_probe(struct platform_device *pdev)
>   return PTR_ERR(ctx->lcd_clk);
>   }
>  
> - res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> -
> - ctx->regs = devm_ioremap_resource(dev, res);
> + ctx->regs = devm_platform_ioremap_resource(pdev, 0);
>   if (IS_ERR(ctx->regs))
>   return PTR_ERR(ctx->regs);
>  
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c 
> b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
> ind

Re: [PATCH v2 06/13] drm/exynos: replace drm_detect_hdmi_monitor() with drm_display_info.is_hdmi

2021-10-26 Thread Inki Dae
Hi,

21. 10. 17. 오전 3:42에 Claudio Suarez 이(가) 쓴 글:
> Once EDID is parsed, the monitor HDMI support information is available
> through drm_display_info.is_hdmi. Retriving the same information with
> drm_detect_hdmi_monitor() is less efficient. Change to
> drm_display_info.is_hdmi
> 
> Signed-off-by: Claudio Suarez 
> ---
>  drivers/gpu/drm/exynos/exynos_hdmi.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
> b/drivers/gpu/drm/exynos/exynos_hdmi.c
> index 7655142a4651..a563d6386abe 100644
> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
> @@ -893,12 +893,14 @@ static int hdmi_get_modes(struct drm_connector 
> *connector)
>   if (!edid)
>   return -ENODEV;
>  
> - hdata->dvi_mode = !drm_detect_hdmi_monitor(edid);
> + /* This updates connector->display_info */
> + drm_connector_update_edid_property(connector, edid);
> +
> + hdata->dvi_mode = !connector->display_info.is_hdmi;

Thanks for correcting this. Yeah, we should use drm_display_info.is_hdmi parsed 
from EDID.
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/gpu/drm/drm_edid.c?h=v5.14.14#n4725

Signed-off-by: Inki Dae 

Thanks,
Inki Dae

>   DRM_DEV_DEBUG_KMS(hdata->dev, "%s : width[%d] x height[%d]\n",
> (hdata->dvi_mode ? "dvi monitor" : "hdmi monitor"),
> edid->width_cm, edid->height_cm);
>  
> - drm_connector_update_edid_property(connector, edid);
>   cec_notifier_set_phys_addr_from_edid(hdata->notifier, edid);
>  
>   ret = drm_add_edid_modes(connector, edid);
> 


Re: [PATCH v2 06/13] drm/exynos: replace drm_detect_hdmi_monitor() with drm_display_info.is_hdmi

2021-10-26 Thread Inki Dae



21. 10. 27. 오전 7:28에 Inki Dae 이(가) 쓴 글:
> Hi,
> 
> 21. 10. 17. 오전 3:42에 Claudio Suarez 이(가) 쓴 글:
>> Once EDID is parsed, the monitor HDMI support information is available
>> through drm_display_info.is_hdmi. Retriving the same information with
>> drm_detect_hdmi_monitor() is less efficient. Change to
>> drm_display_info.is_hdmi
>>
>> Signed-off-by: Claudio Suarez 
>> ---
>>  drivers/gpu/drm/exynos/exynos_hdmi.c | 6 --
>>  1 file changed, 4 insertions(+), 2 deletions(
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
>> b/drivers/gpu/drm/exynos/exynos_hdmi.c
>> index 7655142a4651..a563d6386abe 100644
>> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
>> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
>> @@ -893,12 +893,14 @@ static int hdmi_get_modes(struct drm_connector 
>> *connector)
>>  if (!edid)
>>  return -ENODEV;
>>  
>> -hdata->dvi_mode = !drm_detect_hdmi_monitor(edid);
>> +/* This updates connector->display_info */
>> +drm_connector_update_edid_property(connector, edid);
>> +
>> +hdata->dvi_mode = !connector->display_info.is_hdmi;
> 
> Thanks for correcting this. Yeah, we should use drm_display_info.is_hdmi 
> parsed from EDID.
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/gpu/drm/drm_edid.c?h=v5.14.14#n4725
> 
> Signed-off-by: Inki Dae 

 My mistake. Please, ignore above Signed-off-by.

Acked-by : Inki Dae  instead.

Thanks,
Inki Dae

> 
> Thanks,
> Inki Dae
> 
>>  DRM_DEV_DEBUG_KMS(hdata->dev, "%s : width[%d] x height[%d]\n",
>>(hdata->dvi_mode ? "dvi monitor" : "hdmi monitor"),
>>edid->width_cm, edid->height_cm);
>>  
>> -drm_connector_update_edid_property(connector, edid);
>>  cec_notifier_set_phys_addr_from_edid(hdata->notifier, edid);
>>  
>>  ret = drm_add_edid_modes(connector, edid);
>>
> 


[GIT PULL] exynos-drm-fixes

2021-09-28 Thread Inki Dae
Hi Dave,

   Just one clean up to use helper function.

Please kindly let me know if there is any problem.

Thanks,
Inki Dae

The following changes since commit 6880fa6c56601bb8ed59df6c30fd390cc5f6dd8f:

  Linux 5.15-rc1 (2021-09-12 16:28:37 -0700)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos 
tags/exynos-drm-fixes-for-v5.15-rc4

for you to fetch changes up to 17ac76e050c51497e75871a43aa3328ba54cdafd:

  drm/exynos: Make use of the helper function devm_platform_ioremap_resource() 
(2021-09-16 14:05:07 +0900)


One cleanup
- Use devm_platform_ioremap_resource() helper function instead of old
  one.


Cai Huoqing (1):
  drm/exynos: Make use of the helper function 
devm_platform_ioremap_resource()

 drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 4 +---
 drivers/gpu/drm/exynos/exynos_drm_dsi.c   | 4 +---
 drivers/gpu/drm/exynos/exynos_drm_fimc.c  | 5 +
 drivers/gpu/drm/exynos/exynos_drm_fimd.c  | 4 +---
 drivers/gpu/drm/exynos/exynos_drm_g2d.c   | 5 +
 drivers/gpu/drm/exynos/exynos_drm_gsc.c   | 6 +-
 drivers/gpu/drm/exynos/exynos_drm_rotator.c   | 4 +---
 drivers/gpu/drm/exynos/exynos_drm_scaler.c| 4 +---
 drivers/gpu/drm/exynos/exynos_hdmi.c  | 4 +---
 9 files changed, 9 insertions(+), 31 deletions(-)


Re: [PATCH] Revert "drm: exynos: dsi: Convert to bridge driver"

2022-01-18 Thread Inki Dae
Hi,

22. 1. 17. 오후 6:55에 Robert Foss 이(가) 쓴 글:
> Hi Inki,
> 
> On Fri, 14 Jan 2022 at 02:18, Inki Dae  wrote:
>>
>> Hi Robert,
>>
>> 22. 1. 12. 오후 7:05에 Robert Foss 이(가) 쓴 글:
>>> Thank you again for catching this and submitting a revert.
>>>
>>> Reviewed-by: Robert Foss >>
>>> Applied to drm-misc-next.
>>>
>>
>> Trivial thing I think but just notice. With this applying - original patch 
>> set and revert one, merge conflict may happen on drm-next because 
>> drm-misc-next has this patch set exynos-drm-next tree doesn't include.
>> Leaving this patch history in drm-misc-next is correct?
> 
> Thanks for paying attention to this.
> 
> If we end up seeing a conflict, the exynos patches can go in through drm-misc.
>

I mean is it correct to leave some patch set history - which is not reviewed 
and even not tested - exists in management tree?
Anyway, it depends on maintainer of this tree. :)

Thanks,
Inki Dae


Re: [PATCH] drm/exynos: Don't fail if no TE-gpio is defined for DSI driver

2022-01-23 Thread Inki Dae
Hi Marek,

Thanks for fixing it.
Inki Dae.

22. 1. 21. 19:00에 Marek Szyprowski 이(가) 쓴 글:
> TE-gpio is optional and if it is not found then gpiod_get_optional()
> returns NULL. In such case the code will continue and try to convert NULL
> gpiod to irq what in turn fails. The failure is then propagated and driver
> is not registered.
> 
> Fix this by returning early from exynos_dsi_register_te_irq() if no
> TE-gpio is found.
> 
> Fixes: ee6c8b5afa62 ("drm/exynos: Replace legacy gpio interface for gpiod 
> interface")
> Signed-off-by: Marek Szyprowski  ---
>  drivers/gpu/drm/exynos/exynos_drm_dsi.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
> b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> index 32a36572b894..14ebbb124852 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> @@ -1335,7 +1335,9 @@ static int exynos_dsi_register_te_irq(struct exynos_dsi 
> *dsi,
>   int te_gpio_irq;
>  
>   dsi->te_gpio = devm_gpiod_get_optional(dsi->dev, "te", GPIOD_IN);
> - if (IS_ERR(dsi->te_gpio)) {
> + if (!dsi->te_gpio) {
> + return 0;
> + } else if (IS_ERR(dsi->te_gpio)) {
>   dev_err(dsi->dev, "gpio request failed with %ld\n",
>   PTR_ERR(dsi->te_gpio));
>   return PTR_ERR(dsi->te_gpio);


Re: [PATCH] drm/exynos: Search for TE-gpio in DSI panel's node

2022-01-27 Thread Inki Dae
Hi,

22. 1. 25. 00:22에 Henrik Grimler 이(가) 쓴 글:
> Hi Marek,
> 
> On Mon, Jan 24, 2022 at 02:52:46PM +0100, Marek Szyprowski wrote:
>> TE-gpio, if defined, is placed in the panel's node, not the parent DSI
>> node. Change the devm_gpiod_get_optional() to gpiod_get_optional() and
>> pass proper device node to it. The code already has a proper cleanup
>> path, so it looks that the devm_* variant has been applied assidentally
>  
> Small observation: the spelling above should probably be"accidentally".
> 

I can fix it. Thanks.

>> during the conversion to gpiod API.
> 
> Best regards,
> Henrik Grimler
> 


Re: [PATCH 1/3] drm/exynox: Implement mmap as GEM object function

2021-11-08 Thread Inki Dae
Hi,

Really sorry for late. I saw this patch in my mailbox just before. Seems I 
missed it due to a typo, exynox.
I will review and apply this patch ASAP.

Thanks,
Inki Dae

21. 11. 8. 오후 7:28에 Thomas Zimmermann 이(가) 쓴 글:
> Moving the driver-specific mmap code into a GEM object function allows
> for using DRM helpers for various mmap callbacks.
> 
> The respective exynos functions are being removed. The file_operations
> structure exynos_drm_driver_fops is now being created by the helper macro
> DEFINE_DRM_GEM_FOPS().
> 
> Signed-off-by: Thomas Zimmermann 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_drv.c   | 13 ++-
>  drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 20 ++-
>  drivers/gpu/drm/exynos/exynos_drm_gem.c   | 43 +--
>  drivers/gpu/drm/exynos/exynos_drm_gem.h   |  5 ---
>  4 files changed, 13 insertions(+), 68 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
> b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> index d8f1cf4d6b69..9743b6b17447 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> @@ -102,16 +102,7 @@ static const struct drm_ioctl_desc exynos_ioctls[] = {
>   DRM_RENDER_ALLOW),
>  };
>  
> -static const struct file_operations exynos_drm_driver_fops = {
> - .owner  = THIS_MODULE,
> - .open   = drm_open,
> - .mmap   = exynos_drm_gem_mmap,
> - .poll   = drm_poll,
> - .read   = drm_read,
> - .unlocked_ioctl = drm_ioctl,
> - .compat_ioctl = drm_compat_ioctl,
> - .release= drm_release,
> -};
> +DEFINE_DRM_GEM_FOPS(exynos_drm_driver_fops);
>  
>  static const struct drm_driver exynos_drm_driver = {
>   .driver_features= DRIVER_MODESET | DRIVER_GEM
> @@ -124,7 +115,7 @@ static const struct drm_driver exynos_drm_driver = {
>   .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
>   .gem_prime_import   = exynos_drm_gem_prime_import,
>   .gem_prime_import_sg_table  = exynos_drm_gem_prime_import_sg_table,
> - .gem_prime_mmap = exynos_drm_gem_prime_mmap,
> + .gem_prime_mmap = drm_gem_prime_mmap,
>   .ioctls = exynos_ioctls,
>   .num_ioctls = ARRAY_SIZE(exynos_ioctls),
>   .fops   = &exynos_drm_driver_fops,
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c 
> b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> index 5147f5929be7..02c97b9ca926 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> @@ -15,6 +15,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  
> @@ -39,25 +40,8 @@ static int exynos_drm_fb_mmap(struct fb_info *info,
>   struct drm_fb_helper *helper = info->par;
>   struct exynos_drm_fbdev *exynos_fbd = to_exynos_fbdev(helper);
>   struct exynos_drm_gem *exynos_gem = exynos_fbd->exynos_gem;
> - unsigned long vm_size;
> - int ret;
> -
> - vma->vm_flags |= VM_IO | VM_DONTEXPAND | VM_DONTDUMP;
> -
> - vm_size = vma->vm_end - vma->vm_start;
> -
> - if (vm_size > exynos_gem->size)
> - return -EINVAL;
>  
> - ret = dma_mmap_attrs(to_dma_dev(helper->dev), vma, exynos_gem->cookie,
> -  exynos_gem->dma_addr, exynos_gem->size,
> -  exynos_gem->dma_attrs);
> - if (ret < 0) {
> - DRM_DEV_ERROR(to_dma_dev(helper->dev), "failed to mmap.\n");
> - return ret;
> - }
> -
> - return 0;
> + return drm_gem_prime_mmap(&exynos_gem->base, vma);
>  }
>  
>  static const struct fb_ops exynos_drm_fb_ops = {
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c 
> b/drivers/gpu/drm/exynos/exynos_drm_gem.c
> index 4396224227d1..c4b63902ee7a 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
> @@ -17,6 +17,8 @@
>  #include "exynos_drm_drv.h"
>  #include "exynos_drm_gem.h"
>  
> +static int exynos_drm_gem_mmap(struct drm_gem_object *obj, struct 
> vm_area_struct *vma);
> +
>  static int exynos_drm_alloc_buf(struct exynos_drm_gem *exynos_gem, bool 
> kvmap)
>  {
>   struct drm_device *dev = exynos_gem->base.dev;
> @@ -135,6 +137,7 @@ static const struct vm_operations_struct 
> exynos_drm_gem_vm_ops = {
>  static const struct drm_gem_object_funcs exynos_drm_gem_object_funcs = {
>   .free = exynos_drm_gem_free_object,
>   .get_sg_table = exynos_drm_gem_prime_get_sg_table,
> + .mmap = exynos_drm_gem_mmap,
>

Re: [PATCH] drm/exynos: Replace legacy gpio interface for gpiod interface

2021-11-09 Thread Inki Dae
Hi,

21. 11. 2. 오전 11:20에 Maíra Canal 이(가) 쓴 글:
> Considering the current transition of the GPIO subsystem, remove all
> dependencies of the legacy GPIO interface (linux/gpio.h and linux
> /of_gpio.h) and replace it with the descriptor-based GPIO approach.
> 

Applied.

Thanks,
Inki Dae

> Signed-off-by: Maíra Canal 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_dsi.c | 42 +
>  1 file changed, 14 insertions(+), 28 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
> b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> index 8d137857818c..b0b1acb7e712 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> @@ -13,7 +13,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> @@ -265,7 +264,7 @@ struct exynos_dsi {
>   struct clk **clks;
>   struct regulator_bulk_data supplies[2];
>   int irq;
> - int te_gpio;
> + struct gpio_desc *te_gpio;
>  
>   u32 pll_clk_rate;
>   u32 burst_clk_rate;
> @@ -1298,14 +1297,14 @@ static void exynos_dsi_enable_irq(struct exynos_dsi 
> *dsi)
>  {
>   enable_irq(dsi->irq);
>  
> - if (gpio_is_valid(dsi->te_gpio))
> - enable_irq(gpio_to_irq(dsi->te_gpio));
> + if (dsi->te_gpio)
> + enable_irq(gpiod_to_irq(dsi->te_gpio));
>  }
>  
>  static void exynos_dsi_disable_irq(struct exynos_dsi *dsi)
>  {
> - if (gpio_is_valid(dsi->te_gpio))
> - disable_irq(gpio_to_irq(dsi->te_gpio));
> + if (dsi->te_gpio)
> + disable_irq(gpiod_to_irq(dsi->te_gpio));
>  
>   disable_irq(dsi->irq);
>  }
> @@ -1335,29 +1334,20 @@ static int exynos_dsi_register_te_irq(struct 
> exynos_dsi *dsi,
>   int ret;
>   int te_gpio_irq;
>  
> - dsi->te_gpio = of_get_named_gpio(panel->of_node, "te-gpios", 0);
> - if (dsi->te_gpio == -ENOENT)
> - return 0;
> -
> - if (!gpio_is_valid(dsi->te_gpio)) {
> - ret = dsi->te_gpio;
> - dev_err(dsi->dev, "cannot get te-gpios, %d\n", ret);
> + dsi->te_gpio = devm_gpiod_get_optional(dsi->dev, "te", GPIOD_IN);
> + if (IS_ERR(dsi->te_gpio)) {
> + dev_err(dsi->dev, "gpio request failed with %ld\n",
> + PTR_ERR(dsi->te_gpio));
>   goto out;
>   }
>  
> - ret = gpio_request(dsi->te_gpio, "te_gpio");
> - if (ret) {
> - dev_err(dsi->dev, "gpio request failed with %d\n", ret);
> - goto out;
> - }
> -
> - te_gpio_irq = gpio_to_irq(dsi->te_gpio);
> + te_gpio_irq = gpiod_to_irq(dsi->te_gpio);
>  
>   ret = request_threaded_irq(te_gpio_irq, exynos_dsi_te_irq_handler, NULL,
>  IRQF_TRIGGER_RISING | IRQF_NO_AUTOEN, "TE", 
> dsi);
>   if (ret) {
>   dev_err(dsi->dev, "request interrupt failed with %d\n", ret);
> - gpio_free(dsi->te_gpio);
> + gpiod_put(dsi->te_gpio);
>   goto out;
>   }
>  
> @@ -1367,10 +1357,9 @@ static int exynos_dsi_register_te_irq(struct 
> exynos_dsi *dsi,
>  
>  static void exynos_dsi_unregister_te_irq(struct exynos_dsi *dsi)
>  {
> - if (gpio_is_valid(dsi->te_gpio)) {
> - free_irq(gpio_to_irq(dsi->te_gpio), dsi);
> - gpio_free(dsi->te_gpio);
> - dsi->te_gpio = -ENOENT;
> + if (dsi->te_gpio) {
> + free_irq(gpiod_to_irq(dsi->te_gpio), dsi);
> + gpiod_put(dsi->te_gpio);
>   }
>  }
>  
> @@ -1745,9 +1734,6 @@ static int exynos_dsi_probe(struct platform_device 
> *pdev)
>   if (!dsi)
>   return -ENOMEM;
>  
> - /* To be checked as invalid one */
> - dsi->te_gpio = -ENOENT;
> -
>   init_completion(&dsi->completed);
>   spin_lock_init(&dsi->transfer_lock);
>   INIT_LIST_HEAD(&dsi->transfer_list);
> 


Re: [PATCH 1/3] drm/exynox: Implement mmap as GEM object function

2021-11-09 Thread Inki Dae
Hi Thomas and Daniel,

21. 11. 9. 오전 12:29에 Daniel Vetter 이(가) 쓴 글:
> On Mon, Nov 08, 2021 at 11:28:44AM +0100, Thomas Zimmermann wrote:
>> Moving the driver-specific mmap code into a GEM object function allows
>> for using DRM helpers for various mmap callbacks.
>>
>> The respective exynos functions are being removed. The file_operations
>> structure exynos_drm_driver_fops is now being created by the helper macro
>> DEFINE_DRM_GEM_FOPS().
>>
>> Signed-off-by: Thomas Zimmermann 
> 
> s/exynox/exynos in the subject.
> 
> Patch lgtm, but would still be good if exynos maintainers would
> ack/review/test it. But if you don't get anything within 2 weeks here's

Sorry for late. Confirmed working well on Odroid board, and had a review. 
Applied.
https://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git/log/?h=exynos-drm-next

Thanks,
Inki Dae

> my:
> 
> Acked-by: Daniel Vetter 
> 
>> ---
>>  drivers/gpu/drm/exynos/exynos_drm_drv.c   | 13 ++-
>>  drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 20 ++-
>>  drivers/gpu/drm/exynos/exynos_drm_gem.c   | 43 +--
>>  drivers/gpu/drm/exynos/exynos_drm_gem.h   |  5 ---
>>  4 files changed, 13 insertions(+), 68 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
>> b/drivers/gpu/drm/exynos/exynos_drm_drv.c
>> index d8f1cf4d6b69..9743b6b17447 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
>> @@ -102,16 +102,7 @@ static const struct drm_ioctl_desc exynos_ioctls[] = {
>>  DRM_RENDER_ALLOW),
>>  };
>>  
>> -static const struct file_operations exynos_drm_driver_fops = {
>> -.owner  = THIS_MODULE,
>> -.open   = drm_open,
>> -.mmap   = exynos_drm_gem_mmap,
>> -.poll   = drm_poll,
>> -.read   = drm_read,
>> -.unlocked_ioctl = drm_ioctl,
>> -.compat_ioctl = drm_compat_ioctl,
>> -.release= drm_release,
>> -};
>> +DEFINE_DRM_GEM_FOPS(exynos_drm_driver_fops);
>>  
>>  static const struct drm_driver exynos_drm_driver = {
>>  .driver_features= DRIVER_MODESET | DRIVER_GEM
>> @@ -124,7 +115,7 @@ static const struct drm_driver exynos_drm_driver = {
>>  .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
>>  .gem_prime_import   = exynos_drm_gem_prime_import,
>>  .gem_prime_import_sg_table  = exynos_drm_gem_prime_import_sg_table,
>> -.gem_prime_mmap = exynos_drm_gem_prime_mmap,
>> +.gem_prime_mmap = drm_gem_prime_mmap,
>>  .ioctls = exynos_ioctls,
>>  .num_ioctls = ARRAY_SIZE(exynos_ioctls),
>>  .fops   = &exynos_drm_driver_fops,
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c 
>> b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
>> index 5147f5929be7..02c97b9ca926 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
>> @@ -15,6 +15,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  
>> @@ -39,25 +40,8 @@ static int exynos_drm_fb_mmap(struct fb_info *info,
>>  struct drm_fb_helper *helper = info->par;
>>  struct exynos_drm_fbdev *exynos_fbd = to_exynos_fbdev(helper);
>>  struct exynos_drm_gem *exynos_gem = exynos_fbd->exynos_gem;
>> -unsigned long vm_size;
>> -int ret;
>> -
>> -vma->vm_flags |= VM_IO | VM_DONTEXPAND | VM_DONTDUMP;
>> -
>> -vm_size = vma->vm_end - vma->vm_start;
>> -
>> -if (vm_size > exynos_gem->size)
>> -return -EINVAL;
>>  
>> -ret = dma_mmap_attrs(to_dma_dev(helper->dev), vma, exynos_gem->cookie,
>> - exynos_gem->dma_addr, exynos_gem->size,
>> - exynos_gem->dma_attrs);
>> -if (ret < 0) {
>> -DRM_DEV_ERROR(to_dma_dev(helper->dev), "failed to mmap.\n");
>> -return ret;
>> -}
>> -
>> -return 0;
>> +return drm_gem_prime_mmap(&exynos_gem->base, vma);
>>  }
>>  
>>  static const struct fb_ops exynos_drm_fb_ops = {
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c 
>> b/drivers/gpu/drm/exynos/exynos_drm_gem.c
>> index 4396224227d1..c4b63902ee7a 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
>> @

[PATCH] drm/exynos: drop the use of label from exynos_dsi_register_te_irq

2021-11-30 Thread Inki Dae
Dropped the use of 'out' label from exynos_dsi_register_te_irq function
because the label isn't needed. This patch returns an error in each
error case directly not going to 'out' label.

With this patch build warning[1] is also fixed, which was reported by
kernel test robot 

[1] https://www.spinics.net/lists/dri-devel/msg323803.html

Reported-by: kernel test robot 
Signed-off-by: Inki Dae 
---
 drivers/gpu/drm/exynos/exynos_drm_dsi.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index b0b1acb7e712..32a36572b894 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -1338,7 +1338,7 @@ static int exynos_dsi_register_te_irq(struct exynos_dsi 
*dsi,
if (IS_ERR(dsi->te_gpio)) {
dev_err(dsi->dev, "gpio request failed with %ld\n",
PTR_ERR(dsi->te_gpio));
-   goto out;
+   return PTR_ERR(dsi->te_gpio);
}
 
te_gpio_irq = gpiod_to_irq(dsi->te_gpio);
@@ -1348,11 +1348,10 @@ static int exynos_dsi_register_te_irq(struct exynos_dsi 
*dsi,
if (ret) {
dev_err(dsi->dev, "request interrupt failed with %d\n", ret);
gpiod_put(dsi->te_gpio);
-   goto out;
+   return ret;
}
 
-out:
-   return ret;
+   return 0;
 }
 
 static void exynos_dsi_unregister_te_irq(struct exynos_dsi *dsi)
-- 
2.25.1



[GIT PULL] exynos-drm-next

2021-12-21 Thread Inki Dae
Hi Dave and Daniel,

   Just four cleanups such as replacing the use of legacy interface, 
implementing generic gem mmap,
   fixing a build warning and dropping unnecessary code.

Please let me know if there is any problem.

Thanks,
Inki Dae

The following changes since commit 1c405ca11bf563de1725e5ecfb4a74ee289d2ee9:

  Merge tag 'mediatek-drm-next-5.17' of 
https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux into 
drm-next (2021-12-17 16:16:16 +1000)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos 
tags/exynos-drm-next-for-v5.17

for you to fetch changes up to 760cceff996135fd4830f3d339446a04bd37ca0c:

  drm/exynos: drop the use of label from exynos_dsi_register_te_irq (2021-12-22 
11:39:39 +0900)


Four cleanups
- Replacing lagacy gpio interface of dsi driver with gpiod one.
- Implementing a generic GEM object mmap and use it instead of
  exynos specific one.
- Dropping the use of label from dsi driver. Which also fixes
  a build warning.
- Just trivial cleanup by dropping unnecessay code.


Bernard Zhao (1):
  drm/exynos: remove useless type conversion

Inki Dae (1):
  drm/exynos: drop the use of label from exynos_dsi_register_te_irq

Maíra Canal (1):
  drm/exynos: Replace legacy gpio interface for gpiod interface

Thomas Zimmermann (1):
  drm/exynos: Implement mmap as GEM object function

 drivers/gpu/drm/exynos/exynos_drm_drv.c   | 13 ++--
 drivers/gpu/drm/exynos/exynos_drm_dsi.c   | 49 +++
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 20 ++---
 drivers/gpu/drm/exynos/exynos_drm_fimc.c  |  4 +--
 drivers/gpu/drm/exynos/exynos_drm_gem.c   | 43 ++-
 drivers/gpu/drm/exynos/exynos_drm_gem.h   |  5 
 6 files changed, 32 insertions(+), 102 deletions(-)


Re: [PATCH] Revert "drm: exynos: dsi: Convert to bridge driver"

2022-01-13 Thread Inki Dae
Hi Robert,

22. 1. 12. 오후 7:05에 Robert Foss 이(가) 쓴 글:
> Thank you again for catching this and submitting a revert.
> 
> Reviewed-by: Robert Foss  
> Applied to drm-misc-next.
> 

Trivial thing I think but just notice. With this applying - original patch set 
and revert one, merge conflict may happen on drm-next because drm-misc-next has 
this patch set exynos-drm-next tree doesn't include. 
Leaving this patch history in drm-misc-next is correct?

Thanks,
Inki Dae


Re: [PATCH 2/5] drm/exynos: mixer: Use platform_get_irq() to get the interrupt

2022-01-14 Thread Inki Dae
Hi Lad Prabhakar,

21. 12. 23. 오전 4:01에 Lad Prabhakar 이(가) 쓴 글:
> platform_get_resource(pdev, IORESOURCE_IRQ, ..) relies on static
> allocation of IRQ resources in DT core code, this causes an issue
> when using hierarchical interrupt domains using "interrupts" property
> in the node as this bypassed the hierarchical setup and messed up the
> irq chaining.
> 
> In preparation for removal of static setup of IRQ resource from DT core
> code use platform_get_irq().
> 
> Signed-off-by: Lad Prabhakar 
> ---
> Hi,
> 
> Ideally I would expect the mixer_resources_init() to be called from probe
> instead from the bind callback. If platform_get_irq() returns -EPROBE_DEFER
> the bind callback will fail :(

If the bind callback failed then probe function of exynos drm driver will call 
-EPROBE_DEFER like below so it must be no problem :),

in exynos_drm_platform_probe function
component_master_add_with_match()

in component_master_add_with_match function
try_to_bring_up_master()

Thanks,
Inki Dae

> 
> Cheers,
> Prabhakar
> ---
>  drivers/gpu/drm/exynos/exynos_mixer.c | 14 ++
>  1 file changed, 6 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
> b/drivers/gpu/drm/exynos/exynos_mixer.c
> index 41c54f1f60bc..e5204be86093 100644
> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
> @@ -809,19 +809,17 @@ static int mixer_resources_init(struct mixer_context 
> *mixer_ctx)
>   return -ENXIO;
>   }
>  
> - res = platform_get_resource(mixer_ctx->pdev, IORESOURCE_IRQ, 0);
> - if (res == NULL) {
> - dev_err(dev, "get interrupt resource failed.\n");
> - return -ENXIO;
> - }
> + ret = platform_get_irq(mixer_ctx->pdev, 0);
> + if (ret < 0)
> + return ret;
> + mixer_ctx->irq = ret;
>  
> - ret = devm_request_irq(dev, res->start, mixer_irq_handler,
> - 0, "drm_mixer", mixer_ctx);
> + ret = devm_request_irq(dev, mixer_ctx->irq, mixer_irq_handler,
> +0, "drm_mixer", mixer_ctx);
>   if (ret) {
>   dev_err(dev, "request interrupt failed.\n");
>   return ret;
>   }
> - mixer_ctx->irq = res->start;
>  
>   return 0;
>  }
> 


Re: [PATCH 0/5] drm/exynos: Use platform_get_irq*() variants to fetch IRQ's

2022-01-14 Thread Inki Dae
Hi,

21. 12. 23. 오전 4:01에 Lad Prabhakar 이(가) 쓴 글:
> Hi All,
> 
> This patch series aims to drop using platform_get_resource() for IRQ types
> in preparation for removal of static setup of IRQ resource from DT core
> code.
> 
> Dropping usage of platform_get_resource() was agreed based on
> the discussion [0].
> 
> [0] https://patchwork.kernel.org/project/linux-renesas-soc/
> patch/20211209001056.29774-1-prabhakar.mahadev-lad...@bp.renesas.com/
>

Applied.

Thanks,
Inki Dae

 
> Cheers,
> Prabhakar
> 
> Lad Prabhakar (5):
>   drm/exynos/exynos7_drm_decon: Use platform_get_irq_byname() to get the
> interrupt
>   drm/exynos: mixer: Use platform_get_irq() to get the interrupt
>   drm/exynos/exynos_drm_fimd: Use platform_get_irq_byname() to get the
> interrupt
>   drm/exynos/fimc: Use platform_get_irq() to get the interrupt
>   drm/exynos: gsc: Use platform_get_irq() to get the interrupt
> 
>  drivers/gpu/drm/exynos/exynos7_drm_decon.c | 12 +++-
>  drivers/gpu/drm/exynos/exynos_drm_fimc.c   | 13 +
>  drivers/gpu/drm/exynos/exynos_drm_fimd.c   | 13 -
>  drivers/gpu/drm/exynos/exynos_drm_gsc.c| 10 +++---
>  drivers/gpu/drm/exynos/exynos_mixer.c  | 14 ++
>  5 files changed, 21 insertions(+), 41 deletions(-)
> 


[GIT PULL] exynos-drm-next

2016-04-30 Thread Inki Dae
Hi Dave,

This pull request includes some code refactoring, Exynos5433 and
HW trigger mode supports.

Summary:
- Support for pipeline clock between KMS drivers.
  . Exynos SoC is required to control clocks across KMS drivers
according to Exynos SoC version. So this patch refactos
some relevant codes and provides generic solution for it.
- Add Exynos5433 SoC support to HDMI parts - HDMI and DECON-TV.
- Add HW trigger mode support to CRTC drivers.
  . In case of using i80 Panel, some Exynos SoC supports HW trigger
mode so this patch makes trigger mode - HW or SW trigger - to be
set according to SoC version properly.
- And some cleanups and regression fixups.

Please, kindly let me know if there is any problem.

Thanks,
Inki Dae

The following changes since commit b89359bdf0f1e95a4c5f92300594ba9dde323fc4:

  Merge branch 'for-next' of http://git.agner.ch/git/linux-drm-fsl-dcu into 
drm-next (2016-04-29 14:57:51 +1000)

are available in the git repository at:


  git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git 
exynos-drm-next

for you to fetch changes up to b5bf0f1ea3658254bd72ef64abc97786e8a32255:

  drm/exynos: clean up register definions for fimd and decon (2016-04-30 
11:34:14 +0900)


Andrzej Hajda (23):
  drm/exynos: fix adjusted_mode pointer in exynos_plane_mode_set
  drm/exynos: build fbdev code conditionally
  drm/exynos/hdmi: clock code re-factoring
  drm/exynos/hdmi: constify global variables
  drm/exynos/hdmi: use array specifier for HDMI-PHY configurations
  drm/exynos/hdmi: code cleanup
  drm/exynos/hdmi: stop programming registers with default values
  dt-bindings: exynos_hdmi: add bindings for Exynos5433 variant
  drm/exynos/hdmi: add Exynos5433 support
  dt-bindings: video: add PCLK clock entry to exynos5433-decon
  dt-bindings: video: exynos5433-decon: add bindings for DECON-TV
  drm/exynos/hdmi: fix PHY configuration sequence
  drm/exynos/hdmi: add PHY power off signal handling
  drm/exynos/hdmi: add core reset code
  drm/exynos/hdmi: remove registry dump
  drm/exynos/decon5433: fix DECON standalone update
  drm/exynos/decon5433: reset decon on start
  drm/exynos/decon5433: do not protect window in plane disable
  drm/exynos: add helper to get crtc from pipe
  drm/exynos: add support for pipeline clock to the framework
  drm/exynos/decon5433: enable HDMI-PHY before configuring DECON
  drm/exynos/mixer: enable HDMI-PHY before configuring MIXER
  drm/exynos: convert clock_enable crtc callback to pipeline clock

Arnd Bergmann (1):
  drm/exynos: fix error handling in exynos_drm_subdrv_open

Dan Carpenter (2):
  drm/exynos: mic: fix an error code
  drm/exynos: fix a warning message

Inki Dae (4):
  drm/exynos: clean up wait_for_vblank
  drm/exynos: fimd: add HW trigger support
  drm/exynos: decon: clean up interface type
  drm/exynos: clean up register definions for fimd and decon

Javier Martinez Canillas (1):
  drm/exynos: Use VIDEO_SAMSUNG_S5P_G2D=n as G2D Kconfig dependency

Marek Szyprowski (8):
  drm/exynos: fimd: fix broken dp_clock control
  drm/exynos: exynos5433_decon: use generic of_device_get_match_data helper
  drm/exynos: dsi: use generic of_device_get_match_data helper
  drm/exynos: fimd: use generic of_device_get_match_data helper
  drm/exynos: rotator: use generic of_device_get_match_data helper
  drm/exynos: hdmi: use generic of_device_get_match_data helper
  drm/exynos: mixer: remove support for non-dt platforms
  drm/exynos: mixer: use generic of_device_get_match_data helper

 .../bindings/display/exynos/exynos5433-decon.txt   |5 +-
 .../bindings/display/exynos/exynos_hdmi.txt|   27 +-
 drivers/gpu/drm/exynos/Kconfig |2 +-
 drivers/gpu/drm/exynos/Makefile|6 +-
 drivers/gpu/drm/exynos/exynos5433_drm_decon.c  |   86 +--
 drivers/gpu/drm/exynos/exynos7_drm_decon.c |1 -
 drivers/gpu/drm/exynos/exynos_dp.c |9 +-
 drivers/gpu/drm/exynos/exynos_drm_core.c   |2 +-
 drivers/gpu/drm/exynos/exynos_drm_crtc.c   |   10 +-
 drivers/gpu/drm/exynos/exynos_drm_drv.h|   28 +-
 drivers/gpu/drm/exynos/exynos_drm_dsi.c|   27 +-
 drivers/gpu/drm/exynos/exynos_drm_fb.c |   11 -
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c  |   11 +
 drivers/gpu/drm/exynos/exynos_drm_fbdev.h  |   23 +-
 drivers/gpu/drm/exynos/exynos_drm_fimd.c   |   99 ++-
 drivers/gpu/drm/exynos/exynos_drm_mic.c|3 +-
 drivers/gpu/drm/exynos/exynos_drm_plane.c  |   12 +-
 drivers/gpu/drm/exynos/exynos_drm_rotator.c|   11 +-
 drivers/gpu/drm/exynos/exy

[PATCH v2] exynos-drm: Fix unsupported GEM memory type error message to be clear

2016-08-09 Thread Inki Dae
Picked it up. :)

Thanks,
Inki Dae


2016-08-09 8:48 GMT+09:00 Shuah Khan :

> Fix unsupported GEM memory type error message to include the memory type
> information.
>
> Signed-off-by: Shuah Khan 
> ---
> Changes since v1:
> -- Comment changed to read clearly
>
>  drivers/gpu/drm/exynos/exynos_drm_fb.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c
> b/drivers/gpu/drm/exynos/exynos_drm_fb.c
> index e016640..40ce841 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fb.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fb.c
> @@ -55,11 +55,11 @@ static int check_fb_gem_memory_type(struct drm_device
> *drm_dev,
> flags = exynos_gem->flags;
>
> /*
> -* without iommu support, not support physically non-continuous
> memory
> -* for framebuffer.
> +* Physically non-contiguous memory type for framebuffer is not
> +* supported without IOMMU.
>  */
> if (IS_NONCONTIG_BUFFER(flags)) {
> -   DRM_ERROR("cannot use this gem memory type for fb.\n");
> +   DRM_ERROR("Non-contiguous GEM memory is not supported.\n");
> return -EINVAL;
> }
>
> --
> 2.7.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe
> linux-samsung-soc" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160809/740246d5/attachment.html>


[PATCH] exynos-drm: Fix display manager failing to start without IOMMU problem

2016-08-11 Thread Inki Dae
Hi Shuah,

2016년 08월 11일 02:30에 Shuah Khan 이(가) 쓴 글:
> Fix exynos_drm_gem_create_ioctl() attempts to allocate non-contiguous GEM
> memory without IOMMU. In this case, there is no point in attempting to

DRM gem can be used for Non-DRM drivers such as GPU, V4L2 based Multimedia 
device and other DMA devices.
Even though IOMMU support is disabled, other framework based DMA drivers can 
use IOMMU - i.e., GPU driver -
and they can use non-contiguous GEM buffer through UMM. (DMABUF) 

So GEM allocation type is not dependent on IOMMU.

Thanks,
Inki Dae

> allocate non-contiguous memory, only to return error during the next step
> from exynos_drm_framebuffer_init() which leads to display manager failing
> to start.
> 
> Check if non-contiguous GEM memory is requested without IOMMU. If so,
> allocate contiguous GEM memory to help display manager start.
> 
> Signed-off-by: Shuah Khan 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_gem.c | 14 ++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c 
> b/drivers/gpu/drm/exynos/exynos_drm_gem.c
> index 4c4cb0e..4719116 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
> @@ -266,6 +266,20 @@ int exynos_drm_gem_create_ioctl(struct drm_device *dev, 
> void *data,
>   struct exynos_drm_gem *exynos_gem;
>   int ret;
>  
> + /*
> +  * Check if non-contiguous GEM memory is requested without IOMMU.
> +  * If so, allocate contiguous GEM memory.
> +  *
> +  * There is no point in attempting to allocate non-contiguous memory,
> +  * only to return error from exynos_drm_framebuffer_init() which leads
> +  * to display manager failing to start.
> + */
> + if (!is_drm_iommu_supported(dev) &&
> + (args->flags & EXYNOS_BO_NONCONTIG)) {
> + args->flags &= ~EXYNOS_BO_NONCONTIG;
> + args->flags |= EXYNOS_BO_CONTIG;
> + }
> +
>   exynos_gem = exynos_drm_gem_create(dev, args->flags, args->size);
>   if (IS_ERR(exynos_gem))
>   return PTR_ERR(exynos_gem);
> 


[PATCH] exynos-drm: Fix display manager failing to start without IOMMU problem

2016-08-16 Thread Inki Dae
Hi Shuah,

2016년 08월 13일 02:52에 Shuah Khan 이(가) 쓴 글:
> On 08/12/2016 11:28 AM, Shuah Khan wrote:
>> On 08/10/2016 05:05 PM, Shuah Khan wrote:
>>> On 08/10/2016 04:59 PM, Inki Dae wrote:
>>>> Hi Shuah,
>>>>
>>>> 2016년 08월 11일 02:30에 Shuah Khan 이(가) 쓴 글:
>>>>> Fix exynos_drm_gem_create_ioctl() attempts to allocate non-contiguous GEM
>>>>> memory without IOMMU. In this case, there is no point in attempting to
>>>>
>>>> DRM gem can be used for Non-DRM drivers such as GPU, V4L2 based Multimedia 
>>>> device and other DMA devices.
>>>> Even though IOMMU support is disabled, other framework based DMA drivers 
>>>> can use IOMMU - i.e., GPU driver -
>>>> and they can use non-contiguous GEM buffer through UMM. (DMABUF) 
>>>>
>>>> So GEM allocation type is not dependent on IOMMU.
>>>
>>> Hi Inki,
>>>
>>> I am seeing the following failure without IOMMU and light dm fails
>>> to start:
>>>
>>> [drm:exynos_drm_framebuffer_init] *ERROR* Non-continguous GEM memory is not 
>>> supported.
>>>
>>> The change I made fixed that problem and light dm starts without IOMMU.
>>> Is there a better way to fix this problem? Currently without IOMMU,
>>> light dm doesn't start.
>>>
>>> This is on linux_next
>>
>> Hi Inki,
>>
>> I am looking into this further and I am finding inconsistent
>> commits with regards to GEM contiguous and non-contiguous
>> buffers.
>>
>> Okay what you said is that:
>>
>> exymod-drm should support non-continguous and contiguous GEM memory
>> type with or without IOMMU

Right.

>>
>> However, the code currently isn't doing that. The following
>> commit allocates non-contiguous buffers when IOMMU is enabled
>> to handle contiguous allocation failures.
>>
>> There are other commits that removed checks for non-contig type.
>> Let's look at the following cases to see what should be the driver
>> behavior in these cases:
>>
>> IOMMU is disabled:
>>
>> exynos_drm_gem_create_ioctl() gets called with NONCONTIG
>> - driver should try to allocate non-contig
>> - if it can't allocate non-contig, allocate contig
>>   ( this will allow avoid failure like the one I am seeing)
>>
>> exynos_drm_gem_create_ioctl() gets called with CONTIG
>> - driver should try to allocate contig
>> - if it can't allocate contig, allocate non-contig
>>
>> What is confusing is there are several code paths in the
>> GEN allocation and checking memory types are enforcing
>> non-contig with IOMMU. Check this routine:
>>
>> exynos_drm_framebuffer_init() will reject non-contig
>> memory type when check_fb_gem_memory_type() rejects
>> non-contig GEM memory type without IOMMU.

Only in case that the gem buffer is used for framebuffer, gem memory type 
should be checked because this means the DMA of Display controller accesses the 
gem buffer so without IOMMU the DMA device cannot access non-contiguous memory 
region.
That is why exynos_drm_framebuffer_init checks gem memory type for fb not when 
gem is created.

> 
> 
> okay the very first commit that added IOMMU support
> introduced the code that rejects non-contig gem memory
> type without IOMMU.
> 
> commit 0519f9a12d0113caab78980c48a7902d2bd40c2c
> Author: Inki Dae 
> Date:   Sat Oct 20 07:53:42 2012 -0700
> 
> drm/exynos: add iommu support for exynos drm framework
> 
> Anyway, if it is th right change to fix check_fb_gem_memory_type()
> to not reject NONCONTIG_BUFFER, then I can make that change

No, as I mentioned above, the gem buffer for fb is dependent on IOMMU because 
the gem buffer for fb is used by DMA device - FIMD, DECON or Mixer.
You would need to understand that gem buffer can be used for other purposes - 
2D/3D or post process devices which don't use framebuffer - not display 
controller which uses framebuffer to scanout

Thanks,
Inki Dae

> instead of this patch I sent.
> 
>>
>> So there is inconsistency in the non-contig vs. contig
>> GEM support in exynos-drm. I think this needs to be cleaned
>> up to get the desired behavior.
>>
>> The following commit allocates non-contiguous buffers when IOMMU is
>> enabled to handle contiguous allocation failures.
>>
>> There are other commits that removed checks for non-contig type.
>> Let's look at the following cases to see what should be the driver
>> behavior in these cases:
>>
>> commit 122beea84bb90236b1ae545f08267af58

Re: [PATCH 04/13] drm/exynos: drop DRM_AUTH from DRM_RENDER_ALLOW ioctls

2019-05-27 Thread Inki Dae
Hi Emil,

19. 5. 27. 오후 5:17에 Emil Velikov 이(가) 쓴 글:
> From: Emil Velikov 
> 
> The authentication can be circumvented, by design, by using the render
> node.
> 
>>From the driver POV there is no distinction between primary and render
> nodes, thus we can drop the token.
> 
> Cc: Inki Dae 
> Cc: Joonyoung Shim 
> Cc: Seung-Woo Kim 
> Cc: Kyungmin Park 
> Cc: Tobias Jakobi 
> Signed-off-by: Emil Velikov 
> ---
> Gents, I've looked around for userspace and found only libdrm - the
> exynos library + simple apps and the X driver. All of which are safe
> with this patch.
> 
> Please have a look through other some open-source userspace that you
> have around.

Acked-by: Inki Dae 

Thanks,
Inki Dae

> 
> Tobias, you mentioned userspace projects (mpv, libretro, other) where
> you've added exynos backend. Can you please check they work fine with
> this patch?
> 
> Thanks
> Emil
> ---
>  drivers/gpu/drm/exynos/exynos_drm_drv.c | 18 +-
>  1 file changed, 9 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
> b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> index e1ef9dc9ebf3..b461d89accff 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> @@ -81,29 +81,29 @@ static const struct vm_operations_struct 
> exynos_drm_gem_vm_ops = {
>  
>  static const struct drm_ioctl_desc exynos_ioctls[] = {
>   DRM_IOCTL_DEF_DRV(EXYNOS_GEM_CREATE, exynos_drm_gem_create_ioctl,
> - DRM_AUTH | DRM_RENDER_ALLOW),
> + DRM_RENDER_ALLOW),
>   DRM_IOCTL_DEF_DRV(EXYNOS_GEM_MAP, exynos_drm_gem_map_ioctl,
> - DRM_AUTH | DRM_RENDER_ALLOW),
> + DRM_RENDER_ALLOW),
>   DRM_IOCTL_DEF_DRV(EXYNOS_GEM_GET, exynos_drm_gem_get_ioctl,
>   DRM_RENDER_ALLOW),
>   DRM_IOCTL_DEF_DRV(EXYNOS_VIDI_CONNECTION, vidi_connection_ioctl,
>   DRM_AUTH),
>   DRM_IOCTL_DEF_DRV(EXYNOS_G2D_GET_VER, exynos_g2d_get_ver_ioctl,
> - DRM_AUTH | DRM_RENDER_ALLOW),
> + DRM_RENDER_ALLOW),
>   DRM_IOCTL_DEF_DRV(EXYNOS_G2D_SET_CMDLIST, exynos_g2d_set_cmdlist_ioctl,
> - DRM_AUTH | DRM_RENDER_ALLOW),
> + DRM_RENDER_ALLOW),
>   DRM_IOCTL_DEF_DRV(EXYNOS_G2D_EXEC, exynos_g2d_exec_ioctl,
> - DRM_AUTH | DRM_RENDER_ALLOW),
> + DRM_RENDER_ALLOW),
>   DRM_IOCTL_DEF_DRV(EXYNOS_IPP_GET_RESOURCES,
>   exynos_drm_ipp_get_res_ioctl,
> - DRM_AUTH | DRM_RENDER_ALLOW),
> + DRM_RENDER_ALLOW),
>   DRM_IOCTL_DEF_DRV(EXYNOS_IPP_GET_CAPS, exynos_drm_ipp_get_caps_ioctl,
> - DRM_AUTH | DRM_RENDER_ALLOW),
> + DRM_RENDER_ALLOW),
>   DRM_IOCTL_DEF_DRV(EXYNOS_IPP_GET_LIMITS,
>   exynos_drm_ipp_get_limits_ioctl,
> - DRM_AUTH | DRM_RENDER_ALLOW),
> + DRM_RENDER_ALLOW),
>   DRM_IOCTL_DEF_DRV(EXYNOS_IPP_COMMIT, exynos_drm_ipp_commit_ioctl,
> - DRM_AUTH | DRM_RENDER_ALLOW),
> + DRM_RENDER_ALLOW),
>  };
>  
>  static const struct file_operations exynos_drm_driver_fops = {
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 0/2] drm/exynos: clean up logs

2019-04-14 Thread Inki Dae
Just clean up logs from exynos drm driver.

Inki Dae (2):
  drm/fimd: use DRM_ERROR instead of DRM_INFO in error case
  drm/exynos: remove unnecessary messages

 drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 2 --
 drivers/gpu/drm/exynos/exynos_drm_fimd.c  | 8 +++-
 2 files changed, 3 insertions(+), 7 deletions(-)

-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/2] drm/fimd: use DRM_ERROR instead of DRM_INFO in error case

2019-04-14 Thread Inki Dae
This patch makes error messages to be printed out using DRM_ERROR
instead of DRM_INFO.

Signed-off-by: Inki Dae 
---
 drivers/gpu/drm/exynos/exynos_drm_fimd.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 786a8ee..78427ec 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -400,7 +400,7 @@ static int fimd_atomic_check(struct exynos_drm_crtc *crtc,
u32 clkdiv;
 
if (mode->clock == 0) {
-   DRM_INFO("Mode has zero clock value.\n");
+   DRM_ERROR("Mode has zero clock value.\n");
return -EINVAL;
}
 
@@ -416,7 +416,7 @@ static int fimd_atomic_check(struct exynos_drm_crtc *crtc,
 
lcd_rate = clk_get_rate(ctx->lcd_clk);
if (2 * lcd_rate < ideal_clk) {
-   DRM_INFO("sclk_fimd clock too low(%lu) for requested pixel 
clock(%lu)\n",
+   DRM_ERROR("sclk_fimd clock too low(%lu) for requested pixel 
clock(%lu)\n",
 lcd_rate, ideal_clk);
return -EINVAL;
}
@@ -424,7 +424,7 @@ static int fimd_atomic_check(struct exynos_drm_crtc *crtc,
/* Find the clock divider value that gets us closest to ideal_clk */
clkdiv = DIV_ROUND_CLOSEST(lcd_rate, ideal_clk);
if (clkdiv >= 0x200) {
-   DRM_INFO("requested pixel clock(%lu) too low\n", ideal_clk);
+   DRM_ERROR("requested pixel clock(%lu) too low\n", ideal_clk);
return -EINVAL;
}
 
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/2] drm/exynos: remove unnecessary messages

2019-04-14 Thread Inki Dae
This patch removes unnecessary messages from fimd_clear_channels
and decon_clear_channels functions which print out just function
name.

Signed-off-by: Inki Dae 
---
 drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 2 --
 drivers/gpu/drm/exynos/exynos_drm_fimd.c  | 2 --
 2 files changed, 4 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c 
b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
index 5b4e0e8..ba52180 100644
--- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
@@ -561,8 +561,6 @@ static void decon_clear_channels(struct exynos_drm_crtc 
*crtc)
struct decon_context *ctx = crtc->ctx;
int win, i, ret;
 
-   DRM_DEBUG_KMS("%s\n", __FILE__);
-
for (i = 0; i < ARRAY_SIZE(decon_clks_name); i++) {
ret = clk_prepare_enable(ctx->clks[i]);
if (ret < 0)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 78427ec..ffb686a 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -350,8 +350,6 @@ static void fimd_clear_channels(struct exynos_drm_crtc 
*crtc)
struct fimd_context *ctx = crtc->ctx;
unsigned int win, ch_enabled = 0;
 
-   DRM_DEBUG_KMS("%s\n", __FILE__);
-
/* Hardware is in unknown state, so ensure it gets enabled properly */
pm_runtime_get_sync(ctx->dev);
 
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/2] drm/fimd: use DRM_ERROR instead of DRM_INFO in error case

2019-04-14 Thread Inki Dae
Hi Sam,

19. 4. 15. 오후 12:17에 Sam Ravnborg 이(가) 쓴 글:
> Hi Inki
> 
> On Mon, Apr 15, 2019 at 09:47:19AM +0900, Inki Dae wrote:
>> This patch makes error messages to be printed out using DRM_ERROR
>> instead of DRM_INFO.
>>
>> Signed-off-by: Inki Dae 
>> ---
>>  drivers/gpu/drm/exynos/exynos_drm_fimd.c | 6 +++---
>>  1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
>> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> index 786a8ee..78427ec 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> @@ -400,7 +400,7 @@ static int fimd_atomic_check(struct exynos_drm_crtc 
>> *crtc,
>>  u32 clkdiv;
>>  
>>  if (mode->clock == 0) {
>> -DRM_INFO("Mode has zero clock value.\n");
>> +DRM_ERROR("Mode has zero clock value.\n");
> 
> To give the logs a more precise info on where is comes from you
> could consider to use:
> 
>   DRM_DEV_ERROR(ctx->dev, "Mode has zero clock value.\n");

Thanks for comment and looks better. :)
This patch corrects the use of log macro so I will make and push a new patch - 
which changes all existing DRM_ERROR macros to DRM_DEV_ERROR - on top of this 
patch series.

Thanks,
Inki Dae

> 
> Likewise below.
> 
> 
>   Sam
> 
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 6/7] drm/vidi: replace platform_device pointer with device one

2019-04-15 Thread Inki Dae
Add device pointer to vidi_context and remove platform_device pointer.

It doesn't need for vidi_context to contain platform_device object.
Instead, this patch makes this driver more simply by replacing platform_device
pointer with device one.

Signed-off-by: Inki Dae 
---
 drivers/gpu/drm/exynos/exynos_drm_vidi.c | 33 
 1 file changed, 17 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_vidi.c 
b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
index 08e610c..44bcb2d 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
@@ -40,8 +40,8 @@
 
 struct vidi_context {
struct drm_encoder  encoder;
-   struct platform_device  *pdev;
struct drm_device   *drm_dev;
+   struct device   *dev;
struct exynos_drm_crtc  *crtc;
struct drm_connectorconnector;
struct exynos_drm_plane planes[WINDOWS_NR];
@@ -123,7 +123,7 @@ static void vidi_update_plane(struct exynos_drm_crtc *crtc,
return;
 
addr = exynos_drm_fb_dma_addr(state->fb, 0);
-   DRM_DEV_DEBUG_KMS(&ctx->pdev->dev, "dma_addr = %pad\n", &addr);
+   DRM_DEV_DEBUG_KMS(ctx->dev, "dma_addr = %pad\n", &addr);
 }
 
 static void vidi_enable(struct exynos_drm_crtc *crtc)
@@ -226,19 +226,19 @@ int vidi_connection_ioctl(struct drm_device *drm_dev, 
void *data,
struct drm_exynos_vidi_connection *vidi = data;
 
if (!vidi) {
-   DRM_DEV_DEBUG_KMS(&ctx->pdev->dev,
+   DRM_DEV_DEBUG_KMS(ctx->dev,
  "user data for vidi is null.\n");
return -EINVAL;
}
 
if (vidi->connection > 1) {
-   DRM_DEV_DEBUG_KMS(&ctx->pdev->dev,
+   DRM_DEV_DEBUG_KMS(ctx->dev,
  "connection should be 0 or 1.\n");
return -EINVAL;
}
 
if (ctx->connected == vidi->connection) {
-   DRM_DEV_DEBUG_KMS(&ctx->pdev->dev,
+   DRM_DEV_DEBUG_KMS(ctx->dev,
  "same connection request.\n");
return -EINVAL;
}
@@ -248,13 +248,13 @@ int vidi_connection_ioctl(struct drm_device *drm_dev, 
void *data,
 
raw_edid = (struct edid *)(unsigned long)vidi->edid;
if (!drm_edid_is_valid(raw_edid)) {
-   DRM_DEV_DEBUG_KMS(&ctx->pdev->dev,
+   DRM_DEV_DEBUG_KMS(ctx->dev,
  "edid data is invalid.\n");
return -EINVAL;
}
ctx->raw_edid = drm_edid_duplicate(raw_edid);
if (!ctx->raw_edid) {
-   DRM_DEV_DEBUG_KMS(&ctx->pdev->dev,
+   DRM_DEV_DEBUG_KMS(ctx->dev,
  "failed to allocate raw_edid.\n");
return -ENOMEM;
}
@@ -313,14 +313,14 @@ static int vidi_get_modes(struct drm_connector *connector)
 * to ctx->raw_edid through specific ioctl.
 */
if (!ctx->raw_edid) {
-   DRM_DEV_DEBUG_KMS(&ctx->pdev->dev, "raw_edid is null.\n");
+   DRM_DEV_DEBUG_KMS(ctx->dev, "raw_edid is null.\n");
return -EFAULT;
}
 
edid_len = (1 + ctx->raw_edid->extensions) * EDID_LENGTH;
edid = kmemdup(ctx->raw_edid, edid_len, GFP_KERNEL);
if (!edid) {
-   DRM_DEV_DEBUG_KMS(&ctx->pdev->dev, "failed to allocate edid\n");
+   DRM_DEV_DEBUG_KMS(ctx->dev, "failed to allocate edid\n");
return -ENOMEM;
}
 
@@ -344,7 +344,7 @@ static int vidi_create_connector(struct drm_encoder 
*encoder)
ret = drm_connector_init(ctx->drm_dev, connector,
&vidi_connector_funcs, DRM_MODE_CONNECTOR_VIRTUAL);
if (ret) {
-   DRM_DEV_ERROR(ctx->drm_dev->dev,
+   DRM_DEV_ERROR(ctx->dev,
  "Failed to initialize connector with drm\n");
return ret;
}
@@ -448,13 +448,14 @@ static const struct component_ops vidi_component_ops = {
 static int vidi_probe(struct platform_device *pdev)
 {
struct vidi_context *ctx;
+   struct device *dev = &pdev->dev;
int ret;
 
-   ctx = devm_kzalloc(&pdev->dev, sizeof(*ctx), GFP_KERNEL);
+   ctx = devm_kzalloc(dev, sizeof(*ctx), GFP_KERNEL);
if (!ctx)
return -ENOMEM;
 
-   ctx->pdev = pdev;
+   ctx->dev = dev;
 
timer_setu

[PATCH 7/7] drm/ipp: clean up debug messages

2019-04-15 Thread Inki Dae
Print out debug messages with correct device name.

As for this, this patch adds device pointer to exynos_drm_ipp structure,
and in case of exynos_drm_ipp_task structure, replace drm_device pointer
with device one. This will make each ipp driver to print out debug
messages with correct device name.

Signed-off-by: Inki Dae 
---
 drivers/gpu/drm/exynos/exynos_drm_fimc.c|  5 ++--
 drivers/gpu/drm/exynos/exynos_drm_gsc.c |  5 ++--
 drivers/gpu/drm/exynos/exynos_drm_ipp.c | 46 ++---
 drivers/gpu/drm/exynos/exynos_drm_ipp.h |  9 +++---
 drivers/gpu/drm/exynos/exynos_drm_rotator.c |  5 ++--
 drivers/gpu/drm/exynos/exynos_drm_scaler.c  |  5 ++--
 6 files changed, 40 insertions(+), 35 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimc.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
index 71b0cb1..c50b0f9 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
@@ -1134,9 +1134,10 @@ static int fimc_bind(struct device *dev, struct device 
*master, void *data)
struct exynos_drm_ipp *ipp = &ctx->ipp;
 
ctx->drm_dev = drm_dev;
+   ipp->drm_dev = drm_dev;
exynos_drm_register_dma(drm_dev, dev);
 
-   exynos_drm_ipp_register(drm_dev, ipp, &ipp_funcs,
+   exynos_drm_ipp_register(dev, ipp, &ipp_funcs,
DRM_EXYNOS_IPP_CAP_CROP | DRM_EXYNOS_IPP_CAP_ROTATE |
DRM_EXYNOS_IPP_CAP_SCALE | DRM_EXYNOS_IPP_CAP_CONVERT,
ctx->formats, ctx->num_formats, "fimc");
@@ -1153,7 +1154,7 @@ static void fimc_unbind(struct device *dev, struct device 
*master,
struct drm_device *drm_dev = data;
struct exynos_drm_ipp *ipp = &ctx->ipp;
 
-   exynos_drm_ipp_unregister(drm_dev, ipp);
+   exynos_drm_ipp_unregister(dev, ipp);
exynos_drm_unregister_dma(drm_dev, dev);
 }
 
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gsc.c 
b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
index 433df3e..0bfb5e9 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
@@ -1170,9 +1170,10 @@ static int gsc_bind(struct device *dev, struct device 
*master, void *data)
struct exynos_drm_ipp *ipp = &ctx->ipp;
 
ctx->drm_dev = drm_dev;
+   ctx->drm_dev = drm_dev;
exynos_drm_register_dma(drm_dev, dev);
 
-   exynos_drm_ipp_register(drm_dev, ipp, &ipp_funcs,
+   exynos_drm_ipp_register(dev, ipp, &ipp_funcs,
DRM_EXYNOS_IPP_CAP_CROP | DRM_EXYNOS_IPP_CAP_ROTATE |
DRM_EXYNOS_IPP_CAP_SCALE | DRM_EXYNOS_IPP_CAP_CONVERT,
ctx->formats, ctx->num_formats, "gsc");
@@ -1189,7 +1190,7 @@ static void gsc_unbind(struct device *dev, struct device 
*master,
struct drm_device *drm_dev = data;
struct exynos_drm_ipp *ipp = &ctx->ipp;
 
-   exynos_drm_ipp_unregister(drm_dev, ipp);
+   exynos_drm_ipp_unregister(dev, ipp);
exynos_drm_unregister_dma(drm_dev, dev);
 }
 
diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c 
b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
index a1ee541..c862099 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
@@ -43,7 +43,7 @@ static LIST_HEAD(ipp_list);
  * Returns:
  * Zero on success, error code on failure.
  */
-int exynos_drm_ipp_register(struct drm_device *dev, struct exynos_drm_ipp *ipp,
+int exynos_drm_ipp_register(struct device *dev, struct exynos_drm_ipp *ipp,
const struct exynos_drm_ipp_funcs *funcs, unsigned int caps,
const struct exynos_drm_ipp_formats *formats,
unsigned int num_formats, const char *name)
@@ -67,7 +67,7 @@ int exynos_drm_ipp_register(struct drm_device *dev, struct 
exynos_drm_ipp *ipp,
list_add_tail(&ipp->head, &ipp_list);
ipp->id = num_ipp++;
 
-   DRM_DEV_DEBUG_DRIVER(dev->dev, "Registered ipp %d\n", ipp->id);
+   DRM_DEV_DEBUG_DRIVER(dev, "Registered ipp %d\n", ipp->id);
 
return 0;
 }
@@ -77,7 +77,7 @@ int exynos_drm_ipp_register(struct drm_device *dev, struct 
exynos_drm_ipp *ipp,
  * @dev: DRM device
  * @ipp: ipp module
  */
-void exynos_drm_ipp_unregister(struct drm_device *dev,
+void exynos_drm_ipp_unregister(struct device *dev,
   struct exynos_drm_ipp *ipp)
 {
WARN_ON(ipp->task);
@@ -268,7 +268,7 @@ static inline struct exynos_drm_ipp_task *
task->src.rect.h = task->dst.rect.h = UINT_MAX;
task->transform.rotation = DRM_MODE_ROTATE_0;
 
-   DRM_DEV_DEBUG_DRIVER(ipp->dev->dev, "Allocated task %pK\n", task);
+   DRM_DEV_DEBUG_DRIVER(task->dev, "Allocated task %pK\n", task);
 
return task;
 }
@@ -335,7 +335,7 @@ static int exynos_drm_ipp_task

[PATCH 4/7] drm/exynos: use DRM_DEV_ERROR to print out error message

2019-04-15 Thread Inki Dae
This patch just cleans up the use of error log macro, which changes
the log macro to DRM_DEV_ERROR.

Signed-off-by: Inki Dae 
---
 drivers/gpu/drm/exynos/exynos5433_drm_decon.c |  2 +-
 drivers/gpu/drm/exynos/exynos7_drm_decon.c| 14 +---
 drivers/gpu/drm/exynos/exynos_dp.c|  9 +++--
 drivers/gpu/drm/exynos/exynos_drm_dma.c   |  2 +-
 drivers/gpu/drm/exynos/exynos_drm_dpi.c   |  9 +++--
 drivers/gpu/drm/exynos/exynos_drm_dsi.c   |  7 ++--
 drivers/gpu/drm/exynos/exynos_drm_fb.c|  9 +++--
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 19 +++
 drivers/gpu/drm/exynos/exynos_drm_fimc.c  |  7 ++--
 drivers/gpu/drm/exynos/exynos_drm_fimd.c  | 27 ++-
 drivers/gpu/drm/exynos/exynos_drm_g2d.c   | 49 +++
 drivers/gpu/drm/exynos/exynos_drm_gem.c   | 17 +-
 drivers/gpu/drm/exynos/exynos_drm_gsc.c   | 19 ++-
 drivers/gpu/drm/exynos/exynos_drm_mic.c   | 25 --
 drivers/gpu/drm/exynos/exynos_drm_plane.c |  5 +--
 drivers/gpu/drm/exynos/exynos_drm_vidi.c  | 11 +++---
 drivers/gpu/drm/exynos/exynos_hdmi.c  | 42 +--
 drivers/gpu/drm/exynos/exynos_mixer.c | 26 +-
 18 files changed, 179 insertions(+), 120 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c 
b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
index ba52180..c2715e5 100644
--- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
@@ -188,7 +188,7 @@ static void decon_setup_trigger(struct decon_context *ctx)
 
if (regmap_update_bits(ctx->sysreg, DSD_CFG_MUX,
   DSD_CFG_MUX_TE_UNMASK_GLOBAL, ~0))
-   DRM_ERROR("Cannot update sysreg.\n");
+   DRM_DEV_ERROR(ctx->dev, "Cannot update sysreg.\n");
 }
 
 static void decon_commit(struct exynos_drm_crtc *crtc)
diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c 
b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
index a6bb411..bc76f27 100644
--- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
@@ -620,7 +620,7 @@ static int decon_bind(struct device *dev, struct device 
*master, void *data)
 
ret = decon_ctx_initialize(ctx, drm_dev);
if (ret) {
-   DRM_ERROR("decon_ctx_initialize failed.\n");
+   DRM_DEV_ERROR(dev, "decon_ctx_initialize failed.\n");
return ret;
}
 
@@ -800,25 +800,29 @@ static int exynos7_decon_resume(struct device *dev)
 
ret = clk_prepare_enable(ctx->pclk);
if (ret < 0) {
-   DRM_ERROR("Failed to prepare_enable the pclk [%d]\n", ret);
+   DRM_DEV_ERROR(dev, "Failed to prepare_enable the pclk [%d]\n",
+ ret);
return ret;
}
 
ret = clk_prepare_enable(ctx->aclk);
if (ret < 0) {
-   DRM_ERROR("Failed to prepare_enable the aclk [%d]\n", ret);
+   DRM_DEV_ERROR(dev, "Failed to prepare_enable the aclk [%d]\n",
+ ret);
return ret;
}
 
ret = clk_prepare_enable(ctx->eclk);
if  (ret < 0) {
-   DRM_ERROR("Failed to prepare_enable the eclk [%d]\n", ret);
+   DRM_DEV_ERROR(dev, "Failed to prepare_enable the eclk [%d]\n",
+ ret);
return ret;
}
 
ret = clk_prepare_enable(ctx->vclk);
if  (ret < 0) {
-   DRM_ERROR("Failed to prepare_enable the vclk [%d]\n", ret);
+   DRM_DEV_ERROR(dev, "Failed to prepare_enable the vclk [%d]\n",
+ ret);
return ret;
}
 
diff --git a/drivers/gpu/drm/exynos/exynos_dp.c 
b/drivers/gpu/drm/exynos/exynos_dp.c
index 471242a..b0288cf 100644
--- a/drivers/gpu/drm/exynos/exynos_dp.c
+++ b/drivers/gpu/drm/exynos/exynos_dp.c
@@ -83,7 +83,8 @@ static int exynos_dp_get_modes(struct analogix_dp_plat_data 
*plat_data,
 
mode = drm_mode_create(connector->dev);
if (!mode) {
-   DRM_ERROR("failed to create a new display mode.\n");
+   DRM_DEV_ERROR(dp->dev,
+ "failed to create a new display mode.\n");
return num_modes;
}
 
@@ -111,7 +112,8 @@ static int exynos_dp_bridge_attach(struct 
analogix_dp_plat_data *plat_data,
if (dp->ptn_bridge) {
ret = drm_bridge_attach(&dp->encoder, dp->ptn_bridge, bridge);
if (ret) {
-   DRM_ERROR("Failed to attach bridge to drm\n");
+   DRM_DEV_ERROR(dp->dev,
+ "Failed to attach bridge to 

[PATCH 1/7] drm/exynos: g2d: remove style error

2019-04-15 Thread Inki Dae
From: Seung-Woo Kim 

Remove checkpatch error, "foo* bar" should be "foo *bar".

Signed-off-by: Seung-Woo Kim 
Signed-off-by: Inki Dae 
---
 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 24c536d..a9c26b3 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
@@ -845,7 +845,7 @@ static void g2d_free_runqueue_node(struct g2d_data *g2d,
  *
  * Has to be called under runqueue lock.
  */
-static void g2d_remove_runqueue_nodes(struct g2d_data *g2d, struct drm_file* 
file)
+static void g2d_remove_runqueue_nodes(struct g2d_data *g2d, struct drm_file 
*file)
 {
struct g2d_runqueue_node *node, *n;
 
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 0/7 v2] drm/exynos: clean up logs

2019-04-15 Thread Inki Dae
Just clean up logs of Exynos DRM driver.

What this patch series does is to replace the use of existing DRM_DEBUG/ERROR
macros with DRM_DEV_DEBUG*/ERROR* macros including relevant code cleanup.

Changelog v2:
. Clean up debug/error messages of all Exynos DRM KMS and DMA drivers.
. Clean up vidi driver by adding device pointer to vidi_context.
. Clean up ipp driver by using device pointer instead of drm_device one,
  which makes ipp driver to print out the debug messages with correct
  device name.

Inki Dae (6):
  drm/fimd: use DRM_ERROR instead of DRM_INFO in error case
  drm/exynos: remove unnecessary messages
  drm/exynos: use DRM_DEV_ERROR to print out error message
  drm/exynos: use DRM_DEV_DEBUG* instead of DRM_DEBUG macro
  drm/vidi: replace platform_device pointer with device one
  drm/ipp: clean up debug messages

Seung-Woo Kim (1):
  drm/exynos: g2d: remove style error

 drivers/gpu/drm/exynos/exynos5433_drm_decon.c |  6 +-
 drivers/gpu/drm/exynos/exynos7_drm_decon.c| 26 +++
 drivers/gpu/drm/exynos/exynos_dp.c|  9 ++-
 drivers/gpu/drm/exynos/exynos_drm_dma.c   |  2 +-
 drivers/gpu/drm/exynos/exynos_drm_dpi.c   |  9 ++-
 drivers/gpu/drm/exynos/exynos_drm_dsi.c   |  7 +-
 drivers/gpu/drm/exynos/exynos_drm_fb.c|  9 ++-
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 26 ---
 drivers/gpu/drm/exynos/exynos_drm_fimc.c  | 97 ++-
 drivers/gpu/drm/exynos/exynos_drm_fimd.c  | 48 +++--
 drivers/gpu/drm/exynos/exynos_drm_g2d.c   | 51 +++---
 drivers/gpu/drm/exynos/exynos_drm_gem.c   | 35 +-
 drivers/gpu/drm/exynos/exynos_drm_gsc.c   | 72 ++--
 drivers/gpu/drm/exynos/exynos_drm_ipp.c   | 71 
 drivers/gpu/drm/exynos/exynos_drm_ipp.h   |  9 +--
 drivers/gpu/drm/exynos/exynos_drm_mic.c   | 29 
 drivers/gpu/drm/exynos/exynos_drm_plane.c | 15 +++--
 drivers/gpu/drm/exynos/exynos_drm_rotator.c   |  5 +-
 drivers/gpu/drm/exynos/exynos_drm_scaler.c|  5 +-
 drivers/gpu/drm/exynos/exynos_drm_vidi.c  | 49 --
 drivers/gpu/drm/exynos/exynos_hdmi.c  | 75 -
 drivers/gpu/drm/exynos/exynos_mixer.c | 43 +++-
 22 files changed, 400 insertions(+), 298 deletions(-)

-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/7] drm/fimd: use DRM_ERROR instead of DRM_INFO in error case

2019-04-15 Thread Inki Dae
This patch makes error messages to be printed out using DRM_ERROR
instead of DRM_INFO.

Signed-off-by: Inki Dae 
---
 drivers/gpu/drm/exynos/exynos_drm_fimd.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 786a8ee..78427ec 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -400,7 +400,7 @@ static int fimd_atomic_check(struct exynos_drm_crtc *crtc,
u32 clkdiv;
 
if (mode->clock == 0) {
-   DRM_INFO("Mode has zero clock value.\n");
+   DRM_ERROR("Mode has zero clock value.\n");
return -EINVAL;
}
 
@@ -416,7 +416,7 @@ static int fimd_atomic_check(struct exynos_drm_crtc *crtc,
 
lcd_rate = clk_get_rate(ctx->lcd_clk);
if (2 * lcd_rate < ideal_clk) {
-   DRM_INFO("sclk_fimd clock too low(%lu) for requested pixel 
clock(%lu)\n",
+   DRM_ERROR("sclk_fimd clock too low(%lu) for requested pixel 
clock(%lu)\n",
 lcd_rate, ideal_clk);
return -EINVAL;
}
@@ -424,7 +424,7 @@ static int fimd_atomic_check(struct exynos_drm_crtc *crtc,
/* Find the clock divider value that gets us closest to ideal_clk */
clkdiv = DIV_ROUND_CLOSEST(lcd_rate, ideal_clk);
if (clkdiv >= 0x200) {
-   DRM_INFO("requested pixel clock(%lu) too low\n", ideal_clk);
+   DRM_ERROR("requested pixel clock(%lu) too low\n", ideal_clk);
return -EINVAL;
}
 
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 5/7] drm/exynos: use DRM_DEV_DEBUG* instead of DRM_DEBUG macro

2019-04-15 Thread Inki Dae
Use DRM_DEV_DEBUG* instead of DRM_DEBUG macro to print out
debug messages.

This patch just cleans up the use of debug log macro, which changes
the log macro to DRM_DEV_DEBUG*.

Signed-off-by: Inki Dae 
---
 drivers/gpu/drm/exynos/exynos5433_drm_decon.c |  2 +-
 drivers/gpu/drm/exynos/exynos7_drm_decon.c| 10 ++--
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c |  7 ++-
 drivers/gpu/drm/exynos/exynos_drm_fimc.c  | 85 ++-
 drivers/gpu/drm/exynos/exynos_drm_fimd.c  | 19 +++---
 drivers/gpu/drm/exynos/exynos_drm_gem.c   | 18 +++---
 drivers/gpu/drm/exynos/exynos_drm_gsc.c   | 48 +++
 drivers/gpu/drm/exynos/exynos_drm_ipp.c   | 61 ---
 drivers/gpu/drm/exynos/exynos_drm_mic.c   |  4 +-
 drivers/gpu/drm/exynos/exynos_drm_plane.c | 10 ++--
 drivers/gpu/drm/exynos/exynos_drm_vidi.c  | 25 
 drivers/gpu/drm/exynos/exynos_hdmi.c  | 33 +++
 drivers/gpu/drm/exynos/exynos_mixer.c | 17 +++---
 13 files changed, 191 insertions(+), 148 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c 
b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
index c2715e5..73b318a 100644
--- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
@@ -356,7 +356,7 @@ static void decon_win_set_pixfmt(struct decon_context *ctx, 
unsigned int win,
break;
}
 
-   DRM_DEBUG_KMS("cpp = %u\n", fb->format->cpp[0]);
+   DRM_DEV_DEBUG_KMS(ctx->dev, "cpp = %u\n", fb->format->cpp[0]);
 
/*
 * In case of exynos, setting dma-burst to 16Word causes permanent
diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c 
b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
index bc76f27..0217ee9 100644
--- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
@@ -99,7 +99,7 @@ static void decon_wait_for_vblank(struct exynos_drm_crtc 
*crtc)
if (!wait_event_timeout(ctx->wait_vsync_queue,
!atomic_read(&ctx->wait_vsync_event),
HZ/20))
-   DRM_DEBUG_KMS("vblank wait timed out.\n");
+   DRM_DEV_DEBUG_KMS(ctx->dev, "vblank wait timed out.\n");
 }
 
 static void decon_clear_channels(struct exynos_drm_crtc *crtc)
@@ -313,7 +313,7 @@ static void decon_win_set_pixfmt(struct decon_context *ctx, 
unsigned int win,
break;
}
 
-   DRM_DEBUG_KMS("cpp = %d\n", fb->format->cpp[0]);
+   DRM_DEV_DEBUG_KMS(ctx->dev, "cpp = %d\n", fb->format->cpp[0]);
 
/*
 * In case of exynos, setting dma-burst to 16Word causes permanent
@@ -420,9 +420,9 @@ static void decon_update_plane(struct exynos_drm_crtc *crtc,
writel(state->src.x, ctx->regs + VIDW_OFFSET_X(win));
writel(state->src.y, ctx->regs + VIDW_OFFSET_Y(win));
 
-   DRM_DEBUG_KMS("start addr = 0x%lx\n",
+   DRM_DEV_DEBUG_KMS(ctx->dev, "start addr = 0x%lx\n",
(unsigned long)val);
-   DRM_DEBUG_KMS("ovl_width = %d, ovl_height = %d\n",
+   DRM_DEV_DEBUG_KMS(ctx->dev, "ovl_width = %d, ovl_height = %d\n",
state->crtc.w, state->crtc.h);
 
val = VIDOSDxA_TOPLEFT_X(state->crtc.x) |
@@ -440,7 +440,7 @@ static void decon_update_plane(struct exynos_drm_crtc *crtc,
 
writel(val, ctx->regs + VIDOSD_B(win));
 
-   DRM_DEBUG_KMS("osd pos: tx = %d, ty = %d, bx = %d, by = %d\n",
+   DRM_DEV_DEBUG_KMS(ctx->dev, "osd pos: tx = %d, ty = %d, bx = %d, by = 
%d\n",
state->crtc.x, state->crtc.y, last_x, last_y);
 
/* OSD alpha */
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c 
b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
index 3fb9e83..1186e9c 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
@@ -124,9 +124,10 @@ static int exynos_drm_fbdev_create(struct drm_fb_helper 
*helper,
unsigned long size;
int ret;
 
-   DRM_DEBUG_KMS("surface width(%d), height(%d) and bpp(%d\n",
-   sizes->surface_width, sizes->surface_height,
-   sizes->surface_bpp);
+   DRM_DEV_DEBUG_KMS(dev->dev,
+ "surface width(%d), height(%d) and bpp(%d\n",
+ sizes->surface_width, sizes->surface_height,
+ sizes->surface_bpp);
 
mode_cmd.width = sizes->surface_width;
mode_cmd.height = sizes->surface_height;
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimc.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
index 5a5641b..71b0cb1 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
+++ b/drivers/gpu/drm/exynos/e

[PATCH 3/7] drm/exynos: remove unnecessary messages

2019-04-15 Thread Inki Dae
This patch removes unnecessary messages from fimd_clear_channels
and decon_clear_channels functions which print out just function
name.

Signed-off-by: Inki Dae 
---
 drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 2 --
 drivers/gpu/drm/exynos/exynos7_drm_decon.c| 2 --
 drivers/gpu/drm/exynos/exynos_drm_fimd.c  | 2 --
 3 files changed, 6 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c 
b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
index 5b4e0e8..ba52180 100644
--- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
@@ -561,8 +561,6 @@ static void decon_clear_channels(struct exynos_drm_crtc 
*crtc)
struct decon_context *ctx = crtc->ctx;
int win, i, ret;
 
-   DRM_DEBUG_KMS("%s\n", __FILE__);
-
for (i = 0; i < ARRAY_SIZE(decon_clks_name); i++) {
ret = clk_prepare_enable(ctx->clks[i]);
if (ret < 0)
diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c 
b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
index 381aa3d..a6bb411 100644
--- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
@@ -107,8 +107,6 @@ static void decon_clear_channels(struct exynos_drm_crtc 
*crtc)
struct decon_context *ctx = crtc->ctx;
unsigned int win, ch_enabled = 0;
 
-   DRM_DEBUG_KMS("%s\n", __FILE__);
-
/* Check if any channel is enabled. */
for (win = 0; win < WINDOWS_NR; win++) {
u32 val = readl(ctx->regs + WINCON(win));
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 78427ec..ffb686a 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -350,8 +350,6 @@ static void fimd_clear_channels(struct exynos_drm_crtc 
*crtc)
struct fimd_context *ctx = crtc->ctx;
unsigned int win, ch_enabled = 0;
 
-   DRM_DEBUG_KMS("%s\n", __FILE__);
-
/* Hardware is in unknown state, so ensure it gets enabled properly */
pm_runtime_get_sync(ctx->dev);
 
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/7] drm/exynos: g2d: remove style error

2019-04-15 Thread Inki Dae
Oops. There was my mistake. This patch is already merged to exynos-drm-fixes.
Please ignore this one.

Thanks,
Inki Dae

19. 4. 15. 오후 5:54에 Inki Dae 이(가) 쓴 글:
> From: Seung-Woo Kim 
> 
> Remove checkpatch error, "foo* bar" should be "foo *bar".
> 
> Signed-off-by: Seung-Woo Kim 
> Signed-off-by: Inki Dae 
> ---
>  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 24c536d..a9c26b3 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
> @@ -845,7 +845,7 @@ static void g2d_free_runqueue_node(struct g2d_data *g2d,
>   *
>   * Has to be called under runqueue lock.
>   */
> -static void g2d_remove_runqueue_nodes(struct g2d_data *g2d, struct drm_file* 
> file)
> +static void g2d_remove_runqueue_nodes(struct g2d_data *g2d, struct drm_file 
> *file)
>  {
>   struct g2d_runqueue_node *node, *n;
>  
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/7 v2] drm/exynos: clean up logs

2019-04-15 Thread Inki Dae
Hi Sam,

19. 4. 15. 오후 6:13에 Sam Ravnborg 이(가) 쓴 글:
> Hi Inki
> 
>  
>> Inki Dae (6):
>>   drm/fimd: use DRM_ERROR instead of DRM_INFO in error case
>>   drm/exynos: remove unnecessary messages
>>   drm/exynos: use DRM_DEV_ERROR to print out error message
>>   drm/exynos: use DRM_DEV_DEBUG* instead of DRM_DEBUG macro
>>   drm/vidi: replace platform_device pointer with device one
>>   drm/ipp: clean up debug messages
> 
> In generel plese prefix all patches with "drm/exynos: " as this
> is the driver that is updated.

Oops, sorry. It's my mistake. I didn't check and posted them in a hurry.

> If a patch is specific to a sub-module in the driver mention
> this in the subject.
> Examples:
> drm/exynos: fix log level in fimd
> drm/exynos: use device pointer in vidi> drm/exynos: drop irrelevant logging 
> in ipp

I will send them again.

Thanks,
Inki Dae

> 
>   Sam
> 
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/6] drm/exynos: fimd: use DRM_ERROR instead of DRM_INFO in error case

2019-04-15 Thread Inki Dae
This patch makes error messages to be printed out using DRM_ERROR
instead of DRM_INFO.

Signed-off-by: Inki Dae 
---
 drivers/gpu/drm/exynos/exynos_drm_fimd.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 786a8ee..78427ec 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -400,7 +400,7 @@ static int fimd_atomic_check(struct exynos_drm_crtc *crtc,
u32 clkdiv;
 
if (mode->clock == 0) {
-   DRM_INFO("Mode has zero clock value.\n");
+   DRM_ERROR("Mode has zero clock value.\n");
return -EINVAL;
}
 
@@ -416,7 +416,7 @@ static int fimd_atomic_check(struct exynos_drm_crtc *crtc,
 
lcd_rate = clk_get_rate(ctx->lcd_clk);
if (2 * lcd_rate < ideal_clk) {
-   DRM_INFO("sclk_fimd clock too low(%lu) for requested pixel 
clock(%lu)\n",
+   DRM_ERROR("sclk_fimd clock too low(%lu) for requested pixel 
clock(%lu)\n",
 lcd_rate, ideal_clk);
return -EINVAL;
}
@@ -424,7 +424,7 @@ static int fimd_atomic_check(struct exynos_drm_crtc *crtc,
/* Find the clock divider value that gets us closest to ideal_clk */
clkdiv = DIV_ROUND_CLOSEST(lcd_rate, ideal_clk);
if (clkdiv >= 0x200) {
-   DRM_INFO("requested pixel clock(%lu) too low\n", ideal_clk);
+   DRM_ERROR("requested pixel clock(%lu) too low\n", ideal_clk);
return -EINVAL;
}
 
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 0/6 v3] drm/exynos: clean up logs

2019-04-15 Thread Inki Dae
Just clean up logs of Exynos DRM driver.

What this patch series does is to replace the use of existing DRM_DEBUG/ERROR
macros with DRM_DEV_DEBUG*/ERROR* macros including relevant code cleanup.

Chnagelog v3:
. correct subject prefix.
. drop one patch merged already from v2.

Changelog v2:
. Clean up debug/error messages of all Exynos DRM KMS and DMA drivers.
. Clean up vidi driver by adding device pointer to vidi_context.
. Clean up ipp driver by using device pointer instead of drm_device one,
  which makes ipp driver to print out the debug messages with correct
  device name.

Inki Dae (6):
  drm/exynos: fimd: use DRM_ERROR instead of DRM_INFO in error case
  drm/exynos: remove unnecessary messages
  drm/exynos: use DRM_DEV_ERROR to print out error message
  drm/exynos: use DRM_DEV_DEBUG* instead of DRM_DEBUG macro
  drm/exynos: vidi: replace platform_device pointer with device one
  drm/exynos: ipp: clean up debug messages

 drivers/gpu/drm/exynos/exynos5433_drm_decon.c |  6 +-
 drivers/gpu/drm/exynos/exynos7_drm_decon.c| 26 +++
 drivers/gpu/drm/exynos/exynos_dp.c|  9 ++-
 drivers/gpu/drm/exynos/exynos_drm_dma.c   |  2 +-
 drivers/gpu/drm/exynos/exynos_drm_dpi.c   |  9 ++-
 drivers/gpu/drm/exynos/exynos_drm_dsi.c   |  7 +-
 drivers/gpu/drm/exynos/exynos_drm_fb.c|  9 ++-
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 26 ---
 drivers/gpu/drm/exynos/exynos_drm_fimc.c  | 97 ++-
 drivers/gpu/drm/exynos/exynos_drm_fimd.c  | 48 +++--
 drivers/gpu/drm/exynos/exynos_drm_g2d.c   | 49 --
 drivers/gpu/drm/exynos/exynos_drm_gem.c   | 35 +-
 drivers/gpu/drm/exynos/exynos_drm_gsc.c   | 72 ++--
 drivers/gpu/drm/exynos/exynos_drm_ipp.c   | 71 
 drivers/gpu/drm/exynos/exynos_drm_ipp.h   |  9 +--
 drivers/gpu/drm/exynos/exynos_drm_mic.c   | 29 
 drivers/gpu/drm/exynos/exynos_drm_plane.c | 15 +++--
 drivers/gpu/drm/exynos/exynos_drm_rotator.c   |  5 +-
 drivers/gpu/drm/exynos/exynos_drm_scaler.c|  5 +-
 drivers/gpu/drm/exynos/exynos_drm_vidi.c  | 49 --
 drivers/gpu/drm/exynos/exynos_hdmi.c  | 75 -
 drivers/gpu/drm/exynos/exynos_mixer.c | 43 +++-
 22 files changed, 399 insertions(+), 297 deletions(-)

-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/6] drm/exynos: remove unnecessary messages

2019-04-15 Thread Inki Dae
This patch removes unnecessary messages from fimd_clear_channels
and decon_clear_channels functions which print out just function
name.

Signed-off-by: Inki Dae 
---
 drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 2 --
 drivers/gpu/drm/exynos/exynos7_drm_decon.c| 2 --
 drivers/gpu/drm/exynos/exynos_drm_fimd.c  | 2 --
 3 files changed, 6 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c 
b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
index 5b4e0e8..ba52180 100644
--- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
@@ -561,8 +561,6 @@ static void decon_clear_channels(struct exynos_drm_crtc 
*crtc)
struct decon_context *ctx = crtc->ctx;
int win, i, ret;
 
-   DRM_DEBUG_KMS("%s\n", __FILE__);
-
for (i = 0; i < ARRAY_SIZE(decon_clks_name); i++) {
ret = clk_prepare_enable(ctx->clks[i]);
if (ret < 0)
diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c 
b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
index 381aa3d..a6bb411 100644
--- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
@@ -107,8 +107,6 @@ static void decon_clear_channels(struct exynos_drm_crtc 
*crtc)
struct decon_context *ctx = crtc->ctx;
unsigned int win, ch_enabled = 0;
 
-   DRM_DEBUG_KMS("%s\n", __FILE__);
-
/* Check if any channel is enabled. */
for (win = 0; win < WINDOWS_NR; win++) {
u32 val = readl(ctx->regs + WINCON(win));
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 78427ec..ffb686a 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -350,8 +350,6 @@ static void fimd_clear_channels(struct exynos_drm_crtc 
*crtc)
struct fimd_context *ctx = crtc->ctx;
unsigned int win, ch_enabled = 0;
 
-   DRM_DEBUG_KMS("%s\n", __FILE__);
-
/* Hardware is in unknown state, so ensure it gets enabled properly */
pm_runtime_get_sync(ctx->dev);
 
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 5/6] drm/exynos: vidi: replace platform_device pointer with device one

2019-04-15 Thread Inki Dae
Add device pointer to vidi_context and remove platform_device pointer.

It doesn't need for vidi_context to contain platform_device object.
Instead, this patch makes this driver more simply by replacing platform_device
pointer with device one.

Signed-off-by: Inki Dae 
---
 drivers/gpu/drm/exynos/exynos_drm_vidi.c | 33 
 1 file changed, 17 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_vidi.c 
b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
index 08e610c..44bcb2d 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
@@ -40,8 +40,8 @@
 
 struct vidi_context {
struct drm_encoder  encoder;
-   struct platform_device  *pdev;
struct drm_device   *drm_dev;
+   struct device   *dev;
struct exynos_drm_crtc  *crtc;
struct drm_connectorconnector;
struct exynos_drm_plane planes[WINDOWS_NR];
@@ -123,7 +123,7 @@ static void vidi_update_plane(struct exynos_drm_crtc *crtc,
return;
 
addr = exynos_drm_fb_dma_addr(state->fb, 0);
-   DRM_DEV_DEBUG_KMS(&ctx->pdev->dev, "dma_addr = %pad\n", &addr);
+   DRM_DEV_DEBUG_KMS(ctx->dev, "dma_addr = %pad\n", &addr);
 }
 
 static void vidi_enable(struct exynos_drm_crtc *crtc)
@@ -226,19 +226,19 @@ int vidi_connection_ioctl(struct drm_device *drm_dev, 
void *data,
struct drm_exynos_vidi_connection *vidi = data;
 
if (!vidi) {
-   DRM_DEV_DEBUG_KMS(&ctx->pdev->dev,
+   DRM_DEV_DEBUG_KMS(ctx->dev,
  "user data for vidi is null.\n");
return -EINVAL;
}
 
if (vidi->connection > 1) {
-   DRM_DEV_DEBUG_KMS(&ctx->pdev->dev,
+   DRM_DEV_DEBUG_KMS(ctx->dev,
  "connection should be 0 or 1.\n");
return -EINVAL;
}
 
if (ctx->connected == vidi->connection) {
-   DRM_DEV_DEBUG_KMS(&ctx->pdev->dev,
+   DRM_DEV_DEBUG_KMS(ctx->dev,
  "same connection request.\n");
return -EINVAL;
}
@@ -248,13 +248,13 @@ int vidi_connection_ioctl(struct drm_device *drm_dev, 
void *data,
 
raw_edid = (struct edid *)(unsigned long)vidi->edid;
if (!drm_edid_is_valid(raw_edid)) {
-   DRM_DEV_DEBUG_KMS(&ctx->pdev->dev,
+   DRM_DEV_DEBUG_KMS(ctx->dev,
  "edid data is invalid.\n");
return -EINVAL;
}
ctx->raw_edid = drm_edid_duplicate(raw_edid);
if (!ctx->raw_edid) {
-   DRM_DEV_DEBUG_KMS(&ctx->pdev->dev,
+   DRM_DEV_DEBUG_KMS(ctx->dev,
  "failed to allocate raw_edid.\n");
return -ENOMEM;
}
@@ -313,14 +313,14 @@ static int vidi_get_modes(struct drm_connector *connector)
 * to ctx->raw_edid through specific ioctl.
 */
if (!ctx->raw_edid) {
-   DRM_DEV_DEBUG_KMS(&ctx->pdev->dev, "raw_edid is null.\n");
+   DRM_DEV_DEBUG_KMS(ctx->dev, "raw_edid is null.\n");
return -EFAULT;
}
 
edid_len = (1 + ctx->raw_edid->extensions) * EDID_LENGTH;
edid = kmemdup(ctx->raw_edid, edid_len, GFP_KERNEL);
if (!edid) {
-   DRM_DEV_DEBUG_KMS(&ctx->pdev->dev, "failed to allocate edid\n");
+   DRM_DEV_DEBUG_KMS(ctx->dev, "failed to allocate edid\n");
return -ENOMEM;
}
 
@@ -344,7 +344,7 @@ static int vidi_create_connector(struct drm_encoder 
*encoder)
ret = drm_connector_init(ctx->drm_dev, connector,
&vidi_connector_funcs, DRM_MODE_CONNECTOR_VIRTUAL);
if (ret) {
-   DRM_DEV_ERROR(ctx->drm_dev->dev,
+   DRM_DEV_ERROR(ctx->dev,
  "Failed to initialize connector with drm\n");
return ret;
}
@@ -448,13 +448,14 @@ static const struct component_ops vidi_component_ops = {
 static int vidi_probe(struct platform_device *pdev)
 {
struct vidi_context *ctx;
+   struct device *dev = &pdev->dev;
int ret;
 
-   ctx = devm_kzalloc(&pdev->dev, sizeof(*ctx), GFP_KERNEL);
+   ctx = devm_kzalloc(dev, sizeof(*ctx), GFP_KERNEL);
if (!ctx)
return -ENOMEM;
 
-   ctx->pdev = pdev;
+   ctx->dev = dev;
 
timer_setu

[PATCH 3/6] drm/exynos: use DRM_DEV_ERROR to print out error message

2019-04-15 Thread Inki Dae
This patch just cleans up the use of error log macro, which changes
the log macro to DRM_DEV_ERROR.

Signed-off-by: Inki Dae 
---
 drivers/gpu/drm/exynos/exynos5433_drm_decon.c |  2 +-
 drivers/gpu/drm/exynos/exynos7_drm_decon.c| 14 +---
 drivers/gpu/drm/exynos/exynos_dp.c|  9 +++--
 drivers/gpu/drm/exynos/exynos_drm_dma.c   |  2 +-
 drivers/gpu/drm/exynos/exynos_drm_dpi.c   |  9 +++--
 drivers/gpu/drm/exynos/exynos_drm_dsi.c   |  7 ++--
 drivers/gpu/drm/exynos/exynos_drm_fb.c|  9 +++--
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 19 +++
 drivers/gpu/drm/exynos/exynos_drm_fimc.c  |  7 ++--
 drivers/gpu/drm/exynos/exynos_drm_fimd.c  | 27 ++-
 drivers/gpu/drm/exynos/exynos_drm_g2d.c   | 49 +++
 drivers/gpu/drm/exynos/exynos_drm_gem.c   | 17 +-
 drivers/gpu/drm/exynos/exynos_drm_gsc.c   | 19 ++-
 drivers/gpu/drm/exynos/exynos_drm_mic.c   | 25 --
 drivers/gpu/drm/exynos/exynos_drm_plane.c |  5 +--
 drivers/gpu/drm/exynos/exynos_drm_vidi.c  | 11 +++---
 drivers/gpu/drm/exynos/exynos_hdmi.c  | 42 +--
 drivers/gpu/drm/exynos/exynos_mixer.c | 26 +-
 18 files changed, 179 insertions(+), 120 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c 
b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
index ba52180..c2715e5 100644
--- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
@@ -188,7 +188,7 @@ static void decon_setup_trigger(struct decon_context *ctx)
 
if (regmap_update_bits(ctx->sysreg, DSD_CFG_MUX,
   DSD_CFG_MUX_TE_UNMASK_GLOBAL, ~0))
-   DRM_ERROR("Cannot update sysreg.\n");
+   DRM_DEV_ERROR(ctx->dev, "Cannot update sysreg.\n");
 }
 
 static void decon_commit(struct exynos_drm_crtc *crtc)
diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c 
b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
index a6bb411..bc76f27 100644
--- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
@@ -620,7 +620,7 @@ static int decon_bind(struct device *dev, struct device 
*master, void *data)
 
ret = decon_ctx_initialize(ctx, drm_dev);
if (ret) {
-   DRM_ERROR("decon_ctx_initialize failed.\n");
+   DRM_DEV_ERROR(dev, "decon_ctx_initialize failed.\n");
return ret;
}
 
@@ -800,25 +800,29 @@ static int exynos7_decon_resume(struct device *dev)
 
ret = clk_prepare_enable(ctx->pclk);
if (ret < 0) {
-   DRM_ERROR("Failed to prepare_enable the pclk [%d]\n", ret);
+   DRM_DEV_ERROR(dev, "Failed to prepare_enable the pclk [%d]\n",
+ ret);
return ret;
}
 
ret = clk_prepare_enable(ctx->aclk);
if (ret < 0) {
-   DRM_ERROR("Failed to prepare_enable the aclk [%d]\n", ret);
+   DRM_DEV_ERROR(dev, "Failed to prepare_enable the aclk [%d]\n",
+ ret);
return ret;
}
 
ret = clk_prepare_enable(ctx->eclk);
if  (ret < 0) {
-   DRM_ERROR("Failed to prepare_enable the eclk [%d]\n", ret);
+   DRM_DEV_ERROR(dev, "Failed to prepare_enable the eclk [%d]\n",
+ ret);
return ret;
}
 
ret = clk_prepare_enable(ctx->vclk);
if  (ret < 0) {
-   DRM_ERROR("Failed to prepare_enable the vclk [%d]\n", ret);
+   DRM_DEV_ERROR(dev, "Failed to prepare_enable the vclk [%d]\n",
+ ret);
return ret;
}
 
diff --git a/drivers/gpu/drm/exynos/exynos_dp.c 
b/drivers/gpu/drm/exynos/exynos_dp.c
index 471242a..b0288cf 100644
--- a/drivers/gpu/drm/exynos/exynos_dp.c
+++ b/drivers/gpu/drm/exynos/exynos_dp.c
@@ -83,7 +83,8 @@ static int exynos_dp_get_modes(struct analogix_dp_plat_data 
*plat_data,
 
mode = drm_mode_create(connector->dev);
if (!mode) {
-   DRM_ERROR("failed to create a new display mode.\n");
+   DRM_DEV_ERROR(dp->dev,
+ "failed to create a new display mode.\n");
return num_modes;
}
 
@@ -111,7 +112,8 @@ static int exynos_dp_bridge_attach(struct 
analogix_dp_plat_data *plat_data,
if (dp->ptn_bridge) {
ret = drm_bridge_attach(&dp->encoder, dp->ptn_bridge, bridge);
if (ret) {
-   DRM_ERROR("Failed to attach bridge to drm\n");
+   DRM_DEV_ERROR(dp->dev,
+ "Failed to attach bridge to 

[PATCH 4/6] drm/exynos: use DRM_DEV_DEBUG* instead of DRM_DEBUG macro

2019-04-15 Thread Inki Dae
Use DRM_DEV_DEBUG* instead of DRM_DEBUG macro to print out
debug messages.

This patch just cleans up the use of debug log macro, which changes
the log macro to DRM_DEV_DEBUG*.

Signed-off-by: Inki Dae 
---
 drivers/gpu/drm/exynos/exynos5433_drm_decon.c |  2 +-
 drivers/gpu/drm/exynos/exynos7_drm_decon.c| 10 ++--
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c |  7 ++-
 drivers/gpu/drm/exynos/exynos_drm_fimc.c  | 85 ++-
 drivers/gpu/drm/exynos/exynos_drm_fimd.c  | 19 +++---
 drivers/gpu/drm/exynos/exynos_drm_gem.c   | 18 +++---
 drivers/gpu/drm/exynos/exynos_drm_gsc.c   | 48 +++
 drivers/gpu/drm/exynos/exynos_drm_ipp.c   | 61 ---
 drivers/gpu/drm/exynos/exynos_drm_mic.c   |  4 +-
 drivers/gpu/drm/exynos/exynos_drm_plane.c | 10 ++--
 drivers/gpu/drm/exynos/exynos_drm_vidi.c  | 25 
 drivers/gpu/drm/exynos/exynos_hdmi.c  | 33 +++
 drivers/gpu/drm/exynos/exynos_mixer.c | 17 +++---
 13 files changed, 191 insertions(+), 148 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c 
b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
index c2715e5..73b318a 100644
--- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
@@ -356,7 +356,7 @@ static void decon_win_set_pixfmt(struct decon_context *ctx, 
unsigned int win,
break;
}
 
-   DRM_DEBUG_KMS("cpp = %u\n", fb->format->cpp[0]);
+   DRM_DEV_DEBUG_KMS(ctx->dev, "cpp = %u\n", fb->format->cpp[0]);
 
/*
 * In case of exynos, setting dma-burst to 16Word causes permanent
diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c 
b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
index bc76f27..0217ee9 100644
--- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
@@ -99,7 +99,7 @@ static void decon_wait_for_vblank(struct exynos_drm_crtc 
*crtc)
if (!wait_event_timeout(ctx->wait_vsync_queue,
!atomic_read(&ctx->wait_vsync_event),
HZ/20))
-   DRM_DEBUG_KMS("vblank wait timed out.\n");
+   DRM_DEV_DEBUG_KMS(ctx->dev, "vblank wait timed out.\n");
 }
 
 static void decon_clear_channels(struct exynos_drm_crtc *crtc)
@@ -313,7 +313,7 @@ static void decon_win_set_pixfmt(struct decon_context *ctx, 
unsigned int win,
break;
}
 
-   DRM_DEBUG_KMS("cpp = %d\n", fb->format->cpp[0]);
+   DRM_DEV_DEBUG_KMS(ctx->dev, "cpp = %d\n", fb->format->cpp[0]);
 
/*
 * In case of exynos, setting dma-burst to 16Word causes permanent
@@ -420,9 +420,9 @@ static void decon_update_plane(struct exynos_drm_crtc *crtc,
writel(state->src.x, ctx->regs + VIDW_OFFSET_X(win));
writel(state->src.y, ctx->regs + VIDW_OFFSET_Y(win));
 
-   DRM_DEBUG_KMS("start addr = 0x%lx\n",
+   DRM_DEV_DEBUG_KMS(ctx->dev, "start addr = 0x%lx\n",
(unsigned long)val);
-   DRM_DEBUG_KMS("ovl_width = %d, ovl_height = %d\n",
+   DRM_DEV_DEBUG_KMS(ctx->dev, "ovl_width = %d, ovl_height = %d\n",
state->crtc.w, state->crtc.h);
 
val = VIDOSDxA_TOPLEFT_X(state->crtc.x) |
@@ -440,7 +440,7 @@ static void decon_update_plane(struct exynos_drm_crtc *crtc,
 
writel(val, ctx->regs + VIDOSD_B(win));
 
-   DRM_DEBUG_KMS("osd pos: tx = %d, ty = %d, bx = %d, by = %d\n",
+   DRM_DEV_DEBUG_KMS(ctx->dev, "osd pos: tx = %d, ty = %d, bx = %d, by = 
%d\n",
state->crtc.x, state->crtc.y, last_x, last_y);
 
/* OSD alpha */
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c 
b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
index 3fb9e83..1186e9c 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
@@ -124,9 +124,10 @@ static int exynos_drm_fbdev_create(struct drm_fb_helper 
*helper,
unsigned long size;
int ret;
 
-   DRM_DEBUG_KMS("surface width(%d), height(%d) and bpp(%d\n",
-   sizes->surface_width, sizes->surface_height,
-   sizes->surface_bpp);
+   DRM_DEV_DEBUG_KMS(dev->dev,
+ "surface width(%d), height(%d) and bpp(%d\n",
+ sizes->surface_width, sizes->surface_height,
+ sizes->surface_bpp);
 
mode_cmd.width = sizes->surface_width;
mode_cmd.height = sizes->surface_height;
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimc.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
index 5a5641b..71b0cb1 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
+++ b/drivers/gpu/drm/exynos/e

[PATCH 6/6] drm/exynos: ipp: clean up debug messages

2019-04-15 Thread Inki Dae
Print out debug messages with correct device name.

As for this, this patch adds device pointer to exynos_drm_ipp structure,
and in case of exynos_drm_ipp_task structure, replace drm_device pointer
with device one. This will make each ipp driver to print out debug
messages with correct device name.

Signed-off-by: Inki Dae 
---
 drivers/gpu/drm/exynos/exynos_drm_fimc.c|  5 ++--
 drivers/gpu/drm/exynos/exynos_drm_gsc.c |  5 ++--
 drivers/gpu/drm/exynos/exynos_drm_ipp.c | 46 ++---
 drivers/gpu/drm/exynos/exynos_drm_ipp.h |  9 +++---
 drivers/gpu/drm/exynos/exynos_drm_rotator.c |  5 ++--
 drivers/gpu/drm/exynos/exynos_drm_scaler.c  |  5 ++--
 6 files changed, 40 insertions(+), 35 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimc.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
index 71b0cb1..c50b0f9 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
@@ -1134,9 +1134,10 @@ static int fimc_bind(struct device *dev, struct device 
*master, void *data)
struct exynos_drm_ipp *ipp = &ctx->ipp;
 
ctx->drm_dev = drm_dev;
+   ipp->drm_dev = drm_dev;
exynos_drm_register_dma(drm_dev, dev);
 
-   exynos_drm_ipp_register(drm_dev, ipp, &ipp_funcs,
+   exynos_drm_ipp_register(dev, ipp, &ipp_funcs,
DRM_EXYNOS_IPP_CAP_CROP | DRM_EXYNOS_IPP_CAP_ROTATE |
DRM_EXYNOS_IPP_CAP_SCALE | DRM_EXYNOS_IPP_CAP_CONVERT,
ctx->formats, ctx->num_formats, "fimc");
@@ -1153,7 +1154,7 @@ static void fimc_unbind(struct device *dev, struct device 
*master,
struct drm_device *drm_dev = data;
struct exynos_drm_ipp *ipp = &ctx->ipp;
 
-   exynos_drm_ipp_unregister(drm_dev, ipp);
+   exynos_drm_ipp_unregister(dev, ipp);
exynos_drm_unregister_dma(drm_dev, dev);
 }
 
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gsc.c 
b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
index 433df3e..0bfb5e9 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
@@ -1170,9 +1170,10 @@ static int gsc_bind(struct device *dev, struct device 
*master, void *data)
struct exynos_drm_ipp *ipp = &ctx->ipp;
 
ctx->drm_dev = drm_dev;
+   ctx->drm_dev = drm_dev;
exynos_drm_register_dma(drm_dev, dev);
 
-   exynos_drm_ipp_register(drm_dev, ipp, &ipp_funcs,
+   exynos_drm_ipp_register(dev, ipp, &ipp_funcs,
DRM_EXYNOS_IPP_CAP_CROP | DRM_EXYNOS_IPP_CAP_ROTATE |
DRM_EXYNOS_IPP_CAP_SCALE | DRM_EXYNOS_IPP_CAP_CONVERT,
ctx->formats, ctx->num_formats, "gsc");
@@ -1189,7 +1190,7 @@ static void gsc_unbind(struct device *dev, struct device 
*master,
struct drm_device *drm_dev = data;
struct exynos_drm_ipp *ipp = &ctx->ipp;
 
-   exynos_drm_ipp_unregister(drm_dev, ipp);
+   exynos_drm_ipp_unregister(dev, ipp);
exynos_drm_unregister_dma(drm_dev, dev);
 }
 
diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c 
b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
index a1ee541..c862099 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
@@ -43,7 +43,7 @@ static LIST_HEAD(ipp_list);
  * Returns:
  * Zero on success, error code on failure.
  */
-int exynos_drm_ipp_register(struct drm_device *dev, struct exynos_drm_ipp *ipp,
+int exynos_drm_ipp_register(struct device *dev, struct exynos_drm_ipp *ipp,
const struct exynos_drm_ipp_funcs *funcs, unsigned int caps,
const struct exynos_drm_ipp_formats *formats,
unsigned int num_formats, const char *name)
@@ -67,7 +67,7 @@ int exynos_drm_ipp_register(struct drm_device *dev, struct 
exynos_drm_ipp *ipp,
list_add_tail(&ipp->head, &ipp_list);
ipp->id = num_ipp++;
 
-   DRM_DEV_DEBUG_DRIVER(dev->dev, "Registered ipp %d\n", ipp->id);
+   DRM_DEV_DEBUG_DRIVER(dev, "Registered ipp %d\n", ipp->id);
 
return 0;
 }
@@ -77,7 +77,7 @@ int exynos_drm_ipp_register(struct drm_device *dev, struct 
exynos_drm_ipp *ipp,
  * @dev: DRM device
  * @ipp: ipp module
  */
-void exynos_drm_ipp_unregister(struct drm_device *dev,
+void exynos_drm_ipp_unregister(struct device *dev,
   struct exynos_drm_ipp *ipp)
 {
WARN_ON(ipp->task);
@@ -268,7 +268,7 @@ static inline struct exynos_drm_ipp_task *
task->src.rect.h = task->dst.rect.h = UINT_MAX;
task->transform.rotation = DRM_MODE_ROTATE_0;
 
-   DRM_DEV_DEBUG_DRIVER(ipp->dev->dev, "Allocated task %pK\n", task);
+   DRM_DEV_DEBUG_DRIVER(task->dev, "Allocated task %pK\n", task);
 
return task;
 }
@@ -335,7 +335,7 @@ static int exynos_drm_ipp_task

[GIT PULL] exynos-drm-next

2019-04-22 Thread Inki Dae
Hi Dave,

   Just log cleanup patches of Exynos KMS and DMA drivers
   including one trivial style fixup.

   Please kinkdly let me know if there is any problem.


Thanks,
Inki Dae


The following changes since commit dbb92471674a48892f5e50779425e03388073ab9:

  Revert "drm: allow render capable master with DRM_AUTH ioctls" (2019-04-18 
06:46:33 +1000)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos 
tags/exynos-drm-next-for-v5.2

for you to fetch changes up to 35319804851fad62dfa6284f4e638a7e2a620fe8:

  drm/ipp: clean up debug messages (2019-04-22 12:13:44 +0900)


Log cleanups
- Correct the use of log macro in error case.
- Drop unnecessary messages.
- Replace DRM_ERROR/DEBUG with DRM_DEV_ERROR/DEBUG.
- Print out debug messages with correct device name in vidi and ipp drivers.

One trivial cleanup
- Just fix checkpatch error, "foo* bar" to "foo *bar" in g2d driver.

--------
Inki Dae (6):
  drm/fimd: use DRM_ERROR instead of DRM_INFO in error case
  drm/exynos: remove unnecessary messages
  drm/exynos: use DRM_DEV_ERROR to print out error message
  drm/exynos: use DRM_DEV_DEBUG* instead of DRM_DEBUG macro
  drm/vidi: replace platform_device pointer with device one
  drm/ipp: clean up debug messages

Seung-Woo Kim (1):
  drm/exynos: g2d: remove style error

 drivers/gpu/drm/exynos/exynos5433_drm_decon.c |  6 +-
 drivers/gpu/drm/exynos/exynos7_drm_decon.c| 26 +++
 drivers/gpu/drm/exynos/exynos_dp.c|  9 ++-
 drivers/gpu/drm/exynos/exynos_drm_dma.c   |  2 +-
 drivers/gpu/drm/exynos/exynos_drm_dpi.c   |  9 ++-
 drivers/gpu/drm/exynos/exynos_drm_dsi.c   |  7 +-
 drivers/gpu/drm/exynos/exynos_drm_fb.c|  9 ++-
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 26 ---
 drivers/gpu/drm/exynos/exynos_drm_fimc.c  | 97 ++-
 drivers/gpu/drm/exynos/exynos_drm_fimd.c  | 48 +++--
 drivers/gpu/drm/exynos/exynos_drm_g2d.c   | 51 +++---
 drivers/gpu/drm/exynos/exynos_drm_gem.c   | 35 +-
 drivers/gpu/drm/exynos/exynos_drm_gsc.c   | 72 ++--
 drivers/gpu/drm/exynos/exynos_drm_ipp.c   | 71 
 drivers/gpu/drm/exynos/exynos_drm_ipp.h   |  9 +--
 drivers/gpu/drm/exynos/exynos_drm_mic.c   | 29 
 drivers/gpu/drm/exynos/exynos_drm_plane.c | 15 +++--
 drivers/gpu/drm/exynos/exynos_drm_rotator.c   |  5 +-
 drivers/gpu/drm/exynos/exynos_drm_scaler.c|  5 +-
 drivers/gpu/drm/exynos/exynos_drm_vidi.c  | 49 --
 drivers/gpu/drm/exynos/exynos_hdmi.c  | 75 -
 drivers/gpu/drm/exynos/exynos_mixer.c | 43 +++-
 22 files changed, 400 insertions(+), 298 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [GIT PULL] exynos-drm-next

2019-04-23 Thread Inki Dae
Hi Dave,

19. 4. 24. 오전 11:03에 Dave Airlie 이(가) 쓴 글:
> Hi Inki,
>   CC [M]  drivers/gpu/drm/exynos/exynos_drm_scaler.o
> /home/airlied/devel/kernel/dim/src/drivers/gpu/drm/exynos/exynos_drm_rotator.c:
> In function ‘rotator_unbind’:
> /home/airlied/devel/kernel/dim/src/drivers/gpu/drm/exynos/exynos_drm_rotator.c:262:21:
> warning: unused variable ‘drm_dev’ [-Wunused-variable]
>   struct drm_device *drm_dev = data;
>  ^~~
> /home/airlied/devel/kernel/dim/src/drivers/gpu/drm/exynos/exynos_drm_scaler.c:
> In function ‘scaler_unbind’:
> /home/airlied/devel/kernel/dim/src/drivers/gpu/drm/exynos/exynos_drm_scaler.c:472:21:
> warning: unused variable ‘drm_dev’ [-Wunused-variable]
>   struct drm_device *drm_dev = data;
>  ^~~
>   LD [M]  drivers/gpu/drm/exynos/exynosdrm.o
> 
> are those new? please fix and resent the pull
> 

Sorry for this. I missed to remove them with some cleanup. Will resend the pull.

Thanks,
Inki Dae

> Dave.
> 
> On Mon, 22 Apr 2019 at 19:50, Inki Dae  wrote:
>>
>> Hi Dave,
>>
>>Just log cleanup patches of Exynos KMS and DMA drivers
>>including one trivial style fixup.
>>
>>Please kinkdly let me know if there is any problem.
>>
>>
>> Thanks,
>> Inki Dae
>>
>>
>> The following changes since commit dbb92471674a48892f5e50779425e03388073ab9:
>>
>>   Revert "drm: allow render capable master with DRM_AUTH ioctls" (2019-04-18 
>> 06:46:33 +1000)
>>
>> are available in the git repository at:
>>
>>   git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos 
>> tags/exynos-drm-next-for-v5.2
>>
>> for you to fetch changes up to 35319804851fad62dfa6284f4e638a7e2a620fe8:
>>
>>   drm/ipp: clean up debug messages (2019-04-22 12:13:44 +0900)
>>
>> 
>> Log cleanups
>> - Correct the use of log macro in error case.
>> - Drop unnecessary messages.
>> - Replace DRM_ERROR/DEBUG with DRM_DEV_ERROR/DEBUG.
>> - Print out debug messages with correct device name in vidi and ipp drivers.
>>
>> One trivial cleanup
>> - Just fix checkpatch error, "foo* bar" to "foo *bar" in g2d driver.
>>
>> 
>> Inki Dae (6):
>>   drm/fimd: use DRM_ERROR instead of DRM_INFO in error case
>>   drm/exynos: remove unnecessary messages
>>   drm/exynos: use DRM_DEV_ERROR to print out error message
>>   drm/exynos: use DRM_DEV_DEBUG* instead of DRM_DEBUG macro
>>   drm/vidi: replace platform_device pointer with device one
>>   drm/ipp: clean up debug messages
>>
>> Seung-Woo Kim (1):
>>   drm/exynos: g2d: remove style error
>>
>>  drivers/gpu/drm/exynos/exynos5433_drm_decon.c |  6 +-
>>  drivers/gpu/drm/exynos/exynos7_drm_decon.c| 26 +++
>>  drivers/gpu/drm/exynos/exynos_dp.c|  9 ++-
>>  drivers/gpu/drm/exynos/exynos_drm_dma.c   |  2 +-
>>  drivers/gpu/drm/exynos/exynos_drm_dpi.c   |  9 ++-
>>  drivers/gpu/drm/exynos/exynos_drm_dsi.c   |  7 +-
>>  drivers/gpu/drm/exynos/exynos_drm_fb.c|  9 ++-
>>  drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 26 ---
>>  drivers/gpu/drm/exynos/exynos_drm_fimc.c  | 97 
>> ++-
>>  drivers/gpu/drm/exynos/exynos_drm_fimd.c  | 48 +++--
>>  drivers/gpu/drm/exynos/exynos_drm_g2d.c   | 51 +++---
>>  drivers/gpu/drm/exynos/exynos_drm_gem.c   | 35 +-
>>  drivers/gpu/drm/exynos/exynos_drm_gsc.c   | 72 ++--
>>  drivers/gpu/drm/exynos/exynos_drm_ipp.c   | 71 
>>  drivers/gpu/drm/exynos/exynos_drm_ipp.h   |  9 +--
>>  drivers/gpu/drm/exynos/exynos_drm_mic.c   | 29 
>>  drivers/gpu/drm/exynos/exynos_drm_plane.c | 15 +++--
>>  drivers/gpu/drm/exynos/exynos_drm_rotator.c   |  5 +-
>>  drivers/gpu/drm/exynos/exynos_drm_scaler.c|  5 +-
>>  drivers/gpu/drm/exynos/exynos_drm_vidi.c  | 49 --
>>  drivers/gpu/drm/exynos/exynos_hdmi.c  | 75 -
>>  drivers/gpu/drm/exynos/exynos_mixer.c | 43 +++-
>>  22 files changed, 400 insertions(+), 298 deletions(-)
>> ___
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[GIT PULL RESEND] exynos-drm-next

2019-04-23 Thread Inki Dae
Hi Dave,

   Just log cleanups patches of Exynos KMS and DMA drivers
   including one trivial style fixup.

  Please kindly let me know if there is any problem.

Resend changelog:
- Fixed two build warnings by removing unused variables,
  and confirmed no build warning messages.
- Rebased on top of drm-next again.

Thanks,
Inki Dae

The following changes since commit 70b5f09e4389c789263c6d79c539b8378e3af3bc:

  Merge tag 'drm-msm-next-2019-04-21' of https://gitlab.freedesktop.org/drm/msm 
into drm-next (2019-04-24 11:56:32 +1000)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos 
tags/exynos-drm-next-for-v5.2

for you to fetch changes up to 8b9550344d3914cf606f365b6fa4279fb3cd4684:

  drm/ipp: clean up debug messages (2019-04-24 11:23:20 +0900)


Log cleanups
- Correct the use of log macro in error case.
- Drop unnecessary messages.
- Replace DRM_ERROR/DEBUG with DRM_DEV_ERROR/DEBUG.
- Print out debug messages with correct device name in vidi and ipp drivers.

One trivial cleanup
- Just fix checkpatch error, "foo* bar" to "foo *bar" in g2d driver.

--------
Inki Dae (6):
  drm/fimd: use DRM_ERROR instead of DRM_INFO in error case
  drm/exynos: remove unnecessary messages
  drm/exynos: use DRM_DEV_ERROR to print out error message
  drm/exynos: use DRM_DEV_DEBUG* instead of DRM_DEBUG macro
  drm/vidi: replace platform_device pointer with device one
  drm/ipp: clean up debug messages

Seung-Woo Kim (1):
  drm/exynos: g2d: remove style error

 drivers/gpu/drm/exynos/exynos5433_drm_decon.c |  6 +-
 drivers/gpu/drm/exynos/exynos7_drm_decon.c| 26 +++
 drivers/gpu/drm/exynos/exynos_dp.c|  9 ++-
 drivers/gpu/drm/exynos/exynos_drm_dma.c   |  2 +-
 drivers/gpu/drm/exynos/exynos_drm_dpi.c   |  9 ++-
 drivers/gpu/drm/exynos/exynos_drm_dsi.c   |  7 +-
 drivers/gpu/drm/exynos/exynos_drm_fb.c|  9 ++-
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 26 ---
 drivers/gpu/drm/exynos/exynos_drm_fimc.c  | 97 ++-
 drivers/gpu/drm/exynos/exynos_drm_fimd.c  | 48 +++--
 drivers/gpu/drm/exynos/exynos_drm_g2d.c   | 51 +++---
 drivers/gpu/drm/exynos/exynos_drm_gem.c   | 35 +-
 drivers/gpu/drm/exynos/exynos_drm_gsc.c   | 72 ++--
 drivers/gpu/drm/exynos/exynos_drm_ipp.c   | 71 
 drivers/gpu/drm/exynos/exynos_drm_ipp.h   |  9 +--
 drivers/gpu/drm/exynos/exynos_drm_mic.c   | 29 
 drivers/gpu/drm/exynos/exynos_drm_plane.c | 15 +++--
 drivers/gpu/drm/exynos/exynos_drm_rotator.c   |  6 +-
 drivers/gpu/drm/exynos/exynos_drm_scaler.c|  6 +-
 drivers/gpu/drm/exynos/exynos_drm_vidi.c  | 49 --
 drivers/gpu/drm/exynos/exynos_hdmi.c  | 75 -
 drivers/gpu/drm/exynos/exynos_mixer.c | 43 +++-
 22 files changed, 400 insertions(+), 300 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[GIT PULL] exynos-drm-next

2019-02-07 Thread Inki Dae
Hi Dave,

   Just adding s5pv210 SoC support of rotator module and changing
   email address of scaler module author.

   Please kindly let me know if there is any problem.

Thanks,
Inki Dae

The following changes since commit 2cc3b81dfa7f7de0d647e7f1473de811eef8b0de:

  Merge tag 'drm-intel-next-2019-02-02' of 
git://anongit.freedesktop.org/drm/drm-intel into drm-next (2019-02-04 15:37:58 
+1000)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos 
tags/exynos-drm-next-for-v5.1

for you to fetch changes up to 9c0c4997b8a80ec4ba77c4ebe3e74ec0db2d547d:

  drm/exynos: Change Andrzej Pietrasiewicz's e-mail address (2019-02-07 
19:59:44 +0900)


- Add rotator support for s5pv210
  . With this patch series, s5pv210 SoC can use rotator module but
only NV12 and XRGB formats are supported.
- Modify e-mail address
  . It changes email address of scaler module author.


Andrzej Pietrasiewicz (1):
  drm/exynos: Change Andrzej Pietrasiewicz's e-mail address

Paweł Chmiel (2):
  drm/exynos: rotator: Add support for s5pv210
  dt-bindings: gpu: samsung-rotator: Document s5pv210 support

 .../devicetree/bindings/gpu/samsung-rotator.txt|  7 ---
 drivers/gpu/drm/exynos/exynos_drm_rotator.c| 23 ++
 drivers/gpu/drm/exynos/exynos_drm_scaler.c |  2 +-
 drivers/gpu/drm/exynos/regs-scaler.h   |  2 +-
 4 files changed, 29 insertions(+), 5 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 1/3] drm/exynos: rotator: Add support for s5pv210

2019-01-08 Thread Inki Dae


18. 12. 20. 오전 12:57에 Paweł Chmiel 이(가) 쓴 글:
> This commit adds support for s5pv210.
> Currently only NV12 and XRGB formats are supported.
> It was tested by using tool from
> https://www.spinics.net/lists/linux-samsung-soc/msg60498.html
> 
> Signed-off-by: Paweł Chmiel 
Applied.

Thanks,
Inki Dae

> ---
>  drivers/gpu/drm/exynos/exynos_drm_rotator.c | 23 +
>  1 file changed, 23 insertions(+)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_rotator.c 
> b/drivers/gpu/drm/exynos/exynos_drm_rotator.c
> index a820a68429b9..a822d340ccf6 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_rotator.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_rotator.c
> @@ -357,6 +357,11 @@ static int rotator_runtime_resume(struct device *dev)
>  }
>  #endif
>  
> +static const struct drm_exynos_ipp_limit rotator_s5pv210_rbg888_limits[] = {
> + { IPP_SIZE_LIMIT(BUFFER, .h = { 8, SZ_16K }, .v = { 8, SZ_16K }) },
> + { IPP_SIZE_LIMIT(AREA, .h.align = 2, .v.align = 2) },
> +};
> +
>  static const struct drm_exynos_ipp_limit rotator_4210_rbg888_limits[] = {
>   { IPP_SIZE_LIMIT(BUFFER, .h = { 8, SZ_16K }, .v = { 8, SZ_16K }) },
>   { IPP_SIZE_LIMIT(AREA, .h.align = 4, .v.align = 4) },
> @@ -372,6 +377,11 @@ static const struct drm_exynos_ipp_limit 
> rotator_5250_rbg888_limits[] = {
>   { IPP_SIZE_LIMIT(AREA, .h.align = 2, .v.align = 2) },
>  };
>  
> +static const struct drm_exynos_ipp_limit rotator_s5pv210_yuv_limits[] = {
> + { IPP_SIZE_LIMIT(BUFFER, .h = { 32, SZ_64K }, .v = { 32, SZ_64K }) },
> + { IPP_SIZE_LIMIT(AREA, .h.align = 8, .v.align = 8) },
> +};
> +
>  static const struct drm_exynos_ipp_limit rotator_4210_yuv_limits[] = {
>   { IPP_SIZE_LIMIT(BUFFER, .h = { 32, SZ_64K }, .v = { 32, SZ_64K }) },
>   { IPP_SIZE_LIMIT(AREA, .h.align = 8, .v.align = 8) },
> @@ -382,6 +392,11 @@ static const struct drm_exynos_ipp_limit 
> rotator_4412_yuv_limits[] = {
>   { IPP_SIZE_LIMIT(AREA, .h.align = 8, .v.align = 8) },
>  };
>  
> +static const struct exynos_drm_ipp_formats rotator_s5pv210_formats[] = {
> + { IPP_SRCDST_FORMAT(XRGB, rotator_s5pv210_rbg888_limits) },
> + { IPP_SRCDST_FORMAT(NV12, rotator_s5pv210_yuv_limits) },
> +};
> +
>  static const struct exynos_drm_ipp_formats rotator_4210_formats[] = {
>   { IPP_SRCDST_FORMAT(XRGB, rotator_4210_rbg888_limits) },
>   { IPP_SRCDST_FORMAT(NV12, rotator_4210_yuv_limits) },
> @@ -397,6 +412,11 @@ static const struct exynos_drm_ipp_formats 
> rotator_5250_formats[] = {
>   { IPP_SRCDST_FORMAT(NV12, rotator_4412_yuv_limits) },
>  };
>  
> +static const struct rot_variant rotator_s5pv210_data = {
> + .formats = rotator_s5pv210_formats,
> + .num_formats = ARRAY_SIZE(rotator_s5pv210_formats),
> +};
> +
>  static const struct rot_variant rotator_4210_data = {
>   .formats = rotator_4210_formats,
>   .num_formats = ARRAY_SIZE(rotator_4210_formats),
> @@ -414,6 +434,9 @@ static const struct rot_variant rotator_5250_data = {
>  
>  static const struct of_device_id exynos_rotator_match[] = {
>   {
> + .compatible = "samsung,s5pv210-rotator",
> + .data = &rotator_s5pv210_data,
> + }, {
>   .compatible = "samsung,exynos4210-rotator",
>   .data = &rotator_4210_data,
>   }, {
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 1/6] include/drm: color_mgmt: Add enum labels

2019-01-17 Thread Inki Dae
Hi,

18. 12. 14. 오후 9:10에 Christoph Manszewski 이(가) 쓴 글:
> Range setting makes sense for YCbCr and RGB buffers. Current
> drm_color_range enum labels suggest use with YCbCr buffers.
> Create enum labels without colorspace specification.
> 
> Signed-off-by: Christoph Manszewski 
> ---
>  include/drm/drm_color_mgmt.h | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/include/drm/drm_color_mgmt.h b/include/drm/drm_color_mgmt.h
> index 90ef9996d9a4..52f6d5221a0d 100644
> --- a/include/drm/drm_color_mgmt.h
> +++ b/include/drm/drm_color_mgmt.h
> @@ -62,6 +62,8 @@ enum drm_color_range {
>   DRM_COLOR_YCBCR_LIMITED_RANGE,
>   DRM_COLOR_YCBCR_FULL_RANGE,
>   DRM_COLOR_RANGE_MAX,
> + DRM_COLOR_LIMITED_RANGE = DRM_COLOR_YCBCR_LIMITED_RANGE,
> + DRM_COLOR_FULL_RANGE = DRM_COLOR_YCBCR_FULL_RANGE,

I don't see why above two types are needed. Is there any case that the range 
checking behavior should be different according to the color space?
And even if there is that case, I think you have to put DRM_COLOR_RANG_MAX 
under DRM_COLOR_FULL_RANGE.

Thanks,
Inki Dae

>  };
>  
>  int drm_plane_create_color_properties(struct drm_plane *plane,
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v1 1/1] drm/exynos: drop drmP.h usage

2019-06-21 Thread Inki Dae
Hi,

19. 6. 5. 오후 11:49에 Sam Ravnborg 이(가) 쓴 글:
> Drop use of the deprecated drmP.h file.
> Replace with forwards / externals as appropriate.
> 
> While touching the list of include files divide
> them up in blocks and sort them.

Build error happens with this patch.

[error log]

drivers/gpu/drm/exynos/exynos_drm_g2d.c:196:27: error: field 'base' has 
incomplete type
  struct drm_pending_event base;
   ^
drivers/gpu/drm/exynos/exynos_drm_g2d.c: In function 
'g2d_userptr_get_dma_addr':
drivers/gpu/drm/exynos/exynos_drm_g2d.c:421:50: error: dereferencing 
pointer to incomplete type
  struct drm_exynos_file_private *file_priv = filp->driver_priv;
-- snip --
----

Thanks,
Inki Dae

> 
> Signed-off-by: Sam Ravnborg 
> Cc: Inki Dae 
> Cc: Joonyoung Shim 
> Cc: Seung-Woo Kim 
> Cc: Kyungmin Park 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: Kukjin Kim 
> Cc: Krzysztof Kozlowski 
> Cc: Jingoo Han 
> ---
>  drivers/gpu/drm/exynos/exynos5433_drm_decon.c |  7 +++-
>  drivers/gpu/drm/exynos/exynos7_drm_decon.c|  8 ++--
>  drivers/gpu/drm/exynos/exynos_dp.c| 13 +++---
>  drivers/gpu/drm/exynos/exynos_drm_crtc.c  |  2 +-
>  drivers/gpu/drm/exynos/exynos_drm_dma.c   |  6 ++-
>  drivers/gpu/drm/exynos/exynos_drm_dpi.c   |  8 ++--
>  drivers/gpu/drm/exynos/exynos_drm_drv.c   | 12 +++---
>  drivers/gpu/drm/exynos/exynos_drm_drv.h   |  8 +++-
>  drivers/gpu/drm/exynos/exynos_drm_dsi.c   | 21 +-
>  drivers/gpu/drm/exynos/exynos_drm_fb.c|  6 +--
>  drivers/gpu/drm/exynos/exynos_drm_fbdev.c |  7 ++--
>  drivers/gpu/drm/exynos/exynos_drm_fimc.c  | 15 +++
>  drivers/gpu/drm/exynos/exynos_drm_fimd.c  | 14 ---
>  drivers/gpu/drm/exynos/exynos_drm_g2d.c   |  8 ++--
>  drivers/gpu/drm/exynos/exynos_drm_gem.c   |  7 ++--
>  drivers/gpu/drm/exynos/exynos_drm_gsc.c   | 13 +++---
>  drivers/gpu/drm/exynos/exynos_drm_ipp.c   |  3 +-
>  drivers/gpu/drm/exynos/exynos_drm_mic.c   | 22 +-
>  drivers/gpu/drm/exynos/exynos_drm_plane.c |  4 +-
>  drivers/gpu/drm/exynos/exynos_drm_rotator.c   | 10 ++---
>  drivers/gpu/drm/exynos/exynos_drm_scaler.c| 12 +++---
>  drivers/gpu/drm/exynos/exynos_drm_vidi.c  |  9 ++--
>  drivers/gpu/drm/exynos/exynos_hdmi.c  | 41 +--
>  drivers/gpu/drm/exynos/exynos_mixer.c | 31 +++---
>  24 files changed, 151 insertions(+), 136 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c 
> b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> index 73b318a7ef49..40423e237b82 100644
> --- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> +++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> @@ -10,7 +10,6 @@
>   * published by the Free Software Foundationr
>   */
>  
> -#include 
>  #include 
>  #include 
>  #include 
> @@ -18,11 +17,15 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  
> -#include "exynos_drm_drv.h"
> +#include 
> +#include 
> +
>  #include "exynos_drm_crtc.h"
> +#include "exynos_drm_drv.h"
>  #include "exynos_drm_fb.h"
>  #include "exynos_drm_plane.h"
>  #include "regs-decon5433.h"
> diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c 
> b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
> index 0217ee9a118d..98c2debdd053 100644
> --- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
> +++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
> @@ -11,8 +11,6 @@
>   * option) any later version.
>   *
>   */
> -#include 
> -#include 
>  
>  #include 
>  #include 
> @@ -26,10 +24,14 @@
>  #include 
>  #include 
>  
> +#include 
> +#include 
> +#include 
> +
>  #include "exynos_drm_crtc.h"
> -#include "exynos_drm_plane.h"
>  #include "exynos_drm_drv.h"
>  #include "exynos_drm_fb.h"
> +#include "exynos_drm_plane.h"
>  #include "regs-decon7.h"
>  
>  /*
> diff --git a/drivers/gpu/drm/exynos/exynos_dp.c 
> b/drivers/gpu/drm/exynos/exynos_dp.c
> index b0288cf85701..882275e475c9 100644
> --- a/drivers/gpu/drm/exynos/exynos_dp.c
> +++ b/drivers/gpu/drm/exynos/exynos_dp.c
> @@ -10,25 +10,24 @@
>   * option) any later version.
>   */
>  
> -#include 
> -#include 
> -#include 
>  #include 
> -#include 
>  #include 
> +#include 
> +#include 
> +#in

Re: [PATCH v2 1/1] drm/exynos: drop drmP.h usage

2019-06-21 Thread Inki Dae
HI,

2019년 6월 8일 (토) 오후 5:35, Sam Ravnborg 님이 작성:
>
> Drop use of the deprecated drmP.h file.
> Replace with forwards / externals as appropriate.
>
> While touching the list of include files divide
> them up in blocks and sort them.
>
> Signed-off-by: Sam Ravnborg 
> Cc: Inki Dae 
> Cc: Joonyoung Shim 
> Cc: Seung-Woo Kim 
> Cc: Kyungmin Park 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: Kukjin Kim 
> Cc: Krzysztof Kozlowski 
> Cc: Jingoo Han 
> ---
>  drivers/gpu/drm/exynos/exynos5433_drm_decon.c |  7 +++-
>  drivers/gpu/drm/exynos/exynos7_drm_decon.c|  8 ++--
>  drivers/gpu/drm/exynos/exynos_dp.c| 13 +++---
>  drivers/gpu/drm/exynos/exynos_drm_crtc.c  |  2 +-
>  drivers/gpu/drm/exynos/exynos_drm_dma.c   |  6 ++-
>  drivers/gpu/drm/exynos/exynos_drm_dpi.c   |  8 ++--
>  drivers/gpu/drm/exynos/exynos_drm_drv.c   | 12 +++---
>  drivers/gpu/drm/exynos/exynos_drm_drv.h   |  8 +++-
>  drivers/gpu/drm/exynos/exynos_drm_dsi.c   | 21 +-
>  drivers/gpu/drm/exynos/exynos_drm_fb.c|  6 +--
>  drivers/gpu/drm/exynos/exynos_drm_fbdev.c |  7 ++--
>  drivers/gpu/drm/exynos/exynos_drm_fimc.c  | 15 +++
>  drivers/gpu/drm/exynos/exynos_drm_fimd.c  | 14 ---
>  drivers/gpu/drm/exynos/exynos_drm_g2d.c   |  8 ++--
>  drivers/gpu/drm/exynos/exynos_drm_gem.c   |  7 ++--
>  drivers/gpu/drm/exynos/exynos_drm_gsc.c   | 13 +++---
>  drivers/gpu/drm/exynos/exynos_drm_ipp.c   |  3 +-
>  drivers/gpu/drm/exynos/exynos_drm_mic.c   | 22 +-
>  drivers/gpu/drm/exynos/exynos_drm_plane.c |  4 +-
>  drivers/gpu/drm/exynos/exynos_drm_rotator.c   | 10 ++---
>  drivers/gpu/drm/exynos/exynos_drm_scaler.c| 12 +++---
>  drivers/gpu/drm/exynos/exynos_drm_vidi.c  |  9 ++--
>  drivers/gpu/drm/exynos/exynos_hdmi.c  | 41 +--
>  drivers/gpu/drm/exynos/exynos_mixer.c | 31 +++---
>  24 files changed, 151 insertions(+), 136 deletions(-)
>
--- snip ---
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c 
> b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
> index c20b3a759370..ff9342737a51 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
> @@ -7,21 +7,21 @@
>   * published by the Free Software Foundationr
>   */
>
> -#include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>  #include 
>  #include 
>  #include 
>  #include 
> -#include 
> -#include 
>
> -#include 
>  #include 
> +

With this patch, many build errors happen.

Seems you missed to include below header files,





Thanks,
Inki Dae

[Error log]
--
drivers/gpu/drm/exynos/exynos_drm_g2d.c:196:27: error: field ‘base’
has incomplete type
  struct drm_pending_event base;
   ^~~~
drivers/gpu/drm/exynos/exynos_drm_g2d.c: In function ‘g2d_userptr_get_dma_addr’:
drivers/gpu/drm/exynos/exynos_drm_g2d.c:421:50: error: dereferencing
pointer to incomplete type ‘struct drm_file’
  struct drm_exynos_file_private *file_priv = filp->driver_priv;
  ^~
drivers/gpu/drm/exynos/exynos_drm_g2d.c: In function ‘g2d_map_cmdlist_gem’:
drivers/gpu/drm/exynos/exynos_drm_g2d.c:734:8: error: implicit
declaration of function ‘copy_from_user’; did you mean
‘sg_copy_from_buffer’? [-Werror=implicit-function-declaration]
if (copy_from_user(&g2d_userptr, (void __user *)handle,
^~
sg_copy_from_buffer
drivers/gpu/drm/exynos/exynos_drm_g2d.c: In function ‘g2d_finish_event’:
drivers/gpu/drm/exynos/exynos_drm_g2d.c:923:2: error: implicit
declaration of function ‘drm_send_event’; did you mean ‘drm_eld_mnl’?
[-Werror=implicit-function-declaration]
  drm_send_event(drm_dev, &e->base);
  ^~
  drm_eld_mnl
drivers/gpu/drm/exynos/exynos_drm_g2d.c: In function ‘g2d_wait_finish’:
drivers/gpu/drm/exynos/exynos_drm_g2d.c:990:3: error: implicit
declaration of function ‘mdelay’
[-Werror=implicit-function-declaration]
   mdelay(10);
   ^~
drivers/gpu/drm/exynos/exynos_drm_g2d.c: In function
‘exynos_g2d_set_cmdlist_ioctl’:
drivers/gpu/drm/exynos/exynos_drm_g2d.c:1174:9: error: implicit
declaration of function ‘drm_event_reserve_init’; did you mean
‘drm_mm_reserve_node’? [-Werror=implicit-function-declaration]
   ret = drm_event_reserve_init(drm_dev, file, &e->base, &e->event.base);
 ^~
 drm_mm_reserve_no

Re: [PATCH v4 1/2] drm/exynos: drop drmP.h usage

2019-06-24 Thread Inki Dae
Hi Sam,

2019년 6월 22일 (토) 오후 8:56, Sam Ravnborg 님이 작성:
>
> Drop use of the deprecated drmP.h file.
> Replace with forwards / externals as appropriate.
>
> While touching the list of include files divide
> them up in blocks and sort them.
>
> v3:
> - fix build errors in exynos_drm_g2d.c (Inki Dae)
>   The exynos_drm_g2d.c file is not built in the
>   standard configurations and was therefore missed.

Picked it up.

Thanks,
Inki Dae

>
> Signed-off-by: Sam Ravnborg 
> Cc: Inki Dae 
> Cc: Joonyoung Shim 
> Cc: Seung-Woo Kim 
> Cc: Kyungmin Park 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: Kukjin Kim 
> Cc: Krzysztof Kozlowski 
> Cc: Jingoo Han 
> ---
>  drivers/gpu/drm/exynos/exynos5433_drm_decon.c |  7 +++-
>  drivers/gpu/drm/exynos/exynos7_drm_decon.c|  8 ++--
>  drivers/gpu/drm/exynos/exynos_dp.c| 13 +++---
>  drivers/gpu/drm/exynos/exynos_drm_crtc.c  |  2 +-
>  drivers/gpu/drm/exynos/exynos_drm_dma.c   |  6 ++-
>  drivers/gpu/drm/exynos/exynos_drm_dpi.c   |  8 ++--
>  drivers/gpu/drm/exynos/exynos_drm_drv.c   | 12 +++---
>  drivers/gpu/drm/exynos/exynos_drm_drv.h   |  8 +++-
>  drivers/gpu/drm/exynos/exynos_drm_dsi.c   | 21 +-
>  drivers/gpu/drm/exynos/exynos_drm_fb.c|  6 +--
>  drivers/gpu/drm/exynos/exynos_drm_fbdev.c |  7 ++--
>  drivers/gpu/drm/exynos/exynos_drm_fimc.c  | 15 +++
>  drivers/gpu/drm/exynos/exynos_drm_fimd.c  | 14 ---
>  drivers/gpu/drm/exynos/exynos_drm_g2d.c   | 11 +++--
>  drivers/gpu/drm/exynos/exynos_drm_gem.c   |  7 ++--
>  drivers/gpu/drm/exynos/exynos_drm_gsc.c   | 13 +++---
>  drivers/gpu/drm/exynos/exynos_drm_ipp.c   |  3 +-
>  drivers/gpu/drm/exynos/exynos_drm_mic.c   | 22 +-
>  drivers/gpu/drm/exynos/exynos_drm_plane.c |  4 +-
>  drivers/gpu/drm/exynos/exynos_drm_rotator.c   | 10 ++---
>  drivers/gpu/drm/exynos/exynos_drm_scaler.c| 12 +++---
>  drivers/gpu/drm/exynos/exynos_drm_vidi.c  |  9 ++--
>  drivers/gpu/drm/exynos/exynos_hdmi.c  | 41 +--
>  drivers/gpu/drm/exynos/exynos_mixer.c | 31 +++---
>  24 files changed, 154 insertions(+), 136 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c 
> b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> index 0650b619de24..2d5cbfda3ca7 100644
> --- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> +++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> @@ -7,7 +7,6 @@
>   * Hyungwon Hwang 
>   */
>
> -#include 
>  #include 
>  #include 
>  #include 
> @@ -15,11 +14,15 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>
> -#include "exynos_drm_drv.h"
> +#include 
> +#include 
> +
>  #include "exynos_drm_crtc.h"
> +#include "exynos_drm_drv.h"
>  #include "exynos_drm_fb.h"
>  #include "exynos_drm_plane.h"
>  #include "regs-decon5433.h"
> diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c 
> b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
> index 13509ca8aa35..f0640950bd46 100644
> --- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
> +++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
> @@ -6,8 +6,6 @@
>   * Akshu Agarwal 
>   * Ajay Kumar 
>   */
> -#include 
> -#include 
>
>  #include 
>  #include 
> @@ -21,10 +19,14 @@
>  #include 
>  #include 
>
> +#include 
> +#include 
> +#include 
> +
>  #include "exynos_drm_crtc.h"
> -#include "exynos_drm_plane.h"
>  #include "exynos_drm_drv.h"
>  #include "exynos_drm_fb.h"
> +#include "exynos_drm_plane.h"
>  #include "regs-decon7.h"
>
>  /*
> diff --git a/drivers/gpu/drm/exynos/exynos_dp.c 
> b/drivers/gpu/drm/exynos/exynos_dp.c
> index c0653d007ca4..3a0f0ba8c63a 100644
> --- a/drivers/gpu/drm/exynos/exynos_dp.c
> +++ b/drivers/gpu/drm/exynos/exynos_dp.c
> @@ -6,25 +6,24 @@
>   * Author: Jingoo Han 
>   */
>
> -#include 
> -#include 
> -#include 
>  #include 
> -#include 
>  #include 
> +#include 
> +#include 
> +#include 
> +#include 
>  #include 
>  #include 
>  #include 
>  #include 
>
> -#include 
> +#include 
>  #include 
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
> -
> -#include 
>  #include 
>
>  #include "exynos_drm_crtc.h"
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
> b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
> index 98bec7418f01..77ce78986408 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
>

Re: [PATCH v4 1/2] drm/exynos: drop drmP.h usage

2019-06-24 Thread Inki Dae
Ah, there was a trivial merge conflict so I merged it manually.

Thanks,
Inki Dae

2019년 6월 24일 (월) 오후 10:32, Inki Dae 님이 작성:
>
> Hi Sam,
>
> 2019년 6월 22일 (토) 오후 8:56, Sam Ravnborg 님이 작성:
> >
> > Drop use of the deprecated drmP.h file.
> > Replace with forwards / externals as appropriate.
> >
> > While touching the list of include files divide
> > them up in blocks and sort them.
> >
> > v3:
> > - fix build errors in exynos_drm_g2d.c (Inki Dae)
> >   The exynos_drm_g2d.c file is not built in the
> >   standard configurations and was therefore missed.
>
> Picked it up.
>
> Thanks,
> Inki Dae
>
> >
> > Signed-off-by: Sam Ravnborg 
> > Cc: Inki Dae 
> > Cc: Joonyoung Shim 
> > Cc: Seung-Woo Kim 
> > Cc: Kyungmin Park 
> > Cc: David Airlie 
> > Cc: Daniel Vetter 
> > Cc: Kukjin Kim 
> > Cc: Krzysztof Kozlowski 
> > Cc: Jingoo Han 
> > ---
> >  drivers/gpu/drm/exynos/exynos5433_drm_decon.c |  7 +++-
> >  drivers/gpu/drm/exynos/exynos7_drm_decon.c|  8 ++--
> >  drivers/gpu/drm/exynos/exynos_dp.c| 13 +++---
> >  drivers/gpu/drm/exynos/exynos_drm_crtc.c  |  2 +-
> >  drivers/gpu/drm/exynos/exynos_drm_dma.c   |  6 ++-
> >  drivers/gpu/drm/exynos/exynos_drm_dpi.c   |  8 ++--
> >  drivers/gpu/drm/exynos/exynos_drm_drv.c   | 12 +++---
> >  drivers/gpu/drm/exynos/exynos_drm_drv.h   |  8 +++-
> >  drivers/gpu/drm/exynos/exynos_drm_dsi.c   | 21 +-
> >  drivers/gpu/drm/exynos/exynos_drm_fb.c|  6 +--
> >  drivers/gpu/drm/exynos/exynos_drm_fbdev.c |  7 ++--
> >  drivers/gpu/drm/exynos/exynos_drm_fimc.c  | 15 +++
> >  drivers/gpu/drm/exynos/exynos_drm_fimd.c  | 14 ---
> >  drivers/gpu/drm/exynos/exynos_drm_g2d.c   | 11 +++--
> >  drivers/gpu/drm/exynos/exynos_drm_gem.c   |  7 ++--
> >  drivers/gpu/drm/exynos/exynos_drm_gsc.c   | 13 +++---
> >  drivers/gpu/drm/exynos/exynos_drm_ipp.c   |  3 +-
> >  drivers/gpu/drm/exynos/exynos_drm_mic.c   | 22 +-
> >  drivers/gpu/drm/exynos/exynos_drm_plane.c |  4 +-
> >  drivers/gpu/drm/exynos/exynos_drm_rotator.c   | 10 ++---
> >  drivers/gpu/drm/exynos/exynos_drm_scaler.c| 12 +++---
> >  drivers/gpu/drm/exynos/exynos_drm_vidi.c  |  9 ++--
> >  drivers/gpu/drm/exynos/exynos_hdmi.c  | 41 +--
> >  drivers/gpu/drm/exynos/exynos_mixer.c | 31 +++---
> >  24 files changed, 154 insertions(+), 136 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c 
> > b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> > index 0650b619de24..2d5cbfda3ca7 100644
> > --- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> > +++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> > @@ -7,7 +7,6 @@
> >   * Hyungwon Hwang 
> >   */
> >
> > -#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -15,11 +14,15 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >
> > -#include "exynos_drm_drv.h"
> > +#include 
> > +#include 
> > +
> >  #include "exynos_drm_crtc.h"
> > +#include "exynos_drm_drv.h"
> >  #include "exynos_drm_fb.h"
> >  #include "exynos_drm_plane.h"
> >  #include "regs-decon5433.h"
> > diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c 
> > b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
> > index 13509ca8aa35..f0640950bd46 100644
> > --- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
> > +++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
> > @@ -6,8 +6,6 @@
> >   * Akshu Agarwal 
> >   * Ajay Kumar 
> >   */
> > -#include 
> > -#include 
> >
> >  #include 
> >  #include 
> > @@ -21,10 +19,14 @@
> >  #include 
> >  #include 
> >
> > +#include 
> > +#include 
> > +#include 
> > +
> >  #include "exynos_drm_crtc.h"
> > -#include "exynos_drm_plane.h"
> >  #include "exynos_drm_drv.h"
> >  #include "exynos_drm_fb.h"
> > +#include "exynos_drm_plane.h"
> >  #include "regs-decon7.h"
> >
> >  /*
> > diff --git a/drivers/gpu/drm/exynos/exynos_dp.c 
> > b/drivers/gpu/drm/exynos/exynos_dp.c
> > index c0653d007ca4..3a0f0ba8c63a 100644
> > --- a/drivers/gpu/drm/exynos/exynos_dp.c
> > +++ b/drivers/gpu/drm/exynos/exynos_dp.c
> > @@ -6,25 +6,24 @@
> >  

Re: [PATCH v4 2/2] drm/exynos: trigger build of all modules

2019-06-24 Thread Inki Dae
HI Sam,

2019년 6월 22일 (토) 오후 8:56, Sam Ravnborg 님이 작성:
>
> Add COMPILE_TEST dependency to force exynos driver to
> built for more than arm and to built modules
> that otherwise required other symbols to be de-selected.
>
> This will increase build coverage of the exynos driver
> thus allowing most trivial build errors to be detected/fixed early.
>
> This introduces one warning when built using sh:
> exynos7_drm_decon.c: In function ‘decon_remove’:
> exynos7_drm_decon.c:769:24: warning: unused variable ‘ctx’
>   struct decon_context *ctx = dev_get_drvdata(&pdev->dev);
>
> This is due to the definition of iounmap() in sh,
> and nothing that exynos driver can fix.
>
> Include fix of exynos build for alpha.
>
> Signed-off-by: Sam Ravnborg 
> Cc: Inki Dae 
> Cc: Joonyoung Shim 
> Cc: Seung-Woo Kim 
> Cc: Kyungmin Park 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: Kukjin Kim 
> Cc: Krzysztof Kozlowski 
> Cc: Jingoo Han 
> ---
>  drivers/gpu/drm/exynos/Kconfig| 6 +++---
>  drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 1 +
>  2 files changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
> index cbe58d307d1c..60ce4a8ad9e1 100644
> --- a/drivers/gpu/drm/exynos/Kconfig
> +++ b/drivers/gpu/drm/exynos/Kconfig
> @@ -1,7 +1,7 @@
>  # SPDX-License-Identifier: GPL-2.0-only
>  config DRM_EXYNOS
> tristate "DRM Support for Samsung SoC EXYNOS Series"
> -   depends on OF && DRM && (ARCH_S3C64XX || ARCH_S5PV210 || ARCH_EXYNOS 
> || ARCH_MULTIPLATFORM)
> +   depends on OF && DRM && (ARCH_S3C64XX || ARCH_S5PV210 || ARCH_EXYNOS 
> || ARCH_MULTIPLATFORM || COMPILE_TEST)
> select DRM_KMS_HELPER
> select VIDEOMODE_HELPERS
> select SND_SOC_HDMI_CODEC if SND_SOC
> @@ -86,7 +86,7 @@ comment "Sub-drivers"
>
>  config DRM_EXYNOS_G2D
> bool "G2D"
> -   depends on VIDEO_SAMSUNG_S5P_G2D=n
> +   depends on VIDEO_SAMSUNG_S5P_G2D=n || COMPILE_TEST
> select FRAME_VECTOR
> help
>   Choose this option if you want to use Exynos G2D for DRM.
> @@ -114,7 +114,7 @@ config DRM_EXYNOS_SCALER
>
>  config DRM_EXYNOS_GSC
> bool "GScaler"
> -   depends on VIDEO_SAMSUNG_EXYNOS_GSC=n
> +   depends on VIDEO_SAMSUNG_EXYNOS_GSC=n || COMPILE_TEST
> select DRM_EXYNOS_IPP
> help
>   Choose this option if you want to use Exynos GSC for DRM.
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c 
> b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> index aefcd624fe32..b0877b97291c 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> @@ -10,6 +10,7 @@
>
>  #include 
>  #include 
> +#include 

Is this change related to this patch?

Thanks,
Inki Dae

>
>  #include 
>  #include 
> --
> 2.20.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 2/2] drm/exynos: trigger build of all modules

2019-06-24 Thread Inki Dae
Hi Sam,

On 19. 6. 25. 오전 12:29, Sam Ravnborg wrote:
> Hi Inki
> 
> From changelog:
>>>
>>> Include fix of exynos build for alpha.
>>>
> 
> 
>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c 
>>> b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
>>> index aefcd624fe32..b0877b97291c 100644
>>> --- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
>>> @@ -10,6 +10,7 @@
>>>
>>>  #include 
>>>  #include 
>>> +#include 
>>
>> Is this change related to this patch?
> 
> This is the above mentioned fix.
> Alpha often needs one to pull in vmalloc.h - where all other
> architectures get it indirect via other headers.
> I have never bothered to find out why alpa needs more headers files,
> but I always make sure to test things using alpha so 0-day do not yell at me.

I couldn't see any warning message while building your patch after dropping 
above change.
Could you check it again on top of below git repo.?
 git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git 
exynos-drm-next

I'm going to request GIT-PULL as soon as you get back to me.

Thanks,
Inki Dae

> 
>   Sam
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 2/2] drm/exynos: trigger build of all modules

2019-06-25 Thread Inki Dae
Hi Sam,

On 19. 6. 25. 오후 1:59, Sam Ravnborg wrote:
> Hi Inki.
> 
>>> Alpha often needs one to pull in vmalloc.h - where all other
>>> architectures get it indirect via other headers.
>>> I have never bothered to find out why alpa needs more headers files,
>>> but I always make sure to test things using alpha so 0-day do not yell at 
>>> me.
>>
>> I couldn't see any warning message while building your patch after dropping 
>> above change.
>> Could you check it again on top of below git repo.?
>>  git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git 
>> exynos-drm-next
>>
>> I'm going to request GIT-PULL as soon as you get back to me.
> 
> With the COMPILE_TEST patch, but without the extra fix I get:
> 
>   CC [M]  drivers/gpu/drm/exynos/exynos_drm_fbdev.o
> /home/sam/kernel/drm-exynos/drivers/gpu/drm/exynos/exynos_drm_fbdev.c: In 
> function ‘exynos_drm_fbdev_update’:
> /home/sam/kernel/drm-exynos/drivers/gpu/drm/exynos/exynos_drm_fbdev.c:94:40: 
> error: implicit declaration of function ‘vmap’; did you mean ‘bmap’? 
> [-Werror=implicit-function-declaration]
>   exynos_gem->kvaddr = (void __iomem *) vmap(exynos_gem->pages, nr_pages,
> ^~~~
> bmap
> /home/sam/kernel/drm-exynos/drivers/gpu/drm/exynos/exynos_drm_fbdev.c:95:5: 
> error: ‘VM_MAP’ undeclared (first use in this function); did you mean 
> ‘VM_MPX’?
>  VM_MAP, pgprot_writecombine(PAGE_KERNEL));
>  ^~
>  VM_MPX
> /home/sam/kernel/drm-exynos/drivers/gpu/drm/exynos/exynos_drm_fbdev.c:95:5: 
> note: each undeclared identifier is reported only once for each function it 
> appears in
> /home/sam/kernel/drm-exynos/drivers/gpu/drm/exynos/exynos_drm_fbdev.c: In 
> function ‘exynos_drm_fbdev_destroy’:
> /home/sam/kernel/drm-exynos/drivers/gpu/drm/exynos/exynos_drm_fbdev.c:243:2: 
> error: implicit declaration of function ‘vunmap’; did you mean ‘iounmap’? 
> [-Werror=implicit-function-declaration]
>   vunmap(exynos_gem->kvaddr);
>   ^~
>   iounmap
> cc1: some warnings being treated as errors
> 
> 
> This is with a freshly pulled tree from drm-exynos.git exynos-drm-next
> 
> The warning only appear if you build for alpha.
> So the extra fix is indeed needed. But always good to double check -
> thanks for asking.

Thanks for check,
Inki Dae

> 
> Note:
> My gcc version for alpha:
> $ alpha-linux-gnu-gcc --version
> alpha-linux-gnu-gcc (Ubuntu 8.3.0-6ubuntu1) 8.3.0
> 
>   Sam
> 
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[GIT PULL] exynos-drm-next

2019-06-27 Thread Inki Dae
Hi Dave,

   Just two cleanups - one is to drop drmP.h header, and other is to add
   COMPILE_TEST flag for increasing build test coverage.

   Please kindly let me know if there is any problem.

Thanks,
Inki Dae

The following changes since commit 14808a12bdbdc21143eba70ea07830197b3a04ff:

  Merge tag 'drm-next-5.3-2019-06-25' of
git://people.freedesktop.org/~agd5f/linux into drm-next (2019-06-27
12:33:57 +1000)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos
tags/exynos-drm-next-for-v5.3

for you to fetch changes up to 156bdac99061b4013c8e47799c6e574f7f84e9f4:

  drm/exynos: trigger build of all modules (2019-06-27 22:30:56 +0900)


- Drop the use of drmP.h header file
   drmP.h header file has been deprecated so this patch drops the use of
   this header, and instead includes appropriate header files required.
 - Add COMPILE_TEST flag
   This patch adds COMPILE_TEST dependency to exynos drm driver to
   increase build test coverage. And also, it includes vmalloc.h
   header file to fix one build warning which is introduced when
   building the Linux kernel using sh.


Sam Ravnborg (2):
  drm/exynos: drop drmP.h usage
  drm/exynos: trigger build of all modules

 drivers/gpu/drm/exynos/Kconfig|  6 ++--
 drivers/gpu/drm/exynos/exynos5433_drm_decon.c |  7 +++--
 drivers/gpu/drm/exynos/exynos7_drm_decon.c|  8 --
 drivers/gpu/drm/exynos/exynos_dp.c| 13 -
 drivers/gpu/drm/exynos/exynos_drm_crtc.c  |  2 +-
 drivers/gpu/drm/exynos/exynos_drm_dma.c   |  6 ++--
 drivers/gpu/drm/exynos/exynos_drm_dpi.c   |  8 +++---
 drivers/gpu/drm/exynos/exynos_drm_drv.c   | 12 
 drivers/gpu/drm/exynos/exynos_drm_drv.h   |  8 +-
 drivers/gpu/drm/exynos/exynos_drm_dsi.c   | 21 +++---
 drivers/gpu/drm/exynos/exynos_drm_fb.c|  6 ++--
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c |  8 --
 drivers/gpu/drm/exynos/exynos_drm_fimc.c  | 15 +-
 drivers/gpu/drm/exynos/exynos_drm_fimd.c  | 14 +
 drivers/gpu/drm/exynos/exynos_drm_g2d.c   | 11 ---
 drivers/gpu/drm/exynos/exynos_drm_gem.c   |  7 +++--
 drivers/gpu/drm/exynos/exynos_drm_gsc.c   | 13 +
 drivers/gpu/drm/exynos/exynos_drm_ipp.c   |  3 +-
 drivers/gpu/drm/exynos/exynos_drm_mic.c   | 22 +++---
 drivers/gpu/drm/exynos/exynos_drm_plane.c |  4 +--
 drivers/gpu/drm/exynos/exynos_drm_rotator.c   | 10 +++
 drivers/gpu/drm/exynos/exynos_drm_scaler.c| 12 
 drivers/gpu/drm/exynos/exynos_drm_vidi.c  |  9 +++---
 drivers/gpu/drm/exynos/exynos_hdmi.c  | 41 +--
 drivers/gpu/drm/exynos/exynos_mixer.c | 31 ++--
 25 files changed, 158 insertions(+), 139 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/exynos/mixer: fix MIXER shadow registry synchronisation code

2019-03-18 Thread Inki Dae


19. 3. 8. 오전 9:12에 Marian Mihailescu 이(가) 쓴 글:
> Tested on my Exynos5422 Odroid XU4, vsync seems to not happen at all,> screen 
> remains black since kernel loads.

I faced with same issue.

Andrzej,
Did you test this patch and worked correctly?

I had tested this patch on mainline kernel - linux-5.1.0-rc1 - and even on 
Tizen kernel (tizen-next branch) but screen remained blank after running 
modetest app.
Without this patch, modetest app worked well on both kernels.

Thanks,
Inki Dae

> 
> --
> Either I've been missing something or nothing has been going on. (K. E. 
> Gordon)
> 
> On Thu, Mar 7, 2019 at 1:36 AM Andrzej Hajda  wrote:
>>
>> MIXER on Exynos5 SoCs uses different synchronisation method than Exynos4
>> to update internal state (shadow registers).
>> Apparently the driver implements it incorrectly. The rule should be
>> as follows:
>> - do not request updating registers until previous request was finished,
>>   ie. MXR_CFG_LAYER_UPDATE_COUNT must be 0.
>> - before setting registers synchronisation on VSYNC should be turned off,
>>   ie. MXR_STATUS_SYNC_ENABLE should be reset,
>> - after finishing MXR_STATUS_SYNC_ENABLE should be set again.
>> The patch hopefully implements it correctly.
>> Below sample kernel log from page fault caused by the bug:
>>
>> [   25.670038] exynos-sysmmu 1465.sysmmu: 1445.mixer: PAGE FAULT 
>> occurred at 0x2247b800
>> [   25.677888] [ cut here ]
>> [   25.682164] kernel BUG at ../drivers/iommu/exynos-iommu.c:450!
>> [   25.687971] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM
>> [   25.693778] Modules linked in:
>> [   25.696816] CPU: 5 PID: 1553 Comm: fb-release_test Not tainted 
>> 5.0.0-rc7-01157-g5f86b1566bdd #136
>> [   25.705646] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
>> [   25.711710] PC is at exynos_sysmmu_irq+0x1c0/0x264
>> [   25.716470] LR is at lock_is_held_type+0x44/0x64
>>
>> Reported-by: Marian Mihailescu 
>> Signed-off-by: Andrzej Hajda 
>> ---
>>  drivers/gpu/drm/exynos/exynos_mixer.c | 107 +++---
>>  1 file changed, 63 insertions(+), 44 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
>> b/drivers/gpu/drm/exynos/exynos_mixer.c
>> index 0573eab0e190..42ce01c226ef 100644
>> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
>> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
>> @@ -20,6 +20,7 @@
>>  #include "regs-vp.h"
>>
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> @@ -352,15 +353,59 @@ static void mixer_cfg_vp_blend(struct mixer_context 
>> *ctx, unsigned int alpha)
>> mixer_reg_write(ctx, MXR_VIDEO_CFG, val);
>>  }
>>
>> -static void mixer_vsync_set_update(struct mixer_context *ctx, bool enable)
>> +static bool mixer_is_synced(struct mixer_context *ctx)
>>  {
>> -   /* block update on vsync */
>> -   mixer_reg_writemask(ctx, MXR_STATUS, enable ?
>> -   MXR_STATUS_SYNC_ENABLE : 0, MXR_STATUS_SYNC_ENABLE);
>> +   u32 base, shadow;
>>
>> +   if (ctx->mxr_ver == MXR_VER_16_0_33_0 ||
>> +   ctx->mxr_ver == MXR_VER_128_0_0_184)
>> +   return !(mixer_reg_read(ctx, MXR_CFG) &
>> +MXR_CFG_LAYER_UPDATE_COUNT_MASK);
>> +
>> +   if (test_bit(MXR_BIT_VP_ENABLED, &ctx->flags) &&
>> +   vp_reg_read(ctx, VP_SHADOW_UPDATE))
>> +   return false;
>> +
>> +   base = mixer_reg_read(ctx, MXR_CFG);
>> +   shadow = mixer_reg_read(ctx, MXR_CFG_S);
>> +   if (base != shadow)
>> +   return false;
>> +
>> +   base = mixer_reg_read(ctx, MXR_GRAPHIC_BASE(0));
>> +   shadow = mixer_reg_read(ctx, MXR_GRAPHIC_BASE_S(0));
>> +   if (base != shadow)
>> +   return false;
>> +
>> +   base = mixer_reg_read(ctx, MXR_GRAPHIC_BASE(1));
>> +   shadow = mixer_reg_read(ctx, MXR_GRAPHIC_BASE_S(1));
>> +   if (base != shadow)
>> +   return false;
>> +
>> +   return true;
>> +}
>> +
>> +static int mixer_wait_for_sync(struct mixer_context *ctx)
>> +{
>> +   ktime_t timeout = ktime_add_us(ktime_get(), 10);
>> +
>> +   while (!mixer_is_synced(ctx)) {
>> +   usleep_range(1000, 2000);
>> +   if (ktime_compare(ktime_get(), timeout) > 0)
>> +   return -ETIMEDOUT;
>> +   }
>> +   return 0;
>> +}
>> +
&

Re: [PATCH 2/6] drm/exynos: dsi: Use drm_bridge_detach

2019-03-18 Thread Inki Dae


19. 3. 15. 오후 10:08에 Jagan Teki 이(가) 쓴 글:
> drm_bridge_detach now available to use while detaching
> bridge, use this core wrapper instead of explicitly
> pointing the bridge funcs.
> 
> Cc: Dae 
> Cc: Joonyoung Shim 
> Cc: Seung-Woo Kim 
> Cc: Kyungmin Park 
> Signed-off-by: Jagan Teki 

Acked-by: Inki Dae 

Thanks,
Inki Dae

> ---
>  drivers/gpu/drm/exynos/exynos_drm_dsi.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
> b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> index a4253dd55f86..5daf43d02768 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> @@ -1583,8 +1583,7 @@ static int exynos_dsi_host_detach(struct mipi_dsi_host 
> *host,
>   dsi->connector.status = connector_status_disconnected;
>   mutex_unlock(&drm->mode_config.mutex);
>   } else {
> - if (dsi->out_bridge->funcs->detach)
> - dsi->out_bridge->funcs->detach(dsi->out_bridge);
> + drm_bridge_detach(dsi->out_bridge);
>   dsi->out_bridge = NULL;
>   }
>  
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2] drm/exynos/mixer: fix MIXER shadow registry synchronisation code

2019-03-21 Thread Inki Dae


19. 3. 19. 오후 10:05에 Andrzej Hajda 이(가) 쓴 글:
> MIXER on Exynos5 SoCs uses different synchronisation method than Exynos4
> to update internal state (shadow registers).
> Apparently the driver implements it incorrectly. The rule should be
> as follows:
> - do not request updating registers until previous request was finished,
>   ie. MXR_CFG_LAYER_UPDATE_COUNT must be 0.
> - before setting registers synchronisation on VSYNC should be turned off,
>   ie. MXR_STATUS_SYNC_ENABLE should be reset,
> - after finishing MXR_STATUS_SYNC_ENABLE should be set again.
> The patch hopefully implements it correctly.
> Below sample kernel log from page fault caused by the bug:
> 
> [   25.670038] exynos-sysmmu 1465.sysmmu: 1445.mixer: PAGE FAULT 
> occurred at 0x2247b800
> [   25.677888] [ cut here ]
> [   25.682164] kernel BUG at ../drivers/iommu/exynos-iommu.c:450!
> [   25.687971] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM
> [   25.693778] Modules linked in:
> [   25.696816] CPU: 5 PID: 1553 Comm: fb-release_test Not tainted 
> 5.0.0-rc7-01157-g5f86b1566bdd #136
> [   25.705646] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
> [   25.711710] PC is at exynos_sysmmu_irq+0x1c0/0x264
> [   25.716470] LR is at lock_is_held_type+0x44/0x64
> 
> v2: added missing MXR_CFG_LAYER_UPDATE bit setting in mixer_enable_sync
> 
> Reported-by: Marian Mihailescu 
> Signed-off-by: Andrzej Hajda 
> ---
> Hi Inki and Marian,
> 
> This is fixed version of my previous patch. The only difference is
> added missing MXR_CFG_LAYER_UPDATE setting in mixer_enable_sync.
> I hope this time it is correct. It should solve one page fault issue
> in MIXER, Marek is preparing fix for another issue (to low clock set by
> devfreq). I hope with both patches page faults will not happen anymore ;)

With this patch modetest worked well.
BTW, this change may affect Exynos4 series - which have different 
synchronization way to update shadow registers - so could you or someone else 
who has Exynos4xxx based board check it on Odroid-u3 board? I have no board. :(

Thanks,
Inki Dae

> 
> Regards
> Andrzej
> ---
>  drivers/gpu/drm/exynos/exynos_mixer.c | 110 +++---
>  1 file changed, 66 insertions(+), 44 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
> b/drivers/gpu/drm/exynos/exynos_mixer.c
> index 0573eab0e190..f35e4ab55b27 100644
> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
> @@ -20,6 +20,7 @@
>  #include "regs-vp.h"
>  
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -352,15 +353,62 @@ static void mixer_cfg_vp_blend(struct mixer_context 
> *ctx, unsigned int alpha)
>   mixer_reg_write(ctx, MXR_VIDEO_CFG, val);
>  }
>  
> -static void mixer_vsync_set_update(struct mixer_context *ctx, bool enable)
> +static bool mixer_is_synced(struct mixer_context *ctx)
>  {
> - /* block update on vsync */
> - mixer_reg_writemask(ctx, MXR_STATUS, enable ?
> - MXR_STATUS_SYNC_ENABLE : 0, MXR_STATUS_SYNC_ENABLE);
> + u32 base, shadow;
>  
> + if (ctx->mxr_ver == MXR_VER_16_0_33_0 ||
> + ctx->mxr_ver == MXR_VER_128_0_0_184)
> + return !(mixer_reg_read(ctx, MXR_CFG) &
> +  MXR_CFG_LAYER_UPDATE_COUNT_MASK);
> +
> + if (test_bit(MXR_BIT_VP_ENABLED, &ctx->flags) &&
> + vp_reg_read(ctx, VP_SHADOW_UPDATE))
> + return false;
> +
> + base = mixer_reg_read(ctx, MXR_CFG);
> + shadow = mixer_reg_read(ctx, MXR_CFG_S);
> + if (base != shadow)
> + return false;
> +
> + base = mixer_reg_read(ctx, MXR_GRAPHIC_BASE(0));
> + shadow = mixer_reg_read(ctx, MXR_GRAPHIC_BASE_S(0));
> + if (base != shadow)
> + return false;
> +
> + base = mixer_reg_read(ctx, MXR_GRAPHIC_BASE(1));
> + shadow = mixer_reg_read(ctx, MXR_GRAPHIC_BASE_S(1));
> + if (base != shadow)
> + return false;
> +
> + return true;
> +}
> +
> +static int mixer_wait_for_sync(struct mixer_context *ctx)
> +{
> + ktime_t timeout = ktime_add_us(ktime_get(), 10);
> +
> + while (!mixer_is_synced(ctx)) {
> + usleep_range(1000, 2000);
> + if (ktime_compare(ktime_get(), timeout) > 0)
> + return -ETIMEDOUT;
> + }
> + return 0;
> +}
> +
> +static void mixer_disable_sync(struct mixer_context *ctx)
> +{
> + mixer_reg_writemask(ctx, MXR_STATUS, 0, MXR_STATUS_SYNC_ENABLE);
> +}
> +
> +static void mixer_enable_sync(struct mixer_context *ctx)
> +{
> + if (ctx->mxr_ver ==

Re: [PATCH v2] drm/exynos/mixer: fix MIXER shadow registry synchronisation code

2019-03-21 Thread Inki Dae
Hi Marek,

19. 3. 21. 오후 5:32에 Marek Szyprowski 이(가) 쓴 글:
> Hi Inki,
> 
> On 2019-03-21 09:20, Inki Dae wrote:
>> 19. 3. 19. 오후 10:05에 Andrzej Hajda 이(가) 쓴 글:
>>> MIXER on Exynos5 SoCs uses different synchronisation method than Exynos4
>>> to update internal state (shadow registers).
>>> Apparently the driver implements it incorrectly. The rule should be
>>> as follows:
>>> - do not request updating registers until previous request was finished,
>>>ie. MXR_CFG_LAYER_UPDATE_COUNT must be 0.
>>> - before setting registers synchronisation on VSYNC should be turned off,
>>>ie. MXR_STATUS_SYNC_ENABLE should be reset,
>>> - after finishing MXR_STATUS_SYNC_ENABLE should be set again.
>>> The patch hopefully implements it correctly.
>>> Below sample kernel log from page fault caused by the bug:
>>>
>>> [   25.670038] exynos-sysmmu 1465.sysmmu: 1445.mixer: PAGE FAULT 
>>> occurred at 0x2247b800
>>> [   25.677888] [ cut here ]
>>> [   25.682164] kernel BUG at ../drivers/iommu/exynos-iommu.c:450!
>>> [   25.687971] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM
>>> [   25.693778] Modules linked in:
>>> [   25.696816] CPU: 5 PID: 1553 Comm: fb-release_test Not tainted 
>>> 5.0.0-rc7-01157-g5f86b1566bdd #136
>>> [   25.705646] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
>>> [   25.711710] PC is at exynos_sysmmu_irq+0x1c0/0x264
>>> [   25.716470] LR is at lock_is_held_type+0x44/0x64
>>>
>>> v2: added missing MXR_CFG_LAYER_UPDATE bit setting in mixer_enable_sync
>>>
>>> Reported-by: Marian Mihailescu 
>>> Signed-off-by: Andrzej Hajda 
>>> ---
>>> Hi Inki and Marian,
>>>
>>> This is fixed version of my previous patch. The only difference is
>>> added missing MXR_CFG_LAYER_UPDATE setting in mixer_enable_sync.
>>> I hope this time it is correct. It should solve one page fault issue
>>> in MIXER, Marek is preparing fix for another issue (to low clock set by
>>> devfreq). I hope with both patches page faults will not happen anymore ;)
>> With this patch modetest worked well.
>> BTW, this change may affect Exynos4 series - which have different 
>> synchronization way to update shadow registers - so could you or someone 
>> else who has Exynos4xxx based board check it on Odroid-u3 board? I have no 
>> board. :(
> 
> Andrzej's patch has been tested on Exynos4412 too. HDMI display works 
> fine on Odroid U3.

Applied.

Thanks,
Inki Dae

> 
> ...
> 
> Best regards
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[GIT PULL] exynos-drm-fixes

2019-03-21 Thread Inki Dae
Hi Dave,

   Just one fixup to resolve page fault issue at Mixer device.

   Please kindly let me know if there is any problem.

Thanks,
Inki Dae

The following changes since commit 9e98c678c2d6ae3a17cb2de55d17f69dddaa231b:

  Linux 5.1-rc1 (2019-03-17 14:22:26 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos 
tags/exynos-drm-fixes-for-5.1-rc2

for you to fetch changes up to 6a3b45ada960ac475ec2b4103d43e57943b2b8d3:

  drm/exynos/mixer: fix MIXER shadow registry synchronisation code (2019-03-21 
09:47:29 +0900)


- Fix page fault issue at Mixer device
  . This patch fixes the page fault issue by correcting sychronization
method for updating shadow registers for Mixer device.


Andrzej Hajda (1):
  drm/exynos/mixer: fix MIXER shadow registry synchronisation code

 drivers/gpu/drm/exynos/exynos_mixer.c | 110 --
 1 file changed, 66 insertions(+), 44 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 RESEND 00/24] drm/exynos: add support for GSCALER planes on Exynos5433

2019-03-24 Thread Inki Dae
Hi Andrzej,

Merge conflict. Could you rebase this patch series on top of exynos-drm-next?

Thanks,
Inki Dae

19. 3. 20. 오후 10:06에 Andrzej Hajda 이(가) 쓴 글:
> Hi Inki,
> 
> GSCALERs in Exynos SoCs support conversion between wide range of image 
> formats,
> plus scaling and rotation.
> Driver already supports mem2mem mode - via ExynosDRM IPP framework.
> This patchset adds support for mem to display mode - framebuffers can
> be converted, scaled and send directly to Display Controller. From DRM
> framework's point of view every GSCALER exposes drm_plane which can be 
> connected
> to display controller (display panel or TV).
> The feature is not well documented so the development was quite difficult -
> a process of trial and error, vendor code analysis, guessing from datasheets.
> Hopefully most of the issues were solved. I have developed and tested it on
> TM2 device with panel and TV paths.
> 
> The patchset contains three parts:
> 1. Preparatory patches - mostly cleanup and refactoring of drm_crtc and 
> drm_plane
>related structures, to allow usage of planes which are not physically bound
>to crtcs (01-13).
> 2. Adding local path support to GSCALER and DECON (14-20).
> 3. Few fixes of bugs existing already in the code but discovered due to added
>local path support (21-23).
> 
> The patchset is based on exynos_drm_next plus my patchset adding zpos to DECON
> and FIMD - 'drm/exynos: add support for dynamic zpos in DECON and FIMD' - it 
> is
> required to allow set z-pos position of GSCALER planes.
> To simplify tests I have also created branch containing all required patches:
> Repo: https://git.tizen.org/cgit/platform/kernel/linux-exynos
> Branch: sandbox/ahajda/dev/exynos-drm-local-path
> 
> This is v2 version of the patchset. In this version I have moved code setting
> cursor plane in crtc to separate patch together with code disabling fast 
> cursor
> updates - hardware does not support it. To keep bisectability DTS patches 
> should
> be applied before subsequent ones.
> 
> Regards
> Andrzej
> 
> 
> Andrzej Hajda (24):
>   drm/exynos: remove exynos_drm_plane.h header
>   drm/exynos: remove spare macro
>   drm/exynos: drop exynos_drm_plane_config structure
>   drm/exynos: add exynos_drm_crtc_init function
>   drm/exynos/decon5433: embed exynos_drm_crtc directly into context
>   drm/exynos/decon7: embed exynos_drm_crtc directly into context
>   drm/exynos/fimd: embed exynos_drm_crtc directly into context
>   drm/exynos/mixer: embed exynos_drm_crtc directly into context
>   drm/exynos/vidi: embed exynos_drm_crtc directly into context
>   drm/exynos: remove standalone exynos_drm_crtc leftovers
>   drm/exynos/vidi: remove encoder_to_vidi helper
>   drm/exynos: unify plane type assignment
>   drm/exynos: set primary plane in exynos_drm_crtc_init
>   drm/exynos: set cursor plane in exynos_drm_crtc_init
>   drm/exynos: add plane update/disable callbacks for planes
>   drm/exynos: add GSCALER plane capability
>   drm/exynos/gscaler: fix id assignement
>   arm64: dts: exynos: configure GSCALER related clocks
>   arm64: dts: exynos: add DSD/GSD clocks to DECONs and GSCALERs
>   drm/exynos/gscaler: add local path support
>   drm/exynos/decon5433: add local path support
>   drm/exynos/decon5433: wait for finish previous update
>   drm/exynos/gscaler: change supported color format BGRX to XBGR
>   drm/exynos/gscaler: fix handling YVU420 pixel format
> 
>  .../dts/exynos/exynos5433-tm2-common.dtsi |   6 +
>  arch/arm64/boot/dts/exynos/exynos5433-tm2.dts |   6 +-
>  arch/arm64/boot/dts/exynos/exynos5433.dtsi|  25 +-
>  drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 162 -
>  drivers/gpu/drm/exynos/exynos7_drm_decon.c|  66 +++--
>  drivers/gpu/drm/exynos/exynos_drm_crtc.c  |  46 ++--
>  drivers/gpu/drm/exynos/exynos_drm_crtc.h  |   7 +-
>  drivers/gpu/drm/exynos/exynos_drm_drv.c   |   1 -
>  drivers/gpu/drm/exynos/exynos_drm_drv.h   |  50 ++--
>  drivers/gpu/drm/exynos/exynos_drm_fb.c|  10 +-
>  drivers/gpu/drm/exynos/exynos_drm_fimd.c  |  85 +++
>  drivers/gpu/drm/exynos/exynos_drm_gsc.c   | 229 ++
>  drivers/gpu/drm/exynos/exynos_drm_plane.c |  84 ---
>  drivers/gpu/drm/exynos/exynos_drm_plane.h |  14 --
>  drivers/gpu/drm/exynos/exynos_drm_vidi.c  |  48 ++--
>  drivers/gpu/drm/exynos/exynos_mixer.c |  95 +++-
>  drivers/gpu/drm/exynos/regs-decon5433.h   |   6 +
>  drivers/gpu/drm/exynos/regs-gsc.h |   6 +
>  18 files changed, 538 insertions(+), 408 deletions(-)
>  delete mode 100644 drivers/gpu/drm/exynos/exynos_drm_plane.h
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 RESEND 00/24] drm/exynos: add support for GSCALER planes on Exynos5433

2019-03-26 Thread Inki Dae
Hi Andrzej,

19. 3. 25. 오후 4:13에 Andrzej Hajda 이(가) 쓴 글:
> Hi Inki,
> 
> GSCALERs in Exynos SoCs support conversion between wide range of image 
> formats,
> plus scaling and rotation.
> Driver already supports mem2mem mode - via ExynosDRM IPP framework.
> This patchset adds support for mem to display mode - framebuffers can
> be converted, scaled and send directly to Display Controller. From DRM
> framework's point of view every GSCALER exposes drm_plane which can be 
> connected
> to display controller (display panel or TV).
> The feature is not well documented so the development was quite difficult -
> a process of trial and error, vendor code analysis, guessing from datasheets.
> Hopefully most of the issues were solved. I have developed and tested it on
> TM2 device with panel and TV paths.
> 
> The patchset contains three parts:
> 1. Preparatory patches - mostly cleanup and refactoring of drm_crtc and 
> drm_plane
>related structures, to allow usage of planes which are not physically bound
>to crtcs (01-13).
> 2. Adding local path support to GSCALER and DECON (14-20).
> 3. Few fixes of bugs existing already in the code but discovered due to added
>local path support (21-23).
> 
> The patchset is based on exynos_drm_next plus my patchset adding zpos to DECON
> and FIMD - 'drm/exynos: add support for dynamic zpos in DECON and FIMD' - it 
> is
> required to allow set z-pos position of GSCALER planes.

As for this, we had a discussion before,
https://patchwork.kernel.org/cover/10715521/

And the last comment I left was,
"I know. Your patch will show that plane order is changed by changing mapping 
of plane from one window to another window regardless of overlay priority 
change support. 
I'm not clear but seems maybe we could do more something with your patch even 
though DECON/FIMD have limit. So I will enqueue your patch until real user is 
fixed."

Did you fix TDM module of Tizen which is a real user? Without any modification 
of the TDM module, the user doesn't work.

> To simplify tests I have also created branch containing all required patches:
> Repo: https://git.tizen.org/cgit/platform/kernel/linux-exynos
> Branch: sandbox/ahajda/dev/exynos-drm-local-path
> 
> This is v2 version of the patchset. In this version I have moved code setting
> cursor plane in crtc to separate patch together with code disabling fast 
> cursor
> updates - hardware does not support it. To keep bisectability DTS patches 
> should
> be applied before subsequent ones. It is rebased on today's exynos-drm-next.
> 
> Please be aware that DTS patches has been already applied to samsung-soc tree,
> I left them here to simplify testing on exynos-drm-next, which is not in sync 
> with
> samsung-soc, for this reason I have moved them on the beginning of the 
> patchset.

Got it. I can test it by doing cherry-pick these two patches.

Thanks,
Inki Dae

> 
> Regards
> Andrzej
> 
> 
> Andrzej Hajda (24):
>   arm64: dts: exynos: configure GSCALER related clocks
>   arm64: dts: exynos: add DSD/GSD clocks to DECONs and GSCALERs
>   drm/exynos: remove exynos_drm_plane.h header
>   drm/exynos: remove spare macro
>   drm/exynos: drop exynos_drm_plane_config structure
>   drm/exynos: add exynos_drm_crtc_init function
>   drm/exynos/decon5433: embed exynos_drm_crtc directly into context
>   drm/exynos/decon7: embed exynos_drm_crtc directly into context
>   drm/exynos/fimd: embed exynos_drm_crtc directly into context
>   drm/exynos/mixer: embed exynos_drm_crtc directly into context
>   drm/exynos/vidi: embed exynos_drm_crtc directly into context
>   drm/exynos: remove standalone exynos_drm_crtc leftovers
>   drm/exynos/vidi: remove encoder_to_vidi helper
>   drm/exynos: unify plane type assignment
>   drm/exynos: set primary plane in exynos_drm_crtc_init
>   drm/exynos: set cursor plane in exynos_drm_crtc_init
>   drm/exynos: add plane update/disable callbacks for planes
>   drm/exynos: add GSCALER plane capability
>   drm/exynos/gscaler: fix id assignement
>   drm/exynos/gscaler: add local path support
>   drm/exynos/decon5433: add local path support
>   drm/exynos/decon5433: wait for finish previous update
>   drm/exynos/gscaler: change supported color format BGRX to XBGR
>   drm/exynos/gscaler: fix handling YVU420 pixel format
> 
>  .../dts/exynos/exynos5433-tm2-common.dtsi |   6 +
>  arch/arm64/boot/dts/exynos/exynos5433-tm2.dts |   6 +-
>  arch/arm64/boot/dts/exynos/exynos5433.dtsi|  25 +-
>  drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 162 -
>  drivers/gpu/drm/exynos/exynos7_drm_decon.c|  66 +++--
>  drivers/gpu/drm/exynos/exynos_drm_crtc.c  |  46 ++--
>  drivers/gpu/drm/exynos/exynos_drm_crtc.h  

Re: [PATCH v3 RESEND 00/24] drm/exynos: add support for GSCALER planes on Exynos5433

2019-03-26 Thread Inki Dae


19. 3. 26. 오후 10:51에 Andrzej Hajda 이(가) 쓴 글:
> On 26.03.2019 09:45, Inki Dae wrote:
>> Hi Andrzej,
>>
>> 19. 3. 25. 오후 4:13에 Andrzej Hajda 이(가) 쓴 글:
>>> Hi Inki,
>>>
>>> GSCALERs in Exynos SoCs support conversion between wide range of image 
>>> formats,
>>> plus scaling and rotation.
>>> Driver already supports mem2mem mode - via ExynosDRM IPP framework.
>>> This patchset adds support for mem to display mode - framebuffers can
>>> be converted, scaled and send directly to Display Controller. From DRM
>>> framework's point of view every GSCALER exposes drm_plane which can be 
>>> connected
>>> to display controller (display panel or TV).
>>> The feature is not well documented so the development was quite difficult -
>>> a process of trial and error, vendor code analysis, guessing from 
>>> datasheets.
>>> Hopefully most of the issues were solved. I have developed and tested it on
>>> TM2 device with panel and TV paths.
>>>
>>> The patchset contains three parts:
>>> 1. Preparatory patches - mostly cleanup and refactoring of drm_crtc and 
>>> drm_plane
>>>related structures, to allow usage of planes which are not physically 
>>> bound
>>>to crtcs (01-13).
>>> 2. Adding local path support to GSCALER and DECON (14-20).
>>> 3. Few fixes of bugs existing already in the code but discovered due to 
>>> added
>>>local path support (21-23).
>>>
>>> The patchset is based on exynos_drm_next plus my patchset adding zpos to 
>>> DECON
>>> and FIMD - 'drm/exynos: add support for dynamic zpos in DECON and FIMD' - 
>>> it is
>>> required to allow set z-pos position of GSCALER planes.
>> As for this, we had a discussion before,
>> https://patchwork.kernel.org/cover/10715521/
>>
>> And the last comment I left was,
>> "I know. Your patch will show that plane order is changed by changing 
>> mapping of plane from one window to another window regardless of overlay 
>> priority change support. 
>> I'm not clear but seems maybe we could do more something with your patch 
>> even though DECON/FIMD have limit. So I will enqueue your patch until real 
>> user is fixed."
>>
>> Did you fix TDM module of Tizen which is a real user? Without any 
>> modification of the TDM module, the user doesn't work.
> 
> 
> Last time I have tried to work with Tizen on tm2 the whole system was
> very unstable, the display was black even without my patches, so I gave
> up. If you want to fix TDM in Tizen anyway I can try it again, the only
> problem is that I am currently busy with other tasks, so it can take
> some time to look at Tizen again.
> 

I tested Tizen platform and it worked - I could see launcher UI on screen.
The version I used was tizen-unified_20190322.1_mobile-wayland-armv7l-tm2.tar.
Could you try it again?

Ps. I know you are busy with other works but DRM community wants to take care 
of all real users so we have to follow this. so new ABI or any changes cannot 
be upstreamed without real user who uses this.

Thanks,
Inki Dae

> 
> Regards
> 
> Andrzej
> 
> 
>>
>>> To simplify tests I have also created branch containing all required 
>>> patches:
>>> Repo: https://git.tizen.org/cgit/platform/kernel/linux-exynos
>>> Branch: sandbox/ahajda/dev/exynos-drm-local-path
>>>
>>> This is v2 version of the patchset. In this version I have moved code 
>>> setting
>>> cursor plane in crtc to separate patch together with code disabling fast 
>>> cursor
>>> updates - hardware does not support it. To keep bisectability DTS patches 
>>> should
>>> be applied before subsequent ones. It is rebased on today's exynos-drm-next.
>>>
>>> Please be aware that DTS patches has been already applied to samsung-soc 
>>> tree,
>>> I left them here to simplify testing on exynos-drm-next, which is not in 
>>> sync with
>>> samsung-soc, for this reason I have moved them on the beginning of the 
>>> patchset.
>> Got it. I can test it by doing cherry-pick these two patches.
>>
>> Thanks,
>> Inki Dae
>>
>>> Regards
>>> Andrzej
>>>
>>>
>>> Andrzej Hajda (24):
>>>   arm64: dts: exynos: configure GSCALER related clocks
>>>   arm64: dts: exynos: add DSD/GSD clocks to DECONs and GSCALERs
>>>   drm/exynos: remove exynos_drm_plane.h header
>>>   drm/exynos: remove spare macro
>>>   drm/exynos: dr

Re: [PATCH 08/21] drm/exynos: Use drm_fb_helper_fill_info

2019-03-27 Thread Inki Dae


19. 3. 26. 오후 10:19에 Daniel Vetter 이(가) 쓴 글:
> This will give the exynos fbdev a name!
> 
> v2: Rebase
> 
> Signed-off-by: Daniel Vetter 

Acked-by: Inki Dae 

Thanks,
Inki Dae

> Cc: Inki Dae 
> Cc: Joonyoung Shim 
> Cc: Seung-Woo Kim 
> Cc: Kyungmin Park 
> Cc: Kukjin Kim 
> Cc: Krzysztof Kozlowski 
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-samsung-...@vger.kernel.org
> ---
>  drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c 
> b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> index c30dd88cdb25..581a6a207995 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> @@ -87,11 +87,9 @@ static int exynos_drm_fbdev_update(struct drm_fb_helper 
> *helper,
>   return PTR_ERR(fbi);
>   }
>  
> - fbi->par = helper;
>   fbi->fbops = &exynos_drm_fb_ops;
>  
> - drm_fb_helper_fill_fix(fbi, fb->pitches[0], fb->format->depth);
> - drm_fb_helper_fill_var(fbi, helper, sizes->fb_width, sizes->fb_height);
> + drm_fb_helper_fill_info(fbi, helper, sizes);
>  
>   nr_pages = exynos_gem->size >> PAGE_SHIFT;
>  
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[GIT PULL] exynos-drm-fixes

2019-08-02 Thread Inki Dae
Hi Dave,

   Just two fixups which fixes undefined reference error with NOMMU
   configuration and potential infinite issue of scaler module,
   and two trivial cleanups.

   Please kindly let me know if there is any problem.

Thanks,
Inki Dae

The following changes since commit f8981e0309e9004c6e86d218049045700c79d740:

  Merge tag 'msm-fixes-2019_08_01' of https://gitlab.freedesktop.org/drm/msm 
into drm-fixes (2019-08-02 10:17:25 +1000)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos 
tags/exynos-drm-fixes-for-v5.3-rc3

for you to fetch changes up to 1bbbab097a05276e312dd2462791d32b21ceb1ee:

  drm/exynos: fix missing decrement of retry counter (2019-08-02 16:50:18 +0900)


- Two cleanup patches
  . use dev_get_drvdata for readability instead of platform_get_drvdata
  . remove redundant assignment to node.
- Two fixup patches
  . fix undefined reference to 'vmf_insert_mixed' with NOMMU configuration.
  . fix potential infinite spin issue by decrementing 'retry' variable in
scaler_reset function of exynos_drm_scaler.c


Arnd Bergmann (1):
  drm/exynos: add CONFIG_MMU dependency

Colin Ian King (2):
  drm/exynos: remove redundant assignment to pointer 'node'
  drm/exynos: fix missing decrement of retry counter

Fuqian Huang (1):
  drm/exynos: using dev_get_drvdata directly

 drivers/gpu/drm/exynos/Kconfig | 1 +
 drivers/gpu/drm/exynos/exynos_drm_fimc.c   | 2 +-
 drivers/gpu/drm/exynos/exynos_drm_g2d.c| 2 +-
 drivers/gpu/drm/exynos/exynos_drm_gsc.c| 2 +-
 drivers/gpu/drm/exynos/exynos_drm_scaler.c | 4 ++--
 5 files changed, 6 insertions(+), 5 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Exynos vblank timeout issue

2022-06-03 Thread Inki Dae
Hi Martin,

What kind of panel does Galaxy Note 10.1 use? I guess it uses I80
panel which needs CPU-trigger.
If so, you may need to check if the panel device works correctly after
booting because FIMD will incur vsync timeout if the panel doesn't
work.
I think you could try to check if te signal works or not in
exynos_dsi_te_irq_handler function of exynos_drm_dsi.c

Thanks,
Inki Dae

2022년 5월 27일 (금) 오전 8:34, Martin Jücker 님이 작성:
>
> Hello again,
>
> I tried to dig around a bit to unearth some more information. What I'm
> seeing is that it works just fine in the beginning, planes are updated a
> couple of times and suddenly, after one of the plane updates, the
> interrupt handler in the FIMD driver is no longer called. The screen
> goes dark but the device is still operational, e.g. ADB works fine, I
> can connect and execute commands.
>
> Trying to figure out what is called when and curious about the state of
> the registers, I littered the code with print statements and it looks
> like vsync is still active, no other code calls into disabling it. All
> registers are as expected, e.g. VIDINTCON0 has the interrupt bit set. I
> also had a look at the interrupt combiner, this too has the
> corresponding lcd0-1 interrupt enabled at all times and there is no
> interrupt pending, even after FIMD stopped receiving them.
>
> Looking at the wiki at https://exynos.wiki.kernel.org/todo_tasks I found
> issue #9. It's about trashed display or DMA freeze if planes are too
> narrow and I was wondering if this could be related. So I had a look at
> the drm debug output and planes are indeed getting very small. This
> happens exactly when the animation that is triggering the issue is
> playing, so this would match. Looking a bit closer at the position and
> size of the planes, I could see that the last working vsync was right
> after one of the planes was exactly 1 pixel in width and vsync only
> stopped working one update later. Here are the plane updates from the
> logs:
>
> -
>
> Planes getting smaller and smaller with each update:
> plane : offset_x/y(0,0), width/height(4,800)
> plane : offset_x/y(4,0), width/height(1276,800)
> plane : offset_x/y(0,0), width/height(1280,800)
> plane : offset_x/y(0,776), width/height(1280,24)
>
> plane : offset_x/y(0,0), width/height(2,800)
> plane : offset_x/y(2,0), width/height(1278,800)
> plane : offset_x/y(0,0), width/height(1280,800)
> plane : offset_x/y(0,776), width/height(1280,24)
>
> plane : offset_x/y(0,0), width/height(1,800)
> plane : offset_x/y(1,0), width/height(1279,800)
> plane : offset_x/y(0,0), width/height(1280,800)
> plane : offset_x/y(0,776), width/height(1280,24)
>
> Still got a vsync in between those two. But after the following update,
> it's dead:
> plane : offset_x/y(0,0), width/height(1280,800)
> plane : offset_x/y(0,0), width/height(1280,24)
> plane : offset_x/y(0,740), width/height(1280,60)
> plane : offset_x/y(0,0), width/height(1280,800)
>
> -> vsync timeout comes here
>
> -
>
> I have no idea how to analyze this further on the kernel side. I'll try
> to write an executable that triggers this bug next. If you have any
> ideas on that, I'd be very grateful.
>
> Kind Regards
> Martin
>
> On Sun, May 22, 2022 at 12:06:39PM +0200, Martin Jücker wrote:
> > On Sun, May 22, 2022 at 09:45:51AM +0200, Krzysztof Kozlowski wrote:
> > > On 22/05/2022 02:02, Martin Jücker wrote:
> > > > Hello,
> > > >
> > > > I'm trying to get Android 12 up and running on my Galaxy Note 10.1 which
> > > > is based on Exynos 4412 with a Mali GPU. For Android 11, I had no issues
> > > > with graphics but after upgrading and building Android 12, I'm getting a
> > > > vblank wait timeout shortly after starting the device setup, which in
> > > > turn leads to my display turning black and SurfaceFlinger hanging. This
> > > > can be reliably reproduced after every reboot, so much so that it's
> > > > basically always on the exact same step of the setup.
> > > >
> > > > I'm using the following setup:
> > > >
> > > > * 5.10.101 Android Common Kernel with some patches to get
> > > > the Note 10.1 up and running
> > >
> > > It's Android kernel, so not upstream. It is perfectly fine to use
> > > downstream kernels, but with the issues you also go to downstream folks.
> > > I have no clue what Android did to Exynos.
> >
> > Hi Krzysztof,
> >
> > indeed, that was my mistake. Should have done that on mainline first.
> >
> > I rebased some patches on top of v5.17.9 and tried again, same res

[GIT PULL] exynos-drm-fixes

2022-06-14 Thread Inki Dae
Hi Dave and Daniel,

   Just two regression fixups.

   Please kindly let me know if there is any problem.

Thanks,
Inki Dae

The following changes since commit b13baccc3850ca8b8cccbf8ed9912dbaa0fdf7f3:

  Linux 5.19-rc2 (2022-06-12 16:11:37 -0700)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos 
tags/exynos-drm-fixes-v5.19-rc3

for you to fetch changes up to 7d787184a18f0f84e996de8ff007e4395c1978ea:

  drm/exynos: mic: Rework initialization (2022-06-14 22:32:16 +0900)


two regression fixups
- Check a null pointer instead of IS_ERR().
- Rework initialization code of Exynos MIC driver.


Dan Carpenter (1):
  drm/exynos: fix IS_ERR() vs NULL check in probe

Marek Szyprowski (1):
  drm/exynos: mic: Rework initialization

 drivers/gpu/drm/exynos/exynos_drm_drv.c |  6 ++---
 drivers/gpu/drm/exynos/exynos_drm_mic.c | 42 ++---
 2 files changed, 15 insertions(+), 33 deletions(-)


Re: Exynos vblank timeout issue

2022-06-21 Thread Inki Dae
Hi Martin,

2022년 6월 4일 (토) 오후 8:05, Martin Jücker 님이 작성:
>
> On Sat, Jun 04, 2022 at 01:05:39PM +0900, Inki Dae wrote:
> > Hi Martin,
> >
>
> Hi Inki,
>
> > What kind of panel does Galaxy Note 10.1 use? I guess it uses I80
> > panel which needs CPU-trigger.
>
> the Note 10.1 uses a Samsung LTL101AL01 LCD which is connected via the
> RGB interface.
>
> In the meantime I tried several things but to no avail. Krzysztof
> proposed in IRC to disable devfreq which had no effect. I compared the
> mainline sources with the vendor kernel, but there are no notable
> differences and the parts that were a bit different also didn't solve
> the problem when applied to mainline.
>
> I then tried to reproduce the issue, I noticed that things go wrong as
> soon as I get to planes that are less than 8x8 pixels. There is two
> different issues I can make out:
>
> 1) Active pixels are not what expected, so the plane is 1x4 pixels but
> only two pixels will be visible on the display
> 2) The screen goes dark and the vblank interrupt stops working

Seems malfunctioning of display controller, FIMD device.

>
> The vblank occurs for all planes that are 1x8 or any multiple of it, so
> 1x16, 1x24 as well as planes bigger than 1x279 in size. This is for the
> primary plane. A width of two seems to be fine here.

FIMD device has a limit to DMA burst size. Please see how burst size
is set according to pixel format,
https://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git/tree/drivers/gpu/drm/exynos/exynos_drm_fimd.c?h=exynos-drm-fixes#n660

I think Android platform uses XRGB888 or ARGB888 for framebuffer. In
this case, the burst size - it means the minimum size that FIMD's DMA
controller reads some portion of frame buffer from memory - is 16
words.
So width size should be multiple of the word size.

Could you align the width size of the frame buffer to multiple of 16?
According to your analysis, multiple of 8 would be ok.

Thanks,
Inki Dae

>
> For overlay planes, the situation is worse. All planes of width one will
> trigger a vsync timeout. Also, planes of widths smaller 8 seem to be hit
> and miss, most of them don't work.
>
> The first issue with the wrong number of pixels seems to be for small
> planes less than 8x8 pixels that don't trigger the vsync issue but it's
> more difficult to find a pattern here. It looks like even numbers like
> 4x4, 4x6 are fine but as soon as at least one odd number is present, it
> will go down the drain. 5x6 for example will only display 5x5 pixels,
> 5x5 will display four rows of five pixels and one row with one pixel.
>
> Kind Regards
> Martin
>
>
>
> > If so, you may need to check if the panel device works correctly after
> > booting because FIMD will incur vsync timeout if the panel doesn't
> > work.
> > I think you could try to check if te signal works or not in
> > exynos_dsi_te_irq_handler function of exynos_drm_dsi.c
> >
> > Thanks,
> > Inki Dae
> >
> > 2022년 5월 27일 (금) 오전 8:34, Martin Jücker 님이 작성:
> > >
> > > Hello again,
> > >
> > > I tried to dig around a bit to unearth some more information. What I'm
> > > seeing is that it works just fine in the beginning, planes are updated a
> > > couple of times and suddenly, after one of the plane updates, the
> > > interrupt handler in the FIMD driver is no longer called. The screen
> > > goes dark but the device is still operational, e.g. ADB works fine, I
> > > can connect and execute commands.
> > >
> > > Trying to figure out what is called when and curious about the state of
> > > the registers, I littered the code with print statements and it looks
> > > like vsync is still active, no other code calls into disabling it. All
> > > registers are as expected, e.g. VIDINTCON0 has the interrupt bit set. I
> > > also had a look at the interrupt combiner, this too has the
> > > corresponding lcd0-1 interrupt enabled at all times and there is no
> > > interrupt pending, even after FIMD stopped receiving them.
> > >
> > > Looking at the wiki at https://exynos.wiki.kernel.org/todo_tasks I found
> > > issue #9. It's about trashed display or DMA freeze if planes are too
> > > narrow and I was wondering if this could be related. So I had a look at
> > > the drm debug output and planes are indeed getting very small. This
> > > happens exactly when the animation that is triggering the issue is
> > > playing, so this would match. Looking a bit closer at the position and
> > > size of the planes, I could see that the last working vsync was right
> > > after one o

Re: [PATCH] drm/exynos: fimd: add BGR support for exynos4/5

2022-02-02 Thread Inki Dae
Hi Martin.

Thanks for your contribution,
Inki Dae

22. 1. 30. 07:01에 Martin Jücker 이(가) 쓴 글:
> In the downstream kernels for exynos4 and exynos5 devices, there is an
> undocumented register that controls the order of the RGB output. It can
> be set to either normal order or reversed, which enables BGR support for
> those SoCs.
> 
> This patch enables the BGR support for all the SoCs that were found to
> have at least one device with this logic in the corresponding downstream
> kernels.
> 
> Signed-off-by: Martin Jücker 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_fimd.c | 42 ++--
>  include/video/samsung_fimd.h |  4 +++
>  2 files changed, 44 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> index c735e53939d8..cb632360c968 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> @@ -109,6 +109,7 @@ struct fimd_driver_data {
>   unsigned int has_dp_clk:1;
>   unsigned int has_hw_trigger:1;
>   unsigned int has_trigger_per_te:1;
> + unsigned int has_bgr_support:1;
>  };
>  
>  static struct fimd_driver_data s3c64xx_fimd_driver_data = {
> @@ -138,6 +139,7 @@ static struct fimd_driver_data exynos4_fimd_driver_data = 
> {
>   .lcdblk_bypass_shift = 1,
>   .has_shadowcon = 1,
>   .has_vtsel = 1,
> + .has_bgr_support = 1,
>  };
>  
>  static struct fimd_driver_data exynos5_fimd_driver_data = {
> @@ -149,6 +151,7 @@ static struct fimd_driver_data exynos5_fimd_driver_data = 
> {
>   .has_vidoutcon = 1,
>   .has_vtsel = 1,
>   .has_dp_clk = 1,
> + .has_bgr_support = 1,
>  };
>  
>  static struct fimd_driver_data exynos5420_fimd_driver_data = {
> @@ -162,6 +165,7 @@ static struct fimd_driver_data 
> exynos5420_fimd_driver_data = {
>   .has_vtsel = 1,
>   .has_mic_bypass = 1,
>   .has_dp_clk = 1,
> + .has_bgr_support = 1,
>  };
>  
>  struct fimd_context {
> @@ -226,6 +230,18 @@ static const uint32_t fimd_formats[] = {
>   DRM_FORMAT_ARGB,
>  };
>  
> +static const uint32_t fimd_extended_formats[] = {
> + DRM_FORMAT_C8,
> + DRM_FORMAT_XRGB1555,
> + DRM_FORMAT_XBGR1555,
> + DRM_FORMAT_RGB565,
> + DRM_FORMAT_BGR565,
> + DRM_FORMAT_XRGB,
> + DRM_FORMAT_XBGR,
> + DRM_FORMAT_ARGB,
> + DRM_FORMAT_ABGR,
> +};
> +
>  static const unsigned int capabilities[WINDOWS_NR] = {
>   0,
>   EXYNOS_DRM_PLANE_CAP_WIN_BLEND | EXYNOS_DRM_PLANE_CAP_PIX_BLEND,
> @@ -673,21 +689,25 @@ static void fimd_win_set_pixfmt(struct fimd_context 
> *ctx, unsigned int win,
>   val |= WINCONx_BYTSWP;
>   break;
>   case DRM_FORMAT_XRGB1555:
> + case DRM_FORMAT_XBGR1555:
>   val |= WINCON0_BPPMODE_16BPP_1555;
>   val |= WINCONx_HAWSWP;
>   val |= WINCONx_BURSTLEN_16WORD;
>   break;
>   case DRM_FORMAT_RGB565:
> + case DRM_FORMAT_BGR565:
>   val |= WINCON0_BPPMODE_16BPP_565;
>   val |= WINCONx_HAWSWP;
>   val |= WINCONx_BURSTLEN_16WORD;
>   break;
>   case DRM_FORMAT_XRGB:
> + case DRM_FORMAT_XBGR:
>   val |= WINCON0_BPPMODE_24BPP_888;
>   val |= WINCONx_WSWP;
>   val |= WINCONx_BURSTLEN_16WORD;
>   break;
>   case DRM_FORMAT_ARGB:
> + case DRM_FORMAT_ABGR:
>   default:
>   val |= WINCON1_BPPMODE_25BPP_A1888;
>   val |= WINCONx_WSWP;
> @@ -695,6 +715,18 @@ static void fimd_win_set_pixfmt(struct fimd_context 
> *ctx, unsigned int win,
>   break;
>   }
>  
> + switch (pixel_format) {
> + case DRM_FORMAT_XBGR1555:
> + case DRM_FORMAT_XBGR:
> + case DRM_FORMAT_ABGR:
> + case DRM_FORMAT_BGR565:
> + writel(WIN_RGB_ORDER_REVERSE, ctx->regs + WIN_RGB_ORDER(win));
> + break;
> + default:
> + writel(WIN_RGB_ORDER_FORWARD, ctx->regs + WIN_RGB_ORDER(win));
> + break;
> + }
> +
>   /*
>* Setting dma-burst to 16Word causes permanent tearing for very small
>* buffers, e.g. cursor buffer. Burst Mode switching which based on
> @@ -1074,8 +1106,14 @@ static int fimd_bind(struct device *dev, struct device 
> *master, void *data)
>   ctx->drm_dev = drm_dev;
>  
>   for (i = 0; i < WINDOWS_NR; i++) {
> - ctx->configs[i].pixel_formats = fimd_formats;
> - ctx->configs[i].num_pixel_f

[GIT PULL] exynos-drm-fixes

2022-02-10 Thread Inki Dae
Hi Dave and Daniel,

   Just two fixup series - one is to fix irq chaining issue and other is
   regressions to TE-gpio handling.

Please let me know if there is any problem.

Thanks,
Inki Dae

The following changes since commit dfd42facf1e4ada021b939b4e19c935dcdd55566:

  Linux 5.17-rc3 (2022-02-06 12:20:50 -0800)

are available in the Git repository at:

  gitolite.kernel.org:/pub/scm/linux/kernel/git/daeinki/drm-exynos 
tags/exynos-drm-fixes-for-v5.17-rc4

for you to fetch changes up to 38103fa72e0b70e3067fed489f8316dc5998f26c:

  drm/exynos: Search for TE-gpio in DSI panel's node (2022-02-10 19:17:22 +0900)


Fixups
- Make display controller drivers for Exynos series to use platform_get_irq
  and platform_get_irq_byname functions to get the interrupt, which prevents
  irq chaining from messed up when using hierarchical interrupt domains
  which use "interrupts" property in the node.
- Fix two regressions to TE-gpio handling.


Lad Prabhakar (5):
  drm/exynos/exynos7_drm_decon: Use platform_get_irq_byname() to get the 
interrupt
  drm/exynos: mixer: Use platform_get_irq() to get the interrupt
  drm/exynos/exynos_drm_fimd: Use platform_get_irq_byname() to get the 
interrupt
  drm/exynos/fimc: Use platform_get_irq() to get the interrupt
  drm/exynos: gsc: Use platform_get_irq() to get the interrupt

Marek Szyprowski (2):
  drm/exynos: Don't fail if no TE-gpio is defined for DSI driver
  drm/exynos: Search for TE-gpio in DSI panel's node

 drivers/gpu/drm/exynos/exynos7_drm_decon.c | 12 +++-
 drivers/gpu/drm/exynos/exynos_drm_dsi.c|  6 --
 drivers/gpu/drm/exynos/exynos_drm_fimc.c   | 13 +
 drivers/gpu/drm/exynos/exynos_drm_fimd.c   | 13 -
 drivers/gpu/drm/exynos/exynos_drm_gsc.c| 10 +++---
 drivers/gpu/drm/exynos/exynos_mixer.c  | 14 ++
 6 files changed, 25 insertions(+), 43 deletions(-)


Re: [PATCH] drm/exynos: fix IS_ERR() vs NULL check in probe

2022-04-20 Thread Inki Dae
Hi,

22. 4. 12. 13:19에 Dan Carpenter 이(가) 쓴 글:
> On Tue, Apr 12, 2022 at 10:01:20AM +0900, Inki Dae wrote:
>> Hi Dan Carpenter.
>>
>> Same patch[1] was posted so I will pick it up. 
>>
>> [1] 
>> https://protect2.fireeye.com/v1/url?k=94e9d569-f562c05f-94e85e26-000babff9b5d-4d4f5b20cfffa24c&q=1&e=727c2c54-2082-4e0f-87d7-c6702bf4c81e&u=https%3A%2F%2Fwww.spinics.net%2Flists%2Farm-kernel%2Fmsg967488.html
>>  
>>
> 
> It's not the same.  That one returns -EINVAL and mine returns
> -EPROBE_DEFER.  I obvoiously thought that -EPROBE_DEFER was the correct
> return but I wasn't positive.  -EPROBE_DEFER is kind of a special
> return so I think it matters to get this correct.
> 

Correct so I requested[1] him to fix it but the delivery failed. :( I will just 
pick your patch up. :)
[Delivery Failure] Re: [PATCH -next] drm/exynos: mic: fix return value check in 
exynos_mic_probe().

[1] My email sent below,

22. 4. 6. 18:22에 Yang Yingliang 이(가) 쓴 글:
 > If of_graph_get_remote_node() fails, it returns NULL pointer, replaces
 > IS_ERR() check with NULL pointer check.
 >
 > Fixes: dd8b6803bc49 ("exynos: drm: dsi: Attach in_bridge in MIC driver")
 > Reported-by: Hulk Robot 
 > Signed-off-by: Yang Yingliang 
 > ---
 > drivers/gpu/drm/exynos/exynos_drm_mic.c | 4 ++--
 > 1 file changed, 2 insertions(+), 2 deletions(-)
 >
 > diff --git a/drivers/gpu/drm/exynos/exynos_drm_mic.c 
b/drivers/gpu/drm/exynos/exynos_drm_mic.c
 > index 9e06f8e2a863..43fc357a6682 100644
 > --- a/drivers/gpu/drm/exynos/exynos_drm_mic.c
 > +++ b/drivers/gpu/drm/exynos/exynos_drm_mic.c
 > @@ -434,9 +434,9 @@ static int exynos_mic_probe(struct platform_device *pdev)
 >
 > remote = of_graph_get_remote_node(dev->of_node, 1, 0);
 > mic->next_bridge = of_drm_find_bridge(remote);
 > - if (IS_ERR(mic->next_bridge)) {
 > + if (!mic->next_bridge) {
 > DRM_DEV_ERROR(dev, "mic: Failed to find next bridge\n");
 > - ret = PTR_ERR(mic->next_bridge);
 > + ret = -EINVAL;

-EPROBE_DEFER should be returned instead. Could you modify and resend it again?

> regards,
> dan carpenter
> 
> 


Re: [PATCH] drm/exynos: fix repeated words in comments

2022-08-24 Thread Inki Dae
Hi,

2022년 8월 23일 (화) 오후 10:37, Robin Murphy 님이 작성:
>
> On 2022-08-23 13:21, Jilin Yuan wrote:
> >   Delete the redundant word 'next'.
>
>  From the context, I'm not sure it is redundant - as far as I can tell
> this comment seems to be describing a sequence of 3 commands, where
> "current" is the first, "next" is the second, and "next next" implies
> the third. The whole comment could certainly be reworded more clearly,
> but as it stands I suspect a replacement like s/next next/next+1/ is
> more likely to be correct.
>

"next next" is correct. :) As you said, "next next" could be reworded
more clearly. As of now, the original sentence could make it
confusing.

Thanks,
Inki Dae

> Robin.
>
> > Signed-off-by: Jilin Yuan 
> > ---
> >   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 471fd6c8135f..4f9edca66632 100644
> > --- a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
> > +++ b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
> > @@ -1195,7 +1195,7 @@ int exynos_g2d_set_cmdlist_ioctl(struct drm_device 
> > *drm_dev, void *data,
> >* If don't clear SFR registers, the cmdlist is affected by register
> >* values of previous cmdlist. G2D hw executes SFR clear command and
> >* a next command at the same time then the next command is ignored 
> > and
> > -  * is executed rightly from next next command, so needs a dummy 
> > command
> > +  * is executed rightly from next command, so needs a dummy command
> >* to next command of SFR clear command.
> >*/
> >   cmdlist->data[cmdlist->last++] = G2D_SOFT_RESET;


Re: [PATCH] drm/exynos: mic: Rework initialization

2022-05-15 Thread Inki Dae
Hi Marek,

22. 5. 13. 17:31에 Marek Szyprowski 이(가) 쓴 글:
> Commit dd8b6803bc49 ("exynos: drm: dsi: Attach in_bridge in MIC driver")
> moved Exynos MIC attaching from DSI to MIC driver. However the method
> proposed there is incomplete and cannot really work. To properly attach
> it to the bridge chain, access to the respective encoder is needed. The
> Exynos MIC driver always attaches to the encoder created by the Exynos
> DSI driver, so grab it via available helpers for getting access to the
> CRTC and encoders. This also requires to change the order of driver
> component binding to let DSI to be bound before MIC.
> 
> Fixes: dd8b6803bc49 ("exynos: drm: dsi: Attach in_bridge in MIC driver")
> Signed-off-by: Marek Szyprowski 
> ---
> A few words of comment. The mentioned commit has my Tested-by tag and
> indeed I gave it. However that time due to remote work and incorrect
> camera configuration in the office I was not able to check if the board
> really produces valid display, I only checked if it boots and reports
> valid DRM structures to the userspace.
> 
> If possible, please merge this to the drm-misc-next together with the
> rest of Exynos DSI to drm bridge rework patches.

The commit-id, dd8b6803bc49, has already been merged to drm-next. Seems no need 
to go drm-misc-next.
So I will merge it as a regression fix after the review, which will be merged 
to 5.19-rc series.
Please let me know if there is my missing something.

Thanks,
Inki Dae

> ---
>  drivers/gpu/drm/exynos/exynos_drm_drv.c |  6 ++--
>  drivers/gpu/drm/exynos/exynos_drm_mic.c | 42 +++--
>  2 files changed, 15 insertions(+), 33 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
> b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> index 424ea23eec32..16c539657f73 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> @@ -176,15 +176,15 @@ static struct exynos_drm_driver_info 
> exynos_drm_drivers[] = {
>   }, {
>   DRV_PTR(mixer_driver, CONFIG_DRM_EXYNOS_MIXER),
>   DRM_COMPONENT_DRIVER
> - }, {
> - DRV_PTR(mic_driver, CONFIG_DRM_EXYNOS_MIC),
> - DRM_COMPONENT_DRIVER
>   }, {
>   DRV_PTR(dp_driver, CONFIG_DRM_EXYNOS_DP),
>   DRM_COMPONENT_DRIVER
>   }, {
>   DRV_PTR(dsi_driver, CONFIG_DRM_EXYNOS_DSI),
>   DRM_COMPONENT_DRIVER
> + }, {
> + DRV_PTR(mic_driver, CONFIG_DRM_EXYNOS_MIC),
> + DRM_COMPONENT_DRIVER
>   }, {
>   DRV_PTR(hdmi_driver, CONFIG_DRM_EXYNOS_HDMI),
>   DRM_COMPONENT_DRIVER
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_mic.c 
> b/drivers/gpu/drm/exynos/exynos_drm_mic.c
> index 9e06f8e2a863..09ce28ee08d9 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_mic.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_mic.c
> @@ -26,6 +26,7 @@
>  #include 
>  
>  #include "exynos_drm_drv.h"
> +#include "exynos_drm_crtc.h"
>  
>  /* Sysreg registers for MIC */
>  #define DSD_CFG_MUX  0x1004
> @@ -100,9 +101,7 @@ struct exynos_mic {
>  
>   bool i80_mode;
>   struct videomode vm;
> - struct drm_encoder *encoder;
>   struct drm_bridge bridge;
> - struct drm_bridge *next_bridge;
>  
>   bool enabled;
>  };
> @@ -229,8 +228,6 @@ static void mic_set_reg_on(struct exynos_mic *mic, bool 
> enable)
>   writel(reg, mic->reg + MIC_OP);
>  }
>  
> -static void mic_disable(struct drm_bridge *bridge) { }
> -
>  static void mic_post_disable(struct drm_bridge *bridge)
>  {
>   struct exynos_mic *mic = bridge->driver_private;
> @@ -297,34 +294,30 @@ static void mic_pre_enable(struct drm_bridge *bridge)
>   mutex_unlock(&mic_mutex);
>  }
>  
> -static void mic_enable(struct drm_bridge *bridge) { }
> -
> -static int mic_attach(struct drm_bridge *bridge,
> -   enum drm_bridge_attach_flags flags)
> -{
> - struct exynos_mic *mic = bridge->driver_private;
> -
> - return drm_bridge_attach(bridge->encoder, mic->next_bridge,
> -  &mic->bridge, flags);
> -}
> -
>  static const struct drm_bridge_funcs mic_bridge_funcs = {
> - .disable = mic_disable,
>   .post_disable = mic_post_disable,
>   .mode_set = mic_mode_set,
>   .pre_enable = mic_pre_enable,
> - .enable = mic_enable,
> - .attach = mic_attach,
>  };
>  
>  static int exynos_mic_bind(struct device *dev, struct device *master,
>  void *data)
>  {
>   struct exynos_mic *mic = dev_get_drvdata(dev);
> + struct dr

  1   2   3   4   5   6   7   8   9   10   >