Hi
Am 25.08.19 um 13:25 schrieb Ivan D:
> I'd like to learn DRM subsystem and GPU driver development and I was
> thinking about about writing XGI DRM driver as a practice project
> since:
> - there's (or was until recently) staging fbdev driver that should
> hopefully be working
> - it's still pos
Hi Jacopo,
On Sun, Aug 25, 2019 at 3:50 PM Jacopo Mondi wrote:
> Add CMM units to Renesas R-Car M3-W device tree and reference them from
> the Display Unit they are connected to.
>
> Signed-off-by: Jacopo Mondi
> ---
> arch/arm64/boot/dts/renesas/r8a7796.dtsi | 25
> 1
Hi Jacopo,
On Sun, Aug 25, 2019 at 3:51 PM Jacopo Mondi wrote:
> Add a driver for the R-Car Display Unit Color Correction Module.
> In most of Gen3 SoCs, each DU output channel is provided with a CMM unit
> to perform image enhancement and color correction.
>
> Add support for CMM through a drive
Hi Jacopo,
On Sun, Aug 25, 2019 at 3:50 PM Jacopo Mondi wrote:
> Add device tree bindings documentation for the Renesas R-Car Display
> Unit Color Management Module.
>
> CMM is the image enhancement module available on each R-Car DU video
> channel on R-Car Gen2 and Gen3 SoCs (V3H and V3M exclude
On Fri, 23 Aug 2019 22:32:44 +0300
Laurent Pinchart wrote:
> 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.
>
On Fri, 23 Aug 2019 22:32:45 +0300
Laurent Pinchart wrote:
> The drm panel bridge creates a connector using a connector type explicit
^explicitly
> passed by the display controller or bridge driver that instantiates the
> panel b
Hi Geert,
On Mon, Aug 26, 2019 at 09:34:41AM +0200, Geert Uytterhoeven wrote:
> Hi Jacopo,
>
> On Sun, Aug 25, 2019 at 3:50 PM Jacopo Mondi
> wrote:
> > Add device tree bindings documentation for the Renesas R-Car Display
> > Unit Color Management Module.
> >
> > CMM is the image enhancement mod
Hi Geert.
On Mon, Aug 26, 2019 at 09:28:56AM +0200, Geert Uytterhoeven wrote:
> Hi Jacopo,
>
> On Sun, Aug 25, 2019 at 3:50 PM Jacopo Mondi
> wrote:
> > Add CMM units to Renesas R-Car M3-W device tree and reference them from
> > the Display Unit they are connected to.
> >
> > Signed-off-by: Jaco
Hi Geert,
On Mon, Aug 26, 2019 at 09:31:02AM +0200, Geert Uytterhoeven wrote:
> Hi Jacopo,
>
> On Sun, Aug 25, 2019 at 3:51 PM Jacopo Mondi
> wrote:
> > Add a driver for the R-Car Display Unit Color Correction Module.
> > In most of Gen3 SoCs, each DU output channel is provided with a CMM unit
>
https://bugs.freedesktop.org/show_bug.cgi?id=111455
--- Comment #1 from Nikolay Kichukov ---
Not much seems to have been captured by running the kernel with:
'drm.debug=0x1e log_buf_len=4M'
...snip...
Aug 25 19:03:44 localhost kernel: [283823.907593][T15386]
[drm:amdgpu_display_flip_work_func [a
https://bugs.freedesktop.org/show_bug.cgi?id=110795
--- Comment #36 from Tomas ---
@Andrew Shark: well, it asked me once for the users password for sudo, which I
successfully input and worked. "[sudo] password for user: ".
I have as well tried your removal script, however after running it with su
Hi Jacopo,
On Mon, Aug 26, 2019 at 9:58 AM Jacopo Mondi wrote:
> On Mon, Aug 26, 2019 at 09:34:41AM +0200, Geert Uytterhoeven wrote:
> > On Sun, Aug 25, 2019 at 3:50 PM Jacopo Mondi
> > wrote:
> > > Add device tree bindings documentation for the Renesas R-Car Display
> > > Unit Color Management
Hi,
I would have liked to get some context on the purpose of GEM TTM
helpers. Is is just share-able code?
From my understanding VRAM helpers _are_ GEM TTM helpers. And they where
re-named to VRAM helpers, so that the naming is independent from the
implementation (and vice versa).
Wrt qxl, would
On 8/22/19 10:03 AM, Hans Verkuil wrote:
> Ville or Rodrigo,
>
> Can one of you either merge this patch or Ack it so that I can merge this?
Ping!
Regards,
Hans
>
> Thank you!
>
> Regards,
>
> Hans
>
> On 8/14/19 12:45 PM, Dariusz Marcinkiewicz wrote:
>> Use the new cec_notifi
On 8/23/19 9:01 PM, Laurent Pinchart wrote:
> (And CC'ing Andrzej Hajda and Neil Armstrong as the new DRM bridge
> maintainers, as well as Boris Brezillon, to make sure they're aware of
> the problem)
>
> I would really appreciate if we could delay merging this series and
> other similar changes u
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 09248398fa7b..f1af3490f96b 100644
--- a/drivers/gp
Hi all,
Following Jason's suggestion on another thread adding timeline
documentation [1], here is a small series adding a creation flag to
syncobjs so that users are prevented to drop the existing timeline
fences in the syncobj, effectivelly ensuring a user always adds to the
dma_fence_chain inste
On Mon, Aug 26, 2019 at 10:47 AM Thomas Zimmermann wrote:
>
> Hi,
>
> I would have liked to get some context on the purpose of GEM TTM
> helpers. Is is just share-able code?
>
> From my understanding VRAM helpers _are_ GEM TTM helpers. And they where
> re-named to VRAM helpers, so that the naming
Similarly to the host path from drm_syncobj.c we would like to
disallow those operations to help applications figure where they using
the wrong kind of ioctl.
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers
Binary/legacy signal operations on a syncobj work by replacing the
dma_fence held within the syncobj. Whe dealing with timeline
semaphores we would like to avoid this as this would effectivelly lead
to looser synchronization (by discarding the dma_fence_chain mechanism
waiting on all previous dma_f
On Fri, Aug 16, 2019 at 4:10 AM Lyude Paul wrote:
>
> Reviewed-by: Lyude Paul
Reviewed-by: Ben Skeggs
>
> On Wed, 2019-08-14 at 12:44 +0200, Dariusz Marcinkiewicz wrote:
> > Pass the connector info to the CEC adapter. This makes it possible
> > to associate the CEC adapter with the correspondin
Hi,
On 2019/7/23 18:38, Chuhong Yuan wrote:
Instead of using to_pci_dev + pci_get_drvdata,
use dev_get_drvdata to make code simpler.
Signed-off-by: Chuhong Yuan
Chuhong, thanks for the patch. And sorry for late reply.
Acked-by: Xinliang Liu
Applied to drm-hisilicon-hibmc-next.
Thanks,
Xinl
Hi Dave and Daniel,
Three small cleanup and fix patches for 5.4 hisilicon hibmc driver.
I have tested and verified on taishan 2280v1/v2 machines.
As my drm-misc ssh account request[1] is not finish yet, I still send
the pull this time.
Please pull, thanks.
[1] https://gitlab.freedesktop.org/f
On Mon, Aug 26, 2019 at 9:11 AM Thomas Zimmermann wrote:
>
> Hi
>
> Am 25.08.19 um 13:25 schrieb Ivan D:
> > I'd like to learn DRM subsystem and GPU driver development and I was
> > thinking about about writing XGI DRM driver as a practice project
> > since:
> > - there's (or was until recently) s
On Sun, Aug 25, 2019 at 10:13:05PM +0800, Hillf Danton wrote:
>
> On Sun, 25 Aug 2019 04:28:01 -0700 Mikhail Gavrilov wrote:
> > Hi folks,
> > I left unblocked gnome-shell at noon, and when I returned at the
> > evening I discovered than monitor not sleeping and show open gnome
> > activity. At fi
https://bugs.freedesktop.org/show_bug.cgi?id=111236
--- Comment #7 from Michel Dänzer ---
(In reply to Julien Isorce from comment #6)
> It is working fine with mesa 18.3.6 [...]
I tried to bisect based on this premise, but I can reproduce the crash (with
totem) even with 18.3.6. Maybe this isn't
https://bugs.freedesktop.org/show_bug.cgi?id=110865
--- Comment #21 from Martin ---
sadly the screen still flickers
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
htt
Hi Hans,
On Mon, Aug 26, 2019 at 11:01:40AM +0200, Hans Verkuil wrote:
> On 8/23/19 9:01 PM, Laurent Pinchart wrote:
> > (And CC'ing Andrzej Hajda and Neil Armstrong as the new DRM bridge
> > maintainers, as well as Boris Brezillon, to make sure they're aware of
> > the problem)
> >
> > I would r
https://bugs.freedesktop.org/show_bug.cgi?id=22
--- Comment #24 from James Le Cuirot ---
It's hard to tell who's talking about which issue as there seems to be two or
even three different ones going on here.
I believe I'm seeing the originally reported issue as iommu=pt helps on my
2700U. Wi
Hi Jacopo,
On Mon, Aug 26, 2019 at 09:59:43AM +0200, Jacopo Mondi wrote:
> On Mon, Aug 26, 2019 at 09:34:41AM +0200, Geert Uytterhoeven wrote:
> > On Sun, Aug 25, 2019 at 3:50 PM Jacopo Mondi
> > wrote:
> > > Add device tree bindings documentation for the Renesas R-Car Display
> > > Unit Color M
On 8/26/19 12:13 PM, Laurent Pinchart wrote:
> Hi Hans,
>
> On Mon, Aug 26, 2019 at 11:01:40AM +0200, Hans Verkuil wrote:
>> On 8/23/19 9:01 PM, Laurent Pinchart wrote:
>>> (And CC'ing Andrzej Hajda and Neil Armstrong as the new DRM bridge
>>> maintainers, as well as Boris Brezillon, to make sure
https://bugs.freedesktop.org/show_bug.cgi?id=111487
Bug ID: 111487
Summary: AMD vega - display off/on -> solid green display
Product: DRI
Version: XOrg git
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
https://bugs.freedesktop.org/show_bug.cgi?id=111487
--- Comment #1 from bzz ---
Created attachment 145169
--> https://bugs.freedesktop.org/attachment.cgi?id=145169&action=edit
glxinfo output after fresh restart (no solid green display)
--
You are receiving this mail because:
You are the assig
Hi Feng
Am 24.08.19 um 07:16 schrieb Feng Tang:
> Hi Thomas,
>
> On Thu, Aug 22, 2019 at 07:25:11PM +0200, Thomas Zimmermann wrote:
>> Hi
>>
>> I was traveling and could reply earlier. Sorry for taking so long.
>
> No problem! I guessed so :)
>
>>
>> Am 13.08.19 um 11:36 schrieb Feng Tang:
>>
https://bugs.freedesktop.org/show_bug.cgi?id=111487
--- Comment #2 from bzz ---
after some time following errors appear in dmesg:
[ 488.913338] [drm:drm_atomic_helper_wait_for_flip_done [drm_kms_helper]]
*ERROR* [CRTC:56:crtc-0] flip_done timed out
[ 970.551486] [drm:drm_atomic_helper_wait_for
Hi,
On Tue, Aug 20, 2019 at 04:16:37AM +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 re
On Tue, Aug 20, 2019 at 04:16:38AM +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
Acked-by: Maxime Ripard
Maxime
--
Maxime
On Tue, Aug 20, 2019 at 04:16:39AM +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 suppor
On Tue, Aug 20, 2019 at 04:16:40AM +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: Ma
On Tue, Aug 20, 2019 at 04:16:41AM +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: Maxime Ripard
Maxime
--
Maxi
On Tue, Aug 20, 2019 at 04:16:42AM +0300, Laurent Pinchart wrote:
> Display connectors are modelled in DT as a device node, but have so far
> been handled manually in several bridge drivers. This resulted in
> duplicate code in several bridge drivers, with slightly different (and
> thus confusing)
Hi,
On 20/08/2019 04:16, Laurent Pinchart wrote:
In preparation of adding DRM bridge support to the hdmi4 encoder code,
rework the EDID read to isolate data read.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/dss/hdmi4.c | 94 +++-
drivers/gpu/drm/omap
On 20/08/2019 04:17, Laurent Pinchart wrote:
Move the omap_dss_device .set_timings(), .enable() and .disable()
operations to the drm_bridge functions. As the drm_bridge for the HDMI
encoder is unconditionally registered and attached, those operations
will be called at the appropriate time.
Signe
Hi,
On Wed, Aug 21, 2019 at 01:15:40PM +0300, Robert Chiras wrote:
> This patch-set improves the use of eLCDIF block on iMX 8 SoCs (like 8MQ, 8MM
> and 8QXP). Following, are the new features added and fixes from this
> patch-set:
I've applied this whole series on top of my NWL work and it looks go
On Wed, Aug 14, 2019 at 12:45:00PM +0200, Dariusz Marcinkiewicz wrote:
> Use the new cec_notifier_conn_(un)register() functions to
> (un)register the notifier for the HDMI connector, and fill in
> the cec_connector_info.
>
> Signed-off-by: Dariusz Marcinkiewicz
> Signed-off-by: Hans Verkuil
> Te
Hi Laurent,
On 20/08/2019 04:16, Laurent Pinchart wrote:
> The patches can be found at
>
> git://linuxtv.org/pinchartl/media.git omapdrm/bridge/devel
I took your branch, booted AM5 EVM (I see you had the hack dts patch in your
branch), and:
insmod nfs/work/linux/drivers/media/cec/cec.ko
https://bugs.freedesktop.org/show_bug.cgi?id=111488
Bug ID: 111488
Summary: Testing bug
Product: DRI
Version: unspecified
Hardware: All
OS: All
Status: NEW
Severity: blocker
Priority: not set
https://bugs.freedesktop.org/show_bug.cgi?id=110659
--- Comment #48 from Nicholas Kazlauskas ---
(In reply to tempel.julian from comment #47)
> I got a new 1440p 144 Hz FreeSync display, and as expected, the issue is
> unchanged with it.
>
> With it, I've created a new debug dmesg log for render
On Fri, 23 Aug 2019, 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.
>
> v2: Fix spacing
> v3: Dump dpcd acc
On Fri, 23 Aug 2019, David Francis wrote:
> Add drm_dp_mst_dsc_aux_for_port. To enable DSC, the DSC_ENABLED
> register might have to be written on the leaf port's DPCD,
> its parent's DPCD, or the MST manager's DPCD. This function
> finds the correct aux for the job.
>
> As part of this, add drm_d
https://bugs.freedesktop.org/show_bug.cgi?id=111487
--- Comment #3 from bzz ---
this issue seems connected also with HDMI.
I've connected whole desktop to older display, which has only DVI input and
used cable deskto-HDMI -> display-DVI and there is no issue, when i turn off
the display.
(the f
Den 21.08.2019 09.24, skrev Dan Carpenter:
> This code will likely crash if we try to do a zero byte write. The code
> looks like this:
>
> /* strip trailing whitespace */
> for (i = count - 1; i > 0; i--)
> if (isspace(buf[i]))
> ...
>
> W
Hi Tomi,
On Mon, Aug 26, 2019 at 02:39:25PM +0300, Tomi Valkeinen wrote:
> On 20/08/2019 04:16, Laurent Pinchart wrote:
> > In preparation of adding DRM bridge support to the hdmi4 encoder code,
> > rework the EDID read to isolate data read.
> >
> > Signed-off-by: Laurent Pinchart
> > ---
> >
On Thu, 22 Aug 2019, Simon Ser wrote:
> This patch adds a line with the port name to connectors in
> debugfs/i915_debug_info. If the port is Type-C, the Type-C port number is
> printed too.
>
> Signed-off-by: Simon Ser
> Cc: Imre Deak
> Cc: Manasi Navare
> ---
>
> Thanks for your comments, Imre
This series enables new DRM property, called "subconnector" in order to
represent DisplayPort dongle type.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
DP_MAX_DOWNSTREAM_PORTS=0x10 is a vendor-independent constant.
Reviewed-by: Emil Velikov
Signed-off-by: Oleg Vasilev
Cc: Ville Syrjälä
Cc: intel-...@lists.freedesktop.org
---
drivers/gpu/drm/i915/display/intel_display_types.h | 2 --
include/drm/drm_dp_helper.h| 2 ++
2
On 2019-08-26 4:57 a.m., YueHaibing wrote:
> If CONFIG_DRM_AMD_DC_DSC_SUPPORT is not set, build fails:
>
> drivers/gpu/drm/amd/amdgpu/../display/dc/dcn20/dcn20_hwseq.c: In function
> dcn20_hw_sequencer_construct:
> drivers/gpu/drm/amd/amdgpu/../display/dc/dcn20/dcn20_hwseq.c:2099:28:
> error:
Currently, downstream port type is only reported in debugfs. This
information should be considered important since it reflects the actual
physical connector type. Some userspace (e.g. window compositors)
may want to show this info to a user.
The 'subconnector' property is already utilized for DVI-
Since DP-specific information is stored in driver's structures, every
driver needs to implement subconnector property by itself.
Reviewed-by: Emil Velikov
Signed-off-by: Oleg Vasilev
Cc: Ben Skeggs
Cc: nouv...@lists.freedesktop.org
---
drivers/gpu/drm/nouveau/nouveau_connector.c | 13 +
The helper should always be used.
Reviewed-by: Emil Velikov
Signed-off-by: Oleg Vasilev
Cc: Ville Syrjälä
Cc: intel-...@lists.freedesktop.org
---
drivers/gpu/drm/drm_dp_helper.c | 3 +--
drivers/gpu/drm/i915/display/intel_dp.c | 2 +-
2 files changed, 2 insertions(+), 3 deletions(-)
d
Since DP-specific information is stored in driver's structures, every
driver needs to implement subconnector property by itself.
Reviewed-by: Emil Velikov
Signed-off-by: Oleg Vasilev
Cc: Alex Deucher
Cc: Christian König
Cc: David (ChunMing) Zhou
Cc: amd-...@lists.freedesktop.org
---
drivers/
Since DP-specific information is stored in driver's structures, every
driver needs to implement subconnector property by itself. Display
Core already has the subconnector information, we only need to
expose it through DRM property.
Signed-off-by: Oleg Vasilev
Tested-by: Oleg Vasilev
Cc: Alex Deu
Since DP-specific information is stored in driver's structures, every
driver needs to implement subconnector property by itself.
v2: updates to match previous commit changes
Reviewed-by: Emil Velikov
Tested-by: Oleg Vasilev
Signed-off-by: Oleg Vasilev
Cc: Ville Syrjälä
Cc: intel-...@lists.fre
This should probably be fixed to account for the scenario where an
HDMI connector is plugged directly into the DP++ port. I don't think
the dp.subconnector property will be valid in that case.
(Unfortunately I don't remember how one detects that particular
situation.)
On Mon, Aug 26, 2019 at 9:22
On Mon, 2019-08-26 at 16:10 +0300, Jani Nikula wrote:
> On Thu, 22 Aug 2019, Simon Ser wrote:
> > This patch adds a line with the port name to connectors in
> > debugfs/i915_debug_info. If the port is Type-C, the Type-C port
> > number is
> > printed too.
> >
> > Signed-off-by: Simon Ser
> > Cc:
Hi Tomi,
On Mon, Aug 26, 2019 at 03:15:23PM +0300, Tomi Valkeinen wrote:
> On 20/08/2019 04:16, Laurent Pinchart wrote:
>
> > The patches can be found at
> >
> > git://linuxtv.org/pinchartl/media.git omapdrm/bridge/devel
>
> I took your branch, booted AM5 EVM (I see you had the hack dts pat
Add necessary support for MST DSC.
(Display Stream Compression over Multi-Stream Transport)
v4: Split patchset and rebase onto drm-tip
v5: Clean up formatting, make new quirk
v6: Fix typo, split last patch in two
David Francis (6):
drm/dp_mst: Add PBN calculation for DSC modes
drm/dp_mst: Par
This field on drm_dp_mst_branch was never filled
It is initialized to zero when the port is kzallocced.
When a port is added to the list, increment num_ports,
and when a port is removed from the list, decrement num_ports.
v2: remember to decrement on port removal
v3: don't explicitly init to 0
S
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.
v2: Fix spacing
v3: Dump dpcd access on MST read/writes
Reviewed-by: Lyude Paul
Signed-o
As of DP1.4, ENUM_PATH_RESOURCES returns a bit indicating
if FEC can be supported up to that point in the MST network.
The bit is the first byte of the ENUM_PATH_RESOURCES ack reply,
bottom-most bit (refer to section 2.11.9.4 of DP standard,
v1.4)
That value is needed for FEC and DSC support
Sto
With DSC, bpp can be fractional in multiples of 1/16.
Change drm_dp_calc_pbn_mode to reflect this, adding a new
parameter bool dsc. When this parameter is true, treat the
bpp parameter as having units not of bits per pixel, but
1/16 of a bit per pixel
v2: Don't add separate function for this
Cc:
Add drm_dp_mst_dsc_aux_for_port. To enable DSC, the DSC_ENABLED
register might have to be written on the leaf port's DPCD,
its parent's DPCD, or the MST manager's DPCD. This function
finds the correct aux for the job.
As part of this, add drm_dp_mst_is_virtual_dpcd. Virtual DPCD
is a DP feature ne
Synaptics DP1.4 hubs (BRANCH_ID 0x90CC24) do not
support virtual DPCD registers, but do support DSC.
The DSC caps can be read from the physical aux,
like in SST DSC. These hubs have many different
DEVICE_IDs. Add a new quirk to detect this case.
Cc: Lyude Paul
Cc: Jani Nikula
Signed-off-by: Dav
On 2019-08-26 14:05, Guido Günther wrote:
> Hi,
> On Wed, Aug 21, 2019 at 01:15:40PM +0300, Robert Chiras wrote:
>> This patch-set improves the use of eLCDIF block on iMX 8 SoCs (like 8MQ, 8MM
>> and 8QXP). Following, are the new features added and fixes from this
>> patch-set:
>
> I've applied th
When calculating the HDMI PLL settings for a DMT mode PHY frequency,
use the correct max fractional PLL value for G12A VPU.
With this fix, we can finally setup the 1024x76-60 mode.
Fixes: 202b9808f8ed ("drm/meson: Add G12A Video Clock setup")
Signed-off-by: Neil Armstrong
---
drivers/gpu/drm/me
This is the new dma_fence_array based container for shared fences in the
dma_resv object.
Advantage of this approach is that you can grab a reference to the current set
of shared fences at any time, which allows us to drop the sequence number
increment and makes the whole RCU handling much more
The function is supposed to give a hint even if signaling is not enabled.
Signed-off-by: Christian König
---
drivers/dma-buf/dma-fence-array.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/dma-buf/dma-fence-array.c
b/drivers/dma-buf/dma-fence-array.c
i
A bit surprising that this wasn't already the case.
Signed-off-by: Christian König
---
include/linux/dma-fence-array.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/dma-fence-array.h b/include/linux/dma-fence-array.h
index 303dd712220f..f99cd7eb24e0 100644
---
Try to recycle an dma_fence_array object by dropping the last
reference to it without freeing it.
v2: fix the WARN_ON_ONCE recycle test after rebase
Signed-off-by: Christian König
---
drivers/dma-buf/dma-fence-array.c | 28
include/linux/dma-fence-array.h | 1 +
This seperates allocation and initialization of the dma_fence_array object
and allows allocating the fence array together with the dma_fence_array.
Signed-off-by: Christian König
---
drivers/dma-buf/dma-fence-array.c | 101 --
include/linux/dma-fence-array.h | 50 +
Add a new container for fences which internally uses
dma_fence_array's to store the fences.
Signed-off-by: Christian König
---
drivers/dma-buf/dma-resv.c | 181 +
include/linux/dma-resv.h | 49 ++
2 files changed, 230 insertions(+)
diff --git a/dri
Add a new dma_resv_prune_fences() function to improve memory management.
v2: fix potential NULL deref
Signed-off-by: Christian König
---
drivers/dma-buf/dma-resv.c | 37 ++
drivers/gpu/drm/i915/gem/i915_gem_wait.c | 3 +-
drivers/gpu/drm/i915/i915_gem_batc
Makes it easier to extract the fences in a dma_fence_array.
Signed-off-by: Christian König
---
drivers/dma-buf/dma-fence-array.c | 42 +++
include/linux/dma-fence-array.h | 24 ++
2 files changed, 66 insertions(+)
diff --git a/drivers/dma-buf/dma-fe
We can now grab a reference to all the fences in question,
no need for the sequence counter any more.
Signed-off-by: Christian König
---
drivers/dma-buf/dma-resv.c | 22 ++
drivers/gpu/drm/i915/gem/i915_gem_busy.c | 13 -
include/linux/dma-resv.h
Use the new dma_fence_array based implementation for shared fences.
Signed-off-by: Christian König
---
drivers/dma-buf/dma-buf.c | 102 +---
drivers/dma-buf/dma-resv.c| 492 +++---
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 52 +-
drivers
With DSC, bpp can be fractional in multiples of 1/16.
Change drm_dp_calc_pbn_mode to reflect this, adding a new
parameter bool dsc. When this parameter is true, treat the
bpp parameter as having units not of bits per pixel, but
1/16 of a bit per pixel
v2: Don't add separate function for this
Cc:
Add drm_dp_mst_dsc_aux_for_port. To enable DSC, the DSC_ENABLED
register might have to be written on the leaf port's DPCD,
its parent's DPCD, or the MST manager's DPCD. This function
finds the correct aux for the job.
As part of this, add drm_dp_mst_is_virtual_dpcd. Virtual DPCD
is a DP feature ne
Synaptics DP1.4 hubs (BRANCH_ID 0x90CC24) do not
support virtual DPCD registers, but do support DSC.
The DSC caps can be read from the physical aux,
like in SST DSC. These hubs have many different
DEVICE_IDs. Add a new quirk to detect this case.
Cc: Lyude Paul
Cc: Jani Nikula
Signed-off-by: Dav
As of DP1.4, ENUM_PATH_RESOURCES returns a bit indicating
if FEC can be supported up to that point in the MST network.
The bit is the first byte of the ENUM_PATH_RESOURCES ack reply,
bottom-most bit (refer to section 2.11.9.4 of DP standard,
v1.4)
That value is needed for FEC and DSC support
Sto
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.
v2: Fix spacing
v3: Dump dpcd access on MST read/writes
Reviewed-by: Lyude Paul
Signed-o
Add necessary support for MST DSC.
(Display Stream Compression over Multi-Stream Transport)
v4: Split patchset and rebase onto drm-tip
v5: Clean up formatting, make new quirk
v6: Fix typo, split last patch in two
v7: Fix compilation warnings
David Francis (6):
drm/dp_mst: Add PBN calculation fo
This field on drm_dp_mst_branch was never filled
It is initialized to zero when the port is kzallocced.
When a port is added to the list, increment num_ports,
and when a port is removed from the list, decrement num_ports.
v2: remember to decrement on port removal
v3: don't explicitly init to 0
S
On Mon, Aug 26, 2019 at 9:22 AM Harry Wentland wrote:
>
>
>
> On 2019-08-26 4:57 a.m., YueHaibing wrote:
> > If CONFIG_DRM_AMD_DC_DSC_SUPPORT is not set, build fails:
> >
> > drivers/gpu/drm/amd/amdgpu/../display/dc/dcn20/dcn20_hwseq.c: In function
> > dcn20_hw_sequencer_construct:
> > drivers/gp
https://bugzilla.kernel.org/show_bug.cgi?id=204683
Alex Deucher (alexdeuc...@gmail.com) changed:
What|Removed |Added
CC||alexdeuc...@gmail.c
This in one step in the right direction towards drm_encoder/drm_bridge
unification. By doing that we also allow encoder drivers to implement
the ->pre_enable() and ->post_disable() hooks without adding new
methods to drm_encoder_helper_funcs.
Signed-off-by: Boris Brezillon
---
Changes in v2:
* Ne
We are about to add a drm_bridge_state that inherits from
drm_private_state which is defined in drm_atomic.h. Problem is,
drm_atomic.h includes drm_crtc.h which in turn includes drm_bridge.h,
leading to "drm_private_state has incomplete type" error.
Let's force all users of the drm_bridge API to e
bridge->next is only points to the new bridge if drm_bridge_attach()
succeeds. No need to reset it manually here.
Note that this change is part of the attempt to make the bridge chain
a double-linked list. In order to do that we must patch all drivers
manipulating the bridge->next field.
Signed-o
Some LVDS encoder might support several input/output bus formats. Add
a way to describe the one used on a specific design by adding optional
'data-mapping' properties to the input/output ports.
Signed-off-by: Boris Brezillon
---
Changes in v2:
* Make the bus-format negotiation logic more generic
The encoder->enable() can't report errors and is expected to always
succeed. If we call pm_runtime_put() in the exynos_dsi_enable() error
path (as currently done) we'll have unbalanced get/put calls when
encoder->disable() is called.
The situation is not ideal since drm_panel_{prepare,enable}() ca
Those hooks are called exactly at the same time except the bridge
funcs have pre_enable()/post_disable() hooks which allows us to get
rid of the hack resetting encoder->bridge.next (was needed to control
the encoder/bridge enable/disable sequence).
We can also get of the dsi->bridge field since th
1 - 100 of 251 matches
Mail list logo
