Am 07.07.21 um 08:38 schrieb Christoph Hellwig:
On Wed, Jun 30, 2021 at 01:34:17AM +, John Stultz wrote:
This adds a shrinker controlled page pool, extracted
out of the ttm_pool logic, and abstracted out a bit
so it can be used by other non-ttm drivers.
Can you explain in detail why you nee
https://bugzilla.kernel.org/show_bug.cgi?id=211425
Andreas (icedragon...@web.de) changed:
What|Removed |Added
Kernel Version|5.12.13 |5.12.14
--
You may reply
Hi Benjamin,
RK3568 hdmi phy ref clock source is HPLL. HPLL must be set when
switching resolution or plugging.
Whether to add the configuration for HPLL?
Thanks!
在 2021/7/5 22:03, Benjamin Gaignard 写道:
Add a new dw_hdmi_plat_data struct and new compatible for rk3568.
Sign
On Thu, Jun 24, 2021 at 01:57:22PM +0200, Robert Foss wrote:
> Hey Xin,
>
> I would like to merge this series now, but this patch needs a review
> first. Maybe Laurent/Rob Herring are good candidates.
>
>
> Rob.
Hi Rob, I get Laurent/Rob comments before, and explained why we needs
these DT prope
On Wed, Jul 7, 2021 at 12:48 AM Lucas De Marchi
wrote:
> On Fri, Jul 02, 2021 at 11:21:10AM +0200, Daniel Vetter wrote:
> >On Thu, Jul 1, 2021 at 10:26 PM Matt Roper wrote:
> >>
> >> From: Paulo Zanoni
> >>
> >> The current interrupt handler is getting increasingly complicated and
> >> Xe_HP cha
On Tue, 6 Jul 2021 18:42:41 +0200
Maxime Ripard wrote:
> On Tue, Jul 06, 2021 at 12:37:23PM +0300, Pekka Paalanen wrote:
> > > > > +- It must provide a generic helper in the core code to register that
> > > > > + property on the object it attaches to.
> > > > > +
> > > > > +- Its content must be
On 06/07/2021 22:15, Lucas De Marchi wrote:
On Fri, Jul 02, 2021 at 01:42:59PM +0100, Tvrtko Ursulin wrote:
On 01/07/2021 21:23, Matt Roper wrote:
From: John Harrison
Xe_HP can have a lot of extra media engines. This patch adds the
interrupt handler support for them.
Cc: Tvrtko Ursulin
C
On Tue, 6 Jul 2021 17:57:35 -0700
John Harrison wrote:
> On 7/3/2021 01:21, Martin Peres wrote:
> > On 02/07/2021 18:07, Michal Wajdeczko wrote:
> >> On 02.07.2021 10:09, Martin Peres wrote:
> >>> On 02/07/2021 10:29, Pekka Paalanen wrote:
> On Thu, 1 Jul 2021 21:28:06 +0200
> Dan
Am 06.07.21 um 12:12 schrieb Daniel Vetter:
Specifically document the new/clarified rules around how the shared
fences do not have any ordering requirements against the exclusive
fence.
But also document all the things a bit better, given how central
struct dma_resv to dynamic buffer management
On Tue, 06 Jul 2021, Lucas De Marchi wrote:
> On Mon, Jul 05, 2021 at 02:52:31PM +0300, Jani Nikula wrote:
>>On Fri, 02 Jul 2021, Tvrtko Ursulin wrote:
>>> On 01/07/2021 21:23, Matt Roper wrote:
From: Lucas De Marchi
Besides the arch version returned by GRAPHICS_VER(), new platfor
On Tue, 06 Jul 2021, Kuogee Hsieh wrote:
> From: Rajkumar Subbiah
>
> Commit 2f015ec6eab6 ("drm/dp_mst: Add sideband down request tracing +
> selftests") added some debug code for sideband message tracing. But
> it seems to have unintentionally changed the behavior on sideband message
> failure.
Hi,
Here is a series that enables the higher resolutions on the HDMI0 Controller
found in the BCM2711 (RPi4).
In order to work it needs a few adjustments to config.txt, most notably to
enable the enable_hdmi_4kp60 option.
Let me know what you think,
Maxime
---
Changes from v5:
- Fixed unused
Commit 9d44a8d5 ("drm/vc4: Fall back to using an EDID probe in the
absence of a GPIO.") added some code to read the EDID through DDC in the
HDMI driver detect hook since the Pi3 had no HPD GPIO back then.
However, commit b1b8f45b3130 ("ARM: dts: bcm2837: Add missing GPIOs of
Expander") changed
Prior to commit 6800234ceee0 ("drm/vc4: hdmi: Convert to gpiod"), in the
detect hook, if we had an HPD GPIO we would only rely on it and return
whatever state it was in.
However, that commit changed that by mistake to only consider the case
where we have a GPIO and it returns a logical high, and w
We'll need that function in vc4_kms to compute the core clock rate
requirements.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_crtc.c | 8
drivers/gpu/drm/vc4/vc4_drv.h | 5 +
2 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b
vc4_crtc_config_pv() retrieves the encoder again, even though its only
caller, vc4_crtc_atomic_enable(), already did.
Pass the encoder pointer as an argument instead of going through all the
connectors to retrieve it again.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_crtc.c | 7 +++
It turns out the encoder retrieval code, in addition to being
unnecessarily complicated, has a bug when only the planes and crtcs are
affected by a given atomic commit.
Indeed, in such a case, either drm_atomic_get_old_connector_state or
drm_atomic_get_new_connector_state will return NULL and thus
The encoder retrieval code has been a source of bugs and glitches in the
past and the crtc <-> encoder association been wrong in a number of
different ways.
Add some logging to quickly spot issues if they occur.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_crtc.c | 6 ++
1 file
The load tracker was initially designed to report and warn about a load
too high for the HVS. To do so, it computes for each plane the impact
it's going to have on the HVS, and will warn (if it's enabled) if we go
over what the hardware can process.
While the limits being used are a bit irrelevant
Now that we have the infrastructure in place, we can raise the maximum
pixel rate we can reach for HDMI0 on the BCM2711.
HDMI1 is left untouched since its pixelvalve has a smaller FIFO and
would need a clock faster than what we can provide to support the same
modes.
Acked-by: Thomas Zimmermann
R
If we have a state already and disconnect/reconnect the display, the
SCDC messages won't be sent again since we didn't go through a disable /
enable cycle.
In order to fix this, let's call the vc4_hdmi_enable_scrambling function
in the detect callback if there is a mode and it needs the scrambler
Depending on a given HVS output (HVS to PixelValves) and input (planes
attached to a channel) load, the HVS needs for the core clock to be
raised above its boot time default.
Failing to do so will result in a vblank timeout and a stalled display
pipeline.
Signed-off-by: Maxime Ripard
---
driver
Hello,
This series aims to add a generic background color property for CRTC as
discussed in the conversation:
https://patchwork.freedesktop.org/patch/439585/
This patch "drm: add crtc background color property" is strongly inspired
of Matthew Roper's. Please see:
https://patchwork.freedesktop.or
Some display controllers can be programmed to present non-black colors
for pixels not covered by any plane (or pixels covered by the
transparent regions of higher planes). Compositors that want a UI with
a solid color background can potentially save memory bandwidth by
setting the CRTC background
This patch comes from the need to display small resolution pictures with
very few DDR usage. In practice, using a background color, produced by the
drm CRTC, around this picture allows to fetch less data in memory than
setting a full frame picture. And therefore the picture in DDR is smaller
than t
Hi Daniel,
I'm feeling like I miss a ton of context here, so some maybe dumb
questions/remarks below.
Am Dienstag, dem 06.07.2021 um 12:12 +0200 schrieb Daniel Vetter:
> There's only one exclusive slot, and we must not break the ordering.
>
> A better fix would be to us a dma_fence_chain or _arr
Hi,
Thanks for working on this. Do you have plans for user-space
implementations and IGT?
Thanks,
Simon
Am Freitag, dem 02.07.2021 um 23:38 +0200 schrieb Daniel Vetter:
> We need to pull the drm_sched_job_init much earlier, but that's very
> minor surgery.
>
> Signed-off-by: Daniel Vetter
> Cc: Lucas Stach
> Cc: Russell King
> Cc: Christian Gmeiner
> Cc: Sumit Semwal
> Cc: "Christian König"
>
On 06/07/2021 13:48, Alyssa Rosenzweig wrote:
>> My concern is if we ever find a security bug which requires new
>> information/behaviour in the submit ABI to properly fix. In this case it
>> would be appropriate to backport a 'feature' (bug fix) which provides a
>> new ABI but it would need to be
On Wed, Jul 7, 2021 at 10:06 AM Christian König
wrote:
>
> Am 06.07.21 um 12:12 schrieb Daniel Vetter:
> > Specifically document the new/clarified rules around how the shared
> > fences do not have any ordering requirements against the exclusive
> > fence.
> >
> > But also document all the things
Hi,
This series aims at fixing a complete and silent hang when one tries to use CEC
while the display output is off.
This can be tested with:
echo off > /sys/class/drm/card0-HDMI-A-1/status
cec-ctl --tuner -p 1.0.0.0
cec-compliance
This series addresses it by making sure the HDMI controller is
In the bind hook, we actually need the device to have the HSM clock
running during the final part of the display initialisation where we
reset the controller and initialise the CEC component.
Failing to do so will result in a complete, silent, hang of the CPU.
Fixes: 411efa18e4b0 ("drm/vc4: hdmi:
Since our pre_crtc_configure hook returned void, we didn't implement a
goto-based error path handling, leading to errors like failing to put
back the device in pm_runtime in all the error paths, but also failing
to disable the pixel clock if clk_set_min_rate on the HSM clock fails.
Move to a goto-
Similarly to what we encountered with the detect hook with DRM, nothing
actually prevents any of the CEC callback from being run while the HDMI
output is disabled.
However, this is an issue since any register access to the controller
when it's powered down will result in a silent hang.
Let's make
In order to ease further additions to the CEC enable and disable, let's
split the function into two functions, one to enable and the other to
disable.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 73 --
1 file changed, 44 insertions(+), 29 del
We've had many silent hangs where the kernel would look like it just
stalled due to the access to one of the HDMI registers while the
controller was disabled.
Add a warning if we're about to do that so that it's at least not silent
anymore.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/v
Am 02.07.21 um 23:38 schrieb Daniel Vetter:
Instead of just a callback we can just glue in the gem helpers that
panfrost, v3d and lima currently use. There's really not that many
ways to skin this cat.
On the naming bikeshed: The idea for using _await_ to denote adding
dependencies to a job come
Development vkms_config_debufs in vkms_drv.c for the long term plan of
making vkms configurable and have multiple different instances it's
useful to be able to get at the config of each instance in debugfs
Signed-off-by: Beatriz Martins de Carvalho
---
drivers/gpu/drm/vkms/vkms_drv.c | 28 ++
Am 02.07.21 um 23:38 schrieb Daniel Vetter:
This is a very confusingly named function, because not just does it
init an object, it arms it and provides a point of no return for
pushing a job into the scheduler. It would be nice if that's a bit
clearer in the interface.
But the real reason is tha
Am 07.07.21 um 09:14 schrieb Christoph Hellwig:
On Wed, Jul 07, 2021 at 09:10:26AM +0200, Christian K??nig wrote:
Well, the original code all this is based on already had the comment that
this really belong into the page allocator.
The key point is traditionally only GPUs used uncached and w
The vc4_hdmi_audio_prepare function and the functions it's calling have
in several occurences multiple dereferences of either the sample rate or
the number of channels.
It turns out that these variables are also passed through the hdmi codec
parameters structure. Convert all the users to use this
Commit 91e99e113929 ("drm/vc4: hdmi: Register HDMI codec") removed the
references to the vc4_hdmi_audio_component_drv structure, but not the
structure itself resulting in a warning. Remove it.
Fixes: 91e99e113929 ("drm/vc4: hdmi: Register HDMI codec")
Reported-by: kernel test robot
Signed-off-by:
Hi,
Those are three fixes for race conditions we currently have in the vc4 HDMI
driver with regard to the interrupts handling.
The first two are fixing an issue where the handler will be removed by devm
after the resources it uses have been free'd already.
The last one is there to deal with an i
The CEC interrupt handlers are registered through the
devm_request_threaded_irq function. However, while free_irq is indeed
called properly when the device is unbound or bind fails, it's called
after unbind or bind is done.
In our particular case, it means that on failure it creates a window
where
The hotplugs interrupt handlers are registered through the
devm_request_threaded_irq function. However, while free_irq is indeed
called properly when the device is unbound or bind fails, it's called
after unbind or bind is done.
In our particular case, it means that on failure it creates a window
Our hotplug handler will currently call the drm_kms_helper_hotplug_event
every time a hotplug interrupt is called.
However, since the device is registered after all the drivers have
finished their bind callback, we have a window between when we install
our interrupt handler and when drm_dev_regist
Hi John,
On 26.06.2021 02:45, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> There is a new HuC version available for TGL and compatible platforms,
> so switch to using it. Also, there is now a GuC and HuC for ADL-P, so
> use those too.
I recall discussion about splitting UC_FW meta
Hi Maxime
On Wed, 7 Jul 2021 at 10:51, Maxime Ripard wrote:
>
> Hi,
>
> Those are three fixes for race conditions we currently have in the vc4 HDMI
> driver with regard to the interrupts handling.
>
> The first two are fixing an issue where the handler will be removed by devm
> after the resource
On 07.07.2021 02:57, John Harrison wrote:
> On 7/3/2021 01:21, Martin Peres wrote:
>> On 02/07/2021 18:07, Michal Wajdeczko wrote:
>>> On 02.07.2021 10:09, Martin Peres wrote:
On 02/07/2021 10:29, Pekka Paalanen wrote:
> On Thu, 1 Jul 2021 21:28:06 +0200
> Daniel Vetter wrote:
On Tue, Jul 06, 2021 at 07:09:37PM -0400, Felix Kuehling wrote:
Am 2021-07-06 um 5:44 p.m. schrieb Alex Deucher:
On Tue, Jul 6, 2021 at 7:16 AM Sasha Levin wrote:
From: Yifan Zhang
[ Upstream commit 631003101c516ea29a74aee59666708857b9a805 ]
If GC has entered CGPG, ringing doorbell > first
Am Dienstag, dem 06.07.2021 um 07:11 -0400 schrieb Sasha Levin:
> From: Tian Tao
>
> [ Upstream commit 7d614ab2f20503ed8766363d41f8607337571adf ]
>
> fixed the below warning:
> drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c:84:2-8: WARNING: NULL check
> before some freeing functions is not needed.
On Wed, Jul 7, 2021 at 11:30 AM Christian König
wrote:
>
> Am 02.07.21 um 23:38 schrieb Daniel Vetter:
> > This is a very confusingly named function, because not just does it
> > init an object, it arms it and provides a point of no return for
> > pushing a job into the scheduler. It would be nice
On Wed, Jul 7, 2021 at 11:26 AM Christian König
wrote:
>
> Am 02.07.21 um 23:38 schrieb Daniel Vetter:
> > Instead of just a callback we can just glue in the gem helpers that
> > panfrost, v3d and lima currently use. There's really not that many
> > ways to skin this cat.
> >
> > On the naming bik
On Wed, Jul 7, 2021 at 11:08 AM Lucas Stach wrote:
> Am Freitag, dem 02.07.2021 um 23:38 +0200 schrieb Daniel Vetter:
> > We need to pull the drm_sched_job_init much earlier, but that's very
> > minor surgery.
> >
> > Signed-off-by: Daniel Vetter
> > Cc: Lucas Stach
> > Cc: Russell King
> > Cc:
On Wed, Jul 7, 2021 at 1:26 PM Daniel Vetter wrote:
> On Wed, Jul 7, 2021 at 11:08 AM Lucas Stach wrote:
> > Am Freitag, dem 02.07.2021 um 23:38 +0200 schrieb Daniel Vetter:
> > > We need to pull the drm_sched_job_init much earlier, but that's very
> > > minor surgery.
> > >
> > > Signed-off-by:
On Wed, Jul 7, 2021 at 10:54 AM Lucas Stach wrote:
>
> Hi Daniel,
>
> I'm feeling like I miss a ton of context here, so some maybe dumb
> questions/remarks below.
>
> Am Dienstag, dem 06.07.2021 um 12:12 +0200 schrieb Daniel Vetter:
> > There's only one exclusive slot, and we must not break the or
On Wed, Jul 07, 2021 at 09:03:03AM +, Simon Ser wrote:
> Hi,
>
> Thanks for working on this. Do you have plans for user-space
> implementations and IGT?
Note that these parts are mandatory, and there's a patch floating around
further clarifying what's all expected for new properties:
https:/
On Tue, Jul 06, 2021 at 05:21:42PM +0800, Huacai Chen wrote:
> Hi, Daniel,
>
> On Tue, Jul 6, 2021 at 4:21 PM Daniel Vetter wrote:
> >
> > On Mon, Jul 05, 2021 at 06:05:03PM +0800, Huacai Chen wrote:
> > > Currently, vga_arb_device_init() selects the first probed VGA device
> > > with VGA legacy
On Mon, Jul 05, 2021 at 02:53:06PM +0100, Matthew Auld wrote:
> For discrete, users of pin_map() needs to obey the same rules at the TTM
> backend, where we map system only objects as WB, and everything else as
> WC. The simplest for now is to just force the correct mapping type as
> per the new ru
Am 07.07.21 um 12:52 schrieb Lucas Stach:
Am Dienstag, dem 06.07.2021 um 07:11 -0400 schrieb Sasha Levin:
From: Tian Tao
[ Upstream commit 7d614ab2f20503ed8766363d41f8607337571adf ]
fixed the below warning:
drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c:84:2-8: WARNING: NULL check
before some
Am 07.07.21 um 13:14 schrieb Daniel Vetter:
On Wed, Jul 7, 2021 at 11:30 AM Christian König
wrote:
Am 02.07.21 um 23:38 schrieb Daniel Vetter:
This is a very confusingly named function, because not just does it
init an object, it arms it and provides a point of no return for
pushing a job into
On Wed, Jul 7, 2021 at 1:57 PM Christian König wrote:
> Am 07.07.21 um 13:14 schrieb Daniel Vetter:
> > On Wed, Jul 7, 2021 at 11:30 AM Christian König
> > wrote:
> >> Am 02.07.21 um 23:38 schrieb Daniel Vetter:
> >>> This is a very confusingly named function, because not just does it
> >>> init
Am 06.07.21 um 14:23 schrieb Daniel Vetter:
On Tue, Jul 06, 2021 at 02:21:10PM +0200, Christoph Hellwig wrote:
On Tue, Jul 06, 2021 at 10:40:37AM +0200, Daniel Vetter wrote:
Greg, I hope this will be good enough for you to merge this code.
So we're officially going to use dri-devel for technic
Am Mittwoch, dem 07.07.2021 um 13:37 +0200 schrieb Daniel Vetter:
> On Wed, Jul 7, 2021 at 10:54 AM Lucas Stach wrote:
> >
> > Hi Daniel,
> >
> > I'm feeling like I miss a ton of context here, so some maybe dumb
> > questions/remarks below.
> >
> > Am Dienstag, dem 06.07.2021 um 12:12 +0200 sch
Am Mittwoch, dem 07.07.2021 um 13:32 +0200 schrieb Daniel Vetter:
> On Wed, Jul 7, 2021 at 1:26 PM Daniel Vetter wrote:
> > On Wed, Jul 7, 2021 at 11:08 AM Lucas Stach wrote:
> > > Am Freitag, dem 02.07.2021 um 23:38 +0200 schrieb Daniel Vetter:
> > > > We need to pull the drm_sched_job_init much
On Wed, Jul 7, 2021 at 2:17 PM Christian König
wrote:
> Am 06.07.21 um 14:23 schrieb Daniel Vetter:
> > On Tue, Jul 06, 2021 at 02:21:10PM +0200, Christoph Hellwig wrote:
> >> On Tue, Jul 06, 2021 at 10:40:37AM +0200, Daniel Vetter wrote:
> Greg, I hope this will be good enough for you to mer
Am 07.07.21 um 14:13 schrieb Daniel Vetter:
On Wed, Jul 7, 2021 at 1:57 PM Christian König wrote:
Am 07.07.21 um 13:14 schrieb Daniel Vetter:
On Wed, Jul 7, 2021 at 11:30 AM Christian König
wrote:
Am 02.07.21 um 23:38 schrieb Daniel Vetter:
This is a very confusingly named function, because
On Wed, Jul 7, 2021 at 2:31 PM Lucas Stach wrote:
>
> Am Mittwoch, dem 07.07.2021 um 13:37 +0200 schrieb Daniel Vetter:
> > On Wed, Jul 7, 2021 at 10:54 AM Lucas Stach wrote:
> > >
> > > Hi Daniel,
> > >
> > > I'm feeling like I miss a ton of context here, so some maybe dumb
> > > questions/remar
On Tue, Jul 06, 2021 at 05:45:27PM +0200, Stefan Wahren wrote:
> Hi Maxime,
>
> Am 06.07.21 um 15:21 schrieb Maxime Ripard:
> > Hi Stefan,
> >
> > On Tue, Jul 06, 2021 at 12:48:05PM +0200, Stefan Wahren wrote:
> >> Am 06.07.21 um 11:58 schrieb Maxime Ripard:
> >>> Hi,
> >>>
> >>> On Mon, Jul 05, 2
The drm_encoder crtc pointer isn't really fit for an atomic driver,
let's rely on the connector state instead.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 39 ++
1 file changed, 26 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/
Hi Maxime,
I love your patch! Yet something to improve:
[auto build test ERROR on drm-tip/drm-tip]
[also build test ERROR on drm-intel/for-linux-next next-20210707]
[cannot apply to anholt/for-next v5.13]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting
Refer to DP link CTS 1.2/1.4 spec, the following test case request
source read DPCD 200h - 205h to get latest link status from sink.
(4.3.2.4) Handling of IRQ HPD Pulse with No Error Status Bits Set
(400.3.2.1) Successful Link Re-training After IRQ HPD Pulse
Due to Loss of Symbol Lock:
Hi, Frank:
Frank Wunderlich 於 2021年7月6日 週二 下午7:54寫道：
>
> Hi Daniel
>
> > Gesendet: Dienstag, 06. Juli 2021 um 13:20 Uhr
> > Von: "Daniel Vetter"
> > An: "Frank Wunderlich"
> > Cc: "Maarten Lankhorst" , "Maxime
> > Ripard" , "Thomas Zimmermann" ,
> > "David Airlie" , "Daniel Vetter" ,
> > dri
Hi, Frank:
Frank Wunderlich 於 2021年7月6日 週二 下午7:54寫道：
>
> Hi Daniel
>
> > Gesendet: Dienstag, 06. Juli 2021 um 13:20 Uhr
> > Von: "Daniel Vetter"
> > An: "Frank Wunderlich"
> > Cc: "Maarten Lankhorst" , "Maxime
> > Ripard" , "Thomas Zimmermann" ,
> > "David Airlie" , "Daniel Vetter" ,
> > dri
> +DP_LINK_STATUS_SIZE + 2);
Suggestion: use sizeof(full_link_stat) here instead to avoid this
getting out-of-sync with the real array size?
Hi Dave and Daniel,
Here goes drm-intel-next-fixes-2021-07-07:
One fix targeting stable for display DP VSC, plus DG1 display fix and
a bug fix of IRQs usages and cleanup references to the DRM IRQ midlayer.
Thanks,
Rodrigo.
The following changes since commit 8a02ea42bc1d4c448caf1bab0e05899dad503
On Wed, July 7, 2021, 3:05 p.m., Simon Ser wrote:
>> + DP_LINK_STATUS_SIZE + 2);
>
>Suggestion: use sizeof(full_link_stat) here instead to avoid this getting
>out-of-sync with the real array size?
>
I will update v2 patch later. Thanks for comment!
Best regards,
Refer to DP link CTS 1.2/1.4 spec, the following test case request
source read DPCD 200h - 205h to get latest link status from sink.
(4.3.2.4) Handling of IRQ HPD Pulse with No Error Status Bits Set
(400.3.2.1) Successful Link Re-training After IRQ HPD Pulse
Due to Loss of Symbol Lock:
Am 07.07.21 um 16:19 schrieb Maxime Ripard:
The drm_encoder crtc pointer isn't really fit for an atomic driver,
let's rely on the connector state instead.
Signed-off-by: Maxime Ripard
Acked-by: Thomas Zimmermann
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 39 ++
On Wed, Jul 07, 2021 at 11:34:36AM +0300, Jani Nikula wrote:
On Tue, 06 Jul 2021, Lucas De Marchi wrote:
On Mon, Jul 05, 2021 at 02:52:31PM +0300, Jani Nikula wrote:
On Fri, 02 Jul 2021, Tvrtko Ursulin wrote:
On 01/07/2021 21:23, Matt Roper wrote:
From: Lucas De Marchi
Besides the arch ve
On Wed, Jul 07, 2021 at 09:39:03AM +0200, Daniel Vetter wrote:
On Wed, Jul 7, 2021 at 12:48 AM Lucas De Marchi
wrote:
On Fri, Jul 02, 2021 at 11:21:10AM +0200, Daniel Vetter wrote:
>On Thu, Jul 1, 2021 at 10:26 PM Matt Roper wrote:
>>
>> From: Paulo Zanoni
>>
>> The current interrupt handler
On Wed, 07 Jul 2021, Lee Shawn C wrote:
> Refer to DP link CTS 1.2/1.4 spec, the following test case request
> source read DPCD 200h - 205h to get latest link status from sink.
>
> (4.3.2.4) Handling of IRQ HPD Pulse with No Error Status Bits Set
> (400.3.2.1) Successful Link Re-training After IRQ
Hi Jagan,
thanks for the patch.
Tested-by: Yannick Fertre
On 7/4/21 3:59 PM, Jagan Teki wrote:
As dw-mipi-dsi supported all possible ways to find the DSI
devices. It can take multiple iterations for ltdc to find
all components attached to the DSI bridge.
The current ltdc driver failed to fi
Hi Jagan,
Sorry for the delay. Thanks for the patch.
Tested-by: Yannick Fertre
On 7/4/21 4:03 PM, Jagan Teki wrote:
Finding panel_or_bridge might vary based on associated
DSI devices like DSI panel, bridge, and I2C based DSI
bridge.
1. DSI panels and bridges will invoke the host attach
On Wed, Jul 7, 2021 at 2:58 PM Christian König wrote:
> Am 07.07.21 um 14:13 schrieb Daniel Vetter:
> > On Wed, Jul 7, 2021 at 1:57 PM Christian König
> > wrote:
> >> Am 07.07.21 um 13:14 schrieb Daniel Vetter:
> >>> On Wed, Jul 7, 2021 at 11:30 AM Christian König
> >>> wrote:
> Am 02.07.2
Hi,
> Gesendet: Mittwoch, 07. Juli 2021 um 17:03 Uhr
> Von: "Chun-Kuang Hu"
> I think you have done many experiment [1] and you bisect between
> 2e4773915223 (good) and be18cd1fcae2 (bad), and you are confused by
> merge commit.
> You may refer to [2] and it may help you to understand git bisect
On 07/07, Beatriz Martins de Carvalho wrote:
> Development vkms_config_debufs in vkms_drv.c for the long term plan of
> making vkms configurable and have multiple different instances it's
> useful to be able to get at the config of each instance in debugfs
Hi Beatriz,
Thanks for your patch.
Chang
On 2021-07-06 11:36 a.m., Colin Ian
King wrote:
Hi,
Static analysis with Coverity on linux-next has found a potential null
pointer dereference in function svm_range_restore_pages in
drivers/gpu/drm/amd/amdkfd/kfd_svm.c from the following commit:
commit d4eb
On 2021-07-06 9:08 p.m., Felix Kuehling
wrote:
Am 2021-07-06 um 11:36 a.m. schrieb Colin Ian King:
Hi,
Static analysis with Coverity on linux-next has found a potential null
pointer dereference in function svm_range_restore_pages in
drivers/
On Tue, Jul 06, 2021 at 03:51:00PM -0700, John Harrison wrote:
> On 7/6/2021 15:20, Matthew Brost wrote:
> > CTB writes are now in the path of command submission and should be
> > optimized for performance. Rather than reading CTB descriptor values
> > (e.g. head, tail) which could result in access
From: Rob Clark
It turns out that when the display is enabled by the bootloader, we can
get some transient iommu faults from the display. Which doesn't go over
too well when we install a fault handler that is gpu specific. To avoid
this, defer installing the fault handler until we get around to
Hi Maxime,
Am 07.07.21 um 15:11 schrieb Maxime Ripard:
> On Tue, Jul 06, 2021 at 05:45:27PM +0200, Stefan Wahren wrote:
>> Hi Maxime,
>>
>> Am 06.07.21 um 15:21 schrieb Maxime Ripard:
>>> Hi Stefan,
>>>
>>> On Tue, Jul 06, 2021 at 12:48:05PM +0200, Stefan Wahren wrote:
Am 06.07.21 um 11:58 sc
Commit c816723b6b8a ("drm/i915/gt: replace IS_GEN and friends with
GRAPHICS_VER") converted INTEL_GEN and friends to the new version check
macros. Meanwhile, some changes sneaked in to use INTEL_GEN. Remove the
last users so we can remove the macros.
Signed-off-by: Lucas De Marchi
---
drivers/g
Now that all the codebase is converted to the new *VER macros, remove
the old GEN ones.
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/i915_drv.h | 15 ---
1 file changed, 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 6
Commit 161058fb899e ("drm/i915: Add remaining conversions to GRAPHICS_VER")
did the last conversions to the new macros for version checks, but some
some changes sneaked in to use INTEL_GEN. Remove the last users so
we can remove the macros.
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915
Finish the conversion to the new VER macros and nuke the old macros so
we don't have more changes sneaking in.
Initially I thought about waiting for a backmerge from drm-next in
drm-intel-next so I could use a topic branch to finish the conversion
and nuke the macro, merging the topic branch in bo
On 7/7/2021 10:50, Matthew Brost wrote:
On Tue, Jul 06, 2021 at 03:51:00PM -0700, John Harrison wrote:
On 7/6/2021 15:20, Matthew Brost wrote:
CTB writes are now in the path of command submission and should be
optimized for performance. Rather than reading CTB descriptor values
(e.g. head, tail
On Wed, 07 Jul 2021, Lucas De Marchi wrote:
> Finish the conversion to the new VER macros and nuke the old macros so
> we don't have more changes sneaking in.
>
> Initially I thought about waiting for a backmerge from drm-next in
> drm-intel-next so I could use a topic branch to finish the convers
[+cc linux-pci]
On Mon, Jul 5, 2021 at 5:04 AM Huacai Chen wrote:
>
> Currently, vga_arb_device_init() selects the first probed VGA device
> with VGA legacy resources enabled as the default device. However, some
> BMC-based VGA cards (e.g., AST2500 and HiSilicon D05) don't enable VGA
> legacy res
CTB writes are now in the path of command submission and should be
optimized for performance. Rather than reading CTB descriptor values
(e.g. head, tail) which could result in accesses across the PCIe bus,
store shadow local copies and only read/write the descriptor values when
absolutely necessary
1 - 100 of 126 matches
Mail list logo
