Re: [PATCH] drm/mediatek: check for comp->funcs

[CK Hu]

Hi, Hsin-yi:

On Thu, 2020-01-09 at 15:29 +0800, Hsin-Yi Wang wrote:
> There might be some comp that doesn't have funcs, eg. hdmi-connector.
> Check for comp->funcs otherwise there will be NULL pointer dereference
> crash.
> 
> Fixes: bd3de8cd782b ("drm/mediatek: Add gamma property according to hardware 
> capability")
> Fixes: 7395eab077f9 ("drm/mediatek: Add ctm property support")

Because the fixed patches are still in my tree, so I merge this patch
with the fixed patches in mediatek-drm-next-5.6 [1].

[1]
https://github.com/ckhu-mediatek/linux.git-tags/commits/mediatek-drm-next-5.6

Regards,
CK

> Signed-off-by: Hsin-Yi Wang 
> ---
> This patch is based on mediatek's drm branch:
> https://github.com/ckhu-mediatek/linux.git-tags/commits/mediatek-drm-next-5.6
> 
> After
> https://patchwork.freedesktop.org/patch/344477/?series=63328=59,
> there will also be funcs for hdmi-connector.
> ---
>  drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 10 ++
>  1 file changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c 
> b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> index fb142fcfc353..7b392d6c71cc 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> @@ -808,11 +808,13 @@ int mtk_drm_crtc_create(struct drm_device *drm_dev,
>  
>   mtk_crtc->ddp_comp[i] = comp;
>  
> - if (comp->funcs->ctm_set)
> - has_ctm = true;
> + if (comp->funcs) {
> + if (comp->funcs->ctm_set)
> + has_ctm = true;
>  
> - if (comp->funcs->gamma_set)
> - gamma_lut_size = MTK_LUT_SIZE;
> + if (comp->funcs->gamma_set)
> + gamma_lut_size = MTK_LUT_SIZE;
> + }
>   }
>  
>   for (i = 0; i < mtk_crtc->ddp_comp_nr; i++)

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

[PATCH] drm/v3d: Fix a double free in the ioctl

[Dan Carpenter]

This code used to leak "bin" but then we accidentally merged two fixes
so now it's a double free.

Fixes: 77e0723bd27f ("Merge v5.4-rc7 into drm-next")
Signed-off-by: Dan Carpenter 
---
 drivers/gpu/drm/v3d/v3d_gem.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/v3d/v3d_gem.c b/drivers/gpu/drm/v3d/v3d_gem.c
index 549dde83408b..37515e47b47e 100644
--- a/drivers/gpu/drm/v3d/v3d_gem.c
+++ b/drivers/gpu/drm/v3d/v3d_gem.c
@@ -568,7 +568,6 @@ v3d_submit_cl_ioctl(struct drm_device *dev, void *data,
ret = v3d_job_init(v3d, file_priv, >base,
   v3d_job_free, args->in_sync_bcl);
if (ret) {
-   kfree(bin);
v3d_job_put(>base);
kfree(bin);
return ret;
-- 
2.11.0

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

Re: [PATCH -next] drm/mgag200: Fix typo in parameter description

[Dan Carpenter]

On Fri, Jan 10, 2020 at 01:25:23AM +, Wei Yongjun wrote:
> Fix typo in parameter description.
> 

This commit message isn't totally clear.  Maybe say something like:

There was a typo in the MODULE_PARM_DESC().  It said that the module
parameter was "modeset" but it's actually the description for
"hw_bug_no_startadd".

> Fixes: 3cacb2086e41 ("drm/mgag200: Add module parameter to pin all buffers at 
> offset 0")
> Signed-off-by: Wei Yongjun 

regards,
dan carpenter

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

[PATCH libdrm] meson.build: Don't detect header for linux

[Seung-Woo Kim]

The  header is not required for Linux and GNU libc
2.30 starts to warn about Linux specific  header
deprecation. Don't detect  header for linux.

Signed-off-by: Seung-Woo Kim 
---
Fix meson.build script instead of code itself as commented below:
https://patchwork.kernel.org/patch/11325345/
---
 meson.build |   15 +++
 1 files changed, 11 insertions(+), 4 deletions(-)

diff --git a/meson.build b/meson.build
index 782b1a3..b1c557a 100644
--- a/meson.build
+++ b/meson.build
@@ -183,10 +183,17 @@ else
   dep_rt = []
 endif
 dep_m = cc.find_library('m', required : false)
-# From Niclas Zeising:
-# FreeBSD requires sys/types.h for sys/sysctl.h, add it as part of the
-# includes when checking for headers.
-foreach header : ['sys/sysctl.h', 'sys/select.h', 'alloca.h']
+if not ['linux'].contains(host_machine.system())
+  # From Niclas Zeising:
+  # FreeBSD requires sys/types.h for sys/sysctl.h, add it as part of the
+  # includes when checking for headers.
+  foreach header : ['sys/sysctl.h']
+config.set('HAVE_' + header.underscorify().to_upper(),
+  cc.compiles('#include \n#include <@0@>'.format(header), 
name : '@0@ works'.format(header)))
+  endforeach
+endif
+endforeach
+foreach header : ['sys/select.h', 'alloca.h']
   config.set('HAVE_' + header.underscorify().to_upper(),
 cc.compiles('#include \n#include <@0@>'.format(header), name 
: '@0@ works'.format(header)))
 endforeach
-- 
1.7.4.1

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

[git pull] drm fixes for 5.5-rc6

[Dave Airlie]

Hi Linus,

Pre-LCA pull request I'm not sure how things will look next week,
myself and Daniel are at LCA and I'm speaking quite late, so if I get
my talk finished I'll probably process fixes.

This week has a bunch of i915 fixes, some amdgpu fixes, one sun4i, one
core MST, and one core fb_helper fix. More details are below.

Regards,
Dave.


drm-fixes-2020-01-10:
drm fixes for 5.5-rc6

core:
- mst Fix NO_STOP_BIT bit offset (Wayne)

fb_helper:
- fb_helper: Fix bits_per_pixel param set behavior to round up (Geert)

sun4i:
- Fix RGB_DIV clock min divider on old hardware (Chen-Yu)

amdgpu:
- Stability fix for raven
- Reduce pixel encoding to if max clock is exceeded on HDMI
  to allow additional high res modes
- enable DRIVER_SYNCOBJ_TIMELINE for amdgpu

i915:
- Fix GitLab issue #446 causing GPU hangs: Do not restore invalid RS state
- Fix GitLab issue #846: Restore coarse power gating that was disabled
  by initial RC66 context corruption security fixes.
- Revert f6ec9483091f ("drm/i915: extend audio CDCLK>=2*BCLK
constraint to more platforms")
  to avoid screen flicker
- Fix to fill in unitialized uabi_instance in virtual engine uAPI
- Add two missing W/As for ICL and EHL
The following changes since commit c79f46a282390e0f5b306007bf7b11a46d529538:

  Linux 5.5-rc5 (2020-01-05 14:23:27 -0800)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2020-01-10

for you to fetch changes up to 023b3b0e139f54a680202790ba801f61aa43a5c8:

  Merge tag 'drm-intel-fixes-2020-01-09-1' of
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes (2020-01-10
11:43:02 +1000)


drm fixes for 5.5-rc6

core:
- mst Fix NO_STOP_BIT bit offset (Wayne)

fb_helper:
- fb_helper: Fix bits_per_pixel param set behavior to round up (Geert)

sun4i:
- Fix RGB_DIV clock min divider on old hardware (Chen-Yu)

amdgpu:
- Stability fix for raven
- Reduce pixel encoding to if max clock is exceeded on HDMI
  to allow additional high res modes
- enable DRIVER_SYNCOBJ_TIMELINE for amdgpu

i915:
- Fix GitLab issue #446 causing GPU hangs: Do not restore invalid RS state
- Fix GitLab issue #846: Restore coarse power gating that was disabled
  by initial RC66 context corruption security fixes.
- Revert f6ec9483091f ("drm/i915: extend audio CDCLK>=2*BCLK
constraint to more platforms")
  to avoid screen flicker
- Fix to fill in unitialized uabi_instance in virtual engine uAPI
- Add two missing W/As for ICL and EHL


Alex Deucher (1):
  Revert "drm/amdgpu: Set no-retry as default."

Chen-Yu Tsai (1):
  drm/sun4i: tcon: Set RGB DCLK min. divider based on hardware model

Chris Wilson (3):
  drm/i915/gt: Mark up virtual engine uabi_instance
  drm/i915/gt: Do not restore invalid RS state
  drm/i915/gt: Restore coarse power gating

Chunming Zhou (1):
  drm/amdgpu: add DRIVER_SYNCOBJ_TIMELINE to amdgpu

Dave Airlie (3):
  Merge tag 'drm-misc-fixes-2020-01-08' of
git://anongit.freedesktop.org/drm/drm-misc into drm-fixes
  Merge tag 'amd-drm-fixes-5.5-2020-01-08' of
git://people.freedesktop.org/~agd5f/linux into drm-fixes
  Merge tag 'drm-intel-fixes-2020-01-09-1' of
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes

Geert Uytterhoeven (1):
  drm/fb-helper: Round up bits_per_pixel if possible

Kai Vehmanen (1):
  drm/i915: Limit audio CDCLK>=2*BCLK constraint back to GLK only

Manasi Navare (1):
  drm/i915/dp: Disable Port sync mode correctly on teardown

Matt Roper (2):
  drm/i915: Add Wa_1408615072 and Wa_1407596294 to icl,ehl
  drm/i915: Add Wa_1407352427:icl,ehl

Thomas Anderson (1):
  drm/amd/display: Reduce HDMI pixel encoding if max clock is exceeded

Wayne Lin (1):
  drm/dp_mst: correct the shifting in DP_REMOTE_I2C_READ

 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c   |  7 ++--
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 45 ---
 drivers/gpu/drm/drm_dp_mst_topology.c |  2 +-
 drivers/gpu/drm/drm_fb_helper.c   |  7 +++-
 drivers/gpu/drm/i915/display/intel_audio.c|  4 +-
 drivers/gpu/drm/i915/display/intel_display.c  |  7 +---
 drivers/gpu/drm/i915/gt/intel_lrc.c   |  2 +
 drivers/gpu/drm/i915/gt/intel_ring_submission.c   | 31 ++--
 drivers/gpu/drm/i915/i915_drv.h   |  6 ++-
 drivers/gpu/drm/i915/i915_reg.h   |  8 +++-
 drivers/gpu/drm/i915/intel_pm.c   | 11 ++
 drivers/gpu/drm/sun4i/sun4i_tcon.c| 15 ++--
 drivers/gpu/drm/sun4i/sun4i_tcon.h|  1 +
 13 files changed, 85 insertions(+), 61 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/panfrost: Remove core stack power management

[Nicolas Boichat]

On Thu, Jan 9, 2020 at 9:44 PM Alyssa Rosenzweig
 wrote:
>
> A-b
>
> On Thu, Jan 09, 2020 at 01:31:04PM +, Steven Price wrote:
> > Explict management of the GPU's core stacks is only necessary in the
> > case of a broken integration with the PDC. Since there are no known
> > platforms which have such a broken integration let's remove the explict
> > control from the driver since this apparently causes problems on other
> > platforms and will have a small performance penality.
> >
> > The out of tree mali_kbase driver contains this text regarding
> > controlling the core stack (CONFIGMALI_CORESTACK):
> >
> >   Enabling this feature on supported GPUs will let the driver powering
> >   on/off the GPU core stack independently without involving the Power
> >   Domain Controller. This should only be enabled on platforms which
> >   integration of the PDC to the Mali GPU is known to be problematic.
> >   This feature is currently only supported on t-Six and t-HEx GPUs.
> >
> >   If unsure, say N.
> >

Work on my G-72 Bifrost, no more errors on power on!

Reviewed-by: Nicolas Boichat 
Tested-by: Nicolas Boichat 

> > Signed-off-by: Steven Price 
> > ---
> >  drivers/gpu/drm/panfrost/panfrost_gpu.c | 5 -
> >  1 file changed, 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/panfrost/panfrost_gpu.c 
> > b/drivers/gpu/drm/panfrost/panfrost_gpu.c
> > index 8822ec13a0d6..460fc190de6e 100644
> > --- a/drivers/gpu/drm/panfrost/panfrost_gpu.c
> > +++ b/drivers/gpu/drm/panfrost/panfrost_gpu.c
> > @@ -309,10 +309,6 @@ void panfrost_gpu_power_on(struct panfrost_device 
> > *pfdev)
> >   ret = readl_relaxed_poll_timeout(pfdev->iomem + L2_READY_LO,
> >   val, val == pfdev->features.l2_present, 100, 1000);
> >
> > - gpu_write(pfdev, STACK_PWRON_LO, pfdev->features.stack_present);
> > - ret |= readl_relaxed_poll_timeout(pfdev->iomem + STACK_READY_LO,
> > - val, val == pfdev->features.stack_present, 100, 1000);
> > -
> >   gpu_write(pfdev, SHADER_PWRON_LO, pfdev->features.shader_present);
> >   ret |= readl_relaxed_poll_timeout(pfdev->iomem + SHADER_READY_LO,
> >   val, val == pfdev->features.shader_present, 100, 1000);
> > @@ -329,7 +325,6 @@ void panfrost_gpu_power_off(struct panfrost_device 
> > *pfdev)
> >  {
> >   gpu_write(pfdev, TILER_PWROFF_LO, 0);
> >   gpu_write(pfdev, SHADER_PWROFF_LO, 0);
> > - gpu_write(pfdev, STACK_PWROFF_LO, 0);
> >   gpu_write(pfdev, L2_PWROFF_LO, 0);
> >  }
> >
> > --
> > 2.20.1
> >
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 5/7] drm/panfrost: Add support for multiple power domain support

[Nicolas Boichat]

+Ulf to keep me honest on the power domains

On Thu, Jan 9, 2020 at 10:08 PM Steven Price  wrote:
>
> On 08/01/2020 05:23, Nicolas Boichat wrote:
> > When there is a single power domain per device, the core will
> > ensure the power domains are all switched on.
> >
> > However, when there are multiple ones, as in MT8183 Bifrost GPU,
> > we need to handle them in driver code.
> >
> >
> > Signed-off-by: Nicolas Boichat 
> > ---
> >
> > The downstream driver we use on chromeos-4.19 currently uses 2
> > additional devices in device tree to accomodate for this [1], but
> > I believe this solution is cleaner.
>
> I'm not sure what is best, but it seems odd to encode this into the Panfrost 
> driver itself - it doesn't have any knowledge of what to do with these power 
> domains. The naming of the domains looks suspiciously like someone thought 
> that e.g. only half of the cores could be powered, but it doesn't look like 
> that was implemented in the chromeos driver linked and anyway that is *meant* 
> to be automatic in the hardware! (I.e. if you only power up one cores in one 
> core stack then the PDC should only enable the power domain for that set of 
> cores).

This is actually implemented in the Chrome OS driver [1]. IMHO power
domains are a bit confusing [2]:
 i. If there's only 1 power domain in the device, then the core takes
care of power on the domain (based on pm_runtime)
 ii. If there's more than 1 power domain, then the device needs to
link the domains manually.

So the Chrome OS [1] driver takes approach (i), by creating 3 devices,
each with 1 power domain that is switched on/off automatically using
pm_runtime.

This patch takes approach (ii) with device links to handle the extra domains.

I believe the latter is more upstream-friendly, but, as always,
suggestions welcome.

[2] 
https://elixir.bootlin.com/linux/latest/source/drivers/base/power/domain.c#L2466

> Steve
>
> >
> > [1] 
> > https://chromium.googlesource.com/chromiumos/third_party/kernel/+/refs/heads/chromeos-4.19/drivers/gpu/arm/midgard/platform/mediatek/mali_kbase_runtime_pm.c#31
> >
> > drivers/gpu/drm/panfrost/panfrost_device.c | 87 --
> >   drivers/gpu/drm/panfrost/panfrost_device.h |  4 +
> >   2 files changed, 83 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/panfrost/panfrost_device.c 
> > b/drivers/gpu/drm/panfrost/panfrost_device.c
> > index a0b0a6fef8b4e63..c6e9e059de94a4d 100644
> > --- a/drivers/gpu/drm/panfrost/panfrost_device.c
> > +++ b/drivers/gpu/drm/panfrost/panfrost_device.c
> > @@ -5,6 +5,7 @@
> >   #include 
> >   #include 
> >   #include 
> > +#include 
> >   #include 
> >
> >   #include "panfrost_device.h"
> > @@ -131,6 +132,67 @@ static void panfrost_regulator_fini(struct 
> > panfrost_device *pfdev)
> >   regulator_disable(pfdev->regulator_sram);
> >   }
> >
> > +static void panfrost_pm_domain_fini(struct panfrost_device *pfdev)
> > +{
> > + int i;
> > +
> > + for (i = 0; i < ARRAY_SIZE(pfdev->pm_domain_devs); i++) {
> > + if (!pfdev->pm_domain_devs[i])
> > + break;
> > +
> > + if (pfdev->pm_domain_links[i])
> > + device_link_del(pfdev->pm_domain_links[i]);
> > +
> > + dev_pm_domain_detach(pfdev->pm_domain_devs[i], true);
> > + }
> > +}
> > +
> > +static int panfrost_pm_domain_init(struct panfrost_device *pfdev)
> > +{
> > + int err;
> > + int i, num_domains;
> > +
> > + num_domains = of_count_phandle_with_args(pfdev->dev->of_node,
> > +  "power-domains",
> > +  "#power-domain-cells");
> > + /* Single domains are handled by the core. */
> > + if (num_domains < 2)
> > + return 0;
> > +
> > + if (num_domains > ARRAY_SIZE(pfdev->pm_domain_devs)) {
> > + dev_err(pfdev->dev, "Too many pm-domains: %d\n", num_domains);
> > + return -EINVAL;
> > + }
> > +
> > + for (i = 0; i < num_domains; i++) {
> > + pfdev->pm_domain_devs[i] =
> > + dev_pm_domain_attach_by_id(pfdev->dev, i);
> > + if (IS_ERR(pfdev->pm_domain_devs[i])) {
> > + err = PTR_ERR(pfdev->pm_domain_devs[i]);
> > + pfdev->pm_domain_devs[i] = NULL;
> > + dev_err(pfdev->dev,
> > + "failed to get pm-domain %d: %d\n", i, err);
> > + goto err;
> > + }
> > +
> > + pfdev->pm_domain_links[i] = device_link_add(pfdev->dev,
> > + pfdev->pm_domain_devs[i], DL_FLAG_PM_RUNTIME |
> > + DL_FLAG_STATELESS | DL_FLAG_RPM_ACTIVE);
> > + if (!pfdev->pm_domain_links[i]) {
> > + dev_err(pfdev->pm_domain_devs[i],
> > + "adding device link failed!\n");
> > + err = -ENODEV;
> > +

Re: [PATCH] xf86drm: only include for FreeBSD build case

[Seung-Woo Kim]

Hi

On 2020년 01월 10일 00:28, Niclas Zeising wrote:
> On 2020-01-09 16:18, Jani Nikula wrote:
>> On Thu, 09 Jan 2020, Seung-Woo Kim  wrote:
>>> The  header is only required FreeBSD and GNU libc
>>> 2.30 starts to warn about Linux specific  header
>>> deprecation. Only include  for FreeBSD.
>>>
>>> Signed-off-by: Seung-Woo Kim 
>>> ---
>>>   xf86drmMode.c |2 ++
>>>   1 files changed, 2 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/xf86drmMode.c b/xf86drmMode.c
>>> index 207d7be..ff1d31d 100644
>>> --- a/xf86drmMode.c
>>> +++ b/xf86drmMode.c
>>> @@ -42,9 +42,11 @@
>>>   #include 
>>>   #include 
>>>   #include 
>>> +#if defined (__FreeBSD__) || defined (__FreeBSD_kernel__)
>>>   #ifdef HAVE_SYS_SYSCTL_H
>>
>> Not that I know anything about this, but shouldn't you instead fix
>> HAVE_SYS_SYSCTL_H definition in configure stage to only be enabled on
>> FreeBSD?
>>
>> BR,
>> Jani.
>>
>>>   #include 
>>>   #endif
>>> +#endif /* defined (__FreeBSD__) || defined (__FreeBSD_kernel__) */
>>>   #include 
>>>   #include 
>>
> 
> Hi!
> This fix looks OK on FreeBSD (I haven't had time to test), however, as
> has been pointed out, perhaps the change should go into the meson build
> script or configure instead.

Ok, I will try to fix in build side instead of include itself.

> I don't know if other OSes (other BSDs primarily) need this as well. I'm
> pretty sure it's needed on DragonflyBSD at least.
> Perhaps keep the include for everything except Linux for the time being?

As far as I checked, sysctlbyname() called only with FreeBSD build flag
is only function defined in  at least for xf86drmMode.c,
but I missed something. The header deprecation is done from Linux, so it
seems fine removing the header include only for Linux.

Best Regards,
- Seung-Woo Kim

> Regards

-- 
Seung-Woo Kim
Samsung Research
--

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

Re: [PATCH] xf86drm: only include for FreeBSD build case

[Seung-Woo Kim]

Hi,

On 2020년 01월 10일 00:18, Jani Nikula wrote:
> On Thu, 09 Jan 2020, Seung-Woo Kim  wrote:
>> The  header is only required FreeBSD and GNU libc
>> 2.30 starts to warn about Linux specific  header
>> deprecation. Only include  for FreeBSD.
>>
>> Signed-off-by: Seung-Woo Kim 
>> ---
>>  xf86drmMode.c |2 ++
>>  1 files changed, 2 insertions(+), 0 deletions(-)
>>
>> diff --git a/xf86drmMode.c b/xf86drmMode.c
>> index 207d7be..ff1d31d 100644
>> --- a/xf86drmMode.c
>> +++ b/xf86drmMode.c
>> @@ -42,9 +42,11 @@
>>  #include 
>>  #include 
>>  #include 
>> +#if defined (__FreeBSD__) || defined (__FreeBSD_kernel__)
>>  #ifdef HAVE_SYS_SYSCTL_H
> 
> Not that I know anything about this, but shouldn't you instead fix
> HAVE_SYS_SYSCTL_H definition in configure stage to only be enabled on
> FreeBSD?

That seems better even in the xf86drmMode.c,  is required
for sysctlbyname() called from drmCheckModesettingSupported() with
FeeBSD build macro.

Unfortunately, I am not the meson build expert so if there is someone to
fix, then I am okay. Anyway, I will try to fix with HAVE_SYS_SYSCTL_H.

Best Regards,
- Seung-Woo Kim

> 
> BR,
> Jani.
> 
>>  #include 
>>  #endif
>> +#endif /* defined (__FreeBSD__) || defined (__FreeBSD_kernel__) */
>>  #include 
>>  #include 
> 

-- 
Seung-Woo Kim
Samsung Research
--

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

[radeon-alex:amd-19.50 1962/2687] include/kcl/kcl_drm.h:191:9: error: too few arguments to function 'drm_encoder_init'

[kbuild test robot]

Hi Yifan,

FYI, the error/warning still remains.

tree:   git://people.freedesktop.org/~agd5f/linux.git amd-19.50
head:   02692309efa6ad48d47894e40fcb3832ace49c4c
commit: 35781c0b8d19ed0d1bdb8cfa85780841ea7985ff [1962/2687] drm/amdkcl: Test 
whether drm_encoder_init() wants name
config: i386-allyesconfig (attached as .config)
compiler: gcc-7 (Debian 7.5.0-3) 7.5.0
reproduce:
git checkout 35781c0b8d19ed0d1bdb8cfa85780841ea7985ff
# save the attached .config to linux build tree
make ARCH=i386 

If you fix the issue, kindly add following tag
Reported-by: kbuild test robot 

All errors (new ones prefixed by >>):

   In file included from drivers/gpu/drm/ttm/backport/backport.h:6:0,
from :0:
   include/kcl/kcl_drm.h:98:1: error: conflicting types for 
'drm_fb_helper_remove_conflicting_framebuffers'
drm_fb_helper_remove_conflicting_framebuffers(struct apertures_struct *a,
^
   In file included from include/kcl/kcl_drm.h:7:0,
from drivers/gpu/drm/ttm/backport/backport.h:6,
from :0:
   include/drm/drm_fb_helper.h:589:1: note: previous definition of 
'drm_fb_helper_remove_conflicting_framebuffers' was here
drm_fb_helper_remove_conflicting_framebuffers(struct apertures_struct *a,
^
   In file included from drivers/gpu/drm/ttm/backport/backport.h:6:0,
from :0:
   include/kcl/kcl_drm.h: In function 'kcl_drm_encoder_init':
>> include/kcl/kcl_drm.h:191:9: error: too few arguments to function 
>> 'drm_encoder_init'
 return drm_encoder_init(dev, encoder, funcs,
^~~~
   In file included from include/drm/drm_modeset_helper_vtables.h:33:0,
from include/drm/drm_atomic_helper.h:32,
from include/kcl/kcl_drm.h:10,
from drivers/gpu/drm/ttm/backport/backport.h:6,
from :0:
   include/drm/drm_encoder.h:183:5: note: declared here
int drm_encoder_init(struct drm_device *dev,
^~~~

vim +/drm_encoder_init +191 include/kcl/kcl_drm.h

950c9c93299ece Junwei Zhang   2016-12-233  
950c9c93299ece Junwei Zhang   2016-12-234  #include 
7e18f7a415538c Evan Quan  2019-02-185  #include 
950c9c93299ece Junwei Zhang   2016-12-236  #include 
950c9c93299ece Junwei Zhang   2016-12-23   @7  #include 
950c9c93299ece Junwei Zhang   2016-12-238  #include 
950c9c93299ece Junwei Zhang   2016-12-239  #include 
950c9c93299ece Junwei Zhang   2016-12-23   10  #include 

cc3188c9ec1202 Evan Quan  2017-05-11   11  #include 
7e18f7a415538c Evan Quan  2019-02-18   12  #include 
7e18f7a415538c Evan Quan  2019-02-18   13  #include 
cc3188c9ec1202 Evan Quan  2017-05-11   14  #include 
5027d12c82b867 changzhu   2019-04-03   15  #if DRM_VERSION_CODE >= 
DRM_VERSION(4, 13, 0)
5027d12c82b867 changzhu   2019-04-03   16  #include 
5027d12c82b867 changzhu   2019-04-03   17  #endif
950c9c93299ece Junwei Zhang   2016-12-23   18  
7e18f7a415538c Evan Quan  2019-02-18   19  #ifndef DRM_MODE_ROTATE_0
7e18f7a415538c Evan Quan  2019-02-18   20  #define DRM_MODE_ROTATE_0   
(1<<0)
7e18f7a415538c Evan Quan  2019-02-18   21  #endif
7e18f7a415538c Evan Quan  2019-02-18   22  #ifndef DRM_MODE_ROTATE_90
7e18f7a415538c Evan Quan  2019-02-18   23  #define DRM_MODE_ROTATE_90  
(1<<1)
7e18f7a415538c Evan Quan  2019-02-18   24  #endif
7e18f7a415538c Evan Quan  2019-02-18   25  #ifndef DRM_MODE_ROTATE_180
7e18f7a415538c Evan Quan  2019-02-18   26  #define DRM_MODE_ROTATE_180 
(1<<2)
7e18f7a415538c Evan Quan  2019-02-18   27  #endif
7e18f7a415538c Evan Quan  2019-02-18   28  #ifndef DRM_MODE_ROTATE_270
7e18f7a415538c Evan Quan  2019-02-18   29  #define DRM_MODE_ROTATE_270 
(1<<3)
7e18f7a415538c Evan Quan  2019-02-18   30  #endif
7e18f7a415538c Evan Quan  2019-02-18   31  
7e18f7a415538c Evan Quan  2019-02-18   32  #ifndef DRM_MODE_ROTATE_MASK
7e18f7a415538c Evan Quan  2019-02-18   33  #define DRM_MODE_ROTATE_MASK (\
7e18f7a415538c Evan Quan  2019-02-18   34   DRM_MODE_ROTATE_0  | \
7e18f7a415538c Evan Quan  2019-02-18   35   DRM_MODE_ROTATE_90  | \
7e18f7a415538c Evan Quan  2019-02-18   36   DRM_MODE_ROTATE_180 | \
7e18f7a415538c Evan Quan  2019-02-18   37   DRM_MODE_ROTATE_270)
7e18f7a415538c Evan Quan  2019-02-18   38  #endif
7e18f7a415538c Evan Quan  2019-02-18   39  
950c9c93299ece Junwei Zhang   2016-12-23   40  extern void 
(*_kcl_drm_fb_helper_set_suspend)(struct drm_fb_helper *fb_helper, int state);
950c9c93299ece Junwei Zhang   2016-12-23   41  extern void
950c9c93299ece Junwei Zhang   2016-12-23   42  
(*_kcl_drm_atomic_helper_update_legacy_modeset_state)(struct drm_device *dev,
950c9c93299ece Junwei Zhang   2016-12-23   43   
  

[pull] drm DP MST DSC support

[Alex Deucher]

Hi Dave, Daniel,

Ideally this would have gone through drm-misc, but it had dependencies
on some changes in the DC code which were in my latest PR, so I sent
this as a separate PR on top of my amdgpu PR.

The following changes since commit 0f899fd466b693a129b16994c1b2b4db2fcde4a4:

  drm/amdkfd: Improve kfd_process lookup in kfd_ioctl (2020-01-09 16:08:19 
-0500)

are available in the Git repository at:

  git://people.freedesktop.org/~agd5f/linux 
tags/amd-drm-next-5.6-2020-01-09-dp-mst-dsc

for you to fetch changes up to 9edb435aed968a2c792f6d847f524587697edf37:

  drm/dp_mst: fix documentation of drm_dp_mst_add_affected_dsc_crtcs 
(2020-01-09 18:07:48 -0500)


amd-drm-next-5.6-2020-01-09-dp-mst-dsc:

drm:
- Add MST helper for PBN calculation of DSC modes
- Parse FEC caps on MST ports
- Add MST DPCD R/W functions
- Add MST helpers for virtual DPCD aux
- Add MST HUB quirk
- Add MST DSC enablement helpers

amdgpu:
- Enable MST DSC
- Add fair share algo for DSC bandwidth calcs


Alex Deucher (2):
  drm/amdgpu/display: protect new DSC code with CONFIG_DRM_AMD_DC_DCN
  drm/dp_mst: fix documentation of drm_dp_mst_add_affected_dsc_crtcs

David (Dingchen) Zhang (1):
  drm: add dp helper to initialize remote aux channel.

David Francis (9):
  drm/dp_mst: Add PBN calculation for DSC modes
  drm/dp_mst: Parse FEC capability on MST ports
  drm/dp_mst: Add MST support to DP DPCD R/W functions
  drm/dp_mst: Fill branch->num_ports
  drm/dp_mst: Add helpers for MST DSC and virtual DPCD aux
  drm/amd/display: Initialize DSC PPS variables to 0
  drm/amd/display: Validate DSC caps on MST endpoints
  drm/amd/display: Write DSC enable to MST DPCD
  drm/amd/display: MST DSC compute fair share

Mikita Lipski (10):
  drm/dp_mst: Add new quirk for Synaptics MST hubs
  drm/dp_mst: Manually overwrite PBN divider for calculating timeslots
  drm/dp_mst: Add DSC enablement helpers to DRM
  drm/dp_mst: Add branch bandwidth validation to MST atomic check
  drm/dp_mst: Rename drm_dp_mst_atomic_check_topology_state
  drm/amd/display: Add PBN per slot calculation for DSC
  drm/amd/display: Check return value of drm helper
  drm/amd/display: Recalculate VCPI slots for new DSC connectors
  drm/dp_mst: Add helper to trigger modeset on affected DSC MST CRTCs
  drm/amd/display: Trigger modesets on MST DSC connectors

 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c  | 121 +-
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h  |   1 +
 .../drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c  |  19 +-
 .../amd/display/amdgpu_dm/amdgpu_dm_mst_types.c| 420 -
 .../amd/display/amdgpu_dm/amdgpu_dm_mst_types.h|   7 +
 drivers/gpu/drm/amd/display/dc/core/dc_link_hwss.c |   3 +
 drivers/gpu/drm/amd/display/dc/dcn20/dcn20_dsc.c   |   3 +
 .../gpu/drm/amd/display/dc/dcn20/dcn20_resource.c  |   7 +-
 .../gpu/drm/amd/display/dc/dcn20/dcn20_resource.h  |   1 +
 drivers/gpu/drm/drm_dp_aux_dev.c   |  12 +-
 drivers/gpu/drm/drm_dp_helper.c|  45 ++-
 drivers/gpu/drm/drm_dp_mst_topology.c  | 392 ++-
 drivers/gpu/drm/i915/display/intel_dp_mst.c|   5 +-
 drivers/gpu/drm/nouveau/dispnv50/disp.c|   4 +-
 drivers/gpu/drm/radeon/radeon_dp_mst.c |   2 +-
 drivers/gpu/drm/selftests/test-drm_dp_mst_helper.c |  12 +-
 include/drm/drm_dp_helper.h|   8 +
 include/drm/drm_dp_mst_helper.h|  20 +-
 18 files changed, 1031 insertions(+), 51 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[pull] amdgpu, amdkfd, radeon, scheduler drm-next-5.6

[Alex Deucher]

Hi Dave, Daniel,

More new stuff for 5.6.

A few more things I forgot to put in the tag:

amdgpu:
- Use a task barrier to properly synchronize multi-GPU reset

radeon:
- Misc cleanups

drm:
- Add a task barrier helper for synchronizing threads

scheduler:
- Entity creation rework to separate entities and run queues

The UAPI stuff is straight forward.  Just enabling DRIVER_SYNCOBJ_TIMELINE for
vulkan.  The relevant amdvlk code is in:
https://github.com/GPUOpen-Drivers/pal/blob/dev/src/core/os/amdgpu/amdgpuDevice.cpp
For the KFD ioctl, no changes to the ioctl itself, just adding an additional 
error
code on failure to make it easier to differentiate why the ioctl failed.

Also, a heads up, the DP MST DSC changes depend on some DC changes in this PR.
I would have merged them through drm-misc, but then we need to merge this first
so it seemed easier to just send a separate PR for them.  Let me know how you
want to handle it.

The following changes since commit 66af4a9ddac62a2614af5ce80169b6421b5c2d95:

  Merge tag 'du-next-20191218' of git://linuxtv.org/pinchartl/media into 
drm-next (2019-12-18 16:19:26 +0100)

are available in the Git repository at:

  git://people.freedesktop.org/~agd5f/linux tags/amd-drm-next-5.6-2020-01-09

for you to fetch changes up to 0f899fd466b693a129b16994c1b2b4db2fcde4a4:

  drm/amdkfd: Improve kfd_process lookup in kfd_ioctl (2020-01-09 16:08:19 
-0500)


amd-drm-next-5.6-2020-01-09:

amdgpu:
- Enable DCN support on POWER
- Enable GFXOFF for Raven1 refresh
- Clean up MM engine idle handlers
- HDMI 2.0 audio fixes
- Fixes for some 10 bpc EDP panels
- Watermark fixes for renoir
- SR-IOV fixes
- Runtime pm robustness fixes
- Arcturus VCN fixes
- RAS fixes
- BACO fixes for Arcturus
- Stable pstate fixes for swSMU
- HDCP fixes
- PSP cleanup
- HDMI fixes
- Misc cleanups

amdkfd:
- Spread interrupt work across cores to reduce latency
- Topology fixes for APUs
- GPU reset improvements

UAPI:
- Enable DRIVER_SYNCOBJ_TIMELINE for vulkan
- Return better error values for kfd process ioctl


Aidan Yang (1):
  drm/amd/display: Disable integerscaling for downscale and MPO

Alex Deucher (19):
  drm/amdgpu/gfx10: make ring tests less chatty
  drm/amdgpu/sdma5: make ring tests less chatty
  drm/amdgpu/pm_runtime: update usage count in fence handling
  drm/amdgpu/smu: fix spelling
  drm/amdgpu: wait for all rings to drain before runtime suspending
  drm/amdgpu/smu: add metrics table lock
  drm/amdgpu/smu: add metrics table lock for arcturus (v2)
  drm/amdgpu/smu: add metrics table lock for navi (v2)
  drm/amdgpu/smu: add metrics table lock for renoir (v2)
  drm/amdgpu/smu: add metrics table lock for vega20 (v2)
  drm/amdgpu/display: include delay.h
  drm/amdgpu/smu/navi: Adjust default behavior for peak sclk profile
  drm/amdgpu/smu: add peak profile support for navi12
  Revert "drm/amdgpu: simplify ATPX detection"
  drm/amdgpu/smu: make the set_performance_level logic easier to follow
  drm/amdgpu/gmc: move invaliation bitmap setup to common code
  drm/amdgpu/gmc10: use common invalidation engine helper
  drm/amdgpu/gfx: simplify old firmware warning
  Revert "drm/amdgpu: Set no-retry as default."

Amanda Liu (1):
  drm/amd/display: Reinstate LFC optimization

Andrey Grodzovsky (5):
  drm/amdgpu: reverts commit ce316fa55ef0f1751276b846a54fb3b835bd5e64.
  drm: Add Reusable task barrier.
  drm/amdgpu: Add task barrier to XGMI hive.
  drm/amdgpu: Redo XGMI reset synchronization.
  drm/amdgpu: Switch from system_highpri_wq to system_unbound_wq

Anthony Koo (1):
  drm/amd/display: Do not handle linkloss for eDP

Aric Cyr (5):
  drm/amd/display: Remove integer scaling code from DC and fix cursor
  drm/amd/display: 3.2.63
  drm/amd/display: scaling changes should also be a full update
  drm/amd/display: 3.2.64
  drm/amd/display: Fix manual trigger source for DCN2

Bhawanpreet Lakha (3):
  drm/amd/display: fix psp return condition for hdcp module
  drm/amd/display: Fix hdcp1 create session
  drm/amd/display: Return correct Error code for validate h_prime

Camille Cho (1):
  drm/amd/display: Add definition for number of backlight data points

Charlene Liu (2):
  drm/amd/display: HDMI 2.x audio bandwidth check
  drm/amd/display: Add warmup escape call support

Chunming Zhou (1):
  drm/amdgpu: add DRIVER_SYNCOBJ_TIMELINE to amdgpu

Colin Ian King (1):
  drm/amd/powerplay: fix various dereferences of a pointer before it is 
null checked

Dale Zhao (1):
  drm/amd/display: Use absolute time stamp to follow the eDP T7 spec 
requirement

Derek Lai (1):
  drm/amd/display: Specified VR patch skip to reset segment to 0

Emily Deng (1):
  drm/amdgpu/sriov: Tonga sriov also need load firmware with smu

Eric Yang (1):
  

Re: [PATCH v2 2/2] drm/panel: add support for rm69299 visionox panel driver

[Doug Anderson]

Hi,

On Tue, Jan 7, 2020 at 3:30 AM Harigovindan P  wrote:
>
> +   drm_panel_init(>panel);
> +   ctx->panel.dev = device;
> +   ctx->panel.funcs = _rm69299_drm_funcs;

I haven't reviewed your whole panel driver, but I did just try to
compile it and found that it won't compile against mainline.  Namely
this needs to be changed to:

drm_panel_init(>panel, dev, _rm69299_drm_funcs,
   DRM_MODE_CONNECTOR_DSI);

...because of commit 6dbe0c4b0fc0 ("drm/panel: Initialise panel dev
and funcs through drm_panel_init()") and commit 9a2654c0f62a
("drm/panel: Add and fill drm_panel type field")

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

Re: [PATCH v12 00/22] mm/gup: prereqs to track dma-pinned pages: FOLL_PIN

[John Hubbard]

On 1/7/20 2:45 PM, John Hubbard wrote:
> Hi,
> 
> The "track FOLL_PIN pages" would have been the very next patch, but it is
> not included here because I'm still debugging a bug report from Leon.
> Let's get all of the prerequisite work (it's been reviewed) into the tree
> so that future reviews are easier. It's clear that any fixes that are
> required to the tracking patch, won't affect these patches here.
> 
> This implements an API naming change (put_user_page*() -->
> unpin_user_page*()), and also adds FOLL_PIN page support, up to
> *but not including* actually tracking FOLL_PIN pages. It extends
> the FOLL_PIN support to a few select subsystems. More subsystems will
> be added in follow up work.
> 

Hi Andrew and all,

To clarify: I'm hoping that this series can go into 5.6.

Meanwhile, I'm working on tracking down and solving the problem that Leon
reported, in the "track FOLL_PIN pages" patch, and that patch is not part of
this series.

thanks,
-- 
John Hubbard
NVIDIA
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v8] drm/panel: Add driver for Sony ACX424AKP panel

[Linus Walleij]

On Thu, Jan 9, 2020 at 3:17 PM Sam Ravnborg  wrote:

> Applied to drm-misc-next.

Thanks! Much appreciated.

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

Re: [PATCH 2/2] drm/amd/display: Allow current eDP link settings to override verified ones.

[Harry Wentland]

On 2020-01-09 4:13 p.m., Mario Kleiner wrote:
> On Thu, Jan 9, 2020 at 7:44 PM Harry Wentland  > wrote:
> 
> On 2020-01-09 10:20 a.m., Mario Kleiner wrote:
> > If the current eDP link settings, as read from hw, provide a higher
> > bandwidth than the verified_link_cap ones (= reported_link_cap), then
> > override verified_link_cap with current settings.
> >
> > These initial current eDP link settings have been set up by
> > firmware during boot, so they should work on the eDP panel.
> > Therefore use them if the firmware thinks they are good and
> > they provide higher link bandwidth, e.g., to enable higher
> > resolutions / color depths.
> >
>  
> 
> 
> Hi Harry, happy new year!
> 

Frohes Neues. :)

> This only works when taking over from UEFI, so on boot or resume from
> hibernate. This wouldn't work on a normal suspend/resume.
> 
> 
> See the other thread i just cc'ed you on. Depends if
> dc_link_detect_helper() gets skipped/early returns or not on EDP. Some
> if statement suggests it might get skipped on EDP + resume?
>  

You've likely looked at the code more closely while debugging this than
I have recently. It looks like we indeed skip detection if we've
previously detected the eDP sink.

> 
> Can you check if setting link->dc->config.optimize_edp_link_rate (see
> first if statement in detect_edp_sink_caps) fixes this? I imagine we
> need to read the reported settings from DP_SUPPORTED_LINK_RATES and fail
> to do so.
> 
> 
> Tried that already (see other mail), replacing the whole if statement
> with a if (true) to force reading DP_SUPPORTED_LINK_RATES. The whole
> table reads back as all-zero, and versions are DP 1.1, eDP 1.3, not 1.4+
> as what seems to be required. The use the classic link bw stuff, but
> with a non-standard link bandwidth multiplier of 0xc, and a reported
> DP_MAX_LINK_RATE of 0xa, contradicting the 0xc setting that the firmware
> sets at bootup.
> 
> Seems to be a very Apple thing...

Indeed. I think it was a funky panel that was "ahead of its time" and
ahead of the spec.

I would prefer a DPCD quirk for this panel that updates the reported DP
caps, rather than picking the "current" ones from the FW lightup.

Harry

> -mario
>  
> 
> 
> Thanks,
> Harry
> 
> > This fixes a problem found on the MacBookPro 2017 Retina panel:
> >
> > The panel reports 10 bpc color depth in its EDID, and the
> > firmware chooses link settings at boot which support enough
> > bandwidth for 10 bpc (324000 kbit/sec aka LINK_RATE_RBR2),
> > but the DP_MAX_LINK_RATE dpcd register only reports 2.7 Gbps
> > as possible, so verified_link_cap is only good for 2.7 Gbps
> > and 8 bpc, not providing the full color depth of the panel.
> >
> > Signed-off-by: Mario Kleiner  >
> > Cc: Alex Deucher  >
> > ---
> >  drivers/gpu/drm/amd/display/dc/core/dc_link.c | 21
> +++
> >  1 file changed, 21 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
> b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
> > index 5ea4a1675259..f3acdb8fead5 100644
> > --- a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
> > +++ b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
> > @@ -819,6 +819,27 @@ static bool dc_link_detect_helper(struct
> dc_link *link,
> >               case SIGNAL_TYPE_EDP: {
> >                       detect_edp_sink_caps(link);
> >                       read_current_link_settings_on_detect(link);
> > +
> > +                     /* If cur_link_settings provides higher
> bandwidth than
> > +                      * verified_link_cap, then use
> cur_link_settings as new
> > +                      * verified_link_cap, as it obviously works
> according to
> > +                      * firmware boot setup.
> > +                      *
> > +                      * This has been observed on the Apple
> MacBookPro 2017
> > +                      * Retina panel, which boots with a link
> setting higher
> > +                      * than what dpcd[DP_MAX_LINK_RATE] claims
> as possible.
> > +                      * Overriding allows to run the panel at 10
> bpc / 30 bit.
> > +                      */
> > +                     if (dc_link_bandwidth_kbps(link,
> >cur_link_settings) >
> > +                         dc_link_bandwidth_kbps(link,
> >verified_link_cap)) {
> > +                             DC_LOG_DETECTION_DP_CAPS(
> > +                             "eDP current link setting bw %d kbps
> > verified_link_cap %d kbps. Override.",
> > +                             dc_link_bandwidth_kbps(link,
> >cur_link_settings),
> > +                             dc_link_bandwidth_kbps(link,
> 

Re: [PATCH] drm/i915/dp: Add current maximum eDP link rate to sink_rate array.

[Harry Wentland]

On 2020-01-09 4:04 p.m., Mario Kleiner wrote:
> On Thu, Jan 9, 2020 at 8:49 PM Alex Deucher  > wrote:
>
> On Thu, Jan 9, 2020 at 11:47 AM Mario Kleiner
> mailto:mario.kleiner...@gmail.com>>
> wrote:
> >
> > On Thu, Jan 9, 2020 at 4:40 PM Alex Deucher
> mailto:alexdeuc...@gmail.com>> wrote:
> >>
> >> On Thu, Jan 9, 2020 at 10:08 AM Mario Kleiner
> >>  > wrote:
> >> >
> As Harry mentioned in the other thread, won't this only work if the
> display was brought up by the vbios?  In the suspend/resume case,
> won't we just fall back to 2.7Gbps?
>
> Alex
>
>
> Adding Harry to cc...
>
> The code is only executed for eDP. On the Intel side, it seems that
> intel_edp_init_dpcd() gets only called during driver load /
> modesetting init, so not on resume.
>
> On the AMD DC side, dc_link_detect_helper() has this early no-op
> return at the beginning:
>
> if ((link->connector_signal == SIGNAL_TYPE_LVDS ||
>   link->connector_signal == SIGNAL_TYPE_EDP) &&
>   link->local_sink)
>   return true;
>
> So i guess if link->local_sink doesn't get NULL'ed during a
> suspend/resume cycle, then we never reach the setup code that would
> overwrite with non vbios settings?
>
> Sounds reasonable to me, given that eDP panels are usually fixed
> internal panels, nothing that gets hot(un-)plugged?
>
> I can't test, because suspend/resume with the Polaris gpu on the MBP
> 2017 is totally broken atm., just as vgaswitcheroo can't do its job.
> Looks like powering down the gpu works, but powering up doesn't. And
> also modesetting at vgaswitcheroo switch time is no-go, because the
> DDC/AUX lines apparently can't be switched on that Apple gmux, and
> handover of that data seems to be not implemented in current
> vgaswitcheroo. At the moment switching between AMD only or Intel+AMD
> Prime setup is quite a pita...
>

I haven't followed the entire discussion on the i915 thread but for the
amdgpu dc patch I would prefer a DPCD quirk to override the reported
link settings with the correct link rate.

Harry

> -mario
>
>

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

Re: [PATCH 2/2] drm/amd/display: Allow current eDP link settings to override verified ones.

[Mario Kleiner]

On Thu, Jan 9, 2020 at 7:44 PM Harry Wentland  wrote:

> On 2020-01-09 10:20 a.m., Mario Kleiner wrote:
> > If the current eDP link settings, as read from hw, provide a higher
> > bandwidth than the verified_link_cap ones (= reported_link_cap), then
> > override verified_link_cap with current settings.
> >
> > These initial current eDP link settings have been set up by
> > firmware during boot, so they should work on the eDP panel.
> > Therefore use them if the firmware thinks they are good and
> > they provide higher link bandwidth, e.g., to enable higher
> > resolutions / color depths.
> >
>


Hi Harry, happy new year!

This only works when taking over from UEFI, so on boot or resume from
> hibernate. This wouldn't work on a normal suspend/resume.
>
>
See the other thread i just cc'ed you on. Depends if
dc_link_detect_helper() gets skipped/early returns or not on EDP. Some if
statement suggests it might get skipped on EDP + resume?


> Can you check if setting link->dc->config.optimize_edp_link_rate (see
> first if statement in detect_edp_sink_caps) fixes this? I imagine we
> need to read the reported settings from DP_SUPPORTED_LINK_RATES and fail
> to do so.
>

Tried that already (see other mail), replacing the whole if statement with
a if (true) to force reading DP_SUPPORTED_LINK_RATES. The whole table reads
back as all-zero, and versions are DP 1.1, eDP 1.3, not 1.4+ as what seems
to be required. The use the classic link bw stuff, but with a non-standard
link bandwidth multiplier of 0xc, and a reported DP_MAX_LINK_RATE of 0xa,
contradicting the 0xc setting that the firmware sets at bootup.

Seems to be a very Apple thing...
-mario


>
> Thanks,
> Harry
>
> > This fixes a problem found on the MacBookPro 2017 Retina panel:
> >
> > The panel reports 10 bpc color depth in its EDID, and the
> > firmware chooses link settings at boot which support enough
> > bandwidth for 10 bpc (324000 kbit/sec aka LINK_RATE_RBR2),
> > but the DP_MAX_LINK_RATE dpcd register only reports 2.7 Gbps
> > as possible, so verified_link_cap is only good for 2.7 Gbps
> > and 8 bpc, not providing the full color depth of the panel.
> >
> > Signed-off-by: Mario Kleiner 
> > Cc: Alex Deucher 
> > ---
> >  drivers/gpu/drm/amd/display/dc/core/dc_link.c | 21 +++
> >  1 file changed, 21 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
> b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
> > index 5ea4a1675259..f3acdb8fead5 100644
> > --- a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
> > +++ b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
> > @@ -819,6 +819,27 @@ static bool dc_link_detect_helper(struct dc_link
> *link,
> >   case SIGNAL_TYPE_EDP: {
> >   detect_edp_sink_caps(link);
> >   read_current_link_settings_on_detect(link);
> > +
> > + /* If cur_link_settings provides higher bandwidth
> than
> > +  * verified_link_cap, then use cur_link_settings
> as new
> > +  * verified_link_cap, as it obviously works
> according to
> > +  * firmware boot setup.
> > +  *
> > +  * This has been observed on the Apple MacBookPro
> 2017
> > +  * Retina panel, which boots with a link setting
> higher
> > +  * than what dpcd[DP_MAX_LINK_RATE] claims as
> possible.
> > +  * Overriding allows to run the panel at 10 bpc /
> 30 bit.
> > +  */
> > + if (dc_link_bandwidth_kbps(link,
> >cur_link_settings) >
> > + dc_link_bandwidth_kbps(link,
> >verified_link_cap)) {
> > + DC_LOG_DETECTION_DP_CAPS(
> > + "eDP current link setting bw %d kbps >
> verified_link_cap %d kbps. Override.",
> > + dc_link_bandwidth_kbps(link,
> >cur_link_settings),
> > + dc_link_bandwidth_kbps(link,
> >verified_link_cap));
> > +
> > + link->verified_link_cap =
> link->cur_link_settings;
> > + }
> > +
> >   sink_caps.transaction_type =
> DDC_TRANSACTION_TYPE_I2C_OVER_AUX;
> >   sink_caps.signal = SIGNAL_TYPE_EDP;
> >   break;
> >
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/i915/dp: Add current maximum eDP link rate to sink_rate array.

[Mario Kleiner]

On Thu, Jan 9, 2020 at 8:49 PM Alex Deucher  wrote:

> On Thu, Jan 9, 2020 at 11:47 AM Mario Kleiner
>  wrote:
> >
> > On Thu, Jan 9, 2020 at 4:40 PM Alex Deucher 
> wrote:
> >>
> >> On Thu, Jan 9, 2020 at 10:08 AM Mario Kleiner
> >>  wrote:
> >> >
> As Harry mentioned in the other thread, won't this only work if the
> display was brought up by the vbios?  In the suspend/resume case,
> won't we just fall back to 2.7Gbps?
>
> Alex
>
>
Adding Harry to cc...

The code is only executed for eDP. On the Intel side, it seems that
intel_edp_init_dpcd() gets only called during driver load / modesetting
init, so not on resume.

On the AMD DC side, dc_link_detect_helper() has this early no-op return at
the beginning:

if ((link 
->connector_signal
== SIGNAL_TYPE_LVDS
 ||
link 
->connector_signal
== SIGNAL_TYPE_EDP
) &&
link 
->local_sink)
return  
true
;


So i guess if link->local_sink doesn't get NULL'ed during a suspend/resume
cycle, then we never reach the setup code that would overwrite with non
vbios settings?

Sounds reasonable to me, given that eDP panels are usually fixed internal
panels, nothing that gets hot(un-)plugged?

I can't test, because suspend/resume with the Polaris gpu on the MBP 2017
is totally broken atm., just as vgaswitcheroo can't do its job. Looks like
powering down the gpu works, but powering up doesn't. And also modesetting
at vgaswitcheroo switch time is no-go, because the DDC/AUX lines apparently
can't be switched on that Apple gmux, and handover of that data seems to be
not implemented in current vgaswitcheroo. At the moment switching between
AMD only or Intel+AMD Prime setup is quite a pita...

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

Re: [PATCH 0/2] drm/radeon: have the callers of set_memory_*() check the return value

[Alex Deucher]

On Thu, Jan 9, 2020 at 5:49 AM Thomas Zimmermann  wrote:
>
> Hi
>
> Am 09.01.20 um 11:15 schrieb Christian König:
> > Am 08.01.20 um 18:51 schrieb Alex Deucher:
> >> On Wed, Jan 8, 2020 at 12:39 PM Kees Cook  wrote:
> >>> On Wed, Jan 08, 2020 at 01:56:47PM +0100, Christian König wrote:
>  Am 07.01.20 um 20:25 schrieb Tianlin Li:
> > Right now several architectures allow their set_memory_*() family of
> > functions to fail, but callers may not be checking the return values.
> > If set_memory_*() returns with an error, call-site assumptions may be
> > infact wrong to assume that it would either succeed or not succeed at
> > all. Ideally, the failure of set_memory_*() should be passed up the
> > call stack, and callers should examine the failure and deal with it.
> >
> > Need to fix the callers and add the __must_check attribute. They also
> > may not provide any level of atomicity, in the sense that the memory
> > protections may be left incomplete on failure. This issue likely has a
> > few steps on effects architectures:
> > 1)Have all callers of set_memory_*() helpers check the return value.
> > 2)Add __must_check to all set_memory_*() helpers so that new uses do
> > not ignore the return value.
> > 3)Add atomicity to the calls so that the memory protections aren't
> > left
> > in a partial state.
> >
> > This series is part of step 1. Make drm/radeon check the return
> > value of
> > set_memory_*().
>  I'm a little hesitate merge that. This hardware is >15 years old and
>  nobody
>  of the developers have any system left to test this change on.
> >>> If that's true it should be removed from the tree. We need to be able to
> >>> correctly make these kinds of changes in the kernel.
> >> This driver supports about 15 years of hardware generations.  Newer
> >> cards are still prevalent, but the older stuff is less so.  It still
> >> works and people use it based on feedback I've seen, but the older
> >> stuff has no active development at this point.  This change just
> >> happens to target those older chips.
> >
> > Just a few weeks back we've got a mail from somebody using an integrated
> > R128 in a laptop.
> >
> > After a few mails back and force we figured out that his nearly 20 years
> > old hardware was finally failing.
> >
> > Up till that he was still successfully updating his kernel from time to
> > time and the driver still worked. I find that pretty impressive.
> >
> >>
> >> Alex
> >>
>  Would it be to much of a problem to just add something like: r =
>  set_memory_*(); (void)r; /* Intentionally ignored */.
> >>> This seems like a bad idea -- we shouldn't be papering over failure
> >>> like this when there is logic available to deal with it.
> >
> > Well I certainly agree to that, but we are talking about a call which
> > happens only once during driver load/unload. If necessary we could also
> > print an error when something goes wrong, but please no larger
> > refactoring of return values and call paths.
> >
>
> IMHO radeon should be marked as orphaned or obsolete then.

As I said this covers about 15-17 years of GPUs (~60 asic families).
The older stuff is hard to test these days because it's PCI or AGP
hardware.  So far it works for most people.  The newer stuff is still
tested as used regularly.

Alex

>
> Best regards
> Thomas
>
> > It is perfectly possible that this call actually failed on somebodies
> > hardware, but we never noticed because the driver still works fine. If
> > we now handle the error it is possible that the module never loads and
> > the user gets a black screen instead.
> >
> > Regards,
> > Christian.
> >
> >>>
>  Apart from that certainly a good idea to add __must_check to the
>  functions.
> >>> Agreed!
> >>>
> >>> -Kees
> >>>
> >>> --
> >>> Kees Cook
> >>> ___
> >>> dri-devel mailing list
> >>> dri-devel@lists.freedesktop.org
> >>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fdri-develdata=02%7C01%7Cchristian.koenig%40amd.com%7Ca542d384d54040b5b0b708d794636df1%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637141027080080147sdata=EHFl6YOHmNp7gOqWsVmfoeD0jNirBTOGHcCP4efC%2FvE%3Dreserved=0
> >>>
> >
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> --
> Thomas Zimmermann
> Graphics Driver Developer
> SUSE Software Solutions Germany GmbH
> Maxfeldstr. 5, 90409 Nürnberg, Germany
> (HRB 36809, AG Nürnberg)
> Geschäftsführer: Felix Imendörffer
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/i915/dp: Add current maximum eDP link rate to sink_rate array.

[Mario Kleiner]

On Thu, Jan 9, 2020 at 7:24 PM Ville Syrjälä 
wrote:

> On Thu, Jan 09, 2020 at 06:57:14PM +0100, Mario Kleiner wrote:
> > On Thu, Jan 9, 2020 at 5:47 PM Ville Syrjälä <
> ville.syrj...@linux.intel.com>
> > wrote:
> >
> > > On Thu, Jan 09, 2020 at 05:30:05PM +0100, Mario Kleiner wrote:
> > > > On Thu, Jan 9, 2020 at 4:38 PM Ville Syrjälä <
> > > ville.syrj...@linux.intel.com>
> > > > wrote:
> > > >
>

> wouldn't work if dpcd[0x1] == 0xa, which it likely is [*]. AMD DC
> > identified it as DP 1.1, eDP 1.3, and these extended caps seem to be only
> > part of DP 1.3+ if i understand the comments in
> > intel_dp_extended_receiver_capabilities() correctly.
>
>
Ok, looking at previous debug output logs shows that those extended caps
are not present on the systems, ie. that extended caps bit is not set. So
dpcd[0x1] == 0xa.


> Yeah, but you never know how creative they've been with the DPCD in
> such a propritary machine. A full DPCD dump from /dev/drm_dp_aux* would
> be nice. Can you file a bug an attach the DPCD dump there so we have a
> good reference on what we're talking about (also for future if/when
> someone eventually starts to wonder why we have such hacks in the
> code)?
>
>
True, it's Apple which likes to "Think different..." :/

Will do. But is there a proper/better way to do the /dev/drm_dp_aux0 dump?
I used cat /dev/drm_dp_aux0 > dump, and that hangs, but if i interrupt it
after a few seconds, i get a dump file of 512k size, which seems excessive?
On AMD DC atm., in case that matters.

However, the file shows DPCD_REV 1.1, maximum 0xa and no extended caps (
DP_TRAINING_AUX_RD_INTERVAL

aka
[0xe] == 0x00).
 -mario


-- 
> Ville Syrjälä
> Intel
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/i915/dp: Add current maximum eDP link rate to sink_rate array.

[Alex Deucher]

On Thu, Jan 9, 2020 at 11:47 AM Mario Kleiner
 wrote:
>
> On Thu, Jan 9, 2020 at 4:40 PM Alex Deucher  wrote:
>>
>> On Thu, Jan 9, 2020 at 10:08 AM Mario Kleiner
>>  wrote:
>> >
>> > If the current eDP link rate, as read from hw, provides a
>> > higher bandwidth than the standard link rates, then add the
>> > current link rate to the link_rates array for consideration
>> > in future mode-sets.
>> >
>> > These initial current eDP link settings have been set up by
>> > firmware during boot, so they should work on the eDP panel.
>> > Therefore use them if the firmware thinks they are good and
>> > they provide higher link bandwidth, e.g., to enable higher
>> > resolutions / color depths.
>> >
>> > This fixes a problem found on the MacBookPro 2017 Retina panel:
>> >
>> > The panel reports 10 bpc color depth in its EDID, and the UEFI
>> > firmware chooses link settings at boot which support enough
>> > bandwidth for 10 bpc (324000 kbit/sec to be precise), but the
>> > DP_MAX_LINK_RATE dpcd register only reports 2.7 Gbps as possible,
>> > so intel_dp_set_sink_rates() would cap at that. This restricts
>> > achievable color depth to 8 bpc, not providing the full color
>> > depth of the panel. With this commit, we can use firmware setting
>> > and get the full 10 bpc advertised by the Retina panel.
>>
>> Would it make more sense to just add a quirk for this particular
>> panel?  Would there be cases where the link was programmed wrong and
>> then we end up using that additional link speed as supported?
>>
>> Alex
>>
>
> Not sure. This MBP 2017 is the only non-ancient laptop i now have. I'd assume 
> many other Apple Retina panels would behave similar. The panels dpcd regs 
> report DP 1.1 and eDP 1.3, so the flexible table with additional modes from 
> eDP1.4+ does not exist. According to Wikipedia, eDP 1.4 was introduced in 
> february 2013 and this is a mid 2017 machine, so Apple seems to be quite 
> behind. Therefore i assume  we'd need a lot of quirks over time.
>
> That said:
>
> 1. The logic in amdgpu's DC for the same purpose is a bit different than on 
> the intel side.
>
> 2. DC allows overriding DP link settings, that's how i initially tested this, 
> so one could do the "quirk" via something like that in a bootup script. So on 
> AMD one could work around the lack of the patch and of quirks.
>
> 3. I spent a lot of time with a photo-meter, testing the quality of the 10 
> bit: It turns out that running the panel at 8 bit + AMD's spatial dithering 
> that kicks in gives better results than running the panel in native 10 bit. 
> Maybe the panel is not really a 10 bit one, but just pretends to be and then 
> uses its own dithering to achieve 10 bit. So at least on AMD one is better 
> off precision-wise with the 8 bit panel default with this specific panel.
>
> On Intel however, we don't do dithering for > 6 bpc panels atm., so using the 
> panel at 10 bpc is the only way to get 10 bit display atm. Adn we don't use 
> dithering on Intel at > 6 bpc panels atm., because there are some oddities in 
> the way Intel hw dithers at higher bit depths - it also dithers pixel values 
> where it shouldn't. That makes it impossible to get an identity passthrough 
> of a 8 bpc framebuffer to the outputs, which kills all kind of special 
> display equipment that needs that identity passthrough to work.
>

As Harry mentioned in the other thread, won't this only work if the
display was brought up by the vbios?  In the suspend/resume case,
won't we just fall back to 2.7Gbps?

Alex

> -mario
>
>> >
>> > Signed-off-by: Mario Kleiner 
>> > Cc: Daniel Vetter 
>> > ---
>> >  drivers/gpu/drm/i915/display/intel_dp.c | 23 +++
>> >  1 file changed, 23 insertions(+)
>> >
>> > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
>> > b/drivers/gpu/drm/i915/display/intel_dp.c
>> > index 2f31d226c6eb..aa3e0b5108c6 100644
>> > --- a/drivers/gpu/drm/i915/display/intel_dp.c
>> > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
>> > @@ -4368,6 +4368,8 @@ intel_edp_init_dpcd(struct intel_dp *intel_dp)
>> >  {
>> > struct drm_i915_private *dev_priv =
>> > to_i915(dp_to_dig_port(intel_dp)->base.base.dev);
>> > +   int max_rate;
>> > +   u8 link_bw;
>> >
>> > /* this function is meant to be called only once */
>> > WARN_ON(intel_dp->dpcd[DP_DPCD_REV] != 0);
>> > @@ -4433,6 +4435,27 @@ intel_edp_init_dpcd(struct intel_dp *intel_dp)
>> > else
>> > intel_dp_set_sink_rates(intel_dp);
>> >
>> > +   /*
>> > +* If the firmware programmed a rate higher than the standard sink 
>> > rates
>> > +* during boot, then add that rate as a valid sink rate, as fw 
>> > knows
>> > +* this is a good rate and we get extra bandwidth.
>> > +*
>> > +* Helps, e.g., on the Apple MacBookPro 2017 Retina panel, which 
>> > is only
>> > +* eDP 1.1, but supports the unusual rate of 324000 kHz at bootup, 
>> > for
>> > +* 10 

Re: [PATCH v2 4/7] drm/panfrost: Add support for a second regulator for the GPU

[Mark Brown]

On Thu, Jan 09, 2020 at 04:53:02PM +, Steven Price wrote:
> On 09/01/2020 16:28, Mark Brown wrote:
> > On Thu, Jan 09, 2020 at 02:14:42PM +, Steven Price wrote:

> > > I'm not sure if it's better, but could we just encode the list of
> > > regulators into device tree. I'm a bit worried about special casing an
> > > "sram" regulator given that other platforms might have a similar
> > > situation but call the second regulator a different name.

> > Obviously the list of regulators bound on a given platform is encoded in
> > the device tree but you shouldn't really be relying on that to figure
> > out what to request in the driver - the driver should know what it's
> > expecting.

> From a driver perspective we don't expect to have to worry about power
> domains/multiple regulators - the hardware provides a bunch of power
> registers to turn on/off various parts of the hardware and this should be
> linked (in hardware) to a PDC which sorts it out. The GPU/PDC handles the
> required sequencing. So it *should* be a case of turn power/clocks on and
> go.

Ah, the well abstracted and consistent hardware with which we are all so
fortunate to work :) .  More seriously perhaps the thing to do here is
create a driver that provides a soft PDC and then push all the special
case handling into that?  It can then get instantiated based on the
compatible or perhaps represented directly in the device tree if that
makes sense.

> However certain integrations may have quirks such that there are physically
> multiple supplies. These are expected to all be turned on before using the
> GPU. Quite how this is best represented is something I'm not sure about.

If they're always on and don't ever change then that's really easy to
represent in the DT without involving drivers, it's when you need to
actively manage them that it's more effort.

> > Bear in mind that getting regulator stuff wrong can result
> > in physical damage to the system so it pays to be careful and to
> > consider that platform integrators have a tendency to rely on things
> > that just happen to work but aren't a good idea or accurate
> > representations of the system.  It's certainly *possible* to do
> > something like that, the information is there, but I would not in any
> > way recommend doing things that way as it's likely to not be robust.

> > The possibility that the regulator setup may vary on other platforms
> > (which I'd expect TBH) does suggest that just requesting a bunch of
> > supply names optionally and hoping that we got all the ones that are
> > important on a given platform is going to lead to trouble down the line.

> Certainly if we miss a regulator the GPU isn't going to work properly (some
> cores won't be able to power up successfully). However at the moment the
> driver will happily do this if someone provides it with a DT which includes
> regulators that it doesn't know about. So I'm not sure how adding special
> case code for a SoC would help here.

I thought this SoC neeed to vary the voltage on both rails as part of
the power management?  Things like that can lead to hardware damage if
we go out of spec far enough for long enough - there can be requirements
like keeping one rail a certain voltage above another or whatever.


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

Re: [PATCH v5 1/2] dt-bindings: display: simple: Add Satoz panel

[Sam Ravnborg]

Hi Miquel.

On Thu, Jan 09, 2020 at 07:40:36PM +0100, Miquel Raynal wrote:
> Satoz is a Chinese TFT manufacturer.
> Website: http://www.sat-sz.com/English/index.html
> 
> Add the compatible for its SAT050AT40H12R2 5.0 inch LCD panel.
> 
> Signed-off-by: Miquel Raynal 

Applied this and the following patch to drm-misc-next.
I manually resolved the conflict in panel-simple.yaml.

Thanks,

Sam


> ---
> 
> Changes since v4:
> * Drop the satoz,sat050at40h12r2.yaml file in favor of the very new
>   panel-simple.yaml common file. Just add the compatible there.
> 
> Changes since v3:
> * Added the missing ".yaml" suffix in the $id.
> * Removed the unnecessary "contains" assertion about the compatible.
> * Added a precision : there is no public specification for this panel
>   (known for the moment).
> * Bindings checked with "make dt_binding_check"
> 
> Changes since v2:
> * None.
> 
> Changes since v1:
> * New patch
> 
>  .../devicetree/bindings/display/panel/panel-simple.yaml | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git 
> a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml 
> b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
> index 090866260f4f..8a9c37640dc0 100644
> --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
> +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
> @@ -33,6 +33,8 @@ properties:
>- ampire,am-480272h3tmqw-t01h
>  # Ampire AM-800480R3TMQW-A1H 7.0" WVGA TFT LCD panel
>- ampire,am800480r3tmqwa1h
> +# Satoz SAT050AT40H12R2 5.0" WVGA TFT LCD panel
> +  - satoz,sat050at40h12r2
>  
>backlight: true
>enable-gpios: true
> -- 
> 2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/2] drm/amd/display: Allow current eDP link settings to override verified ones.

[Harry Wentland]

On 2020-01-09 10:20 a.m., Mario Kleiner wrote:
> If the current eDP link settings, as read from hw, provide a higher
> bandwidth than the verified_link_cap ones (= reported_link_cap), then
> override verified_link_cap with current settings.
> 
> These initial current eDP link settings have been set up by
> firmware during boot, so they should work on the eDP panel.
> Therefore use them if the firmware thinks they are good and
> they provide higher link bandwidth, e.g., to enable higher
> resolutions / color depths.
> 

This only works when taking over from UEFI, so on boot or resume from
hibernate. This wouldn't work on a normal suspend/resume.

Can you check if setting link->dc->config.optimize_edp_link_rate (see
first if statement in detect_edp_sink_caps) fixes this? I imagine we
need to read the reported settings from DP_SUPPORTED_LINK_RATES and fail
to do so.

Thanks,
Harry

> This fixes a problem found on the MacBookPro 2017 Retina panel:
> 
> The panel reports 10 bpc color depth in its EDID, and the
> firmware chooses link settings at boot which support enough
> bandwidth for 10 bpc (324000 kbit/sec aka LINK_RATE_RBR2),
> but the DP_MAX_LINK_RATE dpcd register only reports 2.7 Gbps
> as possible, so verified_link_cap is only good for 2.7 Gbps
> and 8 bpc, not providing the full color depth of the panel.
> 
> Signed-off-by: Mario Kleiner 
> Cc: Alex Deucher 
> ---
>  drivers/gpu/drm/amd/display/dc/core/dc_link.c | 21 +++
>  1 file changed, 21 insertions(+)
> 
> diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link.c 
> b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
> index 5ea4a1675259..f3acdb8fead5 100644
> --- a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
> +++ b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
> @@ -819,6 +819,27 @@ static bool dc_link_detect_helper(struct dc_link *link,
>   case SIGNAL_TYPE_EDP: {
>   detect_edp_sink_caps(link);
>   read_current_link_settings_on_detect(link);
> +
> + /* If cur_link_settings provides higher bandwidth than
> +  * verified_link_cap, then use cur_link_settings as new
> +  * verified_link_cap, as it obviously works according to
> +  * firmware boot setup.
> +  *
> +  * This has been observed on the Apple MacBookPro 2017
> +  * Retina panel, which boots with a link setting higher
> +  * than what dpcd[DP_MAX_LINK_RATE] claims as possible.
> +  * Overriding allows to run the panel at 10 bpc / 30 
> bit.
> +  */
> + if (dc_link_bandwidth_kbps(link, 
> >cur_link_settings) >
> + dc_link_bandwidth_kbps(link, 
> >verified_link_cap)) {
> + DC_LOG_DETECTION_DP_CAPS(
> + "eDP current link setting bw %d kbps > 
> verified_link_cap %d kbps. Override.",
> + dc_link_bandwidth_kbps(link, 
> >cur_link_settings),
> + dc_link_bandwidth_kbps(link, 
> >verified_link_cap));
> +
> + link->verified_link_cap = 
> link->cur_link_settings;
> + }
> +
>   sink_caps.transaction_type = 
> DDC_TRANSACTION_TYPE_I2C_OVER_AUX;
>   sink_caps.signal = SIGNAL_TYPE_EDP;
>   break;
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/2] drm/amd/display: Reorder detect_edp_sink_caps before link settings read.

[Harry Wentland]

On 2020-01-09 10:20 a.m., Mario Kleiner wrote:
> read_current_link_settings_on_detect() on eDP 1.4+ may use the
> edp_supported_link_rates table which is set up by
> detect_edp_sink_caps(), so that function needs to be called first.
> 
> Signed-off-by: Mario Kleiner 
> Cc: Martin Leung 

Reviewed-by: Harry Wentland 

This also fixes our assumption that retrieve_link_cap is the first DPCD
reads we perform during detection.

Harry

> ---
>  drivers/gpu/drm/amd/display/dc/core/dc_link.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link.c 
> b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
> index cef8c1ba9797..5ea4a1675259 100644
> --- a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
> +++ b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
> @@ -817,8 +817,8 @@ static bool dc_link_detect_helper(struct dc_link *link,
>   }
>  
>   case SIGNAL_TYPE_EDP: {
> - read_current_link_settings_on_detect(link);
>   detect_edp_sink_caps(link);
> + read_current_link_settings_on_detect(link);
>   sink_caps.transaction_type = 
> DDC_TRANSACTION_TYPE_I2C_OVER_AUX;
>   sink_caps.signal = SIGNAL_TYPE_EDP;
>   break;
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/i915/dp: Add current maximum eDP link rate to sink_rate array.

[Ville Syrjälä]

On Thu, Jan 09, 2020 at 06:57:14PM +0100, Mario Kleiner wrote:
> On Thu, Jan 9, 2020 at 5:47 PM Ville Syrjälä 
> wrote:
> 
> > On Thu, Jan 09, 2020 at 05:30:05PM +0100, Mario Kleiner wrote:
> > > On Thu, Jan 9, 2020 at 4:38 PM Ville Syrjälä <
> > ville.syrj...@linux.intel.com>
> > > wrote:
> > >
> > > > On Thu, Jan 09, 2020 at 05:26:57PM +0200, Ville Syrjälä wrote:
> > > > > On Thu, Jan 09, 2020 at 04:07:52PM +0100, Mario Kleiner wrote:
> > > > > > The panel reports 10 bpc color depth in its EDID, and the UEFI
> > > > > > firmware chooses link settings at boot which support enough
> > > > > > bandwidth for 10 bpc (324000 kbit/sec to be precise), but the
> > > > > > DP_MAX_LINK_RATE dpcd register only reports 2.7 Gbps as possible,
> > > >
> > > > Does it actually or do we just ignore the fact that it reports
> > 3.24Gbps?
> > > >
> > > > If it really reports 3.24 then we should be able to just add that to
> > > > dp_rates[] in intel_dp_set_sink_rates() and be done with it.
> > > >
> > > > Although we'd likely want to skip 3.24 unless it really is reported
> > > > as the max so as to not use that non-standard rate on other displays.
> > > > So would require a bit fancier logic for that.
> > > >
> > > >
> > > Was also my initial thought, but the DP_MAX_LINK_RATE reg reports 2.7
> > Gbps
> > > as maximum.
> >
> > So dpcd[0x1] == 0xa ?
> >
> >
> Yes. [*]
> 
> 
> > What about the magic second version of DP_MAX_LINK_RATE at 0x2201 ?
> > Hmm. I guess we should already be reading that via
> > intel_dp_extended_receiver_capabilities().
> >
> 
> Yes, you do.
> 
> [*] Well, i have to recheck on the machine. I started this work on the AMD
> side and checked what AMD DC gave me, haven't rechecked stuff under i915
> that i already knew from AMD. Comparing the implementations, there's some
> peculiar differences that may matter:
> 
> intel_dp_extended_receiver_capabilities() is more "paranoid" than AMD DC's
> retrieve_link_cap() function in deciding if the extended receiver caps are
> valid. Intels implementation copies only the first 6 Bytes of extended
> receiver caps into the dpcd[] arrays, whereas AMD copies 16 Bytes. Not sure
> about the differences, but one of you may wanna check why this is, and if
> it matters somehow.
> 
> Btw. your proposed
> 
> /* blah */
> if (max_rate > ...)
> 
> wouldn't work if dpcd[0x1] == 0xa, which it likely is [*]. AMD DC
> identified it as DP 1.1, eDP 1.3, and these extended caps seem to be only
> part of DP 1.3+ if i understand the comments in
> intel_dp_extended_receiver_capabilities() correctly.

Yeah, but you never know how creative they've been with the DPCD in
such a propritary machine. A full DPCD dump from /dev/drm_dp_aux* would
be nice. Can you file a bug an attach the DPCD dump there so we have a
good reference on what we're talking about (also for future if/when
someone eventually starts to wonder why we have such hacks in the
code)?

-- 
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/i915/dp: Add current maximum eDP link rate to sink_rate array.

[Mario Kleiner]

On Thu, Jan 9, 2020 at 5:47 PM Ville Syrjälä 
wrote:

> On Thu, Jan 09, 2020 at 05:30:05PM +0100, Mario Kleiner wrote:
> > On Thu, Jan 9, 2020 at 4:38 PM Ville Syrjälä <
> ville.syrj...@linux.intel.com>
> > wrote:
> >
> > > On Thu, Jan 09, 2020 at 05:26:57PM +0200, Ville Syrjälä wrote:
> > > > On Thu, Jan 09, 2020 at 04:07:52PM +0100, Mario Kleiner wrote:
> > > > > The panel reports 10 bpc color depth in its EDID, and the UEFI
> > > > > firmware chooses link settings at boot which support enough
> > > > > bandwidth for 10 bpc (324000 kbit/sec to be precise), but the
> > > > > DP_MAX_LINK_RATE dpcd register only reports 2.7 Gbps as possible,
> > >
> > > Does it actually or do we just ignore the fact that it reports
> 3.24Gbps?
> > >
> > > If it really reports 3.24 then we should be able to just add that to
> > > dp_rates[] in intel_dp_set_sink_rates() and be done with it.
> > >
> > > Although we'd likely want to skip 3.24 unless it really is reported
> > > as the max so as to not use that non-standard rate on other displays.
> > > So would require a bit fancier logic for that.
> > >
> > >
> > Was also my initial thought, but the DP_MAX_LINK_RATE reg reports 2.7
> Gbps
> > as maximum.
>
> So dpcd[0x1] == 0xa ?
>
>
Yes. [*]


> What about the magic second version of DP_MAX_LINK_RATE at 0x2201 ?
> Hmm. I guess we should already be reading that via
> intel_dp_extended_receiver_capabilities().
>

Yes, you do.

[*] Well, i have to recheck on the machine. I started this work on the AMD
side and checked what AMD DC gave me, haven't rechecked stuff under i915
that i already knew from AMD. Comparing the implementations, there's some
peculiar differences that may matter:

intel_dp_extended_receiver_capabilities() is more "paranoid" than AMD DC's
retrieve_link_cap() function in deciding if the extended receiver caps are
valid. Intels implementation copies only the first 6 Bytes of extended
receiver caps into the dpcd[] arrays, whereas AMD copies 16 Bytes. Not sure
about the differences, but one of you may wanna check why this is, and if
it matters somehow.

Btw. your proposed

/* blah */
if (max_rate > ...)

wouldn't work if dpcd[0x1] == 0xa, which it likely is [*]. AMD DC
identified it as DP 1.1, eDP 1.3, and these extended caps seem to be only
part of DP 1.3+ if i understand the comments in
intel_dp_extended_receiver_capabilities() correctly.

-mario



>
> --
> Ville Syrjälä
> Intel
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH next] drm/i915/gtt: add missing include file asm/smp.h

[Chen Zhou]

On 2020/1/8 21:44, Jani Nikula wrote:
> On Wed, 08 Jan 2020, Chen Zhou  wrote:
>> Fix build error:
>> lib/crypto/chacha.c: In function chacha_permute:
>> lib/crypto/chacha.c:65:1: warning: the frame size of 3384 bytes is larger 
>> than 2048 bytes [-Wframe-larger-than=]
>>  }
>>   ^
> 
> IMO this needs a better explanation of why not having the include leads
> to the above failure.
> 
> BR,
> Jani.
> 

Sorry, i made a mistake. The error is as follows:

drivers/gpu/drm/i915/gt/intel_ggtt.c: In function ggtt_restore_mappings:
drivers/gpu/drm/i915/gt/intel_ggtt.c:1239:3: error: implicit declaration of 
function wbinvd_on_all_cpus; did you mean wrmsr_on_cpus? 
[-Werror=implicit-function-declaration]
   wbinvd_on_all_cpus();
   ^~
   wrmsr_on_cpus


Thanks,
Chen Zhou

>>
>> Reported-by: Hulk Robot 
>> Signed-off-by: Chen Zhou 
>> ---
>>  drivers/gpu/drm/i915/gt/intel_ggtt.c | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c 
>> b/drivers/gpu/drm/i915/gt/intel_ggtt.c
>> index 1a2b5dc..9ef8ed8 100644
>> --- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
>> +++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
>> @@ -6,6 +6,7 @@
>>  #include 
>>  
>>  #include 
>> +#include 
>>  
>>  #include "intel_gt.h"
>>  #include "i915_drv.h"
> 

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

[PATCH RFC] ARM: dts: qcom: msm8974: add mdp5 iommu support

[Brian Masney]

This adds preliminary IOMMU support for the MDP5 on msm8974. It appears
that the qcom-iommu driver in upstream can be used on this SoC. I marked
this patch as a RFC since the frame buffer becomes corrupted when I boot
the Nexus 5 phone with this patch:

https://raw.githubusercontent.com/masneyb/nexus-5-upstream/master/images/broken-mdp5-iommu.jpg

A quick note about the ranges of the context banks below: Based on the
downstream sources, I believe that the memory addresses should be mapped
out like this:

mdp_iommu: iommu@fd928000 {
reg = <0xfd928000 0x8000>;
ranges = <0 0xfd93 0x8000>;
...

iommu-ctx@0 {
reg = <0x0 0x1000>;
...
};

iommu-ctx@1000 {
reg = <0x1000 0x1000>;
...
};

iommu-ctx@2000 {
reg = <0x2000 0x1000>;
...
};
};

However, the qcom-iommu driver in upstream expects the first context
bank to exist at address 0x1000, and the address space identifier
(asid) to be greater than 0. See get_asid() and qcom_iommu_of_xlate()
in the upstream qcom-iommu.c driver. I put in the patch below what the
driver expects. I modified the driver in my local tree to allow the
mapping that I have above so that the extra 0x1000 of memory is mapped
into the global address space and still experience the same screen
corruption issue.

Downstream MSM 3.4 IOMMU dts snippet for reference:
https://github.com/AICP/kernel_lge_hammerhead/blob/n7.1/arch/arm/boot/dts/msm-iommu-v1.dtsi#L110

I'm hoping that someone that's more familiar with this hardware has a
suggestion for something to try.

Signed-off-by: Brian Masney 
---
 arch/arm/boot/dts/qcom-msm8974.dtsi | 44 +
 1 file changed, 44 insertions(+)

diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi 
b/arch/arm/boot/dts/qcom-msm8974.dtsi
index 4b161b809dd5..2515a3bd4aa7 100644
--- a/arch/arm/boot/dts/qcom-msm8974.dtsi
+++ b/arch/arm/boot/dts/qcom-msm8974.dtsi
@@ -1305,6 +1305,46 @@ etm3_out: endpoint {
};
};
 
+   mdp_iommu: iommu@fd928000 {
+   compatible = "qcom,msm8974-iommu",
+"qcom,msm-iommu-v1";
+   reg = <0xfd928000 0x7000>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   #iommu-cells = <1>;
+   ranges = <0 0xfd92f000 0x9000>;
+
+   clocks = < MDSS_AHB_CLK>,
+< MDSS_AXI_CLK>;
+   clock-names = "iface",
+ "bus";
+
+   qcom,iommu-secure-id = <1>;
+
+   // mdp_0
+   iommu-ctx@1000 {
+   compatible = "qcom,msm-iommu-v1-ns";
+   reg = <0x1000 0x1000>;
+   interrupts = ;
+   };
+
+   // mdp_1
+   iommu-ctx@2000 {
+   compatible = "qcom,msm-iommu-v1-sec";
+   reg = <0x2000 0x1000>;
+   interrupts = ,
+;
+   };
+
+   // mdp_2
+   iommu-ctx@3000 {
+   compatible = "qcom,msm-iommu-v1-sec";
+   reg = <0x3000 0x1000>;
+   interrupts = ,
+;
+   };
+};
+
ocmem@fdd0 {
compatible = "qcom,msm8974-ocmem";
reg = <0xfdd0 0x2000>,
@@ -1427,6 +1467,10 @@ mdp: mdp@fd90 {
interconnects = < MNOC_MAS_MDP_PORT0 
 BIMC_SLV_EBI_CH0>;
interconnect-names = "mdp0-mem";
 
+   iommus = <_iommu 1
+ _iommu 2
+ _iommu 3>;
+
ports {
#address-cells = <1>;
#size-cells = <0>;
-- 
2.24.1

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

Re: [PATCH RFT v1 3/3] drm/panfrost: Use the mali-supply regulator for control again

[Martin Blumenstingl]

On Thu, Jan 9, 2020 at 12:31 PM Steven Price  wrote:
>
> On 07/01/2020 23:06, Martin Blumenstingl wrote:
> > dev_pm_opp_set_rate() needs a reference to the regulator which should be
> > updated when updating the GPU frequency. The name of the regulator has
> > to be passed at initialization-time using dev_pm_opp_set_regulators().
> > Add the call to dev_pm_opp_set_regulators() so dev_pm_opp_set_rate()
> > will update the GPU regulator when updating the frequency (just like
> > we did this manually before when we open-coded dev_pm_opp_set_rate()).
>
> This patch causes a warning from debugfs on my firefly (RK3288) board:
>
> debugfs: Directory 'ffa3.gpu-mali' with parent 'vdd_gpu' already
> present!
>
> So it looks like the regulator is being added twice - but I haven't
> investigated further.
I *think* it's because the regulator is already fetched by the
panfrost driver itself to enable it
(the devfreq code currently does not support enabling the regulator,
it can only control the voltage)

I'm not sure what to do about this though

[...]
> >   ret = dev_pm_opp_of_add_table(dev);
> > - if (ret)
> > + if (ret) {
> > + 
> > dev_pm_opp_put_regulators(pfdev->devfreq.regulators_opp_table);
>
> If we don't have a regulator then regulators_opp_table will be NULL and
> sadly dev_pm_opp_put_regulators() doesn't handle a NULL argument. The
> same applies to the two below calls obviously.
good catch, thank you!
are you happy with the general approach here or do you think that
dev_pm_opp_set_regulators is the wrong way to go (for whatever
reason)?


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

[PATCH v2] drm/hisilicon: Add the mode_valid function

[Tian Tao]

add mode_valid function, we can make sure the resolution is valid.

Signed-off-by: Tian Tao 
Signed-off-by: Gong junjie 
Reviewed-by: Thomas Zimmermann 

---
v2: declare hibmc_crtc_mode_valid as static.
Modify the return value of hibmc_crtc_mode_valid .
---
 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c 
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
index 843d784..675d629 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
@@ -242,6 +242,24 @@ static void hibmc_crtc_atomic_disable(struct drm_crtc 
*crtc,
hibmc_set_current_gate(priv, reg);
 }
 
+static enum drm_mode_status hibmc_crtc_mode_valid(struct drm_crtc *crtc,
+   const struct drm_display_mode *mode)
+{
+   int i = 0;
+   int vrefresh = drm_mode_vrefresh(mode);
+
+   if (vrefresh < 59 || vrefresh > 61)
+   return MODE_NOCLOCK;
+
+   for (i = 0; i < ARRAY_SIZE(hibmc_pll_table); i++) {
+   if (hibmc_pll_table[i].hdisplay == mode->hdisplay &&
+   hibmc_pll_table[i].vdisplay == mode->vdisplay)
+   return MODE_OK;
+   }
+
+   return MODE_BAD;
+}
+
 static unsigned int format_pll_reg(void)
 {
unsigned int pllreg = 0;
@@ -510,6 +528,7 @@ static const struct drm_crtc_helper_funcs 
hibmc_crtc_helper_funcs = {
.atomic_flush   = hibmc_crtc_atomic_flush,
.atomic_enable  = hibmc_crtc_atomic_enable,
.atomic_disable = hibmc_crtc_atomic_disable,
+   .mode_valid = hibmc_crtc_mode_valid,
 };
 
 int hibmc_de_init(struct hibmc_drm_private *priv)
-- 
2.7.4

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

[PATCH 2/2] dt-bindings: panel-simple: Add compatible for Sharp LS020B1DD01D

[Paul Cercueil]

Add a compatible string for the Sharp LS020B1DD01D 2" HQVGA TFT LCD
panel, and remove the old sharp,ls020b1dd01d.txt documentation which is
now obsolete.

Signed-off-by: Paul Cercueil 
---
 .../bindings/display/panel/panel-simple.yaml |  2 ++
 .../bindings/display/panel/sharp,ls020b1dd01d.txt| 12 
 2 files changed, 2 insertions(+), 12 deletions(-)
 delete mode 100644 
Documentation/devicetree/bindings/display/panel/sharp,ls020b1dd01d.txt

diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml 
b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
index c1a77d9105a2..f1fba1db382a 100644
--- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
+++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
@@ -35,6 +35,8 @@ properties:
   - ampire,am800480r3tmqwa1h
 # GiantPlus GPM940B0 3.0" QVGA TFT LCD panel
   - giantplus,gpm940b0
+# Sharp LS020B1DD01D 2.0" HQVGA TFT LCD panel
+  - sharp,ls020b1dd01d
 
   backlight: true
   enable-gpios: true
diff --git 
a/Documentation/devicetree/bindings/display/panel/sharp,ls020b1dd01d.txt 
b/Documentation/devicetree/bindings/display/panel/sharp,ls020b1dd01d.txt
deleted file mode 100644
index e45edbc565a3..
--- a/Documentation/devicetree/bindings/display/panel/sharp,ls020b1dd01d.txt
+++ /dev/null
@@ -1,12 +0,0 @@
-Sharp 2.0" (240x160 pixels) 16-bit TFT LCD panel
-
-Required properties:
-- compatible: should be "sharp,ls020b1dd01d"
-- power-supply: as specified in the base binding
-
-Optional properties:
-- backlight: as specified in the base binding
-- enable-gpios: as specified in the base binding
-
-This binding is compatible with the simple-panel binding, which is specified
-in simple-panel.txt in this directory.
-- 
2.24.1

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

Re: [PATCH] drm/omap: gem: Fix tearing with BO_TILED

[Tony Lindgren]

* Matthijs van Duin  [200106 10:07]:
> On Sun, Jan 05, 2020 at 12:37:04PM -0800, Tony Lindgren wrote:
> > 4. The issue I'm seeing with stellarium on droid4 may be a stride
> >issue as about one out of 3 or 4 frames is OK and aligning to
> >512 also fixes the issue maybe because it happens to make
> >multiple frames align to 4096
> 
> Yeah if your buffers are 960 pixels wide (assuming the droid4's screen
> is natively portrait) and 32bpp then 512-byte alignment suffices to
> automatically make them 4KB alignment.

Hmm sounds like I need to retest this. But doesn't 512-byte alignment
only make the 960 pixels case 2KB aligned?

> The most obvious thing I can think of that could do wrong is that it
> might contiguously map the pages that cover each line, which is what
> will happen if they use e.g. for_each_sg_page, but subsequently assume
> that the stride in sgx virtual memory is ALIGN( width * cpp, PAGE_SIZE )
> without taking the offset of the buffer inside the mapping into account.

OK

> If each line is at most 4KB (i.e. 1024 pixels @ 32bpp) but each line
> straddles an MMU page boundary, then the result would be that the even
> lines of the frame are written to the top half of the buffer, causing it
> to be scaled to 50% vertically, while the odd lines are "lost" (written
> outside the buffer, either to a different buffer or unmapped tiler
> memory).  This sounds like what you described on irc?

Yes this sounds like what I've been seeing.

Regards,

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

[PATCH next v2] drm/i915/gtt: add missing include file asm/smp.h

[Chen Zhou]

Fix build error:
drivers/gpu/drm/i915/gt/intel_ggtt.c: In function ggtt_restore_mappings:
drivers/gpu/drm/i915/gt/intel_ggtt.c:1239:3: error:
implicit declaration of function wbinvd_on_all_cpus; did you mean 
wrmsr_on_cpus? [-Werror=implicit-function-declaration]
   wbinvd_on_all_cpus();
  ^~
 wrmsr_on_cpus

Reported-by: Hulk Robot 
Signed-off-by: Chen Zhou 
---

changes in v2:
- correct build error messages.

---
 drivers/gpu/drm/i915/gt/intel_ggtt.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c 
b/drivers/gpu/drm/i915/gt/intel_ggtt.c
index 1a2b5dc..9ef8ed8 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
@@ -6,6 +6,7 @@
 #include 
 
 #include 
+#include 
 
 #include "intel_gt.h"
 #include "i915_drv.h"
-- 
2.7.4

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

Re: [RFT 00/13] iomap: Constify ioreadX() iomem argument

[Christophe Leroy]

Le 08/01/2020 à 09:18, Krzysztof Kozlowski a écrit :

On Wed, 8 Jan 2020 at 09:13, Geert Uytterhoeven  wrote:


Hi Krzysztof,

On Wed, Jan 8, 2020 at 9:07 AM Geert Uytterhoeven  wrote:

On Tue, Jan 7, 2020 at 5:53 PM Krzysztof Kozlowski  wrote:

The ioread8/16/32() and others have inconsistent interface among the
architectures: some taking address as const, some not.

It seems there is nothing really stopping all of them to take
pointer to const.


Shouldn't all of them take const volatile __iomem pointers?
It seems the "volatile" is missing from all but the implementations in
include/asm-generic/io.h.


As my "volatile" comment applies to iowrite*(), too, probably that should be
done in a separate patch.

Hence with patches 1-5 squashed, and for patches 11-13:
Reviewed-by: Geert Uytterhoeven 


I'll add to this one also changes to ioreadX_rep() and add another
patch for volatile for reads and writes. I guess your review will be
appreciated once more because of ioreadX_rep()



volatile should really only be used where deemed necessary:

https://www.kernel.org/doc/html/latest/process/volatile-considered-harmful.html

It is said: " ...  accessor functions might use volatile on 
architectures where direct I/O memory access does work. Essentially, 
each accessor call becomes a little critical section on its own and 
ensures that the access happens as expected by the programmer."


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

Re: [PATCH] drm/fb-cma-helpers: Fix include issue

[Benjamin GAIGNARD]

On 12/3/19 5:49 PM, Benjamin Gaignard wrote:
> Le mer. 20 nov. 2019 à 00:28, Benjamin Gaignard
>  a écrit :
>> Exported functions prototypes are missing in drm_fb_cma_helper.c
>> Include drm_fb_cma_helper to fix that issue.
>>
> Gentle ping to reviewers.
> Thanks,
> Benjamin

I know that removing warnings is not a sexy task, but reviewers are welcome.

Thanks,

Benjamin

>
>> Signed-off-by: Benjamin Gaignard 
>> ---
>>   drivers/gpu/drm/drm_fb_cma_helper.c | 1 +
>>   include/drm/drm_fb_cma_helper.h | 2 ++
>>   2 files changed, 3 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c 
>> b/drivers/gpu/drm/drm_fb_cma_helper.c
>> index c0b0f603af63..9801c0333eca 100644
>> --- a/drivers/gpu/drm/drm_fb_cma_helper.c
>> +++ b/drivers/gpu/drm/drm_fb_cma_helper.c
>> @@ -9,6 +9,7 @@
>>*  Copyright (C) 2012 Red Hat
>>*/
>>
>> +#include 
>>   #include 
>>   #include 
>>   #include 
>> diff --git a/include/drm/drm_fb_cma_helper.h 
>> b/include/drm/drm_fb_cma_helper.h
>> index 4becb09975a4..795aea1d0a25 100644
>> --- a/include/drm/drm_fb_cma_helper.h
>> +++ b/include/drm/drm_fb_cma_helper.h
>> @@ -2,6 +2,8 @@
>>   #ifndef __DRM_FB_CMA_HELPER_H__
>>   #define __DRM_FB_CMA_HELPER_H__
>>
>> +#include 
>> +
>>   struct drm_framebuffer;
>>   struct drm_plane_state;
>>
>> --
>> 2.15.0
>>
>> ___
>> 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

[PATCH 0/5] Use new logging macros in drm/i915

[Wambui Karuga]

This patchset continues the conversion to using the new struct
drm_device based logging macros in drm/i915.

Wambui Karuga (5):
  drm/i915: conversion to new logging macros in i915/i915_vgpu.c
  drm/i915: conversion to new logging macros in i915/intel_csr.c
  drm/i915: conversion to new logging macros in i915/intel_device_info.c
  drm/i915: convert to new logging macros in i915/intel_gvt.c
  drm/i915: convert to new logging macros in i915/intel_memory_region.c

 drivers/gpu/drm/i915/i915_vgpu.c   | 41 +-
 drivers/gpu/drm/i915/intel_csr.c   | 24 +++--
 drivers/gpu/drm/i915/intel_device_info.c   | 25 +++--
 drivers/gpu/drm/i915/intel_gvt.c   | 13 ---
 drivers/gpu/drm/i915/intel_memory_region.c |  4 ++-
 5 files changed, 64 insertions(+), 43 deletions(-)

-- 
2.24.1

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

[PATCH 2/5] drm/i915: conversion to new logging macros in i915/intel_csr.c

[Wambui Karuga]

Replace the use of printk and struct device based logging macros with
the new struct drm_device based logging macros in i915/intel_csr.c

Signed-off-by: Wambui Karuga 
---
 drivers/gpu/drm/i915/intel_csr.c | 24 ++--
 1 file changed, 14 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_csr.c b/drivers/gpu/drm/i915/intel_csr.c
index 09870a31b4f0..85e41db7dc0e 100644
--- a/drivers/gpu/drm/i915/intel_csr.c
+++ b/drivers/gpu/drm/i915/intel_csr.c
@@ -298,12 +298,14 @@ void intel_csr_load_program(struct drm_i915_private 
*dev_priv)
u32 i, fw_size;
 
if (!HAS_CSR(dev_priv)) {
-   DRM_ERROR("No CSR support available for this platform\n");
+   drm_err(_priv->drm,
+   "No CSR support available for this platform\n");
return;
}
 
if (!dev_priv->csr.dmc_payload) {
-   DRM_ERROR("Tried to program CSR with empty payload\n");
+   drm_err(_priv->drm,
+   "Tried to program CSR with empty payload\n");
return;
}
 
@@ -636,16 +638,16 @@ static void csr_load_work_fn(struct work_struct *work)
intel_csr_load_program(dev_priv);
intel_csr_runtime_pm_put(dev_priv);
 
-   DRM_INFO("Finished loading DMC firmware %s (v%u.%u)\n",
-dev_priv->csr.fw_path,
-CSR_VERSION_MAJOR(csr->version),
+   drm_info(_priv->drm,
+"Finished loading DMC firmware %s (v%u.%u)\n",
+dev_priv->csr.fw_path, CSR_VERSION_MAJOR(csr->version),
 CSR_VERSION_MINOR(csr->version));
} else {
-   dev_notice(dev_priv->drm.dev,
+   drm_notice(_priv->drm,
   "Failed to load DMC firmware %s."
   " Disabling runtime power management.\n",
   csr->fw_path);
-   dev_notice(dev_priv->drm.dev, "DMC firmware homepage: %s",
+   drm_notice(_priv->drm, "DMC firmware homepage: %s",
   INTEL_UC_FIRMWARE_URL);
}
 
@@ -712,7 +714,8 @@ void intel_csr_ucode_init(struct drm_i915_private *dev_priv)
if (i915_modparams.dmc_firmware_path) {
if (strlen(i915_modparams.dmc_firmware_path) == 0) {
csr->fw_path = NULL;
-   DRM_INFO("Disabling CSR firmware and runtime PM\n");
+   drm_info(_priv->drm,
+"Disabling CSR firmware and runtime PM\n");
return;
}
 
@@ -722,11 +725,12 @@ void intel_csr_ucode_init(struct drm_i915_private 
*dev_priv)
}
 
if (csr->fw_path == NULL) {
-   DRM_DEBUG_KMS("No known CSR firmware for platform, disabling 
runtime PM\n");
+   drm_dbg_kms(_priv->drm,
+   "No known CSR firmware for platform, disabling 
runtime PM\n");
return;
}
 
-   DRM_DEBUG_KMS("Loading %s\n", csr->fw_path);
+   drm_dbg_kms(_priv->drm, "Loading %s\n", csr->fw_path);
schedule_work(_priv->csr.work);
 }
 
-- 
2.24.1

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

Re: [PATCH] drm/modes: tag unused variables to avoid warnings

[Benjamin GAIGNARD]

On 1/7/20 2:24 PM, Thomas Zimmermann wrote:
> Hi
>
> Am 10.12.19 um 11:24 schrieb Benjamin Gaignard:
>> Some variables are set but never used. To avoid warning when compiling
>> with W=1 and keep the algorithm like it is tag theses variables
>> with _maybe_unused macro.
>>
>> Signed-off-by: Benjamin Gaignard 
> Acked-by: Thomas Zimmermann 

Applied on drm-misc-next.

Thanks,

Benjamin

>
>> ---
>> changes in this version:
>> - do not modify the code to remove the unused variables
>>just prefix them with __maybe_unused macro.
>>
>>   drivers/gpu/drm/drm_modes.c | 9 +
>>   1 file changed, 5 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
>> index 88232698d7a0..70aed4e2990d 100644
>> --- a/drivers/gpu/drm/drm_modes.c
>> +++ b/drivers/gpu/drm/drm_modes.c
>> @@ -233,7 +233,7 @@ struct drm_display_mode *drm_cvt_mode(struct drm_device 
>> *dev, int hdisplay,
>>  /* 3) Nominal HSync width (% of line period) - default 8 */
>>   #define CVT_HSYNC_PERCENTAGE   8
>>  unsigned int hblank_percentage;
>> -int vsyncandback_porch, vback_porch, hblank;
>> +int vsyncandback_porch, __maybe_unused vback_porch, hblank;
>>   
>>  /* estimated the horizontal period */
>>  tmp1 = HV_FACTOR * 100  -
>> @@ -386,9 +386,10 @@ drm_gtf_mode_complex(struct drm_device *dev, int 
>> hdisplay, int vdisplay,
>>  int top_margin, bottom_margin;
>>  int interlace;
>>  unsigned int hfreq_est;
>> -int vsync_plus_bp, vback_porch;
>> -unsigned int vtotal_lines, vfieldrate_est, hperiod;
>> -unsigned int vfield_rate, vframe_rate;
>> +int vsync_plus_bp, __maybe_unused vback_porch;
>> +unsigned int vtotal_lines, __maybe_unused vfieldrate_est;
>> +unsigned int __maybe_unused hperiod;
>> +unsigned int vfield_rate, __maybe_unused vframe_rate;
>>  int left_margin, right_margin;
>>  unsigned int total_active_pixels, ideal_duty_cycle;
>>  unsigned int hblank, total_pixels, pixel_freq;
>>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 5/5] drm/i915: convert to new logging macros in i915/intel_memory_region.c

[Wambui Karuga]

Replace the use of printk based logging macros with the new struct
drm_device based logging macro in i915/intel_memory_region.c.

Signed-off-by: Wambui Karuga 
---
 drivers/gpu/drm/i915/intel_memory_region.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_memory_region.c 
b/drivers/gpu/drm/i915/intel_memory_region.c
index d0d038b3cd79..6b5e9d88646d 100644
--- a/drivers/gpu/drm/i915/intel_memory_region.c
+++ b/drivers/gpu/drm/i915/intel_memory_region.c
@@ -265,7 +265,9 @@ int intel_memory_regions_hw_probe(struct drm_i915_private 
*i915)
 
if (IS_ERR(mem)) {
err = PTR_ERR(mem);
-   DRM_ERROR("Failed to setup region(%d) type=%d\n", err, 
type);
+   drm_err(>drm,
+   "Failed to setup region(%d) type=%d\n",
+   err, type);
goto out_cleanup;
}
 
-- 
2.24.1

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

Re: [PATCH 0/2] drm/radeon: have the callers of set_memory_*() check the return value

[Tianlin Li]

> On Jan 8, 2020, at 6:56 AM, Christian König  wrote:
> 
> Am 07.01.20 um 20:25 schrieb Tianlin Li:
>> Right now several architectures allow their set_memory_*() family of
>> functions to fail, but callers may not be checking the return values.
>> If set_memory_*() returns with an error, call-site assumptions may be
>> infact wrong to assume that it would either succeed or not succeed at
>> all. Ideally, the failure of set_memory_*() should be passed up the
>> call stack, and callers should examine the failure and deal with it.
>> 
>> Need to fix the callers and add the __must_check attribute. They also
>> may not provide any level of atomicity, in the sense that the memory
>> protections may be left incomplete on failure. This issue likely has a
>> few steps on effects architectures:
>> 1)Have all callers of set_memory_*() helpers check the return value.
>> 2)Add __must_check to all set_memory_*() helpers so that new uses do
>> not ignore the return value.
>> 3)Add atomicity to the calls so that the memory protections aren't left
>> in a partial state.
>> 
>> This series is part of step 1. Make drm/radeon check the return value of
>> set_memory_*().
> 
> I'm a little hesitate merge that. This hardware is >15 years old and nobody 
> of the developers have any system left to test this change on.
> 
> Would it be to much of a problem to just add something like: r = 
> set_memory_*(); (void)r; /* Intentionally ignored */.

Thank you. I will fix that in patch 1 and remove patch 2 (since no need to fix 
the call sites to handle the retval). 

Best regards,
Tianlin
> Apart from that certainly a good idea to add __must_check to the functions.
> 
> Regards,
> Christian.
> 
>> 
>> Tianlin Li (2):
>>   drm/radeon: have the callers of set_memory_*() check the return value
>>   drm/radeon: change call sites to handle return value properly.
>> 
>>  drivers/gpu/drm/radeon/r100.c|  3 ++-
>>  drivers/gpu/drm/radeon/radeon.h  |  2 +-
>>  drivers/gpu/drm/radeon/radeon_gart.c | 22 ++
>>  drivers/gpu/drm/radeon/rs400.c   |  3 ++-
>>  4 files changed, 23 insertions(+), 7 deletions(-)

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

[PATCH next] drm/i915/gtt: add missing include file asm/smp.h

[Chen Zhou]

Fix build error:
lib/crypto/chacha.c: In function chacha_permute:
lib/crypto/chacha.c:65:1: warning: the frame size of 3384 bytes is larger than 
2048 bytes [-Wframe-larger-than=]
 }
  ^

Reported-by: Hulk Robot 
Signed-off-by: Chen Zhou 
---
 drivers/gpu/drm/i915/gt/intel_ggtt.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c 
b/drivers/gpu/drm/i915/gt/intel_ggtt.c
index 1a2b5dc..9ef8ed8 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
@@ -6,6 +6,7 @@
 #include 
 
 #include 
+#include 
 
 #include "intel_gt.h"
 #include "i915_drv.h"
-- 
2.7.4

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

Re: [PATCH 1/3] drm/msm: support firmware-name for zap fw

[Bjorn Andersson]

On Wed 08 Jan 10:48 PST 2020, Jordan Crouse wrote:

> On Tue, Jan 07, 2020 at 05:38:42PM -0800, Rob Clark wrote:
> > From: Rob Clark 
> > 
> > Since zap firmware can be device specific, allow for a firmware-name
> > property in the zap node to specify which firmware to load, similarly to
> > the scheme used for dsp/wifi/etc.
> > 
> > Signed-off-by: Rob Clark 
> > ---
> >  drivers/gpu/drm/msm/adreno/adreno_gpu.c | 32 ++---
> >  1 file changed, 29 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c 
> > b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> > index 112e8b8a261e..aa8737bd58db 100644
> > --- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> > +++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> > @@ -26,6 +26,7 @@ static int zap_shader_load_mdt(struct msm_gpu *gpu, const 
> > char *fwname,
> >  {
> > struct device *dev = >pdev->dev;
> > const struct firmware *fw;
> > +   const char *signed_fwname = NULL;
> > struct device_node *np, *mem_np;
> > struct resource r;
> > phys_addr_t mem_phys;
> > @@ -58,8 +59,33 @@ static int zap_shader_load_mdt(struct msm_gpu *gpu, 
> > const char *fwname,
> >  
> > mem_phys = r.start;
> >  
> > -   /* Request the MDT file for the firmware */
> > -   fw = adreno_request_fw(to_adreno_gpu(gpu), fwname);
> > +   /*
> > +* Check for a firmware-name property.  This is the new scheme
> > +* to handle firmware that may be signed with device specific
> > +* keys, allowing us to have a different zap fw path for different
> > +* devices.
> > +*
> > +* If the firmware-name property is found, we bypass the
> > +* adreno_request_fw() mechanism, because we don't need to handle
> > +* the /lib/firmware/qcom/* vs /lib/firmware/* case.
> > +*
> > +* If the firmware-name property is not found, for backwards
> > +* compatibility we fall back to the fwname from the gpulist
> > +* table.
> > +*/
> > +   of_property_read_string_index(np, "firmware-name", 0, _fwname);
> > +   if (signed_fwname) {
> > +   fwname = signed_fwname;
> > +   ret = request_firmware_direct(, signed_fwname, 
> > gpu->dev->dev);
> > +   if (ret) {
> > +   DRM_DEV_ERROR(dev, "could not load signed zap firmware: 
> > %d\n", ret);
> > +   fw = ERR_PTR(ret);
> > +   }
> > +   } else {
> > +   /* Request the MDT file for the firmware */
> > +   fw = adreno_request_fw(to_adreno_gpu(gpu), fwname);
> > +   }
> > +
> 
> Since DT seems to be the trend for target specific firmware names I think we
> should plan to quickly deprecate the legacy name and not require new targets 
> to
> set it. If a zap node is going to be opt in then it isn't onerous to ask
> the developer to set the additional property for each target platform.
> 

For the zap specifically I agree that it would be nice to require this
property, but for non-zap firmware it seems reasonable to continue with
the existing scheme.

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

Re: [PATCH] drm/panfrost: Remove core stack power management

[Alyssa Rosenzweig]

A-b

On Thu, Jan 09, 2020 at 01:31:04PM +, Steven Price wrote:
> Explict management of the GPU's core stacks is only necessary in the
> case of a broken integration with the PDC. Since there are no known
> platforms which have such a broken integration let's remove the explict
> control from the driver since this apparently causes problems on other
> platforms and will have a small performance penality.
> 
> The out of tree mali_kbase driver contains this text regarding
> controlling the core stack (CONFIGMALI_CORESTACK):
> 
>   Enabling this feature on supported GPUs will let the driver powering
>   on/off the GPU core stack independently without involving the Power
>   Domain Controller. This should only be enabled on platforms which
>   integration of the PDC to the Mali GPU is known to be problematic.
>   This feature is currently only supported on t-Six and t-HEx GPUs.
> 
>   If unsure, say N.
> 
> Signed-off-by: Steven Price 
> ---
>  drivers/gpu/drm/panfrost/panfrost_gpu.c | 5 -
>  1 file changed, 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/panfrost/panfrost_gpu.c 
> b/drivers/gpu/drm/panfrost/panfrost_gpu.c
> index 8822ec13a0d6..460fc190de6e 100644
> --- a/drivers/gpu/drm/panfrost/panfrost_gpu.c
> +++ b/drivers/gpu/drm/panfrost/panfrost_gpu.c
> @@ -309,10 +309,6 @@ void panfrost_gpu_power_on(struct panfrost_device *pfdev)
>   ret = readl_relaxed_poll_timeout(pfdev->iomem + L2_READY_LO,
>   val, val == pfdev->features.l2_present, 100, 1000);
>  
> - gpu_write(pfdev, STACK_PWRON_LO, pfdev->features.stack_present);
> - ret |= readl_relaxed_poll_timeout(pfdev->iomem + STACK_READY_LO,
> - val, val == pfdev->features.stack_present, 100, 1000);
> -
>   gpu_write(pfdev, SHADER_PWRON_LO, pfdev->features.shader_present);
>   ret |= readl_relaxed_poll_timeout(pfdev->iomem + SHADER_READY_LO,
>   val, val == pfdev->features.shader_present, 100, 1000);
> @@ -329,7 +325,6 @@ void panfrost_gpu_power_off(struct panfrost_device *pfdev)
>  {
>   gpu_write(pfdev, TILER_PWROFF_LO, 0);
>   gpu_write(pfdev, SHADER_PWROFF_LO, 0);
> - gpu_write(pfdev, STACK_PWROFF_LO, 0);
>   gpu_write(pfdev, L2_PWROFF_LO, 0);
>  }
>  
> -- 
> 2.20.1
> 


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

[PATCH] drm/mediatek: check for comp->funcs

[Hsin-Yi Wang]

There might be some comp that doesn't have funcs, eg. hdmi-connector.
Check for comp->funcs otherwise there will be NULL pointer dereference
crash.

Fixes: bd3de8cd782b ("drm/mediatek: Add gamma property according to hardware 
capability")
Fixes: 7395eab077f9 ("drm/mediatek: Add ctm property support")
Signed-off-by: Hsin-Yi Wang 
---
This patch is based on mediatek's drm branch:
https://github.com/ckhu-mediatek/linux.git-tags/commits/mediatek-drm-next-5.6

After
https://patchwork.freedesktop.org/patch/344477/?series=63328=59,
there will also be funcs for hdmi-connector.
---
 drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c 
b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
index fb142fcfc353..7b392d6c71cc 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
@@ -808,11 +808,13 @@ int mtk_drm_crtc_create(struct drm_device *drm_dev,
 
mtk_crtc->ddp_comp[i] = comp;
 
-   if (comp->funcs->ctm_set)
-   has_ctm = true;
+   if (comp->funcs) {
+   if (comp->funcs->ctm_set)
+   has_ctm = true;
 
-   if (comp->funcs->gamma_set)
-   gamma_lut_size = MTK_LUT_SIZE;
+   if (comp->funcs->gamma_set)
+   gamma_lut_size = MTK_LUT_SIZE;
+   }
}
 
for (i = 0; i < mtk_crtc->ddp_comp_nr; i++)
-- 
2.25.0.rc1.283.g88dfdc4193-goog

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

[PATCH 1/5] drm/i915: conversion to new logging macros in i915/i915_vgpu.c

[Wambui Karuga]

Replace the use of printk based logging macros with the struct
drm_device based macros in i915/i915_vgpu.c

Signed-off-by: Wambui Karuga 
---
 drivers/gpu/drm/i915/i915_vgpu.c | 41 +++-
 1 file changed, 25 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_vgpu.c b/drivers/gpu/drm/i915/i915_vgpu.c
index 968be26735c5..4afe21662266 100644
--- a/drivers/gpu/drm/i915/i915_vgpu.c
+++ b/drivers/gpu/drm/i915/i915_vgpu.c
@@ -77,7 +77,8 @@ void i915_detect_vgpu(struct drm_i915_private *dev_priv)
 
shared_area = pci_iomap_range(pdev, 0, VGT_PVINFO_PAGE, 
VGT_PVINFO_SIZE);
if (!shared_area) {
-   DRM_ERROR("failed to map MMIO bar to check for VGT\n");
+   drm_err(_priv->drm,
+   "failed to map MMIO bar to check for VGT\n");
return;
}
 
@@ -87,7 +88,7 @@ void i915_detect_vgpu(struct drm_i915_private *dev_priv)
 
version_major = readw(shared_area + vgtif_offset(version_major));
if (version_major < VGT_VERSION_MAJOR) {
-   DRM_INFO("VGT interface version mismatch!\n");
+   drm_info(_priv->drm, "VGT interface version mismatch!\n");
goto out;
}
 
@@ -95,7 +96,7 @@ void i915_detect_vgpu(struct drm_i915_private *dev_priv)
 
dev_priv->vgpu.active = true;
mutex_init(_priv->vgpu.lock);
-   DRM_INFO("Virtual GPU for Intel GVT-g detected.\n");
+   drm_info(_priv->drm, "Virtual GPU for Intel GVT-g detected.\n");
 
 out:
pci_iounmap(pdev, shared_area);
@@ -120,13 +121,15 @@ static struct _balloon_info_ bl_info;
 static void vgt_deballoon_space(struct i915_ggtt *ggtt,
struct drm_mm_node *node)
 {
+   struct drm_i915_private *dev_priv = ggtt->vm.i915;
if (!drm_mm_node_allocated(node))
return;
 
-   DRM_DEBUG_DRIVER("deballoon space: range [0x%llx - 0x%llx] %llu KiB.\n",
-node->start,
-node->start + node->size,
-node->size / 1024);
+   drm_dbg(_priv->drm,
+   "deballoon space: range [0x%llx - 0x%llx] %llu KiB.\n",
+   node->start,
+   node->start + node->size,
+   node->size / 1024);
 
ggtt->vm.reserved -= node->size;
drm_mm_remove_node(node);
@@ -141,12 +144,13 @@ static void vgt_deballoon_space(struct i915_ggtt *ggtt,
  */
 void intel_vgt_deballoon(struct i915_ggtt *ggtt)
 {
+   struct drm_i915_private *dev_priv = ggtt->vm.i915;
int i;
 
if (!intel_vgpu_active(ggtt->vm.i915))
return;
 
-   DRM_DEBUG("VGT deballoon.\n");
+   drm_dbg(_priv->drm, "VGT deballoon.\n");
 
for (i = 0; i < 4; i++)
vgt_deballoon_space(ggtt, _info.space[i]);
@@ -156,13 +160,15 @@ static int vgt_balloon_space(struct i915_ggtt *ggtt,
 struct drm_mm_node *node,
 unsigned long start, unsigned long end)
 {
+   struct drm_i915_private *dev_priv = ggtt->vm.i915;
unsigned long size = end - start;
int ret;
 
if (start >= end)
return -EINVAL;
 
-   DRM_INFO("balloon space: range [ 0x%lx - 0x%lx ] %lu KiB.\n",
+   drm_info(_priv->drm,
+"balloon space: range [ 0x%lx - 0x%lx ] %lu KiB.\n",
 start, end, size / 1024);
ret = i915_gem_gtt_reserve(>vm, node,
   size, start, I915_COLOR_UNEVICTABLE,
@@ -219,7 +225,8 @@ static int vgt_balloon_space(struct i915_ggtt *ggtt,
  */
 int intel_vgt_balloon(struct i915_ggtt *ggtt)
 {
-   struct intel_uncore *uncore = >vm.i915->uncore;
+   struct drm_i915_private *dev_priv = ggtt->vm.i915;
+   struct intel_uncore *uncore = _priv->uncore;
unsigned long ggtt_end = ggtt->vm.total;
 
unsigned long mappable_base, mappable_size, mappable_end;
@@ -241,16 +248,18 @@ int intel_vgt_balloon(struct i915_ggtt *ggtt)
mappable_end = mappable_base + mappable_size;
unmappable_end = unmappable_base + unmappable_size;
 
-   DRM_INFO("VGT ballooning configuration:\n");
-   DRM_INFO("Mappable graphic memory: base 0x%lx size %ldKiB\n",
+   drm_info(_priv->drm, "VGT ballooning configuration:\n");
+   drm_info(_priv->drm,
+"Mappable graphic memory: base 0x%lx size %ldKiB\n",
 mappable_base, mappable_size / 1024);
-   DRM_INFO("Unmappable graphic memory: base 0x%lx size %ldKiB\n",
+   drm_info(_priv->drm,
+"Unmappable graphic memory: base 0x%lx size %ldKiB\n",
 unmappable_base, unmappable_size / 1024);
 
if (mappable_end > ggtt->mappable_end ||
unmappable_base < ggtt->mappable_end ||
unmappable_end > ggtt_end) {
-   DRM_ERROR("Invalid ballooning configuration!\n");
+   drm_err(_priv->drm, "Invalid ballooning 

[PATCH] drm/hisilicon: add the mode_valid function

[Tian Tao]

add mode_valid function, and we can also use it to make suse the resolution
is valid.

Signed-off-by: Tian Tao 
Signed-off-by: Gong junjie 
---
 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c | 20 
 1 file changed, 20 insertions(+)

diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c 
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
index 843d784..6cb7a79 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
@@ -242,6 +242,25 @@ static void hibmc_crtc_atomic_disable(struct drm_crtc 
*crtc,
hibmc_set_current_gate(priv, reg);
 }
 
+enum drm_mode_status hibmc_crtc_mode_valid(struct drm_crtc *crtc,
+   const struct drm_display_mode *mode)
+{
+   int i = 0;
+   int vrefresh = drm_mode_vrefresh(mode);
+
+   if (vrefresh < 59 || vrefresh > 61)
+   return MODE_NOMODE;
+
+   for (i = 0; i < ARRAY_SIZE(hibmc_pll_table); i++) {
+   if (hibmc_pll_table[i].hdisplay == mode->hdisplay &&
+   hibmc_pll_table[i].vdisplay == mode->vdisplay)
+   return MODE_OK;
+   }
+
+   return MODE_NOMODE;
+}
+
+
 static unsigned int format_pll_reg(void)
 {
unsigned int pllreg = 0;
@@ -510,6 +529,7 @@ static const struct drm_crtc_helper_funcs 
hibmc_crtc_helper_funcs = {
.atomic_flush   = hibmc_crtc_atomic_flush,
.atomic_enable  = hibmc_crtc_atomic_enable,
.atomic_disable = hibmc_crtc_atomic_disable,
+   .mode_valid = hibmc_crtc_mode_valid,
 };
 
 int hibmc_de_init(struct hibmc_drm_private *priv)
-- 
2.7.4

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

Re: [PATCH v2 0/7] Add dts for mt8183 GPU (and misc panfrost patches)

[Alyssa Rosenzweig]

Patches 1,2,3,6 are:

Reviewed-by: Alyssa Rosenzweig 

The remaining patches in the series are Acked-by.

Reportedly the kernel should work on certain Bifrost boards more or less
as-is, but I'm not positive about the details. It's possible some of
these are G72-specific or MT-specific issues; Robin and Stephen will
know more.

Very nice work so far!

Alyssa

On Wed, Jan 08, 2020 at 01:23:30PM +0800, Nicolas Boichat wrote:
> Hi!
> 
> Sorry for the long delay since https://patchwork.kernel.org/patch/11132381/,
> finally got around to give this a real try.
> 
> The main purpose of this series is to upstream the dts change and the binding
> document, but I wanted to see how far I could probe the GPU, to check that the
> binding is indeed correct. The rest of the patches are RFC/work-in-progress, 
> but
> I think some of them could already be picked up.
> 
> So this is tested on MT8183 with a chromeos-4.19 kernel, and a ton of
> backports to get the latest panfrost driver (I should probably try on
> linux-next at some point but this was the path of least resistance).
> 
> I tested it as a module as it's more challenging (originally probing would
> work built-in, on boot, but not as a module, as I didn't have the power
> domain changes, and all power domains are on by default during boot).
> 
> Probing logs looks like this, currently:
> [  221.867726] panfrost 1304.gpu: clock rate = 51170
> [  221.867929] panfrost 1304.gpu: Linked as a consumer to regulator.14
> [  221.868600] panfrost 1304.gpu: Linked as a consumer to regulator.31
> [  221.870586] panfrost 1304.gpu: Linked as a consumer to 
> genpd:0:1304.gpu
> [  221.871492] panfrost 1304.gpu: Linked as a consumer to 
> genpd:1:1304.gpu
> [  221.871866] panfrost 1304.gpu: Linked as a consumer to 
> genpd:2:1304.gpu
> [  221.872427] panfrost 1304.gpu: mali-g72 id 0x6221 major 0x0 minor 0x3 
> status 0x0
> [  221.872439] panfrost 1304.gpu: features: ,13de77ff, issues: 
> ,0400
> [  221.872445] panfrost 1304.gpu: Features: L2:0x07120206 
> Shader:0x Tiler:0x0809 Mem:0x1 MMU:0x2830 AS:0xff JS:0x7
> [  221.872449] panfrost 1304.gpu: shader_present=0x7 l2_present=0x1
> [  221.873526] panfrost 1304.gpu: error powering up gpu stack
> [  221.878088] [drm] Initialized panfrost 1.1.0 20180908 for 1304.gpu on 
> minor 2
> [  221.940817] panfrost 1304.gpu: error powering up gpu stack
> [  222.018233] panfrost 1304.gpu: error powering up gpu stack
> (repeated)
> 
> So the GPU is probed, but there's an issue when powering up the STACK, not
> quite sure why, I'll try to have a deeper look, at some point.
> 
> Thanks!
> 
> Nicolas
> 
> v2:
>  - Use sram instead of mali_sram as SRAM supply name.
>  - Rename mali@ to gpu@.
>  - Add dt-bindings changes
>  - Stacking patches after the device tree change that allow basic
>probing (still incomplete and broken).
> 
> Nicolas Boichat (7):
>   dt-bindings: gpu: mali-bifrost: Add Mediatek MT8183
>   arm64: dts: mt8183: Add node for the Mali GPU
>   drm/panfrost: Improve error reporting in panfrost_gpu_power_on
>   drm/panfrost: Add support for a second regulator for the GPU
>   drm/panfrost: Add support for multiple power domain support
>   RFC: drm/panfrost: Add bifrost compatible string
>   RFC: drm/panfrost: devfreq: Add support for 2 regulators
> 
>  .../bindings/gpu/arm,mali-bifrost.yaml|  20 
>  arch/arm64/boot/dts/mediatek/mt8183-evb.dts   |   7 ++
>  arch/arm64/boot/dts/mediatek/mt8183.dtsi  | 104 +
>  drivers/gpu/drm/panfrost/panfrost_devfreq.c   |  18 +++
>  drivers/gpu/drm/panfrost/panfrost_device.c| 108 --
>  drivers/gpu/drm/panfrost/panfrost_device.h|   7 ++
>  drivers/gpu/drm/panfrost/panfrost_drv.c   |   1 +
>  drivers/gpu/drm/panfrost/panfrost_gpu.c   |  15 ++-
>  8 files changed, 267 insertions(+), 13 deletions(-)
> 
> -- 
> 2.24.1.735.g03f4e72817-goog
> 


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

Re: [RFT 00/13] iomap: Constify ioreadX() iomem argument

[Christophe Leroy]

Hi Geert,

Le 08/01/2020 à 09:43, Geert Uytterhoeven a écrit :

Hi Christophe,

On Wed, Jan 8, 2020 at 9:35 AM Christophe Leroy  wrote:

Le 08/01/2020 à 09:18, Krzysztof Kozlowski a écrit :

On Wed, 8 Jan 2020 at 09:13, Geert Uytterhoeven  wrote:

On Wed, Jan 8, 2020 at 9:07 AM Geert Uytterhoeven  wrote:

On Tue, Jan 7, 2020 at 5:53 PM Krzysztof Kozlowski  wrote:

The ioread8/16/32() and others have inconsistent interface among the
architectures: some taking address as const, some not.

It seems there is nothing really stopping all of them to take
pointer to const.


Shouldn't all of them take const volatile __iomem pointers?
It seems the "volatile" is missing from all but the implementations in
include/asm-generic/io.h.


As my "volatile" comment applies to iowrite*(), too, probably that should be
done in a separate patch.

Hence with patches 1-5 squashed, and for patches 11-13:
Reviewed-by: Geert Uytterhoeven 


I'll add to this one also changes to ioreadX_rep() and add another
patch for volatile for reads and writes. I guess your review will be
appreciated once more because of ioreadX_rep()


volatile should really only be used where deemed necessary:

https://www.kernel.org/doc/html/latest/process/volatile-considered-harmful.html

It is said: " ...  accessor functions might use volatile on
architectures where direct I/O memory access does work. Essentially,
each accessor call becomes a little critical section on its own and
ensures that the access happens as expected by the programmer."


That is exactly the use case here: all above are accessor functions.

Why would ioreadX() not need volatile, while readY() does?



My point was: it might be necessary for some arches and not for others.

And as pointed by Arnd, the volatile is really only necessary for the 
dereference itself, should the arch use dereferencing.


So I guess the best would be to go in the other direction: remove 
volatile keyword wherever possible instead of adding it where it is not 
needed.


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

Re: [PATCH] drm/Kconfig: add missing 'depends on DRM' for DRM_DP_CEC

[Hans Verkuil]

On 12/6/19 12:26 PM, Hans Verkuil wrote:
> Add a missing 'depends on DRM' for the DRM_DP_CEC config
> option. Without that enabling DRM_DP_CEC will force CEC_CORE
> to =y instead of =m if DRM=m as well.
> 
> Signed-off-by: Hans Verkuil 

Daniel, can you review this? It's annoying that the cec core is
compiled as part of the kernel when it can just be a module.

Regards,

Hans

> ---
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index 1168351267fd..e8e478d6da9c 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -163,6 +163,7 @@ config DRM_LOAD_EDID_FIRMWARE
> 
>  config DRM_DP_CEC
>   bool "Enable DisplayPort CEC-Tunneling-over-AUX HDMI support"
> + depends on DRM
>   select CEC_CORE
>   help
> Choose this option if you want to enable HDMI CEC support for
> 

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

Re: [PATCH RFT v1 1/3] drm/panfrost: enable devfreq based the "operating-points-v2" property

[Martin Blumenstingl]

Hi Robin,

On Wed, Jan 8, 2020 at 12:18 PM Robin Murphy  wrote:
>
> On 07/01/2020 11:06 pm, Martin Blumenstingl wrote:
> > Decouple the check to see whether we want to enable devfreq for the GPU
> > from dev_pm_opp_set_regulators(). This is preparation work for adding
> > back support for regulator control (which means we need to call
> > dev_pm_opp_set_regulators() before dev_pm_opp_of_add_table(), which
> > means having a check for "is devfreq enabled" that is not tied to
> > dev_pm_opp_of_add_table() makes things easier).
>
> Hmm, what about cases like the SCMI DVFS protocol where the OPPs are
> dynamically discovered rather than statically defined in DT?
where can I find such an example (Amlogic SoCs use SCPI instead of
SCMI, so I don't think that I have any board with SCMI support) or
some documentation?
(I could only find SCPI clock and CPU DVFS implementations, but no
generic "OPPs for any device" implementation)


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

[PATCH v2] drm/msm: use BUG_ON macro for debugging.

[Wambui Karuga]

As the if statement only checks for the value of the offset_name
variable, it can be replaced by the more conscise BUG_ON macro for error
reporting.

v2: format expression to less than 80 characters for each line.

Signed-off-by: Wambui Karuga 
---
 drivers/gpu/drm/msm/adreno/adreno_gpu.h | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.h 
b/drivers/gpu/drm/msm/adreno/adreno_gpu.h
index c7441fb8313e..d1843abc3ac7 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.h
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.h
@@ -315,10 +315,8 @@ OUT_PKT7(struct msm_ringbuffer *ring, uint8_t opcode, 
uint16_t cnt)
 static inline bool adreno_reg_check(struct adreno_gpu *gpu,
enum adreno_regs offset_name)
 {
-   if (offset_name >= REG_ADRENO_REGISTER_MAX ||
-   !gpu->reg_offsets[offset_name]) {
-   BUG();
-   }
+   BUG_ON(offset_name >= REG_ADRENO_REGISTER_MAX ||
+  !gpu->reg_offsets[offset_name]);
 
/*
 * REG_SKIP is a special value that tell us that the register in
-- 
2.17.1

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

[PATCH 4/5] drm/i915: convert to new logging macros in i915/intel_gvt.c

[Wambui Karuga]

This converts the use of printk based logging macros in i915/intel_gvt.c
with the new struct drm_device based logging macros.

Signed-off-by: Wambui Karuga 
---
 drivers/gpu/drm/i915/intel_gvt.c | 13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_gvt.c b/drivers/gpu/drm/i915/intel_gvt.c
index 2b6c016387c2..38ebd5562c7c 100644
--- a/drivers/gpu/drm/i915/intel_gvt.c
+++ b/drivers/gpu/drm/i915/intel_gvt.c
@@ -67,12 +67,13 @@ void intel_gvt_sanitize_options(struct drm_i915_private 
*dev_priv)
return;
 
if (intel_vgpu_active(dev_priv)) {
-   DRM_INFO("GVT-g is disabled for guest\n");
+   drm_info(_priv->drm, "GVT-g is disabled for guest\n");
goto bail;
}
 
if (!is_supported_device(dev_priv)) {
-   DRM_INFO("Unsupported device. GVT-g is disabled\n");
+   drm_info(_priv->drm,
+"Unsupported device. GVT-g is disabled\n");
goto bail;
}
 
@@ -99,18 +100,20 @@ int intel_gvt_init(struct drm_i915_private *dev_priv)
return -ENODEV;
 
if (!i915_modparams.enable_gvt) {
-   DRM_DEBUG_DRIVER("GVT-g is disabled by kernel params\n");
+   drm_dbg(_priv->drm,
+   "GVT-g is disabled by kernel params\n");
return 0;
}
 
if (USES_GUC_SUBMISSION(dev_priv)) {
-   DRM_ERROR("i915 GVT-g loading failed due to Graphics 
virtualization is not yet supported with GuC submission\n");
+   drm_err(_priv->drm,
+   "i915 GVT-g loading failed due to Graphics 
virtualization is not yet supported with GuC submission\n");
return -EIO;
}
 
ret = intel_gvt_init_device(dev_priv);
if (ret) {
-   DRM_DEBUG_DRIVER("Fail to init GVT device\n");
+   drm_dbg(_priv->drm, "Fail to init GVT device\n");
goto bail;
}
 
-- 
2.24.1

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

Re: [PATCH v2 2/2] drm/sun4i: drc: Make sure we enforce the clock rate

[Maxime Ripard]

On Wed, Jan 08, 2020 at 01:28:34AM +0800, Chen-Yu Tsai wrote:
> On Wed, Jan 8, 2020 at 1:00 AM Maxime Ripard  wrote:
> >
> > The DRC needs to run at 300MHz to be functional. This was done so far
> > using assigned-clocks in the device tree, but that is easy to forget, and
> > dosen't provide any other guarantee than the rate is going to be roughly
> > the one requested at probe time.
> >
> > Therefore it's pretty fragile, so let's just use the exclusive clock API to
> > enforce it.
> >
> > Signed-off-by: Maxime Ripard 
>
> Reviewed-by: Chen-Yu Tsai 

APplied both, thanks!
Maxime


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

Re: [PATCH] xf86drm: only include for FreeBSD build case

[Niclas Zeising]

On 2020-01-09 16:18, Jani Nikula wrote:

On Thu, 09 Jan 2020, Seung-Woo Kim  wrote:

The  header is only required FreeBSD and GNU libc
2.30 starts to warn about Linux specific  header
deprecation. Only include  for FreeBSD.

Signed-off-by: Seung-Woo Kim 
---
  xf86drmMode.c |2 ++
  1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/xf86drmMode.c b/xf86drmMode.c
index 207d7be..ff1d31d 100644
--- a/xf86drmMode.c
+++ b/xf86drmMode.c
@@ -42,9 +42,11 @@
  #include 
  #include 
  #include 
+#if defined (__FreeBSD__) || defined (__FreeBSD_kernel__)
  #ifdef HAVE_SYS_SYSCTL_H


Not that I know anything about this, but shouldn't you instead fix
HAVE_SYS_SYSCTL_H definition in configure stage to only be enabled on
FreeBSD?

BR,
Jani.


  #include 
  #endif
+#endif /* defined (__FreeBSD__) || defined (__FreeBSD_kernel__) */
  #include 
  #include 




Hi!
This fix looks OK on FreeBSD (I haven't had time to test), however, as 
has been pointed out, perhaps the change should go into the meson build 
script or configure instead.
I don't know if other OSes (other BSDs primarily) need this as well. 
I'm pretty sure it's needed on DragonflyBSD at least.

Perhaps keep the include for everything except Linux for the time being?
Regards
--
Niclas Zeising
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/Kconfig: add missing 'depends on DRM' for DRM_DP_CEC

[Hans Verkuil]

On 1/8/20 6:42 PM, Daniel Vetter wrote:
> On Wed, Jan 08, 2020 at 01:08:47PM +0100, Hans Verkuil wrote:
>> On 12/6/19 12:26 PM, Hans Verkuil wrote:
>>> Add a missing 'depends on DRM' for the DRM_DP_CEC config
>>> option. Without that enabling DRM_DP_CEC will force CEC_CORE
>>> to =y instead of =m if DRM=m as well.
>>>
>>> Signed-off-by: Hans Verkuil 
>>
>> Daniel, can you review this? It's annoying that the cec core is
>> compiled as part of the kernel when it can just be a module.
> 
> Why did we even make this optional? Really worth it to compile out 4
> functions and some change?

It's not about those few functions, it's because this enables the CEC
framework as well (drivers/media/cec).

If CEC is not needed, then disabling this saves a lot more code than the
few functions in drm_dp_cec.c.

CEC is an optional HDMI feature, so CEC support for HDMI input/output
drivers is optional as well in the kernel config.

Regards,

Hans

> 
> Anyway the one you really want here is CONFIG_DRM_KMS_HELPER, but that is
> a selected variable, and you can't mix select and depends on because that
> breaks Kconfig in hilarious ways. Or so I thought, but other public
> symbols like this (e.g. DRM_FBDEV_EMULATION) do the same trick. So I guess
> 
> Reviewed-by: Daniel Vetter 
> 
> But really, is all this complexity?
> -Daniel
> 
>>
>> Regards,
>>
>>  Hans
>>
>>> ---
>>> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
>>> index 1168351267fd..e8e478d6da9c 100644
>>> --- a/drivers/gpu/drm/Kconfig
>>> +++ b/drivers/gpu/drm/Kconfig
>>> @@ -163,6 +163,7 @@ config DRM_LOAD_EDID_FIRMWARE
>>>
>>>  config DRM_DP_CEC
>>> bool "Enable DisplayPort CEC-Tunneling-over-AUX HDMI support"
>>> +   depends on DRM
>>> select CEC_CORE
>>> help
>>>   Choose this option if you want to enable HDMI CEC support for
>>>
>>
> 

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

[PATCH 3/5] drm/i915: conversion to new logging macros in i915/intel_device_info.c

[Wambui Karuga]

This replaces the printk and struct device based logging macros with the
new struct drm_device style based logging macros i915/intel_device_info.c.

Signed-off-by: Wambui Karuga 
---
 drivers/gpu/drm/i915/intel_device_info.c | 25 +---
 1 file changed, 14 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_device_info.c 
b/drivers/gpu/drm/i915/intel_device_info.c
index 6670a0763be2..fcdacd6d4aa5 100644
--- a/drivers/gpu/drm/i915/intel_device_info.c
+++ b/drivers/gpu/drm/i915/intel_device_info.c
@@ -974,10 +974,11 @@ void intel_device_info_runtime_init(struct 
drm_i915_private *dev_priv)
sfuse_strap & SFUSE_STRAP_DISPLAY_DISABLED ||
(HAS_PCH_CPT(dev_priv) &&
 !(sfuse_strap & SFUSE_STRAP_FUSE_LOCK))) {
-   DRM_INFO("Display fused off, disabling\n");
+   drm_info(_priv->drm,
+"Display fused off, disabling\n");
info->pipe_mask = 0;
} else if (fuse_strap & IVB_PIPE_C_DISABLE) {
-   DRM_INFO("PipeC fused off\n");
+   drm_info(_priv->drm, "PipeC fused off\n");
info->pipe_mask &= ~BIT(PIPE_C);
}
} else if (HAS_DISPLAY(dev_priv) && INTEL_GEN(dev_priv) >= 9) {
@@ -1000,8 +1001,9 @@ void intel_device_info_runtime_init(struct 
drm_i915_private *dev_priv)
 * in the mask.
 */
if (enabled_mask == 0 || !is_power_of_2(enabled_mask + 1))
-   DRM_ERROR("invalid pipe fuse configuration: 
enabled_mask=0x%x\n",
- enabled_mask);
+   drm_err(_priv->drm,
+   "invalid pipe fuse configuration: 
enabled_mask=0x%x\n",
+   enabled_mask);
else
info->pipe_mask = enabled_mask;
 
@@ -1036,7 +1038,8 @@ void intel_device_info_runtime_init(struct 
drm_i915_private *dev_priv)
gen12_sseu_info_init(dev_priv);
 
if (IS_GEN(dev_priv, 6) && intel_vtd_active()) {
-   DRM_INFO("Disabling ppGTT for VT-d support\n");
+   drm_info(_priv->drm,
+"Disabling ppGTT for VT-d support\n");
info->ppgtt_type = INTEL_PPGTT_NONE;
}
 
@@ -1084,7 +1087,7 @@ void intel_device_info_init_mmio(struct drm_i915_private 
*dev_priv)
 
if (!(BIT(i) & vdbox_mask)) {
info->engine_mask &= ~BIT(_VCS(i));
-   DRM_DEBUG_DRIVER("vcs%u fused off\n", i);
+   drm_dbg(_priv->drm, "vcs%u fused off\n", i);
continue;
}
 
@@ -1096,8 +1099,8 @@ void intel_device_info_init_mmio(struct drm_i915_private 
*dev_priv)
if (INTEL_GEN(dev_priv) >= 12 || logical_vdbox++ % 2 == 0)
RUNTIME_INFO(dev_priv)->vdbox_sfc_access |= BIT(i);
}
-   DRM_DEBUG_DRIVER("vdbox enable: %04x, instances: %04lx\n",
-vdbox_mask, VDBOX_MASK(dev_priv));
+   drm_dbg(_priv->drm, "vdbox enable: %04x, instances: %04lx\n",
+   vdbox_mask, VDBOX_MASK(dev_priv));
GEM_BUG_ON(vdbox_mask != VDBOX_MASK(dev_priv));
 
for (i = 0; i < I915_MAX_VECS; i++) {
@@ -1108,10 +,10 @@ void intel_device_info_init_mmio(struct 
drm_i915_private *dev_priv)
 
if (!(BIT(i) & vebox_mask)) {
info->engine_mask &= ~BIT(_VECS(i));
-   DRM_DEBUG_DRIVER("vecs%u fused off\n", i);
+   drm_dbg(_priv->drm, "vecs%u fused off\n", i);
}
}
-   DRM_DEBUG_DRIVER("vebox enable: %04x, instances: %04lx\n",
-vebox_mask, VEBOX_MASK(dev_priv));
+   drm_dbg(_priv->drm, "vebox enable: %04x, instances: %04lx\n",
+   vebox_mask, VEBOX_MASK(dev_priv));
GEM_BUG_ON(vebox_mask != VEBOX_MASK(dev_priv));
 }
-- 
2.24.1

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

答复: [PATCH] drm/hisilicon: add the mode_valid function

[tiantao (H)]

Hi Thomas Zimmermann:

I will modify this patch and send v2 as you suggested.
Thank you very much.

Best

-邮件原件-
发件人: Thomas Zimmermann [mailto:tzimmerm...@suse.de] 
发送时间: 2020年1月8日 16:49
收件人: tiantao (H) ; Chenfeng (puck) 
; airl...@linux.ie; dan...@ffwll.ch; 
kra...@redhat.com; alexander.deuc...@amd.com; t...@linutronix.de; 
dri-devel@lists.freedesktop.org; xinliang@linaro.org; 
linux-ker...@vger.kernel.org
抄送: Linuxarm 
主题: Re: [PATCH] drm/hisilicon: add the mode_valid function

Hi,

here are a few more nits to fix.

Am 08.01.20 um 09:19 schrieb Tian Tao:
> add mode_valid function, and we can also use it to make suse the 
> resolution is valid.

Start with capital 'Add' and make it a simple sentence. Change 'suse' to 'sure'

> 
> Signed-off-by: Tian Tao 
> Signed-off-by: Gong junjie 
> ---
>  drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c | 20 
> 
>  1 file changed, 20 insertions(+)
> 
> diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c 
> b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
> index 843d784..6cb7a79 100644
> --- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
> +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
> @@ -242,6 +242,25 @@ static void hibmc_crtc_atomic_disable(struct drm_crtc 
> *crtc,
>   hibmc_set_current_gate(priv, reg);
>  }
>  
> +enum drm_mode_status hibmc_crtc_mode_valid(struct drm_crtc *crtc,
> + const struct drm_display_mode *mode)

Please declare this function as static.

> +{
> + int i = 0;
> + int vrefresh = drm_mode_vrefresh(mode);
> +
> + if (vrefresh < 59 || vrefresh > 61)
> + return MODE_NOMODE;

I'd return MODE_NOCLOCK or MODE_CLOCK_RANGE.

> +
> + for (i = 0; i < ARRAY_SIZE(hibmc_pll_table); i++) {
> + if (hibmc_pll_table[i].hdisplay == mode->hdisplay &&
> + hibmc_pll_table[i].vdisplay == mode->vdisplay)
> + return MODE_OK;
> + }
> +
> + return MODE_NOMODE;

Maybe return MODE_BAD. MODE_NOMODE apparently refers to a descriptive string 
for the mode.

> +}
> +
> +

One one empty line please.

With these fixes applied, you can add my

Reviewed-by: Thomas Zimmermann 

Best regards
Thomas


>  static unsigned int format_pll_reg(void)  {
>   unsigned int pllreg = 0;
> @@ -510,6 +529,7 @@ static const struct drm_crtc_helper_funcs 
> hibmc_crtc_helper_funcs = {
>   .atomic_flush   = hibmc_crtc_atomic_flush,
>   .atomic_enable  = hibmc_crtc_atomic_enable,
>   .atomic_disable = hibmc_crtc_atomic_disable,
> + .mode_valid = hibmc_crtc_mode_valid,
>  };
>  
>  int hibmc_de_init(struct hibmc_drm_private *priv)
> 

--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer

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

[PATCH] drm/rockchip: use DIV_ROUND_UP macro for calculations.

[Wambui Karuga]

Replace the open coded calculation with the more concise and readable
DIV_ROUND_UP macro.

Signed-off-by: Wambui Karuga 
---
 drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
index 0b3d18c457b2..cc672620d6e0 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
@@ -328,7 +328,7 @@ static inline uint16_t scl_get_bili_dn_vskip(int src_h, int 
dst_h,
 {
int act_height;
 
-   act_height = (src_h + vskiplines - 1) / vskiplines;
+   act_height = DIV_ROUND_UP(src_h, vskiplines);
 
if (act_height == dst_h)
return GET_SCL_FT_BILI_DN(src_h, dst_h) / vskiplines;
-- 
2.17.1

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

[PATCH 1/2] dt-bindings: panel-simple: Add compatible for GiantPlus GPM940B0

[Paul Cercueil]

Add a compatible string for the GiantPlus GPM740B0 3" QVGA TFT LCD
panel, and remove the old giantplus,gpm740b0.txt documentation which is
now obsolete.

Signed-off-by: Paul Cercueil 
---
 .../bindings/display/panel/giantplus,gpm940b0.txt| 12 
 .../bindings/display/panel/panel-simple.yaml |  2 ++
 2 files changed, 2 insertions(+), 12 deletions(-)
 delete mode 100644 
Documentation/devicetree/bindings/display/panel/giantplus,gpm940b0.txt

diff --git 
a/Documentation/devicetree/bindings/display/panel/giantplus,gpm940b0.txt 
b/Documentation/devicetree/bindings/display/panel/giantplus,gpm940b0.txt
deleted file mode 100644
index 3dab52f92c26..
--- a/Documentation/devicetree/bindings/display/panel/giantplus,gpm940b0.txt
+++ /dev/null
@@ -1,12 +0,0 @@
-GiantPlus 3.0" (320x240 pixels) 24-bit TFT LCD panel
-
-Required properties:
-- compatible: should be "giantplus,gpm940b0"
-- power-supply: as specified in the base binding
-
-Optional properties:
-- backlight: as specified in the base binding
-- enable-gpios: as specified in the base binding
-
-This binding is compatible with the simple-panel binding, which is specified
-in simple-panel.txt in this directory.
diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml 
b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
index 090866260f4f..c1a77d9105a2 100644
--- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
+++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
@@ -33,6 +33,8 @@ properties:
   - ampire,am-480272h3tmqw-t01h
 # Ampire AM-800480R3TMQW-A1H 7.0" WVGA TFT LCD panel
   - ampire,am800480r3tmqwa1h
+# GiantPlus GPM940B0 3.0" QVGA TFT LCD panel
+  - giantplus,gpm940b0
 
   backlight: true
   enable-gpios: true
-- 
2.24.1

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

RE: [PATCH v2 5/9] arc: Constify ioreadX() iomem argument (as in generic implementation)

[Alexey Brodkin]

Hi Krzysztof,

> The ioreadX() helpers have inconsistent interface.  On some architectures
> void *__iomem address argument is a pointer to const, on some not.
> 
> Implementations of ioreadX() do not modify the memory under the
> address so they can be converted to a "const" version for const-safety
> and consistency among architectures.

Thanks for this clean-up. Looks good to me, so ...

Acked-by: Alexey Brodkin 

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

RE: [RFT 00/13] iomap: Constify ioreadX() iomem argument

[David Laight]

From: Christophe Leroy
> Sent: 08 January 2020 08:49
...
> And as pointed by Arnd, the volatile is really only necessary for the
> dereference itself, should the arch use dereferencing.

I've had trouble with some versions of gcc and reading of 'volatile unsigned 
char *'.
It tended to follow the memory read with an extra mask with 0xff.
(I suspect that internally the value landed into a temporary 'int' variable.)

I got better code using memory barriers.
So putting an asm barrier for the exact location of the memory read
either side of the read should have the desired effect without adding
extra instructions.
(You might think 'volatile' would mean that - but it doesn't.)

David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, 
UK
Registration No: 1397386 (Wales)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC PATCH 4/4] drm/i915/gvt: move public gvt headers out into global include

[Julian Stecklina]

Now that the GVT interface to hypervisors does not depend on i915/GVT
internals anymore, we can move the headers to the global include/.

This makes out-of-tree modules for hypervisor integration possible.

Cc: Zhenyu Wang 

Signed-off-by: Julian Stecklina 
---
 drivers/gpu/drm/i915/gvt/gvt.h |  3 +--
 drivers/gpu/drm/i915/gvt/kvmgt.c   |  2 +-
 .../i915/gvt/gvt_public.h => include/drm/i915_gvt.h|  8 
 .../hypercall.h => include/drm/i915_gvt_hypercall.h| 10 +++---
 4 files changed, 13 insertions(+), 10 deletions(-)
 rename drivers/gpu/drm/i915/gvt/gvt_public.h => include/drm/i915_gvt.h (97%)
 rename drivers/gpu/drm/i915/gvt/hypercall.h => 
include/drm/i915_gvt_hypercall.h (95%)

diff --git a/drivers/gpu/drm/i915/gvt/gvt.h b/drivers/gpu/drm/i915/gvt/gvt.h
index f9693c44e342..d09374aa7710 100644
--- a/drivers/gpu/drm/i915/gvt/gvt.h
+++ b/drivers/gpu/drm/i915/gvt/gvt.h
@@ -33,9 +33,8 @@
 #ifndef _GVT_H_
 #define _GVT_H_
 
-#include "gvt_public.h"
+#include 
 #include "debug.h"
-#include "hypercall.h"
 #include "mmio.h"
 #include "reg.h"
 #include "interrupt.h"
diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c b/drivers/gpu/drm/i915/gvt/kvmgt.c
index f5157211d45f..280d69ca964b 100644
--- a/drivers/gpu/drm/i915/gvt/kvmgt.c
+++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
@@ -28,6 +28,7 @@
  *Xiaoguang Chen 
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -52,7 +53,6 @@
 #include 
 
 #include "debug.h"
-#include "gvt_public.h"
 
 static const struct intel_gvt_ops *intel_gvt_ops;
 
diff --git a/drivers/gpu/drm/i915/gvt/gvt_public.h b/include/drm/i915_gvt.h
similarity index 97%
rename from drivers/gpu/drm/i915/gvt/gvt_public.h
rename to include/drm/i915_gvt.h
index 23bf1235e1a1..3926ca32f773 100644
--- a/drivers/gpu/drm/i915/gvt/gvt_public.h
+++ b/include/drm/i915_gvt.h
@@ -21,10 +21,10 @@
  * SOFTWARE.
  */
 
-#ifndef _GVT_PUBLIC_H_
-#define _GVT_PUBLIC_H_
+#ifndef _I915_GVT_H_
+#define _I915_GVT_H_
 
-#include "hypercall.h"
+#include 
 
 struct attribute;
 struct attribute_group;
@@ -101,4 +101,4 @@ bool intel_gvt_in_gtt(struct intel_vgpu *vgpu, u64 off);
 
 struct dentry *intel_vgpu_debugfs(struct intel_vgpu *vgpu);
 
-#endif /* _GVT_PUBLIC_H_ */
+#endif /* _I915_GVT_H_ */
diff --git a/drivers/gpu/drm/i915/gvt/hypercall.h 
b/include/drm/i915_gvt_hypercall.h
similarity index 95%
rename from drivers/gpu/drm/i915/gvt/hypercall.h
rename to include/drm/i915_gvt_hypercall.h
index 7ed33e4919a3..c26eef7dbdde 100644
--- a/drivers/gpu/drm/i915/gvt/hypercall.h
+++ b/include/drm/i915_gvt_hypercall.h
@@ -30,8 +30,12 @@
  *
  */
 
-#ifndef _GVT_HYPERCALL_H_
-#define _GVT_HYPERCALL_H_
+#ifndef _I915_GVT_HYPERCALL_H_
+#define _I915_GVT_HYPERCALL_H_
+
+#include 
+
+struct device;
 
 #include 
 
@@ -84,4 +88,4 @@ extern struct intel_gvt_mpt xengt_mpt;
 int intel_gvt_register_hypervisor(struct intel_gvt_mpt *);
 void intel_gvt_unregister_hypervisor(void);
 
-#endif /* _GVT_HYPERCALL_H_ */
+#endif /* _I915_GVT_HYPERCALL_H_ */
-- 
2.24.1

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

[RFC PATCH 2/4] drm/i915/gvt: remove unused vblank_done completion

[Julian Stecklina]

This variable is used nowhere, so remove it.

Cc: Zhenyu Wang 

Signed-off-by: Julian Stecklina 
---
 drivers/gpu/drm/i915/gvt/gvt.h   | 2 --
 drivers/gpu/drm/i915/gvt/kvmgt.c | 2 --
 2 files changed, 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/gvt/gvt.h b/drivers/gpu/drm/i915/gvt/gvt.h
index 2604739e5680..8cf292a8d6bd 100644
--- a/drivers/gpu/drm/i915/gvt/gvt.h
+++ b/drivers/gpu/drm/i915/gvt/gvt.h
@@ -203,8 +203,6 @@ struct intel_vgpu {
struct mutex dmabuf_lock;
struct idr object_idr;
 
-   struct completion vblank_done;
-
u32 scan_nonprivbb;
 };
 
diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c b/drivers/gpu/drm/i915/gvt/kvmgt.c
index d725a4fb94b9..9a435bc1a2f0 100644
--- a/drivers/gpu/drm/i915/gvt/kvmgt.c
+++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
@@ -1817,8 +1817,6 @@ static int kvmgt_guest_init(struct mdev_device *mdev)
kvmgt_protect_table_init(info);
gvt_cache_init(vgpu);
 
-   init_completion(>vblank_done);
-
info->track_node.track_write = kvmgt_page_track_write;
info->track_node.track_flush_slot = kvmgt_page_track_flush_slot;
kvm_page_track_register_notifier(kvm, >track_node);
-- 
2.24.1

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

[RFC PATCH 0/4] Support for out-of-tree hypervisor modules in i915/gvt

[Julian Stecklina]

These patch series removes the dependency of i915/gvt hypervisor
backends on the driver internals of the i915 driver. Instead, we add a
small public API that hypervisor backends can use.

This enables out-of-tree hypervisor backends for the Intel graphics
virtualization and simplifies development. At the same time, it
creates at least a bit of a barrier to including more i915 internals
into kvmgt, which is nice in itself.

The first two patches are pretty much general cleanup and could be
merged without the rest.

Any feedback is welcome.

Julian Stecklina (4):
  drm/i915/gvt: make gvt oblivious of kvmgt data structures
  drm/i915/gvt: remove unused vblank_done completion
  drm/i915/gvt: define a public interface to gvt
  drm/i915/gvt: move public gvt headers out into global include

 drivers/gpu/drm/i915/gvt/Makefile |   2 +-
 drivers/gpu/drm/i915/gvt/debug.h  |   2 +-
 drivers/gpu/drm/i915/gvt/display.c|  26 ++
 drivers/gpu/drm/i915/gvt/display.h|  27 --
 drivers/gpu/drm/i915/gvt/gtt.h|   2 -
 drivers/gpu/drm/i915/gvt/gvt.h|  65 +--
 drivers/gpu/drm/i915/gvt/gvt_public.c | 154 +++
 drivers/gpu/drm/i915/gvt/kvmgt.c  | 413 ++
 drivers/gpu/drm/i915/gvt/mpt.h|   3 -
 drivers/gpu/drm/i915/gvt/reg.h|   2 -
 include/drm/i915_gvt.h| 104 +
 .../drm/i915_gvt_hypercall.h  |  13 +-
 12 files changed, 537 insertions(+), 276 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/gvt/gvt_public.c
 create mode 100644 include/drm/i915_gvt.h
 rename drivers/gpu/drm/i915/gvt/hypercall.h => 
include/drm/i915_gvt_hypercall.h (92%)

-- 
2.24.1

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

Re: [PATCH v3 1/4] dt-bindings: display: Convert Allwinner display pipeline to schemas

[Rob Herring]

On Fri, Jan 3, 2020 at 9:28 AM Maxime Ripard  wrote:
>
> The Allwinner SoCs have a display engine composed of several controllers
> assembled differently depending on the SoC, the number and type of output
> they have, and the additional features they provide. A number of those are
> supported in Linux, with the matching bindings.
>
> Now that we have the DT validation in place, let's split into separate file
> and convert the device tree bindings for those controllers to schemas.
>
> Signed-off-by: Maxime Ripard 
>
> ---
>
> Changes from v2:
>   - Changed a number of maxItems to minItems to make more sense
>   - Fixed a few enum that were improperly declared. This raised a bunch of
> warnings that were unnoticed before. Fixed them.
>   - Added an if clause to the HDMI PHY binding to check the number of clocks
>
> Changes from v1:
>   - Declare the ports in the bindings
> ---
>  .../allwinner,sun4i-a10-display-backend.yaml  | 291 
>  .../allwinner,sun4i-a10-display-engine.yaml   | 114 +++
>  .../allwinner,sun4i-a10-display-frontend.yaml | 138 
>  .../display/allwinner,sun4i-a10-hdmi.yaml | 183 +
>  .../display/allwinner,sun4i-a10-tcon.yaml | 676 ++
>  .../allwinner,sun4i-a10-tv-encoder.yaml   |  62 ++
>  .../display/allwinner,sun6i-a31-drc.yaml  | 138 
>  .../allwinner,sun8i-a83t-de2-mixer.yaml   | 118 +++
>  .../display/allwinner,sun8i-a83t-dw-hdmi.yaml | 273 +++
>  .../allwinner,sun8i-a83t-hdmi-phy.yaml| 117 +++
>  .../display/allwinner,sun8i-r40-tcon-top.yaml | 382 ++
>  .../display/allwinner,sun9i-a80-deu.yaml  | 133 
>  .../bindings/display/sunxi/sun4i-drm.txt  | 637 -
>  13 files changed, 2625 insertions(+), 637 deletions(-)
>  create mode 100644 
> Documentation/devicetree/bindings/display/allwinner,sun4i-a10-display-backend.yaml
>  create mode 100644 
> Documentation/devicetree/bindings/display/allwinner,sun4i-a10-display-engine.yaml
>  create mode 100644 
> Documentation/devicetree/bindings/display/allwinner,sun4i-a10-display-frontend.yaml
>  create mode 100644 
> Documentation/devicetree/bindings/display/allwinner,sun4i-a10-hdmi.yaml
>  create mode 100644 
> Documentation/devicetree/bindings/display/allwinner,sun4i-a10-tcon.yaml
>  create mode 100644 
> Documentation/devicetree/bindings/display/allwinner,sun4i-a10-tv-encoder.yaml
>  create mode 100644 
> Documentation/devicetree/bindings/display/allwinner,sun6i-a31-drc.yaml
>  create mode 100644 
> Documentation/devicetree/bindings/display/allwinner,sun8i-a83t-de2-mixer.yaml
>  create mode 100644 
> Documentation/devicetree/bindings/display/allwinner,sun8i-a83t-dw-hdmi.yaml
>  create mode 100644 
> Documentation/devicetree/bindings/display/allwinner,sun8i-a83t-hdmi-phy.yaml
>  create mode 100644 
> Documentation/devicetree/bindings/display/allwinner,sun8i-r40-tcon-top.yaml
>  create mode 100644 
> Documentation/devicetree/bindings/display/allwinner,sun9i-a80-deu.yaml
>  delete mode 100644 
> Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt

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

[RFC PATCH 3/4] drm/i915/gvt: define a public interface to gvt

[Julian Stecklina]

So far, the KVMGT code just included the whole i915 driver and GVT
internals to do its job. Change this to have a single public header
that defines the interface via accessor functions.

Some ugly things:

a) The handle member of intel_vgpu should be in kvmgt_vdev and the
generic code should just pass the vgpu pointer around.

b) The "public" API is rather ugly, because I tried to limit the
changes I do to KVMGT and have a mechanical 1:1 conversion. Future
patches will need to simplify this to something sane.

v2:
- Remove edid and display constants from public API

Cc: Zhenyu Wang 

Signed-off-by: Julian Stecklina 
---
 drivers/gpu/drm/i915/gvt/Makefile |   2 +-
 drivers/gpu/drm/i915/gvt/debug.h  |   2 +-
 drivers/gpu/drm/i915/gvt/display.c|  26 +
 drivers/gpu/drm/i915/gvt/display.h|  27 -
 drivers/gpu/drm/i915/gvt/gtt.h|   2 -
 drivers/gpu/drm/i915/gvt/gvt.h|  40 +--
 drivers/gpu/drm/i915/gvt/gvt_public.c | 154 ++
 drivers/gpu/drm/i915/gvt/gvt_public.h | 104 +
 drivers/gpu/drm/i915/gvt/hypercall.h  |   3 +
 drivers/gpu/drm/i915/gvt/kvmgt.c  | 130 +++---
 drivers/gpu/drm/i915/gvt/mpt.h|   3 -
 drivers/gpu/drm/i915/gvt/reg.h|   2 -
 12 files changed, 354 insertions(+), 141 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/gvt/gvt_public.c
 create mode 100644 drivers/gpu/drm/i915/gvt/gvt_public.h

diff --git a/drivers/gpu/drm/i915/gvt/Makefile 
b/drivers/gpu/drm/i915/gvt/Makefile
index ea8324abc784..183827c4f917 100644
--- a/drivers/gpu/drm/i915/gvt/Makefile
+++ b/drivers/gpu/drm/i915/gvt/Makefile
@@ -3,7 +3,7 @@ GVT_DIR := gvt
 GVT_SOURCE := gvt.o aperture_gm.o handlers.o vgpu.o trace_points.o firmware.o \
interrupt.o gtt.o cfg_space.o opregion.o mmio.o display.o edid.o \
execlist.o scheduler.o sched_policy.o mmio_context.o cmd_parser.o 
debugfs.o \
-   fb_decoder.o dmabuf.o page_track.o
+   fb_decoder.o dmabuf.o page_track.o gvt_public.o
 
 ccflags-y  += -I $(srctree)/$(src) -I 
$(srctree)/$(src)/$(GVT_DIR)/
 i915-y += $(addprefix $(GVT_DIR)/, 
$(GVT_SOURCE))
diff --git a/drivers/gpu/drm/i915/gvt/debug.h b/drivers/gpu/drm/i915/gvt/debug.h
index c6027125c1ec..8270f34cfa43 100644
--- a/drivers/gpu/drm/i915/gvt/debug.h
+++ b/drivers/gpu/drm/i915/gvt/debug.h
@@ -32,7 +32,7 @@ do {  
\
if (IS_ERR_OR_NULL(vgpu))   \
pr_err("gvt: "fmt, ##args); \
else\
-   pr_err("gvt: vgpu %d: "fmt, vgpu->id, ##args);\
+   pr_err("gvt: vgpu %d: "fmt, intel_vgpu_id(vgpu), ##args);   
\
 } while (0)
 
 #define gvt_dbg_core(fmt, args...) \
diff --git a/drivers/gpu/drm/i915/gvt/display.c 
b/drivers/gpu/drm/i915/gvt/display.c
index e1c313da6c00..08636fa15c46 100644
--- a/drivers/gpu/drm/i915/gvt/display.c
+++ b/drivers/gpu/drm/i915/gvt/display.c
@@ -529,3 +529,29 @@ void intel_vgpu_reset_display(struct intel_vgpu *vgpu)
 {
emulate_monitor_status_change(vgpu);
 }
+
+unsigned int vgpu_edid_xres(struct intel_vgpu_port *port)
+{
+   switch (port->id) {
+   case GVT_EDID_1024_768:
+   return 1024;
+   case GVT_EDID_1920_1200:
+   return 1920;
+   default:
+   return 0;
+   }
+}
+EXPORT_SYMBOL_GPL(vgpu_edid_xres);
+
+unsigned int vgpu_edid_yres(struct intel_vgpu_port *port)
+{
+   switch (port->id) {
+   case GVT_EDID_1024_768:
+   return 768;
+   case GVT_EDID_1920_1200:
+   return 1200;
+   default:
+   return 0;
+   }
+}
+EXPORT_SYMBOL_GPL(vgpu_edid_yres);
diff --git a/drivers/gpu/drm/i915/gvt/display.h 
b/drivers/gpu/drm/i915/gvt/display.h
index b59b34046e1e..6cdfc28b1070 100644
--- a/drivers/gpu/drm/i915/gvt/display.h
+++ b/drivers/gpu/drm/i915/gvt/display.h
@@ -43,9 +43,6 @@ struct intel_vgpu;
 #define SBI_REG_MAX20
 #define DPCD_SIZE  0x700
 
-#define intel_vgpu_port(vgpu, port) \
-   (&(vgpu->display.ports[port]))
-
 #define intel_vgpu_has_monitor_on_port(vgpu, port) \
(intel_vgpu_port(vgpu, port)->edid && \
intel_vgpu_port(vgpu, port)->edid->data_valid)
@@ -178,30 +175,6 @@ static inline char *vgpu_edid_str(enum intel_vgpu_edid id)
}
 }
 
-static inline unsigned int vgpu_edid_xres(enum intel_vgpu_edid id)
-{
-   switch (id) {
-   case GVT_EDID_1024_768:
-   return 1024;
-   case GVT_EDID_1920_1200:
-   return 1920;
-   default:
-   return 0;
-   }
-}
-
-static inline unsigned int vgpu_edid_yres(enum intel_vgpu_edid id)
-{
-   switch (id) {
-   case GVT_EDID_1024_768:
-   return 768;
-   case GVT_EDID_1920_1200:
-   return 1200;
-   

[RFC PATCH 1/4] drm/i915/gvt: make gvt oblivious of kvmgt data structures

[Julian Stecklina]

Instead of defining KVMGT per-device state in struct intel_vgpu
directly, add an indirection. This makes the GVT code oblivious of
what state KVMGT needs to keep.

The intention here is to eventually make it possible to build
hypervisor backends for the mediator, without having to touch the
mediator itself. This is a first step.

Cc: Zhenyu Wang 

Signed-off-by: Julian Stecklina 
---
 drivers/gpu/drm/i915/gvt/gvt.h   |  32 +---
 drivers/gpu/drm/i915/gvt/kvmgt.c | 287 +++
 2 files changed, 184 insertions(+), 135 deletions(-)

diff --git a/drivers/gpu/drm/i915/gvt/gvt.h b/drivers/gpu/drm/i915/gvt/gvt.h
index 0081b051d3e0..2604739e5680 100644
--- a/drivers/gpu/drm/i915/gvt/gvt.h
+++ b/drivers/gpu/drm/i915/gvt/gvt.h
@@ -196,31 +196,8 @@ struct intel_vgpu {
 
struct dentry *debugfs;
 
-#if IS_ENABLED(CONFIG_DRM_I915_GVT_KVMGT)
-   struct {
-   struct mdev_device *mdev;
-   struct vfio_region *region;
-   int num_regions;
-   struct eventfd_ctx *intx_trigger;
-   struct eventfd_ctx *msi_trigger;
-
-   /*
-* Two caches are used to avoid mapping duplicated pages (eg.
-* scratch pages). This help to reduce dma setup overhead.
-*/
-   struct rb_root gfn_cache;
-   struct rb_root dma_addr_cache;
-   unsigned long nr_cache_entries;
-   struct mutex cache_lock;
-
-   struct notifier_block iommu_notifier;
-   struct notifier_block group_notifier;
-   struct kvm *kvm;
-   struct work_struct release_work;
-   atomic_t released;
-   struct vfio_device *vfio_device;
-   } vdev;
-#endif
+   /* Hypervisor-specific device state. */
+   void *vdev;
 
struct list_head dmabuf_obj_list_head;
struct mutex dmabuf_lock;
@@ -231,6 +208,11 @@ struct intel_vgpu {
u32 scan_nonprivbb;
 };
 
+static inline void *intel_vgpu_vdev(struct intel_vgpu *vgpu)
+{
+   return vgpu->vdev;
+}
+
 /* validating GM healthy status*/
 #define vgpu_is_vm_unhealthy(ret_val) \
(((ret_val) == -EBADRQC) || ((ret_val) == -EFAULT))
diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c b/drivers/gpu/drm/i915/gvt/kvmgt.c
index bd79a9718cc7..d725a4fb94b9 100644
--- a/drivers/gpu/drm/i915/gvt/kvmgt.c
+++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
@@ -108,6 +108,36 @@ struct gvt_dma {
struct kref ref;
 };
 
+struct kvmgt_vdev {
+   struct intel_vgpu *vgpu;
+   struct mdev_device *mdev;
+   struct vfio_region *region;
+   int num_regions;
+   struct eventfd_ctx *intx_trigger;
+   struct eventfd_ctx *msi_trigger;
+
+   /*
+* Two caches are used to avoid mapping duplicated pages (eg.
+* scratch pages). This help to reduce dma setup overhead.
+*/
+   struct rb_root gfn_cache;
+   struct rb_root dma_addr_cache;
+   unsigned long nr_cache_entries;
+   struct mutex cache_lock;
+
+   struct notifier_block iommu_notifier;
+   struct notifier_block group_notifier;
+   struct kvm *kvm;
+   struct work_struct release_work;
+   atomic_t released;
+   struct vfio_device *vfio_device;
+};
+
+static inline struct kvmgt_vdev *kvmgt_vdev(struct intel_vgpu *vgpu)
+{
+   return intel_vgpu_vdev(vgpu);
+}
+
 static inline bool handle_valid(unsigned long handle)
 {
return !!(handle & ~0xff);
@@ -129,7 +159,7 @@ static void gvt_unpin_guest_page(struct intel_vgpu *vgpu, 
unsigned long gfn,
for (npage = 0; npage < total_pages; npage++) {
unsigned long cur_gfn = gfn + npage;
 
-   ret = vfio_unpin_pages(mdev_dev(vgpu->vdev.mdev), _gfn, 1);
+   ret = vfio_unpin_pages(mdev_dev(kvmgt_vdev(vgpu)->mdev), 
_gfn, 1);
WARN_ON(ret != 1);
}
 }
@@ -152,7 +182,7 @@ static int gvt_pin_guest_page(struct intel_vgpu *vgpu, 
unsigned long gfn,
unsigned long cur_gfn = gfn + npage;
unsigned long pfn;
 
-   ret = vfio_pin_pages(mdev_dev(vgpu->vdev.mdev), _gfn, 1,
+   ret = vfio_pin_pages(mdev_dev(kvmgt_vdev(vgpu)->mdev), 
_gfn, 1,
 IOMMU_READ | IOMMU_WRITE, );
if (ret != 1) {
gvt_vgpu_err("vfio_pin_pages failed for gfn 0x%lx, ret 
%d\n",
@@ -219,7 +249,7 @@ static void gvt_dma_unmap_page(struct intel_vgpu *vgpu, 
unsigned long gfn,
 static struct gvt_dma *__gvt_cache_find_dma_addr(struct intel_vgpu *vgpu,
dma_addr_t dma_addr)
 {
-   struct rb_node *node = vgpu->vdev.dma_addr_cache.rb_node;
+   struct rb_node *node = kvmgt_vdev(vgpu)->dma_addr_cache.rb_node;
struct gvt_dma *itr;
 
while (node) {
@@ -237,7 +267,7 @@ static struct gvt_dma *__gvt_cache_find_dma_addr(struct 
intel_vgpu *vgpu,
 
 static struct gvt_dma *__gvt_cache_find_gfn(struct intel_vgpu *vgpu, 

Re: [PATCH v2 4/7] drm/panfrost: Add support for a second regulator for the GPU

[Rob Herring]

On Wed, Jan 8, 2020 at 4:52 PM Nicolas Boichat  wrote:
>
> On Wed, Jan 8, 2020 at 9:23 PM Mark Brown  wrote:
> >
> > On Wed, Jan 08, 2020 at 01:23:34PM +0800, Nicolas Boichat wrote:
> >
> > > Some GPUs, namely, the bifrost/g72 part on MT8183, have a second
> > > regulator for their SRAM, let's add support for that.
> >
> > > + pfdev->regulator_sram = devm_regulator_get_optional(pfdev->dev, 
> > > "sram");
> > > + if (IS_ERR(pfdev->regulator_sram)) {
> >
> > This supply is required for the devices that need it so I'd therefore
> > expect the driver to request the supply non-optionally based on the
> > compatible string rather than just hoping that a missing regulator isn't
> > important.
>
> That'd be a bit awkward to match, though... Currently all bifrost
> share the same compatible "arm,mali-bifrost", and it'd seem
> weird/wrong to match "mediatek,mt8183-mali" in this driver? I have no
> idea if any other Mali implementation will require a second regulator,
> but with the MT8183 we do need it, see below.

The current number of supported bifrost platforms is 0. It's only a
matter of time until SoC specific compatibles need to be used in the
driver. This is why we require them.

It could very well be that all bifrost implementations need 2
supplies. On chip RAMs are very frequently a separate thing which are
synthesized differently from logic. At least within a specific IP
model, I somewhat doubt there's a variable number of supplies. It
could be possible to connect both to the same supply, but the correct
way to handle that is both -supply properties point to the same
regulator.

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

Re: [PATCH v2 4/7] drm/panfrost: Add support for a second regulator for the GPU

[Steven Price]

On 09/01/2020 16:28, Mark Brown wrote:

On Thu, Jan 09, 2020 at 02:14:42PM +, Steven Price wrote:

On 08/01/2020 22:52, Nicolas Boichat wrote:



That'd be a bit awkward to match, though... Currently all bifrost
share the same compatible "arm,mali-bifrost", and it'd seem
weird/wrong to match "mediatek,mt8183-mali" in this driver? I have no
idea if any other Mali implementation will require a second regulator,
but with the MT8183 we do need it, see below.


This doesn't sound particularly hard, just new.  Plenty of other devices
have quirks done based on the SoC they're in or the IP revision, this
would just be another of those quirks.


Well if devfreq was working (see patch 7
https://patchwork.kernel.org/patch/11322851/ for a partial
implementation), it would adjust both mali and sram regulators, see
the OPP table in patch 2
(https://patchwork.kernel.org/patch/11322825/): SRAM voltage needs to
be increased for frequencies >=698Mhz.



Now if you have some better idea how to implement this, I'm all ears!


Set a flag based on the compatible, then base runtime decisions off
that.


I'm not sure if it's better, but could we just encode the list of
regulators into device tree. I'm a bit worried about special casing an
"sram" regulator given that other platforms might have a similar
situation but call the second regulator a different name.


Obviously the list of regulators bound on a given platform is encoded in
the device tree but you shouldn't really be relying on that to figure
out what to request in the driver - the driver should know what it's
expecting. 


From a driver perspective we don't expect to have to worry about power 
domains/multiple regulators - the hardware provides a bunch of power 
registers to turn on/off various parts of the hardware and this should 
be linked (in hardware) to a PDC which sorts it out. The GPU/PDC handles 
the required sequencing. So it *should* be a case of turn power/clocks 
on and go.


However certain integrations may have quirks such that there are 
physically multiple supplies. These are expected to all be turned on 
before using the GPU. Quite how this is best represented is something 
I'm not sure about.



Bear in mind that getting regulator stuff wrong can result
in physical damage to the system so it pays to be careful and to
consider that platform integrators have a tendency to rely on things
that just happen to work but aren't a good idea or accurate
representations of the system.  It's certainly *possible* to do
something like that, the information is there, but I would not in any
way recommend doing things that way as it's likely to not be robust.

The possibility that the regulator setup may vary on other platforms
(which I'd expect TBH) does suggest that just requesting a bunch of
supply names optionally and hoping that we got all the ones that are
important on a given platform is going to lead to trouble down the line.


Certainly if we miss a regulator the GPU isn't going to work properly 
(some cores won't be able to power up successfully). However at the 
moment the driver will happily do this if someone provides it with a DT 
which includes regulators that it doesn't know about. So I'm not sure 
how adding special case code for a SoC would help here.



Steve, please fix your mail client to word wrap within paragraphs at
something substantially less than 80 columns.  Doing this makes your
messages much easier to read and reply to.


Sorry about that - I switched to my laptop to escape the noisy work 
going on outside the office, and apparently that was misconfigured. 
Hopefully fixed now, thanks for letting me know!


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

Re: [PATCH] drm/i915/dp: Add current maximum eDP link rate to sink_rate array.

[Mario Kleiner]

On Thu, Jan 9, 2020 at 4:40 PM Alex Deucher  wrote:

> On Thu, Jan 9, 2020 at 10:08 AM Mario Kleiner
>  wrote:
> >
> > If the current eDP link rate, as read from hw, provides a
> > higher bandwidth than the standard link rates, then add the
> > current link rate to the link_rates array for consideration
> > in future mode-sets.
> >
> > These initial current eDP link settings have been set up by
> > firmware during boot, so they should work on the eDP panel.
> > Therefore use them if the firmware thinks they are good and
> > they provide higher link bandwidth, e.g., to enable higher
> > resolutions / color depths.
> >
> > This fixes a problem found on the MacBookPro 2017 Retina panel:
> >
> > The panel reports 10 bpc color depth in its EDID, and the UEFI
> > firmware chooses link settings at boot which support enough
> > bandwidth for 10 bpc (324000 kbit/sec to be precise), but the
> > DP_MAX_LINK_RATE dpcd register only reports 2.7 Gbps as possible,
> > so intel_dp_set_sink_rates() would cap at that. This restricts
> > achievable color depth to 8 bpc, not providing the full color
> > depth of the panel. With this commit, we can use firmware setting
> > and get the full 10 bpc advertised by the Retina panel.
>
> Would it make more sense to just add a quirk for this particular
> panel?  Would there be cases where the link was programmed wrong and
> then we end up using that additional link speed as supported?
>
> Alex
>
>
Not sure. This MBP 2017 is the only non-ancient laptop i now have. I'd
assume many other Apple Retina panels would behave similar. The panels dpcd
regs report DP 1.1 and eDP 1.3, so the flexible table with additional modes
from eDP1.4+ does not exist. According to Wikipedia, eDP 1.4 was introduced
in february 2013 and this is a mid 2017 machine, so Apple seems to be quite
behind. Therefore i assume  we'd need a lot of quirks over time.

That said:

1. The logic in amdgpu's DC for the same purpose is a bit different than on
the intel side.

2. DC allows overriding DP link settings, that's how i initially tested
this, so one could do the "quirk" via something like that in a bootup
script. So on AMD one could work around the lack of the patch and of quirks.

3. I spent a lot of time with a photo-meter, testing the quality of the 10
bit: It turns out that running the panel at 8 bit + AMD's spatial dithering
that kicks in gives better results than running the panel in native 10 bit.
Maybe the panel is not really a 10 bit one, but just pretends to be and
then uses its own dithering to achieve 10 bit. So at least on AMD one is
better off precision-wise with the 8 bit panel default with this specific
panel.

On Intel however, we don't do dithering for > 6 bpc panels atm., so using
the panel at 10 bpc is the only way to get 10 bit display atm. Adn we don't
use dithering on Intel at > 6 bpc panels atm., because there are some
oddities in the way Intel hw dithers at higher bit depths - it also dithers
pixel values where it shouldn't. That makes it impossible to get an
identity passthrough of a 8 bpc framebuffer to the outputs, which kills all
kind of special display equipment that needs that identity passthrough to
work.

-mario

>
> > Signed-off-by: Mario Kleiner 
> > Cc: Daniel Vetter 
> > ---
> >  drivers/gpu/drm/i915/display/intel_dp.c | 23 +++
> >  1 file changed, 23 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> > index 2f31d226c6eb..aa3e0b5108c6 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > @@ -4368,6 +4368,8 @@ intel_edp_init_dpcd(struct intel_dp *intel_dp)
> >  {
> > struct drm_i915_private *dev_priv =
> > to_i915(dp_to_dig_port(intel_dp)->base.base.dev);
> > +   int max_rate;
> > +   u8 link_bw;
> >
> > /* this function is meant to be called only once */
> > WARN_ON(intel_dp->dpcd[DP_DPCD_REV] != 0);
> > @@ -4433,6 +4435,27 @@ intel_edp_init_dpcd(struct intel_dp *intel_dp)
> > else
> > intel_dp_set_sink_rates(intel_dp);
> >
> > +   /*
> > +* If the firmware programmed a rate higher than the standard
> sink rates
> > +* during boot, then add that rate as a valid sink rate, as fw
> knows
> > +* this is a good rate and we get extra bandwidth.
> > +*
> > +* Helps, e.g., on the Apple MacBookPro 2017 Retina panel, which
> is only
> > +* eDP 1.1, but supports the unusual rate of 324000 kHz at
> bootup, for
> > +* 10 bpc / 30 bit color depth.
> > +*/
> > +   if (!intel_dp->use_rate_select &&
> > +   (drm_dp_dpcd_read(_dp->aux, DP_LINK_BW_SET, _bw,
> 1) == 1) &&
> > +   (link_bw > 0) && (intel_dp->num_sink_rates <
> DP_MAX_SUPPORTED_RATES)) {
> > +   max_rate = drm_dp_bw_code_to_link_rate(link_bw);
> > +   if (max_rate >
> 

Re: [PATCH] drm/i915/dp: Add current maximum eDP link rate to sink_rate array.

[Ville Syrjälä]

On Thu, Jan 09, 2020 at 05:30:05PM +0100, Mario Kleiner wrote:
> On Thu, Jan 9, 2020 at 4:38 PM Ville Syrjälä 
> wrote:
> 
> > On Thu, Jan 09, 2020 at 05:26:57PM +0200, Ville Syrjälä wrote:
> > > On Thu, Jan 09, 2020 at 04:07:52PM +0100, Mario Kleiner wrote:
> > > > The panel reports 10 bpc color depth in its EDID, and the UEFI
> > > > firmware chooses link settings at boot which support enough
> > > > bandwidth for 10 bpc (324000 kbit/sec to be precise), but the
> > > > DP_MAX_LINK_RATE dpcd register only reports 2.7 Gbps as possible,
> >
> > Does it actually or do we just ignore the fact that it reports 3.24Gbps?
> >
> > If it really reports 3.24 then we should be able to just add that to
> > dp_rates[] in intel_dp_set_sink_rates() and be done with it.
> >
> > Although we'd likely want to skip 3.24 unless it really is reported
> > as the max so as to not use that non-standard rate on other displays.
> > So would require a bit fancier logic for that.
> >
> >
> Was also my initial thought, but the DP_MAX_LINK_RATE reg reports 2.7 Gbps
> as maximum.

So dpcd[0x1] == 0xa ?

What about the magic second version of DP_MAX_LINK_RATE at 0x2201 ?
Hmm. I guess we should already be reading that via
intel_dp_extended_receiver_capabilities().

-- 
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/fb-cma-helpers: Fix include issue

[Benjamin Gaignard]

Le jeu. 9 janv. 2020 à 17:29, Benjamin GAIGNARD
 a écrit :
>
>
> On 12/3/19 5:49 PM, Benjamin Gaignard wrote:
> > Le mer. 20 nov. 2019 à 00:28, Benjamin Gaignard
> >  a écrit :
> >> Exported functions prototypes are missing in drm_fb_cma_helper.c
> >> Include drm_fb_cma_helper to fix that issue.
> >>
> > Gentle ping to reviewers.
> > Thanks,
> > Benjamin
>
> I know that removing warnings is not a sexy task, but reviewers are welcome.

Applied on drm-misc-next, with Thomas ack even if dri patchwork doesn't show it.

Thanks
Benjamin

>
> Thanks,
>
> Benjamin
>
> >
> >> Signed-off-by: Benjamin Gaignard 
> >> ---
> >>   drivers/gpu/drm/drm_fb_cma_helper.c | 1 +
> >>   include/drm/drm_fb_cma_helper.h | 2 ++
> >>   2 files changed, 3 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c 
> >> b/drivers/gpu/drm/drm_fb_cma_helper.c
> >> index c0b0f603af63..9801c0333eca 100644
> >> --- a/drivers/gpu/drm/drm_fb_cma_helper.c
> >> +++ b/drivers/gpu/drm/drm_fb_cma_helper.c
> >> @@ -9,6 +9,7 @@
> >>*  Copyright (C) 2012 Red Hat
> >>*/
> >>
> >> +#include 
> >>   #include 
> >>   #include 
> >>   #include 
> >> diff --git a/include/drm/drm_fb_cma_helper.h 
> >> b/include/drm/drm_fb_cma_helper.h
> >> index 4becb09975a4..795aea1d0a25 100644
> >> --- a/include/drm/drm_fb_cma_helper.h
> >> +++ b/include/drm/drm_fb_cma_helper.h
> >> @@ -2,6 +2,8 @@
> >>   #ifndef __DRM_FB_CMA_HELPER_H__
> >>   #define __DRM_FB_CMA_HELPER_H__
> >>
> >> +#include 
> >> +
> >>   struct drm_framebuffer;
> >>   struct drm_plane_state;
> >>
> >> --
> >> 2.15.0
> >>
> >> ___
> >> 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] drm/i915/dp: Add current maximum eDP link rate to sink_rate array.

[Ville Syrjälä]

On Thu, Jan 09, 2020 at 05:38:15PM +0200, Ville Syrjälä wrote:
> On Thu, Jan 09, 2020 at 05:26:57PM +0200, Ville Syrjälä wrote:
> > On Thu, Jan 09, 2020 at 04:07:52PM +0100, Mario Kleiner wrote:
> > > If the current eDP link rate, as read from hw, provides a
> > > higher bandwidth than the standard link rates, then add the
> > > current link rate to the link_rates array for consideration
> > > in future mode-sets.
> > > 
> > > These initial current eDP link settings have been set up by
> > > firmware during boot, so they should work on the eDP panel.
> > > Therefore use them if the firmware thinks they are good and
> > > they provide higher link bandwidth, e.g., to enable higher
> > > resolutions / color depths.
> > > 
> > > This fixes a problem found on the MacBookPro 2017 Retina panel:
> > > 
> > > The panel reports 10 bpc color depth in its EDID, and the UEFI
> > > firmware chooses link settings at boot which support enough
> > > bandwidth for 10 bpc (324000 kbit/sec to be precise), but the
> > > DP_MAX_LINK_RATE dpcd register only reports 2.7 Gbps as possible,
> 
> Does it actually or do we just ignore the fact that it reports 3.24Gbps?
> 
> If it really reports 3.24 then we should be able to just add that to
> dp_rates[] in intel_dp_set_sink_rates() and be done with it.
> 
> Although we'd likely want to skip 3.24 unless it really is reported
> as the max so as to not use that non-standard rate on other displays.
> So would require a bit fancier logic for that.

Maybe just something like this?

--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -177,6 +177,12 @@ static void intel_dp_set_sink_rates(struct intel_dp 
*intel_dp)
intel_dp->sink_rates[i] = dp_rates[i];
}
 
+   /* blah */
+   if (max_rate > intel_dp->sink_rates[i - 1]) {
+   DRM_DEBUG_KMS(...);
+   intel_dp->sink_rates[i++] = max_rate;
+   }
+
intel_dp->num_sink_rates = i;

> 
> > > so intel_dp_set_sink_rates() would cap at that. This restricts
> > > achievable color depth to 8 bpc, not providing the full color
> > > depth of the panel. With this commit, we can use firmware setting
> > > and get the full 10 bpc advertised by the Retina panel.
> > > 
> > > Signed-off-by: Mario Kleiner 
> > > Cc: Daniel Vetter 
> > > ---
> > >  drivers/gpu/drm/i915/display/intel_dp.c | 23 +++
> > >  1 file changed, 23 insertions(+)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
> > > b/drivers/gpu/drm/i915/display/intel_dp.c
> > > index 2f31d226c6eb..aa3e0b5108c6 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > > @@ -4368,6 +4368,8 @@ intel_edp_init_dpcd(struct intel_dp *intel_dp)
> > >  {
> > >   struct drm_i915_private *dev_priv =
> > >   to_i915(dp_to_dig_port(intel_dp)->base.base.dev);
> > > + int max_rate;
> > > + u8 link_bw;
> > >  
> > >   /* this function is meant to be called only once */
> > >   WARN_ON(intel_dp->dpcd[DP_DPCD_REV] != 0);
> > > @@ -4433,6 +4435,27 @@ intel_edp_init_dpcd(struct intel_dp *intel_dp)
> > >   else
> > >   intel_dp_set_sink_rates(intel_dp);
> > >  
> > > + /*
> > > +  * If the firmware programmed a rate higher than the standard sink rates
> > > +  * during boot, then add that rate as a valid sink rate, as fw knows
> > > +  * this is a good rate and we get extra bandwidth.
> > > +  *
> > > +  * Helps, e.g., on the Apple MacBookPro 2017 Retina panel, which is only
> > > +  * eDP 1.1, but supports the unusual rate of 324000 kHz at bootup, for
> > > +  * 10 bpc / 30 bit color depth.
> > > +  */
> > > + if (!intel_dp->use_rate_select &&
> > > + (drm_dp_dpcd_read(_dp->aux, DP_LINK_BW_SET, _bw, 1) == 
> > > 1) &&
> > > + (link_bw > 0) && (intel_dp->num_sink_rates < 
> > > DP_MAX_SUPPORTED_RATES)) {
> > > + max_rate = drm_dp_bw_code_to_link_rate(link_bw);
> > > + if (max_rate > intel_dp->sink_rates[intel_dp->num_sink_rates - 
> > > 1]) {
> > > + intel_dp->sink_rates[intel_dp->num_sink_rates] = 
> > > max_rate;
> > > + intel_dp->num_sink_rates++;
> > > + DRM_DEBUG_KMS("Adding max bandwidth eDP rate %d kHz.\n",
> > > +   max_rate);
> > > + }
> > 
> > Hmm. I guess we could do this. But plese put it into a separate
> > function so we don't end up with that super ugly if condition.
> > 
> > The debug message should probably be a bit more explicit. Eg. 
> > something like: 
> > "Firmware using non-standard link rate %d kHz. Including it in sink 
> > rates.\n"
> > 
> > I'm also wondering if we shouldn't just add the link rate to the sink
> > rates regradless of whether it's the highest rate or not...
> > 
> > > + }
> > > +
> > >   intel_dp_set_common_rates(intel_dp);
> > >  
> > >   /* Read the eDP DSC DPCD registers */
> > > -- 
> > > 2.24.0
> > > 
> > > ___

Re: [PATCH] drm/i915/dp: Add current maximum eDP link rate to sink_rate array.

[Mario Kleiner]

On Thu, Jan 9, 2020 at 4:38 PM Ville Syrjälä 
wrote:

> On Thu, Jan 09, 2020 at 05:26:57PM +0200, Ville Syrjälä wrote:
> > On Thu, Jan 09, 2020 at 04:07:52PM +0100, Mario Kleiner wrote:
> > > The panel reports 10 bpc color depth in its EDID, and the UEFI
> > > firmware chooses link settings at boot which support enough
> > > bandwidth for 10 bpc (324000 kbit/sec to be precise), but the
> > > DP_MAX_LINK_RATE dpcd register only reports 2.7 Gbps as possible,
>
> Does it actually or do we just ignore the fact that it reports 3.24Gbps?
>
> If it really reports 3.24 then we should be able to just add that to
> dp_rates[] in intel_dp_set_sink_rates() and be done with it.
>
> Although we'd likely want to skip 3.24 unless it really is reported
> as the max so as to not use that non-standard rate on other displays.
> So would require a bit fancier logic for that.
>
>
Was also my initial thought, but the DP_MAX_LINK_RATE reg reports 2.7 Gbps
as maximum.
-mario
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 4/7] drm/panfrost: Add support for a second regulator for the GPU

[Mark Brown]

On Thu, Jan 09, 2020 at 02:14:42PM +, Steven Price wrote:
> On 08/01/2020 22:52, Nicolas Boichat wrote:

> > That'd be a bit awkward to match, though... Currently all bifrost
> > share the same compatible "arm,mali-bifrost", and it'd seem
> > weird/wrong to match "mediatek,mt8183-mali" in this driver? I have no
> > idea if any other Mali implementation will require a second regulator,
> > but with the MT8183 we do need it, see below.

This doesn't sound particularly hard, just new.  Plenty of other devices
have quirks done based on the SoC they're in or the IP revision, this
would just be another of those quirks.

> > Well if devfreq was working (see patch 7
> > https://patchwork.kernel.org/patch/11322851/ for a partial
> > implementation), it would adjust both mali and sram regulators, see
> > the OPP table in patch 2
> > (https://patchwork.kernel.org/patch/11322825/): SRAM voltage needs to
> > be increased for frequencies >=698Mhz.

> > Now if you have some better idea how to implement this, I'm all ears!

Set a flag based on the compatible, then base runtime decisions off
that.

> I'm not sure if it's better, but could we just encode the list of
> regulators into device tree. I'm a bit worried about special casing an
> "sram" regulator given that other platforms might have a similar
> situation but call the second regulator a different name.

Obviously the list of regulators bound on a given platform is encoded in
the device tree but you shouldn't really be relying on that to figure
out what to request in the driver - the driver should know what it's
expecting.  Bear in mind that getting regulator stuff wrong can result
in physical damage to the system so it pays to be careful and to
consider that platform integrators have a tendency to rely on things
that just happen to work but aren't a good idea or accurate
representations of the system.  It's certainly *possible* to do
something like that, the information is there, but I would not in any
way recommend doing things that way as it's likely to not be robust.

The possibility that the regulator setup may vary on other platforms
(which I'd expect TBH) does suggest that just requesting a bunch of
supply names optionally and hoping that we got all the ones that are
important on a given platform is going to lead to trouble down the line.

Steve, please fix your mail client to word wrap within paragraphs at
something substantially less than 80 columns.  Doing this makes your
messages much easier to read and reply to.


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

Re: [PATCH] drm/i915/dp: Add current maximum eDP link rate to sink_rate array.

[Mario Kleiner]

On Thu, Jan 9, 2020 at 4:27 PM Ville Syrjälä 
wrote:

> On Thu, Jan 09, 2020 at 04:07:52PM +0100, Mario Kleiner wrote:
> > If the current eDP link rate, as read from hw, provides a
> > higher bandwidth than the standard link rates, then add the
> > current link rate to the link_rates array for consideration
> > in future mode-sets.
> >
> > These initial current eDP link settings have been set up by
> > firmware during boot, so they should work on the eDP panel.
> > Therefore use them if the firmware thinks they are good and
> > they provide higher link bandwidth, e.g., to enable higher
> > resolutions / color depths.
> >
> > This fixes a problem found on the MacBookPro 2017 Retina panel:
> >
> > The panel reports 10 bpc color depth in its EDID, and the UEFI
> > firmware chooses link settings at boot which support enough
> > bandwidth for 10 bpc (324000 kbit/sec to be precise), but the
> > DP_MAX_LINK_RATE dpcd register only reports 2.7 Gbps as possible,
> > so intel_dp_set_sink_rates() would cap at that. This restricts
> > achievable color depth to 8 bpc, not providing the full color
> > depth of the panel. With this commit, we can use firmware setting
> > and get the full 10 bpc advertised by the Retina panel.
> >
> > Signed-off-by: Mario Kleiner 
> > Cc: Daniel Vetter 
> > ---
> >  drivers/gpu/drm/i915/display/intel_dp.c | 23 +++
> >  1 file changed, 23 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> > index 2f31d226c6eb..aa3e0b5108c6 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > @@ -4368,6 +4368,8 @@ intel_edp_init_dpcd(struct intel_dp *intel_dp)
> >  {
> >   struct drm_i915_private *dev_priv =
> >   to_i915(dp_to_dig_port(intel_dp)->base.base.dev);
> > + int max_rate;
> > + u8 link_bw;
> >
> >   /* this function is meant to be called only once */
> >   WARN_ON(intel_dp->dpcd[DP_DPCD_REV] != 0);
> > @@ -4433,6 +4435,27 @@ intel_edp_init_dpcd(struct intel_dp *intel_dp)
> >   else
> >   intel_dp_set_sink_rates(intel_dp);
> >
> > + /*
> > +  * If the firmware programmed a rate higher than the standard sink
> rates
> > +  * during boot, then add that rate as a valid sink rate, as fw
> knows
> > +  * this is a good rate and we get extra bandwidth.
> > +  *
> > +  * Helps, e.g., on the Apple MacBookPro 2017 Retina panel, which
> is only
> > +  * eDP 1.1, but supports the unusual rate of 324000 kHz at bootup,
> for
> > +  * 10 bpc / 30 bit color depth.
> > +  */
> > + if (!intel_dp->use_rate_select &&
> > + (drm_dp_dpcd_read(_dp->aux, DP_LINK_BW_SET, _bw, 1)
> == 1) &&
> > + (link_bw > 0) && (intel_dp->num_sink_rates <
> DP_MAX_SUPPORTED_RATES)) {
> > + max_rate = drm_dp_bw_code_to_link_rate(link_bw);
> > + if (max_rate >
> intel_dp->sink_rates[intel_dp->num_sink_rates - 1]) {
> > + intel_dp->sink_rates[intel_dp->num_sink_rates] =
> max_rate;
> > + intel_dp->num_sink_rates++;
> > + DRM_DEBUG_KMS("Adding max bandwidth eDP rate %d
> kHz.\n",
> > +   max_rate);
> > + }
>
> Hmm. I guess we could do this. But plese put it into a separate
> function so we don't end up with that super ugly if condition.
>
>
Ok. Does static void intel_edp_add_bootup_rate() good to you? Or
intel_edp_add_fw_rate()?

The debug message should probably be a bit more explicit. Eg.
> something like:
> "Firmware using non-standard link rate %d kHz. Including it in sink
> rates.\n"
>

Ok.


> I'm also wondering if we shouldn't just add the link rate to the sink
> rates regradless of whether it's the highest rate or not...
>
>
I tried to be conservative, and simple, but yes, one could add it anyway.
Would need to preserve the order in the sink_rates[] array.
Your choice, your're the expert :)


> > + }
> > +
> >   intel_dp_set_common_rates(intel_dp);
> >
> >   /* Read the eDP DSC DPCD registers */
> > --
> > 2.24.0
> >
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> --
> Ville Syrjälä
> Intel
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RESEND 1/1] drm/panel: Add support for BOE NV140FHM-N49 panel to panel-simple

[Sam Ravnborg]

Hi Tobias.

On Thu, Jan 09, 2020 at 12:29:52PM +0100, Tobias Schramm wrote:
> This patch adds support for the BOE NV140FHM-N49 panel to the panel-simple
> driver. The panel is used by the pine64 Pinebook Pro.
> 
> Signed-off-by: Tobias Schramm 

Applied to drm-misc-next togher with the bindings patch.
Thanks for the quick r-b.

Sam

> ---
>  drivers/gpu/drm/panel/panel-simple.c | 35 
>  1 file changed, 35 insertions(+)
> 
> diff --git a/drivers/gpu/drm/panel/panel-simple.c 
> b/drivers/gpu/drm/panel/panel-simple.c
> index 5d487686d25c..6320df9765f3 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -1036,6 +1036,38 @@ static const struct panel_desc boe_nv101wxmn51 = {
>   },
>  };
>  
> +static const struct drm_display_mode boe_nv140fhmn49_modes[] = {
> + {
> + .clock = 148500,
> + .hdisplay = 1920,
> + .hsync_start = 1920 + 48,
> + .hsync_end = 1920 + 48 + 32,
> + .htotal = 2200,
> + .vdisplay = 1080,
> + .vsync_start = 1080 + 3,
> + .vsync_end = 1080 + 3 + 5,
> + .vtotal = 1125,
> + .vrefresh = 60,
> + },
> +};
> +
> +static const struct panel_desc boe_nv140fhmn49 = {
> + .modes = boe_nv140fhmn49_modes,
> + .num_modes = ARRAY_SIZE(boe_nv140fhmn49_modes),
> + .bpc = 6,
> + .size = {
> + .width = 309,
> + .height = 174,
> + },
> + .delay = {
> + .prepare = 210,
> + .enable = 50,
> + .unprepare = 160,
> + },
> + .bus_format = MEDIA_BUS_FMT_RGB666_1X18,
> + .connector_type = DRM_MODE_CONNECTOR_eDP,
> +};
> +
>  static const struct drm_display_mode cdtech_s043wq26h_ct7_mode = {
>   .clock = 9000,
>   .hdisplay = 480,
> @@ -3161,6 +3193,9 @@ static const struct of_device_id platform_of_match[] = {
>   }, {
>   .compatible = "boe,nv101wxmn51",
>   .data = _nv101wxmn51,
> + }, {
> + .compatible = "boe,nv140fhmn49",
> + .data = _nv140fhmn49,
>   }, {
>   .compatible = "cdtech,s043wq26h-ct7",
>   .data = _s043wq26h_ct7,
> -- 
> 2.24.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/i915/dp: Add current maximum eDP link rate to sink_rate array.

[Alex Deucher]

On Thu, Jan 9, 2020 at 10:08 AM Mario Kleiner
 wrote:
>
> If the current eDP link rate, as read from hw, provides a
> higher bandwidth than the standard link rates, then add the
> current link rate to the link_rates array for consideration
> in future mode-sets.
>
> These initial current eDP link settings have been set up by
> firmware during boot, so they should work on the eDP panel.
> Therefore use them if the firmware thinks they are good and
> they provide higher link bandwidth, e.g., to enable higher
> resolutions / color depths.
>
> This fixes a problem found on the MacBookPro 2017 Retina panel:
>
> The panel reports 10 bpc color depth in its EDID, and the UEFI
> firmware chooses link settings at boot which support enough
> bandwidth for 10 bpc (324000 kbit/sec to be precise), but the
> DP_MAX_LINK_RATE dpcd register only reports 2.7 Gbps as possible,
> so intel_dp_set_sink_rates() would cap at that. This restricts
> achievable color depth to 8 bpc, not providing the full color
> depth of the panel. With this commit, we can use firmware setting
> and get the full 10 bpc advertised by the Retina panel.

Would it make more sense to just add a quirk for this particular
panel?  Would there be cases where the link was programmed wrong and
then we end up using that additional link speed as supported?

Alex

>
> Signed-off-by: Mario Kleiner 
> Cc: Daniel Vetter 
> ---
>  drivers/gpu/drm/i915/display/intel_dp.c | 23 +++
>  1 file changed, 23 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 2f31d226c6eb..aa3e0b5108c6 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -4368,6 +4368,8 @@ intel_edp_init_dpcd(struct intel_dp *intel_dp)
>  {
> struct drm_i915_private *dev_priv =
> to_i915(dp_to_dig_port(intel_dp)->base.base.dev);
> +   int max_rate;
> +   u8 link_bw;
>
> /* this function is meant to be called only once */
> WARN_ON(intel_dp->dpcd[DP_DPCD_REV] != 0);
> @@ -4433,6 +4435,27 @@ intel_edp_init_dpcd(struct intel_dp *intel_dp)
> else
> intel_dp_set_sink_rates(intel_dp);
>
> +   /*
> +* If the firmware programmed a rate higher than the standard sink 
> rates
> +* during boot, then add that rate as a valid sink rate, as fw knows
> +* this is a good rate and we get extra bandwidth.
> +*
> +* Helps, e.g., on the Apple MacBookPro 2017 Retina panel, which is 
> only
> +* eDP 1.1, but supports the unusual rate of 324000 kHz at bootup, for
> +* 10 bpc / 30 bit color depth.
> +*/
> +   if (!intel_dp->use_rate_select &&
> +   (drm_dp_dpcd_read(_dp->aux, DP_LINK_BW_SET, _bw, 1) == 
> 1) &&
> +   (link_bw > 0) && (intel_dp->num_sink_rates < 
> DP_MAX_SUPPORTED_RATES)) {
> +   max_rate = drm_dp_bw_code_to_link_rate(link_bw);
> +   if (max_rate > intel_dp->sink_rates[intel_dp->num_sink_rates 
> - 1]) {
> +   intel_dp->sink_rates[intel_dp->num_sink_rates] = 
> max_rate;
> +   intel_dp->num_sink_rates++;
> +   DRM_DEBUG_KMS("Adding max bandwidth eDP rate %d 
> kHz.\n",
> + max_rate);
> +   }
> +   }
> +
> intel_dp_set_common_rates(intel_dp);
>
> /* Read the eDP DSC DPCD registers */
> --
> 2.24.0
>
> ___
> 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] drm/i915/dp: Add current maximum eDP link rate to sink_rate array.

[Ville Syrjälä]

On Thu, Jan 09, 2020 at 05:26:57PM +0200, Ville Syrjälä wrote:
> On Thu, Jan 09, 2020 at 04:07:52PM +0100, Mario Kleiner wrote:
> > If the current eDP link rate, as read from hw, provides a
> > higher bandwidth than the standard link rates, then add the
> > current link rate to the link_rates array for consideration
> > in future mode-sets.
> > 
> > These initial current eDP link settings have been set up by
> > firmware during boot, so they should work on the eDP panel.
> > Therefore use them if the firmware thinks they are good and
> > they provide higher link bandwidth, e.g., to enable higher
> > resolutions / color depths.
> > 
> > This fixes a problem found on the MacBookPro 2017 Retina panel:
> > 
> > The panel reports 10 bpc color depth in its EDID, and the UEFI
> > firmware chooses link settings at boot which support enough
> > bandwidth for 10 bpc (324000 kbit/sec to be precise), but the
> > DP_MAX_LINK_RATE dpcd register only reports 2.7 Gbps as possible,

Does it actually or do we just ignore the fact that it reports 3.24Gbps?

If it really reports 3.24 then we should be able to just add that to
dp_rates[] in intel_dp_set_sink_rates() and be done with it.

Although we'd likely want to skip 3.24 unless it really is reported
as the max so as to not use that non-standard rate on other displays.
So would require a bit fancier logic for that.

> > so intel_dp_set_sink_rates() would cap at that. This restricts
> > achievable color depth to 8 bpc, not providing the full color
> > depth of the panel. With this commit, we can use firmware setting
> > and get the full 10 bpc advertised by the Retina panel.
> > 
> > Signed-off-by: Mario Kleiner 
> > Cc: Daniel Vetter 
> > ---
> >  drivers/gpu/drm/i915/display/intel_dp.c | 23 +++
> >  1 file changed, 23 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
> > b/drivers/gpu/drm/i915/display/intel_dp.c
> > index 2f31d226c6eb..aa3e0b5108c6 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > @@ -4368,6 +4368,8 @@ intel_edp_init_dpcd(struct intel_dp *intel_dp)
> >  {
> > struct drm_i915_private *dev_priv =
> > to_i915(dp_to_dig_port(intel_dp)->base.base.dev);
> > +   int max_rate;
> > +   u8 link_bw;
> >  
> > /* this function is meant to be called only once */
> > WARN_ON(intel_dp->dpcd[DP_DPCD_REV] != 0);
> > @@ -4433,6 +4435,27 @@ intel_edp_init_dpcd(struct intel_dp *intel_dp)
> > else
> > intel_dp_set_sink_rates(intel_dp);
> >  
> > +   /*
> > +* If the firmware programmed a rate higher than the standard sink rates
> > +* during boot, then add that rate as a valid sink rate, as fw knows
> > +* this is a good rate and we get extra bandwidth.
> > +*
> > +* Helps, e.g., on the Apple MacBookPro 2017 Retina panel, which is only
> > +* eDP 1.1, but supports the unusual rate of 324000 kHz at bootup, for
> > +* 10 bpc / 30 bit color depth.
> > +*/
> > +   if (!intel_dp->use_rate_select &&
> > +   (drm_dp_dpcd_read(_dp->aux, DP_LINK_BW_SET, _bw, 1) == 
> > 1) &&
> > +   (link_bw > 0) && (intel_dp->num_sink_rates < 
> > DP_MAX_SUPPORTED_RATES)) {
> > +   max_rate = drm_dp_bw_code_to_link_rate(link_bw);
> > +   if (max_rate > intel_dp->sink_rates[intel_dp->num_sink_rates - 
> > 1]) {
> > +   intel_dp->sink_rates[intel_dp->num_sink_rates] = 
> > max_rate;
> > +   intel_dp->num_sink_rates++;
> > +   DRM_DEBUG_KMS("Adding max bandwidth eDP rate %d kHz.\n",
> > + max_rate);
> > +   }
> 
> Hmm. I guess we could do this. But plese put it into a separate
> function so we don't end up with that super ugly if condition.
> 
> The debug message should probably be a bit more explicit. Eg. 
> something like: 
> "Firmware using non-standard link rate %d kHz. Including it in sink rates.\n"
> 
> I'm also wondering if we shouldn't just add the link rate to the sink
> rates regradless of whether it's the highest rate or not...
> 
> > +   }
> > +
> > intel_dp_set_common_rates(intel_dp);
> >  
> > /* Read the eDP DSC DPCD registers */
> > -- 
> > 2.24.0
> > 
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
> -- 
> Ville Syrjälä
> Intel

-- 
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RESEND 0/1] Add support for BOE NV140FHM-N49 panel to panel-simple

[Tobias Schramm]

Hi Tobias.

We need binding schema before we can apply this patch.

Knew I forgot something

See patch below.
Please review/ack the patch, then we can process your panel-simple
patch.

LGTM, thanks!

Sam

On Thu, Jan 09, 2020 at 12:29:51PM +0100, Tobias Schramm wrote:

This patch adds support for the 14 inch BOE NV140FHM-N49 eDP panel to
the panel-simple driver. The panel is used by the Pinebook Pro.

Resending with changed CCs due to lack of feedback.





Tobias Schramm (1):
   drm/panel: Add support for BOE NV140FHM-N49 panel to panel-simple

  drivers/gpu/drm/panel/panel-simple.c | 35 
  1 file changed, 35 insertions(+)


 From ad19c4636475bb05ba5c0b6cec2bee85045d628e Mon Sep 17 00:00:00 2001
From: Sam Ravnborg 
Date: Thu, 9 Jan 2020 14:48:41 +0100
Subject: [PATCH] dt-bindings: display: add BOE 14" panel

Add bindings for the BOE NV140FHM-N49 14" 1920x1080 panel.

The panel is used by the pine64 Pinebook Pro.

Signed-off-by: Sam Ravnborg 
Cc: Thierry Reding 
Cc: Tobias Schramm 
---
  .../devicetree/bindings/display/panel/panel-simple.yaml | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml 
b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
index ddc00480b6fe..6c098a0b6e1e 100644
--- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
+++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
@@ -35,6 +35,8 @@ properties:
- ampire,am800480r3tmqwa1h
  # AUO B116XAK01 eDP TFT LCD panel
- auo,b116xa01
+# BOE NV140FHM-N49 14.0" FHD a-Si FT panel
+  - boe,nv140fhmn49
  # GiantPlus GPM940B0 3.0" QVGA TFT LCD panel
- giantplus,gpm940b0
  # Sharp LS020B1DD01D 2.0" HQVGA TFT LCD panel


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

Re: [PATCH] drm/i915/dp: Add current maximum eDP link rate to sink_rate array.

[Ville Syrjälä]

On Thu, Jan 09, 2020 at 04:07:52PM +0100, Mario Kleiner wrote:
> If the current eDP link rate, as read from hw, provides a
> higher bandwidth than the standard link rates, then add the
> current link rate to the link_rates array for consideration
> in future mode-sets.
> 
> These initial current eDP link settings have been set up by
> firmware during boot, so they should work on the eDP panel.
> Therefore use them if the firmware thinks they are good and
> they provide higher link bandwidth, e.g., to enable higher
> resolutions / color depths.
> 
> This fixes a problem found on the MacBookPro 2017 Retina panel:
> 
> The panel reports 10 bpc color depth in its EDID, and the UEFI
> firmware chooses link settings at boot which support enough
> bandwidth for 10 bpc (324000 kbit/sec to be precise), but the
> DP_MAX_LINK_RATE dpcd register only reports 2.7 Gbps as possible,
> so intel_dp_set_sink_rates() would cap at that. This restricts
> achievable color depth to 8 bpc, not providing the full color
> depth of the panel. With this commit, we can use firmware setting
> and get the full 10 bpc advertised by the Retina panel.
> 
> Signed-off-by: Mario Kleiner 
> Cc: Daniel Vetter 
> ---
>  drivers/gpu/drm/i915/display/intel_dp.c | 23 +++
>  1 file changed, 23 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 2f31d226c6eb..aa3e0b5108c6 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -4368,6 +4368,8 @@ intel_edp_init_dpcd(struct intel_dp *intel_dp)
>  {
>   struct drm_i915_private *dev_priv =
>   to_i915(dp_to_dig_port(intel_dp)->base.base.dev);
> + int max_rate;
> + u8 link_bw;
>  
>   /* this function is meant to be called only once */
>   WARN_ON(intel_dp->dpcd[DP_DPCD_REV] != 0);
> @@ -4433,6 +4435,27 @@ intel_edp_init_dpcd(struct intel_dp *intel_dp)
>   else
>   intel_dp_set_sink_rates(intel_dp);
>  
> + /*
> +  * If the firmware programmed a rate higher than the standard sink rates
> +  * during boot, then add that rate as a valid sink rate, as fw knows
> +  * this is a good rate and we get extra bandwidth.
> +  *
> +  * Helps, e.g., on the Apple MacBookPro 2017 Retina panel, which is only
> +  * eDP 1.1, but supports the unusual rate of 324000 kHz at bootup, for
> +  * 10 bpc / 30 bit color depth.
> +  */
> + if (!intel_dp->use_rate_select &&
> + (drm_dp_dpcd_read(_dp->aux, DP_LINK_BW_SET, _bw, 1) == 
> 1) &&
> + (link_bw > 0) && (intel_dp->num_sink_rates < 
> DP_MAX_SUPPORTED_RATES)) {
> + max_rate = drm_dp_bw_code_to_link_rate(link_bw);
> + if (max_rate > intel_dp->sink_rates[intel_dp->num_sink_rates - 
> 1]) {
> + intel_dp->sink_rates[intel_dp->num_sink_rates] = 
> max_rate;
> + intel_dp->num_sink_rates++;
> + DRM_DEBUG_KMS("Adding max bandwidth eDP rate %d kHz.\n",
> +   max_rate);
> + }

Hmm. I guess we could do this. But plese put it into a separate
function so we don't end up with that super ugly if condition.

The debug message should probably be a bit more explicit. Eg. 
something like: 
"Firmware using non-standard link rate %d kHz. Including it in sink rates.\n"

I'm also wondering if we shouldn't just add the link rate to the sink
rates regradless of whether it's the highest rate or not...

> + }
> +
>   intel_dp_set_common_rates(intel_dp);
>  
>   /* Read the eDP DSC DPCD registers */
> -- 
> 2.24.0
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2] drm/dp: Add function to parse EDID descriptors for adaptive sync limits

[Jani Nikula]

On Tue, 07 Jan 2020, Manasi Navare  wrote:
> Adaptive Sync is a VESA feature so add a DRM core helper to parse
> the EDID's detailed descritors to obtain the adaptive sync monitor range.
> Store this info as part fo drm_display_info so it can be used
> across all drivers.
> This part of the code is stripped out of amdgpu's function
> amdgpu_dm_update_freesync_caps() to make it generic and be used
> across all DRM drivers
>
> v2:
> * Change vmin and vmax to use u8 (Ville)
> * Dont store pixel clock since that is just a max dotclock
> and not related to VRR mode (Manasi)
>
> Cc: Ville Syrjälä 
> Cc: Harry Wentland 
> Cc: Clinton A Taylor 
> Cc: Nicholas Kazlauskas 
> Signed-off-by: Manasi Navare 
> ---
>  drivers/gpu/drm/drm_edid.c  | 51 +
>  include/drm/drm_connector.h | 22 
>  include/drm/drm_edid.h  |  2 ++
>  3 files changed, 75 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 99769d6c9f84..52781a0e708b 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -4880,6 +4880,54 @@ static void drm_parse_cea_ext(struct drm_connector 
> *connector,
>   }
>  }
>  
> +void drm_get_adaptive_sync_limits(struct drm_connector *connector,
> +   const struct edid *edid)
> +{
> + struct drm_display_info *info = >display_info;
> + const struct detailed_timing *timing;
> + const struct detailed_non_pixel *data;
> + const struct detailed_data_monitor_range *range;
> + int i;
> +
> + /*
> +  * Restrict Adaptive Sync only for dp and edp
> +  */
> + if (connector->connector_type != DRM_MODE_CONNECTOR_DisplayPort &&
> + connector->connector_type != DRM_MODE_CONNECTOR_eDP)
> + return;
> +
> + if (edid->version <= 1 && !(edid->version == 1 && edid->revision > 1))
> + return;
> +
> + for (i = 0; i < 4; i++) {
> + timing  = >detailed_timings[i];
> + data= >data.other_data;
> + range   = >data.range;
> + /*
> +  * Check if monitor has continuous frequency mode
> +  */
> + if (data->type != EDID_DETAIL_MONITOR_RANGE)
> + continue;
> + /*
> +  * Check for flag range limits only. If flag == 1 then
> +  * no additional timing information provided.
> +  * Default GTF, GTF Secondary curve and CVT are not
> +  * supported
> +  */
> + if (range->flags != 1)
> + continue;
> +
> + info->adaptive_sync.min_vfreq = range->min_vfreq;
> + info->adaptive_sync.max_vfreq = range->max_vfreq;
> +
> + DRM_DEBUG_KMS("Adaptive Sync refresh rate range is %d Hz - %d 
> Hz\n",
> +   info->adaptive_sync.min_vfreq,
> +   info->adaptive_sync.max_vfreq);
> + break;
> + }
> +}
> +EXPORT_SYMBOL(drm_get_adaptive_sync_limits);

Why the export? Rather, why is this not static?

BR,
Jani.

> +
>  /* A connector has no EDID information, so we've got no EDID to compute 
> quirks from. Reset
>   * all of the values which would have been set from EDID
>   */
> @@ -4901,6 +4949,7 @@ drm_reset_display_info(struct drm_connector *connector)
>   memset(>hdmi, 0, sizeof(info->hdmi));
>  
>   info->non_desktop = 0;
> + memset(>adaptive_sync, 0, sizeof(info->adaptive_sync));
>  }
>  
>  u32 drm_add_display_info(struct drm_connector *connector, const struct edid 
> *edid)
> @@ -4916,6 +4965,8 @@ u32 drm_add_display_info(struct drm_connector 
> *connector, const struct edid *edi
>  
>   info->non_desktop = !!(quirks & EDID_QUIRK_NON_DESKTOP);
>  
> + drm_get_adaptive_sync_limits(connector, edid);
> +
>   DRM_DEBUG_KMS("non_desktop set to %d\n", info->non_desktop);
>  
>   if (edid->revision < 3)
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index 221910948b37..77df404a2e01 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -254,6 +254,23 @@ enum drm_panel_orientation {
>   DRM_MODE_PANEL_ORIENTATION_RIGHT_UP,
>  };
>  
> +/**
> + * struct drm_adaptive_sync_info - Panel's Adaptive Sync capabilities for
> + * _display_info
> + *
> + * This struct is used to store a Panel's Adaptive Sync capabilities
> + * as parsed from EDID's detailed monitor range descriptor block.
> + *
> + * @min_vfreq: This is the min supported refresh rate in Hz from
> + * EDID's detailed monitor range.
> + * @max_vfreq: This is the max supported refresh rate in Hz from
> + * EDID's detailed monitor range
> + */
> +struct drm_adaptive_sync_info {
> + u8 min_vfreq;
> + u8 max_vfreq;
> +};
> +
>  /*
>   * This is a consolidated colorimetry list supported by HDMI and
>   * DP protocol standard. The respective connectors will register
> @@ -465,6 

Some eDP fixes/improvements.

[Mario Kleiner]

Hi and happy new year!

Since i now have a MBP 2017 to play with, with a 10 bit Retina panel,
and Polaris gpu, i'm trying to get it to get 10 bits, and found one
small bug [fix: patch1], and a quirk of Apples Retina eDP sink, for
which i propose patch2 as solution. I sent a similar patch to i915 to
make 10 bit Retina work with the Intel Kabylake igp on that machine.

If these make sense, it would be cool to still get them into drm-fixes
for Linux 5.5, so users of spring distro updates like Ubuntu 20.04 LTS
can get a more colorful new year.

thanks,
-mario


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

[PATCH 2/2] drm/amd/display: Allow current eDP link settings to override verified ones.

[Mario Kleiner]

If the current eDP link settings, as read from hw, provide a higher
bandwidth than the verified_link_cap ones (= reported_link_cap), then
override verified_link_cap with current settings.

These initial current eDP link settings have been set up by
firmware during boot, so they should work on the eDP panel.
Therefore use them if the firmware thinks they are good and
they provide higher link bandwidth, e.g., to enable higher
resolutions / color depths.

This fixes a problem found on the MacBookPro 2017 Retina panel:

The panel reports 10 bpc color depth in its EDID, and the
firmware chooses link settings at boot which support enough
bandwidth for 10 bpc (324000 kbit/sec aka LINK_RATE_RBR2),
but the DP_MAX_LINK_RATE dpcd register only reports 2.7 Gbps
as possible, so verified_link_cap is only good for 2.7 Gbps
and 8 bpc, not providing the full color depth of the panel.

Signed-off-by: Mario Kleiner 
Cc: Alex Deucher 
---
 drivers/gpu/drm/amd/display/dc/core/dc_link.c | 21 +++
 1 file changed, 21 insertions(+)

diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link.c 
b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
index 5ea4a1675259..f3acdb8fead5 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
@@ -819,6 +819,27 @@ static bool dc_link_detect_helper(struct dc_link *link,
case SIGNAL_TYPE_EDP: {
detect_edp_sink_caps(link);
read_current_link_settings_on_detect(link);
+
+   /* If cur_link_settings provides higher bandwidth than
+* verified_link_cap, then use cur_link_settings as new
+* verified_link_cap, as it obviously works according to
+* firmware boot setup.
+*
+* This has been observed on the Apple MacBookPro 2017
+* Retina panel, which boots with a link setting higher
+* than what dpcd[DP_MAX_LINK_RATE] claims as possible.
+* Overriding allows to run the panel at 10 bpc / 30 
bit.
+*/
+   if (dc_link_bandwidth_kbps(link, 
>cur_link_settings) >
+   dc_link_bandwidth_kbps(link, 
>verified_link_cap)) {
+   DC_LOG_DETECTION_DP_CAPS(
+   "eDP current link setting bw %d kbps > 
verified_link_cap %d kbps. Override.",
+   dc_link_bandwidth_kbps(link, 
>cur_link_settings),
+   dc_link_bandwidth_kbps(link, 
>verified_link_cap));
+
+   link->verified_link_cap = 
link->cur_link_settings;
+   }
+
sink_caps.transaction_type = 
DDC_TRANSACTION_TYPE_I2C_OVER_AUX;
sink_caps.signal = SIGNAL_TYPE_EDP;
break;
-- 
2.24.0

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

[PATCH 1/2] drm/amd/display: Reorder detect_edp_sink_caps before link settings read.

[Mario Kleiner]

read_current_link_settings_on_detect() on eDP 1.4+ may use the
edp_supported_link_rates table which is set up by
detect_edp_sink_caps(), so that function needs to be called first.

Signed-off-by: Mario Kleiner 
Cc: Martin Leung 
---
 drivers/gpu/drm/amd/display/dc/core/dc_link.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link.c 
b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
index cef8c1ba9797..5ea4a1675259 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
@@ -817,8 +817,8 @@ static bool dc_link_detect_helper(struct dc_link *link,
}
 
case SIGNAL_TYPE_EDP: {
-   read_current_link_settings_on_detect(link);
detect_edp_sink_caps(link);
+   read_current_link_settings_on_detect(link);
sink_caps.transaction_type = 
DDC_TRANSACTION_TYPE_I2C_OVER_AUX;
sink_caps.signal = SIGNAL_TYPE_EDP;
break;
-- 
2.24.0

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

Re: [PATCH] xf86drm: only include for FreeBSD build case

[Jani Nikula]

On Thu, 09 Jan 2020, Seung-Woo Kim  wrote:
> The  header is only required FreeBSD and GNU libc
> 2.30 starts to warn about Linux specific  header
> deprecation. Only include  for FreeBSD.
>
> Signed-off-by: Seung-Woo Kim 
> ---
>  xf86drmMode.c |2 ++
>  1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/xf86drmMode.c b/xf86drmMode.c
> index 207d7be..ff1d31d 100644
> --- a/xf86drmMode.c
> +++ b/xf86drmMode.c
> @@ -42,9 +42,11 @@
>  #include 
>  #include 
>  #include 
> +#if defined (__FreeBSD__) || defined (__FreeBSD_kernel__)
>  #ifdef HAVE_SYS_SYSCTL_H

Not that I know anything about this, but shouldn't you instead fix
HAVE_SYS_SYSCTL_H definition in configure stage to only be enabled on
FreeBSD?

BR,
Jani.

>  #include 
>  #endif
> +#endif /* defined (__FreeBSD__) || defined (__FreeBSD_kernel__) */
>  #include 
>  #include 

-- 
Jani Nikula, Intel Open Source Graphics Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Regression in 5.4 kernel on 32-bit Radeon IBM T40

[Christian König]

Hi Christoph,

Am 09.01.20 um 15:14 schrieb Christoph Hellwig:

Hi Woody,

sorry for the late reply, I've been off to a vacation over the holidays.

On Sat, Dec 14, 2019 at 10:17:15PM -0500, Woody Suwalski wrote:

Regression in 5.4 kernel on 32-bit Radeon IBM T40
triggered by
commit 33b3ad3788aba846fc8b9a065fe2685a0b64f713
Author: Christoph Hellwig 
Date:   Thu Aug 15 09:27:00 2019 +0200

Howdy,
The above patch has triggered a display problem on IBM Thinkpad T40, where
the screen is covered with a lots of random short black horizontal lines,
or distorted letters in X terms.

The culprit seems to be that the dma_get_required_mask() is returning a
value 0x3fff
which is smaller than dma_get_mask()0x.That results in
dma_addressing_limited()==0 in ttm_bo_device(), and using 40-bits dma
instead of 32-bits.

Which is the intended behavior assuming your system has 1GB of memory.
Does it?


Assuming the system doesn't have the 1GB split up somehow crazy over the 
address space that should indeed work as intended.





If I hardcode "1" as the last parameter to ttm_bo_device_init() in place of
a call to dma_addressing_limited(),the problem goes away.

I'll need some help from the drm / radeon / TTM maintainers if there are
any other side effects from not passing the need_dma32 paramters.
Obviously if the device doesn't have more than 32-bits worth of dram and
no DMA offset we can't feed unaddressable memory to the device.
Unfortunately I have a very hard time following the implementation of
the TTM pool if it does anything else in this case.


The only other thing which comes to mind is using huge pages. Can you 
try a kernel with CONFIG_TRANSPARENT_HUGEPAGE disabled?


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

[PATCH] drm/i915/dp: Add current maximum eDP link rate to sink_rate array.

[Mario Kleiner]

If the current eDP link rate, as read from hw, provides a
higher bandwidth than the standard link rates, then add the
current link rate to the link_rates array for consideration
in future mode-sets.

These initial current eDP link settings have been set up by
firmware during boot, so they should work on the eDP panel.
Therefore use them if the firmware thinks they are good and
they provide higher link bandwidth, e.g., to enable higher
resolutions / color depths.

This fixes a problem found on the MacBookPro 2017 Retina panel:

The panel reports 10 bpc color depth in its EDID, and the UEFI
firmware chooses link settings at boot which support enough
bandwidth for 10 bpc (324000 kbit/sec to be precise), but the
DP_MAX_LINK_RATE dpcd register only reports 2.7 Gbps as possible,
so intel_dp_set_sink_rates() would cap at that. This restricts
achievable color depth to 8 bpc, not providing the full color
depth of the panel. With this commit, we can use firmware setting
and get the full 10 bpc advertised by the Retina panel.

Signed-off-by: Mario Kleiner 
Cc: Daniel Vetter 
---
 drivers/gpu/drm/i915/display/intel_dp.c | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 2f31d226c6eb..aa3e0b5108c6 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -4368,6 +4368,8 @@ intel_edp_init_dpcd(struct intel_dp *intel_dp)
 {
struct drm_i915_private *dev_priv =
to_i915(dp_to_dig_port(intel_dp)->base.base.dev);
+   int max_rate;
+   u8 link_bw;
 
/* this function is meant to be called only once */
WARN_ON(intel_dp->dpcd[DP_DPCD_REV] != 0);
@@ -4433,6 +4435,27 @@ intel_edp_init_dpcd(struct intel_dp *intel_dp)
else
intel_dp_set_sink_rates(intel_dp);
 
+   /*
+* If the firmware programmed a rate higher than the standard sink rates
+* during boot, then add that rate as a valid sink rate, as fw knows
+* this is a good rate and we get extra bandwidth.
+*
+* Helps, e.g., on the Apple MacBookPro 2017 Retina panel, which is only
+* eDP 1.1, but supports the unusual rate of 324000 kHz at bootup, for
+* 10 bpc / 30 bit color depth.
+*/
+   if (!intel_dp->use_rate_select &&
+   (drm_dp_dpcd_read(_dp->aux, DP_LINK_BW_SET, _bw, 1) == 
1) &&
+   (link_bw > 0) && (intel_dp->num_sink_rates < 
DP_MAX_SUPPORTED_RATES)) {
+   max_rate = drm_dp_bw_code_to_link_rate(link_bw);
+   if (max_rate > intel_dp->sink_rates[intel_dp->num_sink_rates - 
1]) {
+   intel_dp->sink_rates[intel_dp->num_sink_rates] = 
max_rate;
+   intel_dp->num_sink_rates++;
+   DRM_DEBUG_KMS("Adding max bandwidth eDP rate %d kHz.\n",
+ max_rate);
+   }
+   }
+
intel_dp_set_common_rates(intel_dp);
 
/* Read the eDP DSC DPCD registers */
-- 
2.24.0

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

Re: [PATCH v8] drm/panel: Add driver for Sony ACX424AKP panel

[Sam Ravnborg]

Hi Linus.

On Thu, Jan 09, 2020 at 08:28:15AM +0100, Linus Walleij wrote:
> The Sony ACX424AKP is a command/videomode DSI panel for
> mobile devices. It is used on the ST-Ericsson HREF520
> reference design. We support video mode by default, but
> it is possible to switch the panel into command mode
> by using the bool property "dsi-command-mode".
> 
> Cc: Stephan Gerhold 
> Signed-off-by: Linus Walleij 

Applied to drm-misc-next.

Thanks,
Sam


> ---
> ChangeLog v7->v8:
> - Fix some compilation problems due to the connector refactoring
>   that went in recently so all builds fine now.
> - Add a MAINTAINERS entry for the driver.
> - Convert some msleep() to usleep_range(): it's fine to sleep some
>   more so make this explicit.
> ChangeLog v6->v7:
> - Add some Kconfig help text.
> - Sort includes alphabetically.
> - Move the struct drm_panel first in the state container
>   struct since we are subclassing the panel class.
> - Put an explicit /* sentinel */ text in the NULL entry
>   for compatible.
> - Move MTP ID readout to the .prepare() callback.
> - Add a verbose comment about the MDDI setting so others
>   understand what may be going on.
> - Explain why the backlight follows the display and cannot
>   be turned on/off
> ChangeLog v5->v6:
> - Move the "set MDDI" command back to this file. It is a
>   local pecularity, we suspect there is a Novatek controller
>   inside this display.
> ChangeLog v4->v5:
> - Bindings were iterated separately so a jump in versioning.
> - Add Stephan as reviewer.
> ChangeLog v3->v4:
> - No changes just resending with the new binding updates.
> ChangeLog v2->v3:
> - No changes just resending with the new binding updates.
> ChangeLog v1->v2:
> - Fix up the ID read function to split into reading header,
>   version and ID, store the version in the struct.
> - Get rid of a surplus semicolon found by the build robot
>   while rewriting the above code.
> - Use unsigned int in probe() loop.
> - Set vrefresh to 60Hz, as good as any, the measured vrefresh
>   in continous command mode is ~117 Hz.
> - Use a different for() idiom while retrying to read ID
>   5 times.
> - Drop the sync pulse setting, we are not using this, this
>   panel uses an event.
> - Use the generic "enforce-video-mode" for video mode
>   enforcement.
> ---
>  MAINTAINERS  |   6 +
>  drivers/gpu/drm/panel/Kconfig|  11 +
>  drivers/gpu/drm/panel/Makefile   |   1 +
>  drivers/gpu/drm/panel/panel-sony-acx424akp.c | 550 +++
>  4 files changed, 568 insertions(+)
>  create mode 100644 drivers/gpu/drm/panel/panel-sony-acx424akp.c
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 4118dfe61867..3d5cbbaee117 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -5368,6 +5368,12 @@ S: Maintained
>  F:   drivers/gpu/drm/tiny/st7735r.c
>  F:   Documentation/devicetree/bindings/display/sitronix,st7735r.txt
>  
> +DRM DRIVER FOR SONY ACX424AKP PANELS
> +M:   Linus Walleij 
> +T:   git git://anongit.freedesktop.org/drm/drm-misc
> +S:   Maintained
> +F:   drivers/gpu/drm/panel/panel-sony-acx424akp.c
> +
>  DRM DRIVER FOR ST-ERICSSON MCDE
>  M:   Linus Walleij 
>  T:   git git://anongit.freedesktop.org/drm/drm-misc
> diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
> index 41f796b28dd5..ae44ac2ec106 100644
> --- a/drivers/gpu/drm/panel/Kconfig
> +++ b/drivers/gpu/drm/panel/Kconfig
> @@ -338,6 +338,17 @@ config DRM_PANEL_SITRONIX_ST7789V
> Say Y here if you want to enable support for the Sitronix
> ST7789V controller for 240x320 LCD panels
>  
> +config DRM_PANEL_SONY_ACX424AKP
> + tristate "Sony ACX424AKP DSI command mode panel"
> + depends on OF
> + depends on DRM_MIPI_DSI
> + depends on BACKLIGHT_CLASS_DEVICE
> + select VIDEOMODE_HELPERS
> + help
> +   Say Y here if you want to enable the Sony ACX424 display
> +   panel. This panel supports DSI in both command and video
> +   mode.
> +
>  config DRM_PANEL_SONY_ACX565AKM
>   tristate "Sony ACX565AKM panel"
>   depends on GPIOLIB && OF && SPI
> diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
> index 4dc7acff21b9..7c4d3c581fd4 100644
> --- a/drivers/gpu/drm/panel/Makefile
> +++ b/drivers/gpu/drm/panel/Makefile
> @@ -35,6 +35,7 @@ obj-$(CONFIG_DRM_PANEL_SHARP_LS037V7DW01) += 
> panel-sharp-ls037v7dw01.o
>  obj-$(CONFIG_DRM_PANEL_SHARP_LS043T1LE01) += panel-sharp-ls043t1le01.o
>  obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7701) += panel-sitronix-st7701.o
>  obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7789V) += panel-sitronix-st7789v.o
> +obj-$(CONFIG_DRM_PANEL_SONY_ACX424AKP) += panel-sony-acx424akp.o
>  obj-$(CONFIG_DRM_PANEL_SONY_ACX565AKM) += panel-sony-acx565akm.o
>  obj-$(CONFIG_DRM_PANEL_TPO_TD028TTEC1) += panel-tpo-td028ttec1.o
>  obj-$(CONFIG_DRM_PANEL_TPO_TD043MTEA1) += panel-tpo-td043mtea1.o
> diff --git a/drivers/gpu/drm/panel/panel-sony-acx424akp.c 
> 

Re: [PATCH v2 4/7] drm/panfrost: Add support for a second regulator for the GPU

[Steven Price]

On 08/01/2020 22:52, Nicolas Boichat wrote:

On Wed, Jan 8, 2020 at 9:23 PM Mark Brown  wrote:


On Wed, Jan 08, 2020 at 01:23:34PM +0800, Nicolas Boichat wrote:


Some GPUs, namely, the bifrost/g72 part on MT8183, have a second
regulator for their SRAM, let's add support for that.



+ pfdev->regulator_sram = devm_regulator_get_optional(pfdev->dev, "sram");
+ if (IS_ERR(pfdev->regulator_sram)) {


This supply is required for the devices that need it so I'd therefore
expect the driver to request the supply non-optionally based on the
compatible string rather than just hoping that a missing regulator isn't
important.


That'd be a bit awkward to match, though... Currently all bifrost
share the same compatible "arm,mali-bifrost", and it'd seem
weird/wrong to match "mediatek,mt8183-mali" in this driver? I have no
idea if any other Mali implementation will require a second regulator,
but with the MT8183 we do need it, see below.


Though I do have to wonder given the lack of any active
management of the supply if this is *really* part of the GPU or if it's
more of a SoC thing, it's not clear what exactly adding this code is
achieving.


Well if devfreq was working (see patch 7
https://patchwork.kernel.org/patch/11322851/ for a partial
implementation), it would adjust both mali and sram regulators, see
the OPP table in patch 2
(https://patchwork.kernel.org/patch/11322825/): SRAM voltage needs to
be increased for frequencies >=698Mhz.

Now if you have some better idea how to implement this, I'm all ears!


I'm not sure if it's better, but could we just encode the list of regulators into device 
tree. I'm a bit worried about special casing an "sram" regulator given that 
other platforms might have a similar situation but call the second regulator a different 
name.

Steve


Thanks.
___
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 v2 6/7, RFC] drm/panfrost: Add bifrost compatible string

[Steven Price]

On 08/01/2020 05:23, Nicolas Boichat wrote:

For testing only, the driver doesn't really work yet, AFAICT.

Signed-off-by: Nicolas Boichat 


It does work (at least on the Hikey960), we just don't have any public user 
space driver for it... ;)

Reviewed-by: Steven Price 


---
  drivers/gpu/drm/panfrost/panfrost_drv.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c 
b/drivers/gpu/drm/panfrost/panfrost_drv.c
index 48e3c4165247cea..f3a4d77266ba961 100644
--- a/drivers/gpu/drm/panfrost/panfrost_drv.c
+++ b/drivers/gpu/drm/panfrost/panfrost_drv.c
@@ -591,6 +591,7 @@ static const struct of_device_id dt_match[] = {
{ .compatible = "arm,mali-t830" },
{ .compatible = "arm,mali-t860" },
{ .compatible = "arm,mali-t880" },
+   { .compatible = "arm,mali-bifrost" },
{}
  };
  MODULE_DEVICE_TABLE(of, dt_match);



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

Re: [PATCH v2 5/7] drm/panfrost: Add support for multiple power domain support

[Steven Price]

On 08/01/2020 05:23, Nicolas Boichat wrote:

When there is a single power domain per device, the core will
ensure the power domains are all switched on.

However, when there are multiple ones, as in MT8183 Bifrost GPU,
we need to handle them in driver code.


Signed-off-by: Nicolas Boichat 
---

The downstream driver we use on chromeos-4.19 currently uses 2
additional devices in device tree to accomodate for this [1], but
I believe this solution is cleaner.


I'm not sure what is best, but it seems odd to encode this into the Panfrost 
driver itself - it doesn't have any knowledge of what to do with these power 
domains. The naming of the domains looks suspiciously like someone thought that 
e.g. only half of the cores could be powered, but it doesn't look like that was 
implemented in the chromeos driver linked and anyway that is *meant* to be 
automatic in the hardware! (I.e. if you only power up one cores in one core 
stack then the PDC should only enable the power domain for that set of cores).

Steve



[1] 
https://chromium.googlesource.com/chromiumos/third_party/kernel/+/refs/heads/chromeos-4.19/drivers/gpu/arm/midgard/platform/mediatek/mali_kbase_runtime_pm.c#31

drivers/gpu/drm/panfrost/panfrost_device.c | 87 --
  drivers/gpu/drm/panfrost/panfrost_device.h |  4 +
  2 files changed, 83 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/panfrost/panfrost_device.c 
b/drivers/gpu/drm/panfrost/panfrost_device.c
index a0b0a6fef8b4e63..c6e9e059de94a4d 100644
--- a/drivers/gpu/drm/panfrost/panfrost_device.c
+++ b/drivers/gpu/drm/panfrost/panfrost_device.c
@@ -5,6 +5,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  
  #include "panfrost_device.h"

@@ -131,6 +132,67 @@ static void panfrost_regulator_fini(struct panfrost_device 
*pfdev)
regulator_disable(pfdev->regulator_sram);
  }
  
+static void panfrost_pm_domain_fini(struct panfrost_device *pfdev)

+{
+   int i;
+
+   for (i = 0; i < ARRAY_SIZE(pfdev->pm_domain_devs); i++) {
+   if (!pfdev->pm_domain_devs[i])
+   break;
+
+   if (pfdev->pm_domain_links[i])
+   device_link_del(pfdev->pm_domain_links[i]);
+
+   dev_pm_domain_detach(pfdev->pm_domain_devs[i], true);
+   }
+}
+
+static int panfrost_pm_domain_init(struct panfrost_device *pfdev)
+{
+   int err;
+   int i, num_domains;
+
+   num_domains = of_count_phandle_with_args(pfdev->dev->of_node,
+"power-domains",
+"#power-domain-cells");
+   /* Single domains are handled by the core. */
+   if (num_domains < 2)
+   return 0;
+
+   if (num_domains > ARRAY_SIZE(pfdev->pm_domain_devs)) {
+   dev_err(pfdev->dev, "Too many pm-domains: %d\n", num_domains);
+   return -EINVAL;
+   }
+
+   for (i = 0; i < num_domains; i++) {
+   pfdev->pm_domain_devs[i] =
+   dev_pm_domain_attach_by_id(pfdev->dev, i);
+   if (IS_ERR(pfdev->pm_domain_devs[i])) {
+   err = PTR_ERR(pfdev->pm_domain_devs[i]);
+   pfdev->pm_domain_devs[i] = NULL;
+   dev_err(pfdev->dev,
+   "failed to get pm-domain %d: %d\n", i, err);
+   goto err;
+   }
+
+   pfdev->pm_domain_links[i] = device_link_add(pfdev->dev,
+   pfdev->pm_domain_devs[i], DL_FLAG_PM_RUNTIME |
+   DL_FLAG_STATELESS | DL_FLAG_RPM_ACTIVE);
+   if (!pfdev->pm_domain_links[i]) {
+   dev_err(pfdev->pm_domain_devs[i],
+   "adding device link failed!\n");
+   err = -ENODEV;
+   goto err;
+   }
+   }
+
+   return 0;
+
+err:
+   panfrost_pm_domain_fini(pfdev);
+   return err;
+}
+
  int panfrost_device_init(struct panfrost_device *pfdev)
  {
int err;
@@ -161,37 +223,45 @@ int panfrost_device_init(struct panfrost_device *pfdev)
goto err_out1;
}
  
+	err = panfrost_pm_domain_init(pfdev);

+   if (err) {
+   dev_err(pfdev->dev, "pm_domain init failed %d\n", err);
+   goto err_out2;
+   }
+
res = platform_get_resource(pfdev->pdev, IORESOURCE_MEM, 0);
pfdev->iomem = devm_ioremap_resource(pfdev->dev, res);
if (IS_ERR(pfdev->iomem)) {
dev_err(pfdev->dev, "failed to ioremap iomem\n");
err = PTR_ERR(pfdev->iomem);
-   goto err_out2;
+   goto err_out3;
}
  
  	err = panfrost_gpu_init(pfdev);

if (err)
-   goto err_out2;
+   goto err_out3;
  
  	err = panfrost_mmu_init(pfdev);

if (err)
-   goto err_out3;
+   goto err_out4;
  
  	

Re: [RESEND 0/1] Add support for BOE NV140FHM-N49 panel to panel-simple

[Sam Ravnborg]

Hi Tobias.

We need binding schema before we can apply this patch.
See patch below.
Please review/ack the patch, then we can process your panel-simple
patch.

Sam

On Thu, Jan 09, 2020 at 12:29:51PM +0100, Tobias Schramm wrote:
> This patch adds support for the 14 inch BOE NV140FHM-N49 eDP panel to
> the panel-simple driver. The panel is used by the Pinebook Pro.
> 
> Resending with changed CCs due to lack of feedback.


> 
> Tobias Schramm (1):
>   drm/panel: Add support for BOE NV140FHM-N49 panel to panel-simple
> 
>  drivers/gpu/drm/panel/panel-simple.c | 35 
>  1 file changed, 35 insertions(+)
> 
>From ad19c4636475bb05ba5c0b6cec2bee85045d628e Mon Sep 17 00:00:00 2001
From: Sam Ravnborg 
Date: Thu, 9 Jan 2020 14:48:41 +0100
Subject: [PATCH] dt-bindings: display: add BOE 14" panel

Add bindings for the BOE NV140FHM-N49 14" 1920x1080 panel.

The panel is used by the pine64 Pinebook Pro.

Signed-off-by: Sam Ravnborg 
Cc: Thierry Reding 
Cc: Tobias Schramm 
---
 .../devicetree/bindings/display/panel/panel-simple.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml 
b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
index ddc00480b6fe..6c098a0b6e1e 100644
--- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
+++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
@@ -35,6 +35,8 @@ properties:
   - ampire,am800480r3tmqwa1h
 # AUO B116XAK01 eDP TFT LCD panel
   - auo,b116xa01
+# BOE NV140FHM-N49 14.0" FHD a-Si FT panel
+  - boe,nv140fhmn49
 # GiantPlus GPM940B0 3.0" QVGA TFT LCD panel
   - giantplus,gpm940b0
 # Sharp LS020B1DD01D 2.0" HQVGA TFT LCD panel
-- 
2.20.1

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

Re: [PATCH] drm/dp_mst: fix documentation of drm_dp_mst_add_affected_dsc_crtcs

[Mikita Lipski]

Thank you,
Reviewed-by: Mikita Lipski 

On 1/8/20 10:24 PM, Alex Deucher wrote:

the parameter is the mst manager, not the port.

Signed-off-by: Alex Deucher 
---
  drivers/gpu/drm/drm_dp_mst_topology.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 7e9b9b7e50cf..a4be2f825899 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -4781,7 +4781,7 @@ drm_dp_mst_atomic_check_vcpi_alloc_limit(struct 
drm_dp_mst_topology_mgr *mgr,
  /**
   * drm_dp_mst_add_affected_dsc_crtcs
   * @state: Pointer to the new struct drm_dp_mst_topology_state
- * @port: Port pointer of connector with new state
+ * @mgr: MST topology manager
   *
   * Whenever there is a change in mst topology
   * DSC configuration would have to be recalculated



--
Thanks,
Mikita Lipski
Software Engineer, AMD
mikita.lip...@amd.com
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PULL] drm-intel-fixes

[Joonas Lahtinen]

Quoting Joonas Lahtinen (2020-01-09 15:34:58)
> Hi Dave & Daniel,
> 
> Happy New Year, now back from the holiday break.
> 
> A bunch of important fixes. Further fixes for the power/perf
> regressions caused by the past security fixes. Then fix for
> user reported GPU hang regression. Revert to avoid screen flicker
> caused by HDA audio. Then missing two W/A and uninitialized uAPI
> variable fix.

Forgot to mention:

Fix for GitLab issue #5: Avoid multiple WARN_ON on 2p2c display teardown

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

[PULL] drm-intel-fixes

[Joonas Lahtinen]

Hi Dave & Daniel,

Happy New Year, now back from the holiday break.

A bunch of important fixes. Further fixes for the power/perf
regressions caused by the past security fixes. Then fix for
user reported GPU hang regression. Revert to avoid screen flicker
caused by HDA audio. Then missing two W/A and uninitialized uAPI
variable fix.

There's one further fix which I didn't include in this PR as the
CI results won't make it in time. So at least that will be in next
weeks PR.

Regards, Joonas

***

drm-intel-fixes-2020-01-09-1:

- Fix GitLab issue #446 causing GPU hangs: Do not restore invalid RS state
- Fix GitLab issue #846: Restore coarse power gating that was disabled
  by initial RC66 context corruption security fixes.
- Revert f6ec9483091f ("drm/i915: extend audio CDCLK>=2*BCLK constraint to more 
platforms")
  to avoid screen flicker
- Fix to fill in unitialized uabi_instance in virtual engine uAPI
- Add two missing W/As for ICL and EHL

The following changes since commit c79f46a282390e0f5b306007bf7b11a46d529538:

  Linux 5.5-rc5 (2020-01-05 14:23:27 -0800)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2020-01-09-1

for you to fetch changes up to 2b2c4a83d69dc9f2b46b8e791f5b8c2451c267bd:

  drm/i915/dp: Disable Port sync mode correctly on teardown (2020-01-07 
15:11:40 +0200)


- Fix GitLab issue #446 causing GPU hangs: Do not restore invalid RS state
- Fix GitLab issue #846: Restore coarse power gating that was disabled
  by initial RC66 context corruption security fixes.
- Revert f6ec9483091f ("drm/i915: extend audio CDCLK>=2*BCLK constraint to more 
platforms")
  to avoid screen flicker
- Fix to fill in unitialized uabi_instance in virtual engine uAPI
- Add two missing W/As for ICL and EHL


Chris Wilson (3):
  drm/i915/gt: Mark up virtual engine uabi_instance
  drm/i915/gt: Do not restore invalid RS state
  drm/i915/gt: Restore coarse power gating

Kai Vehmanen (1):
  drm/i915: Limit audio CDCLK>=2*BCLK constraint back to GLK only

Manasi Navare (1):
  drm/i915/dp: Disable Port sync mode correctly on teardown

Matt Roper (2):
  drm/i915: Add Wa_1408615072 and Wa_1407596294 to icl,ehl
  drm/i915: Add Wa_1407352427:icl,ehl

 drivers/gpu/drm/i915/display/intel_audio.c  |  4 ++--
 drivers/gpu/drm/i915/display/intel_display.c|  7 +-
 drivers/gpu/drm/i915/gt/intel_lrc.c |  2 ++
 drivers/gpu/drm/i915/gt/intel_ring_submission.c | 31 +
 drivers/gpu/drm/i915/i915_drv.h |  6 +++--
 drivers/gpu/drm/i915/i915_reg.h |  8 ++-
 drivers/gpu/drm/i915/intel_pm.c | 11 +
 7 files changed, 38 insertions(+), 31 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/panfrost: Remove core stack power management

[Steven Price]

Explict management of the GPU's core stacks is only necessary in the
case of a broken integration with the PDC. Since there are no known
platforms which have such a broken integration let's remove the explict
control from the driver since this apparently causes problems on other
platforms and will have a small performance penality.

The out of tree mali_kbase driver contains this text regarding
controlling the core stack (CONFIGMALI_CORESTACK):

  Enabling this feature on supported GPUs will let the driver powering
  on/off the GPU core stack independently without involving the Power
  Domain Controller. This should only be enabled on platforms which
  integration of the PDC to the Mali GPU is known to be problematic.
  This feature is currently only supported on t-Six and t-HEx GPUs.

  If unsure, say N.

Signed-off-by: Steven Price 
---
 drivers/gpu/drm/panfrost/panfrost_gpu.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/drivers/gpu/drm/panfrost/panfrost_gpu.c 
b/drivers/gpu/drm/panfrost/panfrost_gpu.c
index 8822ec13a0d6..460fc190de6e 100644
--- a/drivers/gpu/drm/panfrost/panfrost_gpu.c
+++ b/drivers/gpu/drm/panfrost/panfrost_gpu.c
@@ -309,10 +309,6 @@ void panfrost_gpu_power_on(struct panfrost_device *pfdev)
ret = readl_relaxed_poll_timeout(pfdev->iomem + L2_READY_LO,
val, val == pfdev->features.l2_present, 100, 1000);
 
-   gpu_write(pfdev, STACK_PWRON_LO, pfdev->features.stack_present);
-   ret |= readl_relaxed_poll_timeout(pfdev->iomem + STACK_READY_LO,
-   val, val == pfdev->features.stack_present, 100, 1000);
-
gpu_write(pfdev, SHADER_PWRON_LO, pfdev->features.shader_present);
ret |= readl_relaxed_poll_timeout(pfdev->iomem + SHADER_READY_LO,
val, val == pfdev->features.shader_present, 100, 1000);
@@ -329,7 +325,6 @@ void panfrost_gpu_power_off(struct panfrost_device *pfdev)
 {
gpu_write(pfdev, TILER_PWROFF_LO, 0);
gpu_write(pfdev, SHADER_PWROFF_LO, 0);
-   gpu_write(pfdev, STACK_PWROFF_LO, 0);
gpu_write(pfdev, L2_PWROFF_LO, 0);
 }
 
-- 
2.20.1

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

Re: [PATCH v2 0/7] Add dts for mt8183 GPU (and misc panfrost patches)

[Steven Price]

On Thu, Jan 09, 2020 at 01:10:33PM +, Robin Murphy wrote:
> On 09/01/2020 12:01 pm, Steven Price wrote:
> > On 08/01/2020 05:23, Nicolas Boichat wrote:
> >> Hi!
> >>
> >> Sorry for the long delay since 
> >> https://patchwork.kernel.org/patch/11132381/,
> >> finally got around to give this a real try.
> >>
> >> The main purpose of this series is to upstream the dts change and the 
> >> binding
> >> document, but I wanted to see how far I could probe the GPU, to check 
> >> that the
> >> binding is indeed correct. The rest of the patches are 
> >> RFC/work-in-progress, but
> >> I think some of them could already be picked up.
> >>
> >> So this is tested on MT8183 with a chromeos-4.19 kernel, and a ton of
> >> backports to get the latest panfrost driver (I should probably try on
> >> linux-next at some point but this was the path of least resistance).
> >>
> >> I tested it as a module as it's more challenging (originally probing 
> >> would
> >> work built-in, on boot, but not as a module, as I didn't have the power
> >> domain changes, and all power domains are on by default during boot).
> >>
> >> Probing logs looks like this, currently:
> >> [  221.867726] panfrost 1304.gpu: clock rate = 51170
> >> [  221.867929] panfrost 1304.gpu: Linked as a consumer to 
> >> regulator.14
> >> [  221.868600] panfrost 1304.gpu: Linked as a consumer to 
> >> regulator.31
> >> [  221.870586] panfrost 1304.gpu: Linked as a consumer to 
> >> genpd:0:1304.gpu
> >> [  221.871492] panfrost 1304.gpu: Linked as a consumer to 
> >> genpd:1:1304.gpu
> >> [  221.871866] panfrost 1304.gpu: Linked as a consumer to 
> >> genpd:2:1304.gpu
> >> [  221.872427] panfrost 1304.gpu: mali-g72 id 0x6221 major 0x0 
> >> minor 0x3 status 0x0
> >> [  221.872439] panfrost 1304.gpu: features: ,13de77ff, 
> >> issues: ,0400
> >> [  221.872445] panfrost 1304.gpu: Features: L2:0x07120206 
> >> Shader:0x Tiler:0x0809 Mem:0x1 MMU:0x2830 AS:0xff JS:0x7
> >> [  221.872449] panfrost 1304.gpu: shader_present=0x7 l2_present=0x1
> >> [  221.873526] panfrost 1304.gpu: error powering up gpu stack
> >> [  221.878088] [drm] Initialized panfrost 1.1.0 20180908 for 
> >> 1304.gpu on minor 2
> >> [  221.940817] panfrost 1304.gpu: error powering up gpu stack
> >> [  222.018233] panfrost 1304.gpu: error powering up gpu stack
> >> (repeated)
> > 
> > It's interesting that it's only the stack that is failing. In hardware 
> > there's a dependency: L2->stack->shader - so in theory the shader cores 
> > shouldn't be able to power up either. There are some known hardware bugs 
> > here though[1]:
> > 
> >  MODULE_PARM_DESC(corestack_driver_control,
> >      "Let the driver power on/off the GPU core stack 
> > independently "
> >      "without involving the Power Domain Controller. This should "
> >      "only be enabled on platforms for which integration of the 
> > PDC "
> >      "to the Mali GPU is known to be problematic.");
> > 
> > [1] 
> > https://github.com/ianmacd/d2s/blob/master/drivers/gpu/arm/b_r16p0/backend/gpu/mali_kbase_pm_driver.c#L57
> >  
> > 
> > 
> > It might be worth just dropping the code for powering up/down stacks and 
> > let the GPU's own dependency management handle it.
> 
> FWIW I remember digging into that same message a while back (although 
> I've forgotten which particular GPU I was playing with at the time), and 
> concluded that the STACK_PWRON/STACK_READY registers might just not be 
> implemented on some GPUs,

They are indeed not implemented on some GPUs. Specifically none of the
Midgard GPUs. I believe G71 also doesn't have it. However the register
addresses were picked so that on these older GPUs they should
read-as-zero and write-ignore so this shouldn't actually cause any
problems.

> and/or this easy-to-overlook register bit 
> could be some kind of enable for the functionality:
> 
> https://github.com/ianmacd/d2s/blob/master/drivers/gpu/arm/b_r16p0/backend/gpu/mali_kbase_pm_driver.c#L1631
> 
> Since even in kbase this is all behind an 'expert' config option, I'm 
> inclined to agree that just dropping it from panfrost unless and until 
> it proves necessary is probably preferable to adding more logic and 
> inscrutable register-magic.

Indeed - I'll post a patch removing it.

Thanks,

Steve

> Robin.
> 
> > 
> > Steve
> > 
> >>
> >> So the GPU is probed, but there's an issue when powering up the STACK, 
> >> not
> >> quite sure why, I'll try to have a deeper look, at some point.
> >>
> >> Thanks!
> >>
> >> Nicolas
> >>
> >> v2:
> >>   - Use sram instead of mali_sram as SRAM supply name.
> >>   - Rename mali@ to gpu@.
> >>   - Add dt-bindings changes
> >>   - Stacking patches after the device tree change that allow basic
> >>     probing (still incomplete and broken).
> >>
> >> Nicolas Boichat (7):
> >>    dt-bindings: gpu: mali-bifrost: Add Mediatek MT8183
> >>    arm64: dts: mt8183: