Hi Dave and Daniel, fixes for v5.3-rc7, all cc: stable.
drm-intel-fixes-2019-08-29:
drm/i915 fixes for v5.3-rc7:
- Fix DP MST max BPC property creation after DRM register
- Fix unused ggtt deballooning and NULL dereference in guest
- Fix DSC eDP transcoder identification
- Fix WARN from DMA API d
Allow DRM TTM memory manager to register a work_struct, such that, when
a drmcgrp is under memory pressure, memory reclaiming can be triggered
immediately.
Change-Id: I25ac04e2db9c19ff12652b88ebff18b44b2706d8
Signed-off-by: Kenny Ho
---
drivers/gpu/drm/ttm/ttm_bo.c| 49 ++
Before this commit, drmcg limits are updated but enforcement is delayed
until the next time the driver check against the new limit. While this
is sufficient for certain resources, a more proactive enforcement may be
needed for other resources.
Introducing an optional drmcg_limit_updated callback
The number of logical gpu (lgpu) is defined to be the number of compute
unit (CU) for a device. The lgpu allocation limit only applies to
compute workload for the moment (enforced via kfd queue creation.) Any
cu_mask update is validated against the availability of the compute unit
as defined by t
drm.buffer.peak.stats
A read-only flat-keyed file which exists on all cgroups. Each
entry is keyed by the drm device's major:minor.
Largest (high water mark) GEM buffer allocated in bytes.
Change-Id: I79e56222151a3d33a76a61ba0097fe93ebb3449f
Signed-off-by: Kenny Ho
---
drm.memory.peak.stats
A read-only nested-keyed file which exists on all cgroups.
Each entry is keyed by the drm device's major:minor. The
following nested keys are defined.
== ==
system Pea
The drm resource being measured is the TTM (Translation Table Manager)
buffers. TTM manages different types of memory that a GPU might access.
These memory types include dedicated Video RAM (VRAM) and host/system
memory accessible through IOMMU (GART/GTT). TTM is currently used by
multiple drm dr
The bandwidth is measured by keeping track of the amount of bytes moved
by ttm within a time period. We defined two type of bandwidth: burst
and average. Average bandwidth is calculated by dividing the total
amount of bytes moved within a cgroup by the lifetime of the cgroup.
Burst bandwidth is s
drm.lgpu
A read-write nested-keyed file which exists on all cgroups.
Each entry is keyed by the DRM device's major:minor.
lgpu stands for logical GPU, it is an abstraction used to
subdivide a physical DRM device for the purpose of resource
management.
With the increased importance of machine learning, data science and
other cloud-based applications, GPUs are already in production use in
data centers today. Existing GPU resource management is very coarse
grain, however, as sysadmins are only able to distribute workload on a
per-GPU basis. An al
The drm resource being limited here is the GEM buffer objects. User
applications allocate and free these buffers. In addition, a process
can allocate a buffer and share it with another process. The consumer
of a shared buffer can also outlive the allocator of the buffer.
For the purpose of cgro
The drm resource being limited is the TTM (Translation Table Manager)
buffers. TTM manages different types of memory that a GPU might access.
These memory types include dedicated Video RAM (VRAM) and host/system
memory accessible through IOMMU (GART/GTT). TTM is currently used by
multiple drm dri
drm.buffer.peak.default
A read-only flat-keyed file which exists on the root cgroup.
Each entry is keyed by the drm device's major:minor.
Default limits on the largest GEM buffer allocation in bytes.
drm.buffer.peak.max
A read-write flat-keyed file which exists on
Since commit 83f35bc3a852 ("drm/bridge: adv7511: Attach to DSI
host at probe time") landed in -next the HiKey board would fail
to boot, looping:
adv7511 2-0039: failed to find dsi host
messages over and over. Andrzej Hajda suggested this is due to a
circular dependency issue, and that the adv75
drmcg initialization involves allocating a per cgroup, per device data
structure and setting the defaults. There are two entry points for
drmcg init:
1) When struct drmcg is created via css_alloc, initialization is done
for each device
2) When DRM devices are created after drmcgs are created
a
To allow other subsystems to iterate through all stored DRM minors and
act upon them.
Also exposes drm_minor_acquire and drm_minor_release for other subsystem
to handle drm_minor. DRM cgroup controller is the initial consumer of
this new features.
Change-Id: I7c4b67ce6b31f06d1037b03435386ff5b814
This is a follow up to the RFC I made previously to introduce a cgroup
controller for the GPU/DRM subsystem [v1,v2,v3]. The goal is to be able to
provide resource management to GPU resources using things like container.
With this RFC v4, I am hoping to have some consensus on a merge plan. I be
The drm resource being measured here is the GEM buffer objects. User
applications allocate and free these buffers. In addition, a process
can allocate a buffer and share it with another process. The consumer
of a shared buffer can also outlive the allocator of the buffer.
For the purpose of cgr
drm.buffer.count.stats
A read-only flat-keyed file which exists on all cgroups. Each
entry is keyed by the drm device's major:minor.
Total number of GEM buffer allocated.
Change-Id: Id3e1809d5fee8562e47a7d2b961688956d844ec6
Signed-off-by: Kenny Ho
---
Documentation/admi
In the designware databook, the sequence of enabling audio clock and
setting format is not clearly specified.
Currently, audio clock is enabled in the end of hw_param ops after
setting format.
On some monitors, there is a possibility that audio does not come out.
Fix this by enabling audio clock i
On 2019-08-28 at 23:23:42 +0530, Winkler, Tomas wrote:
> > FW
> >
> > 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.
> >
> > v2:
> > Copyr
Applied. Thanks!
Alex
On Wed, Aug 28, 2019 at 8:52 PM Colin King wrote:
>
> From: Colin Ian King
>
> There is a spelling mistake in a DRM_DEBUG_DRIVER debug message.
> Fix it.
>
> Signed-off-by: Colin Ian King
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_ras_eeprom.c | 2 +-
> 1 file changed, 1
https://bugzilla.kernel.org/show_bug.cgi?id=204725
Alex Deucher (alexdeuc...@gmail.com) changed:
What|Removed |Added
CC||alexdeuc...@gmail.c
Hi Dave, Daniel,
A few fixes for 5.3. Nothing too major.
The following changes since commit 7837951a12fdaf88d2c51ff0757980c00072790c:
drm/mediatek: include dma-mapping header (2019-08-24 15:09:20 +1000)
are available in the Git repository at:
git://people.freedesktop.org/~agd5f/linux tags
From: Colin Ian King
There is a spelling mistake in a DRM_DEBUG_DRIVER debug message.
Fix it.
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ras_eeprom.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras_eeprom.c
b/d
From: Sean Paul
It seems that on certain MST hubs, namely the CableMatters USB-C 2x DP
hub, using the DP_PAYLOAD_ALLOCATE_SET and DP_PAYLOAD_TABLE_UPDATE_STATUS
register ranges to clear any pre-existing payload allocations on the hub isn't
always enough to reset things if the source device has be
On Fri, Aug 23, 2019 at 2:55 AM Gerd Hoffmann wrote:
>
> ttm increasingly gets into the way while hacking on virtio-gpu memory
> management. It also overkill for what virtio-gpu needs. Lets get rid
> of it.
>
> v8:
> - rebase to latest drm-misc-next, adapt to changes.
Other than two (minor) com
https://bugzilla.kernel.org/show_bug.cgi?id=204725
--- Comment #4 from Dmitri Seletski (drj...@gmail.com) ---
Comment on attachment 284671
--> https://bugzilla.kernel.org/attachment.cgi?id=284671
black screen kernel 5.30
its dmesg output
--
You are receiving this mail because:
You are watchin
https://bugzilla.kernel.org/show_bug.cgi?id=204725
--- Comment #3 from Dmitri Seletski (drj...@gmail.com) ---
Created attachment 284675
--> https://bugzilla.kernel.org/attachment.cgi?id=284675&action=edit
lspci -vv
--
You are receiving this mail because:
You are watching the assignee of the bu
https://bugzilla.kernel.org/show_bug.cgi?id=204725
--- Comment #2 from Dmitri Seletski (drj...@gmail.com) ---
i can connect to machine over ssh, it's how i know machine is responsive.
attempts to startx xorg fail with changing black screen to black screen.
after which keyboard becomes unresponsive
https://bugzilla.kernel.org/show_bug.cgi?id=204725
--- Comment #1 from Dmitri Seletski (drj...@gmail.com) ---
Created attachment 284673
--> https://bugzilla.kernel.org/attachment.cgi?id=284673&action=edit
.config file
--
You are receiving this mail because:
You are watching the assignee of the
https://bugzilla.kernel.org/show_bug.cgi?id=204725
Bug ID: 204725
Summary: black screen
Product: Drivers
Version: 2.5
Kernel Version: linux-5.3-rc6, linux-5.3-rc6 latest,
Hardware: x86-64
OS: Linux
Tree: Mainl
Convert the Arm Utgard GPU binding to DT schema format.
'allwinner,sun8i-a23-mali' compatible was not documented, so add it.
The 'clocks' property is now required. This simplifies the schema as
effectively all the users require 'clocks' already and the upstream
driver requires clocks.
Reviewed-b
Convert the Arm Bifrost GPU binding to DT schema format.
The 'clocks' property is now required. This simplifies the schema as
effectively all the users require 'clocks' already and the upstream
driver requires at least one clock.
Reviewed-by: Neil Armstrong
Acked-by: Maxime Ripard
Acked-by: Hei
This series converts the various Arm Mali GPU bindings to use the DT
schema format.
The Midgard and Bifrost bindings generate warnings on 'interrupt-names'
because there's all different ordering. The Utgard binding generates
warnings on Rockchip platforms because 'clock-names' order is reversed.
Convert the Arm Midgard GPU binding to DT schema format.
The 'clocks' property is now required. This simplifies the schema as
effectively all the users require 'clocks' already and the upstream
driver requires at least one clock.
Reviewed-by: Neil Armstrong
Acked-by: Maxime Ripard
Acked-by: Hei
On Fri, Aug 23, 2019 at 2:55 AM Gerd Hoffmann wrote:
>
> Some helper functions to manage an array of gem objects.
>
> v6:
> - add ticket to struct virtio_gpu_object_array.
> - add virtio_gpu_array_{lock,unlock}_resv helpers.
> - add virtio_gpu_array_add_fence helper.
> v5: some small optimizati
On Fri, Aug 23, 2019 at 2:55 AM Gerd Hoffmann wrote:
>
> Use drm_gem_reservation_object_wait() in virtio_gpu_wait_ioctl().
> This also makes the ioctl run lockless.
>
> v5: handle lookup failure.
> v2: use reservation_object_test_signaled_rcu for VIRTGPU_WAIT_NOWAIT.
>
> Signed-off-by: Gerd Hoffma
On Wed, Aug 28, 2019 at 11:28 AM Jean Delvare wrote:
>
> Comparing adev->family with CHIP constants is not correct.
> adev->family can only be compared with AMDGPU_FAMILY constants and
> adev->asic_type is the struct member to compare with CHIP constants.
> They are separate identification spaces.
On Wed, 28 Aug 2019 11:30:43 -0400
Sean Paul wrote:
> On Wed, Aug 28, 2019 at 11:25 AM Boris Brezillon
> wrote:
> >
> > On Wed, 28 Aug 2019 11:22:57 -0400
> > Sean Paul wrote:
> >
> > > On Mon, Aug 26, 2019 at 05:26:36PM +0200, Boris Brezillon wrote:
> > > > This is part of our attempt to m
On Mon, 26 Aug 2019 17:26:29 +0200
Boris Brezillon wrote:
> 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 incom
On Wed, Aug 28, 2019 at 4:32 AM Jean Delvare wrote:
>
> The driver does not support these sensors yet and there is no point in
> creating sysfs attributes which will always return an error.
>
> Signed-off-by: Jean Delvare
> Cc: Alex Deucher
> Cc: "Christian König"
> Cc: "David (ChunMing) Zhou"
On 08/27, Jani Nikula wrote:
> On Mon, 26 Aug 2019, "Siqueira, Rodrigo" wrote:
> > DP 1.4a specification defines Link Training Tunable PHY Repeater (LTTPR)
> > which is required to add support for systems with Thunderbolt or other
> > repeater devices.
> >
> > Changes since V1:
> > - Adjusts regis
DP 1.4a specification defines Link Training Tunable PHY Repeater (LTTPR)
which is required to add support for systems with Thunderbolt or other
repeater devices.
Changes since V2:
- Drop the kernel-doc comment
- Reorder LTTPR according to register offset
Changes since V1:
- Adjusts registers names
https://bugzilla.kernel.org/show_bug.cgi?id=204683
--- Comment #5 from Matthias Heinz (m...@familie-heinz.name) ---
Created attachment 284667
--> https://bugzilla.kernel.org/attachment.cgi?id=284667&action=edit
Kernel trace
--
You are receiving this mail because:
You are watching the assignee
https://bugzilla.kernel.org/show_bug.cgi?id=204683
--- Comment #4 from Matthias Heinz (m...@familie-heinz.name) ---
I still have 11 steps to go (as I mentioned it's a pretty lengthy task), but I
got some more debug output, before the system stopped working. Please see the
attached file, maybe it h
https://bugs.freedesktop.org/show_bug.cgi?id=111077
--- Comment #21 from Marek Olšák ---
How do I reproduce it?
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https:/
Hi Dave and Danvet,
drm-misc-fixes for v5.3, enjoy!
drm-misc-fixes-2019-08-28:
drm-misc-fixes for v5.3 (rc7?):
- Make qxl reservel the vga ports using vgaargb to prevent switching to vga
compatibility mode.
- Fix omap port lookup for SDI output
- Use virtio_max_dma_size to fix an issue with swio
On Wed, Aug 28, 2019 at 8:43 PM Jason Gunthorpe wrote:
> On Wed, Aug 28, 2019 at 08:33:13PM +0200, Daniel Vetter wrote:
> > On Wed, Aug 28, 2019 at 12:50 AM Jason Gunthorpe wrote:
> > >
> > > > diff --git a/include/linux/kernel.h b/include/linux/kernel.h
> > > > index 4fa360a13c1e..82f84cfe372f 1
On Wed, Aug 28, 2019 at 2:51 PM Randy Dunlap wrote:
>
> On 8/27/19 8:40 PM, a...@linux-foundation.org wrote:
> > The mm-of-the-moment snapshot 2019-08-27-20-39 has been uploaded to
> >
> >http://www.ozlabs.org/~akpm/mmotm/
> >
> > mmotm-readme.txt says
> >
> > README for mm-of-the-moment:
> >
Now I'm reading this other patch about DG1 ' drm/i915/dg1: Initialize DDI ports
for DG1' , is this condition still correct here?
Is the condition 'INTEL_GEN(dev_priv) >= 12' sufficient ?
>
> >From Gen12 onwards, HDCP HW block is implemented within transcoders.
> Till Gen11 HDCP HW block was part
On Wed, Aug 28, 2019 at 08:33:13PM +0200, Daniel Vetter wrote:
> On Wed, Aug 28, 2019 at 12:50 AM Jason Gunthorpe wrote:
> >
> > > diff --git a/include/linux/kernel.h b/include/linux/kernel.h
> > > index 4fa360a13c1e..82f84cfe372f 100644
> > > +++ b/include/linux/kernel.h
> > > @@ -217,7 +217,9 @@
Dear All,
this series adds support for dual-LVDS panel IDK-2121WR
from Advantech:
https://buy.advantech.eu/Displays/Embedded-LCD-Kits-High-Brightness/model-IDK-2121WR-K2FHA2E.htm
V3 approaches the problem in a completely different way, we now
have two new properties to mark the ports in the DT as
Helper to provide bus timing information.
Signed-off-by: Fabrizio Castro
---
v2->v3:
* new patch
---
drivers/gpu/drm/Makefile | 3 +-
drivers/gpu/drm/drm_bus_timings.c | 97 +++
include/drm/drm_bus_timings.h | 21 +
3 files changed, 120
The driver doesn't support dual-link LVDS displays, and the way
it identifies bridges won't allow for dual-LVDS displays to be
connected. Also, it's not possible to swap even and odd pixels
around in case the wiring isn't taking advantage of the default
hardware configuration. Further more, the "mo
No need to report the input bus mode through bridge timings
anymore, that's now done through the DT, as specified by the
dt-bindings.
Signed-off-by: Fabrizio Castro
---
v2->v3:
* new patch
---
drivers/gpu/drm/bridge/thc63lvd1024.c | 9 -
include/drm/drm_bridge.h | 8 ---
Add binding for the idk-2121wr LVDS panel from Advantech.
Some panel-specific documentation can be found here:
https://buy.advantech.eu/Displays/Embedded-LCD-Kits-High-Brightness/model-IDK-2121WR-K2FHA2E.htm
Signed-off-by: Fabrizio Castro
---
v2->v3:
* new patch
---
.../display/panel/advantech
Dual-LVDS connections need markers in the DT, this patch adds
some common documentation to be referenced by both panels and
bridges.
Signed-off-by: Fabrizio Castro
---
v2->v3:
* new patch
---
.../bindings/display/bus-timings/lvds.yaml | 38 ++
1 file changed, 38 inse
https://bugs.freedesktop.org/show_bug.cgi?id=111077
Matt Turner changed:
What|Removed |Added
CC||mar...@gmail.com
Keywords|
On Wed, Aug 28, 2019 at 12:50 AM Jason Gunthorpe wrote:
>
> > diff --git a/include/linux/kernel.h b/include/linux/kernel.h
> > index 4fa360a13c1e..82f84cfe372f 100644
> > +++ b/include/linux/kernel.h
> > @@ -217,7 +217,9 @@ extern void __cant_sleep(const char *file, int line,
> > int preempt_offs
> FW
>
> 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.
>
> v2:
> Copyright years are bumped [Tomas]
>
> Signed-off-by: Ramalingam C
> Acked-by: Ja
On Tue, Aug 27, 2019 at 02:10:09PM -0700, Rob Clark wrote:
> From: Rob Clark
>
> The extra line-break in traces was annoying me.
>
> Signed-off-by: Rob Clark
Reviewed-by: Sean Paul
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>
On Wed, Aug 28, 2019 at 03:58:12PM +, james qian wang (Arm Technology
China) wrote:
> On Wed, Aug 28, 2019 at 03:00:19PM +, Ayan Halder wrote:
> > From: Ayan Halder
> >
> > The de-init routine should be doing the following in order:-
> > 1. Unregister the drm device
> > 2. Shut down the
On 2019-08-28 at 22:12:10 +0530, Ramalingam C wrote:
> Enabling the HDCP1.4 and 2.2 on TGL by supporting the HW block movement
> from DDI into transcoder.
>
> v12:
> r-b and ack are collected.
> few review comments are addressed.
Tomas,
Thanks for reviewing the patches and providing the Ack/
For gen12+ platform we need to pass the transcoder info
as part of the port info into ME FW.
This change fills the payload for ME FW from hdcp_port_data.
v2:
Doc is enhanced for physical_port and attached_transcoder [Tomas]
Signed-off-by: Ramalingam C
Acked-by: Jani Nikula
Reviewed-by: Shash
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]
v3:
comment is added for fw_ddi init for gen12+ [Shashank]
only hdcp capable transcoder is translated into fw_t
>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 hdcp_port_dat
Enabling the HDCP1.4 and 2.2 on TGL by supporting the HW block movement
from DDI into transcoder.
v12:
r-b and ack are collected.
few review comments are addressed.
Ramalingam C (6):
drm/i915: mei_hdcp: I915 sends ddi index as per ME FW
drm: Move port definition back to i915 header
drm:
On Wed, Aug 28, 2019 at 10:29:32AM -0400, Sean Paul wrote:
> On Tue, Aug 27, 2019 at 08:31:29PM -0400, Lyude Paul wrote:
> > Hi! So, I don't have access to the DP 1.3 spec or anything later than 1.3.
>
> 1.3 was just what I was looking at, I checked 1.2 and it looks the same (aside
> from a typo f
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.
v2:
Copyright years are bumped [Tomas]
Signed-off-by: Ramalingam C
Acked-by: Jani Nikula
Reviewed-by: Shas
I915 needs to send the index of the transcoder as per ME FW.
To support this, define enum mei_fw_tc and add as a member into
the struct hdcp_port_data.
v2:
Typo in commit msg is fixed [Shashank]
v3:
kdoc is added for mei_fw_tc [Tomas]
s/MEI_TC_x/MEI_TRANSCODER_x
Signed-off-by: Ramalingam C
We dont need the definition of the enum port outside I915, anymore.
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.
v4:
commit msg is rephrased.
v5:
copyright year is updated [Tomas]
Signed-off-
Hi Geert,
On Wed, Aug 28, 2019 at 06:31:19PM +0200, Linus Walleij wrote:
> On Wed, Aug 28, 2019 at 10:36 AM Geert Uytterhoeven
> wrote:
>
> > CC the pour soul with the ecovec board.
>
I'm sorry, Eco what ? :)
> With great power comes great responsibility ;)
>
Yeah, that's -exactly- a 'great pow
On Wed, Aug 28, 2019 at 10:36 AM Geert Uytterhoeven
wrote:
> CC the pour soul with the ecovec board.
With great power comes great responsibility ;)
Yours,
Linus Walleij
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedeskt
On Wed, Aug 28, 2019 at 03:00:19PM +, Ayan Halder wrote:
> From: Ayan Halder
>
> The de-init routine should be doing the following in order:-
> 1. Unregister the drm device
> 2. Shut down the crtcs - failing to do this might cause a connector leakage
> See the 'commit 109c4d18e574 ("drm/arm/m
On Wed, Aug 28, 2019 at 11:11:41AM -0400, Ilia Mirkin wrote:
> On Wed, Aug 28, 2019 at 10:54 AM Ville Syrjälä
> wrote:
> >
> > On Wed, Aug 28, 2019 at 10:47:08AM -0400, Ilia Mirkin wrote:
> > > On Wed, Aug 28, 2019 at 10:38 AM Ville Syrjälä
> > > wrote:
> > > >
> > > > On Mon, Aug 26, 2019 at 09:
https://bugs.freedesktop.org/show_bug.cgi?id=111481
--- Comment #2 from Mathieu Belanger ---
I confirm that I have this bug or a very similar one.
It, for some reason, happens most when i'm using my IDE (Intellij based).
It will append the most when I type code and the crash occur when the IDE i
On Wed, Aug 28, 2019 at 11:25 AM Boris Brezillon
wrote:
>
> On Wed, 28 Aug 2019 11:22:57 -0400
> Sean Paul wrote:
>
> > On Mon, Aug 26, 2019 at 05:26:36PM +0200, Boris Brezillon wrote:
> > > This is part of our attempt to make the bridge chain a double-linked
> > > list based on the generic list
On Wed, 28 Aug 2019 11:22:57 -0400
Sean Paul wrote:
> On Mon, Aug 26, 2019 at 05:26:36PM +0200, Boris Brezillon wrote:
> > This is part of our attempt to make the bridge chain a double-linked
> > list based on the generic list helpers. In order to do that, we must
> > patch all drivers manipulati
On Mon, Aug 26, 2019 at 05:26:36PM +0200, Boris Brezillon wrote:
> This is part of our attempt to make the bridge chain a double-linked
> list based on the generic list helpers. In order to do that, we must
> patch all drivers manipulating the encoder->bridge field directly.
>
> Signed-off-by: Bor
On 28/08/2019 17:12, Kevin Hilman wrote:
> Neil Armstrong writes:
>
>> On 27/08/2019 21:17, Kevin Hilman wrote:
>>> Neil Armstrong writes:
>>>
This serie adds the resume/suspend hooks in the Amlogic Meson VPU main
driver
and the DW-HDMI Glue driver to correctly save state and dis
Neil Armstrong writes:
> On 27/08/2019 21:17, Kevin Hilman wrote:
>> Neil Armstrong writes:
>>
>>> This serie adds the resume/suspend hooks in the Amlogic Meson VPU main
>>> driver
>>> and the DW-HDMI Glue driver to correctly save state and disable HW before
>>> suspend, and succesfully re-ini
On Wed, Aug 28, 2019 at 10:54 AM Ville Syrjälä
wrote:
>
> On Wed, Aug 28, 2019 at 10:47:08AM -0400, Ilia Mirkin wrote:
> > On Wed, Aug 28, 2019 at 10:38 AM Ville Syrjälä
> > wrote:
> > >
> > > On Mon, Aug 26, 2019 at 09:36:50AM -0400, Ilia Mirkin wrote:
> > > > This should probably be fixed to ac
On Wed, Aug 14, 2019 at 12:44:59PM +0200, Dariusz Marcinkiewicz wrote:
> Pass the connector info to the CEC adapter. This makes it possible
> to associate the CEC adapter with the corresponding drm connector.
>
> Signed-off-by: Dariusz Marcinkiewicz
> Signed-off-by: Hans Verkuil
> Tested-by: Han
From: Ayan Halder
The de-init routine should be doing the following in order:-
1. Unregister the drm device
2. Shut down the crtcs - failing to do this might cause a connector leakage
See the 'commit 109c4d18e574 ("drm/arm/malidp: Ensure that the crtcs are
shutdown before removing any encoder/con
On Wed, Aug 28, 2019 at 10:47:08AM -0400, Ilia Mirkin wrote:
> On Wed, Aug 28, 2019 at 10:38 AM Ville Syrjälä
> wrote:
> >
> > On Mon, Aug 26, 2019 at 09:36:50AM -0400, Ilia Mirkin wrote:
> > > This should probably be fixed to account for the scenario where an
> > > HDMI connector is plugged direc
On Wed, Aug 28, 2019 at 10:38 AM Ville Syrjälä
wrote:
>
> On Mon, Aug 26, 2019 at 09:36:50AM -0400, Ilia Mirkin wrote:
> > 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 wi
On Mon, Aug 26, 2019 at 09:36:50AM -0400, Ilia Mirkin wrote:
> 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 o
Hi Guido,
I tested this on my setup and it works. My DSI panel is a little bit
different and it doesn't work with this as-is, but I added some
improvements on top of this, in order to be able to setup the clocks.
The changes I made can arrive on top of this as improvements, of
course, since it wil
On Tue, Aug 27, 2019 at 08:31:29PM -0400, Lyude Paul wrote:
> Hi! So, I don't have access to the DP 1.3 spec or anything later than 1.3.
1.3 was just what I was looking at, I checked 1.2 and it looks the same (aside
from a typo fix).
> However, I'm fairly sure this is very much againt spec since
On Mon, Aug 26, 2019 at 04:22:13PM +0300, Oleg Vasilev wrote:
> 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 Vasi
On Mon, Aug 26, 2019 at 04:22:12PM +0300, Oleg Vasilev wrote:
> 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 inf
https://bugs.freedesktop.org/show_bug.cgi?id=111482
--- Comment #5 from Robert ---
One additional observation I made yesterday: If I stop sddm/KDE via "systemctl
stop sddm" the frequency has changed after I'm back in console:
"""
cat /sys/class/drm/card0/device/pp_dpm_mclk
0: 100Mhz
1: 500Mhz *
Hi Mihail:
Looks good to me.
Reviewed-by: James Qian Wang (Arm Technology China)
James.
On Wed, Aug 28, 2019 at 11:03:49AM +, Mihail Atanassov wrote:
> Expose node with the name 'aclk_hz'
>
> Signed-off-by: Mihail Atanassov
> ---
> drivers/gpu/drm/arm/display/komeda/komeda_dev.c | 10 ++
Looks good to me,
From display side, Please feel free to use Reviewed-by: Shashank Sharma
Regards
Shashank
> -Original Message-
> From: Winkler, Tomas
> Sent: Wednesday, August 28, 2019 1:49 PM
> To: C, Ramalingam
> Cc: intel-gfx ; dri-devel de...@lists.freedesktop.org>; Sharma, Shasha
Looks good to me,
From display side, Please feel free to use Reviewed-by: Shashank Sharma
> -Original Message-
> From: C, Ramalingam
> Sent: Wednesday, August 28, 2019 2:28 PM
> To: Winkler, Tomas
> Cc: intel-gfx ; dri-devel de...@lists.freedesktop.org>; Sharma, Shashank ;
> Daniel Vet
https://bugs.freedesktop.org/show_bug.cgi?id=111494
Diego Viola changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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 1024x768-60 mode.
Fixes: 202b9808f8ed ("drm/meson: Add G12A Video Clock setup")
Signed-off-by: Neil Armstrong
---
Fixed typo in comm
On 26/08/2019 23:33, Rob Herring wrote:
> It's not entirely clear if this is required, but add a flush of GPU caches
> and TLBs before we change an address space to new page tables.
>
> Fixes: 7282f7645d06 ("drm/panfrost: Implement per FD address spaces")
> Cc: Tomeu Vizoso
> Cc: Steven Price
>
On 28/08/2019 13:35, Rob Herring wrote:
> On Wed, Aug 28, 2019 at 5:55 AM Steven Price wrote:
>>
>> On 26/08/2019 23:33, Rob Herring wrote:
>>> Currently, page tables are freed without disabling the address space first.
>>> This probably is fine as we'll switch to new page tables when the address
1 - 100 of 184 matches
Mail list logo
