Re: some half-baked ttm ideas

2020-09-15 Thread Dave Airlie
On Wed, 16 Sep 2020 at 14:19, Dave Airlie  wrote:
>
> On Wed, 16 Sep 2020 at 00:12, Christian König
>  wrote:
> >
> > Hi Dave,
> >
> > I think we should just completely nuke ttm_tt_bind() and ttm_tt_unbind()
> > and all of that.
> >
> > Drivers can to this from their move_notify() callback now instead.
>
> Good plan, I've put a bunch of rework into the same branch,
>
> https://github.com/airlied/linux/commits/ttm-half-baked-ideas
>
> but I've fried my brain a bit, I'm having trouble reconciling move
> notify and unbinding in the right places, I feel like I'm circling
> around the answer but haven't hit it yet.

drm/ttm: add unbind to move notify paths.

In that tree is incorrect and I think where things fall apart, since
if we are moving TTM to VRAM that will unbind the TTM object from the
GTT at move notify time before the move has executed.

I'm feeling a move_complete_notify might be an idea, but I'm wondering
if it's a bad idea.

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


Re: some half-baked ttm ideas

2020-09-15 Thread Dave Airlie
On Wed, 16 Sep 2020 at 00:12, Christian König
 wrote:
>
> Hi Dave,
>
> I think we should just completely nuke ttm_tt_bind() and ttm_tt_unbind()
> and all of that.
>
> Drivers can to this from their move_notify() callback now instead.

Good plan, I've put a bunch of rework into the same branch,

https://github.com/airlied/linux/commits/ttm-half-baked-ideas

but I've fried my brain a bit, I'm having trouble reconciling move
notify and unbinding in the right places, I feel like I'm circling
around the answer but haven't hit it yet.

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


Re: [RFC 1/5] drm/i915/dp: Program source OUI on eDP panels

2020-09-15 Thread Lyude Paul
On Tue, 2020-09-15 at 15:38 -0700, Navare, Manasi wrote:
> On Tue, Sep 15, 2020 at 03:47:01PM -0400, Lyude Paul wrote:
> > On Tue, 2020-09-15 at 15:06 -0400, Rodrigo Vivi wrote:
> > > On Tue, Sep 15, 2020 at 01:29:35PM -0400, Lyude Paul wrote:
> > > > Since we're about to start adding support for Intel's magic HDR
> > > > backlight interface over DPCD, we need to ensure we're properly
> > > > programming this field so that Intel specific sink services are
> > > > exposed.
> > > > Otherwise, 0x300-0x3ff will just read zeroes.
> > > > 
> > > > We also take care not to reprogram the source OUI if it already
> > > > matches
> > > > what we expect. This is just to be careful so that we don't
> > > > accidentally
> > > > take the panel out of any backlight control modes we found it in.
> > > > 
> > > > Signed-off-by: Lyude Paul 
> > > > Cc: thay...@noraisin.net
> > > > Cc: Vasily Khoruzhick 
> > > > ---
> > > >  drivers/gpu/drm/i915/display/intel_dp.c | 32
> > > > +
> > > >  1 file changed, 32 insertions(+)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > > > b/drivers/gpu/drm/i915/display/intel_dp.c
> > > > index 4bd10456ad188..b591672ec4eab 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > > > @@ -3428,6 +3428,7 @@ void
> > > > intel_dp_sink_set_decompression_state(struct
> > > > intel_dp *intel_dp,
> > > >  void intel_dp_sink_dpms(struct intel_dp *intel_dp, int mode)
> > > >  {
> > > > struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> > > > +   u8 edp_oui[] = { 0x00, 0xaa, 0x01 };
> > > 
> > > what are these values?
> 
> We in i915 typically use the OUI number for adding any eDP specific
> quirks. I have seen these getting spit out in the dmesg log at thebeginning.
> AFAIK It is some kind of OEM identification number for a display panel.

Are you sure you're not confusing this with the sink OUI btw? We're setting
the source OUI (so, identifying ourselves to the display panel instead of the
other way around) here to tell the panel to expose the Intel specific
backlight controls. My assumption is the { 0x00, 0xaa, 0x01 } is some Intel
driver OUI, it's just I'm not really sure where it comes from other then the
patch I linked to down below

> 
> Manasi
> > I wish I knew, my assumption is this is the OUI that Intel's GPU driver
> > uses on
> > other platforms, but I don't have any documentation mentioning this (in
> > fact,
> > the few documents I do have on this backlight interface don't seem to make
> > any
> > mention of it). I only managed to find this when looking through the last
> > attempt someone did at adding support for this backlight interface:
> > 
> > https://patchwork.freedesktop.org/patch/334989/
> > 
> > I think it should be fairly safe to write, as I know nouveau always
> > programs a
> > source OUI (we don't do it from our driver, but nvidia hardware seems to
> > do it
> > automatically) and I don't believe I've seen it ever change any behavior
> > besides
> > making things appear in the 0x300-0x3ff register range.
> > 
> > AFAICT though, the backlight interface won't advertise itself without this
> > being
> > set early on. If you could find anyone from Intel who knows more about it
> > though
> > I'd definitely appreciate it (and just in general for the rest of the
> > patch
> > series as well)
> > 
> > > > int ret, i;
> > > >  
> > > > /* Should have a valid DPCD by this point */
> > > > @@ -3443,6 +3444,14 @@ void intel_dp_sink_dpms(struct intel_dp
> > > > *intel_dp,
> > > > int mode)
> > > > } else {
> > > > struct intel_lspcon *lspcon = dp_to_lspcon(intel_dp);
> > > >  
> > > > +   /* Write the source OUI as early as possible */
> > > > +   if (intel_dp_is_edp(intel_dp)) {
> > > > +   ret = drm_dp_dpcd_write(_dp->aux,
> > > > DP_SOURCE_OUI,
> > > > edp_oui,
> > > > +   sizeof(edp_oui));
> > > > +   if (ret < 0)
> > > > +   drm_err(>drm, "Failed to write
> > > > eDP source
> > > > OUI\n");
> > > > +   }
> > > > +
> > > > /*
> > > >  * When turning on, we need to retry for 1ms to give
> > > > the sink
> > > >  * time to wake up.
> > > > @@ -4530,6 +4539,23 @@ static void intel_dp_get_dsc_sink_cap(struct
> > > > intel_dp
> > > > *intel_dp)
> > > > }
> > > >  }
> > > >  
> > > > +static void
> > > > +intel_edp_init_source_oui(struct intel_dp *intel_dp)
> > > > +{
> > > > +   struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> > > > +   u8 oui[] = { 0x00, 0xaa, 0x01 };
> > > > +   u8 buf[3] = { 0 };
> > > > +
> > > > +   if (drm_dp_dpcd_read(_dp->aux, DP_SOURCE_OUI, buf,
> > > > sizeof(buf)) <
> > > > 0)
> > > > +   drm_err(>drm, "Failed to read source OUI\n");
> > > > +
> > > > +   

[PATCH 2/3] drm/panfrost: Support cache-coherent integrations

2020-09-15 Thread Robin Murphy
When the GPU's ACE-Lite interface is fully wired up and capable of
snooping CPU caches, it may be described as "dma-coherent" in
devicetree, which will already inform the DMA layer not to perform
unnecessary cache maintenance. However, we still need to ensure that
the GPU uses the appropriate cacheable outer-shareable attributes in
order to generate the requisite snoop signals, and that CPU mappings
don't create a mismatch by using a non-cacheable type either.

Signed-off-by: Robin Murphy 
---
 drivers/gpu/drm/panfrost/panfrost_device.h | 1 +
 drivers/gpu/drm/panfrost/panfrost_drv.c| 2 ++
 drivers/gpu/drm/panfrost/panfrost_gem.c| 2 ++
 drivers/gpu/drm/panfrost/panfrost_mmu.c| 1 +
 4 files changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/panfrost/panfrost_device.h 
b/drivers/gpu/drm/panfrost/panfrost_device.h
index c30c719a8059..b31f45315e96 100644
--- a/drivers/gpu/drm/panfrost/panfrost_device.h
+++ b/drivers/gpu/drm/panfrost/panfrost_device.h
@@ -84,6 +84,7 @@ struct panfrost_device {
/* pm_domains for devices with more than one. */
struct device *pm_domain_devs[MAX_PM_DOMAINS];
struct device_link *pm_domain_links[MAX_PM_DOMAINS];
+   bool coherent;
 
struct panfrost_features features;
const struct panfrost_compatible *comp;
diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c 
b/drivers/gpu/drm/panfrost/panfrost_drv.c
index ada51df9a7a3..2a6f2f716b2f 100644
--- a/drivers/gpu/drm/panfrost/panfrost_drv.c
+++ b/drivers/gpu/drm/panfrost/panfrost_drv.c
@@ -588,6 +588,8 @@ static int panfrost_probe(struct platform_device *pdev)
if (!pfdev->comp)
return -ENODEV;
 
+   pfdev->coherent = device_get_dma_attr(>dev) == DEV_DMA_COHERENT;
+
/* Allocate and initialze the DRM device. */
ddev = drm_dev_alloc(_drm_driver, >dev);
if (IS_ERR(ddev))
diff --git a/drivers/gpu/drm/panfrost/panfrost_gem.c 
b/drivers/gpu/drm/panfrost/panfrost_gem.c
index 33355dd302f1..cdf1a8754eba 100644
--- a/drivers/gpu/drm/panfrost/panfrost_gem.c
+++ b/drivers/gpu/drm/panfrost/panfrost_gem.c
@@ -220,6 +220,7 @@ static const struct drm_gem_object_funcs panfrost_gem_funcs 
= {
  */
 struct drm_gem_object *panfrost_gem_create_object(struct drm_device *dev, 
size_t size)
 {
+   struct panfrost_device *pfdev = dev->dev_private;
struct panfrost_gem_object *obj;
 
obj = kzalloc(sizeof(*obj), GFP_KERNEL);
@@ -229,6 +230,7 @@ struct drm_gem_object *panfrost_gem_create_object(struct 
drm_device *dev, size_t
INIT_LIST_HEAD(>mappings.list);
mutex_init(>mappings.lock);
obj->base.base.funcs = _gem_funcs;
+   obj->base.map_cached = pfdev->coherent;
 
return >base.base;
 }
diff --git a/drivers/gpu/drm/panfrost/panfrost_mmu.c 
b/drivers/gpu/drm/panfrost/panfrost_mmu.c
index e8f7b11352d2..8852fd378f7a 100644
--- a/drivers/gpu/drm/panfrost/panfrost_mmu.c
+++ b/drivers/gpu/drm/panfrost/panfrost_mmu.c
@@ -371,6 +371,7 @@ int panfrost_mmu_pgtable_alloc(struct panfrost_file_priv 
*priv)
.pgsize_bitmap  = SZ_4K | SZ_2M,
.ias= FIELD_GET(0xff, pfdev->features.mmu_features),
.oas= FIELD_GET(0xff00, 
pfdev->features.mmu_features),
+   .coherent_walk  = pfdev->coherent,
.tlb= _tlb_ops,
.iommu_dev  = pfdev->dev,
};
-- 
2.28.0.dirty

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


[PATCH 1/3] iommu/io-pgtable-arm: Support coherency for Mali LPAE

2020-09-15 Thread Robin Murphy
Midgard GPUs have ACE-Lite master interfaces which allows systems to
integrate them in an I/O-coherent manner. It seems that from the GPU's
viewpoint, the rest of the system is its outer shareable domain, and so
even when snoop signals are wired up, they are only emitted for outer
shareable accesses. As such, setting the TTBR_SHARE_OUTER bit does
indeed get coherent pagetable walks working nicely for the coherent
T620 in the Arm Juno SoC.

Reviewed-by: Steven Price 
Signed-off-by: Robin Murphy 
---
 drivers/iommu/io-pgtable-arm.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c
index dc7bcf858b6d..e47012006dcc 100644
--- a/drivers/iommu/io-pgtable-arm.c
+++ b/drivers/iommu/io-pgtable-arm.c
@@ -440,7 +440,7 @@ static arm_lpae_iopte arm_lpae_prot_to_pte(struct 
arm_lpae_io_pgtable *data,
<< ARM_LPAE_PTE_ATTRINDX_SHIFT);
}
 
-   if (prot & IOMMU_CACHE)
+   if (prot & IOMMU_CACHE && data->iop.fmt != ARM_MALI_LPAE)
pte |= ARM_LPAE_PTE_SH_IS;
else
pte |= ARM_LPAE_PTE_SH_OS;
@@ -1049,6 +1049,9 @@ arm_mali_lpae_alloc_pgtable(struct io_pgtable_cfg *cfg, 
void *cookie)
cfg->arm_mali_lpae_cfg.transtab = virt_to_phys(data->pgd) |
  ARM_MALI_LPAE_TTBR_READ_INNER |
  ARM_MALI_LPAE_TTBR_ADRMODE_TABLE;
+   if (cfg->coherent_walk)
+   cfg->arm_mali_lpae_cfg.transtab |= 
ARM_MALI_LPAE_TTBR_SHARE_OUTER;
+
return >iop;
 
 out_free_data:
-- 
2.28.0.dirty

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


[PATCH 3/3] arm64: dts: meson: Describe G12b GPU as coherent

2020-09-15 Thread Robin Murphy
According to a downstream commit I found in the Khadas vendor kernel,
the GPU on G12b is wired up for ACE-lite, so (now that Panfrost knows
how to handle this properly) we should describe it as such. Otherwise
the mismatch leads to all manner of fun with mismatched attributes and
inadvertently snooping stale data from caches, which would account for
at least some of the brokenness observed on this platform.

Signed-off-by: Robin Murphy 
---
 arch/arm64/boot/dts/amlogic/meson-g12b.dtsi | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm64/boot/dts/amlogic/meson-g12b.dtsi 
b/arch/arm64/boot/dts/amlogic/meson-g12b.dtsi
index 9b8548e5f6e5..ee8fcae9f9f0 100644
--- a/arch/arm64/boot/dts/amlogic/meson-g12b.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-g12b.dtsi
@@ -135,3 +135,7 @@ map1 {
};
};
 };
+
+ {
+   dma-coherent;
+};
-- 
2.28.0.dirty

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


[PATCH 0/3] drm: panfrost: Coherency support

2020-09-15 Thread Robin Murphy
Hi all,

I polished up my original proof-of-concept a little while back, but now
that I've got my hands on my Juno again I've been able to actually test
it to my satisfaction, so here are proper patches!

It probably makes sense for patches #1 and #2 to stay together and both
go via drm-misc, provided Will's OK with that.

Robin.


Robin Murphy (3):
  iommu/io-pgtable-arm: Support coherency for Mali LPAE
  drm/panfrost: Support cache-coherent integrations
  arm64: dts: meson: Describe G12b GPU as coherent

 arch/arm64/boot/dts/amlogic/meson-g12b.dtsi | 4 
 drivers/gpu/drm/panfrost/panfrost_device.h  | 1 +
 drivers/gpu/drm/panfrost/panfrost_drv.c | 2 ++
 drivers/gpu/drm/panfrost/panfrost_gem.c | 2 ++
 drivers/gpu/drm/panfrost/panfrost_mmu.c | 1 +
 drivers/iommu/io-pgtable-arm.c  | 5 -
 6 files changed, 14 insertions(+), 1 deletion(-)

-- 
2.28.0.dirty

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


Re: [git pull] virtio-shm region

2020-09-15 Thread Gurchetan Singh
On Tue, Sep 15, 2020 at 8:27 AM Maxime Ripard  wrote:

> Hi,
>
> On Mon, Sep 14, 2020 at 04:39:41PM -0700, Gurchetan Singh wrote:
> > Hi,
> >
> > This set of changes are required for zero-copy virtio-gpu.
> >
> > The following changes since commit
> 9123e3a74ec7b934a4a099e98af6a61c2f80bbf5:
> >
> >   Linux 5.9-rc1 (2020-08-16 13:04:57 -0700)
> >
> > are available in the Git repository at:
> >
> >   git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse.git
> virtio-shm
> >
> > for you to fetch changes up to 38e895487afc2ed42c11045853cbb3fa20b52b6e:
> >
> >   virtio: Implement get_shm_region for MMIO transport (2020-09-10
> 10:05:58
> > +0200)
> >
> > 
> > Sebastien Boeuf (3):
> >   virtio: Add get_shm_region method
> >   virtio: Implement get_shm_region for PCI transport
> >   virtio: Implement get_shm_region for MMIO transport
> >
> >  drivers/virtio/virtio_mmio.c   | 31 +
> >  drivers/virtio/virtio_pci_modern.c | 95
> > ++
> >  include/linux/virtio_config.h  | 17 +++
> >  include/uapi/linux/virtio_mmio.h   | 11 +
> >  include/uapi/linux/virtio_pci.h| 11 -
> >  5 files changed, 164 insertions(+), 1 deletion(-)
>
> It's not really clear who you expect to pull that PR?
>

Hmm, Daniel recommended "send[ing] the topic pull request to drm-misc
maintainers (Maarten, Maxime, Thomas)" in the other thread, but I'm not
really sure which one.  Maybe whomever is in charge of drm-misc-next pull
requests?


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


[PATCH] drm: rcar-du: Put reference to VSP device

2020-09-15 Thread Laurent Pinchart
The reference to the VSP device acquired with of_find_device_by_node()
in rcar_du_vsp_init() is never released. Fix it with a drmm action,
which gets run both in the probe error path and in the remove path.

Fixes: 6d62ef3ac30b ("drm: rcar-du: Expose the VSP1 compositor through KMS 
planes")
Reported-by: Yu Kuai 
Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c 
b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
index f1a81c9b184d..fa09b3ae8b9d 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -341,6 +342,13 @@ static const struct drm_plane_funcs 
rcar_du_vsp_plane_funcs = {
.atomic_destroy_state = rcar_du_vsp_plane_atomic_destroy_state,
 };
 
+static void rcar_du_vsp_cleanup(struct drm_device *dev, void *res)
+{
+   struct rcar_du_vsp *vsp = res;
+
+   put_device(vsp->vsp);
+}
+
 int rcar_du_vsp_init(struct rcar_du_vsp *vsp, struct device_node *np,
 unsigned int crtcs)
 {
@@ -357,6 +365,10 @@ int rcar_du_vsp_init(struct rcar_du_vsp *vsp, struct 
device_node *np,
 
vsp->vsp = >dev;
 
+   ret = drmm_add_action(rcdu->ddev, rcar_du_vsp_cleanup, vsp);
+   if (ret < 0)
+   return ret;
+
ret = vsp1_du_init(vsp->vsp);
if (ret < 0)
return ret;
-- 
Regards,

Laurent Pinchart

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


Re: [PATCH] drm: rcar-du: add missing put_device() call in rcar_du_vsp_init()

2020-09-15 Thread Laurent Pinchart
Hi Yu,

Thank you for the patch.

On Thu, Sep 10, 2020 at 09:23:54PM +0800, Yu Kuai wrote:
> if of_find_device_by_node() succeed, rcar_du_vsp_init() doesn't have
> a corresponding put_device(). Thus add a jump target to fix the exception
> handling for this function implementation.
> 
> Fixes: 6d62ef3ac30b ("drm: rcar-du: Expose the VSP1 compositor through KMS 
> planes")
> Signed-off-by: Yu Kuai 
> ---
>  drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 19 +--
>  1 file changed, 13 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c 
> b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> index f1a81c9b184d..172ee3f3b21c 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> @@ -352,14 +352,16 @@ int rcar_du_vsp_init(struct rcar_du_vsp *vsp, struct 
> device_node *np,
>  
>   /* Find the VSP device and initialize it. */
>   pdev = of_find_device_by_node(np);
> - if (!pdev)
> - return -ENXIO;
> + if (!pdev) {
> + ret = -ENXIO;
> + goto put_device;
> + }

This change isn't needed, and will actually cause a crash, as pdev is
NULL.

>  
>   vsp->vsp = >dev;
>  
>   ret = vsp1_du_init(vsp->vsp);
>   if (ret < 0)
> - return ret;
> + goto put_device;
>  
>/*
> * The VSP2D (Gen3) has 5 RPFs, but the VSP1D (Gen2) is limited to
> @@ -369,8 +371,10 @@ int rcar_du_vsp_init(struct rcar_du_vsp *vsp, struct 
> device_node *np,
>  
>   vsp->planes = devm_kcalloc(rcdu->dev, vsp->num_planes,
>  sizeof(*vsp->planes), GFP_KERNEL);
> - if (!vsp->planes)
> - return -ENOMEM;
> + if (!vsp->planes) {
> + ret = -ENOMEM;
> + goto put_device;
> + }
>  
>   for (i = 0; i < vsp->num_planes; ++i) {
>   enum drm_plane_type type = i < num_crtcs
> @@ -387,7 +391,7 @@ int rcar_du_vsp_init(struct rcar_du_vsp *vsp, struct 
> device_node *np,
>  ARRAY_SIZE(rcar_du_vsp_formats),
>  NULL, type, NULL);
>   if (ret < 0)
> - return ret;
> + goto put_device;
>  
>   drm_plane_helper_add(>plane,
>_du_vsp_plane_helper_funcs);
> @@ -403,4 +407,7 @@ int rcar_du_vsp_init(struct rcar_du_vsp *vsp, struct 
> device_node *np,
>   }
>  
>   return 0;

I would add a blank line here.

> +put_device:

And maybe name the label "error" ?

> + put_device(>dev);
> + return ret;
>  }

We need more than this, we also need to call put_device() when the
driver is unloaded. The way to handle cleanup in DRM is through
drmm_add_action() nowadays, and I think we could thus simply replace the
change above with a cleanup action that is run both in the error path
and at driver remove.

I'll post a proposal in a reply to this e-mail.

-- 
Regards,

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


Re: [RFC PATCH 1/3] drm: use flags instead of boolean in plane check

2020-09-15 Thread Laurent Pinchart
Hi Stefan,

Thank you for the patch.

On Thu, Sep 10, 2020 at 11:24:23AM +0200, Stefan Agner wrote:
> To improve readability and make it easier to add further optional checks
> replace the boolean parameters with a single flag bitfield as parameter
> of drm_atomic_helper_check_plane_state.
> 
> The regular call sites have been converted using a simple coccinelle
> patch.
> 
> virtual patch
> 
> @@
> expression e1, e2, e3, e4;
> symbol true, false;
> @@
> 
> (
> - drm_atomic_helper_check_plane_state(e1, e2, e3, e4, true, true)
> + drm_atomic_helper_check_plane_state(e1, e2, e3, e4, DRM_PLANE_CAN_POSITION 
> | DRM_PLANE_CAN_UPDATE_DISABLED)
> |
> - drm_atomic_helper_check_plane_state(e1, e2, e3, e4, true, false)
> + drm_atomic_helper_check_plane_state(e1, e2, e3, e4, DRM_PLANE_CAN_POSITION)
> |
> - drm_atomic_helper_check_plane_state(e1, e2, e3, e4, false, true)
> + drm_atomic_helper_check_plane_state(e1, e2, e3, e4, 
> DRM_PLANE_CAN_UPDATE_DISABLED)
> |
> - drm_atomic_helper_check_plane_state(e1, e2, e3, e4, false, false)
> + drm_atomic_helper_check_plane_state(e1, e2, e3, e4, 0)
> )
> 
> Signed-off-by: Stefan Agner 
> ---
> This implements what has been discussed in the thread of the patch
> "drm: mxsfb: check framebuffer pitch":
> https://lkml.org/lkml/2020/9/8/1342
> 
> Before sending it out to all maintainers I wanted to get conformation
> if the general approach is fine.

I think it's good, yes. As Daniel pointed out it's just missing
documentation.

> I think in some places there should be another linebreak for the flags,
> but this is what coccinelle gives me. Not sure if I should manually fix
> those places...

A break after | would indeed be nice. Sometimes manual edit is required,
although I've seen coccinelle indenting code correctly before. I'm no
expert in that area.

>  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |  5 ++--
>  drivers/gpu/drm/arm/hdlcd_crtc.c  |  6 ++---
>  drivers/gpu/drm/arm/malidp_planes.c   |  5 ++--
>  drivers/gpu/drm/armada/armada_plane.c |  3 ++-
>  drivers/gpu/drm/ast/ast_mode.c|  4 +--
>  .../gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c   |  4 +--
>  drivers/gpu/drm/drm_atomic_helper.c   | 17 +++--
>  drivers/gpu/drm/drm_plane_helper.c|  9 +++
>  drivers/gpu/drm/drm_simple_kms_helper.c   |  2 +-
>  drivers/gpu/drm/i915/display/intel_display.c  |  9 ---
>  drivers/gpu/drm/i915/display/intel_sprite.c   |  6 ++---
>  drivers/gpu/drm/imx/ipuv3-plane.c |  7 --
>  drivers/gpu/drm/ingenic/ingenic-drm-drv.c |  7 --
>  drivers/gpu/drm/mediatek/mtk_drm_plane.c  |  4 +--
>  drivers/gpu/drm/meson/meson_overlay.c |  2 +-
>  drivers/gpu/drm/meson/meson_plane.c   |  2 +-
>  drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c |  7 +++---
>  drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c|  4 +--
>  drivers/gpu/drm/mxsfb/mxsfb_kms.c |  2 +-
>  drivers/gpu/drm/nouveau/dispnv50/base507c.c   |  2 +-
>  drivers/gpu/drm/nouveau/dispnv50/curs507a.c   |  2 +-
>  drivers/gpu/drm/nouveau/dispnv50/ovly507e.c   |  2 +-
>  drivers/gpu/drm/nouveau/dispnv50/wndwc37e.c   |  2 +-
>  drivers/gpu/drm/rcar-du/rcar_du_plane.c   |  2 +-
>  drivers/gpu/drm/rockchip/rockchip_drm_vop.c   |  4 +--
>  .../gpu/drm/selftests/test-drm_plane_helper.c | 25 +--
>  drivers/gpu/drm/sun4i/sun8i_ui_layer.c|  2 +-
>  drivers/gpu/drm/sun4i/sun8i_vi_layer.c|  2 +-
>  drivers/gpu/drm/tegra/plane.c |  5 ++--
>  drivers/gpu/drm/tidss/tidss_plane.c   |  3 ++-
>  drivers/gpu/drm/vboxvideo/vbox_mode.c |  4 +--
>  drivers/gpu/drm/vc4/vc4_plane.c   |  3 ++-
>  drivers/gpu/drm/virtio/virtgpu_plane.c|  7 --
>  drivers/gpu/drm/vkms/vkms_plane.c |  8 +++---
>  drivers/gpu/drm/vmwgfx/vmwgfx_kms.c   |  4 +--
>  drivers/gpu/drm/xlnx/zynqmp_disp.c|  2 +-
>  drivers/gpu/drm/zte/zx_plane.c|  4 +--
>  include/drm/drm_atomic_helper.h   |  7 --
>  38 files changed, 108 insertions(+), 87 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index fd96fafec5b8..db0256ecf1a2 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -5731,8 +5731,9 @@ static int dm_plane_helper_check_state(struct 
> drm_plane_state *state,
>   int max_upscale = INT_MAX;
>  
>   /* TODO: These should be checked against DC plane caps */
> - return drm_atomic_helper_check_plane_state(
> - state, new_crtc_state, max_downscale, max_upscale, true, true);
> + return drm_atomic_helper_check_plane_state(state, new_crtc_state,
> +max_downscale, max_upscale,
> +DRM_PLANE_CAN_POSITION | 
> DRM_PLANE_CAN_UPDATE_DISABLED);
> 

Re: [RFC 1/5] drm/i915/dp: Program source OUI on eDP panels

2020-09-15 Thread Navare, Manasi
On Tue, Sep 15, 2020 at 03:47:01PM -0400, Lyude Paul wrote:
> On Tue, 2020-09-15 at 15:06 -0400, Rodrigo Vivi wrote:
> > On Tue, Sep 15, 2020 at 01:29:35PM -0400, Lyude Paul wrote:
> > > Since we're about to start adding support for Intel's magic HDR
> > > backlight interface over DPCD, we need to ensure we're properly
> > > programming this field so that Intel specific sink services are exposed.
> > > Otherwise, 0x300-0x3ff will just read zeroes.
> > > 
> > > We also take care not to reprogram the source OUI if it already matches
> > > what we expect. This is just to be careful so that we don't accidentally
> > > take the panel out of any backlight control modes we found it in.
> > > 
> > > Signed-off-by: Lyude Paul 
> > > Cc: thay...@noraisin.net
> > > Cc: Vasily Khoruzhick 
> > > ---
> > >  drivers/gpu/drm/i915/display/intel_dp.c | 32 +
> > >  1 file changed, 32 insertions(+)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > > b/drivers/gpu/drm/i915/display/intel_dp.c
> > > index 4bd10456ad188..b591672ec4eab 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > > @@ -3428,6 +3428,7 @@ void intel_dp_sink_set_decompression_state(struct
> > > intel_dp *intel_dp,
> > >  void intel_dp_sink_dpms(struct intel_dp *intel_dp, int mode)
> > >  {
> > >   struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> > > + u8 edp_oui[] = { 0x00, 0xaa, 0x01 };
> > 
> > what are these values?

We in i915 typically use the OUI number for adding any eDP specific
quirks. I have seen these getting spit out in the dmesg log at thebeginning.
AFAIK It is some kind of OEM identification number for a display panel.

Manasi
> 
> I wish I knew, my assumption is this is the OUI that Intel's GPU driver uses 
> on
> other platforms, but I don't have any documentation mentioning this (in fact,
> the few documents I do have on this backlight interface don't seem to make any
> mention of it). I only managed to find this when looking through the last
> attempt someone did at adding support for this backlight interface:
> 
> https://patchwork.freedesktop.org/patch/334989/
> 
> I think it should be fairly safe to write, as I know nouveau always programs a
> source OUI (we don't do it from our driver, but nvidia hardware seems to do it
> automatically) and I don't believe I've seen it ever change any behavior 
> besides
> making things appear in the 0x300-0x3ff register range.
> 
> AFAICT though, the backlight interface won't advertise itself without this 
> being
> set early on. If you could find anyone from Intel who knows more about it 
> though
> I'd definitely appreciate it (and just in general for the rest of the patch
> series as well)
> 
> > 
> > >   int ret, i;
> > >  
> > >   /* Should have a valid DPCD by this point */
> > > @@ -3443,6 +3444,14 @@ void intel_dp_sink_dpms(struct intel_dp *intel_dp,
> > > int mode)
> > >   } else {
> > >   struct intel_lspcon *lspcon = dp_to_lspcon(intel_dp);
> > >  
> > > + /* Write the source OUI as early as possible */
> > > + if (intel_dp_is_edp(intel_dp)) {
> > > + ret = drm_dp_dpcd_write(_dp->aux, DP_SOURCE_OUI,
> > > edp_oui,
> > > + sizeof(edp_oui));
> > > + if (ret < 0)
> > > + drm_err(>drm, "Failed to write eDP source
> > > OUI\n");
> > > + }
> > > +
> > >   /*
> > >* When turning on, we need to retry for 1ms to give the sink
> > >* time to wake up.
> > > @@ -4530,6 +4539,23 @@ static void intel_dp_get_dsc_sink_cap(struct 
> > > intel_dp
> > > *intel_dp)
> > >   }
> > >  }
> > >  
> > > +static void
> > > +intel_edp_init_source_oui(struct intel_dp *intel_dp)
> > > +{
> > > + struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> > > + u8 oui[] = { 0x00, 0xaa, 0x01 };
> > > + u8 buf[3] = { 0 };
> > > +
> > > + if (drm_dp_dpcd_read(_dp->aux, DP_SOURCE_OUI, buf, sizeof(buf)) <
> > > 0)
> > > + drm_err(>drm, "Failed to read source OUI\n");
> > > +
> > > + if (memcmp(oui, buf, sizeof(oui)) == 0)
> > > + return;
> > > +
> > > + if (drm_dp_dpcd_write(_dp->aux, DP_SOURCE_OUI, oui, sizeof(oui)) <
> > > 0)
> > > + drm_err(>drm, "Failed to write source OUI\n");
> > > +}
> > > +
> > >  static bool
> > >  intel_edp_init_dpcd(struct intel_dp *intel_dp)
> > >  {
> > > @@ -4607,6 +4633,12 @@ intel_edp_init_dpcd(struct intel_dp *intel_dp)
> > >   if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
> > >   intel_dp_get_dsc_sink_cap(intel_dp);
> > >  
> > > + /*
> > > +  * Program our source OUI so we can make various Intel-specific AUX
> > > +  * services available (such as HDR backlight controls)
> > > +  */
> > > + intel_edp_init_source_oui(intel_dp);
> > 
> > I believe we should restrict this to the supported platforms: cfl, whl, cml,
> > icl, tgl
> > no?
> > 
> > > +
> > >   return true;
> > >  }
> > >  
> > 

Re: General protection fault: RIP: 0010:free_block+0xdc/0x1f0

2020-09-15 Thread Dave Airlie
cc'ing some more people.

On Tue, 15 Sep 2020 at 23:07, Paul Menzel  wrote:
>
> Dear Andrew folks, dear Linux folks,
>
>
> With Linux 5.9-rc4 on a Dell OptiPlex 5080 with Intel Core i7-10700 CPU
> @ 2.90GHz, and external
>
>  01:00.0 VGA compatible controller [0300]: Advanced Micro Devices,
> Inc. [AMD/ATI] Oland [Radeon HD 8570 / R7 240/340 OEM] [1002:6611] (rev 87)
>
> running graphical demanding applications glmark2 [1] and the Phoronix
> Test Suite [2] benchmark *pts/desktop-graphics* [3]
>
>  $ git describe --tags
>  v10.0.0m1-13-g0b5ddc3c0
>
> I got three general protection faults, and it restarted or froze (no
> input devices working, screen froze and even network card (no ping)).
>
> Here the system restarted itself:
>
> > kernel: general protection fault, probably for non-canonical address 
> > 0xdead0100:  [#1] SMP NOPTI
> > kernel: CPU: 2 PID: 9702 Comm: glmark2 Kdump: loaded Not tainted 
> > 5.9.0-rc4.mx64.343 #1
> > kernel: Hardware name: Dell Inc. OptiPlex 5080/032W55, BIOS 1.1.7 08/17/2020
> > kernel: RIP: 0010:free_block+0xdc/0x1f0
>
> Here it froze:
>
> > [14639.665745] general protection fault, probably for non-canonical address 
> > 0xdead0100:  [#1] SMP NOPTI
> > [14639.675917] CPU: 15 PID: 23094 Comm: pvpython Kdump: loaded Not tainted 
> > 5.9.0-rc4.mx64.343 #1
> > [14639.684431] Hardware name: Dell Inc. OptiPlex 5080/032W55, BIOS 1.1.7 
> > 08/17/2020
> > [14639.691823] RIP: 0010:free_block+0xdc/0x1f0
>
> Here it froze:
>
> > kernel: general protection fault, probably for non-canonical address 
> > 0xdead0100:  [#1] SMP NOPTI
> > kernel: CPU: 15 PID: 23094 Comm: pvpython Kdump: loaded Not tainted 
> > 5.9.0-rc4.mx64.343 #1
> > kernel: Hardware name: Dell Inc. OptiPlex 5080/032W55, BIOS 1.1.7 08/17/2020
> > kernel: RIP: 0010:free_block+0xdc/0x1f0
>
> Running `scripts/decode_stacktrace.sh`:
>
> > linux-5.9_rc4-343.x86_64/source$ scripts/decode_stacktrace.sh vmlinux < 
> > optiplex-5080-linux-5.9-rc4-gp-pvpython.txt
> > [14528.718656] cgroup: fork rejected by pids controller in 
> > /user.slice/user-5272.slice/session-c6.scope
> > [14639.665745] general protection fault, probably for non-canonical address 
> > 0xdead0100:  [#1] SMP NOPTI
> > [14639.675917] CPU: 15 PID: 23094 Comm: pvpython Kdump: loaded Not tainted 
> > 5.9.0-rc4.mx64.343 #1
> > [14639.684431] Hardware name: Dell Inc. OptiPlex 5080/032W55, BIOS 1.1.7 
> > 08/17/2020
> > [14639.691823] RIP: 0010:free_block (./include/linux/list.h:112 
> > ./include/linux/list.h:135 ./include/linux/list.h:146 mm/slab.c:3336)
> > [14639.696006] Code: 00 48 01 d0 48 c1 e8 0c 48 c1 e0 06 4c 01 e8 48 8b 50 
> > 08 48 8d 4a ff 83 e2 01 48 0f 45 c1 48 8b 48 08 48 8b 50 10 4c 8d 78 08 
> > <48> 89 51 08 48 89 0a 4c 89 da 48 2b 50 28 4c 89 60 08 48 89 68 10
> > All code
> > 
> >0: 00 48 01add%cl,0x1(%rax)
> >3: d0 48 c1rorb   -0x3f(%rax)
> >6: e8 0c 48 c1 e0  callq  0xe0c14817
> >b: 06  (bad)
> >c: 4c 01 e8add%r13,%rax
> >f: 48 8b 50 08 mov0x8(%rax),%rdx
> >   13: 48 8d 4a ff lea-0x1(%rdx),%rcx
> >   17: 83 e2 01and$0x1,%edx
> >   1a: 48 0f 45 c1 cmovne %rcx,%rax
> >   1e: 48 8b 48 08 mov0x8(%rax),%rcx
> >   22: 48 8b 50 10 mov0x10(%rax),%rdx
> >   26: 4c 8d 78 08 lea0x8(%rax),%r15
> >   2a:*48 89 51 08 mov%rdx,0x8(%rcx)   <-- 
> > trapping instruction
> >   2e: 48 89 0amov%rcx,(%rdx)
> >   31: 4c 89 damov%r11,%rdx
> >   34: 48 2b 50 28 sub0x28(%rax),%rdx
> >   38: 4c 89 60 08 mov%r12,0x8(%rax)
> >   3c: 48 89 68 10 mov%rbp,0x10(%rax)
> >
> > Code starting with the faulting instruction
> > ===
> >0: 48 89 51 08 mov%rdx,0x8(%rcx)
> >4: 48 89 0amov%rcx,(%rdx)
> >7: 4c 89 damov%r11,%rdx
> >a: 48 2b 50 28 sub0x28(%rax),%rdx
> >e: 4c 89 60 08 mov%r12,0x8(%rax)
> >   12: 48 89 68 10 mov%rbp,0x10(%rax)
> > [14639.714747] RSP: 0018:c9001c26fab8 EFLAGS: 00010046
> > [14639.719970] RAX: ea000d193600 RBX: 8000 RCX: 
> > dead0100
> > [14639.727099] RDX: dead0122 RSI: 88842d5f3ef0 RDI: 
> > 88842b440300
> > [14639.734225] RBP: dead0122 R08: c9001c26fb30 R09: 
> > 88842b441280
> > [14639.741351] R10: 000f R11: 8883464d80c0 R12: 
> > dead0100
> > [14639.748477] R13: ea00 R14: 88842d5f3ff0 R15: 
> > ea000d193608
> > [14639.755604] FS:  7fd3b7e8f040() GS:88842d5c() 
> > knlGS:
> > [14639.763692] CS:  0010 DS:  ES:  CR0: 80050033
> > 

Re: [PATCH] drm: Kconfig: Update description for DRM_RCAR_DW_HDMI config

2020-09-15 Thread Laurent Pinchart
Hi Prabhakar,

Thank you for the patch.

On Fri, Sep 11, 2020 at 11:07:41AM +0100, Lad Prabhakar wrote:
> rcar_dw_hdmi driver is also used on Renesas RZ/G2 SoC's, update the
> same to reflect the description for DRM_RCAR_DW_HDMI config.

I'm not sure what you mean by "the same" here. I'd propose

The rcar_dw_hdmi driver is also used on Renesas RZ/G2 SoCs. Update the
Kconfig entry description to reflect this.

Reviewed-by: Laurent Pinchart 

If you're fine with that, there's no need to resubmit the patch.

> Signed-off-by: Lad Prabhakar 
> Reviewed-by: Chris Paterson 
> ---
>  drivers/gpu/drm/rcar-du/Kconfig | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/rcar-du/Kconfig b/drivers/gpu/drm/rcar-du/Kconfig
> index f65d1489dc50..bd8b43fb9753 100644
> --- a/drivers/gpu/drm/rcar-du/Kconfig
> +++ b/drivers/gpu/drm/rcar-du/Kconfig
> @@ -22,11 +22,11 @@ config DRM_RCAR_CMM
> Enable support for R-Car Color Management Module (CMM).
>  
>  config DRM_RCAR_DW_HDMI
> - tristate "R-Car DU Gen3 HDMI Encoder Support"
> + tristate "R-Car Gen3 and RZ/G2 DU HDMI Encoder Support"
>   depends on DRM && OF
>   select DRM_DW_HDMI
>   help
> -   Enable support for R-Car Gen3 internal HDMI encoder.
> +   Enable support for R-Car Gen3 or RZ/G2 internal HDMI encoder.
>  
>  config DRM_RCAR_LVDS
>   tristate "R-Car DU LVDS Encoder Support"

-- 
Regards,

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


Re: [PATCH v2] drm/amdgpu/dc: Require primary plane to be enabled whenever the CRTC is

2020-09-15 Thread Alex Deucher
Applied.  Thanks!

Alex

On Mon, Sep 14, 2020 at 10:37 AM Kazlauskas, Nicholas
 wrote:
>
> On 2020-09-14 3:52 a.m., Michel Dänzer wrote:
> > On 2020-09-07 9:57 a.m., Daniel Vetter wrote:
> >> On Fri, Sep 04, 2020 at 12:43:04PM +0200, Michel Dänzer wrote:
> >>> From: Michel Dänzer 
> >>>
> >>> Don't check drm_crtc_state::active for this either, per its
> >>> documentation in include/drm/drm_crtc.h:
> >>>
> >>>   * Hence drivers must not consult @active in their various
> >>>   * _mode_config_funcs.atomic_check callback to reject an atomic
> >>>   * commit.
> >>>
> >>> atomic_remove_fb disables the CRTC as needed for disabling the primary
> >>> plane.
> >>>
> >>> This prevents at least the following problems if the primary plane gets
> >>> disabled (e.g. due to destroying the FB assigned to the primary plane,
> >>> as happens e.g. with mutter in Wayland mode):
> >>>
> >>> * The legacy cursor ioctl returned EINVAL for a non-0 cursor FB ID
> >>>(which enables the cursor plane).
> >>> * If the cursor plane was enabled, changing the legacy DPMS property
> >>>value from off to on returned EINVAL.
> >>>
> >>> v2:
> >>> * Minor changes to code comment and commit log, per review feedback.
> >>>
> >>> GitLab:
> >>> https://gitlab.gnome.org/GNOME/mutter/-/issues/1108
> >>>
> >>> GitLab:
> >>> https://gitlab.gnome.org/GNOME/mutter/-/issues/1165
> >>>
> >>> GitLab:
> >>> https://gitlab.gnome.org/GNOME/mutter/-/issues/1344
> >>>
> >>> Suggested-by: Daniel Vetter 
> >>> Signed-off-by: Michel Dänzer 
> >>
> >> Commit message agrees with my understand of this maze now, so:
> >>
> >> Acked-by: Daniel Vetter 
> >
> > Thanks Daniel!
> >
> >
> > Nick / Harry, any more feedback? If not, can you apply this?
> >
> >
> > P.S. Since DCN doesn't make a distinction between primary or overlay
> > planes in hardware, could ChromiumOS achieve the same effect with only
> > the primary plane instead of only an overlay plane? If so, maybe there's
> > no need for the "black plane hack".
> >
> >
>
> I only know that atomictest tries to enable this configuration. Not sure
> if ChromiumOS or other "real" userspace tries this configuration.
>
> Maybe for now this can go in and if something breaks we can deal with
> the fallout then. We can always go back to lying to userspace about the
> cursor being visible if the commit fails in that case I guess since the
> blank plane hack is going to add a significant amount of complexity to DM.
>
> Reviewed-by: Nicholas Kazlauskas 
>
> Regards,
> Nicholas Kazlauskas
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [RFC 1/5] drm/i915/dp: Program source OUI on eDP panels

2020-09-15 Thread Lyude Paul
On Tue, 2020-09-15 at 15:06 -0400, Rodrigo Vivi wrote:
> On Tue, Sep 15, 2020 at 01:29:35PM -0400, Lyude Paul wrote:
> > Since we're about to start adding support for Intel's magic HDR
> > backlight interface over DPCD, we need to ensure we're properly
> > programming this field so that Intel specific sink services are exposed.
> > Otherwise, 0x300-0x3ff will just read zeroes.
> > 
> > We also take care not to reprogram the source OUI if it already matches
> > what we expect. This is just to be careful so that we don't accidentally
> > take the panel out of any backlight control modes we found it in.
> > 
> > Signed-off-by: Lyude Paul 
> > Cc: thay...@noraisin.net
> > Cc: Vasily Khoruzhick 
> > ---
> >  drivers/gpu/drm/i915/display/intel_dp.c | 32 +
> >  1 file changed, 32 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > b/drivers/gpu/drm/i915/display/intel_dp.c
> > index 4bd10456ad188..b591672ec4eab 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > @@ -3428,6 +3428,7 @@ void intel_dp_sink_set_decompression_state(struct
> > intel_dp *intel_dp,
> >  void intel_dp_sink_dpms(struct intel_dp *intel_dp, int mode)
> >  {
> > struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> > +   u8 edp_oui[] = { 0x00, 0xaa, 0x01 };
> 
> what are these values?

I wish I knew, my assumption is this is the OUI that Intel's GPU driver uses on
other platforms, but I don't have any documentation mentioning this (in fact,
the few documents I do have on this backlight interface don't seem to make any
mention of it). I only managed to find this when looking through the last
attempt someone did at adding support for this backlight interface:

https://patchwork.freedesktop.org/patch/334989/

I think it should be fairly safe to write, as I know nouveau always programs a
source OUI (we don't do it from our driver, but nvidia hardware seems to do it
automatically) and I don't believe I've seen it ever change any behavior besides
making things appear in the 0x300-0x3ff register range.

AFAICT though, the backlight interface won't advertise itself without this being
set early on. If you could find anyone from Intel who knows more about it though
I'd definitely appreciate it (and just in general for the rest of the patch
series as well)

> 
> > int ret, i;
> >  
> > /* Should have a valid DPCD by this point */
> > @@ -3443,6 +3444,14 @@ void intel_dp_sink_dpms(struct intel_dp *intel_dp,
> > int mode)
> > } else {
> > struct intel_lspcon *lspcon = dp_to_lspcon(intel_dp);
> >  
> > +   /* Write the source OUI as early as possible */
> > +   if (intel_dp_is_edp(intel_dp)) {
> > +   ret = drm_dp_dpcd_write(_dp->aux, DP_SOURCE_OUI,
> > edp_oui,
> > +   sizeof(edp_oui));
> > +   if (ret < 0)
> > +   drm_err(>drm, "Failed to write eDP source
> > OUI\n");
> > +   }
> > +
> > /*
> >  * When turning on, we need to retry for 1ms to give the sink
> >  * time to wake up.
> > @@ -4530,6 +4539,23 @@ static void intel_dp_get_dsc_sink_cap(struct intel_dp
> > *intel_dp)
> > }
> >  }
> >  
> > +static void
> > +intel_edp_init_source_oui(struct intel_dp *intel_dp)
> > +{
> > +   struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> > +   u8 oui[] = { 0x00, 0xaa, 0x01 };
> > +   u8 buf[3] = { 0 };
> > +
> > +   if (drm_dp_dpcd_read(_dp->aux, DP_SOURCE_OUI, buf, sizeof(buf)) <
> > 0)
> > +   drm_err(>drm, "Failed to read source OUI\n");
> > +
> > +   if (memcmp(oui, buf, sizeof(oui)) == 0)
> > +   return;
> > +
> > +   if (drm_dp_dpcd_write(_dp->aux, DP_SOURCE_OUI, oui, sizeof(oui)) <
> > 0)
> > +   drm_err(>drm, "Failed to write source OUI\n");
> > +}
> > +
> >  static bool
> >  intel_edp_init_dpcd(struct intel_dp *intel_dp)
> >  {
> > @@ -4607,6 +4633,12 @@ intel_edp_init_dpcd(struct intel_dp *intel_dp)
> > if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
> > intel_dp_get_dsc_sink_cap(intel_dp);
> >  
> > +   /*
> > +* Program our source OUI so we can make various Intel-specific AUX
> > +* services available (such as HDR backlight controls)
> > +*/
> > +   intel_edp_init_source_oui(intel_dp);
> 
> I believe we should restrict this to the supported platforms: cfl, whl, cml,
> icl, tgl
> no?
> 
> > +
> > return true;
> >  }
> >  
> > -- 
> > 2.26.2
> > 
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
-- 
Sincerely,
  Lyude Paul (she/her)
  Software Engineer at Red Hat

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


Re: [PATCH -next] drm/amd/display: Create trigger_hotplug entry

2020-09-15 Thread Alex Deucher
Applied.  Thanks!

Alex

On Thu, Sep 10, 2020 at 11:35 AM Harry Wentland  wrote:
>
> On 2020-09-09 11:13 p.m., YueHaibing wrote:
> > Add trigger_hotplug debugfs entry.
> >
> > Fixes: 6f77b2ac6280 ("drm/amd/display: Add connector HPD trigger debugfs 
> > entry")
> > Signed-off-by: YueHaibing 
>
> Reviewed-by: Harry Wentland 
>
> Harry
>
> > ---
> >   drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 1 +
> >   1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c 
> > b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
> > index 94fcb086154c..83da24aced45 100644
> > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
> > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
> > @@ -2098,6 +2098,7 @@ static const struct {
> >   const struct file_operations *fops;
> >   } dp_debugfs_entries[] = {
> >   {"link_settings", _link_settings_debugfs_fops},
> > + {"trigger_hotplug", _trigger_hotplug_debugfs_fops},
> >   {"phy_settings", _phy_settings_debugfs_fop},
> >   {"test_pattern", _phy_test_pattern_fops},
> >   #ifdef CONFIG_DRM_AMD_DC_HDCP
> >
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH -next] drm/amd/display: Fix possible memleak in dp_trigger_hotplug()

2020-09-15 Thread Alex Deucher
Applied.  Thanks,

Alex

On Thu, Sep 10, 2020 at 11:34 AM Harry Wentland  wrote:
>
> On 2020-09-09 11:26 p.m., YueHaibing wrote:
> > If parse_write_buffer_into_params() fails, we should free
> > wr_buf before return.
> >
> > Fixes: 6f77b2ac6280 ("drm/amd/display: Add connector HPD trigger debugfs 
> > entry")
> > Signed-off-by: YueHaibing 
>
> Reviewed-by: Harry Wentland 
>
> Harry
>
> > ---
> >   drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 4 +++-
> >   1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c 
> > b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
> > index 83da24aced45..11e16fbe484d 100644
> > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
> > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
> > @@ -1089,8 +1089,10 @@ static ssize_t dp_trigger_hotplug(struct file *f, 
> > const char __user *buf,
> >   if (parse_write_buffer_into_params(wr_buf, wr_buf_size,
> >   (long *)param, buf,
> >   max_param_num,
> > - _nums))
> > + _nums)) {
> > + kfree(wr_buf);
> >   return -EINVAL;
> > + }
> >
> >   if (param_nums <= 0) {
> >   DRM_DEBUG_DRIVER("user data not be read\n");
> >
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v2 10/16] drm/exynos: implement a drm bridge

2020-09-15 Thread Andrzej Hajda
Hi again,

W dniu 14.09.2020 o 23:19, Andrzej Hajda pisze:
> Hi Marek, Michael,
>
> On 14.09.2020 22:01, Michael Tretter wrote:
>> Hi,
>>
>> On Mon, 14 Sep 2020 14:31:19 +0200, Marek Szyprowski wrote:
>>> On 14.09.2020 10:29, Marek Szyprowski wrote:
 On 11.09.2020 15:54, Michael Tretter wrote:
> Make the exynos_dsi driver a full drm bridge that can be found and 
> used
> from other drivers.
>
> Other drivers can only attach to the bridge, if a mipi dsi device
> already attached to the bridge. This allows to defer the probe of the
> display pipe until the downstream bridges are available, too.
>
> Signed-off-by: Michael Tretter 
 This one (and the whole series applied) still fails on Exynos boards:

 [drm] Exynos DRM: using 11c0.fimd device for DMA mapping 
 operations
 exynos-drm exynos-drm: bound 11c0.fimd (ops fimd_component_ops)
 OF: graph: no port node found in /soc/dsi@11c8
 8<--- cut here ---
 Unable to handle kernel NULL pointer dereference at virtual address 
 0084
 pgd = (ptrval)
 [0084] *pgd=
 Internal error: Oops: 5 [#1] PREEMPT SMP ARM
 Modules linked in:
 CPU: 1 PID: 1 Comm: swapper/0 Not tainted
 5.9.0-rc4-next-20200911-00010-g417dc70d70ec #1608
 Hardware name: Samsung Exynos (Flattened Device Tree)
 PC is at drm_bridge_attach+0x18/0x164
 LR is at exynos_dsi_bind+0x88/0xa8
 pc : []    lr : []    psr: 2013
 sp : ef0dfca8  ip : 0002  fp : c13190e0
 r10:   r9 : ee46d580  r8 : c13190e0
 r7 : ee438800  r6 : 0018  r5 : ef253810  r4 : ef39e840
 r3 :   r2 : 0018  r1 : ef39e888  r0 : ef39e840
 Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
 Control: 10c5387d  Table: 4000404a  DAC: 0051
 Process swapper/0 (pid: 1, stack limit = 0x(ptrval))
 Stack: (0xef0dfca8 to 0xef0e)
 ...
 [] (drm_bridge_attach) from []
 (exynos_dsi_bind+0x88/0xa8)
 [] (exynos_dsi_bind) from []
 (component_bind_all+0xfc/0x290)
 [] (component_bind_all) from []
 (exynos_drm_bind+0xe4/0x19c)
 [] (exynos_drm_bind) from []
 (try_to_bring_up_master+0x1e4/0x2c4)
 [] (try_to_bring_up_master) from []
 (component_master_add_with_match+0xd4/0x108)
 [] (component_master_add_with_match) from []
 (exynos_drm_platform_probe+0xe4/0x110)
 [] (exynos_drm_platform_probe) from []
 (platform_drv_probe+0x6c/0xa4)
 [] (platform_drv_probe) from []
 (really_probe+0x200/0x4fc)
 [] (really_probe) from []
 (driver_probe_device+0x78/0x1fc)
 [] (driver_probe_device) from []
 (device_driver_attach+0x58/0x60)
 [] (device_driver_attach) from []
 (__driver_attach+0xdc/0x174)
 [] (__driver_attach) from []
 (bus_for_each_dev+0x68/0xb4)
 [] (bus_for_each_dev) from []
 (bus_add_driver+0x158/0x214)
 [] (bus_add_driver) from [] 
 (driver_register+0x78/0x110)
 [] (driver_register) from []
 (exynos_drm_init+0xe4/0x118)
 [] (exynos_drm_init) from []
 (do_one_initcall+0x8c/0x42c)
 [] (do_one_initcall) from []
 (kernel_init_freeable+0x190/0x1dc)
 [] (kernel_init_freeable) from []
 (kernel_init+0x8/0x118)
 [] (kernel_init) from [] (ret_from_fork+0x14/0x20)
 Exception stack(0xef0dffb0 to 0xef0dfff8)
 ...
 ---[ end trace ee27f313f9ed9da1 ]---

 # arm-linux-gnueabi-addr2line -e vmlinux c0628c08
 drivers/gpu/drm/drm_bridge.c:184 (discriminator 1)

 I will try to debug it a bit more today.
>>> The above crash has been caused by lack of in_bridge initialization to
>>> NULL in exynos_dsi_bind() in this patch. However, fixing it reveals
>>> another issue:
>>>
>>> [drm] Exynos DRM: using 11c0.fimd device for DMA mapping operations
>>> exynos-drm exynos-drm: bound 11c0.fimd (ops fimd_component_ops)
>>> OF: graph: no port node found in /soc/dsi@11c8
>>> 8<--- cut here ---
>>> Unable to handle kernel NULL pointer dereference at virtual address 
>>> 0280
>>> pgd = (ptrval)
>>> [0280] *pgd=
>>> Internal error: Oops: 5 [#1] PREEMPT SMP ARM
>>> Modules linked in:
>>> CPU: 0 PID: 1 Comm: swapper/0 Not tainted
>>> 5.9.0-rc4-next-20200911-00010-g417dc70d70ec-dirty #1613
>>> Hardware name: Samsung Exynos (Flattened Device Tree)
>>> PC is at __mutex_lock+0x54/0xb18
>>> LR is at lock_is_held_type+0x80/0x138
>>> pc : []    lr : []    psr: 6013
>>> sp : ef0dfd30  ip : 33937b74  fp : c13193c8
>>> r10: c1208eec  r9 :   r8 : ee45f808
>>> r7 : c19561a4  r6 :   r5 :   r4 : 024c
>>> r3 :   r2 : 00204140  r1 : c124f13c  r0 : 
>>> Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
>>> Control: 10c5387d  Table: 4000404a  DAC: 0051
>>> Process swapper/0 (pid: 1, stack limit = 0x(ptrval))
>>> Stack: (0xef0dfd30 to 0xef0e)
>>> ...
>>> [] (__mutex_lock) from [] 
>>> (mutex_lock_nested+0x1c/0x24)
>>> [] 

Re: [PATCH -next 0/8] drm/amd/amdgpu: fix comparison pointer to bool warning

2020-09-15 Thread Ville Syrjälä
On Tue, Sep 15, 2020 at 03:16:32PM -0400, Alex Deucher wrote:
> I question the value of these warnings.  Why even have a boolean type
> if you are going to get warnings when you use them...
> That said, applied to avoid getting these patches again and again
> every time someone sees this.

if (this_is_sparta)
if (this_is_sparta == true)
if (this_is_sparta != false)

I think the first one reads the best, and avoids having to
decide between truth and falsehood :)

> 
> Alex
> 
> On Wed, Sep 9, 2020 at 9:21 AM Christian König  
> wrote:
> >
> > Acked-by: Christian König  for the series.
> >
> > Am 09.09.20 um 15:07 schrieb Zheng Bin:
> > > Zheng Bin (8):
> > >drm/amd/amdgpu: fix comparison pointer to bool warning in gfx_v9_0.c
> > >drm/amd/amdgpu: fix comparison pointer to bool warning in gfx_v10_0.c
> > >drm/amd/amdgpu: fix comparison pointer to bool warning in sdma_v5_0.c
> > >drm/amd/amdgpu: fix comparison pointer to bool warning in sdma_v5_2.c
> > >drm/amd/amdgpu: fix comparison pointer to bool warning in si.c
> > >drm/amd/amdgpu: fix comparison pointer to bool warning in uvd_v6_0.c
> > >drm/amd/amdgpu: fix comparison pointer to bool warning in
> > >  amdgpu_atpx_handler.c
> > >drm/amd/amdgpu: fix comparison pointer to bool warning in sdma_v4_0.c
> > >
> > >   drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c | 4 ++--
> > >   drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c   | 2 +-
> > >   drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c| 2 +-
> > >   drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c   | 4 ++--
> > >   drivers/gpu/drm/amd/amdgpu/sdma_v5_0.c   | 2 +-
> > >   drivers/gpu/drm/amd/amdgpu/sdma_v5_2.c   | 2 +-
> > >   drivers/gpu/drm/amd/amdgpu/si.c  | 2 +-
> > >   drivers/gpu/drm/amd/amdgpu/uvd_v6_0.c| 4 ++--
> > >   8 files changed, 11 insertions(+), 11 deletions(-)
> > >
> > > --
> > > 2.26.0.106.g9fadedd
> > >
> >
> > ___
> > amd-gfx mailing list
> > amd-...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/amd-gfx
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

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


Re: [PATCH -next] drm/ttm/agp: Fix Wunused-variable warning

2020-09-15 Thread Alex Deucher
This function no longer exists.

Alex

On Thu, Sep 10, 2020 at 4:56 AM Christian König
 wrote:
>
> Am 10.09.20 um 04:33 schrieb YueHaibing:
> > If CONFIG_AGP is not set, gcc warns:
> >
> > drivers/gpu/drm/radeon/radeon_ttm.c: In function ‘radeon_ttm_tt_bind’:
> > drivers/gpu/drm/radeon/radeon_ttm.c:692:24: warning: unused variable ‘rdev’ 
> > [-Wunused-variable]
> >struct radeon_device *rdev = radeon_get_rdev(bdev);
> >  ^~~~
> >
> > Move it to ifdef block to fix this.
> >
> > Signed-off-by: YueHaibing 
>
> Reviewed-by: Christian König 
>
> > ---
> >   drivers/gpu/drm/radeon/radeon_ttm.c | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c 
> > b/drivers/gpu/drm/radeon/radeon_ttm.c
> > index 31c63d339629..449e77eb75f9 100644
> > --- a/drivers/gpu/drm/radeon/radeon_ttm.c
> > +++ b/drivers/gpu/drm/radeon/radeon_ttm.c
> > @@ -689,9 +689,9 @@ static int radeon_ttm_tt_bind(struct ttm_bo_device 
> > *bdev,
> > struct ttm_tt *ttm,
> > struct ttm_resource *bo_mem)
> >   {
> > +#if IS_ENABLED(CONFIG_AGP)
> >   struct radeon_device *rdev = radeon_get_rdev(bdev);
> >
> > -#if IS_ENABLED(CONFIG_AGP)
> >   if (rdev->flags & RADEON_IS_AGP)
> >   return ttm_agp_bind(ttm, bo_mem);
> >   #endif
>
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [RFC 4/5] drm/i915: Enable Intel's HDR backlight interface (only SDR for now)

2020-09-15 Thread Rodrigo Vivi
On Tue, Sep 15, 2020 at 01:29:38PM -0400, Lyude Paul wrote:
> So-recently a bunch of laptops on the market have started using DPCD
> backlight controls instead of the traditional DDI backlight controls.
> Originally we thought we had this handled by adding VESA backlight
> control support to i915, but the story ended up being a lot more
> complicated then that.
> 
> Simply put-there's two main backlight interfaces Intel can see in the
> wild. Intel's proprietary HDR backlight interface, and the standard VESA
> backlight interface. Note that many panels have been observed to report
> support for both backlight interfaces, but testing has shown far more
> panels work with the Intel HDR backlight interface at the moment.
> Additionally, the VBT appears to be capable of reporting support for the
> VESA backlight interface but not the Intel HDR interface which needs to
> be probed by setting the right magic OUI.
> 
> On top of that however, there's also actually two different variants of
> the Intel HDR backlight interface. The first uses the AUX channel for
> controlling the brightness of the screen in both SDR and HDR mode, and
> the second only uses the AUX channel for setting the brightness level in
> HDR mode - relying on PWM for setting the brightness level in SDR mode.
> 
> For the time being we've been using EDIDs to maintain a list of quirks
> for panels that safely do support the VESA backlight interface. Adding
> support for Intel's HDR backlight interface in addition however, should
> finally allow us to auto-detect eDP backlight controls properly so long
> as we probe like so:
> 
> * If the panel's VBT reports VESA backlight support, assume it really
>   does support it
> * If the panel's VBT reports DDI backlight controls:
>   * First probe for Intel's HDR backlight interface
>   * If that fails, probe for VESA's backlight interface
>   * If that fails, assume no DPCD backlight control
> * If the panel's VBT reports any other backlight type: just assume it
>   doesn't have DPCD backlight controls
> 
> Note as well that in order for us to make Intel's HDR backlight
> interface appear, we need to start programming the appropriate source
> OUI on the eDP panel as early as possible in the probing process. Note
> that this technically could be done at any time before setting up
> backlight controls, but this way allows us to avoid re-writing it
> multiple times in case we need to use other source-OUI enabled features
> in the future.
> 
> Finally, we also make sure to document the registers for this backlight
> interface since eventually, we want to actually implement the full
> interface instead of keeping it in SDR mode.
> 
> Signed-off-by: Lyude Paul 
> Cc: thay...@noraisin.net
> Cc: Vasily Khoruzhick 
> ---
>  .../drm/i915/display/intel_display_types.h|   9 +-
>  .../drm/i915/display/intel_dp_aux_backlight.c | 384 +++---
>  drivers/gpu/drm/i915/display/intel_panel.c|  34 +-
>  drivers/gpu/drm/i915/display/intel_panel.h|   4 +
>  drivers/gpu/drm/i915/i915_params.c|   2 +-
>  5 files changed, 381 insertions(+), 52 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
> b/drivers/gpu/drm/i915/display/intel_display_types.h
> index 52a6543df842a..9d540368bac89 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -230,7 +230,14 @@ struct intel_panel {
>   struct pwm_state pwm_state;
>  
>   /* DPCD backlight */
> - u8 pwmgen_bit_count;
> + union {
> + struct {
> + u8 pwmgen_bit_count;
> + } vesa;
> + struct {
> + bool sdr_uses_aux;
> + } intel;
> + } edp;
>  
>   struct {
>   int (*setup)(struct intel_connector *connector, enum 
> pipe pipe);
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c 
> b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> index acbd7eb66cbe3..aa1429302db70 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> @@ -22,10 +22,251 @@
>   *
>   */
>  
> +/*
> + * Laptops with Intel GPUs which have panels that support controlling the
> + * backlight through DP AUX can actually use two different interfaces: 
> Intel's
> + * proprietary DP AUX backlight interface, and the standard VESA backlight
> + * interface. Unfortunately, at the time of writing this a lot of laptops 
> will
> + * advertise support for the standard VESA backlight interface when they
> + * don't properly support it. However, on these systems the Intel backlight
> + * interface generally does work properly. Additionally, these systems will
> + * usually just indicate that they use PWM backlight controls in their VBIOS
> + * for some reason.
> + */
> +
>  

Re: [PATCH] drm/amd/display: optimize code runtime a bit

2020-09-15 Thread Alex Deucher
Applied.  Thanks!

Alex

On Thu, Sep 10, 2020 at 3:23 AM Bernard Zhao  wrote:
>
> In fnction is_cr_done & is_ch_eq_done, when done = false
> happened once, no need to circle left ln_count.
> This change is to make the code run a bit fast.
>
> Signed-off-by: Bernard Zhao 
> ---
>  drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c | 14 +-
>  1 file changed, 5 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c 
> b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
> index b2be6ad5101d..53e30be8b66a 100644
> --- a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
> +++ b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
> @@ -373,34 +373,30 @@ static void dpcd_set_lt_pattern_and_lane_settings(
>  static bool is_cr_done(enum dc_lane_count ln_count,
> union lane_status *dpcd_lane_status)
>  {
> -   bool done = true;
> uint32_t lane;
> /*LANEx_CR_DONE bits All 1's?*/
> for (lane = 0; lane < (uint32_t)(ln_count); lane++) {
> if (!dpcd_lane_status[lane].bits.CR_DONE_0)
> -   done = false;
> +   return false;
> }
> -   return done;
> -
> +   return true;
>  }
>
>  static bool is_ch_eq_done(enum dc_lane_count ln_count,
> union lane_status *dpcd_lane_status,
> union lane_align_status_updated *lane_status_updated)
>  {
> -   bool done = true;
> uint32_t lane;
> if (!lane_status_updated->bits.INTERLANE_ALIGN_DONE)
> -   done = false;
> +   return false;
> else {
> for (lane = 0; lane < (uint32_t)(ln_count); lane++) {
> if (!dpcd_lane_status[lane].bits.SYMBOL_LOCKED_0 ||
> 
> !dpcd_lane_status[lane].bits.CHANNEL_EQ_DONE_0)
> -   done = false;
> +   return false;
> }
> }
> -   return done;
> -
> +   return true;
>  }
>
>  static void update_drive_settings(
> --
> 2.28.0
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH -next 0/8] drm/amd/amdgpu: fix comparison pointer to bool warning

2020-09-15 Thread Alex Deucher
I question the value of these warnings.  Why even have a boolean type
if you are going to get warnings when you use them...
That said, applied to avoid getting these patches again and again
every time someone sees this.

Alex

On Wed, Sep 9, 2020 at 9:21 AM Christian König  wrote:
>
> Acked-by: Christian König  for the series.
>
> Am 09.09.20 um 15:07 schrieb Zheng Bin:
> > Zheng Bin (8):
> >drm/amd/amdgpu: fix comparison pointer to bool warning in gfx_v9_0.c
> >drm/amd/amdgpu: fix comparison pointer to bool warning in gfx_v10_0.c
> >drm/amd/amdgpu: fix comparison pointer to bool warning in sdma_v5_0.c
> >drm/amd/amdgpu: fix comparison pointer to bool warning in sdma_v5_2.c
> >drm/amd/amdgpu: fix comparison pointer to bool warning in si.c
> >drm/amd/amdgpu: fix comparison pointer to bool warning in uvd_v6_0.c
> >drm/amd/amdgpu: fix comparison pointer to bool warning in
> >  amdgpu_atpx_handler.c
> >drm/amd/amdgpu: fix comparison pointer to bool warning in sdma_v4_0.c
> >
> >   drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c | 4 ++--
> >   drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c   | 2 +-
> >   drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c| 2 +-
> >   drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c   | 4 ++--
> >   drivers/gpu/drm/amd/amdgpu/sdma_v5_0.c   | 2 +-
> >   drivers/gpu/drm/amd/amdgpu/sdma_v5_2.c   | 2 +-
> >   drivers/gpu/drm/amd/amdgpu/si.c  | 2 +-
> >   drivers/gpu/drm/amd/amdgpu/uvd_v6_0.c| 4 ++--
> >   8 files changed, 11 insertions(+), 11 deletions(-)
> >
> > --
> > 2.26.0.106.g9fadedd
> >
>
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [RFC 2/5] drm/i915: Rename pwm_* backlight callbacks to ext_pwm_*

2020-09-15 Thread Rodrigo Vivi
On Tue, Sep 15, 2020 at 01:29:36PM -0400, Lyude Paul wrote:
> Since we're going to need to add a set of lower-level PWM backlight
> control hooks to be shared by normal backlight controls and HDR
> backlight controls in SDR mode, let's add a prefix to the external PWM
> backlight functions so that the difference between them and the high
> level PWM-only backlight functions is a bit more obvious.

it looks like a good idea to me:

Reviewed-by: Rodrigo Vivi 

> 
> This introduces no functional changes.
> 
> Signed-off-by: Lyude Paul 
> Cc: thay...@noraisin.net
> Cc: Vasily Khoruzhick 
> ---
>  drivers/gpu/drm/i915/display/intel_panel.c | 24 +++---
>  1 file changed, 12 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_panel.c 
> b/drivers/gpu/drm/i915/display/intel_panel.c
> index 9f23bac0d7924..c0e36244bb07d 100644
> --- a/drivers/gpu/drm/i915/display/intel_panel.c
> +++ b/drivers/gpu/drm/i915/display/intel_panel.c
> @@ -589,7 +589,7 @@ static u32 bxt_get_backlight(struct intel_connector 
> *connector)
>BXT_BLC_PWM_DUTY(panel->backlight.controller));
>  }
>  
> -static u32 pwm_get_backlight(struct intel_connector *connector)
> +static u32 ext_pwm_get_backlight(struct intel_connector *connector)
>  {
>   struct intel_panel *panel = >panel;
>   struct pwm_state state;
> @@ -666,7 +666,7 @@ static void bxt_set_backlight(const struct 
> drm_connector_state *conn_state, u32
>  BXT_BLC_PWM_DUTY(panel->backlight.controller), level);
>  }
>  
> -static void pwm_set_backlight(const struct drm_connector_state *conn_state, 
> u32 level)
> +static void ext_pwm_set_backlight(const struct drm_connector_state 
> *conn_state, u32 level)
>  {
>   struct intel_panel *panel = 
> _intel_connector(conn_state->connector)->panel;
>  
> @@ -835,7 +835,7 @@ static void cnp_disable_backlight(const struct 
> drm_connector_state *old_conn_sta
>  tmp & ~BXT_BLC_PWM_ENABLE);
>  }
>  
> -static void pwm_disable_backlight(const struct drm_connector_state 
> *old_conn_state)
> +static void ext_pwm_disable_backlight(const struct drm_connector_state 
> *old_conn_state)
>  {
>   struct intel_connector *connector = 
> to_intel_connector(old_conn_state->connector);
>   struct intel_panel *panel = >panel;
> @@ -1168,8 +1168,8 @@ static void cnp_enable_backlight(const struct 
> intel_crtc_state *crtc_state,
>  pwm_ctl | BXT_BLC_PWM_ENABLE);
>  }
>  
> -static void pwm_enable_backlight(const struct intel_crtc_state *crtc_state,
> -  const struct drm_connector_state *conn_state)
> +static void ext_pwm_enable_backlight(const struct intel_crtc_state 
> *crtc_state,
> +  const struct drm_connector_state 
> *conn_state)
>  {
>   struct intel_connector *connector = 
> to_intel_connector(conn_state->connector);
>   struct intel_panel *panel = >panel;
> @@ -1890,8 +1890,8 @@ cnp_setup_backlight(struct intel_connector *connector, 
> enum pipe unused)
>   return 0;
>  }
>  
> -static int pwm_setup_backlight(struct intel_connector *connector,
> -enum pipe pipe)
> +static int ext_pwm_setup_backlight(struct intel_connector *connector,
> +enum pipe pipe)
>  {
>   struct drm_device *dev = connector->base.dev;
>   struct drm_i915_private *dev_priv = to_i915(dev);
> @@ -2065,11 +2065,11 @@ intel_panel_init_backlight_funcs(struct intel_panel 
> *panel)
>   panel->backlight.hz_to_pwm = pch_hz_to_pwm;
>   } else if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
>   if (connector->base.connector_type == DRM_MODE_CONNECTOR_DSI) {
> - panel->backlight.setup = pwm_setup_backlight;
> - panel->backlight.enable = pwm_enable_backlight;
> - panel->backlight.disable = pwm_disable_backlight;
> - panel->backlight.set = pwm_set_backlight;
> - panel->backlight.get = pwm_get_backlight;
> + panel->backlight.setup = ext_pwm_setup_backlight;
> + panel->backlight.enable = ext_pwm_enable_backlight;
> + panel->backlight.disable = ext_pwm_disable_backlight;
> + panel->backlight.set = ext_pwm_set_backlight;
> + panel->backlight.get = ext_pwm_get_backlight;
>   } else {
>   panel->backlight.setup = vlv_setup_backlight;
>   panel->backlight.enable = vlv_enable_backlight;
> -- 
> 2.26.2
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v2 1/1] drm/radeon: Add sclk frequency as hwmon sensor

2020-09-15 Thread Alex Deucher
Applied.  Thanks!

Alex

On Wed, Sep 9, 2020 at 7:04 AM Sandeep Raghuraman  wrote:
>
> This patch adds support for reporting sclk values for Radeon GPUs, where 
> supported.
>
> Signed-off-by: Sandeep Raghuraman 
> ---
>  drivers/gpu/drm/radeon/radeon_pm.c | 29 -
>  1 file changed, 28 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_pm.c 
> b/drivers/gpu/drm/radeon/radeon_pm.c
> index 8c5d6fda0d75..05c4196a8212 100644
> --- a/drivers/gpu/drm/radeon/radeon_pm.c
> +++ b/drivers/gpu/drm/radeon/radeon_pm.c
> @@ -712,6 +712,31 @@ static SENSOR_DEVICE_ATTR(pwm1_enable, S_IRUGO | 
> S_IWUSR, radeon_hwmon_get_pwm1_
>  static SENSOR_DEVICE_ATTR(pwm1_min, S_IRUGO, radeon_hwmon_get_pwm1_min, 
> NULL, 0);
>  static SENSOR_DEVICE_ATTR(pwm1_max, S_IRUGO, radeon_hwmon_get_pwm1_max, 
> NULL, 0);
>
> +static ssize_t radeon_hwmon_show_sclk(struct device *dev,
> + struct device_attribute *attr, char 
> *buf)
> +{
> +   struct radeon_device *rdev = dev_get_drvdata(dev);
> +   struct drm_device *ddev = rdev->ddev;
> +   u32 sclk = 0;
> +
> +   /* Can't get clock frequency when the card is off */
> +   if ((rdev->flags & RADEON_IS_PX) &&
> +   (ddev->switch_power_state != DRM_SWITCH_POWER_ON))
> +   return -EINVAL;
> +
> +   if (rdev->asic->dpm.get_current_sclk)
> +   sclk = radeon_dpm_get_current_sclk(rdev);
> +
> +   /* Value returned by dpm is in 10 KHz units, need to convert it into 
> Hz
> +  for hwmon */
> +   sclk *= 1;
> +
> +   return snprintf(buf, PAGE_SIZE, "%u\n", sclk);
> +}
> +
> +static SENSOR_DEVICE_ATTR(freq1_input, S_IRUGO, radeon_hwmon_show_sclk, NULL,
> + 0);
> +
>
>  static struct attribute *hwmon_attributes[] = {
> _dev_attr_temp1_input.dev_attr.attr,
> @@ -721,6 +746,7 @@ static struct attribute *hwmon_attributes[] = {
> _dev_attr_pwm1_enable.dev_attr.attr,
> _dev_attr_pwm1_min.dev_attr.attr,
> _dev_attr_pwm1_max.dev_attr.attr,
> +   _dev_attr_freq1_input.dev_attr.attr,
> NULL
>  };
>
> @@ -738,7 +764,8 @@ static umode_t hwmon_attributes_visible(struct kobject 
> *kobj,
>  attr == _dev_attr_pwm1.dev_attr.attr ||
>  attr == _dev_attr_pwm1_enable.dev_attr.attr ||
>  attr == _dev_attr_pwm1_max.dev_attr.attr ||
> -attr == _dev_attr_pwm1_min.dev_attr.attr))
> +attr == _dev_attr_pwm1_min.dev_attr.attr ||
> +attr == _dev_attr_freq1_input.dev_attr.attr))
> return 0;
>
> /* Skip fan attributes if fan is not present */
> --
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [RFC 1/5] drm/i915/dp: Program source OUI on eDP panels

2020-09-15 Thread Rodrigo Vivi
On Tue, Sep 15, 2020 at 01:29:35PM -0400, Lyude Paul wrote:
> Since we're about to start adding support for Intel's magic HDR
> backlight interface over DPCD, we need to ensure we're properly
> programming this field so that Intel specific sink services are exposed.
> Otherwise, 0x300-0x3ff will just read zeroes.
> 
> We also take care not to reprogram the source OUI if it already matches
> what we expect. This is just to be careful so that we don't accidentally
> take the panel out of any backlight control modes we found it in.
> 
> Signed-off-by: Lyude Paul 
> Cc: thay...@noraisin.net
> Cc: Vasily Khoruzhick 
> ---
>  drivers/gpu/drm/i915/display/intel_dp.c | 32 +
>  1 file changed, 32 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 4bd10456ad188..b591672ec4eab 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -3428,6 +3428,7 @@ void intel_dp_sink_set_decompression_state(struct 
> intel_dp *intel_dp,
>  void intel_dp_sink_dpms(struct intel_dp *intel_dp, int mode)
>  {
>   struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> + u8 edp_oui[] = { 0x00, 0xaa, 0x01 };

what are these values?

>   int ret, i;
>  
>   /* Should have a valid DPCD by this point */
> @@ -3443,6 +3444,14 @@ void intel_dp_sink_dpms(struct intel_dp *intel_dp, int 
> mode)
>   } else {
>   struct intel_lspcon *lspcon = dp_to_lspcon(intel_dp);
>  
> + /* Write the source OUI as early as possible */
> + if (intel_dp_is_edp(intel_dp)) {
> + ret = drm_dp_dpcd_write(_dp->aux, DP_SOURCE_OUI, 
> edp_oui,
> + sizeof(edp_oui));
> + if (ret < 0)
> + drm_err(>drm, "Failed to write eDP source 
> OUI\n");
> + }
> +
>   /*
>* When turning on, we need to retry for 1ms to give the sink
>* time to wake up.
> @@ -4530,6 +4539,23 @@ static void intel_dp_get_dsc_sink_cap(struct intel_dp 
> *intel_dp)
>   }
>  }
>  
> +static void
> +intel_edp_init_source_oui(struct intel_dp *intel_dp)
> +{
> + struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> + u8 oui[] = { 0x00, 0xaa, 0x01 };
> + u8 buf[3] = { 0 };
> +
> + if (drm_dp_dpcd_read(_dp->aux, DP_SOURCE_OUI, buf, sizeof(buf)) < 
> 0)
> + drm_err(>drm, "Failed to read source OUI\n");
> +
> + if (memcmp(oui, buf, sizeof(oui)) == 0)
> + return;
> +
> + if (drm_dp_dpcd_write(_dp->aux, DP_SOURCE_OUI, oui, sizeof(oui)) 
> < 0)
> + drm_err(>drm, "Failed to write source OUI\n");
> +}
> +
>  static bool
>  intel_edp_init_dpcd(struct intel_dp *intel_dp)
>  {
> @@ -4607,6 +4633,12 @@ intel_edp_init_dpcd(struct intel_dp *intel_dp)
>   if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
>   intel_dp_get_dsc_sink_cap(intel_dp);
>  
> + /*
> +  * Program our source OUI so we can make various Intel-specific AUX
> +  * services available (such as HDR backlight controls)
> +  */
> + intel_edp_init_source_oui(intel_dp);

I believe we should restrict this to the supported platforms: cfl, whl, cml, 
icl, tgl
no?

> +
>   return true;
>  }
>  
> -- 
> 2.26.2
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH] drm/scheduler: fix sched_fence.c kernel-doc warnings

2020-09-15 Thread Alex Deucher
Applied.  Thanks!

Alex

On Wed, Sep 9, 2020 at 5:11 AM Christian König  wrote:
>
> Am 09.09.20 um 09:57 schrieb Tian Tao:
> > Fix kernel-doc warnings.
> > drivers/gpu/drm/scheduler/sched_fence.c:110: warning: Function parameter or
> > member 'f' not described in 'drm_sched_fence_release_scheduled'
> > drivers/gpu/drm/scheduler/sched_fence.c:110: warning: Excess function
> > parameter 'fence' description in 'drm_sched_fence_release_scheduled'
> >
> > Signed-off-by: Tian Tao 
>
> Reviewed-by: Christian König 
>
> > ---
> >   drivers/gpu/drm/scheduler/sched_fence.c | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/scheduler/sched_fence.c 
> > b/drivers/gpu/drm/scheduler/sched_fence.c
> > index 8b45c3a1b84..69de2c7 100644
> > --- a/drivers/gpu/drm/scheduler/sched_fence.c
> > +++ b/drivers/gpu/drm/scheduler/sched_fence.c
> > @@ -101,7 +101,7 @@ static void drm_sched_fence_free(struct rcu_head *rcu)
> >   /**
> >* drm_sched_fence_release_scheduled - callback that fence can be freed
> >*
> > - * @fence: fence
> > + * @f: fence
> >*
> >* This function is called when the reference count becomes zero.
> >* It just RCU schedules freeing up the fence.
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH] drm: amd/display: fix spelling of "function"

2020-09-15 Thread Alex Deucher
Applied.  Thanks!

Alex

On Wed, Sep 9, 2020 at 3:05 AM Randy Dunlap  wrote:
>
> From: Randy Dunlap 
>
> Fix spellos of "function" in drivers/gpu/drm/amd/display/.
>
> Signed-off-by: Randy Dunlap 
> Cc: Harry Wentland 
> Cc: Leo Li 
> Cc: amd-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org
> ---
>  drivers/gpu/drm/amd/display/dc/dml/dcn20/display_rq_dlg_calc_20.h   |2 +-
>  drivers/gpu/drm/amd/display/dc/dml/dcn20/display_rq_dlg_calc_20v2.h |2 +-
>  drivers/gpu/drm/amd/display/dc/dml/dcn30/display_rq_dlg_calc_30.h   |2 +-
>  drivers/gpu/drm/amd/display/dc/gpio/dce120/hw_factory_dce120.c  |2 +-
>  drivers/gpu/drm/amd/display/dc/gpio/dcn10/hw_factory_dcn10.c|2 +-
>  drivers/gpu/drm/amd/display/dc/gpio/dcn20/hw_factory_dcn20.c|2 +-
>  drivers/gpu/drm/amd/display/dc/gpio/dcn21/hw_factory_dcn21.c|2 +-
>  drivers/gpu/drm/amd/display/dc/gpio/dcn30/hw_factory_dcn30.c|2 +-
>  8 files changed, 8 insertions(+), 8 deletions(-)
>
> --- 
> linux-next-20200908.orig/drivers/gpu/drm/amd/display/dc/dml/dcn20/display_rq_dlg_calc_20.h
> +++ 
> linux-next-20200908/drivers/gpu/drm/amd/display/dc/dml/dcn20/display_rq_dlg_calc_20.h
> @@ -33,7 +33,7 @@ struct display_mode_lib;
>
>  // Function: dml_rq_dlg_get_rq_reg
>  //  Main entry point for test to get the register values out of this DML 
> class.
> -//  This function calls  and  fucntions to 
> calculate
> +//  This function calls  and  functions to 
> calculate
>  //  and then populate the rq_regs struct
>  // Input:
>  //  pipe_src_param - pipe source configuration (e.g. vp, pitch, etc.)
> --- 
> linux-next-20200908.orig/drivers/gpu/drm/amd/display/dc/dml/dcn20/display_rq_dlg_calc_20v2.h
> +++ 
> linux-next-20200908/drivers/gpu/drm/amd/display/dc/dml/dcn20/display_rq_dlg_calc_20v2.h
> @@ -33,7 +33,7 @@ struct display_mode_lib;
>
>  // Function: dml_rq_dlg_get_rq_reg
>  //  Main entry point for test to get the register values out of this DML 
> class.
> -//  This function calls  and  fucntions to 
> calculate
> +//  This function calls  and  functions to 
> calculate
>  //  and then populate the rq_regs struct
>  // Input:
>  //  pipe_src_param - pipe source configuration (e.g. vp, pitch, etc.)
> --- 
> linux-next-20200908.orig/drivers/gpu/drm/amd/display/dc/dml/dcn30/display_rq_dlg_calc_30.h
> +++ 
> linux-next-20200908/drivers/gpu/drm/amd/display/dc/dml/dcn30/display_rq_dlg_calc_30.h
> @@ -32,7 +32,7 @@ struct display_mode_lib;
>
>  // Function: dml_rq_dlg_get_rq_reg
>  //  Main entry point for test to get the register values out of this DML 
> class.
> -//  This function calls  and  fucntions to 
> calculate
> +//  This function calls  and  functions to 
> calculate
>  //  and then populate the rq_regs struct
>  // Input:
>  //  pipe_param - pipe source configuration (e.g. vp, pitch, scaling, dest, 
> etc.)
> --- 
> linux-next-20200908.orig/drivers/gpu/drm/amd/display/dc/gpio/dce120/hw_factory_dce120.c
> +++ 
> linux-next-20200908/drivers/gpu/drm/amd/display/dc/gpio/dce120/hw_factory_dce120.c
> @@ -162,7 +162,7 @@ static void define_hpd_registers(struct
>  }
>
>
> -/* fucntion table */
> +/* function table */
>  static const struct hw_factory_funcs funcs = {
> .init_ddc_data = dal_hw_ddc_init,
> .init_generic = NULL,
> --- 
> linux-next-20200908.orig/drivers/gpu/drm/amd/display/dc/gpio/dcn10/hw_factory_dcn10.c
> +++ 
> linux-next-20200908/drivers/gpu/drm/amd/display/dc/gpio/dcn10/hw_factory_dcn10.c
> @@ -194,7 +194,7 @@ static void define_hpd_registers(struct
>  }
>
>
> -/* fucntion table */
> +/* function table */
>  static const struct hw_factory_funcs funcs = {
> .init_ddc_data = dal_hw_ddc_init,
> .init_generic = dal_hw_generic_init,
> --- 
> linux-next-20200908.orig/drivers/gpu/drm/amd/display/dc/gpio/dcn20/hw_factory_dcn20.c
> +++ 
> linux-next-20200908/drivers/gpu/drm/amd/display/dc/gpio/dcn20/hw_factory_dcn20.c
> @@ -221,7 +221,7 @@ static void define_generic_registers(str
> generic->base.regs = _regs[en].gpio;
>  }
>
> -/* fucntion table */
> +/* function table */
>  static const struct hw_factory_funcs funcs = {
> .init_ddc_data = dal_hw_ddc_init,
> .init_generic = dal_hw_generic_init,
> --- 
> linux-next-20200908.orig/drivers/gpu/drm/amd/display/dc/gpio/dcn21/hw_factory_dcn21.c
> +++ 
> linux-next-20200908/drivers/gpu/drm/amd/display/dc/gpio/dcn21/hw_factory_dcn21.c
> @@ -202,7 +202,7 @@ static void define_hpd_registers(struct
>  }
>
>
> -/* fucntion table */
> +/* function table */
>  static const struct hw_factory_funcs funcs = {
> .init_ddc_data = dal_hw_ddc_init,
> .init_generic = dal_hw_generic_init,
> --- 
> linux-next-20200908.orig/drivers/gpu/drm/amd/display/dc/gpio/dcn30/hw_factory_dcn30.c
> +++ 
> linux-next-20200908/drivers/gpu/drm/amd/display/dc/gpio/dcn30/hw_factory_dcn30.c
> @@ -218,7 +218,7 @@ static void define_hpd_registers(struct
>  }
>
>
> -/* fucntion table */
> +/* function table */
>  

Re: [PATCH -next] drm/amd/display: Remove duplicate include

2020-09-15 Thread Alex Deucher
Applied.  Thanks!

Alex

On Wed, Sep 9, 2020 at 3:05 AM Chen Zhou  wrote:
>
> Remove duplicate header which is included twice.
>
> Signed-off-by: Chen Zhou 
> ---
>  drivers/gpu/drm/amd/display/dc/dcn30/dcn30_hwseq.c | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_hwseq.c 
> b/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_hwseq.c
> index a5d750ed569e..65dc5dcd4eb8 100644
> --- a/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_hwseq.c
> +++ b/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_hwseq.c
> @@ -35,7 +35,6 @@
>  #include "dcn30_dpp.h"
>  #include "dcn10/dcn10_cm_common.h"
>  #include "dcn30_cm_common.h"
> -#include "clk_mgr.h"
>  #include "reg_helper.h"
>  #include "abm.h"
>  #include "clk_mgr.h"
> --
> 2.17.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH] Revert "drm/radeon: handle PCIe root ports with addressing limitations"

2020-09-15 Thread Alex Deucher
This change breaks tons of systems.

This reverts commit 33b3ad3788aba846fc8b9a065fe2685a0b64f713.

Bug: https://bugzilla.kernel.org/show_bug.cgi?id=206973
Bug: https://bugzilla.kernel.org/show_bug.cgi?id=206697
Bug: https://bugzilla.kernel.org/show_bug.cgi?id=207763
Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1140
Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1287
Signed-off-by: Alex Deucher 
Cc: sta...@vger.kernel.org
Cc: Christoph Hellwig 
Cc: christian.koe...@amd.com
---
 drivers/gpu/drm/radeon/radeon.h|  1 +
 drivers/gpu/drm/radeon/radeon_device.c | 13 -
 drivers/gpu/drm/radeon/radeon_ttm.c|  2 +-
 3 files changed, 10 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index b7c3fb2bfb54..eed23dffccf4 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -2391,6 +2391,7 @@ struct radeon_device {
struct radeon_wbwb;
struct radeon_dummy_pagedummy_page;
boolshutdown;
+   boolneed_dma32;
boolneed_swiotlb;
boolaccel_working;
boolfastfb_working; /* IGP feature*/
diff --git a/drivers/gpu/drm/radeon/radeon_device.c 
b/drivers/gpu/drm/radeon/radeon_device.c
index 266e3cbbd09b..f74c74ad8b5d 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -1363,25 +1363,28 @@ int radeon_device_init(struct radeon_device *rdev,
else
rdev->mc.mc_mask = 0xULL; /* 32 bit MC */
 
-   /* set DMA mask.
+   /* set DMA mask + need_dma32 flags.
 * PCIE - can handle 40-bits.
 * IGP - can handle 40-bits
 * AGP - generally dma32 is safest
 * PCI - dma32 for legacy pci gart, 40 bits on newer asics
 */
-   dma_bits = 40;
+   rdev->need_dma32 = false;
if (rdev->flags & RADEON_IS_AGP)
-   dma_bits = 32;
+   rdev->need_dma32 = true;
if ((rdev->flags & RADEON_IS_PCI) &&
(rdev->family <= CHIP_RS740))
-   dma_bits = 32;
+   rdev->need_dma32 = true;
 #ifdef CONFIG_PPC64
if (rdev->family == CHIP_CEDAR)
-   dma_bits = 32;
+   rdev->need_dma32 = true;
 #endif
 
+   dma_bits = rdev->need_dma32 ? 32 : 40;
r = dma_set_mask_and_coherent(>pdev->dev, DMA_BIT_MASK(dma_bits));
if (r) {
+   rdev->need_dma32 = true;
+   dma_bits = 32;
pr_warn("radeon: No suitable DMA available\n");
return r;
}
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c 
b/drivers/gpu/drm/radeon/radeon_ttm.c
index 357e8e98cca9..d2550862313e 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -787,7 +787,7 @@ int radeon_ttm_init(struct radeon_device *rdev)
   _bo_driver,
   rdev->ddev->anon_inode->i_mapping,
   rdev->ddev->vma_offset_manager,
-  dma_addressing_limited(>pdev->dev));
+  rdev->need_dma32);
if (r) {
DRM_ERROR("failed initializing buffer object driver(%d).\n", r);
return r;
-- 
2.25.4

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


Re: [PATCH 1/2] drm/radeon: Add sclk frequency as hwmon sensor

2020-09-15 Thread Alex Deucher
On Tue, Sep 8, 2020 at 1:27 AM Sandeep Raghuraman  wrote:
>
>
>
> On 9/1/20 2:03 AM, Alex Deucher wrote:
> > On Sun, Aug 30, 2020 at 3:25 AM Sandeep Raghuraman  
> > wrote:
> >>
> >> This patch series adds support for reporting sclk and vddc values for 
> >> Radeon GPUs, where supported.
> >
> > This commit message should be specific to this particular patch rather
> > than the series.  You could probably expose mclk as well.
> >
> > Alex
> >
> >
>
> I only have a Radeon iGPU, and don't have a Radeon dGPU to test with, so 
> that's why I didn't wire up mclk.

Well, there is still an mclk, it's just the speed of your memory.

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


Re: [PATCH v2 20/21] drm/xlnx: Initialize DRM driver instance with CMA helper macro

2020-09-15 Thread Hyun Kwon
Hi Tomas,

Thanks for the patch.

On Tue, Sep 15, 2020 at 08:53:46AM -0700, Laurent Pinchart wrote:
> Hi Thomas,
> 
> Thank you for the patch.
> 
> On Tue, Sep 15, 2020 at 04:59:57PM +0200, Thomas Zimmermann wrote:
> > The xlnx driver uses CMA helpers with default callback functions.
> > Initialize the driver structure with the rsp CMA helper macro. The
> > driver is being converted to use GEM object functions as part of
> > this change.
> > 
> > Two callbacks, .dumb_destroy and .gem_prime_import, were initialized
> > to their default implementations, so they are just kept empty now.
> > 
> > v2:
> > * initialize with DRM_GEM_CMA_DRIVER_OPS_WITH_DUMB_CREATE (Laurent)
> > 
> > Signed-off-by: Thomas Zimmermann 
> 
> Reviewed-by: Laurent Pinchart 
> 

Reviewed-by: Hyun Kwon 

Thanks,
-hyun

> > ---
> >  drivers/gpu/drm/xlnx/zynqmp_dpsub.c | 14 +-
> >  1 file changed, 1 insertion(+), 13 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/xlnx/zynqmp_dpsub.c 
> > b/drivers/gpu/drm/xlnx/zynqmp_dpsub.c
> > index 8e69303aad3f..f3ffc3703a0e 100644
> > --- a/drivers/gpu/drm/xlnx/zynqmp_dpsub.c
> > +++ b/drivers/gpu/drm/xlnx/zynqmp_dpsub.c
> > @@ -80,19 +80,7 @@ static struct drm_driver zynqmp_dpsub_drm_driver = {
> > .driver_features= DRIVER_MODESET | DRIVER_GEM |
> >   DRIVER_ATOMIC,
> >  
> > -   .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,
> > -   .gem_prime_vunmap   = drm_gem_cma_prime_vunmap,
> > -   .gem_prime_mmap = drm_gem_cma_prime_mmap,
> > -   .gem_free_object_unlocked   = drm_gem_cma_free_object,
> > -   .gem_vm_ops = _gem_cma_vm_ops,
> > -   .dumb_create= zynqmp_dpsub_dumb_create,
> > -   .dumb_destroy   = drm_gem_dumb_destroy,
> > +   DRM_GEM_CMA_DRIVER_OPS_WITH_DUMB_CREATE(zynqmp_dpsub_dumb_create),
> >  
> > .fops   = _dpsub_drm_fops,
> >  
> 
> -- 
> Regards,
> 
> Laurent Pinchart
> ___
> 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 206475] amdgpu under load drop signal to monitor until hard reset

2020-09-15 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=206475

--- Comment #18 from Marco (rodomar...@protonmail.com) ---
As of 5.8.7 I've tried to revert to stock clocks, and I had no black screen
issue under load even after long game sessions.

It does *seems* to be fixed, at least for me.

I don't know how much code is shared between the Linux open source driver and
the Windows closed source driver, but I wonder if it was some bug that jumped
over the Windows driver too (or even if it was firmware related).

I'll keep testing to see if it happens again, but I haven't seen any error logs
mentioning amdgpu in the dmesg kernel.

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


Re: [PATCH] drm/ttm: some cleanups

2020-09-15 Thread Christian König

Am 15.09.20 um 17:44 schrieb Ruhl, Michael J:

-Original Message-
From: dri-devel  On Behalf Of
Christian König
Sent: Tuesday, September 15, 2020 10:31 AM
To: dri-devel@lists.freedesktop.org
Subject: [PATCH] drm/ttm: some cleanups

Unexport ttm_check_under_lowerlimit.
Make ttm_bo_acc_size static and unexport it.
Remove ttm_get_kernel_zone_memory_size.

Signed-off-by: Christian König 
---
drivers/gpu/drm/ttm/ttm_bo.c |  7 +++
drivers/gpu/drm/ttm/ttm_memory.c |  7 ---
include/drm/ttm/ttm_bo_api.h | 12 
include/drm/ttm/ttm_memory.h |  1 -
4 files changed, 3 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index ee2632128d3c..ffbdc20d8e8d 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -1254,9 +1254,9 @@ int ttm_bo_init(struct ttm_bo_device *bdev,
}
EXPORT_SYMBOL(ttm_bo_init);

-size_t ttm_bo_acc_size(struct ttm_bo_device *bdev,
-  unsigned long bo_size,
-  unsigned struct_size)
+static size_t ttm_bo_acc_size(struct ttm_bo_device *bdev,
+ unsigned long bo_size,
+ unsigned struct_size)
{
unsigned npages = (PAGE_ALIGN(bo_size)) >> PAGE_SHIFT;
size_t size = 0;
@@ -1266,7 +1266,6 @@ size_t ttm_bo_acc_size(struct ttm_bo_device
*bdev,
size += ttm_round_pot(sizeof(struct ttm_tt));
return size;
}
-EXPORT_SYMBOL(ttm_bo_acc_size);

size_t ttm_bo_dma_acc_size(struct ttm_bo_device *bdev,
   unsigned long bo_size,
diff --git a/drivers/gpu/drm/ttm/ttm_memory.c
b/drivers/gpu/drm/ttm/ttm_memory.c
index acd63b70d814..987aa32c4808 100644
--- a/drivers/gpu/drm/ttm/ttm_memory.c
+++ b/drivers/gpu/drm/ttm/ttm_memory.c
@@ -554,7 +554,6 @@ ttm_check_under_lowerlimit(struct ttm_mem_global
*glob,

return false;
}
-EXPORT_SYMBOL(ttm_check_under_lowerlimit);

static int ttm_mem_global_reserve(struct ttm_mem_global *glob,
  struct ttm_mem_zone *single_zone,
@@ -682,9 +681,3 @@ size_t ttm_round_pot(size_t size)
return 0;
}
EXPORT_SYMBOL(ttm_round_pot);
-
-uint64_t ttm_get_kernel_zone_memory_size(struct ttm_mem_global *glob)
-{
-   return glob->zone_kernel->max_mem;
-}
-EXPORT_SYMBOL(ttm_get_kernel_zone_memory_size);
diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h
index 36ff64e2736c..fd8d29f5f370 100644
--- a/include/drm/ttm/ttm_bo_api.h
+++ b/include/drm/ttm/ttm_bo_api.h
@@ -352,18 +352,6 @@ void ttm_bo_unlock_delayed_workqueue(struct
ttm_bo_device *bdev, int resched);
bool ttm_bo_eviction_valuable(struct ttm_buffer_object *bo,
  const struct ttm_place *place);

-/**
- * ttm_bo_acc_size
- *
- * @bdev: Pointer to a ttm_bo_device struct.
- * @bo_size: size of the buffer object in byte.
- * @struct_size: size of the structure holding buffer object datas
- *
- * Returns size to account for a buffer object
- */
-size_t ttm_bo_acc_size(struct ttm_bo_device *bdev,
-  unsigned long bo_size,
-  unsigned struct_size);
size_t ttm_bo_dma_acc_size(struct ttm_bo_device *bdev,
   unsigned long bo_size,
   unsigned struct_size);
diff --git a/include/drm/ttm/ttm_memory.h
b/include/drm/ttm/ttm_memory.h
index c78ea99c42cf..2d468d7c94e6 100644
--- a/include/drm/ttm/ttm_memory.h
+++ b/include/drm/ttm/ttm_memory.h
@@ -91,7 +91,6 @@ extern int ttm_mem_global_alloc_page(struct
ttm_mem_global *glob,
extern void ttm_mem_global_free_page(struct ttm_mem_global *glob,
 struct page *page, uint64_t size);
extern size_t ttm_round_pot(size_t size);
-extern uint64_t ttm_get_kernel_zone_memory_size(struct
ttm_mem_global *glob);
extern bool ttm_check_under_lowerlimit(struct ttm_mem_global *glob,
uint64_t num_pages, struct ttm_operation_ctx *ctx);

^

Externs for function prototypes have always been a slight mystery to me.
Was this necessary for the EXPORT_SYMBOL?

Since this is now "local" is the extern still needed?


It was never needed in the first place, and yes I'm trying to get rid of 
those for quite some time as well.


Going to remove those in a separate patch.

Thanks,
Christian.



Regardless, I can't resist the low lying fruit...

Reviewed-by: Michael J. Ruhl 

M



#endif
--
2.17.1

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


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


Re: [PATCH v2 08/16] drm/exynos: add host_ops callback for platform drivers

2020-09-15 Thread Michael Tretter
On Tue, 15 Sep 2020 19:07:59 +0200, Andrzej Hajda wrote:
> 
> W dniu 11.09.2020 o 15:54, Michael Tretter pisze:
> > Platform drivers need to be aware if a mipi dsi device attaches or
> > detaches. Add host_ops to the driver_data for attach and detach
> > callbacks and move the i80 mode selection and the hotplug handling into
> > the callback, because these depend on the drm driver.
> >
> > Signed-off-by: Michael Tretter 
> > ---
> > v2:
> > - new patch
> > ---
> >   drivers/gpu/drm/exynos/exynos_drm_dsi.c | 64 -
> >   1 file changed, 53 insertions(+), 11 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
> > b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> > index 1a15ae71205d..684a2fbef08a 100644
> > --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> > +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> > @@ -239,6 +239,12 @@ struct exynos_dsi_transfer {
> >   #define DSIM_STATE_CMD_LPMBIT(2)
> >   #define DSIM_STATE_VIDOUT_AVAILABLE   BIT(3)
> >   
> > +struct exynos_dsi;
> > +struct exynos_dsi_host_ops {
> > +   int (*attach)(struct device *dev, struct mipi_dsi_device *device);
> > +   int (*detach)(struct device *dev, struct mipi_dsi_device *device);
> > +};
> > +
> >   enum exynos_reg_offset {
> > EXYNOS_REG_OFS,
> > EXYNOS5433_REG_OFS
> > @@ -254,6 +260,7 @@ struct exynos_dsi_driver_data {
> > unsigned int wait_for_reset;
> > unsigned int num_bits_resol;
> > const unsigned int *reg_values;
> > +   const struct exynos_dsi_host_ops *host_ops;
> >   };
> >   
> >   struct exynos_dsi {
> > @@ -467,6 +474,41 @@ static const unsigned int exynos5433_reg_values[] = {
> > [PHYTIMING_HS_TRAIL] = 0x0c,
> >   };
> >   
> > +static int __exynos_dsi_host_attach(struct device *dev,
> > +   struct mipi_dsi_device *device)
> > +{
> > +   struct exynos_dsi *dsi = dev_get_drvdata(dev);
> > +   struct drm_device *drm = dsi->encoder.dev;
> 
> 
> As I wrote yesterday drm device was guaranteed to be present here only 
> if mipi dsi host registration was performed in component bind. In case 
> it is performed in probe it will be always NULL, and the code does not 
> make sense.

Correct, but if the driver is used as a drm bridge, there won't be an encoder
until bridge_attach. Mipi dsi devices defer their probe until the mipi dsi
host is available. If I move the mipi dsi host registration into
bridge_attach, the driver does not know if the next device is another bridge
or a panel during bridge_attach, but the driver cannot successfully return
from bridge_attach, because then the drm driver expects a connector.

I guess that the encoder should be initialized before registering the mipi dsi
host during probe instead of bind. The probe won't be rolled back on
PROBE_DEFER during bind and the encoder will be available in host_attach.
When splitting the driver into the exynos platform specific code and the more
generic code, there won't be an encoder during host_attach in the generic
code, but the host_ops callback could (and will) use the platform specific
encoder, which is available before bridge_attach.

Does this make sense to you?

Michael

> 
> 
> Regards
> 
> Andrzej
> 
> 
> 
> > +   struct exynos_drm_crtc *crtc;
> > +
> > +   mutex_lock(>mode_config.mutex);
> > +   crtc = exynos_drm_crtc_get_by_type(drm, EXYNOS_DISPLAY_TYPE_LCD);
> > +   crtc->i80_mode = !(device->mode_flags & MIPI_DSI_MODE_VIDEO);
> > +   mutex_unlock(>mode_config.mutex);
> > +
> > +   if (drm->mode_config.poll_enabled)
> > +   drm_kms_helper_hotplug_event(drm);
> > +
> > +   return 0;
> > +}
> > +
> > +static int __exynos_dsi_host_detach(struct device *dev,
> > +struct mipi_dsi_device *device)
> > +{
> > +   struct exynos_dsi *dsi = dev_get_drvdata(dev);
> > +   struct drm_device *drm = dsi->encoder.dev;
> > +
> > +   if (drm->mode_config.poll_enabled)
> > +   drm_kms_helper_hotplug_event(drm);
> > +
> > +   return 0;
> > +}
> > +
> > +static const struct exynos_dsi_host_ops exynos_dsi_host_ops = {
> > +   .attach = __exynos_dsi_host_attach,
> > +   .detach = __exynos_dsi_host_detach,
> > +};
> > +
> >   static const struct exynos_dsi_driver_data exynos3_dsi_driver_data = {
> > .reg_ofs = EXYNOS_REG_OFS,
> > .plltmr_reg = 0x50,
> > @@ -477,6 +519,7 @@ static const struct exynos_dsi_driver_data 
> > exynos3_dsi_driver_data = {
> > .wait_for_reset = 1,
> > .num_bits_resol = 11,
> > .reg_values = reg_values,
> > +   .host_ops = _dsi_host_ops,
> >   };
> >   
> >   static const struct exynos_dsi_driver_data exynos4_dsi_driver_data = {
> > @@ -489,6 +532,7 @@ static const struct exynos_dsi_driver_data 
> > exynos4_dsi_driver_data = {
> > .wait_for_reset = 1,
> > .num_bits_resol = 11,
> > .reg_values = reg_values,
> > +   .host_ops = _dsi_host_ops,
> >   };
> >   
> >   static const struct exynos_dsi_driver_data exynos5_dsi_driver_data = {
> > @@ -499,6 +543,7 @@ static 

Re: [GIT PULL FOR v5.10] R-Car display drivers miscellaneous changes

2020-09-15 Thread Laurent Pinchart
Hello,

Is there anything blocking this ?

On Tue, Sep 08, 2020 at 07:03:36PM +0300, Laurent Pinchart wrote:
> Hi Dave and Daniel,
> 
> The following changes since commit ce5c207c6b8dd9cdeaeeb2345b8a69335c0d98bf:
> 
>   Merge tag 'v5.9-rc4' into drm-next (2020-09-08 14:41:40 +1000)
> 
> are available in the Git repository at:
> 
>   git://linuxtv.org/pinchartl/media.git tags/du-next-20200908
> 
> for you to fetch changes up to 2a7d2463be82554578185dbb61caa01aaf504156:
> 
>   drm: rcar-du: Fix crash when enabling a non-visible plane (2020-09-08 
> 18:55:04 +0300)
> 
> 
> Miscellaneous R-Car display driver changes:
> 
> - R8A7742, R8A774E1 and R8A77961 support
> - Fixes for pitch of YUV planar foamts and non-visible plane handling
> - Kconfig fix to avoid displaying disabled options in .config
> 
> 
> Biju Das (2):
>   dt-bindings: display: bridge: lvds-codec: Document power-supply property
>   drm/bridge: lvds-codec: Add support for regulator
> 
> Kuninori Morimoto (4):
>   dt-bindings: display: renesas: du: Document the r8a77961 bindings
>   dt-bindings: display: renesas: dw-hdmi: Tidyup example compatible
>   dt-bindings: display: renesas: dw-hdmi: Add R8A77961 support
>   drm: rcar-du: Add r8a77961 support
> 
> Lad Prabhakar (4):
>   dt-bindings: display: renesas,du: Document the r8a7742 bindings
>   drm: rcar-du: Add r8a7742 support
>   dt-bindings: display: renesas,lvds: Document r8a7742 bindings
>   drm: rcar-du: lvds: Add r8a7742 support
> 
> Laurent Pinchart (2):
>   drm: rcar-du: Fix pitch handling for fully planar YUV formats
>   drm: rcar-du: Fix crash when enabling a non-visible plane
> 
> Marian-Cristian Rotariu (5):
>   dt-bindings: display: renesas,du: Document r8a774e1 bindings
>   drm: rcar-du: Add support for R8A774E1 SoC
>   dt-bindings: display: renesas,lvds: Document r8a774e1 bindings
>   dt-bindings: display: renesas,dw-hdmi: Add r8a774e1 support
>   drm: rcar-du: lvds: Add support for R8A774E1 SoC
> 
> Qian Cai (1):
>   drm: rcar-du: Make DRM_RCAR_WRITEBACK depends on DRM_RCAR_DU
> 
>  .../bindings/display/bridge/lvds-codec.yaml |  3 ++
>  .../bindings/display/bridge/renesas,dw-hdmi.txt |  4 +-
>  .../bindings/display/bridge/renesas,lvds.yaml   |  2 +
>  .../devicetree/bindings/display/renesas,du.txt  |  6 +++
>  drivers/gpu/drm/bridge/lvds-codec.c | 29 ++
>  drivers/gpu/drm/rcar-du/Kconfig |  1 +
>  drivers/gpu/drm/rcar-du/rcar_du_drv.c   | 37 -
>  drivers/gpu/drm/rcar-du/rcar_du_kms.c   | 54 ++-
>  drivers/gpu/drm/rcar-du/rcar_du_kms.h   |  1 +
>  drivers/gpu/drm/rcar-du/rcar_du_vsp.c   |  2 +-
>  drivers/gpu/drm/rcar-du/rcar_lvds.c |  2 +
>  11 files changed, 135 insertions(+), 6 deletions(-)
> 

-- 
Regards,

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


Re: [Freedreno] [PATCH] drm/msm: Fix the a650 hw_apriv check

2020-09-15 Thread Jonathan Marek

On 9/15/20 11:56 AM, Jordan Crouse wrote:

Commit 604234f33658 ("drm/msm: Enable expanded apriv support for a650")
was checking the result of adreno_is_a650() before the gpu revision
got probed in adreno_gpu_init() so it was always coming across as
false. Snoop into the revision ID ahead of time to correctly set the
hw_apriv flag so that it can be used by msm_gpu to properly setup
global buffers.

Fixes: 604234f33658 ("drm/msm: Enable expanded apriv support for a650")
Signed-off-by: Jordan Crouse 


Tested-by: Jonathan Marek 


---

  drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 11 ++-
  1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index 74bc27eb4203..f3b6d93c207c 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -1048,6 +1048,8 @@ struct msm_gpu *a6xx_gpu_init(struct drm_device *dev)
  {
struct msm_drm_private *priv = dev->dev_private;
struct platform_device *pdev = priv->gpu_pdev;
+   struct adreno_platform_config *config = pdev->dev.platform_data;
+   const struct adreno_info *info;
struct device_node *node;
struct a6xx_gpu *a6xx_gpu;
struct adreno_gpu *adreno_gpu;
@@ -1064,7 +1066,14 @@ struct msm_gpu *a6xx_gpu_init(struct drm_device *dev)
adreno_gpu->registers = NULL;
adreno_gpu->reg_offsets = a6xx_register_offsets;
  
-	if (adreno_is_a650(adreno_gpu))

+   /*
+* We need to know the platform type before calling into adreno_gpu_init
+* so that the hw_apriv flag can be correctly set. Snoop into the info
+* and grab the revision number
+*/
+   info = adreno_info(config->rev);
+
+   if (info && info->revn == 650)
adreno_gpu->base.hw_apriv = true;
  
  	ret = adreno_gpu_init(dev, pdev, adreno_gpu, , 1);



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


Re: [git pull] virtio-shm region

2020-09-15 Thread Maxime Ripard
Hi,

On Mon, Sep 14, 2020 at 04:39:41PM -0700, Gurchetan Singh wrote:
> Hi,
> 
> This set of changes are required for zero-copy virtio-gpu.
> 
> The following changes since commit 9123e3a74ec7b934a4a099e98af6a61c2f80bbf5:
> 
>   Linux 5.9-rc1 (2020-08-16 13:04:57 -0700)
> 
> are available in the Git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse.git virtio-shm
> 
> for you to fetch changes up to 38e895487afc2ed42c11045853cbb3fa20b52b6e:
> 
>   virtio: Implement get_shm_region for MMIO transport (2020-09-10 10:05:58
> +0200)
> 
> 
> Sebastien Boeuf (3):
>   virtio: Add get_shm_region method
>   virtio: Implement get_shm_region for PCI transport
>   virtio: Implement get_shm_region for MMIO transport
> 
>  drivers/virtio/virtio_mmio.c   | 31 +
>  drivers/virtio/virtio_pci_modern.c | 95
> ++
>  include/linux/virtio_config.h  | 17 +++
>  include/uapi/linux/virtio_mmio.h   | 11 +
>  include/uapi/linux/virtio_pci.h| 11 -
>  5 files changed, 164 insertions(+), 1 deletion(-)

It's not really clear who you expect to pull that PR?

Maxime


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


Re: [PATCH v3 1/2] dt-bindings: display: bridge: Add documentation for LT9611UXC

2020-09-15 Thread Bjorn Andersson
On Wed 09 Sep 09:28 UTC 2020, Dmitry Baryshkov wrote:

> Lontium LT9611UXC is a DSI to HDMI bridge which supports 2 DSI ports
> and I2S port as input and one HDMI port as output. The LT9611UXC chip is
> handled by a separate driver, but the bindings used are fully compatible
> with the LT9611 chip, so let's reuse the lt9611.yaml schema.
> 
> Signed-off-by: Dmitry Baryshkov 
> Acked-by: Vinod Koul 
> Acked-by: Sam Ravnborg 

Reviewed-by: Bjorn Andersson 

> ---
>  .../devicetree/bindings/display/bridge/lontium,lt9611.yaml   | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git 
> a/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml 
> b/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml
> index d60208359234..7a1c89b995e2 100644
> --- a/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml
> +++ b/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml
> @@ -4,18 +4,19 @@
>  $id: http://devicetree.org/schemas/display/bridge/lontium,lt9611.yaml#
>  $schema: http://devicetree.org/meta-schemas/core.yaml#
>  
> -title: Lontium LT9611 2 Port MIPI to HDMI Bridge
> +title: Lontium LT9611(UXC) 2 Port MIPI to HDMI Bridge
>  
>  maintainers:
>- Vinod Koul 
>  
>  description: |
> -  The LT9611 is a bridge device which converts DSI to HDMI
> +  The LT9611 and LT9611UXC are bridge devices which convert DSI to HDMI
>  
>  properties:
>compatible:
>  enum:
>- lontium,lt9611
> +  - lontium,lt9611uxc
>  
>reg:
>  maxItems: 1
> -- 
> 2.28.0
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 5.4 000/132] 5.4.66-rc1 review

2020-09-15 Thread Naresh Kamboju
On Tue, 15 Sep 2020 at 19:50, Greg Kroah-Hartman
 wrote:
>
> This is the start of the stable review cycle for the 5.4.66 release.
> There are 132 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Thu, 17 Sep 2020 14:06:12 +.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> 
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.66-rc1.gz
> or in the git tree and branch at:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-5.4.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>

arm and arm64 build breaks on stable rc 5.4.

make -sk KBUILD_BUILD_USER=TuxBuild -C/linux -j16 ARCH=arm
CROSS_COMPILE=arm-linux-gnueabihf- HOSTCC=gcc CC="sccache
arm-linux-gnueabihf-gcc" O=build zImage
#
../kernel/kprobes.c: In function ‘kill_kprobe’:
../kernel/kprobes.c:1081:33: warning: statement with no effect [-Wunused-value]
 1081 | #define disarm_kprobe_ftrace(p) (-ENODEV)
  | ^
../kernel/kprobes.c:2113:3: note: in expansion of macro ‘disarm_kprobe_ftrace’
 2113 |   disarm_kprobe_ftrace(p);
  |   ^~~~
#
# make -sk KBUILD_BUILD_USER=TuxBuild -C/linux -j16 ARCH=arm
CROSS_COMPILE=arm-linux-gnueabihf- HOSTCC=gcc CC="sccache
arm-linux-gnueabihf-gcc" O=build modules
#
../drivers/gpu/drm/msm/adreno/a5xx_preempt.c: In function ‘preempt_init_ring’:
../drivers/gpu/drm/msm/adreno/a5xx_preempt.c:235:21: error:
‘MSM_BO_MAP_PRIV’ undeclared (first use in this function)
  235 |   MSM_BO_UNCACHED | MSM_BO_MAP_PRIV, gpu->aspace, , );
  | ^~~
../drivers/gpu/drm/msm/adreno/a5xx_preempt.c:235:21: note: each
undeclared identifier is reported only once for each function it
appears in
make[5]: *** [../scripts/Makefile.build:266:
drivers/gpu/drm/msm/adreno/a5xx_preempt.o] Error 1
../drivers/gpu/drm/msm/adreno/a6xx_gpu.c: In function ‘a6xx_hw_init’:
../drivers/gpu/drm/msm/adreno/a6xx_gpu.c:414:6: error: implicit
declaration of function ‘adreno_is_a640’; did you mean
‘adreno_is_a540’? [-Werror=implicit-function-declaration]
  414 |  if (adreno_is_a640(adreno_gpu) || adreno_is_a650(adreno_gpu)) {
  |  ^~
  |  adreno_is_a540
../drivers/gpu/drm/msm/adreno/a6xx_gpu.c:414:36: error: implicit
declaration of function ‘adreno_is_a650’; did you mean
‘adreno_is_a540’? [-Werror=implicit-function-declaration]
  414 |  if (adreno_is_a640(adreno_gpu) || adreno_is_a650(adreno_gpu)) {
  |^~
  |adreno_is_a540
../drivers/gpu/drm/msm/adreno/a6xx_gpu.c:415:18: error:
‘REG_A6XX_GBIF_QSB_SIDE0’ undeclared (first use in this function)
  415 |   gpu_write(gpu, REG_A6XX_GBIF_QSB_SIDE0, 0x00071620);
  |  ^~~
../drivers/gpu/drm/msm/adreno/a6xx_gpu.c:415:18: note: each undeclared
identifier is reported only once for each function it appears in
../drivers/gpu/drm/msm/adreno/a6xx_gpu.c:416:18: error:
‘REG_A6XX_GBIF_QSB_SIDE1’ undeclared (first use in this function)
  416 |   gpu_write(gpu, REG_A6XX_GBIF_QSB_SIDE1, 0x00071620);
  |  ^~~
../drivers/gpu/drm/msm/adreno/a6xx_gpu.c:417:18: error:
‘REG_A6XX_GBIF_QSB_SIDE2’ undeclared (first use in this function)
  417 |   gpu_write(gpu, REG_A6XX_GBIF_QSB_SIDE2, 0x00071620);
  |  ^~~
../drivers/gpu/drm/msm/adreno/a6xx_gpu.c:418:18: error:
‘REG_A6XX_GBIF_QSB_SIDE3’ undeclared (first use in this function)
  418 |   gpu_write(gpu, REG_A6XX_GBIF_QSB_SIDE3, 0x00071620);
  |  ^~~
cc1: some warnings being treated as errors
make[5]: *** [../scripts/Makefile.build:265:
drivers/gpu/drm/msm/adreno/a6xx_gpu.o] Error 1
In file included from ../drivers/gpu/drm/msm/msm_gpu.c:7:
../drivers/gpu/drm/msm/msm_gpu.c: In function ‘msm_gpu_init’:
../drivers/gpu/drm/msm/msm_gpu.h:330:22: error: ‘MSM_BO_MAP_PRIV’
undeclared (first use in this function)
  330 |  (((gpu)->hw_apriv ? MSM_BO_MAP_PRIV : 0) | (flags))
  |  ^~~
../drivers/gpu/drm/msm/msm_gpu.c:935:3: note: in expansion of macro
‘check_apriv’
  935 |   check_apriv(gpu, MSM_BO_UNCACHED), gpu->aspace, >memptrs_bo,
  |   ^~~
../drivers/gpu/drm/msm/msm_gpu.h:330:22: note: each undeclared
identifier is reported only once for each function it appears in
  330 |  (((gpu)->hw_apriv ? MSM_BO_MAP_PRIV : 0) | (flags))
  |  ^~~
../drivers/gpu/drm/msm/msm_gpu.c:935:3: note: in expansion of macro
‘check_apriv’
  935 |   check_apriv(gpu, MSM_BO_UNCACHED), gpu->aspace, >memptrs_bo,
  |   ^~~
make[5]: *** [../scripts/Makefile.build:266:
drivers/gpu/drm/msm/msm_gpu.o] Error 1
In file 

Re: [patch 00/13] preempt: Make preempt count unconditional

2020-09-15 Thread Linus Torvalds
On Tue, Sep 15, 2020 at 12:24 AM Thomas Gleixner  wrote:
>
> Alternatively we just make highmem a bit more expensive by making these
> maps preemptible. RT is doing this for a long time and it's not that
> horrible.

Ack.

In fact, I've wanted to start just removing kmap support entirely. At
some point it's not so much about "I have an old machine that wants
HIGHMEM" but about "I have an old CPU, and I'll just run an old
kernel".

It's not that 32-bit is irrelevant, it's that 32-bit with large
amounts of memory is irrelevant.

Last time this was discussed, iirc the main issue was some
questionable old ARM chips that were still very common in embedded
environments, even with large memory.

But we could definitely start de-emphasizing HIGHMEM.

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


Re: [patch 00/13] preempt: Make preempt count unconditional

2020-09-15 Thread Linus Torvalds
On Tue, Sep 15, 2020 at 1:39 AM Thomas Gleixner  wrote:
>
> OTOH, having a working 'preemptible()' or maybe better named
> 'can_schedule()' check makes tons of sense to make decisions about
> allocation modes or other things.

No. I think that those kinds of decisions about actual behavior are
always simply fundamentally wrong.

Note that this is very different from having warnings about invalid
use. THAT is correct. It may not warn in all configurations, but that
doesn't matter: what matters is that it warns in common enough
configurations that developers will catch it.

So having a warning in "might_sleep()" that doesn't always trigger,
because you have a limited configuration that can't even detect the
situation, that's fine and dandy and intentional.

But having code like

   if (can_schedule())
   .. do something different ..

is fundamentally complete and utter garbage.

It's one thing if you test for "am I in hardware interrupt context".
Those tests aren't great either, but at least they make sense.

But a driver - or some library routine - making a difference based on
some nebulous "can I schedule" is fundamentally and basically WRONG.

If some code changes behavior, it needs to be explicit to the *caller*
of that code.

So this is why GFP_ATOMIC is fine, but "if (!can_schedule())
do_something_atomic()" is pure shite.

And I am not IN THE LEAST interested in trying to help people doing
pure shite. We need to fix them. Like the crypto code is getting
fixed.

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


[RFC 5/5] drm/dp: Revert "drm/dp: Introduce EDID-based quirks"

2020-09-15 Thread Lyude Paul
This reverts commit 0883ce8146ed6074c76399f4e70dbed788582e12. Originally
these quirks were added because of the issues with using the eDP
backlight interfaces on certain laptop panels, which made it impossible
to properly probe for DPCD backlight support without having a whitelist
for panels that we know have working VESA backlight control interfaces
over DPCD. As well, it should be noted it was impossible to use the
normal sink OUI for recognizing these panels as none of them actually
filled out their OUIs, hence needing to resort to checking EDIDs.

At the time we weren't really sure why certain panels had issues with
DPCD backlight controls, but we eventually figured out that there was a
second interface that these problematic laptop panels actually did work
with and advertise properly: Intel's proprietary backlight interface for
HDR panels. So far the testing we've done hasn't brought any panels to
light that advertise this interface and don't support it properly, which
means we finally have a real solution to this problem.

As a result, we now have no need for the force DPCD backlight quirk, and
furthermore this also removes the need for any kind of EDID quirk
checking in DRM. So, let's just revert it for now since we were the only
driver using this.

Signed-off-by: Lyude Paul 
Cc: thay...@noraisin.net
Cc: Vasily Khoruzhick 
---
 drivers/gpu/drm/drm_dp_helper.c   | 82 +--
 drivers/gpu/drm/drm_dp_mst_topology.c |  3 +-
 .../drm/i915/display/intel_display_types.h|  1 -
 drivers/gpu/drm/i915/display/intel_dp.c   | 12 +--
 drivers/gpu/drm/i915/display/intel_dp_mst.c   |  3 +-
 drivers/gpu/drm/i915/display/intel_psr.c  |  2 +-
 include/drm/drm_dp_helper.h   | 21 +
 7 files changed, 11 insertions(+), 113 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 1e7c638873c82..7138655bfc9d0 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -823,7 +823,7 @@ bool drm_dp_read_sink_count_cap(struct drm_connector 
*connector,
return connector->connector_type != DRM_MODE_CONNECTOR_eDP &&
dpcd[DP_DPCD_REV] >= DP_DPCD_REV_11 &&
dpcd[DP_DOWNSTREAMPORT_PRESENT] & DP_DWN_STRM_PORT_PRESENT &&
-   !drm_dp_has_quirk(desc, 0, DP_DPCD_QUIRK_NO_SINK_COUNT);
+   !drm_dp_has_quirk(desc, DP_DPCD_QUIRK_NO_SINK_COUNT);
 }
 EXPORT_SYMBOL(drm_dp_read_sink_count_cap);
 
@@ -1544,86 +1544,6 @@ drm_dp_get_quirks(const struct drm_dp_dpcd_ident *ident, 
bool is_branch)
 #undef DEVICE_ID_ANY
 #undef DEVICE_ID
 
-struct edid_quirk {
-   u8 mfg_id[2];
-   u8 prod_id[2];
-   u32 quirks;
-};
-
-#define MFG(first, second) { (first), (second) }
-#define PROD_ID(first, second) { (first), (second) }
-
-/*
- * Some devices have unreliable OUIDs where they don't set the device ID
- * correctly, and as a result we need to use the EDID for finding additional
- * DP quirks in such cases.
- */
-static const struct edid_quirk edid_quirk_list[] = {
-   /* Optional 4K AMOLED panel in the ThinkPad X1 Extreme 2nd Generation
-* only supports DPCD backlight controls
-*/
-   { MFG(0x4c, 0x83), PROD_ID(0x41, 0x41), 
BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
-   /*
-* Some Dell CML 2020 systems have panels support both AUX and PWM
-* backlight control, and some only support AUX backlight control. All
-* said panels start up in AUX mode by default, and we don't have any
-* support for disabling HDR mode on these panels which would be
-* required to switch to PWM backlight control mode (plus, I'm not
-* even sure we want PWM backlight controls over DPCD backlight
-* controls anyway...). Until we have a better way of detecting these,
-* force DPCD backlight mode on all of them.
-*/
-   { MFG(0x06, 0xaf), PROD_ID(0x9b, 0x32), 
BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
-   { MFG(0x06, 0xaf), PROD_ID(0xeb, 0x41), 
BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
-   { MFG(0x4d, 0x10), PROD_ID(0xc7, 0x14), 
BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
-   { MFG(0x4d, 0x10), PROD_ID(0xe6, 0x14), 
BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
-   { MFG(0x4c, 0x83), PROD_ID(0x47, 0x41), 
BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
-};
-
-#undef MFG
-#undef PROD_ID
-
-/**
- * drm_dp_get_edid_quirks() - Check the EDID of a DP device to find additional
- * DP-specific quirks
- * @edid: The EDID to check
- *
- * While OUIDs are meant to be used to recognize a DisplayPort device, a lot
- * of manufacturers don't seem to like following standards and neglect to fill
- * the dev-ID in, making it impossible to only use OUIDs for determining
- * quirks in some cases. This function can be used to check the EDID and look
- * up any additional DP quirks. The bits returned by this function correspond
- * to the quirk bits in _dp_quirk.
- *
- * Returns: a bitmask of quirks, if any. The 

[RFC 3/5] drm/i915: Keep track of pwm-related backlight hooks separately

2020-09-15 Thread Lyude Paul
Currently, every different type of backlight hook that i915 supports is
pretty straight forward - you have a backlight, probably through PWM
(but maybe DPCD), with a single set of platform-specific hooks that are
used for controlling it.

HDR backlights, in particular VESA and Intel's HDR backlight
implementations, can end up being more complicated. With Intel's
proprietary interface, HDR backlight controls always run through the
DPCD. When the backlight is in SDR backlight mode however, the driver
may need to bypass the TCON and control the backlight directly through
PWM.

So, in order to support this we'll need to split our backlight callbacks
into two groups: a set of high-level backlight control callbacks in
intel_panel, and an additional set of pwm-specific backlight control
callbacks. This also implies a functional changes for how these
callbacks are used:

* We now keep track of two separate backlight level ranges, one for the
  high-level backlight, and one for the pwm backlight range
* We also keep track of backlight enablement and PWM backlight
  enablement separately
* Since the currently set backlight level might not be the same as the
  currently programmed PWM backlight level, we stop setting
  panel->backlight.level with the currently programmed PWM backlight
  level in panel->backlight.pwm_funcs.setup(). Instead, we rely
  on the higher level backlight control functions to retrieve the
  current PWM backlight level (in this case, intel_pwm_get_backlight()).
  Note that there are still a few PWM backlight setup callbacks that
  do actually need to retrieve the current PWM backlight level, although
  we no longer save this value in panel->backlight.level like before.
* panel->backlight.pwm_funcs.enable()/disable() both accept a PWM
  brightness level, unlike their siblings
  panel->backlight.enable()/disable(). This is so we can calculate the
  actual PWM brightness level we want to set on disable/enable in the
  higher level backlight enable()/disable() functions, since this value
  might be scaled from a brightness level that doesn't come from PWM.

Signed-off-by: Lyude Paul 
Cc: thay...@noraisin.net
Cc: Vasily Khoruzhick 
---
 .../drm/i915/display/intel_display_types.h|  14 +-
 drivers/gpu/drm/i915/display/intel_panel.c| 436 ++
 2 files changed, 246 insertions(+), 204 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index b2d0edacc58c9..52a6543df842a 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -221,6 +221,9 @@ struct intel_panel {
bool alternate_pwm_increment;   /* lpt+ */
 
/* PWM chip */
+   u32 pwm_min;
+   u32 pwm_max;
+   bool pwm_enabled;
bool util_pin_active_low;   /* bxt+ */
u8 controller;  /* bxt+ only */
struct pwm_device *pwm;
@@ -229,6 +232,16 @@ struct intel_panel {
/* DPCD backlight */
u8 pwmgen_bit_count;
 
+   struct {
+   int (*setup)(struct intel_connector *connector, enum 
pipe pipe);
+   u32 (*get)(struct intel_connector *connector);
+   void (*set)(const struct drm_connector_state 
*conn_state, u32 level);
+   void (*disable)(const struct drm_connector_state 
*conn_state, u32 level);
+   void (*enable)(const struct intel_crtc_state 
*crtc_state,
+  const struct drm_connector_state 
*conn_state, u32 level);
+   u32 (*hz_to_pwm)(struct intel_connector *connector, u32 
hz);
+   } pwm_funcs;
+
struct backlight_device *device;
 
/* Connector and platform specific backlight functions */
@@ -238,7 +251,6 @@ struct intel_panel {
void (*disable)(const struct drm_connector_state *conn_state);
void (*enable)(const struct intel_crtc_state *crtc_state,
   const struct drm_connector_state *conn_state);
-   u32 (*hz_to_pwm)(struct intel_connector *connector, u32 hz);
void (*power)(struct intel_connector *, bool enable);
} backlight;
 };
diff --git a/drivers/gpu/drm/i915/display/intel_panel.c 
b/drivers/gpu/drm/i915/display/intel_panel.c
index c0e36244bb07d..6d3e9d51d069c 100644
--- a/drivers/gpu/drm/i915/display/intel_panel.c
+++ b/drivers/gpu/drm/i915/display/intel_panel.c
@@ -511,25 +511,34 @@ static u32 scale_hw_to_user(struct intel_connector 
*connector,
 0, user_max);
 }
 
-static u32 intel_panel_compute_brightness(struct intel_connector *connector,
- u32 val)
+static u32 intel_panel_sanitize_pwm_level(struct intel_connector *connector, 
u32 val)
 {
struct 

[RFC 4/5] drm/i915: Enable Intel's HDR backlight interface (only SDR for now)

2020-09-15 Thread Lyude Paul
So-recently a bunch of laptops on the market have started using DPCD
backlight controls instead of the traditional DDI backlight controls.
Originally we thought we had this handled by adding VESA backlight
control support to i915, but the story ended up being a lot more
complicated then that.

Simply put-there's two main backlight interfaces Intel can see in the
wild. Intel's proprietary HDR backlight interface, and the standard VESA
backlight interface. Note that many panels have been observed to report
support for both backlight interfaces, but testing has shown far more
panels work with the Intel HDR backlight interface at the moment.
Additionally, the VBT appears to be capable of reporting support for the
VESA backlight interface but not the Intel HDR interface which needs to
be probed by setting the right magic OUI.

On top of that however, there's also actually two different variants of
the Intel HDR backlight interface. The first uses the AUX channel for
controlling the brightness of the screen in both SDR and HDR mode, and
the second only uses the AUX channel for setting the brightness level in
HDR mode - relying on PWM for setting the brightness level in SDR mode.

For the time being we've been using EDIDs to maintain a list of quirks
for panels that safely do support the VESA backlight interface. Adding
support for Intel's HDR backlight interface in addition however, should
finally allow us to auto-detect eDP backlight controls properly so long
as we probe like so:

* If the panel's VBT reports VESA backlight support, assume it really
  does support it
* If the panel's VBT reports DDI backlight controls:
  * First probe for Intel's HDR backlight interface
  * If that fails, probe for VESA's backlight interface
  * If that fails, assume no DPCD backlight control
* If the panel's VBT reports any other backlight type: just assume it
  doesn't have DPCD backlight controls

Note as well that in order for us to make Intel's HDR backlight
interface appear, we need to start programming the appropriate source
OUI on the eDP panel as early as possible in the probing process. Note
that this technically could be done at any time before setting up
backlight controls, but this way allows us to avoid re-writing it
multiple times in case we need to use other source-OUI enabled features
in the future.

Finally, we also make sure to document the registers for this backlight
interface since eventually, we want to actually implement the full
interface instead of keeping it in SDR mode.

Signed-off-by: Lyude Paul 
Cc: thay...@noraisin.net
Cc: Vasily Khoruzhick 
---
 .../drm/i915/display/intel_display_types.h|   9 +-
 .../drm/i915/display/intel_dp_aux_backlight.c | 384 +++---
 drivers/gpu/drm/i915/display/intel_panel.c|  34 +-
 drivers/gpu/drm/i915/display/intel_panel.h|   4 +
 drivers/gpu/drm/i915/i915_params.c|   2 +-
 5 files changed, 381 insertions(+), 52 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 52a6543df842a..9d540368bac89 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -230,7 +230,14 @@ struct intel_panel {
struct pwm_state pwm_state;
 
/* DPCD backlight */
-   u8 pwmgen_bit_count;
+   union {
+   struct {
+   u8 pwmgen_bit_count;
+   } vesa;
+   struct {
+   bool sdr_uses_aux;
+   } intel;
+   } edp;
 
struct {
int (*setup)(struct intel_connector *connector, enum 
pipe pipe);
diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c 
b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
index acbd7eb66cbe3..aa1429302db70 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
@@ -22,10 +22,251 @@
  *
  */
 
+/*
+ * Laptops with Intel GPUs which have panels that support controlling the
+ * backlight through DP AUX can actually use two different interfaces: Intel's
+ * proprietary DP AUX backlight interface, and the standard VESA backlight
+ * interface. Unfortunately, at the time of writing this a lot of laptops will
+ * advertise support for the standard VESA backlight interface when they
+ * don't properly support it. However, on these systems the Intel backlight
+ * interface generally does work properly. Additionally, these systems will
+ * usually just indicate that they use PWM backlight controls in their VBIOS
+ * for some reason.
+ */
+
 #include "intel_display_types.h"
 #include "intel_dp_aux_backlight.h"
+#include "intel_panel.h"
+
+/* TODO:
+ * Implement HDR, right now we just implement the bare minimum to bring us 
back into SDR mode so we
+ * can make people's backlights 

[RFC 0/5] drm/i915: Add support for Intel's eDP backlight controls

2020-09-15 Thread Lyude Paul
A while ago we ran into issues while trying to enable the eDP backlight
control interface as defined by VESA, in order to make the DPCD
backlight controls on newer laptop panels work. The issue ended up being
much more complicated however, as we also apparently needed to add
support for an Intel-specific DPCD backlight control interface as the
VESA interface is broken on many laptop panels. For lack of a better
name, we just call this the Intel HDR backlight interface.

While this only adds support for the SDR backlight mode (I think), this
will fix a lot of user's laptop panels that we weren't able to properly
automatically detect DPCD backlight controls on previously.

Lyude Paul (5):
  drm/i915/dp: Program source OUI on eDP panels
  drm/i915: Rename pwm_* backlight callbacks to ext_pwm_*
  drm/i915: Keep track of pwm-related backlight hooks separately
  drm/i915: Enable Intel's HDR backlight interface (only SDR for now)
  drm/dp: Revert "drm/dp: Introduce EDID-based quirks"

 drivers/gpu/drm/drm_dp_helper.c   |  82 +--
 drivers/gpu/drm/drm_dp_mst_topology.c |   3 +-
 .../drm/i915/display/intel_display_types.h|  24 +-
 drivers/gpu/drm/i915/display/intel_dp.c   |  44 +-
 .../drm/i915/display/intel_dp_aux_backlight.c | 384 --
 drivers/gpu/drm/i915/display/intel_dp_mst.c   |   3 +-
 drivers/gpu/drm/i915/display/intel_panel.c| 476 ++
 drivers/gpu/drm/i915/display/intel_panel.h|   4 +
 drivers/gpu/drm/i915/display/intel_psr.c  |   2 +-
 drivers/gpu/drm/i915/i915_params.c|   2 +-
 include/drm/drm_dp_helper.h   |  21 +-
 11 files changed, 673 insertions(+), 372 deletions(-)

-- 
2.26.2

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


[RFC 2/5] drm/i915: Rename pwm_* backlight callbacks to ext_pwm_*

2020-09-15 Thread Lyude Paul
Since we're going to need to add a set of lower-level PWM backlight
control hooks to be shared by normal backlight controls and HDR
backlight controls in SDR mode, let's add a prefix to the external PWM
backlight functions so that the difference between them and the high
level PWM-only backlight functions is a bit more obvious.

This introduces no functional changes.

Signed-off-by: Lyude Paul 
Cc: thay...@noraisin.net
Cc: Vasily Khoruzhick 
---
 drivers/gpu/drm/i915/display/intel_panel.c | 24 +++---
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_panel.c 
b/drivers/gpu/drm/i915/display/intel_panel.c
index 9f23bac0d7924..c0e36244bb07d 100644
--- a/drivers/gpu/drm/i915/display/intel_panel.c
+++ b/drivers/gpu/drm/i915/display/intel_panel.c
@@ -589,7 +589,7 @@ static u32 bxt_get_backlight(struct intel_connector 
*connector)
 BXT_BLC_PWM_DUTY(panel->backlight.controller));
 }
 
-static u32 pwm_get_backlight(struct intel_connector *connector)
+static u32 ext_pwm_get_backlight(struct intel_connector *connector)
 {
struct intel_panel *panel = >panel;
struct pwm_state state;
@@ -666,7 +666,7 @@ static void bxt_set_backlight(const struct 
drm_connector_state *conn_state, u32
   BXT_BLC_PWM_DUTY(panel->backlight.controller), level);
 }
 
-static void pwm_set_backlight(const struct drm_connector_state *conn_state, 
u32 level)
+static void ext_pwm_set_backlight(const struct drm_connector_state 
*conn_state, u32 level)
 {
struct intel_panel *panel = 
_intel_connector(conn_state->connector)->panel;
 
@@ -835,7 +835,7 @@ static void cnp_disable_backlight(const struct 
drm_connector_state *old_conn_sta
   tmp & ~BXT_BLC_PWM_ENABLE);
 }
 
-static void pwm_disable_backlight(const struct drm_connector_state 
*old_conn_state)
+static void ext_pwm_disable_backlight(const struct drm_connector_state 
*old_conn_state)
 {
struct intel_connector *connector = 
to_intel_connector(old_conn_state->connector);
struct intel_panel *panel = >panel;
@@ -1168,8 +1168,8 @@ static void cnp_enable_backlight(const struct 
intel_crtc_state *crtc_state,
   pwm_ctl | BXT_BLC_PWM_ENABLE);
 }
 
-static void pwm_enable_backlight(const struct intel_crtc_state *crtc_state,
-const struct drm_connector_state *conn_state)
+static void ext_pwm_enable_backlight(const struct intel_crtc_state *crtc_state,
+const struct drm_connector_state 
*conn_state)
 {
struct intel_connector *connector = 
to_intel_connector(conn_state->connector);
struct intel_panel *panel = >panel;
@@ -1890,8 +1890,8 @@ cnp_setup_backlight(struct intel_connector *connector, 
enum pipe unused)
return 0;
 }
 
-static int pwm_setup_backlight(struct intel_connector *connector,
-  enum pipe pipe)
+static int ext_pwm_setup_backlight(struct intel_connector *connector,
+  enum pipe pipe)
 {
struct drm_device *dev = connector->base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
@@ -2065,11 +2065,11 @@ intel_panel_init_backlight_funcs(struct intel_panel 
*panel)
panel->backlight.hz_to_pwm = pch_hz_to_pwm;
} else if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
if (connector->base.connector_type == DRM_MODE_CONNECTOR_DSI) {
-   panel->backlight.setup = pwm_setup_backlight;
-   panel->backlight.enable = pwm_enable_backlight;
-   panel->backlight.disable = pwm_disable_backlight;
-   panel->backlight.set = pwm_set_backlight;
-   panel->backlight.get = pwm_get_backlight;
+   panel->backlight.setup = ext_pwm_setup_backlight;
+   panel->backlight.enable = ext_pwm_enable_backlight;
+   panel->backlight.disable = ext_pwm_disable_backlight;
+   panel->backlight.set = ext_pwm_set_backlight;
+   panel->backlight.get = ext_pwm_get_backlight;
} else {
panel->backlight.setup = vlv_setup_backlight;
panel->backlight.enable = vlv_enable_backlight;
-- 
2.26.2

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


[RFC 1/5] drm/i915/dp: Program source OUI on eDP panels

2020-09-15 Thread Lyude Paul
Since we're about to start adding support for Intel's magic HDR
backlight interface over DPCD, we need to ensure we're properly
programming this field so that Intel specific sink services are exposed.
Otherwise, 0x300-0x3ff will just read zeroes.

We also take care not to reprogram the source OUI if it already matches
what we expect. This is just to be careful so that we don't accidentally
take the panel out of any backlight control modes we found it in.

Signed-off-by: Lyude Paul 
Cc: thay...@noraisin.net
Cc: Vasily Khoruzhick 
---
 drivers/gpu/drm/i915/display/intel_dp.c | 32 +
 1 file changed, 32 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 4bd10456ad188..b591672ec4eab 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -3428,6 +3428,7 @@ void intel_dp_sink_set_decompression_state(struct 
intel_dp *intel_dp,
 void intel_dp_sink_dpms(struct intel_dp *intel_dp, int mode)
 {
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
+   u8 edp_oui[] = { 0x00, 0xaa, 0x01 };
int ret, i;
 
/* Should have a valid DPCD by this point */
@@ -3443,6 +3444,14 @@ void intel_dp_sink_dpms(struct intel_dp *intel_dp, int 
mode)
} else {
struct intel_lspcon *lspcon = dp_to_lspcon(intel_dp);
 
+   /* Write the source OUI as early as possible */
+   if (intel_dp_is_edp(intel_dp)) {
+   ret = drm_dp_dpcd_write(_dp->aux, DP_SOURCE_OUI, 
edp_oui,
+   sizeof(edp_oui));
+   if (ret < 0)
+   drm_err(>drm, "Failed to write eDP source 
OUI\n");
+   }
+
/*
 * When turning on, we need to retry for 1ms to give the sink
 * time to wake up.
@@ -4530,6 +4539,23 @@ static void intel_dp_get_dsc_sink_cap(struct intel_dp 
*intel_dp)
}
 }
 
+static void
+intel_edp_init_source_oui(struct intel_dp *intel_dp)
+{
+   struct drm_i915_private *i915 = dp_to_i915(intel_dp);
+   u8 oui[] = { 0x00, 0xaa, 0x01 };
+   u8 buf[3] = { 0 };
+
+   if (drm_dp_dpcd_read(_dp->aux, DP_SOURCE_OUI, buf, sizeof(buf)) < 
0)
+   drm_err(>drm, "Failed to read source OUI\n");
+
+   if (memcmp(oui, buf, sizeof(oui)) == 0)
+   return;
+
+   if (drm_dp_dpcd_write(_dp->aux, DP_SOURCE_OUI, oui, sizeof(oui)) 
< 0)
+   drm_err(>drm, "Failed to write source OUI\n");
+}
+
 static bool
 intel_edp_init_dpcd(struct intel_dp *intel_dp)
 {
@@ -4607,6 +4633,12 @@ intel_edp_init_dpcd(struct intel_dp *intel_dp)
if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
intel_dp_get_dsc_sink_cap(intel_dp);
 
+   /*
+* Program our source OUI so we can make various Intel-specific AUX
+* services available (such as HDR backlight controls)
+*/
+   intel_edp_init_source_oui(intel_dp);
+
return true;
 }
 
-- 
2.26.2

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


Re: [patch 00/13] preempt: Make preempt count unconditional

2020-09-15 Thread Paul E. McKenney
On Mon, Sep 14, 2020 at 01:59:15PM -0700, Linus Torvalds wrote:
> On Mon, Sep 14, 2020 at 1:45 PM Thomas Gleixner  wrote:
> >
> > Recently merged code does:
> >
> >  gfp = preemptible() ? GFP_KERNEL : GFP_ATOMIC;
> >
> > Looks obviously correct, except for the fact that preemptible() is
> > unconditionally false for CONFIF_PREEMPT_COUNT=n, i.e. all allocations in
> > that code use GFP_ATOMIC on such kernels.
> 
> I don't think this is a good reason to entirely get rid of the no-preempt 
> thing.
> 
> The above is just garbage. It's bogus. You can't do it.
> 
> Blaming the no-preempt code for this bug is extremely unfair, imho.
> 
> And the no-preempt code does help make for much better code generation
> for simple spinlocks.
> 
> Where is that horribly buggy recent code? It's not in that exact
> format, certainly, since 'grep' doesn't find it.

It would be convenient for that "gfp =" code to work, as this would
allow better cache locality while invoking RCU callbacks, and would
further provide better robustness to callback floods.  The full story
is quite long, but here are alternatives have not yet been proven to be
abject failures:

1.  Use workqueues to do the allocations in a clean context.
While waiting for the allocations, the callbacks are queued
in the old cache-busting manner.  This functions correctly,
but in the meantime (which on busy systems can be some time)
the cache locality and robustness are lost.

2.  Provide the ability to allocate memory in raw atomic context.
This is extremely effective, especially when used in combination
with #1 above, but as you might suspect, the MM guys don't like
it much.

In contrast, with Thomas's patch series, call_rcu() and kvfree_rcu()
could just look at preemptible() to see whether or not it was safe to
allocate memory, even in !PREEMPT kernels -- and in the common case,
it almost always would be safe.  It is quite possible that this approach
would work in isolation, or failing that, that adding #1 above would do
the trick.

I understand that this is all very hand-wavy, and I do apologize for that.
If you really want the full sad story with performance numbers and the
works, let me know!

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


Re: [PATCH v3 1/2] dt-bindings: display: bridge: Add documentation for LT9611UXC

2020-09-15 Thread Rob Herring
On Wed, 09 Sep 2020 12:28:22 +0300, Dmitry Baryshkov wrote:
> Lontium LT9611UXC is a DSI to HDMI bridge which supports 2 DSI ports
> and I2S port as input and one HDMI port as output. The LT9611UXC chip is
> handled by a separate driver, but the bindings used are fully compatible
> with the LT9611 chip, so let's reuse the lt9611.yaml schema.
> 
> Signed-off-by: Dmitry Baryshkov 
> Acked-by: Vinod Koul 
> Acked-by: Sam Ravnborg 
> ---
>  .../devicetree/bindings/display/bridge/lontium,lt9611.yaml   | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 

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


Re: [PATCH v2 08/16] drm/exynos: add host_ops callback for platform drivers

2020-09-15 Thread Andrzej Hajda

W dniu 11.09.2020 o 15:54, Michael Tretter pisze:
> Platform drivers need to be aware if a mipi dsi device attaches or
> detaches. Add host_ops to the driver_data for attach and detach
> callbacks and move the i80 mode selection and the hotplug handling into
> the callback, because these depend on the drm driver.
>
> Signed-off-by: Michael Tretter 
> ---
> v2:
> - new patch
> ---
>   drivers/gpu/drm/exynos/exynos_drm_dsi.c | 64 -
>   1 file changed, 53 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
> b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> index 1a15ae71205d..684a2fbef08a 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> @@ -239,6 +239,12 @@ struct exynos_dsi_transfer {
>   #define DSIM_STATE_CMD_LPM  BIT(2)
>   #define DSIM_STATE_VIDOUT_AVAILABLE BIT(3)
>   
> +struct exynos_dsi;
> +struct exynos_dsi_host_ops {
> + int (*attach)(struct device *dev, struct mipi_dsi_device *device);
> + int (*detach)(struct device *dev, struct mipi_dsi_device *device);
> +};
> +
>   enum exynos_reg_offset {
>   EXYNOS_REG_OFS,
>   EXYNOS5433_REG_OFS
> @@ -254,6 +260,7 @@ struct exynos_dsi_driver_data {
>   unsigned int wait_for_reset;
>   unsigned int num_bits_resol;
>   const unsigned int *reg_values;
> + const struct exynos_dsi_host_ops *host_ops;
>   };
>   
>   struct exynos_dsi {
> @@ -467,6 +474,41 @@ static const unsigned int exynos5433_reg_values[] = {
>   [PHYTIMING_HS_TRAIL] = 0x0c,
>   };
>   
> +static int __exynos_dsi_host_attach(struct device *dev,
> + struct mipi_dsi_device *device)
> +{
> + struct exynos_dsi *dsi = dev_get_drvdata(dev);
> + struct drm_device *drm = dsi->encoder.dev;


As I wrote yesterday drm device was guaranteed to be present here only 
if mipi dsi host registration was performed in component bind. In case 
it is performed in probe it will be always NULL, and the code does not 
make sense.


Regards

Andrzej



> + struct exynos_drm_crtc *crtc;
> +
> + mutex_lock(>mode_config.mutex);
> + crtc = exynos_drm_crtc_get_by_type(drm, EXYNOS_DISPLAY_TYPE_LCD);
> + crtc->i80_mode = !(device->mode_flags & MIPI_DSI_MODE_VIDEO);
> + mutex_unlock(>mode_config.mutex);
> +
> + if (drm->mode_config.poll_enabled)
> + drm_kms_helper_hotplug_event(drm);
> +
> + return 0;
> +}
> +
> +static int __exynos_dsi_host_detach(struct device *dev,
> +  struct mipi_dsi_device *device)
> +{
> + struct exynos_dsi *dsi = dev_get_drvdata(dev);
> + struct drm_device *drm = dsi->encoder.dev;
> +
> + if (drm->mode_config.poll_enabled)
> + drm_kms_helper_hotplug_event(drm);
> +
> + return 0;
> +}
> +
> +static const struct exynos_dsi_host_ops exynos_dsi_host_ops = {
> + .attach = __exynos_dsi_host_attach,
> + .detach = __exynos_dsi_host_detach,
> +};
> +
>   static const struct exynos_dsi_driver_data exynos3_dsi_driver_data = {
>   .reg_ofs = EXYNOS_REG_OFS,
>   .plltmr_reg = 0x50,
> @@ -477,6 +519,7 @@ static const struct exynos_dsi_driver_data 
> exynos3_dsi_driver_data = {
>   .wait_for_reset = 1,
>   .num_bits_resol = 11,
>   .reg_values = reg_values,
> + .host_ops = _dsi_host_ops,
>   };
>   
>   static const struct exynos_dsi_driver_data exynos4_dsi_driver_data = {
> @@ -489,6 +532,7 @@ static const struct exynos_dsi_driver_data 
> exynos4_dsi_driver_data = {
>   .wait_for_reset = 1,
>   .num_bits_resol = 11,
>   .reg_values = reg_values,
> + .host_ops = _dsi_host_ops,
>   };
>   
>   static const struct exynos_dsi_driver_data exynos5_dsi_driver_data = {
> @@ -499,6 +543,7 @@ static const struct exynos_dsi_driver_data 
> exynos5_dsi_driver_data = {
>   .wait_for_reset = 1,
>   .num_bits_resol = 11,
>   .reg_values = reg_values,
> + .host_ops = _dsi_host_ops,
>   };
>   
>   static const struct exynos_dsi_driver_data exynos5433_dsi_driver_data = {
> @@ -510,6 +555,7 @@ static const struct exynos_dsi_driver_data 
> exynos5433_dsi_driver_data = {
>   .wait_for_reset = 0,
>   .num_bits_resol = 12,
>   .reg_values = exynos5433_reg_values,
> + .host_ops = _dsi_host_ops,
>   };
>   
>   static const struct exynos_dsi_driver_data exynos5422_dsi_driver_data = {
> @@ -521,6 +567,7 @@ static const struct exynos_dsi_driver_data 
> exynos5422_dsi_driver_data = {
>   .wait_for_reset = 1,
>   .num_bits_resol = 12,
>   .reg_values = exynos5422_reg_values,
> + .host_ops = _dsi_host_ops,
>   };
>   
>   static const struct of_device_id exynos_dsi_of_match[] = {
> @@ -1551,8 +1598,8 @@ static int exynos_dsi_host_attach(struct mipi_dsi_host 
> *host,
> struct mipi_dsi_device *device)
>   {
>   struct exynos_dsi *dsi = host_to_dsi(host);
> + const struct exynos_dsi_host_ops *ops = 

Re: [PATCH 5.4 000/132] 5.4.66-rc1 review

2020-09-15 Thread Greg Kroah-Hartman
On Tue, Sep 15, 2020 at 08:14:34PM +0530, Naresh Kamboju wrote:
> On Tue, 15 Sep 2020 at 19:50, Greg Kroah-Hartman
>  wrote:
> >
> > This is the start of the stable review cycle for the 5.4.66 release.
> > There are 132 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Thu, 17 Sep 2020 14:06:12 +.
> > Anything received after that time might be too late.
> >
> > The whole patch series can be found in one patch at:
> > 
> > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.66-rc1.gz
> > or in the git tree and branch at:
> > 
> > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> > linux-5.4.y
> > and the diffstat can be found below.
> >
> > thanks,
> >
> > greg k-h
> >
> 
> arm and arm64 build breaks on stable rc 5.4.
> 
> make -sk KBUILD_BUILD_USER=TuxBuild -C/linux -j16 ARCH=arm
> CROSS_COMPILE=arm-linux-gnueabihf- HOSTCC=gcc CC="sccache
> arm-linux-gnueabihf-gcc" O=build zImage
> #
> ../kernel/kprobes.c: In function ‘kill_kprobe’:
> ../kernel/kprobes.c:1081:33: warning: statement with no effect 
> [-Wunused-value]
>  1081 | #define disarm_kprobe_ftrace(p) (-ENODEV)
>   | ^
> ../kernel/kprobes.c:2113:3: note: in expansion of macro ‘disarm_kprobe_ftrace’
>  2113 |   disarm_kprobe_ftrace(p);
>   |   ^~~~
> #
> # make -sk KBUILD_BUILD_USER=TuxBuild -C/linux -j16 ARCH=arm
> CROSS_COMPILE=arm-linux-gnueabihf- HOSTCC=gcc CC="sccache
> arm-linux-gnueabihf-gcc" O=build modules
> #
> ../drivers/gpu/drm/msm/adreno/a5xx_preempt.c: In function ‘preempt_init_ring’:
> ../drivers/gpu/drm/msm/adreno/a5xx_preempt.c:235:21: error:
> ‘MSM_BO_MAP_PRIV’ undeclared (first use in this function)
>   235 |   MSM_BO_UNCACHED | MSM_BO_MAP_PRIV, gpu->aspace, , );
>   | ^~~
> ../drivers/gpu/drm/msm/adreno/a5xx_preempt.c:235:21: note: each
> undeclared identifier is reported only once for each function it
> appears in
> make[5]: *** [../scripts/Makefile.build:266:
> drivers/gpu/drm/msm/adreno/a5xx_preempt.o] Error 1
> ../drivers/gpu/drm/msm/adreno/a6xx_gpu.c: In function ‘a6xx_hw_init’:
> ../drivers/gpu/drm/msm/adreno/a6xx_gpu.c:414:6: error: implicit
> declaration of function ‘adreno_is_a640’; did you mean
> ‘adreno_is_a540’? [-Werror=implicit-function-declaration]
>   414 |  if (adreno_is_a640(adreno_gpu) || adreno_is_a650(adreno_gpu)) {
>   |  ^~
>   |  adreno_is_a540
> ../drivers/gpu/drm/msm/adreno/a6xx_gpu.c:414:36: error: implicit
> declaration of function ‘adreno_is_a650’; did you mean
> ‘adreno_is_a540’? [-Werror=implicit-function-declaration]
>   414 |  if (adreno_is_a640(adreno_gpu) || adreno_is_a650(adreno_gpu)) {
>   |^~
>   |adreno_is_a540
> ../drivers/gpu/drm/msm/adreno/a6xx_gpu.c:415:18: error:
> ‘REG_A6XX_GBIF_QSB_SIDE0’ undeclared (first use in this function)
>   415 |   gpu_write(gpu, REG_A6XX_GBIF_QSB_SIDE0, 0x00071620);
>   |  ^~~
> ../drivers/gpu/drm/msm/adreno/a6xx_gpu.c:415:18: note: each undeclared
> identifier is reported only once for each function it appears in
> ../drivers/gpu/drm/msm/adreno/a6xx_gpu.c:416:18: error:
> ‘REG_A6XX_GBIF_QSB_SIDE1’ undeclared (first use in this function)
>   416 |   gpu_write(gpu, REG_A6XX_GBIF_QSB_SIDE1, 0x00071620);
>   |  ^~~
> ../drivers/gpu/drm/msm/adreno/a6xx_gpu.c:417:18: error:
> ‘REG_A6XX_GBIF_QSB_SIDE2’ undeclared (first use in this function)
>   417 |   gpu_write(gpu, REG_A6XX_GBIF_QSB_SIDE2, 0x00071620);
>   |  ^~~
> ../drivers/gpu/drm/msm/adreno/a6xx_gpu.c:418:18: error:
> ‘REG_A6XX_GBIF_QSB_SIDE3’ undeclared (first use in this function)
>   418 |   gpu_write(gpu, REG_A6XX_GBIF_QSB_SIDE3, 0x00071620);
>   |  ^~~
> cc1: some warnings being treated as errors
> make[5]: *** [../scripts/Makefile.build:265:
> drivers/gpu/drm/msm/adreno/a6xx_gpu.o] Error 1
> In file included from ../drivers/gpu/drm/msm/msm_gpu.c:7:
> ../drivers/gpu/drm/msm/msm_gpu.c: In function ‘msm_gpu_init’:
> ../drivers/gpu/drm/msm/msm_gpu.h:330:22: error: ‘MSM_BO_MAP_PRIV’
> undeclared (first use in this function)
>   330 |  (((gpu)->hw_apriv ? MSM_BO_MAP_PRIV : 0) | (flags))
>   |  ^~~
> ../drivers/gpu/drm/msm/msm_gpu.c:935:3: note: in expansion of macro
> ‘check_apriv’
>   935 |   check_apriv(gpu, MSM_BO_UNCACHED), gpu->aspace, >memptrs_bo,
>   |   ^~~
> ../drivers/gpu/drm/msm/msm_gpu.h:330:22: note: each undeclared
> identifier is reported only once for each function it appears in
>   330 |  (((gpu)->hw_apriv ? MSM_BO_MAP_PRIV : 0) | (flags))
>   |  ^~~

[PATCH v2] drm/msm: Fix the a650 hw_apriv check

2020-09-15 Thread Jordan Crouse
Commit 604234f33658 ("drm/msm: Enable expanded apriv support for a650")
was checking the result of adreno_is_a650() before the gpu revision
got probed in adreno_gpu_init() so it was always coming across as
false. Snoop into the revision ID ahead of time to correctly set the
hw_apriv flag so that it can be used by msm_gpu to properly setup
global buffers.

Fixes: 604234f33658 ("drm/msm: Enable expanded apriv support for a650")
Reported-by: Jonathan Marek 
Signed-off-by: Jordan Crouse 
Tested-by: Jonathan Marek 
---

 drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index 74bc27eb4203..f3b6d93c207c 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -1048,6 +1048,8 @@ struct msm_gpu *a6xx_gpu_init(struct drm_device *dev)
 {
struct msm_drm_private *priv = dev->dev_private;
struct platform_device *pdev = priv->gpu_pdev;
+   struct adreno_platform_config *config = pdev->dev.platform_data;
+   const struct adreno_info *info;
struct device_node *node;
struct a6xx_gpu *a6xx_gpu;
struct adreno_gpu *adreno_gpu;
@@ -1064,7 +1066,14 @@ struct msm_gpu *a6xx_gpu_init(struct drm_device *dev)
adreno_gpu->registers = NULL;
adreno_gpu->reg_offsets = a6xx_register_offsets;
 
-   if (adreno_is_a650(adreno_gpu))
+   /*
+* We need to know the platform type before calling into adreno_gpu_init
+* so that the hw_apriv flag can be correctly set. Snoop into the info
+* and grab the revision number
+*/
+   info = adreno_info(config->rev);
+
+   if (info && info->revn == 650)
adreno_gpu->base.hw_apriv = true;
 
ret = adreno_gpu_init(dev, pdev, adreno_gpu, , 1);
-- 
2.25.1

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


Re: [PATCH v2 03/10] dt-bindings: display: renesas: dw-hdmi: Add R8A77961 support

2020-09-15 Thread Rob Herring
On Tue, 08 Sep 2020 09:34:17 +0900, Kuninori Morimoto wrote:
> From: Kuninori Morimoto 
> 
> This patch adds R-Car M3-W+ (R8A77961) SoC bindings.
> 
> Signed-off-by: Kuninori Morimoto 
> Reviewed-by: Geert Uytterhoeven 
> ---
>  .../devicetree/bindings/display/bridge/renesas,dw-hdmi.txt   | 1 +
>  1 file changed, 1 insertion(+)
> 

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


Re: [PATCH v2 01/10] dt-bindings: display: renesas: du: Document the r8a77961 bindings

2020-09-15 Thread Rob Herring
On Tue, 08 Sep 2020 09:34:04 +0900, Kuninori Morimoto wrote:
> From: Kuninori Morimoto 
> 
> Document the R-Car M3-W+ (R8A77961) SoC in the R-Car DU bindings.
> 
> Signed-off-by: Kuninori Morimoto 
> ---
>  Documentation/devicetree/bindings/display/renesas,du.txt | 2 ++
>  1 file changed, 2 insertions(+)
> 

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


Re: [PATCH 2/6] dt-bindings: display: add Amlogic MIPI DSI Host Controller bindings

2020-09-15 Thread Neil Armstrong
On 15/09/2020 17:41, Rob Herring wrote:
> On Mon, Sep 07, 2020 at 10:18:21AM +0200, Neil Armstrong wrote:
>> The Amlogic AXg SoCs embeds a Synopsys DW-MIPI-DSI transceiver (ver 1.21a), 
>> with a custom
>> glue managing the IP resets, clock and data input similar to the DW-HDMI 
>> Glue on other
>> Amlogic SoCs.
>>
>> Signed-off-by: Neil Armstrong 
>> ---
>>  .../display/amlogic,meson-dw-mipi-dsi.yaml| 115 ++
>>  1 file changed, 115 insertions(+)
>>  create mode 100644 
>> Documentation/devicetree/bindings/display/amlogic,meson-dw-mipi-dsi.yaml
>>
>> diff --git 
>> a/Documentation/devicetree/bindings/display/amlogic,meson-dw-mipi-dsi.yaml 
>> b/Documentation/devicetree/bindings/display/amlogic,meson-dw-mipi-dsi.yaml
>> new file mode 100644
>> index ..6177f45ea1a6
>> --- /dev/null
>> +++ 
>> b/Documentation/devicetree/bindings/display/amlogic,meson-dw-mipi-dsi.yaml
>> @@ -0,0 +1,115 @@
>> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
>> +# Copyright 2020 BayLibre, SAS
>> +%YAML 1.2
>> +---
>> +$id: "http://devicetree.org/schemas/display/amlogic,meson-dw-mipi-dsi.yaml#;
>> +$schema: "http://devicetree.org/meta-schemas/core.yaml#;
>> +
>> +title: Amlogic specific extensions to the Synopsys Designware MIPI DSI Host 
>> Controller
>> +
>> +maintainers:
>> +  - Neil Armstrong 
>> +
>> +description: |
>> +  The Amlogic Meson Synopsys Designware Integration is composed of
>> +  - A Synopsys DesignWare MIPI DSI Host Controller IP
>> +  - A TOP control block controlling the Clocks & Resets of the IP
>> +
>> +allOf:
>> +  - $ref: dsi-controller.yaml#
>> +
>> +properties:
>> +  compatible:
>> +enum:
>> +  - amlogic,meson-axg-dw-mipi-dsi
>> +
>> +  reg:
>> +maxItems: 1
>> +
>> +  clocks:
>> +minItems: 2
>> +
>> +  clock-names:
>> +minItems: 2
>> +items:
>> +  - const: pclk
>> +  - const: px_clk
>> +  - const: meas_clk
>> +
>> +  resets:
>> +minItems: 1
>> +
>> +  reset-names:
>> +items:
>> +  - const: top
>> +
>> +  phys:
>> +minItems: 1
>> +
>> +  phy-names:
>> +items:
>> +  - const: dphy
>> +
>> +  ports:
>> +type: object
>> +
>> +properties:
>> +  port@0:
>> +type: object
>> +description: Input node to receive pixel data.
>> +  port@1:
>> +type: object
>> +description: DSI output node to panel.
>> +
>> +required:
>> +  - port@0
>> +  - port@1
>> +
>> +required:
>> +  - compatible
>> +  - reg
>> +  - clocks
>> +  - clock-names
>> +  - resets
>> +  - reset-names
>> +  - phys
>> +  - phy-names
>> +  - ports
>> +
>> +additionalProperties: false
> 
> Presumably you may have panel/bridge child nodes, so this needs to be 
> 'unevaluatedProperties: false'.

OK,

Thanks.

Neil


> 
> Rob
> 

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


[PATCH] drm/rockchip: cdn-dp: fix sign extension on an int multiply for a u64 result

2020-09-15 Thread Colin King
From: Colin Ian King 

The variable bit_per_pix is a u8 and is promoted in the multiplication
to an int type and then sign extended to a u64. If the result of the
int multiplication is greater than 0x7fff then the upper 32 bits will
be set to 1 as a result of the sign extension. Avoid this by casting
tu_size_reg to u64 to avoid sign extension and also a potential overflow.

Addresses-Coverity: ("Unintended sign extension")
Fixes: 1a0f7ed3abe2 ("drm/rockchip: cdn-dp: add cdn DP support for rk3399")
Signed-off-by: Colin Ian King 
---
 drivers/gpu/drm/rockchip/cdn-dp-reg.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/rockchip/cdn-dp-reg.c 
b/drivers/gpu/drm/rockchip/cdn-dp-reg.c
index 9d2163ef4d6e..33fb4d05c506 100644
--- a/drivers/gpu/drm/rockchip/cdn-dp-reg.c
+++ b/drivers/gpu/drm/rockchip/cdn-dp-reg.c
@@ -658,7 +658,7 @@ int cdn_dp_config_video(struct cdn_dp_device *dp)
 */
do {
tu_size_reg += 2;
-   symbol = tu_size_reg * mode->clock * bit_per_pix;
+   symbol = (u64)tu_size_reg * mode->clock * bit_per_pix;
do_div(symbol, dp->max_lanes * link_rate * 8);
rem = do_div(symbol, 1000);
if (tu_size_reg > 64) {
-- 
2.27.0

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


Re: [PATCH v2 06/21] drm/i915: Introduce GEM object functions

2020-09-15 Thread Tvrtko Ursulin



On 15/09/2020 15:59, Thomas Zimmermann wrote:

GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces the per-driver callbacks with
per-instance callbacks in i915.

v2:
* move object-function instance to i915_gem_object.c (Jani)

Signed-off-by: Thomas Zimmermann 
---
  drivers/gpu/drm/i915/gem/i915_gem_object.c| 21 ---
  drivers/gpu/drm/i915/gem/i915_gem_object.h|  3 ---
  drivers/gpu/drm/i915/i915_drv.c   |  4 
  .../gpu/drm/i915/selftests/mock_gem_device.c  |  3 ---
  4 files changed, 18 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c 
b/drivers/gpu/drm/i915/gem/i915_gem_object.c
index c8421fd9d2dc..3389ac972d16 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -39,9 +39,18 @@ static struct i915_global_object {
struct kmem_cache *slab_objects;
  } global;
  
+static const struct drm_gem_object_funcs i915_gem_object_funcs;

+
  struct drm_i915_gem_object *i915_gem_object_alloc(void)
  {
-   return kmem_cache_zalloc(global.slab_objects, GFP_KERNEL);
+   struct drm_i915_gem_object *obj;
+
+   obj = kmem_cache_zalloc(global.slab_objects, GFP_KERNEL);
+   if (!obj)
+   return NULL;
+   obj->base.funcs = _gem_object_funcs;
+
+   return obj;
  }
  
  void i915_gem_object_free(struct drm_i915_gem_object *obj)

@@ -101,7 +110,7 @@ void i915_gem_object_set_cache_coherency(struct 
drm_i915_gem_object *obj,
!(obj->cache_coherent & I915_BO_CACHE_COHERENT_FOR_WRITE);
  }
  
-void i915_gem_close_object(struct drm_gem_object *gem, struct drm_file *file)

+static void i915_gem_close_object(struct drm_gem_object *gem, struct drm_file 
*file)
  {
struct drm_i915_gem_object *obj = to_intel_bo(gem);
struct drm_i915_file_private *fpriv = file->driver_priv;
@@ -264,7 +273,7 @@ static void __i915_gem_free_work(struct work_struct *work)
i915_gem_flush_free_objects(i915);
  }
  
-void i915_gem_free_object(struct drm_gem_object *gem_obj)

+static void i915_gem_free_object(struct drm_gem_object *gem_obj)
  {
struct drm_i915_gem_object *obj = to_intel_bo(gem_obj);
struct drm_i915_private *i915 = to_i915(obj->base.dev);
@@ -403,6 +412,12 @@ int __init i915_global_objects_init(void)
return 0;
  }
  
+static const struct drm_gem_object_funcs i915_gem_object_funcs = {

+   .free = i915_gem_free_object,
+   .close = i915_gem_close_object,
+   .export = i915_gem_prime_export,
+};
+
  #if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
  #include "selftests/huge_gem_object.c"
  #include "selftests/huge_pages.c"
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h 
b/drivers/gpu/drm/i915/gem/i915_gem_object.h
index d46db8d8f38e..eaf3d4147be0 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
@@ -38,9 +38,6 @@ void __i915_gem_object_release_shmem(struct 
drm_i915_gem_object *obj,
  
  int i915_gem_object_attach_phys(struct drm_i915_gem_object *obj, int align);
  
-void i915_gem_close_object(struct drm_gem_object *gem, struct drm_file *file);

-void i915_gem_free_object(struct drm_gem_object *obj);
-
  void i915_gem_flush_free_objects(struct drm_i915_private *i915);
  
  struct sg_table *

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 94e00e450683..011a3fb41ece 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1750,12 +1750,8 @@ static struct drm_driver driver = {
.lastclose = i915_driver_lastclose,
.postclose = i915_driver_postclose,
  
-	.gem_close_object = i915_gem_close_object,

-   .gem_free_object_unlocked = i915_gem_free_object,
-
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
-   .gem_prime_export = i915_gem_prime_export,
.gem_prime_import = i915_gem_prime_import,
  
  	.dumb_create = i915_gem_dumb_create,

diff --git a/drivers/gpu/drm/i915/selftests/mock_gem_device.c 
b/drivers/gpu/drm/i915/selftests/mock_gem_device.c
index f127e633f7ca..9244b5d6fb01 100644
--- a/drivers/gpu/drm/i915/selftests/mock_gem_device.c
+++ b/drivers/gpu/drm/i915/selftests/mock_gem_device.c
@@ -87,9 +87,6 @@ static struct drm_driver mock_driver = {
.name = "mock",
.driver_features = DRIVER_GEM,
.release = mock_device_release,
-
-   .gem_close_object = i915_gem_close_object,
-   .gem_free_object_unlocked = i915_gem_free_object,
  };
  
  static void release_dev(struct device *dev)




Looks obviously fine.

Reviewed-by: Tvrtko Ursulin 

Regards,

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


Re: [patch 04/13] lockdep: Clenaup PREEMPT_COUNT leftovers

2020-09-15 Thread Will Deacon
On Mon, Sep 14, 2020 at 10:42:13PM +0200, Thomas Gleixner wrote:
> CONFIG_PREEMPT_COUNT is now unconditionally enabled and will be
> removed. Cleanup the leftovers before doing so.
> 
> Signed-off-by: Thomas Gleixner 
> Cc: Peter Zijlstra 
> Cc: Ingo Molnar 
> Cc: Will Deacon 
> ---
>  include/linux/lockdep.h |6 ++
>  lib/Kconfig.debug   |1 -
>  2 files changed, 2 insertions(+), 5 deletions(-)
> 
> --- a/include/linux/lockdep.h
> +++ b/include/linux/lockdep.h
> @@ -585,16 +585,14 @@ do {
> \
>  
>  #define lockdep_assert_preemption_enabled()  \
>  do { \
> - WARN_ON_ONCE(IS_ENABLED(CONFIG_PREEMPT_COUNT)   &&  \
> -  debug_locks&&  \
> + WARN_ON_ONCE(debug_locks&&  \
>(preempt_count() != 0  ||  \
> !raw_cpu_read(hardirqs_enabled)));\
>  } while (0)
>  
>  #define lockdep_assert_preemption_disabled() \
>  do { \
> - WARN_ON_ONCE(IS_ENABLED(CONFIG_PREEMPT_COUNT)   &&  \
> -  debug_locks&&  \
> + WARN_ON_ONCE(debug_locks&&  \
>(preempt_count() == 0  &&  \
> raw_cpu_read(hardirqs_enabled))); \
>  } while (0)
> --- a/lib/Kconfig.debug
> +++ b/lib/Kconfig.debug
> @@ -1161,7 +1161,6 @@ config PROVE_LOCKING
>   select DEBUG_RWSEMS
>   select DEBUG_WW_MUTEX_SLOWPATH
>   select DEBUG_LOCK_ALLOC
> - select PREEMPT_COUNT
>   select TRACE_IRQFLAGS
>   default n
>   help

Acked-by: Will Deacon 

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


Re: [patch 06/13] locking/bitspinlock: Clenaup PREEMPT_COUNT leftovers

2020-09-15 Thread Will Deacon
On Mon, Sep 14, 2020 at 10:42:15PM +0200, Thomas Gleixner wrote:
> CONFIG_PREEMPT_COUNT is now unconditionally enabled and will be
> removed. Cleanup the leftovers before doing so.
> 
> Signed-off-by: Thomas Gleixner 
> ---
>  include/linux/bit_spinlock.h |4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> --- a/include/linux/bit_spinlock.h
> +++ b/include/linux/bit_spinlock.h
> @@ -90,10 +90,8 @@ static inline int bit_spin_is_locked(int
>  {
>  #if defined(CONFIG_SMP) || defined(CONFIG_DEBUG_SPINLOCK)
>   return test_bit(bitnum, addr);
> -#elif defined CONFIG_PREEMPT_COUNT
> - return preempt_count();
>  #else
> - return 1;
> + return preempt_count();
>  #endif

Acked-by: Will Deacon 

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


[PATCH] drm/msm: Fix the a650 hw_apriv check

2020-09-15 Thread Jordan Crouse
Commit 604234f33658 ("drm/msm: Enable expanded apriv support for a650")
was checking the result of adreno_is_a650() before the gpu revision
got probed in adreno_gpu_init() so it was always coming across as
false. Snoop into the revision ID ahead of time to correctly set the
hw_apriv flag so that it can be used by msm_gpu to properly setup
global buffers.

Fixes: 604234f33658 ("drm/msm: Enable expanded apriv support for a650")
Signed-off-by: Jordan Crouse 
---

 drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index 74bc27eb4203..f3b6d93c207c 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -1048,6 +1048,8 @@ struct msm_gpu *a6xx_gpu_init(struct drm_device *dev)
 {
struct msm_drm_private *priv = dev->dev_private;
struct platform_device *pdev = priv->gpu_pdev;
+   struct adreno_platform_config *config = pdev->dev.platform_data;
+   const struct adreno_info *info;
struct device_node *node;
struct a6xx_gpu *a6xx_gpu;
struct adreno_gpu *adreno_gpu;
@@ -1064,7 +1066,14 @@ struct msm_gpu *a6xx_gpu_init(struct drm_device *dev)
adreno_gpu->registers = NULL;
adreno_gpu->reg_offsets = a6xx_register_offsets;
 
-   if (adreno_is_a650(adreno_gpu))
+   /*
+* We need to know the platform type before calling into adreno_gpu_init
+* so that the hw_apriv flag can be correctly set. Snoop into the info
+* and grab the revision number
+*/
+   info = adreno_info(config->rev);
+
+   if (info && info->revn == 650)
adreno_gpu->base.hw_apriv = true;
 
ret = adreno_gpu_init(dev, pdev, adreno_gpu, , 1);
-- 
2.25.1

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


Re: [PATCH v2 20/21] drm/xlnx: Initialize DRM driver instance with CMA helper macro

2020-09-15 Thread Laurent Pinchart
Hi Thomas,

Thank you for the patch.

On Tue, Sep 15, 2020 at 04:59:57PM +0200, Thomas Zimmermann wrote:
> The xlnx driver uses CMA helpers with default callback functions.
> Initialize the driver structure with the rsp CMA helper macro. The
> driver is being converted to use GEM object functions as part of
> this change.
> 
> Two callbacks, .dumb_destroy and .gem_prime_import, were initialized
> to their default implementations, so they are just kept empty now.
> 
> v2:
>   * initialize with DRM_GEM_CMA_DRIVER_OPS_WITH_DUMB_CREATE (Laurent)
> 
> Signed-off-by: Thomas Zimmermann 

Reviewed-by: Laurent Pinchart 

> ---
>  drivers/gpu/drm/xlnx/zynqmp_dpsub.c | 14 +-
>  1 file changed, 1 insertion(+), 13 deletions(-)
> 
> diff --git a/drivers/gpu/drm/xlnx/zynqmp_dpsub.c 
> b/drivers/gpu/drm/xlnx/zynqmp_dpsub.c
> index 8e69303aad3f..f3ffc3703a0e 100644
> --- a/drivers/gpu/drm/xlnx/zynqmp_dpsub.c
> +++ b/drivers/gpu/drm/xlnx/zynqmp_dpsub.c
> @@ -80,19 +80,7 @@ static struct drm_driver zynqmp_dpsub_drm_driver = {
>   .driver_features= DRIVER_MODESET | DRIVER_GEM |
> DRIVER_ATOMIC,
>  
> - .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,
> - .gem_prime_vunmap   = drm_gem_cma_prime_vunmap,
> - .gem_prime_mmap = drm_gem_cma_prime_mmap,
> - .gem_free_object_unlocked   = drm_gem_cma_free_object,
> - .gem_vm_ops = _gem_cma_vm_ops,
> - .dumb_create= zynqmp_dpsub_dumb_create,
> - .dumb_destroy   = drm_gem_dumb_destroy,
> + DRM_GEM_CMA_DRIVER_OPS_WITH_DUMB_CREATE(zynqmp_dpsub_dumb_create),
>  
>   .fops   = _dpsub_drm_fops,
>  

-- 
Regards,

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


RE: [PATCH] drm/ttm: some cleanups

2020-09-15 Thread Ruhl, Michael J

>-Original Message-
>From: dri-devel  On Behalf Of
>Christian König
>Sent: Tuesday, September 15, 2020 10:31 AM
>To: dri-devel@lists.freedesktop.org
>Subject: [PATCH] drm/ttm: some cleanups
>
>Unexport ttm_check_under_lowerlimit.
>Make ttm_bo_acc_size static and unexport it.
>Remove ttm_get_kernel_zone_memory_size.
>
>Signed-off-by: Christian König 
>---
> drivers/gpu/drm/ttm/ttm_bo.c |  7 +++
> drivers/gpu/drm/ttm/ttm_memory.c |  7 ---
> include/drm/ttm/ttm_bo_api.h | 12 
> include/drm/ttm/ttm_memory.h |  1 -
> 4 files changed, 3 insertions(+), 24 deletions(-)
>
>diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
>index ee2632128d3c..ffbdc20d8e8d 100644
>--- a/drivers/gpu/drm/ttm/ttm_bo.c
>+++ b/drivers/gpu/drm/ttm/ttm_bo.c
>@@ -1254,9 +1254,9 @@ int ttm_bo_init(struct ttm_bo_device *bdev,
> }
> EXPORT_SYMBOL(ttm_bo_init);
>
>-size_t ttm_bo_acc_size(struct ttm_bo_device *bdev,
>- unsigned long bo_size,
>- unsigned struct_size)
>+static size_t ttm_bo_acc_size(struct ttm_bo_device *bdev,
>+unsigned long bo_size,
>+unsigned struct_size)
> {
>   unsigned npages = (PAGE_ALIGN(bo_size)) >> PAGE_SHIFT;
>   size_t size = 0;
>@@ -1266,7 +1266,6 @@ size_t ttm_bo_acc_size(struct ttm_bo_device
>*bdev,
>   size += ttm_round_pot(sizeof(struct ttm_tt));
>   return size;
> }
>-EXPORT_SYMBOL(ttm_bo_acc_size);
>
> size_t ttm_bo_dma_acc_size(struct ttm_bo_device *bdev,
>  unsigned long bo_size,
>diff --git a/drivers/gpu/drm/ttm/ttm_memory.c
>b/drivers/gpu/drm/ttm/ttm_memory.c
>index acd63b70d814..987aa32c4808 100644
>--- a/drivers/gpu/drm/ttm/ttm_memory.c
>+++ b/drivers/gpu/drm/ttm/ttm_memory.c
>@@ -554,7 +554,6 @@ ttm_check_under_lowerlimit(struct ttm_mem_global
>*glob,
>
>   return false;
> }
>-EXPORT_SYMBOL(ttm_check_under_lowerlimit);
>
> static int ttm_mem_global_reserve(struct ttm_mem_global *glob,
> struct ttm_mem_zone *single_zone,
>@@ -682,9 +681,3 @@ size_t ttm_round_pot(size_t size)
>   return 0;
> }
> EXPORT_SYMBOL(ttm_round_pot);
>-
>-uint64_t ttm_get_kernel_zone_memory_size(struct ttm_mem_global *glob)
>-{
>-  return glob->zone_kernel->max_mem;
>-}
>-EXPORT_SYMBOL(ttm_get_kernel_zone_memory_size);
>diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h
>index 36ff64e2736c..fd8d29f5f370 100644
>--- a/include/drm/ttm/ttm_bo_api.h
>+++ b/include/drm/ttm/ttm_bo_api.h
>@@ -352,18 +352,6 @@ void ttm_bo_unlock_delayed_workqueue(struct
>ttm_bo_device *bdev, int resched);
> bool ttm_bo_eviction_valuable(struct ttm_buffer_object *bo,
> const struct ttm_place *place);
>
>-/**
>- * ttm_bo_acc_size
>- *
>- * @bdev: Pointer to a ttm_bo_device struct.
>- * @bo_size: size of the buffer object in byte.
>- * @struct_size: size of the structure holding buffer object datas
>- *
>- * Returns size to account for a buffer object
>- */
>-size_t ttm_bo_acc_size(struct ttm_bo_device *bdev,
>- unsigned long bo_size,
>- unsigned struct_size);
> size_t ttm_bo_dma_acc_size(struct ttm_bo_device *bdev,
>  unsigned long bo_size,
>  unsigned struct_size);
>diff --git a/include/drm/ttm/ttm_memory.h
>b/include/drm/ttm/ttm_memory.h
>index c78ea99c42cf..2d468d7c94e6 100644
>--- a/include/drm/ttm/ttm_memory.h
>+++ b/include/drm/ttm/ttm_memory.h
>@@ -91,7 +91,6 @@ extern int ttm_mem_global_alloc_page(struct
>ttm_mem_global *glob,
> extern void ttm_mem_global_free_page(struct ttm_mem_global *glob,
>struct page *page, uint64_t size);
> extern size_t ttm_round_pot(size_t size);
>-extern uint64_t ttm_get_kernel_zone_memory_size(struct
>ttm_mem_global *glob);
> extern bool ttm_check_under_lowerlimit(struct ttm_mem_global *glob,
>   uint64_t num_pages, struct ttm_operation_ctx *ctx);
   ^

Externs for function prototypes have always been a slight mystery to me.
Was this necessary for the EXPORT_SYMBOL?

Since this is now "local" is the extern still needed?

Regardless, I can't resist the low lying fruit...

Reviewed-by: Michael J. Ruhl 

M


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


Re: [PATCH 2/6] dt-bindings: display: add Amlogic MIPI DSI Host Controller bindings

2020-09-15 Thread Rob Herring
On Mon, Sep 07, 2020 at 10:18:21AM +0200, Neil Armstrong wrote:
> The Amlogic AXg SoCs embeds a Synopsys DW-MIPI-DSI transceiver (ver 1.21a), 
> with a custom
> glue managing the IP resets, clock and data input similar to the DW-HDMI Glue 
> on other
> Amlogic SoCs.
> 
> Signed-off-by: Neil Armstrong 
> ---
>  .../display/amlogic,meson-dw-mipi-dsi.yaml| 115 ++
>  1 file changed, 115 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/amlogic,meson-dw-mipi-dsi.yaml
> 
> diff --git 
> a/Documentation/devicetree/bindings/display/amlogic,meson-dw-mipi-dsi.yaml 
> b/Documentation/devicetree/bindings/display/amlogic,meson-dw-mipi-dsi.yaml
> new file mode 100644
> index ..6177f45ea1a6
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/amlogic,meson-dw-mipi-dsi.yaml
> @@ -0,0 +1,115 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +# Copyright 2020 BayLibre, SAS
> +%YAML 1.2
> +---
> +$id: "http://devicetree.org/schemas/display/amlogic,meson-dw-mipi-dsi.yaml#;
> +$schema: "http://devicetree.org/meta-schemas/core.yaml#;
> +
> +title: Amlogic specific extensions to the Synopsys Designware MIPI DSI Host 
> Controller
> +
> +maintainers:
> +  - Neil Armstrong 
> +
> +description: |
> +  The Amlogic Meson Synopsys Designware Integration is composed of
> +  - A Synopsys DesignWare MIPI DSI Host Controller IP
> +  - A TOP control block controlling the Clocks & Resets of the IP
> +
> +allOf:
> +  - $ref: dsi-controller.yaml#
> +
> +properties:
> +  compatible:
> +enum:
> +  - amlogic,meson-axg-dw-mipi-dsi
> +
> +  reg:
> +maxItems: 1
> +
> +  clocks:
> +minItems: 2
> +
> +  clock-names:
> +minItems: 2
> +items:
> +  - const: pclk
> +  - const: px_clk
> +  - const: meas_clk
> +
> +  resets:
> +minItems: 1
> +
> +  reset-names:
> +items:
> +  - const: top
> +
> +  phys:
> +minItems: 1
> +
> +  phy-names:
> +items:
> +  - const: dphy
> +
> +  ports:
> +type: object
> +
> +properties:
> +  port@0:
> +type: object
> +description: Input node to receive pixel data.
> +  port@1:
> +type: object
> +description: DSI output node to panel.
> +
> +required:
> +  - port@0
> +  - port@1
> +
> +required:
> +  - compatible
> +  - reg
> +  - clocks
> +  - clock-names
> +  - resets
> +  - reset-names
> +  - phys
> +  - phy-names
> +  - ports
> +
> +additionalProperties: false

Presumably you may have panel/bridge child nodes, so this needs to be 
'unevaluatedProperties: false'.

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


Re: [PATCH 1/6] dt-bindings: display: amlogic,meson-vpu: add bindings for VPU found in AXG SoCs

2020-09-15 Thread Rob Herring
On Mon, Sep 07, 2020 at 10:18:20AM +0200, Neil Armstrong wrote:
> The Amlogic AXG SoC family has a downgraded VPU supporting only MIPI-DSI 
> output
> after it's ENCL DPI encoder output.
> 
> Signed-off-by: Neil Armstrong 
> ---
>  .../bindings/display/amlogic,meson-vpu.yaml   | 36 +--
>  1 file changed, 33 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/display/amlogic,meson-vpu.yaml 
> b/Documentation/devicetree/bindings/display/amlogic,meson-vpu.yaml
> index a8d202c9d004..e2e7d99d8ace 100644
> --- a/Documentation/devicetree/bindings/display/amlogic,meson-vpu.yaml
> +++ b/Documentation/devicetree/bindings/display/amlogic,meson-vpu.yaml
> @@ -31,8 +31,10 @@ description: |
>  
>The Video Input Unit is in charge of the pixel scanout from the DDR memory.
>It fetches the frames addresses, stride and parameters from the "Canvas" 
> memory.
> +  On the AXG family, the Video Input Unit direclty reads from DDR memory.
>This part is also in charge of the CSC (Colorspace Conversion).
>It can handle 2 OSD Planes and 2 Video Planes.
> +  On the AXG family, only a single OSD plane without scalins is supported.

s/scalins/scaling/ ?

Otherwise,

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


Re: [PATCH v2 00/21] Convert all remaining drivers to GEM object functions

2020-09-15 Thread Christian König

Added my rb to the amdgpu and radeon patches.

Should we pick those up through the amd branches or do you want to push 
everything to drm-misc-next?


I think the later since this should result in much merge clash.

Christian.

Am 15.09.20 um 16:59 schrieb Thomas Zimmermann:

The GEM and PRIME related callbacks in struct drm_driver are deprecated in
favor of GEM object functions in struct drm_gem_object_funcs. This patchset
converts the remaining drivers to object functions and removes most of the
obsolete interfaces.

Patches #1 to #16 and #18 to #19 convert DRM drivers to GEM object functions,
one by one. Each patch moves existing callbacks from struct drm_driver to an
instance of struct drm_gem_object_funcs, and sets these funcs when the GEM
object is initialized. The expection is .gem_prime_mmap. There are different
ways of how drivers implement the callback, and moving it to GEM object
functions requires a closer review for each.

Patch #17 fixes virtgpu to use GEM object functions where possible. The
driver recently introduced a function for one of the deprecated callbacks.

Patch #20 converts xlnx to CMA helper macros. There's no apparent reason
why the driver does the GEM setup on it's own. Using CMA helper macros
adds GEM object functions implicitly.

With most of the GEM and PRIME moved to GEM object functions, related code
in struct drm_driver and in the DRM core/helpers is being removed by patch
#21.

Further testing is welcome. I tested the drivers for which I have HW
available. These are gma500, i915, nouveau, radeon and vc4. The console,
Weston and Xorg apparently work with the patches applied.

v2:
* moved code in amdgpu and radeon
* made several functions static in various drivers
* updated TODO-list item
* fix virtgpu

Thomas Zimmermann (21):
   drm/amdgpu: Introduce GEM object functions
   drm/armada: Introduce GEM object functions
   drm/etnaviv: Introduce GEM object functions
   drm/exynos: Introduce GEM object functions
   drm/gma500: Introduce GEM object functions
   drm/i915: Introduce GEM object functions
   drm/mediatek: Introduce GEM object functions
   drm/msm: Introduce GEM object funcs
   drm/nouveau: Introduce GEM object functions
   drm/omapdrm: Introduce GEM object functions
   drm/pl111: Introduce GEM object functions
   drm/radeon: Introduce GEM object functions
   drm/rockchip: Convert to drm_gem_object_funcs
   drm/tegra: Introduce GEM object functions
   drm/vc4: Introduce GEM object functions
   drm/vgem: Introduce GEM object functions
   drm/virtgpu: Set PRIME export function in struct drm_gem_object_funcs
   drm/vkms: Introduce GEM object functions
   drm/xen: Introduce GEM object functions
   drm/xlnx: Initialize DRM driver instance with CMA helper macro
   drm: Remove obsolete GEM and PRIME callbacks from struct drm_driver

  Documentation/gpu/todo.rst|  7 +-
  drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c   |  6 --
  drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c   | 23 +++--
  drivers/gpu/drm/amd/amdgpu/amdgpu_gem.h   |  5 --
  drivers/gpu/drm/amd/amdgpu/amdgpu_object.c|  1 +
  drivers/gpu/drm/armada/armada_drv.c   |  3 -
  drivers/gpu/drm/armada/armada_gem.c   | 12 ++-
  drivers/gpu/drm/armada/armada_gem.h   |  2 -
  drivers/gpu/drm/drm_gem.c | 35 ++--
  drivers/gpu/drm/drm_gem_cma_helper.c  |  6 +-
  drivers/gpu/drm/drm_prime.c   | 17 ++--
  drivers/gpu/drm/etnaviv/etnaviv_drv.c | 13 ---
  drivers/gpu/drm/etnaviv/etnaviv_drv.h |  1 -
  drivers/gpu/drm/etnaviv/etnaviv_gem.c | 19 -
  drivers/gpu/drm/exynos/exynos_drm_drv.c   | 10 ---
  drivers/gpu/drm/exynos/exynos_drm_gem.c   | 15 
  drivers/gpu/drm/gma500/framebuffer.c  |  2 +
  drivers/gpu/drm/gma500/gem.c  | 18 +++-
  drivers/gpu/drm/gma500/gem.h  |  3 +
  drivers/gpu/drm/gma500/psb_drv.c  |  9 --
  drivers/gpu/drm/gma500/psb_drv.h  |  2 -
  drivers/gpu/drm/i915/gem/i915_gem_object.c| 21 -
  drivers/gpu/drm/i915/gem/i915_gem_object.h|  3 -
  drivers/gpu/drm/i915/i915_drv.c   |  4 -
  .../gpu/drm/i915/selftests/mock_gem_device.c  |  3 -
  drivers/gpu/drm/mediatek/mtk_drm_drv.c|  5 --
  drivers/gpu/drm/mediatek/mtk_drm_gem.c| 11 +++
  drivers/gpu/drm/msm/msm_drv.c | 13 ---
  drivers/gpu/drm/msm/msm_drv.h |  1 -
  drivers/gpu/drm/msm/msm_gem.c | 19 -
  drivers/gpu/drm/nouveau/nouveau_drm.c |  9 --
  drivers/gpu/drm/nouveau/nouveau_gem.c | 13 +++
  drivers/gpu/drm/nouveau/nouveau_gem.h |  2 +
  drivers/gpu/drm/nouveau/nouveau_prime.c   |  2 +
  drivers/gpu/drm/omapdrm/omap_drv.c|  9 --
  drivers/gpu/drm/omapdrm/omap_gem.c| 18 +++-
  drivers/gpu/drm/omapdrm/omap_gem.h|  2 -
  drivers/gpu/drm/pl111/pl111_drv.c |  5 +-
  

Re: [PATCH v2 12/21] drm/radeon: Introduce GEM object functions

2020-09-15 Thread Christian König

Am 15.09.20 um 16:59 schrieb Thomas Zimmermann:

GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces the per-driver callbacks with
per-instance callbacks in radeon.

v2:
* move object-function instance to radeon_gem.c (Christian)
* set callbacks in radeon_gem_object_create() (Christian)

Signed-off-by: Thomas Zimmermann 


Reviewed-by: Christian König 


---
  drivers/gpu/drm/radeon/radeon_drv.c | 23 +
  drivers/gpu/drm/radeon/radeon_gem.c | 31 +
  2 files changed, 28 insertions(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_drv.c 
b/drivers/gpu/drm/radeon/radeon_drv.c
index 4cd30613fa1d..65061c949aee 100644
--- a/drivers/gpu/drm/radeon/radeon_drv.c
+++ b/drivers/gpu/drm/radeon/radeon_drv.c
@@ -124,13 +124,6 @@ void radeon_driver_irq_preinstall_kms(struct drm_device 
*dev);
  int radeon_driver_irq_postinstall_kms(struct drm_device *dev);
  void radeon_driver_irq_uninstall_kms(struct drm_device *dev);
  irqreturn_t radeon_driver_irq_handler_kms(int irq, void *arg);
-void radeon_gem_object_free(struct drm_gem_object *obj);
-int radeon_gem_object_open(struct drm_gem_object *obj,
-   struct drm_file *file_priv);
-void radeon_gem_object_close(struct drm_gem_object *obj,
-   struct drm_file *file_priv);
-struct dma_buf *radeon_gem_prime_export(struct drm_gem_object *gobj,
-   int flags);
  extern int radeon_get_crtc_scanoutpos(struct drm_device *dev, unsigned int 
crtc,
  unsigned int flags, int *vpos, int *hpos,
  ktime_t *stime, ktime_t *etime,
@@ -145,14 +138,9 @@ int radeon_mode_dumb_mmap(struct drm_file *filp,
  int radeon_mode_dumb_create(struct drm_file *file_priv,
struct drm_device *dev,
struct drm_mode_create_dumb *args);
-struct sg_table *radeon_gem_prime_get_sg_table(struct drm_gem_object *obj);
  struct drm_gem_object *radeon_gem_prime_import_sg_table(struct drm_device 
*dev,
struct 
dma_buf_attachment *,
struct sg_table *sg);
-int radeon_gem_prime_pin(struct drm_gem_object *obj);
-void radeon_gem_prime_unpin(struct drm_gem_object *obj);
-void *radeon_gem_prime_vmap(struct drm_gem_object *obj);
-void radeon_gem_prime_vunmap(struct drm_gem_object *obj, void *vaddr);
  
  /* atpx handler */

  #if defined(CONFIG_VGA_SWITCHEROO)
@@ -550,7 +538,7 @@ long radeon_drm_ioctl(struct file *filp,
}
  
  	ret = drm_ioctl(filp, cmd, arg);

-   
+
pm_runtime_mark_last_busy(dev->dev);
pm_runtime_put_autosuspend(dev->dev);
return ret;
@@ -609,22 +597,13 @@ static struct drm_driver kms_driver = {
.irq_uninstall = radeon_driver_irq_uninstall_kms,
.irq_handler = radeon_driver_irq_handler_kms,
.ioctls = radeon_ioctls_kms,
-   .gem_free_object_unlocked = radeon_gem_object_free,
-   .gem_open_object = radeon_gem_object_open,
-   .gem_close_object = radeon_gem_object_close,
.dumb_create = radeon_mode_dumb_create,
.dumb_map_offset = radeon_mode_dumb_mmap,
.fops = _driver_kms_fops,
  
  	.prime_handle_to_fd = drm_gem_prime_handle_to_fd,

.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
-   .gem_prime_export = radeon_gem_prime_export,
-   .gem_prime_pin = radeon_gem_prime_pin,
-   .gem_prime_unpin = radeon_gem_prime_unpin,
-   .gem_prime_get_sg_table = radeon_gem_prime_get_sg_table,
.gem_prime_import_sg_table = radeon_gem_prime_import_sg_table,
-   .gem_prime_vmap = radeon_gem_prime_vmap,
-   .gem_prime_vunmap = radeon_gem_prime_vunmap,
  
  	.name = DRIVER_NAME,

.desc = DRIVER_DESC,
diff --git a/drivers/gpu/drm/radeon/radeon_gem.c 
b/drivers/gpu/drm/radeon/radeon_gem.c
index e5c4271e64ed..0ccd7213e41f 100644
--- a/drivers/gpu/drm/radeon/radeon_gem.c
+++ b/drivers/gpu/drm/radeon/radeon_gem.c
@@ -35,7 +35,17 @@
  
  #include "radeon.h"
  
-void radeon_gem_object_free(struct drm_gem_object *gobj)

+struct dma_buf *radeon_gem_prime_export(struct drm_gem_object *gobj,
+   int flags);
+struct sg_table *radeon_gem_prime_get_sg_table(struct drm_gem_object *obj);
+int radeon_gem_prime_pin(struct drm_gem_object *obj);
+void radeon_gem_prime_unpin(struct drm_gem_object *obj);
+void *radeon_gem_prime_vmap(struct drm_gem_object *obj);
+void radeon_gem_prime_vunmap(struct drm_gem_object *obj, void *vaddr);
+
+static const struct drm_gem_object_funcs radeon_gem_object_funcs;
+
+static void radeon_gem_object_free(struct drm_gem_object *gobj)
  {
struct radeon_bo *robj = gem_to_radeon_bo(gobj);
  
@@ -85,6 +95,7 @@ int radeon_gem_object_create(struct radeon_device *rdev, unsigned long size,

 

Re: [PATCH v2 02/21] drm/armada: Introduce GEM object functions

2020-09-15 Thread Russell King - ARM Linux admin
On Tue, Sep 15, 2020 at 04:59:39PM +0200, Thomas Zimmermann wrote:
> GEM object functions deprecate several similar callback interfaces in
> struct drm_driver. This patch replaces the per-driver callbacks with
> per-instance callbacks in armada.
> 
> Signed-off-by: Thomas Zimmermann 

Acked-by: Russell King 

Thanks.

> ---
>  drivers/gpu/drm/armada/armada_drv.c |  3 ---
>  drivers/gpu/drm/armada/armada_gem.c | 12 +++-
>  drivers/gpu/drm/armada/armada_gem.h |  2 --
>  3 files changed, 11 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/armada/armada_drv.c 
> b/drivers/gpu/drm/armada/armada_drv.c
> index 980d3f1f8f16..22247cfce80b 100644
> --- a/drivers/gpu/drm/armada/armada_drv.c
> +++ b/drivers/gpu/drm/armada/armada_drv.c
> @@ -37,13 +37,10 @@ DEFINE_DRM_GEM_FOPS(armada_drm_fops);
>  
>  static struct drm_driver armada_drm_driver = {
>   .lastclose  = drm_fb_helper_lastclose,
> - .gem_free_object_unlocked = armada_gem_free_object,
>   .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
>   .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
> - .gem_prime_export   = armada_gem_prime_export,
>   .gem_prime_import   = armada_gem_prime_import,
>   .dumb_create= armada_gem_dumb_create,
> - .gem_vm_ops = _gem_vm_ops,
>   .major  = 1,
>   .minor  = 0,
>   .name   = "armada-drm",
> diff --git a/drivers/gpu/drm/armada/armada_gem.c 
> b/drivers/gpu/drm/armada/armada_gem.c
> index ecf8a55e93d9..c343fbefe47c 100644
> --- a/drivers/gpu/drm/armada/armada_gem.c
> +++ b/drivers/gpu/drm/armada/armada_gem.c
> @@ -25,7 +25,7 @@ static vm_fault_t armada_gem_vm_fault(struct vm_fault *vmf)
>   return vmf_insert_pfn(vmf->vma, vmf->address, pfn);
>  }
>  
> -const struct vm_operations_struct armada_gem_vm_ops = {
> +static const struct vm_operations_struct armada_gem_vm_ops = {
>   .fault  = armada_gem_vm_fault,
>   .open   = drm_gem_vm_open,
>   .close  = drm_gem_vm_close,
> @@ -184,6 +184,12 @@ armada_gem_map_object(struct drm_device *dev, struct 
> armada_gem_object *dobj)
>   return dobj->addr;
>  }
>  
> +static const struct drm_gem_object_funcs armada_gem_object_funcs = {
> + .free = armada_gem_free_object,
> + .export = armada_gem_prime_export,
> + .vm_ops = _gem_vm_ops,
> +};
> +
>  struct armada_gem_object *
>  armada_gem_alloc_private_object(struct drm_device *dev, size_t size)
>  {
> @@ -195,6 +201,8 @@ armada_gem_alloc_private_object(struct drm_device *dev, 
> size_t size)
>   if (!obj)
>   return NULL;
>  
> + obj->obj.funcs = _gem_object_funcs;
> +
>   drm_gem_private_object_init(dev, >obj, size);
>  
>   DRM_DEBUG_DRIVER("alloc private obj %p size %zu\n", obj, size);
> @@ -214,6 +222,8 @@ static struct armada_gem_object 
> *armada_gem_alloc_object(struct drm_device *dev,
>   if (!obj)
>   return NULL;
>  
> + obj->obj.funcs = _gem_object_funcs;
> +
>   if (drm_gem_object_init(dev, >obj, size)) {
>   kfree(obj);
>   return NULL;
> diff --git a/drivers/gpu/drm/armada/armada_gem.h 
> b/drivers/gpu/drm/armada/armada_gem.h
> index de04cc2c8f0e..ffcc7e8dd351 100644
> --- a/drivers/gpu/drm/armada/armada_gem.h
> +++ b/drivers/gpu/drm/armada/armada_gem.h
> @@ -21,8 +21,6 @@ struct armada_gem_object {
>   void*update_data;
>  };
>  
> -extern const struct vm_operations_struct armada_gem_vm_ops;
> -
>  #define drm_to_armada_gem(o) container_of(o, struct armada_gem_object, obj)
>  
>  void armada_gem_free_object(struct drm_gem_object *);
> -- 
> 2.28.0
> 
> 

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v2 01/21] drm/amdgpu: Introduce GEM object functions

2020-09-15 Thread Christian König

Am 15.09.20 um 16:59 schrieb Thomas Zimmermann:

GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces the per-driver callbacks with
per-instance callbacks in amdgpu. The only exception is gem_prime_mmap,
which is non-trivial to convert.

v2:
* move object-function instance to amdgpu_gem.c (Christian)
* set callbacks in amdgpu_gem_object_create() (Christian)

Signed-off-by: Thomas Zimmermann 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c|  6 --
  drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c| 23 +-
  drivers/gpu/drm/amd/amdgpu/amdgpu_gem.h|  5 -
  drivers/gpu/drm/amd/amdgpu/amdgpu_object.c |  1 +
  4 files changed, 19 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 6edde2b9e402..840ca8f9c1e1 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -1505,19 +1505,13 @@ static struct drm_driver kms_driver = {
.lastclose = amdgpu_driver_lastclose_kms,
.irq_handler = amdgpu_irq_handler,
.ioctls = amdgpu_ioctls_kms,
-   .gem_free_object_unlocked = amdgpu_gem_object_free,
-   .gem_open_object = amdgpu_gem_object_open,
-   .gem_close_object = amdgpu_gem_object_close,
.dumb_create = amdgpu_mode_dumb_create,
.dumb_map_offset = amdgpu_mode_dumb_mmap,
.fops = _driver_kms_fops,
  
  	.prime_handle_to_fd = drm_gem_prime_handle_to_fd,

.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
-   .gem_prime_export = amdgpu_gem_prime_export,
.gem_prime_import = amdgpu_gem_prime_import,
-   .gem_prime_vmap = amdgpu_gem_prime_vmap,
-   .gem_prime_vunmap = amdgpu_gem_prime_vunmap,
.gem_prime_mmap = amdgpu_gem_prime_mmap,
  
  	.name = DRIVER_NAME,

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
index aa7f230c71bf..aeecd5dc3ce4 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
@@ -36,9 +36,12 @@
  
  #include "amdgpu.h"

  #include "amdgpu_display.h"
+#include "amdgpu_dma_buf.h"
  #include "amdgpu_xgmi.h"
  
-void amdgpu_gem_object_free(struct drm_gem_object *gobj)

+static const struct drm_gem_object_funcs amdgpu_gem_object_funcs;
+
+static void amdgpu_gem_object_free(struct drm_gem_object *gobj)
  {
struct amdgpu_bo *robj = gem_to_amdgpu_bo(gobj);
  
@@ -87,6 +90,7 @@ int amdgpu_gem_object_create(struct amdgpu_device *adev, unsigned long size,

return r;
}
*obj = >tbo.base;
+   (*obj)->funcs = _gem_object_funcs;
  
  	return 0;

  }
@@ -119,8 +123,8 @@ void amdgpu_gem_force_release(struct amdgpu_device *adev)
   * Call from drm_gem_handle_create which appear in both new and open ioctl
   * case.
   */
-int amdgpu_gem_object_open(struct drm_gem_object *obj,
-  struct drm_file *file_priv)
+static int amdgpu_gem_object_open(struct drm_gem_object *obj,
+ struct drm_file *file_priv)
  {
struct amdgpu_bo *abo = gem_to_amdgpu_bo(obj);
struct amdgpu_device *adev = amdgpu_ttm_adev(abo->tbo.bdev);
@@ -152,8 +156,8 @@ int amdgpu_gem_object_open(struct drm_gem_object *obj,
return 0;
  }
  
-void amdgpu_gem_object_close(struct drm_gem_object *obj,

-struct drm_file *file_priv)
+static void amdgpu_gem_object_close(struct drm_gem_object *obj,
+   struct drm_file *file_priv)
  {
struct amdgpu_bo *bo = gem_to_amdgpu_bo(obj);
struct amdgpu_device *adev = amdgpu_ttm_adev(bo->tbo.bdev);
@@ -211,6 +215,15 @@ void amdgpu_gem_object_close(struct drm_gem_object *obj,
ttm_eu_backoff_reservation(, );
  }
  
+static const struct drm_gem_object_funcs amdgpu_gem_object_funcs = {

+   .free = amdgpu_gem_object_free,
+   .open = amdgpu_gem_object_open,
+   .close = amdgpu_gem_object_close,
+   .export = amdgpu_gem_prime_export,
+   .vmap = amdgpu_gem_prime_vmap,
+   .vunmap = amdgpu_gem_prime_vunmap,
+};
+
  /*
   * GEM ioctls.
   */
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.h
index e0f025dd1b14..637bf51dbf06 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.h
@@ -33,11 +33,6 @@
  #define AMDGPU_GEM_DOMAIN_MAX 0x3
  #define gem_to_amdgpu_bo(gobj) container_of((gobj), struct amdgpu_bo, 
tbo.base)
  
-void amdgpu_gem_object_free(struct drm_gem_object *obj);

-int amdgpu_gem_object_open(struct drm_gem_object *obj,
-   struct drm_file *file_priv);
-void amdgpu_gem_object_close(struct drm_gem_object *obj,
-   struct drm_file *file_priv);
  unsigned long amdgpu_gem_timeout(uint64_t timeout_ns);
  
  /*

diff --git 

[PATCH v2 15/21] drm/vc4: Introduce GEM object functions

2020-09-15 Thread Thomas Zimmermann
GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces the per-driver callbacks with
per-instance callbacks in vc4. The only exception is gem_prime_mmap,
which is non-trivial to convert.

Signed-off-by: Thomas Zimmermann 
Reviewed-by: Eric Anholt 
---
 drivers/gpu/drm/vc4/vc4_bo.c  | 21 -
 drivers/gpu/drm/vc4/vc4_drv.c | 12 
 drivers/gpu/drm/vc4/vc4_drv.h |  1 -
 3 files changed, 20 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_bo.c b/drivers/gpu/drm/vc4/vc4_bo.c
index 74ceebd62fbc..f432278173cd 100644
--- a/drivers/gpu/drm/vc4/vc4_bo.c
+++ b/drivers/gpu/drm/vc4/vc4_bo.c
@@ -21,6 +21,8 @@
 #include "vc4_drv.h"
 #include "uapi/drm/vc4_drm.h"
 
+static vm_fault_t vc4_fault(struct vm_fault *vmf);
+
 static const char * const bo_type_names[] = {
"kernel",
"V3D",
@@ -374,6 +376,21 @@ static struct vc4_bo *vc4_bo_get_from_cache(struct 
drm_device *dev,
return bo;
 }
 
+static const struct vm_operations_struct vc4_vm_ops = {
+   .fault = vc4_fault,
+   .open = drm_gem_vm_open,
+   .close = drm_gem_vm_close,
+};
+
+static const struct drm_gem_object_funcs vc4_gem_object_funcs = {
+   .free = vc4_free_object,
+   .export = vc4_prime_export,
+   .get_sg_table = drm_gem_cma_prime_get_sg_table,
+   .vmap = vc4_prime_vmap,
+   .vunmap = drm_gem_cma_prime_vunmap,
+   .vm_ops = _vm_ops,
+};
+
 /**
  * vc4_gem_create_object - Implementation of driver->gem_create_object.
  * @dev: DRM device
@@ -400,6 +417,8 @@ struct drm_gem_object *vc4_create_object(struct drm_device 
*dev, size_t size)
vc4->bo_labels[VC4_BO_TYPE_KERNEL].size_allocated += size;
mutex_unlock(>bo_lock);
 
+   bo->base.base.funcs = _gem_object_funcs;
+
return >base.base;
 }
 
@@ -684,7 +703,7 @@ struct dma_buf * vc4_prime_export(struct drm_gem_object 
*obj, int flags)
return dmabuf;
 }
 
-vm_fault_t vc4_fault(struct vm_fault *vmf)
+static vm_fault_t vc4_fault(struct vm_fault *vmf)
 {
struct vm_area_struct *vma = vmf->vma;
struct drm_gem_object *obj = vma->vm_private_data;
diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c
index f1a5fd5dab6f..d27eaa2d0cfe 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.c
+++ b/drivers/gpu/drm/vc4/vc4_drv.c
@@ -140,12 +140,6 @@ static void vc4_close(struct drm_device *dev, struct 
drm_file *file)
kfree(vc4file);
 }
 
-static const struct vm_operations_struct vc4_vm_ops = {
-   .fault = vc4_fault,
-   .open = drm_gem_vm_open,
-   .close = drm_gem_vm_close,
-};
-
 static const struct file_operations vc4_drm_fops = {
.owner = THIS_MODULE,
.open = drm_open,
@@ -195,16 +189,10 @@ static struct drm_driver vc4_drm_driver = {
 #endif
 
.gem_create_object = vc4_create_object,
-   .gem_free_object_unlocked = vc4_free_object,
-   .gem_vm_ops = _vm_ops,
 
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
-   .gem_prime_export = vc4_prime_export,
-   .gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
.gem_prime_import_sg_table = vc4_prime_import_sg_table,
-   .gem_prime_vmap = vc4_prime_vmap,
-   .gem_prime_vunmap = drm_gem_cma_prime_vunmap,
.gem_prime_mmap = vc4_prime_mmap,
 
.dumb_create = vc4_dumb_create,
diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
index 8c8d96b6289f..a22478a35199 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.h
+++ b/drivers/gpu/drm/vc4/vc4_drv.h
@@ -799,7 +799,6 @@ int vc4_get_hang_state_ioctl(struct drm_device *dev, void 
*data,
 struct drm_file *file_priv);
 int vc4_label_bo_ioctl(struct drm_device *dev, void *data,
   struct drm_file *file_priv);
-vm_fault_t vc4_fault(struct vm_fault *vmf);
 int vc4_mmap(struct file *filp, struct vm_area_struct *vma);
 int vc4_prime_mmap(struct drm_gem_object *obj, struct vm_area_struct *vma);
 struct drm_gem_object *vc4_prime_import_sg_table(struct drm_device *dev,
-- 
2.28.0

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


[PATCH v2 11/21] drm/pl111: Introduce GEM object functions

2020-09-15 Thread Thomas Zimmermann
GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces the per-driver callbacks with
per-instance callbacks in pl111. The only exception is gem_prime_mmap,
which is non-trivial to convert.

v2:
* use drm_gem_cma_create_object_default_funcs() (Eric)

Signed-off-by: Thomas Zimmermann 
Reviewed-by: Eric Anholt 
---
 drivers/gpu/drm/pl111/pl111_drv.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/pl111/pl111_drv.c 
b/drivers/gpu/drm/pl111/pl111_drv.c
index 46b0d1c4a16c..ecef8a2383d2 100644
--- a/drivers/gpu/drm/pl111/pl111_drv.c
+++ b/drivers/gpu/drm/pl111/pl111_drv.c
@@ -224,15 +224,12 @@ static struct drm_driver pl111_drm_driver = {
.major = 1,
.minor = 0,
.patchlevel = 0,
+   .gem_create_object = drm_gem_cma_create_object_default_funcs,
.dumb_create = drm_gem_cma_dumb_create,
-   .gem_free_object_unlocked = drm_gem_cma_free_object,
-   .gem_vm_ops = _gem_cma_vm_ops,
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
.gem_prime_import_sg_table = pl111_gem_import_sg_table,
-   .gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
.gem_prime_mmap = drm_gem_cma_prime_mmap,
-   .gem_prime_vmap = drm_gem_cma_prime_vmap,
 
 #if defined(CONFIG_DEBUG_FS)
.debugfs_init = pl111_debugfs_init,
-- 
2.28.0

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


[PATCH v2 13/21] drm/rockchip: Convert to drm_gem_object_funcs

2020-09-15 Thread Thomas Zimmermann
GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces the per-driver callbacks with
per-instance callbacks in rockchip. The only exception is gem_prime_mmap,
which is non-trivial to convert.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c |  5 -
 drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 10 ++
 2 files changed, 10 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
index 0f3eb392fe39..b7654f5e4225 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
@@ -212,15 +212,10 @@ static const struct file_operations 
rockchip_drm_driver_fops = {
 static struct drm_driver rockchip_drm_driver = {
.driver_features= DRIVER_MODESET | DRIVER_GEM | DRIVER_ATOMIC,
.lastclose  = drm_fb_helper_lastclose,
-   .gem_vm_ops = _gem_cma_vm_ops,
-   .gem_free_object_unlocked = rockchip_gem_free_object,
.dumb_create= rockchip_gem_dumb_create,
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
-   .gem_prime_get_sg_table = rockchip_gem_prime_get_sg_table,
.gem_prime_import_sg_table  = rockchip_gem_prime_import_sg_table,
-   .gem_prime_vmap = rockchip_gem_prime_vmap,
-   .gem_prime_vunmap   = rockchip_gem_prime_vunmap,
.gem_prime_mmap = rockchip_gem_mmap_buf,
.fops   = _drm_driver_fops,
.name   = DRIVER_NAME,
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
index 0055d86576f7..bddc7d99efe3 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
@@ -296,6 +296,14 @@ static void rockchip_gem_release_object(struct 
rockchip_gem_object *rk_obj)
kfree(rk_obj);
 }
 
+static const struct drm_gem_object_funcs rockchip_gem_object_funcs = {
+   .free = rockchip_gem_free_object,
+   .get_sg_table = rockchip_gem_prime_get_sg_table,
+   .vmap = rockchip_gem_prime_vmap,
+   .vunmap = rockchip_gem_prime_vunmap,
+   .vm_ops = _gem_cma_vm_ops,
+};
+
 static struct rockchip_gem_object *
rockchip_gem_alloc_object(struct drm_device *drm, unsigned int size)
 {
@@ -310,6 +318,8 @@ static struct rockchip_gem_object *
 
obj = _obj->base;
 
+   obj->funcs = _gem_object_funcs;
+
drm_gem_object_init(drm, obj, size);
 
return rk_obj;
-- 
2.28.0

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


[PATCH v2 18/21] drm/vkms: Introduce GEM object functions

2020-09-15 Thread Thomas Zimmermann
GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces the per-driver callbacks with
per-instance callbacks in vkms.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/vkms/vkms_drv.c |  8 
 drivers/gpu/drm/vkms/vkms_gem.c | 13 +
 2 files changed, 13 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/vkms/vkms_drv.c b/drivers/gpu/drm/vkms/vkms_drv.c
index cb0b6230c22c..726801ab44d4 100644
--- a/drivers/gpu/drm/vkms/vkms_drv.c
+++ b/drivers/gpu/drm/vkms/vkms_drv.c
@@ -51,12 +51,6 @@ static const struct file_operations vkms_driver_fops = {
.release= drm_release,
 };
 
-static const struct vm_operations_struct vkms_gem_vm_ops = {
-   .fault = vkms_gem_fault,
-   .open = drm_gem_vm_open,
-   .close = drm_gem_vm_close,
-};
-
 static void vkms_release(struct drm_device *dev)
 {
struct vkms_device *vkms = container_of(dev, struct vkms_device, drm);
@@ -98,8 +92,6 @@ static struct drm_driver vkms_driver = {
.release= vkms_release,
.fops   = _driver_fops,
.dumb_create= vkms_dumb_create,
-   .gem_vm_ops = _gem_vm_ops,
-   .gem_free_object_unlocked = vkms_gem_free_object,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
.gem_prime_import_sg_table = vkms_prime_import_sg_table,
 
diff --git a/drivers/gpu/drm/vkms/vkms_gem.c b/drivers/gpu/drm/vkms/vkms_gem.c
index a017fc59905e..19a0e260a4df 100644
--- a/drivers/gpu/drm/vkms/vkms_gem.c
+++ b/drivers/gpu/drm/vkms/vkms_gem.c
@@ -7,6 +7,17 @@
 
 #include "vkms_drv.h"
 
+static const struct vm_operations_struct vkms_gem_vm_ops = {
+   .fault = vkms_gem_fault,
+   .open = drm_gem_vm_open,
+   .close = drm_gem_vm_close,
+};
+
+static const struct drm_gem_object_funcs vkms_gem_object_funcs = {
+   .free = vkms_gem_free_object,
+   .vm_ops = _gem_vm_ops,
+};
+
 static struct vkms_gem_object *__vkms_gem_create(struct drm_device *dev,
 u64 size)
 {
@@ -17,6 +28,8 @@ static struct vkms_gem_object *__vkms_gem_create(struct 
drm_device *dev,
if (!obj)
return ERR_PTR(-ENOMEM);
 
+   obj->gem.funcs = _gem_object_funcs;
+
size = roundup(size, PAGE_SIZE);
ret = drm_gem_object_init(dev, >gem, size);
if (ret) {
-- 
2.28.0

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


[PATCH v2 20/21] drm/xlnx: Initialize DRM driver instance with CMA helper macro

2020-09-15 Thread Thomas Zimmermann
The xlnx driver uses CMA helpers with default callback functions.
Initialize the driver structure with the rsp CMA helper macro. The
driver is being converted to use GEM object functions as part of
this change.

Two callbacks, .dumb_destroy and .gem_prime_import, were initialized
to their default implementations, so they are just kept empty now.

v2:
* initialize with DRM_GEM_CMA_DRIVER_OPS_WITH_DUMB_CREATE (Laurent)

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/xlnx/zynqmp_dpsub.c | 14 +-
 1 file changed, 1 insertion(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/xlnx/zynqmp_dpsub.c 
b/drivers/gpu/drm/xlnx/zynqmp_dpsub.c
index 8e69303aad3f..f3ffc3703a0e 100644
--- a/drivers/gpu/drm/xlnx/zynqmp_dpsub.c
+++ b/drivers/gpu/drm/xlnx/zynqmp_dpsub.c
@@ -80,19 +80,7 @@ static struct drm_driver zynqmp_dpsub_drm_driver = {
.driver_features= DRIVER_MODESET | DRIVER_GEM |
  DRIVER_ATOMIC,
 
-   .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,
-   .gem_prime_vunmap   = drm_gem_cma_prime_vunmap,
-   .gem_prime_mmap = drm_gem_cma_prime_mmap,
-   .gem_free_object_unlocked   = drm_gem_cma_free_object,
-   .gem_vm_ops = _gem_cma_vm_ops,
-   .dumb_create= zynqmp_dpsub_dumb_create,
-   .dumb_destroy   = drm_gem_dumb_destroy,
+   DRM_GEM_CMA_DRIVER_OPS_WITH_DUMB_CREATE(zynqmp_dpsub_dumb_create),
 
.fops   = _dpsub_drm_fops,
 
-- 
2.28.0

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


[PATCH v2 07/21] drm/mediatek: Introduce GEM object functions

2020-09-15 Thread Thomas Zimmermann
GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces the per-driver callbacks with
per-instance callbacks in mediatek. The only exception is gem_prime_mmap,
which is non-trivial to convert.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/mediatek/mtk_drm_drv.c |  5 -
 drivers/gpu/drm/mediatek/mtk_drm_gem.c | 11 +++
 2 files changed, 11 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c 
b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index 040a8f393fe2..2f8d0043fca7 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -301,18 +301,13 @@ struct drm_gem_object *mtk_drm_gem_prime_import(struct 
drm_device *dev,
 static struct drm_driver mtk_drm_driver = {
.driver_features = DRIVER_MODESET | DRIVER_GEM | DRIVER_ATOMIC,
 
-   .gem_free_object_unlocked = mtk_drm_gem_free_object,
-   .gem_vm_ops = _gem_cma_vm_ops,
.dumb_create = mtk_drm_gem_dumb_create,
 
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
.gem_prime_import = mtk_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,
-   .gem_prime_vmap = mtk_drm_gem_prime_vmap,
-   .gem_prime_vunmap = mtk_drm_gem_prime_vunmap,
.fops = _drm_fops,
 
.name = DRIVER_NAME,
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_gem.c 
b/drivers/gpu/drm/mediatek/mtk_drm_gem.c
index 6190cc3b7b0d..591b90410e4a 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_gem.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_gem.c
@@ -8,11 +8,20 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include "mtk_drm_drv.h"
 #include "mtk_drm_gem.h"
 
+static const struct drm_gem_object_funcs mtk_drm_gem_object_funcs = {
+   .free = mtk_drm_gem_free_object,
+   .get_sg_table = mtk_gem_prime_get_sg_table,
+   .vmap = mtk_drm_gem_prime_vmap,
+   .vunmap = mtk_drm_gem_prime_vunmap,
+   .vm_ops = _gem_cma_vm_ops,
+};
+
 static struct mtk_drm_gem_obj *mtk_drm_gem_init(struct drm_device *dev,
unsigned long size)
 {
@@ -25,6 +34,8 @@ static struct mtk_drm_gem_obj *mtk_drm_gem_init(struct 
drm_device *dev,
if (!mtk_gem_obj)
return ERR_PTR(-ENOMEM);
 
+   mtk_gem_obj->base.funcs = _drm_gem_object_funcs;
+
ret = drm_gem_object_init(dev, _gem_obj->base, size);
if (ret < 0) {
DRM_ERROR("failed to initialize gem object\n");
-- 
2.28.0

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


[PATCH v2 19/21] drm/xen: Introduce GEM object functions

2020-09-15 Thread Thomas Zimmermann
GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces the per-driver callbacks with
per-instance callbacks in xen. The only exception is gem_prime_mmap,
which is non-trivial to convert.

v2:
* convert xen_drm_drv_free_object_unlocked() to static
  callback (Oleksandr)

Signed-off-by: Thomas Zimmermann 
Acked-by: Oleksandr Andrushchenko 
---
 drivers/gpu/drm/xen/xen_drm_front.c | 44 ++---
 drivers/gpu/drm/xen/xen_drm_front.h |  2 ++
 drivers/gpu/drm/xen/xen_drm_front_gem.c | 15 +
 3 files changed, 34 insertions(+), 27 deletions(-)

diff --git a/drivers/gpu/drm/xen/xen_drm_front.c 
b/drivers/gpu/drm/xen/xen_drm_front.c
index cc93a8c9547b..98b6d2ba088a 100644
--- a/drivers/gpu/drm/xen/xen_drm_front.c
+++ b/drivers/gpu/drm/xen/xen_drm_front.c
@@ -381,6 +381,23 @@ void xen_drm_front_on_frame_done(struct xen_drm_front_info 
*front_info,
fb_cookie);
 }
 
+void xen_drm_front_gem_object_free(struct drm_gem_object *obj)
+{
+   struct xen_drm_front_drm_info *drm_info = obj->dev->dev_private;
+   int idx;
+
+   if (drm_dev_enter(obj->dev, )) {
+   xen_drm_front_dbuf_destroy(drm_info->front_info,
+  xen_drm_front_dbuf_to_cookie(obj));
+   drm_dev_exit(idx);
+   } else {
+   dbuf_free(_info->front_info->dbuf_list,
+ xen_drm_front_dbuf_to_cookie(obj));
+   }
+
+   xen_drm_front_gem_free_object_unlocked(obj);
+}
+
 static int xen_drm_drv_dumb_create(struct drm_file *filp,
   struct drm_device *dev,
   struct drm_mode_create_dumb *args)
@@ -435,23 +452,6 @@ static int xen_drm_drv_dumb_create(struct drm_file *filp,
return ret;
 }
 
-static void xen_drm_drv_free_object_unlocked(struct drm_gem_object *obj)
-{
-   struct xen_drm_front_drm_info *drm_info = obj->dev->dev_private;
-   int idx;
-
-   if (drm_dev_enter(obj->dev, )) {
-   xen_drm_front_dbuf_destroy(drm_info->front_info,
-  xen_drm_front_dbuf_to_cookie(obj));
-   drm_dev_exit(idx);
-   } else {
-   dbuf_free(_info->front_info->dbuf_list,
- xen_drm_front_dbuf_to_cookie(obj));
-   }
-
-   xen_drm_front_gem_free_object_unlocked(obj);
-}
-
 static void xen_drm_drv_release(struct drm_device *dev)
 {
struct xen_drm_front_drm_info *drm_info = dev->dev_private;
@@ -483,22 +483,12 @@ static const struct file_operations xen_drm_dev_fops = {
.mmap   = xen_drm_front_gem_mmap,
 };
 
-static const struct vm_operations_struct xen_drm_drv_vm_ops = {
-   .open   = drm_gem_vm_open,
-   .close  = drm_gem_vm_close,
-};
-
 static struct drm_driver xen_drm_driver = {
.driver_features   = DRIVER_GEM | DRIVER_MODESET | 
DRIVER_ATOMIC,
.release   = xen_drm_drv_release,
-   .gem_vm_ops= _drm_drv_vm_ops,
-   .gem_free_object_unlocked  = xen_drm_drv_free_object_unlocked,
.prime_handle_to_fd= drm_gem_prime_handle_to_fd,
.prime_fd_to_handle= drm_gem_prime_fd_to_handle,
.gem_prime_import_sg_table = xen_drm_front_gem_import_sg_table,
-   .gem_prime_get_sg_table= xen_drm_front_gem_get_sg_table,
-   .gem_prime_vmap= xen_drm_front_gem_prime_vmap,
-   .gem_prime_vunmap  = xen_drm_front_gem_prime_vunmap,
.gem_prime_mmap= xen_drm_front_gem_prime_mmap,
.dumb_create   = xen_drm_drv_dumb_create,
.fops  = _drm_dev_fops,
diff --git a/drivers/gpu/drm/xen/xen_drm_front.h 
b/drivers/gpu/drm/xen/xen_drm_front.h
index 54486d89650e..cefafe859aba 100644
--- a/drivers/gpu/drm/xen/xen_drm_front.h
+++ b/drivers/gpu/drm/xen/xen_drm_front.h
@@ -160,4 +160,6 @@ int xen_drm_front_page_flip(struct xen_drm_front_info 
*front_info,
 void xen_drm_front_on_frame_done(struct xen_drm_front_info *front_info,
 int conn_idx, u64 fb_cookie);
 
+void xen_drm_front_gem_object_free(struct drm_gem_object *obj);
+
 #endif /* __XEN_DRM_FRONT_H_ */
diff --git a/drivers/gpu/drm/xen/xen_drm_front_gem.c 
b/drivers/gpu/drm/xen/xen_drm_front_gem.c
index a8aefaa38bd3..f3830a0d1808 100644
--- a/drivers/gpu/drm/xen/xen_drm_front_gem.c
+++ b/drivers/gpu/drm/xen/xen_drm_front_gem.c
@@ -57,6 +57,19 @@ static void gem_free_pages_array(struct xen_gem_object 
*xen_obj)
xen_obj->pages = NULL;
 }
 
+static const struct vm_operations_struct xen_drm_drv_vm_ops = {
+   .open   = drm_gem_vm_open,
+   .close  = drm_gem_vm_close,
+};
+
+static const struct drm_gem_object_funcs xen_drm_front_gem_object_funcs = {
+   .free = xen_drm_front_gem_object_free,
+   .get_sg_table = 

[PATCH v2 16/21] drm/vgem: Introduce GEM object functions

2020-09-15 Thread Thomas Zimmermann
GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces the per-driver callbacks with
per-instance callbacks in vgem. The only exception is gem_prime_mmap,
which is non-trivial to convert.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/vgem/vgem_drv.c | 21 ++---
 1 file changed, 14 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c
index cb884c890065..fa54a6d1403d 100644
--- a/drivers/gpu/drm/vgem/vgem_drv.c
+++ b/drivers/gpu/drm/vgem/vgem_drv.c
@@ -50,6 +50,8 @@
 #define DRIVER_MAJOR   1
 #define DRIVER_MINOR   0
 
+static const struct drm_gem_object_funcs vgem_gem_object_funcs;
+
 static struct vgem_device {
struct drm_device drm;
struct platform_device *platform;
@@ -167,6 +169,8 @@ static struct drm_vgem_gem_object *__vgem_gem_create(struct 
drm_device *dev,
if (!obj)
return ERR_PTR(-ENOMEM);
 
+   obj->base.funcs = _gem_object_funcs;
+
ret = drm_gem_object_init(dev, >base, roundup(size, PAGE_SIZE));
if (ret) {
kfree(obj);
@@ -401,12 +405,20 @@ static int vgem_prime_mmap(struct drm_gem_object *obj,
return 0;
 }
 
+static const struct drm_gem_object_funcs vgem_gem_object_funcs = {
+   .free = vgem_gem_free_object,
+   .pin = vgem_prime_pin,
+   .unpin = vgem_prime_unpin,
+   .get_sg_table = vgem_prime_get_sg_table,
+   .vmap = vgem_prime_vmap,
+   .vunmap = vgem_prime_vunmap,
+   .vm_ops = _gem_vm_ops,
+};
+
 static struct drm_driver vgem_driver = {
.driver_features= DRIVER_GEM | DRIVER_RENDER,
.open   = vgem_open,
.postclose  = vgem_postclose,
-   .gem_free_object_unlocked   = vgem_gem_free_object,
-   .gem_vm_ops = _gem_vm_ops,
.ioctls = vgem_ioctls,
.num_ioctls = ARRAY_SIZE(vgem_ioctls),
.fops   = _driver_fops,
@@ -415,13 +427,8 @@ static struct drm_driver vgem_driver = {
 
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
-   .gem_prime_pin = vgem_prime_pin,
-   .gem_prime_unpin = vgem_prime_unpin,
.gem_prime_import = vgem_prime_import,
.gem_prime_import_sg_table = vgem_prime_import_sg_table,
-   .gem_prime_get_sg_table = vgem_prime_get_sg_table,
-   .gem_prime_vmap = vgem_prime_vmap,
-   .gem_prime_vunmap = vgem_prime_vunmap,
.gem_prime_mmap = vgem_prime_mmap,
 
.name   = DRIVER_NAME,
-- 
2.28.0

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


[PATCH v2 14/21] drm/tegra: Introduce GEM object functions

2020-09-15 Thread Thomas Zimmermann
GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces the per-driver callbacks with
per-instance callbacks in tegra.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/tegra/drm.c | 4 
 drivers/gpu/drm/tegra/gem.c | 8 
 2 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index ba9d1c3e7cac..f0f581cd345e 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -858,12 +858,8 @@ static struct drm_driver tegra_drm_driver = {
.debugfs_init = tegra_debugfs_init,
 #endif
 
-   .gem_free_object_unlocked = tegra_bo_free_object,
-   .gem_vm_ops = _bo_vm_ops,
-
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
-   .gem_prime_export = tegra_gem_prime_export,
.gem_prime_import = tegra_gem_prime_import,
 
.dumb_create = tegra_bo_dumb_create,
diff --git a/drivers/gpu/drm/tegra/gem.c b/drivers/gpu/drm/tegra/gem.c
index 47e2935b8c68..d481dea4738d 100644
--- a/drivers/gpu/drm/tegra/gem.c
+++ b/drivers/gpu/drm/tegra/gem.c
@@ -231,6 +231,12 @@ static int tegra_bo_iommu_unmap(struct tegra_drm *tegra, 
struct tegra_bo *bo)
return 0;
 }
 
+static const struct drm_gem_object_funcs tegra_gem_object_funcs = {
+   .free = tegra_bo_free_object,
+   .export = tegra_gem_prime_export,
+   .vm_ops = _bo_vm_ops,
+};
+
 static struct tegra_bo *tegra_bo_alloc_object(struct drm_device *drm,
  size_t size)
 {
@@ -241,6 +247,8 @@ static struct tegra_bo *tegra_bo_alloc_object(struct 
drm_device *drm,
if (!bo)
return ERR_PTR(-ENOMEM);
 
+   bo->gem.funcs = _gem_object_funcs;
+
host1x_bo_init(>base, _bo_ops);
size = round_up(size, PAGE_SIZE);
 
-- 
2.28.0

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


[PATCH v2 03/21] drm/etnaviv: Introduce GEM object functions

2020-09-15 Thread Thomas Zimmermann
GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces the per-driver callbacks with
per-instance callbacks in etnaviv. The only exception is gem_prime_mmap,
which is non-trivial to convert.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/etnaviv/etnaviv_drv.c | 13 -
 drivers/gpu/drm/etnaviv/etnaviv_drv.h |  1 -
 drivers/gpu/drm/etnaviv/etnaviv_gem.c | 19 ++-
 3 files changed, 18 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c 
b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
index a9a3afaef9a1..aa270b79e585 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
@@ -468,12 +468,6 @@ static const struct drm_ioctl_desc etnaviv_ioctls[] = {
ETNA_IOCTL(PM_QUERY_SIG, pm_query_sig, DRM_RENDER_ALLOW),
 };
 
-static const struct vm_operations_struct vm_ops = {
-   .fault = etnaviv_gem_fault,
-   .open = drm_gem_vm_open,
-   .close = drm_gem_vm_close,
-};
-
 static const struct file_operations fops = {
.owner  = THIS_MODULE,
.open   = drm_open,
@@ -490,16 +484,9 @@ static struct drm_driver etnaviv_drm_driver = {
.driver_features= DRIVER_GEM | DRIVER_RENDER,
.open   = etnaviv_open,
.postclose   = etnaviv_postclose,
-   .gem_free_object_unlocked = etnaviv_gem_free_object,
-   .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_pin  = etnaviv_gem_prime_pin,
-   .gem_prime_unpin= etnaviv_gem_prime_unpin,
-   .gem_prime_get_sg_table = etnaviv_gem_prime_get_sg_table,
.gem_prime_import_sg_table = etnaviv_gem_prime_import_sg_table,
-   .gem_prime_vmap = etnaviv_gem_prime_vmap,
-   .gem_prime_vunmap   = etnaviv_gem_prime_vunmap,
.gem_prime_mmap = etnaviv_gem_prime_mmap,
 #ifdef CONFIG_DEBUG_FS
.debugfs_init   = etnaviv_debugfs_init,
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.h 
b/drivers/gpu/drm/etnaviv/etnaviv_drv.h
index 4d8dc9236e5f..914f0867ff71 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_drv.h
+++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.h
@@ -49,7 +49,6 @@ int etnaviv_ioctl_gem_submit(struct drm_device *dev, void 
*data,
struct drm_file *file);
 
 int etnaviv_gem_mmap(struct file *filp, struct vm_area_struct *vma);
-vm_fault_t etnaviv_gem_fault(struct vm_fault *vmf);
 int etnaviv_gem_mmap_offset(struct drm_gem_object *obj, u64 *offset);
 struct sg_table *etnaviv_gem_prime_get_sg_table(struct drm_gem_object *obj);
 void *etnaviv_gem_prime_vmap(struct drm_gem_object *obj);
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem.c 
b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
index ea19f1d27275..312e9d58d5a7 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gem.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
@@ -171,7 +171,7 @@ int etnaviv_gem_mmap(struct file *filp, struct 
vm_area_struct *vma)
return obj->ops->mmap(obj, vma);
 }
 
-vm_fault_t etnaviv_gem_fault(struct vm_fault *vmf)
+static vm_fault_t etnaviv_gem_fault(struct vm_fault *vmf)
 {
struct vm_area_struct *vma = vmf->vma;
struct drm_gem_object *obj = vma->vm_private_data;
@@ -561,6 +561,22 @@ void etnaviv_gem_obj_add(struct drm_device *dev, struct 
drm_gem_object *obj)
mutex_unlock(>gem_lock);
 }
 
+static const struct vm_operations_struct vm_ops = {
+   .fault = etnaviv_gem_fault,
+   .open = drm_gem_vm_open,
+   .close = drm_gem_vm_close,
+};
+
+static const struct drm_gem_object_funcs etnaviv_gem_object_funcs = {
+   .free = etnaviv_gem_free_object,
+   .pin = etnaviv_gem_prime_pin,
+   .unpin = etnaviv_gem_prime_unpin,
+   .get_sg_table = etnaviv_gem_prime_get_sg_table,
+   .vmap = etnaviv_gem_prime_vmap,
+   .vunmap = etnaviv_gem_prime_vunmap,
+   .vm_ops = _ops,
+};
+
 static int etnaviv_gem_new_impl(struct drm_device *dev, u32 size, u32 flags,
const struct etnaviv_gem_ops *ops, struct drm_gem_object **obj)
 {
@@ -595,6 +611,7 @@ static int etnaviv_gem_new_impl(struct drm_device *dev, u32 
size, u32 flags,
INIT_LIST_HEAD(_obj->vram_list);
 
*obj = _obj->base;
+   (*obj)->funcs = _gem_object_funcs;
 
return 0;
 }
-- 
2.28.0

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


[PATCH v2 08/21] drm/msm: Introduce GEM object funcs

2020-09-15 Thread Thomas Zimmermann
GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces the per-driver callbacks with
per-instance callbacks in msm. The only exception is gem_prime_mmap,
which is non-trivial to convert.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/msm/msm_drv.c | 13 -
 drivers/gpu/drm/msm/msm_drv.h |  1 -
 drivers/gpu/drm/msm/msm_gem.c | 19 ++-
 3 files changed, 18 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 79333842f70a..5952767ea478 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -978,12 +978,6 @@ static const struct drm_ioctl_desc msm_ioctls[] = {
DRM_IOCTL_DEF_DRV(MSM_SUBMITQUEUE_QUERY, msm_ioctl_submitqueue_query, 
DRM_RENDER_ALLOW),
 };
 
-static const struct vm_operations_struct vm_ops = {
-   .fault = msm_gem_fault,
-   .open = drm_gem_vm_open,
-   .close = drm_gem_vm_close,
-};
-
 static const struct file_operations fops = {
.owner  = THIS_MODULE,
.open   = drm_open,
@@ -1009,18 +1003,11 @@ static struct drm_driver msm_driver = {
.irq_preinstall = msm_irq_preinstall,
.irq_postinstall= msm_irq_postinstall,
.irq_uninstall  = msm_irq_uninstall,
-   .gem_free_object_unlocked = msm_gem_free_object,
-   .gem_vm_ops = _ops,
.dumb_create= msm_gem_dumb_create,
.dumb_map_offset= msm_gem_dumb_map_offset,
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
-   .gem_prime_pin  = msm_gem_prime_pin,
-   .gem_prime_unpin= msm_gem_prime_unpin,
-   .gem_prime_get_sg_table = msm_gem_prime_get_sg_table,
.gem_prime_import_sg_table = msm_gem_prime_import_sg_table,
-   .gem_prime_vmap = msm_gem_prime_vmap,
-   .gem_prime_vunmap   = msm_gem_prime_vunmap,
.gem_prime_mmap = msm_gem_prime_mmap,
 #ifdef CONFIG_DEBUG_FS
.debugfs_init   = msm_debugfs_init,
diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
index af259b0573ea..7bcea10be81f 100644
--- a/drivers/gpu/drm/msm/msm_drv.h
+++ b/drivers/gpu/drm/msm/msm_drv.h
@@ -269,7 +269,6 @@ void msm_gem_shrinker_cleanup(struct drm_device *dev);
 int msm_gem_mmap_obj(struct drm_gem_object *obj,
struct vm_area_struct *vma);
 int msm_gem_mmap(struct file *filp, struct vm_area_struct *vma);
-vm_fault_t msm_gem_fault(struct vm_fault *vmf);
 uint64_t msm_gem_mmap_offset(struct drm_gem_object *obj);
 int msm_gem_get_iova(struct drm_gem_object *obj,
struct msm_gem_address_space *aspace, uint64_t *iova);
diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
index b4553caaa196..de915ff6f4b4 100644
--- a/drivers/gpu/drm/msm/msm_gem.c
+++ b/drivers/gpu/drm/msm/msm_gem.c
@@ -247,7 +247,7 @@ int msm_gem_mmap(struct file *filp, struct vm_area_struct 
*vma)
return msm_gem_mmap_obj(vma->vm_private_data, vma);
 }
 
-vm_fault_t msm_gem_fault(struct vm_fault *vmf)
+static vm_fault_t msm_gem_fault(struct vm_fault *vmf)
 {
struct vm_area_struct *vma = vmf->vma;
struct drm_gem_object *obj = vma->vm_private_data;
@@ -994,6 +994,22 @@ int msm_gem_new_handle(struct drm_device *dev, struct 
drm_file *file,
return ret;
 }
 
+static const struct vm_operations_struct vm_ops = {
+   .fault = msm_gem_fault,
+   .open = drm_gem_vm_open,
+   .close = drm_gem_vm_close,
+};
+
+static const struct drm_gem_object_funcs msm_gem_object_funcs = {
+   .free = msm_gem_free_object,
+   .pin = msm_gem_prime_pin,
+   .unpin = msm_gem_prime_unpin,
+   .get_sg_table = msm_gem_prime_get_sg_table,
+   .vmap = msm_gem_prime_vmap,
+   .vunmap = msm_gem_prime_vunmap,
+   .vm_ops = _ops,
+};
+
 static int msm_gem_new_impl(struct drm_device *dev,
uint32_t size, uint32_t flags,
struct drm_gem_object **obj)
@@ -1024,6 +1040,7 @@ static int msm_gem_new_impl(struct drm_device *dev,
INIT_LIST_HEAD(_obj->vmas);
 
*obj = _obj->base;
+   (*obj)->funcs = _gem_object_funcs;
 
return 0;
 }
-- 
2.28.0

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


[PATCH v2 05/21] drm/gma500: Introduce GEM object functions

2020-09-15 Thread Thomas Zimmermann
GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces the per-driver callbacks with
per-instance callbacks in gma500.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/gma500/framebuffer.c |  2 ++
 drivers/gpu/drm/gma500/gem.c | 18 --
 drivers/gpu/drm/gma500/gem.h |  3 +++
 drivers/gpu/drm/gma500/psb_drv.c |  9 -
 drivers/gpu/drm/gma500/psb_drv.h |  2 --
 5 files changed, 21 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/gma500/framebuffer.c 
b/drivers/gpu/drm/gma500/framebuffer.c
index 54d9876b5305..5ede24fb44ae 100644
--- a/drivers/gpu/drm/gma500/framebuffer.c
+++ b/drivers/gpu/drm/gma500/framebuffer.c
@@ -24,6 +24,7 @@
 #include 
 
 #include "framebuffer.h"
+#include "gem.h"
 #include "gtt.h"
 #include "psb_drv.h"
 #include "psb_intel_drv.h"
@@ -285,6 +286,7 @@ static struct gtt_range *psbfb_alloc(struct drm_device 
*dev, int aligned_size)
/* Begin by trying to use stolen memory backing */
backing = psb_gtt_alloc_range(dev, aligned_size, "fb", 1, PAGE_SIZE);
if (backing) {
+   backing->gem.funcs = _gem_object_funcs;
drm_gem_private_object_init(dev, >gem, aligned_size);
return backing;
}
diff --git a/drivers/gpu/drm/gma500/gem.c b/drivers/gpu/drm/gma500/gem.c
index f9c4b1d76f56..8f07de83b6fb 100644
--- a/drivers/gpu/drm/gma500/gem.c
+++ b/drivers/gpu/drm/gma500/gem.c
@@ -18,7 +18,9 @@
 
 #include "psb_drv.h"
 
-void psb_gem_free_object(struct drm_gem_object *obj)
+static vm_fault_t psb_gem_fault(struct vm_fault *vmf);
+
+static void psb_gem_free_object(struct drm_gem_object *obj)
 {
struct gtt_range *gtt = container_of(obj, struct gtt_range, gem);
 
@@ -36,6 +38,17 @@ int psb_gem_get_aperture(struct drm_device *dev, void *data,
return -EINVAL;
 }
 
+static const struct vm_operations_struct psb_gem_vm_ops = {
+   .fault = psb_gem_fault,
+   .open = drm_gem_vm_open,
+   .close = drm_gem_vm_close,
+};
+
+const struct drm_gem_object_funcs psb_gem_object_funcs = {
+   .free = psb_gem_free_object,
+   .vm_ops = _gem_vm_ops,
+};
+
 /**
  * psb_gem_create  -   create a mappable object
  * @file: the DRM file of the client
@@ -63,6 +76,7 @@ int psb_gem_create(struct drm_file *file, struct drm_device 
*dev, u64 size,
dev_err(dev->dev, "no memory for %lld byte GEM object\n", size);
return -ENOSPC;
}
+   r->gem.funcs = _gem_object_funcs;
/* Initialize the extra goodies GEM needs to do all the hard work */
if (drm_gem_object_init(dev, >gem, size) != 0) {
psb_gtt_free_range(dev, r);
@@ -123,7 +137,7 @@ int psb_gem_dumb_create(struct drm_file *file, struct 
drm_device *dev,
  * vma->vm_private_data points to the GEM object that is backing this
  * mapping.
  */
-vm_fault_t psb_gem_fault(struct vm_fault *vmf)
+static vm_fault_t psb_gem_fault(struct vm_fault *vmf)
 {
struct vm_area_struct *vma = vmf->vma;
struct drm_gem_object *obj;
diff --git a/drivers/gpu/drm/gma500/gem.h b/drivers/gpu/drm/gma500/gem.h
index 4a74dc623b6b..3741a711b9fd 100644
--- a/drivers/gpu/drm/gma500/gem.h
+++ b/drivers/gpu/drm/gma500/gem.h
@@ -8,6 +8,9 @@
 #ifndef _GEM_H
 #define _GEM_H
 
+extern const struct drm_gem_object_funcs psb_gem_object_funcs;
+
 extern int psb_gem_create(struct drm_file *file, struct drm_device *dev,
  u64 size, u32 *handlep, int stolen, u32 align);
+
 #endif
diff --git a/drivers/gpu/drm/gma500/psb_drv.c b/drivers/gpu/drm/gma500/psb_drv.c
index 34b4aae9a15e..b13376a6fb91 100644
--- a/drivers/gpu/drm/gma500/psb_drv.c
+++ b/drivers/gpu/drm/gma500/psb_drv.c
@@ -480,12 +480,6 @@ static const struct dev_pm_ops psb_pm_ops = {
.runtime_idle = psb_runtime_idle,
 };
 
-static const struct vm_operations_struct psb_gem_vm_ops = {
-   .fault = psb_gem_fault,
-   .open = drm_gem_vm_open,
-   .close = drm_gem_vm_close,
-};
-
 static const struct file_operations psb_gem_fops = {
.owner = THIS_MODULE,
.open = drm_open,
@@ -507,9 +501,6 @@ static struct drm_driver driver = {
.irq_uninstall = psb_irq_uninstall,
.irq_handler = psb_irq_handler,
 
-   .gem_free_object_unlocked = psb_gem_free_object,
-   .gem_vm_ops = _gem_vm_ops,
-
.dumb_create = psb_gem_dumb_create,
.ioctls = psb_ioctls,
.fops = _gem_fops,
diff --git a/drivers/gpu/drm/gma500/psb_drv.h b/drivers/gpu/drm/gma500/psb_drv.h
index 956926341316..c71a5a4e912c 100644
--- a/drivers/gpu/drm/gma500/psb_drv.h
+++ b/drivers/gpu/drm/gma500/psb_drv.h
@@ -735,12 +735,10 @@ extern const struct drm_connector_helper_funcs
 extern const struct drm_connector_funcs psb_intel_lvds_connector_funcs;
 
 /* gem.c */
-extern void psb_gem_free_object(struct drm_gem_object *obj);
 extern int psb_gem_get_aperture(struct drm_device *dev, void *data,

[PATCH v2 17/21] drm/virtgpu: Set PRIME export function in struct drm_gem_object_funcs

2020-09-15 Thread Thomas Zimmermann
GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces virtgpu's per-driver PRIME export
function with a per-object function.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/virtio/virtgpu_drv.c| 1 -
 drivers/gpu/drm/virtio/virtgpu_object.c | 1 +
 2 files changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.c 
b/drivers/gpu/drm/virtio/virtgpu_drv.c
index b039f493bda9..1f8d6ed11d21 100644
--- a/drivers/gpu/drm/virtio/virtgpu_drv.c
+++ b/drivers/gpu/drm/virtio/virtgpu_drv.c
@@ -203,7 +203,6 @@ static struct drm_driver driver = {
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
.gem_prime_mmap = drm_gem_prime_mmap,
-   .gem_prime_export = virtgpu_gem_prime_export,
.gem_prime_import = virtgpu_gem_prime_import,
.gem_prime_import_sg_table = virtgpu_gem_prime_import_sg_table,
 
diff --git a/drivers/gpu/drm/virtio/virtgpu_object.c 
b/drivers/gpu/drm/virtio/virtgpu_object.c
index 842f8b61aa89..4f7d7ea8194c 100644
--- a/drivers/gpu/drm/virtio/virtgpu_object.c
+++ b/drivers/gpu/drm/virtio/virtgpu_object.c
@@ -108,6 +108,7 @@ static const struct drm_gem_object_funcs 
virtio_gpu_shmem_funcs = {
.close = virtio_gpu_gem_object_close,
 
.print_info = drm_gem_shmem_print_info,
+   .export = virtgpu_gem_prime_export,
.pin = drm_gem_shmem_pin,
.unpin = drm_gem_shmem_unpin,
.get_sg_table = drm_gem_shmem_get_sg_table,
-- 
2.28.0

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


[PATCH v2 21/21] drm: Remove obsolete GEM and PRIME callbacks from struct drm_driver

2020-09-15 Thread Thomas Zimmermann
Several GEM and PRIME callbacks have been deprecated in favor of
per-instance GEM object functions. Remove the callbacks as they are
now unused. The only exception is .gem_prime_mmap, which is still
in use by several drivers.

What is also gone is gem_vm_ops in struct drm_driver. All drivers now
use struct drm_gem_object_funcs.vm_ops instead.

While at it, the patch also improves error handling around calls
to .free and .get_sg_table callbacks.

v2:
* update related TODO item (Sam)

Signed-off-by: Thomas Zimmermann 
---
 Documentation/gpu/todo.rst   |  7 +--
 drivers/gpu/drm/drm_gem.c| 35 +++-
 drivers/gpu/drm/drm_gem_cma_helper.c |  6 +-
 drivers/gpu/drm/drm_prime.c  | 17 +++---
 include/drm/drm_drv.h| 85 ++--
 5 files changed, 25 insertions(+), 125 deletions(-)

diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
index b0ea17da8ff6..0fc6bc222392 100644
--- a/Documentation/gpu/todo.rst
+++ b/Documentation/gpu/todo.rst
@@ -289,11 +289,8 @@ struct drm_gem_object_funcs
 ---
 
 GEM objects can now have a function table instead of having the callbacks on 
the
-DRM driver struct. This is now the preferred way and drivers can be moved over.
-
-We also need a 2nd version of the CMA define that doesn't require the
-vmapping to be present (different hook for prime importing). Plus this needs to
-be rolled out to all drivers using their own implementations, too.
+DRM driver struct. This is now the preferred way. Callbacks in drivers have 
been
+converted, except for struct drm_driver.gem_prime_mmap.
 
 Level: Intermediate
 
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 19d73868490e..96945bed8291 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -247,12 +247,9 @@ drm_gem_object_release_handle(int id, void *ptr, void 
*data)
 {
struct drm_file *file_priv = data;
struct drm_gem_object *obj = ptr;
-   struct drm_device *dev = obj->dev;
 
if (obj->funcs && obj->funcs->close)
obj->funcs->close(obj, file_priv);
-   else if (dev->driver->gem_close_object)
-   dev->driver->gem_close_object(obj, file_priv);
 
drm_gem_remove_prime_handles(obj, file_priv);
drm_vma_node_revoke(>vma_node, file_priv);
@@ -407,10 +404,6 @@ drm_gem_handle_create_tail(struct drm_file *file_priv,
ret = obj->funcs->open(obj, file_priv);
if (ret)
goto err_revoke;
-   } else if (dev->driver->gem_open_object) {
-   ret = dev->driver->gem_open_object(obj, file_priv);
-   if (ret)
-   goto err_revoke;
}
 
*handlep = handle;
@@ -982,12 +975,11 @@ drm_gem_object_free(struct kref *kref)
 {
struct drm_gem_object *obj =
container_of(kref, struct drm_gem_object, refcount);
-   struct drm_device *dev = obj->dev;
 
-   if (obj->funcs)
-   obj->funcs->free(obj);
-   else if (dev->driver->gem_free_object_unlocked)
-   dev->driver->gem_free_object_unlocked(obj);
+   if (drm_WARN_ON_ONCE(obj->dev, !obj->funcs || !obj->funcs->free))
+   return;
+
+   obj->funcs->free(obj);
 }
 EXPORT_SYMBOL(drm_gem_object_free);
 
@@ -1049,9 +1041,9 @@ EXPORT_SYMBOL(drm_gem_vm_close);
  * @obj_size: the object size to be mapped, in bytes
  * @vma: VMA for the area to be mapped
  *
- * Set up the VMA to prepare mapping of the GEM object using the gem_vm_ops
- * provided by the driver. Depending on their requirements, drivers can either
- * provide a fault handler in their gem_vm_ops (in which case any accesses to
+ * Set up the VMA to prepare mapping of the GEM object using the GEM object's
+ * vm_ops. Depending on their requirements, GEM objects can either
+ * provide a fault handler in their vm_ops (in which case any accesses to
  * the object will be trapped, to perform migration, GTT binding, surface
  * register allocation, or performance monitoring), or mmap the buffer memory
  * synchronously after calling drm_gem_mmap_obj.
@@ -1065,12 +1057,11 @@ EXPORT_SYMBOL(drm_gem_vm_close);
  * callers must verify access restrictions before calling this helper.
  *
  * Return 0 or success or -EINVAL if the object size is smaller than the VMA
- * size, or if no gem_vm_ops are provided.
+ * size, or if no vm_ops are provided.
  */
 int drm_gem_mmap_obj(struct drm_gem_object *obj, unsigned long obj_size,
 struct vm_area_struct *vma)
 {
-   struct drm_device *dev = obj->dev;
int ret;
 
/* Check for valid size. */
@@ -1095,8 +1086,6 @@ int drm_gem_mmap_obj(struct drm_gem_object *obj, unsigned 
long obj_size,
} else {
if (obj->funcs && obj->funcs->vm_ops)
vma->vm_ops = obj->funcs->vm_ops;
-   else if (dev->driver->gem_vm_ops)
-   

[PATCH v2 09/21] drm/nouveau: Introduce GEM object functions

2020-09-15 Thread Thomas Zimmermann
GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces the per-driver callbacks with
per-instance callbacks in nouveau.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/nouveau/nouveau_drm.c   |  9 -
 drivers/gpu/drm/nouveau/nouveau_gem.c   | 13 +
 drivers/gpu/drm/nouveau/nouveau_gem.h   |  2 ++
 drivers/gpu/drm/nouveau/nouveau_prime.c |  2 ++
 4 files changed, 17 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c 
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index 42fc5c813a9b..72640bca1617 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -1207,16 +1207,7 @@ driver_stub = {
 
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
-   .gem_prime_pin = nouveau_gem_prime_pin,
-   .gem_prime_unpin = nouveau_gem_prime_unpin,
-   .gem_prime_get_sg_table = nouveau_gem_prime_get_sg_table,
.gem_prime_import_sg_table = nouveau_gem_prime_import_sg_table,
-   .gem_prime_vmap = nouveau_gem_prime_vmap,
-   .gem_prime_vunmap = nouveau_gem_prime_vunmap,
-
-   .gem_free_object_unlocked = nouveau_gem_object_del,
-   .gem_open_object = nouveau_gem_object_open,
-   .gem_close_object = nouveau_gem_object_close,
 
.dumb_create = nouveau_display_dumb_create,
.dumb_map_offset = nouveau_display_dumb_map_offset,
diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c 
b/drivers/gpu/drm/nouveau/nouveau_gem.c
index 89adadf4706b..28e0cbb00876 100644
--- a/drivers/gpu/drm/nouveau/nouveau_gem.c
+++ b/drivers/gpu/drm/nouveau/nouveau_gem.c
@@ -169,6 +169,17 @@ nouveau_gem_object_close(struct drm_gem_object *gem, 
struct drm_file *file_priv)
ttm_bo_unreserve(>bo);
 }
 
+const struct drm_gem_object_funcs nouveau_gem_object_funcs = {
+   .free = nouveau_gem_object_del,
+   .open = nouveau_gem_object_open,
+   .close = nouveau_gem_object_close,
+   .pin = nouveau_gem_prime_pin,
+   .unpin = nouveau_gem_prime_unpin,
+   .get_sg_table = nouveau_gem_prime_get_sg_table,
+   .vmap = nouveau_gem_prime_vmap,
+   .vunmap = nouveau_gem_prime_vunmap,
+};
+
 int
 nouveau_gem_new(struct nouveau_cli *cli, u64 size, int align, uint32_t domain,
uint32_t tile_mode, uint32_t tile_flags,
@@ -186,6 +197,8 @@ nouveau_gem_new(struct nouveau_cli *cli, u64 size, int 
align, uint32_t domain,
if (IS_ERR(nvbo))
return PTR_ERR(nvbo);
 
+   nvbo->bo.base.funcs = _gem_object_funcs;
+
/* Initialize the embedded gem-object. We return a single gem-reference
 * to the caller, instead of a normal nouveau_bo ttm reference. */
ret = drm_gem_object_init(drm->dev, >bo.base, size);
diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.h 
b/drivers/gpu/drm/nouveau/nouveau_gem.h
index 978e07591990..b35c180322e2 100644
--- a/drivers/gpu/drm/nouveau/nouveau_gem.h
+++ b/drivers/gpu/drm/nouveau/nouveau_gem.h
@@ -5,6 +5,8 @@
 #include "nouveau_drv.h"
 #include "nouveau_bo.h"
 
+extern const struct drm_gem_object_funcs nouveau_gem_object_funcs;
+
 static inline struct nouveau_bo *
 nouveau_gem_object(struct drm_gem_object *gem)
 {
diff --git a/drivers/gpu/drm/nouveau/nouveau_prime.c 
b/drivers/gpu/drm/nouveau/nouveau_prime.c
index b2ecb91f8ddc..a8264aebf3d4 100644
--- a/drivers/gpu/drm/nouveau/nouveau_prime.c
+++ b/drivers/gpu/drm/nouveau/nouveau_prime.c
@@ -77,6 +77,8 @@ struct drm_gem_object 
*nouveau_gem_prime_import_sg_table(struct drm_device *dev,
 
nvbo->valid_domains = NOUVEAU_GEM_DOMAIN_GART;
 
+   nvbo->bo.base.funcs = _gem_object_funcs;
+
/* Initialize the embedded gem-object. We return a single gem-reference
 * to the caller, instead of a normal nouveau_bo ttm reference. */
ret = drm_gem_object_init(dev, >bo.base, size);
-- 
2.28.0

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


[PATCH v2 10/21] drm/omapdrm: Introduce GEM object functions

2020-09-15 Thread Thomas Zimmermann
GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces the per-driver callbacks with
per-instance callbacks in omapdrm.

v2:
* make omap_gem_free_object() static (Tomi)

Signed-off-by: Thomas Zimmermann 
Reviewed-by: Laurent Pinchart 
Reviewed-by: Tomi Valkeinen 
---
 drivers/gpu/drm/omapdrm/omap_drv.c |  9 -
 drivers/gpu/drm/omapdrm/omap_gem.c | 18 --
 drivers/gpu/drm/omapdrm/omap_gem.h |  2 --
 3 files changed, 16 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c 
b/drivers/gpu/drm/omapdrm/omap_drv.c
index 53d5e184ee77..2e598b8b72af 100644
--- a/drivers/gpu/drm/omapdrm/omap_drv.c
+++ b/drivers/gpu/drm/omapdrm/omap_drv.c
@@ -521,12 +521,6 @@ static int dev_open(struct drm_device *dev, struct 
drm_file *file)
return 0;
 }
 
-static const struct vm_operations_struct omap_gem_vm_ops = {
-   .fault = omap_gem_fault,
-   .open = drm_gem_vm_open,
-   .close = drm_gem_vm_close,
-};
-
 static const struct file_operations omapdriver_fops = {
.owner = THIS_MODULE,
.open = drm_open,
@@ -549,10 +543,7 @@ static struct drm_driver omap_drm_driver = {
 #endif
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
-   .gem_prime_export = omap_gem_prime_export,
.gem_prime_import = omap_gem_prime_import,
-   .gem_free_object_unlocked = omap_gem_free_object,
-   .gem_vm_ops = _gem_vm_ops,
.dumb_create = omap_gem_dumb_create,
.dumb_map_offset = omap_gem_dumb_map_offset,
.ioctls = ioctls,
diff --git a/drivers/gpu/drm/omapdrm/omap_gem.c 
b/drivers/gpu/drm/omapdrm/omap_gem.c
index d0d12d5dd76c..979d53a93c2b 100644
--- a/drivers/gpu/drm/omapdrm/omap_gem.c
+++ b/drivers/gpu/drm/omapdrm/omap_gem.c
@@ -487,7 +487,7 @@ static vm_fault_t omap_gem_fault_2d(struct drm_gem_object 
*obj,
  * vma->vm_private_data points to the GEM object that is backing this
  * mapping.
  */
-vm_fault_t omap_gem_fault(struct vm_fault *vmf)
+static vm_fault_t omap_gem_fault(struct vm_fault *vmf)
 {
struct vm_area_struct *vma = vmf->vma;
struct drm_gem_object *obj = vma->vm_private_data;
@@ -1089,7 +1089,7 @@ void omap_gem_describe_objects(struct list_head *list, 
struct seq_file *m)
  * Constructor & Destructor
  */
 
-void omap_gem_free_object(struct drm_gem_object *obj)
+static void omap_gem_free_object(struct drm_gem_object *obj)
 {
struct drm_device *dev = obj->dev;
struct omap_drm_private *priv = dev->dev_private;
@@ -1169,6 +1169,18 @@ static bool omap_gem_validate_flags(struct drm_device 
*dev, u32 flags)
return true;
 }
 
+static const struct vm_operations_struct omap_gem_vm_ops = {
+   .fault = omap_gem_fault,
+   .open = drm_gem_vm_open,
+   .close = drm_gem_vm_close,
+};
+
+static const struct drm_gem_object_funcs omap_gem_object_funcs = {
+   .free = omap_gem_free_object,
+   .export = omap_gem_prime_export,
+   .vm_ops = _gem_vm_ops,
+};
+
 /* GEM buffer object constructor */
 struct drm_gem_object *omap_gem_new(struct drm_device *dev,
union omap_gem_size gsize, u32 flags)
@@ -1236,6 +1248,8 @@ struct drm_gem_object *omap_gem_new(struct drm_device 
*dev,
size = PAGE_ALIGN(gsize.bytes);
}
 
+   obj->funcs = _gem_object_funcs;
+
/* Initialize the GEM object. */
if (!(flags & OMAP_BO_MEM_SHMEM)) {
drm_gem_private_object_init(dev, obj, size);
diff --git a/drivers/gpu/drm/omapdrm/omap_gem.h 
b/drivers/gpu/drm/omapdrm/omap_gem.h
index 729b7812a815..eda9b4839c30 100644
--- a/drivers/gpu/drm/omapdrm/omap_gem.h
+++ b/drivers/gpu/drm/omapdrm/omap_gem.h
@@ -48,7 +48,6 @@ struct drm_gem_object *omap_gem_new_dmabuf(struct drm_device 
*dev, size_t size,
struct sg_table *sgt);
 int omap_gem_new_handle(struct drm_device *dev, struct drm_file *file,
union omap_gem_size gsize, u32 flags, u32 *handle);
-void omap_gem_free_object(struct drm_gem_object *obj);
 void *omap_gem_vaddr(struct drm_gem_object *obj);
 
 /* Dumb Buffers Interface */
@@ -69,7 +68,6 @@ struct dma_buf *omap_gem_prime_export(struct drm_gem_object 
*obj, int flags);
 struct drm_gem_object *omap_gem_prime_import(struct drm_device *dev,
struct dma_buf *buffer);
 
-vm_fault_t omap_gem_fault(struct vm_fault *vmf);
 int omap_gem_roll(struct drm_gem_object *obj, u32 roll);
 void omap_gem_cpu_sync_page(struct drm_gem_object *obj, int pgoff);
 void omap_gem_dma_sync_buffer(struct drm_gem_object *obj,
-- 
2.28.0

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


[PATCH v2 12/21] drm/radeon: Introduce GEM object functions

2020-09-15 Thread Thomas Zimmermann
GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces the per-driver callbacks with
per-instance callbacks in radeon.

v2:
* move object-function instance to radeon_gem.c (Christian)
* set callbacks in radeon_gem_object_create() (Christian)

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/radeon/radeon_drv.c | 23 +
 drivers/gpu/drm/radeon/radeon_gem.c | 31 +
 2 files changed, 28 insertions(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_drv.c 
b/drivers/gpu/drm/radeon/radeon_drv.c
index 4cd30613fa1d..65061c949aee 100644
--- a/drivers/gpu/drm/radeon/radeon_drv.c
+++ b/drivers/gpu/drm/radeon/radeon_drv.c
@@ -124,13 +124,6 @@ void radeon_driver_irq_preinstall_kms(struct drm_device 
*dev);
 int radeon_driver_irq_postinstall_kms(struct drm_device *dev);
 void radeon_driver_irq_uninstall_kms(struct drm_device *dev);
 irqreturn_t radeon_driver_irq_handler_kms(int irq, void *arg);
-void radeon_gem_object_free(struct drm_gem_object *obj);
-int radeon_gem_object_open(struct drm_gem_object *obj,
-   struct drm_file *file_priv);
-void radeon_gem_object_close(struct drm_gem_object *obj,
-   struct drm_file *file_priv);
-struct dma_buf *radeon_gem_prime_export(struct drm_gem_object *gobj,
-   int flags);
 extern int radeon_get_crtc_scanoutpos(struct drm_device *dev, unsigned int 
crtc,
  unsigned int flags, int *vpos, int *hpos,
  ktime_t *stime, ktime_t *etime,
@@ -145,14 +138,9 @@ int radeon_mode_dumb_mmap(struct drm_file *filp,
 int radeon_mode_dumb_create(struct drm_file *file_priv,
struct drm_device *dev,
struct drm_mode_create_dumb *args);
-struct sg_table *radeon_gem_prime_get_sg_table(struct drm_gem_object *obj);
 struct drm_gem_object *radeon_gem_prime_import_sg_table(struct drm_device *dev,
struct 
dma_buf_attachment *,
struct sg_table *sg);
-int radeon_gem_prime_pin(struct drm_gem_object *obj);
-void radeon_gem_prime_unpin(struct drm_gem_object *obj);
-void *radeon_gem_prime_vmap(struct drm_gem_object *obj);
-void radeon_gem_prime_vunmap(struct drm_gem_object *obj, void *vaddr);
 
 /* atpx handler */
 #if defined(CONFIG_VGA_SWITCHEROO)
@@ -550,7 +538,7 @@ long radeon_drm_ioctl(struct file *filp,
}
 
ret = drm_ioctl(filp, cmd, arg);
-   
+
pm_runtime_mark_last_busy(dev->dev);
pm_runtime_put_autosuspend(dev->dev);
return ret;
@@ -609,22 +597,13 @@ static struct drm_driver kms_driver = {
.irq_uninstall = radeon_driver_irq_uninstall_kms,
.irq_handler = radeon_driver_irq_handler_kms,
.ioctls = radeon_ioctls_kms,
-   .gem_free_object_unlocked = radeon_gem_object_free,
-   .gem_open_object = radeon_gem_object_open,
-   .gem_close_object = radeon_gem_object_close,
.dumb_create = radeon_mode_dumb_create,
.dumb_map_offset = radeon_mode_dumb_mmap,
.fops = _driver_kms_fops,
 
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
-   .gem_prime_export = radeon_gem_prime_export,
-   .gem_prime_pin = radeon_gem_prime_pin,
-   .gem_prime_unpin = radeon_gem_prime_unpin,
-   .gem_prime_get_sg_table = radeon_gem_prime_get_sg_table,
.gem_prime_import_sg_table = radeon_gem_prime_import_sg_table,
-   .gem_prime_vmap = radeon_gem_prime_vmap,
-   .gem_prime_vunmap = radeon_gem_prime_vunmap,
 
.name = DRIVER_NAME,
.desc = DRIVER_DESC,
diff --git a/drivers/gpu/drm/radeon/radeon_gem.c 
b/drivers/gpu/drm/radeon/radeon_gem.c
index e5c4271e64ed..0ccd7213e41f 100644
--- a/drivers/gpu/drm/radeon/radeon_gem.c
+++ b/drivers/gpu/drm/radeon/radeon_gem.c
@@ -35,7 +35,17 @@
 
 #include "radeon.h"
 
-void radeon_gem_object_free(struct drm_gem_object *gobj)
+struct dma_buf *radeon_gem_prime_export(struct drm_gem_object *gobj,
+   int flags);
+struct sg_table *radeon_gem_prime_get_sg_table(struct drm_gem_object *obj);
+int radeon_gem_prime_pin(struct drm_gem_object *obj);
+void radeon_gem_prime_unpin(struct drm_gem_object *obj);
+void *radeon_gem_prime_vmap(struct drm_gem_object *obj);
+void radeon_gem_prime_vunmap(struct drm_gem_object *obj, void *vaddr);
+
+static const struct drm_gem_object_funcs radeon_gem_object_funcs;
+
+static void radeon_gem_object_free(struct drm_gem_object *gobj)
 {
struct radeon_bo *robj = gem_to_radeon_bo(gobj);
 
@@ -85,6 +95,7 @@ int radeon_gem_object_create(struct radeon_device *rdev, 
unsigned long size,
return r;
}
*obj = >tbo.base;
+   (*obj)->funcs = 

[PATCH v2 06/21] drm/i915: Introduce GEM object functions

2020-09-15 Thread Thomas Zimmermann
GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces the per-driver callbacks with
per-instance callbacks in i915.

v2:
* move object-function instance to i915_gem_object.c (Jani)

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/i915/gem/i915_gem_object.c| 21 ---
 drivers/gpu/drm/i915/gem/i915_gem_object.h|  3 ---
 drivers/gpu/drm/i915/i915_drv.c   |  4 
 .../gpu/drm/i915/selftests/mock_gem_device.c  |  3 ---
 4 files changed, 18 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c 
b/drivers/gpu/drm/i915/gem/i915_gem_object.c
index c8421fd9d2dc..3389ac972d16 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -39,9 +39,18 @@ static struct i915_global_object {
struct kmem_cache *slab_objects;
 } global;
 
+static const struct drm_gem_object_funcs i915_gem_object_funcs;
+
 struct drm_i915_gem_object *i915_gem_object_alloc(void)
 {
-   return kmem_cache_zalloc(global.slab_objects, GFP_KERNEL);
+   struct drm_i915_gem_object *obj;
+
+   obj = kmem_cache_zalloc(global.slab_objects, GFP_KERNEL);
+   if (!obj)
+   return NULL;
+   obj->base.funcs = _gem_object_funcs;
+
+   return obj;
 }
 
 void i915_gem_object_free(struct drm_i915_gem_object *obj)
@@ -101,7 +110,7 @@ void i915_gem_object_set_cache_coherency(struct 
drm_i915_gem_object *obj,
!(obj->cache_coherent & I915_BO_CACHE_COHERENT_FOR_WRITE);
 }
 
-void i915_gem_close_object(struct drm_gem_object *gem, struct drm_file *file)
+static void i915_gem_close_object(struct drm_gem_object *gem, struct drm_file 
*file)
 {
struct drm_i915_gem_object *obj = to_intel_bo(gem);
struct drm_i915_file_private *fpriv = file->driver_priv;
@@ -264,7 +273,7 @@ static void __i915_gem_free_work(struct work_struct *work)
i915_gem_flush_free_objects(i915);
 }
 
-void i915_gem_free_object(struct drm_gem_object *gem_obj)
+static void i915_gem_free_object(struct drm_gem_object *gem_obj)
 {
struct drm_i915_gem_object *obj = to_intel_bo(gem_obj);
struct drm_i915_private *i915 = to_i915(obj->base.dev);
@@ -403,6 +412,12 @@ int __init i915_global_objects_init(void)
return 0;
 }
 
+static const struct drm_gem_object_funcs i915_gem_object_funcs = {
+   .free = i915_gem_free_object,
+   .close = i915_gem_close_object,
+   .export = i915_gem_prime_export,
+};
+
 #if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
 #include "selftests/huge_gem_object.c"
 #include "selftests/huge_pages.c"
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h 
b/drivers/gpu/drm/i915/gem/i915_gem_object.h
index d46db8d8f38e..eaf3d4147be0 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
@@ -38,9 +38,6 @@ void __i915_gem_object_release_shmem(struct 
drm_i915_gem_object *obj,
 
 int i915_gem_object_attach_phys(struct drm_i915_gem_object *obj, int align);
 
-void i915_gem_close_object(struct drm_gem_object *gem, struct drm_file *file);
-void i915_gem_free_object(struct drm_gem_object *obj);
-
 void i915_gem_flush_free_objects(struct drm_i915_private *i915);
 
 struct sg_table *
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 94e00e450683..011a3fb41ece 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1750,12 +1750,8 @@ static struct drm_driver driver = {
.lastclose = i915_driver_lastclose,
.postclose = i915_driver_postclose,
 
-   .gem_close_object = i915_gem_close_object,
-   .gem_free_object_unlocked = i915_gem_free_object,
-
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
-   .gem_prime_export = i915_gem_prime_export,
.gem_prime_import = i915_gem_prime_import,
 
.dumb_create = i915_gem_dumb_create,
diff --git a/drivers/gpu/drm/i915/selftests/mock_gem_device.c 
b/drivers/gpu/drm/i915/selftests/mock_gem_device.c
index f127e633f7ca..9244b5d6fb01 100644
--- a/drivers/gpu/drm/i915/selftests/mock_gem_device.c
+++ b/drivers/gpu/drm/i915/selftests/mock_gem_device.c
@@ -87,9 +87,6 @@ static struct drm_driver mock_driver = {
.name = "mock",
.driver_features = DRIVER_GEM,
.release = mock_device_release,
-
-   .gem_close_object = i915_gem_close_object,
-   .gem_free_object_unlocked = i915_gem_free_object,
 };
 
 static void release_dev(struct device *dev)
-- 
2.28.0

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


[PATCH v2 04/21] drm/exynos: Introduce GEM object functions

2020-09-15 Thread Thomas Zimmermann
GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces the per-driver callbacks with
per-instance callbacks in exynos. The only exception is gem_prime_mmap,
which is non-trivial to convert.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/exynos/exynos_drm_drv.c | 10 --
 drivers/gpu/drm/exynos/exynos_drm_gem.c | 15 +++
 2 files changed, 15 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index dbd80f1e4c78..fe46680ca208 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -75,11 +75,6 @@ static void exynos_drm_postclose(struct drm_device *dev, 
struct drm_file *file)
file->driver_priv = NULL;
 }
 
-static const struct vm_operations_struct exynos_drm_gem_vm_ops = {
-   .open = drm_gem_vm_open,
-   .close = drm_gem_vm_close,
-};
-
 static const struct drm_ioctl_desc exynos_ioctls[] = {
DRM_IOCTL_DEF_DRV(EXYNOS_GEM_CREATE, exynos_drm_gem_create_ioctl,
DRM_RENDER_ALLOW),
@@ -124,16 +119,11 @@ static struct drm_driver exynos_drm_driver = {
.open   = exynos_drm_open,
.lastclose  = drm_fb_helper_lastclose,
.postclose  = exynos_drm_postclose,
-   .gem_free_object_unlocked = exynos_drm_gem_free_object,
-   .gem_vm_ops = _drm_gem_vm_ops,
.dumb_create= exynos_drm_gem_dumb_create,
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
.gem_prime_import   = exynos_drm_gem_prime_import,
-   .gem_prime_get_sg_table = exynos_drm_gem_prime_get_sg_table,
.gem_prime_import_sg_table  = exynos_drm_gem_prime_import_sg_table,
-   .gem_prime_vmap = exynos_drm_gem_prime_vmap,
-   .gem_prime_vunmap   = exynos_drm_gem_prime_vunmap,
.gem_prime_mmap = exynos_drm_gem_prime_mmap,
.ioctls = exynos_ioctls,
.num_ioctls = ARRAY_SIZE(exynos_ioctls),
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c 
b/drivers/gpu/drm/exynos/exynos_drm_gem.c
index efa476858db5..69a5cf28b4ae 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
@@ -129,6 +129,19 @@ void exynos_drm_gem_destroy(struct exynos_drm_gem 
*exynos_gem)
kfree(exynos_gem);
 }
 
+static const struct vm_operations_struct exynos_drm_gem_vm_ops = {
+   .open = drm_gem_vm_open,
+   .close = drm_gem_vm_close,
+};
+
+static const struct drm_gem_object_funcs exynos_drm_gem_object_funcs = {
+   .free = exynos_drm_gem_free_object,
+   .get_sg_table = exynos_drm_gem_prime_get_sg_table,
+   .vmap = exynos_drm_gem_prime_vmap,
+   .vunmap = exynos_drm_gem_prime_vunmap,
+   .vm_ops = _drm_gem_vm_ops,
+};
+
 static struct exynos_drm_gem *exynos_drm_gem_init(struct drm_device *dev,
  unsigned long size)
 {
@@ -143,6 +156,8 @@ static struct exynos_drm_gem *exynos_drm_gem_init(struct 
drm_device *dev,
exynos_gem->size = size;
obj = _gem->base;
 
+   obj->funcs = _drm_gem_object_funcs;
+
ret = drm_gem_object_init(dev, obj, size);
if (ret < 0) {
DRM_DEV_ERROR(dev->dev, "failed to initialize gem object\n");
-- 
2.28.0

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


[PATCH v2 00/21] Convert all remaining drivers to GEM object functions

2020-09-15 Thread Thomas Zimmermann
The GEM and PRIME related callbacks in struct drm_driver are deprecated in
favor of GEM object functions in struct drm_gem_object_funcs. This patchset
converts the remaining drivers to object functions and removes most of the
obsolete interfaces.

Patches #1 to #16 and #18 to #19 convert DRM drivers to GEM object functions,
one by one. Each patch moves existing callbacks from struct drm_driver to an
instance of struct drm_gem_object_funcs, and sets these funcs when the GEM
object is initialized. The expection is .gem_prime_mmap. There are different
ways of how drivers implement the callback, and moving it to GEM object
functions requires a closer review for each.

Patch #17 fixes virtgpu to use GEM object functions where possible. The
driver recently introduced a function for one of the deprecated callbacks.

Patch #20 converts xlnx to CMA helper macros. There's no apparent reason
why the driver does the GEM setup on it's own. Using CMA helper macros
adds GEM object functions implicitly.

With most of the GEM and PRIME moved to GEM object functions, related code
in struct drm_driver and in the DRM core/helpers is being removed by patch
#21.

Further testing is welcome. I tested the drivers for which I have HW
available. These are gma500, i915, nouveau, radeon and vc4. The console,
Weston and Xorg apparently work with the patches applied.

v2:
* moved code in amdgpu and radeon
* made several functions static in various drivers
* updated TODO-list item
* fix virtgpu

Thomas Zimmermann (21):
  drm/amdgpu: Introduce GEM object functions
  drm/armada: Introduce GEM object functions
  drm/etnaviv: Introduce GEM object functions
  drm/exynos: Introduce GEM object functions
  drm/gma500: Introduce GEM object functions
  drm/i915: Introduce GEM object functions
  drm/mediatek: Introduce GEM object functions
  drm/msm: Introduce GEM object funcs
  drm/nouveau: Introduce GEM object functions
  drm/omapdrm: Introduce GEM object functions
  drm/pl111: Introduce GEM object functions
  drm/radeon: Introduce GEM object functions
  drm/rockchip: Convert to drm_gem_object_funcs
  drm/tegra: Introduce GEM object functions
  drm/vc4: Introduce GEM object functions
  drm/vgem: Introduce GEM object functions
  drm/virtgpu: Set PRIME export function in struct drm_gem_object_funcs
  drm/vkms: Introduce GEM object functions
  drm/xen: Introduce GEM object functions
  drm/xlnx: Initialize DRM driver instance with CMA helper macro
  drm: Remove obsolete GEM and PRIME callbacks from struct drm_driver

 Documentation/gpu/todo.rst|  7 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c   |  6 --
 drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c   | 23 +++--
 drivers/gpu/drm/amd/amdgpu/amdgpu_gem.h   |  5 --
 drivers/gpu/drm/amd/amdgpu/amdgpu_object.c|  1 +
 drivers/gpu/drm/armada/armada_drv.c   |  3 -
 drivers/gpu/drm/armada/armada_gem.c   | 12 ++-
 drivers/gpu/drm/armada/armada_gem.h   |  2 -
 drivers/gpu/drm/drm_gem.c | 35 ++--
 drivers/gpu/drm/drm_gem_cma_helper.c  |  6 +-
 drivers/gpu/drm/drm_prime.c   | 17 ++--
 drivers/gpu/drm/etnaviv/etnaviv_drv.c | 13 ---
 drivers/gpu/drm/etnaviv/etnaviv_drv.h |  1 -
 drivers/gpu/drm/etnaviv/etnaviv_gem.c | 19 -
 drivers/gpu/drm/exynos/exynos_drm_drv.c   | 10 ---
 drivers/gpu/drm/exynos/exynos_drm_gem.c   | 15 
 drivers/gpu/drm/gma500/framebuffer.c  |  2 +
 drivers/gpu/drm/gma500/gem.c  | 18 +++-
 drivers/gpu/drm/gma500/gem.h  |  3 +
 drivers/gpu/drm/gma500/psb_drv.c  |  9 --
 drivers/gpu/drm/gma500/psb_drv.h  |  2 -
 drivers/gpu/drm/i915/gem/i915_gem_object.c| 21 -
 drivers/gpu/drm/i915/gem/i915_gem_object.h|  3 -
 drivers/gpu/drm/i915/i915_drv.c   |  4 -
 .../gpu/drm/i915/selftests/mock_gem_device.c  |  3 -
 drivers/gpu/drm/mediatek/mtk_drm_drv.c|  5 --
 drivers/gpu/drm/mediatek/mtk_drm_gem.c| 11 +++
 drivers/gpu/drm/msm/msm_drv.c | 13 ---
 drivers/gpu/drm/msm/msm_drv.h |  1 -
 drivers/gpu/drm/msm/msm_gem.c | 19 -
 drivers/gpu/drm/nouveau/nouveau_drm.c |  9 --
 drivers/gpu/drm/nouveau/nouveau_gem.c | 13 +++
 drivers/gpu/drm/nouveau/nouveau_gem.h |  2 +
 drivers/gpu/drm/nouveau/nouveau_prime.c   |  2 +
 drivers/gpu/drm/omapdrm/omap_drv.c|  9 --
 drivers/gpu/drm/omapdrm/omap_gem.c| 18 +++-
 drivers/gpu/drm/omapdrm/omap_gem.h|  2 -
 drivers/gpu/drm/pl111/pl111_drv.c |  5 +-
 drivers/gpu/drm/radeon/radeon_drv.c   | 23 +
 drivers/gpu/drm/radeon/radeon_gem.c   | 31 ++-
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c   |  5 --
 drivers/gpu/drm/rockchip/rockchip_drm_gem.c   | 10 +++
 drivers/gpu/drm/tegra/drm.c   |  4 -
 drivers/gpu/drm/tegra/gem.c   |  8 ++
 

[PATCH v2 01/21] drm/amdgpu: Introduce GEM object functions

2020-09-15 Thread Thomas Zimmermann
GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces the per-driver callbacks with
per-instance callbacks in amdgpu. The only exception is gem_prime_mmap,
which is non-trivial to convert.

v2:
* move object-function instance to amdgpu_gem.c (Christian)
* set callbacks in amdgpu_gem_object_create() (Christian)

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c|  6 --
 drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c| 23 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_gem.h|  5 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_object.c |  1 +
 4 files changed, 19 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 6edde2b9e402..840ca8f9c1e1 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -1505,19 +1505,13 @@ static struct drm_driver kms_driver = {
.lastclose = amdgpu_driver_lastclose_kms,
.irq_handler = amdgpu_irq_handler,
.ioctls = amdgpu_ioctls_kms,
-   .gem_free_object_unlocked = amdgpu_gem_object_free,
-   .gem_open_object = amdgpu_gem_object_open,
-   .gem_close_object = amdgpu_gem_object_close,
.dumb_create = amdgpu_mode_dumb_create,
.dumb_map_offset = amdgpu_mode_dumb_mmap,
.fops = _driver_kms_fops,
 
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
-   .gem_prime_export = amdgpu_gem_prime_export,
.gem_prime_import = amdgpu_gem_prime_import,
-   .gem_prime_vmap = amdgpu_gem_prime_vmap,
-   .gem_prime_vunmap = amdgpu_gem_prime_vunmap,
.gem_prime_mmap = amdgpu_gem_prime_mmap,
 
.name = DRIVER_NAME,
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
index aa7f230c71bf..aeecd5dc3ce4 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
@@ -36,9 +36,12 @@
 
 #include "amdgpu.h"
 #include "amdgpu_display.h"
+#include "amdgpu_dma_buf.h"
 #include "amdgpu_xgmi.h"
 
-void amdgpu_gem_object_free(struct drm_gem_object *gobj)
+static const struct drm_gem_object_funcs amdgpu_gem_object_funcs;
+
+static void amdgpu_gem_object_free(struct drm_gem_object *gobj)
 {
struct amdgpu_bo *robj = gem_to_amdgpu_bo(gobj);
 
@@ -87,6 +90,7 @@ int amdgpu_gem_object_create(struct amdgpu_device *adev, 
unsigned long size,
return r;
}
*obj = >tbo.base;
+   (*obj)->funcs = _gem_object_funcs;
 
return 0;
 }
@@ -119,8 +123,8 @@ void amdgpu_gem_force_release(struct amdgpu_device *adev)
  * Call from drm_gem_handle_create which appear in both new and open ioctl
  * case.
  */
-int amdgpu_gem_object_open(struct drm_gem_object *obj,
-  struct drm_file *file_priv)
+static int amdgpu_gem_object_open(struct drm_gem_object *obj,
+ struct drm_file *file_priv)
 {
struct amdgpu_bo *abo = gem_to_amdgpu_bo(obj);
struct amdgpu_device *adev = amdgpu_ttm_adev(abo->tbo.bdev);
@@ -152,8 +156,8 @@ int amdgpu_gem_object_open(struct drm_gem_object *obj,
return 0;
 }
 
-void amdgpu_gem_object_close(struct drm_gem_object *obj,
-struct drm_file *file_priv)
+static void amdgpu_gem_object_close(struct drm_gem_object *obj,
+   struct drm_file *file_priv)
 {
struct amdgpu_bo *bo = gem_to_amdgpu_bo(obj);
struct amdgpu_device *adev = amdgpu_ttm_adev(bo->tbo.bdev);
@@ -211,6 +215,15 @@ void amdgpu_gem_object_close(struct drm_gem_object *obj,
ttm_eu_backoff_reservation(, );
 }
 
+static const struct drm_gem_object_funcs amdgpu_gem_object_funcs = {
+   .free = amdgpu_gem_object_free,
+   .open = amdgpu_gem_object_open,
+   .close = amdgpu_gem_object_close,
+   .export = amdgpu_gem_prime_export,
+   .vmap = amdgpu_gem_prime_vmap,
+   .vunmap = amdgpu_gem_prime_vunmap,
+};
+
 /*
  * GEM ioctls.
  */
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.h
index e0f025dd1b14..637bf51dbf06 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.h
@@ -33,11 +33,6 @@
 #define AMDGPU_GEM_DOMAIN_MAX  0x3
 #define gem_to_amdgpu_bo(gobj) container_of((gobj), struct amdgpu_bo, tbo.base)
 
-void amdgpu_gem_object_free(struct drm_gem_object *obj);
-int amdgpu_gem_object_open(struct drm_gem_object *obj,
-   struct drm_file *file_priv);
-void amdgpu_gem_object_close(struct drm_gem_object *obj,
-   struct drm_file *file_priv);
 unsigned long amdgpu_gem_timeout(uint64_t timeout_ns);
 
 /*
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index 

[PATCH v2 02/21] drm/armada: Introduce GEM object functions

2020-09-15 Thread Thomas Zimmermann
GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces the per-driver callbacks with
per-instance callbacks in armada.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/armada/armada_drv.c |  3 ---
 drivers/gpu/drm/armada/armada_gem.c | 12 +++-
 drivers/gpu/drm/armada/armada_gem.h |  2 --
 3 files changed, 11 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/armada/armada_drv.c 
b/drivers/gpu/drm/armada/armada_drv.c
index 980d3f1f8f16..22247cfce80b 100644
--- a/drivers/gpu/drm/armada/armada_drv.c
+++ b/drivers/gpu/drm/armada/armada_drv.c
@@ -37,13 +37,10 @@ DEFINE_DRM_GEM_FOPS(armada_drm_fops);
 
 static struct drm_driver armada_drm_driver = {
.lastclose  = drm_fb_helper_lastclose,
-   .gem_free_object_unlocked = armada_gem_free_object,
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
-   .gem_prime_export   = armada_gem_prime_export,
.gem_prime_import   = armada_gem_prime_import,
.dumb_create= armada_gem_dumb_create,
-   .gem_vm_ops = _gem_vm_ops,
.major  = 1,
.minor  = 0,
.name   = "armada-drm",
diff --git a/drivers/gpu/drm/armada/armada_gem.c 
b/drivers/gpu/drm/armada/armada_gem.c
index ecf8a55e93d9..c343fbefe47c 100644
--- a/drivers/gpu/drm/armada/armada_gem.c
+++ b/drivers/gpu/drm/armada/armada_gem.c
@@ -25,7 +25,7 @@ static vm_fault_t armada_gem_vm_fault(struct vm_fault *vmf)
return vmf_insert_pfn(vmf->vma, vmf->address, pfn);
 }
 
-const struct vm_operations_struct armada_gem_vm_ops = {
+static const struct vm_operations_struct armada_gem_vm_ops = {
.fault  = armada_gem_vm_fault,
.open   = drm_gem_vm_open,
.close  = drm_gem_vm_close,
@@ -184,6 +184,12 @@ armada_gem_map_object(struct drm_device *dev, struct 
armada_gem_object *dobj)
return dobj->addr;
 }
 
+static const struct drm_gem_object_funcs armada_gem_object_funcs = {
+   .free = armada_gem_free_object,
+   .export = armada_gem_prime_export,
+   .vm_ops = _gem_vm_ops,
+};
+
 struct armada_gem_object *
 armada_gem_alloc_private_object(struct drm_device *dev, size_t size)
 {
@@ -195,6 +201,8 @@ armada_gem_alloc_private_object(struct drm_device *dev, 
size_t size)
if (!obj)
return NULL;
 
+   obj->obj.funcs = _gem_object_funcs;
+
drm_gem_private_object_init(dev, >obj, size);
 
DRM_DEBUG_DRIVER("alloc private obj %p size %zu\n", obj, size);
@@ -214,6 +222,8 @@ static struct armada_gem_object 
*armada_gem_alloc_object(struct drm_device *dev,
if (!obj)
return NULL;
 
+   obj->obj.funcs = _gem_object_funcs;
+
if (drm_gem_object_init(dev, >obj, size)) {
kfree(obj);
return NULL;
diff --git a/drivers/gpu/drm/armada/armada_gem.h 
b/drivers/gpu/drm/armada/armada_gem.h
index de04cc2c8f0e..ffcc7e8dd351 100644
--- a/drivers/gpu/drm/armada/armada_gem.h
+++ b/drivers/gpu/drm/armada/armada_gem.h
@@ -21,8 +21,6 @@ struct armada_gem_object {
void*update_data;
 };
 
-extern const struct vm_operations_struct armada_gem_vm_ops;
-
 #define drm_to_armada_gem(o) container_of(o, struct armada_gem_object, obj)
 
 void armada_gem_free_object(struct drm_gem_object *);
-- 
2.28.0

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


Re: [PATCH v8 5/8] drm/i915: Add dedicated plane hook for async flip case

2020-09-15 Thread Ville Syrjälä
On Mon, Sep 14, 2020 at 11:26:30AM +0530, Karthik B S wrote:
> This hook is added to avoid writing other plane registers in case of
> async flips, so that we do not write the double buffered registers
> during async surface address update.
> 
> v7: -Plane ctl needs bits from skl_plane_ctl_crtc as well. (Ville)
> -Add a vfunc for skl_program_async_surface_address
>  and call it from intel_update_plane. (Ville)
> 
> v8: -Rebased.
> 
> Signed-off-by: Karthik B S 
> Signed-off-by: Vandita Kulkarni 
> ---
>  .../gpu/drm/i915/display/intel_atomic_plane.c |  7 ++
>  .../drm/i915/display/intel_display_types.h|  3 +++
>  drivers/gpu/drm/i915/display/intel_sprite.c   | 24 +++
>  3 files changed, 34 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c 
> b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> index 79032701873a..fdc633020255 100644
> --- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> +++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> @@ -408,6 +408,13 @@ void intel_update_plane(struct intel_plane *plane,
>   struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
>  
>   trace_intel_update_plane(>base, crtc);
> +
> + if (crtc_state->uapi.async_flip) {

Hmm. Now I'm starting to wonder how this is actually going to interact
with legacy cursor updates. The crtc_state we use there I think comes
from the previous update and so will have this flag set it if was an
async flip. Which means the cursor ioctl will oops.

We may want the igt to check this particular combination of ioctls
actually.

> + plane->program_async_surface_address(plane,
> +  crtc_state, plane_state);
> + return;
> + }
> +
>   plane->update_plane(plane, crtc_state, plane_state);
>  }
>  
> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
> b/drivers/gpu/drm/i915/display/intel_display_types.h
> index b2d0edacc58c..d2ae781e4d81 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -1190,6 +1190,9 @@ struct intel_plane {
>  struct intel_plane_state *plane_state);
>   int (*min_cdclk)(const struct intel_crtc_state *crtc_state,
>const struct intel_plane_state *plane_state);
> + void (*program_async_surface_address)(struct intel_plane *plane,
> +   const struct intel_crtc_state 
> *crtc_state,
> +   const struct intel_plane_state 
> *plane_state);
>  };
>  
>  struct intel_watermark_params {
> diff --git a/drivers/gpu/drm/i915/display/intel_sprite.c 
> b/drivers/gpu/drm/i915/display/intel_sprite.c
> index f0c89418d2e1..69407dfcebf6 100644
> --- a/drivers/gpu/drm/i915/display/intel_sprite.c
> +++ b/drivers/gpu/drm/i915/display/intel_sprite.c
> @@ -609,6 +609,29 @@ icl_program_input_csc(struct intel_plane *plane,
> PLANE_INPUT_CSC_POSTOFF(pipe, plane_id, 2), 0x0);
>  }
>  
> +static void
> +skl_program_async_surface_address(struct intel_plane *plane,
> +   const struct intel_crtc_state *crtc_state,
> +   const struct intel_plane_state *plane_state)
> +{
> + struct drm_i915_private *dev_priv = to_i915(plane->base.dev);
> + unsigned long irqflags;
> + enum plane_id plane_id = plane->id;
> + enum pipe pipe = plane->pipe;
> + u32 surf_addr = plane_state->color_plane[0].offset;
> + u32 plane_ctl = plane_state->ctl;
> +
> + plane_ctl |= skl_plane_ctl_crtc(crtc_state);
> +
> + spin_lock_irqsave(_priv->uncore.lock, irqflags);
> +
> + intel_de_write_fw(dev_priv, PLANE_CTL(pipe, plane_id), plane_ctl);
> + intel_de_write_fw(dev_priv, PLANE_SURF(pipe, plane_id),
> +   intel_plane_ggtt_offset(plane_state) + surf_addr);
> +
> + spin_unlock_irqrestore(_priv->uncore.lock, irqflags);
> +}
> +
>  static void
>  skl_program_plane(struct intel_plane *plane,
> const struct intel_crtc_state *crtc_state,
> @@ -3096,6 +3119,7 @@ skl_universal_plane_create(struct drm_i915_private 
> *dev_priv,
>   plane->get_hw_state = skl_plane_get_hw_state;
>   plane->check_plane = skl_plane_check;
>   plane->min_cdclk = skl_plane_min_cdclk;
> + plane->program_async_surface_address = 
> skl_program_async_surface_address;
>  
>   if (INTEL_GEN(dev_priv) >= 11)
>   formats = icl_get_plane_formats(dev_priv, pipe,
> -- 
> 2.22.0

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


[PATCH 0/3] Small improvements to ingenic-drm

2020-09-15 Thread Paul Cercueil
Hi,

Here are three improvements to the ingenic-drm driver.

Patch 1 adds 30-bit RGB support for the SoCs that support it. Not much
to see here.

Patch 2 is here to allow the pixel clock to be re-set when the SoC's
main PLL changes, which can happen at any time. We get a callback before
and after the PLL clock rate is changed, which allows the ingenic-drm
driver to synchronize the clock rate update with vblank. The
synchronization mechanism is implemented with a mutex. I am not sure it
is the best solution, there may be something better/simpler to do here,
but in practice it works just fine.

Patch 3 adds support for using a reserved memory area as storage space
for GEM buffers. On memory-constrained devices, it is hard to find
contiguous space even for a small 320x240 buffer, and sometimes dumb
buffer allocation from userspace fails with -ENOMEM. Using a reserved
memory area makes sure that there will always be space for our GEM
buffers (provided they fit in the memory area).

Cheers,
-Paul

Paul Cercueil (3):
  drm/ingenic: Add support for 30-bit modes
  drm/ingenic: Reset pixclock rate when parent clock rate changes
  drm/ingenic: Add support for reserved memory

 drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 109 +++---
 drivers/gpu/drm/ingenic/ingenic-drm.h |   1 +
 2 files changed, 99 insertions(+), 11 deletions(-)

-- 
2.28.0

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


Re: [PATCH v3 0/1] drm/bridge: ps8640: Make sure all needed is powered to get the EDID

2020-09-15 Thread Enric Balletbo i Serra
Hi Sam,

On 27/8/20 10:59, Enric Balletbo i Serra wrote:
> The first 4 patches of the series version 2:
>   - drm/bridge_connector: Set default status connected for eDP connectors
>   - drm/bridge: ps8640: Get the EDID from eDP control
>   - drm/bridge: ps8640: Return an error for incorrect attach flags
>   - drm/bridge: ps8640: Print an error if VDO control fails
> 
> Are already applied to drm-misc-next, so I removed from this series. The
> pending patch is part of the original series and is a rework of the power
> handling to get the EDID. Basically, we need to make sure all the
> needed is powered to be able to get the EDID. Before, we saw that getting
> the EDID failed as explained in the third patch.
> 
> [1] https://lkml.org/lkml/2020/6/15/1208
> 
> Changes in v3:
> - Make poweron/poweroff and pre_enable/post_disable reverse one to each other 
> (Sam Ravnborg)
> 
> Changes in v2:
> - Use drm_bridge_chain_pre_enable/post_disable() helpers (Sam Ravnborg)
> 
> Enric Balletbo i Serra (1):
>   drm/bridge: ps8640: Rework power state handling
> 
>  drivers/gpu/drm/bridge/parade-ps8640.c | 68 ++
>  1 file changed, 58 insertions(+), 10 deletions(-)
> 

A gentle ping on this patch. Would be nice land this together with the already
accepted patches.

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


Haswell Regression in 5.9-rcX and lower 5.7.x, 5.8.x #2024 - Revert 47f8253d2b89 ("drm/i915/gen7: Clear all EU/L3 residual contexts") ?

2020-09-15 Thread Dirk Neukirchen
Hi David, Chris and lists

I am inquiring about the current status of #2024 [1]

Problem: Kernels 5.7.x , 5.8.x, current 5.9-rcs and drm-tip have a large 
regression on (some?) Haswell (HSW)

This is verified by _multiple people_ using different methods.
All his is documented in [1]  , Kernel 5.6.19 was fine
Result: no output, no usable desktop due to gpu crashes

Hardware : 2x Acer C720 Chromebooks and potentially others

Methods:
- running mpv with vaapi enabled
- glxgears
- automatic desktop environment start (probably with acceleration)

There is atm no fix in drm-tip integrated (5.9.0_rc5bisect_g30b3e38bd6d5 for 
example still errors)
 and no activity from Intel in the bug report beside the "working" suggested 
patches / hacks there

There should be enough bisection info an there.
Nobody asked there to get more info or different bisects/trees.

So - the ticket is still open.

Because Fedora uses newish Kernels I would like to use it "normally" without
going for 5.4 LTS or waiting an unknown amount of time - as 5.9.x currently 
seems to have the
same regression.

Affected Hardware at my end:
- C720 with a Intel Celeron 2955U
- UEFI Bios instead of original Bios (mrchromebox.tech) if thats relevant for 
hardware init related bugs;
But the Kernel should take care of the correct initialization anyway

Feel free to comment which trees, branches, tags or patches we should try to 
help
and what _more_ to report for "Report-By" , "Tested-By", "Verified-By"
tagging so that [1] can be closed.

Greetings, Dirk

[1]https://gitlab.freedesktop.org/drm/intel/-/issues/2024

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


[PATCH 3/3] drm/ingenic: Add support for reserved memory

2020-09-15 Thread Paul Cercueil
Add support for static memory reserved from Device Tree. Since we're
using GEM buffers backed by CMA, it is interesting to have an option to
specify the CMA area where the GEM buffers will be allocated.

Signed-off-by: Paul Cercueil 
---
 drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c 
b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
index aa32660033d2..44b0d029095e 100644
--- a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
+++ b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -827,6 +828,11 @@ static void ingenic_drm_unbind_all(void *d)
component_unbind_all(priv->dev, >drm);
 }
 
+static void __maybe_unused ingenic_drm_release_rmem(void *d)
+{
+   of_reserved_mem_device_release(d);
+}
+
 static int ingenic_drm_bind(struct device *dev, bool has_components)
 {
struct platform_device *pdev = to_platform_device(dev);
@@ -848,6 +854,19 @@ static int ingenic_drm_bind(struct device *dev, bool 
has_components)
return -EINVAL;
}
 
+   if (IS_ENABLED(CONFIG_OF_RESERVED_MEM)) {
+   ret = of_reserved_mem_device_init(dev);
+
+   if (ret && ret != -ENODEV)
+   return dev_err_probe(dev, ret, "Failed to get reserved 
memory\n");
+
+   if (ret != -ENODEV) {
+   ret = devm_add_action_or_reset(dev, 
ingenic_drm_release_rmem, dev);
+   if (ret)
+   return ret;
+   }
+   }
+
priv = devm_drm_dev_alloc(dev, _drm_driver_data,
  struct ingenic_drm, drm);
if (IS_ERR(priv))
-- 
2.28.0

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


[PATCH 1/3] drm/ingenic: Add support for 30-bit modes

2020-09-15 Thread Paul Cercueil
Starting from the JZ4760 SoC, the primary and overlay planes support
30-bit pixel modes (10 bits per color component). Add support for these
in the ingenic-drm driver.

Signed-off-by: Paul Cercueil 
---
 drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 41 +--
 drivers/gpu/drm/ingenic/ingenic-drm.h |  1 +
 2 files changed, 32 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c 
b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
index 937d080f5d06..fb62869befdc 100644
--- a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
+++ b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
@@ -49,6 +49,8 @@ struct jz_soc_info {
bool needs_dev_clk;
bool has_osd;
unsigned int max_width, max_height;
+   const u32 *formats;
+   unsigned int num_formats;
 };
 
 struct ingenic_drm {
@@ -73,12 +75,6 @@ struct ingenic_drm {
bool no_vblank;
 };
 
-static const u32 ingenic_drm_primary_formats[] = {
-   DRM_FORMAT_XRGB1555,
-   DRM_FORMAT_RGB565,
-   DRM_FORMAT_XRGB,
-};
-
 static bool ingenic_drm_cached_gem_buf;
 module_param_named(cached_gem_buffers, ingenic_drm_cached_gem_buf, bool, 0400);
 MODULE_PARM_DESC(cached_gem_buffers,
@@ -411,6 +407,9 @@ void ingenic_drm_plane_config(struct device *dev,
case DRM_FORMAT_XRGB:
ctrl |= JZ_LCD_OSDCTRL_BPP_18_24;
break;
+   case DRM_FORMAT_XRGB2101010:
+   ctrl |= JZ_LCD_OSDCTRL_BPP_30;
+   break;
}
 
regmap_update_bits(priv->map, JZ_REG_LCD_OSDCTRL,
@@ -426,6 +425,9 @@ void ingenic_drm_plane_config(struct device *dev,
case DRM_FORMAT_XRGB:
ctrl |= JZ_LCD_CTRL_BPP_18_24;
break;
+   case DRM_FORMAT_XRGB2101010:
+   ctrl |= JZ_LCD_CTRL_BPP_30;
+   break;
}
 
regmap_update_bits(priv->map, JZ_REG_LCD_CTRL,
@@ -894,8 +896,8 @@ static int ingenic_drm_bind(struct device *dev, bool 
has_components)
 
ret = drm_universal_plane_init(drm, >f1, 1,
   _drm_primary_plane_funcs,
-  ingenic_drm_primary_formats,
-  ARRAY_SIZE(ingenic_drm_primary_formats),
+  priv->soc_info->formats,
+  priv->soc_info->num_formats,
   NULL, DRM_PLANE_TYPE_PRIMARY, NULL);
if (ret) {
dev_err(dev, "Failed to register plane: %i\n", ret);
@@ -919,8 +921,8 @@ static int ingenic_drm_bind(struct device *dev, bool 
has_components)
 
ret = drm_universal_plane_init(drm, >f0, 1,
   _drm_primary_plane_funcs,
-  ingenic_drm_primary_formats,
-  
ARRAY_SIZE(ingenic_drm_primary_formats),
+  priv->soc_info->formats,
+  priv->soc_info->num_formats,
   NULL, DRM_PLANE_TYPE_OVERLAY,
   NULL);
if (ret) {
@@ -1121,11 +1123,26 @@ static int ingenic_drm_remove(struct platform_device 
*pdev)
return 0;
 }
 
+static const u32 jz4740_formats[] = {
+   DRM_FORMAT_XRGB1555,
+   DRM_FORMAT_RGB565,
+   DRM_FORMAT_XRGB,
+};
+
+static const u32 jz4770_formats[] = {
+   DRM_FORMAT_XRGB1555,
+   DRM_FORMAT_RGB565,
+   DRM_FORMAT_XRGB,
+   DRM_FORMAT_XRGB2101010,
+};
+
 static const struct jz_soc_info jz4740_soc_info = {
.needs_dev_clk = true,
.has_osd = false,
.max_width = 800,
.max_height = 600,
+   .formats = jz4740_formats,
+   .num_formats = ARRAY_SIZE(jz4740_formats),
 };
 
 static const struct jz_soc_info jz4725b_soc_info = {
@@ -1133,6 +1150,8 @@ static const struct jz_soc_info jz4725b_soc_info = {
.has_osd = true,
.max_width = 800,
.max_height = 600,
+   .formats = jz4740_formats,
+   .num_formats = ARRAY_SIZE(jz4740_formats),
 };
 
 static const struct jz_soc_info jz4770_soc_info = {
@@ -1140,6 +1159,8 @@ static const struct jz_soc_info jz4770_soc_info = {
.has_osd = true,
.max_width = 1280,
.max_height = 720,
+   .formats = jz4770_formats,
+   .num_formats = ARRAY_SIZE(jz4770_formats),
 };
 
 static const struct of_device_id ingenic_drm_of_match[] = {
diff --git a/drivers/gpu/drm/ingenic/ingenic-drm.h 
b/drivers/gpu/drm/ingenic/ingenic-drm.h
index df99f0f75d39..f05e18e6b6fa 100644
--- a/drivers/gpu/drm/ingenic/ingenic-drm.h
+++ b/drivers/gpu/drm/ingenic/ingenic-drm.h
@@ -124,6 +124,7 @@
 #define JZ_LCD_CTRL_BPP_8  0x3
 

Re: [PATCH 06/13] dt-bindings: mfd: rohm, bd71837-pmic: Add common properties

2020-09-15 Thread Rob Herring
On Tue, Sep 15, 2020 at 12:34 AM Vaittinen, Matti
 wrote:
>
>
> Hello All,
>
> On Mon, 2020-09-14 at 16:44 -0600, Rob Herring wrote:
> > On Fri, Sep 04, 2020 at 04:53:05PM +0200, Krzysztof Kozlowski wrote:
> > > Add common properties appearing in DTSes (clock-names,
> > > clock-output-names) to fix dtbs_check warnings like:
> > >
> > >   arch/arm64/boot/dts/freescale/imx8mq-librem5-r2.dt.yaml:
> > > pmic@4b: 'clock-names', 'clock-output-names', do not match any
> > > of the regexes: 'pinctrl-[0-9]+'
> > >
> > > Signed-off-by: Krzysztof Kozlowski 
> > > ---
> > >  .../devicetree/bindings/mfd/rohm,bd71837-pmic.yaml  | 6
> > > ++
> > >  1 file changed, 6 insertions(+)
> > >
> > > diff --git a/Documentation/devicetree/bindings/mfd/rohm,bd71837-
> > > pmic.yaml b/Documentation/devicetree/bindings/mfd/rohm,bd71837-
> > > pmic.yaml
> > > index 65018a019e1d..ecce0d5e3a95 100644
> > > --- a/Documentation/devicetree/bindings/mfd/rohm,bd71837-pmic.yaml
> > > +++ b/Documentation/devicetree/bindings/mfd/rohm,bd71837-pmic.yaml
> > > @@ -32,9 +32,15 @@ properties:
> > >clocks:
> > >  maxItems: 1
> > >
> > > +  clock-names:
> > > +maxItems: 1
> >
> > Needs to define what the name is.
>
> Someone once told me that "naming is hard".
> Do we have some good common convention for 32K oscillator input naming?

No.

> Or should it just be dropped?

Yes, having a name for a single entry in *-names is kind of pointless IMO.


> > > +
> > >"#clock-cells":
> > >  const: 0
> > >
> > > +  clock-output-names:
> > > +maxItems: 1
> >
> > Ideally this one too, but we've been more flexible on it.
>
> Data-sheet for BD71837 uses pin name "C32k_OUT". So maybe this would be
> good?

What's in all the dts files? I'd go with that if there's any clear
winner. If it's already a random free-for-all, then just leave it
as-is.

>
> BD71838 uses "bd71828-32k-out" . so we could also go with this same
> convention and use "bd71837-32k-out". Or - we could take a risk and
> *assume* typical use case for this clk (as this is typically used with
> i.MX8 I'd guess the 32k is used for RTC) and name it accordingly.

It should be aligned with what the output is called, not what it is
connected to.

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


[PATCH 2/3] drm/ingenic: Reset pixclock rate when parent clock rate changes

2020-09-15 Thread Paul Cercueil
Old Ingenic SoCs can overclock very well, up to +50% of their nominal
clock rate, whithout requiring overvolting or anything like that, just
by changing the rate of the main PLL. Unfortunately, all clocks on the
system are derived from that PLL, and when the PLL rate is updated, so
is our pixel clock.

To counter that issue, we make sure that the panel is in VBLANK before
the rate change happens, and we will then re-set the pixel clock rate
afterwards, once the PLL has been changed, to be as close as possible to
the pixel rate requested by the encoder.

Signed-off-by: Paul Cercueil 
---
 drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 49 ++-
 1 file changed, 48 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c 
b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
index fb62869befdc..aa32660033d2 100644
--- a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
+++ b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
@@ -12,6 +12,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -73,6 +74,9 @@ struct ingenic_drm {
 
bool panel_is_sharp;
bool no_vblank;
+   bool update_clk_rate;
+   struct mutex clk_mutex;
+   struct notifier_block clock_nb;
 };
 
 static bool ingenic_drm_cached_gem_buf;
@@ -115,6 +119,29 @@ static inline struct ingenic_drm *drm_crtc_get_priv(struct 
drm_crtc *crtc)
return container_of(crtc, struct ingenic_drm, crtc);
 }
 
+static inline struct ingenic_drm *drm_nb_get_priv(struct notifier_block *nb)
+{
+   return container_of(nb, struct ingenic_drm, clock_nb);
+}
+
+static int ingenic_drm_update_pixclk(struct notifier_block *nb,
+unsigned long action,
+void *data)
+{
+   struct ingenic_drm *priv = drm_nb_get_priv(nb);
+
+   switch (action) {
+   case PRE_RATE_CHANGE:
+   mutex_lock(>clk_mutex);
+   priv->update_clk_rate = true;
+   drm_crtc_wait_one_vblank(>crtc);
+   return NOTIFY_OK;
+   default:
+   mutex_unlock(>clk_mutex);
+   return NOTIFY_OK;
+   }
+}
+
 static void ingenic_drm_crtc_atomic_enable(struct drm_crtc *crtc,
   struct drm_crtc_state *state)
 {
@@ -280,8 +307,14 @@ static void ingenic_drm_crtc_atomic_flush(struct drm_crtc 
*crtc,
 
if (drm_atomic_crtc_needs_modeset(state)) {
ingenic_drm_crtc_update_timings(priv, >mode);
+   priv->update_clk_rate = true;
+   }
 
+   if (priv->update_clk_rate) {
+   mutex_lock(>clk_mutex);
clk_set_rate(priv->pix_clk, state->adjusted_mode.clock * 1000);
+   priv->update_clk_rate = false;
+   mutex_unlock(>clk_mutex);
}
 
if (event) {
@@ -1046,16 +1079,28 @@ static int ingenic_drm_bind(struct device *dev, bool 
has_components)
if (soc_info->has_osd)
regmap_write(priv->map, JZ_REG_LCD_OSDC, JZ_LCD_OSDC_OSDEN);
 
+   mutex_init(>clk_mutex);
+   priv->clock_nb.notifier_call = ingenic_drm_update_pixclk;
+
+   parent_clk = clk_get_parent(priv->pix_clk);
+   ret = clk_notifier_register(parent_clk, >clock_nb);
+   if (ret) {
+   dev_err(dev, "Unable to register clock notifier\n");
+   goto err_devclk_disable;
+   }
+
ret = drm_dev_register(drm, 0);
if (ret) {
dev_err(dev, "Failed to register DRM driver\n");
-   goto err_devclk_disable;
+   goto err_clk_notifier_unregister;
}
 
drm_fbdev_generic_setup(drm, 32);
 
return 0;
 
+err_clk_notifier_unregister:
+   clk_notifier_unregister(parent_clk, >clock_nb);
 err_devclk_disable:
if (priv->lcd_clk)
clk_disable_unprepare(priv->lcd_clk);
@@ -1077,7 +1122,9 @@ static int compare_of(struct device *dev, void *data)
 static void ingenic_drm_unbind(struct device *dev)
 {
struct ingenic_drm *priv = dev_get_drvdata(dev);
+   struct clk *parent_clk = clk_get_parent(priv->pix_clk);
 
+   clk_notifier_unregister(parent_clk, >clock_nb);
if (priv->lcd_clk)
clk_disable_unprepare(priv->lcd_clk);
clk_disable_unprepare(priv->pix_clk);
-- 
2.28.0

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


  1   2   >