The next call to sii8620_burst_get_tx_buf will result in off-by-one
When ctx->burst.tx_count + size == ARRAY_SIZE(ctx->burst.tx_buf). The same
thing happens in sii8620_burst_get_rx_buf.
This patch also change tx_count and tx_buf to rx_count and rx_buf in
sii8620_burst_get_rx_buf. It is unreasonabl
On 2022-05-13 at 14:06:11 -0700, Jordan Justen wrote:
> On 2022-05-13 05:31:00, Lionel Landwerlin wrote:
> > On 02/05/2022 17:15, Ramalingam C wrote:
> > > Capture the impact of memory region preference list of the objects, on
> > > their memory residency and Flat-CCS capability.
> > >
> > > v2:
>
On Mon-16-05-2022 02:09 pm, Jani Nikula wrote:
On Mon, 02 May 2022, Harry Wentland wrote:
Both the kernel and IGT series look good to me.
I recommend you merge the entire kernel set as one into drm-next. We
can pull it into amd-staging-drm-next so as not to break our CI once
the IGT patches la
Disable ABM feature when the system is running on AC mode to get the more
perfect contrast of the display.
v2: remove "UPSTREAM" from the subject.
v3: adv->pm.ac_power updating by amd gpu_acpi_event_handler.
v4: Add the file I lost to fix the build error.
v5: Move that function of the setting a
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: 47c1c54d1bcd0a69a56b49473bc20f17b70e5242 Add linux-next specific
files for 20220517
Error/Warning reports:
https://lore.kernel.org/linux-mm/202204181931.klac6fwo-...@intel.com
https
On 4/5/22 08:15, Borislav Petkov wrote:
> From: Borislav Petkov
>
> Fix:
>
> In file included from :0:0:
> drivers/gpu/drm/i915/gt/uc/intel_guc.c: In function ‘intel_guc_send_mmio’:
> ././include/linux/compiler_types.h:352:38: error: call to
> ‘__compiletime_assert_1047’ \
> declared
So I think you forgot to update the subject of the patch. If you can send a
respin of this patch with a corrected patch title, then you can consider this:
Reviewed-by: Lyude Paul
I'll push once you get the respin out
On Mon, 2022-05-16 at 15:31 +0200, Mark Menzynski wrote:
> Resources needed fo
So I think you forgot to update the subject of the patch. If you can send a
respin of this patch with a corrected patch title, then you can consider this:
Reviewed-by: Lyude Paul
I'll push once you get the respin out
On Mon, 2022-05-16 at 15:31 +0200, Mark Menzynski wrote:
> Resources needed fo
YEah I saw this as well, will try to bisect soon
On Tue, 2022-05-17 at 13:10 +0200, Hans de Goede wrote:
> Hi All,
>
> I just noticed the below lockdep possible deadlock report with a 5.18-rc6
> kernel on a Dell Latitude E6430 laptop with the following nvidia GPU:
>
> 01:00.0 VGA compatible cont
Reviewed-by: Lyude Paul
Will push to the appropriate branch in a bit
On Mon, 2022-05-16 at 11:20 +0800, Hangyu Hua wrote:
> drm_dp_mst_get_edid call kmemdup to create mst_edid. So mst_edid need to be
> freed after use.
>
> Signed-off-by: Hangyu Hua
> ---
> drivers/gpu/drm/dp/drm_dp_mst_topolo
VM_BIND and related uapi definitions
v2: Ensure proper kernel-doc formatting with cross references.
Also add new uapi and documentation as per review comments
from Daniel.
Signed-off-by: Niranjana Vishwanathapura
---
Documentation/gpu/rfc/i915_vm_bind.h | 399 +++
This is the i915 driver VM_BIND feature design RFC patch series along
with the required uapi definition and description of intended use cases.
v2: Updated design and uapi, more documentation.
v3: Add more documentation and proper kernel-doc formatting with cross
references (including missing i
Add some missing i915 upai documentation which the new
i915 VM_BIND feature documentation will be refer to.
Signed-off-by: Niranjana Vishwanathapura
---
include/uapi/drm/i915_drm.h | 153 +++-
1 file changed, 116 insertions(+), 37 deletions(-)
diff --git a/includ
VM_BIND design document with description of intended use cases.
v2: Add more documentation and format as per review comments
from Daniel.
Signed-off-by: Niranjana Vishwanathapura
---
Documentation/driver-api/dma-buf.rst | 2 +
Documentation/gpu/rfc/i915_vm_bind.rst | 304 +++
Am Freitag, 22. April 2022, 09:28:17 CEST schrieb Sascha Hauer:
> It's v11 time. There's only one small change to v10. Discussion seems to
> have settled now. Is there anything left that prevents the series from
> being merged? I'd really like to have it in during the next merge
> window.
>
> This
On Fri, 22 Apr 2022 09:28:17 +0200, Sascha Hauer wrote:
> It's v11 time. There's only one small change to v10. Discussion seems to
> have settled now. Is there anything left that prevents the series from
> being merged? I'd really like to have it in during the next merge
> window.
>
> This series
On Wed, 11 May 2022 10:21:06 +0200, Sascha Hauer wrote:
> The VOP2 driver sitting in next uses named register spaces, but the
> binding lacks documentation for that. Add the missing documentation
> and while at it take the opportunity to rename the register spaces
> from too generic "regs" to "vop"
Hi,
On Tue, May 17, 2022 at 10:26 AM Kuogee Hsieh wrote:
>
> This patch add regulator_set_load() to both eDP and DP phy driver
> to have totally control regulators.
>
> Signed-off-by: Kuogee Hsieh
> ---
> drivers/phy/qualcomm/phy-qcom-edp.c | 25 +
> drivers/phy/qualcomm
On 5/17/22 00:35, Tvrtko Ursulin wrote:
>
> Hi,
>
> On 16/05/2022 22:22, Randy Dunlap wrote:
>>
>>
>> On 5/16/22 03:57, Stephen Rothwell wrote:
>>> Hi all,
>>>
>>> Changes since 20220513:
>>>
>>
>> on i386:
>>
>> CC drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.o
>> ../drivers/gpu/drm/i915
Hi Kieran,
> Subject: Re: [PATCH v2] drm: rcar-du: Fix Alpha blending issue on Gen3
>
> Quoting Biju Das (2022-04-26 09:41:57)
> > From: LUU HOAI
> >
> > As per R-Car-Gen3_Common_OPC_Customer_Notifications_V30.1.pdf,
> > unexpected image output(such as incorrect colors or planes being
> > invisi
> -Original Message-
> From: Tvrtko Ursulin
> Sent: Tuesday, May 17, 2022 6:49 AM
> To: Auld, Matthew ; intel-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org; Thomas Hellström
> ; Landwerlin, Lionel G
> ; Bloomfield, Jon ;
> Daniel Vetter ; Justen, Jordan L
> ; Kenneth Gr
In the event of a job timeout, debug dump information will be written into
/sys/class/devcoredump.
Inspired by etnaviv's similar feature.
Signed-off-by: Adrián Larumbe
---
drivers/gpu/drm/panfrost/Kconfig | 1 +
drivers/gpu/drm/panfrost/Makefile| 3 +-
drivers/gpu/drm/panfro
This patch adds support for devcoredump in the Panfrost driver. Code
structure is heavily inspired by similar functionality in the Etnaviv
driver, but the main goal of the crash dump is feeding it to a userspace
analyser that accesses the BO raw binary data to pass it to the pandecode
library.
Mes
Vdda regulators are related to both eDP and DP phy so that it should be
managed at eDP and DP phy driver instead of controller. This patch remove
vdda regulators related functions out of eDP/DP controller.
Signed-off-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/dp/dp_parser.c | 14 --
drivers/gp
This patch add regulator_set_load() to both eDP and DP phy driver
to have totally control regulators.
Signed-off-by: Kuogee Hsieh
---
drivers/phy/qualcomm/phy-qcom-edp.c | 25 +
drivers/phy/qualcomm/phy-qcom-qmp.c | 24
2 files changed, 45 inserti
1) add regulator_set_load() to eDP/DP phy
2) remove vdda related function out of eDP/DP controller
Kuogee Hsieh (2):
phy/qcom: add regulator_set_load to edp/dp phy
drm/msm/dp: delete vdda regulator related functions from eDP/DP
controller
drivers/gpu/drm/msm/dp/dp_parser.c | 14 --
if drm_syncobj_fence_get return null, we will get a
null pointer. Fix this by adding the null pointer check
on fence.
Signed-off-by: Yongzhi Liu
---
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer
dp_catalog_ctrl_reset() will software reset DP controller. But it will
not reset programmable registers to default value. DP driver still have
to clear mask bits to interrupt status registers to disable interrupts
after software reset of controller.
At current implementation, dp_ctrl_reset_irq_ctr
On Mon, 25 Apr 2022 at 11:14, Xin Ji wrote:
>
> On Mon, Apr 25, 2022 at 04:24:50PM +0800, Chen-Yu Tsai wrote:
> > On Fri, Apr 22, 2022 at 10:13 PM Robert Foss wrote:
> > >
> > > On Fri, 22 Apr 2022 at 16:01, Robert Foss wrote:
> > > >
> > > > On Fri, 22 Apr 2022 at 10:49, Xin Ji wrote:
> > > >
On 5/17/2022 1:25 AM, Stephen Boyd wrote:
Quoting Kuogee Hsieh (2022-05-12 12:43:18)
diff --git a/drivers/gpu/drm/msm/dp/dp_ctrl.c b/drivers/gpu/drm/msm/dp/dp_ctrl.c
index af7a80c..f3e333e 100644
--- a/drivers/gpu/drm/msm/dp/dp_ctrl.c
+++ b/drivers/gpu/drm/msm/dp/dp_ctrl.c
@@ -1389,8 +1389,13
On 17/05/2022 17:21, Neal Liu wrote:
>
> + udc: udc@1e6a2000 {
The same as DTS in bindings - generic node name, please.
>>>
>>> Is it possible to use "udc: usb-udc@1e6a2000" to distinguish it between
>>> "vhub:
>> usb-vhub@1e6a"?
>>
>> Possible yes :), but not re
Typically the acpi_video driver will initialize before radeon, which
used to cause /sys/class/backlight/acpi_video0 to get registered and then
radeon would register its own radeon_bl# device later. After which
the drivers/acpi/video_detect.c code unregistered the acpi_video0 device
to avoid there b
Typically the acpi_video driver will initialize before amdgpu, which
used to cause /sys/class/backlight/acpi_video0 to get registered and then
amdgpu would register its own amdgpu_bl# device later. After which
the drivers/acpi/video_detect.c code unregistered the acpi_video0 device
to avoid there b
Typically the acpi_video driver will initialize before nouveau, which
used to cause /sys/class/backlight/acpi_video0 to get registered and then
nouveau would register its own nv_backlight device later. After which
the drivers/acpi/video_detect.c code unregistered the acpi_video0 device
to avoid the
Remove the code to unregister acpi_video backlight devices when
a native backlight device gets registered later.
Now that the acpi_video backlight device registration is a separate step
which runs later, after the drm/kms driver is done setting up its own
native backlight device, it is no longer n
On machins without an i915 opregion the acpi_video driver immediately
probes the ACPI video bus and used to also immediately register
acpi_video# backlight devices when supported.
Once the drm/kms driver then loaded later and possibly registered
a native backlight device then the drivers/acpi/vide
On x86/ACPI boards the acpi_video driver will usually initializing before
the kms driver (except i915). This causes /sys/class/backlight/acpi_video0
to show up and then the kms driver registers its own native backlight
device after which the drivers/acpi/video_detect.c code unregisters
the acpi_vid
When acpi_video_register() has not run yet the video_bus_head will be
empty, so there is no need to check the register_count flag first.
Signed-off-by: Hans de Goede
---
drivers/acpi/acpi_video.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/acpi/acpi_v
Move the list_del removing an acpi_video_bus from video_bus_head
on teardown to before the teardown is done, to avoid code iterating
over the video_bus_head list seeing acpi_video_bus objects on there
which are (partly) torn down already.
Signed-off-by: Hans de Goede
---
drivers/acpi/acpi_video.
Before this commit when we want userspace to use the acpi_video backlight
device we register both the GPU's native backlight device and acpi_video's
firmware acpi_video# backlight device. This relies on userspace preferring
firmware type backlight devices over native ones.
Registering 2 backlight
Now that all kms drivers which register native/BACKLIGHT_RAW type backlight
devices on x86/ACPI boards call acpi_video_get_backlight_type(true), with
the native=true value getting cached, there no longer is a need to call
backlight_device_get_by_type(BACKLIGHT_RAW) to see if a native backlight
devi
Before this commit when we want userspace to use the acpi_video backlight
device we register both the GPU's native backlight device and acpi_video's
firmware acpi_video# backlight device. This relies on userspace preferring
firmware type backlight devices over native ones.
Registering 2 backlight
Before this commit when we want userspace to use the acpi_video backlight
device we register both the GPU's native backlight device and acpi_video's
firmware acpi_video# backlight device. This relies on userspace preferring
firmware type backlight devices over native ones.
Registering 2 backlight
ATM on x86 laptops where we want userspace to use the acpi_video backlight
device we often register both the GPU's native backlight device and
acpi_video's firmware acpi_video# backlight device. This relies on
userspace preferring firmware type backlight devices over native ones, but
registering 2
Before this commit when we want userspace to use the acpi_video backlight
device we register both the GPU's native backlight device and acpi_video's
firmware acpi_video# backlight device. This relies on userspace preferring
firmware type backlight devices over native ones.
Registering 2 backlight
Hi All,
As mentioned in my RFC titled "drm/kms: control display brightness through
drm_connector properties":
https://lore.kernel.org/dri-devel/0d188965-d809-81b5-74ce-7d30c49fe...@redhat.com/
The first step towards this is to deal with some existing technical debt
in backlight handling on x86/AC
As with EU masks, it's easier to store subslice/DSS masks internally in
a format that's more natural for the driver to work with, and then only
covert into the u8[] uapi form when the query ioctl is invoked. Since
the hardware design changed significantly with Xe_HP, we'll use a union
to choose be
On 17/05/2022 16:50, Neal Liu wrote:
>> -Original Message-
>> From: Krzysztof Kozlowski
>> Sent: Tuesday, May 17, 2022 8:00 PM
>> To: Neal Liu ; Greg Kroah-Hartman
>> ; Rob Herring ; Krzysztof
>> Kozlowski ; Joel Stanley ;
>> Andrew Jeffery ; Felipe Balbi ; Sumit
>> Semwal ; Christian Köni
On 5/17/22 17:13, Andrey Grodzovsky wrote:
> Done.
>
> Andrey
Awesome, thank you!
--
Best regards,
Dmitry
Done.
Andrey
On 2022-05-17 10:03, Andrey Grodzovsky wrote:
Let me push it into drm-misc-next.
Andrey
On 2022-05-17 05:03, Dmitry Osipenko wrote:
On 5/17/22 10:40, Erico Nunes wrote:
On Wed, Apr 13, 2022 at 12:05 PM Steven Price
wrote:
On 11/04/2022 23:15, Dmitry Osipenko wrote:
Interrupt
Let me push it into drm-misc-next.
Andrey
On 2022-05-17 05:03, Dmitry Osipenko wrote:
On 5/17/22 10:40, Erico Nunes wrote:
On Wed, Apr 13, 2022 at 12:05 PM Steven Price wrote:
On 11/04/2022 23:15, Dmitry Osipenko wrote:
Interrupt context can't sleep. Drivers like Panfrost and MSM are takin
On Mon, 9 May 2022 at 16:41, Marek Vasut wrote:
>
> On 5/9/22 15:52, Geert Uytterhoeven wrote:
> > The Freescale i.MX8MP LDB bridge is only present on Freescale i.MX8MP
> > SoCs. Hence add a dependency on ARCH_MXC, to prevent asking the user
> > about this driver when configuring a kernel without
On 17/05/2022 11:52, Matthew Auld wrote:
Add an entry for the new uapi needed for small BAR on DG2+.
v2:
- Some spelling fixes and other small tweaks. (Akeem & Thomas)
- Rework error capture interactions, including no longer needing
NEEDS_CPU_ACCESS for objects marked for capture. (
On 17/05/2022 10:12, Matthew Auld wrote:
On 17/05/2022 09:29, Tvrtko Ursulin wrote:
On 16/05/2022 19:11, Matthew Auld wrote:
Add an entry for the new uapi needed for small BAR on DG2+.
v2:
- Some spelling fixes and other small tweaks. (Akeem & Thomas)
- Rework error capture interactio
On 17/05/2022 10:39, Lionel Landwerlin wrote:
On 17/05/2022 12:23, Tvrtko Ursulin wrote:
On 17/05/2022 09:55, Lionel Landwerlin wrote:
On 17/05/2022 11:29, Tvrtko Ursulin wrote:
On 16/05/2022 19:11, Matthew Auld wrote:
Add an entry for the new uapi needed for small BAR on DG2+.
v2:
-
On 17/05/2022 10:38, Mikko Perttunen wrote:
>>>
>>> + host1x@13e0 {
>>
>> Generic node names, if that possible. Since the bindings do not exist in
>> the next, I actually cannot figure out what's host1x...
>
> Host1x is a hardware block that provides programmable DMA channels, HW
On Mon, 16 May 2022 18:28:25 +0200, Max Krummenacher wrote:
> From: Max Krummenacher
>
> The property is used to set the enum bus_format and infer the bpc
> for a panel defined by 'panel-dpi'.
> This specifies how the panel is connected to the display interface.
>
> Signed-off-by: Max Krummenach
On 17/05/2022 10:25, Neal Liu wrote:
> +
> + interrupts:
> +maxItems: 1
> +
> +required:
> + - compatible
> + - reg
> + - clocks
> + - interrupts
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +#include
> +usb: usb@1e6a2000 {
> +compatible = "aspeed,ast
On 17/05/2022 10:25, Neal Liu wrote:
> Add USB2.0 device controller(udc) node to device tree
> for AST2600.
>
> Signed-off-by: Neal Liu
> ---
> arch/arm/boot/dts/aspeed-g6.dtsi | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/arch/arm/boot/dts/aspeed-g6.dtsi
> b/arch/arm/bo
Am 17.05.22 um 13:33 schrieb Thomas Zimmermann:
Some DRM helpers assume that all potential color planes of a framebuffer
are available; even if the color format didn't specify them. Non-existing
planes are silently ignored. This behavior is inconsistent with other
helpers and apparently leads to
Warn if callers of drm_gem_fb_get_obj() try to use a GEM buffer for
a non-existing or unset plane.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Javier Martinez Canillas
Tested-by: Noralf Trønnes
---
drivers/gpu/drm/drm_gem_framebuffer_helper.c | 6 +-
1 file changed, 5 insertions(+), 1 de
The error-recovery code in drm_gem_fb_begin() is of the same pattern
as drm_gem_fb_end(). Implement both of them using an internal helper.
No functional changes.
v2:
* print additional information in error message (Javier)
* fix commit description (Javier)
Signed-off-by: Thomas Zi
Only handle color planes that exist in a framebuffer's color format.
Ignore non-existing planes.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Javier Martinez Canillas
Tested-by: Noralf Trønnes
---
drivers/gpu/drm/drm_gem_vram_helper.c | 19 ---
1 file changed, 12 insertions(+)
Only handle color planes that exist in a framebuffer's color format.
Ignore non-existing planes.
So far, several helpers assumed that all 4 planes are available and
silently ignored non-existing planes. This lead to subtil bugs with
uninitialized data in instances of struct iosys_map. [1]
Signed-
Some DRM helpers assume that all potential color planes of a framebuffer
are available; even if the color format didn't specify them. Non-existing
planes are silently ignored. This behavior is inconsistent with other
helpers and apparently leads to subtle bugs with uninitialized GEM buffer
mappings
The error-recovery code in drm_gem_vram_plane_helper_prepare_fb() is of
the same pattern as drm_gem_vram_plane_helper_cleanup_fb(). Implement
both of them using an internal helper. No functional changes.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_gem_vram_helper.c | 37
Hi All,
I just noticed the below lockdep possible deadlock report with a 5.18-rc6
kernel on a Dell Latitude E6430 laptop with the following nvidia GPU:
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GF108GLM [NVS
5200M] [10de:0dfc] (rev a1)
01:00.1 Audio device [0403]: NVIDIA Corpo
Add an entry for the new uapi needed for small BAR on DG2+.
v2:
- Some spelling fixes and other small tweaks. (Akeem & Thomas)
- Rework error capture interactions, including no longer needing
NEEDS_CPU_ACCESS for objects marked for capture. (Thomas)
- Add probed_cpu_visible_size. (Lionel
On 15/05/2022 00:45, Chun-Kuang Hu wrote:
Hi, Matthias:
Matthias Brugger 於 2022年5月13日 週五 下午3:42寫道：
Hi Chun-Kuang,
On 02/05/2022 00:54, Chun-Kuang Hu wrote:
Hi, Matthias:
Matthias Brugger 於 2022年4月22日 週五 下午8:42寫道：
On 19/04/2022 11:41, jason-jh.lin wrote:
After mmsys and drm change
Am 09.05.22 um 16:10 schrieb Daniel Vetter:
On Mon, May 09, 2022 at 08:56:41AM +0200, Christian König wrote:
Am 04.05.22 um 12:08 schrieb Daniel Vetter:
On Mon, May 02, 2022 at 06:37:07PM +0200, Christian König wrote:
Hello everyone,
it's a well known problem that the DMA-buf subsystem mixed
Hi
Am 16.05.22 um 15:34 schrieb Javier Martinez Canillas:
On 5/9/22 10:16, Thomas Zimmermann wrote:
Only handle color planes that exist in a framebuffer's color format.
Ignore non-existing planes.
Signed-off-by: Thomas Zimmermann
---
Reviewed-by: Javier Martinez Canillas
@@ -673,7 +679,1
Hi Javier
Am 16.05.22 um 15:00 schrieb Javier Martinez Canillas:
Hello Thomas,
On 5/9/22 10:15, Thomas Zimmermann wrote:
The error-recovery code in drm_gem_fb_begin() is the same pattern
as drm_gem_fb_end(). Implement both this an internal helper. No
Maybe "both of these using using an" or s
On Mon, May 02, 2022 at 09:53:13AM -0700, Bjorn Andersson wrote:
> In some implementations, such as the Qualcomm platforms, the display
> driver has no way to query the current HPD state and as such it's
> impossible to distinguish between disconnect and attention events.
>
> Add a parameter to dr
On 17/05/2022 12:23, Tvrtko Ursulin wrote:
On 17/05/2022 09:55, Lionel Landwerlin wrote:
On 17/05/2022 11:29, Tvrtko Ursulin wrote:
On 16/05/2022 19:11, Matthew Auld wrote:
Add an entry for the new uapi needed for small BAR on DG2+.
v2:
- Some spelling fixes and other small tweaks. (Akee
On 5/17/22 11:18 AM, Neil Armstrong wrote:
On 17/05/2022 10:16, Tomeu Vizoso wrote:
And use it to store expectations about what the DRM drivers are
supposed to pass in the IGT test suite.
Also include a configuration file that points to the out-of-tree CI
scripts.
By storing the test expectati
On 17/05/2022 09:55, Lionel Landwerlin wrote:
On 17/05/2022 11:29, Tvrtko Ursulin wrote:
On 16/05/2022 19:11, Matthew Auld wrote:
Add an entry for the new uapi needed for small BAR on DG2+.
v2:
- Some spelling fixes and other small tweaks. (Akeem & Thomas)
- Rework error capture inter
On 17/05/2022 10:16, Tomeu Vizoso wrote:
And use it to store expectations about what the DRM drivers are
supposed to pass in the IGT test suite.
Also include a configuration file that points to the out-of-tree CI
scripts.
By storing the test expectations along the code we can make sure both
sta
On 17/05/2022 09:29, Tvrtko Ursulin wrote:
On 16/05/2022 19:11, Matthew Auld wrote:
Add an entry for the new uapi needed for small BAR on DG2+.
v2:
- Some spelling fixes and other small tweaks. (Akeem & Thomas)
- Rework error capture interactions, including no longer needing
NEEDS_C
Am Dienstag, 17. Mai 2022, 11:02:06 CEST schrieb Krzysztof Kozlowski:
> On 14/05/2022 00:26, Heiko Stuebner wrote:
> > Hi Rob, Krzysztof,
> >
> > Am Mittwoch, 11. Mai 2022, 10:21:07 CEST schrieb Sascha Hauer:
> >> The VOP2 driver relies on reg-names properties, but these are not
> >> documented. A
On 5/17/22 10:40, Erico Nunes wrote:
> On Wed, Apr 13, 2022 at 12:05 PM Steven Price wrote:
>>
>> On 11/04/2022 23:15, Dmitry Osipenko wrote:
>>> Interrupt context can't sleep. Drivers like Panfrost and MSM are taking
>>> mutex when job is released, and thus, that code can sleep. This results
>>>
On 14/05/2022 00:26, Heiko Stuebner wrote:
> Hi Rob, Krzysztof,
>
> Am Mittwoch, 11. Mai 2022, 10:21:07 CEST schrieb Sascha Hauer:
>> The VOP2 driver relies on reg-names properties, but these are not
>> documented. Add the missing documentation, make reg-names mandatory
>> and increase minItems to
On 17/05/2022 11:29, Tvrtko Ursulin wrote:
On 16/05/2022 19:11, Matthew Auld wrote:
Add an entry for the new uapi needed for small BAR on DG2+.
v2:
- Some spelling fixes and other small tweaks. (Akeem & Thomas)
- Rework error capture interactions, including no longer needing
NEEDS_C
On 5/17/22 11:43, Krzysztof Kozlowski wrote:
On 17/05/2022 10:41, Mikko Perttunen wrote:
On 5/17/22 11:02, Krzysztof Kozlowski wrote:
On 16/05/2022 12:02, cyn...@kapsi.fi wrote:
From: Mikko Perttunen
Add clock, memory controller, powergate and reset dt-binding headers
for Host1x and VIC on T
On 5/16/22 19:33, Rob Herring wrote:
On Mon, May 16, 2022 at 01:02:01PM +0300, cyn...@kapsi.fi wrote:
From: Mikko Perttunen
Update VIC and Host1x bindings for changes in Tegra234.
Namely,
- New compatible strings
- Sharded syncpoint interrupts
- Optional reset.
Signed-off-by: Mikko Perttunen
On 17/05/2022 10:41, Mikko Perttunen wrote:
> On 5/17/22 11:02, Krzysztof Kozlowski wrote:
>> On 16/05/2022 12:02, cyn...@kapsi.fi wrote:
>>> From: Mikko Perttunen
>>>
>>> Add clock, memory controller, powergate and reset dt-binding headers
>>> for Host1x and VIC on Tegra234.
>>>
>>> Signed-off-by
On 5/17/22 11:02, Krzysztof Kozlowski wrote:
On 16/05/2022 12:02, cyn...@kapsi.fi wrote:
From: Mikko Perttunen
Add clock, memory controller, powergate and reset dt-binding headers
for Host1x and VIC on Tegra234.
Signed-off-by: Mikko Perttunen
All your patches are send from wrong email addr
On 5/17/22 11:01, Krzysztof Kozlowski wrote:
On 16/05/2022 12:02, cyn...@kapsi.fi wrote:
From: Mikko Perttunen
Add device tree nodes for Host1x and VIC on Tegra234.
Signed-off-by: Mikko Perttunen
---
arch/arm64/boot/dts/nvidia/tegra234.dtsi | 46
1 file changed, 4
On 16/05/2022 19:11, Matthew Auld wrote:
Add an entry for the new uapi needed for small BAR on DG2+.
v2:
- Some spelling fixes and other small tweaks. (Akeem & Thomas)
- Rework error capture interactions, including no longer needing
NEEDS_CPU_ACCESS for objects marked for capture. (
Quoting Kuogee Hsieh (2022-05-12 12:43:18)
> diff --git a/drivers/gpu/drm/msm/dp/dp_ctrl.c
> b/drivers/gpu/drm/msm/dp/dp_ctrl.c
> index af7a80c..f3e333e 100644
> --- a/drivers/gpu/drm/msm/dp/dp_ctrl.c
> +++ b/drivers/gpu/drm/msm/dp/dp_ctrl.c
> @@ -1389,8 +1389,13 @@ void dp_ctrl_reset_irq_ctrl(str
And use it to store expectations about what the DRM drivers are
supposed to pass in the IGT test suite.
Also include a configuration file that points to the out-of-tree CI
scripts.
By storing the test expectations along the code we can make sure both
stay in sync with each other, and so we can kn
On 16/05/2022 12:02, cyn...@kapsi.fi wrote:
> From: Mikko Perttunen
>
> Add clock, memory controller, powergate and reset dt-binding headers
> for Host1x and VIC on Tegra234.
>
> Signed-off-by: Mikko Perttunen
All your patches are send from wrong email address and the SoB chain is
not correct.
On 16/05/2022 12:02, cyn...@kapsi.fi wrote:
> From: Mikko Perttunen
>
> Add device tree nodes for Host1x and VIC on Tegra234.
>
> Signed-off-by: Mikko Perttunen
> ---
> arch/arm64/boot/dts/nvidia/tegra234.dtsi | 46
> 1 file changed, 46 insertions(+)
>
> diff --git a/
On Tue, 10 May 2022, Mark Yacoub wrote:
> [Why]
> User space might need to inject data into the kernel without allowing it
> to be read again by any user space.
> An example of where this is particularly useful is secret keys fetched
> by user space and injected into the kernel to enable content p
On Tue, 10 May 2022, Mark Yacoub wrote:
> [Why]
> If a connector property is attached but
> drm_atomic_connector_get_property doesn't handle a case for it,
> modeteset will crash with a segfault without.
>
> [How]
> Add a debug message indicating that a connector property is not handled
> when use
On Wed, Apr 13, 2022 at 12:05 PM Steven Price wrote:
>
> On 11/04/2022 23:15, Dmitry Osipenko wrote:
> > Interrupt context can't sleep. Drivers like Panfrost and MSM are taking
> > mutex when job is released, and thus, that code can sleep. This results
> > into "BUG: scheduling while atomic" if lo
Hi,
On 16/05/2022 22:22, Randy Dunlap wrote:
On 5/16/22 03:57, Stephen Rothwell wrote:
Hi all,
Changes since 20220513:
on i386:
CC drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.o
../drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c: In function ‘act_freq_mhz_show’:
../drivers/gpu/drm/i91
On 16/05/2022 21:37, Martin Jücker wrote:
> Add the Samsung LTL101AL01 WXGA LCD panel to the list.
>
> Signed-off-by: Martin Jücker
> ---
> .../devicetree/bindings/display/panel/panel-simple.yaml | 2 ++
Acked-by: Krzysztof Kozlowski
Best regards,
Krzysztof
This function sets the vrr_enabled property for crtc based
on the platform support and the request from userspace.
V2: Check for platform support before updating the prop.
V3: Don't attach vrr_enabled prop, as it is alreay attached.
Cc: Ville Syrjälä
Cc: Manasi Navare
Signed-off-by: Bhanuprakas
Modern display hardware is capable of supporting variable refresh rates.
This patch introduces helpers to attach and set "vrr_enabled" property
on the crtc to allow userspace to query VRR enabled status on that crtc.
Atomic drivers should attach this property to crtcs those are capable of
driving
This series will add a support to set the vrr_enabled property for
crtc based on the platform support and the request from userspace.
And userspace can also query to get the status of "vrr_enabled".
Test-with: 20220422075223.2792586-2-bhanuprakash.mo...@intel.com
Bhanuprakash Modem (2):
drm/vrr
1 - 100 of 102 matches
Mail list logo
