Am 23.11.22 um 01:13 schrieb Dmitry Osipenko:
The drm_sched_entity_kill() is invoked twice by drm_sched_entity_destroy()
while userspace process is exiting or being killed. First time it's invoked
when sched entity is flushed and second time when entity is released. This
causes a lockup within
> -Original Message-
> From: Fabio Estevam
> Sent: 2022年11月23日 2:09
> To: Sandor Yu
> Cc: andrzej.ha...@intel.com; neil.armstr...@linaro.org;
> robert.f...@linaro.org; laurent.pinch...@ideasonboard.com;
> jo...@kwiboo.se; jernej.skra...@gmail.com; airl...@gmail.com;
> dan...@ffwll.ch;
Hi Dave,
On Wed, 23 Nov 2022 15:35:50 +1000 David Airlie wrote:
>
> Nothing gone wrong as such, just the drm-misc-next pull request was
> sent on a regular weekly cadence, then I merged it a few days later.
> The fix for this is still in the drm-misc-next queue for the next PR
> which I will get
On 11/22/2022 3:12 PM, Dmitry Baryshkov wrote:
On sm8450 a register block was removed from MDP TOP. Accessing it during
snapshotting results in NoC errors / immediate reboot. Skip accessing
these registers during snapshot.
Tested-by: Vinod Koul
Reviewed-by: Vinod Koul
Reviewed-by: Konrad
On Wed, Nov 23, 2022 at 3:21 PM Stephen Rothwell wrote:
>
> Hi all,
>
> On Thu, 17 Nov 2022 18:32:14 +1100 Stephen Rothwell
> wrote:
> >
> > After merging the drm-misc tree, today's linux-next build (powerpc
> > ppc44x_defconfig) failed like this:
> >
> > ld: drivers/video/fbdev/core/fbmon.o:
Hi all,
On Thu, 17 Nov 2022 18:32:14 +1100 Stephen Rothwell
wrote:
>
> After merging the drm-misc tree, today's linux-next build (powerpc
> ppc44x_defconfig) failed like this:
>
> ld: drivers/video/fbdev/core/fbmon.o: in function `fb_modesetting_disabled':
> fbmon.c:(.text+0x1e4): multiple
On 23-11-2022 05:29, Matt Roper wrote:
> On Tue, Nov 22, 2022 at 12:31:26PM +0530, Aravind Iddamsetty wrote:
>> On XE_LPM+ platforms the media engines are carved out into a separate
>> GT but have a common GGTMMADR address range which essentially makes
>> the GGTT address space to be shared
Fix build when CONFIG_FB_OF=y and CONFIG_DRM_OFDRM=m.
When the latter symbol is =m, kconfig downgrades (limits) the 'select's
under FB_OF to modular (=m). This causes undefined symbol references:
powerpc64-linux-ld: drivers/video/fbdev/offb.o:(.data.rel.ro+0x58): undefined
reference to
Support generic drm-shmem memory shrinker and add new madvise IOCTL to
the VirtIO-GPU driver. BO cache manager of Mesa driver will mark BOs as
"don't need" using the new IOCTL to let shrinker purge the marked BOs on
OOM, the shrinker will also evict unpurgeable shmem BOs from memory if
guest
Lockdep warns about potential circular locking dependency of devfreq
with the fs_reclaim caused by immediate device suspension when mapping is
released by shrinker. Fix it by doing the suspension asynchronously.
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/panfrost/panfrost_mmu.c | 2 +-
Consider this scenario:
1. APP1 continuously creates lots of small GEMs
2. APP2 triggers `drop_caches`
3. Shrinker starts to evict APP1 GEMs, while APP1 produces new purgeable
GEMs
4. msm_gem_shrinker_scan() returns non-zero number of freed pages
and causes shrinker to try shrink more
5.
Introduce common drm-shmem shrinker for DRM drivers.
To start using drm-shmem shrinker drivers should do the following:
1. Implement evict() callback of GEM object where driver should check
whether object is purgeable or evictable using drm-shmem helpers and
perform the shrinking action
Replace all drm-shmem locks with a GEM reservation lock. This makes locks
consistent with dma-buf locking convention where importers are responsible
for holding reservation lock for all operations performed over dma-bufs,
preventing deadlock between dma-buf importers and exporters.
Suggested-by:
Add unlocked variants of drm_gem_un/pin() functions. These new helpers
will take care of GEM dma-reservation locking for DRM drivers.
VirtIO-GPU driver will use these helpers to pin shmem framebuffers,
preventing them from eviction during scanout.
Signed-off-by: Dmitry Osipenko
---
DMA-buf core has its own refcounting of vmaps, use it instead of drm-shmem
counting. This change prepares drm-shmem for addition of memory shrinker
support where drm-shmem will use a single dma-buf reservation lock for
all operations performed over dma-bufs.
Signed-off-by: Dmitry Osipenko
---
Replace Panfrost's custom memory shrinker with a common drm-shmem
memory shrinker.
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/drm_gem_shmem_helper.c| 2 -
drivers/gpu/drm/panfrost/Makefile | 1 -
drivers/gpu/drm/panfrost/panfrost_device.h| 4 -
Group all 1-bit boolean members of struct drm_gem_shmem_object in the end
of the structure, allowing compiler to pack data better and making code to
look more consistent.
Suggested-by: Thomas Zimmermann
Signed-off-by: Dmitry Osipenko
---
include/drm/drm_gem_shmem_helper.h | 30
Add new common evict() callback to drm_gem_object_funcs and corresponding
drm_gem_object_evict() helper. This is a first step on a way to providing
common GEM-shrinker API for DRM drivers.
Suggested-by: Thomas Zimmermann
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/drm_gem.c | 15
Ease debugging of a multi-GPU system by using drm_WARN_*() and
drm_dbg_kms() helpers that print out DRM device name corresponding
to shmem GEM.
Suggested-by: Thomas Zimmermann
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/drm_gem_shmem_helper.c | 38 +++---
1 file
Hello,
This series:
1. Makes minor fixes for drm_gem_lru and Panfrost
2. Brings refactoring for older code
3. Adds common drm-shmem memory shrinker
4. Enables shrinker for VirtIO-GPU driver
5. Switches Panfrost driver to the common shrinker
Changelog:
v9: - Replaced struct
On 11/22/2022 3:33 PM, john.c.harri...@intel.com wrote:
From: John Harrison
It was noticed that the table order verification step was only being
run once rather than once per firmware type. Fix that.
Note that the long term plan is to convert this code to be a mock
selftest. It is already
On 11/22/2022 09:54, Michal Wajdeczko wrote:
On 18.11.2022 02:58, john.c.harri...@intel.com wrote:
From: John Harrison
Re-work the existing GuC CT printers and extend as required to match
the new wrapping scheme.
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c |
On 11/22/2022 09:42, Michal Wajdeczko wrote:
On 18.11.2022 02:58, john.c.harri...@intel.com wrote:
From: John Harrison
Create a set of GuC printers and start using them.
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_guc.c| 32 --
The drm_sched_entity_kill() is invoked twice by drm_sched_entity_destroy()
while userspace process is exiting or being killed. First time it's invoked
when sched entity is flushed and second time when entity is released. This
causes a lockup within wait_for_completion(entity_idle) due to how
amdgpu_xgmi_hive_type does provide a release method which frees the allocated
"hive",
so we don't need a kfree() after a kobject_put().
Reviewed-by: Luben Tuikov
Regards,
Luben
On 2022-11-21 23:28, Liang He wrote:
> In amdgpu_get_xgmi_hive(), we should not call kfree() after
> kobject_put()
On Tue, Nov 22, 2022 at 12:31:26PM +0530, Aravind Iddamsetty wrote:
> On XE_LPM+ platforms the media engines are carved out into a separate
> GT but have a common GGTMMADR address range which essentially makes
> the GGTT address space to be shared between media and render GT. As a
> result any
On 20/11/2022 15:37, Adam Skladowski wrote:
Add required display hw catalog changes for SM6115.
Signed-off-by: Adam Skladowski
---
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 87 +++
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h| 1 +
On 20/11/2022 15:37, Adam Skladowski wrote:
Add DPU and MDSS schemas to describe MDSS and DPU blocks on the Qualcomm
SM6115 platform.
Configuration for DSI/PHY is shared with QCM2290 so compatibles are reused.
Lack of dsi phy supply in example is intended
due to fact on qcm2290, sm6115 and
On 11/22/2022 12:09 PM, john.c.harri...@intel.com wrote:
From: John Harrison
The GuC firmware includes an extra version number to specify the
submission API level. So use that rather than the main firmware
version number for submission related checks.
Also, while it is guaranteed that GuC
Enable MDSS/DPU/DSI0 on SM8450-HDK device. Note, there is no panel
configuration (yet).
Signed-off-by: Dmitry Baryshkov
---
arch/arm64/boot/dts/qcom/sm8450-hdk.dts | 22 ++
1 file changed, 22 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sm8450-hdk.dts
From: Vinod Koul
Add the LT9611uxc DSI-HDMI bridge and supplies
Signed-off-by: Vinod Koul
Reviewed-by: Konrad Dybcio
Signed-off-by: Dmitry Baryshkov
---
arch/arm64/boot/dts/qcom/sm8450-hdk.dts | 61 +
1 file changed, 61 insertions(+)
diff --git
From: Vinod Koul
Add the HDMI display nodes and link it to DSI.
Signed-off-by: Vinod Koul
Reviewed-by: Krzysztof Kozlowski
Reviewed-by: Konrad Dybcio
Signed-off-by: Dmitry Baryshkov
---
arch/arm64/boot/dts/qcom/sm8450-hdk.dts | 36 +
1 file changed, 36 insertions(+)
Add devices tree nodes describing display hardware on SM8450:
- Display Clock Controller
- MDSS
- MDP
- two DSI controllers and DSI PHYs
This does not provide support for DP controllers present on SM8450.
Reviewed-by: Konrad Dybcio
Signed-off-by: Dmitry Baryshkov
---
Add another power saving state used on SM8450. Unfortunately adding it
in proper place causes renumbering of all the opp states in sm8450.dtsi
Reviewed-by: Konrad Dybcio
Signed-off-by: Dmitry Baryshkov
---
arch/arm64/boot/dts/qcom/sm8450.dtsi | 20
Add device tree nodes for MDSS, DPU and DSI devices on Qualcomm SM8450
platform. Enable these devices and add the HDMI bridge configuration on
SM8450 HDK.
Changes since v1:
- Reorder properties, making status the last one
- Rename opp nodes to follow the schema
- Renamed display-controller and
From: John Harrison
It was noticed that the table order verification step was only being
run once rather than once per firmware type. Fix that.
Note that the long term plan is to convert this code to be a mock
selftest. It is already only compiled in when selftests are enabled.
And the work
On 11/8/2022 12:52 AM, Ville Syrjälä wrote:
On Mon, Nov 07, 2022 at 07:34:43PM -0800, Rob Clark wrote:
On Mon, Nov 7, 2022 at 4:22 PM Jessica Zhang wrote:
On 11/7/2022 2:09 PM, Rob Clark wrote:
On Mon, Nov 7, 2022 at 1:32 PM Jessica Zhang wrote:
On 11/7/2022 11:37 AM, Ville Syrjälä
On 11/22/2022 12:09 PM, john.c.harri...@intel.com wrote:
From: John Harrison
As a precursor to a coming change (for adding a GuC submission API
version), abstract the UC version number into its own private
structure separate to the firmware filename.
Signed-off-by: John Harrison
On 11/22/2022 12:09 PM, john.c.harri...@intel.com wrote:
From: John Harrison
The way delimieters (underscores and dots) were added to the UC
filenames was different for different types of delimter. Rationalise
delimiter misspelled twice. Apart from this, it's a simple cleanup, so:
Add support for the MDSS block on SM8450 platform.
Tested-by: Vinod Koul
Reviewed-by: Vinod Koul
Reviewed-by: Konrad Dybcio
Reviewed-by: Abhinav Kumar
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/msm_mdss.c | 5 +
1 file changed, 5 insertions(+)
diff --git
SM8350 and SM8450 use 5nm DSI PHYs, which share register definitions
with 7nm DSI PHYs. Rather than duplicating the driver, handle 5nm
variants inside the common 5+7nm driver.
Co-developed-by: Robert Foss
Tested-by: Vinod Koul
Reviewed-by: Vinod Koul
Signed-off-by: Dmitry Baryshkov
---
Add definitions for the display hardware used on Qualcomm SM8450
platform.
Tested-by: Vinod Koul
Reviewed-by: Vinod Koul
Reviewed-by: Konrad Dybcio
Signed-off-by: Dmitry Baryshkov
---
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 224 ++
SM8350 and SM8450 platforms use the same driver and same bindings as the
existing 7nm DSI PHYs. Add corresponding compatibility strings.
Signed-off-by: Dmitry Baryshkov
---
Documentation/devicetree/bindings/display/msm/dsi-phy-7nm.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git
Add DPU and MDSS schemas to describe MDSS and DPU blocks on the Qualcomm
SM8450 platform.
Signed-off-by: Dmitry Baryshkov
---
.../bindings/display/msm/qcom,sm8450-dpu.yaml | 139 +++
.../display/msm/qcom,sm8450-mdss.yaml | 352 ++
2 files changed, 491 insertions(+)
Mark clock-names property as required to be used on all MDSS devices.
Signed-off-by: Dmitry Baryshkov
---
Documentation/devicetree/bindings/display/msm/mdss-common.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/display/msm/mdss-common.yaml
On sm8450 a register block was removed from MDP TOP. Accessing it during
snapshotting results in NoC errors / immediate reboot. Skip accessing
these registers during snapshot.
Tested-by: Vinod Koul
Reviewed-by: Vinod Koul
Reviewed-by: Konrad Dybcio
Signed-off-by: Dmitry Baryshkov
---
Add support for DSI 2.6.0 (block used on sm8450).
Tested-by: Vinod Koul
Reviewed-by: Vinod Koul
Reviewed-by: Konrad Dybcio
Reviewed-by: Abhinav Kumar
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dsi/dsi_cfg.c | 2 ++
drivers/gpu/drm/msm/dsi/dsi_cfg.h | 1 +
2 files changed, 3
In preparation to adding the sm8350 and sm8450 PHYs support, rearrange
register values calculations in dsi_7nm_phy_enable(). This change bears
no functional changes itself, it is merely a preparation for the next
patch.
Signed-off-by: Dmitry Baryshkov
---
Per Krzysztof's request, move a clause requiring 'compatible' property to
the file where it is formally defined.
Signed-off-by: Dmitry Baryshkov
---
Documentation/devicetree/bindings/display/msm/mdss-common.yaml | 1 -
.../devicetree/bindings/display/msm/qcom,msm8998-mdss.yaml | 3 +++
This adds support for the MDSS/DPU/DSI on the Qualcomm SM8450 platform.
Dependencies for the DT bindings: [1].
[1]
https://lore.kernel.org/all/20221024164225.3236654-1-dmitry.barysh...@linaro.org/
Change since v3:
- Reworked the dpu-common.yaml / mdss-common.yaml to require properties
from
Per Krzysztof's request, move a clause requiring certain properties to
the file where they are declared.
Signed-off-by: Dmitry Baryshkov
---
.../devicetree/bindings/display/msm/dpu-common.yaml| 4
.../devicetree/bindings/display/msm/qcom,msm8998-dpu.yaml | 7 +++
On 11/10/2022 16:56, Daniele Ceraolo Spurio wrote:
The fence is always initialized in huc_init_early, but the cleanup in
huc_fini is only being run if HuC is enabled. This causes a leaking of
the debug object when HuC is disabled/not supported, which can in turn
trigger a warning if we try to
On 11/22/2022 12:52 PM, Rodrigo Vivi wrote:
On Mon, Nov 21, 2022 at 03:16:16PM -0800, Daniele Ceraolo Spurio wrote:
From: Jonathan Cavitt
The GSC CS is only used for communicating with the GSC FW, so no need to
initialize it if we're not going to use the FW. If we're not using
neither the
From: John Harrison
There was a report of error captures occurring without any hung
context being indicated despite the capture being initiated by a 'hung
context notification' from GuC. The problem was not reproducible.
However, it is possible to happen if the context in question has no
active
On 11/22/2022 12:46 PM, Rodrigo Vivi wrote:
On Mon, Nov 21, 2022 at 03:16:15PM -0800, Daniele Ceraolo Spurio wrote:
If the GSC was loaded, the only way to stop it during the driver unload
flow is to do a driver-FLR.
The driver-FLR is not the same as PCI config space FLR in that
it doesn't
On Tue, Nov 22, 2022 at 03:17:14PM +0200, Jani Nikula wrote:
Introduce stricter rules for topic/core-for-CI management. Way too many
commits have been added over the years, with insufficient rationale
recorded in the commit message, and insufficient follow-up with removing
the commits from the
result of using
> b4 and the web endpoint:
> https://lore.kernel.org/dri-devel/20221122-gud-shadow-plane-v1-0-9de3afa33...@tronnes.org/
>
> Patchwork gave me a new submitter ID:
> https://patchwork.freedesktop.org/series/111222/
Oooh, I see that patchwork is still not doing the right
t;, line 231, in dumps
> return _default_encoder.encode(obj)
> File "/usr/lib/python3.10/json/encoder.py", line 199, in encode
> chunks = self.iterencode(o, _one_shot=True)
> File "/usr/lib/python3.10/json/encoder.py", line 257, in iterencode
> retu
From: Noralf Trønnes
Use the shadow plane helper to take care of preparing the framebuffer for
CPU access. The synchronous flushing is now done inline without the use of
a worker. The async path now uses a shadow buffer to hold framebuffer
changes and it doesn't read the framebuffer behind
From: Noralf Trønnes
In preparation for inlining synchronous flushing split out the part of
gud_flush_work() that can be shared by the sync and async code paths.
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/gud/gud_pipe.c | 72 +++---
1 file changed,
From: Noralf Trønnes
In preparation for moving to the shadow plane helper prepare the
framebuffer for CPU access as early as possible.
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/gud/gud_pipe.c | 67 +-
1 file changed, 33 insertions(+), 34
: 7257702951305b1f0259c3468c39fc59d1ad4d8b
change-id: 20221122-gud-shadow-plane-ae37a95d4d8d
Best regards,
--
Noralf Trønnes
On Tue, Nov 22, 2022 at 11:39:31AM -0800, Ceraolo Spurio, Daniele wrote:
>
>
> On 11/22/2022 11:01 AM, Rodrigo Vivi wrote:
> > On Mon, Nov 21, 2022 at 03:16:14PM -0800, Daniele Ceraolo Spurio wrote:
> > > GSC FW is loaded by submitting a dedicated command via the GSC engine.
> > > The memory
From: Noralf Trønnes
UBSAN complains about invalid value for bool:
[ 101.165172] [drm] Initialized gud 1.0.0 20200422 for 2-3.2:1.0 on minor 1
[ 101.213360] gud 2-3.2:1.0: [drm] fb1: guddrmfb frame buffer device
[ 101.213426] usbcore: registered new interface driver gud
[ 101.989431]
From: Noralf Trønnes
If a framebuffer flush fails the driver will do one retry by requeing the
worker. Currently the worker is used even for synchronous flushing, but a
later patch will inline it, so this needs to change. Thinking about how to
solve this I came to the conclusion that this retry
From: Noralf Trønnes
Complete the shadow fb access functions by also preparing imported buffers
for CPU access. Update the affected drivers that currently use
drm_gem_fb_begin_cpu_access().
Through this change the following SHMEM drivers will now also make sure
their imported buffers are
On Mon, Nov 21, 2022 at 03:16:17PM -0800, Daniele Ceraolo Spurio wrote:
> Now that we have the GSC FW support code as a user to the GSC CS, we
> can add the relevant flag to the engine mask. Note that the engine will
> still be disabled until we define the GSC FW binary file.
>
> Signed-off-by:
On Mon, Nov 21, 2022 at 03:16:16PM -0800, Daniele Ceraolo Spurio wrote:
> From: Jonathan Cavitt
>
> The GSC CS is only used for communicating with the GSC FW, so no need to
> initialize it if we're not going to use the FW. If we're not using
> neither the engine nor the microcontoller, then we
On Mon, Nov 21, 2022 at 03:16:15PM -0800, Daniele Ceraolo Spurio wrote:
> If the GSC was loaded, the only way to stop it during the driver unload
> flow is to do a driver-FLR.
> The driver-FLR is not the same as PCI config space FLR in that
> it doesn't reset the SGUnit and doesn't modify the PCI
Thanks Stan for the explanation,
With that
Reviewed-by: Manasi Navare
Manasi
-Original Message-
From: Lisovskiy, Stanislav
Sent: Tuesday, November 22, 2022 2:40 AM
To: Navare, Manasi D
Cc: intel-...@lists.freedesktop.org; Saarinen, Jani ;
Nikula, Jani ;
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: 771a207d1ee9f38da8c0cee1412228f18b900bac Add linux-next specific
files for 20221122
Error/Warning reports:
https://lore.kernel.org/oe-kbuild-all/202211130053.np70vidn-...@intel.com
https
Passing the GT rather than uncore to the lowest level MCR read and write
functions will make it easier to introduce dedicated MCR locking in a
folling patch.
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_gt_mcr.c | 18 ++
1 file changed, 10 insertions(+), 8
We've been overloading uncore->lock to protect access to the MCR
steering register. That's not really what uncore->lock is intended for,
and it would be better if we didn't need to hold such a high-traffic
spinlock for the whole sequence of (apply steering, access MCR register,
restore steering).
The kerneldoc function name was not updated when this function was
converted to a non-fw form.
Fixes: 192bb40f030a ("drm/i915/gt: Manage uncore->lock while waiting on MCR
register")
Reported-by: kernel test robot
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_gt_mcr.c | 2 +-
1
Starting with MTL, the driver needs to not only protect the steering
control register from simultaneous software accesses, but also protect
against races with hardware/firmware agents. The hardware provides a
dedicated locking mechanism to support this via the STEER_SEMAPHORE
register. Reading
We've been overloading uncore->lock to protect access to the MCR
steering register. That's not really what uncore->lock is intended for,
and it would be better if we didn't need to hold such a high-traffic
spinlock for the whole sequence of (apply steering, access MCR register,
restore steering).
On Tue, 22 Nov 2022, "Ceraolo Spurio, Daniele"
wrote:
> On 11/22/2022 1:03 AM, Jani Nikula wrote:
>> On Mon, 21 Nov 2022, Daniele Ceraolo Spurio
>> wrote:
>>> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.h
>>> b/drivers/gpu/drm/i915/gt/uc/intel_uc.h
>>> index a8f38c2c60e2..5d0f1bcc381e
From: John Harrison
The GuC firmware includes an extra version number to specify the
submission API level. So use that rather than the main firmware
version number for submission related checks.
Also, while it is guaranteed that GuC version number components are
only 8-bits in size, other
From: John Harrison
The way delimieters (underscores and dots) were added to the UC
filenames was different for different types of delimter. Rationalise
them to all be done the same way - implicitly in the concatenation
macro rather than explicitly in the file name prefix.
Signed-off-by: John
From: John Harrison
As a precursor to a coming change (for adding a GuC submission API
version), abstract the UC version number into its own private
structure separate to the firmware filename.
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_uc.c| 6 +-
From: John Harrison
Start using the 'submission API version' for deciding which GuC API to
use in the submission code.
Correct version number manipulation code to support full 32bit
major/minor/patch components, except for GuC which is guaranteed to be
8bit safe.
Other minor code clean ups
Document RZ/V2L DSI bindings. RZ/V2L MIPI DSI is identical to one found on
the RZ/G2L SoC. No driver changes are required as generic compatible
string "renesas,rzg2l-mipi-dsi" will be used as a fallback.
Signed-off-by: Biju Das
---
.../devicetree/bindings/display/bridge/renesas,dsi.yaml
On Tue, 22 Nov 2022 at 20:34, Jason Gunthorpe wrote:
> On Tue, Nov 22, 2022 at 08:29:05PM +0100, Daniel Vetter wrote:
> > You nuke all the ptes. Drivers that move have slightly more than a
> > bare struct file, they also have a struct address_space so that
> > invalidate_mapping_range() works.
>
On Sun, 20 Nov 2022 at 21:51, syzbot
wrote:
>
> syzbot has bisected this issue to:
>
> commit 997acaf6b4b59c6a9c259740312a69ea549cc684
> Author: Mark Rutland
> Date: Mon Jan 11 15:37:07 2021 +
>
> lockdep: report broken irq restoration
Ok this looks funny. I'm pretty sure the code in
On 11/22/2022 1:03 AM, Jani Nikula wrote:
On Mon, 21 Nov 2022, Daniele Ceraolo Spurio
wrote:
On MTL the GSC FW needs to be loaded on the media GT by the graphics
driver. We're going to treat it like a new uc_fw, so add the initial
defs and init/fini functions for it.
Similarly to the
On 11/22/2022 11:01 AM, Rodrigo Vivi wrote:
On Mon, Nov 21, 2022 at 03:16:14PM -0800, Daniele Ceraolo Spurio wrote:
GSC FW is loaded by submitting a dedicated command via the GSC engine.
The memory area used for loading the FW is then re-purposed as local
memory for the GSC itself, so we use
On Tue, Nov 22, 2022 at 08:29:05PM +0100, Daniel Vetter wrote:
> You nuke all the ptes. Drivers that move have slightly more than a
> bare struct file, they also have a struct address_space so that
> invalidate_mapping_range() works.
Okay, this is one of the ways that this can be made to work
On Tue, 22 Nov 2022 at 19:50, Jason Gunthorpe wrote:
>
> On Tue, Nov 22, 2022 at 07:08:25PM +0100, Daniel Vetter wrote:
> > On Tue, 22 Nov 2022 at 19:04, Jason Gunthorpe wrote:
> > >
> > > On Tue, Nov 22, 2022 at 06:08:00PM +0100, Daniel Vetter wrote:
> > > > tldr; DMA buffers aren't normal
Den 22.11.2022 19.50, skrev Konstantin Ryabitsev:
> On Tue, Nov 22, 2022 at 06:42:19PM +0100, Noralf Trønnes wrote:
>> The first thing that strikes me is that everyone mentioned in one of the
>> patches get the entire patchset, even sta...@vger.kernel.org (cc'ed in a
>> fixes patch). The first
The structs drm_debugfs_info and drm_debugfs_entry introduced a new
debugfs structure to DRM, centered on drm_device instead of drm_minor.
Therefore, remove the tasks related to create a new device-centered
debugfs structure and add a new task to replace the use of
drm_debugfs_create_files() for
Replace the use of drm_debugfs_create_files() with the new
drm_debugfs_add_files() function, which centers the debugfs files
management on the drm_device instead of drm_minor.
Signed-off-by: Maíra Canal
---
drivers/gpu/drm/vkms/vkms_drv.c | 10 +-
1 file changed, 5 insertions(+), 5
Currently, vc4 has its own debugfs infrastructure that adds the debugfs
files on drm_dev_register(). With the introduction of the new debugfs,
functions, replace the vc4 debugfs structure with the DRM debugfs
device-centered function, drm_debugfs_add_file().
Signed-off-by: Maíra Canal
---
Replace the use of drm_debugfs_create_files() with the new
drm_debugfs_add_files() function, which centers the debugfs files
management on the drm_device instead of drm_minor.
Signed-off-by: Maíra Canal
---
drivers/gpu/drm/v3d/v3d_debugfs.c | 22 ++
1 file changed, 10
Introduce the ability to track requests for the addition of DRM debugfs
files at any time and have them added all at once during
drm_dev_register().
Drivers can add DRM debugfs files to a device-managed list and, during
drm_dev_register(), all added files will be created at once.
Now, the
Replace the use of drm_debugfs_create_files() with the new
drm_debugfs_add_files() function in all DRM core files, centering the
debugfs files management on the drm_device instead of drm_minor.
Signed-off-by: Maíra Canal
---
drivers/gpu/drm/drm_atomic.c | 11 +--
This series introduces the initial structure to make DRM debugfs more
device-centered and it is the first step to drop the
drm_driver->debugfs_init hooks in the future [1].
Currently, DRM debugfs files are created using drm_debugfs_create_files()
on request. The first patch of this series makes
On Mon, Nov 21, 2022 at 03:16:14PM -0800, Daniele Ceraolo Spurio wrote:
> GSC FW is loaded by submitting a dedicated command via the GSC engine.
> The memory area used for loading the FW is then re-purposed as local
> memory for the GSC itself, so we use a separate allocation instead of
> using
This reverts commit 2ef6efa79fecd5e3457b324155d35524d95f2b6b.
Checking the presence if the IRST (Intel Rapid Start Technology)
through the ACPI to decide whether to rebuild or not the GGTT
puts us at the mercy of the boot firmware and we need to
unnecessarily rely on third parties.
Because now
From: Chris Wilson
VT-d may cause overfetch of the scanout PTE, both before and after the
vma (depending on the scanout orientation). bspec recommends that we
provide a tile-row in either directions, and suggests using 168 PTE,
warning that the accesses will wrap around the ends of the GGTT.
From: Chris Wilson
Introduce the concept of padding the i915_vma with guard pages before
and after. The major consequence is that all ordinary uses of i915_vma
must use i915_vma_offset/i915_vma_size and not i915_vma.node.start/size
directly, as the drm_mm_node will include the guard pages that
1 - 100 of 200 matches
Mail list logo
