On Thu, 07 Mar 2024, Randy Dunlap wrote:
> On 3/7/24 18:51, R SUNDAR wrote:
>> For linux-next repo
>>
>> /include/drm/display/drm_dp_mst_helper.h:156: warning: Excess struct member
>> 'vcpi' description in 'drm_dp_mst_port'
>>
>> Signed-off-by: R SUNDAR
>
> or
> https://lore.kernel.org/lkml/20
> On 7 Mar 2024, at 15.28, Frieder Schrempf wrote:
>
> On 07.03.24 09:09, Sean Nyekjaer wrote:
>> Hi,
>>
>> We are using the stm32mp1 together with the sn65dsi83 bridge.
>> The ti,sn65dsi83 driver is (hard) enabling MIPI_DSI_MODE_VIDEO_BURST, then
>> the st,stm32-dsi driver is adding +20% to
Patches are tested on AMD platform.
Repeated stress test on Unigine Heaven, memory full (VRAM + GTT + system
SWAP), then free.
No errors/warning in kernel log.
Any suggestion specific tests?
Regards,
S.Amarnath
On 3/6/2024 12:31 PM, Thomas Hellström wrote:
This patch-set is a prerequisite for
Hi Luca,
Am Mittwoch, 6. März 2024, 13:39:20 CET schrieb Luca Ceresoli:
> This reverts commit 8a91b29f1f50ce7742cdbe5cf11d17f128511f3f.
>
> The regulator_disable() added by the original commit solves one kind of
> regulator imbalance but adds another one as it allows the regulator to be
> disable
https://bugzilla.kernel.org/show_bug.cgi?id=218569
--- Comment #2 from Emre (ereno...@gmail.com) ---
OK, I don't have windows on this laptop. I can try another windows laptop but
that has thunderbolt and I dont know if behavior would be the same in windows.
I had an impression this was sth to do
On 3/7/2024 11:23 AM, Mitul Golani wrote:
Add read/write calls for Adaptive Sync SDP.
Signed-off-by: Mitul Golani
---
drivers/gpu/drm/i915/display/intel_ddi.c | 1 +
drivers/gpu/drm/i915/display/intel_dp.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/display
On 3/7/2024 11:23 AM, Mitul Golani wrote:
Compute vrr_vsync_start/end, which sets the position
for hardware to send the Vsync at a fixed position
relative to the end of the Vblank.
--v2:
- Updated VSYNC_START/END macros to VRR_VSYNC_START/END. (Ankit)
- Updated bit fields of VRR_VSYNC_START/EN
On 3/7/2024 11:23 AM, Mitul Golani wrote:
Add the necessary structures and functions to handle reading and
unpacking Adaptive Sync Secondary Data Packets. Also add support
to write and pack AS SDP.
--v2:
- Correct use of REG_BIT and REG_GENMASK. [Jani]
- Use as_sdp instead of async. [Jani]
- R
On 3/7/24 18:51, R SUNDAR wrote:
> For linux-next repo
>
> /include/drm/display/drm_dp_mst_helper.h:156: warning: Excess struct member
> 'vcpi' description in 'drm_dp_mst_port'
>
> Signed-off-by: R SUNDAR
or
https://lore.kernel.org/lkml/20240106032321.28596-1-rdun...@infradead.org/
but I w
On 2024-03-04 18:01, Mina Almasry wrote:
> From: Jakub Kicinski
>
> The page providers which try to reuse the same pages will
> need to hold onto the ref, even if page gets released from
> the pool - as in releasing the page from the pp just transfers
> the "ownership" reference from pp to the pr
Hello all,
Since I didn't get a reply for this one, I assume below are agreed. But feel
free to let us know if you don't agree.
Thanks,
Oak
-Original Message-
From: dri-devel On Behalf Of Zeng, Oak
Sent: Thursday, February 29, 2024 1:23 PM
To: Christian König ; Daniel Vetter
; David A
On Mon, 4 Mar 2024 18:01:40 -0800 Mina Almasry wrote:
> + if (!dev || !dev->netdev_ops)
> + return -EINVAL;
too defensive
> + if (!dev->netdev_ops->ndo_queue_stop ||
> + !dev->netdev_ops->ndo_queue_mem_free ||
> + !dev->netdev_ops->ndo_queue_mem_alloc ||
> +
Hi Linus,
not sure if -final is correct but guess I'll find out if it should
have said rc8.
Regular fixes (two weeks for i915), scattered across drivers, amdgpu
and i915 being the main ones, with nouveau having a couple of fixes.
One patch got applied for udl, but reverted soon after as the
maint
On Thu, 7 Mar 2024 18:08:24 -0800 Mina Almasry wrote:
> On Thu, Mar 7, 2024 at 5:30 PM Jakub Kicinski wrote:
> > On Mon, 4 Mar 2024 18:01:36 -0800 Mina Almasry wrote:
> > > + * void *(*ndo_queue_mem_alloc)(struct net_device *dev, int idx);
> > > + * Allocate memory for an RX queue. The memory
For linux-next repo
./include/drm/display/drm_dp_mst_helper.h:156: warning: Excess struct member
'vcpi' description in 'drm_dp_mst_port'
Signed-off-by: R SUNDAR
---
include/drm/display/drm_dp_mst_helper.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/include/drm/display/drm_dp_mst_helper.
On Thu, Mar 7, 2024 at 5:30 PM Jakub Kicinski wrote:
>
> On Mon, 4 Mar 2024 18:01:36 -0800 Mina Almasry wrote:
> > + * void *(*ndo_queue_mem_alloc)(struct net_device *dev, int idx);
> > + * Allocate memory for an RX queue. The memory returned in the form of
> > + * a void * can be passed to n
From: John Harrison
An existing workaround has been extended in both platforms affected
and implementation complexity.
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/abi/guc_klvs_abi.h | 3 ++-
drivers/gpu/drm/i915/gt/uc/intel_guc.c| 3 ++-
drivers/gpu/drm/i915/gt/uc/int
On Mon, 4 Mar 2024 18:01:49 -0800 Mina Almasry wrote:
> +Intro
> +=
> +
> +Device memory TCP (devmem TCP) enables receiving data directly into device
> +memory (dmabuf). The feature is currently implemented for TCP sockets.
> +
> +
> +Opportunity
> +---
> +
> +A large amount of data tr
On Mon, 4 Mar 2024 18:01:36 -0800 Mina Almasry wrote:
> + * void *(*ndo_queue_mem_alloc)(struct net_device *dev, int idx);
> + * Allocate memory for an RX queue. The memory returned in the form of
> + * a void * can be passed to ndo_queue_mem_free() for freeing or to
> + * ndo_queue_start to
Fix OOM scenario by doing multiple notifications to the OOM handler through
a busy wait logic.
Changes from commit 5a838e5d5825 ("drm/qxl: simplify qxl_fence_wait") would
result in a '[TTM] Buffer eviction failed' exception whenever it reached a
timeout.
Fixes: 5a838e5d5825 ("drm/qxl: simplify qxl
Hi,
As initially reported by Timo in the QXL driver will crash given enough
workload:
https://lore.kernel.org/regressions/fb0fda6a-3750-4e1b-893f-97a3e402b...@leemhuis.info/
I initially came across this problem when migrating Debian VMs from Bullseye
to Bookworm. This bug will somewhat randomly but
Fixed!
Thanks a lot!
Doug Anderson 于2024年3月7日周四 22:36写道：
> Hi,
>
> On Thu, Mar 7, 2024 at 1:44 AM Xuxin Xiong
> wrote:
> >
> > Add support for the following 2 panels:
> > 1. BOE NT116WHM-N44
> > 2. CMN N116BCA-EA1
> >
> > Signed-off-by: Xuxin Xiong
> > ---
> > drivers/gpu/drm/panel/panel-edp.
Add support for the following 2 panels:
1. BOE NT116WHM-N44
2. CMN N116BCA-EA1
Signed-off-by: Xuxin Xiong
Reviewed-by: Douglas Anderson
---
Changes in V2:
- Updated the subject of commit message.
link to V1:
https://patchwork.freedesktop.org/patch/msgid/20240307094433.3440431-1-xuxinxi...@hu
Hi,
On Thu, Mar 7, 2024 at 3:07 PM Hsin-Yi Wang wrote:
>
> Create a type drm_edid_ident as the identity of an EDID. Currently it
> contains panel id and monitor name.
>
> Create a function that can match a given EDID and an identity:
> 1. Reject if the panel id doesn't match.
> 2. If name is not
Setup the HDMI connector on the MSM HDMI outputs. Make use of
atomic_check hook and of the provided Infoframe infrastructure.
Note: for now only AVI Infoframes are enabled. Audio Infoframes are
currenly handled separately. This will be fixed for the final version.
Signed-off-by: Dmitry Baryshkov
Change MSM HDMI bridge to use atomic_* callbacks in preparation to
enablign the HDMI connector support.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/hdmi/hdmi_bridge.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/msm/hdmi/hdmi_bridg
Gate only HDMI Vendor Infoframe generation on the
info->has_hdmi_infoframe. All other infoframes were defined in earlier
HDMI specs and should be generated by default.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/drm_atomic_state_helper.c | 25 ++---
1 file changed, 10
m/msm/hdmi/hdmi_bridge.c| 120 +-
include/drm/drm_bridge.h | 15
include/drm/drm_connector.h | 10 +++
7 files changed, 230 insertions(+), 53 deletions(-)
---
base-commit: 47dc3e3d3051709acd01143e21d2de2b5322336c
change-id: 20240307-b
HDMI bridge drivers need to store private data pointer to be used from
drm_connector_hdmi_funcs::write_infoframes() and clear_infoframes()
callbacks. Add it to the drm_connector.hdmi structure.
Signed-off-by: Dmitry Baryshkov
---
include/drm/drm_connector.h | 5 +
1 file changed, 5 insertion
In order to use HDMI connector extensions from the bridge drivers, carve
out the drm_connector_hdmi_setup() from drmm_connector_hdmi_init(). This
way the drm_bridge drivers can call new function from their
setup_connector callbacks.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/drm_connect
Add a callback to be called by the drivers when the drm_connector is
created at the end of the drm_bridge chain. This allows bridges to
perform additional setup, like setting up the HDMI connector properties.
Note, for now only drm_bridge_connector uses this callback.
Signed-off-by: Dmitry Barysh
Hi John,
...
> > > > +
> > > > + /*
> > > > +* Wa_14019159160: disable the automatic CCS load
> > > > balancing
> > > I'm still a bit concerned that this doesn't really match what this
> > > specific workaround is asking us to do. There seems to be an agreement
> >
Hi Matt,
> > +static void intel_gt_apply_ccs_mode(struct intel_gt *gt)
> > +{
> > + u32 mode;
> > + int cslice;
> > +
> > + if (!IS_DG2(gt->i915))
> > + return;
> > +
> > + /* Set '0' as a default CCS id to all the cslices */
> > + mode = 0;
> > +
> > + for (cslice = 0; cslic
Create a type drm_edid_ident as the identity of an EDID. Currently it
contains panel id and monitor name.
Create a function that can match a given EDID and an identity:
1. Reject if the panel id doesn't match.
2. If name is not null in identity, try to match it in the detailed timing
blocks. No
It's found that some panels have variants that they share the same panel id
although their EDID and names are different. When matching generic edp
panels, we should first match with both panel identity, which contains both
panel id and panel name. If not found, match with panel id only.
Signed-off
There are 2 different AUO panels using the same panel id. One of the
variants requires using overridden modes to resolve glitching issue as
described in commit 70e0d5550f5c ("drm/panel-edp: Add auo_b116xa3_mode").
Other variants should use the modes parsed from EDID.
Signed-off-by: Hsin-Yi Wang
R
Currently edid quirks are matched by panel id only.
Modify it to match with identity so it's easier to be extended
for more complex matching if required.
Signed-off-by: Hsin-Yi Wang
Reviewed-by: Jani Nikula
Reviewed-by: Douglas Anderson
---
drivers/gpu/drm/drm_edid.c | 13 -
1 fil
It's found that some panels have variants that they share the same panel id
although their EDID and names are different. Besides panel id, now we need
more information from the EDID base block to distinguish these panel
variants.
Add drm_edid_read_base_block() to return the EDID base block, which
This series is a follow up for 1a5e81de180e ("Revert "drm/panel-edp: Add
auo_b116xa3_mode""). It's found that 2 different AUO panels use the same
product id. One of them requires an overridden mode, while the other should
use the mode directly from edid.
Match the panel for identity (id and name).
On Thu, 07 Mar 2024, Hsin-Yi Wang wrote:
> On Thu, Mar 7, 2024 at 5:20 AM Jani Nikula
> wrote:
>>
>> On Wed, 06 Mar 2024, Doug Anderson wrote:
>> > Hi,
>> >
>> > On Wed, Mar 6, 2024 at 4:20 PM Hsin-Yi Wang wrote:
>> >>
>> >> On Wed, Mar 6, 2024 at 3:30 PM Doug Anderson
>> >> wrote:
>> >> >
>
On Thu, 07 Mar 2024, Doug Anderson wrote:
> On Thu, Mar 7, 2024 at 12:28 PM Jani Nikula
> wrote:
>> If there's one thing that's for sure, EDIDs are full of stuff like this,
>> across the board.
>>
>> Ignoring the whitespace at the end seemed reasonable, initially, to me
>> too. But the question
On Thu, 7 Mar 2024 at 15:39, Maxime Ripard wrote:
>
> Infoframes in KMS is usually handled by a bunch of low-level helpers
> that require quite some boilerplate for drivers. This leads to
> discrepancies with how drivers generate them, and which are actually
> sent.
>
> Now that we have everything
Hi,
On Thu, Mar 7, 2024 at 12:28 PM Jani Nikula wrote:
>
> On Thu, 07 Mar 2024, Hsin-Yi Wang wrote:
> > On Thu, Mar 7, 2024 at 5:28 AM Jani Nikula
> > wrote:
> >>
> >> On Wed, 06 Mar 2024, Doug Anderson wrote:
> >> > Hi,
> >> >
> >> > On Wed, Mar 6, 2024 at 12:04 PM Hsin-Yi Wang wrote:
> >>
On Thu, Feb 29, 2024 at 10:06:02PM -0600, Lucas De Marchi wrote:
On Thu, Feb 29, 2024 at 08:27:30PM +0200, Andy Shevchenko wrote:
On Thu, Feb 29, 2024 at 12:21:34PM -0600, Lucas De Marchi wrote:
On Thu, Feb 29, 2024 at 12:49:57PM +0200, Andy Shevchenko wrote:
On Wed, Feb 28, 2024 at 05:39:21PM
On Thu, 7 Mar 2024 at 15:39, Maxime Ripard wrote:
>
> Infoframes in KMS is usually handled by a bunch of low-level helpers
> that require quite some boilerplate for drivers. This leads to
> discrepancies with how drivers generate them, and which are actually
> sent.
>
> Now that we have everything
From: Alexey Makhalov
Switch from VMWARE_HYPERCALL macro to vmware_hypercall API.
Eliminate arch specific code. No functional changes intended.
Signed-off-by: Alexey Makhalov
Reviewed-by: Nadav Amit
Reviewed-by: Zack Rusin
Acked-by: Dmitry Torokhov
---
drivers/input/mouse/vmmouse.c | 78 +++
From: Alexey Makhalov
Switch from VMWARE_HYPERCALL macro to vmware_hypercall API.
Eliminate arch specific code.
drivers/gpu/drm/vmwgfx/vmwgfx_msg_arm64.h: implement arm64 variant
of vmware_hypercall. And keep it here until introduction of ARM64
VMWare hypervisor interface.
Signed-off-by: Alexey
From: Alexey Makhalov
VMware hypercalls use I/O port, VMCALL or VMMCALL instructions.
Add __tdx_hypercall path to support TDX guests.
No change in high bandwidth hypercalls, as only low bandwidth
ones are supported for TDX guests.
Co-developed-by: Tim Merrifield
Signed-off-by: Tim Merrifield
From: Alexey Makhalov
No more direct use of VMWARE_HYPERCALL macro should be allowed.
Signed-off-by: Alexey Makhalov
---
arch/x86/include/asm/vmware.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/x86/include/asm/vmware.h b/arch/x86/include/asm/vmware.h
index 2ac87068184a..84a31f579
From: Alexey Makhalov
Switch from VMWARE_HYPERCALL macro to vmware_hypercall API.
Eliminate arch specific code. No functional changes intended.
Signed-off-by: Alexey Makhalov
Reviewed-by: Nadav Amit
Reviewed-by: Jeff Sipek
---
drivers/ptp/ptp_vmw.c | 14 +++---
1 file changed, 3 inse
From: Alexey Makhalov
Introduce vmware_hypercall family of functions. It is a common
implementation to be used by the VMware guest code and virtual
device drivers in architecture independent manner.
The API consists of vmware_hypercallX and vmware_hypercall_hb_{out,in}
set of functions by analog
From: Alexey Makhalov
Move VMware hypercall macros to vmware.h. This is a prerequisite for
the introduction of vmware_hypercall API. No functional changes besides
exporting vmware_hypercall_mode symbol.
Signed-off-by: Alexey Makhalov
Reviewed-by: Nadav Amit
---
arch/x86/include/asm/vmware.h |
VMware hypercalls invocations were all spread out across the kernel
implementing same ABI as in-place asm-inline. With encrypted memory
and confidential computing it became harder to maintain every changes
in these hypercall implementations.
Intention of this patchset is to introduce arch independ
On 2024/3/8 05:09, Sui Jingfeng wrote:
a most experienced
A most experienced programmer & developer.
Hi,
On 2024/3/8 04:40, Dmitry Baryshkov wrote:
But really, there is nothing so hard about it:
- Change of_node to fw_node, apply an automatic patch changing this in
bridge drivers.
- Make drm_of_bridge functions convert passed of_node and comp
After this we can start cleaning up bridge drivers
Add page fault information to the devcoredump.
Output of devcoredump:
AMDGPU Device Coredump
version: 1
kernel: 6.7.0-amd-staging-drm-next
module: amdgpu
time: 29.725011811
process_name: soft_recovery_p PID: 1720
Ring timed out details
IP Type: 0 Ring Name: gfx_0.0.0
[gfxhub] Page faul
Add support of devcoredump from global object of amdgpu_device
Sunil Khatri (2):
drm/amdgpu: add recent pagefault info in vm_manager
drm/amdgpu: add vm fault information to devcoredump
drivers/gpu/drm/amd/amdgpu/amdgpu_reset.c | 14 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
Currently page fault information is stored per
vm and which could be freed or stale during
reset. Add it pagefault information in the
vm_manager which is a global space for vm's
and remains valid across.
Signed-off-by: Sunil Khatri
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 8
drivers
On Thu, 07 Mar 2024, Lucas De Marchi wrote:
> On Wed, Mar 06, 2024 at 08:31:22PM +0200, Jani Nikula wrote:
>>Make documentation match code.
>>
>>Signed-off-by: Jani Nikula
>>---
>> include/drm/i915_pxp_tee_interface.h | 19 ---
>> 1 file changed, 12 insertions(+), 7 deletions(-)
>>
On Thu, 07 Mar 2024, Jani Nikula wrote:
> Switch to drm device based logging and WARNs, and unify connector and
> crtc logging formats. Pass drm device around a bit more to be able to do
> this.
Forgot to mention that I also stop logging about -ENOMEM, instead of
converting that over to drm devic
On Thu, Mar 7, 2024 at 3:42 PM Khatri, Sunil wrote:
>
>
> On 3/8/2024 12:44 AM, Alex Deucher wrote:
> > On Thu, Mar 7, 2024 at 12:00 PM Sunil Khatri wrote:
> >> Add page fault information to the devcoredump.
> >>
> >> Output of devcoredump:
> >> AMDGPU Device Coredump
> >> version: 1
>
On Thu, 07 Mar 2024, Jani Nikula wrote:
> @@ -489,7 +489,6 @@ void drm_sysfs_connector_hotplug_event(struct
> drm_connector *connector)
> drm_dbg_kms(connector->dev,
> "[CONNECTOR:%d:%s] generating connector hotplug event\n",
> connector->base.id, connect
On 3/8/2024 12:44 AM, Alex Deucher wrote:
On Thu, Mar 7, 2024 at 12:00 PM Sunil Khatri wrote:
Add page fault information to the devcoredump.
Output of devcoredump:
AMDGPU Device Coredump
version: 1
kernel: 6.7.0-amd-staging-drm-next
module: amdgpu
time: 29.725011811
process_name: s
On Thu, 7 Mar 2024 at 22:32, Sui Jingfeng wrote:
>
> Hi,
>
>
> On 2024/3/8 03:37, Dmitry Baryshkov wrote:
> > On Thu, 7 Mar 2024 at 21:20, Sui Jingfeng wrote:
> >> Hi,
> >>
> >>
> >> On 2024/3/8 02:43, Dmitry Baryshkov wrote:
> +
> MODULE_AUTHOR("Ajay Kumar");
> MODULE_DESCRI
Switch to drm device based logging and WARNs, and unify connector and
crtc logging formats. Pass drm device around a bit more to be able to do
this.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_client_modeset.c | 129 +++
1 file changed, 70 insertions(+), 59 deletio
Prefer drm_dbg_kms() and drm_dbg_lease() over DRM_DEBUG_KMS() and
DRM_DEBUG() to debug log the drm device info. Fix some debug categories
and unify connector logging while at it.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_sysfs.c | 21 ++---
1 file changed, 10 insertions(
Prefer drm_err() over DRM_ERROR().
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_modes.c | 27 ++-
1 file changed, 14 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 0fff5a8d4d81..bf0f745dd9bd 100644
--- a/
Use device based debug logging for the mode via drm_printer.
This changes the output from the format:
[drm:drm_mode_debug_printmodeline] Modeline "6144x3456": 60 1378800 6144 6192
6224 6464 3456 3459 3464 3555 0x48 0x9
[drm:drm_mode_prune_invalid] Not using 6144x3456 mode: CLOCK_HIGH
to format:
Prefer drm_dbg_kms() over DRM_DEBUG_KMS() to debug log the drm device
info. Also use drm_mode_print() for drm device specific debug logging
the probed modes.
This changes the probed modes output from the format:
[drm:drm_helper_probe_single_connector_modes] [CONNECTOR:290:DP-5] probed modes
:
[d
Add a printer based function for dumping the modeline, so it's not
limited to KMS debug.
Note: The printed output intentionally does not have the "Modeline"
prefix. Prefix, if any, is for the caller to decide when initializing
drm_printer.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_mode
Switch a handful of places over to drm device based logging and WARNs,
unify connector and crtc logging, etc.
Jani Nikula (6):
drm/modes: add drm_mode_print() to dump mode in drm_printer
drm/probe-helper: switch to drm device based logging
drm/modes: switch drm_mode_prune_invalid() to use st
Hi,
On 2024/3/8 03:37, Dmitry Baryshkov wrote:
On Thu, 7 Mar 2024 at 21:20, Sui Jingfeng wrote:
Hi,
On 2024/3/8 02:43, Dmitry Baryshkov wrote:
+
MODULE_AUTHOR("Ajay Kumar");
MODULE_DESCRIPTION("DRM bridge infrastructure");
MODULE_LICENSE("GPL and additional rights");
diff --git a/
On Thu, 07 Mar 2024, Hsin-Yi Wang wrote:
> On Thu, Mar 7, 2024 at 5:28 AM Jani Nikula
> wrote:
>>
>> On Wed, 06 Mar 2024, Doug Anderson wrote:
>> > Hi,
>> >
>> > On Wed, Mar 6, 2024 at 12:04 PM Hsin-Yi Wang wrote:
>> >>
>> >> @@ -1009,6 +1009,19 @@ static const struct panel_desc auo_b101ean01
On 3/7/2024 12:02, Andi Shyti wrote:
Hi Matt,
On Wed, Mar 06, 2024 at 03:46:09PM -0800, Matt Roper wrote:
On Wed, Mar 06, 2024 at 02:22:45AM +0100, Andi Shyti wrote:
The hardware should not dynamically balance the load between CCS
engines. Wa_14019159160 recommends disabling it across all
plat
On Thu, Mar 7, 2024 at 5:28 AM Jani Nikula wrote:
>
> On Wed, 06 Mar 2024, Doug Anderson wrote:
> > Hi,
> >
> > On Wed, Mar 6, 2024 at 12:04 PM Hsin-Yi Wang wrote:
> >>
> >> @@ -1009,6 +1009,19 @@ static const struct panel_desc auo_b101ean01 = {
> >> },
> >> };
> >>
> >> +static const s
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: 1843e16d2df9d98427ef8045589571749d627cf7 Add linux-next specific
files for 20240307
Error/Warning reports:
https://lore.kernel.org/oe-kbuild-all/202403071947.nuyubx0g-...@intel.com
Error
Hi Matt,
On Wed, Mar 06, 2024 at 03:46:09PM -0800, Matt Roper wrote:
> On Wed, Mar 06, 2024 at 02:22:45AM +0100, Andi Shyti wrote:
> > The hardware should not dynamically balance the load between CCS
> > engines. Wa_14019159160 recommends disabling it across all
> > platforms.
> >
> > Fixes: d2ea
Hi,
On 2024/3/8 03:31, Dmitry Baryshkov wrote:
On Thu, 7 Mar 2024 at 19:24, Sui Jingfeng wrote:
Make this driver less DT-dependent by calling the freshly created helpers,
should be no functional changes for DT based systems. But open the door for
otherwise use cases. Even though there is no u
On Thu, 7 Mar 2024 at 21:20, Sui Jingfeng wrote:
>
> Hi,
>
>
> On 2024/3/8 02:43, Dmitry Baryshkov wrote:
> >> +
> >> MODULE_AUTHOR("Ajay Kumar");
> >> MODULE_DESCRIPTION("DRM bridge infrastructure");
> >> MODULE_LICENSE("GPL and additional rights");
> >> diff --git a/include/drm/drm_bridge.
On Thu, Mar 7, 2024 at 5:20 AM Jani Nikula wrote:
>
> On Wed, 06 Mar 2024, Doug Anderson wrote:
> > Hi,
> >
> > On Wed, Mar 6, 2024 at 4:20 PM Hsin-Yi Wang wrote:
> >>
> >> On Wed, Mar 6, 2024 at 3:30 PM Doug Anderson wrote:
> >> >
> >> > Hi,
> >> >
> >> > On Wed, Mar 6, 2024 at 12:04 PM Hsin-Y
Hello!
This is an experimental semi-automated report about issues detected by
Coverity from a scan of next-20240307 as part of the linux-next scan project:
https://scan.coverity.com/projects/linux-next-weekly-scan
You're getting this email because you were associated with the identified
lin
On Thu, 7 Mar 2024 at 19:24, Sui Jingfeng wrote:
>
> Make this driver less DT-dependent by calling the freshly created helpers,
> should be no functional changes for DT based systems. But open the door for
> otherwise use cases. Even though there is no user emerged yet, this still
> do no harms. I
On 2024/3/8 03:20, Sui Jingfeng wrote:
I think the drm_bridge should embeds 'struct device'
'struct device' -> 'struct device *'
Hi,
On 2024/3/8 02:43, Dmitry Baryshkov wrote:
+
MODULE_AUTHOR("Ajay Kumar");
MODULE_DESCRIPTION("DRM bridge infrastructure");
MODULE_LICENSE("GPL and additional rights");
diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
index 3606e1a7f965..d4c95afdd662 100644
--- a/includ
On Thu, Mar 7, 2024 at 12:00 PM Sunil Khatri wrote:
>
> Add page fault information to the devcoredump.
>
> Output of devcoredump:
> AMDGPU Device Coredump
> version: 1
> kernel: 6.7.0-amd-staging-drm-next
> module: amdgpu
> time: 29.725011811
> process_name: soft_recovery_p PID: 1720
>
>
On Thu, 7 Mar 2024 at 19:23, Sui Jingfeng wrote:
>
> Currently, the various drm bridge drivers relay on OF infrastructures to
> works very well. Yet there are platforms and/or don not has OF support.
> Such as virtual display drivers, USB display apapters and ACPI based
> systems etc. Add fwnode b
Le jeudi 29 février 2024 à 10:02 +0100, Maxime Ripard a écrit :
> Hi Helen,
>
> Thanks for working on this
>
> On Wed, Feb 28, 2024 at 07:55:25PM -0300, Helen Koike wrote:
> > This patch introduces a `.gitlab-ci` file along with a `ci/` folder,
> > defininga basic test pipeline triggered by code
On Wed, Mar 06, 2024 at 08:31:22PM +0200, Jani Nikula wrote:
Make documentation match code.
Signed-off-by: Jani Nikula
---
include/drm/i915_pxp_tee_interface.h | 19 ---
1 file changed, 12 insertions(+), 7 deletions(-)
diff --git a/include/drm/i915_pxp_tee_interface.h
b/include
Add a check to mtk_drm_gem_init if we attempt to allocate a GEM object
of 0 bytes. Currently, no such check exists and the kernel will panic if
a userspace application attempts to allocate a 0x0 GBM buffer.
Tested by attempting to allocate a 0x0 GBM buffer on an MT8188 and
verifying that we now re
On Wed, Mar 06, 2024 at 08:31:21PM +0200, Jani Nikula wrote:
Make the documentation match code.
Signed-off-by: Jani Nikula
---
include/drm/i915_hdcp_interface.h | 18 +-
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a/include/drm/i915_hdcp_interface.h
b/include/dr
On Wed, Mar 06, 2024 at 08:31:20PM +0200, Jani Nikula wrote:
There's no proper way to document function pointer members, but at least
silence the warnings.
Signed-off-by: Jani Nikula
Reviewed-by: Lucas De Marchi
Lucas De Marchi
On 07/03/2024 14:22, Jocelyn Falempe wrote:
> [...]
>
> For drm_panic, I changed the way the debugfs is calling the drm_panic
> functions in the last version:
> https://patchwork.freedesktop.org/patch/581845/?series=122244&rev=9
>
> It doesn't use the panic notifier list, but create a file for e
Make this driver less DT-dependent by calling the freshly created helpers,
should be no functional changes for DT based systems. But open the door for
otherwise use cases. Even though there is no user emerged yet, this still
do no harms. In fact, we reduce some boilerplate across drm bridge drivers
Make this driver less DT-dependent by using the fwnode helper function,
should be no functional changes for DT based systems. Do the necessary
works before it can be truely subsystem independent, even though there
is no user yet, this still do no harms.
Signed-off-by: Sui Jingfeng
---
drivers/gp
Make this driver less DT-dependent by calling the freshly created helpers,
should be no functional changes for DT based systems. But open the door for
otherwise use cases. Even though there is no user emerged yet, this still
do no harms.
Signed-off-by: Sui Jingfeng
---
drivers/gpu/drm/bridge/sim
Currently, the various drm bridge drivers relay on OF infrastructures to
works very well. Yet there are platforms and/or don not has OF support.
Such as virtual display drivers, USB display apapters and ACPI based
systems etc. Add fwnode based helpers to fill the niche, this may allows
part of the
Currently, the various drm bridge drivers relay on OF infrastructures to
works very well. Yet there are platforms and/or don not has OF support.
Such as virtual display drivers, USB display apapters and ACPI based
systems etc. Add fwnode based helpers to fill the niche, this may allows
part of the
On 05/03/2024 18:50, Guilherme G. Piccoli wrote:
On 05/03/2024 13:52, Jocelyn Falempe wrote:
[...]
Or maybe have two lists of panic notifiers, the safe and the destructive
list. So in case of fake panic, we can only call the safe notifiers.
I tried something like that:
https://lore.kernel.
Hi
Am 07.03.24 um 10:14 schrieb Jocelyn Falempe:
This is needed for drm_panic, to draw the font, and fill
the background color, in multiple color format.
As you know, I'm not happy about this patch and the the changes do not
reflect my easier review. These format helpers are supposed to serve
Hi,
On 07/03/2024 16:41, Thomas Zimmermann wrote:
Am 07.03.24 um 15:08 schrieb Thomas Zimmermann:
Hi
Am 07.03.24 um 10:14 schrieb Jocelyn Falempe:
This is needed for drm_panic, to draw the font, and fill
the background color, in multiple color format.
As you know, I'm not happy about this
1 - 100 of 215 matches
Mail list logo
