On 9/16/2022 1:00 PM, Bjorn Andersson wrote:
From: Bjorn Andersson
The DisplayPort controller's hot-plug mechanism is based on pinmuxing a
physical signal no a GPIO pin into the controller. This is not always
nit: s/ no / on /?
possible, either because there aren't dedicated GPIOs
From: Bjorn Andersson
Most instances where HPD interrupts are masked and unmasked are guareded
by the presence of an EDP panel being connected, but not all. Extend
this to cover the last few places, as HPD interrupt handling is not used
for the EDP case.
Signed-off-by: Bjorn Andersson
Signed-off-by: Matthew Anderson
---
.../gpu/drm/drm_panel_orientation_quirks.c| 86 ++-
1 file changed, 85 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_panel_orientation_quirks.c
b/drivers/gpu/drm/drm_panel_orientation_quirks.c
index
From: Bjorn Andersson
In the SC8280XP platform there are two identical MDSS instances, each
with the same set of DisplayPort instances, at different addresses.
By not relying on the index to define the instance id it's possible to
describe them both in the same table and hence have a single
From: Bjorn Andersson
The DisplayPort controller's internal HPD interrupt handling is used for
cases where the HPD signal is connected to a GPIO which is pinmuxed into
the DisplayPort controller.
Most of the logic for enabling and disabling the HPD-related interrupts
is conditioned on the
From: Bjorn Andersson
The SC8280XP platform has four DisplayPort controllers, per MDSS
instance, all with widebus support.
The first two are defined to be DisplayPort only, while the latter pair
(of each instance) can be either DisplayPort or Embedded DisplayPort.
The two sets are tied to the
[[PATCH v5 0/2] Fix TLB invalidate issues with Broadwell] On 12/07/2022 (Tue
16:21) Mauro Carvalho Chehab wrote:
> i915 selftest hangcheck is causing the i915 driver timeouts, as reported
> by Intel CI bot:
>
>
From: Bjorn Andersson
The DisplayPort controller's hot-plug mechanism is based on pinmuxing a
physical signal no a GPIO pin into the controller. This is not always
possible, either because there aren't dedicated GPIOs available or
because the hot-plug signal is a virtual notification, in cases
From: Bjorn Andersson
Add compatibles for the DisplayPort and Embedded DisplayPort blocks in
Qualcomm SDM845 and SC8280XP platforms.
Signed-off-by: Bjorn Andersson
Signed-off-by: Bjorn Andersson
---
.../devicetree/bindings/display/msm/dp-controller.yaml | 3 +++
1 file changed, 3
From: Bjorn Andersson
The Qualcomm SDM845 platform has a single DisplayPort controller, with
the same design as SC7180, so add support for this by reusing the SC7180
definition.
Signed-off-by: Bjorn Andersson
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Bjorn Andersson
---
Introduce support for DisplayPort on SDM845 and SC8280XP, followed by
introduction of drm_bridge based HPD handling.
The version of these patches are restarted, as the previous
drm_connector_oob_hotplug_event()-based approach was abandoned and this
only barely resembles that effort.
In this
On Fri, Sep 16, 2022 at 03:04:53PM -0700, Tom Rix wrote:
>
> On 9/16/22 2:06 PM, Nathan Chancellor wrote:
> > Most of the arguments are identical between the two call sites and they
> > can be accessed through the 'struct vba_vars_st' pointer. This reduces
> > the total amount of stack space that
On 9/16/22 2:06 PM, Nathan Chancellor wrote:
Most of the arguments are identical between the two call sites and they
can be accessed through the 'struct vba_vars_st' pointer. This reduces
the total amount of stack space that
dml314_ModeSupportAndSystemConfigurationFull() uses by 240 bytes with
On 9/13/22 18:23, Javier Martinez Canillas wrote:
> Provides a default plane state check handler for primary planes that are a
> fullscreen scanout buffer and whose state scale and position can't change.
>
> There are some drivers that duplicate this logic in their helpers, such as
> simpledrm
Most of the arguments are identical between the two call sites and they
can be accessed through the 'struct vba_vars_st' pointer. This reduces
the total amount of stack space that
dml314_ModeSupportAndSystemConfigurationFull() uses by 112 bytes with
LLVM 16 (1976 -> 1864), helping clear up the
Most of the arguments are identical between the two call sites and they
can be accessed through the 'struct vba_vars_st' pointer. This reduces
the total amount of stack space that
dml314_ModeSupportAndSystemConfigurationFull() uses by 240 bytes with
LLVM 16 (2216 -> 1976), helping clear up the
From: Chris Wilson
If attempting to perform a GT reset takes long than 5 seconds (including
resetting the display for gen3/4), then we declare all hope lost and
discard all user work and wedge the device to prevent further
misbehaviour. 5 seconds is too short a time for such drastic action, as
If the copy of the description string from userspace fails, then the page
for the instance descriptor doesn't get freed before returning -EFAULT,
which leads to a memleak.
Fixes: 7a7a933edd6c ("drm/vmwgfx: Introduce VMware mks-guest-stats")
Signed-off-by: Rafael Mendonca
---
From: Chris Wilson
If attempting to perform a GT reset takes long than 5 seconds (including
resetting the display for gen3/4), then we declare all hope lost and
discard all user work and wedge the device to prevent further
misbehaviour. 5 seconds is too short a time for such drastic action, as
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: d5538ab91d3a9a237805be6f8c6c272af2987995 Add linux-next specific
files for 20220916
Error/Warning reports:
https://lore.kernel.org/linux-media/202209162214.lzfxhn2b-...@intel.com
https
On 9/16/2022 02:10, Tvrtko Ursulin wrote:
On 15/09/2022 21:03, John Harrison wrote:
On 9/15/2022 01:59, Tvrtko Ursulin wrote:
Hi,
On 15/09/2022 00:46, john.c.harri...@intel.com wrote:
From: John Harrison
Going forwards, the intention is for GuC firmware files to be named
for their major
On Thu, 15 Sep 2022 12:15:28 +0100, Geert Uytterhoeven wrote:
> Hi Krzysztof,
>
> On Thu, Sep 15, 2022 at 10:26 AM Krzysztof Kozlowski
> wrote:
> > On Wed, 14 Sep 2022 16:33:22 +0200, Geert Uytterhoeven wrote:
> > > Convert the NXP TDA998x HDMI transmitter Device Tree binding
> > > documentation
Hi folks,
On Fri, Sep 2, 2022 at 12:41 AM Prashant Malani wrote:
>
> Hi Rob,
>
> On Jul 12 11:45, Rob Herring wrote:
> >
> > That's not the right interpretation. There should not be some Type-C
> > specific child mux/switch node because the device has no such h/w within
> > it. Assuming all the
Samsung MIPI DSIM master can also be found in i.MX8MM SoC.
Add compatible and associated driver_data for it.
v5:
* [mszyprow] rebased and adjusted to the new driver initialization
* drop quirk
v4:
* none
v3:
* enable DSIM_QUIRK_FIXUP_SYNC_POL quirk
v2:
* collect Laurent r-b
v1:
* none
Samsung MIPI DSIM bridge can also be found in i.MX8MM SoC.
Add dt-bingings for it.
v5, v4:
* none
v3:
* collect Rob Acked-by
v2:
* updated comments
v1:
* new patch
Acked-by: Rob Herring
Signed-off-by: Jagan Teki
---
Documentation/devicetree/bindings/display/exynos/exynos_dsim.txt | 1 +
1
eLCDIF is expecting to have input_bus_flags as DE_LOW in order to
set active low during valid data transfer on each horizontal line.
Add DE_LOW flag via drm bridge timings.
v5:
* rebased based on updated bridge changes
v4, v3, v2, v1:
* none
Signed-off-by: Jagan Teki
---
In i.MX8M Mini/Nano SoC the DSI Phy requires a MIPI DPHY bit
to reset in order to activate the PHY and that can be done via
upstream i.MX8M blk-ctrl driver.
So, mark the phy get as optional.
v5, v4, v3, v2:
* none
v1:
* new patch
Signed-off-by: Jagan Teki
---
Look like PLL PMS_P offset value varies between platforms that have
Samsung DSIM IP.
However, there is no clear evidence for it as both Exynos and i.MX
8M Mini Application Processor Reference Manual is still referring
the PMS_P offset as 13.
The offset 13 is not working for i.MX8M Mini SoCs but
Finding the right input bus format throughout the pipeline is hard
so add atomic_get_input_bus_fmts callback and initialize with the
default RGB888_1X24 bus format on DSI-end.
This format can be used in pipeline for negotiating bus format between
the DSI-end of this bridge and the other component
DSI host initialization handling in previous exynos dsi driver has
some pitfalls. It initializes the host during host transfer() hook
that is indeed not the desired call flow for I2C and any other DSI
configured downstream bridges.
Host transfer() is usually triggered for downstream DSI panels or
Look like an explicit fixing up of mode_flags is required for DSIM IP
present in i.MX8M Mini/Nano SoCs.
At least the LCDIF + DSIM needs active low sync polarities in order
to correlate the correct sync flags of the surrounding components in
the chain to make sure the whole pipeline can work
Samsung MIPI DSIM controller is common DSI IP that can be used in various
SoCs like Exynos, i.MX8M Mini/Nano.
In order to access this DSI controller between various platform SoCs,
the ideal way to incorporate this in the drm stack is via the drm bridge
driver.
This patch is trying to
The child devices in MIPI DSI can be binding with OF-graph
and also via child nodes.
The OF-graph interface represents the child devices via
remote and associated endpoint numbers like
dsi {
compatible = "fsl,imx8mm-mipi-dsim";
ports {
port@0 {
reg = <0>;
From: Marek Szyprowski
Restore the proper bridge chain by finding the previous bridge
in the chain instead of passing NULL.
This establishes a proper bridge chain while attaching downstream
bridges.
v5:
* exclude the NULL replacement in exynos_dsi_host_attach
v4:
* none
v3:
* new patch
This series supports common bridge support for Samsung MIPI DSIM
which is used in Exynos and i.MX8MM SoC's.
Previous v4 can be available here [1], repo on linux-next [2] and
Engicam i.Core MX8M Mini SoM boot log [3].
The final bridge supports both the Exynos and i.MX8MM DSI devices.
Changes for
Applied the series.
Thanks,
Alex
On Wed, Sep 14, 2022 at 9:58 PM Yang Li wrote:
>
> clean up some inconsistent indentings
>
> Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=2177
> Reported-by: Abaci Robot
> Signed-off-by: Yang Li
> ---
>
DSMBASE register is defined so BDSM bitfield contains the bits 63 to 20
of the base address of stolen. For the supported platforms bits 0-19 are
zero but that may not be true in future. Add the missing mask.
v2: Use REG_GENMASK64()
Acked-by: Aravind Iddamsetty
Reviewed-by: Caz Yokoyama
There is no reason to consider the setup of Data Stolen Memory fatal on
dgfx and non-fatal on integrated. Move the debug and error propagation
around so both have the same behavior: non-fatal. Before this change,
loading i915 on a system with TGL + DG2 would result in just TGL
succeeding the
Add some helpers: adjust_stolen(), request_smem_stolen_() and
init_reserved_stolen() that are now called by i915_gem_init_stolen() to
initialize each part of the Data Stolen Memory region.
Main goal is to split the reserved part within the stolen, also known as
WOPCM, as its calculation changes
Better split, document, and make the code paths for integrated and discrete
more similar.
v2:
- s/GENMASK/REG_GENMASK64/ where appropriate
- Fix comment
Signed-off-by: Lucas De Marchi
---
Lucas De Marchi (3):
drm/i915: Add missing mask when reading GEN12_DSMBASE
drm/i915: Split
Applied. Thanks!
On Wed, Sep 14, 2022 at 1:15 PM Colin Ian King wrote:
>
> There is a spelling mistake in a pr_debug message. Fix it.
>
> Signed-off-by: Colin Ian King
> ---
> drivers/gpu/drm/amd/amdkfd/kfd_migrate.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git
Hi Johan,
On Wed, Sep 14, 2022 at 1:01 AM Johan Hovold wrote:
>
> On Tue, Sep 13, 2022 at 03:23:10PM -0500, Steev Klimaszewski wrote:
> > Hi Johan,
> >
> > On 9/13/22 3:53 AM, Johan Hovold wrote:
> > > The MSM DRM driver is currently broken in multiple ways with respect to
> > > probe deferral.
From: Ville Syrjälä
Make blocking commits execute locklessly (just as nonblocking
commits do) by scheduling them onto the workqueues as well.
There will be a later flush_work() done by whoever called
the commit hook to make sure the blocking behaviour of the
ioctl/etc. is preserved.
I also
From: Ville Syrjälä
Currently a nonblocking commit will actually block if it is
preceded by a blocking commit. It just happens block on the
mutex rather than on the completion. I shall call these as
not-actually-nonblocking commits.
I would like to make blocking commits execute locklessly,
just
From: Ville Syrjälä
Currently we reuse the commit_work for a later cleanup step.
Let's not do that so that atomic ioctl handler won't accidentally
wait for the cleanup work when it really wants to just wait on the
commit_tail() part. We'll just add another work struct for the
cleanup.
Cc:
From: Ville Syrjälä
The easiest way to execute blocking commits locklessly is to just
schedule them onto the workqueue excatly as we do for nonblocking
commits. And to preserve the blocking behaviour of the ioctl we
just flush the work before exiting the kernel.
We do need to reorder the
From: Ville Syrjälä
I've talked about making blocking commits lockless a few
times in the past, so here's finally an attempt at it.
The main benefit I see from this is that TEST_ONLY commits
no longer getting blocked on the mutexes by parallel blocking
commits.
I have a small test here that
On Fri, Sep 16, 2022 at 05:50:33PM +0530, Iddamsetty, Aravind wrote:
On 16-09-2022 02:09, Lucas De Marchi wrote:
Add some helpers: adjust_stolen(), request_smem_stolen_() and
init_reserved_stolen() that are now called by i915_gem_init_stolen() to
initialize each part of the Data Stolen Memory
>From afe79848cb74cc8e45ab426d13fa2394c87e0422 Mon Sep 17 00:00:00 2001
From: xmzyshypnc <1002992...@qq.com>
Date: Fri, 16 Sep 2022 23:48:23 +0800
Subject: [PATCH] drm/i915/gvt: fix double-free bug in split_2MB_gtt_entry
There is a double-free security bug in split_2MB_gtt_entry.
Here is a
Hi Dave, Daniel,
Updates for 6.1.
The following changes since commit 213cb76ddc8b875e772f9f4d173feefa122716af:
Merge tag 'drm-intel-gt-next-2022-09-09' of
git://anongit.freedesktop.org/drm/drm-intel into drm-next (2022-09-12 21:12:23
+1000)
are available in the Git repository at:
Hi greg,
Thanks for pointing that out. Working on it now :)
Best wishes,
Zheng Wang
Greg KH 于2022年9月16日周五 16:25写道：
>
> On Fri, Sep 16, 2022 at 02:39:21PM +0800, Zheng Hacker wrote:
> > >From 8d95c1399e3ff345500a575e21254a73b0c89144 Mon Sep 17 00:00:00 2001
> > From: xmzyshypnc
Most drivers succeed to read out the programmed state unconditionally.
But some don't, allow them to signal a failure to the pwm core.
All drivers are adapted to return 0 on success and forward the error
code otherwise.
The core doesn't make use of this yet.
Signed-off-by: Uwe Kleine-König
---
Record and report an error code for the events. This allows to report
about failed calls without ambiguity and so gives a more complete
picture.
Signed-off-by: Uwe Kleine-König
---
drivers/pwm/core.c | 18 --
include/trace/events/pwm.h | 20 ++--
2 files
This suppresses diagnosis for PWM_DEBUG routines and makes sure that
pwm->state isn't modified in pwm_device_request() if .get_state() fails.
Signed-off-by: Uwe Kleine-König
---
drivers/pwm/core.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git
This exposes a accumulated GPU active time per client via the
fdinfo infrastructure.
Signed-off-by: Lucas Stach
---
v2:
- fix code style
- switch to raw seq_printf
- leave some breadcrumbs about the output format
---
drivers/gpu/drm/etnaviv/etnaviv_drv.c | 40 ++-
1 file
Allows to easily track if several fd are pointing to the same
execution context due to being dup'ed.
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/etnaviv/etnaviv_drv.c | 3 +++
drivers/gpu/drm/etnaviv/etnaviv_drv.h | 1 +
2 files changed, 4 insertions(+)
diff --git
Track the accumulated time that jobs from this entity were active
on the GPU. This allows drivers using the scheduler to trivially
implement the DRM fdinfo when the hardware doesn't provide more
specific information than signalling job completion anyways.
Signed-off-by: Lucas Stach
Reviewed-by:
From: Dale B Stimson
Extend hwmon power/energy for XEHPSDV especially per gt level energy
usage.
v2: Update to latest HWMON spec (Ashutosh)
v3: Fixed review comments (Ashutosh)
Signed-off-by: Ashutosh Dixit
Signed-off-by: Dale B Stimson
Signed-off-by: Badal Nilawar
Acked-by: Guenter Roeck
From: Ashutosh Dixit
Expose power1_max_interval, that is the tau corresponding to PL1. Some bit
manipulation is needed because of the format of PKG_PWR_LIM_1_TIME in
GT0_PACKAGE_RAPL_LIMIT register (1.x * power(2,y)).
v2: Update date and kernel version in Documentation (Badal)
v3: Cleaned up
From: Dale B Stimson
Use i915 HWMON to display device level energy input.
v2:
- Updated the date and kernel version in feature description
v3:
- Cleaned up hwm_energy function and removed unused function
i915_hwmon_energy_status_get (Ashutosh)
- Updated date, kernel version in
From: Dale B Stimson
Use i915 HWMON to display/modify dGfx power PL1 limit and TDP setting.
v2:
- Fix review comments (Ashutosh)
- Do not restore power1_max upon module unload/load sequence
because on production systems modules are always loaded
and not unloaded/reloaded (Ashutosh)
From: Ashutosh Dixit
Expose the card reactive critical (I1) power. I1 is exposed as
power1_crit in microwatts (typically for client products) or as
curr1_crit in milliamperes (typically for server).
v2: Add curr1_crit functionality (Ashutosh)
v3:
- Use HWMON_CHANNEL_INFO to define
From: Riana Tauro
Use i915 HWMON subsystem to display current input voltage.
v2:
- Updated date and kernel version in feature description
- Fixed review comments (Ashutosh)
v3: Use macro HWMON_CHANNEL_INFO to define hwmon channel (Guenter)
v4:
- Fixed review comments (Ashutosh)
- Use
From: Dale B Stimson
The i915 HWMON module will be used to expose voltage, power and energy
values for dGfx. Here we set up i915 hwmon infrastructure including i915
hwmon registration, basic data structures and functions.
v2:
- Create HWMON infra patch (Ashutosh)
- Fixed review comments
This series adds the HWMON support for DGFX
Test-with: 20220914140721.3500129-1-riana.ta...@intel.com
v2:
- Reorganized series. Created first patch as infrastructure patch
followed by feature patches. (Ashutosh)
- Fixed review comments (Jani)
- Fixed review comments (Ashutosh)
v3:
-
Am Samstag, dem 10.09.2022 um 13:29 -0700 schrieb Doug Brown:
> This series contains a few special cases for supporting the GC300
> properly. These were found in the drivers in the vivante_kernel_drivers
> repository. These changes were tested on a PXA168 with GC300 revision
> 0x2201 (date
On Fri, Sep 16, 2022 at 10:02:32AM +0100, Tvrtko Ursulin wrote:
>
> On 16/09/2022 02:43, Matt Roper wrote:
> > Although the bspec lists several MMIO ranges as "MSLICE," it turns out
> > that a subset of these are of a "GAM" subclass that has unique rules and
> > doesn't followed regular mslice
If DEBUG_KERNEL is selected with a kernel build without DRM, Kconfig still
asks if DRM_DEBUG_MODESET_LOCK is to be selected or not, although this has
no influence on the kernel without DRM.
Make DRM_DEBUG_MODESET_LOCK depend on DRM to avoid needless questions
during kernel build configuration.
The pull request you sent on Fri, 16 Sep 2022 18:28:58 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2022-09-16
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/5763d7f29652f94bdfc9dab87888f79ba6bb6c34
Thank you!
--
Deet-doot-dot, I am a bot.
On 9/9/22 10:34 AM, Mauro Carvalho Chehab wrote:
There are several trivial warnings there, due to trivial things:
- lack of function name at the kerneldoc markup;
- renamed functions;
- wrong parameter syntax.
Fix such warnings:
On 2022-09-16 05:12, Lucas Stach wrote:
Am Donnerstag, dem 08.09.2022 um 14:33 -0400 schrieb Andrey Grodzovsky:
On 2022-09-08 14:10, Lucas Stach wrote:
Track the accumulated time that jobs from this entity were active
on the GPU. This allows drivers using the scheduler to trivially
implement
Looks good to me.
Reviewed-by: Gwan-gyeong Mun
On 9/9/22 10:34 AM, Mauro Carvalho Chehab wrote:
There are a couple of issues at i915 display kernel-doc markups:
drivers/gpu/drm/i915/display/intel_display_debugfs.c:2238: warning:
Function parameter or member 'intel_connector' not
On 16-09-2022 02:09, Lucas De Marchi wrote:
> Add some helpers: adjust_stolen(), request_smem_stolen_() and
> init_reserved_stolen() that are now called by i915_gem_init_stolen() to
> initialize each part of the Data Stolen Memory region. Main goal is to
> split the reserved part, also known as
On 16/09/2022 10:50, Lucas Stach wrote:
Hi Tvrtko,
Am Freitag, dem 16.09.2022 um 10:31 +0100 schrieb Tvrtko Ursulin:
Hi Lucas,
On 08/09/2022 19:10, Lucas Stach wrote:
This exposes a accumulated GPU active time per client via the
fdinfo infrastructure.
Signed-off-by: Lucas Stach
---
Hi Dave & Daniel -
The final feature pull for v6.1.
drm-intel-next-2022-09-16-1:
drm/i915 feature pull #2 for v6.1:
Features and functionality:
- More Meteorlake platform enabling (Radhakrishna, Imre, Madhumitha)
- Allow seamless M/N changes on eDP panels that support it (Ville)
- Switch DSC
Reviewed-by: Gwan-gyeong Mun
On 9/16/22 12:24 PM, Janusz Krzysztofik wrote:
From: Chris Wilson
i915_perf assumes that it can use the i915_gem_context reference to
protect its i915->gem.contexts.list iteration. However, this requires
that we do not remove the context from the list until after
Reviewed-by: Gwan-gyeong Mun
On 9/16/22 12:24 PM, Janusz Krzysztofik wrote:
Due to i915_perf assuming that it can use the i915_gem_context reference
to protect its i915->gem.contexts.list iteration, we need to defer removal
of the context from the list until last reference to the context is
On 16-09-2022 02:09, Lucas De Marchi wrote:
> DSMBASE register is defined so BDSM bitfield contains the bits 63 to 20
> of the base address of stolen. For the supported platforms bits 0-19 are
> zero but that may not be true in future. Add the missing mask.
>
> Signed-off-by: Lucas De Marchi
On 16-09-2022 02:09, Lucas De Marchi wrote:
> Reduce possible side effects of assigning the region and bailing out due
> to errors.
>
> Signed-off-by: Lucas De Marchi
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
> b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
> index
On 9/16/22 13:41, Thomas Zimmermann wrote:
[...]
>>
>>> + * @dev: DRM device
>>> + * @type: the type of the struct which contains struct _plane
>>> + * @member: the name of the _plane within @type
>>> + * @possible_crtcs: bitmask of possible CRTCs
>>> + * @funcs: callbacks for the new plane
>>>
Hi
Am 16.09.22 um 13:22 schrieb Javier Martinez Canillas:
On 9/9/22 12:59, Thomas Zimmermann wrote:
Provide drm_univeral_plane_alloc(), which allocated an initializes a
plane. Code for non-atomic drivers uses this pattern. Convert it to
the new function. The modeset helpers contain a quirk for
Hi
Am 16.09.22 um 13:06 schrieb Laurent Pinchart:
Hi Thomas,
Thank you for the patch.
On Fri, Sep 09, 2022 at 12:59:45PM +0200, Thomas Zimmermann wrote:
Provide drm_univeral_plane_alloc(), which allocated an initializes a
plane. Code for non-atomic drivers uses this pattern. Convert it to
On 9/9/22 12:59, Thomas Zimmermann wrote:
> Provide DRM_PLANE_NON_ATOMIC_FUNCS, which initializes plane functions
> of non-atomic drivers to default values. The macro is not supposed to
> be used in new code, but helps with documenting and finding existing
> users.
>
> Signed-off-by: Thomas
On 9/9/22 12:59, Thomas Zimmermann wrote:
> The plane update and disable helpers are only useful for non-atomic
> drivers. Print a warning if an atomic driver calls them.
>
> Suggested-by: Daniel Vetter
> Signed-off-by: Thomas Zimmermann
> ---
Reviewed-by: Javier Martinez Canillas
--
Best
On Fr, 2022-09-16 at 12:40 +0200, Lucas Stach wrote:
> While the interface for the MMU mapping takes phys_addr_t to hold a
> full 64bit address when necessary and MMUv2 is able to map physical
> addresses with up to 40bit, etnaviv_iommu_map() truncates the address
> to 32bits. Fix this by using
Hi Thomas,
Thank you for the patch.
On Fri, Sep 09, 2022 at 12:59:47PM +0200, Thomas Zimmermann wrote:
> Provide DRM_PLANE_NON_ATOMIC_FUNCS, which initializes plane functions
> of non-atomic drivers to default values. The macro is not supposed to
> be used in new code, but helps with documenting
On 9/9/22 12:59, Thomas Zimmermann wrote:
> Provide drm_univeral_plane_alloc(), which allocated an initializes a
> plane. Code for non-atomic drivers uses this pattern. Convert it to
> the new function. The modeset helpers contain a quirk for handling their
> color formats differently. Set the
Hi Thomas,
Thank you for the patch.
On Fri, Sep 09, 2022 at 12:59:46PM +0200, Thomas Zimmermann wrote:
> The plane update and disable helpers are only useful for non-atomic
> drivers. Print a warning if an atomic driver calls them.
>
> Suggested-by: Daniel Vetter
> Signed-off-by: Thomas
Gentle ping. I know it's conference time, but I'd appreciate if this
could be merged in time for v6.1.
I also forgot to mention explicitly in the pull request that patch
"media: vsp1: Add premultiplied alpha support" has Mauro's approval for
merge through the DRM tree (the patch has his ack, but
Hi Thomas,
Thank you for the patch.
On Fri, Sep 09, 2022 at 12:59:45PM +0200, Thomas Zimmermann wrote:
> Provide drm_univeral_plane_alloc(), which allocated an initializes a
> plane. Code for non-atomic drivers uses this pattern. Convert it to
> the new function. The modeset helpers contain a
Hi Thomas,
Thank you for the patch.
On Fri, Sep 09, 2022 at 12:59:44PM +0200, Thomas Zimmermann wrote:
> Open-code drm_plane_init() and remove the function from DRM. The
> implementation of drm_plane_init() is a simple wrapper around a call
> to drm_universal_plane_init(), so drivers can just
Hello Thomas,
On 9/9/22 12:59, Thomas Zimmermann wrote:
> Open-code drm_plane_init() and remove the function from DRM. The
> implementation of drm_plane_init() is a simple wrapper around a call
> to drm_universal_plane_init(), so drivers can just use that instead.
>
> Signed-off-by: Thomas
While the interface for the MMU mapping takes phys_addr_t to hold a
full 64bit address when necessary and MMUv2 is able to map physical
addresses with up to 40bit, etnaviv_iommu_map() truncates the address
to 32bits. Fix this by using the correct type.
Fixes: 931e97f3afd8 ("drm/etnaviv: mmuv2:
On Fri, Sep 16, 2022 at 1:58 PM Marek Szyprowski
wrote:
>
> Hi Jagan,
>
> On 14.09.2022 11:39, Jagan Teki wrote:
> > On Wed, Sep 14, 2022 at 2:51 PM Marek Szyprowski
> > wrote:
> >> On 13.09.2022 19:29, Jagan Teki wrote:
> >>> On Wed, Sep 7, 2022 at 3:34 PM Marek Szyprowski
> >>> wrote:
>
Move the DSC parsing logic into separate function.
v2: Rebase.
Signed-off-by: Ankit Nautiyal
Reviewed-by: Jani Nikula
---
drivers/gpu/drm/drm_edid.c | 128 -
1 file changed, 69 insertions(+), 59 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c
HF-VSDB/SCDB has bits to advertise support for 16, 12 and 10 bpc.
If none of the bits are set, the minimum bpc supported with DSC is 8.
This patch corrects the min bpc supported to be 8, instead of 0.
Fixes: 76ee7b905678 ("drm/edid: Parse DSC1.2 cap fields from HFVSDB block")
Cc: Ankit Nautiyal
DSC capabilities are given in bytes 11-13 of VSDB (i.e. bytes 8-10 of
SCDS). Since minimum length of Data block is 7, all bytes greater than 7
must be read only after checking the length of the data block.
This patch adds check for data block length before reading relavant DSC
bytes.
Replace multiple log lines with a single log line at the end of
parsing HF-VSDB. Also use drm_dbg_kms instead of DRM_DBG_KMS, and
add log for DSC1.2 support.
v2: Fixed the formatting issues in the logging (Jani).
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/drm_edid.c | 21
Fix issues in HFVSDB parsing for DSC support.
Also minor refactoring in Logging.
Split from original patch into a new series.
https://patchwork.freedesktop.org/patch/495193/
v2: Minor styling fixes.
Ankit Nautiyal (4):
drm/edid: Fix minimum bpc supported with DSC1.2 for HDMI sink
drm/edid:
Hi Tvrtko,
Am Freitag, dem 16.09.2022 um 10:31 +0100 schrieb Tvrtko Ursulin:
> Hi Lucas,
>
> On 08/09/2022 19:10, Lucas Stach wrote:
> > This exposes a accumulated GPU active time per client via the
> > fdinfo infrastructure.
> >
> > Signed-off-by: Lucas Stach
> > ---
> >
1 - 100 of 130 matches
Mail list logo
