Rectify multiple kernel-doc warnings in dcn32_fpu.c.
E.g.:
drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn32/dcn32_fpu.c:247: warning:
This comment starts with '/**', but isn't a kernel-doc comment. Refer
Documentation/doc-guide/kernel-doc.rst
* Finds dummy_latency_index when MCLK switching
Add mediatek av1 decoder linux driver which use the stateless API in
MT8195.
Signed-off-by: Xiaoyong Lu
---
Changes from v4:
- convert vb2_find_timestamp to vb2_find_buffer
- test by av1 fluster, result is 173/239
Changes from v3:
- modify comment for struct vdec_av1_slice_slot
- add define SEG
drm_mode_config_init() simply calls drmm_mode_config_init(), hence
cleanup is automatically handled through registering
drm_mode_config_cleanup() with drmm_add_action_or_reset().
While at it, get rid of the deprecated drm_mode_config_init() and
replace it with drmm_mode_config_init() directly.
Si
(Hardware) resources which are bound to the driver and device lifecycle
must not be accessed after the device and driver are unbound.
However, the DRM device isn't freed as long as the last user didn't
close it, hence userspace can still call into the driver.
Therefore protect the critical sectio
When the driver is unbound, there might still be users in userspace
having an open fd and are calling into the driver.
While this is fine for drm managed resources, it is not for resources
bound to the device/driver lifecycle, e.g. clocks or MMIO mappings.
To prevent use-after-free issues we need
(Hardware) resources which are bound to the driver and device lifecycle
must not be accessed after the device and driver are unbound.
However, the DRM device isn't freed as long as the last user didn't
close it, hence userspace can still call into the driver.
Therefore protect the critical sectio
Use drm managed resource allocation (drmm_universal_plane_alloc()) in
order to get rid of the explicit destroy hook in struct drm_plane_funcs.
Signed-off-by: Danilo Krummrich
---
drivers/gpu/drm/arm/hdlcd_crtc.c | 20 +++-
1 file changed, 7 insertions(+), 13 deletions(-)
diff --
Using drm_device->dev_private is deprecated. Since we've switched to
devm_drm_dev_alloc(), struct drm_device is now embedded in struct
hdlcd_drm_private, hence we can use container_of() to get the struct
drm_device instance instead.
Signed-off-by: Danilo Krummrich
---
drivers/gpu/drm/arm/hdlcd_c
Use drm managed resources to allocate driver structures and get rid of
the deprecated drm_dev_alloc() call and replace it with
devm_drm_dev_alloc().
This also serves as preparation to get rid of drm_device->dev_private
and to fix use-after-free issues on driver unload.
Signed-off-by: Danilo Krumm
Hi,
This patch series converts the driver to use drm managed resources to prevent
potential use-after-free issues on driver unbind/rebind and to get rid of the
usage of deprecated APIs.
Changes in v2:
- drop patch "drm/arm/hdlcd: crtc: use drmm_crtc_init_with_planes()"
Changes in v3:
- Fix a
Hi Liviu,
On 9/30/22 18:56, Liviu Dudau wrote:
On Wed, Sep 14, 2022 at 12:03:58AM +0200, Danilo Krummrich wrote:
Do you mind trying again with my v2 (although v2 shouldn't make a difference
for this issue) and provide the back-trace when it hangs?
Hi Danilo,
I've finally got a replacement J
On Xe_HP the fault registers are now in a multicast register range.
However as part of the GAM these registers follow special rules and we
need only read from the "primary" GAM's instance to get the information
we need. So a single intel_gt_mcr_read_any() (which will automatically
steer to the pri
Rather than using the same _MMIO() macro to define MCR registers as
singleton registers, let's use a new MCR_REG() macro to make it clear
that these registers are special and should be handled accordingly. For
now MCR_REG() will still generate an i915_reg_t with the given offset,
but we'll change
Rather than relying on the implicit behavior of intel_uncore_*()
functions, let's always use the intel_gt_mcr_*() functions to operate on
multicast/replicated registers.
v2:
- Add TLB invalidation registers
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_gt.c| 42 ++
MCR registers can be placed on the GuC's save/restore list, but at the
moment they are always handled in a multicast manner (i.e., the GuC
reads one instance to save the value and then does a multicast write to
restore that single value to all instances). In the future the GuC will
probably give u
Rather than treating multicast registers as 'i915_reg_t' let's define
them as a completely new type. This will allow the compiler to help us
make sure we're using multicast-aware functions to operate on multicast
registers.
This plan does break down a bit in places where we're just maintaining
he
There are cases where we wish to read from any non-terminated MCR
register instance (or the primary instance in the case of GAM ranges),
clear/set some bits, and then write the value back out to the register
in a multicast manner. Adding a "multicast RMW" will avoid the need to
open-code this.
Si
We have a few registers that have existed for several hardware
generations, but are only used by the driver on Xe_HP and beyond. In
cases where the Xe_HP version of the register is now replicated and uses
multicast behavior, but earlier generations were singleton, let's change
the register prefix
MTL once again changes the multicast register types and steering
details. Key changes from past platforms:
* The number of instances of some MCR types (NODE, OAAL2, and GAM) vary
according to the MTL subplatform and cannot be read from fuse
registers.
* The MCR steering register (and its b
Let's be more explicit about which of our workarounds are updating MCR
registers.
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 428 +++---
.../gpu/drm/i915/gt/intel_workarounds_types.h | 4 +-
2 files changed, 261 insertions(+), 171 deletions(-)
di
Xe_HP has some MCR registers that need to be polled for completion of
operations like TLB invalidation. Those registers are in the GAM range,
which rolls up the status from each unit into the 'primary' instance's
value. This makes it useful to have a dedicated 'wait for register'
function that ha
MTL's media GT only has a single type of steering ("OAADDRM") which
selects between media slice 0 and media slice 1. We'll always steer to
media slice 0 unless it is fused off (which is the case when VD0, VE0,
and SFC0 are all reported as unavailable).
Bspec: 67789
Signed-off-by: Matt Roper
---
Let's drop a few register definitions that are unused anywhere in the
driver today. Since the referenced offsets are part of what is now
considered a multicast register region, the current definitions would
not be correct for use on any future platform.
Signed-off-by: Matt Roper
---
drivers/gpu
Gen8 was the first time our hardware had multicast registers (or at
least the first time the multicast nature was exposed and MMIO accesses
could be steered). There are some registers that transitioned from
singleton behavior to multicast during the gen7 -> gen8 transition;
let's duplicate the reg
Starting in Xe_HP, several registers our driver works with have been
converted from singleton registers into replicated registers with
multicast behavior. Although the registers are still located at the
same MMIO offsets as on previous platforms, let's duplicate the register
definitions in prepara
Steering of multicast/replicated registers becomes a bit more
complicated on Meteor Lake. Whereas previously the control register we
used to manage the steering was only used by our driver[*], software's
control of steering has now been consolidated with the controls for
various other hardware/fir
Create a wrapper to print out the frequency debugfs for
SLPC and non-SLPC cases. Most of the RPS related information
is no longer valid when SLPC is enabled.
Signed-off-by: Vinay Belgaumkar
---
drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c | 157 +-
drivers/gpu/drm/i915/gt/intel_rps.
On 9/22/2022 15:11, Daniele Ceraolo Spurio wrote:
The media GT shares the G-unit with the root GT, so a second set of
communication registers is required for the media GuC.
Signed-off-by: Daniele Ceraolo Spurio
Cc: John Harrison
Cc: Alan Previn
Reviewed-by: John Harrison
---
drivers/gpu
On 9/30/2022 4:24 PM, John Harrison wrote:
On 9/22/2022 15:11, Daniele Ceraolo Spurio wrote:
Our current FW loading process is the same for all FWs:
- Pin FW to GGTT at the start of the ggtt->uc_fw node
- Load the FW
- Unpin
This worked because we didn't have a case where 2 FWs would be l
On 9/22/2022 15:11, Daniele Ceraolo Spurio wrote:
From: Stuart Summers
MTL supports GuC deprivilege. Add the feature flag to this platform.
Signed-off-by: Stuart Summers
Cc: Radhakrishna Sripada
Cc: John Harrison
Cc: Alan Previn
Reviewed-by: John Harrison
---
drivers/gpu/drm/i915/i91
The pull request you sent on Sat, 1 Oct 2022 00:19:28 +0200:
> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2022-10-01
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/ffb4d94b4314655cea60ab7962756e6bab72fc7e
Thank you!
--
Deet-doot-dot, I am a bot.
https://ko
On 9/22/2022 15:11, Daniele Ceraolo Spurio wrote:
Our current FW loading process is the same for all FWs:
- Pin FW to GGTT at the start of the ggtt->uc_fw node
- Load the FW
- Unpin
This worked because we didn't have a case where 2 FWs would be loaded on
the same GGTT at the same time. On MT
On 9/22/2022 15:11, Daniele Ceraolo Spurio wrote:
The FW binaries are independently loaded on each GT. On MTL, the memory
is shared so we could potentially re-use a single allocation, but on
discrete multi-gt platforms we are going to need independent copies,
so it is easier to do the same on MTL
On Fri, Sep 30, 2022 at 05:04:54PM -0400, Alex Deucher wrote:
> Hi Dave, Daniel,
>
> Sorry, some last minute changes to deal with updated firmwares/bioses and
> board revisions containing new IPs added in this cycle. It required
> pulling in some cleanup patches for the RLC firmware handing, but
Hi Linus,
As Alex mentioned already, here's some last minute amd fixes that would be
nice to also include in the final release.
drm-fixes-2022-10-01:
amdgpu:
- VCN 4.x and GC 11.x fixes, mostly around fw
Cheers, Daniel
The following changes since commit 6643b3836f3908c4f77883b2fae72451e85cf3ca
On Wed, Sep 28, 2022 at 03:20:52PM +0530, Balasubramani Vivekanandan wrote:
> On 19.09.2022 15:32, Matt Roper wrote:
> > Starting in Xe_HP, several registers our driver works with have been
> > converted from singleton registers into replicated registers with
> > multicast behavior. Although the r
Hi Dmitry,
On 9/1/2022 11:40 PM, Dmitry Baryshkov wrote:
On 2 September 2022 02:09:24 GMT+03:00, Jessica Zhang
wrote:
From: Rohith Iyer
Add writeback support to modetest with the below options:
- Passing in -c will now also show the writeback connector
- Test a built-in mode on writeba
On Thu, 29 Sep 2022 14:48:35 -0300
Jason Gunthorpe wrote:
> When converting to directly create the vfio_device the mdev driver has to
> put a vfio_register_emulated_iommu_dev() in the probe() and a pairing
> vfio_unregister_group_dev() in the remove.
>
> This was missed for gvt, add it.
>
> Cc:
On Fri, Sep 30, 2022 at 01:20:50PM +0200, Krzysztof Kozlowski wrote:
> On 30/09/2022 13:15, Thierry Reding wrote:
> > On Fri, Sep 30, 2022 at 12:51:07PM +0200, Krzysztof Kozlowski wrote:
> >> On 29/09/2022 19:05, Diogo Ivo wrote:
> >>> The Google Pixel C has a JDI LPM102A188A display panel. Add a
>
Hello,
Il giorno mar 20 set 2022 alle ore 13:59 Salvatore Bonaccorso
ha scritto:
[..]
> Computer Enthusiastic, can you verify the problem as well in a
> non-Debian patched upstream kernel directly from the 5.10.y series
> (latest 5.10.144) and verify the fix there?
>
> Regards,
> Salvatore
I've
Hi Dave, Daniel,
Sorry, some last minute changes to deal with updated firmwares/bioses and
board revisions containing new IPs added in this cycle. It required
pulling in some cleanup patches for the RLC firmware handing, but they
are only applied to GC 11 in this case. I figured that would be cl
On Fri, Sep 30, 2022 at 09:58:10AM -0400, Alex Deucher wrote:
> Hi Dave, Daniel,
>
> Sorry, some last minute changes to deal with updated firmwares/bioses and
> board revisions containing new IPs added in this cycle. It required
> pulling in some cleanup patches for the RLC firmware handing, but
The variable 'count' is introduced in this commit
'commit f64122c1f6ad("drm: add new QXL driver. (v1.4)")'
However, since introduced it was just iterated and never been used.
Remove it for code cleaning.
Signed-off-by: Chen Zhongjin
---
drivers/gpu/drm/qxl/qxl_cmd.c | 3 +--
1 file changed, 1 i
'commit 1e5df24b996c ("drm/msm/dpu: drop length from struct
dpu_hw_blk_reg_map")'
'commit 9403f9a42c88 ("drm/msm/dpu: merge base_off with blk_off in struct
dpu_hw_blk_reg_map")'
These commits had merged hw.blk_off and hw.blk_off to mdp.
So we don't need to get dpu_hw_mdp in dpu_kms_mdp_snapshot()
Am 30.09.22 um 17:39 schrieb Matthew Auld:
Touching bo->resource looks like it should require first locking the
object, since this state is dynamic and could potentially change from
under us.
Signed-off-by: Matthew Auld
Cc: Christian König
---
drivers/gpu/drm/ttm/ttm_bo_vm.c | 9 +
Add support for the Sony TD4353 JDI 2160x1080 display panel used in
some Sony Xperia XZ2 and XZ2 Compact smartphones. Due to the specifics
of smartphone manufacturing, it is impossible to retrieve a better name
for this panel.
This revision adds support for the default 60 Hz configuration, however
Add bindings for the display panel used on some Sony Xperia XZ2 and XZ2
Compact smartphones.
Signed-off-by: Konrad Dybcio
---
Changes since v2:
- preset -> panel-reset
- treset -> touch-reset
.../display/panel/sony,td4353-jdi.yaml| 82 +++
1 file changed, 82 insertions(+)
On Thu, Sep 29, 2022 at 10:09:03PM -0700, Lucas De Marchi wrote:
> Different handling for XeHP and later platforms should be using the
> xehp prefix, not gen125. Rename them.
>
> Signed-off-by: Lucas De Marchi
Reviewed-by: Matt Roper
> ---
> drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 24
On Thu, Sep 29, 2022 at 10:09:02PM -0700, Lucas De Marchi wrote:
> It's no obviously clear how the encode/decode of the per platform tables
This should probably say "...not obvious..." or "...not clear..."
Otherwise,
Reviewed-by: Matt Roper
> is done. Document it so while adding tables for new
On Thu, Sep 29, 2022 at 10:09:01PM -0700, Lucas De Marchi wrote:
> ce->wa_bb_page is allocated only for graphics version 12. However
> __gen125_emit_bb_start() is used for any graphics version >= 12.50. For
> the currently supported platforms this is not an issue, but for future
> ones there's a mi
On 9/30/2022 02:22, Tvrtko Ursulin wrote:
On 29/09/2022 17:21, John Harrison wrote:
On 9/29/2022 00:42, Tvrtko Ursulin wrote:
On 29/09/2022 03:18, john.c.harri...@intel.com wrote:
From: John Harrison
Compute workloads are inherently not pre-emptible for long periods on
current hardware. As a
On Wed, Sep 14, 2022 at 12:03:58AM +0200, Danilo Krummrich wrote:
> On 9/13/22 10:58, Liviu Dudau wrote:
> > On Mon, Sep 12, 2022 at 09:50:26PM +0200, Danilo Krummrich wrote:
> > > Hi Liviu,
> >
> > Hi Danilo,
> >
> > >
> > > Thanks for having a look!
> > >
> > > This is not about this patch, i
On Tue, Sep 27, 2022 at 11:20:17AM +0530, Badal Nilawar wrote:
> From: Dale B Stimson
>
> Use i915 HWMON to display device level energy input.
>
> v2: Updated the date and kernel version in feature description
> v3:
> - Cleaned up hwm_energy function and removed unused function
> i915_hwmo
On Fri, Sep 30, 2022 at 11:45:34AM +0100, Matthew Auld wrote:
On 28/09/2022 07:19, Niranjana Vishwanathapura wrote:
The new execbuf3 ioctl path and the legacy execbuf ioctl
paths have many common functionalities.
Abstract out the common execbuf functionalities into a
separate file where possible
Hi Dave, Daniel,
A few fixes for 6.1.
The following changes since commit 3e43b760c9e14fc0b7bd553efb01d9ca825cf338:
drm/amdgpu: Fix amdgpu_vm_pt_free warning (2022-09-21 15:25:52 -0400)
are available in the Git repository at:
https://gitlab.freedesktop.org/agd5f/linux.git
tags/amd-drm-next
On Fri, Sep 30, 2022 at 5:27 PM Pekka Paalanen wrote:
>
> On Fri, 30 Sep 2022 17:44:17 +0300
> Ville Syrjälä wrote:
>
> > On Fri, Sep 30, 2022 at 04:20:29PM +0200, Sebastian Wick wrote:
> > > On Fri, Sep 30, 2022 at 9:40 AM Pekka Paalanen
> > > wrote:
> > > >
> > > > On Thu, 29 Sep 2022 20:06:5
On Fri, Sep 30, 2022 at 11:01:17AM +0100, Matthew Auld wrote:
On 28/09/2022 07:19, Niranjana Vishwanathapura wrote:
Add getparam support for VM_BIND capability version.
Add VM creation time flag to enable vm_bind_mode for the VM.
Signed-off-by: Niranjana Vishwanathapura
Signed-off-by: Andi Shy
On Fri, Sep 30, 2022 at 06:45:09PM +0300, Ville Syrjälä wrote:
> On Fri, Sep 30, 2022 at 06:37:00PM +0300, Pekka Paalanen wrote:
> > On Fri, 30 Sep 2022 18:09:55 +0300
> > Ville Syrjälä wrote:
> >
> > > That would actively discourage people from even attempting the
> > > "just dump all the state
On Fri, Sep 30, 2022 at 06:37:00PM +0300, Pekka Paalanen wrote:
> On Fri, 30 Sep 2022 18:09:55 +0300
> Ville Syrjälä wrote:
>
> > That would actively discourage people from even attempting the
> > "just dump all the state into the ioctl" approach with async flips
> > since even the props whose va
Touching bo->resource looks like it should require first locking the
object, since this state is dynamic and could potentially change from
under us.
Signed-off-by: Matthew Auld
Cc: Christian König
---
drivers/gpu/drm/ttm/ttm_bo_vm.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
On 9/30/2022 4:56 PM, Christian König wrote:
Am 30.09.22 um 10:48 schrieb Arvind Yadav:
BUG: kernel NULL pointer dereference, address: 0088
#PF: supervisor read access in kernel mode
#PF: error_code(0x) - not-present page
PGD 0 P4D 0
Oops: [#1] PREEMPT SMP NOPTI
On Fri, 30 Sep 2022 18:09:55 +0300
Ville Syrjälä wrote:
> That would actively discourage people from even attempting the
> "just dump all the state into the ioctl" approach with async flips
> since even the props whose value isn't even changing would be rejected.
About that.
To me it looks like
The pull request you sent on Fri, 30 Sep 2022 10:12:45 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2022-09-30-1
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/5a77386984b513ebfb2700e70dac44509fc81aa9
Thank you!
--
Deet-doot-dot, I am a bot.
https:/
The drm_atomic_helper_damage_merged() helper merges all the damage clips
into one rectangle. If there are multiple damage clips that aren't close
to each other, the resulting rectangle could be quite big.
Instead of using that function helper, iterate over all the damage clips
and update them one
On Fri, 30 Sep 2022 17:44:17 +0300
Ville Syrjälä wrote:
> On Fri, Sep 30, 2022 at 04:20:29PM +0200, Sebastian Wick wrote:
> > On Fri, Sep 30, 2022 at 9:40 AM Pekka Paalanen wrote:
> >
> > >
> > > On Thu, 29 Sep 2022 20:06:50 +0200
> > > Sebastian Wick wrote:
> > >
> > > > If it is supposed
On Thu, Sep 29, 2022 at 8:13 PM Dave Airlie wrote:
>
> Hi Linus,
>
> Last set of fixes for 6.0 hopefully, minor bridge fixes, i915 fixes,
> and a bunch of amdgpu fixes for new IP blocks, along with a couple of
> regression fixes. Hopefully all set for merge window next week.
>
> Dave.
Dave,
Actu
On Fri, Sep 30, 2022 at 05:19:07PM +0300, Ville Syrjälä wrote:
> On Fri, Sep 30, 2022 at 04:52:56PM +0300, Ville Syrjälä wrote:
> > On Thu, Sep 29, 2022 at 06:43:15PM +, Simon Ser wrote:
> > > This series adds support for DRM_MODE_PAGE_FLIP_ASYNC for atomic
> > > commits, aka. "immediate flip"
https://bugzilla.kernel.org/show_bug.cgi?id=213145
Taras (haltu...@gmail.com) changed:
What|Removed |Added
CC||haltu...@gmail.com
--- Comme
Applied. Thanks.
On Thu, Sep 29, 2022 at 10:04 AM Yang Yingliang
wrote:
>
> In some error path in amdgpu_sdma_init_microcode(), release_firmware() is
> not called, the memory allocated in request_firmware() will be leaked,
> calling amdgpu_sdma_destroy_inst_ctx() which calls release_firmware() t
Applied. Thanks!
On 2022-09-25 17:53, Daniel Gomez wrote:
Removal of DC_FP_* wrappers from dml (9696679bf7ac) provokes a mutex
lock [2] on the amdgpu driver. Re-arrange the dcn10 code to avoid
locking the mutex by placing the DC_FP_* wrappers around the proper
functions.
This fixes the followin
On 30.09.2022 11:47, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Patch which added graceful exit for non-persistent contexts missed the
fact it is not enough to set the exiting flag on a context and let the
backend handle it from there.
GuC backend cannot handle it because it runs independently
On Friday, September 30th, 2022 at 16:44, Ville Syrjälä
wrote:
> On Fri, Sep 30, 2022 at 04:20:29PM +0200, Sebastian Wick wrote:
>
> > On Fri, Sep 30, 2022 at 9:40 AM Pekka Paalanen ppaala...@gmail.com wrote:
> >
> > > On Thu, 29 Sep 2022 20:06:50 +0200
> > > Sebastian Wick sebastian.w...@redh
Applied the series. Thanks!
On Fri, Sep 30, 2022 at 1:39 AM Yang Li wrote:
>
> clean up one inconsistent indenting
>
> Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=2321
> Reported-by: Abaci Robot
> Signed-off-by: Yang Li
> ---
> drivers/gpu/drm/amd/display/dc/dcn301/dcn301_resource.c
Den 29.09.2022 18.30, skrev Maxime Ripard:
> As the number of kunit tests in KMS grows further, we start to have
> multiple test suites that, for example, need to register a mock DRM
> driver to interact with the KMS function they are supposed to test.
>
> Let's add a file meant to provide thos
On Fri, Sep 30, 2022 at 04:20:29PM +0200, Sebastian Wick wrote:
> On Fri, Sep 30, 2022 at 9:40 AM Pekka Paalanen wrote:
> >
> > On Thu, 29 Sep 2022 20:06:50 +0200
> > Sebastian Wick wrote:
> >
> > > If it is supposed to be a non-linear luminance curve, which one is it?
> > > It would be much clea
On Sat, Sep 24, 2022 at 6:20 PM Li Zhong wrote:
>
> amdgpu_bo_kmap() returns error when fails to map buffer object. Add the
> error check and propagate the error.
>
> Signed-off-by: Li Zhong
> ---
>
> v2: revise the compile error
Applied. Thanks!
>
> drivers/gpu/drm/amd/pm/legacy-dpm/kv_dpm.c
Applied. Thanks!
Alex
On Thu, Sep 29, 2022 at 4:46 AM Yang Yingliang wrote:
>
> enc314_stream_encoder_dp_blank is only used in dcn314_dio_stream_encoder.c
> now,
> change it to static.
>
> Fixes: c9c2ff53cc20 ("drm/amd/display: Add explicit FIFO disable for DP
> blank")
> Signed-off-by: Yang
On Fri, 30 Sep 2022, Sebastian Wick wrote:
> On Fri, Sep 30, 2022 at 9:40 AM Pekka Paalanen wrote:
>>
>> On Thu, 29 Sep 2022 20:06:50 +0200
>> Sebastian Wick wrote:
>>
>> > If it is supposed to be a non-linear luminance curve, which one is it?
>> > It would be much clearer if user space can cont
Hi Rob,
On 09:14-20220930, Rob Herring wrote:
> On Fri, Sep 30, 2022 at 8:29 AM Rahul T R wrote:
> >
> > Property name for DisplayPort regulator is not matching in
> > the binding and the driver implementation. Fix the same
> > in the binding
> >
> > Si
Hi,
On Thu, Sep 29, 2022 at 9:25 PM Jason Yen
wrote:
>
> This chip can not handle aux defer if the host directly program
> its aux registers to access edid/dpcd. So we need let software
> to handle the aux defer situation.
>
> Signed-off-by: Jason Yen
> ---
>
> Changes in v2:
> - Add aux defer h
On Fri, Sep 30, 2022 at 9:40 AM Pekka Paalanen wrote:
>
> On Thu, 29 Sep 2022 20:06:50 +0200
> Sebastian Wick wrote:
>
> > If it is supposed to be a non-linear luminance curve, which one is it?
> > It would be much clearer if user space can control linear luminance
> > and use whatever definition
On Fri, Sep 30, 2022 at 04:52:56PM +0300, Ville Syrjälä wrote:
> On Thu, Sep 29, 2022 at 06:43:15PM +, Simon Ser wrote:
> > This series adds support for DRM_MODE_PAGE_FLIP_ASYNC for atomic
> > commits, aka. "immediate flip" (which might result in tearing).
> > The feature was only available via
On Fri, Sep 30, 2022 at 8:29 AM Rahul T R wrote:
>
> Property name for DisplayPort regulator is not matching in
> the binding and the driver implementation. Fix the same
> in the binding
>
> Signed-off-by: Rahul T R
> Reported-by: Nishanth Menon
> ---
> .../devicetree/bindings/display/connector
On 9/12/22 11:59, Maíra Canal wrote:
> From: Tales Aparecida
>
> The fixed31_32 library performs a lot of the mathematical operations
> involving fixed-point arithmetic and the conversion of integers to
> fixed-point representation.
>
> This unit tests intend to assure the proper functioning
On Fri, Sep 30, 2022 at 01:56:25PM +, Simon Ser wrote:
> On Friday, September 30th, 2022 at 15:53, Ville Syrjälä
> wrote:
>
> > > diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > > b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > > index 44235345fd57..7500e82cf06a 1
Hi Dave, Daniel,
Sorry, some last minute changes to deal with updated firmwares/bioses and
board revisions containing new IPs added in this cycle. It required
pulling in some cleanup patches for the RLC firmware handing, but they
are only applied to GC 11 in this case. I figured that would be cl
On Friday, September 30th, 2022 at 15:53, Ville Syrjälä
wrote:
> > diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > index 44235345fd57..7500e82cf06a 100644
> > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > +
On Thu, Sep 29, 2022 at 06:43:15PM +, Simon Ser wrote:
> This series adds support for DRM_MODE_PAGE_FLIP_ASYNC for atomic
> commits, aka. "immediate flip" (which might result in tearing).
> The feature was only available via the legacy uAPI, however for
> gaming use-cases it may be desirable to
On Thu, Sep 29, 2022 at 06:43:42PM +, Simon Ser wrote:
> This new field indicates whether the driver has the necessary logic
> to support async page-flips via the atomic uAPI. This is leveraged by
> the next commit to allow user-space to use this functionality.
>
> All atomic drivers setting d
On 2022-09-30 07:51, Christian König wrote:
Am 29.09.22 um 21:20 schrieb Andrey Grodzovsky:
On 2022-09-29 09:21, Christian König wrote:
This was buggy because when we had to wait for entities which were
killed as well we would just deadlock.
Instead move all the dependency handling into the
On 9/29/22 14:43, Simon Ser wrote:
> This series adds support for DRM_MODE_PAGE_FLIP_ASYNC for atomic
> commits, aka. "immediate flip" (which might result in tearing).
> The feature was only available via the legacy uAPI, however for
> gaming use-cases it may be desirable to enable it via the at
Thanks for helping with review and good improvement ideas.
Pushed to drm-misc-next.
Andrey
On 2022-09-30 00:12, Luben Tuikov wrote:
From: Andrey Grodzovsky
When many entities are competing for the same run queue
on the same scheduler, we observe an unusually long wait
times and some jobs get
Fix the property name of displayport pwr in dp connector
nodes
Signed-off-by: Rahul T R
Reported-by: Nishanth Menon
---
arch/arm64/boot/dts/ti/k3-j721e-common-proc-board.dts | 2 +-
arch/arm64/boot/dts/ti/k3-j721e-sk.dts| 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
d
Fix the miss match in the binding and driver implementation for
dp power supply regulator property. Also fix it in the dp-connector
node instances in dt files
Rahul T R (2):
dt-bindings: dp-connector: Fix the property name for dp pwr
arm64: dts: ti: k3-j721e-*: Fix the property name for dp pwr
Property name for DisplayPort regulator is not matching in
the binding and the driver implementation. Fix the same
in the binding
Signed-off-by: Rahul T R
Reported-by: Nishanth Menon
---
.../devicetree/bindings/display/connector/dp-connector.yaml | 2 +-
1 file changed, 1 insertion(+), 1 de
In drm_atomic_helper_check_crtc_state(), do not add a new plane state
to the global state if it does not exist already. Adding a new plane
state will result in overhead for the plane during the atomic-commit
step.
For the test in drm_atomic_helper_check_crtc_state() to succeed, it
is important tha
Well this won't be fixed on older kernel like 5.4 or 5.15.
You at least need something like 5.19 and even then you need to look
into backporting that stuff.
Regards,
Christian.
Am 30.09.22 um 04:05 schrieb Chien, WenChieh (Jay):
[AMD Official Use Only - General]
Hi Christian
This looks on
Hi Niranjana,
On Tue, Sep 27, 2022 at 11:19:10PM -0700, Niranjana Vishwanathapura wrote:
> Do not use i915_vma activeness tracking for persistent vmas.
>
> As persistent vmas are part of working set for each execbuf
> submission on that address space (VM), a persistent vma is
> active if the VM a
Am 29.09.22 um 21:20 schrieb Andrey Grodzovsky:
On 2022-09-29 09:21, Christian König wrote:
This was buggy because when we had to wait for entities which were
killed as well we would just deadlock.
Instead move all the dependency handling into the callbacks so that
will all happen asynchronous
Den 29.09.2022 18.31, skrev Maxime Ripard:
> The TV mode property has been around for a while now to select and get the
> current TV mode output on an analog TV connector.
>
> Despite that property name being generic, its content isn't and has been
> driver-specific which makes it hard to build
1 - 100 of 148 matches
Mail list logo
