As we can now acquire the presence of the full DMA coherency (snooping
capability) from ttm_device, we can now map the CPU side memory as
write-combined when cached is requested and snooping is not avilable.
Signed-off-by: Icenowy Zheng
---
drivers/gpu/drm/ttm/ttm_bo_util.c | 4
drivers/gpu
Currently TTM utilizes cached memory regardless of whether the device
have full DMA coherency (can snoop CPU cache).
Save the device's DMA coherency status in struct ttm_device, to allow
further support of devices w/o snooping capability (the capability
missing on at least one part of the transmis
This patchset tries to make TTM support devices w/o full DMA coherency
capability (usually due to part of the link between the device and the
CPU, esp. PCIe controller, do not have full coherency).
The patchset itself looks quite straightforward, however I don't know
why this isn't included in the
On 6/23/24 01:51, Thomas Weißschuh wrote:
Panels using a PWM-controlled backlight source without an do not have a
standard way to communicate their valid PWM ranges.
On x86 the ranges are read from ACPI through driver-specific tables.
The built-in ranges are not necessarily correct, or may grow s
On 6/15/2024 2:01 PM, Jeff Johnson wrote:
> With ARCH=powerpc, make allmodconfig && make W=1 C=1 reports:
> WARNING: modpost: missing MODULE_DESCRIPTION() in
> drivers/char/agp/uninorth-agp.o
>
> Add the missing invocation of the MODULE_DESCRIPTION() macro.
>
> Signed-off-by: Jeff Johnson
> ---
On Sat, Jun 29, 2024 at 01:49:53AM +0200, Jakob L wrote:
> Hi John,
>
> good find! This seems to fix it on my DSI implementation. Every of the
> recent boots resulted in a pink tint (usually it was green for me, or blue)
> Booted 10 times - no tint.
>
> So this patch is good, but probably has to
On Sat, Jun 29, 2024 at 07:19:33AM +0530, Akhil P Oommen wrote:
> This series adds support for the Adreno X1-85 GPU found in Qualcomm's
> compute series chipset, Snapdragon X1 Elite (x1e80100). In this new
> naming scheme for Adreno GPU, 'X' stands for compute series, '1' denotes
> 1st generation a
On Tue, Jun 18, 2024 at 09:42:47AM -0700, Rob Clark wrote:
> From: Rob Clark
>
> Split into a separate table per generation, in preparation to move each
> gen's device table to it's own file.
>
> Signed-off-by: Rob Clark
> Reviewed-by: Dmitry Baryshkov
> Reviewed-by: Konrad Dybcio
> ---
> dr
Add the necessary dt nodes for gpu support in X1E80100.
Signed-off-by: Akhil P Oommen
---
Changes in v2:
- Reordered gpu & gmu reg enties to match schema
arch/arm64/boot/dts/qcom/x1e80100.dtsi | 195 +
1 file changed, 195 insertions(+)
diff --git a/arch/arm64/boot/dts/
Update the devicetree bindings to support the gpu present in
X1E80100 platform.
Signed-off-by: Akhil P Oommen
---
Changes in v2:
- New patch in v2
Documentation/devicetree/bindings/iommu/arm,smmu.yaml | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetre
To simplify, introduce the new gmu_chipid for a740 & a750 GPUs.
Signed-off-by: Akhil P Oommen
---
Changes in v2:
- New patch in v2
drivers/gpu/drm/msm/adreno/a6xx_catalog.c | 2 ++
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 23 +--
2 files changed, 3 insertions(+), 22 del
Document Adreno X185 GMU in the dt-binding specification.
Signed-off-by: Akhil P Oommen
Reviewed-by: Krzysztof Kozlowski
---
Changes in v2:
- Minor update to compatible pattern, '[x]' -> 'x'
Documentation/devicetree/bindings/display/msm/gmu.yaml | 4
1 file changed, 4 insertions(+)
diff
Add support in drm/msm driver for the Adreno X185 gpu found in
Snapdragon X1 Elite chipset.
Signed-off-by: Akhil P Oommen
---
Changes in v2:
- Increased address space size (Rob)
- Introduced gmu_chipid in a6xx_info (Rob)
- Improved fallback logic for gmxc (Dmitry)
drivers/gpu/drm/msm/adreno/a6
This series adds support for the Adreno X1-85 GPU found in Qualcomm's
compute series chipset, Snapdragon X1 Elite (x1e80100). In this new
naming scheme for Adreno GPU, 'X' stands for compute series, '1' denotes
1st generation and '8' & '5' denotes the tier and the SKU which it
belongs.
X1-85 has m
On QCM2290 chipset DPU does not support UBWC.
Add a dpu cap to indicate this and do not expose compressed formats
in this case.
changes since RFC:
- use ubwc enc and dec version of mdss_data instead of catalog
to decide if ubwc is supported
Signed-off-by: Abhinav Kumar
---
dr
On 6/28/2024 15:58, Matthew Schwartz wrote:
From: John Schoenick
Valve's Steam Deck Galileo revision has a 800x1280 OLED panel
Signed-off-by: John Schoenick
Signed-off-by: Matthew Schwartz
Thanks!
Reviewed-by: Mario Limonciello
---
drivers/gpu/drm/drm_panel_orientation_quirks.c | 7 +
Switch msm_kms to use msm_iommu_disp_new() so that the newly
registered fault handler will kick-in during any mmu faults.
Signed-off-by: Abhinav Kumar
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/msm_kms.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/
There is no recovery mechanism in place yet to recover from mmu
faults for DPU. We can only prevent the faults by making sure there
is no misconfiguration.
Rate-limit the snapshot capture for mmu faults to once per
msm_kms_init_aspace() as that should be sufficient to capture
the snapshot for debu
In preparation to register a iommu fault handler for display
related modules, register a fault handler for the backing
mmu object of msm_kms.
Currently, the fault handler only captures the display snapshot
but we can expand this later if more information needs to be
added to debug display mmu faul
In preparation of registering a separate fault handler for
display, lets rename the existing msm_fault_handler to
msm_gpu_fault_handler.
Signed-off-by: Abhinav Kumar
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/msm_iommu.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
di
Introduce a new API msm_iommu_disp_new() for display use-cases.
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/msm/msm_iommu.c | 26 ++
drivers/gpu/drm/msm/msm_mmu.h | 1 +
2 files changed, 27 insertions(+)
diff --git a/drivers/gpu/drm/msm/msm_iommu.c b/drivers/gpu/
To debug display mmu faults, this series introduces a display fault
handler similar to the gpu one.
This series has been tested on sc7280 chromebook by using triggering
a smmu fault by forcing an incorrect stride on the planes.
changes since RFC:
- move msm_mmu_set_fault_handler() to msm_
To debug display mmu faults, this series introduces a display fault
handler similar to the gpu one.
This series has been tested on sc7280 chromebook by using triggering
a smmu fault by forcing an incorrect stride on the planes.
changes since RFC:
- move msm_mmu_set_fault_handler() to msm_
On Fri, Jun 28, 2024 at 04:55:36PM +0200, Boris Brezillon wrote:
> A sync-only job is meant to provide a synchronization point on a
> queue, so we can't return a NULL fence there, we have to add a signal
> operation to the command stream which executes after all other
> previously submitted jobs ar
Hi Dave, Sima,
More stuff for 6.11.
The following changes since commit a78313bb206e0c456a989f380c4cbd8af8af7c76:
Merge tag 'drm-intel-gt-next-2024-06-12' of
https://gitlab.freedesktop.org/drm/i915/kernel into drm-next (2024-06-27
17:21:44 +1000)
are available in the Git repository at:
ht
This accounts for the existence of two Steam Deck revisions
instead of a single revision
Signed-off-by: Matthew Schwartz
Reviewed-by: Mario Limonciello
---
drivers/gpu/drm/drm_panel_orientation_quirks.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_
From: John Schoenick
Valve's Steam Deck Galileo revision has a 800x1280 OLED panel
Signed-off-by: John Schoenick
Signed-off-by: Matthew Schwartz
---
drivers/gpu/drm/drm_panel_orientation_quirks.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/drm_panel_orientation_
This is a series of 2 patches.
The first patch is from Valve's public kernel
source tree. It adds a panel rotation quirk for Valve's Steam Deck Galileo
revision, which has an 800x1280 OLED panel. The previous Steam Deck panel
orientation quirk does not apply to the Galileo revision's DMI. I have
Hi Thierry,
Le vendredi 28 juin 2024 à 16:11 +0200, Thierry Reding a écrit :
> On Fri, Jun 28, 2024 at 03:21:51PM GMT, mrip...@kernel.org wrote:
> > On Fri, Jun 28, 2024 at 01:47:01PM GMT, Thierry Reding wrote:
> > > On Thu, Jun 27, 2024 at 04:40:02PM GMT, mrip...@kernel.org wrote:
> > > > On Thu,
Hi,
Le jeudi 27 juin 2024 à 16:40 +0200, mrip...@kernel.org a écrit :
> > You can trivially say during use hey this buffer is encrypted.
> >
> > At least that's my 10 mile high view, maybe I'm missing some extensive key
> > exchange or something like that.
>
> That doesn't work in all cases, unf
Hi Christian,
Le jeudi 27 juin 2024 à 08:57 +0200, Christian König a écrit :
> Am 27.06.24 um 05:21 schrieb Jason-JH Lin (林睿祥):
> >
> > On Wed, 2024-06-26 at 19:56 +0200, Daniel Vetter wrote:
> > >
> > > External email : Please do not click links or open attachments until
> > > you have verifi
Introduce a version of the fence ops that on release doesn't remove
the fence from the pending list, and thus doesn't require a lock to
fix poll->fence wait->fence unref deadlocks.
vmwgfx overwrites the wait callback to iterate over the list of all
fences and update their status, to do that it hol
Fix races issues in virtual crc generation by making sure the surface
the code uses for crc computation is properly ref counted.
Crc generation was trying to be too clever by allowing the surfaces
to go in and out of scope, with the hope of always having some kind
of screen present. That's not alw
Dumb buffers can be used in kms but also through prime with gallium's
resource_from_handle. In the second case the dumb buffers can be
rendered by the GPU where with the regular DRM kms interfaces they
are mapped and written to by the CPU. Because the same buffer can
be written to by the GPU and CP
Make vmwgfx go through the dma-buf interface to map/unmap imported
buffers. The driver used to try to directly manipulate external
buffers, assuming that everything that was coming to it had to live
in cpu accessible memory. While technically true because what's in the
vms is controlled by us, it's
This small series fixes all known prime/dumb_buffer/buffer dirty
tracking issues. Fixing of dumb-buffers turned out to be a lot more
complex than I wanted it to be. There's not much that can be done
there because the driver has to support old userspace (our Xorg driver
expects those to not be gem b
On Fri, Jun 28, 2024 at 04:55:35PM +0200, Boris Brezillon wrote:
> The user is likely to leave all the drm_panthor_obj_array fields
> to zero when the array is empty, which will cause an EINVAL failure.
>
> Fixes: 4bdca1150792 ("drm/panthor: Add the driver frontend block")
> Signed-off-by: Boris B
This is a bit of a weird response on my part, apologies, but I just
want to make sure of one thing before I stop paying attention to this
thread.
On Fri, 2024-06-28 at 21:02 +0200, Markus Elfring wrote:
> > Because the responses you have been given read like a bot,
>
> I find it interesting that
> Because the responses you have been given read like a bot,
I find it interesting that you interpret provided information
in such a direction.
>and numerous
> actual contributors and kernel maintainers like myself and Greg have
> asked
Hello,
On the T113 (and most likely the D1) sometimes the RGB LCD output has strange
artifacts such as:
- A blue tint
- A mostly opaque green tint
- A red tint
- A pink tint
The actual tint seems to differ between boards or chips, and has some
probability of showing up that can range from 50% to
Hi Thomas,
FYI, this doesn't fix the issue of lightdm not being able to start for me.
Marek
Marek
On Tue, Jun 25, 2024 at 4:18 AM Thomas Zimmermann wrote:
>
> Retrieving the system framebuffer's parent device in sysfb_init()
> increments the parent device's reference count. Hence release the
On Fri, 2024-06-28 at 20:42 +0200, Markus Elfring wrote:
> > (...I doubt I'll get a response from Markus,
>
> Why?
Because the responses you have been given read like a bot, and numerous
actual contributors and kernel maintainers like myself and Greg have
asked you to stop leaving messages like t
> (...I doubt I'll get a response from Markus,
Why?
> but I certainly want to
> make sure they are a bot
Can I ever adjust your views into more desirable directions
(as it occasionally happened with other contributors)?
> a
Use multi style wrapped functions for mipi_dsi in the
startek-kd070fhfid015 panel.
Signed-off-by: Tejas Vipin
---
.../drm/panel/panel-startek-kd070fhfid015.c | 107 ++
1 file changed, 35 insertions(+), 72 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-startek-kd070fhfid
Add more functions that can benefit from being multi style, which
reduces code size in panels where they appear.
Signed-off-by: Tejas Vipin
---
drivers/gpu/drm/drm_mipi_dsi.c | 164 +
include/drm/drm_mipi_dsi.h | 10 ++
2 files changed, 174 insertions(+)
dif
This series adds more multi style functions and uses them in the
startek-kd070fhfid015 panel effectively.
Tejas Vipin (2):
drm/mipi-dsi: add more multi functions for better error handling
drm/panel: startek-kd070fhfid015: transition to mipi_dsi wrapped
functions
drivers/gpu/drm/drm_mipi
Sorry, didn't intend to send this. please ignore it :p
On 6/28/24 11:42 PM, Tejas Vipin wrote:
> Use functions introduced in commit 966e397e4f60 ("drm/mipi-dsi:
> Introduce mipi_dsi_*_write_seq_multi()") and commit f79d6d28d8fe
> ("drm/mipi-dsi: wrap more functions for streamline handling") for th
On Fri, Jun 28, 2024 at 03:51:33PM +, Matthew Brost wrote:
> On Fri, Jun 28, 2024 at 05:38:48PM +0200, Thomas Hellström wrote:
> > Bos can be put with multiple unrelated dma-resv locks held. But
> > imported bos attempt to grab the bo dma-resv during dma-buf detach
> > that typically happens du
Use functions introduced in commit 966e397e4f60 ("drm/mipi-dsi:
Introduce mipi_dsi_*_write_seq_multi()") and commit f79d6d28d8fe
("drm/mipi-dsi: wrap more functions for streamline handling") for the
asus-z00t-tm5p5-n35596 panel.
Signed-off-by: Tejas Vipin
---
.../drm/panel/panel-asus-z00t-tm5p5-
On Fri, Jun 28, 2024 at 12:21:32PM +0300, Jani Nikula wrote:
> On Fri, 28 Jun 2024, Dmitry Baryshkov wrote:
> > On Thu, Jun 27, 2024 at 09:26:19PM GMT, Jani Nikula wrote:
> >> On Thu, 27 Jun 2024, Jani Nikula wrote:
> >> > On Wed, 26 Jun 2024, Dmitry Baryshkov
> >> > wrote:
> >> >> In order to
On Thu, Jun 27, 2024 at 02:18:44PM +0200, Thomas Hellström wrote:
> On Thu, 2024-06-27 at 10:04 +0200, Daniel Vetter wrote:
> > On Wed, Jun 26, 2024 at 05:58:02PM +0200, Thomas Hellström wrote:
> > > Hi!
> > >
> > > I'm seeing the below lockdep splat 1) with the xe driver in an
> > > imported
> >
On Fri, Jun 28, 2024 at 07:58:23PM +0200, Michal Wajdeczko wrote:
> On 28.06.2024 19:03, Mark Brown wrote:
> > /tmp/next/build/drivers/gpu/drm/xe/xe_gt_sriov_pf_config.c: In function
> > 'pf_get_threshold':
> > /tmp/next/build/drivers/gpu/drm/xe/xe_gt_sriov_pf_config.c:1788:27: error:
> > unused
On Thu, Jun 27, 2024 at 09:18:15AM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 26.06.24 um 19:59 schrieb Daniel Vetter:
> > On Wed, Jun 26, 2024 at 11:01:11AM +0200, Thomas Zimmermann wrote:
> > > Hi
> > >
> > > Am 26.06.24 um 06:34 schrieb Dmitry Baryshkov:
> > > > On Tue, Jun 25, 2024 at 03:18:
On 6/27/24 5:17 PM, Matthew Schwartz wrote:
On Thu, Jun 27, 2024 at 2:28 PM Hamza Mahfooz wrote:
On 6/27/24 16:30, Matthew Schwartz wrote:
From: John Schoenick
Since this patch is from John, you would need his S-o-b in here as well
(assuming you have his permission to add it).
This patch
On 28.06.2024 19:03, Mark Brown wrote:
> Hi all,
>
> After merging the drm tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> /tmp/next/build/drivers/gpu/drm/xe/xe_gt_sriov_pf_config.c: In function
> 'pf_get_threshold':
> /tmp/next/build/drivers/gpu/drm/xe/xe_gt_srio
Reviewed-by: Lyude Paul
Will push this upstream in just a moment, thanks!
On Thu, 2024-06-27 at 10:27 +0800, Ma Ke wrote:
> In nouveau_connector_get_modes(), the return value of
> drm_mode_duplicate()
> is assigned to mode, which will lead to a possible NULL pointer
> dereference on failure of d
On Fri, Jun 28, 2024 at 03:57:49PM +0200, Thierry Reding wrote:
> On Fri, Jun 28, 2024 at 02:34:24PM GMT, Christian König wrote:
> > Am 28.06.24 um 13:47 schrieb Thierry Reding:
> > > [SNIP]
> > > > > The reason I ask is that encryption here looks just like another
> > > > > parameter
> > > > > fo
Ma Ke - I assume you already know but you can just ignore this message
from Markus as it is just spam. Sorry about the trouble!
Markus, you've already been asked by Greg so I will ask a bit more
sternly in case there is actually a person on the other end: you've
already been asked to stop by Greg
On Wed, Jun 26, 2024 at 08:26:04PM +0100, Daniel Stone wrote:
> On Wed, 26 Jun 2024 at 18:52, Daniel Vetter wrote:
> > On Wed, Jun 26, 2024 at 11:39:01AM +0100, Daniel Stone wrote:
> > > On Wed, 26 Jun 2024 at 09:28, Lucas Stach wrote:
> > > > So we are kind of stuck here between breaking one or
On Thu, Jun 27, 2024 at 11:51:37AM -0700, Rob Clark wrote:
> On Wed, Jun 26, 2024 at 10:47 AM Daniel Vetter wrote:
> >
> > On Wed, Jun 26, 2024 at 11:38:30AM +0300, Dmitry Baryshkov wrote:
> > > On Wed, Jun 26, 2024 at 09:32:44AM GMT, Daniel Vetter wrote:
> > > > On Mon, Jun 24, 2024 at 10:25:25AM
On Thu, 2024-06-27 at 09:04 +, Lin, Wayne wrote:
>
> I understand your concern. My patch will just check whether mst
> manager starts
> the probing process or not by confirming whether we sent LINK_ADDRESS
> to
> the 1st mst branch already. It will drop the CSN event only when the
> event come
On Fri, Jun 28, 2024 at 10:24:52AM -0700, Elliot Berman wrote:
> On Tue, Jun 25, 2024 at 08:28:06PM +0200, Konrad Dybcio wrote:
> > On recent (SM8550+) Snapdragon platforms, the GPU speed bin data is
> > abstracted through SMEM, instead of being directly available in a fuse.
> >
> > Add support fo
On Tue, Jun 25, 2024 at 08:28:06PM +0200, Konrad Dybcio wrote:
> On recent (SM8550+) Snapdragon platforms, the GPU speed bin data is
> abstracted through SMEM, instead of being directly available in a fuse.
>
> Add support for SMEM-based speed binning, which includes getting
> "feature code" and "
Hi all,
After merging the drm tree, today's linux-next build (x86_64
allmodconfig) failed like this:
/tmp/next/build/drivers/gpu/drm/xe/xe_gt_sriov_pf_config.c: In function
'pf_get_threshold':
/tmp/next/build/drivers/gpu/drm/xe/xe_gt_sriov_pf_config.c:1788:27: error:
unused variable 'xe' [-Werr
Hi all,
Today's linux-next merge of the drm tree got a conflict in:
drivers/gpu/drm/xe/xe_gt_idle.c
between commit:
2470b141bfae2 ("drm/xe: move disable_c6 call")
from the origin tree and commits:
6800e63cf97ba ("drm/xe: move disable_c6 call")
38e8c4184ea0e ("drm/xe: Enable Coarse Pow
Dump the DSC state to dmesg during HW readout and state computation as
well as the i915_display_info debugfs entry.
v2: Rebase on the s/DRM_X16/FXP_Q4 change.
Signed-off-by: Imre Deak
---
.../drm/i915/display/intel_crtc_state_dump.c | 3 +++
.../drm/i915/display/intel_display_debugfs.c | 4
The Display Engine's DSC register values are deducted from the DSC
configuration stored in intel_crtc_state::dsc. The latter one is
dumped in a human-readable format, so dumping the register values is
redundant, remove it.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/display/intel_vdsc.c |
Replace the to_bpp_frac() helper defined by the driver with the
equivalent fxp_q4_to_frac() helper defined by DRM core.
v2: Rebase on the s/drm_x16/fxp_q4 change.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/display/intel_display_types.h | 7 +--
drivers/gpu/drm/i915/display/intel_dp.c
Replace the BPP_X16_FMT()/ARGS() helpers defined by the driver with the
equivalent FXP_Q4_FMT()/ARGS() helpers defined by DRM core.
v2: Rebase on the s/DRM_X16/FXP_Q4 change.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/display/intel_audio.c | 5 +++--
drivers/gpu/drm/i915/display/i
Replace the to_bpp_int_roundup() helper defined by the driver with the
equivalent fxp_q4_to_int_roundup() helper defined by DRM core.
v2: Rebase on s/drm_x16/fxp_q4 change.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/display/intel_cdclk.c | 5 -
drivers/gpu/drm/i915/display/in
Replace the to_bpp_x16() helper defined by the driver with the
equivalent fxp_q4_from_int() helper defined by DRM core.
v2: Rebase on the s/drm_x16/fxp_q4 change.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/display/intel_bios.c | 5 +++--
.../gpu/drm/i915/display/intel_display_type
Replace the to_bpp_int() helper defined by the driver with the
equivalent fxp_q4_to_int() helper defined by DRM core.
v2: Rebase on the s/drm_x16/fxp_q4 change.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/display/icl_dsi.c | 9 +
drivers/gpu/drm/i915/display/intel_disp
Add a helper to dump the Display Stream Compression configuration, taken
into use in the i915 driver by a later patch.
v2:
- Rebase on the s/DRM_X16/FXP_Q4 change.
- s/DSC configration/DSC configuration in the function documentation.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/display/drm_dsc_
Add helpers to convert between q4 fixed point and integer/fraction
values. Also add the format/argument macros required to printk q4 fixed
point variables. The q4 notation is based on the short variant described
by
https://en.wikipedia.org/wiki/Q_(number_format)
where only the number of fraction
This is v2 of [1], renaming the helpers from drm_x16 to fxp_q4 as
suggested by Jani.
[1] https://lore.kernel.org/all/20240614173911.3743172-1-imre.d...@intel.com
Cc: Jani Nikula
Imre Deak (9):
drm: Add helpers for q4 fixed point values
drm/display/dsc: Add a helper to dump the DSC configura
On Fri, Jun 28, 2024 at 09:13:11AM +0200, Jocelyn Falempe wrote:
> It is present in the kdump log, but before all the register dumps.
> So to retrieve it you need to parse the last 30~40 lines of logs, and search
> for a line starting with "Kernel panic - not syncing".
> https://elixir.bootlin.com/
Hi Jani,
On Fri, Jun 28, 2024 at 10:45:48AM +0300, Jani Nikula wrote:
> Might be helpful to actually point at the source code or commits or
> something.
The source code is here: drivers/gpu/drm/panel/panel-newvision-nv3052c.c
It's just a standard MIPI DBI panel. It reports using an RGB888 bus for
On Fri, Jun 28, 2024 at 02:10:15PM +0900, Hironori KIKUCHI wrote:
> The RG28XX panel is a display panel of the Anbernic RG28XX, a handheld
> gaming device from Anbernic. It is 2.8 inches in size (diagonally) with
> a resolution of 480x640.
>
> This panel is driven by a variant of the ST7701 driver
On Fri, Jun 28, 2024 at 05:38:48PM +0200, Thomas Hellström wrote:
> Bos can be put with multiple unrelated dma-resv locks held. But
> imported bos attempt to grab the bo dma-resv during dma-buf detach
> that typically happens during cleanup. That leads to lockde splats
> similar to the below and a
Bos can be put with multiple unrelated dma-resv locks held. But
imported bos attempt to grab the bo dma-resv during dma-buf detach
that typically happens during cleanup. That leads to lockde splats
similar to the below and a potential ABBA deadlock.
Fix this by always taking the delayed workqueue
From: Konrad Dybcio
Add support for MSM8996, which - fun fact - was the SoC that this driver
(or rather SDE, its downstream origin) was meant for and first tested on.
It has some hardware that differs from the modern SoCs, so not a lot of
current structs could have been reused. It's also seeming
From: Dmitry Baryshkov
Add support for MSM8953, which has MDP5 v1.16. It looks like
trimmed down version of MSM8996. Less SSPP, LM and PP blocks. No DSC,
etc.
Signed-off-by: Dmitry Baryshkov
[Remove intr_start from CTLs config, reword the commit]
Signed-off-by: Barnabás Czémán
---
.../drm/msm
This patch series add dpu support for MSM8996/MSM8953 devices.
Note, by default these platforms are still handled by the MDP5 driver
unless the `msm.prefer_mdp5=false' parameter is provided.
Signed-off-by: Barnabás Czémán
---
Dmitry Baryshkov (1):
drm/msm/dpu: add support for MSM8953
Konr
On Fri, Jun 21, 2024 at 6:45 AM Mikhail Gavrilov
wrote:
>
> On Fri, Jun 21, 2024 at 12:56 PM Linux regression tracking (Thorsten
> Leemhuis) wrote:
> > Hmmm, I might have missed something, but it looks like nothing happened
> > here since then. What's the status? Is the issue still happening?
>
>
The user is likely to leave all the drm_panthor_obj_array fields
to zero when the array is empty, which will cause an EINVAL failure.
Fixes: 4bdca1150792 ("drm/panthor: Add the driver frontend block")
Signed-off-by: Boris Brezillon
---
drivers/gpu/drm/panthor/panthor_drv.c | 6 +++---
1 file cha
A sync-only job is meant to provide a synchronization point on a
queue, so we can't return a NULL fence there, we have to add a signal
operation to the command stream which executes after all other
previously submitted jobs are done.
Fixes: de8548813824 ("drm/panthor: Add the scheduler logical blo
Hello,
Here are two relatively trivial fixes for bugs found while woking
on the Vulkan implementation, where NULL CS are needed to implement
VkQueue synchronization.
Regards,
Boris
Boris Brezillon (2):
drm/panthor: Don't check the array stride on empty uobj arrays
drm/panthor: Fix sync-only
Hi Dave & Sima -
Another feature pull towards v6.11, hopefully last. This should also fix
the 32-bit build issue [1] seen in drm-next.
BR,
Jani.
[1]
https://lore.kernel.org/r/CAPM=9tyNGA2wEgnsKdSyjHRGVikywZLdueZj=sytmfyeunz...@mail.gmail.com
drm-intel-next-2024-06-28:
drm/i915 feature pull
On Fri, Jun 28, 2024 at 03:08:46PM GMT, Maxime Ripard wrote:
> Hi,
>
> On Fri, Jun 28, 2024 at 01:29:17PM GMT, Thierry Reding wrote:
> > On Tue, May 21, 2024 at 02:06:19PM GMT, Daniel Vetter wrote:
> > > On Thu, May 16, 2024 at 09:51:35AM -0700, John Stultz wrote:
> > > > On Thu, May 16, 2024 at 3
On Fri, Jun 28, 2024 at 04:12:10PM +0530, Ekansh Gupta wrote:
>
>
> On 6/28/2024 3:59 PM, Ekansh Gupta wrote:
> >
> > On 6/27/2024 4:43 PM, Dmitry Baryshkov wrote:
> >> On Thu, Jun 27, 2024 at 11:35:18AM GMT, Ekansh Gupta wrote:
> >>> For user PD initialization, initmem is allocated and sent to D
Hello,
On Fri, Jun 28, 2024 at 01:46:32PM +, Chun-Kuang Hu wrote:
> Hi, Dave & Daniel:
>
> This includes:
>
> 1. Convert to platform remove callback returning void
Note that this change (commit f5d5759d29e93fa76466204ad34169b3900a36c6)
is already in next (as commit 573a39d05053cb234a9ac3c7b
On Fri, Jun 28, 2024 at 03:21:51PM GMT, mrip...@kernel.org wrote:
> On Fri, Jun 28, 2024 at 01:47:01PM GMT, Thierry Reding wrote:
> > On Thu, Jun 27, 2024 at 04:40:02PM GMT, mrip...@kernel.org wrote:
> > > On Thu, Jun 27, 2024 at 08:57:40AM GMT, Christian König wrote:
> > > > Am 27.06.24 um 05:21 s
On Thu, Jun 27, 2024 at 06:41:46PM +0300, Jani Nikula wrote:
> On Wed, 19 Jun 2024, Imre Deak wrote:
> > On Wed, Jun 19, 2024 at 01:10:09PM +0300, Jani Nikula wrote:
> >> On Fri, 14 Jun 2024, Imre Deak wrote:
> >> > Add helpers to convert between x16 fixed point and integer/fraction
> >> > values
Hi,
On Thu, Jun 27, 2024 at 09:22:56PM GMT, Maarten Lankhorst wrote:
> Den 2024-06-27 kl. 19:16, skrev Maxime Ripard:
> > Hi,
> >
> > Thanks for working on this!
> >
> > On Thu, Jun 27, 2024 at 05:47:21PM GMT, Maarten Lankhorst wrote:
> > > The initial version was based roughly on the rdma and m
On Fri, Jun 28, 2024 at 02:34:24PM GMT, Christian König wrote:
> Am 28.06.24 um 13:47 schrieb Thierry Reding:
> > [SNIP]
> > > > The reason I ask is that encryption here looks just like another
> > > > parameter
> > > > for the buffer, e.g. like format, stride, tilling etc..
> > > >
> > > > So in
Hi, Dave & Daniel:
This includes:
1. Convert to platform remove callback returning void
2. Drop chain_mode_fixup call in mode_valid()
3. Fixes the errors of MediaTek display driver found by IGT.
4. Add display support for the MT8365-EVK board
5. Fix bit depth overwritten for mtk_ovl_set bit_depth
1-20240627
(https://download.01.org/0day-ci/archive/20240628/202406282158.ogy7xnu2-...@intel.com/config)
compiler: clang version 19.0.0git (https://github.com/llvm/llvm-project
ad79a14c9e5ec4a369eed4adf567c22cc029863f)
dtschema version: 2024.6.dev3+g650bf2d
reproduce (this is a W=1 build):
(https:
On Fri, Jun 28, 2024 at 01:42:27PM GMT, Christian König wrote:
> Am 27.06.24 um 16:40 schrieb mrip...@kernel.org:
> > [SNIP]
> > > > > > > > Why can't you get this information from userspace?
> > > > > > Same reason amd and i915/xe also pass this around internally in the
> > > > > kernel, it's just
On 6/21/24 16:55, Yannick FERTRE wrote:
Hi Raphaël,
Thanks for your patch, it will not merged due to a new clock management.
Philippe,
this patch will be replaced by another which manages all clocks that the
display controller
will need (pixel clock, bus clock reference clock).
Hi Rap
On Fri, Jun 28, 2024 at 01:47:01PM GMT, Thierry Reding wrote:
> On Thu, Jun 27, 2024 at 04:40:02PM GMT, mrip...@kernel.org wrote:
> > On Thu, Jun 27, 2024 at 08:57:40AM GMT, Christian König wrote:
> > > Am 27.06.24 um 05:21 schrieb Jason-JH Lin (林睿祥):
> > > >
> > > > On Wed, 2024-06-26 at 19:56 +0
1 - 100 of 182 matches
Mail list logo
