Hello:
This series was applied to netdev/net-next.git (main)
by Jakub Kicinski :
On Wed, 3 Apr 2024 10:06:18 +0200 you wrote:
> From: Arnd Bergmann
>
> Compilers traditionally warn for unused 'static' variables, but not
> if they are constant. The reason here is a custom for C++ programmers
>
On Fri, Apr 05, 2024 at 08:14:11PM -0700, Bjorn Andersson wrote:
> Now that the connector_type is dynamically determined, the
> connector_type of the struct msm_dp_desc is unused. Clean it up.
>
> Remaining duplicate entries are squashed.
>
> Signed-off-by: Bjorn Andersson
> ---
> This cleans
On Fri, Apr 05, 2024 at 10:41:28AM +0200, Konrad Dybcio wrote:
> Newer (SM8550+) SoCs don't seem to have a nice speedbin fuse anymore,
> but instead rely on a set of combinations of "feature code" (FC) and
> "product code" (PC) identifiers to match the bins. This series adds
> support for that.
>
On Fri, Apr 05, 2024 at 10:41:33AM +0200, Konrad Dybcio wrote:
> Add speebin data for A740, as found on SM8550 and derivative SoCs.
>
> Signed-off-by: Konrad Dybcio
> ---
> drivers/gpu/drm/msm/adreno/adreno_device.c | 14 ++
> 1 file changed, 14 insertions(+)
>
> diff --git
On Fri, Apr 05, 2024 at 10:41:32AM +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
From: Kuogee Hsieh
For HPD events coming from external modules using drm_bridge_hpd_notify(),
the sequence of calls leading to dp_bridge_hpd_notify() is like below:
dp_bridge_hpd_notify+0x18/0x70 [msm]
drm_bridge_connector_detect+0x60/0xe8 [drm_kms_helper]
drm_helper_probe_detect+0x94/0xc0
Now that the connector_type is dynamically determined, the
connector_type of the struct msm_dp_desc is unused. Clean it up.
Remaining duplicate entries are squashed.
Signed-off-by: Bjorn Andersson
---
This cleans up after, and hence depends on,
On Fri, Apr 05, 2024 at 10:41:31AM +0200, Konrad Dybcio wrote:
> From: Neil Armstrong
>
> Usually, speedbin 0 is the "super SKU", a.k.a the one which can clock
> the highest. Falling back to it when things go wrong is largely
> suboptimal, as more often than not, the top frequencies are not
>
On Fri, Apr 05, 2024 at 10:41:29AM +0200, Konrad Dybcio wrote:
> In preparation for parsing the chip "feature code" (FC) and "product
> code" (PC) (essentially the parameters that let us conclusively
> characterize the sillicon we're running on, including various speed
> bins), move the socinfo
On Fri, Apr 05, 2024 at 10:41:30AM +0200, Konrad Dybcio wrote:
> Introduce getters for SoC product and feature codes and export them.
>
> Signed-off-by: Konrad Dybcio
> ---
> drivers/soc/qcom/smem.c | 66
> +++
> include/linux/soc/qcom/smem.h | 2
On Fri, Apr 05, 2024 at 05:17:14PM -0700, Abhinav Kumar wrote:
> From: Kuogee Hsieh
>
> In the external HPD case, hotplug event is delivered by pmic glink to DP
> driver
> using drm_aux_hpd_bridge_notify().
There can be other drivers in front of the DP chain. For example,
altmode driver uses
Krzysztof,
> virtio core already sets the .owner, so driver does not need to.
virtio_scsi looks OK to me.
Acked-by: Martin K. Petersen
--
Martin K. Petersen Oracle Linux Engineering
From: Kuogee Hsieh
In the external HPD case, hotplug event is delivered by pmic glink to DP driver
using drm_aux_hpd_bridge_notify().
The stacktrace showing the sequence of events is below:
dp_bridge_hpd_notify+0x18/0x70 [msm]
drm_bridge_connector_detect+0x60/0xe8 [drm_kms_helper]
On 3/28/2024 10:47 PM, Abhinav Kumar wrote:
On 3/28/2024 8:23 PM, Dmitry Baryshkov wrote:
On Fri, 29 Mar 2024 at 04:16, Abhinav Kumar
wrote:
On 3/28/2024 5:10 PM, Dmitry Baryshkov wrote:
On Fri, 29 Mar 2024 at 01:42, Abhinav Kumar
wrote:
On 3/28/2024 3:50 PM, Dmitry Baryshkov
Hi Konrad,
kernel test robot noticed the following build warnings:
[auto build test WARNING on 2b3d5988ae2cb5cd945ddbc653f0a71706231fdd]
url:
https://github.com/intel-lab-lkp/linux/commits/Konrad-Dybcio/soc-qcom-Move-some-socinfo-defines-to-the-header-expand-them/20240405-164231
base
On Fri, Apr 5, 2024 at 5:53 PM Maaz Mombasawala
wrote:
>
> On 4/2/24 16:28, Zack Rusin wrote:
> >
> > @@ -541,6 +518,8 @@ static int vmw_ldu_init(struct vmw_private *dev_priv,
> > unsigned unit)
> >dev_priv->implicit_placement_property,
> >1);
> >
On 4/2/24 16:28, Zack Rusin wrote:
>
> @@ -541,6 +518,8 @@ static int vmw_ldu_init(struct vmw_private *dev_priv,
> unsigned unit)
>dev_priv->implicit_placement_property,
>1);
>
> + vmw_du_init(>base);
> +
> return 0;
>
>
On 4/4/2024 3:08 AM, Dmitry Baryshkov wrote:
The DSI device for the panel was registered by the DSI host, so it is an
error to unregister it from the panel driver. Drop the call to
mipi_dsi_device_unregister().
Fixes: ea4f9975625a ("drm/panel: Add support for Novatek NT36672E panel driver")
On 4/4/2024 3:07 AM, Dmitry Baryshkov wrote:
The DSI device for the panel was registered by the DSI host, so it is an
error to unregister it from the panel driver. Drop the call to
mipi_dsi_device_unregister().
Hi Dmitry,
Reviewed-by: Jessica Zhang
Thanks,
Jessica Zhang
Fixes:
On Fri, Apr 05, 2024 at 11:39:33PM +0300, Dmitry Baryshkov wrote:
> On Fri, 5 Apr 2024 at 22:17, Ville Syrjälä
> wrote:
> >
> > On Fri, Apr 05, 2024 at 06:24:01AM +0300, Dmitry Baryshkov wrote:
> > > On Thu, Apr 04, 2024 at 11:33:25PM +0300, Ville Syrjala wrote:
> > > > From: Ville Syrjälä
> > >
On Fri, 5 Apr 2024 at 22:17, Ville Syrjälä
wrote:
>
> On Fri, Apr 05, 2024 at 06:24:01AM +0300, Dmitry Baryshkov wrote:
> > On Thu, Apr 04, 2024 at 11:33:25PM +0300, Ville Syrjala wrote:
> > > From: Ville Syrjälä
> > >
> > > The modes[] array contains pointers to modes on the connectors'
> > >
The V3D MMU also supports 64KB and 1MB pages, called big and super pages,
respectively. In order to set a 64KB page or 1MB page in the MMU, we need
to make sure that page table entries for all 4KB pages within a big/super
page must be correctly configured.
In order to create a big/super page, we
Currently, we are using an alignment of 128 kB to insert a node, which
ends up wasting memory as we perform plenty of small BOs allocations
(<= 4 kB). We require that allocations are aligned to 128Kb so for any
allocation smaller than that, we are wasting the difference.
This implies that we
Create a function `drm_gem_shmem_create_with_mnt()`, similar to
`drm_gem_shmem_create()`, that has a mountpoint as a argument. This
function will create a shmem GEM object in a given tmpfs mountpoint.
This function will be useful for drivers that have a special mountpoint
with flags enabled.
Create a separate "tmpfs" kernel mount for V3D. This will allow us to
move away from the shmemfs `shm_mnt` and gives the flexibility to do
things like set our own mount options. Here, the interest is to use
"huge=", which should allow us to enable the use of THP for our
shmem-backed objects.
For some applications, such as applications that uses huge pages, we might
want to have a different mountpoint, for which we pass mount flags that
better match our usecase.
Therefore, create a new function `drm_gem_object_init_with_mnt()` that
allow us to define the tmpfs mountpoint where the GEM
This series introduces support for big and super pages in V3D. The V3D MMU has
support for 64KB and 1MB pages, called big pages and super pages, which are
currently not used. Therefore, this patchset has the intention to enable big and
super pages in V3D. The advantage of enabling big and super
If the scheduler initialization fails, GEM initialization must fail as
well. Therefore, if `v3d_sched_init()` fails, free the DMA memory
allocated and return the error value in `v3d_gem_init()`.
Signed-off-by: Maíra Canal
Reviewed-by: Iago Toral Quiroga
---
drivers/gpu/drm/v3d/v3d_gem.c | 3
On Fri, Apr 05, 2024 at 11:23:01AM +0300, Jani Nikula wrote:
> On Thu, 04 Apr 2024, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Switch to the canonical [CONNECTOR:%d:%s] etc. format for
> > printing out kms objects.
>
> I've been pinging for reviews on [1] for a while now. :/
>
> I'm
The pull request you sent on Fri, 5 Apr 2024 13:41:06 +1000:
> https://gitlab.freedesktop.org/drm/kernel.git tags/drm-fixes-2024-04-05
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/89103a164210f1c88caedf880ac9ab9576a1190d
Thank you!
--
Deet-doot-dot, I am a bot.
On Fri, 2024-04-05 at 17:53 +0200, Danilo Krummrich wrote:
> On 3/31/24 08:45, Mikhail Kobuk wrote:
> > Output Resource (dcb->or) value is not guaranteed to be non-zero
> > (i.e.
> > in drivers/gpu/drm/nouveau/nouveau_bios.c, in
> > 'fabricate_dcb_encoder_table()'
> > 'dcb->or' is assigned value
On Fri, Apr 05, 2024 at 09:57:07AM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 04.04.24 um 22:33 schrieb Ville Syrjala:
> > From: Ville Syrjälä
> >
> > Get rid of all the redundant debugs and just wait until the end
> > to print which mode (and of which type) we picked.
> >
> > Signed-off-by:
On Fri, Apr 05, 2024 at 06:32:46AM +0300, Dmitry Baryshkov wrote:
> On Thu, Apr 04, 2024 at 11:33:28PM +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > crtc->mode is legacy junk and shouldn't really be used with
> > atomic drivers.
> >
> > Most (all?) atomic drivers do end up still
On Tue, 02 Apr 2024 05:57:14 +0300, Dmitry Baryshkov wrote:
> Fix several warnings produced by the display nodes.
>
> Please excuse me for the spam for sending v3 soon after v2.
>
>
Applied, thanks!
[1/4] dt-bindings: display/msm: sm8150-mdss: add DP node
On Wed, 06 Mar 2024 11:35:15 -0800, Abhinav Kumar wrote:
> Fix the typo in the name of dp_display_handle_port_status_changed().
>
>
Applied, thanks!
[1/1] drm/msm/dp: fix typo in dp_display_handle_port_status_changed()
(no commit info)
On Sat, 30 Mar 2024 05:53:22 +0200, Dmitry Baryshkov wrote:
> There is little point in using %ps to print a value known to be NULL. On
> the other hand it makes sense to print the callback symbol in the
> 'invalid IRQ' message. Correct those two error messages to make more
> sense.
>
>
On Fri, 29 Mar 2024 12:46:26 -0700, Kuogee Hsieh wrote:
> At current x1e80100 interface table, interface #3 is wrongly
> connected to DP controller #0 and interface #4 wrongly connected
> to DP controller #2. Fix this problem by connect Interface #3 to
> DP controller #0 and interface #4 connect
On Thu, 14 Mar 2024 03:10:40 +0200, Dmitry Baryshkov wrote:
> Bring back a set of patches extracted from [1] per Abhinav's suggestion.
>
> Rework debugging overrides for the bandwidth and clock settings. Instead
> of specifying the 'mode' and some values, allow one to set the affected
> value
On Fri, Apr 05, 2024 at 06:24:01AM +0300, Dmitry Baryshkov wrote:
> On Thu, Apr 04, 2024 at 11:33:25PM +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > The modes[] array contains pointers to modes on the connectors'
> > mode lists, which are protected by dev->mode_config.mutex.
> >
On Mon, 25 Mar 2024 14:08:09 -0700, Stephen Boyd wrote:
> These debug prints are missing newlines, leading to multiple messages
> being printed on one line and hard to read logs. Add newlines to have
> the debug prints on separate lines. The DBG macro used to add a newline,
> but I missed that
Makes sense.
Reviewed-by: Ian Forbes
On Tue, Apr 2, 2024 at 6:28 PM Zack Rusin wrote:
>
> The conditional was supposed to prevent enabling of a crtc state
> without a set primary plane. Accidently it also prevented disabling
> crtc state with a set primary plane. Neither is correct.
>
> Fix
On Wed, 13 Mar 2024 17:43:04 +0100, Johan Hovold wrote:
> As I've reported elsewhere, I've been hitting runtime PM usage count
> leaks when investigated a DisplayPort hotplug regression on the Lenovo
> ThinkPad X13s. [1]
>
> This series addresses two obvious leaks on disconnect and on connect
>
On 4/5/2024 11:19 AM, Dmitry Baryshkov wrote:
On Fri, 5 Apr 2024 at 21:17, Abhinav Kumar wrote:
On 4/5/2024 11:16 AM, Dmitry Baryshkov wrote:
On Fri, 5 Apr 2024 at 20:20, Abhinav Kumar wrote:
On 3/9/2024 7:09 AM, Dmitry Baryshkov wrote:
All the bridges that are being used with the
On Fri, Apr 05, 2024 at 10:45:42AM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 07.03.24 um 21:39 schrieb Jani Nikula:
> > Add a printer based function for dumping the modeline, so it's not
> > limited to KMS debug.
> >
> > Note: The printed output intentionally does not have the "Modeline"
> >
On Fri, 2024-04-05 at 09:30 -0700, Easwar Hariharan wrote:
>
> Thanks for the review, and for the appetite to go further! So we are
> on the same page, you would prefer
> renaming to controller/target like the feedback on other drm drivers
> (i915, gma500, radeon)?
FWIW I'm in support of this as
On Wed, Apr 03, 2024 at 06:19:34AM -0700, Guenter Roeck wrote:
> Declaring the defines needed for suppressing warning inside
> '#ifdef CONFIG_DEBUG_BUGVERBOSE' results in a kerneldoc warning.
>
> .../bug.h:29: warning: expecting prototype for _EMIT_BUG_ENTRY().
> Prototype was for
On Fri, 5 Apr 2024 at 18:59, Arnd Bergmann wrote:
>
> From: Arnd Bergmann
>
> The modification to a6xx_get_shader_block() had no effect other
> than causing a warning:
>
> drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c:843:6: error: variable 'out' set
> but not used
On Fri, 5 Apr 2024 at 21:17, Abhinav Kumar wrote:
>
>
>
> On 4/5/2024 11:16 AM, Dmitry Baryshkov wrote:
> > On Fri, 5 Apr 2024 at 20:20, Abhinav Kumar
> > wrote:
> >>
> >>
> >>
> >> On 3/9/2024 7:09 AM, Dmitry Baryshkov wrote:
> >>> All the bridges that are being used with the MSM DSI hosts
On 4/5/2024 11:16 AM, Dmitry Baryshkov wrote:
On Fri, 5 Apr 2024 at 20:20, Abhinav Kumar wrote:
On 3/9/2024 7:09 AM, Dmitry Baryshkov wrote:
All the bridges that are being used with the MSM DSI hosts have been
converted to support DRM_BRIDGE_ATTACH_NO_CONNECTOR. Drop the fallback
code
On Fri, 5 Apr 2024 at 20:20, Abhinav Kumar wrote:
>
>
>
> On 3/9/2024 7:09 AM, Dmitry Baryshkov wrote:
> > All the bridges that are being used with the MSM DSI hosts have been
> > converted to support DRM_BRIDGE_ATTACH_NO_CONNECTOR. Drop the fallback
> > code and require
On Fri, 5 Apr 2024 at 20:35, Abhinav Kumar wrote:
>
>
>
> On 3/9/2024 7:09 AM, Dmitry Baryshkov wrote:
> > Currently the MSM DSI driver looks for the next bridge during
> > msm_dsi_modeset_init(). If the bridge is not registered at that point,
> > this might result in -EPROBE_DEFER, which can be
On Fri, Apr 05, 2024 at 04:42:14PM +, Zeng, Oak wrote:
> > > Above codes deal with a case where dma map is not needed. As I
> > > understand it, whether we need a dma map depends on the devices
> > > topology. For example, when device access host memory or another
> > > device's memory through
On Wed, Apr 3, 2024 at 11:37 AM Adrián Larumbe
wrote:
>
> Up to this day, all fdinfo-based GPU profilers must traverse the entire
> /proc directory structure to find open DRM clients with fdinfo file
> descriptors. This is inefficient and time-consuming.
>
> This patch adds a new device class
On 3/9/2024 7:09 AM, Dmitry Baryshkov wrote:
Currently the MSM DSI driver looks for the next bridge during
msm_dsi_modeset_init(). If the bridge is not registered at that point,
this might result in -EPROBE_DEFER, which can be problematic that late
during the device probe process. Move next
On 3/9/2024 7:09 AM, Dmitry Baryshkov wrote:
All the bridges that are being used with the MSM DSI hosts have been
converted to support DRM_BRIDGE_ATTACH_NO_CONNECTOR. Drop the fallback
code and require DRM_BRIDGE_ATTACH_NO_CONNECTOR to be supported by the
downstream bridges.
Signed-off-by:
Hi Wolfram,
On 4/5/2024 3:18 AM, Wolfram Sang wrote:
> Hello Easwar,
>
> On Fri, Mar 29, 2024 at 05:00:24PM +, Easwar Hariharan wrote:
>> I2C v7, SMBus 3.2, and I3C specifications have replaced "master/slave"
>> with more appropriate terms. Inspired by and following on to Wolfram's
>> series
On Mon, Apr 01, 2024 at 01:48:58PM -0700, Abhinav Kumar wrote:
> After IGT migrating to dynamic sub-tests, the pipe prefixes
> in the expected fails list are incorrect. Lets drop those
> to accurately match the expected fails.
>
> In addition, update the xfails list to match the current passing
>
On Fri, Apr 05, 2024 at 12:29:07PM +0300, Jani Nikula wrote:
> Logging u32 pixel formats using %4.4s format string with a pointer to
> the u32 is somewhat questionable, as well as dependent on byte
> order. There's a kernel extension format specifier %p4cc to format 4cc
> codes. Use it across the
> -Original Message-
> From: dri-devel On Behalf Of Jason
> Gunthorpe
> Sent: Friday, April 5, 2024 8:37 AM
> To: Zeng, Oak
> Cc: dri-devel@lists.freedesktop.org; intel...@lists.freedesktop.org; Brost,
> Matthew ; thomas.hellst...@linux.intel.com;
> Welty, Brian ; Ghimiray, Himal
On 4/4/24 18:02, Arnd Bergmann wrote:
From: Arnd Bergmann
Calling a function through an incompatible pointer type causes breaks
kcfi, so clang warns about the assignment:
drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowof.c:73:10: error: cast from
'void (*)(const void *)' to 'void (*)(void
On 3/30/24 15:12, Kees Cook wrote:
Using the end of rpc->entries[] for addressing runs into both compile-time
and run-time detection of accessing beyond the end of the array. Use the
base pointer instead, since was allocated with the additional bytes for
storing the strings. Avoids the following
On 4/5/2024 9:15 AM, Danilo Krummrich wrote:
> Hi Easwar,
>
> On 3/29/24 18:00, Easwar Hariharan wrote:
>> I2C v7, SMBus 3.2, and I3C 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
On 05.04.2024 16:47, Jani Nikula wrote:
On Mon, 27 Feb 2023, Peter Zijlstra wrote:
On Thu, Feb 23, 2023 at 10:24:19PM +0100, Andrzej Hajda wrote:
On 22.02.2023 18:04, Peter Zijlstra wrote:
On Wed, Jan 18, 2023 at 04:35:22PM +0100, Andrzej Hajda wrote:
Andrzej Hajda (7):
arch: rename
Hi Easwar,
On 3/29/24 18:00, Easwar Hariharan wrote:
I2C v7, SMBus 3.2, and I3C 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
I2C_ALGOBIT bitbanging interface,
From: Arnd Bergmann
The modification to a6xx_get_shader_block() had no effect other
than causing a warning:
drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c:843:6: error: variable 'out' set
but not used [-Werror,-Wunused-but-set-variable]
u64 out = dumper->iova + A6XX_CD_DATA_OFFSET;
On 3/31/24 08:45, Mikhail Kobuk wrote:
Output Resource (dcb->or) value is not guaranteed to be non-zero (i.e.
in drivers/gpu/drm/nouveau/nouveau_bios.c, in 'fabricate_dcb_encoder_table()'
'dcb->or' is assigned value '0' in call to 'fabricate_dcb_output()').
I don't really know much about the
On 3/22/2024 11:57 AM, Jeffrey Hugo wrote:
Add 3 debugfs entries that can be useful in debugging a variety of
issues.
bootlog - output the device bootloader log
fifo_size - output the configured dbc fifo size
queued - output how many requests are queued in the dbc fifo
Bootlog is unique to
On Fri, Apr 5, 2024, at 17:43, Niklas Schnelle wrote:
> In a future patch HAS_IOPORT=n will disable inb()/outb() and friends at
> compile time. We thus need to add HAS_IOPORT as dependency for
> those drivers using them.
>
> Co-developed-by: Arnd Bergmann
> Signed-off-by: Arnd Bergmann
>
Hi Greg, Helge,
This is a follow up in my ongoing effort of making inb()/outb() and
similar I/O port accessors compile-time optional. Previously I sent this
as a treewide series titled "treewide: Remove I/O port accessors for
HAS_IOPORT=n" with the latest being its 5th version[0]. With a
In a future patch HAS_IOPORT=n will disable inb()/outb() and friends at
compile time. We thus need to add HAS_IOPORT as dependency for
those drivers using them.
Co-developed-by: Arnd Bergmann
Signed-off-by: Arnd Bergmann
Signed-off-by: Niklas Schnelle
---
Note: This patch does not depend any
On 01/04/2024 12:07, Paneer Selvam, Arunpravin wrote:
Hi Matthew,
On 3/28/2024 10:18 PM, Matthew Auld wrote:
On 28/03/2024 16:07, Paneer Selvam, Arunpravin wrote:
Hi Matthew,
On 3/26/2024 11:39 PM, Matthew Auld wrote:
On 18/03/2024 21:40, Arunpravin Paneer Selvam wrote:
- Add tracking
On Fri, Apr 5, 2024 at 8:37 AM kernel test robot wrote:
>
> tree/branch:
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
> branch HEAD: 8568bb2ccc278f344e6ac44af6ed010a90aa88dc Add linux-next
> specific files for 20240405
>
> Error/Warni
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: 8568bb2ccc278f344e6ac44af6ed010a90aa88dc Add linux-next specific
files for 20240405
Error/Warning reports:
https://lore.kernel.org/oe-kbuild-all/202404051333.7und7ppw-...@intel.com
https
This is needed because we want to reset those devices in device-agnostic
code such as lima_sched.
In particular, masking irqs will be useful before a hard reset to
prevent race conditions.
Signed-off-by: Erico Nunes
---
drivers/gpu/drm/lima/lima_bcast.c | 12
There is a race condition in which a rendering job might take just long
enough to trigger the drm sched job timeout handler but also still
complete before the hard reset is done by the timeout handler.
This runs into race conditions not expected by the timeout handler.
In some very specific cases
In commit 53cb55b20208 ("drm/lima: handle spurious timeouts due to high
irq latency") a check was added to detect an unexpectedly high interrupt
latency timeout.
With further investigation it was noted that on Mali-450 the pp bcast
irq may also be a trigger of race conditions against the timeout
v1 reference:
https://patchwork.freedesktop.org/series/131902/
Changes v1 -> v2:
- Split synchronize_irq of pp bcast irq change into (new) patch 2.
Erico Nunes (3):
drm/lima: add mask irq callback to gp and pp
drm/lima: include pp bcast irq in timeout handler check
drm/lima: mask irqs in
On 4/2/2024 4:49 AM, Jacek Lawrynowicz wrote:
ivpu_device->context_xa is locked both in kernel thread and IRQ context.
It requires XA_FLAGS_LOCK_IRQ flag to be passed during initialization
otherwise the lock could be acquired from a thread and interrupted by
an IRQ that locks it for the second
On 4/2/2024 4:49 AM, Jacek Lawrynowicz wrote:
Change "VPU" to "NPU" in ivpu_suspend() so it matches all other error
messages.
Signed-off-by: Jacek Lawrynowicz
Reviewed-by: Jeffrey Hugo
On 4/2/2024 4:49 AM, Jacek Lawrynowicz wrote:
DRM_IVPU_PARAM_CORE_CLOCK_RATE returned current NPU frequency which
Commit text should be present tense, so returned->returns
could be 0 if device was sleeping. This value wasn't really useful to
also wasn't->isn't
the user space, so return
On 4/2/2024 4:49 AM, Jacek Lawrynowicz wrote:
From: "Wachowski, Karol"
This patch improves readability and clarity of MMU error messages.
Previously, the error strings were somewhat confusing and could lead to
ambiguous interpretations, making it difficult to diagnose issues.
Signed-off-by:
On 4/2/2024 4:49 AM, Jacek Lawrynowicz wrote:
Put NPU in D3hot after ivpu_resume() fails to power up the device.
This will assure that D3->D0 power cycle will be performed before
the next resume and also will minimize power usage in this corner case.
Fixes: 28083ff18d3f ("accel/ivpu: Fix DevTLB
On 4/2/2024 4:49 AM, Jacek Lawrynowicz wrote:
From: "Wachowski, Karol"
In case of failed power up we end up left in PCI D3hot
state making it impossible to access NPU registers on retry.
Enter D0 state on retry before proceeding with power up sequence.
Fixes: 28083ff18d3f ("accel/ivpu: Fix
On 4/2/2024 4:49 AM, Jacek Lawrynowicz wrote:
Always enter D3hot after entering D0i3 an all platforms.
This minimizes power usage.
Signed-off-by: Jacek Lawrynowicz
Reviewed-by: Jeffrey Hugo
On 4/2/2024 4:49 AM, Jacek Lawrynowicz wrote:
From: "Wachowski, Karol"
Return value of drmm_mutex_init(ipc->lock) was unchecked.
Fixes: 5d7422cfb498 ("accel/ivpu: Add IPC driver and JSM messages")
Cc: # v6.3+
Signed-off-by: Wachowski, Karol
Signed-off-by: Jacek Lawrynowicz
Reviewed-by:
On Fri, Apr 05, 2024 at 07:54:46PM +0530, Vinod Koul wrote:
> On 06-03-24, 15:48, Maxime Ripard wrote:
> > Hi Alexander,
> >
> > On Wed, Mar 06, 2024 at 11:16:19AM +0100, Alexander Stein wrote:
> > > From: Sandor Yu
> > >
> > > Allow HDMI PHYs to be configured through the generic
> > >
These pointers are frequently the same and memcmp does not compare the
pointers before comparing their contents so this was wasting cycles
comparing 16 KiB of memory which will always be equal.
Fixes: bb6780aa5a1d ("drm/vmwgfx: Diff cursors when using cmds")
Signed-off-by: Ian Forbes
Cc: #
On 06-03-24, 11:16, Alexander Stein wrote:
> From: Sandor Yu
>
> Add Cadence HDP-TX DisplayPort and HDMI PHY driver for i.MX8MQ.
>
> Cadence HDP-TX PHY could be put in either DP mode or
> HDMI mode base on the configuration chosen.
> DisplayPort or HDMI PHY mode is configured in the driver.
>
On Mon, 27 Feb 2023, Peter Zijlstra wrote:
> On Thu, Feb 23, 2023 at 10:24:19PM +0100, Andrzej Hajda wrote:
>> On 22.02.2023 18:04, Peter Zijlstra wrote:
>> > On Wed, Jan 18, 2023 at 04:35:22PM +0100, Andrzej Hajda wrote:
>> >
>> > > Andrzej Hajda (7):
>> > >arch: rename all internal names
From: Arnd Bergmann
After my fix yesterday, I ran into another problem of the same kind:
aarch64-linux-ld: drivers/gpu/drm/bridge/analogix/analogix_dp_core.o: in
function `drm_dp_dpcd_readb':
analogix_dp_core.c:(.text+0x194): undefined reference to `drm_dp_dpcd_read'
aarch64-linux-ld:
On 06-03-24, 15:48, Maxime Ripard wrote:
> Hi Alexander,
>
> On Wed, Mar 06, 2024 at 11:16:19AM +0100, Alexander Stein wrote:
> > From: Sandor Yu
> >
> > Allow HDMI PHYs to be configured through the generic
> > functions through a custom structure added to the generic union.
> >
> > The
Hi Sato-san,
On Thu, Apr 4, 2024 at 7:15 AM Yoshinori Sato
wrote:
> Add Renesas SH7751 SCIF.
>
> Signed-off-by: Yoshinori Sato
> Reviewed-by: Geert Uytterhoeven
> --- a/Documentation/devicetree/bindings/serial/renesas,scif.yaml
> +++
Hi Sato-san,
On Thu, Apr 4, 2024 at 7:15 AM Yoshinori Sato
wrote:
> Signed-off-by: Yoshinori Sato
Thanks for the update!
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/soc/renesas/sh.yaml
> + compatible:
> +oneOf:
As adding more SoCs is expected, having oneOf from the start
what does "rebase" instead of "PATCH" is supposed to mean here?
And then we have a "PATCH v2" as reply to this one.
Shouldn't this go to dri-devel (too)?
Lucas De Marchi
On Thu, Apr 04, 2024 at 12:48:11PM +0200, Maarten Lankhorst wrote:
From: Maarten Lankhorst
In some cases we want to flush
Hi Sato-san,
Thanks for your patch!
On Thu, Apr 4, 2024 at 7:15 AM Yoshinori Sato
wrote:
> Miscellaneous Timing and Miscellaneous Control registers definition.
Please do not put raw register value definitions into DT bindings.
> Signed-off-by: Yoshinori Sato
> --- /dev/null
> +++
On Thu, 04 Apr 2024 19:14:48 +0100, Alex Constantino wrote:
> This reverts commit 5a838e5d5825c85556011478abde708251cc0776.
>
> Changes from commit 5a838e5d5825 ("drm/qxl: simplify qxl_fence_wait") would
> result in a '[TTM] Buffer eviction failed' exception whenever it reached a
> timeout.
> Due
On Wed, 03 Apr 2024 12:56:20 +0200, Maxime Ripard wrote:
> Commit c0e0f139354c ("drm: Make drivers depends on DRM_DW_HDMI") turned
> select dependencies into depends on ones. However, DRM_DW_HDMI was not
> manually selectable which resulted in no way to enable the drivers that
> were now depending
On Wed, 03 Apr 2024 12:56:19 +0200, Maxime Ripard wrote:
> The DisplayPort helpers rely on some
> (__drm_atomic_helper_private_obj_duplicate_state,
> drm_kms_helper_hotplug_event) helpers found in files compiled by
> DRM_KMS_HELPER.
>
> Prior to commit d674858ff979 ("drm/display: Make all helpers
On 4/5/24 21:56, Geert Uytterhoeven wrote:
> Hi Sato-san,
>
> On Thu, Apr 4, 2024 at 7:15 AM Yoshinori Sato
> wrote:
>> divider and gate only support 32-bit registers.
>> Older hardware uses narrower registers, so I want to be able to handle
>> 8-bit and 16-bit wide registers.
>>
>> Seven
Hi Sato-san,
On Thu, Apr 4, 2024 at 7:15 AM Yoshinori Sato
wrote:
> divider and gate only support 32-bit registers.
> Older hardware uses narrower registers, so I want to be able to handle
> 8-bit and 16-bit wide registers.
>
> Seven clk_divider flags are used, and if I add flags for 8bit access
1 - 100 of 159 matches
Mail list logo
