On Thu, Dec 10, 2020 at 8:42 PM Thomas Gleixner wrote:
> Let the core code do the fiddling with irq_desc.
>
> Signed-off-by: Thomas Gleixner
> Cc: Linus Walleij
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-g...@vger.kernel.org
Reviewed-by: Linus Walleij
I suppose you will funnel
Hi Daniel,
I love your patch! Yet something to improve:
[auto build test ERROR on next-20201211]
[also build test ERROR on v5.10-rc7]
[cannot apply to tegra-drm/drm/tegra/for-next linus/master v5.10-rc7 v5.10-rc6
v5.10-rc5]
[If your patch is applied to the wrong git tree, kindly drop us a note
On 2020-12-11 4:44 p.m., Luben Tuikov wrote:
> If however, you never decide to send it to the hardware and simply
> abandon it (in hopes that the DRM or the Application Client will
> reissue it), then you should send it back to DRM with status "COMPLETE".
Correction: "... decide to *not* send it
On 2020-12-10 4:46 a.m., Steven Price wrote:
> On 10/12/2020 02:14, Luben Tuikov wrote:
>> This patch does not change current behaviour.
>>
>> The driver's job timeout handler now returns
>> status indicating back to the DRM layer whether
>> the task (job) was successfully aborted or whether
>>
On Fri, 11 Dec 2020 09:46:21 +0800, Liu Ying wrote:
> Add support for Mixel MIPI DPHY + LVDS PHY combo IP
> as found on Freescale i.MX8qxp SoC.
>
> Cc: Guido Günther
> Cc: Kishon Vijay Abraham I
> Cc: Vinod Koul
> Cc: Rob Herring
> Cc: NXP Linux Team
> Signed-off-by: Liu Ying
> ---
>
On Fri, 11 Dec 2020 09:46:20 +0800, Liu Ying wrote:
> This patch converts the mixel,mipi-dsi-phy binding to
> DT schema format using json-schema.
>
> Comparing to the plain text version, the new binding adds
> the 'assigned-clocks', 'assigned-clock-parents' and
> 'assigned-clock-rates'
On 2020-12-10 4:41 a.m., Christian König wrote:
> Am 10.12.20 um 10:31 schrieb Lucas Stach:
>> Hi Luben,
>>
>> Am Mittwoch, den 09.12.2020, 21:14 -0500 schrieb Luben Tuikov:
>>> [SNIP]
>>> -static void etnaviv_sched_timedout_job(struct drm_sched_job *sched_job)
>>> +static enum drm_task_status
On 12/11/20 7:37 AM, Thomas Gleixner wrote:
> On Fri, Dec 11 2020 at 13:10, Jürgen Groß wrote:
>> On 11.12.20 00:20, boris.ostrov...@oracle.com wrote:
>>> On 12/10/20 2:26 PM, Thomas Gleixner wrote:
All event channel setups bind the interrupt on CPU0 or the target CPU for
percpu
On 2020-12-10 4:31 a.m., Lucas Stach wrote:
> Hi Luben,
>
> Am Mittwoch, den 09.12.2020, 21:14 -0500 schrieb Luben Tuikov:
>> This patch does not change current behaviour.
>>
>> The driver's job timeout handler now returns
>> status indicating back to the DRM layer whether
>> the task (job) was
On Thu, Dec 10, 2020 at 5:10 AM Daniel Vetter wrote:
> On Thu, Dec 10, 2020 at 1:06 PM Greg KH wrote:
> > On Thu, Dec 10, 2020 at 12:26:01PM +0100, Daniel Vetter wrote:
> > > On Thu, Dec 10, 2020 at 11:55 AM Greg KH
> > > wrote:
> > > > On Thu, Dec 10, 2020 at 11:27:27AM +0100, Daniel Vetter
Hi all
On Fri, Dec 11, 2020 at 8:03 PM Alex Deucher wrote:
>
> On Mon, Nov 30, 2020 at 3:25 AM Wendy Liang wrote:
> >
> > AI engine is the acceleration engine provided by Xilinx. These engines
> > provide high compute density for vector-based algorithms, and flexible
> > custom compute and data
On Mon, Nov 30, 2020 at 3:25 AM Wendy Liang wrote:
>
> AI engine is the acceleration engine provided by Xilinx. These engines
> provide high compute density for vector-based algorithms, and flexible
> custom compute and data movement. It has core tiles for compute and
> shim tiles to interface
If a CRTC is missing a legacy primary plane pointer, a lot of things
will be broken for user-space: fbdev stops working and the entire legacy
uAPI stops working.
Require all drivers to populate drm_crtc.primary to prevent these
issues. Warn if it's NULL.
Signed-off-by: Simon Ser
Reviewed-by:
If a primary or cursor plane is not compatible with a CRTC it's attached
to via the legacy primary/cursor field, things will be broken for legacy
user-space.
v4: use drm_crtc_mask instead of BIT (Ville)
Signed-off-by: Simon Ser
Reviewed-by: Daniel Vetter
Acked-by: Pekka Paalanen
Cc: Ville
The previous wording could be understood by user-space evelopers as "a
primary/cursor plane is only compatible with a single CRTC" [1].
Reword the planes description to make it clear the DRM-internal
drm_crtc.primary and drm_crtc.cursor planes are for legacy uAPI.
[1]:
User-space expects to be able to pick a primary plane for each CRTC
exposed by the driver. Make sure this assumption holds in
drm_mode_config_validate.
Use the legacy drm_crtc.primary field to check this, because it's
simpler and we require drivers to set it anyways. Accumulate a set of
primary
Hi KuoHsiang,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-exynos/exynos-drm-next]
[also build test WARNING on drm-intel/for-linux-next
tegra-drm/drm/tegra/for-next drm-tip/drm-tip linus/master v5.10-rc7
next-20201211]
[cannot apply to drm/drm-next
The pull request you sent on Fri, 11 Dec 2020 11:03:01 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2020-12-11
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/059fe8296e0fb4b89d997ea0aa75996911b8f3aa
Thank you!
--
Deet-doot-dot, I am a bot.
On Thu, Dec 10, 2020 at 9:57 PM Thomas Gleixner wrote:
>
> First of all drivers have absolutely no business to dig into the internals
> of an irq descriptor. That's core code and subject to change. All of this
> information is readily available to /proc/interrupts in a safe and race
> free way.
>
On Thu, 10 Dec 2020 19:25:45 +,
Thomas Gleixner wrote:
>
> The irq descriptor is already there, no need to look it up again.
>
> Signed-off-by: Thomas Gleixner
> Cc: Marc Zyngier
> Cc: Russell King
> Cc: linux-arm-ker...@lists.infradead.org
> ---
> arch/arm/kernel/smp.c |2 +-
> 1
On Thu, 10 Dec 2020 19:25:46 +,
Thomas Gleixner wrote:
>
> The irq descriptor is already there, no need to look it up again.
>
> Signed-off-by: Thomas Gleixner
> Cc: Mark Rutland
> Cc: Catalin Marinas
> Cc: Will Deacon
> Cc: Marc Zyngier
> Cc: linux-arm-ker...@lists.infradead.org
> ---
On Thu, Dec 10, 2020 at 10:14 PM Thomas Gleixner wrote:
>
> irq_set_lockdep_class() is used from modules and requires irq_to_desc() to
> be exported. Move it into the core code which lifts another requirement for
> the export.
...
> + if (IS_ENABLED(CONFIG_LOCKDEP))
> +
On Fri, Oct 23, 2020 at 04:56:20PM +0200, Daniel Vetter wrote:
> On Fri, Oct 23, 2020 at 4:54 PM Christian König
> wrote:
> >
> > Am 23.10.20 um 14:21 schrieb Daniel Vetter:
> > > ttm_resource_manager->use_type is only used for runtime changes by
> > > vmwgfx. I think ideally we'd push this
ttm_resource_manager->use_type is only used for runtime changes by
vmwgfx. I think ideally we'd push this functionality into drivers -
ttm itself does not provide any locking to guarantee this is safe, so
the only way this can work at runtime is if the driver does provide
additional guarantees.
Other way round is a bit inconsistent (but not buggy in any kind).
This is prep work so that ttm_resource_manager_set_used can assert
that the resource manager is empty.
Signed-off-by: Daniel Vetter
Cc: VMware Graphics
Cc: Roland Scheidegger
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 2 +-
1
This isn't actually protecting anything becuase:
- when running, ttm_resource_manager->use_type is protected through
vmw_private->reservation_semaphore against concurrent execbuf or
well anything else that might evict or reserve buffers
- during suspend/resume there's nothing else running,
On Thu 2020-12-10 16:08:05, Andy Shevchenko wrote:
> On Thu, Dec 10, 2020 at 03:55:27PM +0200, Sakari Ailus wrote:
> > On Thu, Dec 10, 2020 at 03:05:02PM +0200, Andy Shevchenko wrote:
> > > My concerns are:
> > > - not so standard format of representation (why not to use
> > > string_escape_mem()
On Fri, Dec 11, 2020 at 06:21:40PM +0200, Ville Syrjälä wrote:
> On Fri, Dec 11, 2020 at 05:11:12PM +0100, Daniel Vetter wrote:
> > There's a confusion between the preferred_depth uapi and the generic
> > fbdev helpers. Former wants depth, latter wants bpp, and for XRGB
> > they don't match.
On Fri, Dec 11, 2020 at 05:11:12PM +0100, Daniel Vetter wrote:
> There's a confusion between the preferred_depth uapi and the generic
> fbdev helpers. Former wants depth, latter wants bpp, and for XRGB
> they don't match. Which hit me with vkms, which wants that.
>
> All other drivers setting
On 11.12.20 00:20, boris.ostrov...@oracle.com wrote:
On 12/10/20 2:26 PM, Thomas Gleixner wrote:
All event channel setups bind the interrupt on CPU0 or the target CPU for
percpu interrupts and overwrite the affinity mask with the corresponding
cpumask. That does not make sense.
The XEN
There's a confusion between the preferred_depth uapi and the generic
fbdev helpers. Former wants depth, latter wants bpp, and for XRGB
they don't match. Which hit me with vkms, which wants that.
All other drivers setting this and using the generic fbdev helpers use
16, where both numbers
I tried to fix this for real, but it's very sprawling and lots of
drivers get this mildly wrong one way or the other.
Signed-off-by: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: David Airlie
Cc: Daniel Vetter
---
drivers/gpu/drm/drm_fb_helper.c | 5 +
Hi All,
On 11/12/2020 12:01, Sam Ravnborg wrote:
> Hi Dan,
>
> I assume your nice tooling found this buggy.
> Nice!
>
> On Fri, Dec 11, 2020 at 01:05:50PM +0300, Dan Carpenter wrote:
>> There is a copy and paste bug so it didn't return the correct error
>> code.
>>
>> Fixes: b215212117f7 ("drm:
At least amdgpu and i915 do, so lets just document this as the rule.
Signed-off-by: Daniel Vetter
Cc: Thomas Zimmermann
Cc: Sumit Semwal
Cc: "Christian König"
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
---
drivers/dma-buf/dma-buf.c | 4
1 file changed, 4
Motivated by a discussion with Christian and Thomas: Try to untangle a
bit what's relevant for importers and what's relevant for exporters.
Also add an assert that really only dynamic importers use the api
function, anything else doesn't make sense.
Signed-off-by: Daniel Vetter
Cc: Thomas
Noticed while reviewing the output. Adds a bunch more links and fixes
the function interface quoting.
Signed-off-by: Daniel Vetter
Cc: Thomas Zimmermann
Cc: Sumit Semwal
Cc: "Christian König"
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
---
drivers/dma-buf/dma-buf.c |
Also try to clarify a bit when dma_buf_begin/end_cpu_access should
be called.
Signed-off-by: Daniel Vetter
Cc: Thomas Zimmermann
Cc: Sumit Semwal
Cc: "Christian König"
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
---
drivers/dma-buf/dma-buf.c | 20 ++--
To support legacy gamma ioctls the drivers need to set
drm_crtc_funcs.gamma_set either to a custom implementation or to
drm_atomic_helper_legacy_gamma_set. Most of the atomic drivers do the
latter.
We can simplify this by making the core handle it automatically.
Move the
The DRM core handles legacy gamma-set ioctl by setting GAMMA_LUT and
clearing CTM and DEGAMMA_LUT.
This works fine on HW where we have either:
degamma -> ctm -> gamma -> out
or
ctm -> gamma -> out
However, if the HW has gamma table before ctm, the atomic property
should be DEGAMMA_LUT, and
Hi,
Yet another try. This time I don't touch the drm_fb_helper.c at all,
except adding a FIXME comment. Now everything is inside
drm_color_mgmt.c.
Tomi
Tomi Valkeinen (2):
drm: automatic legacy gamma support
drm: add legacy support for using degamma for gamma
On Thu, Dec 03, 2020 at 08:53:17PM -0700, Jim Cromie wrote:
> drm's debug system uses distinct categories of debug messages, mapped
> to bits in drm.debug. Currently, code does a lot of unlikely bit-mask
> checks on drm.debug (in drm_debug_enabled), we can use dynamic debug
> instead, and get all
On 10/12/2020 20:06, kernel test robot wrote:
> Hi Tomi,
>
> I love your patch! Perhaps something to improve:
>
> [auto build test WARNING on drm-intel/for-linux-next]
> [also build test WARNING on linus/master v5.10-rc7]
> [cannot apply to drm-tip/drm-tip anholt/for-next next-20201210]
> [If
On Wed, 09 Dec 2020, Lyude Paul wrote:
> 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
Hi, Yongqiang:
Yongqiang Niu 於 2020年12月10日 週四 下午5:08寫道：
>
> add mt8183 function call for setting the routing registers
I think you should move this patch to the series "soc: mediatek:
Prepare MMSYS for DDP routing using function call" [1]. Without this
patch, that series has no strong reason to
Hi, Yongqiang:
Yongqiang Niu 於 2020年12月11日 週五 上午8:43寫道：
>
> On Thu, 2020-12-10 at 23:40 +0800, Chun-Kuang Hu wrote:
> > Hi, Yongqiang:
> >
> > Yongqiang Niu 於 2020年12月10日 週四 下午5:22寫道：
> > >
> > > rdma fifo size may be different even in same SOC, add this
> > > property to the corresponding rdma
On Fri, Dec 11, 2020 at 01:08:26PM +, Simon Ser wrote:
> User-space expects to be able to pick a primary plane for each CRTC
> exposed by the driver. Make sure this assumption holds in
> drm_mode_config_validate.
>
> Use the legacy drm_crtc.primary field to check this, because it's
> simpler
On Wed, 09 Dec 2020, Lyude Paul wrote:
> 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
On Fri, Dec 11, 2020 at 01:24:49PM +0200, Tomi Valkeinen wrote:
> On 10/12/2020 20:06, kernel test robot wrote:
> > Hi Tomi,
> >
> > I love your patch! Perhaps something to improve:
> >
> > [auto build test WARNING on drm-intel/for-linux-next]
> > [also build test WARNING on linus/master
On Friday, December 11th, 2020 at 2:50 PM, Pekka Paalanen
wrote:
> is there a reason why one cannot have more primary planes than CRTCs in
> existence?
>
> Daniel implied that in <20201209003637.GK401619@phenom.ffwll.local>,
> but I didn't get the reason for it yet.
>
> E.g. if all your planes
On 11.12.20 11:13, Thomas Gleixner wrote:
On Fri, Dec 11 2020 at 07:17, Jürgen Groß wrote:
On 11.12.20 00:20, boris.ostrov...@oracle.com wrote:
On 12/10/20 2:26 PM, Thomas Gleixner wrote:
All event channel setups bind the interrupt on CPU0 or the target CPU for
percpu interrupts and
On Wed, Dec 09, 2020 at 03:25:22PM +0100, Thomas Zimmermann wrote:
> The existing dma-buf calls dma_buf_vmap() and dma_buf_vunmap() are
> allowed to pin the buffer or acquire the buffer's reservation object
> lock.
>
> This is a problem for callers that only require a short-term mapping
> of the
On Fri, Dec 11, 2020 at 12:01:57PM +0100, Sam Ravnborg wrote:
> Hi Dan,
>
> I assume your nice tooling found this buggy.
Yeah. Passing a valid pointer to PTR_ERR().
regards,
dan carpenter
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
Hi, Hsin-Yi:
Hsin-Yi Wang 於 2020年12月3日 週四 下午4:24寫道：
>
> Similar to a9d9fea74be2 ("drm/mediatek: mtk_dsi: Create connector for
> bridges"):
>
> Use the drm_bridge_connector helper to create a connector for pipelines
> that use drm_bridge. This allows splitting connector operations across
>
Am 11.12.20 um 14:58 schrieb Michel Dänzer:
On 2020-12-14 9:57 p.m., Christian König wrote:
Am 11.12.20 um 13:20 schrieb Pekka Paalanen:
On Fri, 11 Dec 2020 11:28:36 +0100
Christian König wrote:
I think the general idea we settled on is that we specify an earliest
display time for each
On Fri, Dec 11, 2020 at 11:16:25AM +0100, Thomas Zimmermann wrote:
> Hi
>
> Am 11.12.20 um 11:01 schrieb Daniel Vetter:
> > On Wed, Dec 09, 2020 at 03:25:27PM +0100, Thomas Zimmermann wrote:
> > > Fbdev emulation has to lock the BO into place while flushing the shadow
> > > buffer into the BO's
On 2020-12-14 9:57 p.m., Christian König wrote:
Am 11.12.20 um 13:20 schrieb Pekka Paalanen:
On Fri, 11 Dec 2020 11:28:36 +0100
Christian König wrote:
I think the general idea we settled on is that we specify an earliest
display time for each frame and give feedback to the application when a
Enable HDCP 2.2 MST support till Gen12.
Cc: Ramalingam C
Tested-by: Karthik B S
Signed-off-by: Anshuman Gupta
---
drivers/gpu/drm/i915/display/intel_hdcp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
Authenticate and enable port encryption only once for
an active HDCP 2.2 session, once port is authenticated
and encrypted enable encryption for each stream that
requires encryption on this port.
Similarly disable the stream encryption for each encrypted
stream, once all encrypted stream
Add support for HDCP 2.2 DP MST shim callback.
This adds existing DP HDCP shim callback for Link Authentication
and Encryption and HDCP 2.2 stream encryption
callback.
v2:
- Added a WARN_ON() instead of drm_err. [Uma]
- Cosmetic changes. [Uma]
v3:
- 's/port_data/hdcp_port_data' [Ram]
- skip
Add HDCP 2.2 DP MST HDCP2_STREAM_STATUS
and HDCP2_AUTH_STREAM register in i915_reg header.
B.Spec: 21780
B.Spec: 14410
B.Spec: 50573
v2
- Modified naming convention of HDCP2_STREAM_STATUS
for pre-gen12 platforms inline with B.Spec.
Cc: Ramalingam C
Reviewed-by: Uma Shankar
Reviewed-by:
This requires for HDCP 2.2 MST check link.
As for DP/HDMI shims check_2_2_link retrieves the connector
from dig_port, this is not sufficient or DP MST connector,
there can be multiple DP MST topology connector associated
with same dig_port.
Cc: Ramalingam C
Reviewed-by: Uma Shankar
Reviewed-by:
Let's define Maximum MST content streams up to four
generically which can be supported by modern display
controllers.
Cc: Sean Paul
Cc: Ramalingam C
Acked-by: Maarten Lankhorst
Reviewed-by: Uma Shankar
Reviewed-by: Ramalingam C
Tested-by: Karthik B S
Signed-off-by: Anshuman Gupta
---
Add support for multiple mst stream in hdcp port data
which will be used by RepeaterAuthStreamManage msg and
HDCP 2.2 security f/w for m' validation.
Security f/w doesn't have any provision to mark the stream_type
for each stream separately, it just take single input of
stream_type while
On Fri, Dec 11, 2020 at 11:49:48AM +0100, Thomas Zimmermann wrote:
>
>
> Am 11.12.20 um 11:18 schrieb Daniel Vetter:
> > On Wed, Dec 09, 2020 at 03:25:21PM +0100, Thomas Zimmermann wrote:
> > > The HW cursor's BO used to be mapped permanently into the kernel's
> > > address space. GEM's vmap
Fix the size of WIRED_REPEATER_AUTH_STREAM_REQ cmd buffer size.
It is based upon the actual number of MST streams and size
of wired_cmd_repeater_auth_stream_req_in.
Excluding the size of hdcp_cmd_header.
v2:
- hdcp_cmd_header size annotation nitpick. [Tomas]
Cc: Tomas Winkler
Cc: Ramalingam C
hdcp_port_data is specific to a port on which HDCP
encryption is getting enabled, so encapsulate it to
intel_digital_port.
This will be required to enable HDCP 2.2 stream encryption.
v2:
- 's/port_data/hdcp_port_data'. [Ram]
Cc: Ramalingam C
Reviewed-by: Uma Shankar
Reviewed-by: Ramalingam C
Pass dig_port as an argument to intel_hdcp_init()
and intel_hdcp2_init().
This will be required for HDCP 2.2 stream encryption.
Cc: Ramalingam C
Reviewed-by: Uma Shankar
Reviewed-by: Ramalingam C
Tested-by: Karthik B S
Signed-off-by: Anshuman Gupta
---
Enable HDCP 1.4 over DP MST for Gen12.
v2:
- Enable HDCP for <= Gen12 platforms. [Ram]
v3:
- Connector detials in debug msg. [Ram]
Cc: Ramalingam C
Reviewed-by: Ramalingam C
Tested-by: Karthik B S
Signed-off-by: Anshuman Gupta
---
drivers/gpu/drm/i915/display/intel_dp_mst.c | 7 +++
1
Enable HDCP 1.4 DP MST stream encryption.
Enable stream encryption once encryption is enabled on
the DP transport driving the link for each stream which
has requested encryption.
Disable stream encryption for each stream that no longer
requires encryption before disabling HDCP encryption on
the
Both HDCP_{1.x,2.x} requires to select/deselect Multistream HDCP bit
in TRANS_DDI_FUNC_CTL in order to enable/disable stream HDCP
encryption over DP MST Transport Link.
HDCP 1.4 stream encryption requires to validate the stream encryption
status in HDCP_STATUS_{TRANSCODER,PORT} register driving
DP MST stream encryption status requires time of a link frame
in order to change its status, but as there were some HDCP
encryption timeout observed earlier, it is safer to use
ENCRYPT_STATUS_CHANGE_TIMEOUT_MS timeout for stream status too,
it requires to move the macro to a header.
It will be
Gen12 has H/W delta with respect to HDCP{1.x,2.x} display engine
instances lies in Transcoder instead of DDI as in Gen11.
This requires hdcp driver to use mst_master_transcoder for link
authentication and stream transcoder for stream encryption
separately.
This will be used for both HDCP 1.4 and
There can be situation when DP MST connector is created without
mst modeset being done, in those cases connector->encoder will be
NULL. MST connector->encoder initializes after modeset.
Don't enable HDCP in such cases to prevent any crash.
Cc: Ramalingam C
Cc: Juston Li
Tested-by: Karthik B S
Handle CP_IRQ in DEVICE_SERVICE_IRQ_VECTOR_ESI0
It requires to call intel_hdcp_handle_cp_irq() in case
of CP_IRQ is triggered by a sink in DP-MST topology.
Cc: "Ville Syrjälä"
Cc: Ramalingam C
Reviewed-by: Uma Shankar
Reviewed-by: Ramalingam C
Tested-by: Karthik B S
Signed-off-by: Anshuman
Get DRM connector reference count while scheduling a prop work
to avoid any possible destroy of DRM connector when it is in
DRM_CONNECTOR_REGISTERED state.
Fixes: a6597faa2d59 ("drm/i915: Protect workers against disappearing
connectors")
Cc: Sean Paul
Cc: Ramalingam C
Reviewed-by: Uma Shankar
When crtc state need_modeset is true it is not necessary
it is going to be a real modeset, it can turns to be a
fastset instead of modeset.
This turns content protection property to be DESIRED and hdcp
update_pipe left with property to be in DESIRED state but
actual hdcp->value was ENABLED.
This
This v8 version has fixed the cosmetics eview comment
from ram. No functional change.
It has been tested manually with below IGT series on TGL and ICL.
https://patchwork.freedesktop.org/series/82987/
[PATCH v8 12/19] misc/mei/hdcp: Fix AUTH_STREAM_REQ cmd buffer len
has an Ack from Tomas to
On Fri, 11 Dec 2020 13:08:26 +
Simon Ser wrote:
> User-space expects to be able to pick a primary plane for each CRTC
> exposed by the driver. Make sure this assumption holds in
> drm_mode_config_validate.
>
> Use the legacy drm_crtc.primary field to check this, because it's
> simpler and
On Fri, 11 Dec 2020 13:06:17 +
Simon Ser wrote:
> If a CRTC is missing a legacy primary plane pointer, a lot of things
> will be broken for user-space: fbdev stops working and the entire legacy
> uAPI stops working.
>
> Require all drivers to populate drm_crtc.primary to prevent these
>
On Fri, 11 Dec 2020 13:06:14 +
Simon Ser wrote:
> If a primary or cursor plane is not compatible with a CRTC it's attached
> to via the legacy primary/cursor field, things will be broken for legacy
> user-space.
>
> Signed-off-by: Simon Ser
> Reviewed-by: Daniel Vetter
> Cc: Pekka
On Fri, 11 Dec 2020 13:06:10 +
Simon Ser wrote:
> The previous wording could be understood by user-space evelopers as "a
> primary/cursor plane is only compatible with a single CRTC" [1].
>
> Reword the planes description to make it clear the DRM-internal
> drm_crtc.primary and
On Mon, 14 Dec 2020 21:57:25 +0100
Christian König wrote:
> Am 11.12.20 um 13:20 schrieb Pekka Paalanen:
> > On Fri, 11 Dec 2020 11:28:36 +0100
> > Christian König wrote:
> >
> >> Am 11.12.20 um 10:55 schrieb Pekka Paalanen:
> >>> On Fri, 11 Dec 2020 09:56:07 +0530
> >>> Shashank Sharma
On Wed, 09 Dec 2020, Rodrigo Vivi wrote:
> On Wed, Dec 09, 2020 at 04:16:36PM -0500, Sean Paul wrote:
>> From: Sean Paul
>>
>> No need to spam syslog/console when we can ignore/fix the flag.
>
> besides that we are calling from multiple places anyway..
>
>>
>> Signed-off-by: Sean Paul
>
>
>
Hi,
On Mon 07 Dec 20, 11:42, Maxime Ripard wrote:
> On Wed, Dec 02, 2020 at 05:06:40PM +0100, Paul Kocialkowski wrote:
> > > > +static void logicvc_crtc_atomic_begin(struct drm_crtc *drm_crtc,
> > > > + struct drm_atomic_state *state)
> > > > +{
> > > > +
On Fri, Dec 11, 2020 at 2:08 PM Simon Ser wrote:
>
> User-space expects to be able to pick a primary plane for each CRTC
> exposed by the driver. Make sure this assumption holds in
> drm_mode_config_validate.
>
> Use the legacy drm_crtc.primary field to check this, because it's
> simpler and we
User-space expects to be able to pick a primary plane for each CRTC
exposed by the driver. Make sure this assumption holds in
drm_mode_config_validate.
Use the legacy drm_crtc.primary field to check this, because it's
simpler and we require drivers to set it anyways. Accumulate a set of
primary
If a primary or cursor plane is not compatible with a CRTC it's attached
to via the legacy primary/cursor field, things will be broken for legacy
user-space.
Signed-off-by: Simon Ser
Reviewed-by: Daniel Vetter
Cc: Pekka Paalanen
---
drivers/gpu/drm/drm_mode_config.c | 16
1
If a CRTC is missing a legacy primary plane pointer, a lot of things
will be broken for user-space: fbdev stops working and the entire legacy
uAPI stops working.
Require all drivers to populate drm_crtc.primary to prevent these
issues. Warn if it's NULL.
Signed-off-by: Simon Ser
Reviewed-by:
The previous wording could be understood by user-space evelopers as "a
primary/cursor plane is only compatible with a single CRTC" [1].
Reword the planes description to make it clear the DRM-internal
drm_crtc.primary and drm_crtc.cursor planes are for legacy uAPI.
[1]:
Am 11.12.20 um 13:20 schrieb Pekka Paalanen:
On Fri, 11 Dec 2020 11:28:36 +0100
Christian König wrote:
Am 11.12.20 um 10:55 schrieb Pekka Paalanen:
On Fri, 11 Dec 2020 09:56:07 +0530
Shashank Sharma wrote:
Hello Simon,
Hope you are doing well,
I was helping out Aurabindo and the team
On Fri, 11 Dec 2020, Simon Ser wrote:
> User-space expects to be able to pick a primary plane for each CRTC
> exposed by the driver. Make sure this assumption holds in
> drm_mode_config_validate.
>
> Use the legacy drm_crtc.primary field to check this, because it's
> simpler and we require
Hi,
On Tue, Dec 08, 2020 at 09:34:05AM +0100, Frieder Schrempf wrote:
> On 03.12.20 14:25, Maxime Ripard wrote:
> > From: Dave Stevenson
> >
> > The DSI1_PHY_AFEC0_PD_DLANE1 and DSI1_PHY_AFEC0_PD_DLANE3 register
> > definitions were swapped, so trying to use more than a single data
> > lane
Replace a comma between expression statements by a semicolon.
Signed-off-by: Zheng Yongjun
---
drivers/gpu/drm/i915/display/intel_hdmi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c
b/drivers/gpu/drm/i915/display/intel_hdmi.c
Replace a comma between expression statements by a semicolon.
Signed-off-by: Zheng Yongjun
---
drivers/gpu/drm/imx/parallel-display.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/imx/parallel-display.c
b/drivers/gpu/drm/imx/parallel-display.c
index
Replace a comma between expression statements by a semicolon.
Signed-off-by: Zheng Yongjun
---
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
index
On Fri, 11 Dec 2020 11:28:36 +0100
Christian König wrote:
> Am 11.12.20 um 10:55 schrieb Pekka Paalanen:
> > On Fri, 11 Dec 2020 09:56:07 +0530
> > Shashank Sharma wrote:
> >
> >> Hello Simon,
> >>
> >> Hope you are doing well,
> >>
> >> I was helping out Aurabindo and the team with the
Thank you for the reviews Greg, Christian and Daniel!
On Thu, Dec 10, 2020 at 1:59 AM Christian König
wrote:
>
> In general a good idea, but I have a few concern/comments here.
>
> Am 10.12.20 um 05:43 schrieb Hridya Valsaraju:
> > This patch allows statistics to be enabled for each DMA-BUF in
On Tue, Dec 8, 2020 at 2:18 PM Arnd Bergmann wrote:
>
> On Tue, Dec 8, 2020 at 7:21 PM 'Nick Desaulniers' via Clang Built
> Linux wrote:
> >
> > On Tue, Dec 8, 2020 at 6:26 AM Arnd Bergmann wrote:
> > >
> > > On Mon, Dec 7, 2020 at 11:28 PM 'Nick Desaulniers' via Clang Built
> > > Linux wrote:
Thanks again for the reviews!
On Thu, Dec 10, 2020 at 3:03 AM Christian König
wrote:
>
> Am 10.12.20 um 11:56 schrieb Greg KH:
> > On Thu, Dec 10, 2020 at 11:27:27AM +0100, Daniel Vetter wrote:
> >> On Thu, Dec 10, 2020 at 11:10:45AM +0100, Greg KH wrote:
> >>> On Thu, Dec 10, 2020 at 10:58:50AM
Thanks. Confirmed that this fixes display output for me on a 4K monitor.
On Mon, Nov 23, 2020 at 2:46 AM Robert Foss wrote:
>
> 4k requires two dsi pipes, so don't report MODE_OK when only a
> single pipe is configured. But rather report MODE_PANEL to
> signal that requirements of the panel are
1 - 100 of 200 matches
Mail list logo
