On Monday, April 26, 2021 2:38:53 AM PDT Matthew Auld wrote:
> Add an entry for the new uAPI needed for DG1. Also add the overall
> upstream plan, including some notes for the TTM conversion.
>
> v2(Daniel):
> - include the overall upstreaming plan
> - add a note for mmap, there are
We found another bug after the fix of
https://gitlab.freedesktop.org/drm/intel/-/issues/2538. The external
monitor is also connected via WD19's HDMI/DisplayPort just as #2538.
However, the display monitor can only be detected and show output at
the very first time we power on the WD19 dock. If we
On Wednesday, April 28, 2021 9:56:25 AM PDT Jason Ekstrand wrote:
> On Wed, Apr 28, 2021 at 11:41 AM Matthew Auld wrote:
[snip]
> > Slightly orthogonal: what does Mesa do here for snooped vs LLC
> > platforms? Does it make such a distinction? Just curious.
>
> In Vulkan on non-LLC platforms, we
On Monday, April 26, 2021 2:38:58 AM PDT Matthew Auld wrote:
> Add new extension to support setting an immutable-priority-list of
> potential placements, at creation time.
>
> If we use the normal gem_create or gem_create_ext without the
> extensions/placements then we still get the old behaviour
On Monday, April 26, 2021 2:38:53 AM PDT Matthew Auld wrote:
> +Existing uAPI issues
> +
> +Some potential issues we still need to resolve.
> +
> +I915 MMAP
> +-
> +In i915 there are multiple ways to MMAP GEM object, including mapping the
> same
> +object using
Hi,
* Laurent Pinchart [210428 14:10]:
> Based on my experience on the camera and display side with devices that
> are made of multiple components, suspend and resume are best handled in
> a controlled way by the top-level driver. Otherwise you end up having
> different components suspending and
drm_dev_register() sets connector->registration_state to
DRM_CONNECTOR_REGISTERED and dev->registered to true. If
drm_connector_set_panel_orientation() is first called after
drm_dev_register(), it will fail several checks and results in following
warning.
Add a function to create panel
krane, kakadu, and kodama boards have a default panel rotation.
Signed-off-by: Hsin-Yi Wang
---
arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
b/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
Init panel orientation property after connector is initialized. Let the
panel driver decides the orientation value later.
Signed-off-by: Hsin-Yi Wang
---
drivers/gpu/drm/mediatek/mtk_dsi.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
There are two declarations of struct dc_state here.
The later one is closer to its user. Remove the former duplicate.
Signed-off-by: Wan Jiabing
---
drivers/gpu/drm/amd/display/dc/dc.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dc.h
In commit 482812d56698e ("drm/amd/display: Set max TTU on
DPG enable"), "hubp.h" was added which caused the duplicate include.
To be on the safe side, remove the later duplicate include.
Signed-off-by: Wan Jiabing
---
drivers/gpu/drm/amd/display/dc/core/dc.c | 1 -
1 file changed, 1 deletion(-)
This maybe used lockdep through the fs_reclaim annotations.
Signed-off-by: Bernard Zhao
---
drivers/gpu/drm/i915/i915_sw_fence.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_sw_fence.c
b/drivers/gpu/drm/i915/i915_sw_fence.c
index
Hi Hsin-Yi,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on drm-tip/drm-tip drm-exynos/exynos-drm-next
tegra-drm/drm/tegra/for-next linus/master v5.12 next-20210428]
[cannot apply to drm/drm-next]
[If your patch
This maybe uses lockdep through the fs_reclaim annotations.
Signed-off-by: Bernard Zhao
---
drivers/gpu/drm/i915/i915_request.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index
On Wed, Apr 28, 2021 at 8:14 PM Mikita Lipski wrote:
>
> Hi Linus,
>
> The patch to fix the warning is here
> (https://www.spinics.net/lists/amd-gfx/msg61614.html)
>
> I guess it just didn't propagate all the way to the release.
> Can it still be pulled into 5.13-rc1 release?
I'll include it in
Perf measurements rely on CPU and engine timestamps to correlate
events of interest across these time domains. Current mechanisms get
these timestamps separately and the calculated delta between these
timestamps lack enough accuracy.
To improve the accuracy of these time measurements to within a
This is just a refresh of the earlier patch along with cover letter for the IGT
testing. The query provides the engine cs cycles counter.
v2: Use GRAPHICS_VER() instead of IG_GEN()
v3: Add R-b to the patch
v4: Split cpu timestamp array into timestamp and delta for cleaner API
Signed-off-by:
Hi Linus,
The patch to fix the warning is here
(https://www.spinics.net/lists/amd-gfx/msg61614.html)
I guess it just didn't propagate all the way to the release.
Can it still be pulled into 5.13-rc1 release?
From: Mikita Lipski
[why]
Previous statement would always evaluate to true
making
[why]
DP 1.4a spec madates that if DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT is
set, Extended Base Receiver Capability DPCD space must be used. Without
doing that, the three DPCD values that differ will be wrong, leading to
incorrect or limited functionality. MST link rate, for example, could
have a
Change history:
v8:
- Chaged link lanes and rate parameters to u8
v7:
- Fixed formatting
- Fixed 'unused variable' compile warning
- Fixed comment format
v6:
- Submited from (hopefully) the correct repo to fix build error
v5:
- Fixed min_t() macro arguments
v4:
- Fixed drm/radeon/
[why]
DP 1.4a spec madates that if DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT is
set, Extended Base Receiver Capability DPCD space must be used. Without
doing that, the three DPCD values that differ will be wrong, leading to
incorrect or limited functionality. MST link rate, for example, could
have a
Change history:
v7:
- Fixed formatting in drm_dp_mst_topology.c
- Fixed 'unused variable' compile warning
- Fixed comment format
v6:
- Submited from (hopefully) the correct repo to fix build error
v5:
- Fixed min_t() macro arguments
v4:
- Fixed drm/radeon/ lane count and rate
v3:
-
Hi,
This series adds support for another General Electric patient
monitor series (similar to existing Bx50v3), which is based on
i.MX6DL using Congatec's QMX6 module.
The module uses an I2C RTC to provide the i.MX6 32768 Hz clock,
so it's important to keep it enabled. Not doing so results in
This adds device tree files for the General Electric Healthcare
(GEHC) B1x5v2 series. All models make use of Congatec's QMX6 module,
which is described in its own device tree include, so that it can
also be used by other boards.
Signed-off-by: Sebastian Reichel
---
arch/arm/boot/dts/Makefile
Congatec's QMX6 system on module (SoM) uses a m41t62 as RTC. The
modules SQW clock output defaults to 32768 Hz. This behaviour is
used to provide the i.MX6 CKIL clock. Once the RTC driver is probed,
the clock is disabled and all i.MX6 functionality depending on
the 32 KHz clock has undefined
Some standard resolutions like 1366x768 do not work properly with
i.MX6 SoCs, since the horizontal resolution needs to be aligned
to 8 pixels (so 1360x768 or 1368x768 would work).
This patch allocates framebuffers allocated to 8 pixels. The extra
time required to send the extra pixels are removed
Document binding for congatec.
Signed-off-by: Sebastian Reichel
---
Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml
b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index
Document the compatible for GE B1x5pv2 boards.
Signed-off-by: Sebastian Reichel
---
Documentation/devicetree/bindings/arm/fsl.yaml | 11 +++
1 file changed, 11 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml
b/Documentation/devicetree/bindings/arm/fsl.yaml
On Tue, Apr 27, 2021 at 8:32 PM Dave Airlie wrote:
>
> This is the main drm pull request for 5.13. The usual lots of work all
> over the place. [...]
>
> Mikita Lipski:
> drm/amd/display: Add MST capability to trigger_hotplug interface
Hmm. I've already merged this, but my clang build
Hi,
On 4/28/21 11:52 PM, Hans de Goede wrote:
> Hi All,
>
> Here is a new attempt to make DP over Type-C work on devices where the
> Type-C controller does not drive the HPD pin on the GPU, but instead
> we need to forward HPD events from the Type-C controller to the DRM driver.
>
> For anyone
The Type-C connector on these devices is connected to DP-2 not DP-1,
so the reference must be to the DD04 child-node of the GPU, rather
then the DD02 child-node.
Signed-off-by: Hans de Goede
---
drivers/platform/x86/intel_cht_int33fe_typec.c | 4 ++--
1 file changed, 2 insertions(+), 2
Use the new drm_connector_find_by_fwnode() and
drm_connector_oob_hotplug_event() functions to let drm/kms drivers
know about DisplayPort over Type-C hotplug events.
Signed-off-by: Hans de Goede
---
drivers/usb/typec/altmodes/displayport.c | 45 +++-
1 file changed, 44
From: Heikki Krogerus
On Intel platforms we know that the ACPI connector device
node order will follow the order the driver (i915) decides.
The decision is made using the custom Intel ACPI OpRegion
(intel_opregion.c), though the driver does not actually know
that the values it sends to ACPI
On some Cherry Trail devices, DisplayPort over Type-C is supported through
a USB-PD microcontroller (e.g. a fusb302) + a mux to switch the superspeed
datalines between USB-3 and DP (e.g. a pi3usb30532). The kernel in this
case does the PD/alt-mode negotiation itself, rather then everything being
Make dp_altmode_notify() handle the dp->data.conf == 0 case too,
rather then having separate code-paths for this in various places
which call it.
Signed-off-by: Hans de Goede
---
drivers/usb/typec/altmodes/displayport.c | 35 +---
1 file changed, 13 insertions(+), 22
Add a new drm_connector_oob_hotplug_event() function and
oob_hotplug_event drm_connector_funcs member.
On some hardware a hotplug event notification may come from outside the
display driver / device. An example of this is some USB Type-C setups
where the hardware muxes the DisplayPort data and
Add a function which allows other subsystems to find a connector
based on a fwnode.
This will be used by the USB-Type-C code to be able to find the DP
connector to which to send hotplug events received by a Type-C port in
DP-alternate-mode.
Note this function is defined in
Add a fwnode pointer to struct drm_connector and register an acpi_bus_type
for the connectors with the ACPI subsystem (when CONFIG_ACPI is enabled).
The adding of the fwnode pointer allows drivers to associate a fwnode
that represents a connector with that connector.
When the new fwnode pointer
Userspace could hold open a reference to the connector->kdev device,
through e.g. holding a sysfs-atrtribute open after
drm_sysfs_connector_remove() has been called. In this case the connector
could be free-ed while the connector->kdev device's drvdata is still
pointing to it.
Give drm_connector
Hi All,
Here is a new attempt to make DP over Type-C work on devices where the
Type-C controller does not drive the HPD pin on the GPU, but instead
we need to forward HPD events from the Type-C controller to the DRM driver.
For anyone interested here are the old (2019!) patches for this:
On 4/27/21 6:00 AM, Daniel Vetter wrote:
> On Tue, Apr 27, 2021 at 10:40:24AM +0300, Pekka Paalanen wrote:
>> On Mon, 26 Apr 2021 14:30:53 -0300
>> Leandro Ribeiro wrote:
>>
>>> On 4/26/21 7:58 AM, Simon Ser wrote:
On Monday, April 26th, 2021 at 9:36 AM, Pekka Paalanen
wrote:
In this patch we add a section to document what userspace should do to
find out the CRTC index. This is important as there are multiple places
in the documentation that need this, so it's better to just point to
this section and avoid repetition.
Signed-off-by: Leandro Ribeiro
---
Add a small description and document struct fields of
drm_mode_get_plane.
Signed-off-by: Leandro Ribeiro
---
include/uapi/drm/drm_mode.h | 22 ++
1 file changed, 22 insertions(+)
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index
v2: possible_crtcs field is a bitmask, not a pointer. Suggested by
Ville Syrjälä
v3: document how userspace should find out CRTC index. Also,
document that field 'gamma_size' represents the number of
entries in the lookup table. Suggested by Pekka Paalanen
and Daniel Vetter
Leandro Ribeiro
On Tue, Apr 20, 2021 at 5:25 PM Alex Deucher wrote:
>
> On Fri, Apr 16, 2021 at 12:29 PM Mario Kleiner
> wrote:
> >
> > Friendly ping to the AMD people. Nicholas, Harry, Alex, any feedback?
> > Would be great to get this in sooner than later.
> >
>
> No objections from me.
>
I don't have any
On 28/04/2021 23:45, Jason Ekstrand wrote:
On Wed, Apr 28, 2021 at 3:14 PM Lionel Landwerlin
wrote:
On 28/04/2021 22:54, Jason Ekstrand wrote:
On Wed, Apr 28, 2021 at 2:50 PM Lionel Landwerlin
wrote:
On 28/04/2021 22:24, Jason Ekstrand wrote:
On Wed, Apr 28, 2021 at 3:43 AM Jani Nikula
On Wed, Apr 21, 2021 at 12:18 PM Guenter Roeck wrote:
>
> Fix the following build warnings.
>
> drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:
> In function ‘dm_update_mst_vcpi_slots_for_dsc’:
> drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:6242:46:
>
Applied. Thanks!
Alex
On Fri, Apr 23, 2021 at 7:38 AM Fabio M. De Francesco
wrote:
>
> In the function documentation, I removed the excess parameters,
> described the undocumented ones, and fixed the syntax errors.
>
> Signed-off-by: Fabio M. De Francesco
> ---
>
On Fri, Apr 23, 2021 at 4:57 PM Souptick Joarder wrote:
>
> Kernel test robot throws below warning ->
>
> >> drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_debugfs.c:3015:53:
> >> warning: address of 'aconnector->mst_port->mst_mgr' will always
> >> evaluate to 'true'
On Sat, Apr 24, 2021 at 6:19 PM Fabio M. De Francesco
wrote:
>
> Fixed kernel-doc syntax errors in documentation of functions.
>
> Signed-off-by: Fabio M. De Francesco
Applied. Thanks!
Alex
> ---
>
> Changes from v1: Reword both the subject and the log message
>
>
On Mon, Apr 26, 2021 at 3:35 AM Maxime Ripard wrote:
>
> Hi Alex,
>
> On Thu, Apr 22, 2021 at 12:40:10PM -0400, Alex Deucher wrote:
> > On Thu, Apr 22, 2021 at 12:33 PM Maxime Ripard wrote:
> > >
> > > Hi Dave, Daniel,
> > >
> > > Here's this week drm-misc-next-fixes PR, for the next merge
On Mon, Apr 26, 2021 at 6:50 AM Kai-Heng Feng
wrote:
>
> When an amdgpu device fails to init, it makes another VGA device cause
> kernel splat:
> kernel: amdgpu :08:00.0: amdgpu: amdgpu_device_ip_init failed
> kernel: amdgpu :08:00.0: amdgpu: Fatal error during GPU init
> kernel: amdgpu:
+ dri-devel as well.
On Wed, Apr 28, 2021 at 4:44 PM Nikola Cornij wrote:
>
> [why]
> DP 1.4a spec madates that if DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT is
> set, Extended Base Receiver Capability DPCD space must be used. Without
> doing that, the three DPCD values that differ will be wrong,
On Wed, Apr 28, 2021 at 3:14 PM Lionel Landwerlin
wrote:
>
> On 28/04/2021 22:54, Jason Ekstrand wrote:
> > On Wed, Apr 28, 2021 at 2:50 PM Lionel Landwerlin
> > wrote:
> >> On 28/04/2021 22:24, Jason Ekstrand wrote:
> >>
> >> On Wed, Apr 28, 2021 at 3:43 AM Jani Nikula
> >> wrote:
> >>
> >>
On Wed, Apr 28, 2021 at 10:35 AM Daniel Vetter wrote:
>
> On Wed, Apr 28, 2021 at 03:37:49PM +0200, Christian König wrote:
> > Am 28.04.21 um 15:34 schrieb Daniel Vetter:
> > > On Wed, Apr 28, 2021 at 03:11:27PM +0200, Christian König wrote:
> > > > Am 28.04.21 um 14:26 schrieb Daniel Vetter:
> >
On Wed, Apr 28, 2021 at 1:04 PM Hsin-Yi Wang wrote:
>
> Creating the panel orientation property first since we separate the
> property creating and value setting.
This should probably be included in patch 1 so you don't regress i915
in between patches.
Sean
>
> Signed-off-by: Hsin-Yi Wang
>
On 28/04/2021 23:14, Lionel Landwerlin wrote:
On 28/04/2021 22:54, Jason Ekstrand wrote:
On Wed, Apr 28, 2021 at 2:50 PM Lionel Landwerlin
wrote:
On 28/04/2021 22:24, Jason Ekstrand wrote:
On Wed, Apr 28, 2021 at 3:43 AM Jani Nikula
wrote:
On Tue, 27 Apr 2021, Umesh Nerlige Ramappa
On 28/04/2021 22:54, Jason Ekstrand wrote:
On Wed, Apr 28, 2021 at 2:50 PM Lionel Landwerlin
wrote:
On 28/04/2021 22:24, Jason Ekstrand wrote:
On Wed, Apr 28, 2021 at 3:43 AM Jani Nikula wrote:
On Tue, 27 Apr 2021, Umesh Nerlige Ramappa
wrote:
Perf measurements rely on CPU and engine
On Wed, Apr 28, 2021 at 2:50 PM Lionel Landwerlin
wrote:
>
> On 28/04/2021 22:24, Jason Ekstrand wrote:
>
> On Wed, Apr 28, 2021 at 3:43 AM Jani Nikula
> wrote:
>
> On Tue, 27 Apr 2021, Umesh Nerlige Ramappa
> wrote:
>
> Perf measurements rely on CPU and engine timestamps to correlate
>
On 28/04/2021 22:24, Jason Ekstrand wrote:
On Wed, Apr 28, 2021 at 3:43 AM Jani Nikula wrote:
On Tue, 27 Apr 2021, Umesh Nerlige Ramappa
wrote:
Perf measurements rely on CPU and engine timestamps to correlate
events of interest across these time domains. Current mechanisms get
these
From: Rob Clark
On a5xx and a6xx devices that are using CP_WHERE_AM_I to update a
ringbuffer read-ptr shadow value, periodically emit a CP_WHERE_AM_I
every 32 commands, so that a later submit waiting for ringbuffer
space to become available sees partial progress, rather than not
seeing rptr
From: Rob Clark
Currently if userspace manages to fill up the ring faster than the GPU
can consume we (a) spin for up to 1sec, and then (b) overwrite the
ringbuffer contents from previous submits that the GPU is still busy
executing. Which predictably goes rather badly.
Instead, just skip
From: Rob Clark
With some recent userspace work to allow more rendering to be merged
into a single SUBMIT ioctl, I realized we have some sharp edges around
running out of free ringbuffer space.
1) Currently we only flush once all the cmds (or rather IBs to the cmd
buffer) are written into
On Wed, Apr 28, 2021 at 3:43 AM Jani Nikula wrote:
>
> On Tue, 27 Apr 2021, Umesh Nerlige Ramappa
> wrote:
> > Perf measurements rely on CPU and engine timestamps to correlate
> > events of interest across these time domains. Current mechanisms get
> > these timestamps separately and the
On Wed, Apr 28, 2021 at 12:18 PM Jason Ekstrand wrote:
>
> On Wed, Apr 28, 2021 at 5:13 AM Daniel Vetter wrote:
> >
> > On Tue, Apr 27, 2021 at 08:51:08AM -0500, Jason Ekstrand wrote:
> > > I sent a v2 of this patch because it turns out I deleted a bit too
> > > much code. This function in
On Wed, Apr 28, 2021 at 5:27 AM Daniel Vetter wrote:
>
> On Fri, Apr 23, 2021 at 05:31:21PM -0500, Jason Ekstrand wrote:
> > As far as I can tell, the only real reason for this is to avoid taking a
> > reference to the i915_gem_context. The cost of those two atomics
> > probably pales in
On Wed, Apr 28, 2021 at 1:02 PM Matthew Brost wrote:
>
> On Wed, Apr 28, 2021 at 12:46:07PM -0500, Jason Ekstrand wrote:
> > On Wed, Apr 28, 2021 at 12:26 PM Matthew Brost
> > wrote:
> > >
> > > On Wed, Apr 28, 2021 at 12:18:29PM -0500, Jason Ekstrand wrote:
> > > > On Wed, Apr 28, 2021 at 5:13
On Wed, Apr 28, 2021 at 11:14 AM Daniel Vetter wrote:
>
> Maybe we're overdoing it a bit, but we're trying to not backmerge all
> the time for no reason at all.
Oh, I'm not complaining. I think it's reasonable if some particular
issue doesn't hold up further development.
So my email was more a
On Wed, Apr 28, 2021 at 7:07 PM Linus Torvalds
wrote:
> On Tue, Apr 27, 2021 at 8:32 PM Dave Airlie wrote:
> >
> > There aren't a massive amount of conflicts, only with vmwgfx when I
> > did a test merge into your master yesterday, I think you should be
> > able to handle them yourself, but let
On Wed, Apr 28, 2021 at 12:46:07PM -0500, Jason Ekstrand wrote:
> On Wed, Apr 28, 2021 at 12:26 PM Matthew Brost
> wrote:
> >
> > On Wed, Apr 28, 2021 at 12:18:29PM -0500, Jason Ekstrand wrote:
> > > On Wed, Apr 28, 2021 at 5:13 AM Daniel Vetter wrote:
> > > >
> > > > On Tue, Apr 27, 2021 at
On Wed, Apr 28, 2021 at 12:26 PM Matthew Brost wrote:
>
> On Wed, Apr 28, 2021 at 12:18:29PM -0500, Jason Ekstrand wrote:
> > On Wed, Apr 28, 2021 at 5:13 AM Daniel Vetter wrote:
> > >
> > > On Tue, Apr 27, 2021 at 08:51:08AM -0500, Jason Ekstrand wrote:
> > > > On Fri, Apr 23, 2021 at 5:31 PM
> -Original Message-
> From: Auld, Matthew
> Sent: Monday, April 26, 2021 2:39 AM
> To: intel-...@lists.freedesktop.org
> Cc: Joonas Lahtinen ; Thomas Hellström
> ; Ceraolo Spurio, Daniele
> ; Lionel Landwerlin
> ; Bloomfield, Jon
> ; Justen, Jordan L ;
> Vetter, Daniel ; Kenneth Graunke
On Tue, Apr 27, 2021 at 4:49 AM Daniel Vetter wrote:
>
> On Fri, Apr 23, 2021 at 05:31:15PM -0500, Jason Ekstrand wrote:
> > This API allows one context to grab bits out of another context upon
> > creation. It can be used as a short-cut for setparam(getparam()) for
> > things like
When encoder validation of a display mode fails, retry with less bandwidth
heavy YCbCr420 color mode, if available. This enables some HDMI 1.4 setups
to support 4k60Hz output, which previously failed silently.
AMDGPU had nearly the exact same issue. This problem description is
therefore copied
On 2021-04-27 17:00, Stephen Boyd wrote:
Quoting aravi...@codeaurora.org (2021-04-21 11:55:21)
On 2021-04-21 10:26, khs...@codeaurora.org wrote:
>>
>>> +
>>> mutex_unlock(>event_mutex);
>>>
>>> return 0;
>>> @@ -1496,6 +1502,9 @@ int msm_dp_display_disable(struct msm_dp *dp,
>>>
The pull request you sent on Wed, 28 Apr 2021 13:31:59 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-next-2021-04-28
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/68a32ba14177d4a21c4a9a941cf1d7aea86d436f
Thank you!
--
Deet-doot-dot, I am a bot.
We have established previously we stop using relocations starting
from gen12 platforms with Tigerlake as an exception. Unfortunately
we need extend transition period and support relocations for two
other igfx platforms - Rocketlake and Alderlake.
As Alderlake is coming in two variants - S and P
On Wed, Apr 28, 2021 at 12:18:29PM -0500, Jason Ekstrand wrote:
> On Wed, Apr 28, 2021 at 5:13 AM Daniel Vetter wrote:
> >
> > On Tue, Apr 27, 2021 at 08:51:08AM -0500, Jason Ekstrand wrote:
> > > On Fri, Apr 23, 2021 at 5:31 PM Jason Ekstrand
> > > wrote:
> > > >
> > > > This adds a bunch of
On Wed, Apr 28, 2021 at 10:49 AM Tvrtko Ursulin
wrote:
>
>
> On 23/04/2021 23:31, Jason Ekstrand wrote:
> > This API is entirely unnecessary and I'd love to get rid of it. If
> > userspace wants a single timeline across multiple contexts, they can
> > either use implicit synchronization or a
On Wed, Apr 28, 2021 at 10:55 AM Tvrtko Ursulin
wrote:
> On 23/04/2021 23:31, Jason Ekstrand wrote:
> > Instead of handling it like a context param, unconditionally set it when
> > intel_contexts are created. This doesn't fix anything but does simplify
> > the code a bit.
> >
> > Signed-off-by:
In subject,
s/dmr/drm/
s/Move some/Move/ ("some" consumes space without adding meaning)
Or maybe something like:
drm/amdgpu: Convert driver sysfs attributes to static attributes
On Wed, Apr 28, 2021 at 11:11:49AM -0400, Andrey Grodzovsky wrote:
> This allows to remove explicit creation and
On Wed, Apr 28, 2021 at 5:13 AM Daniel Vetter wrote:
>
> On Tue, Apr 27, 2021 at 08:51:08AM -0500, Jason Ekstrand wrote:
> > On Fri, Apr 23, 2021 at 5:31 PM Jason Ekstrand wrote:
> > >
> > > This adds a bunch of complexity which the media driver has never
> > > actually used. The media driver
On Wed, Apr 28, 2021 at 9:26 AM Tvrtko Ursulin
wrote:
> On 28/04/2021 15:02, Daniel Vetter wrote:
> > On Wed, Apr 28, 2021 at 11:42:31AM +0100, Tvrtko Ursulin wrote:
> >>
> >> On 28/04/2021 11:16, Daniel Vetter wrote:
> >>> On Fri, Apr 23, 2021 at 05:31:19PM -0500, Jason Ekstrand wrote:
>
On Wed, Apr 28, 2021 at 11:11:40AM -0400, Andrey Grodzovsky wrote:
> Until now extracting a card either by physical extraction (e.g. eGPU with
> thunderbolt connection or by emulation through syfs ->
> /sys/bus/pci/devices/device_id/remove)
> would cause random crashes in user apps. The random
On Tue, Apr 27, 2021 at 8:32 PM Dave Airlie wrote:
>
> There aren't a massive amount of conflicts, only with vmwgfx when I
> did a test merge into your master yesterday, I think you should be
> able to handle them yourself, but let me know if you want me to push a
> merged tree somewhere (or if I
Init panel orientation property after connector is initialized. Let the
panel driver decides the orientation value later.
Signed-off-by: Hsin-Yi Wang
---
drivers/gpu/drm/mediatek/mtk_dsi.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
krane, kakadu, and kodama boards have a default panel rotation.
Signed-off-by: Hsin-Yi Wang
---
arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
b/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
Creating the panel orientation property first since we separate the
property creating and value setting.
Signed-off-by: Hsin-Yi Wang
---
drivers/gpu/drm/i915/display/icl_dsi.c | 1 +
drivers/gpu/drm/i915/display/intel_dp.c | 1 +
drivers/gpu/drm/i915/display/vlv_dsi.c | 1 +
3 files changed,
drm_dev_register() sets connector->registration_state to
DRM_CONNECTOR_REGISTERED and dev->registered to true. If
drm_connector_set_panel_orientation() is first called after
drm_dev_register(), it will fail several checks and results in following
warning.
Add a function to create panel
Am 2021-04-28 um 12:58 p.m. schrieb Christian König:
> Am 28.04.21 um 18:49 schrieb Felix Kuehling:
>> Am 2021-04-28 um 12:33 p.m. schrieb Christian König:
>>> Am 28.04.21 um 17:19 schrieb Felix Kuehling:
>>> [SNIP]
>> Failing that, I'd probably have to abandon userptr BOs altogether
>>
Am 28.04.21 um 18:49 schrieb Felix Kuehling:
Am 2021-04-28 um 12:33 p.m. schrieb Christian König:
Am 28.04.21 um 17:19 schrieb Felix Kuehling:
[SNIP]
Failing that, I'd probably have to abandon userptr BOs altogether and
switch system memory mappings over to using the new SVM API on systems
On Wed, Apr 28, 2021 at 11:41 AM Matthew Auld wrote:
>
> On 28/04/2021 16:51, Jason Ekstrand wrote:
> > On Mon, Apr 26, 2021 at 4:42 AM Matthew Auld wrote:
> >>
> >> Add an entry for the new uAPI needed for DG1. Also add the overall
> >> upstream plan, including some notes for the TTM
In subject:
s/PCI: add support/PCI: Add support/
to match convention ("git log --oneline drivers/pci/pci-driver.c" to
learn this).
On Wed, Apr 28, 2021 at 11:11:48AM -0400, Andrey Grodzovsky wrote:
> This is exact copy of 'USB: add support for dev_groups to
> struct usb_device_driver' patch by
On Fri, Apr 23, 2021 at 1:00 PM Douglas Anderson wrote:
>
> It doesn't make sense to go out to the bus and read the EDID over and
> over again. Let's cache it and throw away the cache when we turn power
> off from the panel. Autosuspend means that even if there are several
> calls to read the
Am 2021-04-28 um 12:33 p.m. schrieb Christian König:
> Am 28.04.21 um 17:19 schrieb Felix Kuehling:
>> Am 2021-04-28 um 5:05 a.m. schrieb Christian König:
>> [SNIP]
>> Hmm, I was missing something. The amdgpu_gtt_mgr doesn't actually
>> allocate space for many BOs:
>>
>> if (!place->lpfn)
On Fri, Apr 23, 2021 at 1:00 PM Douglas Anderson wrote:
>
> I don't believe that it ever makes sense to read the EDID when a panel
> is not powered and the powering on of the panel is the job of
> prepare(). Let's make sure that this happens before we try to read the
> EDID. We use the pm_runtime
On 28/04/2021 16:51, Jason Ekstrand wrote:
On Mon, Apr 26, 2021 at 4:42 AM Matthew Auld wrote:
Add an entry for the new uAPI needed for DG1. Also add the overall
upstream plan, including some notes for the TTM conversion.
v2(Daniel):
- include the overall upstreaming plan
- add a note
On Fri, Apr 23, 2021 at 1:00 PM Douglas Anderson wrote:
>
> As of commit 5186421cbfe2 ("drm: Introduce epoch counter to
> drm_connector") the drm_get_edid() function calls
> drm_connector_update_edid_property() for us. There's no reason for us
> to call it again.
>
> Signed-off-by: Douglas
On Fri, Apr 23, 2021 at 1:00 PM Douglas Anderson wrote:
>
> When I added support for the hpd-gpio to simple-panel in commit
> 48834e6084f1 ("drm/panel-simple: Support hpd-gpios for delaying
> prepare()"), I added a special case to handle a circular dependency I
> was running into on the
Am 28.04.21 um 17:19 schrieb Felix Kuehling:
Am 2021-04-28 um 5:05 a.m. schrieb Christian König:
[SNIP]
Hmm, I was missing something. The amdgpu_gtt_mgr doesn't actually
allocate space for many BOs:
if (!place->lpfn) {
mem->mm_node = NULL;
mem->start =
1 - 100 of 212 matches
Mail list logo
