svm_ioctl() should return negative error code in default case.
Fixes: 42de677f7999 ("drm/amdkfd: register svm range")
Signed-off-by: Su Hui
---
Ps: When I try to compile this file, there is a error :
drivers/gpu/drm/amd/amdkfd/kfd_migrate.c:28:10: fatal error: amdgpu_sync.h:
No such file or direc
On 3/25/24 03:57, Kuninori Morimoto wrote:
From DT point of view, in general, drivers should be asking for a
specific port number because their function is fixed in the binding.
of_graph_get_next_endpoint() doesn't match to this concept.
Simply replace
- of_graph_get_next_endpoint(xxx
We already have of_graph_get_remote_port(), Let's use it.
Signed-off-by: Kuninori Morimoto
---
drivers/video/fbdev/omap2/omapfb/dss/dss-of.c | 15 +--
1 file changed, 1 insertion(+), 14 deletions(-)
diff --git a/drivers/video/fbdev/omap2/omapfb/dss/dss-of.c
b/drivers/video/fbdev/om
We already have for_each_endpoint_of_node(), don't use
of_graph_get_next_endpoint() directly. Replace it.
Signed-off-by: Kuninori Morimoto
---
drivers/video/fbdev/omap2/omapfb/dss/omapdss-boot-init.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/omap2/
We already have for_each_endpoint_of_node(), don't use
of_graph_get_next_endpoint() directly. Replace it.
Signed-off-by: Kuninori Morimoto
---
drivers/staging/media/deprecated/atmel/atmel-sama5d2-isc.c | 6 +-
drivers/staging/media/deprecated/atmel/atmel-sama7g5-isc.c | 6 +-
2 files cha
We already have for_each_endpoint_of_node(), don't use
of_graph_get_next_endpoint() directly. Replace it.
Signed-off-by: Kuninori Morimoto
---
drivers/media/platform/xilinx/xilinx-vipp.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/media/platform/xilinx/xilin
We already have for_each_endpoint_of_node(), don't use
of_graph_get_next_endpoint() directly. Replace it.
Signed-off-by: Kuninori Morimoto
---
.../microchip/microchip-sama5d2-isc.c | 19 +++
.../microchip/microchip-sama7g5-isc.c | 19 +++
2 files c
We already have for_each_endpoint_of_node(), don't use
of_graph_get_next_endpoint() directly. Replace it.
Signed-off-by: Kuninori Morimoto
---
drivers/media/platform/ti/am437x/am437x-vpfe.c | 8 +++-
drivers/media/platform/ti/davinci/vpif_capture.c | 11 +--
2 files changed, 8 ins
We already have for_each_endpoint_of_node(), don't use
of_graph_get_next_endpoint() directly. Replace it.
Signed-off-by: Kuninori Morimoto
Reviewed-by: Suzuki K Poulose
---
drivers/hwtracing/coresight/coresight-platform.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/d
We already have for_each_endpoint_of_node(), don't use
of_graph_get_next_endpoint() directly. Replace it.
Signed-off-by: Kuninori Morimoto
---
drivers/gpu/drm/omapdrm/dss/base.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/dss/base.c
b/drivers/gp
Hi Rob, Helge
We already have for_each_endpoint_of_node(), but some drivers are
not using it. This patch-set replace it.
This patch-set is related to "OF" (= Rob), but many driveres are for
"MultiMedia" (= Helge). I'm not sure who can handle it.
[o] done
[x] under reviewing
[*] this patch-set
>From DT point of view, in general, drivers should be asking for a
specific port number because their function is fixed in the binding.
of_graph_get_next_endpoint() doesn't match to this concept.
Simply replace
- of_graph_get_next_endpoint(xxx, NULL);
+ of_graph_get_endpoint_by_r
>From DT point of view, in general, drivers should be asking for a
specific port number because their function is fixed in the binding.
of_graph_get_next_endpoint() doesn't match to this concept.
Simply replace
- of_graph_get_next_endpoint(xxx, NULL);
+ of_graph_get_endpoint_by_r
Hi Rob, Helge
This is resend of remain of replace of_graph_get_next_endpoint()
(In previous patch-set, media maintainer accepted some of them).
This patches are for GPU/Video, I'm not sure who should handle it.
GPU/Video maintainer as Video, or Rom as OF ?
We should get rid of or minimize of_gr
Hello:
This patch was applied to chrome-platform/linux.git (for-next)
by Mark Brown :
On Wed, 7 Feb 2024 19:40:14 +0100 you wrote:
> Changes since v2
> (https://lore.kernel.org/linux-spi/cover.1705944943.git.u.kleine-koe...@pengutronix.de):
>
> - Drop patch "mtd: rawnand: fsl_elbc: Let .probe
Hello:
This patch was applied to chrome-platform/linux.git (for-kernelci)
by Mark Brown :
On Wed, 7 Feb 2024 19:40:14 +0100 you wrote:
> Changes since v2
> (https://lore.kernel.org/linux-spi/cover.1705944943.git.u.kleine-koe...@pengutronix.de):
>
> - Drop patch "mtd: rawnand: fsl_elbc: Let .pr
On Sat, Mar 23, 2024 at 4:47 PM Sharma, Shashank
wrote:
>
>
> On 23/03/2024 15:52, Johannes Weiner wrote:
> > On Thu, Mar 14, 2024 at 01:09:57PM -0400, Johannes Weiner wrote:
> >> Hello,
> >>
> >> On Fri, Mar 08, 2024 at 12:32:33PM +0100, Christian König wrote:
> >>> Am 07.03.24 um 23:07 schrieb J
From: Randy Dunlap
[ Upstream commit 7edd06233958d9086a9e3eb723a8768d3c5a9ce1 ]
When VIDEO is not set, there is a build error. Fix that by selecting
VIDEO for PS3_PS3AV.
ERROR: modpost: ".video_get_options" [drivers/ps3/ps3av_mod.ko] undefined!
Fixes: dae7fbf43fd0 ("driver/ps3: Include for mo
From: Randy Dunlap
[ Upstream commit 7edd06233958d9086a9e3eb723a8768d3c5a9ce1 ]
When VIDEO is not set, there is a build error. Fix that by selecting
VIDEO for PS3_PS3AV.
ERROR: modpost: ".video_get_options" [drivers/ps3/ps3av_mod.ko] undefined!
Fixes: dae7fbf43fd0 ("driver/ps3: Include for mo
From: Randy Dunlap
[ Upstream commit 7edd06233958d9086a9e3eb723a8768d3c5a9ce1 ]
When VIDEO is not set, there is a build error. Fix that by selecting
VIDEO for PS3_PS3AV.
ERROR: modpost: ".video_get_options" [drivers/ps3/ps3av_mod.ko] undefined!
Fixes: dae7fbf43fd0 ("driver/ps3: Include for mo
Hi all,
fetching the drm-intel tree produced this warning:
Commit
326e30e4624c ("drm/i915: Drop dead code for pvc")
added this unexpected file:
drivers/gpu/drm/i915/gt/intel_workarounds.c.rej
--
Cheers,
Stephen Rothwell
pgpVgp90Bny5x.pgp
Description: OpenPGP digital signature
On Sun, 24 Mar 2024 at 20:57, Abel Vesa wrote:
>
> Instead of relying on different compatibles for eDP and DP, lookup
> the panel node in devicetree to figure out the connector type and
> then pass on that information to the PHY. External DP doesn't have
> a panel described in DT, therefore, assum
Instead of relying on different compatibles for eDP and DP, lookup
the panel node in devicetree to figure out the connector type and
then pass on that information to the PHY. External DP doesn't have
a panel described in DT, therefore, assume it's eDP if panel node
is present.
Signed-off-by: Abel
Add the X1E80100 DP descs and compatible. This platform will be using
a single compatible for both eDP and DP mode. The actual mode will
be set based on the presence of the panel node in DT.
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Abel Vesa
---
drivers/gpu/drm/msm/dp/dp_display.c | 9 +
proach
has been dropped due to bindings concerns. So now we lookup the panel
node in DT and based on it's presence we can safely say if it is eDP or not.
The PHY counterpart patchset is here:
https://lore.kernel.org/all/20240324-x1e80100-phy-edp-compatible-refactor-v5-0-a0db5f315...@linaro.org
On Sun, 24 Mar 2024 10:21:28 +0100
Christophe JAILLET wrote:
> Le 23/03/2024 à 22:25, Marek Behún a écrit :
> > On Sat, 23 Mar 2024 22:10:40 +0100
> > Christophe JAILLET wrote:
> >
>
> ...
>
> >>>static int pvt_ts_dbgfs_create(struct pvt_device *pvt, struct device
> >>> *dev)
> >>>
On Sun, 24 Mar 2024 at 11:55, Akhil P Oommen wrote:
>
> On Sat, Mar 23, 2024 at 12:56:56AM +0200, Dmitry Baryshkov wrote:
> > The msm_gpummu.c implementation is used only on A2xx and it is tied to
> > the A2xx registers. Rename the source file accordingly.
> >
>
> There are very few functions in t
On Sun, 10 Mar 2024 13:48:29 +0100
Paul Cercueil wrote:
> Hi Jonathan,
>
> Here's the final-er version of the IIO DMABUF patchset.
>
> This v9 fixes the few issues reported by the kernel bot.
>
> This was based on next-20240308.
>
> Changelog:
>
> - [3/6]:
> - Select DMA_SHARED_BUFFER in
On Sun, 24 Mar 2024 at 12:30, Akhil P Oommen wrote:
>
> On Sat, Mar 23, 2024 at 12:57:02AM +0200, Dmitry Baryshkov wrote:
> > Generate DRM/MSM headers on the fly during kernel build. This removes a
> > need to push register changes to Mesa with the following manual
> > synchronization step. Existi
On Sat, Mar 23, 2024 at 12:57:02AM +0200, Dmitry Baryshkov wrote:
> Generate DRM/MSM headers on the fly during kernel build. This removes a
> need to push register changes to Mesa with the following manual
> synchronization step. Existing headers will be removed in the following
> commits (split aw
commit e531fdb5cd5e ("dma-buf/sw_sync: Avoid recursive lock during fence
signal") fixed a recursive locking when a signal callback released a fence.
It did it by taking an extra reference while traversing it on the list and
holding the timeline lock.
However, this is racy and may end up adding to
On Sat, Mar 23, 2024 at 12:56:56AM +0200, Dmitry Baryshkov wrote:
> The msm_gpummu.c implementation is used only on A2xx and it is tied to
> the A2xx registers. Rename the source file accordingly.
>
There are very few functions in this file and a2xx_gpu.c is a relatively
small source file too. Sh
Le 23/03/2024 à 22:25, Marek Behún a écrit :
On Sat, 23 Mar 2024 22:10:40 +0100
Christophe JAILLET wrote:
...
static int pvt_ts_dbgfs_create(struct pvt_device *pvt, struct device *dev)
{
- pvt->dbgfs_dir = debugfs_create_dir(dev_name(dev), NULL);
+ pvt->dbgfs_dir = devm_de
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
From: Emilio Mendoza Reyes
This patch is the second of a set of two.
In the kernel docs there is a todo:
Link:
https://www.kernel.org/doc/html/v6.8/gpu/todo.html#clean-up-checks-for-already-prepared-enabled-in-panels
The first patch addresses re
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
From: Emilio Mendoza Reyes
The patch ("drm/panel: Check for already prepared/enabled in drm_panel")
moved checking for (en/dis)abled and [un]prepared panels before specific
function calls to drm_panel.c.Those checks that still exist within the
pane
37 matches
Mail list logo
