[PATCH] drm/komeda: Adds power management support

[Lowry Li (Arm Technology China)]

Adds runtime and system power management support in KMS kernel driver.

Depends on:
- https://patchwork.freedesktop.org/series/61650/
- https://patchwork.freedesktop.org/series/60083/

Signed-off-by: Lowry Li (Arm Technology China) 
---
 drivers/gpu/drm/arm/display/komeda/komeda_crtc.c |  2 +
 drivers/gpu/drm/arm/display/komeda/komeda_dev.c  | 30 +
 drivers/gpu/drm/arm/display/komeda/komeda_dev.h  |  2 +
 drivers/gpu/drm/arm/display/komeda/komeda_drv.c  | 54 ++--
 4 files changed, 85 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c 
b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
index 66c5e0d..1b4ea8a 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
@@ -257,6 +257,7 @@ void komeda_crtc_handle_event(struct komeda_crtc   *kcrtc,
 komeda_crtc_atomic_enable(struct drm_crtc *crtc,
  struct drm_crtc_state *old)
 {
+   pm_runtime_get_sync(crtc->dev->dev);
komeda_crtc_prepare(to_kcrtc(crtc));
drm_crtc_vblank_on(crtc);
komeda_crtc_do_flush(crtc, old);
@@ -330,6 +331,7 @@ void komeda_crtc_handle_event(struct komeda_crtc   *kcrtc,
 
drm_crtc_vblank_off(crtc);
komeda_crtc_unprepare(kcrtc);
+   pm_runtime_put(crtc->dev->dev);
 }
 
 static void
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_dev.c 
b/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
index 405c64d..edd0943 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
@@ -308,3 +308,33 @@ void komeda_dev_destroy(struct komeda_dev *mdev)
 
devm_kfree(dev, mdev);
 }
+
+int komeda_dev_resume(struct komeda_dev *mdev)
+{
+   int ret = 0;
+
+   if (mdev->iommu && mdev->funcs->connect_iommu) {
+   ret = mdev->funcs->connect_iommu(mdev);
+   if (ret < 0) {
+   DRM_ERROR("connect iommu failed.\n");
+   return ret;
+   }
+   }
+
+   return mdev->funcs->enable_irq(mdev);
+}
+
+int komeda_dev_suspend(struct komeda_dev *mdev)
+{
+   int ret = 0;
+
+   if (mdev->iommu && mdev->funcs->disconnect_iommu) {
+   ret = mdev->funcs->disconnect_iommu(mdev);
+   if (ret < 0) {
+   DRM_ERROR("disconnect iommu failed.\n");
+   return ret;
+   }
+   }
+
+   return mdev->funcs->disable_irq(mdev);
+}
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_dev.h 
b/drivers/gpu/drm/arm/display/komeda/komeda_dev.h
index d1c86b6..096f9f7 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_dev.h
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_dev.h
@@ -207,4 +207,6 @@ struct komeda_dev {
 
 struct komeda_dev *dev_to_mdev(struct device *dev);
 
+int komeda_dev_resume(struct komeda_dev *mdev);
+int komeda_dev_suspend(struct komeda_dev *mdev);
 #endif /*_KOMEDA_DEV_H_*/
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_drv.c 
b/drivers/gpu/drm/arm/display/komeda/komeda_drv.c
index cfa5068..aa4cef1 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_drv.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_drv.c
@@ -8,6 +8,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include "komeda_dev.h"
 #include "komeda_kms.h"
@@ -32,6 +33,9 @@ static void komeda_unbind(struct device *dev)
return;
 
komeda_kms_detach(mdrv->kms);
+
+   pm_runtime_disable(dev);
+
komeda_dev_destroy(mdrv->mdev);
 
dev_set_drvdata(dev, NULL);
@@ -52,6 +56,9 @@ static int komeda_bind(struct device *dev)
err = PTR_ERR(mdrv->mdev);
goto free_mdrv;
}
+   dev_set_drvdata(dev, mdrv);
+
+   pm_runtime_enable(dev);
 
mdrv->kms = komeda_kms_attach(mdrv->mdev);
if (IS_ERR(mdrv->kms)) {
@@ -59,11 +66,10 @@ static int komeda_bind(struct device *dev)
goto destroy_mdev;
}
 
-   dev_set_drvdata(dev, mdrv);
-
return 0;
 
 destroy_mdev:
+   pm_runtime_disable(dev);
komeda_dev_destroy(mdrv->mdev);
 
 free_mdrv:
@@ -134,13 +140,55 @@ static int komeda_platform_remove(struct platform_device 
*pdev)
 
 MODULE_DEVICE_TABLE(of, komeda_of_match);
 
+static int komeda_rt_pm_suspend(struct device *dev)
+{
+   dev_info(dev, "%s\n", __func__);
+   return 0;
+}
+
+static int komeda_rt_pm_resume(struct device *dev)
+{
+   dev_info(dev, "%s\n", __func__);
+   return 0;
+}
+
+static int __maybe_unused komeda_pm_suspend(struct device *dev)
+{
+   struct komeda_drv *mdrv = dev_get_drvdata(dev);
+   struct drm_device *drm = >kms->base;
+   int res;
+
+   dev_info(dev, "%s\n", __func__);
+   res = drm_mode_config_helper_suspend(drm);
+
+   komeda_dev_suspend(mdrv->mdev);
+
+   return res;
+}
+
+static int __maybe_unused komeda_pm_resume(struct device *dev)
+{
+   struct 

Re: [EXTERNAL] Re: [PATCH 1/1] drm/bochs: Fix connector leak during driver unload

[Gerd Hoffmann]

On Mon, Jun 17, 2019 at 11:20:34AM +1000, Sam Bobroff wrote:
> On Tue, May 21, 2019 at 10:10:29AM +0200, Gerd Hoffmann wrote:
> >   Hi,
> > 
> > The bug is in the driver, so ...
> > 
> > > Bisecting the issue for commits to drivers/gpu/drm/bochs/ points to:
> > > 6579c39594ae ("drm/bochs: atomic: switch planes to atomic, wire up 
> > > helpers.")
> > > ... but the issue also seems to be due to a change in the generic drm code
> > 
> > ... this one is the culprit and should be listed.
> > 
> > > (reverting it separately fixes the issue):
> > > 846c7dfc1193 ("drm/atomic: Try to preserve the crtc enabled state in 
> > > drm_atomic_remove_fb, v2.")
> > > ... so I've included both in the commit.  Is that the right thing to do?
> > 
> > That only triggers the driver bug.
> > 
> > I'll fix it up on commit,
> >   Gerd
> 
> Sorry if I misunderstood, but were you going to take the patch and fix
> it up or would you like me to post a v2?

Patch is in drm-misc-next, I fixed it on commit.

cheers,
  Gerd

Re: [PATCH 44/59] drm/mediatek: Use drm_atomic_helper_wait_for_fences

[CK Hu]

Hi, Daniel:

On Fri, 2019-06-14 at 22:36 +0200, Daniel Vetter wrote:
> If we use the gem fb helper as the prepare_fb hook, plus the
> drm_prime.c import helpers now automatically setting obj->resv, we can
> use the shared helpers to wait for fences instead of rolling our own.
> Note that this relies on mtk setting drm_fb->obj, which is already
> done in mtk_drm_framebuffer_init().

Reviewed-by: CK Hu 

> 
> Aside: Probably can use the default commit_tail with this again, but I
> didn't check for that.
> 
> Signed-off-by: Daniel Vetter 
> Cc: CK Hu 
> Cc: Philipp Zabel 
> Cc: Matthias Brugger 
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-media...@lists.infradead.org
> ---
>  drivers/gpu/drm/mediatek/mtk_drm_drv.c   | 12 +-
>  drivers/gpu/drm/mediatek/mtk_drm_fb.c| 28 
>  drivers/gpu/drm/mediatek/mtk_drm_fb.h|  1 -
>  drivers/gpu/drm/mediatek/mtk_drm_plane.c |  2 ++
>  4 files changed, 3 insertions(+), 40 deletions(-)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c 
> b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> index dd8dab562500..2d5caf532431 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> @@ -38,22 +38,12 @@ static void mtk_atomic_schedule(struct mtk_drm_private 
> *private,
>   schedule_work(>commit.work);
>  }
>  
> -static void mtk_atomic_wait_for_fences(struct drm_atomic_state *state)
> -{
> - struct drm_plane *plane;
> - struct drm_plane_state *new_plane_state;
> - int i;
> -
> - for_each_new_plane_in_state(state, plane, new_plane_state, i)
> - mtk_fb_wait(new_plane_state->fb);
> -}
> -
>  static void mtk_atomic_complete(struct mtk_drm_private *private,
>   struct drm_atomic_state *state)
>  {
>   struct drm_device *drm = private->drm;
>  
> - mtk_atomic_wait_for_fences(state);
> + drm_atomic_helper_wait_for_fences(drm, state, false);
>  
>   /*
>* Mediatek drm supports runtime PM, so plane registers cannot be
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_fb.c 
> b/drivers/gpu/drm/mediatek/mtk_drm_fb.c
> index 4c3ad7de2d3b..396ba497986d 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_fb.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_fb.c
> @@ -49,34 +49,6 @@ static struct drm_framebuffer 
> *mtk_drm_framebuffer_init(struct drm_device *dev,
>   return fb;
>  }
>  
> -/*
> - * Wait for any exclusive fence in fb's gem object's reservation object.
> - *
> - * Returns -ERESTARTSYS if interrupted, else 0.
> - */
> -int mtk_fb_wait(struct drm_framebuffer *fb)
> -{
> - struct drm_gem_object *gem;
> - struct reservation_object *resv;
> - long ret;
> -
> - if (!fb)
> - return 0;
> -
> - gem = fb->obj[0];
> - if (!gem || !gem->dma_buf || !gem->dma_buf->resv)
> - return 0;
> -
> - resv = gem->dma_buf->resv;
> - ret = reservation_object_wait_timeout_rcu(resv, false, true,
> -   MAX_SCHEDULE_TIMEOUT);
> - /* MAX_SCHEDULE_TIMEOUT on success, -ERESTARTSYS if interrupted */
> - if (WARN_ON(ret < 0))
> - return ret;
> -
> - return 0;
> -}
> -
>  struct drm_framebuffer *mtk_drm_mode_fb_create(struct drm_device *dev,
>  struct drm_file *file,
>  const struct drm_mode_fb_cmd2 
> *cmd)
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_fb.h 
> b/drivers/gpu/drm/mediatek/mtk_drm_fb.h
> index 6b80c28e33cf..eb64d26001c6 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_fb.h
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_fb.h
> @@ -6,7 +6,6 @@
>  #ifndef MTK_DRM_FB_H
>  #define MTK_DRM_FB_H
>  
> -int mtk_fb_wait(struct drm_framebuffer *fb);
>  struct drm_framebuffer *mtk_drm_mode_fb_create(struct drm_device *dev,
>  struct drm_file *file,
>  const struct drm_mode_fb_cmd2 
> *cmd);
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_plane.c 
> b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> index f2ef83aed6f9..42cc9823eaaa 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> @@ -8,6 +8,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include "mtk_drm_crtc.h"
>  #include "mtk_drm_ddp_comp.h"
> @@ -146,6 +147,7 @@ static void mtk_plane_atomic_disable(struct drm_plane 
> *plane,
>  }
>  
>  static const struct drm_plane_helper_funcs mtk_plane_helper_funcs = {
> + .prepare_fb = drm_gem_fb_prepare_fb,
>   .atomic_check = mtk_plane_atomic_check,
>   .atomic_update = mtk_plane_atomic_update,
>   .atomic_disable = mtk_plane_atomic_disable,


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

Re: [RFC PATCH] drm/panfrost: Add support for mapping BOs on GPU page faults

[Tomeu Vizoso]

On Fri, 14 Jun 2019 at 23:22, Rob Herring  wrote:
>
> On Wed, Jun 12, 2019 at 6:55 AM Tomeu Vizoso  wrote:
> >
> > On Mon, 10 Jun 2019 at 19:06, Rob Herring  wrote:
> > >
> > > The midgard/bifrost GPUs need to allocate GPU memory which is allocated
> > > on GPU page faults and not pinned in memory. The vendor driver calls
> > > this functionality GROW_ON_GPF.
> > >
> > > This implementation assumes that BOs allocated with the
> > > PANFROST_BO_NOMAP flag are never mmapped or exported. Both of those may
> > > actually work, but I'm unsure if there's some interaction there. It
> > > would cause the whole object to be pinned in memory which would defeat
> > > the point of this.
> > >
> > > Issues/questions/thoughts:
> > >
> > > What's the difference between i_mapping and f_mapping?
> > >
> > > What kind of clean-up on close is needed? Based on vgem faults, there
> > > doesn't seem to be any refcounting. Assume userspace is responsible for
> > > not freeing the BO while a page fault can occur?
> >
> > Aren't we taking a reference on all BOs that a job relates to and
> > unreferencing them once the job is done? I would think that that's
> > enough, or am I missing something?
>
> No, I think we're fine.
>
> > > What about evictions? Need to call mapping_set_unevictable()? Maybe we
> > > want these pages to be swappable, but then we need some notification to
> > > unmap them.
> >
> > I'm not sure there's much point in swapping out pages with lifetimes
> > of a few milliseconds.
>
> The lifetime is *forever* though. If we don't allow swapping, then the
> heap is grow only until the FD is closed. IIRC, the maximum size is on
> the order of 1GB. Seems like you'd want to shrink it with some
> trigger.

I thought that the lifetime of the *contents* of the heap was that of
the job chain that wrote them? Otherwise, only the GPU would know what
can be discarded.

Cheers,

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

Re: [RFC v2 00/11] DVFS in the OPP core

[Viresh Kumar]

On 20-03-19, 15:19, Rajendra Nayak wrote:
> This is a v2 of the RFC posted earlier by Stephen Boyd [1]
> 
> As part of v2 I still follow the same approach of dev_pm_opp_set_rate()
> API using clk framework to round the frequency passed and making it
> accept 0 as a valid frequency indicating the frequency isn't required
> anymore. It just has a few more drivers converted to use this approach
> like dsi/dpu and ufs.
> ufs demonstrates the case of having to handle multiple power domains, one
> of which is scalable.
> 
> The patches are based on 5.1-rc1 and depend on some ufs fixes I posted
> earlier [2] and a DT patch to include the rpmpd header [3]
> 
> [1] https://lkml.org/lkml/2019/1/28/2086
> [2] https://lkml.org/lkml/2019/3/8/70
> [3] https://lkml.org/lkml/2019/3/20/120
> 
> Rajendra Nayak (10):
>   OPP: Make dev_pm_opp_set_rate() with freq=0 as valid
> 
> Stephen Boyd (1):
>   OPP: Don't overwrite rounded clk rate

I have applied modified version of these two patches to the OPP tree now.
Thanks.

-- 
viresh

Re: [RFC v2 01/11] OPP: Don't overwrite rounded clk rate

[Rajendra Nayak]

On 6/17/2019 9:47 AM, Viresh Kumar wrote:

On 17-06-19, 09:37, Rajendra Nayak wrote:



On 6/17/2019 9:20 AM, Viresh Kumar wrote:

On 14-06-19, 10:57, Viresh Kumar wrote:

Hmm, so this patch won't break anything and I am inclined to apply it again :)

Does anyone see any other issues with it, which I might be missing ?


I have updated the commit log a bit more to clarify on things, please let me
know if it looks okay.

  opp: Don't overwrite rounded clk rate
  The OPP table normally contains 'fmax' values corresponding to the
  voltage or performance levels of each OPP, but we don't necessarily want
  all the devices to run at fmax all the time. Running at fmax makes sense
  for devices like CPU/GPU, which have a finite amount of work to do and
  since a specific amount of energy is consumed at an OPP, its better to
  run at the highest possible frequency for that voltage value.
  On the other hand, we have IO devices which need to run at specific
  frequencies only for their proper functioning, instead of maximum
  possible frequency.
  The OPP core currently roundup to the next possible OPP for a frequency
  and select the fmax value. To support the IO devices by the OPP core,
  lets do the roundup to fetch the voltage or performance state values,
  but not use the OPP frequency value. Rather use the value returned by
  clk_round_rate().
  The current user, cpufreq, of dev_pm_opp_set_rate() already does the
  rounding to the next OPP before calling this routine and it won't
  have any side affects because of this change.


Looks good to me. Should this also be documented someplace that 
dev_pm_opp_set_rate()
would not be able to distinguish between its users trying to scale CPU/GPU's vs 
IO
devices, so its the callers responsibility to round it accordingly before 
calling the
API?


diff --git a/drivers/opp/core.c b/drivers/opp/core.c
index 0fbc77f05048..bae94bfa1e96 100644
--- a/drivers/opp/core.c
+++ b/drivers/opp/core.c
@@ -751,8 +751,11 @@ static int _set_required_opps(struct device *dev,
   * @dev:device for which we do this operation
   * @target_freq: frequency to achieve
   *
- * This configures the power-supplies and clock source to the levels specified
- * by the OPP corresponding to the target_freq.
+ * This configures the power-supplies to the levels specified by the OPP
+ * corresponding to the target_freq, and programs the clock to a value <=
+ * target_freq, as rounded by clk_round_rate(). Device wanting to run at fmax
+ * provided by the opp, should have already rounded to the target OPP's
+ * frequency.
   */


Perfect, thanks.

--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC v2 01/11] OPP: Don't overwrite rounded clk rate

[Viresh Kumar]

On 17-06-19, 09:37, Rajendra Nayak wrote:
> 
> 
> On 6/17/2019 9:20 AM, Viresh Kumar wrote:
> > On 14-06-19, 10:57, Viresh Kumar wrote:
> > > Hmm, so this patch won't break anything and I am inclined to apply it 
> > > again :)
> > > 
> > > Does anyone see any other issues with it, which I might be missing ?
> > 
> > I have updated the commit log a bit more to clarify on things, please let me
> > know if it looks okay.
> > 
> >  opp: Don't overwrite rounded clk rate
> >  The OPP table normally contains 'fmax' values corresponding to the
> >  voltage or performance levels of each OPP, but we don't necessarily 
> > want
> >  all the devices to run at fmax all the time. Running at fmax makes 
> > sense
> >  for devices like CPU/GPU, which have a finite amount of work to do and
> >  since a specific amount of energy is consumed at an OPP, its better to
> >  run at the highest possible frequency for that voltage value.
> >  On the other hand, we have IO devices which need to run at specific
> >  frequencies only for their proper functioning, instead of maximum
> >  possible frequency.
> >  The OPP core currently roundup to the next possible OPP for a frequency
> >  and select the fmax value. To support the IO devices by the OPP core,
> >  lets do the roundup to fetch the voltage or performance state values,
> >  but not use the OPP frequency value. Rather use the value returned by
> >  clk_round_rate().
> >  The current user, cpufreq, of dev_pm_opp_set_rate() already does the
> >  rounding to the next OPP before calling this routine and it won't
> >  have any side affects because of this change.
> 
> Looks good to me. Should this also be documented someplace that 
> dev_pm_opp_set_rate()
> would not be able to distinguish between its users trying to scale CPU/GPU's 
> vs IO
> devices, so its the callers responsibility to round it accordingly before 
> calling the
> API?

diff --git a/drivers/opp/core.c b/drivers/opp/core.c
index 0fbc77f05048..bae94bfa1e96 100644
--- a/drivers/opp/core.c
+++ b/drivers/opp/core.c
@@ -751,8 +751,11 @@ static int _set_required_opps(struct device *dev,
  * @dev:device for which we do this operation
  * @target_freq: frequency to achieve
  *
- * This configures the power-supplies and clock source to the levels specified
- * by the OPP corresponding to the target_freq.
+ * This configures the power-supplies to the levels specified by the OPP
+ * corresponding to the target_freq, and programs the clock to a value <=
+ * target_freq, as rounded by clk_round_rate(). Device wanting to run at fmax
+ * provided by the opp, should have already rounded to the target OPP's
+ * frequency.
  */

-- 
viresh

Re: [RFC v2 01/11] OPP: Don't overwrite rounded clk rate

[Rajendra Nayak]

On 6/17/2019 9:20 AM, Viresh Kumar wrote:

On 14-06-19, 10:57, Viresh Kumar wrote:

Hmm, so this patch won't break anything and I am inclined to apply it again :)

Does anyone see any other issues with it, which I might be missing ?


I have updated the commit log a bit more to clarify on things, please let me
know if it looks okay.

 opp: Don't overwrite rounded clk rate
 
 The OPP table normally contains 'fmax' values corresponding to the

 voltage or performance levels of each OPP, but we don't necessarily want
 all the devices to run at fmax all the time. Running at fmax makes sense
 for devices like CPU/GPU, which have a finite amount of work to do and
 since a specific amount of energy is consumed at an OPP, its better to
 run at the highest possible frequency for that voltage value.
 
 On the other hand, we have IO devices which need to run at specific

 frequencies only for their proper functioning, instead of maximum
 possible frequency.
 
 The OPP core currently roundup to the next possible OPP for a frequency

 and select the fmax value. To support the IO devices by the OPP core,
 lets do the roundup to fetch the voltage or performance state values,
 but not use the OPP frequency value. Rather use the value returned by
 clk_round_rate().
 
 The current user, cpufreq, of dev_pm_opp_set_rate() already does the

 rounding to the next OPP before calling this routine and it won't
 have any side affects because of this change.


Looks good to me. Should this also be documented someplace that 
dev_pm_opp_set_rate()
would not be able to distinguish between its users trying to scale CPU/GPU's vs 
IO
devices, so its the callers responsibility to round it accordingly before 
calling the
API?

 
 Signed-off-by: Stephen Boyd 

 Signed-off-by: Rajendra Nayak 
 [ Viresh: Massaged changelog and use temp_opp variable instead ]
 Signed-off-by: Viresh Kumar 




--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation

Re: [RFC v2 02/11] OPP: Make dev_pm_opp_set_rate() with freq=0 as valid

[Rajendra Nayak]

On 6/14/2019 12:02 PM, Viresh Kumar wrote:

On 20-03-19, 15:19, Rajendra Nayak wrote:

For devices with performance state, we use dev_pm_opp_set_rate()
to set the appropriate clk rate and the performance state.
We do need a way to *remove* the performance state vote when
we idle the device and turn the clocks off. Use dev_pm_opp_set_rate()
with freq=0 to achieve this.

Signed-off-by: Rajendra Nayak 
Signed-off-by: Stephen Boyd 
---
  drivers/opp/core.c | 18 --
  1 file changed, 12 insertions(+), 6 deletions(-)


What about this instead ?


yes, this works, thanks for updating the patch.



diff --git a/drivers/opp/core.c b/drivers/opp/core.c
index 2fe96c2363a3..9accf8bb6afc 100644
--- a/drivers/opp/core.c
+++ b/drivers/opp/core.c
@@ -711,7 +711,7 @@ static int _set_required_opps(struct device *dev,
  
 /* Single genpd case */

 if (!genpd_virt_devs) {
-   pstate = opp->required_opps[0]->pstate;
+   pstate = likely(opp) ? opp->required_opps[0]->pstate : 0;
 ret = dev_pm_genpd_set_performance_state(dev, pstate);
 if (ret) {
 dev_err(dev, "Failed to set performance state of %s: %d 
(%d)\n",
@@ -729,7 +729,7 @@ static int _set_required_opps(struct device *dev,
 mutex_lock(_table->genpd_virt_dev_lock);
  
 for (i = 0; i < opp_table->required_opp_count; i++) {

-   pstate = opp->required_opps[i]->pstate;
+   pstate = likely(opp) ? opp->required_opps[i]->pstate : 0;
  
 if (!genpd_virt_devs[i])

 continue;
@@ -770,14 +770,13 @@ int dev_pm_opp_set_rate(struct device *dev, unsigned long 
target_freq)
  
 if (unlikely(!target_freq)) {

 if (opp_table->required_opp_tables) {
-   /* drop the performance state vote */
-   dev_pm_genpd_set_performance_state(dev, 0);
-   return 0;
+   ret = _set_required_opps(dev, opp_table, NULL);
 } else {
-   dev_err(dev, "%s: Invalid target frequency %lu\n", 
__func__,
-   target_freq);
-   return -EINVAL;
+   dev_err(dev, "target frequency can't be 0\n");
+   ret = -EINVAL;
 }
+
+   goto put_opp_table;
 }
  
 clk = opp_table->clk;




--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 110926] on Centos 6.10

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=110926

Bug ID: 110926
   Summary: on Centos 6.10
   Product: DRI
   Version: XOrg git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: blocker
  Priority: medium
 Component: DRM/AMDgpu-pro
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: wilhelm.hor...@gmail.com

Created attachment 144566
  --> https://bugs.freedesktop.org/attachment.cgi?id=144566=edit
X- server won't start

1.) The pre-install script looks for '/boot/SystemMap-'
2.) Xorg.0.log excerpt 
[27.790] (II) LoadModule: "amdgpu"
[27.790] (II) Loading /opt/amdgpu/lib64/xorg/modules/drivers/amdgpu_drv.so
[27.790] (II) Module amdgpu: vendor="X.Org Foundation"
[27.790]compiled for 1.17.4, module version = 18.1.99
[27.790]Module class: X.Org Video Driver
[27.790]ABI class: X.Org Video Driver, version 19.0
[27.790] (II) AMDGPU: Driver for AMD Radeon:
All GPUs supported by the amdgpu kernel driver
[27.790] (++) using VT number 1

[27.792] (II) AMDGPU(0): [KMS] drm report modesetting isn't supported.
[27.792] (EE) Screen 0 deleted because of no matching config section.
[27.792] (II) UnloadModule: "amdgpu"
[27.792] (EE) Device(s) detected, but none match those in the config file.
[27.792] (EE) 
Fatal server error:
[27.792] (EE) no screens found(EE) 
[27.792] (EE)

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3, 27/27] drm/mediatek: add support for mediatek SOC MT8183

[CK Hu]

Hi, Yongqiang:

On Wed, 2019-06-05 at 19:43 +0800, yongqiang@mediatek.com wrote:
> From: Yongqiang Niu 
> 
> This patch add support for mediatek SOC MT8183
> 1.ovl_2l share driver with ovl
> 2.rdma1 share drive with rdma0, but fifo size is different
> 3.add mt8183 mutex private data, and mmsys private data
> 4.add mt8183 main and external path module for crtc create
> 
> Signed-off-by: Yongqiang Niu 
> ---
>  drivers/gpu/drm/mediatek/mtk_disp_ovl.c |  18 +
>  drivers/gpu/drm/mediatek/mtk_disp_rdma.c|  12 
>  drivers/gpu/drm/mediatek/mtk_drm_ddp.c  | 107 
> 
>  drivers/gpu/drm/mediatek/mtk_drm_ddp.h  |   1 +
>  drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c |   1 +
>  drivers/gpu/drm/mediatek/mtk_drm_drv.c  |  47 
>  6 files changed, 186 insertions(+)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c 
> b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> index 63072d1..efd41aa 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> @@ -382,11 +382,29 @@ static int mtk_disp_ovl_remove(struct platform_device 
> *pdev)
>   .fmt_rgb565_is_0 = true,
>  };
>  
> +static const struct mtk_disp_ovl_data mt8183_ovl_driver_data = {
> + .addr = DISP_REG_OVL_ADDR_MT8173,
> + .gmc_bits = 10,
> + .layer_nr = 4,
> + .fmt_rgb565_is_0 = true,
> +};
> +
> +static const struct mtk_disp_ovl_data mt8183_ovl_2l_driver_data = {
> + .addr = DISP_REG_OVL_ADDR_MT8173,
> + .gmc_bits = 10,
> + .layer_nr = 2,
> + .fmt_rgb565_is_0 = true,
> +};
> +
>  static const struct of_device_id mtk_disp_ovl_driver_dt_match[] = {
>   { .compatible = "mediatek,mt2701-disp-ovl",
> .data = _ovl_driver_data},
>   { .compatible = "mediatek,mt8173-disp-ovl",
> .data = _ovl_driver_data},
> + { .compatible = "mediatek,mt8183-disp-ovl",
> +   .data = _ovl_driver_data},
> + { .compatible = "mediatek,mt8183-disp-ovl-2l",
> +   .data = _ovl_2l_driver_data},
>   {},
>  };
>  MODULE_DEVICE_TABLE(of, mtk_disp_ovl_driver_dt_match);
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c 
> b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
> index b0a5cff..5d62588 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
> @@ -336,11 +336,23 @@ static int mtk_disp_rdma_remove(struct platform_device 
> *pdev)
>   .fifo_size = SZ_8K,
>  };
>  
> +static const struct mtk_disp_rdma_data mt8183_rdma_driver_data = {
> + .fifo_size = 5 * SZ_1K,
> +};
> +
> +static const struct mtk_disp_rdma_data mt8183_rdma1_driver_data = {
> + .fifo_size = SZ_2K,
> +};
> +
>  static const struct of_device_id mtk_disp_rdma_driver_dt_match[] = {
>   { .compatible = "mediatek,mt2701-disp-rdma",
> .data = _rdma_driver_data},
>   { .compatible = "mediatek,mt8173-disp-rdma",
> .data = _rdma_driver_data},
> + { .compatible = "mediatek,mt8183-disp-rdma",
> +   .data = _rdma_driver_data},
> + { .compatible = "mediatek,mt8183-disp-rdma1",

"mediatek,mt8183-disp-rdma1" does not exist in binding document.

> +   .data = _rdma1_driver_data},
>   {},
>  };
>  MODULE_DEVICE_TABLE(of, mtk_disp_rdma_driver_dt_match);
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c 
> b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> index 28274d2..eaf2351 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> @@ -41,8 +41,36 @@
>  #define DISP_REG_CONFIG_DSI_SEL  0x050
>  #define DISP_REG_CONFIG_DPI_SEL  0x064
>  
> +#define MT8183_DISP_OVL0_MOUT_EN 0xF00
> +#define OVL0_MOUT_EN_DISP_PATH0  BIT(0)
> +#define OVL0_MOUT_EN_OVL0_2L BIT(4)
> +#define MT8183_DISP_OVL0_2L_MOUT_EN  0xF04
> +#define OVL0_2L_MOUT_EN_DISP_PATH0   BIT(0)
> +#define MT8183_DISP_OVL1_2L_MOUT_EN  0xF08
> +#define OVL1_2L_MOUT_EN_RDMA1BIT(4)
> +#define MT8183_DISP_DITHER0_MOUT_EN  0xF0C
> +#define DITHER0_MOUT_IN_DSI0 BIT(0)
> +#define MT8183_DISP_PATH0_SEL_IN 0xF24
> +#define DISP_PATH0_SEL_IN_OVL0   0x0
> +#define DISP_PATH0_SEL_IN_OVL0_2L0x1
> +#define MT8183_DISP_DSI0_SEL_IN  0xF2C
> +#define DSI0_SEL_IN_DITHER   0x0
> +#define DSI0_SEL_IN_RDMA00x1
> +#define MT8183_DSI0_SEL_IN_RDMA1 0x3
> +#define MT8183_DISP_DPI0_SEL_IN  0xF30
> +#define MT8183_DPI0_SEL_IN_RDMA0 0x1
> +#define MT8183_DPI0_SEL_IN_RDMA1 0x2
> +#define MT8183_DISP_RDMA0_SOUT_SEL_IN0xF50
> +#define MT8183_RDMA0_SOUT_DSI0   0x0
> +#define MT8183_RDMA0_SOUT_COLOR0 0x1
> +#define 

Re: linux-next: manual merge of the drm-misc tree with the amdgpu tree

[Stephen Rothwell]

Hi all,

On Wed, 12 Jun 2019 11:46:15 +1000 Stephen Rothwell  
wrote:
>
> Hi all,
> 
> Today's linux-next merge of the drm-misc tree got a conflict in:
> 
>   drivers/gpu/drm/amd/display/dc/dce/dce_audio.c
> 
> between commit:
> 
>   c7c7192c56d2 ("drm/amd/display: add audio related regs")
> 
> from the amdgpu tree and commit:
> 
>   4fc4dca8320e ("drm/amd: drop use of drmp.h in os_types.h")
> 
> from the drm-misc tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 
> -- 
> Cheers,
> Stephen Rothwell
> 
> diff --cc drivers/gpu/drm/amd/display/dc/dce/dce_audio.c
> index d43d5d924c19,9b078a71de2e..
> --- a/drivers/gpu/drm/amd/display/dc/dce/dce_audio.c
> +++ b/drivers/gpu/drm/amd/display/dc/dce/dce_audio.c
> @@@ -22,7 -22,9 +22,10 @@@
>* Authors: AMD
>*
>*/
> + 
> + #include 
> + 
>  +#include "../dc.h"
>   #include "reg_helper.h"
>   #include "dce_audio.h"
>   #include "dce/dce_11_0_d.h"

This is now a conflict between the drm tree and the amdgpu tree.

-- 
Cheers,
Stephen Rothwell


pgpgSRHnGf_Hn.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 11/59] drm/arm: Drop drm_gem_prime_export/import

[james qian wang (Arm Technology China)]

On Fri, Jun 14, 2019 at 10:35:27PM +0200, Daniel Vetter wrote:
> They're the default.
> 
> Aside: Would be really nice to switch the others over to
> drm_gem_object_funcs.
> 
> Signed-off-by: Daniel Vetter 
> Cc: "James (Qian) Wang" 
> Cc: Liviu Dudau 
> Cc: Brian Starkey 
> ---
>  drivers/gpu/drm/arm/display/komeda/komeda_kms.c | 2 --
>  drivers/gpu/drm/arm/hdlcd_drv.c | 2 --
>  drivers/gpu/drm/arm/malidp_drv.c| 2 --
>  3 files changed, 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c 
> b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
> index b9d699cc7bbf..45f05bc94487 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
> @@ -63,8 +63,6 @@ static struct drm_driver komeda_kms_driver = {
>   .dumb_create= komeda_gem_cma_dumb_create,
>   .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
>   .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
> - .gem_prime_export   = drm_gem_prime_export,
> - .gem_prime_import   = drm_gem_prime_import,
>   .gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
>   .gem_prime_import_sg_table  = drm_gem_cma_prime_import_sg_table,
>   .gem_prime_vmap = drm_gem_cma_prime_vmap,
> diff --git a/drivers/gpu/drm/arm/hdlcd_drv.c b/drivers/gpu/drm/arm/hdlcd_drv.c
> index b126555895d8..27c46a2838c5 100644
> --- a/drivers/gpu/drm/arm/hdlcd_drv.c
> +++ b/drivers/gpu/drm/arm/hdlcd_drv.c
> @@ -240,8 +240,6 @@ static struct drm_driver hdlcd_driver = {
>   .dumb_create = drm_gem_cma_dumb_create,
>   .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
>   .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
> - .gem_prime_export = drm_gem_prime_export,
> - .gem_prime_import = drm_gem_prime_import,
>   .gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
>   .gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table,
>   .gem_prime_vmap = drm_gem_cma_prime_vmap,
> diff --git a/drivers/gpu/drm/arm/malidp_drv.c 
> b/drivers/gpu/drm/arm/malidp_drv.c
> index 5dccc7130739..3ecdf1311335 100644
> --- a/drivers/gpu/drm/arm/malidp_drv.c
> +++ b/drivers/gpu/drm/arm/malidp_drv.c
> @@ -574,8 +574,6 @@ static struct drm_driver malidp_driver = {
>   .dumb_create = malidp_dumb_create,
>   .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
>   .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
> - .gem_prime_export = drm_gem_prime_export,
> - .gem_prime_import = drm_gem_prime_import,
>   .gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
>   .gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table,
>   .gem_prime_vmap = drm_gem_cma_prime_vmap,
> -- 
> 2.20.1

Hi Daniel

Thank you.

Reviewed-by: James Qian Wang (Arm Technology China) 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

linux-next: manual merge of the drm-intel tree with the pci tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the drm-intel tree got a conflict in:

  drivers/gpu/drm/i915/i915_drv.h

between commit:

  151f4e2bdc7a ("docs: power: convert docs to ReST and rename to *.rst")

from the pci tree and commit:

  1bf676cc2dba ("drm/i915: move and rename i915_runtime_pm")

from the drm-intel tree.

I fixed it up (I just removed the struct definition form this files as
the latter did - its comment will need to be fixed up in its new file)
and can carry the fix as necessary. This is now fixed as far as linux-next
is concerned, but any non trivial conflicts should be mentioned to your
upstream maintainer when your tree is submitted for merging.  You may
also want to consider cooperating with the maintainer of the conflicting
tree to minimise any particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell


pgpsI8THavJEn.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3, 26/27] drm/mediatek: add clock property check before get it

[CK Hu]

Hi, Yongqiang:

On Wed, 2019-06-05 at 19:43 +0800, yongqiang@mediatek.com wrote:
> From: Yongqiang Niu 
> 
> This patch add clock property check before get it

In the binding document [1], clock is required property. In this patch,
you change it to optional property. I think you should change the
binding document and describe _WHY_ do you do this.

[1]
https://www.kernel.org/doc/Documentation/devicetree/bindings/display/mediatek/mediatek%2Cdisp.txt

Regards,
CK

> 
> Signed-off-by: Yongqiang Niu 
> ---
>  drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 10 ++
>  1 file changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c 
> b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> index 9986c61..28274d2 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> @@ -689,10 +689,12 @@ static int mtk_ddp_probe(struct platform_device *pdev)
>   for (i = 0; i < 10; i++)
>   ddp->mutex[i].id = i;
>  
> - ddp->clk = devm_clk_get(dev, NULL);
> - if (IS_ERR(ddp->clk)) {
> - dev_err(dev, "Failed to get clock\n");
> - return PTR_ERR(ddp->clk);
> + if (of_find_property(dev->of_node, "clocks", )) {
> + ddp->clk = devm_clk_get(dev, NULL);
> + if (IS_ERR(ddp->clk)) {
> + dev_err(dev, "Failed to get clock\n");
> + return PTR_ERR(ddp->clk);
> + }
>   }
>  
>   regs = platform_get_resource(pdev, IORESOURCE_MEM, 0);


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

[Bug 102646] Screen flickering under amdgpu-experimental [buggy auto power profile]

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=102646

--- Comment #94 from magist3r  ---
Created attachment 144565
  --> https://bugs.freedesktop.org/attachment.cgi?id=144565=edit
proposed fix

FINALLY!!! I fixed the issue. A small patch with a fix is in the attachment.
Feel free to suggest a better solution, but it works for me without any issues.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3, 19/27] drm/mediatek: add function to background color input select for ovl/ovl_2l direct link

[CK Hu]

Hi, Yongqiang:

On Wed, 2019-06-05 at 19:42 +0800, yongqiang@mediatek.com wrote:
> From: Yongqiang Niu 
> 
> This patch add function to background color input select for ovl/ovl_2l 
> direct link
> for ovl/ovl_2l direct link usecase, we need set background color
> input select for these hardware.
> this is preparation patch for ovl/ovl_2l usecase
> 
> Signed-off-by: Yongqiang Niu 
> ---
>  drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 16 
>  1 file changed, 16 insertions(+)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h 
> b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> index 158c1e5..aa1e183 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> @@ -92,6 +92,9 @@ struct mtk_ddp_comp_funcs {
>struct mtk_plane_state *state);
>   void (*gamma_set)(struct mtk_ddp_comp *comp,
> struct drm_crtc_state *state);
> + void (*bgclr_in_on)(struct mtk_ddp_comp *comp,
> + enum mtk_ddp_comp_id prev);

prev is useless, so remove it.

Regards,
CK

> + void (*bgclr_in_off)(struct mtk_ddp_comp *comp);
>  };
>  
>  struct mtk_ddp_comp {
> @@ -173,6 +176,19 @@ static inline void mtk_ddp_gamma_set(struct mtk_ddp_comp 
> *comp,
>   comp->funcs->gamma_set(comp, state);
>  }
>  
> +static inline void mtk_ddp_comp_bgclr_in_on(struct mtk_ddp_comp *comp,
> + enum mtk_ddp_comp_id prev)
> +{
> + if (comp->funcs && comp->funcs->bgclr_in_on)
> + comp->funcs->bgclr_in_on(comp, prev);
> +}
> +
> +static inline void mtk_ddp_comp_bgclr_in_off(struct mtk_ddp_comp *comp)
> +{
> + if (comp->funcs && comp->funcs->bgclr_in_off)
> + comp->funcs->bgclr_in_off(comp);
> +}
> +
>  int mtk_ddp_comp_get_id(struct device_node *node,
>   enum mtk_ddp_comp_type comp_type);
>  int mtk_ddp_comp_init(struct device *dev, struct device_node *comp_node,


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

Re: [PATCH 19/59] drm/mtk: Drop drm_gem_prime_export/import

[CK Hu]

Hi, Daniel:

On Fri, 2019-06-14 at 22:35 +0200, Daniel Vetter wrote:
> They're the default.
> 
> Aside: Would be really nice to switch the others over to
> drm_gem_object_funcs.

Reviewed-by: CK Hu 

> 
> Signed-off-by: Daniel Vetter 
> Cc: CK Hu 
> Cc: Philipp Zabel 
> Cc: Matthias Brugger 
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-media...@lists.infradead.org
> ---
>  drivers/gpu/drm/mediatek/mtk_drm_drv.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c 
> b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> index 1f8b8943b0c6..dd8dab562500 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> @@ -329,8 +329,6 @@ static struct drm_driver mtk_drm_driver = {
>  
>   .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
>   .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
> - .gem_prime_export = drm_gem_prime_export,
> - .gem_prime_import = drm_gem_prime_import,
>   .gem_prime_get_sg_table = mtk_gem_prime_get_sg_table,
>   .gem_prime_import_sg_table = mtk_gem_prime_import_sg_table,
>   .gem_prime_mmap = mtk_drm_gem_mmap_buf,


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

Re: [PATCH 6/6] drm/msm/gpu: add ocmem init/cleanup functions

[Brian Masney]

Hi Bjorn,

On Sun, Jun 16, 2019 at 11:06:33AM -0700, Bjorn Andersson wrote:
> > diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c 
> > b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> > index 6f7f4114afcf..e0a9409c8a32 100644
> > --- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> > +++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> > @@ -29,6 +29,10 @@
> >  #include "msm_gem.h"
> >  #include "msm_mmu.h"
> >  
> > +#ifdef CONFIG_QCOM_OCMEM
> > +#  include 
> > +#endif
> 
> This file exists (after the previous patch), so no need to make its
> inclusion conditional.
> 
> > +
> >  static bool zap_available = true;
> >  
> >  static int zap_shader_load_mdt(struct msm_gpu *gpu, const char *fwname,
> > @@ -897,6 +901,43 @@ static int adreno_get_pwrlevels(struct device *dev,
> > return 0;
> >  }
> >  
> > +int adreno_gpu_ocmem_init(struct device *dev, struct adreno_gpu 
> > *adreno_gpu,
> > + struct adreno_ocmem *adreno_ocmem)
> > +{
> > +#ifdef CONFIG_QCOM_OCMEM
> 
> No need to make this conditional.

I have these #ifdefs for the a5xx and a6xx GPUs that don't have ocmem
in the SoC. Without the #ifdefs, those systems would need to have the
ocmem driver in their kernel.

Thanks for the quick review on the patch set!

Brian

[Bug 110897] HyperZ is broken for r300 (bad z for some micro and macrotiles?)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=110897

--- Comment #64 from Marek Olšák  ---
rs400, which includes rc400, is not r400. It's r300.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 110897] HyperZ is broken for r300 (bad z for some micro and macrotiles?)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=110897

--- Comment #63 from cosiek...@o2.pl ---
(In reply to Richard Thier from comment #58)
> Also there was one time where things were working for me before changes but
> I do not know what the pipe value was back then. So yes, there is SOME
> chance that this register can also return 1 in my case too, but it seems
> most of the time (99% at least if not 100%) it returns 3.

It would be lovely if you could replicate that…

Also this is consistent with your mesa testing earlier. That sometimes when you
compiled mesa with your patches and stock mesa they were both working/not
working. But that means that this weird behaviour:
17.1.2-1 crash(different)
17.1.1-1 crash(different)
17.1.0-1 crash(different)
17.0.5-1 working
17.0.4-2 working
17.0.4-1 crash
17.0.3-2 working
17.0.3-1 crash
17.0.2-2 working
17.0.2-1 crash
17.0.1-2 crash
17.0.1-1 crash
17.0.0-3 crash
17.0.0-2 crash
17.0.0-1 crash
13.0.4-2 crash
is something different than this bug. But I don't believe that there were any
changes between for example 17.0.3-1 and 17.0.3-2…

Sooo, reboot, cold start, suspend don't change anything with pipe numbers?

Also if you take a look at my old piglit tests, there were definitely more bugs
with HyperZ on.

Also great work so far!

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 110897] HyperZ is broken for r300 (bad z for some micro and macrotiles?)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=110897

--- Comment #62 from Richard Thier  ---
Tested both versions and both work for me. Performance gain when using HyperZ
is around 5-10% for me (that is sometimes just 2-4 FPS, sometimes more).

gb_pipes are reported as 1 now as it should be.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 0/6] ARM: qcom: working Nexus 5 display support

[Bjorn Andersson]

On Fri 31 May 02:46 PDT 2019, Brian Masney wrote:

> This patch series adds working display support to the LG Nexus 5
> (hammerhead) phone.
> 
> Changes since v2:
> - Dropped two drm/msm bug fix patches that have been merged separately.
> - New patch: 'add support for per-CRTC max_vblank_count on mdp5'.
>   Special thanks to Jeffrey Hugo for helping to track down this issue.
> - Add panel_pin to msm8974-hammerhead device tree. Dropped Linus
>   Walleij's reviewed-by on this patch due to this change.
> 
> Changes since v1:
> - Shortened problem description above. I'll reply to this email and send
>   a full dmesg with the boot log with debugging turned on.
> - Dropped patch 'fix null pointer dereference in
>   msm_atomic_prepare_fb()'
> - New patch: Remove resv fields from msm_gem_object struct that was
>   incorrectly being referenced by the prepare_fb callbacks.
> - Add drm_plane_enable_fb_damage_clips() to plane init for mdp4, mdp5,
>   and dpu1.
> - Add Linus Walleij's reviewed-by to patches 3-6
> 
> My status page at https://masneyb.github.io/nexus-5-upstream/
> describes what is working so far with the upstream kernel on the Nexus
> 5.
> 

Assuming that patches 1 and 2 won't affect the dts and applied patches 3
through 6 for v5.3.

Regards,
Bjorn

> Brian Masney (6):
>   drm/msm: add dirty framebuffer helper
>   drm/msm: add support for per-CRTC max_vblank_count on mdp5
>   ARM: qcom_defconfig: add display-related options
>   ARM: dts: qcom: msm8974-hammerhead: add support for backlight
>   ARM: dts: msm8974: add display support
>   ARM: dts: qcom: msm8974-hammerhead: add support for display
> 
>  .../qcom-msm8974-lge-nexus5-hammerhead.dts|  92 
>  arch/arm/boot/dts/qcom-msm8974.dtsi   | 132 ++
>  arch/arm/configs/qcom_defconfig   |   5 +
>  drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c |   3 +
>  drivers/gpu/drm/msm/disp/mdp4/mdp4_plane.c|   3 +
>  drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c |  16 ++-
>  drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c  |   2 +-
>  drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c|   3 +
>  drivers/gpu/drm/msm/msm_fb.c  |   2 +
>  9 files changed, 256 insertions(+), 2 deletions(-)
> 
> -- 
> 2.20.1
> 

Re: [PATCH 6/6] drm/msm/gpu: add ocmem init/cleanup functions

[Bjorn Andersson]

On Sun 16 Jun 06:29 PDT 2019, Brian Masney wrote:

> The files a3xx_gpu.c and a4xx_gpu.c have ifdefs for the OCMEM support
> that was missing upstream. Add two new functions (adreno_gpu_ocmem_init
> and adreno_gpu_ocmem_cleanup) that removes some duplicated code. We also
> need to change the ifdef check for CONFIG_MSM_OCMEM to CONFIG_QCOM_OCMEM
> now that OCMEM support is upstream.
> 
> Signed-off-by: Brian Masney 
> ---
>  drivers/gpu/drm/msm/adreno/a3xx_gpu.c   | 33 +++-
>  drivers/gpu/drm/msm/adreno/a3xx_gpu.h   |  3 +-
>  drivers/gpu/drm/msm/adreno/a4xx_gpu.c   | 30 ++
>  drivers/gpu/drm/msm/adreno/a4xx_gpu.h   |  3 +-
>  drivers/gpu/drm/msm/adreno/adreno_gpu.c | 41 +
>  drivers/gpu/drm/msm/adreno/adreno_gpu.h | 10 ++
>  6 files changed, 74 insertions(+), 46 deletions(-)
> 
> diff --git a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c 
> b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
> index c3b4bc6e4155..72720bb2aca1 100644
> --- a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
> @@ -17,10 +17,6 @@
>   * this program.  If not, see .
>   */
>  
> -#ifdef CONFIG_MSM_OCMEM
> -#  include 
> -#endif
> -
>  #include "a3xx_gpu.h"
>  
>  #define A3XX_INT0_MASK \
> @@ -206,9 +202,9 @@ static int a3xx_hw_init(struct msm_gpu *gpu)
>   gpu_write(gpu, REG_A3XX_RBBM_GPR0_CTL, 0x);
>  
>   /* Set the OCMEM base address for A330, etc */
> - if (a3xx_gpu->ocmem_hdl) {
> + if (a3xx_gpu->ocmem.hdl) {
>   gpu_write(gpu, REG_A3XX_RB_GMEM_BASE_ADDR,
> - (unsigned int)(a3xx_gpu->ocmem_base >> 14));
> + (unsigned int)(a3xx_gpu->ocmem.base >> 14));

This blindly requires that the ocmem allocator will return entries
allocated to 16kB. Please ensure that a future implementation of the
actual ocmem allocator maintains this (comments? checks?). 

>   }
>  
>   /* Turn on performance counters: */
> @@ -329,10 +325,7 @@ static void a3xx_destroy(struct msm_gpu *gpu)
>  
>   adreno_gpu_cleanup(adreno_gpu);
>  
> -#ifdef CONFIG_MSM_OCMEM
> - if (a3xx_gpu->ocmem_base)
> - ocmem_free(OCMEM_GRAPHICS, a3xx_gpu->ocmem_hdl);
> -#endif
> + adreno_gpu_ocmem_cleanup(_gpu->ocmem);
>  
>   kfree(a3xx_gpu);
>  }
> @@ -507,17 +500,10 @@ struct msm_gpu *a3xx_gpu_init(struct drm_device *dev)
>  
>   /* if needed, allocate gmem: */
>   if (adreno_is_a330(adreno_gpu)) {
> -#ifdef CONFIG_MSM_OCMEM
> - /* TODO this is different/missing upstream: */
> - struct ocmem_buf *ocmem_hdl =
> - ocmem_allocate(OCMEM_GRAPHICS, 
> adreno_gpu->gmem);
> -
> - a3xx_gpu->ocmem_hdl = ocmem_hdl;
> - a3xx_gpu->ocmem_base = ocmem_hdl->addr;
> - adreno_gpu->gmem = ocmem_hdl->len;
> - DBG("using %dK of OCMEM at 0x%08x", adreno_gpu->gmem / 1024,
> - a3xx_gpu->ocmem_base);
> -#endif
> + ret = adreno_gpu_ocmem_init(_gpu->base.pdev->dev,
> + adreno_gpu, _gpu->ocmem);
> + if (ret)
> + goto fail;
>   }
>  
>   if (!gpu->aspace) {
> @@ -530,11 +516,14 @@ struct msm_gpu *a3xx_gpu_init(struct drm_device *dev)
>*/
>   DRM_DEV_ERROR(dev->dev, "No memory protection without IOMMU\n");
>   ret = -ENXIO;
> - goto fail;
> + goto fail_cleanup_ocmem;
>   }
>  
>   return gpu;
>  
> +fail_cleanup_ocmem:
> + adreno_gpu_ocmem_cleanup(_gpu->ocmem);
> +
>  fail:
>   if (a3xx_gpu)
>   a3xx_destroy(_gpu->base.base);
> diff --git a/drivers/gpu/drm/msm/adreno/a3xx_gpu.h 
> b/drivers/gpu/drm/msm/adreno/a3xx_gpu.h
> index ab60dc9e344e..727c34f38f9e 100644
> --- a/drivers/gpu/drm/msm/adreno/a3xx_gpu.h
> +++ b/drivers/gpu/drm/msm/adreno/a3xx_gpu.h
> @@ -30,8 +30,7 @@ struct a3xx_gpu {
>   struct adreno_gpu base;
>  
>   /* if OCMEM is used for GMEM: */
> - uint32_t ocmem_base;
> - void *ocmem_hdl;
> + struct adreno_ocmem ocmem;
>  };
>  #define to_a3xx_gpu(x) container_of(x, struct a3xx_gpu, base)
>  
> diff --git a/drivers/gpu/drm/msm/adreno/a4xx_gpu.c 
> b/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
> index ab2b752566d8..b8f825107796 100644
> --- a/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
> @@ -2,9 +2,6 @@
>  /* Copyright (c) 2014 The Linux Foundation. All rights reserved.
>   */
>  #include "a4xx_gpu.h"
> -#ifdef CONFIG_MSM_OCMEM
> -#  include 
> -#endif
>  
>  #define A4XX_INT0_MASK \
>   (A4XX_INT0_RBBM_AHB_ERROR |\
> @@ -188,7 +185,7 @@ static int a4xx_hw_init(struct msm_gpu *gpu)
>   (1 << 30) | 0x);
>  
>   gpu_write(gpu, REG_A4XX_RB_GMEM_BASE_ADDR,
> - (unsigned int)(a4xx_gpu->ocmem_base >> 14));
> + (unsigned 

Re: [PATCH 4/6] firmware: qcom: scm: add OCMEM lock/unlock interface

[Bjorn Andersson]

On Sun 16 Jun 06:29 PDT 2019, Brian Masney wrote:

> From: Rob Clark 
> 
> Add support for the OCMEM lock/unlock interface that is needed by the
> On Chip MEMory (OCMEM) that is present on some Snapdragon devices.
> 
> Signed-off-by: Rob Clark 
> [masn...@onstation.org: ported to latest kernel; minor reformatting.]
> Signed-off-by: Brian Masney 

Reviewed-by: Bjorn Andersson 

> ---
> Rob's last version of this patch:
> https://patchwork.kernel.org/patch/7340711/
> 
>  drivers/firmware/qcom_scm-32.c | 35 +
>  drivers/firmware/qcom_scm-64.c | 12 ++
>  drivers/firmware/qcom_scm.c| 40 ++
>  drivers/firmware/qcom_scm.h|  9 
>  include/linux/qcom_scm.h   | 15 +
>  5 files changed, 111 insertions(+)
> 
> diff --git a/drivers/firmware/qcom_scm-32.c b/drivers/firmware/qcom_scm-32.c
> index 089b47124933..0100c82b9c00 100644
> --- a/drivers/firmware/qcom_scm-32.c
> +++ b/drivers/firmware/qcom_scm-32.c
> @@ -463,6 +463,41 @@ int __qcom_scm_restore_sec_config(struct device *dev, 
> u32 sec_id,
>   return 0;
>  }
>  
> +int __qcom_scm_ocmem_lock(struct device *dev, u32 id, u32 offset, u32 size,
> +   u32 mode)
> +{
> + struct ocmem_tz_lock {
> + __le32 id;
> + __le32 offset;
> + __le32 size;
> + __le32 mode;
> + } request;
> +
> + request.id = cpu_to_le32(id);
> + request.offset = cpu_to_le32(offset);
> + request.size = cpu_to_le32(size);
> + request.mode = cpu_to_le32(mode);
> +
> + return qcom_scm_call(dev, QCOM_SCM_OCMEM_SVC, QCOM_SCM_OCMEM_LOCK_CMD,
> +  , sizeof(request), NULL, 0);
> +}
> +
> +int __qcom_scm_ocmem_unlock(struct device *dev, u32 id, u32 offset, u32 size)
> +{
> + struct ocmem_tz_unlock {
> + __le32 id;
> + __le32 offset;
> + __le32 size;
> + } request;
> +
> + request.id = cpu_to_le32(id);
> + request.offset = cpu_to_le32(offset);
> + request.size = cpu_to_le32(size);
> +
> + return qcom_scm_call(dev, QCOM_SCM_OCMEM_SVC, QCOM_SCM_OCMEM_UNLOCK_CMD,
> +  , sizeof(request), NULL, 0);
> +}
> +
>  void __qcom_scm_init(void)
>  {
>  }
> diff --git a/drivers/firmware/qcom_scm-64.c b/drivers/firmware/qcom_scm-64.c
> index b6b78da7f9c9..2674d6d3cdde 100644
> --- a/drivers/firmware/qcom_scm-64.c
> +++ b/drivers/firmware/qcom_scm-64.c
> @@ -247,6 +247,18 @@ int __qcom_scm_restore_sec_config(struct device *dev, 
> u32 sec_id,
>   return -ENOTSUPP;
>  }
>  
> +int __qcom_scm_ocmem_lock(struct device *dev, uint32_t id, uint32_t offset,
> +   uint32_t size, uint32_t mode)
> +{
> + return -ENOTSUPP;
> +}
> +
> +int __qcom_scm_ocmem_unlock(struct device *dev, uint32_t id, uint32_t offset,
> + uint32_t size)
> +{
> + return -ENOTSUPP;
> +}
> +
>  void __qcom_scm_init(void)
>  {
>   u64 cmd;
> diff --git a/drivers/firmware/qcom_scm.c b/drivers/firmware/qcom_scm.c
> index 5495ef994c5d..85afb54defd4 100644
> --- a/drivers/firmware/qcom_scm.c
> +++ b/drivers/firmware/qcom_scm.c
> @@ -193,6 +193,46 @@ int qcom_scm_restore_sec_config(struct device *dev,
>  }
>  EXPORT_SYMBOL(qcom_scm_restore_sec_config);
>  
> +/**
> + * qcom_scm_ocmem_lock_available() - is OCMEM lock/unlock interface available
> + */
> +bool qcom_scm_ocmem_lock_available(void)
> +{
> + return __qcom_scm_is_call_available(__scm->dev, QCOM_SCM_OCMEM_SVC,
> + QCOM_SCM_OCMEM_LOCK_CMD);
> +}
> +EXPORT_SYMBOL(qcom_scm_ocmem_lock_available);
> +
> +/**
> + * qcom_scm_ocmem_lock() - call OCMEM lock interface to assign an OCMEM
> + * region to the specified initiator
> + *
> + * @id: tz initiator id
> + * @offset: OCMEM offset
> + * @size:   OCMEM size
> + * @mode:   access mode (WIDE/NARROW)
> + */
> +int qcom_scm_ocmem_lock(enum qcom_scm_ocmem_client id, u32 offset, u32 size,
> + u32 mode)
> +{
> + return __qcom_scm_ocmem_lock(__scm->dev, id, offset, size, mode);
> +}
> +EXPORT_SYMBOL(qcom_scm_ocmem_lock);
> +
> +/**
> + * qcom_scm_ocmem_unlock() - call OCMEM unlock interface to release an OCMEM
> + * region from the specified initiator
> + *
> + * @id: tz initiator id
> + * @offset: OCMEM offset
> + * @size:   OCMEM size
> + */
> +int qcom_scm_ocmem_unlock(enum qcom_scm_ocmem_client id, u32 offset, u32 
> size)
> +{
> + return __qcom_scm_ocmem_unlock(__scm->dev, id, offset, size);
> +}
> +EXPORT_SYMBOL(qcom_scm_ocmem_unlock);
> +
>  /**
>   * qcom_scm_pas_supported() - Check if the peripheral authentication service 
> is
>   * available for the given peripherial
> diff --git a/drivers/firmware/qcom_scm.h b/drivers/firmware/qcom_scm.h
> index bccc7d10c5c2..387e3c4e33c5 100644
> --- a/drivers/firmware/qcom_scm.h
> +++ b/drivers/firmware/qcom_scm.h
> @@ -48,6 +48,15 @@ extern void 

Re: [PATCH 3/6] firmware: qcom: scm: add support to restore secure config

[Bjorn Andersson]

On Sun 16 Jun 06:29 PDT 2019, Brian Masney wrote:

> From: Rob Clark 
> 
> Add support to restore the secure configuration that is needed by the
> On Chip MEMory (OCMEM) that is present on some Snapdragon devices.
> 
> Signed-off-by: Rob Clark 
> [masn...@onstation.org: ported to latest kernel; minor reformatting.]
> Signed-off-by: Brian Masney 

This went upstream for 64-bit with config abbreviated cfg, so please
implement __qcom_scm_restore_sec_cfg() for 32-bit and add the defines
instead.

Regards,
Bjorn

> ---
> Rob's last version of this patch:
> https://patchwork.kernel.org/patch/7340701/
> 
>  drivers/firmware/qcom_scm-32.c | 21 +
>  drivers/firmware/qcom_scm-64.c |  6 ++
>  drivers/firmware/qcom_scm.c| 23 +++
>  drivers/firmware/qcom_scm.h|  6 ++
>  include/linux/qcom_scm.h   | 13 +
>  5 files changed, 69 insertions(+)
> 
> diff --git a/drivers/firmware/qcom_scm-32.c b/drivers/firmware/qcom_scm-32.c
> index 215061c581e1..089b47124933 100644
> --- a/drivers/firmware/qcom_scm-32.c
> +++ b/drivers/firmware/qcom_scm-32.c
> @@ -442,6 +442,27 @@ int __qcom_scm_hdcp_req(struct device *dev, struct 
> qcom_scm_hdcp_req *req,
>   req, req_cnt * sizeof(*req), resp, sizeof(*resp));
>  }
>  
> +int __qcom_scm_restore_sec_config(struct device *dev, u32 sec_id,
> +   u32 ctx_bank_num)
> +{
> + struct msm_scm_sec_cfg {
> + __le32 id;
> + __le32 ctx_bank_num;
> + } cfg;
> + int ret, scm_ret = 0;
> +
> + cfg.id = cpu_to_le32(sec_id);
> + cfg.ctx_bank_num = cpu_to_le32(sec_id);
> +
> + ret = qcom_scm_call(dev, QCOM_SCM_MP_SVC, QCOM_SCM_MP_RESTORE_SEC_CFG,
> + , sizeof(cfg), _ret, sizeof(scm_ret));
> +
> + if (ret || scm_ret)
> + return ret ? ret : -EINVAL;
> +
> + return 0;
> +}
> +
>  void __qcom_scm_init(void)
>  {
>  }
> diff --git a/drivers/firmware/qcom_scm-64.c b/drivers/firmware/qcom_scm-64.c
> index 91d5ad7cf58b..b6b78da7f9c9 100644
> --- a/drivers/firmware/qcom_scm-64.c
> +++ b/drivers/firmware/qcom_scm-64.c
> @@ -241,6 +241,12 @@ int __qcom_scm_hdcp_req(struct device *dev, struct 
> qcom_scm_hdcp_req *req,
>   return ret;
>  }
>  
> +int __qcom_scm_restore_sec_config(struct device *dev, u32 sec_id,
> +   u32 ctx_bank_num)
> +{
> + return -ENOTSUPP;
> +}
> +
>  void __qcom_scm_init(void)
>  {
>   u64 cmd;
> diff --git a/drivers/firmware/qcom_scm.c b/drivers/firmware/qcom_scm.c
> index 2ddc118dba1b..5495ef994c5d 100644
> --- a/drivers/firmware/qcom_scm.c
> +++ b/drivers/firmware/qcom_scm.c
> @@ -170,6 +170,29 @@ int qcom_scm_hdcp_req(struct qcom_scm_hdcp_req *req, u32 
> req_cnt, u32 *resp)
>  }
>  EXPORT_SYMBOL(qcom_scm_hdcp_req);
>  
> +/**
> + * qcom_scm_restore_sec_config_available() - Check if secure environment
> + * supports restore security config interface.
> + *
> + * Return true if restore-cfg interface is supported, false if not.
> + */
> +bool qcom_scm_restore_sec_config_available(void)
> +{
> + return __qcom_scm_is_call_available(__scm->dev, QCOM_SCM_MP_SVC,
> + QCOM_SCM_MP_RESTORE_SEC_CFG);
> +}
> +EXPORT_SYMBOL(qcom_scm_restore_sec_config_available);
> +
> +/**
> + * qcom_scm_restore_sec_config() - call restore-cfg interface
> + */
> +int qcom_scm_restore_sec_config(struct device *dev,
> + enum qcom_scm_sec_dev_id sec_id)
> +{
> + return __qcom_scm_restore_sec_config(dev, sec_id, 0);
> +}
> +EXPORT_SYMBOL(qcom_scm_restore_sec_config);
> +
>  /**
>   * qcom_scm_pas_supported() - Check if the peripheral authentication service 
> is
>   * available for the given peripherial
> diff --git a/drivers/firmware/qcom_scm.h b/drivers/firmware/qcom_scm.h
> index 99506bd873c0..bccc7d10c5c2 100644
> --- a/drivers/firmware/qcom_scm.h
> +++ b/drivers/firmware/qcom_scm.h
> @@ -42,6 +42,12 @@ extern int __qcom_scm_hdcp_req(struct device *dev,
>  
>  extern void __qcom_scm_init(void);
>  
> +#define QCOM_SCM_MP_SVC  0xc
> +#define QCOM_SCM_MP_RESTORE_SEC_CFG  0x2
> +
> +extern int __qcom_scm_restore_sec_config(struct device *dev, u32 sec_id,
> +  u32 ctx_bank_num);
> +
>  #define QCOM_SCM_SVC_PIL 0x2
>  #define QCOM_SCM_PAS_INIT_IMAGE_CMD  0x1
>  #define QCOM_SCM_PAS_MEM_SETUP_CMD   0x2
> diff --git a/include/linux/qcom_scm.h b/include/linux/qcom_scm.h
> index 3f12cc77fb58..b5c0afaca955 100644
> --- a/include/linux/qcom_scm.h
> +++ b/include/linux/qcom_scm.h
> @@ -24,6 +24,16 @@ struct qcom_scm_vmperm {
>   int perm;
>  };
>  
> +enum qcom_scm_sec_dev_id {
> + QCOM_SCM_MDSS_DEV_ID= 1,
> + QCOM_SCM_OCMEM_DEV_ID   = 5,
> + QCOM_SCM_PCIE0_DEV_ID   = 11,
> + QCOM_SCM_PCIE1_DEV_ID   = 12,
> + QCOM_SCM_GFX_DEV_ID = 18,
> + QCOM_SCM_UFS_DEV_ID = 19,
> + 

Re: [PATCH 1/6] dt-bindings: soc: qcom: add On Chip MEMory (OCMEM) bindings

[Bjorn Andersson]

On Sun 16 Jun 06:29 PDT 2019, Brian Masney wrote:

> Add device tree bindings for the On Chip Memory (OCMEM) that is present
> on some Qualcomm Snapdragon SoCs.
> 
> Signed-off-by: Brian Masney 
> ---
>  .../bindings/soc/qcom/qcom,ocmem.yaml | 66 +++
>  1 file changed, 66 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,ocmem.yaml
> 
> diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,ocmem.yaml 
> b/Documentation/devicetree/bindings/soc/qcom/qcom,ocmem.yaml
> new file mode 100644
> index ..5e3ae6311a16
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,ocmem.yaml
> @@ -0,0 +1,66 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/soc/qcom/qcom,ocmem.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: On Chip Memory (OCMEM) that is present on some Qualcomm Snapdragon 
> SoCs.
> +
> +maintainers:
> +  - Brian Masney 
> +
> +description: |
> +  The On Chip Memory (OCMEM) allocator allows various clients to allocate 
> memory
> +  from OCMEM based on performance, latency and power requirements. This is
> +  typically used by the GPU, camera/video, and audio components on some
> +  Snapdragon SoCs.
> +
> +properties:
> +  compatible:
> +const: qcom,ocmem-msm8974

qcom,msm8974-ocmem

> +
> +  reg:
> +items:
> +  - description: Control registers
> +  - description: OCMEM address range
> +
> +  reg-names:
> +items:
> +  - const: ocmem_ctrl_physical
> +  - const: ocmem_physical

Drop the "_physical" part, it's given by this being "reg".

Regards,
Bjorn

> +
> +  clocks:
> +items:
> +  - description: Core clock
> +  - description: Interface clock
> +
> +  clock-names:
> +items:
> +  - const: core
> +  - const: iface
> +
> +required:
> +  - compatible
> +  - reg
> +  - reg-names
> +  - clocks
> +  - clock-names
> +
> +examples:
> +  - |
> +  #include 
> +  #include 
> +
> +  ocmem: ocmem@fdd0 {
> +compatible = "qcom,ocmem-msm8974";
> +
> +reg = <0xfdd0 0x2000>,
> +   <0xfec0 0x18>;
> +reg-names = "ocmem_ctrl_physical",
> +"ocmem_physical";
> +
> +clocks = < RPM_SMD_OCMEMGX_CLK>,
> +  < OCMEMCX_OCMEMNOC_CLK>;
> +clock-names = "core",
> +  "iface";
> +  };
> -- 
> 2.20.1
> 

[Bug 110897] HyperZ is broken for r300 (bad z for some micro and macrotiles?)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=110897

--- Comment #61 from Richard Thier  ---
Created attachment 144560
  --> https://bugs.freedesktop.org/attachment.cgi?id=144560=edit
Fix variant 2 (special case pipe number for 0x5a62)

Added the second fix variation I've imagined. I am still compiling this so it
is not tested yet, but this should work just as well.

After thinking about it now, actually I tend to favor this latter one as being
more clean, because I have no idea what the other rs400 cards do if I just
forward to the r300 init code. My card works with that variant, but this is
more sane maybe?

The bad thing is that this literally only fixes those cards that do have 0x5a62
as their rdev->pdev->device value.

So "Fix variant 1" might fix more cards if they have a similar issue and "Fix
variant 2" should fix only this one and should not break unrelated cards.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 5/6] soc: qcom: add OCMEM driver

[Bjorn Andersson]

On Sun 16 Jun 06:29 PDT 2019, Brian Masney wrote:

> From: Rob Clark 
> 
> The OCMEM driver handles allocation and configuration of the On Chip
> MEMory that is present on some Snapdragon SoCs.
> 
> Devices which have OCMEM do not have GMEM inside the GPU core, so the
> GPU must instead use OCMEM to be functional. Since currently the GPU
> is the only OCMEM user with an upstream driver, this is just a minimal
> implementation sufficient for statically allocating to the GPU it's
> chunk of OCMEM.
> 
> Signed-off-by: Rob Clark 
> Co-developed-by: Brian Masney 
> Signed-off-by: Brian Masney 
> ---
> Changes since Rob's last version of this patch:
> https://patchwork.kernel.org/patch/7379801/
> - reformatted driver to allow multiple instances
> - updated logging of error paths during device probing
> - remove unused psgsc_ctrl
> - remove _clk from clock names
> - propagate error code from devm_ioremap_resource()
> - use device_get_match_data()
> - SPDX license tags
> - remove QCOM_SMD in Kconfig
> - select ARCH_QCOM in Kconfig
> - select QCOM_SCM in Kconfig
> - longer description in Kconfig
> 
>  drivers/soc/qcom/Kconfig |  10 +
>  drivers/soc/qcom/Makefile|   1 +
>  drivers/soc/qcom/ocmem.c | 402 +++
>  drivers/soc/qcom/ocmem.xml.h |  86 
>  include/soc/qcom/ocmem.h |  34 +++
>  5 files changed, 533 insertions(+)
>  create mode 100644 drivers/soc/qcom/ocmem.c
>  create mode 100644 drivers/soc/qcom/ocmem.xml.h
>  create mode 100644 include/soc/qcom/ocmem.h
> 
> diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
> index 880cf0290962..998d94d60a3c 100644
> --- a/drivers/soc/qcom/Kconfig
> +++ b/drivers/soc/qcom/Kconfig
> @@ -62,6 +62,16 @@ config QCOM_MDT_LOADER
>   tristate
>   select QCOM_SCM
>  
> +config QCOM_OCMEM
> + tristate "Qualcomm On Chip Memory (OCMEM) driver"
> + depends on ARCH_QCOM
> + select QCOM_SCM
> + help
> +  The On Chip Memory (OCMEM) allocator allows various clients to
> +  allocate memory from OCMEM based on performance, latency and power
> +  requirements. This is typically used by the GPU, camera/video, and
> +  audio components on some Snapdragon SoCs.
> +
>  config QCOM_PM
>   bool "Qualcomm Power Management"
>   depends on ARCH_QCOM && !ARM64
> diff --git a/drivers/soc/qcom/Makefile b/drivers/soc/qcom/Makefile
> index ffe519b0cb66..76ac469f548c 100644
> --- a/drivers/soc/qcom/Makefile
> +++ b/drivers/soc/qcom/Makefile
> @@ -5,6 +5,7 @@ obj-$(CONFIG_QCOM_COMMAND_DB) += cmd-db.o
>  obj-$(CONFIG_QCOM_GLINK_SSR) +=  glink_ssr.o
>  obj-$(CONFIG_QCOM_GSBI)  +=  qcom_gsbi.o
>  obj-$(CONFIG_QCOM_MDT_LOADER)+= mdt_loader.o
> +obj-$(CONFIG_QCOM_OCMEM) += ocmem.o
>  obj-$(CONFIG_QCOM_PM)+=  spm.o
>  obj-$(CONFIG_QCOM_QMI_HELPERS)   += qmi_helpers.o
>  qmi_helpers-y+= qmi_encdec.o qmi_interface.o
> diff --git a/drivers/soc/qcom/ocmem.c b/drivers/soc/qcom/ocmem.c
> new file mode 100644
> index ..5ebf5031b6c5
> --- /dev/null
> +++ b/drivers/soc/qcom/ocmem.c
> @@ -0,0 +1,402 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (C) 2019 Brian Masney 
> + * Copyright (C) 2015 Red Hat. Author: Rob Clark 
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include "ocmem.xml.h"
> +
> +enum region_mode {
> + WIDE_MODE = 0x0,
> + THIN_MODE,
> + MODE_DEFAULT = WIDE_MODE,
> +};
> +
> +struct ocmem_region {
> + bool interleaved;
> + enum region_mode mode;
> + unsigned int num_macros;
> + enum ocmem_macro_state macro_state[4];
> + unsigned long macro_size;
> + unsigned long region_size;
> +};
> +
> +struct ocmem_config {
> + uint8_t num_regions;
> + uint32_t macro_size;
> +};
> +
> +struct ocmem {
> + struct device *dev;
> + const struct ocmem_config *config;
> + struct resource *ocmem_mem;
> + struct clk *core_clk;
> + struct clk *iface_clk;
> + void __iomem *mmio;
> + unsigned int num_ports;
> + unsigned int num_macros;
> + bool interleaved;
> + struct ocmem_region *regions;
> +};
> +
> +#define FIELD(val, name) (((val) & name ## __MASK) >> name ## __SHIFT)

include/linux/bitfield.h has standard macros for this, please use that
instead.

> +
> +static inline void ocmem_write(struct ocmem *ocmem, u32 reg, u32 data)
> +{
> + writel(data, ocmem->mmio + reg);
> +}
> +
> +static inline u32 ocmem_read(struct ocmem *ocmem, u32 reg)
> +{
> + return readl(ocmem->mmio + reg);
> +}
> +
> +static int ocmem_clk_enable(struct ocmem *ocmem)
> +{
> + int ret;
> +
> + ret = clk_prepare_enable(ocmem->core_clk);

Use clk_bulk_* instead, it will reduce the amount of duplication in the
three places you poke at your clocks.

And with that I would suggest that you just inline these into probe and
remove.

> + if 

[Bug 110897] HyperZ is broken for r300 (bad z for some micro and macrotiles?)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=110897

--- Comment #60 from Richard Thier  ---
Created attachment 144559
  --> https://bugs.freedesktop.org/attachment.cgi?id=144559=edit
Fix variant 1 (delegate to r300 init)

Added a possible drm patch for kernel source tree. This version is the one that
delegates the rs400_gpu_init call to the r300_gpu_init directly.

Tested at my machine only so far. Tried to comment things as good as possible.

I will make an other variant soon!

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 110674] Crashes / Resets From AMDGPU / Radeon VII

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=110674

--- Comment #40 from Alex Deucher  ---
Please attach your full dmesg output.  Are you passing any parameters to the
driver?

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 110674] Crashes / Resets From AMDGPU / Radeon VII

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=110674

Alex Deucher  changed:

   What|Removed |Added

 Attachment #144438|text/x-log  |text/plain
  mime type||

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 110897] HyperZ is broken for r300 (bad z for some micro and macrotiles?)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=110897

--- Comment #59 from Richard Thier  ---
> the glitches are the same (I know about some already),
> everything works that worked before...

I was kinda hoping maybe some glitches I know can go away if the init code does
the r300_init but that is not the case sadly. Quite the same overall system,
but now have 1 pipes reported in dmesg.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 110897] HyperZ is broken for r300 (bad z for some micro and macrotiles?)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=110897

--- Comment #58 from Richard Thier  ---
I still have some dmesg logs around from my other debugging session and in
every one of those I get 3 pipes despite different kernel versions from 4.4 to
latest 5.x

Also looking at git blame I can see that relevant code paths were last touched
10 years ago with a big drm related commit. So nothing has changed in the code
it seems. Ok... I didn't check if the register number in the header is changed
or not, just hoped not, but the code itself is doing the same 10 year old
things here. Even the FIXME saying if this is good or not (when calling
r420_pipes_init in rs400_init) is that old.

[drm] initializing kernel modesetting (RS400 0x1002:0x5A62 0x1043:0x1392)

^^You seem to be also 5A62 here. In the code of r420_pipes_init, there are some
hardcoded cases for some other similar values that force a single-pipe instead
of reading from the register but you do not fall into those. The last two
numbers are different in your case, but that does not count for that code path
that decides the pipe number - except if the small variance in the last two
means that your card gives back proper values in the register from which you
can read the pipe num.

Btw running with r300_init call instead of the r420 pipe initializaion is going
good so far: performance is the same, the glitches are the same (I know about
some already), everything works that worked before...

One possible solution might be to just use r300_init for r400, but I have no
idea if that breaks some r400 cards. I only have my RC410 but no other... An
other appoach is to add one more special cases for the r420_pipes_init that
specifically checks for 5A62 and forces a single pipeline despite what is read
from the register.

Also there was one time where things were working for me before changes but I
do not know what the pipe value was back then. So yes, there is SOME chance
that this register can also return 1 in my case too, but it seems most of the
time (99% at least if not 100%) it returns 3.

I will prepare both patches and then let others decide which direction to take.
I think taking the r300_init direction is maybe better because of hopeful
backwards compatibility in general.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/amd/powerplay/smu7_hwmgr: replace blocking delay with non-blocking

[Yrjan Skrimstad]

On Thu, Jun 13, 2019 at 09:57:24AM -0400, Alex Deucher wrote:
> The patch is fine and I can apply it (I don't think there are any
> restrictions on sleeping in sysfs), but this code only gets executed
> when you actually read the power status from the card (e.g., via sysfs
> or debugfs).  Presumably you have something in userspace polling one
> of those files on a regular basis?
> 
> Alex

That is an interesting observation to me. I am actually running
lm-sensors, although only every 15 seconds. I suppose that this might
be the reason this happens to me.

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

[Bug 110897] HyperZ is broken for r300 (bad z for some micro and macrotiles?)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=110897

--- Comment #57 from cosiek...@o2.pl ---
4.14.124: 1 quad pipes, 1 z pipes initialized.
4.19.49: 1 quad pipes, 1 z pipes initialized.
4.20.17: 1 quad pipes, 1 z pipes initialized.
5.0.21: 1 quad pipes, 1 z pipes initialized.
5.1.8: 1 quad pipes, 1 z pipes initialized.

Richard Thier, if we have the same graphic card then why do you sometimes get
"3 quad pipes, 1 z pipes initialized."? Can you test on different kernel
versions? Do you always have this 3 quad pipes or it's random? I'm happy to
help further :)

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH libdrm v2 2/4] *symbols-check: use normal shell over bash

[Niclas Zeising]

On 2019-06-16 15:23, Emil Velikov wrote:

None of the tests are bash specific. Tested with bash, zsh, dash, mksh
and ksh.

Signed-off-by: Emil Velikov 


Tested-by: Niclas Zeising 
Reviewed-by: Niclas Zeising 


---
  amdgpu/amdgpu-symbol-check   | 2 +-
  etnaviv/etnaviv-symbol-check | 2 +-
  exynos/exynos-symbol-check   | 2 +-
  freedreno/freedreno-symbol-check | 2 +-
  intel/intel-symbol-check | 2 +-
  libkms/kms-symbol-check  | 2 +-
  nouveau/nouveau-symbol-check | 2 +-
  omap/omap-symbol-check   | 2 +-
  radeon/radeon-symbol-check   | 2 +-
  tegra/tegra-symbol-check | 2 +-
  10 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/amdgpu/amdgpu-symbol-check b/amdgpu/amdgpu-symbol-check
index 5ce15f46..ea83850d 100755
--- a/amdgpu/amdgpu-symbol-check
+++ b/amdgpu/amdgpu-symbol-check
@@ -1,4 +1,4 @@
-#!/bin/bash
+#!/bin/sh
  
  set -u
  
diff --git a/etnaviv/etnaviv-symbol-check b/etnaviv/etnaviv-symbol-check

index 18910688..ef4e66f4 100755
--- a/etnaviv/etnaviv-symbol-check
+++ b/etnaviv/etnaviv-symbol-check
@@ -1,4 +1,4 @@
-#!/bin/bash
+#!/bin/sh
  
  set -u
  
diff --git a/exynos/exynos-symbol-check b/exynos/exynos-symbol-check

index 49d611e6..d2c362e1 100755
--- a/exynos/exynos-symbol-check
+++ b/exynos/exynos-symbol-check
@@ -1,4 +1,4 @@
-#!/bin/bash
+#!/bin/sh
  
  set -u
  
diff --git a/freedreno/freedreno-symbol-check b/freedreno/freedreno-symbol-check

index 978026c0..987e38fa 100755
--- a/freedreno/freedreno-symbol-check
+++ b/freedreno/freedreno-symbol-check
@@ -1,4 +1,4 @@
-#!/bin/bash
+#!/bin/sh
  
  set -u
  
diff --git a/intel/intel-symbol-check b/intel/intel-symbol-check

index de377bef..2f355321 100755
--- a/intel/intel-symbol-check
+++ b/intel/intel-symbol-check
@@ -1,4 +1,4 @@
-#!/bin/bash
+#!/bin/sh
  
  set -u
  
diff --git a/libkms/kms-symbol-check b/libkms/kms-symbol-check

index 30f444f7..7d3426f6 100755
--- a/libkms/kms-symbol-check
+++ b/libkms/kms-symbol-check
@@ -1,4 +1,4 @@
-#!/bin/bash
+#!/bin/sh
  
  set -u
  
diff --git a/nouveau/nouveau-symbol-check b/nouveau/nouveau-symbol-check

index 6296244c..36703a3e 100755
--- a/nouveau/nouveau-symbol-check
+++ b/nouveau/nouveau-symbol-check
@@ -1,4 +1,4 @@
-#!/bin/bash
+#!/bin/sh
  
  set -u
  
diff --git a/omap/omap-symbol-check b/omap/omap-symbol-check

index 16da3c40..21522ba0 100755
--- a/omap/omap-symbol-check
+++ b/omap/omap-symbol-check
@@ -1,4 +1,4 @@
-#!/bin/bash
+#!/bin/sh
  
  set -u
  
diff --git a/radeon/radeon-symbol-check b/radeon/radeon-symbol-check

index da605bb8..7b69f9a4 100755
--- a/radeon/radeon-symbol-check
+++ b/radeon/radeon-symbol-check
@@ -1,4 +1,4 @@
-#!/bin/bash
+#!/bin/sh
  
  set -u
  
diff --git a/tegra/tegra-symbol-check b/tegra/tegra-symbol-check

index 8539b95b..a74d9749 100755
--- a/tegra/tegra-symbol-check
+++ b/tegra/tegra-symbol-check
@@ -1,4 +1,4 @@
-#!/bin/bash
+#!/bin/sh
  
  set -u
  




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

[PATCH 0/2] MSM8998 MTP Display

[Jeffrey Hugo]

Since we are trying to get the GPU and display hardware in the SoC
supported, it would be nice to be able to put the output on the
integrated panel for the reference platform.  To do so, we need support
in the Truly driver to support the specific panel variant for the
MSM8998 MTP.  This series adds taht support.

Jeffrey Hugo (2):
  dt-bindings: display: truly: Add MSM8998 MTP panel
  drm/panel: truly: Add MSM8998 MTP support

 .../bindings/display/truly,nt35597.txt|   7 +-
 drivers/gpu/drm/panel/panel-truly-nt35597.c   | 149 +-
 2 files changed, 116 insertions(+), 40 deletions(-)

-- 
2.17.1

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

Re: [PATCH] drm/nouveau/dmem: missing mutex_lock in error path

[John Hubbard]

On 6/14/19 10:39 AM, Ralph Campbell wrote:
> On 6/13/19 5:49 PM, John Hubbard wrote:
>> On 6/13/19 5:11 PM, Ralph Campbell wrote:
...
>> Actually, the pre-existing code is a little concerning. Your change preserves
>> the behavior, but it seems questionable to be doing a "return 0" (whether
>> via the above break, or your change) when it's in this partially allocated
>> state. It's reporting success when it only allocates part of what was 
>> requested,
>> and it doesn't fill in the pages array either.
>>
>>
>>
>>> +    return 0;
>>>   return ret;
>>>   }
>>> +    mutex_lock(>dmem->mutex);
>>>   continue;
>>>   }
>>>  
>>
>> The above comment is about pre-existing potential problems, but your patch 
>> itself
>> looks correct, so:
>>
>> Reviewed-by: John Hubbard 
>>
>>
>> thanks,
>>
> The crash was the NULL pointer bug in Christoph's patch #10.
> I sent a separate reply for that.
> 
> Below is the console output I got, then I made the changes just based on
> code inspection. Do you think I should include it in the change log?

Yes, I think it's good to have it in there. If you look at git log,
you'll see that it's common to include the symptoms, including the
backtrace. It helps people see if they are hitting the same problem,
for one thing.

> 
> As for the "return 0", If you follow the call chain,
> nouveau_dmem_pages_alloc() is only ever called for one page so this
> currently "works" but I agree it is a bit of a time bomb. There are a
> number of other bugs that I can see that need fixing but I think those
> should be separate patches.
> 

Yes of course. I called it out for the benefit of the email list, not to
say that your patch needs any changes. 

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

Re: Cleanup of -Wunused-const-variable in drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c

[Nick Desaulniers]

On Thu, Jun 13, 2019 at 1:50 PM Sean Paul  wrote:
>
> On Thu, Jun 13, 2019 at 4:13 PM Nathan Huckleberry  wrote:
> >
> > Hey all,
> >
> > I'm looking into cleaning up ignored warnings in the kernel so we can
> > remove compiler flags to ignore warnings.
> >
> > There are several unused variables in dpu_formats.c
> > ('dpu_format_map_tile', 'dpu_format_map_p010',
> > 'dpu_format_map_p010_ubwc', 'dpu_format_map_tp10_ubwc').
> > They look like modifiers that were never implemented. I'd like to
> > remove these variables if there are no plans moving forward to
> > implement them. Otherwise I'll just leave them.
>
> We can probably remove them for now and if someone wants to add
> support, they can dredge them back up.

Yep, this has been the feedback for other patches for this warning
when the code was dead or not obviously some kind of
bug/typo/copy-pasta.

Nathan, please submit a patch removing the dead code; it may be
reverted later when it's actually wired up.  Nothing is truly lost w/
git*.
-- 
Thanks,
~Nick Desaulniers
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 17/28] drivers: Introduce bus_find_device_by_of_node() helper

[Suzuki K Poulose]

Add a wrapper to bus_find_device() to search for a device
by the of_node pointer, reusing the generic match function.
Also convert the existing users to make use of the new helper.

Cc: Maarten Lankhorst 
Cc: Maxime Ripard 
Cc: dri-devel@lists.freedesktop.org
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: devicet...@vger.kernel.org
Cc: Florian Fainelli 
Cc: Frank Rowand 
Cc: Heiko Stuebner 
Cc: Liam Girdwood 
Cc: linux-...@vger.kernel.org
Cc: linux-rockc...@lists.infradead.org
Cc: linux-...@vger.kernel.org
Cc: Mathieu Poirier 
Cc: Rob Herring 
Cc: Srinivas Kandagatla 
Cc: Takashi Iwai 
Cc: Wolfram Sang 
Cc: Greg Kroah-Hartman 
Cc: "Rafael J. Wysocki" 
Signed-off-by: Suzuki K Poulose 
---
 drivers/gpu/drm/drm_mipi_dsi.c |  7 +--
 drivers/hwtracing/coresight/of_coresight.c | 11 ++-
 drivers/i2c/i2c-core-of.c  |  7 +--
 drivers/nvmem/core.c   |  7 +--
 drivers/of/of_mdio.c   |  8 +---
 drivers/of/platform.c  |  7 +--
 drivers/spi/spi.c  |  9 ++---
 include/linux/device.h | 12 
 sound/soc/rockchip/rk3399_gru_sound.c  |  9 ++---
 9 files changed, 23 insertions(+), 54 deletions(-)

diff --git a/drivers/gpu/drm/drm_mipi_dsi.c b/drivers/gpu/drm/drm_mipi_dsi.c
index ad19df0..bd2498b 100644
--- a/drivers/gpu/drm/drm_mipi_dsi.c
+++ b/drivers/gpu/drm/drm_mipi_dsi.c
@@ -93,11 +93,6 @@ static struct bus_type mipi_dsi_bus_type = {
.pm = _dsi_device_pm_ops,
 };
 
-static int of_device_match(struct device *dev, const void *data)
-{
-   return dev->of_node == data;
-}
-
 /**
  * of_find_mipi_dsi_device_by_node() - find the MIPI DSI device matching a
  *device tree node
@@ -110,7 +105,7 @@ struct mipi_dsi_device 
*of_find_mipi_dsi_device_by_node(struct device_node *np)
 {
struct device *dev;
 
-   dev = bus_find_device(_dsi_bus_type, NULL, np, of_device_match);
+   dev = bus_find_device_by_of_node(_dsi_bus_type, np);
 
return dev ? to_mipi_dsi_device(dev) : NULL;
 }
diff --git a/drivers/hwtracing/coresight/of_coresight.c 
b/drivers/hwtracing/coresight/of_coresight.c
index 3fc200e..f417f76 100644
--- a/drivers/hwtracing/coresight/of_coresight.c
+++ b/drivers/hwtracing/coresight/of_coresight.c
@@ -18,11 +18,6 @@
 #include 
 
 
-static int of_dev_node_match(struct device *dev, const void *data)
-{
-   return dev->of_node == data;
-}
-
 static struct device *
 of_coresight_get_endpoint_device(struct device_node *endpoint)
 {
@@ -32,8 +27,7 @@ of_coresight_get_endpoint_device(struct device_node *endpoint)
 * If we have a non-configurable replicator, it will be found on the
 * platform bus.
 */
-   dev = bus_find_device(_bus_type, NULL,
- endpoint, of_dev_node_match);
+   dev = bus_find_device_by_of_node(_bus_type, endpoint);
if (dev)
return dev;
 
@@ -41,8 +35,7 @@ of_coresight_get_endpoint_device(struct device_node *endpoint)
 * We have a configurable component - circle through the AMBA bus
 * looking for the device that matches the endpoint node.
 */
-   return bus_find_device(_bustype, NULL,
-  endpoint, of_dev_node_match);
+   return bus_find_device_by_of_node(_bustype, endpoint);
 }
 
 static inline bool of_coresight_legacy_ep_is_input(struct device_node *ep)
diff --git a/drivers/i2c/i2c-core-of.c b/drivers/i2c/i2c-core-of.c
index 2eb59a2..74a4126 100644
--- a/drivers/i2c/i2c-core-of.c
+++ b/drivers/i2c/i2c-core-of.c
@@ -112,11 +112,6 @@ void of_i2c_register_devices(struct i2c_adapter *adap)
of_node_put(bus);
 }
 
-static int of_dev_node_match(struct device *dev, const void *data)
-{
-   return dev->of_node == data;
-}
-
 static int of_dev_or_parent_node_match(struct device *dev, const void *data)
 {
if (dev->of_node == data)
@@ -134,7 +129,7 @@ struct i2c_client *of_find_i2c_device_by_node(struct 
device_node *node)
struct device *dev;
struct i2c_client *client;
 
-   dev = bus_find_device(_bus_type, NULL, node, of_dev_node_match);
+   dev = bus_find_device_by_of_node(_bus_type, node);
if (!dev)
return NULL;
 
diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c
index ac5d945..057d1ff 100644
--- a/drivers/nvmem/core.c
+++ b/drivers/nvmem/core.c
@@ -76,11 +76,6 @@ static struct bus_type nvmem_bus_type = {
.name   = "nvmem",
 };
 
-static int of_nvmem_match(struct device *dev, const void *nvmem_np)
-{
-   return dev->of_node == nvmem_np;
-}
-
 static struct nvmem_device *of_nvmem_find(struct device_node *nvmem_np)
 {
struct device *d;
@@ -88,7 +83,7 @@ static struct nvmem_device *of_nvmem_find(struct device_node 
*nvmem_np)
if (!nvmem_np)
return NULL;
 
-   d = bus_find_device(_bus_type, NULL, nvmem_np, of_nvmem_match);
+   d = 

[PATCH] drm/msm/dpu: Fix Wunused-const-variable

[Nathan Huckleberry]

Clang produces the following warning

drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c:477:32: warning: unused
variable 'dpu_format_map_tile' [-Wunused-const-variable] static const
struct dpu_format dpu_format_map_tile[] = { ^

drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c:602:32: warning: unused
variable 'dpu_format_map_p010' [-Wunused-const-variable] static const
struct dpu_format dpu_format_map_p010[] = { ^

drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c:610:32: warning: unused
variable 'dpu_format_map_p010_ubwc' [-Wunused-const-variable] static
const struct dpu_format dpu_format_map_p010_ubwc[] = { ^

drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c:619:32: warning: unused
variable 'dpu_format_map_tp10_ubwc' [-Wunused-const-variable] static
const struct dpu_format dpu_format_map_tp10_ubwc[] = { ^

Removing the unimplemented modifiers that cause the warning.

Cc: clang-built-li...@googlegroups.com
Link: https://github.com/ClangBuiltLinux/linux/issues/528
Signed-off-by: Nathan Huckleberry 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c | 110 
 1 file changed, 110 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c
index 0440696b5bad..d28520faf157 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c
@@ -470,90 +470,6 @@ static const struct dpu_format dpu_format_map[] = {
DPU_FETCH_LINEAR, 3),
 };
 
-/*
- * A5x tile formats tables:
- * These tables hold the A5x tile formats supported.
- */
-static const struct dpu_format dpu_format_map_tile[] = {
-   INTERLEAVED_RGB_FMT_TILED(BGR565,
-   0, COLOR_5BIT, COLOR_6BIT, COLOR_5BIT,
-   C2_R_Cr, C0_G_Y, C1_B_Cb, 0, 3,
-   false, 2, 0,
-   DPU_FETCH_UBWC, 1, DPU_TILE_HEIGHT_TILED),
-
-   INTERLEAVED_RGB_FMT_TILED(ARGB,
-   COLOR_8BIT, COLOR_8BIT, COLOR_8BIT, COLOR_8BIT,
-   C3_ALPHA, C2_R_Cr, C0_G_Y, C1_B_Cb, 4,
-   true, 4, 0,
-   DPU_FETCH_UBWC, 1, DPU_TILE_HEIGHT_TILED),
-
-   INTERLEAVED_RGB_FMT_TILED(ABGR,
-   COLOR_8BIT, COLOR_8BIT, COLOR_8BIT, COLOR_8BIT,
-   C3_ALPHA, C1_B_Cb, C0_G_Y, C2_R_Cr, 4,
-   true, 4, 0,
-   DPU_FETCH_UBWC, 1, DPU_TILE_HEIGHT_TILED),
-
-   INTERLEAVED_RGB_FMT_TILED(XBGR,
-   COLOR_8BIT, COLOR_8BIT, COLOR_8BIT, COLOR_8BIT,
-   C2_R_Cr, C0_G_Y, C1_B_Cb, C3_ALPHA, 4,
-   false, 4, 0,
-   DPU_FETCH_UBWC, 1, DPU_TILE_HEIGHT_TILED),
-
-   INTERLEAVED_RGB_FMT_TILED(RGBA,
-   COLOR_8BIT, COLOR_8BIT, COLOR_8BIT, COLOR_8BIT,
-   C2_R_Cr, C0_G_Y, C1_B_Cb, C3_ALPHA, 4,
-   true, 4, 0,
-   DPU_FETCH_UBWC, 1, DPU_TILE_HEIGHT_TILED),
-
-   INTERLEAVED_RGB_FMT_TILED(BGRA,
-   COLOR_8BIT, COLOR_8BIT, COLOR_8BIT, COLOR_8BIT,
-   C1_B_Cb, C0_G_Y, C2_R_Cr, C3_ALPHA, 4,
-   true, 4, 0,
-   DPU_FETCH_UBWC, 1, DPU_TILE_HEIGHT_TILED),
-
-   INTERLEAVED_RGB_FMT_TILED(BGRX,
-   COLOR_8BIT, COLOR_8BIT, COLOR_8BIT, COLOR_8BIT,
-   C1_B_Cb, C0_G_Y, C2_R_Cr, C3_ALPHA, 4,
-   false, 4, 0,
-   DPU_FETCH_UBWC, 1, DPU_TILE_HEIGHT_TILED),
-
-   INTERLEAVED_RGB_FMT_TILED(XRGB,
-   COLOR_8BIT, COLOR_8BIT, COLOR_8BIT, COLOR_8BIT,
-   C3_ALPHA, C2_R_Cr, C0_G_Y, C1_B_Cb, 4,
-   false, 4, 0,
-   DPU_FETCH_UBWC, 1, DPU_TILE_HEIGHT_TILED),
-
-   INTERLEAVED_RGB_FMT_TILED(RGBX,
-   COLOR_8BIT, COLOR_8BIT, COLOR_8BIT, COLOR_8BIT,
-   C2_R_Cr, C0_G_Y, C1_B_Cb, C3_ALPHA, 4,
-   false, 4, 0,
-   DPU_FETCH_UBWC, 1, DPU_TILE_HEIGHT_TILED),
-
-   INTERLEAVED_RGB_FMT_TILED(ABGR2101010,
-   COLOR_8BIT, COLOR_8BIT, COLOR_8BIT, COLOR_8BIT,
-   C2_R_Cr, C0_G_Y, C1_B_Cb, C3_ALPHA, 4,
-   true, 4, DPU_FORMAT_FLAG_DX,
-   DPU_FETCH_UBWC, 1, DPU_TILE_HEIGHT_TILED),
-
-   INTERLEAVED_RGB_FMT_TILED(XBGR2101010,
-   COLOR_8BIT, COLOR_8BIT, COLOR_8BIT, COLOR_8BIT,
-   C2_R_Cr, C0_G_Y, C1_B_Cb, C3_ALPHA, 4,
-   true, 4, DPU_FORMAT_FLAG_DX,
-   DPU_FETCH_UBWC, 1, DPU_TILE_HEIGHT_TILED),
-
-   PSEUDO_YUV_FMT_TILED(NV12,
-   0, COLOR_8BIT, COLOR_8BIT, COLOR_8BIT,
-   C1_B_Cb, C2_R_Cr,
-   DPU_CHROMA_420, DPU_FORMAT_FLAG_YUV,
-   DPU_FETCH_UBWC, 2, DPU_TILE_HEIGHT_NV12),
-
-   PSEUDO_YUV_FMT_TILED(NV21,
-   0, COLOR_8BIT, COLOR_8BIT, COLOR_8BIT,
-   C2_R_Cr, C1_B_Cb,
-   DPU_CHROMA_420, DPU_FORMAT_FLAG_YUV,
-   DPU_FETCH_UBWC, 2, DPU_TILE_HEIGHT_NV12),
-};
-
 /*
  * UBWC formats table:
  * This table holds the UBWC formats supported.
@@ -599,32 +515,6 @@ static 

Re: [PATCH v2] drm: radeon: add a missing break in evergreen_cs_handle_reg

[Mathieu Malaterre]

On Thu, Jan 17, 2019 at 9:40 PM Mathieu Malaterre  wrote:
>
> In commit dd220a00e8bd ("drm/radeon/kms: add support for streamout v7")
> case statements were added without a terminating break statement. This
> commit adds the missing break. This was discovered during a compilation
> with W=1.
>
> This commit removes the following warning:
>
>   drivers/gpu/drm/radeon/evergreen_cs.c:1301:11: warning: this statement may 
> fall through [-Wimplicit-fallthrough=]
>
> Suggested-by: Alex Deucher 
> Fixes: dd220a00e8bd ("drm/radeon/kms: add support for streamout v7")
> Signed-off-by: Mathieu Malaterre 
> ---
> v2: Add missing break statement, instead of marking it as fall through

Replaced by:

cc5034a5d293 drm/radeon/evergreen_cs: fix missing break in switch statement

>  drivers/gpu/drm/radeon/evergreen_cs.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/radeon/evergreen_cs.c 
> b/drivers/gpu/drm/radeon/evergreen_cs.c
> index f471537c852f..1e14c6921454 100644
> --- a/drivers/gpu/drm/radeon/evergreen_cs.c
> +++ b/drivers/gpu/drm/radeon/evergreen_cs.c
> @@ -1299,6 +1299,7 @@ static int evergreen_cs_handle_reg(struct 
> radeon_cs_parser *p, u32 reg, u32 idx)
> return -EINVAL;
> }
> ib[idx] += (u32)((reloc->gpu_offset >> 8) & 0x);
> +   break;
> case CB_TARGET_MASK:
> track->cb_target_mask = radeon_get_ib_value(p, idx);
> track->cb_dirty = true;
> --
> 2.19.2
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 06/22] mm: factor out a devm_request_free_mem_region helper

[John Hubbard]

On 6/13/19 2:43 AM, Christoph Hellwig wrote:
> Keep the physical address allocation that hmm_add_device does with the
> rest of the resource code, and allow future reuse of it without the hmm
> wrapper.
> 
> Signed-off-by: Christoph Hellwig 
> ---
>  include/linux/ioport.h |  2 ++
>  kernel/resource.c  | 39 +++
>  mm/hmm.c   | 33 -
>  3 files changed, 45 insertions(+), 29 deletions(-)

Some trivial typos noted below, but this accurately moves the code
into a helper routine, looks good.

Reviewed-by: John Hubbard  


> 
> diff --git a/include/linux/ioport.h b/include/linux/ioport.h
> index da0ebaec25f0..76a33ae3bf6c 100644
> --- a/include/linux/ioport.h
> +++ b/include/linux/ioport.h
> @@ -286,6 +286,8 @@ static inline bool resource_overlaps(struct resource *r1, 
> struct resource *r2)
> return (r1->start <= r2->end && r1->end >= r2->start);
>  }
>  
> +struct resource *devm_request_free_mem_region(struct device *dev,
> + struct resource *base, unsigned long size);
>  
>  #endif /* __ASSEMBLY__ */
>  #endif   /* _LINUX_IOPORT_H */
> diff --git a/kernel/resource.c b/kernel/resource.c
> index 158f04ec1d4f..99c58134ed1c 100644
> --- a/kernel/resource.c
> +++ b/kernel/resource.c
> @@ -1628,6 +1628,45 @@ void resource_list_free(struct list_head *head)
>  }
>  EXPORT_SYMBOL(resource_list_free);
>  
> +#ifdef CONFIG_DEVICE_PRIVATE
> +/**
> + * devm_request_free_mem_region - find free region for device private memory
> + *
> + * @dev: device struct to bind the resource too

   "to"

> + * @size: size in bytes of the device memory to add
> + * @base: resource tree to look in
> + *
> + * This function tries to find an empty range of physical address big enough 
> to
> + * contain the new resource, so that it can later be hotpluged as ZONE_DEVICE

"hotplugged"

> + * memory, which in turn allocates struct pages.
> + */
> +struct resource *devm_request_free_mem_region(struct device *dev,
> + struct resource *base, unsigned long size)
> +{
> + resource_size_t end, addr;
> + struct resource *res;
> +
> + size = ALIGN(size, 1UL << PA_SECTION_SHIFT);
> + end = min_t(unsigned long, base->end, (1UL << MAX_PHYSMEM_BITS) - 1);
> + addr = end - size + 1UL;
> +
> + for (; addr > size && addr >= base->start; addr -= size) {
> + if (region_intersects(addr, size, 0, IORES_DESC_NONE) !=
> + REGION_DISJOINT)
> + continue;
> +
> + res = devm_request_mem_region(dev, addr, size, dev_name(dev));
> + if (!res)
> + return ERR_PTR(-ENOMEM);
> + res->desc = IORES_DESC_DEVICE_PRIVATE_MEMORY;
> + return res;
> + }
> +
> + return ERR_PTR(-ERANGE);
> +}
> +EXPORT_SYMBOL_GPL(devm_request_free_mem_region);
> +#endif /* CONFIG_DEVICE_PRIVATE */
> +
>  static int __init strict_iomem(char *str)
>  {
>   if (strstr(str, "relaxed"))
> diff --git a/mm/hmm.c b/mm/hmm.c
> index e1dc98407e7b..13a16faf0a77 100644
> --- a/mm/hmm.c
> +++ b/mm/hmm.c
> @@ -26,8 +26,6 @@
>  #include 
>  #include 
>  
> -#define PA_SECTION_SIZE (1UL << PA_SECTION_SHIFT)
> -
>  #if IS_ENABLED(CONFIG_HMM_MIRROR)
>  static const struct mmu_notifier_ops hmm_mmu_notifier_ops;
>  
> @@ -1372,7 +1370,6 @@ struct hmm_devmem *hmm_devmem_add(const struct 
> hmm_devmem_ops *ops,
> unsigned long size)
>  {
>   struct hmm_devmem *devmem;
> - resource_size_t addr;
>   void *result;
>   int ret;
>  
> @@ -1398,32 +1395,10 @@ struct hmm_devmem *hmm_devmem_add(const struct 
> hmm_devmem_ops *ops,
>   if (ret)
>   return ERR_PTR(ret);
>  
> - size = ALIGN(size, PA_SECTION_SIZE);
> - addr = min((unsigned long)iomem_resource.end,
> -(1UL << MAX_PHYSMEM_BITS) - 1);
> - addr = addr - size + 1UL;
> -
> - /*
> -  * FIXME add a new helper to quickly walk resource tree and find free
> -  * range
> -  *
> -  * FIXME what about ioport_resource resource ?
> -  */
> - for (; addr > size && addr >= iomem_resource.start; addr -= size) {
> - ret = region_intersects(addr, size, 0, IORES_DESC_NONE);
> - if (ret != REGION_DISJOINT)
> - continue;
> -
> - devmem->resource = devm_request_mem_region(device, addr, size,
> -dev_name(device));
> - if (!devmem->resource)
> - return ERR_PTR(-ENOMEM);
> - break;
> - }
> - if (!devmem->resource)
> - return ERR_PTR(-ERANGE);
> -
> - devmem->resource->desc = IORES_DESC_DEVICE_PRIVATE_MEMORY;
> + devmem->resource = devm_request_free_mem_region(device, _resource,
> + size);
> + if 

Re: [EXT] Re: [PATCH 2/2] drm/panel: Add support for Raydium RM67191 panel driver

[Robert Chiras]

On Vi, 2019-06-14 at 10:39 -0300, Fabio Estevam wrote:
> Caution: EXT Email
> 
> On Fri, Jun 14, 2019 at 10:29 AM Robert Chiras  > wrote:
> 
> > 
> > The GPIO is active high, and the above sequence was received from
> > the
> > panel vendor in the following form:
> > SET_RESET_PIN(1);
> > MDELAY(10);
> > SET_RESET_PIN(0);
> > MDELAY(5);
> > SET_RESET_PIN(1);
> > MDELAY(20);
> > I got rid of the first transition to high since seemed redundant.
> > Also, according to the manual reference, the RSTB pin needs to be
> > active high while operating the display.
> That's exactly my point :-)
> 
> In normal operation the GPIO reset needs to be high.
> 
> During reset the GPIO reset needs to be low., which means that the
> GPIO reset is "active low".
> 
> So you should invert both the dts and the driver to behave correctly.
Now I get it. Thanks! I will update the dts and driver for the gpio.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/nouveau/dmem: missing mutex_lock in error path

[Ralph Campbell]

On 6/13/19 5:49 PM, John Hubbard wrote:

On 6/13/19 5:11 PM, Ralph Campbell wrote:

In nouveau_dmem_pages_alloc(), the drm->dmem->mutex is unlocked before
calling nouveau_dmem_chunk_alloc().
Reacquire the lock before continuing to the next page.

Signed-off-by: Ralph Campbell 
---

I found this while testing Jason Gunthorpe's hmm tree but this is
independent of those changes. I guess it could go through
David Airlie's tree for nouveau or Jason's tree.



Hi Ralph,

btw, was this the fix for the crash you were seeing? It might be nice to
mention in the commit description, if you are seeing real symptoms.



  drivers/gpu/drm/nouveau/nouveau_dmem.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_dmem.c 
b/drivers/gpu/drm/nouveau/nouveau_dmem.c
index 27aa4e72abe9..00f7236af1b9 100644
--- a/drivers/gpu/drm/nouveau/nouveau_dmem.c
+++ b/drivers/gpu/drm/nouveau/nouveau_dmem.c
@@ -379,9 +379,10 @@ nouveau_dmem_pages_alloc(struct nouveau_drm *drm,
ret = nouveau_dmem_chunk_alloc(drm);
if (ret) {
if (c)
-   break;


Actually, the pre-existing code is a little concerning. Your change preserves
the behavior, but it seems questionable to be doing a "return 0" (whether
via the above break, or your change) when it's in this partially allocated
state. It's reporting success when it only allocates part of what was requested,
and it doesn't fill in the pages array either.




+   return 0;
return ret;
}
+   mutex_lock(>dmem->mutex);
continue;
}
  



The above comment is about pre-existing potential problems, but your patch 
itself
looks correct, so:

Reviewed-by: John Hubbard 


thanks,


The crash was the NULL pointer bug in Christoph's patch #10.
I sent a separate reply for that.

Below is the console output I got, then I made the changes just based on
code inspection. Do you think I should include it in the change log?

As for the "return 0", If you follow the call chain,
nouveau_dmem_pages_alloc() is only ever called for one page so this
currently "works" but I agree it is a bit of a time bomb. There are a
number of other bugs that I can see that need fixing but I think those
should be separate patches.

[ 1294.871933] =
[ 1294.876656] WARNING: bad unlock balance detected!
[ 1294.881375] 5.2.0-rc3+ #5 Not tainted
[ 1294.885048] -
[ 1294.889773] test-malloc-vra/6299 is trying to release lock 
(>dmem->mutex) at:
[ 1294.897482] [] 
nouveau_dmem_migrate_alloc_and_copy+0x79f/0xbf0 [nouveau]

[ 1294.905782] but there are no more locks to release!
[ 1294.910690]
[ 1294.910690] other info that might help us debug this:
[ 1294.917249] 1 lock held by test-malloc-vra/6299:
[ 1294.921881]  #0: 16e10454 (>mmap_sem#2){}, at: 
nouveau_svmm_bind+0x142/0x210 [nouveau]

[ 1294.931313]
[ 1294.931313] stack backtrace:
[ 1294.935702] CPU: 4 PID: 6299 Comm: test-malloc-vra Not tainted 
5.2.0-rc3+ #5

[ 1294.942786] Hardware name: ASUS X299-A/PRIME X299-A, BIOS 1401 05/21/2018
[ 1294.949590] Call Trace:
[ 1294.952059]  dump_stack+0x7c/0xc0
[ 1294.955469]  ? nouveau_dmem_migrate_alloc_and_copy+0x79f/0xbf0 [nouveau]
[ 1294.962213]  print_unlock_imbalance_bug.cold.52+0xca/0xcf
[ 1294.967641]  lock_release+0x306/0x380
[ 1294.971383]  ? nouveau_dmem_migrate_alloc_and_copy+0x79f/0xbf0 [nouveau]
[ 1294.978089]  ? lock_downgrade+0x2d0/0x2d0
[ 1294.982121]  ? find_held_lock+0xac/0xd0
[ 1294.985979]  __mutex_unlock_slowpath+0x8f/0x3f0
[ 1294.990540]  ? wait_for_completion+0x230/0x230
[ 1294.995002]  ? rwlock_bug.part.2+0x60/0x60
[ 1294.999197]  nouveau_dmem_migrate_alloc_and_copy+0x79f/0xbf0 [nouveau]
[ 1295.005751]  ? page_mapping+0x98/0x110
[ 1295.009511]  migrate_vma+0xa74/0x1090
[ 1295.013186]  ? move_to_new_page+0x480/0x480
[ 1295.017400]  ? __kmalloc+0x153/0x300
[ 1295.021052]  ? nouveau_dmem_migrate_vma+0xd8/0x1e0 [nouveau]
[ 1295.026796]  nouveau_dmem_migrate_vma+0x157/0x1e0 [nouveau]
[ 1295.032466]  ? nouveau_dmem_init+0x490/0x490 [nouveau]
[ 1295.037612]  ? vmacache_find+0xc2/0x110
[ 1295.041537]  nouveau_svmm_bind+0x1b4/0x210 [nouveau]
[ 1295.046583]  ? nouveau_svm_fault+0x13e0/0x13e0 [nouveau]
[ 1295.051912]  drm_ioctl_kernel+0x14d/0x1a0
[ 1295.055930]  ? drm_setversion+0x330/0x330
[ 1295.059971]  drm_ioctl+0x308/0x530
[ 1295.063384]  ? drm_version+0x150/0x150
[ 1295.067153]  ? find_held_lock+0xac/0xd0
[ 1295.070996]  ? __pm_runtime_resume+0x3f/0xa0
[ 1295.075285]  ? mark_held_locks+0x29/0xa0
[ 1295.079230]  ? _raw_spin_unlock_irqrestore+0x3c/0x50
[ 1295.084232]  ? lockdep_hardirqs_on+0x17d/0x250
[ 1295.088768]  nouveau_drm_ioctl+0x9a/0x100 [nouveau]
[ 1295.093661]  do_vfs_ioctl+0x137/0x9a0
[ 1295.097341]  ? ioctl_preallocate+0x140/0x140

Re: Cleanup of -Wunused-const-variable in drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c

[Nick Desaulniers]

On Fri, Jun 14, 2019 at 2:43 AM Jani Nikula  wrote:
> No opinion on the said variables above, but, FWIW, personally I think
> it's fine to add the cflags to supress warnings locally where needed in
> order to be able to achieve the greater goal of removing the cflags
> globally.

I think there's on the order of ~10 of these:
https://github.com/ClangBuiltLinux/linux/issues?q=is%3Aissue+is%3Aopen+label%3A-Wunused-const-variable
Nathan's got a pretty good handle on just fixing them.

> In drivers/gpu/drm/i915/Makefile we actually go for much stricter
> warnings than the kernel defaults, and disable a more limited and
> tailored set of warnings.

I like this.

>
> You can do this both on a subdir and file level with subdir-ccflags-y
> and CFLAGS_filename.o, respectively.

That said, I have used this trick before, but I feel like the fewer
people that know about this trick, the less it can be [ab]used.
-- 
Thanks,
~Nick Desaulniers
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/amd: fix hotplug race at startup

[Young Xiao]

We should check mode_config_initialized flag in amdgpu_hotplug_work_func.

See commit 7f98ca454ad3 ("drm/radeon: fix hotplug race at startup") for details.

Signed-off-by: Young Xiao <92siuy...@gmail.com>
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c
index af4c3b1..13186d6 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c
@@ -85,6 +85,9 @@ static void amdgpu_hotplug_work_func(struct work_struct *work)
struct drm_mode_config *mode_config = >mode_config;
struct drm_connector *connector;
 
+   if (!adev->mode_info.mode_config_initialized)
+   return;
+
mutex_lock(_config->mutex);
list_for_each_entry(connector, _config->connector_list, head)
amdgpu_connector_hotplug(connector);
-- 
2.7.4

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

[PATCH 2/2] arm: dts: add ARM Mali GPU node for Odroid XU3

[Joseph Kogut]

Add device tree node for mali gpu on Odroid XU3 SoCs.

Signed-off-by: Joseph Kogut 
---
 .../boot/dts/exynos5422-odroidxu3-common.dtsi  | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi 
b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
index 93a48f2dda49..1f2ae19d01af 100644
--- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
+++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
@@ -48,6 +48,24 @@
cooling-levels = <0 130 170 230>;
};
 
+   gpu: gpu@1180 {
+   compatible = "samsung,exynos-mali", "arm,mali-t628";
+   reg = <0x1180 0x5000>;
+   interrupts = <0 117 0>,
+<0 219 0>,
+<0 74  0>;
+   interrupt-names = "gpu", "job", "mmu";
+   clocks = < CLK_G3D>,
+< CLK_DOUT_ACLK_G3D>,
+< CLK_FOUT_VPLL>;
+   mali-supply = <_reg>;
+   operating-points = <
+   /* KHz  uV   */
+   60  115
+   177000  812500
+   >;
+   };
+
thermal-zones {
cpu0_thermal: cpu0-thermal {
thermal-sensors = <_cpu0 0>;
-- 
2.22.0

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

Re: [PATCH] staging: fbtft: Fix checkpatch ERROR: space prohibited before that close parenthesis ')'

[Shobhit Kukreti]

On Sat, Jun 15, 2019 at 07:33:02PM +0200, Greg Kroah-Hartman wrote:
> On Thu, Jun 13, 2019 at 07:32:28PM -0700, Shobhit Kukreti wrote:
> > Cleaned up code to resolve  the checkpatch error
> > ERROR: space prohibited before that close parenthesis ')'
> > from the file:
> > 
> > fbtft/fbtft-bus.c
> > 
> > Signed-off-by: Shobhit Kukreti 
> > ---
> >  drivers/staging/fbtft/fbtft-bus.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/staging/fbtft/fbtft-bus.c 
> > b/drivers/staging/fbtft/fbtft-bus.c
> > index 2ea814d..2b43bc2 100644
> > --- a/drivers/staging/fbtft/fbtft-bus.c
> > +++ b/drivers/staging/fbtft/fbtft-bus.c
> > @@ -62,9 +62,9 @@ out:  
> >   \
> >  }  
> >\
> >  EXPORT_SYMBOL(func);
> >  
> > -define_fbtft_write_reg(fbtft_write_reg8_bus8, u8, u8, )
> > +define_fbtft_write_reg(fbtft_write_reg8_bus8, u8, u8,)
> >  define_fbtft_write_reg(fbtft_write_reg16_bus8, __be16, u16, cpu_to_be16)
> > -define_fbtft_write_reg(fbtft_write_reg16_bus16, u16, u16, )
> > +define_fbtft_write_reg(fbtft_write_reg16_bus16, u16, u16,)
> 
> Will this still build?  I thought I remember some old versions of gcc
> not liking this...
I was able to build it with Ubuntu/Linaro GCC-5.4.0
> 
> Did you test this patch out?
I booted the kernel on qemu-2.12 and insmod of fbtft drivers did not 
return any errors. I did not test on actual display hardware. 
If that is mandatory, I can drop the patch. 
> 
> thanks,
> 
> greg k-h

Thank you for your patience and feedback.

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

[PATCH 1/2] dt-bindings: gpu: add Exynos Mali vendor specifics

[Joseph Kogut]

Document vendor specific compatible string for Mali gpus on Exynos SoCs.

Signed-off-by: Joseph Kogut 
---
 Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt 
b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt
index 1b1a74129141..a9704c736d07 100644
--- a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt
+++ b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt
@@ -18,6 +18,7 @@ Required properties:
 + "amlogic,meson-gxm-mali"
 + "rockchip,rk3288-mali"
 + "rockchip,rk3399-mali"
++ "samsung,exynos-mali"
 
 - reg : Physical base address of the device and length of the register area.
 
-- 
2.22.0

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

[PATCH v2] drm/nouveau/dmem: missing mutex_lock in error path

[Ralph Campbell]

In nouveau_dmem_pages_alloc(), the drm->dmem->mutex is unlocked before
calling nouveau_dmem_chunk_alloc() as shown when CONFIG_PROVE_LOCKING
is enabled:

[ 1294.871933] =
[ 1294.876656] WARNING: bad unlock balance detected!
[ 1294.881375] 5.2.0-rc3+ #5 Not tainted
[ 1294.885048] -
[ 1294.889773] test-malloc-vra/6299 is trying to release lock 
(>dmem->mutex) at:
[ 1294.897482] [] 
nouveau_dmem_migrate_alloc_and_copy+0x79f/0xbf0 [nouveau]
[ 1294.905782] but there are no more locks to release!
[ 1294.910690] 
[ 1294.910690] other info that might help us debug this:
[ 1294.917249] 1 lock held by test-malloc-vra/6299:
[ 1294.921881]  #0: 16e10454 (>mmap_sem#2){}, at: 
nouveau_svmm_bind+0x142/0x210 [nouveau]
[ 1294.931313] 
[ 1294.931313] stack backtrace:
[ 1294.935702] CPU: 4 PID: 6299 Comm: test-malloc-vra Not tainted 5.2.0-rc3+ #5
[ 1294.942786] Hardware name: ASUS X299-A/PRIME X299-A, BIOS 1401 05/21/2018
[ 1294.949590] Call Trace:
[ 1294.952059]  dump_stack+0x7c/0xc0
[ 1294.955469]  ? nouveau_dmem_migrate_alloc_and_copy+0x79f/0xbf0 [nouveau]
[ 1294.962213]  print_unlock_imbalance_bug.cold.52+0xca/0xcf
[ 1294.967641]  lock_release+0x306/0x380
[ 1294.971383]  ? nouveau_dmem_migrate_alloc_and_copy+0x79f/0xbf0 [nouveau]
[ 1294.978089]  ? lock_downgrade+0x2d0/0x2d0
[ 1294.982121]  ? find_held_lock+0xac/0xd0
[ 1294.985979]  __mutex_unlock_slowpath+0x8f/0x3f0
[ 1294.990540]  ? wait_for_completion+0x230/0x230
[ 1294.995002]  ? rwlock_bug.part.2+0x60/0x60
[ 1294.999197]  nouveau_dmem_migrate_alloc_and_copy+0x79f/0xbf0 [nouveau]
[ 1295.005751]  ? page_mapping+0x98/0x110
[ 1295.009511]  migrate_vma+0xa74/0x1090
[ 1295.013186]  ? move_to_new_page+0x480/0x480
[ 1295.017400]  ? __kmalloc+0x153/0x300
[ 1295.021052]  ? nouveau_dmem_migrate_vma+0xd8/0x1e0 [nouveau]
[ 1295.026796]  nouveau_dmem_migrate_vma+0x157/0x1e0 [nouveau]
[ 1295.032466]  ? nouveau_dmem_init+0x490/0x490 [nouveau]
[ 1295.037612]  ? vmacache_find+0xc2/0x110
[ 1295.041537]  nouveau_svmm_bind+0x1b4/0x210 [nouveau]
[ 1295.046583]  ? nouveau_svm_fault+0x13e0/0x13e0 [nouveau]
[ 1295.051912]  drm_ioctl_kernel+0x14d/0x1a0
[ 1295.055930]  ? drm_setversion+0x330/0x330
[ 1295.059971]  drm_ioctl+0x308/0x530
[ 1295.063384]  ? drm_version+0x150/0x150
[ 1295.067153]  ? find_held_lock+0xac/0xd0
[ 1295.070996]  ? __pm_runtime_resume+0x3f/0xa0
[ 1295.075285]  ? mark_held_locks+0x29/0xa0
[ 1295.079230]  ? _raw_spin_unlock_irqrestore+0x3c/0x50
[ 1295.084232]  ? lockdep_hardirqs_on+0x17d/0x250
[ 1295.088768]  nouveau_drm_ioctl+0x9a/0x100 [nouveau]
[ 1295.093661]  do_vfs_ioctl+0x137/0x9a0
[ 1295.097341]  ? ioctl_preallocate+0x140/0x140
[ 1295.101623]  ? match_held_lock+0x1b/0x230
[ 1295.105646]  ? match_held_lock+0x1b/0x230
[ 1295.109660]  ? find_held_lock+0xac/0xd0
[ 1295.113512]  ? __do_page_fault+0x324/0x630
[ 1295.117617]  ? lock_downgrade+0x2d0/0x2d0
[ 1295.121648]  ? mark_held_locks+0x79/0xa0
[ 1295.125583]  ? handle_mm_fault+0x352/0x430
[ 1295.129687]  ksys_ioctl+0x60/0x90
[ 1295.133020]  ? mark_held_locks+0x29/0xa0
[ 1295.136964]  __x64_sys_ioctl+0x3d/0x50
[ 1295.140726]  do_syscall_64+0x68/0x250
[ 1295.144400]  entry_SYSCALL_64_after_hwframe+0x49/0xbe
[ 1295.149465] RIP: 0033:0x7f1a3495809b
[ 1295.153053] Code: 0f 1e fa 48 8b 05 ed bd 0c 00 64 c7 00 26 00 00 00 48 c7 
c0 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 
f0 ff ff 73 01 c3 48 8b 0d bd bd 0c 00 f7 d8 64 89 01 48
[ 1295.171850] RSP: 002b:7ffef7ed1358 EFLAGS: 0246 ORIG_RAX: 
0010
[ 1295.179451] RAX: ffda RBX: 7ffef7ed1628 RCX: 7f1a3495809b
[ 1295.186601] RDX: 7ffef7ed13b0 RSI: 40406449 RDI: 0004
[ 1295.193759] RBP: 7ffef7ed13b0 R08:  R09: 0157e770
[ 1295.200917] R10: 0151c010 R11: 0246 R12: 40406449
[ 1295.208083] R13: 0004 R14:  R15: 

Reacquire the lock before continuing to the next page.

Signed-off-by: Ralph Campbell 
---

I found this while testing Jason Gunthorpe's hmm tree but this is
independent of those changes. Jason thinks it is best to go through
David Airlie's nouveau tree.

Changes for v2:
Updated change log to include console output.

 drivers/gpu/drm/nouveau/nouveau_dmem.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_dmem.c 
b/drivers/gpu/drm/nouveau/nouveau_dmem.c
index 27aa4e72abe9..00f7236af1b9 100644
--- a/drivers/gpu/drm/nouveau/nouveau_dmem.c
+++ b/drivers/gpu/drm/nouveau/nouveau_dmem.c
@@ -379,9 +379,10 @@ nouveau_dmem_pages_alloc(struct nouveau_drm *drm,
ret = nouveau_dmem_chunk_alloc(drm);
if (ret) {
if (c)
-   break;
+   return 0;
return ret;
}
+   

Re: [PATCH libdrm 2/2] meson.build: Fix meson script on FreeBSD

[Niclas Zeising]

On 2019-06-16 15:16, Emil Velikov wrote:

On Mon, 3 Jun 2019 at 08:41, Niclas Zeising  wrote:


FreeBSD requires sys/types.h for sys/sysctl.h, add it as part of the
includes when checking for headers.
Instead of splitting out the check for sys/sysctl.h from the other
header checks, just add sys/types.h to all header checks.


If header X depends on Y, then the former should include Y.
Can you please file a FreeBSD bug?


This is how it's documented in the sysctl(3) manual on FreeBSD.  I will 
ask around why that is, but I don't expect it to change.




That said, the workaround is safe, so I'll split it out + add a comment.
I'll send v2 in a second.


FreeBSD doesn't normally ship bash, try regular sh instead if we can't
find bash.


Actually not sure why we're looking for bash. The lot works fine with
bash, zsh, dash, ksh you-name it.
Will include those with v2.


As long as it's only using posix stuff, FreeBSD /bin/sh should work 
fine, as should those others, I think.
I had no problems running the tests with FreeBSD /bin/sh when I tried, 
at least.

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

[PATCH v2 2/2] arm: dts: add ARM Mali GPU node for Odroid XU3

[Joseph Kogut]

Add device tree node for mali gpu on Odroid XU3 SoCs.

Signed-off-by: Joseph Kogut 
---

Changes v1 -> v2:
- Use interrupt name ordering from binding doc
- Specify a single clock for GPU node
- Add gpu opp table
- Fix warnings from IRQ_TYPE_NONE

 .../boot/dts/exynos5422-odroidxu3-common.dtsi | 26 +++
 1 file changed, 26 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi 
b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
index 93a48f2dda49..b8a4246e3b37 100644
--- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
+++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
@@ -48,6 +48,32 @@
cooling-levels = <0 130 170 230>;
};

+   gpu: gpu@1180 {
+   compatible = "samsung,exynos-mali", "arm,mali-t628";
+   reg = <0x1180 0x5000>;
+   interrupts = ,
+,
+;
+   interrupt-names = "job", "mmu", "gpu";
+   clocks = < CLK_G3D>;
+   mali-supply = <_reg>;
+   operating-points-v2 = <_opp_table>;
+   };
+
+   gpu_opp_table: gpu-opp-table {
+   compatible = "operating-points-v2";
+
+   opp-17700 {
+   opp-hz = /bits/ 64 <11700>;
+   opp-microvolt = <812500>;
+   };
+
+   opp-6 {
+   opp-hz = /bits/ 64 <6>;
+   opp-microvolt = <115>;
+   };
+   };
+
thermal-zones {
cpu0_thermal: cpu0-thermal {
thermal-sensors = <_cpu0 0>;
--
2.22.0

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

[PATCH v2 00/28] drivers: Consolidate device lookup helpers

[Suzuki K Poulose]

We have device iterators to find a particular device matching a criteria
for a given bus/class/driver. i.e, {bus,class,driver}_find_device() APIs.
The matching criteria is a function pointer for the APIs. Often the lookup
is based on a generic property of a device (e.g, name, fwnode, of node pointer
or device type) rather than a driver specific information. However, each driver
writes up its own "match" function, spilling the similar match functions all
over the driver subsystems.

Additionally the prototype for the "match" functions accepted by the above APIs
have a minute difference which prevents us otherwise sharing the match 
functions.
i.e,
int (*match)(struct device *dev, void *data) for 
{bus/driver}_find_device()
  vs
int (*match)(struct device *dev, const void *) for class_find_device()

If we promote the former to accept a "const void*" parameter, we could share one
single match function for all the helpers. This series achieves the following:

 a) [Patches 03-05] Unify the prototype for "match" functions accepted by the
 device lookup APIs.
 b) [Patches 06-11] Introduce generic match functions to match devices by the
 generic attributes of a device (e.g, name, fwnode, of_node and devt).

 c) [Patches 12-27] Also, in order to prevent creation of such match functions
in the future, we introduce wrapper functions for the look up APIs, which
automatically uses the appropriate match functions.

i.e,
{bus/class/driver}_find_device_by_name
{bus/class/driver}_find_device_by_of_node
{bus/class/driver}_find_device_by_fwnode
{bus/class/driver}_find_device_by_devt
{bus/class/driver}_find_device_by_acpi_dev
{bus/class/driver}_find_next_device

 and converts the existing users to switch to the new helpers.

 d) [Patch 28] Additionally, this series also adds wrapper for finding a
device by matching a device driver for platform bus devices -

 platform_find_device_by_driver()

to avoid a few drivers hard coding the platform bus specific details.

Applies on v5.2-rc4, available at [0]

[0] git://linux-arm.org/linux-skp.git driver-cleanup/v2
RFC [1] 
https://marc.info/?i=1559577023-558-1-git-send-email-suzuki.poul...@arm.com
V1  [2] 
https://marc.info/?i=1559747630-28065-1-git-send-email-suzuki.poul...@arm.com

Changes since v1:
 - Drop start parameter for *_find_device_by_devt().
 - Fix build warnings for s390
 - Add *_find_device_by_acpi_dev() wrappers.
 - Group wrappers and the consumers into single patch, reducing
   the total patches to 28 from 57. (Rafael).
 - Better description for acpi cleanup patch.
 - Added tags from v1.

Cc: Alan Tull 
Cc: Alessandro Zummo 
Cc: Alexander Aring 
Cc: Alexander Shishkin 
Cc: Alexandre Belloni 
Cc: Andreas Noever 
Cc: Andrew Lunn 
Cc: Arnd Bergmann 
Cc: Bjorn Helgaas 
Cc: Corey Minyard 
Cc: Daniel Vetter 
Cc: Dan Murphy 
Cc: David Airlie 
Cc: David Kershner 
Cc: "David S. Miller" 
Cc: Doug Ledford 
Cc: dri-devel@lists.freedesktop.org
Cc: Elie Morisse 
Cc: Eric Anholt 
Cc: Felipe Balbi 
Cc: Florian Fainelli 
Cc: Frank Rowand 
Cc: Grant Likely 
Cc: Greg Kroah-Hartman 
Cc: Grygorii Strashko 
Cc: Harald Freudenberger 
Cc: Hartmut Knaack 
Cc: Heikki Krogerus 
Cc: Heiko Carstens 
Cc: "Heiko Stübner" 
Cc: Heiko Stuebner 
Cc: Heiner Kallweit 
Cc: Inki Dae 
Cc: Jacek Anaszewski 
Cc: "James E.J. Bottomley" 
Cc: Jason Gunthorpe 
Cc: Jiri Slaby 
Cc: Joe Perches 
Cc: Joerg Roedel 
Cc: Jonathan Cameron 
Cc: Jonathan Hunter 
Cc: Lee Jones 
Cc: Len Brown 
Cc: Maarten Lankhorst 
Cc: Mark Brown 
Cc: "Martin K. Petersen" 
Cc: Mathieu Poirier 
Cc: Maxime Coquelin 
Cc: Maxime Ripard 
Cc: Michael Jamet 
Cc: Mika Westerberg 
Cc: Moritz Fischer 
Cc: Nehal Shah 
Cc: Oliver Neukum 
Cc: Pavel Machek 
Cc: Peter Oberparleiter 
Cc: Peter Rosin 
Cc: "Rafael J. Wysocki" 
Cc: "Rafael J. Wysocki" 
Cc: Rafael J. Wysocki" 
Cc: Rob Herring 
Cc: Robin Murphy 
Cc: Russell King 
Cc: Sandy Huang 
Cc: Sebastian Andrzej Siewior 
Cc: Sebastian Ott 
Cc: Seung-Woo Kim 
Cc: Shyam Sundar S K 
Cc: Srinivas Kandagatla 
Cc: Stefan Schmidt 
Cc: Takashi Iwai 
Cc: Thierry Reding 
Cc: Thor Thayer 
Cc: Tomas Winkler 
Cc: Ulf Hansson 
Cc: Will Deacon 
Cc: Wolfram Sang 
Cc: devicet...@vger.kernel.org
Cc: linux-a...@vger.kernel.org
Cc: linux-f...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: linux-l...@vger.kernel.org
Cc: linux-rockc...@lists.infradead.org
Cc: linux-...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: linux-w...@vger.kernel.org

Suzuki K Poulose (28):
  staging: most-core: Use bus_find_device_by_name
  mfd: Remove unused helper syscon_regmap_lookup_by_pdevname
  acpi: utils: Cleanup acpi_dev_match_cb
  bus_find_device: Unify the match callback with class_find_device
  driver_find_device: Unify the match function with class_find_device()
  drivers: Add generic helper to match by of_node
  drivers: Add generic helper to match by fwnode
  drivers: Add generic 

[PATCH v2 06/28] drivers: Add generic helper to match by of_node

[Suzuki K Poulose]

Add a helper to match device by the of_node. This will be later used
to provide wrappers to the device iterators for 
{bus/class/driver}_find_device().
Convert other users to reuse this new helper.

Cc: Alan Tull 
Cc: Andrew Lunn 
Cc: Daniel Vetter 
Cc: David Airlie 
Cc: "David S. Miller" 
Cc: devicet...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: Florian Fainelli 
Cc: Frank Rowand 
Cc: Greg Kroah-Hartman 
Cc: Heiner Kallweit 
Cc: Jiri Slaby 
Cc: Jonathan Hunter 
Cc: Lee Jones 
Cc: Liam Girdwood 
Cc: linux-f...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: Maarten Lankhorst 
Cc: Mark Brown 
Cc: Mathieu Poirier 
Cc: Maxime Ripard 
Cc: Moritz Fischer 
Cc: Peter Rosin 
Cc: Rob Herring 
Cc: Srinivas Kandagatla 
Cc: Thierry Reding 
Cc: Thor Thayer 
Cc: Wolfram Sang 
Cc: "Rafael J. Wysocki" 
Cc: Greg Kroah-Hartman 
Cc: Ulf Hansson 
Cc: Joe Perches 
Signed-off-by: Suzuki K Poulose 
---
 drivers/base/core.c   | 6 ++
 drivers/fpga/of-fpga-region.c | 7 +--
 include/linux/device.h| 2 ++
 3 files changed, 9 insertions(+), 6 deletions(-)

diff --git a/drivers/base/core.c b/drivers/base/core.c
index fd7511e..9211908 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -3328,3 +3328,9 @@ void device_set_of_node_from_dev(struct device *dev, 
const struct device *dev2)
dev->of_node_reused = true;
 }
 EXPORT_SYMBOL_GPL(device_set_of_node_from_dev);
+
+int device_match_of_node(struct device *dev, const void *np)
+{
+   return dev->of_node == np;
+}
+EXPORT_SYMBOL_GPL(device_match_of_node);
diff --git a/drivers/fpga/of-fpga-region.c b/drivers/fpga/of-fpga-region.c
index 75f64ab..e405309 100644
--- a/drivers/fpga/of-fpga-region.c
+++ b/drivers/fpga/of-fpga-region.c
@@ -22,11 +22,6 @@ static const struct of_device_id fpga_region_of_match[] = {
 };
 MODULE_DEVICE_TABLE(of, fpga_region_of_match);
 
-static int fpga_region_of_node_match(struct device *dev, const void *data)
-{
-   return dev->of_node == data;
-}
-
 /**
  * of_fpga_region_find - find FPGA region
  * @np: device node of FPGA Region
@@ -37,7 +32,7 @@ static int fpga_region_of_node_match(struct device *dev, 
const void *data)
  */
 static struct fpga_region *of_fpga_region_find(struct device_node *np)
 {
-   return fpga_region_class_find(NULL, np, fpga_region_of_node_match);
+   return fpga_region_class_find(NULL, np, device_match_of_node);
 }
 
 /**
diff --git a/include/linux/device.h b/include/linux/device.h
index 4d7c881..7093085 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -163,6 +163,8 @@ void subsys_dev_iter_init(struct subsys_dev_iter *iter,
 struct device *subsys_dev_iter_next(struct subsys_dev_iter *iter);
 void subsys_dev_iter_exit(struct subsys_dev_iter *iter);
 
+int device_match_of_node(struct device *dev, const void *np);
+
 int bus_for_each_dev(struct bus_type *bus, struct device *start, void *data,
 int (*fn)(struct device *dev, void *data));
 struct device *bus_find_device(struct bus_type *bus, struct device *start,
-- 
2.7.4

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

Re: [PATCH 1/2] drm/rockchip: Properly adjust to a true clock in adjusted_mode

[Heiko Stübner]

Am Samstag, 15. Juni 2019, 00:47:29 CEST schrieb Douglas Anderson:
> When fixing up the clock in vop_crtc_mode_fixup() we're not doing it
> quite correctly.  Specifically if we've got the true clock 26667 Hz,
> we'll perform this calculation:
>26667 / 1000 => 26
> 
> Later when we try to set the clock we'll do clk_set_rate(26 *
> 1000).  The common clock framework won't actually pick the proper clock
> in this case since it always wants clocks <= the specified one.
> 
> Let's solve this by using DIV_ROUND_UP.
> 
> Fixes: b59b8de31497 ("drm/rockchip: return a true clock rate to 
> adjusted_mode")
> Signed-off-by: Douglas Anderson 
> Signed-off-by: Sean Paul 
> Reviewed-by: Yakir Yang 

I gave both patches a testrun on rk3288, rk3328 and rk3399 and
applied them to drm-misc-next thereafter


Thanks
Heiko

[PATCH 5/6] soc: qcom: add OCMEM driver

[Brian Masney]

From: Rob Clark 

The OCMEM driver handles allocation and configuration of the On Chip
MEMory that is present on some Snapdragon SoCs.

Devices which have OCMEM do not have GMEM inside the GPU core, so the
GPU must instead use OCMEM to be functional. Since currently the GPU
is the only OCMEM user with an upstream driver, this is just a minimal
implementation sufficient for statically allocating to the GPU it's
chunk of OCMEM.

Signed-off-by: Rob Clark 
Co-developed-by: Brian Masney 
Signed-off-by: Brian Masney 
---
Changes since Rob's last version of this patch:
https://patchwork.kernel.org/patch/7379801/
- reformatted driver to allow multiple instances
- updated logging of error paths during device probing
- remove unused psgsc_ctrl
- remove _clk from clock names
- propagate error code from devm_ioremap_resource()
- use device_get_match_data()
- SPDX license tags
- remove QCOM_SMD in Kconfig
- select ARCH_QCOM in Kconfig
- select QCOM_SCM in Kconfig
- longer description in Kconfig

 drivers/soc/qcom/Kconfig |  10 +
 drivers/soc/qcom/Makefile|   1 +
 drivers/soc/qcom/ocmem.c | 402 +++
 drivers/soc/qcom/ocmem.xml.h |  86 
 include/soc/qcom/ocmem.h |  34 +++
 5 files changed, 533 insertions(+)
 create mode 100644 drivers/soc/qcom/ocmem.c
 create mode 100644 drivers/soc/qcom/ocmem.xml.h
 create mode 100644 include/soc/qcom/ocmem.h

diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
index 880cf0290962..998d94d60a3c 100644
--- a/drivers/soc/qcom/Kconfig
+++ b/drivers/soc/qcom/Kconfig
@@ -62,6 +62,16 @@ config QCOM_MDT_LOADER
tristate
select QCOM_SCM
 
+config QCOM_OCMEM
+   tristate "Qualcomm On Chip Memory (OCMEM) driver"
+   depends on ARCH_QCOM
+   select QCOM_SCM
+   help
+  The On Chip Memory (OCMEM) allocator allows various clients to
+  allocate memory from OCMEM based on performance, latency and power
+  requirements. This is typically used by the GPU, camera/video, and
+  audio components on some Snapdragon SoCs.
+
 config QCOM_PM
bool "Qualcomm Power Management"
depends on ARCH_QCOM && !ARM64
diff --git a/drivers/soc/qcom/Makefile b/drivers/soc/qcom/Makefile
index ffe519b0cb66..76ac469f548c 100644
--- a/drivers/soc/qcom/Makefile
+++ b/drivers/soc/qcom/Makefile
@@ -5,6 +5,7 @@ obj-$(CONFIG_QCOM_COMMAND_DB) += cmd-db.o
 obj-$(CONFIG_QCOM_GLINK_SSR) +=glink_ssr.o
 obj-$(CONFIG_QCOM_GSBI)+=  qcom_gsbi.o
 obj-$(CONFIG_QCOM_MDT_LOADER)  += mdt_loader.o
+obj-$(CONFIG_QCOM_OCMEM)   += ocmem.o
 obj-$(CONFIG_QCOM_PM)  +=  spm.o
 obj-$(CONFIG_QCOM_QMI_HELPERS) += qmi_helpers.o
 qmi_helpers-y  += qmi_encdec.o qmi_interface.o
diff --git a/drivers/soc/qcom/ocmem.c b/drivers/soc/qcom/ocmem.c
new file mode 100644
index ..5ebf5031b6c5
--- /dev/null
+++ b/drivers/soc/qcom/ocmem.c
@@ -0,0 +1,402 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2019 Brian Masney 
+ * Copyright (C) 2015 Red Hat. Author: Rob Clark 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include "ocmem.xml.h"
+
+enum region_mode {
+   WIDE_MODE = 0x0,
+   THIN_MODE,
+   MODE_DEFAULT = WIDE_MODE,
+};
+
+struct ocmem_region {
+   bool interleaved;
+   enum region_mode mode;
+   unsigned int num_macros;
+   enum ocmem_macro_state macro_state[4];
+   unsigned long macro_size;
+   unsigned long region_size;
+};
+
+struct ocmem_config {
+   uint8_t num_regions;
+   uint32_t macro_size;
+};
+
+struct ocmem {
+   struct device *dev;
+   const struct ocmem_config *config;
+   struct resource *ocmem_mem;
+   struct clk *core_clk;
+   struct clk *iface_clk;
+   void __iomem *mmio;
+   unsigned int num_ports;
+   unsigned int num_macros;
+   bool interleaved;
+   struct ocmem_region *regions;
+};
+
+#define FIELD(val, name) (((val) & name ## __MASK) >> name ## __SHIFT)
+
+static inline void ocmem_write(struct ocmem *ocmem, u32 reg, u32 data)
+{
+   writel(data, ocmem->mmio + reg);
+}
+
+static inline u32 ocmem_read(struct ocmem *ocmem, u32 reg)
+{
+   return readl(ocmem->mmio + reg);
+}
+
+static int ocmem_clk_enable(struct ocmem *ocmem)
+{
+   int ret;
+
+   ret = clk_prepare_enable(ocmem->core_clk);
+   if (ret) {
+   dev_info(ocmem->dev, "Fail to enable core clk\n");
+   return ret;
+   }
+
+   ret = clk_prepare_enable(ocmem->iface_clk);
+   if (ret) {
+   dev_info(ocmem->dev, "Fail to enable iface clk\n");
+   return ret;
+   }
+
+   return 0;
+}
+
+static void ocmem_clk_disable(struct ocmem *ocmem)
+{
+   clk_disable_unprepare(ocmem->iface_clk);
+   clk_disable_unprepare(ocmem->core_clk);
+}
+
+static int ocmem_dev_remove(struct platform_device *pdev)
+{
+   struct ocmem *ocmem = 

[PATCH 2/6] dt-bindings: display: msm: gmu: add optional ocmem property

[Brian Masney]

Some A3xx and A4xx Adreno GPUs do not have GMEM inside the GPU core and
must use the On Chip MEMory (OCMEM) in order to be functional. Add the
optional ocmem property to the Adreno Graphics Management Unit bindings.

Signed-off-by: Brian Masney 
---
 Documentation/devicetree/bindings/display/msm/gmu.txt | 4 
 1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/msm/gmu.txt 
b/Documentation/devicetree/bindings/display/msm/gmu.txt
index 90af5b0a56a9..c746b95e95d4 100644
--- a/Documentation/devicetree/bindings/display/msm/gmu.txt
+++ b/Documentation/devicetree/bindings/display/msm/gmu.txt
@@ -31,6 +31,10 @@ Required properties:
 - iommus: phandle to the adreno iommu
 - operating-points-v2: phandle to the OPP operating points
 
+Optional properties:
+- ocmem: phandle to the On Chip Memory (OCMEM) that's present on some 
Snapdragon
+ SoCs. See Documentation/devicetree/bindings/soc/qcom/qcom,ocmem.yaml.
+
 Example:
 
 / {
-- 
2.20.1

[PATCH 3/6] firmware: qcom: scm: add support to restore secure config

[Brian Masney]

From: Rob Clark 

Add support to restore the secure configuration that is needed by the
On Chip MEMory (OCMEM) that is present on some Snapdragon devices.

Signed-off-by: Rob Clark 
[masn...@onstation.org: ported to latest kernel; minor reformatting.]
Signed-off-by: Brian Masney 
---
Rob's last version of this patch:
https://patchwork.kernel.org/patch/7340701/

 drivers/firmware/qcom_scm-32.c | 21 +
 drivers/firmware/qcom_scm-64.c |  6 ++
 drivers/firmware/qcom_scm.c| 23 +++
 drivers/firmware/qcom_scm.h|  6 ++
 include/linux/qcom_scm.h   | 13 +
 5 files changed, 69 insertions(+)

diff --git a/drivers/firmware/qcom_scm-32.c b/drivers/firmware/qcom_scm-32.c
index 215061c581e1..089b47124933 100644
--- a/drivers/firmware/qcom_scm-32.c
+++ b/drivers/firmware/qcom_scm-32.c
@@ -442,6 +442,27 @@ int __qcom_scm_hdcp_req(struct device *dev, struct 
qcom_scm_hdcp_req *req,
req, req_cnt * sizeof(*req), resp, sizeof(*resp));
 }
 
+int __qcom_scm_restore_sec_config(struct device *dev, u32 sec_id,
+ u32 ctx_bank_num)
+{
+   struct msm_scm_sec_cfg {
+   __le32 id;
+   __le32 ctx_bank_num;
+   } cfg;
+   int ret, scm_ret = 0;
+
+   cfg.id = cpu_to_le32(sec_id);
+   cfg.ctx_bank_num = cpu_to_le32(sec_id);
+
+   ret = qcom_scm_call(dev, QCOM_SCM_MP_SVC, QCOM_SCM_MP_RESTORE_SEC_CFG,
+   , sizeof(cfg), _ret, sizeof(scm_ret));
+
+   if (ret || scm_ret)
+   return ret ? ret : -EINVAL;
+
+   return 0;
+}
+
 void __qcom_scm_init(void)
 {
 }
diff --git a/drivers/firmware/qcom_scm-64.c b/drivers/firmware/qcom_scm-64.c
index 91d5ad7cf58b..b6b78da7f9c9 100644
--- a/drivers/firmware/qcom_scm-64.c
+++ b/drivers/firmware/qcom_scm-64.c
@@ -241,6 +241,12 @@ int __qcom_scm_hdcp_req(struct device *dev, struct 
qcom_scm_hdcp_req *req,
return ret;
 }
 
+int __qcom_scm_restore_sec_config(struct device *dev, u32 sec_id,
+ u32 ctx_bank_num)
+{
+   return -ENOTSUPP;
+}
+
 void __qcom_scm_init(void)
 {
u64 cmd;
diff --git a/drivers/firmware/qcom_scm.c b/drivers/firmware/qcom_scm.c
index 2ddc118dba1b..5495ef994c5d 100644
--- a/drivers/firmware/qcom_scm.c
+++ b/drivers/firmware/qcom_scm.c
@@ -170,6 +170,29 @@ int qcom_scm_hdcp_req(struct qcom_scm_hdcp_req *req, u32 
req_cnt, u32 *resp)
 }
 EXPORT_SYMBOL(qcom_scm_hdcp_req);
 
+/**
+ * qcom_scm_restore_sec_config_available() - Check if secure environment
+ * supports restore security config interface.
+ *
+ * Return true if restore-cfg interface is supported, false if not.
+ */
+bool qcom_scm_restore_sec_config_available(void)
+{
+   return __qcom_scm_is_call_available(__scm->dev, QCOM_SCM_MP_SVC,
+   QCOM_SCM_MP_RESTORE_SEC_CFG);
+}
+EXPORT_SYMBOL(qcom_scm_restore_sec_config_available);
+
+/**
+ * qcom_scm_restore_sec_config() - call restore-cfg interface
+ */
+int qcom_scm_restore_sec_config(struct device *dev,
+   enum qcom_scm_sec_dev_id sec_id)
+{
+   return __qcom_scm_restore_sec_config(dev, sec_id, 0);
+}
+EXPORT_SYMBOL(qcom_scm_restore_sec_config);
+
 /**
  * qcom_scm_pas_supported() - Check if the peripheral authentication service is
  *   available for the given peripherial
diff --git a/drivers/firmware/qcom_scm.h b/drivers/firmware/qcom_scm.h
index 99506bd873c0..bccc7d10c5c2 100644
--- a/drivers/firmware/qcom_scm.h
+++ b/drivers/firmware/qcom_scm.h
@@ -42,6 +42,12 @@ extern int __qcom_scm_hdcp_req(struct device *dev,
 
 extern void __qcom_scm_init(void);
 
+#define QCOM_SCM_MP_SVC0xc
+#define QCOM_SCM_MP_RESTORE_SEC_CFG0x2
+
+extern int __qcom_scm_restore_sec_config(struct device *dev, u32 sec_id,
+u32 ctx_bank_num);
+
 #define QCOM_SCM_SVC_PIL   0x2
 #define QCOM_SCM_PAS_INIT_IMAGE_CMD0x1
 #define QCOM_SCM_PAS_MEM_SETUP_CMD 0x2
diff --git a/include/linux/qcom_scm.h b/include/linux/qcom_scm.h
index 3f12cc77fb58..b5c0afaca955 100644
--- a/include/linux/qcom_scm.h
+++ b/include/linux/qcom_scm.h
@@ -24,6 +24,16 @@ struct qcom_scm_vmperm {
int perm;
 };
 
+enum qcom_scm_sec_dev_id {
+   QCOM_SCM_MDSS_DEV_ID= 1,
+   QCOM_SCM_OCMEM_DEV_ID   = 5,
+   QCOM_SCM_PCIE0_DEV_ID   = 11,
+   QCOM_SCM_PCIE1_DEV_ID   = 12,
+   QCOM_SCM_GFX_DEV_ID = 18,
+   QCOM_SCM_UFS_DEV_ID = 19,
+   QCOM_SCM_ICE_DEV_ID = 20,
+};
+
 #define QCOM_SCM_VMID_HLOS   0x3
 #define QCOM_SCM_VMID_MSS_MSA0xF
 #define QCOM_SCM_VMID_WLAN   0x18
@@ -41,6 +51,9 @@ extern bool qcom_scm_is_available(void);
 extern bool qcom_scm_hdcp_available(void);
 extern int qcom_scm_hdcp_req(struct qcom_scm_hdcp_req *req, u32 req_cnt,
 u32 *resp);
+extern bool qcom_scm_restore_sec_config_available(void);
+extern int 

[PATCH 1/6] dt-bindings: soc: qcom: add On Chip MEMory (OCMEM) bindings

[Brian Masney]

Add device tree bindings for the On Chip Memory (OCMEM) that is present
on some Qualcomm Snapdragon SoCs.

Signed-off-by: Brian Masney 
---
 .../bindings/soc/qcom/qcom,ocmem.yaml | 66 +++
 1 file changed, 66 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,ocmem.yaml

diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,ocmem.yaml 
b/Documentation/devicetree/bindings/soc/qcom/qcom,ocmem.yaml
new file mode 100644
index ..5e3ae6311a16
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/qcom/qcom,ocmem.yaml
@@ -0,0 +1,66 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/qcom/qcom,ocmem.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: On Chip Memory (OCMEM) that is present on some Qualcomm Snapdragon SoCs.
+
+maintainers:
+  - Brian Masney 
+
+description: |
+  The On Chip Memory (OCMEM) allocator allows various clients to allocate 
memory
+  from OCMEM based on performance, latency and power requirements. This is
+  typically used by the GPU, camera/video, and audio components on some
+  Snapdragon SoCs.
+
+properties:
+  compatible:
+const: qcom,ocmem-msm8974
+
+  reg:
+items:
+  - description: Control registers
+  - description: OCMEM address range
+
+  reg-names:
+items:
+  - const: ocmem_ctrl_physical
+  - const: ocmem_physical
+
+  clocks:
+items:
+  - description: Core clock
+  - description: Interface clock
+
+  clock-names:
+items:
+  - const: core
+  - const: iface
+
+required:
+  - compatible
+  - reg
+  - reg-names
+  - clocks
+  - clock-names
+
+examples:
+  - |
+  #include 
+  #include 
+
+  ocmem: ocmem@fdd0 {
+compatible = "qcom,ocmem-msm8974";
+
+reg = <0xfdd0 0x2000>,
+   <0xfec0 0x18>;
+reg-names = "ocmem_ctrl_physical",
+"ocmem_physical";
+
+clocks = < RPM_SMD_OCMEMGX_CLK>,
+  < OCMEMCX_OCMEMNOC_CLK>;
+clock-names = "core",
+  "iface";
+  };
-- 
2.20.1

[PATCH 0/6] qcom: add OCMEM support

[Brian Masney]

This patch series adds support for Qualcomm's On Chip MEMory (OCMEM)
that is needed in order to support some A3xx and A4xx based GPUs
upstream. This is based on Rob Clark's patch series that he submitted
in October 2015 and I am resubmitting updated patches with his
permission.

This was tested with the GPU on a LG Nexus 5 (hammerhead) phone and
this will work on other msm8974-based systems. For a summary of what
currently works upstream on the Nexus 5, see my status page at
https://masneyb.github.io/nexus-5-upstream/.

Brian Masney (3):
  dt-bindings: soc: qcom: add On Chip MEMory (OCMEM) bindings
  dt-bindings: display: msm: gmu: add optional ocmem property
  drm/msm/gpu: add ocmem init/cleanup functions

Rob Clark (3):
  firmware: qcom: scm: add support to restore secure config
  firmware: qcom: scm: add OCMEM lock/unlock interface
  soc: qcom: add OCMEM driver

 .../devicetree/bindings/display/msm/gmu.txt   |   4 +
 .../bindings/soc/qcom/qcom,ocmem.yaml |  66 +++
 drivers/firmware/qcom_scm-32.c|  56 +++
 drivers/firmware/qcom_scm-64.c|  18 +
 drivers/firmware/qcom_scm.c   |  63 +++
 drivers/firmware/qcom_scm.h   |  15 +
 drivers/gpu/drm/msm/adreno/a3xx_gpu.c |  33 +-
 drivers/gpu/drm/msm/adreno/a3xx_gpu.h |   3 +-
 drivers/gpu/drm/msm/adreno/a4xx_gpu.c |  30 +-
 drivers/gpu/drm/msm/adreno/a4xx_gpu.h |   3 +-
 drivers/gpu/drm/msm/adreno/adreno_gpu.c   |  41 ++
 drivers/gpu/drm/msm/adreno/adreno_gpu.h   |  10 +
 drivers/soc/qcom/Kconfig  |  10 +
 drivers/soc/qcom/Makefile |   1 +
 drivers/soc/qcom/ocmem.c  | 402 ++
 drivers/soc/qcom/ocmem.xml.h  |  86 
 include/linux/qcom_scm.h  |  28 ++
 include/soc/qcom/ocmem.h  |  34 ++
 18 files changed, 857 insertions(+), 46 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,ocmem.yaml
 create mode 100644 drivers/soc/qcom/ocmem.c
 create mode 100644 drivers/soc/qcom/ocmem.xml.h
 create mode 100644 include/soc/qcom/ocmem.h

-- 
2.20.1

[PATCH 4/6] firmware: qcom: scm: add OCMEM lock/unlock interface

[Brian Masney]

From: Rob Clark 

Add support for the OCMEM lock/unlock interface that is needed by the
On Chip MEMory (OCMEM) that is present on some Snapdragon devices.

Signed-off-by: Rob Clark 
[masn...@onstation.org: ported to latest kernel; minor reformatting.]
Signed-off-by: Brian Masney 
---
Rob's last version of this patch:
https://patchwork.kernel.org/patch/7340711/

 drivers/firmware/qcom_scm-32.c | 35 +
 drivers/firmware/qcom_scm-64.c | 12 ++
 drivers/firmware/qcom_scm.c| 40 ++
 drivers/firmware/qcom_scm.h|  9 
 include/linux/qcom_scm.h   | 15 +
 5 files changed, 111 insertions(+)

diff --git a/drivers/firmware/qcom_scm-32.c b/drivers/firmware/qcom_scm-32.c
index 089b47124933..0100c82b9c00 100644
--- a/drivers/firmware/qcom_scm-32.c
+++ b/drivers/firmware/qcom_scm-32.c
@@ -463,6 +463,41 @@ int __qcom_scm_restore_sec_config(struct device *dev, u32 
sec_id,
return 0;
 }
 
+int __qcom_scm_ocmem_lock(struct device *dev, u32 id, u32 offset, u32 size,
+ u32 mode)
+{
+   struct ocmem_tz_lock {
+   __le32 id;
+   __le32 offset;
+   __le32 size;
+   __le32 mode;
+   } request;
+
+   request.id = cpu_to_le32(id);
+   request.offset = cpu_to_le32(offset);
+   request.size = cpu_to_le32(size);
+   request.mode = cpu_to_le32(mode);
+
+   return qcom_scm_call(dev, QCOM_SCM_OCMEM_SVC, QCOM_SCM_OCMEM_LOCK_CMD,
+, sizeof(request), NULL, 0);
+}
+
+int __qcom_scm_ocmem_unlock(struct device *dev, u32 id, u32 offset, u32 size)
+{
+   struct ocmem_tz_unlock {
+   __le32 id;
+   __le32 offset;
+   __le32 size;
+   } request;
+
+   request.id = cpu_to_le32(id);
+   request.offset = cpu_to_le32(offset);
+   request.size = cpu_to_le32(size);
+
+   return qcom_scm_call(dev, QCOM_SCM_OCMEM_SVC, QCOM_SCM_OCMEM_UNLOCK_CMD,
+, sizeof(request), NULL, 0);
+}
+
 void __qcom_scm_init(void)
 {
 }
diff --git a/drivers/firmware/qcom_scm-64.c b/drivers/firmware/qcom_scm-64.c
index b6b78da7f9c9..2674d6d3cdde 100644
--- a/drivers/firmware/qcom_scm-64.c
+++ b/drivers/firmware/qcom_scm-64.c
@@ -247,6 +247,18 @@ int __qcom_scm_restore_sec_config(struct device *dev, u32 
sec_id,
return -ENOTSUPP;
 }
 
+int __qcom_scm_ocmem_lock(struct device *dev, uint32_t id, uint32_t offset,
+ uint32_t size, uint32_t mode)
+{
+   return -ENOTSUPP;
+}
+
+int __qcom_scm_ocmem_unlock(struct device *dev, uint32_t id, uint32_t offset,
+   uint32_t size)
+{
+   return -ENOTSUPP;
+}
+
 void __qcom_scm_init(void)
 {
u64 cmd;
diff --git a/drivers/firmware/qcom_scm.c b/drivers/firmware/qcom_scm.c
index 5495ef994c5d..85afb54defd4 100644
--- a/drivers/firmware/qcom_scm.c
+++ b/drivers/firmware/qcom_scm.c
@@ -193,6 +193,46 @@ int qcom_scm_restore_sec_config(struct device *dev,
 }
 EXPORT_SYMBOL(qcom_scm_restore_sec_config);
 
+/**
+ * qcom_scm_ocmem_lock_available() - is OCMEM lock/unlock interface available
+ */
+bool qcom_scm_ocmem_lock_available(void)
+{
+   return __qcom_scm_is_call_available(__scm->dev, QCOM_SCM_OCMEM_SVC,
+   QCOM_SCM_OCMEM_LOCK_CMD);
+}
+EXPORT_SYMBOL(qcom_scm_ocmem_lock_available);
+
+/**
+ * qcom_scm_ocmem_lock() - call OCMEM lock interface to assign an OCMEM
+ * region to the specified initiator
+ *
+ * @id: tz initiator id
+ * @offset: OCMEM offset
+ * @size:   OCMEM size
+ * @mode:   access mode (WIDE/NARROW)
+ */
+int qcom_scm_ocmem_lock(enum qcom_scm_ocmem_client id, u32 offset, u32 size,
+   u32 mode)
+{
+   return __qcom_scm_ocmem_lock(__scm->dev, id, offset, size, mode);
+}
+EXPORT_SYMBOL(qcom_scm_ocmem_lock);
+
+/**
+ * qcom_scm_ocmem_unlock() - call OCMEM unlock interface to release an OCMEM
+ * region from the specified initiator
+ *
+ * @id: tz initiator id
+ * @offset: OCMEM offset
+ * @size:   OCMEM size
+ */
+int qcom_scm_ocmem_unlock(enum qcom_scm_ocmem_client id, u32 offset, u32 size)
+{
+   return __qcom_scm_ocmem_unlock(__scm->dev, id, offset, size);
+}
+EXPORT_SYMBOL(qcom_scm_ocmem_unlock);
+
 /**
  * qcom_scm_pas_supported() - Check if the peripheral authentication service is
  *   available for the given peripherial
diff --git a/drivers/firmware/qcom_scm.h b/drivers/firmware/qcom_scm.h
index bccc7d10c5c2..387e3c4e33c5 100644
--- a/drivers/firmware/qcom_scm.h
+++ b/drivers/firmware/qcom_scm.h
@@ -48,6 +48,15 @@ extern void __qcom_scm_init(void);
 extern int __qcom_scm_restore_sec_config(struct device *dev, u32 sec_id,
 u32 ctx_bank_num);
 
+#define QCOM_SCM_OCMEM_SVC 0xf
+#define QCOM_SCM_OCMEM_LOCK_CMD0x1
+#define QCOM_SCM_OCMEM_UNLOCK_CMD  0x2
+
+extern 

[PATCH 6/6] drm/msm/gpu: add ocmem init/cleanup functions

[Brian Masney]

The files a3xx_gpu.c and a4xx_gpu.c have ifdefs for the OCMEM support
that was missing upstream. Add two new functions (adreno_gpu_ocmem_init
and adreno_gpu_ocmem_cleanup) that removes some duplicated code. We also
need to change the ifdef check for CONFIG_MSM_OCMEM to CONFIG_QCOM_OCMEM
now that OCMEM support is upstream.

Signed-off-by: Brian Masney 
---
 drivers/gpu/drm/msm/adreno/a3xx_gpu.c   | 33 +++-
 drivers/gpu/drm/msm/adreno/a3xx_gpu.h   |  3 +-
 drivers/gpu/drm/msm/adreno/a4xx_gpu.c   | 30 ++
 drivers/gpu/drm/msm/adreno/a4xx_gpu.h   |  3 +-
 drivers/gpu/drm/msm/adreno/adreno_gpu.c | 41 +
 drivers/gpu/drm/msm/adreno/adreno_gpu.h | 10 ++
 6 files changed, 74 insertions(+), 46 deletions(-)

diff --git a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
index c3b4bc6e4155..72720bb2aca1 100644
--- a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
@@ -17,10 +17,6 @@
  * this program.  If not, see .
  */
 
-#ifdef CONFIG_MSM_OCMEM
-#  include 
-#endif
-
 #include "a3xx_gpu.h"
 
 #define A3XX_INT0_MASK \
@@ -206,9 +202,9 @@ static int a3xx_hw_init(struct msm_gpu *gpu)
gpu_write(gpu, REG_A3XX_RBBM_GPR0_CTL, 0x);
 
/* Set the OCMEM base address for A330, etc */
-   if (a3xx_gpu->ocmem_hdl) {
+   if (a3xx_gpu->ocmem.hdl) {
gpu_write(gpu, REG_A3XX_RB_GMEM_BASE_ADDR,
-   (unsigned int)(a3xx_gpu->ocmem_base >> 14));
+   (unsigned int)(a3xx_gpu->ocmem.base >> 14));
}
 
/* Turn on performance counters: */
@@ -329,10 +325,7 @@ static void a3xx_destroy(struct msm_gpu *gpu)
 
adreno_gpu_cleanup(adreno_gpu);
 
-#ifdef CONFIG_MSM_OCMEM
-   if (a3xx_gpu->ocmem_base)
-   ocmem_free(OCMEM_GRAPHICS, a3xx_gpu->ocmem_hdl);
-#endif
+   adreno_gpu_ocmem_cleanup(_gpu->ocmem);
 
kfree(a3xx_gpu);
 }
@@ -507,17 +500,10 @@ struct msm_gpu *a3xx_gpu_init(struct drm_device *dev)
 
/* if needed, allocate gmem: */
if (adreno_is_a330(adreno_gpu)) {
-#ifdef CONFIG_MSM_OCMEM
-   /* TODO this is different/missing upstream: */
-   struct ocmem_buf *ocmem_hdl =
-   ocmem_allocate(OCMEM_GRAPHICS, 
adreno_gpu->gmem);
-
-   a3xx_gpu->ocmem_hdl = ocmem_hdl;
-   a3xx_gpu->ocmem_base = ocmem_hdl->addr;
-   adreno_gpu->gmem = ocmem_hdl->len;
-   DBG("using %dK of OCMEM at 0x%08x", adreno_gpu->gmem / 1024,
-   a3xx_gpu->ocmem_base);
-#endif
+   ret = adreno_gpu_ocmem_init(_gpu->base.pdev->dev,
+   adreno_gpu, _gpu->ocmem);
+   if (ret)
+   goto fail;
}
 
if (!gpu->aspace) {
@@ -530,11 +516,14 @@ struct msm_gpu *a3xx_gpu_init(struct drm_device *dev)
 */
DRM_DEV_ERROR(dev->dev, "No memory protection without IOMMU\n");
ret = -ENXIO;
-   goto fail;
+   goto fail_cleanup_ocmem;
}
 
return gpu;
 
+fail_cleanup_ocmem:
+   adreno_gpu_ocmem_cleanup(_gpu->ocmem);
+
 fail:
if (a3xx_gpu)
a3xx_destroy(_gpu->base.base);
diff --git a/drivers/gpu/drm/msm/adreno/a3xx_gpu.h 
b/drivers/gpu/drm/msm/adreno/a3xx_gpu.h
index ab60dc9e344e..727c34f38f9e 100644
--- a/drivers/gpu/drm/msm/adreno/a3xx_gpu.h
+++ b/drivers/gpu/drm/msm/adreno/a3xx_gpu.h
@@ -30,8 +30,7 @@ struct a3xx_gpu {
struct adreno_gpu base;
 
/* if OCMEM is used for GMEM: */
-   uint32_t ocmem_base;
-   void *ocmem_hdl;
+   struct adreno_ocmem ocmem;
 };
 #define to_a3xx_gpu(x) container_of(x, struct a3xx_gpu, base)
 
diff --git a/drivers/gpu/drm/msm/adreno/a4xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
index ab2b752566d8..b8f825107796 100644
--- a/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
@@ -2,9 +2,6 @@
 /* Copyright (c) 2014 The Linux Foundation. All rights reserved.
  */
 #include "a4xx_gpu.h"
-#ifdef CONFIG_MSM_OCMEM
-#  include 
-#endif
 
 #define A4XX_INT0_MASK \
(A4XX_INT0_RBBM_AHB_ERROR |\
@@ -188,7 +185,7 @@ static int a4xx_hw_init(struct msm_gpu *gpu)
(1 << 30) | 0x);
 
gpu_write(gpu, REG_A4XX_RB_GMEM_BASE_ADDR,
-   (unsigned int)(a4xx_gpu->ocmem_base >> 14));
+   (unsigned int)(a4xx_gpu->ocmem.base >> 14));
 
/* Turn on performance counters: */
gpu_write(gpu, REG_A4XX_RBBM_PERFCTR_CTL, 0x01);
@@ -318,10 +315,7 @@ static void a4xx_destroy(struct msm_gpu *gpu)
 
adreno_gpu_cleanup(adreno_gpu);
 
-#ifdef CONFIG_MSM_OCMEM
-   if (a4xx_gpu->ocmem_base)
-   ocmem_free(OCMEM_GRAPHICS, a4xx_gpu->ocmem_hdl);
-#endif
+   

[PATCH libdrm v2 4/4] meson.build: Fix meson script on FreeBSD

[Emil Velikov]

From: Niclas Zeising 

FreeBSD requires sys/types.h for sys/sysctl.h, add it as part of the
includes when checking for headers.
Instead of splitting out the check for sys/sysctl.h from the other
header checks, just add sys/types.h to all header checks.

v2 [Emil]
 - add inline comment
 - drop bash/sh hunk

Signed-off-by: Emil Velikov 
---
 meson.build | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/meson.build b/meson.build
index ed407009..14f82b1f 100644
--- a/meson.build
+++ b/meson.build
@@ -179,9 +179,12 @@ 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']
   config.set('HAVE_' + header.underscorify().to_upper(),
-cc.compiles('#include <@0@>'.format(header), name : '@0@ 
works'.format(header)))
+cc.compiles('#include \n#include <@0@>'.format(header), name 
: '@0@ works'.format(header)))
 endforeach
 if cc.has_header_symbol('sys/sysmacros.h', 'major')
   config.set10('MAJOR_IN_SYSMACROS', true)
-- 
2.21.0

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

[PATCH libdrm v2 3/4] meson: normal shell will do

[Emil Velikov]

As tweaked with previous patch - bash is not required. Any shell will do

Signed-off-by: Emil Velikov 
---
 amdgpu/meson.build|  2 +-
 etnaviv/meson.build   |  2 +-
 exynos/meson.build|  2 +-
 freedreno/meson.build |  2 +-
 intel/meson.build | 14 +++---
 libkms/meson.build|  2 +-
 meson.build   |  2 +-
 nouveau/meson.build   |  2 +-
 omap/meson.build  |  2 +-
 radeon/meson.build|  2 +-
 tegra/meson.build |  2 +-
 11 files changed, 17 insertions(+), 17 deletions(-)

diff --git a/amdgpu/meson.build b/amdgpu/meson.build
index 7c8ccc7e..18e30166 100644
--- a/amdgpu/meson.build
+++ b/amdgpu/meson.build
@@ -59,7 +59,7 @@ ext_libdrm_amdgpu = declare_dependency(
 
 test(
   'amdgpu-symbol-check',
-  prog_bash,
+  prog_sh,
   env : env_test,
   args : [files('amdgpu-symbol-check'), libdrm_amdgpu]
 )
diff --git a/etnaviv/meson.build b/etnaviv/meson.build
index 515a4ed0..82fbc208 100644
--- a/etnaviv/meson.build
+++ b/etnaviv/meson.build
@@ -54,6 +54,6 @@ ext_libdrm_etnaviv = declare_dependency(
 
 test(
   'etnaviv-symbol-check',
-  prog_bash,
+  prog_sh,
   args : [files('etnaviv-symbol-check'), libdrm_etnaviv]
 )
diff --git a/exynos/meson.build b/exynos/meson.build
index bdfc3fc6..1de75220 100644
--- a/exynos/meson.build
+++ b/exynos/meson.build
@@ -48,7 +48,7 @@ pkg.generate(
 
 test(
   'exynos-symbol-check',
-  prog_bash,
+  prog_sh,
   env : env_test,
   args : [files('exynos-symbol-check'), libdrm_exynos]
 )
diff --git a/freedreno/meson.build b/freedreno/meson.build
index c9aba060..277d5ec5 100644
--- a/freedreno/meson.build
+++ b/freedreno/meson.build
@@ -71,7 +71,7 @@ pkg.generate(
 
 test(
   'freedreno-symbol-check',
-  prog_bash,
+  prog_sh,
   env : env_test,
   args : [files('freedreno-symbol-check'), libdrm_freedreno]
 )
diff --git a/intel/meson.build b/intel/meson.build
index 3d6bbac6..6f149c74 100644
--- a/intel/meson.build
+++ b/intel/meson.build
@@ -64,43 +64,43 @@ test_decode = executable(
 
 test(
   'gen4-3d.batch',
-  prog_bash,
+  prog_sh,
   args : files('tests/gen4-3d.batch.sh'),
   workdir : meson.current_build_dir(),
 )
 test(
   'gen45-3d.batch',
-  prog_bash,
+  prog_sh,
   args : files('tests/gm45-3d.batch.sh'),
   workdir : meson.current_build_dir(),
 )
 test(
   'gen5-3d.batch',
-  prog_bash,
+  prog_sh,
   args : files('tests/gen5-3d.batch.sh'),
   workdir : meson.current_build_dir(),
 )
 test(
   'gen6-3d.batch',
-  prog_bash,
+  prog_sh,
   args : files('tests/gen6-3d.batch.sh'),
   workdir : meson.current_build_dir(),
 )
 test(
   'gen7-3d.batch',
-  prog_bash,
+  prog_sh,
   args : files('tests/gen7-3d.batch.sh'),
   workdir : meson.current_build_dir(),
 )
 test(
   'gen7-2d-copy.batch',
-  prog_bash,
+  prog_sh,
   args : files('tests/gen7-2d-copy.batch.sh'),
   workdir : meson.current_build_dir(),
 )
 test(
   'intel-symbol-check',
-  prog_bash,
+  prog_sh,
   env : env_test,
   args : [files('intel-symbol-check'), libdrm_intel]
 )
diff --git a/libkms/meson.build b/libkms/meson.build
index dc931608..7b8d34ad 100644
--- a/libkms/meson.build
+++ b/libkms/meson.build
@@ -69,7 +69,7 @@ pkg.generate(
 
 test(
   'kms-symbol-check',
-  prog_bash,
+  prog_sh,
   env : env_test,
   args : [files('kms-symbol-check'), libkms]
 )
diff --git a/meson.build b/meson.build
index 64f0d5b1..ed407009 100644
--- a/meson.build
+++ b/meson.build
@@ -249,7 +249,7 @@ endif
 with_man_pages = with_man_pages != 'false' and prog_xslt.found() and 
prog_sed.found()
 
 # Used for tests
-prog_bash = find_program('bash')
+prog_sh = find_program('sh')
 
 config.set10('HAVE_VISIBILITY',
   cc.compiles('''int foo_hidden(void) 
__attribute__((visibility(("hidden";''',
diff --git a/nouveau/meson.build b/nouveau/meson.build
index 0c1498d7..eda0fd3d 100644
--- a/nouveau/meson.build
+++ b/nouveau/meson.build
@@ -53,7 +53,7 @@ pkg.generate(
 
 test(
   'nouveau-symbol-check',
-  prog_bash,
+  prog_sh,
   env : env_test,
   args : [files('nouveau-symbol-check'), libdrm_nouveau]
 )
diff --git a/omap/meson.build b/omap/meson.build
index 54698c6a..7c11b5e8 100644
--- a/omap/meson.build
+++ b/omap/meson.build
@@ -48,7 +48,7 @@ pkg.generate(
 
 test(
   'omap-symbol-check',
-  prog_bash,
+  prog_sh,
   env : env_test,
   args : [files('omap-symbol-check'), libdrm_omap]
 )
diff --git a/radeon/meson.build b/radeon/meson.build
index 1fc5282c..d272800f 100644
--- a/radeon/meson.build
+++ b/radeon/meson.build
@@ -58,7 +58,7 @@ pkg.generate(
 
 test(
   'radeon-symbol-check',
-  prog_bash,
+  prog_sh,
   env : env_test,
   args : [files('radeon-symbol-check'), libdrm_radeon]
 )
diff --git a/tegra/meson.build b/tegra/meson.build
index 4bc454b6..f385f72e 100644
--- a/tegra/meson.build
+++ b/tegra/meson.build
@@ -47,7 +47,7 @@ pkg.generate(
 
 test(
   'tegra-symbol-check',
-  prog_bash,
+  prog_sh,
   env : env_test,
   args : [files('tegra-symbol-check'), libdrm_tegra]
 )
-- 
2.21.0

___
dri-devel mailing list

[PATCH libdrm v2 2/4] *symbols-check: use normal shell over bash

[Emil Velikov]

None of the tests are bash specific. Tested with bash, zsh, dash, mksh
and ksh.

Signed-off-by: Emil Velikov 
---
 amdgpu/amdgpu-symbol-check   | 2 +-
 etnaviv/etnaviv-symbol-check | 2 +-
 exynos/exynos-symbol-check   | 2 +-
 freedreno/freedreno-symbol-check | 2 +-
 intel/intel-symbol-check | 2 +-
 libkms/kms-symbol-check  | 2 +-
 nouveau/nouveau-symbol-check | 2 +-
 omap/omap-symbol-check   | 2 +-
 radeon/radeon-symbol-check   | 2 +-
 tegra/tegra-symbol-check | 2 +-
 10 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/amdgpu/amdgpu-symbol-check b/amdgpu/amdgpu-symbol-check
index 5ce15f46..ea83850d 100755
--- a/amdgpu/amdgpu-symbol-check
+++ b/amdgpu/amdgpu-symbol-check
@@ -1,4 +1,4 @@
-#!/bin/bash
+#!/bin/sh
 
 set -u
 
diff --git a/etnaviv/etnaviv-symbol-check b/etnaviv/etnaviv-symbol-check
index 18910688..ef4e66f4 100755
--- a/etnaviv/etnaviv-symbol-check
+++ b/etnaviv/etnaviv-symbol-check
@@ -1,4 +1,4 @@
-#!/bin/bash
+#!/bin/sh
 
 set -u
 
diff --git a/exynos/exynos-symbol-check b/exynos/exynos-symbol-check
index 49d611e6..d2c362e1 100755
--- a/exynos/exynos-symbol-check
+++ b/exynos/exynos-symbol-check
@@ -1,4 +1,4 @@
-#!/bin/bash
+#!/bin/sh
 
 set -u
 
diff --git a/freedreno/freedreno-symbol-check b/freedreno/freedreno-symbol-check
index 978026c0..987e38fa 100755
--- a/freedreno/freedreno-symbol-check
+++ b/freedreno/freedreno-symbol-check
@@ -1,4 +1,4 @@
-#!/bin/bash
+#!/bin/sh
 
 set -u
 
diff --git a/intel/intel-symbol-check b/intel/intel-symbol-check
index de377bef..2f355321 100755
--- a/intel/intel-symbol-check
+++ b/intel/intel-symbol-check
@@ -1,4 +1,4 @@
-#!/bin/bash
+#!/bin/sh
 
 set -u
 
diff --git a/libkms/kms-symbol-check b/libkms/kms-symbol-check
index 30f444f7..7d3426f6 100755
--- a/libkms/kms-symbol-check
+++ b/libkms/kms-symbol-check
@@ -1,4 +1,4 @@
-#!/bin/bash
+#!/bin/sh
 
 set -u
 
diff --git a/nouveau/nouveau-symbol-check b/nouveau/nouveau-symbol-check
index 6296244c..36703a3e 100755
--- a/nouveau/nouveau-symbol-check
+++ b/nouveau/nouveau-symbol-check
@@ -1,4 +1,4 @@
-#!/bin/bash
+#!/bin/sh
 
 set -u
 
diff --git a/omap/omap-symbol-check b/omap/omap-symbol-check
index 16da3c40..21522ba0 100755
--- a/omap/omap-symbol-check
+++ b/omap/omap-symbol-check
@@ -1,4 +1,4 @@
-#!/bin/bash
+#!/bin/sh
 
 set -u
 
diff --git a/radeon/radeon-symbol-check b/radeon/radeon-symbol-check
index da605bb8..7b69f9a4 100755
--- a/radeon/radeon-symbol-check
+++ b/radeon/radeon-symbol-check
@@ -1,4 +1,4 @@
-#!/bin/bash
+#!/bin/sh
 
 set -u
 
diff --git a/tegra/tegra-symbol-check b/tegra/tegra-symbol-check
index 8539b95b..a74d9749 100755
--- a/tegra/tegra-symbol-check
+++ b/tegra/tegra-symbol-check
@@ -1,4 +1,4 @@
-#!/bin/bash
+#!/bin/sh
 
 set -u
 
-- 
2.21.0

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

[PATCH libdrm v2 1/4] meson.build: Fix typo

[Emil Velikov]

From: Niclas Zeising 

Reviewed-by: Emil Velikov 
---
 meson.build | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meson.build b/meson.build
index be768afa..64f0d5b1 100644
--- a/meson.build
+++ b/meson.build
@@ -248,7 +248,7 @@ if prog_xslt.found()
 endif
 with_man_pages = with_man_pages != 'false' and prog_xslt.found() and 
prog_sed.found()
 
-# Used for tets
+# Used for tests
 prog_bash = find_program('bash')
 
 config.set10('HAVE_VISIBILITY',
-- 
2.21.0

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

Re: [PATCH libdrm 2/2] meson.build: Fix meson script on FreeBSD

[Emil Velikov]

On Mon, 3 Jun 2019 at 08:41, Niclas Zeising  wrote:
>
> FreeBSD requires sys/types.h for sys/sysctl.h, add it as part of the
> includes when checking for headers.
> Instead of splitting out the check for sys/sysctl.h from the other
> header checks, just add sys/types.h to all header checks.
>
If header X depends on Y, then the former should include Y.
Can you please file a FreeBSD bug?

That said, the workaround is safe, so I'll split it out + add a comment.
I'll send v2 in a second.

> FreeBSD doesn't normally ship bash, try regular sh instead if we can't
> find bash.

Actually not sure why we're looking for bash. The lot works fine with
bash, zsh, dash, ksh you-name it.
Will include those with v2.

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

Re: [linux-sunxi] [PATCH v6 5/6] drm: sun4i: Add support for enabling DDC I2C bus to sun8i_dw_hdmi glue

[Ondřej Jirman]

Hi Jernej,

On Sun, Jun 16, 2019 at 01:05:13PM +0200, Jernej Škrabec wrote:
> Hi Ondrej!
> 
> Dne ponedeljek, 27. maj 2019 ob 18:22:36 CEST je megous via linux-sunxi 
> napisal(a):
> > From: Ondrej Jirman 
> > 
> > Orange Pi 3 board requires enabling a voltage shifting circuit via GPIO
> > for the DDC bus to be usable.
> > 
> > Add support for hdmi-connector node's optional ddc-en-gpios property to
> > support this use case.
> > 
> > Signed-off-by: Ondrej Jirman 
> > ---
> >  drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c | 55 +--
> >  drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h |  3 ++
> >  2 files changed, 55 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
> > b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c index 39d8509d96a0..59b81ba02d96
> > 100644
> > --- a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
> > +++ b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
> > @@ -98,6 +98,30 @@ static u32 sun8i_dw_hdmi_find_possible_crtcs(struct
> > drm_device *drm, return crtcs;
> >  }
> > 
> > +static int sun8i_dw_hdmi_find_connector_pdev(struct device *dev,
> > +struct 
> platform_device **pdev_out)
> > +{
> > +   struct platform_device *pdev;
> > +   struct device_node *remote;
> > +
> > +   remote = of_graph_get_remote_node(dev->of_node, 1, -1);
> > +   if (!remote)
> > +   return -ENODEV;
> > +
> > +   if (!of_device_is_compatible(remote, "hdmi-connector")) {
> > +   of_node_put(remote);
> > +   return -ENODEV;
> > +   }
> > +
> > +   pdev = of_find_device_by_node(remote);
> > +   of_node_put(remote);
> > +   if (!pdev)
> > +   return -ENODEV;
> > +
> > +   *pdev_out = pdev;
> > +   return 0;
> > +}
> > +
> >  static int sun8i_dw_hdmi_bind(struct device *dev, struct device *master,
> >   void *data)
> >  {
> > @@ -151,16 +175,29 @@ static int sun8i_dw_hdmi_bind(struct device *dev,
> > struct device *master, return PTR_ERR(hdmi->regulator);
> > }
> > 
> > +   ret = sun8i_dw_hdmi_find_connector_pdev(dev, >connector_pdev);
> > +   if (!ret) {
> > +   hdmi->ddc_en = gpiod_get_optional(>connector_pdev-
> >dev,
> > + "ddc-en", 
> GPIOD_OUT_HIGH);
> > +   if (IS_ERR(hdmi->ddc_en)) {
> > +   platform_device_put(hdmi->connector_pdev);
> > +   dev_err(dev, "Couldn't get ddc-en gpio\n");
> > +   return PTR_ERR(hdmi->ddc_en);
> > +   }
> > +   }
> > +
> > ret = regulator_enable(hdmi->regulator);
> > if (ret) {
> > dev_err(dev, "Failed to enable regulator\n");
> > -   return ret;
> > +   goto err_unref_ddc_en;
> > }
> > 
> > +   gpiod_set_value(hdmi->ddc_en, 1);
> 
> Why don't you do that inside if clause where hdmi->ddc_en is assigned? It's 
> not useful otherwise anyway.
> 
> Besides, you would then only need to adjust one goto label in error path.

The idea is to enable DDC after enabling the regulator. I don't think it matters
for the particular HW that's on Orange Pi 3, and similar Xunlong boards, but
this is a fairly generic binding and it makes more sense to power the bus, and
then enable whatever aditional circuitry might be there for the IO.

I can move sun8i_dw_hdmi_find_connector_pdev lower, but I would then need to
disable the regulator in the error path, and I like to keep this order:

- parsing DT
- enabling actual HW stuff

Because parsing is likely to fail with DEFERED_PROBE, because GPIO or whatever
else is not yet ready, and this approach avoids enabling/disabling the HW
needlessly.

> > +
> > ret = reset_control_deassert(hdmi->rst_ctrl);
> > if (ret) {
> > dev_err(dev, "Could not deassert ctrl reset 
> control\n");
> > -   goto err_disable_regulator;
> > +   goto err_disable_ddc_en;
> > }
> > 
> > ret = clk_prepare_enable(hdmi->clk_tmds);
> > @@ -213,8 +250,14 @@ static int sun8i_dw_hdmi_bind(struct device *dev,
> > struct device *master, clk_disable_unprepare(hdmi->clk_tmds);
> >  err_assert_ctrl_reset:
> > reset_control_assert(hdmi->rst_ctrl);
> > -err_disable_regulator:
> > +err_disable_ddc_en:
> > +   gpiod_set_value(hdmi->ddc_en, 0);
> > regulator_disable(hdmi->regulator);
> > +err_unref_ddc_en:
> > +   if (hdmi->ddc_en)
> > +   gpiod_put(hdmi->ddc_en);
> > +
> > +   platform_device_put(hdmi->connector_pdev);
> > 
> > return ret;
> >  }
> > @@ -228,7 +271,13 @@ static void sun8i_dw_hdmi_unbind(struct device *dev,
> > struct device *master, sun8i_hdmi_phy_remove(hdmi);
> > clk_disable_unprepare(hdmi->clk_tmds);
> > reset_control_assert(hdmi->rst_ctrl);
> > +   gpiod_set_value(hdmi->ddc_en, 0);
> > regulator_disable(hdmi->regulator);
> > +
> > +   if (hdmi->ddc_en)
> > +   gpiod_put(hdmi->ddc_en);
> > +
> > +   platform_device_put(hdmi->connector_pdev);
> >  }
> > 
> >  static const struct component_ops sun8i_dw_hdmi_ops = {
> > diff --git 

[Bug 110897] HyperZ is broken for r300 (bad z for some micro and macrotiles?)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=110897

--- Comment #56 from Richard Thier  ---
(In reply to cosiekvfj from comment #54)
> Created attachment 144558 [details]
> dmesg log
> 
> [   14.303343] [drm] radeon: 1 quad pipes, 1 z pipes initialized.

This is really interesting! It tells us why it works in your case (the 1 quad
pipe is reported "properly"), but I have no idea why it is reported properly.

I see you are using 4.x kernel so there might be changes - or for some reason
your card returns proper values from the registers the driver read from and
mine does not. Thank you for the information!

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 110897] HyperZ is broken for r300 (bad z for some micro and macrotiles?)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=110897

--- Comment #55 from Richard Thier  ---
(In reply to Dieter Nützel from comment #53)

> If you do NOT 'make mrproper' and change only radeon/amdgpu stuff it should
> only take some minutes (seconds) on your system/CPU.

I was dumb-enough that last time I have cleaned the kernel build dir of mine to
save some space haha. This way it took around 50 minutes.

> > This seems to be the real core of the issue.
> 
> We hear from you. ;-)

I am testing right now, at least the system and X have started but will try
some games and look for what the logs say. I have also added some extra logging
for my liking just to gain more insightful information as I actually have two
ideas for fixing this.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [linux-sunxi] [PATCH v6 5/6] drm: sun4i: Add support for enabling DDC I2C bus to sun8i_dw_hdmi glue

[Jernej Škrabec]

Hi Ondrej!

Dne ponedeljek, 27. maj 2019 ob 18:22:36 CEST je megous via linux-sunxi 
napisal(a):
> From: Ondrej Jirman 
> 
> Orange Pi 3 board requires enabling a voltage shifting circuit via GPIO
> for the DDC bus to be usable.
> 
> Add support for hdmi-connector node's optional ddc-en-gpios property to
> support this use case.
> 
> Signed-off-by: Ondrej Jirman 
> ---
>  drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c | 55 +--
>  drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h |  3 ++
>  2 files changed, 55 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
> b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c index 39d8509d96a0..59b81ba02d96
> 100644
> --- a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
> +++ b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
> @@ -98,6 +98,30 @@ static u32 sun8i_dw_hdmi_find_possible_crtcs(struct
> drm_device *drm, return crtcs;
>  }
> 
> +static int sun8i_dw_hdmi_find_connector_pdev(struct device *dev,
> +  struct 
platform_device **pdev_out)
> +{
> + struct platform_device *pdev;
> + struct device_node *remote;
> +
> + remote = of_graph_get_remote_node(dev->of_node, 1, -1);
> + if (!remote)
> + return -ENODEV;
> +
> + if (!of_device_is_compatible(remote, "hdmi-connector")) {
> + of_node_put(remote);
> + return -ENODEV;
> + }
> +
> + pdev = of_find_device_by_node(remote);
> + of_node_put(remote);
> + if (!pdev)
> + return -ENODEV;
> +
> + *pdev_out = pdev;
> + return 0;
> +}
> +
>  static int sun8i_dw_hdmi_bind(struct device *dev, struct device *master,
> void *data)
>  {
> @@ -151,16 +175,29 @@ static int sun8i_dw_hdmi_bind(struct device *dev,
> struct device *master, return PTR_ERR(hdmi->regulator);
>   }
> 
> + ret = sun8i_dw_hdmi_find_connector_pdev(dev, >connector_pdev);
> + if (!ret) {
> + hdmi->ddc_en = gpiod_get_optional(>connector_pdev-
>dev,
> +   "ddc-en", 
GPIOD_OUT_HIGH);
> + if (IS_ERR(hdmi->ddc_en)) {
> + platform_device_put(hdmi->connector_pdev);
> + dev_err(dev, "Couldn't get ddc-en gpio\n");
> + return PTR_ERR(hdmi->ddc_en);
> + }
> + }
> +
>   ret = regulator_enable(hdmi->regulator);
>   if (ret) {
>   dev_err(dev, "Failed to enable regulator\n");
> - return ret;
> + goto err_unref_ddc_en;
>   }
> 
> + gpiod_set_value(hdmi->ddc_en, 1);

Why don't you do that inside if clause where hdmi->ddc_en is assigned? It's 
not useful otherwise anyway.

Besides, you would then only need to adjust one goto label in error path.

> +
>   ret = reset_control_deassert(hdmi->rst_ctrl);
>   if (ret) {
>   dev_err(dev, "Could not deassert ctrl reset 
control\n");
> - goto err_disable_regulator;
> + goto err_disable_ddc_en;
>   }
> 
>   ret = clk_prepare_enable(hdmi->clk_tmds);
> @@ -213,8 +250,14 @@ static int sun8i_dw_hdmi_bind(struct device *dev,
> struct device *master, clk_disable_unprepare(hdmi->clk_tmds);
>  err_assert_ctrl_reset:
>   reset_control_assert(hdmi->rst_ctrl);
> -err_disable_regulator:
> +err_disable_ddc_en:
> + gpiod_set_value(hdmi->ddc_en, 0);
>   regulator_disable(hdmi->regulator);
> +err_unref_ddc_en:
> + if (hdmi->ddc_en)
> + gpiod_put(hdmi->ddc_en);
> +
> + platform_device_put(hdmi->connector_pdev);
> 
>   return ret;
>  }
> @@ -228,7 +271,13 @@ static void sun8i_dw_hdmi_unbind(struct device *dev,
> struct device *master, sun8i_hdmi_phy_remove(hdmi);
>   clk_disable_unprepare(hdmi->clk_tmds);
>   reset_control_assert(hdmi->rst_ctrl);
> + gpiod_set_value(hdmi->ddc_en, 0);
>   regulator_disable(hdmi->regulator);
> +
> + if (hdmi->ddc_en)
> + gpiod_put(hdmi->ddc_en);
> +
> + platform_device_put(hdmi->connector_pdev);
>  }
> 
>  static const struct component_ops sun8i_dw_hdmi_ops = {
> diff --git a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
> b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h index 720c5aa8adc1..dad66b8301c2
> 100644
> --- a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
> +++ b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
> @@ -9,6 +9,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -190,6 +191,8 @@ struct sun8i_dw_hdmi {
>   struct regulator*regulator;
>   const struct sun8i_dw_hdmi_quirks *quirks;
>   struct reset_control*rst_ctrl;
> + struct platform_device  *connector_pdev;

It seems that connector_pdev is needed only during intialization. Why do you 
store it?

Best regards,
Jernej

> + struct gpio_desc*ddc_en;
>  };
> 
>  static inline struct sun8i_dw_hdmi *

[Bug 110117] Waking from Suspend causes screen to appear with grey static (like a TV with no signal)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=110117

--- Comment #13 from Alexey Shindin  ---
I can confirm this behavior at Ubuntu 18.04.2 LTS with Acer PH517-61 notebook.

The minor addition is that the issue concerns only the built-in display. In two
display configuration after wake up the external display seems to be normal.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 10/12] drm/modes: Parse overscan properties

[Noralf Trønnes]

Den 15.06.2019 17.40, skrev Noralf Trønnes:
> 
> 
> Den 14.06.2019 14.13, skrev Maxime Ripard:
>> Properly configuring the overscan properties might be needed for the
>> initial setup of the framebuffer for display that still have overscan.
>> Let's allow for more properties on the kernel command line to setup each
>> margin.
> 
> This also needs to be documented in Documentation/fb/modedb.txt
> 
>>
>> Reviewed-by: Noralf Trønnes 
>> Signed-off-by: Maxime Ripard 
>> ---
>>  drivers/gpu/drm/drm_modes.c | 44 ++-
>>  include/drm/drm_connector.h | 12 +-
>>  2 files changed, 50 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
>> index b92b7df6784a..25d2ba595750 100644
>> --- a/drivers/gpu/drm/drm_modes.c
>> +++ b/drivers/gpu/drm/drm_modes.c
>> @@ -1609,6 +1609,50 @@ static int drm_mode_parse_cmdline_options(char *str, 
>> size_t len,
>>  } else if (!strncmp(option, "reflect_y", delim - option)) {
>>  rotation |= DRM_MODE_REFLECT_Y;
>>  sep = delim;
>> +} else if (!strncmp(option, "margin_right", delim - option)) {
> 
> I wonder if this should be called tv_margin_right to distinguish it from
> 'm' (the mode specifier) which also is a margin? Or can these margins be
> reused on other display types later on? A little stupid to have both
> 'tv_margin_right' and 'margin_right'.

And after a nights sleep I think 'margin_right' is just fine as long as
it's documented in modedb.txt as TV margins.

So with an modedb.txt entry and the struct change moved to patch 8:

Reviewed-by: Noralf Trønnes 

> 
>> +const char *value = delim + 1;
>> +unsigned int margin;
>> +
>> +margin = simple_strtol(value, , 10);
>> +
>> +/* Make sure we have parsed something */
>> +if (sep == value)
>> +return -EINVAL;
>> +
>> +mode->tv_margins.right = margin;
>> +} else if (!strncmp(option, "margin_left", delim - option)) {
>> +const char *value = delim + 1;
>> +unsigned int margin;
>> +
>> +margin = simple_strtol(value, , 10);
>> +
>> +/* Make sure we have parsed something */
>> +if (sep == value)
>> +return -EINVAL;
>> +
>> +mode->tv_margins.left = margin;
>> +} else if (!strncmp(option, "margin_top", delim - option)) {
>> +const char *value = delim + 1;
>> +unsigned int margin;
>> +
>> +margin = simple_strtol(value, , 10);
>> +
>> +/* Make sure we have parsed something */
>> +if (sep == value)
>> +return -EINVAL;
>> +
>> +mode->tv_margins.top = margin;
>> +} else if (!strncmp(option, "margin_bottom", delim - option)) {
>> +const char *value = delim + 1;
>> +unsigned int margin;
>> +
>> +margin = simple_strtol(value, , 10);
>> +
>> +/* Make sure we have parsed something */
>> +if (sep == value)
>> +return -EINVAL;
>> +
>> +mode->tv_margins.bottom = margin;
>>  } else {
>>  return -EINVAL;
>>  }
>> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
>> index c58a35b34c1a..6841c46e6781 100644
>> --- a/include/drm/drm_connector.h
>> +++ b/include/drm/drm_connector.h
>> @@ -505,12 +505,7 @@ struct drm_connector_tv_margins {
>>   */
>>  struct drm_tv_connector_state {
>>  enum drm_mode_subconnector subconnector;
>> -struct {
>> -unsigned int left;
>> -unsigned int right;
>> -unsigned int top;
>> -unsigned int bottom;
>> -} margins;
>> +struct drm_connector_tv_margins margins;
>>  unsigned int mode;
>>  unsigned int brightness;
>>  unsigned int contrast;
> 
> As mentioned this needs moving to patch 8.
> 
> Noralf.
> 
>> @@ -1039,6 +1034,11 @@ struct drm_cmdline_mode {
>>   * DRM_MODE_ROTATE_180 are supported at the moment.
>>   */
>>  unsigned int rotation;
>> +
>> +/**
>> + * @tv_margins: TV margins to apply to the mode.
>> + */
>> +struct drm_connector_tv_margins tv_margins;
>>  };
>>  
>>  /**
>>
> ___
> 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

[Bug 110897] HyperZ is broken for r300 (bad z for some micro and macrotiles?)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=110897

--- Comment #54 from cosiek...@o2.pl ---
Created attachment 144558
  --> https://bugs.freedesktop.org/attachment.cgi?id=144558=edit
dmesg log

[   14.303343] [drm] radeon: 1 quad pipes, 1 z pipes initialized.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 2/2] arm: dts: add ARM Mali GPU node for Odroid XU3

[Krzysztof Kozlowski]

On Fri, Jun 14, 2019 at 04:57:19PM -0700, Joseph Kogut wrote:
> Add device tree node for mali gpu on Odroid XU3 SoCs.
> 
> Signed-off-by: Joseph Kogut 
> ---
> 
> Changes v1 -> v2:
> - Use interrupt name ordering from binding doc
> - Specify a single clock for GPU node
> - Add gpu opp table
> - Fix warnings from IRQ_TYPE_NONE
> 
>  .../boot/dts/exynos5422-odroidxu3-common.dtsi | 26 +++

This should go to exynos5422-odroid-core.dtsi instead, because it is
common to entire Odroid Exynos5422 family (not only XU3 family).

>  1 file changed, 26 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi 
> b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
> index 93a48f2dda49..b8a4246e3b37 100644
> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
> @@ -48,6 +48,32 @@
>   cooling-levels = <0 130 170 230>;
>   };
> 
> + gpu: gpu@1180 {
> + compatible = "samsung,exynos-mali", "arm,mali-t628";

This is common to all Exynos542x chips so it should go to
exynos5420.dtsi. Here you would need to only enable it and provide
regulator.

Probably this should be also associated with tmu_gpu as a cooling device
(if Mali registers a cooling device...). Otherwise the tmu_gpu is not
really used for it.

> + reg = <0x1180 0x5000>;
> + interrupts = ,
> +  ,
> +  ;
> + interrupt-names = "job", "mmu", "gpu";
> + clocks = < CLK_G3D>;
> + mali-supply = <_reg>;

Please check if always-on property could be removed from buck4. Also,
what about LDO27? It should be used as well (maybe through
vendor-specific properties which would justify the need of new vendor
compatible).


Best regards,
Krzysztof

> + operating-points-v2 = <_opp_table>;
> + };
> +
> + gpu_opp_table: gpu-opp-table {
> + compatible = "operating-points-v2";
> +
> + opp-17700 {
> + opp-hz = /bits/ 64 <11700>;
> + opp-microvolt = <812500>;
> + };
> +
> + opp-6 {
> + opp-hz = /bits/ 64 <6>;
> + opp-microvolt = <115>;
> + };
> + };
> +
>   thermal-zones {
>   cpu0_thermal: cpu0-thermal {
>   thermal-sensors = <_cpu0 0>;
> --
> 2.22.0
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/2] dt-bindings: gpu: add Exynos Mali vendor specifics

[Krzysztof Kozlowski]

On Fri, Jun 14, 2019 at 01:31:43PM -0700, Joseph Kogut wrote:
> Document vendor specific compatible string for Mali gpus on Exynos SoCs.
> 
> Signed-off-by: Joseph Kogut 
> ---
>  Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt 
> b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt
> index 1b1a74129141..a9704c736d07 100644
> --- a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt
> +++ b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt
> @@ -18,6 +18,7 @@ Required properties:
>  + "amlogic,meson-gxm-mali"
>  + "rockchip,rk3288-mali"
>  + "rockchip,rk3399-mali"
> ++ "samsung,exynos-mali"

Are there any driver differences for Exynos? If not then why adding
another compatible?

Best regards,
Krzysztof

>  
>  - reg : Physical base address of the device and length of the register area.
>  
> -- 
> 2.22.0
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 13/59] drm/etnaviv: Drop drm_gem_prime_export/import

[Christian Gmeiner]

Am Fr., 14. Juni 2019 um 22:36 Uhr schrieb Daniel Vetter
:
>
> They're the default.
>
> Aside: Would be really nice to switch the others over to
> drm_gem_object_funcs.
>
> Signed-off-by: Daniel Vetter 

Reviewed-by: Christian Gmeiner 

> Cc: Lucas Stach 
> Cc: Russell King 
> Cc: Christian Gmeiner 
> Cc: etna...@lists.freedesktop.org
> ---
>  drivers/gpu/drm/etnaviv/etnaviv_drv.c | 2 --
>  1 file changed, 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c 
> b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
> index db3b00031fcf..400fbb2588f1 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
> @@ -469,8 +469,6 @@ static struct drm_driver etnaviv_drm_driver = {
> .gem_vm_ops = _ops,
> .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
> .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
> -   .gem_prime_export   = drm_gem_prime_export,
> -   .gem_prime_import   = drm_gem_prime_import,
> .gem_prime_pin  = etnaviv_gem_prime_pin,
> .gem_prime_unpin= etnaviv_gem_prime_unpin,
> .gem_prime_get_sg_table = etnaviv_gem_prime_get_sg_table,
> --
> 2.20.1
>


-- 
greets
--
Christian Gmeiner, MSc

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