Hi Sam
Am 16.08.22 um 19:22 schrieb Sam Ravnborg:
Hi Thomas,
On Tue, Aug 16, 2022 at 03:48:53PM +0200, Thomas Zimmermann wrote:
Add drm_fb_build_fourcc_list() function that builds a list of supported
formats from native and emulated ones. Helpful for all drivers that do
format conversion as pa
Hi,
On Tue, Aug 16, 2022 at 05:34:51PM +0100, Sudip Mukherjee (Codethink) wrote:
> Not sure if it has been reported but the mainline kernel shows a drm warning
> on RPI4B.
>
> [ 14.821276] WARNING: CPU: 3 PID: 187 at
> drivers/gpu/drm/vc4/vc4_hdmi_regs.h:487 vc5_hdmi_reset+0x1f8/0x240 [vc4]
>
On 8/16/22 13:36, Mark Brown wrote:
> On Tue, Aug 16, 2022 at 07:56:06AM +0300, Matti Vaittinen wrote:
>> On 8/16/22 01:55, Mark Brown wrote:
>>> On Tue, Aug 16, 2022 at 12:17:17AM +0300, Laurent Pinchart wrote:
>
These devres helpers give
a false sense of security to driver authors and
Delete the redundant word 'set'.
Signed-off-by: Jilin Yuan
---
drivers/video/fbdev/ssd1307fb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/ssd1307fb.c b/drivers/video/fbdev/ssd1307fb.c
index 5c765655d000..52e4ed9da78c 100644
--- a/drivers/video/fbdev/
Delete the redundant word 'its'.
Signed-off-by: Jilin Yuan
---
drivers/video/fbdev/skeletonfb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/skeletonfb.c b/drivers/video/fbdev/skeletonfb.c
index 818b3a5003e1..f316ea320d29 100644
--- a/drivers/video/fbd
On Mon, 8 Aug 2022 13:15:24 +0300, Krzysztof Kozlowski wrote:
> Bartlomiej's Samsung email address is not working since around last
> year and there was no follow up patch take over of the drivers, so drop
> the email from maintainers.
>
>
Applied, thanks!
[1/3] MAINTAINERS: Drop Bartlomiej Zol
在 2022/8/15 21:12, Christian König 写道:
Am 15.08.22 um 09:34 schrieb 李真能:
在 2022/8/12 18:55, Christian König 写道:
Am 11.08.22 um 09:25 schrieb Zhenneng Li:
Although radeon card fence and wait for gpu to finish processing
current batch rings,
there is still a corner case that radeon lockup wor
On Wed, Aug 17, 2022 at 9:31 AM Geert Uytterhoeven wrote:
> On Tue, Aug 16, 2022 at 5:50 PM Maxime Ripard wrote:
> > On Tue, Aug 16, 2022 at 04:43:44PM +0200, Geert Uytterhoeven wrote:
> > > > > > > Either you have to add them here (e.g. "hd720p50" and
> > > > > > > "hd720p60"), or
> > > > > > >
On Wed, 2022-08-17 at 09:55 +0300, Sviatoslav Peleshko wrote:
> The i915_gem_object_trylock we had in the grab_vma() makes it return
> false
> when the vma->obj is already locked. In this case we'll skip this vma
> during eviction, and eventually might be forced to return -ENOSPC
> even
> though we
Hi Maxime,
On Tue, Aug 16, 2022 at 5:50 PM Maxime Ripard wrote:
> On Tue, Aug 16, 2022 at 04:43:44PM +0200, Geert Uytterhoeven wrote:
> > > > > > Either you have to add them here (e.g. "hd720p50" and "hd720p60"),
> > > > > > or
> > > > > > handle them through "@". The latter would impact "[PATC
On Wed, Aug 17, 2022 at 09:31:18AM +0200, Geert Uytterhoeven wrote:
> Hi Maxime,
>
> On Tue, Aug 16, 2022 at 5:50 PM Maxime Ripard wrote:
> > On Tue, Aug 16, 2022 at 04:43:44PM +0200, Geert Uytterhoeven wrote:
> > > > > > > Either you have to add them here (e.g. "hd720p50" and
> > > > > > > "hd7
On Tue, Aug 16, 2022 at 05:00:38PM +0200, Geert Uytterhoeven wrote:
> Hi Maxime,
>
> On Tue, Aug 16, 2022 at 3:26 PM Maxime Ripard wrote:
> > On Fri, Aug 12, 2022 at 03:18:58PM +0200, Geert Uytterhoeven wrote:
> > > On Fri, Jul 29, 2022 at 6:35 PM Maxime Ripard wrote:
> > > > Multiple drivers (m
Hi Maxime,
On Wed, Aug 17, 2022 at 9:47 AM Maxime Ripard wrote:
> On Wed, Aug 17, 2022 at 09:31:18AM +0200, Geert Uytterhoeven wrote:
> > On Tue, Aug 16, 2022 at 5:50 PM Maxime Ripard wrote:
> > > On Tue, Aug 16, 2022 at 04:43:44PM +0200, Geert Uytterhoeven wrote:
> > > > > > > > Either you have
Am 16.08.22 um 19:29 schrieb Rob Clark:
On Tue, Aug 16, 2022 at 9:51 AM Christian König
wrote:
Am 16.08.22 um 16:26 schrieb Rob Clark:
On Tue, Aug 16, 2022 at 1:27 AM Christian König
wrote:
Am 15.08.22 um 23:15 schrieb Rob Clark:
From: Rob Clark
This is a fairly narrowly focused interf
On Tue, 16 Aug 2022, Bo Liu wrote:
> There is an unexpected word "the" in the file i915_irq.c,
> fix it.
>
> Signed-off-by: Bo Liu
Thanks for the patch, pushed to drm-intel-next.
BR,
Jani.
> ---
> drivers/gpu/drm/i915/i915_irq.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff
On Wed, Aug 17, 2022 at 10:35:07AM +0200, Geert Uytterhoeven wrote:
> Hi Maxime,
>
> On Wed, Aug 17, 2022 at 9:47 AM Maxime Ripard wrote:
> > On Wed, Aug 17, 2022 at 09:31:18AM +0200, Geert Uytterhoeven wrote:
> > > On Tue, Aug 16, 2022 at 5:50 PM Maxime Ripard wrote:
> > > > On Tue, Aug 16, 202
Am 17.08.22 um 09:31 schrieb 李真能:
在 2022/8/15 21:12, Christian König 写道:
Am 15.08.22 um 09:34 schrieb 李真能:
在 2022/8/12 18:55, Christian König 写道:
Am 11.08.22 um 09:25 schrieb Zhenneng Li:
Although radeon card fence and wait for gpu to finish processing
current batch rings,
there is still a
On Wed, Aug 17, 2022 at 7:59 PM Ville Syrjälä
wrote:
[snipped]
> I had a quick trawl through some Windows stuff for this and
> it does seem to do a few extra checks:
> - platform must be TGL-H (nothing else has the DPin stuff I guess)
> - OpRegion header must indicate dGPU presence
Is the dGPU
On Tue, 16 Aug 2022 18:28:04 +0100,
Robin Murphy wrote:
>
> The iommu-dma layer is now mostly encapsulated by iommu_dma_ops, with
> only a couple more public interfaces left pertaining to MSI integration.
> Since these depend on the main IOMMU API header anyway, move their
> declarations there, t
On Wed, Aug 17, 2022 at 08:15:58PM +0800, Kai-Heng Feng wrote:
> On Wed, Aug 17, 2022 at 7:59 PM Ville Syrjälä
> wrote:
>
> [snipped]
>
> > I had a quick trawl through some Windows stuff for this and
> > it does seem to do a few extra checks:
> > - platform must be TGL-H (nothing else has the DP
Hi,
On 7/20/22 18:46, Alex Deucher wrote:
> On Wed, Jul 20, 2022 at 12:44 PM Alex Deucher wrote:
>>
>> On Tue, Jul 12, 2022 at 3:39 PM Hans de Goede wrote:
>>>
>>> Before this commit when we want userspace to use the acpi_video backlight
>>> device we register both the GPU's native backlight dev
Hi Maxime,
On Wed, Aug 17, 2022 at 1:15 PM Maxime Ripard wrote:
> On Wed, Aug 17, 2022 at 10:35:07AM +0200, Geert Uytterhoeven wrote:
> > On Wed, Aug 17, 2022 at 9:47 AM Maxime Ripard wrote:
> > > On Wed, Aug 17, 2022 at 09:31:18AM +0200, Geert Uytterhoeven wrote:
> > > > On Tue, Aug 16, 2022 at
Den 17.08.2022 13.46, skrev Maxime Ripard:
> On Tue, Aug 16, 2022 at 09:35:24PM +0200, Noralf Trønnes wrote:
>> Den 16.08.2022 11.49, skrev Maxime Ripard:
>>> On Tue, Aug 16, 2022 at 11:42:20AM +0200, Noralf Trønnes wrote:
Den 16.08.2022 10.26, skrev Maxime Ripard:
> Hi,
>
> On
On Wed, Aug 17, 2022 at 10:51:55AM +0200, Geert Uytterhoeven wrote:
> On Wed, Aug 17, 2022 at 9:54 AM Maxime Ripard wrote:
> > On Tue, Aug 16, 2022 at 05:00:38PM +0200, Geert Uytterhoeven wrote:
> > > On Tue, Aug 16, 2022 at 3:26 PM Maxime Ripard wrote:
> > > > On Fri, Aug 12, 2022 at 03:18:58PM
On Wed, Aug 17, 2022 at 03:05:52PM +0200, Geert Uytterhoeven wrote:
> Hi Maxime,
>
> On Wed, Aug 17, 2022 at 1:15 PM Maxime Ripard wrote:
> > On Wed, Aug 17, 2022 at 10:35:07AM +0200, Geert Uytterhoeven wrote:
> > > On Wed, Aug 17, 2022 at 9:47 AM Maxime Ripard wrote:
> > > > On Wed, Aug 17, 202
From: Tomi Valkeinen
rcar_du_regs.h is not needed by rcar_du_drv.c so drop the include.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/rcar-du/rcar_du_drv.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
inde
From: Tomi Valkeinen
The rcar DU driver on r8a779a0 has a bug causing some specific colors
getting converted to transparent colors, which then (usually) show as
black pixels on the screen.
The reason seems to be that the driver sets PnMR_SPIM_ALP bit in
PnMR.SPIM field, which is an illegal setti
On Wed, Aug 17, 2022 at 2:57 AM Christian König
wrote:
>
>
>
> Am 16.08.22 um 19:29 schrieb Rob Clark:
> > On Tue, Aug 16, 2022 at 9:51 AM Christian König
> > wrote:
> >> Am 16.08.22 um 16:26 schrieb Rob Clark:
> >>> On Tue, Aug 16, 2022 at 1:27 AM Christian König
> >>> wrote:
> Am 15.08.22
On Tue, Aug 16, 2022 at 11:20:50AM +, Olivier Masse wrote:
> On ven., 2022-08-12 at 17:39 +0100, Brian Starkey wrote:
> > On Mon, Aug 08, 2022 at 02:39:53PM +, Olivier Masse wrote:
> > > On ven., 2022-08-05 at 16:41 +0100, Brian Starkey wrote:
> > > > On Fri, Aug 05, 2022 at 03:53:28PM +020
Hi Maxime,
On Wed, Aug 17, 2022 at 3:19 PM Maxime Ripard wrote:
> On Wed, Aug 17, 2022 at 03:05:52PM +0200, Geert Uytterhoeven wrote:
> > On Wed, Aug 17, 2022 at 1:15 PM Maxime Ripard wrote:
> > > On Wed, Aug 17, 2022 at 10:35:07AM +0200, Geert Uytterhoeven wrote:
> > > > On Wed, Aug 17, 2022 at
Hi Maxime,
On Wed, Aug 17, 2022 at 3:15 PM Maxime Ripard wrote:
> On Wed, Aug 17, 2022 at 10:51:55AM +0200, Geert Uytterhoeven wrote:
> > On Wed, Aug 17, 2022 at 9:54 AM Maxime Ripard wrote:
> > > On Tue, Aug 16, 2022 at 05:00:38PM +0200, Geert Uytterhoeven wrote:
> > > > On Tue, Aug 16, 2022 at
Hi,
On Tue, Aug 16, 2022 at 5:58 AM Yongqin Liu wrote:
>
> HI, Douglas
>
> With this change, I get one kernel panic with my hikey960
> android-mainline based Android build,
> if it's reverted, then the build could boot to the home screen successfully.
> From the log information I shared here, not
Hi Folks,
Le mardi 16 août 2022 à 11:20 +, Olivier Masse a écrit :
> Hi Brian,
>
>
> On ven., 2022-08-12 at 17:39 +0100, Brian Starkey wrote:
> > Caution: EXT Ema
> >
[...]
> >
> > Interesting, that's not how the devices I've worked on operated.
> >
> > Are you saying that you have to h
+Cyrille
Hi Nicolas,
On mer., 2022-08-17 at 10:29 -0400, Nicolas Dufresne wrote:
> Caution: EXT Email
>
> Hi Folks,
>
> Le mardi 16 août 2022 à 11:20 +, Olivier Masse a écrit :
> > Hi Brian,
> >
> >
> > On ven., 2022-08-12 at 17:39 +0100, Brian Starkey wrote:
> > > Caution: EXT Ema
> > >
Hi Daniel,
On 8/2/22 18:49, Daniel Dadap wrote:
> On 8/2/22 06:31, Hans de Goede wrote:
>> Hi Daniel,
>>
>> On 7/21/22 23:30, Daniel Dadap wrote:
>>> On 7/21/22 16:24, Daniel Dadap wrote:
On 7/12/22 14:38, Hans de Goede wrote:
> ATM on x86 laptops where we want userspace to use the acpi_v
On 08/17, Mikhail Gavrilov wrote:
> On Mon, Aug 15, 2022 at 3:37 PM Mikhail Gavrilov
> wrote:
> >
> > Thanks, I tested this patch.
> > But with this patch use-after-free problem happening in another place:
>
> Does anyone have an idea why the second use-after-free happened?
> From the trace I don
Used to increment the refcount of the dma buf's struct file, only if the
refcount is not zero. Useful to allow the struct file's lifetime to
control the lifetime of the dmabuf while still letting the driver to keep
track of created dmabufs.
Signed-off-by: Jason Gunthorpe
---
include/linux/dma-bu
dma-buf has become a way to safely acquire a handle to non-struct page
memory that can still have lifetime controlled by the exporter. Notably
RDMA can now import dma-buf FDs and build them into MRs which allows for
PCI P2P operations. Extend this to allow vfio-pci to export MMIO memory
from PCI de
To increment a reference the caller already holds. Export
vfio_device_put() to pair with it.
Signed-off-by: Jason Gunthorpe
---
drivers/vfio/vfio_main.c | 3 ++-
include/linux/vfio.h | 6 ++
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/vfio/vfio_main.c b/drivers/
dma-buf has become a way to safely acquire a handle to non-struct page
memory that can still have lifetime controlled by the exporter. Notably
RDMA can now import dma-buf FDs and build them into MRs which allows for
PCI P2P operations. Extend this to allow vfio-pci to export MMIO memory
from PCI de
FLR triggered by an emulated config space write should not behave
differently from a FLR triggered by VFIO_DEVICE_RESET, currently the
config space path misses the power management.
Consolidate all the call sites to invoke a single function.
Signed-off-by: Jason Gunthorpe
---
drivers/vfio/pci/v
Am Mittwoch, dem 17.08.2022 um 10:29 -0400 schrieb Nicolas Dufresne:
> Hi Folks,
>
> Le mardi 16 août 2022 à 11:20 +, Olivier Masse a écrit :
> > Hi Brian,
> >
> >
> > On ven., 2022-08-12 at 17:39 +0100, Brian Starkey wrote:
> > > Caution: EXT Ema
> > >
>
> [...]
>
> > >
> > > Interestin
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: 95d10484d66e54d5c01e36389e9318221fb8f60b Add linux-next specific
files for 20220817
Warning reports:
https://lore.kernel.org/linux-doc/202208162058.7appivkl-...@intel.com
https
Hi, Douglas
On Wed, 17 Aug 2022 at 22:26, Doug Anderson wrote:
>
> Hi,
>
> On Tue, Aug 16, 2022 at 5:58 AM Yongqin Liu wrote:
> >
> > HI, Douglas
> >
> > With this change, I get one kernel panic with my hikey960
> > android-mainline based Android build,
> > if it's reverted, then the build could
On 8/17/22 7:22 AM, Hans de Goede wrote:
Hi Daniel,
On 7/15/22 13:59, Hans de Goede wrote:
Hi Daniel,
On 7/12/22 22:13, Daniel Dadap wrote:
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 p
On Wed, Aug 17, 2022 at 9:08 PM Melissa Wen wrote:
>
> Hi Mikhail,
>
> IIUC, you got this second user-after-free by applying the first version
> of Maíra's patch, right? So, that version was adding another unbalanced
> unlock to the cs ioctl flow, but it was solved in the latest version,
> that yo
Adding Mark Pearson from Lenovo to this, Mark for reference the original patch
is here:
https://patchwork.freedesktop.org/patch/497807/?series=107312&rev=1
Comments from me down below
On Wed, 2022-08-17 at 09:02 +0800, Kai-Heng Feng wrote:
> On Wed, Aug 17, 2022 at 2:24 AM Lyude Paul wrote:
> >
On 8/17/22 14:44, Mikhail Gavrilov wrote:
On Wed, Aug 17, 2022 at 9:08 PM Melissa Wen wrote:
Hi Mikhail,
IIUC, you got this second user-after-free by applying the first version
of Maíra's patch, right? So, that version was adding another unbalanced
unlock to the cs ioctl flow, but it was s
For quite a while we've been carrying around a lot of legacy modesetting
code in the MST helpers that has been rather annoying to keep around,
and very often gets in the way of trying to implement additional
functionality in MST such as fallback link rate retraining, dynamic BPC
management and DSC
This function isn't too confusing if you see the comment around the
call-site for it, but if you don't then it's not at all obvious this is
meant to copy DRM's payload table over to DC's internal state structs.
Seeing this function before finding that comment definitely threw me into a
loop a few t
Just to make this more clear to outside contributors that these are
DC-specific structs, as this also threw me into a loop a number of times
before I figured out the purpose of this.
Signed-off-by: Lyude Paul
Cc: Wayne Lin
Cc: Fangzhi Zuo
Acked-by: Jani Nikula
---
.../gpu/drm/amd/display/amdg
In retrospect, the name I chose for this originally is confusing, as
there's a lot more info in here then just the VCPI. This really should be
called a payload. Let's make it more obvious that this is meant to be
related to the atomic state and is about payloads by renaming it to
drm_dp_mst_atomic_
VCPI is only sort of the correct term here, originally the majority of this
code simply referred to timeslots vaguely as "slots" - and since I started
working on it and adding atomic functionality, the name "VCPI slots" has
been used to represent time slots.
Now that we actually have consistent ac
For some reason we mention returning 0 if "slots have been added back to
drm_dp_mst_topology_state->avail_slots". This is totally misleading,
avail_slots is simply for figuring out the total number of slots available
in total on the topology and has no relation to the current payload
allocations.
We already open-code this quite often, and will be iterating through
payloads even more once we've moved all of the payload tracking into the
atomic state. So, let's add a helper for doing this.
Signed-off-by: Lyude Paul
Cc: Wayne Lin
Cc: Ville Syrjälä
Cc: Fangzhi Zuo
Cc: Jani Nikula
Cc: Imre
As Daniel Vetter pointed out, if we only use the atomic modesetting locks
with MST it's technically possible for a driver with non-blocking modesets
to race when it comes to MST displays - as we make the mistake of not doing
our own CRTC commit tracking in the topology_state object.
This could pot
Since we're going to be relying on atomic locking for payloads now (and the
MST mgr needs to track CRTCs), pull in the topology state for all modesets
in nv50_msto_atomic_check().
Signed-off-by: Lyude Paul
Acked-by: Jani Nikula
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 2 +-
1 file changed,
Since we're about to start adding some stuff here, we may as well fill in
any missing documentation that we forgot to write.
Signed-off-by: Lyude Paul
Cc: Wayne Lin
Cc: Ville Syrjälä
Cc: Fangzhi Zuo
Cc: Jani Nikula
Cc: Imre Deak
Cc: Daniel Vetter
Cc: Sean Paul
Acked-by: Jani Nikula
---
i
Currently with the MST helpers we avoid releasing payloads _and_ avoid
pulling in the MST state if there aren't any actual payload changes. While
we want to keep the first step, we need to now make sure that we're always
pulling in the MST state on all modesets that can modify payloads - even if
th
Post-NV50, the only kind of encoder you'll find for DP connectors on Nvidia
GPUs are SORs (serial output resources). Because SORs have fixed
associations with their connectors, we can correctly assume that any DP
connector on a nvidia GPU will have exactly one SOR encoder routed to it
for DisplayPo
There's another kind of situation where we could potentially race with
nonblocking modesets and MST, especially if we were to only use the locking
provided by atomic modesetting:
* Display 1 begins as enabled on DP-1 in SST mode
* Display 1 switches to MST mode, exposes one sink in MST mode
* User
We want to start cutting down on all of the places that we use port
validation, so that ports may be removed from the topology as quickly as
possible to minimize the number of errors we run into as a result of being
out of sync with the current topology status. This isn't a very typical
scenario an
Currently, we set drm_dp_atomic_payload->time_slots to 0 in order to
indicate that we're about to delete a payload in the current atomic state.
Since we're going to be dropping all of the legacy code for handling the
payload table however, we need to be able to ensure that we still keep
track of th
I'm not sure why, but at the time I originally wrote the find/release time
slot helpers I thought we should avoid keeping modeset tracking out of the
MST helpers. In retrospect though there's no actual good reason to do
this, and the logic has ended up being identical across all the drivers
using t
Right now, radeon is technically the only non-atomic driver still making
use of the MST helpers - and thus the final user of all of the legacy MST
helpers. Originally I was going to look into seeing if we could move legacy
MST into the radeon driver itself, however:
* SI and CIK both can use amdgp
Now that we've finally gotten rid of the non-atomic MST users leftover in
the kernel, we can finally get rid of all of the legacy payload code we
have and move as much as possible into the MST atomic state structs. The
main purpose of this is to make the MST code a lot less confusing to work
on, as
On 8/17/22 10:05 AM, Hans de Goede wrote:
Hi Daniel,
On 8/2/22 18:49, Daniel Dadap wrote:
On 8/2/22 06:31, Hans de Goede wrote:
Hi Daniel,
On 7/21/22 23:30, Daniel Dadap wrote:
On 7/21/22 16:24, Daniel Dadap wrote:
On 7/12/22 14:38, Hans de Goede wrote:
ATM on x86 laptops where we want use
t; pass-through during mode validation")
> > > And, reverting that commit has fixed the build failure.
> > >
> > > I will be happy to test any patch or provide any extra log if needed.
> >
> > I have reverted that commit in today's linux-next.
>
> I have removed that revert. Sudip, can you recheck when linux-next is
> released, please?
The build failure is not seen with next-20220817.
--
Regards
Sudip
Hi,
On Wed, Jul 20, 2022 at 3:42 PM Doug Anderson wrote:
>
> Hi,
>
> On Wed, Jul 20, 2022 at 1:46 PM Rob Clark wrote:
> >
> > On Fri, Jul 8, 2022 at 8:25 AM Doug Anderson wrote:
> > >
> > > Hi,
> > >
> > > On Wed, Jul 6, 2022 at 12:14 PM Stephen Boyd wrote:
> > > >
> > > > Set the panel orient
On Wed, Aug 17, 2022 at 11:43 PM Maíra Canal wrote:
>
> Hi Mikhail,
>
> Looks like 45ecaea738830b9d521c93520c8f201359dcbd95 ("drm/sched: Partial
> revert of 'drm/sched: Keep s_fence->parent pointer'") introduced the
> error. Try reverting it and check if the use-after-free still happens.
Thanks,
Negative tests can be expressed as a single parameterized test case,
which highlights that we're following the same test logic (passing
invalid cmdline and expecting drm_mode_parse_command_line_for_connector
to fail), which improves readability.
v2: s/negative/invalid to be consistent with other t
Expecting to observe a specific value, when the function responsible for
setting the value has failed will lead to extra noise in test output.
Use assert when the situation calls for it.
Also - very small tidying up around the changed areas (whitespace).
v2: Leave out the locals (drm_connector is
Hi All,
Not sure if it has been reported, build of next-20220817 fails with the
error:
ERROR: modpost: "cpu_smallcore_map" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko]
undefined!
Trying to do a git bisect to find out the offending commit.
I will be happy to test any patch or provide any
Am 2022-08-12 um 21:27 schrieb Bas Nieuwenhuizen:
This way callsites can choose between READ/BOOKKEEP reservations.
Signed-off-by: Bas Nieuwenhuizen
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 5 +
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 9 +++--
drivers/gpu/dr
failure.
> > > >
> > > > I will be happy to test any patch or provide any extra log if needed.
> > >
> > > I have reverted that commit in today's linux-next.
> >
> > I have removed that revert. Sudip, can you recheck when linux-next is
> > released, please?
>
> The build failure is not seen with next-20220817.
Excellent, thanks.
--
Cheers,
Stephen Rothwell
pgpQG482fU9Uv.pgp
Description: OpenPGP digital signature
On 8/15/22 16:08, Christian König wrote:
> TTM owns the pages it uses for backing buffer objects with system
> memory. Because of this it is absolutely illegal to mess around with
> the reference count of those pages.
>
> So make sure that nobody ever tries to grab an extra reference on
> pages al
Am 2022-07-15 um 04:07 schrieb ZhiJie.zhang:
memleak will happend that reload module due to ignore kfree when release
topology
Signed-off-by: ZhiJie.zhang
---
drivers/gpu/drm/amd/amdkfd/kfd_topology.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_topolog
Hi,
On Mon, Aug 15, 2022 at 2:39 AM Hsin-Yi Wang wrote:
>
> The double reset power-on sequence is a workaround for the hardware
> flaw in some chip that SPI Clock output glitch and cause internal MPU
> unable to read firmware correctly. The sequence is suggested in ps8640
> application note.
>
>
On 8/15/22 18:54, Dmitry Osipenko wrote:
> On 8/15/22 17:57, Dmitry Osipenko wrote:
>> On 8/15/22 16:53, Christian König wrote:
>>> Am 15.08.22 um 15:45 schrieb Dmitry Osipenko:
[SNIP]
> Well that comment sounds like KVM is doing the right thing, so I'm
> wondering what exactly is goin
Hi Kees,
would you mind taking a look at this patch?
Thanks,
Andi
On Tue, Aug 16, 2022 at 06:35:18PM +0900, Gwan-gyeong Mun wrote:
> It moves overflows_type utility macro into overflow header from i915_utils
> header. The overflows_type can be used to catch the truncation between data
> types. A
64 DRM device nodes is not enough for everyone.
Upgrade it to 512K (which definitely is more than enough).
Additionally - one minor tweak around minor IDR locking.
Michał Winiarski (3):
drm: Don't reserve minors for control nodes
drm: Expand max DRM device number to full MINORBITS
drm: Use m
Operating on drm minor is not done in IRQ context, which means that we
could safely downgrade to regular non-irq spinlock.
But we can also go further and drop the idr_preload tricks by just using
a mutex.
Signed-off-by: Michał Winiarski
---
drivers/gpu/drm/drm_drv.c | 31
Control nodes are no longer with us.
While we still need to preserve render nodes numbering, there's no need
to reserve the range formerly used for control. Let's repurpose it to be
used by primary and remove control remains from the code entirely.
References: commit 0d49f303e8a7 ("drm: remove all
On 8/18/22 01:57, Dmitry Osipenko wrote:
> On 8/15/22 18:54, Dmitry Osipenko wrote:
>> On 8/15/22 17:57, Dmitry Osipenko wrote:
>>> On 8/15/22 16:53, Christian König wrote:
Am 15.08.22 um 15:45 schrieb Dmitry Osipenko:
> [SNIP]
>> Well that comment sounds like KVM is doing the right th
Den 17.08.2022 15.11, skrev Noralf Trønnes:
>
>
> Den 17.08.2022 13.46, skrev Maxime Ripard:
>> On Tue, Aug 16, 2022 at 09:35:24PM +0200, Noralf Trønnes wrote:
>>> Den 16.08.2022 11.49, skrev Maxime Ripard:
On Tue, Aug 16, 2022 at 11:42:20AM +0200, Noralf Trønnes wrote:
> Den 16.08.20
Hi,
On Sun, Aug 14, 2022 at 11:46 PM Maxime Ripard wrote:
>
> On Fri, Jul 29, 2022 at 12:57:40PM -0700, Doug Anderson wrote:
> > Hi,
> >
> > On Fri, Jul 29, 2022 at 9:41 AM Maxime Ripard wrote:
> > >
> > > On Fri, Jul 29, 2022 at 07:50:20AM -0700, Doug Anderson wrote:
> > > > On Fri, Jul 29, 202
On Wed, Aug 17, 2022 at 01:34:13PM -0700, Brian Norris wrote:
> On Mon, Aug 15, 2022 at 11:46 PM Zhang Zekun wrote:
> >
> > Add the missing clk_disable_unprepare() before return from
> > analogix_dp_resume() in the error handling case.
> >
> > Fixes: 211f276ed3d9 ("drm: bridge: analogix/dp: add pa
On Thu, Aug 18, 2022 at 01:07:29AM +0200, Andi Shyti wrote:
> Hi Kees,
>
> would you mind taking a look at this patch?
Hi! Thanks for the heads-up!
>
> Thanks,
> Andi
>
> On Tue, Aug 16, 2022 at 06:35:18PM +0900, Gwan-gyeong Mun wrote:
> > It moves overflows_type utility macro into overflow he
On 8/17/22 19:01, Alex Deucher wrote:
> On Wed, Aug 17, 2022 at 6:03 PM Sudip Mukherjee (Codethink)
> wrote:
>>
>> Hi All,
>>
>> Not sure if it has been reported, build of next-20220817 fails with the
>> error:
>>
>> ERROR: modpost: "cpu
On Thu, Aug 18, 2022 at 6:54 AM Doug Anderson wrote:
>
> Hi,
>
> On Mon, Aug 15, 2022 at 2:39 AM Hsin-Yi Wang wrote:
> >
> > The double reset power-on sequence is a workaround for the hardware
> > flaw in some chip that SPI Clock output glitch and cause internal MPU
> > unable to read firmware co
Hi Dave, Daniel,
A bit bigger than normal, but this is several weeks of fixes since I was out
of the office and then digging out once I got back. Mainly fixes for new
IPs that were added in 6.0.
The following changes since commit 5493ee1919eae4f49d62276cf5986b7f7c7aa8f6:
Merge tag 'amd-drm-ne
Semicolon is not required after curly braces.
Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=1918
Reported-by: Abaci Robot
Signed-off-by: Yang Li
---
drivers/gpu/drm/amd/display/dc/clk_mgr/dcn314/dcn314_clk_mgr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/
On Thu, Aug 18, 2022 at 11:19 AM Rock Chiu
wrote:
>
> How does T4/T5 impact the real case? We talked previously the T4/T5
> shouldn't cause user impact.
> Do we have testing data from ODM?
>
Please leave comments below the previous comment's headline.
I'm confused. The reason I upstreamed this p
Add a reset op compatible function to poll for gdsc collapse.
Signed-off-by: Akhil P Oommen
---
Changes in v2:
- Minor update to function prototype
drivers/clk/qcom/gdsc.c | 23 +++
drivers/clk/qcom/gdsc.h | 7 +++
2 files changed, 26 insertions(+), 4 deletions(-)
dif
Instead of separate refcount for each submit, take single rpm refcount
on behalf of all the submits. This makes it easier to drop the rpm
refcount during recovery in an upcoming patch.
Signed-off-by: Akhil P Oommen
---
(no changes since v3)
Changes in v3:
- New patch
drivers/gpu/drm/msm/msm_g
Allow a consumer driver to poll for cx gdsc collapse through Reset
framework.
Signed-off-by: Akhil P Oommen
---
Changes in v2:
- Minor update to use the updated custom reset ops implementation
drivers/clk/qcom/gpucc-sc7280.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drive
Add necessary definitions in gpucc bindings to ensure gpu cx gdsc collapse
through 'reset' framework for SC7280.
Signed-off-by: Akhil P Oommen
Acked-by: Krzysztof Kozlowski
---
(no changes since v1)
include/dt-bindings/clock/qcom,gpucc-sc7280.h | 3 +++
1 file changed, 3 insertions(+)
diff -
Recently, I debugged a few device crashes which occured during recovery
after a hangcheck timeout. It looks like there are a few things we can
do to improve our chance at a successful gpu recovery.
First one is to ensure that CX GDSC collapses which clears the internal
states in gpu's CX domain.
We can do a few more things to improve our chance at a successful gpu
recovery, especially during a hangcheck timeout:
1. Halt CP and GMU core
2. Do RBBM GBIF HALT sequence
3. Do a soft reset of GPU core
Signed-off-by: Akhil P Oommen
---
(no changes since v1)
drivers/gpu/drm/msm/adreno/a6xx.xm
Because there could be transient votes from other drivers/tz/hyp which
may keep the cx gdsc enabled, we should poll until cx gdsc collapses.
We can use the reset framework to poll for cx gdsc collapse from gpucc
clk driver.
This feature requires support from the platform's gpucc driver.
Signed-of
1 - 100 of 112 matches
Mail list logo
