Am 04.09.23 um 21:57 schrieb Sui Jingfeng:
From: Sui Jingfeng
On a machine with multiple GPUs, a Linux user has no control over which one
is primary at boot time.
Question is why is that useful? Should we give users the ability to
control that?
I don't see an use case for this.
Regards,
On Thursday, August 24, 2023 5:48 PM, Maxime Ripard wrote:
> On Wed, Aug 23, 2023 at 08:47:51AM +, Ying Liu wrote:
> > > > This dt-binding just follows generic dt-binding rule to describe the DPU
> IP
> > > > hardware, not the software implementation. DPU internal units do not
> > > >
On Tuesday, August 22, 2023 8:59 PM, Maxime Ripard wrote:
>
> Hi,
Hi,
>
> Aside from the discussion on the binding and the general architecture, I
> have some comments there.
Thanks for your comments.
>
> On Tue, Aug 22, 2023 at 04:59:48PM +0800, Liu Ying wrote:
> > +int dpu_cf_init(struct
Thomas Zimmermann writes:
> Refactor fb_pgprotect() in PowerPC to work without struct file. Then
> clean up and rename fb_pgprotect(). This change has been discussed at
> [1] in the context of refactoring fbdev's mmap code.
>
> The first three patches adapt PowerPC's internal interfaces to
>
The qseed_type field points out the particular QSEED type implemented by
the scaler. However this field is unused by the driver. Correct scaler
type is inferred from the features data. Drop the the qseed_type field.
Signed-off-by: Dmitry Baryshkov
---
Three different features, DPU_SSPP_SCALER_QSEED3, QSEED3LITE and QSEED4
are all related to different versions of the same HW scaling block.
Corresponding driver parts use scaler_blk.version to identify the
correct way to program the hardware. In order to simplify the driver
codepath, merge these
After folding QSEED3LITE and QSEED4 feature bits into QSEED3 several
VIG feature masks became equal. Drop these duplicates.
Signed-off-by: Dmitry Baryshkov
---
.../gpu/drm/msm/disp/dpu1/catalog/dpu_5_4_sm6125.h| 2 +-
.../gpu/drm/msm/disp/dpu1/catalog/dpu_6_0_sm8250.h| 8
The function _dpu_hw_sspp_setup_scaler3() passes and
dpu_hw_setup_scaler3() uses scaler_blk.version to determine in which way
the scaler (QSEED3) block should be programmed. However up to now we
were not setting this field. Set it now, splitting the vig_sblk data
which has different version
As the subblock info is now mostly gone, inline and drop the macro
DPU_HW_SUBBLK_INFO.
Signed-off-by: Dmitry Baryshkov
---
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h| 40 ++-
1 file changed, 21 insertions(+), 19 deletions(-)
diff --git
As we have dropped the variadic parts of SSPP sub-blocks declarations,
deduplicate them now, reducing memory cruft.
Signed-off-by: Dmitry Baryshkov
---
.../msm/disp/dpu1/catalog/dpu_3_0_msm8998.h | 16 +--
.../msm/disp/dpu1/catalog/dpu_4_0_sdm845.h| 16 +--
In preparation to deduplicating SSPP subblocks, drop the (unused)
`smart_dma_priority' field from struct dpu_sspp_sub_blks. If it is
needed later (e.g. for SmartDMA v1), it should be added to the SSPP
declarations themselves.
Signed-off-by: Dmitry Baryshkov
---
The field `id' is not used for subblocks. The handling code usually
knows, which sub-block it is now looking at. Drop the field completely.
Signed-off-by: Dmitry Baryshkov
---
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 76 +--
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h|
The handling code also usually knows, which sub-block it is now looking
at. Drop unused 'id' field and arguments and merge some of sub-block
declarations.
While we are at it, also fix all VIG subblocks to contain correct scaler
block version and drop the becoming unused QSEED-related feature
On 8/31/23 21:17, Rodrigo Vivi wrote:
On Tue, Aug 29, 2023 at 12:30:04PM -0400, Rodrigo Vivi wrote:
Nouveau has landed the GPU VA helpers, support and documentation
already and Xe is already using the upstream GPU VA.
Danilo, although this is more on the Xe side and I wouldn't ask you
to
Hi Rodrigo,
On 8/31/23 21:10, Rodrigo Vivi wrote:
On Tue, Aug 29, 2023 at 12:30:03PM -0400, Rodrigo Vivi wrote:
The consensus is for individual drivers VM_BIND uapis with
the GPUVA helpers that are already implemented and merged
upstream.
The merged GPUVA documentation also establish some
Hi Arthur,
On 9/1/23 14:08, Arthur Grillo wrote:
Insert parameterized test for the drm_fb_blit() to ensure correctness
and prevent future regressions.
The test is done by adding a call to drm_fb_blit() on every format
that has support. Also, to fully test the function, add new format
On 9/1/23 15:05, Arthur Grillo wrote:
When CONFIG_DEBUG_FS is not set -Wunused-function warnings appear,
make the static function inline to suppress that.
Reported-by: kernel test robot
Closes:
https://lore.kernel.org/oe-kbuild-all/202309012114.t8vlfaf8-...@intel.com/
Closes:
On 9/1/23 15:52, Arthur Grillo wrote:
fourccs_out array is not initialized. As the
drm_fb_build_fourcc_list() doesn't necessarily change all the array,
and the test compares all of it, the comparison could fail if the
array is not initialized. Zero initialize the array to fix this.
Fixes:
From: Sui Jingfeng
Because the display controller in N2000/D2000 series can be VGA-compatible,
so let's register gma500 as a VGA client, despite the firmware may alter
the PCI class code of IGD on a multiple GPU co-exist configuration. But
this commit no crime, because VGAARB only cares about
From: Sui Jingfeng
Because the display controller in the Hibmc chip is a VGA compatible
display controller. Because ARM64 doesn't need the VGA console. It does not
need to worry about the side effects that come with the VGA compatible.
However, the real problem is that some ARM64 PCs and servers
From: Sui Jingfeng
On a machine with multiple GPUs, a Linux user has no control over which one
is primary at boot time. This patch tries to solve the mentioned problem by
implementing the .be_primary() callback. Pass i915.modeset=10 on the kernel
cmd line if you really want the device bound by
From: Sui Jingfeng
Becasuse the display controller in the ASpeed BMC chip is a VGA-compatible
device, the software programming guide of AST2400 say that it is fully
IBM VGA compliant. Thus, it should also participate in the arbitration.
Cc: Thomas Zimmermann
Cc: Jocelyn Falempe
Signed-off-by:
From: Sui Jingfeng
On a machine with multiple GPUs, a Linux user has no control over which one
is primary at boot time. This patch tries to solve the mentioned problem by
implementing the .be_primary() callback. Pass loongson.modeset=10 on the
kernel cmd line if you really want the device bound
From: Sui Jingfeng
On a machine with multiple GPUs, a Linux user has no control over which one
is primary at boot time. This patch tries to solve the mentioned problem by
implementing the .be_primary() callback. Pass amdgpu.modeset=10 on the
kernel cmd line if you really want the device bound by
From: Sui Jingfeng
On a machine with multiple GPUs, a Linux user has no control over which one
is primary at boot time. This patch tries to solve the mentioned problem by
implementing the .be_primary() callback. Pass radeon.modeset=10 on the
kernel cmd line if you really want the device bound by
From: Sui Jingfeng
On a machine with multiple GPUs, a Linux user has no control over which one
is primary at boot time. This patch tries to solve the mentioned problem by
implementing the .be_primary() callback. VGAARB will call back to Nouveau
when the drm/nouveau gets loaded successfully.
From: Sui Jingfeng
On a machine with multiple GPUs, a Linux user has no control over which
one is primary at boot time. This series tries to solve above mentioned
problem by introduced the ->be_primary() function stub. The specific
device drivers can provide an implementation to hook up with
From: Sui Jingfeng
On a machine with multiple GPUs, a Linux user has no control over which
one is primary at boot time. This series tries to solve above mentioned
problem by introduced the ->be_primary() function stub. The specific
device drivers can provide an implementation to hook up with
snprintf() returns the "number of characters which *would* be generated for
the given input", not the size *really* generated.
In order to avoid too large values for 'str_size' (and potential negative
values for "PSOC_RAZWI_ENG_STR_SIZE - str_size") use scnprintf()
instead of snprintf().
Fixes:
On Mon, 4 Sep 2023, Thomas Weißschuh wrote:
+Cc Hans who ins involved with the backlight subsystem
Hi Julius,
today I stumbled upon a mail from Hans [0], which explains that the
backlight subsystem is not actually a good fit (yet?) for external
displays.
It seems a new API is in the works
Hi Maíra,
On 8/26/23 11:13, Maíra Canal wrote:
Hi Carlos,
On 8/25/23 13:07, Carlos Eduardo Gallo Filho wrote:
Add a single KUnit test case for the drm_framebuffer_lookup function.
Signed-off-by: Carlos Eduardo Gallo Filho
---
drivers/gpu/drm/tests/drm_framebuffer_test.c | 28
Hi Tomi
Looks good. Thanks! Tested both on Verdin AM62 as well as on Verdin iMX8M Mini.
Just a minor nit-pick in your code comment further below.
On Tue, 2023-08-22 at 19:19 +0300, Tomi Valkeinen wrote:
> The DSI horizontal timing calculations done by the driver seem to often
> lead to
Hi Tomi
Looks good. Thanks! Tested both on Verdin AM62 as well as on Verdin iMX8M Mini.
Just a minor nit-pick in your commit message.
On Fri, 2023-08-04 at 13:48 +0300, Tomi Valkeinen wrote:
> lt8912b only calls drm_bridge_hpd_enable() if it creates a connector and
> the next bridge has
A CPU job is a type of job that performs operations that requires CPU
intervention. A copy performance query job is a job that copy the complete
or partial result of a query to a buffer. In order to copy the result of
a performance query to a buffer, we need to get the values from the
performance
A CPU job is a type of job that performs operations that requires CPU
intervention. A reset performance query job is a job that resets the
performance queries by resetting the values of the perfmons. Moreover,
we also reset the syncobjs related to the availability of the query.
So, create a user
A CPU job is a type of job that performs operations that requires CPU
intervention. A copy timestamp query job is a job that copy the complete
or partial result of a query to a buffer. As V3D doesn't provide any
mechanism to obtain a timestamp from the GPU, it is a job that needs
CPU intervention.
A CPU job is a type of job that performs operations that requires CPU
intervention. A reset timestamp job is a job that resets the timestamp
queries based on the value offset of the first query. As V3D doesn't
provide any mechanism to obtain a timestamp from the GPU, it is a job
that needs CPU
A CPU job is a type of job that performs operations that requires CPU
intervention. A timestamp query job is a job that calculates the
query timestamp and updates the query availability by signaling a
syncobj. As V3D doesn't provide any mechanism to obtain a timestamp
from the GPU, it is a job
A CPU job is a type of job that performs operations that requires CPU
intervention. An indirect CSD job is a job that, when executed in the
queue, will map the indirect buffer, read the dispatch parameters, and
submit a regular dispatch. Therefore, it is a job that needs CPU
intervention.
So,
For the indirect CSD CPU job, we will need to access the internal
contents of the BO with the dispatch parameters. Therefore, create
methods to allow the mapping and unmapping of the BO.
Signed-off-by: Maíra Canal
---
drivers/gpu/drm/v3d/v3d_bo.c | 18 ++
From: Melissa Wen
Detach CSD job setup from CSD submission ioctl to reuse it in CPU
submission ioctl for indirect CSD job.
Signed-off-by: Melissa Wen
Co-developed-by: Maíra Canal
Signed-off-by: Maíra Canal
---
drivers/gpu/drm/v3d/v3d_submit.c | 52 +---
1 file
Create tracepoints to track the three major events of a CPU job
lifetime:
1. Submission of a `v3d_submit_cpu` IOCTL
2. Beginning of the execution of a CPU job
3. Ending of the execution of a CPU job
Signed-off-by: Maíra Canal
---
drivers/gpu/drm/v3d/v3d_sched.c | 4 +++
Currently, v3d_get_extensions() only parses multisync data and assigns
it to the `struct v3d_submit_ext`. But, to implement the CPU job with
user extensions, we want v3d_get_extensions() to be able to parse CPU
job data and assign it to the `struct v3d_cpu_job`.
Therefore, allow the function
From: Melissa Wen
Create a new type of job, a CPU job. A CPU job is a type of job that
performs operations that requires CPU intervention. The overall idea is
to use user extensions to enable different types of CPU job, allowing the
CPU job to perform different operations according to the type
We want to allow the IOCTLs to allocate the job without initiating it.
This will be useful for the CPU job submission IOCTL, as the CPU job has
the need to use information from the user extensions. Currently, the
user extensions are parsed before the job allocation, making it
impossible to fill
Currently, two multisync extensions can be added to the same job and
only the last multisync extension will be used. To avoid this
vulnerability, don't allow two multisync extensions in the same job.
Signed-off-by: Maíra Canal
---
drivers/gpu/drm/v3d/v3d_submit.c | 5 +
1 file changed, 5
From: Melissa Wen
Instead of checking if the job is NULL every time we call the function,
check it inside the function.
Signed-off-by: Melissa Wen
Signed-off-by: Maíra Canal
---
drivers/gpu/drm/v3d/v3d_submit.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git
From: Melissa Wen
We will include a new job submission type, the CPU job submission. For
readability and maintability, separate the job submission IOCTLs and
related operations from v3d_gem.c.
Minor fix in the CSD submission kernel doc:
CSD (texture formatting) -> CSD (compute shader).
This patchset implements the basic infrastructure for a new type of
V3D job, a CPU job. A CPU job is a job that requires CPU intervention.
It would be nice to perform this operations on the kernel space as we
can attach multiple in/out syncobjs to it.
Why we want a CPU job on the kernel?
From: Melissa Wen
IOCTLs related to BO operations reside on the file v3d_bo.c. The wait BO
ioctl is the only IOCTL regarding BOs that is placed in a different file.
So, move it to the v3d_bo.c file.
Signed-off-by: Melissa Wen
Signed-off-by: Maíra Canal
---
drivers/gpu/drm/v3d/v3d_bo.c | 33
From: Melissa Wen
v3d_mmu_get_offset header was added but the function was never defined.
Just remove it.
Signed-off-by: Melissa Wen
Signed-off-by: Maíra Canal
---
drivers/gpu/drm/v3d/v3d_drv.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/v3d/v3d_drv.h
Hi Maíra,
On 8/26/23 11:16, Maíra Canal wrote:
Hi Carlos,
On 8/25/23 13:11, Carlos Eduardo Gallo Filho wrote:
Add a single KUnit test case for the drm_framebuffer_init function.
Signed-off-by: Carlos Eduardo Gallo Filho
---
drivers/gpu/drm/tests/drm_framebuffer_test.c | 52
Hi Maíra,
On 8/26/23 11:06, Maíra Canal wrote:
Hi Carlos,
On 8/25/23 13:07, Carlos Eduardo Gallo Filho wrote:
Add a single KUnit test case for the drm_framebuffer_cleanup function.
Signed-off-by: Carlos Eduardo Gallo Filho
---
drivers/gpu/drm/tests/drm_framebuffer_test.c | 49
On Mon, 4 Sept 2023 at 19:16, Vignesh Raman wrote:
>
> Force db410c to host mode to fix network issue which results in failure
> to mount root fs via NFS.
> See
> https://gitlab.freedesktop.org/gfx-ci/linux/-/commit/cb72a629b8c15c80a54dda510743cefd1c4b65b8
>
> Use fdtoverlay command to merge
Hi Maíra,
On 8/26/23 10:58, Maíra Canal wrote:
Hi Carlos,
On 8/25/23 13:07, Carlos Eduardo Gallo Filho wrote:
Introduce a test to cover the creation of framebuffer with
modifier on a device that doesn't support it.
Signed-off-by: Carlos Eduardo Gallo Filho
---
On 2023-09-04 17:16, Boris Brezillon wrote:
On Mon, 4 Sep 2023 16:22:19 +0100
Steven Price wrote:
On 04/09/2023 10:26, Boris Brezillon wrote:
On Mon, 4 Sep 2023 08:42:08 +0100
Steven Price wrote:
On 01/09/2023 17:10, Boris Brezillon wrote:
On Wed, 9 Aug 2023 18:53:15 +0200
Boris
On Mon, 4 Sep 2023 16:22:19 +0100
Steven Price wrote:
> On 04/09/2023 10:26, Boris Brezillon wrote:
> > On Mon, 4 Sep 2023 08:42:08 +0100
> > Steven Price wrote:
> >
> >> On 01/09/2023 17:10, Boris Brezillon wrote:
> >>> On Wed, 9 Aug 2023 18:53:15 +0200
> >>> Boris Brezillon wrote:
>
Instead of modifying files in git to enable/disable
configs, use scripts/config on the .config file which
will be used for building the kernel.
Signed-off-by: Vignesh Raman
---
v2:
- Added a new patch in the series to use scripts/config to enable/disable
configs
---
Update amdgpu-stoney-fails, mediatek-mt8173-flakes,
mediatek-mt8173-fails, rockchip-rk3399-fails, rockchip-rk3399-flakes,
rockchip-rk3288-flakes, i915-cml-fails, i915-cml-flakes,
msm-apq8016-flakes files.
Add tests that fail sometimes into the *-flakes file and tests
that are failing into the
Enable the following jobs, as the issues noted in the
TODO comments have been resolved. This will ensure that these jobs
are now included and executed as part of the CI/CD pipeline.
msm:apq8016:
TODO: current issue: it is not fiding the NFS root. Fix and remove this rule.
mediatek:mt8173:
TODO:
Enable regulator
Enable MT6397 RTC driver
Signed-off-by: Vignesh Raman
---
v2:
- No changes
---
drivers/gpu/drm/ci/arm64.config | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/ci/arm64.config b/drivers/gpu/drm/ci/arm64.config
index 817e18ddfd4f..ea7a6cceff40 100644
Update ci variables to fix the below error,
ERROR - Igt error: malloc(): corrupted top size
ERROR - Igt error: Received signal SIGABRT.
ERROR - Igt error: Stack trace:
ERROR - Igt error: #0 [fatal_sig_handler+0x17b]
Signed-off-by: Vignesh Raman
---
v2:
- No changes
---
Force db410c to host mode to fix network issue which results in failure
to mount root fs via NFS.
See
https://gitlab.freedesktop.org/gfx-ci/linux/-/commit/cb72a629b8c15c80a54dda510743cefd1c4b65b8
Use fdtoverlay command to merge base device tree with an overlay
which contains the fix for USB
/sys/kernel/debug/dri/*/state exist for every atomic KMS driver.
We do not test non-atomic drivers, so remove the todo.
Signed-off-by: Vignesh Raman
---
v2:
- No changes
---
drivers/gpu/drm/ci/igt_runner.sh | 1 -
1 file changed, 1 deletion(-)
diff --git
The patch series contains improvements, enabling new ci jobs which
enables testing for Mediatek MT8173, Qualcomm APQ 8016 and VirtIO GPU,
fixing issues with the ci jobs and updating the expectation files.
This series is intended for drm branch topic/drm-ci.
v2:
- Use fdtoverlay command to merge
On 2023-08-09 17:53, Boris Brezillon wrote:
[...]
+/**
+ * struct drm_panthor_vm_create - Arguments passed to
DRM_PANTHOR_IOCTL_VM_CREATE
+ */
+struct drm_panthor_vm_create {
+ /** @flags: VM flags, MBZ. */
+ __u32 flags;
+
+ /** @id: Returned VM ID. */
+ __u32 id;
+
+
+Cc Hans who ins involved with the backlight subsystem
Hi Julius,
today I stumbled upon a mail from Hans [0], which explains that the
backlight subsystem is not actually a good fit (yet?) for external
displays.
It seems a new API is in the works that would better fit, but I'm not
sure about the
On Mon, Sep 04, 2023 at 12:41:45AM +0300, Dmitry Baryshkov wrote:
> Set the bridge's path property to point out that this connector is
> wrapped into the Type-C port.
>
> We can not really identify the exact Type-C port because it is
> registered separately, by another driver, which is not
On 04/09/2023 18:46, Bjorn Andersson wrote:
On Mon, Sep 04, 2023 at 12:41:38AM +0300, Dmitry Baryshkov wrote:
During the discussion regarding DisplayPort wrapped in the USB-C
connectors (via the USB-C altmode) it was pointed out that currently
there is no good way to let userspace know if the
On 04/09/2023 18:43, Bjorn Andersson wrote:
On Mon, Sep 04, 2023 at 12:41:45AM +0300, Dmitry Baryshkov wrote:
Set the bridge's path property to point out that this connector is
wrapped into the Type-C port.
We can not really identify the exact Type-C port because it is
registered separately,
On Mon, Sep 04, 2023 at 12:41:44AM +0300, Dmitry Baryshkov wrote:
> During discussions regarding USB-C vs native DisplayPort it was pointed
> out that other implementations (i915, AMD) are using
> DRM_MODE_CONNECTOR_DisplayPort for both native and USB-C-wrapped DP
> output. Follow this example and
On Mon, Sep 04, 2023 at 12:41:38AM +0300, Dmitry Baryshkov wrote:
> During the discussion regarding DisplayPort wrapped in the USB-C
> connectors (via the USB-C altmode) it was pointed out that currently
> there is no good way to let userspace know if the DRM connector in
> question is the
Hi,
On Fri, Sep 01, 2023 at 06:42:42AM -0700, Doug Anderson wrote:
> On Fri, Sep 1, 2023 at 1:15 AM Maxime Ripard wrote:
> > On Thu, Aug 31, 2023 at 11:18:49AM -0700, Doug Anderson wrote:
> > > Today this is explicitly _not_ refcounting, right? It is simply
> > > treating double-enables as
Thomas Zimmermann writes:
> Am 04.09.23 um 15:05 schrieb Javier Martinez Canillas:
>> Thomas Zimmermann writes:
>>
>>> Generate callback functions for struct fb_ops with the fbdev macro
>>> FB_GEN_DEFAULT_DEFERRED_SYSMEM_OPS(). Initialize struct fb_ops to
>>> the generated functions with fbdev
Thomas Zimmermann writes:
> Hi Javier
>
> Am 04.09.23 um 14:59 schrieb Javier Martinez Canillas:
>> Thomas Zimmermann writes:
>>
>> Hello Thomas,
>>
>>> Generate callback functions for struct fb_ops with the fbdev macro
>>> FB_GEN_DEFAULT_DEFERRED_SYSMEM_OPS(). Initialize struct fb_ops to
>>>
On 04/09/2023 10:26, Boris Brezillon wrote:
> On Mon, 4 Sep 2023 08:42:08 +0100
> Steven Price wrote:
>
>> On 01/09/2023 17:10, Boris Brezillon wrote:
>>> On Wed, 9 Aug 2023 18:53:15 +0200
>>> Boris Brezillon wrote:
>>>
+/**
+ * DOC: MMIO regions exposed to userspace.
+ *
On Mon, Sep 04, 2023 at 08:55:43AM +0100, Russell King (Oracle) wrote:
> On Mon, Sep 04, 2023 at 09:36:10AM +0200, Maxime Ripard wrote:
> > On Sun, Sep 03, 2023 at 04:53:42PM +0100, Russell King (Oracle) wrote:
> > > On Fri, Sep 01, 2023 at 04:41:12PM -0700, Douglas Anderson wrote:
> > > > Based
Am 04.09.23 um 16:39 schrieb Thomas Zimmermann:
[...]
At least two drivers could use __FB_DEFAULT_DEFERRED_OPS_MMAP:
picolcd-fb and hyperv_fb. At some point, we might want to set/clear
Both drivers are already in this patchset.
fb_mmap depending on some Kconfig value. Having
Of course this should be 'drm/msm/dpu: drop DPU_INTF_TE and
DPU_PINGPONG_TE' series
On 04/09/2023 05:04, Dmitry Baryshkov wrote:
rop two feature flags, DPU_INTF_TE and DPU_PINGPONG_TE, in favour of
performing the MDSS revision checks instead.
Changes since v2:
- Added guarding checks for
Am 04.09.23 um 15:05 schrieb Javier Martinez Canillas:
Thomas Zimmermann writes:
Generate callback functions for struct fb_ops with the fbdev macro
FB_GEN_DEFAULT_DEFERRED_SYSMEM_OPS(). Initialize struct fb_ops to
the generated functions with fbdev initializer macros.
Signed-off-by: Thomas
Hi Javier
Am 04.09.23 um 14:59 schrieb Javier Martinez Canillas:
Thomas Zimmermann writes:
Hello Thomas,
Generate callback functions for struct fb_ops with the fbdev macro
FB_GEN_DEFAULT_DEFERRED_SYSMEM_OPS(). Initialize struct fb_ops to
the generated functions with fbdev initializer
> -Original Message-
> From: Sebastian Wick
> Sent: Thursday, August 31, 2023 2:46 AM
> To: Shankar, Uma
> Cc: Harry Wentland ; intel-
> g...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; wayland-
> de...@lists.freedesktop.org; Ville Syrjala ;
> Pekka
> Paalanen ; Simon Ser
Hi Jocelyn,
thanks for moving this effort forward. It's much appreciated. I looked
through the patches and tried the patchset on my test machine.
Am 09.08.23 um 21:17 schrieb Jocelyn Falempe:
This introduces a new drm panic handler, which displays a message when a panic
occurs.
So when
Hi,
On 28.08.23 17:59, Michael Tretter wrote:
> Calculating the byte_clk in kHz is imprecise for a hs_clock of 55687500
> Hz, which may be used with a pixel clock of 74.25 MHz with mode
> 1920x1080-30.
>
> Fix the calculation by using HZ instead of kHZ.
>
> This requires to change the type to
> -Original Message-
> From: dri-devel On Behalf Of Pekka
> Paalanen
> Sent: Wednesday, August 30, 2023 6:30 PM
> To: Shankar, Uma
> Cc: intel-...@lists.freedesktop.org; Borah, Chaitanya Kumar
> ; dri-devel@lists.freedesktop.org; wayland-
> de...@lists.freedesktop.org
> Subject: Re:
Hi Michael,
On 28.08.23 17:59, Michael Tretter wrote:
> I tested the i.MX8M Nano EVK with the NXP supplied MIPI-DSI adapter,
> which uses an ADV7535 MIPI-DSI to HDMI converter. I found that a few
> modes were working, but in many modes my monitor stayed dark.
>
> This series fixes the Samsung
On Mon, Sep 4, 2023 at 12:16 PM Jani Nikula wrote:
>
> On Sat, 02 Sep 2023, Peter Senna Tschudin wrote:
> > Good morning Jani,
> >
> > It has been a long time since I wrote the driver, and many many years
> > since I sent my last kernel patch, so my memory does not serve me very
> > well, but I
> -Original Message-
> From: dri-devel On Behalf Of Pekka
> Paalanen
> Sent: Wednesday, August 30, 2023 5:59 PM
> To: Shankar, Uma
> Cc: intel-...@lists.freedesktop.org; Borah, Chaitanya Kumar
> ; dri-devel@lists.freedesktop.org; wayland-
> de...@lists.freedesktop.org
> Subject: Re:
Thomas Zimmermann writes:
> Generate callback functions for struct fb_ops with the fbdev macro
> FB_GEN_DEFAULT_DEFERRED_SYSMEM_OPS(). Initialize struct fb_ops to
> the generated functions with an fbdev initializer macro.
>
> Signed-off-by: Thomas Zimmermann
> ---
Acked-by: Javier Martinez
Thomas Zimmermann writes:
> Replace dynamic allocation of the fb_ops instance with static
> allocation. Initialize the fields at module-load time. The owner
> field changes to THIS_MODULE, as in all other fbdev drivers.
>
> Signed-off-by: Thomas Zimmermann
> ---
Acked-by: Javier Martinez
Thomas Zimmermann writes:
> Generate callback functions for struct fb_ops with the fbdev macro
> FB_GEN_DEFAULT_DEFERRED_SYSMEM_OPS(). Initialize struct fb_ops to
> the generated functions with an fbdev initializer macro.
>
> Signed-off-by: Thomas Zimmermann
> Cc: Jiri Kosina
> Cc: Benjamin
Thomas Zimmermann writes:
> Fix coding style in Kconfig. No functional changes.
>
> Signed-off-by: Thomas Zimmermann
> Cc: Jiri Kosina
> Cc: Benjamin Tissoires
> ---
Acked-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
On 03/09/2023 18:07, Dmitry Osipenko wrote:
> Replace Panfrost's custom memory shrinker with a common drm-shmem
> memory shrinker.
>
> Tested-by: Steven Price # Firefly-RK3288
I just gave this version of the series a spin and I can trigger the following
warning:
[ 477.776163] [
Thomas Zimmermann writes:
> Generate callback functions for struct fb_ops with the fbdev macro
> FB_GEN_DEFAULT_DEFERRED_IOMEM_OPS(). Initialize struct fb_ops to
> the generated functions with fbdev initializer macros.
>
> The hyperv_fb driver is incomplete in its handling of deferred I/O
> and
Thomas Zimmermann writes:
> The new Kconfig macro FB_IOMEM_HELPERS_DEFERRED selects fbdev's
> helpers for device I/O memory and deferred I/O. Drivers should
> use it if they perform damage updates on device I/O memory.
>
> Signed-off-by: Thomas Zimmermann
> ---
Acked-by: Javier Martinez
On Mon, Sep 04, 2023 at 01:04:40PM +0300, Jani Nikula wrote:
> On Sat, 02 Sep 2023, Peter Senna Tschudin wrote:
> > Good morning Jani,
> >
> > It has been a long time since I wrote the driver, and many many years
> > since I sent my last kernel patch, so my memory does not serve me very
> > well,
Thomas Zimmermann writes:
> Generate callback functions for struct fb_ops with the fbdev macro
> FB_GEN_DEFAULT_DEFERRED_SYSMEM_OPS(). Initialize struct fb_ops to
> the generated functions with fbdev initializer macros.
>
> Signed-off-by: Thomas Zimmermann
> Cc: Bernie Thompson
> ---
Thomas Zimmermann writes:
Hello Thomas,
> Generate callback functions for struct fb_ops with the fbdev macro
> FB_GEN_DEFAULT_DEFERRED_SYSMEM_OPS(). Initialize struct fb_ops to
> the generated functions with fbdev initializer macros.
>
> Signed-off-by: Thomas Zimmermann
> Cc: Steve Glendinning
Quoting Kieran Bingham (2023-09-03 16:23:46)
> Hi Alexandra
>
> Quoting Alexandra Diupina (2023-09-03 14:37:09)
> > rcar_du_group_get() never returns a negative
> > error code (always returns 0), so change
> > the comment about returned value
>
> If so, then perhaps this may as well become a
Reviewed-by: Alexandre Mergnat
On 22/08/2023 15:26, Jason-JH.Lin wrote:
Add spinlock protection to avoid race condition on vblank event
between mtk_drm_crtc_atomic_begin() and mtk_drm_finish_page_flip().
--
Regards,
Alexandre
1 - 100 of 157 matches
Mail list logo
