Quoting Zhen Lei (2021-05-07 19:42:54)
> Fix to return a negative error code from the error handling case instead
> of 0, as done elsewhere in this function.
>
> Fixes: 070e64dc1bbc ("drm/msm/dpu: Convert to a chained irq chip")
> Reported-by: Hulk Robot
> Signed-off-by: Zhen Lei
> ---
> drivers
The user may incorrectly set the value of dma_bs->secondary_bin_count to 0.
In this case, the for loop is not entered and the 'err' value remains 0.
Fixes: 6795c985a648 ("Add support for PCI MGA cards to MGA DRM.")
Reported-by: Hulk Robot
Signed-off-by: Zhen Lei
---
drivers/gpu/drm/mga/mga_dma.
Fix to return a negative error code from the error handling case instead
of 0, as done elsewhere in this function.
Fixes: db1a0ae21461 ("drm/nouveau/bl: Assign different names to interfaces")
Reported-by: Hulk Robot
Signed-off-by: Zhen Lei
---
drivers/gpu/drm/nouveau/nouveau_backlight.c | 1 +
Fix to return a negative error code from the error handling case instead
of 0, as done elsewhere in this function.
Fixes: 070e64dc1bbc ("drm/msm/dpu: Convert to a chained irq chip")
Reported-by: Hulk Robot
Signed-off-by: Zhen Lei
---
drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c | 4 +++-
1 file cha
Fix to return a negative error code from the error handling case instead
of 0, as done elsewhere in this function.
Fixes: 7f9743abaa79 ("drm/msm: validate display and event threads")
Reported-by: Hulk Robot
Signed-off-by: Zhen Lei
---
drivers/gpu/drm/msm/msm_drv.c | 1 +
1 file changed, 1 inser
This patch adds missing MODULE_DEVICE_TABLE definition which generates
correct modalias for automatic loading of this driver when it is built
as an external module.
Reported-by: Hulk Robot
Signed-off-by: Bixuan Cui
---
drivers/gpu/drm/tdfx/tdfx_drv.c | 1 +
1 file changed, 1 insertion(+)
diff
Hello,
On Fri, May 07, 2021 at 06:30:56PM -0400, Alex Deucher wrote:
> Maybe we are speaking past each other. I'm not following. We got
> here because a device specific cgroup didn't make sense. With my
> Linux user hat on, that makes sense. I don't want to write code to a
> bunch of device sp
This adds support for controlling panel backlights over eDP using VESA's
standard backlight control interface. Luckily, Nvidia was cool enough to
never come up with their own proprietary backlight control interface (at
least, not any that I or the laptop manufacturers I've talked to are aware
of),
Since we're about to implement eDP backlight support in nouveau using the
standard protocol from VESA, we might as well just take the code that's
already written for this and move it into a set of shared DRM helpers.
Note that these helpers are intended to handle DPCD related backlight
control bit
Also, stop printing the DPCD register that failed, and just describe it
instead. Saves us from having to look up each register offset when reading
through kernel logs (plus, DPCD dumping with drm.debug |= 0x100 will give
us that anyway).
Signed-off-by: Lyude Paul
---
.../drm/i915/display/intel_d
If we can't read DP_EDP_PWMGEN_BIT_COUNT in
intel_dp_aux_vesa_calc_max_backlight() but do have a valid PWM frequency
defined in the VBT, we'll keep going in the function until we inevitably
fail on reading DP_EDP_PWMGEN_BIT_COUNT_CAP_MIN. There's not much point in
doing this, so just return early.
No functional changes, just move set_vesa_backlight_enable() closer to it's
only caller: intel_dp_aux_vesa_enable_backlight().
Signed-off-by: Lyude Paul
Reviewed-by: Rodrigo Vivi
---
.../drm/i915/display/intel_dp_aux_backlight.c | 54 +--
1 file changed, 27 insertions(+), 27 del
Since we're about to be moving this code into shared DRM helpers, we might
as well start to cache certain backlight capabilities that can be
determined from the EDP DPCD, and are likely to be relevant to the majority
of drivers using said helpers. The main purpose of this is just to prevent
every d
Get rid of the extraneous switch case in here, and just open code
edp_backlight_mode as we only ever use it once.
v4:
* Check that backlight mode is DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD, not
DP_EDP_BACKLIGHT_CONTROL_MODE_MASK - imirkin
Signed-off-by: Lyude Paul
---
.../gpu/drm/i915/display/inte
This is kind of an annoying aspect of DRM's DP helpers:
drm_dp_dpcd_readb/writeb() return the size of bytes read/written on
success, thus we want to check against that instead of checking if the
return value is less than 0.
I'll probably be fixing this in the near future once I start doing DP work
Noticed this while moving all of the VESA backlight code in i915 over to
DRM helpers: it would appear that we calculate the frequency value we want
to write to DP_EDP_BACKLIGHT_FREQ_SET twice even though this value never
actually changes during runtime. So, let's simplify things by just caching
thi
This series:
* Cleans up i915's DPCD backlight code a little bit
* Extracts i915's DPCD backlight code into a set of shared DRM helpers
* Starts using those helpers in nouveau to add support to nouveau for
DPCD backlight control
v2 series-wide changes:
* Rebase
v3 series-wide changes:
* Split up
On Fri, May 7, 2021 at 4:59 PM Tejun Heo wrote:
>
> 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, i
On Fri, 07 May 2021 10:00:15 +0200, Mike Looijmans wrote:
> 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,
On Fri, 2021-05-07 at 17:00 -0500, Bjorn Andersson wrote:
> On Fri 07 May 16:18 CDT 2021, Lyude Paul wrote:
>
> > 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 read
On Fri 07 May 16:18 CDT 2021, Lyude Paul wrote:
> 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 bri
Ville pointed this out to me when fixing some issues in
drm_dp_read_downstream_info() - the DPCD version check here is bogus as
there's no DisplayPort versions prior to 1.0. The original code from i915
that this was extracted from actually did:
dpcd[DP_DPCD_REV] == DP_DPCD_REV_10
Which is corre
Hi,
On Tue, Mar 23, 2021 at 12:53 PM Laurent Pinchart
wrote:
>
> Hi Doug,
>
> On Tue, Mar 23, 2021 at 12:07:27PM -0700, Doug Anderson wrote:
> > On Mon, Mar 22, 2021 at 8:17 PM Stephen Boyd wrote:
> > >
> > > Quoting Laurent Pinchart (2021-03-17 17:20:43)
> > > > Hi Stephen,
> > > >
> > > > Revi
On Mon, 2021-05-03 at 06:06 +0300, Ville Syrjälä wrote:
> On Fri, Apr 30, 2021 at 06:34:28PM -0400, Lyude Paul wrote:
> > Noticed this while fixing another issue in drm_dp_read_downstream_info(),
> > the open coded DP_DOWNSTREAMPORT_PRESENT check here just duplicates what
> > we
> > already do in d
We don't need to stash away 'isr' in the aux structure to pass to two
functions. Let's use a local variable instead. And we can complete the
completion variable in one place instead of two to simplify the code.
Cc: Dmitry Baryshkov
Cc: Abhinav Kumar
Cc: Kuogee Hsieh
Cc: aravi...@codeaurora.org
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
Let's look at the irq status bits after a transfer and see if we got a
nack or a defer or a timeout, instead of telling drm layers that
everything was fine, while still printing an error message. I wasn't
sure about NACK+DEFER so I lumped all those various errors along with a
nack so that the drm c
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
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.
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
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
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
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
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
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
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
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
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
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 +++
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
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/
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
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
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
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 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 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 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 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 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 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 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 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 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 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 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 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, 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 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: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 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 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 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
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
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_
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
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
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
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 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
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
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
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
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
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_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 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
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
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);
^~
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
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
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/
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 ++--
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
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
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
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
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
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
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
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
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
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
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
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 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 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 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
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
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
1 - 100 of 126 matches
Mail list logo
