Sending myself a pull request just to keep the process going. This is
some misc nouveau patches Ben has queued up, been good to land them in
-next.
Dave.
topic/nouveau-misc-2022-07-13-1:
drm/nouveau next misc
This is a set of misc nouveau patches skeggsb left queued up, just
flushing some of
On Tue, 2022-07-12 at 10:56 +0300, Pekka Paalanen wrote:
> On Mon, 11 Jul 2022 23:32:43 -0400
> Zack Rusin wrote:
>
> > From: Zack Rusin
> >
> > Atomic modesetting got support for mouse hotspots via the hotspot
> > properties. Port the legacy kms hotspot handling to the new properties
> > on
From: allen chen
Use i2c bus to read/write when it6505 power off will occur i2c error.
Add this check will prevent i2c error when it6505 power off.
Signed-off-by: Pin-Yen Lin
Signed-off-by: Allen Chen
Reviewed-by: Robert Foss
---
drivers/gpu/drm/bridge/ite-it6505.c | 12 ++--
1 file
live_rps_control is failing in BAT on a TGL. Increase the
time we wait for actual frequency to change, and see if this
is just a matter of slowness.
Bug: https://gitlab.freedesktop.org/drm/intel/-/issues/1759
Signed-off-by: Vinay Belgaumkar
---
drivers/gpu/drm/i915/gt/selftest_rps.c | 3 ++-
1
Hi Lee,
Thanks for your reply.
Lee Jones 於 2022年7月12日 週二 晚上11:29寫道：
>
> On Thu, 23 Jun 2022, ChiaEn Wu wrote:
>
> > From: ChiYuan Huang
> >
> > Add Mediatek MT6370 MFD support.
>
> No such thing as "MFD support".
>
> And you're not getting away with submitting a 370 line patch with a 5
> word
From: John Harrison
A bunch of code was copy/pasted using pr_err as the default way to
report errors. However, drm_err is significantly more useful in
identifying where the error came from. So update the code to use that
instead.
Signed-off-by: John Harrison
---
On Tue, Jul 12, 2022 at 04:31:31PM -0700, john.c.harri...@intel.com wrote:
> From: Michał Winiarski
>
> Since we're going to use semaphores in selftests (and eventually in
> regular GuC submission), let's route semaphores to GuC.
I don't think this comment isn't correct, we have no plans to use
On Tue, Jul 12, 2022 at 04:31:33PM -0700, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> It is no longer guaranteed that there will always be an RCS engine.
> So, use the helper function for finding the first available engine that
> can be used for general purpose selftets.
>
>
On Tue, Jul 12, 2022 at 04:31:36PM -0700, john.c.harri...@intel.com wrote:
> From: Alan Previn
>
> Add a helper to get GuC log buffer size.
>
> Signed-off-by: Alan Previn
John - you need to add a Signed-off-by since you posted.
Patch LGTM:
Reviewed-by: Matthew Brost
> ---
>
From: John Harrison
It is no longer guaranteed that there will always be an RCS engine.
So, use the helper function for finding the first available engine that
can be used for general purpose selftets.
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 12
From: Matthew Brost
The engine registers really shouldn't be touched during GuC submission
as the GuC owns the registers. Don't call ring_is_idle and tie
intel_engine_is_idle strictly to the engine pm.
Because intel_engine_is_idle tied to the engine pm, retire requests
before checking
From: Matthew Brost
The GuC needs a copy of a golden context for implementing watchdog
resets (aka media resets). This context is larger on newer platforms.
So adjust the size being allocated/copied accordingly.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c | 10
From: John Harrison
It is useful to be able to match GuC events to kernel events when
looking at the GuC log. That requires being able to convert GuC
timestamps to kernel time. So, when dumping error captures and/or GuC
logs, include a stamp in both time zones plus the clock frequency.
From: John Harrison
When the KMD sends a CLIENT_RESET request to GuC (as part of the
suspend sequence), GuC will mark the CTB buffer as 'UNUSED'. If the
KMD then checked the CTB queue, it would see a non-zero status value
and report the buffer as corrupted.
Technically, no G2H messages should
From: Matthew Brost
Remove bogus GEM_BUG_ON which compared kernel context timeline seqno to
seqno in memory on engine PM unpark. If a GT reset occurred these values
might not match as a kernel context could be skipped. This bug was
hidden by always switching to a kernel context on park
From: John Harrison
When debugging GuC communication issues, it is useful to have the CTB
info available. So add the state and buffer contents to the error
capture log.
Also, add a sub-structure for the GuC specific error capture info as
it is now becoming numerous.
Signed-off-by: John
From: Chris Wilson
Use a temporary page and mempy_from_wc to reduce the time it takes to
dump the guc log to debugfs.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/uc/intel_guc_log.c | 24 --
1 file changed, 18 insertions(+), 6 deletions(-)
diff --git
From: Michał Winiarski
Since we're going to use semaphores in selftests (and eventually in
regular GuC submission), let's route semaphores to GuC.
Signed-off-by: Michał Winiarski
---
drivers/gpu/drm/i915/gt/uc/intel_guc_reg.h| 4
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
From: Alan Previn
Add a helper to get GuC log buffer size.
Signed-off-by: Alan Previn
---
drivers/gpu/drm/i915/gt/uc/intel_guc_log.c | 49 --
1 file changed, 27 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
From: Rahul Kumar Singh
Add a test to check that the hangcheck will recover from a submission
hang in the GuC.
Signed-off-by: Rahul Kumar Singh
---
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 1 +
.../drm/i915/gt/uc/selftest_guc_hangcheck.c | 159 ++
From: John Harrison
Pushing a bunch of patches which had gotten forgotten about.
Signed-off-by: John Harrison
Alan Previn (1):
drm/i915/guc: Add a helper for log buffer size
Chris Wilson (1):
drm/i915/guc: Use streaming loads to speed up dumping the guc log
John Harrison (4):
From: Matthew Brost
Having semaphores results in different behavior when a dependent request
is cancelled. In the case of semaphores the request could be on the HW
and complete successfully while without the request is held in the
driver and the error from the dependent request is propagated.
The new display engine uses floating point math, which is not supported
by KCOV. Commit 9d1d02ff3678 ("drm/amd/display: Don't build DCN1 when kcov
is enabled") tried to work around the problem by disabling
CONFIG_DRM_AMD_DC_DCN if KCOV_INSTRUMENT_ALL and KCOV_ENABLE_COMPARISONS
are enabled. The
Accidental use of a "SLICE" macro where a "SUBSLICE" macro was intended
causes the group ID for steering to be calculated incorrectly on
pre-Xe_HP platforms.
Fixes: 9a92732f040a ("drm/i915/gt: Add general DSS steering iterator to
intel_gt_mcr")
Signed-off-by: Matt Roper
---
On Tue, Jul 12, 2022 at 04:21:33PM +0100, Mauro Carvalho Chehab wrote:
> From: Chris Wilson
>
> Avoid trying to invalidate the TLB in the middle of performing an
> engine reset, as this may result in the reset timing out. Currently,
> the TLB invalidate is only serialised by its own mutex,
On 7/12/2022 1:10 PM, Dmitry Baryshkov wrote:
On Tue, 12 Jul 2022 at 22:15, Abhinav Kumar wrote:
On 7/12/2022 3:00 AM, Dmitry Baryshkov wrote:
On Tue, 12 Jul 2022 at 01:39, Abhinav Kumar wrote:
On 7/11/2022 2:43 AM, Dmitry Baryshkov wrote:
Currently the DSI driver has two separate
On 12/07/2022 22:50, Konrad Dybcio wrote:
>
>
> On 12.07.2022 22:47, Krzysztof Kozlowski wrote:
>> On 12/07/2022 22:02, Konrad Dybcio wrote:
>>> Add bindings for the display panel used on some Sony Xperia XZ2 and XZ2
>>> Compact smartphones.
>>>
>>> Signed-off-by: Konrad Dybcio
>>> ---
>>>
On 12.07.2022 22:47, Krzysztof Kozlowski wrote:
> On 12/07/2022 22:02, Konrad Dybcio wrote:
>> Add bindings for the display panel used on some Sony Xperia XZ2 and XZ2
>> Compact smartphones.
>>
>> Signed-off-by: Konrad Dybcio
>> ---
>> .../display/panel/sony,td4353-jdi.yaml| 84
On 12/07/2022 22:02, Konrad Dybcio wrote:
> Add bindings for the display panel used on some Sony Xperia XZ2 and XZ2
> Compact smartphones.
>
> Signed-off-by: Konrad Dybcio
> ---
> .../display/panel/sony,td4353-jdi.yaml| 84 +++
> 1 file changed, 84 insertions(+)
>
I'll ask around to see if there's some DMI property we can match in
order to detect whether a system is expected to use the EC backlight
driver: if so, maybe we can avoid the WMI interactions in patch 16/29 of
this series. Although I suppose even if there were a DMI property, we'd
still need
Thanks, Hans:
On 7/12/22 14:38, Hans de Goede wrote:
On some new laptop designs a new Nvidia specific WMI interface is present
which gives info about panel brightness control and may allow controlling
the brightness through this interface when the embedded controller is used
for brightness
On Tue, 12 Jul 2022 at 22:15, Abhinav Kumar wrote:
>
>
>
> On 7/12/2022 3:00 AM, Dmitry Baryshkov wrote:
> > On Tue, 12 Jul 2022 at 01:39, Abhinav Kumar
> > wrote:
> >>
> >>
> >>
> >> On 7/11/2022 2:43 AM, Dmitry Baryshkov wrote:
> >>> Currently the DSI driver has two separate paths: one if the
From: Jiangshan Yi
Fix the following coccicheck warning:
drivers/base/component.c:544: WARNING opportunity for min().
drivers/base/component.c:740: WARNING opportunity for min().
min() macro is defined in include/linux/minmax.h. It avoids
multiple evaluations of the arguments when non-constant
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,
Add bindings for the display panel used on some Sony Xperia XZ2 and XZ2
Compact smartphones.
Signed-off-by: Konrad Dybcio
---
.../display/panel/sony,td4353-jdi.yaml| 84 +++
1 file changed, 84 insertions(+)
create mode 100644
On 7/12/2022 3:13 AM, Dmitry Baryshkov wrote:
On Tue, 12 Jul 2022 at 01:54, Abhinav Kumar wrote:
On 7/11/2022 3:39 PM, Abhinav Kumar wrote:
On 7/11/2022 2:43 AM, Dmitry Baryshkov wrote:
Currently the DSI driver has two separate paths: one if the next device
in a chain is a bridge
On Thu, 16 Jun 2022 21:50:55 -0700, Dixit, Ashutosh wrote:
>
> On Thu, 16 Jun 2022 15:01:59 -0700, Zhanjun Dong wrote:
> >
> > We are seeing error message of "No response for request". Some cases
> > happened while waiting for response and reset/suspend action was triggered.
> > In this case, no
Add an entry summarizing the discussion about dealing with brightness
control on devices with more then 1 internal panel.
The original discussion can be found here:
https://lore.kernel.org/dri-devel/20220517152331.16217-1-hdego...@redhat.com/
Signed-off-by: Hans de Goede
---
acpi_backlight=native is the default for these, but as the comment
explains the quirk was still necessary because even briefly registering
the acpi_video0 backlight; and then unregistering it once the native
driver showed up, was leading to issues.
After the "ACPI: video: Make backlight class
The video_detect_dmi_table[] uses an unusual indentation for
before the ".name = ..." named struct initializers.
Instead of being indented with an extra tab compared to
the previous line's '{' these are indented to with only
a single space to allow for long DMI_MATCH() lines without
wrapping.
acpi_backlight=native is the default for the "Samsung X360", but as
the comment explains the quirk was still necessary because even
briefly registering the acpi_video0 backlight; and then unregistering
it once the native driver showed up, was leading to issues.
After the "ACPI: video: Make
acpi_video_set_dmi_backlight_type() is troublesome because it may end
up getting called after other backlight drivers have already called
acpi_video_get_backlight_type() resulting in the other drivers
already being registered even though they should not.
In case of the acpi_video backlight,
Remove the asus-wmi quirk_entry.wmi_backlight_native quirk-flag, which
called acpi_video_set_dmi_backlight_type(acpi_backlight_native) and replace
it with acpi/video_detect.c video_detect_dmi_table[] entries using the
video_detect_force_native callback.
acpi_video_set_dmi_backlight_type() is
acpi_video_set_dmi_backlight_type() is troublesome because it may end up
getting called after other backlight drivers have already called
acpi_video_get_backlight_type() resulting in the other drivers
already being registered even though they should not.
Move all the
Remove the asus-wmi quirk_entry.wmi_backlight_power quirk-flag, which
called acpi_video_set_dmi_backlight_type(acpi_backlight_vendor) and replace
it with acpi/video_detect.c video_detect_dmi_table[] entries using the
video_detect_force_vendor callback.
acpi_video_set_dmi_backlight_type() is
Remove this check from the asus-wmi backlight handling:
/* Some Asus desktop boards export an acpi-video backlight interface,
stop this from showing up */
chassis_type = dmi_get_system_info(DMI_CHASSIS_TYPE);
if (chassis_type && !strcmp(chassis_type, "3"))
acpi_video_set_dmi_backlight_type() is troublesome because it may end up
getting called after other backlight drivers have already called
acpi_video_get_backlight_type() resulting in the other drivers
already being registered even though they should not.
In case of the acpi_video backlight,
Move the backlight DMI quirks to acpi/video_detect.c, so that
the driver no longer needs to call acpi_video_set_dmi_backlight_type().
acpi_video_set_dmi_backlight_type() is troublesome because it may end up
getting called after other backlight drivers have already called
Now that acpi_video_get_backlight_type() has apple-gmux detection (using
apple_gmux_present()), it is no longer necessary for the apple-gmux code
to manually remove possibly conflicting drivers.
So remove the handling for this from the apple-gmux driver.
Signed-off-by: Hans de Goede
---
On Apple laptops with an Apple GMUX using this for brightness control,
should take precedence of any other brightness control methods.
Add apple-gmux detection to acpi_video_get_backlight_type() using
the already existing apple_gmux_present() helper function.
This will allow removig the (ab)use
On some new laptop designs a new Nvidia specific WMI interface is present
which gives info about panel brightness control and may allow controlling
the brightness through this interface when the embedded controller is used
for brightness control.
When this WMI interface is present and indicates
Refactor acpi_video_get_backlight_type() so that the heuristics /
detection steps are stricly in order of descending precedence.
Also move the comments describing the steps to when the various steps are
actually done, to avoid the comments getting out of sync with the code.
Signed-off-by: Hans
Typically the acpi_video driver will initialize before radeon, which
used to cause /sys/class/backlight/acpi_video0 to get registered and then
radeon would register its own radeon_bl# device later. After which
the drivers/acpi/video_detect.c code unregistered the acpi_video0 device
to avoid there
Typically the acpi_video driver will initialize before nouveau, which
used to cause /sys/class/backlight/acpi_video0 to get registered and then
nouveau would register its own nv_backlight device later. After which
the drivers/acpi/video_detect.c code unregistered the acpi_video0 device
to avoid
Typically the acpi_video driver will initialize before amdgpu, which
used to cause /sys/class/backlight/acpi_video0 to get registered and then
amdgpu would register its own amdgpu_bl# device later. After which
the drivers/acpi/video_detect.c code unregistered the acpi_video0 device
to avoid there
Remove the code to unregister acpi_video backlight devices when
a native backlight device gets registered later.
Now that the acpi_video backlight device registration is a separate step
which runs later, after the drm/kms driver is done setting up its own
native backlight device, it is no longer
On machins without an i915 opregion the acpi_video driver immediately
probes the ACPI video bus and used to also immediately register
acpi_video# backlight devices when supported.
Once the drm/kms driver then loaded later and possibly registered
a native backlight device then the
When acpi_video_register() has not run yet the video_bus_head will be
empty, so there is no need to check the register_count flag first.
Signed-off-by: Hans de Goede
---
drivers/acpi/acpi_video.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git
On x86/ACPI boards the acpi_video driver will usually initializing before
the kms driver (except i915). This causes /sys/class/backlight/acpi_video0
to show up and then the kms driver registers its own native backlight
device after which the drivers/acpi/video_detect.c code unregisters
the
All x86/ACPI kms drivers which register native/BACKLIGHT_RAW type
backlight devices call acpi_video_backlight_use_native() now. This sets
__acpi_video_get_backlight_type()'s internal static native_available flag.
This makes the backlight_device_get_by_type(BACKLIGHT_RAW) check
unnecessary.
Move the list_del removing an acpi_video_bus from video_bus_head
on teardown to before the teardown is done, to avoid code iterating
over the video_bus_head list seeing acpi_video_bus objects on there
which are (partly) torn down already.
Signed-off-by: Hans de Goede
---
Before this commit when we want userspace to use the acpi_video backlight
device we register both the GPU's native backlight device and acpi_video's
firmware acpi_video# backlight device. This relies on userspace preferring
firmware type backlight devices over native ones.
Registering 2 backlight
Before this commit when we want userspace to use the acpi_video backlight
device we register both the GPU's native backlight device and acpi_video's
firmware acpi_video# backlight device. This relies on userspace preferring
firmware type backlight devices over native ones.
Registering 2 backlight
Before this commit when we want userspace to use the acpi_video backlight
device we register both the GPU's native backlight device and acpi_video's
firmware acpi_video# backlight device. This relies on userspace preferring
firmware type backlight devices over native ones.
Registering 2 backlight
Before this commit when we want userspace to use the acpi_video backlight
device we register both the GPU's native backlight device and acpi_video's
firmware acpi_video# backlight device. This relies on userspace preferring
firmware type backlight devices over native ones.
Registering 2 backlight
ATM on x86 laptops where we want userspace to use the acpi_video backlight
device we often register both the GPU's native backlight device and
acpi_video's firmware acpi_video# backlight device. This relies on
userspace preferring firmware type backlight devices over native ones, but
registering 2
Hi All,
As mentioned in my RFC titled "drm/kms: control display brightness through
drm_connector properties":
https://lore.kernel.org/dri-devel/0d188965-d809-81b5-74ce-7d30c49fe...@redhat.com/
The first step towards this is to deal with some existing technical debt
in backlight handling on
On 7/12/2022 10:14 PM, Rob Clark wrote:
On Mon, Jul 11, 2022 at 10:05 PM Akhil P Oommen
wrote:
On 7/12/2022 4:52 AM, Doug Anderson wrote:
Hi,
On Fri, Jul 8, 2022 at 11:00 PM Akhil P Oommen wrote:
There are some hardware logic under CX domain. For a successful
recovery, we should ensure cx
On 7/12/2022 3:00 AM, Dmitry Baryshkov wrote:
On Tue, 12 Jul 2022 at 01:39, Abhinav Kumar wrote:
On 7/11/2022 2:43 AM, Dmitry Baryshkov wrote:
Currently the DSI driver has two separate paths: one if the next device
in a chain is a bridge and another one if the panel is connected
On Tue, Jul 12, 2022 at 10:21:14AM -0400, Anthony Krowiak wrote:
> > +void vfio_unpin_pages(struct vfio_device *device, unsigned long *user_pfn,
> > + int npage)
> > {
> > struct vfio_container *container;
> > struct vfio_iommu_driver *driver;
> > - int ret;
>
On Tue, Jul 05, 2022 at 05:40:27PM +0800, Rex-BC Chen wrote:
> On Fri, 2022-07-01 at 14:29 -0600, Rob Herring wrote:
> > On Fri, Jul 01, 2022 at 02:27:59PM +0800, Bo-Chen Chen wrote:
> > > From: Markus Schneider-Pargmann
> > >
> > > This controller is present on several mediatek hardware.
Both, GEM and FB, CMA helpers were renamed to "GEM DMA" and "FB DMA",
hence the task can be removed.
Acked-by: Thomas Zimmermann
Reviewed-by: Laurent Pinchart
Signed-off-by: Danilo Krummrich
---
Documentation/gpu/todo.rst | 13 -
1 file changed, 13 deletions(-)
diff --git
The field paddr of struct drm_gem_dma_object holds a DMA address, which
might actually be a physical address. However, depending on the platform,
it can also be a bus address or a virtual address managed by an IOMMU.
Hence, rename the field to dma_addr, which is more applicable.
In order to do
Rename "FB CMA" helpers to "FB DMA" helpers - considering the hierarchy
of APIs (mm/cma -> dma -> fb dma) calling them "FB DMA" seems to be
more applicable.
Besides that, commit e57924d4ae80 ("drm/doc: Task to rename CMA helpers")
requests to rename the CMA helpers and implies that people seem to
This patch series renames all CMA helpers to DMA helpers - considering the
hierarchy of APIs (mm/cma -> dma -> gem/fb dma helpers) calling them DMA
helpers seems to be more applicable.
Additionally, commit e57924d4ae80 ("drm/doc: Task to rename CMA helpers")
requests to rename the CMA helpers and
On 7/11/22 15:17, Linus Walleij wrote:
On Sun, Jul 10, 2022 at 9:44 PM Marek Vasut wrote:
The ST7701 and ST7701S are TFT matrix drivers with integrated multi
protocol decoder capable of DSI/DPI/SPI input and 480x360...864 line
TFT matrix output. Currently the only supported input is DSI.
The
On Thu, Jun 30, 2022 at 10:10:32AM -0700, Prashant Malani wrote:
> (CC+ Bjorn)
>
> On Wed, Jun 29, 2022 at 4:55 PM Stephen Boyd wrote:
> >
> > Quoting Prashant Malani (2022-06-29 15:55:10)
> > > On Wed, Jun 29, 2022 at 2:58 PM Stephen Boyd wrote:
> > > >
> > > > My understanding is there are 4
Since segment_pages is no longer a compile time constant, it looks the
DIV_ROUND_UP(node->size, segment_pages) breaks the 32b build. Simplest
is just to use the ULL variant, but really we should need not need more
than u32 for the page alignment (also we are limited by that due to the
sg->length
On Mon, Jul 11, 2022 at 10:05 PM Akhil P Oommen
wrote:
>
> On 7/12/2022 4:52 AM, Doug Anderson wrote:
> > Hi,
> >
> > On Fri, Jul 8, 2022 at 11:00 PM Akhil P Oommen
> > wrote:
> >> There are some hardware logic under CX domain. For a successful
> >> recovery, we should ensure cx headswitch
On 06/28, Harry Wentland wrote:
>
>
> On 2022-06-19 18:30, Melissa Wen wrote:
> > Hi,
> >
> > I've been working on a proposal to add 3D LUT interface to DRM CRTC
> > color mgmt, that means new **after-blending** properties for color
> > correction. As I'm targeting AMD display drivers, I need
The pull request you sent on Tue, 12 Jul 2022 11:32:31 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2022-07-12
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/29851567d1aa8f0045170545d2e1a5d7a4057667
Thank you!
--
Deet-doot-dot, I am a bot.
On 12/07/2022 17:54, conor.doo...@microchip.com wrote:
> On 11/07/2022 00:21, Damien Le Moal wrote:
>> On 7/11/22 04:39, conor.doo...@microchip.com wrote:
>>> Damien, Krzysztof,
>>>
>>> I know this particular version has not been posted for all that
>>> long, but this binding is (functionally)
Am 12.07.22 um 17:48 schrieb John Stultz:
On Tue, Jul 12, 2022 at 12:40 AM Christian König
wrote:
Am 12.07.22 um 06:22 schrieb John Stultz:
After having to debug down through the kernel to figure out
why my _WAIT calls were always timing out, I realized its
an absolute timeout value instead
Applied. Thanks!
Alex
On Tue, Jul 12, 2022 at 9:56 AM Harry Wentland wrote:
>
> On 2022-07-12 07:32, Melissa Wen wrote:
> > Check the value of per_pixel_alpha to decide whether the Coverage pixel
> > blend mode is applicable or not.
> >
> > Fixes: 76818cdd11a2 ("drm/amd/display: add Coverage
On Thu, 23 Jun 2022, ChiaEn Wu wrote:
> From: ChiYuan Huang
>
> Add Mediatek MT6370 MFD support.
No such thing as "MFD support".
And you're not getting away with submitting a 370 line patch with a 5
word change log either. :)
Please at least tell us what the device is and what it's used for.
i915 selftest hangcheck is causing the i915 driver timeouts, as reported
by Intel CI bot:
http://gfx-ci.fi.intel.com/cibuglog-ng/issuefilterassoc/24297?query_key=42a999f48fa6ecce068bc8126c069be7c31153b4
When such test runs, the only output is:
[ 68.811639] i915: Performing live
From: Chris Wilson
Don't allow two engines to be reset in parallel, as they would both
try to select a reset bit (and send requests to common registers)
and wait on that register, at the same time. Serialize control of
the reset requests/acks using the uncore->lock, which will also ensure
that
From: Chris Wilson
Avoid trying to invalidate the TLB in the middle of performing an
engine reset, as this may result in the reset timing out. Currently,
the TLB invalidate is only serialised by its own mutex, forgoing the
uncore lock, but we can take the uncore->lock as well to serialise
the
Applied. Thanks!
Alex
On Mon, Jul 11, 2022 at 1:39 PM Mario Kleiner
wrote:
>
> Various DCE versions had trouble with 36 bpp lb depth, requiring fixes,
> last time in commit 353ca0fa5630 ("drm/amd/display: Fix 10bit 4K display
> on CIK GPUs") for DCE-8. So far >= DCE-11.2 was considered ok, but
Hi Sebin,
Às 10:29 de 10/07/22, Sebin Sebastian escreveu:
> Fix two coverity warning's double free and and an uninitialized pointer
> read. Both tmp and new are pointing at same address and both are freed
> which leads to double free. Freeing tmp in the condition after new is
> assigned with new
On 06/28, Harry Wentland wrote:
>
>
> On 6/19/22 18:31, Melissa Wen wrote:
> > Add 3D LUT for gammar correction using a 3D lookup table. The position
> > in the color correction pipeline where 3D LUT is applied depends on hw
> > design, being after CTM or gamma. If just after CTM, a shaper lut
Yeah, adding dma_fence_enable_sw_signaling() is the right thing to do.
The question is where to add that? Usually right before the fence is
returned from the object or queried from userspace would probably be the
right place.
Regards,
Christian.
Am 12.07.22 um 16:22 schrieb Lionel
On 06/27, Ville Syrjälä wrote:
> On Sun, Jun 19, 2022 at 09:31:03PM -0100, Melissa Wen wrote:
> > Add 3D LUT for gammar correction using a 3D lookup table. The position
> > in the color correction pipeline where 3D LUT is applied depends on hw
> > design, being after CTM or gamma. If just after
Reviewed-by: Tony Krowiak
On 7/8/22 6:44 PM, Nicolin Chen wrote:
The vfio_ap_ops code maintains both nib address and its PFN, which
is redundant, merely because vfio_pin/unpin_pages API wanted pfn.
Since vfio_pin/unpin_pages() now accept "iova", change "saved_pfn"
to "saved_iova" and remove
Reviewed-by: Tony Krowiak
On 7/8/22 6:44 PM, Nicolin Chen wrote:
The vfio_pin/unpin_pages() so far accepted arrays of PFNs of user IOVA.
Among all three callers, there was only one caller possibly passing in
a non-contiguous PFN list, which is now ensured to have contiguous PFN
inputs too.
Hi Laurent,
On 7/1/22 20:52, d...@redhat.com wrote:
From: Danilo Krummrich
This patch series initializes IDRs with idr_init_base(, 1) rather than
idr_init() in case for the particular IDR no IDs < 1 are ever requested -
this avoids unnecessary tree walks.
Guess this would go through
I'll let Lucas comment. I've only looked a little at it.
From what I remember just enabling sw_signaling was enough to fix the
issue.
-Lionel
On 12/07/2022 13:26, Christian König wrote:
Ping to the Intel guys here. Especially Lucas/Nirmoy/Lionel.
IIRC you stumbled over that problem as well,
On 7/8/22 6:44 PM, Nicolin Chen wrote:
There's only one caller that checks its return value with a WARN_ON_ONCE,
while all other callers don't check the return value at all. Above that,
an undo function should not fail. So, simplify the API to return void by
embedding similar WARN_ONs.
Also
I'm really sorry about that. I made a stupid mistake when sending the mail.
Apology for the mess I've made.
Best regards,
Molly
On Tue, Jul 12, 2022 at 10:08 PM Krzysztof Kozlowski <
krzysztof.kozlow...@linaro.org> wrote:
> On 09/07/2022 16:11, MollySophia wrote:
> > Add documentation for
On 09/07/2022 16:11, MollySophia wrote:
> Add documentation for "novatek,nt35596s" panel.
>
> Signed-off-by: MollySophia
I see now three different patchsets, twice v1 and once v2 (send shortly
after v1). This is confusing.
Best regards,
Krzysztof
1 - 100 of 152 matches
Mail list logo
