Re: [Linaro-mm-sig] Re: DMA-buf and uncached system memory
Am 09.08.22 um 16:46 schrieb Daniel Vetter: On Mon, Jul 04, 2022 at 03:48:03PM +0200, Christian König wrote: Hi Daniel, Am 25.06.22 um 00:02 schrieb Daniel Vetter: On Thu, Jun 23, 2022 at 01:32:18PM +0200, Christian König wrote: Am 23.06.22 um 13:27 schrieb Daniel Stone: [SNIP] If it's really your belief that dmabuf requires universal snooping, I recommend you send the patch to update the documentation, as well as to remove DRIVER_PRIME from, realistically, most non-PCIE drivers. Well, to be honest I think that would indeed be necessary. What we have created are essentially two different worlds, one for PCI devices and one for the rest. This was indeed not the intention, but it's a fact that basically all DMA-buf based PCI drivers assume coherent access. dma-buf does not require universal snooping. It does defacto require that all device access is coherent with all other device access, and consistent with the exporters notion of how cpu coherency is achieved. Not that coherent does not mean snooping, as long as all devices do unsnooped access and the exporter either does wc/uc or flushes caches that's perfectly fine, and how all the arm soc dma-buf sharing works. We should probably start documenting that better. Agreed :-) Are you volunteering to type up something that reflects the current sorry state of affairs? I'm not sure I'm the best since I guess I've been too badly involved in this ... Yeah, already working on this. But you know, normal human being with two hands and one head. With all the workload I'm pretty sure people would have cloned me by now if tech would be just a bit more advanced. Christian. We did originally have the wording in there that you have to map/unamp around every device access, but that got dropped because no one was doing that anyway. Now where this totally breaks down is how we make this work, because the idea was that dma_buf_attach validates this all. Where this means all the hilarious reasons buffer sharing might not work: - wrong coherency mode (cpu cached or not) - not contiguous (we do check that, but only once we get the sg from dma_buf_attachment_map, which strictly speaking is a bit too late but most drivers do attach as one step so not that bad in practice) - whether the dma api will throw in bounce buffers or not - random shit like "oh this is in the wrong memory bank", which I think never landed in upstream p2p connectivity is about the only one that gets this right, yay. And the only reason we can even get it right is because all the information is exposed to drivers fully. Yeah, that's why I designed P2P that way :) I also don't think it's that bad, at least for radeon, nouveau and amdgpu all the migration restrictions are actually handled correctly. In other words when a DMA-buf is about to be used by another device we use TTM to move the buffer around so that it can actually be accessed by that device. What I haven't foreseen in here is that we need to deal with different caching behaviors between exporter and importer. Yeah we should have done caching explicitly and full opt-in like with p2p. The trouble is that this would have been a multi-year fight with dma api folks, who insist it must be all transparent. So the politically clever thing was to just ignore the problem and land dma-buf, but it comes back to bite us now :-/ The issue is that the device dma api refuses to share this information because it would "leak". Which sucks, because we have defacto build every single cross-device use-case of dma-buf on the assumption we can check this (up to gl/vk specs), but oh well. So in practice this gets sorted out by endless piles of hacks to make individual use-cases work. Oh and: This is definitely not limited to arm socs. x86 socs with intel at least have exactly all the same issues, and they get solved by adding various shitty hacks to the involved drivers (like i915+amdgpu). Luckily the intel camera driver isn't in upstream yet, since that would break a bunch of the hacks since suddently there will be now 2 cpu cache incoherent devices in an x86 system. Ideally someone fixes this, but I'm not hopeful. I recommend pouring more drinks. What is definitely not correct is claiming that dma-buf wasn't meant for this. We discussed cache coherency issues endless in budapest 12 or so years ago, I was there. It's just that the reality of the current implementation is falling short, and every time someone tries to fix it we get shouted down by dma api maintainers for looking behind their current. Well that explains this, I've joined the party a year later and haven't witnessed all of this. Yay, cleared up another confusion! tldr; You have to magically know to not use cpu cached allocators on these machines. Or reject the attachment. As far as I can see that is still the cleanest option. Yeah rejecting is always an ok thing if it just doesn't work. -Daniel
RE: [Intel-gfx] [RFC 1/1] drm/i915/dgfx: Avoid parent bridge rpm on mmap mappings
> -Original Message-
> From: Vivi, Rodrigo
> Sent: Tuesday, August 9, 2022 8:36 PM
> To: Gupta, Anshuman
> Cc: intel-...@lists.freedesktop.org; dan...@ffwll.ch; Wilson, Chris P
> ; dri-devel@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [RFC 1/1] drm/i915/dgfx: Avoid parent bridge rpm on
> mmap mappings
>
> On Mon, Aug 08, 2022 at 04:05:55PM +0530, Anshuman Gupta wrote:
> > As per PCIe Spec Section 5.3,
> > When a Type 1 Function associated with a Switch/Root Port (a “virtual
> > bridge”) is in a non-D0 power state, it will emulate the behavior of a
> > conventional PCI bridge in its handling of Memory, I/O, and
> > Configuration Requests and Completions. All Memory and I/O requests
> > flowing Downstream are terminated as Unsupported Requests.
> >
> > Due to above limitations when Intel DGFX Cards graphics PCI func's
> > upstream bridge(referred as VSP) enters to D3, all mmap memory mapping
> > associated with lmem objects reads 0xff, therefore avoiding VSP
> > runtime suspend accordingly.
> >
> > This will make sure that user can read valid data from lmem, while
> > DGFX Card graphics PCI func is in D3 state.
> >
> > Signed-off-by: Anshuman Gupta
> > ---
> > drivers/gpu/drm/i915/gem/i915_gem_mman.c | 11
> > drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 8 ++
> > drivers/gpu/drm/i915/intel_runtime_pm.c | 35
> > drivers/gpu/drm/i915/intel_runtime_pm.h | 2 ++
> > 4 files changed, 56 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> > b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> > index 0c5c43852e24..968bed5b56d3 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> > @@ -845,6 +845,10 @@ static void vm_open(struct vm_area_struct *vma)
> > struct drm_i915_gem_object *obj = mmo->obj;
> >
> > GEM_BUG_ON(!obj);
> > +
> > + if (i915_gem_object_is_lmem(obj))
> > + intel_runtime_pm_get_vsp(to_i915(obj->base.dev));
> > +
> > i915_gem_object_get(obj);
> > }
> >
> > @@ -854,6 +858,10 @@ static void vm_close(struct vm_area_struct *vma)
> > struct drm_i915_gem_object *obj = mmo->obj;
> >
> > GEM_BUG_ON(!obj);
> > +
> > + if (i915_gem_object_is_lmem(obj))
> > + intel_runtime_pm_put_vsp(to_i915(obj->base.dev));
> > +
> > i915_gem_object_put(obj);
> > }
> >
> > @@ -972,6 +980,9 @@ int i915_gem_mmap(struct file *filp, struct
> vm_area_struct *vma)
> > return PTR_ERR(anon);
> > }
> >
> > + if (i915_gem_object_is_lmem(obj))
> > + intel_runtime_pm_get_vsp(to_i915(obj->base.dev));
> > +
> > vma->vm_flags |= VM_PFNMAP | VM_DONTEXPAND |
> VM_DONTDUMP | VM_IO;
> >
> > /*
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> > b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> > index 5a5cf332d8a5..bcacd95fdbc1 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> > @@ -1101,6 +1101,10 @@ static void ttm_vm_open(struct vm_area_struct
> *vma)
> > i915_ttm_to_gem(vma->vm_private_data);
> >
> > GEM_BUG_ON(!obj);
> > +
> > + if (i915_gem_object_is_lmem(obj))
> > + intel_runtime_pm_get_vsp(to_i915(obj->base.dev));
> > +
> > i915_gem_object_get(obj);
> > }
> >
> > @@ -1110,6 +1114,10 @@ static void ttm_vm_close(struct vm_area_struct
> *vma)
> > i915_ttm_to_gem(vma->vm_private_data);
> >
> > GEM_BUG_ON(!obj);
> > +
> > + if (i915_gem_object_is_lmem(obj))
> > + intel_runtime_pm_put_vsp(to_i915(obj->base.dev));
> > +
> > i915_gem_object_put(obj);
> > }
>
> we need to ensure the runtime pm get / put at dma buf attach & detach as well,
> no?
AFAIU dma-buf import does migrate an object from lmem to smem , so effectively
the memory mapping access will be
limited to smem. So there will not be any issue here, unless i am missing
something .
Thanks,
Anshuman Gupta.
>
> >
> > diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
> > b/drivers/gpu/drm/i915/intel_runtime_pm.c
> > index 6ed5786bcd29..a5557918674f 100644
> > --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> > @@ -646,3 +646,38 @@ void intel_runtime_pm_init_early(struct
> > intel_runtime_pm *rpm)
> >
> > init_intel_runtime_pm_wakeref(rpm);
> > }
> > +
> > +void intel_runtime_pm_get_vsp(struct drm_i915_private *i915) {
> > + struct pci_dev *pdev = to_pci_dev(i915->drm.dev), *vsp;
> > +
> > + if (!IS_DGFX(i915))
> > + return;
> > +
> > + vsp = pci_upstream_bridge(pdev);
> > + if (!vsp) {
> > + drm_err(>drm, "Failed to get the PCI upstream
> bridge\n");
> > + return;
> > + }
> > +
> > + pci_dbg(vsp, "get runtime usage count\n");
>
> we should always prefer the drm_dbg in our subsystem
This print will be useful in case any leaks from users around munmap.
The device bdf with pci_dbg will be useful in such cases.
>
> > +
Re: [Linaro-mm-sig] Re: [PATCH v2] drm/gem: Fix GEM handle release errors
Hi Christian, On 8/9 星期二 18:18, Christian König wrote: Hi Jeffy, Am 09.08.22 um 12:02 schrieb Chen Jeffy: Hi Christian, On 8/9 星期二 17:08, Christian König wrote: Hi Jeffy, Am 09.08.22 um 09:55 schrieb Christian König: [SNIP] So we are allowing GEM object to have multiple handles, and GEM object could have at most one dma-buf, doesn't that means that dma-buf could map to multiple handles? No, at least not for the same GEM file private. That's the reason why the rb is indexed by the dma_buf object and not the handle. In other words the rb is so that you have exactly one handle for each dma_buf in each file private. I don't think so, because if user get multiple handles for the same GEM obj and use drm_gem_prime_handle_to_fd() for those handles Mhm, that works? This is illegal and should have been prevented somehow. At least I see the problem now. I'm just not sure how to fix it. Your v2 patch indeed prevents leakage of the drm_prime_member for the additional handles, but those shouldn't have been added in the first place. The issue is that with this we make it unpredictable which handle is returned. E.g. if we have handle 2,5,7 it can be that because of re-balancing the tree sometimes 2 and sometimes 5 is returned. Maybe cache the latest returned handle in the obj(after drm_gem_prime_fd_to_handle), and clear it when that handle been deleted in drm_gem_handle_delete()? That won't work. The handle is per fpriv, but the same object is used by multiple fpriv instances. > What we could maybe do is to prevent adding multiple lockup structures when there is already one, but that's not something I can easily judge. So maybe we need to protect that unique lookup structure been deleted before deleting the last handle, and make the handle unique for GEM obj, in case of that unique lookup's handle been deleted earlier that others? How about adding a GEM obj rbtree too, and make drm_prime_member kref-ed? So the drm_prime_add_buf_handle/drm_gem_handle_create_tail/drm_gem_handle_delete would be looking up drm_prime_member by GEM obj, then update dmabuf rb and inc/dec drm_prime_member's kref, drm_gem_prime_fd_to_handle/drm_gem_prime_handle_to_fd remain unchanged. Daniel seems to be either very busy or on vacation otherwise he would have chimed in by now. Anyway, your patch seems to at least fix the of hand memory leak, so feel free to add my rb to the v2 and push it to drm-misc-fixes for now. Thanks, Christian. Something like: drm_gem_prime_fd_to_handle handle = drm_prime_lookup_buf_handle(buf) obj = obj_from_handle(handle) if !obj->primary_handle obj->primary_handle = handle return obj->primary_handle Or maybe limit GEM obj with a single lifetime handle? That's not really a good idea and breaks a couple of assumptions as far as I know. Ideas? Thanks, Christian.
[PATCH v4 1/2] dt-bindings: panel-simple-dsi: add Tianma TL057FVXP01
Adds the bindings for the Tianma TL057FVXP01 DSI panel, found on the Motorola Moto G6. Signed-off-by: Julian Braha --- v4: Fixed makefile entry. v3: Fixed kconfig dependencies. v2: Fixed accidental whitespace deletion. --- .../devicetree/bindings/display/panel/panel-simple-dsi.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml index 2c00813f5d20..1b3d5e5acefd 100644 --- a/Documentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml +++ b/Documentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml @@ -57,6 +57,8 @@ properties: - samsung,sofef00 # Shangai Top Display Optoelectronics 7" TL070WSH30 1024x600 TFT LCD panel - tdo,tl070wsh30 +# Tianma Micro-electronics TL057FVXP01 5.7" 2160x1080 LCD panel + - tianma,tl057fvxp01 reg: maxItems: 1 -- 2.34.1
[PATCH 6/7] drm/msm/dp: Don't enable HPD interrupts for edp
Most instances where HPD interrupts are masked and unmasked are guareded by the presence of an EDP panel being connected, but not all. Extend this to cover the last few places, as HPD interrupt handling is not used for the EDP case. Signed-off-by: Bjorn Andersson --- drivers/gpu/drm/msm/dp/dp_display.c | 15 ++- 1 file changed, 10 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/msm/dp/dp_display.c b/drivers/gpu/drm/msm/dp/dp_display.c index 568295381246..bb4db9acaa4f 100644 --- a/drivers/gpu/drm/msm/dp/dp_display.c +++ b/drivers/gpu/drm/msm/dp/dp_display.c @@ -610,8 +610,10 @@ static int dp_hpd_plug_handle(struct dp_display_private *dp, u32 data) } /* enable HDP irq_hpd/replug interrupt */ - dp_catalog_hpd_config_intr(dp->catalog, - DP_DP_IRQ_HPD_INT_MASK | DP_DP_HPD_REPLUG_INT_MASK, true); + if (!dp->dp_display.is_edp) + dp_catalog_hpd_config_intr(dp->catalog, + DP_DP_IRQ_HPD_INT_MASK | DP_DP_HPD_REPLUG_INT_MASK, + true); drm_dbg_dp(dp->drm_dev, "After, type=%d hpd_state=%d\n", dp->dp_display.connector_type, state); @@ -651,8 +653,10 @@ static int dp_hpd_unplug_handle(struct dp_display_private *dp, u32 data) dp->dp_display.connector_type, state); /* disable irq_hpd/replug interrupts */ - dp_catalog_hpd_config_intr(dp->catalog, - DP_DP_IRQ_HPD_INT_MASK | DP_DP_HPD_REPLUG_INT_MASK, false); + if (!dp->dp_display.is_edp) + dp_catalog_hpd_config_intr(dp->catalog, + DP_DP_IRQ_HPD_INT_MASK | DP_DP_HPD_REPLUG_INT_MASK, + false); /* unplugged, no more irq_hpd handle */ dp_del_event(dp, EV_IRQ_HPD_INT); @@ -678,7 +682,8 @@ static int dp_hpd_unplug_handle(struct dp_display_private *dp, u32 data) } /* disable HPD plug interrupts */ - dp_catalog_hpd_config_intr(dp->catalog, DP_DP_HPD_PLUG_INT_MASK, false); + if (!dp->dp_display.is_edp) + dp_catalog_hpd_config_intr(dp->catalog, DP_DP_HPD_PLUG_INT_MASK, false); /* * We don't need separate work for disconnect as -- 2.35.1
[PATCH 5/7] drm/msm/dp: Implement hpd_notify()
The DisplayPort controller's hot-plug mechanism is based on pinmuxing a
physical signal no a GPIO pin into the controller. This is not always
possible, either because there aren't dedicated GPIOs available or
because the hot-plug signal is a virtual notification, in cases such as
USB Type-C.
For these cases, by implementing the hpd_notify() callback for the
DisplayPort controller's drm_bridge, a downstream drm_bridge
(next_bridge) can be used to track and signal the connection status
changes.
This makes it possible to use downstream drm_bridges such as
display-connector or any virtual mechanism, as long as they are
implemented as a drm_bridge.
Signed-off-by: Bjorn Andersson
---
drivers/gpu/drm/msm/dp/dp_display.c | 23 +++
drivers/gpu/drm/msm/dp/dp_display.h | 1 +
drivers/gpu/drm/msm/dp/dp_drm.c | 3 +++
drivers/gpu/drm/msm/dp/dp_drm.h | 2 ++
4 files changed, 29 insertions(+)
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b/drivers/gpu/drm/msm/dp/dp_display.c
index 699f28f2251e..568295381246 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -1303,6 +1303,7 @@ static int dp_display_probe(struct platform_device *pdev)
if (!desc)
return -EINVAL;
+ dp->dp_display.dev = >dev;
dp->pdev = pdev;
dp->name = "drm_dp";
dp->id = desc->id;
@@ -1765,3 +1766,25 @@ void dp_bridge_mode_set(struct drm_bridge *drm_bridge,
dp_display->dp_mode.h_active_low =
!!(dp_display->dp_mode.drm_mode.flags & DRM_MODE_FLAG_NHSYNC);
}
+
+void dp_bridge_hpd_notify(struct drm_bridge *bridge,
+ enum drm_connector_status status)
+{
+ struct msm_dp_bridge *dp_bridge = to_dp_bridge(bridge);
+ struct msm_dp *dp_display = dp_bridge->dp_display;
+ struct dp_display_private *dp = container_of(dp_display, struct
dp_display_private, dp_display);
+
+ /* Without next_bridge interrupts are handled by the DP core directly */
+ if (!dp_display->next_bridge)
+ return;
+
+ if (!dp->core_initialized) {
+ drm_dbg_dp(dp->drm_dev, "not initialized\n");
+ return;
+ }
+
+ if (!dp_display->is_connected && status == connector_status_connected)
+ dp_add_event(dp, EV_HPD_PLUG_INT, 0, 0);
+ else if (dp_display->is_connected && status ==
connector_status_disconnected)
+ dp_add_event(dp, EV_HPD_UNPLUG_INT, 0, 0);
+}
diff --git a/drivers/gpu/drm/msm/dp/dp_display.h
b/drivers/gpu/drm/msm/dp/dp_display.h
index dcedf021f7fe..d7bc537ead31 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.h
+++ b/drivers/gpu/drm/msm/dp/dp_display.h
@@ -11,6 +11,7 @@
#include "disp/msm_disp_snapshot.h"
struct msm_dp {
+ struct device *dev;
struct drm_device *drm_dev;
struct device *codec_dev;
struct drm_bridge *bridge;
diff --git a/drivers/gpu/drm/msm/dp/dp_drm.c b/drivers/gpu/drm/msm/dp/dp_drm.c
index 6df25f7662e7..875b23910bef 100644
--- a/drivers/gpu/drm/msm/dp/dp_drm.c
+++ b/drivers/gpu/drm/msm/dp/dp_drm.c
@@ -68,6 +68,7 @@ static const struct drm_bridge_funcs dp_bridge_ops = {
.mode_valid = dp_bridge_mode_valid,
.get_modes= dp_bridge_get_modes,
.detect = dp_bridge_detect,
+ .hpd_notify = dp_bridge_hpd_notify,
};
struct drm_bridge *dp_bridge_init(struct msm_dp *dp_display, struct drm_device
*dev,
@@ -138,6 +139,8 @@ struct drm_connector *dp_drm_connector_init(struct msm_dp
*dp_display, struct dr
if (IS_ERR(connector))
return connector;
+ connector->fwnode = fwnode_handle_get(dev_fwnode(dp_display->dev));
+
drm_connector_attach_encoder(connector, encoder);
return connector;
diff --git a/drivers/gpu/drm/msm/dp/dp_drm.h b/drivers/gpu/drm/msm/dp/dp_drm.h
index 82035dbb0578..79e6b2cf2d25 100644
--- a/drivers/gpu/drm/msm/dp/dp_drm.h
+++ b/drivers/gpu/drm/msm/dp/dp_drm.h
@@ -32,5 +32,7 @@ enum drm_mode_status dp_bridge_mode_valid(struct drm_bridge
*bridge,
void dp_bridge_mode_set(struct drm_bridge *drm_bridge,
const struct drm_display_mode *mode,
const struct drm_display_mode *adjusted_mode);
+void dp_bridge_hpd_notify(struct drm_bridge *bridge,
+ enum drm_connector_status status);
#endif /* _DP_DRM_H_ */
--
2.35.1
[PATCH 7/7] drm/msm/dp: HPD handling relates to next_bridge
The DisplayPort controller's internal HPD interrupt handling is used for cases where the HPD signal is connected to a GPIO which is pinmuxed into the DisplayPort controller. Most of the logic for enabling and disabling the HPD-related interrupts is conditioned on the presence of an EDP panel, but more generically designs that has a downstream drm_bridge (next_bridge) could use this to handle the HPD interrupts, instead of the internal mechanism. So replace the current is_edp-based guards with a check for the presence of next_bridge. Signed-off-by: Bjorn Andersson --- drivers/gpu/drm/msm/dp/dp_display.c | 15 +++ 1 file changed, 7 insertions(+), 8 deletions(-) diff --git a/drivers/gpu/drm/msm/dp/dp_display.c b/drivers/gpu/drm/msm/dp/dp_display.c index bb4db9acaa4f..3e93918aa276 100644 --- a/drivers/gpu/drm/msm/dp/dp_display.c +++ b/drivers/gpu/drm/msm/dp/dp_display.c @@ -610,7 +610,7 @@ static int dp_hpd_plug_handle(struct dp_display_private *dp, u32 data) } /* enable HDP irq_hpd/replug interrupt */ - if (!dp->dp_display.is_edp) + if (!dp->dp_display.next_bridge) dp_catalog_hpd_config_intr(dp->catalog, DP_DP_IRQ_HPD_INT_MASK | DP_DP_HPD_REPLUG_INT_MASK, true); @@ -653,7 +653,7 @@ static int dp_hpd_unplug_handle(struct dp_display_private *dp, u32 data) dp->dp_display.connector_type, state); /* disable irq_hpd/replug interrupts */ - if (!dp->dp_display.is_edp) + if (!dp->dp_display.next_bridge) dp_catalog_hpd_config_intr(dp->catalog, DP_DP_IRQ_HPD_INT_MASK | DP_DP_HPD_REPLUG_INT_MASK, false); @@ -682,7 +682,7 @@ static int dp_hpd_unplug_handle(struct dp_display_private *dp, u32 data) } /* disable HPD plug interrupts */ - if (!dp->dp_display.is_edp) + if (!dp->dp_display.next_bridge) dp_catalog_hpd_config_intr(dp->catalog, DP_DP_HPD_PLUG_INT_MASK, false); /* @@ -701,7 +701,7 @@ static int dp_hpd_unplug_handle(struct dp_display_private *dp, u32 data) dp_display_handle_plugged_change(>dp_display, false); /* enable HDP plug interrupt to prepare for next plugin */ - if (!dp->dp_display.is_edp) + if (!dp->dp_display.next_bridge) dp_catalog_hpd_config_intr(dp->catalog, DP_DP_HPD_PLUG_INT_MASK, true); drm_dbg_dp(dp->drm_dev, "After, type=%d hpd_state=%d\n", @@ -1086,8 +1086,8 @@ static void dp_display_config_hpd(struct dp_display_private *dp) dp_display_host_init(dp); dp_catalog_ctrl_hpd_config(dp->catalog); - /* Enable plug and unplug interrupts only for external DisplayPort */ - if (!dp->dp_display.is_edp) + /* Enable plug and unplug interrupts only if not handled by next_bridge */ + if (!dp->dp_display.next_bridge) dp_catalog_hpd_config_intr(dp->catalog, DP_DP_HPD_PLUG_INT_MASK | DP_DP_HPD_UNPLUG_INT_MASK, @@ -1380,8 +1380,7 @@ static int dp_pm_resume(struct device *dev) dp_catalog_ctrl_hpd_config(dp->catalog); - - if (!dp->dp_display.is_edp) + if (!dp->dp_display.next_bridge) dp_catalog_hpd_config_intr(dp->catalog, DP_DP_HPD_PLUG_INT_MASK | DP_DP_HPD_UNPLUG_INT_MASK, -- 2.35.1
[PATCH 4/7] drm/msm/dp: Add SDM845 DisplayPort instance
The Qualcomm SDM845 platform has a single DisplayPort controller, with
the same design as SC7180, so add support for this by reusing the SC7180
definition.
Signed-off-by: Bjorn Andersson
---
drivers/gpu/drm/msm/dp/dp_display.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b/drivers/gpu/drm/msm/dp/dp_display.c
index e4a83c2cd972..699f28f2251e 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -178,6 +178,7 @@ static const struct of_device_id dp_dt_match[] = {
{ .compatible = "qcom,sc8180x-edp", .data = _dp_descs },
{ .compatible = "qcom,sc8280xp-dp", .data = _dp_descs },
{ .compatible = "qcom,sc8280xp-edp", .data = _edp_descs },
+ { .compatible = "qcom,sdm845-dp", .data = _dp_descs },
{ .compatible = "qcom,sm8350-dp", .data = _dp_descs },
{}
};
--
2.35.1
[PATCH 1/7] dt-bindings: msm/dp: Add SDM845 and SC8280XP compatibles
Add compatibles for the DisplayPort and Embedded DisplayPort blocks in Qualcomm SDM845 and SC8280XP platforms. Signed-off-by: Bjorn Andersson --- .../devicetree/bindings/display/msm/dp-controller.yaml | 3 +++ 1 file changed, 3 insertions(+) diff --git a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml index 94bc6e1b6451..90f9302d1731 100644 --- a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml +++ b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml @@ -16,11 +16,14 @@ description: | properties: compatible: enum: + - qcom,sdm845-dp - qcom,sc7180-dp - qcom,sc7280-dp - qcom,sc7280-edp - qcom,sc8180x-dp - qcom,sc8180x-edp + - qcom,sc8280xp-dp + - qcom,sc8280xp-edp - qcom,sm8350-dp reg: -- 2.35.1
[PATCH 3/7] drm/msm/dp: Add DP and EDP compatibles for SC8280XP
The SC8280XP platform has four DisplayPort controllers, per MDSS
instance, all with widebus support.
The first two are defined to be DisplayPort only, while the latter pair
(of each instance) can be either DisplayPort or Embedded DisplayPort.
The two sets are tied to the possible compatibels.
Signed-off-by: Bjorn Andersson
---
drivers/gpu/drm/msm/dp/dp_display.c | 22 ++
drivers/gpu/drm/msm/msm_drv.h | 1 +
2 files changed, 23 insertions(+)
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b/drivers/gpu/drm/msm/dp/dp_display.c
index 2d9bbc335786..e4a83c2cd972 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -145,6 +145,26 @@ static const struct msm_dp_desc sc8180x_dp_descs[] = {
{}
};
+static const struct msm_dp_desc sc8280xp_dp_descs[] = {
+ { .io_start = 0x0ae9, .id = MSM_DP_CONTROLLER_0, .connector_type =
DRM_MODE_CONNECTOR_DisplayPort, .wide_bus_en = true },
+ { .io_start = 0x0ae98000, .id = MSM_DP_CONTROLLER_1, .connector_type =
DRM_MODE_CONNECTOR_DisplayPort, .wide_bus_en = true },
+ { .io_start = 0x0ae9a000, .id = MSM_DP_CONTROLLER_2, .connector_type =
DRM_MODE_CONNECTOR_DisplayPort, .wide_bus_en = true },
+ { .io_start = 0x0aea, .id = MSM_DP_CONTROLLER_3, .connector_type =
DRM_MODE_CONNECTOR_DisplayPort, .wide_bus_en = true },
+ { .io_start = 0x2209, .id = MSM_DP_CONTROLLER_0, .connector_type =
DRM_MODE_CONNECTOR_DisplayPort, .wide_bus_en = true },
+ { .io_start = 0x22098000, .id = MSM_DP_CONTROLLER_1, .connector_type =
DRM_MODE_CONNECTOR_DisplayPort, .wide_bus_en = true },
+ { .io_start = 0x2209a000, .id = MSM_DP_CONTROLLER_2, .connector_type =
DRM_MODE_CONNECTOR_DisplayPort, .wide_bus_en = true },
+ { .io_start = 0x220a, .id = MSM_DP_CONTROLLER_3, .connector_type =
DRM_MODE_CONNECTOR_DisplayPort, .wide_bus_en = true },
+ {}
+};
+
+static const struct msm_dp_desc sc8280xp_edp_descs[] = {
+ { .io_start = 0x0ae9a000, .id = MSM_DP_CONTROLLER_2, .connector_type =
DRM_MODE_CONNECTOR_eDP, .wide_bus_en = true },
+ { .io_start = 0x0aea, .id = MSM_DP_CONTROLLER_3, .connector_type =
DRM_MODE_CONNECTOR_eDP, .wide_bus_en = true },
+ { .io_start = 0x2209a000, .id = MSM_DP_CONTROLLER_2, .connector_type =
DRM_MODE_CONNECTOR_eDP, .wide_bus_en = true },
+ { .io_start = 0x220a, .id = MSM_DP_CONTROLLER_3, .connector_type =
DRM_MODE_CONNECTOR_eDP, .wide_bus_en = true },
+ {}
+};
+
static const struct msm_dp_desc sm8350_dp_descs[] = {
{ .io_start = 0x0ae9, .id = MSM_DP_CONTROLLER_0, .connector_type =
DRM_MODE_CONNECTOR_DisplayPort },
{}
@@ -156,6 +176,8 @@ static const struct of_device_id dp_dt_match[] = {
{ .compatible = "qcom,sc7280-edp", .data = _dp_descs },
{ .compatible = "qcom,sc8180x-dp", .data = _dp_descs },
{ .compatible = "qcom,sc8180x-edp", .data = _dp_descs },
+ { .compatible = "qcom,sc8280xp-dp", .data = _dp_descs },
+ { .compatible = "qcom,sc8280xp-edp", .data = _edp_descs },
{ .compatible = "qcom,sm8350-dp", .data = _dp_descs },
{}
};
diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
index b3689a2d27d7..5978c6e26a1e 100644
--- a/drivers/gpu/drm/msm/msm_drv.h
+++ b/drivers/gpu/drm/msm/msm_drv.h
@@ -55,6 +55,7 @@ enum msm_dp_controller {
MSM_DP_CONTROLLER_0,
MSM_DP_CONTROLLER_1,
MSM_DP_CONTROLLER_2,
+ MSM_DP_CONTROLLER_3,
MSM_DP_CONTROLLER_COUNT,
};
--
2.35.1
[PATCH 2/7] drm/msm/dp: Stop using DP id as index in desc
In the SC8280XP platform there are two identical MDSS instances, each
with the same set of DisplayPort instances, at different addresses.
By not relying on the index to define the instance id it's possible to
describe them both in the same table and hence have a single compatible.
While at it, flatten the cfg/desc structure so that the match data is
just an array of descs.
Signed-off-by: Bjorn Andersson
---
drivers/gpu/drm/msm/dp/dp_display.c | 72 ++---
1 file changed, 25 insertions(+), 47 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b/drivers/gpu/drm/msm/dp/dp_display.c
index bfd0aeff3f0d..2d9bbc335786 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -122,61 +122,41 @@ struct dp_display_private {
struct msm_dp_desc {
phys_addr_t io_start;
+ unsigned int id;
unsigned int connector_type;
bool wide_bus_en;
};
-struct msm_dp_config {
- const struct msm_dp_desc *descs;
- size_t num_descs;
-};
-
static const struct msm_dp_desc sc7180_dp_descs[] = {
- [MSM_DP_CONTROLLER_0] = { .io_start = 0x0ae9, .connector_type =
DRM_MODE_CONNECTOR_DisplayPort },
-};
-
-static const struct msm_dp_config sc7180_dp_cfg = {
- .descs = sc7180_dp_descs,
- .num_descs = ARRAY_SIZE(sc7180_dp_descs),
+ { .io_start = 0x0ae9, .id = MSM_DP_CONTROLLER_0, .connector_type =
DRM_MODE_CONNECTOR_DisplayPort },
+ {}
};
static const struct msm_dp_desc sc7280_dp_descs[] = {
- [MSM_DP_CONTROLLER_0] = { .io_start = 0x0ae9, .connector_type =
DRM_MODE_CONNECTOR_DisplayPort, .wide_bus_en = true },
- [MSM_DP_CONTROLLER_1] = { .io_start = 0x0aea, .connector_type =
DRM_MODE_CONNECTOR_eDP, .wide_bus_en = true },
-};
-
-static const struct msm_dp_config sc7280_dp_cfg = {
- .descs = sc7280_dp_descs,
- .num_descs = ARRAY_SIZE(sc7280_dp_descs),
+ { .io_start = 0x0ae9, .id = MSM_DP_CONTROLLER_0, .connector_type =
DRM_MODE_CONNECTOR_DisplayPort, .wide_bus_en = true },
+ { .io_start = 0x0aea, .id = MSM_DP_CONTROLLER_1, .connector_type =
DRM_MODE_CONNECTOR_eDP, .wide_bus_en = true },
+ {}
};
static const struct msm_dp_desc sc8180x_dp_descs[] = {
- [MSM_DP_CONTROLLER_0] = { .io_start = 0x0ae9, .connector_type =
DRM_MODE_CONNECTOR_DisplayPort },
- [MSM_DP_CONTROLLER_1] = { .io_start = 0x0ae98000, .connector_type =
DRM_MODE_CONNECTOR_DisplayPort },
- [MSM_DP_CONTROLLER_2] = { .io_start = 0x0ae9a000, .connector_type =
DRM_MODE_CONNECTOR_eDP },
-};
-
-static const struct msm_dp_config sc8180x_dp_cfg = {
- .descs = sc8180x_dp_descs,
- .num_descs = ARRAY_SIZE(sc8180x_dp_descs),
+ { .io_start = 0x0ae9, .id = MSM_DP_CONTROLLER_0, .connector_type =
DRM_MODE_CONNECTOR_DisplayPort },
+ { .io_start = 0x0ae98000, .id = MSM_DP_CONTROLLER_1, .connector_type =
DRM_MODE_CONNECTOR_DisplayPort },
+ { .io_start = 0x0ae9a000, .id = MSM_DP_CONTROLLER_2, .connector_type =
DRM_MODE_CONNECTOR_eDP },
+ {}
};
static const struct msm_dp_desc sm8350_dp_descs[] = {
- [MSM_DP_CONTROLLER_0] = { .io_start = 0x0ae9, .connector_type =
DRM_MODE_CONNECTOR_DisplayPort },
-};
-
-static const struct msm_dp_config sm8350_dp_cfg = {
- .descs = sm8350_dp_descs,
- .num_descs = ARRAY_SIZE(sm8350_dp_descs),
+ { .io_start = 0x0ae9, .id = MSM_DP_CONTROLLER_0, .connector_type =
DRM_MODE_CONNECTOR_DisplayPort },
+ {}
};
static const struct of_device_id dp_dt_match[] = {
- { .compatible = "qcom,sc7180-dp", .data = _dp_cfg },
- { .compatible = "qcom,sc7280-dp", .data = _dp_cfg },
- { .compatible = "qcom,sc7280-edp", .data = _dp_cfg },
- { .compatible = "qcom,sc8180x-dp", .data = _dp_cfg },
- { .compatible = "qcom,sc8180x-edp", .data = _dp_cfg },
- { .compatible = "qcom,sm8350-dp", .data = _dp_cfg },
+ { .compatible = "qcom,sc7180-dp", .data = _dp_descs },
+ { .compatible = "qcom,sc7280-dp", .data = _dp_descs },
+ { .compatible = "qcom,sc7280-edp", .data = _dp_descs },
+ { .compatible = "qcom,sc8180x-dp", .data = _dp_descs },
+ { .compatible = "qcom,sc8180x-edp", .data = _dp_descs },
+ { .compatible = "qcom,sm8350-dp", .data = _dp_descs },
{}
};
@@ -1262,10 +1242,9 @@ int dp_display_request_irq(struct msm_dp *dp_display)
return 0;
}
-static const struct msm_dp_desc *dp_display_get_desc(struct platform_device
*pdev,
-unsigned int *id)
+static const struct msm_dp_desc *dp_display_get_desc(struct platform_device
*pdev)
{
- const struct msm_dp_config *cfg = of_device_get_match_data(>dev);
+ const struct msm_dp_desc *descs = of_device_get_match_data(>dev);
struct resource *res;
int i;
@@ -1273,11 +1252,9 @@ static const struct msm_dp_desc
*dp_display_get_desc(struct platform_device
[PATCH 0/7] drm/msm/dp: Support for external displays
Introduce support for DisplayPort on SDM845 and SC8280XP, followed by introduction of drm_bridge based HPD handling. The version of these patches are restarted, as the previous drm_connector_oob_hotplug_event()-based approach was abandoned and this only barely resembles that effort. In this effort the HPD handling is based on the reliance of the hpd_notify() being invoked by a downstream (next_bridge) drm_bridge implementation, such as the standard display-connector, or a something like an USB Type-C controller implementation. Bjorn Andersson (7): dt-bindings: msm/dp: Add SDM845 and SC8280XP compatibles drm/msm/dp: Stop using DP id as index in desc drm/msm/dp: Add DP and EDP compatibles for SC8280XP drm/msm/dp: Add SDM845 DisplayPort instance drm/msm/dp: Implement hpd_notify() drm/msm/dp: Don't enable HPD interrupts for edp drm/msm/dp: HPD handling relates to next_bridge .../bindings/display/msm/dp-controller.yaml | 3 + drivers/gpu/drm/msm/dp/dp_display.c | 136 +++--- drivers/gpu/drm/msm/dp/dp_display.h | 1 + drivers/gpu/drm/msm/dp/dp_drm.c | 3 + drivers/gpu/drm/msm/dp/dp_drm.h | 2 + drivers/gpu/drm/msm/msm_drv.h | 1 + 6 files changed, 92 insertions(+), 54 deletions(-) -- 2.35.1
RE: [RESEND RFC 15/18] drm/display/dp_mst: Skip releasing payloads if last connected port isn't connected
[Public]
> -Original Message-
> From: Lyude Paul
> Sent: Wednesday, August 3, 2022 6:12 AM
> To: Lin, Wayne ; dri-devel@lists.freedesktop.org;
> nouv...@lists.freedesktop.org; amd-...@lists.freedesktop.org
> Cc: Ville Syrjälä ; Zuo, Jerry
> ; Jani Nikula ; Imre Deak
> ; Daniel Vetter ; Sean Paul
> ; David Airlie ; Daniel Vetter
> ; Thomas Zimmermann ; Lakha,
> Bhawanpreet ; open list ker...@vger.kernel.org>
> Subject: Re: [RESEND RFC 15/18] drm/display/dp_mst: Skip releasing
> payloads if last connected port isn't connected
>
> On Tue, 2022-07-05 at 08:45 +, Lin, Wayne wrote:
> > [Public]
> >
> >
> >
> > > -Original Message-
> > > From: Lyude Paul
> > > Sent: Wednesday, June 8, 2022 3:30 AM
> > > To: dri-devel@lists.freedesktop.org; nouv...@lists.freedesktop.org;
> > > amd- g...@lists.freedesktop.org
> > > Cc: Lin, Wayne ; Ville Syrjälä
> > > ; Zuo, Jerry ;
> > > Jani Nikula ; Imre Deak
> > > ; Daniel Vetter ; Sean
> > > Paul ; David Airlie ; Daniel
> > > Vetter ; Thomas Zimmermann
> ;
> > > Lakha, Bhawanpreet ; open list
> > >
> > > Subject: [RESEND RFC 15/18] drm/display/dp_mst: Skip releasing
> > > payloads if last connected port isn't connected
> > >
> > > In the past, we've ran into strange issues regarding errors in
> > > response to trying to destroy payloads after a port has been
> > > unplugged. We fixed this back in:
> > >
> > > This is intended to replace the workaround that was added here:
> > >
> > > commit 3769e4c0af5b ("drm/dp_mst: Avoid to mess up payload table by
> > > ports in stale topology")
> > >
> > > which was intended fix to some of the payload leaks that were
> > > observed before, where we would attempt to determine if the port was
> > > still connected to the topology before updating payloads using
> > > drm_dp_mst_port_downstream_of_branch. This wasn't a particularly
> > > good solution, since one of the points of still having port and mstb
> > > validation is to avoid sending messages to newly disconnected
> > > branches wherever possible
> > > - thus the required use of drm_dp_mst_port_downstream_of_branch
> > > would indicate something may be wrong with said validation.
> > >
> > > It seems like it may have just been races and luck that made
> > > drm_dp_mst_port_downstream_of_branch work however, as while I
> was
> > > trying to figure out the true cause of this issue when removing the
> > > legacy MST code - I discovered an important excerpt in section
> > > 2.14.2.3.3.6 of the DP
> > > 2.0
> > > specs:
> > >
> > > "BAD_PARAM - This reply is transmitted when a Message Transaction
> > > parameter is in error; for example, the next port number is invalid
> > > or /no device is connected/ to the port associated with the port number."
> > >
> > > Sure enough - removing the calls to
> > > drm_dp_mst_port_downstream_of_branch()
> > > and instead checking the ->ddps field of the parent port to see
> > > whether we should release a given payload or not seems to totally
> > > fix the issue. This does actually make sense to me, as it seems the
> > > implication is that given a topology where an MSTB is removed, the
> > > payload for the MST parent's port will be released automatically if
> > > that port is also marked as disconnected.
> > > However, if there's another parent in the chain after that which is
> > > connected
> > > - payloads must be released there with an ALLOCATE_PAYLOAD message.
> > >
> > > So, let's do that!
> > >
> > > Signed-off-by: Lyude Paul
> > > Cc: Wayne Lin
> > > Cc: Ville Syrjälä
> > > Cc: Fangzhi Zuo
> > > Cc: Jani Nikula
> > > Cc: Imre Deak
> > > Cc: Daniel Vetter
> > > Cc: Sean Paul
> > > ---
> > > drivers/gpu/drm/display/drm_dp_mst_topology.c | 51
> > > +++
> > > 1 file changed, 17 insertions(+), 34 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > > b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > > index dd314586bac3..70adb8db4335 100644
> > > --- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > > +++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > > @@ -3137,7 +3137,7 @@ static struct drm_dp_mst_port
> > > *drm_dp_get_last_connected_port_to_mstb(struct drm static struct
> > > drm_dp_mst_branch
> * drm_dp_get_last_connected_port_and_mstb(struct
> > > drm_dp_mst_topology_mgr *mgr,
> > > struct drm_dp_mst_branch
> > > *mstb,
> > > - int *port_num)
> > > + struct drm_dp_mst_port
> > > **last_port)
> > > {
> > > struct drm_dp_mst_branch *rmstb = NULL;
> > > struct drm_dp_mst_port *found_port; @@ -3153,7 +3153,8 @@
> > > drm_dp_get_last_connected_port_and_mstb(struct
> > > drm_dp_mst_topology_mgr *mgr,
> > >
> > > if (drm_dp_mst_topology_try_get_mstb(found_port-
> > > > parent)) {
> > > rmstb = found_port->parent;
> > > - *port_num = found_port->port_num;
> > >
Re: [PATCH] drm/msm/dp: check hpd_state before push idle pattern at dp_bridge_disable()
Quoting Kuogee Hsieh (2022-08-09 13:44:50)
> dp_bridge_disable() is the first step toward tearing down main link.
> Its major function is to start transmitting idle pattern to replace
> video stream. This patch will check hpd_state to make sure main link
> is enabled before commit changes of main link's configuration to
> push idle pattern out to avoid system crashing due to main link clock
> is disabled while access main link registers.
>
> Fixes: 13ea4799a81b ("drm/msm/dp: remove extra wrappers and public
> functions");
Does it really fix 375a126090b9 ("drm/msm/dp: tear down main link at
unplug handle immediately")? I don't see how removing extra wrappers
caused us to start trying to set the idle pattern when the device was
unclocked.
[PATCH] drm/i915/guc/slpc: Allow SLPC to use efficient frequency
Host Turbo operates at efficient frequency when GT is not idle unless
the user or workload has forced it to a higher level. Replicate the same
behavior in SLPC by allowing the algorithm to use efficient frequency.
We had disabled it during boot due to concerns that it might break
kernel ABI for min frequency. However, this is not the case, since
SLPC will still abide by the (min,max) range limits and pcode forces
frequency to 0 anyways when GT is in C6.
We also see much better perf numbers with benchmarks like glmark2 with
efficient frequency usage enabled.
Fixes: 025cb07bebfa ("drm/i915/guc/slpc: Cache platform frequency limits")
Signed-off-by: Vinay Belgaumkar
---
drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c | 52 -
1 file changed, 52 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
index e1fa1f32f29e..4b824da3048a 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
@@ -137,17 +137,6 @@ static int guc_action_slpc_set_param(struct intel_guc
*guc, u8 id, u32 value)
return ret > 0 ? -EPROTO : ret;
}
-static int guc_action_slpc_unset_param(struct intel_guc *guc, u8 id)
-{
- u32 request[] = {
- GUC_ACTION_HOST2GUC_PC_SLPC_REQUEST,
- SLPC_EVENT(SLPC_EVENT_PARAMETER_UNSET, 1),
- id,
- };
-
- return intel_guc_send(guc, request, ARRAY_SIZE(request));
-}
-
static bool slpc_is_running(struct intel_guc_slpc *slpc)
{
return slpc_get_state(slpc) == SLPC_GLOBAL_STATE_RUNNING;
@@ -201,16 +190,6 @@ static int slpc_set_param(struct intel_guc_slpc *slpc, u8
id, u32 value)
return ret;
}
-static int slpc_unset_param(struct intel_guc_slpc *slpc,
- u8 id)
-{
- struct intel_guc *guc = slpc_to_guc(slpc);
-
- GEM_BUG_ON(id >= SLPC_MAX_PARAM);
-
- return guc_action_slpc_unset_param(guc, id);
-}
-
static int slpc_force_min_freq(struct intel_guc_slpc *slpc, u32 freq)
{
struct drm_i915_private *i915 = slpc_to_i915(slpc);
@@ -597,29 +576,6 @@ static int slpc_set_softlimits(struct intel_guc_slpc *slpc)
return 0;
}
-static int slpc_ignore_eff_freq(struct intel_guc_slpc *slpc, bool ignore)
-{
- int ret = 0;
-
- if (ignore) {
- ret = slpc_set_param(slpc,
-SLPC_PARAM_IGNORE_EFFICIENT_FREQUENCY,
-ignore);
- if (!ret)
- return slpc_set_param(slpc,
-
SLPC_PARAM_GLOBAL_MIN_GT_UNSLICE_FREQ_MHZ,
- slpc->min_freq);
- } else {
- ret = slpc_unset_param(slpc,
- SLPC_PARAM_IGNORE_EFFICIENT_FREQUENCY);
- if (!ret)
- return slpc_unset_param(slpc,
-
SLPC_PARAM_GLOBAL_MIN_GT_UNSLICE_FREQ_MHZ);
- }
-
- return ret;
-}
-
static int slpc_use_fused_rp0(struct intel_guc_slpc *slpc)
{
/* Force SLPC to used platform rp0 */
@@ -679,14 +635,6 @@ int intel_guc_slpc_enable(struct intel_guc_slpc *slpc)
slpc_get_rp_values(slpc);
- /* Ignore efficient freq and set min to platform min */
- ret = slpc_ignore_eff_freq(slpc, true);
- if (unlikely(ret)) {
- i915_probe_error(i915, "Failed to set SLPC min to RPn (%pe)\n",
-ERR_PTR(ret));
- return ret;
- }
-
/* Set SLPC max limit to RP0 */
ret = slpc_use_fused_rp0(slpc);
if (unlikely(ret)) {
--
2.35.1
[Bug 216277] X11 doesn't wait for amdgpu driver to be up
https://bugzilla.kernel.org/show_bug.cgi?id=216277 --- Comment #7 from dark_syl...@yahoo.com.ar --- Adding amdgpu to initramfs seems to have workarounded the problem. I have not experienced this problem after it. I can also visibly see the boot process is slightly different (splash becomes 1920x1080 a bit sooner) If anyone is having the same issue, the workaround is (Ubuntu): echo "amdgpu" | sudo tee --append /etc/initramfs-tools/modules sudo update-initramfs -c -k $(uname -r) If done properly then running: lsinitramfs /boot/initrd.img-$(uname -r) | grep amdgpu Should return multiple hits Then reboot. This ticket can be closed; but probably a new one to track an interface to notify when kernel is done loading all video interfaces should be created. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[RFC v3] drm/display/dp_mst: Add helpers for serializing SST <-> MST transitions
There's another kind of situation where we could potentially race with
nonblocking modesets and MST, especially if we were to only use the locking
provided by atomic modesetting:
* Display 1 begins as enabled on DP-1 in SST mode
* Display 1 switches to MST mode, exposes one sink in MST mode
* Userspace does non-blocking modeset to disable the SST display
* Userspace does non-blocking modeset to enable the MST display with a
different CRTC, but the SST display hasn't been fully taken down yet
* Execution order between the last two commits isn't guaranteed since they
share no drm resources
We can fix this however, by ensuring that we always pull in the atomic
topology state whenever a connector capable of driving an MST display
performs its atomic check - and then tracking CRTC commits happening on the
SST connector in the MST topology state. So, let's add some simple helpers
for doing that and hook them up in various drivers.
v2:
* Use intel_dp_mst_source_support() to check for MST support in i915, fixes
CI failures
Signed-off-by: Lyude Paul
Cc: Wayne Lin
Cc: Ville Syrjälä
Cc: Fangzhi Zuo
Cc: Jani Nikula
Cc: Imre Deak
Cc: Daniel Vetter
Cc: Sean Paul
Acked-by: Jani Nikula
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 7 +++
drivers/gpu/drm/display/drm_dp_mst_topology.c | 59 +++
drivers/gpu/drm/i915/display/intel_dp.c | 9 +++
drivers/gpu/drm/nouveau/dispnv50/disp.c | 2 +-
drivers/gpu/drm/nouveau/dispnv50/disp.h | 2 +
drivers/gpu/drm/nouveau/nouveau_connector.c | 14 +
include/drm/display/drm_dp_mst_helper.h | 2 +
7 files changed, 94 insertions(+), 1 deletion(-)
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 1739710003a4..51732bd603a9 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -6318,10 +6318,17 @@ amdgpu_dm_connector_atomic_check(struct drm_connector
*conn,
drm_atomic_get_old_connector_state(state, conn);
struct drm_crtc *crtc = new_con_state->crtc;
struct drm_crtc_state *new_crtc_state;
+ struct amdgpu_dm_connector *aconn = to_amdgpu_dm_connector(conn);
int ret;
trace_amdgpu_dm_connector_atomic_check(new_con_state);
+ if (conn->connector_type == DRM_MODE_CONNECTOR_DisplayPort) {
+ ret = drm_dp_mst_root_conn_atomic_check(new_con_state,
>mst_mgr);
+ if (ret < 0)
+ return ret;
+ }
+
if (!crtc)
return 0;
diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c
b/drivers/gpu/drm/display/drm_dp_mst_topology.c
index 2f7c43f88d74..97e8f8a83ed4 100644
--- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
@@ -4597,6 +4597,65 @@ void drm_dp_mst_atomic_wait_for_dependencies(struct
drm_atomic_state *state)
}
EXPORT_SYMBOL(drm_dp_mst_atomic_wait_for_dependencies);
+/**
+ * drm_dp_mst_root_conn_atomic_check() - Serialize CRTC commits on MST-capable
connectors operating
+ * in SST mode
+ * @new_conn_state: The new connector state of the _connector
+ * @mgr: The MST topology manager for the _connector
+ *
+ * Since MST uses fake _encoder structs, the generic atomic modesetting
code isn't able to
+ * serialize non-blocking commits happening on the real DP connector of an MST
topology switching
+ * into/away from MST mode - as the CRTC on the real DP connector and the
CRTCs on the connector's
+ * MST topology will never share the same _encoder.
+ *
+ * This function takes care of this serialization issue, by checking a root
MST connector's atomic
+ * state to determine if it is about to have a modeset - and then pulling in
the MST topology state
+ * if so, along with adding any relevant CRTCs to
_dp_mst_topology_state.pending_crtc_mask.
+ *
+ * Drivers implementing MST must call this function from the
+ * _connector_helper_funcs.atomic_check hook of any physical DP
_connector capable of
+ * driving MST sinks.
+ *
+ * Returns:
+ * 0 on success, negative error code otherwise
+ */
+int drm_dp_mst_root_conn_atomic_check(struct drm_connector_state
*new_conn_state,
+ struct drm_dp_mst_topology_mgr *mgr)
+{
+ struct drm_atomic_state *state = new_conn_state->state;
+ struct drm_connector_state *old_conn_state =
+ drm_atomic_get_old_connector_state(state,
new_conn_state->connector);
+ struct drm_crtc_state *crtc_state;
+ struct drm_dp_mst_topology_state *mst_state = NULL;
+
+ if (new_conn_state->crtc) {
+ crtc_state = drm_atomic_get_new_crtc_state(state,
new_conn_state->crtc);
+ if (crtc_state && drm_atomic_crtc_needs_modeset(crtc_state)) {
+ mst_state = drm_atomic_get_mst_topology_state(state,
mgr);
+ if (IS_ERR(mst_state))
+
Re: [PATCH v2 1/3] drm/dp_mst: add passthrough_aux to struct drm_dp_mst_port
Ah yes of course! Probably should have asked when I gave the r-b :). Also,
just so patchwork actually catches it I will say the magic incantation:
Reviewed-by: Lyude Paul
Do we want to merge just this patch to drm-misc-next, or do you want to merge
the whole series through there? If you'd rather just merge this through amd's
branch I'm fine with that as well
On Tue, 2022-08-09 at 11:15 -0400, Hamza Mahfooz wrote:
> Hey Lyude,
>
> On 2022-08-05 17:17, Lyude Paul wrote:
> > lgtm!
> >
>
> Any chance you can apply this to drm-misc-next?
>
> > Reviewed-by: Lyude Paul
> >
> > On Fri, 2022-08-05 at 17:13 -0400, Hamza Mahfooz wrote:
> > > Currently, there is no way to identify if DSC pass-through can be
> > > enabled and what aux DSC pass-through requests ought to be sent to. So,
> > > add a variable to struct drm_dp_mst_port that keeps track of the
> > > aforementioned information.
> > >
> > > Signed-off-by: Hamza Mahfooz
> > > ---
> > > v2: define DP_DSC_PASSTHROUGH_IS_SUPPORTED
> > > ---
> > > drivers/gpu/drm/display/drm_dp_mst_topology.c | 4 +++-
> > > include/drm/display/drm_dp.h | 1 +
> > > include/drm/display/drm_dp_mst_helper.h | 3 +++
> > > 3 files changed, 7 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > > b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > > index 67b3b9697da7..71915afd9892 100644
> > > --- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > > +++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > > @@ -5921,8 +5921,10 @@ struct drm_dp_aux
> > > *drm_dp_mst_dsc_aux_for_port(struct drm_dp_mst_port *port)
> > > /* Enpoint decompression with DP-to-DP peer device */
> > > if ((endpoint_dsc & DP_DSC_DECOMPRESSION_IS_SUPPORTED)
> > > &&
> > > (endpoint_fec & DP_FEC_CAPABLE) &&
> > > - (upstream_dsc & 0x2) /* DSC passthrough */)
> > > + (upstream_dsc & DP_DSC_PASSTHROUGH_IS_SUPPORTED)) {
> > > + port->passthrough_aux = _upstream_port->aux;
> > > return >aux;
> > > + }
> > >
> > > /* Virtual DPCD decompression with DP-to-DP peer device
> > > */
> > > return _upstream_port->aux;
> > > diff --git a/include/drm/display/drm_dp.h b/include/drm/display/drm_dp.h
> > > index 9e3aff7e68bb..4d0abe4c7ea9 100644
> > > --- a/include/drm/display/drm_dp.h
> > > +++ b/include/drm/display/drm_dp.h
> > > @@ -239,6 +239,7 @@
> > >
> > > #define DP_DSC_SUPPORT 0x060 /* DP 1.4 */
> > > # define DP_DSC_DECOMPRESSION_IS_SUPPORTED (1 << 0)
> > > +# define DP_DSC_PASSTHROUGH_IS_SUPPORTED(1 << 1)
> > >
> > > #define DP_DSC_REV 0x061
> > > # define DP_DSC_MAJOR_MASK (0xf << 0)
> > > diff --git a/include/drm/display/drm_dp_mst_helper.h
> > > b/include/drm/display/drm_dp_mst_helper.h
> > > index 10adec068b7f..4a39c95f8afd 100644
> > > --- a/include/drm/display/drm_dp_mst_helper.h
> > > +++ b/include/drm/display/drm_dp_mst_helper.h
> > > @@ -86,6 +86,8 @@ struct drm_dp_vcpi {
> > >* @next: link to next port on this branch device
> > >* @aux: i2c aux transport to talk to device connected to this port,
> > > protected
> > >* by _dp_mst_topology_mgr.base.lock.
> > > + * @passthrough_aux: parent aux to which DSC pass-through requests
> > > should be
> > > + * sent, only set if DSC pass-through is possible.
> > >* @parent: branch device parent of this port
> > >* @vcpi: Virtual Channel Payload info for this port.
> > >* @connector: DRM connector this port is connected to. Protected by
> > > @@ -140,6 +142,7 @@ struct drm_dp_mst_port {
> > >*/
> > > struct drm_dp_mst_branch *mstb;
> > > struct drm_dp_aux aux; /* i2c bus for this port? */
> > > + struct drm_dp_aux *passthrough_aux;
> > > struct drm_dp_mst_branch *parent;
> > >
> > > struct drm_dp_vcpi vcpi;
> >
>
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
Re: [PATCH] drm/msm/dp: check hpd_state before push idle pattern at dp_bridge_disable()
On 8/9/2022 1:44 PM, Kuogee Hsieh wrote:
dp_bridge_disable() is the first step toward tearing down main link.
Its major function is to start transmitting idle pattern to replace
video stream. This patch will check hpd_state to make sure main link
is enabled before commit changes of main link's configuration to
push idle pattern out to avoid system crashing due to main link clock
is disabled while access main link registers.
Fixes: 13ea4799a81b ("drm/msm/dp: remove extra wrappers and public functions");
there should be no ; at the end
Signed-off-by: Kuogee Hsieh
Reported-by: Leonard Lausen @leezu
We should check the email address of the reporter , this is not right.
---
drivers/gpu/drm/msm/dp/dp_display.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b/drivers/gpu/drm/msm/dp/dp_display.c
index b36f8b6..678289a 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -1729,10 +1729,20 @@ void dp_bridge_disable(struct drm_bridge *drm_bridge)
struct msm_dp_bridge *dp_bridge = to_dp_bridge(drm_bridge);
struct msm_dp *dp = dp_bridge->dp_display;
struct dp_display_private *dp_display;
+ u32 state;
dp_display = container_of(dp, struct dp_display_private, dp_display);
+ mutex_lock(_display->event_mutex);
+
+ state = dp_display->hpd_state;
+ if (state != ST_DISCONNECT_PENDING && state != ST_CONNECTED) {
+ mutex_unlock(_display->event_mutex);
+ return;
+ }
+
dp_ctrl_push_idle(dp_display->ctrl);
+ mutex_unlock(_display->event_mutex);
}
void dp_bridge_post_disable(struct drm_bridge *drm_bridge)
Re: [RFC] drm/bridge: adv7533: remove dynamic lane switching from adv7533 bridge
Hi Laurent
Thanks for the response.
On 8/9/2022 12:40 PM, Laurent Pinchart wrote:
Hi Abhinav,
Thank you for the patch.
On Mon, Aug 08, 2022 at 05:35:30PM -0700, Abhinav Kumar wrote:
adv7533 bridge tries to dynamically switch lanes based on the
mode by detaching and attaching the mipi dsi device.
This approach is incorrect because as per the DSI spec the
number of lanes is fixed at the time of system design or initial
configuration and may not change dynamically.
Is that really so ? The number of lanes connected on the board is
certainlyset at design time, but a lower number of lanes can be used at
runtime. It shouldn't change dynamically while the display is on, but it
could change at mode set time.
So as per the spec it says this:
"The number of Lanes used shall be a static parameter. It shall be fixed
at the time of system design or initial configuration and may not change
dynamically. Typically, the peripheral’s bandwidth requirement and its
corresponding Lane configuration establishes the number of Lanes used in
a system."
But I do agree with you that this does not prohibit us from changing the
lanes during mode_set time because display might have been off.
Although, I really did not see any other bridges doing it this way.
At the same time, detach() and attach() cycle seems the incorrect way to
do it here.
We did think of another approach of having a new mipi_dsi_op to
reconfigure the host without the component_del()/component_add() because
most of the host drivers also do component_del()/component_add() in
detach()/attach().
But that would not work here either because this bridge is after the DSI
controller's bridge in the chain.
Hence DSI controller's modeset would happen earlier than this one.
So even if we do have another op to reconfigure the host , this bridge's
modeset would be too late to call that new op.
It complicates things a bit, so we thought that not supporting dynamic
lane switching would be the better way forward unless there is another
suggestion on how to support this.
In addition this method of dynamic switch of detaching and
attaching the mipi dsi device also results in removing
and adding the component which is not necessary.
Yes, that doesn't look good, and the .mode_valid() operation is
definitely not the right point where to set the number of lanes.
I didnt follow this. Did you mean mode_set() is not the right point to
set the number of lanes?
So without this change, adv7533 changes the number of lanes during
mode_set time followed by a detach/attach cycle.
This approach is also prone to deadlocks. So for example, on the
db410c whenever this path is executed with lockdep enabled,
this results in a deadlock due to below ordering of locks.
-> #1 (crtc_ww_class_acquire){+.+.}-{0:0}:
lock_acquire+0x6c/0x90
drm_modeset_acquire_init+0xf4/0x150
drmm_mode_config_init+0x220/0x770
msm_drm_bind+0x13c/0x654
try_to_bring_up_aggregate_device+0x164/0x1d0
__component_add+0xa8/0x174
component_add+0x18/0x2c
dsi_dev_attach+0x24/0x30
dsi_host_attach+0x98/0x14c
devm_mipi_dsi_attach+0x38/0xb0
adv7533_attach_dsi+0x8c/0x110
adv7511_probe+0x5a0/0x930
i2c_device_probe+0x30c/0x350
really_probe.part.0+0x9c/0x2b0
__driver_probe_device+0x98/0x144
driver_probe_device+0xac/0x14c
__device_attach_driver+0xbc/0x124
bus_for_each_drv+0x78/0xd0
__device_attach+0xa8/0x1c0
device_initial_probe+0x18/0x24
bus_probe_device+0xa0/0xac
deferred_probe_work_func+0x90/0xd0
process_one_work+0x28c/0x6b0
worker_thread+0x240/0x444
kthread+0x110/0x114
ret_from_fork+0x10/0x20
-> #0 (component_mutex){+.+.}-{3:3}:
__lock_acquire+0x1280/0x20ac
lock_acquire.part.0+0xe0/0x230
lock_acquire+0x6c/0x90
__mutex_lock+0x84/0x400
mutex_lock_nested+0x3c/0x70
component_del+0x34/0x170
dsi_dev_detach+0x24/0x30
dsi_host_detach+0x20/0x64
mipi_dsi_detach+0x2c/0x40
adv7533_mode_set+0x64/0x90
adv7511_bridge_mode_set+0x210/0x214
drm_bridge_chain_mode_set+0x5c/0x84
crtc_set_mode+0x18c/0x1dc
drm_atomic_helper_commit_modeset_disables+0x40/0x50
msm_atomic_commit_tail+0x1d0/0x6e0
commit_tail+0xa4/0x180
drm_atomic_helper_commit+0x178/0x3b0
drm_atomic_commit+0xa4/0xe0
drm_client_modeset_commit_atomic+0x228/0x284
drm_client_modeset_commit_locked+0x64/0x1d0
drm_client_modeset_commit+0x34/0x60
drm_fb_helper_lastclose+0x74/0xcc
drm_lastclose+0x3c/0x80
drm_release+0xfc/0x114
__fput+0x70/0x224
fput+0x14/0x20
task_work_run+0x88/0x1a0
do_exit+0x350/0xa50
do_group_exit+0x38/0xa4
__wake_up_parent+0x0/0x34
Re: New subsystem for acceleration devices
On Sun, Aug 7, 2022 at 9:50 AM Oded Gabbay wrote: > > On Fri, Aug 5, 2022 at 6:03 AM Dave Airlie wrote: > > > > On Thu, 4 Aug 2022 at 17:44, Oded Gabbay wrote: > > > > > > On Thu, Aug 4, 2022 at 2:54 AM Dave Airlie wrote: > > > > > > > > On Thu, 4 Aug 2022 at 06:21, Oded Gabbay wrote: > > > > > > > > > > On Wed, Aug 3, 2022 at 10:04 PM Dave Airlie wrote: > > > > > > > > > > > > On Sun, 31 Jul 2022 at 22:04, Oded Gabbay > > > > > > wrote: > > > > > > > > > > > > > > Hi, > > > > > > > Greg and I talked a couple of months ago about preparing a new > > > > > > > accel > > > > > > > subsystem for compute/acceleration devices that are not GPUs and I > > > > > > > think your drivers that you are now trying to upstream fit it as > > > > > > > well. > > > > > > > > > > > > We've had some submissions for not-GPUs to the drm subsystem > > > > > > recently. > > > > > > > > > > > > Intel GNA, Intel VPU, NVDLA, rpmsg AI processor unit. > > > > > > > > > > > > why is creating a new subsystem at this time necessary? > > > > > > > > > > > > Are we just creating a subsystem to avoid the open source userspace > > > > > > consumer rules? Or do we have some concrete reasoning behind it? > > > > > > > > > > > > Dave. > > > > > > > > > > Hi Dave. > > > > > The reason it happened now is because I saw two drivers, which are > > > > > doing h/w acceleration for AI, trying to be accepted to the misc > > > > > subsystem. > > > > > Add to that the fact I talked with Greg a couple of months ago about > > > > > doing a subsystem for any compute accelerators, which he was positive > > > > > about, I thought it is a good opportunity to finally do it. > > > > > > > > > > I also honestly think that I can contribute much to these drivers from > > > > > my experience with the habana driver (which is now deployed in mass at > > > > > AWS) and contribute code from the habana driver to a common framework > > > > > for AI drivers. > > > > > > > > Why not port the habana driver to drm now instead? I don't get why it > > > > wouldn't make sense? > > > > > > imho, no, I don't see the upside. This is not a trivial change, and > > > will require a large effort. What will it give me that I need and I > > > don't have now ? > > > > The opportunity for review, code sharing, experience of locking > > hierarchy, mm integration? > > > > IMHO The biggest thing that drm has is the community of people who > > understand accelerators, memory management, userspace command > > submissions, fencing, dma-buf etc. > > > > It's hard to have input to those discussions from the outside, and > > they are always ongoing. > > > > I think one of the Intel teams reported dropping a lot of code on > > their drm port due to stuff already being there, I'd expect the same > > for you. > > > > The opposite question is also valid, what does moving to a new > > subsystem help you or others, when there is one with all the > > infrastructure and more importantly reviewers. > > > > I'd be happy to have accelerator submaintainers, I'd be happy to even > > create an ACCELERATOR property for non-gpu drivers, so they can opt > > out of some of the GPUier stuff, like multiple device node users etc, > > or even create a new class of device nodes under /dev/dri. > > > I'm taking all what you wrote seriously, these are all good points. > As I wrote to Jason, I don't want to jump the gun here. I think we > should discuss this and explore the possibilities that you suggested > because I would like to reach consensus if possible. > Maybe this is something we can discuss in LPC or in the kernel summit ? > > Oded Hi Jiho, Yuji. I want to update that I'm currently in discussions with Dave to figure out what's the best way to move forward. We are writing it down to do a proper comparison between the two paths (new accel subsystem or using drm). I guess it will take a week or so. In the meantime, I'm putting the accel code on hold. I have only managed to do the very basic infra and add a demo driver that shows how to register and unregister from it. You can check the code at: https://git.kernel.org/pub/scm/linux/kernel/git/ogabbay/linux.git/log/?h=accel It has two commits. The first adds the subsystem code and the second adds the demo driver. The subsystem code is basically drm code copied and renamed and slightly modified, but I really only worked on it for a couple of hours so take that into consideration. The important thing is that the demo driver shows the basic steps are really simple. You need to add two function calls in your probe and one function call in your release. Of course you will need to supply some function callbacks, but I haven't got to fill that in the demo driver. Once you register, you get /dev/accel/ac0 and /dev/accel/ac_controlD64 (if you want a control device). If I were to continue this, the next step is to do the open and close part. I will update once we know where things are heading. As I said, I imagine it can take a few weeks. Thanks, Oded Oded >
[PATCH] drm/msm/dp: check hpd_state before push idle pattern at dp_bridge_disable()
dp_bridge_disable() is the first step toward tearing down main link.
Its major function is to start transmitting idle pattern to replace
video stream. This patch will check hpd_state to make sure main link
is enabled before commit changes of main link's configuration to
push idle pattern out to avoid system crashing due to main link clock
is disabled while access main link registers.
Fixes: 13ea4799a81b ("drm/msm/dp: remove extra wrappers and public functions");
Signed-off-by: Kuogee Hsieh
Reported-by: Leonard Lausen @leezu
---
drivers/gpu/drm/msm/dp/dp_display.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b/drivers/gpu/drm/msm/dp/dp_display.c
index b36f8b6..678289a 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -1729,10 +1729,20 @@ void dp_bridge_disable(struct drm_bridge *drm_bridge)
struct msm_dp_bridge *dp_bridge = to_dp_bridge(drm_bridge);
struct msm_dp *dp = dp_bridge->dp_display;
struct dp_display_private *dp_display;
+ u32 state;
dp_display = container_of(dp, struct dp_display_private, dp_display);
+ mutex_lock(_display->event_mutex);
+
+ state = dp_display->hpd_state;
+ if (state != ST_DISCONNECT_PENDING && state != ST_CONNECTED) {
+ mutex_unlock(_display->event_mutex);
+ return;
+ }
+
dp_ctrl_push_idle(dp_display->ctrl);
+ mutex_unlock(_display->event_mutex);
}
void dp_bridge_post_disable(struct drm_bridge *drm_bridge)
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
Re: [PATCH 0/5] clk/qcom: Support gdsc collapse polling using 'reset' inteface
On Sat 30 Jul 04:17 CDT 2022, Akhil P Oommen wrote:
>
> Some clients like adreno gpu driver would like to ensure that its gdsc
> is collapsed at hardware during a gpu reset sequence. This is because it
> has a votable gdsc which could be ON due to a vote from another subsystem
> like tz, hyp etc or due to an internal hardware signal. To allow
> this, gpucc driver can expose an interface to the client driver using
> reset framework. Using this the client driver can trigger a polling within
> the gdsc driver.
>
> This series is rebased on top of linus's master branch.
>
> Related discussion: https://patchwork.freedesktop.org/patch/493144/
>
Forgive me if I'm assuming too much, but isn't this an extension of:
85a3d920d30a ("clk: qcom: Add a dummy enable function for GX gdsc")
With the additional requirement that disable should really ensure that
the GDSC is turned off?
Regards,
Bjorn
>
> Akhil P Oommen (5):
> dt-bindings: clk: qcom: Support gpu cx gdsc reset
> clk: qcom: Allow custom reset ops
> clk: qcom: gpucc-sc7280: Add cx collapse reset support
> clk: qcom: gdsc: Add a reset op to poll gdsc collapse
> arm64: dts: qcom: sc7280: Add Reset support for gpu
>
> arch/arm64/boot/dts/qcom/sc7280.dtsi | 3 +++
> drivers/clk/qcom/gdsc.c | 23 +++
> drivers/clk/qcom/gdsc.h | 7 +++
> drivers/clk/qcom/gpucc-sc7280.c | 6 ++
> drivers/clk/qcom/reset.c | 6 ++
> drivers/clk/qcom/reset.h | 2 ++
> include/dt-bindings/clock/qcom,gpucc-sc7280.h | 3 +++
> 7 files changed, 46 insertions(+), 4 deletions(-)
>
> --
> 2.7.4
>
Re: [PATCH 3/3] drm/bridge: tc358767: disable main link PHYs on main link disable
On 7/6/22 15:42, Robert Foss wrote: On Wed, 6 Jul 2022 at 15:28, Lucas Stach wrote: Disable the main link PHYs and put them into reset when the main link is disabled. When the PHYs stay enabled while the rest of the DP link circuits are disabled there is some noise on the data lanes, which some displays try to lock onto, waking them up from their low power state. Signed-off-by: Lucas Stach --- drivers/gpu/drm/bridge/tc358767.c | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/bridge/tc358767.c b/drivers/gpu/drm/bridge/tc358767.c index fd4936215b55..615b4988bf34 100644 --- a/drivers/gpu/drm/bridge/tc358767.c +++ b/drivers/gpu/drm/bridge/tc358767.c @@ -1249,7 +1249,13 @@ static int tc_main_link_disable(struct tc_data *tc) if (ret) return ret; - return regmap_write(tc->regmap, DP0CTL, 0); + ret = regmap_write(tc->regmap, DP0CTL, 0); + if (ret) + return ret; + + return regmap_update_bits(tc->regmap, DP_PHY_CTRL, + PHY_M0_RST | PHY_M1_RST | PHY_M0_EN, + PHY_M0_RST | PHY_M1_RST); } static int tc_dsi_rx_enable(struct tc_data *tc) -- 2.30.2 Reviewed-by: Robert Foss Do you want me to apply this ?
Re: [PATCH 23/33] drm/vc4: hdmi: Move HDMI reset to pm_resume
Hallo Stefan,
On 8/9/22 13:16, Stefan Wahren wrote:
Hi Florian,
Am 05.08.22 um 01:11 schrieb Florian Fainelli:
On 6/13/22 07:47, Maxime Ripard wrote:
From: Dave Stevenson
The BCM2835-37 found in the RaspberryPi 0 to 3 have a power domain
attached to the HDMI block, handled in Linux through runtime_pm.
That power domain is shared with the VEC block, so even if we put our
runtime_pm reference in the HDMI driver it would keep being on. If the
VEC is disabled though, the power domain would be disabled and we would
lose any initialization done in our bind implementation.
That initialization involves calling the reset function and initializing
the CEC registers.
Let's move the initialization to our runtime_resume implementation so
that we initialize everything properly if we ever need to.
Fixes: c86b41214362 ("drm/vc4: hdmi: Move the HSM clock enable to
runtime_pm")
Signed-off-by: Dave Stevenson
Signed-off-by: Maxime Ripard
After seeing the same warning as Stefan reported in the link below,
but on the Raspberry Pi 4B:
https://www.spinics.net/lists/dri-devel/msg354170.html
a separate bisection effort led me to this commit, before is fine,
after produces 4 warnings during boot, see attached log.
Which config do you use (multi_v7_defconfig + LPAE or arm64/defconfig)?
This was actually bcm2835_defconfig copied over to arch/arm64/configs/
and slightly modified to enable PCIe, here is it:
https://gist.github.com/481999edc11b823d0c3e87ecf1693d26
Is there a fix that we can try that would also cover the Raspberry Pi
4B? Is it possible that this series precipitates the problem:
https://www.spinics.net/lists/arm-kernel/msg984638.html
I don't think this is related because this is a different driver.
Best regards
--
Florian
Re: [PATCH 23/33] drm/vc4: hdmi: Move HDMI reset to pm_resume
Hi Florian,
Am 05.08.22 um 01:11 schrieb Florian Fainelli:
On 6/13/22 07:47, Maxime Ripard wrote:
From: Dave Stevenson
The BCM2835-37 found in the RaspberryPi 0 to 3 have a power domain
attached to the HDMI block, handled in Linux through runtime_pm.
That power domain is shared with the VEC block, so even if we put our
runtime_pm reference in the HDMI driver it would keep being on. If the
VEC is disabled though, the power domain would be disabled and we would
lose any initialization done in our bind implementation.
That initialization involves calling the reset function and initializing
the CEC registers.
Let's move the initialization to our runtime_resume implementation so
that we initialize everything properly if we ever need to.
Fixes: c86b41214362 ("drm/vc4: hdmi: Move the HSM clock enable to
runtime_pm")
Signed-off-by: Dave Stevenson
Signed-off-by: Maxime Ripard
After seeing the same warning as Stefan reported in the link below,
but on the Raspberry Pi 4B:
https://www.spinics.net/lists/dri-devel/msg354170.html
a separate bisection effort led me to this commit, before is fine,
after produces 4 warnings during boot, see attached log.
Which config do you use (multi_v7_defconfig + LPAE or arm64/defconfig)?
Is there a fix that we can try that would also cover the Raspberry Pi
4B? Is it possible that this series precipitates the problem:
https://www.spinics.net/lists/arm-kernel/msg984638.html
I don't think this is related because this is a different driver.
Best regards
Re: [PATCH v3 1/2] dt-bindings: panel-simple-dsi: add Tianma TL057FVXP01
On Mon, 08 Aug 2022 17:37:25 -0400, Julian Braha wrote: > Adds the bindings for the Tianma TL057FVXP01 DSI panel, > found on the Motorola Moto G6. > > Signed-off-by: Julian Braha > --- > v3: > Fixed kconfig dependencies. > > v2: > Fixed accidental whitespace deletion. > --- > .../devicetree/bindings/display/panel/panel-simple-dsi.yaml | 2 ++ > 1 file changed, 2 insertions(+) > Acked-by: Rob Herring
Re: [PATCH 3/3] dt-bindings: display: simple-framebuffer: Drop Bartlomiej Zolnierkiewicz
On Mon, 08 Aug 2022 13:15:26 +0300, Krzysztof Kozlowski wrote: > Bartlomiej's Samsung email address is not working since around last > year and there was no follow up patch take over of the drivers, so drop > the email from maintainers. > > Cc: Bartlomiej Zolnierkiewicz > Signed-off-by: Krzysztof Kozlowski > > --- > > I assume that if other change was preferred, there was quite enough of > time to send a patch for this. :) > --- > .../devicetree/bindings/display/simple-framebuffer.yaml | 1 - > 1 file changed, 1 deletion(-) > Applied, thanks!
Re: [PATCH v16 1/8] dt-bindings: mediatek,dp: Add Display Port binding
On Fri, 05 Aug 2022 18:14:52 +0800, Bo-Chen Chen wrote: > From: Markus Schneider-Pargmann > > This controller is present on several mediatek hardware. Currently > mt8195 and mt8395 have this controller without a functional difference, > so only one compatible field is added. > > The controller can have two forms, as a normal display port and as an > embedded display port. > > Signed-off-by: Markus Schneider-Pargmann > Signed-off-by: Guillaume Ranquet > Signed-off-by: Bo-Chen Chen > --- > .../display/mediatek/mediatek,dp.yaml | 116 ++ > 1 file changed, 116 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/mediatek/mediatek,dp.yaml > Reviewed-by: Rob Herring
Re: [RFC] drm/bridge: adv7533: remove dynamic lane switching from adv7533 bridge
Hi Abhinav,
Thank you for the patch.
On Mon, Aug 08, 2022 at 05:35:30PM -0700, Abhinav Kumar wrote:
> adv7533 bridge tries to dynamically switch lanes based on the
> mode by detaching and attaching the mipi dsi device.
>
> This approach is incorrect because as per the DSI spec the
> number of lanes is fixed at the time of system design or initial
> configuration and may not change dynamically.
Is that really so ? The number of lanes connected on the board is
certainlyset at design time, but a lower number of lanes can be used at
runtime. It shouldn't change dynamically while the display is on, but it
could change at mode set time.
> In addition this method of dynamic switch of detaching and
> attaching the mipi dsi device also results in removing
> and adding the component which is not necessary.
Yes, that doesn't look good, and the .mode_valid() operation is
definitely not the right point where to set the number of lanes.
> This approach is also prone to deadlocks. So for example, on the
> db410c whenever this path is executed with lockdep enabled,
> this results in a deadlock due to below ordering of locks.
>
> -> #1 (crtc_ww_class_acquire){+.+.}-{0:0}:
> lock_acquire+0x6c/0x90
> drm_modeset_acquire_init+0xf4/0x150
> drmm_mode_config_init+0x220/0x770
> msm_drm_bind+0x13c/0x654
> try_to_bring_up_aggregate_device+0x164/0x1d0
> __component_add+0xa8/0x174
> component_add+0x18/0x2c
> dsi_dev_attach+0x24/0x30
> dsi_host_attach+0x98/0x14c
> devm_mipi_dsi_attach+0x38/0xb0
> adv7533_attach_dsi+0x8c/0x110
> adv7511_probe+0x5a0/0x930
> i2c_device_probe+0x30c/0x350
> really_probe.part.0+0x9c/0x2b0
> __driver_probe_device+0x98/0x144
> driver_probe_device+0xac/0x14c
> __device_attach_driver+0xbc/0x124
> bus_for_each_drv+0x78/0xd0
> __device_attach+0xa8/0x1c0
> device_initial_probe+0x18/0x24
> bus_probe_device+0xa0/0xac
> deferred_probe_work_func+0x90/0xd0
> process_one_work+0x28c/0x6b0
> worker_thread+0x240/0x444
> kthread+0x110/0x114
> ret_from_fork+0x10/0x20
>
> -> #0 (component_mutex){+.+.}-{3:3}:
> __lock_acquire+0x1280/0x20ac
> lock_acquire.part.0+0xe0/0x230
> lock_acquire+0x6c/0x90
> __mutex_lock+0x84/0x400
> mutex_lock_nested+0x3c/0x70
> component_del+0x34/0x170
> dsi_dev_detach+0x24/0x30
> dsi_host_detach+0x20/0x64
> mipi_dsi_detach+0x2c/0x40
> adv7533_mode_set+0x64/0x90
> adv7511_bridge_mode_set+0x210/0x214
> drm_bridge_chain_mode_set+0x5c/0x84
> crtc_set_mode+0x18c/0x1dc
> drm_atomic_helper_commit_modeset_disables+0x40/0x50
> msm_atomic_commit_tail+0x1d0/0x6e0
> commit_tail+0xa4/0x180
> drm_atomic_helper_commit+0x178/0x3b0
> drm_atomic_commit+0xa4/0xe0
> drm_client_modeset_commit_atomic+0x228/0x284
> drm_client_modeset_commit_locked+0x64/0x1d0
> drm_client_modeset_commit+0x34/0x60
> drm_fb_helper_lastclose+0x74/0xcc
> drm_lastclose+0x3c/0x80
> drm_release+0xfc/0x114
> __fput+0x70/0x224
> fput+0x14/0x20
> task_work_run+0x88/0x1a0
> do_exit+0x350/0xa50
> do_group_exit+0x38/0xa4
> __wake_up_parent+0x0/0x34
> invoke_syscall+0x48/0x114
> el0_svc_common.constprop.0+0x60/0x11c
> do_el0_svc+0x30/0xc0
> el0_svc+0x58/0x100
> el0t_64_sync_handler+0x1b0/0x1bc
> el0t_64_sync+0x18c/0x190
>
> Due to above reasons, remove the dynamic lane switching
> code from adv7533 bridge chip and filter out the modes
> which would need different number of lanes as compared
> to the initialization time using the mode_valid callback.
>
> Suggested-by: Dmitry Baryshkov
> Signed-off-by: Abhinav Kumar
> ---
> drivers/gpu/drm/bridge/adv7511/adv7511.h | 3 ++-
> drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 18 ++
> drivers/gpu/drm/bridge/adv7511/adv7533.c | 25 +
> 3 files changed, 29 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511.h
> b/drivers/gpu/drm/bridge/adv7511/adv7511.h
> index 9e3bb8a8ee40..0a7cec80b75d 100644
> --- a/drivers/gpu/drm/bridge/adv7511/adv7511.h
> +++ b/drivers/gpu/drm/bridge/adv7511/adv7511.h
> @@ -417,7 +417,8 @@ static inline int adv7511_cec_init(struct device *dev,
> struct adv7511 *adv7511)
>
> void adv7533_dsi_power_on(struct adv7511 *adv);
> void adv7533_dsi_power_off(struct adv7511 *adv);
> -void adv7533_mode_set(struct adv7511 *adv, const struct drm_display_mode
> *mode);
> +enum drm_mode_status adv7533_mode_valid(struct adv7511 *adv,
> + const struct drm_display_mode *mode);
> int adv7533_patch_registers(struct adv7511 *adv);
> int adv7533_patch_cec_registers(struct adv7511 *adv);
> int
[Bug 216119] 087451f372bf76d breaks hibernation on amdgpu Radeon R9 390
https://bugzilla.kernel.org/show_bug.cgi?id=216119 --- Comment #38 from Alex Deucher (alexdeuc...@gmail.com) --- (In reply to Harald Judt from comment #36) > Maybe these are also relevant, they occur right after resuming, before all > those other messages: > [drm] Fence fallback timer expired on ring sdma0 > [drm] Fence fallback timer expired on ring sdma0 Those are usually a sign of interrupt issues on the platform. E.g., interrupts not being proper enabled on the platform after resume. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[Bug 216119] 087451f372bf76d breaks hibernation on amdgpu Radeon R9 390
https://bugzilla.kernel.org/show_bug.cgi?id=216119 --- Comment #37 from Mario Limonciello (AMD) (mario.limoncie...@amd.com) --- Hmm. I get the impression that those are /probably/ collateral damage from the underlying issue of something not initializing properly during resume from S4. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
Re: [PATCH 23/33] drm/vc4: hdmi: Move HDMI reset to pm_resume
On 8/4/22 16:11, Florian Fainelli wrote:
On 6/13/22 07:47, Maxime Ripard wrote:
From: Dave Stevenson
The BCM2835-37 found in the RaspberryPi 0 to 3 have a power domain
attached to the HDMI block, handled in Linux through runtime_pm.
That power domain is shared with the VEC block, so even if we put our
runtime_pm reference in the HDMI driver it would keep being on. If the
VEC is disabled though, the power domain would be disabled and we would
lose any initialization done in our bind implementation.
That initialization involves calling the reset function and initializing
the CEC registers.
Let's move the initialization to our runtime_resume implementation so
that we initialize everything properly if we ever need to.
Fixes: c86b41214362 ("drm/vc4: hdmi: Move the HSM clock enable to
runtime_pm")
Signed-off-by: Dave Stevenson
Signed-off-by: Maxime Ripard
After seeing the same warning as Stefan reported in the link below, but
on the Raspberry Pi 4B:
https://www.spinics.net/lists/dri-devel/msg354170.html
a separate bisection effort led me to this commit, before is fine, after
produces 4 warnings during boot, see attached log.
Is there a fix that we can try that would also cover the Raspberry Pi
4B? Is it possible that this series precipitates the problem:
https://www.spinics.net/lists/arm-kernel/msg984638.html
Maxime, Dave, anything you would want me to try? Still seeing these
warnings with net-next-6.0-11220-g15205c2829ca
Would be nice to see those fixes before 6.0 final, thanks!
--
Florian
[Bug 216119] 087451f372bf76d breaks hibernation on amdgpu Radeon R9 390
https://bugzilla.kernel.org/show_bug.cgi?id=216119 --- Comment #36 from Harald Judt (h.j...@gmx.at) --- Maybe these are also relevant, they occur right after resuming, before all those other messages: [drm] Fence fallback timer expired on ring sdma0 [drm] Fence fallback timer expired on ring sdma0 -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[Bug 216119] 087451f372bf76d breaks hibernation on amdgpu Radeon R9 390
https://bugzilla.kernel.org/show_bug.cgi?id=216119 --- Comment #35 from Harald Judt (h.j...@gmx.at) --- I have not had time yet to try any patches, but here are more detailed dmesg messages when things get awry after resuming from hibernation and vt-switching (see symptoms described above). Maybe they give someone additional hints what's going wrong: [drm:amdgpu_dm_atomic_commit_tail] *ERROR* Waiting for fences timed out! [drm:amdgpu_job_timedout] *ERROR* ring gfx timeout, but soft recovered [drm:amdgpu_dm_atomic_commit_tail] *ERROR* Waiting for fences timed out! [drm:amdgpu_job_timedout] *ERROR* ring gfx timeout, but soft recovered [drm:amdgpu_dm_atomic_commit_tail] *ERROR* Waiting for fences timed out! [drm:amdgpu_job_timedout] *ERROR* ring gfx timeout, but soft recovered [drm:amdgpu_dm_atomic_commit_tail] *ERROR* Waiting for fences timed out! [drm:amdgpu_job_timedout] *ERROR* ring gfx timeout, but soft recovered [drm:amdgpu_dm_atomic_commit_tail] *ERROR* Waiting for fences timed out! [drm:amdgpu_job_timedout] *ERROR* ring gfx timeout, but soft recovered [drm:amdgpu_dm_atomic_commit_tail] *ERROR* Waiting for fences timed out! [drm:amdgpu_job_timedout] *ERROR* ring gfx timeout, but soft recovered [drm:amdgpu_job_timedout] *ERROR* ring gfx timeout, but soft recovered amdgpu :01:00.0: amdgpu: GPU fault detected: 146 0x000cc40c amdgpu :01:00.0: amdgpu: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x amdgpu :01:00.0: amdgpu: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x0C0C400C amdgpu :01:00.0: amdgpu: VM fault (0x0c, vmid 6, pasid 0) at page 0, read from 'TC7' (0x54433700) (196) amdgpu :01:00.0: amdgpu: GPU fault detected: 146 0x0004c40c amdgpu :01:00.0: amdgpu: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x amdgpu :01:00.0: amdgpu: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x040C400C amdgpu :01:00.0: amdgpu: VM fault (0x0c, vmid 2, pasid 0) at page 0, read from 'TC7' (0x54433700) (196) amdgpu :01:00.0: amdgpu: GPU fault detected: 146 0x000ac40c amdgpu :01:00.0: amdgpu: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x amdgpu :01:00.0: amdgpu: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x0A0C400C amdgpu :01:00.0: amdgpu: VM fault (0x0c, vmid 5, pasid 0) at page 0, read from 'TC7' (0x54433700) (196) amdgpu :01:00.0: amdgpu: GPU fault detected: 146 0x0004c40c amdgpu :01:00.0: amdgpu: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x amdgpu :01:00.0: amdgpu: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x040C400C amdgpu :01:00.0: amdgpu: VM fault (0x0c, vmid 2, pasid 0) at page 0, read from 'TC7' (0x54433700) (196) amdgpu :01:00.0: amdgpu: GPU fault detected: 146 0x0004480c amdgpu :01:00.0: amdgpu: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x amdgpu :01:00.0: amdgpu: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x0404800C amdgpu :01:00.0: amdgpu: VM fault (0x0c, vmid 2, pasid 0) at page 0, read from 'TC0' (0x54433000) (72) [drm:amdgpu_job_timedout] *ERROR* ring gfx timeout, but soft recovered amdgpu :01:00.0: amdgpu: GPU fault detected: 146 0x0004480c amdgpu :01:00.0: amdgpu: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x amdgpu :01:00.0: amdgpu: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x0404800C amdgpu :01:00.0: amdgpu: VM fault (0x0c, vmid 2, pasid 0) at page 0, read from 'TC0' (0x54433000) (72) [drm:amdgpu_job_timedout] *ERROR* ring gfx timeout, but soft recovered amdgpu :01:00.0: amdgpu: GPU fault detected: 146 0x000a480c amdgpu :01:00.0: amdgpu: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x amdgpu :01:00.0: amdgpu: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x0A04800C amdgpu :01:00.0: amdgpu: VM fault (0x0c, vmid 5, pasid 0) at page 0, read from 'TC0' (0x54433000) (72) [drm:amdgpu_job_timedout] *ERROR* ring gfx timeout, but soft recovered The funny thing was that another X session was still somehow usable (it takes a while to switch to it because of the hangs). But in general, those hangs when vt-switching sucks. I will try to revert all the fbdev patches again to see if that also happens with the old fb code, though I cannot remember it did. I will also test whether that happens when using only S3 instead of S4. It will probably take me a few days until I can get to it though. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
Re: [PATCH v8 1/2] drm/gem: Properly annotate WW context on drm_gem_lock_reservations() error
On Tue, Jul 05, 2022 at 01:33:51PM +0200, Christian König wrote:
> Am 01.07.22 um 11:02 schrieb Dmitry Osipenko:
> > Use ww_acquire_fini() in the error code paths. Otherwise lockdep
> > thinks that lock is held when lock's memory is freed after the
> > drm_gem_lock_reservations() error. The ww_acquire_context needs to be
> > annotated as "released", which fixes the noisy "WARNING: held lock freed!"
> > splat of VirtIO-GPU driver with CONFIG_DEBUG_MUTEXES=y and enabled lockdep.
> >
> > Cc: sta...@vger.kernel.org
> > Fixes: 7edc3e3b975b5 ("drm: Add helpers for locking an array of BO
> > reservations.")
> > Reviewed-by: Thomas Hellström
> > Signed-off-by: Dmitry Osipenko
>
> Reviewed-by: Christian König
Also added this r-b tag when merging to drm-misc-next-fixes.
-Daniel
>
> > ---
> > drivers/gpu/drm/drm_gem.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
> > index eb0c2d041f13..86d670c71286 100644
> > --- a/drivers/gpu/drm/drm_gem.c
> > +++ b/drivers/gpu/drm/drm_gem.c
> > @@ -1226,7 +1226,7 @@ drm_gem_lock_reservations(struct drm_gem_object
> > **objs, int count,
> > ret = dma_resv_lock_slow_interruptible(obj->resv,
> > acquire_ctx);
> > if (ret) {
> > - ww_acquire_done(acquire_ctx);
> > + ww_acquire_fini(acquire_ctx);
> > return ret;
> > }
> > }
> > @@ -1251,7 +1251,7 @@ drm_gem_lock_reservations(struct drm_gem_object
> > **objs, int count,
> > goto retry;
> > }
> > - ww_acquire_done(acquire_ctx);
> > + ww_acquire_fini(acquire_ctx);
> > return ret;
> > }
> > }
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [PATCH v7 1/2] drm/gem: Properly annotate WW context on drm_gem_lock_reservations() error
On Thu, Jun 30, 2022 at 11:04:04PM +0300, Dmitry Osipenko wrote:
> Use ww_acquire_fini() in the error code paths. Otherwise lockdep
> thinks that lock is held when lock's memory is freed after the
> drm_gem_lock_reservations() error. The ww_acquire_context needs to be
> annotated as "released", which fixes the noisy "WARNING: held lock freed!"
> splat of VirtIO-GPU driver with CONFIG_DEBUG_MUTEXES=y and enabled lockdep.
>
> Cc: sta...@vger.kernel.org
> Fixes: 7edc3e3b975b5 ("drm: Add helpers for locking an array of BO
> reservations.")
> Reviewed-by: Thomas Hellström
> Signed-off-by: Dmitry Osipenko
I merged this one to drm-misc-next-fixes. The other one looks like there's
still opens pending, pls resubmit appropriately (and maybe with some
analysis in the commit message of how exactly this impacts other drivers).
-Daniel
> ---
> drivers/gpu/drm/drm_gem.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
> index eb0c2d041f13..86d670c71286 100644
> --- a/drivers/gpu/drm/drm_gem.c
> +++ b/drivers/gpu/drm/drm_gem.c
> @@ -1226,7 +1226,7 @@ drm_gem_lock_reservations(struct drm_gem_object **objs,
> int count,
> ret = dma_resv_lock_slow_interruptible(obj->resv,
>acquire_ctx);
> if (ret) {
> - ww_acquire_done(acquire_ctx);
> + ww_acquire_fini(acquire_ctx);
> return ret;
> }
> }
> @@ -1251,7 +1251,7 @@ drm_gem_lock_reservations(struct drm_gem_object **objs,
> int count,
> goto retry;
> }
>
> - ww_acquire_done(acquire_ctx);
> + ww_acquire_fini(acquire_ctx);
> return ret;
> }
> }
> --
> 2.36.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [PATCH v7 1/2] drm/shmem-helper: Add missing vunmap on error
On Thu, Jun 30, 2022 at 11:00:57PM +0300, Dmitry Osipenko wrote:
> The vmapping of dma-buf may succeed, but DRM SHMEM rejects the IOMEM
> mapping, and thus, drm_gem_shmem_vmap_locked() should unvmap the IOMEM
> before erroring out.
>
> Cc: sta...@vger.kernel.org
> Fixes: 49a3f51dfeee ("drm/gem: Use struct dma_buf_map in GEM vmap ops and
> convert GEM backends")
> Signed-off-by: Dmitry Osipenko
Pushed to drm-misc-next-fixes, thanks for your patch.
-Daniel
> ---
> drivers/gpu/drm/drm_gem_shmem_helper.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c
> b/drivers/gpu/drm/drm_gem_shmem_helper.c
> index 8ad0e02991ca..904fc893c905 100644
> --- a/drivers/gpu/drm/drm_gem_shmem_helper.c
> +++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
> @@ -302,6 +302,7 @@ static int drm_gem_shmem_vmap_locked(struct
> drm_gem_shmem_object *shmem,
> ret = dma_buf_vmap(obj->import_attach->dmabuf, map);
> if (!ret) {
> if (WARN_ON(map->is_iomem)) {
> + dma_buf_vunmap(obj->import_attach->dmabuf, map);
> ret = -EIO;
> goto err_put_pages;
> }
> --
> 2.36.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [PATCH v7 2/2] drm/shmem-helper: Correct doc-comment of drm_gem_shmem_get_sg_table()
On Thu, Jun 30, 2022 at 11:00:58PM +0300, Dmitry Osipenko wrote:
> drm_gem_shmem_get_sg_table() never returns NULL on error, but a ERR_PTR.
> Correct the doc comment which says that it returns NULL on error.
>
> Acked-by: Thomas Zimmermann
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/gpu/drm/drm_gem_shmem_helper.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c
> b/drivers/gpu/drm/drm_gem_shmem_helper.c
> index 904fc893c905..0b526657fbea 100644
> --- a/drivers/gpu/drm/drm_gem_shmem_helper.c
> +++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
> @@ -663,7 +663,8 @@ EXPORT_SYMBOL(drm_gem_shmem_print_info);
> * drm_gem_shmem_get_pages_sgt() instead.
> *
> * Returns:
> - * A pointer to the scatter/gather table of pinned pages or NULL on failure.
> + * A pointer to the scatter/gather table of pinned pages or an
> ERR_PTR()-encoded
> + * error code on failure.
There was a conflict here because another patch adjusted this already, but
I fixed it up and merged this to drm-misc-next.
Thanks, Daniel
> */
> struct sg_table *drm_gem_shmem_get_sg_table(struct drm_gem_shmem_object
> *shmem)
> {
> @@ -689,7 +690,8 @@ EXPORT_SYMBOL_GPL(drm_gem_shmem_get_sg_table);
> * drm_gem_shmem_get_sg_table() should not be directly called by drivers.
> *
> * Returns:
> - * A pointer to the scatter/gather table of pinned pages or errno on failure.
> + * A pointer to the scatter/gather table of pinned pages or an
> ERR_PTR()-encoded
> + * error code on failure.
> */
> struct sg_table *drm_gem_shmem_get_pages_sgt(struct drm_gem_shmem_object
> *shmem)
> {
> --
> 2.36.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [PATCH 0/1] [RFC] drm/fourcc: Add new unsigned R16_UINT/RG1616_UINT formats
On Fri, 2022-07-15 at 11:20 +0100, Dennis Tsiang wrote: > On 30/06/2022 08:47, Pekka Paalanen wrote: > > On Wed, 29 Jun 2022 14:53:49 + > > Simon Ser wrote: > > > > > On Wednesday, June 29th, 2022 at 16:46, Dennis Tsiang > > > wrote: > > > > > > > Thanks for your comments. This is not intended to be used for > > > > KMS, where > > > > indeed there would be no difference. This proposal is for other > > > > Graphics > > > > APIs such as Vulkan, which requires the application to be > > > > explicit > > > > upfront about how they will interpret the data, whether that be > > > > UNORM, > > > > UINT .etc. We want to be able to import dma_bufs which create a > > > > VkImage > > > > with a "_UINT" VkFormat. However there is currently no explicit > > > > mapping > > > > between the DRM fourccs + modifiers combos to "_UINT" > > > > VkFormats. One > > > > solution is to encode that into the fourccs, which is what this > > > > RFC is > > > > proposing. > > > > > > As a general comment, I don't think it's reasonable to encode all > > > of the > > > VkFormat information inside DRM FourCC. For instance, VkFormat > > > has SRGB/UNORM > > > variants which describe whether pixel values are electrical or > > > optical > > > (IOW, EOTF-encoded or not). Moreover, other APIs may encode > > > different > > > information in their format enums. > > > > Yeah, do not add any of that information to the DRM pixel format > > codes. > > > > There is *so much* other stuff you also need to define than what's > > already mentioned, and which bits you need for the API at hand > > depends > > totally on the API at hand. After the API has defined some parts of > > the > > metadata, the API user has to take care of the remaining parts of > > the > > metadata in other ways, like dynamic range or color space. > > > > Besides, when you deal with dmabuf, you already need to pass a lot > > of > > metadata explicitly, like the pixel format, width, height, stride, > > modifier, etc. so it's better to add more of those (like we will be > > doing in Wayland, and not specific to dmabuf even) than to try make > > pixel formats a huge mess through combinatorial explosion and > > sometimes > > partial and sometimes conflicting image metadata. > > > > You might be able to get a glimpse of what all metadata there could > > be > > by reading > > https://gitlab.freedesktop.org/pq/color-and-hdr/-/blob/main/doc/pixels_color.md > > . > > > > Compare Vulkan formats to e.g. > > https://docs.microsoft.com/en-us/windows/win32/api/dxgicommon/ne-dxgicommon-dxgi_color_space_type > > and you'll see that while DXGI color space enumeration is mostly > > about > > other stuff, it also has overlap with Vulkan formats I think, at > > least > > the SRGB vs. not part. > > > > Btw. practically all buffers you see used, especially if they are 8 > > bpc, they are almost guaranteed to be "SRGB" non-linearly encoded, > > but > > do you ever see that fact being explicitly communicated? > > > > Then there is the question that if you have an SRGB-encoded buffer, > > do > > you want to read out SRGB-encoded or linear values? That depends on > > what you are doing with the buffer, so if you always mapped dmabuf > > to > > Vulkan SRGB formats (or always to non-SRGB formats), then you need > > some > > other way in Vulkan for the app to say whether to sample encoded or > > linear (electrical or optical) values. And whether texture > > filtering is > > done in encoded or linear space, because that makes a difference > > too. > > > > IOW, there are cases where the format mapping depends on the user > > of the > > buffer and not only on the contents of the buffer. > > > > Therefore you simply cannot create a static mapping table between > > two > > format definition systems when the two systems are fundamentally > > different, like Vulkan and DRM fourcc. > > > > > > Thanks, > > pq > > Thanks all for your comments. We'll look into an alternative approach > to > achieve what we need. I mostly agree with Pekka here. The fourcc formats as they currently are defined only specify a bit pattern and channel order, not an interpretation. Vulkan formats, on the other hand, have everything you need in order to know how to convert float vec4s to/from that format in a shader. That's not the same as knowing what the data represents (colorspace, wite values, etc.) but it's a lot more than fourcc. That said, the Vulkan APIs for querying modifier support will give you much more fine-grained information about exactly the Vulkan formats you request. So if you ask for modifier support for VK_FORMAT_R16G16_UINT, that's what you'll get. I *think* it should be fine to use VK_FORMAT_R16G16_UINT with DRM_FOURCC_GR1616. Of course, the API on the other side will also need a more precise format specifier than fourcc if it's to know the difference between R16G16_UINT and R16G16_UNORM. --Jason
Re: tiny drm driver for NOKIA-5110 LCD
On Tue, Aug 9, 2022 at 6:14 PM Aliliche Larbi wrote: > > Good morning sir, > > I am developing a linux driver for the nokia 5110 lcd(monochrome), > I would like to know if I can use the drm API or tiny drm for this lcd. > I'm writing to you because I saw your commit in /staging/fbtft/TODO > where you talk about converting all fbtft drivers to drm_simple_display_pipe. > > Is this possible for simple monochrome lcds like the 5110 one? You may convert _existing_ driver [1] to real DRM, like it's done for SSD130x [2]. [1]: https://elixir.bootlin.com/linux/latest/source/drivers/staging/fbtft/fb_pcd8544.c [2]: https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/solomon -- With Best Regards, Andy Shevchenko
Re: [PATCH v5 00/33] DYNDBG: opt-in class'd debug for modules, use in drm.
[Catching up on mails] Did you see the feedback form Steven from tracing side of things? Does this version have that taken into account already? I think once we have that and acks from dyndbg maintainers then I think we should just land this and polish from there? Maybe some acks from drm drivrer folks (cros people where once interested), but otherwise I'm a bit afraid this might be stuck in limbo too much for too long and we just need to get going :-/ -Daniel On Fri, Aug 05, 2022 at 03:53:22PM -0600, Jim Cromie wrote: > Hi Jason, Greg, DRM-folk, > > heres V5. Diffs vs V4: > > 1st 9 have Jason's Ack > 10 is new: simple var cleanup > 11 new struct, to contain future addins. touches kernel/module/ > > dyndbg-param callbacks moved to last (of dyndbg patches) > they're where the uncertainty is, > and the bulk of the API addition (class keyword is small) > > patches between the move are the guts of the "class foo" feature. > exposure of feature is only via >control, until sysfs parts added > > DRM chunk: > included here to see how patchwork's merge & test proceeds. > categories -> classes re-work is unchanged - feels pretty solid. > nouveau & LEVEL made some progress, still WIP. > > I left out tracefs bits for now. > > UNCERTAINTIES / RFC: > > 1st is my "sharing" technique, across DRM's multi modules. Its > literally duplicated decls, by each participating module, each adding > static data in its own special section. I didn't try at all to shrink > or unify this any further. There might be a perfect place to add a > single decl, but that quest will require a pony. > > Sharing by class-names lacks the compiler support that varnames get; > "incomplete" enables will probably happen if one of the declarations > miss-spells one of the classnames. > > That said, see the how-to below: stringifying va-args in the macro > would allow direct use of the enum-consts, and cc will insist that > those consts are defined, eliminating part of the un-support. > > I could split the _BITS,_NUM handling out from _NAMES (ie split > drm.debug style patch); theres no user-demand for the _NAMES feature > ATM, and theres probably some legit API-bikeshedding to do. > > PATCHSET DESCRIPTION > > This patchset adds 'typed' "class FOO" support to dynamic-debug, where > 'typed' means either DISJOINT_BITS, like drm_dbg(DRM_UT_CORE,..), or > LEVEL_NUM (like nouveau debug-levels). Use it in DRM modules: core, > helpers, and in drivers i915, amdgpu, nouveau. > > If a module is using class'd prdbgs (pr_debug_class, dev_dbg_class, or > adapted drm_dbg_) or similar in its code, it can "opt in" to > allow dyndbg to manipulate those class'd prdebugs, by declaring in a > c-file: > > DECLARE_DYNDBG_CLASSMAP(drm_debug_classes, > DD_CLASS_TYPE_DISJOINT_BITS, 0, > "DRM_UT_CORE", > "DRM_UT_DRIVER", > "DRM_UT_KMS", > "DRM_UT_PRIME", > "DRM_UT_ATOMIC", > "DRM_UT_VBL", > "DRM_UT_STATE", > "DRM_UT_LEASE", > "DRM_UT_DP", > "DRM_UT_DRMRES"); > // how-to stringify __va_args inside the macro ? > > By doing this, a module tells dyndbg that it: > >- is using class-ids [0..N] in prdbg callsites > ( 0..N == DRM_UT_CORE..DRM_UT_DRMRES ) >- wants to refer to them by class-names [0..N] >- is mapping those names to those class-ids >- expects users to enable them via >control or >parameter/knob > > Then, a user can enable the prdbgs by their class: > >:#> echo class DRM_UT_KMS +p > /proc/dynamic_debug/control > > And with another 3-line bitmap param decl/init, wrapping the > drm_debug_classes var in a module-param-cb: > >:#> echo 0x1 > /sys/module/drm/parameters/debug > > and optionally using classnames: > >:#> echo +DRM_UT_CORE,-DRM_UT_KMS \ > > /sys/module/drm/parameters/debug_cats > > DYNAMIC_DEBUG gets: > > struct _ddebug gets a new .class_id:5 field, big enough to represent > drm_debug_category (after squeezing). It defaults to 31 for all > existing prdbgs. class_id also supports verbose uses. > > classmaps (as declared by macro above) are in their own linker > section, are loaded by kernel/module, and handled by add_module, > which attaches classmaps to their module's ddebug table. > > ddebug_change() handles a class FOO query by validating that FOO is > known by each module in the loop. The query is skipped unless the > module knows FOO, so no changes are possible w/o a good classname. > > Without class FOO in a query/command, only ids=31 can be changed by > that query. This protects all class'd prdbgs from changes by legacy > class-less user queries. > > With this support, the module opt-in approach means that: > >- modules declare classnames they like, meaningful
Re: [PATCH v2 1/3] drm/dp_mst: add passthrough_aux to struct drm_dp_mst_port
Hey Lyude,
On 2022-08-05 17:17, Lyude Paul wrote:
lgtm!
Any chance you can apply this to drm-misc-next?
Reviewed-by: Lyude Paul
On Fri, 2022-08-05 at 17:13 -0400, Hamza Mahfooz wrote:
Currently, there is no way to identify if DSC pass-through can be
enabled and what aux DSC pass-through requests ought to be sent to. So,
add a variable to struct drm_dp_mst_port that keeps track of the
aforementioned information.
Signed-off-by: Hamza Mahfooz
---
v2: define DP_DSC_PASSTHROUGH_IS_SUPPORTED
---
drivers/gpu/drm/display/drm_dp_mst_topology.c | 4 +++-
include/drm/display/drm_dp.h | 1 +
include/drm/display/drm_dp_mst_helper.h | 3 +++
3 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c
b/drivers/gpu/drm/display/drm_dp_mst_topology.c
index 67b3b9697da7..71915afd9892 100644
--- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
@@ -5921,8 +5921,10 @@ struct drm_dp_aux *drm_dp_mst_dsc_aux_for_port(struct
drm_dp_mst_port *port)
/* Enpoint decompression with DP-to-DP peer device */
if ((endpoint_dsc & DP_DSC_DECOMPRESSION_IS_SUPPORTED) &&
(endpoint_fec & DP_FEC_CAPABLE) &&
- (upstream_dsc & 0x2) /* DSC passthrough */)
+ (upstream_dsc & DP_DSC_PASSTHROUGH_IS_SUPPORTED)) {
+ port->passthrough_aux = _upstream_port->aux;
return >aux;
+ }
/* Virtual DPCD decompression with DP-to-DP peer device */
return _upstream_port->aux;
diff --git a/include/drm/display/drm_dp.h b/include/drm/display/drm_dp.h
index 9e3aff7e68bb..4d0abe4c7ea9 100644
--- a/include/drm/display/drm_dp.h
+++ b/include/drm/display/drm_dp.h
@@ -239,6 +239,7 @@
#define DP_DSC_SUPPORT 0x060 /* DP 1.4 */
# define DP_DSC_DECOMPRESSION_IS_SUPPORTED (1 << 0)
+# define DP_DSC_PASSTHROUGH_IS_SUPPORTED(1 << 1)
#define DP_DSC_REV 0x061
# define DP_DSC_MAJOR_MASK (0xf << 0)
diff --git a/include/drm/display/drm_dp_mst_helper.h
b/include/drm/display/drm_dp_mst_helper.h
index 10adec068b7f..4a39c95f8afd 100644
--- a/include/drm/display/drm_dp_mst_helper.h
+++ b/include/drm/display/drm_dp_mst_helper.h
@@ -86,6 +86,8 @@ struct drm_dp_vcpi {
* @next: link to next port on this branch device
* @aux: i2c aux transport to talk to device connected to this port, protected
* by _dp_mst_topology_mgr.base.lock.
+ * @passthrough_aux: parent aux to which DSC pass-through requests should be
+ * sent, only set if DSC pass-through is possible.
* @parent: branch device parent of this port
* @vcpi: Virtual Channel Payload info for this port.
* @connector: DRM connector this port is connected to. Protected by
@@ -140,6 +142,7 @@ struct drm_dp_mst_port {
*/
struct drm_dp_mst_branch *mstb;
struct drm_dp_aux aux; /* i2c bus for this port? */
+ struct drm_dp_aux *passthrough_aux;
struct drm_dp_mst_branch *parent;
struct drm_dp_vcpi vcpi;
--
Hamza
Re: [Intel-gfx] [RFC 1/1] drm/i915/dgfx: Avoid parent bridge rpm on mmap mappings
On Mon, Aug 08, 2022 at 04:05:55PM +0530, Anshuman Gupta wrote:
> As per PCIe Spec Section 5.3,
> When a Type 1 Function associated with a Switch/Root
> Port (a “virtual bridge”) is in a non-D0 power state,
> it will emulate the behavior of a conventional PCI bridge
> in its handling of Memory, I/O, and Configuration
> Requests and Completions. All Memory and I/O requests
> flowing Downstream are terminated as Unsupported Requests.
>
> Due to above limitations when Intel DGFX Cards graphics
> PCI func's upstream bridge(referred as VSP) enters to D3,
> all mmap memory mapping associated with lmem objects
> reads 0xff, therefore avoiding VSP runtime suspend
> accordingly.
>
> This will make sure that user can read valid data from lmem,
> while DGFX Card graphics PCI func is in D3 state.
>
> Signed-off-by: Anshuman Gupta
> ---
> drivers/gpu/drm/i915/gem/i915_gem_mman.c | 11
> drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 8 ++
> drivers/gpu/drm/i915/intel_runtime_pm.c | 35
> drivers/gpu/drm/i915/intel_runtime_pm.h | 2 ++
> 4 files changed, 56 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> index 0c5c43852e24..968bed5b56d3 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> @@ -845,6 +845,10 @@ static void vm_open(struct vm_area_struct *vma)
> struct drm_i915_gem_object *obj = mmo->obj;
>
> GEM_BUG_ON(!obj);
> +
> + if (i915_gem_object_is_lmem(obj))
> + intel_runtime_pm_get_vsp(to_i915(obj->base.dev));
> +
> i915_gem_object_get(obj);
> }
>
> @@ -854,6 +858,10 @@ static void vm_close(struct vm_area_struct *vma)
> struct drm_i915_gem_object *obj = mmo->obj;
>
> GEM_BUG_ON(!obj);
> +
> + if (i915_gem_object_is_lmem(obj))
> + intel_runtime_pm_put_vsp(to_i915(obj->base.dev));
> +
> i915_gem_object_put(obj);
> }
>
> @@ -972,6 +980,9 @@ int i915_gem_mmap(struct file *filp, struct
> vm_area_struct *vma)
> return PTR_ERR(anon);
> }
>
> + if (i915_gem_object_is_lmem(obj))
> + intel_runtime_pm_get_vsp(to_i915(obj->base.dev));
> +
> vma->vm_flags |= VM_PFNMAP | VM_DONTEXPAND | VM_DONTDUMP | VM_IO;
>
> /*
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> index 5a5cf332d8a5..bcacd95fdbc1 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> @@ -1101,6 +1101,10 @@ static void ttm_vm_open(struct vm_area_struct *vma)
> i915_ttm_to_gem(vma->vm_private_data);
>
> GEM_BUG_ON(!obj);
> +
> + if (i915_gem_object_is_lmem(obj))
> + intel_runtime_pm_get_vsp(to_i915(obj->base.dev));
> +
> i915_gem_object_get(obj);
> }
>
> @@ -1110,6 +1114,10 @@ static void ttm_vm_close(struct vm_area_struct *vma)
> i915_ttm_to_gem(vma->vm_private_data);
>
> GEM_BUG_ON(!obj);
> +
> + if (i915_gem_object_is_lmem(obj))
> + intel_runtime_pm_put_vsp(to_i915(obj->base.dev));
> +
> i915_gem_object_put(obj);
> }
we need to ensure the runtime pm get / put at dma buf attach & detach as well,
no?
>
> diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
> b/drivers/gpu/drm/i915/intel_runtime_pm.c
> index 6ed5786bcd29..a5557918674f 100644
> --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> @@ -646,3 +646,38 @@ void intel_runtime_pm_init_early(struct intel_runtime_pm
> *rpm)
>
> init_intel_runtime_pm_wakeref(rpm);
> }
> +
> +void intel_runtime_pm_get_vsp(struct drm_i915_private *i915)
> +{
> + struct pci_dev *pdev = to_pci_dev(i915->drm.dev), *vsp;
> +
> + if (!IS_DGFX(i915))
> + return;
> +
> + vsp = pci_upstream_bridge(pdev);
> + if (!vsp) {
> + drm_err(>drm, "Failed to get the PCI upstream bridge\n");
> + return;
> + }
> +
> + pci_dbg(vsp, "get runtime usage count\n");
we should always prefer the drm_dbg in our subsystem
> + pm_runtime_get_sync(>dev);
why? I believe that grabbing our own ref would be enough to block the
upstream chain. I don't understand why this is such an special case
that we don't see any other driver in the linux tree having to do such
a thing. what am I missing?
> +}
> +
> +void intel_runtime_pm_put_vsp(struct drm_i915_private *i915)
> +{
> + struct pci_dev *pdev = to_pci_dev(i915->drm.dev), *vsp;
> +
> + if (!IS_DGFX(i915))
> + return;
> +
> + vsp = pci_upstream_bridge(pdev);
> + if (!vsp) {
> + drm_err(>drm, "Failed to get the PCI upstream bridge\n");
> + return;
> + }
> +
> + pci_dbg(vsp, "put runtime usage count\n");
> + pm_runtime_mark_last_busy(>dev);
> + pm_runtime_put(>dev);
> +}
> diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.h
>
Re: [PATCH] drm/fb-helper: Remove helpers to change frame buffer config
On Sat, Jul 02, 2022 at 08:05:54PM +0200, Helge Deller wrote:
> On 6/29/22 12:56, Geert Uytterhoeven wrote:
> > The DRM fbdev emulation layer does not support pushing back
> > changes to fb_var_screeninfo to KMS.
> >
> > However, drm_fb_helper still implements the fb_ops.fb_check_var() and
> > fb_ops.fb_set_par() callbacks, but the former fails to validate various
> > parameters passed from userspace. Hence unsanitized and possible
> > invaled values are passed up through the fbdev, fbcon, and console
> > stack, which has become an endless source of security issues reported
> > against fbdev.
> >
> > Fix this by not populating the fb_ops.fb_check_var() and
> > fb_ops.fb_set_par() callbacks, as there is no point in providing them if
> > the frame buffer config cannot be changed anyway. This makes the fbdev
> > core aware that making changes to the frame buffer config is not
> > supported, so it will always return the current config.
> >
> > Signed-off-by: Geert Uytterhoeven
>
> It's unfortunate that DRM currently isn't able to switch resolutions
> at runtime.
>
> With that in mind I agree with Geert that it's probably better to
> disable (or drop) that code until DRM can cope with fbdev's
> interface to switch resolutions.
>
> Furthermore, with the upcoming patches to fbcon (which prevents crashes on
> invalid userspace input), you will face a kernel WARNING if you call fbset
> to switch screen resolutions with DRM drivers.
>
> So, from my side (although I'd prefer a better fix for DRM):
>
> Acked-by: Helge Deller
So maybe I'm missing something, but I think this breaks a lot of stuff.
The issue is that fbdev is only a subordinate owner of the kms device, if
there's a real drm kms owner around that wins.
Which means when you switch back then set_par needs to restore the fbdev
framebuffer. So that might break some recovery/use-cases.
The other thing is that I think this also breaks the scanout offset, and
people do use that for double-buffering on top of fbdev on top of drm
drivers. So we can't just nuke it completely.
For better or worse I think we need to keep playing the whack-a-mole game.
Or do I miss something here?
-Daniel
>
> Helge
>
> > ---
> > The only remaining DRM driver that implements fb_ops.fb_check_var() is
> > also broken, as it fails to validate various parameters passed from
> > userspace. So vmw_fb_check_var() should either be fixed, or removed.
> > ---
> > drivers/gpu/drm/drm_fb_helper.c| 180 ++---
> > drivers/gpu/drm/i915/display/intel_fbdev.c | 15 --
> > drivers/gpu/drm/omapdrm/omap_fbdev.c | 2 -
> > include/drm/drm_fb_helper.h| 16 --
> > 4 files changed, 13 insertions(+), 200 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_fb_helper.c
> > b/drivers/gpu/drm/drm_fb_helper.c
> > index 2d4cee6a10e7..1041a11c410d7967 100644
> > --- a/drivers/gpu/drm/drm_fb_helper.c
> > +++ b/drivers/gpu/drm/drm_fb_helper.c
> > @@ -228,9 +228,18 @@ int drm_fb_helper_debug_leave(struct fb_info *info)
> > }
> > EXPORT_SYMBOL(drm_fb_helper_debug_leave);
> >
> > -static int
> > -__drm_fb_helper_restore_fbdev_mode_unlocked(struct drm_fb_helper
> > *fb_helper,
> > - bool force)
> > +/**
> > + * drm_fb_helper_restore_fbdev_mode_unlocked - restore fbdev configuration
> > + * @fb_helper: driver-allocated fbdev helper, can be NULL
> > + *
> > + * This should be called from driver's drm _driver.lastclose callback
> > + * when implementing an fbcon on top of kms using this helper. This
> > ensures that
> > + * the user isn't greeted with a black screen when e.g. X dies.
> > + *
> > + * RETURNS:
> > + * Zero if everything went ok, negative error code otherwise.
> > + */
> > +int drm_fb_helper_restore_fbdev_mode_unlocked(struct drm_fb_helper
> > *fb_helper)
> > {
> > bool do_delayed;
> > int ret;
> > @@ -242,16 +251,7 @@ __drm_fb_helper_restore_fbdev_mode_unlocked(struct
> > drm_fb_helper *fb_helper,
> > return 0;
> >
> > mutex_lock(_helper->lock);
> > - if (force) {
> > - /*
> > -* Yes this is the _locked version which expects the master lock
> > -* to be held. But for forced restores we're intentionally
> > -* racing here, see drm_fb_helper_set_par().
> > -*/
> > - ret = drm_client_modeset_commit_locked(_helper->client);
> > - } else {
> > - ret = drm_client_modeset_commit(_helper->client);
> > - }
> > + ret = drm_client_modeset_commit(_helper->client);
> >
> > do_delayed = fb_helper->delayed_hotplug;
> > if (do_delayed)
> > @@ -263,22 +263,6 @@ __drm_fb_helper_restore_fbdev_mode_unlocked(struct
> > drm_fb_helper *fb_helper,
> >
> > return ret;
> > }
> > -
> > -/**
> > - * drm_fb_helper_restore_fbdev_mode_unlocked - restore fbdev configuration
> > - * @fb_helper: driver-allocated fbdev helper, can be NULL
> > - *
> > - * This should be called from driver's drm
Re: DMA-buf and uncached system memory
On Mon, Feb 15, 2021 at 12:58 AM Christian König wrote: > > Hi guys, > > we are currently working an Freesync and direct scan out from system > memory on AMD APUs in A+A laptops. > > On problem we stumbled over is that our display hardware needs to scan > out from uncached system memory and we currently don't have a way to > communicate that through DMA-buf. > > For our specific use case at hand we are going to implement something > driver specific, but the question is should we have something more > generic for this? I'm a bit late to this party (and sorry, I didn't read the entire thread), but it occurs to me that dmabuf mmap_info[1] would also get you what you need, ie. display importing dma-buf could check whether the exporter is mapping cached or not, and reject the import if needed? [1] https://patchwork.freedesktop.org/patch/496069/?series=106847=2 > After all the system memory access pattern is a PCIe extension and as > such something generic. > > Regards, > Christian. > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Linaro-mm-sig] Re: DMA-buf and uncached system memory
On Mon, Jul 04, 2022 at 03:48:03PM +0200, Christian König wrote: > Hi Daniel, > > Am 25.06.22 um 00:02 schrieb Daniel Vetter: > > On Thu, Jun 23, 2022 at 01:32:18PM +0200, Christian König wrote: > > > Am 23.06.22 um 13:27 schrieb Daniel Stone: > > > > [SNIP] > > > > If it's really your belief that dmabuf requires universal snooping, I > > > > recommend you send the patch to update the documentation, as well as > > > > to remove DRIVER_PRIME from, realistically, most non-PCIE drivers. > > > Well, to be honest I think that would indeed be necessary. > > > > > > What we have created are essentially two different worlds, one for PCI > > > devices and one for the rest. > > > > > > This was indeed not the intention, but it's a fact that basically all > > > DMA-buf based PCI drivers assume coherent access. > > dma-buf does not require universal snooping. > > > > It does defacto require that all device access is coherent with all other > > device access, and consistent with the exporters notion of how cpu > > coherency is achieved. Not that coherent does not mean snooping, as long > > as all devices do unsnooped access and the exporter either does wc/uc or > > flushes caches that's perfectly fine, and how all the arm soc dma-buf > > sharing works. > > We should probably start documenting that better. Agreed :-) Are you volunteering to type up something that reflects the current sorry state of affairs? I'm not sure I'm the best since I guess I've been too badly involved in this ... > > We did originally have the wording in there that you have to map/unamp > > around every device access, but that got dropped because no one was doing > > that anyway. > > > > Now where this totally breaks down is how we make this work, because the > > idea was that dma_buf_attach validates this all. Where this means all the > > hilarious reasons buffer sharing might not work: > > - wrong coherency mode (cpu cached or not) > > - not contiguous (we do check that, but only once we get the sg from > >dma_buf_attachment_map, which strictly speaking is a bit too late but > >most drivers do attach as one step so not that bad in practice) > > - whether the dma api will throw in bounce buffers or not > > - random shit like "oh this is in the wrong memory bank", which I think > >never landed in upstream > > > > p2p connectivity is about the only one that gets this right, yay. And the > > only reason we can even get it right is because all the information is > > exposed to drivers fully. > > Yeah, that's why I designed P2P that way :) > > I also don't think it's that bad, at least for radeon, nouveau and amdgpu > all the migration restrictions are actually handled correctly. > > In other words when a DMA-buf is about to be used by another device we use > TTM to move the buffer around so that it can actually be accessed by that > device. > > What I haven't foreseen in here is that we need to deal with different > caching behaviors between exporter and importer. Yeah we should have done caching explicitly and full opt-in like with p2p. The trouble is that this would have been a multi-year fight with dma api folks, who insist it must be all transparent. So the politically clever thing was to just ignore the problem and land dma-buf, but it comes back to bite us now :-/ > > The issue is that the device dma api refuses to share this information > > because it would "leak". Which sucks, because we have defacto build every > > single cross-device use-case of dma-buf on the assumption we can check > > this (up to gl/vk specs), but oh well. > > > > So in practice this gets sorted out by endless piles of hacks to make > > individual use-cases work. > > > > Oh and: This is definitely not limited to arm socs. x86 socs with intel > > at least have exactly all the same issues, and they get solved by adding > > various shitty hacks to the involved drivers (like i915+amdgpu). Luckily > > the intel camera driver isn't in upstream yet, since that would break a > > bunch of the hacks since suddently there will be now 2 cpu cache > > incoherent devices in an x86 system. > > > > Ideally someone fixes this, but I'm not hopeful. > > > > I recommend pouring more drinks. > > > > What is definitely not correct is claiming that dma-buf wasn't meant for > > this. We discussed cache coherency issues endless in budapest 12 or so > > years ago, I was there. It's just that the reality of the current > > implementation is falling short, and every time someone tries to fix it we > > get shouted down by dma api maintainers for looking behind their current. > > Well that explains this, I've joined the party a year later and haven't > witnessed all of this. Yay, cleared up another confusion! > > tldr; You have to magically know to not use cpu cached allocators on these > > machines. > > Or reject the attachment. As far as I can see that is still the cleanest > option. Yeah rejecting is always an ok thing if it just doesn't work. -Daniel --
Re: [RFC PATCH 3/5] drm/amdgpu: Allow explicit sync for VM ops.
[Back from vacations and work change and out sick and absolutely everything else going wrong] On Mon, Jul 04, 2022 at 03:37:43PM +0200, Christian König wrote: > Hey Daniel, > > Am 26.06.22 um 00:45 schrieb Daniel Vetter: > > [SNIP] > > I think we should highlight a bit more that for explicitly synchronized > > userspace like vk OTHER is the normal case. So really not an exception. > > Ofc aside from amdkgf there's currently no driver doing this, but really > > we should have lots of them ... > > > > See > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Fdri-devel%2FYZ%2By%2BUwo809qtvs5%40phenom.ffwll.local%2Fdata=05%7C01%7Cchristian.koenig%40amd.com%7C88037a566a8d4c8d4aca08da56fc6e3c%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637917939428739923%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=6sYto7GCLw8i3pT9OCFN1l6dxeYYHPghzKDMYxqUw90%3Dreserved=0 > > > > I didn't find anything else. So not sure how we managed to create > > confusion here :-( > > Well you said something like "Yeah, READ is supposed to be used for > that" and that created the impression that AMDGPU should start using > that for Vulkan submissions and you are rejecting my idea of using BOOKKEEP > for that. > > > > I mean that still makes a lot of sense to me because if I'm not completely > > > mistaken we do have use cases which break, especially Vulkan+encoding. > > Yeah I think we only have some communication fumble here, nothing else :-) > > Ok, well then @Bas: Sorry for all the noise, we are actually all on the same > page :) > > > And yes libva doesn't have any support for vk's explicit sync model, so > > that will just fall flat on its face. Might motivate a few folks to fix > > libva :-) > > Well that's not the problem. The problem is that we have a couple of use > cases where libva is supposed to encode a Vulkan surface without letting > Vulkan know about that. > > In other words: Application shares DMA-buf between Vulkan and VA-API, > renders with Vulkan and encodes with VA-API without any explicit > synchronization between the two. > > I know that this is absolutely against the Vulkan specification, but it just > happened to work fine. And when you break something which used to work > people start to complain... Yeah I feared that, and worse libva doesn't have the nice gl interop extensions to make it actually work. > > Note that on i915 side it's exactly the same, we've also been setting the > > READ fence thus far. Since the breakage will be introduced by upgrading > > mesa we'll at least avoid the kernel regression complaints, or at least I > > hope we can get away with that. > > Yeah, the path to salvation start's with the words: It's not my f... problem > :) > > > Since really I don't have any idea how it could be fixed otherwise, except > > through some really, really terrible hacks. Maybe kernel module option or > > so. > > > > Anyway I think all we need is just a patch to the dma_resv docs to explain > > that USAGE_BOOKKEEPING is what vulkan userspace wants, and why. Bas, > > you're up to typing that? > > I can do that. I'm just back from a week of vacation and still digging > through my mails. Yeah I think the best path is we're pushing hard for adding the libva syncobj extensions like gl has, so that this can be done properly. And then just pave it over with kernel modoptions until userspace is fixed. If we end up making implicit sync part of defacto vk api on linux, then a _lot_ of people will be very sad :-( -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: New subsystem for acceleration devices
On Tue, Aug 09, 2022 at 02:46:36PM +0200, Arnd Bergmann wrote: > On Tue, Aug 9, 2022 at 2:18 PM Jason Gunthorpe wrote: > > On Tue, Aug 09, 2022 at 10:32:27AM +0200, Arnd Bergmann wrote: > > > On Tue, Aug 9, 2022 at 10:04 AM Christoph Hellwig > > > wrote: > > > > > > I think for devices with hardware MMU contexts you actually want to > > > bind the context to a 'mm_struct', and then ensure that the context > > > is only ever used from a process that shares this mm_struct, > > > regardless of who else has access to the same file or inode. > > > > I can't think of a security justification for this. > > > > If process A stuffs part of its address space into the device and > > passes the FD to process B which can then access that addresss space, > > how is it any different from process A making a tmpfs, mmaping it, and > > passing it to process B which can then access that address space? > > > > IMHO the 'struct file' is the security domain and a process must be > > careful to only allow FDs to be created that meet its security needs. > > > > The kernel should not be involved in security here any further than > > using the standard FD security mechanisms. > > > > Who is to say there isn't a meaningful dual process use case for the > > accelerator? We see dual-process designs regularly in networking > > accelerators. > > I think there is a lot of value in keeping things simple here, to > make sure users and developers don't make a mess of it. I don't think the kernel should enforce policy on userspace. As long as the kernel side is simple and reasonable then it should let userspace make whatever mess it likes. We have a lot of experiance here now, and userspaces do take advantage of this flexability in more well established accelerator subsystems, like DRM and RDMA. > If the accelerator has access to the memory of one process but I run > it from another process, I lose the benefits of the shared page > tables, There are several accelerator "ASID" models I've seen - devices can have one or many ASID's and the ASID's can be map/unmap style or forced 1:1 with a mm_struct (usually called SVA/SVM). Userspace is responsible to figure out how to use this stuff. With map/unmap there should be no kernel restriction on what mappings can be created, but often sane userspaces will probably want to stick to 1:1 map/unmap with a single process. > E.g. attaching a debugger to single-step through the accelerator code > would then involve at least four address spaces: > > - the addresses of the debugger > - the addresses local to the accelerator > - addresses in the shared address space of the process that owns >the memory > - addresses in the process that owns the accelerator context > > which is at least one more than I'd like to deal with. It is a FD. There is no "owns the accelerator context" - that concept is an abuse of the FD model, IMHO. If you are debugging you have the mmu_struct of each of the threads you are debugging and each of the ASID's loaded in the accelerator to deal with - it is inherent in the hardware design. > This is somewhat different for accelerators that have coherent > access to a process address space and only access explicitly > shared buffers. On these you could more easily allow sharing the > file descriptor between any number of processes. That is just a multi-ASID accelerator and userspace has linked a unique SVA ASID to each unique process using the FD. The thing to understand is that the FD represents the security context, so it is very resonable on a multi-ASID device I could share the same security context with two co-operating processes, create two ASID's and do accelerator operations that work jointly across both memory spaces. For instance I might consume a source from process B, process it and deliver the result into process A where process A will then send it over the network or something. We have these kinds of use models already. Jason
Re: [EXT] Re: [PATCH 1/3] dma-buf: heaps: add Linaro secure dmabuf heap support
Hi Brian,
> > +
> > + rmem->ops = _dma_ops;
> > + pr_info("Reserved memory: DMA buf secure pool %s at
> > %pa, size %ld MiB\n",
> > + secure_data[secure_data_count].name,
> > + >base, (unsigned long)rmem->size /
> > SZ_1M);
>
> nit: What if rmem->size < SZ_1M, or not 1M-aligned
>
Let's assume that size is 1K-aligned, maybe something like that could
be better ?
unsigned long mb = rmem->size >> 20;
unsigned long kb = (rmem->size & (SZ_1M - 1)) >> 10;
pr_info("Reserved memory: DMA buf secure pool %s at %pa, size
%ld MiB and %ld KiB",
secure_data[secure_data_count].name,
>base, mb, kb);
Cheers,
Olivier
Re: [PATCH] drivers:gpu:drm:amd:amdgpu:amdgpu_cs.c:fix a potential use-after-free
Am 28.07.22 um 14:12 schrieb Wentao_Liang:
in line 1535, "dma_fence_put(fence);" drop the reference to fence and may
cause fence to be released. However, fence is used subsequently in line
1542 "fence->error". This may result in an use-after-free bug.
It can be fixed by recording fence->error in a variable before dropping
the reference to fence and referencing it after dropping.
The bug has been confirmed by Christian König on 2021-08-16. Now, I
resend this patch with my real name. I hope the patch can be updated
in a near future.
The subject line should be something like "drm/amdgpu: fix potential use
after free".
Signed-off-by: Wentao_Liang
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index b28af04b0c3e..1d675a5838f2 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -1518,7 +1518,7 @@ static int amdgpu_cs_wait_all_fences(struct amdgpu_device
*adev,
struct drm_amdgpu_fence *fences)
{
uint32_t fence_count = wait->in.fence_count;
- unsigned int i;
+ unsigned int i, error;
long r = 1;
for (i = 0; i < fence_count; i++) {
@@ -1533,14 +1533,15 @@ static int amdgpu_cs_wait_all_fences(struct
amdgpu_device *adev,
r = dma_fence_wait_timeout(fence, true, timeout);
dma_fence_put(fence);
+ error = fence->error;
That's still the wrong order, you need to get the fence error before
dropping the reference.
Christian.
if (r < 0)
return r;
if (r == 0)
break;
- if (fence->error)
- return fence->error;
+ if (error)
+ return error;
}
memset(wait, 0, sizeof(*wait));
Re: [PATCH v7 07/13] mfd: mt6370: Add MediaTek MT6370 support
On Fri, 05 Aug 2022, ChiaEn Wu wrote: > From: ChiYuan Huang > > This adds support for the MediaTek MT6370 SubPMIC. MediaTek MT6370 is a > SubPMIC consisting of a single cell battery charger with ADC monitoring, > RGB LEDs, dual channel flashlight, WLED backlight driver, display bias > voltage supply, one general purpose LDO, and the USB Type-C & PD controller > complies with the latest USB Type-C and PD standards. > > Reviewed-by: Andy Shevchenko > Signed-off-by: ChiYuan Huang > Signed-off-by: ChiaEn Wu > --- > > v7 > - Move '#define MT6370_REG_MAXADDR' to the next line of > '#define MT6370_REG_CHG_MASK1' > - Rename 'MT6370_REG_ADDRLEN' to 'MT6370_MAX_ADDRLEN' > --- > drivers/mfd/Kconfig | 16 +++ > drivers/mfd/Makefile | 1 + > drivers/mfd/mt6370.c | 312 > +++ > drivers/mfd/mt6370.h | 99 > 4 files changed, 428 insertions(+) > create mode 100644 drivers/mfd/mt6370.c > create mode 100644 drivers/mfd/mt6370.h Applied, thanks. -- DEPRECATED: Please use l...@kernel.org
Re: [PATCH v7 06/13] dt-bindings: mfd: Add MediaTek MT6370
On Fri, 05 Aug 2022, ChiaEn Wu wrote: > From: ChiYuan Huang > > Add MediaTek MT6370 binding documentation. > > Reviewed-by: Krzysztof Kozlowski > Signed-off-by: ChiYuan Huang > Signed-off-by: ChiaEn Wu > --- > .../devicetree/bindings/mfd/mediatek,mt6370.yaml | 280 > + > include/dt-bindings/iio/adc/mediatek,mt6370_adc.h | 18 ++ > 2 files changed, 298 insertions(+) > create mode 100644 Documentation/devicetree/bindings/mfd/mediatek,mt6370.yaml > create mode 100644 include/dt-bindings/iio/adc/mediatek,mt6370_adc.h Applied, thanks. -- DEPRECATED: Please use l...@kernel.org
Re: New subsystem for acceleration devices
On Tue, Aug 9, 2022 at 2:18 PM Jason Gunthorpe wrote: > On Tue, Aug 09, 2022 at 10:32:27AM +0200, Arnd Bergmann wrote: > > On Tue, Aug 9, 2022 at 10:04 AM Christoph Hellwig > > wrote: > > > > I think for devices with hardware MMU contexts you actually want to > > bind the context to a 'mm_struct', and then ensure that the context > > is only ever used from a process that shares this mm_struct, > > regardless of who else has access to the same file or inode. > > I can't think of a security justification for this. > > If process A stuffs part of its address space into the device and > passes the FD to process B which can then access that addresss space, > how is it any different from process A making a tmpfs, mmaping it, and > passing it to process B which can then access that address space? > > IMHO the 'struct file' is the security domain and a process must be > careful to only allow FDs to be created that meet its security needs. > > The kernel should not be involved in security here any further than > using the standard FD security mechanisms. > > Who is to say there isn't a meaningful dual process use case for the > accelerator? We see dual-process designs regularly in networking > accelerators. I think there is a lot of value in keeping things simple here, to make sure users and developers don't make a mess of it. If the accelerator has access to the memory of one process but I run it from another process, I lose the benefits of the shared page tables, but gain a lot of the complexity that I think the 'single-opener' logic was trying (without success) to avoid. E.g. attaching a debugger to single-step through the accelerator code would then involve at least four address spaces: - the addresses of the debugger - the addresses local to the accelerator - addresses in the shared address space of the process that owns the memory - addresses in the process that owns the accelerator context which is at least one more than I'd like to deal with. This is somewhat different for accelerators that have coherent access to a process address space and only access explicitly shared buffers. On these you could more easily allow sharing the file descriptor between any number of processes. Arnd
Re: New subsystem for acceleration devices
On Mon, Aug 08, 2022 at 11:26:11PM +0300, Oded Gabbay wrote: > So if you want a common uAPI and a common userspace library to use it, > you need to expose the same device character files for every device, > regardless of the driver. e.g. you need all devices to be called > /dev/accelX and not /dev/habanaX or /dev/nvidiaX So, this is an interesting idea. One of the things we did in RDMA that turned our very well is to have the user side of the kernel/user API in a single git repo for all the drivers, including the lowest layer of the driver-specific APIs. It gives a reasonable target for a DRM-like test of "you must have a userspace". Ie send your userspace and userspace documentation/tests before your kernel side can be merged. Even if it is just a git repo collecting and curating driver-specific libraries under the "accel" banner it could be quite a useful activity. But, probably this boils down to things that look like: device = habana_open_device() habana_mooo(device) device = nvidia_open_device() nvidia_baaa(device) > That's what I mean by abstracting all this kernel API from the > drivers. Not because it is an API that is hard to use, but because the > drivers should *not* use it at all. > > I think drm did that pretty well. Their code defines objects for > driver, device and minors, with resource manager that will take care > of releasing the objects automatically (it is based on devres.c). We have lots of examples of subsystems doing this - the main thing unique about accel is that that there is really no shared uAPI between the drivers, and not 'abstraction' provided by the kernel. Maybe that is the point.. > So actually I do want an ioctl but as you said, not for the main > device char, but to an accompanied control device char. There is a general problem across all these "thick" devices in the kernel to support their RAS & configuration requirements and IMHO we don't have a good answer at all. We've been talking on and off here about having some kind of subsystem/methodology specifically for this area - how to monitor, configure, service, etc a very complicated off-CPU device. I think there would be a lot of interest in this and maybe it shouldn't be coupled to this accel idea. Eg we already have some established mechinisms - I would expect any accel device to be able to introspect and upgrade its flash FW using the 'devlink flash' common API. > an application only has access to the information ioctl through this > device char (so it can't submit anything, allocate memory, etc.) and > can only retrieve metrics which do not leak information about the > compute application. This is often being done over a netlink socket as the "second char" Jason
Re: [Linaro-mm-sig] [PATCH v2 2/5] drm/gem: Take reservation lock for vmap/vunmap operations
Am 25.07.22 um 17:18 schrieb Dmitry Osipenko:
The new common dma-buf locking convention will require buffer importers
to hold the reservation lock around mapping operations. Make DRM GEM core
to take the lock around the vmapping operations and update QXL and i915
drivers to use the locked functions for the case where DRM core now holds
the lock. This patch prepares DRM core and drivers to transition to the
common dma-buf locking convention where vmapping of exported GEMs will
be done under the held reservation lock.
Signed-off-by: Dmitry Osipenko
Reviewed-by: Christian König
---
drivers/gpu/drm/drm_client.c | 4 ++--
drivers/gpu/drm/drm_gem.c| 24
drivers/gpu/drm/drm_gem_framebuffer_helper.c | 6 ++---
drivers/gpu/drm/drm_prime.c | 4 ++--
drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 2 +-
drivers/gpu/drm/qxl/qxl_object.c | 17 +++---
drivers/gpu/drm/qxl/qxl_prime.c | 4 ++--
include/drm/drm_gem.h| 3 +++
8 files changed, 46 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/drm_client.c b/drivers/gpu/drm/drm_client.c
index af3b7395bf69..e9a1cd310352 100644
--- a/drivers/gpu/drm/drm_client.c
+++ b/drivers/gpu/drm/drm_client.c
@@ -323,7 +323,7 @@ drm_client_buffer_vmap(struct drm_client_buffer *buffer,
* fd_install step out of the driver backend hooks, to make that
* final step optional for internal users.
*/
- ret = drm_gem_vmap(buffer->gem, map);
+ ret = drm_gem_vmap_unlocked(buffer->gem, map);
if (ret)
return ret;
@@ -345,7 +345,7 @@ void drm_client_buffer_vunmap(struct drm_client_buffer *buffer)
{
struct iosys_map *map = >map;
- drm_gem_vunmap(buffer->gem, map);
+ drm_gem_vunmap_unlocked(buffer->gem, map);
}
EXPORT_SYMBOL(drm_client_buffer_vunmap);
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index eb0c2d041f13..8b92846112ef 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -1171,6 +1171,8 @@ int drm_gem_vmap(struct drm_gem_object *obj, struct
iosys_map *map)
{
int ret;
+ dma_resv_assert_held(obj->resv);
+
if (!obj->funcs->vmap)
return -EOPNOTSUPP;
@@ -1186,6 +1188,8 @@ EXPORT_SYMBOL(drm_gem_vmap);
void drm_gem_vunmap(struct drm_gem_object *obj, struct iosys_map *map)
{
+ dma_resv_assert_held(obj->resv);
+
if (iosys_map_is_null(map))
return;
@@ -1197,6 +1201,26 @@ void drm_gem_vunmap(struct drm_gem_object *obj, struct iosys_map *map)
}
EXPORT_SYMBOL(drm_gem_vunmap);
+int drm_gem_vmap_unlocked(struct drm_gem_object *obj, struct iosys_map *map)
+{
+ int ret;
+
+ dma_resv_lock(obj->resv, NULL);
+ ret = drm_gem_vmap(obj, map);
+ dma_resv_unlock(obj->resv);
+
+ return ret;
+}
+EXPORT_SYMBOL(drm_gem_vmap_unlocked);
+
+void drm_gem_vunmap_unlocked(struct drm_gem_object *obj, struct iosys_map *map)
+{
+ dma_resv_lock(obj->resv, NULL);
+ drm_gem_vunmap(obj, map);
+ dma_resv_unlock(obj->resv);
+}
+EXPORT_SYMBOL(drm_gem_vunmap_unlocked);
+
/**
* drm_gem_lock_reservations - Sets up the ww context and acquires
* the lock on an array of GEM objects.
diff --git a/drivers/gpu/drm/drm_gem_framebuffer_helper.c
b/drivers/gpu/drm/drm_gem_framebuffer_helper.c
index 61339a9cd010..135cd4a96ea9 100644
--- a/drivers/gpu/drm/drm_gem_framebuffer_helper.c
+++ b/drivers/gpu/drm/drm_gem_framebuffer_helper.c
@@ -354,7 +354,7 @@ int drm_gem_fb_vmap(struct drm_framebuffer *fb, struct
iosys_map *map,
ret = -EINVAL;
goto err_drm_gem_vunmap;
}
- ret = drm_gem_vmap(obj, [i]);
+ ret = drm_gem_vmap_unlocked(obj, [i]);
if (ret)
goto err_drm_gem_vunmap;
}
@@ -376,7 +376,7 @@ int drm_gem_fb_vmap(struct drm_framebuffer *fb, struct
iosys_map *map,
obj = drm_gem_fb_get_obj(fb, i);
if (!obj)
continue;
- drm_gem_vunmap(obj, [i]);
+ drm_gem_vunmap_unlocked(obj, [i]);
}
return ret;
}
@@ -403,7 +403,7 @@ void drm_gem_fb_vunmap(struct drm_framebuffer *fb, struct
iosys_map *map)
continue;
if (iosys_map_is_null([i]))
continue;
- drm_gem_vunmap(obj, [i]);
+ drm_gem_vunmap_unlocked(obj, [i]);
}
}
EXPORT_SYMBOL(drm_gem_fb_vunmap);
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index b75ef1756873..1bd234fd21a5 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -678,7 +678,7 @@ int drm_gem_dmabuf_vmap(struct dma_buf *dma_buf, struct
iosys_map *map)
{
struct drm_gem_object *obj = dma_buf->priv;
- return
Re: New subsystem for acceleration devices
On Tue, Aug 09, 2022 at 10:32:27AM +0200, Arnd Bergmann wrote: > On Tue, Aug 9, 2022 at 10:04 AM Christoph Hellwig wrote: > > On Tue, Aug 09, 2022 at 08:23:27AM +0200, Greg Kroah-Hartman wrote: > > > > This is different from the number of FDs pointing at the struct file. > > > > Userpsace can open a HW state and point a lot of FDs at it, that is > > > > userspace's problem. From a kernel view they all share one struct file > > > > and thus one HW state. > > > > > > Yes, that's fine, if that is what is happening here, I have no > > > objection. > > > > It would be great if we could actually life that into a common > > layer (chardev or vfs) given just how common this, and drivers tend > > to get it wrong, do it suboptimal so often. > > Totally agreed. > > I think for devices with hardware MMU contexts you actually want to > bind the context to a 'mm_struct', and then ensure that the context > is only ever used from a process that shares this mm_struct, > regardless of who else has access to the same file or inode. I can't think of a security justification for this. If process A stuffs part of its address space into the device and passes the FD to process B which can then access that addresss space, how is it any different from process A making a tmpfs, mmaping it, and passing it to process B which can then access that address space? IMHO the 'struct file' is the security domain and a process must be careful to only allow FDs to be created that meet its security needs. The kernel should not be involved in security here any further than using the standard FD security mechanisms. Who is to say there isn't a meaningful dual process use case for the accelerator? We see dual-process designs regularly in networking accelerators. Jason
Re: [Linaro-mm-sig] [PATCH v2 1/5] dma-buf: Add _unlocked postfix to function names
Am 25.07.22 um 17:18 schrieb Dmitry Osipenko:
Add _unlocked postfix to the dma-buf API function names in a preparation
to move all non-dynamic dma-buf users over to the dynamic locking
specification. This patch only renames API functions, preparing drivers
to the common locking convention. Later on we will make the "unlocked"
functions to take the reservation lock.
Suggested-by: Christian König
Signed-off-by: Dmitry Osipenko
Could be that we later say we will remove the prefix again because some
functions should stay unlocked, but for now it makes it much clearer
what happens here.
This patch is Acked-by: Christian König
---
drivers/dma-buf/dma-buf.c | 76 ++-
drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 4 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 4 +-
drivers/gpu/drm/armada/armada_gem.c | 14 ++--
drivers/gpu/drm/drm_gem_cma_helper.c | 6 +-
drivers/gpu/drm/drm_gem_shmem_helper.c| 6 +-
drivers/gpu/drm/drm_prime.c | 12 +--
drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c | 6 +-
drivers/gpu/drm/exynos/exynos_drm_gem.c | 2 +-
drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c| 12 +--
.../drm/i915/gem/selftests/i915_gem_dmabuf.c | 20 ++---
drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c | 8 +-
drivers/gpu/drm/tegra/gem.c | 27 +++
drivers/infiniband/core/umem_dmabuf.c | 11 +--
.../common/videobuf2/videobuf2-dma-contig.c | 15 ++--
.../media/common/videobuf2/videobuf2-dma-sg.c | 12 +--
.../common/videobuf2/videobuf2-vmalloc.c | 6 +-
.../platform/nvidia/tegra-vde/dmabuf-cache.c | 12 +--
drivers/misc/fastrpc.c| 12 +--
drivers/xen/gntdev-dmabuf.c | 14 ++--
include/linux/dma-buf.h | 34 +
21 files changed, 161 insertions(+), 152 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 44574fbe7482..d16237a6ffaa 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -795,7 +795,7 @@ static struct sg_table * __map_dma_buf(struct
dma_buf_attachment *attach,
}
/**
- * dma_buf_dynamic_attach - Add the device to dma_buf's attachments list
+ * dma_buf_dynamic_attach_unlocked - Add the device to dma_buf's attachments
list
* @dmabuf: [in]buffer to attach device to.
* @dev: [in]device to be attached.
* @importer_ops: [in]importer operations for the attachment
@@ -817,9 +817,9 @@ static struct sg_table * __map_dma_buf(struct
dma_buf_attachment *attach,
* indicated with the error code -EBUSY.
*/
struct dma_buf_attachment *
-dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct device *dev,
- const struct dma_buf_attach_ops *importer_ops,
- void *importer_priv)
+dma_buf_dynamic_attach_unlocked(struct dma_buf *dmabuf, struct device *dev,
+ const struct dma_buf_attach_ops *importer_ops,
+ void *importer_priv)
{
struct dma_buf_attachment *attach;
int ret;
@@ -892,25 +892,25 @@ dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct
device *dev,
if (dma_buf_is_dynamic(attach->dmabuf))
dma_resv_unlock(attach->dmabuf->resv);
- dma_buf_detach(dmabuf, attach);
+ dma_buf_detach_unlocked(dmabuf, attach);
return ERR_PTR(ret);
}
-EXPORT_SYMBOL_NS_GPL(dma_buf_dynamic_attach, DMA_BUF);
+EXPORT_SYMBOL_NS_GPL(dma_buf_dynamic_attach_unlocked, DMA_BUF);
/**
- * dma_buf_attach - Wrapper for dma_buf_dynamic_attach
+ * dma_buf_attach_unlocked - Wrapper for dma_buf_dynamic_attach
* @dmabuf: [in]buffer to attach device to.
* @dev: [in]device to be attached.
*
- * Wrapper to call dma_buf_dynamic_attach() for drivers which still use a
static
- * mapping.
+ * Wrapper to call dma_buf_dynamic_attach_unlocked() for drivers which still
+ * use a static mapping.
*/
-struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf,
- struct device *dev)
+struct dma_buf_attachment *dma_buf_attach_unlocked(struct dma_buf *dmabuf,
+ struct device *dev)
{
- return dma_buf_dynamic_attach(dmabuf, dev, NULL, NULL);
+ return dma_buf_dynamic_attach_unlocked(dmabuf, dev, NULL, NULL);
}
-EXPORT_SYMBOL_NS_GPL(dma_buf_attach, DMA_BUF);
+EXPORT_SYMBOL_NS_GPL(dma_buf_attach_unlocked, DMA_BUF);
static void __unmap_dma_buf(struct dma_buf_attachment *attach,
struct sg_table *sg_table,
@@ -923,7 +923,7 @@ static void __unmap_dma_buf(struct dma_buf_attachment
*attach,
}
/**
- * dma_buf_detach - Remove the given attachment from dmabuf's attachments list
+ * dma_buf_detach_unlocked - Remove the given attachment from dmabuf's
attachments list
* @dmabuf: [in]
Re: [PATCH v5] drm/i915: stop using swiotlb
On 08/08/2022 16:48, Hellstrom, Thomas wrote:
Hi, [back from vacation]
On Tue, 2022-07-26 at 16:39 +0100, Robert Beckett wrote:
Calling swiotlb functions directly is nowadays considered harmful.
See
https://lore.kernel.org/intel-gfx/20220711082614.ga29...@lst.de/
Replace swiotlb_max_segment() calls with dma_max_mapping_size().
In i915_gem_object_get_pages_internal() no longer consider
max_segment
only if CONFIG_SWIOTLB is enabled. There can be other (iommu related)
causes of specific max segment sizes.
Cc: Christoph Hellwig
Cc: Tvrtko Ursulin
Cc: Thomas Hellstrom
Cc: Matthew Auld
v2: - restore UINT_MAX clamp in i915_sg_segment_size()
- drop PAGE_SIZE check as it will always be >= PAGE_SIZE
v3: - actually clamp to UINT_MAX in i915_sg_segment_size()
v4: - round down max segment size to PAGE_SIZE
v5: - fix checkpatch whitespace issue
Reviewed-by: Christoph Hellwig
Reviewed-by: Tvrtko Ursulin
Signed-off-by: Robert Beckett
Hmm,
This whole thing looks a bit strange to me since with SWIOTLB actually
used for i915, the driver should malfunction anyway as it doesn't do
any dma_sync_sg_for_cpu() or dma_sync_sg_for_device(), and the driver
assumes all coherent dma. Is that SWIOTLB=force kernel option still
available?
Don't know about these - but pretty sure in the past we had i915 break
if we did not respect swiotlb_max_segment.
Digging through git history at least running as Xen dom0 looks to have
been impacted, but commits such as abb0deacb5a6 ("drm/i915: Fallback to
single PAGE_SIZE segments for DMA remapping") are older and suggest
problem was generic. 1625e7e549c5 ("drm/i915: make compact dma scatter
lists creation work with SWIOTLB backend.") as well. So it looks it did
work behind swiotlb despite those missing calls you highlighted.
Also, correct me if I'm wrong, but the original driver segment size
appears to mean "the largest contiguous area that can be handled either
by the device or the dma mapping layer" rather than the total space
available for dma mappings? Not completely sure what
dma_max_mapping_size() is returning, though?
AFAIU looks to be compatible on paper at least.:
dma_max_mapping_size -> "Returns the maximum size of a mapping for the
device."
So an individual mapping.
But then in case of swiotlb is implemented in swiotlb_max_mapping_size,
and not the same code as swiotlb_max_segment. I agree, ideally if
someone could clarify they are returning the same thing or there is a
miss somewhere.
Regards,
Tvrtko
Re: [PATCH v2 11/39] drm/i915: i915_gem_ttm_pm.c: fix kernel-doc markups
On Wed, Jul 13, 2022 at 09:11:59AM +0100, Mauro Carvalho Chehab wrote: > The documentation for the flags field is missing there. It sounds > that some last-time change converted some bools into flags, but > the kernel-doc change didn't follow it. > > Fix those warnings: > > drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c:135: warning: Function > parameter or member 'flags' not described in 'i915_ttm_backup_region' > drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c:135: warning: Excess > function parameter 'allow_gpu' description in 'i915_ttm_backup_region' > drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c:135: warning: Excess > function parameter 'backup_pinned' description in 'i915_ttm_backup_region' > drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c:199: warning: Function > parameter or member 'flags' not described in 'i915_ttm_restore_region' > drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c:199: warning: Excess > function parameter 'allow_gpu' description in 'i915_ttm_restore_region' > > Signed-off-by: Mauro Carvalho Chehab Reviewed-by: Rodrigo Vivi > --- > > To avoid mailbombing on a large number of people, only mailing lists were C/C > on the cover. > See [PATCH v2 00/39] at: > https://lore.kernel.org/all/cover.1657699522.git.mche...@kernel.org/ > > drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c | 8 +--- > 1 file changed, 5 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c > b/drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c > index 9aad84059d56..9843831c9b37 100644 > --- a/drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c > +++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c > @@ -123,8 +123,9 @@ void i915_ttm_recover_region(struct intel_memory_region > *mr) > /** > * i915_ttm_backup_region - Back up all objects of a region to smem. > * @mr: The memory region > - * @allow_gpu: Whether to allow the gpu blitter for this backup. > - * @backup_pinned: Backup also pinned objects. > + * @flags: Bitmap field with the following flags: > + * %I915_TTM_BACKUP_ALLOW_GPU: allow the gpu blitter for this backup; > + * %I915_TTM_BACKUP_PINNED: backup also pinned objects. > * > * Loops over all objects of a region and either evicts them if they are > * evictable or backs them up using a backup object if they are pinned. > @@ -188,7 +189,8 @@ static int i915_ttm_restore(struct > i915_gem_apply_to_region *apply, > /** > * i915_ttm_restore_region - Restore backed-up objects of a region from smem. > * @mr: The memory region > - * @allow_gpu: Whether to allow the gpu blitter to recover. > + * @flags: Bitmap field with the following flags: > + * %I915_TTM_BACKUP_ALLOW_GPU: allow the gpu blitter for this backup; > * > * Loops over all objects of a region and if they are backed-up, restores > * them from smem. > -- > 2.36.1 >
Re: [Intel-gfx] [PATCH v2 35/39] docs: gpu: i915.rst: add the remaining kernel-doc markup files
On Wed, Jul 13, 2022 at 09:12:23AM +0100, Mauro Carvalho Chehab wrote: > There are other files with kernel-doc markups: > > $ git grep -l "/\*\*" $(git ls-files|grep drivers/gpu/drm/i915/) > >kernel-doc-files > $ for i in $(cat kernel-doc-files); do if [ "$(git grep $i > Documentation/)" == "" ]; then echo "$i"; fi; done >aaa > > Add them to i915.rst as well. > > Signed-off-by: Mauro Carvalho Chehab > --- > > To avoid mailbombing on a large number of people, only mailing lists were C/C > on the cover. > See [PATCH v2 00/39] at: > https://lore.kernel.org/all/cover.1657699522.git.mche...@kernel.org/ > > Documentation/gpu/i915.rst | 87 ++ > 1 file changed, 87 insertions(+) > > diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst > index 974754586be8..6bb50edc6d79 100644 > --- a/Documentation/gpu/i915.rst > +++ b/Documentation/gpu/i915.rst > @@ -13,6 +13,11 @@ Core Driver Infrastructure > This section covers core driver infrastructure used by both the display > and the GEM parts of the driver. > > +Core driver > +--- > + > +.. kernel-doc:: drivers/gpu/drm/i915/i915_driver.c > + > Runtime Power Management > > > @@ -29,6 +34,10 @@ Runtime Power Management > > .. kernel-doc:: drivers/gpu/drm/i915/intel_pm.c > > +.. kernel-doc:: drivers/gpu/drm/i915/intel_wakeref.h > + > +.. kernel-doc:: drivers/gpu/drm/i915/i915_active.h not sure if this belongs to this group... > + > Interrupt Handling > -- > > @@ -44,6 +53,28 @@ Interrupt Handling > .. kernel-doc:: drivers/gpu/drm/i915/i915_irq.c > :functions: intel_runtime_pm_enable_interrupts > > +Error handling > +-- > + > +.. kernel-doc:: drivers/gpu/drm/i915/i915_gpu_error.c not sure if this gt hang stuff deserves a separated section alone and if the name is the best one > + > +Memory Handling > +--- > + > +.. kernel-doc:: drivers/gpu/drm/i915/i915_vma_resource.h > + > +.. kernel-doc:: drivers/gpu/drm/i915/i915_vma_resource.c > + > +.. kernel-doc:: drivers/gpu/drm/i915/i915_vma.h > + > +.. kernel-doc:: drivers/gpu/drm/i915/i915_vma.c > + > +.. kernel-doc:: drivers/gpu/drm/i915/i915_mm.c > + > +.. kernel-doc:: drivers/gpu/drm/i915/intel_memory_region.c > + > +.. kernel-doc:: drivers/gpu/drm/i915/i915_memcpy.c > + > Intel GVT-g Guest Support(vGPU) ^ missing space > --- > > @@ -109,6 +140,54 @@ Workarounds > .. kernel-doc:: drivers/gpu/drm/i915/gt/intel_workarounds.c > :doc: Hardware workarounds > > +32-bits compatible ioctl Logic > +-- > + > +.. kernel-doc:: drivers/gpu/drm/i915/i915_ioc32.c > + > +Scatterlist handling > + > + > +.. kernel-doc:: drivers/gpu/drm/i915/i915_scatterlist.h > + > +.. kernel-doc:: drivers/gpu/drm/i915/i915_scatterlist.c > + > +i915 request > + > + > +.. kernel-doc:: drivers/gpu/drm/i915/i915_request.h > + > +.. kernel-doc:: drivers/gpu/drm/i915/i915_request.c > + > +Ancillary routines maybe simply have an "Others" section and put everything that has only one item like the gpu hang one? > +-- > + > +.. kernel-doc:: drivers/gpu/drm/i915/i915_deps.c > + > +.. kernel-doc:: drivers/gpu/drm/i915/i915_deps.h > + > +.. kernel-doc:: drivers/gpu/drm/i915/intel_device_info.c > + > +.. kernel-doc:: drivers/gpu/drm/i915/i915_params.c > + > +.. kernel-doc:: drivers/gpu/drm/i915/i915_sw_fence_work.h > + > +.. kernel-doc:: drivers/gpu/drm/i915/i915_syncmap.c > + > +.. kernel-doc:: drivers/gpu/drm/i915/intel_pcode.c > + > +.. kernel-doc:: drivers/gpu/drm/i915/i915_reg_defs.h > + > +.. kernel-doc:: drivers/gpu/drm/i915/intel_wopcm.h > + > + > +PXP Protected Xe Path (PXP) > +--- > + > +.. kernel-doc:: drivers/gpu/drm/i915/pxp/intel_pxp_irq.c > + > +.. kernel-doc:: drivers/gpu/drm/i915/pxp/intel_pxp_tee.c > + > Display Hardware Handling > = > > @@ -618,6 +697,12 @@ Protected Objects > Table Manager (TTM) > --- > > +.. kernel-doc:: drivers/gpu/drm/i915/i915_ttm_buddy_manager.h > + > +.. kernel-doc:: drivers/gpu/drm/i915/i915_ttm_buddy_manager.c > + > +.. kernel-doc:: drivers/gpu/drm/i915/intel_region_ttm.c > + > .. kernel-doc:: drivers/gpu/drm/i915/gem/i915_gem_ttm.c > > .. kernel-doc:: drivers/gpu/drm/i915/gem/i915_gem_ttm.h > @@ -627,6 +712,8 @@ Table Manager (TTM) > Graphics Execution Manager (GEM) > > > +.. kernel-doc:: drivers/gpu/drm/i915/i915_gem.c > + > .. kernel-doc:: drivers/gpu/drm/i915/gem/i915_gem_create.c > > .. kernel-doc:: drivers/gpu/drm/i915/gem/i915_gem_domain.c in many cases I see only the .h or only the .c... why is that? wouldn't be better already put both in all the cases? > -- > 2.36.1 >
Re: [Linaro-mm-sig] Re: [PATCH v2] drm/gem: Fix GEM handle release errors
Hi Jeffy, Am 09.08.22 um 12:02 schrieb Chen Jeffy: Hi Christian, On 8/9 星期二 17:08, Christian König wrote: Hi Jeffy, Am 09.08.22 um 09:55 schrieb Christian König: [SNIP] So we are allowing GEM object to have multiple handles, and GEM object could have at most one dma-buf, doesn't that means that dma-buf could map to multiple handles? No, at least not for the same GEM file private. That's the reason why the rb is indexed by the dma_buf object and not the handle. In other words the rb is so that you have exactly one handle for each dma_buf in each file private. I don't think so, because if user get multiple handles for the same GEM obj and use drm_gem_prime_handle_to_fd() for those handles Mhm, that works? This is illegal and should have been prevented somehow. At least I see the problem now. I'm just not sure how to fix it. Your v2 patch indeed prevents leakage of the drm_prime_member for the additional handles, but those shouldn't have been added in the first place. The issue is that with this we make it unpredictable which handle is returned. E.g. if we have handle 2,5,7 it can be that because of re-balancing the tree sometimes 2 and sometimes 5 is returned. Maybe cache the latest returned handle in the obj(after drm_gem_prime_fd_to_handle), and clear it when that handle been deleted in drm_gem_handle_delete()? That won't work. The handle is per fpriv, but the same object is used by multiple fpriv instances. What we could maybe do is to prevent adding multiple lockup structures when there is already one, but that's not something I can easily judge. Daniel seems to be either very busy or on vacation otherwise he would have chimed in by now. Anyway, your patch seems to at least fix the of hand memory leak, so feel free to add my rb to the v2 and push it to drm-misc-fixes for now. Thanks, Christian. Something like: drm_gem_prime_fd_to_handle handle = drm_prime_lookup_buf_handle(buf) obj = obj_from_handle(handle) if !obj->primary_handle obj->primary_handle = handle return obj->primary_handle Or maybe limit GEM obj with a single lifetime handle? That's not really a good idea and breaks a couple of assumptions as far as I know. Ideas? Thanks, Christian.
Re: [PATCH v2 39/39] drm/i915: add GuC functions to the documentation
On Wed, Jul 13, 2022 at 09:12:27AM +0100, Mauro Carvalho Chehab wrote: > Currently, functions inside GuC aren't presented as part of the > GuC documentation. > > Add them. > > Signed-off-by: Mauro Carvalho Chehab could be squashed to the other guc patch, but anyways: Reviewed-by: Rodrigo Vivi > --- > > To avoid mailbombing on a large number of people, only mailing lists were C/C > on the cover. > See [PATCH v2 00/39] at: > https://lore.kernel.org/all/cover.1657699522.git.mche...@kernel.org/ > > Documentation/gpu/i915.rst | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst > index 9862d504df4d..8c21a90d8b5a 100644 > --- a/Documentation/gpu/i915.rst > +++ b/Documentation/gpu/i915.rst > @@ -768,6 +768,9 @@ GuC > > .. kernel-doc:: drivers/gpu/drm/i915/gt/uc/intel_guc.h > > +.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/intel_guc.c > + :internal: > + > .. kernel-doc:: drivers/gpu/drm/i915/gt/uc/abi/guc_actions_slpc_abi.h > > .. kernel-doc:: drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c > -- > 2.36.1 >
Re: [PATCH v2 31/39] docs: gpu: i915.rst: GuC: add more kernel-doc markups
On Wed, Jul 13, 2022 at 09:12:19AM +0100, Mauro Carvalho Chehab wrote: > There are several documented GuC kAPI that aren't currently part > of the docs. Add them, as this allows identifying issues with > badly-formatted tags. > > Signed-off-by: Mauro Carvalho Chehab Reviewed-by: Rodrigo Vivi > --- > > To avoid mailbombing on a large number of people, only mailing lists were C/C > on the cover. > See [PATCH v2 00/39] at: > https://lore.kernel.org/all/cover.1657699522.git.mche...@kernel.org/ > > Documentation/gpu/i915.rst | 22 ++ > 1 file changed, 22 insertions(+) > > diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst > index afd8c0e3c689..70f2f4826eba 100644 > --- a/Documentation/gpu/i915.rst > +++ b/Documentation/gpu/i915.rst > @@ -596,6 +596,28 @@ GuC > > .. kernel-doc:: drivers/gpu/drm/i915/gt/uc/intel_guc.h > > +.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/abi/guc_actions_slpc_abi.h > + > +.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c > + > +.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h > + > +.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c > + > +.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c > + > +.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/intel_guc_log.c > + > +.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c > + > +.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c > + > +.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/intel_uc.c > + > +.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h > + > +.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c > + > GuC Firmware Layout > ~~~ > > -- > 2.36.1 >
Re: [Intel-gfx] [PATCH v2 38/39] drm/i915: add descriptions for some RPM macros at intel_gt_pm.h
On Wed, Jul 13, 2022 at 09:12:26AM +0100, Mauro Carvalho Chehab wrote:
> The intel_gt_pm.h file contains some convenient macros to be used
> in GT code in order to get/put runtime PM references and for
> checking them.
>
> Add descriptions based on the ones at intel_wakeref.h and
> intel_runtime_pm.c.
>
> Signed-off-by: Mauro Carvalho Chehab
> ---
>
> To avoid mailbombing on a large number of people, only mailing lists were C/C
> on the cover.
> See [PATCH v2 00/39] at:
> https://lore.kernel.org/all/cover.1657699522.git.mche...@kernel.org/
>
> Documentation/gpu/i915.rst| 2 +
> drivers/gpu/drm/i915/gt/intel_gt_pm.h | 62 +++
> 2 files changed, 64 insertions(+)
>
> diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
> index 6bb50edc6d79..9862d504df4d 100644
> --- a/Documentation/gpu/i915.rst
> +++ b/Documentation/gpu/i915.rst
> @@ -709,6 +709,8 @@ Table Manager (TTM)
>
> .. kernel-doc:: drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
>
> +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_gt_pm.h
I don't believe this is the right placement for this.
the rest lgtm
> +
> Graphics Execution Manager (GEM)
>
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm.h
> b/drivers/gpu/drm/i915/gt/intel_gt_pm.h
> index bc898df7a48c..a8ea6846980a 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_pm.h
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_pm.h
> @@ -11,21 +11,57 @@
> #include "intel_gt_types.h"
> #include "intel_wakeref.h"
>
> +/**
> + * intel_gt_pm_is_awake: Query whether the runtime PM is awake held
> + *
> + * @gt: pointer to the graphics engine
> + *
> + * Returns: true if a runtime pm reference is currently held and the GT is
> + * awake.
> + */
> static inline bool intel_gt_pm_is_awake(const struct intel_gt *gt)
> {
> return intel_wakeref_is_active(>wakeref);
> }
>
> +/**
> + * intel_gt_pm_get: grab a runtime PM reference ensuring that GT is powered
> up
> + * @gt: pointer to the graphics engine
> + *
> + * Any runtime pm reference obtained by this function must have a symmetric
> + * call to intel_gt_pm_put() to release the reference again.
> + *
> + * Note that this is allowed to fail, in which case the runtime-pm wakeref
> + * will be released and the acquisition unwound.
> + */
> static inline void intel_gt_pm_get(struct intel_gt *gt)
> {
> intel_wakeref_get(>wakeref);
> }
>
> +/**
> + * __intel_gt_pm_get: Acquire the runtime PM reference again
> + * @gt: pointer to the graphics engine which contains the wakeref
> + *
> + * Increment the PM reference counter, only valid if it is already held by
> + * the caller.
> + *
> + * See intel_gt_pm_get().
> + */
> static inline void __intel_gt_pm_get(struct intel_gt *gt)
> {
> __intel_wakeref_get(>wakeref);
> }
>
> +/**
> + * intel_gt_pm_get_if_awake: Acquire the runtime PM reference if active
> + * @gt: pointer to the graphics engine which contains the PM reference
> + *
> + * Acquire a hold on the PM reference, but only if the GT is already
> + * active.
> + *
> + * Returns: true if the wakeref was acquired, false otherwise.
> + */
> static inline bool intel_gt_pm_get_if_awake(struct intel_gt *gt)
> {
> return intel_wakeref_get_if_active(>wakeref);
> @@ -36,6 +72,14 @@ static inline void intel_gt_pm_might_get(struct intel_gt
> *gt)
> intel_wakeref_might_get(>wakeref);
> }
>
> +/**
> + * intel_gt_pm_put: Release the runtime PM reference
> + * @gt: pointer to the graphics engine which contains the PM reference
> + *
> + * Release our hold on the runtime PM for GT.
> + *
> + * It might power down the GT right away if this is the last reference.
> + */
> static inline void intel_gt_pm_put(struct intel_gt *gt)
> {
> intel_wakeref_put(>wakeref);
> @@ -51,10 +95,28 @@ static inline void intel_gt_pm_might_put(struct intel_gt
> *gt)
> intel_wakeref_might_put(>wakeref);
> }
>
> +/**
> + * with_intel_gt_pm - get a GT reference ensuring that GT is powered up,
> + * run some code and then put the reference away.
> + *
> + * @gt: pointer to the gt
> + * @tmp: pointer to a temporary wakeref.
> + */
> #define with_intel_gt_pm(gt, tmp) \
> for (tmp = 1, intel_gt_pm_get(gt); tmp; \
>intel_gt_pm_put(gt), tmp = 0)
>
> +/**
> + * intel_gt_pm_wait_for_idle: Wait until the runtime PM reference is idle
> + * @gt: pointer to the graphics engine which contains the PM reference
> + *
> + * Wait for the earlier asynchronous release of the runtime PM reference.
> Note
> + * this will wait for any third party as well, so make sure you only wait
> + * when you have control over the GT runtime PM and trust no one else is
> + * acquiring it.
> + *
> + * Return: 0 on success, error code if killed.
> + */
> static inline int intel_gt_pm_wait_for_idle(struct intel_gt *gt)
> {
> return intel_wakeref_wait_for_idle(>wakeref);
> --
> 2.36.1
>
Re: [PATCH v2 36/39] drm/i915 i915_gem_object_types.h: document struct i915_lut_handle
On Wed, Jul 13, 2022 at 09:12:24AM +0100, Mauro Carvalho Chehab wrote:
> commit d1b48c1e7184 ("drm/i915: Replace execbuf vma ht with an idr")
> added a rbtree list to allow searching for obj/ctx.
>
> Document it.
>
> Signed-off-by: Mauro Carvalho Chehab
Reviewed-by: Rodrigo Vivi
> ---
>
> To avoid mailbombing on a large number of people, only mailing lists were C/C
> on the cover.
> See [PATCH v2 00/39] at:
> https://lore.kernel.org/all/cover.1657699522.git.mche...@kernel.org/
>
> drivers/gpu/drm/i915/gem/i915_gem_object_types.h | 12 +---
> 1 file changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> index 5cf36a130061..ceed0d220ce3 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> @@ -21,9 +21,15 @@ struct drm_i915_gem_object;
> struct intel_fronbuffer;
> struct intel_memory_region;
>
> -/*
> - * struct i915_lut_handle tracks the fast lookups from handle to vma used
> - * for execbuf. Although we use a radixtree for that mapping, in order to
> +/**
> + * struct i915_lut_handle - tracks the fast lookups from handle to vma used
> + * for execbuf.
> + *
> + * @obj_link: link to the object associated with the @handle.
> + * @ctx: context associated with the @handle.
> + * @handle: a rbtree handle to lookup context for specific obj/vma.
> + *
> + * Although we use a radixtree for that mapping, in order to
> * remove them as the object or context is closed, we need a secondary list
> * and a translation entry (i915_lut_handle).
> */
> --
> 2.36.1
>
Re: [Intel-gfx] [PATCH v2 37/39] drm/i915: document struct drm_i915_gem_object
On Wed, Jul 13, 2022 at 09:12:25AM +0100, Mauro Carvalho Chehab wrote:
> This is a large struct used to describe gem objects. It is
> currently partially documented. Finish its documentation, filling
> the gaps from git logs.
>
> Signed-off-by: Mauro Carvalho Chehab
Reviewed-by: Rodrigo Vivi
> ---
>
> To avoid mailbombing on a large number of people, only mailing lists were C/C
> on the cover.
> See [PATCH v2 00/39] at:
> https://lore.kernel.org/all/cover.1657699522.git.mche...@kernel.org/
>
> .../gpu/drm/i915/gem/i915_gem_object_types.h | 200 ++
> 1 file changed, 158 insertions(+), 42 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> index ceed0d220ce3..8c09e493590d 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> @@ -233,6 +233,9 @@ struct i915_gem_object_page_iter {
> struct mutex lock; /* protects this cache */
> };
>
> +/**
> + * struct drm_i915_gem_object - describes an i915 GEM object
> + */
> struct drm_i915_gem_object {
> /*
>* We might have reason to revisit the below since it wastes
> @@ -241,12 +244,16 @@ struct drm_i915_gem_object {
>* when accessing it.
>*/
> union {
> + /** @base: GEM base object */
> struct drm_gem_object base;
> + /** @__do_not_access: TTM buffer object */
> struct ttm_buffer_object __do_not_access;
> };
>
> + /** @ops: pointer to GEM object ops */
> const struct drm_i915_gem_object_ops *ops;
>
> + /** @vma: struct containing VMA list, tree and lock */
> struct {
> /**
>* @vma.lock: protect the list/tree of vmas
> @@ -280,10 +287,12 @@ struct drm_i915_gem_object {
>*
>* If this object is closed, we need to remove all of its VMA from
>* the fast lookup index in associated contexts; @lut_list provides
> - * this translation from object to context->handles_vma.
> + * this translation from object to ``context->handles_vma``.
>*/
> struct list_head lut_list;
> - spinlock_t lut_lock; /* guards lut_list */
> +
> + /** @lut_lock: guards @lut_list */
> + spinlock_t lut_lock;
>
> /**
>* @obj_link: Link into @i915_gem_ww_ctx.obj_list
> @@ -294,42 +303,88 @@ struct drm_i915_gem_object {
>*/
> struct list_head obj_link;
> /**
> - * @shared_resv_from: The object shares the resv from this vm.
> + * @shares_resv_from: The object shares the resv from this vm.
>*/
> struct i915_address_space *shares_resv_from;
>
> union {
> + /** @rcu: head used when freeing objects with RCU */
> struct rcu_head rcu;
> + /** @freed: list of GEM freed objects */
> struct llist_node freed;
> };
>
> /**
> - * Whether the object is currently in the GGTT mmap.
> + * @userfault_count: a value bigger than zero means that the object
> + * was mmapped into userspace.
> + *
> + * Used when the object is currently in the GGTT mmap.
>*/
> unsigned int userfault_count;
> + /**
> + * @userfault_link: list of all objects that were
> + * mmapped into userspace.
> + *
> + * Used when the object is currently in the GGTT mmap.
> + */
> struct list_head userfault_link;
>
> + /** @mmo: struct containing mmo offsets and lock */
> struct {
> - spinlock_t lock; /* Protects access to mmo offsets */
> + /** @mmo.lock: protects access to @mmo.offsets */
> + spinlock_t lock;
> + /** @mmo.offsets: rbtree list of mmo offsets */
> struct rb_root offsets;
> } mmo;
>
> + /* private: used on selftest only */
> I915_SELFTEST_DECLARE(struct list_head st_link);
> + /* public: */
>
> + /**
> + * @flags: object flags. Current flags are:
> + *
> + * %I915_BO_ALLOC_CONTIGUOUS:
> + * Object requires to be allocated as a contiguous block
> + * %I915_BO_ALLOC_VOLATILE:
> + * Volatile objects are marked as %DONTNEED while pinned, therefore
> + * once unpinned the backing store can be discarded.
> + * This is limited to kernel internal objects.
> + * %I915_BO_ALLOC_CPU_CLEAR:
> + * Some internal device local-memory objects may have an option
> + * to CPU clear the pages upon gathering the backing store.
> + * Note that this might be before the blitter is usable, which
> + * is the case for some internal GuC objects.
> + * %I915_BO_ALLOC_USER:
> + * Make sure the object is cleared before any user access.
> + * %I915_BO_ALLOC_PM_VOLATILE:
> + * Object is allowed to lose its contents on suspend / resume,
> + *
Re: [Intel-gfx] [PATCH v2 33/39] docs: gpu: i915.rst: PM: add more kernel-doc markups
On Wed, Jul 13, 2022 at 09:12:21AM +0100, Mauro Carvalho Chehab wrote: > Both intel_runtime_pm.h and intel_pm.c contains kAPI for > runtime PM. So, add them to the documentation. > > Signed-off-by: Mauro Carvalho Chehab Reviewed-by: Rodrigo Vivi > --- > > To avoid mailbombing on a large number of people, only mailing lists were C/C > on the cover. > See [PATCH v2 00/39] at: > https://lore.kernel.org/all/cover.1657699522.git.mche...@kernel.org/ > > Documentation/gpu/i915.rst | 4 > 1 file changed, 4 insertions(+) > > diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst > index 3ee121a0ea62..c32409c03d32 100644 > --- a/Documentation/gpu/i915.rst > +++ b/Documentation/gpu/i915.rst > @@ -25,6 +25,10 @@ Runtime Power Management > .. kernel-doc:: drivers/gpu/drm/i915/intel_uncore.c > :internal: > > +.. kernel-doc:: drivers/gpu/drm/i915/intel_runtime_pm.h > + > +.. kernel-doc:: drivers/gpu/drm/i915/intel_pm.c > + > Interrupt Handling > -- > > -- > 2.36.1 >
Re: [Intel-gfx] [PATCH v2 34/39] docs: gpu: i915.rst: GEM/TTM: add more kernel-doc markups
On Wed, Jul 13, 2022 at 09:12:22AM +0100, Mauro Carvalho Chehab wrote: > There are several documented GEM/TTM kAPI that aren't currently part > of the docs. Add them, as this allows identifying issues with > badly-formatted tags. > > Signed-off-by: Mauro Carvalho Chehab Reviewed-by: Rodrigo Vivi > --- > > To avoid mailbombing on a large number of people, only mailing lists were C/C > on the cover. > See [PATCH v2 00/39] at: > https://lore.kernel.org/all/cover.1657699522.git.mche...@kernel.org/ > > Documentation/gpu/i915.rst | 38 ++ > 1 file changed, 38 insertions(+) > > diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst > index c32409c03d32..974754586be8 100644 > --- a/Documentation/gpu/i915.rst > +++ b/Documentation/gpu/i915.rst > @@ -615,6 +615,44 @@ Protected Objects > > .. kernel-doc:: drivers/gpu/drm/i915/pxp/intel_pxp_types.h > > +Table Manager (TTM) > +--- > + > +.. kernel-doc:: drivers/gpu/drm/i915/gem/i915_gem_ttm.c > + > +.. kernel-doc:: drivers/gpu/drm/i915/gem/i915_gem_ttm.h > + > +.. kernel-doc:: drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c > + > +Graphics Execution Manager (GEM) > + > + > +.. kernel-doc:: drivers/gpu/drm/i915/gem/i915_gem_create.c > + > +.. kernel-doc:: drivers/gpu/drm/i915/gem/i915_gem_domain.c > + > +.. kernel-doc:: drivers/gpu/drm/i915/gem/i915_gem_internal.c > + > +.. kernel-doc:: drivers/gpu/drm/i915/gem/i915_gem_lmem.c > + > +.. kernel-doc:: drivers/gpu/drm/i915/gem/i915_gem_mman.c > + > +.. kernel-doc:: drivers/gpu/drm/i915/gem/i915_gem_object.c > + > +.. kernel-doc:: drivers/gpu/drm/i915/gem/i915_gem_object.h > + > +.. kernel-doc:: drivers/gpu/drm/i915/gem/i915_gem_object_types.h > + > +.. kernel-doc:: drivers/gpu/drm/i915/gem/i915_gem_region.c > + > +.. kernel-doc:: drivers/gpu/drm/i915/gem/i915_gem_region.h > + > +.. kernel-doc:: drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c > + > +.. kernel-doc:: drivers/gpu/drm/i915/gem/i915_gem_userptr.c > + > +.. kernel-doc:: drivers/gpu/drm/i915/gem/i915_gem_wait.c > + > Microcontrollers > > > -- > 2.36.1 >
Re: [Linaro-mm-sig] Re: [PATCH v2] drm/gem: Fix GEM handle release errors
Hi Christian, On 8/9 星期二 17:08, Christian König wrote: Hi Jeffy, Am 09.08.22 um 09:55 schrieb Christian König: [SNIP] So we are allowing GEM object to have multiple handles, and GEM object could have at most one dma-buf, doesn't that means that dma-buf could map to multiple handles? No, at least not for the same GEM file private. That's the reason why the rb is indexed by the dma_buf object and not the handle. In other words the rb is so that you have exactly one handle for each dma_buf in each file private. I don't think so, because if user get multiple handles for the same GEM obj and use drm_gem_prime_handle_to_fd() for those handles Mhm, that works? This is illegal and should have been prevented somehow. At least I see the problem now. I'm just not sure how to fix it. Your v2 patch indeed prevents leakage of the drm_prime_member for the additional handles, but those shouldn't have been added in the first place. The issue is that with this we make it unpredictable which handle is returned. E.g. if we have handle 2,5,7 it can be that because of re-balancing the tree sometimes 2 and sometimes 5 is returned. Maybe cache the latest returned handle in the obj(after drm_gem_prime_fd_to_handle), and clear it when that handle been deleted in drm_gem_handle_delete()? Something like: drm_gem_prime_fd_to_handle handle = drm_prime_lookup_buf_handle(buf) obj = obj_from_handle(handle) if !obj->primary_handle obj->primary_handle = handle return obj->primary_handle Or maybe limit GEM obj with a single lifetime handle? That's not really a good idea and breaks a couple of assumptions as far as I know. Ideas? Thanks, Christian.
Re: [Intel-gfx] [PATCH v2 30/39] docs: gpu: i915.rst: gt: add more kernel-doc markups
On Wed, Jul 13, 2022 at 09:12:18AM +0100, Mauro Carvalho Chehab wrote: > There are several documented GT kAPI that aren't currently part > of the docs. Add them, as this allows identifying issues with > badly-formatted tags. > > Signed-off-by: Mauro Carvalho Chehab > --- > > To avoid mailbombing on a large number of people, only mailing lists were C/C > on the cover. > See [PATCH v2 00/39] at: > https://lore.kernel.org/all/cover.1657699522.git.mche...@kernel.org/ > > Documentation/gpu/i915.rst | 43 +- > 1 file changed, 42 insertions(+), 1 deletion(-) > > diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst > index 2ad7941a79f2..afd8c0e3c689 100644 > --- a/Documentation/gpu/i915.rst > +++ b/Documentation/gpu/i915.rst > @@ -149,7 +149,6 @@ Misc display functions > > .. kernel-doc:: drivers/gpu/drm/i915/display/skl_scaler.c > > - > Plane Configuration > --- > > @@ -308,6 +307,48 @@ Multicast/Replicated (MCR) Registers > .. kernel-doc:: drivers/gpu/drm/i915/gt/intel_gt_mcr.c > :internal: > > +GT engine > +- > + > +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_engine_types.h > + > +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_engine_cs.c > + > +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_engine_pm.c > + > +GT context > +-- > + > +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_context.h why does the context deserves a separated section and the many others below no? > + > +Graphics Translation Tables > +--- > + > +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_ggtt.c > + > +Other GT functionality > +-- > + > +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_gsc.h > + > +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_gtt.c > + > +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_gtt.h Why aren't these gtt ones in the above block? why only having the global gtt there? > + > +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_migrate.c > + > +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_mocs.h > + > +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_rc6.c > + > +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_reset.c > + > +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_rps_types.h > + > +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_rps.c > + > +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_sseu.c > + > Memory Management and Command Submission > > > -- > 2.36.1 >
Re: [Intel-gfx] [PATCH v2 19/39] drm/i915: i915_gem_region.h: fix i915_gem_apply_to_region_ops doc
On Wed, Jul 13, 2022 at 09:12:07AM +0100, Mauro Carvalho Chehab wrote:
> The kernel-doc markup for i915_gem_apply_to_region_ops() has some
> issues:
>
> 1. The field should be marked as @process_obj;
> 2. The callback parameters aren't document properly, as sphinx
>will consider them to be placed at the wrong place.
>
> Fix (1) and change the way the parameters are described, using
> a list, in order for it to be properly parsed during documentation
> build time.
>
> Signed-off-by: Mauro Carvalho Chehab
Reviewed-by: Rodrigo Vivi
> ---
>
> To avoid mailbombing on a large number of people, only mailing lists were C/C
> on the cover.
> See [PATCH v2 00/39] at:
> https://lore.kernel.org/all/cover.1657699522.git.mche...@kernel.org/
>
> drivers/gpu/drm/i915/gem/i915_gem_region.h | 8 +---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_region.h
> b/drivers/gpu/drm/i915/gem/i915_gem_region.h
> index 2dfcc41c0170..b0134bf4b1b7 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_region.h
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_region.h
> @@ -22,9 +22,11 @@ struct i915_gem_apply_to_region;
> */
> struct i915_gem_apply_to_region_ops {
> /**
> - * process_obj - Process the current object
> - * @apply: Embed this for private data.
> - * @obj: The current object.
> + * @process_obj: Callback function to process the current object
> + * it requires two arguments:
> + *
> + * - @apply: Embed this for private data.
> + * - @obj: The current object.
>*
>* Note that if this function is part of a ww transaction, and
>* if returns -EDEADLK for one of the objects, it may be
> --
> 2.36.1
>
Re: [Intel-gfx] [PATCH v2 29/39] docs: gpu: i915.rst: display: add kernel-doc markups
On Wed, Jul 13, 2022 at 09:12:17AM +0100, Mauro Carvalho Chehab wrote: > There are several documented kAPI at the display side that > aren't currently part of the docs. Add them, as this allows > identifying issues with badly-formatted tags. > > Signed-off-by: Mauro Carvalho Chehab same here, not checked if these would be all the files, but it is reasonable Reviewed-by: Rodrigo Vivi > --- > > To avoid mailbombing on a large number of people, only mailing lists were C/C > on the cover. > See [PATCH v2 00/39] at: > https://lore.kernel.org/all/cover.1657699522.git.mche...@kernel.org/ > > Documentation/gpu/i915.rst | 50 ++ > 1 file changed, 50 insertions(+) > > diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst > index 4e59db1cfb00..2ad7941a79f2 100644 > --- a/Documentation/gpu/i915.rst > +++ b/Documentation/gpu/i915.rst > @@ -100,6 +100,56 @@ Display FIFO Underrun Reporting > .. kernel-doc:: drivers/gpu/drm/i915/display/intel_fifo_underrun.c > :internal: > > +Atomic Modeset Support > +-- > + > +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_atomic.c > + > +Display Power Domain > + > + > +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_display_power.c > + > +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_display_power_map.c > + > +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_display_power_well.c > + > +Misc display functions > +-- > + > +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_backlight.c > + > +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_crtc.c > + > +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_connector.c > + > +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_display_debugfs.c > + > +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_dp.c > + > +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_dp_link_training.c > + > +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_dpll.c > + > +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_dpt.c > + > +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_fb.c > + > +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_fb_pin.c > + > +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_gmbus.c > + > +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_lvds.c > + > +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_opregion.c > + > +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_snps_phy.c > + > +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_tc.c > + > +.. kernel-doc:: drivers/gpu/drm/i915/display/skl_scaler.c > + > + > Plane Configuration > --- > > -- > 2.36.1 >
Re: [PATCH v3 2/2] drm/tidss: Add support for AM625 DSS
On 09/08/2022 12:21, Aradhya Bhatia wrote:
Hi Tomi,
On 09-Aug-22 12:01, Tomi Valkeinen wrote:
On 09/08/2022 09:08, Aradhya Bhatia wrote:
Hi Tomi,
On 28-Jul-22 17:34, Tomi Valkeinen wrote:
On 27/06/2022 18:12, Aradhya Bhatia wrote:
Add support for the DSS IP on TI's new AM625 SoC in the tidss driver.
Signed-off-by: Aradhya Bhatia
Reviewed-by: Rahul T R
---
drivers/gpu/drm/tidss/tidss_dispc.c | 56
-
drivers/gpu/drm/tidss/tidss_dispc.h | 2 ++
drivers/gpu/drm/tidss/tidss_drv.c | 1 +
3 files changed, 58 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/tidss/tidss_dispc.c
b/drivers/gpu/drm/tidss/tidss_dispc.c
index dae47853b728..f084f0688a54 100644
--- a/drivers/gpu/drm/tidss/tidss_dispc.c
+++ b/drivers/gpu/drm/tidss/tidss_dispc.c
@@ -272,6 +272,55 @@ const struct dispc_features dispc_j721e_feats = {
.vid_order = { 1, 3, 0, 2 },
};
+const struct dispc_features dispc_am625_feats = {
+ .max_pclk_khz = {
+ [DISPC_VP_DPI] = 165000,
+ [DISPC_VP_OLDI] = 165000,
+ },
+
+ .scaling = {
+ .in_width_max_5tap_rgb = 1280,
+ .in_width_max_3tap_rgb = 2560,
+ .in_width_max_5tap_yuv = 2560,
+ .in_width_max_3tap_yuv = 4096,
+ .upscale_limit = 16,
+ .downscale_limit_5tap = 4,
+ .downscale_limit_3tap = 2,
+ /*
+ * The max supported pixel inc value is 255. The value
+ * of pixel inc is calculated like this: 1+(xinc-1)*bpp.
+ * The maximum bpp of all formats supported by the HW
+ * is 8. So the maximum supported xinc value is 32,
+ * because 1+(32-1)*8 < 255 < 1+(33-1)*4.
+ */
+ .xinc_max = 32,
+ },
+
+ .subrev = DISPC_AM625,
+
+ .common = "common",
+ .common_regs = tidss_am65x_common_regs,
+
+ .num_vps = 2,
+ .vp_name = { "vp1", "vp2" },
+ .ovr_name = { "ovr1", "ovr2" },
+ .vpclk_name = { "vp1", "vp2" },
+ .vp_bus_type = { DISPC_VP_OLDI, DISPC_VP_DPI },
This looks correct, but with the two OLDI TXes, I think there will
be some interesting issues.
The tidss_kms.c associates a DSS VP and a DT port, but that's no
longer true if you add the ports for both OLDI TXes, as they both
use the same VP. I think fixing that won't affect this patch,
though, and merging this patch will, afaik, enable similar DSS
functionality as we have for AM65x.
So, I think these two patches could be merged, or we could wait a
bit until the OLDI situation becomes more clear. Up to you. In any
case, for both patches:
Reviewed-by: Tomi Valkeinen \
Thank you for the review!
This patch set is required for the dss DT patches to be upstreamed for
the AM625-SK, so I would like them to get merged.
Since these were posted in the previous merge window, I will re-send
with your tag.
I'd like to understand better the dual OLDI TX case before merging any
AM625 dss changes.
At the moment you have only one port in the DT for the OLDI TX for
AM625, right? I don't see how that is supposed to work as there are
two OLDI outputs.
The OLDI node doesn't have node of its own at all. Its the dss port that
gets directly connected to the panel ports.
And if we do add a new port, it perhaps makes sense to have two OLDI
TX ports as ports 0 and 1, and the DPI as port 2, which is then
different from AM65x.
The DSS still has a single (DPI) VP for the OLDI outputs. Both the OLDI
TXes receive the same input from the DSS VP.
Yes, but don't mix the DSS VP and the DT port. They are not the same thing.
Wouldn't having them modeled as videp ports 0 and 1 would mean that the
DSS is capable of driving 2 different OLDI displays? (which is not the
case here).
If you use the OLDI cloning, the AM625 is driving two OLDI displays, no?
In theory the panels could be of different model, as long as they both
support the same video mode, and they could be managed by different
drivers. This requires two ports so that you can connect the panels in
the DT.
But let's continue this discussion in the "[PATCH 4/8] drm/tidss: Add
support for Dual Link LVDS Bus Format" thread, no need to discuss the
same things in two threads =).
Tomi
Re: [PATCH v2 32/39] docs: gpu: i915.rst: GVT: add more kernel-doc markups
On Wed, Jul 13, 2022 at 09:12:20AM +0100, Mauro Carvalho Chehab wrote: > There are several documented GVT kAPI that aren't currently part > of the docs. Add them, as this allows identifying issues with > badly-formatted tags. > > Signed-off-by: Mauro Carvalho Chehab I haven't checked if these would be all the files, but the approach looks reasonable to me. Reviewed-by: Rodrigo Vivi > --- > > To avoid mailbombing on a large number of people, only mailing lists were C/C > on the cover. > See [PATCH v2 00/39] at: > https://lore.kernel.org/all/cover.1657699522.git.mche...@kernel.org/ > > Documentation/gpu/i915.rst | 41 ++ > 1 file changed, 41 insertions(+) > > diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst > index 70f2f4826eba..3ee121a0ea62 100644 > --- a/Documentation/gpu/i915.rst > +++ b/Documentation/gpu/i915.rst > @@ -58,6 +58,47 @@ Intel GVT-g Host Support(vGPU device model) > .. kernel-doc:: drivers/gpu/drm/i915/intel_gvt.c > :internal: > > +Other Intel GVT-g interfaces > + > + > +.. kernel-doc:: drivers/gpu/drm/i915/gvt/gvt.h > + > +.. kernel-doc:: drivers/gpu/drm/i915/gvt/aperture_gm.c > + > +.. kernel-doc:: drivers/gpu/drm/i915/gvt/cfg_space.c > + > +.. kernel-doc:: drivers/gpu/drm/i915/gvt/debugfs.c > + > +.. kernel-doc:: drivers/gpu/drm/i915/gvt/display.c > + > +.. kernel-doc:: drivers/gpu/drm/i915/gvt/edid.c > + > +.. kernel-doc:: drivers/gpu/drm/i915/gvt/fb_decoder.c > + > +.. kernel-doc:: drivers/gpu/drm/i915/gvt/firmware.c > + > +.. kernel-doc:: drivers/gpu/drm/i915/gvt/gtt.c > + > +.. kernel-doc:: drivers/gpu/drm/i915/gvt/handlers.c > + > +.. kernel-doc:: drivers/gpu/drm/i915/gvt/interrupt.c > + > +.. kernel-doc:: drivers/gpu/drm/i915/gvt/kvmgt.c > + > +.. kernel-doc:: drivers/gpu/drm/i915/intel_gvt_mmio_table.c > + > +.. kernel-doc:: drivers/gpu/drm/i915/gvt/mmio.c > + > +.. kernel-doc:: drivers/gpu/drm/i915/gvt/mmio_context.c > + > +.. kernel-doc:: drivers/gpu/drm/i915/gvt/opregion.c > + > +.. kernel-doc:: drivers/gpu/drm/i915/gvt/page_track.c > + > +.. kernel-doc:: drivers/gpu/drm/i915/gvt/scheduler.c > + > +.. kernel-doc:: drivers/gpu/drm/i915/gvt/vgpu.c > + > Workarounds > --- > > -- > 2.36.1 >
[PATCH v2] drm/ttm: Fix dummy res NULL ptr deref bug
Check the bo->resource value before accessing the resource mem_type. v2: Fix commit description unwrapped warning [ 40.191227][ T184] general protection fault, probably for non-canonical address 0xdc02: [#1] SMP KASAN PTI [ 40.192995][ T184] KASAN: null-ptr-deref in range [0x0010-0x0017] [ 40.194411][ T184] CPU: 1 PID: 184 Comm: systemd-udevd Not tainted 5.19.0-rc4-00721-gb297c22b7070 #1 [ 40.196063][ T184] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-debian-1.16.0-4 04/01/2014 [ 40.199605][ T184] RIP: 0010:ttm_bo_validate+0x1b3/0x240 [ttm] [ 40.200754][ T184] Code: e8 72 c5 ff ff 83 f8 b8 74 d4 85 c0 75 54 49 8b 9e 58 01 00 00 48 b8 00 00 00 00 00 fc ff df 48 8d 7b 10 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 04 3c 03 7e 44 8b 53 10 31 c0 85 d2 0f 85 58 [ 40.203685][ T184] RSP: 0018:c96df0c8 EFLAGS: 00010202 [ 40.204630][ T184] RAX: dc00 RBX: RCX: 11102f4bb71b [ 40.205864][ T184] RDX: 0002 RSI: c96df208 RDI: 0010 [ 40.207102][ T184] RBP: 192dbe1a R08: c96df208 R09: [ 40.208394][ T184] R10: 88817a5f R11: 0001 R12: c96df110 [ 40.209692][ T184] R13: c96df0f0 R14: 88817a5db800 R15: c96df208 [ 40.210862][ T184] FS: 7f6b1d16e8c0() GS:88839d70() knlGS: [ 40.212250][ T184] CS: 0010 DS: ES: CR0: 80050033 [ 40.213275][ T184] CR2: 55a1001d4ff0 CR3: 0001700f4000 CR4: 06e0 [ 40.214469][ T184] Call Trace: [ 40.214974][ T184] [ 40.215438][ T184] ? ttm_bo_bounce_temp_buffer+0x140/0x140 [ttm] [ 40.216572][ T184] ? mutex_spin_on_owner+0x240/0x240 [ 40.217456][ T184] ? drm_vma_offset_add+0xaa/0x100 [drm] [ 40.218457][ T184] ttm_bo_init_reserved+0x3d6/0x540 [ttm] [ 40.219410][ T184] ? shmem_get_inode+0x744/0x980 [ 40.220231][ T184] ttm_bo_init_validate+0xb1/0x200 [ttm] [ 40.221172][ T184] ? bo_driver_evict_flags+0x340/0x340 [drm_vram_helper] [ 40.222530][ T184] ? ttm_bo_init_reserved+0x540/0x540 [ttm] [ 40.223643][ T184] ? __do_sys_finit_module+0x11a/0x1c0 [ 40.224654][ T184] ? __shmem_file_setup+0x102/0x280 [ 40.234764][ T184] drm_gem_vram_create+0x305/0x480 [drm_vram_helper] [ 40.235766][ T184] ? bo_driver_evict_flags+0x340/0x340 [drm_vram_helper] [ 40.236846][ T184] ? __kasan_slab_free+0x108/0x180 [ 40.237650][ T184] drm_gem_vram_fill_create_dumb+0x134/0x340 [drm_vram_helper] [ 40.238864][ T184] ? local_pci_probe+0xdf/0x180 [ 40.239674][ T184] ? drmm_vram_helper_init+0x400/0x400 [drm_vram_helper] [ 40.240826][ T184] drm_client_framebuffer_create+0x19c/0x400 [drm] [ 40.241955][ T184] ? drm_client_buffer_delete+0x200/0x200 [drm] [ 40.243001][ T184] ? drm_client_pick_crtcs+0x554/0xb80 [drm] [ 40.244030][ T184] drm_fb_helper_generic_probe+0x23f/0x940 [drm_kms_helper] [ 40.245226][ T184] ? __cond_resched+0x1c/0xc0 [ 40.245987][ T184] ? drm_fb_helper_memory_range_to_clip+0x180/0x180 [drm_kms_helper] [ 40.247316][ T184] ? mutex_unlock+0x80/0x100 [ 40.248005][ T184] ? __mutex_unlock_slowpath+0x2c0/0x2c0 [ 40.249083][ T184] drm_fb_helper_single_fb_probe+0x907/0xf00 [drm_kms_helper] [ 40.250314][ T184] ? drm_fb_helper_check_var+0x1180/0x1180 [drm_kms_helper] [ 40.251540][ T184] ? __cond_resched+0x1c/0xc0 [ 40.252321][ T184] ? mutex_lock+0x9f/0x100 [ 40.253062][ T184] __drm_fb_helper_initial_config_and_unlock+0xb9/0x2c0 [drm_kms_helper] [ 40.254394][ T184] drm_fbdev_client_hotplug+0x56f/0x840 [drm_kms_helper] [ 40.255477][ T184] drm_fbdev_generic_setup+0x165/0x3c0 [drm_kms_helper] [ 40.256607][ T184] bochs_pci_probe+0x6b7/0x900 [bochs] [ 40.257515][ T184] ? _raw_spin_lock_irqsave+0x87/0x100 [ 40.258312][ T184] ? bochs_hw_init+0x480/0x480 [bochs] [ 40.259244][ T184] ? bochs_hw_init+0x480/0x480 [bochs] [ 40.260186][ T184] local_pci_probe+0xdf/0x180 [ 40.260928][ T184] pci_call_probe+0x15f/0x500 [ 40.265798][ T184] ? _raw_spin_lock+0x81/0x100 [ 40.266508][ T184] ? pci_pm_suspend_noirq+0x980/0x980 [ 40.267322][ T184] ? pci_assign_irq+0x81/0x280 [ 40.268096][ T184] ? pci_match_device+0x351/0x6c0 [ 40.268883][ T184] ? kernfs_put+0x18/0x40 [ 40.269611][ T184] pci_device_probe+0xee/0x240 [ 40.270352][ T184] really_probe+0x435/0xa80 [ 40.271021][ T184] __driver_probe_device+0x2ab/0x480 [ 40.271828][ T184] driver_probe_device+0x49/0x140 [ 40.272627][ T184] __driver_attach+0x1bd/0x4c0 [ 40.273372][ T184] ? __device_attach_driver+0x240/0x240 [ 40.274273][ T184] bus_for_each_dev+0x11e/0x1c0 [ 40.275080][ T184] ? subsys_dev_iter_exit+0x40/0x40 [ 40.275951][ T184] ? klist_add_tail+0x132/0x280 [ 40.276767][ T184] bus_add_driver+0x39b/0x580 [ 40.277574][ T184]
Re: [Intel-gfx] [PATCH v2 18/39] drm/i915: intel_pm.c: fix some ascii artwork at kernel-doc
On Wed, Jul 13, 2022 at 09:12:06AM +0100, Mauro Carvalho Chehab wrote:
> Preserving ascii artwork on kernel-docs is tricky, as it needs
> to respect both the Sphinx rules and be properly parsed by
> kernel-doc script.
>
> The Sphinx syntax require code-blocks, which is:
>
> ::
>
> followed by a blank line and indented lines.
>
> But kernel-doc only works fine if the first and the last line
> are indented with the same amount of spaces.
>
> Also, a "\" at the end means that the next line should be merged
> with the first one.
my first reaction was: "do we really need those new empty ( ) blocks?"
Then I read this ;)
Reviewed-by: Rodrigo Vivi
>
> Change the ascii artwork to be on code-blocks, starting all
> lines at the same characters and not ending with a backslash.
>
> Signed-off-by: Mauro Carvalho Chehab
> ---
>
> To avoid mailbombing on a large number of people, only mailing lists were C/C
> on the cover.
> See [PATCH v2 00/39] at:
> https://lore.kernel.org/all/cover.1657699522.git.mche...@kernel.org/
>
> drivers/gpu/drm/i915/intel_pm.c | 33 ++---
> 1 file changed, 18 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index f06babdb3a8c..d3393752b04b 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -684,18 +684,20 @@ static const struct intel_watermark_params i845_wm_info
> = {
> * FIFO is relatively small compared to the amount of data
> * fetched.
> *
> - * The FIFO level vs. time graph might look something like:
> + * The FIFO level vs. time graph might look something like::
> *
> - * |\ |\
> - * | \ | \
> - * __---__---__ (- plane active, _ blanking)
> - * -> time
> + * ^
> + * | |\ |\ ( )
> + * | | \ | \ ( )
> + * | __---__---__ (- plane active, _ blanking)
> + * +---> time
> *
> - * or perhaps like this:
> + * or perhaps like this::
> *
> - * |\|\ |\|\
> - * ______ (- plane active, _ blanking)
> - * -> time
> + * ^
> + * | |\|\ |\|\ ( )
> + * | ______ (- plane active, _ blanking)
> + * +---> time
> *
> * Returns:
> * The watermark in bytes
> @@ -731,13 +733,14 @@ static unsigned int intel_wm_method1(unsigned int
> pixel_rate,
> * FIFO is relatively large compared to the amount of data
> * fetched.
> *
> - * The FIFO level vs. time graph might look something like:
> + * The FIFO level vs. time graph might look something like::
> *
> - *|\___ |\___
> - *|\___ |\___
> - *|\ |\
> - * __ --__--__--__--__--__--__ (- plane active, _ blanking)
> - * -> time
> + * ^
> + * | |\___ |\___( )
> + * | |\___ |\___( )
> + * | |\ |\ ( )
> + * | __ --__--__--__--__--__--__ (- plane active, _ blanking)
> + * +-> time
> *
> * Returns:
> * The watermark in bytes
> --
> 2.36.1
>
Re: [PATCH v5 6/6] drm/ttm: Switch to using the new res callback
Am 09.08.22 um 11:22 schrieb Arunpravin Paneer Selvam:
Apply new intersect and compatible callback instead
of having a generic placement range verfications.
v2: Added a separate callback for compatiblilty
checks (Christian)
We need to move parts of this patch earlier or the i915 will temporary
break the driver until this here is applied.
I suggest to have most of this in the first patch and use the existing
res->start checks as fallback when the new callbacks are not implemented
yet.
This here can then be the last patch with cleanups and removal of those
workarounds.
Apart from that looks like a nice cleanup to me.
Regards,
Christian.
Signed-off-by: Christian König
Signed-off-by: Arunpravin Paneer Selvam
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 45 +++--
drivers/gpu/drm/ttm/ttm_bo.c| 9 +++--
drivers/gpu/drm/ttm/ttm_resource.c | 5 +--
3 files changed, 20 insertions(+), 39 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 170935c294f5..7d25a10395c0 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -1328,11 +1328,12 @@ uint64_t amdgpu_ttm_tt_pte_flags(struct amdgpu_device
*adev, struct ttm_tt *ttm,
static bool amdgpu_ttm_bo_eviction_valuable(struct ttm_buffer_object *bo,
const struct ttm_place *place)
{
- unsigned long num_pages = bo->resource->num_pages;
struct dma_resv_iter resv_cursor;
- struct amdgpu_res_cursor cursor;
struct dma_fence *f;
+ if (!amdgpu_bo_is_amdgpu_bo(bo))
+ return ttm_bo_eviction_valuable(bo, place);
+
/* Swapout? */
if (bo->resource->mem_type == TTM_PL_SYSTEM)
return true;
@@ -1351,40 +1352,20 @@ static bool amdgpu_ttm_bo_eviction_valuable(struct
ttm_buffer_object *bo,
return false;
}
- switch (bo->resource->mem_type) {
- case AMDGPU_PL_PREEMPT:
- /* Preemptible BOs don't own system resources managed by the
-* driver (pages, VRAM, GART space). They point to resources
-* owned by someone else (e.g. pageable memory in user mode
-* or a DMABuf). They are used in a preemptible context so we
-* can guarantee no deadlocks and good QoS in case of MMU
-* notifiers or DMABuf move notifiers from the resource owner.
-*/
+ /* Preemptible BOs don't own system resources managed by the
+* driver (pages, VRAM, GART space). They point to resources
+* owned by someone else (e.g. pageable memory in user mode
+* or a DMABuf). They are used in a preemptible context so we
+* can guarantee no deadlocks and good QoS in case of MMU
+* notifiers or DMABuf move notifiers from the resource owner.
+*/
+ if (bo->resource->mem_type == AMDGPU_PL_PREEMPT)
return false;
- case TTM_PL_TT:
- if (amdgpu_bo_is_amdgpu_bo(bo) &&
- amdgpu_bo_encrypted(ttm_to_amdgpu_bo(bo)))
- return false;
- return true;
- case TTM_PL_VRAM:
- /* Check each drm MM node individually */
- amdgpu_res_first(bo->resource, 0, (u64)num_pages << PAGE_SHIFT,
-);
- while (cursor.remaining) {
- if (place->fpfn < PFN_DOWN(cursor.start + cursor.size)
- && !(place->lpfn &&
-place->lpfn <= PFN_DOWN(cursor.start)))
- return true;
-
- amdgpu_res_next(, cursor.size);
- }
+ if (bo->resource->mem_type == TTM_PL_TT &&
+ amdgpu_bo_encrypted(ttm_to_amdgpu_bo(bo)))
return false;
- default:
- break;
- }
-
return ttm_bo_eviction_valuable(bo, place);
}
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index c1bd006a5525..f066e8124c50 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -518,6 +518,9 @@ static int ttm_bo_evict(struct ttm_buffer_object *bo,
bool ttm_bo_eviction_valuable(struct ttm_buffer_object *bo,
const struct ttm_place *place)
{
+ struct ttm_resource *res = bo->resource;
+ struct ttm_device *bdev = bo->bdev;
+
dma_resv_assert_held(bo->base.resv);
if (bo->resource->mem_type == TTM_PL_SYSTEM)
return true;
@@ -525,11 +528,7 @@ bool ttm_bo_eviction_valuable(struct ttm_buffer_object *bo,
/* Don't evict this BO if it's outside of the
* requested placement range
*/
- if (place->fpfn >= (bo->resource->start + bo->resource->num_pages) ||
- (place->lpfn && place->lpfn <= bo->resource->start))
Re: [Intel-gfx] [PATCH v2 15/39] drm/i915: intel_dp_link_training.c: fix kernel-doc markup
On Wed, Jul 13, 2022 at 09:12:03AM +0100, Mauro Carvalho Chehab wrote:
> The return code table is not properly marked, causing warnings
> and being badly parsed by Sphinx:
>
> Documentation/gpu/i915:130:
> ./drivers/gpu/drm/i915/display/intel_dp_link_training.c:183: WARNING: Block
> quote ends without a blank line; unexpected unindent.
> Documentation/gpu/i915:130:
> ./drivers/gpu/drm/i915/display/intel_dp_link_training.c:186: WARNING:
> Definition list ends without a blank line; unexpected unindent.
>
> Use table markups to fix it.
cool, I didn't know that
Reviewed-by: Rodrigo Vivi
>
> Signed-off-by: Mauro Carvalho Chehab
> ---
>
> To avoid mailbombing on a large number of people, only mailing lists were C/C
> on the cover.
> See [PATCH v2 00/39] at:
> https://lore.kernel.org/all/cover.1657699522.git.mche...@kernel.org/
>
> drivers/gpu/drm/i915/display/intel_dp_link_training.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> index 9feaf1a589f3..23a269fcf6ca 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> @@ -177,12 +177,14 @@ static int intel_dp_init_lttpr(struct intel_dp
> *intel_dp, const u8 dpcd[DP_RECEI
> * transparent mode link training mode.
> *
> * Returns:
> + *
> =
> * >0 if LTTPRs were detected and the non-transparent LT mode was set. The
> * DPRX capabilities are read out.
> *0 if no LTTPRs or more than 8 LTTPRs were detected or in case of a
> * detection failure and the transparent LT mode was set. The DPRX
> * capabilities are read out.
> * <0 Reading out the DPRX capabilities failed.
> + *
> =
> */
> int intel_dp_init_lttpr_and_dprx_caps(struct intel_dp *intel_dp)
> {
> --
> 2.36.1
>
Re: [PATCH 4/8] drm/tidss: Add support for Dual Link LVDS Bus Format
On 09/08/2022 12:06, Aradhya Bhatia wrote: Even in DT, the dss port (for OLDI) connects to the panel port's endpoint directly. Even in cases of dual link or cloning, it's only a singular remote-to-endpoint connection between the (OLDI) VP and the panel port. Hence the requirement of the properties in the earlier patches of the series. Sorry, I don't follow. If you use cloning, you have two TX outputs, going to two panels, right? So you need two panel DT nodes, and those would connect to two OLDI TX ports in the DSS. > Afaics the existing dual link bridge/panel drivers also use two ports for the connection, so to use the dual link you need two ports in the DSS. I admit I'm not familiar with LVDS dual link, but it's not clear to me how you see the dual OLDI TX being used with other drivers if you have only one port. What kind of setups have you tested? In the DTs, the OLDIs are not modeled at all. Since the DSS only has a single VP for OLDI, the DT dss port (for OLDI) is connected to a single simple-panel node for dual link, bypassing the OLDI TX in DT. I have this same OLDI setup and have been testing on this. A DSS VP is a DSS internal port, whereas a port node in the DT is an external port. There doesn't have to be a 1:1 match between those. The port in the DT represents some kind of "connector" to the outside world, which is usually a collection of pins that provide a video bus. Here, as far as I can see, the DSS clearly has three external ports, two OLDI ports and one DPI port. I do not have a cloning display setup with me, but I have seen DT DSS port connected to one of 2 panel nodes while the other panel (remains as a companion panel to the first) without any endpoint connections. Since, the OLDI TXes (0 and 1), receive the same clocks and inputs from DSS OLDI VP, this 'method' has worked too. This, and using simple-panel for dual link with single port connection, sounds like a hack. A practical example: TI's customer wants to use AM625 and THC63LVD1024 bridge. How does it work? THC63LVD1024 driver uses two LVDS ports for input, both of which are used in dual-link mode. The use of lvds helper functions does not seem feasible in this case, because even they read DT properties to determine the dual link connection and those properties need to be a part of a lvds bridge device. Can you elaborate a bit more why the DRM helpers couldn't be used here? The drm_of.c helpers use DT properties to ascertain the presence of a dual-link connection. While there wasn't a specific helper to determine dual-link or not, the drivers use the odd/even pixel order helper which is based on the properties "dual-lvds-odd-pixels" and "dual-lvds-odd- pixels". If either of the properties are absent, the helper returns an error making the driver to use single link. These properties are LVDS specific, but they could not be added in the DT because there is no OLDI TX DT node for our case. If I'm not mistaken, those properties are in the port node, not the device node, and also, I believe those properties are on the sink side, so they wouldn't even be in the AM625 data. See, for example: arch/arm64/boot/dts/renesas/r8a774c0-ek874-idk-2121wr.dts I have also been considering the idea of implementing a new device driver for the OLDI TXes, not unlike the renesas' one. That way the driver could have the properties and the lvds helper functions at their disposal. I am just slightly unsure if that would allow space for any conflicts because of the shared register space. No, I don't think new devices are needed here. Okay... I am not quite sure I understand completely what you are recommending the OLDI to be. It seems to me that you want the OLDI TXes to be modeled as nodes, right? Wouldn't that automatically require some sort of standalone driver arrangement for them? Or am I missing something important here? No, I'm only talking about the DT port nodes. At the moment the AM65x DT bindings doc says that there are two ports, port@0 for OLDI and port@1 for DPI. I'm saying AM625 needs three ports. Tomi
[PATCH v5 3/6] drm/amdgpu: Implement intersect/compatible functions
Implemented a new intersect and compatible callback function
fetching start offset from backend drm buddy allocator.
Signed-off-by: Christian König
Signed-off-by: Arunpravin Paneer Selvam
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c | 38 +++
drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 68
2 files changed, 106 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
index 8c6b2284cf56..1f3302aebeff 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
@@ -204,6 +204,42 @@ void amdgpu_gtt_mgr_recover(struct amdgpu_gtt_mgr *mgr)
amdgpu_gart_invalidate_tlb(adev);
}
+/**
+ * amdgpu_gtt_mgr_intersects - test for intersection
+ *
+ * @man: Our manager object
+ * @res: The resource to test
+ * @place: The place for the new allocation
+ * @size: The size of the new allocation
+ *
+ * Simplified intersection test, only interesting if we need GART or not.
+ */
+static bool amdgpu_gtt_mgr_intersects(struct ttm_resource_manager *man,
+ struct ttm_resource *res,
+ const struct ttm_place *place,
+ size_t size)
+{
+ return !place->lpfn || amdgpu_gtt_mgr_has_gart_addr(res);
+}
+
+/**
+ * amdgpu_gtt_mgr_compatible - test for compatibility
+ *
+ * @man: Our manager object
+ * @res: The resource to test
+ * @place: The place for the new allocation
+ * @size: The size of the new allocation
+ *
+ * Simplified compatibility test.
+ */
+static bool amdgpu_gtt_mgr_compatible(struct ttm_resource_manager *man,
+ struct ttm_resource *res,
+ const struct ttm_place *place,
+ size_t size)
+{
+ return !place->lpfn || amdgpu_gtt_mgr_has_gart_addr(res);
+}
+
/**
* amdgpu_gtt_mgr_debug - dump VRAM table
*
@@ -225,6 +261,8 @@ static void amdgpu_gtt_mgr_debug(struct
ttm_resource_manager *man,
static const struct ttm_resource_manager_func amdgpu_gtt_mgr_func = {
.alloc = amdgpu_gtt_mgr_new,
.free = amdgpu_gtt_mgr_del,
+ .intersects = amdgpu_gtt_mgr_intersects,
+ .compatible = amdgpu_gtt_mgr_compatible,
.debug = amdgpu_gtt_mgr_debug
};
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
index 7a5e8a7b4a1b..dcf2a6400e8e 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
@@ -720,6 +720,72 @@ uint64_t amdgpu_vram_mgr_vis_usage(struct amdgpu_vram_mgr
*mgr)
return atomic64_read(>vis_usage);
}
+/**
+ * amdgpu_vram_mgr_intersects - test each drm buddy block for intersection
+ *
+ * @man: TTM memory type manager
+ * @res: The resource to test
+ * @place: The place to test against
+ * @size: Size of the new allocation
+ *
+ * Test each drm buddy block for intersection for eviction decision.
+ */
+static bool amdgpu_vram_mgr_intersects(struct ttm_resource_manager *man,
+ struct ttm_resource *res,
+ const struct ttm_place *place,
+ size_t size)
+{
+ struct amdgpu_vram_mgr_resource *mgr = to_amdgpu_vram_mgr_resource(res);
+ struct drm_buddy_block *block;
+
+ /* Check each drm buddy block individually */
+ list_for_each_entry(block, >blocks, link) {
+ unsigned long fpfn =
+ amdgpu_vram_mgr_block_start(block) >> PAGE_SHIFT;
+ unsigned long lpfn = fpfn +
+ (amdgpu_vram_mgr_block_size(block) >> PAGE_SHIFT);
+
+ if (place->fpfn < lpfn &&
+ (place->lpfn && place->lpfn > fpfn))
+ return true;
+ }
+
+ return false;
+}
+
+/**
+ * amdgpu_vram_mgr_compatible - test each drm buddy block for compatibility
+ *
+ * @man: TTM memory type manager
+ * @res: The resource to test
+ * @place: The place to test against
+ * @size: Size of the new allocation
+ *
+ * Test each drm buddy block for placement compatibility.
+ */
+static bool amdgpu_vram_mgr_compatible(struct ttm_resource_manager *man,
+ struct ttm_resource *res,
+ const struct ttm_place *place,
+ size_t size)
+{
+ struct amdgpu_vram_mgr_resource *mgr = to_amdgpu_vram_mgr_resource(res);
+ struct drm_buddy_block *block;
+
+ /* Check each drm buddy block individually */
+ list_for_each_entry(block, >blocks, link) {
+ unsigned long fpfn =
+ amdgpu_vram_mgr_block_start(block) >> PAGE_SHIFT;
+ unsigned long lpfn = fpfn +
+ (amdgpu_vram_mgr_block_size(block) >> PAGE_SHIFT);
+
+ if
[PATCH v5 4/6] drm/i915: Implement intersect/compatible functions
Implemented a new intersect and compatible callback function
fetching start offset from drm buddy allocator.
v3: move the bits that are specific to buddy_man (Matthew)
v4: consider the block size /range (Matthew)
Signed-off-by: Christian König
Signed-off-by: Arunpravin Paneer Selvam
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 41 +--
drivers/gpu/drm/i915/i915_ttm_buddy_manager.c | 73 +++
2 files changed, 74 insertions(+), 40 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index 70e2ed4e99df..bf5fd6886ca0 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -379,7 +379,6 @@ static bool i915_ttm_eviction_valuable(struct
ttm_buffer_object *bo,
const struct ttm_place *place)
{
struct drm_i915_gem_object *obj = i915_ttm_to_gem(bo);
- struct ttm_resource *res = bo->resource;
if (!obj)
return false;
@@ -396,45 +395,7 @@ static bool i915_ttm_eviction_valuable(struct
ttm_buffer_object *bo,
if (!i915_gem_object_evictable(obj))
return false;
- switch (res->mem_type) {
- case I915_PL_LMEM0: {
- struct ttm_resource_manager *man =
- ttm_manager_type(bo->bdev, res->mem_type);
- struct i915_ttm_buddy_resource *bman_res =
- to_ttm_buddy_resource(res);
- struct drm_buddy *mm = bman_res->mm;
- struct drm_buddy_block *block;
-
- if (!place->fpfn && !place->lpfn)
- return true;
-
- GEM_BUG_ON(!place->lpfn);
-
- /*
-* If we just want something mappable then we can quickly check
-* if the current victim resource is using any of the CPU
-* visible portion.
-*/
- if (!place->fpfn &&
- place->lpfn == i915_ttm_buddy_man_visible_size(man))
- return bman_res->used_visible_size > 0;
-
- /* Real range allocation */
- list_for_each_entry(block, _res->blocks, link) {
- unsigned long fpfn =
- drm_buddy_block_offset(block) >> PAGE_SHIFT;
- unsigned long lpfn = fpfn +
- (drm_buddy_block_size(mm, block) >> PAGE_SHIFT);
-
- if (place->fpfn < lpfn && place->lpfn > fpfn)
- return true;
- }
- return false;
- } default:
- break;
- }
-
- return true;
+ return ttm_bo_eviction_valuable(bo, place);
}
static void i915_ttm_evict_flags(struct ttm_buffer_object *bo,
diff --git a/drivers/gpu/drm/i915/i915_ttm_buddy_manager.c
b/drivers/gpu/drm/i915/i915_ttm_buddy_manager.c
index a5109548abc0..56d017e4038b 100644
--- a/drivers/gpu/drm/i915/i915_ttm_buddy_manager.c
+++ b/drivers/gpu/drm/i915/i915_ttm_buddy_manager.c
@@ -178,6 +178,77 @@ static void i915_ttm_buddy_man_free(struct
ttm_resource_manager *man,
kfree(bman_res);
}
+static bool i915_ttm_buddy_man_intersects(struct ttm_resource_manager *man,
+ struct ttm_resource *res,
+ const struct ttm_place *place,
+ size_t size)
+{
+ struct i915_ttm_buddy_resource *bman_res = to_ttm_buddy_resource(res);
+ struct i915_ttm_buddy_manager *bman = to_buddy_manager(man);
+ struct drm_buddy *mm = >mm;
+ struct drm_buddy_block *block;
+
+ if (!place->fpfn && !place->lpfn)
+ return true;
+
+ GEM_BUG_ON(!place->lpfn);
+
+ /*
+* If we just want something mappable then we can quickly check
+* if the current victim resource is using any of the CPU
+* visible portion.
+*/
+ if (!place->fpfn &&
+ place->lpfn == i915_ttm_buddy_man_visible_size(man))
+ return bman_res->used_visible_size > 0;
+
+ /* Check each drm buddy block individually */
+ list_for_each_entry(block, _res->blocks, link) {
+ unsigned long fpfn =
+ drm_buddy_block_offset(block) >> PAGE_SHIFT;
+ unsigned long lpfn = fpfn +
+ (drm_buddy_block_size(mm, block) >> PAGE_SHIFT);
+
+ if (place->fpfn < lpfn && place->lpfn > fpfn)
+ return true;
+ }
+
+ return false;
+}
+
+static bool i915_ttm_buddy_man_compatible(struct ttm_resource_manager *man,
+ struct ttm_resource *res,
+ const struct ttm_place *place,
+ size_t size)
+{
+ struct i915_ttm_buddy_resource
[PATCH v5 5/6] drm/nouveau: Implement intersect/compatible functions
Implemented a new intersect and compatible callback function
fetching the start offset from struct ttm_resource.
Signed-off-by: Christian König
Signed-off-by: Arunpravin Paneer Selvam
---
drivers/gpu/drm/nouveau/nouveau_mem.c | 29 +++
drivers/gpu/drm/nouveau/nouveau_mem.h | 6 ++
drivers/gpu/drm/nouveau/nouveau_ttm.c | 24 ++
3 files changed, 59 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/nouveau_mem.c
b/drivers/gpu/drm/nouveau/nouveau_mem.c
index 2e517cdc24c9..76f8edefa637 100644
--- a/drivers/gpu/drm/nouveau/nouveau_mem.c
+++ b/drivers/gpu/drm/nouveau/nouveau_mem.c
@@ -187,3 +187,32 @@ nouveau_mem_new(struct nouveau_cli *cli, u8 kind, u8 comp,
*res = >base;
return 0;
}
+
+bool
+nouveau_mem_intersects(struct ttm_resource *res,
+ const struct ttm_place *place,
+ size_t size)
+{
+ u32 num_pages = PFN_UP(size);
+
+ /* Don't evict BOs outside of the requested placement range */
+ if (place->fpfn >= (res->start + num_pages) ||
+ (place->lpfn && place->lpfn <= res->start))
+ return false;
+
+ return true;
+}
+
+bool
+nouveau_mem_compatible(struct ttm_resource *res,
+ const struct ttm_place *place,
+ size_t size)
+{
+ u32 num_pages = PFN_UP(size);
+
+ if (res->start < place->fpfn ||
+ (place->lpfn && (res->start + num_pages) > place->lpfn))
+ return false;
+
+ return true;
+}
diff --git a/drivers/gpu/drm/nouveau/nouveau_mem.h
b/drivers/gpu/drm/nouveau/nouveau_mem.h
index 325551eba5cd..1ee6cdb9ad9b 100644
--- a/drivers/gpu/drm/nouveau/nouveau_mem.h
+++ b/drivers/gpu/drm/nouveau/nouveau_mem.h
@@ -25,6 +25,12 @@ int nouveau_mem_new(struct nouveau_cli *, u8 kind, u8 comp,
struct ttm_resource **);
void nouveau_mem_del(struct ttm_resource_manager *man,
struct ttm_resource *);
+bool nouveau_mem_intersects(struct ttm_resource *res,
+ const struct ttm_place *place,
+ size_t size);
+bool nouveau_mem_compatible(struct ttm_resource *res,
+ const struct ttm_place *place,
+ size_t size);
int nouveau_mem_vram(struct ttm_resource *, bool contig, u8 page);
int nouveau_mem_host(struct ttm_resource *, struct ttm_tt *);
void nouveau_mem_fini(struct nouveau_mem *);
diff --git a/drivers/gpu/drm/nouveau/nouveau_ttm.c
b/drivers/gpu/drm/nouveau/nouveau_ttm.c
index 85f1f5a0fe5d..9602c30928f2 100644
--- a/drivers/gpu/drm/nouveau/nouveau_ttm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_ttm.c
@@ -42,6 +42,24 @@ nouveau_manager_del(struct ttm_resource_manager *man,
nouveau_mem_del(man, reg);
}
+static bool
+nouveau_manager_intersects(struct ttm_resource_manager *man,
+ struct ttm_resource *res,
+ const struct ttm_place *place,
+ size_t size)
+{
+ return nouveau_mem_intersects(res, place, size);
+}
+
+static bool
+nouveau_manager_compatible(struct ttm_resource_manager *man,
+ struct ttm_resource *res,
+ const struct ttm_place *place,
+ size_t size)
+{
+ return nouveau_mem_compatible(res, place, size);
+}
+
static int
nouveau_vram_manager_new(struct ttm_resource_manager *man,
struct ttm_buffer_object *bo,
@@ -73,6 +91,8 @@ nouveau_vram_manager_new(struct ttm_resource_manager *man,
const struct ttm_resource_manager_func nouveau_vram_manager = {
.alloc = nouveau_vram_manager_new,
.free = nouveau_manager_del,
+ .intersects = nouveau_manager_intersects,
+ .compatible = nouveau_manager_compatible,
};
static int
@@ -97,6 +117,8 @@ nouveau_gart_manager_new(struct ttm_resource_manager *man,
const struct ttm_resource_manager_func nouveau_gart_manager = {
.alloc = nouveau_gart_manager_new,
.free = nouveau_manager_del,
+ .intersects = nouveau_manager_intersects,
+ .compatible = nouveau_manager_compatible,
};
static int
@@ -130,6 +152,8 @@ nv04_gart_manager_new(struct ttm_resource_manager *man,
const struct ttm_resource_manager_func nv04_gart_manager = {
.alloc = nv04_gart_manager_new,
.free = nouveau_manager_del,
+ .intersects = nouveau_manager_intersects,
+ .compatible = nouveau_manager_compatible,
};
static int
--
2.25.1
[PATCH v5 6/6] drm/ttm: Switch to using the new res callback
Apply new intersect and compatible callback instead
of having a generic placement range verfications.
v2: Added a separate callback for compatiblilty
checks (Christian)
Signed-off-by: Christian König
Signed-off-by: Arunpravin Paneer Selvam
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 45 +++--
drivers/gpu/drm/ttm/ttm_bo.c| 9 +++--
drivers/gpu/drm/ttm/ttm_resource.c | 5 +--
3 files changed, 20 insertions(+), 39 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 170935c294f5..7d25a10395c0 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -1328,11 +1328,12 @@ uint64_t amdgpu_ttm_tt_pte_flags(struct amdgpu_device
*adev, struct ttm_tt *ttm,
static bool amdgpu_ttm_bo_eviction_valuable(struct ttm_buffer_object *bo,
const struct ttm_place *place)
{
- unsigned long num_pages = bo->resource->num_pages;
struct dma_resv_iter resv_cursor;
- struct amdgpu_res_cursor cursor;
struct dma_fence *f;
+ if (!amdgpu_bo_is_amdgpu_bo(bo))
+ return ttm_bo_eviction_valuable(bo, place);
+
/* Swapout? */
if (bo->resource->mem_type == TTM_PL_SYSTEM)
return true;
@@ -1351,40 +1352,20 @@ static bool amdgpu_ttm_bo_eviction_valuable(struct
ttm_buffer_object *bo,
return false;
}
- switch (bo->resource->mem_type) {
- case AMDGPU_PL_PREEMPT:
- /* Preemptible BOs don't own system resources managed by the
-* driver (pages, VRAM, GART space). They point to resources
-* owned by someone else (e.g. pageable memory in user mode
-* or a DMABuf). They are used in a preemptible context so we
-* can guarantee no deadlocks and good QoS in case of MMU
-* notifiers or DMABuf move notifiers from the resource owner.
-*/
+ /* Preemptible BOs don't own system resources managed by the
+* driver (pages, VRAM, GART space). They point to resources
+* owned by someone else (e.g. pageable memory in user mode
+* or a DMABuf). They are used in a preemptible context so we
+* can guarantee no deadlocks and good QoS in case of MMU
+* notifiers or DMABuf move notifiers from the resource owner.
+*/
+ if (bo->resource->mem_type == AMDGPU_PL_PREEMPT)
return false;
- case TTM_PL_TT:
- if (amdgpu_bo_is_amdgpu_bo(bo) &&
- amdgpu_bo_encrypted(ttm_to_amdgpu_bo(bo)))
- return false;
- return true;
- case TTM_PL_VRAM:
- /* Check each drm MM node individually */
- amdgpu_res_first(bo->resource, 0, (u64)num_pages << PAGE_SHIFT,
-);
- while (cursor.remaining) {
- if (place->fpfn < PFN_DOWN(cursor.start + cursor.size)
- && !(place->lpfn &&
-place->lpfn <= PFN_DOWN(cursor.start)))
- return true;
-
- amdgpu_res_next(, cursor.size);
- }
+ if (bo->resource->mem_type == TTM_PL_TT &&
+ amdgpu_bo_encrypted(ttm_to_amdgpu_bo(bo)))
return false;
- default:
- break;
- }
-
return ttm_bo_eviction_valuable(bo, place);
}
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index c1bd006a5525..f066e8124c50 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -518,6 +518,9 @@ static int ttm_bo_evict(struct ttm_buffer_object *bo,
bool ttm_bo_eviction_valuable(struct ttm_buffer_object *bo,
const struct ttm_place *place)
{
+ struct ttm_resource *res = bo->resource;
+ struct ttm_device *bdev = bo->bdev;
+
dma_resv_assert_held(bo->base.resv);
if (bo->resource->mem_type == TTM_PL_SYSTEM)
return true;
@@ -525,11 +528,7 @@ bool ttm_bo_eviction_valuable(struct ttm_buffer_object *bo,
/* Don't evict this BO if it's outside of the
* requested placement range
*/
- if (place->fpfn >= (bo->resource->start + bo->resource->num_pages) ||
- (place->lpfn && place->lpfn <= bo->resource->start))
- return false;
-
- return true;
+ return ttm_resource_intersects(bdev, res, place, bo->base.size);
}
EXPORT_SYMBOL(ttm_bo_eviction_valuable);
diff --git a/drivers/gpu/drm/ttm/ttm_resource.c
b/drivers/gpu/drm/ttm/ttm_resource.c
index ea67976f1f60..a729c32a1e48 100644
--- a/drivers/gpu/drm/ttm/ttm_resource.c
+++ b/drivers/gpu/drm/ttm/ttm_resource.c
@@ -316,6 +316,8 @@ static bool ttm_resource_places_compat(struct ttm_resource
*res,
[PATCH v5 2/6] drm/ttm: Implement intersect/compatible functions
Implemented a new intersect and compatible callback functions
to ttm range manager fetching start offset from drm mm range
allocator.
Signed-off-by: Christian König
Signed-off-by: Arunpravin Paneer Selvam
---
drivers/gpu/drm/ttm/ttm_range_manager.c | 33 +
1 file changed, 33 insertions(+)
diff --git a/drivers/gpu/drm/ttm/ttm_range_manager.c
b/drivers/gpu/drm/ttm/ttm_range_manager.c
index d91666721dc6..4cfef2b3514d 100644
--- a/drivers/gpu/drm/ttm/ttm_range_manager.c
+++ b/drivers/gpu/drm/ttm/ttm_range_manager.c
@@ -113,6 +113,37 @@ static void ttm_range_man_free(struct ttm_resource_manager
*man,
kfree(node);
}
+static bool ttm_range_man_intersects(struct ttm_resource_manager *man,
+struct ttm_resource *res,
+const struct ttm_place *place,
+size_t size)
+{
+ struct drm_mm_node *node = _ttm_range_mgr_node(res)->mm_nodes[0];
+ u32 num_pages = PFN_UP(size);
+
+ /* Don't evict BOs outside of the requested placement range */
+ if (place->fpfn >= (node->start + num_pages) ||
+ (place->lpfn && place->lpfn <= node->start))
+ return false;
+
+ return true;
+}
+
+static bool ttm_range_man_compatible(struct ttm_resource_manager *man,
+struct ttm_resource *res,
+const struct ttm_place *place,
+size_t size)
+{
+ struct drm_mm_node *node = _ttm_range_mgr_node(res)->mm_nodes[0];
+ u32 num_pages = PFN_UP(size);
+
+ if (node->start < place->fpfn ||
+ (place->lpfn && (node->start + num_pages) > place->lpfn))
+ return false;
+
+ return true;
+}
+
static void ttm_range_man_debug(struct ttm_resource_manager *man,
struct drm_printer *printer)
{
@@ -126,6 +157,8 @@ static void ttm_range_man_debug(struct ttm_resource_manager
*man,
static const struct ttm_resource_manager_func ttm_range_manager_func = {
.alloc = ttm_range_man_alloc,
.free = ttm_range_man_free,
+ .intersects = ttm_range_man_intersects,
+ .compatible = ttm_range_man_compatible,
.debug = ttm_range_man_debug
};
--
2.25.1
[PATCH v5 1/6] drm/ttm: Add new callbacks to ttm res mgr
We are adding two new callbacks to ttm resource manager
function to handle intersection and compatibility of
placement and resources.
v2: move the amdgpu and ttm_range_manager changes to
separate patches (Christian)
v3: rename "intersect" to "intersects" (Matthew)
v4: move !place check to the !res if and return false
in ttm_resource_compatible() function (Christian)
Signed-off-by: Christian König
Signed-off-by: Arunpravin Paneer Selvam
---
drivers/gpu/drm/ttm/ttm_resource.c | 59 ++
include/drm/ttm/ttm_resource.h | 40
2 files changed, 99 insertions(+)
diff --git a/drivers/gpu/drm/ttm/ttm_resource.c
b/drivers/gpu/drm/ttm/ttm_resource.c
index 20f9adcc3235..ea67976f1f60 100644
--- a/drivers/gpu/drm/ttm/ttm_resource.c
+++ b/drivers/gpu/drm/ttm/ttm_resource.c
@@ -253,6 +253,65 @@ void ttm_resource_free(struct ttm_buffer_object *bo,
struct ttm_resource **res)
}
EXPORT_SYMBOL(ttm_resource_free);
+/**
+ * ttm_resource_intersects - test for intersection
+ *
+ * @bdev: TTM device structure
+ * @res: The resource to test
+ * @place: The placement to test
+ * @size: How many bytes the new allocation needs.
+ *
+ * Test if @res intersects with @place and @size. Used for testing if evictions
+ * are valueable or not.
+ *
+ * Returns true if the res placement intersects with @place and @size.
+ */
+bool ttm_resource_intersects(struct ttm_device *bdev,
+struct ttm_resource *res,
+const struct ttm_place *place,
+size_t size)
+{
+ struct ttm_resource_manager *man;
+
+ if (!res)
+ return false;
+
+ man = ttm_manager_type(bdev, res->mem_type);
+ if (!place || !man->func->intersects)
+ return true;
+
+ return man->func->intersects(man, res, place, size);
+}
+
+/**
+ * ttm_resource_compatible - test for compatibility
+ *
+ * @bdev: TTM device structure
+ * @res: The resource to test
+ * @place: The placement to test
+ * @size: How many bytes the new allocation needs.
+ *
+ * Test if @res compatible with @place and @size.
+ *
+ * Returns true if the res placement compatible with @place and @size.
+ */
+bool ttm_resource_compatible(struct ttm_device *bdev,
+struct ttm_resource *res,
+const struct ttm_place *place,
+size_t size)
+{
+ struct ttm_resource_manager *man;
+
+ if (!res || !place)
+ return false;
+
+ man = ttm_manager_type(bdev, res->mem_type);
+ if (!man->func->compatible)
+ return true;
+
+ return man->func->compatible(man, res, place, size);
+}
+
static bool ttm_resource_places_compat(struct ttm_resource *res,
const struct ttm_place *places,
unsigned num_placement)
diff --git a/include/drm/ttm/ttm_resource.h b/include/drm/ttm/ttm_resource.h
index ca89a48c2460..5afc6d664fde 100644
--- a/include/drm/ttm/ttm_resource.h
+++ b/include/drm/ttm/ttm_resource.h
@@ -88,6 +88,38 @@ struct ttm_resource_manager_func {
void (*free)(struct ttm_resource_manager *man,
struct ttm_resource *res);
+ /**
+* struct ttm_resource_manager_func member intersects
+*
+* @man: Pointer to a memory type manager.
+* @res: Pointer to a struct ttm_resource to be checked.
+* @place: Placement to check against.
+* @size: Size of the check.
+*
+* Test if @res intersects with @place + @size. Used to judge if
+* evictions are valueable or not.
+*/
+ bool (*intersects)(struct ttm_resource_manager *man,
+ struct ttm_resource *res,
+ const struct ttm_place *place,
+ size_t size);
+
+ /**
+* struct ttm_resource_manager_func member compatible
+*
+* @man: Pointer to a memory type manager.
+* @res: Pointer to a struct ttm_resource to be checked.
+* @place: Placement to check against.
+* @size: Size of the check.
+*
+* Test if @res compatible with @place + @size. Used to check of
+* the need to move the backing store or not.
+*/
+ bool (*compatible)(struct ttm_resource_manager *man,
+ struct ttm_resource *res,
+ const struct ttm_place *place,
+ size_t size);
+
/**
* struct ttm_resource_manager_func member debug
*
@@ -329,6 +361,14 @@ int ttm_resource_alloc(struct ttm_buffer_object *bo,
const struct ttm_place *place,
struct ttm_resource **res);
void ttm_resource_free(struct ttm_buffer_object *bo, struct ttm_resource
**res);
+bool ttm_resource_intersects(struct ttm_device *bdev,
+
Re: [PATCH 3/4] drm/udl: Kill pending URBs at suspend and disconnect
On Tue, 09 Aug 2022 11:13:46 +0200,
Thomas Zimmermann wrote:
>
> Hi
>
> Am 09.08.22 um 11:03 schrieb Takashi Iwai:
> > On Tue, 09 Aug 2022 09:41:19 +0200,
> > Thomas Zimmermann wrote:
> >>
> >> Hi
> >>
> >> Am 09.08.22 um 09:15 schrieb Takashi Iwai:
> >>> On Tue, 09 Aug 2022 09:13:16 +0200,
> >>> Thomas Zimmermann wrote:
>
> Hi
>
> Am 04.08.22 um 09:58 schrieb Takashi Iwai:
> > At both suspend and disconnect, we should rather cancel the pending
> > URBs immediately. For the suspend case, the display will be turned
> > off, so it makes no sense to process the rendering. And for the
> > disconnect case, the device may be no longer accessible, hence we
> > shouldn't do any submission.
> >
> > Tested-by: Thomas Zimmermann
> > Signed-off-by: Takashi Iwai
> > ---
> > drivers/gpu/drm/udl/udl_drv.h | 2 ++
> > drivers/gpu/drm/udl/udl_main.c| 25 ++---
> > drivers/gpu/drm/udl/udl_modeset.c | 2 ++
> > 3 files changed, 26 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/udl/udl_drv.h
> > b/drivers/gpu/drm/udl/udl_drv.h
> > index f01e50c5b7b7..28aaf75d71cf 100644
> > --- a/drivers/gpu/drm/udl/udl_drv.h
> > +++ b/drivers/gpu/drm/udl/udl_drv.h
> > @@ -39,6 +39,7 @@ struct urb_node {
> > struct urb_list {
> > struct list_head list;
> > + struct list_head in_flight;
> > spinlock_t lock;
> > wait_queue_head_t sleep;
> > int available;
> > @@ -84,6 +85,7 @@ static inline struct urb *udl_get_urb(struct
> > drm_device *dev)
> > int udl_submit_urb(struct drm_device *dev, struct urb *urb,
> > size_t len);
> > int udl_sync_pending_urbs(struct drm_device *dev);
> > +void udl_kill_pending_urbs(struct drm_device *dev);
> > void udl_urb_completion(struct urb *urb);
> > int udl_init(struct udl_device *udl);
> > diff --git a/drivers/gpu/drm/udl/udl_main.c
> > b/drivers/gpu/drm/udl/udl_main.c
> > index 93615648414b..47204b7eb10e 100644
> > --- a/drivers/gpu/drm/udl/udl_main.c
> > +++ b/drivers/gpu/drm/udl/udl_main.c
> > @@ -135,7 +135,7 @@ void udl_urb_completion(struct urb *urb)
> > urb->transfer_buffer_length = udl->urbs.size; /* reset to
> > actual */
> > spin_lock_irqsave(>urbs.lock, flags);
> > - list_add_tail(>entry, >urbs.list);
> > + list_move(>entry, >urbs.list);
> > udl->urbs.available++;
> > spin_unlock_irqrestore(>urbs.lock, flags);
> > @@ -180,6 +180,7 @@ static int udl_alloc_urb_list(struct
> > drm_device *dev, int count, size_t size)
> > retry:
> > udl->urbs.size = size;
> > INIT_LIST_HEAD(>urbs.list);
> > + INIT_LIST_HEAD(>urbs.in_flight);
> > init_waitqueue_head(>urbs.sleep);
> > udl->urbs.count = 0;
> > @@ -246,7 +247,7 @@ struct urb *udl_get_urb_timeout(struct drm_device
> > *dev, long timeout)
> > }
> > unode = list_first_entry(>urbs.list, struct urb_node,
> > entry);
> > - list_del_init(>entry);
> > + list_move(>entry, >urbs.in_flight);
> > udl->urbs.available--;
> > unlock:
> > @@ -279,7 +280,7 @@ int udl_sync_pending_urbs(struct drm_device *dev)
> > spin_lock_irq(>urbs.lock);
> > /* 2 seconds as a sane timeout */
> > if (!wait_event_lock_irq_timeout(udl->urbs.sleep,
> > -udl->urbs.available ==
> > udl->urbs.count,
> > +
> > list_empty(>urbs.in_flight),
> > udl->urbs.lock,
> > msecs_to_jiffies(2000)))
> > ret = -ETIMEDOUT;
> > @@ -287,6 +288,23 @@ int udl_sync_pending_urbs(struct drm_device *dev)
> > return ret;
> > }
> > +/* kill pending URBs */
> > +void udl_kill_pending_urbs(struct drm_device *dev)
> > +{
> > + struct udl_device *udl = to_udl(dev);
> > + struct urb_node *unode;
> > +
> > + spin_lock_irq(>urbs.lock);
> > + while (!list_empty(>urbs.in_flight)) {
> > + unode = list_first_entry(>urbs.in_flight,
> > +struct urb_node, entry);
> > + spin_unlock_irq(>urbs.lock);
> > + usb_kill_urb(unode->urb);
> > + spin_lock_irq(>urbs.lock);
> > + }
> > + spin_unlock_irq(>urbs.lock);
> > +}
> > +
> > int udl_init(struct udl_device *udl)
> > {
> > struct drm_device *dev = >drm;
> > @@ -335,6 +353,7 @@ int udl_drop_usb(struct drm_device *dev)
> > {
> > struct
Re: [PATCH 3/4] drm/udl: Kill pending URBs at suspend and disconnect
Hi
Am 09.08.22 um 11:03 schrieb Takashi Iwai:
On Tue, 09 Aug 2022 09:41:19 +0200,
Thomas Zimmermann wrote:
Hi
Am 09.08.22 um 09:15 schrieb Takashi Iwai:
On Tue, 09 Aug 2022 09:13:16 +0200,
Thomas Zimmermann wrote:
Hi
Am 04.08.22 um 09:58 schrieb Takashi Iwai:
At both suspend and disconnect, we should rather cancel the pending
URBs immediately. For the suspend case, the display will be turned
off, so it makes no sense to process the rendering. And for the
disconnect case, the device may be no longer accessible, hence we
shouldn't do any submission.
Tested-by: Thomas Zimmermann
Signed-off-by: Takashi Iwai
---
drivers/gpu/drm/udl/udl_drv.h | 2 ++
drivers/gpu/drm/udl/udl_main.c| 25 ++---
drivers/gpu/drm/udl/udl_modeset.c | 2 ++
3 files changed, 26 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/udl/udl_drv.h b/drivers/gpu/drm/udl/udl_drv.h
index f01e50c5b7b7..28aaf75d71cf 100644
--- a/drivers/gpu/drm/udl/udl_drv.h
+++ b/drivers/gpu/drm/udl/udl_drv.h
@@ -39,6 +39,7 @@ struct urb_node {
struct urb_list {
struct list_head list;
+ struct list_head in_flight;
spinlock_t lock;
wait_queue_head_t sleep;
int available;
@@ -84,6 +85,7 @@ static inline struct urb *udl_get_urb(struct drm_device *dev)
int udl_submit_urb(struct drm_device *dev, struct urb *urb,
size_t len);
int udl_sync_pending_urbs(struct drm_device *dev);
+void udl_kill_pending_urbs(struct drm_device *dev);
void udl_urb_completion(struct urb *urb);
int udl_init(struct udl_device *udl);
diff --git a/drivers/gpu/drm/udl/udl_main.c b/drivers/gpu/drm/udl/udl_main.c
index 93615648414b..47204b7eb10e 100644
--- a/drivers/gpu/drm/udl/udl_main.c
+++ b/drivers/gpu/drm/udl/udl_main.c
@@ -135,7 +135,7 @@ void udl_urb_completion(struct urb *urb)
urb->transfer_buffer_length = udl->urbs.size; /* reset to actual */
spin_lock_irqsave(>urbs.lock, flags);
- list_add_tail(>entry, >urbs.list);
+ list_move(>entry, >urbs.list);
udl->urbs.available++;
spin_unlock_irqrestore(>urbs.lock, flags);
@@ -180,6 +180,7 @@ static int udl_alloc_urb_list(struct
drm_device *dev, int count, size_t size)
retry:
udl->urbs.size = size;
INIT_LIST_HEAD(>urbs.list);
+ INIT_LIST_HEAD(>urbs.in_flight);
init_waitqueue_head(>urbs.sleep);
udl->urbs.count = 0;
@@ -246,7 +247,7 @@ struct urb *udl_get_urb_timeout(struct drm_device *dev,
long timeout)
}
unode = list_first_entry(>urbs.list, struct urb_node,
entry);
- list_del_init(>entry);
+ list_move(>entry, >urbs.in_flight);
udl->urbs.available--;
unlock:
@@ -279,7 +280,7 @@ int udl_sync_pending_urbs(struct drm_device *dev)
spin_lock_irq(>urbs.lock);
/* 2 seconds as a sane timeout */
if (!wait_event_lock_irq_timeout(udl->urbs.sleep,
-udl->urbs.available == udl->urbs.count,
+list_empty(>urbs.in_flight),
udl->urbs.lock,
msecs_to_jiffies(2000)))
ret = -ETIMEDOUT;
@@ -287,6 +288,23 @@ int udl_sync_pending_urbs(struct drm_device *dev)
return ret;
}
+/* kill pending URBs */
+void udl_kill_pending_urbs(struct drm_device *dev)
+{
+ struct udl_device *udl = to_udl(dev);
+ struct urb_node *unode;
+
+ spin_lock_irq(>urbs.lock);
+ while (!list_empty(>urbs.in_flight)) {
+ unode = list_first_entry(>urbs.in_flight,
+struct urb_node, entry);
+ spin_unlock_irq(>urbs.lock);
+ usb_kill_urb(unode->urb);
+ spin_lock_irq(>urbs.lock);
+ }
+ spin_unlock_irq(>urbs.lock);
+}
+
int udl_init(struct udl_device *udl)
{
struct drm_device *dev = >drm;
@@ -335,6 +353,7 @@ int udl_drop_usb(struct drm_device *dev)
{
struct udl_device *udl = to_udl(dev);
+ udl_kill_pending_urbs(dev);
udl_free_urb_list(dev);
put_device(udl->dmadev);
udl->dmadev = NULL;
diff --git a/drivers/gpu/drm/udl/udl_modeset.c
b/drivers/gpu/drm/udl/udl_modeset.c
index 50025606b6ad..169110d8fc2e 100644
--- a/drivers/gpu/drm/udl/udl_modeset.c
+++ b/drivers/gpu/drm/udl/udl_modeset.c
@@ -397,6 +397,8 @@ udl_simple_display_pipe_disable(struct
drm_simple_display_pipe *pipe)
struct urb *urb;
char *buf;
+ udl_kill_pending_urbs(dev);
+
I already reviewed the patchset, but I have another comment. I think
we should only kill urbs from within the suspend handler. Same for the
call to the URB-sync function in patch 2.
This disable function is part of the regular modeset path. It's
probably not appropriate to outright remove pending URBs here. This
can lead to failed modesets, which would have succeeded otherwise.
Well, the device shall be
Re: [Linaro-mm-sig] Re: [PATCH v2] drm/gem: Fix GEM handle release errors
Hi Jeffy, Am 09.08.22 um 09:55 schrieb Christian König: [SNIP] So we are allowing GEM object to have multiple handles, and GEM object could have at most one dma-buf, doesn't that means that dma-buf could map to multiple handles? No, at least not for the same GEM file private. That's the reason why the rb is indexed by the dma_buf object and not the handle. In other words the rb is so that you have exactly one handle for each dma_buf in each file private. I don't think so, because if user get multiple handles for the same GEM obj and use drm_gem_prime_handle_to_fd() for those handles Mhm, that works? This is illegal and should have been prevented somehow. At least I see the problem now. I'm just not sure how to fix it. Your v2 patch indeed prevents leakage of the drm_prime_member for the additional handles, but those shouldn't have been added in the first place. The issue is that with this we make it unpredictable which handle is returned. E.g. if we have handle 2,5,7 it can be that because of re-balancing the tree sometimes 2 and sometimes 5 is returned. That's not really a good idea and breaks a couple of assumptions as far as I know. Ideas? Thanks, Christian.
Re: [PATCH 3/4] drm/udl: Kill pending URBs at suspend and disconnect
On Tue, 09 Aug 2022 09:41:19 +0200,
Thomas Zimmermann wrote:
>
> Hi
>
> Am 09.08.22 um 09:15 schrieb Takashi Iwai:
> > On Tue, 09 Aug 2022 09:13:16 +0200,
> > Thomas Zimmermann wrote:
> >>
> >> Hi
> >>
> >> Am 04.08.22 um 09:58 schrieb Takashi Iwai:
> >>> At both suspend and disconnect, we should rather cancel the pending
> >>> URBs immediately. For the suspend case, the display will be turned
> >>> off, so it makes no sense to process the rendering. And for the
> >>> disconnect case, the device may be no longer accessible, hence we
> >>> shouldn't do any submission.
> >>>
> >>> Tested-by: Thomas Zimmermann
> >>> Signed-off-by: Takashi Iwai
> >>> ---
> >>>drivers/gpu/drm/udl/udl_drv.h | 2 ++
> >>>drivers/gpu/drm/udl/udl_main.c| 25 ++---
> >>>drivers/gpu/drm/udl/udl_modeset.c | 2 ++
> >>>3 files changed, 26 insertions(+), 3 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/udl/udl_drv.h b/drivers/gpu/drm/udl/udl_drv.h
> >>> index f01e50c5b7b7..28aaf75d71cf 100644
> >>> --- a/drivers/gpu/drm/udl/udl_drv.h
> >>> +++ b/drivers/gpu/drm/udl/udl_drv.h
> >>> @@ -39,6 +39,7 @@ struct urb_node {
> >>> struct urb_list {
> >>> struct list_head list;
> >>> + struct list_head in_flight;
> >>> spinlock_t lock;
> >>> wait_queue_head_t sleep;
> >>> int available;
> >>> @@ -84,6 +85,7 @@ static inline struct urb *udl_get_urb(struct drm_device
> >>> *dev)
> >>> int udl_submit_urb(struct drm_device *dev, struct urb *urb,
> >>> size_t len);
> >>>int udl_sync_pending_urbs(struct drm_device *dev);
> >>> +void udl_kill_pending_urbs(struct drm_device *dev);
> >>>void udl_urb_completion(struct urb *urb);
> >>> int udl_init(struct udl_device *udl);
> >>> diff --git a/drivers/gpu/drm/udl/udl_main.c
> >>> b/drivers/gpu/drm/udl/udl_main.c
> >>> index 93615648414b..47204b7eb10e 100644
> >>> --- a/drivers/gpu/drm/udl/udl_main.c
> >>> +++ b/drivers/gpu/drm/udl/udl_main.c
> >>> @@ -135,7 +135,7 @@ void udl_urb_completion(struct urb *urb)
> >>> urb->transfer_buffer_length = udl->urbs.size; /* reset to
> >>> actual */
> >>> spin_lock_irqsave(>urbs.lock, flags);
> >>> - list_add_tail(>entry, >urbs.list);
> >>> + list_move(>entry, >urbs.list);
> >>> udl->urbs.available++;
> >>> spin_unlock_irqrestore(>urbs.lock, flags);
> >>>@@ -180,6 +180,7 @@ static int udl_alloc_urb_list(struct
> >>> drm_device *dev, int count, size_t size)
> >>>retry:
> >>> udl->urbs.size = size;
> >>> INIT_LIST_HEAD(>urbs.list);
> >>> + INIT_LIST_HEAD(>urbs.in_flight);
> >>> init_waitqueue_head(>urbs.sleep);
> >>> udl->urbs.count = 0;
> >>> @@ -246,7 +247,7 @@ struct urb *udl_get_urb_timeout(struct drm_device
> >>> *dev, long timeout)
> >>> }
> >>> unode = list_first_entry(>urbs.list, struct urb_node,
> >>> entry);
> >>> - list_del_init(>entry);
> >>> + list_move(>entry, >urbs.in_flight);
> >>> udl->urbs.available--;
> >>> unlock:
> >>> @@ -279,7 +280,7 @@ int udl_sync_pending_urbs(struct drm_device *dev)
> >>> spin_lock_irq(>urbs.lock);
> >>> /* 2 seconds as a sane timeout */
> >>> if (!wait_event_lock_irq_timeout(udl->urbs.sleep,
> >>> - udl->urbs.available == udl->urbs.count,
> >>> + list_empty(>urbs.in_flight),
> >>>udl->urbs.lock,
> >>>msecs_to_jiffies(2000)))
> >>> ret = -ETIMEDOUT;
> >>> @@ -287,6 +288,23 @@ int udl_sync_pending_urbs(struct drm_device *dev)
> >>> return ret;
> >>>}
> >>>+/* kill pending URBs */
> >>> +void udl_kill_pending_urbs(struct drm_device *dev)
> >>> +{
> >>> + struct udl_device *udl = to_udl(dev);
> >>> + struct urb_node *unode;
> >>> +
> >>> + spin_lock_irq(>urbs.lock);
> >>> + while (!list_empty(>urbs.in_flight)) {
> >>> + unode = list_first_entry(>urbs.in_flight,
> >>> + struct urb_node, entry);
> >>> + spin_unlock_irq(>urbs.lock);
> >>> + usb_kill_urb(unode->urb);
> >>> + spin_lock_irq(>urbs.lock);
> >>> + }
> >>> + spin_unlock_irq(>urbs.lock);
> >>> +}
> >>> +
> >>>int udl_init(struct udl_device *udl)
> >>>{
> >>> struct drm_device *dev = >drm;
> >>> @@ -335,6 +353,7 @@ int udl_drop_usb(struct drm_device *dev)
> >>>{
> >>> struct udl_device *udl = to_udl(dev);
> >>>+ udl_kill_pending_urbs(dev);
> >>> udl_free_urb_list(dev);
> >>> put_device(udl->dmadev);
> >>> udl->dmadev = NULL;
> >>> diff --git a/drivers/gpu/drm/udl/udl_modeset.c
> >>> b/drivers/gpu/drm/udl/udl_modeset.c
> >>> index 50025606b6ad..169110d8fc2e 100644
> >>> --- a/drivers/gpu/drm/udl/udl_modeset.c
> >>> +++ b/drivers/gpu/drm/udl/udl_modeset.c
> >>> @@ -397,6 +397,8 @@
Re: [PATCH v2] drm/gem: Fix GEM handle release errors
Hi Christian,
On 8/9 星期二 15:55, Christian König wrote:
Am 09.08.22 um 03:28 schrieb Chen Jeffy:
Hi Christian,
On 8/9 星期二 2:03, Christian König wrote:
Hi Jeffy,
Am 08.08.22 um 05:51 schrieb Chen Jeffy:
Hi Christian,
Thanks for your reply, and sorry i didn't make it clear.
On 8/8 星期一 0:52, Christian König wrote:
Am 03.08.22 um 10:32 schrieb Jeffy Chen:
Currently we are assuming a one to one mapping between dmabuf and
handle
when releasing GEM handles.
But that is not always true, since we would create extra handles
for the
GEM obj in cases like gem_open() and getfb{,2}().
A similar issue was reported at:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Fall%2F20211105083308.392156-1-jay.xu%40rock-chips.com%2Fdata=05%7C01%7Cchristian.koenig%40amd.com%7C52cd6ca16a3a415b92a708da79a67dec%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637956053232922419%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=hIuH18B10sbVAyS0D4iK6R6WYc%2BZ7mlxGcKdUae%2BW6Y%3Dreserved=0
Another problem is that the drm_gem_remove_prime_handles() now only
remove handle to the exported dmabuf (gem_obj->dma_buf), so the
imported
ones would leak:
WARNING: CPU: 2 PID: 236 at drivers/gpu/drm/drm_prime.c:228
drm_prime_destroy_file_private+0x18/0x24
Let's fix these by using handle to find the exact map to remove.
Well we are clearly something missing here. As far as I can see the
current code is correct.
Creating multiple GEM handles for the same DMA-buf is possible, but
illegal. >
In other words when a GEM handle is exported as DMA-buf and
imported again you should intentionally always get the same handle.
These issue are not about having handles for importing an exported
dma-buf case, but for having multiple handles to a GEM object(which
means having multiple handles to a dma-buf).
I know the drm-prime is trying to make dma-buf and handle maps one
to one, but the drm-gem is allowing to create extra handles for a
GEM object, for example:
drm_gem_open_ioctl -> drm_gem_handle_create_tail
drm_mode_getfb2_ioctl -> drm_gem_handle_create
drm_mode_getfb -> fb->funcs->create_handle
Yes, so far that's correct.
So we are allowing GEM object to have multiple handles, and GEM
object could have at most one dma-buf, doesn't that means that
dma-buf could map to multiple handles?
No, at least not for the same GEM file private. That's the reason why
the rb is indexed by the dma_buf object and not the handle.
In other words the rb is so that you have exactly one handle for each
dma_buf in each file private.
I don't think so, because if user get multiple handles for the same
GEM obj and use drm_gem_prime_handle_to_fd() for those handles
Mhm, that works? This is illegal and should have been prevented somehow.
Let me double check the code.
Thanks for pointing that out,
Christian.
Thanks for checking it, my test case is a preload library which hooks
the drmModeSetCrtc(and other APIs) then use drmModeGetFB to extract
dmafd from fb_id.
, the current code would try to add multiple maps to rb:
drm_prime_add_buf_handle(buf_1, hdl_1)
drm_prime_add_buf_handle(buf_1, hdl_2)
...
drm_prime_add_buf_handle(buf_1, hdl_n)
Or should we rewrite the GEM framework to limit GEM object with uniq
handle?
No, the extra handles are expected because when you call
drm_mode_getfb*() and drm_gem_open_ioctl() the caller now owns the
returned GEM handle.
The other issue is that we are leaking dma-buf <-> handle map for
the imported dma-buf, since the drm_gem_remove_prime_handles doesn't
take care of obj->import_attach->dmabuf.
No, that's correct as well. obj->dma_buf is set even for imported
DMA-buf objects. See drm_gem_prime_fd_to_handle().
Well, that obj->dma_buf would be set in
drm_gem_prime_fd_to_handle(create new handle), and cleared when
releasing the latest handle(release handle).
So it doesn't cover other handle creating path.
For example, a imported dma buf:
drm_gem_prime_fd_to_handle <-- we got a handle and obj->dma_buf and
obj->import_attach->dmabuf
drm_gem_handle_delete <-- we lost that handle and obj->dma_buf cleared
drm_gem_open_ioctl/or getfb* <-- we got a new handle and
obj->import_attach->dmabuf
drm_gem_handle_delete <-- we lost that handle and obj->dma_buf is
null, which means rb leaks.
Another way to solve this would be set this obj->dma_buf again in
drm_gem_prime_handle_to_fd(), which would make sure obj->dma_buf is
valid in all current paths lead to drm_prime_add_buf_handle().
Regards,
Christian.
But of cause this can be fixed in other way:
+++ b/drivers/gpu/drm/drm_gem.c
@@ -180,6 +180,9 @@ drm_gem_remove_prime_handles(struct
drm_gem_object *obj, struct drm_file *filp)
drm_prime_remove_buf_handle_locked(>prime,
obj->dma_buf);
}
+ if (obj->import_attach)
+ drm_prime_remove_buf_handle_locked(>prime,
+ obj->import_attach->dmabuf);
Re: New subsystem for acceleration devices
On Tue, Aug 09, 2022 at 01:04:15AM -0700, Christoph Hellwig wrote: > On Tue, Aug 09, 2022 at 08:23:27AM +0200, Greg Kroah-Hartman wrote: > > Based on the number of drivers that I see submitted weekly that try to > > restrict their open call to just one user by using atomic variables or > > other tricks, I think my interpretation of this stands :) > > I think they really want what Jason described most of the time. They > just don't know about the pitfalls of dup yet. > > > > This is different from the number of FDs pointing at the struct file. > > > Userpsace can open a HW state and point a lot of FDs at it, that is > > > userspace's problem. From a kernel view they all share one struct file > > > and thus one HW state. > > > > Yes, that's fine, if that is what is happening here, I have no > > objection. > > It would be great if we could actually life that into a common > layer (chardev or vfs) given just how common this, and drivers tend > to get it wrong, do it suboptimal so often. No objection from me, I'll gladly take patches to chardev or miscdev to support this. greg k-h
Re: New subsystem for acceleration devices
On Tue, Aug 9, 2022 at 10:04 AM Christoph Hellwig wrote: > On Tue, Aug 09, 2022 at 08:23:27AM +0200, Greg Kroah-Hartman wrote: > > > This is different from the number of FDs pointing at the struct file. > > > Userpsace can open a HW state and point a lot of FDs at it, that is > > > userspace's problem. From a kernel view they all share one struct file > > > and thus one HW state. > > > > Yes, that's fine, if that is what is happening here, I have no > > objection. > > It would be great if we could actually life that into a common > layer (chardev or vfs) given just how common this, and drivers tend > to get it wrong, do it suboptimal so often. Totally agreed. I think for devices with hardware MMU contexts you actually want to bind the context to a 'mm_struct', and then ensure that the context is only ever used from a process that shares this mm_struct, regardless of who else has access to the same file or inode. We did this in a somewhat hacky way in spufs a long time ago, and I would expect this to be solved more cleanly in drivers/gpu/drm, but I don't know where to look for that code. Arnd
Re: [Intel-gfx] [PATCH v5 1/7] drm: Move and add a few utility macros into drm util header
On 8/4/22 12:06 PM, Andi Shyti wrote: Hi Jani, It moves overflows_type utility macro into drm util header from i915_utils header. The overflows_type can be used to catch the truncation between data types. And it adds safe_conversion() macro which performs a type conversion (cast) of an source value into a new variable, checking that the destination is large enough to hold the source value. And it adds exact_type and exactly_pgoff_t macro to catch type mis-match while compiling. v3: Add is_type_unsigned() macro (Mauro) Modify overflows_type() macro to consider signed data types (Mauro) Fix the problem that safe_conversion() macro always returns true v4: Fix kernel-doc markups Signed-off-by: Gwan-gyeong Mun Cc: Thomas Hellström Cc: Matthew Auld Cc: Nirmoy Das Cc: Jani Nikula Reviewed-by: Mauro Carvalho Chehab --- drivers/gpu/drm/i915/i915_utils.h | 5 +- include/drm/drm_util.h| 77 +++ 2 files changed, 78 insertions(+), 4 deletions(-) Jani and Mauro suggested to have this macro in include/drm/drm_util.h. I can't recall suggesting such a thing. The macros in question have nothing specifically to do with i915 *or* drm. They are generic, and should be in generic kernel headers. We must stop piling up generic and generally useful stuff in our own headers. Yes, I agree with you and I think there was already such discussion whether to move this into generic kernel headers or in drm header. Gwan-gyeong, any thoughts or further plans to move this to a different place? It's been already three people (and I'm including myself here) recommending to have this in a different place. Andi Yes, except for the i915, there was no use case in the code, so I moved the header file here, but thanks to many people's comments, I will move these utility macros to a more generic place and send a new patch. Thank you for checking again and for your comments. Many thanks, Andi, Jani, Mauro. G.G. I thought I've been clear about this all along. Thanks, Jani! Andi
Re: [PATCH v2 2/6] drm/ttm: Implement intersect/compatible functions
On 8/8/2022 5:00 PM, Christian König wrote:
Am 25.07.22 um 13:42 schrieb Arunpravin Paneer Selvam:
Implemented a new intersect and compatible callback functions
to ttm range manager fetching start offset from drm mm range
allocator.
Signed-off-by: Christian König
Signed-off-by: Arunpravin Paneer Selvam
---
drivers/gpu/drm/ttm/ttm_range_manager.c | 33 +
1 file changed, 33 insertions(+)
diff --git a/drivers/gpu/drm/ttm/ttm_range_manager.c
b/drivers/gpu/drm/ttm/ttm_range_manager.c
index d91666721dc6..12b8d9b36fe6 100644
--- a/drivers/gpu/drm/ttm/ttm_range_manager.c
+++ b/drivers/gpu/drm/ttm/ttm_range_manager.c
@@ -113,6 +113,37 @@ static void ttm_range_man_free(struct
ttm_resource_manager *man,
kfree(node);
}
+static bool ttm_range_man_intersect(struct ttm_resource_manager *man,
+ struct ttm_resource *res,
+ const struct ttm_place *place,
+ size_t size)
+{
+ struct drm_mm_node *node =
_ttm_range_mgr_node(res)->mm_nodes[0];
+ u32 num_pages = PFN_UP(size);
+
+ /* Don't evict BOs outside of the requested placement range */
+ if (place->fpfn >= (node->start + num_pages) ||
+ (place->lpfn && place->lpfn <= node->start))
+ return false;
+
+ return true;
+}
+
+static bool ttm_range_man_compatible(struct ttm_resource_manager *man,
+ struct ttm_resource *res,
+ const struct ttm_place *place,
+ size_t size)
+{
+ struct drm_mm_node *node =
_ttm_range_mgr_node(res)->mm_nodes[0];
+ u32 num_pages = PFN_UP(size);
+
+ if (node->start < place->fpfn ||
This should probably be "<=".
We are checking the false condition here, if node->start == place->fpfn,
then the node->start
value is compatible with place->fpfn, therefore, we don't return false.
Thanks,
Arun
Regards,
Christian.
+ (place->lpfn && (node->start + num_pages) > place->lpfn))
+ return false;
+
+ return true;
+}
+
static void ttm_range_man_debug(struct ttm_resource_manager *man,
struct drm_printer *printer)
{
@@ -126,6 +157,8 @@ static void ttm_range_man_debug(struct
ttm_resource_manager *man,
static const struct ttm_resource_manager_func
ttm_range_manager_func = {
.alloc = ttm_range_man_alloc,
.free = ttm_range_man_free,
+ .intersect = ttm_range_man_intersect,
+ .compatible = ttm_range_man_compatible,
.debug = ttm_range_man_debug
};
Re: [PATCH v2] drm/gem: Fix GEM handle release errors
Am 09.08.22 um 03:28 schrieb Chen Jeffy:
Hi Christian,
On 8/9 星期二 2:03, Christian König wrote:
Hi Jeffy,
Am 08.08.22 um 05:51 schrieb Chen Jeffy:
Hi Christian,
Thanks for your reply, and sorry i didn't make it clear.
On 8/8 星期一 0:52, Christian König wrote:
Am 03.08.22 um 10:32 schrieb Jeffy Chen:
Currently we are assuming a one to one mapping between dmabuf and
handle
when releasing GEM handles.
But that is not always true, since we would create extra handles
for the
GEM obj in cases like gem_open() and getfb{,2}().
A similar issue was reported at:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Fall%2F20211105083308.392156-1-jay.xu%40rock-chips.com%2Fdata=05%7C01%7Cchristian.koenig%40amd.com%7C52cd6ca16a3a415b92a708da79a67dec%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637956053232922419%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=hIuH18B10sbVAyS0D4iK6R6WYc%2BZ7mlxGcKdUae%2BW6Y%3Dreserved=0
Another problem is that the drm_gem_remove_prime_handles() now only
remove handle to the exported dmabuf (gem_obj->dma_buf), so the
imported
ones would leak:
WARNING: CPU: 2 PID: 236 at drivers/gpu/drm/drm_prime.c:228
drm_prime_destroy_file_private+0x18/0x24
Let's fix these by using handle to find the exact map to remove.
Well we are clearly something missing here. As far as I can see the
current code is correct.
Creating multiple GEM handles for the same DMA-buf is possible, but
illegal. >
In other words when a GEM handle is exported as DMA-buf and
imported again you should intentionally always get the same handle.
These issue are not about having handles for importing an exported
dma-buf case, but for having multiple handles to a GEM object(which
means having multiple handles to a dma-buf).
I know the drm-prime is trying to make dma-buf and handle maps one
to one, but the drm-gem is allowing to create extra handles for a
GEM object, for example:
drm_gem_open_ioctl -> drm_gem_handle_create_tail
drm_mode_getfb2_ioctl -> drm_gem_handle_create
drm_mode_getfb -> fb->funcs->create_handle
Yes, so far that's correct.
So we are allowing GEM object to have multiple handles, and GEM
object could have at most one dma-buf, doesn't that means that
dma-buf could map to multiple handles?
No, at least not for the same GEM file private. That's the reason why
the rb is indexed by the dma_buf object and not the handle.
In other words the rb is so that you have exactly one handle for each
dma_buf in each file private.
I don't think so, because if user get multiple handles for the same
GEM obj and use drm_gem_prime_handle_to_fd() for those handles
Mhm, that works? This is illegal and should have been prevented somehow.
Let me double check the code.
Thanks for pointing that out,
Christian.
, the current code would try to add multiple maps to rb:
drm_prime_add_buf_handle(buf_1, hdl_1)
drm_prime_add_buf_handle(buf_1, hdl_2)
...
drm_prime_add_buf_handle(buf_1, hdl_n)
Or should we rewrite the GEM framework to limit GEM object with uniq
handle?
No, the extra handles are expected because when you call
drm_mode_getfb*() and drm_gem_open_ioctl() the caller now owns the
returned GEM handle.
The other issue is that we are leaking dma-buf <-> handle map for
the imported dma-buf, since the drm_gem_remove_prime_handles doesn't
take care of obj->import_attach->dmabuf.
No, that's correct as well. obj->dma_buf is set even for imported
DMA-buf objects. See drm_gem_prime_fd_to_handle().
Well, that obj->dma_buf would be set in
drm_gem_prime_fd_to_handle(create new handle), and cleared when
releasing the latest handle(release handle).
So it doesn't cover other handle creating path.
For example, a imported dma buf:
drm_gem_prime_fd_to_handle <-- we got a handle and obj->dma_buf and
obj->import_attach->dmabuf
drm_gem_handle_delete <-- we lost that handle and obj->dma_buf cleared
drm_gem_open_ioctl/or getfb* <-- we got a new handle and
obj->import_attach->dmabuf
drm_gem_handle_delete <-- we lost that handle and obj->dma_buf is
null, which means rb leaks.
Regards,
Christian.
But of cause this can be fixed in other way:
+++ b/drivers/gpu/drm/drm_gem.c
@@ -180,6 +180,9 @@ drm_gem_remove_prime_handles(struct
drm_gem_object *obj, struct drm_file *filp)
drm_prime_remove_buf_handle_locked(>prime,
obj->dma_buf);
}
+ if (obj->import_attach)
+ drm_prime_remove_buf_handle_locked(>prime,
+ obj->import_attach->dmabuf);
mutex_unlock(>prime.lock);
}
So this is pretty much a clear NAK to this patch since it shouldn't
be necessary or something is seriously broken somewhere else.
Regards,
Christian.
Signed-off-by: Jeffy Chen
---
Changes in v2:
Fix a typo of rbtree.
drivers/gpu/drm/drm_gem.c | 17 +
drivers/gpu/drm/drm_internal.h | 4 ++--
drivers/gpu/drm/drm_prime.c | 20
3 files changed, 15
Re: [PATCH 3/4] drm/udl: Kill pending URBs at suspend and disconnect
Hi
Am 09.08.22 um 09:15 schrieb Takashi Iwai:
On Tue, 09 Aug 2022 09:13:16 +0200,
Thomas Zimmermann wrote:
Hi
Am 04.08.22 um 09:58 schrieb Takashi Iwai:
At both suspend and disconnect, we should rather cancel the pending
URBs immediately. For the suspend case, the display will be turned
off, so it makes no sense to process the rendering. And for the
disconnect case, the device may be no longer accessible, hence we
shouldn't do any submission.
Tested-by: Thomas Zimmermann
Signed-off-by: Takashi Iwai
---
drivers/gpu/drm/udl/udl_drv.h | 2 ++
drivers/gpu/drm/udl/udl_main.c| 25 ++---
drivers/gpu/drm/udl/udl_modeset.c | 2 ++
3 files changed, 26 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/udl/udl_drv.h b/drivers/gpu/drm/udl/udl_drv.h
index f01e50c5b7b7..28aaf75d71cf 100644
--- a/drivers/gpu/drm/udl/udl_drv.h
+++ b/drivers/gpu/drm/udl/udl_drv.h
@@ -39,6 +39,7 @@ struct urb_node {
struct urb_list {
struct list_head list;
+ struct list_head in_flight;
spinlock_t lock;
wait_queue_head_t sleep;
int available;
@@ -84,6 +85,7 @@ static inline struct urb *udl_get_urb(struct drm_device *dev)
int udl_submit_urb(struct drm_device *dev, struct urb *urb,
size_t len);
int udl_sync_pending_urbs(struct drm_device *dev);
+void udl_kill_pending_urbs(struct drm_device *dev);
void udl_urb_completion(struct urb *urb);
int udl_init(struct udl_device *udl);
diff --git a/drivers/gpu/drm/udl/udl_main.c b/drivers/gpu/drm/udl/udl_main.c
index 93615648414b..47204b7eb10e 100644
--- a/drivers/gpu/drm/udl/udl_main.c
+++ b/drivers/gpu/drm/udl/udl_main.c
@@ -135,7 +135,7 @@ void udl_urb_completion(struct urb *urb)
urb->transfer_buffer_length = udl->urbs.size; /* reset to actual */
spin_lock_irqsave(>urbs.lock, flags);
- list_add_tail(>entry, >urbs.list);
+ list_move(>entry, >urbs.list);
udl->urbs.available++;
spin_unlock_irqrestore(>urbs.lock, flags);
@@ -180,6 +180,7 @@ static int udl_alloc_urb_list(struct
drm_device *dev, int count, size_t size)
retry:
udl->urbs.size = size;
INIT_LIST_HEAD(>urbs.list);
+ INIT_LIST_HEAD(>urbs.in_flight);
init_waitqueue_head(>urbs.sleep);
udl->urbs.count = 0;
@@ -246,7 +247,7 @@ struct urb *udl_get_urb_timeout(struct drm_device *dev,
long timeout)
}
unode = list_first_entry(>urbs.list, struct urb_node,
entry);
- list_del_init(>entry);
+ list_move(>entry, >urbs.in_flight);
udl->urbs.available--;
unlock:
@@ -279,7 +280,7 @@ int udl_sync_pending_urbs(struct drm_device *dev)
spin_lock_irq(>urbs.lock);
/* 2 seconds as a sane timeout */
if (!wait_event_lock_irq_timeout(udl->urbs.sleep,
-udl->urbs.available == udl->urbs.count,
+list_empty(>urbs.in_flight),
udl->urbs.lock,
msecs_to_jiffies(2000)))
ret = -ETIMEDOUT;
@@ -287,6 +288,23 @@ int udl_sync_pending_urbs(struct drm_device *dev)
return ret;
}
+/* kill pending URBs */
+void udl_kill_pending_urbs(struct drm_device *dev)
+{
+ struct udl_device *udl = to_udl(dev);
+ struct urb_node *unode;
+
+ spin_lock_irq(>urbs.lock);
+ while (!list_empty(>urbs.in_flight)) {
+ unode = list_first_entry(>urbs.in_flight,
+struct urb_node, entry);
+ spin_unlock_irq(>urbs.lock);
+ usb_kill_urb(unode->urb);
+ spin_lock_irq(>urbs.lock);
+ }
+ spin_unlock_irq(>urbs.lock);
+}
+
int udl_init(struct udl_device *udl)
{
struct drm_device *dev = >drm;
@@ -335,6 +353,7 @@ int udl_drop_usb(struct drm_device *dev)
{
struct udl_device *udl = to_udl(dev);
+udl_kill_pending_urbs(dev);
udl_free_urb_list(dev);
put_device(udl->dmadev);
udl->dmadev = NULL;
diff --git a/drivers/gpu/drm/udl/udl_modeset.c
b/drivers/gpu/drm/udl/udl_modeset.c
index 50025606b6ad..169110d8fc2e 100644
--- a/drivers/gpu/drm/udl/udl_modeset.c
+++ b/drivers/gpu/drm/udl/udl_modeset.c
@@ -397,6 +397,8 @@ udl_simple_display_pipe_disable(struct
drm_simple_display_pipe *pipe)
struct urb *urb;
char *buf;
+udl_kill_pending_urbs(dev);
+
I already reviewed the patchset, but I have another comment. I think
we should only kill urbs from within the suspend handler. Same for the
call to the URB-sync function in patch 2.
This disable function is part of the regular modeset path. It's
probably not appropriate to outright remove pending URBs here. This
can lead to failed modesets, which would have succeeded otherwise.
Well, the device shall be turned off right after that point, so the
all pending rendering makes little sense, no?
udl_simple_display_pipe_disable()
Re: [PATCH 3/4] drm/udl: Kill pending URBs at suspend and disconnect
On Tue, 09 Aug 2022 09:13:16 +0200,
Thomas Zimmermann wrote:
>
> Hi
>
> Am 04.08.22 um 09:58 schrieb Takashi Iwai:
> > At both suspend and disconnect, we should rather cancel the pending
> > URBs immediately. For the suspend case, the display will be turned
> > off, so it makes no sense to process the rendering. And for the
> > disconnect case, the device may be no longer accessible, hence we
> > shouldn't do any submission.
> >
> > Tested-by: Thomas Zimmermann
> > Signed-off-by: Takashi Iwai
> > ---
> > drivers/gpu/drm/udl/udl_drv.h | 2 ++
> > drivers/gpu/drm/udl/udl_main.c| 25 ++---
> > drivers/gpu/drm/udl/udl_modeset.c | 2 ++
> > 3 files changed, 26 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/udl/udl_drv.h b/drivers/gpu/drm/udl/udl_drv.h
> > index f01e50c5b7b7..28aaf75d71cf 100644
> > --- a/drivers/gpu/drm/udl/udl_drv.h
> > +++ b/drivers/gpu/drm/udl/udl_drv.h
> > @@ -39,6 +39,7 @@ struct urb_node {
> > struct urb_list {
> > struct list_head list;
> > + struct list_head in_flight;
> > spinlock_t lock;
> > wait_queue_head_t sleep;
> > int available;
> > @@ -84,6 +85,7 @@ static inline struct urb *udl_get_urb(struct drm_device
> > *dev)
> > int udl_submit_urb(struct drm_device *dev, struct urb *urb,
> > size_t len);
> > int udl_sync_pending_urbs(struct drm_device *dev);
> > +void udl_kill_pending_urbs(struct drm_device *dev);
> > void udl_urb_completion(struct urb *urb);
> > int udl_init(struct udl_device *udl);
> > diff --git a/drivers/gpu/drm/udl/udl_main.c b/drivers/gpu/drm/udl/udl_main.c
> > index 93615648414b..47204b7eb10e 100644
> > --- a/drivers/gpu/drm/udl/udl_main.c
> > +++ b/drivers/gpu/drm/udl/udl_main.c
> > @@ -135,7 +135,7 @@ void udl_urb_completion(struct urb *urb)
> > urb->transfer_buffer_length = udl->urbs.size; /* reset to actual */
> > spin_lock_irqsave(>urbs.lock, flags);
> > - list_add_tail(>entry, >urbs.list);
> > + list_move(>entry, >urbs.list);
> > udl->urbs.available++;
> > spin_unlock_irqrestore(>urbs.lock, flags);
> > @@ -180,6 +180,7 @@ static int udl_alloc_urb_list(struct
> > drm_device *dev, int count, size_t size)
> > retry:
> > udl->urbs.size = size;
> > INIT_LIST_HEAD(>urbs.list);
> > + INIT_LIST_HEAD(>urbs.in_flight);
> > init_waitqueue_head(>urbs.sleep);
> > udl->urbs.count = 0;
> > @@ -246,7 +247,7 @@ struct urb *udl_get_urb_timeout(struct drm_device *dev,
> > long timeout)
> > }
> > unode = list_first_entry(>urbs.list, struct urb_node,
> > entry);
> > - list_del_init(>entry);
> > + list_move(>entry, >urbs.in_flight);
> > udl->urbs.available--;
> > unlock:
> > @@ -279,7 +280,7 @@ int udl_sync_pending_urbs(struct drm_device *dev)
> > spin_lock_irq(>urbs.lock);
> > /* 2 seconds as a sane timeout */
> > if (!wait_event_lock_irq_timeout(udl->urbs.sleep,
> > -udl->urbs.available == udl->urbs.count,
> > +list_empty(>urbs.in_flight),
> > udl->urbs.lock,
> > msecs_to_jiffies(2000)))
> > ret = -ETIMEDOUT;
> > @@ -287,6 +288,23 @@ int udl_sync_pending_urbs(struct drm_device *dev)
> > return ret;
> > }
> > +/* kill pending URBs */
> > +void udl_kill_pending_urbs(struct drm_device *dev)
> > +{
> > + struct udl_device *udl = to_udl(dev);
> > + struct urb_node *unode;
> > +
> > + spin_lock_irq(>urbs.lock);
> > + while (!list_empty(>urbs.in_flight)) {
> > + unode = list_first_entry(>urbs.in_flight,
> > +struct urb_node, entry);
> > + spin_unlock_irq(>urbs.lock);
> > + usb_kill_urb(unode->urb);
> > + spin_lock_irq(>urbs.lock);
> > + }
> > + spin_unlock_irq(>urbs.lock);
> > +}
> > +
> > int udl_init(struct udl_device *udl)
> > {
> > struct drm_device *dev = >drm;
> > @@ -335,6 +353,7 @@ int udl_drop_usb(struct drm_device *dev)
> > {
> > struct udl_device *udl = to_udl(dev);
> > + udl_kill_pending_urbs(dev);
> > udl_free_urb_list(dev);
> > put_device(udl->dmadev);
> > udl->dmadev = NULL;
> > diff --git a/drivers/gpu/drm/udl/udl_modeset.c
> > b/drivers/gpu/drm/udl/udl_modeset.c
> > index 50025606b6ad..169110d8fc2e 100644
> > --- a/drivers/gpu/drm/udl/udl_modeset.c
> > +++ b/drivers/gpu/drm/udl/udl_modeset.c
> > @@ -397,6 +397,8 @@ udl_simple_display_pipe_disable(struct
> > drm_simple_display_pipe *pipe)
> > struct urb *urb;
> > char *buf;
> > + udl_kill_pending_urbs(dev);
> > +
>
> I already reviewed the patchset, but I have another comment. I think
> we should only kill urbs from within the suspend handler. Same for the
> call to the URB-sync function in patch 2.
>
> This disable function is part of the regular modeset path. It's
> probably not appropriate to outright remove pending URBs here. This
Re: [PATCH 3/4] drm/udl: Kill pending URBs at suspend and disconnect
Hi
Am 04.08.22 um 09:58 schrieb Takashi Iwai:
At both suspend and disconnect, we should rather cancel the pending
URBs immediately. For the suspend case, the display will be turned
off, so it makes no sense to process the rendering. And for the
disconnect case, the device may be no longer accessible, hence we
shouldn't do any submission.
Tested-by: Thomas Zimmermann
Signed-off-by: Takashi Iwai
---
drivers/gpu/drm/udl/udl_drv.h | 2 ++
drivers/gpu/drm/udl/udl_main.c| 25 ++---
drivers/gpu/drm/udl/udl_modeset.c | 2 ++
3 files changed, 26 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/udl/udl_drv.h b/drivers/gpu/drm/udl/udl_drv.h
index f01e50c5b7b7..28aaf75d71cf 100644
--- a/drivers/gpu/drm/udl/udl_drv.h
+++ b/drivers/gpu/drm/udl/udl_drv.h
@@ -39,6 +39,7 @@ struct urb_node {
struct urb_list {
struct list_head list;
+ struct list_head in_flight;
spinlock_t lock;
wait_queue_head_t sleep;
int available;
@@ -84,6 +85,7 @@ static inline struct urb *udl_get_urb(struct drm_device *dev)
int udl_submit_urb(struct drm_device *dev, struct urb *urb, size_t len);
int udl_sync_pending_urbs(struct drm_device *dev);
+void udl_kill_pending_urbs(struct drm_device *dev);
void udl_urb_completion(struct urb *urb);
int udl_init(struct udl_device *udl);
diff --git a/drivers/gpu/drm/udl/udl_main.c b/drivers/gpu/drm/udl/udl_main.c
index 93615648414b..47204b7eb10e 100644
--- a/drivers/gpu/drm/udl/udl_main.c
+++ b/drivers/gpu/drm/udl/udl_main.c
@@ -135,7 +135,7 @@ void udl_urb_completion(struct urb *urb)
urb->transfer_buffer_length = udl->urbs.size; /* reset to actual */
spin_lock_irqsave(>urbs.lock, flags);
- list_add_tail(>entry, >urbs.list);
+ list_move(>entry, >urbs.list);
udl->urbs.available++;
spin_unlock_irqrestore(>urbs.lock, flags);
@@ -180,6 +180,7 @@ static int udl_alloc_urb_list(struct drm_device *dev, int count, size_t size)
retry:
udl->urbs.size = size;
INIT_LIST_HEAD(>urbs.list);
+ INIT_LIST_HEAD(>urbs.in_flight);
init_waitqueue_head(>urbs.sleep);
udl->urbs.count = 0;
@@ -246,7 +247,7 @@ struct urb *udl_get_urb_timeout(struct drm_device *dev,
long timeout)
}
unode = list_first_entry(>urbs.list, struct urb_node, entry);
- list_del_init(>entry);
+ list_move(>entry, >urbs.in_flight);
udl->urbs.available--;
unlock:
@@ -279,7 +280,7 @@ int udl_sync_pending_urbs(struct drm_device *dev)
spin_lock_irq(>urbs.lock);
/* 2 seconds as a sane timeout */
if (!wait_event_lock_irq_timeout(udl->urbs.sleep,
-udl->urbs.available == udl->urbs.count,
+list_empty(>urbs.in_flight),
udl->urbs.lock,
msecs_to_jiffies(2000)))
ret = -ETIMEDOUT;
@@ -287,6 +288,23 @@ int udl_sync_pending_urbs(struct drm_device *dev)
return ret;
}
+/* kill pending URBs */
+void udl_kill_pending_urbs(struct drm_device *dev)
+{
+ struct udl_device *udl = to_udl(dev);
+ struct urb_node *unode;
+
+ spin_lock_irq(>urbs.lock);
+ while (!list_empty(>urbs.in_flight)) {
+ unode = list_first_entry(>urbs.in_flight,
+struct urb_node, entry);
+ spin_unlock_irq(>urbs.lock);
+ usb_kill_urb(unode->urb);
+ spin_lock_irq(>urbs.lock);
+ }
+ spin_unlock_irq(>urbs.lock);
+}
+
int udl_init(struct udl_device *udl)
{
struct drm_device *dev = >drm;
@@ -335,6 +353,7 @@ int udl_drop_usb(struct drm_device *dev)
{
struct udl_device *udl = to_udl(dev);
+ udl_kill_pending_urbs(dev);
udl_free_urb_list(dev);
put_device(udl->dmadev);
udl->dmadev = NULL;
diff --git a/drivers/gpu/drm/udl/udl_modeset.c
b/drivers/gpu/drm/udl/udl_modeset.c
index 50025606b6ad..169110d8fc2e 100644
--- a/drivers/gpu/drm/udl/udl_modeset.c
+++ b/drivers/gpu/drm/udl/udl_modeset.c
@@ -397,6 +397,8 @@ udl_simple_display_pipe_disable(struct
drm_simple_display_pipe *pipe)
struct urb *urb;
char *buf;
+ udl_kill_pending_urbs(dev);
+
I already reviewed the patchset, but I have another comment. I think we
should only kill urbs from within the suspend handler. Same for the call
to the URB-sync function in patch 2.
This disable function is part of the regular modeset path. It's probably
not appropriate to outright remove pending URBs here. This can lead to
failed modesets, which would have succeeded otherwise.
Best regards
Thomas
urb = udl_get_urb(dev);
if (!urb)
return;
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo
Re: [EXT] Re: [PATCH 2/3] dt-bindings: reserved-memory: add linaro,secure-heap
Hi Brian,
It was part of a discussion during a Devicetree evolution meeting with
Bill Mills from Linaro.
I've done some modification to OPTEE OS and OPTEE TEST to support dma
buf:
OPTEE OS
https://github.com/OP-TEE/optee_os/commit/eb108a04369fbfaf60c03c0e00bbe9489a761c69
https://github.com/OP-TEE/optee_os/commit/513b0748d46e7eefa17dadb204289e49dc17f854
OPTEE TEST
https://github.com/OP-TEE/optee_test/commit/da5282a011b40621a2cf7a296c11a35c833ed91b
BR / Olivier
On ven., 2022-08-05 at 16:46 +0100, Brian Starkey wrote:
> Caution: EXT Email
>
> +Rob and devicetree list.
>
> I don't know if this should be "linaro" or something more generic,
> and also where previous discussions got to about DMA heaps in DT.
>
> Cheers,
> -Brian
>
> On Fri, Aug 05, 2022 at 03:53:29PM +0200, Olivier Masse wrote:
> > DMABUF Reserved memory definition for OP-TEE SDP feaure.
> >
> > Signed-off-by: Olivier Masse
> > ---
> > .../reserved-memory/linaro,secure-heap.yaml | 56
> > +++
> > 1 file changed, 56 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/reserved-
> > memory/linaro,secure-heap.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/reserved-
> > memory/linaro,secure-heap.yaml
> > b/Documentation/devicetree/bindings/reserved-memory/linaro,secure-
> > heap.yaml
> > new file mode 100644
> > index ..80522a4e2989
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/reserved-
> > memory/linaro,secure-heap.yaml
> > @@ -0,0 +1,56 @@
> > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id:
> > https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevicetree.org%2Fschemas%2Freserved-memory%2Flinaro%2Csecure-heap.yaml%23data=05%7C01%7Colivier.masse%40nxp.com%7C0a9e67bbd65446aa05e408da76f9b82a%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637953112157450452%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=lb9U8Fnt1Y43UgObcgakAC%2FZx4je%2BCoNX5vhkFvgbdQ%3Dreserved=0
> > +$schema:
> > https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevicetree.org%2Fmeta-schemas%2Fcore.yaml%23data=05%7C01%7Colivier.masse%40nxp.com%7C0a9e67bbd65446aa05e408da76f9b82a%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637953112157450452%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=UVuVI%2FmUFj7jX7c6DY0rRi9lkZW7kqTJyQurQxvNvz8%3Dreserved=0
> > +
> > +title: Linaro Secure DMABUF Heap
> > +
> > +maintainers:
> > + - Olivier Masse
> > +
> > +description:
> > + Linaro OP-TEE firmware needs a reserved memory for the
> > + Secure Data Path feature (aka SDP).
> > + The purpose is to provide a secure memory heap which allow
> > + non-secure OS to allocate/free secure buffers.
> > + The TEE is reponsible for protecting the SDP memory buffers.
> > + TEE Trusted Application can access secure memory references
> > + provided as parameters (DMABUF file descriptor).
> > +
> > +allOf:
> > + - $ref: "reserved-memory.yaml"
> > +
> > +properties:
> > + compatible:
> > +const: linaro,secure-heap
> > +
> > + reg:
> > +description:
> > + Region of memory reserved for OP-TEE SDP feature
> > +
> > + no-map:
> > +$ref: /schemas/types.yaml#/definitions/flag
> > +description:
> > + Avoid creating a virtual mapping of the region as part of
> > the OS'
> > + standard mapping of system memory.
> > +
> > +unevaluatedProperties: false
> > +
> > +required:
> > + - compatible
> > + - reg
> > + - no-map
> > +
> > +examples:
> > + - |
> > + reserved-memory {
> > +#address-cells = <2>;
> > +#size-cells = <2>;
> > +
> > +sdp@3e80 {
> > + compatible = "linaro,secure-heap";
> > + no-map;
> > + reg = <0 0x3E80 0 0x0040>;
> > +};
> > + };
> > --
> > 2.25.0
> >
