Re: [PATCH v8 6/6] drm/i915/panelreplay: Debugfs support for panel replay
On Tue, 2023-11-07 at 05:01 +, Manna, Animesh wrote:
>
>
> > -Original Message-
> > From: Hogander, Jouni
> > Sent: Monday, November 6, 2023 1:33 PM
> > To: dri-devel@lists.freedesktop.org; Manna, Animesh
> > ; intel-...@lists.freedesktop.org
> > Cc: Murthy, Arun R ; Nikula, Jani
> >
> > Subject: Re: [PATCH v8 6/6] drm/i915/panelreplay: Debugfs support
> > for
> > panel replay
> >
> > Hello Animesh,
> >
> > Thank you for the changes. Now the patch is much shorter, cleaner
> > and
> > easier to review. See my inline comments below.
> >
> > On Sat, 2023-11-04 at 02:30 +0530, Animesh Manna wrote:
> > > Add debugfs support which will print source and sink status per
> > > connector basis. Existing i915_psr_status and
> > > i915_psr_sink_status
> > > will be used to get the source and sink status of panel replay.
> > >
> > > v1: Initial version. [rb-ed by Arun]
> > > v2: Added check for DP 2.0 and connector type in
> > > connector_debugfs_add().
> > > v3: Optimization and cosmetic changes. [Jouni]
> > >
> > > Cc: Jouni Högander
> > > Cc: Arun R Murthy
> > > Cc: Jani Nikula
> > > Reviewed-by: Arun R Murthy
> > > Signed-off-by: Animesh Manna
> > > ---
> > > drivers/gpu/drm/i915/display/intel_psr.c | 93 +-
> > >
> > > --
> > > 1 file changed, 66 insertions(+), 27 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> > > b/drivers/gpu/drm/i915/display/intel_psr.c
> > > index 8ed4684b4528..8b7c03cd4989 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_psr.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> > > @@ -2813,12 +2813,19 @@ static int
> > > psr_get_status_and_error_status(struct intel_dp *intel_dp,
> > > {
> > > struct drm_dp_aux *aux = _dp->aux;
> > > int ret;
> > > + unsigned int offset;
> > >
> > > - ret = drm_dp_dpcd_readb(aux, DP_PSR_STATUS, status);
> > > + offset = intel_dp->psr.panel_replay_enabled ?
> > > + DP_SINK_DEVICE_PR_AND_FRAME_LOCK_STATUS :
> > > DP_PSR_STATUS;
> > > +
> > > + ret = drm_dp_dpcd_readb(aux, offset, status);
> > > if (ret != 1)
> > > return ret;
> > >
> > > - ret = drm_dp_dpcd_readb(aux, DP_PSR_ERROR_STATUS,
> > > error_status);
> > > + offset = intel_dp->psr.panel_replay_enabled ?
> > > + DP_PANEL_REPLAY_ERROR_STATUS :
> > > DP_PSR_ERROR_STATUS;
> > > +
> > > + ret = drm_dp_dpcd_readb(aux, offset, error_status);
> > > if (ret != 1)
> > > return ret;
> > >
> > > @@ -3039,7 +3046,7 @@ psr_source_status(struct intel_dp
> > > *intel_dp,
> > > struct seq_file *m)
> > > status = live_status[status_val];
> > > }
> > >
> > > - seq_printf(m, "Source PSR status: %s [0x%08x]\n", status,
> > > val);
> > > + seq_printf(m, "Source PSR/PanelReplay status: %s
> > > [0x%08x]\n",
> > > status, val);
> > > }
> > >
> > > static int intel_psr_status(struct seq_file *m, struct intel_dp
> > > *intel_dp)
> > > @@ -3052,18 +3059,23 @@ static int intel_psr_status(struct
> > > seq_file
> > > *m, struct intel_dp *intel_dp)
> > > bool enabled;
> > > u32 val;
> > >
> > > - seq_printf(m, "Sink support: %s", str_yes_no(psr-
> > > > sink_support));
> > > - if (psr->sink_support)
> > > + seq_printf(m, "Sink support: PSR = %s, Panel Replay =
> > > %s",
> > > + str_yes_no(psr->sink_support),
> > > + str_yes_no(psr->sink_panel_replay_support));
> > > +
> > > + if (psr->sink_support || psr->sink_panel_replay_support)
> > > seq_printf(m, " [0x%02x]", intel_dp-
> > > >psr_dpcd[0]);
> >
> > The output will look like this:
> >
> > Sink support: PSR = yes, Panel Replay = yes, [0x01]
> >
> > I think more logical would be:
> >
> > Sink support: PSR = yes [0x01], Panel Replay = yes
> >
> >
> > > seq_puts(m, "\n");
> > >
> > > - if (!psr->sink_support)
> > > + if (!(psr->sink_support || psr-
> > > >sink_panel_replay_support))
> > > return 0;
> > >
> > > wakeref = intel_runtime_pm_get(_priv->runtime_pm);
> > > mutex_lock(>lock);
> > >
> > > - if (psr->enabled)
> > > + if (psr->panel_replay_enabled)
> > > + status = "Panel Replay Enabled";
> > > + else if (psr->enabled)
> > > status = psr->psr2_enabled ? "PSR2 enabled" :
> > > "PSR1
> > > enabled";
> > > else
> > > status = "disabled";
> > > @@ -3076,14 +3088,17 @@ static int intel_psr_status(struct
> > > seq_file
> > > *m, struct intel_dp *intel_dp)
> > > goto unlock;
> > > }
> > >
> > > - if (psr->psr2_enabled) {
> > > + if (psr->panel_replay_enabled) {
> > > + val = intel_de_read(dev_priv,
> > > TRANS_DP2_CTL(cpu_transcoder));
> > > + enabled = val & TRANS_DP2_PANEL_REPLAY_ENABLE;
> > > + } else if
Re: [PATCH v2 8/9] PCI: Exclude PCIe ports used for tunneling in pcie_bandwidth_available()
On Tue, Nov 07, 2023 at 07:45:26AM +0200, Mika Westerberg wrote: > Hi, > > On Mon, Nov 06, 2023 at 07:56:52PM +0100, Lukas Wunner wrote: > > On Mon, Nov 06, 2023 at 12:44:25PM -0600, Mario Limonciello wrote: > > > Tangentially related; the link speed is currently symmetric but there are > > > two sysfs files. Mika left a comment in drivers/thunderbolt/switch.c it > > > may > > > be asymmetric in the future. So we may need to keep that in mind on any > > > design that builds on top of them. > > > > Aren't asymmetric Thunderbolt speeds just a DisplayPort thing? > > No, they affect the whole fabric. We have the initial code for > asymmetric switching in v6.7-rc1. > > > > As 'thunderbolt' can be a module or built in, we need to bring code into > > > PCI > > > core so that it works in early boot before it loads. > > > > tb_switch_get_generation() is small enough that it could be moved to the > > PCI core. I doubt that we need to make thunderbolt built-in only > > or move a large amount of code to the PCI core. > > If at all possible I would like to avoid this and littering PCI side > with non-PCI stuff. There could be other similar "mediums" in the future > where you can transfer packets of "native" protocols such as PCIe so > instead of making it Thunderbolt/USB4 specific it should be generic > enough to support future extensions. > > In case of Thunderbolt/USB4 there is no real way to figure out how much > bandwidth each PCIe tunnel gets (it is kind of bulk traffic that gets > what is left from isochronous protocols) so I would not even try that > and instead use the real PCIe links in pcie_bandwidth_available() and > skip all the "virtual" ones. Actually can we call the new function something like pci_link_is_virtual() instead and make pcie_bandwidth_available() call it? That would be more future proof IMHO.
Re: [PATCH] drivers: gpu: Fix warning using plain integer as NULL
On 11/7/23 03:07, Alex Deucher wrote:
On Mon, Nov 6, 2023 at 4:20 PM Abhinav Singh
wrote:
On 11/7/23 00:25, Alex Deucher wrote:
Applied. This matches what we already do in the other clear state headers.
Alex
On Fri, Nov 3, 2023 at 12:00 PM Abhinav Singh
wrote:
sparse static analysis tools generate a warning with this message
"Using plain integer as NULL pointer". In this case this warning is
being shown because we are trying to intialize a pointer to NULL using
integer value 0.
Signed-off-by: Abhinav Singh
---
drivers/gpu/drm/radeon/clearstate_evergreen.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/radeon/clearstate_evergreen.h
b/drivers/gpu/drm/radeon/clearstate_evergreen.h
index 63a1ffbb3ced..3b645558f133 100644
--- a/drivers/gpu/drm/radeon/clearstate_evergreen.h
+++ b/drivers/gpu/drm/radeon/clearstate_evergreen.h
@@ -1049,7 +1049,7 @@ static const struct cs_extent_def SECT_CONTEXT_defs[] =
{SECT_CONTEXT_def_5, 0xa29e, 5 },
{SECT_CONTEXT_def_6, 0xa2a5, 56 },
{SECT_CONTEXT_def_7, 0xa2de, 290 },
-{ 0, 0, 0 }
+{ NULL, 0, 0 }
};
static const u32 SECT_CLEAR_def_1[] =
{
@@ -1060,7 +1060,7 @@ static const u32 SECT_CLEAR_def_1[] =
static const struct cs_extent_def SECT_CLEAR_defs[] =
{
{SECT_CLEAR_def_1, 0xffc0, 3 },
-{ 0, 0, 0 }
+{ NULL, 0, 0 }
};
static const u32 SECT_CTRLCONST_def_1[] =
{
@@ -1070,11 +1070,11 @@ static const u32 SECT_CTRLCONST_def_1[] =
static const struct cs_extent_def SECT_CTRLCONST_defs[] =
{
{SECT_CTRLCONST_def_1, 0xf3fc, 2 },
-{ 0, 0, 0 }
+{ NULL, 0, 0 }
};
static const struct cs_section_def evergreen_cs_data[] = {
{ SECT_CONTEXT_defs, SECT_CONTEXT },
{ SECT_CLEAR_defs, SECT_CLEAR },
{ SECT_CTRLCONST_defs, SECT_CTRLCONST },
-{ 0, SECT_NONE }
+{ NULL, SECT_NONE }
};
--
2.39.2
Hi Alex, thanks for looking into this. By applied you mean this patch is
accepted and it has been merged?
Yes. Once it makes it through our CI system, it will show up in my
drm-next tree.
Alex
Okay, this is my first patch to get into kernel :)
Thank you once again for your time with this patch and accepting it.
Re: [PATCH v2 8/9] PCI: Exclude PCIe ports used for tunneling in pcie_bandwidth_available()
Hi, On Mon, Nov 06, 2023 at 07:56:52PM +0100, Lukas Wunner wrote: > On Mon, Nov 06, 2023 at 12:44:25PM -0600, Mario Limonciello wrote: > > Tangentially related; the link speed is currently symmetric but there are > > two sysfs files. Mika left a comment in drivers/thunderbolt/switch.c it may > > be asymmetric in the future. So we may need to keep that in mind on any > > design that builds on top of them. > > Aren't asymmetric Thunderbolt speeds just a DisplayPort thing? No, they affect the whole fabric. We have the initial code for asymmetric switching in v6.7-rc1. > > As 'thunderbolt' can be a module or built in, we need to bring code into PCI > > core so that it works in early boot before it loads. > > tb_switch_get_generation() is small enough that it could be moved to the > PCI core. I doubt that we need to make thunderbolt built-in only > or move a large amount of code to the PCI core. If at all possible I would like to avoid this and littering PCI side with non-PCI stuff. There could be other similar "mediums" in the future where you can transfer packets of "native" protocols such as PCIe so instead of making it Thunderbolt/USB4 specific it should be generic enough to support future extensions. In case of Thunderbolt/USB4 there is no real way to figure out how much bandwidth each PCIe tunnel gets (it is kind of bulk traffic that gets what is left from isochronous protocols) so I would not even try that and instead use the real PCIe links in pcie_bandwidth_available() and skip all the "virtual" ones.
Re: Blank screen on boot of Linux 6.5 and later on Lenovo ThinkPad L570
Hi Huacai,
On 2023-11-07 Tue 09:49am, Huacai Chen wrote:
> Hi, Evan,
>
> On Tue, Nov 7, 2023 at 4:32 AM Evan Preston wrote:
> >
> > Hi Huacai,
> >
> > On 2023-11-06 Mon 10:22pm, Huacai Chen wrote:
> > > On Mon, Nov 6, 2023 at 9:49 PM Jaak Ristioja wrote:
> > > >
> > > > On 06.11.23 04:15, Huacai Chen wrote:
> > > > > Hi, Jaak and Evan,
> > > > >
> > > > > On Mon, Nov 6, 2023 at 12:28 AM Jaak Ristioja
> > > > > wrote:
> > > > >>
> > > > >> On 05.11.23 14:40, Huacai Chen wrote:
> > > > >>> Hi, Evan,
> > > > >>>
> > > > >>> On Sat, Nov 4, 2023 at 10:50 AM Evan Preston
> > > > >>> wrote:
> > > >
> > > > Hi Huacai,
> > > >
> > > > On 2023-11-03 Fri 02:36pm, Huacai Chen wrote:
> > > > > Hi, Evan,
> > > > >
> > > > > On Fri, Nov 3, 2023 at 1:54 PM Evan Preston
> > > > > wrote:
> > > > >>
> > > > >> Hi Huacai,
> > > > >>
> > > > >> On 2023-11-02 Thu 08:38pm, Huacai Chen wrote:
> > > > >>> Hi, Jaak,
> > > > >>>
> > > > >>> On Wed, Nov 1, 2023 at 7:52 PM Jaak Ristioja
> > > > >>> wrote:
> > > >
> > > > On 31.10.23 14:17, Huacai Chen wrote:
> > > > > Hi, Jaak and Evan,
> > > > >
> > > > > On Sun, Oct 29, 2023 at 9:42 AM Huacai Chen
> > > > > wrote:
> > > > >>
> > > > >> On Sat, Oct 28, 2023 at 7:06 PM Jaak Ristioja
> > > > >> wrote:
> > > > >>>
> > > > >>> On 26.10.23 03:58, Huacai Chen wrote:
> > > > Hi, Jaak,
> > > >
> > > > On Thu, Oct 26, 2023 at 2:49 AM Jaak Ristioja
> > > > wrote:
> > > > >
> > > > > On 25.10.23 16:23, Huacai Chen wrote:
> > > > >> On Wed, Oct 25, 2023 at 6:08 PM Thorsten Leemhuis
> > > > >> wrote:
> > > > >>>
> > > > >>> Javier, Dave, Sima,
> > > > >>>
> > > > >>> On 23.10.23 00:54, Evan Preston wrote:
> > > > On 2023-10-20 Fri 05:48pm, Huacai Chen wrote:
> > > > > On Fri, Oct 20, 2023 at 5:35 PM Linux regression
> > > > > tracking (Thorsten
> > > > > Leemhuis) wrote:
> > > > >> On 09.10.23 10:54, Huacai Chen wrote:
> > > > >>> On Mon, Oct 9, 2023 at 4:45 PM Bagas Sanjaya
> > > > >>> wrote:
> > > > On Mon, Oct 09, 2023 at 09:27:02AM +0800, Huacai
> > > > Chen wrote:
> > > > > On Tue, Sep 26, 2023 at 10:31 PM Huacai Chen
> > > > > wrote:
> > > > >> On Tue, Sep 26, 2023 at 7:15 PM Linux regression
> > > > >> tracking (Thorsten
> > > > >> Leemhuis) wrote:
> > > > >>> On 13.09.23 14:02, Jaak Ristioja wrote:
> > > >
> > > > Upgrading to Linux 6.5 on a Lenovo ThinkPad
> > > > L570 (Integrated Intel HD
> > > > Graphics 620 (rev 02), Intel(R) Core(TM)
> > > > i7-7500U) results in a blank
> > > > screen after boot until the display manager
> > > > starts... if it does start
> > > > at all. Using the nomodeset kernel parameter
> > > > seems to be a workaround.
> > > >
> > > > I've bisected this to commit
> > > > 60aebc9559492cea6a9625f514a8041717e3a2e4
> > > > ("drivers/firmware: Move sysfb_init() from
> > > > device_initcall to
> > > > subsys_initcall_sync").
> > > > >>>
> > > > > As confirmed by Jaak, disabling DRM_SIMPLEDRM
> > > > > makes things work fine
> > > > > again. So I guess the reason:
> > > > >>
> > > > >> Well, this to me still looks a lot (please correct
> > > > >> me if I'm wrong) like
> > > > >> regression that should be fixed, as DRM_SIMPLEDRM
> > > > >> was enabled beforehand
> > > > >> if I understood things correctly. Or is there a
> > > > >> proper fix for this
> > > > >> already in the works and I just missed this? Or is
> > > > >> there some good
> > > > >> reason why this won't/can't be fixed?
> > > > >
> > > > > DRM_SIMPLEDRM was enabled but it didn't work at all
> > > > > because there was
> > > > > no corresponding platform device. Now DRM_SIMPLEDRM
> > > > > works but it has a
> > > > > blank screen. Of course it is valuable to investigate
> > > > >
[PATCH] nouveau: use an rwlock for the event lock.
From: Dave Airlie
This allows it to break the following circular locking dependency.
Aug 10 07:01:29 dg1test kernel:
==
Aug 10 07:01:29 dg1test kernel: WARNING: possible circular locking dependency
detected
Aug 10 07:01:29 dg1test kernel: 6.4.0-rc7+ #10 Not tainted
Aug 10 07:01:29 dg1test kernel:
--
Aug 10 07:01:29 dg1test kernel: wireplumber/2236 is trying to acquire lock:
Aug 10 07:01:29 dg1test kernel: 8fca5320da18 (>lock){-...}-{2:2}, at:
nouveau_fence_wait_uevent_handler+0x2b/0x100 [nouveau]
Aug 10 07:01:29 dg1test kernel:
but task is already holding lock:
Aug 10 07:01:29 dg1test kernel: 8fca41208610
(>list_lock#2){-...}-{2:2}, at: nvkm_event_ntfy+0x50/0xf0 [nouveau]
Aug 10 07:01:29 dg1test kernel:
which lock already depends on the new lock.
Aug 10 07:01:29 dg1test kernel:
the existing dependency chain (in reverse
order) is:
Aug 10 07:01:29 dg1test kernel:
-> #3 (>list_lock#2){-...}-{2:2}:
Aug 10 07:01:29 dg1test kernel:_raw_spin_lock_irqsave+0x4b/0x70
Aug 10 07:01:29 dg1test kernel:nvkm_event_ntfy+0x50/0xf0 [nouveau]
Aug 10 07:01:29 dg1test kernel:ga100_fifo_nonstall_intr+0x24/0x30
[nouveau]
Aug 10 07:01:29 dg1test kernel:nvkm_intr+0x12c/0x240 [nouveau]
Aug 10 07:01:29 dg1test kernel:__handle_irq_event_percpu+0x88/0x240
Aug 10 07:01:29 dg1test kernel:handle_irq_event+0x38/0x80
Aug 10 07:01:29 dg1test kernel:handle_edge_irq+0xa3/0x240
Aug 10 07:01:29 dg1test kernel:__common_interrupt+0x72/0x160
Aug 10 07:01:29 dg1test kernel:common_interrupt+0x60/0xe0
Aug 10 07:01:29 dg1test kernel:asm_common_interrupt+0x26/0x40
Aug 10 07:01:29 dg1test kernel:
-> #2 (>intr.lock){-...}-{2:2}:
Aug 10 07:01:29 dg1test kernel:_raw_spin_lock_irqsave+0x4b/0x70
Aug 10 07:01:29 dg1test kernel:nvkm_inth_allow+0x2c/0x80 [nouveau]
Aug 10 07:01:29 dg1test kernel:nvkm_event_ntfy_state+0x181/0x250
[nouveau]
Aug 10 07:01:29 dg1test kernel:nvkm_event_ntfy_allow+0x63/0xd0 [nouveau]
Aug 10 07:01:29 dg1test kernel:nvkm_uevent_mthd+0x4d/0x70 [nouveau]
Aug 10 07:01:29 dg1test kernel:nvkm_ioctl+0x10b/0x250 [nouveau]
Aug 10 07:01:29 dg1test kernel:nvif_object_mthd+0xa8/0x1f0 [nouveau]
Aug 10 07:01:29 dg1test kernel:nvif_event_allow+0x2a/0xa0 [nouveau]
Aug 10 07:01:29 dg1test kernel:nouveau_fence_enable_signaling+0x78/0x80
[nouveau]
Aug 10 07:01:29 dg1test kernel:__dma_fence_enable_signaling+0x5e/0x100
Aug 10 07:01:29 dg1test kernel:dma_fence_add_callback+0x4b/0xd0
Aug 10 07:01:29 dg1test kernel:nouveau_cli_work_queue+0xae/0x110
[nouveau]
Aug 10 07:01:29 dg1test kernel:nouveau_gem_object_close+0x1d1/0x2a0
[nouveau]
Aug 10 07:01:29 dg1test kernel:drm_gem_handle_delete+0x70/0xe0 [drm]
Aug 10 07:01:29 dg1test kernel:drm_ioctl_kernel+0xa5/0x150 [drm]
Aug 10 07:01:29 dg1test kernel:drm_ioctl+0x256/0x490 [drm]
Aug 10 07:01:29 dg1test kernel:nouveau_drm_ioctl+0x5a/0xb0 [nouveau]
Aug 10 07:01:29 dg1test kernel:__x64_sys_ioctl+0x91/0xd0
Aug 10 07:01:29 dg1test kernel:do_syscall_64+0x3c/0x90
Aug 10 07:01:29 dg1test kernel:entry_SYSCALL_64_after_hwframe+0x72/0xdc
Aug 10 07:01:29 dg1test kernel:
-> #1 (>refs_lock#4){}-{2:2}:
Aug 10 07:01:29 dg1test kernel:_raw_spin_lock_irqsave+0x4b/0x70
Aug 10 07:01:29 dg1test kernel:nvkm_event_ntfy_state+0x37/0x250
[nouveau]
Aug 10 07:01:29 dg1test kernel:nvkm_event_ntfy_allow+0x63/0xd0 [nouveau]
Aug 10 07:01:29 dg1test kernel:nvkm_uevent_mthd+0x4d/0x70 [nouveau]
Aug 10 07:01:29 dg1test kernel:nvkm_ioctl+0x10b/0x250 [nouveau]
Aug 10 07:01:29 dg1test kernel:nvif_object_mthd+0xa8/0x1f0 [nouveau]
Aug 10 07:01:29 dg1test kernel:nvif_event_allow+0x2a/0xa0 [nouveau]
Aug 10 07:01:29 dg1test kernel:nouveau_fence_enable_signaling+0x78/0x80
[nouveau]
Aug 10 07:01:29 dg1test kernel:__dma_fence_enable_signaling+0x5e/0x100
Aug 10 07:01:29 dg1test kernel:dma_fence_add_callback+0x4b/0xd0
Aug 10 07:01:29 dg1test kernel:nouveau_cli_work_queue+0xae/0x110
[nouveau]
Aug 10 07:01:29 dg1test kernel:nouveau_gem_object_close+0x1d1/0x2a0
[nouveau]
Aug 10 07:01:29 dg1test kernel:drm_gem_handle_delete+0x70/0xe0 [drm]
Aug 10 07:01:29 dg1test kernel:drm_ioctl_kernel+0xa5/0x150 [drm]
Aug 10 07:01:29 dg1test kernel:drm_ioctl+0x256/0x490 [drm]
Aug 10 07:01:29 dg1test kernel:nouveau_drm_ioctl+0x5a/0xb0 [nouveau]
Aug 10 07:01:29 dg1test kernel:__x64_sys_ioctl+0x91/0xd0
Aug 10 07:01:29 dg1test kernel:do_syscall_64+0x3c/0x90
Aug 10 07:01:29 dg1test kernel:
Re: [RFC v4 0/5] Proposal to use netlink for RAS and Telemetry across drm subsystem
On 11/1/2023 1:36 PM, Aravind Iddamsetty wrote:
On 30/10/23 20:41, Lazar, Lijo wrote:
On 10/30/2023 11:49 AM, Aravind Iddamsetty wrote:
On 26/10/23 15:34, Lazar, Lijo wrote:
Hi Lijo,
Thank you for your comments.
On 10/23/2023 8:59 PM, Alex Deucher wrote:
On Fri, Oct 20, 2023 at 7:42 PM Aravind Iddamsetty
wrote:
Our hardware supports RAS(Reliability, Availability, Serviceability) by
reporting the errors to the host, which the KMD processes and exposes a
set of error counters which can be used by observability tools to take
corrective actions or repairs. Traditionally there were being exposed
via PMU (for relative counters) and sysfs interface (for absolute
value) in our internal branch. But, due to the limitations in this
approach to use two interfaces and also not able to have an event based
reporting or configurability, an alternative approach to try netlink
was suggested by community for drm subsystem wide UAPI for RAS and
telemetry as discussed in [1].
This [1] is the inspiration to this series. It uses the generic
netlink(genl) family subsystem and exposes a set of commands that can
be used by every drm driver, the framework provides a means to have
custom commands too. Each drm driver instance in this example xe driver
instance registers a family and operations to the genl subsystem through
which it enumerates and reports the error counters. An event based
notification is also supported to which userpace can subscribe to and
be notified when any error occurs and read the error counter this avoids
continuous polling on error counter. This can also be extended to
threshold based notification.
The commands used seems very limited. In AMD SOCs, IP blocks, instances of IP
blocks, block types which support RAS will change across generations.
This series has a single command to query the counters supported. Within that
it seems to assign unique ids for every combination of error type, IP block
type and then another for each instance. Not sure how good this kind of
approach is for an end user. The Ids won't necessarily the stay the same across
multiple generations. Users will generally be interested in specific IP blocks.
Exactly the IDs are UAPI and won't change once defined for a platform and any
new SKU or platform will add on top of existing ones. Userspace can include the
header and use the defines. The query is used to know what all errors exists on
a platform and userspace can process the IDs of IP block of interest. I believe
even if we list block wise a query will be needed without which userspace
wouldn't know which blocks exist on a platform.
What I meant is - assigning an id for every combination of IP block/ instance
number/error type is not maintainable across different SOCs.
Instead, can we have something like -
Query -> returns IP block ids, number of instances, error types supported
by each IP block.
Read Error -> IP block id | Instance number /Instance ALL | Error type
id/Error type ALL.
Hi Lijo,
Would you please elaborate more on what is the issue you fore see with the
maintainability. But I have a query on the model suggested
This might work well with user input based tools, but don't think it suits if
we want to periodically read a particular counter.
The inspiration to have ID for each is taken from PMU subsystem where every
event has an ID and a flat list so no multiple queries and we can read them
individually or group together
which can be achieved via READ_MULTI command I proposed earlier.
The problem is mainly with maintaining a static list including all ip_id
| instance | err_type combinations. Instead, preference is for client
to query the capabilities -> instance/error types supported and then use
that info later to fetch error info.
Capability query could return something like ip block, total instance
available and error types supported. This doesn't require to maintain an
ID list for each combination.
The instances per SOC could be variable. For ex: it's not required that
all SKUs of your SOC type to have have ss0-ss3 HBMs. For the same SOC
type or for new SOC type, it could be more or less.
Roughly something like ..
enum ip_block_id
{
block1,
block2,
block3,
block_all
}
enum ip_sub_block_id (if required)
{
sub_block1,
sub_block2,
sub_block_all
}
#define INSTANCE_ALL -1
enum ras_error_type
{
correctable,
uncorrectable,
deferred,
fatal,
...
err_all
}
Then define something like below while querying error details.
<31:24> = Block Id
<23:16> subblock id
<15:8> - interested instance
<7:0> - error_type
Instance number could be 'inst_all' or specific IP instance.
Thanks,
Lijo
Thanks,
Aravind.
Thanks,
Lijo
For ex: to get HBM errors, it looks like the current patch series supports
READALL which dumps the whole set of errors. Or,
RE: [PATCH v8 6/6] drm/i915/panelreplay: Debugfs support for panel replay
> -Original Message-
> From: Hogander, Jouni
> Sent: Monday, November 6, 2023 1:33 PM
> To: dri-devel@lists.freedesktop.org; Manna, Animesh
> ; intel-...@lists.freedesktop.org
> Cc: Murthy, Arun R ; Nikula, Jani
>
> Subject: Re: [PATCH v8 6/6] drm/i915/panelreplay: Debugfs support for
> panel replay
>
> Hello Animesh,
>
> Thank you for the changes. Now the patch is much shorter, cleaner and
> easier to review. See my inline comments below.
>
> On Sat, 2023-11-04 at 02:30 +0530, Animesh Manna wrote:
> > Add debugfs support which will print source and sink status per
> > connector basis. Existing i915_psr_status and i915_psr_sink_status
> > will be used to get the source and sink status of panel replay.
> >
> > v1: Initial version. [rb-ed by Arun]
> > v2: Added check for DP 2.0 and connector type in
> > connector_debugfs_add().
> > v3: Optimization and cosmetic changes. [Jouni]
> >
> > Cc: Jouni Högander
> > Cc: Arun R Murthy
> > Cc: Jani Nikula
> > Reviewed-by: Arun R Murthy
> > Signed-off-by: Animesh Manna
> > ---
> > drivers/gpu/drm/i915/display/intel_psr.c | 93 +-
> > --
> > 1 file changed, 66 insertions(+), 27 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> > b/drivers/gpu/drm/i915/display/intel_psr.c
> > index 8ed4684b4528..8b7c03cd4989 100644
> > --- a/drivers/gpu/drm/i915/display/intel_psr.c
> > +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> > @@ -2813,12 +2813,19 @@ static int
> > psr_get_status_and_error_status(struct intel_dp *intel_dp,
> > {
> > struct drm_dp_aux *aux = _dp->aux;
> > int ret;
> > + unsigned int offset;
> >
> > - ret = drm_dp_dpcd_readb(aux, DP_PSR_STATUS, status);
> > + offset = intel_dp->psr.panel_replay_enabled ?
> > + DP_SINK_DEVICE_PR_AND_FRAME_LOCK_STATUS :
> > DP_PSR_STATUS;
> > +
> > + ret = drm_dp_dpcd_readb(aux, offset, status);
> > if (ret != 1)
> > return ret;
> >
> > - ret = drm_dp_dpcd_readb(aux, DP_PSR_ERROR_STATUS,
> > error_status);
> > + offset = intel_dp->psr.panel_replay_enabled ?
> > + DP_PANEL_REPLAY_ERROR_STATUS : DP_PSR_ERROR_STATUS;
> > +
> > + ret = drm_dp_dpcd_readb(aux, offset, error_status);
> > if (ret != 1)
> > return ret;
> >
> > @@ -3039,7 +3046,7 @@ psr_source_status(struct intel_dp *intel_dp,
> > struct seq_file *m)
> > status = live_status[status_val];
> > }
> >
> > - seq_printf(m, "Source PSR status: %s [0x%08x]\n", status,
> > val);
> > + seq_printf(m, "Source PSR/PanelReplay status: %s [0x%08x]\n",
> > status, val);
> > }
> >
> > static int intel_psr_status(struct seq_file *m, struct intel_dp
> > *intel_dp)
> > @@ -3052,18 +3059,23 @@ static int intel_psr_status(struct seq_file
> > *m, struct intel_dp *intel_dp)
> > bool enabled;
> > u32 val;
> >
> > - seq_printf(m, "Sink support: %s", str_yes_no(psr-
> > >sink_support));
> > - if (psr->sink_support)
> > + seq_printf(m, "Sink support: PSR = %s, Panel Replay = %s",
> > + str_yes_no(psr->sink_support),
> > + str_yes_no(psr->sink_panel_replay_support));
> > +
> > + if (psr->sink_support || psr->sink_panel_replay_support)
> > seq_printf(m, " [0x%02x]", intel_dp->psr_dpcd[0]);
>
> The output will look like this:
>
> Sink support: PSR = yes, Panel Replay = yes, [0x01]
>
> I think more logical would be:
>
> Sink support: PSR = yes [0x01], Panel Replay = yes
>
>
> > seq_puts(m, "\n");
> >
> > - if (!psr->sink_support)
> > + if (!(psr->sink_support || psr->sink_panel_replay_support))
> > return 0;
> >
> > wakeref = intel_runtime_pm_get(_priv->runtime_pm);
> > mutex_lock(>lock);
> >
> > - if (psr->enabled)
> > + if (psr->panel_replay_enabled)
> > + status = "Panel Replay Enabled";
> > + else if (psr->enabled)
> > status = psr->psr2_enabled ? "PSR2 enabled" : "PSR1
> > enabled";
> > else
> > status = "disabled";
> > @@ -3076,14 +3088,17 @@ static int intel_psr_status(struct seq_file
> > *m, struct intel_dp *intel_dp)
> > goto unlock;
> > }
> >
> > - if (psr->psr2_enabled) {
> > + if (psr->panel_replay_enabled) {
> > + val = intel_de_read(dev_priv,
> > TRANS_DP2_CTL(cpu_transcoder));
> > + enabled = val & TRANS_DP2_PANEL_REPLAY_ENABLE;
> > + } else if (psr->psr2_enabled) {
> > val = intel_de_read(dev_priv,
> > EDP_PSR2_CTL(cpu_transcoder));
> > enabled = val & EDP_PSR2_ENABLE;
> > } else {
> > val = intel_de_read(dev_priv, psr_ctl_reg(dev_priv,
> > cpu_transcoder));
> > enabled = val & EDP_PSR_ENABLE;
> > }
> > - seq_printf(m, "Source PSR ctl: %s [0x%08x]\n",
> > +
Re: [PATCH v2] drm: amd: Resolve Sphinx unexpected indentation warning
On 11/7/2023 1:47 AM, Hunter Chasens wrote: Resolves Sphinx unexpected indentation warning when compiling documentation (e.g. `make htmldocs`). Replaces tabs with spaces and adds a literal block to keep vertical formatting of the example power state list. Signed-off-by: Hunter Chasens --- drivers/gpu/drm/amd/pm/amdgpu_pm.c | 13 +++-- 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/amd/pm/amdgpu_pm.c b/drivers/gpu/drm/amd/pm/amdgpu_pm.c index 517b9fb4624c..81b8ceb26890 100644 --- a/drivers/gpu/drm/amd/pm/amdgpu_pm.c +++ b/drivers/gpu/drm/amd/pm/amdgpu_pm.c @@ -989,12 +989,13 @@ static ssize_t amdgpu_get_pp_features(struct device *dev, * Reading back the files will show you the available power levels within * the power state and the clock information for those levels. If deep sleep is * applied to a clock, the level will be denoted by a special level 'S:' - * E.g., - * S: 19Mhz * - * 0: 615Mhz - * 1: 800Mhz - * 2: 888Mhz - * 3: 1000Mhz + * E.g.:: This will be like E.g.: Could you keep it like E.g.,:: so that :: is taken out? Thanks, Lijo + * + * S: 19Mhz * + * 0: 615Mhz + * 1: 800Mhz + * 2: 888Mhz + * 3: 1000Mhz * * * To manually adjust these states, first select manual using
Re: [PATCH v2 1/3] mm/gup: Introduce pin_user_pages_fd() for pinning shmem/hugetlbfs file pages (v2)
Hi Vivek,
kernel test robot noticed the following build errors:
[auto build test ERROR on akpm-mm/mm-everything]
url:
https://github.com/intel-lab-lkp/linux/commits/Vivek-Kasireddy/mm-gup-Introduce-pin_user_pages_fd-for-pinning-shmem-hugetlbfs-file-pages-v2/20231106-141954
base: https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git
mm-everything
patch link:
https://lore.kernel.org/r/20231106061541.507116-2-vivek.kasireddy%40intel.com
patch subject: [PATCH v2 1/3] mm/gup: Introduce pin_user_pages_fd() for pinning
shmem/hugetlbfs file pages (v2)
config: mips-maltaup_defconfig
(https://download.01.org/0day-ci/archive/20231107/202311071223.zeorzg33-...@intel.com/config)
compiler: clang version 17.0.0 (https://github.com/llvm/llvm-project.git
4a5ac14ee968ff0ad5d2cc1ffa0299048db4c88a)
reproduce (this is a W=1 build):
(https://download.01.org/0day-ci/archive/20231107/202311071223.zeorzg33-...@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot
| Closes:
https://lore.kernel.org/oe-kbuild-all/202311071223.zeorzg33-...@intel.com/
All errors (new ones prefixed by >>):
>> mm/gup.c:3419:9: error: call to undeclared function
>> 'hugetlb_add_to_page_cache'; ISO C99 and later do not support implicit
>> function declarations [-Wimplicit-function-declaration]
3419 | err = hugetlb_add_to_page_cache(folio,
file->f_mapping, idx);
| ^
1 error generated.
vim +/hugetlb_add_to_page_cache +3419 mm/gup.c
3403
3404 static struct page *alloc_file_page(struct file *file, pgoff_t idx)
3405 {
3406 struct page *page = ERR_PTR(-ENOMEM);
3407 struct folio *folio;
3408 int err;
3409
3410 if (shmem_file(file))
3411 return shmem_read_mapping_page(file->f_mapping, idx);
3412
3413 folio = alloc_hugetlb_folio_nodemask(hstate_file(file),
3414 NUMA_NO_NODE,
3415 NULL,
3416 GFP_USER);
3417 if (folio && folio_try_get(folio)) {
3418 page = >page;
> 3419 err = hugetlb_add_to_page_cache(folio, file->f_mapping,
> idx);
3420 if (err) {
3421 folio_put(folio);
3422 free_huge_folio(folio);
3423 page = ERR_PTR(err);
3424 }
3425 }
3426
3427 return page;
3428 }
3429
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
[PATCH] drm/sched: Don't disturb the entity when in RR-mode scheduling
Don't call drm_sched_select_entity() in drm_sched_run_job_queue(). In fact,
rename __drm_sched_run_job_queue() to just drm_sched_run_job_queue(), and let
it do just that, schedule the work item for execution.
The problem is that drm_sched_run_job_queue() calls drm_sched_select_entity()
to determine if the scheduler has an entity ready in one of its run-queues,
and in the case of the Round-Robin (RR) scheduling, the function
drm_sched_rq_select_entity_rr() does just that, selects the _next_ entity
which is ready, sets up the run-queue and completion and returns that
entity. The FIFO scheduling algorithm is unaffected.
Now, since drm_sched_run_job_work() also calls drm_sched_select_entity(), then
in the case of RR scheduling, that would result in drm_sched_select_entity()
having been called twice, which may result in skipping a ready entity if more
than one entity is ready. This commit fixes this by eliminating the call to
drm_sched_select_entity() from drm_sched_run_job_queue(), and leaves it only
in drm_sched_run_job_work().
v2: Rebased on top of Tvrtko's renames series of patches. (Luben)
Add fixes-tag. (Tvrtko)
Signed-off-by: Luben Tuikov
Fixes: f7fe64ad0f22ff ("drm/sched: Split free_job into own work item")
---
drivers/gpu/drm/scheduler/sched_main.c | 16 +++-
1 file changed, 3 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/scheduler/sched_main.c
b/drivers/gpu/drm/scheduler/sched_main.c
index 27843e37d9b769..cd0dc3f81d05f0 100644
--- a/drivers/gpu/drm/scheduler/sched_main.c
+++ b/drivers/gpu/drm/scheduler/sched_main.c
@@ -256,10 +256,10 @@ drm_sched_rq_select_entity_fifo(struct drm_sched_rq *rq)
}
/**
- * __drm_sched_run_job_queue - enqueue run-job work
+ * drm_sched_run_job_queue - enqueue run-job work
* @sched: scheduler instance
*/
-static void __drm_sched_run_job_queue(struct drm_gpu_scheduler *sched)
+static void drm_sched_run_job_queue(struct drm_gpu_scheduler *sched)
{
if (!READ_ONCE(sched->pause_submit))
queue_work(sched->submit_wq, >work_run_job);
@@ -928,7 +928,7 @@ static bool drm_sched_can_queue(struct drm_gpu_scheduler
*sched)
void drm_sched_wakeup(struct drm_gpu_scheduler *sched)
{
if (drm_sched_can_queue(sched))
- __drm_sched_run_job_queue(sched);
+ drm_sched_run_job_queue(sched);
}
/**
@@ -1040,16 +1040,6 @@ drm_sched_pick_best(struct drm_gpu_scheduler
**sched_list,
}
EXPORT_SYMBOL(drm_sched_pick_best);
-/**
- * drm_sched_run_job_queue - enqueue run-job work if there are ready entities
- * @sched: scheduler instance
- */
-static void drm_sched_run_job_queue(struct drm_gpu_scheduler *sched)
-{
- if (drm_sched_select_entity(sched))
- __drm_sched_run_job_queue(sched);
-}
-
/**
* drm_sched_free_job_work - worker to call free_job
*
base-commit: 27d9620e9a9a6bc27a646b464b85860d91e21af3
--
2.42.1
Re: [PATCH v2 1/3] mm/gup: Introduce pin_user_pages_fd() for pinning shmem/hugetlbfs file pages (v2)
Hi Vivek, kernel test robot noticed the following build errors: [auto build test ERROR on akpm-mm/mm-everything] url: https://github.com/intel-lab-lkp/linux/commits/Vivek-Kasireddy/mm-gup-Introduce-pin_user_pages_fd-for-pinning-shmem-hugetlbfs-file-pages-v2/20231106-141954 base: https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git mm-everything patch link: https://lore.kernel.org/r/20231106061541.507116-2-vivek.kasireddy%40intel.com patch subject: [PATCH v2 1/3] mm/gup: Introduce pin_user_pages_fd() for pinning shmem/hugetlbfs file pages (v2) config: um-allyesconfig (https://download.01.org/0day-ci/archive/20231107/202311071110.zgf6p4zc-...@intel.com/config) compiler: clang version 14.0.6 (https://github.com/llvm/llvm-project.git f28c006a5895fc0e329fe15fead81e37457cb1d1) reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20231107/202311071110.zgf6p4zc-...@intel.com/reproduce) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot | Closes: https://lore.kernel.org/oe-kbuild-all/202311071110.zgf6p4zc-...@intel.com/ All errors (new ones prefixed by >>): In file included from mm/gup.c:9: In file included from include/linux/pagemap.h:11: In file included from include/linux/highmem.h:12: In file included from include/linux/hardirq.h:11: In file included from arch/um/include/asm/hardirq.h:5: In file included from include/asm-generic/hardirq.h:17: In file included from include/linux/irq.h:20: In file included from include/linux/io.h:13: In file included from arch/um/include/asm/io.h:24: include/asm-generic/io.h:547:31: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic] val = __raw_readb(PCI_IOBASE + addr); ~~ ^ include/asm-generic/io.h:560:61: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic] val = __le16_to_cpu((__le16 __force)__raw_readw(PCI_IOBASE + addr)); ~~ ^ include/uapi/linux/byteorder/little_endian.h:37:51: note: expanded from macro '__le16_to_cpu' #define __le16_to_cpu(x) ((__force __u16)(__le16)(x)) ^ In file included from mm/gup.c:9: In file included from include/linux/pagemap.h:11: In file included from include/linux/highmem.h:12: In file included from include/linux/hardirq.h:11: In file included from arch/um/include/asm/hardirq.h:5: In file included from include/asm-generic/hardirq.h:17: In file included from include/linux/irq.h:20: In file included from include/linux/io.h:13: In file included from arch/um/include/asm/io.h:24: include/asm-generic/io.h:573:61: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic] val = __le32_to_cpu((__le32 __force)__raw_readl(PCI_IOBASE + addr)); ~~ ^ include/uapi/linux/byteorder/little_endian.h:35:51: note: expanded from macro '__le32_to_cpu' #define __le32_to_cpu(x) ((__force __u32)(__le32)(x)) ^ In file included from mm/gup.c:9: In file included from include/linux/pagemap.h:11: In file included from include/linux/highmem.h:12: In file included from include/linux/hardirq.h:11: In file included from arch/um/include/asm/hardirq.h:5: In file included from include/asm-generic/hardirq.h:17: In file included from include/linux/irq.h:20: In file included from include/linux/io.h:13: In file included from arch/um/include/asm/io.h:24: include/asm-generic/io.h:584:33: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic] __raw_writeb(value, PCI_IOBASE + addr); ~~ ^ include/asm-generic/io.h:594:59: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic] __raw_writew((u16 __force)cpu_to_le16(value), PCI_IOBASE + addr); ~~ ^ include/asm-generic/io.h:604:59: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic] __raw_writel((u32 __force)cpu_to_le32(value), PCI_IOBASE + addr); ~~ ^ include/asm-generic/io.h:692:20: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic] readsb(PCI_IOBASE + addr, buffer, count); ~~ ^ include/asm-generic/io.h:700:20: warning: performing pointer arit
Re: [PATCH 0/5] Some drm scheduler internal renames
On 2023-11-06 07:41, Tvrtko Ursulin wrote: > > On 05/11/2023 01:51, Luben Tuikov wrote: >> On 2023-11-02 06:55, Tvrtko Ursulin wrote: >>> From: Tvrtko Ursulin >>> >>> I found some of the naming a bit incosistent and unclear so just a small >>> attempt to clarify and tidy some of them. See what people think if my first >>> stab improves things or not. >>> >>> Cc: Luben Tuikov >>> Cc: Matthew Brost >>> >>> Tvrtko Ursulin (5): >>>drm/sched: Rename drm_sched_get_cleanup_job to be more descriptive >>>drm/sched: Move free worker re-queuing out of the if block >>>drm/sched: Rename drm_sched_free_job_queue to be more descriptive >>>drm/sched: Rename drm_sched_run_job_queue_if_ready and clarify >>> kerneldoc >>>drm/sched: Drop suffix from drm_sched_wakeup_if_can_queue >>> >>> drivers/gpu/drm/scheduler/sched_entity.c | 4 +- >>> drivers/gpu/drm/scheduler/sched_main.c | 53 >>> include/drm/gpu_scheduler.h | 2 +- >>> 3 files changed, 29 insertions(+), 30 deletions(-) >>> >> >> Series is, >> >> Reviewed-by: Luben Tuikov >> >> and pushed to drm-misc-next. > > Oh thanks, I definitely did not expect that to happen so quickly, > especially since it conflicts with your fix for RR and there are some > other opens. But it is fine, all that can be worked on top. Yeah, it does conflict, and it does make some changes obsolete, but your series was fine and an improvement, so might as well push it. I'll rebase my patch on top of yours. -- Regards, Luben OpenPGP_0x4C15479431A334AF.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Re: [RFC PATCH v3 09/12] net: add support for skbs with unreadable frags
> > > > I think my other issue with MSG_SOCK_DEVMEM being on recvmsg is that
> > > > it somehow implies that I have an option of passing or not passing it
> > > > for an individual system call.
> > > > If we know that we're going to use dmabuf with the socket, maybe we
> > > > should move this flag to the socket() syscall?
> > > >
> > > > fd = socket(AF_INET6, SOCK_STREAM, SOCK_DEVMEM);
> > > >
> > > > ?
> > >
> > > I think it should then be a setsockopt called before any data is
> > > exchanged, with no change of modifying mode later. We generally use
> > > setsockopts for the mode of a socket. This use of the protocol field
> > > in socket() for setting a mode would be novel. Also, it might miss
> > > passively opened connections, or be overly restrictive: one approach
> > > for all accepted child sockets.
> >
> > I was thinking this is similar to SOCK_CLOEXEC or SOCK_NONBLOCK? There
> > are plenty of bits we can grab. But setsockopt works as well!
>
> To follow up: if we have this flag on a socket, not on a per-message
> basis, can we also use recvmsg for the recycling part maybe?
>
> while (true) {
> memset(msg, 0, ...);
>
> /* receive the tokens */
> ret = recvmsg(fd, , 0);
>
> /* recycle the tokens from the above recvmsg() */
> ret = recvmsg(fd, , MSG_RECYCLE);
> }
>
> recvmsg + MSG_RECYCLE can parse the same format that regular recvmsg
> exports (SO_DEVMEM_OFFSET) and we can also add extra cmsg option
> to recycle a range.
>
> Will this be more straightforward than a setsockopt(SO_DEVMEM_DONTNEED)?
> Or is it more confusing?
It would have to be sendmsg, as recvmsg is a copy_to_user operation.
I am not aware of any precedent in multiplexing the data stream and a
control operation stream in this manner. It would also require adding
a branch in the sendmsg hot path.
The memory is associated with the socket, freed when the socket is
closed as well as on SO_DEVMEM_DONTNEED. Fundamentally it is a socket
state operation, for which setsockopt is the socket interface.
Is your request purely a dislike, or is there some technical concern
with BPF and setsockopt?
[git pull] drm next + fixes for 6.7-rc1
Hi Linus, Geert pointed out I missed the renesas reworks in my main pull, so this pull contains the renesas next work for atomic conversion and DT support. It also contains a bunch of amdgpu and some small ssd13xx fixes. I'm going to be travelling from tomorrow, I should in theory have access to send MRs on the road, but it relies on a VPN connection I'm not confident in surviving long enough, we shall see. Dave. drm-next-2023-11-07: drm next and fixes for 6.7-rc1 renesas: - atomic conversion - DT support ssd13xx: - dt binding fix for ssd132x - Initialize ssd130x crtc_state to NULL. amdgpu: - Fix RAS support check - RAS fixes - MES fixes - SMU13 fixes - Contiguous memory allocation fix - BACO fixes - GPU reset fixes - Min power limit fixes - GFX11 fixes - USB4/TB hotplug fixes - ARM regression fix - GFX9.4.3 fixes - KASAN/KCSAN stack size check fixes - SR-IOV fixes - SMU14 fixes - PSP13 fixes - Display blend fixes - Flexible array size fixes amdkfd: - GPUVM fix radeon: - Flexible array size fixes The following changes since commit 631808095a82e6b6f8410a95f8b12b8d0d38b161: Merge tag 'amd-drm-next-6.7-2023-10-27' of https://gitlab.freedesktop.org/agd5f/linux into drm-next (2023-10-31 12:37:19 +1000) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm tags/drm-next-2023-11-07 for you to fetch changes up to 9ccde17d46554dbb2757c427f2cdf67688701f96: Merge tag 'amd-drm-next-6.7-2023-11-03' of https://gitlab.freedesktop.org/agd5f/linux into drm-next (2023-11-06 11:25:14 +1000) drm next and fixes for 6.7-rc1 renesas: - atomic conversion - DT support ssd13xx: - dt binding fix for ssd132x - Initialize ssd130x crtc_state to NULL. amdgpu: - Fix RAS support check - RAS fixes - MES fixes - SMU13 fixes - Contiguous memory allocation fix - BACO fixes - GPU reset fixes - Min power limit fixes - GFX11 fixes - USB4/TB hotplug fixes - ARM regression fix - GFX9.4.3 fixes - KASAN/KCSAN stack size check fixes - SR-IOV fixes - SMU14 fixes - PSP13 fixes - Display blend fixes - Flexible array size fixes amdkfd: - GPUVM fix radeon: - Flexible array size fixes Alex Deucher (7): drm/amdgpu/gfx10,11: use memcpy_to/fromio for MQDs drm/amdgpu: don't use ATRM for external devices drm/amdgpu: don't use pci_is_thunderbolt_attached() drm/amd: Fix UBSAN array-index-out-of-bounds for Powerplay headers drm/amdgpu: add a retry for IP discovery init drm/amdgpu/smu13: drop compute workload workaround drm/amdgpu: don't put MQDs in VRAM on ARM | ARM64 Arunpravin Paneer Selvam (1): drm/amdgpu: Fix the vram base start address Candice Li (1): drm/amdgpu: Drop deferred error in uncorrectable error check Dave Airlie (3): Merge tag 'shmob-drm-atomic-dt-tag2' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers into drm-next Merge tag 'drm-misc-next-fixes-2023-11-02' of git://anongit.freedesktop.org/drm/drm-misc into drm-next Merge tag 'amd-drm-next-6.7-2023-11-03' of https://gitlab.freedesktop.org/agd5f/linux into drm-next Felix Kuehling (2): drm/amdkfd: Improve amdgpu_vm_handle_moved drm/amdgpu: Attach eviction fence on alloc Geert Uytterhoeven (36): MAINTAINER: Create entry for Renesas SH-Mobile DRM drivers dt-bindings: display: Add Renesas SH-Mobile LCDC bindings media: uapi: Add MEDIA_BUS_FMT_RGB666_2X9_BE format drm: renesas: shmobile: Fix overlay plane disable drm: renesas: shmobile: Fix ARGB32 overlay format typo drm: renesas: shmobile: Correct encoder/connector types drm: renesas: shmobile: Add support for Runtime PM drm: renesas: shmobile: Restore indentation of shmob_drm_setup_clocks() drm: renesas: shmobile: Use %p4cc to print fourcc code drm: renesas: shmobile: Add missing YCbCr formats drm: renesas: shmobile: Improve shmob_drm_format_info table drm: renesas: shmobile: Improve error handling drm: renesas: shmobile: Convert to use devm_request_irq() drm: renesas: shmobile: Remove custom plane destroy callback drm: renesas: shmobile: Use drmm_universal_plane_alloc() drm: renesas: shmobile: Embed drm_device in shmob_drm_device drm: renesas: shmobile: Convert container helpers to static inline functions drm: renesas: shmobile: Replace .dev_private with container_of() drm: renesas: shmobile: Use media bus formats in platform data drm: renesas: shmobile: Move interface handling to connector setup drm: renesas: shmobile: Unify plane allocation drm: renesas: shmobile: Rename shmob_drm_crtc.crtc drm: renesas: shmobile: Rename shmob_drm_connector.connector drm: renesas: shmobile: Rename shmob_drm_plane.plane drm: renesas: shmobile: Use drm_crtc_handle_vblank() drm: renesas: shmobile: Move
Re: [PATCH v7 0/7] incorporate pm runtime framework and eDP clean up
On Sat, 7 Oct 2023 at 01:55, Kuogee Hsieh wrote: > > The purpose of this patch series is to incorporate pm runtime framework > into MSM eDP/DP driver so that eDP panel can be detected by DRM eDP panel > driver during system probe time. During incorporating procedure, original > customized pm realted fucntions, such as dp_pm_prepare(), dp_pm_suspend(), > dp_pm_resume() and dp_pm_prepare(), are removed and replaced with functions > provided by pm runtiem framework such as pm_runtime_force_suspend() and > pm_runtime_force_resume(). In addition, both eDP aux-bus and irq handler > are bound at system probe time too. With this patchset in place I can crash the board using the following sequence (SM8350-HDK): - plug the USBC DP dongle - run modetest at any mode, don't press Enter yet - unplug the dongle - press Enter to stop modetest => the board resets to Sahara. Please ping me if you need any additional information from my side. -- With best wishes Dmitry
[PATCH v2] drm/panel: starry-2081101qfh032011-53g: Fine tune the panel power sequence
For the "starry, 2081101qfh032011-53g" panel, it is stipulated in the
panel spec that MIPI needs to keep the LP11 state before the
lcm_reset pin is pulled high.
Fixes: 6069b66cd962 ("drm/panel: support for STARRY 2081101QFH032011-53G
MIPI-DSI panel")
Signed-off-by: xiazhengqiao
Reviewed-by: Jessica Zhang
---
drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
b/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
index 4f370bc6dca8..4ed8c2e28d37 100644
--- a/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
+++ b/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
@@ -1765,6 +1765,7 @@ static const struct panel_desc starry_qfh032011_53g_desc
= {
.mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_SYNC_PULSE |
MIPI_DSI_MODE_LPM,
.init_cmds = starry_qfh032011_53g_init_cmd,
+ .lp11_before_reset = true,
};
static const struct drm_display_mode starry_himax83102_j02_default_mode = {
--
2.17.1
Re: Blank screen on boot of Linux 6.5 and later on Lenovo ThinkPad L570
Hi, Evan,
On Tue, Nov 7, 2023 at 4:32 AM Evan Preston wrote:
>
> Hi Huacai,
>
> On 2023-11-06 Mon 10:22pm, Huacai Chen wrote:
> > On Mon, Nov 6, 2023 at 9:49 PM Jaak Ristioja wrote:
> > >
> > > On 06.11.23 04:15, Huacai Chen wrote:
> > > > Hi, Jaak and Evan,
> > > >
> > > > On Mon, Nov 6, 2023 at 12:28 AM Jaak Ristioja wrote:
> > > >>
> > > >> On 05.11.23 14:40, Huacai Chen wrote:
> > > >>> Hi, Evan,
> > > >>>
> > > >>> On Sat, Nov 4, 2023 at 10:50 AM Evan Preston
> > > >>> wrote:
> > >
> > > Hi Huacai,
> > >
> > > On 2023-11-03 Fri 02:36pm, Huacai Chen wrote:
> > > > Hi, Evan,
> > > >
> > > > On Fri, Nov 3, 2023 at 1:54 PM Evan Preston
> > > > wrote:
> > > >>
> > > >> Hi Huacai,
> > > >>
> > > >> On 2023-11-02 Thu 08:38pm, Huacai Chen wrote:
> > > >>> Hi, Jaak,
> > > >>>
> > > >>> On Wed, Nov 1, 2023 at 7:52 PM Jaak Ristioja
> > > >>> wrote:
> > >
> > > On 31.10.23 14:17, Huacai Chen wrote:
> > > > Hi, Jaak and Evan,
> > > >
> > > > On Sun, Oct 29, 2023 at 9:42 AM Huacai Chen
> > > > wrote:
> > > >>
> > > >> On Sat, Oct 28, 2023 at 7:06 PM Jaak Ristioja
> > > >> wrote:
> > > >>>
> > > >>> On 26.10.23 03:58, Huacai Chen wrote:
> > > Hi, Jaak,
> > >
> > > On Thu, Oct 26, 2023 at 2:49 AM Jaak Ristioja
> > > wrote:
> > > >
> > > > On 25.10.23 16:23, Huacai Chen wrote:
> > > >> On Wed, Oct 25, 2023 at 6:08 PM Thorsten Leemhuis
> > > >> wrote:
> > > >>>
> > > >>> Javier, Dave, Sima,
> > > >>>
> > > >>> On 23.10.23 00:54, Evan Preston wrote:
> > > On 2023-10-20 Fri 05:48pm, Huacai Chen wrote:
> > > > On Fri, Oct 20, 2023 at 5:35 PM Linux regression
> > > > tracking (Thorsten
> > > > Leemhuis) wrote:
> > > >> On 09.10.23 10:54, Huacai Chen wrote:
> > > >>> On Mon, Oct 9, 2023 at 4:45 PM Bagas Sanjaya
> > > >>> wrote:
> > > On Mon, Oct 09, 2023 at 09:27:02AM +0800, Huacai
> > > Chen wrote:
> > > > On Tue, Sep 26, 2023 at 10:31 PM Huacai Chen
> > > > wrote:
> > > >> On Tue, Sep 26, 2023 at 7:15 PM Linux regression
> > > >> tracking (Thorsten
> > > >> Leemhuis) wrote:
> > > >>> On 13.09.23 14:02, Jaak Ristioja wrote:
> > >
> > > Upgrading to Linux 6.5 on a Lenovo ThinkPad L570
> > > (Integrated Intel HD
> > > Graphics 620 (rev 02), Intel(R) Core(TM)
> > > i7-7500U) results in a blank
> > > screen after boot until the display manager
> > > starts... if it does start
> > > at all. Using the nomodeset kernel parameter
> > > seems to be a workaround.
> > >
> > > I've bisected this to commit
> > > 60aebc9559492cea6a9625f514a8041717e3a2e4
> > > ("drivers/firmware: Move sysfb_init() from
> > > device_initcall to
> > > subsys_initcall_sync").
> > > >>>
> > > > As confirmed by Jaak, disabling DRM_SIMPLEDRM makes
> > > > things work fine
> > > > again. So I guess the reason:
> > > >>
> > > >> Well, this to me still looks a lot (please correct me
> > > >> if I'm wrong) like
> > > >> regression that should be fixed, as DRM_SIMPLEDRM was
> > > >> enabled beforehand
> > > >> if I understood things correctly. Or is there a proper
> > > >> fix for this
> > > >> already in the works and I just missed this? Or is
> > > >> there some good
> > > >> reason why this won't/can't be fixed?
> > > >
> > > > DRM_SIMPLEDRM was enabled but it didn't work at all
> > > > because there was
> > > > no corresponding platform device. Now DRM_SIMPLEDRM
> > > > works but it has a
> > > > blank screen. Of course it is valuable to investigate
> > > > further about
> > > > DRM_SIMPLEDRM on Jaak's machine, but that needs Jaak's
> > > > effort because
> > > > I don't have a same machine.
> > > >>>
> > > >>> Side note: Huacai, have you tried working with Jaak to
Re: [RFC PATCH v3 09/12] net: add support for skbs with unreadable frags
On 11/6/23 5:20 PM, Mina Almasry wrote: > The user is free to modify or delete flow steering rules outside of the > lifetime of the socket. Technically it's possible for the user to > reconfigure flow steering while the socket is simultaneously receiving, > and the result will be packets switching from devmem to non-devmem. generically, from one page pool to another (ie., devmem piece of that statement is not relevant).
Re: [RFC PATCH v3 09/12] net: add support for skbs with unreadable frags
On 11/06, Mina Almasry wrote:
> On Mon, Nov 6, 2023 at 4:08 PM Willem de Bruijn
> wrote:
> >
> > On Mon, Nov 6, 2023 at 3:55 PM Stanislav Fomichev wrote:
> > >
> > > On Mon, Nov 6, 2023 at 3:27 PM Mina Almasry
> > > wrote:
> > > >
> > > > On Mon, Nov 6, 2023 at 2:59 PM Stanislav Fomichev
> > > > wrote:
> > > > >
> > > > > On 11/06, Mina Almasry wrote:
> > > > > > On Mon, Nov 6, 2023 at 1:59 PM Stanislav Fomichev
> > > > > > wrote:
> > > > > > >
> > > > > > > On 11/06, Mina Almasry wrote:
> > > > > > > > On Mon, Nov 6, 2023 at 11:34 AM David Ahern
> > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > On 11/6/23 11:47 AM, Stanislav Fomichev wrote:
> > > > > > > > > > On 11/05, Mina Almasry wrote:
> > > > > > > > > >> For device memory TCP, we expect the skb headers to be
> > > > > > > > > >> available in host
> > > > > > > > > >> memory for access, and we expect the skb frags to be in
> > > > > > > > > >> device memory
> > > > > > > > > >> and unaccessible to the host. We expect there to be no
> > > > > > > > > >> mixing and
> > > > > > > > > >> matching of device memory frags (unaccessible) with host
> > > > > > > > > >> memory frags
> > > > > > > > > >> (accessible) in the same skb.
> > > > > > > > > >>
> > > > > > > > > >> Add a skb->devmem flag which indicates whether the frags
> > > > > > > > > >> in this skb
> > > > > > > > > >> are device memory frags or not.
> > > > > > > > > >>
> > > > > > > > > >> __skb_fill_page_desc() now checks frags added to skbs for
> > > > > > > > > >> page_pool_iovs,
> > > > > > > > > >> and marks the skb as skb->devmem accordingly.
> > > > > > > > > >>
> > > > > > > > > >> Add checks through the network stack to avoid accessing
> > > > > > > > > >> the frags of
> > > > > > > > > >> devmem skbs and avoid coalescing devmem skbs with non
> > > > > > > > > >> devmem skbs.
> > > > > > > > > >>
> > > > > > > > > >> Signed-off-by: Willem de Bruijn
> > > > > > > > > >> Signed-off-by: Kaiyuan Zhang
> > > > > > > > > >> Signed-off-by: Mina Almasry
> > > > > > > > > >>
> > > > > > > > > >> ---
> > > > > > > > > >> include/linux/skbuff.h | 14 +++-
> > > > > > > > > >> include/net/tcp.h | 5 +--
> > > > > > > > > >> net/core/datagram.c| 6
> > > > > > > > > >> net/core/gro.c | 5 ++-
> > > > > > > > > >> net/core/skbuff.c | 77
> > > > > > > > > >> --
> > > > > > > > > >> net/ipv4/tcp.c | 6
> > > > > > > > > >> net/ipv4/tcp_input.c | 13 +--
> > > > > > > > > >> net/ipv4/tcp_output.c | 5 ++-
> > > > > > > > > >> net/packet/af_packet.c | 4 +--
> > > > > > > > > >> 9 files changed, 115 insertions(+), 20 deletions(-)
> > > > > > > > > >>
> > > > > > > > > >> diff --git a/include/linux/skbuff.h
> > > > > > > > > >> b/include/linux/skbuff.h
> > > > > > > > > >> index 1fae276c1353..8fb468ff8115 100644
> > > > > > > > > >> --- a/include/linux/skbuff.h
> > > > > > > > > >> +++ b/include/linux/skbuff.h
> > > > > > > > > >> @@ -805,6 +805,8 @@ typedef unsigned char *sk_buff_data_t;
> > > > > > > > > >> * @csum_level: indicates the number of consecutive
> > > > > > > > > >> checksums found in
> > > > > > > > > >> * the packet minus one that have been verified
> > > > > > > > > >> as
> > > > > > > > > >> * CHECKSUM_UNNECESSARY (max 3)
> > > > > > > > > >> + * @devmem: indicates that all the fragments in this skb
> > > > > > > > > >> are backed by
> > > > > > > > > >> + * device memory.
> > > > > > > > > >> * @dst_pending_confirm: need to confirm neighbour
> > > > > > > > > >> * @decrypted: Decrypted SKB
> > > > > > > > > >> * @slow_gro: state present at GRO time, slower prepare
> > > > > > > > > >> step required
> > > > > > > > > >> @@ -991,7 +993,7 @@ struct sk_buff {
> > > > > > > > > >> #if IS_ENABLED(CONFIG_IP_SCTP)
> > > > > > > > > >> __u8csum_not_inet:1;
> > > > > > > > > >> #endif
> > > > > > > > > >> -
> > > > > > > > > >> +__u8devmem:1;
> > > > > > > > > >> #if defined(CONFIG_NET_SCHED) ||
> > > > > > > > > >> defined(CONFIG_NET_XGRESS)
> > > > > > > > > >> __u16 tc_index; /* traffic
> > > > > > > > > >> control index */
> > > > > > > > > >> #endif
> > > > > > > > > >> @@ -1766,6 +1768,12 @@ static inline void
> > > > > > > > > >> skb_zcopy_downgrade_managed(struct sk_buff *skb)
> > > > > > > > > >> __skb_zcopy_downgrade_managed(skb);
> > > > > > > > > >> }
> > > > > > > > > >>
> > > > > > > > > >> +/* Return true if frags in this skb are not readable by
> > > > > > > > > >> the host. */
> > > > > > > > > >> +static inline bool skb_frags_not_readable(const struct
> > > > > > > > > >> sk_buff *skb)
> > > > > > > > > >> +{
> > > > > > > > > >> +return skb->devmem;
> > > > > > > > > >
> > > > > > > > > > bikeshedding: should we also rename 'devmem' sk_buff flag
> > > > > > > > > > to 'not_readable'?
> > > > > >
Re: [RFC PATCH v3 09/12] net: add support for skbs with unreadable frags
On 11/06, Stanislav Fomichev wrote:
> On 11/06, Willem de Bruijn wrote:
> > On Mon, Nov 6, 2023 at 3:55 PM Stanislav Fomichev wrote:
> > >
> > > On Mon, Nov 6, 2023 at 3:27 PM Mina Almasry
> > > wrote:
> > > >
> > > > On Mon, Nov 6, 2023 at 2:59 PM Stanislav Fomichev
> > > > wrote:
> > > > >
> > > > > On 11/06, Mina Almasry wrote:
> > > > > > On Mon, Nov 6, 2023 at 1:59 PM Stanislav Fomichev
> > > > > > wrote:
> > > > > > >
> > > > > > > On 11/06, Mina Almasry wrote:
> > > > > > > > On Mon, Nov 6, 2023 at 11:34 AM David Ahern
> > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > On 11/6/23 11:47 AM, Stanislav Fomichev wrote:
> > > > > > > > > > On 11/05, Mina Almasry wrote:
> > > > > > > > > >> For device memory TCP, we expect the skb headers to be
> > > > > > > > > >> available in host
> > > > > > > > > >> memory for access, and we expect the skb frags to be in
> > > > > > > > > >> device memory
> > > > > > > > > >> and unaccessible to the host. We expect there to be no
> > > > > > > > > >> mixing and
> > > > > > > > > >> matching of device memory frags (unaccessible) with host
> > > > > > > > > >> memory frags
> > > > > > > > > >> (accessible) in the same skb.
> > > > > > > > > >>
> > > > > > > > > >> Add a skb->devmem flag which indicates whether the frags
> > > > > > > > > >> in this skb
> > > > > > > > > >> are device memory frags or not.
> > > > > > > > > >>
> > > > > > > > > >> __skb_fill_page_desc() now checks frags added to skbs for
> > > > > > > > > >> page_pool_iovs,
> > > > > > > > > >> and marks the skb as skb->devmem accordingly.
> > > > > > > > > >>
> > > > > > > > > >> Add checks through the network stack to avoid accessing
> > > > > > > > > >> the frags of
> > > > > > > > > >> devmem skbs and avoid coalescing devmem skbs with non
> > > > > > > > > >> devmem skbs.
> > > > > > > > > >>
> > > > > > > > > >> Signed-off-by: Willem de Bruijn
> > > > > > > > > >> Signed-off-by: Kaiyuan Zhang
> > > > > > > > > >> Signed-off-by: Mina Almasry
> > > > > > > > > >>
> > > > > > > > > >> ---
> > > > > > > > > >> include/linux/skbuff.h | 14 +++-
> > > > > > > > > >> include/net/tcp.h | 5 +--
> > > > > > > > > >> net/core/datagram.c| 6
> > > > > > > > > >> net/core/gro.c | 5 ++-
> > > > > > > > > >> net/core/skbuff.c | 77
> > > > > > > > > >> --
> > > > > > > > > >> net/ipv4/tcp.c | 6
> > > > > > > > > >> net/ipv4/tcp_input.c | 13 +--
> > > > > > > > > >> net/ipv4/tcp_output.c | 5 ++-
> > > > > > > > > >> net/packet/af_packet.c | 4 +--
> > > > > > > > > >> 9 files changed, 115 insertions(+), 20 deletions(-)
> > > > > > > > > >>
> > > > > > > > > >> diff --git a/include/linux/skbuff.h
> > > > > > > > > >> b/include/linux/skbuff.h
> > > > > > > > > >> index 1fae276c1353..8fb468ff8115 100644
> > > > > > > > > >> --- a/include/linux/skbuff.h
> > > > > > > > > >> +++ b/include/linux/skbuff.h
> > > > > > > > > >> @@ -805,6 +805,8 @@ typedef unsigned char *sk_buff_data_t;
> > > > > > > > > >> * @csum_level: indicates the number of consecutive
> > > > > > > > > >> checksums found in
> > > > > > > > > >> * the packet minus one that have been verified
> > > > > > > > > >> as
> > > > > > > > > >> * CHECKSUM_UNNECESSARY (max 3)
> > > > > > > > > >> + * @devmem: indicates that all the fragments in this skb
> > > > > > > > > >> are backed by
> > > > > > > > > >> + * device memory.
> > > > > > > > > >> * @dst_pending_confirm: need to confirm neighbour
> > > > > > > > > >> * @decrypted: Decrypted SKB
> > > > > > > > > >> * @slow_gro: state present at GRO time, slower prepare
> > > > > > > > > >> step required
> > > > > > > > > >> @@ -991,7 +993,7 @@ struct sk_buff {
> > > > > > > > > >> #if IS_ENABLED(CONFIG_IP_SCTP)
> > > > > > > > > >> __u8csum_not_inet:1;
> > > > > > > > > >> #endif
> > > > > > > > > >> -
> > > > > > > > > >> +__u8devmem:1;
> > > > > > > > > >> #if defined(CONFIG_NET_SCHED) ||
> > > > > > > > > >> defined(CONFIG_NET_XGRESS)
> > > > > > > > > >> __u16 tc_index; /* traffic
> > > > > > > > > >> control index */
> > > > > > > > > >> #endif
> > > > > > > > > >> @@ -1766,6 +1768,12 @@ static inline void
> > > > > > > > > >> skb_zcopy_downgrade_managed(struct sk_buff *skb)
> > > > > > > > > >> __skb_zcopy_downgrade_managed(skb);
> > > > > > > > > >> }
> > > > > > > > > >>
> > > > > > > > > >> +/* Return true if frags in this skb are not readable by
> > > > > > > > > >> the host. */
> > > > > > > > > >> +static inline bool skb_frags_not_readable(const struct
> > > > > > > > > >> sk_buff *skb)
> > > > > > > > > >> +{
> > > > > > > > > >> +return skb->devmem;
> > > > > > > > > >
> > > > > > > > > > bikeshedding: should we also rename 'devmem' sk_buff flag
> > > > > > > > > > to 'not_readable'?
> > > > > > > > > > It better
[PATCH] drm/msm/dp: call dp_display_get_next_bridge() during probe
The funcion dp_display_get_next_bridge() can return -EPROBE_DEFER if the
next bridge is not (yet) available. However returning -EPROBE_DEFER from
msm_dp_modeset_init() is not ideal. This leads to -EPROBE return from
component_bind, which can easily result in -EPROBE_DEFR loops.
Signed-off-by: Dmitry Baryshkov
---
Dependencies: https://patchwork.freedesktop.org/series/120375/
---
drivers/gpu/drm/msm/dp/dp_display.c | 36 +
1 file changed, 21 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b/drivers/gpu/drm/msm/dp/dp_display.c
index d542db37763a..ddb3c84f39a2 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -1197,15 +1197,27 @@ static const struct msm_dp_desc
*dp_display_get_desc(struct platform_device *pde
return NULL;
}
-static int dp_auxbus_done_probe(struct drm_dp_aux *aux)
+static int dp_display_get_next_bridge(struct msm_dp *dp);
+
+static int dp_display_probe_tail(struct device *dev)
{
- int rc;
+ struct msm_dp *dp = dev_get_drvdata(dev);
+ int ret;
- rc = component_add(aux->dev, _display_comp_ops);
- if (rc)
- DRM_ERROR("eDP component add failed, rc=%d\n", rc);
+ ret = dp_display_get_next_bridge(dp);
+ if (ret)
+ return ret;
- return rc;
+ ret = component_add(dev, _display_comp_ops);
+ if (ret)
+ DRM_ERROR("component add failed, rc=%d\n", ret);
+
+ return ret;
+}
+
+static int dp_auxbus_done_probe(struct drm_dp_aux *aux)
+{
+ return dp_display_probe_tail(aux->dev);
}
static int dp_display_probe(struct platform_device *pdev)
@@ -1280,11 +1292,9 @@ static int dp_display_probe(struct platform_device *pdev)
goto err;
}
} else {
- rc = component_add(>dev, _display_comp_ops);
- if (rc) {
- DRM_ERROR("component add failed, rc=%d\n", rc);
+ rc = dp_display_probe_tail(>dev);
+ if (rc)
goto err;
- }
}
return rc;
@@ -1415,7 +1425,7 @@ static int dp_display_get_next_bridge(struct msm_dp *dp)
* For DisplayPort interfaces external bridges are optional, so
* silently ignore an error if one is not present (-ENODEV).
*/
- rc = devm_dp_parser_find_next_bridge(dp->drm_dev->dev, dp_priv->parser);
+ rc = devm_dp_parser_find_next_bridge(>pdev->dev, dp_priv->parser);
if (!dp->is_edp && rc == -ENODEV)
return 0;
@@ -1435,10 +1445,6 @@ int msm_dp_modeset_init(struct msm_dp *dp_display,
struct drm_device *dev,
dp_priv = container_of(dp_display, struct dp_display_private,
dp_display);
- ret = dp_display_get_next_bridge(dp_display);
- if (ret)
- return ret;
-
ret = dp_bridge_init(dp_display, dev, encoder);
if (ret) {
DRM_DEV_ERROR(dev->dev,
--
2.42.0
Re: [PATCH v2] drm: amd: Resolve Sphinx unexpected indentation warning
On Mon, Nov 06, 2023 at 03:17:39PM -0500, Hunter Chasens wrote: > diff --git a/drivers/gpu/drm/amd/pm/amdgpu_pm.c > b/drivers/gpu/drm/amd/pm/amdgpu_pm.c > index 517b9fb4624c..81b8ceb26890 100644 > --- a/drivers/gpu/drm/amd/pm/amdgpu_pm.c > +++ b/drivers/gpu/drm/amd/pm/amdgpu_pm.c > @@ -989,12 +989,13 @@ static ssize_t amdgpu_get_pp_features(struct device > *dev, > * Reading back the files will show you the available power levels within > * the power state and the clock information for those levels. If deep sleep > is > * applied to a clock, the level will be denoted by a special level 'S:' > - * E.g., > - * S: 19Mhz * > - * 0: 615Mhz > - * 1: 800Mhz > - * 2: 888Mhz > - * 3: 1000Mhz > + * E.g.:: > + * > + * S: 19Mhz * > + * 0: 615Mhz > + * 1: 800Mhz > + * 2: 888Mhz > + * 3: 1000Mhz > * > * > * To manually adjust these states, first select manual using LGTM, thanks! Reviewed-by: Bagas Sanjaya -- An old man doll... just what I always wanted! - Clara signature.asc Description: PGP signature
Re: [RFC PATCH v3 09/12] net: add support for skbs with unreadable frags
On Mon, Nov 6, 2023 at 4:16 PM David Ahern wrote:
>
> On 11/5/23 7:44 PM, Mina Almasry wrote:
> > diff --git a/net/core/datagram.c b/net/core/datagram.c
> > index 176eb5834746..cdd4fb129968 100644
> > --- a/net/core/datagram.c
> > +++ b/net/core/datagram.c
> > @@ -425,6 +425,9 @@ static int __skb_datagram_iter(const struct sk_buff
> > *skb, int offset,
> > return 0;
> > }
> >
> > + if (skb_frags_not_readable(skb))
> > + goto short_copy;
> > +
> > /* Copy paged appendix. Hmm... why does this look so complicated? */
> > for (i = 0; i < skb_shinfo(skb)->nr_frags; i++) {
> > int end;
> > @@ -616,6 +619,9 @@ int __zerocopy_sg_from_iter(struct msghdr *msg, struct
> > sock *sk,
> > {
> > int frag;
> >
> > + if (skb_frags_not_readable(skb))
> > + return -EFAULT;
>
> This check
> > +
> > if (msg && msg->msg_ubuf && msg->sg_from_iter)
> > return msg->sg_from_iter(sk, skb, from, length);
>
>
> ... should go here. That allows custome sg_from_iter to have access to
> the skb. What matters is not expecting struct page (e.g., refcounting);
> if the custom iter does not do that then all is well. io_uring's iter
> does not look at the pages, so all good.
>
> >
> > diff --git a/net/core/gro.c b/net/core/gro.c
> > index 42d7f6755f32..56046d65386a 100644
> > --- a/net/core/gro.c
> > +++ b/net/core/gro.c
> > @@ -390,6 +390,9 @@ static void gro_pull_from_frag0(struct sk_buff *skb,
> > int grow)
> > {
> > struct skb_shared_info *pinfo = skb_shinfo(skb);
> >
> > + if (WARN_ON_ONCE(skb_frags_not_readable(skb)))
> > + return;
> > +
> > BUG_ON(skb->end - skb->tail < grow);
> >
> > memcpy(skb_tail_pointer(skb), NAPI_GRO_CB(skb)->frag0, grow);
> > @@ -411,7 +414,7 @@ static void gro_try_pull_from_frag0(struct sk_buff *skb)
> > {
> > int grow = skb_gro_offset(skb) - skb_headlen(skb);
> >
> > - if (grow > 0)
> > + if (grow > 0 && !skb_frags_not_readable(skb))
> > gro_pull_from_frag0(skb, grow);
> > }
> >
> > diff --git a/net/core/skbuff.c b/net/core/skbuff.c
> > index 13eca4fd25e1..f01673ed2eff 100644
> > --- a/net/core/skbuff.c
> > +++ b/net/core/skbuff.c
> > @@ -1230,6 +1230,14 @@ void skb_dump(const char *level, const struct
> > sk_buff *skb, bool full_pkt)
> > struct page *p;
> > u8 *vaddr;
> >
> > + if (skb_frag_is_page_pool_iov(frag)) {
>
> Why skb_frag_is_page_pool_iov here vs skb_frags_not_readable?
Seems like a silly choice on my end. I should probably check
skb_frags_not_readable() and not kmap any frags in that case. Will do.
--
Thanks,
Mina
Re: [RFC PATCH v3 09/12] net: add support for skbs with unreadable frags
On Mon, Nov 6, 2023 at 4:08 PM Willem de Bruijn
wrote:
>
> On Mon, Nov 6, 2023 at 3:55 PM Stanislav Fomichev wrote:
> >
> > On Mon, Nov 6, 2023 at 3:27 PM Mina Almasry wrote:
> > >
> > > On Mon, Nov 6, 2023 at 2:59 PM Stanislav Fomichev wrote:
> > > >
> > > > On 11/06, Mina Almasry wrote:
> > > > > On Mon, Nov 6, 2023 at 1:59 PM Stanislav Fomichev
> > > > > wrote:
> > > > > >
> > > > > > On 11/06, Mina Almasry wrote:
> > > > > > > On Mon, Nov 6, 2023 at 11:34 AM David Ahern
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > On 11/6/23 11:47 AM, Stanislav Fomichev wrote:
> > > > > > > > > On 11/05, Mina Almasry wrote:
> > > > > > > > >> For device memory TCP, we expect the skb headers to be
> > > > > > > > >> available in host
> > > > > > > > >> memory for access, and we expect the skb frags to be in
> > > > > > > > >> device memory
> > > > > > > > >> and unaccessible to the host. We expect there to be no
> > > > > > > > >> mixing and
> > > > > > > > >> matching of device memory frags (unaccessible) with host
> > > > > > > > >> memory frags
> > > > > > > > >> (accessible) in the same skb.
> > > > > > > > >>
> > > > > > > > >> Add a skb->devmem flag which indicates whether the frags in
> > > > > > > > >> this skb
> > > > > > > > >> are device memory frags or not.
> > > > > > > > >>
> > > > > > > > >> __skb_fill_page_desc() now checks frags added to skbs for
> > > > > > > > >> page_pool_iovs,
> > > > > > > > >> and marks the skb as skb->devmem accordingly.
> > > > > > > > >>
> > > > > > > > >> Add checks through the network stack to avoid accessing the
> > > > > > > > >> frags of
> > > > > > > > >> devmem skbs and avoid coalescing devmem skbs with non devmem
> > > > > > > > >> skbs.
> > > > > > > > >>
> > > > > > > > >> Signed-off-by: Willem de Bruijn
> > > > > > > > >> Signed-off-by: Kaiyuan Zhang
> > > > > > > > >> Signed-off-by: Mina Almasry
> > > > > > > > >>
> > > > > > > > >> ---
> > > > > > > > >> include/linux/skbuff.h | 14 +++-
> > > > > > > > >> include/net/tcp.h | 5 +--
> > > > > > > > >> net/core/datagram.c| 6
> > > > > > > > >> net/core/gro.c | 5 ++-
> > > > > > > > >> net/core/skbuff.c | 77
> > > > > > > > >> --
> > > > > > > > >> net/ipv4/tcp.c | 6
> > > > > > > > >> net/ipv4/tcp_input.c | 13 +--
> > > > > > > > >> net/ipv4/tcp_output.c | 5 ++-
> > > > > > > > >> net/packet/af_packet.c | 4 +--
> > > > > > > > >> 9 files changed, 115 insertions(+), 20 deletions(-)
> > > > > > > > >>
> > > > > > > > >> diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
> > > > > > > > >> index 1fae276c1353..8fb468ff8115 100644
> > > > > > > > >> --- a/include/linux/skbuff.h
> > > > > > > > >> +++ b/include/linux/skbuff.h
> > > > > > > > >> @@ -805,6 +805,8 @@ typedef unsigned char *sk_buff_data_t;
> > > > > > > > >> * @csum_level: indicates the number of consecutive
> > > > > > > > >> checksums found in
> > > > > > > > >> * the packet minus one that have been verified as
> > > > > > > > >> * CHECKSUM_UNNECESSARY (max 3)
> > > > > > > > >> + * @devmem: indicates that all the fragments in this skb
> > > > > > > > >> are backed by
> > > > > > > > >> + * device memory.
> > > > > > > > >> * @dst_pending_confirm: need to confirm neighbour
> > > > > > > > >> * @decrypted: Decrypted SKB
> > > > > > > > >> * @slow_gro: state present at GRO time, slower prepare
> > > > > > > > >> step required
> > > > > > > > >> @@ -991,7 +993,7 @@ struct sk_buff {
> > > > > > > > >> #if IS_ENABLED(CONFIG_IP_SCTP)
> > > > > > > > >> __u8csum_not_inet:1;
> > > > > > > > >> #endif
> > > > > > > > >> -
> > > > > > > > >> +__u8devmem:1;
> > > > > > > > >> #if defined(CONFIG_NET_SCHED) || defined(CONFIG_NET_XGRESS)
> > > > > > > > >> __u16 tc_index; /* traffic
> > > > > > > > >> control index */
> > > > > > > > >> #endif
> > > > > > > > >> @@ -1766,6 +1768,12 @@ static inline void
> > > > > > > > >> skb_zcopy_downgrade_managed(struct sk_buff *skb)
> > > > > > > > >> __skb_zcopy_downgrade_managed(skb);
> > > > > > > > >> }
> > > > > > > > >>
> > > > > > > > >> +/* Return true if frags in this skb are not readable by the
> > > > > > > > >> host. */
> > > > > > > > >> +static inline bool skb_frags_not_readable(const struct
> > > > > > > > >> sk_buff *skb)
> > > > > > > > >> +{
> > > > > > > > >> +return skb->devmem;
> > > > > > > > >
> > > > > > > > > bikeshedding: should we also rename 'devmem' sk_buff flag to
> > > > > > > > > 'not_readable'?
> > > > > > > > > It better communicates the fact that the stack shouldn't
> > > > > > > > > dereference the
> > > > > > > > > frags (because it has 'devmem' fragments or for some other
> > > > > > > > > potential
> > > > > > > > > future reason).
> > > > > > > >
> > > > > > > > +1.
> > > > > > > >
> > > > > > > >
Re: [RFC PATCH v3 09/12] net: add support for skbs with unreadable frags
On 11/5/23 7:44 PM, Mina Almasry wrote:
> diff --git a/net/core/datagram.c b/net/core/datagram.c
> index 176eb5834746..cdd4fb129968 100644
> --- a/net/core/datagram.c
> +++ b/net/core/datagram.c
> @@ -425,6 +425,9 @@ static int __skb_datagram_iter(const struct sk_buff *skb,
> int offset,
> return 0;
> }
>
> + if (skb_frags_not_readable(skb))
> + goto short_copy;
> +
> /* Copy paged appendix. Hmm... why does this look so complicated? */
> for (i = 0; i < skb_shinfo(skb)->nr_frags; i++) {
> int end;
> @@ -616,6 +619,9 @@ int __zerocopy_sg_from_iter(struct msghdr *msg, struct
> sock *sk,
> {
> int frag;
>
> + if (skb_frags_not_readable(skb))
> + return -EFAULT;
This check
> +
> if (msg && msg->msg_ubuf && msg->sg_from_iter)
> return msg->sg_from_iter(sk, skb, from, length);
... should go here. That allows custome sg_from_iter to have access to
the skb. What matters is not expecting struct page (e.g., refcounting);
if the custom iter does not do that then all is well. io_uring's iter
does not look at the pages, so all good.
>
> diff --git a/net/core/gro.c b/net/core/gro.c
> index 42d7f6755f32..56046d65386a 100644
> --- a/net/core/gro.c
> +++ b/net/core/gro.c
> @@ -390,6 +390,9 @@ static void gro_pull_from_frag0(struct sk_buff *skb, int
> grow)
> {
> struct skb_shared_info *pinfo = skb_shinfo(skb);
>
> + if (WARN_ON_ONCE(skb_frags_not_readable(skb)))
> + return;
> +
> BUG_ON(skb->end - skb->tail < grow);
>
> memcpy(skb_tail_pointer(skb), NAPI_GRO_CB(skb)->frag0, grow);
> @@ -411,7 +414,7 @@ static void gro_try_pull_from_frag0(struct sk_buff *skb)
> {
> int grow = skb_gro_offset(skb) - skb_headlen(skb);
>
> - if (grow > 0)
> + if (grow > 0 && !skb_frags_not_readable(skb))
> gro_pull_from_frag0(skb, grow);
> }
>
> diff --git a/net/core/skbuff.c b/net/core/skbuff.c
> index 13eca4fd25e1..f01673ed2eff 100644
> --- a/net/core/skbuff.c
> +++ b/net/core/skbuff.c
> @@ -1230,6 +1230,14 @@ void skb_dump(const char *level, const struct sk_buff
> *skb, bool full_pkt)
> struct page *p;
> u8 *vaddr;
>
> + if (skb_frag_is_page_pool_iov(frag)) {
Why skb_frag_is_page_pool_iov here vs skb_frags_not_readable?
[PATCH v5 09/30] drm/dp: Add helpers to calculate the link BW overhead
Add helpers drivers can use to calculate the BW allocation overhead -
due to SSC, FEC, DSC and data alignment on symbol cycles - and the
channel coding efficiency - due to the 8b/10b, 128b/132b encoding. On
128b/132b links the FEC overhead is part of the coding efficiency, so
not accounted for in the BW allocation overhead.
The drivers can use these functions to calculate a ratio, controlling
the stream symbol insertion rate of the source device in each SST TU
or MST MTP frame. Drivers can calculate this
m/n = (pixel_data_rate * drm_dp_bw_overhead()) /
(link_data_rate * drm_dp_bw_channel_coding_efficiency())
ratio for a given link and pixel stream and with that the
slots_per_mtp = CEIL(64 * m / n)
allocated slots per MTP for the stream in a link frame and with
that the
pbn = slots_per_mtp * drm_mst_get_pbn_divider()
allocated PBNs for the stream on the MST link path.
Take drm_dp_bw_overhead() into use in drm_dp_calc_pbn_mode(), for
drivers calculating the PBN value directly.
v2:
- Add dockbook description to drm_dp_bw_channel_coding_efficiency().
(LKP).
- Clarify the way m/n ratio is calculated in the commit log.
v3:
- Fix compile breakage for !CONFIG_BACKLIGHT_CLASS_DEVICE. (LKP)
- Account for FEC_PM overhead (+ 0.0015625 %), add comment
with the formula to calculate the total FEC overhead. (Ville)
v4:
- Rename DRM_DP_OVERHEAD_SSC to DRM_DP_OVERHEAD_SSC_REF_CLK. (Ville)
v5:
- Clarify in the commit log what MTP means.
- Simplify the commit log's formula to calculate PBN.
Cc: Lyude Paul
Cc: Ville Syrjälä
Cc: kernel test robot
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Stanislav Lisovskiy (v2)
Acked-by: Maxime Ripard
Signed-off-by: Imre Deak
---
drivers/gpu/drm/display/drm_dp_helper.c | 132 ++
drivers/gpu/drm/display/drm_dp_mst_topology.c | 23 ++-
include/drm/display/drm_dp_helper.h | 11 ++
3 files changed, 160 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/display/drm_dp_helper.c
b/drivers/gpu/drm/display/drm_dp_helper.c
index e5d7970a9ddd0..72ba9ae89f862 100644
--- a/drivers/gpu/drm/display/drm_dp_helper.c
+++ b/drivers/gpu/drm/display/drm_dp_helper.c
@@ -3900,3 +3900,135 @@ int drm_panel_dp_aux_backlight(struct drm_panel *panel,
struct drm_dp_aux *aux)
EXPORT_SYMBOL(drm_panel_dp_aux_backlight);
#endif
+
+/* See DP Standard v2.1 2.6.4.4.1.1, 2.8.4.4, 2.8.7 */
+static int drm_dp_link_symbol_cycles(int lane_count, int pixels, int bpp_x16,
+int symbol_size, bool is_mst)
+{
+ int cycles = DIV_ROUND_UP(pixels * bpp_x16, 16 * symbol_size *
lane_count);
+ int align = is_mst ? 4 / lane_count : 1;
+
+ return ALIGN(cycles, align);
+}
+
+static int drm_dp_link_dsc_symbol_cycles(int lane_count, int pixels, int
slice_count,
+int bpp_x16, int symbol_size, bool
is_mst)
+{
+ int slice_pixels = DIV_ROUND_UP(pixels, slice_count);
+ int slice_data_cycles = drm_dp_link_symbol_cycles(lane_count,
slice_pixels,
+ bpp_x16, symbol_size,
is_mst);
+ int slice_eoc_cycles = is_mst ? 4 / lane_count : 1;
+
+ return slice_count * (slice_data_cycles + slice_eoc_cycles);
+}
+
+/**
+ * drm_dp_bw_overhead - Calculate the BW overhead of a DP link stream
+ * @lane_count: DP link lane count
+ * @hactive: pixel count of the active period in one scanline of the stream
+ * @dsc_slice_count: DSC slice count if @flags/DRM_DP_LINK_BW_OVERHEAD_DSC is
set
+ * @bpp_x16: bits per pixel in .4 binary fixed point
+ * @flags: DRM_DP_OVERHEAD_x flags
+ *
+ * Calculate the BW allocation overhead of a DP link stream, depending
+ * on the link's
+ * - @lane_count
+ * - SST/MST mode (@flags / %DRM_DP_OVERHEAD_MST)
+ * - symbol size (@flags / %DRM_DP_OVERHEAD_UHBR)
+ * - FEC mode (@flags / %DRM_DP_OVERHEAD_FEC)
+ * - SSC/REF_CLK mode (@flags / %DRM_DP_OVERHEAD_SSC_REF_CLK)
+ * as well as the stream's
+ * - @hactive timing
+ * - @bpp_x16 color depth
+ * - compression mode (@flags / %DRM_DP_OVERHEAD_DSC).
+ * Note that this overhead doesn't account for the 8b/10b, 128b/132b
+ * channel coding efficiency, for that see
+ * @drm_dp_link_bw_channel_coding_efficiency().
+ *
+ * Returns the overhead as 100% + overhead% in 1ppm units.
+ */
+int drm_dp_bw_overhead(int lane_count, int hactive,
+ int dsc_slice_count,
+ int bpp_x16, unsigned long flags)
+{
+ int symbol_size = flags & DRM_DP_BW_OVERHEAD_UHBR ? 32 : 8;
+ bool is_mst = flags & DRM_DP_BW_OVERHEAD_MST;
+ u32 overhead = 100;
+ int symbol_cycles;
+
+ /*
+* DP Standard v2.1 2.6.4.1
+* SSC downspread and ref clock variation margin:
+* 5300ppm + 300ppm ~ 0.6%
+*/
+ if (flags & DRM_DP_BW_OVERHEAD_SSC_REF_CLK)
+ overhead += 6000;
+
+ /*
+* DP Standard v2.1 2.6.4.1.1, 3.5.1.5.4:
+* FEC symbol insertions for
Re: [RFC PATCH v3 09/12] net: add support for skbs with unreadable frags
On 11/06, Willem de Bruijn wrote:
> On Mon, Nov 6, 2023 at 3:55 PM Stanislav Fomichev wrote:
> >
> > On Mon, Nov 6, 2023 at 3:27 PM Mina Almasry wrote:
> > >
> > > On Mon, Nov 6, 2023 at 2:59 PM Stanislav Fomichev wrote:
> > > >
> > > > On 11/06, Mina Almasry wrote:
> > > > > On Mon, Nov 6, 2023 at 1:59 PM Stanislav Fomichev
> > > > > wrote:
> > > > > >
> > > > > > On 11/06, Mina Almasry wrote:
> > > > > > > On Mon, Nov 6, 2023 at 11:34 AM David Ahern
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > On 11/6/23 11:47 AM, Stanislav Fomichev wrote:
> > > > > > > > > On 11/05, Mina Almasry wrote:
> > > > > > > > >> For device memory TCP, we expect the skb headers to be
> > > > > > > > >> available in host
> > > > > > > > >> memory for access, and we expect the skb frags to be in
> > > > > > > > >> device memory
> > > > > > > > >> and unaccessible to the host. We expect there to be no
> > > > > > > > >> mixing and
> > > > > > > > >> matching of device memory frags (unaccessible) with host
> > > > > > > > >> memory frags
> > > > > > > > >> (accessible) in the same skb.
> > > > > > > > >>
> > > > > > > > >> Add a skb->devmem flag which indicates whether the frags in
> > > > > > > > >> this skb
> > > > > > > > >> are device memory frags or not.
> > > > > > > > >>
> > > > > > > > >> __skb_fill_page_desc() now checks frags added to skbs for
> > > > > > > > >> page_pool_iovs,
> > > > > > > > >> and marks the skb as skb->devmem accordingly.
> > > > > > > > >>
> > > > > > > > >> Add checks through the network stack to avoid accessing the
> > > > > > > > >> frags of
> > > > > > > > >> devmem skbs and avoid coalescing devmem skbs with non devmem
> > > > > > > > >> skbs.
> > > > > > > > >>
> > > > > > > > >> Signed-off-by: Willem de Bruijn
> > > > > > > > >> Signed-off-by: Kaiyuan Zhang
> > > > > > > > >> Signed-off-by: Mina Almasry
> > > > > > > > >>
> > > > > > > > >> ---
> > > > > > > > >> include/linux/skbuff.h | 14 +++-
> > > > > > > > >> include/net/tcp.h | 5 +--
> > > > > > > > >> net/core/datagram.c| 6
> > > > > > > > >> net/core/gro.c | 5 ++-
> > > > > > > > >> net/core/skbuff.c | 77
> > > > > > > > >> --
> > > > > > > > >> net/ipv4/tcp.c | 6
> > > > > > > > >> net/ipv4/tcp_input.c | 13 +--
> > > > > > > > >> net/ipv4/tcp_output.c | 5 ++-
> > > > > > > > >> net/packet/af_packet.c | 4 +--
> > > > > > > > >> 9 files changed, 115 insertions(+), 20 deletions(-)
> > > > > > > > >>
> > > > > > > > >> diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
> > > > > > > > >> index 1fae276c1353..8fb468ff8115 100644
> > > > > > > > >> --- a/include/linux/skbuff.h
> > > > > > > > >> +++ b/include/linux/skbuff.h
> > > > > > > > >> @@ -805,6 +805,8 @@ typedef unsigned char *sk_buff_data_t;
> > > > > > > > >> * @csum_level: indicates the number of consecutive
> > > > > > > > >> checksums found in
> > > > > > > > >> * the packet minus one that have been verified as
> > > > > > > > >> * CHECKSUM_UNNECESSARY (max 3)
> > > > > > > > >> + * @devmem: indicates that all the fragments in this skb
> > > > > > > > >> are backed by
> > > > > > > > >> + * device memory.
> > > > > > > > >> * @dst_pending_confirm: need to confirm neighbour
> > > > > > > > >> * @decrypted: Decrypted SKB
> > > > > > > > >> * @slow_gro: state present at GRO time, slower prepare
> > > > > > > > >> step required
> > > > > > > > >> @@ -991,7 +993,7 @@ struct sk_buff {
> > > > > > > > >> #if IS_ENABLED(CONFIG_IP_SCTP)
> > > > > > > > >> __u8csum_not_inet:1;
> > > > > > > > >> #endif
> > > > > > > > >> -
> > > > > > > > >> +__u8devmem:1;
> > > > > > > > >> #if defined(CONFIG_NET_SCHED) || defined(CONFIG_NET_XGRESS)
> > > > > > > > >> __u16 tc_index; /* traffic
> > > > > > > > >> control index */
> > > > > > > > >> #endif
> > > > > > > > >> @@ -1766,6 +1768,12 @@ static inline void
> > > > > > > > >> skb_zcopy_downgrade_managed(struct sk_buff *skb)
> > > > > > > > >> __skb_zcopy_downgrade_managed(skb);
> > > > > > > > >> }
> > > > > > > > >>
> > > > > > > > >> +/* Return true if frags in this skb are not readable by the
> > > > > > > > >> host. */
> > > > > > > > >> +static inline bool skb_frags_not_readable(const struct
> > > > > > > > >> sk_buff *skb)
> > > > > > > > >> +{
> > > > > > > > >> +return skb->devmem;
> > > > > > > > >
> > > > > > > > > bikeshedding: should we also rename 'devmem' sk_buff flag to
> > > > > > > > > 'not_readable'?
> > > > > > > > > It better communicates the fact that the stack shouldn't
> > > > > > > > > dereference the
> > > > > > > > > frags (because it has 'devmem' fragments or for some other
> > > > > > > > > potential
> > > > > > > > > future reason).
> > > > > > > >
> > > > > > > > +1.
> > > > > > > >
> > > > > > > > Also, the flag on the skb is
Re: [PATCH v1] docs: gpu: rfc: i915_scheduler.rst remove unused directives for namespacing
On 07/11/2023 02:41, Jani Nikula wrote:
> On Mon, 06 Nov 2023, Hunter Chasens wrote:
>> When running `make htmldocs` the following warnings are given.
>>
>> ```
>> Documentation/gpu/rfc/i915_scheduler.rst:138: WARNING:
>> Unknown directive type "c:namespace-push".
>>
>> .. c:namespace-push:: rfc
>> Documentation/gpu/rfc/i915_scheduler.rst:143: WARNING:
>> Unknown directive type "c:namespace-pop".
>>
>> .. c:namespace-pop::
>> ```
>>
>> The kernel test robot also reported it here.
>> Link: https://lore.kernel.org/all/202311061623.86ptqrie-...@intel.com/
>>
>> Last year Maryam Tahhan from Redhat noticed something
>> similar. "The missing support of c:namespace-push:: and c:namespace-pop::
>> directives by helper scripts for kernel documentation prevents using the
>> ``c:function::`` directive with proper namespacing." From the context, it
>> sounds like this was brought about from a Sphinx update.
>>
>> Link: https://lore.kernel.org/all/20221123092321.88558-3-mtah...@redhat.com/
>>
>> When compiled the `.. kernel-doc::` literal gives it the same formatting with
>> or without the namespace directives present. Due to the above information I
>> think it safe to remove these, as they don't seem to do anything but
>> throw warnings.
>
> Not so fast!
>
> Looks like this is because namespacing was introduced in Sphinx 3.1
> [1]. With earlier Sphinx, you get a warning about the namespace
> directives.
>
> However, with newer Sphinx, you get the warning mentioned in commit
> f6757dfcfde7 ("drm/doc: fix duplicate declaration warning") if you
> remove the namespace directives:
>
> linux/Documentation/gpu/driver-uapi.rst:2279: WARNING: Duplicate C
> declaration, also defined at rfc/i915_scheduler:3.
> Declaration is '.. c:struct:: i915_context_engines_parallel_submit'.
>
> It would be short-sighted to just remove the directives. Sooner or later
> we're gong to bump the (IMO extremely conservative) minimum version
> requirement.
>
OK, thanks for explanation!
--
An old man doll... just what I always wanted! - Clara
Re: [PATCH v1] docs: gpu: rfc: i915_scheduler.rst remove unused directives for namespacing
On 06/11/2023 17:31, Jani Nikula wrote: > On Mon, 06 Nov 2023, Bagas Sanjaya wrote: >> On Sat, Nov 04, 2023 at 09:47:08AM -0400, Hunter Chasens wrote: >>> diff --git a/Documentation/gpu/rfc/i915_scheduler.rst >>> b/Documentation/gpu/rfc/i915_scheduler.rst >>> index c237ebc024cd..23ba7006929b 100644 >>> --- a/Documentation/gpu/rfc/i915_scheduler.rst >>> +++ b/Documentation/gpu/rfc/i915_scheduler.rst >>> @@ -135,13 +135,9 @@ Add I915_CONTEXT_ENGINES_EXT_PARALLEL_SUBMIT and >>> drm_i915_context_engines_parallel_submit to the uAPI to implement this >>> extension. >>> >>> -.. c:namespace-push:: rfc >>> - >>> .. kernel-doc:: include/uapi/drm/i915_drm.h >>> :functions: i915_context_engines_parallel_submit >>> >>> -.. c:namespace-pop:: >>> - > > What makes the namespacing unnecessary? > > $ git grep '.. kernel-doc:: include/uapi/drm/i915_drm.h' > Documentation/gpu/driver-uapi.rst:.. kernel-doc:: include/uapi/drm/i915_drm.h > Documentation/gpu/rfc/i915_scheduler.rst:.. kernel-doc:: > include/uapi/drm/i915_drm.h > > And you get [1] and [2]. > >>> Extend execbuf2 IOCTL to support submitting N BBs in a single IOCTL >>> --- >>> Contexts that have been configured with the 'set_parallel' extension can >>> only >> >> The warnings go away, thanks! > > What warnings go away? > Oops, I mean the patch author had silenced these warnings. -- An old man doll... just what I always wanted! - Clara
Re: [RFC PATCH v3 09/12] net: add support for skbs with unreadable frags
On Mon, Nov 6, 2023 at 3:55 PM Stanislav Fomichev wrote:
>
> On Mon, Nov 6, 2023 at 3:27 PM Mina Almasry wrote:
> >
> > On Mon, Nov 6, 2023 at 2:59 PM Stanislav Fomichev wrote:
> > >
> > > On 11/06, Mina Almasry wrote:
> > > > On Mon, Nov 6, 2023 at 1:59 PM Stanislav Fomichev
> > > > wrote:
> > > > >
> > > > > On 11/06, Mina Almasry wrote:
> > > > > > On Mon, Nov 6, 2023 at 11:34 AM David Ahern
> > > > > > wrote:
> > > > > > >
> > > > > > > On 11/6/23 11:47 AM, Stanislav Fomichev wrote:
> > > > > > > > On 11/05, Mina Almasry wrote:
> > > > > > > >> For device memory TCP, we expect the skb headers to be
> > > > > > > >> available in host
> > > > > > > >> memory for access, and we expect the skb frags to be in device
> > > > > > > >> memory
> > > > > > > >> and unaccessible to the host. We expect there to be no mixing
> > > > > > > >> and
> > > > > > > >> matching of device memory frags (unaccessible) with host
> > > > > > > >> memory frags
> > > > > > > >> (accessible) in the same skb.
> > > > > > > >>
> > > > > > > >> Add a skb->devmem flag which indicates whether the frags in
> > > > > > > >> this skb
> > > > > > > >> are device memory frags or not.
> > > > > > > >>
> > > > > > > >> __skb_fill_page_desc() now checks frags added to skbs for
> > > > > > > >> page_pool_iovs,
> > > > > > > >> and marks the skb as skb->devmem accordingly.
> > > > > > > >>
> > > > > > > >> Add checks through the network stack to avoid accessing the
> > > > > > > >> frags of
> > > > > > > >> devmem skbs and avoid coalescing devmem skbs with non devmem
> > > > > > > >> skbs.
> > > > > > > >>
> > > > > > > >> Signed-off-by: Willem de Bruijn
> > > > > > > >> Signed-off-by: Kaiyuan Zhang
> > > > > > > >> Signed-off-by: Mina Almasry
> > > > > > > >>
> > > > > > > >> ---
> > > > > > > >> include/linux/skbuff.h | 14 +++-
> > > > > > > >> include/net/tcp.h | 5 +--
> > > > > > > >> net/core/datagram.c| 6
> > > > > > > >> net/core/gro.c | 5 ++-
> > > > > > > >> net/core/skbuff.c | 77
> > > > > > > >> --
> > > > > > > >> net/ipv4/tcp.c | 6
> > > > > > > >> net/ipv4/tcp_input.c | 13 +--
> > > > > > > >> net/ipv4/tcp_output.c | 5 ++-
> > > > > > > >> net/packet/af_packet.c | 4 +--
> > > > > > > >> 9 files changed, 115 insertions(+), 20 deletions(-)
> > > > > > > >>
> > > > > > > >> diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
> > > > > > > >> index 1fae276c1353..8fb468ff8115 100644
> > > > > > > >> --- a/include/linux/skbuff.h
> > > > > > > >> +++ b/include/linux/skbuff.h
> > > > > > > >> @@ -805,6 +805,8 @@ typedef unsigned char *sk_buff_data_t;
> > > > > > > >> * @csum_level: indicates the number of consecutive
> > > > > > > >> checksums found in
> > > > > > > >> * the packet minus one that have been verified as
> > > > > > > >> * CHECKSUM_UNNECESSARY (max 3)
> > > > > > > >> + * @devmem: indicates that all the fragments in this skb are
> > > > > > > >> backed by
> > > > > > > >> + * device memory.
> > > > > > > >> * @dst_pending_confirm: need to confirm neighbour
> > > > > > > >> * @decrypted: Decrypted SKB
> > > > > > > >> * @slow_gro: state present at GRO time, slower prepare step
> > > > > > > >> required
> > > > > > > >> @@ -991,7 +993,7 @@ struct sk_buff {
> > > > > > > >> #if IS_ENABLED(CONFIG_IP_SCTP)
> > > > > > > >> __u8csum_not_inet:1;
> > > > > > > >> #endif
> > > > > > > >> -
> > > > > > > >> +__u8devmem:1;
> > > > > > > >> #if defined(CONFIG_NET_SCHED) || defined(CONFIG_NET_XGRESS)
> > > > > > > >> __u16 tc_index; /* traffic
> > > > > > > >> control index */
> > > > > > > >> #endif
> > > > > > > >> @@ -1766,6 +1768,12 @@ static inline void
> > > > > > > >> skb_zcopy_downgrade_managed(struct sk_buff *skb)
> > > > > > > >> __skb_zcopy_downgrade_managed(skb);
> > > > > > > >> }
> > > > > > > >>
> > > > > > > >> +/* Return true if frags in this skb are not readable by the
> > > > > > > >> host. */
> > > > > > > >> +static inline bool skb_frags_not_readable(const struct
> > > > > > > >> sk_buff *skb)
> > > > > > > >> +{
> > > > > > > >> +return skb->devmem;
> > > > > > > >
> > > > > > > > bikeshedding: should we also rename 'devmem' sk_buff flag to
> > > > > > > > 'not_readable'?
> > > > > > > > It better communicates the fact that the stack shouldn't
> > > > > > > > dereference the
> > > > > > > > frags (because it has 'devmem' fragments or for some other
> > > > > > > > potential
> > > > > > > > future reason).
> > > > > > >
> > > > > > > +1.
> > > > > > >
> > > > > > > Also, the flag on the skb is an optimization - a high level
> > > > > > > signal that
> > > > > > > one or more frags is in unreadable memory. There is no
> > > > > > > requirement that
> > > > > > > all of the frags are in the same memory type.
> > > > >
> > > > >
Re: [PATCH v5 1/4] drm/panel-edp: drm/panel-edp: Fix AUO B116XTN02, B116XAK01 name and timing
On Mon, Nov 6, 2023 at 4:00 PM Hsin-Yi Wang wrote:
>
> According to decoding edid and datahseet:
> - Rename AUO 0x235c B116XTN02 to B116XTN02.3
> - Rename AUO 0x405c B116XAK01 to B116XAK01.0 and adjust the timing of
> auo_b116xak01: T3=200, T12=500, T7_max = 50.
>
> Fixes: 3db2420422a5 ("drm/panel-edp: Add AUO B116XTN02, BOE
> NT116WHM-N21,836X2, NV116WHM-N49 V8.0")
> Fixes: da458286a5e2 ("drm/panel: Add support for AUO B116XAK01 panel")
> Signed-off-by: Hsin-Yi Wang
> Reviewed-by: Douglas Anderson
Cc: sta...@vger.kernel.org
> ---
> v4->v5: separate fixes patch.
> ---
> drivers/gpu/drm/panel/panel-edp.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/panel/panel-edp.c
> b/drivers/gpu/drm/panel/panel-edp.c
> index 9dce4c702414..d41d205f7f5b 100644
> --- a/drivers/gpu/drm/panel/panel-edp.c
> +++ b/drivers/gpu/drm/panel/panel-edp.c
> @@ -973,6 +973,8 @@ static const struct panel_desc auo_b116xak01 = {
> },
> .delay = {
> .hpd_absent = 200,
> + .unprepare = 500,
> + .enable = 50,
> },
> };
>
> @@ -1869,8 +1871,8 @@ static const struct edp_panel_entry edp_panels[] = {
> EDP_PANEL_ENTRY('A', 'U', 'O', 0x145c, _200_500_e50,
> "B116XAB01.4"),
> EDP_PANEL_ENTRY('A', 'U', 'O', 0x1e9b, _200_500_e50,
> "B133UAN02.1"),
> EDP_PANEL_ENTRY('A', 'U', 'O', 0x1ea5, _200_500_e50,
> "B116XAK01.6"),
> - EDP_PANEL_ENTRY('A', 'U', 'O', 0x235c, _200_500_e50,
> "B116XTN02"),
> - EDP_PANEL_ENTRY('A', 'U', 'O', 0x405c, _b116xak01.delay,
> "B116XAK01"),
> + EDP_PANEL_ENTRY('A', 'U', 'O', 0x235c, _200_500_e50,
> "B116XTN02.3"),
> + EDP_PANEL_ENTRY('A', 'U', 'O', 0x405c, _b116xak01.delay,
> "B116XAK01.0"),
> EDP_PANEL_ENTRY('A', 'U', 'O', 0x582d, _200_500_e50,
> "B133UAN01.0"),
> EDP_PANEL_ENTRY('A', 'U', 'O', 0x615c, _200_500_e50,
> "B116XAN06.1"),
> EDP_PANEL_ENTRY('A', 'U', 'O', 0x8594, _200_500_e50,
> "B133UAN01.0"),
> --
> 2.42.0.869.gea05f2083d-goog
>
Re: [RFC PATCH v3 09/12] net: add support for skbs with unreadable frags
On Mon, Nov 6, 2023 at 3:37 PM David Ahern wrote:
>
> On 11/6/23 3:18 PM, Mina Almasry wrote:
> >> @@ -991,7 +993,7 @@ struct sk_buff {
> >> #if IS_ENABLED(CONFIG_IP_SCTP)
> >> __u8csum_not_inet:1;
> >> #endif
> >> -
> >> +__u8devmem:1;
> >> #if defined(CONFIG_NET_SCHED) || defined(CONFIG_NET_XGRESS)
> >> __u16 tc_index; /* traffic control index
> >> */
> >> #endif
> >> @@ -1766,6 +1768,12 @@ static inline void
> >> skb_zcopy_downgrade_managed(struct sk_buff *skb)
> >> __skb_zcopy_downgrade_managed(skb);
> >> }
> >>
> >> +/* Return true if frags in this skb are not readable by the host. */
> >> +static inline bool skb_frags_not_readable(const struct sk_buff *skb)
> >> +{
> >> +return skb->devmem;
> >
> > bikeshedding: should we also rename 'devmem' sk_buff flag to
> > 'not_readable'?
> > It better communicates the fact that the stack shouldn't dereference the
> > frags (because it has 'devmem' fragments or for some other potential
> > future reason).
>
> +1.
>
> Also, the flag on the skb is an optimization - a high level signal that
> one or more frags is in unreadable memory. There is no requirement that
> all of the frags are in the same memory type.
> >>
> >> David: maybe there should be such a requirement (that they all are
> >> unreadable)? Might be easier to support initially; we can relax later
> >> on.
> >>
> >
> > Currently devmem == not_readable, and the restriction is that all the
> > frags in the same skb must be either all readable or all unreadable
> > (all devmem or all non-devmem).
>
> What requires that restriction? In all of the uses of skb->devmem and
> skb_frags_not_readable() what matters is if any frag is not readable,
> then frag list walk or collapse is avoided.
>
>
Currently only tcp_recvmsg_devmem(), I think. tcp_recvmsg_locked()
delegates to tcp_recvmsg_devmem() if skb->devmem, and
tcp_recvmsg_devmem() net_err's if it finds a non-iov frag in the skb.
This is done for some simplicity, because iov's are given to the user
via cmsg, but pages are copied into the linear buffer. I think it
would be confusing for the user if we simultaneously copied some data
to the linear buffer and gave them a devmem cmsgs in the same
recvmsg() call.
So, my simplicity is:
1. in a single skb, all frags must be devmem or non-devmem, no mixing.
2. In a single recvmsg() call, we only process devmem or non-devmem
skbs, no mixing.
--
Thanks,
Mina
Re: [RFC PATCH v3 10/12] tcp: RX path for devmem TCP
On Mon, Nov 6, 2023 at 3:55 PM David Ahern wrote: > > On 11/6/23 4:32 PM, Stanislav Fomichev wrote: > >> The concise notification API returns tokens as a range for > >> compression, encoding as two 32-bit unsigned integers start + length. > >> It allows for even further batching by returning multiple such ranges > >> in a single call. > > > > Tangential: should tokens be u64? Otherwise we can't have more than > > 4gb unacknowledged. Or that's a reasonable constraint? > > > > Was thinking the same and with bits reserved for a dmabuf id to allow > multiple dmabufs in a single rx queue (future extension, but build the > capability in now). e.g., something like a 37b offset (128GB dmabuf > size), 19b length (large GRO), 8b dmabuf id (lots of dmabufs to a queue). Agreed. Converting to 64b now sounds like a good forward looking revision.
[PATCH v5 4/4] drm/panel-edp: Avoid adding multiple preferred modes
If a non generic edp-panel is under aux-bus, the mode read from edid would
still be selected as preferred and results in multiple preferred modes,
which is ambiguous.
If both hard-coded mode and edid exists, only add mode from hard-coded.
Signed-off-by: Hsin-Yi Wang
---
v4->v5: remove inapplicable comments.
---
drivers/gpu/drm/panel/panel-edp.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-edp.c
b/drivers/gpu/drm/panel/panel-edp.c
index c0c24d94c3a0..006939cc3fee 100644
--- a/drivers/gpu/drm/panel/panel-edp.c
+++ b/drivers/gpu/drm/panel/panel-edp.c
@@ -589,6 +589,7 @@ static int panel_edp_get_modes(struct drm_panel *panel,
{
struct panel_edp *p = to_panel_edp(panel);
int num = 0;
+ bool has_hard_coded_modes = p->desc->num_timings || p->desc->num_modes;
bool has_override_edid_mode = p->detected_panel &&
p->detected_panel != ERR_PTR(-EINVAL) &&
p->detected_panel->override_edid_mode;
@@ -599,7 +600,11 @@ static int panel_edp_get_modes(struct drm_panel *panel,
if (!p->edid)
p->edid = drm_get_edid(connector, p->ddc);
- if (p->edid) {
+ /*
+* If both edid and hard-coded modes exists, skip edid modes to
+* avoid multiple preferred modes.
+*/
+ if (p->edid && !has_hard_coded_modes) {
if (has_override_edid_mode) {
/*
* override_edid_mode is specified. Use
@@ -616,12 +621,7 @@ static int panel_edp_get_modes(struct drm_panel *panel,
pm_runtime_put_autosuspend(panel->dev);
}
- /*
-* Add hard-coded panel modes. Don't call this if there are no timings
-* and no modes (the generic edp-panel case) because it will clobber
-* the display_info that was already set by drm_add_edid_modes().
-*/
- if (p->desc->num_timings || p->desc->num_modes)
+ if (has_hard_coded_modes)
num += panel_edp_get_non_edid_modes(p, connector);
else if (!num)
dev_warn(p->base.dev, "No display modes\n");
--
2.42.0.869.gea05f2083d-goog
[PATCH v5 1/4] drm/panel-edp: drm/panel-edp: Fix AUO B116XTN02, B116XAK01 name and timing
According to decoding edid and datahseet:
- Rename AUO 0x235c B116XTN02 to B116XTN02.3
- Rename AUO 0x405c B116XAK01 to B116XAK01.0 and adjust the timing of
auo_b116xak01: T3=200, T12=500, T7_max = 50.
Fixes: 3db2420422a5 ("drm/panel-edp: Add AUO B116XTN02, BOE NT116WHM-N21,836X2,
NV116WHM-N49 V8.0")
Fixes: da458286a5e2 ("drm/panel: Add support for AUO B116XAK01 panel")
Signed-off-by: Hsin-Yi Wang
Reviewed-by: Douglas Anderson
---
v4->v5: separate fixes patch.
---
drivers/gpu/drm/panel/panel-edp.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-edp.c
b/drivers/gpu/drm/panel/panel-edp.c
index 9dce4c702414..d41d205f7f5b 100644
--- a/drivers/gpu/drm/panel/panel-edp.c
+++ b/drivers/gpu/drm/panel/panel-edp.c
@@ -973,6 +973,8 @@ static const struct panel_desc auo_b116xak01 = {
},
.delay = {
.hpd_absent = 200,
+ .unprepare = 500,
+ .enable = 50,
},
};
@@ -1869,8 +1871,8 @@ static const struct edp_panel_entry edp_panels[] = {
EDP_PANEL_ENTRY('A', 'U', 'O', 0x145c, _200_500_e50,
"B116XAB01.4"),
EDP_PANEL_ENTRY('A', 'U', 'O', 0x1e9b, _200_500_e50,
"B133UAN02.1"),
EDP_PANEL_ENTRY('A', 'U', 'O', 0x1ea5, _200_500_e50,
"B116XAK01.6"),
- EDP_PANEL_ENTRY('A', 'U', 'O', 0x235c, _200_500_e50, "B116XTN02"),
- EDP_PANEL_ENTRY('A', 'U', 'O', 0x405c, _b116xak01.delay,
"B116XAK01"),
+ EDP_PANEL_ENTRY('A', 'U', 'O', 0x235c, _200_500_e50,
"B116XTN02.3"),
+ EDP_PANEL_ENTRY('A', 'U', 'O', 0x405c, _b116xak01.delay,
"B116XAK01.0"),
EDP_PANEL_ENTRY('A', 'U', 'O', 0x582d, _200_500_e50,
"B133UAN01.0"),
EDP_PANEL_ENTRY('A', 'U', 'O', 0x615c, _200_500_e50,
"B116XAN06.1"),
EDP_PANEL_ENTRY('A', 'U', 'O', 0x8594, _200_500_e50,
"B133UAN01.0"),
--
2.42.0.869.gea05f2083d-goog
[PATCH v5 3/4] drm/panel-edp: Add override_edid_mode quirk for generic edp
Generic edp gets mode from edid. However, some panels report incorrect
mode in this way, resulting in glitches on panel. Introduce a new quirk
additional_mode to the generic edid to pick a correct hardcoded mode.
Signed-off-by: Hsin-Yi Wang
Reviewed-by: Douglas Anderson
---
v4->v5: fix coding style comments from v4.
---
drivers/gpu/drm/panel/panel-edp.c | 67 ---
1 file changed, 62 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-edp.c
b/drivers/gpu/drm/panel/panel-edp.c
index 599a949d74d1..c0c24d94c3a0 100644
--- a/drivers/gpu/drm/panel/panel-edp.c
+++ b/drivers/gpu/drm/panel/panel-edp.c
@@ -203,6 +203,9 @@ struct edp_panel_entry {
/** @name: Name of this panel (for printing to logs). */
const char *name;
+
+ /** @override_edid_mode: Override the mode obtained by edid. */
+ const struct drm_display_mode *override_edid_mode;
};
struct panel_edp {
@@ -301,6 +304,24 @@ static unsigned int panel_edp_get_display_modes(struct
panel_edp *panel,
return num;
}
+static int panel_edp_override_edid_mode(struct panel_edp *panel,
+ struct drm_connector *connector,
+ const struct drm_display_mode
*override_mode)
+{
+ struct drm_display_mode *mode;
+
+ mode = drm_mode_duplicate(connector->dev, override_mode);
+ if (!mode) {
+ dev_err(panel->base.dev, "failed to add additional mode\n");
+ return 0;
+ }
+
+ mode->type |= DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED;
+ drm_mode_set_name(mode);
+ drm_mode_probed_add(connector, mode);
+ return 1;
+}
+
static int panel_edp_get_non_edid_modes(struct panel_edp *panel,
struct drm_connector *connector)
{
@@ -568,6 +589,9 @@ static int panel_edp_get_modes(struct drm_panel *panel,
{
struct panel_edp *p = to_panel_edp(panel);
int num = 0;
+ bool has_override_edid_mode = p->detected_panel &&
+ p->detected_panel != ERR_PTR(-EINVAL) &&
+ p->detected_panel->override_edid_mode;
/* probe EDID if a DDC bus is available */
if (p->ddc) {
@@ -575,9 +599,18 @@ static int panel_edp_get_modes(struct drm_panel *panel,
if (!p->edid)
p->edid = drm_get_edid(connector, p->ddc);
-
- if (p->edid)
- num += drm_add_edid_modes(connector, p->edid);
+ if (p->edid) {
+ if (has_override_edid_mode) {
+ /*
+* override_edid_mode is specified. Use
+* override_edid_mode instead of from edid.
+*/
+ num += panel_edp_override_edid_mode(p,
connector,
+
p->detected_panel->override_edid_mode);
+ } else {
+ num += drm_add_edid_modes(connector, p->edid);
+ }
+ }
pm_runtime_mark_last_busy(panel->dev);
pm_runtime_put_autosuspend(panel->dev);
@@ -950,6 +983,19 @@ static const struct panel_desc auo_b101ean01 = {
},
};
+static const struct drm_display_mode auo_b116xa3_mode = {
+ .clock = 70589,
+ .hdisplay = 1366,
+ .hsync_start = 1366 + 40,
+ .hsync_end = 1366 + 40 + 40,
+ .htotal = 1366 + 40 + 40 + 32,
+ .vdisplay = 768,
+ .vsync_start = 768 + 10,
+ .vsync_end = 768 + 10 + 12,
+ .vtotal = 768 + 10 + 12 + 6,
+ .flags = DRM_MODE_FLAG_NVSYNC | DRM_MODE_FLAG_NHSYNC,
+};
+
static const struct drm_display_mode auo_b116xak01_mode = {
.clock = 69300,
.hdisplay = 1366,
@@ -1878,6 +1924,15 @@ static const struct panel_delay delay_200_150_e200 = {
.delay = _delay \
}
+#define EDP_PANEL_ENTRY2(vend_chr_0, vend_chr_1, vend_chr_2, product_id,
_delay, _name, _mode) \
+{ \
+ .name = _name, \
+ .panel_id = drm_edid_encode_panel_id(vend_chr_0, vend_chr_1,
vend_chr_2, \
+product_id), \
+ .delay = _delay, \
+ .override_edid_mode = _mode \
+}
+
/*
* This table is used to figure out power sequencing delays for panels that
* are detected by EDID. Entries here may point to entries in the
@@ -1895,9 +1950,11 @@ static const struct edp_panel_entry edp_panels[] = {
EDP_PANEL_ENTRY('A', 'U', 'O', 0x239b, _200_500_e50,
"B116XAN06.1"),
EDP_PANEL_ENTRY('A', 'U', 'O', 0x255c, _200_500_e50,
"B116XTN02.5"),
EDP_PANEL_ENTRY('A', 'U', 'O', 0x403d, _200_500_e50,
"B140HAN04.0"),
- EDP_PANEL_ENTRY('A', 'U', 'O', 0x405c, _b116xak01.delay,
"B116XAK01.0"),
+ EDP_PANEL_ENTRY2('A', 'U', 'O', 0x405c, _b116xak01.delay,
[PATCH v5 2/4] drm/panel-edp: drm/panel-edp: Add several generic edp panels
Add a few generic edp panels used by mt8186 chromebooks.
Signed-off-by: Hsin-Yi Wang
Reviewed-by: Douglas Anderson
---
v4->v5: seperate fixes patch
---
drivers/gpu/drm/panel/panel-edp.c | 51 +++
1 file changed, 51 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-edp.c
b/drivers/gpu/drm/panel/panel-edp.c
index d41d205f7f5b..599a949d74d1 100644
--- a/drivers/gpu/drm/panel/panel-edp.c
+++ b/drivers/gpu/drm/panel/panel-edp.c
@@ -1832,6 +1832,12 @@ static const struct panel_delay delay_200_500_e50 = {
.enable = 50,
};
+static const struct panel_delay delay_200_500_e80 = {
+ .hpd_absent = 200,
+ .unprepare = 500,
+ .enable = 80,
+};
+
static const struct panel_delay delay_200_500_e80_d50 = {
.hpd_absent = 200,
.unprepare = 500,
@@ -1851,6 +1857,19 @@ static const struct panel_delay delay_200_500_e200 = {
.enable = 200,
};
+static const struct panel_delay delay_200_500_e200_d10 = {
+ .hpd_absent = 200,
+ .unprepare = 500,
+ .enable = 200,
+ .disable = 10,
+};
+
+static const struct panel_delay delay_200_150_e200 = {
+ .hpd_absent = 200,
+ .unprepare = 150,
+ .enable = 200,
+};
+
#define EDP_PANEL_ENTRY(vend_chr_0, vend_chr_1, vend_chr_2, product_id,
_delay, _name) \
{ \
.name = _name, \
@@ -1871,37 +1890,69 @@ static const struct edp_panel_entry edp_panels[] = {
EDP_PANEL_ENTRY('A', 'U', 'O', 0x145c, _200_500_e50,
"B116XAB01.4"),
EDP_PANEL_ENTRY('A', 'U', 'O', 0x1e9b, _200_500_e50,
"B133UAN02.1"),
EDP_PANEL_ENTRY('A', 'U', 'O', 0x1ea5, _200_500_e50,
"B116XAK01.6"),
+ EDP_PANEL_ENTRY('A', 'U', 'O', 0x208d, _200_500_e50,
"B140HTN02.1"),
EDP_PANEL_ENTRY('A', 'U', 'O', 0x235c, _200_500_e50,
"B116XTN02.3"),
+ EDP_PANEL_ENTRY('A', 'U', 'O', 0x239b, _200_500_e50,
"B116XAN06.1"),
+ EDP_PANEL_ENTRY('A', 'U', 'O', 0x255c, _200_500_e50,
"B116XTN02.5"),
+ EDP_PANEL_ENTRY('A', 'U', 'O', 0x403d, _200_500_e50,
"B140HAN04.0"),
EDP_PANEL_ENTRY('A', 'U', 'O', 0x405c, _b116xak01.delay,
"B116XAK01.0"),
EDP_PANEL_ENTRY('A', 'U', 'O', 0x582d, _200_500_e50,
"B133UAN01.0"),
EDP_PANEL_ENTRY('A', 'U', 'O', 0x615c, _200_500_e50,
"B116XAN06.1"),
+ EDP_PANEL_ENTRY('A', 'U', 'O', 0x635c, _200_500_e50,
"B116XAN06.3"),
+ EDP_PANEL_ENTRY('A', 'U', 'O', 0x639c, _200_500_e50,
"B140HAK02.7"),
EDP_PANEL_ENTRY('A', 'U', 'O', 0x8594, _200_500_e50,
"B133UAN01.0"),
+ EDP_PANEL_ENTRY('A', 'U', 'O', 0xf390, _200_500_e50,
"B140XTN07.7"),
+ EDP_PANEL_ENTRY('B', 'O', 'E', 0x0715, _200_150_e200,
"NT116WHM-N21"),
+ EDP_PANEL_ENTRY('B', 'O', 'E', 0x0731, _200_500_e80,
"NT116WHM-N42"),
+ EDP_PANEL_ENTRY('B', 'O', 'E', 0x0741, _200_500_e200,
"NT116WHM-N44"),
EDP_PANEL_ENTRY('B', 'O', 'E', 0x0786, _200_500_p2e80,
"NV116WHM-T01"),
EDP_PANEL_ENTRY('B', 'O', 'E', 0x07d1, _nv133fhm_n61.delay,
"NV133FHM-N61"),
+ EDP_PANEL_ENTRY('B', 'O', 'E', 0x07f6, _200_500_e200,
"NT140FHM-N44"),
EDP_PANEL_ENTRY('B', 'O', 'E', 0x082d, _nv133fhm_n61.delay,
"NV133FHM-N62"),
+ EDP_PANEL_ENTRY('B', 'O', 'E', 0x08b2, _200_500_e200,
"NT140WHM-N49"),
EDP_PANEL_ENTRY('B', 'O', 'E', 0x09c3, _200_500_e50,
"NT116WHM-N21,836X2"),
EDP_PANEL_ENTRY('B', 'O', 'E', 0x094b, _200_500_e50,
"NT116WHM-N21"),
+ EDP_PANEL_ENTRY('B', 'O', 'E', 0x0951, _200_500_e80,
"NV116WHM-N47"),
EDP_PANEL_ENTRY('B', 'O', 'E', 0x095f, _200_500_e50,
"NE135FBM-N41 v8.1"),
EDP_PANEL_ENTRY('B', 'O', 'E', 0x0979, _200_500_e50,
"NV116WHM-N49 V8.0"),
EDP_PANEL_ENTRY('B', 'O', 'E', 0x098d, _nv110wtm_n61.delay,
"NV110WTM-N61"),
+ EDP_PANEL_ENTRY('B', 'O', 'E', 0x09ae, _200_500_e200,
"NT140FHM-N45"),
EDP_PANEL_ENTRY('B', 'O', 'E', 0x09dd, _200_500_e50,
"NT116WHM-N21"),
EDP_PANEL_ENTRY('B', 'O', 'E', 0x0a5d, _200_500_e50,
"NV116WHM-N45"),
EDP_PANEL_ENTRY('B', 'O', 'E', 0x0ac5, _200_500_e50,
"NV116WHM-N4C"),
+ EDP_PANEL_ENTRY('B', 'O', 'E', 0x0b43, _200_500_e200,
"NV140FHM-T09"),
+ EDP_PANEL_ENTRY('B', 'O', 'E', 0x0b56, _200_500_e80,
"NT140FHM-N47"),
+ EDP_PANEL_ENTRY('B', 'O', 'E', 0x0c20, _200_500_e80,
"NT140FHM-N47"),
+ EDP_PANEL_ENTRY('C', 'M', 'N', 0x1132, _200_500_e80_d50,
"N116BGE-EA2"),
+ EDP_PANEL_ENTRY('C', 'M', 'N', 0x1138, _n116bca_ea1.delay,
"N116BCA-EA1-RC4"),
EDP_PANEL_ENTRY('C', 'M', 'N', 0x1139, _200_500_e80_d50,
"N116BGE-EA2"),
+ EDP_PANEL_ENTRY('C', 'M', 'N', 0x1145, _200_500_e80_d50,
"N116BCN-EB1"),
EDP_PANEL_ENTRY('C', 'M', 'N', 0x114c, _n116bca_ea1.delay,
"N116BCA-EA1"),
EDP_PANEL_ENTRY('C', 'M', 'N', 0x1152, _200_500_e80_d50,
"N116BCN-EA1"),
EDP_PANEL_ENTRY('C', 'M', 'N', 0x1153, _200_500_e80_d50,
"N116BGE-EA2"),
EDP_PANEL_ENTRY('C', 'M', 'N', 0x1154, _200_500_e80_d50,
"N116BCA-EA2"),
+
[PATCH v5 0/4] Add a few panels and use correct modes
This series contains 3 patches: 1. Add a few new generic edp panels. 2. Support a new quirk to override the mode read from edid 3. Only add hard-coded mode if both edid and hard-coded modes presents. v1: https://patchwork.kernel.org/project/dri-devel/cover/20231101212604.1636517-1-hsi...@chromium.org/ v2: https://patchwork.kernel.org/project/dri-devel/cover/20231102221309.1971910-1-hsi...@chromium.org/ v3: https://patchwork.kernel.org/project/dri-devel/cover/20231106202718.2770821-1-hsi...@chromium.org/ v4: https://patchwork.kernel.org/project/dri-devel/cover/20231106210337.2900034-1-hsi...@chromium.org/ Hsin-Yi Wang (4): drm/panel-edp: drm/panel-edp: Fix AUO B116XTN02, B116XAK01 name and timing drm/panel-edp: drm/panel-edp: Add several generic edp panels drm/panel-edp: Add override_edid_mode quirk for generic edp drm/panel-edp: Avoid adding multiple preferred modes drivers/gpu/drm/panel/panel-edp.c | 134 +++--- 1 file changed, 122 insertions(+), 12 deletions(-) -- 2.42.0.869.gea05f2083d-goog
[PATCH 1/2] drm/i915/guc: Fix for potential false positives in GuC hang selftest
From: John Harrison
Noticed that the hangcheck selftest is submitting a non-preemptoble
spinner. That means that even if the GuC does not die, the heartbeat
will still kick in and trigger a reset. Which is rather defeating the
purpose of the test - to verify that the heartbeat will kick in if the
GuC itself has died. The test is deliberately killing the GuC, so it
should never hit the case of a non-dead GuC. But it is not impossible
that the kill might fail at some future point due to other driver
re-work.
So, make the spinner pre-emptible. That way the heartbeat can get
through if the GuC is alive and context switching. Thus a reset only
happens if the GuC dies. Thus, if the kill should stop working the
test will now fail rather than claim to pass.
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/selftest_guc_hangcheck.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/selftest_guc_hangcheck.c
b/drivers/gpu/drm/i915/gt/uc/selftest_guc_hangcheck.c
index 34b5d952e2bcb..26fdc392fce6c 100644
--- a/drivers/gpu/drm/i915/gt/uc/selftest_guc_hangcheck.c
+++ b/drivers/gpu/drm/i915/gt/uc/selftest_guc_hangcheck.c
@@ -74,7 +74,7 @@ static int intel_hang_guc(void *arg)
goto err;
}
- rq = igt_spinner_create_request(, ce, MI_NOOP);
+ rq = igt_spinner_create_request(, ce, MI_ARB_CHECK);
intel_context_put(ce);
if (IS_ERR(rq)) {
ret = PTR_ERR(rq);
--
2.41.0
[PATCH 2/2] drm/i915/guc: Add a selftest for FAST_REQUEST errors
From: John Harrison
There is a mechanism for reporting errors from fire and forget H2G
messages. This is the only way to find out about almost any error in
the GuC backend submission path. So it would be useful to know that it
is working.
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_guc.h| 4 +
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 9 ++
drivers/gpu/drm/i915/gt/uc/selftest_guc.c | 122 ++
3 files changed, 135 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
index 2b6dfe62c8f2a..e22c12ce245ad 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
@@ -297,6 +297,10 @@ struct intel_guc {
* @number_guc_id_stolen: The number of guc_ids that have been stolen
*/
int number_guc_id_stolen;
+ /**
+* @fast_response_selftest: Backdoor to CT handler for fast response
selftest
+*/
+ u32 fast_response_selftest;
#endif
};
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
index 89e314b3756bb..9d958afb78b7f 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
@@ -1076,6 +1076,15 @@ static int ct_handle_response(struct intel_guc_ct *ct,
struct ct_incoming_msg *r
found = true;
break;
}
+
+#ifdef CONFIG_DRM_I915_SELFTEST
+ if (!found && ct_to_guc(ct)->fast_response_selftest) {
+ CT_DEBUG(ct, "Assuming unsolicited response due to FAST_REQUEST
selftest\n");
+ ct_to_guc(ct)->fast_response_selftest++;
+ found = 1;
+ }
+#endif
+
if (!found) {
CT_ERROR(ct, "Unsolicited response message: len %u, data %#x
(fence %u, last %u)\n",
len, hxg[0], fence, ct->requests.last_fence);
diff --git a/drivers/gpu/drm/i915/gt/uc/selftest_guc.c
b/drivers/gpu/drm/i915/gt/uc/selftest_guc.c
index bfb72143566f6..97fbbb396336c 100644
--- a/drivers/gpu/drm/i915/gt/uc/selftest_guc.c
+++ b/drivers/gpu/drm/i915/gt/uc/selftest_guc.c
@@ -286,11 +286,133 @@ static int intel_guc_steal_guc_ids(void *arg)
return ret;
}
+/*
+ * Send a context schedule H2G message with an invalid context id.
+ * This should generate a GUC_RESULT_INVALID_CONTEXT response.
+ */
+static int bad_h2g(struct intel_guc *guc)
+{
+ u32 action[3], len = 0;
+
+ action[len++] = INTEL_GUC_ACTION_SCHED_CONTEXT;
+ action[len++] = 0x12345678;
+
+ return intel_guc_send_nb(guc, action, len, 0);
+}
+
+/*
+ * Set a spinner running to make sure the system is alive and active,
+ * then send a bad but asynchronous H2G command and wait to see if an
+ * error response is returned. If no response is received or if the
+ * spinner dies then the test will fail.
+ */
+#define FAST_RESPONSE_TIMEOUT_MS 1000
+static int intel_guc_fast_request(void *arg)
+{
+ struct intel_gt *gt = arg;
+ struct intel_context *ce;
+ struct igt_spinner spin;
+ struct i915_request *rq;
+ intel_wakeref_t wakeref;
+ struct intel_engine_cs *engine = intel_selftest_find_any_engine(gt);
+ ktime_t before, now, delta;
+ bool spinning = false;
+ u64 delta_ms;
+ int ret = 0;
+
+ if (!engine)
+ return 0;
+
+ wakeref = intel_runtime_pm_get(gt->uncore->rpm);
+
+ ce = intel_context_create(engine);
+ if (IS_ERR(ce)) {
+ ret = PTR_ERR(ce);
+ gt_err(gt, "Failed to create spinner request: %pe\n", ce);
+ goto err_pm;
+ }
+
+ ret = igt_spinner_init(, engine->gt);
+ if (ret) {
+ gt_err(gt, "Failed to create spinner: %pe\n", ERR_PTR(ret));
+ goto err_pm;
+ }
+ spinning = true;
+
+ rq = igt_spinner_create_request(, ce, MI_ARB_CHECK);
+ intel_context_put(ce);
+ if (IS_ERR(rq)) {
+ ret = PTR_ERR(rq);
+ gt_err(gt, "Failed to create spinner request: %pe\n", rq);
+ goto err_spin;
+ }
+
+ ret = request_add_spin(rq, );
+ if (ret) {
+ gt_err(gt, "Failed to add Spinner request: %pe\n",
ERR_PTR(ret));
+ goto err_rq;
+ }
+
+ gt->uc.guc.fast_response_selftest = 1;
+
+ ret = bad_h2g(>uc.guc);
+ if (ret) {
+ gt_err(gt, "Failed to send H2G: %pe\n", ERR_PTR(ret));
+ goto err_rq;
+ }
+
+ before = ktime_get();
+ while (gt->uc.guc.fast_response_selftest == 1) {
+ ret = i915_request_wait(rq, 0, 1);
+ if (ret != -ETIME) {
+ gt_err(gt, "Request wait failed: %pe\n", ERR_PTR(ret));
+ goto err_rq;
+ }
+ now = ktime_get();
+ delta = ktime_sub(now, before);
+ delta_ms = ktime_to_ms(delta);
+
[PATCH 0/2] Selftest for FAST_REQUEST feature
From: John Harrison Add a selftest to verify that the FAST_REQUEST mechanism (getting errors back from fire-and-forget H2G commands) is functional. Also fix up a potential false positive in the GuC hang selftest. Signed-off-by: John Harrison John Harrison (2): drm/i915/guc: Fix for potential false positives in GuC hang selftest drm/i915/guc: Add a selftest for FAST_REQUEST errors drivers/gpu/drm/i915/gt/uc/intel_guc.h| 4 + drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 9 ++ drivers/gpu/drm/i915/gt/uc/selftest_guc.c | 122 ++ .../drm/i915/gt/uc/selftest_guc_hangcheck.c | 2 +- 4 files changed, 136 insertions(+), 1 deletion(-) -- 2.41.0
Re: [RFC PATCH v3 09/12] net: add support for skbs with unreadable frags
On Mon, Nov 6, 2023 at 3:27 PM Mina Almasry wrote:
>
> On Mon, Nov 6, 2023 at 2:59 PM Stanislav Fomichev wrote:
> >
> > On 11/06, Mina Almasry wrote:
> > > On Mon, Nov 6, 2023 at 1:59 PM Stanislav Fomichev wrote:
> > > >
> > > > On 11/06, Mina Almasry wrote:
> > > > > On Mon, Nov 6, 2023 at 11:34 AM David Ahern
> > > > > wrote:
> > > > > >
> > > > > > On 11/6/23 11:47 AM, Stanislav Fomichev wrote:
> > > > > > > On 11/05, Mina Almasry wrote:
> > > > > > >> For device memory TCP, we expect the skb headers to be available
> > > > > > >> in host
> > > > > > >> memory for access, and we expect the skb frags to be in device
> > > > > > >> memory
> > > > > > >> and unaccessible to the host. We expect there to be no mixing and
> > > > > > >> matching of device memory frags (unaccessible) with host memory
> > > > > > >> frags
> > > > > > >> (accessible) in the same skb.
> > > > > > >>
> > > > > > >> Add a skb->devmem flag which indicates whether the frags in this
> > > > > > >> skb
> > > > > > >> are device memory frags or not.
> > > > > > >>
> > > > > > >> __skb_fill_page_desc() now checks frags added to skbs for
> > > > > > >> page_pool_iovs,
> > > > > > >> and marks the skb as skb->devmem accordingly.
> > > > > > >>
> > > > > > >> Add checks through the network stack to avoid accessing the
> > > > > > >> frags of
> > > > > > >> devmem skbs and avoid coalescing devmem skbs with non devmem
> > > > > > >> skbs.
> > > > > > >>
> > > > > > >> Signed-off-by: Willem de Bruijn
> > > > > > >> Signed-off-by: Kaiyuan Zhang
> > > > > > >> Signed-off-by: Mina Almasry
> > > > > > >>
> > > > > > >> ---
> > > > > > >> include/linux/skbuff.h | 14 +++-
> > > > > > >> include/net/tcp.h | 5 +--
> > > > > > >> net/core/datagram.c| 6
> > > > > > >> net/core/gro.c | 5 ++-
> > > > > > >> net/core/skbuff.c | 77
> > > > > > >> --
> > > > > > >> net/ipv4/tcp.c | 6
> > > > > > >> net/ipv4/tcp_input.c | 13 +--
> > > > > > >> net/ipv4/tcp_output.c | 5 ++-
> > > > > > >> net/packet/af_packet.c | 4 +--
> > > > > > >> 9 files changed, 115 insertions(+), 20 deletions(-)
> > > > > > >>
> > > > > > >> diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
> > > > > > >> index 1fae276c1353..8fb468ff8115 100644
> > > > > > >> --- a/include/linux/skbuff.h
> > > > > > >> +++ b/include/linux/skbuff.h
> > > > > > >> @@ -805,6 +805,8 @@ typedef unsigned char *sk_buff_data_t;
> > > > > > >> * @csum_level: indicates the number of consecutive checksums
> > > > > > >> found in
> > > > > > >> * the packet minus one that have been verified as
> > > > > > >> * CHECKSUM_UNNECESSARY (max 3)
> > > > > > >> + * @devmem: indicates that all the fragments in this skb are
> > > > > > >> backed by
> > > > > > >> + * device memory.
> > > > > > >> * @dst_pending_confirm: need to confirm neighbour
> > > > > > >> * @decrypted: Decrypted SKB
> > > > > > >> * @slow_gro: state present at GRO time, slower prepare step
> > > > > > >> required
> > > > > > >> @@ -991,7 +993,7 @@ struct sk_buff {
> > > > > > >> #if IS_ENABLED(CONFIG_IP_SCTP)
> > > > > > >> __u8csum_not_inet:1;
> > > > > > >> #endif
> > > > > > >> -
> > > > > > >> +__u8devmem:1;
> > > > > > >> #if defined(CONFIG_NET_SCHED) || defined(CONFIG_NET_XGRESS)
> > > > > > >> __u16 tc_index; /* traffic control
> > > > > > >> index */
> > > > > > >> #endif
> > > > > > >> @@ -1766,6 +1768,12 @@ static inline void
> > > > > > >> skb_zcopy_downgrade_managed(struct sk_buff *skb)
> > > > > > >> __skb_zcopy_downgrade_managed(skb);
> > > > > > >> }
> > > > > > >>
> > > > > > >> +/* Return true if frags in this skb are not readable by the
> > > > > > >> host. */
> > > > > > >> +static inline bool skb_frags_not_readable(const struct sk_buff
> > > > > > >> *skb)
> > > > > > >> +{
> > > > > > >> +return skb->devmem;
> > > > > > >
> > > > > > > bikeshedding: should we also rename 'devmem' sk_buff flag to
> > > > > > > 'not_readable'?
> > > > > > > It better communicates the fact that the stack shouldn't
> > > > > > > dereference the
> > > > > > > frags (because it has 'devmem' fragments or for some other
> > > > > > > potential
> > > > > > > future reason).
> > > > > >
> > > > > > +1.
> > > > > >
> > > > > > Also, the flag on the skb is an optimization - a high level signal
> > > > > > that
> > > > > > one or more frags is in unreadable memory. There is no requirement
> > > > > > that
> > > > > > all of the frags are in the same memory type.
> > > >
> > > > David: maybe there should be such a requirement (that they all are
> > > > unreadable)? Might be easier to support initially; we can relax later
> > > > on.
> > > >
> > >
> > > Currently devmem == not_readable, and the restriction is that all the
> > > frags in the same skb must be either all readable or
Re: [RFC PATCH v3 10/12] tcp: RX path for devmem TCP
On 11/6/23 4:32 PM, Stanislav Fomichev wrote: >> The concise notification API returns tokens as a range for >> compression, encoding as two 32-bit unsigned integers start + length. >> It allows for even further batching by returning multiple such ranges >> in a single call. > > Tangential: should tokens be u64? Otherwise we can't have more than > 4gb unacknowledged. Or that's a reasonable constraint? > Was thinking the same and with bits reserved for a dmabuf id to allow multiple dmabufs in a single rx queue (future extension, but build the capability in now). e.g., something like a 37b offset (128GB dmabuf size), 19b length (large GRO), 8b dmabuf id (lots of dmabufs to a queue).
Re: linux-next: manual merge of the amdgpu tree with Linus' tree
Hi all,
On Mon, 6 Nov 2023 09:48:55 +1100 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the amdgpu tree got a conflict in:
>
> drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c
>
> between commit:
>
> 18bf400530ca ("drm/amdgpu: Use pci_get_base_class() to reduce duplicated
> code")
>
> from Linus' tree and commit:
>
> 432e664e7c98 ("drm/amdgpu: don't use ATRM for external devices")
>
> from the amdgpu tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c
> index 5bbb23e102ba,f3a09ecb7699..
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c
> @@@ -286,12 -287,12 +287,16 @@@ static bool amdgpu_atrm_get_bios(struc
> /* ATRM is for the discrete card only */
> if (adev->flags & AMD_IS_APU)
> return false;
> +
> + /* ATRM is for on-platform devices only */
> + if (dev_is_removable(>pdev->dev))
> + return false;
>
> -while ((pdev = pci_get_class(PCI_CLASS_DISPLAY_VGA << 8, pdev)) !=
> NULL) {
> +while ((pdev = pci_get_base_class(PCI_BASE_CLASS_DISPLAY, pdev))) {
> +if ((pdev->class != PCI_CLASS_DISPLAY_VGA << 8) &&
> +(pdev->class != PCI_CLASS_DISPLAY_OTHER << 8))
> +continue;
> +
> dhandle = ACPI_HANDLE(>dev);
> if (!dhandle)
> continue;
This is now a conflict between the drm tree and Linus' tree.
--
Cheers,
Stephen Rothwell
pgpfND900uZJK.pgp
Description: OpenPGP digital signature
Re: [RFC PATCH v3 06/12] memory-provider: dmabuf devmem memory provider
On 11/5/23 7:44 PM, Mina Almasry wrote:
> diff --git a/include/net/page_pool/helpers.h b/include/net/page_pool/helpers.h
> index 78cbb040af94..b93243c2a640 100644
> --- a/include/net/page_pool/helpers.h
> +++ b/include/net/page_pool/helpers.h
> @@ -111,6 +112,45 @@ page_pool_iov_binding(const struct page_pool_iov *ppiov)
> return page_pool_iov_owner(ppiov)->binding;
> }
>
> +static inline int page_pool_iov_refcount(const struct page_pool_iov *ppiov)
> +{
> + return refcount_read(>refcount);
> +}
> +
> +static inline void page_pool_iov_get_many(struct page_pool_iov *ppiov,
> + unsigned int count)
> +{
> + refcount_add(count, >refcount);
> +}
> +
> +void __page_pool_iov_free(struct page_pool_iov *ppiov);
> +
> +static inline void page_pool_iov_put_many(struct page_pool_iov *ppiov,
> + unsigned int count)
> +{
> + if (!refcount_sub_and_test(count, >refcount))
> + return;
> +
> + __page_pool_iov_free(ppiov);
> +}
> +
> +/* page pool mm helpers */
> +
> +static inline bool page_is_page_pool_iov(const struct page *page)
> +{
> + return (unsigned long)page & PP_DEVMEM;
This is another one where the code can be more generic to not force a
lot changes later. e.g., PP_CUSTOM or PP_NO_PAGE. Then io_uring use
case with host memory can leverage the iov pool in a similar manner.
That does mean skb->devmem needs to be a flag on the page pool and not
just assume iov == device memory.
Re: [PATCH] drm/msm/dpu: correct clk bit for WB2 block
On Tue, 7 Nov 2023 at 01:30, Abhinav Kumar wrote:
>
>
>
> On 11/6/2023 2:11 PM, Dmitry Baryshkov wrote:
> > On Mon, 6 Nov 2023 at 20:39, Abhinav Kumar
> > wrote:
> >>
> >> Sorry for the delay in getting back on this. There was quite a bit of
> >> history digging I had to do myself to give a certain response.
> >>
> >>
> >> On 10/9/2023 10:11 AM, Dmitry Baryshkov wrote:
> >>> On sc7280 there are two clk bits for WB2: control and status. While
> >>> programming the VBIF params of WB, the driver should be toggling the
> >>> former bit, while the sc7280_mdp struct lists the latter one.
> >>>
> >>
> >> No, this is not correct. Both are control bits. But for the context of
> >> where this is being used today, that is setting the VBIF OT limit, we
> >> should be using the VBIF_CLI one. So the below change itself is correct
> >> but not the commit text.
> >
> > Maybe you can update dt bindings for the SDE driver? Because they
> > clearly speak about the control and status bits.
> >
>
> There is nothing to update here if we both are referring to the same
> entries in the dt bindings.
>
> qcom,sde-wb-clk-status = <0x3bc 20>;
>
> the clk status is indeed bit 20 of 0x3bc.
>
> What we have before your patch was bit 24 of 0x3b8 which was indeed
> clk_ctl bit for wb2. But the only issue was it was not the vbif_cli one.
>
> So we are talking about two different registers?
Ah, excuse me then, I didn't notice 24 vs 20.
>
> >>
> >> We need to make the same change on sm8250 WB2 as well as this register
> >> is present there too. In fact, anything >=msm8994 for setting VBIF OT
> >> for WB2 we should be using VBIF_CLI bits of register MDP_CLK_CTRL2
> >> (offset 0x2bc).
> >>
> >> For anything >=sm8550, we need to use WB_2_CLK_CTRL present within the
> >> WB block and not the one in the top.
> >>
> >> Hence for this change, we can do below:
> >>
> >> -> update the commit text to indicate both are control bits but for the
> >> vbif ot context we should using the corrected one
> >> -> if you can also add sm8250 in the same change i can ack it and pick it
> >> up
> >>
> >> Have you re-validated WB with this change? If not, let me know I shall
> >> while picking this up for -fixes.
> >
> > No, I haven't validated this on sc7280. I'll try this on sm8250 and
> > then I'll send v2.
> >
> >>
> >>> Correct that to ensure proper programming sequence for WB2 on sc7280.
> >>>
> >>> Fixes: 3ce166380567 ("drm/msm/dpu: add writeback support for sc7280")
> >>> Signed-off-by: Dmitry Baryshkov
> >>> ---
> >>>drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h | 2 +-
> >>>1 file changed, 1 insertion(+), 1 deletion(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h
> >>> b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h
> >>> index 3b5061c4402a..9195cb996f44 100644
> >>> --- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h
> >>> +++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h
> >>> @@ -25,7 +25,7 @@ static const struct dpu_mdp_cfg sc7280_mdp = {
> >>>[DPU_CLK_CTRL_DMA0] = { .reg_off = 0x2ac, .bit_off = 8 },
> >>>[DPU_CLK_CTRL_DMA1] = { .reg_off = 0x2b4, .bit_off = 8 },
> >>>[DPU_CLK_CTRL_DMA2] = { .reg_off = 0x2c4, .bit_off = 8 },
> >>> - [DPU_CLK_CTRL_WB2] = { .reg_off = 0x3b8, .bit_off = 24 },
> >>> + [DPU_CLK_CTRL_WB2] = { .reg_off = 0x2bc, .bit_off = 16 },
> >>>},
> >>>};
> >>>
> >
> >
> >
--
With best wishes
Dmitry
Re: [RFC PATCH v3 05/12] netdev: netdevice devmem allocator
On 11/5/23 7:44 PM, Mina Almasry wrote:
> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
> index eeeda849115c..1c351c138a5b 100644
> --- a/include/linux/netdevice.h
> +++ b/include/linux/netdevice.h
> @@ -843,6 +843,9 @@ struct netdev_dmabuf_binding {
> };
>
> #ifdef CONFIG_DMA_SHARED_BUFFER
> +struct page_pool_iov *
> +netdev_alloc_devmem(struct netdev_dmabuf_binding *binding);
> +void netdev_free_devmem(struct page_pool_iov *ppiov);
netdev_{alloc,free}_dmabuf?
I say that because a dmabuf can be host memory, at least I am not aware
of a restriction that a dmabuf is device memory.
Re: [RFC PATCH v3 09/12] net: add support for skbs with unreadable frags
On 11/6/23 3:18 PM, Mina Almasry wrote:
>> @@ -991,7 +993,7 @@ struct sk_buff {
>> #if IS_ENABLED(CONFIG_IP_SCTP)
>> __u8csum_not_inet:1;
>> #endif
>> -
>> +__u8devmem:1;
>> #if defined(CONFIG_NET_SCHED) || defined(CONFIG_NET_XGRESS)
>> __u16 tc_index; /* traffic control index */
>> #endif
>> @@ -1766,6 +1768,12 @@ static inline void
>> skb_zcopy_downgrade_managed(struct sk_buff *skb)
>> __skb_zcopy_downgrade_managed(skb);
>> }
>>
>> +/* Return true if frags in this skb are not readable by the host. */
>> +static inline bool skb_frags_not_readable(const struct sk_buff *skb)
>> +{
>> +return skb->devmem;
>
> bikeshedding: should we also rename 'devmem' sk_buff flag to
> 'not_readable'?
> It better communicates the fact that the stack shouldn't dereference the
> frags (because it has 'devmem' fragments or for some other potential
> future reason).
+1.
Also, the flag on the skb is an optimization - a high level signal that
one or more frags is in unreadable memory. There is no requirement that
all of the frags are in the same memory type.
>>
>> David: maybe there should be such a requirement (that they all are
>> unreadable)? Might be easier to support initially; we can relax later
>> on.
>>
>
> Currently devmem == not_readable, and the restriction is that all the
> frags in the same skb must be either all readable or all unreadable
> (all devmem or all non-devmem).
What requires that restriction? In all of the uses of skb->devmem and
skb_frags_not_readable() what matters is if any frag is not readable,
then frag list walk or collapse is avoided.
Re: [RFC PATCH v3 10/12] tcp: RX path for devmem TCP
On Mon, Nov 6, 2023 at 2:56 PM Willem de Bruijn wrote: > > On Mon, Nov 6, 2023 at 2:34 PM Stanislav Fomichev wrote: > > > > On 11/06, Willem de Bruijn wrote: > > > > > IMHO, we need a better UAPI to receive the tokens and give them back > > > > > to > > > > > the kernel. CMSG + setsockopt(SO_DEVMEM_DONTNEED) get the job done, > > > > > but look dated and hacky :-( > > > > > > > > > > We should either do some kind of user/kernel shared memory queue to > > > > > receive/return the tokens (similar to what Jonathan was doing in his > > > > > proposal?) > > > > > > > > I'll take a look at Jonathan's proposal, sorry, I'm not immediately > > > > familiar but I wanted to respond :-) But is the suggestion here to > > > > build a new kernel-user communication channel primitive for the > > > > purpose of passing the information in the devmem cmsg? IMHO that seems > > > > like an overkill. Why add 100-200 lines of code to the kernel to add > > > > something that can already be done with existing primitives? I don't > > > > see anything concretely wrong with cmsg & setsockopt approach, and if > > > > we switch to something I'd prefer to switch to an existing primitive > > > > for simplicity? > > > > > > > > The only other existing primitive to pass data outside of the linear > > > > buffer is the MSG_ERRQUEUE that is used for zerocopy. Is that > > > > preferred? Any other suggestions or existing primitives I'm not aware > > > > of? > > > > > > > > > or bite the bullet and switch to io_uring. > > > > > > > > > > > > > IMO io_uring & socket support are orthogonal, and one doesn't preclude > > > > the other. As you know we like to use sockets and I believe there are > > > > issues with io_uring adoption at Google that I'm not familiar with > > > > (and could be wrong). I'm interested in exploring io_uring support as > > > > a follow up but I think David Wei will be interested in io_uring > > > > support as well anyway. > > > > > > I also disagree that we need to replace a standard socket interface > > > with something "faster", in quotes. > > > > > > This interface is not the bottleneck to the target workload. > > > > > > Replacing the synchronous sockets interface with something more > > > performant for workloads where it is, is an orthogonal challenge. > > > However we do that, I think that traditional sockets should continue > > > to be supported. > > > > > > The feature may already even work with io_uring, as both recvmsg with > > > cmsg and setsockopt have io_uring support now. > > > > I'm not really concerned with faster. I would prefer something cleaner :-) > > > > Or maybe we should just have it documented. With some kind of path > > towards beautiful world where we can create dynamic queues.. > > I suppose we just disagree on the elegance of the API. Yeah, I might be overly sensitive to the apis that use get/setsockopt for something more involved than setting a flag. Probably because I know that bpf will (unnecessarily) trigger on these :-D I had to implement that bpf "bypass" (or fastpath) for TCP_ZEROCOPY_RECEIVE and it looks like this token recycle might also benefit from something similar. > The concise notification API returns tokens as a range for > compression, encoding as two 32-bit unsigned integers start + length. > It allows for even further batching by returning multiple such ranges > in a single call. Tangential: should tokens be u64? Otherwise we can't have more than 4gb unacknowledged. Or that's a reasonable constraint? > This is analogous to the MSG_ZEROCOPY notification mechanism from > kernel to user. > > The synchronous socket syscall interface can be replaced by something > asynchronous like io_uring. This already works today? Whatever > asynchronous ring-based API would be selected, io_uring or otherwise, > I think the concise notification encoding would remain as is. > > Since this is an operation on a socket, I find a setsockopt the > fitting interface.
Re: [PATCH] drm/msm/dpu: correct clk bit for WB2 block
On 11/6/2023 2:11 PM, Dmitry Baryshkov wrote:
On Mon, 6 Nov 2023 at 20:39, Abhinav Kumar wrote:
Sorry for the delay in getting back on this. There was quite a bit of
history digging I had to do myself to give a certain response.
On 10/9/2023 10:11 AM, Dmitry Baryshkov wrote:
On sc7280 there are two clk bits for WB2: control and status. While
programming the VBIF params of WB, the driver should be toggling the
former bit, while the sc7280_mdp struct lists the latter one.
No, this is not correct. Both are control bits. But for the context of
where this is being used today, that is setting the VBIF OT limit, we
should be using the VBIF_CLI one. So the below change itself is correct
but not the commit text.
Maybe you can update dt bindings for the SDE driver? Because they
clearly speak about the control and status bits.
There is nothing to update here if we both are referring to the same
entries in the dt bindings.
qcom,sde-wb-clk-status = <0x3bc 20>;
the clk status is indeed bit 20 of 0x3bc.
What we have before your patch was bit 24 of 0x3b8 which was indeed
clk_ctl bit for wb2. But the only issue was it was not the vbif_cli one.
So we are talking about two different registers?
We need to make the same change on sm8250 WB2 as well as this register
is present there too. In fact, anything >=msm8994 for setting VBIF OT
for WB2 we should be using VBIF_CLI bits of register MDP_CLK_CTRL2
(offset 0x2bc).
For anything >=sm8550, we need to use WB_2_CLK_CTRL present within the
WB block and not the one in the top.
Hence for this change, we can do below:
-> update the commit text to indicate both are control bits but for the
vbif ot context we should using the corrected one
-> if you can also add sm8250 in the same change i can ack it and pick it up
Have you re-validated WB with this change? If not, let me know I shall
while picking this up for -fixes.
No, I haven't validated this on sc7280. I'll try this on sm8250 and
then I'll send v2.
Correct that to ensure proper programming sequence for WB2 on sc7280.
Fixes: 3ce166380567 ("drm/msm/dpu: add writeback support for sc7280")
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h
index 3b5061c4402a..9195cb996f44 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h
@@ -25,7 +25,7 @@ static const struct dpu_mdp_cfg sc7280_mdp = {
[DPU_CLK_CTRL_DMA0] = { .reg_off = 0x2ac, .bit_off = 8 },
[DPU_CLK_CTRL_DMA1] = { .reg_off = 0x2b4, .bit_off = 8 },
[DPU_CLK_CTRL_DMA2] = { .reg_off = 0x2c4, .bit_off = 8 },
- [DPU_CLK_CTRL_WB2] = { .reg_off = 0x3b8, .bit_off = 24 },
+ [DPU_CLK_CTRL_WB2] = { .reg_off = 0x2bc, .bit_off = 16 },
},
};
Re: [RFC PATCH v3 09/12] net: add support for skbs with unreadable frags
On Mon, Nov 6, 2023 at 2:59 PM Stanislav Fomichev wrote:
>
> On 11/06, Mina Almasry wrote:
> > On Mon, Nov 6, 2023 at 1:59 PM Stanislav Fomichev wrote:
> > >
> > > On 11/06, Mina Almasry wrote:
> > > > On Mon, Nov 6, 2023 at 11:34 AM David Ahern wrote:
> > > > >
> > > > > On 11/6/23 11:47 AM, Stanislav Fomichev wrote:
> > > > > > On 11/05, Mina Almasry wrote:
> > > > > >> For device memory TCP, we expect the skb headers to be available
> > > > > >> in host
> > > > > >> memory for access, and we expect the skb frags to be in device
> > > > > >> memory
> > > > > >> and unaccessible to the host. We expect there to be no mixing and
> > > > > >> matching of device memory frags (unaccessible) with host memory
> > > > > >> frags
> > > > > >> (accessible) in the same skb.
> > > > > >>
> > > > > >> Add a skb->devmem flag which indicates whether the frags in this
> > > > > >> skb
> > > > > >> are device memory frags or not.
> > > > > >>
> > > > > >> __skb_fill_page_desc() now checks frags added to skbs for
> > > > > >> page_pool_iovs,
> > > > > >> and marks the skb as skb->devmem accordingly.
> > > > > >>
> > > > > >> Add checks through the network stack to avoid accessing the frags
> > > > > >> of
> > > > > >> devmem skbs and avoid coalescing devmem skbs with non devmem skbs.
> > > > > >>
> > > > > >> Signed-off-by: Willem de Bruijn
> > > > > >> Signed-off-by: Kaiyuan Zhang
> > > > > >> Signed-off-by: Mina Almasry
> > > > > >>
> > > > > >> ---
> > > > > >> include/linux/skbuff.h | 14 +++-
> > > > > >> include/net/tcp.h | 5 +--
> > > > > >> net/core/datagram.c| 6
> > > > > >> net/core/gro.c | 5 ++-
> > > > > >> net/core/skbuff.c | 77
> > > > > >> --
> > > > > >> net/ipv4/tcp.c | 6
> > > > > >> net/ipv4/tcp_input.c | 13 +--
> > > > > >> net/ipv4/tcp_output.c | 5 ++-
> > > > > >> net/packet/af_packet.c | 4 +--
> > > > > >> 9 files changed, 115 insertions(+), 20 deletions(-)
> > > > > >>
> > > > > >> diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
> > > > > >> index 1fae276c1353..8fb468ff8115 100644
> > > > > >> --- a/include/linux/skbuff.h
> > > > > >> +++ b/include/linux/skbuff.h
> > > > > >> @@ -805,6 +805,8 @@ typedef unsigned char *sk_buff_data_t;
> > > > > >> * @csum_level: indicates the number of consecutive checksums
> > > > > >> found in
> > > > > >> * the packet minus one that have been verified as
> > > > > >> * CHECKSUM_UNNECESSARY (max 3)
> > > > > >> + * @devmem: indicates that all the fragments in this skb are
> > > > > >> backed by
> > > > > >> + * device memory.
> > > > > >> * @dst_pending_confirm: need to confirm neighbour
> > > > > >> * @decrypted: Decrypted SKB
> > > > > >> * @slow_gro: state present at GRO time, slower prepare step
> > > > > >> required
> > > > > >> @@ -991,7 +993,7 @@ struct sk_buff {
> > > > > >> #if IS_ENABLED(CONFIG_IP_SCTP)
> > > > > >> __u8csum_not_inet:1;
> > > > > >> #endif
> > > > > >> -
> > > > > >> +__u8devmem:1;
> > > > > >> #if defined(CONFIG_NET_SCHED) || defined(CONFIG_NET_XGRESS)
> > > > > >> __u16 tc_index; /* traffic control
> > > > > >> index */
> > > > > >> #endif
> > > > > >> @@ -1766,6 +1768,12 @@ static inline void
> > > > > >> skb_zcopy_downgrade_managed(struct sk_buff *skb)
> > > > > >> __skb_zcopy_downgrade_managed(skb);
> > > > > >> }
> > > > > >>
> > > > > >> +/* Return true if frags in this skb are not readable by the host.
> > > > > >> */
> > > > > >> +static inline bool skb_frags_not_readable(const struct sk_buff
> > > > > >> *skb)
> > > > > >> +{
> > > > > >> +return skb->devmem;
> > > > > >
> > > > > > bikeshedding: should we also rename 'devmem' sk_buff flag to
> > > > > > 'not_readable'?
> > > > > > It better communicates the fact that the stack shouldn't
> > > > > > dereference the
> > > > > > frags (because it has 'devmem' fragments or for some other potential
> > > > > > future reason).
> > > > >
> > > > > +1.
> > > > >
> > > > > Also, the flag on the skb is an optimization - a high level signal
> > > > > that
> > > > > one or more frags is in unreadable memory. There is no requirement
> > > > > that
> > > > > all of the frags are in the same memory type.
> > >
> > > David: maybe there should be such a requirement (that they all are
> > > unreadable)? Might be easier to support initially; we can relax later
> > > on.
> > >
> >
> > Currently devmem == not_readable, and the restriction is that all the
> > frags in the same skb must be either all readable or all unreadable
> > (all devmem or all non-devmem).
> >
> > > > The flag indicates that the skb contains all devmem dma-buf memory
> > > > specifically, not generic 'not_readable' frags as the comment says:
> > > >
> > > > + * @devmem: indicates that all the fragments in this skb are
> > > > backed by
> >
Re: [syzbot] [dri?] kernel BUG in vmf_insert_pfn_prot (2)
syzbot has found a reproducer for the following issue on: HEAD commit:d2f51b3516da Merge tag 'rtc-6.7' of git://git.kernel.org/p.. git tree: upstream console+strace: https://syzkaller.appspot.com/x/log.txt?x=1422ebef68 kernel config: https://syzkaller.appspot.com/x/.config?x=1ffa1cec3b40f3ce dashboard link: https://syzkaller.appspot.com/bug?extid=398e17b61dab22cc56bc compiler: gcc (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40 syz repro: https://syzkaller.appspot.com/x/repro.syz?x=16344918e8 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=156bb2c0e8 Downloadable assets: disk image: https://storage.googleapis.com/syzbot-assets/01a7f380fc8d/disk-d2f51b35.raw.xz vmlinux: https://storage.googleapis.com/syzbot-assets/c2fe46c74542/vmlinux-d2f51b35.xz kernel image: https://storage.googleapis.com/syzbot-assets/247d6a0567c5/bzImage-d2f51b35.xz IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+398e17b61dab22cc5...@syzkaller.appspotmail.com [ cut here ] kernel BUG at mm/memory.c:2216! invalid opcode: [#1] PREEMPT SMP KASAN CPU: 1 PID: 5067 Comm: syz-executor340 Not tainted 6.6.0-syzkaller-14651-gd2f51b3516da #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/09/2023 RIP: 0010:vmf_insert_pfn_prot+0x247/0x430 mm/memory.c:2216 Code: 0f 0b e8 7c e6 bd ff 49 89 ef bf 20 00 00 00 41 83 e7 28 4c 89 fe e8 f8 e1 bd ff 49 83 ff 20 0f 85 aa fe ff ff e8 59 e6 bd ff <0f> 0b 48 bd ff ff ff ff ff ff 0f 00 e8 48 e6 bd ff 4c 89 f6 48 89 RSP: 0018:c90003bbf758 EFLAGS: 00010293 RAX: RBX: 88802847ec00 RCX: 81cab618 RDX: 888015bd1dc0 RSI: 81cab627 RDI: 0007 RBP: 0c040474 R08: 0007 R09: 0020 R10: 0020 R11: 0009 R12: 20ffd000 R13: 192000777eec R14: 0001e529 R15: 0020 FS: 55e2a480() GS:8880b990() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 20ffd000 CR3: 2aae7000 CR4: 003506f0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: drm_gem_shmem_fault+0x207/0x400 drivers/gpu/drm/drm_gem_shmem_helper.c:531 __do_fault+0x107/0x5f0 mm/memory.c:4265 do_read_fault mm/memory.c:4628 [inline] do_fault mm/memory.c:4762 [inline] do_pte_missing mm/memory.c:3730 [inline] handle_pte_fault mm/memory.c:5038 [inline] __handle_mm_fault+0x2682/0x3d60 mm/memory.c:5179 handle_mm_fault+0x478/0xa00 mm/memory.c:5344 do_user_addr_fault+0x3d1/0x1000 arch/x86/mm/fault.c:1413 handle_page_fault arch/x86/mm/fault.c:1505 [inline] exc_page_fault+0x5c/0xd0 arch/x86/mm/fault.c:1561 asm_exc_page_fault+0x26/0x30 arch/x86/include/asm/idtentry.h:570 RIP: 0010:rep_movs_alternative+0x4a/0x70 arch/x86/lib/copy_user_64.S:71 Code: 75 f1 c3 66 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 8b 06 48 89 07 48 83 c6 08 48 83 c7 08 83 e9 08 74 df 83 f9 08 73 e8 eb c9 a4 c3 48 89 c8 48 c1 e9 03 83 e0 07 f3 48 a5 89 c1 85 c9 75 b3 RSP: 0018:c90003bbfb50 EFLAGS: 00050206 RAX: 0001 RBX: 20ffd000 RCX: 1000 RDX: RSI: 20ffd000 RDI: 888018796000 RBP: 1000 R08: 0001 R09: ed10030f2dff R10: 888018796fff R11: R12: 20ffe000 R13: 888018796000 R14: R15: 20ffd000 copy_user_generic arch/x86/include/asm/uaccess_64.h:112 [inline] raw_copy_from_user arch/x86/include/asm/uaccess_64.h:127 [inline] _copy_from_user+0xc2/0xf0 lib/usercopy.c:23 copy_from_user include/linux/uaccess.h:183 [inline] snd_rawmidi_kernel_write1+0x360/0x860 sound/core/rawmidi.c:1618 snd_rawmidi_write+0x26e/0xc00 sound/core/rawmidi.c:1687 vfs_write+0x2a4/0xdf0 fs/read_write.c:582 ksys_write+0x1f0/0x250 fs/read_write.c:637 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x3f/0x110 arch/x86/entry/common.c:82 entry_SYSCALL_64_after_hwframe+0x63/0x6b RIP: 0033:0x7f31add88d69 Code: 48 83 c4 28 c3 e8 37 17 00 00 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:7ffdd9a49ee8 EFLAGS: 0246 ORIG_RAX: 0001 RAX: ffda RBX: 7ffdd9a49f00 RCX: 7f31add88d69 RDX: fd2c RSI: 2000 RDI: 0004 RBP: 7ffdd9a49f08 R08: R09: R10: 7ffdd9a49f08 R11: 0246 R12: R13: 7ffdd9a4a168 R14: 0001 R15: 0001 Modules linked in: ---[ end trace ]--- RIP: 0010:vmf_insert_pfn_prot+0x247/0x430 mm/memory.c:2216 Code: 0f 0b e8 7c e6 bd ff 49 89 ef bf 20 00 00 00 41 83 e7 28 4c 89 fe e8 f8 e1 bd ff
Re: [RFC PATCH v3 09/12] net: add support for skbs with unreadable frags
>
> But there is still always 1 dmabuf to 1 socket association (on rx), right?
>
In practice yes, but my understanding is that such association is only
enforced by NIC features such as flow steering.
So why not have a separate control channel action to say: this socket fd
> is supposed to receive into this dmabuf fd?
>
Are you proposing also adding the installation of corresponding flow
steering into this action? Or just add checks to make sure the flow
steering won't be removed?
On Mon, Nov 6, 2023 at 2:59 PM Stanislav Fomichev wrote:
> On 11/06, Mina Almasry wrote:
> > On Mon, Nov 6, 2023 at 1:59 PM Stanislav Fomichev
> wrote:
> > >
> > > On 11/06, Mina Almasry wrote:
> > > > On Mon, Nov 6, 2023 at 11:34 AM David Ahern
> wrote:
> > > > >
> > > > > On 11/6/23 11:47 AM, Stanislav Fomichev wrote:
> > > > > > On 11/05, Mina Almasry wrote:
> > > > > >> For device memory TCP, we expect the skb headers to be
> available in host
> > > > > >> memory for access, and we expect the skb frags to be in device
> memory
> > > > > >> and unaccessible to the host. We expect there to be no mixing
> and
> > > > > >> matching of device memory frags (unaccessible) with host memory
> frags
> > > > > >> (accessible) in the same skb.
> > > > > >>
> > > > > >> Add a skb->devmem flag which indicates whether the frags in
> this skb
> > > > > >> are device memory frags or not.
> > > > > >>
> > > > > >> __skb_fill_page_desc() now checks frags added to skbs for
> page_pool_iovs,
> > > > > >> and marks the skb as skb->devmem accordingly.
> > > > > >>
> > > > > >> Add checks through the network stack to avoid accessing the
> frags of
> > > > > >> devmem skbs and avoid coalescing devmem skbs with non devmem
> skbs.
> > > > > >>
> > > > > >> Signed-off-by: Willem de Bruijn
> > > > > >> Signed-off-by: Kaiyuan Zhang
> > > > > >> Signed-off-by: Mina Almasry
> > > > > >>
> > > > > >> ---
> > > > > >> include/linux/skbuff.h | 14 +++-
> > > > > >> include/net/tcp.h | 5 +--
> > > > > >> net/core/datagram.c| 6
> > > > > >> net/core/gro.c | 5 ++-
> > > > > >> net/core/skbuff.c | 77
> --
> > > > > >> net/ipv4/tcp.c | 6
> > > > > >> net/ipv4/tcp_input.c | 13 +--
> > > > > >> net/ipv4/tcp_output.c | 5 ++-
> > > > > >> net/packet/af_packet.c | 4 +--
> > > > > >> 9 files changed, 115 insertions(+), 20 deletions(-)
> > > > > >>
> > > > > >> diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
> > > > > >> index 1fae276c1353..8fb468ff8115 100644
> > > > > >> --- a/include/linux/skbuff.h
> > > > > >> +++ b/include/linux/skbuff.h
> > > > > >> @@ -805,6 +805,8 @@ typedef unsigned char *sk_buff_data_t;
> > > > > >> * @csum_level: indicates the number of consecutive checksums
> found in
> > > > > >> * the packet minus one that have been verified as
> > > > > >> * CHECKSUM_UNNECESSARY (max 3)
> > > > > >> + * @devmem: indicates that all the fragments in this skb are
> backed by
> > > > > >> + * device memory.
> > > > > >> * @dst_pending_confirm: need to confirm neighbour
> > > > > >> * @decrypted: Decrypted SKB
> > > > > >> * @slow_gro: state present at GRO time, slower prepare step
> required
> > > > > >> @@ -991,7 +993,7 @@ struct sk_buff {
> > > > > >> #if IS_ENABLED(CONFIG_IP_SCTP)
> > > > > >> __u8csum_not_inet:1;
> > > > > >> #endif
> > > > > >> -
> > > > > >> +__u8devmem:1;
> > > > > >> #if defined(CONFIG_NET_SCHED) || defined(CONFIG_NET_XGRESS)
> > > > > >> __u16 tc_index; /* traffic control
> index */
> > > > > >> #endif
> > > > > >> @@ -1766,6 +1768,12 @@ static inline void
> skb_zcopy_downgrade_managed(struct sk_buff *skb)
> > > > > >> __skb_zcopy_downgrade_managed(skb);
> > > > > >> }
> > > > > >>
> > > > > >> +/* Return true if frags in this skb are not readable by the
> host. */
> > > > > >> +static inline bool skb_frags_not_readable(const struct sk_buff
> *skb)
> > > > > >> +{
> > > > > >> +return skb->devmem;
> > > > > >
> > > > > > bikeshedding: should we also rename 'devmem' sk_buff flag to
> 'not_readable'?
> > > > > > It better communicates the fact that the stack shouldn't
> dereference the
> > > > > > frags (because it has 'devmem' fragments or for some other
> potential
> > > > > > future reason).
> > > > >
> > > > > +1.
> > > > >
> > > > > Also, the flag on the skb is an optimization - a high level signal
> that
> > > > > one or more frags is in unreadable memory. There is no requirement
> that
> > > > > all of the frags are in the same memory type.
> > >
> > > David: maybe there should be such a requirement (that they all are
> > > unreadable)? Might be easier to support initially; we can relax later
> > > on.
> > >
> >
> > Currently devmem == not_readable, and the restriction is that all the
> > frags in the same skb must be either all readable or all unreadable
> >
Re: [RFC PATCH v3 09/12] net: add support for skbs with unreadable frags
On 11/06, Mina Almasry wrote:
> On Mon, Nov 6, 2023 at 1:59 PM Stanislav Fomichev wrote:
> >
> > On 11/06, Mina Almasry wrote:
> > > On Mon, Nov 6, 2023 at 11:34 AM David Ahern wrote:
> > > >
> > > > On 11/6/23 11:47 AM, Stanislav Fomichev wrote:
> > > > > On 11/05, Mina Almasry wrote:
> > > > >> For device memory TCP, we expect the skb headers to be available in
> > > > >> host
> > > > >> memory for access, and we expect the skb frags to be in device memory
> > > > >> and unaccessible to the host. We expect there to be no mixing and
> > > > >> matching of device memory frags (unaccessible) with host memory frags
> > > > >> (accessible) in the same skb.
> > > > >>
> > > > >> Add a skb->devmem flag which indicates whether the frags in this skb
> > > > >> are device memory frags or not.
> > > > >>
> > > > >> __skb_fill_page_desc() now checks frags added to skbs for
> > > > >> page_pool_iovs,
> > > > >> and marks the skb as skb->devmem accordingly.
> > > > >>
> > > > >> Add checks through the network stack to avoid accessing the frags of
> > > > >> devmem skbs and avoid coalescing devmem skbs with non devmem skbs.
> > > > >>
> > > > >> Signed-off-by: Willem de Bruijn
> > > > >> Signed-off-by: Kaiyuan Zhang
> > > > >> Signed-off-by: Mina Almasry
> > > > >>
> > > > >> ---
> > > > >> include/linux/skbuff.h | 14 +++-
> > > > >> include/net/tcp.h | 5 +--
> > > > >> net/core/datagram.c| 6
> > > > >> net/core/gro.c | 5 ++-
> > > > >> net/core/skbuff.c | 77
> > > > >> --
> > > > >> net/ipv4/tcp.c | 6
> > > > >> net/ipv4/tcp_input.c | 13 +--
> > > > >> net/ipv4/tcp_output.c | 5 ++-
> > > > >> net/packet/af_packet.c | 4 +--
> > > > >> 9 files changed, 115 insertions(+), 20 deletions(-)
> > > > >>
> > > > >> diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
> > > > >> index 1fae276c1353..8fb468ff8115 100644
> > > > >> --- a/include/linux/skbuff.h
> > > > >> +++ b/include/linux/skbuff.h
> > > > >> @@ -805,6 +805,8 @@ typedef unsigned char *sk_buff_data_t;
> > > > >> * @csum_level: indicates the number of consecutive checksums
> > > > >> found in
> > > > >> * the packet minus one that have been verified as
> > > > >> * CHECKSUM_UNNECESSARY (max 3)
> > > > >> + * @devmem: indicates that all the fragments in this skb are
> > > > >> backed by
> > > > >> + * device memory.
> > > > >> * @dst_pending_confirm: need to confirm neighbour
> > > > >> * @decrypted: Decrypted SKB
> > > > >> * @slow_gro: state present at GRO time, slower prepare step
> > > > >> required
> > > > >> @@ -991,7 +993,7 @@ struct sk_buff {
> > > > >> #if IS_ENABLED(CONFIG_IP_SCTP)
> > > > >> __u8csum_not_inet:1;
> > > > >> #endif
> > > > >> -
> > > > >> +__u8devmem:1;
> > > > >> #if defined(CONFIG_NET_SCHED) || defined(CONFIG_NET_XGRESS)
> > > > >> __u16 tc_index; /* traffic control
> > > > >> index */
> > > > >> #endif
> > > > >> @@ -1766,6 +1768,12 @@ static inline void
> > > > >> skb_zcopy_downgrade_managed(struct sk_buff *skb)
> > > > >> __skb_zcopy_downgrade_managed(skb);
> > > > >> }
> > > > >>
> > > > >> +/* Return true if frags in this skb are not readable by the host. */
> > > > >> +static inline bool skb_frags_not_readable(const struct sk_buff *skb)
> > > > >> +{
> > > > >> +return skb->devmem;
> > > > >
> > > > > bikeshedding: should we also rename 'devmem' sk_buff flag to
> > > > > 'not_readable'?
> > > > > It better communicates the fact that the stack shouldn't dereference
> > > > > the
> > > > > frags (because it has 'devmem' fragments or for some other potential
> > > > > future reason).
> > > >
> > > > +1.
> > > >
> > > > Also, the flag on the skb is an optimization - a high level signal that
> > > > one or more frags is in unreadable memory. There is no requirement that
> > > > all of the frags are in the same memory type.
> >
> > David: maybe there should be such a requirement (that they all are
> > unreadable)? Might be easier to support initially; we can relax later
> > on.
> >
>
> Currently devmem == not_readable, and the restriction is that all the
> frags in the same skb must be either all readable or all unreadable
> (all devmem or all non-devmem).
>
> > > The flag indicates that the skb contains all devmem dma-buf memory
> > > specifically, not generic 'not_readable' frags as the comment says:
> > >
> > > + * @devmem: indicates that all the fragments in this skb are backed
> > > by
> > > + * device memory.
> > >
> > > The reason it's not a generic 'not_readable' flag is because handing
> > > off a generic not_readable skb to the userspace is semantically not
> > > what we're doing. recvmsg() is augmented in this patch series to
> > > return a devmem skb to the user via a cmsg_devmem struct which refers
> > > specifically to the memory in the
Re: [RFC PATCH v3 10/12] tcp: RX path for devmem TCP
On Mon, Nov 6, 2023 at 2:34 PM Stanislav Fomichev wrote: > > On 11/06, Willem de Bruijn wrote: > > > > IMHO, we need a better UAPI to receive the tokens and give them back to > > > > the kernel. CMSG + setsockopt(SO_DEVMEM_DONTNEED) get the job done, > > > > but look dated and hacky :-( > > > > > > > > We should either do some kind of user/kernel shared memory queue to > > > > receive/return the tokens (similar to what Jonathan was doing in his > > > > proposal?) > > > > > > I'll take a look at Jonathan's proposal, sorry, I'm not immediately > > > familiar but I wanted to respond :-) But is the suggestion here to > > > build a new kernel-user communication channel primitive for the > > > purpose of passing the information in the devmem cmsg? IMHO that seems > > > like an overkill. Why add 100-200 lines of code to the kernel to add > > > something that can already be done with existing primitives? I don't > > > see anything concretely wrong with cmsg & setsockopt approach, and if > > > we switch to something I'd prefer to switch to an existing primitive > > > for simplicity? > > > > > > The only other existing primitive to pass data outside of the linear > > > buffer is the MSG_ERRQUEUE that is used for zerocopy. Is that > > > preferred? Any other suggestions or existing primitives I'm not aware > > > of? > > > > > > > or bite the bullet and switch to io_uring. > > > > > > > > > > IMO io_uring & socket support are orthogonal, and one doesn't preclude > > > the other. As you know we like to use sockets and I believe there are > > > issues with io_uring adoption at Google that I'm not familiar with > > > (and could be wrong). I'm interested in exploring io_uring support as > > > a follow up but I think David Wei will be interested in io_uring > > > support as well anyway. > > > > I also disagree that we need to replace a standard socket interface > > with something "faster", in quotes. > > > > This interface is not the bottleneck to the target workload. > > > > Replacing the synchronous sockets interface with something more > > performant for workloads where it is, is an orthogonal challenge. > > However we do that, I think that traditional sockets should continue > > to be supported. > > > > The feature may already even work with io_uring, as both recvmsg with > > cmsg and setsockopt have io_uring support now. > > I'm not really concerned with faster. I would prefer something cleaner :-) > > Or maybe we should just have it documented. With some kind of path > towards beautiful world where we can create dynamic queues.. I suppose we just disagree on the elegance of the API. The concise notification API returns tokens as a range for compression, encoding as two 32-bit unsigned integers start + length. It allows for even further batching by returning multiple such ranges in a single call. This is analogous to the MSG_ZEROCOPY notification mechanism from kernel to user. The synchronous socket syscall interface can be replaced by something asynchronous like io_uring. This already works today? Whatever asynchronous ring-based API would be selected, io_uring or otherwise, I think the concise notification encoding would remain as is. Since this is an operation on a socket, I find a setsockopt the fitting interface.
Re: [RFC PATCH v3 10/12] tcp: RX path for devmem TCP
On 11/06, Willem de Bruijn wrote: > > > IMHO, we need a better UAPI to receive the tokens and give them back to > > > the kernel. CMSG + setsockopt(SO_DEVMEM_DONTNEED) get the job done, > > > but look dated and hacky :-( > > > > > > We should either do some kind of user/kernel shared memory queue to > > > receive/return the tokens (similar to what Jonathan was doing in his > > > proposal?) > > > > I'll take a look at Jonathan's proposal, sorry, I'm not immediately > > familiar but I wanted to respond :-) But is the suggestion here to > > build a new kernel-user communication channel primitive for the > > purpose of passing the information in the devmem cmsg? IMHO that seems > > like an overkill. Why add 100-200 lines of code to the kernel to add > > something that can already be done with existing primitives? I don't > > see anything concretely wrong with cmsg & setsockopt approach, and if > > we switch to something I'd prefer to switch to an existing primitive > > for simplicity? > > > > The only other existing primitive to pass data outside of the linear > > buffer is the MSG_ERRQUEUE that is used for zerocopy. Is that > > preferred? Any other suggestions or existing primitives I'm not aware > > of? > > > > > or bite the bullet and switch to io_uring. > > > > > > > IMO io_uring & socket support are orthogonal, and one doesn't preclude > > the other. As you know we like to use sockets and I believe there are > > issues with io_uring adoption at Google that I'm not familiar with > > (and could be wrong). I'm interested in exploring io_uring support as > > a follow up but I think David Wei will be interested in io_uring > > support as well anyway. > > I also disagree that we need to replace a standard socket interface > with something "faster", in quotes. > > This interface is not the bottleneck to the target workload. > > Replacing the synchronous sockets interface with something more > performant for workloads where it is, is an orthogonal challenge. > However we do that, I think that traditional sockets should continue > to be supported. > > The feature may already even work with io_uring, as both recvmsg with > cmsg and setsockopt have io_uring support now. I'm not really concerned with faster. I would prefer something cleaner :-) Or maybe we should just have it documented. With some kind of path towards beautiful world where we can create dynamic queues..
Re: [PATCH v4 09/30] drm/dp: Add helpers to calculate the link BW overhead
On Mon, Nov 06, 2023 at 11:31:51PM +0200, Ville Syrjälä wrote:
> On Mon, Oct 30, 2023 at 05:58:22PM +0200, Imre Deak wrote:
> > Add helpers drivers can use to calculate the BW allocation overhead -
> > due to SSC, FEC, DSC and data alignment on symbol cycles - and the
> > channel coding efficiency - due to the 8b/10b, 128b/132b encoding. On
> > 128b/132b links the FEC overhead is part of the coding efficiency, so
> > not accounted for in the BW allocation overhead.
> >
> > The drivers can use these functions to calculate a ratio, controlling
> > the stream symbol insertion rate of the source device in each SST TU
> > or MST MTP frame. Drivers can calculate this
> >
> > m/n = (pixel_data_rate * drm_dp_bw_overhead()) /
> > (link_data_rate * drm_dp_bw_channel_coding_efficiency())
> >
> > ratio for a given link and pixel stream and with that the
> >
> > mtp_count = CEIL(64 * m / n)
> >
> > allocated MTPs for the stream in a link frame and
> >
> > pbn = CEIL(64 * dm_mst_get_pbn_divider() * m / n)
> >
> > allocated PBNs for the stream on the MST link path.
> >
> > Take drm_dp_bw_overhead() into use in drm_dp_calc_pbn_mode(), for
> > drivers calculating the PBN value directly.
> >
> > v2:
> > - Add dockbook description to drm_dp_bw_channel_coding_efficiency().
> > (LKP).
> > - Clarify the way m/n ratio is calculated in the commit log.
> > v3:
> > - Fix compile breakage for !CONFIG_BACKLIGHT_CLASS_DEVICE. (LKP)
> > - Account for FEC_PM overhead (+ 0.0015625 %), add comment
> > with the formula to calculate the total FEC overhead. (Ville)
> > v4:
> > - Rename DRM_DP_OVERHEAD_SSC to DRM_DP_OVERHEAD_SSC_REF_CLK. (Ville)
> >
> > Cc: Lyude Paul
> > Cc: Ville Syrjälä
> > Cc: kernel test robot
> > Cc: dri-devel@lists.freedesktop.org
> > Reviewed-by: Stanislav Lisovskiy (v2)
> > Signed-off-by: Imre Deak
> > ---
> > drivers/gpu/drm/display/drm_dp_helper.c | 132 ++
> > drivers/gpu/drm/display/drm_dp_mst_topology.c | 23 ++-
> > include/drm/display/drm_dp_helper.h | 11 ++
> > 3 files changed, 160 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/display/drm_dp_helper.c
> > b/drivers/gpu/drm/display/drm_dp_helper.c
> > index e5d7970a9ddd0..72ba9ae89f862 100644
> > --- a/drivers/gpu/drm/display/drm_dp_helper.c
> > +++ b/drivers/gpu/drm/display/drm_dp_helper.c
> > @@ -3900,3 +3900,135 @@ int drm_panel_dp_aux_backlight(struct drm_panel
> > *panel, struct drm_dp_aux *aux)
> > EXPORT_SYMBOL(drm_panel_dp_aux_backlight);
> >
> > #endif
> > +
> > +/* See DP Standard v2.1 2.6.4.4.1.1, 2.8.4.4, 2.8.7 */
> > +static int drm_dp_link_symbol_cycles(int lane_count, int pixels, int
> > bpp_x16,
> > +int symbol_size, bool is_mst)
> > +{
> > + int cycles = DIV_ROUND_UP(pixels * bpp_x16, 16 * symbol_size *
> > lane_count);
> > + int align = is_mst ? 4 / lane_count : 1;
> > +
> > + return ALIGN(cycles, align);
> > +}
> > +
> > +static int drm_dp_link_dsc_symbol_cycles(int lane_count, int pixels, int
> > slice_count,
> > +int bpp_x16, int symbol_size, bool
> > is_mst)
> > +{
> > + int slice_pixels = DIV_ROUND_UP(pixels, slice_count);
> > + int slice_data_cycles = drm_dp_link_symbol_cycles(lane_count,
> > slice_pixels,
> > + bpp_x16, symbol_size,
> > is_mst);
> > + int slice_eoc_cycles = is_mst ? 4 / lane_count : 1;
> > +
> > + return slice_count * (slice_data_cycles + slice_eoc_cycles);
> > +}
> > +
> > +/**
> > + * drm_dp_bw_overhead - Calculate the BW overhead of a DP link stream
> > + * @lane_count: DP link lane count
> > + * @hactive: pixel count of the active period in one scanline of the stream
> > + * @dsc_slice_count: DSC slice count if @flags/DRM_DP_LINK_BW_OVERHEAD_DSC
> > is set
> > + * @bpp_x16: bits per pixel in .4 binary fixed point
> > + * @flags: DRM_DP_OVERHEAD_x flags
> > + *
> > + * Calculate the BW allocation overhead of a DP link stream, depending
> > + * on the link's
> > + * - @lane_count
> > + * - SST/MST mode (@flags / %DRM_DP_OVERHEAD_MST)
> > + * - symbol size (@flags / %DRM_DP_OVERHEAD_UHBR)
> > + * - FEC mode (@flags / %DRM_DP_OVERHEAD_FEC)
> > + * - SSC/REF_CLK mode (@flags / %DRM_DP_OVERHEAD_SSC_REF_CLK)
> > + * as well as the stream's
> > + * - @hactive timing
> > + * - @bpp_x16 color depth
> > + * - compression mode (@flags / %DRM_DP_OVERHEAD_DSC).
> > + * Note that this overhead doesn't account for the 8b/10b, 128b/132b
> > + * channel coding efficiency, for that see
> > + * @drm_dp_link_bw_channel_coding_efficiency().
> > + *
> > + * Returns the overhead as 100% + overhead% in 1ppm units.
> > + */
> > +int drm_dp_bw_overhead(int lane_count, int hactive,
> > + int dsc_slice_count,
> > + int bpp_x16, unsigned long flags)
> > +{
> > + int symbol_size = flags & DRM_DP_BW_OVERHEAD_UHBR ? 32 : 8;
> > + bool is_mst = flags & DRM_DP_BW_OVERHEAD_MST;
> > +
Re: [RFC PATCH v3 09/12] net: add support for skbs with unreadable frags
On Mon, Nov 6, 2023 at 1:59 PM Stanislav Fomichev wrote:
>
> On 11/06, Mina Almasry wrote:
> > On Mon, Nov 6, 2023 at 11:34 AM David Ahern wrote:
> > >
> > > On 11/6/23 11:47 AM, Stanislav Fomichev wrote:
> > > > On 11/05, Mina Almasry wrote:
> > > >> For device memory TCP, we expect the skb headers to be available in
> > > >> host
> > > >> memory for access, and we expect the skb frags to be in device memory
> > > >> and unaccessible to the host. We expect there to be no mixing and
> > > >> matching of device memory frags (unaccessible) with host memory frags
> > > >> (accessible) in the same skb.
> > > >>
> > > >> Add a skb->devmem flag which indicates whether the frags in this skb
> > > >> are device memory frags or not.
> > > >>
> > > >> __skb_fill_page_desc() now checks frags added to skbs for
> > > >> page_pool_iovs,
> > > >> and marks the skb as skb->devmem accordingly.
> > > >>
> > > >> Add checks through the network stack to avoid accessing the frags of
> > > >> devmem skbs and avoid coalescing devmem skbs with non devmem skbs.
> > > >>
> > > >> Signed-off-by: Willem de Bruijn
> > > >> Signed-off-by: Kaiyuan Zhang
> > > >> Signed-off-by: Mina Almasry
> > > >>
> > > >> ---
> > > >> include/linux/skbuff.h | 14 +++-
> > > >> include/net/tcp.h | 5 +--
> > > >> net/core/datagram.c| 6
> > > >> net/core/gro.c | 5 ++-
> > > >> net/core/skbuff.c | 77 --
> > > >> net/ipv4/tcp.c | 6
> > > >> net/ipv4/tcp_input.c | 13 +--
> > > >> net/ipv4/tcp_output.c | 5 ++-
> > > >> net/packet/af_packet.c | 4 +--
> > > >> 9 files changed, 115 insertions(+), 20 deletions(-)
> > > >>
> > > >> diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
> > > >> index 1fae276c1353..8fb468ff8115 100644
> > > >> --- a/include/linux/skbuff.h
> > > >> +++ b/include/linux/skbuff.h
> > > >> @@ -805,6 +805,8 @@ typedef unsigned char *sk_buff_data_t;
> > > >> * @csum_level: indicates the number of consecutive checksums found
> > > >> in
> > > >> * the packet minus one that have been verified as
> > > >> * CHECKSUM_UNNECESSARY (max 3)
> > > >> + * @devmem: indicates that all the fragments in this skb are backed
> > > >> by
> > > >> + * device memory.
> > > >> * @dst_pending_confirm: need to confirm neighbour
> > > >> * @decrypted: Decrypted SKB
> > > >> * @slow_gro: state present at GRO time, slower prepare step required
> > > >> @@ -991,7 +993,7 @@ struct sk_buff {
> > > >> #if IS_ENABLED(CONFIG_IP_SCTP)
> > > >> __u8csum_not_inet:1;
> > > >> #endif
> > > >> -
> > > >> +__u8devmem:1;
> > > >> #if defined(CONFIG_NET_SCHED) || defined(CONFIG_NET_XGRESS)
> > > >> __u16 tc_index; /* traffic control index
> > > >> */
> > > >> #endif
> > > >> @@ -1766,6 +1768,12 @@ static inline void
> > > >> skb_zcopy_downgrade_managed(struct sk_buff *skb)
> > > >> __skb_zcopy_downgrade_managed(skb);
> > > >> }
> > > >>
> > > >> +/* Return true if frags in this skb are not readable by the host. */
> > > >> +static inline bool skb_frags_not_readable(const struct sk_buff *skb)
> > > >> +{
> > > >> +return skb->devmem;
> > > >
> > > > bikeshedding: should we also rename 'devmem' sk_buff flag to
> > > > 'not_readable'?
> > > > It better communicates the fact that the stack shouldn't dereference the
> > > > frags (because it has 'devmem' fragments or for some other potential
> > > > future reason).
> > >
> > > +1.
> > >
> > > Also, the flag on the skb is an optimization - a high level signal that
> > > one or more frags is in unreadable memory. There is no requirement that
> > > all of the frags are in the same memory type.
>
> David: maybe there should be such a requirement (that they all are
> unreadable)? Might be easier to support initially; we can relax later
> on.
>
Currently devmem == not_readable, and the restriction is that all the
frags in the same skb must be either all readable or all unreadable
(all devmem or all non-devmem).
> > The flag indicates that the skb contains all devmem dma-buf memory
> > specifically, not generic 'not_readable' frags as the comment says:
> >
> > + * @devmem: indicates that all the fragments in this skb are backed by
> > + * device memory.
> >
> > The reason it's not a generic 'not_readable' flag is because handing
> > off a generic not_readable skb to the userspace is semantically not
> > what we're doing. recvmsg() is augmented in this patch series to
> > return a devmem skb to the user via a cmsg_devmem struct which refers
> > specifically to the memory in the dma-buf. recvmsg() in this patch
> > series is not augmented to give any 'not_readable' skb to the
> > userspace.
> >
> > IMHO skb->devmem + an skb_frags_not_readable() as implemented is
> > correct. If a new type of unreadable skbs are introduced to the stack,
> > I imagine the stack
Re: [PATCH v4 2/3] drm/panel-edp: Add override_edid_mode quirk for generic edp
On Mon, 6 Nov 2023 at 23:03, Hsin-Yi Wang wrote:
>
> Generic edp gets mode from edid. However, some panels report incorrect
> mode in this way, resulting in glitches on panel. Introduce a new quirk
> additional_mode to the generic edid to pick a correct hardcoded mode.
>
> Signed-off-by: Hsin-Yi Wang
> Reviewed-by: Douglas Anderson
> ---
> v3->v4: no change
> ---
> drivers/gpu/drm/panel/panel-edp.c | 68 ---
> 1 file changed, 63 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/panel/panel-edp.c
> b/drivers/gpu/drm/panel/panel-edp.c
> index 599a949d74d1..0fb439b5efb1 100644
> --- a/drivers/gpu/drm/panel/panel-edp.c
> +++ b/drivers/gpu/drm/panel/panel-edp.c
> @@ -203,6 +203,9 @@ struct edp_panel_entry {
>
> /** @name: Name of this panel (for printing to logs). */
> const char *name;
> +
> + /** @override_edid_mode: Override the mode obtained by edid. */
> + const struct drm_display_mode *override_edid_mode;
> };
>
> struct panel_edp {
> @@ -301,6 +304,25 @@ static unsigned int panel_edp_get_display_modes(struct
> panel_edp *panel,
> return num;
> }
>
> +static int panel_edp_override_edid_mode(struct panel_edp *panel,
> + struct drm_connector *connector,
> + const struct drm_display_mode
> *override_mode)
> +{
> + struct drm_display_mode *mode;
> +
> + mode = drm_mode_duplicate(connector->dev, override_mode);
> + if (mode) {
> + mode->type |= DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED;
> + drm_mode_set_name(mode);
> + drm_mode_probed_add(connector, mode);
> + return 1;
> + }
> +
> + dev_err(panel->base.dev, "failed to add additional mode\n");
> +
> + return 0;
Nit:
it is more typical to handle error cases as conditionals.
This means:
if (!mode) {
dev_err();
return 0;
}
mode->type |= ...
drm_mode_set_name();
drm_mode_probed_add();
return 1;
> +}
> +
> static int panel_edp_get_non_edid_modes(struct panel_edp *panel,
> struct drm_connector *connector)
> {
> @@ -568,6 +590,9 @@ static int panel_edp_get_modes(struct drm_panel *panel,
> {
> struct panel_edp *p = to_panel_edp(panel);
> int num = 0;
> + bool has_override_edid_mode = p->detected_panel &&
> + p->detected_panel != ERR_PTR(-EINVAL) &&
> + p->detected_panel->override_edid_mode;
>
> /* probe EDID if a DDC bus is available */
> if (p->ddc) {
> @@ -575,9 +600,18 @@ static int panel_edp_get_modes(struct drm_panel *panel,
>
> if (!p->edid)
> p->edid = drm_get_edid(connector, p->ddc);
> -
> - if (p->edid)
> - num += drm_add_edid_modes(connector, p->edid);
> + if (p->edid) {
> + if (has_override_edid_mode) {
> + /*
> +* override_edid_mode is specified. Use
> +* override_edid_mode instead of from edid.
> +*/
> + num += panel_edp_override_edid_mode(p,
> connector,
> +
> p->detected_panel->override_edid_mode);
> + } else {
> + num += drm_add_edid_modes(connector, p->edid);
> + }
> + }
>
> pm_runtime_mark_last_busy(panel->dev);
> pm_runtime_put_autosuspend(panel->dev);
> @@ -950,6 +984,19 @@ static const struct panel_desc auo_b101ean01 = {
> },
> };
>
> +static const struct drm_display_mode auo_b116xa3_mode = {
> + .clock = 70589,
> + .hdisplay = 1366,
> + .hsync_start = 1366 + 40,
> + .hsync_end = 1366 + 40 + 40,
> + .htotal = 1366 + 40 + 40 + 32,
> + .vdisplay = 768,
> + .vsync_start = 768 + 10,
> + .vsync_end = 768 + 10 + 12,
> + .vtotal = 768 + 10 + 12 + 6,
> + .flags = DRM_MODE_FLAG_NVSYNC | DRM_MODE_FLAG_NHSYNC,
> +};
> +
> static const struct drm_display_mode auo_b116xak01_mode = {
> .clock = 69300,
> .hdisplay = 1366,
> @@ -1878,6 +1925,15 @@ static const struct panel_delay delay_200_150_e200 = {
> .delay = _delay \
> }
>
> +#define EDP_PANEL_ENTRY2(vend_chr_0, vend_chr_1, vend_chr_2, product_id,
> _delay, _name, _mode) \
> +{ \
> + .name = _name, \
> + .panel_id = drm_edid_encode_panel_id(vend_chr_0, vend_chr_1,
> vend_chr_2, \
> +product_id), \
> + .delay = _delay, \
> + .override_edid_mode = _mode \
> +}
> +
> /*
> * This table is used to figure out power sequencing delays for panels that
> * are detected by EDID. Entries here may point to
Re: [PATCH v3 1/3] drm/panel-edp: drm/panel-edp: Add several generic edp panels
On Mon, 6 Nov 2023 at 22:27, Hsin-Yi Wang wrote:
>
> Add a few generic edp panels used by mt8186 chromebooks.
> Besides, modify the following panel:
> - AUO 0x235c B116XTN02 renamed to B116XTN02.3.
> - AUO 0x405c B116XAK01 adjust the timing of auo_b116xak01. According
> to the datasheet: T3=200, T12=500, T7_max = 50.
Generally speaking, these two chunks can go into a separate patch,
which has Fixes tag and cc:stable to get it backported to earlier
kernels.
>
> Signed-off-by: Hsin-Yi Wang
> Reviewed-by: Douglas Anderson
> ---
> v2->v3: fix title
> ---
> drivers/gpu/drm/panel/panel-edp.c | 57 +--
> 1 file changed, 55 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/panel/panel-edp.c
> b/drivers/gpu/drm/panel/panel-edp.c
> index 9dce4c702414..599a949d74d1 100644
> --- a/drivers/gpu/drm/panel/panel-edp.c
> +++ b/drivers/gpu/drm/panel/panel-edp.c
> @@ -973,6 +973,8 @@ static const struct panel_desc auo_b116xak01 = {
> },
> .delay = {
> .hpd_absent = 200,
> + .unprepare = 500,
> + .enable = 50,
> },
> };
>
> @@ -1830,6 +1832,12 @@ static const struct panel_delay delay_200_500_e50 = {
> .enable = 50,
> };
>
> +static const struct panel_delay delay_200_500_e80 = {
> + .hpd_absent = 200,
> + .unprepare = 500,
> + .enable = 80,
> +};
> +
> static const struct panel_delay delay_200_500_e80_d50 = {
> .hpd_absent = 200,
> .unprepare = 500,
> @@ -1849,6 +1857,19 @@ static const struct panel_delay delay_200_500_e200 = {
> .enable = 200,
> };
>
> +static const struct panel_delay delay_200_500_e200_d10 = {
> + .hpd_absent = 200,
> + .unprepare = 500,
> + .enable = 200,
> + .disable = 10,
> +};
> +
> +static const struct panel_delay delay_200_150_e200 = {
> + .hpd_absent = 200,
> + .unprepare = 150,
> + .enable = 200,
> +};
> +
> #define EDP_PANEL_ENTRY(vend_chr_0, vend_chr_1, vend_chr_2, product_id,
> _delay, _name) \
> { \
> .name = _name, \
> @@ -1869,37 +1890,69 @@ static const struct edp_panel_entry edp_panels[] = {
> EDP_PANEL_ENTRY('A', 'U', 'O', 0x145c, _200_500_e50,
> "B116XAB01.4"),
> EDP_PANEL_ENTRY('A', 'U', 'O', 0x1e9b, _200_500_e50,
> "B133UAN02.1"),
> EDP_PANEL_ENTRY('A', 'U', 'O', 0x1ea5, _200_500_e50,
> "B116XAK01.6"),
> - EDP_PANEL_ENTRY('A', 'U', 'O', 0x235c, _200_500_e50,
> "B116XTN02"),
> - EDP_PANEL_ENTRY('A', 'U', 'O', 0x405c, _b116xak01.delay,
> "B116XAK01"),
> + EDP_PANEL_ENTRY('A', 'U', 'O', 0x208d, _200_500_e50,
> "B140HTN02.1"),
> + EDP_PANEL_ENTRY('A', 'U', 'O', 0x235c, _200_500_e50,
> "B116XTN02.3"),
> + EDP_PANEL_ENTRY('A', 'U', 'O', 0x239b, _200_500_e50,
> "B116XAN06.1"),
> + EDP_PANEL_ENTRY('A', 'U', 'O', 0x255c, _200_500_e50,
> "B116XTN02.5"),
> + EDP_PANEL_ENTRY('A', 'U', 'O', 0x403d, _200_500_e50,
> "B140HAN04.0"),
> + EDP_PANEL_ENTRY('A', 'U', 'O', 0x405c, _b116xak01.delay,
> "B116XAK01.0"),
> EDP_PANEL_ENTRY('A', 'U', 'O', 0x582d, _200_500_e50,
> "B133UAN01.0"),
> EDP_PANEL_ENTRY('A', 'U', 'O', 0x615c, _200_500_e50,
> "B116XAN06.1"),
> + EDP_PANEL_ENTRY('A', 'U', 'O', 0x635c, _200_500_e50,
> "B116XAN06.3"),
> + EDP_PANEL_ENTRY('A', 'U', 'O', 0x639c, _200_500_e50,
> "B140HAK02.7"),
> EDP_PANEL_ENTRY('A', 'U', 'O', 0x8594, _200_500_e50,
> "B133UAN01.0"),
> + EDP_PANEL_ENTRY('A', 'U', 'O', 0xf390, _200_500_e50,
> "B140XTN07.7"),
>
> + EDP_PANEL_ENTRY('B', 'O', 'E', 0x0715, _200_150_e200,
> "NT116WHM-N21"),
> + EDP_PANEL_ENTRY('B', 'O', 'E', 0x0731, _200_500_e80,
> "NT116WHM-N42"),
> + EDP_PANEL_ENTRY('B', 'O', 'E', 0x0741, _200_500_e200,
> "NT116WHM-N44"),
> EDP_PANEL_ENTRY('B', 'O', 'E', 0x0786, _200_500_p2e80,
> "NV116WHM-T01"),
> EDP_PANEL_ENTRY('B', 'O', 'E', 0x07d1, _nv133fhm_n61.delay,
> "NV133FHM-N61"),
> + EDP_PANEL_ENTRY('B', 'O', 'E', 0x07f6, _200_500_e200,
> "NT140FHM-N44"),
> EDP_PANEL_ENTRY('B', 'O', 'E', 0x082d, _nv133fhm_n61.delay,
> "NV133FHM-N62"),
> + EDP_PANEL_ENTRY('B', 'O', 'E', 0x08b2, _200_500_e200,
> "NT140WHM-N49"),
> EDP_PANEL_ENTRY('B', 'O', 'E', 0x09c3, _200_500_e50,
> "NT116WHM-N21,836X2"),
> EDP_PANEL_ENTRY('B', 'O', 'E', 0x094b, _200_500_e50,
> "NT116WHM-N21"),
> + EDP_PANEL_ENTRY('B', 'O', 'E', 0x0951, _200_500_e80,
> "NV116WHM-N47"),
> EDP_PANEL_ENTRY('B', 'O', 'E', 0x095f, _200_500_e50,
> "NE135FBM-N41 v8.1"),
> EDP_PANEL_ENTRY('B', 'O', 'E', 0x0979, _200_500_e50,
> "NV116WHM-N49 V8.0"),
> EDP_PANEL_ENTRY('B', 'O', 'E', 0x098d, _nv110wtm_n61.delay,
> "NV110WTM-N61"),
> + EDP_PANEL_ENTRY('B', 'O', 'E', 0x09ae, _200_500_e200,
> "NT140FHM-N45"),
> EDP_PANEL_ENTRY('B', 'O', 'E', 0x09dd, _200_500_e50,
> "NT116WHM-N21"),
> EDP_PANEL_ENTRY('B', 'O', 'E', 0x0a5d, _200_500_e50,
Re: [PATCH] drm/msm/dpu: correct clk bit for WB2 block
On Mon, 6 Nov 2023 at 20:39, Abhinav Kumar wrote:
>
> Sorry for the delay in getting back on this. There was quite a bit of
> history digging I had to do myself to give a certain response.
>
>
> On 10/9/2023 10:11 AM, Dmitry Baryshkov wrote:
> > On sc7280 there are two clk bits for WB2: control and status. While
> > programming the VBIF params of WB, the driver should be toggling the
> > former bit, while the sc7280_mdp struct lists the latter one.
> >
>
> No, this is not correct. Both are control bits. But for the context of
> where this is being used today, that is setting the VBIF OT limit, we
> should be using the VBIF_CLI one. So the below change itself is correct
> but not the commit text.
Maybe you can update dt bindings for the SDE driver? Because they
clearly speak about the control and status bits.
>
> We need to make the same change on sm8250 WB2 as well as this register
> is present there too. In fact, anything >=msm8994 for setting VBIF OT
> for WB2 we should be using VBIF_CLI bits of register MDP_CLK_CTRL2
> (offset 0x2bc).
>
> For anything >=sm8550, we need to use WB_2_CLK_CTRL present within the
> WB block and not the one in the top.
>
> Hence for this change, we can do below:
>
> -> update the commit text to indicate both are control bits but for the
> vbif ot context we should using the corrected one
> -> if you can also add sm8250 in the same change i can ack it and pick it up
>
> Have you re-validated WB with this change? If not, let me know I shall
> while picking this up for -fixes.
No, I haven't validated this on sc7280. I'll try this on sm8250 and
then I'll send v2.
>
> > Correct that to ensure proper programming sequence for WB2 on sc7280.
> >
> > Fixes: 3ce166380567 ("drm/msm/dpu: add writeback support for sc7280")
> > Signed-off-by: Dmitry Baryshkov
> > ---
> > drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h
> > b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h
> > index 3b5061c4402a..9195cb996f44 100644
> > --- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h
> > +++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h
> > @@ -25,7 +25,7 @@ static const struct dpu_mdp_cfg sc7280_mdp = {
> > [DPU_CLK_CTRL_DMA0] = { .reg_off = 0x2ac, .bit_off = 8 },
> > [DPU_CLK_CTRL_DMA1] = { .reg_off = 0x2b4, .bit_off = 8 },
> > [DPU_CLK_CTRL_DMA2] = { .reg_off = 0x2c4, .bit_off = 8 },
> > - [DPU_CLK_CTRL_WB2] = { .reg_off = 0x3b8, .bit_off = 24 },
> > + [DPU_CLK_CTRL_WB2] = { .reg_off = 0x2bc, .bit_off = 16 },
> > },
> > };
> >
--
With best wishes
Dmitry
Re: [RFC PATCH v3 09/12] net: add support for skbs with unreadable frags
On 11/06, Mina Almasry wrote:
> On Mon, Nov 6, 2023 at 11:34 AM David Ahern wrote:
> >
> > On 11/6/23 11:47 AM, Stanislav Fomichev wrote:
> > > On 11/05, Mina Almasry wrote:
> > >> For device memory TCP, we expect the skb headers to be available in host
> > >> memory for access, and we expect the skb frags to be in device memory
> > >> and unaccessible to the host. We expect there to be no mixing and
> > >> matching of device memory frags (unaccessible) with host memory frags
> > >> (accessible) in the same skb.
> > >>
> > >> Add a skb->devmem flag which indicates whether the frags in this skb
> > >> are device memory frags or not.
> > >>
> > >> __skb_fill_page_desc() now checks frags added to skbs for page_pool_iovs,
> > >> and marks the skb as skb->devmem accordingly.
> > >>
> > >> Add checks through the network stack to avoid accessing the frags of
> > >> devmem skbs and avoid coalescing devmem skbs with non devmem skbs.
> > >>
> > >> Signed-off-by: Willem de Bruijn
> > >> Signed-off-by: Kaiyuan Zhang
> > >> Signed-off-by: Mina Almasry
> > >>
> > >> ---
> > >> include/linux/skbuff.h | 14 +++-
> > >> include/net/tcp.h | 5 +--
> > >> net/core/datagram.c| 6
> > >> net/core/gro.c | 5 ++-
> > >> net/core/skbuff.c | 77 --
> > >> net/ipv4/tcp.c | 6
> > >> net/ipv4/tcp_input.c | 13 +--
> > >> net/ipv4/tcp_output.c | 5 ++-
> > >> net/packet/af_packet.c | 4 +--
> > >> 9 files changed, 115 insertions(+), 20 deletions(-)
> > >>
> > >> diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
> > >> index 1fae276c1353..8fb468ff8115 100644
> > >> --- a/include/linux/skbuff.h
> > >> +++ b/include/linux/skbuff.h
> > >> @@ -805,6 +805,8 @@ typedef unsigned char *sk_buff_data_t;
> > >> * @csum_level: indicates the number of consecutive checksums found in
> > >> * the packet minus one that have been verified as
> > >> * CHECKSUM_UNNECESSARY (max 3)
> > >> + * @devmem: indicates that all the fragments in this skb are backed by
> > >> + * device memory.
> > >> * @dst_pending_confirm: need to confirm neighbour
> > >> * @decrypted: Decrypted SKB
> > >> * @slow_gro: state present at GRO time, slower prepare step required
> > >> @@ -991,7 +993,7 @@ struct sk_buff {
> > >> #if IS_ENABLED(CONFIG_IP_SCTP)
> > >> __u8csum_not_inet:1;
> > >> #endif
> > >> -
> > >> +__u8devmem:1;
> > >> #if defined(CONFIG_NET_SCHED) || defined(CONFIG_NET_XGRESS)
> > >> __u16 tc_index; /* traffic control index */
> > >> #endif
> > >> @@ -1766,6 +1768,12 @@ static inline void
> > >> skb_zcopy_downgrade_managed(struct sk_buff *skb)
> > >> __skb_zcopy_downgrade_managed(skb);
> > >> }
> > >>
> > >> +/* Return true if frags in this skb are not readable by the host. */
> > >> +static inline bool skb_frags_not_readable(const struct sk_buff *skb)
> > >> +{
> > >> +return skb->devmem;
> > >
> > > bikeshedding: should we also rename 'devmem' sk_buff flag to
> > > 'not_readable'?
> > > It better communicates the fact that the stack shouldn't dereference the
> > > frags (because it has 'devmem' fragments or for some other potential
> > > future reason).
> >
> > +1.
> >
> > Also, the flag on the skb is an optimization - a high level signal that
> > one or more frags is in unreadable memory. There is no requirement that
> > all of the frags are in the same memory type.
David: maybe there should be such a requirement (that they all are
unreadable)? Might be easier to support initially; we can relax later
on.
> The flag indicates that the skb contains all devmem dma-buf memory
> specifically, not generic 'not_readable' frags as the comment says:
>
> + * @devmem: indicates that all the fragments in this skb are backed by
> + * device memory.
>
> The reason it's not a generic 'not_readable' flag is because handing
> off a generic not_readable skb to the userspace is semantically not
> what we're doing. recvmsg() is augmented in this patch series to
> return a devmem skb to the user via a cmsg_devmem struct which refers
> specifically to the memory in the dma-buf. recvmsg() in this patch
> series is not augmented to give any 'not_readable' skb to the
> userspace.
>
> IMHO skb->devmem + an skb_frags_not_readable() as implemented is
> correct. If a new type of unreadable skbs are introduced to the stack,
> I imagine the stack would implement:
>
> 1. new header flag: skb->newmem
> 2.
>
> static inline bool skb_frags_not_readable(const struct skb_buff *skb)
> {
> return skb->devmem || skb->newmem;
> }
>
> 3. tcp_recvmsg_devmem() would handle skb->devmem skbs is in this patch
> series, but tcp_recvmsg_newmem() would handle skb->newmem skbs.
You copy it to the userspace in a special way because your frags
are page_is_page_pool_iov(). I agree with David, the skb bit is
just and optimization.
Re: [PATCH] drivers: gpu: Fix warning using plain integer as NULL
On Mon, Nov 6, 2023 at 4:20 PM Abhinav Singh
wrote:
>
> On 11/7/23 00:25, Alex Deucher wrote:
> > Applied. This matches what we already do in the other clear state headers.
> >
> > Alex
> >
> > On Fri, Nov 3, 2023 at 12:00 PM Abhinav Singh
> > wrote:
> >>
> >> sparse static analysis tools generate a warning with this message
> >> "Using plain integer as NULL pointer". In this case this warning is
> >> being shown because we are trying to intialize a pointer to NULL using
> >> integer value 0.
> >>
> >> Signed-off-by: Abhinav Singh
> >> ---
> >> drivers/gpu/drm/radeon/clearstate_evergreen.h | 8
> >> 1 file changed, 4 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/radeon/clearstate_evergreen.h
> >> b/drivers/gpu/drm/radeon/clearstate_evergreen.h
> >> index 63a1ffbb3ced..3b645558f133 100644
> >> --- a/drivers/gpu/drm/radeon/clearstate_evergreen.h
> >> +++ b/drivers/gpu/drm/radeon/clearstate_evergreen.h
> >> @@ -1049,7 +1049,7 @@ static const struct cs_extent_def
> >> SECT_CONTEXT_defs[] =
> >> {SECT_CONTEXT_def_5, 0xa29e, 5 },
> >> {SECT_CONTEXT_def_6, 0xa2a5, 56 },
> >> {SECT_CONTEXT_def_7, 0xa2de, 290 },
> >> -{ 0, 0, 0 }
> >> +{ NULL, 0, 0 }
> >> };
> >> static const u32 SECT_CLEAR_def_1[] =
> >> {
> >> @@ -1060,7 +1060,7 @@ static const u32 SECT_CLEAR_def_1[] =
> >> static const struct cs_extent_def SECT_CLEAR_defs[] =
> >> {
> >> {SECT_CLEAR_def_1, 0xffc0, 3 },
> >> -{ 0, 0, 0 }
> >> +{ NULL, 0, 0 }
> >> };
> >> static const u32 SECT_CTRLCONST_def_1[] =
> >> {
> >> @@ -1070,11 +1070,11 @@ static const u32 SECT_CTRLCONST_def_1[] =
> >> static const struct cs_extent_def SECT_CTRLCONST_defs[] =
> >> {
> >> {SECT_CTRLCONST_def_1, 0xf3fc, 2 },
> >> -{ 0, 0, 0 }
> >> +{ NULL, 0, 0 }
> >> };
> >> static const struct cs_section_def evergreen_cs_data[] = {
> >> { SECT_CONTEXT_defs, SECT_CONTEXT },
> >> { SECT_CLEAR_defs, SECT_CLEAR },
> >> { SECT_CTRLCONST_defs, SECT_CTRLCONST },
> >> -{ 0, SECT_NONE }
> >> +{ NULL, SECT_NONE }
> >> };
> >> --
> >> 2.39.2
> >>
> Hi Alex, thanks for looking into this. By applied you mean this patch is
> accepted and it has been merged?
Yes. Once it makes it through our CI system, it will show up in my
drm-next tree.
Alex
Re: [PATCH v4 09/30] drm/dp: Add helpers to calculate the link BW overhead
On Mon, Oct 30, 2023 at 05:58:22PM +0200, Imre Deak wrote:
> Add helpers drivers can use to calculate the BW allocation overhead -
> due to SSC, FEC, DSC and data alignment on symbol cycles - and the
> channel coding efficiency - due to the 8b/10b, 128b/132b encoding. On
> 128b/132b links the FEC overhead is part of the coding efficiency, so
> not accounted for in the BW allocation overhead.
>
> The drivers can use these functions to calculate a ratio, controlling
> the stream symbol insertion rate of the source device in each SST TU
> or MST MTP frame. Drivers can calculate this
>
> m/n = (pixel_data_rate * drm_dp_bw_overhead()) /
> (link_data_rate * drm_dp_bw_channel_coding_efficiency())
>
> ratio for a given link and pixel stream and with that the
>
> mtp_count = CEIL(64 * m / n)
>
> allocated MTPs for the stream in a link frame and
>
> pbn = CEIL(64 * dm_mst_get_pbn_divider() * m / n)
>
> allocated PBNs for the stream on the MST link path.
>
> Take drm_dp_bw_overhead() into use in drm_dp_calc_pbn_mode(), for
> drivers calculating the PBN value directly.
>
> v2:
> - Add dockbook description to drm_dp_bw_channel_coding_efficiency().
> (LKP).
> - Clarify the way m/n ratio is calculated in the commit log.
> v3:
> - Fix compile breakage for !CONFIG_BACKLIGHT_CLASS_DEVICE. (LKP)
> - Account for FEC_PM overhead (+ 0.0015625 %), add comment
> with the formula to calculate the total FEC overhead. (Ville)
> v4:
> - Rename DRM_DP_OVERHEAD_SSC to DRM_DP_OVERHEAD_SSC_REF_CLK. (Ville)
>
> Cc: Lyude Paul
> Cc: Ville Syrjälä
> Cc: kernel test robot
> Cc: dri-devel@lists.freedesktop.org
> Reviewed-by: Stanislav Lisovskiy (v2)
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/display/drm_dp_helper.c | 132 ++
> drivers/gpu/drm/display/drm_dp_mst_topology.c | 23 ++-
> include/drm/display/drm_dp_helper.h | 11 ++
> 3 files changed, 160 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/display/drm_dp_helper.c
> b/drivers/gpu/drm/display/drm_dp_helper.c
> index e5d7970a9ddd0..72ba9ae89f862 100644
> --- a/drivers/gpu/drm/display/drm_dp_helper.c
> +++ b/drivers/gpu/drm/display/drm_dp_helper.c
> @@ -3900,3 +3900,135 @@ int drm_panel_dp_aux_backlight(struct drm_panel
> *panel, struct drm_dp_aux *aux)
> EXPORT_SYMBOL(drm_panel_dp_aux_backlight);
>
> #endif
> +
> +/* See DP Standard v2.1 2.6.4.4.1.1, 2.8.4.4, 2.8.7 */
> +static int drm_dp_link_symbol_cycles(int lane_count, int pixels, int bpp_x16,
> + int symbol_size, bool is_mst)
> +{
> + int cycles = DIV_ROUND_UP(pixels * bpp_x16, 16 * symbol_size *
> lane_count);
> + int align = is_mst ? 4 / lane_count : 1;
> +
> + return ALIGN(cycles, align);
> +}
> +
> +static int drm_dp_link_dsc_symbol_cycles(int lane_count, int pixels, int
> slice_count,
> + int bpp_x16, int symbol_size, bool
> is_mst)
> +{
> + int slice_pixels = DIV_ROUND_UP(pixels, slice_count);
> + int slice_data_cycles = drm_dp_link_symbol_cycles(lane_count,
> slice_pixels,
> + bpp_x16, symbol_size,
> is_mst);
> + int slice_eoc_cycles = is_mst ? 4 / lane_count : 1;
> +
> + return slice_count * (slice_data_cycles + slice_eoc_cycles);
> +}
> +
> +/**
> + * drm_dp_bw_overhead - Calculate the BW overhead of a DP link stream
> + * @lane_count: DP link lane count
> + * @hactive: pixel count of the active period in one scanline of the stream
> + * @dsc_slice_count: DSC slice count if @flags/DRM_DP_LINK_BW_OVERHEAD_DSC
> is set
> + * @bpp_x16: bits per pixel in .4 binary fixed point
> + * @flags: DRM_DP_OVERHEAD_x flags
> + *
> + * Calculate the BW allocation overhead of a DP link stream, depending
> + * on the link's
> + * - @lane_count
> + * - SST/MST mode (@flags / %DRM_DP_OVERHEAD_MST)
> + * - symbol size (@flags / %DRM_DP_OVERHEAD_UHBR)
> + * - FEC mode (@flags / %DRM_DP_OVERHEAD_FEC)
> + * - SSC/REF_CLK mode (@flags / %DRM_DP_OVERHEAD_SSC_REF_CLK)
> + * as well as the stream's
> + * - @hactive timing
> + * - @bpp_x16 color depth
> + * - compression mode (@flags / %DRM_DP_OVERHEAD_DSC).
> + * Note that this overhead doesn't account for the 8b/10b, 128b/132b
> + * channel coding efficiency, for that see
> + * @drm_dp_link_bw_channel_coding_efficiency().
> + *
> + * Returns the overhead as 100% + overhead% in 1ppm units.
> + */
> +int drm_dp_bw_overhead(int lane_count, int hactive,
> +int dsc_slice_count,
> +int bpp_x16, unsigned long flags)
> +{
> + int symbol_size = flags & DRM_DP_BW_OVERHEAD_UHBR ? 32 : 8;
> + bool is_mst = flags & DRM_DP_BW_OVERHEAD_MST;
> + u32 overhead = 100;
> + int symbol_cycles;
> +
> + /*
> + * DP Standard v2.1 2.6.4.1
> + * SSC downspread and ref clock variation margin:
> + * 5300ppm + 300ppm ~ 0.6%
> + */
> + if (flags & DRM_DP_BW_OVERHEAD_SSC_REF_CLK)
> +
Re: [PATCH] drivers: gpu: Fix warning using plain integer as NULL
On 11/7/23 00:25, Alex Deucher wrote:
Applied. This matches what we already do in the other clear state headers.
Alex
On Fri, Nov 3, 2023 at 12:00 PM Abhinav Singh
wrote:
sparse static analysis tools generate a warning with this message
"Using plain integer as NULL pointer". In this case this warning is
being shown because we are trying to intialize a pointer to NULL using
integer value 0.
Signed-off-by: Abhinav Singh
---
drivers/gpu/drm/radeon/clearstate_evergreen.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/radeon/clearstate_evergreen.h
b/drivers/gpu/drm/radeon/clearstate_evergreen.h
index 63a1ffbb3ced..3b645558f133 100644
--- a/drivers/gpu/drm/radeon/clearstate_evergreen.h
+++ b/drivers/gpu/drm/radeon/clearstate_evergreen.h
@@ -1049,7 +1049,7 @@ static const struct cs_extent_def SECT_CONTEXT_defs[] =
{SECT_CONTEXT_def_5, 0xa29e, 5 },
{SECT_CONTEXT_def_6, 0xa2a5, 56 },
{SECT_CONTEXT_def_7, 0xa2de, 290 },
-{ 0, 0, 0 }
+{ NULL, 0, 0 }
};
static const u32 SECT_CLEAR_def_1[] =
{
@@ -1060,7 +1060,7 @@ static const u32 SECT_CLEAR_def_1[] =
static const struct cs_extent_def SECT_CLEAR_defs[] =
{
{SECT_CLEAR_def_1, 0xffc0, 3 },
-{ 0, 0, 0 }
+{ NULL, 0, 0 }
};
static const u32 SECT_CTRLCONST_def_1[] =
{
@@ -1070,11 +1070,11 @@ static const u32 SECT_CTRLCONST_def_1[] =
static const struct cs_extent_def SECT_CTRLCONST_defs[] =
{
{SECT_CTRLCONST_def_1, 0xf3fc, 2 },
-{ 0, 0, 0 }
+{ NULL, 0, 0 }
};
static const struct cs_section_def evergreen_cs_data[] = {
{ SECT_CONTEXT_defs, SECT_CONTEXT },
{ SECT_CLEAR_defs, SECT_CLEAR },
{ SECT_CTRLCONST_defs, SECT_CTRLCONST },
-{ 0, SECT_NONE }
+{ NULL, SECT_NONE }
};
--
2.39.2
Hi Alex, thanks for looking into this. By applied you mean this patch is
accepted and it has been merged?
Re: [RFC PATCH v3 10/12] tcp: RX path for devmem TCP
On 11/06, Mina Almasry wrote:
> On Mon, Nov 6, 2023 at 10:44 AM Stanislav Fomichev wrote:
> >
> > On 11/05, Mina Almasry wrote:
> > > In tcp_recvmsg_locked(), detect if the skb being received by the user
> > > is a devmem skb. In this case - if the user provided the MSG_SOCK_DEVMEM
> > > flag - pass it to tcp_recvmsg_devmem() for custom handling.
> > >
> > > tcp_recvmsg_devmem() copies any data in the skb header to the linear
> > > buffer, and returns a cmsg to the user indicating the number of bytes
> > > returned in the linear buffer.
> > >
> > > tcp_recvmsg_devmem() then loops over the unaccessible devmem skb frags,
> > > and returns to the user a cmsg_devmem indicating the location of the
> > > data in the dmabuf device memory. cmsg_devmem contains this information:
> > >
> > > 1. the offset into the dmabuf where the payload starts. 'frag_offset'.
> > > 2. the size of the frag. 'frag_size'.
> > > 3. an opaque token 'frag_token' to return to the kernel when the buffer
> > > is to be released.
> > >
> > > The pages awaiting freeing are stored in the newly added
> > > sk->sk_user_pages, and each page passed to userspace is get_page()'d.
> > > This reference is dropped once the userspace indicates that it is
> > > done reading this page. All pages are released when the socket is
> > > destroyed.
> > >
> > > Signed-off-by: Willem de Bruijn
> > > Signed-off-by: Kaiyuan Zhang
> > > Signed-off-by: Mina Almasry
> > >
> > > ---
> > >
> > > RFC v3:
> > > - Fixed issue with put_cmsg() failing silently.
> > >
> > > ---
> > > include/linux/socket.h| 1 +
> > > include/net/page_pool/helpers.h | 9 ++
> > > include/net/sock.h| 2 +
> > > include/uapi/asm-generic/socket.h | 5 +
> > > include/uapi/linux/uio.h | 6 +
> > > net/ipv4/tcp.c| 189 +-
> > > net/ipv4/tcp_ipv4.c | 7 ++
> > > 7 files changed, 214 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/include/linux/socket.h b/include/linux/socket.h
> > > index cfcb7e2c3813..fe2b9e2081bb 100644
> > > --- a/include/linux/socket.h
> > > +++ b/include/linux/socket.h
> > > @@ -326,6 +326,7 @@ struct ucred {
> > > * plain text and require
> > > encryption
> > > */
> > >
> > > +#define MSG_SOCK_DEVMEM 0x200/* Receive devmem skbs as cmsg */
> >
> > Sharing the feedback that I've been providing internally on the public list:
> >
>
> There may have been a miscommunication. I don't recall hearing this
> specific feedback from you, at least in the last few months. Sorry if
> it seemed like I'm ignoring feedback :)
No worries, there was a thread long time ago about this whole token
interface and whether it should support out-of-order refills, etc.
> > IMHO, we need a better UAPI to receive the tokens and give them back to
> > the kernel. CMSG + setsockopt(SO_DEVMEM_DONTNEED) get the job done,
> > but look dated and hacky :-(
> >
> > We should either do some kind of user/kernel shared memory queue to
> > receive/return the tokens (similar to what Jonathan was doing in his
> > proposal?)
>
> I'll take a look at Jonathan's proposal, sorry, I'm not immediately
> familiar but I wanted to respond :-) But is the suggestion here to
> build a new kernel-user communication channel primitive for the
> purpose of passing the information in the devmem cmsg? IMHO that seems
> like an overkill. Why add 100-200 lines of code to the kernel to add
> something that can already be done with existing primitives? I don't
> see anything concretely wrong with cmsg & setsockopt approach, and if
> we switch to something I'd prefer to switch to an existing primitive
> for simplicity?
>
> The only other existing primitive to pass data outside of the linear
> buffer is the MSG_ERRQUEUE that is used for zerocopy. Is that
> preferred? Any other suggestions or existing primitives I'm not aware
> of?
I guess I'm just wondering whether other people have any suggestions
here. Not sure Jonathan's way was better, but we fundamentally
have two queues between the kernel and the userspace:
- userspace receiving tokens (recvmsg + magical flag)
- userspace refilling tokens (setsockopt + magical flag)
So having some kind of shared memory producer-consumer queue feels natural.
And using 'classic' socket api here feels like a stretch, idk.
But maybe I'm overthinking and overcomplicating :-)
> > or bite the bullet and switch to io_uring.
> >
>
> IMO io_uring & socket support are orthogonal, and one doesn't preclude
> the other. As you know we like to use sockets and I believe there are
> issues with io_uring adoption at Google that I'm not familiar with
> (and could be wrong). I'm interested in exploring io_uring support as
> a follow up but I think David Wei will be interested in io_uring
> support as well anyway.
Ack, might be one more reason on our side to adopt iouring :-p
> > I was also suggesting
Re: [RFC PATCH v3 10/12] tcp: RX path for devmem TCP
> > IMHO, we need a better UAPI to receive the tokens and give them back to > > the kernel. CMSG + setsockopt(SO_DEVMEM_DONTNEED) get the job done, > > but look dated and hacky :-( > > > > We should either do some kind of user/kernel shared memory queue to > > receive/return the tokens (similar to what Jonathan was doing in his > > proposal?) > > I'll take a look at Jonathan's proposal, sorry, I'm not immediately > familiar but I wanted to respond :-) But is the suggestion here to > build a new kernel-user communication channel primitive for the > purpose of passing the information in the devmem cmsg? IMHO that seems > like an overkill. Why add 100-200 lines of code to the kernel to add > something that can already be done with existing primitives? I don't > see anything concretely wrong with cmsg & setsockopt approach, and if > we switch to something I'd prefer to switch to an existing primitive > for simplicity? > > The only other existing primitive to pass data outside of the linear > buffer is the MSG_ERRQUEUE that is used for zerocopy. Is that > preferred? Any other suggestions or existing primitives I'm not aware > of? > > > or bite the bullet and switch to io_uring. > > > > IMO io_uring & socket support are orthogonal, and one doesn't preclude > the other. As you know we like to use sockets and I believe there are > issues with io_uring adoption at Google that I'm not familiar with > (and could be wrong). I'm interested in exploring io_uring support as > a follow up but I think David Wei will be interested in io_uring > support as well anyway. I also disagree that we need to replace a standard socket interface with something "faster", in quotes. This interface is not the bottleneck to the target workload. Replacing the synchronous sockets interface with something more performant for workloads where it is, is an orthogonal challenge. However we do that, I think that traditional sockets should continue to be supported. The feature may already even work with io_uring, as both recvmsg with cmsg and setsockopt have io_uring support now.
Re: [PATCH v4 3/3] drm/panel-edp: Avoid adding multiple preferred modes
Hi, On Mon, Nov 6, 2023 at 1:03 PM Hsin-Yi Wang wrote: > > @@ -622,7 +627,7 @@ static int panel_edp_get_modes(struct drm_panel *panel, > * and no modes (the generic edp-panel case) because it will clobber > * the display_info that was already set by drm_add_edid_modes(). > */ > - if (p->desc->num_timings || p->desc->num_modes) > + if (has_hard_coded_modes) nit: the comment above this line is a bit confusing now and probably needs to be updated or removed.
Re: [PATCH v2] drm: amd: Resolve Sphinx unexpected indentation warning
On 11/6/23 12:17, Hunter Chasens wrote: > Resolves Sphinx unexpected indentation warning when compiling > documentation (e.g. `make htmldocs`). Replaces tabs with spaces and adds > a literal block to keep vertical formatting of the > example power state list. > > Signed-off-by: Hunter Chasens Acked-by: Randy Dunlap Thanks. > --- > drivers/gpu/drm/amd/pm/amdgpu_pm.c | 13 +++-- > 1 file changed, 7 insertions(+), 6 deletions(-) > > diff --git a/drivers/gpu/drm/amd/pm/amdgpu_pm.c > b/drivers/gpu/drm/amd/pm/amdgpu_pm.c > index 517b9fb4624c..81b8ceb26890 100644 > --- a/drivers/gpu/drm/amd/pm/amdgpu_pm.c > +++ b/drivers/gpu/drm/amd/pm/amdgpu_pm.c > @@ -989,12 +989,13 @@ static ssize_t amdgpu_get_pp_features(struct device > *dev, > * Reading back the files will show you the available power levels within > * the power state and the clock information for those levels. If deep sleep > is > * applied to a clock, the level will be denoted by a special level 'S:' > - * E.g., > - * S: 19Mhz * > - * 0: 615Mhz > - * 1: 800Mhz > - * 2: 888Mhz > - * 3: 1000Mhz > + * E.g.:: > + * > + * S: 19Mhz * > + * 0: 615Mhz > + * 1: 800Mhz > + * 2: 888Mhz > + * 3: 1000Mhz > * > * > * To manually adjust these states, first select manual using -- ~Randy
[PATCH v4 3/3] drm/panel-edp: Avoid adding multiple preferred modes
If a non generic edp-panel is under aux-bus, the mode read from edid would
still be selected as preferred and results in multiple preferred modes,
which is ambiguous.
If both hard-coded mode and edid exists, only add mode from hard-coded.
Signed-off-by: Hsin-Yi Wang
---
v3->v4: don't skip read edid. only skip add modes.
---
drivers/gpu/drm/panel/panel-edp.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-edp.c
b/drivers/gpu/drm/panel/panel-edp.c
index 0fb439b5efb1..c8bb4baf1d45 100644
--- a/drivers/gpu/drm/panel/panel-edp.c
+++ b/drivers/gpu/drm/panel/panel-edp.c
@@ -590,6 +590,7 @@ static int panel_edp_get_modes(struct drm_panel *panel,
{
struct panel_edp *p = to_panel_edp(panel);
int num = 0;
+ bool has_hard_coded_modes = p->desc->num_timings || p->desc->num_modes;
bool has_override_edid_mode = p->detected_panel &&
p->detected_panel != ERR_PTR(-EINVAL) &&
p->detected_panel->override_edid_mode;
@@ -600,7 +601,11 @@ static int panel_edp_get_modes(struct drm_panel *panel,
if (!p->edid)
p->edid = drm_get_edid(connector, p->ddc);
- if (p->edid) {
+ /*
+* If both edid and hard-coded modes exists, skip edid modes to
+* avoid multiple preferred modes.
+*/
+ if (p->edid && !has_hard_coded_modes) {
if (has_override_edid_mode) {
/*
* override_edid_mode is specified. Use
@@ -622,7 +627,7 @@ static int panel_edp_get_modes(struct drm_panel *panel,
* and no modes (the generic edp-panel case) because it will clobber
* the display_info that was already set by drm_add_edid_modes().
*/
- if (p->desc->num_timings || p->desc->num_modes)
+ if (has_hard_coded_modes)
num += panel_edp_get_non_edid_modes(p, connector);
else if (!num)
dev_warn(p->base.dev, "No display modes\n");
--
2.42.0.869.gea05f2083d-goog
[PATCH v4 2/3] drm/panel-edp: Add override_edid_mode quirk for generic edp
Generic edp gets mode from edid. However, some panels report incorrect
mode in this way, resulting in glitches on panel. Introduce a new quirk
additional_mode to the generic edid to pick a correct hardcoded mode.
Signed-off-by: Hsin-Yi Wang
Reviewed-by: Douglas Anderson
---
v3->v4: no change
---
drivers/gpu/drm/panel/panel-edp.c | 68 ---
1 file changed, 63 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-edp.c
b/drivers/gpu/drm/panel/panel-edp.c
index 599a949d74d1..0fb439b5efb1 100644
--- a/drivers/gpu/drm/panel/panel-edp.c
+++ b/drivers/gpu/drm/panel/panel-edp.c
@@ -203,6 +203,9 @@ struct edp_panel_entry {
/** @name: Name of this panel (for printing to logs). */
const char *name;
+
+ /** @override_edid_mode: Override the mode obtained by edid. */
+ const struct drm_display_mode *override_edid_mode;
};
struct panel_edp {
@@ -301,6 +304,25 @@ static unsigned int panel_edp_get_display_modes(struct
panel_edp *panel,
return num;
}
+static int panel_edp_override_edid_mode(struct panel_edp *panel,
+ struct drm_connector *connector,
+ const struct drm_display_mode
*override_mode)
+{
+ struct drm_display_mode *mode;
+
+ mode = drm_mode_duplicate(connector->dev, override_mode);
+ if (mode) {
+ mode->type |= DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED;
+ drm_mode_set_name(mode);
+ drm_mode_probed_add(connector, mode);
+ return 1;
+ }
+
+ dev_err(panel->base.dev, "failed to add additional mode\n");
+
+ return 0;
+}
+
static int panel_edp_get_non_edid_modes(struct panel_edp *panel,
struct drm_connector *connector)
{
@@ -568,6 +590,9 @@ static int panel_edp_get_modes(struct drm_panel *panel,
{
struct panel_edp *p = to_panel_edp(panel);
int num = 0;
+ bool has_override_edid_mode = p->detected_panel &&
+ p->detected_panel != ERR_PTR(-EINVAL) &&
+ p->detected_panel->override_edid_mode;
/* probe EDID if a DDC bus is available */
if (p->ddc) {
@@ -575,9 +600,18 @@ static int panel_edp_get_modes(struct drm_panel *panel,
if (!p->edid)
p->edid = drm_get_edid(connector, p->ddc);
-
- if (p->edid)
- num += drm_add_edid_modes(connector, p->edid);
+ if (p->edid) {
+ if (has_override_edid_mode) {
+ /*
+* override_edid_mode is specified. Use
+* override_edid_mode instead of from edid.
+*/
+ num += panel_edp_override_edid_mode(p,
connector,
+
p->detected_panel->override_edid_mode);
+ } else {
+ num += drm_add_edid_modes(connector, p->edid);
+ }
+ }
pm_runtime_mark_last_busy(panel->dev);
pm_runtime_put_autosuspend(panel->dev);
@@ -950,6 +984,19 @@ static const struct panel_desc auo_b101ean01 = {
},
};
+static const struct drm_display_mode auo_b116xa3_mode = {
+ .clock = 70589,
+ .hdisplay = 1366,
+ .hsync_start = 1366 + 40,
+ .hsync_end = 1366 + 40 + 40,
+ .htotal = 1366 + 40 + 40 + 32,
+ .vdisplay = 768,
+ .vsync_start = 768 + 10,
+ .vsync_end = 768 + 10 + 12,
+ .vtotal = 768 + 10 + 12 + 6,
+ .flags = DRM_MODE_FLAG_NVSYNC | DRM_MODE_FLAG_NHSYNC,
+};
+
static const struct drm_display_mode auo_b116xak01_mode = {
.clock = 69300,
.hdisplay = 1366,
@@ -1878,6 +1925,15 @@ static const struct panel_delay delay_200_150_e200 = {
.delay = _delay \
}
+#define EDP_PANEL_ENTRY2(vend_chr_0, vend_chr_1, vend_chr_2, product_id,
_delay, _name, _mode) \
+{ \
+ .name = _name, \
+ .panel_id = drm_edid_encode_panel_id(vend_chr_0, vend_chr_1,
vend_chr_2, \
+product_id), \
+ .delay = _delay, \
+ .override_edid_mode = _mode \
+}
+
/*
* This table is used to figure out power sequencing delays for panels that
* are detected by EDID. Entries here may point to entries in the
@@ -1895,9 +1951,11 @@ static const struct edp_panel_entry edp_panels[] = {
EDP_PANEL_ENTRY('A', 'U', 'O', 0x239b, _200_500_e50,
"B116XAN06.1"),
EDP_PANEL_ENTRY('A', 'U', 'O', 0x255c, _200_500_e50,
"B116XTN02.5"),
EDP_PANEL_ENTRY('A', 'U', 'O', 0x403d, _200_500_e50,
"B140HAN04.0"),
- EDP_PANEL_ENTRY('A', 'U', 'O', 0x405c, _b116xak01.delay,
"B116XAK01.0"),
+ EDP_PANEL_ENTRY2('A', 'U', 'O', 0x405c, _b116xak01.delay,
[PATCH v4 1/3] drm/panel-edp: drm/panel-edp: Add several generic edp panels
Add a few generic edp panels used by mt8186 chromebooks.
Besides, modify the following panel:
- AUO 0x235c B116XTN02 renamed to B116XTN02.3.
- AUO 0x405c B116XAK01 adjust the timing of auo_b116xak01. According
to the datasheet: T3=200, T12=500, T7_max = 50.
Signed-off-by: Hsin-Yi Wang
Reviewed-by: Douglas Anderson
---
v3->v4: no change
---
drivers/gpu/drm/panel/panel-edp.c | 57 +--
1 file changed, 55 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-edp.c
b/drivers/gpu/drm/panel/panel-edp.c
index 9dce4c702414..599a949d74d1 100644
--- a/drivers/gpu/drm/panel/panel-edp.c
+++ b/drivers/gpu/drm/panel/panel-edp.c
@@ -973,6 +973,8 @@ static const struct panel_desc auo_b116xak01 = {
},
.delay = {
.hpd_absent = 200,
+ .unprepare = 500,
+ .enable = 50,
},
};
@@ -1830,6 +1832,12 @@ static const struct panel_delay delay_200_500_e50 = {
.enable = 50,
};
+static const struct panel_delay delay_200_500_e80 = {
+ .hpd_absent = 200,
+ .unprepare = 500,
+ .enable = 80,
+};
+
static const struct panel_delay delay_200_500_e80_d50 = {
.hpd_absent = 200,
.unprepare = 500,
@@ -1849,6 +1857,19 @@ static const struct panel_delay delay_200_500_e200 = {
.enable = 200,
};
+static const struct panel_delay delay_200_500_e200_d10 = {
+ .hpd_absent = 200,
+ .unprepare = 500,
+ .enable = 200,
+ .disable = 10,
+};
+
+static const struct panel_delay delay_200_150_e200 = {
+ .hpd_absent = 200,
+ .unprepare = 150,
+ .enable = 200,
+};
+
#define EDP_PANEL_ENTRY(vend_chr_0, vend_chr_1, vend_chr_2, product_id,
_delay, _name) \
{ \
.name = _name, \
@@ -1869,37 +1890,69 @@ static const struct edp_panel_entry edp_panels[] = {
EDP_PANEL_ENTRY('A', 'U', 'O', 0x145c, _200_500_e50,
"B116XAB01.4"),
EDP_PANEL_ENTRY('A', 'U', 'O', 0x1e9b, _200_500_e50,
"B133UAN02.1"),
EDP_PANEL_ENTRY('A', 'U', 'O', 0x1ea5, _200_500_e50,
"B116XAK01.6"),
- EDP_PANEL_ENTRY('A', 'U', 'O', 0x235c, _200_500_e50, "B116XTN02"),
- EDP_PANEL_ENTRY('A', 'U', 'O', 0x405c, _b116xak01.delay,
"B116XAK01"),
+ EDP_PANEL_ENTRY('A', 'U', 'O', 0x208d, _200_500_e50,
"B140HTN02.1"),
+ EDP_PANEL_ENTRY('A', 'U', 'O', 0x235c, _200_500_e50,
"B116XTN02.3"),
+ EDP_PANEL_ENTRY('A', 'U', 'O', 0x239b, _200_500_e50,
"B116XAN06.1"),
+ EDP_PANEL_ENTRY('A', 'U', 'O', 0x255c, _200_500_e50,
"B116XTN02.5"),
+ EDP_PANEL_ENTRY('A', 'U', 'O', 0x403d, _200_500_e50,
"B140HAN04.0"),
+ EDP_PANEL_ENTRY('A', 'U', 'O', 0x405c, _b116xak01.delay,
"B116XAK01.0"),
EDP_PANEL_ENTRY('A', 'U', 'O', 0x582d, _200_500_e50,
"B133UAN01.0"),
EDP_PANEL_ENTRY('A', 'U', 'O', 0x615c, _200_500_e50,
"B116XAN06.1"),
+ EDP_PANEL_ENTRY('A', 'U', 'O', 0x635c, _200_500_e50,
"B116XAN06.3"),
+ EDP_PANEL_ENTRY('A', 'U', 'O', 0x639c, _200_500_e50,
"B140HAK02.7"),
EDP_PANEL_ENTRY('A', 'U', 'O', 0x8594, _200_500_e50,
"B133UAN01.0"),
+ EDP_PANEL_ENTRY('A', 'U', 'O', 0xf390, _200_500_e50,
"B140XTN07.7"),
+ EDP_PANEL_ENTRY('B', 'O', 'E', 0x0715, _200_150_e200,
"NT116WHM-N21"),
+ EDP_PANEL_ENTRY('B', 'O', 'E', 0x0731, _200_500_e80,
"NT116WHM-N42"),
+ EDP_PANEL_ENTRY('B', 'O', 'E', 0x0741, _200_500_e200,
"NT116WHM-N44"),
EDP_PANEL_ENTRY('B', 'O', 'E', 0x0786, _200_500_p2e80,
"NV116WHM-T01"),
EDP_PANEL_ENTRY('B', 'O', 'E', 0x07d1, _nv133fhm_n61.delay,
"NV133FHM-N61"),
+ EDP_PANEL_ENTRY('B', 'O', 'E', 0x07f6, _200_500_e200,
"NT140FHM-N44"),
EDP_PANEL_ENTRY('B', 'O', 'E', 0x082d, _nv133fhm_n61.delay,
"NV133FHM-N62"),
+ EDP_PANEL_ENTRY('B', 'O', 'E', 0x08b2, _200_500_e200,
"NT140WHM-N49"),
EDP_PANEL_ENTRY('B', 'O', 'E', 0x09c3, _200_500_e50,
"NT116WHM-N21,836X2"),
EDP_PANEL_ENTRY('B', 'O', 'E', 0x094b, _200_500_e50,
"NT116WHM-N21"),
+ EDP_PANEL_ENTRY('B', 'O', 'E', 0x0951, _200_500_e80,
"NV116WHM-N47"),
EDP_PANEL_ENTRY('B', 'O', 'E', 0x095f, _200_500_e50,
"NE135FBM-N41 v8.1"),
EDP_PANEL_ENTRY('B', 'O', 'E', 0x0979, _200_500_e50,
"NV116WHM-N49 V8.0"),
EDP_PANEL_ENTRY('B', 'O', 'E', 0x098d, _nv110wtm_n61.delay,
"NV110WTM-N61"),
+ EDP_PANEL_ENTRY('B', 'O', 'E', 0x09ae, _200_500_e200,
"NT140FHM-N45"),
EDP_PANEL_ENTRY('B', 'O', 'E', 0x09dd, _200_500_e50,
"NT116WHM-N21"),
EDP_PANEL_ENTRY('B', 'O', 'E', 0x0a5d, _200_500_e50,
"NV116WHM-N45"),
EDP_PANEL_ENTRY('B', 'O', 'E', 0x0ac5, _200_500_e50,
"NV116WHM-N4C"),
+ EDP_PANEL_ENTRY('B', 'O', 'E', 0x0b43, _200_500_e200,
"NV140FHM-T09"),
+ EDP_PANEL_ENTRY('B', 'O', 'E', 0x0b56, _200_500_e80,
"NT140FHM-N47"),
+ EDP_PANEL_ENTRY('B', 'O', 'E', 0x0c20, _200_500_e80,
"NT140FHM-N47"),
+ EDP_PANEL_ENTRY('C', 'M', 'N', 0x1132, _200_500_e80_d50,
"N116BGE-EA2"),
+ EDP_PANEL_ENTRY('C',
[PATCH v4 0/3] Add a few panels and use correct modes
This series contains 3 patches: 1. Add a few new generic edp panels. 2. Support a new quirk to override the mode read from edid 3. Only add hard-coded mode if both edid and hard-coded modes presents. v1: https://patchwork.kernel.org/project/dri-devel/cover/20231101212604.1636517-1-hsi...@chromium.org/ v2: https://patchwork.kernel.org/project/dri-devel/cover/20231102221309.1971910-1-hsi...@chromium.org/ v3: https://patchwork.kernel.org/project/dri-devel/cover/20231106202718.2770821-1-hsi...@chromium.org/ Hsin-Yi Wang (3): drm/panel-edp: drm/panel-edp: Add several generic edp panels drm/panel-edp: Add override_edid_mode quirk for generic edp drm/panel-edp: Avoid adding multiple preferred modes drivers/gpu/drm/panel/panel-edp.c | 130 -- 1 file changed, 123 insertions(+), 7 deletions(-) -- 2.42.0.869.gea05f2083d-goog
Re: [RFC PATCH v3 06/12] memory-provider: dmabuf devmem memory provider
On 11/05, Mina Almasry wrote:
> Implement a memory provider that allocates dmabuf devmem page_pool_iovs.
>
> Support of PP_FLAG_DMA_MAP and PP_FLAG_DMA_SYNC_DEV is omitted for
> simplicity.
>
> The provider receives a reference to the struct netdev_dmabuf_binding
> via the pool->mp_priv pointer. The driver needs to set this pointer for
> the provider in the page_pool_params.
>
> The provider obtains a reference on the netdev_dmabuf_binding which
> guarantees the binding and the underlying mapping remains alive until
> the provider is destroyed.
>
> Signed-off-by: Willem de Bruijn
> Signed-off-by: Kaiyuan Zhang
> Signed-off-by: Mina Almasry
>
> ---
> include/net/page_pool/helpers.h | 40 +
> include/net/page_pool/types.h | 10 +
> net/core/page_pool.c| 76 +
> 3 files changed, 126 insertions(+)
>
> diff --git a/include/net/page_pool/helpers.h b/include/net/page_pool/helpers.h
> index 78cbb040af94..b93243c2a640 100644
> --- a/include/net/page_pool/helpers.h
> +++ b/include/net/page_pool/helpers.h
> @@ -53,6 +53,7 @@
> #define _NET_PAGE_POOL_HELPERS_H
>
> #include
> +#include
>
> #ifdef CONFIG_PAGE_POOL_STATS
> int page_pool_ethtool_stats_get_count(void);
> @@ -111,6 +112,45 @@ page_pool_iov_binding(const struct page_pool_iov *ppiov)
> return page_pool_iov_owner(ppiov)->binding;
> }
>
> +static inline int page_pool_iov_refcount(const struct page_pool_iov *ppiov)
> +{
> + return refcount_read(>refcount);
> +}
> +
> +static inline void page_pool_iov_get_many(struct page_pool_iov *ppiov,
> + unsigned int count)
> +{
> + refcount_add(count, >refcount);
> +}
> +
> +void __page_pool_iov_free(struct page_pool_iov *ppiov);
> +
> +static inline void page_pool_iov_put_many(struct page_pool_iov *ppiov,
> + unsigned int count)
> +{
> + if (!refcount_sub_and_test(count, >refcount))
> + return;
> +
> + __page_pool_iov_free(ppiov);
> +}
> +
> +/* page pool mm helpers */
> +
> +static inline bool page_is_page_pool_iov(const struct page *page)
> +{
> + return (unsigned long)page & PP_DEVMEM;
> +}
Speaking of bpf: one thing that might be problematic with this PP_DEVMEM
bit is that it will make debugging with bpftrace a bit (more)
complicated. If somebody were trying to get to that page_pool_iov from
the frags, they will have to do the equivalent of page_is_page_pool_iov,
but probably not a big deal? (thinking out loud)
Re: [RFC PATCH v3 09/12] net: add support for skbs with unreadable frags
On 11/05, Mina Almasry wrote: > For device memory TCP, we expect the skb headers to be available in host > memory for access, and we expect the skb frags to be in device memory > and unaccessible to the host. We expect there to be no mixing and > matching of device memory frags (unaccessible) with host memory frags > (accessible) in the same skb. > > Add a skb->devmem flag which indicates whether the frags in this skb > are device memory frags or not. > > __skb_fill_page_desc() now checks frags added to skbs for page_pool_iovs, > and marks the skb as skb->devmem accordingly. > > Add checks through the network stack to avoid accessing the frags of > devmem skbs and avoid coalescing devmem skbs with non devmem skbs. > > Signed-off-by: Willem de Bruijn > Signed-off-by: Kaiyuan Zhang > Signed-off-by: Mina Almasry [..] > - snaplen = skb->len; > + snaplen = skb_frags_not_readable(skb) ? skb_headlen(skb) : skb->len; > > res = run_filter(skb, sk, snaplen); > if (!res) > @@ -2279,7 +2279,7 @@ static int tpacket_rcv(struct sk_buff *skb, struct > net_device *dev, > } > } > > - snaplen = skb->len; > + snaplen = skb_frags_not_readable(skb) ? skb_headlen(skb) : skb->len; > > res = run_filter(skb, sk, snaplen); > if (!res) Not sure it covers 100% of bpf. We might need to double-check bpf_xdp_copy_buf which is having its own, non-skb shinfo and frags. And in general, xdp can reference those shinfo frags early... (xdp part happens before we create an skb with all devmem association)
Re: [RFC PATCH v2 05/17] drm/vkms: Avoid reading beyond LUT array
On 2023-10-30 09:29, Pekka Paalanen wrote:
> On Thu, 19 Oct 2023 17:21:21 -0400
> Harry Wentland wrote:
>
>> When the floor LUT index (drm_fixp2int(lut_index) is the last
>> index of the array the ceil LUT index will point to an entry
>> beyond the array. Make sure we guard against it and use the
>> value of the floot LUT index.
>>
>> Blurb about LUT creation and how first element should be 0x0 and
>> last one 0x.
>>
>> Hold on, is that even correct? What should the ends of a LUT be?
>> How does UNORM work and how does it apply to LUTs?
>
> Do you mean how should UNORM input value map to LUT entries for LUT
> indexing?
>
> I suppose UNORM 16-bit converts to nominal real values as:
> - 0x0: 0.0
> - 0x: 1.0
>
> And in LUT, you want 0.0 to map to the first LUT element exactly, and
> 1.0 to map to the last LUT element exactly, even if whatever
> interpolation may be in use, right?
>
> If so, it is important to make sure that, assuming linear interpolation
> for instance, there is no "dead zone" at either end. Given high
> interpolation precision, any step away from 0.0 or 1.0 needs to imply a
> change in the real-valued output, assuming e.g. identity LUT.
>
> If LUT has N elements, and 16-bit UNORM input value is I, then (in
> naive real-valued math, so no implicit truncation between operations)
>
> x = I / 0x * (N - 1)
> ia = floor(x)
> ib = min(ia + 1, N - 1)
>
> f = x - floor(x)
> y = (1 - f) * LUT[ia] + f * LUT[ib]
>
>
> Does that help?
>
Thanks. Yes, this is what the code is doing (with this commit).
The commit description was an oversight and only reflect my initial
thoughts when coding it, before I made sure this is the right way
to go about it. I'll update it.
Harry
> In my mind, I'm thinking of a uniformly distributed LUT as a 1-D
> texture, because that's how I have implemented them in GL. There you
> have to be careful so that input values 0.0 and 1.0 map to the *center*
> of the first and last texel, and not to the edges of the texture like
> texture coordinates do. Then you can use the GL linear texture
> interpolation as-is.
>
>
> Thanks,
> pq
>
>
>> Signed-off-by: Harry Wentland
>> Cc: Ville Syrjala
>> Cc: Pekka Paalanen
>> Cc: Simon Ser
>> Cc: Harry Wentland
>> Cc: Melissa Wen
>> Cc: Jonas Ådahl
>> Cc: Sebastian Wick
>> Cc: Shashank Sharma
>> Cc: Alexander Goins
>> Cc: Joshua Ashton
>> Cc: Michel Dänzer
>> Cc: Aleix Pol
>> Cc: Xaver Hugl
>> Cc: Victoria Brekenfeld
>> Cc: Sima
>> Cc: Uma Shankar
>> Cc: Naseer Ahmed
>> Cc: Christopher Braga
>> Cc: Abhinav Kumar
>> Cc: Arthur Grillo
>> Cc: Hector Martin
>> Cc: Liviu Dudau
>> Cc: Sasha McIntosh
>> ---
>> drivers/gpu/drm/vkms/vkms_composer.c | 14 ++
>> 1 file changed, 10 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/vkms/vkms_composer.c
>> b/drivers/gpu/drm/vkms/vkms_composer.c
>> index a0a3a6fd2926..cf1dff162920 100644
>> --- a/drivers/gpu/drm/vkms/vkms_composer.c
>> +++ b/drivers/gpu/drm/vkms/vkms_composer.c
>> @@ -123,6 +123,8 @@ static u16 apply_lut_to_channel_value(const struct
>> vkms_color_lut *lut, u16 chan
>>enum lut_channel channel)
>> {
>> s64 lut_index = get_lut_index(lut, channel_value);
>> +u16 *floor_lut_value, *ceil_lut_value;
>> +u16 floor_channel_value, ceil_channel_value;
>>
>> /*
>> * This checks if `struct drm_color_lut` has any gap added by the
>> compiler
>> @@ -130,11 +132,15 @@ static u16 apply_lut_to_channel_value(const struct
>> vkms_color_lut *lut, u16 chan
>> */
>> static_assert(sizeof(struct drm_color_lut) == sizeof(__u16) * 4);
>>
>> -u16 *floor_lut_value = (__u16 *)>base[drm_fixp2int(lut_index)];
>> -u16 *ceil_lut_value = (__u16 *)>base[drm_fixp2int_ceil(lut_index)];
>> +floor_lut_value = (__u16 *)>base[drm_fixp2int(lut_index)];
>> +if (drm_fixp2int(lut_index) == (lut->lut_length - 1))
>> +/* We're at the end of the LUT array, use same value for ceil
>> and floor */
>> +ceil_lut_value = floor_lut_value;
>> +else
>> +ceil_lut_value = (__u16
>> *)>base[drm_fixp2int_ceil(lut_index)];
>>
>> -u16 floor_channel_value = floor_lut_value[channel];
>> -u16 ceil_channel_value = ceil_lut_value[channel];
>> +floor_channel_value = floor_lut_value[channel];
>> +ceil_channel_value = ceil_lut_value[channel];
>>
>> return lerp_u16(floor_channel_value, ceil_channel_value,
>> lut_index & DRM_FIXED_DECIMAL_MASK);
>
Re: [PATCH v3 3/3] drm/panel-edp: Avoid adding multiple preferred modes
On Mon, Nov 6, 2023 at 12:33 PM Doug Anderson wrote:
>
> Hi,
>
> On Mon, Nov 6, 2023 at 12:27 PM Hsin-Yi Wang wrote:
> >
> > diff --git a/drivers/gpu/drm/panel/panel-edp.c
> > b/drivers/gpu/drm/panel/panel-edp.c
> > index 0fb439b5efb1..54dbbdf62ec0 100644
> > --- a/drivers/gpu/drm/panel/panel-edp.c
> > +++ b/drivers/gpu/drm/panel/panel-edp.c
> > @@ -594,8 +594,20 @@ static int panel_edp_get_modes(struct drm_panel *panel,
> > p->detected_panel != ERR_PTR(-EINVAL)
> > &&
> > p->detected_panel->override_edid_mode;
> >
> > - /* probe EDID if a DDC bus is available */
> > - if (p->ddc) {
> > + /*
> > +* If both edid and hard-coded modes exists, only add hard-coded
> > modes
> > +* to avoid multiple preferred modes.
> > +*/
> > + if (p->desc->num_timings || p->desc->num_modes) {
> > + /*
> > +* Add hard-coded panel modes. Don't call this if there are
> > no
> > +* timings and no modes (the generic edp-panel case)
> > because it
> > +* will clobber the display_info that was already set by
> > +* drm_add_edid_modes().
> > +*/
> > + num += panel_edp_get_non_edid_modes(p, connector);
> > + } else if (p->ddc) {
> > + /* probe EDID if a DDC bus is available */
>
> As per discussion in v2, I think if you have the "ddc" you still want
> to fetch the EDID, you just don't want to add the modes from the EDID.
> This will mean that the EDID is present in sysfs if userspace wants to
> look at it for whatever reason.
>
Ack. Will update this.
> -Doug
Re: [PATCH v3 3/3] drm/panel-edp: Avoid adding multiple preferred modes
Hi,
On Mon, Nov 6, 2023 at 12:27 PM Hsin-Yi Wang wrote:
>
> diff --git a/drivers/gpu/drm/panel/panel-edp.c
> b/drivers/gpu/drm/panel/panel-edp.c
> index 0fb439b5efb1..54dbbdf62ec0 100644
> --- a/drivers/gpu/drm/panel/panel-edp.c
> +++ b/drivers/gpu/drm/panel/panel-edp.c
> @@ -594,8 +594,20 @@ static int panel_edp_get_modes(struct drm_panel *panel,
> p->detected_panel != ERR_PTR(-EINVAL) &&
> p->detected_panel->override_edid_mode;
>
> - /* probe EDID if a DDC bus is available */
> - if (p->ddc) {
> + /*
> +* If both edid and hard-coded modes exists, only add hard-coded modes
> +* to avoid multiple preferred modes.
> +*/
> + if (p->desc->num_timings || p->desc->num_modes) {
> + /*
> +* Add hard-coded panel modes. Don't call this if there are no
> +* timings and no modes (the generic edp-panel case) because
> it
> +* will clobber the display_info that was already set by
> +* drm_add_edid_modes().
> +*/
> + num += panel_edp_get_non_edid_modes(p, connector);
> + } else if (p->ddc) {
> + /* probe EDID if a DDC bus is available */
As per discussion in v2, I think if you have the "ddc" you still want
to fetch the EDID, you just don't want to add the modes from the EDID.
This will mean that the EDID is present in sysfs if userspace wants to
look at it for whatever reason.
-Doug
Re: Blank screen on boot of Linux 6.5 and later on Lenovo ThinkPad L570
Hi Huacai,
On 2023-11-06 Mon 10:22pm, Huacai Chen wrote:
> On Mon, Nov 6, 2023 at 9:49 PM Jaak Ristioja wrote:
> >
> > On 06.11.23 04:15, Huacai Chen wrote:
> > > Hi, Jaak and Evan,
> > >
> > > On Mon, Nov 6, 2023 at 12:28 AM Jaak Ristioja wrote:
> > >>
> > >> On 05.11.23 14:40, Huacai Chen wrote:
> > >>> Hi, Evan,
> > >>>
> > >>> On Sat, Nov 4, 2023 at 10:50 AM Evan Preston
> > >>> wrote:
> >
> > Hi Huacai,
> >
> > On 2023-11-03 Fri 02:36pm, Huacai Chen wrote:
> > > Hi, Evan,
> > >
> > > On Fri, Nov 3, 2023 at 1:54 PM Evan Preston
> > > wrote:
> > >>
> > >> Hi Huacai,
> > >>
> > >> On 2023-11-02 Thu 08:38pm, Huacai Chen wrote:
> > >>> Hi, Jaak,
> > >>>
> > >>> On Wed, Nov 1, 2023 at 7:52 PM Jaak Ristioja
> > >>> wrote:
> >
> > On 31.10.23 14:17, Huacai Chen wrote:
> > > Hi, Jaak and Evan,
> > >
> > > On Sun, Oct 29, 2023 at 9:42 AM Huacai Chen
> > > wrote:
> > >>
> > >> On Sat, Oct 28, 2023 at 7:06 PM Jaak Ristioja
> > >> wrote:
> > >>>
> > >>> On 26.10.23 03:58, Huacai Chen wrote:
> > Hi, Jaak,
> >
> > On Thu, Oct 26, 2023 at 2:49 AM Jaak Ristioja
> > wrote:
> > >
> > > On 25.10.23 16:23, Huacai Chen wrote:
> > >> On Wed, Oct 25, 2023 at 6:08 PM Thorsten Leemhuis
> > >> wrote:
> > >>>
> > >>> Javier, Dave, Sima,
> > >>>
> > >>> On 23.10.23 00:54, Evan Preston wrote:
> > On 2023-10-20 Fri 05:48pm, Huacai Chen wrote:
> > > On Fri, Oct 20, 2023 at 5:35 PM Linux regression tracking
> > > (Thorsten
> > > Leemhuis) wrote:
> > >> On 09.10.23 10:54, Huacai Chen wrote:
> > >>> On Mon, Oct 9, 2023 at 4:45 PM Bagas Sanjaya
> > >>> wrote:
> > On Mon, Oct 09, 2023 at 09:27:02AM +0800, Huacai Chen
> > wrote:
> > > On Tue, Sep 26, 2023 at 10:31 PM Huacai Chen
> > > wrote:
> > >> On Tue, Sep 26, 2023 at 7:15 PM Linux regression
> > >> tracking (Thorsten
> > >> Leemhuis) wrote:
> > >>> On 13.09.23 14:02, Jaak Ristioja wrote:
> >
> > Upgrading to Linux 6.5 on a Lenovo ThinkPad L570
> > (Integrated Intel HD
> > Graphics 620 (rev 02), Intel(R) Core(TM) i7-7500U)
> > results in a blank
> > screen after boot until the display manager
> > starts... if it does start
> > at all. Using the nomodeset kernel parameter seems
> > to be a workaround.
> >
> > I've bisected this to commit
> > 60aebc9559492cea6a9625f514a8041717e3a2e4
> > ("drivers/firmware: Move sysfb_init() from
> > device_initcall to
> > subsys_initcall_sync").
> > >>>
> > > As confirmed by Jaak, disabling DRM_SIMPLEDRM makes
> > > things work fine
> > > again. So I guess the reason:
> > >>
> > >> Well, this to me still looks a lot (please correct me if
> > >> I'm wrong) like
> > >> regression that should be fixed, as DRM_SIMPLEDRM was
> > >> enabled beforehand
> > >> if I understood things correctly. Or is there a proper
> > >> fix for this
> > >> already in the works and I just missed this? Or is there
> > >> some good
> > >> reason why this won't/can't be fixed?
> > >
> > > DRM_SIMPLEDRM was enabled but it didn't work at all
> > > because there was
> > > no corresponding platform device. Now DRM_SIMPLEDRM works
> > > but it has a
> > > blank screen. Of course it is valuable to investigate
> > > further about
> > > DRM_SIMPLEDRM on Jaak's machine, but that needs Jaak's
> > > effort because
> > > I don't have a same machine.
> > >>>
> > >>> Side note: Huacai, have you tried working with Jaak to get
> > >>> down to the
> > >>> real problem? Evan, might you be able to help out here?
> > >> No, Jaak has no response after he 'fixed' his problem by
> > >> disabling SIMPLEDRM.
> > >>
> > >
> > >
Re: [RFC PATCH v3 09/12] net: add support for skbs with unreadable frags
On Mon, Nov 6, 2023 at 11:34 AM David Ahern wrote:
>
> On 11/6/23 11:47 AM, Stanislav Fomichev wrote:
> > On 11/05, Mina Almasry wrote:
> >> For device memory TCP, we expect the skb headers to be available in host
> >> memory for access, and we expect the skb frags to be in device memory
> >> and unaccessible to the host. We expect there to be no mixing and
> >> matching of device memory frags (unaccessible) with host memory frags
> >> (accessible) in the same skb.
> >>
> >> Add a skb->devmem flag which indicates whether the frags in this skb
> >> are device memory frags or not.
> >>
> >> __skb_fill_page_desc() now checks frags added to skbs for page_pool_iovs,
> >> and marks the skb as skb->devmem accordingly.
> >>
> >> Add checks through the network stack to avoid accessing the frags of
> >> devmem skbs and avoid coalescing devmem skbs with non devmem skbs.
> >>
> >> Signed-off-by: Willem de Bruijn
> >> Signed-off-by: Kaiyuan Zhang
> >> Signed-off-by: Mina Almasry
> >>
> >> ---
> >> include/linux/skbuff.h | 14 +++-
> >> include/net/tcp.h | 5 +--
> >> net/core/datagram.c| 6
> >> net/core/gro.c | 5 ++-
> >> net/core/skbuff.c | 77 --
> >> net/ipv4/tcp.c | 6
> >> net/ipv4/tcp_input.c | 13 +--
> >> net/ipv4/tcp_output.c | 5 ++-
> >> net/packet/af_packet.c | 4 +--
> >> 9 files changed, 115 insertions(+), 20 deletions(-)
> >>
> >> diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
> >> index 1fae276c1353..8fb468ff8115 100644
> >> --- a/include/linux/skbuff.h
> >> +++ b/include/linux/skbuff.h
> >> @@ -805,6 +805,8 @@ typedef unsigned char *sk_buff_data_t;
> >> * @csum_level: indicates the number of consecutive checksums found in
> >> * the packet minus one that have been verified as
> >> * CHECKSUM_UNNECESSARY (max 3)
> >> + * @devmem: indicates that all the fragments in this skb are backed by
> >> + * device memory.
> >> * @dst_pending_confirm: need to confirm neighbour
> >> * @decrypted: Decrypted SKB
> >> * @slow_gro: state present at GRO time, slower prepare step required
> >> @@ -991,7 +993,7 @@ struct sk_buff {
> >> #if IS_ENABLED(CONFIG_IP_SCTP)
> >> __u8csum_not_inet:1;
> >> #endif
> >> -
> >> +__u8devmem:1;
> >> #if defined(CONFIG_NET_SCHED) || defined(CONFIG_NET_XGRESS)
> >> __u16 tc_index; /* traffic control index */
> >> #endif
> >> @@ -1766,6 +1768,12 @@ static inline void
> >> skb_zcopy_downgrade_managed(struct sk_buff *skb)
> >> __skb_zcopy_downgrade_managed(skb);
> >> }
> >>
> >> +/* Return true if frags in this skb are not readable by the host. */
> >> +static inline bool skb_frags_not_readable(const struct sk_buff *skb)
> >> +{
> >> +return skb->devmem;
> >
> > bikeshedding: should we also rename 'devmem' sk_buff flag to 'not_readable'?
> > It better communicates the fact that the stack shouldn't dereference the
> > frags (because it has 'devmem' fragments or for some other potential
> > future reason).
>
> +1.
>
> Also, the flag on the skb is an optimization - a high level signal that
> one or more frags is in unreadable memory. There is no requirement that
> all of the frags are in the same memory type.
The flag indicates that the skb contains all devmem dma-buf memory
specifically, not generic 'not_readable' frags as the comment says:
+ * @devmem: indicates that all the fragments in this skb are backed by
+ * device memory.
The reason it's not a generic 'not_readable' flag is because handing
off a generic not_readable skb to the userspace is semantically not
what we're doing. recvmsg() is augmented in this patch series to
return a devmem skb to the user via a cmsg_devmem struct which refers
specifically to the memory in the dma-buf. recvmsg() in this patch
series is not augmented to give any 'not_readable' skb to the
userspace.
IMHO skb->devmem + an skb_frags_not_readable() as implemented is
correct. If a new type of unreadable skbs are introduced to the stack,
I imagine the stack would implement:
1. new header flag: skb->newmem
2.
static inline bool skb_frags_not_readable(const struct skb_buff *skb)
{
return skb->devmem || skb->newmem;
}
3. tcp_recvmsg_devmem() would handle skb->devmem skbs is in this patch
series, but tcp_recvmsg_newmem() would handle skb->newmem skbs.
--
Thanks,
Mina
[PATCH v3 3/3] drm/panel-edp: Avoid adding multiple preferred modes
If a non generic edp-panel is under aux-bus, the mode read from edid would
still be selected as preferred and results in multiple preferred modes,
which is ambiguous.
If both hard-coded mode and edid exists, only add mode from hard-coded.
Signed-off-by: Hsin-Yi Wang
---
v2->v3: if hard-coded mode presents, don't add edid mode.
---
drivers/gpu/drm/panel/panel-edp.c | 25 +++--
1 file changed, 15 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-edp.c
b/drivers/gpu/drm/panel/panel-edp.c
index 0fb439b5efb1..54dbbdf62ec0 100644
--- a/drivers/gpu/drm/panel/panel-edp.c
+++ b/drivers/gpu/drm/panel/panel-edp.c
@@ -594,8 +594,20 @@ static int panel_edp_get_modes(struct drm_panel *panel,
p->detected_panel != ERR_PTR(-EINVAL) &&
p->detected_panel->override_edid_mode;
- /* probe EDID if a DDC bus is available */
- if (p->ddc) {
+ /*
+* If both edid and hard-coded modes exists, only add hard-coded modes
+* to avoid multiple preferred modes.
+*/
+ if (p->desc->num_timings || p->desc->num_modes) {
+ /*
+* Add hard-coded panel modes. Don't call this if there are no
+* timings and no modes (the generic edp-panel case) because it
+* will clobber the display_info that was already set by
+* drm_add_edid_modes().
+*/
+ num += panel_edp_get_non_edid_modes(p, connector);
+ } else if (p->ddc) {
+ /* probe EDID if a DDC bus is available */
pm_runtime_get_sync(panel->dev);
if (!p->edid)
@@ -617,14 +629,7 @@ static int panel_edp_get_modes(struct drm_panel *panel,
pm_runtime_put_autosuspend(panel->dev);
}
- /*
-* Add hard-coded panel modes. Don't call this if there are no timings
-* and no modes (the generic edp-panel case) because it will clobber
-* the display_info that was already set by drm_add_edid_modes().
-*/
- if (p->desc->num_timings || p->desc->num_modes)
- num += panel_edp_get_non_edid_modes(p, connector);
- else if (!num)
+ if (!num)
dev_warn(p->base.dev, "No display modes\n");
/*
--
2.42.0.869.gea05f2083d-goog
[PATCH v3 2/3] drm/panel-edp: Add override_edid_mode quirk for generic edp
Generic edp gets mode from edid. However, some panels report incorrect
mode in this way, resulting in glitches on panel. Introduce a new quirk
additional_mode to the generic edid to pick a correct hardcoded mode.
Signed-off-by: Hsin-Yi Wang
Reviewed-by: Douglas Anderson
---
v2->v3: no change.
---
drivers/gpu/drm/panel/panel-edp.c | 68 ---
1 file changed, 63 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-edp.c
b/drivers/gpu/drm/panel/panel-edp.c
index 599a949d74d1..0fb439b5efb1 100644
--- a/drivers/gpu/drm/panel/panel-edp.c
+++ b/drivers/gpu/drm/panel/panel-edp.c
@@ -203,6 +203,9 @@ struct edp_panel_entry {
/** @name: Name of this panel (for printing to logs). */
const char *name;
+
+ /** @override_edid_mode: Override the mode obtained by edid. */
+ const struct drm_display_mode *override_edid_mode;
};
struct panel_edp {
@@ -301,6 +304,25 @@ static unsigned int panel_edp_get_display_modes(struct
panel_edp *panel,
return num;
}
+static int panel_edp_override_edid_mode(struct panel_edp *panel,
+ struct drm_connector *connector,
+ const struct drm_display_mode
*override_mode)
+{
+ struct drm_display_mode *mode;
+
+ mode = drm_mode_duplicate(connector->dev, override_mode);
+ if (mode) {
+ mode->type |= DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED;
+ drm_mode_set_name(mode);
+ drm_mode_probed_add(connector, mode);
+ return 1;
+ }
+
+ dev_err(panel->base.dev, "failed to add additional mode\n");
+
+ return 0;
+}
+
static int panel_edp_get_non_edid_modes(struct panel_edp *panel,
struct drm_connector *connector)
{
@@ -568,6 +590,9 @@ static int panel_edp_get_modes(struct drm_panel *panel,
{
struct panel_edp *p = to_panel_edp(panel);
int num = 0;
+ bool has_override_edid_mode = p->detected_panel &&
+ p->detected_panel != ERR_PTR(-EINVAL) &&
+ p->detected_panel->override_edid_mode;
/* probe EDID if a DDC bus is available */
if (p->ddc) {
@@ -575,9 +600,18 @@ static int panel_edp_get_modes(struct drm_panel *panel,
if (!p->edid)
p->edid = drm_get_edid(connector, p->ddc);
-
- if (p->edid)
- num += drm_add_edid_modes(connector, p->edid);
+ if (p->edid) {
+ if (has_override_edid_mode) {
+ /*
+* override_edid_mode is specified. Use
+* override_edid_mode instead of from edid.
+*/
+ num += panel_edp_override_edid_mode(p,
connector,
+
p->detected_panel->override_edid_mode);
+ } else {
+ num += drm_add_edid_modes(connector, p->edid);
+ }
+ }
pm_runtime_mark_last_busy(panel->dev);
pm_runtime_put_autosuspend(panel->dev);
@@ -950,6 +984,19 @@ static const struct panel_desc auo_b101ean01 = {
},
};
+static const struct drm_display_mode auo_b116xa3_mode = {
+ .clock = 70589,
+ .hdisplay = 1366,
+ .hsync_start = 1366 + 40,
+ .hsync_end = 1366 + 40 + 40,
+ .htotal = 1366 + 40 + 40 + 32,
+ .vdisplay = 768,
+ .vsync_start = 768 + 10,
+ .vsync_end = 768 + 10 + 12,
+ .vtotal = 768 + 10 + 12 + 6,
+ .flags = DRM_MODE_FLAG_NVSYNC | DRM_MODE_FLAG_NHSYNC,
+};
+
static const struct drm_display_mode auo_b116xak01_mode = {
.clock = 69300,
.hdisplay = 1366,
@@ -1878,6 +1925,15 @@ static const struct panel_delay delay_200_150_e200 = {
.delay = _delay \
}
+#define EDP_PANEL_ENTRY2(vend_chr_0, vend_chr_1, vend_chr_2, product_id,
_delay, _name, _mode) \
+{ \
+ .name = _name, \
+ .panel_id = drm_edid_encode_panel_id(vend_chr_0, vend_chr_1,
vend_chr_2, \
+product_id), \
+ .delay = _delay, \
+ .override_edid_mode = _mode \
+}
+
/*
* This table is used to figure out power sequencing delays for panels that
* are detected by EDID. Entries here may point to entries in the
@@ -1895,9 +1951,11 @@ static const struct edp_panel_entry edp_panels[] = {
EDP_PANEL_ENTRY('A', 'U', 'O', 0x239b, _200_500_e50,
"B116XAN06.1"),
EDP_PANEL_ENTRY('A', 'U', 'O', 0x255c, _200_500_e50,
"B116XTN02.5"),
EDP_PANEL_ENTRY('A', 'U', 'O', 0x403d, _200_500_e50,
"B140HAN04.0"),
- EDP_PANEL_ENTRY('A', 'U', 'O', 0x405c, _b116xak01.delay,
"B116XAK01.0"),
+ EDP_PANEL_ENTRY2('A', 'U', 'O', 0x405c, _b116xak01.delay,
[PATCH v3 1/3] drm/panel-edp: drm/panel-edp: Add several generic edp panels
Add a few generic edp panels used by mt8186 chromebooks.
Besides, modify the following panel:
- AUO 0x235c B116XTN02 renamed to B116XTN02.3.
- AUO 0x405c B116XAK01 adjust the timing of auo_b116xak01. According
to the datasheet: T3=200, T12=500, T7_max = 50.
Signed-off-by: Hsin-Yi Wang
Reviewed-by: Douglas Anderson
---
v2->v3: fix title
---
drivers/gpu/drm/panel/panel-edp.c | 57 +--
1 file changed, 55 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-edp.c
b/drivers/gpu/drm/panel/panel-edp.c
index 9dce4c702414..599a949d74d1 100644
--- a/drivers/gpu/drm/panel/panel-edp.c
+++ b/drivers/gpu/drm/panel/panel-edp.c
@@ -973,6 +973,8 @@ static const struct panel_desc auo_b116xak01 = {
},
.delay = {
.hpd_absent = 200,
+ .unprepare = 500,
+ .enable = 50,
},
};
@@ -1830,6 +1832,12 @@ static const struct panel_delay delay_200_500_e50 = {
.enable = 50,
};
+static const struct panel_delay delay_200_500_e80 = {
+ .hpd_absent = 200,
+ .unprepare = 500,
+ .enable = 80,
+};
+
static const struct panel_delay delay_200_500_e80_d50 = {
.hpd_absent = 200,
.unprepare = 500,
@@ -1849,6 +1857,19 @@ static const struct panel_delay delay_200_500_e200 = {
.enable = 200,
};
+static const struct panel_delay delay_200_500_e200_d10 = {
+ .hpd_absent = 200,
+ .unprepare = 500,
+ .enable = 200,
+ .disable = 10,
+};
+
+static const struct panel_delay delay_200_150_e200 = {
+ .hpd_absent = 200,
+ .unprepare = 150,
+ .enable = 200,
+};
+
#define EDP_PANEL_ENTRY(vend_chr_0, vend_chr_1, vend_chr_2, product_id,
_delay, _name) \
{ \
.name = _name, \
@@ -1869,37 +1890,69 @@ static const struct edp_panel_entry edp_panels[] = {
EDP_PANEL_ENTRY('A', 'U', 'O', 0x145c, _200_500_e50,
"B116XAB01.4"),
EDP_PANEL_ENTRY('A', 'U', 'O', 0x1e9b, _200_500_e50,
"B133UAN02.1"),
EDP_PANEL_ENTRY('A', 'U', 'O', 0x1ea5, _200_500_e50,
"B116XAK01.6"),
- EDP_PANEL_ENTRY('A', 'U', 'O', 0x235c, _200_500_e50, "B116XTN02"),
- EDP_PANEL_ENTRY('A', 'U', 'O', 0x405c, _b116xak01.delay,
"B116XAK01"),
+ EDP_PANEL_ENTRY('A', 'U', 'O', 0x208d, _200_500_e50,
"B140HTN02.1"),
+ EDP_PANEL_ENTRY('A', 'U', 'O', 0x235c, _200_500_e50,
"B116XTN02.3"),
+ EDP_PANEL_ENTRY('A', 'U', 'O', 0x239b, _200_500_e50,
"B116XAN06.1"),
+ EDP_PANEL_ENTRY('A', 'U', 'O', 0x255c, _200_500_e50,
"B116XTN02.5"),
+ EDP_PANEL_ENTRY('A', 'U', 'O', 0x403d, _200_500_e50,
"B140HAN04.0"),
+ EDP_PANEL_ENTRY('A', 'U', 'O', 0x405c, _b116xak01.delay,
"B116XAK01.0"),
EDP_PANEL_ENTRY('A', 'U', 'O', 0x582d, _200_500_e50,
"B133UAN01.0"),
EDP_PANEL_ENTRY('A', 'U', 'O', 0x615c, _200_500_e50,
"B116XAN06.1"),
+ EDP_PANEL_ENTRY('A', 'U', 'O', 0x635c, _200_500_e50,
"B116XAN06.3"),
+ EDP_PANEL_ENTRY('A', 'U', 'O', 0x639c, _200_500_e50,
"B140HAK02.7"),
EDP_PANEL_ENTRY('A', 'U', 'O', 0x8594, _200_500_e50,
"B133UAN01.0"),
+ EDP_PANEL_ENTRY('A', 'U', 'O', 0xf390, _200_500_e50,
"B140XTN07.7"),
+ EDP_PANEL_ENTRY('B', 'O', 'E', 0x0715, _200_150_e200,
"NT116WHM-N21"),
+ EDP_PANEL_ENTRY('B', 'O', 'E', 0x0731, _200_500_e80,
"NT116WHM-N42"),
+ EDP_PANEL_ENTRY('B', 'O', 'E', 0x0741, _200_500_e200,
"NT116WHM-N44"),
EDP_PANEL_ENTRY('B', 'O', 'E', 0x0786, _200_500_p2e80,
"NV116WHM-T01"),
EDP_PANEL_ENTRY('B', 'O', 'E', 0x07d1, _nv133fhm_n61.delay,
"NV133FHM-N61"),
+ EDP_PANEL_ENTRY('B', 'O', 'E', 0x07f6, _200_500_e200,
"NT140FHM-N44"),
EDP_PANEL_ENTRY('B', 'O', 'E', 0x082d, _nv133fhm_n61.delay,
"NV133FHM-N62"),
+ EDP_PANEL_ENTRY('B', 'O', 'E', 0x08b2, _200_500_e200,
"NT140WHM-N49"),
EDP_PANEL_ENTRY('B', 'O', 'E', 0x09c3, _200_500_e50,
"NT116WHM-N21,836X2"),
EDP_PANEL_ENTRY('B', 'O', 'E', 0x094b, _200_500_e50,
"NT116WHM-N21"),
+ EDP_PANEL_ENTRY('B', 'O', 'E', 0x0951, _200_500_e80,
"NV116WHM-N47"),
EDP_PANEL_ENTRY('B', 'O', 'E', 0x095f, _200_500_e50,
"NE135FBM-N41 v8.1"),
EDP_PANEL_ENTRY('B', 'O', 'E', 0x0979, _200_500_e50,
"NV116WHM-N49 V8.0"),
EDP_PANEL_ENTRY('B', 'O', 'E', 0x098d, _nv110wtm_n61.delay,
"NV110WTM-N61"),
+ EDP_PANEL_ENTRY('B', 'O', 'E', 0x09ae, _200_500_e200,
"NT140FHM-N45"),
EDP_PANEL_ENTRY('B', 'O', 'E', 0x09dd, _200_500_e50,
"NT116WHM-N21"),
EDP_PANEL_ENTRY('B', 'O', 'E', 0x0a5d, _200_500_e50,
"NV116WHM-N45"),
EDP_PANEL_ENTRY('B', 'O', 'E', 0x0ac5, _200_500_e50,
"NV116WHM-N4C"),
+ EDP_PANEL_ENTRY('B', 'O', 'E', 0x0b43, _200_500_e200,
"NV140FHM-T09"),
+ EDP_PANEL_ENTRY('B', 'O', 'E', 0x0b56, _200_500_e80,
"NT140FHM-N47"),
+ EDP_PANEL_ENTRY('B', 'O', 'E', 0x0c20, _200_500_e80,
"NT140FHM-N47"),
+ EDP_PANEL_ENTRY('C', 'M', 'N', 0x1132, _200_500_e80_d50,
"N116BGE-EA2"),
+ EDP_PANEL_ENTRY('C',
[PATCH v3 0/3] Add a few panels and use correct modes
This series contains 3 patches: 1. Add a few new generic edp panels. 2. Support a new quirk to override the mode read from edid 3. Only add hard-coded mode if both edid and hard-coded modes presents. v1: https://patchwork.kernel.org/project/dri-devel/cover/20231101212604.1636517-1-hsi...@chromium.org/ v2: https://patchwork.kernel.org/project/dri-devel/cover/20231102221309.1971910-1-hsi...@chromium.org/ Hsin-Yi Wang (3): drm/panel-edp: drm/panel-edp: Add several generic edp panels drm/panel-edp: Add override_edid_mode quirk for generic edp drm/panel-edp: Avoid adding multiple preferred modes drivers/gpu/drm/panel/panel-edp.c | 148 ++ 1 file changed, 132 insertions(+), 16 deletions(-) -- 2.42.0.869.gea05f2083d-goog
[PATCH v2] drm: amd: Resolve Sphinx unexpected indentation warning
Resolves Sphinx unexpected indentation warning when compiling documentation (e.g. `make htmldocs`). Replaces tabs with spaces and adds a literal block to keep vertical formatting of the example power state list. Signed-off-by: Hunter Chasens --- drivers/gpu/drm/amd/pm/amdgpu_pm.c | 13 +++-- 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/amd/pm/amdgpu_pm.c b/drivers/gpu/drm/amd/pm/amdgpu_pm.c index 517b9fb4624c..81b8ceb26890 100644 --- a/drivers/gpu/drm/amd/pm/amdgpu_pm.c +++ b/drivers/gpu/drm/amd/pm/amdgpu_pm.c @@ -989,12 +989,13 @@ static ssize_t amdgpu_get_pp_features(struct device *dev, * Reading back the files will show you the available power levels within * the power state and the clock information for those levels. If deep sleep is * applied to a clock, the level will be denoted by a special level 'S:' - * E.g., - * S: 19Mhz * - * 0: 615Mhz - * 1: 800Mhz - * 2: 888Mhz - * 3: 1000Mhz + * E.g.:: + * + * S: 19Mhz * + * 0: 615Mhz + * 1: 800Mhz + * 2: 888Mhz + * 3: 1000Mhz * * * To manually adjust these states, first select manual using -- 2.39.3
Re: [PATCH v1] drm: amd: Resolve Sphinx unexpected indentation warning
On 11/6/23 11:06, Hunter Chasens wrote: > First, apologies to Jani Nikula. I accedently top posted on the other thread. > My email client is giving me a hard time. The following works and, if > everyone agrees, I'll send out a v2. > > * E.g.:: > * > * S: 19Mhz * > * 0: 615Mhz > * 1: 800Mhz > * 2: 888Mhz > * 3: 1000Mhz Please do. Thanks. -- ~Randy
Re: [PATCH v1] docs: gpu: rfc: i915_scheduler.rst remove unused directives for namespacing
Jani Nikula writes:
> Looks like this is because namespacing was introduced in Sphinx 3.1
> [1]. With earlier Sphinx, you get a warning about the namespace
> directives.
>
> However, with newer Sphinx, you get the warning mentioned in commit
> f6757dfcfde7 ("drm/doc: fix duplicate declaration warning") if you
> remove the namespace directives:
>
> linux/Documentation/gpu/driver-uapi.rst:2279: WARNING: Duplicate C
> declaration, also defined at rfc/i915_scheduler:3.
> Declaration is '.. c:struct:: i915_context_engines_parallel_submit'.
>
> It would be short-sighted to just remove the directives. Sooner or later
> we're gong to bump the (IMO extremely conservative) minimum version
> requirement.
I'd say let's just do that once the merge window is done. A year ago
(in 31abfdda6527) I added a warning for <2.4.x, so raising the minimum
that far would appear to require no thought. Going up to 3.1 is a step
beyond that, though, not sure if we want to go that far.
Something to ask at the LPC session next week.
Thanks,
jon
Re: [PATCH] drm/bridge: tc358767: Support input format negotiation hook
Hi Sam,
Thank you for the suggestion!
On 06-Nov-23 18:08, Sam Ravnborg wrote:
> Hi Aradhya,
>
> On Tue, Oct 31, 2023 at 12:58:46AM +0530, Aradhya Bhatia wrote:
>> With new connector model, tc358767 will not create the connector, when
>> DRM_BRIDGE_ATTACH_NO_CONNECTOR is set and display-controller driver will
>> rely on format negotiation to setup the encoder format.
>>
>> Add the missing input-format negotiation hook in the
>> drm_bridge_funcs to complete DRM_BRIDGE_ATTACH_NO_CONNECTOR support.
>>
>> Input format is selected to MEDIA_BUS_FMT_RGB888_1X24 as default, as is
>> the case with older model.
>>
>> Reported-by: Jan Kiszka
>> Signed-off-by: Aradhya Bhatia
>> ---
>>
>> Notes:
>>
>> * Since I do not have hardware with me, this was just build tested. I would
>> appreciate it if someone could test and review it, especically somebody,
>> who
>> uses the bridge for DPI/DSI to eDP format conversion.
>>
>> * The Toshiba TC358767 bridge is not enabled in arm64 defconfig by default,
>> when it should be. Hence, I sent a quick patch[0] earlier.
>>
>> [0]: https://lore.kernel.org/all/20231030152834.18450-1-a-bhat...@ti.com/
>>
>> drivers/gpu/drm/bridge/tc358767.c | 25 +
>> 1 file changed, 25 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/bridge/tc358767.c
>> b/drivers/gpu/drm/bridge/tc358767.c
>> index ef2e373606ba..0affcefdeb1c 100644
>> --- a/drivers/gpu/drm/bridge/tc358767.c
>> +++ b/drivers/gpu/drm/bridge/tc358767.c
>> @@ -1751,6 +1751,30 @@ tc_dpi_atomic_get_input_bus_fmts(struct drm_bridge
>> *bridge,
>> return input_fmts;
>> }
>>
>> +static u32 *
>> +tc_edp_atomic_get_input_bus_fmts(struct drm_bridge *bridge,
>> + struct drm_bridge_state *bridge_state,
>> + struct drm_crtc_state *crtc_state,
>> + struct drm_connector_state *conn_state,
>> + u32 output_fmt,
>> + unsigned int *num_input_fmts)
>> +{
>> +u32 *input_fmts;
>> +
>> +*num_input_fmts = 0;
>> +
>> +input_fmts = kcalloc(MAX_INPUT_SEL_FORMATS, sizeof(*input_fmts),
>> + GFP_KERNEL);
>> +if (!input_fmts)
>> +return NULL;
>> +
>> +/* This is the DSI/DPI-end bus format */
>> +input_fmts[0] = MEDIA_BUS_FMT_RGB888_1X24;
>> +*num_input_fmts = 1;
>> +
>> +return input_fmts;
>> +}
>
> You could benefit from using the helper:
> drm_atomic_helper_bridge_propagate_bus_fmt()
You are right!
Upon taking a second look, I realize that the bridge chain works with
MEDIA_BUS_FMT_FIXED bus format, when tc358767 is being used in DPI/DSI
to eDP mode (because the panel-bridge does not have a get_output_bus_fmt
hook, and uses the same helper for its get_input_bus_fmt hook). My patch
creates a deviation from that, by forcing MEDIA_BUS_FMT_RGB888_1X24 even
when eDP is involved.
Using the helper here, will certainly address this deviation.
However, for the DPI/DSI to DP mode, MEDIA_BUS_FMT_RGB888_1X24 bus
format is required, and *just* using the helper as its get_input_bus_fmt
hook, might not be enough.
Since tc358767 is the last bridge in DPI/DSI to DP mode, the
output_fmt parameter get defaulted to MEDIA_BUS_FMT_FIXED too, as there
is no get_output_bus_fmt hook present in the driver. If we simply us
the helper here, the input_fmt will also get set to MEDIA_BUS_FMT_FIXED.
This too is an unwanted deviation.
It seems like the right way to address both the cases, would be by
adding the get_output_bus_fmt hook that sets output_fmt to
MEDIA_BUS_FMT_RGB888_1X24, as well as using the helper as the
get_input_bus_fmt hook.
If this seems good to you too, I will send a new version of Tomi's
series[0] which incorporates this patch.
Regards
Aradhya
[0]:
https://lore.kernel.org/all/20231031-tc358767-v1-0-392081ad9...@ideasonboard.com/
Re: [PATCH v1] docs: gpu: rfc: i915_scheduler.rst remove unused directives for namespacing
On Mon, 06 Nov 2023, Hunter Chasens wrote:
> When running `make htmldocs` the following warnings are given.
>
> ```
> Documentation/gpu/rfc/i915_scheduler.rst:138: WARNING:
> Unknown directive type "c:namespace-push".
>
> .. c:namespace-push:: rfc
> Documentation/gpu/rfc/i915_scheduler.rst:143: WARNING:
> Unknown directive type "c:namespace-pop".
>
> .. c:namespace-pop::
> ```
>
> The kernel test robot also reported it here.
> Link: https://lore.kernel.org/all/202311061623.86ptqrie-...@intel.com/
>
> Last year Maryam Tahhan from Redhat noticed something
> similar. "The missing support of c:namespace-push:: and c:namespace-pop::
> directives by helper scripts for kernel documentation prevents using the
> ``c:function::`` directive with proper namespacing." From the context, it
> sounds like this was brought about from a Sphinx update.
>
> Link: https://lore.kernel.org/all/20221123092321.88558-3-mtah...@redhat.com/
>
> When compiled the `.. kernel-doc::` literal gives it the same formatting with
> or without the namespace directives present. Due to the above information I
> think it safe to remove these, as they don't seem to do anything but
> throw warnings.
Not so fast!
Looks like this is because namespacing was introduced in Sphinx 3.1
[1]. With earlier Sphinx, you get a warning about the namespace
directives.
However, with newer Sphinx, you get the warning mentioned in commit
f6757dfcfde7 ("drm/doc: fix duplicate declaration warning") if you
remove the namespace directives:
linux/Documentation/gpu/driver-uapi.rst:2279: WARNING: Duplicate C declaration,
also defined at rfc/i915_scheduler:3.
Declaration is '.. c:struct:: i915_context_engines_parallel_submit'.
It would be short-sighted to just remove the directives. Sooner or later
we're gong to bump the (IMO extremely conservative) minimum version
requirement.
BR,
Jani.
[1] https://www.sphinx-doc.org/en/master/usage/domains/c.html#namespacing
>
> On Mon, Nov 6, 2023 at 5:31 AM Jani Nikula wrote:
>>
>> On Mon, 06 Nov 2023, Bagas Sanjaya wrote:
>> > On Sat, Nov 04, 2023 at 09:47:08AM -0400, Hunter Chasens wrote:
>> >> diff --git a/Documentation/gpu/rfc/i915_scheduler.rst
>> >> b/Documentation/gpu/rfc/i915_scheduler.rst
>> >> index c237ebc024cd..23ba7006929b 100644
>> >> --- a/Documentation/gpu/rfc/i915_scheduler.rst
>> >> +++ b/Documentation/gpu/rfc/i915_scheduler.rst
>> >> @@ -135,13 +135,9 @@ Add I915_CONTEXT_ENGINES_EXT_PARALLEL_SUBMIT and
>> >> drm_i915_context_engines_parallel_submit to the uAPI to implement this
>> >> extension.
>> >>
>> >> -.. c:namespace-push:: rfc
>> >> -
>> >> .. kernel-doc:: include/uapi/drm/i915_drm.h
>> >> :functions: i915_context_engines_parallel_submit
>> >>
>> >> -.. c:namespace-pop::
>> >> -
>>
>> What makes the namespacing unnecessary?
>>
>> $ git grep '.. kernel-doc:: include/uapi/drm/i915_drm.h'
>> Documentation/gpu/driver-uapi.rst:.. kernel-doc:: include/uapi/drm/i915_drm.h
>> Documentation/gpu/rfc/i915_scheduler.rst:.. kernel-doc::
>> include/uapi/drm/i915_drm.h
>>
>> And you get [1] and [2].
>>
>> >> Extend execbuf2 IOCTL to support submitting N BBs in a single IOCTL
>> >> ---
>> >> Contexts that have been configured with the 'set_parallel' extension can
>> >> only
>> >
>> > The warnings go away, thanks!
>>
>> What warnings go away?
>>
>> BR,
>> Jani.
>>
>>
>> [1]
>> https://docs.kernel.org/gpu/driver-uapi.html#c.i915_context_engines_parallel_submit
>> [2]
>> https://docs.kernel.org/gpu/rfc/i915_scheduler.html#c.rfc.i915_context_engines_parallel_submit
>>
>> >
>> > Fixes: f6757dfcfde7 ("drm/doc: fix duplicate declaration warning")
>> > Reviewed-by: Bagas Sanjaya
>>
>> --
>> Jani Nikula, Intel
--
Jani Nikula, Intel
Re: [PATCH 3/3] drm/panel-edp: Choose correct preferred mode
On Mon, Nov 6, 2023 at 8:21 AM Doug Anderson wrote:
>
> Hi,
>
> On Mon, Nov 6, 2023 at 12:06 AM Maxime Ripard wrote:
> >
> > On Thu, Nov 02, 2023 at 07:33:48AM -0700, Doug Anderson wrote:
> > > Hi,
> > >
> > > On Wed, Nov 1, 2023 at 11:31 PM Dmitry Baryshkov
> > > wrote:
> > > >
> > > > On Wed, 1 Nov 2023 at 23:26, Hsin-Yi Wang wrote:
> > > > >
> > > > > If a non generic edp-panel is under aux-bus, the mode read from edid
> > > > > would
> > > > > still be selected as preferred and results in multiple preferred
> > > > > modes,
> > > > > which is ambiguous.
> > > > >
> > > > > If a hard-coded mode is present, unset the preferred bit of the modes
> > > > > read
> > > > > from edid.
> > > >
> > > > Can we skip the EDID completely if the hardcoded override is present?
> > >
> > > Yeah, I wondered about that too. The blending of the hardcoded with
> > > the EDID predates my involvement with the driver. You can see even as
> > > of commit 280921de7241 ("drm/panel: Add simple panel support") that
> > > the driver would start with the EDID modes (if it had them) and then
> > > go onto add the hardcoded modes. At least for eDP panels, though,
> > > nobody (or almost nobody?) actually provided panel-simple a DDC bus at
> > > the same time it was given a hardcoded panel.
> > >
> > > I guess I could go either way, but I have a slight bias to adding the
> > > extra modes and just making it clear to userspace that none of them
> > > are "preferred". That seems like it would give userspace the most
> > > flexibility
> >
> > I disagree. "Flexibility" here just means "the way to shoot itself in
> > the foot without knowing it's aiming at its foot".
> >
> > If a mode is broken, we shouldn't expose it, just like we don't for all
> > modes that require a maximum frequency higher than what the controller
> > can provide on HDMI for example.
>
> In this particular case we aren't saying that modes are broken. There
> are two (somewhat separate) things in Hsin-Yi's series.
>
> The first thing is a quirk for panels with incorrect modes in their
> EDID when using the generic "edp-panel" compatible. In that case we
> now _replace_ the broken mode with a more correct one because, as you
> say, we shouldn't be telling userspace about a broken mode.
>
> The second thing in Hsin-Yi's series is for when we're _not_ using the
> generic "edp-panel". In that case we have a hardcoded mode from the
> "compatible" string but we also have modes from the EDID and that's
> what ${SUBJECT} patch is about. Here we don't truly know that the
> modes in the EDID are broken.
>
>
> > > and also is closer to what we've historically done (though,
> > > historically, we just allowed there to be more than one "preferred"
> > > mode).
> >
> > I have no idea what history you're referring to here
>
> History = historical behavior? As above, I pointed out that the kernel
> has been merging the hardcoded and EDID modes as far back as commit
> 280921de7241 ("drm/panel: Add simple panel support") in 2013.
>
> That being said, the historical behavior has more than one mode marked
> preferred which is bad, so we're changing the behavior anyway. I'm not
> against changing it to just have the hardcoded mode if that's what
> everyone else wants (and it sounds like it is).
I'll change the behavior to: if hard-coded mode presents, don't add
edid mode since it will result in multiple preferred modes.
Re: [RFC PATCH v3 09/12] net: add support for skbs with unreadable frags
On 11/6/23 11:47 AM, Stanislav Fomichev wrote:
> On 11/05, Mina Almasry wrote:
>> For device memory TCP, we expect the skb headers to be available in host
>> memory for access, and we expect the skb frags to be in device memory
>> and unaccessible to the host. We expect there to be no mixing and
>> matching of device memory frags (unaccessible) with host memory frags
>> (accessible) in the same skb.
>>
>> Add a skb->devmem flag which indicates whether the frags in this skb
>> are device memory frags or not.
>>
>> __skb_fill_page_desc() now checks frags added to skbs for page_pool_iovs,
>> and marks the skb as skb->devmem accordingly.
>>
>> Add checks through the network stack to avoid accessing the frags of
>> devmem skbs and avoid coalescing devmem skbs with non devmem skbs.
>>
>> Signed-off-by: Willem de Bruijn
>> Signed-off-by: Kaiyuan Zhang
>> Signed-off-by: Mina Almasry
>>
>> ---
>> include/linux/skbuff.h | 14 +++-
>> include/net/tcp.h | 5 +--
>> net/core/datagram.c| 6
>> net/core/gro.c | 5 ++-
>> net/core/skbuff.c | 77 --
>> net/ipv4/tcp.c | 6
>> net/ipv4/tcp_input.c | 13 +--
>> net/ipv4/tcp_output.c | 5 ++-
>> net/packet/af_packet.c | 4 +--
>> 9 files changed, 115 insertions(+), 20 deletions(-)
>>
>> diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
>> index 1fae276c1353..8fb468ff8115 100644
>> --- a/include/linux/skbuff.h
>> +++ b/include/linux/skbuff.h
>> @@ -805,6 +805,8 @@ typedef unsigned char *sk_buff_data_t;
>> * @csum_level: indicates the number of consecutive checksums found in
>> * the packet minus one that have been verified as
>> * CHECKSUM_UNNECESSARY (max 3)
>> + * @devmem: indicates that all the fragments in this skb are backed by
>> + * device memory.
>> * @dst_pending_confirm: need to confirm neighbour
>> * @decrypted: Decrypted SKB
>> * @slow_gro: state present at GRO time, slower prepare step required
>> @@ -991,7 +993,7 @@ struct sk_buff {
>> #if IS_ENABLED(CONFIG_IP_SCTP)
>> __u8csum_not_inet:1;
>> #endif
>> -
>> +__u8devmem:1;
>> #if defined(CONFIG_NET_SCHED) || defined(CONFIG_NET_XGRESS)
>> __u16 tc_index; /* traffic control index */
>> #endif
>> @@ -1766,6 +1768,12 @@ static inline void skb_zcopy_downgrade_managed(struct
>> sk_buff *skb)
>> __skb_zcopy_downgrade_managed(skb);
>> }
>>
>> +/* Return true if frags in this skb are not readable by the host. */
>> +static inline bool skb_frags_not_readable(const struct sk_buff *skb)
>> +{
>> +return skb->devmem;
>
> bikeshedding: should we also rename 'devmem' sk_buff flag to 'not_readable'?
> It better communicates the fact that the stack shouldn't dereference the
> frags (because it has 'devmem' fragments or for some other potential
> future reason).
+1.
Also, the flag on the skb is an optimization - a high level signal that
one or more frags is in unreadable memory. There is no requirement that
all of the frags are in the same memory type.
Re: [PATCH v4 00/32] drm/amd/display: add AMD driver-specific properties for color mgmt
On 10/06, Sebastian Wick wrote: > On Thu, Oct 05, 2023 at 04:14:55PM -0100, Melissa Wen wrote: > > Hello, > > > > Just another iteration for AMD driver-specific color properties. > > Basically, addressing comments from the previous version. > > > > Recap: this series extends the current KMS color management API with AMD > > driver-specific properties to enhance the color management support on > > AMD Steam Deck. The key additions to the color pipeline include: > > Did you talk with the maintainers about this already? The last few times > driver specific properties, and even kind of generic plane properties > with a fixed position in the pipeline were proposed they were all > NAKed. Just putting them behind a define doesn't sound great and I don't > think there is any precedence for allowing this in. This is basically > just more burden for upstream without any benefits for upstream. Hi Sebastian, Sorry for delaying. I believe it was already answered during the XDC KMS color workshop, but: yes, I've talked with them and they are fine with the cflags approach. Remember that we are not using here kconfig anymore. The driver-specific properties (creation and attachment) are guarded by cflags, not a kernel building option. We changed to cflags after Harry's suggestion in the first version. I think the main point for upstream it now is that we can actually exercise the plane color properties and all machinery around new color elements (as 3D LUT) with a userspace that cares about it (Gamescope). Worth mentioning that I removed CRTC shaper/3D LUT support from previous version, because, even with the internal implementation, we don't have how to exercise these CRTC properties right now. Finally, the main goal is ofc attaching it to the generic API from Harry's series. We are all in the same page about it. BR, Melissa > > Maybe you can separate the uAPI changes from the internal improvements > to land at least parts of this faster. > > > - plane degamma LUT and pre-defined TF; > > - plane HDR multiplier; > > - plane CTM 3x4; > > - plane shaper LUT and pre-defined TF; > > - plane 3D LUT; > > - plane blend LUT and pre-defined TF; > > - CRTC gamma pre-defined TF; > > > > You can find the AMD HW color capabilities documented here: > > https://dri.freedesktop.org/docs/drm/gpu/amdgpu/display/display-manager.html#color-management-properties > > > > The userspace case is Gamescope[1], the compositor for SteamOS. > > Gamescope has already adopted AMD driver-specific properties to > > implement comprehensive color management support, including gamut > > mapping, HDR rendering, SDR on HDR, HDR on SDR. Using these features in > > the SteamOS 3.5[2] users can expect a significantly enhanced visual > > experience. > > > > You can find a brief overview of the Steam Deck color pipeline here: > > https://github.com/ValveSoftware/gamescope/blob/master/src/docs/Steam%20Deck%20Display%20Pipeline.png > > > > Changes from: > > > > [RFC] > > https://lore.kernel.org/dri-devel/20230423141051.702990-1-m...@igalia.com > > - Remove KConfig and guard properties with `AMD_PRIVATE_COLOR`; > > - Remove properties for post-blending/CRTC shaper TF+LUT and 3D LUT; > > - Use color caps to improve the support of pre-defined curve; > > > > [v1] > > https://lore.kernel.org/dri-devel/20230523221520.3115570-1-m...@igalia.com > > - Replace DRM_ by AMDGPU_ prefix for transfer function (TF) enum; > > - Explicitly define EOTFs and inverse EOTFs and set props accordingly; > > - Document pre-defined transfer functions; > > - Remove HLG transfer function from supported TFs; > > - Remove misleading comments; > > - Remove post-blending shaper TF+LUT and 3D LUT support; > > - Move driver-specific property operations from amdgpu_display.c to > > amdgpu_dm_color.c; > > - Reset planes if any color props change; > > - Add plane CTM 3x4 support; > > - Removed two DC fixes already applied upstream; > > > > [v2] > > https://lore.kernel.org/dri-devel/20230810160314.48225-1-m...@igalia.com > > - Many documentation fixes: BT.709 OETF, description of sRGB and pure > > power functions, TF+1D LUT behavior; > > - Rename CTM2 to CTM 3x4 and fix misleading comment about DC gamut remap; > > - Squash `Linear` and `Unity` TF in `Identity`; > > - Remove the `MPC gamut remap` patch already applied upstream[3]; > > - Remove outdated delta segmentation fix; > > - Nits/small fixes; > > > > [v3] > > https://lore.kernel.org/amd-gfx/20230925194932.1329483-1-m...@igalia.com > > - Add table to describe value range in linear and non-linear forms > > - Comment the PQ TF need after HDR multiplier > > - Advertise the 3D LUT size as the size of a single-dimension (read-only) > > - remove function to check expected size from 3DLUT caps > > - cleanup comments > > > > It's worth noting that driver-specific properties are guarded by > > `AMD_PRIVATE_COLOR`. So, finally, this is the color management API when > > driver-specific properties are enabled: > > > >
Re: [RFC PATCH v3 10/12] tcp: RX path for devmem TCP
On Mon, Nov 6, 2023 at 10:44 AM Stanislav Fomichev wrote:
>
> On 11/05, Mina Almasry wrote:
> > In tcp_recvmsg_locked(), detect if the skb being received by the user
> > is a devmem skb. In this case - if the user provided the MSG_SOCK_DEVMEM
> > flag - pass it to tcp_recvmsg_devmem() for custom handling.
> >
> > tcp_recvmsg_devmem() copies any data in the skb header to the linear
> > buffer, and returns a cmsg to the user indicating the number of bytes
> > returned in the linear buffer.
> >
> > tcp_recvmsg_devmem() then loops over the unaccessible devmem skb frags,
> > and returns to the user a cmsg_devmem indicating the location of the
> > data in the dmabuf device memory. cmsg_devmem contains this information:
> >
> > 1. the offset into the dmabuf where the payload starts. 'frag_offset'.
> > 2. the size of the frag. 'frag_size'.
> > 3. an opaque token 'frag_token' to return to the kernel when the buffer
> > is to be released.
> >
> > The pages awaiting freeing are stored in the newly added
> > sk->sk_user_pages, and each page passed to userspace is get_page()'d.
> > This reference is dropped once the userspace indicates that it is
> > done reading this page. All pages are released when the socket is
> > destroyed.
> >
> > Signed-off-by: Willem de Bruijn
> > Signed-off-by: Kaiyuan Zhang
> > Signed-off-by: Mina Almasry
> >
> > ---
> >
> > RFC v3:
> > - Fixed issue with put_cmsg() failing silently.
> >
> > ---
> > include/linux/socket.h| 1 +
> > include/net/page_pool/helpers.h | 9 ++
> > include/net/sock.h| 2 +
> > include/uapi/asm-generic/socket.h | 5 +
> > include/uapi/linux/uio.h | 6 +
> > net/ipv4/tcp.c| 189 +-
> > net/ipv4/tcp_ipv4.c | 7 ++
> > 7 files changed, 214 insertions(+), 5 deletions(-)
> >
> > diff --git a/include/linux/socket.h b/include/linux/socket.h
> > index cfcb7e2c3813..fe2b9e2081bb 100644
> > --- a/include/linux/socket.h
> > +++ b/include/linux/socket.h
> > @@ -326,6 +326,7 @@ struct ucred {
> > * plain text and require encryption
> > */
> >
> > +#define MSG_SOCK_DEVMEM 0x200/* Receive devmem skbs as cmsg */
>
> Sharing the feedback that I've been providing internally on the public list:
>
There may have been a miscommunication. I don't recall hearing this
specific feedback from you, at least in the last few months. Sorry if
it seemed like I'm ignoring feedback :)
> IMHO, we need a better UAPI to receive the tokens and give them back to
> the kernel. CMSG + setsockopt(SO_DEVMEM_DONTNEED) get the job done,
> but look dated and hacky :-(
>
> We should either do some kind of user/kernel shared memory queue to
> receive/return the tokens (similar to what Jonathan was doing in his
> proposal?)
I'll take a look at Jonathan's proposal, sorry, I'm not immediately
familiar but I wanted to respond :-) But is the suggestion here to
build a new kernel-user communication channel primitive for the
purpose of passing the information in the devmem cmsg? IMHO that seems
like an overkill. Why add 100-200 lines of code to the kernel to add
something that can already be done with existing primitives? I don't
see anything concretely wrong with cmsg & setsockopt approach, and if
we switch to something I'd prefer to switch to an existing primitive
for simplicity?
The only other existing primitive to pass data outside of the linear
buffer is the MSG_ERRQUEUE that is used for zerocopy. Is that
preferred? Any other suggestions or existing primitives I'm not aware
of?
> or bite the bullet and switch to io_uring.
>
IMO io_uring & socket support are orthogonal, and one doesn't preclude
the other. As you know we like to use sockets and I believe there are
issues with io_uring adoption at Google that I'm not familiar with
(and could be wrong). I'm interested in exploring io_uring support as
a follow up but I think David Wei will be interested in io_uring
support as well anyway.
> I was also suggesting to do it via netlink initially, but it's probably
> a bit slow for these purpose, idk.
Yeah, I hear netlink is reserved for control paths and is
inappropriate for data path, but I'll let folks correct me if wrong.
--
Thanks,
Mina
Re: drm/panel: panel-simple power-off sequencing
Hi, On Fri, Oct 27, 2023 at 7:31 AM Doug Anderson wrote: > > I guess, in summary, I'm hoping you'll look again and find that this > really is a backlight enable. If not, I'd probably advocate for a > per-panel boolean. Circling back, I'm curious what ended up happening here. Did you decide that it actually was a backlight enable GPIO, or are you planning on sending a patch? -Doug
Re: [PATCH v2 2/3] drm/amdgpu: Add flag to disable implicit sync for GEM operations.
Am 06.11.23 um 16:47 schrieb Tatsuyuki Ishi: On Nov 6, 2023, at 22:44, Christian König wrote: Am 02.11.23 um 15:04 schrieb Tatsuyuki Ishi: In Vulkan, it is the application's responsibility to perform adequate synchronization before a sparse unmap, replace or BO destroy operation. Until now, the kernel applied the same rule as implicitly-synchronized APIs like OpenGL, which with per-VM BOs made page table updates stall the queue completely. The newly added AMDGPU_VM_EXPLICIT_SYNC flag allows drivers to opt-out of this behavior, while still ensuring adequate implicit sync happens for kernel-initiated updates (e.g. BO moves). We record whether to use implicit sync or not for each freed mapping. To avoid increasing the mapping struct's size, this is union-ized with the interval tree field which is unused after the unmap. The reason this is done with a GEM ioctl flag, instead of being a VM / context global setting, is that the current libdrm implementation shares the DRM handle even between different kind of drivers (radeonsi vs radv). It would be nice if we could make this more future prove by not using a flag, but rather a drm_syncobj. There is asynchronous VM_BIND and synchronous VM_BIND. Using syncobjs address asynchronous binds, but what this patch set solves is to add an explicitly synced synchronous bind. All VM updates are asynchronous in the sense that they are queues up and don't execute immediately. If you don't add input/output fences and don't sync implicitly with command submission any more you actually have no idea in userspace when they execute. That doesn't sound like a good idea to me. Even within Vulkan, there are use cases for synchronous binds. This is when a non-sparse BO is destroyed (or created but that’s not synchronized). Such operations should still be explicit sync, unlike OpenGL where it syncs to previous submissions. So adding asynchronous bind doesn’t supersede this need. I’ve also thought whether we can just make the unmap asynchronous, since the spec requires that destroyed stuff are not accessed in any way, but I think it will complicate behavior when the destruction of BO immediately follows. We should implement asynchronous bind someday to make vkQueueBindSparse work (even) better, but that will likely involve a larger scope including the scheduler. Getting synchronous but explicitly synced binds should be simpler and a good incremental step. That's the whole point, I don't think that the flag is simpler/cleaner than a fence. We still need to take the implicit sync which can come from kernel operations into account, but at the same time disable the implicit sync which comes from user space submissions. As far as I can see the easiest way to do this and which both doesn't break anything currently and still leaves room to extend the interface is to add an input dependency fence. If you then use a signaled syncpoint as input you get exactly the semantic you desire while we are still able to add an output fence later on. Regards, Christian. Tatsuyuki. You can extend the drm_amdgpu_gem_va structure by adding a drm_syncobj handle and timeline point at the end. If the syncobj/timeline point results in a fence we give that as input dependency the operation has to wait for. And output fence can come later on as well, but that one is much more harder to handle. Regards, Christian. Signed-off-by: Tatsuyuki Ishi --- .../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 14 -- drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 7 ++- drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h | 6 ++- drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 47 +++ drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h | 23 + drivers/gpu/drm/amd/amdkfd/kfd_svm.c | 18 +++ include/uapi/drm/amdgpu_drm.h | 2 + 9 files changed, 71 insertions(+), 50 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c index 7d6daf8d2bfa..10e129bff977 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c @@ -1196,7 +1196,7 @@ static void unmap_bo_from_gpuvm(struct kgd_mem *mem, struct amdgpu_device *adev = entry->adev; struct amdgpu_vm *vm = bo_va->base.vm; -amdgpu_vm_bo_unmap(adev, bo_va, entry->va); +amdgpu_vm_bo_unmap(adev, bo_va, entry->va, true); amdgpu_vm_clear_freed(adev, vm, _va->last_pt_update); diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c index 720011019741..612279e65bff 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c @@ -122,7 +122,7 @@ int amdgpu_unmap_static_csa(struct amdgpu_device *adev, struct amdgpu_vm *vm, } } -r = amdgpu_vm_bo_unmap(adev,
Re: [PATCH v1] drm: amd: Resolve Sphinx unexpected indentation warning
First, apologies to Jani Nikula. I accedently top posted on the other thread. My email client is giving me a hard time. The following works and, if everyone agrees, I'll send out a v2. * E.g.:: * * S: 19Mhz * * 0: 615Mhz * 1: 800Mhz * 2: 888Mhz * 3: 1000Mhz
Re: [PATCH v2 8/9] PCI: Exclude PCIe ports used for tunneling in pcie_bandwidth_available()
On Mon, Nov 06, 2023 at 12:44:25PM -0600, Mario Limonciello wrote: > Tangentially related; the link speed is currently symmetric but there are > two sysfs files. Mika left a comment in drivers/thunderbolt/switch.c it may > be asymmetric in the future. So we may need to keep that in mind on any > design that builds on top of them. Aren't asymmetric Thunderbolt speeds just a DisplayPort thing? > As 'thunderbolt' can be a module or built in, we need to bring code into PCI > core so that it works in early boot before it loads. tb_switch_get_generation() is small enough that it could be moved to the PCI core. I doubt that we need to make thunderbolt built-in only or move a large amount of code to the PCI core. Thanks, Lukas
Re: [PATCH] drivers: gpu: Fix warning using plain integer as NULL
Applied. This matches what we already do in the other clear state headers.
Alex
On Fri, Nov 3, 2023 at 12:00 PM Abhinav Singh
wrote:
>
> sparse static analysis tools generate a warning with this message
> "Using plain integer as NULL pointer". In this case this warning is
> being shown because we are trying to intialize a pointer to NULL using
> integer value 0.
>
> Signed-off-by: Abhinav Singh
> ---
> drivers/gpu/drm/radeon/clearstate_evergreen.h | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/clearstate_evergreen.h
> b/drivers/gpu/drm/radeon/clearstate_evergreen.h
> index 63a1ffbb3ced..3b645558f133 100644
> --- a/drivers/gpu/drm/radeon/clearstate_evergreen.h
> +++ b/drivers/gpu/drm/radeon/clearstate_evergreen.h
> @@ -1049,7 +1049,7 @@ static const struct cs_extent_def SECT_CONTEXT_defs[] =
> {SECT_CONTEXT_def_5, 0xa29e, 5 },
> {SECT_CONTEXT_def_6, 0xa2a5, 56 },
> {SECT_CONTEXT_def_7, 0xa2de, 290 },
> -{ 0, 0, 0 }
> +{ NULL, 0, 0 }
> };
> static const u32 SECT_CLEAR_def_1[] =
> {
> @@ -1060,7 +1060,7 @@ static const u32 SECT_CLEAR_def_1[] =
> static const struct cs_extent_def SECT_CLEAR_defs[] =
> {
> {SECT_CLEAR_def_1, 0xffc0, 3 },
> -{ 0, 0, 0 }
> +{ NULL, 0, 0 }
> };
> static const u32 SECT_CTRLCONST_def_1[] =
> {
> @@ -1070,11 +1070,11 @@ static const u32 SECT_CTRLCONST_def_1[] =
> static const struct cs_extent_def SECT_CTRLCONST_defs[] =
> {
> {SECT_CTRLCONST_def_1, 0xf3fc, 2 },
> -{ 0, 0, 0 }
> +{ NULL, 0, 0 }
> };
> static const struct cs_section_def evergreen_cs_data[] = {
> { SECT_CONTEXT_defs, SECT_CONTEXT },
> { SECT_CLEAR_defs, SECT_CLEAR },
> { SECT_CTRLCONST_defs, SECT_CTRLCONST },
> -{ 0, SECT_NONE }
> +{ NULL, SECT_NONE }
> };
> --
> 2.39.2
>
Re: [PATCH v4 09/32] drm/amd/display: add plane 3D LUT driver-specific properties
On 11/02, Joshua Ashton wrote:
> Also, Melissa, you cannot do:
>
> if (!plane_state->color_mgmt_changed)
> return 0;
>
> in amdgpu_dm_plane_set_color_properties.
>
> The allocation for dc_plane_state could be new and zero'ed so it needs to be
> set every time. (Until AMDGPU has better dedup'ing of stuff there)
>
> The reason it looked like it worked for you now is because the duplicate was
> broken, so color mgmt for planes was always being marked as dirty there.
I see, it makes sense. I'll double-check it out, but thanks again for
debugging the issue.
BR,
Melissa
>
> Thanks
>
> - Joshie ✨
>
> On 11/2/23 03:48, Joshua Ashton wrote:
> >
> >
> > On 10/5/23 18:15, Melissa Wen wrote:
> > > Add 3D LUT property for plane color transformations using a 3D lookup
> > > table. 3D LUT allows for highly accurate and complex color
> > > transformations and is suitable to adjust the balance between color
> > > channels. It's also more complex to manage and require more
> > > computational resources.
> > >
> > > Since a 3D LUT has a limited number of entries in each dimension we want
> > > to use them in an optimal fashion. This means using the 3D LUT in a
> > > colorspace that is optimized for human vision, such as sRGB, PQ, or
> > > another non-linear space. Therefore, userpace may need one 1D LUT
> > > (shaper) before it to delinearize content and another 1D LUT after 3D
> > > LUT (blend) to linearize content again for blending. The next patches
> > > add these 1D LUTs to the plane color mgmt pipeline.
> > >
> > > v3:
> > > - improve commit message about 3D LUT
> > > - describe the 3D LUT entries and size (Harry)
> > >
> > > v4:
> > > - advertise 3D LUT max size as the size of a single-dimension
> > >
> > > Signed-off-by: Melissa Wen
> > > ---
> > > drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h | 18 +++
> > > .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 9
> > > .../amd/display/amdgpu_dm/amdgpu_dm_color.c | 14 +++
> > > .../amd/display/amdgpu_dm/amdgpu_dm_plane.c | 23 +++
> > > 4 files changed, 64 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
> > > b/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
> > > index 62044d41da75..f7adaa52c23f 100644
> > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
> > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
> > > @@ -363,6 +363,24 @@ struct amdgpu_mode_info {
> > > * @plane_hdr_mult_property:
> > > */
> > > struct drm_property *plane_hdr_mult_property;
> > > + /**
> > > + * @plane_lut3d_property: Plane property for color
> > > transformation using
> > > + * a 3D LUT (pre-blending), a three-dimensional array where each
> > > + * element is an RGB triplet. Each dimension has a size of the cubed
> > > + * root of lut3d_size. The array contains samples from the
> > > approximated
> > > + * function. On AMD, values between samples are estimated by
> > > + * tetrahedral interpolation. The array is accessed with three
> > > indices,
> > > + * one for each input dimension (color channel), blue being the
> > > + * outermost dimension, red the innermost.
> > > + */
> > > + struct drm_property *plane_lut3d_property;
> > > + /**
> > > + * @plane_degamma_lut_size_property: Plane property to define
> > > the max
> > > + * size of 3D LUT as supported by the driver (read-only). The
> > > max size
> > > + * is the max size of one dimension and, therefore, the max
> > > number of
> > > + * entries for 3D LUT array is the 3D LUT size cubed;
> > > + */
> > > + struct drm_property *plane_lut3d_size_property;
> > > };
> > > #define AMDGPU_MAX_BL_LEVEL 0xFF
> > > diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
> > > b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
> > > index bb2ce843369d..7a2350c62cf1 100644
> > > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
> > > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
> > > @@ -784,6 +784,11 @@ struct dm_plane_state {
> > > * TF is needed for any subsequent linear-to-non-linear transforms.
> > > */
> > > __u64 hdr_mult;
> > > + /**
> > > + * @lut3d: 3D lookup table blob. The blob (if not NULL) is an
> > > array of
> > > + * drm_color_lut.
> > > + */
> > > + struct drm_property_blob *lut3d;
> > > };
> > > struct dm_crtc_state {
> > > @@ -869,6 +874,10 @@ void amdgpu_dm_update_freesync_caps(struct
> > > drm_connector *connector,
> > > void amdgpu_dm_trigger_timing_sync(struct drm_device *dev);
> > > +/* 3D LUT max size is 17x17x17 (4913 entries) */
> > > +#define MAX_COLOR_3DLUT_SIZE 17
> > > +#define MAX_COLOR_3DLUT_BITDEPTH 12
> > > +/* 1D LUT size */
> > > #define MAX_COLOR_LUT_ENTRIES 4096
> > > /* Legacy gamm LUT users such as X doesn't like large LUT sizes */
> > > #define MAX_COLOR_LEGACY_LUT_ENTRIES 256
> > > diff --git
