Link Off Between Active Frames, is a new feature for eDP
that allows the panel to go to lower power state after
transmission of data. This is a feature on top of ALPM, AS SDP.
Add compute config during atomic-check phase.
v1: RFC version.
v2: Add separate flag for auxless-alpm. [Jani]
v3:
-
For validation purpose add debugfs for LOBF.
v1: Initial version.
v2: Add aux-wake/less info along with lobf status. [Jouni]
Signed-off-by: Animesh Manna
---
drivers/gpu/drm/i915/display/intel_alpm.c | 49 +++
drivers/gpu/drm/i915/display/intel_alpm.h | 2 +
Set the Link Off Between Frames Enable bit in ALPM_CTL register.
Note: Lobf need to be enabled adaptive sync fixed refresh mode
where vmin = vmax = flipline, which will arise after cmmr feature
enablement. Will add enabling sequence in a separate patch.
v1: Initial version.
v2: Condition check
From: Jouni Högander
eDP1.5 adds some more bits into DP_RECEIVER_ALPM_CAP and
DP_RECEIVER_ALPM_CONFIG registers. Add definitions for these.
Signed-off-by: Jouni Högander
---
include/drm/display/drm_dp.h | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git
Move ALPM feature related code as it will be used for
non-psr panel also thorugh LOBF feature.
v1: Initial version.
v2: Correct ordering in makefile. [Jani]
Signed-off-by: Animesh Manna
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/display/intel_alpm.c | 292
ALPM can be enabled for non psr panel and currenly aplm-params are
encapsulated under intel_psr struct, so moving out to intel_dp struct.
Signed-off-by: Animesh Manna
---
.../drm/i915/display/intel_display_types.h| 21 +
drivers/gpu/drm/i915/display/intel_psr.c | 43
Link Off Between Active Frames (LOBF) allows an eDP link to be turned Off and On
durning long VBLANK durations without enabling any of the PSR/PSR2/PR modes of
operation.
Bspec: 71477
Note: Lobf need to be enabled adaptive sync fixed refresh mode
where vmin = vmax = flipline, which will arise
On Tue, May 07, 2024 at 01:04:11PM GMT, Shuicheng Lin wrote:
Here is the failure stack:
[ 12.988209] [ cut here ]
[ 12.988216] UBSAN: shift-out-of-bounds in ./include/linux/log2.h:57:13
[ 12.988232] shift exponent 64 is too large for 64-bit type 'long unsigned
int'
On Thu, May 9, 2024 at 9:28 AM Doug Anderson wrote:
>
> Hi,
>
> On Tue, May 7, 2024 at 4:05 PM Abhinav Kumar wrote:
> >
> > Since commit 5acf49119630 ("drm/msm: import gen_header.py script from
> > Mesa"),
> > compilation is broken on machines having python versions older than 3.9
> > due to
The IVO t109nw41 is a 11.0" WUXGA TFT LCD panel, use hx83102 controller
which fits in nicely with the existing panel-himax-hx83102 driver. Hence,
we add a new compatible with panel specific config.
Signed-off-by: Cong Yang
---
Chage since V5:
- Adjust inital cmds indentation and check accum_err
The IVO t109nw41 is a 11.0" WUXGA TFT LCD panel with himax-hx83102
controller. Hence, we add a new compatible with panel specific config.
Signed-off-by: Cong Yang
Acked-by: Conor Dooley
---
Chage since V5:
- No change.
V4:
The BOE nv110wum-l60 is a 11.0" WUXGA TFT LCD panel, use hx83102 controller
which fits in nicely with the existing panel-himax-hx83102 driver. Hence,
we add a new compatible with panel specific config.
Signed-off-by: Cong Yang
---
Chage since V5:
- Adjust inital cmds indentation and check
The BOE nv110wum-l60 is a 11.0" WUXGA TFT LCD panel with himax-hx83102
controller. Hence, we add a new compatible with panel specific config.
Signed-off-by: Cong Yang
Acked-by: Conor Dooley
---
Chage since V5:
- No change.
V4:
DRM_PANEL_HIMAX_HX83102 is being split out from DRM_PANEL_BOE_TV101WUM_NL6.
Since the arm64 defconfig had the BOE panel driver enabled, let's also
enable the himax driver.
Signed-off-by: Cong Yang
Reviewed-by: Douglas Anderson
---
arch/arm64/configs/defconfig | 1 +
1 file changed, 1
The Starry HX83102 based mipi panel should never have been part of the boe
tv101wum-n16 driver. Discussion with Doug and Linus in V1 [1], we need a
separate driver to enable the hx83102 controller.
In hx83102 driver, add DSI commands as macros. So it can add some panels
with same control model in
In V1, discussed with Doug and Linus [1], we need break out as separate
driver for the himax83102-j02 controller. Beacuse "starry,himax83102-j02"
and in this series "BOE nv110wum-l60" "IVO t109nw41" panels use same
controller, they have some common CMDS. So add new documentation for
this panels.
Discussion with Doug and Linus in V1, we need a
separate driver to enable the hx83102 controller.
So this series this series mainly Break out as separate driver
for Starry-himax83102-j02 panels from boe tv101wum driver.
Then add BOE nv110wum-l60 and IVO t109nw41 in himax-hx83102 driver.
Add
Both virtio_gpu_queue_ctrl_buffer and virtio_gpu_queue_cursor use
virtqueue_add_sgs to upload the structure virtio_gpu_vbuffer * vbuf
to virtqueue. However, when the vbuf fails to upload and virtqueue_add_sgs
returns -EIO or -ENOMEM, the vbuf will not be able to be free by
Hi,
On Tue, May 7, 2024 at 4:05 PM Abhinav Kumar wrote:
>
> Since commit 5acf49119630 ("drm/msm: import gen_header.py script from Mesa"),
> compilation is broken on machines having python versions older than 3.9
> due to dependency on argparse.BooleanOptionalAction.
>
> Switch to use simple bool
Hi Weishi,
kernel test robot noticed the following build warnings:
[auto build test WARNING on drm-misc/drm-misc-next]
[also build test WARNING on drm/drm-next linus/master v6.9-rc7 next-20240508]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch
I2C v7, SMBus 3.2, and I3C 1.1.1 specifications have replaced "master/slave"
with more appropriate terms. Inspired by Wolfram's series to fix drivers/i2c/,
fix the terminology for users of I2C_ALGOBIT bitbanging interface, now that
the approved verbiage exists in the specification.
Compile
I2C v7, SMBus 3.2, and I3C 1.1.1 specifications have replaced "master/slave"
with more appropriate terms. Inspired by Wolfram's series to fix drivers/i2c/,
fix the terminology for users of I2C_ALGOBIT bitbanging interface, now that
the approved verbiage exists in the specification.
Compile
I2C v7, SMBus 3.2, and I3C 1.1.1 specifications have replaced "master/slave"
with more appropriate terms. Inspired by Wolfram's series to fix drivers/i2c/,
fix the terminology for users of I2C_ALGOBIT bitbanging interface, now that
the approved verbiage exists in the specification.
Compile
I2C v7, SMBus 3.2, and I3C 1.1.1 specifications have replaced "master/slave"
with more appropriate terms. Inspired by Wolfram's series to fix drivers/i2c/,
fix the terminology for users of I2C_ALGOBIT bitbanging interface, now that
the approved verbiage exists in the specification.
Compile
I2C v7, SMBus 3.2, and I3C 1.1.1 specifications have replaced "master/slave"
with more appropriate terms. Inspired by Wolfram's series to fix drivers/i2c/,
fix the terminology for users of I2C_ALGOBIT bitbanging interface, now that
the approved verbiage exists in the specification.
Compile
I2C v7, SMBus 3.2, and I3C 1.1.1 specifications have replaced "master/slave"
with more appropriate terms. Inspired by Wolfram's series to fix drivers/i2c/,
fix the terminology for users of I2C_ALGOBIT bitbanging interface, now that
the approved verbiage exists in the specification.
Compile
I2C v7, SMBus 3.2, and I3C 1.1.1 specifications have replaced "master/slave"
with more appropriate terms. Inspired by and following on to Wolfram's
series to fix drivers/i2c/[1], fix the terminology for users of the
I2C_ALGOBIT bitbanging interface, now that the approved verbiage exists
in the
On 5/8/2024 3:41 PM, Doug Anderson wrote:
Hi,
On Fri, May 3, 2024 at 11:15 AM Dmitry Baryshkov
wrote:
@@ -941,6 +948,7 @@ def main():
parser = argparse.ArgumentParser()
parser.add_argument('--rnn', type=str, required=True)
parser.add_argument('--xml', type=str,
On Wed, May 8, 2024 at 6:06 PM Mohamed Ahmed <
mohamedahmedegypt2...@gmail.com> wrote:
> Allows PTE kind and tile mode on BO create with VM_BIND,
> and adds a GETPARAM to indicate this change. This is needed to support
> modifiers in NVK and ensure correctness when dealing with the nouveau
> GL
Allows PTE kind and tile mode on BO create with VM_BIND,
and adds a GETPARAM to indicate this change. This is needed to support
modifiers in NVK and ensure correctness when dealing with the nouveau
GL driver.
The userspace modifiers implementation this is for can be found here:
Hi Dave, Sima,
Fixes for 6.9.
The following changes since commit dd5a440a31fae6e459c0d627162825505361:
Linux 6.9-rc7 (2024-05-05 14:06:01 -0700)
are available in the Git repository at:
https://gitlab.freedesktop.org/agd5f/linux.git
tags/amd-drm-fixes-6.9-2024-05-08
for you to fetch
Hi,
On Fri, May 3, 2024 at 11:15 AM Dmitry Baryshkov
wrote:
>
> @@ -941,6 +948,7 @@ def main():
> parser = argparse.ArgumentParser()
> parser.add_argument('--rnn', type=str, required=True)
> parser.add_argument('--xml', type=str, required=True)
> +
Quoting Jani Nikula (2024-05-08 01:43:56)
> On Tue, 07 May 2024, Abhinav Kumar wrote:
> > Since commit 5acf49119630 ("drm/msm: import gen_header.py script from
> > Mesa"),
> > compilation is broken on machines having python versions older than 3.9
> > due to dependency on
Hey everyone! This is just a general reminder that if you're interested
in receiving professional Code of Conduct enforcement training for your
project - freedesktop.org is happy to cover the costs for doing such
training through the wonderful services of https://otter.technology/ .
All that's
On Wed, May 08, 2024 at 10:39:58AM +0200, Daniel Vetter wrote:
> On Tue, May 07, 2024 at 10:59:42PM +0300, Dmitry Baryshkov wrote:
> > On Tue, 7 May 2024 at 21:40, Laurent Pinchart wrote:
> > > On Tue, May 07, 2024 at 06:19:18PM +0300, Dmitry Baryshkov wrote:
> > > > On Tue, 7 May 2024 at 18:15,
On Thu, May 09, 2024 at 12:51:08AM +0300, Laurent Pinchart wrote:
> On Wed, May 08, 2024 at 10:36:08AM +0200, Daniel Vetter wrote:
> > On Tue, May 07, 2024 at 04:07:39PM -0400, Nicolas Dufresne wrote:
> > > Le mardi 07 mai 2024 à 21:36 +0300, Laurent Pinchart a écrit :
> > > > Shorter term, we
On Wed, May 08, 2024 at 10:36:08AM +0200, Daniel Vetter wrote:
> On Tue, May 07, 2024 at 04:07:39PM -0400, Nicolas Dufresne wrote:
> > Le mardi 07 mai 2024 à 21:36 +0300, Laurent Pinchart a écrit :
> > > Shorter term, we have a problem to solve, and the best option we have
> > > found so far is to
MST colorspace property support was disabled due to a series of warnings
that came up when the device was plugged in since the properties weren't
made at device creation. Create the properties in advance instead.
Suggested-by: Ville Syrjälä
Fixes: 69a959610229 ("drm/amd/display: Temporary
Hi,
On Sun, May 5, 2024 at 11:52 PM Linus Walleij wrote:
>
> On Fri, May 3, 2024 at 11:36 PM Douglas Anderson
> wrote:
>
> > As talked about in commit d2aacaf07395 ("drm/panel: Check for already
> > prepared/enabled in drm_panel"), we want to remove needless code from
> > panel drivers that
On Wed, May 8, 2024 at 4:12 PM Easwar Hariharan
wrote:
>
> On 5/8/2024 7:53 AM, Alex Deucher wrote:
> > On Tue, May 7, 2024 at 2:32 PM Easwar Hariharan
> > wrote:
> >>
> >> On 5/3/2024 11:13 AM, Easwar Hariharan wrote:
> >>> I2C v7, SMBus 3.2, and I3C 1.1.1 specifications have replaced
> >>>
On Wed, May 8, 2024, at 22:36, Sam Ravnborg wrote:
>>
>> I think if you want to do a new version, that is likely to run
>> into new problems, given that this part of fbdev is particularly
>> fragile and partly wrong. On the other hand, it would be nice to
>> have a patch to limit the use of the
On Wed, May 08, 2024 at 09:23:17AM GMT, Tvrtko Ursulin wrote:
On 07/05/2024 22:35, Lucas De Marchi wrote:
On Fri, Apr 26, 2024 at 11:47:37AM GMT, Tvrtko Ursulin wrote:
On 24/04/2024 00:56, Lucas De Marchi wrote:
Print the accumulated runtime for client when printing fdinfo.
Each time a
Consensus on the mailing lists is that panels shouldn't use a table of
init commands but should instead use init functions. With the recently
introduced mipi_dsi_dcs_write_seq_multi() this is not only clean/easy
but also saves space. Measuring before/after this change:
$ scripts/bloat-o-meter \
Consensus on the mailing lists is that panels shouldn't use a table of
init commands but should instead use init functions. We'll use the
same concepts as the recently introduced
mipi_dsi_generic_write_seq_multi() to make this clean/easy and also
not bloat the driver too much. Measuring
Consensus on the mailing lists is that panels shouldn't use a table of
init commands but should instead use init functions. With the recently
introduced mipi_dsi_dcs_write_seq_multi() this is not only clean/easy
but also saves space. Measuring before/after this change:
$ scripts/bloat-o-meter \
This is a mechanical conversion of the novatek-nt36672e driver to use
the new mipi_dsi_dcs_write_seq_multi(). The new function is easier for
clients to understand and using it also causes smaller code to be
generated. Specifically:
$ scripts/bloat-o-meter \
...after/panel-novatek-nt36672e.ko \
The current mipi_dsi_*_write_seq() macros are non-intutitive because
they contain a hidden "return" statement that will return out of the
_caller_ of the macro. Let's mark them as deprecated and instead
introduce some new macros that are more intuitive.
These new macros are less optimal when an
Through a cooperative effort between Hsin-Yi Wang and Dmitry
Baryshkov, we have realized the dev_err() in the
mipi_dsi_*_write_seq() macros was causing quite a bit of bloat to the
kernel. Let's hoist this call into drm_mipi_dsi.c by adding a "chatty"
version of the functions that includes the
We really don't expect these errors to be printed over and over
again. When a driver hits the error it should bail out. Just use a
normal error print.
This gives a nice space savings for users of these functions:
$ scripts/bloat-o-meter \
.../before/panel-novatek-nt36672e.ko \
The mipi_dsi_generic_write_seq() macro makes a call to
mipi_dsi_generic_write() which returns a type ssize_t. The macro then
stores it in an int and checks to see if it's negative. This could
theoretically be a problem if "ssize_t" is larger than "int".
To see the issue, imagine that "ssize_t" is
The mipi_dsi_dcs_write_seq() macro makes a call to
mipi_dsi_dcs_write_buffer() which returns a type ssize_t. The macro
then stores it in an int and checks to see if it's negative. This
could theoretically be a problem if "ssize_t" is larger than "int".
To see the issue, imagine that "ssize_t" is
The consensus of many DRM folks is that we want to move away from DSI
drivers defining tables of init commands. Instead, we want to move to
init functions that can use common DRM functions. The issue thus far
has been that using the macros mipi_dsi_generic_write_seq() and
mipi_dsi_dcs_write_seq()
On 08/05/2024 17:46, Abhinav Kumar wrote:
On 5/8/2024 2:17 AM, Jon Hunter wrote:
Building the kernel with python3 versions earlier than v3.9 fails with
...
Traceback (most recent call last):
File "drivers/gpu/drm/msm/registers/gen_header.py", line 970, in
main()
File
Hi Arnd,
>
> I think if you want to do a new version, that is likely to run
> into new problems, given that this part of fbdev is particularly
> fragile and partly wrong. On the other hand, it would be nice to
> have a patch to limit the use of the notifiers to the smallest
> set of kernel
On 08/05/2024 11:51, Jason-JH.Lin wrote:
> When we run kernel with lockdebug option, we will get the BUG below:
> [ 106.692124] BUG: sleeping function called from invalid context at
> drivers/base/power/runtime.c:1164
> [ 106.692190] in_atomic(): 1, irqs_disabled(): 128, non_block: 0, pid:
On 5/8/2024 7:53 AM, Alex Deucher wrote:
> On Tue, May 7, 2024 at 2:32 PM Easwar Hariharan
> wrote:
>>
>> On 5/3/2024 11:13 AM, Easwar Hariharan wrote:
>>> I2C v7, SMBus 3.2, and I3C 1.1.1 specifications have replaced "master/slave"
>>> with more appropriate terms. Inspired by and following on to
On Wed, May 08, 2024 at 02:43:07PM -0500, Mario Limonciello wrote:
> When the colorspace property is registered on MST devices there is
> no `obj_free_cb` callback for it in drm_mode_object_add().
>
> Don't show a warning trace for __drm_mode_object_add() calls for
> DRM_MODE_OBJECT_PROPERTY.
MST colorspace property support was disabled due to a series of warnings
that came up when the device was plugged in. As those warnings are fixed,
revert commit 69a959610229 ("drm/amd/display: Temporary Disable MST DP
Colorspace Property").
Reported-and-tested-by: Tyler Schneider
Closes:
When the colorspace property is registered on MST devices there is
no `obj_free_cb` callback for it in drm_mode_object_add().
Don't show a warning trace for __drm_mode_object_add() calls for
DRM_MODE_OBJECT_PROPERTY.
Reported-and-tested-by: Tyler Schneider
Closes:
On Mon, Apr 08, 2024 at 08:04:05PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> I got fed up having to build multiple architectures when
> doing subsystem wide refactoring. So I decided to attack
> the low hanging COMPILE_TEST=y fruit. Here are the
> results. All of these drivers now
Hello!
We're delighted to announce that the 2024 X.Org Developers Conference
(XDC) will be taking place on October 9 to 11 in Montréal, Canada, co-
located with the GStreamer Conference & Hackfest 2024 which will be
running from October 7 to 10. Join us for a freedesktop week in
Montréal!
XDC is
On 08/05/2024 16:54, Daniel Vetter wrote:
> On Wed, May 08, 2024 at 09:02:02AM +0100, Chris Clayton wrote:
>> Hi,
>>
>> I'm running the latest development kernel - 6.9.0-rc7+ (HEAD is
>> dccb07f2914cdab2ac3a5b6c98406f765acab803.)
>>
>> As I say in $SUBJECT, the directory
On Wed, May 8, 2024, at 20:37, Florian Fainelli wrote:
> On 5/7/24 04:44, Arnd Bergmann wrote:
>> On Tue, May 7, 2024, at 13:10, Daniel Vetter wrote:
>>> On Mon, May 06, 2024 at 04:53:47PM +0200, Arnd Bergmann wrote:
>> Right, let's wait for Florian to reply. From what he said earlier
>> though,
On Mon, Apr 29, 2024 at 1:32 PM Jim Cromie wrote:
>
> hi Greg, Jason, DRM-folk,
>
> This patchset fixes the CONFIG_DRM_USE_DYNAMIC_DEBUG=y regression,
> Fixes: bb2ff6c27bc9 ("drm: Disable dynamic debug as broken")
>
> this is v8.
> Its also here:
>
Hi Dave and Sima,
Here goes our last fixes for v6.9.
drm-intel-fixes-2024-05-08:
- Automate CCS Mode setting during engine resets (Andi)
- Fix audio time stamp programming for DP (Chaitanya)
- Fix parsing backlight BDB data (Karthikeyan)
The following changes since commit
On 08.05.24 20:09, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
The logic assumed any migration attempt worked and therefore would over-
account the amount of data migrated during buffer re-validation. As a
consequence client can be unfairly penalised by incorrectly considering
its migration
On Tue, May 07, 2024 at 10:09:18AM +0100, Tvrtko Ursulin wrote:
>
> On 07/05/2024 00:23, Matthew Brost wrote:
> > On Thu, May 02, 2024 at 03:33:50PM +0100, Tvrtko Ursulin wrote:
> > >
> > > Hi all,
> > >
> > > Continuing after the brief IRC discussion yesterday regarding work queues
> > > being
On Wed, May 08, 2024 at 12:12:32PM +0300, Jani Nikula wrote:
> On Mon, 08 Apr 2024, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Replace the open coded drm_crtc_vblank_crtc() with the real
> > thing.
> >
> > Cc: intel-...@lists.freedesktop.org
> > Signed-off-by: Ville Syrjälä
>
>
On Wed, May 08, 2024 at 09:47:50AM -0400, Alex Deucher wrote:
> On Mon, Apr 8, 2024 at 3:06 PM Ville Syrjala
> wrote:
> >
> > From: Ville Syrjälä
> >
> > Replace the open coded drm_crtc_vblank_crtc() with the real
> > thing.
> >
> > Cc: Alex Deucher
> > Cc: "Christian König"
> > Cc: "Pan,
On 5/7/24 04:44, Arnd Bergmann wrote:
On Tue, May 7, 2024, at 13:10, Daniel Vetter wrote:
On Mon, May 06, 2024 at 04:53:47PM +0200, Arnd Bergmann wrote:
On Mon, May 6, 2024, at 15:14, Daniel Vetter wrote:
On Fri, May 03, 2024 at 01:22:10PM -0700, Florian Fainelli wrote:
On 5/3/24 12:45, Arnd
Hi everyone,
I wasn't aware of these patches, but I'm really glad they are getting
some attention, thanks a lot for your review Sima.
Given that it's been a while since the patches were emailed, I'm not
sure if the original authors of the patches could implement your
comments. If not, I can work
From: Tvrtko Ursulin
The logic assumed any migration attempt worked and therefore would over-
account the amount of data migrated during buffer re-validation. As a
consequence client can be unfairly penalised by incorrectly considering
its migration budget spent.
Fix it by looking at the before
From: Tvrtko Ursulin
Current code appears to live in a misconception that playing with buffer
allowed and preferred placements can control the decision on whether
backing store migration will be attempted or not.
Both from code inspection and from empirical experiments I see that not
being
From: Tvrtko Ursulin
Last few days I was looking at the situation with VRAM over subscription, what
happens versus what perhaps should happen. Browsing through the driver and
running some simple experiments.
I ended up with this patch series which, as a disclaimer, may be completely
wrong but
From: Tvrtko Ursulin
Currently the driver appears to be thinking that it will be attempting to
re-validate the evicted buffers on the next submission if they are not in
their preferred placement.
That however appears not to be true for the very common case of buffers
with allowed placements of
From: Tvrtko Ursulin
Currently the fallback placement flag can achieve a hint that buffer
should be migrated back to the non-fallback placement, however that only
works while there is no memory pressure. As soon as we reach full VRAM
utilisation, or worse overcommit, the logic is happy to leave
From: Tvrtko Ursulin
Now that TTM has the preferred placement flag, extend the current
workaround which assumes the GTT placement as fallback in the presence of
the additional VRAM placement.
By marking the VRAM placement as preferred we will make the buffer re-
validation phase actually
_until(!gpu_read(gpu, REG_A6XX_GBIF_HALT_ACK));
-
gpu_write(gpu, REG_A6XX_RBBM_SECVID_TSB_CNTL, 0);
if (adreno_is_a619_holi(adreno_gpu))
---
base-commit: 93a39e4766083050ca0ecd6a3548093a3b9eb60c
change-id: 20240508-topic-adreno-a2d199cd4152
Best regards,
--
Konrad Dybcio
Hi,
On Wed, May 8, 2024 at 4:52 AM cong yang
wrote:
>
> > > +static int starry_himax83102_j02_init(struct hx83102 *ctx)
> > > +{
> > > + struct mipi_dsi_multi_context dsi_ctx = { .dsi = ctx->dsi };
> > > +
> > > + hx83102_enable_extended_cmds(ctx, true);
> > > +
On Wed, 8 May 2024 at 09:19, Linus Torvalds
wrote:
>
> So since we already have two versions of F_DUPFD (the other being
> F_DUPFD_CLOEXEC) I decided that the best thing to do is to just extend
> on that existing naming pattern, and called it F_DUPFD_QUERY instead.
>
> I'm not married to the
On 5/8/24 16:51, Christoph Hellwig wrote:
On Wed, May 08, 2024 at 12:35:52PM +0100, Pavel Begunkov wrote:
all these, because e.g. ttm internally does have a page pool because
depending upon allocator, that's indeed beneficial. Other drm drivers have
more buffer-based concepts for
On 5/8/2024 1:43 AM, Jani Nikula wrote:
On Tue, 07 May 2024, Abhinav Kumar wrote:
Since commit 5acf49119630 ("drm/msm: import gen_header.py script from Mesa"),
compilation is broken on machines having python versions older than 3.9
due to dependency on argparse.BooleanOptionalAction.
Is
On 5/8/2024 2:17 AM, Jon Hunter wrote:
Building the kernel with python3 versions earlier than v3.9 fails with ...
Traceback (most recent call last):
File "drivers/gpu/drm/msm/registers/gen_header.py", line 970, in
main()
File "drivers/gpu/drm/msm/registers/gen_header.py",
On Tue, 7 May 2024 at 12:07, Linus Torvalds
wrote:
>
> That example thing shows that we shouldn't make it a FISAME ioctl - we
> should make it a fcntl() instead, and it would just be a companion to
> F_DUPFD.
>
> Doesn't that strike everybody as a *much* cleaner interface? I think
> F_ISDUP would
On 5/8/24 16:58, Jason Gunthorpe wrote:
On Wed, May 08, 2024 at 04:44:32PM +0100, Pavel Begunkov wrote:
like a weird and indirect way to get there. Why can't io_uring just be
the entity that does the final free and not mess with the logic
allocator?
Then the user has to do a syscall (e.g.
On Wed, May 08, 2024 at 04:44:32PM +0100, Pavel Begunkov wrote:
> > like a weird and indirect way to get there. Why can't io_uring just be
> > the entity that does the final free and not mess with the logic
> > allocator?
>
> Then the user has to do a syscall (e.g. via io_uring) to return pages,
On Wed, May 08, 2024 at 09:02:02AM +0100, Chris Clayton wrote:
> Hi,
>
> I'm running the latest development kernel - 6.9.0-rc7+ (HEAD is
> dccb07f2914cdab2ac3a5b6c98406f765acab803.)
>
> As I say in $SUBJECT, the directory /sys/kernel/debug/vgaswitcheroo is
> missing in this release. Perhaps
On Wed, May 08, 2024 at 09:38:33AM +0100, Daniel Stone wrote:
> On Wed, 8 May 2024 at 09:33, Daniel Vetter wrote:
> > On Wed, May 08, 2024 at 06:46:53AM +0100, Daniel Stone wrote:
> > > That would have the unfortunate side effect of making sandboxed apps
> > > less efficient on some platforms,
On Wed, May 08, 2024 at 12:08:57PM +0200, Christian Brauner wrote:
> On Mon, May 06, 2024 at 04:29:44PM +0200, Christian König wrote:
> > Am 04.05.24 um 20:20 schrieb Linus Torvalds:
> > > On Sat, 4 May 2024 at 08:32, Linus Torvalds
> > > wrote:
> > > > Lookie here, the fundamental issue is that
On 5/8/24 15:25, Jason Gunthorpe wrote:
On Wed, May 08, 2024 at 12:30:07PM +0100, Pavel Begunkov wrote:
I'm not going to pretend to know about page pool details, but dmabuf
is the way to get the bulk of pages into a pool within the net stack's
allocator and keep that bulk properly refcounted
On Wed, May 08, 2024 at 12:35:52PM +0100, Pavel Begunkov wrote:
> On 5/8/24 08:16, Daniel Vetter wrote:
> > On Tue, May 07, 2024 at 08:32:47PM -0300, Jason Gunthorpe wrote:
> > > On Tue, May 07, 2024 at 08:35:37PM +0100, Pavel Begunkov wrote:
> > > > On 5/7/24 18:56, Jason Gunthorpe wrote:
> > > >
On Tue, May 7, 2024 at 2:32 PM Easwar Hariharan
wrote:
>
> On 5/3/2024 11:13 AM, Easwar Hariharan wrote:
> > I2C v7, SMBus 3.2, and I3C 1.1.1 specifications have replaced "master/slave"
> > with more appropriate terms. Inspired by and following on to Wolfram's
> > series to fix drivers/i2c/[1],
This series has the intention to address two issues with Performance Counters
on V3D:
1. Update the number of Performance Counters for V3D 7.1
V3D 7.1 has 93 performance counters, while V3D 4.2 has only 87. Although the
series [1] enabled support for V3D 7.1, it didn’t replace the
The Performance Counters enum used to identify the index of each
performance counter and provide the total number of performance
counters (V3D_PERFCNT_NUM). But, this enum is only valid for V3D 4.2,
not for V3D 7.1.
As we implemented a new flexible structure to retrieve performance
counters
Currently, even though V3D 7.1 has 93 performance counters, it is not
possible to create counters bigger than 87, as
`v3d_perfmon_create_ioctl()` understands that counters bigger than 87
are invalid.
Therefore, create a device variable to expose the maximum
number of counters for a given V3D
The maximum number of performance counters can change from version to
version and it's important for userspace to know this value, as it needs
to use the counters for performance queries. Therefore, expose the
maximum number of performance counters to userspace as a parameter.
Signed-off-by:
V3D_PERFCNT_NUM represents the maximum number of performance counters
for V3D 4.2, but not for V3D 7.1. This means that, if we use
V3D_PERFCNT_NUM, we might go out-of-bounds on V3D 7.1.
Therefore, use the number of performance counters on V3D 7.1 as the
maximum number of counters. This will allow
Userspace usually needs some information about the performance counters
available. Although we could replicate this information in the kernel
and user-space, let's use the kernel as the "single source of truth" to
avoid issues in the future (e.g. list of performance counters is updated
in
Add name, category and description for each one of the 93 performance
counters available on V3D.
Note that V3D 4.2 has 87 performance counters, while V3D 7.1 has 93.
Therefore, there are two performance counters arrays. The index of the
performance counter for each V3D version is represented by
1 - 100 of 194 matches
Mail list logo
