Re: [pull] amdgpu, radeon, ttm, sched drm-next-5.13
On Tue, Apr 6, 2021 at 11:42 AM Felix Kuehling wrote: > > Am 2021-04-01 um 6:29 p.m. schrieb Alex Deucher: > > Hi Dave, Daniel, > > > > New stuff for 5.13. There are two small patches for ttm and scheduler > > that were dependencies for amdgpu changes. > > > > The following changes since commit 2cbcb78c9ee5520c8d836c7ff57d1b60ebe8e9b7: > > > > Merge tag 'amd-drm-next-5.13-2021-03-23' of > > https://gitlab.freedesktop.org/agd5f/linux into drm-next (2021-03-26 > > 15:53:21 +0100) > > > > are available in the Git repository at: > > > > https://gitlab.freedesktop.org/agd5f/linux.git > > tags/amd-drm-next-5.13-2021-04-01 > > > > for you to fetch changes up to ef95d2a98d642a537190d73c45ae3c308afee890: > > > > drm/amdgpu/display: fix warning on 32 bit in dmub (2021-04-01 17:32:32 > > -0400) > > > > > > amd-drm-next-5.13-2021-04-01: > > > > amdgpu: > > - Re-enable GPU reset on VanGogh > > - Enable DPM flags for SMART_SUSPEND and MAY_SKIP_RESUME > > - Disentangle HG from vga_switcheroo > > - S0ix fixes > > - W=1 fixes > > - Resource iterator fixes > > - DMCUB updates > > - UBSAN fixes > > - More PM API cleanup > > - Aldebaran updates > > - Modifier fixes > > - Enable VCN load balancing with asymmetric engines > > - Rework BO structs > > - Aldebaran reset support > > - Initial LTTPR display work > > - Display MALL fixes > > - Fall back to YCbCr420 when YCbCr444 fails > > - SR-IOV fixes > > - Misc cleanups and fixes > > > > radeon: > > - Typo fixes > > > > ttm: > > - Handle cached requests (required for Aldebaran) > > > > scheduler: > > - Fix runqueue selection when changing priorities (required to fix VCN > > load balancing) > > > > > > Alex Deucher (20): > > drm/amdgpu/display/dm: add missing parameter documentation > > drm/amdgpu: Add additional Sienna Cichlid PCI ID > > drm/amdgpu: add a dev_pm_ops prepare callback (v2) > > drm/amdgpu: enable DPM_FLAG_MAY_SKIP_RESUME and > > DPM_FLAG_SMART_SUSPEND flags (v2) > > drm/amdgpu: disentangle HG systems from vgaswitcheroo > > drm/amdgpu: rework S3/S4/S0ix state handling > > drm/amdgpu: don't evict vram on APUs for suspend to ram (v4) > > drm/amdgpu: clean up non-DC suspend/resume handling > > drm/amdgpu: move s0ix check into amdgpu_device_ip_suspend_phase2 (v3) > > drm/amdgpu: re-enable suspend phase 2 for S0ix > > drm/amdgpu/swsmu: skip gfx cgpg on s0ix suspend > > drm/amdgpu: update comments about s0ix suspend/resume > > drm/amdgpu: drop S0ix checks around CG/PG in suspend > > drm/amdgpu: skip kfd suspend/resume for S0ix > > drm/amdgpu/display: restore AUX_DPHY_TX_CONTROL for DCN2.x > > drm/amdgpu/display: fix memory leak for dimgrey cavefish > > drm/amdgpu/pm: mark pcie link/speed arrays as const > > drm/amdgpu/pm: bail on sysfs/debugfs queries during platform suspend > > drm/amdgpu/vangogh: don't check for dpm in is_dpm_running when in > > suspend > > drm/amdgpu/display: fix warning on 32 bit in dmub > > > > Alex Sierra (2): > > drm/amdgpu: replace per_device_list by array > > drm/amdgpu: ih reroute for newer asics than vega20 > > > > Alvin Lee (1): > > drm/amd/display: Change input parameter for set_drr > > > > Anson Jacob (2): > > drm/amd/display: Fix UBSAN: shift-out-of-bounds warning > > drm/amd/display: Removing unused code from dmub_cmd.h > > > > Anthony Koo (2): > > drm/amd/display: [FW Promotion] Release 0.0.57 > > drm/amd/display: [FW Promotion] Release 0.0.58 > > > > Aric Cyr (2): > > drm/amd/display: 3.2.128 > > drm/amd/display: 3.2.129 > > > > Arnd Bergmann (3): > > amdgpu: avoid incorrect %hu format string > > amdgpu: fix gcc -Wrestrict warning > > amdgpu: securedisplay: simplify i2c hexdump output > > > > Bhaskar Chowdhury (6): > > drm/amdgpu: Fix a typo > > drm/amdgpu: Fix a typo > > drm/atomic: Couple of typo fixes > > drm/radeon/r600_cs: Few typo fixes > > drm/amd/amdgpu/gfx_v7_0: Trivial typo fixes > > drm/amd: Fix a typo in two different sentences > > > > Bindu Ramamurthy (1): > > drm/amd/display: Allow idle optimization based on vblank. > > > > Chengming Gui (1): > > drm/amd/amdgpu: set MP1 state to UNLOAD before reload its FW for > > vega20/ALDEBARAN > > > > Chris Park (1): > > drm/amd/display: Disable MALL when SMU not present > > > > Christian König (5): > > drm/amdgpu: remove irq_src->data handling > > drm/amdgpu: add the sched_score to amdgpu_ring_init > > drm/amdgpu: share scheduler score on VCN3 instances > > drm/sched: select new rq even if there is only one v3 > > drm/amdgpu: load balance VCN3 decode as well v8 > > > > Daniel Gomez (2): > > drm/amdgpu/ttm: Fix memory leak userptr pages > > This introduced a regressio
Re: [PATCH v2 11/14] drm/bridge: ti-sn65dsi86: Power things properly for reading the EDID
Hello again after easter,
I have looked little bit more at sn65* driver and its application to
have better background.
I miss only info what panel do you have, how it is enabled/power controlled.
W dniu 01.04.2021 o 16:57, Doug Anderson pisze:
> Hi,
>
> On Thu, Apr 1, 2021 at 4:12 AM Andrzej Hajda wrote:
>>
>> W dniu 31.03.2021 o 16:48, Doug Anderson pisze:
>>> Hi,
>>>
>>> On Wed, Mar 31, 2021 at 4:08 AM Andrzej Hajda wrote:
W dniu 30.03.2021 o 04:53, Douglas Anderson pisze:
> eDP panels won't provide their EDID unless they're powered on. Let's
> chain a power-on before we read the EDID. This roughly matches what
> was done in 'parade-ps8640.c'.
>
> NOTE: The old code attempted to call pm_runtime_get_sync() before
> reading the EDID. While that was enough to power the bridge chip on,
> it wasn't enough to talk to the panel for two reasons:
> 1. Since we never ran the bridge chip's pre-enable then we never set
> the bit to ignore HPD. This meant the bridge chip didn't even _try_
> to go out on the bus and communicate with the panel.
> 2. Even if we fixed things to ignore HPD, the EDID still wouldn't read
> if the panel wasn't on.
>
> One thing that's a bit odd here is taking advantage of the EDID that
> the core might have cached for us. See the patch ("drm/edid: Use the
> cached EDID in drm_get_edid() if eDP"). We manage to get at the cache
> by:
> - Instantly failing aux transfers if we're not powered.
> - If the first read of the EDID fails we try again after powering.
>
> Fixes: 58074b08c04a ("drm/bridge: ti-sn65dsi86: Read EDID blob over DDC")
> Signed-off-by: Douglas Anderson
> ---
> Depending on what people think of the other patches in this series,
> some of this could change.
> - If everyone loves the "runtime PM" in the panel driver then we
> could, in theory, put the pre-enable chaining straight in the "aux
> transfer" function.
> - If everyone hates the EDID cache moving to the core then we can
> avoid some of the awkward flow of things and keep the EDID cache in
> the sn65dsi86 driver.
I wonder if this shouldn't be solved in the core - ie caller of
get_modes callback should be responsible for powering up the pipeline,
otherwise we need to repeat this stuff in every bridge/panel driver.
Any thoughts?
>>> Yeah, I did look at this a little bit. Presumably it would only make
>>> sense to do it for eDP connections since:
>>>
>>> a) The concept of reading an EDID doesn't make sense for things like MIPI.
>> I guess you mean MIPI DSI
> Yes, sorry! I'll try to be more clear.
>
>
>> and yes I agree, more generally it usually(!)
>> doesn't make sense for any setup with fixed display panel.
>>
>> On the other hand there are DSI/HDMI or DSI/DP adapters which usually
>> have EDID reading logic.
>>
>> And the concept makes sense for most connectors accepting external
>> displays: HDMI, DP, MHL, VGA...
> So, actually, IMO the concept doesn't make sense for anything with an
> external connector. Here's the logic for a handful of connectors:
>
> 1. MIPI DSI: there is no EDID so this doesn't make sense.
>
> 2. An external connector (HDMI, DP, etc): the display that's plugged
> in is externally powered so doesn't need us to power it up to read the
> EDID. By definition, when the HPD signal is asserted then it's OK to
> read the EDID and we don't even know if a display is plugged in until
> HPD is asserted. Thus no special power sequencing is needed to read
> the EDID. (Yes, we need to make sure that the eDP controller itself
> is powered, but that doesn't seem like it's the core's business).
Not true IMO, even if external device is powered on, you must enable
EDID-reader logic.
I guess it is not uncommon to have different power states for EDID
reading and bridge/panel pre-enablement (especially in embedded world).
In fact there are setups where EDID-reader is totally different device
than the bridge itself, and these devices should be
powered/enabled/operational only for time of EDID reading.
>
> 3. eDP: this is where it matters. This is because:
>
> 3a) eDP displays aren't powered all the time. If you just boot up or
> you blank your screen, likely the display has no power at all.
>
> 3b) Because the display has no power, the "HPD" signal doesn't assert.
> In fact, for eDP the "HPD" signal really should mean "display ready"
> or "display finished powering up".
>
> 3c) Even though we never get a HPD signal, we still simply assume that
> a display is present because this is an "embedded" device.
>
> So eDP is unique (as far as I know) in that it's a type of display
> that has an EDID but that we will report "a display is here" before
> we've powered up the display and before we can read the EDID.
>
>>> b) For something with an external connector (DP and HDMI) you don't
>>> even know they're inserted unless th
Re: [PATCH 18/18] vfio/mdev: Correct the function signatures for the mdev_type_attributes
On Tue, Mar 23, 2021 at 08:31:03PM +0100, Christoph Hellwig wrote: > > - type = intel_gvt_find_vgpu_type(gvt, mtype_get_type_group_id(kobj)); > > + type = intel_gvt_find_vgpu_type(gvt, mtype_get_type_group_id(mtype)); > > Somewhere in this series you should probably switch > intel_gvt_find_vgpu_type to only get the mtype, as it can trivially > deduct the gvt from it (which also seems to have lost its type > somewhere..) I look at just this minor change for a bit and it just is a mess. This only exists like this because the gvt_type_attrs[] are in the wrong file and I already tried to fix that and gave up. Deleting the intel_gvt_ops looks like precondition to do any big improvement in here :\ Jason ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] drm/i915/dpcd_bl: Don't try vesa interface unless specified by VBT
On Tue, 23 Mar 2021, Lyude Paul wrote:
> On Tue, 2021-03-23 at 16:06 +0200, Jani Nikula wrote:
>> On Thu, 18 Mar 2021, Lyude Paul wrote:
>> > Actually-NAK this. I just realized I've been misreading the bug and that
>> > this
>> > doesn't actually seem to be fixed. Will resend once I figure out what's
>> > going on
>>
>> Well, I think there are actually multiple issues on multiple
>> machines. This fixes the issue on ThinkPad X1 Titanium Gen1 [1].
>>
>> I suspect reverting 98e497e203a5 ("drm/i915/dpcd_bl: uncheck PWM_PIN_CAP
>> when detect eDP backlight capabilities") would too. But then that would
>> break *other* machines that claim support for *both* eDP PWM pin and
>> DPCD backlight control, I think.
>>
>> I think there are issues with how we try setup DPCD backlight if the GOP
>> has set up PWM backlight. For example, we don't set the backlight
>> control mode correctly until the next disable/enable sequence. However,
>> I tried to fix this, and I think I was doing all the right things, and
>> DPCD reads seemed to confirm this, yet I was not able to control
>> brightness using DPCD. I don't know what gives, but I do know eDP PWM
>> pin control works.
>
> Should we go ahead and push the VESA fix for this then? If you're willing to
> test future patches on that machine, we could give another shot at enabling
> this
> in the future if we find reason to.
Yes, let's go with this first.
Reviewed-by: Jani Nikula
>
>>
>>
>> BR,
>> Jani.
>>
>>
>> [1] https://gitlab.freedesktop.org/drm/intel/-/issues/3158
>>
>>
>> >
>> > On Thu, 2021-03-18 at 13:02 -0400, Lyude Paul wrote:
>> > > Looks like that there actually are another subset of laptops on the
>> > > market
>> > > that don't support the Intel HDR backlight interface, but do advertise
>> > > support for the VESA DPCD backlight interface despite the fact it doesn't
>> > > seem to work.
>> > >
>> > > Note though I'm not entirely clear on this - on one of the machines where
>> > > this issue was observed, I also noticed that we appeared to be rejecting
>> > > the VBT defined backlight frequency in
>> > > intel_dp_aux_vesa_calc_max_backlight(). It's noted in this function that:
>> > >
>> > > /* Use highest possible value of Pn for more granularity of brightness
>> > > * adjustment while satifying the conditions below.
>> > > * ...
>> > > * - FxP is within 25% of desired value.
>> > > * Note: 25% is arbitrary value and may need some tweak.
>> > > */
>> > >
>> > > So it's possible that this value might just need to be tweaked, but for
>> > > now
>> > > let's just disable the VESA backlight interface unless it's specified in
>> > > the VBT just to be safe. We might be able to try enabling this again by
>> > > default in the future.
>> > >
>> > > Fixes: 2227816e647a ("drm/i915/dp: Allow forcing specific interfaces
>> > > through
>> > > enable_dpcd_backlight")
>> > > Cc: Jani Nikula
>> > > Cc: Rodrigo Vivi
>> > > Bugzilla: https://gitlab.freedesktop.org/drm/intel/-/issues/3169
>> > > Signed-off-by: Lyude Paul
>> > > ---
>> > > drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c | 1 -
>> > > 1 file changed, 1 deletion(-)
>> > >
>> > > diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
>> > > b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
>> > > index 651884390137..4f8337c7fd2e 100644
>> > > --- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
>> > > +++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
>> > > @@ -646,7 +646,6 @@ int intel_dp_aux_init_backlight_funcs(struct
>> > > intel_connector *connector)
>> > > break;
>> > > case INTEL_BACKLIGHT_DISPLAY_DDI:
>> > > try_intel_interface = true;
>> > > - try_vesa_interface = true;
>> > > break;
>> > > default:
>> > > return -ENODEV;
>>
--
Jani Nikula, Intel Open Source Graphics Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/doc: emphasize difference between plane formats and IN_FORMATS blob
Emphasize how userspace should use the plane format list
(format_type_ptr) and the IN_FORMATS blob property.
Formats exposed in the plane format list (format_type_ptr) do not
require modifiers, and formats that are present in the IN_FORMATS blob
property support modifiers.
Note that these are not disjoint sets. If a format supports modifiers
but the driver can also handle it without a modifier, it should be
present in both the IN_FORMATS blob property and the plane format list.
Signed-off-by: Leandro Ribeiro
---
drivers/gpu/drm/drm_plane.c | 4
include/uapi/drm/drm_mode.h | 3 +++
2 files changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index 0dd43882fe7c..b48d9bd81a59 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -128,6 +128,10 @@
* pairs supported by this plane. The blob is a struct
* drm_format_modifier_blob. Without this property the plane doesn't
* support buffers with modifiers. Userspace cannot change this property.
+ *
+ * To find out the list of buffer formats which are supported without a
+ * modifier, userspace should not look at this blob property, but at the
+ * formats list of the plane: &drm_mode_get_plane.format_type_ptr.
*/
static unsigned int drm_num_planes(struct drm_device *dev)
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index 96fc9a6da608..4293800ec095 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -340,6 +340,9 @@ struct drm_mode_get_plane {
/**
* @format_type_ptr: Pointer to ``__u32`` array of formats that are
* supported by the plane. These formats do not require modifiers.
+*
+* To find out the list of formats that support modifiers, userspace
+* must use the plane IN_FORMATS blob property.
*/
__u64 format_type_ptr;
};
--
2.31.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/2] Document how userspace should use plane format list and IN_FORMATS
This patch is to emphasize how userspace should use the plane format list and the IN_FORMATS blob. The plane format list contains the formats that do not require modifiers, and the blob property has the formats that support modifiers. Note that these are not disjoint sets. If a format supports modifiers but the driver can also handle it without a modifier, it should be present in both the IN_FORMATS blob property and the plane format list. This is important for userspace, as there are situations in which we need to find out if the KMS driver can handle a certain format without any modifiers. Leandro Ribeiro (2): drm/doc: document drm_mode_get_plane drm/doc: emphasize difference between plane formats and IN_FORMATS blob drivers/gpu/drm/drm_plane.c | 4 include/uapi/drm/drm_mode.h | 22 ++ 2 files changed, 26 insertions(+) -- 2.31.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm/doc: document drm_mode_get_plane
Add a small description and document struct fields of
drm_mode_get_plane.
Signed-off-by: Leandro Ribeiro
---
include/uapi/drm/drm_mode.h | 19 +++
1 file changed, 19 insertions(+)
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index d1a93d2a85f9..96fc9a6da608 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -312,16 +312,35 @@ struct drm_mode_set_plane {
__u32 src_w;
};
+/**
+ * struct drm_mode_get_plane - Get plane metadata.
+ *
+ * Userspace can perform a GETPLANE ioctl to retrieve information about a
+ * plane.
+ */
struct drm_mode_get_plane {
+ /** @plane_id: Object ID of the plane. */
__u32 plane_id;
+ /** @crtc_id: Object ID of the current CRTC. */
__u32 crtc_id;
+ /** @fb_id: Object ID of the current fb. */
__u32 fb_id;
+ /**
+* @possible_crtcs: Pointer to ``__u32`` array of CRTC's that are
+* compatible with the plane.
+*/
__u32 possible_crtcs;
+ /** @gamma_size: Size of the legacy gamma table. */
__u32 gamma_size;
+ /** @count_format_types: Number of formats. */
__u32 count_format_types;
+ /**
+* @format_type_ptr: Pointer to ``__u32`` array of formats that are
+* supported by the plane. These formats do not require modifiers.
+*/
__u64 format_type_ptr;
};
--
2.31.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH] pwm: Rename pwm_get_state() to better reflect its semantic
On Tue, 06 Apr 2021, Uwe Kleine-König wrote: > Given that lowlevel drivers usually cannot implement exactly what a > consumer requests with pwm_apply_state() there is some > rounding involved. > > pwm_get_state() traditionally returned the setting that was requested > most recently by the consumer (opposed to what was > actually implemented in hardware in reply to the last request). > To make this semantic obvious rename the function. > > Signed-off-by: Uwe Kleine-König > --- > drivers/input/misc/da7280.c| 2 +- Acked-by: Roy Im ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH -next] gma500: Use DEFINE_SPINLOCK() for spinlock
From: Guobin Huang spinlock can be initialized automatically with DEFINE_SPINLOCK() rather than explicitly calling spin_lock_init(). Reported-by: Hulk Robot Signed-off-by: Guobin Huang --- drivers/gpu/drm/gma500/power.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/drm/gma500/power.c b/drivers/gpu/drm/gma500/power.c index 56ef88237ef6..f07641dfa5a4 100644 --- a/drivers/gpu/drm/gma500/power.c +++ b/drivers/gpu/drm/gma500/power.c @@ -36,7 +36,7 @@ #include static struct mutex power_mutex; /* Serialize power ops */ -static spinlock_t power_ctrl_lock; /* Serialize power claim */ +static DEFINE_SPINLOCK(power_ctrl_lock); /* Serialize power claim */ /** * gma_power_init - initialise power manager @@ -55,7 +55,6 @@ void gma_power_init(struct drm_device *dev) dev_priv->display_power = true; /* We start active */ dev_priv->display_count = 0;/* Currently no users */ dev_priv->suspended = false;/* And not suspended */ - spin_lock_init(&power_ctrl_lock); mutex_init(&power_mutex); if (dev_priv->ops->init_pm) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] vfio/pci: remove vfio_pci_nvlink2
On Fri, 26 Mar 2021 07:13:10 +0100 Christoph Hellwig wrote: > This driver never had any open userspace (which for VFIO would include > VM kernel drivers) that use it, and thus should never have been added > by our normal userspace ABI rules. > > Signed-off-by: Christoph Hellwig > Acked-by: Greg Kroah-Hartman > --- > drivers/vfio/pci/Kconfig| 6 - > drivers/vfio/pci/Makefile | 1 - > drivers/vfio/pci/vfio_pci.c | 18 - > drivers/vfio/pci/vfio_pci_nvlink2.c | 490 > drivers/vfio/pci/vfio_pci_private.h | 14 - > include/uapi/linux/vfio.h | 38 +-- > 6 files changed, 4 insertions(+), 563 deletions(-) > delete mode 100644 drivers/vfio/pci/vfio_pci_nvlink2.c Hearing no objections, applied to vfio next branch for v5.13. Thanks, Alex ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 15/18] vfio/gvt: Make DRM_I915_GVT depend on VFIO_MDEV
At some point there may have been some reason for this weird split in this driver, but today only the VFIO side is actually implemented. However, it got messed up at some point and mdev code was put in gvt.c and is pretending to be "generic" by masquerading as some generic attribute list: static MDEV_TYPE_ATTR_RO(description); But MDEV_TYPE attributes are only usable with mdev_device, nothing else. Ideally all of this would be moved to kvmgt.c, but it is entangled with the rest of the "generic" code in an odd way. Thus put in a kconfig dependency so we don't get randconfig failures when the next patch creates a link time dependency related to the use of MDEV_TYPE. Reviewed-by: Kevin Tian Reviewed-by: Christoph Hellwig Signed-off-by: Jason Gunthorpe --- drivers/gpu/drm/i915/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig index 1e1cb245fca778..483e9ff8ca1d23 100644 --- a/drivers/gpu/drm/i915/Kconfig +++ b/drivers/gpu/drm/i915/Kconfig @@ -101,6 +101,7 @@ config DRM_I915_GVT bool "Enable Intel GVT-g graphics virtualization host support" depends on DRM_I915 depends on 64BIT + depends on VFIO_MDEV default n help Choose this option if you want to enable Intel GVT-g graphics -- 2.31.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 00/18] Make vfio_mdev type safe
vfio_mdev has a number of different objects: mdev_parent, mdev_type and mdev_device. Unfortunately the types of these have been erased in various places throughout the API, and this makes it very hard to understand this code or maintain it by the time it reaches all of the drivers. This series puts in all the types and aligns some of the design with the driver core standard for a driver core bus driver: - Replace 'struct device *' with 'struct mdev_device * - Replace 'struct device *' with 'struct mdev_type *' and mtype_get_parent_dev() - Replace 'struct kobject *' with 'struct mdev_type *' Now that types are clear it is easy to spot a few places that have duplicated information. More significantly we can now understand how to directly fix the obfuscated 'kobj->name' matching by realizing the the kobj is a mdev_type, which is linked to the supported_types_list provided by the driver, and thus the core code can directly return the array indexes all the drivers actually want. v2: - Use a mdev_type local in mdev_create_sysfs_files - Rename the goto unwind labels in mdev_device_free() - Reorder patches, annotate reviewed-by's thanks all v1: https://lore.kernel.org/r/0-v1-7dedf20b2b75+4f785-vfio2_...@nvidia.com Jason Gunthorpe (18): vfio/mdev: Fix missing static's on MDEV_TYPE_ATTR's vfio/mdev: Do not allow a mdev_type to have a NULL parent pointer vfio/mdev: Add missing typesafety around mdev_device vfio/mdev: Simplify driver registration vfio/mdev: Use struct mdev_type in struct mdev_device vfio/mdev: Expose mdev_get/put_parent to mdev_private.h vfio/mdev: Add missing reference counting to mdev_type vfio/mdev: Reorganize mdev_device_create() vfio/mdev: Add missing error handling to dev_set_name() vfio/mdev: Remove duplicate storage of parent in mdev_device vfio/mdev: Add mdev/mtype_get_type_group_id() vfio/mtty: Use mdev_get_type_group_id() vfio/mdpy: Use mdev_get_type_group_id() vfio/mbochs: Use mdev_get_type_group_id() vfio/gvt: Make DRM_I915_GVT depend on VFIO_MDEV vfio/gvt: Use mdev_get_type_group_id() vfio/mdev: Remove kobj from mdev_parent_ops->create() vfio/mdev: Correct the function signatures for the mdev_type_attributes .../driver-api/vfio-mediated-device.rst | 9 +- drivers/gpu/drm/i915/Kconfig | 1 + drivers/gpu/drm/i915/gvt/gvt.c| 41 ++--- drivers/gpu/drm/i915/gvt/gvt.h| 4 +- drivers/gpu/drm/i915/gvt/kvmgt.c | 7 +- drivers/s390/cio/vfio_ccw_ops.c | 17 +- drivers/s390/crypto/vfio_ap_ops.c | 14 +- drivers/vfio/mdev/mdev_core.c | 174 +++--- drivers/vfio/mdev/mdev_driver.c | 19 +- drivers/vfio/mdev/mdev_private.h | 40 ++-- drivers/vfio/mdev/mdev_sysfs.c| 59 +++--- drivers/vfio/mdev/vfio_mdev.c | 29 +-- drivers/vfio/vfio_iommu_type1.c | 25 +-- include/linux/mdev.h | 80 +--- samples/vfio-mdev/mbochs.c| 55 +++--- samples/vfio-mdev/mdpy.c | 56 +++--- samples/vfio-mdev/mtty.c | 66 ++- 17 files changed, 313 insertions(+), 383 deletions(-) -- 2.31.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 16/18] vfio/gvt: Use mdev_get_type_group_id()
intel_gvt_init_vgpu_type_groups() makes gvt->types 1:1 with the
supported_type_groups array, so the type_group_id is also the index into
gvt->types. Use it directly and remove the string matching.
Reviewed-by: Kevin Tian
Reviewed-by: Christoph Hellwig
Signed-off-by: Jason Gunthorpe
---
drivers/gpu/drm/i915/gvt/gvt.c | 24 +++-
drivers/gpu/drm/i915/gvt/gvt.h | 4 ++--
drivers/gpu/drm/i915/gvt/kvmgt.c | 5 ++---
3 files changed, 11 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/i915/gvt/gvt.c b/drivers/gpu/drm/i915/gvt/gvt.c
index d1d8ee4a5f16a3..4b47a18e9dfa0f 100644
--- a/drivers/gpu/drm/i915/gvt/gvt.c
+++ b/drivers/gpu/drm/i915/gvt/gvt.c
@@ -46,22 +46,12 @@ static const char * const supported_hypervisors[] = {
[INTEL_GVT_HYPERVISOR_KVM] = "KVM",
};
-static struct intel_vgpu_type *intel_gvt_find_vgpu_type(struct intel_gvt *gvt,
- const char *name)
+static struct intel_vgpu_type *
+intel_gvt_find_vgpu_type(struct intel_gvt *gvt, unsigned int type_group_id)
{
- const char *driver_name =
- dev_driver_string(&gvt->gt->i915->drm.pdev->dev);
- int i;
-
- name += strlen(driver_name) + 1;
- for (i = 0; i < gvt->num_types; i++) {
- struct intel_vgpu_type *t = &gvt->types[i];
-
- if (!strncmp(t->name, name, sizeof(t->name)))
- return t;
- }
-
- return NULL;
+ if (WARN_ON(type_group_id >= gvt->num_types))
+ return NULL;
+ return &gvt->types[type_group_id];
}
static ssize_t available_instances_show(struct kobject *kobj,
@@ -71,7 +61,7 @@ static ssize_t available_instances_show(struct kobject *kobj,
unsigned int num = 0;
void *gvt = kdev_to_i915(dev)->gvt;
- type = intel_gvt_find_vgpu_type(gvt, kobject_name(kobj));
+ type = intel_gvt_find_vgpu_type(gvt, mtype_get_type_group_id(kobj));
if (!type)
num = 0;
else
@@ -92,7 +82,7 @@ static ssize_t description_show(struct kobject *kobj, struct
device *dev,
struct intel_vgpu_type *type;
void *gvt = kdev_to_i915(dev)->gvt;
- type = intel_gvt_find_vgpu_type(gvt, kobject_name(kobj));
+ type = intel_gvt_find_vgpu_type(gvt, mtype_get_type_group_id(kobj));
if (!type)
return 0;
diff --git a/drivers/gpu/drm/i915/gvt/gvt.h b/drivers/gpu/drm/i915/gvt/gvt.h
index 03c993d68f105a..0cf480f42850d2 100644
--- a/drivers/gpu/drm/i915/gvt/gvt.h
+++ b/drivers/gpu/drm/i915/gvt/gvt.h
@@ -569,8 +569,8 @@ struct intel_gvt_ops {
void (*vgpu_reset)(struct intel_vgpu *);
void (*vgpu_activate)(struct intel_vgpu *);
void (*vgpu_deactivate)(struct intel_vgpu *);
- struct intel_vgpu_type *(*gvt_find_vgpu_type)(struct intel_gvt *gvt,
- const char *name);
+ struct intel_vgpu_type *(*gvt_find_vgpu_type)(
+ struct intel_gvt *gvt, unsigned int type_group_id);
bool (*get_gvt_attrs)(struct attribute_group ***intel_vgpu_type_groups);
int (*vgpu_query_plane)(struct intel_vgpu *vgpu, void *);
int (*vgpu_get_dmabuf)(struct intel_vgpu *vgpu, unsigned int);
diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c b/drivers/gpu/drm/i915/gvt/kvmgt.c
index b4348256ae9591..16e1e4a38aa1f6 100644
--- a/drivers/gpu/drm/i915/gvt/kvmgt.c
+++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
@@ -700,10 +700,9 @@ static int intel_vgpu_create(struct kobject *kobj, struct
mdev_device *mdev)
pdev = mdev_parent_dev(mdev);
gvt = kdev_to_i915(pdev)->gvt;
- type = intel_gvt_ops->gvt_find_vgpu_type(gvt, kobject_name(kobj));
+ type = intel_gvt_ops->gvt_find_vgpu_type(gvt,
+mdev_get_type_group_id(mdev));
if (!type) {
- gvt_vgpu_err("failed to find type %s to create\n",
- kobject_name(kobj));
ret = -EINVAL;
goto out;
}
--
2.31.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 18/18] vfio/mdev: Correct the function signatures for the mdev_type_attributes
The driver core standard is to pass in the properly typed object, the
properly typed attribute and the buffer data. It stems from the root
kobject method:
ssize_t (*show)(struct kobject *kobj, struct kobj_attribute *attr,..)
Each subclass of kobject should provide their own function with the same
signature but more specific types, eg struct device uses:
ssize_t (*show)(struct device *dev, struct device_attribute *attr,..)
In this case the existing signature is:
ssize_t (*show)(struct kobject *kobj, struct device *dev,..)
Where kobj is a 'struct mdev_type *' and dev is 'mdev_type->parent->dev'.
Change the mdev_type related sysfs attribute functions to:
ssize_t (*show)(struct mdev_type *mtype, struct mdev_type_attribute *attr,..)
In order to restore type safety and match the driver core standard
There are no current users of 'attr', but if it is ever needed it would be
hard to add in retroactively, so do it now.
Reviewed-by: Kevin Tian
Reviewed-by: Cornelia Huck
Reviewed-by: Christoph Hellwig
Signed-off-by: Jason Gunthorpe
---
drivers/gpu/drm/i915/gvt/gvt.c| 21 +++--
drivers/s390/cio/vfio_ccw_ops.c | 15 +--
drivers/s390/crypto/vfio_ap_ops.c | 12 +++-
drivers/vfio/mdev/mdev_core.c | 14 --
drivers/vfio/mdev/mdev_sysfs.c| 11 ++-
include/linux/mdev.h | 11 +++
samples/vfio-mdev/mbochs.c| 26 +++---
samples/vfio-mdev/mdpy.c | 24 ++--
samples/vfio-mdev/mtty.c | 18 +-
9 files changed, 90 insertions(+), 62 deletions(-)
diff --git a/drivers/gpu/drm/i915/gvt/gvt.c b/drivers/gpu/drm/i915/gvt/gvt.c
index 4b47a18e9dfa0f..3703814a669b46 100644
--- a/drivers/gpu/drm/i915/gvt/gvt.c
+++ b/drivers/gpu/drm/i915/gvt/gvt.c
@@ -54,14 +54,15 @@ intel_gvt_find_vgpu_type(struct intel_gvt *gvt, unsigned
int type_group_id)
return &gvt->types[type_group_id];
}
-static ssize_t available_instances_show(struct kobject *kobj,
- struct device *dev, char *buf)
+static ssize_t available_instances_show(struct mdev_type *mtype,
+ struct mdev_type_attribute *attr,
+ char *buf)
{
struct intel_vgpu_type *type;
unsigned int num = 0;
- void *gvt = kdev_to_i915(dev)->gvt;
+ void *gvt = kdev_to_i915(mtype_get_parent_dev(mtype))->gvt;
- type = intel_gvt_find_vgpu_type(gvt, mtype_get_type_group_id(kobj));
+ type = intel_gvt_find_vgpu_type(gvt, mtype_get_type_group_id(mtype));
if (!type)
num = 0;
else
@@ -70,19 +71,19 @@ static ssize_t available_instances_show(struct kobject
*kobj,
return sprintf(buf, "%u\n", num);
}
-static ssize_t device_api_show(struct kobject *kobj, struct device *dev,
- char *buf)
+static ssize_t device_api_show(struct mdev_type *mtype,
+ struct mdev_type_attribute *attr, char *buf)
{
return sprintf(buf, "%s\n", VFIO_DEVICE_API_PCI_STRING);
}
-static ssize_t description_show(struct kobject *kobj, struct device *dev,
- char *buf)
+static ssize_t description_show(struct mdev_type *mtype,
+ struct mdev_type_attribute *attr, char *buf)
{
struct intel_vgpu_type *type;
- void *gvt = kdev_to_i915(dev)->gvt;
+ void *gvt = kdev_to_i915(mtype_get_parent_dev(mtype))->gvt;
- type = intel_gvt_find_vgpu_type(gvt, mtype_get_type_group_id(kobj));
+ type = intel_gvt_find_vgpu_type(gvt, mtype_get_type_group_id(mtype));
if (!type)
return 0;
diff --git a/drivers/s390/cio/vfio_ccw_ops.c b/drivers/s390/cio/vfio_ccw_ops.c
index 10407cf67583c6..491a64c61fff1a 100644
--- a/drivers/s390/cio/vfio_ccw_ops.c
+++ b/drivers/s390/cio/vfio_ccw_ops.c
@@ -71,23 +71,26 @@ static int vfio_ccw_mdev_notifier(struct notifier_block *nb,
return NOTIFY_DONE;
}
-static ssize_t name_show(struct kobject *kobj, struct device *dev, char *buf)
+static ssize_t name_show(struct mdev_type *mtype,
+struct mdev_type_attribute *attr, char *buf)
{
return sprintf(buf, "I/O subchannel (Non-QDIO)\n");
}
static MDEV_TYPE_ATTR_RO(name);
-static ssize_t device_api_show(struct kobject *kobj, struct device *dev,
- char *buf)
+static ssize_t device_api_show(struct mdev_type *mtype,
+ struct mdev_type_attribute *attr, char *buf)
{
return sprintf(buf, "%s\n", VFIO_DEVICE_API_CCW_STRING);
}
static MDEV_TYPE_ATTR_RO(device_api);
-static ssize_t available_instances_show(struct kobject *kobj,
- struct device *dev, char *buf)
+static ssize_t available_instances_show(struct mdev_type *mtype,
+ struct mdev_type_attribute *attr,
+
[PATCH v2 17/18] vfio/mdev: Remove kobj from mdev_parent_ops->create()
The kobj here is a type-erased version of mdev_type, which is already
stored in the struct mdev_device being passed in. It was only ever used to
compute the type_group_id, which is now extracted directly from the mdev.
Reviewed-by: Kevin Tian
Reviewed-by: Cornelia Huck
Reviewed-by: Christoph Hellwig
Signed-off-by: Jason Gunthorpe
---
drivers/gpu/drm/i915/gvt/kvmgt.c | 2 +-
drivers/s390/cio/vfio_ccw_ops.c | 2 +-
drivers/s390/crypto/vfio_ap_ops.c | 2 +-
drivers/vfio/mdev/mdev_core.c | 2 +-
include/linux/mdev.h | 3 +--
samples/vfio-mdev/mbochs.c| 2 +-
samples/vfio-mdev/mdpy.c | 2 +-
samples/vfio-mdev/mtty.c | 2 +-
8 files changed, 8 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c b/drivers/gpu/drm/i915/gvt/kvmgt.c
index 16e1e4a38aa1f6..6bf176e8426e63 100644
--- a/drivers/gpu/drm/i915/gvt/kvmgt.c
+++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
@@ -689,7 +689,7 @@ static void kvmgt_put_vfio_device(void *vgpu)
vfio_device_put(vdev->vfio_device);
}
-static int intel_vgpu_create(struct kobject *kobj, struct mdev_device *mdev)
+static int intel_vgpu_create(struct mdev_device *mdev)
{
struct intel_vgpu *vgpu = NULL;
struct intel_vgpu_type *type;
diff --git a/drivers/s390/cio/vfio_ccw_ops.c b/drivers/s390/cio/vfio_ccw_ops.c
index 767ac41686fe2f..10407cf67583c6 100644
--- a/drivers/s390/cio/vfio_ccw_ops.c
+++ b/drivers/s390/cio/vfio_ccw_ops.c
@@ -110,7 +110,7 @@ static struct attribute_group *mdev_type_groups[] = {
NULL,
};
-static int vfio_ccw_mdev_create(struct kobject *kobj, struct mdev_device *mdev)
+static int vfio_ccw_mdev_create(struct mdev_device *mdev)
{
struct vfio_ccw_private *private =
dev_get_drvdata(mdev_parent_dev(mdev));
diff --git a/drivers/s390/crypto/vfio_ap_ops.c
b/drivers/s390/crypto/vfio_ap_ops.c
index 1ffdd411201cd6..d319152dd484a2 100644
--- a/drivers/s390/crypto/vfio_ap_ops.c
+++ b/drivers/s390/crypto/vfio_ap_ops.c
@@ -322,7 +322,7 @@ static void vfio_ap_matrix_init(struct ap_config_info *info,
matrix->adm_max = info->apxa ? info->Nd : 15;
}
-static int vfio_ap_mdev_create(struct kobject *kobj, struct mdev_device *mdev)
+static int vfio_ap_mdev_create(struct mdev_device *mdev)
{
struct ap_matrix_mdev *matrix_mdev;
diff --git a/drivers/vfio/mdev/mdev_core.c b/drivers/vfio/mdev/mdev_core.c
index 5ae06f951a0998..10eff33ce1f263 100644
--- a/drivers/vfio/mdev/mdev_core.c
+++ b/drivers/vfio/mdev/mdev_core.c
@@ -286,7 +286,7 @@ int mdev_device_create(struct mdev_type *type, const guid_t
*uuid)
goto out_put_device;
}
- ret = parent->ops->create(&type->kobj, mdev);
+ ret = parent->ops->create(mdev);
if (ret)
goto out_unlock;
diff --git a/include/linux/mdev.h b/include/linux/mdev.h
index 41e91936522394..c3a800051d6146 100644
--- a/include/linux/mdev.h
+++ b/include/linux/mdev.h
@@ -61,7 +61,6 @@ unsigned int mtype_get_type_group_id(struct kobject
*mtype_kobj);
* @create:Called to allocate basic resources in parent device's
* driver for a particular mediated device. It is
* mandatory to provide create ops.
- * @kobj: kobject of type for which 'create' is called.
* @mdev: mdev_device structure on of mediated device
* that is being created
* Returns integer: success (0) or error (< 0)
@@ -107,7 +106,7 @@ struct mdev_parent_ops {
const struct attribute_group **mdev_attr_groups;
struct attribute_group **supported_type_groups;
- int (*create)(struct kobject *kobj, struct mdev_device *mdev);
+ int (*create)(struct mdev_device *mdev);
int (*remove)(struct mdev_device *mdev);
int (*open)(struct mdev_device *mdev);
void(*release)(struct mdev_device *mdev);
diff --git a/samples/vfio-mdev/mbochs.c b/samples/vfio-mdev/mbochs.c
index a1af30df10a2ee..ac4d0dc2490705 100644
--- a/samples/vfio-mdev/mbochs.c
+++ b/samples/vfio-mdev/mbochs.c
@@ -506,7 +506,7 @@ static int mbochs_reset(struct mdev_device *mdev)
return 0;
}
-static int mbochs_create(struct kobject *kobj, struct mdev_device *mdev)
+static int mbochs_create(struct mdev_device *mdev)
{
const struct mbochs_type *type =
&mbochs_types[mdev_get_type_group_id(mdev)];
diff --git a/samples/vfio-mdev/mdpy.c b/samples/vfio-mdev/mdpy.c
index 08c15f9f06a880..da88fd7dd42329 100644
--- a/samples/vfio-mdev/mdpy.c
+++ b/samples/vfio-mdev/mdpy.c
@@ -216,7 +216,7 @@ static int mdpy_reset(struct mdev_device *mdev)
return 0;
}
-static int mdpy_create(struct kobject *kobj, struct mdev_device *mdev)
+static int mdpy_create(struct mdev_device *mdev)
{
const struct mdpy_type *type =
&mdpy_types[mdev_get_type_group_id(mdev)];
diff --git a/samples/vfio-mdev/mtty.c b/
[PATCH] drm/virtio: Create Dumb BOs as guest Blobs (v2)
If support for Blob resources is available, then dumb BOs created
by the driver can be considered as guest Blobs.
v2: Don't skip transfer and flush commands as part of plane update
as the device may have created a shared mapping. (Gerd)
Cc: Gerd Hoffmann
Signed-off-by: Vivek Kasireddy
---
drivers/gpu/drm/virtio/virtgpu_gem.c| 8
drivers/gpu/drm/virtio/virtgpu_object.c | 3 +++
2 files changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/virtio/virtgpu_gem.c
b/drivers/gpu/drm/virtio/virtgpu_gem.c
index 8502400b2f9c..5f49fb1cce65 100644
--- a/drivers/gpu/drm/virtio/virtgpu_gem.c
+++ b/drivers/gpu/drm/virtio/virtgpu_gem.c
@@ -64,6 +64,7 @@ int virtio_gpu_mode_dumb_create(struct drm_file *file_priv,
{
struct drm_gem_object *gobj;
struct virtio_gpu_object_params params = { 0 };
+ struct virtio_gpu_device *vgdev = dev->dev_private;
int ret;
uint32_t pitch;
@@ -79,6 +80,13 @@ int virtio_gpu_mode_dumb_create(struct drm_file *file_priv,
params.height = args->height;
params.size = args->size;
params.dumb = true;
+
+ if (vgdev->has_resource_blob) {
+ params.blob_mem = VIRTGPU_BLOB_MEM_GUEST;
+ params.blob_flags = VIRTGPU_BLOB_FLAG_USE_SHAREABLE;
+ params.blob = true;
+ }
+
ret = virtio_gpu_gem_create(file_priv, dev, ¶ms, &gobj,
&args->handle);
if (ret)
diff --git a/drivers/gpu/drm/virtio/virtgpu_object.c
b/drivers/gpu/drm/virtio/virtgpu_object.c
index 4ff1ec28e630..f648b0e24447 100644
--- a/drivers/gpu/drm/virtio/virtgpu_object.c
+++ b/drivers/gpu/drm/virtio/virtgpu_object.c
@@ -254,6 +254,9 @@ int virtio_gpu_object_create(struct virtio_gpu_device
*vgdev,
}
if (params->blob) {
+ if (params->blob_mem == VIRTGPU_BLOB_MEM_GUEST)
+ bo->guest_blob = true;
+
virtio_gpu_cmd_resource_create_blob(vgdev, bo, params,
ents, nents);
} else if (params->virgl) {
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [pull] amdgpu, radeon, ttm, sched drm-next-5.13
On Fri, Apr 2, 2021 at 12:22 PM Christian König wrote: > > Hey Alex, > > the TTM and scheduler changes should already be in the drm-misc-next > branch (not 100% sure about the TTM patch, need to double check next week). > The TTM change is not in drm-misc yet. > Could that cause problems when both are merged into drm-next? Dave, Daniel, how do you want to handle this? The duplicated patch is this one: https://cgit.freedesktop.org/drm/drm-misc/commit/?id=ac4eb83ab255de9c31184df51fd1534ba36fd212 amdgpu has changes which depend on it. The same patch is included in this PR. Thanks, Alex > > Thanks, > Christian. > > Am 02.04.21 um 00:29 schrieb Alex Deucher: > > Hi Dave, Daniel, > > > > New stuff for 5.13. There are two small patches for ttm and scheduler > > that were dependencies for amdgpu changes. > > > > The following changes since commit 2cbcb78c9ee5520c8d836c7ff57d1b60ebe8e9b7: > > > >Merge tag 'amd-drm-next-5.13-2021-03-23' of > > https://gitlab.freedesktop.org/agd5f/linux into drm-next (2021-03-26 > > 15:53:21 +0100) > > > > are available in the Git repository at: > > > >https://gitlab.freedesktop.org/agd5f/linux.git > > tags/amd-drm-next-5.13-2021-04-01 > > > > for you to fetch changes up to ef95d2a98d642a537190d73c45ae3c308afee890: > > > >drm/amdgpu/display: fix warning on 32 bit in dmub (2021-04-01 17:32:32 > > -0400) > > > > > > amd-drm-next-5.13-2021-04-01: > > > > amdgpu: > > - Re-enable GPU reset on VanGogh > > - Enable DPM flags for SMART_SUSPEND and MAY_SKIP_RESUME > > - Disentangle HG from vga_switcheroo > > - S0ix fixes > > - W=1 fixes > > - Resource iterator fixes > > - DMCUB updates > > - UBSAN fixes > > - More PM API cleanup > > - Aldebaran updates > > - Modifier fixes > > - Enable VCN load balancing with asymmetric engines > > - Rework BO structs > > - Aldebaran reset support > > - Initial LTTPR display work > > - Display MALL fixes > > - Fall back to YCbCr420 when YCbCr444 fails > > - SR-IOV fixes > > - Misc cleanups and fixes > > > > radeon: > > - Typo fixes > > > > ttm: > > - Handle cached requests (required for Aldebaran) > > > > scheduler: > > - Fix runqueue selection when changing priorities (required to fix VCN > >load balancing) > > > > > > Alex Deucher (20): > >drm/amdgpu/display/dm: add missing parameter documentation > >drm/amdgpu: Add additional Sienna Cichlid PCI ID > >drm/amdgpu: add a dev_pm_ops prepare callback (v2) > >drm/amdgpu: enable DPM_FLAG_MAY_SKIP_RESUME and > > DPM_FLAG_SMART_SUSPEND flags (v2) > >drm/amdgpu: disentangle HG systems from vgaswitcheroo > >drm/amdgpu: rework S3/S4/S0ix state handling > >drm/amdgpu: don't evict vram on APUs for suspend to ram (v4) > >drm/amdgpu: clean up non-DC suspend/resume handling > >drm/amdgpu: move s0ix check into amdgpu_device_ip_suspend_phase2 (v3) > >drm/amdgpu: re-enable suspend phase 2 for S0ix > >drm/amdgpu/swsmu: skip gfx cgpg on s0ix suspend > >drm/amdgpu: update comments about s0ix suspend/resume > >drm/amdgpu: drop S0ix checks around CG/PG in suspend > >drm/amdgpu: skip kfd suspend/resume for S0ix > >drm/amdgpu/display: restore AUX_DPHY_TX_CONTROL for DCN2.x > >drm/amdgpu/display: fix memory leak for dimgrey cavefish > >drm/amdgpu/pm: mark pcie link/speed arrays as const > >drm/amdgpu/pm: bail on sysfs/debugfs queries during platform suspend > >drm/amdgpu/vangogh: don't check for dpm in is_dpm_running when in > > suspend > >drm/amdgpu/display: fix warning on 32 bit in dmub > > > > Alex Sierra (2): > >drm/amdgpu: replace per_device_list by array > >drm/amdgpu: ih reroute for newer asics than vega20 > > > > Alvin Lee (1): > >drm/amd/display: Change input parameter for set_drr > > > > Anson Jacob (2): > >drm/amd/display: Fix UBSAN: shift-out-of-bounds warning > >drm/amd/display: Removing unused code from dmub_cmd.h > > > > Anthony Koo (2): > >drm/amd/display: [FW Promotion] Release 0.0.57 > >drm/amd/display: [FW Promotion] Release 0.0.58 > > > > Aric Cyr (2): > >drm/amd/display: 3.2.128 > >drm/amd/display: 3.2.129 > > > > Arnd Bergmann (3): > >amdgpu: avoid incorrect %hu format string > >amdgpu: fix gcc -Wrestrict warning > >amdgpu: securedisplay: simplify i2c hexdump output > > > > Bhaskar Chowdhury (6): > >drm/amdgpu: Fix a typo > >drm/amdgpu: Fix a typo > >drm/atomic: Couple of typo fixes > >drm/radeon/r600_cs: Few typo fixes > >drm/amd/amdgpu/gfx_v7_0: Trivial typo fixes > >drm/amd: Fix a typo in two different sentences > > > > Bindu Ramamurthy (1): > >drm/amd/display: Allow idle optimization based on vblank. > > > > Chengming Gui (1): > >drm/
Re: [PATCH] drm/radeon/ttm: Fix memory leak userptr pages
On Mon, Mar 22, 2021 at 6:34 AM Christian König wrote: > > Hi Daniel, > > Am 22.03.21 um 10:38 schrieb Daniel Gomez: > > On Fri, 19 Mar 2021 at 21:29, Felix Kuehling wrote: > >> This caused a regression in kfdtest in a large-buffer stress test after > >> memory allocation for user pages fails: > > I'm sorry to hear that. BTW, I guess you meant amdgpu leak patch and > > not this one. > > Just some background for the mem leak patch if helps to understand this: > > The leak was introduce here: > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0b988ca1c7c4c73983b4ea96ef7c2af2263c87eb > > where the bound status was introduced for all drm drivers including > > radeon and amdgpu. So this patch just reverts the logic to the > > original code but keeping the bound status. In my case, the binding > > code allocates the user pages memory and returns without bounding (at > > amdgpu_gtt_mgr_has_gart_addr). So, > > when the unbinding happens, the memory needs to be cleared to prevent the > > leak. > > Ah, now I understand what's happening here. Daniel your patch is not > really correct. > > The problem is rather that we don't set the tt object to bound if it > doesn't have a GTT address. > > Going to provide a patch for this. Did this patch ever land? Alex > > Regards, > Christian. > > > > >> [17359.536303] amdgpu: init_user_pages: Failed to get user pages: -16 > >> [17359.543746] BUG: kernel NULL pointer dereference, address: > >> > >> [17359.551494] #PF: supervisor read access in kernel mode > >> [17359.557375] #PF: error_code(0x) - not-present page > >> [17359.563247] PGD 0 P4D 0 > >> [17359.566514] Oops: [#1] SMP PTI > >> [17359.570728] CPU: 8 PID: 5944 Comm: kfdtest Not tainted > >> 5.11.0-kfd-fkuehlin #193 > >> [17359.578760] Hardware name: ASUS All Series/X99-E WS/USB 3.1, BIOS 3201 > >> 06/17/2016 > >> [17359.586971] RIP: 0010:amdgpu_ttm_backend_unbind+0x52/0x110 [amdgpu] > >> [17359.594075] Code: 48 39 c6 74 1b 8b 53 0c 48 8d bd 80 a1 ff ff e8 24 62 > >> 00 00 85 c0 0f 85 ab 00 00 00 c6 43 54 00 5b 5d c3 48 8b 46 10 8b 4e 50 > >> <48> 8b 30 48 85 f6 74 ba 8b 50 0c 48 8b bf 80 a1 ff ff 83 e1 01 45 > >> [17359.614340] RSP: 0018:a4764971fc98 EFLAGS: 00010206 > >> [17359.620315] RAX: RBX: 950e8d4edf00 RCX: > >> > >> [17359.628204] RDX: RSI: 950e8d4edf00 RDI: > >> 950eadec5e80 > >> [17359.636084] RBP: 950eadec5e80 R08: R09: > >> > >> [17359.643958] R10: 0246 R11: 0001 R12: > >> 950c03377800 > >> [17359.651833] R13: 950eadec5e80 R14: 950c03377858 R15: > >> > >> [17359.659701] FS: 7febb20cb740() GS:950ebfc0() > >> knlGS: > >> [17359.668528] CS: 0010 DS: ES: CR0: 80050033 > >> [17359.675012] CR2: CR3: 0006d700e005 CR4: > >> 001706e0 > >> [17359.682883] Call Trace: > >> [17359.686063] amdgpu_ttm_backend_destroy+0x12/0x70 [amdgpu] > >> [17359.692349] ttm_bo_cleanup_memtype_use+0x37/0x60 [ttm] > >> [17359.698307] ttm_bo_release+0x278/0x5e0 [ttm] > >> [17359.703385] amdgpu_bo_unref+0x1a/0x30 [amdgpu] > >> [17359.708701] amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu+0x7e5/0x910 > >> [amdgpu] > >> [17359.716307] kfd_ioctl_alloc_memory_of_gpu+0x11a/0x220 [amdgpu] > >> [17359.723036] kfd_ioctl+0x223/0x400 [amdgpu] > >> [17359.728017] ? kfd_dev_is_large_bar+0x90/0x90 [amdgpu] > >> [17359.734152] __x64_sys_ioctl+0x8b/0xd0 > >> [17359.738796] do_syscall_64+0x2d/0x40 > >> [17359.743259] entry_SYSCALL_64_after_hwframe+0x44/0xa9 > >> [17359.749205] RIP: 0033:0x7febb083b6d7 > >> [17359.753681] Code: b3 66 90 48 8b 05 b1 47 2d 00 64 c7 00 26 00 00 00 48 > >> c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 > >> <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 81 47 2d 00 f7 d8 64 89 01 48 > >> [17359.774340] RSP: 002b:7ffdb5522cd8 EFLAGS: 0202 ORIG_RAX: > >> 0010 > >> [17359.782668] RAX: ffda RBX: 0001 RCX: > >> 7febb083b6d7 > >> [17359.790566] RDX: 7ffdb5522d60 RSI: c0284b16 RDI: > >> 0003 > >> [17359.798459] RBP: 7ffdb5522d10 R08: 7ffdb5522dd0 R09: > >> c404 > >> [17359.806352] R10: R11: 0202 R12: > >> 559416e4e2aa > >> [17359.814251] R13: R14: 0021 R15: > >> > >> [17359.822140] Modules linked in: ip6table_filter ip6_tables > >> iptable_filter amdgpu x86_pkg_temp_thermal drm_ttm_helper ttm iommu_v2 > >> gpu_sched ip_tables x_tables > >> [17359.837776] CR2: > >> [17359.841888] ---[ end trace a6f27d64475b28c8 ]--- > >> [17359.847318] RIP: 0010:amdgpu_ttm_backend_unbind+0x52/0x110 [amdgpu] > >> [17359.854479] Code: 48 39 c6 74 1b 8b 53 0c 48 8d bd 80 a1 ff ff e8 24 62 > >> 00 00 85 c0 0f 85 ab 00 00 00 c6 43 5
[PATCH 0/3] drm/msm/mdp5: Emit vsync signal often enough
This set of patches corrects and improves VSync-related register setup on the MDP5 block. Values written to the registers were way too high leading to the MDSS block counting way too many ticks on the vclk before emitting a vsync interrupt, resulting in significant update issues on command- and video-mode panels. With lower values - that match those of downstream kernels - the panels on Sony devices (Xperia X, XA2 Ultra, and more) update at an acceptable rate without "pp_done" timeouts. The Driver-IC in these panels is also able to drive an interrupt line and a future patchset will enable the use of this "disp-te" GPIO beyond acquiring it in dsi_host. This fixes panel framerate the correct way (instead of running at half the desired framerate), but these patches are still needed to aid development now and shorten lockup times when the TE interrupt misbehaves by not arriving at all. AngeloGioacchino Del Regno (1): drm/msm/mdp5: Disable pingpong autorefresh at tearcheck init Marijn Suijten (2): drm/msm/mdp5: Configure PP_SYNC_HEIGHT to double the vtotal drm/msm/mdp5: Do not multiply vclk line count by 100 drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c | 11 ++- 1 file changed, 6 insertions(+), 5 deletions(-) -- 2.31.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/3] drm/msm/mdp5: Do not multiply vclk line count by 100
Neither vtotal nor drm_mode_vrefresh contain a value that is
premultiplied by 100 making the x100 variable name incorrect and
resulting in vclks_line to become 100 times larger than it is supposed
to be. The hardware counts 100 clockticks too many before tearcheck,
leading to severe panel issues on at least the Sony Xperia lineup.
This is likely an artifact from the original MDSS DSI panel driver where
the calculation [1] corrected for a premultiplied reference framerate by
100 [2]. It does not appear that the above values were ever
premultiplied in the history of the DRM MDP5 driver.
With this change applied the value written to the SYNC_CONFIG_VSYNC
register is now identical to downstream kernels.
[1]:
https://source.codeaurora.org/quic/la/kernel/msm-3.18/tree/drivers/video/msm/mdss/mdss_mdp_intf_cmd.c?h=LA.UM.8.6.c26-02400-89xx.0#n288
[2]:
https://source.codeaurora.org/quic/la/kernel/msm-3.18/tree/drivers/video/msm/mdss/mdss_dsi_panel.c?h=LA.UM.8.6.c26-02400-89xx.0#n1648
Reviewed-by: AngeloGioacchino Del Regno
Signed-off-by: Marijn Suijten
---
drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c
index 2d5ac03dbc17..0bda4257823a 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c
@@ -20,7 +20,7 @@ static int pingpong_tearcheck_setup(struct drm_encoder
*encoder,
{
struct mdp5_kms *mdp5_kms = get_kms(encoder);
struct device *dev = encoder->dev->dev;
- u32 total_lines_x100, vclks_line, cfg;
+ u32 total_lines, vclks_line, cfg;
long vsync_clk_speed;
struct mdp5_hw_mixer *mixer = mdp5_crtc_get_mixer(encoder->crtc);
int pp_id = mixer->pp;
@@ -30,8 +30,8 @@ static int pingpong_tearcheck_setup(struct drm_encoder
*encoder,
return -EINVAL;
}
- total_lines_x100 = mode->vtotal * drm_mode_vrefresh(mode);
- if (!total_lines_x100) {
+ total_lines = mode->vtotal * drm_mode_vrefresh(mode);
+ if (!total_lines) {
DRM_DEV_ERROR(dev, "%s: vtotal(%d) or vrefresh(%d) is 0\n",
__func__, mode->vtotal, drm_mode_vrefresh(mode));
return -EINVAL;
@@ -43,7 +43,7 @@ static int pingpong_tearcheck_setup(struct drm_encoder
*encoder,
vsync_clk_speed);
return -EINVAL;
}
- vclks_line = vsync_clk_speed * 100 / total_lines_x100;
+ vclks_line = vsync_clk_speed / total_lines;
cfg = MDP5_PP_SYNC_CONFIG_VSYNC_COUNTER_EN
| MDP5_PP_SYNC_CONFIG_VSYNC_IN_EN;
--
2.31.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/3] drm/msm/mdp5: Configure PP_SYNC_HEIGHT to double the vtotal
Leaving this at a close-to-maximum register value 0xFFF0 means it takes very long for the MDSS to generate a software vsync interrupt when the hardware TE interrupt doesn't arrive. Configuring this to double the vtotal (like some downstream kernels) leads to a frame to take at most twice before the vsync signal, until hardware TE comes up. In this case the hardware interrupt responsible for providing this signal - "disp-te" gpio - is not hooked up to the mdp5 vsync/pp logic at all. This solves severe panel update issues observed on at least the Xperia Loire and Tone series, until said gpio is properly hooked up to an irq. Suggested-by: AngeloGioacchino Del Regno Signed-off-by: Marijn Suijten Reviewed-by: AngeloGioacchino Del Regno --- drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c b/drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c index ff2c1d583c79..2d5ac03dbc17 100644 --- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c +++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c @@ -51,7 +51,7 @@ static int pingpong_tearcheck_setup(struct drm_encoder *encoder, mdp5_write(mdp5_kms, REG_MDP5_PP_SYNC_CONFIG_VSYNC(pp_id), cfg); mdp5_write(mdp5_kms, - REG_MDP5_PP_SYNC_CONFIG_HEIGHT(pp_id), 0xfff0); + REG_MDP5_PP_SYNC_CONFIG_HEIGHT(pp_id), (2 * mode->vtotal)); mdp5_write(mdp5_kms, REG_MDP5_PP_VSYNC_INIT_VAL(pp_id), mode->vdisplay); mdp5_write(mdp5_kms, REG_MDP5_PP_RD_PTR_IRQ(pp_id), mode->vdisplay + 1); -- 2.31.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/3] drm/msm/mdp5: Disable pingpong autorefresh at tearcheck init
From: AngeloGioacchino Del Regno If pp autorefresh is up (from bootloader splash), we will surely get vblank and pp timeouts. Ensure it is turned off. Signed-off-by: AngeloGioacchino Del Regno Signed-off-by: Marijn Suijten --- drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c b/drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c index 0bda4257823a..66315b82dd6e 100644 --- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c +++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c @@ -59,6 +59,7 @@ static int pingpong_tearcheck_setup(struct drm_encoder *encoder, mdp5_write(mdp5_kms, REG_MDP5_PP_SYNC_THRESH(pp_id), MDP5_PP_SYNC_THRESH_START(4) | MDP5_PP_SYNC_THRESH_CONTINUE(4)); + mdp5_write(mdp5_kms, REG_MDP5_PP_AUTOREFRESH_CONFIG(pp_id), 0x0); return 0; } -- 2.31.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] clk: fixed: fix double free in resource managed fixed-factor clock
devm_clk_hw_register_fixed_factor_release(), the release function for
the devm_clk_hw_register_fixed_factor(), calls
clk_hw_unregister_fixed_factor(), which will kfree() the clock. However
after that the devres functions will also kfree the allocated data,
resulting in double free/memory corruption. Just call
clk_hw_unregister() instead, leaving kfree() to devres code.
Reported-by: Rob Clark
Cc: Daniel Palmer
Signed-off-by: Dmitry Baryshkov
---
Stephen, this fix affects the DSI PHY rework. Do we have a chance of
getting it into 5.12, otherwise there will be a cross-dependency between
msm-next and clk-next.
---
drivers/clk/clk-fixed-factor.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/clk-fixed-factor.c b/drivers/clk/clk-fixed-factor.c
index 4f7bf3929d6d..390c16f321a6 100644
--- a/drivers/clk/clk-fixed-factor.c
+++ b/drivers/clk/clk-fixed-factor.c
@@ -66,7 +66,12 @@ EXPORT_SYMBOL_GPL(clk_fixed_factor_ops);
static void devm_clk_hw_register_fixed_factor_release(struct device *dev, void
*res)
{
- clk_hw_unregister_fixed_factor(&((struct clk_fixed_factor *)res)->hw);
+ /*
+* We can not use clk_hw_unregister_fixed_factor, since it will kfree()
+* the hw, resulting in double free. Just unregister the hw and let
+* devres code kfree() it.
+*/
+ clk_hw_unregister(&((struct clk_fixed_factor *)res)->hw);
}
static struct clk_hw *
--
2.30.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/virtio: Create Dumb BOs as guest Blobs (v2)
On Tue, Apr 6, 2021 at 1:47 PM Vivek Kasireddy
wrote:
> If support for Blob resources is available, then dumb BOs created
> by the driver can be considered as guest Blobs.
>
> v2: Don't skip transfer and flush commands as part of plane update
> as the device may have created a shared mapping. (Gerd)
>
> Cc: Gerd Hoffmann
> Signed-off-by: Vivek Kasireddy
> ---
> drivers/gpu/drm/virtio/virtgpu_gem.c| 8
> drivers/gpu/drm/virtio/virtgpu_object.c | 3 +++
> 2 files changed, 11 insertions(+)
>
> diff --git a/drivers/gpu/drm/virtio/virtgpu_gem.c
> b/drivers/gpu/drm/virtio/virtgpu_gem.c
> index 8502400b2f9c..5f49fb1cce65 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_gem.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_gem.c
> @@ -64,6 +64,7 @@ int virtio_gpu_mode_dumb_create(struct drm_file
> *file_priv,
> {
> struct drm_gem_object *gobj;
> struct virtio_gpu_object_params params = { 0 };
> + struct virtio_gpu_device *vgdev = dev->dev_private;
> int ret;
> uint32_t pitch;
>
> @@ -79,6 +80,13 @@ int virtio_gpu_mode_dumb_create(struct drm_file
> *file_priv,
> params.height = args->height;
> params.size = args->size;
> params.dumb = true;
> +
> + if (vgdev->has_resource_blob) {
> + params.blob_mem = VIRTGPU_BLOB_MEM_GUEST;
> + params.blob_flags = VIRTGPU_BLOB_FLAG_USE_SHAREABLE;
>
This creates some log spam with crosvm + virgl_3d + vanilla linux, since
transfers don't work for guest blobs. Two options:
a) Add vgdev->has_virgl_3d check and don't create a guest blob in that case.
b) The interactions between TRANSFER_TO_HOST_2D and VIRTGPU_BLOB_MEM_GUEST
are a bit under-defined in the spec. Though since you don't have a host
side resource, you can safely skip the transfer and crosvm can be modified
to do the right thing in case of RESOURCE_FLUSH.
It makes a ton of sense to have a explicit udmabuf-like flag
("BLOB_FLAG_CREATE_GUEST_HANDLE" or "BLOB_FLAG_HANDLE_FROM_GUEST" -- want
to host OS agnostic -- any other ideas?), especially with 3d mode. For
now, implicit udmabuf + dumb should be fine since the QEMU patches have
been floating around for a while and should land soon for future use cases.
> + params.blob = true;
> + }
>
> +
> ret = virtio_gpu_gem_create(file_priv, dev, ¶ms, &gobj,
> &args->handle);
> if (ret)
> diff --git a/drivers/gpu/drm/virtio/virtgpu_object.c
> b/drivers/gpu/drm/virtio/virtgpu_object.c
> index 4ff1ec28e630..f648b0e24447 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_object.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_object.c
> @@ -254,6 +254,9 @@ int virtio_gpu_object_create(struct virtio_gpu_device
> *vgdev,
> }
>
> if (params->blob) {
> + if (params->blob_mem == VIRTGPU_BLOB_MEM_GUEST)
> + bo->guest_blob = true;
> +
> virtio_gpu_cmd_resource_create_blob(vgdev, bo, params,
> ents, nents);
> } else if (params->virgl) {
> --
> 2.26.2
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH v5 1/2] dt-bindings: drm/bridge: MHDP8546 bridge binding changes for HDCP
Hi Rob, Thanks for your comment and sorry for late response. >> -minItems: 1 >> -maxItems: 2 >> +minItems: 2 >> +maxItems: 3 > >1 entry was valid and now it is not? That's not a compatible change and >needs an explanation at a minimum. Yes, as the driver returns error in the absence of SAPB port address range, this may break the driver on platform without SAPB port. This IP needs SAPB port to support HDCP feature using embedded HDCP crypto module. So, to maintain backward compatibility I will modify the driver and allow it to proceed without HDCP feature, instead of returning an error, in case of no SAPB port. Regards, Parshuram Thombare ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] video: fbdev: sm501fb: Fix deallocation of buffers order
The resource release in sm501fb_remove() is not in the inverse order of sm501fb_probe(), for the buffers. Release the info object after deallocating the buffers. Signed-off-by: Aditya Pakki --- drivers/video/fbdev/sm501fb.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/video/fbdev/sm501fb.c b/drivers/video/fbdev/sm501fb.c index 6a52eba64559..4c32c9e88850 100644 --- a/drivers/video/fbdev/sm501fb.c +++ b/drivers/video/fbdev/sm501fb.c @@ -2060,11 +2060,11 @@ static int sm501fb_remove(struct platform_device *pdev) unregister_framebuffer(fbinfo_pnl); sm501fb_stop(info); - kfree(info); framebuffer_release(fbinfo_pnl); framebuffer_release(fbinfo_crt); + kfree(info); return 0; } -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drivers/gpu/drm/ttm/ttm_page_allo.c: adjust ttm pages refcount fix the bug: Feb 6 17:13:13 aaa-PC kernel: [ 466.271034] BUG: Bad page state in process blur_image pfn:7aee2 Feb 6 17:13:13 aaa-P
Signed-off-by: songqiang
---
drivers/gpu/drm/ttm/ttm_page_alloc.c | 18 ++
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c
b/drivers/gpu/drm/ttm/ttm_page_alloc.c
index 14660f723f71..f3698f0ad4d7 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
@@ -736,8 +736,16 @@ static void ttm_put_pages(struct page **pages, unsigned
npages, int flags,
if (++p != pages[i + j])
break;
- if (j == HPAGE_PMD_NR)
+ if (j == HPAGE_PMD_NR) {
order = HPAGE_PMD_ORDER;
+ for (j = 1; j < HPAGE_PMD_NR; ++j)
+ page_ref_dec(pages[i+j]);
+ }
}
#endif
@@ -868,10 +876,12 @@ static int ttm_get_pages(struct page **pages, unsigned
npages, int flags,
p = alloc_pages(huge_flags, HPAGE_PMD_ORDER);
if (!p)
break;
-
- for (j = 0; j < HPAGE_PMD_NR; ++j)
+ for (j = 0; j < HPAGE_PMD_NR; ++j) {
pages[i++] = p++;
-
+ if (j > 0)
+ page_ref_inc(pages[i-1]);
+ }
npages -= HPAGE_PMD_NR;
}
}
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1] drm/radeon: Fix a missing check bug in radeon_dp_mst_detect()
From: Yingjie Wang
In radeon_dp_mst_detect(), We should check whether or not @connector
has been unregistered from userspace. If the connector is unregistered,
we should return disconnected status.
Fixes: 9843ead08f18 ("drm/radeon: add DisplayPort MST support (v2)")
Signed-off-by: Yingjie Wang
---
drivers/gpu/drm/radeon/radeon_dp_mst.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/radeon/radeon_dp_mst.c
b/drivers/gpu/drm/radeon/radeon_dp_mst.c
index 2c32186c4acd..4e4c937c36c6 100644
--- a/drivers/gpu/drm/radeon/radeon_dp_mst.c
+++ b/drivers/gpu/drm/radeon/radeon_dp_mst.c
@@ -242,6 +242,9 @@ radeon_dp_mst_detect(struct drm_connector *connector,
to_radeon_connector(connector);
struct radeon_connector *master = radeon_connector->mst_port;
+ if (drm_connector_is_unregistered(connector))
+ return connector_status_disconnected;
+
return drm_dp_mst_detect_port(connector, ctx, &master->mst_mgr,
radeon_connector->port);
}
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [pull] amdgpu, radeon, ttm, sched drm-next-5.13
Am 06.04.21 um 17:42 schrieb Felix Kuehling: Am 2021-04-01 um 6:29 p.m. schrieb Alex Deucher: Hi Dave, Daniel, New stuff for 5.13. There are two small patches for ttm and scheduler that were dependencies for amdgpu changes. The following changes since commit 2cbcb78c9ee5520c8d836c7ff57d1b60ebe8e9b7: Merge tag 'amd-drm-next-5.13-2021-03-23' of https://gitlab.freedesktop.org/agd5f/linux into drm-next (2021-03-26 15:53:21 +0100) are available in the Git repository at: https://gitlab.freedesktop.org/agd5f/linux.git tags/amd-drm-next-5.13-2021-04-01 for you to fetch changes up to ef95d2a98d642a537190d73c45ae3c308afee890: drm/amdgpu/display: fix warning on 32 bit in dmub (2021-04-01 17:32:32 -0400) amd-drm-next-5.13-2021-04-01: amdgpu: - Re-enable GPU reset on VanGogh - Enable DPM flags for SMART_SUSPEND and MAY_SKIP_RESUME - Disentangle HG from vga_switcheroo - S0ix fixes - W=1 fixes - Resource iterator fixes - DMCUB updates - UBSAN fixes - More PM API cleanup - Aldebaran updates - Modifier fixes - Enable VCN load balancing with asymmetric engines - Rework BO structs - Aldebaran reset support - Initial LTTPR display work - Display MALL fixes - Fall back to YCbCr420 when YCbCr444 fails - SR-IOV fixes - Misc cleanups and fixes radeon: - Typo fixes ttm: - Handle cached requests (required for Aldebaran) scheduler: - Fix runqueue selection when changing priorities (required to fix VCN load balancing) Alex Deucher (20): drm/amdgpu/display/dm: add missing parameter documentation drm/amdgpu: Add additional Sienna Cichlid PCI ID drm/amdgpu: add a dev_pm_ops prepare callback (v2) drm/amdgpu: enable DPM_FLAG_MAY_SKIP_RESUME and DPM_FLAG_SMART_SUSPEND flags (v2) drm/amdgpu: disentangle HG systems from vgaswitcheroo drm/amdgpu: rework S3/S4/S0ix state handling drm/amdgpu: don't evict vram on APUs for suspend to ram (v4) drm/amdgpu: clean up non-DC suspend/resume handling drm/amdgpu: move s0ix check into amdgpu_device_ip_suspend_phase2 (v3) drm/amdgpu: re-enable suspend phase 2 for S0ix drm/amdgpu/swsmu: skip gfx cgpg on s0ix suspend drm/amdgpu: update comments about s0ix suspend/resume drm/amdgpu: drop S0ix checks around CG/PG in suspend drm/amdgpu: skip kfd suspend/resume for S0ix drm/amdgpu/display: restore AUX_DPHY_TX_CONTROL for DCN2.x drm/amdgpu/display: fix memory leak for dimgrey cavefish drm/amdgpu/pm: mark pcie link/speed arrays as const drm/amdgpu/pm: bail on sysfs/debugfs queries during platform suspend drm/amdgpu/vangogh: don't check for dpm in is_dpm_running when in suspend drm/amdgpu/display: fix warning on 32 bit in dmub Alex Sierra (2): drm/amdgpu: replace per_device_list by array drm/amdgpu: ih reroute for newer asics than vega20 Alvin Lee (1): drm/amd/display: Change input parameter for set_drr Anson Jacob (2): drm/amd/display: Fix UBSAN: shift-out-of-bounds warning drm/amd/display: Removing unused code from dmub_cmd.h Anthony Koo (2): drm/amd/display: [FW Promotion] Release 0.0.57 drm/amd/display: [FW Promotion] Release 0.0.58 Aric Cyr (2): drm/amd/display: 3.2.128 drm/amd/display: 3.2.129 Arnd Bergmann (3): amdgpu: avoid incorrect %hu format string amdgpu: fix gcc -Wrestrict warning amdgpu: securedisplay: simplify i2c hexdump output Bhaskar Chowdhury (6): drm/amdgpu: Fix a typo drm/amdgpu: Fix a typo drm/atomic: Couple of typo fixes drm/radeon/r600_cs: Few typo fixes drm/amd/amdgpu/gfx_v7_0: Trivial typo fixes drm/amd: Fix a typo in two different sentences Bindu Ramamurthy (1): drm/amd/display: Allow idle optimization based on vblank. Chengming Gui (1): drm/amd/amdgpu: set MP1 state to UNLOAD before reload its FW for vega20/ALDEBARAN Chris Park (1): drm/amd/display: Disable MALL when SMU not present Christian König (5): drm/amdgpu: remove irq_src->data handling drm/amdgpu: add the sched_score to amdgpu_ring_init drm/amdgpu: share scheduler score on VCN3 instances drm/sched: select new rq even if there is only one v3 drm/amdgpu: load balance VCN3 decode as well v8 Daniel Gomez (2): drm/amdgpu/ttm: Fix memory leak userptr pages This introduced a regression for KFD, which I pointed out at the time. Was there ever a fix for that. This was fixed recently by somebody else. I've reviewed the patch, but I'm not sure if it landed inside the branch. Regards, Christian. Regards, Felix drm/radeon/ttm: Fix memory leak userptr pages David Galiffi (1): drm/amd/display: Fixed Clock Recovery Sequence Dennis Li (1): drm/amdgpu: add codes to capture invalid hardware access when recovery Di
Re: [PATCH] drm/panel: panel-dsi-cm: disable TE for now
Hi,
* Tomi Valkeinen [210316 14:12]:
> Hi Sebastian, Sam, Thierry,
>
> On 27/02/2021 23:45, Sebastian Reichel wrote:
> > From: Sebastian Reichel
> >
> > Disable TE for Droid 4 panel, since implementation is currently
> > broken. Also disable it for N950 panel, which is untested.
> >
> > Reported-by: Tony Lindgren
> > Reported-by: Tomi Valkeinen
> > Fixes: 4c1b935fea54 ("drm/omap: dsi: move TE GPIO handling into core")
> > Signed-off-by: Sebastian Reichel
> > ---
> > I suggest to start by fix the regression like this and look into
> > proper Droid 4 TE support separatly. Assumption is, that Tomi
> > tested taal panel, droid4 panel is 'broken' and N950 (himalaya)
> > is untested [*], so choosing safe default. Patch is compile-tested
> > only.
> >
> > [*] N950 display is not yet functional on mainline, since it needs
> > the omap3 FIFO workaround:
> > https://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-n900.git/commit/?h=n950-display-tony&id=d4cbc226a30b29bf258397b052c9ec68c8a3
> > ---
> > drivers/gpu/drm/panel/panel-dsi-cm.c | 12 +---
> > 1 file changed, 9 insertions(+), 3 deletions(-)
>
> Reviewed-by: Tomi Valkeinen
>
> Sam, Thierry, will you pick this up or can I push to drm-misc-fixes?
Looks like this regression fix is still pending, can you guys please
apply?
Regards,
Tony
> > diff --git a/drivers/gpu/drm/panel/panel-dsi-cm.c
> > b/drivers/gpu/drm/panel/panel-dsi-cm.c
> > index af381d756ac1..5fbfb71ca3d9 100644
> > --- a/drivers/gpu/drm/panel/panel-dsi-cm.c
> > +++ b/drivers/gpu/drm/panel/panel-dsi-cm.c
> > @@ -37,6 +37,7 @@ struct dsic_panel_data {
> > u32 height_mm;
> > u32 max_hs_rate;
> > u32 max_lp_rate;
> > + bool te_support;
> > };
> > struct panel_drv_data {
> > @@ -334,9 +335,11 @@ static int dsicm_power_on(struct panel_drv_data *ddata)
> > if (r)
> > goto err;
> > - r = mipi_dsi_dcs_set_tear_on(ddata->dsi, MIPI_DSI_DCS_TEAR_MODE_VBLANK);
> > - if (r)
> > - goto err;
> > + if (ddata->panel_data->te_support) {
> > + r = mipi_dsi_dcs_set_tear_on(ddata->dsi,
> > MIPI_DSI_DCS_TEAR_MODE_VBLANK);
> > + if (r)
> > + goto err;
> > + }
> > /* possible panel bug */
> > msleep(100);
> > @@ -619,6 +622,7 @@ static const struct dsic_panel_data taal_data = {
> > .height_mm = 0,
> > .max_hs_rate = 3,
> > .max_lp_rate = 1000,
> > + .te_support = true,
> > };
> > static const struct dsic_panel_data himalaya_data = {
> > @@ -629,6 +633,7 @@ static const struct dsic_panel_data himalaya_data = {
> > .height_mm = 88,
> > .max_hs_rate = 3,
> > .max_lp_rate = 1000,
> > + .te_support = false,
> > };
> > static const struct dsic_panel_data droid4_data = {
> > @@ -639,6 +644,7 @@ static const struct dsic_panel_data droid4_data = {
> > .height_mm = 89,
> > .max_hs_rate = 3,
> > .max_lp_rate = 1000,
> > + .te_support = false,
> > };
> > static const struct of_device_id dsicm_of_match[] = {
> >
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] pwm: Rename pwm_get_state() to better reflect its semantic
Given that lowlevel drivers usually cannot implement exactly what a
consumer requests with pwm_apply_state() there is some rounding involved.
pwm_get_state() traditionally returned the setting that was requested most
recently by the consumer (opposed to what was actually implemented in
hardware in reply to the last request). To make this semantic obvious
rename the function.
Signed-off-by: Uwe Kleine-König
---
Documentation/driver-api/pwm.rst | 6 +++-
drivers/clk/clk-pwm.c | 2 +-
drivers/gpu/drm/i915/display/intel_panel.c | 4 +--
drivers/input/misc/da7280.c| 2 +-
drivers/input/misc/pwm-beeper.c| 2 +-
drivers/input/misc/pwm-vibra.c | 4 +--
drivers/pwm/core.c | 4 +--
drivers/pwm/pwm-atmel-hlcdc.c | 2 +-
drivers/pwm/pwm-atmel.c| 2 +-
drivers/pwm/pwm-imx27.c| 2 +-
drivers/pwm/pwm-rockchip.c | 2 +-
drivers/pwm/pwm-stm32-lp.c | 4 +--
drivers/pwm/pwm-sun4i.c| 2 +-
drivers/pwm/sysfs.c| 18 ++--
drivers/regulator/pwm-regulator.c | 4 +--
drivers/video/backlight/pwm_bl.c | 10 +++
include/linux/pwm.h| 34 ++
17 files changed, 59 insertions(+), 45 deletions(-)
diff --git a/Documentation/driver-api/pwm.rst b/Documentation/driver-api/pwm.rst
index ab62f1bb0366..381f3c46cdac 100644
--- a/Documentation/driver-api/pwm.rst
+++ b/Documentation/driver-api/pwm.rst
@@ -55,7 +55,11 @@ several parameter at once. For example, if you see
pwm_config() and
pwm_{enable,disable}() calls in the same function, this probably means you
should switch to pwm_apply_state().
-The PWM user API also allows one to query the PWM state with pwm_get_state().
+The PWM user API also allows one to query the last applied PWM state with
+pwm_get_last_applied_state(). Note this is different to what the driver has
+actually implemented if the request cannot be implemented exactly with the
+hardware in use. There is currently no way for consumers to get the actually
+implemented settings.
In addition to the PWM state, the PWM API also exposes PWM arguments, which
are the reference PWM config one should use on this PWM.
diff --git a/drivers/clk/clk-pwm.c b/drivers/clk/clk-pwm.c
index da2c8eddfd9f..7cfaff32980b 100644
--- a/drivers/clk/clk-pwm.c
+++ b/drivers/clk/clk-pwm.c
@@ -49,7 +49,7 @@ static int clk_pwm_get_duty_cycle(struct clk_hw *hw, struct
clk_duty *duty)
struct clk_pwm *clk_pwm = to_clk_pwm(hw);
struct pwm_state state;
- pwm_get_state(clk_pwm->pwm, &state);
+ pwm_get_last_applied_state(clk_pwm->pwm, &state);
duty->num = state.duty_cycle;
duty->den = state.period;
diff --git a/drivers/gpu/drm/i915/display/intel_panel.c
b/drivers/gpu/drm/i915/display/intel_panel.c
index 5fdf52643150..3aebf9be6b6a 100644
--- a/drivers/gpu/drm/i915/display/intel_panel.c
+++ b/drivers/gpu/drm/i915/display/intel_panel.c
@@ -627,7 +627,7 @@ static u32 ext_pwm_get_backlight(struct intel_connector
*connector, enum pipe un
struct intel_panel *panel = &connector->panel;
struct pwm_state state;
- pwm_get_state(panel->backlight.pwm, &state);
+ pwm_get_last_applied_state(panel->backlight.pwm, &state);
return pwm_get_relative_duty_cycle(&state, 100);
}
@@ -1915,7 +1915,7 @@ static int ext_pwm_setup_backlight(struct intel_connector
*connector,
if (pwm_is_enabled(panel->backlight.pwm)) {
/* PWM is already enabled, use existing settings */
- pwm_get_state(panel->backlight.pwm,
&panel->backlight.pwm_state);
+ pwm_get_last_applied_state(panel->backlight.pwm,
&panel->backlight.pwm_state);
level = pwm_get_relative_duty_cycle(&panel->backlight.pwm_state,
100);
diff --git a/drivers/input/misc/da7280.c b/drivers/input/misc/da7280.c
index b08610d6e575..409670be1d2b 100644
--- a/drivers/input/misc/da7280.c
+++ b/drivers/input/misc/da7280.c
@@ -333,7 +333,7 @@ static int da7280_haptic_set_pwm(struct da7280_haptic
*haptics, bool enabled)
return -EINVAL;
}
- pwm_get_state(haptics->pwm_dev, &state);
+ pwm_get_last_applied_state(haptics->pwm_dev, &state);
state.enabled = enabled;
if (enabled) {
period_mag_multi = (u64)state.period * haptics->gain;
diff --git a/drivers/input/misc/pwm-beeper.c b/drivers/input/misc/pwm-beeper.c
index d6b12477748a..4c5f09201ecf 100644
--- a/drivers/input/misc/pwm-beeper.c
+++ b/drivers/input/misc/pwm-beeper.c
@@ -33,7 +33,7 @@ static int pwm_beeper_on(struct pwm_beeper *beeper, unsigned
long period)
struct pwm_state state;
int error;
- pwm_get_state(beeper->pwm, &state);
+ pwm_get_last_applied_state(beeper->pwm, &stat
[Bug 200695] Blank screen on RX 580 with amdgpu.dc=1 enabled (no displays detected)
https://bugzilla.kernel.org/show_bug.cgi?id=200695 farshad (fars...@7d.nz) changed: What|Removed |Added CC||fars...@7d.nz --- Comment #49 from farshad (fars...@7d.nz) --- Had the same problem on a Dell Latitude 5410 with a Lexa Radeon E9171 MCM and linux kernel 4.19.0.13 (Debian Buster), Read it's still and issue with 4.20-rc5 *Now operational with a kernel 5.11* default options. The Lexa serie is in the RX540, RX550 550X et RX550X range, (sold 80$ en 2017) DRM was loading followed by ACPI error, field tmpb at bot offset exceed size of target buffer... method parse/execution failed SB.PCIO.GFX0.ATRM, AE_AML_BUFFER_LIMIT Error message was : Error DC : number of connector is zero -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/4] drm/gem-ttm-helper: Provide helper for struct drm_driver.dumb_map_offset
Provides an implementation of struct drm_driver.dumb_map_offset that
can be used by TTM-based GEM drivers.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_gem_ttm_helper.c | 33
include/drm/drm_gem_ttm_helper.h | 5 -
2 files changed, 37 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_gem_ttm_helper.c
b/drivers/gpu/drm/drm_gem_ttm_helper.c
index de28720757af..b14bed8be771 100644
--- a/drivers/gpu/drm/drm_gem_ttm_helper.c
+++ b/drivers/gpu/drm/drm_gem_ttm_helper.c
@@ -114,5 +114,38 @@ int drm_gem_ttm_mmap(struct drm_gem_object *gem,
}
EXPORT_SYMBOL(drm_gem_ttm_mmap);
+/**
+ * drm_gem_ttm_dumb_map_offset() - Implements struct
&drm_driver.dumb_map_offset
+ * @file: DRM file pointer.
+ * @dev: DRM device.
+ * @handle:GEM handle
+ * @offset:Returns the mapping's memory offset on success
+ *
+ * Provides an implementation of struct &drm_driver.dumb_map_offset for
+ * TTM-based GEM drivers. TTM allocates the offset internally and
+ * drm_gem_ttm_dumb_map_offset() returns it for dumb-buffer implementations.
+ *
+ * See struct &drm_driver.dumb_map_offset.
+ *
+ * Returns:
+ * 0 on success, or a negative errno code otherwise.
+ */
+int drm_gem_ttm_dumb_map_offset(struct drm_file *file, struct drm_device *dev,
+ uint32_t handle, uint64_t *offset)
+{
+ struct drm_gem_object *gem;
+
+ gem = drm_gem_object_lookup(file, handle);
+ if (!gem)
+ return -ENOENT;
+
+ *offset = drm_vma_node_offset_addr(&gem->vma_node);
+
+ drm_gem_object_put(gem);
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_gem_ttm_dumb_map_offset);
+
MODULE_DESCRIPTION("DRM gem ttm helpers");
MODULE_LICENSE("GPL");
diff --git a/include/drm/drm_gem_ttm_helper.h b/include/drm/drm_gem_ttm_helper.h
index 7c6d874910b8..c1aa02bd4c89 100644
--- a/include/drm/drm_gem_ttm_helper.h
+++ b/include/drm/drm_gem_ttm_helper.h
@@ -5,8 +5,8 @@
#include
-#include
#include
+#include
#include
#include
@@ -24,4 +24,7 @@ void drm_gem_ttm_vunmap(struct drm_gem_object *gem,
int drm_gem_ttm_mmap(struct drm_gem_object *gem,
struct vm_area_struct *vma);
+int drm_gem_ttm_dumb_map_offset(struct drm_file *file, struct drm_device *dev,
+ uint32_t handle, uint64_t *offset);
+
#endif
--
2.30.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/4] drm/vram-helper: Use drm_gem_ttm_dumb_map_offset()
VRAM helpers now use drm_gem_ttm_dumb_map_offset() to implement
struct drm_driver.dumb_map_offset.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_gem_vram_helper.c | 48 ---
include/drm/drm_gem_vram_helper.h | 7 ++--
2 files changed, 2 insertions(+), 53 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
b/drivers/gpu/drm/drm_gem_vram_helper.c
index 2b7c3a07956d..797200315854 100644
--- a/drivers/gpu/drm/drm_gem_vram_helper.c
+++ b/drivers/gpu/drm/drm_gem_vram_helper.c
@@ -245,22 +245,6 @@ void drm_gem_vram_put(struct drm_gem_vram_object *gbo)
}
EXPORT_SYMBOL(drm_gem_vram_put);
-/**
- * drm_gem_vram_mmap_offset() - Returns a GEM VRAM object's mmap offset
- * @gbo: the GEM VRAM object
- *
- * See drm_vma_node_offset_addr() for more information.
- *
- * Returns:
- * The buffer object's offset for userspace mappings on success, or
- * 0 if no offset is allocated.
- */
-u64 drm_gem_vram_mmap_offset(struct drm_gem_vram_object *gbo)
-{
- return drm_vma_node_offset_addr(&gbo->bo.base.vma_node);
-}
-EXPORT_SYMBOL(drm_gem_vram_mmap_offset);
-
static u64 drm_gem_vram_pg_offset(struct drm_gem_vram_object *gbo)
{
/* Keep TTM behavior for now, remove when drivers are audited */
@@ -638,38 +622,6 @@ int drm_gem_vram_driver_dumb_create(struct drm_file *file,
}
EXPORT_SYMBOL(drm_gem_vram_driver_dumb_create);
-/**
- * drm_gem_vram_driver_dumb_mmap_offset() - \
- Implements &struct drm_driver.dumb_mmap_offset
- * @file: DRM file pointer.
- * @dev: DRM device.
- * @handle:GEM handle
- * @offset:Returns the mapping's memory offset on success
- *
- * Returns:
- * 0 on success, or
- * a negative errno code otherwise.
- */
-int drm_gem_vram_driver_dumb_mmap_offset(struct drm_file *file,
-struct drm_device *dev,
-uint32_t handle, uint64_t *offset)
-{
- struct drm_gem_object *gem;
- struct drm_gem_vram_object *gbo;
-
- gem = drm_gem_object_lookup(file, handle);
- if (!gem)
- return -ENOENT;
-
- gbo = drm_gem_vram_of_gem(gem);
- *offset = drm_gem_vram_mmap_offset(gbo);
-
- drm_gem_object_put(gem);
-
- return 0;
-}
-EXPORT_SYMBOL(drm_gem_vram_driver_dumb_mmap_offset);
-
/*
* Helpers for struct drm_plane_helper_funcs
*/
diff --git a/include/drm/drm_gem_vram_helper.h
b/include/drm/drm_gem_vram_helper.h
index 288055d397d9..27ed7e9243b9 100644
--- a/include/drm/drm_gem_vram_helper.h
+++ b/include/drm/drm_gem_vram_helper.h
@@ -5,6 +5,7 @@
#include
#include
+#include
#include
#include
#include
@@ -93,7 +94,6 @@ struct drm_gem_vram_object *drm_gem_vram_create(struct
drm_device *dev,
size_t size,
unsigned long pg_align);
void drm_gem_vram_put(struct drm_gem_vram_object *gbo);
-u64 drm_gem_vram_mmap_offset(struct drm_gem_vram_object *gbo);
s64 drm_gem_vram_offset(struct drm_gem_vram_object *gbo);
int drm_gem_vram_pin(struct drm_gem_vram_object *gbo, unsigned long pl_flag);
int drm_gem_vram_unpin(struct drm_gem_vram_object *gbo);
@@ -113,9 +113,6 @@ int drm_gem_vram_fill_create_dumb(struct drm_file *file,
int drm_gem_vram_driver_dumb_create(struct drm_file *file,
struct drm_device *dev,
struct drm_mode_create_dumb *args);
-int drm_gem_vram_driver_dumb_mmap_offset(struct drm_file *file,
-struct drm_device *dev,
-uint32_t handle, uint64_t *offset);
/*
* Helpers for struct drm_plane_helper_funcs
@@ -149,7 +146,7 @@ void drm_gem_vram_simple_display_pipe_cleanup_fb(
#define DRM_GEM_VRAM_DRIVER \
.debugfs_init = drm_vram_mm_debugfs_init, \
.dumb_create = drm_gem_vram_driver_dumb_create, \
- .dumb_map_offset = drm_gem_vram_driver_dumb_mmap_offset, \
+ .dumb_map_offset = drm_gem_ttm_dumb_map_offset, \
.gem_prime_mmap = drm_gem_prime_mmap
/*
--
2.30.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/4] drm: Generic dumb_map_offset for TTM-based drivers
The implementation of drm_driver.dumb_map_offset is the same for several TTM-based drivers. Provide a common function in GEM-TTM helpers. Thomas Zimmermann (4): drm/gem-ttm-helper: Provide helper for struct drm_driver.dumb_map_offset drm/vram-helper: Use drm_gem_ttm_dumb_map_offset() drm/nouveau: Use drm_gem_ttm_dumb_map_offset() drm/qxl: Use drm_gem_ttm_dumb_map_offset() drivers/gpu/drm/drm_gem_ttm_helper.c | 33 drivers/gpu/drm/drm_gem_vram_helper.c | 48 --- drivers/gpu/drm/nouveau/nouveau_display.c | 18 - drivers/gpu/drm/nouveau/nouveau_display.h | 2 - drivers/gpu/drm/nouveau/nouveau_drm.c | 3 +- drivers/gpu/drm/qxl/qxl_drv.c | 3 +- drivers/gpu/drm/qxl/qxl_drv.h | 3 -- drivers/gpu/drm/qxl/qxl_dumb.c| 17 drivers/gpu/drm/qxl/qxl_ioctl.c | 4 +- drivers/gpu/drm/qxl/qxl_object.h | 5 --- include/drm/drm_gem_ttm_helper.h | 5 ++- include/drm/drm_gem_vram_helper.h | 7 +--- 12 files changed, 45 insertions(+), 103 deletions(-) -- 2.30.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/4] drm/qxl: Use drm_gem_ttm_dumb_map_offset()
Qxl now uses drm_gem_ttm_dumb_map_offset() to implement struct
drm_driver.dumb_map_offset.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/qxl/qxl_drv.c| 3 ++-
drivers/gpu/drm/qxl/qxl_drv.h| 3 ---
drivers/gpu/drm/qxl/qxl_dumb.c | 17 -
drivers/gpu/drm/qxl/qxl_ioctl.c | 4 ++--
drivers/gpu/drm/qxl/qxl_object.h | 5 -
5 files changed, 4 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_drv.c b/drivers/gpu/drm/qxl/qxl_drv.c
index 1864467f1063..db92eec07d96 100644
--- a/drivers/gpu/drm/qxl/qxl_drv.c
+++ b/drivers/gpu/drm/qxl/qxl_drv.c
@@ -37,6 +37,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -271,7 +272,7 @@ static struct drm_driver qxl_driver = {
.driver_features = DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC,
.dumb_create = qxl_mode_dumb_create,
- .dumb_map_offset = qxl_mode_dumb_mmap,
+ .dumb_map_offset = drm_gem_ttm_dumb_map_offset,
#if defined(CONFIG_DEBUG_FS)
.debugfs_init = qxl_debugfs_init,
#endif
diff --git a/drivers/gpu/drm/qxl/qxl_drv.h b/drivers/gpu/drm/qxl/qxl_drv.h
index 6dd57cfb2e7c..20a0f3ab84ad 100644
--- a/drivers/gpu/drm/qxl/qxl_drv.h
+++ b/drivers/gpu/drm/qxl/qxl_drv.h
@@ -330,9 +330,6 @@ void qxl_bo_force_delete(struct qxl_device *qdev);
int qxl_mode_dumb_create(struct drm_file *file_priv,
struct drm_device *dev,
struct drm_mode_create_dumb *args);
-int qxl_mode_dumb_mmap(struct drm_file *filp,
- struct drm_device *dev,
- uint32_t handle, uint64_t *offset_p);
/* qxl ttm */
int qxl_ttm_init(struct qxl_device *qdev);
diff --git a/drivers/gpu/drm/qxl/qxl_dumb.c b/drivers/gpu/drm/qxl/qxl_dumb.c
index 48a58ba1db96..a635d9fdf8ac 100644
--- a/drivers/gpu/drm/qxl/qxl_dumb.c
+++ b/drivers/gpu/drm/qxl/qxl_dumb.c
@@ -69,20 +69,3 @@ int qxl_mode_dumb_create(struct drm_file *file_priv,
args->handle = handle;
return 0;
}
-
-int qxl_mode_dumb_mmap(struct drm_file *file_priv,
- struct drm_device *dev,
- uint32_t handle, uint64_t *offset_p)
-{
- struct drm_gem_object *gobj;
- struct qxl_bo *qobj;
-
- BUG_ON(!offset_p);
- gobj = drm_gem_object_lookup(file_priv, handle);
- if (gobj == NULL)
- return -ENOENT;
- qobj = gem_to_qxl_bo(gobj);
- *offset_p = qxl_bo_mmap_offset(qobj);
- drm_gem_object_put(gobj);
- return 0;
-}
diff --git a/drivers/gpu/drm/qxl/qxl_ioctl.c b/drivers/gpu/drm/qxl/qxl_ioctl.c
index b6075f452b9e..38aabcbe2238 100644
--- a/drivers/gpu/drm/qxl/qxl_ioctl.c
+++ b/drivers/gpu/drm/qxl/qxl_ioctl.c
@@ -67,8 +67,8 @@ static int qxl_map_ioctl(struct drm_device *dev, void *data,
struct qxl_device *qdev = to_qxl(dev);
struct drm_qxl_map *qxl_map = data;
- return qxl_mode_dumb_mmap(file_priv, &qdev->ddev, qxl_map->handle,
- &qxl_map->offset);
+ return drm_gem_ttm_dumb_map_offset(file_priv, &qdev->ddev,
qxl_map->handle,
+ &qxl_map->offset);
}
struct qxl_reloc_info {
diff --git a/drivers/gpu/drm/qxl/qxl_object.h b/drivers/gpu/drm/qxl/qxl_object.h
index ee9c29de4d3d..cee4b52b75dd 100644
--- a/drivers/gpu/drm/qxl/qxl_object.h
+++ b/drivers/gpu/drm/qxl/qxl_object.h
@@ -53,11 +53,6 @@ static inline unsigned long qxl_bo_size(struct qxl_bo *bo)
return bo->tbo.base.size;
}
-static inline u64 qxl_bo_mmap_offset(struct qxl_bo *bo)
-{
- return drm_vma_node_offset_addr(&bo->tbo.base.vma_node);
-}
-
extern int qxl_bo_create(struct qxl_device *qdev,
unsigned long size,
bool kernel, bool pinned, u32 domain,
--
2.30.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/4] drm/nouveau: Use drm_gem_ttm_dumb_map_offset()
Nouveau now uses drm_gem_ttm_dumb_map_offset() to implement
struct drm_driver.dumb_map_offset.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/nouveau/nouveau_display.c | 18 --
drivers/gpu/drm/nouveau/nouveau_display.h | 2 --
drivers/gpu/drm/nouveau/nouveau_drm.c | 3 ++-
3 files changed, 2 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c
b/drivers/gpu/drm/nouveau/nouveau_display.c
index dac02c7be54d..14101bd2a0ff 100644
--- a/drivers/gpu/drm/nouveau/nouveau_display.c
+++ b/drivers/gpu/drm/nouveau/nouveau_display.c
@@ -838,21 +838,3 @@ nouveau_display_dumb_create(struct drm_file *file_priv,
struct drm_device *dev,
drm_gem_object_put(&bo->bo.base);
return ret;
}
-
-int
-nouveau_display_dumb_map_offset(struct drm_file *file_priv,
- struct drm_device *dev,
- uint32_t handle, uint64_t *poffset)
-{
- struct drm_gem_object *gem;
-
- gem = drm_gem_object_lookup(file_priv, handle);
- if (gem) {
- struct nouveau_bo *bo = nouveau_gem_object(gem);
- *poffset = drm_vma_node_offset_addr(&bo->bo.base.vma_node);
- drm_gem_object_put(gem);
- return 0;
- }
-
- return -ENOENT;
-}
diff --git a/drivers/gpu/drm/nouveau/nouveau_display.h
b/drivers/gpu/drm/nouveau/nouveau_display.h
index 616c43427059..2ab2ddb1eadf 100644
--- a/drivers/gpu/drm/nouveau/nouveau_display.h
+++ b/drivers/gpu/drm/nouveau/nouveau_display.h
@@ -58,8 +58,6 @@ bool nouveau_display_scanoutpos(struct drm_crtc *crtc,
int nouveau_display_dumb_create(struct drm_file *, struct drm_device *,
struct drm_mode_create_dumb *args);
-int nouveau_display_dumb_map_offset(struct drm_file *, struct drm_device *,
-u32 handle, u64 *offset);
void nouveau_hdmi_mode_set(struct drm_encoder *, struct drm_display_mode *);
diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index 885815ea917f..9766218a99ca 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -31,6 +31,7 @@
#include
#include
+#include
#include
#include
@@ -1212,7 +1213,7 @@ driver_stub = {
.gem_prime_import_sg_table = nouveau_gem_prime_import_sg_table,
.dumb_create = nouveau_display_dumb_create,
- .dumb_map_offset = nouveau_display_dumb_map_offset,
+ .dumb_map_offset = drm_gem_ttm_dumb_map_offset,
.name = DRIVER_NAME,
.desc = DRIVER_DESC,
--
2.30.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH -next] backlight: backlight: Use DEFINE_MUTEX() for mutex lock
On Mon, Apr 05, 2021 at 06:14:40PM +0800, Zheng Yongjun wrote:
> mutex lock can be initialized automatically with DEFINE_MUTEX()
> rather than explicitly calling mutex_init().
>
> Reported-by: Hulk Robot
> Signed-off-by: Zheng Yongjun
This patch looks like a resend of this one (but with a different revision
number):
https://lkml.org/lkml/2020/12/24/229
A resend should always maintain the version number and be clearly marked
as a resend. In this case, there is also a pending review comment that
you have ignored. Given I also clarified when you asked (off-list) for
additional details I'm very surprised to see this patch circulated again
without modification.
I have repeated the feedback below.
> ---
> drivers/video/backlight/backlight.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/video/backlight/backlight.c
> b/drivers/video/backlight/backlight.c
> index 537fe1b376ad..d7a09c422547 100644
> --- a/drivers/video/backlight/backlight.c
> +++ b/drivers/video/backlight/backlight.c
> @@ -64,7 +64,7 @@
> */
>
> static struct list_head backlight_dev_list;
> -static struct mutex backlight_dev_list_mutex;
> +static DEFINE_MUTEX(backlight_dev_list_mutex);
> static struct blocking_notifier_head backlight_notifier;
>
> static const char *const backlight_types[] = {
> @@ -757,7 +757,6 @@ static int __init backlight_class_init(void)
> backlight_class->dev_groups = bl_device_groups;
> backlight_class->pm = &backlight_class_dev_pm_ops;
> INIT_LIST_HEAD(&backlight_dev_list);
> - mutex_init(&backlight_dev_list_mutex);
> BLOCKING_INIT_NOTIFIER_HEAD(&backlight_notifier);
On Mon, 4 Jan 2021 at 14:19, Daniel Thompson wrote:
: the purpose of backlight_dev_list_mutex is (as the name suggests) to
: protect backlight_dev_list. It makes no sense to initialize these
: variables from different places within the code. It just makes it
: harder to reason about the lifetimes of the variables.
:
: To be clear, switching over to static initializers is a good change,
: but please change all three in one patch.
Daniel.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RESEND 00/25] Rid W=1 warnings from HID
On Fri, 26 Mar 2021, Lee Jones wrote: > This set is part of a larger effort attempting to clean-up W=1 > kernel builds, which are currently overwhelmingly riddled with > niggly little warnings. > > Lee Jones (25): > HID: intel-ish-hid: Remove unused variable 'err' > HID: ishtp-hid-client: Move variable to where it's actually used > HID: intel-ish-hid: pci-ish: Remove unused variable 'ret' > HID: intel-ish: Supply some missing param descriptions > HID: intel-ish: Fix a naming disparity and a formatting error > HID: usbhid: Repair a formatting issue in a struct description > HID: intel-ish-hid: Fix a little doc-rot > HID: usbhid: hid-pidff: Demote a couple kernel-doc abuses > HID: hid-alps: Correct struct misnaming > HID: intel-ish-hid: Fix potential copy/paste error > HID: hid-core: Fix incorrect function name in header > HID: intel-ish-hid: ipc: Correct fw_reset_work_fn() function name in > header > HID: ishtp-hid-client: Fix incorrect function name report_bad_packet() > HID: hid-kye: Fix incorrect function name for kye_tablet_enable() > HID: hid-picolcd_core: Remove unused variable 'ret' > HID: hid-logitech-hidpp: Fix conformant kernel-doc header and demote > abuses > HID: hid-uclogic-rdesc: Kernel-doc is for functions and structs > HID: hid-thrustmaster: Demote a bunch of kernel-doc abuses > HID: hid-uclogic-params: Ensure function names are present and correct > in kernel-doc headers > HID: hid-sensor-custom: Remove unused variable 'ret' > HID: wacom_sys: Demote kernel-doc abuse > HID: hid-sensor-hub: Remove unused struct member 'quirks' > HID: hid-sensor-hub: Move 'hsdev' description to correct struct > definition > HID: intel-ish-hid: ishtp-fw-loader: Fix a bunch of formatting issues > HID: ishtp-hid-client: Fix 'suggest-attribute=format' compiler warning These have been on the list for a couple of weeks now. Is there anything I can do to help expedite their merge? I'm concerned since -rc6 has just been released. -- Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 0/1] drm/nouveau/dmem: Remove duplicated header file
v1 --> v2: Arrange all included header files in alphabetical order. Zhen Lei (1): drm/nouveau/dmem: Remove duplicated header file inclusion drivers/gpu/drm/nouveau/nouveau_dmem.c | 27 --- 1 file changed, 12 insertions(+), 15 deletions(-) -- 1.8.3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/1] drm/nouveau/dmem: Remove duplicated header file inclusion
Delete one of the header files that are included twice, all included header files are then rearranged alphabetically. Signed-off-by: Zhen Lei --- drivers/gpu/drm/nouveau/nouveau_dmem.c | 27 --- 1 file changed, 12 insertions(+), 15 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_dmem.c b/drivers/gpu/drm/nouveau/nouveau_dmem.c index 92987daa5e17d02..8e7a1b6598e0659 100644 --- a/drivers/gpu/drm/nouveau/nouveau_dmem.c +++ b/drivers/gpu/drm/nouveau/nouveau_dmem.c @@ -19,26 +19,23 @@ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR * OTHER DEALINGS IN THE SOFTWARE. */ -#include "nouveau_dmem.h" -#include "nouveau_drv.h" -#include "nouveau_chan.h" -#include "nouveau_dma.h" -#include "nouveau_mem.h" -#include "nouveau_bo.h" -#include "nouveau_svm.h" - +#include +#include +#include #include -#include -#include #include #include #include -#include - -#include +#include +#include -#include -#include +#include "nouveau_bo.h" +#include "nouveau_chan.h" +#include "nouveau_dma.h" +#include "nouveau_dmem.h" +#include "nouveau_drv.h" +#include "nouveau_mem.h" +#include "nouveau_svm.h" /* * FIXME: this is ugly right now we are using TTM to allocate vram and we pin -- 1.8.3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/8] drm: Clean up mmap for TTM-based GEM drivers
Implement mmap via struct drm_gem_object_functions.mmap for amdgpu, radeon and nouveau. This allows for using common DRM helpers for the mmap-related callbacks in struct file_operations and struct drm_driver. The drivers have their own vm_ops, which are now set automatically by the DRM core functions. The code in each driver's verify_access becomes part of the driver's new mmap implementation. With the GEM drivers converted, vmwgfx is the only user of ttm_bo_mmap() and related infrastructure. So move everything into vmwgfx and delete the rsp code from TTM. This touches several drivers. Preferably everything would be merged at once via drm-misc-next. Thomas Zimmermann (8): drm/ttm: Don't override vm_ops callbacks, if set drm/amdgpu: Remove unused function amdgpu_bo_fbdev_mmap() drm/amdgpu: Implement mmap as GEM object function drm/radeon: Implement mmap as GEM object function drm/nouveau: Implement mmap as GEM object function drm/vmwgfx: Inline ttm_bo_mmap() into vmwgfx driver drm/vmwgfx: Inline vmw_verify_access() drm/ttm: Remove ttm_bo_mmap() and friends drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 46 - drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.h | 2 - drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 4 +- drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 64 +++ drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 19 -- drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 2 - drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 71 - drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h | 1 - drivers/gpu/drm/nouveau/nouveau_bo.c| 10 --- drivers/gpu/drm/nouveau/nouveau_drm.c | 3 +- drivers/gpu/drm/nouveau/nouveau_gem.c | 36 +++ drivers/gpu/drm/nouveau/nouveau_ttm.c | 49 -- drivers/gpu/drm/nouveau/nouveau_ttm.h | 1 - drivers/gpu/drm/radeon/radeon_drv.c | 3 +- drivers/gpu/drm/radeon/radeon_gem.c | 52 +++ drivers/gpu/drm/radeon/radeon_ttm.c | 65 --- drivers/gpu/drm/radeon/radeon_ttm.h | 1 - drivers/gpu/drm/ttm/ttm_bo_vm.c | 60 ++--- drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 9 --- drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c| 51 ++- include/drm/ttm/ttm_bo_api.h| 13 include/drm/ttm/ttm_device.h| 15 - 22 files changed, 212 insertions(+), 365 deletions(-) -- 2.30.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/8] drm/radeon: Implement mmap as GEM object function
Moving the driver-specific mmap code into a GEM object function allows
for using DRM helpers for various mmap callbacks.
This change also allows to support prime-based mmap via DRM's helper
drm_gem_prime_mmap().
Permission checks are implemented by drm_gem_mmap(), with an additional
check for radeon_ttm_tt_has_userptr() in the GEM object function. The
function radeon_verify_access() is now unused and has thus been removed.
As a side effect, amdgpu_ttm_vm_ops and amdgpu_ttm_fault() are now
implemented in amdgpu's GEM code.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/radeon/radeon_drv.c | 3 +-
drivers/gpu/drm/radeon/radeon_gem.c | 52 +++
drivers/gpu/drm/radeon/radeon_ttm.c | 65 -
drivers/gpu/drm/radeon/radeon_ttm.h | 1 -
4 files changed, 54 insertions(+), 67 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_drv.c
b/drivers/gpu/drm/radeon/radeon_drv.c
index efeb115ae70e..4039b6d71aa2 100644
--- a/drivers/gpu/drm/radeon/radeon_drv.c
+++ b/drivers/gpu/drm/radeon/radeon_drv.c
@@ -557,7 +557,7 @@ static const struct file_operations radeon_driver_kms_fops
= {
.open = drm_open,
.release = drm_release,
.unlocked_ioctl = radeon_drm_ioctl,
- .mmap = radeon_mmap,
+ .mmap = drm_gem_mmap,
.poll = drm_poll,
.read = drm_read,
#ifdef CONFIG_COMPAT
@@ -632,6 +632,7 @@ static const struct drm_driver kms_driver = {
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
.gem_prime_import_sg_table = radeon_gem_prime_import_sg_table,
+ .gem_prime_mmap = drm_gem_prime_mmap,
.name = DRIVER_NAME,
.desc = DRIVER_DESC,
diff --git a/drivers/gpu/drm/radeon/radeon_gem.c
b/drivers/gpu/drm/radeon/radeon_gem.c
index 05ea2f39f626..71e8737bce01 100644
--- a/drivers/gpu/drm/radeon/radeon_gem.c
+++ b/drivers/gpu/drm/radeon/radeon_gem.c
@@ -44,6 +44,42 @@ void radeon_gem_prime_unpin(struct drm_gem_object *obj);
const struct drm_gem_object_funcs radeon_gem_object_funcs;
+static vm_fault_t radeon_ttm_fault(struct vm_fault *vmf)
+{
+ struct ttm_buffer_object *bo = vmf->vma->vm_private_data;
+ struct radeon_device *rdev = radeon_get_rdev(bo->bdev);
+ vm_fault_t ret;
+
+ down_read(&rdev->pm.mclk_lock);
+
+ ret = ttm_bo_vm_reserve(bo, vmf);
+ if (ret)
+ goto unlock_mclk;
+
+ ret = radeon_bo_fault_reserve_notify(bo);
+ if (ret)
+ goto unlock_resv;
+
+ ret = ttm_bo_vm_fault_reserved(vmf, vmf->vma->vm_page_prot,
+ TTM_BO_VM_NUM_PREFAULT, 1);
+ if (ret == VM_FAULT_RETRY && !(vmf->flags & FAULT_FLAG_RETRY_NOWAIT))
+ goto unlock_mclk;
+
+unlock_resv:
+ dma_resv_unlock(bo->base.resv);
+
+unlock_mclk:
+ up_read(&rdev->pm.mclk_lock);
+ return ret;
+}
+
+static const struct vm_operations_struct radeon_ttm_vm_ops = {
+ .fault = radeon_ttm_fault,
+ .open = ttm_bo_vm_open,
+ .close = ttm_bo_vm_close,
+ .access = ttm_bo_vm_access
+};
+
static void radeon_gem_object_free(struct drm_gem_object *gobj)
{
struct radeon_bo *robj = gem_to_radeon_bo(gobj);
@@ -226,6 +262,20 @@ static int radeon_gem_handle_lockup(struct radeon_device
*rdev, int r)
return r;
}
+static int radeon_gem_object_mmap(struct drm_gem_object *obj, struct
vm_area_struct *vma)
+{
+ struct radeon_bo *bo = gem_to_radeon_bo(obj);
+ struct radeon_device *rdev = radeon_get_rdev(bo->tbo.bdev);
+
+ if (!rdev)
+ return -EINVAL;
+
+ if (radeon_ttm_tt_has_userptr(rdev, bo->tbo.ttm))
+ return -EPERM;
+
+ return drm_gem_ttm_mmap(obj, vma);
+}
+
const struct drm_gem_object_funcs radeon_gem_object_funcs = {
.free = radeon_gem_object_free,
.open = radeon_gem_object_open,
@@ -236,6 +286,8 @@ const struct drm_gem_object_funcs radeon_gem_object_funcs =
{
.get_sg_table = radeon_gem_prime_get_sg_table,
.vmap = drm_gem_ttm_vmap,
.vunmap = drm_gem_ttm_vunmap,
+ .mmap = radeon_gem_object_mmap,
+ .vm_ops = &radeon_ttm_vm_ops,
};
/*
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
b/drivers/gpu/drm/radeon/radeon_ttm.c
index 476ce9c24b9f..a5ce43a909a2 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -136,17 +136,6 @@ static void radeon_evict_flags(struct ttm_buffer_object
*bo,
*placement = rbo->placement;
}
-static int radeon_verify_access(struct ttm_buffer_object *bo, struct file
*filp)
-{
- struct radeon_bo *rbo = container_of(bo, struct radeon_bo, tbo);
- struct radeon_device *rdev = radeon_get_rdev(bo->bdev);
-
- if (radeon_ttm_tt_has_userptr(rdev, bo->ttm))
- return -EPERM;
- return drm_vma_node_verify_access(&rbo->tbo.base.vma_node,
- filp->private
[PATCH 2/8] drm/amdgpu: Remove unused function amdgpu_bo_fbdev_mmap()
Remove an unused function. Mapping the fbdev framebuffer is apparently
not supported.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 19 ---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 2 --
2 files changed, 21 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index b99e9d8736c2..cfc89164dee8 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -1092,25 +1092,6 @@ void amdgpu_bo_fini(struct amdgpu_device *adev)
}
}
-/**
- * amdgpu_bo_fbdev_mmap - mmap fbdev memory
- * @bo: &amdgpu_bo buffer object
- * @vma: vma as input from the fbdev mmap method
- *
- * Calls ttm_fbdev_mmap() to mmap fbdev memory if it is backed by a bo.
- *
- * Returns:
- * 0 for success or a negative error code on failure.
- */
-int amdgpu_bo_fbdev_mmap(struct amdgpu_bo *bo,
-struct vm_area_struct *vma)
-{
- if (vma->vm_pgoff != 0)
- return -EACCES;
-
- return ttm_bo_mmap_obj(vma, &bo->tbo);
-}
-
/**
* amdgpu_bo_set_tiling_flags - set tiling flags
* @bo: &amdgpu_bo buffer object
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
index 54ceb065e546..46e94d413c5c 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
@@ -268,8 +268,6 @@ void amdgpu_bo_unpin(struct amdgpu_bo *bo);
int amdgpu_bo_evict_vram(struct amdgpu_device *adev);
int amdgpu_bo_init(struct amdgpu_device *adev);
void amdgpu_bo_fini(struct amdgpu_device *adev);
-int amdgpu_bo_fbdev_mmap(struct amdgpu_bo *bo,
- struct vm_area_struct *vma);
int amdgpu_bo_set_tiling_flags(struct amdgpu_bo *bo, u64 tiling_flags);
void amdgpu_bo_get_tiling_flags(struct amdgpu_bo *bo, u64 *tiling_flags);
int amdgpu_bo_set_metadata (struct amdgpu_bo *bo, void *metadata,
--
2.30.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 6/8] drm/vmwgfx: Inline ttm_bo_mmap() into vmwgfx driver
The vmwgfx driver is the only remaining user of ttm_bo_mmap(). Inline
the code. The internal helper ttm_bo_vm_lookup() is now also part of
vmwgfx as vmw_bo_vm_lookup().
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c | 54 ++--
1 file changed, 51 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c
index cb9975889e2f..3eaad00668f2 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c
@@ -27,6 +27,30 @@
#include "vmwgfx_drv.h"
+static struct ttm_buffer_object *vmw_bo_vm_lookup(struct ttm_device *bdev,
+ unsigned long offset,
+ unsigned long pages)
+{
+ struct drm_vma_offset_node *node;
+ struct ttm_buffer_object *bo = NULL;
+
+ drm_vma_offset_lock_lookup(bdev->vma_manager);
+
+ node = drm_vma_offset_lookup_locked(bdev->vma_manager, offset, pages);
+ if (likely(node)) {
+ bo = container_of(node, struct ttm_buffer_object,
+ base.vma_node);
+ bo = ttm_bo_get_unless_zero(bo);
+ }
+
+ drm_vma_offset_unlock_lookup(bdev->vma_manager);
+
+ if (!bo)
+ pr_err("Could not find buffer object to map\n");
+
+ return bo;
+}
+
int vmw_mmap(struct file *filp, struct vm_area_struct *vma)
{
static const struct vm_operations_struct vmw_vm_ops = {
@@ -41,10 +65,28 @@ int vmw_mmap(struct file *filp, struct vm_area_struct *vma)
};
struct drm_file *file_priv = filp->private_data;
struct vmw_private *dev_priv = vmw_priv(file_priv->minor->dev);
- int ret = ttm_bo_mmap(filp, vma, &dev_priv->bdev);
+ struct ttm_device *bdev = &dev_priv->bdev;
+ struct ttm_buffer_object *bo;
+ int ret;
+
+ if (unlikely(vma->vm_pgoff < DRM_FILE_PAGE_OFFSET_START))
+ return -EINVAL;
+
+ bo = vmw_bo_vm_lookup(bdev, vma->vm_pgoff, vma_pages(vma));
+ if (unlikely(!bo))
+ return -EINVAL;
- if (ret)
- return ret;
+ if (unlikely(!bo->bdev->funcs->verify_access)) {
+ ret = -EPERM;
+ goto out_unref;
+ }
+ ret = bo->bdev->funcs->verify_access(bo, filp);
+ if (unlikely(ret != 0))
+ goto out_unref;
+
+ ret = ttm_bo_mmap_obj(vma, bo);
+ if (unlikely(ret != 0))
+ goto out_unref;
vma->vm_ops = &vmw_vm_ops;
@@ -52,7 +94,13 @@ int vmw_mmap(struct file *filp, struct vm_area_struct *vma)
if (!is_cow_mapping(vma->vm_flags))
vma->vm_flags = (vma->vm_flags & ~VM_MIXEDMAP) | VM_PFNMAP;
+ ttm_bo_put(bo); /* release extra ref taken by ttm_bo_mmap_obj() */
+
return 0;
+
+out_unref:
+ ttm_bo_put(bo);
+ return ret;
}
/* struct vmw_validation_mem callback */
--
2.30.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/8] drm/amdgpu: Implement mmap as GEM object function
Moving the driver-specific mmap code into a GEM object function allows
for using DRM helpers for various mmap callbacks.
This change resolves several inconsistencies between regular mmap and
prime-based mmap. The vm_ops field in vma is now set for all mmap'ed
areas. Previously it way only set for regular mmap calls, prime-based
mmap used TTM's default vm_ops. The check for kfd_bo has been taken
from amdgpu_verify_access(), which is not called any longer and has
been removed.
As a side effect, amdgpu_ttm_vm_ops and amdgpu_ttm_fault() are now
implemented in amdgpu's GEM code.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 46 -
drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.h | 2 -
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 4 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 64 +++
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 71 -
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h | 1 -
6 files changed, 66 insertions(+), 122 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
index e0c4f7c7f1b9..19c5ab08d9ec 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
@@ -42,52 +42,6 @@
#include
#include
-/**
- * amdgpu_gem_prime_mmap - &drm_driver.gem_prime_mmap implementation
- * @obj: GEM BO
- * @vma: Virtual memory area
- *
- * Sets up a userspace mapping of the BO's memory in the given
- * virtual memory area.
- *
- * Returns:
- * 0 on success or a negative error code on failure.
- */
-int amdgpu_gem_prime_mmap(struct drm_gem_object *obj,
- struct vm_area_struct *vma)
-{
- struct amdgpu_bo *bo = gem_to_amdgpu_bo(obj);
- struct amdgpu_device *adev = amdgpu_ttm_adev(bo->tbo.bdev);
- unsigned asize = amdgpu_bo_size(bo);
- int ret;
-
- if (!vma->vm_file)
- return -ENODEV;
-
- if (adev == NULL)
- return -ENODEV;
-
- /* Check for valid size. */
- if (asize < vma->vm_end - vma->vm_start)
- return -EINVAL;
-
- if (amdgpu_ttm_tt_get_usermm(bo->tbo.ttm) ||
- (bo->flags & AMDGPU_GEM_CREATE_NO_CPU_ACCESS)) {
- return -EPERM;
- }
- vma->vm_pgoff += amdgpu_bo_mmap_offset(bo) >> PAGE_SHIFT;
-
- /* prime mmap does not need to check access, so allow here */
- ret = drm_vma_node_allow(&obj->vma_node, vma->vm_file->private_data);
- if (ret)
- return ret;
-
- ret = ttm_bo_mmap(vma->vm_file, vma, &adev->mman.bdev);
- drm_vma_node_revoke(&obj->vma_node, vma->vm_file->private_data);
-
- return ret;
-}
-
static int
__dma_resv_make_exclusive(struct dma_resv *obj)
{
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.h
index 39b5b9616fd8..3e93b9b407a9 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.h
@@ -31,8 +31,6 @@ struct drm_gem_object *amdgpu_gem_prime_import(struct
drm_device *dev,
struct dma_buf *dma_buf);
bool amdgpu_dmabuf_is_xgmi_accessible(struct amdgpu_device *adev,
struct amdgpu_bo *bo);
-int amdgpu_gem_prime_mmap(struct drm_gem_object *obj,
- struct vm_area_struct *vma);
extern const struct dma_buf_ops amdgpu_dmabuf_ops;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 76f48f79c70b..e96d2758f4bb 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -1656,7 +1656,7 @@ static const struct file_operations
amdgpu_driver_kms_fops = {
.flush = amdgpu_flush,
.release = drm_release,
.unlocked_ioctl = amdgpu_drm_ioctl,
- .mmap = amdgpu_mmap,
+ .mmap = drm_gem_mmap,
.poll = drm_poll,
.read = drm_read,
#ifdef CONFIG_COMPAT
@@ -1719,7 +1719,7 @@ static const struct drm_driver amdgpu_kms_driver = {
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
.gem_prime_import = amdgpu_gem_prime_import,
- .gem_prime_mmap = amdgpu_gem_prime_mmap,
+ .gem_prime_mmap = drm_gem_prime_mmap,
.name = DRIVER_NAME,
.desc = DRIVER_DESC,
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
index fb7171e5507c..fe93faad05f2 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
@@ -41,6 +41,36 @@
static const struct drm_gem_object_funcs amdgpu_gem_object_funcs;
+static vm_fault_t amdgpu_ttm_fault(struct vm_fault *vmf)
+{
+ struct ttm_buffer_object *bo = vmf->vma->vm_private_data;
+ vm_fault_t ret;
+
+ ret = ttm_bo_vm_reserve(bo, vmf);
+ if (ret)
+ r
[PATCH 1/8] drm/ttm: Don't override vm_ops callbacks, if set
Drivers may want to set their own callbacks for a VM area. Only set
TTM's callbacks if the vm_ops field is clear.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/ttm/ttm_bo_vm.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
index b31b18058965..bf4a213bc66c 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
@@ -534,7 +534,12 @@ static struct ttm_buffer_object *ttm_bo_vm_lookup(struct
ttm_device *bdev,
static void ttm_bo_mmap_vma_setup(struct ttm_buffer_object *bo, struct
vm_area_struct *vma)
{
- vma->vm_ops = &ttm_bo_vm_ops;
+ /*
+* Drivers may want to override the vm_ops field. Otherwise we
+* use TTM's default callbacks.
+*/
+ if (!vma->vm_ops)
+ vma->vm_ops = &ttm_bo_vm_ops;
/*
* Note: We're transferring the bo reference to
--
2.30.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 8/8] drm/ttm: Remove ttm_bo_mmap() and friends
The function ttm_bo_mmap is unused. Remove it and it's helpers; including
the verify_access callback in struct ttm_device_funcs.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/ttm/ttm_bo_vm.c | 53 -
include/drm/ttm/ttm_bo_api.h| 13
include/drm/ttm/ttm_device.h| 15 --
3 files changed, 81 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
index bf4a213bc66c..6cd352399941 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
@@ -508,30 +508,6 @@ static const struct vm_operations_struct ttm_bo_vm_ops = {
.access = ttm_bo_vm_access,
};
-static struct ttm_buffer_object *ttm_bo_vm_lookup(struct ttm_device *bdev,
- unsigned long offset,
- unsigned long pages)
-{
- struct drm_vma_offset_node *node;
- struct ttm_buffer_object *bo = NULL;
-
- drm_vma_offset_lock_lookup(bdev->vma_manager);
-
- node = drm_vma_offset_lookup_locked(bdev->vma_manager, offset, pages);
- if (likely(node)) {
- bo = container_of(node, struct ttm_buffer_object,
- base.vma_node);
- bo = ttm_bo_get_unless_zero(bo);
- }
-
- drm_vma_offset_unlock_lookup(bdev->vma_manager);
-
- if (!bo)
- pr_err("Could not find buffer object to map\n");
-
- return bo;
-}
-
static void ttm_bo_mmap_vma_setup(struct ttm_buffer_object *bo, struct
vm_area_struct *vma)
{
/*
@@ -559,35 +535,6 @@ static void ttm_bo_mmap_vma_setup(struct ttm_buffer_object
*bo, struct vm_area_s
vma->vm_flags |= VM_IO | VM_DONTEXPAND | VM_DONTDUMP;
}
-int ttm_bo_mmap(struct file *filp, struct vm_area_struct *vma,
- struct ttm_device *bdev)
-{
- struct ttm_buffer_object *bo;
- int ret;
-
- if (unlikely(vma->vm_pgoff < DRM_FILE_PAGE_OFFSET_START))
- return -EINVAL;
-
- bo = ttm_bo_vm_lookup(bdev, vma->vm_pgoff, vma_pages(vma));
- if (unlikely(!bo))
- return -EINVAL;
-
- if (unlikely(!bo->bdev->funcs->verify_access)) {
- ret = -EPERM;
- goto out_unref;
- }
- ret = bo->bdev->funcs->verify_access(bo, filp);
- if (unlikely(ret != 0))
- goto out_unref;
-
- ttm_bo_mmap_vma_setup(bo, vma);
- return 0;
-out_unref:
- ttm_bo_put(bo);
- return ret;
-}
-EXPORT_SYMBOL(ttm_bo_mmap);
-
int ttm_bo_mmap_obj(struct vm_area_struct *vma, struct ttm_buffer_object *bo)
{
ttm_bo_get(bo);
diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h
index 2155e2e38aec..6e35680ac01b 100644
--- a/include/drm/ttm/ttm_bo_api.h
+++ b/include/drm/ttm/ttm_bo_api.h
@@ -522,19 +522,6 @@ void ttm_bo_vunmap(struct ttm_buffer_object *bo, struct
dma_buf_map *map);
*/
int ttm_bo_mmap_obj(struct vm_area_struct *vma, struct ttm_buffer_object *bo);
-/**
- * ttm_bo_mmap - mmap out of the ttm device address space.
- *
- * @filp: filp as input from the mmap method.
- * @vma: vma as input from the mmap method.
- * @bdev: Pointer to the ttm_device with the address space manager.
- *
- * This function is intended to be called by the device mmap method.
- * if the device address space is to be backed by the bo manager.
- */
-int ttm_bo_mmap(struct file *filp, struct vm_area_struct *vma,
- struct ttm_device *bdev);
-
/**
* ttm_bo_io
*
diff --git a/include/drm/ttm/ttm_device.h b/include/drm/ttm/ttm_device.h
index 7c8f87bd52d3..cd592f8e941b 100644
--- a/include/drm/ttm/ttm_device.h
+++ b/include/drm/ttm/ttm_device.h
@@ -161,21 +161,6 @@ struct ttm_device_funcs {
struct ttm_resource *new_mem,
struct ttm_place *hop);
- /**
-* struct ttm_bo_driver_member verify_access
-*
-* @bo: Pointer to a buffer object.
-* @filp: Pointer to a struct file trying to access the object.
-*
-* Called from the map / write / read methods to verify that the
-* caller is permitted to access the buffer object.
-* This member may be set to NULL, which will refuse this kind of
-* access for all buffer objects.
-* This function should return 0 if access is granted, -EPERM otherwise.
-*/
- int (*verify_access)(struct ttm_buffer_object *bo,
-struct file *filp);
-
/**
* Hook to notify driver about a resource delete.
*/
--
2.30.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 7/8] drm/vmwgfx: Inline vmw_verify_access()
Vmwgfx is the only user of the TTM's verify_access callback. Inline
the call and avoid the indirection through the function pointer.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 9 -
drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c | 7 ++-
2 files changed, 2 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
index 2dc031fe4a90..a079734f9d68 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
@@ -658,14 +658,6 @@ static void vmw_evict_flags(struct ttm_buffer_object *bo,
*placement = vmw_sys_placement;
}
-static int vmw_verify_access(struct ttm_buffer_object *bo, struct file *filp)
-{
- struct ttm_object_file *tfile =
- vmw_fpriv((struct drm_file *)filp->private_data)->tfile;
-
- return vmw_user_bo_verify_access(bo, tfile);
-}
-
static int vmw_ttm_io_mem_reserve(struct ttm_device *bdev, struct ttm_resource
*mem)
{
struct vmw_private *dev_priv = container_of(bdev, struct vmw_private,
bdev);
@@ -768,7 +760,6 @@ struct ttm_device_funcs vmw_bo_driver = {
.eviction_valuable = ttm_bo_eviction_valuable,
.evict_flags = vmw_evict_flags,
.move = vmw_move,
- .verify_access = vmw_verify_access,
.swap_notify = vmw_swap_notify,
.io_mem_reserve = &vmw_ttm_io_mem_reserve,
};
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c
index 3eaad00668f2..2574d4707407 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c
@@ -65,6 +65,7 @@ int vmw_mmap(struct file *filp, struct vm_area_struct *vma)
};
struct drm_file *file_priv = filp->private_data;
struct vmw_private *dev_priv = vmw_priv(file_priv->minor->dev);
+ struct ttm_object_file *tfile = vmw_fpriv(file_priv)->tfile;
struct ttm_device *bdev = &dev_priv->bdev;
struct ttm_buffer_object *bo;
int ret;
@@ -76,11 +77,7 @@ int vmw_mmap(struct file *filp, struct vm_area_struct *vma)
if (unlikely(!bo))
return -EINVAL;
- if (unlikely(!bo->bdev->funcs->verify_access)) {
- ret = -EPERM;
- goto out_unref;
- }
- ret = bo->bdev->funcs->verify_access(bo, filp);
+ ret = vmw_user_bo_verify_access(bo, tfile);
if (unlikely(ret != 0))
goto out_unref;
--
2.30.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/8] drm/nouveau: Implement mmap as GEM object function
Moving the driver-specific mmap code into a GEM object function allows
for using DRM helpers for various mmap callbacks.
The GEM object function is provided by GEM TTM helpers. Nouveau's
implementation of verify_access is unused and has been removed. Access
permissions are validated by the DRM helpers.
As a side effect, nouveau_ttm_vm_ops and nouveau_ttm_fault() are now
implemented in nouveau's GEM code.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 10 --
drivers/gpu/drm/nouveau/nouveau_drm.c | 3 +-
drivers/gpu/drm/nouveau/nouveau_gem.c | 36
drivers/gpu/drm/nouveau/nouveau_ttm.c | 49 ---
drivers/gpu/drm/nouveau/nouveau_ttm.h | 1 -
5 files changed, 38 insertions(+), 61 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 3e09df0472ce..bc67cbccc83b 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -1051,15 +1051,6 @@ nouveau_bo_move(struct ttm_buffer_object *bo, bool evict,
return ret;
}
-static int
-nouveau_bo_verify_access(struct ttm_buffer_object *bo, struct file *filp)
-{
- struct nouveau_bo *nvbo = nouveau_bo(bo);
-
- return drm_vma_node_verify_access(&nvbo->bo.base.vma_node,
- filp->private_data);
-}
-
static void
nouveau_ttm_io_mem_free_locked(struct nouveau_drm *drm,
struct ttm_resource *reg)
@@ -1332,7 +1323,6 @@ struct ttm_device_funcs nouveau_bo_driver = {
.evict_flags = nouveau_bo_evict_flags,
.delete_mem_notify = nouveau_bo_delete_mem_notify,
.move = nouveau_bo_move,
- .verify_access = nouveau_bo_verify_access,
.io_mem_reserve = &nouveau_ttm_io_mem_reserve,
.io_mem_free = &nouveau_ttm_io_mem_free,
};
diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index 885815ea917f..7586328c1de5 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -1177,7 +1177,7 @@ nouveau_driver_fops = {
.open = drm_open,
.release = drm_release,
.unlocked_ioctl = nouveau_drm_ioctl,
- .mmap = nouveau_ttm_mmap,
+ .mmap = drm_gem_mmap,
.poll = drm_poll,
.read = drm_read,
#if defined(CONFIG_COMPAT)
@@ -1210,6 +1210,7 @@ driver_stub = {
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
.gem_prime_import_sg_table = nouveau_gem_prime_import_sg_table,
+ .gem_prime_mmap = drm_gem_prime_mmap,
.dumb_create = nouveau_display_dumb_create,
.dumb_map_offset = nouveau_display_dumb_map_offset,
diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c
b/drivers/gpu/drm/nouveau/nouveau_gem.c
index c88cbb85f101..71dfac820c4d 100644
--- a/drivers/gpu/drm/nouveau/nouveau_gem.c
+++ b/drivers/gpu/drm/nouveau/nouveau_gem.c
@@ -39,6 +39,40 @@
#include
#include
+static vm_fault_t nouveau_ttm_fault(struct vm_fault *vmf)
+{
+ struct vm_area_struct *vma = vmf->vma;
+ struct ttm_buffer_object *bo = vma->vm_private_data;
+ pgprot_t prot;
+ vm_fault_t ret;
+
+ ret = ttm_bo_vm_reserve(bo, vmf);
+ if (ret)
+ return ret;
+
+ ret = nouveau_ttm_fault_reserve_notify(bo);
+ if (ret)
+ goto error_unlock;
+
+ nouveau_bo_del_io_reserve_lru(bo);
+ prot = vm_get_page_prot(vma->vm_flags);
+ ret = ttm_bo_vm_fault_reserved(vmf, prot, TTM_BO_VM_NUM_PREFAULT, 1);
+ nouveau_bo_add_io_reserve_lru(bo);
+ if (ret == VM_FAULT_RETRY && !(vmf->flags & FAULT_FLAG_RETRY_NOWAIT))
+ return ret;
+
+error_unlock:
+ dma_resv_unlock(bo->base.resv);
+ return ret;
+}
+
+static const struct vm_operations_struct nouveau_ttm_vm_ops = {
+ .fault = nouveau_ttm_fault,
+ .open = ttm_bo_vm_open,
+ .close = ttm_bo_vm_close,
+ .access = ttm_bo_vm_access
+};
+
void
nouveau_gem_object_del(struct drm_gem_object *gem)
{
@@ -180,6 +214,8 @@ const struct drm_gem_object_funcs nouveau_gem_object_funcs
= {
.get_sg_table = nouveau_gem_prime_get_sg_table,
.vmap = drm_gem_ttm_vmap,
.vunmap = drm_gem_ttm_vunmap,
+ .mmap = drm_gem_ttm_mmap,
+ .vm_ops = &nouveau_ttm_vm_ops,
};
int
diff --git a/drivers/gpu/drm/nouveau/nouveau_ttm.c
b/drivers/gpu/drm/nouveau/nouveau_ttm.c
index b81ae90b8449..e511a26379da 100644
--- a/drivers/gpu/drm/nouveau/nouveau_ttm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_ttm.c
@@ -127,55 +127,6 @@ const struct ttm_resource_manager_func nv04_gart_manager =
{
.free = nouveau_manager_del,
};
-static vm_fault_t nouveau_ttm_fault(struct vm_fault *vmf)
-{
- struct vm_area_struct *vma = vmf->vma;
- struct ttm_buffer_object *bo = vma->vm_private_data;
- pgprot_t prot;
- vm_fault_t ret;
-
- ret = ttm_
Re: [PATCH] pwm: Rename pwm_get_state() to better reflect its semantic
On Tue, 06 Apr 2021, Uwe Kleine-König wrote: > Given that lowlevel drivers usually cannot implement exactly what a > consumer requests with pwm_apply_state() there is some rounding involved. > > pwm_get_state() traditionally returned the setting that was requested most > recently by the consumer (opposed to what was actually implemented in > hardware in reply to the last request). To make this semantic obvious > rename the function. > > Signed-off-by: Uwe Kleine-König > --- > drivers/gpu/drm/i915/display/intel_panel.c | 4 +-- Acked-by: Jani Nikula -- Jani Nikula, Intel Open Source Graphics Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/8] drm/amdgpu: Implement mmap as GEM object function
Am 06.04.21 um 11:08 schrieb Thomas Zimmermann:
Moving the driver-specific mmap code into a GEM object function allows
for using DRM helpers for various mmap callbacks.
This change resolves several inconsistencies between regular mmap and
prime-based mmap. The vm_ops field in vma is now set for all mmap'ed
areas. Previously it way only set for regular mmap calls, prime-based
mmap used TTM's default vm_ops. The check for kfd_bo has been taken
from amdgpu_verify_access(), which is not called any longer and has
been removed.
As a side effect, amdgpu_ttm_vm_ops and amdgpu_ttm_fault() are now
implemented in amdgpu's GEM code.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 46 -
drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.h | 2 -
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 4 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 64 +++
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 71 -
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h | 1 -
6 files changed, 66 insertions(+), 122 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
index e0c4f7c7f1b9..19c5ab08d9ec 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
@@ -42,52 +42,6 @@
#include
#include
-/**
- * amdgpu_gem_prime_mmap - &drm_driver.gem_prime_mmap implementation
- * @obj: GEM BO
- * @vma: Virtual memory area
- *
- * Sets up a userspace mapping of the BO's memory in the given
- * virtual memory area.
- *
- * Returns:
- * 0 on success or a negative error code on failure.
- */
-int amdgpu_gem_prime_mmap(struct drm_gem_object *obj,
- struct vm_area_struct *vma)
-{
- struct amdgpu_bo *bo = gem_to_amdgpu_bo(obj);
- struct amdgpu_device *adev = amdgpu_ttm_adev(bo->tbo.bdev);
- unsigned asize = amdgpu_bo_size(bo);
- int ret;
-
- if (!vma->vm_file)
- return -ENODEV;
-
- if (adev == NULL)
- return -ENODEV;
-
- /* Check for valid size. */
- if (asize < vma->vm_end - vma->vm_start)
- return -EINVAL;
-
- if (amdgpu_ttm_tt_get_usermm(bo->tbo.ttm) ||
- (bo->flags & AMDGPU_GEM_CREATE_NO_CPU_ACCESS)) {
- return -EPERM;
- }
- vma->vm_pgoff += amdgpu_bo_mmap_offset(bo) >> PAGE_SHIFT;
-
- /* prime mmap does not need to check access, so allow here */
- ret = drm_vma_node_allow(&obj->vma_node, vma->vm_file->private_data);
- if (ret)
- return ret;
-
- ret = ttm_bo_mmap(vma->vm_file, vma, &adev->mman.bdev);
- drm_vma_node_revoke(&obj->vma_node, vma->vm_file->private_data);
-
- return ret;
-}
-
static int
__dma_resv_make_exclusive(struct dma_resv *obj)
{
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.h
index 39b5b9616fd8..3e93b9b407a9 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.h
@@ -31,8 +31,6 @@ struct drm_gem_object *amdgpu_gem_prime_import(struct
drm_device *dev,
struct dma_buf *dma_buf);
bool amdgpu_dmabuf_is_xgmi_accessible(struct amdgpu_device *adev,
struct amdgpu_bo *bo);
-int amdgpu_gem_prime_mmap(struct drm_gem_object *obj,
- struct vm_area_struct *vma);
extern const struct dma_buf_ops amdgpu_dmabuf_ops;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 76f48f79c70b..e96d2758f4bb 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -1656,7 +1656,7 @@ static const struct file_operations
amdgpu_driver_kms_fops = {
.flush = amdgpu_flush,
.release = drm_release,
.unlocked_ioctl = amdgpu_drm_ioctl,
- .mmap = amdgpu_mmap,
+ .mmap = drm_gem_mmap,
.poll = drm_poll,
.read = drm_read,
#ifdef CONFIG_COMPAT
@@ -1719,7 +1719,7 @@ static const struct drm_driver amdgpu_kms_driver = {
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
.gem_prime_import = amdgpu_gem_prime_import,
- .gem_prime_mmap = amdgpu_gem_prime_mmap,
+ .gem_prime_mmap = drm_gem_prime_mmap,
.name = DRIVER_NAME,
.desc = DRIVER_DESC,
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
index fb7171e5507c..fe93faad05f2 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
@@ -41,6 +41,36 @@
static const struct drm_gem_object_funcs amdgpu_gem_object_funcs;
+static vm_fault_t amdgpu_ttm_fault(struct vm_fault *vmf)
Please name that function amdgpu_gem_fault or amdgpu_gem_object_fault
+{
+ struct ttm_buffer
[PATCH v1] drm/bridge/sii8620: fix dependency on extcon
The DRM_SIL_SII8620 kconfig has a weak `imply` dependency on EXTCON, which causes issues when sii8620 is built as a builtin and EXTCON is built as a module. Th symptoms are 'undefined reference' errors caused by the symbols in EXTCON not being available to the sii8620 driver. Signed-off-by: Robert Foss Reported-by: kernel test robot --- LKP reported issue: https://lore.kernel.org/lkml/202104040604.sste2cxf-...@intel.com/ drivers/gpu/drm/bridge/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig index 7c15fc170510..204c38e87849 100644 --- a/drivers/gpu/drm/bridge/Kconfig +++ b/drivers/gpu/drm/bridge/Kconfig @@ -169,7 +169,7 @@ config DRM_SIL_SII8620 tristate "Silicon Image SII8620 HDMI/MHL bridge" depends on OF select DRM_KMS_HELPER - imply EXTCON + depends on EXTCON || !EXTCON # if EXTCON=m, this cannot be built-in depends on RC_CORE || !RC_CORE help Silicon Image SII8620 HDMI/MHL bridge chip driver. -- 2.31.0.30.g398dba342d.dirty ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/8] drm/radeon: Implement mmap as GEM object function
Am 06.04.21 um 11:08 schrieb Thomas Zimmermann:
Moving the driver-specific mmap code into a GEM object function allows
for using DRM helpers for various mmap callbacks.
This change also allows to support prime-based mmap via DRM's helper
drm_gem_prime_mmap().
Permission checks are implemented by drm_gem_mmap(), with an additional
check for radeon_ttm_tt_has_userptr() in the GEM object function. The
function radeon_verify_access() is now unused and has thus been removed.
As a side effect, amdgpu_ttm_vm_ops and amdgpu_ttm_fault() are now
implemented in amdgpu's GEM code.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/radeon/radeon_drv.c | 3 +-
drivers/gpu/drm/radeon/radeon_gem.c | 52 +++
drivers/gpu/drm/radeon/radeon_ttm.c | 65 -
drivers/gpu/drm/radeon/radeon_ttm.h | 1 -
4 files changed, 54 insertions(+), 67 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_drv.c
b/drivers/gpu/drm/radeon/radeon_drv.c
index efeb115ae70e..4039b6d71aa2 100644
--- a/drivers/gpu/drm/radeon/radeon_drv.c
+++ b/drivers/gpu/drm/radeon/radeon_drv.c
@@ -557,7 +557,7 @@ static const struct file_operations radeon_driver_kms_fops
= {
.open = drm_open,
.release = drm_release,
.unlocked_ioctl = radeon_drm_ioctl,
- .mmap = radeon_mmap,
+ .mmap = drm_gem_mmap,
.poll = drm_poll,
.read = drm_read,
#ifdef CONFIG_COMPAT
@@ -632,6 +632,7 @@ static const struct drm_driver kms_driver = {
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
.gem_prime_import_sg_table = radeon_gem_prime_import_sg_table,
+ .gem_prime_mmap = drm_gem_prime_mmap,
.name = DRIVER_NAME,
.desc = DRIVER_DESC,
diff --git a/drivers/gpu/drm/radeon/radeon_gem.c
b/drivers/gpu/drm/radeon/radeon_gem.c
index 05ea2f39f626..71e8737bce01 100644
--- a/drivers/gpu/drm/radeon/radeon_gem.c
+++ b/drivers/gpu/drm/radeon/radeon_gem.c
@@ -44,6 +44,42 @@ void radeon_gem_prime_unpin(struct drm_gem_object *obj);
const struct drm_gem_object_funcs radeon_gem_object_funcs;
+static vm_fault_t radeon_ttm_fault(struct vm_fault *vmf)
Please name this radeon_gem_fault or radeon_gem_object_fault.
Apart from that looks good to me.
Christian.
+{
+ struct ttm_buffer_object *bo = vmf->vma->vm_private_data;
+ struct radeon_device *rdev = radeon_get_rdev(bo->bdev);
+ vm_fault_t ret;
+
+ down_read(&rdev->pm.mclk_lock);
+
+ ret = ttm_bo_vm_reserve(bo, vmf);
+ if (ret)
+ goto unlock_mclk;
+
+ ret = radeon_bo_fault_reserve_notify(bo);
+ if (ret)
+ goto unlock_resv;
+
+ ret = ttm_bo_vm_fault_reserved(vmf, vmf->vma->vm_page_prot,
+ TTM_BO_VM_NUM_PREFAULT, 1);
+ if (ret == VM_FAULT_RETRY && !(vmf->flags & FAULT_FLAG_RETRY_NOWAIT))
+ goto unlock_mclk;
+
+unlock_resv:
+ dma_resv_unlock(bo->base.resv);
+
+unlock_mclk:
+ up_read(&rdev->pm.mclk_lock);
+ return ret;
+}
+
+static const struct vm_operations_struct radeon_ttm_vm_ops = {
+ .fault = radeon_ttm_fault,
+ .open = ttm_bo_vm_open,
+ .close = ttm_bo_vm_close,
+ .access = ttm_bo_vm_access
+};
+
static void radeon_gem_object_free(struct drm_gem_object *gobj)
{
struct radeon_bo *robj = gem_to_radeon_bo(gobj);
@@ -226,6 +262,20 @@ static int radeon_gem_handle_lockup(struct radeon_device
*rdev, int r)
return r;
}
+static int radeon_gem_object_mmap(struct drm_gem_object *obj, struct vm_area_struct *vma)
+{
+ struct radeon_bo *bo = gem_to_radeon_bo(obj);
+ struct radeon_device *rdev = radeon_get_rdev(bo->tbo.bdev);
+
+ if (!rdev)
+ return -EINVAL;
+
+ if (radeon_ttm_tt_has_userptr(rdev, bo->tbo.ttm))
+ return -EPERM;
+
+ return drm_gem_ttm_mmap(obj, vma);
+}
+
const struct drm_gem_object_funcs radeon_gem_object_funcs = {
.free = radeon_gem_object_free,
.open = radeon_gem_object_open,
@@ -236,6 +286,8 @@ const struct drm_gem_object_funcs radeon_gem_object_funcs =
{
.get_sg_table = radeon_gem_prime_get_sg_table,
.vmap = drm_gem_ttm_vmap,
.vunmap = drm_gem_ttm_vunmap,
+ .mmap = radeon_gem_object_mmap,
+ .vm_ops = &radeon_ttm_vm_ops,
};
/*
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
b/drivers/gpu/drm/radeon/radeon_ttm.c
index 476ce9c24b9f..a5ce43a909a2 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -136,17 +136,6 @@ static void radeon_evict_flags(struct ttm_buffer_object
*bo,
*placement = rbo->placement;
}
-static int radeon_verify_access(struct ttm_buffer_object *bo, struct file *filp)
-{
- struct radeon_bo *rbo = container_of(bo, struct radeon_bo, tbo);
- struct radeon_device *rdev = radeon_get_rdev(bo->bdev);
-
- if (radeon_ttm_tt_h
Re: [PATCH 8/8] drm/ttm: Remove ttm_bo_mmap() and friends
Am 06.04.21 um 11:09 schrieb Thomas Zimmermann:
The function ttm_bo_mmap is unused. Remove it and it's helpers; including
the verify_access callback in struct ttm_device_funcs.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo_vm.c | 53 -
include/drm/ttm/ttm_bo_api.h| 13
include/drm/ttm/ttm_device.h| 15 --
3 files changed, 81 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
index bf4a213bc66c..6cd352399941 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
@@ -508,30 +508,6 @@ static const struct vm_operations_struct ttm_bo_vm_ops = {
.access = ttm_bo_vm_access,
};
-static struct ttm_buffer_object *ttm_bo_vm_lookup(struct ttm_device *bdev,
- unsigned long offset,
- unsigned long pages)
-{
- struct drm_vma_offset_node *node;
- struct ttm_buffer_object *bo = NULL;
-
- drm_vma_offset_lock_lookup(bdev->vma_manager);
-
- node = drm_vma_offset_lookup_locked(bdev->vma_manager, offset, pages);
- if (likely(node)) {
- bo = container_of(node, struct ttm_buffer_object,
- base.vma_node);
- bo = ttm_bo_get_unless_zero(bo);
- }
-
- drm_vma_offset_unlock_lookup(bdev->vma_manager);
-
- if (!bo)
- pr_err("Could not find buffer object to map\n");
-
- return bo;
-}
-
static void ttm_bo_mmap_vma_setup(struct ttm_buffer_object *bo, struct
vm_area_struct *vma)
{
/*
@@ -559,35 +535,6 @@ static void ttm_bo_mmap_vma_setup(struct ttm_buffer_object
*bo, struct vm_area_s
vma->vm_flags |= VM_IO | VM_DONTEXPAND | VM_DONTDUMP;
}
-int ttm_bo_mmap(struct file *filp, struct vm_area_struct *vma,
- struct ttm_device *bdev)
-{
- struct ttm_buffer_object *bo;
- int ret;
-
- if (unlikely(vma->vm_pgoff < DRM_FILE_PAGE_OFFSET_START))
- return -EINVAL;
-
- bo = ttm_bo_vm_lookup(bdev, vma->vm_pgoff, vma_pages(vma));
- if (unlikely(!bo))
- return -EINVAL;
-
- if (unlikely(!bo->bdev->funcs->verify_access)) {
- ret = -EPERM;
- goto out_unref;
- }
- ret = bo->bdev->funcs->verify_access(bo, filp);
- if (unlikely(ret != 0))
- goto out_unref;
-
- ttm_bo_mmap_vma_setup(bo, vma);
- return 0;
-out_unref:
- ttm_bo_put(bo);
- return ret;
-}
-EXPORT_SYMBOL(ttm_bo_mmap);
-
int ttm_bo_mmap_obj(struct vm_area_struct *vma, struct ttm_buffer_object *bo)
{
ttm_bo_get(bo);
diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h
index 2155e2e38aec..6e35680ac01b 100644
--- a/include/drm/ttm/ttm_bo_api.h
+++ b/include/drm/ttm/ttm_bo_api.h
@@ -522,19 +522,6 @@ void ttm_bo_vunmap(struct ttm_buffer_object *bo, struct
dma_buf_map *map);
*/
int ttm_bo_mmap_obj(struct vm_area_struct *vma, struct ttm_buffer_object *bo);
-/**
- * ttm_bo_mmap - mmap out of the ttm device address space.
- *
- * @filp: filp as input from the mmap method.
- * @vma: vma as input from the mmap method.
- * @bdev: Pointer to the ttm_device with the address space manager.
- *
- * This function is intended to be called by the device mmap method.
- * if the device address space is to be backed by the bo manager.
- */
-int ttm_bo_mmap(struct file *filp, struct vm_area_struct *vma,
- struct ttm_device *bdev);
-
/**
* ttm_bo_io
*
diff --git a/include/drm/ttm/ttm_device.h b/include/drm/ttm/ttm_device.h
index 7c8f87bd52d3..cd592f8e941b 100644
--- a/include/drm/ttm/ttm_device.h
+++ b/include/drm/ttm/ttm_device.h
@@ -161,21 +161,6 @@ struct ttm_device_funcs {
struct ttm_resource *new_mem,
struct ttm_place *hop);
- /**
-* struct ttm_bo_driver_member verify_access
-*
-* @bo: Pointer to a buffer object.
-* @filp: Pointer to a struct file trying to access the object.
-*
-* Called from the map / write / read methods to verify that the
-* caller is permitted to access the buffer object.
-* This member may be set to NULL, which will refuse this kind of
-* access for all buffer objects.
-* This function should return 0 if access is granted, -EPERM otherwise.
-*/
- int (*verify_access)(struct ttm_buffer_object *bo,
-struct file *filp);
-
/**
* Hook to notify driver about a resource delete.
*/
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/8] drm/amdgpu: Remove unused function amdgpu_bo_fbdev_mmap()
Am 06.04.21 um 11:08 schrieb Thomas Zimmermann:
Remove an unused function. Mapping the fbdev framebuffer is apparently
not supported.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Christian König
Should I just upstream this through our internal branches?
Thanks,
Christian.
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 19 ---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 2 --
2 files changed, 21 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index b99e9d8736c2..cfc89164dee8 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -1092,25 +1092,6 @@ void amdgpu_bo_fini(struct amdgpu_device *adev)
}
}
-/**
- * amdgpu_bo_fbdev_mmap - mmap fbdev memory
- * @bo: &amdgpu_bo buffer object
- * @vma: vma as input from the fbdev mmap method
- *
- * Calls ttm_fbdev_mmap() to mmap fbdev memory if it is backed by a bo.
- *
- * Returns:
- * 0 for success or a negative error code on failure.
- */
-int amdgpu_bo_fbdev_mmap(struct amdgpu_bo *bo,
-struct vm_area_struct *vma)
-{
- if (vma->vm_pgoff != 0)
- return -EACCES;
-
- return ttm_bo_mmap_obj(vma, &bo->tbo);
-}
-
/**
* amdgpu_bo_set_tiling_flags - set tiling flags
* @bo: &amdgpu_bo buffer object
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
index 54ceb065e546..46e94d413c5c 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
@@ -268,8 +268,6 @@ void amdgpu_bo_unpin(struct amdgpu_bo *bo);
int amdgpu_bo_evict_vram(struct amdgpu_device *adev);
int amdgpu_bo_init(struct amdgpu_device *adev);
void amdgpu_bo_fini(struct amdgpu_device *adev);
-int amdgpu_bo_fbdev_mmap(struct amdgpu_bo *bo,
- struct vm_area_struct *vma);
int amdgpu_bo_set_tiling_flags(struct amdgpu_bo *bo, u64 tiling_flags);
void amdgpu_bo_get_tiling_flags(struct amdgpu_bo *bo, u64 *tiling_flags);
int amdgpu_bo_set_metadata (struct amdgpu_bo *bo, void *metadata,
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: bridge: rename the function drm_bridge_hpd_notify to drm_bridge_hpd_cb
Reviewed-by: Robert Foss
On Tue, 30 Mar 2021 at 14:28, Robert Foss wrote:
>
> Hey Dafna,
>
> Thanks for submitting a cleanup patch, it is much appreciated. It
> looks good to me, feel free to add my r-b.
>
> I'm not going to merge this right away, but will let this patch soak
> for a while to let other people have a look at it.
>
> On Tue, 30 Mar 2021 at 13:52, Dafna Hirschfeld
> wrote:
> >
> > drm_bridge_funcs has a function called 'hpd_notify'.
> > The function drm_bridge_hpd_notify does not call
> > 'hpd_notify' but it calls 'hpd_cb'. This is rather
> > confusing. Rename the function to fix this confusion.
> >
> > Signed-off-by: Dafna Hirschfeld
> > ---
> > drivers/gpu/drm/bridge/adv7511/adv7511_drv.c| 2 +-
> > drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c | 4 ++--
> > drivers/gpu/drm/bridge/display-connector.c | 2 +-
> > drivers/gpu/drm/bridge/lontium-lt9611uxc.c | 8
> > drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 2 +-
> > drivers/gpu/drm/bridge/ti-tpd12s015.c | 2 +-
> > drivers/gpu/drm/drm_bridge.c| 8
> > include/drm/drm_bridge.h| 8
> > 8 files changed, 18 insertions(+), 18 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> > b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> > index 76555ae64e9c..748f82910f4f 100644
> > --- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> > +++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> > @@ -449,7 +449,7 @@ static void adv7511_hpd_work(struct work_struct *work)
> > cec_phys_addr_invalidate(adv7511->cec_adap);
> >
> > drm_kms_helper_hotplug_event(adv7511->connector.dev);
> > } else {
> > - drm_bridge_hpd_notify(&adv7511->bridge, status);
> > + drm_bridge_hpd_cb(&adv7511->bridge, status);
> > }
> > }
> > }
> > diff --git a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
> > b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
> > index d0c65610ebb5..682da288ff6d 100644
> > --- a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
> > +++ b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
> > @@ -794,7 +794,7 @@ static void cdns_mhdp_fw_cb(const struct firmware *fw,
> > void *context)
> > if (mhdp->connector.dev)
> > drm_kms_helper_hotplug_event(mhdp->bridge.dev);
> > else
> > - drm_bridge_hpd_notify(&mhdp->bridge,
> > cdns_mhdp_detect(mhdp));
> > + drm_bridge_hpd_cb(&mhdp->bridge,
> > cdns_mhdp_detect(mhdp));
> > }
> > }
> >
> > @@ -2314,7 +2314,7 @@ static irqreturn_t cdns_mhdp_irq_handler(int irq,
> > void *data)
> > else
> >
> > drm_kms_helper_hotplug_event(mhdp->bridge.dev);
> > } else {
> > - drm_bridge_hpd_notify(&mhdp->bridge,
> > cdns_mhdp_detect(mhdp));
> > + drm_bridge_hpd_cb(&mhdp->bridge,
> > cdns_mhdp_detect(mhdp));
> > }
> > }
> >
> > diff --git a/drivers/gpu/drm/bridge/display-connector.c
> > b/drivers/gpu/drm/bridge/display-connector.c
> > index 05eb759da6fc..8ccd69d7fe34 100644
> > --- a/drivers/gpu/drm/bridge/display-connector.c
> > +++ b/drivers/gpu/drm/bridge/display-connector.c
> > @@ -98,7 +98,7 @@ static irqreturn_t display_connector_hpd_irq(int irq,
> > void *arg)
> > struct display_connector *conn = arg;
> > struct drm_bridge *bridge = &conn->bridge;
> >
> > - drm_bridge_hpd_notify(bridge, display_connector_detect(bridge));
> > + drm_bridge_hpd_cb(bridge, display_connector_detect(bridge));
> >
> > return IRQ_HANDLED;
> > }
> > diff --git a/drivers/gpu/drm/bridge/lontium-lt9611uxc.c
> > b/drivers/gpu/drm/bridge/lontium-lt9611uxc.c
> > index fee27952ec6d..58f61b5da605 100644
> > --- a/drivers/gpu/drm/bridge/lontium-lt9611uxc.c
> > +++ b/drivers/gpu/drm/bridge/lontium-lt9611uxc.c
> > @@ -175,10 +175,10 @@ static void lt9611uxc_hpd_work(struct work_struct
> > *work)
> > connected = lt9611uxc->hdmi_connected;
> > mutex_unlock(<9611uxc->ocm_lock);
> >
> > - drm_bridge_hpd_notify(<9611uxc->bridge,
> > - connected ?
> > - connector_status_connected :
> > - connector_status_disconnected);
> > + drm_bridge_hpd_cb(<9611uxc->bridge,
> > + connected ?
> > + connector_status_connected :
> > + connector_status_disconnected);
> > }
> > }
> >
> > diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > index dda4fa9a1a08..
Re: [PATCH -next] drm/bridge: lt8912b: DRM_LONTIUM_LT8912B select GPIOLIB
Hey Zhang On Tue, 6 Apr 2021 at 11:07, Zhang Jianhua wrote: > > If CONFIG_DRM_LONTIUM_LT8912B=y, the following errors will be seen while > compiling lontium-lt8912b.c > > drivers/gpu/drm/bridge/lontium-lt8912b.c: In function > ‘lt8912_hard_power_on’: > drivers/gpu/drm/bridge/lontium-lt8912b.c:252:2: error: implicit > declaration of function ‘gpiod_set_value_cansleep’; did you mean > ‘gpio_set_value_cansleep’? [-Werror=implicit-function-declaration] > gpiod_set_value_cansleep(lt->gp_reset, 0); > ^~~~ > gpio_set_value_cansleep > drivers/gpu/drm/bridge/lontium-lt8912b.c: In function ‘lt8912_parse_dt’: > drivers/gpu/drm/bridge/lontium-lt8912b.c:628:13: error: implicit > declaration of function ‘devm_gpiod_get_optional’; did you mean > ‘devm_gpio_request_one’? [-Werror=implicit-function-declaration] > gp_reset = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_HIGH); > ^~~ > devm_gpio_request_one > drivers/gpu/drm/bridge/lontium-lt8912b.c:628:51: error: ‘GPIOD_OUT_HIGH’ > undeclared (first use in this function); did you mean ‘GPIOF_INIT_HIGH’? > gp_reset = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_HIGH); >^~ >GPIOF_INIT_HIGH > > Signed-off-by: Zhang Jianhua > --- > drivers/gpu/drm/bridge/Kconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig > index dba62f92d051..caa9658ec933 100644 > --- a/drivers/gpu/drm/bridge/Kconfig > +++ b/drivers/gpu/drm/bridge/Kconfig > @@ -67,6 +67,7 @@ config DRM_LONTIUM_LT8912B > select DRM_PANEL_BRIDGE > select DRM_KMS_HELPER > select REGMAP_I2C > + select GPIOLIB This appears like the right fix for this problem. However, a number of drm/bridge drivers seem to call both gpio_set_value_cansleep() and devm_gpiod_get_optional() without having the GPIOLIB kconfig option selected so this can't be a new issue. Maybe some more investigation is in order. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/8] drm/amdgpu: Remove unused function amdgpu_bo_fbdev_mmap()
Hi
Am 06.04.21 um 11:43 schrieb Christian König:
Am 06.04.21 um 11:08 schrieb Thomas Zimmermann:
Remove an unused function. Mapping the fbdev framebuffer is apparently
not supported.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Christian König
Should I just upstream this through our internal branches?
I guess you can pick up this patch into your branches if that's easier
for you. For the other patches, I'd like to merge them via drm-misc-next.
Best regards
Thomas
Thanks,
Christian.
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 19 ---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 2 --
2 files changed, 21 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index b99e9d8736c2..cfc89164dee8 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -1092,25 +1092,6 @@ void amdgpu_bo_fini(struct amdgpu_device *adev)
}
}
-/**
- * amdgpu_bo_fbdev_mmap - mmap fbdev memory
- * @bo: &amdgpu_bo buffer object
- * @vma: vma as input from the fbdev mmap method
- *
- * Calls ttm_fbdev_mmap() to mmap fbdev memory if it is backed by a bo.
- *
- * Returns:
- * 0 for success or a negative error code on failure.
- */
-int amdgpu_bo_fbdev_mmap(struct amdgpu_bo *bo,
- struct vm_area_struct *vma)
-{
- if (vma->vm_pgoff != 0)
- return -EACCES;
-
- return ttm_bo_mmap_obj(vma, &bo->tbo);
-}
-
/**
* amdgpu_bo_set_tiling_flags - set tiling flags
* @bo: &amdgpu_bo buffer object
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
index 54ceb065e546..46e94d413c5c 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
@@ -268,8 +268,6 @@ void amdgpu_bo_unpin(struct amdgpu_bo *bo);
int amdgpu_bo_evict_vram(struct amdgpu_device *adev);
int amdgpu_bo_init(struct amdgpu_device *adev);
void amdgpu_bo_fini(struct amdgpu_device *adev);
-int amdgpu_bo_fbdev_mmap(struct amdgpu_bo *bo,
- struct vm_area_struct *vma);
int amdgpu_bo_set_tiling_flags(struct amdgpu_bo *bo, u64 tiling_flags);
void amdgpu_bo_get_tiling_flags(struct amdgpu_bo *bo, u64
*tiling_flags);
int amdgpu_bo_set_metadata (struct amdgpu_bo *bo, void *metadata,
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
OpenPGP_signature
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/8] drm/amdgpu: Implement mmap as GEM object function
Hi
Am 06.04.21 um 11:35 schrieb Christian König:
Am 06.04.21 um 11:08 schrieb Thomas Zimmermann:
Moving the driver-specific mmap code into a GEM object function allows
for using DRM helpers for various mmap callbacks.
This change resolves several inconsistencies between regular mmap and
prime-based mmap. The vm_ops field in vma is now set for all mmap'ed
areas. Previously it way only set for regular mmap calls, prime-based
mmap used TTM's default vm_ops. The check for kfd_bo has been taken
from amdgpu_verify_access(), which is not called any longer and has
been removed.
As a side effect, amdgpu_ttm_vm_ops and amdgpu_ttm_fault() are now
implemented in amdgpu's GEM code.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 46 -
drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.h | 2 -
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 4 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 64 +++
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 71 -
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h | 1 -
6 files changed, 66 insertions(+), 122 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
index e0c4f7c7f1b9..19c5ab08d9ec 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
@@ -42,52 +42,6 @@
#include
#include
-/**
- * amdgpu_gem_prime_mmap - &drm_driver.gem_prime_mmap implementation
- * @obj: GEM BO
- * @vma: Virtual memory area
- *
- * Sets up a userspace mapping of the BO's memory in the given
- * virtual memory area.
- *
- * Returns:
- * 0 on success or a negative error code on failure.
- */
-int amdgpu_gem_prime_mmap(struct drm_gem_object *obj,
- struct vm_area_struct *vma)
-{
- struct amdgpu_bo *bo = gem_to_amdgpu_bo(obj);
- struct amdgpu_device *adev = amdgpu_ttm_adev(bo->tbo.bdev);
- unsigned asize = amdgpu_bo_size(bo);
- int ret;
-
- if (!vma->vm_file)
- return -ENODEV;
-
- if (adev == NULL)
- return -ENODEV;
-
- /* Check for valid size. */
- if (asize < vma->vm_end - vma->vm_start)
- return -EINVAL;
-
- if (amdgpu_ttm_tt_get_usermm(bo->tbo.ttm) ||
- (bo->flags & AMDGPU_GEM_CREATE_NO_CPU_ACCESS)) {
- return -EPERM;
- }
- vma->vm_pgoff += amdgpu_bo_mmap_offset(bo) >> PAGE_SHIFT;
-
- /* prime mmap does not need to check access, so allow here */
- ret = drm_vma_node_allow(&obj->vma_node,
vma->vm_file->private_data);
- if (ret)
- return ret;
-
- ret = ttm_bo_mmap(vma->vm_file, vma, &adev->mman.bdev);
- drm_vma_node_revoke(&obj->vma_node, vma->vm_file->private_data);
-
- return ret;
-}
-
static int
__dma_resv_make_exclusive(struct dma_resv *obj)
{
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.h
index 39b5b9616fd8..3e93b9b407a9 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.h
@@ -31,8 +31,6 @@ struct drm_gem_object
*amdgpu_gem_prime_import(struct drm_device *dev,
struct dma_buf *dma_buf);
bool amdgpu_dmabuf_is_xgmi_accessible(struct amdgpu_device *adev,
struct amdgpu_bo *bo);
-int amdgpu_gem_prime_mmap(struct drm_gem_object *obj,
- struct vm_area_struct *vma);
extern const struct dma_buf_ops amdgpu_dmabuf_ops;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 76f48f79c70b..e96d2758f4bb 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -1656,7 +1656,7 @@ static const struct file_operations
amdgpu_driver_kms_fops = {
.flush = amdgpu_flush,
.release = drm_release,
.unlocked_ioctl = amdgpu_drm_ioctl,
- .mmap = amdgpu_mmap,
+ .mmap = drm_gem_mmap,
.poll = drm_poll,
.read = drm_read,
#ifdef CONFIG_COMPAT
@@ -1719,7 +1719,7 @@ static const struct drm_driver amdgpu_kms_driver
= {
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
.gem_prime_import = amdgpu_gem_prime_import,
- .gem_prime_mmap = amdgpu_gem_prime_mmap,
+ .gem_prime_mmap = drm_gem_prime_mmap,
.name = DRIVER_NAME,
.desc = DRIVER_DESC,
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
index fb7171e5507c..fe93faad05f2 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
@@ -41,6 +41,36 @@
static const struct drm_gem_object_funcs amdgpu_gem_object_funcs;
+static vm_fault_t amdgpu_ttm_fault(struct vm_fault *vmf)
Please name that function amdgpu_gem_fault or amdgpu_gem_object_fault
+{
+ struct ttm_buffer_object *bo = vmf->vma->vm_private_data;
+ vm_fault_t ret;
+
+ ret = ttm_bo_vm_reserve(bo, vmf);
+ if (ret)
+ return
Re: [PATCH 3/8] drm/amdgpu: Implement mmap as GEM object function
Hi Thomas,
Am 06.04.21 um 12:38 schrieb Thomas Zimmermann:
Hi
Am 06.04.21 um 11:35 schrieb Christian König:
Am 06.04.21 um 11:08 schrieb Thomas Zimmermann:
Moving the driver-specific mmap code into a GEM object function allows
for using DRM helpers for various mmap callbacks.
This change resolves several inconsistencies between regular mmap and
prime-based mmap. The vm_ops field in vma is now set for all mmap'ed
areas. Previously it way only set for regular mmap calls, prime-based
mmap used TTM's default vm_ops. The check for kfd_bo has been taken
from amdgpu_verify_access(), which is not called any longer and has
been removed.
As a side effect, amdgpu_ttm_vm_ops and amdgpu_ttm_fault() are now
implemented in amdgpu's GEM code.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 46 -
drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.h | 2 -
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 4 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 64 +++
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 71
-
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h | 1 -
6 files changed, 66 insertions(+), 122 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
index e0c4f7c7f1b9..19c5ab08d9ec 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
@@ -42,52 +42,6 @@
#include
#include
-/**
- * amdgpu_gem_prime_mmap - &drm_driver.gem_prime_mmap implementation
- * @obj: GEM BO
- * @vma: Virtual memory area
- *
- * Sets up a userspace mapping of the BO's memory in the given
- * virtual memory area.
- *
- * Returns:
- * 0 on success or a negative error code on failure.
- */
-int amdgpu_gem_prime_mmap(struct drm_gem_object *obj,
- struct vm_area_struct *vma)
-{
- struct amdgpu_bo *bo = gem_to_amdgpu_bo(obj);
- struct amdgpu_device *adev = amdgpu_ttm_adev(bo->tbo.bdev);
- unsigned asize = amdgpu_bo_size(bo);
- int ret;
-
- if (!vma->vm_file)
- return -ENODEV;
-
- if (adev == NULL)
- return -ENODEV;
-
- /* Check for valid size. */
- if (asize < vma->vm_end - vma->vm_start)
- return -EINVAL;
-
- if (amdgpu_ttm_tt_get_usermm(bo->tbo.ttm) ||
- (bo->flags & AMDGPU_GEM_CREATE_NO_CPU_ACCESS)) {
- return -EPERM;
- }
- vma->vm_pgoff += amdgpu_bo_mmap_offset(bo) >> PAGE_SHIFT;
-
- /* prime mmap does not need to check access, so allow here */
- ret = drm_vma_node_allow(&obj->vma_node,
vma->vm_file->private_data);
- if (ret)
- return ret;
-
- ret = ttm_bo_mmap(vma->vm_file, vma, &adev->mman.bdev);
- drm_vma_node_revoke(&obj->vma_node, vma->vm_file->private_data);
-
- return ret;
-}
-
static int
__dma_resv_make_exclusive(struct dma_resv *obj)
{
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.h
index 39b5b9616fd8..3e93b9b407a9 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.h
@@ -31,8 +31,6 @@ struct drm_gem_object
*amdgpu_gem_prime_import(struct drm_device *dev,
struct dma_buf *dma_buf);
bool amdgpu_dmabuf_is_xgmi_accessible(struct amdgpu_device *adev,
struct amdgpu_bo *bo);
-int amdgpu_gem_prime_mmap(struct drm_gem_object *obj,
- struct vm_area_struct *vma);
extern const struct dma_buf_ops amdgpu_dmabuf_ops;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 76f48f79c70b..e96d2758f4bb 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -1656,7 +1656,7 @@ static const struct file_operations
amdgpu_driver_kms_fops = {
.flush = amdgpu_flush,
.release = drm_release,
.unlocked_ioctl = amdgpu_drm_ioctl,
- .mmap = amdgpu_mmap,
+ .mmap = drm_gem_mmap,
.poll = drm_poll,
.read = drm_read,
#ifdef CONFIG_COMPAT
@@ -1719,7 +1719,7 @@ static const struct drm_driver
amdgpu_kms_driver = {
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
.gem_prime_import = amdgpu_gem_prime_import,
- .gem_prime_mmap = amdgpu_gem_prime_mmap,
+ .gem_prime_mmap = drm_gem_prime_mmap,
.name = DRIVER_NAME,
.desc = DRIVER_DESC,
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
index fb7171e5507c..fe93faad05f2 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
@@ -41,6 +41,36 @@
static const struct drm_gem_object_funcs amdgpu_gem_object_funcs;
+static vm_fault_t amdgpu_ttm_fault(struct vm_fault *vmf)
Please name that function amdgpu_gem_fault or amdgpu_gem_object_fault
+{
+ struct ttm_buffer_object *bo = vmf->vma->vm_private_data;
+ vm_fault_t ret;
+
+
Re: [PATCH] pwm: Rename pwm_get_state() to better reflect its semantic
On Tue, Apr 06, 2021 at 09:30:36AM +0200, Uwe Kleine-König wrote: > Given that lowlevel drivers usually cannot implement exactly what a > consumer requests with pwm_apply_state() there is some rounding involved. > > pwm_get_state() traditionally returned the setting that was requested most > recently by the consumer (opposed to what was actually implemented in > hardware in reply to the last request). To make this semantic obvious > rename the function. > > Signed-off-by: Uwe Kleine-König > --- > Documentation/driver-api/pwm.rst | 6 +++- > drivers/clk/clk-pwm.c | 2 +- > drivers/gpu/drm/i915/display/intel_panel.c | 4 +-- > drivers/input/misc/da7280.c| 2 +- > drivers/input/misc/pwm-beeper.c| 2 +- > drivers/input/misc/pwm-vibra.c | 4 +-- > drivers/pwm/core.c | 4 +-- > drivers/pwm/pwm-atmel-hlcdc.c | 2 +- > drivers/pwm/pwm-atmel.c| 2 +- > drivers/pwm/pwm-imx27.c| 2 +- > drivers/pwm/pwm-rockchip.c | 2 +- > drivers/pwm/pwm-stm32-lp.c | 4 +-- > drivers/pwm/pwm-sun4i.c| 2 +- > drivers/pwm/sysfs.c| 18 ++-- > drivers/regulator/pwm-regulator.c | 4 +-- > drivers/video/backlight/pwm_bl.c | 10 +++ > include/linux/pwm.h| 34 ++ > 17 files changed, 59 insertions(+), 45 deletions(-) Honestly, I don't think this is worth the churn. If you think people will easily get confused by this then a better solution might be to more explicitly document the pwm_get_state() function to say exactly what it returns. But there's no need to make life difficult for everyone by renaming this to something as cumbersome as this. Thierry signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] drm/i915/pmu: Do not report 100% RC6 if not supported
Hi Tvrtko,
> We use GT parked status to estimate RC6 while not in use, however if RC6
> is not supported to start with that does not work very well and produces a
> false 100% RC6 readout.
>
> Fix by not advancing the estimated RC6 counter when feature is not
> supported.
>
> Signed-off-by: Tvrtko Ursulin
> Fixes: 1fe699e30113 ("drm/i915/pmu: Fix sleep under atomic in RC6 readout")
> Reported-by: Eero T Tamminen
> ---
> drivers/gpu/drm/i915/i915_pmu.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
> index 41651ac255fa..02fe0d22c470 100644
> --- a/drivers/gpu/drm/i915/i915_pmu.c
> +++ b/drivers/gpu/drm/i915/i915_pmu.c
> @@ -191,7 +191,10 @@ static u64 get_rc6(struct intel_gt *gt)
>* on top of the last known real value, as the approximated RC6
>* counter value.
>*/
> - val = ktime_since_raw(pmu->sleep_last);
> + if (gt->rc6.supported)
> + val = ktime_since_raw(pmu->sleep_last);
> + else
> + val = 0;
if rc6 is not supported, why are we here?
Did you mean rc6.enabled ?
Andi
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] pwm: Rename pwm_get_state() to better reflect its semantic
On Tue, Apr 06, 2021 at 09:30:36AM +0200, Uwe Kleine-König wrote: > Given that lowlevel drivers usually cannot implement exactly what a > consumer requests with pwm_apply_state() there is some rounding involved. Acked-by: Mark Brown signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH -next] drm/bridge: lt8912b: DRM_LONTIUM_LT8912B select GPIOLIB
If CONFIG_DRM_LONTIUM_LT8912B=y, the following errors will be seen while compiling lontium-lt8912b.c drivers/gpu/drm/bridge/lontium-lt8912b.c: In function ‘lt8912_hard_power_on’: drivers/gpu/drm/bridge/lontium-lt8912b.c:252:2: error: implicit declaration of function ‘gpiod_set_value_cansleep’; did you mean ‘gpio_set_value_cansleep’? [-Werror=implicit-function-declaration] gpiod_set_value_cansleep(lt->gp_reset, 0); ^~~~ gpio_set_value_cansleep drivers/gpu/drm/bridge/lontium-lt8912b.c: In function ‘lt8912_parse_dt’: drivers/gpu/drm/bridge/lontium-lt8912b.c:628:13: error: implicit declaration of function ‘devm_gpiod_get_optional’; did you mean ‘devm_gpio_request_one’? [-Werror=implicit-function-declaration] gp_reset = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_HIGH); ^~~ devm_gpio_request_one drivers/gpu/drm/bridge/lontium-lt8912b.c:628:51: error: ‘GPIOD_OUT_HIGH’ undeclared (first use in this function); did you mean ‘GPIOF_INIT_HIGH’? gp_reset = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_HIGH); ^~ GPIOF_INIT_HIGH Signed-off-by: Zhang Jianhua --- drivers/gpu/drm/bridge/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig index dba62f92d051..caa9658ec933 100644 --- a/drivers/gpu/drm/bridge/Kconfig +++ b/drivers/gpu/drm/bridge/Kconfig @@ -67,6 +67,7 @@ config DRM_LONTIUM_LT8912B select DRM_PANEL_BRIDGE select DRM_KMS_HELPER select REGMAP_I2C + select GPIOLIB help Driver for Lontium LT8912B DSI to HDMI bridge chip driver. -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RFC 2/3] fpga: support loading from a pre-allocated buffer
Hi Nava,
On minor comment below.
On 02/04/2021 11.09, Nava kishore Manne wrote:
Some systems are memory constrained but they need to load very
large Configuration files. The FPGA subsystem allows drivers to
request this Configuration image be loaded from the filesystem,
but this requires that the entire configuration data be loaded
into kernel memory first before it's provided to the driver.
This can lead to a situation where we map the configuration
data twice, once to load the configuration data into kernel
memory and once to copy the configuration data into the final
resting place which is nothing but a dma-able continuous buffer.
This creates needless memory pressure and delays due to multiple
copies. Let's add a dmabuf handling support to the fpga manager
framework that allows drivers to load the Configuration data
directly from a pre-allocated buffer. This skips the intermediate
step of allocating a buffer in kernel memory to hold the
Configuration data.
Signed-off-by: Nava kishore Manne
---
drivers/fpga/fpga-mgr.c | 126 +-
drivers/fpga/of-fpga-region.c | 3 +
include/linux/fpga/fpga-mgr.h | 6 +-
3 files changed, 132 insertions(+), 3 deletions(-)
diff --git a/drivers/fpga/fpga-mgr.c b/drivers/fpga/fpga-mgr.c
index b85bc47c91a9..13faed61af62 100644
--- a/drivers/fpga/fpga-mgr.c
+++ b/drivers/fpga/fpga-mgr.c
@@ -8,6 +8,8 @@
* With code from the mailing list:
* Copyright (C) 2013 Xilinx, Inc.
*/
+#include
+#include
#include
#include
#include
@@ -306,6 +308,51 @@ static int fpga_mgr_buf_load(struct fpga_manager *mgr,
return rc;
}
+/**
+ * fpga_mgr_buf_load - load fpga from image in dma buffer
s/fpga_mgr_buf_load/fpga_dmabuf_load
// Martin
+ * @mgr:fpga manager
+ * @info: fpga image info
+ *
+ * Step the low level fpga manager through the device-specific steps of getting
+ * an FPGA ready to be configured, writing the image to it, then doing whatever
+ * post-configuration steps necessary. This code assumes the caller got the
+ * mgr pointer from of_fpga_mgr_get() and checked that it is not an error code.
+ *
+ * Return: 0 on success, negative error code otherwise.
+ */
+static int fpga_dmabuf_load(struct fpga_manager *mgr,
+ struct fpga_image_info *info)
+{
+ struct dma_buf_attachment *attach;
+ struct sg_table *sgt;
+ int ret;
+
+ /* create attachment for dmabuf with the user device */
+ attach = dma_buf_attach(mgr->dmabuf, &mgr->dev);
+ if (IS_ERR(attach)) {
+ pr_err("failed to attach dmabuf\n");
+ ret = PTR_ERR(attach);
+ goto fail_put;
+ }
+
+ sgt = dma_buf_map_attachment(attach, DMA_BIDIRECTIONAL);
+ if (IS_ERR(sgt)) {
+ ret = PTR_ERR(sgt);
+ goto fail_detach;
+ }
+
+ info->sgt = sgt;
+ ret = fpga_mgr_buf_load_sg(mgr, info, info->sgt);
+ dma_buf_unmap_attachment(attach, sgt, DMA_BIDIRECTIONAL);
+
+fail_detach:
+ dma_buf_detach(mgr->dmabuf, attach);
+fail_put:
+ dma_buf_put(mgr->dmabuf);
+
+ return ret;
+}
+
/**
* fpga_mgr_firmware_load - request firmware and load to fpga
* @mgr: fpga manager
@@ -358,6 +405,8 @@ static int fpga_mgr_firmware_load(struct fpga_manager *mgr,
*/
int fpga_mgr_load(struct fpga_manager *mgr, struct fpga_image_info *info)
{
+ if (info->flags & FPGA_MGR_CONFIG_DMA_BUF)
+ return fpga_dmabuf_load(mgr, info);
if (info->sgt)
return fpga_mgr_buf_load_sg(mgr, info, info->sgt);
if (info->buf && info->count)
@@ -549,6 +598,62 @@ void fpga_mgr_unlock(struct fpga_manager *mgr)
}
EXPORT_SYMBOL_GPL(fpga_mgr_unlock);
+static int fpga_dmabuf_fd_get(struct file *file, char __user *argp)
+{
+ struct fpga_manager *mgr = (struct fpga_manager *)(file->private_data);
+ int buffd;
+
+ if (copy_from_user(&buffd, argp, sizeof(buffd)))
+ return -EFAULT;
+
+ mgr->dmabuf = dma_buf_get(buffd);
+ if (IS_ERR_OR_NULL(mgr->dmabuf))
+ return -EINVAL;
+
+ return 0;
+}
+
+static int fpga_device_open(struct inode *inode, struct file *file)
+{
+ struct miscdevice *miscdev = file->private_data;
+ struct fpga_manager *mgr = container_of(miscdev,
+ struct fpga_manager, miscdev);
+
+ file->private_data = mgr;
+
+ return 0;
+}
+
+static int fpga_device_release(struct inode *inode, struct file *file)
+{
+ return 0;
+}
+
+static long fpga_device_ioctl(struct file *file, unsigned int cmd,
+ unsigned long arg)
+{
+ char __user *argp = (char __user *)arg;
+ int err;
+
+ switch (cmd) {
+ case FPGA_IOCTL_LOAD_DMA_BUFF:
+ err = fpga_dmabuf_fd_get(file, argp);
+ break;
+ default:
+ err = -ENOTTY;
+ }
+
+
Re: [PATCH 3/8] drm/amdgpu: Implement mmap as GEM object function
Hi Am 06.04.21 um 12:56 schrieb Christian König: In the end I went with the semantics I found in amdgpu_mmap() and handled KFD specially. Let me know if this requires to be changed. Well the question is where is the call to drm_vma_node_verify_access() now? Cause that needs to be skipped for KFD BOs. I see. It's now drm_vma_node_is_allowed(); called by drm_gem_mmap(). [1] So drm_gem_mmap() cannot be used by amdgpu. If I understand the code at [2] correctly, KFD objects don't use the GEM ioctl interfaces, but they still use the internal GEM object that is part of the TTM BO. In this case, amdgpu could have its own version of drm_gem_mmap(), which calls drm_gem_mmap_obj(), [3] which in turn handles the mmap details via GEM object functions. drm_gem_prime_mmap() doesn't do any additional verification. Best regards Thomas [1] https://elixir.bootlin.com/linux/v5.11.11/source/drivers/gpu/drm/drm_gem.c#L1156 [2] https://elixir.bootlin.com/linux/v5.11.11/source/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c#L1224 [3] https://elixir.bootlin.com/linux/v5.12-rc6/source/drivers/gpu/drm/drm_gem.c#L1053 Regards, Christian. Best regards Thomas - int amdgpu_copy_buffer(struct amdgpu_ring *ring, uint64_t src_offset, uint64_t dst_offset, uint32_t byte_count, struct dma_resv *resv, diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h index dec0db8b0b13..6e51faad7371 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h @@ -146,7 +146,6 @@ int amdgpu_fill_buffer(struct amdgpu_bo *bo, struct dma_resv *resv, struct dma_fence **fence); -int amdgpu_mmap(struct file *filp, struct vm_area_struct *vma); int amdgpu_ttm_alloc_gart(struct ttm_buffer_object *bo); int amdgpu_ttm_recover_gart(struct ttm_buffer_object *tbo); uint64_t amdgpu_ttm_domain_start(struct amdgpu_device *adev, uint32_t type); ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer OpenPGP_signature Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i915/sysfs: convert snprintf to sysfs_emit
On Sun, 04 Apr 2021, Carlis wrote:
> From: Xuezhi Zhang
>
> Fix the following coccicheck warning:
> drivers/gpu/drm/i915//i915_sysfs.c:266:8-16:
> WARNING: use scnprintf or sprintf
> drivers/gpu/drm/i915//i915_sysfs.c:285:8-16:
> WARNING: use scnprintf or sprintf
> drivers/gpu/drm/i915//i915_sysfs.c:276:8-16:
> WARNING: use scnprintf or sprintf
> drivers/gpu/drm/i915//i915_sysfs.c:335:8-16:
> WARNING: use scnprintf or sprintf
> drivers/gpu/drm/i915//i915_sysfs.c:390:8-16:
> WARNING: use scnprintf or sprintf
> drivers/gpu/drm/i915//i915_sysfs.c:465:8-16:
> WARNING: use scnprintf or sprintf
> drivers/gpu/drm/i915//i915_sysfs.c:107:8-16:
> WARNING: use scnprintf or sprintf
> drivers/gpu/drm/i915//i915_sysfs.c:75:8-16:
> WARNING: use scnprintf or sprintf
> drivers/gpu/drm/i915//i915_sysfs.c:83:8-16:
> WARNING: use scnprintf or sprintf
> drivers/gpu/drm/i915//i915_sysfs.c:91:8-16:
> WARNING: use scnprintf or sprintf
> drivers/gpu/drm/i915//i915_sysfs.c:99:8-16:
> WARNING: use scnprintf or sprintf
> drivers/gpu/drm/i915//i915_sysfs.c:326:8-16:
> WARNING: use scnprintf or sprintf
>
> Signed-off-by: Xuezhi Zhang
Thanks for the patch, pushed to drm-intel-next.
BR,
Jani.
> ---
> drivers/gpu/drm/i915/i915_sysfs.c | 30 --
> 1 file changed, 12 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_sysfs.c
> b/drivers/gpu/drm/i915/i915_sysfs.c
> index 45d32ef42787..4c6b5d52b5ca 100644
> --- a/drivers/gpu/drm/i915/i915_sysfs.c
> +++ b/drivers/gpu/drm/i915/i915_sysfs.c
> @@ -72,7 +72,7 @@ show_rc6_mask(struct device *kdev, struct device_attribute
> *attr, char *buf)
> if (HAS_RC6pp(dev_priv))
> mask |= BIT(2);
>
> - return snprintf(buf, PAGE_SIZE, "%x\n", mask);
> + return sysfs_emit(buf, "%x\n", mask);
> }
>
> static ssize_t
> @@ -80,7 +80,7 @@ show_rc6_ms(struct device *kdev, struct device_attribute
> *attr, char *buf)
> {
> struct drm_i915_private *dev_priv = kdev_minor_to_i915(kdev);
> u32 rc6_residency = calc_residency(dev_priv, GEN6_GT_GFX_RC6);
> - return snprintf(buf, PAGE_SIZE, "%u\n", rc6_residency);
> + return sysfs_emit(buf, "%u\n", rc6_residency);
> }
>
> static ssize_t
> @@ -88,7 +88,7 @@ show_rc6p_ms(struct device *kdev, struct device_attribute
> *attr, char *buf)
> {
> struct drm_i915_private *dev_priv = kdev_minor_to_i915(kdev);
> u32 rc6p_residency = calc_residency(dev_priv, GEN6_GT_GFX_RC6p);
> - return snprintf(buf, PAGE_SIZE, "%u\n", rc6p_residency);
> + return sysfs_emit(buf, "%u\n", rc6p_residency);
> }
>
> static ssize_t
> @@ -96,7 +96,7 @@ show_rc6pp_ms(struct device *kdev, struct device_attribute
> *attr, char *buf)
> {
> struct drm_i915_private *dev_priv = kdev_minor_to_i915(kdev);
> u32 rc6pp_residency = calc_residency(dev_priv, GEN6_GT_GFX_RC6pp);
> - return snprintf(buf, PAGE_SIZE, "%u\n", rc6pp_residency);
> + return sysfs_emit(buf, "%u\n", rc6pp_residency);
> }
>
> static ssize_t
> @@ -104,7 +104,7 @@ show_media_rc6_ms(struct device *kdev, struct
> device_attribute *attr, char *buf)
> {
> struct drm_i915_private *dev_priv = kdev_minor_to_i915(kdev);
> u32 rc6_residency = calc_residency(dev_priv, VLV_GT_MEDIA_RC6);
> - return snprintf(buf, PAGE_SIZE, "%u\n", rc6_residency);
> + return sysfs_emit(buf, "%u\n", rc6_residency);
> }
>
> static DEVICE_ATTR(rc6_enable, S_IRUGO, show_rc6_mask, NULL);
> @@ -263,8 +263,7 @@ static ssize_t gt_act_freq_mhz_show(struct device *kdev,
> struct drm_i915_private *i915 = kdev_minor_to_i915(kdev);
> struct intel_rps *rps = &i915->gt.rps;
>
> - return snprintf(buf, PAGE_SIZE, "%d\n",
> - intel_rps_read_actual_frequency(rps));
> + return sysfs_emit(buf, "%d\n", intel_rps_read_actual_frequency(rps));
> }
>
> static ssize_t gt_cur_freq_mhz_show(struct device *kdev,
> @@ -273,8 +272,7 @@ static ssize_t gt_cur_freq_mhz_show(struct device *kdev,
> struct drm_i915_private *i915 = kdev_minor_to_i915(kdev);
> struct intel_rps *rps = &i915->gt.rps;
>
> - return snprintf(buf, PAGE_SIZE, "%d\n",
> - intel_gpu_freq(rps, rps->cur_freq));
> + return sysfs_emit(buf, "%d\n", intel_gpu_freq(rps, rps->cur_freq));
> }
>
> static ssize_t gt_boost_freq_mhz_show(struct device *kdev, struct
> device_attribute *attr, char *buf)
> @@ -282,8 +280,7 @@ static ssize_t gt_boost_freq_mhz_show(struct device
> *kdev, struct device_attribu
> struct drm_i915_private *i915 = kdev_minor_to_i915(kdev);
> struct intel_rps *rps = &i915->gt.rps;
>
> - return snprintf(buf, PAGE_SIZE, "%d\n",
> - intel_gpu_freq(rps, rps->boost_freq));
> + return sysfs_emit(buf, "%d\n", intel_gpu_freq(rps, rps->boost_freq));
> }
>
> static ssize_t gt_boost_freq_mhz_store(struct device *kdev,
> @@ -323,8 +320,7 @@ static ssize_t vlv_rpe_freq_mhz_show(struct device *kdev,
> st
Re: [PATCH] drm: bridge: rename the function drm_bridge_hpd_notify to drm_bridge_hpd_cb
Hi Dafna,
Thank you for the patch.
On Tue, Mar 30, 2021 at 01:52:00PM +0200, Dafna Hirschfeld wrote:
> drm_bridge_funcs has a function called 'hpd_notify'.
> The function drm_bridge_hpd_notify does not call
> 'hpd_notify' but it calls 'hpd_cb'. This is rather
> confusing. Rename the function to fix this confusion.
>
> Signed-off-by: Dafna Hirschfeld
> ---
> drivers/gpu/drm/bridge/adv7511/adv7511_drv.c| 2 +-
> drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c | 4 ++--
> drivers/gpu/drm/bridge/display-connector.c | 2 +-
> drivers/gpu/drm/bridge/lontium-lt9611uxc.c | 8
> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 2 +-
> drivers/gpu/drm/bridge/ti-tpd12s015.c | 2 +-
> drivers/gpu/drm/drm_bridge.c| 8
> include/drm/drm_bridge.h| 8
> 8 files changed, 18 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> index 76555ae64e9c..748f82910f4f 100644
> --- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> +++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> @@ -449,7 +449,7 @@ static void adv7511_hpd_work(struct work_struct *work)
> cec_phys_addr_invalidate(adv7511->cec_adap);
> drm_kms_helper_hotplug_event(adv7511->connector.dev);
> } else {
> - drm_bridge_hpd_notify(&adv7511->bridge, status);
> + drm_bridge_hpd_cb(&adv7511->bridge, status);
> }
> }
> }
> diff --git a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
> b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
> index d0c65610ebb5..682da288ff6d 100644
> --- a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
> +++ b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
> @@ -794,7 +794,7 @@ static void cdns_mhdp_fw_cb(const struct firmware *fw,
> void *context)
> if (mhdp->connector.dev)
> drm_kms_helper_hotplug_event(mhdp->bridge.dev);
> else
> - drm_bridge_hpd_notify(&mhdp->bridge,
> cdns_mhdp_detect(mhdp));
> + drm_bridge_hpd_cb(&mhdp->bridge,
> cdns_mhdp_detect(mhdp));
> }
> }
>
> @@ -2314,7 +2314,7 @@ static irqreturn_t cdns_mhdp_irq_handler(int irq, void
> *data)
> else
> drm_kms_helper_hotplug_event(mhdp->bridge.dev);
> } else {
> - drm_bridge_hpd_notify(&mhdp->bridge,
> cdns_mhdp_detect(mhdp));
> + drm_bridge_hpd_cb(&mhdp->bridge,
> cdns_mhdp_detect(mhdp));
> }
> }
>
> diff --git a/drivers/gpu/drm/bridge/display-connector.c
> b/drivers/gpu/drm/bridge/display-connector.c
> index 05eb759da6fc..8ccd69d7fe34 100644
> --- a/drivers/gpu/drm/bridge/display-connector.c
> +++ b/drivers/gpu/drm/bridge/display-connector.c
> @@ -98,7 +98,7 @@ static irqreturn_t display_connector_hpd_irq(int irq, void
> *arg)
> struct display_connector *conn = arg;
> struct drm_bridge *bridge = &conn->bridge;
>
> - drm_bridge_hpd_notify(bridge, display_connector_detect(bridge));
> + drm_bridge_hpd_cb(bridge, display_connector_detect(bridge));
>
> return IRQ_HANDLED;
> }
> diff --git a/drivers/gpu/drm/bridge/lontium-lt9611uxc.c
> b/drivers/gpu/drm/bridge/lontium-lt9611uxc.c
> index fee27952ec6d..58f61b5da605 100644
> --- a/drivers/gpu/drm/bridge/lontium-lt9611uxc.c
> +++ b/drivers/gpu/drm/bridge/lontium-lt9611uxc.c
> @@ -175,10 +175,10 @@ static void lt9611uxc_hpd_work(struct work_struct *work)
> connected = lt9611uxc->hdmi_connected;
> mutex_unlock(<9611uxc->ocm_lock);
>
> - drm_bridge_hpd_notify(<9611uxc->bridge,
> - connected ?
> - connector_status_connected :
> - connector_status_disconnected);
> + drm_bridge_hpd_cb(<9611uxc->bridge,
> + connected ?
> + connector_status_connected :
> + connector_status_disconnected);
> }
> }
>
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> index dda4fa9a1a08..984ab5c4bc71 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> @@ -3026,7 +3026,7 @@ static irqreturn_t dw_hdmi_irq(int irq, void *dev_id)
>
> if (hdmi->bridge.dev) {
> drm_helper_hpd_irq_event(hdmi->bridge.dev);
> - drm_bridge_hpd_notify(&hdmi->bridge, status);
> + drm_bridge_hpd_cb(&hdmi->bridge, status);
> }
> }
>
> diff --git a/drivers/gpu/drm/bridge/ti-tpd12s015.c
> b/drivers/gpu/drm/bridge/ti-tp
Re: [PATCH 3/8] drm/amdgpu: Implement mmap as GEM object function
Hi Thomas, Am 06.04.21 um 13:55 schrieb Thomas Zimmermann: Hi Am 06.04.21 um 12:56 schrieb Christian König: In the end I went with the semantics I found in amdgpu_mmap() and handled KFD specially. Let me know if this requires to be changed. Well the question is where is the call to drm_vma_node_verify_access() now? Cause that needs to be skipped for KFD BOs. I see. It's now drm_vma_node_is_allowed(); called by drm_gem_mmap(). [1] So drm_gem_mmap() cannot be used by amdgpu. If I understand the code at [2] correctly, KFD objects don't use the GEM ioctl interfaces, but they still use the internal GEM object that is part of the TTM BO. In this case, amdgpu could have its own version of drm_gem_mmap(), which calls drm_gem_mmap_obj(), [3] which in turn handles the mmap details via GEM object functions. Correct, well we could cleanup the KFD to use the GEM functions as well. Felix what exactly was your objections to using this? Regards, Christian. drm_gem_prime_mmap() doesn't do any additional verification. Best regards Thomas [1] https://elixir.bootlin.com/linux/v5.11.11/source/drivers/gpu/drm/drm_gem.c#L1156 [2] https://elixir.bootlin.com/linux/v5.11.11/source/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c#L1224 [3] https://elixir.bootlin.com/linux/v5.12-rc6/source/drivers/gpu/drm/drm_gem.c#L1053 Regards, Christian. Best regards Thomas - int amdgpu_copy_buffer(struct amdgpu_ring *ring, uint64_t src_offset, uint64_t dst_offset, uint32_t byte_count, struct dma_resv *resv, diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h index dec0db8b0b13..6e51faad7371 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h @@ -146,7 +146,6 @@ int amdgpu_fill_buffer(struct amdgpu_bo *bo, struct dma_resv *resv, struct dma_fence **fence); -int amdgpu_mmap(struct file *filp, struct vm_area_struct *vma); int amdgpu_ttm_alloc_gart(struct ttm_buffer_object *bo); int amdgpu_ttm_recover_gart(struct ttm_buffer_object *tbo); uint64_t amdgpu_ttm_domain_start(struct amdgpu_device *adev, uint32_t type); ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/8] drm/amdgpu: Implement mmap as GEM object function
Hi Am 06.04.21 um 14:42 schrieb Christian König: Hi Thomas, Am 06.04.21 um 13:55 schrieb Thomas Zimmermann: Hi Am 06.04.21 um 12:56 schrieb Christian König: In the end I went with the semantics I found in amdgpu_mmap() and handled KFD specially. Let me know if this requires to be changed. Well the question is where is the call to drm_vma_node_verify_access() now? Cause that needs to be skipped for KFD BOs. I see. It's now drm_vma_node_is_allowed(); called by drm_gem_mmap(). [1] So drm_gem_mmap() cannot be used by amdgpu. If I understand the code at [2] correctly, KFD objects don't use the GEM ioctl interfaces, but they still use the internal GEM object that is part of the TTM BO. In this case, amdgpu could have its own version of drm_gem_mmap(), which calls drm_gem_mmap_obj(), [3] which in turn handles the mmap details via GEM object functions. Correct, well we could cleanup the KFD to use the GEM functions as well. The KFD code already calls amdgpu_gem_object_create(). It should have the object-functions pointer set for use with mmap. Not sure what the use of drm_vma_node_is_allowed() would involve. Best regards Thomas Felix what exactly was your objections to using this? Regards, Christian. drm_gem_prime_mmap() doesn't do any additional verification. Best regards Thomas [1] https://elixir.bootlin.com/linux/v5.11.11/source/drivers/gpu/drm/drm_gem.c#L1156 [2] https://elixir.bootlin.com/linux/v5.11.11/source/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c#L1224 [3] https://elixir.bootlin.com/linux/v5.12-rc6/source/drivers/gpu/drm/drm_gem.c#L1053 Regards, Christian. Best regards Thomas - int amdgpu_copy_buffer(struct amdgpu_ring *ring, uint64_t src_offset, uint64_t dst_offset, uint32_t byte_count, struct dma_resv *resv, diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h index dec0db8b0b13..6e51faad7371 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h @@ -146,7 +146,6 @@ int amdgpu_fill_buffer(struct amdgpu_bo *bo, struct dma_resv *resv, struct dma_fence **fence); -int amdgpu_mmap(struct file *filp, struct vm_area_struct *vma); int amdgpu_ttm_alloc_gart(struct ttm_buffer_object *bo); int amdgpu_ttm_recover_gart(struct ttm_buffer_object *tbo); uint64_t amdgpu_ttm_domain_start(struct amdgpu_device *adev, uint32_t type); ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer OpenPGP_signature Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/8] drm/amdgpu: Implement mmap as GEM object function
Am 06.04.21 um 14:52 schrieb Thomas Zimmermann: Hi Am 06.04.21 um 14:42 schrieb Christian König: Hi Thomas, Am 06.04.21 um 13:55 schrieb Thomas Zimmermann: Hi Am 06.04.21 um 12:56 schrieb Christian König: In the end I went with the semantics I found in amdgpu_mmap() and handled KFD specially. Let me know if this requires to be changed. Well the question is where is the call to drm_vma_node_verify_access() now? Cause that needs to be skipped for KFD BOs. I see. It's now drm_vma_node_is_allowed(); called by drm_gem_mmap(). [1] So drm_gem_mmap() cannot be used by amdgpu. If I understand the code at [2] correctly, KFD objects don't use the GEM ioctl interfaces, but they still use the internal GEM object that is part of the TTM BO. In this case, amdgpu could have its own version of drm_gem_mmap(), which calls drm_gem_mmap_obj(), [3] which in turn handles the mmap details via GEM object functions. Correct, well we could cleanup the KFD to use the GEM functions as well. The KFD code already calls amdgpu_gem_object_create(). It should have the object-functions pointer set for use with mmap. Not sure what the use of drm_vma_node_is_allowed() would involve. The KFD allows BOs to be mmaped with different offsets than what's used in the DRM node. So drm_vma_node_is_allowed() would return false as far as I know. Regards, Christian. Best regards Thomas Felix what exactly was your objections to using this? Regards, Christian. drm_gem_prime_mmap() doesn't do any additional verification. Best regards Thomas [1] https://elixir.bootlin.com/linux/v5.11.11/source/drivers/gpu/drm/drm_gem.c#L1156 [2] https://elixir.bootlin.com/linux/v5.11.11/source/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c#L1224 [3] https://elixir.bootlin.com/linux/v5.12-rc6/source/drivers/gpu/drm/drm_gem.c#L1053 Regards, Christian. Best regards Thomas - int amdgpu_copy_buffer(struct amdgpu_ring *ring, uint64_t src_offset, uint64_t dst_offset, uint32_t byte_count, struct dma_resv *resv, diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h index dec0db8b0b13..6e51faad7371 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h @@ -146,7 +146,6 @@ int amdgpu_fill_buffer(struct amdgpu_bo *bo, struct dma_resv *resv, struct dma_fence **fence); -int amdgpu_mmap(struct file *filp, struct vm_area_struct *vma); int amdgpu_ttm_alloc_gart(struct ttm_buffer_object *bo); int amdgpu_ttm_recover_gart(struct ttm_buffer_object *tbo); uint64_t amdgpu_ttm_domain_start(struct amdgpu_device *adev, uint32_t type); ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v15 3/4] dt-bindings: msm: dsi: add yaml schemas for DSI PHY bindings
On Mon, 05 Apr 2021 16:36:09 +0530, Krishna Manikandan wrote: > Add YAML schema for the device tree bindings for DSI PHY. > > Signed-off-by: Krishna Manikandan > > Changes in v1: >- Merge dsi-phy.yaml and dsi-phy-10nm.yaml (Stephen Boyd) >- Remove qcom,dsi-phy-regulator-ldo-mode (Stephen Boyd) >- Add clock cells properly (Stephen Boyd) >- Remove unnecessary decription from clock names (Stephen Boyd) >- Add pin names for the supply entries for 10nm phy which is > used in sc7180 and sdm845 (Stephen Boyd) >- Remove unused header files from examples (Stephen Boyd) >- Drop labels for display nodes and correct node name (Stephen Boyd) > > Changes in v2: >- Drop maxItems for clock (Stephen Boyd) >- Add vdds supply pin information for sdm845 (Stephen Boyd) >- Add examples for 14nm, 20nm and 28nm phy yaml files (Stephen Boyd) >- Keep child nodes directly under soc node (Stephen Boyd) > > Changes in v3: >- Use a separate yaml file to describe the common properties > for all the dsi phy versions (Stephen Boyd) >- Remove soc from examples (Stephen Boyd) >- Add description for register property > > Changes in v4: >- Modify the title for all the phy versions (Stephen Boyd) >- Drop description for all the phy versions (Stephen Boyd) >- Modify the description for register property (Stephen Boyd) > > Changes in v5: >- Remove unused properties from common dsi phy file >- Add clock-cells and phy-cells to required property > list (Stephen Boyd) > --- > .../bindings/display/msm/dsi-phy-10nm.yaml | 68 + > .../bindings/display/msm/dsi-phy-14nm.yaml | 66 > .../bindings/display/msm/dsi-phy-20nm.yaml | 71 > ++ > .../bindings/display/msm/dsi-phy-28nm.yaml | 68 + > .../bindings/display/msm/dsi-phy-common.yaml | 40 > 5 files changed, 313 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/msm/dsi-phy-10nm.yaml > create mode 100644 > Documentation/devicetree/bindings/display/msm/dsi-phy-14nm.yaml > create mode 100644 > Documentation/devicetree/bindings/display/msm/dsi-phy-20nm.yaml > create mode 100644 > Documentation/devicetree/bindings/display/msm/dsi-phy-28nm.yaml > create mode 100644 > Documentation/devicetree/bindings/display/msm/dsi-phy-common.yaml > My bot found errors running 'make dt_binding_check' on your patch: yamllint warnings/errors: dtschema/dtc warnings/errors: Documentation/devicetree/bindings/display/msm/dsi-phy-28nm.example.dt.yaml:0:0: /example-0/dsi-phy@fd922a00: failed to match any schema with compatible: ['qcom,dsi-phy-28nm'] See https://patchwork.ozlabs.org/patch/1462327 This check can fail if there are any dependencies. The base for a patch series is generally the most recent rc1. If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date: pip3 install dtschema --upgrade Please check and re-submit. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH][next] drm/msm: Fix spelling mistake "Purgable" -> "Purgeable"
From: Colin Ian King There is a spelling mistake in debugfs gem stats. Fix it. Also re-align output to cater for the extra 1 character. Signed-off-by: Colin Ian King --- drivers/gpu/drm/msm/msm_gem.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c index f146d9c5ba9c..4e2e0a93d17d 100644 --- a/drivers/gpu/drm/msm/msm_gem.c +++ b/drivers/gpu/drm/msm/msm_gem.c @@ -979,13 +979,13 @@ void msm_gem_describe_objects(struct list_head *list, struct seq_file *m) msm_gem_describe(obj, m, &stats); } - seq_printf(m, "Total:%4d objects, %9zu bytes\n", + seq_printf(m, "Total: %4d objects, %9zu bytes\n", stats.all.count, stats.all.size); - seq_printf(m, "Active: %4d objects, %9zu bytes\n", + seq_printf(m, "Active:%4d objects, %9zu bytes\n", stats.active.count, stats.active.size); - seq_printf(m, "Purgable: %4d objects, %9zu bytes\n", + seq_printf(m, "Purgeable: %4d objects, %9zu bytes\n", stats.purgable.count, stats.purgable.size); - seq_printf(m, "Purged: %4d objects, %9zu bytes\n", + seq_printf(m, "Purged:%4d objects, %9zu bytes\n", stats.purged.count, stats.purged.size); } #endif -- 2.30.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] drm-intel-gt-next
Hi Dave & Daniel,
Bit late PR due to Easter break.
Prep work for local memory support as requested. Hard hang
fix for Sandybridge. Sanitize dma-buf size on import and
avoid GPU reset if heartbeat callback runs before timeout.
The rest is mostly small fixes and code/checkpatch cleanups.
Regards, Joonas
***
drm-intel-gt-next-2021-04-06:
Driver Changes:
- Prepare for local/device memory support on DG1 by starting
to use it for kernel internal allocations: context, ring
and engine scratch (Matt A, CQ, Abdiel, Imre)
- Sandybridge fix to avoid hard hang on ring resume (Chris)
- Limit imported dma-buf size to int32 (Matt A)
- Double check heartbeat timeout before resetting (Chris)
- Use new tasklet API for execution list (Emil)
- Fix SPDX checkpats warnings (Chris)
- Fixes for various checkpatch warnings (Chris)
- Selftest improvements (Chris)
- Move the defer_request waiter active assertion to correct spot (Chris)
- Make local-memory probing a GT operation (Matt, Tvrtko)
- Protect against request freeing during cancellation on wedging (Chris)
- Retire unexpected starting state error dumping (Chris)
- Distinction of memory regions in debugging (Zbigniew)
- Always flush the submission queue on checking for idle (Chris)
- Consolidate 2big error check to helper (Matt)
- Decrease number of subplatform bits (Tvrtko)
- Remove unused internal request priority levels (Chris)
- Document the unused internal header bits in buddy allocator (Matt)
- Cleanup the region class/instance encoding (Matt)
The following changes since commit 06debd6e1b28029e6e77c41e59a162868f377897:
Merge tag 'drm-intel-next-2021-03-16' of
git://anongit.freedesktop.org/drm/drm-intel into drm-next (2021-03-18 08:06:34
+1000)
are available in the Git repository at:
git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-gt-next-2021-04-06
for you to fetch changes up to 2da21daa7d93817fa82f703c29adfcb5eed7f77d:
drm/i915/gt: Always flush the submission queue on checking for idle
(2021-03-24 19:31:59 +0100)
Driver Changes:
- Prepare for local/device memory support on DG1 by starting
to use it for kernel internal allocations: context, ring
and engine scratch (Matt A, CQ, Abdiel, Imre)
- Sandybridge fix to avoid hard hang on ring resume (Chris)
- Limit imported dma-buf size to int32 (Matt A)
- Double check heartbeat timeout before resetting (Chris)
- Use new tasklet API for execution list (Emil)
- Fix SPDX checkpats warnings (Chris)
- Fixes for various checkpatch warnings (Chris)
- Selftest improvements (Chris)
- Move the defer_request waiter active assertion to correct spot (Chris)
- Make local-memory probing a GT operation (Matt, Tvrtko)
- Protect against request freeing during cancellation on wedging (Chris)
- Retire unexpected starting state error dumping (Chris)
- Distinction of memory regions in debugging (Zbigniew)
- Always flush the submission queue on checking for idle (Chris)
- Consolidate 2big error check to helper (Matt)
- Decrease number of subplatform bits (Tvrtko)
- Remove unused internal request priority levels (Chris)
- Document the unused internal header bits in buddy allocator (Matt)
- Cleanup the region class/instance encoding (Matt)
Abdiel Janulgue (1):
drm/i915: introduce mem->reserved
CQ Tang (1):
drm/i915: reserve stolen for LMEM region
Chris Wilson (22):
drm/i915: Strip out internal priorities
drm/i915: Remove I915_USER_PRIORITY_SHIFT
drm/i915/gt: Call stop_ring() from ring resume, again
drm/i915/gt: SPDX cleanup
drm/i915/gt: Add some missing blank lines after declaration
drm/i915/gt: Remove repeated words from comments
drm/i915/gt: Fixup misaligned function parameters
drm/i915/gt: Remove a bonus newline
drm/i915/gt: Wrap macro arg in ()
drm/i915/gt: Insert spaces into GEN3_L3LOG_SIZE/4
drm/i915/gt: Replace unnecessary ',' with '; '
drm/i915/gt: Add a space before '('
drm/i915/gt: Replace 'return' with a fall-through
drm/i915/selftests: Check for engine-reset errors in the middle of
workarounds
drm/i915/gt: Move the defer_request waiter active assertion
drm/i915: Protect against request freeing during cancellation on wedging
drm/i915/selftests: Use a single copy of the mocs table
drm/i915/gt: Retire unexpected starting state error dumping
drm/i915/selftests: Restore previous heartbeat interval
drm/i915/gt: Double check heartbeat timeout before resetting
drm/i915/selftest: Synchronise with the GPU timestamp
drm/i915/gt: Always flush the submission queue on checking for idle
Emil Renner Berthing (1):
drm/i915/gt: use new tasklet API for execution list
Imre Deak (1):
drm/i915/dg1: Reserve first 1MB of local memory
Matthew Auld (11):
drm/i915/gem: don't trust the dma_buf->size
drm/i915/gem: consolid
Re: [PATCH] pwm: Rename pwm_get_state() to better reflect its semantic
Hello Thierry, On Tue, Apr 06, 2021 at 01:16:31PM +0200, Thierry Reding wrote: > On Tue, Apr 06, 2021 at 09:30:36AM +0200, Uwe Kleine-König wrote: > > Given that lowlevel drivers usually cannot implement exactly what a > > consumer requests with pwm_apply_state() there is some rounding involved. > > > > pwm_get_state() traditionally returned the setting that was requested most > > recently by the consumer (opposed to what was actually implemented in > > hardware in reply to the last request). To make this semantic obvious > > rename the function. > > > > Signed-off-by: Uwe Kleine-König > > --- > > Documentation/driver-api/pwm.rst | 6 +++- > > drivers/clk/clk-pwm.c | 2 +- > > drivers/gpu/drm/i915/display/intel_panel.c | 4 +-- > > drivers/input/misc/da7280.c| 2 +- > > drivers/input/misc/pwm-beeper.c| 2 +- > > drivers/input/misc/pwm-vibra.c | 4 +-- > > drivers/pwm/core.c | 4 +-- > > drivers/pwm/pwm-atmel-hlcdc.c | 2 +- > > drivers/pwm/pwm-atmel.c| 2 +- > > drivers/pwm/pwm-imx27.c| 2 +- > > drivers/pwm/pwm-rockchip.c | 2 +- > > drivers/pwm/pwm-stm32-lp.c | 4 +-- > > drivers/pwm/pwm-sun4i.c| 2 +- > > drivers/pwm/sysfs.c| 18 ++-- > > drivers/regulator/pwm-regulator.c | 4 +-- > > drivers/video/backlight/pwm_bl.c | 10 +++ > > include/linux/pwm.h| 34 ++ > > 17 files changed, 59 insertions(+), 45 deletions(-) > > Honestly, I don't think this is worth the churn. If you think people > will easily get confused by this then a better solution might be to more > explicitly document the pwm_get_state() function to say exactly what it > returns. I'm not so optimistic that people become aware of the semantic just because there is documentation describing it and I strongly believe that a good name for functions is more important than accurate documentation. If you don't agree, what do you think about the updated wording in Documentation/driver-api/pwm.rst? > But there's no need to make life difficult for everyone by > renaming this to something as cumbersome as this. I don't expect any merge conflicts (and if still a problem occurs resolving should be trivial enough). So I obviously don't agree to your weighing. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | https://www.pengutronix.de/ | signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amdgpu: Fix a potential sdma invalid access
Hi Qu,
Am 06.04.21 um 08:04 schrieb Qu Huang:
Hi Christian,
On 2021/4/3 16:49, Christian König wrote:
Hi Qu,
Am 03.04.21 um 07:08 schrieb Qu Huang:
Hi Christian,
On 2021/4/3 0:25, Christian König wrote:
Hi Qu,
Am 02.04.21 um 05:18 schrieb Qu Huang:
Before dma_resv_lock(bo->base.resv, NULL) in
amdgpu_bo_release_notify(),
the bo->base.resv lock may be held by ttm_mem_evict_first(),
That can't happen since when bo_release_notify is called the BO has
not
more references and is therefore deleted.
And we never evict a deleted BO, we just wait for it to become idle.
Yes, the bo reference counter return to zero will enter
ttm_bo_release(),but notify bo release (call
amdgpu_bo_release_notify())
first happen, and then test if a reservation object's fences have been
signaled, and then mark bo as deleted and remove bo from the LRU list.
When ttm_bo_release() and ttm_mem_evict_first() is concurrent,
the Bo has not been removed from the LRU list and is not marked as
deleted, this will happen.
Not sure on which code base you are, but I don't see how this can
happen.
ttm_mem_evict_first() calls ttm_bo_get_unless_zero() and
ttm_bo_release() is only called when the BO reference count becomes
zero.
So ttm_mem_evict_first() will see that this BO is about to be destroyed
and skips it.
Yes, you are right. My version of TTM is ROCM 3.3, so
ttm_mem_evict_first() did not call ttm_bo_get_unless_zero(), check that
ROCM 4.0 ttm doesn't have this issue. This is an oversight on my part.
As a test, when we use CPU memset instead of SDMA fill in
amdgpu_bo_release_notify(), the result is page fault:
PID: 5490 TASK: 8e8136e04100 CPU: 4 COMMAND: "gemmPerf"
#0 [8e79eaa17970] machine_kexec at b2863784
#1 [8e79eaa179d0] __crash_kexec at b291ce92
#2 [8e79eaa17aa0] crash_kexec at b291cf80
#3 [8e79eaa17ab8] oops_end at b2f6c768
#4 [8e79eaa17ae0] no_context at b2f5aaa6
#5 [8e79eaa17b30] __bad_area_nosemaphore at b2f5ab3d
#6 [8e79eaa17b80] bad_area_nosemaphore at b2f5acae
#7 [8e79eaa17b90] __do_page_fault at b2f6f6c0
#8 [8e79eaa17c00] do_page_fault at b2f6f925
#9 [8e79eaa17c30] page_fault at b2f6b758
[exception RIP: memset+31]
RIP: b2b8668f RSP: 8e79eaa17ce8 RFLAGS: 00010a17
RAX: bebebebebebebebe RBX: 8e747bff10c0 RCX:
060b0020
RDX: RSI: 00be RDI:
ab807f00
RBP: 8e79eaa17d10 R8: 8e79eaa14000 R9:
ab7c8000
R10: bcba R11: 01ba R12:
8e79ebaa4050
R13: ab7c8000 R14: 00022600 R15:
8e8136e04100
ORIG_RAX: CS: 0010 SS: 0018
#10 [8e79eaa17ce8] amdgpu_bo_release_notify at c092f2d1
[amdgpu]
#11 [8e79eaa17d18] ttm_bo_release at c08f39dd [amdttm]
#12 [8e79eaa17d58] amdttm_bo_put at c08f3c8c [amdttm]
#13 [8e79eaa17d68] amdttm_bo_vm_close at c08f7ac9 [amdttm]
#14 [8e79eaa17d80] remove_vma at b29ef115
#15 [8e79eaa17da0] exit_mmap at b29f2c64
#16 [8e79eaa17e58] mmput at b28940c7
#17 [8e79eaa17e78] do_exit at b289dc95
#18 [8e79eaa17f10] do_group_exit at b289e4cf
#19 [8e79eaa17f40] sys_exit_group at b289e544
#20 [8e79eaa17f50] system_call_fastpath at b2f74ddb
Well that might be perfectly expected. VRAM is not necessarily CPU
accessible.
As a test，use CPU memset instead of SDMA fill, This is my code:
void amdgpu_bo_release_notify(struct ttm_buffer_object *bo)
{
struct amdgpu_bo *abo;
uint64_t num_pages;
struct drm_mm_node *mm_node;
struct amdgpu_device *adev;
void __iomem *kaddr;
if (!amdgpu_bo_is_amdgpu_bo(bo))
return;
abo = ttm_to_amdgpu_bo(bo);
num_pages = abo->tbo.num_pages;
mm_node = abo->tbo.mem.mm_node;
adev = amdgpu_ttm_adev(abo->tbo.bdev);
kaddr = adev->mman.aper_base_kaddr;
if (abo->kfd_bo)
amdgpu_amdkfd_unreserve_memory_limit(abo);
if (bo->mem.mem_type != TTM_PL_VRAM || !bo->mem.mm_node ||
!(abo->flags & AMDGPU_GEM_CREATE_VRAM_WIPE_ON_RELEASE))
return;
dma_resv_lock(amdkcl_ttm_resvp(bo), NULL);
while (num_pages && mm_node) {
void *ptr = kaddr + (mm_node->start << PAGE_SHIFT);
That might not work as expected.
aper_base_kaddr can only point to a 256MiB window into VRAM, but VRAM
itself is usually much larger.
So your memset_io() might end up in nirvana if the BO is allocated
outside of the window.
memset_io(ptr, AMDGPU_POISON & 0xff, mm_node->size
Re: [PATCH] drm/panel: panel-dsi-cm: disable TE for now
On Tue, Mar 16, 2021 at 04:11:30PM +0200, Tomi Valkeinen wrote:
> Hi Sebastian, Sam, Thierry,
>
> On 27/02/2021 23:45, Sebastian Reichel wrote:
> > From: Sebastian Reichel
> >
> > Disable TE for Droid 4 panel, since implementation is currently
> > broken. Also disable it for N950 panel, which is untested.
> >
> > Reported-by: Tony Lindgren
> > Reported-by: Tomi Valkeinen
> > Fixes: 4c1b935fea54 ("drm/omap: dsi: move TE GPIO handling into core")
> > Signed-off-by: Sebastian Reichel
> > ---
> > I suggest to start by fix the regression like this and look into
> > proper Droid 4 TE support separatly. Assumption is, that Tomi
> > tested taal panel, droid4 panel is 'broken' and N950 (himalaya)
> > is untested [*], so choosing safe default. Patch is compile-tested
> > only.
> >
> > [*] N950 display is not yet functional on mainline, since it needs
> > the omap3 FIFO workaround:
> > https://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-n900.git/commit/?h=n950-display-tony&id=d4cbc226a30b29bf258397b052c9ec68c8a3
> > ---
> > drivers/gpu/drm/panel/panel-dsi-cm.c | 12 +---
> > 1 file changed, 9 insertions(+), 3 deletions(-)
>
> Reviewed-by: Tomi Valkeinen
>
> Sam, Thierry, will you pick this up or can I push to drm-misc-fixes?
Sorry, I had missed this. Feel free to take this through drm-misc
yourself:
Acked-by: Thierry Reding
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/i915/display/vlv_dsi: Do not skip panel_pwr_cycle_delay when disabling the panel
Hi,
On 3/25/21 12:48 PM, Hans de Goede wrote:
> After the recently added commit fe0f1e3bfdfe ("drm/i915: Shut down
> displays gracefully on reboot"), the DSI panel on a Cherry Trail based
> Predia Basic tablet would no longer properly light up after reboot.
>
> I've managed to reproduce this without rebooting by doing:
> chvt 3; echo 1 > /sys/class/graphics/fb0/blank;\
> echo 0 > /sys/class/graphics/fb0/blank
>
> Which rapidly turns the panel off and back on again.
>
> The vlv_dsi.c code uses an intel_dsi_msleep() helper for the various delays
> used for panel on/off, since starting with MIPI-sequences version >= 3 the
> delays are already included inside the MIPI-sequences.
>
> The problems exposed by the "Shut down displays gracefully on reboot"
> change, show that using this helper for the panel_pwr_cycle_delay is
> not the right thing to do. This has not been noticed until now because
> normally the panel never is cycled off and directly on again in quick
> succession.
>
> Change the msleep for the panel_pwr_cycle_delay to a normal msleep()
> call to avoid the panel staying black after a quick off + on cycle.
>
> Cc: Ville Syrjälä
> Fixes: fe0f1e3bfdfe ("drm/i915: Shut down displays gracefully on reboot")
> Signed-off-by: Hans de Goede
Ping? Ville AFAICT this is ready for merging, can you review this please so
that I can push it to drm-intel-next ?
Regards,
Hans
> ---
> drivers/gpu/drm/i915/display/vlv_dsi.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/vlv_dsi.c
> b/drivers/gpu/drm/i915/display/vlv_dsi.c
> index d5a3f69c5df3..38d5a1f3ded5 100644
> --- a/drivers/gpu/drm/i915/display/vlv_dsi.c
> +++ b/drivers/gpu/drm/i915/display/vlv_dsi.c
> @@ -996,14 +996,14 @@ static void intel_dsi_post_disable(struct
> intel_atomic_state *state,
>* FIXME As we do with eDP, just make a note of the time here
>* and perform the wait before the next panel power on.
>*/
> - intel_dsi_msleep(intel_dsi, intel_dsi->panel_pwr_cycle_delay);
> + msleep(intel_dsi->panel_pwr_cycle_delay);
> }
>
> static void intel_dsi_shutdown(struct intel_encoder *encoder)
> {
> struct intel_dsi *intel_dsi = enc_to_intel_dsi(encoder);
>
> - intel_dsi_msleep(intel_dsi, intel_dsi->panel_pwr_cycle_delay);
> + msleep(intel_dsi->panel_pwr_cycle_delay);
> }
>
> static bool intel_dsi_get_hw_state(struct intel_encoder *encoder,
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/amd/pm: convert sysfs snprintf to sysfs_emit
From: Xuezhi Zhang Fix the following coccicheck warning: drivers/gpu/drm/amd/pm//amdgpu_pm.c:1940:8-16: WARNING: use scnprintf or sprintf drivers/gpu/drm/amd/pm//amdgpu_pm.c:1978:8-16: WARNING: use scnprintf or sprintf drivers/gpu/drm/amd/pm//amdgpu_pm.c:2022:8-16: WARNING: use scnprintf or sprintf drivers/gpu/drm/amd/pm//amdgpu_pm.c:294:8-16: WARNING: use scnprintf or sprintf drivers/gpu/drm/amd/pm//amdgpu_pm.c:154:8-16: WARNING: use scnprintf or sprintf drivers/gpu/drm/amd/pm//amdgpu_pm.c:496:8-16: WARNING: use scnprintf or sprintf drivers/gpu/drm/amd/pm//amdgpu_pm.c:512:9-17: WARNING: use scnprintf or sprintf drivers/gpu/drm/amd/pm//amdgpu_pm.c:1740:8-16: WARNING: use scnprintf or sprintf drivers/gpu/drm/amd/pm//amdgpu_pm.c:1667:8-16: WARNING: use scnprintf or sprintf drivers/gpu/drm/amd/pm//amdgpu_pm.c:2074:8-16: WARNING: use scnprintf or sprintf drivers/gpu/drm/amd/pm//amdgpu_pm.c:2047:9-17: WARNING: use scnprintf or sprintf drivers/gpu/drm/amd/pm//amdgpu_pm.c:2768:8-16: WARNING: use scnprintf or sprintf drivers/gpu/drm/amd/pm//amdgpu_pm.c:2738:8-16: WARNING: use scnprintf or sprintf drivers/gpu/drm/amd/pm//amdgpu_pm.c:2442:8-16: WARNING: use scnprintf or sprintf drivers/gpu/drm/amd/pm//amdgpu_pm.c:3246:8-16: WARNING: use scnprintf or sprintf drivers/gpu/drm/amd/pm//amdgpu_pm.c:3253:8-16: WARNING: use scnprintf or sprintf drivers/gpu/drm/amd/pm//amdgpu_pm.c:2458:8-16: WARNING: use scnprintf or sprintf drivers/gpu/drm/amd/pm//amdgpu_pm.c:3047:8-16: WARNING: use scnprintf or sprintf drivers/gpu/drm/amd/pm//amdgpu_pm.c:3133:8-16: WARNING: use scnprintf or sprintf drivers/gpu/drm/amd/pm//amdgpu_pm.c:3209:8-16: WARNING: use scnprintf or sprintf drivers/gpu/drm/amd/pm//amdgpu_pm.c:3216:8-16: WARNING: use scnprintf or sprintf drivers/gpu/drm/amd/pm//amdgpu_pm.c:2410:8-16: WARNING: use scnprintf or sprintf drivers/gpu/drm/amd/pm//amdgpu_pm.c:2496:8-16: WARNING: use scnprintf or sprintf drivers/gpu/drm/amd/pm//amdgpu_pm.c:2470:8-16: WARNING: use scnprintf or sprintf drivers/gpu/drm/amd/pm//amdgpu_pm.c:2426:8-16: WARNING: use scnprintf or sprintf drivers/gpu/drm/amd/pm//amdgpu_pm.c:2965:8-16: WARNING: use scnprintf or sprintf drivers/gpu/drm/amd/pm//amdgpu_pm.c:2972:8-16: WARNING: use scnprintf or sprintf drivers/gpu/drm/amd/pm//amdgpu_pm.c:3006:8-16: WARNING: use scnprintf or sprintf drivers/gpu/drm/amd/pm//amdgpu_pm.c:3013:8-16: WARNING: use scnprintf or sprintf Signed-off-by: Xuezhi Zhang --- drivers/gpu/drm/amd/pm/amdgpu_pm.c | 58 +++--- 1 file changed, 29 insertions(+), 29 deletions(-) diff --git a/drivers/gpu/drm/amd/pm/amdgpu_pm.c b/drivers/gpu/drm/amd/pm/amdgpu_pm.c index 5fa65f191a37..2777966ec1ca 100644 --- a/drivers/gpu/drm/amd/pm/amdgpu_pm.c +++ b/drivers/gpu/drm/amd/pm/amdgpu_pm.c @@ -151,7 +151,7 @@ static ssize_t amdgpu_get_power_dpm_state(struct device *dev, pm_runtime_mark_last_busy(ddev->dev); pm_runtime_put_autosuspend(ddev->dev); - return snprintf(buf, PAGE_SIZE, "%s\n", + return sysfs_emit(buf, "%s\n", (pm == POWER_STATE_TYPE_BATTERY) ? "battery" : (pm == POWER_STATE_TYPE_BALANCED) ? "balanced" : "performance"); } @@ -291,7 +291,7 @@ static ssize_t amdgpu_get_power_dpm_force_performance_level(struct device *dev, pm_runtime_mark_last_busy(ddev->dev); pm_runtime_put_autosuspend(ddev->dev); - return snprintf(buf, PAGE_SIZE, "%s\n", + return sysfs_emit(buf, "%s\n", (level == AMD_DPM_FORCED_LEVEL_AUTO) ? "auto" : (level == AMD_DPM_FORCED_LEVEL_LOW) ? "low" : (level == AMD_DPM_FORCED_LEVEL_HIGH) ? "high" : @@ -493,7 +493,7 @@ static ssize_t amdgpu_get_pp_cur_state(struct device *dev, if (i == data.nums) i = -EINVAL; - return snprintf(buf, PAGE_SIZE, "%d\n", i); + return sysfs_emit(buf, "%d\n", i); } static ssize_t amdgpu_get_pp_force_state(struct device *dev, @@ -509,7 +509,7 @@ static ssize_t amdgpu_get_pp_force_state(struct device *dev, if (adev->pp_force_state_enabled) return amdgpu_get_pp_cur_state(dev, attr, buf); else - return snprintf(buf, PAGE_SIZE, "\n"); + return sysfs_emit(buf, "\n"); } static ssize_t amdgpu_set_pp_force_state(struct device *dev, @@ -1664,7 +1664,7 @@ static ssize_t amdgpu_get_pp_sclk_od(struct device *dev, pm_runtime_mark_last_busy(ddev->dev); pm_runtime_put_autosuspend(ddev->dev); - return snprintf(buf, PAGE_SIZE, "%d\n", value); + return sysfs_emit(buf, "%d\n", value); } static ssize_t amdgpu_set_pp_sclk_od(struct device *dev, @@ -1737,7 +1737,7 @@ static ssize_t amdgpu_get_pp_mclk_od(struct device *dev, pm_runtime_mark_last_busy(ddev->dev); pm_runtime_put_autosuspend(ddev->dev); - return snprintf(buf, PAGE_SIZE, "%d\n", value); + return sysfs_emit(buf, "%d\n
Re: [PATCH v5 1/2] dt-bindings: usb: add analogix,anx7688.yaml
Hi Laurent and Dafna, On 31/3/21 22:40, Laurent Pinchart wrote: > On Tue, Mar 30, 2021 at 05:14:44PM +0200, Enric Balletbo i Serra wrote: >> On 30/3/21 15:35, Dafna Hirschfeld wrote: >>> On 05.03.21 16:19, Laurent Pinchart wrote: On Fri, Mar 05, 2021 at 04:14:03PM +0100, Dafna Hirschfeld wrote: > On 05.03.21 15:34, Laurent Pinchart wrote: >> On Fri, Mar 05, 2021 at 01:43:50PM +0100, Dafna Hirschfeld wrote: >>> ANX7688 is a USB Type-C port controller with a MUX. It converts HDMI >>> 2.0 to >>> DisplayPort 1.3 Ultra-HDi (4096x2160p60). >>> The integrated crosspoint switch (the MUX) supports USB 3.1 data >>> transfer >>> along with the DisplayPort Alternate Mode signaling over USB Type-C. >>> Additionally, an on-chip microcontroller (OCM) is available to manage >>> the >>> signal switching, Channel Configuration (CC) detection, USB Power >>> Delivery (USB-PD), Vendor Defined Message (VDM) protocol support and >>> other >>> functions as defined in the USB TypeC and USB Power Delivery >>> specifications. >>> >>> ANX7688 is found on Acer Chromebook R13 (elm) and on >>> Pine64 PinePhone. >>> >>> Signed-off-by: Dafna Hirschfeld >>> --- >>> .../bindings/usb/analogix,anx7688.yaml | 177 >>> ++ >>> 1 file changed, 177 insertions(+) >>> create mode 100644 >>> Documentation/devicetree/bindings/usb/analogix,anx7688.yaml >>> >>> diff --git a/Documentation/devicetree/bindings/usb/analogix,anx7688.yaml >>> b/Documentation/devicetree/bindings/usb/analogix,anx7688.yaml >>> new file mode 100644 >>> index ..6c4dd6b4b28b >>> --- /dev/null >>> +++ b/Documentation/devicetree/bindings/usb/analogix,anx7688.yaml >>> @@ -0,0 +1,177 @@ >>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) >>> +%YAML 1.2 >>> +--- >>> +$id: http://devicetree.org/schemas/usb/analogix,anx7688.yaml# >>> +$schema: http://devicetree.org/meta-schemas/core.yaml# >>> + >>> +title: Analogix ANX7688 Type-C Port Controller with HDMI to DP >>> conversion >>> + >>> +maintainers: >>> + - Nicolas Boichat >>> + - Enric Balletbo i Serra >>> + >>> +description: | >>> + ANX7688 is a USB Type-C port controller with a MUX. It converts HDMI >>> 2.0 to >>> + DisplayPort 1.3 Ultra-HDi (4096x2160p60). >>> + The integrated crosspoint switch (the MUX) supports USB 3.1 data >>> transfer along with >>> + the DisplayPort Alternate Mode signaling over USB Type-C. >>> Additionally, >>> + an on-chip microcontroller (OCM) is available to manage the signal >>> switching, >>> + Channel Configuration (CC) detection, USB Power Delivery (USB-PD), >>> Vendor >>> + Defined Message (VDM) protocol support and other functions as >>> defined in >>> the >>> + USB TypeC and USB Power Delivery specifications. >>> + >>> + >> >> Extra blank line ? >> >>> +properties: >>> + compatible: >>> + const: analogix,anx7688 >>> + >>> + reg: >>> + maxItems: 1 >>> + >>> + avdd33-supply: >>> + description: 3.3V Analog core supply voltage. >>> + >>> + dvdd18-supply: >>> + description: 1.8V Digital I/O supply voltage. >>> + >>> + avdd18-supply: >>> + description: 1.8V Analog core power supply voltage. >>> + >>> + avdd10-supply: >>> + description: 1.0V Analog core power supply voltage. >>> + >>> + dvdd10-supply: >>> + description: 1.0V Digital core supply voltage. >>> + >> >> That's lots of supplies. If there's a reasonable chance that some of >> them will always be driven by the same regulator (especially if the >> ANX7688 documentation requires that), then they could be grouped. For >> instance dvdd18-supply and avdd18-supply could be grouped into >> vdd18-supply. It would still allow us to extend the bindings in a >> backward compatible way later if a system uses different regulators. You >> have more information about the hardware than I do, so it's your call. >>> >>> Can you explain what do you mean by 'grouped' ? >>> Do you mean that instead of having two properties dvdd18-supply and >>> avdd18-supply >>> I have only one property vdd18-supply? >> >> You can simplify all this with vdd33, vdd18 vdd10. For the Chromebook case >> all >> the analogic and digital part are the same regulator just filtered. That's a >> common configuration and if there is some hardware that needs it we can >> extend >> later. > > That's the idea, yes. If in a typical use case multiple supplies are > provided by a single regulator (for some devices that datasheet strongly > recommends that, or event mandates it), then it makes sense to group > those supplies in a single DT supply property. It can always be extended > later indeed, without any
Re: [PATCH 4/8] drm/radeon: Implement mmap as GEM object function
On Tue, Apr 6, 2021 at 5:09 AM Thomas Zimmermann wrote:
>
> Moving the driver-specific mmap code into a GEM object function allows
> for using DRM helpers for various mmap callbacks.
>
> This change also allows to support prime-based mmap via DRM's helper
> drm_gem_prime_mmap().
>
> Permission checks are implemented by drm_gem_mmap(), with an additional
> check for radeon_ttm_tt_has_userptr() in the GEM object function. The
> function radeon_verify_access() is now unused and has thus been removed.
>
> As a side effect, amdgpu_ttm_vm_ops and amdgpu_ttm_fault() are now
> implemented in amdgpu's GEM code.
s/amdgpu/radeon/
Alex
>
> Signed-off-by: Thomas Zimmermann
> ---
> drivers/gpu/drm/radeon/radeon_drv.c | 3 +-
> drivers/gpu/drm/radeon/radeon_gem.c | 52 +++
> drivers/gpu/drm/radeon/radeon_ttm.c | 65 -
> drivers/gpu/drm/radeon/radeon_ttm.h | 1 -
> 4 files changed, 54 insertions(+), 67 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_drv.c
> b/drivers/gpu/drm/radeon/radeon_drv.c
> index efeb115ae70e..4039b6d71aa2 100644
> --- a/drivers/gpu/drm/radeon/radeon_drv.c
> +++ b/drivers/gpu/drm/radeon/radeon_drv.c
> @@ -557,7 +557,7 @@ static const struct file_operations
> radeon_driver_kms_fops = {
> .open = drm_open,
> .release = drm_release,
> .unlocked_ioctl = radeon_drm_ioctl,
> - .mmap = radeon_mmap,
> + .mmap = drm_gem_mmap,
> .poll = drm_poll,
> .read = drm_read,
> #ifdef CONFIG_COMPAT
> @@ -632,6 +632,7 @@ static const struct drm_driver kms_driver = {
> .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
> .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
> .gem_prime_import_sg_table = radeon_gem_prime_import_sg_table,
> + .gem_prime_mmap = drm_gem_prime_mmap,
>
> .name = DRIVER_NAME,
> .desc = DRIVER_DESC,
> diff --git a/drivers/gpu/drm/radeon/radeon_gem.c
> b/drivers/gpu/drm/radeon/radeon_gem.c
> index 05ea2f39f626..71e8737bce01 100644
> --- a/drivers/gpu/drm/radeon/radeon_gem.c
> +++ b/drivers/gpu/drm/radeon/radeon_gem.c
> @@ -44,6 +44,42 @@ void radeon_gem_prime_unpin(struct drm_gem_object *obj);
>
> const struct drm_gem_object_funcs radeon_gem_object_funcs;
>
> +static vm_fault_t radeon_ttm_fault(struct vm_fault *vmf)
> +{
> + struct ttm_buffer_object *bo = vmf->vma->vm_private_data;
> + struct radeon_device *rdev = radeon_get_rdev(bo->bdev);
> + vm_fault_t ret;
> +
> + down_read(&rdev->pm.mclk_lock);
> +
> + ret = ttm_bo_vm_reserve(bo, vmf);
> + if (ret)
> + goto unlock_mclk;
> +
> + ret = radeon_bo_fault_reserve_notify(bo);
> + if (ret)
> + goto unlock_resv;
> +
> + ret = ttm_bo_vm_fault_reserved(vmf, vmf->vma->vm_page_prot,
> + TTM_BO_VM_NUM_PREFAULT, 1);
> + if (ret == VM_FAULT_RETRY && !(vmf->flags & FAULT_FLAG_RETRY_NOWAIT))
> + goto unlock_mclk;
> +
> +unlock_resv:
> + dma_resv_unlock(bo->base.resv);
> +
> +unlock_mclk:
> + up_read(&rdev->pm.mclk_lock);
> + return ret;
> +}
> +
> +static const struct vm_operations_struct radeon_ttm_vm_ops = {
> + .fault = radeon_ttm_fault,
> + .open = ttm_bo_vm_open,
> + .close = ttm_bo_vm_close,
> + .access = ttm_bo_vm_access
> +};
> +
> static void radeon_gem_object_free(struct drm_gem_object *gobj)
> {
> struct radeon_bo *robj = gem_to_radeon_bo(gobj);
> @@ -226,6 +262,20 @@ static int radeon_gem_handle_lockup(struct radeon_device
> *rdev, int r)
> return r;
> }
>
> +static int radeon_gem_object_mmap(struct drm_gem_object *obj, struct
> vm_area_struct *vma)
> +{
> + struct radeon_bo *bo = gem_to_radeon_bo(obj);
> + struct radeon_device *rdev = radeon_get_rdev(bo->tbo.bdev);
> +
> + if (!rdev)
> + return -EINVAL;
> +
> + if (radeon_ttm_tt_has_userptr(rdev, bo->tbo.ttm))
> + return -EPERM;
> +
> + return drm_gem_ttm_mmap(obj, vma);
> +}
> +
> const struct drm_gem_object_funcs radeon_gem_object_funcs = {
> .free = radeon_gem_object_free,
> .open = radeon_gem_object_open,
> @@ -236,6 +286,8 @@ const struct drm_gem_object_funcs radeon_gem_object_funcs
> = {
> .get_sg_table = radeon_gem_prime_get_sg_table,
> .vmap = drm_gem_ttm_vmap,
> .vunmap = drm_gem_ttm_vunmap,
> + .mmap = radeon_gem_object_mmap,
> + .vm_ops = &radeon_ttm_vm_ops,
> };
>
> /*
> diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
> b/drivers/gpu/drm/radeon/radeon_ttm.c
> index 476ce9c24b9f..a5ce43a909a2 100644
> --- a/drivers/gpu/drm/radeon/radeon_ttm.c
> +++ b/drivers/gpu/drm/radeon/radeon_ttm.c
> @@ -136,17 +136,6 @@ static void radeon_evict_flags(struct ttm_buffer_object
> *bo,
> *placement = rbo->placement;
> }
>
> -static int radeon_verify_access(struct ttm_buffer_object *bo, struct file
> *filp)
> -{
> -
Re: [PATCH v5 1/2] dt-bindings: usb: add analogix,anx7688.yaml
On Wed, Mar 31, 2021 at 07:16:40PM +0200, Dafna Hirschfeld wrote: > Hi, > > On 05.03.21 18:24, Ondřej Jirman wrote: > > Hello Dafna, > > [...] > > > > > + vconn-en1-gpios: > > > > > +description: Controls the VCONN switch on the CC1 pin. > > > > > +maxItems: 1 > > > > > + > > > > > + vconn-en2-gpios: > > > > > +description: Controls the VCONN switch on the CC2 pin. > > > > > +maxItems: 1 > > > > VCONN is a voltage regulator that can be enabled either on CC1 or CC2 > > pin, or disabled completely. This control is *partially* performed in > > reference > > design directly by the OCM. OCM only decides which CC pin to switch > > the VCONN regulator to, and informs the SoC when the base VCONN regulator > > for the switches needs to be enabled. > > > > So vconn-en1/2 gpios are irrelevant to the driver, but the driver needs > > to control VCONN power supply somehow and defer control over it to the OCM. > > > > I don't know how to express it in the bindings. Maybe a vconn-supply here > > on the anx7688 node? > > > > It may also be part of the usb-connector binding, but this is really when it > > comes to anx7688 a parent regulator for the switches, and switches are not > > controlled by this driver, just their parent regulator is. > > > > Any ideas? > > Looking at the diagram in the schematics, I see that both vbus-supply and > vconn-supply > come directly from the PMIC so similarly to the vbus-supply, the vconn-supply > can be part of the usb-connector. Then a driver can access the vconn-supply > from the remote usb > connector. Is there a problem with that? No problem with that. usb-c-connector binding would just have to be extended. I just don't see any need for these `vconn-en*-gpios`, because the control is performed directly by the OCM firmware via GPIOs in the ANX7688 chip, outside of the control of the Linux driver, and the driver doesn't even care about the status of these pins. And if it will ever care, the status can be read via I2C from the ANX7688 chip directly. kind regards, o. > Thanks a lot for the review, I am not very familiar with usb and type-c, so > your review helps a lot. > I will send v6 soon. > > Thanks, > Dafna ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/panel: panel-dsi-cm: disable TE for now
On 06/04/2021 16:51, Thierry Reding wrote:
On Tue, Mar 16, 2021 at 04:11:30PM +0200, Tomi Valkeinen wrote:
Hi Sebastian, Sam, Thierry,
On 27/02/2021 23:45, Sebastian Reichel wrote:
From: Sebastian Reichel
Disable TE for Droid 4 panel, since implementation is currently
broken. Also disable it for N950 panel, which is untested.
Reported-by: Tony Lindgren
Reported-by: Tomi Valkeinen
Fixes: 4c1b935fea54 ("drm/omap: dsi: move TE GPIO handling into core")
Signed-off-by: Sebastian Reichel
---
I suggest to start by fix the regression like this and look into
proper Droid 4 TE support separatly. Assumption is, that Tomi
tested taal panel, droid4 panel is 'broken' and N950 (himalaya)
is untested [*], so choosing safe default. Patch is compile-tested
only.
[*] N950 display is not yet functional on mainline, since it needs
the omap3 FIFO workaround:
https://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-n900.git/commit/?h=n950-display-tony&id=d4cbc226a30b29bf258397b052c9ec68c8a3
---
drivers/gpu/drm/panel/panel-dsi-cm.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
Reviewed-by: Tomi Valkeinen
Sam, Thierry, will you pick this up or can I push to drm-misc-fixes?
Sorry, I had missed this. Feel free to take this through drm-misc
yourself:
Acked-by: Thierry Reding
Thanks! I have pushed this to drm-misc-fixes.
Tomi
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH][next] drm/msm: Fix spelling mistake "Purgable" -> "Purgeable"
On Tue, Apr 6, 2021 at 6:39 AM Colin King wrote: > > From: Colin Ian King > > There is a spelling mistake in debugfs gem stats. Fix it. Also > re-align output to cater for the extra 1 character. > > Signed-off-by: Colin Ian King > --- > drivers/gpu/drm/msm/msm_gem.c | 8 > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c > index f146d9c5ba9c..4e2e0a93d17d 100644 > --- a/drivers/gpu/drm/msm/msm_gem.c > +++ b/drivers/gpu/drm/msm/msm_gem.c > @@ -979,13 +979,13 @@ void msm_gem_describe_objects(struct list_head *list, > struct seq_file *m) > msm_gem_describe(obj, m, &stats); > } > > - seq_printf(m, "Total:%4d objects, %9zu bytes\n", > + seq_printf(m, "Total: %4d objects, %9zu bytes\n", > stats.all.count, stats.all.size); > - seq_printf(m, "Active: %4d objects, %9zu bytes\n", > + seq_printf(m, "Active:%4d objects, %9zu bytes\n", > stats.active.count, stats.active.size); > - seq_printf(m, "Purgable: %4d objects, %9zu bytes\n", > + seq_printf(m, "Purgeable: %4d objects, %9zu bytes\n", > stats.purgable.count, stats.purgable.size); oh, whoops.. I spel gud.. Thanks, applied.. I'll follow-up with fixing the spelling in the code BR, -R > - seq_printf(m, "Purged: %4d objects, %9zu bytes\n", > + seq_printf(m, "Purged:%4d objects, %9zu bytes\n", > stats.purged.count, stats.purged.size); > } > #endif > -- > 2.30.2 > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/msm: Fix spelling "purgable" -> "purgeable"
From: Rob Clark
The previous patch fixes the user visible spelling. This one fixes the
code. Oops.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem.c | 12 ++--
drivers/gpu/drm/msm/msm_gem.h | 16
drivers/gpu/drm/msm/msm_gem_shrinker.c | 2 +-
3 files changed, 15 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
index 9568d551f7de..3c0b384a8984 100644
--- a/drivers/gpu/drm/msm/msm_gem.c
+++ b/drivers/gpu/drm/msm/msm_gem.c
@@ -821,14 +821,14 @@ static void update_inactive(struct msm_gem_object
*msm_obj)
WARN_ON(msm_obj->active_count != 0);
if (msm_obj->dontneed)
- mark_unpurgable(msm_obj);
+ mark_unpurgeable(msm_obj);
list_del(&msm_obj->mm_list);
if (msm_obj->madv == MSM_MADV_WILLNEED) {
list_add_tail(&msm_obj->mm_list, &priv->inactive_willneed);
} else if (msm_obj->madv == MSM_MADV_DONTNEED) {
list_add_tail(&msm_obj->mm_list, &priv->inactive_dontneed);
- mark_purgable(msm_obj);
+ mark_purgeable(msm_obj);
} else {
WARN_ON(msm_obj->madv != __MSM_MADV_PURGED);
list_add_tail(&msm_obj->mm_list, &priv->inactive_purged);
@@ -901,8 +901,8 @@ void msm_gem_describe(struct drm_gem_object *obj, struct
seq_file *m,
madv = " purged";
break;
case MSM_MADV_DONTNEED:
- stats->purgable.count++;
- stats->purgable.size += obj->size;
+ stats->purgeable.count++;
+ stats->purgeable.size += obj->size;
madv = " purgeable";
break;
case MSM_MADV_WILLNEED:
@@ -984,7 +984,7 @@ void msm_gem_describe_objects(struct list_head *list,
struct seq_file *m)
seq_printf(m, "Active:%4d objects, %9zu bytes\n",
stats.active.count, stats.active.size);
seq_printf(m, "Purgeable: %4d objects, %9zu bytes\n",
- stats.purgable.count, stats.purgable.size);
+ stats.purgeable.count, stats.purgeable.size);
seq_printf(m, "Purged:%4d objects, %9zu bytes\n",
stats.purged.count, stats.purged.size);
}
@@ -1003,7 +1003,7 @@ void msm_gem_free_object(struct drm_gem_object *obj)
mutex_lock(&priv->mm_lock);
if (msm_obj->dontneed)
- mark_unpurgable(msm_obj);
+ mark_unpurgeable(msm_obj);
list_del(&msm_obj->mm_list);
mutex_unlock(&priv->mm_lock);
diff --git a/drivers/gpu/drm/msm/msm_gem.h b/drivers/gpu/drm/msm/msm_gem.h
index 7c7d54bad189..13ebecdd70f4 100644
--- a/drivers/gpu/drm/msm/msm_gem.h
+++ b/drivers/gpu/drm/msm/msm_gem.h
@@ -163,7 +163,7 @@ struct msm_gem_stats {
struct {
unsigned count;
size_t size;
- } all, active, purgable, purged;
+ } all, active, purgeable, purged;
};
void msm_gem_describe(struct drm_gem_object *obj, struct seq_file *m,
@@ -207,8 +207,8 @@ static inline bool is_active(struct msm_gem_object *msm_obj)
return msm_obj->active_count;
}
-/* imported/exported objects are not purgable: */
-static inline bool is_unpurgable(struct msm_gem_object *msm_obj)
+/* imported/exported objects are not purgeable: */
+static inline bool is_unpurgeable(struct msm_gem_object *msm_obj)
{
return msm_obj->base.dma_buf && msm_obj->base.import_attach;
}
@@ -216,7 +216,7 @@ static inline bool is_unpurgable(struct msm_gem_object
*msm_obj)
static inline bool is_purgeable(struct msm_gem_object *msm_obj)
{
return (msm_obj->madv == MSM_MADV_DONTNEED) && msm_obj->sgt &&
- !is_unpurgable(msm_obj);
+ !is_unpurgeable(msm_obj);
}
static inline bool is_vunmapable(struct msm_gem_object *msm_obj)
@@ -225,13 +225,13 @@ static inline bool is_vunmapable(struct msm_gem_object
*msm_obj)
return (msm_obj->vmap_count == 0) && msm_obj->vaddr;
}
-static inline void mark_purgable(struct msm_gem_object *msm_obj)
+static inline void mark_purgeable(struct msm_gem_object *msm_obj)
{
struct msm_drm_private *priv = msm_obj->base.dev->dev_private;
WARN_ON(!mutex_is_locked(&priv->mm_lock));
- if (is_unpurgable(msm_obj))
+ if (is_unpurgeable(msm_obj))
return;
if (WARN_ON(msm_obj->dontneed))
@@ -241,13 +241,13 @@ static inline void mark_purgable(struct msm_gem_object
*msm_obj)
msm_obj->dontneed = true;
}
-static inline void mark_unpurgable(struct msm_gem_object *msm_obj)
+static inline void mark_unpurgeable(struct msm_gem_object *msm_obj)
{
struct msm_drm_private *priv = msm_obj->base.dev->dev_private;
WARN_ON(!mutex_is_locked(&priv->mm_lock));
- if (is_unpurgable(msm_obj))
+ if (is_unpurgeable(msm_obj))
return;
if (WARN_ON(!
Re: [PATCH 3/8] drm/amdgpu: Implement mmap as GEM object function
Am 2021-04-06 um 9:04 a.m. schrieb Christian König: > Am 06.04.21 um 14:52 schrieb Thomas Zimmermann: >> Hi >> >> Am 06.04.21 um 14:42 schrieb Christian König: >>> Hi Thomas, >>> >>> Am 06.04.21 um 13:55 schrieb Thomas Zimmermann: Hi Am 06.04.21 um 12:56 schrieb Christian König: >> >> In the end I went with the semantics I found in amdgpu_mmap() and >> handled KFD specially. Let me know if this requires to be changed. > > Well the question is where is the call to > drm_vma_node_verify_access() now? Cause that needs to be skipped > for KFD BOs. I see. It's now drm_vma_node_is_allowed(); called by drm_gem_mmap(). [1] So drm_gem_mmap() cannot be used by amdgpu. If I understand the code at [2] correctly, KFD objects don't use the GEM ioctl interfaces, but they still use the internal GEM object that is part of the TTM BO. In this case, amdgpu could have its own version of drm_gem_mmap(), which calls drm_gem_mmap_obj(), [3] which in turn handles the mmap details via GEM object functions. >>> >>> Correct, well we could cleanup the KFD to use the GEM functions as >>> well. >> >> The KFD code already calls amdgpu_gem_object_create(). It should have >> the object-functions pointer set for use with mmap. Not sure what the >> use of drm_vma_node_is_allowed() would involve. > > The KFD allows BOs to be mmaped with different offsets than what's > used in the DRM node. > > So drm_vma_node_is_allowed() would return false as far as I know. We used to mmap KFD BOs through the /dev/kfd file descriptor. We moved that to using the /dev/dri/renderD* file descriptors a long time ago. If there is some KFD special casing left in the code for BO mmap, it's probably an oversight and we should be able to remove it. We still have a few special mmaps in /dev/kfd, but they are for things that don't involve GEM BOs that could be mmapped through the render node: doorbells, MMIO pages and CWSR trap-handler mappings for APUs. Regards, Felix > > Regards, > Christian. > >> >> Best regards >> Thomas >> >>> >>> Felix what exactly was your objections to using this? >>> >>> Regards, >>> Christian. >>> drm_gem_prime_mmap() doesn't do any additional verification. Best regards Thomas [1] https://elixir.bootlin.com/linux/v5.11.11/source/drivers/gpu/drm/drm_gem.c#L1156 [2] https://elixir.bootlin.com/linux/v5.11.11/source/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c#L1224 [3] https://elixir.bootlin.com/linux/v5.12-rc6/source/drivers/gpu/drm/drm_gem.c#L1053 > > Regards, > Christian. > >> >> Best regards >> Thomas >> - int amdgpu_copy_buffer(struct amdgpu_ring *ring, uint64_t src_offset, uint64_t dst_offset, uint32_t byte_count, struct dma_resv *resv, diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h index dec0db8b0b13..6e51faad7371 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h @@ -146,7 +146,6 @@ int amdgpu_fill_buffer(struct amdgpu_bo *bo, struct dma_resv *resv, struct dma_fence **fence); -int amdgpu_mmap(struct file *filp, struct vm_area_struct *vma); int amdgpu_ttm_alloc_gart(struct ttm_buffer_object *bo); int amdgpu_ttm_recover_gart(struct ttm_buffer_object *tbo); uint64_t amdgpu_ttm_domain_start(struct amdgpu_device *adev, uint32_t type); >>> >>> ___ >>> dri-devel mailing list >>> dri-devel@lists.freedesktop.org >>> https://lists.freedesktop.org/mailman/listinfo/dri-devel >> > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel >>> >>> ___ >>> dri-devel mailing list >>> dri-devel@lists.freedesktop.org >>> https://lists.freedesktop.org/mailman/listinfo/dri-devel >> > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/8] drm/amdgpu: Implement mmap as GEM object function
Am 2021-04-06 um 6:38 a.m. schrieb Thomas Zimmermann:
> Hi
>
> Am 06.04.21 um 11:35 schrieb Christian König:
>> Am 06.04.21 um 11:08 schrieb Thomas Zimmermann:
>>> Moving the driver-specific mmap code into a GEM object function allows
>>> for using DRM helpers for various mmap callbacks.
>>>
>>> This change resolves several inconsistencies between regular mmap and
>>> prime-based mmap. The vm_ops field in vma is now set for all mmap'ed
>>> areas. Previously it way only set for regular mmap calls, prime-based
>>> mmap used TTM's default vm_ops. The check for kfd_bo has been taken
>>> from amdgpu_verify_access(), which is not called any longer and has
>>> been removed.
>>>
>>> As a side effect, amdgpu_ttm_vm_ops and amdgpu_ttm_fault() are now
>>> implemented in amdgpu's GEM code.
>>>
>>> Signed-off-by: Thomas Zimmermann
>>> ---
>>> drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 46 -
>>> drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.h | 2 -
>>> drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 4 +-
>>> drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 64 +++
>>> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 71
>>> -
>>> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h | 1 -
>>> 6 files changed, 66 insertions(+), 122 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
>>> index e0c4f7c7f1b9..19c5ab08d9ec 100644
>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
>>> @@ -42,52 +42,6 @@
>>> #include
>>> #include
>>> -/**
>>> - * amdgpu_gem_prime_mmap - &drm_driver.gem_prime_mmap implementation
>>> - * @obj: GEM BO
>>> - * @vma: Virtual memory area
>>> - *
>>> - * Sets up a userspace mapping of the BO's memory in the given
>>> - * virtual memory area.
>>> - *
>>> - * Returns:
>>> - * 0 on success or a negative error code on failure.
>>> - */
>>> -int amdgpu_gem_prime_mmap(struct drm_gem_object *obj,
>>> - struct vm_area_struct *vma)
>>> -{
>>> - struct amdgpu_bo *bo = gem_to_amdgpu_bo(obj);
>>> - struct amdgpu_device *adev = amdgpu_ttm_adev(bo->tbo.bdev);
>>> - unsigned asize = amdgpu_bo_size(bo);
>>> - int ret;
>>> -
>>> - if (!vma->vm_file)
>>> - return -ENODEV;
>>> -
>>> - if (adev == NULL)
>>> - return -ENODEV;
>>> -
>>> - /* Check for valid size. */
>>> - if (asize < vma->vm_end - vma->vm_start)
>>> - return -EINVAL;
>>> -
>>> - if (amdgpu_ttm_tt_get_usermm(bo->tbo.ttm) ||
>>> - (bo->flags & AMDGPU_GEM_CREATE_NO_CPU_ACCESS)) {
>>> - return -EPERM;
>>> - }
>>> - vma->vm_pgoff += amdgpu_bo_mmap_offset(bo) >> PAGE_SHIFT;
>>> -
>>> - /* prime mmap does not need to check access, so allow here */
>>> - ret = drm_vma_node_allow(&obj->vma_node,
>>> vma->vm_file->private_data);
>>> - if (ret)
>>> - return ret;
>>> -
>>> - ret = ttm_bo_mmap(vma->vm_file, vma, &adev->mman.bdev);
>>> - drm_vma_node_revoke(&obj->vma_node, vma->vm_file->private_data);
>>> -
>>> - return ret;
>>> -}
>>> -
>>> static int
>>> __dma_resv_make_exclusive(struct dma_resv *obj)
>>> {
>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.h
>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.h
>>> index 39b5b9616fd8..3e93b9b407a9 100644
>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.h
>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.h
>>> @@ -31,8 +31,6 @@ struct drm_gem_object
>>> *amdgpu_gem_prime_import(struct drm_device *dev,
>>> struct dma_buf *dma_buf);
>>> bool amdgpu_dmabuf_is_xgmi_accessible(struct amdgpu_device *adev,
>>> struct amdgpu_bo *bo);
>>> -int amdgpu_gem_prime_mmap(struct drm_gem_object *obj,
>>> - struct vm_area_struct *vma);
>>> extern const struct dma_buf_ops amdgpu_dmabuf_ops;
>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
>>> index 76f48f79c70b..e96d2758f4bb 100644
>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
>>> @@ -1656,7 +1656,7 @@ static const struct file_operations
>>> amdgpu_driver_kms_fops = {
>>> .flush = amdgpu_flush,
>>> .release = drm_release,
>>> .unlocked_ioctl = amdgpu_drm_ioctl,
>>> - .mmap = amdgpu_mmap,
>>> + .mmap = drm_gem_mmap,
>>> .poll = drm_poll,
>>> .read = drm_read,
>>> #ifdef CONFIG_COMPAT
>>> @@ -1719,7 +1719,7 @@ static const struct drm_driver
>>> amdgpu_kms_driver = {
>>> .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
>>> .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
>>> .gem_prime_import = amdgpu_gem_prime_import,
>>> - .gem_prime_mmap = amdgpu_gem_prime_mmap,
>>> + .gem_prime_mmap = drm_gem_prime_mmap,
>>> .name = DRIVER_NAME,
>>> .desc = DRIVER_DESC,
>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
>>> b/drivers/gpu/drm/amd/amdgp
Re: [PATCH 2/4] drm/vram-helper: Use drm_gem_ttm_dumb_map_offset()
Hi Thomas,
I love your patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v5.12-rc6 next-20210406]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Thomas-Zimmermann/drm-Generic-dumb_map_offset-for-TTM-based-drivers/20210406-163159
base: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
0a50438c84363bd37fe18fe432888ae9a074dcab
config: arm64-allyesconfig (attached as .config)
compiler: aarch64-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
#
https://github.com/0day-ci/linux/commit/80a1349080db0bb20f1e9a9909470c09d125daab
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Thomas-Zimmermann/drm-Generic-dumb_map_offset-for-TTM-based-drivers/20210406-163159
git checkout 80a1349080db0bb20f1e9a9909470c09d125daab
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross
ARCH=arm64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
>> drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c:63:28: error:
>> 'drm_gem_vram_driver_dumb_mmap_offset' undeclared here (not in a function);
>> did you mean 'drm_gem_vram_driver_dumb_create'?
63 | .dumb_map_offset= drm_gem_vram_driver_dumb_mmap_offset,
|^~~~
|drm_gem_vram_driver_dumb_create
vim +63 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
552a77bab3ff86 Tian Tao 2020-12-04 52
70a59dd82959f8 Daniel Vetter 2020-11-04 53 static const struct drm_driver
hibmc_driver = {
5b38e7475e3dc5 Daniel Vetter 2019-01-29 54 .driver_features
= DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC,
5e0df3a08f3d17 Rongrong Zou 2016-11-16 55 .fops
= &hibmc_fops,
5e0df3a08f3d17 Rongrong Zou 2016-11-16 56 .name
= "hibmc",
5e0df3a08f3d17 Rongrong Zou 2016-11-16 57 .date
= "20160828",
5e0df3a08f3d17 Rongrong Zou 2016-11-16 58 .desc
= "hibmc drm driver",
5e0df3a08f3d17 Rongrong Zou 2016-11-16 59 .major
= 1,
5e0df3a08f3d17 Rongrong Zou 2016-11-16 60 .minor
= 0,
de2318f69366cd Thomas Zimmermann 2019-12-03 61 .debugfs_init
= drm_vram_mm_debugfs_init,
e4daebc77e7b34 Rongrong Zou 2016-11-16 62 .dumb_create
= hibmc_dumb_create,
e2f572aa9cbb30 Thomas Zimmermann 2019-05-08 @63 .dumb_map_offset
= drm_gem_vram_driver_dumb_mmap_offset,
80be7eed1d32fb Thomas Zimmermann 2019-07-02 64 .gem_prime_mmap
= drm_gem_prime_mmap,
1d98b91611725e Rongrong Zou 2016-11-16 65 .irq_handler
= hibmc_drm_interrupt,
5e0df3a08f3d17 Rongrong Zou 2016-11-16 66 };
5e0df3a08f3d17 Rongrong Zou 2016-11-16 67
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [pull] amdgpu, radeon, ttm, sched drm-next-5.13
Am 2021-04-01 um 6:29 p.m. schrieb Alex Deucher: > Hi Dave, Daniel, > > New stuff for 5.13. There are two small patches for ttm and scheduler > that were dependencies for amdgpu changes. > > The following changes since commit 2cbcb78c9ee5520c8d836c7ff57d1b60ebe8e9b7: > > Merge tag 'amd-drm-next-5.13-2021-03-23' of > https://gitlab.freedesktop.org/agd5f/linux into drm-next (2021-03-26 15:53:21 > +0100) > > are available in the Git repository at: > > https://gitlab.freedesktop.org/agd5f/linux.git > tags/amd-drm-next-5.13-2021-04-01 > > for you to fetch changes up to ef95d2a98d642a537190d73c45ae3c308afee890: > > drm/amdgpu/display: fix warning on 32 bit in dmub (2021-04-01 17:32:32 > -0400) > > > amd-drm-next-5.13-2021-04-01: > > amdgpu: > - Re-enable GPU reset on VanGogh > - Enable DPM flags for SMART_SUSPEND and MAY_SKIP_RESUME > - Disentangle HG from vga_switcheroo > - S0ix fixes > - W=1 fixes > - Resource iterator fixes > - DMCUB updates > - UBSAN fixes > - More PM API cleanup > - Aldebaran updates > - Modifier fixes > - Enable VCN load balancing with asymmetric engines > - Rework BO structs > - Aldebaran reset support > - Initial LTTPR display work > - Display MALL fixes > - Fall back to YCbCr420 when YCbCr444 fails > - SR-IOV fixes > - Misc cleanups and fixes > > radeon: > - Typo fixes > > ttm: > - Handle cached requests (required for Aldebaran) > > scheduler: > - Fix runqueue selection when changing priorities (required to fix VCN > load balancing) > > > Alex Deucher (20): > drm/amdgpu/display/dm: add missing parameter documentation > drm/amdgpu: Add additional Sienna Cichlid PCI ID > drm/amdgpu: add a dev_pm_ops prepare callback (v2) > drm/amdgpu: enable DPM_FLAG_MAY_SKIP_RESUME and DPM_FLAG_SMART_SUSPEND > flags (v2) > drm/amdgpu: disentangle HG systems from vgaswitcheroo > drm/amdgpu: rework S3/S4/S0ix state handling > drm/amdgpu: don't evict vram on APUs for suspend to ram (v4) > drm/amdgpu: clean up non-DC suspend/resume handling > drm/amdgpu: move s0ix check into amdgpu_device_ip_suspend_phase2 (v3) > drm/amdgpu: re-enable suspend phase 2 for S0ix > drm/amdgpu/swsmu: skip gfx cgpg on s0ix suspend > drm/amdgpu: update comments about s0ix suspend/resume > drm/amdgpu: drop S0ix checks around CG/PG in suspend > drm/amdgpu: skip kfd suspend/resume for S0ix > drm/amdgpu/display: restore AUX_DPHY_TX_CONTROL for DCN2.x > drm/amdgpu/display: fix memory leak for dimgrey cavefish > drm/amdgpu/pm: mark pcie link/speed arrays as const > drm/amdgpu/pm: bail on sysfs/debugfs queries during platform suspend > drm/amdgpu/vangogh: don't check for dpm in is_dpm_running when in > suspend > drm/amdgpu/display: fix warning on 32 bit in dmub > > Alex Sierra (2): > drm/amdgpu: replace per_device_list by array > drm/amdgpu: ih reroute for newer asics than vega20 > > Alvin Lee (1): > drm/amd/display: Change input parameter for set_drr > > Anson Jacob (2): > drm/amd/display: Fix UBSAN: shift-out-of-bounds warning > drm/amd/display: Removing unused code from dmub_cmd.h > > Anthony Koo (2): > drm/amd/display: [FW Promotion] Release 0.0.57 > drm/amd/display: [FW Promotion] Release 0.0.58 > > Aric Cyr (2): > drm/amd/display: 3.2.128 > drm/amd/display: 3.2.129 > > Arnd Bergmann (3): > amdgpu: avoid incorrect %hu format string > amdgpu: fix gcc -Wrestrict warning > amdgpu: securedisplay: simplify i2c hexdump output > > Bhaskar Chowdhury (6): > drm/amdgpu: Fix a typo > drm/amdgpu: Fix a typo > drm/atomic: Couple of typo fixes > drm/radeon/r600_cs: Few typo fixes > drm/amd/amdgpu/gfx_v7_0: Trivial typo fixes > drm/amd: Fix a typo in two different sentences > > Bindu Ramamurthy (1): > drm/amd/display: Allow idle optimization based on vblank. > > Chengming Gui (1): > drm/amd/amdgpu: set MP1 state to UNLOAD before reload its FW for > vega20/ALDEBARAN > > Chris Park (1): > drm/amd/display: Disable MALL when SMU not present > > Christian König (5): > drm/amdgpu: remove irq_src->data handling > drm/amdgpu: add the sched_score to amdgpu_ring_init > drm/amdgpu: share scheduler score on VCN3 instances > drm/sched: select new rq even if there is only one v3 > drm/amdgpu: load balance VCN3 decode as well v8 > > Daniel Gomez (2): > drm/amdgpu/ttm: Fix memory leak userptr pages This introduced a regression for KFD, which I pointed out at the time. Was there ever a fix for that. Regards, Felix > drm/radeon/ttm: Fix memory leak userptr pages > > David Galiffi (1): > drm/amd/display: Fixed Clock Recovery Sequence > > Dennis Li (1): > drm/amdgpu: add codes to capture invalid hardware access when recovery
