Hello,
Our static analysis tool finds a possible uninitialized-variable access
in the sis driver in Linux 5.14.0-rc3:
At the beginning of the function SiS_SetCRT2FIFO_300(), the variable
modeidindex is not initialized.
If the following conditions are false, it remains uninitialized.
5346:
On 7/27/21 6:39 PM, Martin K. Petersen wrote:
>
> Kees,
>
>> In preparation for FORTIFY_SOURCE performing compile-time and run-time
>> field bounds checking for memset(), avoid intentionally writing across
>> neighboring fields.
>>
>> Instead of writing beyond the end of evt_struct->iu.srp.cmd, t
On 7/28/21 8:35 PM, Martin K. Petersen wrote:
>
> Kees,
>
>> For example, change it to:
>>
>> +BUILD_BUG_ON(sizeof(evt_struct->iu.srp) != SRP_MAX_IU_LEN);
>> +memset(&evt_struct->iu.srp, 0x00, sizeof(evt_struct->iu.srp));
>> srp_cmd = &evt_struct->iu.srp.cmd;
>> -memset(srp_cmd,
Removed space before comma, fixed if statements by putting trailing
statements on new line, fixed unsigned int declaration, and removed
not needed else statement after return.
Signed-off-by: Gregory Williams
---
drivers/gpu/drm/ast/ast_mode.c | 31 ---
1 file change
On Sat, Jul 31, 2021, 04:59 Kees Cook wrote:
> On Fri, Jul 30, 2021 at 10:19:20PM +, Williams, Dan J wrote:
> > On Wed, 2021-07-28 at 14:59 -0700, Kees Cook wrote:
>
> > /**
> > * struct_group(NAME, MEMBERS)
> > *
> > @@ -67,7 +73,10 @@ enum {
> > * @NAME: The name of the mirrored sub-
On Thu, Jul 29, 2021 at 02:11:27PM +0200, Daniel Vetter wrote:
> On Wed, Jul 28, 2021 at 07:56:40AM +0200, Greg Kroah-Hartman wrote:
> > On Tue, Jul 27, 2021 at 01:58:16PM -0700, Kees Cook wrote:
> > > In preparation for FORTIFY_SOURCE performing compile-time and run-time
> > > field bounds checkin
On Fri, Jul 30, 2021 at 10:19:20PM +, Williams, Dan J wrote:
> On Wed, 2021-07-28 at 14:59 -0700, Kees Cook wrote:
> > On Wed, Jul 28, 2021 at 12:54:18PM +0200, Rasmus Villemoes wrote:
> > > On 27/07/2021 22.57, Kees Cook wrote:
> > >
> > > > In order to have a regular programmatic way to desc
To extend test coverage, relax the dependency on ARCH_STI or
ARCH_MULTIPLATFORM to also enable compilation with COMPILE_TEST.
Signed-off-by: Laurent Pinchart
---
Changes since v1:
- Enable COMPILE_TEST on all architectures
---
drivers/gpu/drm/sti/Kconfig | 3 ++-
1 file changed, 2 insertions(+)
To extend test coverage, support COMPILE_TEST on ARM64 in addition to
ARM.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/tilcdc/Kconfig | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/tilcdc/Kconfig b/drivers/gpu/drm/tilcdc/Kconfig
index 9f505a149990..
To extend test coverage, support COMPILE_TEST on all architectures.
Signed-off-by: Laurent Pinchart
---
Changes since v1:
- Enable COMPILE_TEST on all architectures
---
drivers/gpu/drm/tegra/Kconfig | 2 +-
drivers/gpu/host1x/Kconfig| 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
To extend test coverage, support COMPILE_TEST on all architectures by
dropping the ARM || ARM64 dependency. The dependency is a no-op when
COMPILE_TEST is not selected as ARCH_RENESAS can only be defined for ARM
or ARM64.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/Kconfig | 1 -
To extend test coverage, relax the dependency on ARCH_OMAP2PLUS or
ARCH_MULTIPLATFORM to also enable compilation with COMPILE_TEST.
Signed-off-by: Laurent Pinchart
---
Changes since v1:
- Enable COMPILE_TEST on all architectures
---
drivers/gpu/drm/omapdrm/Kconfig | 2 +-
1 file changed, 1 inse
On 64-bit platforms, the compiler complains that casting a void pointer
to an unsigned int loses data. Cast the pointer to a uintptr_t unsigned
to fix this.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/omap_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/
The correct format specifier for size_t is %zu. Using %d (or %u)
generates a warning on 64-bit platforms. Fix it.
Signed-off-by: Laurent Pinchart
Reviewed-by: Philippe Cornu
---
drivers/gpu/drm/sti/sti_hqvdp.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/d
The correct format specifier for size_t is %zu. Using %d (or %u)
generates a warning on 64-bit platforms. Fix it.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/dss/dsi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/dss/dsi.c
b/dri
To extend test coverage, relax the dependency on ARCH_MXC and ARM64 to
also enable compilation when COMPILE_TEST is selected.
Signed-off-by: Laurent Pinchart
---
Changes since v1:
- Enable COMPILE_TEST on all architectures
---
drivers/gpu/drm/imx/dcss/Kconfig | 3 ++-
1 file changed, 2 insertio
Hello,
This patch series stems from subsystem-wide changes I wanted to
compile-test with an ARM64 cross-compiler. My laziness to fire a 32-bit
ARM build definitely resulted in more time being spent writing these
patches, but hopefully they'll turn out to be useful for more people.
Patches 1/9 to
strncpy() is widely regarded as unsafe due to the fact that it may leave
the destination string without a nul-termination when the source string
size is too large. When compiling the kernel with W=1, the gcc warns
about this:
drivers/gpu/drm/drm_property.c: In function ‘drm_property_create’:
drive
Hi Laurent,
I love your patch! Perhaps something to improve:
[auto build test WARNING on tegra-drm/drm/tegra/for-next]
[also build test WARNING on tegra/for-next drm-intel/for-linux-next
drm-tip/drm-tip drm-exynos/exynos-drm-next linus/master v5.14-rc3 next-20210730]
[If your patch is applied
Hi Bjorn
On 2021-07-24 21:24, Bjorn Andersson wrote:
The current implementation supports a single DP instance and the DPU
code will
only match it against INTF_DP instance 0. These patches extends this to
allow
multiple DP instances and support for matching against DP instances
beyond 0.
This
I guess I forgot to Cc dri-devel. Doing it now.
Lucas De Marchi
On Fri, Jul 30, 2021 at 12:18:59PM -0700, Matt Roper wrote:
On Fri, Jul 30, 2021 at 12:11:15PM -0700, Lucas De Marchi wrote:
There's a missing sentinel since we are not using ARRAY_SIZE(), but rather
checking that the .start is 0
Hi Tomi,
On Thu, Jul 29, 2021 at 09:13:17AM +0300, Tomi Valkeinen wrote:
> On 28/07/2021 18:37, Laurent Pinchart wrote:
> > On 64-bit platforms, the compiler complains that casting a void pointer
> > to an unsigned int loses data. Cast the pointer to a uintptr_t unsigned
> > to fix this.
> >
> >
On 2021-07-24 21:24, Bjorn Andersson wrote:
As the Qualcomm DisplayPort driver only supports a single instance of
the driver the commonly used struct dp_display is kept in a global
variable. As we introduce additional instances this obviously doesn't
work.
Replace this with a combination of exis
Hi, Jason:
jason-jh.lin 於 2021年7月30日 週五 上午1:07寫道：
>
> Add DSC into mtk_drm_ddp_comp to support for mt8195.
>
> DSC is designed for real-time systems with real-time compression,
> transmission, decompression and display.
> The DSC standard is a specification of the algorithms used for
> compressin
On Wed, 2021-07-28 at 14:59 -0700, Kees Cook wrote:
> On Wed, Jul 28, 2021 at 12:54:18PM +0200, Rasmus Villemoes wrote:
> > On 27/07/2021 22.57, Kees Cook wrote:
> >
> > > In order to have a regular programmatic way to describe a struct
> > > region that can be used for references and sizing, can
On 7/30/21 1:31 AM, Thomas Zimmermann wrote:
> Hi Dan and Sam
>
> Am 29.07.21 um 21:55 schrieb dan.sned...@microchip.com:
>> Hi Thomas and Sam,
>> On 7/29/21 12:48 PM, Sam Ravnborg wrote:
>>> EXTERNAL EMAIL: Do not click links or open attachments unless you
>>> know the content is safe
>>>
>>> Hi
In the case where we can read an EDID for a panel the only part of the
panel description that can't be found directly from the EDID is the
description of the delays. Let's break the delay structure out so that
we can specify just the delays for panels that are detected by EDID.
This is simple code
As discussed in the patch ("dt-bindings: drm/panel-simple: Introduce
generic eDP panels") we can actually support probing eDP panels at
runtime instead of hardcoding what panel is connected. Add support to
the panel-simple driver for this.
We'll implement a solution like this:
* We'll read in two
A future change wants to be able to read just block 0 of the EDID, so
break it out of drm_do_get_edid() into a sub-function.
This is intended to be a no-op change--just code movement.
Signed-off-by: Douglas Anderson
---
(no changes since v1)
drivers/gpu/drm/drm_edid.c | 62 +++
EDIDs have 32-bits worth of data which is intended to be used to
uniquely identify the make/model of a panel. This has historically
been used only internally in the EDID processing code to identify
quirks with panels.
We'd like to use this panel ID in panel-simple to identify which panel
is hooked
The simple-panel driver is for panels that are not hot-pluggable at
runtime. Let's keep our cached EDID around until driver unload.
Signed-off-by: Douglas Anderson
---
(no changes since v1)
drivers/gpu/drm/panel/panel-simple.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff -
eDP panels generally contain almost everything needed to control them
in their EDID. This comes from their DP heritage were a computer needs
to be able to properly control pretty much any DP display that's
plugged into it.
The one big issue with eDP panels and the reason that we need a panel
drive
The goal of this patch series is to move away from hardcoding exact
eDP panels in device tree files. As discussed in the various patches
in this series (I'm not repeating everything here), most eDP panels
are 99% probable and we can get that last 1% by allowing two "power
up" delays to be specified
On Thu, Jul 29, 2021 at 9:52 PM John Stultz wrote:
>
> On Thu, Jul 29, 2021 at 12:24 AM Daniel Vetter wrote:
> >
> > On Thu, Jul 29, 2021 at 09:03:30AM +0200, Christian König wrote:
> > > As we now knew controlling dma_fence synchronization from userspace is
> > > extremely dangerous and can not
From: Bhawanpreet Lakha
Due to the way displays and human vision work it is most effective to
encode luminance information in a non-linear space.
For SDR this non-linear mapping is assumed to roughly use a gamma 2.2 curve.
This was due to the way CRTs worked and was fine for SDR content with a
l
From: Bhawanpreet Lakha
SDR is typically mastered at 200 nits and HDR is mastered at up to 10,000
nits. Due to this luminance range difference if we blend a SDR and
HDR plane together, we can run into problems where the HDR plane is too
bright or the SDR plane is too dim
A common solution to thi
Show the CSC matrixes in a 4x3 format.
Signed-off-by: Harry Wentland
---
drivers/gpu/drm/amd/display/dc/inc/hw/dpp.h | 28 +
1 file changed, 18 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/inc/hw/dpp.h
b/drivers/gpu/drm/amd/display/dc/inc/hw/dp
From: Bhawanpreet Lakha
Add color space definitions for BT601, BT709, BT2020, and DCI-P3.
Default to BT709, the sRGB color space.
Signed-off-by: Bhawanpreet Lakha
Signed-off-by: Harry Wentland
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 +
.../gpu/drm/arm/display/komeda/komeda_pla
We currently have 1D LUTs to define output transfer function but using a
1D LUT is not always the best way to define a transfer function for HW
that has ROMs for certain transfer functions, or for HW that has complex
PWL definition for accurate LUT definitions.
For this reason we're introducing na
Use the new DRM RFC doc section to capture the RFC previously only
described in the cover letter at
https://patchwork.freedesktop.org/series/89506/
v3:
* Add sections on single-plane and multi-plane HDR
* Describe approach to define HW details vs approach to define SW intentions
* Link Jeremy C
We are looking to enable HDR support for a couple of single-plane and
multi-plane scenarios. To do this effectively we recommend new interfaces
to drm_plane. The first patch gives a bit of background on HDR and why we
propose these interfaces.
This update is only changing the documentation, not th
This feature hands over the control of HW RC6 to the GuC.
GuC decides when to put HW into RC6 based on it's internal
busyness algorithms.
GuCRC needs GuC submission to be enabled, and only
supported on Gen12+ for now.
When GuCRC is enabled, do not set HW RC6. Use a H2G message
to tell GuC to enab
Tests that exercise the SLPC get/set frequency interfaces.
Clamp_max will set max frequency to multiple levels and check
that SLPC requests frequency lower than or equal to it.
Clamp_min will set min frequency to different levels and check
if SLPC requests are higher or equal to those levels.
v2
Update the get/set min/max freq hooks to work for
SLPC case as well. Consolidate helpers for requested/min/max
frequency get/set to intel_rps where the proper action can
be taken depending on whether SLPC is enabled.
v2: Add wrappers for getting rp0/1/n frequencies, update
softlimits in set min/ma
Cache rp0, rp1 and rpn platform limits into SLPC structure
for range checking while setting min/max frequencies.
Also add "soft" limits which keep track of frequency changes
made from userland. These are initially set to platform min
and max.
v2: Address review comments (Michal W)
v3: Formatting
Add helpers to read the min/max frequency being used
by SLPC. This is done by send a H2G command which forces
SLPC to update the shared data struct which can then be
read. These helpers will be used in a sysfs patch later
on.
v2: Address review comments (Michal W)
v3: Return err in case of query f
This interrupt is enabled during RPS initialization, and
now needs to be done by SLPC code. It allows ARAT timer
expiry interrupts to get forwarded to GuC.
v2: Fix comment (Matthew Brost)
v3: checkpatch()
Reviewed-by: Matthew Brost
Signed-off-by: Vinay Belgaumkar
---
drivers/gpu/drm/i915/gt/uc
Add param set h2g helpers to set the min and max frequencies
for use by SLPC.
v2: Address review comments (Michal W)
v3: Check for positive error code (Michal W)
v4: Print generic error in set_param (Michal W)
Reviewed-by: Michal Wajdeczko
Signed-off-by: Sundaresan Sujaritha
Signed-off-by: Vina
This prints out relevant SLPC info from the SLPC shared structure.
We will send a H2G message which forces SLPC to update the
shared data structure with latest information before reading it.
v2: Address review comments (Michal W)
v3: Remove unnecessary tasks from slpc_info (Michal W)
v4: Rename f
Allocate data structures for SLPC and functions for
initializing on host side.
v2: Address review comments (Michal W)
v3: Remove unnecessary header includes (Michal W)
v4: Rebase
v5: Move allocation of shared data into slpc_init() (Michal W)
Reviewed-by: Michal Wajdeczko
Signed-off-by: Vinay Bel
The assumption when it was added was that GT would not be
holding any gt_pm references. However, uc_init is called
from gt_init_hw, which holds a forcewake ref. If SLPC
enable fails, we will still be holding this ref, which will
result in the BUG_ON.
Reviewed-by: Matthew Brost
Signed-off-by: Vina
Add methods for interacting with GuC for enabling SLPC. Enable
SLPC after GuC submission has been established. GuC load will
fail if SLPC cannot be successfully initialized. Add various
helper methods to set/unset the parameters for SLPC. They can
be set using H2G calls or directly setting bits in
Add constants and params that are needed to configure SLPC.
v2: Add a new abi header for SLPC. Replace bitfields with
genmasks. Address other comments from Michal W.
v3: Add slpc H2G format in abi, other review commments (Michal W)
v4: Update status bits according to latest spec
v5: checkpatch(
Also ensure uc_init is called before we initialize RPS so that we
can check for SLPC support. We do not need to enable up/down
interrupts when SLPC is enabled. However, we still need the ARAT
interrupt, which will be enabled separately later.
v2: Explicitly return from intel_rps_enable with slpc c
Add macros to check for SLPC support. This feature is currently supported
for Gen12+ and enabled whenever GuC submission is enabled/selected.
Include templates for SLPC init/fini and enable.
v2: Move SLPC helper functions to intel_guc_slpc.c/.h. Define
basic template for SLPC structure in intel_g
This series enables Single Loop Power Control (SLPC) feature in GuC.
GuC implements various power management algorithms as part of it's
operation. These need to be specifically enabled by KMD. They replace
the legacy host based management of these features.
With this series, we will enable two PM
On Thu, Jul 29, 2021 at 07:01:06PM -0700, Vinay Belgaumkar wrote:
> Tests that exercise the SLPC get/set frequency interfaces.
>
> Clamp_max will set max frequency to multiple levels and check
> that SLPC requests frequency lower than or equal to it.
>
> Clamp_min will set min frequency to differ
A small race exists between intel_gt_retire_requests_timeout and
intel_timeline_exit which could result in the syncmap not getting
free'd. Rather than work to hard to seal this race, simply cleanup the
syncmap on fini.
unreferenced object 0x88813bc53b18 (size 96):
comm "gem_close_race", pid
Hi Sam,
On Thu, Jul 29, 2021 at 06:53:33PM +0200, Sam Ravnborg wrote:
> On Wed, Jul 28, 2021 at 06:37:29PM +0300, Laurent Pinchart wrote:
> > Hello,
> >
> > This patch series stems from subsystem-wide changes I wanted to
> > compile-test with an ARM64 cross-compiler. My laziness to fire a 32-bit
On Fri, Jul 30, 2021 at 10:08:03AM -0700, Nick Desaulniers wrote:
> On Fri, Jul 30, 2021 at 9:44 AM Kees Cook wrote:
> >
> > On Fri, Jul 30, 2021 at 12:00:54PM +0300, Dan Carpenter wrote:
> > > On Fri, Jul 30, 2021 at 10:38:45AM +0200, David Sterba wrote:
> > > > Then is explicit memset the only r
Am 2021-07-28 um 7:45 p.m. schrieb Sierra Guiza, Alejandro (Alex):
>
> On 7/22/2021 12:26 PM, Jason Gunthorpe wrote:
>> On Thu, Jul 22, 2021 at 11:59:17AM -0500, Sierra Guiza, Alejandro
>> (Alex) wrote:
>>> On 7/22/2021 7:23 AM, Jason Gunthorpe wrote:
On Sat, Jul 17, 2021 at 02:21:32PM -0500,
Am 2021-07-23 um 6:46 p.m. schrieb Sierra Guiza, Alejandro (Alex):
>
> On 7/17/2021 2:54 PM, Sierra Guiza, Alejandro (Alex) wrote:
>>
>> On 7/16/2021 5:14 PM, Felix Kuehling wrote:
>>> Am 2021-07-16 um 11:07 a.m. schrieb Theodore Y. Ts'o:
On Wed, Jun 23, 2021 at 05:49:55PM -0400, Felix Kuehlin
Quoting Kuogee Hsieh (2021-07-28 14:30:54)
> Currently at dp_pm_resume() is_connected state is decided base on hpd
> connection
> status only. This will put is_connected in wrongly "true" state at the
> scenario
> that dongle attached to DUT but without hmdi cable connecting to it. Fix this
> pro
Abstract the framebuffer details by mapping its BOs with a call
to drm_gem_fb_vmap(). Unmap with drm_gem_fb_vunmap().
The call to drm_gem_fb_vmap() ensures that all BOs are mapped
correctly. Gud still only supports single-plane formats.
No functional changes.
Signed-off-by: Thomas Zimmermann
Ac
Move framebuffer vmap code from shadow-buffered plane state into the new
interfaces drm_gem_fb_vmap() and drm_gem_fb_vunmap(). These functions
provide mappings of a framebuffer's BOs into kernel address space. No
functional changes.
v2:
* using [static N] for array parameters enables compi
Abstract the framebuffer details by mappings its BOs with a call
to drm_gem_fb_vmap(). Unmap with drm_gem_fb_vunamp().
Before, the output address with stored as raw pointer in the priv
field of struct drm_writeback_job. Introduce the new type
struct vkms_writeback_job, which holds the output mappi
Set the returned mapping address to NULL if a framebuffer plane does
not have a BO associated with it. Likewise, ignore mappings of NULL
during framebuffer unmap operations. Allows users of the functions to
perform unmap operations of certain BOs by themselfes.
Signed-off-by: Thomas Zimmermann
Re
DRM uses a magic number of 4 for the maximum number of planes per color
format. Declare this constant via DRM_FORMAT_MAX_PLANES and update the
related code. Some code depends on the length of arrays that are now
declared with DRM_FORMAT_MAX_PLANES. Convert it from '4' to ARRAY_SIZE.
v2:
*
Add the new helpers drm_gem_fb_vmap() and drm_gem_fb_vunmap(), which
provide vmap/vunmap for all BOs of a framebuffer. Convert shadow-
plane helpers, gud and vkms.
Callers of GEM vmap and vunmap functions used to do the minimum work
or get some detail wrong. Therefore shadow-plane helpers were int
On Fri, Jul 30, 2021 at 10:49:01AM +0100, Tvrtko Ursulin wrote:
>
> On 30/07/2021 01:13, John Harrison wrote:
> > On 7/28/2021 17:34, Matthew Brost wrote:
> > > If an engine associated with a context does not have a heartbeat, ban it
> > > immediately. This is needed for GuC submission as a idle p
On 7/30/2021 02:49, Tvrtko Ursulin wrote:
On 30/07/2021 01:13, John Harrison wrote:
On 7/28/2021 17:34, Matthew Brost wrote:
If an engine associated with a context does not have a heartbeat,
ban it
immediately. This is needed for GuC submission as a idle pulse doesn't
kick the context off the
On 7/30/21 12:15 AM, Desmond Cheong Zhi Xi wrote:
Hi,
Following a discussion on the patch ("drm: use the lookup lock in
drm_is_current_master") [1], Peter Zijlstra proposed new lockdep_assert
helpers to make it convenient to compose lockdep checks together.
This series includes the patch that i
On Fri, Jul 30, 2021 at 9:44 AM Kees Cook wrote:
>
> On Fri, Jul 30, 2021 at 12:00:54PM +0300, Dan Carpenter wrote:
> > On Fri, Jul 30, 2021 at 10:38:45AM +0200, David Sterba wrote:
> > > Then is explicit memset the only reliable way accross all compiler
> > > flavors and supported versions?
> > >
On Fri, Jul 30, 2021 at 12:00:54PM +0300, Dan Carpenter wrote:
> On Fri, Jul 30, 2021 at 10:38:45AM +0200, David Sterba wrote:
> > Then is explicit memset the only reliable way accross all compiler
> > flavors and supported versions?
> >
>
> The = { } initializer works. It's only when you start
Hi, Chunfeng:
Chunfeng Yun 於 2021年7月28日 週三 下午3:59寫道：
>
> Use devm_platform_ioremap_resource to simplify code
Acked-by: Chun-Kuang Hu
>
> Signed-off-by: Chunfeng Yun
> ---
> drivers/phy/mediatek/phy-mtk-mipi-dsi.c | 7 ++-
> 1 file changed, 2 insertions(+), 5 deletions(-)
>
> diff --git a
Hi, Chunfeng:
Chunfeng Yun 於 2021年7月28日 週三 下午3:59寫道：
>
> Return the error number directly without assignment
Acked-by: Chun-Kuang Hu
>
> Signed-off-by: Chunfeng Yun
> ---
> drivers/phy/mediatek/phy-mtk-mipi-dsi.c | 6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/
Hi, Chunfeng:
Chunfeng Yun 於 2021年7月28日 週三 下午3:59寫道：
>
> Use devm_platform_ioremap_resource to simplify code
Acked-by: Chun-Kuang Hu
>
> Signed-off-by: Chunfeng Yun
> ---
> drivers/phy/mediatek/phy-mtk-hdmi.c | 7 ++-
> 1 file changed, 2 insertions(+), 5 deletions(-)
>
> diff --git a/dri
This reverts commit 18a1488bf1e13fc3fc96d7948466b2166067c6c8.
Those delays were added to support the Samsung ATNA33XC20
panel. However, we've moving that to its own panel driver and out of
panel-simple. That means we don't need the ability to specify this
delay.
NOTE: it's unlikely we want to kee
This reverts commit 4bfe6c8f7c23b01719671b69fd29b87a35ccd9d6.
This panel's power sequencing really can't be handled properly by
panel-simple because of the special sequencing needed for the EL_ON3
GPIO. The only way it was sorta working in the past was by trying to
jam that signal into the "enable
The Samsung ATNA33XC20 panel is an AMOLED eDP panel that has backlight
control over the DP AUX channel.
This panel is _almost_ able to be controlled in a "simple" way (and it
originally was implemented in panel-simple.c), but it's really
impossible to get the backlight semantics right there withou
The manual has always said that we need 100 us delays in a few
places. Though it hasn't seemed to be a big deal to skip these, let's
add them in case it makes something happier.
NOTE: this fixes no known issues but it seems good to make it right.
Fixes: a095f15c00e2 ("drm/bridge: add support for
The function drm_edp_backlight_init() is defined such that the
"driver_pwm_freq_hz" parameter is optional--it's 0 if you don't want
to futz with it. If you follow this variable through, you'll find out
that if it's 0 we won't ever set the "bl->pwmgen_bit_count", leaving
it as 0.
That means that be
When testing with a panel that's apparently a little more persnickety
about the correct power sequence (specifically Samsung ATNA33XC20), we
found that the ti-sn65dsi86 was doing things just slightly wrong.
Looking closely at the ti-sn65dsi86's datasheet, the power off
sequence is supposed to be:
The overall goal of this series is to make the Samsung ATNA33XC20
panel work more properly. As part of this, we have:
* A bugfix for the recently abstracted DP AUX backlight code.
* A bugfix for the sequencing of the ti-sn65dsi86 bridge driver.
* Removal of the panel from panel-simple and moving
09.07.2021 22:31, Thierry Reding пишет:
> From: Thierry Reding
>
> Hi all,
>
> Mikko has been away for a few weeks, so I've been testing and revising
> the new UABI patches in the meantime. There are very minor changes to
> the naming of some of the UABI fields, but other than that it's mostly
>
Applied. Thanks!
Alex
On Thu, Jul 29, 2021 at 11:03 PM Randy Dunlap wrote:
>
> 'pm_suspend_target_state' is only available when CONFIG_PM_SLEEP
> is set/enabled. OTOH, when both SUSPEND and HIBERNATION are not set,
> PM_SLEEP is not set, so this variable cannot be used.
>
> ../drivers/gpu/drm/a
e-property/20210730-175415
base: git://anongit.freedesktop.org/drm/drm-tip drm-tip
config: i386-randconfig-s001-20210730 (attached as .config)
compiler: gcc-10 (Ubuntu 10.3.0-1ubuntu1~20.04) 10.3.0
reproduce:
# apt-get install sparse
# sparse version: v0.6.3-341-g8af2
drivers/gpu/drm/selftests/test-drm_damage_helper.c:15:19: warning: symbol
'mock_device' was not declared. Should it be static?
drivers/gpu/drm/selftests/test-drm_damage_helper.c:16:30: warning: symbol
'mock_obj_props' was not declared. Should it be static?
drivers/gpu/drm/selftests/test-drm_damag
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Adam Jackson (2):
kms: Handle changes to SourceValidate call chain in xserver 19
Fix link failure with gcc 10
Alex Deucher (1):
Bump version for the 21.0.0 release
Emil Velikov (10):
Use ODEV_ATTRIB_PATH where possible for the
Hi,
> - We fix virtio to send out the completion event at the end of this entire
> pipeline, i.e. virtio code needs to take care of sending out the
> crtc_state->event correctly.
That sounds sensible to me. Fence the virtio commands, make sure (on
the host side) the command completes only
fix typo for drm
v1->v2:
respin with the change "iff ==> implies that"
Reviewed-by: Daniel Vetter
Signed-off-by: Cai Huoqing
---
drivers/gpu/drm/drm_aperture.c | 2 +-
drivers/gpu/drm/drm_atomic.c| 2 +-
drivers/gpu/drm/drm_atomic_helper.c | 10 +-
drivers/gp
On 2021-07-30 12:25 p.m., Daniel Vetter wrote:
> On Thu, Jul 29, 2021 at 01:16:55AM -0700, Vivek Kasireddy wrote:
>> By separating the OUT_FENCE signalling from pageflip completion allows
>> a Guest compositor to start a new repaint cycle with a new buffer
>> instead of waiting for the old buffer t
On Fri, 2021-07-30 at 14:10 +0200, Geert Uytterhoeven wrote:
> Hi Laurent,
>
> On Wed, Jul 28, 2021 at 5:37 PM Laurent Pinchart
> wrote:
> > To extend test coverage, relax the dependency on ARCH_MXC to also enable
> > compilation when COMPILE_TEST is selected.
> >
> > Signed-off-by: Laurent Pinc
Add support for the 10.3" E Ink panel described at:
https://www.eink.com/product.html?type=productdetail&id=7
Signed-off-by: Alistair Francis
Acked-by: Rob Herring
Reviewed-by: Sam Ravnborg
---
v5:
- Add .connector_type
.../bindings/display/panel/panel-simple.yaml | 2 ++
.../devicetree/bi
Hi Laurent,
On Wed, Jul 28, 2021 at 5:37 PM Laurent Pinchart
wrote:
> To extend test coverage, relax the dependency on ARCH_MXC to also enable
> compilation when COMPILE_TEST is selected.
>
> Signed-off-by: Laurent Pinchart
Thanks for your patch!
> --- a/drivers/gpu/drm/imx/dcss/Kconfig
> +++
Full Series tested on BPI-R2/MT7623
Tested-By: Frank Wunderlich
regards Frank
Hi Jason,
Thank you for your patch.
On 29/7/21 19:07, jason-jh.lin wrote:
> The hardware path of vdosys0 with eDP panel output need to go through
> by several modules, such as, OVL, RDMA, COLOR, CCORR, AAL, GAMMA,
> DITHER, DSC and MERGE.
>
You said in other discussions that vdosys0 has eDP pa
Hi Jason,
Thank you for your patch.
On 29/7/21 19:07, jason-jh.lin wrote:
> Add mt8195 vdosys0 clock driver name and routing table to
> the driver data of mtk-mmsys.
>
This patch is the one that is really introducing mt8195 mmsys support. It is a
bit confusing sent the binding on another patchs
On Thu, Jul 29, 2021 at 07:57:47PM -0700, Bart Van Assche wrote:
> On 7/29/21 7:31 PM, Kees Cook wrote:
> > On Wed, Jul 28, 2021 at 02:45:55PM -0700, Bart Van Assche wrote:
> >> On 7/27/21 1:58 PM, Kees Cook wrote:
> >>> In preparation for FORTIFY_SOURCE performing compile-time and run-time
> >>> f
This symbol is not used outside of vc4_hdmi.c, so marks it static.
Fix the following sparse warning:
drivers/gpu/drm/vc4/vc4_hdmi.c:1479:25: warning: symbol
'vc4_hdmi_codec_pdata' was not declared. Should it be static?
Reported-by: Abaci Robot
Signed-off-by: Jiapeng Chong
---
drivers/gpu/drm/
1 - 100 of 113 matches
Mail list logo
