The driver originally use an atomic_t for keep track of the power
status, which makes the driver more complicated than needed, and has
some race condition as it's possible to have the power on and power off
sequence going at the same time.
This patch remove the usage of the atomic_t power_status,
Add suspend / resume hooks for anx7625 driver, that power off the device
on suspend and power on the device on resume if it was previously
powered.
Signed-off-by: Pi-Hsun Shih
---
drivers/gpu/drm/bridge/analogix/anx7625.c | 27 +++
1 file changed, 27 insertions(+)
diff --git
The driver originally use an atomic_t for keep track of the power
status, which makes the driver more complicated than needed, and has
some race condition as it's possible to have the power on and power off
sequence going at the same time.
This patch remove the usage of the atomic_t power_status,
Add suspend / resume hooks for anx7625 driver, that power off the device
on suspend and power on the device on resume if it was previously
powered.
Signed-off-by: Pi-Hsun Shih
Change-Id: I62122cc2a4eafdfce4859cbb419edc39875ebe3b
---
drivers/gpu/drm/bridge/analogix/anx7625.c | 27
The CDP DP component of the rockchip GPU driver requires firmware
so define MODULE_FIRMWARE for rockchip/dptx.bin so the details
are available in the module info.
Signed-off-by: Peter Robinson
---
drivers/gpu/drm/rockchip/cdn-dp-core.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/
'ret' is known to be 0 here.
No error code is available, so just remove it from the error message.
Fixes: 72330b0eeefc ("i.MX Framebuffer: Use readl/writel instead of direct
pointer deref")
Signed-off-by: Christophe JAILLET
---
drivers/video/fbdev/imxfb.c | 2 +-
1 file changed, 1 insertion(+),
From: Daniel Vetter
Date: 2021-05-01 01:42:20
To: kernel test robot
Cc: Bernard Zhao ,Jani Nikula
,Joonas Lahtinen
,Rodrigo Vivi ,David
Airlie ,Daniel Vetter
,intel-...@lists.freedesktop.org,dri-devel@lists.freedesktop.org,linux-ker...@vger.kernel.org,kbuild-...@lists.01.org
Subject: Re: [
Hello Christophe,
[dropping krzysztof...@poczta.fm from recipents, the address doesn't
seem to exist]
On Fri, May 07, 2021 at 09:11:19AM +0200, Christophe JAILLET wrote:
> Le 07/05/2021 à 07:05, Uwe Kleine-König a écrit :
> > On Thu, May 06, 2021 at 08:57:05PM +0200, Christophe JAILLET wrote:
> >
From: Tvrtko Ursulin
This is an alternative proposed fix for the below references bug report
where dma fence error propagation is causing undesirable change in
behaviour post GPU hang/reset.
Approach in this patch is to simply stop propagating all dma fence errors
by default since that seems to
Adds support for the Yes YTS700TLBC-02-100C which is a 1024x600 TFT
display panel with LVDS interface.
Signed-off-by: Mike Looijmans
---
drivers/gpu/drm/panel/panel-simple.c | 30
1 file changed, 30 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/
Le 07/05/2021 à 07:05, Uwe Kleine-König a écrit :
Hello Christophe,
On Thu, May 06, 2021 at 08:57:05PM +0200, Christophe JAILLET wrote:
'ret' is known to be 0 here.
No error code is available, so just remove it from the error message.
Fixes: 72330b0eeefc ("i.MX Framebuffer: Use readl/writel in
Adds these panels to the dt bindings:
- Yes Optoelectronics YTS700TLBC-02-100C
- Innolux G104AGE-L02
Signed-off-by: Mike Looijmans
---
.../devicetree/bindings/display/panel/panel-simple.yaml | 4
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/p
Adds support for the Innolux G104AGE-L02 which is a 800x600 TFT
display panel with LVDS interface.
Signed-off-by: Mike Looijmans
---
drivers/gpu/drm/panel/panel-simple.c | 34
1 file changed, 34 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/driv
When encoder validation of a display mode fails, retry with less bandwidth
heavy YCbCr420 color mode, if available. This enables some HDMI 1.4 setups
to support 4k60Hz output, which previously failed silently.
AMDGPU had nearly the exact same issue. This problem description is
therefore copied fro
Moves some checks that later will be performed 2 times to an own function.
This avoids duplicate code later on.
Signed-off-by: Werner Sembach
---
drivers/gpu/drm/i915/display/intel_hdmi.c | 41 ++-
1 file changed, 26 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/dr
Couples the decission between RGB and YCbCr420 mode and the check if the
port clock can archive the required frequency. Other checks and
configuration steps that where previously done in between can also be done
before or after.
This allows for are cleaner implementation of retrying different colo
When encoder validation of a display mode fails, retry with less bandwidth
heavy YCbCr420 color mode, if available. This enables some HDMI 1.4 setups
to support 4k60Hz output, which previously failed silently.
AMDGPU had nearly the exact same issue. This problem description is
therefore copied fro
From: Tvrtko Ursulin
Same workaround was listed two times - once under the Gen7 block and once
under the Haswell section.
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Lucas De Marchi
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gp
On Thu, 6 May 2021 at 21:49, Marek Vasut wrote:
>
> On 5/6/21 7:03 PM, Dave Stevenson wrote:
> > On Thu, 6 May 2021 at 13:48, Marek Vasut wrote:
> >>
> >> On 5/6/21 11:45 AM, Dave Stevenson wrote:
> >>> Hi Marek
> >>
> >> Hi,
> >>
> >>> I'm taking an interest as there are a number of Raspberry Pi
On Thu, May 06, 2021 at 10:06:32PM -0400, Kenny Ho wrote:
> Sorry for the late reply (I have been working on other stuff.)
>
> On Fri, Feb 5, 2021 at 8:49 AM Daniel Vetter wrote:
> >
> > So I agree that on one side CU mask can be used for low-level quality
> > of service guarantees (like the CLOS
On Thu, May 06, 2021 at 12:25:06PM -0400, Andrey Grodzovsky wrote:
>
>
> On 2021-05-06 5:40 a.m., Daniel Vetter wrote:
> > On Fri, Apr 30, 2021 at 01:27:37PM -0400, Andrey Grodzovsky wrote:
> > >
> > >
> > > On 2021-04-30 6:25 a.m., Daniel Vetter wrote:
> > > > On Thu, Apr 29, 2021 at 04:34:55P
On Thu, 6 May 2021 at 21:51, Marek Vasut wrote:
>
> On 5/6/21 6:03 PM, Frieder Schrempf wrote:
> > On 06.05.21 17:46, Marek Vasut wrote:
> >> On 5/6/21 5:38 PM, Frieder Schrempf wrote:
> >> [...]
> >>> Works on i.MX8MM with SN65DSI84 and a single link LVDS display (1024x600)
> >>> and from my per
It's very confusing for userspace to have to deal with inconsistencies
here, and some drivers screwed this up a bit. Most just ommitted the
format list when they meant to say that only linear modifier is
allowed, but some also meant that only implied modifiers are
acceptable (because actually none
[Bug][AST2500]
V1:
When AST2500 acts as stand-alone VGA so that DRAM and DVO initialization
have to be achieved by VGA driver with P2A (PCI to AHB) enabling.
However, HW suggests disable Fast reset mode after DRAM initializaton,
because fast reset mode is mainly designed for ARM ICE debugger.
Once
On Thu, May 06, 2021 at 12:10:15PM -0400, Felix Kuehling wrote:
> Am 2021-05-04 um 9:00 a.m. schrieb Daniel Vetter:
> > On Fri, Apr 30, 2021 at 09:57:45PM -0400, Felix Kuehling wrote:
> >> We have been working on a prototype supporting CRIU (Checkpoint/Restore
> >> In Userspace) for accelerated com
https://bugzilla.kernel.org/show_bug.cgi?id=51381
--- Comment #54 from Luca T. (luca.trom...@gmail.com) ---
(In reply to Luca T. from comment #53)
> Dear all,
> I'm using Linux Mint, before I used Arch Linux and also Red Hat, but my
> laptop suffer of the same problem because of this kernel bug wh
We generally want to first call i915_gem_object_init_memory_region()
before calling into get_pages(), since this sets up various bits of
state which might be needed there. Currently for stolen this doesn't
matter much, but it might in the future, and at the very least this
makes things consistent w
https://bugzilla.kernel.org/show_bug.cgi?id=51381
--- Comment #55 from Luca T. (luca.trom...@gmail.com) ---
Dear all,
to fix this issue permanently so that I can quickly switch between multiple
accounts and I'm also able to resume from suspend my laptop I added the
following options into:
- add
On Thu, May 06, 2021 at 01:14:10PM -0400, Lyude Paul wrote:
I would drop this patch for all of the stable kernel versions, it doesn't
really fix any user reported issues.
Will do, thanks!
--
Thanks,
Sasha
On 2021/05/03 22:41, Tetsuo Handa wrote:
> Therefore, I guess that the problem is that fbcon_putcs() from
> do_update_region() from
> redraw_screen() from vt_kdsetmode(KD_TEXT) from ioctl(fd, KDSETMODE, KD_TEXT)
> tries to
> redraw 2 x 16640 despite memory amount allocated for actual screen is on
On Fri, May 7, 2021 at 2:44 PM Pi-Hsun Shih wrote:
>
> The driver originally use an atomic_t for keep track of the power
> status, which makes the driver more complicated than needed, and has
> some race condition as it's possible to have the power on and power off
> sequence going at the same tim
On Wed, 5 May 2021 at 11:03, Marek Vasut wrote:
>
> Add driver for TI SN65DSI83 Single-link DSI to Single-link LVDS bridge
> and TI SN65DSI84 Single-link DSI to Dual-link or 2x Single-link LVDS
> bridge. TI SN65DSI85 is unsupported due to lack of hardware to test on,
> but easy to add.
>
> The dri
On 05/05/2021 14:12, Tony Lindgren wrote:
* Tony Lindgren [210503 12:18]:
I think we still fix the dispc related issue too, otherwise the parent
child_count will just keep increasing on each suspend. I check that
again though.
After tons more debugging, I found the root cause for the parent c
Right now the HDMI properties like vendor and product ids are hardcoded
in the function "intel_hdmi_compute_spd_infoframe()".
ret = hdmi_spd_infoframe_init(frame, "Intel", "Integrated gfx").
This patch enables the possibility of setting vendor and product id fields
of the Infoframe structure in t
Right now the HDMI properties like vendor and product ids are hardcoded
in the function "intel_hdmi_compute_spd_infoframe()".
ret = hdmi_spd_infoframe_init(frame, "Intel", "Integrated gfx").
This patch enables the possibility of setting vendor and product id fields
of the Infoframe structure in
Hi,
hdmi-codec allows to have a lot of HDMI-audio related infrastructure in place,
it's missing a few controls to be able to provide HBR passthrough. This series
adds more infrastructure for the drivers, and leverages it in the vc4 HDMI
controller driver.
One thing that felt a bit weird is that e
In some situations, like a codec probe, we need to provide an IEC status
default but don't have access to the sampling rate and width yet since
no stream has been configured yet.
Each and every driver has its own default, whereas the core iec958 code
also has some buried in the snd_pcm_create_iec9
Signed-off-by: Maxime Ripard
---
sound/soc/codecs/hdmi-codec.c | 66 +--
1 file changed, 64 insertions(+), 2 deletions(-)
diff --git a/sound/soc/codecs/hdmi-codec.c b/sound/soc/codecs/hdmi-codec.c
index bc0d695d2df0..45081f928680 100644
--- a/sound/soc/codecs/hdmi
We're going to add more controls to support the IEC958 output, so let's
rework the control registration a bit to support more of them.
Signed-off-by: Maxime Ripard
---
sound/soc/codecs/hdmi-codec.c | 43 ++-
1 file changed, 27 insertions(+), 16 deletions(-)
diff
The IEC958 status bit is usually set by the userspace after hw_params
has been called, so in order to use whatever is set by the userspace, we
need to implement the prepare hook. Let's add it to the hdmi_codec_ops,
and mandate that either prepare or hw_params is implemented.
Signed-off-by: Maxime
From: Dom Cobley
Symptom is random switching of speakers when using multichannel.
Repeatedly running speakertest -c8 occasionally starts with
channels jumbled. This is fixed with HD_CTL_WHOLSMP.
The other bit looks beneficial and apears harmless in testing so
I'd suggest adding it too.
Documen
From: Dom Cobley
The hardware uses this for generating the right audio
data island packets when using formats other than PCM
Signed-off-by: Dom Cobley
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 48 ++
drivers/gpu/drm/vc4/vc4_regs.h | 30 +
From: Dom Cobley
Without this bit set, HDMI_MAI_FORMAT doesn't pick up
the format and samplerate from DVP_CFG_MAI0_FMT and you
can't get HDMI_HDMI_13_AUDIO_STATUS_1 to indicate HBR mode
Signed-off-by: Dom Cobley
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 1 +
1 file cha
From: Dom Cobley
This was a workaround for bugs in hardware on earlier Pi models
and wasn't totally successful.
It makes audio quality worse on a Pi4 at the higher sample rates
Signed-off-by: Dom Cobley
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 22 ++--
The hdmi-codec brings a lot of advanced features, including the HDMI
channel mapping. Let's use it in our driver instead of our own codec.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/Kconfig| 1 +
drivers/gpu/drm/vc4/vc4_hdmi.c | 243 +++--
drivers/gpu/
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 26 --
drivers/gpu/drm/vc4/vc4_hdmi.h | 2 --
2 files changed, 12 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index 19739b57d067..a5780da70c1
From: Dom Cobley
Enable NO_WAIT_RESP, DMA_WIDE_SOURCE, DMA_WIDE_DEST, and bump the DMA
panic and AXI priorities to avoid any DMA transfer error with HBR audio
(8 channel, 192Hz).
Signed-off-by: Dom Cobley
Signed-off-by: Maxime Ripard
---
arch/arm/boot/dts/bcm2711.dtsi | 4 ++--
1 file changed
From: Sean Paul
This patch fixes the following error:
drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm_8960.c:425:11: error: variable
'parent_name' is uninitialized when used here
[-Werror,-Wuninitialized]
snprintf(parent_name, 32, "dsi%dvco_clk", pll_28nm->phy->id);
^~
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 v3:
- Rework the e
The current code does a binary OR on the possible_crtcs variable of the
TXP encoder, while we want to set it to that value instead.
Cc: # v5.9+
Fixes: 39fcb2808376 ("drm/vc4: txp: Turn the TXP into a CRTC of its own")
Acked-by: Thomas Zimmermann
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm
The vc4_set_crtc_possible_masks is meant to run over all the encoders
and then set their possible_crtcs mask to their associated pixelvalve.
However, since the commit 39fcb2808376 ("drm/vc4: txp: Turn the TXP into
a CRTC of its own"), the TXP has been turned to a CRTC and encoder of
its own, and w
The vc4_crtc_config_pv will need to access the drm_atomic_state
structure and its only parent function, vc4_crtc_atomic_enable already
has access to it. Let's pass it as a parameter.
Fixes: 792c3132bc1b ("drm/vc4: encoder: Add finer-grained encoder callbacks")
Signed-off-by: Maxime Ripard
---
dr
The vc4_get_crtc_encoder function currently only works when the
connector->state->crtc pointer is set, which is only true when the
connector is currently enabled.
However, we use it as part of the disable path as well, and our lookup
will fail in that case, resulting in it returning a null pointer
At boot, we can't rely on the vc4_get_crtc_encoder since we don't have a
state yet and thus will not be able to figure out which connector is
attached to our CRTC.
However, we have a muxing bit in the CRTC register we can use to get the
encoder currently connected to the pixelvalve. We can thus re
Since we fixed the hooks to disable the encoder at boot, we now have an
unbalanced clk_disable call at boot since we never enabled them in the
first place.
Let's mimic the state of the hardware and enable the clocks at boot if
the controller is enabled to get the use-count right.
Cc: # v5.10+
Fi
We'll need to have the HVS binding before the HDMI controllers so that
we can check whether the firmware allows to run in 4kp60. Reorder a bit
the component list, and document the current constraints we're aware of.
Acked-by: Dave Stevenson
Acked-by: Thomas Zimmermann
Signed-off-by: Maxime Ripar
The BVB clock rate computation doesn't take into account a mode clock of
594MHz that we're going to need to support 4k60.
Acked-by: Thomas Zimmermann
Reviewed-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 17 +
1 file changed, 9 insertions
In order to reach the frequencies needed to output at 594MHz, the
firmware needs to be configured with the appropriate parameters in the
config.txt file (enable_hdmi_4kp60 and force_turbo).
Let's detect it at bind time, warn the user if we can't, and filter out
the relevant modes.
Acked-by: Thoma
The HDMI controller on the BCM2711 includes a scrambler in order to
reach the HDMI 2.0 modes that require it. Let's add the support for it.
Acked-by: Thomas Zimmermann
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 64 +
drivers/gpu/drm/vc4/vc
It looks like some displays (like the LG 27UL850-W) don't enable the
scrambling when the HDMI driver enables it. However, if we set later the
scrambler enable bit, the display will work as expected.
Let's create delayed work queue to periodically look at the display
scrambling status, and if it's
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
Hi,
we've received a regression report showing NULL dereference Oops with
radeon driver on 5.12 kernel:
https://bugzilla.opensuse.org/show_bug.cgi?id=1185516
It turned out that the recent TTM cleanup / refactoring via commit
0575ff3d33cd ("drm/radeon: stop using pages with
drm_prime_sg_to_page_
Hi Takashi,
Am 07.05.21 um 17:08 schrieb Takashi Iwai:
Hi,
we've received a regression report showing NULL dereference Oops with
radeon driver on 5.12 kernel:
https://bugzilla.opensuse.org/show_bug.cgi?id=1185516
It turned out that the recent TTM cleanup / refactoring via commit
0575ff3d33c
On Fri, May 7, 2021 at 4:59 AM Daniel Vetter wrote:
>
> Hm I missed that. I feel like time-sliced-of-a-whole gpu is the easier gpu
> cgroups controler to get started, since it's much closer to other cgroups
> that control bandwidth of some kind. Whether it's i/o bandwidth or compute
> bandwidht is
On 2021-05-07 5:11 a.m., Daniel Vetter wrote:
On Thu, May 06, 2021 at 12:25:06PM -0400, Andrey Grodzovsky wrote:
On 2021-05-06 5:40 a.m., Daniel Vetter wrote:
On Fri, Apr 30, 2021 at 01:27:37PM -0400, Andrey Grodzovsky wrote:
On 2021-04-30 6:25 a.m., Daniel Vetter wrote:
On Thu, Apr 29
On Thu, May 06, 2021 at 03:30:45PM -0700, Linus Torvalds wrote:
> [ You had a really odd Reply-to on this one ]
>
> On Mon, May 3, 2021 at 12:15 PM Daniel Vetter wrote:
> >
> > Anyway here's a small pull for you to ponder, now that the big ones are
> > all through.
>
> Well, _now_ I'm all caught
On Fri, May 07, 2021 at 11:33:46AM -0400, Kenny Ho wrote:
> On Fri, May 7, 2021 at 4:59 AM Daniel Vetter wrote:
> >
> > Hm I missed that. I feel like time-sliced-of-a-whole gpu is the easier gpu
> > cgroups controler to get started, since it's much closer to other cgroups
> > that control bandwidt
On Fri, May 7, 2021 at 12:13 PM Daniel Vetter wrote:
>
> On Fri, May 07, 2021 at 11:33:46AM -0400, Kenny Ho wrote:
> > On Fri, May 7, 2021 at 4:59 AM Daniel Vetter wrote:
> > >
> > > Hm I missed that. I feel like time-sliced-of-a-whole gpu is the easier gpu
> > > cgroups controler to get started,
On Fri, May 07, 2021 at 11:39:49AM -0400, Andrey Grodzovsky wrote:
>
>
> On 2021-05-07 5:11 a.m., Daniel Vetter wrote:
> > On Thu, May 06, 2021 at 12:25:06PM -0400, Andrey Grodzovsky wrote:
> > >
> > >
> > > On 2021-05-06 5:40 a.m., Daniel Vetter wrote:
> > > > On Fri, Apr 30, 2021 at 01:27:37P
On Fri, May 07, 2021 at 12:19:13PM -0400, Alex Deucher wrote:
> On Fri, May 7, 2021 at 12:13 PM Daniel Vetter wrote:
> >
> > On Fri, May 07, 2021 at 11:33:46AM -0400, Kenny Ho wrote:
> > > On Fri, May 7, 2021 at 4:59 AM Daniel Vetter wrote:
> > > >
> > > > Hm I missed that. I feel like time-slice
On Fri, Apr 30, 2021 at 12:10:57PM -0400, Andrey Grodzovsky wrote:
>
>
> On 2021-04-30 2:47 a.m., Christian König wrote:
> >
> >
> > Am 29.04.21 um 19:06 schrieb Andrey Grodzovsky:
> > >
> > >
> > > On 2021-04-29 3:18 a.m., Christian König wrote:
> > > > I need to take another look at this pa
On Fri, May 7, 2021 at 12:26 PM Daniel Vetter wrote:
>
> On Fri, May 07, 2021 at 12:19:13PM -0400, Alex Deucher wrote:
> > On Fri, May 7, 2021 at 12:13 PM Daniel Vetter wrote:
> > >
> > > On Fri, May 07, 2021 at 11:33:46AM -0400, Kenny Ho wrote:
> > > > On Fri, May 7, 2021 at 4:59 AM Daniel Vette
On 2021-05-07 12:29 p.m., Daniel Vetter wrote:
On Fri, Apr 30, 2021 at 12:10:57PM -0400, Andrey Grodzovsky wrote:
On 2021-04-30 2:47 a.m., Christian König wrote:
Am 29.04.21 um 19:06 schrieb Andrey Grodzovsky:
On 2021-04-29 3:18 a.m., Christian König wrote:
I need to take another loo
On Fri, May 07, 2021 at 07:05:03AM +0200, Uwe Kleine-König wrote:
> Hello Christophe,
>
> On Thu, May 06, 2021 at 08:57:05PM +0200, Christophe JAILLET wrote:
> > 'ret' is known to be 0 here.
> > No error code is available, so just remove it from the error message.
> >
> > Fixes: 72330b0eeefc ("i.
On Fri, May 7, 2021 at 7:16 AM Sean Paul wrote:
>
> From: Sean Paul
>
> This patch fixes the following error:
>
> drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm_8960.c:425:11: error: variable
> 'parent_name' is uninitialized when used here
> [-Werror,-Wuninitialized]
> snprintf(parent_name, 32
On Fri, May 7, 2021 at 12:31 PM Alex Deucher wrote:
>
> On Fri, May 7, 2021 at 12:26 PM Daniel Vetter wrote:
> >
> > On Fri, May 07, 2021 at 12:19:13PM -0400, Alex Deucher wrote:
> > > On Fri, May 7, 2021 at 12:13 PM Daniel Vetter wrote:
> > > >
> > > > On Fri, May 07, 2021 at 11:33:46AM -0400,
On Fri, May 07, 2021 at 12:50:07PM -0400, Alex Deucher wrote:
> On Fri, May 7, 2021 at 12:31 PM Alex Deucher wrote:
> >
> > On Fri, May 7, 2021 at 12:26 PM Daniel Vetter wrote:
> > >
> > > On Fri, May 07, 2021 at 12:19:13PM -0400, Alex Deucher wrote:
> > > > On Fri, May 7, 2021 at 12:13 PM Daniel
On Fri, May 7, 2021 at 9:43 AM Rob Clark wrote:
>
> On Fri, May 7, 2021 at 7:16 AM Sean Paul wrote:
> >
> > From: Sean Paul
> >
> > This patch fixes the following error:
> >
> > drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm_8960.c:425:11: error: variable
> > 'parent_name' is uninitialized when used
On Fri, May 7, 2021 at 12:54 PM Daniel Vetter wrote:
>
> SRIOV is kinda by design vendor specific. You set up the VF endpoint, it
> shows up, it's all hw+fw magic. Nothing for cgroups to manage here at all.
Right, so in theory you just use the device cgroup with the VF endpoints.
> All I meant is
On Fri, May 07, 2021 at 10:49:01AM +0200, Werner Sembach wrote:
> Moves some checks that later will be performed 2 times to an own function.
> This avoids duplicate code later on.
>
> Signed-off-by: Werner Sembach
> ---
> drivers/gpu/drm/i915/display/intel_hdmi.c | 41 ++-
>
On Fri, May 07, 2021 at 10:49:02AM +0200, Werner Sembach wrote:
> Couples the decission between RGB and YCbCr420 mode and the check if the
> port clock can archive the required frequency. Other checks and
> configuration steps that where previously done in between can also be done
> before or after
On 5/7/21 10:52 AM, Ville Syrjälä wrote:
> On Fri, May 07, 2021 at 10:49:02AM +0200, Werner Sembach wrote:
>> Couples the decission between RGB and YCbCr420 mode and the check if the
>> port clock can archive the required frequency. Other checks and
>> configuration steps that where previously done
On 2021-05-07 12:24 p.m., Daniel Vetter wrote:
On Fri, May 07, 2021 at 11:39:49AM -0400, Andrey Grodzovsky wrote:
On 2021-05-07 5:11 a.m., Daniel Vetter wrote:
On Thu, May 06, 2021 at 12:25:06PM -0400, Andrey Grodzovsky wrote:
On 2021-05-06 5:40 a.m., Daniel Vetter wrote:
On Fri, Apr 3
This patch moves the DRM core's AGP code behind CONFIG_DRM_LEGACY. The
only use besides legacy, UMS drivers is radeon, which can implement the
required functionality by itself.
This patchset has no impact on the AGP support of existing drivers.
Patches 1 and 2 move some AGP code from DRM core int
Only UMs drivers use DRM's core AGP code and ioctls. Mark the icotls
as legacy. Add the _legacy_ infix to all AGP functions. Move the
declarations to the public and internal legacy header files. The agp
field in struct drm_device is now located in the structure's legacy
section. Adapt drivers to th
With the AGP code already duplicated, move over the AGP structures
from the legacy code base in to radeon. The AGP data structures that
are required by radeon are now declared within the driver. The AGP
instance is stored in struct radeon_device.agp.
Signed-off-by: Thomas Zimmermann
---
drivers/
DRM's AGP helpers for PCI are only required by legacy drivers. Put them
behind CONFIG_DRM_LEGACY and add the _legacy_ infix.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_drv.c | 4 +---
drivers/gpu/drm/drm_internal.h | 5 -
drivers/gpu/drm/drm_legacy.h | 6 ++
drive
Radeon calls DRMs core AGP helpers. These helpers are only required
by legacy drivers. Reimplement the code in radeon to uncouple radeon
from the legacy code.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/radeon/radeon.h | 8 +++
drivers/gpu/drm/radeon/radeon_agp.c | 102 +++
Acked-by: Christian König
Am 07.05.21 um 20:57 schrieb Thomas Zimmermann:
This patch moves the DRM core's AGP code behind CONFIG_DRM_LEGACY. The
only use besides legacy, UMS drivers is radeon, which can implement the
required functionality by itself.
This patchset has no impact on the AGP supp
On Fri, May 7, 2021 at 2:57 PM Thomas Zimmermann wrote:
>
> This patch moves the DRM core's AGP code behind CONFIG_DRM_LEGACY. The
> only use besides legacy, UMS drivers is radeon, which can implement the
> required functionality by itself.
>
> This patchset has no impact on the AGP support of exi
Hi Maxime,
I love your patch! Perhaps something to improve:
[auto build test WARNING on sound/for-next]
[also build test WARNING on asoc/for-next v5.12 next-20210507]
[cannot apply to anholt/for-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting
xrandr --prop and other userspace info tools have currently no way of
telling which color configuration is used on HDMI and DP ports.
The ongoing transsition from HDMI 1.4 to 2.0 and the different bandwidth
requirements of YCbCr 4:2:0 and RGB color format raise different
incompatibilities. Having
Hello,
On Fri, May 07, 2021 at 06:54:13PM +0200, Daniel Vetter wrote:
> All I meant is that for the container/cgroups world starting out with
> time-sharing feels like the best fit, least because your SRIOV designers
> also seem to think that's the best first cut for cloud-y computing.
> Whether i
On Fri, May 7, 2021 at 3:33 PM Tejun Heo wrote:
>
> Hello,
>
> On Fri, May 07, 2021 at 06:54:13PM +0200, Daniel Vetter wrote:
> > All I meant is that for the container/cgroups world starting out with
> > time-sharing feels like the best fit, least because your SRIOV designers
> > also seem to thin
Am 07.05.21 um 19:47 schrieb Ville Syrjälä:
> On Fri, May 07, 2021 at 10:49:01AM +0200, Werner Sembach wrote:
>> Moves some checks that later will be performed 2 times to an own function.
>> This avoids duplicate code later on.
>>
>> Signed-off-by: Werner Sembach
>> ---
>> drivers/gpu/drm/i915/d
Hello,
On Fri, May 07, 2021 at 03:55:39PM -0400, Alex Deucher wrote:
> The problem is temporal partitioning on GPUs is much harder to enforce
> unless you have a special case like SR-IOV. Spatial partitioning, on
> AMD GPUs at least, is widely available and easily enforced. What is
> the point o
Adding ville from Intel to also get their take on this.
In general we've been trying to move DRM to a design where we don't expose any
devices until everything is ready. That's pretty much the main reason that we
register things during bridge attach time. Note though that even before the
DDC bus i
Here's a few patches that simplify the aux handling code and bubble up
timeouts and nacks to the upper DRM layers. The goal is to get DRM to
know that the other side isn't there or that there's been a timeout,
instead of saying that everything is fine and putting some error message
into the logs.
We don't need to hold the lock to inspect the message we're going to
transfer, and we don't need to clear the busy flag either. Take the lock
later and bail out earlier if conditions aren't met.
Cc: Dmitry Baryshkov
Cc: Abhinav Kumar
Cc: Kuogee Hsieh
Cc: aravi...@codeaurora.org
Cc: Sean Paul
S
Am 07.05.21 um 19:52 schrieb Ville Syrjälä:
> On Fri, May 07, 2021 at 10:49:02AM +0200, Werner Sembach wrote:
>> Couples the decission between RGB and YCbCr420 mode and the check if the
>> port clock can archive the required frequency. Other checks and
>> configuration steps that where previously d
1 - 100 of 126 matches
Mail list logo
