From: Rob Clark
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c| 2 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 2 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h | 3 +--
3 files changed, 3 insertions(+), 4 deletions(-)
diff --git
From: Rob Clark
I'm sure there is plenty more to remove.. this is just some of the ones
I noticed.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 19 ---
.../drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c | 3 ---
Hi all,
Today's linux-next merge of the drm tree got a conflict in:
drivers/gpu/drm/mediatek/mtk_drm_drv.c
between commit:
4c6f3196e6ea ("drm/mediatek: use correct device to import PRIME buffers")
from the drm-fixes tree and commit:
3baeeb21983a ("drm/mtk: Drop
Hey Dave,
This is mostly just the stuff I missed last round. Various cleanup
patches + fixes, improvements to display colour management, and some
code to avoid loading when power cables aren't properly attached.
There may be a second round next week with more changes, development
system died
The following changes since commit 4d352dbd5850bfc752609d46b5c8403ae0bd5163:
drm/nouveau/secboot/gp102-: remove WAR for SEC2 RTOS start bug
(2019-07-19 16:26:51 +1000)
are available in the Git repository at:
git://github.com/skeggsb/linux linux-5.3
for you to fetch changes up to
Doing a pm_runtime_put as soon as a job is submitted is wrong as it should
not happen until the job completes. It works because we are relying on the
autosuspend timeout to keep the h/w enabled.
Cc: Tomeu Vizoso
Cc: Steven Price
Cc: Alyssa Rosenzweig
Cc: David Airlie
Cc: Daniel Vetter
There's a few issues with the runtime PM initialization.
The documentation states pm_runtime_set_active() should be called before
pm_runtime_enable(). The pm_runtime_put_autosuspend() could suspend the GPU
before panfrost_perfcnt_init() is called which touches the h/w. The
autosuspend delay keeps
There is no point in resuming the h/w just to do flush operations and
doing so takes several locks which cause lockdep issues with the shrinker.
Rework the flush operations to only happen when the h/w is already awake.
This avoids taking any locks associated with resuming.
Cc: Tomeu Vizoso
Cc:
Lockdep reports a circular locking dependency with pages_lock taken in
the shrinker callback. The deadlock can't actually happen with current
users at least as a BO will never be purgeable when pages_lock is held.
To be safe, let's use mutex_trylock() instead and bail if a BO is locked
already.
Calling dma_unmap_sg() in drm_gem_shmem_free_object() is too late if the
backing pages have already been released by the shrinker. The result is
the following abort:
Unable to handle kernel paging request at virtual address 898ed000
Mem abort info:
ESR = 0x96000147
Exception class =
tlb_inv_context() hook is only called when freeing the page tables. There's
no point in flushing only to free the page tables immediately following.
There is also a problem that we could be accessing the h/w when suspended.
Cc: Tomeu Vizoso
Cc: Steven Price
Cc: Alyssa Rosenzweig
Cc: David
Lockdep reports a circular locking dependency with pages_lock taken in
the shrinker callback. The deadlock can't actually happen with current
users at least as a BO will never be purgeable when pages_lock is held.
To be safe, let's use mutex_trylock() instead and bail if a BO is locked
already.
Calls to panfrost_device_fini() access the h/w, but we already done a
pm_runtime_put_sync_autosuspend() beforehand. This only works if the
autosuspend delay is long enough. A 0ms delay will hang the system when
removing the device. Fix this by moving the pm_runtime_put_sync_suspend()
after the
Subject: [PATCH v2 0/8] panfrost: Locking and runtime PM fixes
With further testing of recent changes with lockdep and other locking
checks enabled, we've found several bugs in the shrinker code and one
sleep while atomic in panfrost_gem_open(). This series addresses those
issues.
Delaying the
Hi Linus,
Hi Linus,
Live from the laundromat after my washing machine broke down, we have
the 5.3-rc6 fixes. Changelog is in the tag below, but nothing too
noteworthy in here.
Dave.
drm-fixes-2019-08-23:
drm fixes for 5.3-rc6
rcar-du:
- LVDS dual-link mode fix
mediatek:
- of node refcount
On Thu, Aug 22, 2019 at 4:32 AM Steven Price wrote:
>
> When modifying panfrost_devfreq_target() to support a device without a
> regulator defined I missed the check on the error path. Let's add it.
>
> Reported-by: Dan Carpenter
> Fixes: e21dd290881b ("drm/panfrost: Enable devfreq to work
On Fri, 23 Aug 2019 at 05:29, Rodrigo Vivi wrote:
>
> Hi Dave and Daniel,
>
> Here goes the final pull request targeting 5.4.
For some reason patchwork hasn't picked this up. or if it has I can't
see it. Not sure whether it was the earlier patch code in it or
something else malformed.
Dave.
Add a type field to the drm_panel structure to report the panel type,
using DRM_MODE_CONNECTOR_* macros (the values that make sense are LVDS,
eDP, DSI and DPI). This will be used to initialise the corresponding
connector type.
Update all panel drivers to fill the new field.
Signed-off-by:
The drm panel bridge creates a connector using a connector type explicit
passed by the display controller or bridge driver that instantiates the
panel bridge. Now that drm_panel reports its connector type, use it and
remove the connector_type argument to drm_panel_bridge_add() and
Function intel_dp_setup_hdr_metadata_infoframe_sdp handles Infoframe SDP
header and data block setup for HDR Static Metadata. It enables writing of
HDR metadata infoframe SDP to panel. Support for HDR video was introduced
in DisplayPort 1.4. It implements the CTA-861-G standard for transport of
It attaches the colorspace connector property to a DisplayPort connector.
Based on colorspace change, modeset will be triggered to switch to a new
colorspace.
Based on colorspace property value create a VSC SDP packet with appropriate
colorspace. This would help to enable wider color gamut like
When BT.2020 Colorimetry output is used for DP, we should program BT.2020
Colorimetry to MSA and VSC SDP. It adds output_colorspace to
intel_crtc_state struct as a place holder of pipe's output colorspace.
In order to distinguish needed colorimetry for VSC SDP, it adds
It attaches HDR metadata property to DP connector on GLK+.
It enables HDR metadata infoframe sdp on GLK+ to be used to send
HDR metadata to DP sink.
Signed-off-by: Gwan-gyeong Mun
---
drivers/gpu/drm/i915/display/intel_dp.c | 4
1 file changed, 4 insertions(+)
diff --git
In order to use colorspace property to Display Port connectors, it extends
DRM_MODE_CONNECTOR_DisplayPort connector_type on
drm_mode_create_colorspace_property function.
Signed-off-by: Gwan-gyeong Mun
---
drivers/gpu/drm/drm_connector.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
It refactors and renames a function which handled vsc sdp header and data
block setup for supporting colorimetry format.
Function intel_dp_setup_vsc_sdp handles vsc sdp header and data block
setup for pixel encoding / colorimetry format.
In order to use colorspace information of a connector, it
Support for HDR10 video was introduced in DisplayPort 1.4.
On GLK+ platform, in order to use DisplayPort HDR10, we need to support
BT.2020 colorimetry and HDR Static metadata.
It implements the CTA-861-G standard for transport of static HDR metadata.
It enables writing of HDR metadata infoframe
Add Steven Price and Alyssa Rosenzweig as reviewers as they have been the
primary reviewers already.
Cc: Steven Price
Cc: Alyssa Rosenzweig
Cc: Tomeu Vizoso
Signed-off-by: Rob Herring
---
MAINTAINERS | 2 ++
1 file changed, 2 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index
Hi Boris,
On Thu, Aug 22, 2019 at 08:02:47PM +0200, Boris Brezillon wrote:
> On Thu, 22 Aug 2019 19:35:24 +0300 Laurent Pinchart wrote:
> > On Thu, Aug 22, 2019 at 06:29:09PM +0200, Boris Brezillon wrote:
> >> On Tue, 20 Aug 2019 04:16:44 +0300 Laurent Pinchart wrote:
> >>
> >>> Implement the
Hi Boris,
On Thu, Aug 22, 2019 at 06:41:25PM +0200, Boris Brezillon wrote:
> On Tue, 20 Aug 2019 04:16:35 +0300 Laurent Pinchart wrote:
>
> > +/**
> > + * enum drm_bridge_ops - Bitmask of operations supported by the bridge
> > + */
> > +enum drm_bridge_ops {
> > + /**
> > +*
Now that we've fixed i915 so that it sets a max SG segment length and
gotten rid of the relevant warnings, let's enable
CONFIG_DMA_API_DEBUG_SG for intel-ci so that we can catch issues like
this in the future as well.
Changes since v2:
* Also select DMA_API_DEBUG - Chris Wilson
Signed-off-by:
OK-done reviewing, but there's some stuff missing here. The PBN bandwidth
checks in https://patchwork.freedesktop.org/patch/325604/?series=65423=3
need to be moved into drm_dp_mst_atomic_check(), along with moving amdgpu over
to using drm_dp_mst_atomic_check(). Doing so will also give us PBN
On Thu, 2019-08-22 at 09:57 -0400, David Francis wrote:
> Add drm_dp_mst_dsc_caps_for_port and drm_dp_mst_dsc_enable,
> two helper functions for MST DSC
>
> The former, given a port, returns the raw DPCD DSC caps off
> that port.
>
> The latter, given a port, enables or disables DSC on that
Hi Boris,
On Thu, Aug 22, 2019 at 07:00:11PM +0200, Boris Brezillon wrote:
> On Tue, 20 Aug 2019 04:17:05 +0300 Laurent Pinchart wrote:
> > Use the drm_bridge_connector helper to create a connector for pipelines
> > that use drm_bridge. This allows splitting connector operations across
> >
On Tue, 20 Aug 2019 22:24:40 +0200 Daniel Vetter wrote:
> Hi Peter,
>
> Iirc you've been involved at least somewhat in discussing this. -mm folks
> are a bit undecided whether these new non_block semantics are a good idea.
> Michal Hocko still is in support, but Andrew Morton and Jason
Quoting Lyude Paul (2019-08-22 21:31:27)
> Now that we've fixed i915 so that it sets a max SG segment length and
> gotten rid of the relevant warnings, let's enable
> CONFIG_DMA_API_DEBUG_SG for intel-ci so that we can catch issues like
> this in the future as well.
>
> Signed-off-by: Lyude Paul
DP 1.4 specification defines Link Training Tunable PHY Repeater (LTTPR)
which is required to add support for systems with Thunderbolt or other
repeater devices.
Cc: Abdoulaye Berthe
Cc: Harry Wentland
Cc: Leo Li
Signed-off-by: Rodrigo Siqueira
Signed-off-by: Abdoulaye Berthe
---
On 22/08/2019 21:24, Jason Ekstrand wrote:
On Thu, Aug 22, 2019 at 9:55 AM Lionel Landwerlin
mailto:lionel.g.landwer...@intel.com>>
wrote:
We've added a set of new APIs to manipulate syncobjs holding timelines
of dma_fence. This adds a bit of documentation about how this works.
On Thu, Aug 22, 2019 at 6:06 PM Stephen Rothwell wrote:
>
> Hi all,
>
> After merging the drm-fixes tree, today's linux-next build (KCONFIG_NAME)
> produced this warning:
>
> drivers/gpu/drm/amd/amdgpu/../powerplay/smu_v11_0.c: In function
> 'smu_v11_0_setup_pptable':
>
Hi all,
After merging the drm-fixes tree, today's linux-next build (KCONFIG_NAME)
produced this warning:
drivers/gpu/drm/amd/amdgpu/../powerplay/smu_v11_0.c: In function
'smu_v11_0_setup_pptable':
drivers/gpu/drm/amd/amdgpu/../powerplay/smu_v11_0.c:368:40: warning: 'size' may
be used
On Thu, 2019-08-22 at 09:57 -0400, David Francis wrote:
> This field on drm_dp_mst_branch was never filled
>
> Initialize it to zero when the list of ports is created.
> When a port is added to the list, increment num_ports,
> and when a port is removed from the list, decrement num_ports.
>
>
Mhhh, one last nitpick
On Thu, 2019-08-22 at 09:57 -0400, David Francis wrote:
> Instead of having drm_dp_dpcd_read/write and
> drm_dp_mst_dpcd_read/write as entry points into the
> aux code, have drm_dp_dpcd_read/write handle both.
>
> This means that DRM drivers can make MST DPCD read/writes.
For HDMI2.0 CTS item - HF1-35, it verifies if the source generates
video timing "64:27" video format correctly.
eg: (vic-76) 1920x1080p@60Hz,24bpp
This patch add on "64:27" and "256:135" to drm_aspect_ratio_enum_list.
Thereafter, one can specify the aspect ratio to "64:27" or "256:135"
after
Agh, sorry to go back on this - I'm noticing a lot more changes we should have
now that I've been able apply this locally to my tree. See below:
On Thu, 2019-08-22 at 09:57 -0400, David Francis wrote:
> With DSC, bpp can be a multiple of 1/16, so
> drm_dp_calc_pbn_mode is insufficient.
>
> Add
Still in the process of reviewing this, but one minor change that should be
done on all of the patches (which I didn't notice before, whoops):
s:drm/dp-mst:drm/dp_mst:g
On Thu, 2019-08-22 at 09:57 -0400, David Francis wrote:
> Add necessary support for MST DSC.
> (Display Stream COmpression over
If we don't find any matching components, we should go through the error
handling path, in order to free some resources.
Fixes: ca5be902a87d ("drm/mcde: Fix uninitialized variable")
Signed-off-by: Christophe JAILLET
---
drivers/gpu/drm/mcde/mcde_drv.c | 3 ++-
1 file changed, 2 insertions(+), 1
On Thu, Aug 22, 2019 at 3:21 PM Harry Wentland wrote:
>
> On 2019-08-16 6:10 p.m., Colin King wrote:
> > From: Colin Ian King
> >
> > Currently the pointer init_data is dereferenced on the assignment
> > of fw_info before init_data is sanity checked to see if it is null.
> > Fix te potential
Currently, we don't call dma_set_max_seg_size() for i915 because we
intentionally do not limit the segment length that the device supports.
However, this results in a warning being emitted if we try to map
anything larger than SZ_64K on a kernel with CONFIG_DMA_API_DEBUG_SG
enabled:
[
Now that we've fixed i915 so that it sets a max SG segment length and
gotten rid of the relevant warnings, let's enable
CONFIG_DMA_API_DEBUG_SG for intel-ci so that we can catch issues like
this in the future as well.
Signed-off-by: Lyude Paul
Cc: Chris Wilson
---
...whoops.
Ignore this patch-Chris Wilson had requested that I send a patch along with
this one to enable CONFIG_DMA_API_DEBUG_SG in CI, but I completely forgot to
do that before sending. Will send out a reroll with that in just a moment
On Thu, 2019-08-22 at 16:04 -0400, Lyude Paul wrote:
>
Currently, we don't call dma_set_max_seg_size() for i915 because we
intentionally do not limit the segment length that the device supports.
However, this results in a warning being emitted if we try to map
anything larger than SZ_64K on a kernel with CONFIG_DMA_API_DEBUG_SG
enabled:
[
On Fri, 23 Aug 2019 at 03:25, Thomas Zimmermann wrote:
>
> Hi
>
> I was traveling and could reply earlier. Sorry for taking so long.
>
> Am 13.08.19 um 11:36 schrieb Feng Tang:
> > Hi Thomas,
> >
> > On Mon, Aug 12, 2019 at 03:25:45PM +0800, Feng Tang wrote:
> >> Hi Thomas,
> >>
> >> On Fri, Aug
Hi Jacopo,
On Thu, Aug 22, 2019 at 09:19:25PM +0200, Jacopo Mondi wrote:
> On Tue, Aug 20, 2019 at 09:42:15PM +0300, Laurent Pinchart wrote:
> > On Sat, Jul 06, 2019 at 04:07:46PM +0200, Jacopo Mondi wrote:
> > > Update CMM settings at in the atomic commit tail helper method.
> > >
> > > The CMM
On Thu, Aug 22, 2019 at 9:55 AM Lionel Landwerlin <
lionel.g.landwer...@intel.com> wrote:
> We've added a set of new APIs to manipulate syncobjs holding timelines
> of dma_fence. This adds a bit of documentation about how this works.
>
> Signed-off-by: Lionel Landwerlin
> Cc: Christian Koenig
>
On 2019-08-16 6:10 p.m., Colin King wrote:
> From: Colin Ian King
>
> Currently the pointer init_data is dereferenced on the assignment
> of fw_info before init_data is sanity checked to see if it is null.
> Fix te potential null pointer dereference on init_data by only
> performing dereference
Hi Laurent,
On Tue, Aug 20, 2019 at 09:42:15PM +0300, Laurent Pinchart wrote:
> Hi Jacopo,
>
> Thank you for the patch.
>
> On Sat, Jul 06, 2019 at 04:07:46PM +0200, Jacopo Mondi wrote:
> > Update CMM settings at in the atomic commit tail helper method.
> >
> > The CMM is updated with new gamma
Hi Laurent,
On Tue, Aug 20, 2019 at 08:54:57PM +0300, Laurent Pinchart wrote:
> Hi Jacopo,
>
> Thank you for the patch.
>
> On Sat, Jul 06, 2019 at 04:07:43PM +0200, Jacopo Mondi wrote:
> > Implement device tree parsing to collect the available CMM instances
> > described by the 'cmms' property.
On Tue, 20 Aug 2019 04:16:48 +0300
Laurent Pinchart wrote:
> + /**
> + * @bridge_detect:
^ @bridge_modes
> + *
> + * The last bridge in the chain (closest to the connector) that provides
> + * connector modes detection, if any (see _BRIDGE_OP_MODES).
> +
On Tue, 20 Aug 2019 04:16:47 +0300
Laurent Pinchart wrote:
> The tfp410 driver can operate as part of a pipeline where the
> drm_connector is created by the display controller. Enable this mode of
> operation by skipping creation of a drm_connector internally.
>
> Signed-off-by: Laurent
https://bugs.freedesktop.org/show_bug.cgi?id=110659
--- Comment #45 from tempel.jul...@gmail.com ---
Created attachment 145140
--> https://bugs.freedesktop.org/attachment.cgi?id=145140=edit
new dmesg log with debug patch applied after starting Hitman 2
--
You are receiving this mail because:
https://bugs.freedesktop.org/show_bug.cgi?id=110659
--- Comment #44 from tempel.jul...@gmail.com ---
I applied the patch to linux 5.2 (among
0001-drm-amd-display-Allow-fast-updates-again-for-swappin.patch) and as
expected, gamma adjustments have stopped working.
Unfortunately, the games still
On Thu, 22 Aug 2019 19:35:24 +0300
Laurent Pinchart wrote:
> Hi Boris,
>
> On Thu, Aug 22, 2019 at 06:29:09PM +0200, Boris Brezillon wrote:
> > On Tue, 20 Aug 2019 04:16:44 +0300 Laurent Pinchart wrote:
> >
> > > Implement the newly added bridge connector operations, allowing the
> > > usage
Hi
I was traveling and could reply earlier. Sorry for taking so long.
Am 13.08.19 um 11:36 schrieb Feng Tang:
> Hi Thomas,
>
> On Mon, Aug 12, 2019 at 03:25:45PM +0800, Feng Tang wrote:
>> Hi Thomas,
>>
>> On Fri, Aug 09, 2019 at 04:12:29PM +0800, Rong Chen wrote:
>>> Hi,
>>>
> Actually we
On Thu, 22 Aug 2019 19:54:56 +0300
Laurent Pinchart wrote:
> Hi Boris,
>
> On Thu, Aug 22, 2019 at 06:36:45PM +0200, Boris Brezillon wrote:
> > On Tue, 20 Aug 2019 04:16:46 +0300 Laurent Pinchart wrote:
> >
> > > Now that a driver is available for display connectors, replace the
> > > manual
https://bugs.freedesktop.org/show_bug.cgi?id=110659
--- Comment #43 from Nicholas Kazlauskas ---
Created attachment 145139
--> https://bugs.freedesktop.org/attachment.cgi?id=145139=edit
0001-drm-amd-display-Test-patch-for-disabling-color-adjus.patch
>From your video it looks like something is
Hi Robert,
thanks for your comments! Most of this make sense, i have some comments
inline below (mostly since I only have access to the imx8mq reference
manual but not to the any NWL IP docs):
On Thu, Aug 22, 2019 at 01:18:21PM +, Robert Chiras wrote:
> Hi Guido,
>
> I added my signed-off,
https://bugs.freedesktop.org/show_bug.cgi?id=110659
--- Comment #42 from tempel.jul...@gmail.com ---
(In reply to Nicholas Kazlauskas from comment #39)
> Disabling the compositor doesn't make a difference as far as stuttering goes
> for Hitman 2's DXVK - I don't see any commits in the log that
On Tue, 20 Aug 2019 04:17:05 +0300
Laurent Pinchart wrote:
> Use the drm_bridge_connector helper to create a connector for pipelines
> that use drm_bridge. This allows splitting connector operations across
> multiple bridges when necessary, instead of having the last bridge in
> the chain
Hi Boris,
On Thu, Aug 22, 2019 at 06:36:45PM +0200, Boris Brezillon wrote:
> On Tue, 20 Aug 2019 04:16:46 +0300 Laurent Pinchart wrote:
>
> > Now that a driver is available for display connectors, replace the
> > manual connector handling code with usage of the DRM bridge API. The
> > tfp410
Hi Ulrich,
On Tue, Aug 20, 2019 at 08:37:44PM +0300, Laurent Pinchart wrote:
> Hello,
>
> On Tue, Jul 16, 2019 at 03:17:04PM +0200, Ulrich Hecht wrote:
> > > On July 6, 2019 at 4:07 PM Jacopo Mondi wrote:
> > >
> > > Add a driver for the R-Car Display Unit Color Correction Module.
> > >
> > > In
On Tue, 20 Aug 2019 04:16:35 +0300
Laurent Pinchart wrote:
>
> +/**
> + * enum drm_bridge_ops - Bitmask of operations supported by the bridge
> + */
> +enum drm_bridge_ops {
> + /**
> + * @DRM_BRIDGE_OP_DETECT: The bridge can detect displays connected to
> + * its output. Bridges
https://bugs.freedesktop.org/show_bug.cgi?id=110659
--- Comment #41 from tempel.jul...@gmail.com ---
Created attachment 145138
--> https://bugs.freedesktop.org/attachment.cgi?id=145138=edit
debug dmesg.log after running Hitman 2 with the issue
--
You are receiving this mail because:
You are
Hi Boris,
On Thu, Aug 22, 2019 at 06:05:20PM +0200, Boris Brezillon wrote:
> On Tue, 20 Aug 2019 04:16:42 +0300 Laurent Pinchart wrote:
>
> > + /*
> > +* Get the HPD GPIO for DVI and HDMI connectors. If the GPIO can provide
> > +* interrupts, register an interrupt handler.
> > +*/
On Tue, 20 Aug 2019 04:16:46 +0300
Laurent Pinchart wrote:
> Now that a driver is available for display connectors, replace the
> manual connector handling code with usage of the DRM bridge API. The
> tfp410 driver doesn't deal with the display connector directly anymore,
> but still delegates
Hi Boris,
On Thu, Aug 22, 2019 at 06:29:09PM +0200, Boris Brezillon wrote:
> On Tue, 20 Aug 2019 04:16:44 +0300 Laurent Pinchart wrote:
>
> > Implement the newly added bridge connector operations, allowing the
> > usage of drm_bridge_panel with drm_bridge_connector.
> >
> > Signed-off-by:
On Tue, 20 Aug 2019 04:16:44 +0300
Laurent Pinchart wrote:
> Implement the newly added bridge connector operations, allowing the
> usage of drm_bridge_panel with drm_bridge_connector.
>
> Signed-off-by: Laurent Pinchart
> ---
> drivers/gpu/drm/bridge/panel.c | 18 +-
> 1 file
https://bugs.freedesktop.org/show_bug.cgi?id=110659
--- Comment #40 from tempel.jul...@gmail.com ---
Created attachment 145137
--> https://bugs.freedesktop.org/attachment.cgi?id=145137=edit
video demonstrating the issue in Hitman 2 (different to Oblivion/Skyrim)
--
You are receiving this mail
https://bugs.freedesktop.org/show_bug.cgi?id=110865
--- Comment #17 from Alex Deucher ---
Note that it will only work if your monitors have identical timing.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel
https://bugs.freedesktop.org/show_bug.cgi?id=110865
Alex Deucher changed:
What|Removed |Added
Attachment #144983|0 |1
is obsolete|
On Tue, 20 Aug 2019 04:16:45 +0300
Laurent Pinchart wrote:
> The drmP.h header is deprecated, replace it with the headers
> specifically needed by the tfp410 driver. While at it, replace the DRM
> print macros with dev_info() and dev_err() instead of including
> drm_print.h
Looks like
On Thu, Aug 22, 2019 at 9:37 AM Brian Masney wrote:
>
> Some A3xx and A4xx Adreno GPUs do not have GMEM inside the GPU core and
> must use the On Chip MEMory (OCMEM) in order to be functional. Add the
> optional ocmem property to the Adreno Graphics Management Unit bindings.
>
> Signed-off-by:
On Tue, 20 Aug 2019 04:16:42 +0300
Laurent Pinchart wrote:
> + /*
> + * Get the HPD GPIO for DVI and HDMI connectors. If the GPIO can provide
> + * interrupts, register an interrupt handler.
> + */
> + if (type == DRM_MODE_CONNECTOR_DVII ||
> + type ==
Hi Julien,
On 22/08/2019 16:43, Julien Masson wrote:
> This patch introduce new enum which contains all VPU family (GXBB,
> GXL, GXM and G12A).
> This enum is used to detect the VPU compatible with the device.
>
> We only need to set .data to the corresponding enum in the device
> table, no need
From: Rob Clark
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 20
1 file changed, 20 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
index 45bfac9e3af7..970194958257 100644
---
On Tue, 20 Aug 2019 04:16:41 +0300
Laurent Pinchart wrote:
> The TI OP362 is an analog video amplifier controlled through a GPIO. Add
> support for it to the simple-bridge driver.
>
> Signed-off-by: Laurent Pinchart
> Reviewed-by: Andrzej Hajda
Reviewed-by: Boris Brezillon
> ---
>
On Thu, Aug 22, 2019 at 5:26 AM Ville Syrjälä
wrote:
>
> On Wed, Aug 21, 2019 at 06:57:24PM -0700, Rob Clark wrote:
> > From: Rob Clark
> >
> > Signed-off-by: Rob Clark
> > ---
> > drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 20
> > 1 file changed, 20 insertions(+)
> >
> >
On Tue, 20 Aug 2019 04:16:40 +0300
Laurent Pinchart wrote:
> If an enable GPIO is declared in the firmware, assert it when enabling
> the bridge and deassert it when disabling it.
>
> Signed-off-by: Laurent Pinchart
> Reviewed-by: Andrzej Hajda
> Reviewed-by: Stefan Agner
Reviewed-by: Boris
On Tue, 20 Aug 2019 04:16:39 +0300
Laurent Pinchart wrote:
> Create a new simple_bridge_info structure that stores information about
> the bridge model, and store the bridge timings in there, along with the
> connector type. Use that new structure for of_device_id data. This
> enables support
On Tue, 20 Aug 2019 04:16:38 +0300
Laurent Pinchart wrote:
> The dumb-vga-dac driver can support simple DRM bridges without being
> limited to VGA DACs. Rename it to simple-bridge.
>
> Signed-off-by: Laurent Pinchart
> Reviewed-by: Andrzej Hajda
Reviewed-by: Boris Brezillon
> ---
>
On Tue, 20 Aug 2019 04:16:37 +0300
Laurent Pinchart wrote:
> The dumb-vga-dac driver is a simple DRM bridge driver for simple VGA
> DACs that don't require configuration. Other non-VGA bridges fall in a
> similar category, and would benefit from a common driver. Prepare for
> this by renaming
On Tue, 20 Aug 2019 04:16:36 +0300
Laurent Pinchart wrote:
> Most bridge drivers create a DRM connector to model the connector at the
> output of the bridge. This model is historical and has worked pretty
> well so far, but causes several issues:
>
> - It prevents supporting more complex
On Tue, 20 Aug 2019 04:16:35 +0300
Laurent Pinchart wrote:
> To support implementation of DRM connectors on top of DRM bridges
> instead of by bridges, the drm_bridge needs to expose new operations and
> data:
>
> - Output detection, hot-plug notification, mode retrieval and EDID
> retrieval
Handled the need for exposing enum port to mei_hdcp driver, by
converting the port into ddi index as per ME FW and sending to mei_hdcp.
Hence move enum port definition into I915 driver itself.
v2:
intel_display.h is included in intel_hdcp.h
v3:
enum port is declared in headers.
Enabling the HDCP1.4 and 2.2 on TGL by supporting the HW block movement
from DDI into transcoder.
v9:
s/trans/cpu_transcoder
enum port and transcoders are declared at few headers.
Ramalingam C (6):
drm/i915: mei_hdcp: I915 sends ddi index as per ME FW
drm: Move port definition back to
From Gen12 onwards, HDCP HW block is implemented within transcoders.
Till Gen11 HDCP HW block was part of DDI.
Hence required changes in HW programming is handled here.
As ME FW needs the transcoder detail on which HDCP is enabled
on Gen12+ platform, we are populating the detail in
I915 needs to send the index of the transcoder as per ME FW.
To support this, define enum mei_fw_ddi and add as a member into
the struct hdcp_port_data.
Signed-off-by: Ramalingam C
Acked-by: Jani Nikula
---
include/drm/i915_mei_hdcp_interface.h | 13 +
1 file changed, 13
I915 converts it's port value into ddi index defiend by ME FW
and pass it as a member of hdcp_port_data structure.
Hence expose the enum mei_fw_ddi to I915 through
i915_mei_interface.h.
Signed-off-by: Ramalingam C
Acked-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_hdcp.c | 15
On gen12+ platforms, HDCP HW is associated to the transcoder.
Hence on every modeset update associated transcoder into the
intel_hdcp of the port.
v2:
s/trans/cpu_transcoder [Jani]
Signed-off-by: Ramalingam C
Acked-by: Jani Nikula
---
.../drm/i915/display/intel_display_types.h| 7 +++
Hi Jacopo,
On Thu, Aug 22, 2019 at 03:01:46PM +0200, Jacopo Mondi wrote:
> On Tue, Aug 20, 2019 at 08:34:44PM +0300, Laurent Pinchart wrote:
> > On Sat, Jul 06, 2019 at 04:07:41PM +0200, Jacopo Mondi wrote:
> >> Add a driver for the R-Car Display Unit Color Correction Module.
> >>
> >> In most of
Hi Jacopo,
On Thu, Aug 22, 2019 at 12:00:51PM +0200, Jacopo Mondi wrote:
> On Wed, Aug 21, 2019 at 02:16:02PM +0200, Geert Uytterhoeven wrote:
> > On Sat, Jul 6, 2019 at 4:07 PM Jacopo Mondi
> > wrote:
> > > Update the 'vsps' property in the R-Car Gen3 SoC device tree files to
> > > match
We've added a set of new APIs to manipulate syncobjs holding timelines
of dma_fence. This adds a bit of documentation about how this works.
Signed-off-by: Lionel Landwerlin
Cc: Christian Koenig
Cc: Jason Ekstrand
Cc: David(ChunMing) Zhou
---
drivers/gpu/drm/drm_syncobj.c | 87
1 - 100 of 246 matches
Mail list logo
