We already enable gpu power from msm_gpu_submit(), so avoid a duplicate
pm_runtime_get/put from msm_job_run().
Signed-off-by: Akhil P Oommen
---
(no changes since v1)
drivers/gpu/drm/msm/msm_ringbuffer.c | 4
1 file changed, 4 deletions(-)
diff --git
There are some hardware logic under CX domain. For a successful
recovery, we should ensure cx headswitch collapses to ensure all the
stale states are cleard out. This is especially true to for a6xx family
where we can GMU co-processor.
Currently, cx doesn't collapse due to a devlink between gpu
In the scenario where there is one a single submit which is hung, gpu is
power collapsed when it is retired. Because of this, by the time we call
reover(), gpu state would be already clear. Fix this by correctly
managing the pm runtime votes.
Signed-off-by: Akhil P Oommen
---
(no changes since
Some clients like adreno gpu driver would like to ensure that its gdsc
is collapsed at hardware during a gpu reset sequence. This is because it
has a votable gdsc which could be ON due to a vote from another subsystem
like tz, hyp etc or due to an internal hardware signal. To allow
this, gpucc
Add support for Reset using GPUCC driver for GPU. This helps to ensure
that GPU state is reset by making sure that CX head switch is collapsed.
Signed-off-by: Akhil P Oommen
---
(no changes since v1)
arch/arm64/boot/dts/qcom/sc7280.dtsi | 3 +++
1 file changed, 3 insertions(+)
diff --git
When prepare-slumber hfi fails, we should follow a6xx_gmu_force_off()
sequence.
Signed-off-by: Akhil P Oommen
---
(no changes since v1)
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
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.
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)
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
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
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
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
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(-)
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
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
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
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
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 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
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
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,
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
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
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
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
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
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.
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
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.
>
>
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
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
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
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 +++--
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
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
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
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,
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
> 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
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
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,
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
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
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
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
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
*
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
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
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
---
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
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
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:
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.
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
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
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
---
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
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
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
Adding Mark Pearson from Lenovo to this, Mark for reference the original patch
is here:
https://patchwork.freedesktop.org/patch/497807/?series=107312=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 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
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
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
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
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
> > >
>
> [...]
>
> > >
> > >
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
---
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
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
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
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
---
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
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
+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 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
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,
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
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
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
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
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
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
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,
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
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
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
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
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
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,
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
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 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,
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(-)
>
>
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
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
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
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
> > > > > > >
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
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
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
> > > > > >
在 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
1 - 100 of 114 matches
Mail list logo
