On 2021-04-27 7:27, Fabio M. De Francesco wrote:
In the documentation of functions, removed excess parameters, described
undocumented ones, and fixed syntax errors.
Signed-off-by: Fabio M. De Francesco
---
Changes from v1: Cc'ed all the maintainers.
Looks like Alex already applied V1. So thi
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 difference
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 u
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 o
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 differen
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 orientation
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
inde
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
b/drivers/gp
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
b/drivers/gpu/drm/amd
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 2744558f30
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 is
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 9165971c3c47..7e1aa
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 m
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 f
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: Umesh
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 l
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/ lan
[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 l
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:
- Fixe
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
inco
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 behavi
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
ind
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 shows
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 i
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 deletions
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 inserti
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 there
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
ha
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 deletion
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 aux
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 drivers/gpu/drm/drm_sys
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 p
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 d
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:
https:/
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
---
Documentation/
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 a5e76aa06ad5..8fa64
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 (2)
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 obj
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 wro
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:
> wa
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
> ---
> drivers/gpu/drm/amd/amdgpu/am
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' [-Wpointer-bool-con
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
>
> drivers/gpu/drm/amd/pm/powe
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 window
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: p
+ 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, lea
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
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
wrot
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 time
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
> events
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 timestam
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 advan
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 flush
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 the
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 calcula
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 parti
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 comparis
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 s
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 m
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 08:
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 Ja
> -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 I915_CONTEXT_P
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 fro
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(&dp->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.
https://ko
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 an
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 co
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 sync
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: J
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 d
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 do
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:
> The
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
b/drivers/gp
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
inde
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, 3
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 orientation
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
>> and
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
wher
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 conversion.
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 G
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 EDID
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 f
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 Anderso
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 ti-sn65dsi
1 - 100 of 212 matches
Mail list logo
